madVR - high quality video renderer (GPU assisted)

[ryrynz]

Originally Posted by yok833

Which one should we use for the best quality?

Madshi said the opencl dithering has a lower noise floor so that should produce better quality. Haven't looked at it yet so the difference might not be terribly noticeable and given the huge increase in gpu usage it requires may not be worth enabling unless you have a good gpu. As for lav I would recommend just keeping the default random dithering. Doesn't hurt to test these out and look at them yourself and decide what suits your tastes.

[nevcairiel]

If you use madVR, LAV should never need to dither anyway, so the option in LAV is really unimportant.

[SecurityBunny]

Figured I'd report my findings to help narrow down bugs.

Using MadVR 0.87.1, according to control panel. (AKA 0.87f)
MPC-HC 1.7.1.383 (Latest nightly.)

Nvidia GTX 780 graphics card. Quadro Driver 334.67.
Intel 3770k @ 4.2 GHZ

Tested with lav hardware acceleration 'none' and 'dxva2 (native)'. Tested in windowed mode.

No 'trade quality for performance' options checked with smooth motion enabled, black screen.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion enabled, flashing screen between picture and black until completely black.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion disabled, video plays back normally.

MadVR settings.

Everything under processing tab - disabled.
Chroma upscaling - Jinc 3 taps w/ anti-ringing.
Image doubling - all settings disabled.
Image upscaling - Jinc 3 taps w/ anti-ringing.
Image downscaling - Catmull-Rom w/ anti-ringing & linear light.
Rendering general settings - only fullscreen exclusive mode and separate device for presentation checked. CPU queue size: 16, GPU queue size: 8.
Default windowed and exclusive mode settings.

[michkrol]

Originally Posted by truexfan81

if i assign kb shortcuts i can can toggle between them, however it would be nice if the auto selection worked.

It works for me (and probably others). I have 4 settings groups and all get selected correctly, but I don't have any rules with fps checks.

Does madVR show correct fps in OSD (CTRL+J)? Have you tried using some other numerical values checks, like (scrHeight>768) or any other, just to be sure it's not related to incorrect fps detection? Maybe you need (deintFps==60)? Or try (srcFps>59) to eliminate problems with non-integer values, like 59,94 or 60,6?

Can you see a green tick icon on the right just over the auto selection rules? It's a built-in validator for the scripts, shows either a green tick (ok) or red triangle icon(invalid script).

[truexfan81]

Originally Posted by michkrol

It works for me (and probably others). I have 4 settings groups and all get selected correctly, but I don't have any rules with fps checks.

Does madVR show correct fps in OSD (CTRL+J)? Have you tried using some other numerical values checks, like (scrHeight>768) or any other, just to be sure it's not related to incorrect fps detection? Maybe you need (deintFps==60)? Or try (srcFps>59) to eliminate problems with non-integer values, like 59,94 or 60,6?

Can you see a green tick icon on the right just over the auto selection rules? It's a built-in validator for the scripts, shows either a green tick (ok) or red triangle icon(invalid script).

thanks (srcFps>59) got it

[TheProfileth]

Have you considered adding in a upscale/downscale gaussian resize kernel, it just happens to my favorite blurring kernel so I thought I would ask.

[truexfan81]

ok i give up and am looking for help with the scripting, if the source is 23.976, 25. or 29.97p i want to use Profile 1 if the source is 29.97i or 50p or 59.94p i want it to use Profile 2

a huge thanks to anyone who can make this work

[6233638]

Originally Posted by truexfan81

ok i give up and am looking for help with the scripting, if the source is 23.976, 25. or 29.97p i want to use Profile 1 if the source is 29.97i or 50p or 59.94p i want it to use Profile 2

a huge thanks to anyone who can make this work

I'm not 100% clear on your requirements, but the simplest code to do what I think you want would be:

if (srcFps<=30) and (!srcInterlaced)   "Profile 1"
else                                   "Profile 2"

[truexfan81]

Originally Posted by 6233638

I'm not 100% clear on your requirements, but the simplest code to do what I think you want would be:

if (srcFps<=30) and (!srcInterlaced)   "Profile 1"
else                                   "Profile 2"

that works

oh and i am still noticing a performance issue with 87x i cannot do 1080i at all render queue stays empty.

if i revert back to 0.86 deband14 the same 1080i video plays perfect, render queue stays full

