madVR - high quality video renderer (GPU assisted)

[madshi]

I was indeed thinking about just adding an additional queue for the fade and in turn increase its length. I didn't think about the RAM and thought you just didn't feel like adding yet another queue or didn't want to make it too long. I wasn't affected, just wondering.

Well, I thought queues are there to ensure fluid playback, i.e. having some security net/buffer for avoiding dropped frames. Resetting a queue fully or partly/reprocessing frames means decreasing that security and results in more dropouts on average even if most users aren't affected and it can be worked-around/turned off easily. Maybe I'm missing something.
You're missing how important GPU RAM is. If you have GPU RAM to spare, you can turn up the GPU queues to insane lengths. If you're short on GPU RAM, your preferred solution won't work, either. To sum up:

Your preferred solution:
(1) introduce a new fade queue
(2) increase queue size for decoder, IVTC, deinterlace, upload, DXVA scaling and fade queues by 5 frames
(3) this results in the render queue always staying at 15-16/16
(4) this solution is technically quite complicated, which a new queue, and different queue sizes for different GPU queues
(5) this solution requires higher GPU RAM consumption

The current madVR implementation:
(1) no changes at all to queue/render design
(2) no increase in GPU RAM consumption
(3) if a fade is detected (and only then and only for a short time) the render queue goes down to 11/16

Your solution only works if you have GPU RAM to spare. But if you *DO* have GPU RAM to spare, you could also do this:

The current madVR implementation with 5 frames longer GPU queues:
(1) no changes at all to queue/render design
(2) this solution requires higher GPU RAM consumption
(3) if a fade is detected, the render queue goes down to 16/21, otherwise it stays at 20-21/21 all the time

So what is better? Having the render queue at 15-16/16 all the time? Or having it at 20-21/21 during 99.9% of the movie runtime, and it dropping to 16/21 during 0.1% of the time? Comparing your solution with 16/16 all the time, to my solution with GPU queue size increased to 21, my solution seems much better to me. It has a better queue saturation per GPU RAM ratio. And a much simpler design.

I currently use the sRGB profile on my monitor and the default settings in Windows Color management (No ICC profile). I've set "this display is already calibrated" (while it's not) with BT.709 and pure power curve 2.20 in the calibration tab. However, some guides about calibration advice to set pure power curve to 2.40 with sRGB. Is it true or not ?
Which gamma curve you select there makes no difference unless you activate gamma processing (IIRC).

Another question : should I keep my actual settings or change for "disable calibration controls for this display" in the calibration tab and enable gamma processing in the color & gamma tab ?
Disabling calibration controls means that madVR will not convert DVDs to BT.709 gamut. The difference is small. But keeping your current settings might be the better choice.

[bacondither]

I haven't found the new fading algorithm useful i any case, but if someone have a clip where the "strength during fade/in out" is useful please post it.
The fading detection seems to flicker on and off in scenes withouth fading or stay constant on in other scenes or after a fade. It must be hard for a algorithm to decide that with good results.

[Werewolfy]

Huh!? Where did you get *that* impression from? If you're talking about the reported frame drops, that's not a performance problem, but a simple logic bug in the current build, which is already fixed in my sources, and which btw never introduced any visible stuttering. The simple bug was that a smooth motion blended frame which should have been deleted by the fade detection wasn't deleted. So there suddenly were two blended frames for the same situation. So one was dropped, without causing a visual problem. So the only real "problem" was that the OSD reported a dropped frame. But the dropped frame was superfluous, anyway.

The issue I mentioned earlier does create stuttering, this is how I noticed it in 24hz. It's pretty obvious during panning shots. It's not a performance problem, even if I use Bicubic instead of Jinc for upscaling it doesn't change anything.

[madshi]

Well, in any case, it's already fixed in my sources.

[bacondither]

