[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