[FFmpeg-devel] [PATCH] Add non native 16bits RGB/BGR output support to libswscale
Thu Aug 13 18:31:04 CEST 2009
On Thu, Aug 13, 2009 at 07:53:47AM +0200, Alexis Ballier wrote:
> > 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
> Now the question would be how to implement this properly, so far I've
> been doing like this:
> int needbswap=0;
> case nonNE: needbswap=1
> case NE: do stuff
> if(needbswap) ...
> When you say bloat, you mean in terms of compiled object size or in
> terms of code size?
bloated .c files rarely compile to non bloated .o files (at least after the
preprocessor) so thats included
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel