6 ms·

H.264

117 points by mmozeiko 11y ago

andreasley 11y ago
It's good to see that libvpx and x265 are moving forward. However, not mentioned is that a higher bitrate doesn't necessarily correlate with higher perceptual quality. Additionally, part of H.264's appeal is its widespread hardware support, which enables features like smartphones with 4K video recording.
- vetinari 11y ago
  Nowadays, smartphone SoCs support both VP9 decoding and encoding in hardware. They have been supporting the same for VP8 for a while.
  - andreasley 11y ago
    On the desktop: Nvidia added full hardware acceleration support for HEVC and VP9 in their GM206 GPU only this year. Intel has partial hardware acceleration for both codecs since this year as well, as does AMD. But: Only for decoding. On mobile, there are some SoCs that can do HEVC and VP9 decoding in 4K in hardware (like Nvidia's Tegra X1), but the large majority of smartphones does not yet have this capability. Encoding is a different story altogether. And iPhones will only do H.264 anyway for the foreseeable future. I'm a strong proponent of open standards and I'm really looking forward to VP9 and HEVC, but it will be a while before they'll have good hardware acceleration on all platforms.
    - fithisux 11y ago
      We shouldn't depend on HW implementations. Instead OpenCL (possibly/hopefully with a DSP profile should suffice).
      - Narishma 11y ago
        OpenCL and other GPU implementations of codecs are not as efficient in terms of power consumption as dedicated hardware.
        astrange 11y ago
        OpenCL implementations of codecs aren't even as efficient as CPU implementations. Just because there's some pixels in there doesn't make it a good fit. They are entirely useless.
    - leonatan 11y ago
      HEVC is not an open standard. It has, arguably, even worse/strict license model.
      - simoncion 11y ago
        Not to mention -when last I checked- multiple, competing patent pools, each with its own licensing terms! >:D
      - acdha 11y ago
        “open standard” just means is that there's a spec which you could use to produce a compatible encoder or decoder. It doesn't mean that no country in the world has issued a patent which could conceivably affect your ability to sell a product. The other thing to remember is that most companies find the presence of a licensing model reassuring because you know the costs up front, as opposed to finding out when someone sues after you've shipped millions of units. That's one of the reasons why VP8 never posed a threat to H.264 – it was almost certain to get bogged down in lawsuits if it became popular – and why HEVC Advance is arguably the biggest threat to H.265 since it removes that comfort zone.
        Silhouette 11y ago
        “open standard” just means is that there's a spec which you could use to produce a compatible encoder or decoder. A published standard has that advantage, but I think when most people talk about "open standards" they are implying a standard that can freely be implemented, in much the same way that for example Open Source software implies more than mere visibility of the source code.
        acdha 11y ago
        “most” people in certain communities: if you poll open source developers, that's probably true but almost everything you use has components covered by ISO/IETF/ITU-T/etc. standards which do allow licensing at varying levels and all of those people also strongly feel that they work on "open standards” as well. > in much the same way that for example Open Source software implies more than mere visibility of the source code. This has a very similar problem: public domain != BSD != Apache != GPL, etc. Depending on who you talk to, only some of those are true open source licenses. In both cases, the term is too vague to be useful for this level of fine-parsing and you have to talk in more detail about the aspects which you're specifically referring to rather than using a broad term.
  - threeseed 11y ago
    Smartphones are not the only hardware that uses codecs. There are computers, consoles, handhelds, DSLRs, video cameras, security cameras etc. When you actually look at hardware in its totality VP9 has been completely irrelevant. And from my perspective a ubiquitous codec is infinitely more valuable than an open one.
- IshKebab 11y ago
  Err it is mentioned - there is even a graph of SSIM vs bitrate showing it.
  - andreasley 11y ago
    You're absolutely right. My bad.
acqq 11y ago
The worrying part is "x265 is still too slow to be useful in most practical scenarios" and "if your CPU usage target for x264 is anything faster than veryslow, you basically want to keep using x264, since at that same CPU usage target, x265 will give worse quality for the same bitrate than x264." That can mean that there's a real danger that we'll get a lot of worse content in the future, as those who encode may go to use a bigger-number codec because it's assumed to be better (hey, it's newer!) Most of people never encode with different codecs every material just to compare the actual quality.
- leonatan 11y ago
  I'm pretty sure x265 is just not mature enough. Same thing happened with x264, where it had many issues and bugs. We all know how these fared in the long run.
  - fithisux 11y ago
    Moreover consortium depends on GPU implementations to be available.
