madVR - high quality video renderer (GPU assisted)

[huhn]

madVR likes to crash with D3D11 seeking so don't use it.
the 432ß is a lie by the decoder or is read wrong from madVR it has no effect.

for proper tone mapping setting you need to wait for someone else.

[flossy_cake]

The movie keeps flickering sometimes? I'm not sure why.

Any help is appreciate it. Sorry my english.

I am using MPC-BE 1.8.8 x64

Try right clicking the mpc-be .exe , properties, compatibilty tab, "disable full screen optimizations". then in madvr settings use full screen exclusive mode and try d3d9 vs d3d11 to see if it helps


What is 3840x4320 ? That's not my resolution.My native resolution is 3840x2160.

Yes that is what madvr is reporting - the video file is 3840x4320 then underneath it says "scale 3840x4320 -> 3840x2160" which seems correct

[YxP]

Well I gave up and just disabled Hardware Accelerated GPU Scheduling (HAGS). Everything seems to work like before. Not what I wanted, but since I don't have games anymore that need Nvidia's frame generation it's ok. Stupid Microsoft.

[Celio1080p]

Try right clicking the mpc-be .exe , properties, compatibilty tab, "disable full screen optimizations". then in madvr settings use full screen exclusive mode and try d3d9 vs d3d11 to see if it helps




Yes that is what madvr is reporting - the video file is 3840x4320 then underneath it says "scale 3840x4320 -> 3840x2160" which seems correct

Hey there. Tried all that, same thing. An error, then crash. It doesn't happen with the 'not beta' build.

Tried the "disable full screen optimizations", tried d3d9, same thing.

About the scale, it is wrong because I know the movie resolution is not 3840x4320 - this is wrong. Completely.

The resolution of the movie is 3840x2160, I'm testing Blu-ray Remux 4K versions of some movies. Same result.

So I guess I can't use the latest version of MadVR... sad. :/

[huhn]

the file is not 4320 is it just wrong string it is neither scaling from that nor is is actually getting that and the OSD is also very clear about that.

madVR has a history of crashing with d3d11 native decode when a seek is performed just use a different decoder. there are other reasons for a crash btu these are static and happen always at a similar time.

[flossy_cake]

Well I finally got around to setting up 4k 119.88hz 10bit with autoswitching to HDR on my Windows 10 22H2 3060 machine connected to a S90D TV, and it's working, and the frame pacing is good as long as I keep my GPU clock speed high enough.

But I have a levels issue with HDR that I was hoping could be fixed with a third party tool or maybe even some Nvidia command line tool.

You see, when playing HDR files with MaxCLL 1000nits, such as S01E01 of The Grand Tour, I don't think 1000nits metadata is being sent to the display over the HDMI port. How can I tell? Because when my Samsung S90D receives no MaxCLL metadata over HDMI, it defaults to MaxCLL 10,000 nits, which means it starts rolling off the tone curve much earlier to preserve tones all the way up to 10,000 nits, and overall APL is dimmer as a result, and the HDR image is much less impactful.

My "ground truth" is when I play the file through the TV's internal media player. I believe the TV's internal media player sees the MaxCLL 1000nits metadata in the mkv file and uses the correct 1000nit tone curve which is much brighter.

I see some people on AVSforum bought HDFury device to inject 1000nits metadata into the HDMI signal for game consoles to solve this issue since game consoles don't send MaxCLL metadata either. But I was hoping I can use some command line app to do it instead on the PC. Ideally MadVR would tell the Nvidia driver to set the HDMI metadata to MaxCLL 1000 nits but that doesn't seem to be happening.

I am using the final non-beta version of MadVR - maybe that's the issue? In beta versions was it improved to send the right MaxCLL metadata over HDMI?

:thanks:

[huhn]

tone map HDR send HDR and set the max brightness to the point where it clips.

[flossy_cake]

tone map HDR send HDR and set the max brightness to the point where it clips.

I can't figure that out cause if I display this HDR clipping pattern (https://drive.google.com/uc?export=download&id=1cbAyu9ZIMpZNgkMnao0KNIrQwSm5gzv2) the clipping point changes with the contrast control.

