RMVB playback in MPC

[datascab]

Hi,

I have a file which underplay back in realone uses about 30-40% cpu

Under MPC latest it uses nearly double that.

If I change between realmedia and directshow output I see a slight difference in usage (DS is about 10%) higher.

Another thing I noticed is a problem with either the splitter or directshow renderer.

I have resized via display output size the rmvb in a hex editor.

They playback ok in realone.

They playback ok in mpc via realmedia renderer

If I use directshow the player crashes.

Any ideas please?

Thanks

Data

[qwerpoi]

Out of curiosity, do you have ffdshow installed? If you do and it's set to decode raw video, it will slow down rmvb playback a lot (at least it did for me, 1.1 GHz athlon).

[datascab]

AFAIK, realmedia isnt handled by ffdshow?

data

[qwerpoi]

Yeah, but if you are using real media directshow filters and ffdshow is set to decode raw video, it will add itself to the filterchain (in addition to the directshow filters). This is a good way to use ffdshow filtering for realmedia or dvds, but it's a pretty big hit on the cpu usage. To see if ffdshow is being added to the filterchain in mpc, just right-click on the video as it's playing, and you can see what filters are being used to decode the file.

[datascab]

Hi mate...

Yeah I see what you are saying now.. i enabled it and it nearly killed it... lol.

When i play rmvb in realplater... what renderer does it use and can I make mpc use that as well?

Data

[qwerpoi]

Well, theoretically, if you configure mpc to use realmedia instead of directshow to decode rmvb files, you should be using the same decoder as the realone player. One thing to doublecheck is to make sure that the built-in realmedia splitter is disabled, you can disable any built-in filter in one of the options screens. As a quick check, ffdshow set to raw video will NOT enter the filterchain if you are using the realmedia decoder. If you still have problems, you may want to consider reinstalling realone, or possibly getting a newer version of mpc and trying directshow again (the early versions of the directshow filters were slower).

[gabest]

I have resized via display output size the rmvb in a hex editor.This might be the cause of the increased cpu usage. Sometimes the filter itself has to resize the image to the correct aspect ratio: (1) if the next filter in the chain (old renderer, transform filters like) does not accept the VIDEOINFOHEADER2 format stucture with the ar width/height fields, or (2) if the rm file has rv10/rv20/rv30 compression type then and the splitter cannot figure out the display size before connecting up with the renderer.