madVR - high quality video renderer (GPU assisted)

[cyberbeing]

CPU load with 0.87e is now the same as 0.87.0 & 0.87a in my previous post, but it's still more than twice that of 0.86.11.

This CPU load regression exists in all builds starting with the first madVR deband test build released on 9/30/2013. There is no change whether debanding is enabled or disabled, so it must be some other change you made starting with that build.

[DragonQ]

Here's a new test build:

http://madshi.net/madVR87e.rar

I hope that CPU and GPU performance is mostly back to v.86.11 levels (maybe GPU performance could be slightly lower due to modified dithering logic). Can anybody confirm?

There's a new option in the rendering settings now, allowing you to enable/disable OpenCL processing of DXVA NV12 surfaces for AMD and Intel GPUs. It's disabled by default now. Please check whether this option helps or harms with your GPU (AMD/Intel only) and report. Thanks.

OpenCL will still not work with newer NVidia GPUs. Need a new debug log for this with error diffusion enabled.
Hmm. Performance still seems worse than 0.86.x for me. GPU usage is 95-100% and the queues are essentially empty.

Disabling "Use random dithering instead of OpenCL error diffusion" drops GPU usage to ~85% but the queues are still generally empty. Using 10-bit chroma and image buffers gets me perfect playback but I've never had to use these options before.

The "Use OpenCL to process DXVA NV12 surfaces" doesn't seem to make any difference to GPU or CPU usage or the queues for me. By the way, ticking/unticking that option doesn't trigger the "Apply" button being enabled, unlike the other options. I never tried the deband builds so I don't know if those had the problem or not.

[James Freeman]

Here is another Log with 87.1 (87e) & GTX660:
https://www.mediafire.com/?kc6y1y9253f4gva

[michkrol]

You're right. I thought adding the "renderQueue" field would be a clever idea, but it changes too often for it to make sense. So I've completely removed it now.
Thanks for looking into this.

There's a new option in the rendering settings now, allowing you to enable/disable OpenCL processing of DXVA NV12 surfaces for AMD and Intel GPUs. It's disabled by default now. Please check whether this option helps or harms with your GPU (AMD/Intel only) and report. Thanks.
I'm unable to save this option. The Apply button doesn't get activated, clicking OK does nothing.

In the latest test build, I have the same issues:
if (srcInterlaced) && (!filmMode) "Don't Use OpenCL"
else "Use OpenCL"
works just fine (thanks michkrol!), but
if (srcInterlaced && !filmMode) "Don't Use OpenCL"
else "Use OpenCL"
doesn't work. If you want me to enter this into the bug tracker, please tell me so.

You're welcome. It's all in the documantationEach value comparison must be placed in brackets
So it shouldn't work the way you want it to. The syntax may seem familiar (java, C#, etc.), but is not exactly the same.

[noee]

There's a new option in the rendering settings now, allowing you to enable/disable OpenCL processing of DXVA NV12 surfaces for AMD and Intel GPUs. It's disabled by default now. Please check whether this option helps or harms with your GPU (AMD/Intel only) and report. Thanks.

This option will not "take". If I click it, the apply button does not enable, if I hit okay and come back, the option reverts to disabled.

.87e fixes the performance problem here for me for SD material. No drops, queues full. Turned on error diffusion also.

Still have the slideshow with 1080p film on 1080 monitor, upload queue just never goes above 1...fwiw, I have a 1080p video file that works perfectly..

Edit: I should also add that all of my 1080p film mkvs are P010, not sure if that makes a difference, I don't have any 8-bit 1080p film mkvs....

[jaju123]

So what is the new maximum quality setting? I am using two AMD r9 290s in crossfire, if that helps! :) Is OpenCL providing higher quality upscaling?

Thanks guys.

[huhn]

So what is the new maximum quality setting? I am using two AMD r9 290s in crossfire, if that helps! :) Is OpenCL providing higher quality upscaling?

Thanks guys.

what's best to your eyes.

[DarkSpace]

You're welcome. It's all in the documantation
Ugh. I think I even read that, but I thought comparisons meant all stuff that isn't bool by itself ( e.g. (srcWidth <= 720) compared to srcInterlaced ). Thanks for pointing it out to me, I hope I've learned something for the future. Anyway, it seems like it's not even a bug then!

By the way, madshi: What do you think about a single bool that states whether deinterlacing is active (false for source treated as progressive or IVTC, true for deinterlacing)? As I understand it, filmMode will be false for progressive content, so it's not entirely suitable, and I fear that if I once discover a source encoded as progressive but activate deinterlacing, the srcInterlaced switch won't change.

[cca]

Testing 0.87e on the PC shown in my signature produced good results, I can play my interlaced DVDs with the same settings I used in 0.86.11 plus debanding on. NNEDI is no go, too much load on the GPU. The only case I can use NNEDI is on SD videos of either 24 or 30 fps, on those cases it works good enough. To solve these issues I set up the profile system to select those options according to resolution/frame rate, I just blatantly copied madshi's example and tailored it to my needs ;)

EDIT: Forgot to mention, the option to enable/disable OpenCL processing of DXVA NV12 surfaces is not working for me either just like the above reports.

[DragonQ]

CPU load with 0.87e is now the same as 0.87.0 & 0.87a in my previous post, but it's still more than twice that of 0.86.11.

This CPU load regression exists in all builds starting with the first madVR deband test build released on 9/30/2013. There is no change whether debanding is enabled or disabled, so it must be some other change you made starting with that build.

This would seem to match my findings.

[kasper93]

You're right. I thought adding the "renderQueue" field would be a clever idea, but it changes too often for it to make sense. So I've completely removed it now.

Yeah, "renderQueue" was funny. But thats the only thing that I was excited about. So we could make profile based on performance not on source video. Maybe add "droppedFrames" instead? So we could make an automatic fallback to "faster" profile if certain threshold is reached. Or even few profiles with different limits ;p You know
if (droppedFrames < 50) "Profile1" else if (droppedFrames < 100) "Profile2" else "Profile3"

I know that it won't make much use, but hey it will be fun to have just in case.


Thanks for new release, everything is working great :) Except minor cosmetic, and my GPU performance :X

[vivan]

Maybe rendering time would be a better option?
Like (rendering_time * fps < 0.9) means that profile is too slow.

[djfred93]

MadVR don't load with the latest version, it is stuck at opening the file and it crash on the setting window. The debug work fine but the debug don't have the enable/disable OpenCL processing of DXVA NV12 option. The deinterlacing have framedrop but it's better than the other 0.87 version of MadVR. The deinterlacing worked fine (no framedrops) with the latest deband test and stable version. Thanks anyway for the latest version.

My system : Intel Core i7@920, Ati Radeon HD 5770, Windows 8.1, MPC-HC 1.7.1

[madshi]

For me this did the trick. Playback is smooth and CPU and GPU usage are about the same as with 0.86.11.
That's a relief.

CPU load with 0.87e is now the same as 0.87.0 & 0.87a in my previous post, but it's still more than twice that of 0.86.11.
This CPU load regression exists in all builds starting with the first madVR deband test build released on 9/30/2013. There is no change whether debanding is enabled or disabled, so it must be some other change you made starting with that build.
Ok, good to know. So it's got nothing to do with OpenCL or profiling, which should make it easier to fix. Was the CPU load already higher in the first few builds where fade in/out detection was not implemented yet? You seem to say so. Yet I'm wondering. The fade in/out detection was my first guess about what could have increased the CPU load. But if the CPU load was already higher in the first few deband test builds then fade in/out detection can't be the reason cause it was added rather late.

