madVR - high quality video renderer (GPU assisted)

[madshi]

Originally Posted by huhn

the big point was that Philips pc mode works with all refresh rate. and the information is still easy to find in the manuels.

Does every Philips TV support PC mode with all refresh rates?

Originally Posted by tFWo

Error Diffusion performance is highly dependent on having Smooth Motion turned on.

I don’t know if this is the correct behavior. ED is applied after SM, so the performance hit is massive if you are doing 24->60. Is it necessary to dither after SM or it can be done before it?

You're right that SM FRC increases the cost of Error Diffusion quite a lot. There's nothing I can do about it. Either I apply Error Diffusion or I don't apply it. Applying it only to some frames doesn't make so much sense. Depending on source frame rate and display refresh rate, every frame could potentially blended. So it doesn't make sense to only apply it to the non-blended frames, either...

Originally Posted by coolcat

Queues are not always full, but no frames are dropped.
Is it a normal result?

What does "not always full" mean exactly? As long as playback is smooth and no frames are dropped, everything seems to be ok. If queues go near empty sometimes that's not so good, though. They don't necessarily have to be full, but they should be far enough away from empty to be safe...

Originally Posted by turbojet

It works fine in FSE and overlay, problem only in windowed mode. It happens on all videos with the same scenario. It could be a gpu load issue, goes from 55% to 60% after enabling frc.

Yes, smooth motion FRC is problematic in windowed mode. I've found that in windowed mode the max rendering times must be lower than the vsync time. Meaning with 60Hz, max rendering times must be smaller than 16.68ms. Otherwise playback will judder, even if no frame drops are recorded. In FSE mode, the situation is different. There rendering times only need to be smaller than the frame interval (e.g. 41.71ms for 24fps). There is probably nothing I can do about it. That's simply a limitation of D3D in windowed mode.

Originally Posted by ryrynz

On the one hand NNEDI gives beautiful sharp edges but does so at the expense of thinning things out a little more than they should be on these edges.

Actually NNEDI does not thin out lines enough yet, I think. Try taking a high resolution image, then downscale is to 50%, then upscale it with NNEDI. I believe you'll find that NNEDI still has slightly fatter lines than the original high-res image sometimes.

Originally Posted by omarank

Can you try this script?

if (deintFps > 24.5) and (deintFps < 25.5) "Off"
else "On"

Are we talking forced film mode? With forced film mode disabled, deintFps will be around 50.0 for PAL content.

Originally Posted by The 8472

• GTX 760
• Smooth motion on
• 60Hz
• doubling 720p -> 1440p with nnedi 32 neurons
• 2560x1440 display

random dithering: 51-55% GPU load
error diffusion: 90+% load, occasional frame drops

That's probably due to the combination of using Smooth Motion FRC and Error diffusion. Using both means that Smooth Motion FRC increases the cost of Error diffusion, because Error diffusion must be applied to every output frame, and Smooth Motion FRC increases the output frames from 24fps to nearly 60fps. So basically Smooth Motion FRC means that the cost of Error diffusion increases by a factor of almost 2.5x.

Originally Posted by The 8472

Have you considered using void and cluster ordered dither instead of error diffusion? It would only require a lookup table instead of inspecting neighboring pixels. That might be more shader-friendly.

I don't think it's as high quality as error diffusion?

Originally Posted by omarank

Is the performance hit with error diffusion due to OpenCL implementation or the algorithm itself?

The algorithm itself seems to be quite fast. About 2.5ms per 1080p frame on my HD7770. The majority of the cost comes from using OpenCL <-> D3D9 interop, at least when using AMD. On Intel GPUs interop is almost free, but the Intel GPU itself is rather slow with OpenCL. I don't about NVidia.

Originally Posted by cyberbeing

