7 ms·

H.265 Is Approved

132 points by FreeKill 14y ago

rcthompson 14y ago
So how much better can video formats theoretically get? Are we anywhere near the absolute limit of compression, or are current solutions limited by what can be accomplished in real time on today's hardware?
- ihsw 14y ago
  The Wikipedia article[1] outlines various features of this standard, for instance predictive motion vectors are being utilized more heavily, not unlike actual vector graphics. This is impressive however it requires more CPU (naturally we have more CPU available compared to when H.264 was standardized). With regards to hardware: performance/watt is a commonly touted benchmark for measuring the quality of hardware however architectural changes should be considered as well (ie: today's CPUs do more per Hz than yesterday's CPUs). [1] http://en.wikipedia.org/wiki/H.265 http://en.wikipedia.org/wiki/H.265
- bradleyjg 14y ago
  These are lossy formats, so there aren't clean, easily defined limits like there are for lossless formats.
- BlackAura 14y ago
  We won't know until we get there. Generally, the performance of a video codec is held back by available hardware performance more than anything else. The specifications of a video codec generally specify the decoder, but not the encoder. The decoder specification is intended to be implementable on hardware or software, so it can be played back in real-time, either now or in the immediate future. If some compression technique is available, but can't be done real-time, it can't be used. If a compression technique could be done real-time but only if limits are placed on it, then limits will be placed on it. The encoder has to generate a bitstream that the decoder will decode, so it's limited by the decoder's capabilities. To an extent, it's limited by available algorithms (see how much better a modern h.264 encoder is compared to the original ones), and by encoding performance (particularly if you need to encode in real time, but even offline encoders can only be so slow before they become useless), and the quality / compression performance tends to get better with time. It's still limited mostly by the decoder, though. This example is for audio codecs, but LAME actually generated higher-quality MP3s than all of the first generation of AAC encoders, entirely because it had smarter encoding algorithms. For that matter, XVID tended to produce videos that rivaled, and occasionally surpassed, the first generations of h.264 encoders. Despite that early lead, both LAME and XVID were overtaken once the AAC and h.264 encoders matured, because they were still limited by the decoders they were targetting. There's probably still a long way to go just adding complexity to the decoder, even if we don't invent any new techniques. Eventually, it'll get to the point where you could increase the limits on the decoder, but you'll end up using far more power, and getting no noticeable improvement. So, the limit would be the point when nobody can come up with any new techniques, encoders can perfectly measure perceptual quality (and therefore make perfect decisions about what techniques to use to get the best combination of bitrate vs quality), and improving existing techniques has a high cost and very low return. I don't think we're anywhere near there, yet. Lossless codecs, on the other hand, definitely do have a hard theoretical limit, because they can't discard data like lossy codecs can.
