[lxgr]

Yet I still only got hardware support for it on my first devices last year. The downside of "rapid" iteration on video codecs is that content needs to always be stored in multiple formats (or alternatively battery life on the client suffers from software playback, which is the route e.g. Youtube seems to be preferring).

[amiga386]

Hopefully that improves. The guy giving the presentation on AV2 made clear there was "rigorous scrutiny for hardware decoding complexity", and they were advised by Realtek and AMD on this.

So it seems like they checked that all their ideas could be implemented efficiently in hardware as they went along, with advice from real hardware producers.

Hopefully AV2-capable hardware will appear much quicker than AV1-capable hardware did.

[lxgr]

Oh, I don't doubt that it'll be hardware implementable, but it's a shame that current hardware is usually mostly out of luck with new codecs. (Sometimes parts can be reused in more programmable/compartmentalized decoding pipelines, but I haven't seen that often.)

[quaintdev]

That's reason I prefer firesticks over TVs

[RicoElectrico]

Maybe not only reference software, but also reference RTL should be provided? Yes, this is more work, but should speed up adoption immensely.

[IshKebab]

There's no point having reference RTL. The point of reference software is to demonstrate the correct behaviour for people implementing production grade libraries and RTL. Having an RTL version of that wouldn't add anything - it should have identical behaviour.

Providing a production grade verified RTL implementation would obviously be useful but also entire companies exist to do that and they charge a lot of money for it.

[Neywiny]

Could help people on the hobby or lower budget FPGA side. H.264/5/etc never really made it

[tverbeure]

There is absolutely no way an FPGA would make sense. The requirements for AV1 and H265 far exceed the hardware resources of lower budget FPGAs. For the same process, FPGA logic density is about 40x lower than ASIC, and lower budget FPGAs use older processes.

A h265 or AV1 decoder requires millions of logic gates (and DRAM memory bandwidth.) Only high-end FPGAs provide that.

[Neywiny]

There's mention that the decode could get a lot easier. Here's an H264 core that runs on older lattice chips and only takes 56k luts. https://www.latticesemi.com/products/designsoftwareandip/int... . Microchip's polarfires have a soft H.264 core as well taking under 20k. If AV2 will really be easier for hardware to implement, it might work out. Here's another example, H 264 decode in an artix 7, can do 1080p60 https://www.cast-inc.com/compression/avc-hevc-video-compress... . So with all due respect, what in the world are you talking about?

[sagarm]

Can a "lower budget" FPGA really outperform a consumer-grade CPU for this?

And what hobbyist is sending off decoding chips to be fabbed? If this exists, it sounds interesting if incredibly impractical.

[tverbeure]

It’s not possible on any but the largest $$$ FPGAs… and even then we often need to partition over multiple FPGAs to make it fit. And it will only run at a fraction of the target clock speed.

[pdimitar]

I have to wonder whether PCIe devices that do hardware encoding / decoding might be the more viable path going forward?

Wait, I just discovered GPUs, nevermind. [giggles]

Still, the ability to do specialized work should probably be offloaded to specialized but pluggable hardware. I wonder what the economics of this would be...

[mckirk]

It'd be really cool if we had 'upgradable codec FPGAs' in our machines that you could just use flash to the newest codec... but that'd probably be noticeably more expensive, and also not really in the interest of the manufacturers, who want to have reasons to sell new chips.

[daeken]

Back in ~2004, I worked on a project to define a codec virtual machine, with the goal of each file being able to reference the standard it was encoded against, along with a link to a reference decoder built for that VM. My thought was that you could compile that codec for the system you were running on and decode in software, or if a sufficient DSP or FPGA was available, target that.

While it worked, I don't think it ever left my machine. Never moved past software decoding -- I was a broke teen with no access to non-standard hardware. But the idea has stuck with me and feels more relevant than ever, with the proliferation of codecs we're seeing now.

It has the Sufficiently Smart Compiler problem baked in, but I tried to define things to be SIMD-native from the start (which could be split however it needed to be for the hardware) and I suspect it could work. Somehow.

[axiolite]

> FPGAs' in our machines that you could just use flash to the newest codec

They're called GPUs... They're ASICs rather than FPGAs, but it's easy to update the driver software to handle new video codecs. The difficulty is motivating GPU manufacturers to do so... They'd rather sell you a new one with newer codec support as a feature.

[toast0]

A lot of the GPUs have fixed function hardware to accelerate parts of encode/decode. If the new codec is compatible, sure.

But often a new codec requires decoders to know how to work with new things that the fixed function hardware likely can't do.

Encoding might actually be different. If your encoder hardware can only do fixed block sizes, and can only detect some types of motion, a driver change might be able to package it up as the new codec. Probably not a lot of benefit, other than ticking a box... but might be useful sometimes. Especially if you say offload motion detection, but the new codec needs different arithmetic encoding, you'd need to use cpu (or general purpose gpu) to do the arithmetic encoding and presumably get a size saving over the old codec.

[lxgr]

They’re programmable parallel compute units, and as such pretty much the conceptual opposite of ASICs.

The main point of having ASICs for video codecs these days is efficiency, not being able to real-time decode a stream at all (as even many embedded CPUs can do that at this point).

[astrange]

GPU video decoding doesn't use the graphics cores. It just happens to be on the GPU and is not upgradeable.

[ZeroGravitas]

The main delay the last time was corporations being dicks about IP but the two main culprits have got on board this time.

[bapak]

Unless they create a codec that GPUs are naturally good at, we will inevitably always be a couple of hardware cycles behind.

[astrange]

You can't do this because GPUs are parallel and decompression cannot be parallel. If there's any parallelism it means it's not compressed as much as it could be.