Media Player Classic - BE Win32/x64

[wyup]

HDR to SDR - https://github.com/Aleksoid1978/VideoRenderer/blob/master/Shaders/d3d11/ps_convert_pq_to_sdr.hlsl
Dolby Vision supported profile 5 and 8, MPC VR convert DV to PQ.
MPC-VR support D3D11, post-resize shaders.

Static value of 10,000 nits is assigned to 'luminance peak' in ps_convert_pq_to_sdr.hlsl:

#define SRC_LUMINANCE_PEAK 10000.0
#define DISPLAY_LUMINANCE_PEAK 125.0

Wouldn't it be more convenient to assign LUMINANCE_PEAK to MaxCLL or MaxMonDispLuminance from file metadata when available for a tighter curve?

Why is DISPLAY_LUMINANCE_PEAK set to 125 instead of standard 100 SDR?

[Siso]

Why is DISPLAY_LUMINANCE_PEAK set to 125 instead of standard 100 SDR?

I was wondering the same, cause 100 nits would make more sense imho.

[huhn]

there are talks to make this an option and maybe you can even get the gamma of your display in so it can properly tone map.
120 make most sense but i'm not going into that.

[Aleksoid1978]

If someone want to implement improvement for VR - patch are welcome :)

[v0lt]

Why is DISPLAY_LUMINANCE_PEAK set to 125 instead of standard 100 SDR?
Give a link to the standard, please.

[wyup]

Give a link to the standard, please.
https://www.itu.int/pub/R-REP-BT.2390-11-2023
Recommendation ITU-R BT.1886, 100 cd/m2 peak luminance.

However, hard setting LUMINANCE_PEAK to 10,000 nits is worse, most HDR videos are capped much lower at MaxCLL. It makes sense to tonemap from there to a tigher curve. By default, MPC-BE/MPC_VR shows hdr movies darker than they are.

I suggest to make an option to map it to either MaxCLL, MaxFALL, Max. Mon. Disp. Lumin. from HDR10 metadata, or a custom value.

[huhn]

they used 100 bt 1886 does not define it as 100 it does not define it at all.
they talk about 1000 CR lcs and other stuff 100 make math easy anyway.
there is even SDR at 1000 nits in there.

https://github.com/Aleksoid1978/VideoRenderer/issues/143

[ashlar42]

even if you calibrate in limited range full range will be calibrated too.
just set it to full range and let displaycal verify the results.
why even use that software...

So there is no way to do it within MPCVR?

[huhn]

there is no point in doing so. if you load a shader mpcVR will have to do that i don't have on at hand. bandaid for a self-imposed injury.
just set the GPU driver to limited.

[v0lt]

I suggest to make an option to map it to either MaxCLL, MaxFALL, Max. Mon. Disp. Lumin. from HDR10 metadata, or a custom value.
I can also offer such features (and even more). But who will implement this and thoroughly check it? After all, we don’t need to break the existing functionality.

[clsid]

I have a WIP patch for customizing display nits setting.

I am looking for good HDR sample files. Preferably a few with different MaxCLL values. Then I can test if using that value makes any sense in the current basic algorithm that MPCVR uses.

Files with a low MaxCLL would currently be too bright.

[huhn]

looking at the code there is nothing that tells the tone mapping the new maxcll and the display brightness and that's bad because of how tonemapping spec is define.

same file as an example:
125 peak brightness that means a knee point around 54.04 nits(this is the old spec i don't know the new one it's but goes higher).
maxcll 4000

current algorithm uses 10000 and peak 125 the high light 54.04-125 will be inefficeintly compressed and only about 100 nits will be used.

at 4000 the algorithm needs to recalculate the knee point or even the part of 0-54 will be to bright which should be the same no matter the maxcll.

i don't see anything even considering do that in the code.

[v0lt]

125 vs 100
https://i.ibb.co/yhffn9j/125.png (https://ibb.co/yhffn9j) https://i.ibb.co/Hq1hjpr/100.png (https://ibb.co/Hq1hjpr)

[Sunspark]

I think the 100 image looks better than the 125 one on an srgb display.

[wyup]

looking at the code there is nothing that tells the tone mapping the new maxcll and the display brightness and that's bad because of how tonemapping spec is define.

same file as an example:
125 peak brightness that means a knee point around 54.04 nits(this is the old spec i don't know the new one it's but goes higher).
maxcll 4000