- lmm 14y ago
  We're a long, long, way from the theoretical limit - you can tell by comparing the size of programmatically generated videos (e.g. 3D renderings, or videogame videos) with their source material. A "perfect" video codec would mean they were the same size, but at the moment a 256kb SNES rom and a few hundred bytes of buttonpresses will generate you a video that's easily in the 10s of megabytes (granted video codecs aren't optimized with snes gameplay videos as their primary target).
  - snowwrestler 14y ago
    These are two totally different things. Video codecs do not try to "discover" the equations that created the scene. They take the recorded data of the scene and then try to represent it "well enough" in a smaller number of bits. By analogy: knowing the equation for conservation of momentum does not help you find the smallest way to record the results of 1 million experimental collisions.
    - lmm 14y ago
      >These are two totally different things. Video codecs do not try to "discover" the equations that created the scene. They take the recorded data of the scene and then try to represent it "well enough" in a smaller number of bits. Think of it in information-theory terms (e.g. Kolmogorov complexity). If the scene was created from no more than n bits of data, then it is possible to represent it in n bits, and a "theoretically perfect" video codec would do so. Video codecs really do try and "discover" the simplest representation of a scene (e.g. motion vectors are exactly that), and the things they can "understand" are getting more and more complex as video codecs advance (e.g. film grain).
      - snowwrestler 14y ago
        Let's say you take an algorithm for generating the digits of pi, and run it on 2 computers. One you let run only a short time and it produces a string 100,000 digits long. The other you let run for a longer time and it produces a string one million digits long. Would you argue that these two strings should compress to the same size because the source code that generated each of them is the same size? edit: to clarify my question
Hello71 14y ago
And... patents.
- ihsw 14y ago
  That is an inevitability.
  - azakai 14y ago
    There are open alternatives like Daala. The patented codec won last time (H.264), but history might not repeat itself this time.
    - greyfade 14y ago
      That will depend on who chooses to implement which. If hardware manufacturers choose H.265, VP9 and Daala will be marginalized purely because of performance concerns. If, on the other hand, VP9 or Daala can be implemented in hardware cheaply enough and with good enough electrical characteristics, perhaps OEMs can be persuaded to use it.
      - alexkcd 14y ago
        Sadly, the best compression techniques are fairly obvious and have been patented. The economics of this space have always favored better codecs over licensing concerns. Savings in bandwidth often negate the cost benefits of a free codec. High end video recording/editing tools used by most content creators are expensive, such that a codec license amounts to only a small fraction of the cost. Pirates care about high quality and fast downloads. They don't care about licensing costs for obvious reasons. H.265 merely standardizes on a set of the best known compression techniques that meet certain compression vs processing constraints. It just so happens that most of these techniques are patented. Which in turn is why MPEG-LA exists. This will continue to be true going forward. The only way to make a free codec viable is to fix the patent system. I'm all for patent reform, but as I mentioned elsewhere, I'd much rather discuss h265 tech here, and leave the patent debate for the numerous posts we're sure to continue to see on HN.
ghc 14y ago
H.265 sounds great...but the article doesn't mention the most important point: Is it patent-encumbered? Last time around patents proved a major barrier to adoption in free browsers, so why should this time be any different? A quick wiki check seems to indicate that MPEGLA has patents on H.265, so a GPL3-compliant decoder is probably a no-go, but we don't yet know whether they'll take a more enlightened approach to licensing this time around so that adoption will be cleaner than it was with H.264.
- jws 14y ago
  I hesitate to bring this up, because it may well trigger a barrage of ill informed replies onto the poor overtaxed internet, but… Does GPL-3 have anything to say about third-party patents? Assuming I neither own nor control the sublicensing of any patents, why could I not write an H.265 decoder and place it under GPL-3? (Well not me specifically, but someone who lives in a country free of software patents.) I'm not seeing the problem, except for possibly in section "11. Patents" of the GPL-3 there is this odd paragraph… If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. … which seems to create some sort of obligation if I have reason to believe there exists a country in which the work would infringe a patent. But there are three remedies available, one of which is to publish the source code of the program, which is sort of a non-penalty for a GPL licensed program.
  - crazytony 14y ago
    I believe this section is mostly dealing with companies that create a library, patent it, then create a GPL3 app that uses said library without the intention of opening up the library. Looking at you NVIDIA :). The way I'm reading that is if you build a work that relies on a library covered under patent you must do one of the following: 1. Publish the library as some form of open source (no license specified) 2. Cede the patent to the public domain through some mechanism 3. Grant anyone creating software based on said library a license to the patent free of charge. As the MPEGLA owns the patent and is not shipping code #1 would not be available and #2 and #3 would not be applicable to a 3rd party developing code because they don't own the patent. IANAL but that seems to be the way that clause was intended.
jbk 14y ago
> The new video format is the successor to the H.264 codec, which nearly every video publisher has standardized after the release of the iPad and several other connected devices. No. H.264 was already used by HD-DVD, Blu-Ray, DVB (since 2004) and AVCHD. > It seems crazy now, but once upon a time, Apple’s adoption of H.264 and insistence on HTML5-based video players was controversial — especially since most video before the iPad was encoded in VP6 to play through Adobe’s proprietary Flash player. No. Most professional videos were using MPEG-2 and pirated movies were using Mpeg-4 part 2 (DivX, Xvid). Seriously, Apple can do great things, but this TC sensationalism is boring and inaccurate. Besides that, it is great to finally have H.265 ready. We'll see the fight with VP9 and Daala very soon.
- wmf 14y ago
  I think when TechCruch says publisher they mean Web site. If you really think about it, the Web is the entire universe.
  - nolok 14y ago
    > If you really think about it, the Web is the entire universe _their_ entire universe
- deleted 14y ago
  [deleted]
- taligent 14y ago
  >We'll see the fight with VP9 and Daala very soon. Let's be realistic here. Nobody particularly cared what Google or Mozilla were doing before and there is nothing to suggest it is going to change now. It wouldn't be a close fight with just Apple but against all the MPEG companies I don't even know why they bother.
