Log in

View Full Version : Mpc 6.4 & Wmv9


MoFoQ
12th October 2004, 07:47
What is the best output setting for WMV9 on MPC 6.4 to help reduce cpu usage?

For some reason, some WMV9 VCM'ed AVI's take 100%+ in MPC6.4 (6.4.8.2 to be exact) while the same file plays fine at under 40% cpu utilization in wmp6.4 (at least I don't have to use wmp7+).

Any ideas?

(btw, already did search....but since the search function doesn't give me the page numbers in the uber huge MPC6.4 post...thought I'd throw the question out there in case there are other ppl who want to know).

Leak
12th October 2004, 08:06
Originally posted by MoFoQ
(btw, already did search....but since the search function doesn't give me the page numbers in the uber huge MPC6.4 post...thought I'd throw the question out there in case there are other ppl who want to know).

Try using "Show results as posts" when searching, that'll fix that.

rigel
12th October 2004, 09:17
If you are using Windows XP and/or have Direct X 9 installed, try using VMR-7 or VMR-9 renderer.
Choose "VMR7 (windowed)" or "VMR9 (windowed)"
At least it helped me :)
renderless versions usually consume more CPU time.
and VMR7 is usually faster.

MoFoQ
12th October 2004, 16:16
Originally posted by Leak
Try using "Show results as posts" when searching, that'll fix that.

thx...but what about the WMV9 issue?

Originally posted by rigel
If you are using Windows XP and/or have Direct X 9 installed, try using VMR-7 or VMR-9 renderer.
Choose "VMR7 (windowed)" or "VMR9 (windowed)"
At least it helped me
renderless versions usually consume more CPU time.
and VMR7 is usually faster.

Yea, I've tried that, still at 88% and up.

I wonder what WMP6.4 is doing differently....

dzy
13th October 2004, 01:30
for renderless modes

vmr9 renderless seems to be faster than vmr7 renderless

or is it video card/driver dependent?

MoFoQ
15th October 2004, 18:03
Apparently, it doesn't seem to be limited to just WMV9 based avi's (though it happens more often with them).

The "Tsukuyomi ep 2 raw" (mislabeled as "Tsukiyomi -Moon Phase- 2 RAW.avi") from Saiyaman is one of those weird ones. It's DivX 5.0 (according to ffdshow's info). In MPC6.4 (ffdshow 20030523 build AND 20041003 build), it's corrupted (plus unusually high cpu usage for a divx [near 80% vs ~30% in wmp6.4]) but in WMP6.4 (with the same ffdshow builds), it's fine. If the same file is encaps in an avisynth (directshowsource; generated using VdubMod 1.5.10), it plays without corruption in MPC6.4 (but still a bit high cpu usage). (on a slower machine, the computer was usable until it finished playing the sample clip in MPC6.4)

What could MPC6.4 be doing to the stream to make it corrupt and increased cpu usage?

rigel
15th October 2004, 20:59
Have you tried disabling some MPC-s internal filters?
For example internal "Avi Splitter"
And what audio formats do these files have?
If it is one of those for which MPC has its own decoders, then try to disable it.

MoFoQ
15th October 2004, 21:43
Interestingly enough, right after I posted, I tried disabling the AVI splitter (last time I tried, it did jack) and reloaded the file and viola, the divx corruption is gone and cpu utilization is on par with wmp6.4. I just need to test with a known problematic wmv9 source (don't have it with me at the moment).

(for some other reason, I can't get ffdshow 20041003 to work with another system of mine. Any program that can play avi's will crash if ffdshow 20041003 is installed and the avi's vid is something ffdshow can handle; even causes explorer to crash if I have shmedia.dll enabled. Of course, I have intermittent issues with any version of ffdshow on that same system....every so often explorer will crash with a "ffdshow_something_something error" when it's idling, when I'm websurfing, watching TV via SVideo input on my monitor [thus computer is idling]), when under load, when playing games, etc.)

MoFoQ
16th October 2004, 08:57
It was still getting an access violation (didn't matter what program, even AVI Codec Info would crash) with 20041003.

I went to sourceforge and grabbed the latest build (http://sourceforge.net/project/showfiles.php?group_id=53761) (20041012-sse2) and no issues. weeee....