madVR - high quality video renderer (GPU assisted)

[Soukyuu]

Originally Posted by michkrol

Open settings, left click any settings group (processing/scaling ...), click create profile group. I'm sure you'll work it out from there
When created, the profiles get switched automagically with your auto-select rules or by customizable key shortcuts. Be sure to read the help for auto-select rules scripting.

Thanks, I saw the "add new device" button, but not the "add profile" on the groups

I was holding off testing debanding until the final version, and man, does it make a difference. Though low seems to be the only non-destructive setting. What does the "don't analyze gradient angles" option affect? I didn't really see any difference

[huhn]

i just checked deint ms too they are high at start but after some time about the same like 86.9.

but while i was testing this is find a new bug introduced in 87.x.
when you change the deinterlacer mode with shift + control + alt + t i get - creating Direct3d Device failed (80070005) picture
one items it even switch to 8 bit color deep.
doesn't matter if film to video or video to film.

edit: works fine when change in the tray options strange but doesn't try to change resolution this way.

I was holding off testing debanding until the final version, and man, does it make a difference. Though low seems to be the only non-destructive setting. What does the "don't analyze gradient angles" option affect? I didn't really see any difference

it checks for parts that need debanding and didn't apply it to the hole image (very short version)

[Thunderbolt8]

OpenCL crashes (bluescreen) on a laptop with radeon 7650 with 13.12 drivers (leshcat drivers v3).

[madshi]

Originally Posted by HolyWu

Error Diffusion works on 327.23, but NNEDI chroma upscaling or doubling doesn't.

Originally Posted by Soukyuu

        dith | doubl | upsc
314.07:  yes |  yes  | yes*
314.22:  yes |  yes  | yes*
320.18:  yes |  yes  | yes*
320.49:  yes |  yes  | yes*
327.23:  yes |  yes  | yes*
331.58:   no | yes** | yes***
331.65:   no | yes** | yes***
331.82:   no | yes** | yes***
332.81:   no | yes** | yes***

  * yellow tint on 10bit h264 only
 ** no green channel (and no luma?) on 10bit h264 only
*** green tint on 10bit h264 only

Examples of yellow, green tints and missing green channel.

327.23 is the first driver officially released for win8.1, so I'm glad it works. Reverting to it until the issue is fixed.
Oh and... openCL dithering makes me drop frames, rendering queue is running out very fast. Same applies to all NNEDI3 features.
I guess my GPU is just too slow.

edit: openCL dithering also makes the ctrl+J osd an opaque black box.

@everyone: don't forget to mention your GPU when you report the results (or just put it in your sig)

Originally Posted by HolyWu

Tested GTX460 with drivers 327.23 and 331.40. Error Diffusion only works on 327.23, does not work on 331.40. NNEDI3 chroma upscaling and doubling don't work at all on both versions.

Originally Posted by cyberbeing

NVIDIA GTX 770 + madVR 0.87g

OpenCL Dither
R304 branch = Functional
R310 branch = Functional
R313 branch = Functional
R319 branch = Functional
R325 branch = Functional
R331 branch = Broken
R334 branch = Broken

OpenCL NNEDI3
R304 branch = Broken
R310 branch = Broken
R313 branch = Broken
R319 branch = Broken
R325 branch = Broken
R331 branch = Broken
R334 branch = Broken

R304 branch release tested = 309.00 (10/28/2013)
R310 branch release tested = 310.90 (12/29/2012) & 312.69 (10/28/2013)
R313 branch release tested = 314.22 (03/14/2013)
R319 branch release tested = 321.10 (12/05/2013)
R325 branch release tested = 327.23 (09/12/2013)
R331 branch release tested = 331.40 BETA (09/27/2013) & 332.21 (12/19/2013)
R334 branch release tested = 334.67 (01/15/2014)

Conclusion: NVIDIA R331 branch drivers and newer broke madVR display with OpenCL dither.

Originally Posted by PixelH8

^This. My own testing mirrors this exactly.

On my system with the 560 Ti, the last driver to have OpenCL error diffusion working is 327.23.
Every version after this is total FAIL. Something went very wrong indeed. Nothing in the release notes for 331.40 indicate any changes that would adversely affect OpenCL applications but who knows? Maybe whoever compiled the latest drivers forgot to flip the OpenCL switch.