Relatively speaking, the OpenCL error-diffusion dither has the same cost at 1080p 24hz as Jinc4|AR Luma + Jinc4|AR Chroma 1280x720 -> 1920x1080 scaling + Random Dither. Overall I'd say it's probably the second most expensive thing in madVR behind NNEDI3 now, considering it's a couple ms slower than NNEDI3|16 1280x720 -> 2560x1440 display. At least that's the case with my GTX 770.

Is that with smooth motion FRC enabled? That is quite important to note, because it increases the cost of Error diffusion by a factor of about 2.5x.

Originally Posted by cyberbeing

Yes, I'd say its more true to the source, but the dither quality feels somewhat questionable on less than pristine sources. From what I can tell, it only does a hard mix of existing source colors, lightness, hues. For example, I saw it create a dither comprising dark specks on a light surface. Similarly I've seen it hard mix red specks and green specks in a pattern. While this works to some extent perceptually, it seems like it would be superior if the dither created new colors to better assist in creating smooth transitions.

Currently I'm doing Error diffusion in RGB. Maybe doing it in YCbCr would produce nicer results, I'm not sure. Other than that I don't have an algorithm which would spreads errors over multiple color channels. All the algorithms I know strictly work on one channel at a time, only.

Originally Posted by leeperry

My only current problem is that I've set mVR to automatically roll refresh rates when going FS and when going from 1080p60 windowed to 1080p24/50 FSE, I randomly get an "Exclusive mode failed" error message in the top left corner of mVR...and no FSE for me

It seems completely random so I'm not sure wth is going on here? Would you care for a log?

This does not sound like a new bug in v0.87.4, and that's all I care about atm. Also, most other users don't seem to have the problem you're describing. Not sure where it comes from.

Originally Posted by leeperry

I've checked the windows event viewer and it seems that PotP asks Windows to disable Aero before going FSE, is that part of the standard FSE procedure?

I've also tried to disable Aero when going FS in the mVR settings but then FSE didn't work anymore.

If PotP disables Aero behind madVR's back, that could eventually cause trouble, I don't know. I don't like it if media players try to be clever. Video playback is madVR's job, and PotP should the hell stay out of madVR's business...

Disabling Aero in madVR should not stop FSE mode from working. Maybe it collides with what PotP does, I don't know. I've not heard of such problems from MPC-HC users. Maybe you could double check with MPC-HC, just to be sure it's not media player related?

Originally Posted by leeperry

No 3D support, 4:4:4 only in 60Hz. 24p is dead smooth, though

IIRC only their "6" serie in the 2013 F lineup will allow for 3D but only the "5" serie allows for BFI without FI.......Sammy's FI hiccups on 24p and doesn't look all that good, OTOH their BFI provides the nice added value of removing motion blur and most visible flicker. I'm very sensitive to flicker BTW.

I don't think I need BFI. I don't plan to actually use the monitor for real movie watching, just as a monitor, and of course for madVR development testing. For that the monitor needs to support all features I need for testing, but it doesn't actually need to have a good quality video playback. It should have good quality monitor properties, though.

Originally Posted by petran79

with version 0.87.4, if I enable NNEDI3, video doesnt freeze, but I get green color levels all over the video image.
Probably because its Nvidia.

If it was AMD, I'd get red color levels.....

Haha! Did you read the v0.87.4 announcement, though? It says you need to downgrade your drivers.

Originally Posted by GCRaistlin

Why the picture with madVR is so dark compared to other renderers?
VMR9 renderless
madVR

That's probably just a different output levels setting. You can configure the output levels in madVR's device management. Switch your display to TV levels, if that's what it wants for correct playback levels.

[cyberbeing]

Originally Posted by nevcairiel

There should only be one dithering process, which reduces the internal 16-bit floating point pixels down to 8-bit integer, and this should be done as the very last step, because the output of this process is in much lower bitdepth, namely 8-bit pixels.

My memory must be failing me then. I could have sworn that madVR performed dithering during other conversions which could result in accuracy loss, before the final dither down to 8bit.

[madshi]

Originally Posted by fairchild