In the latest test build, I have the same issues:
if (srcInterlaced) && (!filmMode) "Don't Use OpenCL"
else "Use OpenCL"
works just fine (thanks michkrol!), but
if (srcInterlaced && !filmMode) "Don't Use OpenCL"
else "Use OpenCL"
doesn't work. If you want me to enter this into the bug tracker, please tell me so.
That's as intended. The script language is not fully C++ compatible. I do require brackets everywhere to make parsing simpler (= faster).

Here is another Log with 87.1 (87e) & GTX660:
https://www.mediafire.com/?kc6y1y9253f4gva
Log with GTX460: https://www.mediafire.com/?5rn2nmrwon1k85e
Thx.

By the way, madshi: What do you think about a single bool that states whether deinterlacing is active (false for source treated as progressive or IVTC, true for deinterlacing)? As I understand it, filmMode will be false for progressive content, so it's not entirely suitable, and I fear that if I once discover a source encoded as progressive but activate deinterlacing, the srcInterlaced switch won't change.
srcInterlaced will be true if you force deinterlacing on.

Hmm. Performance still seems worse than 0.86.x for me. GPU usage is 95-100% and the queues are essentially empty.

Disabling "Use random dithering instead of OpenCL error diffusion" drops GPU usage to ~85% but the queues are still generally empty. Using 10-bit chroma and image buffers gets me perfect playback but I've never had to use these options before.
Does that mean performance is 1-2% worse than before? Or are rendering times twice as high as before? Your post doesn't give any indication about how much worse things really got. Already a 1% performance drop could explain the problem if your settings were already borderline with v0.86.x.

The "Use OpenCL to process DXVA NV12 surfaces" doesn't seem to make any difference to GPU or CPU usage or the queues for me. By the way, ticking/unticking that option doesn't trigger the "Apply" button being enabled, unlike the other options.
I'm unable to save this option. The Apply button doesn't get activated, clicking OK does nothing.
This option will not "take".Yes, seems to be a bug.

Still have the slideshow with 1080p film on 1080 monitor, upload queue just never goes above 1...fwiw, I have a 1080p video file that works perfectly..

Edit: I should also add that all of my 1080p film mkvs are P010, not sure if that makes a difference, I don't have any 8-bit 1080p film mkvs....
Your CPU does support SSE2, I hope? In v0.86.x I uploaded P010 content simply by using the MSVC++ "memcpy" function. Now in v0.87.x I'm using custom SSE2 code which while copying also does some rudimentary analyzation of the pixel data (for fade in/out detection and for potential future features). On my CPU/GPU the SSE2 code performs just as fast as the old "memcpy" code. But it seems to be very different on your PC. I'm wondering why...

Testing 0.87e on the PC shown in my signature produced good results, I can play my interlaced DVDs with the same settings I used in 0.86.11 plus debanding on. NNEDI is no go, too much load on the GPU. The only case I can use NNEDI is on SD videos of either 24 or 30 fps, on those cases it works good enough. To solve these issues I set up the profile system to select those options according to resolution/frame rate
That's exactly the reason I implemented profiles now.

Yeah, "renderQueue" was funny. But thats the only thing that I was excited about. So we could make profile based on performance not on source video. Maybe add "droppedFrames" instead? So we could make an automatic fallback to "faster" profile if certain threshold is reached. Or even few profiles with different limits ;p
The problem is that dropped frames can jump a lot if you seek or things like that. I liked the idea of switching profiles based on rendering performance/state myself. But in real life switching rendering settings costs time/performance, too. And if whatever value you're checking is borderline, it's bound to jump back and forth over the boundary all the time, resulting in profiles having to switch back and forth all the time, too, which doesn't really make sense. Maybe I'll find a better solution for this in the future. But for now I think switching based on actual performance isn't going to work well.

