madVR - high quality video renderer (GPU assisted)

[huhn]

I could try to make a video but I guess it's just like you said: XP was a lot snappier....pretty ironic huh.

Basically I get a black frame for quite a while during every transition and with Aero enabled I get a random frame from the movie between the black frames, which is a lot more annoying :o

So on W8 you do get the slow updating black frame but no previous frame from the movie? The latter comes with Aero on W7SP1, I would enjoy a clear confirmation whether upgrading to W8/W10 would greet me with forced previous frames during transitions as Aero can't be disabled anymore.

windwo 8 and newer aero version is on a whole different level compared to totally broken windows 7 aero.

playback works really well without FSE.

but in the end all mode are different and different with AMD and nvidia on top.

for example windows 10 d3d11 10 bit FSE takes a lot longer to switch modes than any other mode on my system.

[huhn]

wouldn't x2 of 720p be 1440p?

chroma of videos is in nearly all cases 4:2:0 which is 540 for a 1080p video.

[flashmozzg]

chroma of videos is in nearly all cases 4:2:0 which is 540 for a 1080p video.

but It still won't give x2 factor if upscaling from 720p to 1080p, it would be x3 in this case (1080*2/720). Or I'm missing something?

[6233638]

wouldn't x2 of 720p be 1440p?With 4:2:0 video (practically all compressed video) chroma is half (a quarter? depends how you define it...) the resolution of luma.
So if the video is 720p, the chroma channel is 360p and must be scaled up 2x to match the luma resolution even if you are displaying the video 1:1 without upscaling.

In previous versions of madVR, scaling was basically performed in two steps:

Chroma is scaled from 360p to 720p with your selected chroma algorithm to create a 720p RGB image.
This 720p RGB image is scaled to 1080p (or whatever your output resolution is) using the luma algothirm.

(note: I am just using "RGB" as a shorthand for "full chroma resolution" - it may not internally be RGB)


What I'm wondering is if we now have:

Chroma: 360p → 1080p
Luma: 720p → 1080p

Or if that sort of scaling (scaling chroma directly to the output resolution) is only applied when downscaling, which seems like an acceptable solution when dealing with something like 4K on a 1080p or 1440p display.

I don't think that it would have changed, because that was originally implemented for quality reasons, but I just wanted to check that it was still the case before doing any more testing.

[huhn]

but It still won't give x2 factor if upscaling from 720p to 1080p, it would be x3 in this case (1080*2/720). Or I'm missing something?

in older madVR version the chroma scaler was just used to get the picture to 4:4:4 nothiing else. so a pure chroma doubling x2. for everythign else the image upscaler was used.

some things have changed so this isn't 100 % true anymore.

[flashmozzg]

Thanks for explanation.

[huhn]

With 4:2:0 video (practically all compressed video) chroma is half (a quarter? depends how you define it...) the resolution of luma.
So if the video is 720p, the chroma channel is 360p and must be scaled up 2x to match the luma resolution even if you are displaying the video 1:1 without upscaling.

In previous versions of madVR, scaling was basically performed in two steps:

Chroma is scaled from 360p to 720p with your selected chroma algorithm to create a 720p RGB image.
This 720p RGB image is scaled to 1080p (or whatever your output resolution is) using the luma algothirm.

(note: I am just using "RGB" as a shorthand for "full chroma resolution" - it may not internally be RGB)


What I'm wondering is if we now have:

Chroma: 360p → 1080p
Luma: 720p → 1080p

Or if that sort of scaling (scaling chroma directly to the output resolution) is only applied when downscaling, which seems like an acceptable solution when dealing with something like 4K on a 1080p or 1440p display.

I don't think that it would have changed, because that was originally implemented for quality reasons, but I just wanted to check that it was still the case before doing any more testing.

the OSD should tell you.


just use nnedi3 and look at the OSD when you upsacle. i can't do this my self right now the PC i'm using can't use nnedi3 chroma.

[cyberscott]

madVR 88.8 is the last version that the upload and Render queues fill completely when in FSE DX11 10bit mode for me.

With 88.9 and 88.10, render queue is stuck at 1-5 and upload queue is stuck at 3-6. Additionally, in both of these versions, the decoder queue shows one more than it should, example, 24-25/24 where normally, it would be 24-24/24. Queues fill normally when not using FSE.

Rolling back to 88.8 and all the queues work at they should in DX11 FSE 10 bit mode.

Problem occurs using MPC-HE and MPC-BE in both 32 and 64 bit versions, latest nightly builds.

I'm using latest nvidia driver 352.86 (Titan X), Windows 8.1 Pro 64 bit.

[Asmodian]

madVR 88.8 is the last version that the upload and Render queues fill completely when in FSE DX11 10bit mode for me.

Have you tried dropping the present/upload queue to 8 or even 6? That solved the stuck queue problem for others as well as myself.


What I'm wondering is if we now have:

Chroma: 360p → 1080p
Luma: 720p → 1080p