Has anybody noticed if there is a visible quality difference between using 32 neurons vs 64 neurons to double Luma resolution with NNEDI3, since in several of my media files it's the difference between increasing/decreasing the rendering times to prevent frame drops.

There's a nice step up in quality from 16 to 32 neurons with some images. Every higher neuron setting increases quality a little bit, but not *that* much. 32 neurons should be fine. Unlike with Lanczos, where more taps often hurts more than it helps, with NNEDI3 more neurons usually have no disadvantages, other than performance. So more neurons shouldn't hurt, if your GPU can handle it. But IMHO 32 neurons are alright.

Originally Posted by asmo42

While playing around with different image doubling/quadrupling and scaling settings I think I've discovered a bug, unless I'm misunderstanding how it's supposed to work.

If I use NNEDI3 to double a 1280x720 video for output at 1080p it's my understanding that since the doubled resolution is higher than the output resolution no further image upscaling should be necessary. Only the image downscaling algorithm should scale it down to output resolution. However I noticed that the image upscaling setting still affects render times pretty much in the same way as if I didn't do any doubling before. If I switch between two extreme settings like Jinc 8 tap AR and Bicubic the rendering times change dramatically from something like 40 to 60 ms which should be way beyond any margin of error.

You probably only have enabled NNEDI3 doubling for luma, right? In that case the chroma channels are upscaled using the "image upscaling" algorithm. That's the explanation for what you're seeing.

Originally Posted by bjd

Can anyone elaborate what MadVR currently does with 720x576 to produce 1920x1080 using NNEDI - Does NNEDI produce 1440x1152 which then has to be downscaled and then upscaled to fit 1080p ?

Depends on the exact settings in the image doubling page. 1920/720 = 2.67x. 1080/576 = 1.875x. So X and Y have quite different scaling factors. Depending on your image doubling settings it's possible that only X is doubled by NNEDI, or X and Y.

Originally Posted by mimi123

It's best new series of ATI R7 and R9 or is the same as HD7000?

I do not want to buy now one card and having to buy another one next year?

I'm reading reviews but this point is not clear for me. They says R7 and R9 series are manufactured with the same chips of HD7000 but have more functions. I don't understand.

I'm not sure if the new series of ATI GPUs have new technical abilities or not. If you're happy with the current algorithms I don't see a reason why you should have to buy another GPU next year. Of course if I add more algorithms in the future, you may want to use those, too. But then the 7750 should already have some more power than you need right now. But I don't know what future algorithms I might add and how much performance they will eat. So I can't promise that the 7750 will be fast enough a year from now. Maybe it will be. Maybe even a 7970 will not be fast enough. I don't know. Can only say what is fast enough for today's features.

Originally Posted by leeperry

BTW, I presume that "always - if upscaling is needed" should read "if scaling is bigger than 1.0 and lower than 2.0" for 2X luma and "if scaling is bigger than 2.0" for X4 luma?

Yes. Although quadrupling requires doing doubling first. So the double "always" option just means "bigger than 1.0".

Originally Posted by Soukyuu

I kind of don't see any difference between openCL dither and random dither, except for dropped frames :P
Tried dark and light scenes and both seem identical both when paused and playing.

Don't see any difference on my computer monitor, too, except if I take screenshots and zoom in. I do see a lower noise floor on my projector, though. It all depends on how big your display is, how far away you sit, and how sensitive to noise you are.

Originally Posted by sgraves66

As of v0.87.4, I've been experiencing issues with IVideoWindow::SetWindowPosition(). v0.86.11 and prior have been working fine. It appears that madVR does not consistently respond to each request to set position - video no longer displays, although playback continues, leaving artifacts in the child area as if no painting has occurred. The main window has to be re-sized a few times for it to display again.

Have these implementations changed or should I be using another method for positioning madVR child window?

Nothing has changed there, as far as I'm aware. And all the other media players seem to have no problems with v0.87.4, without any code changes, so I don't really know what problems you've run into...

I did slightly modify some window subclassing code to make it more stable, but that shouldn't really affect media players.

