5 ms·

i wonder how many orders of magnitude slower this one will be compared to x264. vp8/9 was like 9x slower last time i checked

by yjm 11y ago

TD-Linux 11y ago
It is currently quite a bit slower, but the goal is to make a codec fast enough for real time communication use. VP9 is still about 9x slower than x264, but yields the same quality at half the bitrate. You can set VP9 to run a lot faster, but you'll lose some of the bitrate advantages. Still, VP9 is practical for a lot of applications, such as Youtube.
- bitmapbrother 11y ago
  VP9 being 9x slower than x264 is hard to believe. Do you have a citation?
  - Sir_Cmpwn 11y ago
    I can anecdotally agree with him. I ran a service that did a lot of media encoding and VP9 is very, very slow to encode.
    - DarkLinkXXXX 11y ago
      Could that be due to lack of hardware support?
      - TD-Linux 11y ago
        No, generally encoding is done in software. It's just because VP9 is a much more complex format with many more different coding possibilities to search. It also hasn't been around as long as x264 to be hyper-optimized.
      - astrange 11y ago
        There are probably some issues with missing SIMD, but no further hardware support would be helpful. It's purely an implementation issue - you don't get software as good as x264 just by paying for it.
      - mappu 11y ago
        Comparing x264 to hardware-accelerated encoders (QuickSync, NVENC, VCE), the speed/quality/bitrate tradeoff is massively in favour of the cpu-only x264. So i think hardware encoding could help VP9, but it's not a magic bullet (unless your CPU is busy with other work simultaneously).
  - mappu 11y ago
    "VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. ... libvpx multithreading [encoding] performance is deplorable. It gains virtually nothing."[1] 1. https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes... n.b. x264 comparisons were taken with `--preset veryslow` which understates x264's potential performance by an order of magnitude. From the same link: "it can be fast, and it can beat x264, but it can’t do both at the same time."
    - TD-Linux 11y ago
      This is old. libvpx 1.4.0 is a lot faster now and has multithreading. On my i7-4900MQ laptop, I get about 3fps encoding 1080p content. Still very slow, but 24 minutes for a 3 minute clip, not days.
- mappu 11y ago
  VP9 producing the same quality as x264 at half the bitrate is hard to believe. Do you have a citation? Which `--preset` for x264 are you basing this on?
  - TD-Linux 11y ago
    It's based on --best for VP9 1.4.0 and placebo for x264. Generally improvement tends to be from 30-50%, based on the quality target and content (the lower the bitrate, the greater the improvement). I have objective metrics which test this at http://arewecompressedyet.com/ http://arewecompressedyet.com/. If you're more of a visual person, you can take a look at some images here, compressed to 60KB: https://people.xiph.org/~tdaede/pcs2015_vp9_vs_x264/0.25/ https://people.xiph.org/~tdaede/pcs2015_vp9_vs_x264/0.25/ Certainly libvpx still has a lot of optimization and tuning work left to do. But there's only so much x264 can do with a 15 year old bitstream format.
    - aw3c2 11y ago
      Those example images are of really low quality video. Usually people who care about image quality do not care about that. Can you show some ~720p 5mb/s x264 versus 3-4mb/s VP9 samples?
      - indolering 11y ago
        Low resolution samples are the norm, I think it's because low resolution makes it so you can see how the compression algorithm works. If you a high resolution comparison, you would need to zoom in to see the difference anyway. There are, of course, compression artifacts that are readily apparent even in high-resolution (chain link fences, transparent wipes, etc) but I suspect that they are in the minority.

i wonder how many orders of magnitude slower this one will be compared to x264. vp8/9 was like 9x slower last time i checked

by yjm 11y ago

i wonder how many orders of magnitude slower this one will be compared to x264. vp8/9 was like 9x slower last time i checked

TD-Linux 11y ago

It is currently quite a bit slower, but the goal is to make a codec fast enough for real time communication use. VP9 is still about 9x slower than x264, but yields the same quality at half the bitrate. You can set VP9 to run a lot faster, but you'll lose some of the bitrate advantages. Still, VP9 is practical for a lot of applications, such as Youtube.

bitmapbrother 11y ago
VP9 being 9x slower than x264 is hard to believe. Do you have a citation?
- Sir_Cmpwn 11y ago
  I can anecdotally agree with him. I ran a service that did a lot of media encoding and VP9 is very, very slow to encode.
  - DarkLinkXXXX 11y ago
    Could that be due to lack of hardware support?
    - TD-Linux 11y ago
      No, generally encoding is done in software. It's just because VP9 is a much more complex format with many more different coding possibilities to search. It also hasn't been around as long as x264 to be hyper-optimized.
    - astrange 11y ago
      There are probably some issues with missing SIMD, but no further hardware support would be helpful. It's purely an implementation issue - you don't get software as good as x264 just by paying for it.
    - mappu 11y ago
      Comparing x264 to hardware-accelerated encoders (QuickSync, NVENC, VCE), the speed/quality/bitrate tradeoff is massively in favour of the cpu-only x264. So i think hardware encoding could help VP9, but it's not a magic bullet (unless your CPU is busy with other work simultaneously).
- mappu 11y ago
  "VP9 encoding (using libvpx) is horrendously slow – like, 50x slower than VP8/x264 encoding. This means that encoding a 3-minute 1080p clip takes several days on a high-end machine. ... libvpx multithreading [encoding] performance is deplorable. It gains virtually nothing."[1] 1. https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastest-vp9-decoder-ffvp9/ https://blogs.gnome.org/rbultje/2014/02/22/the-worlds-fastes... n.b. x264 comparisons were taken with `--preset veryslow` which understates x264's potential performance by an order of magnitude. From the same link: "it can be fast, and it can beat x264, but it can’t do both at the same time."
  - TD-Linux 11y ago
    This is old. libvpx 1.4.0 is a lot faster now and has multithreading. On my i7-4900MQ laptop, I get about 3fps encoding 1080p content. Still very slow, but 24 minutes for a 3 minute clip, not days.
mappu 11y ago
VP9 producing the same quality as x264 at half the bitrate is hard to believe. Do you have a citation? Which `--preset` for x264 are you basing this on?
- TD-Linux 11y ago
  It's based on --best for VP9 1.4.0 and placebo for x264. Generally improvement tends to be from 30-50%, based on the quality target and content (the lower the bitrate, the greater the improvement). I have objective metrics which test this at http://arewecompressedyet.com/ http://arewecompressedyet.com/. If you're more of a visual person, you can take a look at some images here, compressed to 60KB: https://people.xiph.org/~tdaede/pcs2015_vp9_vs_x264/0.25/ https://people.xiph.org/~tdaede/pcs2015_vp9_vs_x264/0.25/ Certainly libvpx still has a lot of optimization and tuning work left to do. But there's only so much x264 can do with a 15 year old bitstream format.
  - aw3c2 11y ago
    Those example images are of really low quality video. Usually people who care about image quality do not care about that. Can you show some ~720p 5mb/s x264 versus 3-4mb/s VP9 samples?
    - indolering 11y ago
      Low resolution samples are the norm, I think it's because low resolution makes it so you can see how the compression algorithm works. If you a high resolution comparison, you would need to zoom in to see the difference anyway. There are, of course, compression artifacts that are readily apparent even in high-resolution (chain link fences, transparent wipes, etc) but I suspect that they are in the minority.