Or if that sort of scaling (scaling chroma directly to the output resolution) is only applied when downscaling, which seems like an acceptable solution when dealing with something like 4K on a 1080p or 1440p display.

This separate chroma scaling mode only triggers when downscaling luma below 65% (if chroma upscaling is MN through Spline) or 85% (if chroma upscaling is Jinc or NNEDI3).

So 4K on a 1440 screen will not trigger it if using a bicubic, lanczos, or spline for chroma upscaling but it will if using Jinc or NNEDI3.

[cyberscott]

Have you tried dropping the present/upload queue to 8 or even 6? That solved the stuck queue problem for others as well as myself.


No change in 88.10 if I drop the present/upload queue. Going back to 88.8 fixes the queue problem.

[Reign]

I am having an issue with the Ut Video codec, i just get a black screen and nothing happens. when i change MPC-HC to use the enhanced video renderer with custom preset it plays fine however.

I am not 100% if this is an issue with MADVR since it was working perfectly for the last 4 years and reverting to an old version of MADVR doesn't fix it.

I thought it might be my LAV decoders but an old version of those doesn't help either.

Does anyone have any ideas?

[TheShadowRunner]

madshi, madVR v0.88.9 & v0.88.10 both crash when exiting fullscreen here.

v.0.88.8 has no such issue. Here's a log (http://videoff7.free.fr/madVR_0.88.10 exit_fullscreen_crash.zip) with 0.88.10, I open the movie, go fullscreen, it plays ok. As soon as coming back to windowed mode, madvr crashes.

Thanks for your support.

[madshi]

With D3D9 fullscreen windowed new path they are: 0.12 ms

with D3D11 they are: around 0.55 ms
That's ok.

Just to be clear though, if chroma is being upscaled, it is always being upscaled 2x, yes? (e.g. 720p > 1080p)
No, if *luma* is being upscaled, chroma is always being upscaled 2x first. I think that's what you meant?

This had me wondering if there was a specific reason that some settings are locked out of profiles.
For example, I had to drop the present queue size down to 6 from 8 for 4K, and I'd prefer to set that with a profile instead of it being set globally.

And though it's not specific to 4K playback, I'd really like to set up profiles that change the calibration and color & gamma settings based on the source content.
I'd like to use 2.40 gamma for 480/576/1080p content (movies) and 2.20 gamma for all other source resolutions.
That's a setting I find myself changing quite often depending on the source content, so it would be very convenient to have that switch automatically.
Well, there are some settings where profiles don't make that much sense. E.g. why would you want to use different keyboard shortcuts? Some of the other settings that are locked out now might make sense, though, I'll add that to my to do list.

FWIW, supporting profiles in the "device" section is somewhat more difficult because the "device" section is dynamically built, depending on which monitors are detected. That's the main reason why those are not available for profiling yet. That's already on my to do list.

What I'm wondering is if we now have:

Chroma: 360p → 1080p
Luma: 720p → 1080p

Nothing has changed as long as the video (luma) is not downscaled. Which means that in your specific example chroma is doubled from 360p to 720p, and then the video frame is converted to R'G'B' and then afterwards scaled to 1080p.

The chroma handling has only changed if the video (luma) is downscaled. And even then only if the downscaling factor reaches a certain factor. So e.g. if you downscale a Blu-Ray from 1920x1080 to e.g. 1900x1070, chroma is usually still doubled first, then the video frame is converted to R'G'B', then the video frame is scaled down to 1900x1070. However, if you scale 1920x1080 down to 960x540 (or lower), chroma is *not* doubled, anymore (unless you activate linear light downscaling). For any target resolutions between 960x540 and 1919x1079, madVR may decide to double chroma or not, depending on the chroma scaling algorithm you selected and the exact luma downscaling factor.

But as I mentioned before, the OSD shows very clearly what it does. If you see "image >", chroma is doubled first, then the frame is converted to R'G'B', then upscaled. If you see "image <", chroma is doubled first, then the frame is converted to R'G'B', then downscaled. If you see "luma <", that means that both luma and chroma are downscaled separately from each other directly to the target resolution, and afterwards converted to R'G'B'.

madVR 88.8 is the last version that the upload and Render queues fill completely when in FSE DX11 10bit mode for me.

With 88.9 and 88.10, render queue is stuck at 1-5 and upload queue is stuck at 3-6. Additionally, in both of these versions, the decoder queue shows one more than it should, example, 24-25/24 where normally, it would be 24-24/24. Queues fill normally when not using FSE.

Rolling back to 88.8 and all the queues work at they should in DX11 FSE 10 bit mode.

Problem occurs using MPC-HE and MPC-BE in both 32 and 64 bit versions, latest nightly builds.

I'm using latest nvidia driver 352.86 (Titan X), Windows 8.1 Pro 64 bit.
That is a bit surprising. How are you rendering times with v0.88.8 and v0.88.10? Do they differ noticeably? Could it be that for some reason v0.88.10 is simply slower for you, so that rendering doesn't keep up with your scaling configuration? Which queues are full and which are empty?

