[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files

Baptiste Coudurier baptiste.coudurier
Tue Apr 10 12:57:00 CEST 2007


Michael Niedermayer wrote:
> Hi
> On Mon, Apr 09, 2007 at 11:51:16PM +0200, Baptiste Coudurier wrote:
> [...]
>>> now iam still not sure what exactly you are complaining about and maybe 
>>> even
>>> you yourself dont know that ;)
>>> is the names you disslike?
>> About some, yes
>>> is it the fact that some code plain doesnt work with your favorite pix_fmt?
>> Well, even if that is true, that would be up to me to support it ;)
>>> is it that native endian pix_fmt are available instead of littering the 
>>> code
>>> with #ifdef WORDS_BIGENDIAN ?
>> I might agree with that, but that is done atm is more complicated than 
>> simply avoiding define's.
>> What I don't like:
>> first:
>> #define PIX_FMT_RGBA PIX_FMT_RGB32_1
>> #define PIX_FMT_BGRA PIX_FMT_BGR32_1
>> #else
>> 4 defines for 4 pixfmt is useless. Those can be specified correctly in 
>> the code !
> no they can not the code works just with them there is ONLY ONE option
> and that is to move the #ifdef WORDS_BIGENDIAN into the code, removial
> is NOT possible

Removial IS possible. Statement is:
you got RGBA (buf[0] == R, buf[1] == G ...) in avi, you will use native
 on x86, and on ppc it will be the inverse.
you got ABGR (buf[0] == A, buf[1] == B ...) in mov, you will use native
on ppc,
and x86 it will be the inverse.
Broken design comes by the fact that the exact reverse EXISTS in other
and you just mess up pix_fmt names while you can use file storage as
for completeness sake, since you'd have to implement ALL conversions.

> please understand that the code (yuv2rgb and many applications using libav)
> is working with native endian rgb32 and it does so because it is faster
> noone will rewrite applications to be slower or more complex that is use
> bytewise IO or convert non native endian to native endian ids just to get
> rid a a single line you dont like!

It is just a matter of changing pix_fmt value where it must be changed !
Or are you just trying to say that code using broken design must not be
changed ever because it works ? If so I clearly do not agree with that

> also why dont you just remove the 4 lines and try to recompile? then start
> changeing the code and send a patch which can be tested if you are so certain
> this is a good idea ...
>> Also RGBA is clearly better that BGR32_1 !
> huh!? better in what respect, the number 3 is also better then 4
> thats no argument to remove 4 from mathematics (for i hope obvious reasons)

RGBA clearly should mean R, G, B, A stored into the FILE, like U, Y, V,
Y means, what are you trying to obfuscate here ?

Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312

More information about the ffmpeg-devel mailing list