[za222]

Originally Posted by madshi

Known problem. Already fixed in a test build.

I had the same problem in 0.87.

But for me the problem is not fixed in test build 0.87f.
Instead, when opening a video file the whole screen flickers very shortly, and then i get a *green* video screen with some weird artifacts on the top-left:
http://i.imgur.com/CstoDBp.png

Windows 7 x64 / MPC-HC x86 / LAV / Geforce 8800GTS

[AngelGraves13]

Playback freezes when dragging the window to another monitor or to the TV. Dragging it back does not fix it.

MPC-BE and latest 0.87f. all 0.87 versions do this...going back to old version.

Also, image doubling freezes image too.

[ryrynz]

Have had this happen on the c as as f builds, bringing up the OSD and then using CTRL-J again doesn't make the OSD disappear on the black bars of the window (4:3 image on 6:10 screen)
Could be the newer Intel drivers though, perhaps take a look when you test the old 'separate device' issue along with the blinking on entry exit of fullscreen I mentioned with the .3383 drivers.

[pie1394]

Test 0.87f build + MPC-BE 1.3.0.3 + XySubFilter 3.1.0.546 + GeForce driver 320.49 and 332.32 with IonLE(GF9300) on Win7 x64 SP1. The most ordinatory options available in 0.86.x build + debanding option work fine except following:

1. P10 contents shows nothing on the video window.
2. SmoothMotion option causes black rectangle box on ASS sub-title text. (this time it always presents no matter what option or configuration reset operation...)
3. Chroma NNEDI3 scaling option causes GREENish video
4. Any other option which requires OpenCL causes BSOD... @_@

[DragonQ]

Originally Posted by ryrynz

Have had this happen on the c as as f builds, bringing up the OSD and then using CTRL-J again doesn't make the OSD disappear on the black bars of the window (4:3 image on 6:10 screen)
Could be the newer Intel drivers though, perhaps take a look when you test the old 'separate device' issue along with the blinking on entry exit of fullscreen I mentioned with the .3383 drivers.

I'm sure that's the driver and/or MPC-HC because I've seen it well before MadVR 0.87 came out.

[G_M_C]

Is is just me, and am i wrong when i notice that most reports here are of people that are using an Nvidia card + geforce drivers ?

[huhn]

Originally Posted by G_M_C

Is is just me, and am i wrong when i notice that most reports here are of people that are using an Nvidia card + geforce drivers ?

opencl plus nvdia is not working and well known by madshi.

using exclusive fullscreen and switching the file with page up or mouse button 4/5 in mpc-hc frezzes the image but sound is still working like using opencl with nvidia but this happens with amd and no opencl options! it is still possible to stop playback with pressing the left mouse button but to close or leave the frozen image alt f4 is needed.

a vfr file runs almost fine with 86.9 6.5 ms but is runs very very bad with 87f 11 ms i can use spline3 ar with 86.9 but 87f doesn't work with bilinear. i don't think this is related to the "high" cpu usage from the debanding+ builds.

amd 6770 13.12
phenom 2 x4 955

[sdancer75]

Originally Posted by madshi

Look at "madVR\developers\mvrInterfaces.h". If you know how to use e.g. VMR9, using madVR is not that much different. madVR supports many of the VMR9 interfaces, plus all those private ones listed in the mentioned header file. You can also look at e.g. MPC-HC or MPC-BE, which are open source projects supporting madVR.

Hi,

1) IVideoWindow Interface does not support windowless mode and the interface
IVMRWindowlessControl is not supported. How to make madVR windowless ?

2) 3RD PARTY SOFTWARE RESTRICTIONS : The software "madVR" may not be distributed together with any 3rd party
software without the written consent of the "madVR" author.

So, do I have to pay license fees ?

Regards,

[madshi]

Originally Posted by cyberbeing

And yes, the CPU load regression began in the very first deband test build. CPU load in 0.87.0 is slightly higher (+0.4%), but the significant doubling in madVR CPU usage started with this first deband test build.

Ok, can you please retest with the 87g build? If the problem is still there, please try the "madVR - cyber.ax" in the 87g rar file. Does that fix the problem? If not, how can I reproduce the problem? I've tested with DXVA2 decoding here with my AMD card, to avoid having the software decoder screw CPU consumption measurements up, and I'm getting 0.7% CPU usage in MPC-HC, both with v0.86.11 and v0.87f.

