[MPlayer-users] are threads working?

[Grant]

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

omapfb always segfaults for me.  It sounds like your fbdev suggestion
would be pretty hard to get working?

- Grant