This is a short sample recorded with fraps and the fade in/out set ridicilous high so you can se when it activates.
sample (http://www.sendspace.com/file/tk2gz7)

[madshi]

I haven't found the new fading algorithm useful i any case, but if someone have a clip where the "strength during fade/in out" is useful please post it.
It should be useful whenever you have a movie where "low" may not fully fix all banding problems. In that situation having a higher debanding strength during fades should help making fades more stable, while not hurting image detail in all other scenes.

The fading detection seems to flicker on and off in scenes withouth fading or stay constant on in other scenes or after a fade. It must be hard for a algorithm to decide that with good results.
The hard part is making the detection work without losing too much CPU and GPU performance. But I've already implemented some improvements in my sources that seem to avoid "false positives" quite nicely. So the problem you've noticed now might already be solved in the next build.

[jpavic019]

Can i use madvr as video render in mpchc at the highest settings(Chroma upscaling- jinc 3 taps (AR), image upscaling-jinc 3 taps(AR) and image downscaling-catmul rom (AR,LL) ) on my pc without any sttutering and lagging?
my pc specs are: : CPU- Intel Core i3 2120 @ 3.30GHz
Motherboard: Asus P8H61-MX R2.0
Gpu: MSI Radeon Hd 7750 1GB DDR 5 (R7750-1GD5/OC)
Ram : 8 gb
I mostly watch 1080p and 720p movies

[madshi]

You should be able to, at least when using fullscreen exclusive mode. Maybe you could run into trouble when using DXVA deinterlacing, but that only applies to interlaced material. And for movies you can force on film mode, which will make everything run smooth again. DXVA deinterlacing results in double framerate (60p output) which doubles the requires GPU power. That's why it's extra demanding. As long as you stay with 24p/30p progressive content, I think your GPU should do the highest settings just fine.

[leeperry]

Yes, but with a rather bad quality. On a quick check I think if the 6 zones noticeably differ with that PS script, you might actually see the zone boundaries. Furthermore that script doesn't work in linear light, so you'll get discoloration in pixel on/off test patterns. Finally, the convergence correction seems to be done with bilinear filtering which will soften up the image. madVR's convergence correction should not have any of these problems (I hope).
Oh.......would you have the same negative remarks to make about those two scripts please?

Mirroring:
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, float2(1 - tex.x, tex.y));
}
Flipping:
sampler s0 : register(s0);

float4 main(float2 tex : TEXCOORD0) : COLOR
{
return tex2D(s0, float2(tex.x, 1 - tex.y));
}
:thanks:

[madshi]

Those should be fine.

[e-t172]

Hi everyone,
I currently use the sRGB profile on my monitor and the default settings in Windows Color management (No ICC profile). I've set "this display is already calibrated" (while it's not) with BT.709 and pure power curve 2.20 in the calibration tab. However, some guides about calibration advice to set pure power curve to 2.40 with sRGB. Is it true or not ?

No. You should keep it that way. If you don't have any information about your monitor's color response you have to assume that it at least tries to get as close to sRGB as possible, and the best settings to use with sRGB are the ones you chose.

[dansrfe]

According to your log switching to exclusive mode worked just fine. Can you clarify "stopped working"? Some more details might help.

False alarm. The problem was related to NVIDIA GeForce Experience interfering with the custom refresh rates I had set with CRU. The custom refresh rates wouldn't show up in the monitor's device properties yet it would show up in NVIDIA's control panel. After uninstalling GeForce Experience everything works as expected when switching to FSE.

[turbojet]

So when you say "It doesn't appear noticeably faster for me" what do you mean exactly? That the face doesn't appear faster for you with Werewolfy's video sample, when using "medium" instead of "high" debanding for fade in/outs? Or are you talking about the madVR rendering times? Or what?

The feedback I was hoping to get is whether I should use "medium" or "high" as a default option for debanding during fade ins/outs.

The face doesn't noticeably appear faster for me but there is a bit more detail when frame stepping with 'medium' vs. 'high' but it's also not noticeable to me during playback.

Concerning fades there's many in this clip (http://www.sendspace.com/file/otfqcw) which are handled fine but the one at 5 seconds has a lot of banding. Is there anything that can be done with this?

Also does anyone else have issues with playback starting before a display mode change (60 to 72hz for example) is finished? Would this be a madvr or a player issue?

[Asmodian]

Also does anyone else have issues with playback starting before a display mode change (60 to 72hz for example) is finished? Would this be a madvr or a player issue?

That actually sounds like a display issue to me. Does your display take a while to show a picture after a refresh rate change? I have one monitor that takes at least three times longer to display a picture after a refresh rate change than my other screens and I often hear the audio before it starts displaying a picture. As far as the computer is concerned the change was finished a long time ago.

