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

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.

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.