Brightness fluctuations with gpu-next, HDR10+ Profile B

[FCrane]

Important Information

Provide following Information:

• mpv version: Nightly from 22.10.2023, Shinchiro build, libmpv-2.dll
• Windows Version: 11
• Source of the mpv binary: see above
• If known which version of mpv introduced the problem: not sure

Reproduction steps

I have 2 videos encoded with HDR10+ Profile B and both show strange brightness fluctuations with gpu-next. Brightness (and probably colors) are changing repeatedly and constantly. It's very visible, from dark to bright and vice versa. HDR10+ Profile A files seem to display correctly.

Is this a known issue?

[FCrane]

Here's the Mediainfo:

Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main 10@L5@Main HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible Codec ID : V_MPEGH/ISO/HEVC Duration : 25 min 47 s Bit rate : 13.9 Mb/s Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:0 (Type 2) Bit depth : 10 bits Bits/(Pixel*Frame) : 0.070 Stream size : 2.50 GiB (96%) Default : Yes Forced : No Color range : Limited Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant Mastering display color primaries : Display P3 Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

[FCrane]

Oh my, brightness flickering also happening with this file:

Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Main 10@L5@High HDR format : SMPTE ST 2086, HDR10 compatible Codec ID : V_MPEGH/ISO/HEVC Duration : 1 h 36 min Bit rate : 14.0 Mb/s Width : 3 832 pixels Height : 1 596 pixels Display aspect ratio : 2.40:1 Frame rate mode : Constant Frame rate : 23.976 FPS Color space : YUV Chroma subsampling : 4:2:0 (Type 2) Bit depth : 10 bits Bits/(Pixel*Frame) : 0.095 Stream size : 9.42 GiB (95%) Title : 2160p23.976 Language : English Default : Yes Forced : No Color range : Limited Color primaries : BT.2020 Transfer characteristics : PQ Matrix coefficients : BT.2020 non-constant Mastering display color primaries : Display P3 Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2 Maximum Content Light Level : 1000 cd/m2 Maximum Frame-Average Light Level : 147 cd/m2

So it doesn't seem to only affect HDR+ Profile B!

[FCrane]

Something's wrong (again) with HDR decoding!

Rolled back to "mpv-dev-x86_64-v3-20230430-git-6d422b3.7z" now and this one at least works for regular HDR and does not show the annoying startup delay I mentioned in another issue! HDR+ Profile B however is also not displaying correctly with the older build...

[quietvoid]

Samples where?

[FCrane]

Sorry, but it's not possible to add larger samples here in Github and the suggested https://0x0.st/ does not work! Just tried..

Where should I upload the samples?

[quietvoid]

If you can reproduce at specific timestamps you can use either of ffmpeg or MKVToolNix to extract that part out into a smaller file. It has to be under 512M.

[FCrane]

You can create a repo, then relelase your sample

Really? That's too much effort for such a simple task...

[FCrane]

If you can reproduce at specific timestamps you can use either of ffmpeg or MKVToolNix to extract that part out into a smaller file. It has to be under 512M.

I already have extracted clips around 350 MB, but https://0x0.st/ is not working!!! First of all, https uploads (as suggested in the instructions) are not accepted and when I upload the clip with http it seems to work, but can not be downloaded! (Internal server error).

https://0x0.st/ is unusable!

[FCrane]

Here are the 2 clips:

https://we.tl/t-tKs6pyjtTd

Downloads only available for 7 days though...

[quietvoid]

What title is the HDR10+ sample from?

The HDR10+ metadata has brightness changes in the middle of the shots. Also the current libplacebo code reads from the MaxSCL and that has very high brightness compared to the histogram, so the resulting image is too dark. The histogram is a lot smoother here and would probably not exhibit these issues.

Either way, blame the metadata author. In the meantime you haven't shared your config and this should only happen with --tone-mapping=st2094-40.

As for the 2nd HDR only file, you will have to provide a specific timestamp. It's probably just related to the peak detection rolling average, though.

[FCrane]

The HDR+ clip is from the TV series "Frasier 2023", episode 3, captured from some streaming service (I don't know which one). I think it was streamed like that without the metadata being changed. Tone mapping is set to "auto" - see attached config. mpv.zip

The brightness changes in the second clip occur every few seconds - it's actually quite easy to see. But as an example: Timestamp 00:00:20.520 is bright, the next frame visibly darker... Or 00:00:53.345 is bright, next frame dark. And so on... Jumping brightness all over the clip. This didn't happen with the older version of mpv DLL with the exact same config.

[quietvoid]

Since tone-mapping=auto doesn't use HDR10+ metadata, your issue has nothing to do with HDR10+. It's all caused by the latest peak detection smoothing tuning, which is pretty aggressive.

You can try going back to the old defaults with

--libplacebo-opts=peak_smoothing_period=100.0,scene_threshold_low=5.5,scene_threshold_high=10.0

[FCrane]

But the brightness fluctuations also happen when peak detection is disabled with "hdr-compute-peak = no"... Something seems to be broken (again) in the newer versions. And why was the smoothing made more aggressive if it causes problems in many videos?

[quietvoid]

Because when you disable peak detection it falls back to the bad HDR10+ metadata... See also https://github.com/mpv-player/mpv/issues/11581, same issue.

Using MaxSCL is apparently not great for some files.

[FCrane]

The second clip is not HDR10+ but just HDR. And it also changes brightness even with peak detection off. Older versions of libmpv display the clip correctly.

[quietvoid]

That doesn't make any sense. I can't see any brightness changes when playing the 2nd sample video. With this mpv --no-config --vo=gpu-next --hdr-compute-peak=no Test2HDR.mkv.

[FCrane]

So any news on this? I just downloaded the latest Nightly (04.02.24) and it still shows these annoying brightness fluctuations with hdr-compute-peak=on! Turning it off makes the videos too dark and dull, so it needs to be on. Old versions (from about a year ago) work perfectly fine with the same settings... Will this never be fixed?

Thanks!

[haasn]

Try:

hdr-peak-decay-rate=100
hdr-scene-threshold-low=5.5
hdr-scene-threshold-high=10

This should get you the exact old settings.

[FCrane]

Almost... Sometimes when a new scene is beginning (a "cut"), image starts darker than with the old version. During scenes, image is also often different - some details brighter, others darker, even with the exact same settings in the conf file. Not really sure what the reference should be though, so maybe the old version was "off" and the new is more correct ;-) I guess there have been other changes to the HDR processing as well resulting in different results that with previous versions.

So the question remains, why the defaults of the parameters you posted have been changed in a way that they produce horrible brightness issues?

Anyway, I guess I can start testing the new version with your settings, thank you! Now I just need to find out why it's starting so slowly (see my other posted issue #12753, which I also have no solution for and which also is unexplainable to me, because previous versions simply worked...

Thanks!

[haasn]

I mean, the peak detection algorithm changed, and it works on a completely different brightness scale. That's sort of why the values were changed. You'll have to play around with them.

I settled on the current defaults based on initial user feedback and sample files I was investigating. Clearly it was too aggressive.

[FCrane]

Thanks for all the info! Seems to work fine with your settings, so I'll stick with them! Finally I can use newer builds again ;-)

It would be nice if there was some kind of "standard" that always works, or at least a very comprehensive explanation of the parameters involved and how they play together, so that the end user can play around with them in a way that is more than just guessing or trial and error. After all there are several parameters (at least 5 or so) that seem to interact with each other and without detailed knowledge about the influence and functionality of each one, it's hard for me to tune the output.

Regards!