madVR - high quality video renderer (GPU assisted)

[aufkrawall]

Mostly agreed.
I really like the effect of AS as an UR with low values (e.g. 0.2) for NNEDI3. Everything's still well reconstructed, but that softness disappears for a huge amount. Especially if sharpened after each 2x upscaling step. Thanks to its adaptive nature, it doesn't oversharp already sharpened areas and there is very little aliasing introduced.
Maybe this works a bit better with naturalistic content than with artificial one due to that thickening of black lines. But without sharpening, those lines are very soft with NNEDI3 though.

[XMonarchY]

I still get a ton of presentation glitches on my 120Hz monitor, even if I set it to 60Hz. The same exact settings work perfectly fine on my TV @ 23Hz. I don't get it. Average rendering times are identical on both TV and monitor - about 27-28ms (same as max stats). I can reduce presentation glitches on 120Hz monitor by enabling "present a frame for every VSync", but then still occur (1 every 10 seconds or so). However, enabling this option during playback on my TV @ 23Hz creates dropped frames and presentation glitches. Setting "present several frames in advance" to 1 also helped to reduce presentation glitches (1 every 15-30 seconds). Using less GPU-taxing settings made no difference.

The second issue I get on my TV is that at times when I pause playback and resume it, I get severe playback stuttering, which I can fix by exiting fullscreen exclusive mode to window mode and then going back to fullscreen exclusive mode. That does not happen on my 120Hz monitor though...

I reset madVR settings to default, uninstall it as admin, restarted, install madVR as admin, reset settings back to default, and applied settings I use. That did not help.

EDIT: Could these issues because I set "Maximum Pre-Rendered Frames" to 1 in NVidia Control Panel? I set it so because it reduces stuttering associated with using Borderless Window mode in PC games.

[nevcairiel]

High Refresh Rate screens can be a bit fiddly. You may need to increase the queue sizes quite a bit to accomodate for the higher refresh rate, that tends to help for me to reduce the glitches, and "present a frame every vsync" is pretty much mandatory.
Personally, its not like I see the glitches, it just piles up on the counter.

PS:
There will never be settings that work 100% perfect on every system, so having to change a setting here or there depending if you're playing 23.976 on a 120Hz screen, or having it play 1:1 on a 23p TV is not uncommon.

[kasper93]

@madshi: Something weird is going on. If I make MPC-HC window size equal to screen size madVR will go into exclusive mode and position window in center even though it weren't before. If I open context menu to disable exclusive mode it window go back to its original place. Also seekbar doesn't work in this "exclusive mode" probably it is not reported correctly.

To reproduce open any file in MPC-HC. And stretch the window to display size (not work area size). Basically this means to Make MPC-HC max size. To do that you need manual grab window borders and stretch it.

I will look into details tommorow. But it looks like madVR have "if (windowSize == displaySize) GoToRetardedExclusiveMode();" logic :)

[XMonarchY]

High Refresh Rate screens can be a bit fiddly. You may need to increase the queue sizes quite a bit to accomodate for the higher refresh rate, that tends to help for me to reduce the glitches, and "present a frame every vsync" is pretty much mandatory.
Personally, its not like I see the glitches, it just piles up on the counter.

PS:
There will never be settings that work 100% perfect on every system, so having to change a setting here or there depending if you're playing 23.976 on a 120Hz screen, or having it play 1:1 on a 23p TV is not uncommon.

Erm, but enabling "present several frames in advance" and setting "how many video frames shall be presented in advance" to 1 helped a lot. Anything higher than 1 and I get more frequent presentation glitches.

[nevcairiel]

Erm, but enabling "present several frames in advance" and setting "how many video frames shall be presented in advance" to 1 helped a lot. Anything higher than 1 and I get more frequent presentation glitches.

Don't set pre-presented frames in the NVIDIA control panel then, it messes madVR up quite considerably.
Luckily the NVIDIA panel has per-app settings!

[Magik Mark]

Don't set pre-presented frames in the NVIDIA control panel then, it messes madVR up quite considerably.
Luckily the NVIDIA panel has per-app settings!

