15 ms·

VP9 vs H264 vs H265: - Next-gen codecs provide 50% bitrate improvements over x264, but are 10-20x as slow at the top settings required to accomplish such resul

by ju-st 11y ago

VP9 vs H264 vs H265: - Next-gen codecs provide 50% bitrate improvements over x264, but are 10-20x as slow at the top settings required to accomplish such results. - Normalized for CPU usage, libvpx already has some selling points when compared to x264; x265 is still too slow to be useful in most practical scenarios except in very high-end scenarios. - ffvp9 is an incredibly awesome decoder that outperforms all other decoders. https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/ https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecod...

Veratyr 11y ago
ffvp9 is indeed awesome. There was a talk at VideoLan Dev Days about the development. They outperform the reference decoder and optimized basically everything they could touch.
keithwinstein 11y ago
One downside of VP9: the VP9 spec is still under NDA from Google. There is no publicly available spec. As far as I know, the only people that have written a software VP9 decoder are either Google employees (libvpx) or ex-Google-employees who worked on VP9 when they were there (rbultje, who wrote ffvp9 with Clément Bœsch).
- DannyBee 11y ago
  Which "spec" are you referring to? The bitstream spec is definitely public.
  - TD-Linux 11y ago
    I have never seen a spec, do you have a link?
    - nickodell 11y ago
      This, perhaps? https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 It's only a draft, and two years out of date, but it is public.
      - TD-Linux 11y ago
        It's a good overview of VP9, but it's certainly not enough to implement a decoder, or call it a "spec".
  - mrb 11y ago
    I could only find an "overview", not a full spec: https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00
  - Ace17 11y ago
    There's a public RFC, but it's by no means usable as a bitstream spec. There's an official text document describing the bitstream format (several hundreds pages), but it's under NDA. We use it at work, and getting an updated version is far more trouble than downloading a file on a public server. The document in itself is nearly worthless, though, as it's far from complete. In the end, you still need to dig into libvpx to understand how things work.
- jimbankoski 11y ago
  Lots of people have produced decoders for vp9 including both hardware and software vendors. Including companies like ittiam, Intel, samsung and qualcomm. Lack of a non NDA public spec may have made things more difficult for some but it certainly didn't stop everyone.
  - deleted 11y ago
    [deleted]
  - Ace17 11y ago
    Actually, as a decoder implementer, I found that having the C source code of a reference decoder (libvpx), whose behaviour is authoritative over any text document, actually made things a lot more easy. Because now, whenever you ask yourself "how should a VP9 decoder behave in this situation?", you have a non-ambiguous answer "do like libvpx does". We didn't have this luxury with HEVC. The HEVC reference decoder (HM) is horribly complex, and has been easy to crash in many different ways for years. As a consequence, it could by no means be considered as authoritative. Which is a pity, because there were a lot of discrepancies between the reference decoder and the .doc spec.
- tagrun 11y ago
  http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP9-Encoder http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP...
acdha 11y ago
> ffvp9 is an incredibly awesome decoder that outperforms all other decoders. Not to take away from the hard work which has gone into ffvp9 but that should be “all other open-source decoders” without benchmarks comparing it against the proprietary implementations which most people actually use. ffvp9 be great but still the wrong choice if someone has a hardware/GPU-accelerated H.265 codec in their OS and would prefer longer battery life to use of free software.
- microcolonel 11y ago
  Intel platform seems to have a VP9 decoder built in. Not sure about others.
  - cpeterso 11y ago
    Firefox added support for Intel's VP9 hardware decoder, but had to disable it because of Intel bugs and hardware performance was often worse the available software decoders! https://bugzil.la/1225019 https://bugzil.la/1225019
cpeterso 11y ago
Mozilla plans to ship ffvp9 in Firefox 46 (now in Nightly channel): https://bugzil.la/ffvp9 https://bugzil.la/ffvp9
cat-dev-null 11y ago
This seems like an opportunity for hardware acceleration (CPU/GPU instructions / x265 accelerator) to reduce the power consumption on video playback for the majority of devices. Perhaps it's cheaper and simpler to make a co(+)dec chip that can encode too.
- dogma1138 11y ago
  NVIDIA currently supports HEVC decoding on it's GTX 900 (and 750ti/se as they are also Maxwell) GPU's. iPhone 6s has h265 decoding also (works with Plex without transcoding flawlessly). Qalcomm has support for HEVC through all of it's latest generations 200 (2xx, 4xx, 6xx all) through 800 (808 onward) series of SOC's. I have not had issues playing 1080 x265 content videos on any of my mobile devices past 18 months or so since they've started releasing them. There's just something to be said about 200-300MB per 1080p episode and about 700MB per movie. Can cram an entire library to most of my current mobile devices for a flight/long commute without having to worry about SD cards/USB OTG.
threeseed 11y ago
Am I missing something or is that article's conclusions pretty disingenuous. Then again the author did work for Google on VP9 so am not totally surprised. Yes H.265 encoding speed is 10-20x slower (at the highest quality setting) but the decoding speed was only 20% slower than H.264. And it is still quite faster than 60fps below which almost all movie content exists. If all that mattered in a codec was encoding speed VP9 would be dominant. But it isn't. It's largely irrelevant compared to decoding speed (majority of codec users) and device support. The latter which H.265 is in an unassailable position.
- spb 11y ago
  Encoding speed is very relevant for real-time feeds like WebRTC and Twitch.
  - HappyTypist 11y ago
    Good point, actually. VP9 appears to be superior for consumer real time feeds (ie not 1 million streamers backed by datacenters)
