madVR - high quality video renderer (GPU assisted)

[madshi]

Should i also create a feature request for rendering subtitles on screenshots taken with madvr or is that part just not done, yet?
The bug tracker is only for bugs, not for feature requests. The screenshot functionality will be improved some time in the future.

[dansrfe]

I haven't come across the repeating frame bug with FRC on since v0.86.2. Also, the previously visible FRC artifacts are gone.Thanks madshi! :)

[madshi]

I haven't come across the repeating frame bug with FRC on since v0.86.2. Also, the previously visible FRC artifacts are gone.Thanks madshi! :)
That's good to hear!

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

[Soukyuu]

Should i also create a feature request for rendering subtitles on screenshots taken with madvr or is that part just not done, yet?Wait... doesn't it do that already? I've been taking screenshots with subs with lav+mpc-hc+madvr all this time o_O

[zero9999]

Hi madshi,
A quick bug report (not due to this new build, as I tested with 0.86.1):
madvr has troubles rendering videos encoded with Cinepak/CVID, the display is all screwed up.
A sample file: here (http://videoff7.free.fr/cvid_sample.avi).
In the exact same graph, replacing madvr by the VMRs or EVR solves the issue.
Unrelatedly, now on to test 0.86.2, thanks for this new build!

Edit: same bug with 0.86.2.

this is not only broken with zoom player (as mentioned on the bug report), but also with mpc-hc using the VCM decoder that comes with windows.
however, LAV video decoder seems to behave correctly, so enabling Cinepak in LAV fixes this.

Wait... doesn't it do that already? I've been taking screenshots with subs with lav+mpc-hc+madvr all this time o_O

not when using the upcoming subtitle interface.
xy-vsfilter renders the subtitles directly on the video before it even gets to madvr, so no further steps are necessary to get the subs to display on screenshots in that case.

[dansrfe]

I spoke too soon about the repeating frame bug. Still happens in the same situation. The easiest way to replicate the issue is by rapidly pressing the right (or left?) arrow.

[cyberbeing]

Hmmmm... This might be a bug in madVR which happens when XySubFilter is doing the color correction. @cyberbeing, this might also explain why the colors are wrong when XySubFilter is doing the color correction internally.

If you think this is a madVR bug that's good news, since we still had no idea how or why madVR 0.86.2 Final was breaking XySubFilter internal color correction when it worked fine in the older 0.86.2pre test builds. When you fix this, please send me a new test build, unless you plan to push out a 0.86.3 bug fix release very soon.

@zero9999

As a workaround, you can force madVR GPU-based subtitle color correction to always be used by setting:
HKEY_CURRENT_USER\Software\Gabest\xy_sub_filter\General\
RGB_CORRECTION = never

Accepted RGB_CORRECTION values are auto , always and never . By default, auto performs internal color correction only with TV.601 (subs) on TV.709 (video) and lets madVR handle other combinations. The advantage of XySubFilter's internal color correction is that its faster, since we can do it prior to bitmap rasterization without any additional GPU overhead in madVR. This is why it was made the default for the most common correction.

[kiccolsd]

Does the same problem occur if you use a different video renderer (e.g. VMR9 or EVR)?

Do you have madVR's smooth motion FRC on or off? (I'm not asking you to turn it on or off, just asking how you have configured it at the moment).

After a quick test the answer is no... with EVR no issue at all. Ill keep trying and report back with more mkvs

Smooth Motion is off.

[madshi]

I spoke too soon about the repeating frame bug. Still happens in the same situation. The easiest way to replicate the issue is by rapidly pressing the right (or left?) arrow.
Please create a bug entry in the madVR bug tracker for this, with a detailed description of how it looks, behaves and how to reproduce it with which madVR settings, which display refresh rate, in which mode (FSE?) etc. Thanks.

P.S: If it only occurs in FSE mode then it might already be fixed in v0.86.3. If it also occurs in other modes then this will probably not be fixed by v0.86.3 as of right now.

After a quick test the answer is no... with EVR no issue at all. Ill keep trying and report back with more mkvs

Smooth Motion is off.
Does the issue occur with all scaling algorithms? Does it occur in all presentation modes (windowed, overlay, fullscreen exclusive)?

If you think this is a madVR bug that's good news, since we still had no idea how or why madVR 0.86.2 Final was breaking XySubFilter internal color correction when it worked fine in the older 0.86.2pre test builds. When you fix this, please send me a new test build, unless you plan to push out a 0.86.3 bug fix release very soon.
I've confirmed that it's a bug in madVR. v0.86.3 will come very soon.