Thanks for this tip. Are there any other settings that would degrade the performance of madvr or any other renderers in the Nvidia control panel? Is it better to just tick "Let 3d application decide" option?

[huhn]

Thanks for this tip. Are there any other settings that would degrade the performance of madvr or any other renderers in the Nvidia control panel? Is it better to just tick "Let 3d application decide" option?

just leave them at default and you are fine.

[aufkrawall]

Vsync, prerenderlimit, power management mode and Optimus settings are the only driver-settings that should affect madVR. Everything should be kept at driver default (app-controlled) for the profile of your media player.
If you change settings globally, you have to set them back for each profile.

[Anime Viewer]

If you were using it in combination with any kind of ED, run a gray ramp and you'll both be be horrified and happy to have it unchecked now ;)

I realized why I had it checked, and it wasn't because of render rate stats, but present stats. With "don't use linear light for dithering" checked and the video full screen my present rates are in the 3ms area, but with it unchecked and the video full screen they are in the 11ms area.

Edit: Windowed Full Screen (D3D11) runs with the 11ms presents, but if I run in D3D11 Exclusive (10 bit) its back down to 3ms again. Edit #2: Unchecking "present a frame for every VSync" also seems to be a way to bring it back down to 3ms while in (D3D11) Windowed Full Screen mode.

[6ari8]

I realized why I had it checked, and it wasn't because of render rate stats, but present stats. With "don't use linear light for dithering" checked and the video full screen my present rates are in the 3ms area, but with it unchecked and the video full screen they are in the 11ms area.

Edit: Windowed Full Screen (D3D11) runs with the 11ms presents, but if I run in D3D11 Exclusive (10 bit) its back down to 3ms again. Edit #2: Unchecking "present a frame for every VSync" also seems to be a way to bring it back down to 3ms while in (D3D11) Windowed Full Screen mode.

Are you using an HDMI port? I think you can probably bring down the present stats to below 1ms by using the DisplayPort (though that depends on the laptop). You can see which port you have that's connected to the discreet GPU from Nvidia's control panel. Mine has the mDP only but there are different cases for laptops like these:
http://3dsurroundgaming.com/TutorialImages/4.jpg
http://forum.notebookreview.com/attachments/physx-panel-hdmi-jpg.96903/
http://i1308.photobucket.com/albums/s619/fama_0/NvidiaPhysx_zps56496684.png~original

[Warner306]

Today, I attempted to embrace image sharpening as tool to improve an image rather than enhance its artifacts. I found the following settings beneficial in improving the quality of high-definition video:

1080p -> 1080p
Image Enhancements - FineSharp (strength 0.6)

720p -> 1080p
Upscaling Refinement - SuperRes (medium: strength=1.0; passes=1)

SuperRes is my favourite of the two. Its ringing is not obvious or bothersome compared to other sharpeners. I'm curious if the luma and chroma are doubled together or just the luma like the other shaders?

An AR filter for FineSharp would be great.

[Anime Viewer]

Are you using an HDMI port? I think you can probably bring down the present stats to below 1ms by using the DisplayPort (though that depends on the laptop). You can see which port you have that's connected to the discreet GPU from Nvidia's control panel. Mine has the mDP only but there are different cases for laptops like these:


Yes, I have an HDMI port that I connect my TV to, but both the TV and the laptop screen are shown to go through the Intel GPU like the second image you posted. Here is the PhysX display diagram on my system:
http://s10.postimg.org/kbllla6p3/Phys_X_auto.jpg

[Nachbar]

Does madvr support 36-bit deep color output or does it cap out at 30-bit?

I ask this because I believe my receiver is taking 30-bit output and down converting it to 24-bit. It is a Pioneer VSX 1021-K which the specs say it supports 36-bit deep color and no mention of anything else.

If I connect my computer directly to my TV it is fine and the test picture I am viewing shows no banding but if I go through the receiver it shows banding.

I have made sure the display properties in madvr is set to 10-bit and higher and made sure in catalyst control center that the display is set to 12-bit.

The manual doesn't mention if only certain HDMI ports accept this or not. I could try moving it around and testing a bit more. I am using the same input on the TV that works and made sure it is set to PC and UHD color.

