[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files
Tue Apr 10 13:55:27 CEST 2007
On Tue, Apr 10, 2007 at 12:57:00PM +0200, Baptiste Coudurier wrote:
> 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 == 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
> 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.
you either dont understand what you are talking about or i dont understand
> > 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
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
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel