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

[Nicolas George]

Le primidi 21 thermidor, an CCXXI, Clement Boesch a écrit :
> If you're suggesting to use the WebM representation as the standard, we
> have to deal with:
> 
>  - retro compat: changing the format of the packets for WebVTT format
>    create version clashes between lavc & lavf (+ deprecation of the side
>    data types)

That is always a burden, but I do not think it should come in the way of
deciding a better design: if the design is bad, it will need to be changed
sooner or later, and it is less work if it is done sooner.

In that particular case, I suspect we could just change the format of the
packets and get away with it, although some additional safeguards would
probably be better.

>  - move the complexity into lavf for webvtt muxing and demuxing

I suppose you mean "into lavc"? Otherwise I do not understand your sentence.
Then, yes: better the complexity once in lavc than twice in lavf!

>  - create more hacks if webvtt is muxed differently in another format

We will deal with it if it ever happens. Hopefully, people who decide on a
format will chose to adhere to the choices made for WebM, for
compatibility's sake.

>    (will you oppose to a sane muxing of webvtt in NUT?)

You imply that WebM's format is insane. I do not agree at all. It is not
perfect¹, but it rather good.

(1: it would have been better with 0 as a separator instead of LF and tags
in front of each fields.)

> OTOH, adding a special case only in WebM demuxer where a bad muxing
> decision was made doesn't look broken. That way of muxing into WebM is
> merely the result of two successive bad decisions, it doesn't look correct
> to rely on its layout

The broken thing is the heavy use of side data. Side data is a hack to code
whatever information is present somewhere but does not fit the common data
structure. How do you mux side data into NUT? Into MP4? Into elementary
streams? Answer: you do not, it does not exist. Side data exist because one
particular codec or container has a very specific feature to store one field
that does not exist elsewhere and it was not deemed important enough to
warrant a new field in AVPacket or AVFrame.

It does not apply there.

> (and relying on the original WebVTT layout with timestamps will lead to
> the ASS insanity you know: writing timestamps into demuxer etc).

No one is suggesting that, naturally.

> Also note that the hack I wanted to remove with ASS/SSA was the insane
> string *constructions* of SSA packets within the matroska demuxer, which
> is not the case here: the text is extracted, and extra data put into side
> data.

Granted, that was not exactly what I was referring to.

> Now if you insist on comparing with ASS/SSA, it might be a better solution
> for that case to abstract the differences between ASS and SSA into side
> data (like the ReadOrder),

That is exactly what I was referring to: ASS-in-Matroska and WebVTT-in-WebM
share the exact same structure: technical_field, delimiter,
technical-field... delimiter, actual_text.

And NO! it is not the demuxer's job to split the fields in the packet; a
packet is a blob of arbitrary data, it should be totally opaque to the
demuxer.

The job of splitting the fields in the packet is for the decoder. And the
result should go, in the end, in specific fields in the new AVSubtitle2
structure, not in the magical bag of holding called side data.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130810/3d4f12a5/attachment.asc>