madVR - high quality video renderer (GPU assisted)

[Razoola]

Well, it doesn't matter, anyway, the final exclusive mode rendering path is coming soon and should fix the problem you're having.

Yippee, I am eargerly awaiting this.

[cyberbeing]

On my 2.4GHz dual-core it uses at least twice as much CPU as EVR-CP: ~3200kbps H.264 hovers around 15-20% with EVR-CP, with madVR it's 35-40%.

Very strange, since I based that avg < 3% CPU stat on my 6 year old AMD X2 4800+ (939) 2.4Ghz dual-core. :rolleyes:

The only setting which potentially eats extra CPU cycles is Flush & Wait (loop). Something is very wrong with your PC, if you claim you are not using DXVA with EVR-CP and seeing madVR double CPU usage.

Please list your cpu, gpu, decoder, splitter, media player, and operating system.

[fastplayer]

Very strange, since I based that avg < 3% CPU stat on my 6 year old AMD X2 4800+ (939) 2.4Ghz dual-core. :rolleyes:
I'm not sure what the :rolleyes: mean in this context...
Anyway, I've got essentially the same CPU as you: Athlon64 X2 3800+@2.4GHz, on Socket 939.

The only setting which potentially eats extra CPU cycles is Flush & Wait (loop). Something is very wrong with your PC, if you claim you are not using DXVA with EVR-CP and seeing madVR double CPU usage.

Please list your cpu, gpu, decoder, splitter, media player, and operating system.
It actually doesn't matter which combinations of decoders/splitters/media players/OSs I use, the effect is the same: madVR uses twice as much CPU as other renderers.
Here's the rest of my setup:
Win7 32-bit
HD4670, CAT 11.2
MPC-HC rev2956
Haali/LAV/MPC's internal Splitter
ffdshow rev3765/DivX AVC/MPC's internal decoder
madVR 0.42 (down-/upsampling methods seem to have next to zero impact on CPU usage)

[djsolidsnake86]

seem that with last version some flv files aren't played correctly

[madshi]

Disabled while in fullscreen mode.

I've found an issue I can duplicate on this machine using 0.42.
How about the garbage issue you reported before? Is that reproducable with v0.42?

Using MPC, if I expand to fullscreen and bring it back to normal window mode by double clicking on the window while watching a video I get Aero eventually changing modes in an endless loop.
You mean Aero constantly switches on/off? How often? Just a couple of times? Or all the time until you stop MPC?

When exclusive mode is disabled and when I have both options disable desktop composition and only in fullscreen mode ticked Aero still goes through a changing of modes for a couple of seconds
In what way is this different to the "endless loop"?

My question is, does madVR do much processing on the cpu at all?
madVR consumes a little bit more CPU than VMR/EVR because the video frames are cached in system RAM, while with VMR/EVR usually all decoded video frames are directly transported to GPU RAM. The madVR queues do consume a little bit more CPU, also the whole VSync handling consumes a bit of CPU, but it shouldn't really be very much.

The biggest improvement in terms of reducing frame drops with these scripts was to choose decoders that are multithreaded so thought it would be worth while to ask yourself if your cpu dependent code is already multithreaded or not or if it would even be of benefit.
madVR is as much multithreaded as makes sense.

Some users on avsforums are adament that to maximize quality (avisynth script wise), I shouldn't use madVR
Huh!? What is the reasoning they give? Why would madVR be inferior when using avisynth scripts? I don't really understand that.

seem that with last version some flv files aren't played correctly
Which OS? Which splitter? Which exact decoder? Which exact problem do you have? I need more details...

[djsolidsnake86]

seven x64, ffdshow and madvr 0.42
screen is black and playback go on with audio
happen only with some flv files

[pirlouy]

You forgot splitter...
I have NO problem here with MPC-HC, MPC-HC FLV splitter, ffdshow, madvr 0.42, Seven x64 with 15 .flv files I found on my HDD...

[djsolidsnake86]

i don't have flv splitter in filters
very strange

[mark0077]

"Huh!? What is the reasoning they give? Why would madVR be inferior when using avisynth scripts? I don't really understand that."

The reasoning being with the system under stress with CPU hungry avisynth scripts. Madvr will drop more frames than evr. If its not something that can be prevented then it's something they will need to deal with by reducing avisynth script CPU usage like I did until madvr doesn't drop frames.

[dansrfe]

I can inverse telecine, resize and sometimes run smoothtweak on-the-fly in avisynth with madVR and no frames are ever dropped or delayed. My system never breaks a sweat. I've even mdegrain'd on-the-fly without any issues.

[mark0077]

