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

[Attila Kinali]

On Wed, Aug 25, 2004 at 01:18:10PM +0100, Ed Wildgoose wrote:
> What would people say to adding multithreaded coding to mplayer?  The 
> idea would be to run the audio decoder and video decoder in their own 
> seperate threads. 

A few reasons already given at another thread.

> The video thread basically just needs to block periodically until it 
> gets synchronised with some external sync code to display the next 
> frame.  This can happen from a combination of the main event loop, audio 
> thread and any external sources (RTC, etc).

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.

> Do we support any architectures that make writing threads particularly 
> troublesome?  Win32 for example?

Very troublesome. Allthough most unix have some kind of posix threads,
all of them have little differences in how they follow the standard.
This can be workarounded for most apps which dont have hard restrictions
on synchronisation of the threads and proper timing at the same time,
with apps like MPlayer it might get very difficult.
Not to talk about win which is a totaly different story.

			Attila Kinali