x265 HEVC Encoder

[Kurtnoise]

Your conclusion is biased...you compare only one HEVC/AVC encoder. Moreover, why not compare also the speed time between each other ?

[LigH]

Do that. I also have a fulltime job besides my hobby. ;)

I never claimed to know how to do a comparison which satisfies every member of this forum. I just added a few values as incentive for others.

[Selur]

@Kurtnoise: since this is the x265 thread isn't it kind of obvious that people will post stuff about x265 and not about other hevc encoders,...

[smok3]

Just uploaded some updates encoded with x265 v0.7+ and x264 core:142:

...

The quality differences are interesting...

Pretty amazing stuff from HEVC here (Although the original must be really weirdly sharpened).

My try at low-bitrate "Big bucks bunny" (crf26, everything default, 420) https://dl.dropboxusercontent.com/u/79532365/tmp/bbb26hifi.mp4
ffmpeg -r 24 -i big_buck_bunny_%05d.png -pix_fmt yuv420p -r 24 -f yuv4mpegpipe - 2> /dev/null | x265 --crf 26 -o bbb.hevc - --y4m

[bxyhxyh]

This is not 1-pass CBR, but 2-pass VBR, and that works in a not too different way:

The 1st pass gathers statistics required to calculate the CRF which is required to reach the desired bitrate for the 2nd pass. So after all, the 2nd pass is a CRF encoding as well.

Several people with much experience and insight explained why it is necessary to try to get to similar filesizes in result to make meaningful comparisons, so I tried to achieve just that.

Furthermore, we are comparing x265 (HEVC) vs. x264 (AVC), so differences in the bitrate distribution are pretty expectable; encoding efficiency will be different for different scenes.

The algorithms in x265 are by far not yet final. Especially psychovisual enhancements are not yet elaborate. Still, the only conclusion I would agree to for now is, that the high efficiency of HEVC (*g*) was made obvious; and there is still headroom for improving implementations...
__

P.S.: According to the 1st pass statistics of x264, for this clip and the chosen parameters, trying to reach the same output size (not a similar visual quality):
x265 --crf 24 ~ x264 --crf 31.68
x265 --crf 18 ~ x264 --crf 25.17
x265 --crf 12 ~ x264 --crf 18.36
Not to be generalized!
Did you use slow first pass? This would give more correct crf values for x264

[Audionut]

not sure about Bitbucket,

Bitbucket parses the RST automatically like so: https://bitbucket.org/hudson/magic-lantern/src/fd5a7b3cb94d001c9bac60223576239d0744d125/modules/dual_iso/?at=unified

[LigH]

@ bxyhxyh:

I was not at all interested in "exact" CRF values for x264. Just in a vague notion that quality/bitrate relations of x264 and x265 have different magnitudes already, and x265 is not yet "finished" by far.

[qyot27]

Something about the CPU detection in the buildsystem is broken with the development tip (Ubuntu 13.10, x86). CMake reported that it couldn't recognize i686 as an x86 CPU and then disabled the assembly. Which is weird, considering it was detected properly with MinGW-w64 when I cross-compiled a couple days ago.

Obviously, changing the 'i386' to 'i686' in CMakeLists.txt enabled it to detect the CPU correctly and build the assembly. But it seems like something is getting in the way of properly detecting the CPU during configure.

[darkbasic]

Hi, I did an x264 vs x265 comparison at low bitrates. Here it is if someone is interested:

http://www.linuxsystems.it/2014/02/washed-video-x264-vs-x265-placebo-comparison/

I will add vp9 to the comparison but it will take 2.6 days to encode because it uses a wooden abacus to encode instead of my i7-3770K. Really, I tought it was broken before realising if was really that slow.

I just bought "The Hobbit: An Unexpected Journey" which is considered one of the best quality sources available, so next time I will rip directly from Blu Ray and I will choose an higher target bitrate.

[Procrastinating]

Essentially, currently x265 handles 8-bit low detail with high accuracy, and 8-bit high detail with low detail. Great for some anime, particularly at 10bit(where other features becomes less significant), not great for much else at this stage.

This has been the case since the dawn of x265, and key x264 features have not been implemented yet. It's not going to look nice on high-detail/grain footage until reasonable feature parity has been met.

