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

Baptiste Coudurier baptiste.coudurier
Tue Apr 10 18:33:31 CEST 2007

Michael Niedermayer wrote:
> 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

using pkt->data and rawvideo, in MY philosophy, pkt->data[0] SHALL be R
if pix_fmt is RGBA32, period. No matter if Im on big or little endian arch.

> [...]
> your patch removes NEEDED and USED features

no kidding ?

> breaks API

increase major

> breaks ABI

increase major

> breaks compilation

no kidding ?

> 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 

s/clean/broken/g, I could extend the broken philosophy to palette
handling in swscale.

> 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

no kidding ?
Let's stop the discussion, it's going nowhere.

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