madVR - high quality video renderer (GPU assisted)

[leeperry]

Goodie, goodie! Well, that seems faster than my 7850

Using monostatic ED1 LL, low debanding, CC AR LL downscaling, J3AR upscaling for chroma & luma, with my 1Ghz 7850 I'm capped to:
-64x NNEDI luma for <=30fps SD to 1080p
-64x NNEDI luma for <=24p >=1.85 720p@1080p
-32x NNEDI luma for >=25p 720p@1080p

Which model is it please? How hot does it get under load?

[hu1kamania]

Originally Posted by leeperry

Goodie, goodie! Well, that seems faster than my 7850

Using monostatic ED1, low debanding, CC AR LL downscaling, J3AR upscaling for chroma & luma, with my 1Ghz 7850 I'm capped to:
-64x NNEDI luma for <=30fps SD to 1080p
-64x NNEDI for <=24p >=1.85 720p@1080p
-32x NNEDI for >=25p 720p@1080p

Which model is it please? How hot does it get under load?

I'm using the EVGA GTX 750Ti 2GB. Just the normal, not SC or FTW. I've never seen it hit 80C while heavily overclocked. Normally it reaches about 70C, and the fan is still quite low. If it's not overclocked it sits in the low 50's.

[QBhd]

Originally Posted by James Freeman

Yes, I mean for scaling 1080p video (Chroma) on a 1080p or 1440p Display.

I CAN see a small difference in chroma aliasing with NNEDI3 vs Lanczos, but the question is whether its worth the extra 30% GPU hit?
I'm also using Ordered Dithering instead of Error Diffusion (another 30% GPU hit).

I guess I prefer a cool running system (and a low electricity bill ) instead of squeezing every last drop of "almost invisible" performance from the system.

I personally rank the resource hogs like this:

Luma Doubling==> Chroma Upscaling==> Dithering==> Chroma Doubling

If I have resources to spare I will toss in chroma doubling neurons (I don't pay for electricty and my system's stupid cool) just to make sure I am getting every last drop of performance.

Originally Posted by hu1kamania

if (srcWidth >= 1900) and (srcHeight >= 721) "1080p"
else if (srcWidth >= 956) and (srcWidth < 1900) and (srcHeight >= 500) and (deintFps <= 23.98) "720p < 24fps"
else if (srcWidth >= 956) and (srcWidth < 1900) and (srcHeight >= 500) and (deintFps > 23.98) and (deintFps < 29.7) "720p > 24fps"
else if (srcWidth >= 956) and (srcWidth < 1900) and (srcHeight >= 500) and (deintFps > 29.7) "720p > 30fps"
else if (srcWidth <= 956) and (srcHeight <= 576) and (deintFps <= 23.98) "SD < 24fps"
else if (srcWidth <= 956) and (srcHeight <= 576) and (deintFps > 23.98) and (deintFps < 29.7) "SD > 24fps"
else if (srcWidth <= 956) and (srcHeight <= 576) and (deintFps > 29.7) "SD > 30fps"

You can clean up your script by reversing the order of things and going from small to lager values. Something like mine:

if (srcHeight < 481) and (deintFps < 31) "SD 30fps"
elseif (srcHeight < 541) and (deintFps < 26) "1/2 HD"
elseif (srcHeight < 541) and (deintFps < 31) "1/2 HD 30fps"
elseif (srcHeight < 721) and (deintFps < 26) "720p24"
elseif (srcHeight < 721) and (deintFps < 31) "720p30"
elseif (srcHeight < 721) and (deintFps > 31) "720p60"
else "1080p24"

It makes it easier to insert new lines and edit if you need to

QB

[leeperry]

Originally Posted by hu1kamania

I'm using the EVGA GTX 750Ti 2GB. Just the normal, not SC or FTW. I've never seen it hit 80C while heavily overclocked. Normally it reaches about 70C, and the fan is still quite low. If it's not overclocked it sits in the low 50's.

OK, thanks for the infos!

Are you using PCI-E 2.0 or 3.0?

What's your ASIC quality in GPU-Z BTW?

[hu1kamania]

Thanks for the suggestion QBhd

Originally Posted by leeperry

OK, thanks for the infos!

Are you using PCI-E 2.0 or 3.0?

What's your ASIC quality in GPU-Z BTW?

I am showing an ASIC quality of 78% with my current configuration.

Edit: oh yeah, and it's PCI-E 3.0

[mindbomb]

i'm having trouble conceptually trying to imagine what nnedi3 artifacts would look like when used in chroma scaling. It would be colors coming outside of the objects?

[Procrastinating]

nnedi3 artifacts tend to connect details where there was no connection previously, so I would imagine you could possibly notice colors appearing outside of their outlines.

[baii]

Not sure if mentioned previously.

Currently running a bay trail z3740 tablet,
stable (that is, until it start throttling due to temperature xD).24fps 1080p downscale to 1200 x 800 using quick sync/DXVA decode, DXVA downscaling, random diethering and FRC. Havent had a chance to get a profile for color management, hopefully it can handle it when 3dlut is added.

struggles with 1080i, drop frame if deinterlanced to 60fps, repeated frame if trade quality option "half frames" is used.

[turbojet]

madshi: Do you have any plans for using ivtc with 50/59/60 fps sources? It can be a large performance gain, in my case would allow nnedi3 doubling of 720p. I have some clips of 23, 25, 29 and 59 progressive in 720p59 if they are of any use.

[StinDaWg]

Originally Posted by turbojet

madshi: Do you have any plans for using ivtc with 50/59/60 fps sources? It can be a large performance gain, in my case would allow nnedi3 doubling of 720p. I have some clips of 23, 25, 29 and 59 progressive in 720p59 if they are of any use.

+1

Lots of stuff I have from Fox HDTV is 720p59.94 but actually 720p23.976 filmed.

[nevcairiel]

Originally Posted by turbojet

madshi: Do you have any plans for using ivtc with 50/59/60 fps sources? It can be a large performance gain, in my case would allow nnedi3 doubling of 720p. I have some clips of 23, 25, 29 and 59 progressive in 720p59 if they are of any use.

Did you try forcing it to IVTC? It should be able to detect any cadence, even if its 6:4 instead of 3:2 due to being 60 fps.
Just toggle the content type with Ctrl-Alt-Shift-T to "Film", and it may just work.

[kasper93]

What we really need is auto detection when to use film mode. I'm sure madshi will do it when the time comes

Tapatalk 4 @ GT-I9300

[DragonQ]

It's probably quite high on madshi's priority list. Combined with profiles it'd mean settings don't need to manually changed per video any more.

[madshi]

Originally Posted by mark0077

madshi I have noticed something that may or not be an issue. Its not just happening with your latest windowed mode updates, happened before so let me know if you think its worth creating a bug report for. And it actually doesn't seem to negatively effect me at all but you may like to look into it.

I notice sometimes when I start a movie, sometimes the render queue starts at say 15-16/16 but after a few moment drops to 10-11/16 (always exactly this amount), and even if I leave it there for hours with <50% cpu usage, it never grows beyond 10-11/16. The only way I can get it to fill up again is to seek after which it immediately returns to 15-16/16.