On the plus side, Nvidia does make installing and uninstalling drivers as pain-free as possible, so there's that.

EDIT: I forgot to mention I was using the latest 0.87.1 build of madvr. Also, I'm not 100% sure if this is only a problem that affects Fermi cards and newer so I really have to get my GTS 250 system up and running to find out for sure. I also have a stockpile of drivers going back to 2009, so let the good times roll.

Thanks for doing all those testing, guys! It's interesting to see that some features work with some drivers and some GPUs. I "like" especially Soukyuu's results where NNEDI3 produces different color artifacts depending on source color space and driver version. That pretty much shows how unreliable NVidia OpenCL is. It doesn't even go from working to non-working, but seemingly the color channels are interpreted differently depending on driver version. That's a nightmare!

Originally Posted by Soukyuu

What does the "don't analyze gradient angles" option affect? I didn't really see any difference

Enabling it makes debanding stronger for image areas which are likely large gradiants, while keeping debanding strength the same for areas which probably contain image detail. Basically it should improve debanding strength where it's needed without losing a lot of additional detail in other image areas. It costs quite a bit of added GPU performance, though.

Originally Posted by pie1394

Regarding the Image Doubling function on the above 720x480i60 contents to 1920x1080p60 display mode, even HD7970 is not quick enough to handle 60fps. It needs more than 17ms (Debanding_with_AngleDetect + NNEDI3 2x + Jinc3AR) processing time vs 6.2ms (Debanding_with_AngleDetect + Jinc3AR)

Image Doubling doesn't have just one settings. How many neurons did you use? And did you tell madVR to double chroma resolution, too? Furthermore: If you do use image doubling, I'd recommend to use a cheaper follow-up algorithm for "image upscaling". E.g. use Bicubic50AR instead of Jinc3AR.

Originally Posted by DragonQ

Improved over 0.87. Hard to say whether it's really usable without the 10-bit chrome & image buffers. Certainly not better than 0.86.11. Average stats:

0.87.1 Software:
Deinterlace: 18.65 ms
Split: 18.85 ms
Rendering: 8.64 ms
Present: 0.42 ms
Dropped Frames: 63
Delayed Frames: 2

0.86.11 Software:
Deinterlace: 8.29 ms
Split: 9.15 ms
Rendering: 4.70 ms
Present: 0.17 ms
Dropped Frames: 14
Delayed Frames: 0

0.87.1 DXVA2 Native:
Deinterlace: 13.96 ms
Split: 16.53 ms
Rendering: 8.38 ms
Present: 0.41 ms
Dropped Frames: 4
Delayed Frames: 1

0.86.11 DXVA2 Native:
Deinterlace: 7.58 ms
Split: 8.08 ms
Rendering: 5.02 ms
Present: 0.16 ms
Dropped Frames: 8
Delayed Frames: 0

Using: HD4000, MPC-HC, LAV Filters, Smooth Motion, Bicubic75 Chroma upscaling, Catmull-Rom downscaling, playing 1080i/25 @ slightly under 1080p.

Originally Posted by pie1394

0.87.1 works fine on my HTPC, with HD7970 + Catalyst 13.12 -- Win7x64SP1. Just noticed the GPU's deinterlacing time is increased around 100%...

[720x480i60]
0.86.10 --> 0.83ms
0.87.1 --> 1.64ms

[1440x1080i60]
0.86.10 --> 1.44ms
0.87.1 --> 4.21ms

Originally Posted by noee

I notice the same thing using a 1080i video:

.86: Queues all full, no drops, deint=7.3ms
.87.1: Render and present queues struggle ~3-4, 50+ drops after 2 min of playback, deint=18.13ms

HD6570

Edit: Should add, this is a VC1 video using DXVA2 decode

Ok.

-------

So for all users who have:

(1) Stability problems (D3D9 error messages, freezing when switching video files in FSE mode etc).
(2) Performance issues with deinterlacing.

Please try the various test builds you can find here:

http://madshi.net/madVRtestbuilds.rar

Every test build reverts one change back to v0.86.11. This way hopefully we can identify which change is reponsible for which problem.

[cyberbeing]