Originally Posted by cyberbeing

Otherwise madshi, you really need to consider modifying the workflow so OpenCL dither is applied before Smooth Motion at original video framerate rather than after at double framerate w/ blended frames.

Proper blending produces floating point RGB data. That needs to be dithered down to 8bit.

Originally Posted by Gagorian

Is it normal that OpenCL error diffusion increases average rendering time 3x? My GPU is a r9 270 (basically a 7870?) and using latest madVR.

I tried playing a few 1080p24 standard x264 blu-ray movies presented at 23.976 Hz.

Average rendering time (using Jinc 3 AR for both Luma and Chroma, Debanding low, all trade quality for performance options except OpenCL error diffusion disabled) was around 8-10 ms. The rendering time is about the same for 720p movies, so scaling for instance is rather cheap even with Jinc 3 AR.

With OpenCL error diffusion the average rendering time was raised to around 28-30 ms.

Should it really be that demanding?

Is smooth motion on or off? What is your display resolution? On my PC the cost of Error diffusion seems to be quite a bit lower than on yours, even though I only have an 7770. Is your display resolution much higher than 1080p, maybe?

Originally Posted by DragonQ

Reports so far suggest that OpenCL Error Diffusion is indeed very demanding. Can't imagine most people can even use it.

Please STOP saying that!! I already corrected you in this post:

http://forum.doom9.org/showpost.php?p=1664877&postcount=22144

The cost of Error Diffusion seems to differ a lot, depending on the exact settings (e.g. Smooth Motion FRC increases it a lot), the GPU, the monitor resoultion and frame rate. I can use it without any problems on my PC, with an HD7770, when playing back 1080p24 content without smooth motion FRC. The exact circumstances when it consumes how much have yet to be fully understood. It's too early to draw conclusions, especially such general unspecific onces as you just did (again).

Originally Posted by cyberbeing

It's partially a matter of perspective I believe. madshi's numbers showed it increased his relative render times by 400% when he enabled OpenCL dither compared to his previous settings. This could likely be interpolated into 400% higher GPU load and power draw. That said, I have no doubt it will perform well on AMD Southern Islands based GPUs, since that's what he optimized it for.

Argh.

It's 400% because I was playing content without any scaling and with cheap chroma upscaling. So the original rendering times were very low. If I had done upscaling with Jinc8AR, the increase of the rendering times caused by Error Diffusion might have been only 1% (wild guess). Does that mean anything? No. The only thing that is important is the number of milliseconds Error Diffusion takes to process a frame, not how much percent the increase is over some random rendering times with random settings.

And I've not optimized the Error Diffusion algorithm for any specific GPU. I've tested it with all AMD, Intel and NVidia and the code is pretty simple. So simple actually that no GPU specific optimizations made sense. The optimizations I did were very general, like trying to get along with just using registers and without using any memory accesses and stuff like that...

Originally Posted by iSunrise

madshi, I have a bug to report with 0.87.4 (yes, finally, the week end nears, so I have more time to test):

There´s something wrong with chroma upscaling, even when using the Nvidia 327.23 drivers, as I get a yellow/greenish image instead of levels of grey (not sure if this is only NV related, don´t have an AMD at my disposal atm) when you enable chroma upscaling and you choose NNEDI3.

Steps to reproduce is pretty easy, just enable chroma upscaling NNEDI3 and it should show in windowed mode or in FSE. It also doesn´t matter how many neurons. I really hope this isn´t exclusively NV-related again, because this is using OpenCL.

For some reason, this is only happening on some files, example:
http://www.w6rz.net/filmrez.zip

This is with a GTX580 with the last working OpenCL drivers as of today (327.23).

Doesn't seem to happen with my GTX 650, using 327.23...

Originally Posted by iSunrise

I still cannot see an error in my code though, does anyone see a problem? If not, is this a bug madshi?

I don't know. You didn't say which kind of videos (resolution, framerate) you tested with.

[madshi]

