[FFmpeg-devel] [PATCH] Add DPX decoder rev-20

[Vitor Sessak]

Jimmy Christensen wrote:
> On 2009-06-04 18:33, Vitor Sessak wrote:
>> Jimmy Christensen wrote:
>> [....]
>> you can replace
>>
>>> + case 16:
>>> + for (x = 0; x < avctx->height; x++) {
>>> + uint16_t *dst = ptr;
>>> + for (y = 0; y < avctx->width; y++) {
>>> + *dst++ = read16(&buf, endian);
>>> + *dst++ = read16(&buf, endian);
>>> + *dst++ = read16(&buf, endian);
>>> + }
>>> + ptr += stride;
>>> + }
>>> + break;
>>
>> by just
>>
>> case 16:
>> for (x = 0; x < avctx->height; x++) {
>> memcpy(ptr, buf, 6*avctx->width);
>> ptr += stride;
>> }
>> break;
>>
> 
> Hmm.. I'm not so sure it's a good idea. First of all I think the idea of 
> the pix_fmt is to have it as the systems native endian. 

Not really. The general idea is that the decoder should not do pix fmt 
conversion (this is swscaler task). Of course, there are exceptions to 
avoid polluting the API with too many sorts of weird formats (like 10 
bit RGB, for example). If the decoder can output to two different 
formats (as in the 10-bit case), it should use the one that it decodes 
to faster (what in general favors native endianness).

> Also in my test 
> case it didn't make any difference performance wise, probably bacause 
> the rgb48 > yuv has to do endian conversion anyway. 

Imagine in a LE box do a conversion where the input is DPX 16BE and the 
encoder wants RGB16BE (PCX?, TIFF?, some not yet existing stuff?). Your 
code will convert 16BE to 16LE and the scaler back to 16BE.

> This will also be 
> the case when/if I have to do log/lin conversion.

For log/lin conversion, I agree that native endianness is better (faster).

-Vitor