[6ari8]

Yes, I have an HDMI port that I connect my TV to, but both the TV and the laptop screen are shown to go through the Intel GPU like the second image you posted. Here is the PhysX display diagram on my system:
http://s10.postimg.org/kbllla6p3/Phys_X_auto.jpg

Mine's like the second one. Yours seems to be like the third image.

Unfortunately, that means that all your output ports are connected to the Intel GPU.

I don't know what gaming laptop makers were thinking by choosing to connect output ports to the iGPU. I think anyone using their laptop to drive monitors with those ports would be using a power supply so connecting them to the discreet GPU would've been a much better choice.

With your setup, I think you should use exclusive mode with either D3D9 or D3D11 because that brings down the present stats to around 1-3ms for me when I'm using my HDMI port. Windowed mode gives me 8-9ms present.

[trip_let]

I was checking through a variety of content to find bad samples for s-xbr and just ran across a case where s-xbr doubling at any sharpness gets confused. I'm sure there are others, but in case someone's never seen what weirdness can happen sometimes, here it is.

s-xbr 50 vs. nnedi3 16
http://screenshotcomparison.com/comparison/134926

Original image
http://i.imgur.com/O7kqQN1.png

Doesn't really matter which s-xbr setting; it gets confused and erases some of the lines in the background grid in the box with the 32275GP with all of them. And there's nothing special about nnedi3, which was used for comparison. It could have been anything else. I think SuperRes may be on for both, but that's besides the point and not consequential.

[iSunrise]

@trip_let:
Your example perfectly shows, why super-xbr in it's current state is not a contender to NNEDI3 at all. Personally, I found the loss of picture details disturbing and also the strange alterations in various samples. Your example (and other tests I've done yesterday) only show that:

1) super-xbr seems to completely erase/destroy very visible picture details and also fine detail (look at the various 1s at the bottom, it almost modifies the 1 to an I, unacceptable)
2) NNEDI3 is a lot sharper than super-xbr (which is a result of the loss of fine detail)
3) super-xbr "rounds everything" and acts as some kind of anti-aliasing filter, adding picture information where there was none before

People that want an accurate representation of the original should stay away from it, even though it might be a lot faster.

Personally, I found that the new bilateral chroma scaler is extremely promising, at least on the samples I've watched closely, it's also extremely fast, looks great and is a perfect combination with NNEDI3 doubling and Bicubic50/75 for luma upscaling. Very good results if you can take the NNEDI3 performance hit.

[nevcairiel]

Pixel Art is a special kind of content, and resizers/doublers designed for generic content will just not always handle it properly. Its not a very convincing example of anything other than the fact that it doesn't work nicely for Pixel Art. :)

[madshi]

I would also be cool with creating a folder in mVR's folder such as "SuperRes HQ OFF" or something if that's not too much trouble please.
Ok, I could live with that. Will add it to a future build.

@madshi: Something weird is going on. If I make MPC-HC window size equal to screen size madVR will go into exclusive mode and position window in center even though it weren't before. If I open context menu to disable exclusive mode it window go back to its original place. Also seekbar doesn't work in this "exclusive mode" probably it is not reported correctly.

To reproduce open any file in MPC-HC. And stretch the window to display size (not work area size). Basically this means to Make MPC-HC max size. To do that you need manual grab window borders and stretch it.

I will look into details tommorow. But it looks like madVR have "if (windowSize == displaySize) GoToRetardedExclusiveMode();" logic :)
That sounds quite weird! I'm having trouble reproducing it, though. I suppose the MPC-HC window is not centered on the screen in this situation, is it? Could you create a debug log that shows this situation?

Today, I attempted to embrace image sharpening as tool to improve an image rather than enhance its artifacts. I found the following settings beneficial in improving the quality of high-definition video:

1080p -> 1080p
Image Enhancements - FineSharp (strength 0.6)

720p -> 1080p
Upscaling Refinement - SuperRes (medium: strength=1.0; passes=1)

