madVR - high quality video renderer (GPU assisted)

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

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]

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]

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]

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

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

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?

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.

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

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

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?

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.

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

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?

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.

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)?

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?

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?

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?

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?

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.

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?

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.

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.

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.

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]

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

[MSL_DK]

Is there any way to check an mkv for faults resulting in dropped frames and presentation glitches?

Thanks for the new release!

[cyberbeing]

0.87g has essentially resolved the CPU load issue. It's now close enough that the remaining difference can be chalked up to new features added.

madVR 0.86.11 = 1.52% +/- 0.02% CPU load

madVR 0.87g = 1.63% +/- 0.02% CPU Load

The special 'cyber' build seems slightly worse with 1.67% +/- 0.02% CPU load.

[noee]

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?

Quite impressive results with .87g. Yes, it appears to be back to .86 perf levels. In fact, maybe even better, queues are all maxed full.

So, I decided to enable debanding and Error Diffusion, and it's working great with those options too. Maxed out queues, no drops, excellent perf. We'll see what happens with NNEDI, but that might be the line for this GPU (HD6570).

[PixelH8]

Oh goodie. I just tried the latest madVR87g build and the swapped colors are definitely gone. But the not-so-little red box that sometimes flashes in the upper left corner is supposed to be there right? To indicate that this is a test build?

I also have a third system with a GTS 250 that I'm in the middle of repairing. As soon as I'm done I'll let you know how the new build works on that system as well.

[Siso]

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

I can confirm the swapped color channels too.
GTX 550 ti, 326.19

MPC-BE latest stable version, lav filters 0.60.1, xy-vsfilter 3.0.0.236

I'm going to try 0.87g

[madshi]

Ooopsi-daisy, forgot to reenable optimization in the MSVC++ compiler settings. Does this one bring 0.87g back to 1.52%, cyberbeing? Please also try enabling debanding with different settings for fade in/out detection, to see how that impacts CPU performance - because in that case madVR will fall back to my SSE2 uploading code, instead of using memcpy. Would be interesting to see how it compares...

http://madshi.net/madVRoptimized.rar (87g, only release mode madVR.ax)

[madshi]

Oh goodie. I just tried the latest madVR87g build and the swapped colors are definitely gone. But the not-so-little red box that sometimes flashes in the upper left corner is supposed to be there right? To indicate that this is a test build?
Ooops, sorry. That's a debug rectangle which indicates that madVR detected a fade in/out. I sometimes enable that so I can see whether fade in/out detection works or not. I'll disable it again for the next build.

Quite impressive results with .87g. Yes, it appears to be back to .86 perf levels. In fact, maybe even better, queues are all maxed full.

So, I decided to enable debanding and Error Diffusion, and it's working great with those options too. Maxed out queues, no drops, excellent perf. We'll see what happens with NNEDI, but that might be the line for this GPU (HD6570).
Good to hear! I did do some changes which I hoped would improve performance slightly.

[SecurityBunny]

Can you please retest with 87g?




Random dithering with smooth motion no longer flashes the screen. OpenCL error diffusion (unchecked use random dithering) still causes a black screen unfortunately. I'll take your advice and stay away from OpenCL for the time being. Thanks for the smooth motion fix.

[pie1394]

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


This version is actually worse on the ION-LE platform. None of these two issues is fixed. Instead it introduces a new issue: :rolleyes:

- Video screen becomes totally black when the 1st subtitle arrived from XySubFilter -- if SmoothMotion logic is NOT engaged. It happens to any 24-frames or 60-fields contents regardless of resolution. Debanding option ON/OFF does not matter, either.

[Soukyuu]

Now this is weird. Why is it working for you - and for me, too. But not for everyone else? I'm quite confused.I smell driver issue. Everyone with failing openCL features, including me, are on one of the newest driver versions. Maybe nVidia broke something in the update?

[cyberbeing]

Ooopsi-daisy, forgot to reenable optimization in the MSVC++ compiler settings. Does this one bring 0.87g back to 1.52%, cyberbeing?

That build is even better, ~1.26% CPU load.


