[FFmpeg-devel] [PATCH] Matroska demuxer adds WebVTT support

Matthew Heaney matthewjheaney at google.com
Fri Jul 19 16:21:41 CEST 2013

On Fri, Jul 19, 2013 at 6:33 AM, Nicolas George <
nicolas.george at normalesup.org> wrote:

> That is very good news. I just hope that if someone adds support for WebVTT
> in another generic format, they will have the intelligence of using the
> same
> format as Matroska. Otherwise, one of the demuxers will need a special
> case;
> that is what I had in mind when I spoke of "not necessarily under ffmpeg's
> control" above.

The representation of WebVTT cues in WebM is strictly an artifact of
Matroska.  There's no expectation that that representation would make sense
for some other container.  Frank and I (along with various browser vendors)
designed the representation that way so that a Matroska demuxer could
losslessly reconstruct the original WebVTT cue from its embedded
representation.  It was never intended as a general-purpose embedded
representation of WebVTT cues.

As it stands now, the Matroska demuxer reconstructs the WebVTT cue such
that it exactly matches what the WebVTT demuxer already pushes downstream.
 To me this makes perfect sense (hence the patch), since the format of the
WebVTT cue itself is canonical.

I can change the WebVTT demuxer to convert the original WebVTT cues into a
format that matches the embedded representation in a WebM file, but one
issue is that this will pollute the rest of ffmpeg with artifacts of WebM.
 Are you sure this is what you want?  If you use WebVTT cues as the
canonical representation (as the WebVTT demuxer does now, and the current
patch does for the WebM demuxer), this has the benefit that only the WebM
demuxer has to care about the representation WebVTT cues in a WebM file.

More information about the ffmpeg-devel mailing list