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.

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.

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

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.