madVR - high quality video renderer (GPU assisted)

[watchman]

Hello madshi,
i did few tests with new 0.53 version and there seems to be some new problem. With this new version i have really choppy playback and OSD stats are just confirming it - there are tons of presentation glitches. To be totally sure i tried 0.52 and everything was fine and there was no glithes at all and also no dropped frames.

I also created you a log. Hope it helps you figure out what's wrong. http://www.mediafire.com/?hhl3ohyvhnr6nwa

On the other hand, i can play Samsung ocean life demo (1080p 30fps 40mbps) without dropped frames. So performance will be better i think :)

About my config: nV 9600gt (270.51) under vista sp2

[Andy o]

madshi here is the info and the log

TID 4488 madVR.ax+0xb5d0

Just in case, there's another one that uses lower CPU:

TID 3872 madVR.ax+0xb500

File name: madVR - log.zip File size: 1.19 MB (http://www.fileserve.com/file/hZNKDDp)

Don't know if I should have kept the video running longer though? The log was getting very big.

[kasper93]

Please try again with v0.53. Of course if there are no dropped/delayed frames and no presentation glitches then it's not a big problem if the queues are not stable. Anyway, if it bothers you, try fixing the GPU clock to a specific level. Maybe your GPU clocks down and up all the time, resulting in this queue behaviour? Not sure, just guessing...

Thanks for 0.53 :) After 5 minutes test it's look better. Maybe vsync were causing the problem. My GPU clocks are fine, I checked it yesterday. Anyway until it isn't drop frames is not a problem. Thanks:)

The point was that the name of the .ax file that is currently not being used would immediately tell the user whether debug mode is enabled or not.
Your filenames instead tell you which one is which, and only if you know what's going on. If one sees "madVR [Normal].ax", one may think "everything is normal" instead of "the normal one doesn't have the correct filename, therefore the debug build is active".

Maybe you're right ... I have a different view on this matter. But it's not so important ;P

[sneaker_ger]

First, short tests of 0.53:

1080p60 on 9200M GS with bilinear:
perfect

1080p60 on 5850:
perfect (the queues and dropped frames look like burned into the monitor, they fill up and stay filled, not changing at all)

1080p24 on 9200M GS with Soft Bicubic Chroma + Lanczos Luma:
The decoder queue stays at 0, whereas the old path would at least fill up a decoder queue. I didn't expect the decoder queue to stay at zero when the GPU is not powerful enough to render in real time.

