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

[Matthew Heaney]

On Wed, Jul 31, 2013 at 7:47 PM, Clément Bœsch <ubitux at gmail.com> wrote:

>
>   - in WebVTT a cue looks like this:
> [<chapter>\n]<timestamp>[<settings>]\n<text>\n\n
>   - in WebM   a cue looks like this: <chapter>\n<settings>\n<text>


> Please correct me if that's incorrect.
>

Of WebM I would say instead:

- in WebM   a cue looks like this: [<chapter>]\n[<settings>]\n<text>


>
> Now the problem in my opinion is that WebM uses a full textual way of
> muxing the 3 informations: requiring some strchr or similar in a binary
> parser is a bit insane (and dangerous? what about a non null terminated
> payload?).


No worries, that issue was addressed in my last patch.  (In WebM, all such
payloads are non-null terminated.  This is not a problem.)



> TL;DR: the <chapter>, <settings> and <text> are so weirdla (badly?) muxed
> in *both* WebVTT format and WebM that it, in my opinion, makes sense to
> separate them at AVPacket level like it is now (payload for <text> and
> side data for the two other extra info), and let every muxer sanely mux it
> using the API interface.
>

Right -- that's how it is now.

I was hoping that we could commit this patch and then make any additional
changes (which are strictly an internal ffmpeg-design matter) as part of a
separate patch set.  The webvtt changes to ffmpeg that are already present
(along with the current patch) do what we need for adding inband text track
support to Chrome, which solves our immediate problem.

-Matt