Originally Posted by madshi

That pretty much shows how unreliable NVidia OpenCL is. It doesn't even go from working to non-working, but seemingly the color channels are interpreted differently depending on driver version. That's a nightmare!

This is NVIDIA's way of telling you to use CUDA, instead of depending on their automated OpenCL to CUDA driver translation functioning properly. As a bonus, you can actually debug and profile CUDA kernels on NVIDIA as well, while no such thing exists for OpenCL on NVIDIA.

[nevcairiel]

Originally Posted by madshi

Thanks for doing all those testing, guys! It's interesting to see that some features work with some drivers and some GPUs. I "like" especially Soukyuu's results where NNEDI3 produces different color artifacts depending on source color space and driver version. That pretty much shows how unreliable NVidia OpenCL is. It doesn't even go from working to non-working, but seemingly the color channels are interpreted differently depending on driver version. That's a nightmare!

Should've gone with CUDA, the API is much easier to use, too!
More importantly, I don't think NVIDIA (or quite possibly any other GPU vendor) cares much about such (tiny) compute use-cases.

[iSunrise]

0.87.1 is working great here (speed-wise it seems at least on par with 0.86.11, if not faster, haven´t tested with de-interlacing yet, though).

I found one bug though, which is reproducible every time:

1) enable smooth motion - enable always
2) play a video file
3) enter fullscreen-exclusive
4) leave fullscreen-exclusive and return to windowed mode
-> black screen
5) going back to fullscreen-exclusive the picture is back
6) leave fullscreen-exclusive again
-> black screen
...

GTX580, 331.82 drivers (quadro)

@madshi:
I don´t know if this is helpful for you, but on the 3dcenter-forum there is a member called Blaire, which seems to be part of the NV BETA Testing-Program and he seems to know a lot of various related (known) issues and he reports directly to them (driver related problems, primarily he reports game issues). He seems to be always up-to-date when it comes to new drivers, too. It seems that when he is reporting bugs directly, they have a very high chance to get fixed ASAP. That´s only an observation on my part though, I didn´t actually every have a conversation with him, since I never had serious problems, thankfully.

Also, if you tell him that a lot of the madVR users are going to consider switching to AMD in the future, because of the lackluster OpenCL drivers, NV may listen a bit more closely. Seems worth a try, at least. Not your problem if they cannot provide stable drivers for such things, anyway.

[cca]

CUDA though works exclusively and only on Nvidia, it's a proprietary interface. OpenCL isn't. Nvidia's attitude is forcing developers to support their own interface so they have to do double the work.

Sent from my Nexus 7 using Tapatalk

[noee]

Some more feedback....OpenCL...HD6570

I've been testing SD video (and interlaced) and film, upscaling to 1080, with the NNEDI Double Luma, 64neurons. I can't use secondary scaling options that use pixel shaders, but DXVA2 scaling works great in this case. I can still see some ringing around hair and people's heads, but it seems to be working very well, using about 25-30% less GPU than Jinc3/AR with SD film.

Edit: % perf numbers

[huhn]

So for all users who have:

(1) Stability problems (D3D9 error messages, freezing when switching video files in FSE mode etc).
(2) Performance issues with deinterlacing.

Please try the various test builds you can find here:

http://madshi.net/madVRtestbuilds.rar

Every test build reverts one change back to v0.86.11. This way hopefully we can identify which change is reponsible for which problem.

so all 6 didn't work all got the same error with switching video mode to film mode and all freeze/crash with fullscreen exclusive switching file.

BUT! after that 86.9 didn't work too at least the film video mode switching the error is different the player is completely crashing (bug report sending didn't work yet again) to fix this i have to reset all settings.

so i try all 6 again but this time i reset them all each time... and type the display modes in each time X-)

maybe just an problem with an registry entry?

[Soukyuu]

Originally Posted by madshi

Enabling it makes debanding stronger for image areas which are likely large gradiants, while keeping debanding strength the same for areas which probably contain image detail. Basically it should improve debanding strength where it's needed without losing a lot of additional detail in other image areas. It costs quite a bit of added GPU performance, though.

Hmm, so setting deband to say, "low", that option will increase it to "high" where needed?