[madshi]

The advantage of XySubFilter's internal color correction is that its faster, since we can do it prior to bitmap rasterization without any additional GPU overhead in madVR. This is why it was made the default for the most common correction.
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...

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

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]

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]

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.



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. :eek:

[madshi]

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.

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. :eek:
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]

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.

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]

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]

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]

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. :mad:

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]

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.

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

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.

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]

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]

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]

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

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 (http://bugs.madshi.net/view.php?id=81)

[madshi]

Great. It's here: http://bugs.madshi.net/view.php?id=78

Bug and samples submitted (http://bugs.madshi.net/view.php?id=79).
It's not a problem, I just don't know if it should be doing that or not. Bug #0000081 (http://bugs.madshi.net/view.php?id=81)
I've posted a bug to the bug tracker. See here (http://madVR.bugs.madshi.net).
Really, guys, it's great that you create bug tracker entries! It really is, it makes my life a lot easier. But you don't really need to announce that here. I do get an automatic email about the tiniest change in the bug tracker... ;)

[Danat]

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.Oh well, according to my observations in AnVir Task Manager tool, LAV decoder threads have Base Priority = 10 ('normal' for 'above normal' processes), so it's probably the task scheduler issue as you said. Guess I'm screwed ;).
Couldnt find any thread that looked like madVR renderer though - the only one CPU-consuming (10%) thread after LAV had Base Priority 11. The only valid enough thread with Base Priority = 12 were rarely active, mostly using ~3% CPU even on tough parts, strangely jumping to 12% sometimes on the most boring parts.

[madshi]

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.
It's possible that the backbuffer queue gets empty first. But if the render queue goes to 0/15 there's no way the backbuffer queue can be anything but empty. If you look at the OSD, every queue depends on the queue "above" it. So the first queue from top to bottom which gets into trouble is the guilty one. In your case it seems to be the render queue for some reason. Not sure why. Are you sure no other application is eating GPU performance in the background?

The only valid enough thread with Base Priority = 12 were rarely active, mostly using ~3% CPU even on tough parts, strangely jumping to 12% sometimes on the most boring parts.
That is probably the render thread. It mostly just waits for the GPU to get done, so it really doesn't consume much CPU.

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
It's hard to give recommendations for this. If you want something that is totally fast enough for everything possible with today's madVR algorithms, you might have to get a 660. And even then, maybe tomorrow (not literally) madVR is getting new algorithms which require even more GPU power. On the other hand, do you really have to use the best madVR algorithms for everything? If you're willing to compromise even a little bit, a slower GPU should do the job just fine.

Generally some people prefer getting a really fast GPU and then they don't upgrade for a long time. Others upgrade more often, but choose cheaper GPUs for that. It's your decision in the end.

Regarding ATI vs. NVidia, this has been discussed in this thread multiple time. Hope a search will lead you there.

[ajp2k11]

If the refresh rate reads 0Hz that means that your GPU driver doesn't inform madVR reliably enough about the VSync scanline position. That is required by madVR to do proper presentation. This is a rare problem, but some people have it. It's mostly a problem on XP, though, so I'm surprised you have this with win8. I'd suggest that you update to the latest drivers, to make sure. You could also try updating your GPU BIOS, maybe that helps...

I discovered today that the files I'm having problems with are the ones with subtitles, the ones without seem to work fine. Any ideas?

[madshi]

Interesting! Which subtitle renderer are you using? VSFilter? xy-vsfilter? MPC-HC internal? MC18 internal? Try switching to xy-vsfilter or the MPC-HC or MC18 internal one. I don't really understand how any of this could influence the refresh rate measurements, though! Oh well, the only renderer for which this could be potentially possible would be the MPC-HC internal subtitle renderer. Are you using that one?

[ajp2k11]

Interesting! Which subtitle renderer are you using? VSFilter? xy-vsfilter? MPC-HC internal? MC18 internal? Try switching to xy-vsfilter or the MPC-HC or MC18 internal one. I don't really understand how any of this could influence the refresh rate measurements, though! Oh well, the only renderer for which this could be potentially possible would be the MPC-HC internal subtitle renderer. Are you using that one?

