madVR - high quality video renderer (GPU assisted)

[aufkrawall]

There's surely truth in this, but usually downscaling doesn't introduce many artifacts and C-R is neither blurry nor overly sharp.
Dunno if I'd call it "groundtruth" though.

[Ver Greeneyes]

my point is when watching a movie which needs to be upscaled it will not be downscaled first then. only upscaled. so the upscaled picture should be compared to the source image to clarify which algorythm comes closest to the source at this resolution.How do you define 'the source at this resolution'? Do you downscale the upscaled image - if so, using which algorithm? Do you compare the upscale to the 'ideal' upscale using a more expensive algorithm like waifu2x? Do you compare it to the nearest neighbor upscale from a distance where you can no longer see the individual pixels? At some point you're going to have to make a judgment call. With madshi's way of downscaling first, at least you know what the source looks like. The only question is what impact the downscaling algorithm makes, and how it compares to how other sources are downscaled.

[Thunderbolt8]

the source at its native resolution I meant

The only question is what impact the downscaling algorithm makes, and how it compares to how other sources are downscaled.this point should definately be clarified before continuing with these comparisons

[Telion]

A no-brainer solution is to take the same screenshot from original DVD and BD sources of some initially analog video. E.g. one from Mononoke would be pretty good since this anime is known to be pure analog in production. So all dissimilarities between 2 reference screenshots would be almost completely due to a difference in scanning resolution from an analog film. Moreover, an upscale from SD to FHD would be much closer to a real-life scenario.

[Akeno]

A no-brainer solution is to take the same screenshot from original DVD and BD sources of some initially analog video. E.g. one from Mononoke would be pretty good since this anime is known to be pure analog in production. So all dissimilarities between 2 reference screenshots would be almost completely due to a difference in scanning resolution from an analog film. Moreover, an upscale from SD to FHD would be much closer to a real-life scenario.

Were the DVD and Blu-Ray released at the same time? If not, we run into the issue of studios "touching up" the originals for Blu-Ray release as was the case of Tropic Thunder if I'm not mistaken. The studio applied bad sharpening and noise reduction that actually lowered detail compared to the DVD release.

[Thunderbolt8]

if possible, Im in favour of using upscale comparisons of 720p to 1080p and 1080p to 4k. that probably already is (720p to 1080p) and definately will be the most used cases of upscaling in the future and imho it makes sense to focus on these resolution when doing comparisons and not compare mini pictures.

[Ver Greeneyes]

The difficulty with 720p to 1080p is that it's not straight-up doubling, so not all algorithms can be applied directly. You either have to double the image using something like SuperXBR or NNEDI3, then downscale using another algorithm, or upscale using a scale-agnostic algorithm like Jinc.

However, if a movie is filmed in UltraHD, and they release UltraHD and FullHD versions, we'd be able to compare scaling algorithms on the downscaling algorithm that studios are using. The algorithm might still differ from studio to studio though, so it's not like there's One True Solution to this.

[Akeno]

However, if a movie is filmed in UltraHD, and they release UltraHD and FullHD versions, we'd be able to compare scaling algorithms on the downscaling algorithm that studios are using. The algorithm might still differ from studio to studio though, so it's not like there's One True Solution to this.

In the end, it's basically what we are doing now. I doubt the studios scan the masters twice for DVD and Blu-Ray releases but it's anyone's guess on what they do.

[aufkrawall]

Just out of curiosity, what is everyone currently using for debanding strength and dithering mode?
High deband & quality trade-off checkboxes unchecked, I really hate banding.
I find Error Diffusion totally useless with my 8 bit QX2710 bypass display, thus just ordered dithering.

Banding can be real-hardcore in real world content:
http://www18.zippyshare.com/v/0Jil84gy/file.html
madshi's deband filter is doing an excellent job.

[Telion]

I doubt the studios scan the masters twice for DVD and Blu-Ray releases but it's anyone's guess on what they do.
They do if BD is released long after the initial DVD release, as with Mononoke. Of course, the original source must be of high quality, as heavily remastered/retouched ones obviously should be avoided in such comparisons.

[DarkSpace]

In the end, it's basically what we are doing now. I doubt the studios scan the masters twice for DVD and Blu-Ray releases but it's anyone's guess on what they do.

Well, it's certainly not Anime, but they did for Star Trek (and did it really well, at that), but there it was advertised. Unfortunately, I don't remember enough to say that it was prominently advertised, but I believe it was.

Edit: Well, Telion mentioned the core information already some hours ago. I should go to bed now.