current algorithm uses 10000 and peak 125 the high light 54.04-125 will be inefficeintly compressed and only about 100 nits will be used.

at 4000 the algorithm needs to recalculate the knee point or even the part of 0-54 will be to bright which should be the same no matter the maxcll.

i don't see anything even considering do that in the code.

I don't understand that well. Do you mean you need to set 125 nits and 10,000 not to have overblown highlights? That's to say 125 equals 100 in practice?

The 100 image is overexposed and has overblown highlights. But it is a sRGB image, 8-bits and full-range (0-255).

At 4,000 you mean 0-54 will be too bright? But 0-54 is half the brightness..

[Sunspark]

I don't think the 100 image is overexposed. The mid-tones in the 125 are too dark and real life doesn't have a neutral density filter over stuff to darken things.

I suppose in a dark viewing environment it's fine.

[huhn]

I don't understand that well. Do you mean you need to set 125 nits and 10,000 not to have overblown highlights? That's to say 125 equals 100 in practice?

The 100 image is overexposed and has overblown highlights. But it is a sRGB image, 8-bits and full-range (0-255).

At 4,000 you mean 0-54 will be too bright? But 0-54 is half the brightness..

no i mean nothing of this and no the resulting image is not sRGB.
// Linear to sRGB
color = saturate(color);
color = pow(color, 1.0 / 2.2);

this is pure gamma 2.2.

[wyup]

I don't think the 100 image is overexposed. The mid-tones in the 125 are too dark and real life doesn't have a neutral density filter over stuff to darken things.

I suppose in a dark viewing environment it's fine.

Well, overall exposure is maybe better at 100, but you can see in a histogram that it is clipped, the lake waves have clipped highlights.

Since we are dealing with HDR to SDR tonemapping, we don't want clipping by any chance. In fact what we want is to brighten the image, since default 10,000 curve is too high for most content and that makes images darker, because we are reserving brightness that we won't ever display.

The ideal static tonemapping is such that we only tonemap used range: ie: input: 0.005 to 590 nits (MaxCLL) -----> output: 0 to 100 nits (SDR)

[s0meone_new]

Hungarian translation updated:
https://easyupload.io/xl190e

[Ripmann]

Hi clsid, can you please [re]consider copying the "Move to Recycle Bin" keyboard shortcut and functionality from MPC-HC? I often copy several dozens of small video files from my phone, and having the ability to delete the unnecessary ones on the fly, without looking for the file in Explorer, is a massive time saver to say the least.

If you're wary of users accidentally deleting their files, you can leave the shortcut unbound by default. Although I never heard MPC-HC users complaining about it, so I doubt it happens often enough to worry about it. Thank you.

[Ravioli]

Finally I found a solution for two things that have been annoying me for the last couple of month:

1) MKV files would randomly freeze MPC while fast seeking or using the seekbar. Solution was to choose D3D11cb decoder instead of D3D11,DXVA I was using until now.

2) While in fullscreen, screen would sometimes flicker when mousing over the seekbar. What helped was setting Native display bitdepth as 8-bit in MadVR settings. While it was set to 10-bit, MadVR was switching between D3D11 windowed 10-bit and 8-bit mode when MPC's UI appeared (mouse was over seekbar or I right clicked for menu to appear). When I selected 8-bit, MadVR was rendering D3D11 windowed 8-bit all the time and flickering stopped completely. Later I've tried to pixel hunt the difference between 8 and 10 bit rendering in various movies, even with youtube low bitrate videos with visible banding and to be honest, I haven't seen any difference at all.

For reference, my configuration is Windows 10, Nvidia 3080, LG C1.

[Aleksoid1978]

1) Don't confirm.
2) Don't use madVR or don't move mouse.
This is how madVR behaves, it automatically switches between windowed and full-screen mode.

Show filters list.
If use some external filters like madVR, LAV - disable it and check again on internal filters only.

[Ravioli]

I apologize for not mentioning in 1) that I am using MadVR all the time. When I switch to MPC Video renderer, everything is just fine, no random freezes. It is 100% a MadVR issue. Tried the last official 0.92.17 version and beta 113 as well. No difference at all.

I do have LAV filters installed but in External filters, they are all set to "block". Only external file I am using is MadVR.

These are just workarounds I posted in case somebody else ends up with similar issues. Thank you.

[clsid]

Freezes with D3D11 native is due to a bug in MadVR. It holds all buffers causing deadlock because decoder is waiting for free buffer. It is known bug for several years and unlikely to ever be fixed given MadVR's current state of development (or lack thereof).

