undefined

points

[-]

The container is useless. Files based on a newer codec won't display anyway.

ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.

AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)

I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.

by theandrewbailey6 hours ago|

prev|

[-]

> I think one overlooked aspect is that AVIF is container based.

Many other image formats are. AVIF uses HEIC, the same container that HEIF does.

> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.

Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.

https://github.com/AOMediaCodec/av2-isobmff

by jaffathecake6 hours ago|

prev|

[-]

This doesn't make sense to me. There's enough content negotiation out there that AV2 will need a new content-type parameter. Feature detection is important to browsers.

by shmerl5 hours ago|

parent|

[-]

I don't think so. WebM doesn't need new content type and it can ship AV1 and VP9 all the same.

by jaffathecake5 hours ago|

parent|

[-]

What are you talking about? Video formats have a whole mad type parameter for this stuff https://jakearchibald.com/2022/html-codecs-parameter-for-av1...

by shmerl2 hours ago|

parent|

[-]

It's not mandatory, and it would work without using it. The whole point is for forward compatibility support effect for sites which are very slow introducing these kind of changes.

by jaffathecake2 hours ago|

parent|

[-]

It's not mandatory. But if you don't use it, the browser may select a source it cannot play.

by shmerl2 hours ago|

parent|

[-]

Possibly, but as above, a much slower problem to solve is not in the browser support, but in sites support. Browsers in practice move way faster.

by arendtio6 hours ago|

prev|

[-]

Can someone please explain the downvotes?

by pwg6 hours ago|

parent|

[-]

My guess: because the OP forgot that to decode AV2/AV3 it matters not that it is in an AVIF container, it matters that the display system (browser, etc.) actually have the codec available to it that can decode the new format (AV2/AV3/etc.).

With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.

by shmerl5 hours ago|

parent|

[-]

You didn't get the point of the post. I explained why and how container matters here. Not a specific container, but just the idea of container itself. Hint, it's not the browser.

by ksec2 hours ago|

parent|

[-]

I don't get it. And to me it wasn't clear in the post. As others have explained the container and codec are two separate issues.

by shmerl2 hours ago|

parent|

[-]

Concrete example. Let's say GitHub will add AVIF support at some point (it's not yet handled well by the site as you can notice[1].

You as user can then upload AVIF images to wherever images on the site are processed. And after that, let's say when newer codec inside AVIF will get a good browser coverage, you'll be able to start using it without waiting another decade for GitHub to pipe it through their site code.

For formats without a container, it's always a two step process. Browser coverage first, then another huge period of sites support catching up.

[1]: https://github.com/orgs/community/discussions/138164