- TheCondor 14y ago
  Hddvd and bluray use vc1
  - DiabloD3 14y ago
benwerd 14y ago
h.265 is exciting. It takes into account the vastly improved processing power of today's devices to create smaller files - I'm looking forward to integrating it with our service, which in turn will put h.265 in easy reach of broadcasters. Really great step forward for the industry, although, of course, I wish it was an open standard.
- pkulak 14y ago
  1080p H.264 can just now be played back on modern processors without hardware acceleration. I shutter to think about playing back 2160p H.265 before anyone builds hardware support. I'm sure you don't get "twice as efficient" without making it about twice as difficult to decode. Or maybe 4 times...
modeless 14y ago
VP9 is also under development. VP9 decoding support was recently added to Chromium. http://src.chromium.org/viewvc/chrome?view=rev&revision=172738 http://src.chromium.org/viewvc/chrome?view=rev&revision=... http://en.wikipedia.org/wiki/VP9 http://en.wikipedia.org/wiki/VP9
- kristofferR 14y ago
  Unless VP9 decoding is implemented in hardware chips like H.264 is and H.265 is going to be, it'll likely fail. It sucks, but I'd much rather have a "non-free" codec that plays smoothly on all my devices than a "free" codec with lag issues on everything but my computer. Try playing 1080P H264 videos on your tablet/phone without using the H264 hardware decoder and you'll know what I mean. Decoding H265 and VP9 will likely be even more resource intensive than decoding H264 already is And really, does the closedness of H264/H265 really matter at all for the end users? x264 seems pretty free to me, what is the difference in reality?
  - modeless 14y ago
    Hardware support for VP8 exists, though it's not widespread as of yet. Tegra 3 has it. http://www.nvidia.com/object/tegra-3-processor.html http://www.nvidia.com/object/tegra-3-processor.html As with most software, the closedness of H.26X matters a lot more to developers than users.
    - wmf 14y ago
      I think the last developer who cared was Firefox and even they gave up.
      - gillianseed 14y ago
        Firefox has native vp8/webm support. I know as I use it when I visit Youtube pretty much everyday and watch webm (vp8) videos. I don't have flash installed.
        14y ago
nextstep 14y ago
So when can we expect this to be supported in VLC?
- jbk 14y ago
  As soon as there is a GPLv2 compatible decoder available? See https://github.com/smarter/libav/commits/hevc https://github.com/smarter/libav/commits/hevc
ComputerGuru 14y ago
I'm just waiting for DarkShikari [1] to post in this thread :) Reading his codec-related comments on HN is always such a wonderful and humbling learning experience. I look forward to his take on the h265 spec and the changes (both advantages and disadvantages, as there are bound to be both) over h264. 1: http://news.ycombinator.com/user?id=DarkShikari http://news.ycombinator.com/user?id=DarkShikari
- wmf 14y ago
  And many of us are wondering if he's working on x265.
nextparadigms 14y ago
I'm confident VP9 has a much better chance of succeeding this time around. h264 was already widely supported before Apple decided to promote it against Flash. That's not the case with h.265 right now. It will have to start from scratch, which gives VP9 a much larger window of opportunity. This is from November, where they posted they are about 7% behind h.265/HVEC: https://www.ietf.org/proceedings/85/slides/slides-85-videocodec-4.pdf https://www.ietf.org/proceedings/85/slides/slides-85-videoco... I've also seen in another document I can't find right now them saying that work on h.265 started in 2005, while work on VP9 started in 2011...and they are already pretty close to matching it, and they are gaining 10% on it every quarter. If that's true it should be at least as efficient or more within a quarter or two, than h.265. Then it will be just a question of adoption. Software adoption should be much easier. Many have already implemented VP8 (which is also slightly better than h.264 at this point - [1]), and I'm sure Google will use VP9 for HD Hangouts, and for Youtube. This time I hope they go through with their promise and make it the default codec for Youtube, with fallback to Flash for browsers not supporting it (only about 20% of the users are not supporting VP8 right now, for reference [2]). That should encourage adoption by other video sites, and also chip makers. And that's I think the biggest hurdle - getting chip makers to support VP9. But now with Android's popularity and virtually every chip maker supporting Android, I think it will be much easier than it was to get support for VP8. The nice part about VP9 is that it will also come integrated with the Opus codec inside WebM, and that should be a big factor in the adoption of WebM, too. [1] http://pacoup.com/2012/12/20/vp8-webm-vs-h-264-mp4-december-2012/ http://pacoup.com/2012/12/20/vp8-webm-vs-h-264-mp4-december-... [2] http://downloads.webmproject.org/ngov2012/pdf/03-ngov-vp8-update.pdf http://downloads.webmproject.org/ngov2012/pdf/03-ngov-vp8-up...
- doublec 14y ago
  Integrating Opus and/or VP9 into WebM removes one of the selling points they used to promote the format. WebM wasn't supposed to be a generic container format holding different codecs. It was specifically tied to Vorbis/VP8 to ensure everyone advertising WebM support would be able to play the files. If they decide to add these additional codecs then there will be some players that can play some WebM files but not others. If that was the direction they wanted to head then they could have just stuck with Matroska for the container format.
