Hacker News Reader

Comment by vkaku | Hacker News Reader

We all know these aren't purely technical reasons, it's to break the monopoly of one Internet Company's decoder format portfolio. You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.

View on HN

AVIF is royalty-free, with open-source implementations not developed by Google. Google's implementation is libaom; as you can see, SVT-AV1 beats it. SVT-AV1 is developed by a number of companies – historically Meta, Netflix, Intel, independent contractors, and others. I worked on SVT-AV1 myself. I don't see how this is a bad thing for everyone, even if Google drove standardization of AV1?

There were something like 40 companies involved in AV1 standardization. Quite a few technical contributions did not come from Google, and quite a few of Google's proposals were substantially modified by feedback from others before they were included (and not all of them were eventually included).

Source: I lead Mozilla's technical contributions to AV1.

It saddens me to see discourse on the internet about AV1's ancestry being focused on Google's VPx line of contributions, while diminishing those coming from Daala (entropy coder...) and Thor (QMs...), as well as inter-company collaborations (CDEF).

A redeeming outcome is that with AVIF's new image tuning modes (both in libaom and SVT-AV1), Gianni and I managed to utilize as many AV1 coding tools as possible, including QMs that sorely needed a well-deserved spotlight.

Also, thanks for paving the way to the current state of multimedia compression! I'm a longtime fan of Xiph(ophorus) since the 1.0 beta/RC Vorbis days. We used your image sets a lot during our testing.

You're welcome. That is what those image sets were for.

I was really happy Thomas Davies added quantization matrices to the spec, because if he hadn't, I would have had to. Fortunately, he did a good job. I am glad someone is finally using them. Don't sleep on per-segment quantizer deltas, either.

Hello derf.

I think you might like this: https://github.com/Uranite/svt-av1-tritium#from-svt-av1-hdr-...

Me and a bunch of friends (mainly Clybius and Yiss/Uranite), after I was constantly saying daala was a great low complexity visual metric that should be added back to AV1 encoders, we decided to implement it into yet another svt-av1 encoder fork: https://github.com/Uranite/svt-av1-tritium#from-svt-av1-hdr-...

It has been showing great performance overall and is quite nice. It can work on CDEF, like it did in aomenc-av1 back in 2018/early 2019. It does so very well.

We've also implemented deeper controls, but that is still experimental.

Thank you so much for your work on daala stuff, as it's been one of my many inspirations in the field.

> You can't let one Fruit Company's format be the thing either, so it's basically a L for engineering but a W for pleasing everyone TBF.

What exactly is "Fruit Company's format"?

I'm guessing HEIC.

HEIF isn't an Apple owned format, most modern cameras have it as an option alongside JPEG now. The situation is JPEG is woefully outdated, lacking in HDR support and dated compression. HEIF is technically much better but patent encumbered.

JPEG-XL offers all the benefits of HEIF and more, while not being patent encumbered.

> HEIF isn't an Apple owned format […]

I'm also thinking the OP meant HEIC, but I know that it is not proprietary (though as noted patented), and wanted to make sure, as a lot of people of all sorts of assumptions/misconceptions about Apple.

HEIF/HEIC is based on H.265, so not Apple-only as Android supports it. (Recent Sony, Canon, Nikon, etc cameras all support the format as well.)

They support different variants of the format, though.

https://www.dpreview.com/articles/8980170510/how-hdr-tvs-cou...

> HEIF/HEIC is a broad standard, and the files from Canon and Apple are not cross-compatible with one another

Reply on news.ycombinator.com