[FFmpeg-devel] [PATCH 4/4] dpx: fix endianess for RGB 8bits

Christophe Gisquet christophe.gisquet at gmail.com
Sat Aug 16 11:39:44 CEST 2014


Hi,

2014-08-14 11:48 GMT+02:00 Christophe Gisquet <christophe.gisquet at gmail.com>:
> Hi,
>
> 2014-08-14 5:01 GMT+02:00 Michael Niedermayer <michaelni at gmx.at>:
>> On Wed, Aug 13, 2014 at 10:21:54AM +0000, Christophe Gisquet wrote:
>>>      case 50081:
>>> +        avctx->pix_fmt = AV_PIX_FMT_BGR24;
>>> +        break;
>>
>> this possibly breaks decoding of
>> checkerboard_1080p_nuke_bigendian_8bit_noalpha.dpx
>> the cross in the middle is displayed as cyan while the other samples
>> have it yellow
>
> And DLAD_8b_3c_big.dpx has the reverse :-(
>
> I don't know what additional information is missing to correctly
> decode them, nor if it's an encoder bug.
>
> Note: -1994 spec is marked as V1.0 and -2003 one as V2.0, but both
> specify the scan line boundary thing.

So I dug a bit more and tried to compare the data. In all cases, image
data starts at 0x2000.

In the following, XX is just a placeholder for alignment/readability purpose.
BE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 94 95 XX 94 95 95 95
LE RGB24: 94 95 94 XX 95 94 95 XX 94 95 94 XX 95 95 95 XX 95 94 95 94
BE RGBA:  95 94 95 00 94 95 94 00 95 94 95 00 94 95 94 00
LE RGBA:  95 95 95 00 94 95 95 00 95 94 94 00 94 95 95 00

Are those files supposed to be the same data? The RGB24 and RGBA
versions do not match. When comparing a LE and a BE version, the
pixels do not seem to match either. How come BE/LE RGBA start with the
same data for 12 bytes, but then diverge, if they are of opposite
endianness?

Am I missing something or are those files somewhat broken anyway? Case
in point, the reading code doesn't account for endianness and always
goes through av_image_copy_plane, for all 4 images.

-- 
Christophe


More information about the ffmpeg-devel mailing list