[MPlayer-users] are threads working?

Grant emailgrant at gmail.com
Fri Jan 31 16:44:23 CET 2014

>> >> 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.

Yes it does indicate that.

> 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.

How can I multithread that?

The Pandaboard does have working XV output if I use the pvr-omap4
drivers but they only work on kernel 3.4.

- Grant

More information about the MPlayer-users mailing list