13 ms·

AV1 beats x264 and libvpx-vp9 in practical use case

296 points by runesoerensen 9y ago

CharlesW 9y ago
The interesting bits for me: "Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively. "However, AV1 saw increases in encoding computational complexity compared with x264 main, x264 high and libvpx-vp9 for ABR mode. Encoding run time was 9226.4x, 8139.2x and 667.1x greater, respectively…"
- niftich 9y ago
  Let that sink in: 'Encoding run time was 9226.4x, 8139.2x and 667.1x greater, respectively…' The codec is good, but the encoder has a long way to go. This places it squarely in the realm of only worth it right now if you're serving the same video millions of times (someone graph this?). It's a bit hyperbolic to claim that this is a 'practical use case', but maybe at Facebook/Netflix/YouTube's scale, it is. But it will be exciting to watch this space.
  - JoshTriplett 9y ago
    On the flip side, as the encoder gets better, the quality and bitrate will improve as well, not just the encoding time.
  - homero 9y ago
    Netflix yes, others no, most videos aren't played often
    - gpm 9y ago
      Certainly some videos on youtube, and which ones should be pretty predictable.
      - estebank 9y ago
        It doesn't even need to be predictable, just reactive.
  - whatever_dude 9y ago
    I'd assume encoding was largely software-based using a POC encoder while x264/vp9 video encoders probably already take advantage of hardware acceleration shortcuts evolved over many years. > the main focus of current AV1 development is on speed optimization to make it practical for use in production systems Remember: first make it work, then make it right, then make it fast. Seems they're only starting the 3rd step now.
    - written 9y ago
      x264 is a software codec.
    - voltagex_ 9y ago
      x264 runs circles around all the hardware accelerated encoders, at least quality wise. I haven't tried AV1 yet, but the only way I was able to encode with x265 in a reasonable amount of time was to shard the job over multiple machines and then join the file back together at the end.
      - aidenn0 9y ago
        x265 gets ~10fps on veryslow with 480p video on a recent workstation. Intel and AMD are pretty much tied there because Intel's per-core performance is significantly higher for x265, but AMD has more cores.
    - niftich 9y ago
      libvpx, the VP9 encoder library used in this test, has no support for any hardware encoder blocks for VP9 [1], so it does everything in software. There are ways [2] to compile some support into ffmpeg-with-libvpx that makes it able to invoke the hardware encoder in newer Intel CPUs (Skylake or newer) [3][4] (using vp9_vaapi) but it's doubtful that this was used, since their command-line switches indicate nothing of the sort. x264 is a software-only encoder that provides no hooks into hardware acceleration. Their ffmpeg command line indicates that no hardware acceleration hooks of ffmpeg were used. [1] https://github.com/webmproject/libvpx/blob/master/CHANGELOG https://github.com/webmproject/libvpx/blob/master/CHANGELOG [2] https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3 https://gist.github.com/Brainiarc7/24de2edef08866c3040805048... [3] https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c39efeb2a10492a327110d6a06c8&utm_source=anzwix https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c3... [4] https://en.wikipedia.org/wiki/VP9#Hardware_implementations https://en.wikipedia.org/wiki/VP9#Hardware_implementations
  - duskwuff 9y ago
    The same thing was true of H264 when it first came out. Reference encoders/decoders are always incredibly slow -- they're written to be correct, not fast.
    - ksec 9y ago
      Many continue to use this comparison. H264 Reference Encoder wasn't even tuned for anything. Not even quality. Hence why we not only get much better speed in x264, but also higher quality. And the Reference Encoder ( JM ) was only 250 times slower when it first came out. It truly was a pieces written to be correct rather then anything else. And there was some easy wins to get it 10x - 20x faster within a matter of weeks. Now Av1 is nearly 10000x slower, that is if you manage to speed it up 100x it is still 100x slower. The codec right now was tuned for quality metrics. They were trying to hit PSNR, SSIM and even VRMF at 30% higher then VP9 at all cost. Which is not the same as JM. I dont doubt they could speed it up. But by how much. Some even mention it is only usable by companies with Scale, well this is so far from truth. You dont gain much economy of scale once you past certain level of compute. What cost $1M dollar to encode at facebook now cost $1B or $10B as it stands. People seems to have a real lack of sense in scale of how much 1000x is. Or even 10K x. Your compute cost is going to be dictated by CPU manufacturer or silicon prices. And that 30% of bitrate reduction is not going to save you money from the insane increase of compute. Especially if you are Netflix with Appliance sitting at ISP's DC. Not long ago I asked how are we going to get the encoding speed to some sane's time. Like 10x of x264 High Quality. Turns out it will very likely have to disable certain tools set now being used, which means a reduction of quality. But I believe it will still be better then x265 at the end. The tools available for AV1 is quite massive. Right now we have xvc which is looking more like an H.266 encoder, and offer 30% improvement over AV1 if you want to believe PSNR and SSIM. But it is even slower then AV1.
      - ec109685 9y ago
        To get to “sane time”, you break up the video and have more than one encoder running at a time: http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf
  - BurningCycles 9y ago
    >The codec is good, but the encoder has a long way to go. True, but it hasn't been optimized as of yet, I'm pretty sure there are a lot of low-hanging fruits once they start converting code hot paths into hand-optimized assembly. That said, no matter how much optimization it gets, it will be slower than equally optimized HEVC, h264 given that AV1 is a more complex codec.