dogma1138 11y ago
For decoding CPU usage comparison is pretty pointless since every relevant device will have hardware decoding. And encoding speed really only matters as far as real time services go like streaming services.

by ju-st 11y ago

Veratyr 11y ago

ffvp9 is indeed awesome. There was a talk at VideoLan Dev Days about the development. They outperform the reference decoder and optimized basically everything they could touch.

keithwinstein 11y ago

One downside of VP9: the VP9 spec is still under NDA from Google. There is no publicly available spec. As far as I know, the only people that have written a software VP9 decoder are either Google employees (libvpx) or ex-Google-employees who worked on VP9 when they were there (rbultje, who wrote ffvp9 with Clément Bœsch).

DannyBee 11y ago
Which "spec" are you referring to? The bitstream spec is definitely public.
- TD-Linux 11y ago
  I have never seen a spec, do you have a link?
  - nickodell 11y ago
    This, perhaps? https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 It's only a draft, and two years out of date, but it is public.
    - TD-Linux 11y ago
      It's a good overview of VP9, but it's certainly not enough to implement a decoder, or call it a "spec".
- mrb 11y ago
  I could only find an "overview", not a full spec: https://tools.ietf.org/html/draft-grange-vp9-bitstream-00 https://tools.ietf.org/html/draft-grange-vp9-bitstream-00
- Ace17 11y ago
  There's a public RFC, but it's by no means usable as a bitstream spec. There's an official text document describing the bitstream format (several hundreds pages), but it's under NDA. We use it at work, and getting an updated version is far more trouble than downloading a file on a public server. The document in itself is nearly worthless, though, as it's far from complete. In the end, you still need to dig into libvpx to understand how things work.
jimbankoski 11y ago
Lots of people have produced decoders for vp9 including both hardware and software vendors. Including companies like ittiam, Intel, samsung and qualcomm. Lack of a non NDA public spec may have made things more difficult for some but it certainly didn't stop everyone.
- deleted 11y ago
  [deleted]
- Ace17 11y ago
  Actually, as a decoder implementer, I found that having the C source code of a reference decoder (libvpx), whose behaviour is authoritative over any text document, actually made things a lot more easy. Because now, whenever you ask yourself "how should a VP9 decoder behave in this situation?", you have a non-ambiguous answer "do like libvpx does". We didn't have this luxury with HEVC. The HEVC reference decoder (HM) is horribly complex, and has been easy to crash in many different ways for years. As a consequence, it could by no means be considered as authoritative. Which is a pity, because there were a lot of discrepancies between the reference decoder and the .doc spec.
tagrun 11y ago
http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP9-Encoder http://www.phoronix.com/scan.php?page=news_item&px=OpenCL-VP...

acdha 11y ago

> ffvp9 is an incredibly awesome decoder that outperforms all other decoders. Not to take away from the hard work which has gone into ffvp9 but that should be “all other open-source decoders” without benchmarks comparing it against the proprietary implementations which most people actually use. ffvp9 be great but still the wrong choice if someone has a hardware/GPU-accelerated H.265 codec in their OS and would prefer longer battery life to use of free software.

microcolonel 11y ago
Intel platform seems to have a VP9 decoder built in. Not sure about others.
- cpeterso 11y ago
  Firefox added support for Intel's VP9 hardware decoder, but had to disable it because of Intel bugs and hardware performance was often worse the available software decoders! https://bugzil.la/1225019 https://bugzil.la/1225019

cpeterso 11y ago

Mozilla plans to ship ffvp9 in Firefox 46 (now in Nightly channel): https://bugzil.la/ffvp9 https://bugzil.la/ffvp9

cat-dev-null 11y ago

This seems like an opportunity for hardware acceleration (CPU/GPU instructions / x265 accelerator) to reduce the power consumption on video playback for the majority of devices. Perhaps it's cheaper and simpler to make a co(+)dec chip that can encode too.

dogma1138 11y ago
NVIDIA currently supports HEVC decoding on it's GTX 900 (and 750ti/se as they are also Maxwell) GPU's. iPhone 6s has h265 decoding also (works with Plex without transcoding flawlessly). Qalcomm has support for HEVC through all of it's latest generations 200 (2xx, 4xx, 6xx all) through 800 (808 onward) series of SOC's. I have not had issues playing 1080 x265 content videos on any of my mobile devices past 18 months or so since they've started releasing them. There's just something to be said about 200-300MB per 1080p episode and about 700MB per movie. Can cram an entire library to most of my current mobile devices for a flight/long commute without having to worry about SD cards/USB OTG.

threeseed 11y ago

Am I missing something or is that article's conclusions pretty disingenuous. Then again the author did work for Google on VP9 so am not totally surprised. Yes H.265 encoding speed is 10-20x slower (at the highest quality setting) but the decoding speed was only 20% slower than H.264. And it is still quite faster than 60fps below which almost all movie content exists. If all that mattered in a codec was encoding speed VP9 would be dominant. But it isn't. It's largely irrelevant compared to decoding speed (majority of codec users) and device support. The latter which H.265 is in an unassailable position.

spb 11y ago
Encoding speed is very relevant for real-time feeds like WebRTC and Twitch.
- HappyTypist 11y ago
  Good point, actually. VP9 appears to be superior for consumer real time feeds (ie not 1 million streamers backed by datacenters)

dogma1138 11y ago

For decoding CPU usage comparison is pretty pointless since every relevant device will have hardware decoding. And encoding speed really only matters as far as real time services go like streaming services.