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

[Clément Bœsch]

On Fri, Jul 19, 2013 at 08:01:26PM +0200, Nicolas George wrote:
> Le primidi 1er thermidor, an CCXXI, wm4 a écrit :
> > 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.
> 
> That is the plan. The packet format for the SSA codec id was a quick hack to
> get the interface with libass working, but it was very badly designed from
> an API point of view.
> 
> The plan is to deprecate the SSA codec id in favour of ASS, both for the
> Matroska muxer and demuxer (done), the .ass text file muxer (done) and the
> .ass text file demuxer (not yet done, should be easy).
> 

Actually, I'm not so sure about having SSA deprecated (aside from mkv
format), but that can be discussed (in another thread please).

Anyway, about the whole current thread, I'm sorry I didn't have time to
read every single post, but I'd like to have a few words before random
development is done, like changing the current (de)muxing of WebVTT.

Summary of the current situation: WebVTT "codec" is defined by a payload
(the text with its markup) and two extra information. WebVTT and WebM
formats mux them differently:

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

Note how the chaptering and its \n are optional in WebVTT for instance,
and how the settings are strangely placed along the timing information.

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?). IMO it would have been much more wise to mux it with \0
separators, but whatever. The point is, if someone decides to mux WebVTT
in another format, he might come with a different way and more relevant
way of muxing it.

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.

Note: sorry for not being active recently, I'm back from holidays pretty
soon.

Regards,

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130801/5147d473/attachment.asc>