[Ffmpeg-devel] [PATCH/RFC] 1-7 and 9-15 bits per pixel PGM files
Baptiste Coudurier
baptiste.coudurier
Mon Apr 9 23:51:16 CEST 2007
Hi
Michael Niedermayer a ?crit :
> Hi
>
> On Mon, Apr 09, 2007 at 07:32:13PM +0200, Baptiste Coudurier wrote:
>> Hi
>>
>> Michael Niedermayer a ?crit :
>>> [...]
>>>
>>>> + }
>>>> + } else if (avctx->pix_fmt == PIX_FMT_GRAY16BE && s->bpp < 16) {
>>>> + unsigned int j, val;
>>>> + for(ptr = p->data[0], i = 0; i < avctx->height; i++, ptr +=
>>>> linesize) {
>>>> + for(j = 0; j < avctx->width; j++) {
>>>> + val = AV_RB16(&ptr[j<<1]);
>>>> + val = val<<(16-s->bpp) | val>>(s->bpp-(16-s->bpp));
>>>> + AV_WB16(&ptr[j<<1], val);
>>> 16bit formats should be in native endian internally (for obvious reasons)
>> Is it speed reason ?
>>
>> pix_fmt IS external IMHO.
>>
>> This "native" endian pix_fmt exporting is IMHO broken, and history prove
>> that it is useless with RGB32 variants, since AVI and MOV used
>> respectivly inversed order. Im not that wrong extrapolating that to
>> GRAY16/ME/LE/BE, Im sure I can find exact same problem in tiff/targa/dpx.
>>
>> Now in swscale you got pix_fmt only supported on one arch.
>> PIX_FMT_RGB32_1 used by MOV, while clear name is obvious:
>> PIX_FMT_RGBA8888 (not sure about right order for rgba else abgr, didnt
>> double check specs), 32 might be used if it appears obvious that each
>> comp will have 8 bits.
>>
>> Correct design is to name it according to what endianness is stored INTO
>> the file, and implement routines that deals with it, assigning correct
>> function pointers at init, if "native" endianness can be used.
>>
>> Since Im being ignored on this issue, just my 2 cents.
>
> you are being ignored as what you say makes no sense
> formats ARE named in both native endian and stored variants with #ifdefs
> and #defines setting one to the other depening on host endianness
> so you can use enirely host endian independant names if you wish ...
Well I agree that I may be confused myself ;)
> the namimg also is fairly consistent and you would likely agree if you
> tried to name all using a different scheme but as you look at just 1 out
> of 20 pix formats it surely looks confusing, try to name rgb555 & rgb565
> based on what is bytewise stored for example ...
Yes, mainly because those 2 (RGB32 and RGB656) are the only ones which I
have issues with.
> 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 !
Also RGBA is clearly better that BGR32_1 !
1 define for 2 pix_fmt is useful, I agree:
#define PIX_FMT_GRAY16 for LE/BE
second:
Exporting NATIVE pix_fmt, if we solve RGB32 issue, only RGB555/565 will
be left, and it will be the same issue as RGB32 since mov uses 555 on 16
bits. About the naming, well I need to think, but I'll find something
sooner or later, I never give up ;)
[...]
--
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
More information about the ffmpeg-devel
mailing list