Originally Posted by cyberbeing

My memory must be failing me then. I could have sworn that madVR performed dithering during other conversions which could result in accuracy loss, before the final dither down to 8bit.

There's normally only the one last final dithering during the downconversion to the final 8bit output. If you want to do DXVA2 deinterlacing, though, and if the source video is more than 8bit, then another dithering pass is needed to convert the video to 8bit to satisfy DXVA2.

[huhn]

Originally Posted by madshi

Does every Philips TV support PC mode with all refresh rates?

they are known for very good pc mode. and all i used/setup got that. i never heard of a Philips with only 60 hz pc mode. i didn't test them all so i can say that for sure.

but my Philips got a "problem" with pc mode too it is reported as limited but it's unlimited. i saw this with all philips tv i ever used since 2010. but i'm sure this is nothing you can't handle.

how about using SM with the 8 bit ED picture this reduce quality but is way way faster.

ignore this too many post at the same time sorry.

[Werewolfy]

Originally Posted by madshi

I suppose you're only doubling the luma channel and not the chroma channels? In that case Jinc might be used to upscale the chroma channels directly from 720x576 to 1920x1080. Luma can't be upscaled by Jinc for Y because it would be a downscale. So luma X is upscaled by using Lanczos (using the same tap number you specified for Jinc), and luma Y is downscaled using Catmull-Rom. Lanczos always replaces Jinc if Jinc is selected but can't be used.

Yes only the luma chanel, I don't really see the point to use NNEDI3 for chroma upscaling. Thanks for the explanation, I didn't know that Lanczos replace Jinc when it's needed.

Originally Posted by madshi

Does every Philips TV support PC mode with all refresh rates?

No, some Philips TV don't even support 4:4:4 http://www.hdtvtest.co.uk/news/phili...1309193320.htm (see the benchmark results)

Have you considered this one? http://www.hdtvtest.co.uk /news/kdl32w653-201310313413.htm It supports 4:4:4 at every refresh rates and it has everything except 3D, I don't know if it's a requirement for you.

[Farfie]

This is without error diffusion.

Something tells me AMD performance isn't nearly this bad. I don't see how I could ever do 4k upscale like this at anything above 16 neurons. Is this expected? I'd be willing to bet, from the reports in this thread, that AMD performance is much better.
Not trying to complain at all, but I love NNEDI3 and I'd also love to always use it for upscaling at at least 32 neurons, and I feel like a 680 should be able to do so much more.

[trip_let]

Quick questions:

1. Anybody else seeing this have Optimus (generally on laptops) Nvidia / Intel setup? I don't really think a GT 650M is fast enough for most of the OpenCL features anyway, but I want to confirm if it doesn't work for anyone else either or it's just me being dumb somewhere or somehow.

2. When downgrading drivers to make Nvidia work (non-Optimus too), do you have to perform a clean installation? That's one thing I haven't tried yet, partially because part of my Nvidia settings involve that renaming MPC-HC workaround to make the system choose the Nvidia GPU for the program in the first place...

[iSunrise]

Originally Posted by madshi

Doesn't seem to happen with my GTX 650, using 327.23...

I tried to narrow it down further, it seems to be related to the deinterlacing/NNEDI3 settings (the clip itself is interlaced) and madVR uses IVTC/deinterlacing for it. Please always test with filmrez.ts.

So, for some reason NNEDI3 triggers that same problem, when deinterlacing is at some specific settings.

Please play around with the following:

1) automatically activate deinterlacing when needed (checked)
1.1) if in doubt, deactivate deinterlacing (checked)
- don´t check anything else in the deinterlacing tab -
2) enable NNEDI3 chroma upscaling
3) if you now suddenly check automatic source type in the deinterlacing tab, the bug goes away (grey levels instead of yellow)
4) If there´s no bug at this stage, enable/disable NNEDI3 chroma upsampling again
5) If there´s no bug at this stage, enable/disable deinterlacing again

