vo=gpu-next is not stable during HDR10+ playback

[Zemax27]

Important Information

Provide following Information:

• mpv version : Git master at 2023-04-09
• Windows Version : Windows 10 or 11
• Source of the mpv binary : https://sourceforge.net/projects/mpv-player-windows/files/64bit/
• If known which version of mpv introduced the problem : Release 0.35.1 is stable
• Possible screenshot or video of visual glitches : https://0x0.st/H8PF.mp4

Reproduction steps

I playback this video (https://0x0.st/H8PF.mp4) with the following configuration. vo=gpu-next hwdec=auto-safe gpu-api=d3d11 gpu-context=d3d11 priority=high target-colorspace-hint=yes target-prim=auto target-trc=bt.1886 tone-mapping=linear

Same problem occurs if I use the configuration without tone-mapping or with auto target-trc and playback on HDR monitor vo=gpu-next hwdec=auto-safe gpu-api=d3d11 gpu-context=d3d11 priority=high target-colorspace-hint=yes target-prim=auto target-trc=auto

Expected behavior

Video playback without exposure instabilities / flickering

Actual behavior

Video playback with exposure instabilities / flickering

Log file

output.txt

Sample files

HDR10+ video

[quietvoid]

Your file doesn't really have stable metadata. Maybe libplacebo is too sensitive to the changes, have you tried playing it on a HDR10+ compatible device?

This is how the metadata looks to libplacebo:

[Zemax27]

Yes, I played it on a HDR10+ compatible smart TV through usb. I don’t see those instabilities on tv. The tv display has a peak brightness of ~300nits so the video is heavily tone-mapped. I don’t known if this can be relevant

[quietvoid]

Since the current implementation is a lot of guess work, it's probable that some things are different to "reference" implementations in actual HDR10+ devices.

When using the histogram instead of MaxSCL from the metadata, the brightness is a lot more stable.

It's a possible workaround, would have to reanalyze the specs used to see if they suggest the same.

[haasn]

I definitely think we should also try using the histogram if available.

Btw, @quietvoid libplacebo uses dot(rgb2luma, MaxSCL) instead of max(MaxSCL). That might lead to a more (or less) stable result

[Zemax27]

@quietvoid @haasn This is extracted from the HDR10+ standard. Hope that helps :)

[mitzsch]

@haasn May I ask if there is an option to disable hdr10+ processing? Something like --vf=format:dolbyvision=no but for hdr10+?

[kasper93]

--libplacebo-opts=tone_map_metadata=cie_y

[mitzsch]

@kasper93 Many thanks! May I ask if there is any further documentation about the tone_map_metadata= option and those suboptions? I have seen that there is also a hdr10 setting... Would like to know what those options do (and where the difference is between those)!

[ghost]

https://github.com/haasn/libplacebo/blob/d6f1db186d535f3d99d56165bb468de71d58dc6e/src/options.c#L999

[haasn]

As of current libplacebo git master, we ignore HDR10+ metadata by default unless you explicitly set the tone-mapping function to st2094-40. So, I believe this can be closed.

[Zemax27]

Hello @haasn, I think this issue cannot be closed. I still see instabilities when playback some HDR10+ files. Here attached a sample file: https://0x0.st/H4eE.mp4 mpv.conf to reproduce the issue:

vo=gpu-next hwdec=auto-safe gpu-api=d3d11 gpu-context=d3d11 d3d11-output-csp=pq priority=high target-colorspace-hint=yes target-prim=auto target-trc=auto

I also tested different configurations with multiple combination of hdr-compute-peak=yes / no ; libplacebo-opts=tone_map_metadata=cie_y / none And also converting the transfer function with target-trc=bt.1886 and removing d3d11-output-csp=pq , plus using tone-mapping=linear. The exposure instabilities are always visible. The correct playback behavior (as seen on compatible TV) is achieved when disabling libplacebo. Indeed the mpv configuration with vo=gpu correctly playback the video.

vo=gpu hwdec=auto-safe gpu-api=d3d11 gpu-context=d3d11 d3d11-output-csp=pq priority=high target-prim=auto target-trc=auto

[mitzsch]

Have you already tried --libplacebo-opts=tone_map_metadata=hdr10. Sure it will drop HDR10plus data, but maybe so the video is viewable....

[haasn]

I don't see any flickering in this clip with the HDR10+ metadata ignored.

[Zemax27]

@mitzsch yes, I have. It doesn't solve the issue. @haasn It is not a flickering issue but visible exposure jumps. They are quite strong toward the end of the video. For example at timestamps 10,901 sec vs 10,935 sec

This behavior is not visible using vo=gpu or by playback on compatible smart TV through usb.

[kasper93]

Is this maybe related to pretty aggressive peak detection? I think after recent changes, the smoothing is not really doing much.

[Zemax27]

@kasper93 as I wrote above, forcing hdr-compute-peak=no has no effect. I don’t know if it can help to identify the issue but setting tone-mapping=clip resolves the problem. By the way, it is not an option that users generally set.