Handling reddish, chroma-heavy scenes

[Z2697]

Are you going to submit your patch and findings to x265?

I just submitted an issue because I think reverting a commit of their own doesn't necessitate a patch...

[microchip8]

Good luck. They seem to have abandoned x265 development. Many outstanding issues on their tracker that are not addressed

[GeoffreyA]

I just submitted an issue because I think reverting a commit of their own doesn't necessitate a patch...

Fingers crossed. Hope something comes of it.

Good luck. They seem to have abandoned x265 development. Many outstanding issues on their tracker that are not addressed

It's sad because I get the impression there's still "juice in the tank" with regards to improving the encoder. And with VVC/x266 dead, it's important.

[microchip8]

Oh, there's definitely more to improve and fix! I do not know what MultiCoreWare are doing all day (sipping coffee?) but even on the ML, patches sent are not merged or commented on. So, it's dead, Jim. There's quite a lot that can be improved in relation to quality improvements and fixes. Maybe they think it's "good enough" and leave it at that. On the other hand, x264 still merges fixes for issues or new patches (mostly for others than amd64 archs). There is very little that can be improved wrt quality in x264 so that is mostly done. BugMaster still merges stuff he receives from others...

[GeoffreyA]

akupenguin, Dark Shikari, and other legends wrung every last drop of quality from x264. It seems that will never be the case for x265. In 2024, there were some tests on a Mulholland Drive clip, very grainy and challenging bitrate, and I remember that rwill's HEVC encoder from work held up well, beating x265. Just one instance to show that it hasn't reached the full potential of HEVC.

So, yes, perhaps they're sipping coffee at MCW headquarters, resting on their laurels. Enthusiastic work is mostly going into improving the SVT-AV1 forks.

[microchip8]

To be honest, I've always found x265's picture to be softer than that of x264. The latter really brings out the details but suffers from other things (in 8-bit mode). Even if you disable in x265 all of SAO, selective SAO, strong intra smoothing and lower deblock to -3,-3, it's still not on-par with x264's detailed image.

These days I mostly encode HDR content and am forced to use x265 via ffmpeg as it has robust (not perfect) HDR support. Technically, HDR can be added to x264 too but I'm not sure how compatible that will be with devices. BT.2020 colorspace is no problem for x264 as it already supports it. It's things like master-display and max-cll that's missing.

MCW promised us x266, but seeing how they made x265, even if the former does come out, I am/will be skeptical of its quality

[Z2697]

x264 does support master-display and maxcll (they are SEI).
Namely --mastering-display and --cll.
And FFmpeg does support "copy" them over when source has them.

[GeoffreyA]

To be honest, I've always found x265's picture to be softer than that of x264. The latter really brings out the details but suffers from other things (in 8-bit mode). Even if you disable in x265 all of SAO, selective SAO, strong intra smoothing and lower deblock to -3,-3, it's still not on-par with x264's detailed image.

It's a trend with the modern codec. But I was surprised to see recently, with libaom, that if you drop the CRF substantially, say about 10, it preserves heavy grain quite well.

I just submitted an issue because I think reverting a commit of their own doesn't necessitate a patch...

Using the Soho1 clip, I made a set of encodings with different offsets in the mainline x265 and your patched version. The bitrate increase is on par with x264.

https://i.imgur.com/fl2weFW.png



--input-depth 8 --output-depth 10 --dither --preset slow --crf 21 --no-sao --deblock=-1:-1 --aq-mode 1 --cbqpoffs %%x --crqpoffs %%x
-c:v libx264 -crf 22 -preset veryslow -tune film -x264-params chroma_qp_offset=%%x

// I see I forgot to use 10-bit for x264 :)

[microchip8]

x264 does support master-display and maxcll (they are SEI).
Namely --mastering-display and --cll.
And FFmpeg does support "copy" them over when source has them.

I did not know that. But can devices play such H.264 HDR files?

[Sunspark]

The chroma algorithm you use in the renderer has a noticeable effect on reds and some other colours. I find some algos makes stuff appear too saturated or punchy.

My personal preference is Mitchell-Netravali. Colours look right and reds are not saturated.

Bicubic 60 also works well, but I like M-N more.

[Z2697]

It's a trend with the modern codec. But I was surprised to see recently, with libaom, that if you drop the CRF substantially, say about 10, it preserves heavy grain quite well.

Wouldn't it be much more surprising (in a bad way) if it doesn't?

[GeoffreyA]

Wouldn't it be much more surprising (in a bad way) if it doesn't?

Well, with modern codecs, too much is upside down, so when they do something right, it raises one's eyebrows.

[Z2697]

Well, with modern codecs, too much is upside down, so when they do something right, it raises one's eyebrows.

Which ones you think are categorized as modern, by the way?

[GeoffreyA]

The chroma algorithm you use in the renderer has a noticeable effect on reds and some other colours. I find some algos makes stuff appear too saturated or punchy.

My personal preference is Mitchell-Netravali. Colours look right and reds are not saturated.

Bicubic 60 also works well, but I like M-N more.

I wonder which is a good default for scaling chroma.

Which ones you think are categorized as modern, by the way?

Post-HEVC: AV1, VVC, and afterwards. To be sure, though, H.264 represents an important point, an era.

Adapting the words of Madam from Blade Runner 2049, "The world is built on a wall. It separates the old codecs from the new." :-)

[microchip8]

Adapting the words of Madam from Blade Runner 2049, "The world is built on a wall. It separates the old codecs from the new." :-)

... tell them there is no wall, and the old codecs beat the new ones! :D

[GeoffreyA]

... tell them there is no wall, and the old codecs beat the new ones! :D

The ancients are venerable and mighty!

[Z2697]

I want to add some more information, about why I chose to remove the psy-rd check.

First, to be clear, x264 has this check, to this day.

But I ran a little experiment with no-psy or psy-rd=0, and found that the effect of chroma offsets in x265 is weaker than x264, again.
UPDATE: also having that adversarial effect when offsets are extreme (https://forum.doom9.org/showthread.php?p=2027370#post2027370): the filesize is bigger, but the quality is worse.*
So without further investigation, I just yanked it out, and the effect is... stronger. (maybe too strong at this point)

It's probably not the most clever thing to do, but it gets the job done, at least, apparently.
I don't have much interest in going deeper into this rabbit hole, so I just leave it like this.

If anyone is interested, please dig deeper.

* In both cases, I think the increase in filesize is due to intra frames being actually higher quality (but maybe not much), and the worsening in quality is due to inter frames having lower quality.