Resize and degrain? :D read my posts above i said when the system is under stress, not when the system "never breaks a sweat" talk about the complete opposite!! I guess your not using mvtools with 16 8 and 4 blksizes then. Try that on 1080p in real time. Why do people always come and say x works for me or it always runs fine here when other people clearly say something doesn't for them. In any case does it matter what external filter one uses. The point is madvr will drop more frames than evr when the machine is on the limit. Either we must reduce the processing done outside of madvr to compensAte or madvr reduces it's processing. It seems this isn't possible so theres nothing left to discuss. It's no piece of softwares fault just a fact.

[fairchild]

I think mark is referring to a frame doubling script such as this. (turns 30fps into 60fps, 24fps into 48fps etc.) I tried it once and it definitely stresses the CPU to the limit. It definitely gives the video a unique look and it's definitely a desired taste. (it kinda gives the "soap opera" effect)

SetMtmode(2,10)
source=ffdshow_source()
source=changefps(source,source,true)
# assume progressive PAL 25 fps or NTSC Film 23.976 source
backward_vec = source.MVAnalyse(blksize=16, isb = true, chroma=false, pel=1, searchparam=1, idx=1)
# we use explicit idx for more fast processing
forward_vec = source.MVAnalyse(blksize=16, isb = false, chroma=false, pel=1, searchparam=1, idx=1)
source.MVFlowFps(backward_vec, forward_vec, num=2*FramerateNumerator(source), \
den=FramerateDenominator(source), mask=0, idx=1)
distributor()

[dansrfe]

Ah for 1080p post-processing...Well, that's a different story. Get a more powerful cpu or overclock I guess. I won't deny that I can't post-process with heavy filters on a 1080p stream but I think that's mainly due to the fact that I'm on a C2D vs. a oc'd quad, i7, or even hexacore.

[ryrynz]

How about the garbage issue you reported before? Is that reproducable with v0.42?

I haven't managed to reproduced it yet.

You mean Aero constantly switches on/off? How often? Just a couple of times? Or all the time until you stop MPC?

Yes, Aero switches on and off. This continues until I close MPC, also the video display turns black and doesn't change.


In what way is this different to the "endless loop"?

The whole screen turns black for a moment and then MPC and any other windows that are open redraw themselves, this occurs over a couple of seconds.

[cyberbeing]

I'm not sure what the :rolleyes: mean in this context...
Anyway, I've got essentially the same CPU as you: Athlon64 X2 3800+@2.4GHz, on Socket 939.
Just that I'm skeptical, since I can't reproduce the problem on a system not all that different than yours.
Your problem appears unique to only you, since no one else in this thread appears to be have high CPU issues with madVR.

It actually doesn't matter which combinations of decoders/splitters/media players/OSs I use, the effect is the same: madVR uses twice as much CPU as other renderers.
Here's the rest of my setup:
Win7 32-bit
HD4670, CAT 11.2
MPC-HC rev2956
Haali/LAV/MPC's internal Splitter
ffdshow rev3765/DivX AVC/MPC's internal decoder
madVR 0.42 (down-/upsampling methods seem to have next to zero impact on CPU usage)
Out of curiosity, have you installed Win7 SP1?

The following are my suggestions for troubleshooting, please do all of them:

Uninstall FFDshow and DivX decoders.
Uninstall Haali, LAV, and DivX splitters.
Uninstall madVR and delete the settings.bin
Open MPC-HC and disable ALL internal filters.
Restart your computer.

Install Haali as your only splitter.
Install FFDshow as your only decoder.
Install madVR.
Playback a MKV with MPC-HC and madVR.
Open madVR settings. Set all resizers to Bilinear, Disable Fullscreen Exclusive, and set all Windowed Mode Tweaks to Don't Flush.
Close MPC-HC
Playback a MKV with MPC-HC and madVR once again.
Does the problem still exist?