Maybe rendering time would be a better option?
Like (rendering_time * fps < 0.9) means that profile is too slow.
That would probably work better. But what happens if the profile switches, and then the rendering times is low enough, so just 2 frames later the profiles switch back into the more difficult profile again? Switching settings around all the time is not a good idea, it costs performance, too. Furthermore NNEDI3 has a 0.5 pixel offset, so if you switch NNEDI3 on/off during playback, the image will shift 0.5 pixels during runtime, too.

MadVR don't load with the latest version, it is stuck at opening the file and it crash on the setting window.
Strange. Please try again with the next build.

-------

So here's the next test build. I'm carefully optimistic that it might make OpenCL work with newer NVidia GPUs. Give it a few seconds when you activate OpenCL features the first time. The kernels need to be compiled which may take 1-3 seconds or so.

http://madshi.net/madVR87f.rar

Also the new OpenCL option should now work properly.

[James Freeman]

So here's the next test build. I'm carefully optimistic that it might make OpenCL work with newer NVidia GPUs.

Not yet, but I see a different behaviour.
The image turns black whether on the previous release (87e) it freezes.

MadVR 87f Log (http://www.mediafire.com/download/pg1538dcf7j28y0/madVR%20-%20log%2087f.zip)

[cyberbeing]

Still a black screen when enabling OpenCL stuff (tested dither and nnedi) with 0.87f.

madVR 0.87f debug log (http://www.mediafire.com/?un3mceavrtvssgz)

And yes, the CPU load regression began in the very first deband test build (http://madshi.net/madVRdeband.rar). 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.

Seems that D3D9 <-> OpenCL interop doesn't work properly.

Simple OpenCL D3D9 Texture
Simple program which demonstrates Direct3D9 texture interoperability with OpenCL. The program creates a number of D3D9 textures (2D, 3D, and CubeMap) which are written to from OpenCL kernels. Direct3D then renders the results on the screen.

The NVIDIA test program for D3D9 <-> OpenCL interop runs successfully on my GTX 770. Link (http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSimpleD3D9Texture.zip)

It also seems to be very fast, at least in these simple test programs. While the D3D9 <-> OpenCL interop program seems to have fps limited to VSync (max I could test on my CRT was 170fps @ 170Hz with 5% GPU load), their D3D10 version (http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSimpleD3D10Texture.zip) utilizing swap chain isn't, and runs runs at 1550 fps on my GTX 770 at only 50% GPU load.

Maybe worth looking at? At least it confirms this OpenCL feature isn't bugged with the 332.21 driver.

[madshi]

Not yet, but I see a different behaviour.
The image turns black whether on the previous release (87e) it freezes.

MadVR 87f Log (http://www.mediafire.com/download/pg1538dcf7j28y0/madVR%20-%20log%2087f.zip)
Hmmmm... Your log reports that everything's working. Can you try NNEDI3 instead of Error Diffusion? Still black image?

[HeadlessCow]

That would probably work better. But what happens if the profile switches, and then the rendering times is low enough, so just 2 frames later the profiles switch back into the more difficult profile again? Switching settings around all the time is not a good idea, it costs performance, too. Furthermore NNEDI3 has a 0.5 pixel offset, so if you switch NNEDI3 on/off during playback, the image will shift 0.5 pixels during runtime, too.

Maybe a "maxRenderingTime" value instead of "renderingTime", that way once you hit a frame that has a rendering time that is too high it will switch to the lower profile and stay there.

[DarkSpace]

That's as intended. The script language is not fully C++ compatible. I do require brackets everywhere to make parsing simpler (= faster).
Thanks, I'll just leave it as it is and remember it for the future, then.

srcInterlaced will be true if you force deinterlacing on.
That's one less worry, then!

Furthermore NNEDI3 has a 0.5 pixel offset, so if you switch NNEDI3 on/off during playback, the image will shift 0.5 pixels during runtime, too.
Talking about NNEDI pixel shifts: You added a chroma upscaling option for NNEDI, how do you handle the shifts there?

[DragonQ]

Does that mean performance is 1-2% worse than before? Or are rendering times twice as high as before? Your post doesn't give any indication about how much worse things really got. Already a 1% performance drop could explain the problem if your settings were already borderline with v0.86.x.
Screenshots for the same clip (1080i/25) with the same settings (no new OpenCL stuff) for 0.86.11 and 0.87f are below using an HD4000. My settings are:

Luma: Lanczos3AR (shouldn't be used in this case)
Chroma: Bicubic75
Downscaling: Catmull-Rom
General: Using separate device for presentation & DXVA processing
Smooth Motion: On
Deinterlacing: On

I only get a few dropped frames when first opening the video with 0.86.11, I get loads and very dodgy playback with 0.87f. In terms of average stats, all of them are worse with the latter.

Screenshot 0.86.11 (http://www.aotplaza.com/Files/HTPC/Screengrabs/MadVR/0.86.11.png)
Screenshot 0.87f (http://www.aotplaza.com/Files/HTPC/Screengrabs/MadVR/0.87f.png)

[James Freeman]

Hmmmm... Your log reports that everything's working. Can you try NNEDI3 instead of Error Diffusion? Still black image?

It freezes with Chroma upscaler or NNEDI3 Doubling.
I have revert to Lanczos (or any other) and restart MPC-HC because the image freezes completely (audio still working though).
Moreover, I have to manually close the mpc-hc.exe process because it stays open after I close MPC itself with the (X) button.

[madshi]

Still a black screen when enabling OpenCL stuff with 0.87f.

madVR 0.87f debug log (http://www.mediafire.com/?un3mceavrtvssg)
That link doesn't seem to work for me. Have you tested NNEDI3, too? Or just error diffusion? Please try both. Thx.

And yes, the CPU load regression began in the very first deband test build (http://madshi.net/madVRdeband.rar). CPU load in 0.87.0 is slightly higher (+0.3%), but the significant doubling in madVR CPU usage started with this first deband test build.
Ok, thanks, will look into this later. I'm not good at looking into 10 different issues at the same time.

The NVIDIA test program for D3D9 <-> OpenCL interop runs successfully on my GTX 770. Link (http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSimpleD3D9Texture.zip)

It also seems to be very fast, at least in these simple test programs. While the D3D9 <-> OpenCL interop program seems to have fps limited to VSync (max I could test on my CRT was 170fps @ 170Hz with 5% GPU load), their D3D10 version (http://developer.download.nvidia.com/compute/DevZone/OpenCL/Projects/oclSimpleD3D10Texture.zip) utilizing swap chain isn't, and runs runs at 1550 fps on my GTX 770 at only 50% GPU load.

Maybe worth looking at? At least it confirms this OpenCL feature isn't bugged with the 332.21 driver.
It doesn't confirm anything. There are a million different ways to use D3D9 and OpenCL. All this demo proves is that one out of those million ways works ok. Which is not surprising because this demo is probably what NVidia tests with. I'm using different flags for creating the textures, different flags for mapping the texture to OpenCL (the NVidia demo actually uses clearly incorrect flags, according to NVidia's own OpenCL documentation). Also my code has a very different handling of OpenCL input/output. What I found out is that my NVidia 9400 has no problem with shared textures, but your GPU does. So I've dropped the use of shared textures when using OpenCL with NVidia. However, AMD and Intel actually *require* the use of shared textures, otherwise OpenCL will run a hundred times slower. Programming can be funny sometimes. Now it seems that according to NVidias OpenCL APIs everything seems to run through fine with the latest test build, but the video image is black. Why? I've no idea...

I guess the only way to get this fixed might be to install a newer NVidia GPU into one of my PCs, so I can try all this myself. But all of this is probably a bug in NVidia's OpenCL code and not my fault.

Maybe a "maxRenderingTime" value instead of "renderingTime", that way once you hit a frame that has a rendering time that is too high it will switch to the lower profile and stay there.
Once in a while (e.g. after changing settings) the maxRenderingTime might have a big spike. That would screw everything up. This really isn't easy. Maybe I'll find a solution for this idea of using profiles. But not right now. I'm busy fixing bugs for now.

Talking about NNEDI pixel shifts: You added a chroma upscaling option for NNEDI, how do you handle the shifts there?
Chroma actually has to be shifted in one direction, so there the NNEDI3 shift is exactly what I need. However, in the other direction it should not be shifted, so I run another interpolation pass over the NNEDI3 chroma upscaling output to correct the chroma position.

Screenshots for the same clip (1080i/25) with the same settings (no new OpenCL stuff) for 0.86.11 and 0.87f are below using an HD4000. My settings are:

Luma: Lanczos3AR (shouldn't be used in this case)
Chroma: Bicubic75
Downscaling: Catmull-Rom
General: Using separate device for presentation & DXVA processing
Smooth Motion: On
Deinterlacing: On

I only get a few dropped frames when first opening the video with 0.86.11, I get loads and very dodgy playback with 0.87f. In terms of average stats, all of them are worse with the latter.

Screenshot 0.86.11 (http://www.aotplaza.com/Files/HTPC/Screengrabs/MadVR/0.86.11.png)
Screenshot 0.87f (http://www.aotplaza.com/Files/HTPC/Screengrabs/MadVR/0.87f.png)
This looks like a rather big difference. Are you sure you haven't accidently left debanding on, or something like that? I know, stupid question. But I can't explain such a big difference with anything else...

[DragonQ]

This looks like a rather big difference. Are you sure you haven't accidently left debanding on, or something like that? I know, stupid question. But I can't explain such a big difference with anything else...

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

[cyberbeing]

That link doesn't seem to work for me. Have you tested NNEDI3, too? Or just error diffusion? Please try both. Thx.

Fixed the link, it was missing a "z" at the end. http://www.mediafire.com/?un3mceavrtvssgz

That log is just with error diffusion though. Here is another with NNEDI:
https://www.mediafire.com/?e9dy437h3x2eh2s

I guess the only way to get this fixed might be to install a newer NVidia GPU into one of my PCs, so I can try all this myself.

Or try porting the code OpenCL to CUDA directly and see if that works... NVIDIA's drivers run OCL via CUDA anyway, but the translation is probably less than optimal.

[djfred93]

MadVR don't load with the latest version, it is stuck at opening the file and it crash on the setting window. The debug work fine but the debug don't have the enable/disable OpenCL processing of DXVA NV12 option. The deinterlacing have framedrop but it's better than the other 0.87 version of MadVR. The deinterlacing worked fine (no framedrops) with the latest deband test and stable version. Thanks anyway for the latest version.

My system : Intel Core i7@920, Ati Radeon HD 5770, Windows 8.1, MPC-HC 1.7.1

Still the same but debug don't work either with the latest version

log (http://www.mediafire.com/view/0giu29vh6g17cwo/madVR%20-%20log.txt)

[noee]

Your CPU does support SSE2, I hope? In v0.86.x I uploaded P010 content simply by using the MSVC++ "memcpy" function. Now in v0.87.x I'm using custom SSE2 code which while copying also does some rudimentary analyzation of the pixel data (for fade in/out detection and for potential future features). On my CPU/GPU the SSE2 code performs just as fast as the old "memcpy" code. But it seems to be very different on your PC. I'm wondering why...

Yes, it does, but it's an old Athlon II 620. I'll try some overclocking (this chip will hit 3.7 on air, especially the cold air we have this week!) and see if that makes any difference.

FWIW, I have a Kaveri coming next week for a client build.....

[madshi]

Fixed the link, it was missing a "z" at the end. http://www.mediafire.com/?un3mceavrtvssgz

That log is just with error diffusion though. Here is another with NNEDI:
https://www.mediafire.com/?e9dy437h3x2eh2s
Hmmmm... According to the log NVidia OpenCL claims that error diffusion succeeds. However, NNEDI3 fails. Hmmmm... Will have to check if I can make sense of the NNEDI3 failure.

Still the same but debug don't work either with the latest version

log (http://www.mediafire.com/view/0giu29vh6g17cwo/madVR%20-%20log.txt)
Which driver version are you using?

Yes, it does, but it's an old Athlon II 620. I'll try some overclocking (this chip will hit 3.7 on air, especially the cold air we have this week!) and see if that makes any difference.
Ah, ok. How high is CPU consumption when the upload queue is empty? How high is CPU consumption with v0.86.11 in the same situation?

I'll probably release a few test builds tomorrow aimed at different problems. I'm probably done for today...

[DarkSpace]

Chroma actually has to be shifted in one direction, so there the NNEDI3 shift is exactly what I need. However, in the other direction it should not be shifted, so I run another interpolation pass over the NNEDI3 chroma upscaling output to correct the chroma position.
Thanks for the explanation. The unwanted shift is exactly why I was asking... I'm curious: What kind of interpolation pass are you running?

[noee]

Ah, ok. How high is CPU consumption when the upload queue is empty? How high is CPU consumption with v0.86.11 in the same situation?

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.

I'm going to see if I can find the "sweet spot" where it goes good.

[djfred93]

which driver version are you using?

ccc 13.12

[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.

[Q-the-STORM]

Got a NVIDIA GTX 560M
I have upgraded to the current version, these are my issues:

trade quality for performance the new openCL option, if I uncheck it, I get a black screen.
same for NNEDI3 options, so it seems to be the same issue others describe...

I have not changed any settings, except i deactivated all quality for performance settings (except the opencl one)


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...



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 (http://www53.zippyshare.com/v/95652553/file.html)

//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...

[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).

[Deim0s]

Except OpenCL, stopped working algorithms "image downscaling" (...or something else).
While playing content UHD (4k):
in windowed mode slideshow (madVR output (http://i.imgur.com/QaPMvtg.png)),
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

[Farfie]

Probably redundant, but I'm throwing up another log just in case you find yourself needing more clues.

madvr log .87f (https://mega.co.nz/#!mEsUQDSQ!OwnNX00ZvDj0WU06ILLU8LPxF5SB0Tx8gmUefG5qoqk)

[kazuya2k8]

Tested with 0.87f still blank w/ error diffusion, nnedi3 upscaling and needi3 doubling. Hope this logs help.

madVRlog errdiff.7z (https://dl.dropboxusercontent.com/u/48377332/madVR%20logs/madVRlog%20errdiff.7z)

madVRlog nnedi3chromup.7z (https://dl.dropboxusercontent.com/u/48377332/madVR%20logs/madVRlog%20nnedi3chromup.7z)

madVRlog nnedi3double.7z (https://dl.dropboxusercontent.com/u/48377332/madVR%20logs/madVRlog%20nnedi3double.7z)

GTX 660 w/ 332.21 Driver

[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.

[truexfan81]

madshi running the f build the cpu load is back down, all is good until i try using profiles, even a simple rule such as:
if (srcFps == 60) "Profile 2" else "Profile 1" fails to use the correct profile, i know this because my gpu cannot handle my Profile 1 settings with 60fps content so it results in all queues empty and massive frame drops.

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

[yok833]

Hello I have no possibilty to try the new version of Madvr right now but I was wondering is the new <error diffusion >algorithm improves the picture quality in your opinion? What is the difference with the option that you can select in lav filters with ordered/random dithering??? Which one should we use for the best quality?

[Nachbar]

MadVR don't load with the latest version, it is stuck at opening the file and it crash on the setting window.

My system : Intel Core i7@920, Ati Radeon HD 5770, Windows 8.1, MPC-HC 1.7.1

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

[ryrynz]

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]

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]

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]

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]

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]

Latest official version for me is just showing a black screen when using it's deinterlacing

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