madshi, madVR v0.88.9 & v0.88.10 both crash when exiting fullscreen here.

v.0.88.8 has no such issue. Here's a log (http://videoff7.free.fr/madVR_0.88.10 exit_fullscreen_crash.zip) with 0.88.10, I open the movie, go fullscreen, it plays ok. As soon as coming back to windowed mode, madvr crashes.
Unfortunately a debug log doesn't help with crashes. Do you get a madVR crash box? If so, I'd need the crash report. Or is it the media player which is crashing and not madVR? In that case it might still be madVR's fault, but it will be much harder to track down. Which media player are we talking about? And how exactly can I reproduce the problem? Does it only occur in DX11 mode (and only with 10bit output?) or also with DX9?

[omarank]

Can you play with the custom deband settings? You can activate them via custom keyboard shortcut (see settings dialog), and then you can modify the settings by using the arrow keys. You can then modify the "angleBoost" and "maxAngle" values to fine tune the angle analyzation stuff. Maybe you can find a setting for "high" which you like better than the old and current "high" preset?

Can you try to set the Maxangle at 0.10 or even 0.08?
At 0.08 I don't think that details are lost but the debanding is still stronger than with the old high preset.
I tried playing with the Custom Deband settings and settled on “angleBoost” 1.5 and “maxAngle” 0.08. With these settings, the debanding effect seems to be the same as with the old “high” preset and the image is apparently a bit sharper.

@Werewolfy: You found that “angleBoost” at 1.5 did some harm to a specific scene. Maybe you would want to test that again with the above settings. On all the samples that I tried, I didn’t see any kind of artifact or loss of detail with it set to 1.5. Can you post the original image or screenshot of the scene without debanding being applied?

[TheShadowRunner]

