madVR - high quality video renderer (GPU assisted)

[turbojet]

Originally Posted by Asmodian

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]

Originally Posted by huhn

the screen is showing the problem.

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

[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 using the old rendering path.....would happily provide logs

[Asmodian]

Originally Posted by 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.

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]

Originally Posted by turbojet

Concerning fades there's many in this clip 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.

Originally Posted by turbojet

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.

Originally Posted by dansrfe

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.

Originally Posted by sneaker_ger

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.

Originally Posted by leeperry

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?

Originally Posted by LDD9O

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

Originally Posted by Asmodian

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]

Originally Posted by madshi

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

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

[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]

Originally Posted by madshi

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

[Ver Greeneyes]

Originally Posted by madshi

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]

Originally Posted by 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

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

Now that I remember, this app might save the day: Monitor Calibration Wizard

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

[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]

Originally Posted by 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.

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]

Originally Posted by Asmodian

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.