H.265 Is Approved
techcrunch.com
techcrunch.com
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.
_their_ entire universe
Most titles on both formats used H264, very few use VC1, even less use MPEG2.
You are right that it is highly doubtful that it would be GPLv3 compatible until the patents have expired. In practice I expect it will be included in FFMPEG and available to open source users even if impure and unavailable to strict Free software purists.
I'm not sure what isn't clean about the H.264 license except for Motorola/Google's legal action that attempts to make the FRAND commitment nearly meaningless. It would be much better for everyone else if they were part of the MPEG-LA offer.
http://www.osnews.com/story/23258/MPEG-LA-owned_Patent_Troll...
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.
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.
This is from November, where they posted they are about 7% behind h.265/HVEC:
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-...
[2] http://downloads.webmproject.org/ngov2012/pdf/03-ngov-vp8-up...
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.
The ITU/ISO camp has the same problem but worse, since MP4 may contain MPEG-4, H.264, or H.265.
Yup Micro$oft and Apple (partners of MPEG LA) will totally let that happen.
I'm sorry, but you have been mislead - VP8 is not better than H.264, and comparison you linked is bad for multiple reasons, like not telling the exact encoder settings used, not providing actual video for users to compare and only showing one frame (for all we know, it might be a keyframe on VP8 and it pumped the bitrate up for it and x264 didn't), not providing source for test replication and so on - just read these:
http://x264dev.multimedia.cx/archives/458
http://x264dev.multimedia.cx/archives/472
I can do a proper comparison between H.264 and VP8 if you or anyone else is interested, though it'll take at least a few hours (I intend to use the park_joy test clip found in derf's test clip collection[1]).
Also, On2 is famous for hyping up their products to heaven and have yet to match their claims, so I remain skeptical about VP9. There's also Xiph working on Daala, but right now it doesn't seem to be much beyond big words.
While I would love an open format to provide better quality than H.264 and even H.265, I wouldn't hold my breath for such a thing.
So VP9 is pretty much a non-starter.
But VP9 is pretty much a non starter for any embedded device as well. Apple, LG, Microsoft, Samsung, Sony are patent licensors so they have every reason to use H.265 in their own products. So that takes cares of the majority of all of the mobile and console markets.
Then you still have the situation where even if H.265 and VP9 are supported equally everywhere why would anybody use it. H.265 will be technically superior, be built into the core OS SDKs and have far, far better tool support from content creation to editing to output.
As for VP9 being a 'non-starter', nonsense. The reason Google is creating their own in-house codec is obvious, 'online' video will be used in an ever-increasing number of services in the future, services which Google wants to provide. As such Google wants their own codec so that they don't have to licence from someone else.
When you record video in your Google Glass or play/record in <insert Google product/service here>, it will use Google's own VPx codec.
And Google Glass is vapourware and YouTube/Chrome supports H.264 so not buying the whole Google will put its weight behind VP9 argument. We heard it before with VP8.
Flash is headed for irrelevance - I doubt it will make much difference at all in this format choice. What will matter a lot more is what format mobile devices are able to play.
I'd love to uninstall Flash, but it'd be a major pain if I had to switch over to Chrome every time I wanted to visit an MP3 blog or news site (think CNN or The Verge with their proprietary Flash video players).
EDIT: Also, last I checked, HTML5 videos on YouTube could not be played in "true" fullscreen (they'd only take over the browser window, not your entire screen). Has that changed?
2) Yes, full screen works since the JS API was implemented in all browsers (albeit prefixed until recently) except for IE.
Most browsers (at least Safari definitely does) do proper full screen too.
I'm not sure if the experience would be as good with Firefox as I'm not sure if they support H.264 yet. But I heard that was planned.
I'd encourage you to try it for a while - it's free and pretty quick to re-install Flash if it gets too annoying.
Other than some minor annoyance of flipping to Chrome, the only real downside to browsing without Flash is that there's a surprisingly number of sites that silently fail without warning if you don't have flash installed. I'm looking at you, eBay.
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?
As with most software, the closedness of H.26X matters a lot more to developers than users.
And a quibble about words: h.264 isn't "closed". The standard is well-understood and easily available, and there are free high-quality implementations of both sides of the codec. What you mean to say is that it is "proprietary" and that its use is subject to IP laws and licensing restrictions.
Are you sure you're not scaremongering just a bit here?
For one thing, the royalties typically don't kick in until projects have reached a significant size. Using H.264 is explicitly free up to that point for those users, even if you accept the validity of the patents etc.
Moreover, it seems unlikely that lawyers would trouble a lot of small companies anyway, at least in places like Europe. Firstly, they'd have to notice them. Secondly, they'd have to know that the use wasn't properly authorised (since bringing a groundless lawsuit in a loser-pays system can be expensive -- you don't see the equivalent of the xxAA shakedowns over here for similar reasons). Thirdly, are heavyweight industry lawyers really going to risk a legal action that could set a precedent that these patents are unenforceable, destroying their entire business model across an entire continent, just to extract a modest amount of licensing fees from a small business? If they wanted to pick that fight, I suspect the unlucky business having to defend itself would suddenly find itself with a lot of well-financed friends.
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. 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.
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).
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.
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.
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).
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
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.
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.
As far as encoding technology goes, this is pretty exciting. Looking forward to the first wave of 4K TVs & cell phone cameras hitting the market.
(Disclaimer: I'm the cofounder of a startup specializing in high quality cellphone videos)
More info here: http://luma.io
So while it won't do Free software any good the situation won't be much worse than for AVC unless Google/Motorola or Samsung win in their current cases with Microsoft and Apple about the meaning of FRAND commitments. If FRAND commitments are weak or loose many companies may fight to get the biggest slice of the benefit which could effectively kill the standard.
The competitive pressure of RF formats against H.264 drove the licensing fees _very_ low (with many use-cases made no cost, but even the w/ fee cases are basically 1/10th the AAC royalty rates). H.265 looks like it will have many more patent holders too. But it will likely be several years before there exists an even incomplete H.265 pool license, so it may be a while to see how much worse (or better) the rates are compared to H.264.