madVR - high quality video renderer (GPU assisted)

[madshi]

madVR v0.86.3 released

http://madshi.net/madVR.zip

* disabled resolution based BT.2020 auto-detection (for now)
* fixed: ZoomPlayer: cosmetical issue when pausing in FSE mode
* fixed: #26: seeking/pausing in FSE with FRC on freezes video
* fixed: #72: display mode restauration didn't work correctly in win8
* fixed: #73: display mode was not restored when playback was stopped in MC18
* fixed: #74: fullscreen <-> windowed can be slow with large CPU queue
* fixed: #79: XySubFilter: non-color-corrected subtitles had wrong levels

[ryrynz]

Originally Posted by madshi

From what I remember, something like this had been reported months ago and I had fixed it, and it was reported to be actually fixed. Not sure if what you're experiencing is a new problem, or if the fix doesn't work for you, or if the fix and unfixed itself at some point. Right now I'm not really feeling like looking into this, though.

It's always occurred for me and still happens with 0.86.3.
Play a file, have 'After Playback' 'Play next in folder' active and you'll see the a new window flash up before it plays the next file.
Nice to see you back BTW, haven't had a black screen flash yet.

[madshi]

Originally Posted by ryrynz

It's always occurred for me and still happens with 0.86.3.
Play a file, have 'After Playback' 'Play next in folder' active and you'll see the a new window flash up before it plays the next file.
Nice to see you back BTW, haven't had a black screen flash yet.

Well, feel free to create a bug entry for this in the madVR bug tracker. I can't promise to work on that soon, but at least it'll be on record then.

[ryrynz]

Will do, was almost finished doing it when I encountered an issue.

MPC allows you to select D3D Fullscreen for VMR when MadVR is selected as the renderer, shouldn't it be ignored when MadVR is selected?

Things don't work right if it's ticked, I have to use Task Manager to exit MPC as it plays fullscreen and the keyboard doesn't work within the player properly, also the seekbar sometimes won't display.
Not that I use VMR these days but I happened to have this option ticked.

[madshi]

I had that option removed at some point in the past, but then some users complained who seemed to need it for some reason, so the option was put back into MPC.

[ryrynz]

Yeah I remember now, how does it even work for people when it's so broken for me? Is it just the Intel graphics driver?

[cyberbeing]

Originally Posted by madshi

Hmmmm... It was faster with v0.86.2, but only because madVR didn't apply subtitles in the correct PC/TV levels, when XySubFilter did the color correction. Now that I've added the fix for the incorrect levels, doing color correction inside of madVR does not cost any extra performance compared to when not doing it. Basically subtitle color correction in madVR comes for "free". Or more correctly: It doesn't come for free, but the cost is hidden because I have to do extra processing to apply the subtitles in the correct levels, anyway, and doing color correction in addition to doing levels adjustments simply doesn't cost any extra performance...

It was faster with test builds prior to that bug as well, at least with my NVIDIA GT440 DDR5.

I just reconfirmed this with 0.86.3 as well. The madVR color correction is ~10% slower than our internal correction. On a faster GPU it could be different though.

Originally Posted by madshi

Yes, it could be GetOutputRect, too.

I tracked down the commit which seemed to be causing this, and it was GetOutputRect related as I suspected. This also seems to have been the cause that massive performance regression on certain heavy scripts we were tracking as well. Hacked together a build without this change and performance increased nearly ten fold on one of the worst samples.

[madshi]

Originally Posted by cyberbeing

I just reconfirmed this with 0.86.3 as well. The madVR color correction is ~10% slower than our internal correction. On a faster GPU it could be different though.

Are you totally sure? As far as I can see in my source code, the only difference for madVR is that it fills a multiplication matrix with different values, depending on whether color correction is enabled or not.

Originally Posted by cyberbeing

I tracked down the commit which seemed to be causing this, and it was GetOutputRect related as I suspected. This also seems to have been the cause that massive performance regression on certain heavy scripts we were tracking as well. Hacked together a build without this change and performance increased nearly ten fold on one of the worst samples.

That's good to hear. Are there still performance issues left in XySubFilter? Or did the change you made already clear up all known problems?

