[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files
Tue Apr 10 12:57:00 CEST 2007
Michael Niedermayer wrote:
> 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
>>> 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
>>> 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:
>> #ifdef WORDS_BIGENDIAN
>> #define PIX_FMT_RGBA PIX_FMT_RGB32_1
>> #define PIX_FMT_BGRA PIX_FMT_BGR32_1
>> #define PIX_FMT_ARGB PIX_FMT_RGB32
>> #define PIX_FMT_ABGR PIX_FMT_BGR32
>> 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 == R, buf == G ...) in avi, you will use native
on x86, and on ppc it will be the inverse.
you got ABGR (buf == A, buf == B ...) in mov, you will use native
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