It isn’t required for content distribution platforms which aren’t realtime and the cost of encode is easily made up by hundreds of thousands of streams.

You need hardware encoders for things like cameras because they need to encode in real time since the buffer would quickly overflow otherwise.

They can't adopt it if it doesn't exist.

And HW acceleration is generally a preset baked in version of the encoder or decoder. These are mostly codec specific.

So, no using hardware from previous versions.

Now, you can see some software that tries to use the GPU itself, instead of the dedicated hardware acceleration, to decode, but that isn't the HW accelerated, and may not operate in real time.

At the same time, that will consume much more power, eliminating some of the advantages or the pure HW rendition, especially important for mobile.

I could see an argument being made for encoding, if it is 2x or faster than the CPU, but I haven't looked at any in a while, so don't know the speeds.

This is what makes it viable on mobile devices where system responsiveness and power efficiency are high priority.

Generally these hardware decoders haven’t been retoolalble.

https://www.youtube.com/watch?v=Se8E_SUlU3w&t=1480

e.g. if you check in 4 directions to see if you can reuse a chunk then make it check in 8 or 16.

Faster encoders will have smart heuristics on when to use these new abilities and when to skip them but the reference encoder will try everything in a dumb way to eke out a tiny win to maximize a theoretical advantage and map out the extreme best case.

JPEG XL would like a word.

Which kind of encode settings do you suggest for conversion from high resolution RAWs or JPEGs ?

1. Lossless AVIF is a joke often beaten by WebP and even PNG. Even worse for grayscale.

2. Chroma subsampling remains a bad idea for still images unless the resolution is high enough to hide the artifacts.

3. Tooling is the worst part, AV1 encoders are basically focused 99% on video and leave a measly 1% to image; unlike JXL, of course. SVT-AV1 still doesn't do YUV444 and libaom was unusable. Fortunately, the unpaid enthusiasts were here: https://giannirosato.com/blog/post/the-multimedia-renaissanc... (and more recently https://giannirosato.com/blog/post/oavif/)

I don't see AVIF being used for lossless, which is the largest reason I'd prefer JXL to win: one codec to rule them all sure is an alluring future.

JPEG is woefully outdated with the lack of HDR and modern compression, HEIF can’t be used without paying a license, webp was designed just for extremely efficient small images rather than local storage, avif I’ve never seen used ever, and JPEG XL is on track to be the next major format.

I agree we don’t need an avif2, but until jpeg xl there really weren’t any decent alternatives for jpeg.

This might just mean that if the claim is found valid, there's seven years' worth of inertia slowing down any effort to move on. Seven years in which HW and SW manufacturers worked to build in the support, and you the user developed your processes or workflows around assumptions specifically tied to that solution. I'd rather know on day one if I should go that way or not.

[1] https://www.phoronix.com/news/dav1d-0.5 (it's mislabled as a core i3, but the 3770K is a core i7).

For encoding, you can always write a simple encoder that use only the features that were present in mpeg2, and it will be about as efficient as mpeg2 as well. Newer codecs has more features that allows more efficient encoding, at the cost of more processing.