x265 HEVC Encoder

[hellgauss]

Yes, you can also disable thread pools for even better quality!
(and watch the fps go down but let's not talk about that for now:cool:)

disable frame-threads you get 2% lower bd-rate.
disable thread pools you get 0.5% or less improvement (on top of the previous 2%).

If you have enough RAM, you can tune your scripts to run several encoding in parallel...
I find it useful for series, and also to tune % of %cpu usage if you need your PC for other tasks, especially if you run the encode in low priority (Windows).

[KarthikTdk]

Hi @all

Can i get reference code for H. 265 Encoder which should have 4:2:2 , 10 bit support

Thanks in advance
Karthik.

[RARY]

I find p1204.3, which combines full reference and bitstream analysis, to have the highest subjective correlation of currently available metrics. It includes chroma, even. VMAF is luma only, which causes a big blind spot, particularly with HDR content.

Of course, like VMAF and any other machine learning based metric, the quality of the results is highly dependent on training on the right ground truth data, and scores using different ML models will be different.


But, ITU-T P.1204 allows us to estimate video quality on a per-second MOS score basis. However, for frame-level quality assessment, metrics like VMAF or any non-references(blocking, blurring), with Tools like MSU VQMT would be a choice for detailed per-frame analysis.

is it or any better one than this?

[Z2697]

Hi @all

Can i get reference code for H. 265 Encoder which should have 4:2:2 , 10 bit support

Thanks in advance
Karthik.

Maybe this
https://vcgit.hhi.fraunhofer.de/jvet/HM

[benwaggoner]

But, ITU-T P.1204 allows us to estimate video quality on a per-second MOS score basis. However, for frame-level quality assessment, metrics like VMAF or any non-references(blocking, blurring), with Tools like MSU VQMT would be a choice for detailed per-frame analysis.

is it or any better one than this?
P.1204, done correctly, offers better correlation to subjective ratings for moving images. I don't think per-frame metrics are all that valuable in overall quality assessment or quality tuning. There's lots of stuff we can do that may give one frame poor metrics but isn't visible at normal speed playback, and lots of stuff we can do where each individual frame scores well, but discontinuities between frames cause a visible quality issue.

Per frame is helpful for diagnostics, sure. If I frame QP is lower than P, that's likely to cause issues. And if P, B, and b frames have consistent if small differences on some metrics, that can cause frame strobing and other artifacts.

But if I want to know how good someone subjectively would think a video looked, P.1204 is definitely the best available metric I've used. With the right ground truth data, it can get better than 90% correlation while VMAF can't really hit 80%.

The biggest downside is it is both full reference and bitstream level, so P1204.3 training is codec specific, and supporting a new codec requires a whole new round of test content and subjective ratings to train on. And if there are codec tools that weren't used in the test corpus, the training won't account for that tool either. VAMF doesn't really pick up on when --tskip is valuable, or adaptive quantization. the public VMAF model was originally just trained on x264 encodes using the same preset with varying --crf values. And VMAF's subjective correlation went down there more tools and tuning outside of that are implemented. VMAF was pretty bad at HDR until a bunch of HDR test content was made and subjectively rated, and an HDR-specific model was created.

The upside of VMAF is it is at least somewhat codec agnostic (and can be made much more so the bigger and more varied the content it is tested and trained on), and certainly better than PSNR or SSIM was.

Modern machine learning based metrics aren't really "a" metric. They're really just foundations that define the inputs a machine learning model can be run against. The actual model itself is the most important part, and that's really orthogonal to the metric itself. And they get a lot more accurate than the public model if an organization creates its own ground truth subjective ratings tuned around their content and scenarios.

I get a little frustrated when people talk about "VMAF scores" in the abstract without specifying the model that was used, as the same content can give quite different scores with varying accuracy based on the specific model used.

And also when the mean of scores for an hour long clip is presented as an overall quality, masking whether quality is consistently good or variably excellent or terrible.

How we measure and describe quality over time isn't something I've got a mechanism I'm confident in yet.

[RARY]

Is the VQMT tool metric's calculation accurate ?

For any reference metric, when I gave original sequences for both original and processed one and expecting high value i.e 100 ( based on scale ),
But there are some fluctuations in the score for few frames.

[benwaggoner]

Is the VQMT tool metric's calculation accurate ?

For any reference metric, when I gave original sequences for both original and processed one and expecting high value i.e 100 ( based on scale ),
But there are some fluctuations in the score for few frames.
“Accuracy” is more a continuum than a yes/no. I rate it by correlation with subjective MOS rating. It is also important to know what definition of “quality” you want to measure, and how that relates to the kind of “quality” that the metric is designed to measure.

Per frame quality numbers absolutely will vary, and also don’t always mean a whole lot, as we see video in motion. Great looking video can have frames with obvious artifacts if paused that are invisible (and thus don’t count) when being watched at normal speed.

No metric is or ever will be perfect. I like p1204.3, combining full reference and bitstream analysis, with a ML model trained on the breadth of content and compression being used.

[KarthikTdk]

Hi @all ,

What is syntax element , how we put our data in it and send it to binarization ,
Can anyone explain this , i am unable to understand the working of this , how quantization output is sending input to binarization

Thanks in advance

BR
Karthik

[RARY]

Any widely used implementation available for this p1204.3 standard along with videoParser?

I have been using https://github.com/Telecommunication-Telemedia-Assessment/bitstream_mode3_p1204_3 repo for a while.

[benwaggoner]

Any widely used implementation available for this p1204.3 standard along with videoParser?

I have been using https://github.com/Telecommunication-Telemedia-Assessment/bitstream_mode3_p1204_3 repo for a while.
That's what I know is available.

The software is fine (although some more optimization is always welcome). It's getting or building the right ML model with the right ground truth data that's the hard, expensive part. It was the hard part with VMAF as well; probably 90% of the expense was getting all the subjective rating tests generated and rated.

[asarian]

I am about to buy an AMD 99503D, which supports AVX-512 very well. I wanted to prepare a command line with --asm avx512, but fail to see avx512 as a valid string in the documentation any more. Are there still versions of x265 that support this?

[LigH]

Support for AVX512 certainly still exists, I just read it in the sources. But it will not be auto-detected. So add the parameter explicitly; if it is not supported either by hardware or by your OS, or being removed from the CLI without my knowledge, x265 will tell you when you execute it.

[asarian]

Thank you.

[TR-7970X]

Thank you.

I also have a 9950X3D, and I have this:- --asm avx512 in my x265 command line.

The documentation needs to be updated.

[asarian]

I also have a 9950X3D, and I have this:- --asm avx512 in my x265 command line.

Good to hear. :)