Mediainfo says that file's MaxCLL is 1000nits but that can't be right because the white squares go up to 80% which is 3162 nits in the PQ scale?

I seem to think I want to put the S90D in HGIG mode and have MadVR manage the rolloff - is that correct? I can't use Movie/FMM mode cause of technical issues with those modes. I'm going to try getting game HDR working nicely first. And it has to be HGIG game cause that's the only game mode that stores is own HDR settings separately to SDR settings otherwise i would have to manually change the pic mode every time I want to play a HDR video

edit: nevermind I got a better pattern and that shows the proper clipping point in nits - 950 nits. Now in game HGIG i get the same rolloff at around 1300 nits just like Movie mode's rolloff - great

[flossy_cake]

and lol has anyone noticed how after exiting HDR mode back to SDR at the desktop, there's like a timer thingy counting down from around 20 seconds and when it hits 0 a grey ramp becomes smooth again? What the hell is that. Some dodgy Windows colour management bug or maybe the nvidia driver? At least it corrects itself, if it didn't then I'd have to restart the PC after displaying every HDR video. Oh and I've had that other bug strike where the HDMI signal switches to HDR but the pixel values are still SDR and levels are washed out. Only a restart seemed to fix that one. Sometimes going into FSE fixes it. Bugs galore!

[flossy_cake]

I think MadVR is correctly telling the NVidia driver to inject 1000nits metadata over the HDMI cable when the source video is 1000nits. For some reason the S90D uses dimmer tonemapping at 120hz than 24hz so that's what I was seeing. Luckily madshi put in some hdr boolean for profile selection so I can make it use 24hz only when the source is HDR - thanks madshi :)

[flossy_cake]

Is it possible to tell madVR's auto resolution switching to match the bitness of the source as well?

I can't see any option there in madVR, seems like NVCP is the only place to toggle between 8/10 bits?

[nevcairiel]

There is no benefit in lowering the bitdepth, especially since the source is getting processed from the file to the display. Just converting from YCrCb to RGB will create more then 8-bits of output, so if you output 10-bit you preserve that and reduce noise.

[huhn]

colorcontrol can do that.
there is no point to it when 10 bit works properly use 10 bit.

[QBhd]

I think MadVR is correctly telling the NVidia driver to inject 1000nits metadata over the HDMI cable when the source video is 1000nits. For some reason the S90D uses dimmer tonemapping at 120hz than 24hz so that's what I was seeing. Luckily madshi put in some hdr boolean for profile selection so I can make it use 24hz only when the source is HDR - thanks madshi :)

It almost sounds like the TV is doing BFI at 120Hz...

QB

[flossy_cake]

Ok thanks

So now I will use 10 bit on everything but I noticed it brings back that DWM overlay stutter in web browser SDR YouTube videos when subtitle appears on screen ( related to that regkey "OverlayTestMode"). But madVR is still smooth at 10bit thank goodness.

@huhn Iam not sure how colorconrol is go to intermingle with mad VR to get the HDR metadata from the file to know to switch to 10bit, that seems beyond the scope of colour control?

[flossy_cake]

I'm still very confused about how the madVR tone mapping works when the source is HDR and "output HDR" is ticked

I'm in HGIG mode on the S90D and I can see the clipping point is 950 nits on the test pattern. Other people report similar values on AVS forum. I understand this doesn't mean I'm getting 950 nits coming off the screen, it's just what the TVs processor is resolving due to its own internal tone curve. Proof of this is that I can lower the contrast control on the TV and then I can see all the tones up to 4,000 nits or more if I want, at cost of APL. But we want to maximise APL, so max out the contrast and the clipping point is 950 , ok fine.

Now what happens when I display the 4,000 nit clipping pattern? I have set madVR to tone map to 950 nits so I was expecting to be able to see all those tones up to 4,000 - shouldn't I? But I don't. All I see is up to like 1200 or so. So the mad VR tone mapping BT.2390 only gained me about 250 nits of extra highlight detail visibility. I thought it would start rolling off way sooner to make all tones up to 4000 visible. But it doesn't.

