Next-Gen Video Encoding: x265 Tackles HEVC/H.265

An anonymous reader writes "Late last night, MulticoreWare released an early alpha build of the x265 library. x265 is intended to be the open source counterpart to the recently released HEVC/H.265 standard which was approved back in January, much in the same way that x264 is used for H.264 today. Tom's Hardware put x265 through a series of CPU benchmarks and then compared x265 to x264. While x265 is more taxing in terms of CPU utilization, it affords higher quality at any given bit rate, or the same quality at a lower bit rate than x264." (Reader Dputiger writes points out a comparison at ExtremeTech, too.)

Comments

This is great news!

[ShooterNeo]

25-35% less file size for the same quality is an incredible advance. Obviously the task of improving compression algorithms is going to ratchet up enormously as the file sizes get smaller with higher entropy. I'm in fact amazed that an advance this big is even possible, apparently, x264 is nowhere near the theoretical limits for (lossy) video compression.

Re:This is great news!

[gl4ss]

Storage isn't a problem, it's the cheapest part of the equation. Energy consumption is the biggest technical challenge due to the global domination of mobile devices and the current limitations in energy storage.

_transferring_ is still very much a issue though.

Re:This is great news!

[jedidiah]

Storage isn't even the problem when it comes to file size, network bandwidth is. The generally poor quality of broadband and even cable ultimately relate to the size of the file. Network performance and bandwidth caps are the real choke point.

Streams get over compressed to the point that even an aggressively transcoded DVD beats the snot out of them in terms of quality. Forget about a raw BluRay stream.

Re:This is great news!

[NFN_NLN]

Storage isn't a problem, it's the cheapest part of the equation. Energy consumption is the biggest technical challenge due to the global domination of mobile devices and the current limitations in energy storage.

The summary talks about an increase in CPU usage. If they use a dedicated H.265 chips in the future (much like they use H.264 chips now) can they not optimize the hardware to minimize CPU and power use? I'm just wondering from the perspective of mobile/phone users if H.265 is going to dominate or will H.264 still be the standard for mobile.

Re:This is great news!

[dj245]

Storage isn't a problem, it's the cheapest part of the equation. Energy consumption is the biggest technical challenge due to the global domination of mobile devices and the current limitations in energy storage.

But there are bandwidth limitations on many devices. Limitations which are generally fine now for 1080p, but could be a problem with "something better", or with multiple streams of "something better".

Plus, this article deals with the compression part of the video encoding. Most media is decompressed many many times, but only compressed once. It is reasonable to assume that decompression will be more taxing with x265 compared to x264, but that isn't a part of this article. How much more CPU is required for decompressing x265 compared to x264? That isn't so clear at the moment, and since the code isn't finalized, results today may have no bearing on tomorrow anyhow.

Re:This is great news!

[evilviper]

25-35% less file size for the same quality is an incredible advance.

No, it really isn't.

First off, we're just talking about PSNR per bitrate, which is pretty meaningless. They even say in TFA that they could have used the "--psnr" option to increase the PSNR, at the expense of video that looks like crap. At least SSIM would have been less easy to fool than PSNR. At the end of the day, there's nothing better than a subjective expert human visual comparison.

Secondly, look at a few of those charts. The specific encoder you use makes a HELL of a lot more difference than the codec/format. Other H.264 encoders don't come close to x264. If x265 doesn't get the same kind of open source development boost, x264 will continue to improve, and probably outperform the newer format, as proprietary codec developers just haven't shown themselves willing or able to do a good job of perceptual encoding, yet that's where the bulk of our non-pirated content comes from... And those pirate rips aren't exactly encoded by experts, so they tend to be crap that can be easily surpassed by MPEG-2 encodings.

And finally, Google claims their patent-free VP9 codec, which was recently finalized, will outperform H.265/HEVC. Even if they're over-promising, I'm sure it'll be close enough. And if we get open source developers working on and optimizing VP9/libvpx, while shunning HEVC, then the patent-free codec could fly past the patent-encumbered one easily enough. And for the first time in history, we'll have non-proprietary audio and video codecs that can outperform the expensive and patented kind, laying to rest the contentious HTML5 video debate, back when Theora really didn't have a snowball's chance in hell against H.264.

