[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