3 ms·

I would hope so! Otherwise the Pareto front wouldn't have moved in ~20 years which would be rather hard to believe. However, at the same time, h265, h266 and A

by jchw 3mo ago

I would hope so! Otherwise the Pareto front wouldn't have moved in ~20 years which would be rather hard to believe. However, at the same time, h265, h266 and AV1 are all vastly more complicated, and will have less broad hardware acceleration support than h264, which, again, even if it is not optimally efficient use of compute, just doesn't require a whole lot by modern standards. So I'd argue there is really no reason to be rushing away from h264 unless you have a compelling reason. There are some obvious compelling reasons in some cases; nobody is going to be terribly surprised that an entity like Netflix is eager to switch to codecs that will save bandwidth, because at their scale saving bytes definitely adds up, bonus points if it can increase the quality at the same time. On the other hand, though, unless you are absolutely sure you can switch to only new codecs, you will probably want to keep some h264 encodings around to act as a fallback baseline for legacy devices. And thus, you also have to take into account the complexity brought on by needing to store and maintain multiple encodings - in many use cases, like simple <video>s thrown into website backgrounds, I can see just eating the extra bandwidth costs and keeping it all h264 as a valid strategy.

Dylan16807 3mo ago
Well a lot of the improvements cost more computation. I wouldn't be surprised if low-computation video had only improved slightly, but it seems like it has improved a lot. The advantage of h264 is hardware adoption much more than actually being computationally cheap, it seems? Well, maybe. The thing is, I don't know how the decoders scale. Can you make a decoder for a constrained AV1/h.265 in the same hardware space or maximum CPU budget as an h.264 decoder and still see very big advantages?
duskwuff 3mo ago
Once the patents expire, I expect to see H.264 become the JPEG of video codecs - it may not be the most efficient format available, but it's widely supported, relatively easy to encode/decode, and good enough quality for many use cases. (MP3 is in a similar place. AAC and Opus are technically superior, but everything supports MP3.)
- ksec 3mo ago
  >(MP3 is in a similar place. AAC and Opus are technically superior, but everything supports MP3.) Actually MP3 is more like the H.263 / Divx here. AAC-LC is more like H.264. The difference in support of AAC-LC and MP3 is near zero, both in terms of hardware and software. While AAC-LC is vastly more superior. AAC-LC has been declared patent free ( all patent expired ) by Redhat for 9 years already. The only part that is not perfect is there isn't a decent open source AAC-LC encoder. While you could use QAAC using Apple's encoder in iTunes. It would still have been better if there was an open source version. Luckily we just have a new AAC encoder with FFmpeg, it is doing great for and although sill not Apple's quality. But hopefully improve in the future. Or Apple could have just open source the god damn thing.
  - jchw 3mo ago
    I was under the impression that the new FFmpeg nmr codec indeed outperforms the Apple one in every bitrate with Google's new Zimtohrli benchmark as well as ViSQOL. That would suggest Apple doesn't really have to open source anything, we should be good? Still, I don't see the point. Unlike video, audio decoding is so cheap you can practically do it on software even on fairly constrained devices. So really only in places like Bluetooth headphones where codec complexity can have a direct impact on battery life does it actually factor in. I say for most purposes people should just be going Opus today: it is far ahead of basically anything else. In most cases, for old devices you can simply ship software codecs instead. Hell, Wikipedia ships video software codecs in the form of ogv.js, mainly because a lot of Apple devices wouldn't expose VP8/VP9 support even on SoCs that had hardware support for it, and that works surprisingly well. So for something like Opus, obviously it is trivial even on older hardware, even in the confines of a web browser. (And of course, Wikipedia uses it for Opus as well, but my understanding is this is only necessary for 1-2% of Internet traffic since most devices/browsers support Opus these days) That may leave some niches where AAC-LC is still a reasonable choice, like maybe old PMPs. However, I reckon that there are probably a lot of older PMPs that in fact, don't natively support AAC. For example, the trusty Sansa Clip+ from 2009 doesn't have AAC support. If you were to install third-party software such as Rockbox, well, then you'd have Opus support. So for audio, I think barring any specific reason not to, the meta is to basically always choose Opus.

by jchw 3mo ago

Dylan16807 3mo ago

Well a lot of the improvements cost more computation. I wouldn't be surprised if low-computation video had only improved slightly, but it seems like it has improved a lot. The advantage of h264 is hardware adoption much more than actually being computationally cheap, it seems? Well, maybe. The thing is, I don't know how the decoders scale. Can you make a decoder for a constrained AV1/h.265 in the same hardware space or maximum CPU budget as an h.264 decoder and still see very big advantages?

duskwuff 3mo ago

Once the patents expire, I expect to see H.264 become the JPEG of video codecs - it may not be the most efficient format available, but it's widely supported, relatively easy to encode/decode, and good enough quality for many use cases. (MP3 is in a similar place. AAC and Opus are technically superior, but everything supports MP3.)

ksec 3mo ago
>(MP3 is in a similar place. AAC and Opus are technically superior, but everything supports MP3.) Actually MP3 is more like the H.263 / Divx here. AAC-LC is more like H.264. The difference in support of AAC-LC and MP3 is near zero, both in terms of hardware and software. While AAC-LC is vastly more superior. AAC-LC has been declared patent free ( all patent expired ) by Redhat for 9 years already. The only part that is not perfect is there isn't a decent open source AAC-LC encoder. While you could use QAAC using Apple's encoder in iTunes. It would still have been better if there was an open source version. Luckily we just have a new AAC encoder with FFmpeg, it is doing great for and although sill not Apple's quality. But hopefully improve in the future. Or Apple could have just open source the god damn thing.
- jchw 3mo ago
  I was under the impression that the new FFmpeg nmr codec indeed outperforms the Apple one in every bitrate with Google's new Zimtohrli benchmark as well as ViSQOL. That would suggest Apple doesn't really have to open source anything, we should be good? Still, I don't see the point. Unlike video, audio decoding is so cheap you can practically do it on software even on fairly constrained devices. So really only in places like Bluetooth headphones where codec complexity can have a direct impact on battery life does it actually factor in. I say for most purposes people should just be going Opus today: it is far ahead of basically anything else. In most cases, for old devices you can simply ship software codecs instead. Hell, Wikipedia ships video software codecs in the form of ogv.js, mainly because a lot of Apple devices wouldn't expose VP8/VP9 support even on SoCs that had hardware support for it, and that works surprisingly well. So for something like Opus, obviously it is trivial even on older hardware, even in the confines of a web browser. (And of course, Wikipedia uses it for Opus as well, but my understanding is this is only necessary for 1-2% of Internet traffic since most devices/browsers support Opus these days) That may leave some niches where AAC-LC is still a reasonable choice, like maybe old PMPs. However, I reckon that there are probably a lot of older PMPs that in fact, don't natively support AAC. For example, the trusty Sansa Clip+ from 2009 doesn't have AAC support. If you were to install third-party software such as Rockbox, well, then you'd have Opus support. So for audio, I think barring any specific reason not to, the meta is to basically always choose Opus.