DNx OpAtom MXF

If we’re trying to create DNx OpAtom MXF (with separate MXF files for video and audio) the Avid SDK only produces an Op1a file (with video and audio combined in one MXF file) so we process it using the open source bmxtranswrap command line tool to split the combined file into separate MXF files.

We also read the randomly generated UMIDs of the exported MXF files and populate the AvidProxy fields on the original clip, so if we later export the original clip to Avid via AAF then Media Composer should correctly link to the OpAtom MXF files (assuming we exported them to the “Avid MediaFiles” folder) as Avid does all its linking based on UMIDs.

The code flow in SegmentExporter.exportOpAtom() is a little convoluted:

Although it’s called from SegmentExporter.doExport(), SegmentExporter.exportOpAtom() calls SpecialTranscoder.exportDirect() to do the export to an intermediate Op1a file. In turn, SpecialTranscoder.exportDirect() checks to see if it can directly export the clip to DNx Op1a (if it’s a simple file) or if it needs to do a second intermediate step (eg. if the source clip is a sequence or image sequence or has burnt in text or we need to manipulate the audio channel layout), in which case it calls back to SegmentExporter.doExport() to invoke all the segment-based transcode logic above to create an intermediate M-JPEG MOV file using SpecialTranscoder.getIntermediateSettings(), and then exports that intermediate file to Op1a MXF.

So, in a few rare circumstances it’s possible for the SegmentExporter to be invoked re- entrantly!