Copy link to clipboard
Copied
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
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.
Copy link to clipboard
Copied
Hi,
it is possible to determine the wrapper (i.e. file extension) and video codec of an item using
app.project.rootItem.children
-> 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).
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
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...
Copy link to clipboard
Copied
Hi,
Thank you e.d for your valuable information
We will explore this, and get back soon.
Thanks and Regards,
Anoop NR
Copy link to clipboard
Copied
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...
Copy link to clipboard
Copied
How/why would you handle OP Atom files differently?
Copy link to clipboard
Copied
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
Copy link to clipboard
Copied
Talk me through the "AAF Handling" workflow(s)...?
Copy link to clipboard
Copied
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.
Copy link to clipboard
Copied
You're not alone in thinking such functionality should be within PPro, though the providers of those third-party tools might not agree.
Copy link to clipboard
Copied
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.