And madVR specific: With this XySubFilter change, are there any performance problems left, when using a 128 frame CPU + subtitle queue?

[cyberbeing]

Originally Posted by madshi

Are you totally sure? As far as I can see in my source code, the only difference for madVR is that it fills a multiplication matrix with different values, depending on whether color correction is enabled or not.

Yes I'm totally sure. GPU load + rendering times are slightly higher, and benchmark FPS are slightly lower when using madVR's GPU based color correction on my slowish GT440 DDR5 OC. It's there, but overall its not that significant unless someone was already pushing their GPU to the maximum limits. I'm sure I told you something similar during our roundtable email discussions back in April when we added this feature.

Originally Posted by madshi

That's good to hear. Are there still performance issues left in XySubFilter? Or did the change you made already clear up all known problems?

And madVR specific: With this XySubFilter change, are there any performance problems left, when using a 128 frame CPU + subtitle queue?

I didn't actually fix anything, I just reverted a change and hacked it back semi up-to-date through ~50 conflicts for some quick testing, likely breaking a few minor things in the process. This is more of just a preliminary identification of a problem area at this point. I've yet to get feedback from the xy-VSFilter developer, and overall this is something which really needs to be fixed by him considering how much this code was integral to later commits. I'd rather not make final judgement on performance problems until I'm sure I have a fully functional build.

[huhn]

is it possible that madvr got problems with 144 hz mode and can't calculate the repeat/drop rate?

if this is not know i'll make a bug report with log right away.

here a screen: http://s3.imgimg.de/uploads/osd75bad2dcpng.png

[madshi]

Originally Posted by cyberbeing

Yes I'm totally sure. GPU load + rendering times are slightly higher, and benchmark FPS are slightly lower when using madVR's GPU based color correction on my slowish GT440 DDR5 OC. It's there, but overall its not that significant unless someone was already pushing their GPU to the maximum limits. I'm sure I told you something similar during our roundtable email discussions back in April when we added this feature.

Yes, but in April you tested v0.86.1. In both v0.86.1 and v0.86.2, madVR definitely had a lower GPU load when XySubFilter did the color correction internally, because madVR simply did less work in that case. In v0.86.3 this should have changed. Looking at my code, with v0.86.3, whether madVR does subtitle color correction or not should not matter for performance.

[madshi]

Originally Posted by huhn

is it possible that madvr got problems with 144 hz mode and can't calculate the repeat/drop rate?

Repeat/drop rates are only shown if refresh rate and movie framerate roughly match.

[huhn]

i'm talking about a normal 24000/1001 video on an 144 hz panel

in 120 hz it is shown every ~52 sec
in 144 hz it is not

[cyberbeing]

Originally Posted by madshi

Yes, but in April you tested v0.86.1. In both v0.86.1 and v0.86.2, madVR definitely had a lower GPU load when XySubFilter did the color correction internally, because madVR simply did less work in that case. In v0.86.3 this should have changed. Looking at my code, with v0.86.3, whether madVR does subtitle color correction or not should not matter for performance.

Oops... I downloaded 0.86.3 but forgot to install it.

And you you are correct, you made XySubFilter's internal color correction slower, with no improvement to speed for madVR's color correction.
Why did you do that? I have a weak GPU, I want less load not more.

What made yuvMatrix=None subtitles so much slower in this build, when they seemed to be handled just fine the April build? Logically, not doing something should be faster than doing it. What is the purpose of this extra workload in 0.86.3 ?

NVIDIA GT440 1GB DDR5
1280x720 -> 1920x1080
8bit 3DLUT
Luma: Spline36 AR
Chroma: Catmull Rom
TV.601 script on TV.709 video

madVR 0.86.2 (April 3rd Test Build)
madVR color correction
GPU Load: 43%
Render Times: 17.3ms avg | 20.0ms max

XySubFilter color correction
GPU Load: 34%
Render Times: 13.0ms avg | 15.0ms max


madVR 0.86.2 (Final Build)
madVR color correction
GPU Load: 43%
Render Times: 17.3ms avg | 20.0ms max

XySubFilter color correction
GPU Load: 34%
Render Times: 13.3ms avg | 16.0ms max