My system is very clean, only LAV and madVR in the filter chain. I only downgraded to the 327.23 drivers from the 331.82 drivers and directly upgraded from 0.86.11 to 0.87.4. Nothing else changed.

Originally Posted by madshi

I don't know. You didn't say which kind of videos (resolution, framerate) you tested with.

I have played a 1080p 59.940fps file where the "1080p LowFPS" profile was always selected, even though it´s clearly higher than 50fps, that´s when I realized it. Whatever I played after it, the original script was always picked and I could reproduce it with every file that normally shouldn´t select the "1080p LowFPS" profile. If I use the corrected script, everything works as expected.

EDIT: After a system restart, for some reason I cannot reproduce this bug anymore. This is very weird, since I´ve tested this for like 20 minutes (I went back and forth only between <= 50 and < 50 and > 50 and >= 50) and wrote the post. Now, both scripts suddenly work. Difference is that I actually wrote the script before the restart (where madVR changed the status of checked/unchecked all the time) and played some files while writing it. Now I didn´t change anything in the scripting fields, except for cutting/pasting and playing a sample file. There still must be a bug, but I cannot seem to reproduce it now.

Now I know how you felt, since bugs in 0.87.4 are a pain to reproduce. So many useful features.

[DragonQ]

Originally Posted by madshi

Please STOP saying that!! I already corrected you in this post:

http://forum.doom9.org/showpost.php?p=1664877&postcount=22144

Just because it's not that demanding for you on your rig doesn't mean it isn't in general, which you seem to admit in your next sentence:

Originally Posted by madshi

The cost of Error Diffusion seems to differ a lot, depending on the exact settings (e.g. Smooth Motion FRC increases it a lot), the GPU, the monitor resoultion and frame rate. I can use it without any problems on my PC, with an HD7770, when playing back 1080p24 content without smooth motion FRC.

Exactly. Smooth Motion seems very popular with PC monitor users, yes? IIRC even the best Intel CPUs can't use it and even with your decent AMD card you can't use it with Smooth Motion, right? Dunno about nVidia. Surely that leaves a minority of hardware combinations where it would be feasible? Maybe we have a different definition of "demanding". I forgot about the new profiles though, I suppose they mean more people can use it for some video types.

Originally Posted by madshi

The exact circumstances when it consumes how much have yet to be fully understood. It's too early to draw conclusions, especially such general unspecific onces as you just did (again).

I didn't conclude anything madshi, I used the word suggest.

[cyberbeing]

Originally Posted by madshi

Is that with smooth motion FRC enabled? That is quite important to note, because it increases the cost of Error diffusion by a factor of about 2.5x.

Smooth motion disabled. I believe I was comparing total GPU utilization, rather than render times.

Why did I care about GPU load measurements instead of madVR render times? I was in the process of tuning madVR's OpenCL settings to a level of heat, power draw, noise, and quality which I found acceptable for general use.

Originally Posted by madshi

Currently I'm doing Error diffusion in RGB. Maybe doing it in YCbCr would produce nicer results, I'm not sure. Other than that I don't have an algorithm which would spreads errors over multiple color channels. All the algorithms I know strictly work on one channel at a time, only.

That's unfortunate. It may be worth trying it on YCbCr, or maybe even better converting RGB -> L*a*b* channels and doing error-diffusion dither on that.

[leeperry]

Originally Posted by madshi

If PotP disables Aero behind madVR's back, that could eventually cause trouble, I don't know. I don't like it if media players try to be clever. Video playback is madVR's job, and PotP should the hell stay out of madVR's business...

Disabling Aero in madVR should not stop FSE mode from working. Maybe it collides with what PotP does, I don't know. I've not heard of such problems from MPC-HC users. Maybe you could double check with MPC-HC, just to be sure it's not media player related?

I've decided to disable Aero altogether as I don't care for Aero peek or tearing with windowed videos and yet the problem remains.