If so, download Process Explorer (http://download.sysinternals.com/Files/ProcessExplorer.zip), run as administrator, double click on MPC-HC in Process Explorer while playing an MKV in madVR, click on the Threads tab, and take a screenshot of the Threads tab (PrtScn & paste in MS Paint) when you are seeing High CPU usage. Take a screenshot of your entire Process Explorer window during high CPU usage. Navigate the menu View -> System Information and take a screenshot of the System Information window during high CPU usage. Post all three screenshots here. Hopefully that should give some insight to the cause. I'm somewhat suspecting it's a LAV or DivX MKV splitter issue. Last week when I tried LAV splitter with madVR, they didn't get along at all. If madVR.ax is really to blame, it should show with high CPU use in the Threads tab screenshot. In which case, there may be a bug of some sort which madshi needs to fix.

[fastplayer]

Your problem appears unique to only you, since no one else in this thread appears to be have high CPU issues with madVR.
Probably or because no one else has ProcMon/Task Manager opened at all times...
As for your troubleshooting tips, thanks, been there done that:
- This is not a codecpack-infested machine.
- Although it's not an apple-vs-apple comparison, madVR performed in XPSP3 the same as it does now in Win7 SP1.
- Most importantly: I'm perfectly happy with madVR :)

[madshi]

seven x64, ffdshow and madvr 0.42
screen is black and playback go on with audio
happen only with some flv files

i don't have flv splitter in filters
very strange
Hmmm... So you probably have the internal FLV splitter disabled in MPC-HC? What happens if you enable it, does the problem then go away?

Can anybody reproduce any problems with FLV files in Windows 7? There were 2 different people reporting problems now, so it should be credible.

The reasoning being with the system under stress with CPU hungry avisynth scripts. Madvr will drop more frames than evr. If its not something that can be prevented then it's something they will need to deal with by reducing avisynth script CPU usage like I did until madvr doesn't drop frames.
Ok, makes sense.

Yes, Aero switches on and off. This continues until I close MPC, also the video display turns black and doesn't change.

The whole screen turns black for a moment and then MPC and any other windows that are open redraw themselves, this occurs over a couple of seconds.
Ok, I'll see if I can reproduce that. Can anybody else?

[ryrynz]

Ok, I'll see if I can reproduce that. Can anybody else?

http://forum.doom9.org/showthread.php?p=1481794#post1481794

My post linked above gives a bit more info on those two issues for anyone trying to reproduce them.

[djsolidsnake86]

tried also with flv splitter, same problem

[dansrfe]

Interestingly enough I can reproduce problems with the internal flv splitter, ffdshow and madVR. :( This is almost for all FLV files I have now. I thought it was a corrupt file or something but it doesn't happen with EVR-CP.

[cyberbeing]

Probably or because no one else has ProcMon/Task Manager opened at all times...
As for your troubleshooting tips, thanks, been there done that:
- This is not a codecpack-infested machine.
- Although it's not an apple-vs-apple comparison, madVR performed in XPSP3 the same as it does now in Win7 SP1.
- Most importantly: I'm perfectly happy with madVR :)
It has nothing to do with a codecpack-infested machine. It has to do with reducing the test case variables. Since madVR doesn't use +20% CPU on a X2 4800+, it shouldn't be any different on a X2 3800+. Even if madVR.ax has low CPU use, something else on your PC must have high CPU when using madVR. Decoder? Splitter? GPU driver? Windows Kernel? Hardware Interrupts? DPC? Anti-Virus? Some other random driver? There are numerous possibilities, and taking the Process Explorer screenshots I described should clearly identify what is eating the extra CPU cycles. Yet you seem to be happy with abnormally high CPU usage, and have no desire to find the cause, so I'll just drop it.

[mark0077]

madshi, I know you looked into this before, but am unsure if you checked it recently. When starting a movie with madVR, I usually get between 4 and 20~ frame drops, randomly falling somewhere in between these. If the very start of the movie, ie the first second, actually contains some content, obviously we will see a noticible judder effect.

Is this something madVR can control, ie can it wait internally for a period of time for whatever causes the frame drops (buffers filling maybe?) to be completed before beginning the rendering process.. Obviously this would be very low priority but just aiming for perfection it would be great to start a clip and see 0 frame drops in the first second or two.

[Luv]

cyberbeing,can you test these:

http://forum.doom9.org/showpost.php?p=927671&postcount=3

beyonce.at.the.bbc.1080mbaff.sample.ts 1080 "i" (50mb)
BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts 1080 "p" (100mb)

I have a x2 4200+ and they use 7% cpu with DXVA (WMR9)

beyonce.at.the.bbc.1080mbaff.sample.ts 1080 "i"
ZP+Coreavc2.0+madVR 0.36: ~56% cpu with deinterlacing

BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts 1080 "p"
~64% cpu

[cyberbeing]

I don't have a GPU which supports H264 hardware decoding.

beyonce.at.the.bbc.1080mbaff.sample.ts
MPC-HC + FFDshow (ffmpeg-mt + cubic interpolation deinterlacing) + Haali + madVR 0.42: ~58% CPU
MPC-HC + FFDshow (ffmpeg-mt + cubic interpolation deinterlacing) + Haali + VMR9: ~56% CPU

BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts
MPC-HC + FFDshow (ffmpeg-mt) + Haali + madVR 0.42: ~54% CPU
MPC-HC + FFDshow (ffmpeg-mt) + Haali + VMR9: ~52% CPU

Edit: Luv, since you read my post but didn't respond, what exactly were you curious about? Just interested in how my CPU/setup compared to yours?

[bjd]

Don't know if anyone can point me in the right direction, but I have very frustrating issue with an XP where I start to experience serious delayed frames with MadVR after about 40 minutes of playback no matter what the source material is.

For the 40 minutes or so playback is superb, a maybe 1 or 2 dropped/delayed frames at the start of playback and that's it, but after the system has been running a while, frames start to get delayed at an alarming rate (5 a second).

A reboot always sorts it out. I have checked the GPU/CPU/Memory use with various tools and they all seem minimal, but it is like a driver somewhere on the PC goes skew whiff after a while.

The PC is XP SP3, Athlon x64 Dual 5000+, 2gb RAM, 2gb Geforce 430, multiple hard disks running on an NForce 630/7025 based motherboard. Playback is always on Mpc-Hc.

I am going to do some more investigating this weekend, but any pointers as to what in general causes the delayed frames might give me a headstart.

[mark0077]

Bjd are you usIng reclock? I had issues before when using it when it didn't and still doesn't detect my monitors refresh correctly and started changing the media playback speed in weird ways. Just something to check.

[bjd]

I do use ReClock in bit exact mode by slaving reference clock to audio, but i still get the issue of delayed frames if I fall back to the the XP default direct sound, so I have discounted ReClock as the culprit.

[Luv]

I don't have a GPU which supports H264 hardware decoding.

beyonce.at.the.bbc.1080mbaff.sample.ts
MPC-HC + FFDshow (ffmpeg-mt + cubic interpolation deinterlacing) + Haali + madVR 0.42: ~58% CPU
MPC-HC + FFDshow (ffmpeg-mt + cubic interpolation deinterlacing) + Haali + VMR9: ~56% CPU

BBC.HD.Robin.Hood.S01E03.H.264.1080MBAFF.AC3.5.1-BBC.sample.ts
MPC-HC + FFDshow (ffmpeg-mt) + Haali + madVR 0.42: ~54% CPU
MPC-HC + FFDshow (ffmpeg-mt) + Haali + VMR9: ~52% CPU

Edit: Luv, since you read my post but didn't respond, what exactly were you curious about? Just interested in how my CPU/setup compared to yours?

Thanks for you swiftness,cyberbeing ! :)
Yeah,I just wanted to make sure nothing was borked on my rig.Since your cpu is about 9% more powerful than mine,your numbers make sense (At least for .264 1080p but for .264 1080i,ouch ! Seems that Coreavc outperforms very noticeably your actuel decoder.)
Still,I don't understand how you managed to evaluate the madVR cpu usage.You were speaking about a 3% but I might have completely misunderstood your post...

[pankov]

now that I have access to my forum account and I can post I'm glad to report that all GUI draw issues with ZoomPlayer are fixed with v0.42
:)
now if only I can find what's causing the access violation when going to the next file I'll be one more step closer to the home theater nirvana
;)

