5 ms·

AV1 is more magic with better licensing. For their use case Meta is gradually getting to a baseline of VP9 and AV1 streams for their video streaming: https://w

AV1 is more magic with better licensing. For their use case Meta is gradually getting to a baseline of VP9 and AV1 streams for their video streaming: https://www.streamingmedia.com/Producer/Articles/Editorial/Featured-Articles/Is-the-AVC-H.264-Codec-Finally-Fading-163413.aspx https://www.streamingmedia.com/Producer/Articles/Editorial/F... And AV1 for video calls: https://engineering.fb.com/2024/03/20/video-engineering/mobile-rtc-video-av1-hd/ https://engineering.fb.com/2024/03/20/video-engineering/mobi... Microsoft is starting to use AV1 in Teams. AV1 has video coding tools that are particularly useful for screen sharing: https://techcommunity.microsoft.com/t5/microsoft-teams-blog/enhancing-screen-sharing-with-av1-in-microsoft-teams/ba-p/4096056 https://techcommunity.microsoft.com/t5/microsoft-teams-blog/... Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264. H.264 will still be around for quite some time, but AV1 looks set to become the new baseline for internet video.

MrDrMcCoy 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. 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...
wolfspider 2y ago
Well sure, but the hardware encode and decode isn’t completely widespread yet. I’ve been patiently waiting for what has felt like an eternity. From the developer perspective everyone needs to have access to it or I’m just sitting on my hands waiting for the capabilities to trickle down to the majority of users. Hopefully more users will purchase hardware if it features AV1 encode/decode. They need a logo that says “AV1 inside” or something. So, for example only the iPhone 15 pro offers hardware decode so far in the iPhone lineup.
- throwaway42668 2y ago
  Get a cheap Intel ARC A310 card. I have one in my workstation along side my AMD GPU purely for streaming/encoding. It works great.
  - KronisLV 2y ago
    Then the issue kind of becomes software support. For example, something like Handbrake will gladly use AV1, but Kdenlive will refuse to acknowledge that it exists (at least for hardware encode, last I checked; that said, they still mark NVENC as experimental). Also, OBS handles AV1 nicely, but you can’t stream to a site like Twitch because they only support H264 outside of specific experiments. That said, Arc GPUs are nice, I have an A580 and while the drivers aren’t as mature as Nvidia or AMD, I got it for a pretty good price and they’re gradually patching things out.
  - eternityforest 2y ago
    That only works if you actually own a desktop though. It's too bad they don't have some ultra tiny SD card sized accelerator addon system or something for laptops
- peutetre 2y ago
  You inevitably have to do multiple encodes. An H.264 encode as the "plays anywhere" option and an AV1 encode as the "less bandwidth or better image quality at the same bandwidth" option. YouTube does H.264, VP9, and AV1 video encodes with AAC and Opus audio encodes. This video for example has encodes of all those options: https://www.youtube.com/watch?v=ArmDp-zijuc https://www.youtube.com/watch?v=ArmDp-zijuc You can watch it in multiple resolutions and formats from 4K in AV1 down to 144p in H.264.
mananaysiempre 2y ago
> AV1 is more magic with better licensing. AV1 is bloody awful to encode in software. I was recording videos of lectures (a slowly moving person against a whiteboard with thin sharp lines on it, in a questionably well-lit room) and needed to encode them to smallish 720p files to be posted somewhere (ended up uploading them to the Internet Archive). This is not something that x264’s default encoding profiles do well on, but with a day or two of fiddling with the settings I had something I could run on my 2014-era iGPU-only laptop the night after the lecture and have the result up the next day. By contrast, libaom promised me something like a week of rendering time for the three hours of video. Perhaps this could be brought down (my x264 fiddling got me veryslow-comparable results several times faster), but the defaults were so bad I couldn’t afford to experiment. (This was some four years ago. Things have probably gotten better since then, but I don’t expect miracles.)
- peutetre 2y ago
  SVT-AV1 is a much faster AV1 encoder: https://gitlab.com/AOMediaCodec/SVT-AV1/ https://gitlab.com/AOMediaCodec/SVT-AV1/