I was using xy-vsfilter since a while back using just the default settings but I've uninstalled it now and using MPC-HC internal, no change as far as I can see. Don't know what MC18 is? Black screen with audio but no video, at leat not for a minute or so. If I disable subtitles through the xy-vsfilter tray icon when I used that or using the MadVR tray icon the player hangs and audio stops and I have to use task manager to terminate it... weird.

Tried zoom player free and it works if I don't install xy-vsfilter but I guess that's because then it doesn't try and load any subs. Also get lots of presentation glitches with ZP, not sure if it's related.

Maybe it doesn't influence the refresh rate measurements, it't just that it doesn't get as far as that because of this subtitle thing? I mean maybe it hasn't had time to measure refresh rate yet before the problem starts... just a thought.

[madshi]

What happens if you disable subtitles in MPC-HC? Does the problem go away then?

[ajp2k11]

What happens if you disable subtitles in MPC-HC? Does the problem go away then?

Don't think so, although I'm not sure how I completely disable them? Uncheck auto load subtitles?

[Danat]

So the first queue from top to bottom which gets into trouble is the guilty one. In your case it seems to be the render queue for some reason. Not sure why. Are you sure no other application is eating GPU performance in the background?
Hmmmm, now that you've explained it I think I made a mistake. Here is how it goes in windowed mode (I use 14 GPU queue size now):

// the first numbers i see in OSD after a visual frame drop (there is also some OSD update lag because of CPU bottleneck)

// test #1:
upload queue: 8/14
render queue: 7/14
backbuffer queue: 0/3

// test #2:
upload queue: 5/14
render queue: 1/14
backbuffer queue: 0/3

// test #3:
upload queue: 6/14
render queue: 1/14
backbuffer queue: 0/3

// test #4
upload queue: 4/14
render queue: 1/14
backbuffer queue: 0/3

So we should blame upload queue right ? I'm kinda confused since I'd say the first queue that gets empty is backbuffer, just by looking at zeroes :). Though I guess upload queue is CPU related and it would make more sense that it has troubles with decoder.

P.S. I've restarted my PC to make sure nothing hugs GPU. It's usage during one test with GPU-Z in the background is around 15% on the hard part. I've tried to set LAV to use no hardware just in case it does smth to GPU - same result.

[Buckster]

It's possible that the backbuffer queue gets empty first. But if the render queue goes to 0/15 there's no way the backbuffer queue can be anything but empty. If you look at the OSD, every queue depends on the queue "above" it. So the first queue from top to bottom which gets into trouble is the guilty one. In your case it seems to be the render queue for some reason. Not sure why. Are you sure no other application is eating GPU performance in the background?


That is probably the render thread. It mostly just waits for the GPU to get done, so it really doesn't consume much CPU.


It's hard to give recommendations for this. If you want something that is totally fast enough for everything possible with today's madVR algorithms, you might have to get a 660. And even then, maybe tomorrow (not literally) madVR is getting new algorithms which require even more GPU power. On the other hand, do you really have to use the best madVR algorithms for everything? If you're willing to compromise even a little bit, a slower GPU should do the job just fine.

Generally some people prefer getting a really fast GPU and then they don't upgrade for a long time. Others upgrade more often, but choose cheaper GPUs for that. It's your decision in the end.

Regarding ATI vs. NVidia, this has been discussed in this thread multiple time. Hope a search will lead you there.

madshi - thanks very much indeed for taking the time to reply - I think I'll take your advice and go over-specced for some additional future proofness so to speak

thanks

[cyberbeing]

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.

It make sense, but it completely goes against the concept of yuvMatrix=None representing untouched PC-range RGB subtitles which could just be alphablended at minimal cost, and means madVR will never be any sort of reference implementation for how the subtitle interface with color correction should be implemented. If I had disabled the 3DLUT, disabled SmoothMotion, and was using 0-255 output in madVR, and the subtitle matrix matched the video, it would be really nice if you could somehow add an alternative path which skipped unneeded steps and behaved like the April build to save performance.

Otherwise have you considered just moving madVR back to using a PC-range pipeline from the 3DLUT onward? Talking to Graeme Gill, it seemed to suggest this could resolve many of the problems which madVR showing elevated BTB information (instead of clipping it) with a TV-range 16-235 output 3DLUT, as well as the 0-15 & 236-255 range not being optimally corrected. Overall I get the impression that he believes TV-range 3DLUTs are very sub-optimal and undesired when profiling for 0-255 display output. If you switched back to using PC-range 3DLUTs, this could resolve the performance overhead as well as improve 3DLUT quality with the more desired 0-255 final output to a TV/Display.

