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

[Attila Kinali]

On Wed, Sep 01, 2004 at 02:38:16PM +0200, Jiri Svoboda wrote:
> > No, video needs to be synchronized to audio. Otherwise you'll either
> > destroy A/V sync or have to resample audio to sync to another source.
> > Believe me, the second approach isnt worth the effort.
> 
> Some time ago (actually long time in mplayer development) i´ve tried to split mplayer into two threads. And I _was_ sucesfull. Actually the code wasn´t big (I think less then 50 lines added) but it was very big hack and I think the way I did it cant be used anymore. I´ve gained some performance boost - not very big but worth of effort. Interesting think was that same performance boost i´ve gained if I splitted video decoder and frame displaying into two threads. It seem that on my machine copy from RAM to video RAM is quite slow that it occupies significant amount of time.
> All of these tests were done on my two processor machine (2x celeron 460).

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 ?


			Attila Kinali