H.265 Is Approved

http://techcrunch.com/2013/01/25/h265-is-approved/

by FreeKill • 13 years ago

132 85 13 years ago

techcrunch.com

Hello71• 13 years ago

And... patents.

ihsw2• 13 years ago

That is an inevitability.

azakai• 13 years ago

There are open alternatives like Daala. The patented codec won last time (H.264), but history might not repeat itself this time.

alexkcd6• 13 years ago

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)

jfb2• 13 years ago

High quality cellphone videos? Tell us more.

josephlord3• 13 years ago

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.

nullc• 13 years ago

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.

ghc• 13 years 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.

jbk3• 13 years ago

Yes, it is. And very heavily.

josephlord3• 13 years ago

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.

ksherlock• 13 years ago

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.

r00fus• 13 years ago

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...

jws• 13 years 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• 13 years 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.

jbk3• 13 years 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.

wmf4• 13 years ago

I think when TechCruch says publisher they mean Web site. If you really think about it, the Web is the entire universe.

nolok• 13 years ago

> If you really think about it, the Web is the entire universe

_their_ entire universe

TheCondor• 13 years ago

Hddvd and bluray use vc1

DiabloD3• 13 years ago

CAN use VC1, its one of 3 mandatory video codecs, H264, VC1, and MPEG2, all available up to 1920x1080.

Most titles on both formats used H264, very few use VC1, even less use MPEG2.

benwerd• 13 years 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• 13 years 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...

modeless3• 13 years ago

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

taligent4• 13 years ago

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.

modeless3• 13 years ago

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.

gillianseed4• 13 years ago

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.

stephen_g2• 13 years ago

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.

kristofferR• 13 years 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?

modeless3• 13 years 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

As with most software, the closedness of H.26X matters a lot more to developers than users.

ajross• 13 years ago

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.

nextparadigms3• 13 years ago

It will be, and I'm sure most video players will support it, too, just like they are supporting VP8 now.

nextstep• 13 years ago

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

jbk3• 13 years ago

As soon as there is a GPLv2 compatible decoder available?

See https://github.com/smarter/libav/commits/hevc

rcthompson• 13 years 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?

ihsw2• 13 years 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

bradleyjg• 13 years ago

These are lossy formats, so there aren't clean, easily defined limits like there are for lossless formats.

BlackAura• 13 years 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.

lmm4• 13 years 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).

snowwrestler2• 13 years 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.

ComputerGuru2• 13 years 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

wmf4• 13 years ago

And many of us are wondering if he's working on x265.

nextparadigms3• 13 years 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-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...

doublec2• 13 years 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.

fosap• 13 years ago

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).

wmf4• 13 years ago

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.

newguysob2• 13 years ago

> 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.

Cyranix• 13 years ago

"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€".)

Hupo2• 13 years ago

>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/

Hupo2• 13 years ago

Okay then, I'm done with the comparison. You can find it here: http://news.ycombinator.com/item?id=5122855

ksec• 13 years 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• 13 years ago

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

venomsnake• 13 years 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• 13 years 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.

H.265 Is Approved

Related Stories