[soulkeeper]

I've recently installed madvr after reading for it's excellent pq (congratulations @madshi)!!
I updated today to 0.42,using mpc-hc and ffdshowand i'm going to do some tests...the resizing is done to 1280*720 in ffdshow because i use an avisynth script to interpolate 23.976->59.94....
Are there any benefits of using exclusive modein madvr?does it "bypasses" any "dirty" processes that may occur in the os during the playback?
i realize that aero is disabled when in fullscreen exclusive mode but there is an option to leave it enabled when we are not in exclusive...

Till now i used evr cp,D3d fullscreen mode and full floating point processing enabled in mpc-hc options with aero enabled...so i'd prefer to start my tests with aero enabled..

Can i do that when in exclusive mode?

Thanks!

[pankov]

And now back to some other issues I found in the latest versions:

1. If I disable the switch to disable Aero (so I have Aero always on) I get DirectVobSub's icon (green arrow) leftovers in the system tray. So I guess ZoomPlayer is not destroying the filters correctly, right? Strangely if I use the default madVR setting (which is "when in fullscreen") I don't get the leftover icons.
Should I try to talk to Blight (the author of ZoomPlayer) about this now that he's back and working on it again?

2. If I restore ZoomPlayer (go out of fullscreen an back to windowed) while in Exclusive mode I get an error about Direct3D device failed
madVR reports:
- resetting Direct3D device failed (88760868)
- creating Direct3D device failed (88760868)

Rebuilding the graph (restarting playback) doesn't help. I have to close the player and then I can start the movie again.