Can you tell me something about the performance boost using AVX512 gives? There are many charts on the 99050X3D, and even on them using x265, but never with AVX512 being used. I feel it will make quite a difference.

[LigH]

In general: In the past, the difference between AVX2 and AVX512 used to be marginal, and AVX512 has a higher risk of thermal throttling.

I can't tell you current results though, sorry. Try to search this thread for AVX512, I believe there have been reports a few months ago.

Like here (https://forum.doom9.org/showthread.php?p=2008991#post2008991)

[TR-7970X]

Good to hear. :)

Can you tell me something about the performance boost using AVX512 gives? There are many charts on the 99050X3D, and even on them using x265, but never with AVX512 being used. I feel it will make quite a difference.

I can't give you any info on performance, as I haven't been doing much recently, and I guess I just use it because I can.

I never noticed any thermal throttling with the 7950X, and I would suggest that the 9950X3D & the 7970X won't either, but I do have pretty good cooling.

But one thing I have noticed is 2 major typos in your post's, when referencing the 9950X3D !!!! :(

[Emulgator]

On a i9-11900K I found a few percent speed gain using -- asm avx512, limited by some of Intels safety features (limiting to base clock)
and the available cooling of a 125W CPU+115W GPU notebook system, although with plenty air intake, exhaust and 2x 5000rpm fan).

On a real desktop AMD 7950X/9950X I would expect considerable speed gains in the range of >25%, so well worth it.

[Z2697]

Unfortunatelly they are nowhere near 25% (compared to avx2)

[asarian]

In general: In the past, the difference between AVX2 and AVX512 used to be marginal, and AVX512 has a higher risk of thermal throttling.

That's the beauty if the 9950X3D! Allegedly it includes an extremely efficient implementation of AVX512, where the CPU doesn't reduce clockspeed for them, and only consumes a few Watt extra on AVX512. So, this should go endlessly better on the 9950X3D.

[rwill]

Unfortunatelly they are nowhere near 25% (compared to avx2)

Yeah, there are not that many situations in a HEVC encoder where one needs 512bit wide registers.

[Emulgator]

Yeah, there are not that many situations in a HEVC encoder where one needs 512bit wide registers.
True. I should have gone down to 15% in my estimate.
How many % speed advantage AVX2 vs AVX512 in the described scenario do 7950X/9950X owners note ?

[Z2697]

