Comment by F3nd0 | Hacker News Reader

Comment by F3nd0 | Hacker News Reader

It seems to me that AV1 (the codec used in AVIF) has seen a lot more development in recent years, by virtue of being widely adopted for video. JPEG XL has not seen comparably massive adoption, perhaps owing in large part to Chrome rejecting it on dubious grounds (in spite of eagerly forcing the adoption of both WebP and AVIF earlier on). The pace of the reference implementation’s development has grown very slow, and most of the modest attention it’s been getting seems to have recently moved to the new Rust decoder, once the browsers finally made up their mind that’s what they wanted from the devs.

That considered, I don’t think it’s a fair comparison between the codecs. JPEG XL used to be far more impressive than AVIF; it’s great people (author included) have managed to push AVIF forward, but until similar efforts have been made for JPEG XL in earnest, I don’t feel like a comparison between their encoders says much about the codecs themselves. The author does take a guess on how much the JXL encoder could be improved, but that’s just that: a guess. It won’t be know until it’s been tried. And especially given the whole unfortunate history, I think JPEG XL really, really deserves a try.

It is getting its try, actively, in libjxl. People like to pretend AV1 got infinite resources; the reality is myself and one other contributor produced the vast majority of the image gains. I built Iris-WebP and aperture-alpha myself, from scratch. As a compression engineer, I think JXL is way, way harder to work with, and it would've taken me a lot longer. libjxl has community contributors, it is just an uphill battle with a codec like that. Same as WebP is an uphill battle due to its format restrictions.

> It is getting its try, actively, in libjxl.

That’s the thing, though: libjxl development hasn’t seemed all that active in recent years. The community contributors you mention seem quite far from driving the development, and some of them say that the usual devs have been busy with other projects (including jxl-rs as of recently).

> People like to pretend AV1 got infinite resources

I would not suggest that, but in another comment here you yourself say that SVT-AV1 (which you compare to JXL favourably in your article) has seen active involvement from ‘Meta, Netflix, Intel, independent contractors, and others’ – not to the community fork SVT-AV1-PSY and its successors contributing their improvements back upstream.

I can believe that JXL may very well be more difficult to work with, but am I wrong to assume you’ve been able to continuously focus on your own encoder (and apply your experiences from your earlier work on SVT-AV1)?

I think libjxl's development is stalled because the format is hard to work with. It wasn't super hard to drive meaningful improvements to AVIF.

Yes, SVT-AV1 received and continues to receive development efforts from devs at big companies, but the number of core contributors has always been somewhat small. Definitely more resources, but the entirety of the original AVIF work was done by two people.

I'm able to utilize my experiences generally in image coding to work on my encoders. This should translate to JPEG XL, but I feel held back by how algorithmically complex compelling implementations of the coding tools would be, and how to make those implementations fast. I think if the JPEG XL spec was incredibly intuitive, community contributions would have gotten it a lot further. Heck, my own efforts may have gone to it instead of SVT-AV1-PSY's AVIF encoding.

Yes, but for speed which means a lot of SIMD plumbing, the larger workforce certainly benefited AV1 codecs!

Wasn't that also basically one guy from the VLC/ffmpeg community that drove that effort? I think they got funding from Netflix to do it again on ARM after demonstrating the benefits on desktop.

For decoding, yes, dav1d. But for encoding, a lot more SIMD kernels in libaom/SVT-AV1 written by other people.

(And lots of kernel shared between decoding and encoding, of course)

> It won’t be know until it’s been tried

We can reevaluate when and if improvements are made. The problem with statements like this, is its really easy to miss the showstoppers when imagining what something could be. All plans are amazing until you have to actually do them in the real world.

As the saying goes: Never fall in love with potential.

"We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".

You'd rip a new one to Google if there would be a CVE in a new C++ library in Chrome because of it.

Now that Rust library is available, they will continue adoption, as it should be.

> "We don't want to support another pile of security bug ridden C++ library" absolutely aren't "dubious grounds".

It is when that didn't stop them YOLO'ing in webp and then avif support.

If you have two toilets in your house, are you going to sign up to clean mine too, for free, because I demanded it from you?

Thought so.

The stated reason for Chrome was not ‘we need a memory-safe implementation’. It was ‘there is not enough interest’ and ‘there is not enough improvement over AVIF’. At the time, there was interest and there was improvement over AVIF (which Google has decided to support regardless of memory safety, interest, or seemingly any deeper consideration).

Memory safety as a condition for adoption was brought up only years later, and by Mozilla rather than Google. The JPEG XL devs, who’d offered to work on it if there was interest, got to work as soon as interest was proclaimed. You might say it’s a good thing for Chrome to have held off adoption until then, but that’s completely incidental, not because they cared. Near-zero efforts to be fair and responsible were made.

Reply on news.ycombinator.com