[Akeno]

Well, it's certainly not Anime, but they did for Star Trek (and did it really well, at that), but there it was advertised. Unfortunately, I don't remember enough to say that it was prominently advertised, but I believe it was.

Are we talking about the new Star Treks or the older movies?

[DarkSpace]

Are we talking about the new Star Treks or the older movies?

I'm talking about the series here... as far as I know, the movies I-X were rescanned only. I've got Star Trek TOS and TNG here, and I've heard that the animates series is also (going to be?) available on BD. Anyway, even TOS' "original effects" video has been remastered in so far as that the footage has been cleaned up after being re-scanned, so it's unsuitable for comparison, I'd guess.

[XMonarchY]

I don't know whether its the NVidia 353.54 drivers or Windows 10 or madVR or MPC-HC, but in Windows 10, I am unable to use the seek bar in madVR exclusive mode. The mouse pointed can never reach the bottom of the screen and just resets itself to the middle of the screen. Anyone know which software is the issue?

Also, I noticed that latest NVidia Windows 10 drivers do not support CUDA. Is that a problem for using CUVID Decoding in LAV Filters or for madVR or anything else for that matter? Doesn't seem to affect games or anything else I use, but AFAIK CUDA is like the core architecture for NVidia, so..?

[aufkrawall]

Seekbar works fine here with same GPU and OS in D3D9 and 11, driver is 353.49.
Don't use drivers from WU like 353.54, they lack Cuda and/or OpenCL. Pure crap.

To prevent driver updates from WU for certain devices under Windows 10, see this:
https://support.microsoft.com/de-de/kb/3073930
If it doesn't work, try this script (no guarantee from my side for anything):
http://www68.zippyshare.com/v/wFdDMPMV/file.html

[XMonarchY]

Seekbar works fine here with same GPU and OS in D3D9 and 11, driver is 353.49.
Don't use drivers from WU like 353.54, they lack Cuda and/or OpenCL. Pure crap.

To prevent driver updates from WU for certain devices under Windows 10, see this:
https://support.microsoft.com/de-de/kb/3073930
If it doesn't work, try this script (no guarantee from my side for anything):
http://www68.zippyshare.com/v/wFdDMPMV/file.html

Really? Then why is ED working with 353.54 drivers then?

[x7007]

NEEDI3 in Madvr 88.20 works in Potplayer + windows 10 + NVidia 353.54 + CUVID ?

Because my Rendering always 5.32ms and doesn't change when I change the madvr settings from 64 to 256 or any heavy setting.

and the bar works for me in Potplayer in exclusive mode + D3D11

[michkrol]

Really? Then why is ED working with 353.54 drivers then?

Because it uses Direct Compute?

NEEDI3 in Madvr 88.20 works in Potplayer + windows 10 + NVidia 353.54 + CUVID ?

Because my Rendering always 5.32ms and doesn't change when I change the madvr settings from 64 to 256 or any heavy setting.

Check the OSD (Ctrl+J to toggle), you should get something like:
image > NNEDI3 ... or chroma > NNEDI3.
Then check with MPC-HC, just to be sure.
Then follow aufkrawall's advice from 2 posts up/back :cool:

[x7007]

Because it uses Direct Compute?



Check the OSD (Ctrl+J to toggle), you should get something like:
image > NNEDI3 ... or chroma > NNEDI3.
Then check with MPC-HC, just to be sure.
Then follow aufkrawall's advice from 2 posts up/back :cool:

For some weird reason it says Jinc AR even though I selected Chroma upscaling NEEDI3
All others works expect NEEDI3, if I select it , I see Chroma Jinc AR..

anyone has fix ?

Sometimes it's hard to go into exclusive mode in windows 10 , it tries to go in but flashes and you in black screen while the movie keep running, the only fast fix is to run the file again from the playlist, but it only happens randomly when you run the file, then it will always go exclusive without issue.

[huhn]

anyone has fix ?

use drivers with openCL.

[Schwartz]

Try DXVA copy-back instead of CUVID. I had a Catalyst driver that auto-selected Jinc AR instead of NNEDI3 because I was using native instead of cb.

[x7007]

use drivers with openCL.

Which drivers are those ?

Try DXVA copy-back instead of CUVID. I had a Catalyst driver that auto-selected Jinc AR instead of NNEDI3 because I was using native instead of cb.
Still stays JINC even when DXVA - Copyback is selected

[aufkrawall]

Which drivers are those ?