ksec 14y ago
Few Points. 1. To the Post above on VP8 better then x264. Comparing a single frame, single video, single....? isn't very detail. VP8 has improved A LOT!. That is true. But as far as i am concern and many other video encoder it is also true that it hasn't match x264 yet. 2. VP9 is great! It has matched and in many case even exceed x264 quality. Although there would still be areas where x264 perform better simply because it is much more mature. 3. So given more time VP9 will very likely beat x264 quality. It is only with 10% range of HEVC / h.265 JM, under benchmarks. So it will very likely beat that too. 4. Do bare in mind JM is reference encoder. So it does not in anyway show the full potential of h.265 as a codec. While VP9 is itself the standard and the best encoder available. If you look at the difference between h.264 JM and x264. I will argue it is very likely x265 ( If DS decide to do it ) will still be better then VP9. 5. Daala... as much as i love Mozilla, knowing their pace of work and Daala's current condition, expect it to compete with h.266 or VP10. 6. Patents are not evil. Patents Trolls are.
Keyframe 14y ago
Path us now open for 4k streaming! Well, that and we need affordable 4k displays.
venomsnake 14y ago
It will be interesting when the scene groups will adopt H.265 or at all. I have always found fascinating how piracy and porn can be trendsetters in technology standards.
- seanalltogether 14y ago
  Scene groups are actually very conservative with codecs. They jumped onto mkv format because they didn't have an alternative for hi def rips, but it took them a long time to get off the avi format until enough devices supported h264 mp4 containers.

132 points by FreeKill 14y ago

So how much better can video formats theoretically get? Are we anywhere near the absolute limit of compression, or are current solutions limited by what can be accomplished in real time on today's hardware?