I'll probably make some new 10bit comparisons once the devs feel that x265 has met relative feature parity with x264. Studios are starting to make not-terrible BD encodes of anime nowadays too, which makes 10bit all the more exciting!

With all that said, how is Main Still Frame coming along? Is that planned as a post-parity feature?

[sneaker_ger]

and key x264 features have not been implemented yet.
And those would be which?

[darkbasic]

Essentially, currently x265 handles 8-bit low detail with high accuracy, and 8-bit high detail with low detail.

I couldn't agree more, x265 HATES grain which is such a pity.

[foxyshadis]

Main Still is literally just setting the profile to 3 instead of 1 (Main) or 2 (Main 10), the only restriction from Main is that it can't have more than one frame. The default VUI doesn't even change to full range (PC levels) like JPEG, it has to be manually specified if you want that. Anyone could submit a patch to include it today, multicoreware probably won't write it unless there's some demand.

It's 8-bit and 4:2:0 only, though, which sucks. I'm waiting for a Still 10 4:4:4; in the meantime, since there's no difference, I'll just encode one frame to regular 10 or 10 4:4:4 and pretend it's still profile.

As for grain, it's mostly not feature parity anymore; cu-tree and AQ and weightp are all working. (Weightb is in the wings along with .) At this point it's aggressive tuning of AQ and mode decision for different profiles, because their current focus is 16-bit assembly functions to speed up Main 10, VBV, platform compatibility, and bugfixes. Tuning is great, but very time consuming when just implementing everything is pressing.

[x265_Project]

Main Still is literally just setting the profile to 3 instead of 1 (Main) or 2 (Main 10), the only restriction from Main is that it can't have more than one frame. The default VUI doesn't even change to full range (PC levels) like JPEG, it has to be manually specified if you want that. Anyone could submit a patch to include it today, multicoreware probably won't write it unless there's some demand.

It's 8-bit and 4:2:0 only, though, which sucks. I'm waiting for a Still 10 4:4:4; in the meantime, since there's no difference, I'll just encode one frame to regular 10 or 10 4:4:4 and pretend it's still profile.

As for grain, it's mostly not feature parity anymore; cu-tree and AQ and weightp are all working. (Weightb is in the wings along with .) At this point it's aggressive tuning of AQ and mode decision for different profiles, because their current focus is 16-bit assembly functions to speed up Main 10, VBV, platform compatibility, and bugfixes. Tuning is great, but very time consuming when just implementing everything is pressing.
We're definitely interested in supporting Main Still Picture. If the studies I've read are accurate, HEVC still picture has great potential as a more efficient image compression format.

The x265 development team is focused on achieving the best possible subjective visual quality. This includes further development/optimization of features that have already been implemented, tuning, porting / adapting of the remaining visual quality optimizations from x264, and ongoing algorithm development.

Tom

[x265_Project]

x265 0.8 is a regularly scheduled feature release

= New in 0.8 =

* 4:4:4 internal color space is now supported. Input pictures must also be 4:4:4, 8 or 10bit. We advise to disable weightp with 4:4:4. Note that since the HEVC Range Extensions are not finalized, this feature should be considered highly experimental. Our output streams may not be compliant with the final spec.

* Improved VBV. x265 will now do mid-frame QP adjustments in order to better meet the bit target. Further improvements will be in the next release (partial slice re-encode when bit budget is very tight).

* FPS is finally handled in a sane fashion. It may be configured as a rational number (numerator/denominator) or as a float. The frame rate is now signaled in the VPS header for use by the decoder.

* VUI signaling is now exposed in the x265_param structure and in the x265 CLI. The exact params and CLI options should be considered experimental at this point, and are liable to change.

* Near full ASM coverage of the 8bit build, and much more 10bit assembly than the previous release. All of the interpolation and intra primitives that were written with SIMD intrinsics have been replaced with assembly routines.

* Input pixel bit depth is now decoupled from the internal bit depth. An 8bpp build and a 16bpp build of x265 will both be able to encode 8bit or 10bit or 16bit raw video streams. The encoder will shift and mask pixels as necessary to get them to the internal depth.

* Motion compensated weight analysis. This will be further improved in the next release.

= CLI changes since 0.7 =

# Added #

--scenecut <integer>
-i/--min-keyint <integer>