Please also try enabling debanding with different settings for fade in/out detection, to see how that impacts CPU performance - because in that case madVR will fall back to my SSE2 uploading code, instead of using memcpy. Would be interesting to see how it compares...

I'll look into this.

[madshi]

This version is actually worse on the ION-LE platform. None of these two issues is fixed. Instead it introduces a new issue: :rolleyes:

- Video screen becomes totally black when the 1st subtitle arrived from XySubFilter -- if SmoothMotion logic is NOT engaged. It happens to any 24-frames or 60-fields contents regardless of resolution. Debanding option ON/OFF does not matter, either.
Hmmmm... I've tried all of this on my NVidia 9400 GPU which had problems with black rectangles when using XySubFilter in the past. But no problems here, whatsoever. How can I reproduce these issues? Maybe you can provide me with small samples to test with, in case it has something to do with the samples somehow?

That build is even better, ~1.26% CPU load.
Cool! :)

I smell driver issue. Everyone with failing openCL features, including me, are on one of the newest driver versions. Maybe nVidia broke something in the update?
That is quite possible. Anyone willing to downgrade to the driver versions used by PixelH8 to check if that fixes the OpenCL issues?

[James Freeman]

87g with Debanding, 4K 60fps video (downscaled to HD with Catmull-Rom) works like charm without frame skipping (although buffers not fully full).
Without Debanding the buffers completely full with this video.

"1 frame drop every t" & "clock deviation %" works better than 86.11, its a lot more stable.
Performance up to par with 86.11 or even better, Perfect.

[madshi]

madVR v0.87.1 released

http://madshi.net/madVR.zip

* fixed: CPU consumption was unnecessarily high
* fixed: auto profile switching didn't fully work
* fixed: uploading was very slow, resulting in performance problems
* fixed: chroma channels were swapped when using error diffusion with NVidia
* fixed: some OpenCL crashes when using OpenCL 1.2 DLL with NVidia
* fixed: smooth motion FRC produced black image in some situations
* fixed: video mode deinterlacing was completely broken
There may still be some problems left. But there's definite improvement over v0.87.0, so I've decided to release v0.87.1 now.

Current theory is that older NVidia drivers might make OpenCL work with madVR, and that newer drivers might have broken something. Drivers 306.97 are reported to be working with GTX 560 Ti. And drivers 310.90 are reported to be working with GTX 460. This needs to be double checked.

[burfadel]

I tried the MadVR optimised one, and it didn't even load! (MPC-HC used a different renderer). I then went back and realised the previous version I had was 0.87E or 0.87F, so I copied over the files from 0.87G, then used the MadVR optimised version and it works fine :).

[antonyfrn]

I just installed 87G and tried with MadVR Optimised and both give me the below message if I go from full screen to windowed mode. (I used the restore defaults bat to clear out any settings)

resetting Direct3D device failed (80070005)
creating Direct3D device failed (80070005)

[DarkSpace]

Lanczos3AR in only one dimension (Y, IIRC) to shift the image 0.5 pixels.
Yes, should be y dimension (x needs the shift, after all). Thanks for answering!
Now for the (I think) last curious question: Even though it's probably insignificant, do you have any plans to let the user choose the shifting algorithm?

[mark0077]

madVR v0.87.1 released

http://madshi.net/madVR.zip

* fixed: CPU consumption was unnecessarily high
* fixed: auto profile switching didn't fully work
* fixed: uploading was very slow, resulting in performance problems
* fixed: chroma channels were swapped when using error diffusion with NVidia
* fixed: some OpenCL crashes when using OpenCL 1.2 DLL with NVidia
* fixed: smooth motion FRC produced black image in some situations
* fixed: video mode deinterlacing was completely broken
There may still be some problems left. But there's definite improvement over v0.87.0, so I've decided to release v0.87.1 now.

Current theory is that older NVidia drivers might make OpenCL work with madVR, and that newer drivers might have broken something. Drivers 306.97 are reported to be working with GTX 560 Ti. And drivers 310.90 are reported to be working with GTX 460. This needs to be double checked.

Cheers for the new version. All working fine except for OpenCL as reported. My driver version is 332.21 WHQL with GTX295 incase anyone else has older driver versions with the same card and it works. Do you have a contact in Nvidia or do you need any of us to post on their forums regarding the OpenCL issues?

[antonyfrn]

@madshi just some info for you posted by an NVidia Rep ManuelG maybe something improvements driver side or a headache I think they are off the new Quadros 334.67

For those who don't like to mod their drivers or risk corrupting their driver installation, we will be releasing an update Geforce driver soon.

creating Direct3D device failed (80070005) message with 0.87.1 you just posted

[Soukyuu]

Anyone willing to downgrade to the driver versions used by PixelH8 to check if that fixes the OpenCL issues?331.81 -> 310.90:
- openCL dither works
- NNEDI doubling works (slideshow)
- luma NNEDI upscaling gives a green tint to the whole image for 10bit h264, 8bit is fine.

I am going to update versions until I hit the blackscreen again. This is with 87.1 btw.

[noee]

Just an FYI regarding the older low-end pre-GCN AMD cards (HD6570) performance. I have my primary display set at 6bit and my secondary as 8bit. Playback on the 8bit monitor with error diffusion enabled drops frames and the render queue can't keep up with all material. If I set it to 7bit, back to perfect playback with error diffusion enabled. If I turn off error diffusion and set to 8bit, same perfect playback. Not sure I can see a difference in the image with playback. Is one option more "optimal" than the other?

[DragonQ]

Performance in general is improved certainly. I can now watch that 1080i/25 video in a full screen window when using DXVA2 Native as long as I don't open any other windows on top, but not when using software decoding, so maybe CPU usage is the problem? Seems strange since this CPU is pretty beefy (mobile Ivy Bridge Core i5). If I even open GPU-Z or Task Manager it stops working and I see GPU usage at 99-100%, so I guess it's sailing close to the wind.

When the render queue dips the frame order still goes all wrong (requires pausing and resuming to fix), but this bug has existed for as long as I can remember on all of my machines.

[huhn]

render times are good now same or better than 86.9.

all version still freeze when fullscreen exclusive is used and active when a new/next file is loaded.

tested with all 3 g versions and 87.1.

this is a very typical usages and easy to reproduce but no one else reported this issue. a problem at my end?

[aufkrawall]

I'm getting framedrops with smooth motion + debanding during fade ins/outs if I disable rerendering frames for this.
Is this expected behavior? GPU is a GTX 670 at 1.2Ghz and queues seem to be fine. With smooth motion off I'm getting "just" presentation glitches in such situations.
Dunno if wanted/needed, but I guess it doesn't hurt to link to a debug log:
https://www.mediafire.com/?igbz9sayzry2rw7

[mark0077]

@madshi just some info for you posted by an NVidia Rep ManuelG maybe something improvements driver side or a headache I think they are off the new Quadros 334.67


I just tried these 334.67 quadro drivers on my GTX295, looks like it hasn't been fixed in these at least, still OpenCL issues.

[Deim0s]

madshi,
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.)
Yes, as before, there is a problem.
While playing content UHD (4k) began to appear such messages OSD: 1 (http://i.imgur.com/U6osUgs.png), 2 (http://i.imgur.com/wLWp6lK.png).
Sometimes played with artifacts in windowed mode and black screen in full screen.
One time playback of many attempts was normal.

Maybe to you can help debug information: madVR - log (http://rghost.ru/51915841)

[madshi]

I tried the MadVR optimised one, and it didn't even load! (MPC-HC used a different renderer). I then went back and realised the previous version I had was 0.87E or 0.87F, so I copied over the files from 0.87G, then used the MadVR optimised version and it works fine :).
Yeah, the new build requires the new mvrSettings.dll, too, otherwise it won't load.

I just installed 87G and tried with MadVR Optimised and both give me the below message if I go from full screen to windowed mode. (I used the restore defaults bat to clear out any settings)

resetting Direct3D device failed (80070005)
creating Direct3D device failed (80070005)
Hmmm... Can anybody else reproduce this?

Antony, is this problem new with v0.87.x, or did this also occur with v0.86.11? Can you play with all the various settings a bit to check if any setting changes anything? How about default settings, does it occur with those, too? Ideally, I'd need to be able to reproduce it somehow...

Yes, should be y dimension (x needs the shift, after all. Thanks for answering!
Now for the (I think) last curious question: Even though it's probably insignificant, do you have any plans to let the user choose the shifting algorithm?
I don't think so. I've written a custom pixel shader script for the shifting which is performance optimized for just this purpose. If I offered other algorithms, that would mean a lot extra work, and to be honest, I don't think it's important enough. When shifting, the algorithm is not too important. I don't think e.g. Jinc3AR would look any better even with test patterns for simple 0.5 pixel shifting.

Cheers for the new version. All working fine except for OpenCL as reported. My driver version is 332.21 WHQL with GTX295 incase anyone else has older driver versions with the same card and it works. Do you have a contact in Nvidia or do you need any of us to post on their forums regarding the OpenCL issues?
Soukyuu just reported downgrading actually does help. So it seems to be proven: OpenCL/NVidia/madVR works with older drivers, but not with new drivers, for some reason...

331.81 -> 310.90:
- openCL dither works
- NNEDI doubling works (slideshow)
- luma NNEDI upscaling gives a green tint to the whole image for 10bit h264, 8bit is fine.

I am going to update versions until I hit the blackscreen again. This is with 87.1 btw.
Thanks for testing! Will be interesting to know which NVidia driver version introduced the problem.

Just an FYI regarding the older low-end pre-GCN AMD cards (HD6570) performance. I have my primary display set at 6bit and my secondary as 8bit. Playback on the 8bit monitor with error diffusion enabled drops frames and the render queue can't keep up with all material. If I set it to 7bit, back to perfect playback with error diffusion enabled. If I turn off error diffusion and set to 8bit, same perfect playback. Not sure I can see a difference in the image with playback. Is one option more "optimal" than the other?
I probably should have said that error diffusion is only used if your display is set to 8bit. Otherwise I'm silently falling back to random dithering. I don't think I can do error diffusion to lower than 8bit because I don't know whether the displays rounds or truncates to 6/7 bits and at which values exactly.

Performance in general is improved certainly.
Improved over v0.87.0, or improved over v0.86.11? How is it compared to v0.86.11?

all version still freeze when fullscreen exclusive is used and active when a new/next file is loaded.

tested with all 3 g versions and 87.1.

this is a very typical usages and easy to reproduce but no one else reported this issue. a problem at my end?
And this didn't occur with v0.86.11? Will try to reproduce it here...

I'm getting framedrops with smooth motion + debanding during fade ins/outs if I disable rerendering frames for this.
Is this expected behavior? GPU is a GTX 670 at 1.2Ghz and queues seem to be fine. With smooth motion off I'm getting "just" presentation glitches in such situations.
Dunno if wanted/needed, but I guess it doesn't hurt to link to a debug log:
https://www.mediafire.com/?igbz9sayzry2rw7
Definitely not expected behaviour. With *disabled* rerendering?? That's weird. How about if you enable it? Same problem? Or does that work fine?

I just tried these 334.67 quadro drivers on my GTX295, looks like it hasn't been fixed in these at least, still OpenCL issues.
You need to go older, not newer, it seems.

Yes, as before, there is a problem.
While playing content UHD (4k) began to appear such messages OSD: 1 (http://i.imgur.com/U6osUgs.png), 2 (http://i.imgur.com/wLWp6lK.png).
Sometimes played with artifacts in windowed mode and black screen in full screen.
One time playback of many attempts was normal.

Maybe to you can help debug information: madVR - log (http://rghost.ru/51915841)
And this did not occur with v0.86.11? It's a new problem with v0.87.x?

Is it possible that you're running out of GPU RAM? Try lowering the GPU queues and/or the number of pre-rendered frames. Does that help?

[michkrol]

Thanks for the new release, just tested v0.87.1. Everything works as expected.

If you're still interested, "use OpenCL to process DXVA NV12 surfaces" works here correctly (Intel HD 4000). I'm not noticing any performance penalty from this.

I really like the profiling's flexibility. I'm only missing an ability to use comments inside the script. Something like:
/* comment */
with different opening and closing tags should be quite fast to process (and easy to implement?).
I might have overdone it, but with 5 or more rules (SD/HD/FullHD + fps checks) it takes a while to sort out what is what (or what it was supposed to be). Perhaps something to consider in the future ;)

[kasper93]

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

I found out what happens. I was installing new drivers and forgot to disable video "enchantments".

It's quite strange actually because it doesn't work if I select "dynamic contrast" and any of the "De-Blocking", "Edge-enchantment", "De-noise", "Mosquito noise reduction". At least one, no matter which... "dynamic contrast" alone works fine, same as others without "dynamic contrast".

So in fact it's not a problem for me, because I always disable those options, but still maybe there is a way to fix it on madVR side. :)

[6233638]

* fixed: auto profile switching didn't fully workFor what it's worth, I am really happy with how the profile switching works in the new version of madVR - I just haven't said anything as I didn't want to interrupt the Nvidia OpenCL discussion.

Current theory is that older NVidia drivers might make OpenCL work with madVR, and that newer drivers might have broken something. Drivers 306.97 are reported to be working with GTX 560 Ti. And drivers 310.90 are reported to be working with GTX 460. This needs to be double checked.310.90 are over a year out of date, and the oldest WHQL drivers that Nvidia has available to download on the GeForce site.
The oldest Windows 8.1 certified drivers are 327.23 from September.

I tried installing 310.90 anyway, and it was successful - I was able to use the new error diffusion dithering.
However, enabling any of the nnedi scaling options still resulted in a black screen.


I understand that HTPC users don't have much reason to keep their drivers up to date, but the opposite is true for gamers - you need to stay on the latest drivers if you're playing the latest releases. It's often recommended to use the beta drivers rather than waiting for new WHQL drivers to be released. I typically avoid those however, as they often cause problems for madVR.

[za222]

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?
The issue is still present in 0.87.1. I've tried interlaced 50i/60i/29.97telecine SD/HD MPEG2/h264 material and it always fails.
When I toggle deinterlacing (Ctrl-Shift-D) while playing, the image shows / disappears.

Also (maybe this information could help?): After the initial green screen, when I resize the window I get a completely white screen.

Smooth motion seems to be completely unrelated.

[madshi]

If you're still interested, "use OpenCL to process DXVA NV12 surfaces" works here correctly (Intel HD 4000). I'm not noticing any performance penalty from this.
That's good to hear. I think OpenCL <-> Direct3D9 interop costs less performance with Intel compared to AMD. But then Intel's OpenCL performance itself is rather bad. But the DXVA NV12 stuff is very light weight, so no problem for Intel.

I really like the profiling's flexibility. I'm only missing an ability to use comments inside the script.
"//" comments should be supported. Not tested it, though. I'm strictly opposed to using "/*" or "{" comments for documentation in C++, because doing so means you can't comment out large portions of source code. "//" comments don't come with this problem, so I added support only for "//".

I found out what happens. I was installing new drivers and forgot to disable video "enchantments".

It's quite strange actually because it doesn't work if I select "dynamic contrast" and any of the "De-Blocking", "Edge-enchantment", "De-noise", "Mosquito noise reduction". At least one, no matter which... "dynamic contrast" alone works fine, same as others without "dynamic contrast".

So in fact it's not a problem for me, because I always disable those options, but still maybe there is a way to fix it on madVR side. :)
That's interesting. Can you double check whether this is a new problem with v0.87.x? Or does it also occur with v0.86.11?

For what it's worth, I am really happy with how the profile switching works in the new version of madVR
:)

310.90 are over a year out of date, and the oldest WHQL drivers that Nvidia has available to download on the GeForce site.
The oldest Windows 8.1 certified drivers are 327.23 from September.

I tried installing 310.90 anyway, and it was successful - I was able to use the new error diffusion dithering.
However, enabling any of the nnedi scaling options still resulted in a black screen.

I understand that HTPC users don't have much reason to keep their drivers up to date, but the opposite is true for gamers - you need to stay on the latest drivers if you're playing the latest releases. It's often recommended to use the beta drivers rather than waiting for new WHQL drivers to be released. I typically avoid those however, as they often cause problems for madVR.
I don't think it's a good long term solution to require old drivers. Maybe I can make things work with new drivers, too. But I don't know yet. This might be NVidia's job to fix. Or mine. At least installing old drivers could be a temporary solution for users who desperately want to try/use the new OpenCL features...

The issue is still present in 0.87.1. I've tried interlaced 50i/60i/29.97telecine SD/HD MPEG2/h264 material and it always fails.
When I toggle deinterlacing (Ctrl-Shift-D) while playing, the image shows / disappears.

Also (maybe this information could help?): After the initial green screen, when I resize the window I get a completely white screen.

Smooth motion seems to be completely unrelated.
So the issue is caused by DXVA deinterlacing, correct? It doesn't occur if you force film mode on? And it also doesn't occur if you force deinterlacing off? Does this issue also occur with v0.86.11? Or is it a new problem with v0.87?

[nevcairiel]

I'm strictly opposed to using "/*" or "{" comments for documentation in C++, because doing so means you can't comment out large portions of source code.

Off-Topic, but in C++ I use "#if 0" to disable large code blocks to avoid such problems.. :)

[cyberbeing]

GTX 770

__

312.69 driver (Quadro maintenance release for R310 branch, 10/28/2013)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

__


310.90 driver (Geforce R310 branch, 12/29/2012)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

[antonyfrn]

@madshi the issue was introduced for me in 0.87.G I tried with the optimised file and the latest build v0.87.1. Each time I've reset the setting to default using the bat file to reset madvr settings I will play about with it again some more and try get you a log

[Ava Pug]

last working nvidia driver that works for me is 327.23

[za222]

So the issue is caused by DXVA deinterlacing, correct? It doesn't occur if you force film mode on? And it also doesn't occur if you force deinterlacing off? Does this issue also occur with v0.86.11? Or is it a new problem with v0.87?
It seems like it:
Force Film -> Works
Force Video -> Broken
Deinterlacing Off -> Works

0.86.11 in all of the cases above -> Works

[Budtz]

i can confirm switching to another file in FSE-mode crashes or freezes. this happens everytime i try and never i windowed mode

[madshi]

Off-Topic, but in C++ I use "#if 0" to disable large code blocks to avoid such problems.. :)
Hehe, yes, that should work, too. Personally, I always use // for comments. As a result I can use { or /* to comment out large source code sections without any problems.

GTX 770

__

312.69 driver (Quadro maintenance release for R310 branch, 10/28/2013)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)

