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

[Michael Niedermayer]

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
> 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

yes


> 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.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090813/d53f7a74/attachment.pgp>