[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