[dansrfe]

Does dithering need to be disabled for calibration because I see faint blocking on all color patches, distributed across the entire patch. It may be affecting the i1 Display Pro's accuracy. This is using the command line procedure in post 2 of the madVR/ArgyllCMS thread on AVS.

[huhn]

these blocks aren't dithering noise they are so huge on my tn panel... 5x5 or so i make a screen later.

edit: this is not on screenshoots. but i was able to record it (very strange)

http://abload.de/img/madtpg01.mp4_snapshot3ef7p.png the dots are huge on a 6 or 7 bit dithering panel like my asus vg248. this screen was done with "don't use dithering".

[sneaker_ger]

@madshi
Thanks for the detailed answer. There's one thing I'm still uncertain concerning the re-rendering and the fade detection: at which point does it actually take place? Does madVR have to re-request frames from the decoder or does this not happen as its own decoder queue is unaffected?

[LigH]

@ huhn:

The system "Screenshot" function [PrtScr] only captures the desktop, but many renderers instead use a memory area distant to the desktop (e.g. the "Hardware Overlay" or an offscreen DirectShow canvas). The player provided capture function will take a picture before it is rendered. You may have to either use an accelleration API aware tool, or really use a camera...

[huhn]

the screen is showing the problem.

i took it with openbroadcast software and game capture.

i can't see it on my tv right now but on my tn panel display is not possible to overview this...

[leeperry]

Yes, now it will give you BT.1886 without elevating the 0 black step, thus not sacrificing contrast ratio
using ArgyllCMS1.61...uncalibrated, D65 but funky gamma-land:
Black level = 0.04 cd/m²
50% level = 29.87 cd/m²
White level = 149.57 cd/m²
Aprox. gamma = 2.32
Contrast ratio = 3419:1
dispcal -v -yl -t6500 -G2.4 -f0 -qm test:
Black level = 0.05 cd/m²
50% level = 31.18 cd/m²
White level = 146.09 cd/m²
Aprox. gamma = 2.23
Contrast ratio = 2884:1
a lighter gamma and +0.01 black, I was hoping for a darker gamma tbh :o

This said I get nearly perfect gamma now: http://thumbnails108.imagebam.com/28933/0beaff289322322.jpg (http://www.imagebam.com/image/0beaff289322322)

I also wish there were a way to build an mVR-compatible 3DLUT out of a .cal file but apparently this isn't possible.

[turbojet]

That actually sounds like a display issue to me. Does your display take a while to show a picture after a refresh rate change? I have one monitor that takes at least three times longer to display a picture after a refresh rate change than my other screens and I often hear the audio before it starts displaying a picture. As far as the computer is concerned the change was finished a long time ago.

About 3 seconds which is pretty long. While not a big deal would madshi consider a delay after display change at some point?

This is one advantage of mpc's slower loads over potplayer. The former only plays for about a second before video displays, the latter about 3.

[LigH]

the screen is showing the problem.

Oh, yes; I had to turn up the gamma extremely to see any. :cool:

[huhn]

and on a bad panel it doesn't matter you always see them.

[LDD9O]

Has madVR close reaching it peaks? And we will not see any major update for years to come?

[pirlouy]

Strange way to ask for future plans. Anyway, Madshi does not (like to) talk about his future plans and he is still active to fix bugs.

[leeperry]

Humm, not sure why but whatever I do gamma ramps are ignored once I run FSE with the latest beta....I've tried all kinds of options and no dice whatsoever.

Easy to reproduce with this attachment (http://forum.doom9.org/showpost.php?p=1600195&postcount=15430) using the old rendering path.....would happily provide logs :o

[Asmodian]

Strange way to ask for future plans. Anyway, Madshi does not (like to) talk about his future plans and he is still active to fix bugs.

Not only fixing bugs! Debanding is a major feature in my opinion.

It seems very odd to ask if madVR is "done" now, read the last 10 pages. Hints of interesting things to come. :)

[madshi]

Concerning fades there's many in this clip (http://www.sendspace.com/file/otfqcw) which are handled fine but the one at 5 seconds has a lot of banding. Is there anything that can be done with this?
Looks more like compression artifacts to me than simple banding problems. Banding are visible steps in a simple gradient. There is no clear gradiant at 5 seconds.

