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

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

Tomas Härdin:
> tis 2025-06-10 klockan 11:42 +0000 skrev Marcos Del Sol:
> > WebVTT is supposed to be an extensible format.
>
> The syntax says otherwise. Why the W3C feels the need to specify a
> particular imperative algorithm for parsing I cannot know, but this is
> not how RFCs are authored. It also makes implementing WebVTT in
> functional languages impossible. It is a shotgun parser to boot.

What do you mean that's not how RFCs are authored? Go read RFC2083
from 1997 where it has literal C code in it. You should consider writing
an irate email to the IETF and tell them that has to go. This TLV-based
standard, by the way, also asks you to ignore unknown tags.

> > 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.
>
> No, it should not. That is a bourgeois attitude to parsing. If the W3C
> needs extensibility then it should amend the syntax to make that
> possible. Or they should just have used XML I guess, but here we are.

If they had used XML you would be here complaining that we should crash
on unknown tags that don't appear in the XML DOCTYPE, so that'd change
nothing.

Would you say that'd be the correct approach on unknown Matroska EBML
tags, which the standard (RFC9559) also tells you to accept and ignore?

If you wanna go proprietary, let's read what QuickTime says about
unknown atoms:

"If your application encounters an atom of an unknown type, it should
not attempt to interpret the atom’s data. Use the atom’s size field to
skip this atom and all of its contents. This allows a degree of forward
compatibility with extensions to the QuickTime file format."

I haven't checked any others, but I am fairly sure no tag-based file
format standard would say "be as strict as possible, treat any
recoverable parsing errors as fatal and do not notify the user".

> A liberal attitude towards parsing begets liberal attitudes elsewhere,
> for example in the very sample you linked. Rather than this broadcaster
> fixing their workflow, are we to be saddled with the maintenance burden
> of their broken files for free, in perpetuity? To give our labour away
> gratis? Of course not.

Isn't this what you're exactly advocating for though? Spent time and
effort perpetually updating the list of known tags just to ultimately
ignore them?

PS: Remember to send the emails to the list, not to me alone.
_______________________________________________
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".