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

["Tomas Härdin" <git@haerdin.se>]

fre 2025-06-06 klockan 22:22 +0200 skrev Marcos Del Sol Vives:
> 
> 
> El 6 de junio de 2025 21:43:58 CEST, "Tomas Härdin" <git@haerdin.se>
> escribió:
> > 
> > Sounds like the demuxer correctly rejected some broken files
> > 
> 
> The WebVTT standard does not call for a fatal error unless the magic
> header does not match. The current implementation is not only non-
> compliant with the standard, but will also break on future changes.

The linked file does not follow the syntax specified in section 4 of
the WebVTT standard. Therefore it is not WebVTT.

The probe function should ensure that the file starts with the
necessary bytes. I see it can let some non-compliant files slip by,
since it does not check whether [BOM]WEBVTT is followed by a newline,
and possibly a space or tab and any non-newline characters. We could
fix that in the main parsing loop. We also shouldn't expect any
"WEBVTT" chunks after the first one.

webvttdec.c also allows REGION etc chunks outside of where section 4
says they are allowed. In my opinion this is bad, since it means the
demuxer allows more than just WebVTT.

I've been harping on the permissive attitude towards parsing on this
list for a while. The reason why I do this is because every time we're
lax with parsing, some user will come to rely on said laxness rather
than fixing their workflow. Therefore we're perpetually unable to fix
our demuxers. My opinion is that it is best to nip this permissiveness
in the bud. The fact that the demuxer does the wrong thing right now is
no excuse to make it behave even more incorrectly.

What I'd like to see is the project moving towards either parser
combinators or a domain specific language for grammars like a PEG
variant extended with length fields.

We can't do much about the W3C making breaking changes to their
standards in the future, other than updating our code when that
happens. We're lucky that the spec is quite narrow. The space for
making non-breaking changes to it is quite small. They could for
example reuse NOTE chunks for future functionality. For example, if W3C
wants to allow STYLE chunks in the middle of the file the current
syntax does not allow that. But they could amend it by using "NOTE
STYLE" for stylesheets between cues.

All this is just my views of course. Other devs might feel very
differently. I'd point out it's no longer the wild west of the early
2000's.

/Tomas
_______________________________________________
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".