SuperRes is my favourite of the two. Its ringing is not obvious or bothersome compared to other sharpeners. I'm curious if the luma and chroma are doubled together or just the luma like the other shaders?

An AR filter for FineSharp would be great.
I had tried to add an AR filter for FineSharp, but my first try didn't work very well. Will have to try again later...

Does madvr support 36-bit deep color output or does it cap out at 30-bit?
Direct3D11 supports either 8bit, 10bit or 16bit, but not 12bit. The GPU drivers make of that whatever they want. If I output 10bit, some GPU drivers output 10bit, others 12bit, others 8bit or 16bit. So in other words I don't have exact control over what the GPU outputs, unfortunately.

I was checking through a variety of content to find bad samples for s-xbr and just ran across a case where s-xbr doubling at any sharpness gets confused. I'm sure there are others, but in case someone's never seen what weirdness can happen sometimes, here it is.

s-xbr 50 vs. nnedi3 16
http://screenshotcomparison.com/comparison/134926

Original image
http://i.imgur.com/O7kqQN1.png

Doesn't really matter which s-xbr setting; it gets confused and erases some of the lines in the background grid in the box with the 32275GP with all of them. And there's nothing special about nnedi3, which was used for comparison. It could have been anything else. I think SuperRes may be on for both, but that's besides the point and not consequential.
Interesting!

@trip_let:
Your example perfectly shows, why super-xbr in it's current state is not a contender to NNEDI3 at all. Personally, I found the loss of picture details disturbing and also the strange alterations in various samples. Your example (and other tests I've done yesterday) only show that:

1) super-xbr seems to completely erase/destroy very visible picture details and also fine detail (look at the various 1s at the bottom, it almost modifies the 1 to an I, unacceptable)
2) NNEDI3 is a lot sharper than super-xbr (which is a result of the loss of fine detail)
3) super-xbr "rounds everything" and acts as some kind of anti-aliasing filter, adding picture information where there was none before

People that want an accurate representation of the original should stay away from it, even though it might be a lot faster.
Pixel Art is a special kind of content, and resizers/doublers designed for generic content will just not always handle it properly. Its not a very convincing example of anything other than the fact that it doesn't work nicely for Pixel Art. :)
^

Agree with nevcairiel. Although super-xbr was originally made for pixel art! Which means that maybe Hyllian may want to look into this issue? Not sure if it's easily fixable, though.

In any case, yes, NNEDI3 is superior to super-xbr in quality - but at a multiple of the performance cost. It's your decision which algo to use, of course.

Personally, I found that the new bilateral chroma scaler is extremely promising, at least on the samples I've watched closely, it's also extremely fast, looks great and is a perfect combination with NNEDI3 doubling and Bicubic50/75 for luma upscaling. Very good results if you can take the NNEDI3 performance hit.
There are some samples which show significant problems with the bilateral chroma upscaler, though. So once we concentrate on that, we'll have to collect such samples and try to fix them. For now I'm still concentrated on SuperRes.

[madshi]

madVR v0.88.17 released

http://madshi.net/madVR.zip

* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected
For users, this build is probably not much different to Saturday's test build. Well, at least I hope so. However, for some media player developers there's a big (positive) change. I've been asked to do rendering in paused and stopped modes for a long time, and now finally it's implemented. This required some deeper changes, though, so there's a certain danger of new bugs showing up.

Notes for media player developers:

1) Please set the owner/parent *before* you connect the pins.
2) All the various OSD interfaces in madVR now also work in paused and stopped mode. Maybe you can make use of it in some way?
3) If you're using IOsdRenderCallback, *PLEASE* make sure that your ClearBackground() and RenderOsd() callbacks return "ERROR_EMPTY" if there is no active OSD on screen. This is very important because if you don't return ERROR_EMPTY, madVR will switch into low latency mode to speed up your OSD reaction times. This is good for OSD latency, but not good for video playback reliability.
4) If you're using IMadVROsdServices::OsdSetBitmap, there's a new flag (see header files) that tells madVR whether your OSD bitmap needs low latency or not. Low latency makes sense for OSD elements the user can use to control something, but probably not for purely informational OSD elements.
5) You can see whether madVR is in low latency mode by checking the size of the "present queue". In low latency mode this queue is limited to 2 frames.