Use copyback instead.

[Ravioli]

Yes, I will stick to D3D11 copyback from now on. I used to use D3D11 native since it was using the least resources out of all renderers on my old system but since I upgraded to 13700k, I don't need to cut corners anywhere, I just want things to work.

[s0meone_new]

Hungarian translation updated:
https://easyupload.io/xl190e

Will this be updated later?

[Sunspark]

If you're going to use copyback, then why even bother with D3D11? MadVR is natively written for D3D9.

[v0lt]

Will this be updated later?
Thank you. Translation updated.

[Ravioli]

If you're going to use copyback, then why even bother with D3D11? MadVR is natively written for D3D9.

Alright, I disabled DX11 in MadVR settings, to force it to DX9, and cpu and gpu usage have stayed exactly the same in one scene i used to test this.

Tried that test scene with different renderers (DX11 checked in MadVR) (4k, 24fps, HDR video):

DX11,DXVA - 7% CPU, 22% GPU
DX11,Copyback - 10% CPU, 28% GPU
DX12,Copyback - 9% CPU, 26% GPU

Is there anything I'm missing here ? Based on above numbers, safe choice would be to stick with DX11 checked in MadVR and DX11 copyback renderer, since I know for sure that combo is working flawless on my setup.

[v0lt]

DX11,DXVA - 7% CPU, 22% GPU
DX11,Copyback - 10% CPU, 28% GPU
DX12,Copyback - 9% CPU, 26% GPU

Is there anything I'm missing here ?
I think you forgot to see the frequencies of CPU and GPU.

[huhn]

copyback is always slower. if this is measurable is a different story.
d3d11 in madVR is always slower because it is still dx9 it just does 1 or 2 additional interops which just cost performance. madVR is not a DX11 renderer mpcVR is.

and frequency's obviously big issue for such trivial easy tasks.

[wyup]

looking at the code there is nothing that tells the tone mapping the new maxcll and the display brightness and that's bad because of how tonemapping spec is define.

same file as an example:
125 peak brightness that means a knee point around 54.04 nits(this is the old spec i don't know the new one it's but goes higher).
maxcll 4000

current algorithm uses 10000 and peak 125 the high light 54.04-125 will be inefficeintly compressed and only about 100 nits will be used.

at 4000 the algorithm needs to recalculate the knee point or even the part of 0-54 will be to bright which should be the same no matter the maxcll.

i don't see anything even considering do that in the code.

It doesn't make sense to use 10000 when most movies are 1000 max or less. In practice, MPC-BE/MPC shows all HDR dark. You should use preferably MaxCLL or MaxMDL value from file and map from there using different methods, such as ITU-R Report BT.2446, method A:

https://www.itu.int/pub/R-REP-BT.2446
https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2446-1-2021-PDF-E.pdf

In 4.1 paragraph, you have Table 2: HDR to SDR conversion reference functions. They assume Lhdr=1000 nits for HDR and Lsdr=100 nits for SDR, but I guess you could choose the exact value from MaxCLL or MaxMDL.

There is also SMPTE ST2094-40 Annex B which is Dynamic HDR10+ tone-mapping:
https://pub.smpte.org/latest/st2094-40/

Mpv, by means of libplacebo library, can choose between one of these algorithms, using metadata from the file when available. When you have proper metadata from a well mastered file, you use Bt.2446, and when you don't, you use ST2094-40 (dynamic).

Here you have the calls from libplacebo library:
https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_libplacebo.c#L1398

Microsoft provides a HDR to SDR tonemapping implementation built-in in D3D11, which uses maxCLL. Maybe you could use this:
https://learn.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range#adapt-hdr-content-to-the-displays-capabilities-using-tone-mapping

It would be nice that you implemented any of such methods, if possible, to improve actual tonemapping. Thanks

[v0lt]

wyup
For what purpose are you writing this?
Show your patch and people will have something to test.

[wyup]

I write this as a user to help improve HDR tonemapping in MPC-BE/MPC.
I don't have a patch, I'm not a programmer. I leave some ideas.

Right now MPC has a problem: HDR looks dark on a normal SDR monitor. Its tonemapping is not good.
MPC-BE/MPC is and has been to me the best overall windows media player. MPV is open source and doing things better. Let's learn from it.

[wushantao]

Update Simplified Chinese：）