ihsw 14y ago
The Wikipedia article[1] outlines various features of this standard, for instance predictive motion vectors are being utilized more heavily, not unlike actual vector graphics. This is impressive however it requires more CPU (naturally we have more CPU available compared to when H.264 was standardized). With regards to hardware: performance/watt is a commonly touted benchmark for measuring the quality of hardware however architectural changes should be considered as well (ie: today's CPUs do more per Hz than yesterday's CPUs). [1] http://en.wikipedia.org/wiki/H.265 http://en.wikipedia.org/wiki/H.265
bradleyjg 14y ago
These are lossy formats, so there aren't clean, easily defined limits like there are for lossless formats.
BlackAura 14y ago
We won't know until we get there. Generally, the performance of a video codec is held back by available hardware performance more than anything else. The specifications of a video codec generally specify the decoder, but not the encoder. The decoder specification is intended to be implementable on hardware or software, so it can be played back in real-time, either now or in the immediate future. If some compression technique is available, but can't be done real-time, it can't be used. If a compression technique could be done real-time but only if limits are placed on it, then limits will be placed on it. The encoder has to generate a bitstream that the decoder will decode, so it's limited by the decoder's capabilities. To an extent, it's limited by available algorithms (see how much better a modern h.264 encoder is compared to the original ones), and by encoding performance (particularly if you need to encode in real time, but even offline encoders can only be so slow before they become useless), and the quality / compression performance tends to get better with time. It's still limited mostly by the decoder, though. This example is for audio codecs, but LAME actually generated higher-quality MP3s than all of the first generation of AAC encoders, entirely because it had smarter encoding algorithms. For that matter, XVID tended to produce videos that rivaled, and occasionally surpassed, the first generations of h.264 encoders. Despite that early lead, both LAME and XVID were overtaken once the AAC and h.264 encoders matured, because they were still limited by the decoders they were targetting. There's probably still a long way to go just adding complexity to the decoder, even if we don't invent any new techniques. Eventually, it'll get to the point where you could increase the limits on the decoder, but you'll end up using far more power, and getting no noticeable improvement. So, the limit would be the point when nobody can come up with any new techniques, encoders can perfectly measure perceptual quality (and therefore make perfect decisions about what techniques to use to get the best combination of bitrate vs quality), and improving existing techniques has a high cost and very low return. I don't think we're anywhere near there, yet. Lossless codecs, on the other hand, definitely do have a hard theoretical limit, because they can't discard data like lossy codecs can.
lmm 14y ago
We're a long, long, way from the theoretical limit - you can tell by comparing the size of programmatically generated videos (e.g. 3D renderings, or videogame videos) with their source material. A "perfect" video codec would mean they were the same size, but at the moment a 256kb SNES rom and a few hundred bytes of buttonpresses will generate you a video that's easily in the 10s of megabytes (granted video codecs aren't optimized with snes gameplay videos as their primary target).
- snowwrestler 14y ago
  These are two totally different things. Video codecs do not try to "discover" the equations that created the scene. They take the recorded data of the scene and then try to represent it "well enough" in a smaller number of bits. By analogy: knowing the equation for conservation of momentum does not help you find the smallest way to record the results of 1 million experimental collisions.
  - lmm 14y ago
    >These are two totally different things. Video codecs do not try to "discover" the equations that created the scene. They take the recorded data of the scene and then try to represent it "well enough" in a smaller number of bits. Think of it in information-theory terms (e.g. Kolmogorov complexity). If the scene was created from no more than n bits of data, then it is possible to represent it in n bits, and a "theoretically perfect" video codec would do so. Video codecs really do try and "discover" the simplest representation of a scene (e.g. motion vectors are exactly that), and the things they can "understand" are getting more and more complex as video codecs advance (e.g. film grain).
    - snowwrestler 14y ago
      Let's say you take an algorithm for generating the digits of pi, and run it on 2 computers. One you let run only a short time and it produces a string 100,000 digits long. The other you let run for a longer time and it produces a string one million digits long. Would you argue that these two strings should compress to the same size because the source code that generated each of them is the same size? edit: to clarify my question

Hello71 14y ago

And... patents.

ihsw 14y ago
That is an inevitability.
- azakai 14y ago
  There are open alternatives like Daala. The patented codec won last time (H.264), but history might not repeat itself this time.
  - greyfade 14y ago
    That will depend on who chooses to implement which. If hardware manufacturers choose H.265, VP9 and Daala will be marginalized purely because of performance concerns. If, on the other hand, VP9 or Daala can be implemented in hardware cheaply enough and with good enough electrical characteristics, perhaps OEMs can be persuaded to use it.
    - alexkcd 14y ago
      Sadly, the best compression techniques are fairly obvious and have been patented. The economics of this space have always favored better codecs over licensing concerns. Savings in bandwidth often negate the cost benefits of a free codec. High end video recording/editing tools used by most content creators are expensive, such that a codec license amounts to only a small fraction of the cost. Pirates care about high quality and fast downloads. They don't care about licensing costs for obvious reasons. H.265 merely standardizes on a set of the best known compression techniques that meet certain compression vs processing constraints. It just so happens that most of these techniques are patented. Which in turn is why MPEG-LA exists. This will continue to be true going forward. The only way to make a free codec viable is to fix the patent system. I'm all for patent reform, but as I mentioned elsewhere, I'd much rather discuss h265 tech here, and leave the patent debate for the numerous posts we're sure to continue to see on HN.

ghc 14y ago

H.265 sounds great...but the article doesn't mention the most important point: Is it patent-encumbered? Last time around patents proved a major barrier to adoption in free browsers, so why should this time be any different? A quick wiki check seems to indicate that MPEGLA has patents on H.265, so a GPL3-compliant decoder is probably a no-go, but we don't yet know whether they'll take a more enlightened approach to licensing this time around so that adoption will be cleaner than it was with H.264.

jws 14y ago
I hesitate to bring this up, because it may well trigger a barrage of ill informed replies onto the poor overtaxed internet, but… Does GPL-3 have anything to say about third-party patents? Assuming I neither own nor control the sublicensing of any patents, why could I not write an H.265 decoder and place it under GPL-3? (Well not me specifically, but someone who lives in a country free of software patents.) I'm not seeing the problem, except for possibly in section "11. Patents" of the GPL-3 there is this odd paragraph… If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. … which seems to create some sort of obligation if I have reason to believe there exists a country in which the work would infringe a patent. But there are three remedies available, one of which is to publish the source code of the program, which is sort of a non-penalty for a GPL licensed program.
- crazytony 14y ago
  I believe this section is mostly dealing with companies that create a library, patent it, then create a GPL3 app that uses said library without the intention of opening up the library. Looking at you NVIDIA :). The way I'm reading that is if you build a work that relies on a library covered under patent you must do one of the following: 1. Publish the library as some form of open source (no license specified) 2. Cede the patent to the public domain through some mechanism 3. Grant anyone creating software based on said library a license to the patent free of charge. As the MPEGLA owns the patent and is not shipping code #1 would not be available and #2 and #3 would not be applicable to a 3rd party developing code because they don't own the patent. IANAL but that seems to be the way that clause was intended.

