[MPlayer-users] are threads working?

[Reimar Döffinger]

On 31.01.2014, at 16:44, Grant <emailgrant at gmail.com> 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.
> 
> 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?

It needs multithreading support to be added to libswscale.
Though NEON support would probably be a more sensible first step.
Just to be clear: that involves someone programming....

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

http://alastordmcblog.blogspot.se/2012/09/debian-on-pandaboard-graphics.html says omapfb does it and does not require any special kernel modules or binary blobs, using the same hardware features as my -vo fbdev suggestion.