madVR - high quality video renderer (GPU assisted)

[SirMaster]

The screenshot I posted is the setting I'm using. Thanks for your feedback.

Ah, screenshot didn't come through on the forum for me.

Best to use external image host on this forum just FYI.

[Siso]

Ah, screenshot didn't come through on the forum for me.

Best to use external image host on this forum just FYI.

It is uploaded on ext image site.

[Selur]

@huhn: Thanks for clearing that up. :)

[Megalith]

HDR no longer works on my system, and I have no idea why. Starting a video puts my TV into HDR mode, but the image is washed out in both windowed and full-screen modes (normally, it would only be washed out in windowed mode). Windows 10, GeForce RTX 3080 Ti, latest NVIDIA driver.

EDIT: A restart fixed it.

[x7007]

NV HDR doesn't work properly with Potplayer with 526.47 Windows 11 22H2??? I am using 4090 and I just noticed the NV HDR is not different than SDR and nothing in MADVR is working, changing from 0-255 to 16-235 or anything in the normal menu,, what is going on??? how can I fix this? only the OS HDR is working



HDR no longer works on my system, and I have no idea why. Starting a video puts my TV into HDR mode, but the image is washed out in both windowed and full-screen modes (normally, it would only be washed out in windowed mode). Windows 10, GeForce RTX 3080 Ti, latest NVIDIA driver.

EDIT: A restart fixed it.


Lol,, same, restart works...

[huhn]

there is a major known and supposed to be fixed issue with madVR and win 11h2 the fix is in beta 164 or 165 give this a try.

the issue is related to the duplication of device ids where it is possible that a device will not response to anything changes in that device id pretty much breaking madVR.

the problem is the driver shouldn't matter and i mostly tested this on AMD.

[OpenSource Ghost]

I am not sure if this is MPC-HC or madVR issue and as such I am asking in both threads.

MPC-HC keep trying to use network connection for video files when madVR is used as external filter. Why? Local Network in madVR tray is disabled. I don't use any MPC-HC plugins that require local or public network use. MPC-HC requests network access only when I launch video files to rendered with madVR, but never when I launch audio files, regardless of renderer. If I launch video files when madVR is not default preferred external renderer, then there are no attempts to use local network.

My PC is highly isolated and doesn't even have local network sharing capabilities, only WAN access over VPN. On top of that I disable private and public network use of MPC-HC executable with basic Windows firewall, but such blocking causes a delay when I launch MPC-HC because MPC-HC attempts to use network when madVR is the set primary external video renderer. If I just disconnect PC from LAN, then there is no delay.

Is there a way to fully disable network functionality of MPC-HC and madVR through their options? Again, network access requests only happen if I tr yto launch video files in MPC-HC when madVR is the default prefered renderer.

[mclingo]

Is it something to do with the licence maybe, are you using a pre licence version? v0.92.17 with no madvmeasure addons

[clsid]

MadVR does local network discovery when its tray icon is enabled. Disabling that in its tray icon right-click menu should stop it.

[shaolin95]

Hi all!
So I using Nvidia 23fps which windows shows as 23.976.
In about 1 hour and 20 minutes of playing Hobbit Part 2, I got 3 dropped frames and 1 repeated. Is this acceptable or is there anything I can do to prevent any drops?
I mean,. this is a 5600x with RTX 3070 dedicated to HTPC only.
Projector is a JVC RS540
Thanks

[flossy_cake]

Hi all!
So I using Nvidia 23fps which windows shows as 23.976.
In about 1 hour and 20 minutes of playing Hobbit Part 2, I got 3 dropped frames and 1 repeated. Is this acceptable or is there anything I can do to prevent any drops?

What does Ctrl+J say for "1 frame drop every..."

You can fine tune the refresh rate with CRU to make it say "1 frame drop every <many> hours" but it's convoluted and difficult, requires using calculator and adding/removing blanking since we only get 2 decimal places of precision for the pixel clock which isn't enough.

Also are you at 1080p23 or 2160p23? If the latter then due to the the large pixel count, 2 decimal places of pixel clock precision may be sufficient for making a quick 1-click adjustment in CRU.

[shaolin95]

What does Ctrl+J say for "1 frame drop every..."

You can fine tune the refresh rate with CRU to make it say "1 frame drop every <many> hours" but it's convoluted and difficult, requires using calculator and adding/removing blanking since we only get 2 decimal places of precision for the pixel clock which isn't enough.