1%-1.5% and 5%-8% respectively, for at least the set of settings and hardwares that I tested with.
(why there's a range, because lower quality / bitrate have more speedup somehow)

[excellentswordfight]

True. I should have gone down to 15% in my estimate.
How many % speed advantage AVX2 vs AVX512 in the described scenario do 7950X/9950X owners note ?
1%-1.5% and 5%-8% respectively, for at least the set of settings and hardwares that I tested with.
(why there's a range, because lower quality / bitrate have more speedup somehow)
Sounds about right, I've seen about 5-8% with Xeon (Sapphire Rapids), and only 1-3% with 7000-series (Threadripper Pro). With the avx512 change in Zen5 i assume it should be about the same performance gain as the xeon.

[_DLS_]

I am about to buy an AMD 99503D, which supports AVX-512 very well. I wanted to prepare a command line with --asm avx512, but fail to see avx512 as a valid string in the documentation any more. Are there still versions of x265 that support this?

In my tests with the 9950X3D, the speed bump with --asm avx512 can be between 16-36% depending on the other settings too.

on 2160p:

CTU 32, ref 4, subme 4, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 3, tu-inter-depth 3, max-merge 5, crf 20 => +15.5%
CTU 64, ref 5, subme 5, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 4, tu-inter-depth 4, max-merge 5, crf 18 => +36%

Temps are manageable on air cooling.

[Z2697]

In my tests with the 9950X3D, the speed bump with --asm avx512 can be between 16-36% depending on the other settings too.

on 2160p:

CTU 32, ref 4, subme 4, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 3, tu-inter-depth 3, max-merge 5, crf 20 => +15.5%
CTU 64, ref 5, subme 5, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 4, tu-inter-depth 4, max-merge 5, crf 18 => +36%

Temps are manageable on air cooling.

Kinda too good to be true...

[Z2697]

x265 will produce nonconformity bitstream when a very sudden change in chroma channel happens and triggered weighted prediction.

https://bitbucket.org/multicoreware/x265_git/issues/996/weighted-prediction-delta_chroma_offset_lx
(Finally remembered my bitbucket account)

Related issue (4 years ago, when I didn't know the root cause): https://bitbucket.org/multicoreware/x265_git/issues/582

Many hardware decoders will fail to decode such frame, and result in corrupted output.

HM will abort due to assertion.


int pred = (128 - ((128 * wp[plane].inputWeight) >> (wp[plane].log2WeightDenom)));
int deltaChroma = (wp[plane].inputOffset - pred);
WRITE_SVLC(deltaChroma, "delta_chroma_offset_lX");


TL;DR: the deltaChroma in the code I referenced above should be in the range of [-512, 511], but there’s no check on the value of pred. For example if the value of pred is a fairly “large” negative number, the deltaChroma can exceed the range.

[benwaggoner]

In general: In the past, the difference between AVX2 and AVX512 used to be marginal, and AVX512 has a higher risk of thermal throttling.
More to the point "the difference between AVX2 and AVX512 used to be marginal, BECAUSE of AVX512 thermal throttling."

The per clock throughput improvements were solid, but the throttling reductions in instructions per second nearly cancelled those out. An implementation that maintains IPS with the IPC gains would be quite impressive.

[benwaggoner]

TL;DR: the deltaChroma in the code I referenced above should be in the range of [-512, 511], but there’s no check on the value of pred. For example if the value of pred is a fairly “large” negative number, the deltaChroma can exceed the range.
Good catch!

[asarian]

In my tests with the 9950X3D, the speed bump with --asm avx512 can be between 16-36% depending on the other settings too.

on 2160p:

CTU 32, ref 4, subme 4, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 3, tu-inter-depth 3, max-merge 5, crf 20 => +15.5%
CTU 64, ref 5, subme 5, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 4, tu-inter-depth 4, max-merge 5, crf 18 => +36%

Temps are manageable on air cooling.

Now we're talking! :thanks:

I heard +37% elsewhere (but didn't mention that yet, as I was looking for objective feedback). So, it now seems that number was quite accurate!

[Z2697]

x265 will produce non-conformative bitstream when a very sudden change in chroma channel happens and triggered weighted prediction.

Some "synthetic" inupt to trigger that bug :)

import vapoursynth as vs
core=vs.core
i=core.imwri.Read('a.png').resize.Bicubic(format=vs.YUV420P8,matrix=1)
f1=core.std.BlankClip(i,color=[16,16,16])

f1=core.std.Merge(i,f1,0.9)
f2=i
f3=f2.std.FlipHorizontal()

clip=f1*30+f2*9+f3*30 #69
clip.set_output()

(This does not mean only synthetic input can trigger the bug. There are "legit" buggy videos in the wild)
Example encoding commandline: vspipe aa.vpy -c y4m - | x265 --input - --y4m -b0 -o aa.265
I have to set bframes to 0, otherwise even with --weightb enabled, the weightd prediction won't catch up.
(Again this does not mean the bug will only be triggered when bframes=0)

I guess most images will work, but you can use this lovely nostalgic wallpaper:
https://files.catbox.moe/4c2bsn.png

A patch was submitted:
https://mailman.videolan.org/pipermail/x265-devel/2025-May/014363.html
and you can see the process of figuring out the fix at https://github.com/Mr-Z-2697/x265-experimental/tree/E-2025-05-12

[excellentswordfight]

More to the point "the difference between AVX2 and AVX512 used to be marginal, BECAUSE of AVX512 thermal throttling."

The per clock throughput improvements were solid, but the throttling reductions in instructions per second nearly cancelled those out. An implementation that maintains IPS with the IPC gains would be quite impressive.
I dont think this is totally true, i've encoded on pretty muc every generation of xeon and epyc with avx512 support, still have not seen over 10% improvement. And isnt that also expected, I dont see why an encoder like x265 would benefit that much from 512bit wide registers. And in the case with downclocking, it wasnt a marginal difference for the early implementations, it was more outright an performance regression. I think the only systems were this didnt happen was were you could allow for the huge increase in powerdraw.

In my tests with the 9950X3D, the speed bump with --asm avx512 can be between 16-36% depending on the other settings too.

on 2160p:

CTU 32, ref 4, subme 4, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 3, tu-inter-depth 3, max-merge 5, crf 20 => +15.5%
CTU 64, ref 5, subme 5, rd 4, rect, no-amp, aq-mode 2, tu-intra-depth 4, tu-inter-depth 4, max-merge 5, crf 18 => +36%

Temps are manageable on air cooling.
Can you share source and complete command line and build versions so this can be validated? I dont have a 9000-series, but I have plenty of systems with avx512 support and I have never seen anything close to this. Would be intresseting to see what the specific criteria is to get this increase.

[benwaggoner]

I dont think this is totally true, i've encoded on pretty muc every generation of xeon and epyc with avx512 support, still have not seen over 10% improvement. And isnt that also expected, I dont see why an encoder like x265 would benefit that much from 512bit wide registers. And in the case with downclocking, it wasnt a marginal difference for the early implementations, it was more outright an performance regression. I think the only systems were this didnt happen was were you could allow for the huge increase in powerdraw.
Yeah. While there are some simplifications possible with the bigger registers (fewer instructions per bit, easier byte alignment), if you're touching 2x the bits you'll need some more power and also more cooling because of that extra power.

It's somewhat more complex as AVX-512 also came with some better permute instructions and such that could allow for more efficient algorithm design, as did ARM's SIMD for bigger registers. How much improvement could be gained via better instructions versus just more width is highly architecture and algorithm dependent.

[tormento]

Can someone explain me the criteria that --crf-min and --crf-max use to increase/decrease CRF?

[TR-7970X]

Can someone explain me the criteria that --crf-min and --crf-max use to increase/decrease CRF?

--crf-max <0..51.0>
Specify an upper limit to the rate factor which may be assigned to any given frame (ensuring a max QP). This is dangerous when CRF is used in combination with VBV as it may result in buffer underruns. Default disabled

--crf-min <0..51.0>
Specify a lower limit to the rate factor which may be assigned to any given frame (ensuring a min compression factor).

[Z2697]

While qpmax is "global", crfmax is only effective when used together with VBV (and of course CRF itself, hence CRF + VBV aka "capped CRF").

BTW, Read The Manual.

BTW (A huge one)

VBV is non-deterministic (when it's engaged), VBV + const-vbv is deterministic (without significant quality drawback, if any, it's hard to do comparison because of the non-deterministic), but const-vbv is not enabled by default.

VBV + const-vbv + qpmax/crfmax (when "hit" by) + rskip=1 is non-deterministic again, use rskip=0 or 2 with this combination makes it deterministic again.
I guess that's related to how rskip=1 is doing skip decision using the RD cost, with 0 you don't skip and 2 is using edge density, which is independent from the RD stuff.

[tormento]

--crf-max <0..51.0>
Your answer is not an answer. It's the manual, that I just read and it arose doubts in me.

Thank you.

[tormento]

BTW
I just want to know what are the criteria used to increase, decrease QP.

SSIM? What?

[LigH]

The "rate factor" is a codec-specific internal metric of the HEVC algorithm, a kind of magnitude of difference between the original video and the reconstructed video, just calculated during the lossy compression, without actually reconstructing and subtracting. You may imagine the codec adding details to a coarse encoding result until a threshold of quality is passed. But the RF may vary for different GOP frame types (e.g. B frames may have a slightly bigger RF than P frames than I frames due to a dependency hierarchy) or due to an encoding mode trying to achieve a less variable bitrate for streaming instead of archival use or VBV restrictions. The two mentioned parameters force the RF in an explicit range and overrule the optimal RF calculated by quality or bitrate based decisions.

I bet Ben "Video Kenobi" Waggoner knows a lot more than me about that...

[tormento]

The two mentioned parameters force the RF in an explicit range and overrule the optimal RF calculated by quality or bitrate based decisions.
So, imposing them is a limitation and not giving more degrees of freedom?

I mean: I know that even setting a CRF, the bitrate can fluctuate a lot but I can't understand if there are no restraints but the vbv values.

In a few words: imposing qp-min and max gives less or more "freedom" to x265 encoder?

[LigH]

I believe to remember that some Presets / Tunings may limit the RF range. A maximum of 51 may be counterproductive to some uses. Don't count on me here, I would have to search the sources to be sure.

[Z2697]

While qpmax is "global", crfmax is only effective when used together with VBV (and of course CRF itself, hence CRF + VBV aka "capped CRF").

What else criteria do you need

(IDK how crf-min will work because... does VBV also increase bitrate?(apart from the "decrease over limit bitrate" we all know it does) otherwise why should we worry about minimum RF anyway?(I'm reluctant to call it CRF(constant rate factor) because it's certainly not constant anymore unless the limit is so high that it's never touched))

[benwaggoner]

In a few words: imposing qp-min and max gives less or more "freedom" to x265 encoder?
They give the encoder less flexibility. A higher min keeps the encode from getting deep into visually lossless even if there are bits available. Although having a meaningful --crf would set a higher minimum than qp-min. qp-min is something I've only used with CBR encodes.

qp-max will cap the maximum compression. I've never used it myself for anything. I'd be wary of it, because the encoder could get into states where it couldn't maintain VBV if qp-max is too low.

[Z2697]

VBV in x265 and x264 is a mess, and can well blow up quite easily (in x264 it's a little better, but still awful), I'd suggest stay away from it, especially as a way of reducing file size, unless you are limited by some target device and/or transmitting media (e.g. bluray)

("blow up" in image quality, the buffer itself is not that easy to break)

[benwaggoner]

VBV in x265 and x264 is a mess, and can well blow up quite easily (in x264 it's a little better, but still awful), I'd suggest stay away from it, especially as a way of reducing file size, unless you are limited by some target device and/or transmitting media (e.g. bluray)

("blow up" in image quality, the buffer itself is not that easy to break)
"unless you are limited by some target device and/or transmitting media" is basically were most of us live, of course. Streams need to work within a huge variety of HW decoders Profile and Level requirements.

Hence 2-pass, lookahead rate control, and lots of other mechanisms to maintain optimal quality with VBV on.

[benwaggoner]

So, imposing them is a limitation and not giving more degrees of freedom?

I mean: I know that even setting a CRF, the bitrate can fluctuate a lot but I can't understand if there are no restraints but the vbv values.
VBV limits the maximum peak bitrate, which provides a maximum average bitrate, but the ABR can also be way less. In a lot of common encoding scenarios the VBV isn't a factor 99% of the time.

In a few words: imposing qp-min and max gives less or more "freedom" to x265 encoder?
Less. When they aren't specified x265 can use anything in the possible range.

[Barough]

x265 v4.1+168-1e993ee
https://www.mediafire.com/file/aru29lv3c52vhmr

[LigH]

VBV does not only limit a maximum bitrate. In case of optical media it also limits a minimum bitrate because reading too slowly may cause loss of tracking, and filling the decoding buffer with more than one GOP causes the "buffer underrun"...

[benwaggoner]

VBV does not only limit a maximum bitrate. In case of optical media it also limits a minimum bitrate because reading too slowly may cause loss of tracking, and filling the decoding buffer with more than one GOP causes the "buffer underrun"...
Optical media is always full of exciting exceptions!

As is streaming to a lesser degree. People who just encode files for local playback don't know how easy they have it ;).

[cubicibo]

VBV does not only limit a maximum bitrate. In case of optical media it also limits a minimum bitrate because reading too slowly may cause loss of tracking, and filling the decoding buffer with more than one GOP causes the "buffer underrun"...

? There are no minimum required bitrate for physical media. Some decoders do choke with abysmal bitrates but that's an implementation problem.

Tracking is guaranteed at all time with the usual PMT, PAT and PSI repetitions in the transport stream.