AV1 Still Picture Encoding Merged For Mesa 24.3 Radeon Driver

[phoronix]

Phoronix: AV1 Still Picture Encoding Merged For Mesa 24.3 Radeon Driver

David Rosca working for AMD has continued to improve their open-source video acceleration support within Mesa. Merged today for Mesa 24.3 is the code within the Gallium3D video acceleration front-end and the RadeonSI Gallium3D driver for handling AV1 still picture encode...

https://www.phoronix.com/news/RadeonSI-AV1-Still-Picture-AVIF

[Adarion]

This is nice, however, I wonder how and if that will come out in reality. First off, only few ASICs support AV1 (de)/encode. Only very recent chips do so, UVD is decode only, VCE iirc. hardly supported AV1 and some VCNs should be able to. But that aside, how will software make use of it? I doubt that any of the programs like e.g. GIMP or something, will actually make use of hardware accelerated image compression for AVIF, the nasty webp or for JPEG (there should be ASICs, too). For some reason userspace software seems very slow to pick up these things, or actively use it via some sort of ffmpeg utilization. (Of course, it might be, that most HW accelerated stuff is simply less flexible and only offers like one sort of profile for compression.) But either I am too dumb and missed it, or most programs do not even have an option to use ASIC-hardware for anything related to compression, so one always goes via CPU.
(Same is for all that dysfunctional OpenCL stuff, there would be use cases but I never noticed anything working there.)

(And having some super-recent GPU-part often implies also having already strong CPUs, and lots of money spent. HW acceleration however, would be especially useful for smaller/older setups and laptop APUs to speed up things and conserve electric energy.)

[Quackdoc]

This is nice, however, I wonder how and if that will come out in reality. First off, only few ASICs support AV1 (de)/encode. Only very recent chips do so, UVD is decode only, VCE iirc. hardly supported AV1 and some VCNs should be able to. But that aside, how will software make use of it? I doubt that any of the programs like e.g. GIMP or something, will actually make use of hardware accelerated image compression for AVIF, the nasty webp or for JPEG (there should be ASICs, too). For some reason userspace software seems very slow to pick up these things, or actively use it via some sort of ffmpeg utilization. (Of course, it might be, that most HW accelerated stuff is simply less flexible and only offers like one sort of profile for compression.) But either I am too dumb and missed it, or most programs do not even have an option to use ASIC-hardware for anything related to compression, so one always goes via CPU.
(Same is for all that dysfunctional OpenCL stuff, there would be use cases but I never noticed anything working there.)

(And having some super-recent GPU-part often implies also having already strong CPUs, and lots of money spent. HW acceleration however, would be especially useful for smaller/older setups and laptop APUs to speed up things and conserve electric energy.)

I could see this being useful for allintra, not that allintra is super useful with av1 right now.

Could be useful for android maybe.

[geerge]

Avif is kinda crappy, it has a use potentially in phones that can re-use hardware av1 support I guess, but really jpeg-xl is the way to go in general.

[Gamer1227]

Avif is kinda crappy, it has a use potentially in phones that can re-use hardware av1 support I guess, but really jpeg-xl is the way to go in general.

Sadly Chrome refused to adopt jpeg-xl thefore it is dead. ;(

[Quackdoc]

Avif is kinda crappy, it has a use potentially in phones that can re-use hardware av1 support I guess, but really jpeg-xl is the way to go in general.

indeed. Sadly most applications on android don't support JXL. Fossify gallery now does, Aves doesn't accept PRs so I can't work on that, and I don't know of any other opensource gallery apps that aren't crap. nor of any gallery apps that otherwise ship JXL outside of fossify.

NDK doesn't support JXL, Coil and glide have plugins, so any applications that use either coil or glide should be able to support it easily. As for "NDK" Platform support needs to be added to both android's C libraries and Java ones (Though I think the C libraries are just glue to the existing java interface for images). If any AOSP dev wanted to look at that, it would be great. but as of now, I havent even seen a mention on any of the trackers I follow.

Sadly Chrome refused to adopt jpeg-xl thefore it is dead. ;(

I'm not sure if this is sarcasm or not, forgive me if it is, but I'll treat it as not. Thanks to apple shipping JXL support, Cloudinary has found that roughly 25% of their traffic supports JXL. Shopify CDN is serving JXL to any one who has JXL in their accept headers, and cloudinary is in an opt in basis. Even assuming just shopify, there is a large amount of web traffic that supports JXL.

Chrome is not enough to kill stuff now, Adoption is happening whether chrome likes it or not.

[ayumu]

Is JXL free of patent encumbering?

Is it actually better than AV1 at encoding static images?

[Quackdoc]

Is JXL free of patent encumbering?

Is it actually better than AV1 at encoding static images?

yes and yes. JXL patents are licensed under the same "defensive" patent scheme av1 is. IE. you are granted royalty free use under any circumstances, but if you try to claim royalties for JXL, your right to use said patents is revoked.

as for if it's better then Av1, far better. Even assuming you don't care about things like high bitdepth, progressive decoding etc. libjxl only gets beaten, in some specific cases by svt-av1-psy, which is a highly optimized visual fidelity fork of svtav1. but even then libjxl can often beat it interms of compression:quality, and pretty much always beats in in lossless encoding.

ofc a format is only as good as it's best encoder. nether AV1 nor JXL have encoders that really tap into their full potential. However AV1 has hard limitations that prevent things like super high resolution photos, greater then 12bit depths Proper progressive decoding (AVIF adopted a hack where you just encode an image sequence for progressive decoding lol). and many more features.

JXL on average is also far easier to decode for legacy hardware then avif is is in most cases. Which is actually really important as people still use old hardware to view images. and opening a gallery full of AVIF images can cripple old devices far easier then JXL can.

[NekoTrix]

The SVT-AV1-PSY project has closed the gap between JXL and AVIF, and there is still some untapped potential that's being actively looked into by the development team. Some of the ideas are being backported upstream to SVT-AV1 right now, heck even to the reference encoder aomenc. The fast decoding options on the AV1 side are numerous and underutilized, so that's not a serious issue in all honesty. JXL still has the lossless efficiency and JPEG recompression advantage, true, but I don't think it's fair to disregard AVIF when it already provides so many improvements over current standards.

[BlueSwordM]

The SVT-AV1-PSY project has closed the gap between JXL and AVIF, and there is still some untapped potential that's being actively looked into by the development team. Some of the ideas are being backported upstream to SVT-AV1 right now, heck even to the reference encoder aomenc. The fast decoding options on the AV1 side are numerous and underutilized, so that's not a serious issue in all honesty. JXL still has the lossless efficiency and JPEG recompression advantage, true, but I don't think it's fair to disregard AVIF when it already provides so many improvements over current standards.

To be fair, the same can be applied to libjxl.

All of the efforts we've put into svt-av1-psy will eventually find their way back to libjxl, like how many of the improvements in aom-av1-psy/svt-av1-psy came from JXL, x264, Vorbis and even Theora.