Drivers directly from Nvidia.
Use this:
http://nvidia.custhelp.com/app/answers/detail/a_id/3698
Or wait until a new driver is released directly from Nvidia next week for Windows 10 RTM.
But DON'T use anything from Windows Update and be sure that it doesn't automatically replace your driver. I posted instructions for this above.

[x7007]

Drivers directly from Nvidia.
Use this:
http://nvidia.custhelp.com/app/answers/detail/a_id/3698
Or wait until a new driver is released directly from Nvidia next week for Windows 10 RTM.
But DON'T use anything from Windows Update and be sure that it doesn't automatically replace your driver. I posted instructions for this above.

353.49 only works with DXVA- Copyback right ? not Cuvid.

What more issues does it has ?

[aufkrawall]

Cuvid works, just not together with NNEDI3 OpenCL.
Why would you want to use Cuvid? I don't think the linked driver has any important issues. I wouldn't have linked it if I'd known better.

[leeperry]

Any idea why? I had doubling activated for >= factor 1.5 (default) and it worked just normally.

No idea, that's what I get: http://thumbnails113.imagebam.com/42428/63d60e424270522.jpg (http://www.imagebam.com/image/63d60e424270522)

It works in FSE and/or with motion pictures, but pictures in FSW just don't upscale with NNEDI256 for chroma+luma for some reason. I'm on W7SP1 in DX9 and I got Aero disabled, I do prefer FSE of course but no screenie in this mode.

Anyway, 3@0.41LQ with sxbr75 in .15 is definitely a keeper to me. J3AR is nice for chroma but sxbr125 AR would provide a nice sharpness boost w/o looking artificial(great looking on ppl with freckles for instance), I can't add AS or anything else though. Would have to try SR for chroma but it's still experimental in .15 IIRC.

I've had success loading images in MPC-HC, though it's not ideal for saving the result since I think madVR uses slightly different logic for that. I'm pretty sure the upscaling works just fine though.
I use the default queues and it's a black frames mess for me in PotP, I wish mVR could identify still frames source filters and run in a pictures-only mode without any queue. Fair enough, will try MPC-HC then :cool:

This obscure picture viewer would provide NNEDI3 scaling but it seems quite a PITA to setup, no automation, no AR filter bleh: http://www.mydailymanga.com/pin/7768/

[XMonarchY]

OK, I removed 353.54 drivers using DDU, restarted, installed 353.49 Hotfix drivers for Windows 10. Now madVR does not work at all. I get audio and no video... If I use another renderer, then I do get proper playback. I guess madVR does not work with Windows 10 353.49 drivers...

Are you saying we cannot use OpenCL NNEDI3 at all with Windows 10?????

[XMonarchY]

Ha, you were right -disabling NNEDI3 did fix madVR. THING IS - 353.54 drivers DID allow the use of NNEDI3 in madVR! 353.54 > 353.49 Hotfix. It appears both are missing CUDA and OpenCL is present in 353.54 drivers!

[XMonarchY]

Wait! Now I selected DXVA Copy-back and NNEDI3 suddenly works. So 353.49 Hotfix only work with NNEDI3 when DXVA Copy-back is selected, while 353.54 WHQL work with NNEDI3 when CUVID is selected. What am I losing when CUVID cannot be selected? Does image quality or performance get worse?

Also, how can I check whether OpenCL is installed?

[x7007]

Ha, you were right -disabling NNEDI3 did fix madVR. THING IS - 353.54 drivers DID allow the use of NNEDI3 in madVR! 353.54 > 353.49 Hotfix. It appears both are missing CUDA and OpenCL is present in 353.54 drivers!

It allowed to use but it doesn't work because the OpenCL doesn't work.. lol, NVidia are PITA.

Can you explain why not to use the CUVID ? Hardware/GPU Deinterlacing (CUVID/QS only)

Enable Adaptive HW Deinterlacing

Output mode 50/60Fps (Video)

(V) High-Quality Processing

[Schwartz]

Read the last couple of pages about CUVID and the other modes. Basically you're not losing anything but a forced high power state on your GPU. Oh and LAV hardware deinterlacing. But as I understand it that's something you can leave up to madVR anyway?

It's not only NVidia making a mess, both manufacturers are pretty spotty in their OpenCL support and performance as well as availability of NNEDI3 is always driver-dependant.

[aufkrawall]

What am I losing when CUVID cannot be selected? Does image quality or performance get worse?

This has already been discussed on the previous pages of this thread...

to put it short:
using cuvid improves nothing
don't use WU drivers

