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

[Michael Niedermayer]

Hi

On Tue, Apr 10, 2007 at 12:57:00PM +0200, Baptiste Coudurier wrote:
> Hi
> 
> 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:
> >>
> >> #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
> >> #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
> containers,
> and you just mess up pix_fmt names while you can use file storage as
> reference,
> for completeness sake, since you'd have to implement ALL conversions.

you either dont understand what you are talking about or i dont understand
you


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

WHAT!? what design, pix_fmt, yuv2rgb, ????
what change do you propose!? you never proposed anything just random
generic unspecific flames


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

can you please stop this nonsense, you clearly dont know what you are talking
about PIX_FMT_RGBA is R,G,B,A as stored in the file

so again, not a single thing you said makes sense, please 
1. read the code
2. think about it
3. if you have any suggestions to change it then propose that clearly
   preferable with a patch
4. i gladly disscuss such a patch but i cannot "disscuss" 
   "division by zero" ideas

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you really think that XML is the answer, then you definitly missunderstood
the question -- Attila Kinali
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070410/11fc244d/attachment.pgp>