Also does anyone else have issues with playback starting before a display mode change (60 to 72hz for example) is finished? Would this be a madvr or a player issue?
The source device has no way to know how long the display will take to sync to a new display mode.

I see faint blocking on all color patches, distributed across the entire patch.
Might be a bug in the test pattern generator. Dithering cannot be disabled for test patterns, it's forced on. But it shouldn't be blocking.

Thanks for the detailed answer. There's one thing I'm still uncertain concerning the re-rendering and the fade detection: at which point does it actually take place? Does madVR have to re-request frames from the decoder or does this not happen as its own decoder queue is unaffected?
Fade detection is performed by the SSE2 CPU routine which uploads the video frames to the GPU. The way I implemented it, fade detection almost comes for free (in terms of CPU & GPU performance) when your CPU can do SSE2. Rerendering is done when the SSE2 routine finds the 5th frame in a row with lowered/raised brightness across the whole frame. Rerendering only affects the render queue and all queues "below" that in the madVR OSD. It does not affect any queue "above" the render queue in the madVR OSD. So the decoder, upload, deint, IVTC etc queues are all unaffected.

Humm, not sure why but whatever I do gamma ramps are ignored once I run FSE with the latest beta....
Sounds like a driver issue? Does the same issue occur when using the new FSE rendering path?

Has madVR close reaching it peaks? And we will not see any major update for years to come?
Not only fixing bugs! Debanding is a major feature in my opinion.

It seems very odd to ask if madVR is "done" now, read the last 10 pages. Hints of interesting things to come. :)
^ Still many things on my to do list, some small, some big.

[leeperry]