Originally Posted by DragonQ

Nope, all the new features, including debanding, are definitely off.

Ok. Can you please try 87g? If the problem still occurs, please try the "madVR - dithermod.ax" instead. Does that fix the problem? If not try setting the display to 7bit instead of 8bit. That will switch to a simpler dithering method. Does that fix the problem? If not, please try turning dithering completely off for both v0.86.11 and v0.87.0g and compare whether that makes them perform identically or not. If not, at least I'll know that the problem is not caused by the changes in the dithering pixel shader...

Originally Posted by noee

Clocked the chip to 3.5Ghz (NB @ 2.4Ghz) and everything works great, no drops, full queues. Back to bone stock BIOS (2.6Ghz), no joy.

At stock, when upload queue goes empty, CPU is at ~55-60% per ProcessExplorer. On .86, it hovers ~34%, same video, same settings.

Ok. Can you please try 87g with debanding turned *off*? Does that fix the uploading problem for you? If so, does turning debanding on - and choosing a higher setting for fades bring the problem back?

Originally Posted by DarkSpace

Thanks for the explanation. The unwanted shift is exactly why I was asking... I'm curious: What kind of interpolation pass are you running?

Lanczos3AR in only one dimension (Y, IIRC) to shift the image 0.5 pixels.

Originally Posted by djfred93

ccc 13.12

Does 87g fix the problem? Make sure you disable all OpenCL related options, just to be safe...

Originally Posted by livache

.87 with smooth motion turned on returns black image when playing videos with mod2 height in normal window (100% - unresized). After resizing the window or turning to full screen, the image appears. > mod2 seem to play fine with smooth motion on.
GPU: GTX560Ti.

Originally Posted by Q-the-STORM

