madVR - high quality video renderer (GPU assisted)

[brazen1]

Any chance of adding toggle for RRN (reduce random noise) hotkey?

[huhn]

denoise toggle.

[Siso]

Originally Posted by Warner306

What do you mean by delays one frame? NGU will shift a pixel or two but frames should be rendered the same. Maybe it is taking a second longer at playback start to fill the queues?

I have enabled "delay playback start until render queue is full", and it just delays 1 frame, it says it in the OSD stats. This happens when using NGU only, I have no idea why is that, no other problems with other chroma scallers...The delayed frame is somewhere around 10-15 min of the movie.

[huhn]

delaying a frame when starting playback is not a problem.

[Siso]

Originally Posted by huhn

delaying a frame when starting playback is not a problem.

I always reset the frames counter when I go into fullscreen, this happens 10-15 min after playback.

[brazen1]

Thank you huhn. I see you don't need to toggle on/off. 'Increase' essentially turns on and 'Decrease' turns it off.... and all 10 steps in between. NICE!

[Seedmanc]

Is there a way for madvr to automatically disable GSYNC during playback like it does with GPU gamma ramps? Disabling it manually every time is annoying and with it enabled at the same time with smooth motion it goes bonkers.

[Georgel]

madVR is out of updating?

I am getting freakouts and crashes with madVR has crashed every ten minutes watching anime upscaled from FHD to 4K. Tried multiple file types, multiple encodes, and I tried keeping the algorithms very friendly. Not sure why it happens.

This is what my crash dump thingy looks like

lavvideo!CLAVPixFmtConverter::convert_yuv420_px1x_le+0xb7
lavvideo!CLAVPixFmtConverter::Convert+0x19e
lavvideo!CLAVVideo:eliverToRenderer+0x7a5
lavvideo!CLAVVideo:eliver+0x1e7
lavvideo!CDecAvcodec:ecodePacket+0x6d0
lavvideo!CDecAvcodec:ecode+0x192
lavvideo!CDecBase:ecode+0x113
lavvideo!CDecodeManager:ecode+0x53
lavvideo!CLAVVideo::Receive+0x115
lavvideo!CTransformInputPin::Receive+0x59
lavvideo!CDeCSSTransformInputPin::Receive+0x1b
lavsplitter!CBaseOutputPin:eliver+0x1c
lavsplitter!CLAVOutputPin:eliverPacket+0x4d3
lavsplitter!CLAVOutputPin::ThreadProc+0x181
lavsplitter!CAMThread::InitialThreadProc+0x36
lavsplitter!strcspn+0x9d
kernel32!BaseThreadInitThunk+0x24
ntdll!__RtlUserThreadStart+0x2f
ntdll!_RtlUserThreadStart+0x1b

[Asmodian]

The last update was less than a month ago! How often do you expect updates from a free project with one developer working in his spare time?

Sorry, no idea why you are getting crashes but what player are you using? Do you have any non-default values set in LAV Video?

[ryrynz]

Originally Posted by Georgel

I am getting freakouts and crashes with madVR has crashed every ten minutes watching anime upscaled from FHD to 4K.

Assuming it's related to MadVR? Try another renderer.

[truexfan81]

anyone else get a huge madvr performance drop after upgrading to the windows 10 1803 build? i'm running a ryzen7 1700 with 16GB ram, and an evga 1050ti ftw, and I cannot get the present queue to fill, I've turned off everything except smooth motion, and set the scalers to spline36AR. its showing 0.21ms present time for a 392p30 video. decoder queue, and upload queue are both full, render queue is at 1-2/7 present queue is at 0-3/3. monitor is running at native 1080p60

[cyberscott]

Originally Posted by truexfan81

anyone else get a huge madvr performance drop after upgrading to the windows 10 1803 build? i'm running a ryzen7 1700 with 16GB ram, and an evga 1050ti ftw, and I cannot get the present queue to fill, I've turned off everything except smooth motion, and set the scalers to spline36AR. its showing 0.21ms present time for a 392p30 video. decoder queue, and upload queue are both full, render queue is at 1-2/7 present queue is at 0-3/3. monitor is running at native 1080p60

Multiple individuals, including me have this issue, in varying degrees.
If you use the "search this thread" feature at the top of this page for "windows 10 1803" You'll have at least two pages of information to go through.
No full fix for those of us affected beyond rolling back to the previous Windows version. I've reduced a few setting and also set my render queue (GPU) to 7 and my present queue to 6 as they will not fill up beyond that. I have everything working with the slight settings reduction in quality and with the queues set to what I mentioned.
You will just have to adjust settings while watching a video until you can find something that will work with your hardware to fill up the reduced queues. For me, dropping settngs in "artifact removal" helped me.
I'm sure madshi will be able to come up with solutions once he can allocate some time for madVR. He has a real job beyond madVR and committments and bills to pay.

[Betroz]

Originally Posted by truexfan81