I can only seem to reproduce it when actually starting a movie from scratch (I have madVR set to wait for queues to fill up) and when in non fullscreen mode (both FSE or windowed fullscreen don't seem to show it). After seeking I never see it drop below 15-16/16. All other queues arn't effected. Should I report this on the bug tracker incase it does end up causing frame drops on someones machine at some point?

Things like this are very hard to find the cause for. Maybe by looking at very long logs for a very long time I could find something, or maybe not. At the moment, I'd prefer to not touch this, as it would cost a *lot* of time to investigate, and the chance is high that there isn't anything I can do about it, anyway.

Originally Posted by turbojet

The no cadence breaks for a whole episode with new window mode was definitely an exception. Others have been 5-10 down from 15-20 but only usually happen during the black frames between segments and is not noticeable. New window has reduce frame drops from 5-15 to 0-5. Render times have dropped about 10% which gives enough to disable overlay with ivtc+smoothmotion in my case. Secondary display with a different refresh rate then primary now works fine in new window mode, no need for overlay or fse for me anymore.

Sounds good!

Originally Posted by annovif

Hello everybody, do you think that we can join BlurayDisc "Mastered in 4k" in their full quality? what settings should I set in lav and madvr?

There's a thread on AVSForum where some users analyzed some "Mastered in 4k" discs (by using AviSynth scripts etc) and found that there isn't really any xvYCC data worth talking about. At this point in time I think it's mostly a marketing gimmick by Sony and nothing else.

Originally Posted by nevcairiel

HTPCs cannot output untouched YCbCr, there is generally always a RGB step in between, so its doubtful this is ever going to work.

True. However, if the display is calibrated to a bigger than BT.709 gamut (e.g. DCI) and if madVR is configured accordingly, the extended colors might still be transported to the display just fine. I'm not really 100% sure, though. The whole gamut topic will get interesting when we get the first 4K Blu-Rays with hopefully a bigger native gamut. At that point I guess I'll have to investigate how to transport that data to the display properly.

Originally Posted by 6233638

I thought xvYCC used negative values (or are values below 16 considered to be "negative"?) to expand the gamut beyond the normal range.

So:
+100% green
−100% red
−100% blue
(i.e. −100% magenta, being the opposite of green)

Would be equal to 200% green.

Which should be possible to represent in RGB if you are doing the appropriate color management and have a display capable of displaying that range of saturation.

Displays calibrated to Adobe RGB are common with photo editing for example.

The encoding is done in YCbCr, but yes, RGB values after YCbCr -> RGB conversion could become negative, in relation to the BT.709 gamut. After conversion to a bigger gamut they might get back into positive range. But I'm not sure whether all of this works correctly in madVR atm, to be honest. If the colors are just slightly outside the valid range, then there should be no problem because madVR has some headroom due to doing all math in video levels. But if the colors are waaay outside of BT.709, then I'm not sure if madVR isn't maybe clipping them, not sure...

Originally Posted by trip_let

I haven't had much time to test, but I think I found a situation where new windowed fullscreen is worse than old windowed fullscreen. It looks like the new version has slightly lower rendering times, but it starts dropping frames "earlier" (at lower frame times) than the old windowed path.

Try cranking up enough features to have average rendering time close to 1/fps. e.g. on 23.976 fps content, around 40 ms. For me, new path drops frames for the same settings that old path doesn't. (With things turned down more reasonably so we're not skirting the 90%+ render times and the GPU barely keeping up with the source, new path works perfectly.)

Yeah, that's quite possible. That will be especially true if your display refresh rate is higher than the movie framerate.

Originally Posted by tp4tissue

I tried a whole bunch of configs/reformat/updates/official-beta drivers.. giving up...

No go with NED 2x luma on 1920x1080 to 2560x1600 ...

Tried both my 7970cfx and 7870xt downstairs..

/Cry really loudly

I'm willing to buy a 290x.... Anyone try NED 2xluma @ 19x10 to 25x16.

You could try the interop test builds (see next post) to see if they make a difference for you. But at this point I guess your best bet might be an NVidia 750ti, because it seems that with your mainboard the AMD OpenCL interop cost is too high. Alternatively you could replace your mainboard, but I think going over to green land would be the easier solution.

Originally Posted by Stereodude

In 87.7 and 87.9 MadVR does not switch into FSE correctly on the first attempt for me. Alt+Enter to go back to windowed mode, and then another time to go to full screen again works. 87.4 worked okay on the first try. I haven't tried any of the intermediate releases.