As for nVidia's openCL, I guess I just have to be happy other openCL seems to function properly, i.e. flaccl still being lossless. But that kind of scares me to be honest. Maybe I'll go with AMD for my next GPU this iteration...

[madshi]

Originally Posted by cyberbeing

This is NVIDIA's way of telling you to use CUDA, instead of depending on their automated OpenCL to CUDA driver translation functioning properly. As a bonus, you can actually debug and profile CUDA kernels on NVIDIA as well, while no such thing exists for OpenCL on NVIDIA.

Originally Posted by nevcairiel

Should've gone with CUDA, the API is much easier to use, too!
More importantly, I don't think NVIDIA (or quite possibly any other GPU vendor) cares much about such compute use-cases.

That's all nice and fine. But think about the future, too. What if I add a dozen new features relying on computing? Am I really expected to create, debug and profile two versions of every kernel? It might not be twice the work, but it would definitely be a lot extra work. I'd really *REALLY* prefer to stick with one API. I'm considering to maybe at some point adding a full OpenCL rendering queue, dropping D3D9 rendering completely (just for GPUs which support it, of course). That would mean there would be several dozens of pixel shaders that need to be converted to OpenCL. Converting them all to OpenCL *and* CUDA would increase my workload quite a lot. So much that I might actually forget about the whole idea.

Originally Posted by iSunrise

0.87.1 is working great here (speed-wise it seems at least on par with 0.86.11, if not faster, haven´t tested with de-interlacing yet, though).

I found one bug though, which is reproducible every time:

1) enable smooth motion - enable always
2) play a video file
3) enter fullscreen-exclusive
4) leave fullscreen-exclusive and return to windowed mode
-> black screen
5) going back to fullscreen-exclusive the picture is back
6) leave fullscreen-exclusive again
-> black screen
...

GTX580, 331.82 drivers (quadro)

Everybody please, if you find a bug, always double check with v0.86.11 for now. I need to know which bugs are new bugs and which already existed in v0.86.11. I'm mostly only interested in fixing new bugs for now.

@iSunrise, if this issue did not occur in v0.86.11 (please double check), could you please also check the test builds I posted a couple posts above to see if any one of them fixes this problem or not? Thanks.

Originally Posted by noee

Some more feedback....OpenCL...HD6570

I've been testing SD video (and interlaced) and film, upscaling to 1080, with the NNEDI Double Luma, 64neurons. I can't use secondary scaling options that use pixel shaders, but DXVA2 scaling works great in this case. I can still see some ringing around hair and people's heads, but it seems to be working very well, using about 12-15% less GPU than Jinc3/AR.

Unfortunately if you activate DXVA2 scaling, NNEDI3 is not used at all. Sorry, should have said so. But it would be technically quite difficult to combine NNEDI3 and DXVA2 scaling. Try NNEDI3 for Luma only + Bilinear.

[noee]

haha! Yes, that explains a lot.....

Okay, I see, yeah. I can only run 32 neurons with Bilinear without drops, but it works, GPU is >80%.

[madshi]

Originally Posted by huhn

so all 6 didn't work all got the same error with switching video mode to film mode and all freeze/crash with fullscreen exclusive switching file.

BUT! after that 86.9 didn't work too at least the film video mode switching the error is different the player is completely crashing (bug report sending didn't work yet again) to fix this i have to reset all settings.

so i try all 6 again but this time i reset them all each time... and type the display modes in each time X-)

maybe just an problem with an registry entry?

So what is the final conclusion? I'm not sure right now. Is this a new problem with v0.87.x or is it not?

Originally Posted by Soukyuu

Hmm, so setting deband to say, "low", that option will increase it to "high" where needed?

Not to "high" maybe, but quite a bit higher than "low". But don't expect perfection.

Originally Posted by Soukyuu

As for nVidia's openCL, I guess I just have to be happy other openCL seems to function properly, i.e. flaccl still being lossless. But that kind of scares me to be honest. Maybe I'll go with AMD for my next GPU this iteration...

If you want OpenCL support, AMD is the better option at the moment. Many of the problems I've having are with the D3D9 <-> OpenCL interop, though. Which most applications don't need. So probably for normal use causes you're safe enough with NVidia. OpenCL performance is probably not as good as AMD, though, compared to how your NVidia GPU compares to AMD in game performance.

