H.265 Is Approved(techcrunch.com)
techcrunch.com
H.265 Is Approved
http://techcrunch.com/2013/01/25/h265-is-approved/
87 comments
[deleted]
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.
I doubt that MPEG-LA has any patents on H.265 (they don't have any on H.264). They offer a bulk licensing deal for many different patent owners which is much better than licensing from each individually.
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.
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.
Perhaps not MPEG-LA itself, but a company owned by it's CEO, Jack Horn definitely waded into the patent trolling business a while back:
http://www.osnews.com/story/23258/MPEG-LA-owned_Patent_Troll...
http://www.osnews.com/story/23258/MPEG-LA-owned_Patent_Troll...
Google signed the MPEG-LA license agreement which would put Motorola's patents into the MPEG-LA pool as well. Arguments are Monday, so one way or another, it will be clarified sooner or later.
Even if they lose that part they won't be signed up to H.265 licence unless they choose to so the FRAND status matters too so can potentially charge excessively. Also if the weak FRAND interpretations stand many other patent holders may stay outside the collective license to get as much as they can.
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.
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.
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.
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.
Yes, it is. And very heavily.
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-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...
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...
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.
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.
Google can solve this by defining some interoperability profiles like WebM = only VP8+Vorbis and WebM2 = only VP9+Opus. Or they could give a completely different name to VP9+Opus since WebM is not a popular name anyway.
The ITU/ISO camp has the same problem but worse, since MP4 may contain MPEG-4, H.264, or H.265.
The ITU/ISO camp has the same problem but worse, since MP4 may contain MPEG-4, H.264, or H.265.
webm is a defined subset of mkv. And it stays that way. Only a small, finite number of codecs have to be implemented (so far vp8, vp9, vorbis, opus).
The defined subset included the particular codecs that would only be supported. Implementers who got on the WebM train agreed to VP8 and Vorbis. They may not be keen to do VP9 or Opus. There's no "have to be implemented" for these two formats. This means there will be fragmentation which WebM was supposed to avoid.
>VP8 (which is also slightly better than h.264 at this point)
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.
[1] http://media.xiph.org/video/derf/
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.
[1] http://media.xiph.org/video/derf/
Okay then, I'm done with the comparison. You can find it here: http://news.ycombinator.com/item?id=5122855
> I'm confident VP9 has a much better chance of succeeding this time around.
Yup Micro$oft and Apple (partners of MPEG LA) will totally let that happen.
Yup Micro$oft and Apple (partners of MPEG LA) will totally let that happen.
"Micro$oft" in this day and age? It's time to move on. (Or at least update to something equally obnoxious but more relevant like "Appl€".)
VP9 is also under development. VP9 decoding support was recently added to Chromium. http://src.chromium.org/viewvc/chrome?view=rev&revision=...
http://en.wikipedia.org/wiki/VP9
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?
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?
x264 isn't remotely free to you. If you use that encoded video in any business capacity at all that doesn't meet the "free internet content for end users" definition, you're going to hear from them MPEG-LA lawyers about licensing. And note that isn't a license they're offering, just a promise. They can change their mind at any time.
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.
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.
x264 isn't remotely free to you. If you use that encoded video in any business capacity at all that doesn't meet the "free internet content for end users" definition, you're going to hear from them MPEG-LA lawyers about licensing.
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.
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.
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
As with most software, the closedness of H.26X matters a lot more to developers than users.
As with most software, the closedness of H.26X matters a lot more to developers than users.
I think the last developer who cared was Firefox and even they gave up.
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.
I don't think that's what he meant. Firefox was the last browser to refuse to use (not just ship, but to even use already-installed) patent-encumbered video codecs. i.e. even if you had an h264 decoder on your PC, Firefox would refuse to play h264-encoded videos. This was their (very obstinate) stance for years, and has been a source of much consternation within the FF community, as theirs was the only browser to refuse to play many online videos not available in vp8 or theora. They finally gave in last month and will now use an h264 decoder if such a decoder is installed on your PC (though FF does not ship with, nor (to the best of my knowledge) will ever ship with, such a decoder).
Does YT default to this if you go there with a newer Firefox?
No, but you can opt-in at https://youtube.com/html5
I would assume so, since when I clicked at the link sp332 provided, it says that I'm not part of the HTML5 trial, and asks me to join.
Well Google promised to support them then they backed off.
They did support them, they released VP8 royalty free and supports it on Youtube. What 'support' were you referring too?
H.264 has never mattered for developers either. Windows, OSX, iOS and Linux have all had OS libraries that developers could use to handle H.264 content. This will continue with H.265.
It's mattered for professional developers. It was an issue at my last^2 company, which was not exactly large (~100 employees).
It will be, and I'm sure most video players will support it, too, just like they are supporting VP8 now.
Whether it is built into the browser or not means nothing so long as Flash dominates web video. And Adobe will already need to license H.265 because of Premiere.
So VP9 is pretty much a non-starter.
So VP9 is pretty much a non-starter.
I've been using the web without Flash installed on my system for months now - an it really surprised me how little I have to jump into Chrome (with its built in flash) to play a video!
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.
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've been doing the same. The only time I need to switch to chrome for video is when I want to watch ad-supported videos. One caveat is that most of my video consumption is Youtube, a little from Vimeo and almost nothing from anywhere else.
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.
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.
Facebook embeds.
I'm really curious...do most sites now fall back to HTML5-compatible players even on the desktop?
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?
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?
News sites would probably be the ones that would make you flip over to Chrome, as well as MP3 sites I guess. The Verge falls back properly, as do pretty much all YouTube videos.
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.
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.
1) Those using popular open source players often do. Podcasts and vodcasts should have an RSS feed you can subscribe.
2) Yes, full screen works since the JS API was implemented in all browsers (albeit prefixed until recently) except for IE.
2) Yes, full screen works since the JS API was implemented in all browsers (albeit prefixed until recently) except for IE.
When serving video, Flash can act as a container for any type of video, as such it can serve VP8/VP9 just fine. There is no technical barrier here.
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.
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.
I am well aware that Flash can act as a container. But that container by default will have H.265 since Adobe is already a licensee. So why would anybody not use it ?
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.
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.
Web video players aren't the only application in the world for video codecs. VP9 will be a great option for anyone writing native code, for example phone apps or PC/console games.
Sure. But I was just assuming that VP9 would be similar to VP8 which found most of its usage in a web browser.
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.
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.
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
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
And many of us are wondering if he's working on x265.
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.
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.
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?
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.
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.
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
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
These are lossy formats, so there aren't clean, easily defined limits like there are for lossless formats.
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).
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.
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.
>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).
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).
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
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
Yes, very much so. You'll find that most compression algorithms will do this for a string of zeroes (i.e. 100,000 zeroes will compress to approximately the same size as 1,000,000 zeroes) or 1s, or simple repeating patterns. I don't know whether any common compression algorithm is "smart" enough to be able to compress the digits of pi, but a "perfect" compression algorithm certainly would be.
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.
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...
So when can we expect this to be supported in VLC?
As soon as there is a GPLv2 compatible decoder available?
See https://github.com/smarter/libav/commits/hevc
See https://github.com/smarter/libav/commits/hevc
And... patents.
No different than h264 in that regard. I'd rather we discuss the technical merits of this technology than have another patent debate. Not that I wouldn't agree, just that if you want to talk patent reform, it might be better suited to do so in a dedicated HN posting.
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)
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)
High quality cellphone videos? Tell us more.
We remove handshake by computing optimally smooth camera paths. Some example videos shot on a handheld iPhone using our app:
http://luma.io/v/Brl
http://luma.io/v/BtN
http://luma.io/v/Brm
More info here: http://luma.io
More info here: http://luma.io
The "Get Luma" button on that page just kicks me to http://itunes.luma.com/ (the home page).
Fixed. Thanks!
Owned by the standards participants will have to be licensed on an FRAND basis.
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.
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.
H.265 will 'add' a bit more than ten years of life to the encumbrance, so in that regard it is worse.
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.
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.
That is an inevitability.
There are open alternatives like Daala. The patented codec won last time (H.264), but history might not repeat itself this time.
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.
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.
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.
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.
So what happens if VP9 and Daala are significantly better then? By your logic they should be adopted instead of h.265.
Yes, if 1) VP9/Daala are significantly better, and 2) they don't come out much later than h265. VP8 failed on both accounts compared to h264. To see why, read: http://x264dev.multimedia.cx/archives/377 (not an unbiased source admittedly, but the technical analysis is accurate).
Daala link for the lazy: https://xiph.org/daala/
Path us now open for 4k streaming! Well, that and we need affordable 4k displays.
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.
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.
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.