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

[Kostya]

On Fri, May 29, 2009 at 08:43:00AM +0200, Jimmy Christensen wrote:
> On 2009-05-28 12:52, Michael Niedermayer wrote:
>> On Thu, May 28, 2009 at 07:19:48AM +0200, Jimmy Christensen wrote:
>>> On 2009-05-27 21:18, Vitor Sessak wrote:
>>>> [...]
>>>>
>>>> I suggest you remove completely the RGB16Field struct and just use
>>>>
>>>>> + for (x = 0; x<  s->height; x++) {
>>>>> + uint16_t *dst = ptr;
>>>>
>>>> instead of
>>>>
>>>>> + for (x = 0; x<  s->height; x++) {
>>>>> + uint8_t *dst = ptr;
>>>>
>>>> as a secondary benefit, the code should be simpler (no memcpy()).
>>>>
>>>> -Vitor
>>>
>>> Thank you. Didn't know about this.
>>>
>>> Solved my problem and the code should be alot better and cleaner. Although
>>> there is 1 warning about changing format from uint8_t to uint16_t. It seems
>>> that avctx->priv_data->picture->data is always uint8_t so either way it
>>> seems I'll get a warning no matter what. Also since
>>> avctx->priv_data->picture->linesize is based on a uint8_t I'll need it as
>>> uint8_t anyway.
>>>
>>
>>> I also forced the avctx->pix_fmt to PIX_FMT_RGB48BE to avoid any portable
>>> issues and also since this is the only format which is supported by any
>>> encoders(pnm).
>>
>> the output should be PIX_FMT_RGB48
>
> The thing is that PIX_FMT_RGB48 becomes PIX_FMT_RGB48BE on big endian  
> systems and PIX_FMT_RGB48LE on little endian systems. Tried to avoid  
> having a if else thing, but probably makes more sense to have the  
> picture frame in the systems native format. Changed it in this patch.  
> The problem now is that without the RGB48 support patch for swscale. The  
> dpx decoder can only be used on big endian systems, since there are no  
> PIX_FMT_RGB48LE supporting encoders. The pnm encoder specifically  
> chooses PIX_FMT_RGB48BE.

Why not help by adding RGB48BE<->RGB48LE<->anything else conversion code
to swscale? Then any encoder will be able to use decoded DPX source.