madVR - high quality video renderer (GPU assisted)

[flossy_cake]

Hi, quick question...
Using current 120Hz TV, if I play 23.976 fps or 24 fps content, what is the "best" option for MadVR..?
Switch to 23/24Hz or stay in 120Hz (since its 5x24)..?
Thank you.

Is it 120hz (24×5) or 119.88hz (23.976×5)? Ctrl+J should give an indication but it's not accurate. There is also vsynctester.com.

Ideally you would want both modes available as some content is 24 and most is 23.976, and have MadVR to auto select.

Theoretically there should be no difference whether TV is receiving 24 or 120 but in reality there might be some small differences depending on the video processor or the way the panel is being driven when at higher refresh rates. I'm not even sure which model TVs can even display a 4k120 4:4:4.

[EpsilonX]

Is it 120hz (24×5) or 119.88hz (23.976×5)? Ctrl+J should give an indication but it's not accurate. There is also vsynctester.com.

Ideally you would want both modes available as some content is 24 and most is 23.976, and have MadVR to auto select.

Theoretically there should be no difference whether TV is receiving 24 or 120 but in reality there might be some small differences depending on the video processor or the way the panel is being driven when at higher refresh rates. I'm not even sure which model TVs can even display a 4k120 4:4:4.

Hmmm, I always assume there won't be a noticable difference since not all GPU currently can accurately output 23.976 to the dot. :D
Smooth motion from 119.88hz to 120hz should be fine for me. :D
The Sony X90J as far as I know have no problem running 4K120@4:4:4.
No, I dont have the TV, still waiting for some new model to check the improvement (if any).

[flossy_cake]

