[FFmpeg-devel] WORDS_BIGENDIAN used in installed header avutil.h

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Thu, Jan 29, 2009 at 02:36:53PM -0800, Baptiste Coudurier wrote:
> [...]
>>>> considering both values since the
>>>> goal is to deprecate all _1 (horrible names)
>>> You are free to suggest better names for the _1 cases, we can surely
>>> rename them in the next major bump
>> The best names are RGBA8888, BGRA8888, ARGB8888, ABGR8888, IMHO.
>> Now RGBA, BGRA, ARGB, ABGR are ok too.
>>
>> And this is what should be as external API, there is _no_ sense if
>> hacking pixfmt externally.
>>
>> If libswscale wants to optimize routines based on its internal
>> implementation (using uint64_t or uint32_t) to deal with data, it's
>> _its_ problem, not users which should see what is _obvious_.
> 
> i dont mind if we move the byte based RGBA, ... into the enum and
> move the RGB32 stuff to the #defines with the next major bump
> (it would break ABI not API)
> assuming someone posts a patch ...
> 
> iam not in favor of droping the native 32bit word formats nor do i agree
> that this is just sws problem, it really is not.
> a grep in mplayer confirms this also, the 32bit word formats are used
> the byte based formats are not.

Well, mplayer is one thing, I know that several people already asked how
to access raw data from AVFrame.

If you don't want to use libswscale because it's GPL for example or you
want to write your own conversion routine or filter, it is definitely
more simple and obvious to have arch independant representation in
uint8_t buffer.

> also what is your oppinion on the 15/16bit formats, they dont have any
> sane byte based representation.

Im not too familiar with them, IMHO we should be consistant that is,
still considering uint8_t *buf

'R' is (buf[0] >> 3) & 0x1f and 'B' is (buf[1] >> 1) & 0x1f, if RGB5551,
'R' is (buf[0] >> 2) & 0x1f and 'B' is buf[1] & 0x1f, if RGB1555

.mov and .avi are reversed of course.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org