Basically, if I set mVR to automatically roll refresh rates when playback starts then everything's fine but if I set it to roll refresh rates when going FS then FSE is more likely to fail. Actually I can easily reproduce the problem if I wait for mVR's OSD to appear and instantly switch to FS.....then I get this in mVR's logs:

00003601 Render   COsd::DisplayMessage(self: 0C9D1FB8, message: exclusive mode failed, milliseconds: 2000)
00003601 Render   CQueue::IsStillImage();
00003601 Render   CQueue::IsRunGraphWhenQueueFull(self: 0C9F4188) -> no
00003601 Render   CQueue::IsStillImage() -> no
00003601 Render   COsd::DisplayMessage(self: 0C9D1FB8) -> +
00003601 Render   CDirect3D::ResetDevice(self: 0C9D01E0) -> switching to fullscreen failed (8876086c)

I've taken the liberty of uploading some working and failing logs at PotP+mVR.rar (864 KB)

I've tried hard but I can't get MPC-HC to fail.

Originally Posted by madshi

This does not sound like a new bug in v0.87.4, and that's all I care about atm. Also, most other users don't seem to have the problem you're describing. Not sure where it comes from.

This worked perfectly fine on XP with 0.86.9, the same latest stable build of PotP and the newest AMD drivers

I wouldn't know whether it's a new problem as I only migrated from XP a few days ago and I don't think there are many mVR users here on d9 who run the same W7SP1 / PotP with its GUI set to D3D / HD7850 combination and set FSE to trigger when going FS.

Originally Posted by madshi

I don't think I need BFI. I don't plan to actually use the monitor for real movie watching, just as a monitor, and of course for madVR development testing. For that the monitor needs to support all features I need for testing, but it doesn't actually need to have a good quality video playback. It should have good quality monitor properties, though.

Well, I think the BenQ GW2760HS might be right up your alley......it's so easy on the eyes, just amazing. And its 72/75Hz are smooth as butter. It would also supposedly support even more(the GW2760HM will go right up to 1080p@85Hz over SL-DVI) if you apply this hack: http://www.monitortests.com/forum/Th...-Clock-Patcher

Finding a 32" 3D capable TV that will do 4:4:4 at all refresh rates will take a lot of trial & error IMHO.

[Andrey /MAG/]

nnedi3 doubling makes picture very dark when I use the last NVIDIA WHQL driver 332.
I have tested it on Quadro 600 and on GTX 660 Ti.

[asmo42]

Originally Posted by madshi

You probably only have enabled NNEDI3 doubling for luma, right? In that case the chroma channels are upscaled using the "image upscaling" algorithm. That's the explanation for what you're seeing.

You're right that's it. I was under the impression that if I did luma doubling beyond the output resolution it would be the "chroma upscaling" setting that controlled all the chroma upscaling and the "image upscaling" setting wouldn't have any effect. But I realize now that's not how it works. After re-reading the thread again I saw the quote below which explains everything. Sorry for taking up your time.

Originally Posted by madshi

The "chroma upscaling" settings are only for 4:2:0/4:2:2 to 4:4:4 conversion, for nothing else. Once 4:4:4 is reached, all other scaling operations are decided by "image doubling/upscaling/downscaling" options.

[sajara]

Originally Posted by leeperry

Madshi said that it wasn't all that demanding on his 7770(or was it 7790?) and I can confirm that it's a breeze on my factory overclocked 7850.

Originally Posted by DragonQ

Just because it's not that demanding for you on your rig doesn't mean it isn't in general

I can only say that with my test video H264 720x404 25fps with HD5730M:

upscale settings
chroma: lanczos 3 taps
image: jinc 3 taps
debanding: low
fade: high

laptop monitor res:1366x768@60hz
FSE: on
smooth motion: off

random dithering: rendering 13.84ms/gpu 43%
OpenCL error diffusion: rendering 28.36ms / gpu 70%

I think it scales very nicely for a low end mobile GPU upscaling to a bit over HD res.

