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

[Jimmy Christensen]

On 2009-06-05 00:00, Jimmy Christensen wrote:
> 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.

I've now changed it to match the source image endian type, which does in 
fact make some sense. One can argue that due to this, having the files 
endian type match the systems will always be the fastest.

Also added support for RGBA although discards the alpha channel for all 
bit depths except 8-bit.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpegDPX-rev21.diff
Type: text/x-patch
Size: 10273 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090608/dc67777b/attachment.bin>