XXXXp24 on 9200M GS at 60 Hz display:
No dropped or delayed frames but many glitches. log (https://rapidshare.com/files/457405637/9200M_053.7z)

I experienced two hangs on close on my laptop, but I can't reproduce it nor did I have logging enabled at that time.

[madshi]

Ok I got a log with madVR 0.52. It doesn't appear to be caused by the new Fullscreen render path after-all, in the following log it happened in windowed mode with no resizing.
Ok, here's a test build with more log output:

http://madshi.net/madVRcpu.rar

Not useful for anything other than logging either the hang or the high CPU consumption.

i did few tests with new 0.53 version and there seems to be some new problem. With this new version i have really choppy playback and OSD stats are just confirming it - there are tons of presentation glitches. To be totally sure i tried 0.52 and everything was fine and there was no glithes at all and also no dropped frames.
Interesting. I've had a few flushs in v0.52 which I've removed for v0.53. It seems that the new exclusive mode does need a flush setting after all... :(

My log 61MB unzip
Thanks, will look at that later...

madshi here is the info and the log

TID 4488 madVR.ax+0xb5d0

Just in case, there's another one that uses lower CPU:

TID 3872 madVR.ax+0xb500

File name: madVR - log.zip File size: 1.19 MB (http://www.fileserve.com/file/hZNKDDp)

Don't know if I should have kept the video running longer though? The log was getting very big.
Thanks. It's the rendering thread. Ok, so I've created and uploaded a special log build here:

http://madshi.net/madVRcpu.rar

Can you create another log for me with this build? It may help finding the cause of the problem. Or maybe not. I'm not sure. I don't need Process Explorer TID numbers, anymore. Just the log.

1080p24 on 9200M GS with Soft Bicubic Chroma + Lanczos Luma:
The decoder queue stays at 0, whereas the old path would at least fill up a decoder queue. I didn't expect the decoder queue to stay at zero when the GPU is not powerful enough to render in real time.
Hmmmmm... No idea why the decoder queue doesn't move. It should. Unless your CPU is too slow.

XXXXp24 on 9200M GS at 60 Hz display:
No dropped or delayed frames but many glitches.
Bilinear?

[Andy o]

Thanks madshi here's the new log

File name: madVRcpu - log.zip File size: 1.99 MB (http://www.fileserve.com/file/RU7PPrp)

[madshi]

My log 61MB unzip
I've tried to have a look at your log, but it's a mess really. In the beginning of the log you're switching between windowed and exclusive mode like 10 times or so. I don't even know where to look for the problem exactly in the log. What I can see is that you're using a rather high refresh rate (72Hz) and a rather low number of pre-rendered frames. Try increasing the number of pre-rendered frames to 8. Maybe that helps a little?

[madshi]

Thanks madshi here's the new log

File name: madVRcpu - log.zip File size: 1.99 MB (http://www.fileserve.com/file/RU7PPrp)
Thanks!

Does this build fix the problem?

http://madshi.net/madVRcpu2.rar

If not, please another log with that build... :D

[DigitalLF]

MadShi: small bugreport.

first my screen was using DVI and it got the name u2711 in madvr and today i got a new displayport cable to handle the full resolution on this screen and in madvr i renamed it from u2711 (1) to u2711 at that time i had 2 with same name so i tried to delete the one i wasn't using and madvr crashed....

no hurry about that bug fix it will never happen to me again....

[DigitalLF]

MadShi: oh one other thing.... 0.52 (*) got my computer to freeze up completely today i had to hard reboot it ... do you think if i enable debug and in case that would ever happen again... will the reason be in the log file ?


* and by 0.52 i might mean 0.52 or ati drivers or win7 x64 :D

[sneaker_ger]

Hmmmmm... No idea why the decoder queue doesn't move. It should. Unless your CPU is too slow.

It's not.

Bilinear?

Yes.

[fatboyz]

Yeah, I don't understand that, either. On my secondary monitor similar things happen. It seems that *after* I switch to the correct refresh rate, Windows suddenly reports 60Hz. So madVR says: Ok, then I'll use that. Very weird. Should be solved once I implement the automatic refresh rate changing. Oh well, maybe I should stop being such a perfectionist and implement a crude automatic refresh rate changer soon instead of waiting for the perfect solution (which will take time).


:p



I don't know if you are using ATI drivers, but this is a problem I reported way back.
http://forum.doom9.org/showthread.php?p=1480241#post1480241

I found when I updated my drivers that the full screen exclusive mode meant everything switched to 60hz.

The last working version of ati ccc drivers that didn't switch from 50hz to 60hz in exclusive mode is version 10.10.

Everything after that and exclusive mode switched to 60hz, no matter how many settings in catalyst you tweaked.

[pirlouy]

Just my quick report (only visual, I don't look at stats for now) :
- 0.49: ok
- 0.50 (new path): CPU heavy (dropped frames)
- 0.51: ok
- 0.52: CPU heavy (dropped frames)
- 0.53: ok
- 0.54, tomorrow: CPU heavy. :D

[Andy o]

Thanks!

Does this build fix the problem?

http://madshi.net/madVRcpu2.rar

If not, please another log with that build... :D

It's fixed, thanks a lot madshi!

[Razoola]

everything is ok for me in 053 so far.

[Gleb Egorych]

0.49 has a bit less dropped frames with CoreAVC software mode than 0.51 with default settings. Though these 2 versions drop frames differently. 0.49 drops frames more regularly while 0.51 with 4 pre-rendered frames drops more spiky.
And how does v0.52 behave? (out in a couple of minutes)

With 0.52 no dropped frames but presentation glitches appear while decoder, render, backbuffer queues are stable. I guess you fixed stats. Playback experience is the same as with 0.51 - with 14 or 16 frames pre-render playback is smooth, jerking with lesser number of frames.

0.53 is worse for me, even with 14 and 16 pre-rendered I have some glitches.

[someone`]

I've tried to have a look at your log, but it's a mess really. In the beginning of the log you're switching between windowed and exclusive mode like 10 times or so. I don't even know where to look for the problem exactly in the log.
It because I reopen the file to make it play smoothly , i only reopen 2 times and pause 2-3 times . After the last reopen it works .
What I can see is that you're using a rather high refresh rate (72Hz) and a rather low number of pre-rendered frames. Try increasing the number of pre-rendered frames to 8. Maybe that helps a little?
I tested it before , it makes no different . But when i got smoothly playback , i could increase the number to 16 and it still smoothly .

I try the cpu2 build , it's fixed . But window mode is broken , same behaviour .
Also FSE --> pause --> window mode ---> black screen .
log :
http://www.mediafire.com/download.php?ze4h382n38heula

[Andy o]

someone, which decoder are you using? HAM with MPC-HC or DXVA with potplayer? OR something else?

[someone`]

I use PotPlayer , decoder : HAM and DXVA . HAM is faster than PotPlayer DXVA but it has bug cause artifact .

[Andy o]

I tried potplayer & DXVA with madVR and get horrible stuttering, even worse than MPC-HC with HAM.

[fiver]

Madshi:

I'm the one with the ATI 6850M 120Hz issue.

Same problem in .53, log attached.

Thanks!

[SamuriHL]

MPC-HC with Cyberlink HAM for me works extremely well on both my main HTPC (5870) and my laptop (3450). W7SP1 x64 in both cases.

[nevcairiel]

I tried potplayer & DXVA with madVR and get horrible stuttering, even worse than MPC-HC with HAM.

Well duh, madVR does not work with DXVA, whatever results you get, its really unpredictable - quite surprising that you get any image though. =)

[SamuriHL]

Well duh, madVR does not work with DXVA, whatever results you get, its really unpredictable - quite surprising that you get any image though. =)

PotPlayer's DXVA implementation is more like a decoder. They're copying the frames back into system memory after they're decoded on the GPU. As you're well aware, this could be extremely slow depending on the implementation. But, it's the wave of the future. LOL.

[Andy o]

MPC-HC with Cyberlink HAM for me works extremely well on both my main HTPC (5870) and my laptop (3450). W7SP1 x64 in both cases.

Well what do you know. madshi's "cpu2" debug version above, besides fixing the CPU issues, also fixed this. Only the new exclusive path though. The presentation queue doesn't dip to zero.

In windowed and the old exclusive path though, I still get major frame drops, but that's fine I guess.

So now only waiting for that non-debug version that doesn't create a huge txt file on my desktop!

[Andy o]

PotPlayer's DXVA implementation is more like a decoder. They're copying the frames back into system memory after they're decoded on the GPU. As you're well aware, this could be extremely slow depending on the implementation. But, it's the wave of the future. LOL.

Yeah other people reported it worked (even "someone" above), so why not give it a whirl.

[SamuriHL]

Well what do you know. madshi's "cpu2" debug version above, besides fixing the CPU issues, also fixed this. Only the new exclusive path though. The presentation queue doesn't dip to zero.

In windowed and the old exclusive path though, I still get major frame drops, but that's fine I guess.

So now only waiting for that non-debug version that doesn't create a huge txt file on my desktop!

That's awesome! madshi's been putting out new versions like a banshee so I'm sure you'll see a new version soon. I'm extremely happy with recent developments with LAVF/madVR/MPC-HC. We've come a REALLY long way in a short time. The fact that I can run it on my laptop is amazing!!!

[Qaq]

Does this build fix the problem?
http://madshi.net/madVRcpu2.rar
If not, please another log with that build... :D
I did some tests with 0.53 (results are similar to previous), but they look useless now. I will test your madVRcpu releases tomorrow and report back. Thanks for your work.

[SamuriHL]

Yeah other people reported it worked (even "someone" above), so why not give it a whirl.

I may. I'm not jazzed about using a new player, though. The ffdshow extension that was linked to earlier looks possible, though. I was going to check that out and apply the patch to my local ffdshow repository and build it. Don't know when I'll get to test it but I'm curious to see how it compares to Cyberlink HAM/LAVF CUVID with madVR.

[6233638]

Firstly, thanks for the switch to a green OSD, it's much easier to read now.

I'm getting a large number of presentation glitches in 0.53. I tried increasing the backbuffers to 16, but that only made things worse, almost 500 in a 10 minute video.

http://www.mediafire.com/?725le1n1ai6985p

[madshi]

first my screen was using DVI and it got the name u2711 in madvr and today i got a new displayport cable to handle the full resolution on this screen and in madvr i renamed it from u2711 (1) to u2711 at that time i had 2 with same name so i tried to delete the one i wasn't using and madvr crashed....
I can't do much about that without the crash report. Did you save it or email it to me?

oh one other thing.... 0.52 (*) got my computer to freeze up completely today i had to hard reboot it ... do you think if i enable debug and in case that would ever happen again... will the reason be in the log file ?
No, I don't think so.

Yes.
Try playing with the v0.54 flush settings then. Maybe that helps.

I don't know if you are using ATI drivers, but this is a problem I reported way back.
http://forum.doom9.org/showthread.php?p=1480241#post1480241

I found when I updated my drivers that the full screen exclusive mode meant everything switched to 60hz.

The last working version of ati ccc drivers that didn't switch from 50hz to 60hz in exclusive mode is version 10.10.

Everything after that and exclusive mode switched to 60hz, no matter how many settings in catalyst you tweaked.
This *may* be worked around in v0.54, thanks to the CPU consumption bug fix. Huh? Makes no sense? No, it doesn't. The whole CPU consumption bug makes no sense, anyway. But still, the refresh rate problem might be worked around in v0.54.

Just my quick report (only visual, I don't look at stats for now) :
- 0.49: ok
- 0.50 (new path): CPU heavy (dropped frames)
- 0.51: ok
- 0.52: CPU heavy (dropped frames)
- 0.53: ok
- 0.54, tomorrow: CPU heavy. :D
Haha!! :p Yeah, you better skip versions with even numbers, they're evil!!

It's fixed, thanks a lot madshi!
http://madshi.net/icon_crazy.gif

I'm still waiting for others to comment on this, though. The cause of the high CPU consumption in your case was really weird. So I'm not sure if it's the same for the others. I sure hope so, but I'm not sure.

everything is ok for me in 053 so far.
:)

With 0.52 no dropped frames but presentation glitches appear while decoder, render, backbuffer queues are stable. I guess you fixed stats. Playback experience is the same as with 0.51 - with 14 or 16 frames pre-render playback is smooth, jerking with lesser number of frames.

0.53 is worse for me, even with 14 and 16 pre-rendered I have some glitches.
Try playing with the v0.54 flush settings. I think in your case it might help.

I tested it before , it makes no different .
Well, in that case (and if v0.54 doesn't help) then I don't really know how to improve things for you... :(

I'm the one with the ATI 6850M 120Hz issue.

Same problem in .53, log attached.
Unfortunately attachments sometimes take a long time to be approved here. It's safer to upload the log somewhere else.

That's awesome! madshi's been putting out new versions like a banshee so I'm sure you'll see a new version soon.
Nah, there won't be a new version for a couple of months now, just to balance the last couple of days... :p

I'm getting a large number of presentation glitches in 0.53. I tried increasing the backbuffers to 16, but that only made things worse, almost 500 in a 10 minute video.
Try the v0.54 flush settings, they might help.

[SamuriHL]

Nah, there won't be a new version for a couple of months now, just to balance the last couple of days... :p


Well, as long as it works for everyone that's fine. Give you a much needed break. LOL!

[madshi]

madVR v0.54 released

http://madshi.net/madVR.zip

* fixed high CPU consumption in new exclusive mode rendering path (hopefully)
* added option to use windowed mode flush tweaks for new exclusive path, too
* added batch file to switch between debug <-> release mode
Thanks to ajp_anton for providing the first version of the batch file.

My original hope for the new exclusive mode rendering path was that no manual tweaks would be necessary. But after the last couple of days and various feedback from you guys my impression is that the flush settings do still make a difference, sadly. So I've now added an option which allows you to activate the flush settings for the new exclusive mode rendering path, too. If you don't activate this option, no flushs are done at all. If you find that activating some flushs works better for you, please let me know which exact settings work best for you. My recommendation on what to try is this:

(1) Try default setting without any flushs first. If you don't get good results:
(2) Activate the "use windowed flush tweaks" option. Then try setting "after last render step" and "after D3D presentation" to "flush", set the others to "don't flush". If that still doesn't help:
(3) Try setting "after intermediate render steps" to "flush", too, in addition to (2). If that still doesn't help:
(4) Try setting some "flush"s to "flush & wait", maybe first "after last render step" or "after D3D presentation".

[someone`]

Thanks , i try (2) , it works both windowed and FSE .

[Andy o]

madshi, thanks again. Do you think the higher CPU usage and/or my problems with HAM (ATI Stream) decoder in windowed, old exclusive, and all modes on versions 0.53 and before (queues drop to zero, esp. present and backbuffer) can be due to lack of RAM or its speed? I'm running 2GB of RAM on Win 7-64, It's DDR2-800 but it is clocked to 667 to be in sync with the CPU, I think whatever the mobo does automatically. It's an old Asus P5e-VM HDMI with a G35 chipset, but I use an ATI 5770.

[DigitalLF]

MadShi: sorry it was just i app hang in my "Event Viewer" with binary data "UNKNOWN" and it was madHCCtrl.exe that crashed. (i think its just if you have 2 devices with same name or some other data that is the same on both "devices" and you try to remove one of them..)
an export did not help at all...

[madshi]

Thanks , i try (2) , it works both windowed and FSE .
Oh, so problem solved for you?

Do you think the higher CPU usage and/or my problems with HAM (ATI Stream) decoder in windowed, old exclusive, and all modes on versions 0.53 and before (queues drop to zero, esp. present and backbuffer) can be due to lack of RAM or its speed?
I've no idea.

it was just i app hang in my "Event Viewer" with binary data "UNKNOWN" and it was madHCCtrl.exe that crashed.
Ah, so you didn't get a proper dialog with the option to mail information to me? In that case there's not much we can do, unfortunately.

[leeperry]

My original hope for the new exclusive mode rendering path was that no manual tweaks would be necessary. But after the last couple of days and various feedback from you guys my impression is that the flush settings do still make a difference, sadly.
using 0.54 on XPSP3/8800GS, I've had PotPlayer crashing when going FSE>FSW(default settings, no flush selected), and drwatsn32 reported that it was due to "ntdll!RtlpWaitForCriticalSection". I didn't keep the drwatsn32 log coz you said these were useless to you :o

I'll run more tests and try to provide you w/ mVR debug logs..and thanks for the new builds!

[SamuriHL]

On my laptop, I have to have the ...after last render step set to flush & wait (sleep) else it no workie. I haven't yet tried 0.54 on my HTPC's yet. I never even got to 0.53 on those. :) Will try soon. They should be ok without having to flush, but, my laptop...definitely not. All the others can be set to no flush, but, that one MUST be set to flush & wait or one of my test files breaks up horrible and loses tons of frames with massive presentation errors, as well.

[Hprd]

Hrmm, with bitperfect audio (reclock doesn't resample to sync with system clock, etc.) i still get stuttery playback, even after trying all your suggestions :(. If i just unclick "slave reference clock to audio" my playback is more or less perfect. (and of course like said b4, for some reason, not all videos do this, it seems ones that are at 30fps, exactly, with 44khz audio are the bad ones, lol).

[Mark_A_W]

With 0.54 I either get a series of mad flashes as it constantly tries to get into exclusive mode, or Zoom Player just crashes :(

[someone`]

Oh, so problem solved for you?

Yes , SamuriHL's setting is the best for me .
After last render step set to flush & wait (sleep)
All the others set to no flush .
I have no problem switching between windowed and exclusive mode multi times .

[SamuriHL]

That's my experience on my laptop, as well.

[jmone]

v0.54 testing on my HTPC

1) Using Relcock to change the Refresh Rate to match the media fps but I'm seeing a different behaviour from V0.52:
- V0.54 using New Path = Upon a refresh rate change, madVR now displays video frames but the OSD stills says the old refresh rate and while it does not report any dropped frames the playback is choppy
- V0.54 using Old Path = Fine.

Q) - Given NOT changing freq to match fps produces a poor playback expereince, I'm not sure that new path is currently a viable option to HTPC duty which has a mix of fps material. Or am I missing somthing?

2) 1080/50p x264 material plays well but I see that on fast pans the OSD itself breaks up / tears / displays duplicate characters etc

Thanks
Nathan

[yesgrey]

madshi,

I was going to post my log with v0.53 because I had several problems with one file, but you beat me. v0.54 is running great, without any problems, so it probably were the high cpu usage problems.

When we start thinking that madVR cannot improve anymore, you come and surprise us. :)

Well done!

[Andy o]

The Kill-A-Watt is reporting ~10W less when playing with HAM decoder compared to ffdshow-mt :D

[pankov]

With 0.54 I either get a series of mad flashes as it constantly tries to get into exclusive mode, or Zoom Player just crashes :(
It's the same with me but only when using the second display (projector). If I play it on the first (LCD monitor) everything is fine. I've tried both madVRcpu and madVRcpu2 and I get mixed results - madVRcpu2 flashes/crashes as v0.54 while v0.53 has the same high CPU usage as v0.52/0.51.
Here are some log files from my tests this evening.
http://www.mediafire.com/?xd3r76fo2n5xdz8

[ajp_anton]

Is the "slow" (.5 s) windowed<->exclusive switch because of madVR or Windows (/drivers)?
I noticed that all buffers seem to be emptied after the switch. Can't you render the frames already created, and just start filling the buffers with frames of the new size, and do the actual switch when all "old" frames are rendered?

[tmbt]

It's the same with me but only when using the second display (projector). If I play it on the first (LCD monitor) everything is fine. I've tried both madVRcpu and madVRcpu2 and I get mixed results - madVRcpu2 flashes/crashes as v0.54 while v0.53 has the same high CPU usage as v0.52/0.51.
Here are some log files from my tests this evening.
http://www.mediafire.com/?xd3r76fo2n5xdz8

Same problem here. If i play on first monitor everything is fine.
On secondary monitor i've flashes/crashes. I'm currently using 0.50.

[ajp_anton]

Not sure I understand the function of each queue shown in the OSD... how much of the following is correct?
Decoder queue: Decoded YV12 frames, stored in system RAM
Upload queue: Frames sent to the graphics RAM
Render queue: Processed frames in RGB
Backbuffer queue: "Direct3D queue for frames soon to be presented" /madshi
Present queue: same as backbuffer?

Also, the backbuffer/present queues never seem to want to go above ~11-13. But when set to 16, the seekbar delay seems to be a lot faster than when it's at ~2 or 3.