[FFmpeg-devel] [Patch/RFC] Improved PixelLayout parsing in mxfdec.c

[Tomas Härdin]

Hi

While poking around with transcoding DPX sequences to rawvideo in MXF I
discovered that the demuxer's handling of the PixelLayout item only
parses enough to fill in bits_per_coded_sample. The attached patch
improves the code so that it also figures out pix_fmt. At the moment it
detects RGB24, RGB48LE/BE and BGR24. More formats are easily added. I
use pix_fmt to fill in codec_tag using avcodec_pix_fmt_to_codec_tag(),
since that seemed the most correct way.

The code could be shared with the muxer in order to enable rawvideo
muxing. In that case the code would probably go in mxf.c instead.

Finally, I left the old switch code intact so that YUV formats still
produce the same value for bits_per_coded_sample.

RFC part follows:

Notice that I have several definitions for PIX_FMT_RGB48BE. This is due
to some confusion on my part. The reason is that E.2.46 appears to be a
little ambiguous regarding endianness. The standard provides these two
examples:

"Example: Component 4:2:2:4
8-bit components packed into a 32-bit word, in 601 sequence: Cb Y Cr,
with alpha in 4th byte of the stored pixel
PixelLayout = {'U',8,'Y',8,'V',8,'A',8,0,0}"

and

"Example: one of the formats supported by SMPTE 268M
10-bit components filled to 32-bit word boundaries, padded in most
significant bits
PixelLayout = {'F',2,'B',10,'G',10,'R',10,0,0}"

The first example states that the output bytes come in the same order as
they are defined in PixelLayout. The second example states that the
leftmost bytes are the most significant. My interpretation of this is
that rawvideo must be stored in big-endian form unless otherwise stated
in PixelLayout (using 'R' and 'r' etc. for MSBs and LSBs). A less
ambiguous definition of the second example would therefore be:

PixelLayout = {'F',2,'B',6,'b',4,'G',4,'g',6,'R',2,'r',8,0,0}

while the little-endian form would be

PixelLayout = {'r',8,'g',6,'R',2,'b',4,'G',4,'F',2,'B',6,0,0}

That should hopefully make sense. Any thoughts?

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mxf_pix_fmt.patch
Type: text/x-patch
Size: 3764 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100603/675a8315/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100603/675a8315/attachment.pgp>