https://files.catbox.moe/ng8lq0.7z
https://file.io/Fv9c1NyDVZgU

[Klaus1189]

Updated german translation (https://drive.google.com/file/d/1NwBzp70DqbsN-NeKUsrorOgUedPyb_nu/view?usp=sharing) :)

[s0meone_new]

Hungarian translation updated:
https://easyupload.io/m97qpz

[Klaus1189]

Updated german translation (https://drive.google.com/file/d/1NwBzp70DqbsN-NeKUsrorOgUedPyb_nu/view?usp=sharing) - small fix -> unnecessary ":"

[v0lt]

Thank you. All translations are updated.

[v0lt]

MPC Video Renderer 0.8.3.2255 (https://github.com/Aleksoid1978/VideoRenderer/releases/tag/0.8.3)

Changes:
Added "SDR Display nits" setting.
Added validation of HDR metadata.
Fixed HDR Passthrough working in some rare cases.
Improved control of the "RTX Video HDR" setting.

[SirMaster]

MPC Video Renderer 0.8.3.2255 (https://github.com/Aleksoid1978/VideoRenderer/releases/tag/0.8.3)

Changes:
Added "SDR Display nits" setting.
Added validation of HDR metadata.
Fixed HDR Passthrough working in some rare cases.
Improved control of the "RTX Video HDR" setting.

This is a great addition, the SDR Display nits setting!

I wonder if this is the right place to ask or not, but what do you think about an option to tone-map into BT.2020 gamut rather than BT.709?

Example, I have a display that can do much wider color than BT.709, and it can track BT.2020, but it's an SDR display, so to preserve more of the original wide color we could have "SDR.2020" output as some call it.

Also, what about an option to tone-map, but keep the output in HDR10 PQ?

If we have say a 700 nit peak OLED, and want to tone-map all HDR10 down into the 0-700 nit range, but keep it as HDR, because the display won't do 700 nits in SDR mode.


These are just of course some things madVR offers, but I think it would be great if MPC-VR could too.

[v0lt]

SirMaster
If you want to experiment, then take the source code and change it as you want. I have neither the time nor the desire to implement experimental features so that someone can play around with it a couple of times.

You can also use AviSynth Filter (https://github.com/CrendKing/avisynth_filter) for your experiments. It's easier than C++ and HLSL. Modern AviSynth+ (https://github.com/AviSynth/AviSynthPlus/releases) has many features (https://forum.doom9.org/forumdisplay.php?f=33).

[GCRaistlin]

Aleksoid1978, please fix the bug with [x] Remember DVD position I first discovered in MPC-HC. It is present in MPC-BE 1.7.11.
Close the player after checking [x] Remember DVD position, open it again and start playing the DVD. For me it starts showing the clip with papers - which it should not.
The old sample link is dead, here's a new one: https://mir.cr/B3LYUEPW

[Dion]

Finally...

"SDR Display nits"

Long overdue feature..

[Manni]

MPC Video Renderer 0.8.3.2255 (https://github.com/Aleksoid1978/VideoRenderer/releases/tag/0.8.3)

Changes:
Added "SDR Display nits" setting.
Added validation of HDR metadata.
Fixed HDR Passthrough working in some rare cases.
Improved control of the "RTX Video HDR" setting.

Thank you very much for implementing this.

[Aleksoid1978]

Aleksoid1978, please fix the bug with [x] Remember DVD position I first discovered in MPC-HC. It is present in MPC-BE 1.7.11.

The old sample link is dead, here's a new one: https://mir.cr/B3LYUEPW

For me all is working, position remember.

[Aleksoid1978]

Player don't remember position for short duration.

[beter]

Update for translation of Chinese Traditional and Dutch:

https://www.sendspace.com/file/lc6jtw

[v0lt]

Release MPC-BE 1.7.2 (https://github.com/Aleksoid1978/MPC-BE/releases/tag/1.7.2)

Important changes:
VVdeC decoder is now used to decode VVC video.
Fixed decoding of some VP9 and interlaced H.264 videos.
When saving only audio from YouTube, add cover art to the audio file using the available FFmpeg.
Added timeout time setting when receiving data from the network.

MPC-BE Nightly builds (https://github.com/Aleksoid1978/MPC-BE/wiki/Nightly-builds)
Night builds are provided by volunteers.

Donate (https://mpc-be.org/forum/index.php?topic=240.0).

[longiloquence]

Cheers!