- sergiotapia 2y ago
  Not at all my experience, 673 movies and counting. I encode at around 10 to 13x with my 12900K using svt-av1. My command: ffmpeg.exe -i file.mp4 -r 23.976 -vf scale=1280:720 -c:v libsvtav1 -pix_fmt yuv420p10le -crf 30 -preset 10 -g 600 -c:a libopus -b:a 96k -ac 2 -c:s copy -map 0 out.mp4 Try it.
  - runsfromfire 2y ago
    while the lectures in they were encoding would definitely look fine with these settings, I have to question your baseline for quality if you’re watching full Hollywood movies encoded at CRF 30.
    - sergiotapia 2y ago
      I'm watching these on my second monitor when I play guitar.
sambazi 2y ago
> Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264. can't shake the feeling that most videos at 720p took a hard hit to quality within the last years (or my eyes are getting better) any deep dives on the topic appreciated
- defrost 2y ago
  I've compressed tens of thousands of videos in recent years and critically looked at the results. My gut feeling is that implementations of hardware acceleration are just simply not as good as software implementations, the cause perhaps relating to localised resource constraints in hardware when recursing deeper or somesuch. The algorithms are the same, the chip versions are more resource constrained as the stack goes deeper if you will. Hardware compressors are much much faster, no doubt, by an order of magnitude and more .. but software compressors left to run slow, with two passes, just produce a much better result. Standard hardware compressor settings tend to leave moire patterns when the camera pans outside a chain link fence onto a player inside a court (for example), or leaves a blocky halo around the significant figure point of interest moving in an otherwise stillish scene - it's subltle small things that grate when you see them. The root cause of perceived downgrade in quality is bulk pushing of high quality originals through hardware accelerated compression in order to save time and reduce cost when generating lower bitrate versions to stream.
  - The_Colonel 2y ago
    There are tradeoffs. IIRC Netflix uses software encoders and they work pretty hard to squeeze the maximum quality for a given bitrate. Makes sense for their use case. OTOH, for like video calls, certain kinds of archiving, in general cases with few or no views, it makes sense to use hardware encoding even if it means compromised image quality.
    - defrost 2y ago
      Sure, there are many use cases and Netflix generally has streams with high quality and few artifacts. Real time video communications are going to go for fast low bitrates and that's more or less expected. In other cases where encoders have no real time constraint, eg pirate torrents and youtube alternate versions, there are multiple tiers of quality - for a given resolution (say 720p) and bit rate rate | file size the offerings can be split by time spent encoding, quick and shitty to slow and few visible quirks.
Dwedit 2y ago
AV1 doesn't have the fast encode/decode speed that H.264 has.
- Dylan16807 2y ago
  Do you have numbers for that? I don't have a comparison for decode speed, but software encoding of AV1 is able to match the performance of x264 veryfast while looking vastly better.

MrDrMcCoy 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. 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...

wolfspider 2y ago

Well sure, but the hardware encode and decode isn’t completely widespread yet. I’ve been patiently waiting for what has felt like an eternity. From the developer perspective everyone needs to have access to it or I’m just sitting on my hands waiting for the capabilities to trickle down to the majority of users. Hopefully more users will purchase hardware if it features AV1 encode/decode. They need a logo that says “AV1 inside” or something. So, for example only the iPhone 15 pro offers hardware decode so far in the iPhone lineup.

throwaway42668 2y ago
Get a cheap Intel ARC A310 card. I have one in my workstation along side my AMD GPU purely for streaming/encoding. It works great.
- KronisLV 2y ago
  Then the issue kind of becomes software support. For example, something like Handbrake will gladly use AV1, but Kdenlive will refuse to acknowledge that it exists (at least for hardware encode, last I checked; that said, they still mark NVENC as experimental). Also, OBS handles AV1 nicely, but you can’t stream to a site like Twitch because they only support H264 outside of specific experiments. That said, Arc GPUs are nice, I have an A580 and while the drivers aren’t as mature as Nvidia or AMD, I got it for a pretty good price and they’re gradually patching things out.
- eternityforest 2y ago
  That only works if you actually own a desktop though. It's too bad they don't have some ultra tiny SD card sized accelerator addon system or something for laptops
