[Ffmpeg-devel] Re: pixel format names in swscale

[Michael Niedermayer]

Hi

On Mon, Mar 27, 2006 at 11:33:03AM +0200, Michel Bardiaux wrote:
> Michael Niedermayer wrote:
> >Hi
> >
> >On Mon, Mar 27, 2006 at 10:42:04AM +0200, Michel Bardiaux wrote:
> >
> >>Michael Niedermayer wrote:
> >>
> >>>Hi
> >>>
> >>>On Fri, Mar 24, 2006 at 12:28:29PM +0100, Michel Bardiaux wrote:
> >>>
> >>
> >>[snip]
> >>
> >>
> >>>>Just a suggestion on the side: would this not be a good time to change
> >>>>the definition of RGBA32 from endian-dependent to strict byte order,
> >>>
> >>>
> >>>no
> >>
> >>Why?
> >
> >
> >optimized code accesses RGBA32 with 32bit or larger types so having 
> >pix_fmts
> >which are based on native types is the logic choice
> >
> >[...]
> 
> The problem is that code optimized *inside* lavc may no longer be 
> optimal in the overall application. I have g-profiles showing that 
> converting from the endian-dependent RGBA32 to the byte order needed for 
> the X server uses a significant amount of CPU time, so that overall the 
> optimal code is to convert directly to what one needs, and this is 
> currently impossible.
> 
> Do you confirm that the use of an endian-dependent definition of RGBA32 
> is *only* a matter of optimizing the colorspace conversion code, or does 
> that have implications elesewhere? If you confirm, then a patch that 
> would introduce the 4 endian-independent 32-bits R,G,B,A variants 
> *without compromising speed* should be acceptable?

read the thread again

1. the "endian dependant" RGB32 formats will stay this decission is final
2. you can send a patch which adds the 3 missing "endian depenant" RGB32
   formats
3. you can send a patch which #defines 4 endian independant formats
   which depending on cpu endianness get defined to the correct endian
   dependant format


[...]
-- 
Michael