Whiter than white (236-255) support.

[whataboutpereira]

I've tried to get whiter than white working to no avail. Is it possible with MPC Video Renderer?

Setting the GPU to output 16-235 or 0-255 both result in white not going past 235.

With MadVR it's possible to get whiter than white when MadVR is in 16-235 mode and GPU in 0-255, but MadVR has other issues with Windows 11. :)

[Aleksoid1978]

Do you use DX9 or DX11 ?

[whataboutpereira]

DX11, 12-bit output in NVidia control panel, RTX 3070, Windows 11.

I just cycled through DX9 also and 8 and 12-bit modes but they all seem to be the same.

[Aleksoid1978]

Try use Shader video processor - uncheck NV12/P010/P016/YUY2 and Other ...

[whataboutpereira]

No change. Also curious that I had to change TV black level to "high" to display correct blacks with MPC renderer and GPU output at 0-255.

MPC-BE + MadVR, Potplayer + MadVR, Kodi, VLC work with black level low. MPC-BE with MPC rendered needed high.

Fortunately I now see the HDR colour issues with Potplayer + MadVR don't manifest atm with MPC-BE + MadVR.

[Aleksoid1978]

I don't understand you. Can you made screenshot for compare ?

[v0lt]

What you want is unclear to me. It looks like some kind of experimentation on your part. I don't think there is any bug here.

For proper video output, my advice would be to do a driver reset. Then set the full range and RGB format for the display. Just for the display, not in the video settings.

I also advise you to disable the message about the type of content for displays connected via HDMI, forcing the "programs on the desktop" type.

[v0lt]

In any case, the MPC-BE always has brightness and contrast settings available. Use it.

[whataboutpereira]

MPC-BE + MadVR output:

MPC-BE + MPC video renderer output:

[v0lt]

Your photos are meaningless. The test video should have a description and an example of the correct result. And it should be available for research.

I've seen people use similar test samples a few times with a range of 0-255, but the video stream properties specified (or defaulted to) a range of 16-265. Accordingly, all correctly working renderers cut the range correctly. But people did not understand this and set up a decoder, renderer or driver. They got a picture that they liked in the test sample, and reduced contrast on regular video.

[v0lt]

I checked my test videos and didn't see any issues on the Intel UHD 750 and Windows 10.

[ghost]

I checked my test videos and didn't see any issues on the Intel UHD 750 and Windows 10.

Hi @v0lt and @Aleksoid1978 It's seems that mpcvr don't do 16-235 to 0-255 conversion. How do I force conversion?

My tesing with intel GPU: 16-235_scale file with GPU limited input range (normal becuase 16,235 to 16,235)

16-235_scale file with GPU full input range (renderer outputs 16,235 and gpu interprets as 0,255 range)

0-255 video with GPU limited input range (clipping happens because renderer outputs 0,255 but GPU only render 16,235)

0-255 video with GPU limited input range (normal becuase 0,255 to 0,255)

The Intel driver none option seems to be the auto now.

[Aleksoid1978]

Issue is closed - why write again adn again.

MPC VR don't do any 16-235 to 0-255 conversion. It's output as is - 16-235 as 16-235, 0-255 as 0-255. If somebody need conversion - force it in GPU driver.

[DBotThePony]

But it is up to video renderer to do any color correction, which includes expanding 16-235 range to 0-255 full range.

I think you misunderstand what videodriver is responsible for in handling color space and what is not responsible for. Videodriver (regarding color profile) is responsible for displaying black as black and white as white when transmitting signal to monitor, be it TV screen with limited (16-235) or PC monitor with full (0-255) sRGB color range.

When you work with color inside your application, you are expected to always work in full sRGB range (0-255). If video is in Limited sRGB space, and you display its colors as-is, "black" in video won't be "black" when displaying inside media player's window. And hence, it won't be "black" on monitor no matter the monitor's color space.

To put differently, videodriver expects you to always work in full sRGB range, and limited sRGB range monitor is the only thing handled by videodriver.

So process is something like this for full 0-255 PC monitor range: 16-235 (video, 16 is pitch black, 235 is pure white) ->16-235 (video renderer, 0 is pitch black, 255 is pure white) -> 16-235 (monitor, 0 is pitch black, 255 is pure white)

You might say this is desired behavior, but what happens if monitor is limited sRGB range (16-235)? And this is where things get ugly: 16-235 (video, 16 is pitch black, 235 is pure white) -> 16-235 (video renderer, 0 is pitch black, 255 is pure white) -> 29-222 (monitor, 16 is pitch black, 235 is pure white)

Both cases are incorrect, and culprit is video renderer in middle.

This happens not because videodriver is broken. Not because something else is broken. But this happens, because it is implied you always work in full sRGB range when providing your window output to window composer. And videodriver is responsible for transforming full sRGB into whatever color space monitor has.

And i don't even need to use camera to demonstrate this issue, basic color pipette will do (e.g. ShareX).

---

Reference image:

When encoded as (realistical scenario, not using plain ffmpeg) video with following parameters:

Video
ID                          : 1
Format                      : HEVC
Format/Info                 : High Efficiency Video Coding
Format profile              : Main@L6.2@Main
Codec ID                    : V_MPEGH/ISO/HEVC
Duration                    : 4 s 634 ms
Width                       : 1 920 pixels
Height                      : 1 080 pixels
Display aspect ratio        : 16:9
Frame rate mode             : Constant
Frame rate                  : 30.000 FPS
Standard                    : Component
Color space                 : YUV
Chroma subsampling          : 4:2:0
Bit depth                   : 8 bits
Default                     : No
Forced                      : No
Color range                 : Limited
Color primaries             : BT.709
Transfer characteristics    : sRGB/sYCC
Matrix coefficients         : BT.709

2024-01-25_02-56-20.zip

Produces next result in MPC-HC or MPC-BE with all rendereres (on default settings, except madVR and "legacy video renderer", both of which produce correct color expanding on default settings):

This is incorrect, because these pixels are supposed to be "pitch black" from Video's point of view. But Video Renderer doesn't care about this fact, and displays color as-is, resulting in washed out colors.

When using "16-235 to 0-255" shader, or when selecting color range 16-235 in EVR CP, or when using madVR, colors are handled correctly:

Issue with using "16-235 to 0-255" shader is that you need to turn it off when playing full sRGB range video manually, when such color expansion should be handled automatically, like any other media player does. I hope my reply will make clear that video renderer is responsible for expanding color values if video is in limited sRGB range.

[clsid2]

It expands the input just fine. It is only lacking support for limited range in GPU driver settings. It always does full range output, since that is the logical setting to use in driver. Any modern TV has full range setting. So there is little excuse to use limited range.