peutetre 2y ago
You inevitably have to do multiple encodes. An H.264 encode as the "plays anywhere" option and an AV1 encode as the "less bandwidth or better image quality at the same bandwidth" option. YouTube does H.264, VP9, and AV1 video encodes with AAC and Opus audio encodes. This video for example has encodes of all those options: https://www.youtube.com/watch?v=ArmDp-zijuc https://www.youtube.com/watch?v=ArmDp-zijuc You can watch it in multiple resolutions and formats from 4K in AV1 down to 144p in H.264.

mananaysiempre 2y ago

> AV1 is more magic with better licensing. AV1 is bloody awful to encode in software. I was recording videos of lectures (a slowly moving person against a whiteboard with thin sharp lines on it, in a questionably well-lit room) and needed to encode them to smallish 720p files to be posted somewhere (ended up uploading them to the Internet Archive). This is not something that x264’s default encoding profiles do well on, but with a day or two of fiddling with the settings I had something I could run on my 2014-era iGPU-only laptop the night after the lecture and have the result up the next day. By contrast, libaom promised me something like a week of rendering time for the three hours of video. Perhaps this could be brought down (my x264 fiddling got me veryslow-comparable results several times faster), but the defaults were so bad I couldn’t afford to experiment. (This was some four years ago. Things have probably gotten better since then, but I don’t expect miracles.)

peutetre 2y ago
SVT-AV1 is a much faster AV1 encoder: https://gitlab.com/AOMediaCodec/SVT-AV1/ https://gitlab.com/AOMediaCodec/SVT-AV1/
sergiotapia 2y ago
Not at all my experience, 673 movies and counting. I encode at around 10 to 13x with my 12900K using svt-av1. My command: ffmpeg.exe -i file.mp4 -r 23.976 -vf scale=1280:720 -c:v libsvtav1 -pix_fmt yuv420p10le -crf 30 -preset 10 -g 600 -c:a libopus -b:a 96k -ac 2 -c:s copy -map 0 out.mp4 Try it.
- runsfromfire 2y ago
  while the lectures in they were encoding would definitely look fine with these settings, I have to question your baseline for quality if you’re watching full Hollywood movies encoded at CRF 30.
  - sergiotapia 2y ago
    I'm watching these on my second monitor when I play guitar.

sambazi 2y ago

> Most of the video I see on YouTube these days is in VP9 or AV1. Occasionally some video is still H.264. can't shake the feeling that most videos at 720p took a hard hit to quality within the last years (or my eyes are getting better) any deep dives on the topic appreciated

defrost 2y ago
I've compressed tens of thousands of videos in recent years and critically looked at the results. My gut feeling is that implementations of hardware acceleration are just simply not as good as software implementations, the cause perhaps relating to localised resource constraints in hardware when recursing deeper or somesuch. The algorithms are the same, the chip versions are more resource constrained as the stack goes deeper if you will. Hardware compressors are much much faster, no doubt, by an order of magnitude and more .. but software compressors left to run slow, with two passes, just produce a much better result. Standard hardware compressor settings tend to leave moire patterns when the camera pans outside a chain link fence onto a player inside a court (for example), or leaves a blocky halo around the significant figure point of interest moving in an otherwise stillish scene - it's subltle small things that grate when you see them. The root cause of perceived downgrade in quality is bulk pushing of high quality originals through hardware accelerated compression in order to save time and reduce cost when generating lower bitrate versions to stream.
- The_Colonel 2y ago
  There are tradeoffs. IIRC Netflix uses software encoders and they work pretty hard to squeeze the maximum quality for a given bitrate. Makes sense for their use case. OTOH, for like video calls, certain kinds of archiving, in general cases with few or no views, it makes sense to use hardware encoding even if it means compromised image quality.
  - defrost 2y ago
    Sure, there are many use cases and Netflix generally has streams with high quality and few artifacts. Real time video communications are going to go for fast low bitrates and that's more or less expected. In other cases where encoders have no real time constraint, eg pirate torrents and youtube alternate versions, there are multiple tiers of quality - for a given resolution (say 720p) and bit rate rate | file size the offerings can be split by time spent encoding, quick and shitty to slow and few visible quirks.

Dwedit 2y ago

AV1 doesn't have the fast encode/decode speed that H.264 has.

Dylan16807 2y ago
Do you have numbers for that? I don't have a comparison for decode speed, but software encoding of AV1 is able to match the performance of x264 veryfast while looking vastly better.