As long as you're aware that Smooth Motion will produce many blended frames with 23.976fps video at both 119.88hz and 120hz (confirmed with video capture) and that it is possible to fine tune a custom refresh rate to high precision if you have the knowledge of how to do it. I should probably write a tutorial. Basically if it's a TV then it's probably using CTA VIC timings, so export the TV's EDID using CRU (https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU) and open it here (http://www.edidreader.com/) to see what VIC mode number it is that you want to adjust, then cross reference that number to a mode on page 26 of this document (https://web.archive.org/web/20171130183104/https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf) to discover the full timings of that mode. Then plug those values into this calculator (http://www.monitortests.com/pixelclock.php) to generate a list of modes resulting in your target refresh which will be very close to the factory timings and should work as long as you delete the factory mode from the CTA block of the EDID in CRU (otherwise GPU driver may use it instead) and add your custom mode to a new Display ID 1.3 block underneath the CTA block.

edit: but you probably won't notice the blended frames with Smooth Motion @ 120hz so unless you really care about having frame-perfect output then it's probably not worth going to the trouble of tuning a custom mode.

[Asmodian]

No, I dont have the TV, still waiting for some new model to check the improvement (if any).

The Sony A95K looks very nice. I think it might be my next display, though it is really expensive. :(

As long as you're aware that Smooth Motion will produce many blended frames with 23.976fps video at both 119.88hz and 120hz (confirmed with video capture)

You don't need to confirm it with video capture, that is how it is supposed to work. :confused:

On a 120+ Hz display I prefer simply enabling smooth motion and never worrying about the fps of the file or the display again. With how short the blended frames are displayed it does not damage the apparent video quality.

[flossy_cake]

You don't need to confirm it with video capture, that is how it is supposed to work. :confused:

So we all know 24 goes evenly into 120, so that means if it's still creating blended frames then it's doing it for some other purpose like what -- trying to minimise "jitter" or "strobing" effect of low frame rates? Ok, but in my video capture I found it blends 1 in 2.5 frames on average for 24@120 -- is that really enough to reduce jitter? The fact that it's difficult to tell in a double blind test whether it's enabled in this scenario would seem to indicate not, which is supported by your observation that you cannot tell there are blended frames. On the other hand, the setting does have an option to enable it "if the display refresh rate is an exact multiple of the movie frame rate" which would seem to indicate that Madshi is still trying to do some kind of intentional smoothing not targeted at reducing judder.

[ashlar42]

Only if you want to use the latest beta version of MadVR which has autism levels of HDR tonemapping adjustments which I don't really agree with from a purely philosophical standpoint.
To be fair, the current depths of settings is there for testing purposes. Madshi ha repeatedly stated that they will get significantly simplified once testing is done.

[huhn]

So we all know 24 goes evenly into 120, so that means if it's still creating blended frames then it's doing it for some other purpose like what -- trying to minimise "jitter" or "strobing" effect of low frame rates? Ok, but in my video capture I found it blends 1 in 2.5 frames on average for 24@120 -- is that really enough to reduce jitter? The fact that it's difficult to tell in a double blind test whether it's enabled in this scenario would seem to indicate not, which is supported by your observation that you cannot tell there are blended frames. On the other hand, the setting does have an option to enable it "if the display refresh rate is an exact multiple of the movie frame rate" which would seem to indicate that Madshi is still trying to do some kind of intentional smoothing not targeted at reducing judder.

i explained this before it's not for jitter it's just to a void clock drift and that's it.
and doing absolutely simple math yes you only need to display 48 different frames (1 blended 1 original rest are original repeats) with SM for 24 to 120 everything more is mathematically unnecessary or plain bad.

[EpsilonX]

The Sony A95K looks very nice. I think it might be my next display, though it is really expensive. :(

I still want to keep my kidney.. :D
Even the 65" A80J is still ~USD 2.200 in my country.
Not to mention my way of using the TV, I use it for 3-5 years, then move it to my mom's bedroom, then her bedroom's TV will be moved to the guest room.
So I need the TV to work for 6-10 years, and since my mom only watch like 3 channel or so, an OLED is gonna be ruined so fast. :D
Currently monitoring the 65" X90K for improvement over X90J, and if the A80J fall close to the X90K, I'll get that instead (definitely not for the current ~USD 2.200 price).

[ashlar42]

Since my TV is calibrated, I would want to understand how to best set up the Devices/TV/Calibration panel.

The TV is calibrated to Rec.709 for SDR and BT.2020 for HDR. But for Rec.709 I use more than one picture mode. The critical viewing one is with gamma 2.4, then there are other three picture modes with varying levels of brightness for different light conditions in the room. Those three all have gamma at 2.2 (I reserve 2.4 for absolute darkness).

Am I better off telling madVR "disable calibration controls for this display" or is there a point in seeking a different solution?

[x7007]

Is the 10bit issue with windows 11 fixed with 159?

[flossy_cake]

Since my TV is calibrated, I would want to understand how to best set up the Devices/TV/Calibration panel.

The TV is calibrated to Rec.709 for SDR and BT.2020 for HDR. But for Rec.709 I use more than one picture mode. The critical viewing one is with gamma 2.4, then there are other three picture modes with varying levels of brightness for different light conditions in the room. Those three all have gamma at 2.2 (I reserve 2.4 for absolute darkness).

Am I better off telling madVR "disable calibration controls for this display" or is there a point in seeking a different solution?

I think MadVR uses the parameters under "this display is already calibrated" when converting between different gamuts and dynamic ranges. Since your TV already supports both SDR and HDR signals you probably don't need MadVR to do any conversion as long as your PC is outputting SDR when playing SDR video and HDR for HDR video.

But maybe you are outputting HDR when playing SDR video, so I don't know what happens in that situation if you choose the default "disable calibration controls". Perhaps MadVR gets your monitor's HDR parameters through the Windows/GPU API, or maybe it just assumes Rec.2020/2100 gamut & PQ EOTF which is used by HDR10, HDR10+ and Dolby Vision.

[ashlar42]

I think MadVR uses the parameters under "this display is already calibrated" when converting between different gamuts and dynamic ranges. Since your TV already supports both SDR and HDR signals you probably don't need MadVR to do any conversion as long as your PC is outputting SDR when playing SDR video and HDR for HDR video.

But maybe you are outputting HDR when playing SDR video, so I don't know what happens in that situation if you choose the default "disable calibration controls". Perhaps MadVR gets your monitor's HDR parameters through the Windows/GPU API, or maybe it just assumes Rec.2020/2100 gamut & PQ EOTF which is used by HDR10, HDR10+ and Dolby Vision.

Current situation is madVR outputting HDR when playing HDR and SDR when playing SDR. On the TV I have HDR calibrated to BT.2020 and SDR to Rec.709.

[huhn]

keep it there are some correction which will not be done if neither a 3D LUT or a this display is cali... is set.
this should mostly matter for DVDs.

[Sunspark]

It hacks Direct3D to make 24 and 60 Hz work. If you want to use 24.000 Hz or 60.000 Hz you need to enable it. If you only want to use 23 Hz (23.976) or 59 Hz (59.940) then you should not enable it. It can cause presentation queues to not fill correctly so it should only be enabled if you want true 24 or 60 Hz refresh rates.

Asmodian, point of clarification please if you know. For this option, am I correct in understanding that having it checked exposes both 24&60 as valid switchable options in addition to 23.967&59.940? Or does having it checked actually remove 23.976/59.940 and replaces them with 24.000/60.000 instead, even for 23.976/59.940 content? Thanks!

[flossy_cake]

I have "hack direct3D" unticked and encounter no problems with n/1 and n/1.001 modes. My "list all display modes MadVR may switch to" string is: 1080p23, 1080p24, 1080p50, 1080p59, 1080p60. I have tested them with real content and they appear to be functioning correctly so I'm not sure why the "hack direct3D" is needed. I am using Direct3D 9 (unticked "use Direct3D 11"). My n/1.001 modes were tuned with CRU and live in a DisplayID 1.3 block in the EDID in Windows registry. My n/1 modes didn't need any tuning.

keep it there are some correction which will not be done if neither a 3D LUT or a this display is cali... is set.
this should mostly matter for DVDs.

Yeah but they would have to change it in MadVR every time they changed it on their TV. I'm in the same boat -- when I watch HDR on my SDR TV at night, MadVR is probably assuming 2.2 gamma for the conversion to SDR, but at night I have manually changed my TV from 2.2 to 2.4.

[huhn]

Yeah but they would have to change it in MadVR every time they changed it on their TV. I'm in the same boat -- when I watch HDR on my SDR TV at night, MadVR is probably assuming 2.2 gamma for the conversion to SDR, but at night I have manually changed my TV from 2.2 to 2.4.
if you don't care about an accurate image do as you plz.
you can just change the gamma in madVR too.
Asmodian, point of clarification please if you know. For this option, am I correct in understanding that having it checked exposes both 24&60 as valid switchable options in addition to 23.967&59.940? Or does having it checked actually remove 23.976/59.940 and replaces them with 24.000/60.000 instead, even for 23.976/59.940 content? Thanks!
it's an old hack to make both refresh rate work again on a windows version i forgot i have not seent eh need for it in years.
as long as p23 and p24 give you a different refreshrate in madVR you don't need this hack.

[flossy_cake]

if you don't care about an accurate image do as you plz.

Yeah but displaying HDR in SDR is already inaccurate -- the tone mapping is already way off and compressed to fit in small dynamic range.

[SamuriHL]

Not original is NOT the same as inaccurate. madvr does compress the specular highlights to fit a specific nit target range, yes. However, there's a reason there's been so many betas and so much time spent on very minor details within the tone mapping process....madshi absolutely strives for an accurate (meaning true to director's intent) picture representing faithfully the HDR picture in an SDR range.

[ashlar42]

keep it there are some correction which will not be done if neither a 3D LUT or a this display is cali... is set.
this should mostly matter for DVDs.
I ended up creating two profiles, one for resolutions below 576 (PAL), where I specify that the display is calibrated for Rec.709.

The other, for all higher resolutions, where I ask to disable calibration.

I know this is probably not perfect, but SD content was the only one were I actually saw a difference (colors were oversaturated if I went with "disable calibration". 1080p and 2160p content HDR did not display noticeable differences between disable/rec.709 and disable/bt.2020, respectively.

[flossy_cake]

Not original is NOT the same as inaccurate. madvr does compress the specular highlights to fit a specific nit target range, yes. However, there's a reason there's been so many betas and so much time spent on very minor details within the tone mapping process....madshi absolutely strives for an accurate (meaning true to director's intent) picture representing faithfully the HDR picture in an SDR range.

If the MadVR conversion from HDR to SDR matches the director's SDR release of the film, yes.

I was looking at a HDR scene just now where the bright parts of the actor's faces are clipping severely when MadVR is set to 200 nits clipping. So that means when selecting BT.2390 it's having to compress their facial contours and their faces won't look the same as on a HDR display. In my books that is inaccurate.

Maybe for the SDR release the director would compress that region on that particular scene, or just lower the peak luminance level down to relieve clipping. I don't really know. I guess I am curious to know the curve MadVR uses to fit to user specified target peak nits. I'm reading BT.2390 (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-10-2021-PDF-E.pdf) and trying to figure out how it would be done.

[flossy_cake]

this should mostly matter for DVDs.SD content was the only one were I actually saw a difference (colors were oversaturated if I went with "disable calibration". 1080p and 2160p content HDR did not display noticeable differences between disable/rec.709 and disable/bt.2020, respectively.

If it's oversaturated then it means 709 gamut is getting enlarged to 2020, which means your PC is probably outputting 2020 for SDR which will be incorrect for most SDR content. 4k SDR uses 2020 it seems, so that would explain it. Seems MadVR assumes 709 gamut unless you tell it otherwise, so in your case you definitely want to be using MadVR's calibration settings. Good find.

[SamuriHL]

If the MadVR conversion from HDR to SDR matches the director's SDR release of the film, yes.



I was looking at a HDR scene just now where the bright parts of the actor's faces are clipping severely when MadVR is set to 200 nits clipping. So that means when selecting BT.2390 it's having to compress their facial contours and their faces won't look the same as on a HDR display. In my books that is inaccurate.



Maybe for the SDR release the director would compress that region on that particular scene, or just lower the peak luminance level down to relieve clipping. I don't really know. I guess I am curious to know the curve MadVR uses to fit to user specified target peak nits. I'm reading BT.2390 (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-10-2021-PDF-E.pdf) and trying to figure out how it would be done.It matters very much how you configure madvr. There are multiple tone curves and other options that can tweak how the time mapping is done. The goal isn't to make it look like the bluray version. If you have specific content you find that madvr isn't tone mapping well, post it in the beta thread with the settings you're using and let madshi improve the tone mapping.

Sent from my SM-G998U1 using Tapatalk

[huhn]

Yeah but displaying HDR in SDR is already inaccurate -- the tone mapping is already way off and compressed to fit in small dynamic range.

if you gamma match a range that is displayed will be 100 % the same as passthorugh that's why gamma matching is important because only the top is compressed. if you change the gamma everything is compressed/decompressed making it in accurate.

if you have a device with 1000 in SDR and HDR and play a file with 1000 nits it will be 100% the same with HDR to SDR or passthrough (assuming both modes are calibrated)
but only if the gamma is matched so in short.

so in short again not matching gamma when HDR SDR tone mapping is used will be in accurate and it matters if you want an accurate image.
I ended up creating two profiles, one for resolutions below 576 (PAL), where I specify that the display is calibrated for Rec.709.

The other, for all higher resolutions, where I ask to disable calibration.

I know this is probably not perfect, but SD content was the only one were I actually saw a difference (colors were oversaturated if I went with "disable calibration". 1080p and 2160p content HDR did not display noticeable differences between disable/rec.709 and disable/bt.2020, respectively.
i don't know why you did this because i'm pretty sure passthrough ignores all/some of this anyway. which would perfectly explain why you don't see a difference because there is none under some situations.

sorry i can't get HDR working for like 6 month now so i can't do a super fast check.

you are using an OLED right?
if you have an nvidia card just set send bt 2020 and set it to bt 2020 and never thing about it again (after you have run a verification of cause).

[flossy_cake]

if you gamma match a range that is displayed will be 100 % the same as passthorugh that's why gamma matching is important because only the top is compressed. if you change the gamma everything is compressed/decompressed making it inaccurate.

If there are artistically important parts of the image which contain pixels brighter than SDR, or the SDR version of the film doesn't use the same tonemapping as MadVR does, then it would be inaccurate anyway wouldn't it?

Actors faces above 200 nits
https://i3.lensdump.com/i/t4atFv.png
https://i.lensdump.com/i/t4aRIC.png

Gamma 2.2 vs 2.4
https://i1.lensdump.com/i/t4aTB5.png
https://i2.lensdump.com/i/t4aEoz.png

Even if I set MadVR cal to 2.4 to match my TV, it would still be wrong for daytime viewing when I'm using 2.2, and I always get the SDR version of the film anyway which the director/colourist approved.

I suppose I may as well set MadVR cal to 2.4 as most films will be screened at night when the TV is set to 2.4.

[ashlar42]

If it's oversaturated then it means 709 gamut is getting enlarged to 2020, which means your PC is probably outputting 2020 for SDR which will be incorrect for most SDR content. 4k SDR uses 2020 it seems, so that would explain it. Seems MadVR assumes 709 gamut unless you tell it otherwise, so in your case you definitely want to be using MadVR's calibration settings. Good find.
SD not SDR. Low resolution content.

Display is calibrated and verified to average dE2000 of 0.24, there is no oversaturation for SDR hires content.

SD content is BT.601. From what I see, I am led to believe that madVR defaults to 709 for HD and 2020 for HDR.

[huhn]

If there are artistically important parts of the image which contain pixels brighter than SDR, or the SDR version of the film doesn't use the same tonemapping as MadVR does, then it would be inaccurate anyway wouldn't it?
no because it follows the spec for tone mapping. which only works when you match the gamma else bt 2390 will produce wrong results.
Actors faces above 200 nits
https://i3.lensdump.com/i/t4atFv.png
https://i.lensdump.com/i/t4aRIC.png
nothing todo with the spec
Gamma 2.2 vs 2.4
https://i1.lensdump.com/i/t4aTB5.png
https://i2.lensdump.com/i/t4aEoz.png
again this is not showing anything of relevance without contex of the calibrated screen which a screenshoot will not show. because relativity and such
Even if I set MadVR cal to 2.4 to match my TV, it would still be wrong for daytime viewing when I'm using 2.2, and I always get the SDR version of the film anyway which the director/colourist approved.
this option doesn't do anything to SDR. so you can set it to 2.8 if you set your TV to 2.0 now you will still get 2.0.
this is different with HDR because it has to correct it to make it accurate.
I suppose I may as well set MadVR cal to 2.4 as most films will be screened at night when the TV is set to 2.4.
ok...

[ashlar42]

I ended up creating two profiles, one for resolutions below 576 (PAL), where I specify that the display is calibrated for Rec.709.

The other, for all higher resolutions, where I ask to disable calibration.

I know this is probably not perfect, but SD content was the only one were I actually saw a difference (colors were oversaturated if I went with "disable calibration". 1080p and 2160p content HDR did not display noticeable differences between disable/rec.709 and disable/bt.2020, respectively.

I added a profile for HDR that goes to "calibrated to bt.2020" (which is the case for the HDR picture mode I use with madVR, where I have eliminated tone-mapping, handing it completely to madVR).
Empirically I would have said that it made no difference but since it was easy to do... I did it.

[Alexkral]

I don't think that the result of the conversion from HDR to SDR (including the one made by madVR) could or should be considered accurate in terms of being true to the director's intent. SDR grades are made most of the time using what Madshi always calls dumb, or mathematically incorrect tone mapping. I can tell you right now that madVR is never going to be true to the hue shifting derived from this.

The HDR white level also changes from one grade to another, and even in scenes within the same film. There's nothing that can be done with this. The dynamic target nits feature, which might help with this, was quite limited and useless the last time I tried it. But even if it worked well the result would be very different from the SDR grade.

And then there are the differences in saturation and contrast...

I've done a lot of comparisons in the past between SDR grades and HDR to SDR conversions, and the differences were so wild that I immediately understood that it didn't make much sense.

Still, most content is below or relatively close to 100 nits, so it's not much different, except for the white level. I usually raise it to 200 according to the recommendations, setting the target nits to a value lower than the maximum nits of my display. I have never measured it, since the measurements would be inconsistent due to the difference between the SDR grades, but it seems to work as intended.

I don't usually change the gamma, but sometimes it's a must, and with some movies (e.g. "The witch") the image improves a lot, at least if your display doesn't have a good contrast like mine.

In any case, the development of tone mapping in madVR has long been focused mainly in the projectors, giving more importance to the level of detail than to the maximum luminance, which on other types of displays is at least questionable.

[Sunspark]

Because I am playing with 23.976 and 24 modes in one player, I am currently using MadVR for the chroma upscaling (in this example, super-xbr 100 ar which increases gpu load) but letting the monitor upscale it from 1080p to the higher resolution of the panel. (I find it odd that the monitor will let me use 23.976 at 1080p, but not at the native resolution of the panel, at best, I can only do 48 Hz at native so far).

I noticed a load difference with some configurations with showrendersteps.

For the player properties I have disabled full-screen optimizations checked in Windows 10.

dxva2 copyback, d3d9 mode, my igpu is the Intel HD 6000 here.

Windowed overlay, FSE backbuffers, FSE frames in advance were tested to see which was "smoother" on panning motion. There is a very subtle difference.

GPU load as measured with gpu-z was the same with all 3.

CPU usage however, was not.

Overlay 13.22 ms w/ 15% cpu
FSE frames in advance 40.72 ms w/ 45% cpu
FSE backbuffers 32.70 ms w/ 40% cpu.

Took a look at D3D9 Fullscreen Windowed (old path) as well. same as FSE backbuffers. Couldn't do frames in advance with it, might need to reboot.

These results are specific to my system, but I find it interesting that by far the lowest CPU usage was with overlay and that frames in advance needed more ms and more cpu than backbuffers, even though both were set to a value of "1".

UPDATE: I rebooted the computer, and now these numbers don't apply anymore, e.g. the 45%, etc. Weird.. I've noticed sometimes MadVR sometimes gets stuck or glitched. For example once in awhile it refuses to go into FSE unless rebooted, etc.

[huhn]

I don't think that the result of the conversion from HDR to SDR (including the one made by madVR) could or should be considered accurate in terms of being true to the director's intent. SDR grades are made most of the time using what Madshi always calls dumb, or mathematically incorrect tone mapping. I can tell you right now that madVR is never going to be true to the hue shifting derived from this.
it is accurate to bt 2390 not the creators intend the creators intend is to display it at the nits the file has which is not rarely completely impossible maybe even forever laws of thermodynamic and such...

but that's not the point about gamma and the SDR master also does not matter for this it about changing as little of the source as possible and with BT 2390 you need to gamma match.

i personally think this is a tone mapping trap and should be discarded. just as the SDR master here doesn't matter so doesn't what i think.
what is the point of having 100 % accurate luminance matching for like 46 nits diffusion point out of a 1000...
but the spec defines it so if you want it to be accurate you should follow it.

[flossy_cake]

I agree with the statement "it is accurate to f" where f is some formula. And this is somewhat different to saying "it is accurate to d" where d is director's intent.

Question tho: does BT.2390 actually say "this is how you should convert HDR to SDR"? i.e a formula for converting PQ to gamma given a target peak nits?

After skimming the document all I could really find was this:


5.4 Display Mapping
content often must be viewed or produced in environments brighter than the reference condition, and on monitors that cannot display the deepest blacks or brightest highlights that the PQ signal can convey. In these cases, the display characteristic needs to be changed in a process often referred to as display mapping (DM). More information can be found in Recommendation ITU-R BT.814 and Reports ITU-R BT.2408 and ITU-R BT.2446.

6.4 Compatibility with SDR displays
Both PQ and HLG provide limited compatibility when directly connected to legacy SDR displays with BT.709 colorimetry. In the absence of additional processing HLG has a degree of compatibility when shown on SDR UHDTV displays that have been designed to accept signals in the BT.2020 colour space.

Concerning the degree of compatibility achieved by HLG, hue changes can be perceptible on the SDR display should images contain bright areas of highly saturated colour or very high code values. Generally, such high code values would be used for specular highlights and thus constitute a small proportion of the picture. The acceptability of the degree of compatibility of HLG might be a commercial decision by specific broadcasters or for a specific application. When PQ or HLG HDR signals are converted for use in SDR ITU-R BT.709 facilities, the conversion process is expected to perform the colour space, HDR to SDR and any video format conversion in such a way as to minimise perceptible changes in colour for all types of HDR content, regardless of the code value ranges in use.

edit: it seems BT.2446 (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2446-2019-PDF-E.pdf) "Methods for conversion of high dynamic range content to standard dynamic range content and vice-versa" contains the relevant formulas.

[Alexkral]

Question tho: does BT.2390 actually say "this is how you should convert HDR to SDR"? i.e a formula for converting PQ to gamma given a target peak nits?

Of course there is a formula, which is the one used (with some changes) in the official versions. BT.2390-8 (02/2020) (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-8-2020-PDF-E.pdf) was the last version of this paper that included it (pages 22 to 25). Now this is considered obsolete, and the recommendation is BT.2446 as you say.

I haven't tried the latter yet, but you can with this (https://forum.doom9.org/showthread.php?t=175488).

[flossy_cake]

:thanks:

[flossy_cake]

Was doing some power consumption tests with GPU vs CPU decoding on various files: 1080p, 4k, h.264, h.265 etc. My observation is that CPU decoding only seems to use an extra 5 watts max on my i7-4790k & GTX 1070 system. I concluded that I may as well just use CPU decoding to try and avoid any potential decoding accuracy issues with the GPU driver.

But I still need GPU decoding for high bitrate 4k60 HDR which the CPU is too weak for, and unfortunately LAV Video Decoder doesn't allow us to set GPU decoding only for 4k60 or above, only "4k", so 4k24 must still be GPU decoded even though the i7 can easily manage 4k24 HDR with only 15% CPU load.

I took some screenshots to try and find colour differences for CPU vs GPU decoding and haven't found any (yet). But the fact of GPU decoding being somewhat like a black box without any way of verifying whether it decoded accurately, makes me lean towards CPU decoding. I presume LAV Video Decoder is perhaps more mature and reliable than NVidia decoding? Please correct me if I'm wrong though -- I'd like to know whether NVidia drivers are considered mature enough to trust for accurate decoding.

[huhn]

hardware decoder are known to be bit perfect.
what has this to do with madVR.

[flossy_cake]

hardware decoder are known to be bit perfect.

Cool and good, I will use it then.

Okay it's only 5 watts savings but I kind of like the idea the GPU is doing its thing and spreading the load a bit. And I'm getting my money's worth from those hardware blocks.


what has this to do with madVR.

Well... I guess MadVR has some settings which dont work with certain GPU decoding settings so maybe it's good to know CPU decoding can be used in that case without paying a power penalty.

Overall MadVR is very good, I am satisfied with the product, and I am difficult to satisfy. Thanks to Madshi for the countless hours and years spent on this project, now we have something nice in the public domain.

Random tip: to discover how much GPU load is spent just decoding video, GPU-Z can show it under "Video Engine Load" :helpful:

[jkauff]

Thanks to Madshi for the countless hours and years spent on this project, now we have something nice in the public domain.
Unless I missed an announcement, madVR is NOT public domain, or even Open Source. The source code is closed, as it always has been, and belongs solely to madshi. It's free in its compiled form, and the public version may appear to be abandoned, but that doesn't make the binary, and certainly not the source code, public domain.

[el Filou]

hardware decoder are known to be bit perfect.Caveat: DXVA2 native with NVIDIA isn't (chroma errors), other hardware decoders are.

For people watching video source material, using NVIDIA hardware deinterlacing within madVR also introduces chroma errors (and other artifacts but mostly in SD).

[flossy_cake]

Unless I missed an announcement, madVR is NOT public domain, or even Open Source. The source code is closed, as it always has been, and belongs solely to madshi. It's free in its compiled form, and the public version may appear to be abandoned, but that doesn't make the binary, and certainly not the source code, public domain.

I didn't say MadVR is public domain, I said it is in the public domain, meaning, in the public area or available to the public, in the colloquial sense as opposed to the legal sense. And yes I'm aware the term public domain is typically used in the legal sense, so your comment is noted.

[huhn]

Caveat: DXVA2 native with NVIDIA isn't (chroma errors), other hardware decoders are.

For people watching video source material, using NVIDIA hardware deinterlacing within madVR also introduces chroma errors (and other artifacts but mostly in SD).

the decoder is bit perfect but yes the DXVA pipeline changes the image negatively.

DXVA processing in general has misalign chroma on nvidia if the decoder is used or not is not the issue here just deint and the chroma will be in the wrong spot same for scaling.

[Sunspark]

Caveat: DXVA2 native with NVIDIA isn't (chroma errors), other hardware decoders are.

This is something I have wondered about for some time because I have never seen a conclusive answer.

I have seen the statement that DXVA2 native is bad because of chroma blur, across the board for all GPUs. But I have also seen the statement that Intel doesn't have this problem. I have never seen "proof" of either and it may even possibly be dependent on which generation of GPU it is, for Intel and others.

Is there a test that can be performed to detect whether or not there actually is a blur?

Is the test just simply capturing the exact timestamp, screenshot, then subtracting the difference between two images in a photo editor?

On another note, I was futzing about with chroma upscaling in madvr last night as I had a good video sequence with some difficult colour/light without much movement in it but included both distance and up-close views, and I noticed with a 2-tap scaler that one of them actually looked very slightly sharper without the anti-ringing filter turned on. I will look again later, but I submit the hypothesis that the anti-ringing filter may not necessarily be ideal to use in all circumstances as it may blur a tiny bit.

Edit: The video sequence (for those who have already seen the episode, don't watch if you haven't as it will be a spoiler) is Stranger Things S04E07 1:18:59 to 1:20:25. This scene is under fluorescent (or led) cold white overhead lighting. It is a room with coloured stripes on the wall. One character is wearing white. Their face is backlit at times, does their face become too dark or pick up a colour cast? Look at the colour stripes on the wall, are they too punchy or dull? Look at the pores on the face of the character in white as well as their hair, are they too sharp or ok? The white clothes, does it pick up a neutral, greenish or yellowish colour cast? There is even CGI on the other character's face at one point around 1:20ish, does it look "ok" or does the chroma upscaling make the CGI look more artificial and pop out more?

Another interesting one is S04E05 1:09:09 to 1:11:35. This scene uses a variety of coloured lights at the same time with a full range between black and white. I would say, look at whether the colours are too intense or not, and whether the overall scene looks too contrasty or not.

[huhn]

with DXVA2 native madVR get the image in "RGB"(or something) or with other words not native format and it tries to undo this i leave the rest up to you what that means because it has been tested to death.

chroma test have been done here before not long ago.

[ashlar42]

with DXVA2 native madVR get the image in "RGB"(or something) or with other words not native format and it tries to undo this i leave the rest up to you what that means because it has been tested to death.

chroma test have been done here before not long ago.
Since it has to do with deinterlacing, though, I have to wonder.

I have found so far exactly zero software solutions that even come close to hardware deinterlacing quality with Nvidia cards.

And while people struggle to notice chroma errors, deinterlacing imperfections seem pretty obvious to me.
Am I the only one?

[Sunspark]

Interesting.. with a 24 fps file I discovered that switching from native res/60 Hz to 1080p/24 Hz was blackscreening repeatedly (but not every single time) in Win10 when in d3d9 overlay mode AND when DXVA2-Native was the selected decoder. Seemed stable with 23.976. Toggling the hack directx option didn't really solve the issue. Blackscreening didn't happen with software decoding or copy-backs. It also did not happen when staying in native/60 mode. I do not understand why a lower resolution made it fussy, but it did. Showing render steps showed that in dxva2-native it was performing additional chroma transforms, so that is probably part of why/fighting the texture format or something.

I have to switch to 1080p for 23.976 because the intel drivers won't let me set a custom resolution of 23 at native, it does for 24 and up though, but then image size would be scaled up by the drivers and not the monitor's hardware (pros and cons).

So I did some number testing on the 24 fps file which is not 23.976.

When switching to 1080p mode (madvr 2-tap chroma)

dx-cb 12% cpu 12% gpu 2.38 ms rendering time
quicksync 15% cpu 12% gpu 18.03 ms rendering time (EDIT: Not accurate, see postscript at bottom)
dx-native 10% cpu 22% gpu (yes, the gpu load almost doubled) 23.99 ms rendering time
dx-native (forced dvxa chroma) 24.81 ms rendering time

So, on my system, if one is switching to 1080p using a madvr chroma scaler, dx-cb is by far the best hardware decoder to use if you're using overlay with a 24 fps file, and native was the worst.

At native monitor resolution/60 Hz, chroma and image scaling performed by DVXA instead of madvr/monitor, it is not as clear cut.

dx-native 9% cpu 10% gpu
dx-cb 10% cpu 9% gpu
qs 12% cpu 12% cpu

Rendering times were lower, ~4-5 ms.

I don't understand why at native resolution the gpu load wasn't penalized like it was when in 1080p..

Yes, I know, you will all say but clearly you have proven that dx-cb is the best for this edge case on this hardware so it shouldn't matter as long as it works. Sure, but I think native shouldn't have had a gpu load % difference between the two display resolutions when for one of the tests I forced dxva chroma by using the trade quality checkbox.

Maybe it would have been different using d3d11, but I don't want to deal with that, I already know it's not optimized for my hardware even though it does work.

And this is the fun of procrastinating by compulsively tweaking when you're supposed to be doing some work that you're avoiding.. sigh.

Postscript: I don't think the rendering time number is very reliable.

With Mitchell-Netravali without AR it was 2.38 ms
With AR turned on, it became 19.11 ms. Big jump!
With Super-XBR 100 AR, it was 2.62 ms. However, GPU % tripled compared to MN.
GPU % did not go up for MN AR despite the increase in rendering time.. so probably better to watch power.

Curiously, switching the decoder to QuickSync and changing MN to AR, the rendering time changed to 2.5 ms down from 18 ms.

So, the decoder used does affect rendering time for AR on/AR off, but it doesn't seem to affect cpu/gpu % if AR is on or off.

Postscript 2: I have since discovered that toggling in and out of fullscreen mode, will force quicksync to render about the same as dxva2-copyback, so it is possible to change the rendering time # in the hud by toggling in and out, and you can see this with other scaler algorithms.. high rendering ms then low, etc.

Postscript 3: I seem to have stopped the blackscreening by turning off "delay playback start after seeking too". At last! Now I can have "smooth" panning motion because I can use dxva2native without crashing. I did start playing with the D3D11 stuff too though, and D3D11 on in LAV with D3D11 Presentation+vsync frame in MadVR but without exclusive mode is also pretty good. dxva2-native in overlay is smoother though. Now I will leave this alone for a bit.

[flossy_cake]

I need some chroma resolution/alignment test pattern videos in 264 & 265 to see if MadVR and DXVA-CopyBack on/off is producing chroma errors as people are saying.

Can anyone recommend such test pattern videos?

Thanks

[huhn]

@Sunspark
as i'm say again and again you can not just go and take a % number of nothing and compare it to another % number of nothing.
intel iGPU have a very big frequency range and older like this also suffer from high load if DXVA decode or processing is used which is not comparable to nvidia and AMD and who knows modern intel GPUs.
btw. there are also more than one part that can be loaded on a GPU so a GPU load with no contex and completely different load types (DXVA doesn't load the bus but CP and quicksync will put heavy load on it) is not of much meaning.
Since it has to do with deinterlacing, though, I have to wonder.

I have found so far exactly zero software solutions that even come close to hardware deinterlacing quality with Nvidia cards.

And while people struggle to notice chroma errors, deinterlacing imperfections seem pretty obvious to me.
Am I the only one?

QTGMC https://forum.doom9.org/showthread.php?t=174544
have a look at this.

and yes properly working hardware deint from all 3 major vender are very good and also close to free.


I need some chroma resolution/alignment test pattern videos in 264 & 265 to see if MadVR and DXVA-CopyBack on/off is producing chroma errors as people are saying.

Can anyone recommend such test pattern videos?

Thanks

https://forum.doom9.org/showthread.php?p=1967409#post1967409

https://drive.google.com/file/d/12YUZbkUqkCGHcU25Ri_bCV0P5PaliDDU/view?usp=sharing
reencoding this to a format that supports DXVA should be trivial. not that it needs to be done to test this a simple EVR screenshoot loaded in madVR and a couple of taps on control+shift+alt+f12 will show it pretty much instantly.

this is the issue with the current AMD driver where nothing work in term of processing:
https://abload.de/img/amdbilinearwbkbb.png
https://abload.de/img/amdchromascale9aj2y.png
yes they managed to get image quality below bilinear scaling and misalign the chroma which is not an easy feat.

[flossy_cake]

Testing CPU vs DXVA2 decoding on GTX 1070 with test files:

4k HDR HEVC 10bit 444.mkv (https://drive.google.com/file/d/1-_eNLcQYHtuJeYqB2OjWQnu_MgCIN6i0/view?usp=sharing)
4k HDR HEVC 10bit 420.mkv (https://drive.google.com/file/d/1I7fAy3Gyf1uDci7cEjCQcJqzKSS1ouXC/view?usp=sharing)

Notes:


4:2:0 is quarter chroma resolution (half horizontal & half vertical)

When taking screenshots for comparisons, wait 8 seconds into the video until HEVC compression artefacts stabilise from the initial keyframe. Then in MadVR settings: "create screenshots with a custom zoom factor: encoded video size".

Following images were zoomed in 300% using nearest-neighbour in Photoshop to see what's going on at single pixel level


4:4:4, CPU decoding
https://i2.lensdump.com/i/tpv0QZ.png

4:2:0, CPU decoding, Bicubic60 chroma
https://i3.lensdump.com/i/tpvIeP.png

4:2:0, DXVA2-copyback decoding, Bicubic60 chroma:
https://i.lensdump.com/i/tpvZym.png

4:2:0, DXVA2-native decoding, DXVA2-native chroma (unchangeable in this mode):
https://i1.lensdump.com/i/tpvrTi.png

__________________________________________

Animated PNG comparisons

DXVA2-native vs Bicubic60
https://i.lensdump.com/i/tpvJQz.png

Bicubic60 vs Super-xbr:
https://i1.lensdump.com/i/tpvQnT.png

Super-xbr vs Bilateral old:
https://i2.lensdump.com/i/tpvVyb.png

__________________________________________

Conclusions:


DXVA2-copyback appears faithful to CPU decoding, at least with this video file and GTX 1070.

DXVA2-native uses its own chroma upscaling mode which is less sharp. I am not sure if the alignment is slightly shifted to the right by 1 or 2 pixels, or if that is just a function of its algorithm.

[Sunspark]

@flossy_cake you can force the use of a different chroma with dxva2-native decoding by unchecking the checkbox for "use dxva chroma when using native" in the trade quality for performance section. This is more load on the system. When checked on, dxva chroma will be used even if something doesn't need to be scaled, so unchecking uses the software scaler.

In those screenshots, the dxva2-native algo in your card is best. It has the sharpest text rendition and doesn't do stupid stuff like putting white pixels in the middle of the letters like O.

Turn on the anti-ringing filter, you have a lot of ringing going on, might fix those white pixels.

[huhn]

that's the problem of dxva native in madVR even if you use a different chroma scaler the position is still off by half a subpixel as can easily be seen.

the "white" pixel well it is blue is correct all that doesn't show blue are wrong because the text is blue.

DXVA chroma scaling on nvidia looks like bicubic 50 so nothing has chance there too.
DXVA2 copyback is as excepted bit perfect like all decoder modes and only the transfer of DXVA2 native with madVR is the issue nothing else.

[el Filou]

What's frustrating with this chroma DXVA2 thing on NVIDIA is for people who watch interlaced content, if you use GPU deinterlacing it will reintroduce chroma errors even if it was decoded correctly with software or copyback.
Only doing decoding and deinterlacing with CUVID gives good results for video.

madVR would just be 100% perfect for me if it had D3D11 native deinterlacing and black bar detection running on the GPU, it's really a shame it's never gonna happen. :(