Inspired by some comments from Zeb Chadfield on Linkedin, I exhaustively worked on reproducing the troubles he experienced the last time he tried out OP1a MXF media in his Avid Media Composer workflow.

I can confirm: you will run into some of the troubles he outlined in certain workflows.

I’m compiling those troubles here so:

1. You can decide if they’re valid blockers to using OP1a MXFs in your workflow.
2. With the hope the right software vendors will see this and take action.

To that end, here’s an old saying on identifying real money versus fake money:

You don’t have to memorize all the different types of counterfeits out there; you only need to know how real money looks.

Building on that principle, let’s look at this file called P1810409.MOV. ¹

I transcoded it to an OP1a MXF in Media Composer, then used ffprobe to examine it.

Here are the results:

What do we learn?

There are five groups of metadata Media Composer wants from what I’ll call a fully formed OP1a MXF:

1. material_package_name & material_package_umid
2. file_package_name & file_package_umid (per stream)
3. track_name (per stream)
4. reel_name & reel_name_umid (per stream)
5. timecode

Also, the UMID’s – material_package_umid, file_package_umid, reel_name_umid – must be the same.

For testing, I transcoded OP1a MXFs or attempted to add metadata to existing OP1a MXFs using these apps:

• EditReady by Hedge
• Apple Compressor
• ffmpeg - transcoding and adding metadata
• bmxtranswrap - adding metadata only

None of these apps can write all five groups of metadata with matching UMID’s, but there is one app that can: Blackmagic Design’s DaVinci Resolve.

Before all you DaVinci Resolve fans come pouring in, let’s make one important distinction.

Fully Formed vs. Valid OP1a MXFs

If a fully formed OP1a MXF has all five groups of metadata with matching UMID’s, why can Media Composer open OP1a MXFs transcoded from EditReady and Compressor?

It seems Media Composer views OP1a MXFs with or without certain metadata to be viewed as valid OP1a MXFs.

That is, Media Composer will successfully index managed media folders and allow the user to successfully open and play back Clips attached to those OP1a MXFs.

Based on my tests and ffprobe reports, here are the criteria Media Composer uses to determine if you’re using a valid OP1a MXF file as managed media:

1. An OP1a MXF contains a material_package_umidand file_package_umid without any of these defined: material_package_name, file_package_name, and reel_name.
2. An OP1 MXF contains a material_package_umidand file_package_umid with this metadata defined: material_package_name and file_package_name.

However, if you define material_package_name, file_package_name, and reel_name, MC will fail to properly index the OP1a MXF. ^{2 3}

Why?

Once you define reel_name in your transcoding app, it seems Media Composer expects track_name to also be explicitly defined per stream.

Questions

Should I use OP1a MXFs for Editorial with Media Composer?

I still think the answer is, “Yes”.

Or at the very least, “OP1a MXFs are definitely worth testing for your workflow.”

What if I’m using DaVinci Resolve in my workflow?

Check out this section of the DaVinci Resolve Reference Manual (or DaVinci Resolve Manual.pdf):

Chapter 56 > Conforming and Relinking Clips > Importing Clips Before Importing an EDL, AAF, or XML:

• Essential Clip Metadata for Easy Conforming and Relinking
• Defining Clip Metadata When Adding Media to the Media Pool
• How Reel Names are Identified

The messaging’s a bit mixed, but if you concentrate, you’ll see:

“Assist using reel names” is recommended, but not necessary.

Again, I’m not a hater, but if you’re only using DaVinci Resolve to make dailies for Media Composer, there are far easier ways to do so with EditReady, Compressor, and Shutter Encoder.

What could Avid Technology do?

If Media Composer’s Universal Media Engine was built for native OP1a MXF support, and “you can access OP1a originals directly without having to transcode to OP-Atom MXFs as media to get superior performance”, then Avid Technology could:

• Make Media Composer more forgiving when using valid (but not fully formed) OP1a MXFs as managed media.
• Make Media Composer a bit smarter about detecting the number of tracks in an OP1a MXF, then display the correct number of Tracks in a Bin.

Currently, when track_name metadata is missing from an OP1a MXF, Media Composer will display an error:

Exception: CM_LABEL_NOT_UNIQUE, tt:2, lnum:768

And if the user selects Yes, then the Bin displays an inaccurate number of tracks.

Plus, you can’t open the Clip.

What could transcoding app vendors do?

They can make sure their OP1a MXF writers write all five groups of metadata:

1. material_package_name & material_package_umid
2. file_package_name & file_package_umid (per stream)
3. track_name (per stream)
4. reel_name & reel_name_umid (per stream)
5. timecode

With matching UMID’s for material_package_umid, file_package_umid, and reel_name_umid.

I have a ticket open with the ffmpeg dev team – #11226 Add Track Names to OP1a MXF files – but I’m not sure how much traction it will get. It was already tagged as an Enhancement.

There’s nothing wrong with using OP-Atom MXFs, but it seems OP1a MXFs were meant to be the future… back in 2019.

Imagine being able to easily gather your project media with or without MDV and then use an OpenTimelineIO export to continue editing or finishing in the app of your choice.

In the much nearer future, it’s looking more and more like Media Composer | Enterprise’s High-Resolution Only/Proxy Preferred/High-Resolution Preferred feature will be added to other Media Composer tiers, significantly reducing the pain of a relink or conform phase.

OP1a MXFs – another step toward working how we want and where we want, with the least amount of friction possible.

ShareOpenly