In the last few days I have been playing with raw2bmx to create Sony XDCAM HD (RDD9) and IMX50 D10 files. I tested the results with some validator tools and based on that, a few issues came up, and I don't know if these are real issues, or only the validator tools are faulty, or both :)
1) Some tools expect the static local tags to be also part of the MXF Primer pack, but raw2bmx does not put some tags there, (e.g. 0x3f05 (Edit unit lenght in the index table)). Is this intentional? Or this small issue usually does not cause any problems, so it was never implemented?
2) Is there a reason why the Locked flag is not set in the audio descriptor of the D10 mxf files? I checked IMX50 D10 files created with other tools, and the Locked flag is always set there.
3) ImageAlignmentOffset and ReversedByteOrder in the CDCI descriptor is not set in simple RDD9 profile, only if AS10 flavour is selected as well. Files I checked from various sources always have these, and some validators also require these fields, so is it intentional that raw2bmx does not set these for every RDD9 file?
4) It is not clear to me from the MXF specs if the Constant B frames flag should be set or not if the number of consecutive B frames is constant except in the end of the last GOP. raw2bmx certainly ignores that if the video finishes with only a single B frame (in decoding order), but I don't know if this is a bug or not. Some validator tools work the same way. Any thoughts on this?
Thanks,
Marton
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) The MXF Primer Pack only covers the local tags in the MXF Header Metadata, i.e. not Index Tables. Quoting the ST377-2011 spec.: "The scope of the Local Tags in the Primer Pack shall be restricted to the Header Metadata inside the Partition that contains the Primer Pack. Index Table parsers shall not use the Primer Pack to decode Local Tags within the Index Tables. The Primer Pack shall not cover Local Sets within Essence Containers."
2) I guess for D-10 it should be set to true by default given that the ST 386-2004 spec. suggests that's what it should be. I'll fix that. For now you can set locked to true using the "--locked true" commandline option before the audio essence input.
3) Those properties are not relevant or deprecated and that's why raw2bmx doesn't set them. MXF validators and readers should not care and ignore them. However, RDD-9 unfortunately does say in Table B.1 that those (optional with explicit default value) properties are required and so I might as well set them for non-AS10 RDD-9 cases as well to keep the validators happy.
4) It's not clear to me either. The way i viewed these properties is from the perspective of an encoder producing the MXF wrapped essence. The encoder is configured to produce constant B frames (and possibly identical GOPs etc.) and so you would assume the encoder sets the property to true at the start. If the input essence does not allow the last GOP to have the same constant B frames then I would think that the property doesn't need to change to false. It also depends on how decoders use this information and whether they would break if the assumption of constant B frames is broken in the last GOP. I would guess (I'm not a codec expert) that they would be fine with that.
Philip
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the last few days I have been playing with raw2bmx to create Sony XDCAM HD (RDD9) and IMX50 D10 files. I tested the results with some validator tools and based on that, a few issues came up, and I don't know if these are real issues, or only the validator tools are faulty, or both :)
1) Some tools expect the static local tags to be also part of the MXF Primer pack, but raw2bmx does not put some tags there, (e.g. 0x3f05 (Edit unit lenght in the index table)). Is this intentional? Or this small issue usually does not cause any problems, so it was never implemented?
2) Is there a reason why the Locked flag is not set in the audio descriptor of the D10 mxf files? I checked IMX50 D10 files created with other tools, and the Locked flag is always set there.
3) ImageAlignmentOffset and ReversedByteOrder in the CDCI descriptor is not set in simple RDD9 profile, only if AS10 flavour is selected as well. Files I checked from various sources always have these, and some validators also require these fields, so is it intentional that raw2bmx does not set these for every RDD9 file?
4) It is not clear to me from the MXF specs if the Constant B frames flag should be set or not if the number of consecutive B frames is constant except in the end of the last GOP. raw2bmx certainly ignores that if the video finishes with only a single B frame (in decoding order), but I don't know if this is a bug or not. Some validator tools work the same way. Any thoughts on this?
Thanks,
Marton
1) The MXF Primer Pack only covers the local tags in the MXF Header Metadata, i.e. not Index Tables. Quoting the ST377-2011 spec.: "The scope of the Local Tags in the Primer Pack shall be restricted to the Header Metadata inside the Partition that contains the Primer Pack. Index Table parsers shall not use the Primer Pack to decode Local Tags within the Index Tables. The Primer Pack shall not cover Local Sets within Essence Containers."
2) I guess for D-10 it should be set to true by default given that the ST 386-2004 spec. suggests that's what it should be. I'll fix that. For now you can set locked to true using the "--locked true" commandline option before the audio essence input.
3) Those properties are not relevant or deprecated and that's why raw2bmx doesn't set them. MXF validators and readers should not care and ignore them. However, RDD-9 unfortunately does say in Table B.1 that those (optional with explicit default value) properties are required and so I might as well set them for non-AS10 RDD-9 cases as well to keep the validators happy.
4) It's not clear to me either. The way i viewed these properties is from the perspective of an encoder producing the MXF wrapped essence. The encoder is configured to produce constant B frames (and possibly identical GOPs etc.) and so you would assume the encoder sets the property to true at the start. If the input essence does not allow the last GOP to have the same constant B frames then I would think that the property doesn't need to change to false. It also depends on how decoders use this information and whether they would break if the assumption of constant B frames is broken in the last GOP. I would guess (I'm not a codec expert) that they would be fine with that.
Philip