x265 HEVC Encoder

[Boulder]

Originally Posted by benwaggoner

Gotcha.

It's not like SDR is more "real" pixels than HDR, it's just been the primary EOTF (Electro-optical transfer function) for the first decades of digital video. But gamma is a psychovisual optimization every bit as much as the PQ curve, just with simpler math that isn't optimal for a broader dynamic range.

It's really hard to work with HDR without a 10-bit HDR display and HDR-enabled tools, because what you see is not what you get. Encoders that are tuned for SDR aren't optimal for HDR, and vise versa. Optimal SDR needs lower QPs near black as code value steps are much more visible at the low end than the high end in SDR. HDR is much more perceptually uniform, and benefits from different optimizations like --hdr10-opt which would make near-dark look really bad if applied to SDR.

Yeah, it's sometimes difficult to grasp the idea that the PC monitor can fool you big time with HDR encodes..

My thinking was more or less around the fact that for example aq-mode 3 has not been recommended for HDR encodes because it will start allocating bits into all the wrong places. Now if this new automatic method uses all modes as it seems necessary, things could go quite wrong. A movie like Blade Runner 2049 might be a good test since it has both ends of the spectrum.

[benwaggoner]

Originally Posted by Boulder

My thinking was more or less around the fact that for example aq-mode 3 has not been recommended for HDR encodes because it will start allocating bits into all the wrong places. Now if this new automatic method uses all modes as it seems necessary, things could go quite wrong. A movie like Blade Runner 2049 might be a good test since it has both ends of the spectrum.

Gotcha.

Lots of algorithms assume perceptual uniformity across code values, so the difference between 16 and 17 is as important as between 234 and 235. And while that's not true for SDR, it is true for PQ, so I've seen non-SDR optimized algorithms that work better with PQ than SDR. However, if an algorithm has a low-luma bias for SDR, it will work quite a bit worse with HDR.

Hopefully the algorithm either ignores dark bias, or is adaptive based on the color space being encoded.

In the early years of HDR encoding, we fundamentally encoded everything as if it were SDR, avoiding any SDR-optimized tuning, and it worked okay. Later we got stuff like --hdr10-opt which specifically optimizes for HDR.

[Barough]

x265 v3.5+57
Built on October 26, 2022, GCC 12.2.0

https://bitbucket.org/multicoreware/.../branch/master


DL :
https://www.mediafire.com/file/9ohiddzw2yftl7w

[LigH]

MABS included a patch which should be commited soon in the x265 repo.

[Boulder]

Originally Posted by benwaggoner

Later we got stuff like --hdr10-opt which specifically optimizes for HDR.

I'm afraid this optimization is just adjusting QP offsets, for example this small snippet of a code. From what I gather, any luma level related aq-mode would be doing similar things on top or before that, which cannot be good practice.

if (param->bHDR10Opt)
                        {
                            uint32_t sum = lumaSumCu(curFrame, blockX, blockY, param->rc.qgSize);
                            uint32_t lumaAvg = sum / (loopIncr * loopIncr);
                            if (lumaAvg < 301)
                                qp_adj += 3;
                            else if (lumaAvg >= 301 && lumaAvg < 367)
                                qp_adj += 2;
                            else if (lumaAvg >= 367 && lumaAvg < 434)
                                qp_adj += 1;
                            else if (lumaAvg >= 501 && lumaAvg < 567)
                                qp_adj -= 1;
                            else if (lumaAvg >= 567 && lumaAvg < 634)
                                qp_adj -= 2;
                            else if (lumaAvg >= 634 && lumaAvg < 701)
                                qp_adj -= 3;
                            else if (lumaAvg >= 701 && lumaAvg < 767)
                                qp_adj -= 4;
                            else if (lumaAvg >= 767 && lumaAvg < 834)
                                qp_adj -= 5;
                            else if (lumaAvg >= 834)
                                qp_adj -= 6;
                        }

[jpsdr]

Build a release of current version with Patman mods.

https://github.com/jpsdr/x265/releases

[Stereodude]

Originally Posted by jpsdr

Build a release of current version with Patman mods.

https://github.com/jpsdr/x265/releases

Thanks for the builds. Sorry if this is a dumb question, but what's the difference between the standard build and the AVX2 builds? The standard one shows it has AVX2 enabled.

[jpsdr]

Standard is build with no specific arch instruction (for the C code part), so it will run on "any" CPU. The AVX2 build is build specifying AVX2 arch CPU instruction (for the C code part), so, it can't run on CPU without at least AVX2.

