[MPlayer-users] Disable colospace conversion

Andy Furniss adf.lists at gmail.com
Fri Jun 28 20:53:27 CEST 2013


Carl Eugen Hoyos wrote:
> Andy Furniss <adf.lists <at> gmail.com> writes:

>> CSC is normally done by the -vo so normally hardware
>> (gpu) eg. -vo xv or gl or vdpau but may be done by
>> cpu eg -vo x11.
>
> This is at least very misleading.
> You are right that vos internally (can) do some
> colourspace conversion but - at least imo - that is
> irrelevant (since it should happen on the GPU) as
> long as we are talking about software OpenGL.
> But this conversion only takes a small number of
> colour spaces as input (often only YV12) and the
> problem is to provide YV12. Avoiding this conversion
> can mean a large performance gain, see prores with
> -vo gl_nosw vs xv or gl.

Yea, I guess I was being imprecise in implying that the vos actually do 
the conversion rather than either passing to h/w or invoking swscale or 
both I suppose if the yuv layout needs tweaking.

>> So I suppose -vo null will do what you want but some
>> of the difference in cpu usage you see may not be CSC
>> but because you are avoiding really displaying which
>> may (depending on -vo implementation details) show
>> extra cpu use when waiting to vsync with the display.
>
> I am not convinced about your reasoning but -vo null
> can definitely be used to test "playing" (decoding)
> performance without colour space conversion.
>
>> I assume -vo null will also avoid a mem copy as well.
>
> This is not generally correct, the memcopy isn't always
> needed for actual playback either (direct rendering).

Yea, I was just thinking from the PC + GPU card point of view here.

What I was trying to say was that the difference seen when measuring 
perf with -vo null (on PC + card) is likely down to avoiding copying the 
yuv across whatever bus to the GPU card rather than CSC - but it totally 
doesn't make sense now I know it's ARM not PC.



More information about the MPlayer-users mailing list