Unfortunately a debug log doesn't help with crashes. Do you get a madVR crash box? If so, I'd need the crash report. Or is it the media player which is crashing and not madVR? In that case it might still be madVR's fault, but it will be much harder to track down. Which media player are we talking about? And how exactly can I reproduce the problem? Does it only occur in DX11 mode (and only with 10bit output?) or also with DX9?
Yes, I got a crash box and a full report (http://videoff7.free.fr/madvrv0.88.10_crash_back_from_fullscreen.zip). I though the information would be more complete with a debug log, sorry ^^;
It's madVR that seems to crash, not the player (ZP).
Using DX9, on WinXP SP3 still.
Again this crash showed up with 0.88.9. I don't believe you can reproduce except if you're on XP (?).
In this case, just open the player, load a video, go in fullscreen mode (it plays fine) and then just go back to windowed mode (crash exactly happens at this point).

[QBhd]

So I decided to try the AMD registry hack to disable dithering on my R9 270X, and I am rather impressed with the way things turned out. I have a Plasma (circa 2007) with a 1024x768 rectangular pixel resolution... And I must say, it likes Ordered-Colored-Static dithering much better now. Without the reg hack, I always settled on ED1-Colored-Static, but Ordered seems to be a lot less noisy now... and I had done extensive testing when the dithering options were first implemented, and Ordered used to be very noisy. It seems that eliminating that intermediate dithering (GPU) outputs a cleaner picture. So, in this case (AMD, old Plasma and madVR), is this a placebo, or is there just too much dithering going without the registry hack. Thoughts? Anyone else with AMD and Plasma tried this?

QB

[Qaq]

if *luma* is being upscaled, chroma is always being upscaled 2x first.
Even if *luma* is being "upscaled" from 1076 to 1080 (WEB-DLs)?

[nevcairiel]

Even if *luma* is being "upscaled" from 1076 to 1080 (WEB-DLs)?

Of course. Even if Luma isn't being upscaled at all but just kept 1:1, you need to upscale chroma by 2x.

So in your case, Chroma is upscaled 2x to 1076, the image is converted to R'G'B', and then the entire image is upscaled to 1080.

[FireFreak111]

Windows 10 (build 10122), NNEDI3 is finally stable. I am able to use it with Nvidia 362.84 (WDDM 2.0) with no artifacts, no crashing, no green dots, nothing. Clean, sharp image. I am able to upscale Anime from 720p with 1.5x NNEDI3, apply SuperRes with the NNEDI3 settings, then downscale it back down with Catmull-Rom AR at 36ms on a GTX 660 with the newest madVR build (no drops for 5 mins with 8/4 queues). This is also using Jinc3 AR Chroma + SuperRes. Noticable thing though, Chroma is shown twice in the OSD, once before and after the Luma scaling. Is this a bug? Is Chroma meant to be done twice?

D3D11 Fullscreen Exclusive (8 bit, 10 bit works the same) is also working far better in the new build, no random failures, no crash when switching to FSE 25% of the time, really fast switch, I can switch back and forth ~10 times in 3-4 seconds with no issues. Present times are literally 0.08-0.10ms (3 frames ahead). I think madVR is completely stable at least on the Nvidia side. This is of course with the Frame for VSync option ticked, without it there are endless presentation glitches. I can run D3D11 Fullscreen Windowed with no glitches without that ticked however (0.5ms). All using MPC-HC latest nightly, and the whole chain done in 64 bit.

Thankyou for your work, I am happy madVR is finally stable and working well on Windows 10. The only option I could ask for is the dithering to match the Smooth Motion refresh rate rather than the video's playback rate as an option.

[nevcairiel]

The only option I could ask for is the dithering to match the Smooth Motion refresh rate rather than the video's playback rate as an option.

When you use SM, Dithering should already be performed at the refresh rate, since its the very last step in the entire process.

[Werewolfy]

I tried playing with the Custom Deband settings and settled on “angleBoost” 1.5 and “maxAngle” 0.08. With these settings, the debanding effect seems to be the same as with the old “high” preset and the image is apparently a bit sharper.

@Werewolfy: You found that “angleBoost” at 1.5 did some harm to a specific scene. Maybe you would want to test that again with the above settings. On all the samples that I tried, I didn’t see any kind of artifact or loss of detail with it set to 1.5. Can you post the original image or screenshot of the scene without debanding being applied?

I tested it and even if I set the maxAngle to 0.01, it harms the picture with Angleboost to 1.5.
Here's the video sample : https://dl.dropboxusercontent.com/u/16254258/test/bandingfest/Rurouni_Kenshin_-_01.mkv
Look at the left corner of the picture.

[Siso]

That's ok.

In max stats/present stats it shows more than 1.70 ms, is this ok?

[Qaq]

Even if *luma* is being "upscaled" from 1076 to 1080 (WEB-DLs)?Even if Luma isn't being upscaled at all but just kept 1:1, you need to upscale chroma by 2x.I understand L and C should be matched 1:1 in "size". I thought with 1-2% of "upscaling" chroma is being changed a very weird way.

[FireFreak111]

I am sort of eating my words on NNEDI3 being completely stable on Win 10. It works perfectly for Image Doubling and Chroma doubling, (if Chroma doubling the second Chroma > Jinc3 AR disappears), but for Chroma upscaling, it instantly crashes my display driver, and no image is shown (black screen). I can't pull up an OSD, but I can switch between FSE and windowed. Restarting MPC-HC with Jinc3 AR brings back the image. Same occurs if I reenable NNEDI3.

Shame, since its almost completely working. Any idea why only Chroma upscaling would be broken? Win 10 likely won't be released until mid July, so there's some time before it needs to be directly addressed, its just puzzling that Chroma doubling works but Chroma upscaling doesn't.

When you use SM, Dithering should already be performed at the refresh rate, since its the very last step in the entire process.
That's good to hear then, no other features I can think of besides a final choice on the debanding algo's.

[vivan]

When you use SM, Dithering should already be performed at the refresh rate, since its the very last step in the entire process.SM doesn't blend frames at refresh rate, it only blends frames that overlap. E.g. for 24 fps over 60 hz: A A AB B B. That's 3 unique frames for 5 refreshes, not 5.

[mogli]

Some more with 'present a frame for every VSync' turned off:
Found a NTSC file which reliably causes constant glitches only in FSE mode with deinterlacing off then. Using deinterlacing (video or film) in FSE mode or windowed mode (with or without deinterlacing) or turning 'every VSync' on will not glitch.

[x7007]

FSE mode 10bit just doesn't run well for me in windows 7.

If I use FSE 10 bit + Exclusive mode in Potplayer I just get high rendering up to 40ms , in windows mode it's 22 ms. I can't understand what is the issue.

Windows 7 x64
Potplayer x32 Exclusive Mode Enabled - fastest

How much rendering do you get in FSE 10 bit ?

It happens in all sources , MKV , 1080P , Blu-ray AVC . 720p.

EDIT : If I enable " Present a frame for every sync " The rendering goes to 30ms but Render Queue and Present Queue doesn't max out. Render 2-8 /8 - Present 1-3 /3 . it should be Render 7-8 /8 , Present 2-3 /3. How to fix this bug or settings or what causing this.

[nevcairiel]

SM doesn't blend frames at refresh rate, it only blends frames that overlap. E.g. for 24 fps over 60 hz: A A AB B B. That's 3 unique frames for 5 refreshes, not 5.

Actually thats incorrect. It may appear a simple choice to do it like this, but it is not the way SM works. I assumed that at first as well, but madshi corrected me.

Its more like this:

24p: 0ms=A, 42ms=B

60p: 0ms=A, 16ms=0.6A/0.4B 32ms=0.2A/0.8B, 48ms=0.9B/0.1C

(Factors and times rounded for simplicity)

A clean "A" is only output when the timestamps match perfectly, otherwise there is always blending performed. In the chain above, C would be output clean again at 83/84ms.
As a result of this, you can pretty much assume you get a new frame for every refresh.

If you think about it, it also makes sense. Only this way you can actually get rid of the 3:2 judder, the more simple approach wouldn't eliminate it.

[vivan]

If you think about it, it also makes sense. Only this way you can actually get rid of the 3:2 judder, the more simple approach wouldn't eliminate it.Nope, it doesn't :P Try avisynth's ConvertFPS (60) - you'll see crazy amount of blending.

When rates don't perfectly match (which indeed always happens) - instead of last clean B you get BC. Basically two 3:2 patterns are blended together. That gives 2 same clean frames in succession for every pattern (5 refresh rates) or 48 fps.
SM capture https://dl.dropboxusercontent.com/u/16254258/test/sm/mpc-hc%2029-05-2015%2014-13-16.mp4
1-bit dithering without SM https://dl.dropboxusercontent.com/u/16254258/test/sm/mpc-hc%2029-05-2015%2014-27-30.mp4
1-bit dithering with SM https://dl.dropboxusercontent.com/u/16254258/test/sm/mpc-hc%2029-05-2015%2014-27-50.mp4

(but it's possible to make them match by messing with audio - AFAIK this is what mpv does, they have fixed pattern and built-in "reclock")

[Anime Viewer]

How high are your present numbers exactly? Anything lower than 1ms should be ok.

I didn't realized present ms is normally supposed to be so low. Mine only seem to run as low as 3.10ms-5ms (720p expanded to 1920x1080), 1.96ms (in 720p native window), 7.51ms-9ms (480 video expanded to 1920x1080) 2.26ms 480 native window. (When I say native window size I mean with settings of Zoom 100%, and normal size for video frame in view settings in MPC-HC). I've experimented with present frames in advance settings in every setting from 14 to 1 with nothing better than those stats (and with settings as low as 1 my present queue tends to drop to 0 and report presentation glitches and dropped frames).
What other settings besides present frames in advance may be effecting present ms?
(My Nivida settings for mpc-hc are set to set to maximum pre-rendered frames use global settings (use the 3d application setting), and virtual reality pre-rendered frames (guessing this had no baring since its only supposed to effect virtual reality head sets) also at use global settings (use the 3d application setting)).

[Sunset1982]

Madshi is there a roadmap for future features or do you habe any feautre plans?

[ryrynz]

Anyone here can answer that :P No roadmap and he doesn't divulge future plans, sometimes he lets the cat out of the bag early though.

[huhn]

Nope, it doesn't :P Try avisynth's ConvertFPS (60) - you'll see crazy amount of blending.

When rates don't perfectly match (which indeed always happens) - instead of last clean B you get BC. Basically two 3:2 patterns are blended together. That gives 2 same clean frames in succession for every pattern (5 refresh rates) or 48 fps.
SM capture https://dl.dropboxusercontent.com/u/16254258/test/sm/mpc-hc%2029-05-2015%2014-13-16.mp4
1-bit dithering without SM https://dl.dropboxusercontent.com/u/16254258/test/sm/mpc-hc%2029-05-2015%2014-27-30.mp4
1-bit dithering with SM https://dl.dropboxusercontent.com/u/16254258/test/sm/mpc-hc%2029-05-2015%2014-27-50.mp4

(but it's possible to make them match by messing with audio - AFAIK this is what mpv does, they have fixed pattern and built-in "reclock")

i see the same and there is a easy way to test this.

disable present frames in advance
take a 23p source and play at 60 hz with smooth motion.

now look at the MPC-HC statistics you will see about ~48 FPS

[pirlouy]

I think Nevcairiel is right for Smooth Motion:
http://forum.doom9.org/showthread.php?p=1616533#post1616533

The exact blending factors (and whether blending is needed at all) are calculated for every vsync interval. The blending factors usually change all the time.

[madshi]

Yes, I got a crash box and a full report (http://videoff7.free.fr/madvrv0.88.10_crash_back_from_fullscreen.zip). I though the information would be more complete with a debug log, sorry ^^;
It's madVR that seems to crash, not the player (ZP).
Using DX9, on WinXP SP3 still.
Again this crash showed up with 0.88.9. I don't believe you can reproduce except if you're on XP (?).
In this case, just open the player, load a video, go in fullscreen mode (it plays fine) and then just go back to windowed mode (crash exactly happens at this point).
Ok, will look at that later.

So I decided to try the AMD registry hack to disable dithering on my R9 270X, and I am rather impressed with the way things turned out. I have a Plasma (circa 2007) with a 1024x768 rectangular pixel resolution... And I must say, it likes Ordered-Colored-Static dithering much better now. Without the reg hack, I always settled on ED1-Colored-Static, but Ordered seems to be a lot less noisy now... and I had done extensive testing when the dithering options were first implemented, and Ordered used to be very noisy. It seems that eliminating that intermediate dithering (GPU) outputs a cleaner picture. So, in this case (AMD, old Plasma and madVR), is this a placebo, or is there just too much dithering going without the registry hack. Thoughts? Anyone else with AMD and Plasma tried this?
You see a difference even with 8bit output? That's surprising. I would have expected AMD dithering to only be active when using 10bit output (and only when using a display which doesn't support 10bit).

I tried playing with the Custom Deband settings and settled on “angleBoost” 1.5 and “maxAngle” 0.08. With these settings, the debanding effect seems to be the same as with the old “high” preset and the image is apparently a bit sharper.

@Werewolfy: You found that “angleBoost” at 1.5 did some harm to a specific scene. Maybe you would want to test that again with the above settings. On all the samples that I tried, I didn’t see any kind of artifact or loss of detail with it set to 1.5. Can you post the original image or screenshot of the scene without debanding being applied?
I tested it and even if I set the maxAngle to 0.01, it harms the picture with Angleboost to 1.5.
Here's the video sample : https://dl.dropboxusercontent.com/u/16254258/test/bandingfest/Rurouni_Kenshin_-_01.mkv
Look at the left corner of the picture.
So 1.4 and 0.08 it is?

In max stats/present stats it shows more than 1.70 ms, is this ok?
Yes.

I am sort of eating my words on NNEDI3 being completely stable on Win 10. It works perfectly for Image Doubling and Chroma doubling, (if Chroma doubling the second Chroma > Jinc3 AR disappears), but for Chroma upscaling, it instantly crashes my display driver, and no image is shown (black screen). I can't pull up an OSD, but I can switch between FSE and windowed. Restarting MPC-HC with Jinc3 AR brings back the image. Same occurs if I reenable NNEDI3.

Shame, since its almost completely working. Any idea why only Chroma upscaling would be broken? Win 10 likely won't be released until mid July, so there's some time before it needs to be directly addressed, its just puzzling that Chroma doubling works but Chroma upscaling doesn't.
No idea. Can anybody else reproduce this?

FSE mode 10bit just doesn't run well for me in windows 7.

If I use FSE 10 bit + Exclusive mode in Potplayer I just get high rendering up to 40ms , in windows mode it's 22 ms. I can't understand what is the issue.

Windows 7 x64
Potplayer x32 Exclusive Mode Enabled - fastest

How much rendering do you get in FSE 10 bit ?

It happens in all sources , MKV , 1080P , Blu-ray AVC . 720p.

EDIT : If I enable " Present a frame for every sync " The rendering goes to 30ms but Render Queue and Present Queue doesn't max out. Render 2-8 /8 - Present 1-3 /3 . it should be Render 7-8 /8 , Present 2-3 /3. How to fix this bug or settings or what causing this.
Do you have an NVidia GPU? Then double check that the setting "max prerendered frames" (or something like that) is set to application control.

I didn't realized present ms is normally supposed to be so low. Mine only seem to run as low as 3.10ms-5ms (720p expanded to 1920x1080), 1.96ms (in 720p native window), 7.51ms-9ms (480 video expanded to 1920x1080) 2.26ms 480 native window. (When I say native window size I mean with settings of Zoom 100%, and normal size for video frame in view settings in MPC-HC). I've experimented with present frames in advance settings in every setting from 14 to 1 with nothing better than those stats (and with settings as low as 1 my present queue tends to drop to 0 and report presentation glitches and dropped frames).
What other settings besides present frames in advance may be effecting present ms?
(My Nivida settings for mpc-hc are set to set to maximum pre-rendered frames use global settings (use the 3d application setting), and virtual reality pre-rendered frames (guessing this had no baring since its only supposed to effect virtual reality head sets) also at use global settings (use the 3d application setting)).
Not sure why the numbers are so bad for you. Is it the same for D3D9 with "use a separate device for presentation" either enabled or disabled?

-------

About smooth motion FRC. You can think of it like this: madVR tries to simulate a digicam which is filming a perfect monitor, with the digicam framerate being identical to the refresh rate of the GPU output.

E.g. the perfect monitor for 24fps would display the "video frames" ("vf") like this:

[-vf.1-][-vf.2-][-vf.3-][-vf.4-]

Now imagine a digicam filming this at 60fps:

[ vf1 ][ vf2 ][ vf3 ][ vf4 ]
[d1][d2][d3][d4][d5][d6][d7][d8][d9]
You can easily see that the "d1" and "d2" digicam frames only cover the "vf1" video frame. So madVR doesn't blend either "d1" or "d2". madVR actually only renders "d1" and not "d2" to save performance. "d3" is blended, using 0.25 * vf1 + 0.75 * vf2. "d4" is not blended etc.

If you think about it, what madVR does is pretty much the same as what a digicam would capture. And that's good enough to achieve smooth motion. If I blended every frame, the result would not be smoother, just more blurry. The exact blending factors are not fixed, but are calculated dynamically, based on the exactly measured vsync position.

[huhn]

Same here.

I've tried to find any API that would tell me whether the GPU actually outputs 10bit or not, but I've not found anything, at least not nothing official GPU independent from Microsoft. I can see that Direct3D11 actually tells the GPU driver to output 10bit, and the driver accepts it, although I know for a fact that my display doesn't support 10bit. So basically it's a black box and I don't know what the GPU is doing with my 10bit output... :(

my new TV shows the input bit deep. i test nvidia later to see what the GPU is outputting under different situations.

the screen needs to be replaced. so not much time to test with it for now.

[aufkrawall]

I still think that Shiandow with low power is a nice addition to the madVR high deband setting of the current build (judged by the Tagesschau sample).

[kalston]

You see a difference even with 8bit output? That's surprising. I would have expected AMD dithering to only be active when using 10bit output (and only when using a display which doesn't support 10bit).


AFAIK it applies for 8bit too, people have reported a significantly better PQ on AMD cards when using icc profiles because of that (with nvidia you get noticeable banding with icc profiles).
- I don't use AMD hardware, I don't know anything more than that but I have read it many times, especially when those cheap (and overclockable) Korean 1440p panels were the craze and required calibration to look decent.

[QBhd]

You see a difference even with 8bit output? That's surprising. I would have expected AMD dithering to only be active when using 10bit output (and only when using a display which doesn't support 10bit).


I will double check and triple check... like I said, I was wondering if I was falling victim to placebo effect. But yes, after the reg hack I thought I saw a difference. I will remove them and test the dithering options again to be certain.

QB

[Shiandow]

If you think about it, what madVR does is pretty much the same as what a digicam would capture. And that's good enough to achieve smooth motion. If I blended every frame, the result would not be smoother, just more blurry. The exact blending factors are not fixed, but are calculated dynamically, based on the exactly measured vsync position.

By the way, I've been wondering, do you also change the blending factors depending on the horizontal position of the image? It seems like that would matter as well, at least for most screens.

[vivan]

By the way, I've been wondering, do you also change the blending factors depending on the horizontal position of the image? It seems like that would matter as well, at least for most screens.Horizontal position? Can you elaborate?

[Shiandow]

Horizontal position? Can you elaborate?

A frame isn't displayed all at once (on most screens anyway) it is displayed line for line, this is why you see tearing when you change an image midway (except during the vsync). It takes quite a long time before all lines are painted so if it's say 70% frame A and 30% frame B when it starts painting, it might need to be something like 30% A and 70% B by the time it reaches the bottom (these numbers are just an example, not an educated guess).

I'm not sure if it makes any visible difference in image quality, but since madshi seems to make quite a lot of effort to ensure that the blending factors are as exact as possible, I was wondering if he took into account when which part of the image is displayed.

[G_M_C]

People, i need some help getting the DX11 path to activate.

I want to try to use DX11 for the possibility of improvements in performance (10bit out is only the secondary reason at this time). But regardless of what i do, the OSD keeps saying madVR is using D3D9 [new path]. I cant seem to be able to get the DX11 path running.

I have an AMD 7850, with catalyst 14.12.
I'm on Win7-64, DirectX is up to date.
I use latest stable MPC-HC and latest version madVR.

I've followed all the tips i found in this thread and the in the thread for testing the 10bit output. I've even set the dword for disabling dithering.

Can someone point me in the right direction, i've got the feeling im missing (of have missed) something.

[kalston]

Windows 7 platform update perhaps? It was only an optional update so no matter how up to date your Windows install is, you could be missing that. I know I don't have it because it was said to cause some serious issues back in the day but I'm happy with overlay mode and waiting to jump on Windows 10 anyway so not sure I'm going to bother.

[leeperry]

^ Yeah, google shows scary testimonials regarding this update....my box is rock stable atm, will wait for W10.

[omarank]

I tested it and even if I set the maxAngle to 0.01, it harms the picture with Angleboost to 1.5.
Here's the video sample : https://dl.dropboxusercontent.com/u/16254258/test/bandingfest/Rurouni_Kenshin_-_01.mkv
Look at the left corner of the picture.
You are referring to a thin dark-gray strip at the extreme left which gets debanded when “angleBoost” is set to 1.5. If we consider that strip to be some kind of detail, then 1.4 is the max that we can set otherwise 1.5 is just fine. In my opinion, 1.5 is doing a better job on this sample as I prefer the results with the gray strip blended with the surroundings. Have you noticed any detail getting lost with 1.5 in any other sample, which is preserved with 1.4?

So 1.4 and 0.08 it is?
I still prefer “angleBoost” 1.5 and “maxAngle” 0.08. However, if you set “angleBoost” to 1.4, I have no problems.

[madshi]

A frame isn't displayed all at once (on most screens anyway) it is displayed line for line, this is why you see tearing when you change an image midway (except during the vsync).
I think tearing is not caused by the display, but it's caused by the GPU. These days we have digital connection via DVI or HDMI. And this connection works by sending full frames to the display. The display then receives these frames and displays them one by one. Whether the display internally draws the frames line by line or not doesn't really matter. We can treat the display as a black box. It shouldn't matter to us what the display does, as long as it does its job reasonably well.

If we see tearing, this is caused by the GPU producing a video frame which has tearing baked into it. This is caused by someone (e.g. Direct3D) writing to the front buffer while the front buffer is in the process of being send out via HDMI. This produces a frame which has tearing hard coded into it, and there's nothing the display could do to get rid of the tearing.

The solution to tearing is to not write to the active front buffer at all, but to flip the front buffer during the VSync hardware interrupt. That's what FSE mode does, I think (hope). The "problem" with waiting for the next VSync interrupt is that you have wait a while until the VSync interrupt occurs again. For video playback that's no problem, but for games it means that even if the GPU is already done rendering a new frame, the GPU can't send it to the display yet. Because of that gamers often disable VSync, so that newly rendered frames appear on screen as quickly as possible. Obviously this must produce tearing. And this is where FreeSync comes in: Instead of waiting for the next VSync interrupt to occur, Direct3D simply tells the GPU to produce a new VSync interrupt immediately. Great for games, not as much useful for video playback. And no, please no further FreeSync discussion in this thread. Thanks.

[Werewolfy]

You are referring to a thin dark-gray strip at the extreme left which gets debanded when “angleBoost” is set to 1.5. If we consider that strip to be some kind of detail, then 1.4 is the max that we can set otherwise 1.5 is just fine. In my opinion, 1.5 is doing a better job on this sample as I prefer the results with the gray strip blended with the surroundings. Have you noticed any detail getting lost with 1.5 in any other sample, which is preserved with 1.4?

I still prefer “angleBoost” 1.5 and “maxAngle” 0.08. However, if you set “angleBoost” to 1.4, I have no problems.

No, I didn't notice any details being lost in another picture but I don't like this kind of artefact and it could be worst in another scene. If 1.5 was a big improvement over 1.4 for debanding I would take the leap but the benefit here is very very small.

You know the high preset already use much higher values than the other presets and angleBoost set to 1.4 multiplies each values by 1.4 so I don't think we need even higher values. Here I just propose these settings because I read sometimes that people want a tad better debanding for this preset. If we can do it without harming the picture, there is no reason to hesitate but I don't feel that's the case with 1.5.


So 1.4 and 0.08 it is?


Yes, it is ;)