[Ziron]

Couldn't NNEDI3 be written as an OpenGL shader? That would probably cause less compatibility issues. It would also have the side effect of making it useable by emulators.

[sneaker_ger]

I'm also having trouble with the FSE image freezing (but sound playing on normally) when skipping to a new file/restarting the file.

http://www.file-upload.net/download-...w-file.7z.html

1. start file in windowed mode
2. go into FSE and play file for a few seconds (everything's normal up until here)
3. restart video via ctrl+e (->current image freezes)

Win 7 x64, MPC-HC 1.7.1.383, madvr 0.87.11

===

A question regarding the settings dialogue outside of playing a file: is it normal that it takes a few seconds to open compared to instantly when playing a file? Is it waiting for an answer of open madVR instances and assumes there is none after waiting a bit?

[iSunrise]

Originally Posted by madshi

@iSunrise, if this issue did not occur in v0.86.11 (please double check), could you please also check the test builds I posted a couple posts above to see if any one of them fixes this problem or not? Thanks.

Switching while smooth motion is on works fine in 0.86.11 and in all of your test builds, too. I found the problem though and it´s not smooth motion related at all.

It seems that simply enabling OpenCL related things like image doubling in it´s current form on NV can lead to the NV drivers behaving abnormally, even after shutting down every related player process or madVR entirely and that doesn´t seem to go away if you don´t restart the system. So any OpenCL testing currently could lead to false positives with other madVR functionality. Just as a heads-up.

After a system restart, 0.87.1 works just fine in that regard. Sorry for the wasted time, but I didn´t expect this weird NV driver behaviour at all. They are usually not that error prone and very reliable.

[noee]

Originally Posted by madshi

Every test build reverts one change back to v0.86.11. This way hopefully we can identify which change is reponsible for which problem.

No diff with any of the 6 builds with the deint speed, all hover between 18-22ms for this 1080i VC1 (DXVA2 decode) file I'm using.

[huhn]

i only report problem with 87.x so yeah i can get it working with 86.11 (i just switch to this sup version)

i just finished testing all 6 again all crash with 70080005 error.

yet again after this i toke the madVR08611.zip from videohelp override alle datas from 87.1 and it didn't work to the player crashed again every thing was at default except the display mode i added : 1080p23, 1080p24, 1080p50, 1080p59, 1080p60

then i started the restore default settings.bat added 1080p23, 1080p24, 1080p50, 1080p59, 1080p60 and it works fine now so the error with film-video has something to do with the madvr settings.

i tested all 6 .ax with 87.1 with uninstall install and reset.

but the freeze problem doesn't happen with 86.11 and settings from version 87.1

[madshi]

Originally Posted by sneaker_ger

I'm also having trouble with the FSE image freezing (but sound playing on normally) when skipping to a new file/restarting the file.

http://www.file-upload.net/download-...w-file.7z.html

1. start file in windowed mode
2. go into FSE and play file for a few seconds (everything's normal up until here)
3. restart video via ctrl+e (->current image freezes)

Win 7 x64, MPC-HC 1.7.1.383, madvr 0.87.11

Please try the test builds I posted a few posts above.

Originally Posted by sneaker_ger

A question regarding the settings dialogue outside of playing a file: is it normal that it takes a few seconds to open compared to instantly when playing a file? Is it waiting for an answer of open madVR instances and assumes there is none after waiting a bit?

It opens instantly on my PC.

Originally Posted by iSunrise

It seems that simply enabling OpenCL related things like image doubling in it´s current form on NV can lead to the NV drivers behaving abnormally, even after shutting down every related player process or madVR entirely and that doesn´t seem to go away if you don´t restart the system. So any OpenCL testing currently or in the future on NV could lead to false positives with other madVR functionality. Just as a heads-up.

After a system restart, 0.87.1 works just fine in that regard. Sorry for the wasted time, but I didn´t expect this weird NV driver behaviour at all. They are usually not that error prone and very reliable.

Ouch...

Originally Posted by noee

No diff with any of the 6 builds with the deint speed, all hover between 18-22ms for this 1080i VC1 (DXVA2 decode) file I'm using.

That's weird! I wish I could reproduce that here...