[ryrynz]

You can see whether madVR is in low latency mode by checking the size of the "present queue". In low latency mode this queue is limited to 2 frames.

Any particular reason for this feature?

[madshi]

Faster OSD reaction times, of course. Not so important for simple informational texts like "exclusive" or "windowed". But things like the FSE seekbar or even more complex OSD elements do benefit. Some media players draw complex OSDs through the madVR OSD interfaces.

[Prinz]

I have here a video file that results in black video screen (windowed mode) with all current version. 0.88.8 is the last that works, 0.88.9 and 0.88.10 crash right away, all newer versions have black video screen in windowed mode.

[madshi]

Sample?

[6ari8]

In 0.88.17, both MPC-HC and MPC-BE stutter when I bring up the OSD (CTRL+j) during playback.
No frame drops/repeats but it acts as if it's dropping frames.

[leeperry]

* fixed: high GPU consumption in paused mode (PotPlayer
Oh wow, too good! :)

Ok, I could live with that. Will add it to a future build.
Awesomtastic, thank you! I still don't understand why I would be the only one seeing that nasty veil among the few mVR users who currently aren't on vacation huh......maybe it somehow synergizes with dynamic dithering, I could imagine it making the dancing noise patterns less obvious or maybe the latter completely hide the veil.

I had a really good look at what HQ does and I must admit that I see the exact same veil in the HDTV tuner of my Sammy TV, I only see it in mVR when HQ is on....maybe it's display dependent then huh, not sure but either way I can't wait to try the new SR AR coz sxbr50 does kinda look like the rings of Saturn on bad sources ^^

Please allow me to +1 the request of a few other SR users to please allow us specifying the number of passes and strength along with the new presets. I do realize that less is more when it comes to sharpening and that I'm currently going way overboard on sharpness in SR so I would happily try presets but a good bunch of us would also very much fancy the ability to specify our own parameters.

:thanks:

[mogli]

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

[iSunrise]

Agree with nevcairiel. Although super-xbr was originally made for pixel art! Which means that maybe Hyllian may want to look into this issue? Not sure if it's easily fixable, though.
It would certainly be great if he can reduce the rounding that seems to occur, which also eats into some details. Maybe he can optimize that to be a little less aggressive.

There are some samples which show significant problems with the bilateral chroma upscaler, though. So once we concentrate on that, we'll have to collect such samples and try to fix them. For now I'm still concentrated on SuperRes.
OK. I would be very interested in some samples that show artefacts, because when I used them on mine, I was pleasently surprised by it's sharpness and detail retention.

[James Freeman]

* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic

What are the benefits/purpose of these?

[Ver Greeneyes]

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.I'm seeing the same thing. Happens both with D3D9 and D3D11. No frames seem to actually drop, so it must be a visual issue.

[rack04]

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

I was just about to report the same problem.

[Anime Viewer]

madVR v0.88.17 released

http://madshi.net/madVR.zip

* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected
For users, this build is probably not much different to Saturday's test build. Well, at least I hope so. However, for some media player developers there's a big (positive) change. I've been asked to do rendering in paused and stopped modes for a long time, and now finally it's implemented. This required some deeper changes, though, so there's a certain danger of new bugs showing up.

Notes for media player developers:

1) Please set the owner/parent *before* you connect the pins.
2) All the various OSD interfaces in madVR now also work in paused and stopped mode. Maybe you can make use of it in some way?
3) If you're using IOsdRenderCallback, *PLEASE* make sure that your ClearBackground() and RenderOsd() callbacks return "ERROR_EMPTY" if there is no active OSD on screen. This is very important because if you don't return ERROR_EMPTY, madVR will switch into low latency mode to speed up your OSD reaction times. This is good for OSD latency, but not good for video playback reliability.
4) If you're using IMadVROsdServices::OsdSetBitmap, there's a new flag (see header files) that tells madVR whether your OSD bitmap needs low latency or not. Low latency makes sense for OSD elements the user can use to control something, but probably not for purely informational OSD elements.
5) You can see whether madVR is in low latency mode by checking the size of the "present queue". In low latency mode this queue is limited to 2 frames.

