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

[Jiri Svoboda]

Hi,
I did some hack for MPlayer.
At first I would like to say that they are dirty and not recommended for
normal use. They will significanty rise ammount of memory needed by mplayer.
DO NOT USE THEM IF YOU HAVE ONLY ONE PROCESSOR - You will not get any profit
just the side effects.
They are not tested at all.

Ok here is first one - fbdev hack:
can be found on http://www.jirisvoboda.cz/download/vo_fbdev.c

I did this hack to get better TV output on second head of my mga using
unacellerated framebuffer, but should work with any other framebuffer
supported by original vo_fbdev.

- it is implementation of async copy to framebuffer - only copy is separated
not drawing/frame preparation
- simply use my vo_fbdev.c instead of original one and recompile (I suggest
to gointo libvo directory first and make there before doing make in root
dir)
- I hope that this hack will get some mplayer speed up - my system shows
that approximately 10-20% is redirected to second processor. But it is still
slower then mga_vid!!!

Second one - mplayer main file
can be found on http://www.jirisvoboda.cz/download/mplayer.c
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

Please if you will have some results, speed comparisons or ... let me know.

Conclusion:
First hack is usefull. Second maybe.
Better (S)MP use needs changes of mplayer design or decode library. Better
distributing load - eg. one cpu audio decode and disp. frames, second only
video decoding - this needs changes in mplayer (changing point/time of
decode video).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). Another approach is to optimize decode lib, but
this is related to devel of mplayer (requires better decode lib which are
external).


TO ARPI are You interested in such things? Should I do regular patch?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-users/attachments/20011011/f341ae0a/attachment.htm>