[MPlayer-dev-eng] Adding threaded functionality to mplayer

[Ed Wildgoose]

>Yes, teh copy operation from RAM to the video card is actualy what is
>limiting everyting. Just do a quick calculation:
>
>320*240 pixels * 3 bytes/pixel * 30 frames per second = 6'912'000 bytes/s
>(CIF RGB)
>640*480 pixels * 2 byte/pixe * 30 frames per second = 18'432'000 bytes/s
>
>Now, the BW you have is anything between 15MB/s to 100MB/s, ie
>it uses 6% to 120% of your time to just copy data (with the above
>numbers). And at this time, the CPU is mostly blocked as it cannot
>access RAM.
>
>Note: the 100MB/s is an estimation on my side, i dont have numbers
>for todays super fast blah blub systems. Is there someone out there
>who can provide some _real_world_ data on how much BW is available
>from RAM to graphics memory with current state of the art PC hardware ?
>  
>

Most people have AGP, but someone told me that this is an asynchronous 
interface...?  Faster to copy in than out...?  Anyway, PCI-X is on the 
horizon, and this promises to let you do really silly things like use 
your graphics card as a general purpose DSP processor!  This should be 
really funky, and the bandwidth will be awesome.  Boards are already 
available from Asus and others.


Cutting back to the original point though about threading mplayer.  
Adding threads is not really about performance, and whoever said that 
synchronisation became harder was missing the point.  Basically all I 
was suggesting is that you have one thread displaying video, and one 
running the audio.  Basically at a high level the video thread prepares 
a frame and then blocks until the audio thread signals that the video 
frame is due to be displayed, and effectively yields to the video 
thread.  Video displays a frame and then blocks again until the audio 
thread tellis it that it's time to display again.

In the same way you can have a keyboard loop sending instructions to the 
other threads about what to play.

It's quite a simple design compared with the event loop that we have at 
the moment, effectively you just split main() into a number of chunks 
and get them all to run in their own loops with appropriate 
synchronisation back to the main thread for master control.  In practice 
of course you need to be careful not to have a whole bunch of problems 
caused by threading, but the top down design becomes very simple.

Anyway, I'm not going to bang on about this too much.  Splitting up 
main() will go a long way to making this practical, and I will have a 
bash when I get some time.  After that it will be pretty much a case of 
showing a patch to the new broken up main that runs small chunks of it 
in it's own thread.  We can argue about the merits much better when 
there is some code to look at, but I guess I am unlikely to go down that 
route anyway if there is resistance!

All the best

Ed W