madVR - high quality video renderer (GPU assisted)

[pankov]

Originally Posted by madshi

With which renderer did you test LAV CUVID? madVR generally does consume more GPU than EVR, because madVR does many things via pixel shaders, which is more "expensive" than using hard wired video processing circuits. Interesting would be:

(1) "LAV CUVID+EVR" vs. "DXVADecoder+EVR"
(2) "LAV CUVID+madVR" vs. "SoftwareDecoder+madVR"

I would expect you to get somewhat similar GPU numbers for "LAV CUVID+EVR" and "DXVADecoder+EVR". Not sure about (2). Depends on whether video decoding is counted as GPU usage. If it's not, I would expect you to get somewhat similar GPU numbers for "LAV CUVID+madVR" and "SoftwareDecoder+madVR", too. But of course the GPU numbers should be higher for (2) than for (1).

For my previous tests of LAV CUVID (LAV Video in CUVID mode to be precise) I used madVR but now I used both EVR and madVR.

Here are the results of all the combinations I could think of
http://imageshack.us/g/31/lavvideocuvidadaptivehq.png/
or you can download all of them as one archive directly from here
http://www.mediafire.com/?au9ouh2w8b65z7x

From what I saw I still think that madVR's Deinterlacing is too GPU intensive - a jump from from 24% to 79% GPU Load seams a lot.
At the same time playing a progressive 1080p video (not the same one though) with LAV Video (Soft mode) and EVR takes up 28% while the interlaced video + EVR was taking 45% which is only 17% above the progressive one ... and it's far from madVR's increase of 55%. I do understand that some of the difference could be from the different video files but sadly I don't have (don't know how to do it) the same video both interlaced and progressive.

One more thing I noticed is that LAV Video (CUVID - Adaptive + HQ Proc) + madVR (Deint=OFF) uses 4-5% less GPU than LAV Video (Soft) + madVR (Deint=ON).
Does this mean that there is some room for improvement?

I hope I didn't bore you with my tests and you'll be able to improve madVR even more
for your great work

[jmonier]

Originally Posted by madshi

"the same thing/problem" is rather relative. It could mean something totally different to you than it might mean to me. Could you please describe exactly which problem you have? Having smooth playback in exclusive mode while you have problems in windowed mode is not usual in itself. There's a reason why I implemented exclusive mode, after all. The key question for me is: Did things get noticeable worse for you with v0.78? Because that's what cremor is reporting.

Sorry I wasn't clearer, but what I was trying to say was that I'm seeing essentially the same problem under essentially the same conditions that cremor was reporting. That is, if I wrote a description of my problem, I would be writing something very similar to what cremor wrote.

For me, windowed mode was fine (no dropped frames) prior to 0.78 with one exception: If I use LAV CUVID (either stand-alone or combined), I get the same thing with older madVR versions. So the key point seems to be that if hardware de-interlace is used either via CUVID or DXVA 2 on either AMD or NVidia I get lots of dropped frames in windowed mode only. This leads me to believe that madVR is affected somehow by the hardware de-interlace.

I have no problem with using full-screen exclusive if the hardware or driver imposes some limitation that requires it, but I thought you'd like to know about the problem in any case.

[mr.duck]

Originally Posted by madshi

That's really bad. Can I have a log, please? Also, can you step through the video frame by frame with both EVR and madVR? Maybe when looking through both frame by frame you can see why it's smooth with EVR and not smooth with madVR? Maybe madVR repeats each frame twice to achieve double rate, while EVR really produces fluid unique frames?

It might be worth trying drivers 10.11. But I'd really be interested to hear your results when doing frame-by-frame stepping with your current drivers.

http://www.mediafire.com/?dgd5p0mt185rh59

I checked each frame. EVR looks like it's 50p and madVR looks like it's 25p x2. Each frame happens twice with madVR. EVR really does produce fluid unique frames!

