[MPlayer-users] Re: mplayer + heavy io: why ionice doesn't help?

[Denis Vlasenko]

On Tuesday 22 August 2006 19:38, Xavier Bestel wrote:
> Le mardi 22 août 2006 à 18:26 +0200, Denis Vlasenko a écrit :
> 
> > > I think the problem is also due to mplayer's faulty design.  It should
> > > be multithreaded and use RT threads for the time sensitive work, like
> > > all professional AV applications and many other consumer players do.
> > 
> > RT - yes, multithreaded - unsure. Witness how squid manages to
> > serve hundreds of simultaneous streams using just a single process.
> > 
> > Multithreading seems cool on the first glance and it is easier to code
> > than clever O_NONBLOCK/select/poll/etc stuff. However,
> > on single-CPU boxes, which are still a majority, multithreading
> > just incurs context switching penalty. It cannot magically
> > make CPU do more work in a unit of time.
> 
> The problem with mplayer is latency more than throughput, and for that
> multithreading is king. Squid can get away with a 100ms delay between
> two packets, mplayer can't.

This assumes that it is not possible to write single-threaded
code so that it decodes the audio/video streams to a buffer
a few frames deep, and plays/renders already prepared data
from that buffer just in time. Yes, it is a bit non-trivial,
but you get less context switches as a bonus.

I am not an expert, but I think squid does not have "100ms delay"s,
it uses O_NONBLOCK extensively.
--
vda