I'm out now, it feels like talking to a wall.

[KoD]

Hi, I experience lots of dropped frames after switching between fullscreen and windowed modes, the way I describe below:

What I do is this: start playback-> all is fine, go fullscreen -> everything is still fine, then go back to windowed mode -> all still fine -> go back to full screen -> now lots of frames dropped, it does not recover itself unless I pause the video, and then resume. With 0.88.12 it was enough to pause once, and then playback would be smooth again after resuming; with 0.88.19 once is often not enough, I have to pause twice. It looks like the render queue does not recover staying at 1-3 or 2-3, even though the decoder, subtitle and upload queues fill up to their normal stats. The present queue also ends up with the same fill status as the render queue.

Some details: I'm using MPC, with its internal filters for h264 playback of mkvs, it happens on both 8 bit and 10 bit content, irrespective of whether I use software or hardware decoding. Happens only when using D3D11 and fullscreen exclusive mode. If I use full screen windowed mode, or I use the D3D9 renderer, all is fine.

I happen to have a Sony TV which accepts 12 bit color input. When using D3D11 and fullscreen exclusive mode, the TV receives 12bit per channel input (I can see this by pressing the Info key on the remote).

Have not changed the graphics drivers since a long time ago, it's still version 347.25 on a GTX980 for me.
Is this a new problem with the newer madVR builds? Or what it "always" this way?


Hi madshi, since my post last week, I discovered that, in fact, pausing twice is often not enough to resume playback. And what's worse, is that if I keep doing switches between fullscreen and windowed modes, the player ends up in a state where it can't recover anymore even after pause/unpause, playback is impossible even in windowed mode. I have to close MPC and open it again, and then playback works fine again (until I start switching between full-screen and windowed modes a few times).

As for version 0.88.20, the problem is even worse than in 0.88.19.
For one, now I have the issue even with the default settings in madVR, which don't use D3D11 and FSE, so no 10 bit per color output. I did not even try to test the D3D11 renderer this time. And instead of dropped frames, now playback simply seems to hang for 20 seconds or so, showing the same frame, while MPC is reporting to be playing, the madVR OSD shows all queues full but the frame displayed on the screen does not change, and the "rendering" time in the OSD is reporting 0.00ms. If I wait long enough (tens of seconds), playback then suddenly starts to resume.

I agree with the reports from others, rendering times when it is playing are definitely not correct - I never saw 1-2ms before.

As a side-note, the player does not become unresponsive, it's just the playback that suddenly stops on one frame. If I press the ESC key, MPC closes immediately.

Previous to trying 0.88.12, I have been using 0.87.21 and there are no issues there. I just tested again that version, and indeed, no issues. 0.87.21 does not have the option for a D3D11 renderer, so if you can let me know which is the first version that has it, I can download it and test if the issue is present there or not.

I don't think I said this before, but I am using the 64 bit version of MPC with the 64 bit version of madVR.



Later edit:
Ok, please disregard my assumptions in the previous post. In fact, there are two issues:
- the issue in my original post, about the frame dropping and queue depletion happening only when 10bit output is sent to the TV is still there in 0.88.20, just like in 0.88.19 and 0.88.12. With 0.87.21 this issue is not present, but there was no way to output 10 bit color back then.

- the "new" issue I am speaking about above, where I had the frame freeze, despite using default settings, with no 10 bit output, and everything seemingly playing, seems to be caused by something else! :)

MPC-HC is set to send its audio output to the optical S/PDIF output, through the "DirectSound: Digital audio (S/PDIF) (High Definition Audio)" device. But foobar2000 is also configured to send the audio to the S/PDIF using the "WASAPI (event) : Digital Audio (S/PDIF) (High Definition Audio Device)", which looks like gives it exclusive access to the audio device. The issue I described above with the playback freezing for a while, and then suddenly resuming, happens only when foobar2000 is playing music and I pause the video in MPC -> when I unpause the video in MPC I get the sudden frame freeze for a couple of seconds. And this issue is present in 0.87.21 too, and even with EVR, so it's a MPC-HC issue. If I use the "Digital Audio (S/PDIF) (High Definition Audio Device)" device in MPC, or the new Internal Audio renderer which has exclusive mode capabilities, this issue then does not occur.

[Warner306]

This has already been discussed on the previous pages of this thread...

to put it short:
using cuvid improves nothing
don't use WU drivers

I'm out now, it feels like talking to a wall.

The discussion in this thread may be useful regarding the benefits of DXVA2 Copy-back vs Nvidia Cuvid: http://yabb.jriver.com/interact/index.php?topic=80258.0.

