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