I'm not sure which change its from, but my OSD no longer seems to be reporting accurate information:
http://s10.postimg.org/y1w9bpn53/mad_VR_OSD_stats.jpg
Even though it says 0s for target rectangle, and all of the queues I'm not seeing any problems with the video playing. (Therefore the dropped frames, delayed frames, and presentation glitches 0s may be correct. I can change my settings to something my system can't handle like 256 neurons, and see if it still reports no problems with drops and glitches to see they are being misreported too). This screen capture of the OSD was taken with the video playing, so it wasn't during a pause or stop.
Edit: When I changed to 256 neurons my render times shot up to 96ms, and I did get dropped frames and presentation glitches so the 0's reported in those areas were accurate.

[michkrol]

@madshi, a small tweak for some (later) build: could we get keyboard shortcuts for the new chroma upscaling algos (Bilateral, NEDI, s-xbr) as well as ability to switch to/from them with the "chroma upscaling algorithm - toggle" key?

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.

Similar thing happens here on MPC-HC (x64) V1.7.9.54 (nightly).
For me the queues show as 0-x/x while playing and x-x/x while paused.
No frame drops, playback is stable.
Screenshots below.

http://i.imgur.com/hyeEas1.pnghttp://i.imgur.com/GZjv3Ke.png

EDIT: Looks like I'm the n-th person to report this (I'm a slow writer). Sorry for the duplicate info/unintended spam.

[ryrynz]

What are the benefits/purpose of these?

Madshi already answered me above regarding the OSD. Regarding rendering while paused and stopped it's my assumption that this too is related to media players rendering their own OSD through madVR.

[tobindac]

crash with latest mpchc nightly. running svp latest too.

[aufkrawall]

This build shows completely empty queues (e.g. 0-8) while playing on Windows 10. However, with previous builds, render queue already wasn't reported correctly (was less filled than present queue). A driver bug, or needs madVR an adjustment for Windows 10?
Playback still seems to be totally fine.

[madshi]

In 0.88.17, both MPC-HC and MPC-BE stutter when I bring up the OSD (CTRL+j) during playback.
No frame drops/repeats but it acts as if it's dropping frames.
Need more information. GPU? OS? Maybe a screenshot of the OSD (Ctrl+J)?

Does this problem also occur with v0.88.16, or is it a new problem with v0.88.17? How about this test build?

http://madshi.net/madVR8816b.rar

Does it show the same problem or not?

Please allow me to +1 the request of a few other SR users to please allow us specifying the number of passes and strength along with the new presets.
Not going to happen. We've found in the meanwhile that 1 pass with 1.0 strength is roughly identical to 2 passes with 0.5 strength. So there's no reason to use more than 1 pass with a strength of less than 1.0. That would be simply a waste of GPU performance for no good reason.

And that's *exactly* one of the reasons why I'm trying to reduce the options: To protect you from yourself. If I give you all the options, you're going to shoot yourself in the foot, by using settings that waste performance without any quality benefit, or which destroy quality.

OK. I would be very interested in some samples that show artefacts, because when I used them on mine, I was pleasently surprised by it's sharpness and detail retention.
Sure, when discussion gets to that. Not there yet.

With the new release all queues display as empty while playing and only fill when paused, though everything seems to work fine nevertheless.
I'm seeing the same thing. Happens both with D3D9 and D3D11. No frames seem to actually drop, so it must be a visual issue.
I was just about to report the same problem.
I'm not sure which change its from, but my OSD no longer seems to be reporting accurate information
Similar thing happens here on MPC-HC (x64) V1.7.9.54 (nightly).
For me the queues show as 0-x/x while playing and x-x/x while paused.
Strange thing. Can't reproduce it here! Can I get a debug log from each of you, please?

And do you get 0/x? Or 0-x/x? And either of that is constant? So you have 0/x or 0-x/x all the time?