I'm using Win 7 x64 with MPC-HC 1.7.3 using the Intel HD4600 graphics in my i7-4770k.

Can you please try to find out which exact madVR build introduced this problem? Also a debug log might help figuring out why the switch fails. Please don't switch back and forth in the debug log. Just let it fail, then stop, I don't need to see it working in the log, I only need to see the fail. Please enable the OSD (Ctrl+J) while creating the debug log, because otherwise the log will not contain all important information.

Originally Posted by tp4tissue

Aliased?

That's irrelevant when you get 1:1 scaling.. from 1280x720 to 2560x1600(1440)

That is as much information as is in the file.. anything ONTOP of that is an approximation.

You're aware of that almost all 1280x720 files were downscaled from 2K or 4K masters? The downscaling is usually done with linear interpolation. Something like Lanczos. The key thing to understand here is that a video file like that does not describe rectangular pixels. You need to think of each pixel more of a circle. If you display these files in 2x resolution with Nearest Neighbor scaling you're throwing away potential image quality. Why? Because what you're doing is this:

4K master -> Blu-Ray downscale -> 720p downscale -> 1440p upscale

All the downscales were done with linear interpolation. Which means that each pixel also contains a small portion of the original neighboring pixels. The best way to watch such movies is to upscale them with a good upscaling algorithm. This will get you nearer to the way the image looked in its original resolution.

If you don't believe me, try this:

(1) Take a sharp and detailed photo.
(2) Downscale it with your favorite image editor to 50%, by using a good downscaling algorithm (e.g. Cubic or Lanczos).
(3) Upscale it again 200% to get back to the original resolution.

Now for step (3) try Nearest Neighbor scaling and compare it to e.g. Lanczos. Check which upscaled image looks nearer to the original photo. This test is very valid for video playback, too. After all you don't just want to see what is in the video file, you want to see an image which is as near to the original film scan as possible, don't you?

Originally Posted by tp4tissue

720p to 25x16 or 15x14 using NN is akin to LOSSLESS conversion

Lossless to the 720p file, yes. But the 720p file itself has a much lower resolution and quality compared to the original film negative. By using a good upscaling algorithm you would get nearer to the original film negative. Do you want to stay lossless to the 720p downscaled source? Or do you want to get as near to the original film negative as possible?

Originally Posted by ryrynz

I'd really like to see some more development put into NNEDI to attempt to improve it, I wonder the chances of it improving in future?

NNEDI3 is what it is. There's no way for *me* to improve it. I could just post-process it (e.g. sharpen it), or alternatively I could try to create a new algorithm from the ground up, but I'm not sure if I could even reach NNEDI3 quality with such a new algorithm. If you want the NNEDI3 algorithm itself to be improved, you'd have to talk to tritical who created NNEDI3 in the first place. But I don't think you can expect big improvements.

Originally Posted by ryrynz

Basically it sounds like someone needs to create an external Darby-like neural network upscaler.

Darbee is a sharpener, not an upscaler, and Darbee doesn't use a neural network. If you want sharper images, use a sharpening algorithm after NNEDI3 scaling.

Originally Posted by ryrynz

Madshi, how does madVR's NNEDI settings stack up vs the default settings in Avisynth filter? Was wondering if we'd see options available for nsize and qual etc.

I've done some image quality comparisons and found an nsize setting of "8x4" to produce the least amount of artifacts for image doubling. It happens to also be the fastest nsize setting available. So the choice was simple for me. I don't plan to offer nsize or qual options in madVR, because the performance cost would not be worth the quality gain. The best way to improve quality is to increase the neuron count, so that's the only option I'm offering. No plans to change that.

Originally Posted by hu1kamania