Also are you at 1080p23 or 2160p23? If the latter then due to the the large pixel count, 2 decimal places of pixel clock precision may be sufficient for making a quick 1-click adjustment in CRU.

2160p23 . The time for 1 frame drop changes but usually 50mins to over an 1 hour is what it shows.
I c was able to get great results with jriver and its built in vidoeclock BUT that means no Atmos so useless to me :/
Guess is not a big deal just ocd lol

[flossy_cake]

2160p23 . The time for 1 frame drop changes but usually 50mins to over an 1 hour is what it shows.

1 per hour isnt too bad. You'll have to watch a few movies and see if you notice it once or twice. If the camera is not moving very much at that point in the movie, it won't even be visible at all.

With my 1080p23 mode I initially had 1 skip in 15 minutes and I was noticing that unfortunately. I wasn't trying to notice it, it just kept presenting itself to me. At first I couldn't get CRU to register my custom mode in Windows list of display modes, but that was due to it clashing with another 24hz mode defined elsewhere in CRU (in the CTA block, it turned out). Once I deleted that mode and created my custom mode in another separate block in CRU, it worked.

NVCP also has its own custom res utility and I did manage to get it to work but it was so buggy and awful. CRU is better imo as it just modifies the EDID stored in the Windows Registry, but it seems the Nvidia driver is the bit of code which actually reads it and uses it to register the new modes in Windows list of display modes. MadVR "sees" whatever is in the list of Windows own display modes list. Also I love the fact that I can backup the EDID with 1 click in CRU so I don't have to remake all my modes if I do a driver update or something.

[shaolin95]

1 per hour isnt too bad. You'll have to watch a few movies and see if you notice it once or twice. If the camera is not moving very much at that point in the movie, it won't even be visible at all.

With my 1080p23 mode I initially had 1 skip in 15 minutes and I was noticing that unfortunately. I wasn't trying to notice it, it just kept presenting itself to me. At first I couldn't get CRU to register my custom mode in Windows list of display modes, but that was due to it clashing with another 24hz mode defined elsewhere in CRU (in the CTA block, it turned out). Once I deleted that mode and created my custom mode in another separate block in CRU, it worked.

NVCP also has its own custom res utility and I did manage to get it to work but it was so buggy and awful. CRU is better imo as it just modifies the EDID stored in the Windows Registry, but it seems the Nvidia driver is the bit of code which actually reads it and uses it to register the new modes in Windows list of display modes. MadVR "sees" whatever is in the list of Windows own display modes list. Also I love the fact that I can backup the EDID with 1 click in CRU so I don't have to remake all my modes if I do a driver update or something.
So do you get 0 drops now?
Thanks!

[flossy_cake]

So do you get 0 drops now?


Not quite -- about 1 drop per 12 hours, which for me is good enough. It even fluctuates a bit depending on ambient temperature.

So let's say you're targeting 23.976hz (24/1.001 to be precise, and precision is important here) and your actual refresh is 23.977hz, the error is 0.001hz which would theoretically give you 1 repeat every 16 minutes (1/0.001/60=16).


Error = Frame drop every
0.001hz = 16 minutes
0.0001hz = 2.7 hours
0.00001hz = 27 hours


For 1 drop per 12 hours I had to get it within around 0.00002hz.

[shaolin95]

Not quite -- about 1 drop per 12 hours, which for me is good enough. It even fluctuates a bit depending on ambient temperature.

So let's say you're targeting 23.976hz (24/1.001 to be precise, and precision is important here) and your actual refresh is 23.977hz, the error is 0.001hz which would theoretically give you 1 repeat every 16 minutes (1/0.001/60=16).


Error = Frame drop every
0.001hz = 16 minutes
0.0001hz = 2.7 hours
0.00001hz = 27 hours


For 1 drop per 12 hours I had to get it within around 0.00002hz.

So in the nvcp you set it to anything specific before adding the cru one?
Where do you get the timings from?
Maybe I can PM you to not of off topic?
Thank you!!

[Klaus1189]