[huhn]

Read the last couple of pages about CUVID and the other modes. Basically you're not losing anything but a forced high power state on your GPU. Oh and LAV hardware deinterlacing. But as I understand it that's something you can leave up to madVR anyway?

It's not only NVidia making a mess, both manufacturers are pretty spotty in their OpenCL support and performance as well as availability of NNEDI3 is always driver-dependant.

DXVA deinterlacing is the same deinterlacer as CUVID deinterlacer. HQ is default for DXVA deinterlacing.

and to be more precise CUVID deinterlacing doesn't allow madVR to use IVTC on the interlaced video stream. so there is nothing to win only things to loose.

and different decoder doesn't have better picture quality.

and about openCL looks like nvidia has removed cl_nv_d3d9_sharing in newer drivers. i'm not 100% sure if madVR uses that extensions. if it does everything make sense.

[mogli]

When displaying a movie one frame at a time in MPC-HC one sees a future frame flashing shortly before the correct one is shown. This is new since a few madVR versions ago.

Is this a known issue?

[DragonQ]

I upgraded to the latest MadVR on both my laptop and desktop and now have the same issue with both: deinterlacing no longer activates for 1080i/25 AVC videos in MKVs. I get a "DXVA processing failed" message. 576i/25 MPEG2 videos in MKVs seem to work fine.

The laptop has Intel and nVidia GPUs, the desktop has AMD. 0.88.19 also suffers this problem but 0.88.15 doesn't, so something happened somewhere between those two versions to break this.

[aufkrawall]

