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

[Baptiste Coudurier]

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.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no