3 ms·

In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a proble

In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem. The real problem with AV1 is how darn computationally intensive it is to compress.

chii 2y ago
> how darn computationally intensive it is to compress. which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).
- ninjin 2y ago
  VP8, VP9, and AV1 are all wonderful and unencumbered. However, as awful as the licensing of H.264 is, it does yield reasonable quality even on hardware that is over a decade old. It is true that for many purposes we can offload encoding onto servers. However, as someone that frequently deals with live video streaming, AV1 is still out of reach on most hardware I am on and VP9 has only been viable for less than a decade. Yes, VP9 and AV1 are superior in terms of quality, but it is truly remarkable that H.264 runs as well as it does and I wish we had a similar unencumbered lightweight/portable codec (VP8 in my experience is about as heavy as VP9 and offers about the same quality as H.264). At least for audio we now have Opus and Flac (plus MP3 having had its vile patents expire), so hopefully video is the last frontier and VP9 and AV1 will become the standard over this decade.
- tonetegeatinst 2y ago
  In many ways I'd agree. Its more economical to compress once on the server and send over the internet as small as possible. Compression is both a science and a dark art to me.....yet I recognize that the more you compress data the more CPU usage is needed to decompress that data.
- mort96 2y ago
  > which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!). This is 100% use case dependent. For Netflix, compression is only done once and decompression happens a ridiculous amount of times. For YouTube, popular channels are similar to Netflix; but they suffer from a very very long tail of videos which only get watched a handful of times. For chat applications, videos may get watched only once by the recipient. For video conferencing, videos get compressed once (on the client's machine even, so ideally using hardware encoding), then decompressed once per recipient. This use-case also has the issue that every client needs to decode every other client's video stream, so you better send video in a format which every client can quickly decode (ideally using hardware decoding). Notice how "slow compression is fine because decompressing happens much more frequently" is only true for the Netflix use-case and the popular YouTube channels use-case. For everything else, slow compression is a problem. (Luckily, at least according to others here, AV1 isn't necessarily slow to encode, it's just the reference implementation that's slow and there are software implementations which match the speed of x264. I haven't verified this though)
Dylan16807 2y ago
> In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem. H.264 gets enough of a compression boost from 10-bit math that you should be using it anyway. I don't know if this affects H.265 > The real problem with AV1 is how darn computationally intensive it is to compress. How are you measuring that? It's true that SVT-AV1 is slower than x264 at preset 6 or below. And it's slower than x265 at preset 3 or below. But those aren't the presets you use if you want to be fast. SVT-AV1 can match the quality of x264 veryslow while running at the speed of x264 veryfast. It can match the quality of x265 veryslow while running at the speed of x265 medium. It can match the quality of x265 medium while running at the speed of x265 ultrafast. https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Computation-Tradeoffs.jpg https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...

chii 2y ago

> how darn computationally intensive it is to compress. which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!).

ninjin 2y ago
VP8, VP9, and AV1 are all wonderful and unencumbered. However, as awful as the licensing of H.264 is, it does yield reasonable quality even on hardware that is over a decade old. It is true that for many purposes we can offload encoding onto servers. However, as someone that frequently deals with live video streaming, AV1 is still out of reach on most hardware I am on and VP9 has only been viable for less than a decade. Yes, VP9 and AV1 are superior in terms of quality, but it is truly remarkable that H.264 runs as well as it does and I wish we had a similar unencumbered lightweight/portable codec (VP8 in my experience is about as heavy as VP9 and offers about the same quality as H.264). At least for audio we now have Opus and Flac (plus MP3 having had its vile patents expire), so hopefully video is the last frontier and VP9 and AV1 will become the standard over this decade.
tonetegeatinst 2y ago
In many ways I'd agree. Its more economical to compress once on the server and send over the internet as small as possible. Compression is both a science and a dark art to me.....yet I recognize that the more you compress data the more CPU usage is needed to decompress that data.
mort96 2y ago
> which i think is fine, as most decompression is on user side, but compression is on server side (and mostly only ever done once!). This is 100% use case dependent. For Netflix, compression is only done once and decompression happens a ridiculous amount of times. For YouTube, popular channels are similar to Netflix; but they suffer from a very very long tail of videos which only get watched a handful of times. For chat applications, videos may get watched only once by the recipient. For video conferencing, videos get compressed once (on the client's machine even, so ideally using hardware encoding), then decompressed once per recipient. This use-case also has the issue that every client needs to decode every other client's video stream, so you better send video in a format which every client can quickly decode (ideally using hardware decoding). Notice how "slow compression is fine because decompressing happens much more frequently" is only true for the Netflix use-case and the popular YouTube channels use-case. For everything else, slow compression is a problem. (Luckily, at least according to others here, AV1 isn't necessarily slow to encode, it's just the reference implementation that's slow and there are software implementations which match the speed of x264. I haven't verified this though)

Dylan16807 2y ago

> In an 8-bit colorspace, h.264/5 suffer from virtually no block artifacts. AV1 can't get rid of them without upping to 10-bit. Not that it's necessarily a problem. H.264 gets enough of a compression boost from 10-bit math that you should be using it anyway. I don't know if this affects H.265 > The real problem with AV1 is how darn computationally intensive it is to compress. How are you measuring that? It's true that SVT-AV1 is slower than x264 at preset 6 or below. And it's slower than x265 at preset 3 or below. But those aren't the presets you use if you want to be fast. SVT-AV1 can match the quality of x264 veryslow while running at the speed of x264 veryfast. It can match the quality of x265 veryslow while running at the speed of x265 medium. It can match the quality of x265 medium while running at the speed of x265 ultrafast. https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Computation-Tradeoffs.jpg https://engineering.fb.com/wp-content/uploads/2023/02/AV1-Co...