But, the result is still visually an improvement — I don't lose any appreciable APL on a typical scene, and the highlight detail visibility on test clips like bright fire and such looks better and less clipped and better hued. So madVR tone mapping is working well, it's just I don't have any clue what it's actually doing mathematically.

[huhn]

Ok thanks

So now I will use 10 bit on everything but I noticed it brings back that DWM overlay stutter in web browser SDR YouTube videos when subtitle appears on screen ( related to that regkey "OverlayTestMode"). But madVR is still smooth at 10bit thank goodness.

@huhn Iam not sure how colorconrol is go to intermingle with mad VR to get the HDR metadata from the file to know to switch to 10bit, that seems beyond the scope of colour control?

that's what it is made for create a preset and trigger that preset which madVR can do. you shouldn't do that anyway. but there is also the dithering issue with nvidia which colorcontrol can temporary fix.

dynamic target nits dynamic clipping and so on.

[flossy_cake]

that's what it is made for create a preset and trigger that preset which madVR can do.

Ah yeah I get it now — use the madVR command line on profile activation to call colour control to set 10bit. Man that's some crazy stuff, might do it because 99% of the time I only use 8bit content and I feel like the whole 8-bit rendering pipeline is more legacy and would have less compatibility issues.

[huhn]

sdr needs 10 bit(even 8 bit sources) more then HDR but what ever.

[flossy_cake]

sdr needs 10 bit(even 8 bit sources) more then HDR but what ever.

What sort of artifacts are you seeing with an 8-bit source and 8-bit display mode?

I've always been very satisfied with madvrs dithering.
My understanding was that madvrs pixel shader operates at 16 or 32 bit and then the final colour value is dithered to 8 bits? If I use 10bit display mode then it would presumably get dithered to 10 bits which is even more precise.

But I discovered last night my S90D has some "always on" debanding filter in the 0-10 stimulus range. But it's dynamic, depends on gradient direction and ramp window size. This is even active in game mode, so it must be part of Samsung's core processing.

[huhn]

noise

[flossy_cake]

noise

In the past I had taken screenshots of the dithering and found it was dithering +/- an 8bit tone on the green and magenta subpixels and that was practically invisible but I guess the sharpener and scalers could be interacting with it if the dithering is done before scaling and sharpening

A few months ago I was looking at that avshd709 8-bit grey ramp pattern and I believe that ramp pattern is actually faulty in the source, it is not actually a perfectly smooth ramp in the source, there are little ridges of thin bars in the ramp that the sharpener/scaler accentuates and the midpoint of the ramp skips a tone and is easily visible as a 2-tone step instead of 1-tone step

But anyway I'll give 10bit a try, it's 2025 time to move on from 8bit I guess

[flossy_cake]

I'm still very confused about how the madVR tone mapping works when the source is HDR and "output HDR" is ticked...
...Now what happens when I display the 4,000 nit clipping pattern? I have set madVR to tone map to 950 nits so I was expecting to be able to see all those tones up to 4,000 - shouldn't I? But I don't. All I see is up to like 1200 or so.


