The specification for AV2 has only been finalised very recently, so performant encoders have not yet been developed. Meaningful comparison to older codecs like H265 and AV1 will only be possible once that has changed. (It'll be slower, but almost certainly not one-frame-per-second slow.)
dav1d is the av1 decoder and it’s an insane feat of engineering. Written in assembly, it even eschews the normal c calling convention to get even better performance.
The normal C calling convention is really only for cross-binary calls (e.g. between shared libraries). If you're not doing that you can ignore it; it's not a weird thing to do. It would be odd to strictly follow it in assembly and I assume compilers don't either.
Yes, much higher computation required to encode it, and decode it, both.
He only mentioned decode complexity. Would be interesting to know the average encode complexity compared to AV1.
Encoding speed even on Mac Studio is atrocious, it’s in range of single frames per second as opposed to realtime+ for even h265
The specification for AV2 has only been finalised very recently, so performant encoders have not yet been developed. Meaningful comparison to older codecs like H265 and AV1 will only be possible once that has changed. (It'll be slower, but almost certainly not one-frame-per-second slow.)
dav1d is the av1 decoder and it’s an insane feat of engineering. Written in assembly, it even eschews the normal c calling convention to get even better performance.
The normal C calling convention is really only for cross-binary calls (e.g. between shared libraries). If you're not doing that you can ignore it; it's not a weird thing to do. It would be odd to strictly follow it in assembly and I assume compilers don't either.
Yes