also, some files give a black screen, until i resize them (doesn't matter if up or down)... what these files have in common is that they are 1280x718 with DAR set to 16:9 according to mediainfo...
so it's black until i resize the window, but when I resize the window back to the original size, the frame is black again...
1280x720 content is working fine, so there might to be an issue with DAR... but 960x720 content with DAR set to 16:9 is also working fine, so it's not a universal problem with DAR...

9MB sample file

//just disabled smooth motion and there is no more black frame with the 1280x718 file.... it might have nothing to do with DAR... might be the mod2 problem livache is talking about...

Thanks guys, yes, same problem. Was a bug in the modified frame cropping logic, in combination with Smooth Motion FRC. Should be fixed in 87g.

Originally Posted by Q-the-STORM

there is a issue with deinterlacing... when I play 1080i MBAFF interlaced content or telecined NTSC DVDs (basically content that has some kind of interlacing), I get a black screen when having deinterlacing enabled (if in doubt, deactivate deinterlacing)... works fine when I disable deinterlacing in madVR...

Does it still occur with 87g? If so, can I have a small sample, just to make sure I'm testing with the same stuff? This is with video mode deinterlacing, not forced film mode, right? Does the problem also occur with forced film mode? Does it have anything to do with Smooth Motion FRC?

Originally Posted by noee

madshi, to follow up on your question regarding the impact of "use OpenCL to process DXVA NV12 surfaces...", yes, this has quite an impact here on my setup (HD6570). With that option enabled, I get dropped and repeated frames, video is not quite a slideshow, but close. All is well with that option disabled (default).

Ok, interesting. Seems the 6570 doesn't like this option. It has pretty much zero impact on my 7770.

Originally Posted by Deim0s

Except OpenCL, stopped working algorithms "image downscaling" (...or something else).
While playing content UHD (4k):
in windowed mode slideshow (madVR output),
when switching to full screen - black screen

In version 0.86.11 worked perfectly.

latest nightly MPC-HC, latest LAV Filters
Win7 32bit, i7-2600K, ASUS GTX770 2GB, ASUS VG278 27" 120Hz

Does the problem still occur with the 87g test build, if you disable all OpenCL related options and if you disable debanding? (Make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled.)

Originally Posted by kasper93

I have a problem with DXVA deinterlacing. "DXVA processing fail" when I open interlaced content. Log from latest test build https://dl.dropboxusercontent.com/u/16282309/madVR/madVR_deint.7z

I can manually enable deinterlacing later, but initially it fails.

Does it still occur with 87g? Which GPU, which OS?

Originally Posted by truexfan81

even a simple rule such as:
if (srcFps == 60) "Profile 2" else "Profile 1" fails to use the correct profile

The FPS information is coming from the decoder in a weird format. After convertion to something we humans can make sense of, it's not perfectly exact, anymore. Furthermore, it's likely to be around 59.940 and not 60.000. Your check "if (srcFps == 60)" would only work as intended if the FPS information coming from the decoder were exactly 60.000000000, without the slighest deviation. That's not going to happen. So it's better to use ">" or "<" instead of "==". E.g. use "if (srcFps > 59)" to give it a bit of safety margin.

Originally Posted by Nachbar

Same here. All i did was copy the new madvr over the previous version. I tried the uninstall and install.bat after mpc-hc crashed and that did not fix it. Weird thing is even though it will display a window that mpc-hc crashed unexpectedly the video still plays in the background fine.

My system: Intel Core i5 3570k, Nvidia Geforce 560 Ti, Windows 7, MPC-HC 1.7.1, madvr 1.8.8.1 (also tried 1.8.8.0 since it recently updated but the problem still occurs), LAV 60.1, xy-vsfilter 3.0.0.211

Does it still happen with 87g? Even with all OpenCL related options turned off ("use random dithering..." turned *on* in the "trade quality" section)?

Originally Posted by SecurityBunny

Figured I'd report my findings to help narrow down bugs.

Using MadVR 0.87.1, according to control panel. (AKA 0.87f)
MPC-HC 1.7.1.383 (Latest nightly.)

Nvidia GTX 780 graphics card. Quadro Driver 334.67.
Intel 3770k @ 4.2 GHZ

Tested with lav hardware acceleration 'none' and 'dxva2 (native)'. Tested in windowed mode.

No 'trade quality for performance' options checked with smooth motion enabled, black screen.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion enabled, flashing screen between picture and black until completely black.

Only 'use random dithering instead of OpenCL error diffusion' under 'trade quality for performance' checked with smooth motion disabled, video plays back normally.

Can you please retest with 87g?

Originally Posted by TheProfileth

Have you considered adding in a upscale/downscale gaussian resize kernel, it just happens to my favorite blurring kernel so I thought I would ask.

Do you really want to blur things for realtime playback? Why?

Originally Posted by za222

I had the same problem in 0.87.

But for me the problem is not fixed in test build 0.87f.
Instead, when opening a video file the whole screen flickers very shortly, and then i get a *green* video screen with some weird artifacts on the top-left:
http://i.imgur.com/CstoDBp.png

Windows 7 x64 / MPC-HC x86 / LAV / Geforce 8800GTS

Weird. Does this still happen with 87g? If so, does it happen with *all* videos or just with some? Is it related to Smooth Motion FRC or not?

Originally Posted by AngelGraves13

Playback freezes when dragging the window to another monitor or to the TV. Dragging it back does not fix it.

MPC-BE and latest 0.87f. all 0.87 versions do this...going back to old version.

Does it still happen with 87g?

Originally Posted by ryrynz

Have had this happen on the c as as f builds, bringing up the OSD and then using CTRL-J again doesn't make the OSD disappear on the black bars of the window (4:3 image on 6:10 screen)

This is exactly the Intel driver problem everyone is talking about. The "BorderColor" tweak mentioned in the v0.87.0 release notes should fix this.

Originally Posted by pie1394

Test 0.87f build + MPC-BE 1.3.0.3 + XySubFilter 3.1.0.546 + GeForce driver 320.49 and 332.32 with IonLE(GF9300) on Win7 x64 SP1. The most ordinatory options available in 0.86.x build + debanding option work fine except following:

1. P10 contents shows nothing on the video window.
2. SmoothMotion option causes black rectangle box on ASS sub-title text. (this time it always presents no matter what option or configuration reset operation...)
3. Chroma NNEDI3 scaling option causes GREENish video
4. Any other option which requires OpenCL causes BSOD... @_@

OpenCL not working is currently to be expected, sadly. Will work on that later. BSOD is very very bad, of course. I kind of hate NVidia right now...

P10 and SmoothMotion making problems: Does this still occur with 87g? Even with debanding turned off?

Originally Posted by G_M_C

Is is just me, and am i wrong when i notice that most reports here are of people that are using an Nvidia card + geforce drivers ?

It's not just you. It's the pretty bad NVidia OpenCL support which is causing a lot of trouble. For now I'd advise all NVidia users to stay away from the new OpenCL options, until I found some time to investigate a proper workaround. Some problems are not related to OpenCL/NVidia, though.

Originally Posted by huhn

using exclusive fullscreen and switching the file with page up or mouse button 4/5 in mpc-hc frezzes the image but sound is still working like using opencl with nvidia but this happens with amd and no opencl options! it is still possible to stop playback with pressing the left mouse button but to close or leave the frozen image alt f4 is needed.

a vfr file runs almost fine with 86.9 6.5 ms but is runs very very bad with 87f 11 ms i can use spline3 ar with 86.9 but 87f doesn't work with bilinear. i don't think this is related to the "high" cpu usage from the debanding+ builds.

Does this still happen with 87g, even with debanding disabled? If so, please try the "madVR - dithermod.ax" file with the other related things I suggested somewhere above. Thanks.

Originally Posted by sdancer75

1) IVideoWindow Interface does not support windowless mode and the interface
IVMRWindowlessControl is not supported. How to make madVR windowless ?