jbk 14y ago

> The new video format is the successor to the H.264 codec, which nearly every video publisher has standardized after the release of the iPad and several other connected devices. No. H.264 was already used by HD-DVD, Blu-Ray, DVB (since 2004) and AVCHD. > It seems crazy now, but once upon a time, Apple’s adoption of H.264 and insistence on HTML5-based video players was controversial — especially since most video before the iPad was encoded in VP6 to play through Adobe’s proprietary Flash player. No. Most professional videos were using MPEG-2 and pirated movies were using Mpeg-4 part 2 (DivX, Xvid). Seriously, Apple can do great things, but this TC sensationalism is boring and inaccurate. Besides that, it is great to finally have H.265 ready. We'll see the fight with VP9 and Daala very soon.

wmf 14y ago
I think when TechCruch says publisher they mean Web site. If you really think about it, the Web is the entire universe.
- nolok 14y ago
  > If you really think about it, the Web is the entire universe _their_ entire universe
deleted 14y ago
[deleted]
taligent 14y ago
>We'll see the fight with VP9 and Daala very soon. Let's be realistic here. Nobody particularly cared what Google or Mozilla were doing before and there is nothing to suggest it is going to change now. It wouldn't be a close fight with just Apple but against all the MPEG companies I don't even know why they bother.
TheCondor 14y ago
Hddvd and bluray use vc1
- DiabloD3 14y ago

benwerd 14y ago

h.265 is exciting. It takes into account the vastly improved processing power of today's devices to create smaller files - I'm looking forward to integrating it with our service, which in turn will put h.265 in easy reach of broadcasters. Really great step forward for the industry, although, of course, I wish it was an open standard.

pkulak 14y ago
1080p H.264 can just now be played back on modern processors without hardware acceleration. I shutter to think about playing back 2160p H.265 before anyone builds hardware support. I'm sure you don't get "twice as efficient" without making it about twice as difficult to decode. Or maybe 4 times...

modeless 14y ago

VP9 is also under development. VP9 decoding support was recently added to Chromium. http://src.chromium.org/viewvc/chrome?view=rev&revision=172738 http://src.chromium.org/viewvc/chrome?view=rev&revision=... http://en.wikipedia.org/wiki/VP9 http://en.wikipedia.org/wiki/VP9

kristofferR 14y ago
Unless VP9 decoding is implemented in hardware chips like H.264 is and H.265 is going to be, it'll likely fail. It sucks, but I'd much rather have a "non-free" codec that plays smoothly on all my devices than a "free" codec with lag issues on everything but my computer. Try playing 1080P H264 videos on your tablet/phone without using the H264 hardware decoder and you'll know what I mean. Decoding H265 and VP9 will likely be even more resource intensive than decoding H264 already is And really, does the closedness of H264/H265 really matter at all for the end users? x264 seems pretty free to me, what is the difference in reality?
- modeless 14y ago
  Hardware support for VP8 exists, though it's not widespread as of yet. Tegra 3 has it. http://www.nvidia.com/object/tegra-3-processor.html http://www.nvidia.com/object/tegra-3-processor.html As with most software, the closedness of H.26X matters a lot more to developers than users.
  - wmf 14y ago
    I think the last developer who cared was Firefox and even they gave up.
    - gillianseed 14y ago
      Firefox has native vp8/webm support. I know as I use it when I visit Youtube pretty much everyday and watch webm (vp8) videos. I don't have flash installed.
      - 14y ago

nextstep 14y ago

So when can we expect this to be supported in VLC?