__


310.90 driver (Geforce R310 branch, 12/29/2012)

OpenCL Dither = functional
NNEDI doubling = broken (black screen, frozen frame, or hung GPU)
NNEDI chroma = broken (black screen, frozen frame, or hung GPU)
Interesting. NNEDI works here, too, with my 9400, but this might be just luck. Maybe there's a bug there in my code, I don't know. Could be, since error diffusion works.

@madshi the issue was introduced for me in 0.87.G I tried with the optimised file and the latest build v0.87.1. Each time I've reset the setting to default using the bat file to reset madvr settings I will play about with it again some more and try get you a log
Please always quote me, otherwise I lose track of past communication.

I could interpret your post as saying that the problem did not occur in v0.86.11, but I don't want to interpret, I want to know for sure, without any doubt. So please say it clearly: Did this issue occur in v0.86.11 or not? Please double check if you're not sure. Thanks.

last working nvidia driver that works for me is 327.23
You mean with OpenCL? Does NNEDI work for you with that driver? Or just error diffusion?

It seems like it:
Force Film -> Works
Force Video -> Broken
Deinterlacing Off -> Works

0.86.11 in all of the cases above -> Works
Hmmmm... Ok. Let me see what has changed in the source code which could explain this. Might have to release some test builds to get to the bottom of this problem...

i can confirm switching to another file in FSE-mode crashes or freezes. this happens everytime i try and never i windowed mode
Ok, I'll look into it.

[kasper93]

That's interesting. Can you double check whether this is a new problem with v0.87.x? Or does it also occur with v0.86.11?

It is not a regression actually. I've tested few madVR version back and the same results. So either I never noticed this (not likely) or AMD break something in drivers. Anyway sorry for interrupting regression hunt :)