One thing I must note is that when I moved from Win 7 to 8 I noticed vast improvements on seeking times with lav+madvr and much better performance switching from FSE to desktop. Maybe and just maybe that can make a difference in overall performance.

[JarrettH]

Is it worth it to have debanding on the low setting all the time? I don't watch animation very much, just good quality films. I can think of instances where I might have seen banding (light sources, logo fades), but it wasn't that severe

[cyberbeing]

When playing around with the NNEDI3 doubling on 720p anime viewed at 1080p, I came to the conclusion that 32 neurons is not worthwhile. You don't get a big step-up in edge quality from 16 neurons until you use 64 neurons.

Originally Posted by madshi

That said, I recommend not to go lower than 32 neurons for luma upscaling, because 16 neurons leaves too many artifacts in the image for my taste with *some* videos.
....
I wouldn't go lower than 16 for doubling, unless your GPU absolutely can't handle 32 neurons and you still prefer NNEDI3 with 16 neurons over Jinc/Lanczos.

But this interests me. Could you expand on the *some* videos which have artifacts using NNEDI3 16 neurons? Better yet, take a PNG screenshot of the source video at original resolution so I can test myself in madVR.

Does source resolution and quality matter? Have you actually see these artifacts doing 1280x720 -> 2560x1440 or 1920x1080 -> 3840x2160 scaling?

Originally Posted by madshi

In my tests I've found little reason to enable NNEDI3 for the chroma channels. So I would recommend to leave the right side of the image doubling settings page unchecked.

My testing agrees with this. NNEDI3 image doubling for chroma doesn't seem to be worth it, at least until you've hit at least 64 neurons for luma doubling.

One addition though. The 'chroma upscaling' setting for NNEDI3 does have a noticeable impact on chroma quality, especially when dealing with DVD resolution content and below. I'd consider it worthwhile for at least SD content if you can afford it.

Originally Posted by cyberbeing

No, it's an added cost.
Open GPU-Z. If OpenCL is not checked, then you've broken OpenCL support in the driver.

You mean using previous version nvopencl.dll with newer drivers will make OpenCL box un-ticked, right? Because with 344.67 drivers with 344.67 nvopencl.dll files my box IS ticked, but black screen goes black.

I wonder if its possible to edit that file verificaiton you are talking about. Just how deeply are OpenCL drivers integrated with regular drivers? I'm sure with some time and patience its possible to force drivers to use the older nvopencl.dll files...

[Audionut]

Well I was getting by with just an Intel i7 2600k with onboard GPU, until all these new features turned up.
Turns out I was actually getting the odd frame drop with none of the quality stuff turned on, resizing all being done as bilinear and using a 3dlut as described here: http://www.avsforum.com/t/1471169/madvr-argyllcms
I was even using a heap of the quality tradeoffs.

Bit the bullet and got an HD 7790.

Now I have none of the quality tradeoffs enabled, debanding enabled, NNEDI3 (32 neurons) chroma upscaling and it purrs like a kitten. This is in 24.976 playback as I prefer the odd motion judder to the current smooth motion algorithms.

One thing I am not entirely certain of, the rendering times drop when I output 16bit 4:4:4 from LAV, I assume this is because LAV is doing some of the processing? I also assume it's best to just output 8bit 4:2:0 from LAV and let mVR do all the grunt work?

edit: Ok seems better to output 4:2:0 from LAV and give control to mVR. What about the bit depth though?

[cyberbeing]

Originally Posted by XMonarchY

You mean using previous version nvopencl.dll with newer drivers will make OpenCL box un-ticked

Yes, that's correct.

Originally Posted by XMonarchY

I wonder if its possible to edit that file verificaiton you are talking about. Just how deeply are OpenCL drivers integrated with regular drivers? I'm sure with some time and patience its possible to force drivers to use the older nvopencl.dll files...

Who knows, but considering madshi has stated that OpenCL <-> D3D9 interop fails (black screen), while the OpenCL processing is actually successful, I'd be more suspect that the Direct3D driver is bugged rather then the OpenCL driver.