x265 HEVC Encoder

[Z2697]

Originally Posted by 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:


A patch was submitted:
https://mailman.videolan.org/piperma...ay/014363.html
and you can see the process of figuring out the fix at https://github.com/Mr-Z-2697/x265-ex...e/E-2025-05-12

[excellentswordfight]

Originally Posted by benwaggoner

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.

Originally Posted by _DLS_

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]

Originally Posted by excellentswordfight

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]

Originally Posted by tormento

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]

Originally Posted by TR-7970X

--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]

Originally Posted by Z2697

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]

Originally Posted by LigH

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]

Originally Posted by 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]

Originally Posted by tormento

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]

Originally Posted by 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)

"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]

Originally Posted by tormento

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]

Originally Posted by 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"...

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]

Originally Posted by 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"...

? 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.