[G_M_C]

People, i need some help getting the DX11 path to activate.

I want to try to use DX11 for the possibility of improvements in performance (10bit out is only the secondary reason at this time). But regardless of what i do, the OSD keeps saying madVR is using D3D9 [new path]. I cant seem to be able to get the DX11 path running.

I have an AMD 7850, with catalyst 14.12.
I'm on Win7-64, DirectX is up to date.
I use latest stable MPC-HC and latest version madVR.

I've followed all the tips i found in this thread and the in the thread for testing the 10bit output. I've even set the dword for disabling dithering.

Can someone point me in the right direction, i've got the feeling im missing (of have missed) something.

Never mind everybody. I figured it out, it was something i hadn't thought about ... i was still running windows classic theme. And that doesnt make the Dx11 path work ;-)

Thanx for the help though everybody.

[avinab]

Ok, will look at that later.


You see a difference even with 8bit output? That's surprising. I would have expected AMD dithering to only be active when using 10bit output (and only when using a display which doesn't support 10bit).



So 1.4 and 0.08 it is?


Yes.


No idea. Can anybody else reproduce this?


Do you have an NVidia GPU? Then double check that the setting "max prerendered frames" (or something like that) is set to application control.


Not sure why the numbers are so bad for you. Is it the same for D3D9 with "use a separate device for presentation" either enabled or disabled?