--vui
--sar <int:int|int>
--overscan <string>
--videoformat <string>
--range <string>
--colorprim <string>
--transfer <string>
--colormatrix <string>
--chromaloc <integer>
--[no-]fieldseq
--[no-]framefieldinfo
--crop-rect <string>
--timinginfo
--nal-hrd
--bitstreamrestriction
--subpichrd

See CLI help for descriptions

# Replaced options, to sync with x264 #

--refresh <integer> is now --[no]open-gop --frame-skip <integer> is now --seek <integer> -i/--keyint <integer> is now -I/--keyint <integer> (short opt case change)


= Upcoming work =

The next release will focus on improving all of the recently added features, particularly VBV and adaptive quant, and focusing heavily on improving perceptive visual quality.

[darkbasic]

http://www.linuxsystems.it/2014/03/new-screenshots-comparator-loads-new-x264-x265-vp8-vp9-tests/

Congratulations to the x265 team: at low bitrates x265 completely CRUSH x264 if you use a very high quality source like the Blu-ray of “The Hobbit: An Unexpected Journey”.
Hopefully in the future it will improve at high bitrates too. hi10p is just too bugged to be useful right now.

[LigH]

And don't forget to release a current Evaluator's Guide as well, please.

[x265_Project]

And don't forget to release a current Evaluator's Guide as well, please.