- jascenso 9y ago
  Much worse than I tough. With this complexity increase, HEVC is by far the best choice.
  - voltagex_ 9y ago
    For now - and even HEVC encoders are still pretty new.
- jbk 9y ago
  At least 2 new software encoders are coming by and they are way faster than this, while achieving the same (or better?) quality than libaom.
  - voltagex_ 9y ago
    Do you have any more info on this?
  - ksec 9y ago
    Names?
- masklinn 9y ago
  Note that this is for the AV1 reference software encoder. It's not hardware accelerated, and probably built with limited regards to speed and e.g. vectorisation.
LeoPanthera 9y ago
AV1's competition is x265, not x264.
- lern_too_spel 9y ago
  AV1 is a codec, not an implementation. Its competition is the upcoming H.266. VP9's competition was H.265, and libvpx-vp9's competition was x265.
  - niftich 9y ago
    The exact correspondence between the VPx-es and the MPEG codecs is not that relevant, because old codecs don't go away when new ones come out. In fact, hardware decoders are irrevocably baked into devices where consumption happens, so anything H.264 or newer becomes difficult to displace -- like Google's ham-fisted push [1] for VP8 and VP9 on YouTube for their own benefit, burning through people's batteries in software instead of serving H.264. But I'd argue that the MPEG codecs roughly slot in between each tier of VP8, VP9, and AV1, because the MPEG codecs are tremendously flexible (as can be seen in Netflix's tests [2]), have dozens of competing encoders of different qualities, and dozens of profiles that constrain or unlock advanced features. So in a way, it can be simultaneously true that AV1's competition is both H.265 and whatever comes after H.265. [1] https://news.ycombinator.com/item?id=13230676 https://news.ycombinator.com/item?id=13230676 [2] https://medium.com/netflix-techblog/more-efficient-mobile-encodes-for-netflix-downloads-625d7b082909 https://medium.com/netflix-techblog/more-efficient-mobile-en...
    - deleted 9y ago
      [deleted]
    - lern_too_spel 9y ago
      VP9 had more browser support than H.265, the codec it competed against. It was Apple's hamfisted attempt to hinder royalty free codecs for the web (among other web standards) that gave some users a bad battery experience. https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp9-and-av1 https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp... That Google didn't force VP8 over H.264 is what led to the unfortunate situation with Firefox needing to ship a binary blob. I'm happy that Google stuck to its guns in the next round.
formatkaka 9y ago
Encoding time is 667x compared to VP9. How can it be used in production ? 667 TIMES LONGER
- akmittal 9y ago
  How about decoding performance, which is much more important.
  - bufferoverflow 9y ago
    Both are important, especially in the age of user-generated content and 4K camera in every new smartphone.
    - akmittal 9y ago
      Most people spend lot more time decoding than encoding.
      - vanderZwan 9y ago
        Yesterday's xiph.org thread had the same discussion - for live-streaming, encoding is the bottleneck. If the encoder drops frames, all recipients drop frames. - for other purposes, decoding is likely the "bottleneck", although even then: the slower and more CPU intensive an encoder is, the more times a video has to be downloaded and viewed to "break even" through the "savings" on the decoder side. So there still is a trade-off to be made with how slow an encoder is allowed to be.
  - opencl 9y ago
    Decoding is going to have be supported in hardware for any sort of mass adoption anyway.
    - deleted 9y ago
      [deleted]
    - 9y ago
ncmncm 9y ago
I wonder if anyone has tried rendering directly to AV1 (or x264, or what-have-you), e.g. in a video game. There is all this hardware devoted to turning a few bytes of input into lots of pixels out. Maybe you could do less work producing just the few bytes, and let dedicated hardware generate the pixels. Of course you don't need for the CPU to generate the bytes; code running on the GPU would still do that, but with less work to do, you might get higher frame rates, or better detail at the same rate. You heard it here first. (That is, unless it doesn't work.)
- msravi 9y ago
  > Maybe you could do less work producing just the few bytes It takes more work to produce fewer bytes, because you've to pack the same information in fewer bytes. Entropy and all that.
  - ncmncm 9y ago
    Not if the information starts out in fewer bytes. Then, you're just rearranging the bits into renderable order. "Chicken" is a very small number of bits that would need to be expanded to more bits (leg down here, wing over there, beak up here) before handing them over to the decoder to make actual feathers. The representation in a game's scene list is overwhelmingly more compact than the input to a decoder would be, and most of it barely changes from one second to the next, as the pixels are all replaced dozens of times over.
    - baseethrowaway 9y ago
      The information does not start out in fewer bytes. It starts out in all the bytes that represent the 3D models of entities you're interacting with in your game and the textures to cover them, at least. That's usually more bytes than needed to show a 32 bit 4K picture. The rendering process reduces all the jungle you have in your VRAM to a few kB that are briefly shown on your screen. It seems like you don't know the basics of 3D graphics nor the basics of video encoding. It is extra work and would save some bandwidth needed to pump the picture to the display, which is not an issue in 3D graphics (we have dedicated cables).
