Re: [FFmpeg-devel] [PATCH] avformat/webvttdec: improve WebVTT parsing

[Marcos Del Sol <marcos@orca.pet>]

> WebVTT is supposed to be an extensible format. Limiting to a small set of
> known values and silently aborting when anything new is introduced does
> not seem like the best option to me. Web browsers do not stop rendering
> pages when they see a new, unknown HTML tag or CSS option.

About this, for interoperability reasons I've checked other multiple
implementations of WebVTT parsers and these all follow the approach of
silently ignoring unknown chunks:

 - WebKit (https://github.com/WebKit/WebKit/blob/main/Source/WebCore/html/track/WebVTTParser.cpp#L224-L227)
 - Chromium's Blink parser (https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/core/html/track/vtt/vtt_parser.cc#199)
 - Mozilla's Gecko (https://searchfox.org/mozilla-central/source/dom/media/webvtt/vtt.sys.mjs#1674-1677)
 - VLC (https://code.videolan.org/videolan/vlc/-/blob/master/modules/codec/webvtt/webvtt.c)

The only one that would report an error, but will still keep parsing anyway,
is W3C's own WebVTT.js parser (https://github.com/w3c/webvtt.js/blob/main/parser.js#L150-L153).

If that's not enough, I found also in part 2.1 of the WebVTT specification,
also copied verbatim:

"The parsing rules are more tolerant to author errors than the syntax
allows, in order to provide for extensibility and to still render cues that
have some syntax errors."

Basically, the standard asks to follow Postel's law: "Be conservative in
what you send, be liberal in what you accept". ffmpeg should do that.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".