Let's just hope Google is actually committed this time, and will convert more than 4% of their Youtube catalog to WebM in the next 4 years... This time using the new and improved VP9 and Opus, instead of just using it as a threat to get cheap licensing for the proprietary codecs.

Re:This is great news!

[tttonyyy]

Ultimately video over IP (which sounds like a bad plan to start off with) is all about the connection - modern broadcasters use adaptive streaming - the same video is encoded at a variety of bitrates and resolutions and made available to playback clients. The client assesses live buffer fill and decides between low bitrate and poor quality and high bitrate/quality dynamically depending on how the link is performing, fetching small/large files off the server as appropriate. It works very well and the user is left completely unaware that it's happening.

Curiously enough the H264 standard was very forward thinking in this respect and there are lots of clever ways to dynamically control streaming - none of which anyone uses as it's complicated to implement compared to just encoding the same thing at different bitrates.

H265/HEVC is the logical progression in computational complexity vs compression efficiency - definitely here to stay in the video compression industry.

Re:This is great news!

[mister2au]

The specific encoder you use makes a HELL of a lot more difference than the codec/format. Other H.264 encoders don't come close to x264. If x265 doesn't get the same kind of open source development boost, x264 will continue to improve, and probably outperform the newer format, as proprietary codec developers just haven't shown themselves willing or able to do a good job of perceptual encoding, yet that's where the bulk of our non-pirated content comes from...

Wow ... just wow!

I'll assume by "proprietary codec developers" you actually mean developers who have closed source implementation of the encoder. In which case, the statement may not be completely unreasonable ie closed-source encoders have not kept pass with this open-source implementation due to less comphrensive (and less costly) implementation of the encoding tools.

The rest is complete rubbish though ...

So what if the bulk of non-pirated comes from closed source encoders ... what does that have to do x264 or x265 or H.265 development? Is this just a shot at closed-source software given you seem to be VERY pro-open source?

The specific encoder you use makes a HELL of a lot more difference than the codec/format. Other H.264 encoders don't come close to x264. If ... blah blah blah .. x264 will continue to improve, and probably outperform the newer format"

Do you understand that H.265 is essentially a superset of H.264? You know, as in H.264 + extensions? How is x264 going to out-perform x265 given it is a subset of the later?

Do you understand that x264 uses a superset of the encoder algorithms implemented by other encoders? So what you attribute is primarily due to codec and then codec parameters and then software optimisations.

You could have said "I hate standards .. I love open source ... I hope H.265 fails" ... much quicker and doesn't need any pretence of understanding video codecs.

Reference encoder with some small tweaks

[PhrostyMcByte]

This is basically just the HEVC reference encoder right now. Expect it to be slow and inefficient.

Re:Reference encoder with some small tweaks

[StreamingEagle]

The HM reference encoder takes roughly 40 seconds to encode one frame of 1080P video on a dual Xeon (16 core) server. x265 can encode 1080P at roughly 11 frames per second today. The project is still early in development, and there are many features (lookahead, B-frames, rate control, etc) and efficiency/performance optimizations left to be done, but we are making good progress. I would encourage you to try it before reaching any conclusions.

Re:Reference encoder with some small tweaks

[timeOday]

How amenable is H.265 to vector operations? Nobody would expect a 3d game to run at an acceptable rate without a GPU nowadays, and video encoding may fall in the same category. Serial processing hasn't been getting significantly faster for years now.

no patent clarification yet, though

[Trepidity]

Not even just that it's almost certainly covered by a pile of patents, but unlike H.264, there isn't any clarity yet about which ones, and what the licensing terms will be like. Will the categories of royalty-free use granted to H.264 codecs also be applied to H.265? Nobody seems to know. MPEG-LA hasn't issued an update since June 2012, at which point they were still at the stage of calling for patent-holders to submit claims.

