WebVTT timestamp format incorrect when including more than zero and less than ten hours

[anonymous_coward]

Summary of the bug: WebVTT spec requires that, when hours are required, WebVTT timestamps should have two or more characters (ie be zero-padded like the other portions of the timestamp). ​https://www.w3.org/TR/webvtt1/#webvtt-timestamp

webvttenc does not zero pad the hours part in webvtt_write_time.

How to reproduce:

% printf "1\n01:00:00.000 --> 01:01:00.000\nTest" | ffmpeg -y -f srt -i - -f webvtt test.webvtt
ffmpeg version N-91807-ga77c2df Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 4.8.5 (GCC) 20150623 (Red Hat 4.8.5-28)
  configuration: --prefix=/home/anonymous_coward/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/home/anonymous_coward/ffmpeg_build/include --extra-ldflags=-L/home/anonymous_coward/ffmpeg_build/lib --extra-libs=-lpthread --extra-libs=-lm --bindir=/home/anonymous_coward/bin --enable-gpl --enable-libfreetype --enable-libx264 --enable-libx265 --enable-libzvbi
  libavutil      56. 19.100 / 56. 19.100
  libavcodec     58. 27.101 / 58. 27.101
  libavformat    58. 18.100 / 58. 18.100
  libavdevice    58.  4.101 / 58.  4.101
  libavfilter     7. 26.100 /  7. 26.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, srt, from 'pipe:':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Subtitle: subrip
Output #0, webvtt, to 'test.webvtt':
  Metadata:
    encoder         : Lavf58.18.100
    Stream #0:0: Subtitle: webvtt
    Metadata:
      encoder         : Lavc58.27.101 webvtt
Stream mapping:
  Stream #0:0 -> #0:0 (subrip (srt) -> webvtt (native))
size=       0kB time=01:00:00.00 bitrate=   0.0kbits/s speed=6.67e+07x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 925.000000%

Contents of test.webvtt should be

WEBVTT

01:00:00.000 --> 01:01:00.000
Test

but are instead

WEBVTT

1:00:00.000 --> 1:01:00.000
Test

[Carl Eugen Hoyos]

Patch sent.

[Carl Eugen Hoyos]

Should be fixed in 26902f2ef0dc7b65992228767b8adba46e7a6d48, thank you for the report!