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

[Michael Niedermayer]

Hi

On Tue, Apr 10, 2007 at 03:11:39PM +0200, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> >>> [...]
> >>> 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
> 
> pix_fmt. See patch attached.
> 
> >>> 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
> 
> RGBA is a define ! How can it be what is stored in the file ?

RTFS, it IS what is bytewise stored in the file

[...]

your patch removes NEEDED and USED features
breaks API
breaks ABI
breaks compilation
breaks the clean design where RGB/BGR15/16/32 is specified in native endian and
the corresponding name without <num> is native endian independant
the naming is not even more consistent 

if you want to propose changes to the API then you MUST fully understand the
existing API first and provide some justifications for the change, also
such changes must be behind the proper #ifdef LIABV_VERSION to delay
ABI/API breakage until the next version increase

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- 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/f868bbc2/attachment.pgp>