The other idea would to just modify the interface so the consumer can request TV-range subtitles. This would be nearly-free from XySubFilter's end, since it's yet another thing we could do prior to bitmap rasterization. Yes, the horror of add complexity, but you seem to be changing gears now and telling me PC-range subtitles are useless to madVR and result in this undesired performance overhead. The choices and trade-offs we make.

I'm just ranting here, you can do whatever you want with madVR, but I do believe you are headed in the opposite direction needed if you ever had the goal of lowering madVR's minimum requirements and increasing accessibility. There is already a concern that when we release XySubFilter, a rather large subset of xy-VSFilter's user-base won't have a GPU fast enough to use madVR in its current state of overall performance.

[cyberbeing]

I discovered today that the files I'm having problems with are the ones with subtitles, the ones without seem to work fine. Any ideas?

Try installing and using the components from CCCP codec pack (http://www.cccp-project.net/) and then resetting settings in the CCCP control panel. The xy-VSFilter build they include has a few random bug-fix patches which are not yet included in the official 3.0.0.211 build on GoogleCode since we've been busy working on XySubFilter.

[clsid]

I would indeed be a major waste of resources to do basic color corrections (not 3DLUT) in madVR for subs, certainly since madVR needs to process every single pixel from every sub bitmap during the entire movie, while XySubFilter would only need to adjust the color values found in the defined styles and color tags. Usually just a few values for a whole movie. This should not require much extra complexity imo. Just a simple function to transform a color from script value to desired output value. Then render with corrected values.

[kasper93]

I'm just ranting here, you can do whatever you want with madVR, but I do believe you are headed in the opposite direction needed if you ever had the goal of lowering madVR's minimum requirements and increasing accessibility. There is already a concern that when we release XySubFilter, a rather large subset of xy-VSFilter's user-base won't have a GPU fast enough to use madVR in its current state of overall performance.

I do understand your point of view. But madVR was never intended to be low end renderer for everyone. At least I always thought this way. Quality comes with cost. People will get better hardware eventually. We can't care about everyone, if someone have too weak GPU there are other, faster renderers that he can use. But that's my point of view, you don't need to agree.

[cyberbeing]

I do understand your point of view. But madVR was never intended to be low end renderer for everyone. At least I always thought this way.

Quality comes with cost. People will get better hardware eventually. We can't care about everyone, if someone have too weak GPU there are other, faster renderers that he can use. But that's my point of view, you don't need to agree.

I've always thought this way as well, almost to an extreme, just look though some of my old posts on various forums. I have very little sympathy for people who refuse or claim to be unable to upgrade their crap boxes and complain about performance, but sometimes I have to take a kinder view and look this from the point of view of the current xy-VSFilter user-base, many of who do have these crap boxes which can barely run madVR at this point, if at all. Though recently, as madshi's been moving closer to version 1.0 and possibly a paid version, it seems he's been thinking more and more about making madVR capable of scaling down to be more of a "for everyone" renderer, as one of his side goals.

Fun fact: The sole XySubFilter/xy-VSFilter developer doesn't even have access to a computer capable of running madVR with acceptable performance the majority of the time. It's very likely he added this internal color correction option for his own needs so he could run madVR slightly better on his development boxes. Oh well...

Overall I don't really care, I am personally always happy to upgrade my hardware as needed when madshi finds new and interesting ways to increase quality in madVR. The main issue is what madVR is doing here in 0.86.3 doesn't increase quality, it just hurts performance from unnecessary conversions because of [IMHO bad] design decisions he made around 0.62 which destroy any possibly of streamlining the render chain for subtitle display. What seems negligible here could push someone over the edge, and in the next few years, even mid-range to high-end GPUs would likely suffer from this decision in 0.86.3 once UHD video and beyond becomes available.

This is just me ranting my displeasure at this unexpected development, rather than actually expecting madshi to change anything in madVR at this point. I understand and am accepting of why he did it, I'm just not happy that madVR is currently designed in such a way that makes this necessary. Is it worth the time and effort to do a major refactor of madVR only to reduce the performance overhead of its subtitle consumer implementation? Probably not, but maybe it could be wishful thinking for the future.

[truexfan81]

maybe tomorrow (not literally) madVR is getting new algorithms which require even more GPU power.

madshi can you provide an example of what these "new algorithms" might be?

when you said that it got me curious

[madshi]

Don't think so, although I'm not sure how I completely disable them? Uncheck auto load subtitles?
They should be "disabled enough" if you don't see them.

Hmmmm, now that you've explained it I think I made a mistake. Here is how it goes in windowed mode (I use 14 GPU queue size now)
Interesting. And the decoder queue is always full when this happens?

It make sense, but it completely goes against the concept of yuvMatrix=None representing untouched PC-range RGB subtitles which could just be alphablended at minimal cost, and means madVR will never be any sort of reference implementation for how the subtitle interface with color correction should be implemented.
You know what's funny? If I had implemented XySubFilter subtitle rendering correctly in the first place, there'd never been any complaints about performance. You'd just have taken for granted that the performance is what it is.

If I had disabled the 3DLUT, disabled SmoothMotion, and was using 0-255 output in madVR, and the subtitle matrix matched the video, it would be really nice if you could somehow add an alternative path which skipped unneeded steps and behaved like the April build to save performance.
There are too many "if"s here to make sense to me. You didn't even mention all "if"s that apply. E.g. there's also "if I had scaling disabled" and "if I had custom pixel shaders disabled" and "if there's no special situation with subtitle positioning" etc. If I simply put back in that happy accident, subtitle positioning would be incorrect, due to the other XySubFilter related bug fixes I implemented.

I don't feel like adding a specific subtitle rendering path which only applies under a dozen of special parameters. It would require too many changes and it would open up the door for new weird bugs which only occur under specific circumstances...

Otherwise have you considered just moving madVR back to using a PC-range pipeline from the 3DLUT onward?
What do you mean with "moving back"? As far as I remember, madVR has always used a TV levels rendering pipeline. Going PC levels would mean either losing BTB/WTW, or alternatively I'd have to use floating point textures for all rendering steps, which would make things slower rather than faster. The main reason for using a TV level rendering pipeline is that I don't have to use floating point textures to maintain BTB/WTW, to save performance!!

Talking to Graeme Gill, it seemed to suggest this could resolve many of the problems which madVR showing elevated BTB information (instead of clipping it) with a TV-range 16-235 output 3DLUT, as well as the 0-15 & 236-255 range not being optimally corrected. Overall I get the impression that he believes TV-range 3DLUTs are very sub-optimal and undesired when profiling for 0-255 display output. If you switched back to using PC-range 3DLUTs, this could resolve the performance overhead as well as improve 3DLUT quality with the more desired 0-255 final output to a TV/Display.
Sorry, but I'm pretty sure you misunderstood him completely. AFAIK, the issues he ran into had nothing to do with the 3DLUT being TV range, I believe. Actually he had implemented 3DLUT support for the external eeColor calibration box before he implemented support for madVR, and for the eeColor box he supports both PC and TV range 3DLUTs. And he told me via email that he stores ICC 3dluts in TV levels, anyway.

As to performance, as I said above, going PC range would either mean losing BTB/WTW, or using floating point textures, the latter of which would make things slower instead of faster.

The other idea would to just modify the interface so the consumer can request TV-range subtitles. This would be nearly-free from XySubFilter's end, since it's yet another thing we could do prior to bitmap rasterization. Yes, the horror of add complexity, but you seem to be changing gears now and telling me PC-range subtitles are useless to madVR and result in this undesired performance overhead. The choices and trade-offs we make.
PC-range subtitles are not "useless" to madVR, they just happen to not be in the exact format madVR's internal rendering pipeline uses. From my point of view this is an internal madVR rendering problem and not really a critical issue. Yes, it means losing a little bit of GPU performance, but it's not really a "night and day" difference, is it?

I could live with adding support for TV levels subtitles to the subtitle interface, if performance is so critical to you. I do wonder whether the added complexity is worth the small performance benefit. But I could live with it...

There is already a concern that when we release XySubFilter, a rather large subset of xy-VSFilter's user-base won't have a GPU fast enough to use madVR in its current state of overall performance.
Is there? What kind of GPU does that large subset of the user-base have? With bilinear scaling, most DX9 GPUs should be able to handle madVR ok, as far as I can see. I would think that with even Intel HD3000 already running madVR just fine, most users today should have GPUs that should handle madVR with bilinear filtering just fine?

Fun fact: The sole XySubFilter/xy-VSFilter developer doesn't even have access to a computer capable of running madVR with acceptable performance the majority of the time. It's very likely he added this internal color correction option for his own needs so he could run madVR slightly better on his development boxes. Oh well...
Well, then let's collect some money and send it to him. A budget GPU is so cheap these days.

The main issue is what madVR is doing here in 0.86.3 doesn't increase quality, it just hurts performance from unnecessary conversions because of [IMHO bad] design decisions he made around 0.62
madVR has *always* used a TV levels rendering pipeline. Nothing has changed in 0.62 in that regard. And the main reason for using TV levels is actually faster performance. So you have this pretty much backwards.

The changes in 0.86.2 and 0.86.3 were necessary to fix all the remaining XySubFilter related bugs.

in the next few years, even mid-range to high-end GPUs would likely suffer from this decision in 0.86.3 once UHD video and beyond becomes available.
You're kidding, right? If we're talking about the next few years and even mid-range or high-end GPUs, they have insane performance. I believe you totally under-estimate the power of today's mid-range GPUs. Doing two extra rendering steps which do nothing but convert TV -> PC -> TV is soooo easy for anything mid-range (e.g. 660) today that you probably can't even measure the difference. Of course doing any processing in UHD costs more performance, but again, the simple TV -> PC -> TV conversion is so easy on any modern GPU that I don't expect any performance hit worth mentioning with mid-range or high-end GPUs in the near future, even with UHD.

I'm just not happy that madVR is currently designed in such a way that makes this necessary. Is it worth the time and effort to do a major refactor of madVR only to reduce the performance overhead of its subtitle consumer implementation? Probably not, but maybe it could be wishful thinking for the future.
Well, as I explained above, doing what you suggest would slow madVR down instead of speeding it up. I do know what I'm doing, you know, although you often seem to doubt that... ;)

Hmmm... Just a thought: Try activating the trade quality for performance option "store custom pixel shader results in 16bit buffer instead of 32bit". That way the TV -> PC conversion for subtitle blending will use 16bit floating point textures instead of 32bit. That might help to get some performance back, on the cost of accuracy.

I would indeed be a major waste of resources to do basic color corrections (not 3DLUT) in madVR for subs, certainly since madVR needs to process every single pixel from every sub bitmap during the entire movie, while XySubFilter would only need to adjust the color values found in the defined styles and color tags.
The funny thing is that the madVR subtitle color correction practically comes for free. What costs performance is the conversion of the PC levels subs to TV levels.

madshi can you provide an example of what these "new algorithms" might be?
I don't know, maybe NNEDI3? Maybe sharpening algorithms? Maybe new deinterlacing algorithms? I don't really know right now what the future will bring.

[madshi]

@cyberbeing:

I've just looked through the subtitle interface. As you know, it does already contain a "TV" vs "PC" levels indicator. But currently madVR ignores what XySubFilter sets there, and madVR reports TV vs PC depending on whether the source was detected as fullrange or not. I think we do need to re-think the way we handle levels because currently it's a bit of a mess. I've taken for granted that XySubFilter always renders in PC levels, but looking at the interface, it's not clearly defined that way. Ok, "None" is defined as being fullrange. But anything else is flexible, and I think neither madVR nor XySubFilter handle the flexible part correctly right now. So I think we should restart a discussion on how to handle levels in the best way. I'm not happy with the interface right now in regards to levels because it's not clear enough how either provider or consumer should behave in all situations.

Do you agree that we should re-discuss this? If so, where should we do this discussion?

[Danat]

Interesting. And the decoder queue is always full when this happens?
Not 100% full, but "full enough" I'd say ;). Around 100/128 if I just play the video through a first heavy fragment. Though the 4-th test was made just by seeking into the middle of long heavy fragment, pausing to allow the CPU queue to fill up to 60-80/128, then releasing pause and observe how decoder's attempt to fill CPU queue (it fluctuates around 70-90) makes troubles sometimes for the renderer.

[ajp2k11]

Try installing and using the components from CCCP codec pack (http://www.cccp-project.net/) and then resetting settings in the CCCP control panel. The xy-VSFilter build they include has a few random bug-fix patches which are not yet included in the official 3.0.0.211 build on GoogleCode since we've been busy working on XySubFilter.

Thanks for the suggestion, tried it but same thing.

@Madshi,

I have 'auto-load subtitles' unchecked in MPC-HC when using the internal subtitle rendering but same thing...

EDIT: Remuxed one of the files I'm having problems with, removing the internal subtitle, after that it plays fine...