a small tweak for some (later) build: could we get keyboard shortcuts for the new chroma upscaling algos (Bilateral, NEDI, s-xbr) as well as ability to switch to/from them with the "chroma upscaling algorithm - toggle" key?
Yes, for later. Please ask again when things have calmed down a bit. For now too many things are still changing each week.

crash with latest mpchc nightly. running svp latest too.
How about providing some more information? E.g. GPU and OS? Does it only occur with v0.88.17 or also with older builds? Do you get a madVR crash report? If so, show it to me.

[rack04]

Strange thing. Can't reproduce it here! Can I get a debug log from each of you, please?

And do you get 0/x? Or 0-x/x? And either of that is constant? So you have 0/x or 0-x/x all the time?

0-x/x all the time.

Log sent to madshi@gmail.com

[TheLion]

I've been following the discussion a bit and the problem might be that you're trying to do everything in linear light. For a simple unsharp mask filter you tend to get better results if you blur the image in linear light but subtract the unsharp mask in gamma light (or maybe even L*a*b). Unfortunately I couldn't immediately figure out how to apply this to finesharp, but at first glance the RemoveGrain11, FineSharpB parts should be done in linear light, for RemoveGrain4 it doesn't matter, so the LL artefacts are probably caused by either FineSharpA or FineSharpC.

Dear Mathias,

as much as I like FineSharp for HQ 1080p content the whole LL on/off topic keeps troubeling me. I can find examples where one option performs (much) better than the other, just to have another example where it is the other way round. I agree that animation like Anime is in average much worse with LL on. In conclusion both options are compromised (as is almost everything in life :) )

Is there any chance you find time to look into Shiandow's suggestion to combine LL on/off throughout different stages? Could be potentially more fruitful than investing more time in tuning an AR filter for FineSharp. my 2 cents

[Ver Greeneyes]

Strange thing. Can't reproduce it here! Can I get a debug log from each of you, please?
Constant 0-x/x.

I've uploaded a log here (http://www.mediafire.com/download/ak4xt74qcczxua2/madVR+-+log.rar) of playing for a few seconds, pausing and waiting a few seconds, then unpausing and playing for a few more seconds.

[leeperry]

Not going to happen. We've found in the meanwhile that 1 pass with 1.0 strength is roughly identical to 2 passes with 0.5 strength. So there's no reason to use more than 1 pass with a strength of less than 1.0. That would be simply a waste of GPU performance for no good reason.
Right, but if even if there's only a very slight PQ improvement with a slightly higher GPU load then what is the big deal? The diff between 128X and 256X NNEDI3 is not worth the load either but some ppl choose to use it anyway. I currently run 0.65 with 3 passes and I like it quite a bit, 2 passes don't seem enough to me and my GPU can take the load without cranking its fans so all is well...who cares about compromises when we're talking about PQ and such small GPU loads?

Many videophiles hate sharpening but SR is seductive as it seems like a smarter more advanced sharpening filter, some sources are softer than others so not allowing to change the SR settings will force us to use another "dumber" sharpening filters on top for no good reason :(

[michkrol]

Strange thing. Can't reproduce it here! Can I get a debug log from each of you, please?

And do you get 0/x? Or 0-x/x? And either of that is constant? So you have 0/x or 0-x/x all the time?

Basically I see one of two things, based on playback status:

During playback, the queues are between zero and full (based on OSD), showing 0-x/x constantly. The playback is smooth and stable, so it might be an OSD thing. Log and screen below:
http://www.mediafire.com/download/n8lj2gvev4yn7pp/madVR_-_log_-_playing.zip

http://i.imgur.com/hyeEas1.png
----------------------------------------------------
With playback paused, the queues are full, showing x-x/x constantly. Log (paused after ~1 second) and screen below:
http://www.mediafire.com/download/uzc29gzq4ny3p6l/madVR_-_log_-_paused_after_1_sec.zip

http://i.imgur.com/GZjv3Ke.png
----------------------------------------------------
I'm on Windows 8.1 (x64), MPC-HC (x64) v1.7.9.54 (nightly), Geforce 750Ti, drivers v353.38.
I hope the logs are long enough to show something useful.

[Braum]

To the guys who got completely empty queues, try setting smooth motion on and off.

When it's on I got empty queues (but it's not a problem for me as I don't use it).

[madshi]

Ok, thanks for the debug logs, everyone, bug already found. So you can stop sending debug logs now. It's just a cosmetical issue and only seems to affect smooth motion FRC. The queues are actually always full, it's just the OSD which reports it incorrectly. You can safely ignore that. Will be fixed in the next build.

as much as I like FineSharp for HQ 1080p content the whole LL on/off topic keeps troubeling me. I can find examples where one option performs (much) better than the other, just to have another example where it is the other way round. I agree that animation like Anime is in average much worse with LL on. In conclusion both options are compromised (as is almost everything in life :) )