Sounds like a driver issue? Does the same issue occur when using the new FSE rendering path?
Same story with the new rendering path, I guess I could try my luck building a 3DLUT out of my .cal file using this: 3dlut Generator for madVR (http://forum.doom9.org/showthread.php?t=162285)
Applies an ArgyllCMS .cal [..] file to a .3dlut, thus calibrating it for a specific display device
It's too bad ArgyllCMS can't do it on its own, hopefully this'll save my day :o

[ryrynz]

Anyone had exclusive mode just freeze? Not sure if it's related specifically to my system or not.
Audio continues to play, If I change to windowed mode in continues to play fine.. then I can enter back into exclusive and everything is normal.
I did see briefly some red text on the top left likely commenting on a direct3d error, might be a tough issue to track down.

[luke823]

Hi all,
If you're interested to see a new media player that supports madvr internally, please take a look at Media Browser Theater:

http://forum.doom9.org/showthread.php?t=169768

[sebdelsol]

Maybe we should think of an alternative solution for this? E.g. you turning the rendering queue off, so that only the first frame in the queue is getting re-rendered all the time? Or I could check how often you call "OsdRedrawFrame()" myself automatically and disable the rendering queue if I notice that you're calling it a lot. Or something like that...

Turning off the rendering queue would work with me. I guess I would need to be sure that I turn it on again just before playing.


I'll think of something for (hopefully) the next official release. Stay tuned...

I've tested with a rendering queue set to 1 frame. As you said, the gpu load is fine even with a lot of OsdRedrawFrame() calls.

But this solution may be problematic for seeking, since the graph seems to block the renderer after IMediaSeeking::SetPositions().
During a seek IOsdRenderCallback::RenderOsd() is not called for a lot of frames even when I keep calling OsdRedrawFrame(). It could last for several seconds depending on where you seek.

Thanks again for the new debanding feature, it works great with me:D

[Ver Greeneyes]

Might be a bug in the test pattern generator. Dithering cannot be disabled for test patterns, it's forced on. But it shouldn't be blocking.
Running the TPG in fullscreen mode during calibration or profiling, on particularly dark patches I see random clumps of pixels with a slight greenish hue that change roughly every half a second - not single pixel noise of a neutral colour that changes rapidly as I would expect. Is this working as intended? What it looks like is that it generates patches at a specific resolution, then upscales them to my screen resolution, instead of generating them at the native resolution in the first place. But I don't know if that's true.

[leeperry]

Same story with the new rendering path, I guess I could try my luck building a 3DLUT out of my .cal file using this: 3dlut Generator for madVR (http://forum.doom9.org/showthread.php?t=162285)
Oh well, scratch that, Graeme Gill tells me that this app would appear to promise more than it can actually deliver and that I might as well forget about it.

IIRC AMD GPU drivers have always been hard to deal with when it comes to CLUT's in D3D games, I presume that you didn't only test this feature on nvidia & Intel? I woulda really liked to get BT1886 in mVR too :o

Now that I remember, this app might save the day: Monitor Calibration Wizard (http://www.hex2bit.com/products/product_mcw.asp#description)
provides a persistent profile option that enforces your profile to prevent other programs from changing the color profile Windows uses.


PS: to those who care, Argyll 1.62 is bound to be released and will include "a slight change that may improve the dispcal black level"...all in good time :cool:

[dansrfe]

I've observed sharp drops in the render queue with artifact removal at default settings which results in dropped frames every ~5 seconds. This tends to happen only in high motion sequences like action/dance sequences.

Windows 7 x64, GTX 670, LAV, MPC-HC nightly, latest madVR deband build.

[huhn]

i got a crash and i can't send the bug report just got this:
http://abload.de/img/bugreportbugdysj2.png

the problem was the old mpc hc version so no big deal. these old version are still needed because newer version can't play ps2 lpcm audio. is the bug report tool part of mpc hc or madvr. so i just tried to use an old version that simply isn't supported anymore or was broken?

[Asmodian]

I've observed sharp drops in the render queue with artifact removal at default settings which results in dropped frames every ~5 seconds. This tends to happen only in high motion sequences like action/dance sequences.

Windows 7 x64, GTX 670, LAV, MPC-HC nightly, latest madVR deband build.

Known issue, it is a bug in the interaction of the fade detection for debanding and smooth motion. Turning off either will solve it (set both debanding options to the same setting to turn off fade detection).

[secvensor]

Similar the project is frozen.

[dansrfe]

Known issue, it is a bug in the interaction of the fade detection for debanding and smooth motion. Turning off either will solve it (set both debanding options to the same setting to turn off fade detection).

Yep, setting both to low solved it.

[Niyawa]

madshi, I have a question from a dev friend for you:

"Hi, "fastSubtitles" is not listed in the commented list of available settings in mvrInterfaces in the latest available version. Do you plan on keeping this setting at that specified name?"

Also a question of my own... the option "use a separate device for presentation (Vista and newer)", does it haves any downsides? Or maybe just something that I should keep in mind? I've tested it enabled with a variety of PCs and it always halved the rendering time, not to mention it made smooth motion more stable too.

[vivan]

Also a question of my own... the option "use a separate device for presentation (Vista and newer)", does it haves any downsides? Or maybe just something that I should keep in mind? I've tested it enabled with a variety of PCs and it always halved the rendering time, not to mention it made smooth motion more stable too.On systems with Optimus it was leading to freeze after 30-40 seconds of playback if you were using nVidia GPU for rendering.

UPD: tested right now, seems that this is issue is now gone :)

[turbojet]

Use separate device for presentation is a must for me with nvidia gts250 and 9500GT, without it there's a lot of dropped frames. However an i3m/HD3000 drops a lot of frames with it enabled and fine disabled.

I'm having an issue with 30fps@60hz and madvr. In display changer there's 1680x1050p60, 1680x1050p72, 1680x1050p75 that were setup with cru lcd - automatic standard. The latter 2 work correctly but anytime a 29.97 video is played it always tries to change to 60hz even if it's already at 60hz and enables smoothmotion (it shouldn't) but when a 59.94 fps video is played it won't try to change to 60hz (if already at 60hz) and disables smoothmotion. Any ideas on fixing it or is this a bug?

[Mangix]

I'm having an issue with 30fps@60hz and madvr. In display changer there's 1680x1050p60, 1680x1050p72, 1680x1050p75 that were setup with cru lcd - automatic standard. The latter 2 work correctly but anytime a 29.97 video is played it always tries to change to 60hz even if it's already at 60hz and enables smoothmotion (it shouldn't) but when a 59.94 fps video is played it won't try to change to 60hz (if already at 60hz) and disables smoothmotion. Any ideas on fixing it or is this a bug?

