[MPlayer-users] are threads working?

[Reimar Döffinger]

On Tue, Jan 21, 2014 at 06:08:10AM -0800, Grant wrote:
> >> I'm launching mplayer with -lavdopts threads=2 but how can I find out
> >> if multiple threads are actually being used?  There is no mention of
> >> them in mplayer's output, even with -v.
> >
> > Run "ps auH" (assuming mplayer is launched by the same user) and see if
> > all threads are using CPU (through there probably will be a cache thread
> > not using CPU).
> 
> There seems to always be one more thread than I have specified which
> uses most of the CPU.  For example, if I use threads=2, there are 3
> mplayer threads running with one using about 60% and the other two
> using about 25% each.  If I use threads=8, there are 9 threads with
> one using 50% and the others using about 10% each.  Is that the
> expected behavior?

Also:
There are n threads doing the video decoding.
There is one thread executing the main MPlayer code.
Specifying significantly more threads than number of CPUs doesn't
make much sense in itself, but it causes more frames to be buffered
inside FFmpeg. This helps smooth out when decoding the video sometimes
is faster and sometimes slower.
That you have one thread taking most CPU time almost certainly means
that you are doing YUV to RGB conversion in software - which is probably
why SDL is faster, since I believe its version is much more optimized
for ARM.
You should also be able to see that from the MPlayer status line, which
should indicate that it spends most time waiting for the VO.
While that step can be trivially multithreaded, any sane video playback
system leaves this to hardware, or at the very least the GPU instead of
doing it on the CPU.