Is there any chance you find time to look into Shiandow's suggestion to combine LL on/off throughout different stages? Could be potentially more fruitful than investing more time in tuning an AR filter for FineSharp. my 2 cents
I had tried Shiandow's suggestion, but didn't find a working solution on a quick check.

Right, but if even if there's only a very slight PQ improvement with a slightly higher GPU load then what is the big deal?
But there isn't any PQ improvement, and the GPU load is dramatically higher. E.g. 2 passes with 1.0 strength look pretty much identical to 4 passes with 0.5 strength, and 4 passes take exactly twice as much time as 2 passes.

I currently run 0.65 with 3 passes and I like it quite a bit
Try 2 passes with strength 1.0, should look identical. If not, show me comparison screenshots which show that 3 passes with 0.65 look better than 2 passes with 1.0.

[mogli]

There's also an issue with deinterlacing in this version. It causes a constant flicker like a stroboscope.

OS: win 8.1 x64
GPU: NVIDIA 353.30
deinterlacer mode: video (film is fine)
OSD: nothing unusual (no drops or glitches)
which files: all interlaced material I tested (both PAL and NTSC DVDs and Blu-rays)
window mode: happens in all modes

TEMPORARY SOLUTION: use half frame rate DXVA deinterlacing
The sideeffect is that repeated frames constantly increase.

[madshi]

Not on my PC.

Some of the bug reports recently have a surprisingly low amount of detail/information. Come on, you can do better than that.

GPU? OS? Forced film mode or DXVA deinterlacing? What does the OSD say? Does it occur with all interlaced video files or just with some? Does it occur both in windowed and FSE mode? Etc etc...

[leeperry]

But there isn't any PQ improvement, and the GPU load is dramatically higher. E.g. 2 passes with 1.0 strength look pretty much identical to 4 passes with 0.5 strength, and 4 passes take exactly twice as much time as 2 passes.

Try 2 passes with strength 1.0, should look identical. If not, show me comparison screenshots which show that 3 passes with 0.65 look better than 2 passes with 1.0.
"Pretty much", "roughly" are irrelevant when it comes to PQ and such small GPU loads IMVHO......but fair enough, I'll play around with 1.0@2X and will report back then.

BTW, so PotPlayer users will finally be able to pause mVR but they'll still have to switch to a TV channel as they more than likely don't want to leave a fixed image on for too long......I do know that many standalone DVD/BD players make a screensaver kick in after a few secs, it would only make sense to me to see mVR run something like the "Spotlight.hlsl" script from MPC-HC so we would all finally be able to pause mVR and stop worrying...pure class :cool:

[XMonarchY]

Is SuperRes Anti-Ringing filter integrated by default? I do not see a new option to enable Anti-Ringing.

Is algo 2 & 4 passes still considered to be an Ultra-quality setting?

[tobindac]

crashing when starting a dvb-t device/channel. correction that it wasn't on any video, adding on previous report about crash on latest mpc-hc nightly (also running svp latest).

[XMonarchY]

Don't set pre-presented frames in the NVIDIA control panel then, it messes madVR up quite considerably.
Luckily the NVIDIA panel has per-app settings!

I set all settings to default in NVidia CP and "Pre-rendered frames" are set to default "Use 3D application setting". That did not solve my problem.

With latest 88.17 madVR, even after madVR setting reset, my rendering times went WAY from 26ms to 37-40ms.