Hi, 2014-08-14 11:48 GMT+02:00 Christophe Gisquet <christophe.gisq...@gmail.com>: > Hi, > > 2014-08-14 5:01 GMT+02:00 Michael Niedermayer <michae...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel