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

[wm4]

On Fri, 19 Jul 2013 10:21:41 -0400
Matthew Heaney <matthewjheaney at google.com> wrote:

> 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.

To be fair, it's exactly the same for ASS subtitles. FFmpeg now has two
packet formats for ASS: one as used in Matroska packets ("ass"), and one
as used in .ass files ("ssa", has nothing to do with SSA). This is a
recent change, and before this, matroskadec.c mangled the Matroska
packets to make them look like the packets assdec.c outputs. But this
was a problem in some ways (for example, duplicated timestamps), so it
was changed.

In my opinion, the Matroska ASS packet format is a superset of what
assdec.c outputs, so assdec.c should be changed to output the Matroska
format.

Could the same apply in this case?

> 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.

Could be the other way around as well... or is there any "higher"
standard that defines what a WebVTT packet is?

Personally, and as non-participant, the side data format looks a bit
awkward, while packets that are byte chunks make sense to me.

> 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.