- IshKebab 11y ago
  99% of video is encode-one decode-lots. In that case encoding speed doesn't matter much. It's only for streaming (videocalls, screen mirroring, VNC) that you really need fast encoding.
  - feulix 11y ago
    > In that case encoding speed doesn't matter much When occasionally encoding: yes. When your daily business is encoding larger batches: not necessarily. edit: Just to clarify: we've got an encoding farm which will have to be siginficantly expanded if a substantial amount of content will have to be transcoded in H.265.
    - ZeroGravitas 11y ago
      And if you need to have a h.264 fallback anyway, then any alternative codec starts at a disadvantage, as it can only have marginal gains in return for the extra encoding.
espadrine 11y ago
Encoding speed is a real concern for some applications. Think about Chromoting (Chrome Remote Desktop). They send VP9 video. If they cannot encode it at 60Hz (15ms per frame), it will look choppy. (I quickly looked into it yesterday: https://twitter.com/espadrine/status/648158704420941825 https://twitter.com/espadrine/status/648158704420941825)
- simoncion 11y ago
  I 110% understand the appeal of 60+fps encoding, and the requirement to do so for certain applications. However, I'm reminded of all of the very useful work I and my colleagues were able to do while using Remote Desktop or VNC over a 56kbit/s or 128kbit/s connection. Choppy remoting is far from a dealbreaker for folks who need to get things done. :)
- lbenes 11y ago
  Chrome has done so much right, why did they develop a case of NIHS with this? I've RDP'd to machine IN CHINA with better performance than I got connecting my uncle across town. The devs that came up with the harebrained idea, should be forced use it with a standard $299 chromebook, not their dev Pixel. Normal chrombooks are way too under powered for this.
- Scaevolus 11y ago
  Google Hangouts uses VP9 for HD video chat, and it's noticeably power-hungry and laggy as well.
mrb 11y ago
Wow, my VP9 vs H.264 takeaways are: - for encoding: libvpx always matches or surpasses the quality of x264 (at a given bitrate or at a given CPU budget), because the red line (libvpx) is always on or above the blue line (x264) here: https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-encoding-speed-1024x752.png https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-... (Except there is no libvpx data for CPU budget under ~0.2 SPF —which is a bit annoying, I know for one I do most of my encodings spending around 0.05-0.15 seconds per frame.) - for single-threaded decoding: ffvp9 is faster than ffh264 - for multi-threaded decoding: ffvp9 is a bit slower than ffh264 On top of that, the VP9 implementations are bound to become faster (whereas not much more improvement can be made to already-mature H.264 implementations), so VP9 is bound to become even more preferable over H.264 over time. I think the author's first concluding bullet point ("next-gen codecs provide 50% bitrate improvements over x264, but are 10-20x as slow") is poorly worded. Sure, you can make the next-gen codecs ultra slow by using the highest quality settings, but for libvpx you should choose less agressive settings, and you will still beat the quality of x264 at the same CPU cost. Edit: in addition, these benchmarks show that as of today out of all these implementations, VP9 even matches or beats HEVC on all aspects (encoding at a given bitrate, encoding at a given CPU budget, single- and multi-threaded decoding). But I expect this to change as HEVC implementations are all quite still immature.
- izacus 11y ago
  You just need to remember that in terms of decoding and encoding complexity, VP9 is in the same range as H.265, not H.264. You might as well compare MPEG-4 Part 2 codecs (known under names like DivX, Xvid or whatnot) with H.264.
- clouddrover 11y ago
  VP9 implementations probably won't become all that much faster over time purely because the current development focus is the next-nextgen video codec that is under development via NetVC (https://datatracker.ietf.org/wg/netvc/charter/ https://datatracker.ietf.org/wg/netvc/charter/) and the Alliance for Open Media (http://aomedia.org/ http://aomedia.org/). The codec will be built from the best features of Daala (http://xiph.org/daala/ http://xiph.org/daala/), Thor (https://github.com/cisco/thor https://github.com/cisco/thor) and VP10. Their rough release date is for early 2017.
ris 11y ago
I think things are about to get a lot more interesting between these two since Microsoft announced support for VP9.
ZeroGravitas 11y ago
Another HEVC encoder comparison (which also includes x264 and VP9) is due to be released in a couple of days: http://compression.ru/video/codec_comparison/call_for_codecs_15.html http://compression.ru/video/codec_comparison/call_for_codecs... One of the results that's already leaked shows VP9 ahead of all the HEVC encoders except for x265, which it trails by a couple of percentage points.

117 points by mmozeiko 11y ago

It's good to see that libvpx and x265 are moving forward. However, not mentioned is that a higher bitrate doesn't necessarily correlate with higher perceptual quality. Additionally, part of H.264's appeal is its widespread hardware support, which enables features like smartphones with 4K video recording.

vetinari 11y ago
Nowadays, smartphone SoCs support both VP9 decoding and encoding in hardware. They have been supporting the same for VP8 for a while.
- andreasley 11y ago
  On the desktop: Nvidia added full hardware acceleration support for HEVC and VP9 in their GM206 GPU only this year. Intel has partial hardware acceleration for both codecs since this year as well, as does AMD. But: Only for decoding. On mobile, there are some SoCs that can do HEVC and VP9 decoding in 4K in hardware (like Nvidia's Tegra X1), but the large majority of smartphones does not yet have this capability. Encoding is a different story altogether. And iPhones will only do H.264 anyway for the foreseeable future. I'm a strong proponent of open standards and I'm really looking forward to VP9 and HEVC, but it will be a while before they'll have good hardware acceleration on all platforms.
  - fithisux 11y ago
    We shouldn't depend on HW implementations. Instead OpenCL (possibly/hopefully with a DSP profile should suffice).
    - Narishma 11y ago
      OpenCL and other GPU implementations of codecs are not as efficient in terms of power consumption as dedicated hardware.
      - astrange 11y ago
        OpenCL implementations of codecs aren't even as efficient as CPU implementations. Just because there's some pixels in there doesn't make it a good fit. They are entirely useless.
  - leonatan 11y ago
    HEVC is not an open standard. It has, arguably, even worse/strict license model.
    - simoncion 11y ago
      Not to mention -when last I checked- multiple, competing patent pools, each with its own licensing terms! >:D
    - acdha 11y ago
      “open standard” just means is that there's a spec which you could use to produce a compatible encoder or decoder. It doesn't mean that no country in the world has issued a patent which could conceivably affect your ability to sell a product. The other thing to remember is that most companies find the presence of a licensing model reassuring because you know the costs up front, as opposed to finding out when someone sues after you've shipped millions of units. That's one of the reasons why VP8 never posed a threat to H.264 – it was almost certain to get bogged down in lawsuits if it became popular – and why HEVC Advance is arguably the biggest threat to H.265 since it removes that comfort zone.
      - Silhouette 11y ago
        “open standard” just means is that there's a spec which you could use to produce a compatible encoder or decoder. A published standard has that advantage, but I think when most people talk about "open standards" they are implying a standard that can freely be implemented, in much the same way that for example Open Source software implies more than mere visibility of the source code.
        acdha 11y ago
        “most” people in certain communities: if you poll open source developers, that's probably true but almost everything you use has components covered by ISO/IETF/ITU-T/etc. standards which do allow licensing at varying levels and all of those people also strongly feel that they work on "open standards” as well. > in much the same way that for example Open Source software implies more than mere visibility of the source code. This has a very similar problem: public domain != BSD != Apache != GPL, etc. Depending on who you talk to, only some of those are true open source licenses. In both cases, the term is too vague to be useful for this level of fine-parsing and you have to talk in more detail about the aspects which you're specifically referring to rather than using a broad term.
- threeseed 11y ago
  Smartphones are not the only hardware that uses codecs. There are computers, consoles, handhelds, DSLRs, video cameras, security cameras etc. When you actually look at hardware in its totality VP9 has been completely irrelevant. And from my perspective a ubiquitous codec is infinitely more valuable than an open one.
IshKebab 11y ago
Err it is mentioned - there is even a graph of SSIM vs bitrate showing it.
- andreasley 11y ago
  You're absolutely right. My bad.

acqq 11y ago

The worrying part is "x265 is still too slow to be useful in most practical scenarios" and "if your CPU usage target for x264 is anything faster than veryslow, you basically want to keep using x264, since at that same CPU usage target, x265 will give worse quality for the same bitrate than x264." That can mean that there's a real danger that we'll get a lot of worse content in the future, as those who encode may go to use a bigger-number codec because it's assumed to be better (hey, it's newer!) Most of people never encode with different codecs every material just to compare the actual quality.

leonatan 11y ago
I'm pretty sure x265 is just not mature enough. Same thing happened with x264, where it had many issues and bugs. We all know how these fared in the long run.
- fithisux 11y ago
  Moreover consortium depends on GPU implementations to be available.
IshKebab 11y ago
99% of video is encode-one decode-lots. In that case encoding speed doesn't matter much. It's only for streaming (videocalls, screen mirroring, VNC) that you really need fast encoding.
- feulix 11y ago
  > In that case encoding speed doesn't matter much When occasionally encoding: yes. When your daily business is encoding larger batches: not necessarily. edit: Just to clarify: we've got an encoding farm which will have to be siginficantly expanded if a substantial amount of content will have to be transcoded in H.265.
  - ZeroGravitas 11y ago
    And if you need to have a h.264 fallback anyway, then any alternative codec starts at a disadvantage, as it can only have marginal gains in return for the extra encoding.

espadrine 11y ago

Encoding speed is a real concern for some applications. Think about Chromoting (Chrome Remote Desktop). They send VP9 video. If they cannot encode it at 60Hz (15ms per frame), it will look choppy. (I quickly looked into it yesterday: https://twitter.com/espadrine/status/648158704420941825 https://twitter.com/espadrine/status/648158704420941825)

simoncion 11y ago
I 110% understand the appeal of 60+fps encoding, and the requirement to do so for certain applications. However, I'm reminded of all of the very useful work I and my colleagues were able to do while using Remote Desktop or VNC over a 56kbit/s or 128kbit/s connection. Choppy remoting is far from a dealbreaker for folks who need to get things done. :)
lbenes 11y ago
Chrome has done so much right, why did they develop a case of NIHS with this? I've RDP'd to machine IN CHINA with better performance than I got connecting my uncle across town. The devs that came up with the harebrained idea, should be forced use it with a standard $299 chromebook, not their dev Pixel. Normal chrombooks are way too under powered for this.
Scaevolus 11y ago
Google Hangouts uses VP9 for HD video chat, and it's noticeably power-hungry and laggy as well.

mrb 11y ago

Wow, my VP9 vs H.264 takeaways are: - for encoding: libvpx always matches or surpasses the quality of x264 (at a given bitrate or at a given CPU budget), because the red line (libvpx) is always on or above the blue line (x264) here: https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-encoding-speed-1024x752.png https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-... (Except there is no libvpx data for CPU budget under ~0.2 SPF —which is a bit annoying, I know for one I do most of my encodings spending around 0.05-0.15 seconds per frame.) - for single-threaded decoding: ffvp9 is faster than ffh264 - for multi-threaded decoding: ffvp9 is a bit slower than ffh264 On top of that, the VP9 implementations are bound to become faster (whereas not much more improvement can be made to already-mature H.264 implementations), so VP9 is bound to become even more preferable over H.264 over time. I think the author's first concluding bullet point ("next-gen codecs provide 50% bitrate improvements over x264, but are 10-20x as slow") is poorly worded. Sure, you can make the next-gen codecs ultra slow by using the highest quality settings, but for libvpx you should choose less agressive settings, and you will still beat the quality of x264 at the same CPU cost. Edit: in addition, these benchmarks show that as of today out of all these implementations, VP9 even matches or beats HEVC on all aspects (encoding at a given bitrate, encoding at a given CPU budget, single- and multi-threaded decoding). But I expect this to change as HEVC implementations are all quite still immature.

izacus 11y ago
You just need to remember that in terms of decoding and encoding complexity, VP9 is in the same range as H.265, not H.264. You might as well compare MPEG-4 Part 2 codecs (known under names like DivX, Xvid or whatnot) with H.264.
clouddrover 11y ago
VP9 implementations probably won't become all that much faster over time purely because the current development focus is the next-nextgen video codec that is under development via NetVC (https://datatracker.ietf.org/wg/netvc/charter/ https://datatracker.ietf.org/wg/netvc/charter/) and the Alliance for Open Media (http://aomedia.org/ http://aomedia.org/). The codec will be built from the best features of Daala (http://xiph.org/daala/ http://xiph.org/daala/), Thor (https://github.com/cisco/thor https://github.com/cisco/thor) and VP10. Their rough release date is for early 2017.

ris 11y ago

I think things are about to get a lot more interesting between these two since Microsoft announced support for VP9.

ZeroGravitas 11y ago

Another HEVC encoder comparison (which also includes x264 and VP9) is due to be released in a couple of days: http://compression.ru/video/codec_comparison/call_for_codecs_15.html http://compression.ru/video/codec_comparison/call_for_codecs... One of the results that's already leaked shows VP9 ahead of all the HEVC encoders except for x265, which it trails by a couple of percentage points.