[FFmpeg-devel] [PATCH] avformat/webvttdec: improve WebVTT parsing
Marcos Del Sol
marcos at orca.pet
Tue Jun 10 14:42:40 EEST 2025
> 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.
More information about the ffmpeg-devel
mailing list