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

[Ed Wildgoose]

>Suppose a frame is displayed after being passed throught 10 different
>threads (audio/video effects...), we can estimate one context switch
>per frame per thread, so at 25fps it is 250 cs/s.
>(A clever assignment of priorities and a good kernel will avoid
>switching from thread to thread continuously)
>Assuming a 1000 cycles penalty for one context switch, we are "wasting"
>250000 cycles, which is 0.01% at 2GHz.
>
>My idea is that, yes, there is a cost, but it is smaller than what
>we think. 250cs/s or even 1000cs/s are easily manageable. My
>timer interrupt ticks at 1000Hz even when the system is idle.
>At 1000Hz, there are still one million cycles between ticks.
>  
>

In fairness to Zoltan, going multi-threaded can add an aweful lot of 
complexity to the app if it's not done right.  For example in Mythtv 
there is no top down document and I have given up completely trying to 
chase some issues altogether. 

However, your point is also valid (IMHO), in that there are far less 
context switches required than some people seem to think.  Remember that 
you only need fairly fine context switches for the hard scheduled stuff, 
eg frame display, or if you want to process keyboard input frequently.  
For the rest of the time, bar locking problems you just have a free 
running thread that can run for 500ms processing the next N video 
frames, or decoding the next 20s of audio.

I think some of the confusion arises because right now the loop spins 
very fast and does a tiny amount each time, eg decode one frame, decode 
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.

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

I think my efforts are better spent better understanding the main loop 
with a view to tidying that up so we can see the wood from the trees...


>It could look much too complicated but we have almost all the pieces:
>input drivers, demuxers, decoders, filters, output drivers, rescalers...
>we only miss compositing (not a great task) and a good infrastructure
>to put pieces together (that would include negotiation of YUV2/RGB
>and auto placing of rescalers or converters) and handle the
>syncronization.
>  
>

Yeah, then we could write a DVD player program using mplayer!!  ;-)

(I really miss DVD menu support...)

Ed W