> 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-requ...@ffmpeg.org with subject "unsubscribe".
