[MPlayer-users] (S)MP hack(s) for mplayer

[Kjetil Torgrim Homme]

"Jiri Svoboda" <jiri.svoboda at seznam.cz> writes:

> You can try this, but as on my system You will not get any good -
> separation of decoding audio and video to separate threads did not
> any speedup. Video decoding is so CPU intensive in comparism with
> audio, that there is no difference in speed. Maybe on Your files
> will, but on my DIVX files not.  - use similar as previous hack

Ogle uses the standalone a52dec program for decoding the audio track
in DVD.  When downmixing from DD 5.1 to stereo it uses 5% of one CPU,
while the video uses approx. 80% of the other (dual Celeron 366).  It
should be noted that a52dec currently lacks any MMX/SSE/3Dnow!
optimisation.

I suspect Ogle does this due to simple reuse of code rather than to
exploit SMP machines :-)

> You can also get speedup by decoding two frames at same time (but
> this is not possible always-depends on format Or You have huge
> buffer from keyframe to keyframe).

This is interesting -- how huge is "huge"?  You could run into
problems with the scheduler -- it might prioritise the thread working
on the next key frame sequence, rather than the current.

How about shared memory, and handing out macro blocks to the different
CPUs?  (I know too little about MPEG.)  As Arpi says, mplayer often is
memory bandwidth limited, so the design needs to keep extra
communication down to a minimum.


Kjetil T.