[MPlayer-users] mplayer benchmark interpretation

Reimar Döffinger Reimar.Doeffinger at gmx.de
Sat Jun 29 09:38:19 CEST 2013


On 29.06.2013, at 03:03, Carl Eugen Hoyos <cehoyos at ag.or.at> wrote:
> Umar Qureshey <umar <at> janteq.com> writes:
> 
>> I got the following on my platform:
>> -OpenGL ES 1.1 and 2.0 API
>> -EGL 1.4 API
>> -OpenVG 1.1 API
>> -OpenCL 1.1 EP API
>> 
>> I don't have OpenGL and I see that mplayer 
>> supports that but not OpenGL ES.
> 
> To the best of my knowledge, MPlayer does 
> support OpenGL ES but I don't have such 
> hardware, Reimar will hopefully comment 
> when you explain why you think it does 
> not work.

OpenGL ES 2.0 is supported, though performance can be bad for other reasons, and creating a GLES context is highly platform specific, currently only EGL+X11 and Android (partially) are supported, I suspect this is EGL+framebuffer, how to set that up is very vendor-specific so it is not implemented - though it should be simple with a bit of help from vendor documentation.

>>> Reimar will hopefully correct me but I thought that 
>>> x11 (when fed with rgb16) does not need additional 
>>> colourspace conversion, but the filtering may be 
>>> part of the "VO:" in this statistic.
>> 
>> Any way to turn off this filtering?
> 
> You wouldn't see anything without the conversion 
> from yuv420p -> rgb16 ...
> (that is part of the "filtering" chain.)
> The conversion was never optimised on arm, if 
> you know arm assembly, a patch is welcome!

That could probably provide about 8x speedup as well.
Also, you can try the -sws option to get a simpler and faster conversion method, especially in case scaling is involved.


More information about the MPlayer-users mailing list