No, to záleží. Někdy bývá formát definován tak, že existuje jakási šedá zóna, co by konzument měl nějak zpracovat, ale producent by to podle specifikace dělat neměl. Důvodem může být třeba kompatibilita s další verzí.
Například některé volitelné sekce budou podle specifikace první verze rezervovány pro budoucí použití. Dekodér je bude muset podle specifikace ignorovat (protože je nezná), ale to neznamená, že enkodér tam může dát cokoli. Když tam hodí něco neuváženého, může to způsobit problémy s dekodérem novější verze.
Někdy ty šedé zóny mohou být celkem intuitivní, někdy nemusejí.
Pár příkladů, co mě z hlavy napadají:
U formátů mě napadá třeba HTML5, kde – co si vzpomínám – je definováno, jak se má parser stavět k nevalidním dokumentům.
U x509 certifikátů je prostor pro nějaké extensions. Čistě podle logiky „výstup uděláme tak, aby ho současný standard-compliant parser zpracoval“, by bylo OK vymyslet si vlastní extension, a označit ho jako non-critical (pak musí být podle standardu ignorován, pokud ho aplikace nezná). Jenže jeho identifikátor může kolidovat se standardizovaným extension, který vznikne časem, a najednou podle nového standardu má takový certifikát být odmítnut, protože obsahuje nějaké blbosti.
Pokud netrváme jen na formátech, ale mohu uvést i příklad u protokolů, pak mě napadají různé reserved ranges u IP adres. Tyto rozsahy nemají být přidělovány. Nevím o tom, že by standard zakazoval těmto IP adresám odpovídat nebo na ně posílat jiné pakety, ostatně by to jen omezovalo interoperabilitu mezi starším a případným novějším standardem. Pak ale z toho, jak mám na co reagovat, nemusí být ani zřejmé, že některé IP adresy nemám přidělovat.
Nevím, jestli u tohoto standardu je reálné riziko šedé zóny, která by nebyla zřejmá. Vím ale, že je to někdy problematické.
Download samozřejmě je:
https://aomedia.googlesource.com/aom/+/master
Těžko by asi VLC a GStreamer měli podporu kodeku, pro který není implementace!
Klasicka jezkovina, je to zatim jenom draft a jeste se neco ladi. Sice byla zverejnena specifikace 1.0, ale neni to natuty finalni (freeze).
https://aomediacodec.github.io/av1-spec/av1-spec.pdf
Mozna je Jezek barvoslepej, ale spis to vubec necet a jen si nekde na jinym webu precet titulku a do sve zpravicky doplnil 2 odkazy.
Tak pár citací:
"Today, the Alliance is proud to announce the public release of the AOMedia Video Codec 1.0 (AV1) specification"
"Designed at the outset for hardware optimization, the AV1 specification, reference code, and bindings are available for tool makers and developers to download here to begin designing AVI into products."
"Please note that the document will remain marked as “draft” until all final comments are closed out. AOMedia is respectful of the open source process, and the contributions from the broader development community. As final comments are addressed, the document will auto generate with the latest version, and then the watermark will be removed."
To prohlaseni nedava moc smysl. Pokud se releasne nejakej SW, tak se neceka ze by ve verzi 1.0 jeste nekdo po releasu delal naky opravy. Ty se vetsinou vydavaji jako opravny releasy (treba 1.0.1).
Pokud to bylo mysleno tak, ze ten draft nebyl verejny a byl teprve ted byl zverejnen, tak to zas moc nejde dohromady s tim "open source process". Ale hlavne to znamena, ze ta specifikace porad neni finalni, jak naznacuje clanek...
Máte nějaký zdroj, na tyhle čísla? 40% lepší kompresi než HEVC má asi sotva, jedině snad u 8K videa a to se, mírně řečeno, zatím zas tak moc nepoužívá. U HD až 4K bude o něco lepší, než HEVC, ale určitě ne o 40%. A těch 10000? To jste někde četl, že na kódování/dekódování AV1 je potřeba superkalkulátor o tisících CPU, jinak dekódovat dvouhodinový film trvá víc, než rok?