You can go on here if you want:
AMD, Intel and Nvidia driver issues and last recommended version (https://forum.doom9.org/showthread.php?t=176013)

A guide for it would be nice to have.

[flossy_cake]

So in the nvcp you set it to anything specific before adding the cru one?

I avoid setting refresh rate in NVCP as it seems to have issues distinguishing 23 vs 24, and 59 vs 60, when making custom modes with CRU.


Where do you get the timings from?

Well, the situation is a bit tricky. In CRU we can select "automatic HDTV" and this will choose timings CRU thinks is standard:

https://i2.lensdump.com/i/RgAwfD.png

But it is different to what CTA specifies (https://web.archive.org/web/20171130183104/https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf):

https://i3.lensdump.com/i/RgA5BA.png

Note the bit highlighted in red which says that 23.976hz mode will be the same as 24.0hz mode but with pixel clock reduced slightly to produce 23.976hz.

So I start by plugging CTA's timings into CRU:

https://i.lensdump.com/i/RgAGYM.png

I'm not sure why CRU highlights front porch in red. It is a weirdly high value but hey that's what CTA says it should be. (edit: it seems the mode must be added to a new "display id 1.3/2.0" extension block, in which the value won't be red and CRU will even automatically select CTA timings when selecting "automatic HDTV").

Now lower the pixel clock until resulting refresh rate is 23.976:

https://i2.lensdump.com/i/RgAh2Q.png

Now we are ready to make some very small changes to the refresh rate to minimise the "1 frame drop/repeat every..." on MadVR's ctrl+J. Drop = refresh rate is slightly too slow, repeat = slightly too fast.

The problem is we don't have enough decimal places of precision to elicit less than a 0.001hz in the refresh rate. You might get lucky and a 0.001hz nudge might get you to a satisfactory value on ctrl+J. But for higher precision we can instead change the number of pixels in the blanking zones which has a very tiny effect on the refresh rate. To calculate the amount I'm using this calculator: https://www.monitortests.com/pixelclock.php?width=3840&height=2160&refresh=23.976023&decimals=2&minhblank=1494&maxhblank=1826&hmultiple=8&minvblank=91&maxvblank=99&vmultiple=1&maxpclock=165:

https://i1.lensdump.com/i/Rgitg0.png

Note how I've already prefilled everything there -- the blanking values I've set to +/- 10% of the CTA spec. This should give us enough adjustability without straying too far from the spec.

Now suppose you want to increase the refresh rate by 0.00001hz, change it from 23.976023 to 23.976033, click calculate, then pick one of the resulting modes and copy their total resolution into CRU:

https://i3.lensdump.com/i/RgWfuK.png

And remember: in CRU you may need to remove all other 24hz modes to avoid clashes, and create your new custom mode in a separate block. Otherwise it didn't work for me and the refresh rate didn't change -- this can be checked with Ctrl+J or vsynctester.com.

Good luck.

[Alexkral]

I just noticed that the results of custom pixel shaders are stored in a 16-bit buffer in beta versions, and the 32-bit option has disappeared from the "trade quality for performance" menu.

I can't understand what relationship it can have with the tone mapping development.

[chros]

Aks him on avs, Alex! I think we reached.the new low with madvr "development": he doesn't even want to fix obvious bugs that he introduced, let alone lack of manual/unit tests.

@flossy_cake: you can check out this post (https://forum.doom9.org/showthread.php?p=1868998#post1868998) about CRU.

[huhn]

while the development is literally abandon ware state now.
the 32 bit buffer option was and is pointless in the first place.
but i have to say if you know a reason this should ever matter i would like to know and learn more.

hands down madVR is in a pretty unacceptable state the turing card are now 5 years old and even the beta madVR version don't have settings that will have a higher chance to work with these cards they still default to 8 present queue while 1-3 is recommend or necessary on now >old< GPUs.

it's free software and this is part of it.

[shaolin95]

I avoid setting refresh rate in NVCP as it seems to have issues distinguishing 23 vs 24, and 59 vs 60, when making custom modes with CRU.



Well, the situation is a bit tricky. In CRU we can select "automatic HDTV" and this will choose timings CRU thinks is standard:


But it is different to what CTA specifies (https://web.archive.org/web/20171130183104/https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf):


Note the bit highlighted in red which says that 23.976hz mode will be the same as 24.0hz mode but with pixel clock reduced slightly to produce 23.976hz.

So I start by plugging CTA's timings into CRU:

https://i.lensdump.com/i/RgAGYM.png

I'm not sure why CRU highlights porch in red. It is a weirdly high value but hey that's what CTA says it should be.

Now lower the pixel clock until resulting refresh rate is 23.976:


Now we are ready to make some very small changes to the refresh rate to minimise the "1 frame drop/repeat every..." on MadVR's ctrl+J. Drop = refresh rate is slightly too slow, repeat = slightly too fast.

The problem is we don't have enough decimal places of precision to elicit less than a 0.001hz in the refresh rate. You might get lucky and a 0.001hz nudge might get you to a satisfactory value on ctrl+J. But for higher precision we can instead change the number of pixels in the blanking zones which has a very tiny effect on the refresh rate. To calculate the amount I'm using this calculator: https://www.monitortests.com/pixelclock.php?width=3840&height=2160&refresh=23.976023&decimals=2&minhblank=1494&maxhblank=1826&hmultiple=8&minvblank=91&maxvblank=99&vmultiple=1&maxpclock=165:


Note how I've already prefilled everything there -- the blanking values I've set to +/- 10% of the CTA spec. This should give us enough adjustability without straying too far from the spec.

Now suppose you want to increase the refresh rate by 0.00001hz, change it from 23.976023 to 23.976033, click calculate, then pick one of the resulting modes and copy their total resolution into CRU:


And remember: in CRU you may need to remove all other 24hz modes to avoid clashes, and create your new custom mode in a separate block. Otherwise it didn't work for me and the refresh rate didn't change -- this can be checked with Ctrl+J or vsynctester.com.

Good luck.

This is a great post!
I will have it for reference if mine goes wacky again but right now I am very happy :D

Thank you!!!!

[Alexkral]

while the development is literally abandon ware state now.
the 32 bit buffer option was and is pointless in the first place.
but i have to say if you know a reason this should ever matter i would like to know and learn more.

hands down madVR is in a pretty unacceptable state the turing card are now 5 years old and even the beta madVR version don't have settings that will have a higher chance to work with these cards they still default to 8 present queue while 1-3 is recommend or necessary on now >old< GPUs.

it's free software and this is part of it.

Well, reading an 8 bit blue (0, 0, 213) I get 0.8352966010 x 255 = 213.000633255 with 32 bits, and 0.8349609076 x 255 = 212.915031438 with 16 bits. It's a small difference, but it can be important depending on what you're doing.

[chros]

I just noticed that the results of custom pixel shaders are stored in a 16-bit buffer in beta versions, and the 32-bit option has disappeared from the "trade quality for performance" menu.
Just went back till beta 38 (2018.12.27) and the option was already gone and nothing in the beta changelog (https://pastebin.com/6N9tr0t6) either that I could find.

[ryrynz]

while the development is literally abandon ware state now.



hands down madVR is in a pretty unacceptable state..



it's free software and this is part of it.

Agreed. Pretty disrespectful behavior. At the very least provide a maintenance release with any bugs fixed in the betas and address the default settings. That always seemed to be the intention.

[Alexkral]

Just went back till beta 38 (2018.12.27) and the option was already gone and nothing in the beta changelog (https://pastebin.com/6N9tr0t6) either that I could find.

Yeah, I just wanted to put it on the record, I don't feel comfortable in avs and I'm not interested in the answer either.

[ryrynz]

I can't understand what relationship it can have with the tone mapping development.

I'll go out on a limb here and say it's a Envy only feature. Have a chat to Manni, your friendly madVR Envy representative for more info. :)

[shaolin95]

People complaining should totally ask for a refund...

[dbezerra]

I think it's time for alternatives. MPV has made progress on HDR/DV tone mapping, and I hope it will fully support DV one day. JRiver is also pressing forward. Hopefully at some point one of those solutions will have quality parity with MadVR main scenarios (for me - 1st, HDR tonemapping & DV support, 2nd: 1080p to 4K upscaling).

[kasper93]

Guys stop... You won't get anywhere by complaining.

Hard truth is that madVR is abandonware and has been for a while. As much as I like this software, it's time to let go. Any development is in DTM area which directly contributes to madVR Envy and even this is progressing very slowly. Last madVR release was 30 Sep 2018 and since then there were only DTM test versions, which introduced regressions on its own (crop, smoothmotion and so on). madshi were teasing subscription model for madVR, but this never happened, clearly it is not a priority. And frankly without it, don't except any real development, bug fixes or new features, that were added to Envy like NLS. Obviously, there is no business incentive to port (enable, coz it is mostly the same codebase) them to madVR in current state.

Move on... it is not 2013 anymore.

You should be using mpv with gpu-next (libplacebo). It is easy to use, you really do not need full GUI to adjust few player settings and OSC is good for all playback related controls. Or JRiver if you prefer more.
I think it's time for alternatives. MPV has made progress on HDR/DV tone mapping, and I hope it will fully support DV one day. JRiver is also pressing forward. Hopefully at some point one of those solutions will have quality parity with MadVR main scenarios (for me - 1st, HDR tonemapping & DV support, 2nd: 1080p to 4K upscaling). What do you mean? mpv (w/ libplacebo) supports Dolby Vision, HLG, which madVR does not and doesn't look like it will anytime soon ...and uh upscaling is also supported. Notably libplacebo is superior to madVR it almost every way, more future complete, modern, open source and cross platform. It has better performance, better customizability, film grain synthesis on GPU, tonemapping, frame blending, all color managment stuff. You name it... I think only madVR feature that is missing is dynamic crop, but this is also little broken in recent madVR test build.

I will not convince you to switch, but to be honest your time would be better spent reporting mpv issues/requests, than complaining about lack of madVR development here.

[shaolin95]

I avoid setting refresh rate in NVCP as it seems to have issues distinguishing 23 vs 24, and 59 vs 60, when making custom modes with CRU.



Well, the situation is a bit tricky. In CRU we can select "automatic HDTV" and this will choose timings CRU thinks is standard:

https://i2.lensdump.com/i/RgAwfD.png

But it is different to what CTA specifies (https://web.archive.org/web/20171130183104/https://standards.cta.tech/kwspub/published_docs/CTA-861-G_FINAL_revised_2017.pdf):

https://i3.lensdump.com/i/RgA5BA.png

Note the bit highlighted in red which says that 23.976hz mode will be the same as 24.0hz mode but with pixel clock reduced slightly to produce 23.976hz.

So I start by plugging CTA's timings into CRU:

https://i.lensdump.com/i/RgAGYM.png

I'm not sure why CRU highlights porch in red. It is a weirdly high value but hey that's what CTA says it should be.

Now lower the pixel clock until resulting refresh rate is 23.976:

https://i2.lensdump.com/i/RgAh2Q.png

Now we are ready to make some very small changes to the refresh rate to minimise the "1 frame drop/repeat every..." on MadVR's ctrl+J. Drop = refresh rate is slightly too slow, repeat = slightly too fast.

The problem is we don't have enough decimal places of precision to elicit less than a 0.001hz in the refresh rate. You might get lucky and a 0.001hz nudge might get you to a satisfactory value on ctrl+J. But for higher precision we can instead change the number of pixels in the blanking zones which has a very tiny effect on the refresh rate. To calculate the amount I'm using this calculator: https://www.monitortests.com/pixelclock.php?width=3840&height=2160&refresh=23.976023&decimals=2&minhblank=1494&maxhblank=1826&hmultiple=8&minvblank=91&maxvblank=99&vmultiple=1&maxpclock=165:

https://i1.lensdump.com/i/Rgitg0.png

Note how I've already prefilled everything there -- the blanking values I've set to +/- 10% of the CTA spec. This should give us enough adjustability without straying too far from the spec.

Now suppose you want to increase the refresh rate by 0.00001hz, change it from 23.976023 to 23.976033, click calculate, then pick one of the resulting modes and copy their total resolution into CRU:

https://i3.lensdump.com/i/RgWfuK.png

And remember: in CRU you may need to remove all other 24hz modes to avoid clashes, and create your new custom mode in a separate block. Otherwise it didn't work for me and the refresh rate didn't change -- this can be checked with Ctrl+J or vsynctester.com.

Good luck.
One question..with that high front porch in red it won't let me OK as it grayed out.
How did you do it?

Also what do you mean by "create your new custom mode in a separate block."?
Thanks

[huhn]

Well, reading an 8 bit blue (0, 0, 213) I get 0.8352966010 x 255 = 213.000633255 with 32 bits, and 0.8349609076 x 255 = 212.915031438 with 16 bits. It's a small difference, but it can be important depending on what you're doing.

you have to think what madVR does not what you do in this case.

do you know if it was 32 bit before it is send to the custom shader or 16 ?
do you know it will keep it at 32 bit after getting it back?
and that's pretty much all that option changes nothing more.

[glc650]

What do you mean? mpv (w/ libplacebo) supports Dolby VisionUsing the RPU to convert the color space to remove the green/pink tint on playback is hardly what I would call support for DV.

[Alexkral]

you have to think what madVR does not what you do in this case.

do you know if it was 32 bit before it is send to the custom shader or 16 ?
do you know it will keep it at 32 bit after getting it back?
and that's pretty much all that option changes nothing more.

I don't need to know all that, when the madVR option changes the result it's clear that it's because in some madVR step there is a bit depth reduction. And yes, the option changes the result, nothing more.

[flossy_cake]

One question..with that high front porch in red it won't let me OK as it grayed out.
How did you do it?

Ok that's a weird one. At first I thought it must be due to a pixel clock limit as that is mentioned a lot in the author's thread.

But it doesn't seem to be that as I can reduce the pixel clock down to a very low value and the ok button is still greyed out due to the front porch being too high (it's definitely not too high - that's what the CTA spec says it should be).

Even weirder is if I create a new "display id 1.3/2.0" block in the extension block at the bottom, and select "automatic HDTV", and enter only the values 3840x2160 &24hz, CRU automatically populates the rest with the CTA's timings including the massive 1276 horizontal blanking, and it's not red, and the ok button is not greyed out.

https://i3.lensdump.com/i/Rg5AIT.png



Also what do you mean by "create your new custom mode in a separate block."?


In the extension block, I put my custom modes in a new "display id 1.3" data block. On my system that was the only way Nvidia would see them and add them to the list of resolutions in Windows display settings.

[huhn]

it nearly for sure is using 16 bit in the first place. if you want 32 bit you have to convert it your self because that's nearly for sure what that option does nothing more nothing less. so is there a feature that is been removed yes. does it lower bit deep most likely not...

just as a reminder features:

- high quality chroma upsampling
- high quality scaling (bicubic, mitchell, lanczos, spline etc)
- high quality YCbCr -> RGB conversion
- gamut & gamma correction for display calibration
- full 16bit processing queue
- final 16bit processing result is dithered down to RGB output bitdepth
- bypasses graphics card's video (damage) algorithms
- all work is done via GPU shaders (except madVR's IVTC atm)
- no shortcuts, highest quality has priority over anything else

this didn't age well.

and yes 32 bit float has different results compered to 16 if it was 16 or 32 bit before doesn't matter.

to prove that madVR was 32 bit before you would need a limited range RGB source that is blue 213 like your example. and you need to check run custom shaders in video levels instead of PC level.
because if the difference comes from limited to full range conversation using 32 bit or 16 bit that would be funny...

just as a reminder unticking run custom shaders in video level instead of PC level always adds float point "errors" because madVR works in limited range(even with full range input!!!) all the time until presentation.

[shaolin95]

Ok that's a weird one. At first I thought it must be due to a pixel clock limit as that is mentioned a lot in the author's thread.

But it doesn't seem to be that as I can reduce the pixel clock down to a very low value and the ok button is still greyed out due to the front porch being too high (it's definitely not too high - that's what the CTA spec says it should be).

Even weirder is if I create a new "display id 1.3/2.0" block in the extension block at the bottom, and select "automatic HDTV", and enter only the values 3840x2160 &24hz, CRU automatically populates the rest with the CTA's timings including the massive 1276 horizontal blanking, and it's not red, and the ok button is not greyed out.

https://i3.lensdump.com/i/Rg5AIT.png




In the extension block, I put my custom modes in a new "display id 1.3" data block. On my system that was the only way Nvidia would see them and add them to the list of resolutions in Windows display settings.

I tried that but I see in the block part but cannot get it to allow that high porch in the detailed resolutions above. And adding it when creating the block won't show in Nvidia or windows res options.
Hope that makes sense
Maybe you can export yours and I can use it as a base?
Thanks!

[Klaus1189]

@shaolin95: Please use an external file hoster like google drive or whatever. All your pictures of your recent posts can not be viewed.

[OpenSource Ghost]

MadVR does local network discovery when its tray icon is enabled. Disabling that in its tray icon right-click menu should stop it.

I am not able to find the option to disable madVR tray icon, but madVR OP does say that madVR looks for subtitles or whatever other material related to current video playback over LAN. It doesn't just try to connect to LAN, but also to WAN. It attemps to use DNS settings specified in Windows network options to resolve whichever domain addresses. All local multicast discovery protocols (mDNS, IGMP, LLDP, LLMNR, 224.0.0.0-255.255.255.255 IP range, etc) are disabled on my network via Windows client settings and via router VLAN isolation settings. For what can madVR be looking over WAN???

[Sunspark]

I have experimented with CRU in the past as well as the poorly implemented Intel Custom Resolutions panel.

One observation I have is that sometimes the blocks already present in the display might have accurate timings, but only for HDMI. I am not currently using either CRU or Intel's CR, and with MadVR it says 23.976 and days between frame drop or repeat. Could it really be that my display came pre-defined that accurately? I am skeptical. It is also possible that MadVR is not measuring the numbers with that degree of precision.. or is it?

It is assumed here that MadVR is reporting the numbers accurately but can it be measured empirically?

[kasper93]

Using the RPU to convert the color space to remove the green/pink tint on playback is hardly what I would call support for DV. Oh well, more than you get out of madVR or anything else...

[huhn]

I have experimented with CRU in the past as well as the poorly implemented Intel Custom Resolutions panel.

One observation I have is that sometimes the blocks already present in the display might have accurate timings, but only for HDMI. I am not currently using either CRU or Intel's CR, and with MadVR it says 23.976 and days between frame drop or repeat. Could it really be that my display came pre-defined that accurately? I am skeptical. It is also possible that MadVR is not measuring the numbers with that degree of precision.. or is it?

It is assumed here that MadVR is reporting the numbers accurately but can it be measured empirically?

if you have read about this and used it you should understnad that:
1. your display has nothiung todo with that at all how good it is out of the box.
2. madVR know when it drops a frame if it is measured accurate or not does not matter.
3. the most important one repeated dropped frame don't happen becausde of bad timing of a GPU it happen because the GPU output and the audio run async.

when you are creating a custom resolution to fix frame drops repeats you are not making the clock better or accurate you are just lowering the drift between to clock the GPU and the audio clock that's it.

in cease of intel it seem that with an iGPU the GPU and the HDMI audio generator clock are one and the same so they don't drift.

[flossy_cake]

I tried that but I see in the block part but cannot get it to allow that high porch in the detailed resolutions above.

Indeed, it seems CRU will only allow such high resolutions in the detailed resolutions section of a DisplayID 1.3/2.0 block, which that last screenshot was from. Even in the CTA block it won't allow CTA's own timings for 4k (at least for me it won't).

And adding it when creating the block won't show in Nvidia or windows res options.

Did you delete any 24hz modes from all other blocks to avoid clashes? You may have one in the CTA block under "TV Resolutions" section. At least I did, and getting rid of it was what made all my custom mode(s) in my DisplayID 1.3 block finally appear in Windows display settings.

On my AMD GPU the procedure is different and AMD driver will only add my custom mode to Windows display settings if I create it in Radeon settings.


Maybe you can export yours and I can use it as a base?
Thanks!

Unfortunately CRU can't export a single mode or block, only the entire EDID and that would surely muck things up on your system so that you would probably get a black screen on reboot and have to boot windows in safe mode to fix it.

[flossy_cake]

when you are creating a custom resolution to fix frame drops repeats you are not making the clock better or accurate you are just lowering the drift between to clock the GPU and the audio clock that's it.

In most cases I agree, but for CTA's 1080p23 mode specifically, if the GPU only has 2 decimal places of pixel clock precision in its own driver code, the resulting refresh rate may be off by 0.001hz:


Pixel clock , resulting refresh rate
74.18Mhz , 23.977hz
74.17Mhz , 23.974hz


i.e it appears 23.977hz is the closest we can get to 23.976hz if we are limited to 2 decimal places of pixel clock precision, for CTA's 1080p23 mode.

It's entirely possible the driver can do more precision than 2 decimal place:


Use DisplayID to add resolutions greater than 4095x4095 or 655.35 MHz pixel clock. DisplayID 2.0 supports pixel clocks with three decimal places, but the driver or hardware might not support such precision.
https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?page=1

[Sunspark]

I wonder if it makes a difference or not at all in terms of pixel clock and refresh rate if one uses a displayport to hdmi adapter?

I'm actually using one because I felt the desktop looked a little better with the adapter than the port on the PC.

MadVR settings says my max pixel clock is 225 MHz when I connect to the monitor's HDMI port.. if I connect it to the DVI port it changes to 165.

[flossy_cake]

I wonder if it makes a difference or not at all in terms of pixel clock and refresh rate if one uses a displayport to hdmi adapter?
MadVR settings says my max pixel clock is 225 MHz when I connect to the monitor's HDMI port.. if I connect it to the DVI port it changes to 165.


Passive DisplayPort to HDMI adapters are limited to 165 MHz unless the driver is patched.
These DisplayPort to HDMI 2.0 active adapters support up to 600 MHz pixel clock (Amazon affiliate links):
These DisplayPort to HDMI 1.4 active adapters support up to 300 MHz pixel clock (Amazon affiliate links)
https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU?page=1



I've noticed there is also a "HDMI support" block in the CTA block which specifies a max pixel clock.

Also we can export the EDID from CRU to a txt file and paste it into www.edidreader.com to view some things which are not visible in CRU, such as the VIC numbers for supported modes which is useful for confirming your display uses CTA timings (except edidreader.com calls them by their old name CEA instead of CTA)

https://i.ibb.co/d5P0Hs3/vic.png

[Alexkral]

it nearly for sure is using 16 bit in the first place. if you want 32 bit you have to convert it your self because that's nearly for sure what that option does nothing more nothing less. so is there a feature that is been removed yes. does it lower bit deep most likely not...

Ah ok, I see what you mean. Agreed, that's probably what happens.

[lvqcl]

you really do not need full GUI to adjust few player settings and OSC is good for all playback related controls

from https://itsfoss.com/linux-market-share/:


Statcounter: Linux occupies 2.6% of the market share compared to 15.74% for macOS and 75.93% for Windows.
W3Schools: As of October 2022, Linux has a grip on 4% of the market share, compared to 9.8% of macOS and 70.4% of Windows.
Steam Survey: In terms of desktop gaming, Linux has a market share of 1.28% (Ubuntu, Arch, Manjaro as the top-three) when compared to 2.23% for macOS and 96.50% for Windows.
Statista (last updated on June 2022): The Linux desktop market share was 2.42% when compared to 14.64% for macOS, and 76.33% for Windows.


No ease-of-use -> no market share.

[glc650]

Oh well, more than you get out of madVR or anything else...
For good reason. MadVR has always been about playback quality. This hack for mpv is anything but.

It makes no sense to take DV streaming content and convert it (butcher it really) into SDR just for playback on a PC. Just obtain the HDR10 version (or SDR version for that matter) and run it through madVR (or mpv if you prefer). Or just use a device that is actually intended for DV playback.

[chrisssj2]

Guys stop... You won't get anywhere by complaining.

Hard truth is that madVR is abandonware and has been for a while. As much as I like this software, it's time to let go. Any development is in DTM area which directly contributes to madVR Envy and even this is progressing very slowly. Last madVR release was 30 Sep 2018 and since then there were only DTM test versions, which introduced regressions on its own (crop, smoothmotion and so on). madshi were teasing subscription model for madVR, but this never happened, clearly it is not a priority. And frankly without it, don't except any real development, bug fixes or new features, that were added to Envy like NLS. Obviously, there is no business incentive to port (enable, coz it is mostly the same codebase) them to madVR in current state.

Move on... it is not 2013 anymore.

You should be using mpv with gpu-next (libplacebo). It is easy to use, you really do not need full GUI to adjust few player settings and OSC is good for all playback related controls. Or JRiver if you prefer more.
What do you mean? mpv (w/ libplacebo) supports Dolby Vision, HLG, which madVR does not and doesn't look like it will anytime soon ...and uh upscaling is also supported. Notably libplacebo is superior to madVR it almost every way, more future complete, modern, open source and cross platform. It has better performance, better customizability, film grain synthesis on GPU, tonemapping, frame blending, all color managment stuff. You name it... I think only madVR feature that is missing is dynamic crop, but this is also little broken in recent madVR test build.

I will not convince you to switch, but to be honest your time would be better spent reporting mpv issues/requests, than complaining about lack of madVR development here.
WHere do you aquire gpu-next?