1080p: 16 neurons (Not with NNEDI3 ChromaUpscaling, and it's not used often.)
720p < 24fps: 64 neurons
720p > 24fps: 32 neurons
720p > 30fps: 32 neurons
SD < 24 fps: 128 neurons
SD > 24 fps: 128 neurons
SD > 30 fps: 32 neurons

Nice. Looks faster than my AMD7770, although I haven't compared in detail.

Originally Posted by leeperry

Are you using PCI-E 2.0 or 3.0?

PCIe version is only important for AMD users.

Originally Posted by turbojet

madshi: Do you have any plans for using ivtc with 50/59/60 fps sources? It can be a large performance gain, in my case would allow nnedi3 doubling of 720p. I have some clips of 23, 25, 29 and 59 progressive in 720p59 if they are of any use.

It's on my to do list, but not for soon.

Originally Posted by nevcairiel

Did you try forcing it to IVTC? It should be able to detect any cadence, even if its 6:4 instead of 3:2 due to being 60 fps.
Just toggle the content type with Ctrl-Alt-Shift-T to "Film", and it may just work.

Hmmmm... You're right, it does seem to work. At least it lists 6:4 and plays just fine in 60Hz. Not sure whether the IVTC decimation timestamp manipulations will work properly, though. I guess at 24Hz it would probably play fine. But playing this at 60Hz with Smooth Motion FRC turned on might fail to achieve smooth motion.

Originally Posted by kasper93

What we really need is auto detection when to use film mode.

Yes, we do need that. Unfortunately it's not that easy to implement properly. Especially if we want to take mixed sources (e.g. film content with video overlay) into account.

Originally Posted by iSunrise

@madshi:
Blaire linked to your recent workaround (your changelog for 0.87.9) for the NV driver issue and asked me via PM, if there still is a driver fix needed.

I kinda feared this would happen, since your woraround takes the pressure off of NV to fix an issue no one else (besides you and people that use NV hardware with madVR) seems to care about (that's how I interpret it).

It looks to me that they were in the process of working on the fix, but they re-checked if they have the newest madVR version to test against.

Now, what should I tell him? Some technical details would probably be helpful. Also how you (if memory serves right, a madVR user actually came up with the idea) worked around the bug, so NV knows where and what to search for.

To be honest, madVR doesn't need a fix, anymore. The workaround works fine and doesn't have any negative side effects. That said, it's a clear bug in the NVidia drivers, from what I can see, so they might still want to fix it.

Basically the old madVR builds did this:

for each video frame do
{
  clTargetTex = clCreateFromD3D9TextureNV(...);
  clEnqueueAcquireD3D9ObjectsNV(clTargetTex);
  clSetKernelArg(clTargetTex);
  clEnqueueNDRangeKernel(...);
  clEnqueueReleaseD3D9ObjectsNV(clTargetTex);
  clFinish(...);
  clReleaseMemObject(clTargetTex);
}

With this code, older NVidia drivers worked fine, but newer NVidia drivers either do nothing, or write zeroed out data to the target texture.

The latest madVR builds now use the following approach instead, which works around the issue:

clTargetTex = clCreateFromD3D9TextureNV(...);
for each video frame do
{
  clEnqueueAcquireD3D9ObjectsNV(clTargetTex);
  clSetKernelArg(clTargetTex);
  clEnqueueNDRangeKernel(...);
  clEnqueueReleaseD3D9ObjectsNV(clTargetTex);
  clFinish(...);
}
clReleaseMemObject(clTargetTex);

[madshi]

Here's a new test build set for AMD users wanting to do NNEDI3:

http://madshi.net/madVRinteropTest.rar

In the rar file are two madVR.ax files which use different methods to try to improve the interop problem. Unfortunately the improvement is probably not as large as I had hoped, but there should be a small improvement at least. Probably one build will work better than the other build. Please try both and let me know which build works better for you. I've intentionally removed the rendering times from the OSD (only for these test builds, of course) because due to the way these 2 test builds work, judging them by looking at the rendering times would be misleading. So please judge these builds by testing which build allows you to use higher/more quality settings.

Looking forward to your feedback!

(FWIW, I've concentrated on NNEDI3 luma doubling, with NNEDI3 chroma upscaling and NNEDI3 chroma doubling disabled. Enabling those might still work, but I've not tested that.)

[James Freeman]

Is there a problem with NNEDI3 and AMD?
Not long ago it was Nvidia that didn't work at all, now its AMD?

[michkrol]

Originally Posted by James Freeman

Is there a problem with NNEDI3 and AMD?
Not long ago it was Nvidia that didn't work at all, now its AMD?

On AMD it's a performance only problem - it works correctly, just slower than it should, because of the way AMD('s driver) goes around DX->OpenCL interop.

[DragonQ]

Originally Posted by madshi

Here's a new test build set for AMD users wanting to do NNEDI3:

http://madshi.net/madVRinteropTest.rar

In the rar file are two madVR.ax files which use different methods to try to improve the interop problem. Unfortunately the improvement is probably not as large as I had hoped, but there should be a small improvement at least. Probably one build will work better than the other build. Please try both and let me know which build works better for you. I've intentionally removed the rendering times from the OSD (only for these test builds, of course) because due to the way these 2 test builds work, judging them by looking at the rendering times would be misleading. So please judge these builds by testing which build allows you to use higher/more quality settings.

Looking forward to your feedback!

(FWIW, I've concentrated on NNEDI3 luma doubling, with NNEDI3 chroma upscaling and NNEDI3 chroma doubling disabled. Enabling those might still work, but I've not tested that.)

Whilst playing a 640x480p/25 file with 16 neurons and Smooth Motion enabled (60 Hz):

v0.87.9: 35-40 dropped frames per second; render queue is 1-2/8; present queue is 0-1/8; GPU load ~95%
Test 1: 1-2 dropped frames per second; render & present queues are 0-4/8 or 1-5/8 typically; GPU load ~80%
Test 2: 0 dropped frames per second; render & present queues are 4-7/8 or 5-8/8 typically; GPU load ~82%

Test 2 seems the best for me. Still can't use 32 neurons though, I get a dropped frame every few seconds and GPU usage rises to 89%.

[MS-DOS]

Originally Posted by madshi

Here's a new test build set for AMD users wanting to do NNEDI3:

http://madshi.net/madVRinteropTest.rar

Let's see. On my 5870 (Win 7 x64, 13.12) the interop cost was insane, as I posted here (the image is dead, argh).
Tested the new builds on 480 -> 1080 (+J3AR) content in FSE (new path), which gave me about ~8-10 dropped frames per second even with 16 neurons before.

TestBuild1 - Seems to work smoothly up to 64 neurons, 128 starts to give loads of presentations glitches and the playback stutters quite a lot, but it doesn't report any dropped frames, thou. GPU load is stuck at ~63%.
TestBuild2 - Seems smooth up to 128 (!) neurons with no dropped frames or presentation glitches, ~64% GPU load. Setting it to 256 neurons puts 99% load on the GPU and I'm starting to get frame drops.

The improvement overall looks very large to me, TB2 is a beast. Could you implement these two in your OpenCL benchmark? I'd really like to see the raw numbers

Great work!

[huhn]

Originally Posted by madshi

Hmmmm... You're right, it does seem to work. At least it lists 6:4 and plays just fine in 60Hz. Not sure whether the IVTC decimation timestamp manipulations will work properly, though. I guess at 24Hz it would probably play fine. But playing this at 60Hz with Smooth Motion FRC turned on might fail to achieve smooth motion.

IVTC with something else like 3:2 normally never works fine. madvr doesn't drop the right frame with right detected 4:2:2:2 and playback is unwatchable and this on a 23 hz tv.

@tesbuilds

for me on a r9 270 the build 1 is "faster"
i tested 256 neuron 480p23 to 1080p. with the old build it is impossible with both new builds it works but with test 2 all queue drop but no frame is dropped. with test1 all queue fill up after some time so i think this is working better.


i get 82 % gpu usage test1 and 84% with test2 both drop like crazy with opend gpu-z so they should't be judge with gpu-z