madVR 0.86.3
madVR color correction
GPU Load: 43%
Render Times: 17.3ms avg | 20.0ms max

XySubFilter color correction
GPU Load: 43%
Render Times: 17.3ms avg | 20.0ms max

[Danat]

I'd like to hear your thoughts on this madshi:
When using 128 CPU queue, and getting near the heavy part of the video (decoder starts processing the tough part), sometimes everything goes smooth, sometimes I got a lot of frame drops. Whats disappointing is that the decoder queue is at lowest around 100 during this, but because it tries so hard to get full, it bottlenecks CPU sometimes, making troubles for the renderer. If I force LAV decoder to use 1 thread - it fills the CPU queue slower, using significantly less CPU, resulting in absolutely no frame drops on tough parts at least until the decoder queue becomes empty (which of course happens faster now since CPU usage now is 75% max). As I understand it, ideally the buffering should always have less CPU priority than the actual rendering, so that decoder never takes away CPU resources from the renderer when it just wants to fill some 100-th frame in the buffer. I've already managed to reduce the CPU usage by not using ReClock (found out it's using 20% CPU), so it is annoying to watch a single peak in decoder CPU usage (5 seconds long) spoiling rendering process while having everything buffered .

Now I was wondering - do you have any control over these things in your code ? Is it possible to give the decoder all the CPU it needs but when there is not enough CPU resources left for the renderer, decoder will rest a bit ? The idea is to keep the 100% CPU usage but making decoder suffer instead of the renderer.

[madshi]

Originally Posted by huhn

in 120 hz it is shown every ~52 sec
in 144 hz it is not

Ooops, you're right. The drop/repeat OSD information is more clever than I thought. It works up to 120Hz, but not higher. I've fixed this in my sources now. In the next build the OSD info will work up to 240Hz.

Originally Posted by cyberbeing

Why did you do that? I have a weak GPU, I want less load not more.

What made yuvMatrix=None subtitles so much slower in this build, when they seemed to be handled just fine the April build?

That's a long story. I suppose you want to hear it, so here we go:

madVR rendering consists of several rendering steps / shader passes. The April build had a bug which resulted in subtitles being blended onto the video frame after a more or less "random" shader pass, if (and only if) XySubFilter did the subtitle color correction internally. This "random" step depended on the circumstances. If no scaling was being done, and smooth motion FRC was turned off, subtitles were blended onto the final image after dithering, 3dlut applying etc. If your display needs PC levels, all of this mess resulted in the happy accident that subtitles were actually rendered with the correct levels, without madVR having to do any extra work. Hence the good performance numbers, with correct output. But it was really an accident, nothing less.

So you may wonder: Why don't I make use of this happy accident to save performance? Well, there are a big number of reasons: The subtitle rendering was really done at a bad point in time. You do want the 3dlut do be applied to the subtitles, too, don't you? And you want subtitles to work for smooth motion FRC, too, right? And you want all those positioning bugs gone that the April build still had, right? Please do the following test with the April build: Run the ASS color test sample with XySubFilter internal color correction. Then switch madVR to TV levels output. Oooops, suddenly everything is screwed up!

One part of fixing all the known subtitle issues of the April build was to move the subtitle rendering to the correct shader pass. However, doing so resulted in levels being always (but at least reliably) wrong, when using XySubFilter internal color correction. Why is that? Because subtitles produced by XySubFilter always come in PC levels, while madVR's internal rendering pipeline works in TV levels. The only proper way to fix this is to temporarily switch the madVR internal rendering pipeline to PC levels, then render the subtitles, then convert back to TV levels. In order to not lose BTB/WTW, for the TV -> PC conversion shader pass I need to use floating point textures, because integer textures would lose BTB/WTW (integer textures can't store negative numbers in Direct3D). Now floating point textures can be expensive, especially on older generation GPUs. The color correction itself is almost free. What costs all the performance is the conversion of the madVR rendering pipeline from TV levels to PC levels then back to TV levels. That's 2 extra shader passes and one of those involves floating point textures. This levels conversion was already performed by the April build, if madVR was reponsible for the color correction, but it was not performed by any build until v0.86.3, if the color correction was performed by XySubFilter.