Found the reason: BT.2390 tonemapping rolls off the white channel much sooner than the primaries and secondaries. Got some better test patterns here (https://drive.google.com/drive/folders/10dOnw3dKh48Mmfm1-W7BMtW6X21pbY2F), and looking at the 700-10k nit pattern I can see the colours (RGBCMY) are all visible up to 10k. But the white is visible only up to ~2000 nits. This is a deliberate design choice of the BT.2390 function according to AI:

When the tone-mapping compresses the I channel, saturated colours are affected less in perceived brightness than white would be at the same original nit level.
In practice, this means very bright saturated colours appear relatively “protected” or less rolled-off compared to bright white at the same original peak luminance

[huhn]

a pattern that shows 10k red should be burned...

[flossy_cake]

Is it generally recommended to tick "measure each frame's peak luminance" in madvr?

Because I was thinking - what happens if I encounter a file which is incorrectly tagged as having MaxCLL of 10k nits when in fact the video is actually 1k nits?

In this case it seems madvr would apply the 10k rolloff thus resulting in a dim image, so I would need to enable madvr measuring of each frame to sidestep this kind of issue?

But then I thought, if it's measuring every frame's peak luminance, how does that work - does madvr use some kind of hysteresis characteristic or temporal smoothing of the measured peak to stop fluctuations in average picture level due to fluctuations in the measured peak luminance of each frame?

[flossy_cake]

I can't figure that out cause if I display this HDR clipping pattern (https://drive.google.com/uc?export=download&id=1cbAyu9ZIMpZNgkMnao0KNIrQwSm5gzv2) the clipping point changes with the contrast control.

Mediainfo says that file's MaxCLL is 1000nits but that can't be right because the white squares go up to 80% which is 3162 nits in the PQ scale?


Solved this issue as well just now - that test pattern is incorrectly tagged as 1000 nits, that's why the clipping point wasn't making mathematical sense.

Because if I enable madvr's "measure each frames luminance" it reports the test pattern is actually 1700 nits, and i can now see all the squares now that madvr is working with the correct value of 1700 to tonemap it down to my specified 950

Gosh what a mess HDR is

And Windows tonemapping of SDR to HDR is all wrong too, the darker tones are all way overbrightened no matter where I set the slider to in Windows HDR settings, so Windows has no idea of correct tonemapping either

[huhn]

windows SDR to HDR is done correctly cause windows is sRGB and videos are not it will change the gamma because to mircosoft everything is sRGB so madVR will need to change to sRGB to make it work correctly.

mpv will maybe do that correctly. madVR can not do sRGB. the slider is just changing the peak...

[flossy_cake]

windows SDR to HDR is done correctly cause windows is sRGB and videos are not it will change the gamma because to mircosoft everything is sRGB so madVR will need to change to sRGB to make it work correctly.

mpv will maybe do that correctly. madVR can not do sRGB. the slider is just changing the peak...

I'm seeing it in photos displayed in applications like Photoshop, Paint, Irfanview, Windows Photo Viewer. Must be a Windows 10 vs 11 thing, maybe they fixed it in 11 which I presume you are using if I'm not mistaken

[flossy_cake]

Is it just me or does DX9 mode not support HDR at all? I can't get it to output HDR levels at all. It seems only FSE DX11 is capable of guaranteeing HDR levels output. Even windowed DX11 does not guarantee HDR levels, most of the time it's just output at SDR levels (washed out).

Cause if true that means HDR is kind of hanging on by a thread with madvr.

Sometimes I can clear the bug and HDR works in DX11 windowed mode too but I dont know what triggers it. Sometimes switching to 8-bit in NVCP clears the bug. So maybe some automated workaround with ColorControl setting 10bit -> 8bit -> 10bit on windows logon (task scheduler) to reset the bug

[flossy_cake]

Ok I figured out how to clear the HDR levels bug in DX11 windowed. Not sure this would work for all systems but basically once FSE mode has been engaged one time, from then on windowed mode works fine. So you can create a hotkey in madvr to "enable-disable FSE mode" to clear the bug when it strikes. After reboot the bug returns tho, obviously.

[huhn]

I'm seeing it in photos displayed in applications like Photoshop, Paint, Irfanview, Windows Photo Viewer. Must be a Windows 10 vs 11 thing, maybe they fixed it in 11 which I presume you are using if I'm not mistaken

there is nothing to fix you are supposed to output sRGB. that madVR can not do that is not microsoft mistake.

if you have calibrated your device to not sRGB like everyone else SDR -> HDR will not look the same as SDR.

[Sunspark]

As a sidebar just for reading interest, Linux is getting a HDR colour management API soon. This will be hardware support as opposed to software support.

I have no HDR display but many of you do.

It'll be interesting to see what next year brings once the patchset is merged into the main kernel.

"VKMS supports two named transfer function colorops and two matrix
colorops.

Amdgpu advertises the following pipeline for GPUs with DCN 3 or newer:

1. 1D Curve EOTF
2. 3x4 CTM
3. Multiplier
4. 1D Curve Inverse EOTF
5. 1D LUT
6. 3D LUT
7. 1D Curve EOTF
8. 1D LUT

The supported curves for the 1D Curve type are:
- sRGB EOTF and its inverse
- PQ EOTF, scaled to [0.0, 125.0] and its inverse
- BT.2020/BT.709 OETF and its inverse
- Gamma 2.2 and its inverse

Note that the 1st and 5th colorops take the EOTF or Inverse
OETF while the 3rd colorop takes the Inverse EOTF or OETF.

The 3D LUT is a 17^3 tetrahedrally interpolated LUT but the mechanism
exists for other drivers to describe their own 3D LUT capability."

[huhn]

that's the exact stuff you want to avoid...

- BT.2020/BT.709 OETF and its inverse
oetf so utterly useless

- Gamma 2.2 and its inverse
not a spec.

- sRGB EOTF and its inverse literally the "issue" at hand.

no 2.4 or bt 1886 with defined black point all of this is useless or even bad for standart video.

[flossy_cake]

there is nothing to fix you are supposed to output sRGB. that madVR can not do that is not microsoft mistake.

if you have calibrated your device to not sRGB like everyone else SDR -> HDR will not look the same as SDR.

Calibrating my display to sRGB would just make it even worse due to sRGB having even more boosted shadows due to that linear segment near black.

I do agree it is very important for any SDR<->HDR conversion to know the user's display gamma. For instance if I tell madvr my display is calibrated to 2.2 when in reality it is 2.4, madvr's HDR->SDR conversion results in dark areas looking overly dark and almost crushed. If I give madvr the correct information (2.4) then the conversion is good. Although I find I need to set peak nits BT.2390 to about 220 even though I'm only at 140 nits at the display. 200 is okay as well, but S01E01 The Grand Tour tonemapped to 200 looks a bit off , Clarkson's face is too milky and compressed looking in the first indoor studio shot and bumping it to 220 just nudges it to the right place.

Anyway the levels i'm getting from windows 10 22H2's SDR->HDR conversion is complete rubbish and if you could see it with your own eyes you would agree it's wrong. Looking at any low APL scene it's complete nonsense, milky, like gamma 1.5 or something. The slider doesn't fix it. Doing SDR->HDR conversion should be much easier than vice versa as HDR dedicates way more bits in the dark tones so dark scenes and near black detail will be precisely preserved in a SDR->HDR conversion whereas the reverse is more difficult to get right. Trying to put something small into a big space is easier than vice versa.

[flossy_cake]

As a sidebar just for reading interest, Linux is getting a HDR colour management API soon. This will be hardware support as opposed to software support.

I have no HDR display but many of you do.

It'll be interesting to see what next year brings once the patchset is merged into the main kernel.

"VKMS supports two named transfer function colorops and two matrix
colorops.

Amdgpu advertises the following pipeline for GPUs with DCN 3 or newer:

1. 1D Curve EOTF
2. 3x4 CTM
3. Multiplier
4. 1D Curve Inverse EOTF
5. 1D LUT
6. 3D LUT
7. 1D Curve EOTF
8. 1D LUT

The supported curves for the 1D Curve type are:
- sRGB EOTF and its inverse
- PQ EOTF, scaled to [0.0, 125.0] and its inverse
- BT.2020/BT.709 OETF and its inverse
- Gamma 2.2 and its inverse

Note that the 1st and 5th colorops take the EOTF or Inverse
OETF while the 3rd colorop takes the Inverse EOTF or OETF.

The 3D LUT is a 17^3 tetrahedrally interpolated LUT but the mechanism
exists for other drivers to describe their own 3D LUT capability."

NVidia should have done this ages ago, it's 2025 we should be able to upload 3D LUTs and matrices to NVCP and have that apply globally to everything or per-app if we want.

Of course the hard part is generating a good 3D LUT in the first place. Displaycal is pretty good but very easy to make a mistake with the settings and botch the colours. I need a new colorimeter too, something that is accurate on wide gamuts and high nits.

[flossy_cake]

And the answer to the question "should measure every frame's luminance be ticked?".... a resounding YES, a million times yes. Looking at the measured nits on various HDR content it often goes way over what the file metadata says.

I'm still curious how madvr is doing it, because obviously you would get flickering APL if it updated the tonemap every frame as the new max nits increased at the next scene.

[huhn]

Calibrating my display to sRGB would just make it even worse due to sRGB having even more boosted shadows due to that linear segment near black.

I do agree it is very important for any SDR<->HDR conversion to know the user's display gamma. For instance if I tell madvr my display is calibrated to 2.2 when in reality it is 2.4, madvr's HDR->SDR conversion results in dark areas looking overly dark and almost crushed. If I give madvr the correct information (2.4) then the conversion is good. Although I find I need to set peak nits BT.2390 to about 220 even though I'm only at 140 nits at the display. 200 is okay as well, but S01E01 The Grand Tour tonemapped to 200 looks a bit off , Clarkson's face is too milky and compressed looking in the first indoor studio shot and bumping it to 220 just nudges it to the right place.

Anyway the levels i'm getting from windows 10 22H2's SDR->HDR conversion is complete rubbish and if you could see it with your own eyes you would agree it's wrong. Looking at any low APL scene it's complete nonsense, milky, like gamma 1.5 or something. The slider doesn't fix it. Doing SDR->HDR conversion should be much easier than vice versa as HDR dedicates way more bits in the dark tones so dark scenes and near black detail will be precisely preserved in a SDR->HDR conversion whereas the reverse is more difficult to get right. Trying to put something small into a big space is easier than vice versa.
SDR to HDR doesn't need the user gamma response it does not matter because it is sending HDR. the problem is that madVR should have been sRGB because that's the windows spec and windows thinks it is sRGB because everything is supposed to be sRGB on windows before HDR and special applications.

so SDR -> HDR uses sRGB only for that reason.

we never ever calibrated to sRGB and used a video renderer that turns gamma 2.4 to sRGB. we calibrate to 2.4 and send it as is windows can not know this.
there are tools trying to "fix" that.
https://github.com/ledoge/dwm_eotf
what so ever the point is yes win 11 is a mess but that is not an win 11 issue.

madVR could just convert to sRGB as the spec defines
madVR could also just directly reverse tonemap to HDR.
it does neither of this so win 11 uses the default that is sRGB as all applications should be.

i can see all that but is is not rubbish sRGB starts linear yeah that will mess the image up. the slider has nothing todo with that that just max brightness the inverse EOTF is still the same.

i do not understand what is there not to understand it uses the wrong spec for video so the result is trash there can be no other results because it is sRGB not gamma.
https://i.ibb.co/cXKn08ML/image.png

[flossy_cake]

SDR to HDR doesn't need the user gamma response it does not matter because it is sending HDR. the problem is that madVR should have been sRGB because that's the windows spec and windows thinks it is sRGB because everything is supposed to be sRGB on windows before HDR and special applications.

so SDR -> HDR uses sRGB only for that reason.

we never ever calibrated to sRGB and used a video renderer that turns gamma 2.4 to sRGB. we calibrate to 2.4 and send it as is windows can not know this.
there are tools trying to "fix" that.
https://github.com/ledoge/dwm_eotf
what so ever the point is yes win 11 is a mess but that is not an win 11 issue.

madVR could just convert to sRGB as the spec defines
madVR could also just directly reverse tonemap to HDR.
it does neither of this so win 11 uses the default that is sRGB as all applications should be.

i can see all that but is is not rubbish sRGB starts linear yeah that will mess the image up. the slider has nothing todo with that that just max brightness the inverse EOTF is still the same.

i do not understand what is there not to understand it uses the wrong spec for video so the result is trash there can be no other results because it is sRGB not gamma.
https://i.ibb.co/cXKn08ML/image.png

I understand what you are saying it's just that i know what sRGB gamma looks like and it's not what I'm seeing in Windows 10 22H2

sRGB gamma is not much different to Bt.1886 gamma (red line vs green line below) and yeah it looks "bad" to me but not "broken bad", just "bad" and i'm very fussy about shadow detail


https://drive.google.com/open?id=1MIwUSfc8HxmWx9pBqidaY7THfhv5rrs4S89Vgy1t2Y4
https://i.lensdump.com/i/g5ADyr.png

[huhn]

first of all it is the reverse and the graph is wrong you are on an oled it is absolute 2.4.

they are as different as it is possible to make then different for SDR.
it start at 2.4 and it end at 2.4 because it is 2.4.

shadow details are utterly ruined because of that.
if set madVR to calibrated 2.4 and set color & gamma to bt709 2.4 you get something "similar" as sRGB on on 2.4 calibrated screen.
which is completely washed out trash.

and for windows SDR to HDR you need to apply this the other way around.

what so ever SDR HDR isn't supported don't do it.

[flossy_cake]

first of all it is the reverse

Yes I think it reverses sRGB to convert it to linear light, then linear light to PQ. Probably. I'm guessing here. The end result is gonna be sRGB inside a PQ container. Boosted shadows, yes, but if only you could see what I'm seeing, it's so much more boosted than sRGB, it's a whole 'nother degree of wrongness above that almost like sRGB is being applied twice or something.

Anyway it doesn't matter, I just turn that shyt off and use native SDR for Windows and let MadVR autoswitch to HDR , it works fine in DX11 and I'm happy with the result.

[Sunspark]

How does it look when played with the Microsoft Films & TV app that most regular people would be using?

[flossy_cake]

How does it look when played with the Microsoft Films & TV app that most regular people would be using?

It looks the same for all content whether it's still images opened in various image viewing apps or video in any media player app. It's not a video/madvr issue at all, it's Windowses' SDR->HDR conversion that looks bogus, phony and wrong to me. This is on a heavily debloated Win10 22H2 install, so maybe some windows colour management system stuff got disabled, which I want.

[flossy_cake]

Just learned a cool functionality

I am the kind of user who goes nuts with the profiles. I use various aspect ratio correction profiles, 9 different sharpening profiles, 3 for debanding & artefact removal etc. If you don't use profiles very much then you probably won't care about this at all.

The issue is that normally we can only pick one profile to tag our files/folders with, as per the tips.txt like: [profile='SomeProfile'], meaning we would have to create lots of profile bloat in the MadVR Settings GUI to accommodate a selection of more than one profile at a time.

But with "profile autoselect rules" it is possible to pick and choose MULTIPLE PROFILE TAGS to apply on a per-file, per-season or per-show basis. So now I can do tags like this:

D:\Videos\ShowName\Season 1 [prof=adaptivesharpen low] [prof=aspect squish 720 to 704] [prof=deband medium]\File.mkv

...and it will apply those 3 profiles only to episodes in season 1 - great just what I wanted thankyou Madshi :thanks:

The trick is inside MadVR's "profile autoselect rules" to put something like this

if (filepath == "*[prof=adaptivesharpen low]*") "adaptivesharpen low"
if (filepath == "*[prof=deband medium]*") "deband medium"
if (filepath == "*[prof=aspect squish 720 to 704]*") "aspect squish 720 to 704"

(* = wildcard)



Then, if you wanna go a bit more advanced and make it so MadVR preferences lower level tags in the path hierarchy (for instance if you already tagged a season folder but wanted to override it for a single episode in the series) do like this instead:

if (filepath == "*[prof=adaptivesharpen low]*") and (filepath != "*[prof=adaptivesharpen low]\*[prof=*") "adaptivesharpen low"

This excludes applying the profile if there is another profile tag downstream from it in the path hierarchy.


edit: of course, it's also possible to make it so instead of tagging your files/folders you instead define the mapping from folder/filenames to profiles inside the "profile autoselect rules" section. But this would also result in bloat since you'd have to write that folder/filename rule multiple times (once inside each profile group category). But more importantly for me personally I like to visually see and confirm the tag(s) at the moment before screening the file as a reminder of what profiles I've got active for that series/episode at a glance without having to dig through the GUI and look inside multiple profile categories to figure out what is actually active for that particular show/episode.

[Sunspark]

Very cool, but be careful not to run into the too many characters for file paths limit. Windows can get iffy if filenames/directory character count goes over 260. You can increase this in the registry, but that's so-so depending on how the application handles it.

[flossy_cake]

Very cool, but be careful not to run into the too many characters for file paths limit. Windows can get iffy if filenames/directory character count goes over 260. You can increase this in the registry, but that's so-so depending on how the application handles it.

Damn, some of my paths are already like 170 characters. I probably should be okay but there's this big looney tunes collection on channel BT with its own extensive tagging format so I may run into trouble with that if I start adding my own

[Sunspark]

You can try.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled

Change the value from 0 to 1.

It will work with apps that were coded to understand that it is possible to have paths larger than 260.

[clsid]

MPC-HC can handle long paths without any need for changes to Windows settings/registry.

Also, that registry tweak does not magically fix old apps with hardcoded limits.

[flossy_cake]

Just found a path with 230 chars so I'm getting close. I see there is a group policy setting for it. Probably won't need it given what clsid wrote, but I often use Avisynth for realtime playback in MPC so Avisynth source filters need to handle the long paths also

[ABDO]

I’ve wanted to save video files after upscaling with madVR before, especially to get a nicer HD version of some old SD stuff, but it’s way more complicated than just clicking a save button. I tried using screen recorders to capture the output live—Bandicam actually worked okay for me, but the resulting file size was massive, and sometimes the quality took a hit depending on the PC load. It’s just not the same as a built-in export, which honestly would be amazing for editing workflows.

If you’re into photo editing at all, the process for creative stuff like how to invert colors on a picture (https://www.screencapture.com/blog/how-to-invert-colors-on-a-picture/) is much more straightforward in desktop editors. There, you just use the right tool and you’re done in a few clicks—way easier than capturing and re-encoding video output.

[flossy_cake]

I’ve wanted to save video files after upscaling with madVR before, especially to get a nicer HD version of some old SD stuff, but it’s way more complicated than just clicking a save button. I tried using screen recorders to capture the output live—Bandicam actually worked okay for me, but the resulting file size was massive, and sometimes the quality took a hit depending on the PC load. It’s just not the same as a built-in export, which honestly would be amazing for editing workflows.

If you’re into photo editing at all, the process for creative stuff like how to invert colors on a picture (https://www.screencapture.com/blog/how-to-invert-colors-on-a-picture/) is much more straightforward in desktop editors. There, you just use the right tool and you’re done in a few clicks—way easier than capturing and re-encoding video output.

The ideal for me would be an Avisynth filter which can send an Avisynth clip object through any DirectShow filter, like MadVR. Then we have the raw output from MadVR and can do whatever we like with it (ffmpeg can take an Avisynth clip as an input clip if desired to transcode).

On a separate note, does anyone set up their MadVR to resolve the 235-255 range for SDR?

I've been playing around with that and can't decide if it's worth it. I overlaid "YMax" in the corner of the screen with Avisynth while watching SDR content which reports the maximum Y value for the current frame to see how much content actually uses Y values greater than 235, and to my surprise quite a lot of it does. This means I'm missing out on highlight pops in SDR. Even old shows like Law and Order Criminal Intent from 2001 has many scenes with YMax > 235 (or > 944 for 10-bit SDR files).

To resolve the 235-255 region in madvr it seems there are 2 possible methods -- these methods seem to work correctly for me when my GPU is outputting full range 0-255 to the display:

Method 1:

In madvr settings -> "the display expects the following RGB output levels" -> set to 0-235.
Check with this AVSHD709 pattern (https://drive.google.com/uc?export=download&id=15mdHcIcdTeWFl8qmw-y5ccOQyo2asxuU) that black starts at 16 and white ends at 255.
Increase the peak brightness on your display by the amount needed to make tone 235 the same brightness it was before.


Now you should have the same brightness of all the tones up to 235, but highlights above 235 will now "pop" brighter than before. Unfortunately taking screenshots doesn't reflect this setting so it can't be used to validate the output, but eyeballing it on test patterns seems correct. Without a meter you'll have to guess how much to increase peak brightness on your display though. Alternatively:

Method 2:

Just tag the file with [levels=PC] [blacklevel=-14].

For some reason -14 instead of the mathematically expected -16, not sure why, but -14 gives me the closest match with method 1 above:

No file tags - typical orthodox 16-235 resolution:

https://i.imgur.com/N4mYCZo.png


File tagged with [levels=PC] [blacklevel=-14] to resolve 16-255:


https://i.imgur.com/7LqGdMd.png


It's probably better not to use the filetagging method as it's a bit of a bodge - better to just use method 1 I think. But it's the only way I could take a screenshot that shows the difference.