gok 9y ago
Compression standard finalized in 2018 is more sophisticated than one from 2004? Say it ain’t so.
StreamBright 9y ago
Is this going to be supported as a native platform on iOS and Android? Let's say I would like to start a new company that delivers video content to people. Could I use this today as the primary format for that? The performance numbers look great.
- Mindwipe 9y ago
  No, because there's no hardware decoder support for it yet in common chipsets. We're probably three years away from that, realistically.
vanderZwan 9y ago
> Our tests were conducted primarily with Standard Definition (SD) and High Definition (HD) video files, because those are currently the most popular video formats on Facebook. But because AV1's performance increased as video resolution increased, we conclude the new compression codec will likely deliver even higher efficiency gains with UHD/4K and 8K content. This remark about higher resolution reminded me of something I've been wondering about frame rates, which are essentially also a higher resolution, except across the dimension of time. Assuming low to negligible noise from the camera (or a CGI, which avoids the problem altogether, shouldn't doubling from 30FPS to 60FPS have less than double the size increase? The reasoning being that changes per frame are lower, leading to better predictions. Is there any rule-of-thumb formula for expected size increase as frame rate increases?
- iameli 9y ago
  I don't know any math, but speaking from experience streaming it's around ~30% more.
  - vanderZwan 9y ago
    Thanks for the datapoint, even if it is anecdotal! As colde points out in the other reply, the type of content matters so: what kind of content do you stream? Games? If so, which genre(s) (as in: a 2D platformer might compress much better, given the simpler motion, not to mention minimalistic graphics that are more common there)
- jd20 9y ago
  The delta encoding will be more efficient with higher frame rate, but also x264 has a tweak which decreases quality factor as frame rate increases. Why? The reasoning was that, since the frame is displayed for less time, you don't have as much time to appreciate the details and hence fewer bits can be used, while still maintaining the same perceptual quality. I found this out the hard way when encoding time lapses, even if the delta between frames is identical, the final choice of frame rate greatly affects output file size.
  - 9y ago
vbezhenar 9y ago
I wonder about CPU decoding. I never cared about codecs, because every movie was played at proper FPS on my 2013 MacBook Air. But recently I downloaded 4k H.265-encoded movie and it turns out that MacBook just wasn't able to decode it at proper speed. I hope that AV1 will be more efficient.
- freeone3000 9y ago
  The determining factor is hardware decode support, not efficiency. H.264 is worse than H.265, but if that movie was H.264, it would have played back flawlessly due to the Intel hardware decoder.
  - TD-Linux 9y ago
    It would also play back flawlessly even without the hardware decoder, because H.264 is so fast to decode nowadays. If AV1 is fast enough it can allow people to use AV1 without buying new hardware.
- microcolonel 9y ago
  The software decoder is not considerably slower than the VP9 decoder, which is pretty fast. If you want to try it out, Firefox Nightly ships a pre-release AV1 decoder behind a runtime preference, so you can try it out. There's still a chance that it can't keep up, of course. Also, it's likely that you've been using the hardware decoder on your machine for H.264, which would further take a load off. H.265 decoders also vary considerably in terms of speed, I've noticed recently that ffmpeg decodes H.265 faster than it used to. https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/ https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video...
keldaris 9y ago
"Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively. This sounds like AV1 is actually worse than H.265, at least at low-ish resolutions. Am I misreading these results? For context, I've moved to using H.265 (via the x265 encoder) for archiving 720p and 1080p video. At least for low bitrates (in the 500-1500 kbit/s range) it gives me over 50% smaller filesizes compared to x264 high profile at roughly the same quality. The encoding speed is much slower, of course, but not by more than 10x on modern CPUs, typically less. I had hoped to move over to some AV1 implementation in a few years, but these results make that look doubtful. Are the supposed advantages of AV1 over H.265 confined to ultra high resolutions and/or high bitrates? Please note that this is a purely technical question. I don't care about the patent issues and for those that do, they've been covered at length in other comments already.
- microcolonel 9y ago
  > This sounds like AV1 is actually worse than H.265, at least at low-ish resolutions. Am I misreading these results? Yes, VP9 is basically on par with H.265 at standard resolutions, so if AV1 is 34% better, then it is a lot better than H.265. H.265 also doesn't tend to scale as well down to smaller resolutions, a lot of AV1's benefits scale well across the resolution spectrum (it seems). I'm sure a lot of the confusion about this comparison comes from the fact that a) we're not talking about UHD content, which is where H.265 was intended to shine, and b) Facebook probably has never had, and will likely never have, any interest in H.265 because it is simply too legally and practically cumbersome.
  - keldaris 9y ago
    > Yes, VP9 is basically on par with H.265 at standard resolutions, so if AV1 is 34% better, then it is a lot better than H.265. Is that really true, though? The most comprehensive test I've seen [1] led Netflix to conclude that H.265 was better than VP9 by about 20%, including resolutions all the way down to 360p. In my own experience and other tests I've seen the gap seems even wider. There's a few usecases where VP9 is superior (most notably screencasts), but generally it seems to lag behind H.265 while also being much slower to encode. [1] http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx http://www.streamingmedia.com/Articles/Editorial/Featured-Ar...