-------

About smooth motion FRC. You can think of it like this: madVR tries to simulate a digicam which is filming a perfect monitor, with the digicam framerate being identical to the refresh rate of the GPU output.

E.g. the perfect monitor for 24fps would display the "video frames" ("vf") like this:

[-vf.1-][-vf.2-][-vf.3-][-vf.4-]

Now imagine a digicam filming this at 60fps:

[ vf1 ][ vf2 ][ vf3 ][ vf4 ]
[d1][d2][d3][d4][d5][d6][d7][d8][d9]
You can easily see that the "d1" and "d2" digicam frames only cover the "vf1" video frame. So madVR doesn't blend either "d1" or "d2". madVR actually only renders "d1" and not "d2" to save performance. "d3" is blended, using 0.25 * vf1 + 0.75 * vf2. "d4" is not blended etc.

If you think about it, what madVR does is pretty much the same as what a digicam would capture. And that's good enough to achieve smooth motion. If I blended every frame, the result would not be smoother, just more blurry. The exact blending factors are not fixed, but are calculated dynamically, based on the exactly measured vsync position.


Yes in windows 10 i am also not able to enable NNEDI3 in chroma upscaling,madvr instantly crashes so unable to get any OSD details.I have sent the crash report through MADVR application. Also cannot enable chroma or luma doubling,it works in windowed mode and if i do full screen(not exclusive mode) madvr crases.@madashi please look into it.I have reported it many times but nobody has acknowledged it.I am using gtx 980 and on 353.84 driver.:(:(:(:(:(