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

[Jan Knutar]

On Friday 10 September 2004 15:47, Ed Wildgoose wrote:

> 20ms of audio, sync frame, check keyboard, etc, etc.  With the thread 
> approach you would likely try to decode 25 frames, then decode 20sec of 
> audio, and then you have only a small number of threads doing actions 
> like frame display that need regular context switching (yes, I know that 
> this potentially purges the cache, and the fact that you need any 
> context switching is what is the issue).  Think pipeline processing, 
> rather than spinning a fast loop and context changing on a very regular 
> basis.

As far as I've understood, a batch-like processing approach causes the
Linux scheduler to consider the process non-interactive, and thus getting
CPU at the right time gets more difficult. I don't know how that all works
with threads, if it just considers some threads interactive or not, or if it
applies to the entire process.

> Anyway, I would like to retract any support from the threads issue, it 
> was clearly a mistake to mention it.  I will certainly NOT be investing 
> a load of my time pushing this uphill, but I still think it's an 
> interesting architecture to debate, regardless of whether it's not the 
> best one or not

MPlayerXP is a multithreaded port of mplayer, for those interested, go
look at that ;-)