[LeXXuz]

Originally Posted by jpsdr

Build a release of current version with Patman mods.

https://github.com/jpsdr/x265/releases

Thanks a lot for this.

[benwaggoner]

Originally Posted by Boulder

I'm afraid this optimization is just adjusting QP offsets, for example this small snippet of a code. From what I gather, any luma level related aq-mode would be doing similar things on top or before that, which cannot be good practice.

Yes, it is exactly doing QP offsets for psychovisual improvements. IIRC, it's based on an IEEE paper from the mid 2010s. It's a pretty basic implementation with room for further enhancements, certainly. It can wind up raising QPs in the darks a little too much.

[jpsdr]

As i've said, i have some concern about possible flickering issue with sbrc. One possible "fix" would be some kind of "fuzzy" logic, but it's not always possible, another, easier to put is to have an hysteresis.

In my mod branch, i've made a patch to allow the possibility of an hysteresis in sbrc decision. Limit/range of hysteresis is for now totaly "out of the blue", no idea what to put (relative like i've done, static...).
No build made yet, your thoughts about it : https://github.com/jpsdr/x265/commit...20b89f8e78f255

Also, your thoughts about another possible sbrc tweak : add (another...) switch to allow X265_AQ_EDGE : X265_AQ_EDGE_BIASED instead of X265_AQ_EDGE : X265_AQ_EDGE_BIASED_SBRC.

Waiting your feedback...

[jpsdr]

Just thought !!!
Can sbrc be ported back to x264 ??? I don't think this feature exist.
If i'm so over it, it's because i found the idea (with some minor adjustments ) realy interesting !

[ShortKatz]

Is there something special with --mcstf ? I'm getting a crash if I try to use it with my custom build HandBrake.

Edit: OK, all-clear. That is just a bug in the current code.
This patch does fix the crash: https://mailman.videolan.org/piperma...er/013521.html

Edit2: I think I will never use --mcstf for whole movies. This option does increase the encoding time for me 7 times.

[benwaggoner]

Originally Posted by jpsdr

Just thought !!!
Can sbrc be ported back to x264 ??? I don't think this feature exist.
If i'm so over it, it's because i found the idea (with some minor adjustments ) realy interesting !

There is a TON of great x265 features that should be back ported to x264. I know MCW contributed a lot of patches from x265 back, but not a lot made it into main. I would so love to have CSV logging, for example. And I know that code was contributed to x265 at least seven years ago.

[LigH]

New upload: x265 3.5+57-4d2890fe4

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit

News since v3.5+39:

   --[no-]sbrc                   Enables the segment based rate control, using its scene statistics. Default disabled

   --[no-]mcstf                  Enable GOP based temporal filter. Default 0

[LeXXuz]

Originally Posted by jpsdr

As i've said, i have some concern about possible flickering issue with sbrc. One possible "fix" would be some kind of "fuzzy" logic, but it's not always possible, another, easier to put is to have an hysteresis.

Haven't noticed anything so far. What kind of flickering would that be and where possible to look out for?

[jpsdr]

Possible situation...
If the calculated value is at the threshold value, check here.

[jpsdr]

I've also added the option to use AQ-MODE 5 instead of AQ-MODE 1 in sbrc, and... i've made a build, it's on my github.
So you can play with both experimental options i've added...

[LeXXuz]

Originally Posted by jpsdr

I've also added the option to use AQ-MODE 5 instead of AQ-MODE 1 in sbrc, and... i've made a build, it's on my github.
So you can play with both experimental options i've added...

M'kay, sbrc was worth a shot. I've seen that flickering now. Unbearable.
Not sure if aq-mode 5 + sbrc would change anything on that.

I guess I will test a little more with just aq-mode 4 and 5 now. aq-mode 3 does improve faint details in very dark scenes slightly where aq-mode 2 fails, even with generous CRF values of 18 and below. The opening scene of Thor (2011) is one of these rare cases where x265 doesn't spend enough bits with aq-mode 1/2 for that scene and the result looks awful. Even CRF 16 with the Very Low preset +rskip and -sao didn't change anything on that.

But I think aq-mode 3 just wastes too much bits in general compared to the other aq-modes. Even clips with no dark scenes at all get much bigger than with mode 2, which I don't quite understand to be honest.

[jpsdr]

Sure flickering is because of sbrc ? I was just talking of a rare theoretical possible situation sbrc may produce...
But if it's because of that, the hysteresis option may help, it's for that case i've made it.