madVR currently does not support windowless, unfortunately. This is planned for a future version. But not any time soon.

Originally Posted by sdancer75

2) 3RD PARTY SOFTWARE RESTRICTIONS : The software "madVR" may not be distributed together with any 3rd party
software without the written consent of the "madVR" author.

So, do I have to pay license fees ?

Don't stop reading there. Read to the end of the "3RD PARTY SOFTWARE RESTRICTIONS" section.

-------

So here's 87g:

http://madshi.net/madVR87g.rar

NVidia users, please stay away from all OpenCL related options for now. Also make sure the "use random dithering..." option in the "trade quality..." section is checked/enabled. I'll look into making OpenCL work for NVidia once all the other problems (introduced by v0.87) are solved.

[PixelH8]

Nvidia user here. Let me start by saying that I do NOT have any black screen issues when using the OpenCL error diffusion instead of random dithering. Instead, I get swapped red and blue channels.
This happens on two systems I've tried the new main 0.87 build on.
The primary system has a GTX 560 Ti w/driver 306.97
The second system has a GTX 460 w/driver 310.90
Both are running Windows 7 64-bit with MPC-HC 1.7.1.220, LAV filters 0.59.1 and XySubFilter 3.1.0.546.

The swapped colors are easy to correct, as I simply use the ffdshow raw video filter's built-in avisynth module and add the line: "SwapUV" and voila, problem solved.
This was even easier since I was already using the ffdshow raw avisynth filter to decimate 29.97 fps video to 23.976 fps on-the-fly to eliminate that annoying judder on some old videos.

On average, toggling OpenCL error diffusion adds 10% GPU load to whatever the base load is. Though for me that's not an issue as the GTX 460 never reaches even 50% load with all the trade-quality-for-performance options disabled.

Never tried any of the NNEDI3 stuff as I see no need. Same with smooth motion conversion. That said, I really like the new deband filters. They work well.

[madshi]

Originally Posted by PixelH8

Nvidia user here. Let me start by saying that I do NOT have any black screen issues when using the OpenCL error diffusion instead of random dithering. Instead, I get swapped red and blue channels.
This happens on two systems I've tried the new main 0.87 build on.
The primary system has a GTX 560 Ti w/driver 306.97
The second system has a GTX 460 w/driver 310.90
Both are running Windows 7 64-bit with MPC-HC 1.7.1.220, LAV filters 0.59.1 and XySubFilter 3.1.0.546.

The swapped colors are easy to correct, as I simply use the ffdshow raw video filter's built-in avisynth module and add the line: "SwapUV" and voila, problem solved.
This was even easier since I was already using the ffdshow raw avisynth filter to decimate 29.97 fps video to 23.976 fps on-the-fly to eliminate that annoying judder on some old videos.

On average, toggling OpenCL error diffusion adds 10% GPU load to whatever the base load is. Though for me that's not an issue as the GTX 460 never reaches even 50% load with all the trade-quality-for-performance options disabled.

Never tried any of the NNEDI3 stuff as I see no need. Same with smooth motion conversion. That said, I really like the new deband filters. They work well.

Now this is weird. Why is it working for you - and for me, too. But not for everyone else? I'm quite confused. BTW, I've already fixed the swapped color channels in the latest test build...