jbk 14y ago
As soon as there is a GPLv2 compatible decoder available? See https://github.com/smarter/libav/commits/hevc https://github.com/smarter/libav/commits/hevc

ComputerGuru 14y ago

I'm just waiting for DarkShikari [1] to post in this thread :) Reading his codec-related comments on HN is always such a wonderful and humbling learning experience. I look forward to his take on the h265 spec and the changes (both advantages and disadvantages, as there are bound to be both) over h264. 1: http://news.ycombinator.com/user?id=DarkShikari http://news.ycombinator.com/user?id=DarkShikari

wmf 14y ago
And many of us are wondering if he's working on x265.

nextparadigms 14y ago

I'm confident VP9 has a much better chance of succeeding this time around. h264 was already widely supported before Apple decided to promote it against Flash. That's not the case with h.265 right now. It will have to start from scratch, which gives VP9 a much larger window of opportunity. This is from November, where they posted they are about 7% behind h.265/HVEC: https://www.ietf.org/proceedings/85/slides/slides-85-videocodec-4.pdf https://www.ietf.org/proceedings/85/slides/slides-85-videoco... I've also seen in another document I can't find right now them saying that work on h.265 started in 2005, while work on VP9 started in 2011...and they are already pretty close to matching it, and they are gaining 10% on it every quarter. If that's true it should be at least as efficient or more within a quarter or two, than h.265. Then it will be just a question of adoption. Software adoption should be much easier. Many have already implemented VP8 (which is also slightly better than h.264 at this point - [1]), and I'm sure Google will use VP9 for HD Hangouts, and for Youtube. This time I hope they go through with their promise and make it the default codec for Youtube, with fallback to Flash for browsers not supporting it (only about 20% of the users are not supporting VP8 right now, for reference [2]). That should encourage adoption by other video sites, and also chip makers. And that's I think the biggest hurdle - getting chip makers to support VP9. But now with Android's popularity and virtually every chip maker supporting Android, I think it will be much easier than it was to get support for VP8. The nice part about VP9 is that it will also come integrated with the Opus codec inside WebM, and that should be a big factor in the adoption of WebM, too. [1] http://pacoup.com/2012/12/20/vp8-webm-vs-h-264-mp4-december-2012/ http://pacoup.com/2012/12/20/vp8-webm-vs-h-264-mp4-december-... [2] http://downloads.webmproject.org/ngov2012/pdf/03-ngov-vp8-update.pdf http://downloads.webmproject.org/ngov2012/pdf/03-ngov-vp8-up...

doublec 14y ago
Integrating Opus and/or VP9 into WebM removes one of the selling points they used to promote the format. WebM wasn't supposed to be a generic container format holding different codecs. It was specifically tied to Vorbis/VP8 to ensure everyone advertising WebM support would be able to play the files. If they decide to add these additional codecs then there will be some players that can play some WebM files but not others. If that was the direction they wanted to head then they could have just stuck with Matroska for the container format.

ksec 14y ago

Few Points. 1. To the Post above on VP8 better then x264. Comparing a single frame, single video, single....? isn't very detail. VP8 has improved A LOT!. That is true. But as far as i am concern and many other video encoder it is also true that it hasn't match x264 yet. 2. VP9 is great! It has matched and in many case even exceed x264 quality. Although there would still be areas where x264 perform better simply because it is much more mature. 3. So given more time VP9 will very likely beat x264 quality. It is only with 10% range of HEVC / h.265 JM, under benchmarks. So it will very likely beat that too. 4. Do bare in mind JM is reference encoder. So it does not in anyway show the full potential of h.265 as a codec. While VP9 is itself the standard and the best encoder available. If you look at the difference between h.264 JM and x264. I will argue it is very likely x265 ( If DS decide to do it ) will still be better then VP9. 5. Daala... as much as i love Mozilla, knowing their pace of work and Daala's current condition, expect it to compete with h.266 or VP10. 6. Patents are not evil. Patents Trolls are.

Keyframe 14y ago

Path us now open for 4k streaming! Well, that and we need affordable 4k displays.

venomsnake 14y ago

It will be interesting when the scene groups will adopt H.265 or at all. I have always found fascinating how piracy and porn can be trendsetters in technology standards.

seanalltogether 14y ago
Scene groups are actually very conservative with codecs. They jumped onto mkv format because they didn't have an alternative for hi def rips, but it took them a long time to get off the avi format until enough devices supported h264 mp4 containers.