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

[Jimmy Christensen]

On 2009-06-04 23:28, Vitor Sessak wrote:
> 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.

Very true, but I imagine that the most used cases would be to another 
format completely. Personally if I were to convert/resize from one image 
format to another eg. TIFF I would probably use imagemagick instead of 
ffmpeg (no offense there :) ). Also there aren't many formats out there 
which support 16-bit and all of those I have seen so far supports both 
little and big endian. The output would then naturally be the systems 
native endian.

>
>> 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).
>

I plan on making the log/lin conversion through a videofilter, so it's 
also possible to support LUTs. I think this will probably be more used 
compared to image > image.

The decision is up to you guys. I can easily make the change.