JoachimS 9y ago
(Several have asked, but I haven't seen a good response yet.) What are the computational requirements for AV1 decoding compared to x264, v9 etc? Is it in the same order, multiple orders worse? Or lower?
- sturmen 9y ago
  I don't know the true answer to your question, but since encoding is expected to reach just 5X of VP9 by the end of this year, I think decoding is in the same order. The plan, of course, is in the coming years there will be decoders baked into the silicon so the computational complexity is offloaded from the CPU and therefore becomes (in some ways) irrelevant.
- Radle 9y ago
  They are nearly identical. But your current CPU does not have a integrated hardware decoder for AV1, thus it might practically be slower for now.
vladdanilov 9y ago
Meanwhile, there are 2.8 MB of images in the article with the header image alone being a 1.6 MB JPEG (!). They can be reduced by at least 50%, given that the deringing filter works fine on contrast text/charts. Even more, the optimal format for this type of images is PNG not JPEG. After the conversion and optimization, they take 889 KB [1], >3 times smaller, and doing the same on properly resized originals without JPEG artifacts can bring them down to 100-200 KB. [1] https://github.com/vmdanilov/optimage/files/1898955/images.zip https://github.com/vmdanilov/optimage/files/1898955/images.z...
- triangleman 9y ago
  Totally appropriate self promotion, I approve.
- tinus_hn 9y ago
  If that graph is a jpeg it kind of disqualifies the author in any discussion on compression.
ksec 9y ago
From Doom9 Harmonic showed a comparison demo at NAB, pitting AV1, AVC, HEVC and JVET against each other. At the equivalent bitrate of 1.9 Mbps they got the following results: Codec -- PSNR -- VMAF AVC -- 32.7 -- 58 HEVC -- 36.7 -- 80 AV1 -- 37.2 -- 83 JVET -- 38.5 -- 88

296 points by runesoerensen 9y ago

The interesting bits for me: "Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively. "However, AV1 saw increases in encoding computational complexity compared with x264 main, x264 high and libvpx-vp9 for ABR mode. Encoding run time was 9226.4x, 8139.2x and 667.1x greater, respectively…"

niftich 9y ago
Let that sink in: 'Encoding run time was 9226.4x, 8139.2x and 667.1x greater, respectively…' The codec is good, but the encoder has a long way to go. This places it squarely in the realm of only worth it right now if you're serving the same video millions of times (someone graph this?). It's a bit hyperbolic to claim that this is a 'practical use case', but maybe at Facebook/Netflix/YouTube's scale, it is. But it will be exciting to watch this space.
- JoshTriplett 9y ago
  On the flip side, as the encoder gets better, the quality and bitrate will improve as well, not just the encoding time.
- homero 9y ago
  Netflix yes, others no, most videos aren't played often
  - gpm 9y ago
    Certainly some videos on youtube, and which ones should be pretty predictable.
    - estebank 9y ago
      It doesn't even need to be predictable, just reactive.
- whatever_dude 9y ago
  I'd assume encoding was largely software-based using a POC encoder while x264/vp9 video encoders probably already take advantage of hardware acceleration shortcuts evolved over many years. > the main focus of current AV1 development is on speed optimization to make it practical for use in production systems Remember: first make it work, then make it right, then make it fast. Seems they're only starting the 3rd step now.
  - written 9y ago
    x264 is a software codec.
  - voltagex_ 9y ago
    x264 runs circles around all the hardware accelerated encoders, at least quality wise. I haven't tried AV1 yet, but the only way I was able to encode with x265 in a reasonable amount of time was to shard the job over multiple machines and then join the file back together at the end.
    - aidenn0 9y ago
      x265 gets ~10fps on veryslow with 480p video on a recent workstation. Intel and AMD are pretty much tied there because Intel's per-core performance is significantly higher for x265, but AMD has more cores.
  - niftich 9y ago
    libvpx, the VP9 encoder library used in this test, has no support for any hardware encoder blocks for VP9 [1], so it does everything in software. There are ways [2] to compile some support into ffmpeg-with-libvpx that makes it able to invoke the hardware encoder in newer Intel CPUs (Skylake or newer) [3][4] (using vp9_vaapi) but it's doubtful that this was used, since their command-line switches indicate nothing of the sort. x264 is a software-only encoder that provides no hooks into hardware acceleration. Their ffmpeg command line indicates that no hardware acceleration hooks of ffmpeg were used. [1] https://github.com/webmproject/libvpx/blob/master/CHANGELOG https://github.com/webmproject/libvpx/blob/master/CHANGELOG [2] https://gist.github.com/Brainiarc7/24de2edef08866c304080504877239a3 https://gist.github.com/Brainiarc7/24de2edef08866c3040805048... [3] https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c39efeb2a10492a327110d6a06c8&utm_source=anzwix https://cgit.freedesktop.org/libva/commit/?id=fb57f5c15e72c3... [4] https://en.wikipedia.org/wiki/VP9#Hardware_implementations https://en.wikipedia.org/wiki/VP9#Hardware_implementations
- duskwuff 9y ago
  The same thing was true of H264 when it first came out. Reference encoders/decoders are always incredibly slow -- they're written to be correct, not fast.
  - ksec 9y ago
    Many continue to use this comparison. H264 Reference Encoder wasn't even tuned for anything. Not even quality. Hence why we not only get much better speed in x264, but also higher quality. And the Reference Encoder ( JM ) was only 250 times slower when it first came out. It truly was a pieces written to be correct rather then anything else. And there was some easy wins to get it 10x - 20x faster within a matter of weeks. Now Av1 is nearly 10000x slower, that is if you manage to speed it up 100x it is still 100x slower. The codec right now was tuned for quality metrics. They were trying to hit PSNR, SSIM and even VRMF at 30% higher then VP9 at all cost. Which is not the same as JM. I dont doubt they could speed it up. But by how much. Some even mention it is only usable by companies with Scale, well this is so far from truth. You dont gain much economy of scale once you past certain level of compute. What cost $1M dollar to encode at facebook now cost $1B or $10B as it stands. People seems to have a real lack of sense in scale of how much 1000x is. Or even 10K x. Your compute cost is going to be dictated by CPU manufacturer or silicon prices. And that 30% of bitrate reduction is not going to save you money from the insane increase of compute. Especially if you are Netflix with Appliance sitting at ISP's DC. Not long ago I asked how are we going to get the encoding speed to some sane's time. Like 10x of x264 High Quality. Turns out it will very likely have to disable certain tools set now being used, which means a reduction of quality. But I believe it will still be better then x265 at the end. The tools available for AV1 is quite massive. Right now we have xvc which is looking more like an H.266 encoder, and offer 30% improvement over AV1 if you want to believe PSNR and SSIM. But it is even slower then AV1.
    - ec109685 9y ago
      To get to “sane time”, you break up the video and have more than one encoder running at a time: http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf http://cseweb.ucsd.edu/~gmporter/papers/nsdi17-excamera.pdf
- BurningCycles 9y ago
  >The codec is good, but the encoder has a long way to go. True, but it hasn't been optimized as of yet, I'm pretty sure there are a lot of low-hanging fruits once they start converting code hot paths into hand-optimized assembly. That said, no matter how much optimization it gets, it will be slower than equally optimized HEVC, h264 given that AV1 is a more complex codec.
jascenso 9y ago
Much worse than I tough. With this complexity increase, HEVC is by far the best choice.
- voltagex_ 9y ago
  For now - and even HEVC encoders are still pretty new.
jbk 9y ago
At least 2 new software encoders are coming by and they are way faster than this, while achieving the same (or better?) quality than libaom.
- voltagex_ 9y ago
  Do you have any more info on this?
- ksec 9y ago
  Names?
masklinn 9y ago
Note that this is for the AV1 reference software encoder. It's not hardware accelerated, and probably built with limited regards to speed and e.g. vectorisation.

LeoPanthera 9y ago

AV1's competition is x265, not x264.

lern_too_spel 9y ago
AV1 is a codec, not an implementation. Its competition is the upcoming H.266. VP9's competition was H.265, and libvpx-vp9's competition was x265.
- niftich 9y ago
  The exact correspondence between the VPx-es and the MPEG codecs is not that relevant, because old codecs don't go away when new ones come out. In fact, hardware decoders are irrevocably baked into devices where consumption happens, so anything H.264 or newer becomes difficult to displace -- like Google's ham-fisted push [1] for VP8 and VP9 on YouTube for their own benefit, burning through people's batteries in software instead of serving H.264. But I'd argue that the MPEG codecs roughly slot in between each tier of VP8, VP9, and AV1, because the MPEG codecs are tremendously flexible (as can be seen in Netflix's tests [2]), have dozens of competing encoders of different qualities, and dozens of profiles that constrain or unlock advanced features. So in a way, it can be simultaneously true that AV1's competition is both H.265 and whatever comes after H.265. [1] https://news.ycombinator.com/item?id=13230676 https://news.ycombinator.com/item?id=13230676 [2] https://medium.com/netflix-techblog/more-efficient-mobile-encodes-for-netflix-downloads-625d7b082909 https://medium.com/netflix-techblog/more-efficient-mobile-en...
  - deleted 9y ago
    [deleted]
  - lern_too_spel 9y ago
    VP9 had more browser support than H.265, the codec it competed against. It was Apple's hamfisted attempt to hinder royalty free codecs for the web (among other web standards) that gave some users a bad battery experience. https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp9-and-av1 https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp... That Google didn't force VP8 over H.264 is what led to the unfortunate situation with Firefox needing to ship a binary blob. I'm happy that Google stuck to its guns in the next round.

formatkaka 9y ago

Encoding time is 667x compared to VP9. How can it be used in production ? 667 TIMES LONGER

akmittal 9y ago
How about decoding performance, which is much more important.
- bufferoverflow 9y ago
  Both are important, especially in the age of user-generated content and 4K camera in every new smartphone.
  - akmittal 9y ago
    Most people spend lot more time decoding than encoding.
    - vanderZwan 9y ago
      Yesterday's xiph.org thread had the same discussion - for live-streaming, encoding is the bottleneck. If the encoder drops frames, all recipients drop frames. - for other purposes, decoding is likely the "bottleneck", although even then: the slower and more CPU intensive an encoder is, the more times a video has to be downloaded and viewed to "break even" through the "savings" on the decoder side. So there still is a trade-off to be made with how slow an encoder is allowed to be.
- opencl 9y ago
  Decoding is going to have be supported in hardware for any sort of mass adoption anyway.
  - deleted 9y ago
    [deleted]
  - 9y ago

ncmncm 9y ago

I wonder if anyone has tried rendering directly to AV1 (or x264, or what-have-you), e.g. in a video game. There is all this hardware devoted to turning a few bytes of input into lots of pixels out. Maybe you could do less work producing just the few bytes, and let dedicated hardware generate the pixels. Of course you don't need for the CPU to generate the bytes; code running on the GPU would still do that, but with less work to do, you might get higher frame rates, or better detail at the same rate. You heard it here first. (That is, unless it doesn't work.)

msravi 9y ago
> Maybe you could do less work producing just the few bytes It takes more work to produce fewer bytes, because you've to pack the same information in fewer bytes. Entropy and all that.
- ncmncm 9y ago
  Not if the information starts out in fewer bytes. Then, you're just rearranging the bits into renderable order. "Chicken" is a very small number of bits that would need to be expanded to more bits (leg down here, wing over there, beak up here) before handing them over to the decoder to make actual feathers. The representation in a game's scene list is overwhelmingly more compact than the input to a decoder would be, and most of it barely changes from one second to the next, as the pixels are all replaced dozens of times over.
  - baseethrowaway 9y ago
    The information does not start out in fewer bytes. It starts out in all the bytes that represent the 3D models of entities you're interacting with in your game and the textures to cover them, at least. That's usually more bytes than needed to show a 32 bit 4K picture. The rendering process reduces all the jungle you have in your VRAM to a few kB that are briefly shown on your screen. It seems like you don't know the basics of 3D graphics nor the basics of video encoding. It is extra work and would save some bandwidth needed to pump the picture to the display, which is not an issue in 3D graphics (we have dedicated cables).

gok 9y ago

Compression standard finalized in 2018 is more sophisticated than one from 2004? Say it ain’t so.

StreamBright 9y ago

Is this going to be supported as a native platform on iOS and Android? Let's say I would like to start a new company that delivers video content to people. Could I use this today as the primary format for that? The performance numbers look great.

Mindwipe 9y ago
No, because there's no hardware decoder support for it yet in common chipsets. We're probably three years away from that, realistically.

vanderZwan 9y ago

> Our tests were conducted primarily with Standard Definition (SD) and High Definition (HD) video files, because those are currently the most popular video formats on Facebook. But because AV1's performance increased as video resolution increased, we conclude the new compression codec will likely deliver even higher efficiency gains with UHD/4K and 8K content. This remark about higher resolution reminded me of something I've been wondering about frame rates, which are essentially also a higher resolution, except across the dimension of time. Assuming low to negligible noise from the camera (or a CGI, which avoids the problem altogether, shouldn't doubling from 30FPS to 60FPS have less than double the size increase? The reasoning being that changes per frame are lower, leading to better predictions. Is there any rule-of-thumb formula for expected size increase as frame rate increases?

iameli 9y ago
I don't know any math, but speaking from experience streaming it's around ~30% more.
- vanderZwan 9y ago
  Thanks for the datapoint, even if it is anecdotal! As colde points out in the other reply, the type of content matters so: what kind of content do you stream? Games? If so, which genre(s) (as in: a 2D platformer might compress much better, given the simpler motion, not to mention minimalistic graphics that are more common there)
jd20 9y ago
The delta encoding will be more efficient with higher frame rate, but also x264 has a tweak which decreases quality factor as frame rate increases. Why? The reasoning was that, since the frame is displayed for less time, you don't have as much time to appreciate the details and hence fewer bits can be used, while still maintaining the same perceptual quality. I found this out the hard way when encoding time lapses, even if the delta between frames is identical, the final choice of frame rate greatly affects output file size.
- 9y ago

vbezhenar 9y ago

I wonder about CPU decoding. I never cared about codecs, because every movie was played at proper FPS on my 2013 MacBook Air. But recently I downloaded 4k H.265-encoded movie and it turns out that MacBook just wasn't able to decode it at proper speed. I hope that AV1 will be more efficient.

freeone3000 9y ago
The determining factor is hardware decode support, not efficiency. H.264 is worse than H.265, but if that movie was H.264, it would have played back flawlessly due to the Intel hardware decoder.
- TD-Linux 9y ago
  It would also play back flawlessly even without the hardware decoder, because H.264 is so fast to decode nowadays. If AV1 is fast enough it can allow people to use AV1 without buying new hardware.
microcolonel 9y ago
The software decoder is not considerably slower than the VP9 decoder, which is pretty fast. If you want to try it out, Firefox Nightly ships a pre-release AV1 decoder behind a runtime preference, so you can try it out. There's still a chance that it can't keep up, of course. Also, it's likely that you've been using the hardware decoder on your machine for H.264, which would further take a load off. H.265 decoders also vary considerably in terms of speed, I've noticed recently that ffmpeg decodes H.265 faster than it used to. https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video/ https://hacks.mozilla.org/2017/11/dash-playback-of-av1-video...

keldaris 9y ago

"Our testing shows AV1 surpasses its stated goal of 30% better compression than VP9, and achieves gains of 50.3%, 46.2% and 34.0%, compared to x264 main profile, x264 high profile and libvpx-vp9, respectively. This sounds like AV1 is actually worse than H.265, at least at low-ish resolutions. Am I misreading these results? For context, I've moved to using H.265 (via the x265 encoder) for archiving 720p and 1080p video. At least for low bitrates (in the 500-1500 kbit/s range) it gives me over 50% smaller filesizes compared to x264 high profile at roughly the same quality. The encoding speed is much slower, of course, but not by more than 10x on modern CPUs, typically less. I had hoped to move over to some AV1 implementation in a few years, but these results make that look doubtful. Are the supposed advantages of AV1 over H.265 confined to ultra high resolutions and/or high bitrates? Please note that this is a purely technical question. I don't care about the patent issues and for those that do, they've been covered at length in other comments already.

microcolonel 9y ago
> This sounds like AV1 is actually worse than H.265, at least at low-ish resolutions. Am I misreading these results? Yes, VP9 is basically on par with H.265 at standard resolutions, so if AV1 is 34% better, then it is a lot better than H.265. H.265 also doesn't tend to scale as well down to smaller resolutions, a lot of AV1's benefits scale well across the resolution spectrum (it seems). I'm sure a lot of the confusion about this comparison comes from the fact that a) we're not talking about UHD content, which is where H.265 was intended to shine, and b) Facebook probably has never had, and will likely never have, any interest in H.265 because it is simply too legally and practically cumbersome.
- keldaris 9y ago
  > Yes, VP9 is basically on par with H.265 at standard resolutions, so if AV1 is 34% better, then it is a lot better than H.265. Is that really true, though? The most comprehensive test I've seen [1] led Netflix to conclude that H.265 was better than VP9 by about 20%, including resolutions all the way down to 360p. In my own experience and other tests I've seen the gap seems even wider. There's a few usecases where VP9 is superior (most notably screencasts), but generally it seems to lag behind H.265 while also being much slower to encode. [1] http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx http://www.streamingmedia.com/Articles/Editorial/Featured-Ar...

JoachimS 9y ago

(Several have asked, but I haven't seen a good response yet.) What are the computational requirements for AV1 decoding compared to x264, v9 etc? Is it in the same order, multiple orders worse? Or lower?

sturmen 9y ago
I don't know the true answer to your question, but since encoding is expected to reach just 5X of VP9 by the end of this year, I think decoding is in the same order. The plan, of course, is in the coming years there will be decoders baked into the silicon so the computational complexity is offloaded from the CPU and therefore becomes (in some ways) irrelevant.
Radle 9y ago
They are nearly identical. But your current CPU does not have a integrated hardware decoder for AV1, thus it might practically be slower for now.

vladdanilov 9y ago

Meanwhile, there are 2.8 MB of images in the article with the header image alone being a 1.6 MB JPEG (!). They can be reduced by at least 50%, given that the deringing filter works fine on contrast text/charts. Even more, the optimal format for this type of images is PNG not JPEG. After the conversion and optimization, they take 889 KB [1], >3 times smaller, and doing the same on properly resized originals without JPEG artifacts can bring them down to 100-200 KB. [1] https://github.com/vmdanilov/optimage/files/1898955/images.zip https://github.com/vmdanilov/optimage/files/1898955/images.z...

triangleman 9y ago
Totally appropriate self promotion, I approve.
tinus_hn 9y ago
If that graph is a jpeg it kind of disqualifies the author in any discussion on compression.

ksec 9y ago

From Doom9 Harmonic showed a comparison demo at NAB, pitting AV1, AVC, HEVC and JVET against each other. At the equivalent bitrate of 1.9 Mbps they got the following results: Codec -- PSNR -- VMAF AVC -- 32.7 -- 58 HEVC -- 36.7 -- 80 AV1 -- 37.2 -- 83 JVET -- 38.5 -- 88