Decode performance

[Anonymous Coward]

Has anyone found any information on decode performance? Apparently "H.265 is known for taking more horsepower to encode and decode than H.264" but I only see numbers provided for encode performance. It seems like decode performance is more important in most cases.

Re:Decode performance

[StreamingEagle]

x265 is an HEVC encoder implementation only. To answer the general question, H.265 is more compute intensive to decode than H.264, but the compute requirements for HD decoding are not unreasonable. Software decoding of HD HEVC is possible on a dual-core ARM system, and x86 systems will not have a problem. Of course, as with any video codec, hardware manufacturers will implement hardware decoders. Some have been announced. Expect more announcements in the coming months.

Re:"lacks B-frame support"

[maxwell demon]

"With -b 1 you activate a hack which enables a "random access" GOP structure which uses B frames."

Will they also have a version with Democrat structure?

Re:A shame that they/he 'stole' the x265 name,..

[StreamingEagle]

This project is not a surprise to any of the x264 developers - we have been in discussions with them for many weeks, and we have an agreement which allows us to utilize x264 code in x265. The x264 developers haven't had a chance to make contributions yet, as we just opened the project up to participation by the open source development community. We welcome their participation, and will do everything we can to enable and encourage it.

Re:A shame that they/he 'stole' the x265 name,..

[TopSpin]

we have an agreement which allows us to utilize x264 code in x265

You don't need an 'agreement' to use x264 code because x264 is licensed under the terms of the GNU GPL v2.0. What, exactly, is this agreement supposed to permit?

Hardware Decode

[LordCrank]

If it's anything like H.264/x264 then I expect to have the hardware to decode H.265/x265 in my laptop about 2 years after movies and tv shows are being distributed in this format, but 2 years before there are any linux drivers for the hardware decoders.

Re:Hardware Decode

[evilviper]

By the time I had any need of a hardware h264 decoder in Linux, the drivers were readily available and used by all of the relevant software.

So? You were a VERY LATE ADOPTER of H.264, which doesn't remotely represent the rest of the world. H.264 has been around since 2003, and people have been struggling to watch H.264 videos in realtime on top-of-the-line CPUs from the start, and failing miserably for years. It took several years to get it decoded by GPUs even on Windows, and longer still before Linux could do it with VADPU or other frameworks. GP was absolutely correct about how it progressed.

Dual licensing

[tepples]

What, exactly, is this agreement [to use x264 code in x265] supposed to permit?

Dual licensing permits the x264 maintainer to dual license the x264 code to clients unwilling to accept the GPL. The agreement permits the x265 maintainer to do the same with pieces of x265 that were borrowed from x264.

Re:I hope they consider Opus for audio

[evilviper]

Ogg Opus (open, royalty-free, not patent-encumbered audio) beats the pants off of HE-AAC (which, in turn, is superior to everything else at pretty much every level).

Wow! So much wrong in just a single sentence...

Opus is an IETF developed codec, based on CELT from Xiph.org, and Silk from Skype/Microsoft.

HE-AAC certainly isn't "superior" at "every level". It excels at very low bitrate encoding that sounds SOMEWHAT like the original. As you start increasing the bitrate (eg 96k), low-complexity AAC easily surpasses HE-AAC. And as you go to higher bitrates still (eg. 160k), temporal domain codecs can outperform any frequency-domain codecs, so Musepack will beat the pants of AAC, and even Opus.

Still, low bitrate lossy audio quality is important, so Opus is a good choice for streaming audio and video. That's why Google chose it for their latest revision of WebM, along with their new VP9 codec that they claim outperforms HEVC.

I seriously doubt the MPEG / MPEG-LA organizations, and their members, will consider using a patent-free audio codec along with their heavily patent-encumbered video codec. Their business model is patents, and they'll chose an expensive and inferior option over a free one, any day. I'd expect HE-AACv2 to be the best you can count on for the foreseeable future.