x265 HEVC Encoder

[x265_Project]

Hi x265 community

i am working with x265 version 1.3+26-5acfb12ec5d1 . According to x265 documentation (http://x265.readthedocs.org/en/default/cli.html#quality-rate-control-and-rate-distortion-options)
the default value of aq-mode is 2 :

Adaptive Quantization operating mode. Raise or lower per-block quantization based on complexity analysis of the source image. The more complex the block, the more quantization is used. This offsets the tendency of the encoder to spend too many bits on complex areas and not enough in flat areas.

disabled
AQ enabled
AQ enabled with auto-variance (default)



However, actually the default of aq-mode is 0 (AQ disabled). Indeed, in param.cpp the following statement is executed:
param->rc.aqMode = X265_AQ_NONE;

So, pls. correct the documentation.
Hi Shevach,
On line 185 in param.cpp we set the default value...
param->rc.aqMode = X265_AQ_AUTO_VARIANCE;

For the Ultrafast or Superfast presets we turn it off...
if (!strcmp(preset, "ultrafast"))
{
param->lookaheadDepth = 10;
param->scenecutThreshold = 0; // disable lookahead
param->maxCUSize = 32;
param->searchRange = 25;
param->bFrameAdaptive = 0;
param->subpelRefine = 0;
param->searchMethod = X265_DIA_SEARCH;
param->bEnableEarlySkip = 1;
param->bEnableCbfFastMode = 1;
param->bEnableSAO = 0;
param->bEnableSignHiding = 0;
param->bEnableWeightedPred = 0;
param->rdLevel = 2;
param->maxNumReferences = 1;
param->bEnableLoopFilter = 0;
param->rc.aqStrength = 0.0;
param->rc.aqMode = X265_AQ_NONE;
param->rc.cuTree = 0;
param->bEnableFastIntra = 1;
}
else if (!strcmp(preset, "superfast"))
{
param->lookaheadDepth = 10;
param->maxCUSize = 32;
param->searchRange = 44;
param->bFrameAdaptive = 0;
param->subpelRefine = 1;
param->bEnableEarlySkip = 1;
param->bEnableCbfFastMode = 1;
param->bEnableWeightedPred = 0;
param->rdLevel = 2;
param->maxNumReferences = 1;
param->rc.aqStrength = 0.0;
param->rc.aqMode = X265_AQ_NONE;
param->rc.cuTree = 0;
param->bEnableFastIntra = 1;
As you run x265 from the command-line you can see the AQ strength reported on the screen...

C:\Testx265>x265 --input v:\Sequences\10_chinchilla_02_3840x2160_24p.yuv --input
-res 3840x2160 --fps 24 -f 240 -o d:\BBBunny_4000_24fps.hevc --csv c:\Testx265\R
esults\2PassDemos-2014-09-07-09-21.csv --bitrate 4000 -p veryslow --ssim --psnr
--pass 2 --psy-rd 0.7 --psy-rdoq 1.0 --stats v:\DemoBitstreams\Logs\BBBunny_4000
_stats.log
yuv [info]: 3840x2160 fps 24000/1000 i420p8 frames 0 - 239 of 240
x265 [info]: HEVC encoder version 1.3+117-ed4c9acafc11
x265 [info]: build info [Windows][MSVC 1700][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZ
CNT BMI2
x265 [info]: WPP streams / pool / frames : 34 / 8 / 3
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-6 (Main tier)
x265 [info]: CU size : 64
x265 [info]: Max RQT depth inter / intra : 3 / 3
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut : 24 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 5
x265 [info]: Rate Control / AQ-Strength / CUTree : ABR-4000 kbps / 1.0 / 1
x265 [info]: tools: rect amp rd=6 psy-rd=0.70 psy-rdoq=1.00 lft sao-lcu signhide
stats-read

[LigH]

After so many recent patches with speed-ups and fixes, now is probably a good time to release another build: x265 1.3+145-44cb33846e0e (https://www.mediafire.com/download/e52sw5dvxb2lsbg/x265_1.3+145-44cb33846e0e.7z)

Unfortunately, most speed-ups seem to be relevant only for AVX2 supporting CPUs, which I don't own... but a few are also rather generic.

[Daemon404]

Slightly off topic here: Is there any value in providing MinGW-w64 builds of x265 on chromashift?

If there is significant interest I will add it to the nightlies.

[SamKook]

Those are the one I use so I would say yes. They were running faster(or about equal for some) than all others on my 2600k last time I checked.

[LigH]

Not sure which kind of binaries you used to offer so far (since I build my own, I don't look much elsewhere); but at least AMD64 Windows builds are certainly of interest (Win32 not so much, 4K resolutions are hard-edge cases), and if you offer builds of the same revision by different compilers, one can even compare their speed (and you may find warnings only thrown by one of several).

[Daemon404]

Not sure which kind of binaries you used to offer so far (since I build my own, I don't look much elsewhere); but at least AMD64 Windows builds are certainly of interest (Win32 not so much, 4K resolutions are hard-edge cases), and if you offer builds of the same revision by different compilers, one can even compare their speed (and you may find warnings only thrown by one of several).

I only have offered Win64 built with ICL ans MSVC so far, nightly/morningly.

[foxyshadis]

Moved posts unrelated to x265 to a new devices thread (https://forum.doom9.org/showthread.php?t=171163).

[sneaker_ger]

Using default settings with --psy-rd 1.0 --psy-rdoq 1.0 results in the following line:
x265 [info]: tools: esd rd=2 psy-rd=1.00 lft sao-lcu signhide fast-intra stats-write

psy-rd 1.0 will also be written into the custom SEI. The docs say this should be impossible as at least rd 3 is required for psy-rd.

[Atak_Snajpera]

Using default settings with --psy-rd 1.0 --psy-rdoq 1.0 results in the following line:
x265 [info]: tools: esd rd=2 psy-rd=1.00 lft sao-lcu signhide fast-intra stats-write

psy-rd 1.0 will also be written into the custom SEI. The docs say this should be impossible as at least rd 3 is required for psy-rd.

Second or first pass?

[sneaker_ger]

It was a (fast) first pass - I overlooked that. The second pass does indeed use rd 3.

[MoSal]

typedefs are missing for the new structures in commit e5a24e5ba46e?

[x265_Project]

typedefs are missing for the new structures in commit e5a24e5ba46e?

Thanks MoSal. I've passed this along to the engineering team, but in the future it would be better if you would be able to provide software development feedback directly to the development mailing list (which all x265 developers read).

Tom

[x265_Project]

If you're in Amsterdam this weekend for the IBC show and you want to meet with us, please send me an email (tom . vaughan @ multicorewareinc.com). We've had many fantastic meetings so far, and I'm really excited for the future of x265 and UHDcode.

Tom

[a5180007]

Using default settings with --psy-rd 1.0 --psy-rdoq 1.0 results in the following line:
x265 [info]: tools: esd rd=2 psy-rd=1.00 lft sao-lcu signhide fast-intra stats-write

@sneaker_ger Beware, also no psy-rdoq when rd < 4.

[NikosD]

We've had many fantastic meetings so far, and I'm really excited for the future of x265 and UHDcode.

Tom

In a brief post, which are the main advantages of a commercial HEVC decoder (UHDcode) over free solutions like the FFmpeg based LAV filters ?

[x265_Project]

In a brief post, which are the main advantages of a commercial HEVC decoder (UHDcode) over free solutions like the FFmpeg based LAV filters ?

Our decoder is twice as fast as FFMPEG (we have done a great deal of performance optimization). This means that on a given system, our decoder can handle higher quality video (higher resolution, bit rate, frame rate). It's OpenCL accelerated, offloading much of the work to the GPU. This allows for more available CPU resources for the rest of the video application. It supports the full HEVC specification, including 10 bit video. It is very rigorously tested, and adopted by many commercial customers on a variety of platforms.

[nevcairiel]

It supports the full HEVC specification, including 10 bit video.

You keep saying that as if FFmpeg doesn't. FFmpeg supports 12-bit even, and RExt. :)
Regarding the speed, a lot of work is happening to SIMD the crucial parts, which will make FFmpeg more than twice as fast as it is now (as preliminary numbers indicate). But competition is a good thing, i hope. ;)

[x265_Project]

You keep saying that as if FFmpeg doesn't. FFmpeg supports 12-bit even, and RExt. :)
Regarding the speed, a lot of work is happening to SIMD the crucial parts, which will make FFmpeg more than twice as fast as it is now (as preliminary numbers indicate). But competition is a good thing, i hope. ;)
Sorry... I wasn't aware that it supported high bit depth.

Yes, it's takes a lot of development work to make things go as fast as possible, but I'm sure FFMPEG will get there. I don't want to sound critical of FFMPEG... we are big fans of and contributors to FFMPEG, and many other open-source projects.

[NikosD]

Our decoder is twice as fast as FFMPEG (we have done a great deal of performance optimization). This means that on a given system, our decoder can handle higher quality video (higher resolution, bit rate, frame rate). It's OpenCL accelerated, offloading much of the work to the GPU. This allows for more available CPU resources for the rest of the video application. It supports the full HEVC specification, including 10 bit video. It is very rigorously tested, and adopted by many commercial customers on a variety of platforms.

I searched a little your site and didn't find a trial or free demo of UHDcode just to test speed and compatibility.

Is it in a DS filter form ?

Do you provide a trial version that could be downloaded ?

[Gravitator]

You can take as an example to test this decoder > http://xhevc.com/en/downloads/downloadCenter.jsp
(Strongene PC OpenCL HEVC/H.265 Decoder for AMD)

Very quiet and not hear about these developments in terms of benefit / superiority on the forums.

[huhn]

You can take as an example to test this decoder > http://xhevc.com/en/downloads/downloadCenter.jsp
(Strongene PC OpenCL HEVC/H.265 Decoder for AMD)

Very quiet and not hear about these developments in terms of benefit / superiority on the forums.

he did alrady

works with nvidia and intel too.
http://forum.doom9.org/showthread.php?t=163110&page=17

newer lavfilter 64x builds can beat this openCL decoder already.

[Gravitator]

newer lavfilter 64x builds can beat this openCL decoder already.
DivX is preferable on my C2D.

[huhn]

DivX is preferable on my C2D.

so what?

[Gravitator]

so what?
Comes out that DivX a leader in decoding HEVC (at least on the weak processor).

[huhn]

I still wonder what this has to do with the x265 encoder.

[LigH]

(Back to encoders...)

Another "merge with stable" plus a few fixes — x265 1.3+185-2fb61cc75152 (https://www.mediafire.com/download/auvclatsanj1lkt/x265_1.3+185-2fb61cc75152.7z)

There was an interesting find in the VideoHelp forum, based on a quite extreme test with too little bitrate versus too much freedom (16 b, 16 ref) for a 1080p50 clip: The reconstructed video appears to introduce blends not present in the original. Is it possible that partially blending half the framerate gets preferred over encoding all frames?

[a5180007]

There was an interesting find in the VideoHelp forum, based on a quite extreme test with too little bitrate versus too much freedom (16 b, 16 ref) for a 1080p50 clip

The encoding has been done with Hybrid, filters and x265 parameters unknown (nothing in the SEI ?!?). I have not been able to reproduce these artefacts with x265 cli.

EDIT : artefact from http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2346046&viewfull=1#post2346046 reproduced with [1.3+198] x265 --crf 29 --psy-rd 0.1 --b-adapt 0 --bframes 16 --ref 16 --rc-lookahead 30 --ipratio 1.7 --pbratio 1.7 --seek 395 -o pj_crf29.hevc park_joy_1080p50.y4m

[xooyoozoo]

(16 b, 16 ref) for a 1080p50 clip

Slight tangent: the spec caps 'numpoctotalcurr' (unique L0 + L1 refs per frame) at 8 for all profiles and levels. The DPB can be larger if the extra frames are for later usage, but x265 puts any frame in the DPB immediately to use in either L0 or L1.

To be honest, I'm not sure why the x265 cli should allow breaking that cap at all. It's inviting potential decoder issues for little gain.

[a5180007]

Artefact is still present (although less visible) with the following profile-compliant encoding :

x265 --crf 29 --b-adapt 0 --bframes 16 --seek 395 -o pj_crf29.hevc park_joy_1080p50.y4m

[LigH]

Even the "pacebo" preset uses only 8 consecutive B frames and 5 reference frames as maxima, according to the presets documentation (http://x265.readthedocs.org/en/default/presets.html) (provided it is current and correct).

We should call this preset "homeopathic" (= "placebo forte"). :p

[Atak_Snajpera]

What has happened to 32 bit binaries of x265? Both executables at http://builds.x265.eu/ are 64 bit
http://i.cubeupload.com/7UGeSz.png http://i.cubeupload.com/qQbs81.png

[zerowalker]

Been a while since i last checked this.
At that time Psy-rdo was being implemented and fixed etc.

So how has it been since that time?

Any highlights?

Does it still make a "blurry mess" compared to x264 in normal scenarios?(sounds harsh, but you know what i mean;P).

Thanks

[LigH]

So you want us to spend our leisure time to test for you? ... Uhm, no. You can believe us telling you that x265 keeps developing and improving, or you can doubt it and test on your own... ;) Preferably with a CPU supporting AVX2.

[foxyshadis]

zw, check the comparison thread (https://forum.doom9.org/showthread.php?t=170986). sneaker is doing a bang-up job of encoding tons of comparisons for us, though more samples could always help.

[zerowalker]

So you want us to spend our leisure time to test for you? ... Uhm, no. You can believe us telling you that x265 keeps developing and improving, or you can doubt it and test on your own... ;) Preferably with a CPU supporting AVX2.

No, not at all;P

Simply wanted a statement if something big has happened.
And your answer makes me assume it's at a similar place as before. Which of course isn't bad.

Thanks

Foxyshadis, have looked there from time to time. So guess i have kept my self updated;)

[LigH]

As far as I understood, HEVC can't break the laws of Claude Shannon's theory of information. You want less data for a similar amount of information? Then you need to reduce redundancies. But you can't go below the entropy threshold. If you have less data, you will lose information. Therefore, expect compression algorithms with arbitrary target bitrates to be lossy; but the annoyance of this loss may vary among these algorithms. Information is a matter of interpretation. There may be enough for a summary, but not enough for a complete replication.

I have done several tests with very tight bitrates. In general, at about the same bitrates, HEVC appeared to preserve the overall content better, leaving less annoying artefacts than AVC where loss was inevitable. But I did not compare how much detail HEVC and AVC preserve when the bitrate is beneficial.

Also I tested the psychovisual features a bit and found that the strong bias for simplification may be counterproductive in specific cases where areas with very much energy (high image frequencies, much contrast) and very little energy are close together (e.g. curly hair next to a flat wall), but will probably hurt less when the "energy dynamics" is not so extreme across the frame (at least some structure everywhere).

By the way, the most recent patches of version 1.3 contain a lot of speed optimizations. But mainly for AVX2 and SSE3+... a Phenom-II is way below par now.

[zerowalker]

Understandable, like Moore's law there is only so much that can be done, though luckily here you can use tricks and illusions, while a physical limit is there to stay.

From my own understanding, and probably everyone else, it's as you say. Low bitrate and the HEVC will prevail while AVC/H264 will be a mess beyond compare.

Higher though, i think HEVC quite quickly losses against AVC/H264, and that's probably what most people are "disappointed", as when you hear H265, you would think (Oh it's H264 v2) or something;P

Interesting factors you noticed though, haven't really thought about them, as i just pretty much compare and say "This is the winner".

Ah great, remember that last i checked it was quite a bit faster compared to a while back (when it was Very Slow), so speeds, no matter what instructions are used (latest and greatest is of course understandable) is something that's very welcomed:)

[LigH]

I remember a similar comparison between MPEG2 and MPEG4-ASP (DivX). Already (what seems to be) decades ago, people stated that MPEG2 is better at preserving details for high bitrate circumstances.

Well, MPEG4-ASP can achieve the same level of detail preservation when using MPEG quantization instead of H.263, and possibly even custom matrices.

So I believe HEVC may be able to be on par with AVC too, with specific tweaks.

[Atak_Snajpera]

I still do not understand why film grain reconstruction is not part of HEVC standard? Is that hard to analyze original footage in terms of grain/noise characteristics and then try to reconstruct that grain/noise during decoding? Instead of that we have to experiment like idiots with AQ strength and with psy settings. I think that reconstructed grain/noise could look as good as original and the same time we could save more bits.

[LigH]

But it is instead already part of the MPEG4-AVC (H.264) specification? So its support is more or less mandatory for decoders? ... Probably yes; searching for "Film grain modeling" in the english Wikipedia directly leads to "H.264/MPEG-4 AVC: Software encoder feature comparison (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison)" (Interesting: English Wikipedia reports no support for x264 despite its "--nr" parameter, so this seems to be less complex than "a visual version of Spectral Band Replication".)

Its implementation, though, seems to be very sparse, for both AVC encoders and decoders. Apparently, not even JM reference software implemented it yet for AVC, not to mention HEVC. The complexity of such algorithms is certainly quite high.

DarkShikari tried some Film Grain Optimization (I believe that was reordering of grain patterns for compressibility instead?) back in 2008.

[zerowalker]

Didn't know that, thought it was always better than MPEG2.
But AVC is always better than MPEG2 right, i mean, MPEG2 needs like 10mbps while x264 can look similar at 3mbps (or something), so it's not really comparable.
But of course if both are at 50mbps they will look the same (for SD and some HD material).

[Gravitator]

I still do not understand why film grain reconstruction is not part of HEVC standard? Is that hard to analyze original footage in terms of grain/noise characteristics and then try to reconstruct that grain/noise during decoding? Instead of that we have to experiment like idiots with AQ strength and with psy settings. I think that reconstructed grain/noise could look as good as original and the same time we could save more bits.
Hi! I have previously suggested such a method > vhelp.com (http://forum.videohelp.com/threads/360069-x265-HEVC-Encoder?p=2318174&viewfull=1#post2318174)
Approximate emulation - noise analysis and transmission of information for filter (example MadVR will use it for a more accurate noise generation - take from the stream HEVC).
+ For interest

Experiment with the settings and achieve additional visual quality.
--------
Look at the left part of the costume (dark scene - a complicated scene) > MadVR vs EVR.7z (http://forum.videohelp.com/attachments/23940-1394141284/MadVR%20vs%20EVR.7z) (source (http://forum.videohelp.com/threads/362892-Upgrading-madvr?p=2306667&viewfull=1#post2306667))

[sneaker_ger]

But it is instead already part of the MPEG4-AVC (H.264) specification? So its support is more or less mandatory for decoders? ... Probably yes; searching for "Film grain modeling" in the english Wikipedia directly leads to "H.264/MPEG-4 AVC: Software encoder feature comparison (http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison)" (Interesting: English Wikipedia reports no support for x264 despite its "--nr" parameter, so this seems to be less complex than "a visual version of Spectral Band Replication".)

We had a short discussion here (http://forum.doom9.org/showthread.php?t=171195). Both AVC and HEVC have this model but it is optional for decoding. It's not used for references.
x264's --nr and --fgo (not in vanilla x264) are pure encoder side features AFAIK. I don't know why fgo never made the vanilla builds (superseded by psy-rd?) or if it worth looking at for the x265 devs.

[foxyshadis]

Noise analysis isn't particularly hard -- merely denoising, differencing, and analyzing the remainder is easy. Compressing, storing, and reconstructing it is hard, though, and requires a huge amount of processing power (or silicon area) to recreate the character of the noise, depending on how granular you want to be -- one value for the whole frame, all the way down to one value per macroblock. FGO applies to full frames, but has not one but two entirely different ways of emulating grain, both of which can be used; one uses frequency values and an iDCT, one is basically Tom Barry's AddGrain filter. With zero guidance in the spec on how to build such a decoder, aside from the abstract principles, it's no wonder that most don't bother.

[lotusgg]

Noise analysis isn't particularly hard -- merely denoising, differencing, and analyzing the remainder is easy. Compressing, storing, and reconstructing it is hard, though, and requires a huge amount of processing power (or silicon area) to recreate the character of the noise, depending on how granular you want to be -- one value for the whole frame, all the way down to one value per macroblock. FGO applies to full frames, but has not one but two entirely different ways of emulating grain, both of which can be used; one uses frequency values and an iDCT, one is basically Tom Barry's AddGrain filter. With zero guidance in the spec on how to build such a decoder, aside from the abstract principles, it's no wonder that most don't bother.

Why no make it a 3rd(or second in CRF cases) pass just for calculating, compressing and storing this "noise"?

[foxyshadis]

Why no make it a 3rd(or second in CRF cases) pass just for calculating, compressing and storing this "noise"?

You have to do it before or at the same time the video is encoded, because you analyze and remove the grain prior to encoding. There's no need for an extra pass. The big problem is on the decoder side, anyway, not the encoder side.

[lotusgg]

You have to do it before or at the same time the video is encoded, because you analyze and remove the grain prior to encoding. There's no need for an extra pass. The big problem is on the decoder side, anyway, not the encoder side.

I see.
This is goind to be a hard hit on mild processors.

[Parabola]

To me, the trickiest thing is that the parameters are set per-frame (OK, granted, you might be able to tile/slice to apply grain differently per set of CTUs).

You would have to check that the grain exists in the whole area to which you are applying it. Otherwise, you can imagine that, for example, if encoding a grainy old movie with modern crisp, clean, CG captions, you could easily get grainy captions at the decoder.

-John

[LigH]

Thank you all for sharing your thoughts. This supports my impression of a complex topic.

If decoder support is not mandatory, then I could imagine that encoder-only support might instead cause a flattened reproduction with decoders not supporting it, and I don't dare to imagine if it will look rather good (denoised) or bad (lowpass-quant-blurry).

[smegolas]

You have to do it before or at the same time the video is encoded, because you analyze and remove the grain prior to encoding.

Therein lies the problem. Removing noise/grain without compromising image quality is not trivial.