View Full Version : madVR - high quality video renderer (GPU assisted)
huhn
2nd March 2026, 09:39
it will be in sync cause it really doesn't care what madVR is doing.to do changes to the speed you need VRR.
with SM you actually get always no matter what double the source frame rate as long as that fids changed by the audio clocks speed.
and SM takes the speed of the audio where other algorithm do not matter only audio speed matters. and that's why it can change speed by syncing it to audio something a scaler can not do.
if you could slightly change speed with a scaler the A/V be so far off after just mins it would be utterly unwatched able.
and yes SM changes stuff and why couldn't that happen without cause VSYNC. to get difference you need to get tearing and if you have that you really messed up!
and if the "AI" says a vsync frame send to GPU for presentation can have a different "timing" based on the rendertime of "heavy" algorithm then the AI is not the only one imagination right now.
yes let GPU load change the frame duration on an HDMI signal what could possible go wrong the AI said that's possible... why couldn't that happen? cause a render pipeline is not blending. audio video just stays in sync using MAGIC.
why would older hardware have different smaller buffer? the presentation queue is a buffer we set that up not by hand.
the only difference you can get is an entire VSYNC and if that is "slightly" different i'm lost.
I have a problem with madVR. Every recent Nvidia driver (latest I tried without problems was 581.80) causes madvr to have washed out colors and raised black. As if gamma was suddenly incorrect? Adjusting gamme setting in madvr doesn't fix it however. I've been using madvr for over 10 years now on a variety of systems and never experienced that before. Reverting back to 581.80 fixed the problem but that's not a permanent solution.
Help??
Sunspark
7th March 2026, 05:07
Sounds like a PC 0-255/video 16-235 levels mismatch. Look in the madvr settings for display and see if changing that does anything.
clsid
7th March 2026, 15:54
Either a driver bug, or the display output settings in driver settings were changed to incorrect value.
Sounds like a PC 0-255/video 16-235 levels mismatch. Look in the madvr settings for display and see if changing that does anything.
That's what I tried first. Doesn't dix it. It's not just levels it looks like a gamma issue.
Something that madvr uses must have changed in the driver. Does nobody else have this problem?
Either a driver bug, or the display output settings in driver settings were changed to incorrect value.
Nothing changed, everything default. When reverting back to the old driver everything is fixed.
huhn
7th March 2026, 17:29
are you using anything related to DXVA2?
if yes stop that.
doffen
8th March 2026, 11:35
What about DXVA2 (copy-back)?
huhn
8th March 2026, 12:43
if you have that problem yes also that while that will be the last place i expect to fix that but still yes.
doffen
8th March 2026, 12:56
I haven't noticed that problem, the question was about avoiding anything related to DXVA2, and alternatives to DXVA2 copy-back.
My settings have been the same for years with no apparent need to change anything, and I'm still using windows 10 for media playback. Although I might have to update to windows 11 in the end.
huhn
8th March 2026, 13:27
if you see no issue DXVA2 copyback should be bit perfect. but that is something that can break with a GPU driver update
doffen
8th March 2026, 14:47
Perfect, thanks!
Sunspark
14th March 2026, 18:30
Where downscaling from 1080p to 768p is concerned on my Intel Broadwell igpu the DXVA downscaling option is noticeably superior--used with either copy-back or software decoding for best flexibility with other features.
Most of the madvr software downscaling algorithms are blurry or not quite to satisfaction. Some of them are manageable, but they are not worth the incredible hit to CPU/GPU load when they don't provide better results than DXVA in this (now-old) generation. Even SSIM 1D, 2D or Jinc are not better. Intel must have tuned it with polyphasic or something back then for specific viewing conditions since 32" 768p TVs were very common when this cpu came out. It almost looks 1080p! Testing with upscaling chroma and sending 1080p and having the TV downscale it to 768p looks bad so it really makes a difference if you're using 1:1 pixel mapping or not and the quality of the algorithm.
Different gpu manufacturers will have different outputs, and even different generations from the same manufacturer will have different output so this isn't a 'must-use this' recommendation. Just an observation on a specific hardware setup because too often people believe the most expensive setting will give the best result, and it's not true.
Most people upscale, and probably not that many downscale from 4K to 1440 or 1080, but worth testing if you do to see what your hardware comes with.
huhn
14th March 2026, 19:55
just make a screen shootshoot comparison...
https://www.mediafire.com/download/49ahiwm5ukfu6c9/7640_CO40_FM1-175pct_sRGB.jpg
Sunspark
14th March 2026, 22:38
Which site do you recommend for upload to?
huhn
15th March 2026, 01:00
https://slow.pics
Sunspark
15th March 2026, 16:28
huhn, the rgb jpg isn't compatible with the video processor. It expects yuv. I did try using ffmpeg to convert it into a yuv format file but it wouldn't display which might be a possible splitter issue.
Have to use video instead. Found an interesting collection of test clips here https://media.xiph.org/video/derf/ of note, some of them are 4:2:2 and 4:4:4 which is not common. You'll probably like that there's 1 HDR test clip in there too.
huhn
15th March 2026, 21:06
no jpg isn't rgb ever. doing lossy compression in RGB is just bad. in the past this was decoded by lavfilter and co and decoded as yuv that time is gone and we get the generate still image trash maybe that was ffdsow...
ffmpeg strikes again me.
ffmpeg.exe -f rawvideo -pix_fmt yuv420p -video_size 3744x5616 -i 420.y4m -c:v libx264 -x265-params crf=0 420.mkv
corruption
x264.exe --crf=0 --output 420.mkv 420.y4m
don't even tell me what is in there i got your back.
how was it created?
ffmpeg.exe -i sRGB.jpg -vf scale=out_color_matrix=bt709:flags=lanczos -pix_fmt yuv420p 420.y4m
can ffmpeg read there own y4m with the same pix_fmt no why would it?
so yeah i do not blame you that yuv from ffmepg did not work... will they ever confirm a one liner will not work no...
https://trac.ffmpeg.org/ticket/11568 i guess i could waste my time and add there "rare" case of doing 420 to this issue.
here you go: https://drive.google.com/file/d/1bY6lSZoGnHVGTpTRezv4q2z3_Z7Z2C5M/view?usp=sharing
Sunspark
16th March 2026, 20:38
Thanks huhn for the file, it works well. Quite the torture test it is. I have been taking screenshots and resolving bumps along the way. One of the ones I ran into was puzzlement as to why with the software algorithms everything seemed so incredibly oversharpened which was affecting the colours, but I figured out it was the checkboxes inside madvr for screenshots. So to be clear, for a neutral correct presentation, every single checkbox should be unchecked in the screenshot options, right?
huhn
16th March 2026, 20:49
just use alt print
matbezlima
18th March 2026, 05:39
What are the best settings to tonemap from HDR to SDR? I use the standard curve BT.2390 and 100 nits of target peak brightness. The version of MadVR I have is the latest stable one, I installed it today.
huhn
18th March 2026, 14:42
rule 12.
get the beta find someone that actual tone maps cause the "stable" has nothing todo with modern tone mapping.
matbezlima
19th March 2026, 05:53
rule 12.
get the beta find someone that actual tone maps cause the "stable" has nothing todo with modern tone mapping.
Ok, I'll get the latest beta. After that, what should I do to find all the best settings, custom curves, and so on? Please, don't be afraid of being as detailed as possible in your reply.
Another question: is there any video converter that allows one to reencode a video to SDR so that the output is what MadVR renders? I would love a program that is able to use madVR for the tonemapping from the HDR input to the SDR output file. I know that MadVR in itself is just a renderer for live playback.
VergiL
19th March 2026, 08:24
Hello, I recently installed my old GPU (RTX 3070) in another PC. This PC is a low-end setup with an IGPU in the Ryzen 4200G. Everything worked perfectly on the 1080p TV with the integrated GPU. Once I installed everything, there were some major inconsistencies in the CTRL+J menu, notably the V-Sync at 40.70, the maximum rendering stats being far too high, and even the display frequency being much too far from the reference, well beyond what I was getting with this card on another monitor. Any ideas what could be causing this? Because I've never encountered this issues on any of the PCs where I've installed MadVR...
https://i.ibb.co/fYMjps62/IMG-20260319-081636.jpg
huhn
19th March 2026, 13:27
hags. if your tv can do 120 do 120.
VergiL
19th March 2026, 15:50
Hags is disabled, pc is on windows 10. Tv is 1080. I have presentation glitches. The max stats rendering is much too far from average stats. Old Nvidia driver does not solve the problem. Vsync is activated.
Klaus1189
19th March 2026, 18:34
What exact tv?
VergiL
19th March 2026, 19:21
An old Samsung 48h6400.
Sunspark
19th March 2026, 19:40
@VergiL You are upscaling chroma at NGU Sharp (med). This is way too much load for very little return for just chroma. Change it to superxbr-150 if you still want to have something high that won't destroy your system as much.
It's interesting how it says 10-bit, even though the display and the file are both 8-bit. What decoder are you using? Change it to D3D11 (Automatic).
clsid
19th March 2026, 22:43
D3D11 (automatic/native) can give freezes and other stability issues. Use copy-back mode.
Reduce frames presented in advance to 3 or less.
huhn
19th March 2026, 23:36
rendering 10 bit when the GPU is set to 8 is usually not allowed by madVR and will results in massive banding. it is very odd this is working with nvidia. this works fine with AMD.
Sunspark
20th March 2026, 00:15
@huhn Sorry about the delay, here is the slowpics comparison.. I included the original, you'll probably want to uncheck it as it's throwing the canvas scaling off.
3 pics (I can do more) 1 is the original, 2 is DXVA from Broadwell, 3 is M-N for chroma, Jinc for luma (no AR for either). I did play around with other combinations to see but there wasn't a great deal of difference.
I would suggest zooming 400% or more, and looking at the diagonal pulley by the blue boat on the deck in the center, the dark planking in the shed on the right, the brickwork.
Seems like the DXVA has less ringing which is interesting. It's not perfect, but my argument here is that this is a great result for only 3-4% GPU load on this old system according to gpu-z. If I set it to Jinc AR/Jinc AR that load will go up to 50%. SSIM 1D 100 is less load, about 25%. (Clarification: the load is with a regular 4:2:0 1080p video, not the test image which is very heavy.)
https://slow.pics/c/4mZG0ryr
huhn
20th March 2026, 01:01
as expected massive aliasing massive artificing it creates giant rings on the tower similar to bilinear just much much weaker. there is no need to zoom at all.
this is a bad implementation of some kind of bicubic like all dxva downscaler. bicubic 60 AR will beat this hands down by not creating artifacts.
what is m-n for chroma? NN?
matbezlima
20th March 2026, 01:59
Ok, I'll get the latest beta. After that, what should I do to find all the best settings, custom curves, and so on? Please, don't be afraid of being as detailed as possible in your reply.
Another question: is there any video converter that allows one to reencode a video to SDR so that the output is what MadVR renders? I would love a program that is able to use madVR for the tonemapping from the HDR input to the SDR output file. I know that MadVR in itself is just a renderer for live playback.
Please, someone help me with this.
Sunspark
20th March 2026, 02:01
M-N is Mitchell-Netravali. Most of the chroma choices are fine, but it's luma for downscaling that presents an issue.. it's not ideal to make it too sharp because then the eye drags, and not ideal to make it too soft either because then the eye hunts. Or at least it does for me. The tower isn't really a fair test because most content will not be set up to create moire-like patterns.
The content I'm watching right now is a 70s TV show that was transferred to bluray at some point so it isn't digitally filmed like the new stuff is, so perhaps a bit of aliasing is good?
VergiL
20th March 2026, 04:52
D3D11 (automatic/native) can give freezes and other stability issues. Use copy-back mode.
Reduce frames presented in advance to 3 or less.
I use copy-back and i have already tested d3d11. I have also tested 1 to 3 frame presented in advance and it not resolved presentation glitches issues.
Sunspark
20th March 2026, 04:58
If it's only the 3 glitches when switching to or out of fullscreen, that is normal.
VergiL
20th March 2026, 06:43
I know that, the presentation glitches occur continuously during playback every 15-20 seconds, approximately.
Sunspark
20th March 2026, 06:56
Try seeing if you have better luck with the mpcvr renderer. It has good d3d11 support.
VergiL
20th March 2026, 07:07
This will be a last resort; the goal here is to use madvr like on all other PCs and understand what's wrong.
VergiL
20th March 2026, 12:55
Presentation glitches still here with superxbr for chroma. No presentation glitches when i'm not in fullscreen (windowed or exclusive)... Could it be that this only happens in fullscreen because I am then in d3d11 10bit and not in 8bit?
huhn
20th March 2026, 13:15
windowed is always 8 with madVR. you are throwing 10 bit at the GPU driver which is sending 8 bit limited this very very suboptimal and shouldn't even work maybe a new limitation int eh new version which breaks more stuff then it fixes. the next issue is that your clock deviation is catastrophic
VergiL
20th March 2026, 14:25
I force madvr in 8 bit in fullscreen but presentation glitches still here.. And for clock déviation i don't know what to do. Also if I disable image enhancement, there are no more presentation glitches.
Sunspark
20th March 2026, 17:00
Huhn, what do you mean catastrophic clock deviation? It's only a frame repeat every 13 minutes. I also have a composition rate mismatch with the display refresh rate and the only setting that made the two match was using D3D11 Exclusive, except I don't trust the number it is reporting there because sometimes it reports the same number as the other paths and other times not. It's just because of the compositor.
huhn
20th March 2026, 17:13
this deviation is so big the vsync is reported as 41.70 instead of 41.71ms.
13 mins is just terrible. the composition rate has nothing todo with deviation and is meaningless if it is off by a tiny bit if 59p get flat 60 HZ composition rate this should not create issues.
VergiL
20th March 2026, 20:38
And what could cause this?
Sunspark
20th March 2026, 20:39
Playing around some more with screenshots.. so, usage of linear light for downscaling is no good. Do not use it.
Here are two pics, the only change between the two is with one of them linear light is off and the other is on. You can very clearly see clicking with your mouse that the bricks get washed out as does the text "Cunera" on the ship.
This LL washing out shows on all the algorithms. It is not related to AR, I checked with AR turned off on both chroma and luma. The original jpeg photo does not have this washing out.
https://slow.pics/c/fKzX4qkW
-sTi-
20th March 2026, 20:53
Playing around some more with screenshots.. so, usage of linear light for downscaling is no good. Do not use it.
Here are two pics, the only change between the two is with one of them linear light is off and the other is on. You can very clearly see clicking with your mouse that the bricks get washed out as does the text "Cunera" on the ship.
This LL washing out shows on all the algorithms. It is not related to AR, I checked with AR turned off on both chroma and luma. The original jpeg photo does not have this washing out.
https://slow.pics/c/fKzX4qkW
What you perceive as bug ("washing out") is actually a feature (preserving small highlights) :)
https://www.ericbrasseur.org/gamma.html?i=1
huhn
20th March 2026, 21:01
LL downscaling while it often looks not as good it is just to sharp is also called correct downscaling.
the math behind that makes a lot of sense it fixes which pixel are seen as more important by removing the gamma first.
this was also tried with upscaling but discarded later there is still sigmoidal light or something like that where gamma of ~1.6 is used
Sunspark
20th March 2026, 21:19
Very interesting! It's tougher to test this with the original without scaling.. so what I am doing now, I have opened the original image at 100% scaling, it is large. And the screenshots I took I can position them next to the original image, changed the browser zoom to 400% to make it a bit easier to see, click back and forth to see which version looks more like the non-scaled image.
On the windmill, the shadow at the top of the windmill's arched door is more visible without LL just like the original non-scaled image.. and at the top of the windmill where there is the curved scrollwork below the date, with LL the green shrinks in width, with LL off, the green expands in width and looks more like the original non-scaled image. I don't think the width of the green should be changing.
Another place you can see sizes changing is the chimney cover on the house's right chimney, one image will shrink it, the other will have it a more normal looking size.
huhn
20th March 2026, 21:26
your browser will just use bilinear.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.