It's a Windows 7+ bug. Windows lies to madVR about the refresh rate. Nothing can really be done about it. I also use a 1680x1050 monitor but have the default at 75Hz since mouse movements are smoother and as a result I don't notice it.

[Niyawa]

I see, thanks you all for the input. I'd still appreciate if anyone else could tell me their experiences with the option, I'm limited by my own hardware after all.

Also on an unrelated note, any of you guys heard of an issue with madVR where video only appear 5 seconds after even though audio has already started in playback?

[QBhd]

I also use the seperate device for presentation... Win 7 x64, HD 5770... and IIRC, I had bad drops without it... haven't checked in a very long time if I still need it.

QB

[turbojet]

Interesting Mangix but I haven't had the problem with 60hz until now but did have an issue with 75hz that seems to work now. The problem with 60hz was forced film mode, changing back to auto detect fixed it.

The i3m/HD3000 no longer drops a lot of frames with separate device presentation. I remember reading somewhere (probably this thread) that it reduces the chance of frame drops with a little increase in gpu load or something along those lines.

Niyawa, I've experienced the audio playing with no video for at least a few seconds randomly, lately. May be latest deband build or forcing film mode. Sometimes the video never shows and potplayer isn't functional. Closing the player and reopening fixes it.

[Vyral]

I see, thanks you all for the input. I'd still appreciate if anyone else could tell me their experiences with the option, I'm limited by my own hardware after all.


I also use the option "use a separate device for presentation (Vista and newer)" because it always halved the rendering time and produce less dropped frames.

[THX-UltraII]

I know that I will go off-topic a little bit with this but I do also know that the knowledge here is far beyond videocard forums. I am running a 4K display device with a Club3D HD7950 card. I configured my ATI control panel to output 3840x2160 (4K)@23Hz. madVR upscales my 2K content to 4K with the JINC3+AR algorithm. This does an outstanding job! This upscaling is the best there is and better then Sony's Reality Creation or Oppo's upscaling tech. The problem however is that I get 'faults' in the content from time to time. Sometimes it is during scene changes or sometimes during scene panning. It is pretty hard to describe the actual problem but think about a cable that is loose. The picture just 'distorts' for some seconds. You see 'bright green/blue distortion lines'. The problem goes away when outputting 1080p from the card. The problem is also not madVR related because it is also there when using EVR. So there is something wrong but I have no clue what. Is there someone who can help me on my way?

[druneau]

I know that I will go off-topic a little bit with this but I do also know that the knowledge here is far beyond videocard forums. I am running a 4K display device with a Club3D HD7950 card. I configured my ATI control panel to output 3840x2160 (4K)@23Hz. madVR upscales my 2K content to 4K with the JINC3+AR algorithm. This does an outstanding job! This upscaling is the best there is and better then Sony's Reality Creation or Oppo's upscaling tech. The problem however is that I get 'faults' in the content from time to time. Sometimes it is during scene changes or sometimes during scene panning. It is pretty hard to describe the actual problem but think about a cable that is loose. The picture just 'distorts' for some seconds. You see 'bright green/blue distortion lines'. The problem goes away when outputting 1080p from the card. The problem is also not madVR related because it is also there when using EVR. So there is something wrong but I have no clue what. Is there someone who can help me on my way?

I've seen/heard of low "idle" memory clocks causing screen artifacts. On my displays (1080p 144hz and 1440p 120hz) I've had to raise idle memory clocks a few times to avoid glitches while on the desktop.

Now, while playing video with madvr I would expect the card to be working somewhat hard.. so I would think it stays in 3d clock mode. You could monitor your memory clocks using something like hwinfo64 or gpu-z while playing a video and see if clock speeds change near artifacts occuring?

[THX-UltraII]

I've seen/heard of low "idle" memory clocks causing screen artifacts. On my displays (1080p 144hz and 1440p 120hz) I've had to raise idle memory clocks a few times to avoid glitches while on the desktop.

Now, while playing video with madvr I would expect the card to be working somewhat hard.. so I would think it stays in 3d clock mode. You could monitor your memory clocks using something like hwinfo64 or gpu-z while playing a video and see if clock speeds change near artifacts occuring?
Ok. I will try this. Could you also tell me how to overclock my card a little bit to see if this helps?