Here is the log
http://www.mediafire.com/file/k3ft0n7b1ve4664/madVR%20-%20log%20-%20D3D%20failed.rar
(madshi, this one is from v0.42. you can also use the one that I sent you a few days ago)
This never happens with v0.31 but I saw the same error with other 0.37+ versions but I thought I did something wrong then - now I can repeat the problem every time ... at least I did it 6 times in a row. I also noticed that this only happens if I start the playback in fullscreen mode. If I go from windowed to fullscreen and then back to windowed everything is OK.
Am I the only one getting this error? Can it be connected with the access violation problem which I have?

[mark0077]

Hi madshi, I have a clip which to my surprise won't play with madVR. Audio plays but video and mpc-hc itself seems to become unresponsive. Plays fine with evr.. Here is madVR pin info. Do you need a sample or is pin info enough for you to recognize what might be wrong...

Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {04FE9017-F873-410E-871E-AB91661A4EF7}
Filter: ffdshow Video Decoder
Pin: Out

- Connection media type:

Video: YV12 1024x304 (480:209) 23.98fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 466944
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(576,304)
rcTarget: (0,0)-(576,304)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417083

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 480
dwPictAspectRatioY: 209
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: 304
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 466944
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 40 02 00 00 30 01 00 00 ........@...0...
0010: 00 00 00 00 00 00 00 00 40 02 00 00 30 01 00 00 ........@...0...
0020: 00 00 00 00 00 00 00 00 3b 5d 06 00 00 00 00 00 ........;]......
0030: 00 00 00 00 00 00 00 00 e0 01 00 00 d1 00 00 00 ........à...Ñ...
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 04 00 00 ........(.......
0050: 30 01 00 00 01 00 0c 00 59 56 31 32 00 20 07 00 0.......YV12. ..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

[cyberbeing]

Still,I don't understand how you managed to evaluate the madVR cpu usage.You were speaking about a 3% but I might have completely misunderstood your post...
Using Process Explorer to view the theads of MPC-HC.
http://img203.imageshack.us/img203/9747/theads.png
Usually madVR.ax is completely idle, apparently using no CPU whatsoever. Every couple minutes madVR.ax will use ~2-5% CPU for no more than 2 seconds, but that may be caused by my use of Flush & Wait (Loop). Other than that, there may be 1% CPU being used by madVR.ax in the splitter.ax (Haali Splitter) thread stack. From that I estimated less than 3% average CPU usage by madVR.

[JamPS]

I'm having problems with dual gfx cards and 4 display setup, when I start mpc-hc with some video, the screens constantly blink until I pause and then resume after some sec. Windows 7 reports that some Aero(?) mode has been changed.
EVR works fine.

1st gfx: Radeon HD 6850
2nd gfx: Radeon HD 4850

No crossfire(obviously).

[dansrfe]

I just reverted back to v0.41 for the time being.

[madshi]

tried also with flv splitter, same problem
Hmmmmm... How can I reproduce this problem? It seems to work just fine for me! :( Can you upload a log for me? Perhaps that helps...

madshi, I know you looked into this before, but am unsure if you checked it recently. When starting a movie with madVR, I usually get between 4 and 20~ frame drops, randomly falling somewhere in between these. If the very start of the movie, ie the first second, actually contains some content, obviously we will see a noticible judder effect.

Is this something madVR can control, ie can it wait internally for a period of time for whatever causes the frame drops (buffers filling maybe?) to be completed before beginning the rendering process.. Obviously this would be very low priority but just aiming for perfection it would be great to start a clip and see 0 frame drops in the first second or two.

Interestingly enough I can reproduce problems with the internal flv splitter, ffdshow and madVR. :( This is almost for all FLV files I have now. I thought it was a corrupt file or something but it doesn't happen with EVR-CP.
Which OS? Can you try different splitters and different decoders? Maybe that helps us figuring out which setup exactly is causing the problems. On my PC FLV files work just fine.

Don't know if anyone can point me in the right direction, but I have very frustrating issue with an XP where I start to experience serious delayed frames with MadVR after about 40 minutes of playback no matter what the source material is.

For the 40 minutes or so playback is superb, a maybe 1 or 2 dropped/delayed frames at the start of playback and that's it, but after the system has been running a while, frames start to get delayed at an alarming rate (5 a second).

A reboot always sorts it out. I have checked the GPU/CPU/Memory use with various tools and they all seem minimal, but it is like a driver somewhere on the PC goes skew whiff after a while.

The PC is XP SP3, Athlon x64 Dual 5000+, 2gb RAM, 2gb Geforce 430, multiple hard disks running on an NForce 630/7025 based motherboard. Playback is always on Mpc-Hc.

I am going to do some more investigating this weekend, but any pointers as to what in general causes the delayed frames might give me a headstart.
Hmmmm... Do you have to reboot? Or does restarting the media player also help? My first guess would be that either your GPU driver has some kind of memory leak, resulting in problems after a while. Or that your GPU clocks down after a while and fails to clock up again. Can you try locking your GPU clocks and voltages at a fixed value, just as a test? You should be able to do that with one of the tweaker tools, I think.

the resizing is done to 1280*720 in ffdshow because i use an avisynth script to interpolate 23.976->59.94....
Can't you interpolate first and then let madVR resize?

Are there any benefits of using exclusive modein madvr?does it "bypasses" any "dirty" processes that may occur in the os during the playback?
The main benefit of the exclusive mode is to guarantee that there's no tearing, and maybe to squeeze out a bit more performance.

i realize that aero is disabled when in fullscreen exclusive mode but there is an option to leave it enabled when we are not in exclusive...

Till now i used evr cp,D3d fullscreen mode and full floating point processing enabled in mpc-hc options with aero enabled...so i'd prefer to start my tests with aero enabled..

Can i do that when in exclusive mode?
Sure. If you uncheck the "disable desktop composition" option in the madVR settings dialog, Aero should stay enabled all the time.

1. If I disable the switch to disable Aero (so I have Aero always on) I get DirectVobSub's icon (green arrow) leftovers in the system tray. So I guess ZoomPlayer is not destroying the filters correctly, right? Strangely if I use the default madVR setting (which is "when in fullscreen") I don't get the leftover icons.
Should I try to talk to Blight (the author of ZoomPlayer) about this now that he's back and working on it again?
I'm not sure about who's at fault here. Can't imagine it has anything to do with madVR, but I don't really know. Don't know what to tell you. I guess the leftovers go automatically away if you move the mouse cursor over them?

2. If I restore ZoomPlayer (go out of fullscreen an back to windowed) while in Exclusive mode I get an error about Direct3D device failed
madVR reports:
- resetting Direct3D device failed (88760868)
- creating Direct3D device failed (88760868)

Rebuilding the graph (restarting playback) doesn't help. I have to close the player and then I can start the movie again.

Here is the log
http://www.mediafire.com/file/k3ft0n7b1ve4664/madVR%20-%20log%20-%20D3D%20failed.rar
(madshi, this one is from v0.42. you can also use the one that I sent you a few days ago)
This never happens with v0.31 but I saw the same error with other 0.37+ versions but I thought I did something wrong then - now I can repeat the problem every time ... at least I did it 6 times in a row. I also noticed that this only happens if I start the playback in fullscreen mode. If I go from windowed to fullscreen and then back to windowed everything is OK.
Am I the only one getting this error? Can it be connected with the access violation problem which I have?
Will have a look at that.

Hi madshi, I have a clip which to my surprise won't play with madVR. Audio plays but video and mpc-hc itself seems to become unresponsive. Plays fine with evr.. Here is madVR pin info. Do you need a sample or is pin info enough for you to recognize what might be wrong...
Need a sample. And info about OS, splitter and decoder.

I'm having problems with dual gfx cards and 4 display setup, when I start mpc-hc with some video, the screens constantly blink until I pause and then resume after some sec. Windows 7 reports that some Aero(?) mode has been changed.
EVR works fine.

1st gfx: Radeon HD 6850
2nd gfx: Radeon HD 4850

No crossfire(obviously).
That's weird! Can I have a log, please? Let the blinking run for a couple of seconds, then press pause and resume and let it continue to run for a couple of seconds. Then close MPC-HC.

(In order to create a log, rename "madVR [debug].ax" to "madVR.ax", then restart MPC-HC. After that madVR will write a log file to your desktop. Please *zip* the log file.

I just reverted back to v0.41 for the time being.
Why?

[dansrfe]

Because we're all having problems with the internal flv splitter. I was also having problems with the avi splitter too. Basically no video or it hangs and then the audio works fine. All I did was revert back to 0.41 with all other conditions constant and everything works as expected to. Something doesn't fit as per this incident.

[fairchild]

I'm also having issues with certain FLV files. They will hang the media player and just have the audio going while there is a black screen with no image. I verified that if I switch the renderer to any of the following, the files play fine: EVR-CP or Haali or VMR9 Renderless or Video Renderer. The following filters are being used: ffdshow video decoder (3768 ICL 12), ffdshow audio decoder (3768 ICL 12), reclock audio renderer (1.8.7.3), FLV Source (splitter), PotPlayer (1.5 build 26978).

I also tested by rolling back to 0.41 as dansrfe mentioned, and the FLV's that hang the media player and only play audio begin to work again.

I'm sticking with 0.42 though since this is a minor inconvenience for me, as I don't exclusively watch FLV's and they are usually poor quality to begin with so I will just switch renderer's as a workaround till it's corrected.

[soulkeeper]

Can't you interpolate first and then let madVR resize?

No i can't..with the script i'm using ,i'm getting about 90% cpu util. with my Q9400@3.5Ghz if i don't resize before using avisynth..


The main benefit of the exclusive mode is to guarantee that there's no tearing, and maybe to squeeze out a bit more performance.

Very nice!!


Sure. If you uncheck the "disable desktop composition" option in the madVR settings dialog, Aero should stay enabled all the time.

I've already unchecked that,but i thought that aero is still disabled in exclusive because when pressing ctl+j to see the stats i don't see the composition rate..(you've wrote in a previous post that when we don't see the composition rate then aero is disabled...

[madshi]

If I restore ZoomPlayer (go out of fullscreen an back to windowed) while in Exclusive mode I get an error about Direct3D device failed
madVR reports:
- resetting Direct3D device failed (88760868)
- creating Direct3D device failed (88760868)

Rebuilding the graph (restarting playback) doesn't help. I have to close the player and then I can start the movie again.

Here is the log
http://www.mediafire.com/file/k3ft0n7b1ve4664/madVR%20-%20log%20-%20D3D%20failed.rar
(madshi, this one is from v0.42. you can also use the one that I sent you a few days ago)
This never happens with v0.31 but I saw the same error with other 0.37+ versions but I thought I did something wrong then - now I can repeat the problem every time ... at least I did it 6 times in a row. I also noticed that this only happens if I start the playback in fullscreen mode. If I go from windowed to fullscreen and then back to windowed everything is OK.
Am I the only one getting this error? Can it be connected with the access violation problem which I have?
I can't reproduce that on my XPSP3 PC. Can anybody else?

Anyway, this should be fixed with the final exclusive mode rendering path, I think. Unless the problem also occurs if you disable exclusive mode?

[madshi]

I've found an issue I can duplicate on this machine using 0.42.

Using MPC, if I expand to fullscreen and bring it back to normal window mode by double clicking on the window while watching a video I get Aero eventually changing modes in an endless loop.
I've can replicate this problem usually within twenty seconds by constantly double clicking.
This is with exclusive mode is disabled and desktop composition disabled in fullscreen.

I've noticed the resizing pixelation and stretching I mentioned earlier during fullscreen resize does not occur when exclusive mode is disabled.

When exclusive mode is disabled and when I have both options disable desktop composition and only in fullscreen mode ticked Aero still goes through a changing of modes (enabling and disabling) for a couple of seconds and the video playback lags for a bit as this happens, using Windows 7 x64 with HD4890 & Cat 11.2.
I think this should be fixed in the next build.

[madshi]

No i can't..with the script i'm using ,i'm getting about 90% cpu util. with my Q9400@3.5Ghz if i don't resize before using avisynth..
Ah, you're *down*sizing, right? Then it makes sense. I originally thought you were upsizing.

I've already unchecked that,but i thought that aero is still disabled in exclusive because when pressing ctl+j to see the stats i don't see the composition rate..(you've wrote in a previous post that when we don't see the composition rate then aero is disabled...
Please try again with the next build. Might have been a bug.

[pankov]

I'm not sure about who's at fault here. Can't imagine it has anything to do with madVR, but I don't really know. Don't know what to tell you. I guess the leftovers go automatically away if you move the mouse cursor over them?

Yes, they disappear when I hover over them with the mouse.
Can anybody help me configure MPC-HC to use DirectVobSub? I've added it to the External Filters list as "prefered" and it's present in the graph but it doesn't load the subtitles automatically. Should I use the "autoloading version"? I've managed to replicate the same DS graph except this. I'd like to test if it's ZP's problem or it's something general on my PC.

I can't reproduce that on my XPSP3 PC. Can anybody else?

Anyway, this should be fixed with the final exclusive mode rendering path, I think. Unless the problem also occurs if you disable exclusive mode?
I noticed that a few times you've mentioned you are testing on XPSP3. I'm not sure if you do this only to reproduce my error reports or in general but I personally use Windows 7 Ultimate 32bit with Service Pack 1. And I can reproduce this problem on both of my PCs - one with i5-750 + AMD HD5750 and the other one with C2D6420 + NV9400 integrated.
btw if I remember correctly you're using nV9400 also, right?
Can you share with us which scaling algorithm you use on such low end GPU?

[madshi]

I noticed that a few times you've mentioned you are testing on XPSP3. I'm not sure if you do this only to reproduce my error reports or in general but I personally use Windows 7 Ultimate 32bit with Service Pack 1. And I can reproduce this problem on both of my PCs - one with i5-750 + AMD HD5750 and the other one with C2D6420 + NV9400 integrated.
My development PC is XPSP3, so that's where I do most testing. I do test Aero etc stuff on my win7 x64 HTPC, but that's more painful because it's not my development PC. Anyway, as I said, I expect the problem you reported to be fixed with the final exclusive mode rendering path, so I don't think it's worth it investigating it now.

btw if I remember correctly you're using nV9400 also, right?
Can you share with us which scaling algorithm you use on such low end GPU?
I'm trying to avoid scaling. Luckily, my projector is 1080p and 99% of my content is 1080p.

[madshi]

madVR v0.43 released

http://madshi.net/madVR.zip

* restored some v0.36 behaviour for exclusive -> windowed switch (XP only)
* fixed FLV problem (introduced with v0.42)
* fixed bug which resulted in Aero en/disabling happening incorrectly
I was originally planning to implement the final exclusive mode rendering path this weekend (and last, and the one before that). But these steady bug reports and bug fixes consume all my time, so I don't get to implement anything new, sadly. Maybe I should ignore bug reports for a while, so that I can finally get around to do something new?

[pirlouy]

Yeah ! Ignore bugs reports until I have ! :D

[pankov]

I'm trying to avoid scaling. Luckily, my projector is 1080p and 99% of my content is 1080p.
Lucky you :)
I too have a 1080p and a 1080p TV but I do watch a lot of 720p TV shows so that was the reason why I was asking.

My development PC is XPSP3, so that's where I do most testing. I do test Aero etc stuff on my win7 x64 HTPC, but that's more painful because it's not my development PC. Anyway, as I said, I expect the problem you reported to be fixed with the final exclusive mode rendering path, so I don't think it's worth it investigating it now.

madVR v0.43 released

http://madshi.net/madVR.zip

* restored some v0.36 behaviour for exclusive -> windowed switch (XP only)
* fixed FLV problem (introduced with v0.42)
* fixed bug which resulted in Aero en/disabling happening incorrectly
I was originally planning to implement the final exclusive mode rendering path this weekend (and last, and the one before that). But these steady bug reports and bug fixes consume all my time, so I don't get to implement anything new, sadly. Maybe I should ignore bug reports for a while, so that I can finally get around to do something new?

I totally understand your dilemma and I'll support you whatever you decide. I'll stop reporting problems until the new rendering path is ready.

[leeperry]

Oh well. Ok, I've changed some things back to the way v0.36 behaved - but only for Windows XP. I think the behaviour in XP was always fine. Most of the changes for improved exclusive -> windowed switching are now Vista (and newer) exclusive. Hope that you'll be back to v0.36 standards with the next build.
Yes, that seems to have done the trick! no more hiccups, no more zombie frames :thanks:

* settings dialog now remembers the page you've been on
That's a nice little time saver, but it still takes around 3 secs to get the properties dialog to show up, and it very often fails: http://thumbnails35.imagebam.com/12247/9e0577122464821.jpg (http://www.imagebam.com/image/9e0577122464821)

I'm not sure what network protocol you're using, but I've updated the "madHcCtrl.exe" MD5 in my firewall and it still very often fails like this. I run a stripped to the bone XPSP3, only TCP-IP's active...and I don't allow 127.0.0.1 loopback(due to possible attacks) either. I never need to get into those menus anyway...the only reason I might need to would be selecting LUT's for different colorspaces, but I'm sure you'd set up hotkeys for that http://forum-images.hardware.fr/images/perso/icon12.gif

[madshi]

it still takes around 3 secs to get the properties dialog to show up
Not sure why.

and it very often fails
Can you please do this:

(1) Replace madHcCtrl.exe with this file:

http://madshi.net/madHcCtrl.zip

(2) Open the settings dialog. At this moment there should appear a new file on your desktop, named "reply.dat".

(3) If the settings show up ok, rename "reply.dat" to "success.dat".

(4) If you get the "madVR instance didn't reply properly" message, rename "reply.dat" to "failure.dat".

Once you got both "success.dat" and "failure.dat", zip them up and mail them both to me. Maybe I can figure out what went wrong.

Please do NOT change any settings while doing all this.

[leeperry]

Can you please do this [..] zip them up and mail them both to me.
done, it failed the two first times then it worked(after a 3 secs wait).