[FFmpeg-devel] [PATCH] Add non native 16bits RGB/BGR output support to libswscale

Alexis Ballier alexis.ballier
Thu Aug 13 07:53:47 CEST 2009


> by how much do these increase the object size?

~18Kb here; i'm on 64bits so thats probably an upper bound but indeed
that's a lot.

> and how much would a if() in the inner loop of the rgb565/555 formats do,
> also what are the speed effects of these 2 options

I didn't want to do this not to slow down native endian converters.
Trying it gives me ~2-4% slowdown for both native and non native
endian formats.

> also as a 3rd alternative whats the speed with a seperate bswap pass ?

I get almost no difference for the native endian version but a ~5%
slowdown (compared to the original patch) on the non native endian
one.
Now the question would be how to implement this properly, so far I've
been doing like this:

int needbswap=0;
switch(dstformat){
case nonNE: needbswap=1
case NE: do stuff
    if(needbswap) ...
    break
}


When you say bloat, you mean in terms of compiled object size or in
terms of code size? For the former only I suppose a CONFIG_SMALL
conditional for a separate bswap pass would be sane. For both, a
separate bswap pass seems the best choice here.


Alexis.



More information about the ffmpeg-devel mailing list