Slashdot Mirror
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.)
I want to play back a 4k MKV of Ben Hur on my phone! When?!?!
Is there any possibility that the PS4 or Xbox One will have playback capability?
Roku?
Apple TV?
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.
This is basically just the HEVC reference encoder right now. Expect it to be slow and inefficient.
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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.
even so that none of the main x264 developers is involved with the project. -> lame marketing stunt
That's like half of the job.
https://bitbucket.org/multicoreware/x265
I'm also annoyed about the name, and we may now end up in a confusing situation with two independent x265 programs if the x264 developers eventually start working on a h265 encoder too.
Developer: So we've finally made our h264 mp4 HTML5 applets and site work for every device out there using customized and conditioned JavaScript.
MulticoreWare: h265 soon out!
Developer: Awwww crap =(
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.
Sorry, but I have no interest. Until I can avoid the MPEG-LA and subsequent media cartels in every way, shape and form, from hardware to production, and commercial distribution by my own terms, I want nothing to do with it.
For any of you asking why? Go read up on WHO you have to pay, if you want to sell a video you'ved created to distribute commercially.
The question is whether HEVC will be of use on mobile devices - that is where an increasing amount of video viewing is being done, and the area where bandwidth is most in demand.
Existing smartphones have hardware support for H.264 - it is unclear how soon they will have hardware support for HEVC, which of course is even more computationally intensive.
Seriously... anyone else hoping it takes over this time around? License/royalty free and *supposedly* within 1% of the quality for filesize? I hope my next WDTV supports it. ... guess this means I'll have to re-acquire my tv collection.
And its now about time for Google to jump in and try and push their crap again!!
The thing is h264 is maybe too entrenched, it took many years to have many millions of devices supporting it and that gives you a big install base that people don't necessarily want to replace (not everyone is the middle class american with "drawer full of smartphones"). And even then many old PCs aren't quite up to the task yet - the kind that barely manage youtube 480p or even 360p.
MP3 files are still commonly used, even though they're clearly inferior and using AAC or OGG is a comparatively much simpler problem. I still even watch a lot of xvid. I can imagine the market will stick to h264 for a long time, like Windows XP stuck and still sticks around. Even if h265 is adopted it will mean content providers and hosts will have to dual encode to h264 and h265 for everything, increasing storage and encoding hardware costs.
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.
Just a guess, but the "x" in x264 comes from it being the H.264 counterpart to Xvid, which is DivX spelled backward, and DivX is named after an experimental time-limited counterpart to DVD-Video that Circuit City was pushing.
Ideally, you added multi-format support to your HTML5 applets when VP8 came out, and plugging in support for VP9 and H.265 won't be too hard.
Does "hardware support for H.264" refer to dedicated silicon that does nothing but AVC decoding, or does it refer to implementing AVC's inner loops in a programmable digital signal processor such as a GPU? If the latter, it may be reprogrammable for HEVC. In fact, with HEVC increasing opportunities for parallelism, it might be easier to bring the GPU in.
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). Opus also streams better, capable of dealing with extreme low-latency demands associated with real-time uses like VoIP.
It is so common to see people talking about tweaking x264 to improve quality and compression, but there is a point where you're better off optimizing the other pieces; AC3 passthru is laughable contrasted to 6-channel vorbis (which I use in place of HE-AAC due to not having access to a quality AAC encoder on Linux). I'm still waiting for opus support in matroska (which is in progress) or something to supplant matroska as the prevailing file container.
There's also the patent question; will this be intentionally patent-encumbered the way MPEG standards tend to go (in which case they'll certainly connect it to HE-AAC), or will this be a somewhat more open standard (which lends nicely to Opus)?
Use my userscript to add story images to Slashdot. There's no going back.
The thing is h264 is maybe too entrenched, it took many years to have many millions of devices supporting it
The same was true of MPEG-2 hardware (DVD players) and MPEG-4 ASP hardware (DVD players with DivX). It took Blu-ray and smartphones to get AVC hardware into users' hands. People replace smartphones regularly. And just as Blu-ray Disc with AVC replaced DVD-Video with MPEG-2, whatever optical disc format replaces Blu-ray Disc is likely to include HEVC as an option for 4K video.
When the likes of Sony seem perfectly willing to use Free Software
Sony uses permissively licensed free software, such as *BSD operating systems. The X-series MPEG-4 video encoders (Xvid, x264, and x265), on the other hand, are copylefted. Console makers in general ban copylefted software on their platforms because allowing game publishers to distribute "Installation Information" (GPLv3) or "scripts to control [...] installation" (GPLv2) would allow other publishers to circumvent licensing.
VP9 produces video about the same size and quality as H.265 (Google I/O talk on VP9, though they of course weren't using x265 to compare), VP9 support is already in Chrome (with Firefox and Opera likely to follow soon) and the reference VP9 implementation is BSD-licensed. What's the advantage of H.265 over VP9 and what does x265 in particular offer over this new version of WebM (VP9+Opus)?