anyone else get a huge madvr performance drop after upgrading to the windows 10 1803 build? i'm running a ryzen7 1700 with 16GB ram, and an evga 1050ti ftw, and I cannot get the present queue to fill, I've turned off everything except smooth motion, and set the scalers to spline36AR. its showing 0.21ms present time for a 392p30 video. decoder queue, and upload queue are both full, render queue is at 1-2/7 present queue is at 0-3/3. monitor is running at native 1080p60

I too have this issue with the queues not filling up and dropping frames. My fix was to remove Windows 10 and install Windows 8.1. Now MadVr works as intended. If Madshi will be able to fix the problem, then maybe I'll switch back to Win10 later. But the thing is that the next big update to Win10 things can brake again...! Win8.1 will stay the same.

[Warner306]

So many lines of code have been written into madVR over the years. It could be a real mess if Microsoft has made significant changes to way software interacts with the OS. The fact it is not happening to everyone is quite strange.

Have you tried wiping the drivers and reinstalling? The driver upgrades sometimes don't always go as planned. I'm not sure if Windows forced a driver upgrade or not.

[Betroz]

Originally Posted by Warner306

Have you tried wiping the drivers and reinstalling? The driver upgrades sometimes don't always go as planned. I'm not sure if Windows forced a driver upgrade or not.

I did a clean install of Win10 1803, and tried 3 different nVidia drivers (after a DDU cleanup too). I had no problems with the 1709 build of Win10, so yes something changed with 1803. I even tried an older build of MadVr with NNEDI3 128 settings, and that worked fine under Win10 1803.

Now I'm using the newest version av MadVr under Win 8.1 and NGU is working as it should. Besides Madshi have recommended Win 8.1 several times in the past, so now I see why. An ever changing OS like Win10 is not allways the best thing it seams.

[zaemon]

Same here. Went back to Win 8.1 since custom modes were not working and I had pretty bad repeated frames. Even though custom modes are not working either, I get excellent results now (1 frame repeated every hour). I’m running the latest drivers for my GTX.

[foozoor]

Time to switch to D3D11/12 and MediaFoundation!

[huhn]

feel free to rewrite everything.
maybe start with decoders and don't forget the media player.

[el Filou]

I tested with Windows 10 v1803 and I encountered the queue length issue too.
Here's a folder with OSD and GPU-Z screenshots:

https://drive.google.com/open?id=13G...KrJ3qhpZIbywhI

Test system: Core i5-2520M (HD Graphics 3000 12 EUs @ 1300 MHz, 35W TDP); latest versions of Windows, Intel drivers, MPC-HC, LAV, and madVR; all software 64-bit; graphics power plan set to Maximum Performance and verified using GPU-Z render test (1300 MHz, 9,6W @ 100% GPU).
EDIT: screenshots taken with DXVA2 Native decoding, as that's what gives the best performance with Intel iGPUs.
EDIT2: I never noticed any issue like this with Windows 1709 obviously, but I can't go back to that version to test more thoroughly as it's an Insider install, and I have no desire to test 1803 on my 'production' PCs.

Observation: the problem isn't restricted to NGU, actually all scaling algorithms can fail to fill up the render queue but they do it at different queue lengths depending on their complexity.

- NGU @ render queue length 8: render time is 75% of the frame time which should be OK, GPU is at 71% load but only at half clock although not limited by TDP. Render queue 1-3/8, and madVR drops 13 frames on ~45 seconds of playback.

- NGU @ Q4: now fills up a bit more at 2-3/4, and no frames are dropped anymore. Frame render time and GPU clock/load are identical.

- Bilateral Sharp: this the lower complexity scaler closest to NGU Low, and @ Q9 it can fill up the queue but it can't @ Q16 even though once again the GPU isn't even at 1/3 its tested maximum capability.

- Jinc: uses 30% less power, can fill the queue @ Q16, cannot @ Q24.

- Bicubic: can fill the queue even @ Q24.

Things I tried:
- Disabled Windows' Game Mode
- Disabled Windows' Full Screen Optimisatons for MPC-HC
- Unchecked "delay playback start until render queue is full"
- Used D3D9 instead of D3D11
- Tried software and QuickSync decoding
but none of that did have any impact.

GPU power definitely isn't the issue, because switching to higher complexity scalers makes it reach higher clocks successfully.

Only idea: could it be a VRAM issue? I noticed all the scenarios that don't drop frames used ~165-180 MB of VRAM in this test, i.e. NGU at QL 2-3 is using the same amount of VRAM as Bicubic at QL 23-24 but nothing that would need more than that amount - like NGU at higher queue lengths - will fill up the queue.
Could memory allocation be the source of the problem?

Cheers.

[Betroz]

Originally Posted by el Filou

Observation: the problem isn't restricted to NGU, actually all scaling algorithms can fail to fill up the render queue but they do it at different queue lengths depending on their complexity.

Well if you test an older version of MadVr, you'll see that NNEDI3 works so that the queues does fill up with that.