> How much silicon does it take to add an AV1 decoder to a chip?
The die area is very modest, but the hard part is building it in the first place.
Encoding is more area, but should still be peanuts for Apple SoCs.
The die area is very modest, but the hard part is building it in the first place.
Encoding is more area, but should still be peanuts for Apple SoCs.
There are also likely opportunities for additional efficiencies when you make a custom {en,de}coder for your system. I suspect (but haven't confirmed) that the typical Intel/AMD/Nvidia/Apple multi-function media engine isn't just a collection of completely independent encoder/decoder blocks for each codec but a kind of simplified specialized microcoded CPU with a collection of fixed-function blocks which can be shared between different codecs. So it could have blocks that do RGB->YUV conversion, Discrete Cosine Transforms, etc. and you can use the same DCT block for AV1, HEVC, and AVC. Maybe you can also create specialized efficient ways to transfer frames back and forth with the GPU, for sharing cache with the GPU, etc.
I believe the team we worked with at Arm during AV1 standardization is no longer there, which is too bad. They were really great guys to work with.
Your suspicion is mostly correct, though obviously you cannot share too much of the DCTs as these must be bit-exact and are different for each of the standards. But especially things like the compressed tile cache for reference frames used in motion compensation are extremely complicated (to save memory bandwidth and power) and entirely shareable. The SRAM used for line buffers is also a lot of area and shareable. And so on.