Something to do with the source filter reporting 25fps? (I've switched from LAV splitter to built in MPC splitter now, and all is exactly the same).

Source material is UK digital TV in case you were wondering. MPEG2 50i.

[RBG]

Originally Posted by madshi

Does it only occur with Haali but not with LAV Splitter? Does it only occur with LAV Video Decoder but not with other decoders? Does it only occur with madVR v0.78 but not with older versions? Does it only occur with PotPlayer 1.5.29996 but not with other versions?

This error occurs with every filter/player combination I have, including Haali, AVs, LAV as a splitter and LAV video, Potdecoder, FFdshow as a video decoder, madVR 0.77, madVR 078, LAV audio, FFdshow audio, Podecoder audio and last three stable releases of potplayer(29996, 29917, 29795)

Originally Posted by madshi

I'm asking because you're asking a lot here. Finding, downloading, installing and testing these exact versions of all the various filters/player would take me quite some time, and I don't really want to mess up my own filter configuration.

I know, but I am not the only one who gets this annoying bug, though since you're testing madVR in XP, then I guess, there is no reason to reproduce the same filter set, because I am using Window 7 x64.

Originally Posted by madshi

What happens if you use DX9 instead of DX11 in the madVR settings? Does that change anything? The DX11 path is known to be not as stable (yet) as the DX9 path.

I have already tried DX9, but the result is same.

[Hypernova]

Originally Posted by madshi

Ok, tried that, but doesn't happen for me. I can seek and pause, subtitles stay. Using MPC-HC.

Just in case you're still keeping track of this, madshi. I cannot reproduce this anymore. It is true that I randomly have subtitles disappear on pause once in awhile. It's not something I'm bothered by though.

[Skwelcha]

Originally Posted by Hypernova

Just in case you're still keeping track of this, madshi. I cannot reproduce this anymore. It is true that I randomly have subtitles disappear on pause once in awhile. It's not something I'm bothered by though.

Happnes to me sometimes too. but like you said, it's not that much of a bother.

[Mr Alpha]

Originally Posted by nevcairiel

(Unless i missed the news on a new architecture)

Yes, I believe you may have.

[noee]

Re: the upload/render queue problems with Windowed Mode....I've found a couple of interesting things:

1. It doesn't happen on my Llano machine, Windowed and FSE mode are both maxing all queues with deint=ON. That machine is, however, using an older driver version, from July.
2. Even with that driver, my HD6570 playback machine still exhibits the starved upload/render queues in windowed mode. Again, FSE mode, the queues are maxed.
3. On the 6570 machine, if I disable the ESVP option in CCC, madVR shows a Deinterlace Failure in red warning. ESVP seems to matter not on the Llano machine.
4. While testing, I'm using ATI Tray Tools with a profile to keep the card at max clocks.

6570 machine is with CCC11.10 (or any previous). 10.xx series drivers will not support the 6xxx series cards, so testing that is not possible.

So, madshi, fwiw, if you've still got that log I sent you the other day, it shows the starved queues in Windowed mode and then the switch to FSE mode where they max out and all is well.

[nevcairiel]

Originally Posted by Mr Alpha

Yes, I believe you may have.

I'm aware of those, but as i understood, it won't be used for the majority of the HD7000 series, but only for the 79xx high end models.

IMHO, having a architecture disparity in one line is really bad and will confuse alot of people (although its not the first time AMD did it).

[cremor]

Originally Posted by madshi

The only thing that comes to my mind right now is that maybe your GPU is downclocking with v0.78 but not with v0.77? I don't know why it should. But then I don't understand what else could be going on. Your render queue is the problem, so it seems that your GPU isn't rendering fast enough. Which is weird, since your GPU should be plenty fast enough.

GPU is at max clock rate with both versions. Activity is also quite equal according to the CCC, 36% with 0.77 and 38% with 0.78.

Originally Posted by madshi

If you're sure that the GPU clock is ok then please create a short log with v0.77 (no frame drops) and one with v0.78 (frame drops). Maybe 20 seconds of playback each. Thanks.

Hope this helps:
http://www.mediafire.com/?7ek3ubk645kvv4f

edit:
Just managed to play the Devil May Cry clip with full queues in windowed mode with 0.78 a few times. Activity and GPU clocks were exactly the same as previously. But then the problem was back again. So whatever the problem is, it's not always there.

[madshi]

Originally Posted by derp

Ok, here it is.

Argh. MPC-HC shows a little message "Pause" when you pause playback. MPC-HC uses madVR's own OSD functionality for that. However, every time that madVR tries to update the OSD, the subtitles disappear. So the "Pause" message shown by MPC-HC practically removes the subtitles.

So why does it occur only on your PC, but not on anyone else's? I've added extra code to madVR to block the "Pause" OSD message. However, you seem to be using a translated version of MPC-HC. Your MPC-HC shows "Pausa" instead of "Pause". And madVR doesn't block "Pausa". You can fix the problem by translating just the "Pausa" text back to "Pause". I'm not sure where and how to do translations, though. The next madVR build will also block "Pausa". I'm aware that this all isn't really a good solution, but that's all I can do right now.

Originally Posted by pankov

Here are the results of all the combinations I could think of
http://imageshack.us/g/31/lavvideocuvidadaptivehq.png/
or you can download all of them as one archive directly from here
http://www.mediafire.com/?au9ouh2w8b65z7x

Thanks. These are very interesting results - well done! From what I can see:

(1) EVR progressive ~ 15%
(2) madVR progressive ~ 25%
(3) EVR deinterlacing ~ 45%
(4) CUVID deinterlacing + EVR ~ 65%
(5) CUVID deinterlacing + madVR ~ 75%
(6) madVR deinterlacing ~ 80%

If I try to interpret these numbers, I come up with the following estimates:

- EVR progressive double rate ~ 30%
- madVR progressive double rate ~ 50%
- DXVA deinterlacing ~ 25%

The surprising thing here is the low GPU consumption with EVR deinterlacing. My best guess is that EVR saves GPU power by combining all deinterlacing and chroma upsampling and color conversion and scaling into one step. I've looked into what EVR does exactly and it uses basically the same DXVA2 API calls madVR uses, just with 8bit RGB output instead of NV12 output. CUVID and madVR deinterlace first (to NV12). Chroma upsampling, color conversion and scaling are done separately. Unfortunately there's not much we can do about it, unless we want to let DXVA2 do chroma upsampling and color conversion in addition to deinterlacing.

Originally Posted by pankov

From what I saw I still think that madVR's Deinterlacing is too GPU intensive - a jump from from 24% to 79% GPU Load seams a lot.

Deinterlacing produces double rate, so you need to double the progressive 24% to 48% for double rate handling. So DXVA deinterlacing itself "only" consumes about 25-30% GPU.

Originally Posted by pankov

One more thing I noticed is that LAV Video (CUVID - Adaptive + HQ Proc) + madVR (Deint=OFF) uses 4-5% less GPU than LAV Video (Soft) + madVR (Deint=ON).
Does this mean that there is some room for improvement?

Probably not. madVR has to do a couple of funny conversions to make the DXVA2 output compatible to pixel shaders. That's probably the 4-5% difference you're seeing. Well, maybe I could shave off a tiny bit by using CUDA to avoid those funny conversions with NVidia cards, but I'm not sure if that's really worth it.

Originally Posted by jmonier

Sorry I wasn't clearer, but what I was trying to say was that I'm seeing essentially the same problem under essentially the same conditions that cremor was reporting. That is, if I wrote a description of my problem, I would be writing something very similar to what cremor wrote.

For me, windowed mode was fine (no dropped frames) prior to 0.78 with one exception: If I use LAV CUVID (either stand-alone or combined), I get the same thing with older madVR versions. So the key point seems to be that if hardware de-interlace is used either via CUVID or DXVA 2 on either AMD or NVidia I get lots of dropped frames in windowed mode only. This leads me to believe that madVR is affected somehow by the hardware de-interlace.

Your report is *totally* different from cremor's report...

You're reporting that hardware deinterlacing makes problems with windowed mode. That is not at all what cremor has reported. He reported that even *without* deinterlacing v0.78 works noticeably worse than v0.77. So basically he's reporting a new problem in v0.78 which didn't exist in v0.77. While you've reported that all madVR versions have problems in windowed mode when hardware deinterlacing is used (either via madVR or CUVID).

Your GPU is probably not powerful enough to run hardware deinterlacing in windowed mode, together with madVR rendering. I'm not sure if there's anything I can do about it. You probably already tried toggling the "perform deinterlacing in a separate thread" switch on/off?

Originally Posted by mr.duck

http://www.mediafire.com/?dgd5p0mt185rh59

I checked each frame. EVR looks like it's 50p and madVR looks like it's 25p x2. Each frame happens twice with madVR. EVR really does produce fluid unique frames!

Ah, thanks.

I've now hooked into EVR and logged all the DXVA2 deinterlacing calls it makes. And I found a couple of small differences, one of which probably explains the problem you're seeing. Could you please test this special version to check whether it fixes the problem for you?

http://madshi.net/mrduck.rar

Originally Posted by RBG

I know, but I am not the only one who gets this annoying bug, though since you're testing madVR in XP, then I guess, there is no reason to reproduce the same filter set, because I am using Window 7 x64.

Ok, so I'll put on my to do list to test this in win7 x64. Might take a while until I get to that, though.

Originally Posted by noee

Re: the upload/render queue problems with Windowed Mode....I've found a couple of interesting things:

1. It doesn't happen on my Llano machine, Windowed and FSE mode are both maxing all queues with deint=ON. That machine is, however, using an older driver version, from July.
2. Even with that driver, my HD6570 playback machine still exhibits the starved upload/render queues in windowed mode. Again, FSE mode, the queues are maxed.
3. On the 6570 machine, if I disable the ESVP option in CCC, madVR shows a Deinterlace Failure in red warning. ESVP seems to matter not on the Llano machine.

What is "ESVP"?

Did you try toggling the "perform deinterlacing in separate thread" option on/off? Doesn't help? Is your Llano machine's GPU more or less powerful than the 6570? The 6570 is probably not very powerful, so that might explain the problems in windowed mode.

Originally Posted by cremor

Hope this helps:
http://www.mediafire.com/?7ek3ubk645kvv4f

edit:
Just managed to play the Devil May Cry clip with full queues in windowed mode with 0.78 a few times. Activity and GPU clocks were exactly the same as previously. But then the problem was back again. So whatever the problem is, it's not always there.

The log doesn't show much difference, except that somehow the render queue gets empty over time with 0.78, while 0.77 doesn't dip so low. Can't really see what causes the difference.

I've created a couple of special madVR versions for you to try:

http://madshi.net/cremor.rar

Please check if any one of them fixes the issue or not. Thx.

[madshi]

Originally Posted by pankov

From what I saw I still think that madVR's Deinterlacing is too GPU intensive - a jump from from 24% to 79% GPU Load seams a lot.

P.S: Can you please double check whether you get the same results with this test build?

http://madshi.net/mrduck.rar

I don't expect any changes, but who knows. The ATI smoothness fixes might also help NVidia GPU Load. I kinda doubt it, though.

[mr.duck]

Originally Posted by madshi

Ah, thanks.

I've now hooked into EVR and logged all the DXVA2 deinterlacing calls it makes. And I found a couple of small differences, one of which probably explains the problem you're seeing. Could you please test this special version to check whether it fixes the problem for you?

http://madshi.net/mrduck.rar

It appears to be exactly the same


(ESVP = enforce smooth video playback)

[derp]

Originally Posted by madshi

Argh. MPC-HC shows a little message "Pause" when you pause playback. MPC-HC uses madVR's own OSD functionality for that. However, every time that madVR tries to update the OSD, the subtitles disappear. So the "Pause" message shown by MPC-HC practically removes the subtitles.

So why does it occur only on your PC, but not on anyone else's? I've added extra code to madVR to block the "Pause" OSD message. However, you seem to be using a translated version of MPC-HC. Your MPC-HC shows "Pausa" instead of "Pause". And madVR doesn't block "Pausa". You can fix the problem by translating just the "Pausa" text back to "Pause". I'm not sure where and how to do translations, though. The next madVR build will also block "Pausa". I'm aware that this all isn't really a good solution, but that's all I can do right now.

So that's what it was. I simply switched to the english version and now it works perfectly. Thanks.

You know what? You could also block the "pause" translations into the major european languages in order to prevent that this kind of stuff could happen to other people.
You can exclude Italy since "pausa" is in italian and you already said that you'll fix it in the next release.

[cremor]

Originally Posted by madshi

I've created a couple of special madVR versions for you to try:

http://madshi.net/cremor.rar

Please check if any one of them fixes the issue or not. Thx.

The "queues" version seems to fix it! All queues are equal to 0.77 and no dropped or delayed frames.
The other three versions are same as 0.78.

I noticed that this version is back to a decoder queue of 8. Interesting how that can affect the following queues when the decoder queue with 12 was always full too. Or did you change more than just the queue size in that special version?

[Thunderbolt8]

I guess why deinterlacing doenst work that well on my PC is because of that frame rate doubling. I'd say only deinterlacing itself would be ok for my card, but the additional load due to frame rate doubling is too much to handle smoothly.

[noee]

What is "ESVP"?

Did you try toggling the "perform deinterlacing in separate thread" option on/off? Doesn't help? Is your Llano machine's GPU more or less powerful than the 6570? The 6570 is probably not very powerful, so that might explain the problems in windowed mode.

"Ensure Smooth Video Playback" in CCC/Video

Yeah, I tried the thread option, no difference. And the Llano machine I have is a laptop, with a less powerful GPU than the 6570. I think my issue is similar to cremor's, I will try that build.

[madshi]

Originally Posted by mr.duck

It appears to be exactly the same

That's really bad. madVR's DXVA2 calls are now pretty much identical to EVR's. Well, I guess I'll have to install win7 x64 and the latest ATI driver and then hope to be able to reproduce the problem on my own PC.

Originally Posted by cremor

The "queues" version seems to fix it! All queues are equal to 0.77 and no dropped or delayed frames.
The other three versions are same as 0.78.

I noticed that this version is back to a decoder queue of 8. Interesting how that can affect the following queues when the decoder queue with 12 was always full too. Or did you change more than just the queue size in that special version?

I only changed the queue sizes, nothing else. That's really bad that the bigger decoding queue makes problems. Other users reported improvements, so I'm reluctant to change this back. What happens if you slightly dial down the scaling algorithms with v0.78? Does that help, too? My impression from your logs is that the difference between 0.77 and 0.78 on your PC isn't that big. It just adds up over time, so that 0.77 is *just* able to keep up with rendering while 0.78 is only very slightly slower.

Originally Posted by Thunderbolt8

I guess why deinterlacing doenst work that well on my PC is because of that frame rate doubling. I'd say only deinterlacing itself would be ok for my card, but the additional load due to frame rate doubling is too much to handle smoothly.

Yes, that's quite possible. Though, the 4770 should be pretty powerful. I'm surprised it has problems with deinterlacing when using madVR. You're sure you've disabled anti-aliasing, anisotropic filtering etc? Does your GPU run near 100% GPU usage?

Originally Posted by noee

"Ensure Smooth Video Playback" in CCC/Video

Yeah, I tried the thread option, no difference. And the Llano machine I have is a laptop, with a less powerful GPU than the 6570. I think my issue is similar to cremor's, I will try that build.

I really wonder why so many people think their issue is similar to cremor's. You're at least the 3rd person to say so, and until now nobody really shared cremor's problems. Your issue is with deinterlacing activate. cremor's issue is with progressive sources (deinterlacing off).

That said, it wouldn't hurt to try those test versions.

[cyberbeing]

cremor, have you tried playing with the Windowed Mode Tweaks?

If you haven't tried setting everything to No Flush, that would be the first thing I'd try, then proceed to test each setting by itself one by one if all No Flush didn't help. I'd also try disabling Aero if Windowed Mode Tweaks don't help.

If your ATI 6870 w/ 60fps|1920x1080@120hz is only very slightly slower with 0.78 as madshi expects, little things like above may make a difference.

[cremor]

Originally Posted by madshi

I only changed the queue sizes, nothing else. That's really bad that the bigger decoding queue makes problems. Other users reported improvements, so I'm reluctant to change this back. What happens if you slightly dial down the scaling algorithms with v0.78? Does that help, too? My impression from your logs is that the difference between 0.77 and 0.78 on your PC isn't that big. It just adds up over time, so that 0.77 is *just* able to keep up with rendering while 0.78 is only very slightly slower.

Bilinear seems to work, queues equal to 0.77 then. But as soon as I try something with custom pixel shaders the problem is there again. (All three scaling options changed at the same time.)

If the decoder queue is really the only problem here, how about adding an option to change it (or just registry key/file in madVR folder)?

But I still don't get how the decoder queue can affect anything on the GPU. Isn't this all on CPU and system RAM (with LAV software decoding)?

Originally Posted by cyberbeing

cremor, have you tried playing with the Windowed Mode Tweaks?

If you haven't tried setting everything to No Flush, that would be the first thing I'd try, then proceed to test each setting by itself one by one if all No Flush didn't help. I'd also try disabling Aero if Windowed Mode Tweaks don't help.

If your ATI 6870 w/ 60fps|1920x1080@120hz is only very slightly slower with 0.78 as madshi expects, little things like above may make a difference.

Will try that tomorrow.