x265 Evaluators Guide March 4 2014.pdf (https://bitbucket.org/multicoreware/x265/downloads/x265%20Evaluators%20Guide%20March%204%202014.pdf)

[Kurtnoise]

What does the "NOT IMPLEMENTED" flag mean exactly in the VUI options ?

[Kurtnoise]

http://chromashift.org/x265_builds/
Currently it is doing ICL64 and MSVC2012 builds (8bpp and 16bpp) nightly.

Server is in Europe, and I have no intention of ceasing builds.

dude, may we have also the mingw64 builds please ?

[Daemon404]

dude, may we have also the mingw64 builds please ?

Why? There's no discernible benefit.

[Kurtnoise]

In order to make some comparisons between each compilers...

[Selur]

@Kurtnoise: uploaded MinGW(32&64bit) builds of 0.8+40 here (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2306614&viewfull=1#post2306614)

[Daemon404]

In order to make some comparisons between each compilers...

I'm definitely not interested in adding an extra nightly build just for this.

[upyzl]

for whom wants to compare diff compilings: Google drive (https://docs.google.com/file/d/0B6cMPUGFjTn8UDhpbmg5M3hTYXc/edit?pli=1)

latest stable, vc12(u1)/icl14.0.2/gcc4.8.2, default and with AVX flag on
only 64bit 8bpp

[LigH]

v0.8+40 Win32 (XP enabled) and Win64 (cross-compile) also on my HEVC folter on MediaFire (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC).

[Marchand]

Built: 2014/Mar/10 - Version: 0.8+61-50d7910ddd61 - Hevc Video Encoder (32 and 64Bit)

x265-64bit-0.8+61-50d7910ddd61.zip (http://forum.videohelp.com/attachments/24010-1394491956/x265-64bit-0.8+61-50d7910ddd61.zip) (759.6 KB)
x265-32bit-0.8+61-50d7910ddd61.zip (http://forum.videohelp.com/attachments/24011-1394491956/x265-32bit-0.8+61-50d7910ddd61.zip) (759.6 KB)

[Atak_Snajpera]

# Replaced options, to sync with x264 #

--refresh <integer> is now --[no]open-gop --frame-skip <integer> is now --seek <integer> -i/--keyint <integer> is now -I/--keyint <integer> (short opt case change)

Good idea. Why not to replace even --y4m in x265 with --stdin y4m from x264?

[mandarinka]

= Upcoming work =

The next release will focus on improving all of the recently added features, particularly VBV and adaptive quant, and focusing heavily on improving perceptive visual quality.

Oh, I am looking forward to that last part, yay :)

[professor_desty_nova]

There's an error in the table "QUALITY PRESETS" of the latest Evaluators Guide. In "--aq-mode", the default is 1 not 2.
And on page 10, it has --b-adapt 1 as default, when 2 is the default.

PS: Isn't "(now it only enables B GOP structure)" on x265 help outdated ("--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4")? It is the same as version 0.3 when you didn't have b-adapt...

[x265_Project]

There's an error in the table "QUALITY PRESETS" of the latest Evaluators Guide. In "--aq-mode", the default is 1 not 2.
And on page 10, it has --b-adapt 1 as default, when 2 is the default.

PS: Isn't "(now it only enables B GOP structure)" on x265 help outdated ("--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4")? It is the same as version 0.3 when you didn't have b-adapt...

Thanks. I've posted a new Evaluator's Guide with these corrections.

[x265_Project]

Someone asked me the following question privately. For everyone to benefit from the answer, we prefer questions to be asked publicly (through our x265-devel mailing list, or on this forum). I've anonymized some details in the question...
What is the input format for 10-bit 4:2:0 into x265?

We used x264 for <our last project> and would like to use x265 for the 4k <version of our next project>. We would like to start developing our 10-bit <content>. We create most of <our content> natively in 4:2:0 to avoid down conversion loss.

Do you support P010 or P016 input? http://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

For x264, we used the QP min and max parameters and set the peak bitrate and buffer size. If we underflow, then we adjust the QP up. e.g. Most of our <content> was encoded with QPMax set to 0 and peak bitrate set to 40 Mbps. I believe Blu-ray 4k will be 60 Mbps peak. Some <content> had to be a higher QP (8 or 10) to not violate the VBV constraints.

Yes. x265 supports 10 bit YUV input. I believe it supports 12 and 16 bit input also, but this will be truncated to 10 bits/sample.
Using FFMPEG to create your YUV file, we support the following -pix_fmts...
yuv420p10le
yuv444p10le

For example, you can convert a ProRes 4444 10 bit MOV file to YUV 420 10 bit with the following syntax;
ffmpeg -i example_1920x1080_2997fps.mov -pix_fmt yuv420p10le example420p10.YUV

[Stacey Spears]

Thank you Tom.

Is yuv420p10le the same as the FOURCC P010? http://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

[Daemon404]

Thank you Tom.

Is yuv420p10le the same as the FOURCC P010? http://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx

No.

YUV420P10LE is planar.

[Stacey Spears]

No.

YUV420P10LE is planar.

P010 is planar.

[nevcairiel]

P010 is half-planar, Y is separate, and CbCr are interleaved, just like NV12 for 8-bit.
YUV420P10LE is completely planar, 3 separate planes for Y, Cb, Cr each.

[Stacey Spears]

Thank you nevcairiel, that helps. Are YUV420P10LE and YUV444P10LE actually documented anyplace?

[James Freeman]

I've missed the progression of this thread, but I have a question.

Is x265 up to par with x264? I remember not so long ago x265 would destroy the fine detail...
My real question is, is it good enough for professional studios to use it as the next blu-ray standard?

Thanks.

[LigH]

The ability to preserve details is being fixed and enhanced, there have been several patches changing some internal behaviour regarding motion vectors and quantization. So I believe it will be comparable in version 1.0; and I assume that professional studios won't get a commercial license much earlier anyway.

[sneaker_ger]

and I assume that professional studios won't get a commercial license much earlier anyway.
Not that they need one, GPL is free for commercial use.

[LigH]

Means, it will be each studio's own matter to contact the MPEG-LA for the created content in case of relevant amount and circumstances? Well, these details may be beyond this topic.

[James Freeman]

Thanks.

Time-wise, when x265 v1.0 will be ready to be licensed?
From what I've ready all over the net, the next Blu-Ray standard will be announced in 2014-2015.

[x265_Project]

I've missed the progression of this thread, but I have a question.

Is x265 up to par with x264? I remember not so long ago x265 would destroy the fine detail...
My real question is, is it good enough for professional studios to use it as the next blu-ray standard?

Thanks.
As x264 is the gold standard for production video encoders, and as we are porting and adapting x264 features into x265, we run extensive tests comparing the visual quality of x265 against x264 at the same bit rate. From an objective standpoint, x265 produces rate distortion curves that are substantially better (either with PSNR or SSIM) at any constrained bit rate. But the only thing that really matters is subjective visual quality. From a subjective standpoint, in our tests x265 produces better visual quality in the vast majority of test sequences. HEVC is especially stronger with respect to temporal noise. We're still working hard to fine-tune the encoding algorithms under all of the most challenging conditions (high motion with high detail at low bit rates), and we're still working to implement some x264 features like psy-rd.

So, the quick answer is - try it. Run x264 and x265 on the same clips at the same bit rate, play the video back and see what you think.

We've come a long way, but we're not done. You can expect a number of improvements that are focused on visual quality in the coming weeks.

Tom

[x265_Project]

Thanks.

Time-wise, when x265 v1.0 will be ready to be licensed?
From what I've ready all over the net, the next Blu-Ray standard will be announced in 2014-2015.
x265 is ready to license today. We have been reaching licensing agreements with leading video hardware, software and service providers for many months.

We will reach the 0.9 tag in the next couple of weeks. I don't expect to hit the 1.0 milestone until late April, but this is just a number. Most of the key HEVC encoding features are already implemented in x265 (v0.8). As we continue our work it will just keep getting better with respect to features, performance and encoding efficiency (visual quality at a given bit rate).

Tom

[James Freeman]

These are excellent news (for me).
Thank you very much Tom.

[benwaggoner]

So, the quick answer is - try it. Run x264 and x265 on the same clips at the same bit rate, play the video back and see what you think.
My overall experience has been that x265 is substantially superior to x264 at similar, challenging bitrates at UHD frame sizes.

[Atak_Snajpera]

For my test file x264 still wins

sample -> http://www.diktafon.atw.hu/112.MTS (http://www.diktafon.atw.hu/112.MTS)

CPU: Xeon E5-2690 @ 2.9Ghz ( 8C - 16T )

x264 --preset veryslow --crf 33.6 , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium --crf 30 , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g

frame 625 -> http://i.cubeupload.com/99I2GS.png
frame 1065 -> http://i.cubeupload.com/21QL6S.png

x265
frame 625 -> http://i.cubeupload.com/Jrl3mg.png
frame 1065 -> http://i.cubeupload.com/oHudEz.png

[benwaggoner]

For sample -> http://www.diktafon.atw.hu/112.MTS (http://www.diktafon.atw.hu/112.MTS)
That site gets blocked by my work network. Can you tell me its specs?

x264 --preset veryslow --crf 33.6 , encoding speed 8.3 fps , average bitrate : 2279 Kbps , file size : 16.3 MB
https://mega.co.nz/#!BE0nmTrZ!Nf6dG2BC4aBb3CBWdp9nPPIZj4bj7b2WEPbrWgz93YY

x265 --preset medium --crf 30 , encoding speed 7.7 fps , average bitrate : 2269 Kbps , file size : 16.3 MB
https://mega.co.nz/#!NN9mwbiY!2Zp4lN2bJ-zLbHWh9jGRKChDAjPk5ROwkID6on6Gs0g
I don't know if we want to be comparing x264 and x265 at the same bitrate AND the same encoding time at this point. We know that x264 has a lot more speed optimization than x265.

I'm not sure how well refined CRF is in x265, and it generally makes comparisons more complex. I'd suggest CBR so we are generally comparing similar bitrates throughout the file.

[x265_Project]

For my test file x264 still wins

Atak_Snajpera - Thanks for posting this. I like your test file (112.MTS). We downloaded this when you first posted it in December, and we've been using it for tests since that time. Waves on water are always a challenge for video encoders, as they contain high frequencies both spatially and temporally. At constrained bit rates, the question is - how do you handle it? Do you fail gracefully, or does the lack of bits cause visually obvious and objectionable artifacts? x264 and x265 handle the lack of sufficient bits in different ways. With x264 you see more temporal noise (inaccuracy in the actual edge or position of objects, or apparent motion where there should be none).

I know you understand this, but for those less experienced; you can't see temporal noise in a still picture, ... you need to watch the video. With x265 we see much lower temporal noise, but we see some areas that appear to be low-pass filtered. We've been working on this, and we have made a lot of progress in the past few months, but we're not quite there yet.

I've posted a couple of my encodes from 112.MTS here...
http://x265.org/video/112veryslow1500.264
http://x265.org/video/112_vslow_1500_25fps.hevc

Tom

[x265_Project]

I don't know if we want to be comparing x264 and x265 at the same bitrate AND the same encoding time at this point. We know that x264 has a lot more speed optimization than x265.

Agreed. The basic idea here is that HEVC gives us the coding tools to achieve higher compression efficiency, but you don't get that higher efficiency for free. It comes at the cost of higher computational complexity (higher compute resource requirements for a given level of performance, or slower performance on a given system).