How to identify the MXF-OP Atom files in a Premiere project

[emam-dev]

Hi All,

Is there any way we can go through a large project and find the MXF-OP Atom files in that project?

Is there any way to get the codec/wrapper details of the files in a Premiere project?

We are trying to achieve this using our HTML5-CEP based panel.

Thanks and Regards,

Anoop NR

[e_d_]

Hi,

it is possible to determine the wrapper (i.e. file extension) and video codec of an item using

app.project.rootItem.children.getProjectMetadata()

-> for example, DNxHD is AVdn, XDCAM-HD422 is xd5c (sounds familiar? ), but it won't tell you if the clipitem really is a OP-1a or OP-Atom container. Premiere figures this out "under the hood", presumably by checking the file's internal GUIDs (which requires them to have been properly generated, otherwise OP-Atom files won't import as a single clip anyway).

[emam-dev]

Hi,

Thank you e.d. for that info.

But as you said, we can only get the codec- AVdn, and its common for OP1a and OP Atom.

We cannot depend on that one.

Thanks and Regards,

Anoop NR

[e_d_]

Hi Anoop,

I know, Premiere's codec info is not sufficient for this application...What would be useful and feasible is to do a binary read of the MXF header and have the relevant byte(s) tell you what kind of essence(s) the file is containing.

(One hour of research later...)

As far as I understand it, if one looks at offset 16h of an MXF container, the byte value provided there gives the exact offset (x+1) of the OP descriptors. So if it says "83", the offset for the identifier is 84h (found this in XDCAM OP-1a, in OP-Atom generated by MC the offset is 89h).

BTW, the "magic number" for OP-1a is 06 0E 2B 34 04 01 01 01 0D 01 02 01 01 01 09 00,

whereas OP-Atom is 06 0E 2B 34 04 01 01 02 0D 01 02 01 10 02 00 00 . You might as well just regex-match for this in the first 300 bytes of the file...

[emam-dev]

Hi,

Thank you e.d for your valuable information

We will explore this, and get back soon.

Thanks and Regards,

Anoop NR

[e_d_]

Sorry, my bad I got the offsets wrong, or say I assumed the parser would give me hex, but they were dec.

Hence the offsets are 10h (16d), and 54h (84d), and respectively 59h (89d).

Which ruins my beautiful theory of straightforward offsetting, unless one interprets the hex value at 10h as decimal, but that hack might lead to trouble downstream...

[Bruce Bullis]

How/why would you handle OP Atom files differently?

[emam-dev]

Hi Bruce,

We are trying to make a workflow to handle the AAF files from Avid and create a single highres file for edit and archive. We thought the best way to do this was to wrap the OP Atom to a DNXHD OP 1A and archive that. Please correct us if there is better way to do this.

We want to automate this process from our panel

-Wrap the OP Atom files into OP 1A and move to Archive

-Save all the other files in the in its native format to Archive

Thanks and Regards,

Anoop NR

[Bruce Bullis]

Talk me through the "AAF Handling" workflow(s)...?

[e_d_]

Hi Anoop,

but that's not really the case. In order to have proper wrapping to OP-1a, all streams contained therein need to be of the same length. Which means you have to do a full consolidation on every track of the AAF, which as a result means you're wasting disk space on black video and (mostly) audio silence (which again might not a big deal, depending on the sequence duration and the audio track count). I wonder why to make the extra effort when you can just as easily export a consolidated OP-1a file from MediaComposer. From an archiving point of view this doesn't make sense, because I would always want to preserve a non-baked version of the edit as well as the rendered result (with audio stems).

Bruce Bullis​: In my view the issue is PPro represents OP-Atom essences as ClipItems which only hold a reference to the video essence, but not the audio essences of the same material package, so a reverse lookup requires jumping through various hoops on a file system or metadata level which either requires binary processing or 3rd party tools.

[Bruce Bullis]

You're not alone in thinking such functionality should be within PPro, though the providers of those third-party tools might not agree.

[e_d_ · Accepted solution]

I don't expect it. I'm just curious (as with many other things) how it's possible that one has made the effort to implement (mostly) proper OP-Atom reading and then just stopped. One could call it an incomplete feature. I see your reasoning behind it, but from a user perspective it's a PITA, breaking workflows in many places.