I hope it all makes sense to you now?

To sum up: The subtitle color correction in madVR doesn't cost any extra performance. The necessary conversions to render subtitles at the correct levels (PC) are what is causing the extra GPU power.

Originally Posted by Danat

I'd like to hear your thoughts on this madshi:
When using 128 CPU queue, and getting near the heavy part of the video (decoder starts processing the tough part), sometimes everything goes smooth, sometimes I got a lot of frame drops. Whats disappointing is that the decoder queue is at lowest around 100 during this, but because it tries so hard to get full, it bottlenecks CPU sometimes, making troubles for the renderer. If I force LAV decoder to use 1 thread - it fills the CPU queue slower, using significantly less CPU, resulting in absolutely no frame drops on tough parts at least until the decoder queue becomes empty (which of course happens faster now since CPU usage now is 75% max). As I understand it, ideally the buffering should always have less CPU priority than the actual rendering, so that decoder never takes away CPU resources from the renderer when it just wants to fill some 100-th frame in the buffer. I've already managed to reduce the CPU usage by not using ReClock (found out it's using 20% CPU), so it is annoying to watch a single peak in decoder CPU usage (5 seconds long) spoiling rendering process while having everything buffered .

Now I was wondering - do you have any control over these things in your code ? Is it possible to give the decoder all the CPU it needs but when there is not enough CPU resources left for the renderer, decoder will rest a bit ? The idea is to keep the 100% CPU usage but making decoder suffer instead of the renderer.

The madVR rendering thread is already running at a priority 2 steps higher than normal. That means it should in theory have priority over decoding - if the OS thread scheduler is working correctly. Of course if the decoder thinks it should run at a higher priority, too, this might be a problem. But that's outside of my control.

Which queues exactly get empty when you get the frame drops? Does the same problem also happen in fullscreen exclusive mode?

[ThurstonX]

Originally Posted by ryrynz

Yeah I remember now, how does it even work for people when it's so broken for me? Is it just the Intel graphics driver?

Nah, it happened to me with AMD. Not sure how the box got ticked, but it was driving me nuts.

[Danat]

Originally Posted by madshi

Which queues exactly get empty when you get the frame drops? Does the same problem also happen in fullscreen exclusive mode?

It's more stable in exclusive mode (about 5 frame drops comparing to sometimes 20 or more in windowed) but it still happens.

windowed mode:
framedrops at backbuffer queue 3/3 -> 0/3, then render queue too goes 15/15 -> 0/15. Most of the time it happens almost simultaneously but after testing this over and over I think backbuffer queue gets emtpy first.

exclusive mode:
same as with windowed, framedrops at present queue 3 -> 0. I'm not sure render queue gets empty here but after some stalling in OSD updates (CPU bottleneck) I see present queue: 0/3, render queue: 6/15.

Btw I'm using MPC-HC "Video Frame" -> "Normal size" option to make things easier for madVR rendering process.

[Buckster]

what would be a preferable upgrade from my 5670 for MadVR please ?

a 7770 or a 650Ti - the latter being quite a bit more expensive ?

I was thinking may a 7750 at much lower power - but maybe more borderline performance wise?

my 5670 does ok most content, but for some it really struggles - no idea whats different in those videos - but even with Chroma dropped to Bicubic it struggles, the 5670 is clocked to 900mhz too. Its always the Render queue that has issues

[6233638]

Originally Posted by madshi

madVR v0.86.3 released

Thanks for the quick fixes of #72-74. Now I can leave madVR to handle all display mode switching again.

Originally Posted by madshi

Can those guys who were seeing ghosting problems with madVR's FRC please recheck with v0.86.2? Maybe they're gone now, too?

Well I was going to report that it seemed to have been eliminated, but now that you have fixed 24/60Hz output on Windows 8, it turns out that my refresh rates are close enough that madVR doesn't activate Smooth Motion any more.

I do still see ghosting when it's active.



Something which seemed to have been fixed in previous builds - or at least I had not noticed it, is that pausing the video increases the repeated frame count by 1-2 every second.

It's not a problem, I just don't know if it should be doing that or not. Bug #0000081