and about openCL looks like nvidia has removed cl_nv_d3d9_sharing in newer drivers. i'm not 100% sure if madVR uses that extensions. if it does everything make sense.
Urks. If this proves to be true, we need a non-OpenCL implementation of NNEDI3 very badly. :(
Edit: Or can d3d11_sharing be used?

[chros]

I have found a bug with 30 fps content with the latest .20 build. OSD reported render times are well under 2 ms (which is impossible for my hardware specs: last version reports render times ~28ms for same settings), but cranking up settings will caused dropped frames while the OSD reports <20ms render times. This is a cosmetic bug with no functional problems that I can see. Problem didn't occur in .19 and earlier. No rendering time calculation errors with 24 fps content. Don't have access to any other framerate content to test.

Windows 8.1 x64, mpc-hc x64, madvr x64, LAV filters 65.0. Image upscale jinc ar, chroma bicubic 75 ar. No image doubling.
I can confirm the OSD rendering times issue with D3D9 Old Path as well (windowed and FS) even with 24fps content. (v0.88.20)

[huhn]

Urks. If this proves to be true, we need a non-OpenCL implementation of NNEDI3 very badly. :(
Edit: Or can d3d11_sharing be used?

should be possible with this or NV/KHL d3d10 but who said they will not remove this next version?
but only dx10 or newer card should support this. the old version should work on dx9 cards at least in theory.

just removing an extension... and no they didn't added cl_khl_dx9_media_sharing

[chros]

The discussion in this thread may be useful regarding the benefits of DXVA2 Copy-back vs Nvidia Cuvid: http://yabb.jriver.com/interact/index.php?topic=80258.0.
Wooow, thank you for the link!
I had been using CUVID so far, now I switched to DXVA2 copyback, and I haven't known this:
"1. ... DXVA2 Copy-Back allows the graphics card to drop down to the medium power state if the GPU load is low enough."

Although I have been maxed out the powerstate to P5, gpu was always used at P5 with CUVID, even when MPC-HC was paused or stopped, now it goes down to the lowest states in these cases as well: less power -> less heat -> less noise.

[aufkrawall]

should be possible with this or NV/KHL d3d10 but who said they will not remove this next version?

Totally agreed, I really hope due to this madshi might give a non-OpenCL implementation of NNEDI3 a higher priority.
Not being able to use NNEDI3 would be a tragic loss, at least to me.

[ShadyCrab]

Using 0.88.20, when a MPC-HC OSD element pops up (volume, skip, etc) there is a very minor stutter, as though 1-2 frames had to repeat. Its noticeable, but isn't consistent in its severity or length. Big improvement from earlier versions, but not pre-OSD rewrite smoothness.

The madVR OSD seems to cause this issue too. Its like theres something off, almost like smooth motion was disabled, but less extreme.

GTX 660, MPC-HC (latest nightly) internal LAV, ISR, etc. D3D11 exclusive.

[Sunset1982]

and about openCL looks like nvidia has removed cl_nv_d3d9_sharing in newer drivers.

What means newer drivers? What was the last Version with cl_nv_d3d9_sharing in it?

Is there a windows 10 working driver with that extension?

[huhn]

not sure maybe 353.30 still has it maybe not.

[aufkrawall]

I rather recommend 353.49, since it includes fixes for TDR issues. NNEDI3 OpenCL works with these drivers.

[madshi]

I've made a short comparison along the lines of madshi's post comparing Super-XBR and NNEDI3 in regards to SuperRes.
Source chosen specifically for the details in the eyes. These get extremely soft when upscaling.

GroundTruth (http://i.cubeupload.com/SNi1yK.png) -|- 50% downscaled (http://i.cubeupload.com/LQD0D4.png)

Without Refinement
NNEDI3 (http://i.cubeupload.com/FyLoQ2.png) -|- Super-XBR (http://i.cubeupload.com/dmWWfc.png)

I'm using s-xbr 100 for these comparisons. NNEDI looks a better than s-xbr. You can see that the lines are a bit thicker especially in her eyes and there's small ringing around her chin and on the flash cards she's holding. S-xbr is a bit sharper than NNEDI in this example but NNEDI is closer to the groundtruth here.

SuperRes: Strength 2 / Radius 0.66
NNEDI3 (http://i.cubeupload.com/rD8EEE.png) -|- Super-XBR (http://i.cubeupload.com/APvFPU.png)

With SuperRes, the images look nearly identical. NNEDI benefits a tiny bit from SuperRes. The image is slightly sharpened at the cost of tiny aliasing all around. You can see it on the lines of the flashcards. Super-XBR benefits a lot more from SuperRes as the thickness around the lines is significantly reduced but the ringing is still present.

Conclusions
So here's SuperRes on cartoon and anime content. No horrible directional artifacts to be found unlike the trees in the castle examples. All in all, NNEDI3 and Super-XBR produce nearly identical results when combined with SuperRes. NNEDI3 is still superior though as Super-XBR does produce more artifacts (look at the lower edge where the glass meets the door frame next to her shoulder and on the edges of her uniform) and ringing. If the image could be sharpened just a teeny bit more, we'd be extremely close to the groundtruth. Maybe a change in finesharp's algorithm to decrease artifacts or a denoise filter with finesharp could do the trick.

I'm also going to take back what I said about adaptive sharpen (http://i.cubeupload.com/SdhDo6.png) as an image enhancer. It completely ruins the soft glow she has on her face and makes the image look processed.
Thanks. Your groundtruth is not the same frame, though. But I think in this case it's probably not a big problem.

I have black screen problem. My GPU is Radeon HD 3200. I use Potplayer (last version). Catalyst display driver is last version. A sample video (https://sites.google.com/site/pureocean1/madvr_black_screen.mkv?attredirects=0&d=1). When in this video jump to 07, 08, 09, 10 and 18, 19, 20 seconds, it's displaying black screen for an instant. Which settings can fix this problem? I don't know using how "madVR debug.ax".
For an instant? And after that it works fine? Doesn't sound like a very big problem. Just a cosmetical issue?

I did a short comparison of upscaling refinement options, mainly for myself, needed to know what was best for anime content.

Source : 1280x720
Monitor : 1680x1050

Chroma upscaling : Super-xbr 75
Image downscaling : Lanczos 4 AR LL
Image doubling : Super-xbr 75 (double luma/chroma)
Image upscaling : Jinc AR

Zoom 400%

Original (http://img11.hostingpics.net/pics/705472Original.png)

SuperRes Strengh 2 Radius 0.65 (http://img11.hostingpics.net/pics/115439SR2065.png) (the higher the strengh, the worst the result)

Adaptive Sharpen 0.3 (http://img11.hostingpics.net/pics/177803Ad03.png)

Adaptive Sharpen 0.1 (http://img11.hostingpics.net/pics/607562Ad01.png)

Finesharp 1.0 (http://img11.hostingpics.net/pics/774019FineS1.png)

So SuperRes mostly damage the original content, adaptive sharpen 0.3 is way too much, so I'll go for Finesharp 1.0/1.5 or Adaptive Sharpen 0.1/0.2.

Finesharp seems to be better for movie content (bluray, high quality source) and adaptive sharpen for anime content (relatively new animes), at least that's my preferences.

edit : I decided to go with adaptive sharpen 0.2
I personally cannot judge anything at 400% nearest neighbor zoom. There's also no groundtruth to compare to. So basically I can't comment on your images or comments at all.

I believe the stuttering issue started with v0.88.16b.
Ok, please try again with v0.88.21.

With regards to what Nev said over on the LAV thread

Can you give us any firm info on this?
Copyback produces the same quality as software decoding. Native DXVA decoding (and also DXVA deinterlacing and scaling) is problematic because Direct3D doesn't allow me to directly access the decoded NV12 surfaces, so I have to use tricks to make it work. Depending on the GPU and the driver it might work out well or badly. Usually if it works out badly, it's either a total misconfiguration in your GPU control panel settings. Or if your GPU control panel settings are ok, the worst that should happen is that the chroma channel is a tiny bit less detailed. Should have no effect on luma.

As I said, the foreground looks totally clear to me in its native resolution.
Why is this not a valid point, according to you?
Judging what is "totally clear" and what is not is subjective. Judging how a "totally clear" small image should look like 400% zoomed up is even more so. The only way to make things objective is if we have something to compare to.

Is your display still sub-1080p? I really doubt it makes sense to judge about sharpness if you can count every single pixel.
1080p front projection.

I have a problem with MPC-BE and madvr. If I set "treat 25p as 24p" in madvr, display mode won't change to 24p when I open a 25p video: it's stuck at 60p. If I use MPC-HC the issue doesn't appear. I'm using MPC-BE 1.4.5.579 and madvr 0.88.20
Check the source fps information in the madVR debug OSD. Maybe it's incorrect in MPC-BE?

Righty, took me a while to find the ideal picture but I think this one works very nicely:

original untouched 1080p BD screenshot(not captured by me):

sxbr75+SR3@0.41LQ(my favorite)
sxbr75+SR3@0.41HQ
NEDI+SR3@0.41LQ
sxbr75+AS0.5
NNEDI3 for luma+chroma@16 neurons +SR3@0.41LQ
NNEDI3 for luma@32 neurons+J3AR chroma+SR3@0.41LQ
NNEDI3 for luma+chroma@32 neurons

sxbr75+SR1@0.66LQ
sxbr75+SR1@0.66HQ
sxbr75+SR2@0.66HQ
sxbr75+SR3@0.66HQ
It's an interesting test picture because even NNEDI3-256 still has noticeable aliasing in some image areas. Of course SuperRes doesn't improve on that.

I find it hard to understand your image descriptions, though. I'm not sure if @0.xx is the radius of the strength?? Or is it sometimes this and sometimes that?

Madshi, looks like there's an issue here. On my 750 Ti there are considerable differences between running LAV in copy-back mode and native DXVA2.

http://screenshotcomparison.com/comparison/136044
This almost looks like DXVA does some sort of overscan scaling or stuff. Is everything in the GPU control panel set to neutral/disabled/application controlled?

Now that Kodi DSPlayer has integrated low latency mode, I have noticed a new issue. I believe this addition has made 1080p60 playback a little stuttery with some noticeable blurring on moving objects. It is subtle, but I cannot detect the same problem at 1080p24.

I have switched between MPC-BE and DSPlayer at 60hz and find DSPlayer is now less smooth - the blurring on objects being particularly noticeable.

Was 3/2 pulldown properly tested when low latency mode was added? Something does not look right at 1080p60 when played through DSPlayer.
I think there's a bug in v0.88.20 which keeps low latency mode active sometimes although it shouldn't be active. I suppose that motion smoothness might not perfect for all users in low latency mode - although it works just fine on my PC with all my GPUs. In any case, during normal video playback low latency mode should be disabled, and then v0.88.21 should hopefully be back to v0.88.16 reliability.

All kind people hello!
Version 0.88.16 during pause 0% GPU (MPC-HC 1.7.9.54);
Version 0.88.20 when paused consumes 40% of the GPU. - Перемудрил Мад;
(Win x64, Pentium E6600, nVidia GTX750 (DR 350.12).
Thats expected, madVR now keeps drawing the frame while paused.
But 40%? Shouldn't only presenting be done while pausing (+maybe OSD changes), no scaling/filtering?
40% is a relative value, so without knowing the power state of the card, its not that meaningful.
It may have clocked down and show a high utilization.

But ultimately madshi will have to comment on what it really does in pause mode.
40% does seem a bit high, but as nevcairiel says, it depends on the GPU clock. If the GPU clock is very low, 40% is not so much. GPU consumption in paused mode highly depends on the refresh rate, because madVR will present one frame for each VSync, and redraw the OSD for each. I seem to get near 0% GPU consumption on my PC in paused state, though.

In any case, currently madVR *always* draws in paused/stopped mode. I will change that in a future version so that it only draws when it's needed. That will depend on the media player, though (which OSD APIs they're using).

my point is when watching a movie which needs to be upscaled it will not be downscaled first then. only upscaled. so the upscaled picture should be compared to the source image to clarify which algorythm comes closest to the source at this resolution. because thats simply the resolution this movie will be watched and not at the same resolution as the source image.

my point is that I am questioning this method of sclaling into the other direction first and then getting back to the original size of the image, because we dont know in how far the result of the first scaling process might influence the result of the 2nd one, the one we want to look at. you wouldnt have this problem when directly applying the scaling process you want and compare from there.
I understand your concern. But please understand that most of today's content is actually a downscale, produced by the studios from their masters. DVDs were usually downscaled from 2K masters. Better Blu-Rays are downscaled from 4K masters. So upscaling video that was formerly downscaled is not something unusual, it's what we do every day.

The purpose of first downscaling and then upscaling again is that this is the only way we can objectively judge whether the upscaled image comes near to the original. If we don't use this approach, we have e.g. a DVD resolution source and an 1080p upscale, but whether the upscale is good or not nobody can say. Different upscalers, different sharpening algorithms produce different "looks". Some users prefer this, other users prefer that. Without having the original to compare to, if you ask 100 different users for which algorithm combination they prefer, you'll get 98 different answers.

the issue in my original post, about the frame dropping and queue depletion happening only when 10bit output is sent to the TV is still there in 0.88.20, just like in 0.88.19 and 0.88.12. With 0.87.21 this issue is not present, but there was no way to output 10 bit color back then.
There is a known issue if D3D11 does not officially support the refresh rate you want to use. In that case some GPU drivers run into trouble with queues not filling properly, especially when using a large number of prepresented frames. There's no solution to this. madVR is able to make D3D11 use the refresh rate you want, but with some GPU drivers these queues-not-filling problem is the consequence. Probably if you limit yourself to 1080p60, you'll not have this problem.

When displaying a movie one frame at a time in MPC-HC one sees a future frame flashing shortly before the correct one is shown. This is new since a few madVR versions ago.

Is this a known issue?
Not really. But different users had a couple of different weird issues. Try v0.88.21.

I upgraded to the latest MadVR on both my laptop and desktop and now have the same issue with both: deinterlacing no longer activates for 1080i/25 AVC videos in MKVs. I get a "DXVA processing failed" message. 576i/25 MPEG2 videos in MKVs seem to work fine.

The laptop has Intel and nVidia GPUs, the desktop has AMD. 0.88.19 also suffers this problem but 0.88.15 doesn't, so something happened somewhere between those two versions to break this.
Try v0.88.21. If that still fails, please upload a debug log.

Using 0.88.20, when a MPC-HC OSD element pops up (volume, skip, etc) there is a very minor stutter, as though 1-2 frames had to repeat. Its noticeable, but isn't consistent in its severity or length. Big improvement from earlier versions, but not pre-OSD rewrite smoothness.

The madVR OSD seems to cause this issue too. Its like theres something off, almost like smooth motion was disabled, but less extreme.

GTX 660, MPC-HC (latest nightly) internal LAV, ISR, etc. D3D11 exclusive.
Try v0.88.21. You may still have this issue when activating the FSE seekbar, but hopefully for all other OSD elements this issue might be gone in v0.88.21.

[madshi]

madVR v0.88.21 released

http://madshi.net/madVR.zip

* OSD rendering back to 0.88.16 logic, except when low latency mode is active
* fixed: DXVA processing failed when video stream switched resolution
* fixed: render times weren't shown correctly
* fixed: SuperRes bigger radius values could cause artifacts
* fixed: low latency mode sometimes wasn't turned off when it should

[DragonQ]

Try v0.88.21. If that still fails, please upload a debug log.
The problem persists, unfortunately. I'll try to get a debug log tomorrow evening for you.

[Asmodian]

not sure maybe 353.30 still has it maybe not.

I have been unable to get NNEDI3 in madVR working with the Windows 10 Nvidia drivers 353.54. Other OpenCL tests do work and by uninstalling 54 and reinstalling 353.30 NNEDI3 works again. Windows Update will automatically re-install 353.54 which breaks it again.

Tested with a 980 Ti, madVR v0.88.20, and Windows 10 Pro (not preview).