Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Avid MXF proxy editing report

Christoffer Glans

Well-known member
Joined
Jun 11, 2007
Messages
4,993
Reaction score
36
Points
48
Age
42
Location
Stockholm, Sweden
So I did a quick test of shooting Avid MXF files both as primary codec and as proxies. I've found that there's a a few things lacking at this time that needs to be fixed.

First I noticed is that the 444 quality do not work in Avid MediaFiles as MXF media. The latest version of Avid quarantines the 444 file and it's only supported through AMA link, not native media.

When I try to edit proxy files and then export an offline I cannot export a quicktime reference or a same as source. Traditionally, because Avid doesn't have a great export tool, you export a high quality reference or same as source file to code something else in say Adobe Media Encoder. With the proxy files from the Weapon you can't do either. The reference is black with white noise audio and the same as source file can't be rendered because the quality settings reference a quailty naming that isn't what same as source is using. I've got word that Avid themselves recommended using the "HQ" and "LT" naming for the file types but Avid Media Composer software works with the "DNxHD 36", "DNxHD 120" etc. -quality naming, meaning Avid prompts to re-encode them into say "DNxHD 120" which renders out a same as source file that is incompatible or unplayable. Only option is to code it into something else like re-encoded DNxHD, not re-wrap as a same as source file which means very long coding times.

Usually, when editing in Avid you will do online and grade in another software like Resolve. When exporting an offline video file as well as an EDL list, I put the EDL through Redcine-X and export a high quality DNxHR 444 file as a test. Importing this file as well as the offline file shows that the edit doesn't match between the offline and online. This makes proxy editing with MXF files not possible if going through Redcine-X (latest version). Looking at the timecode length of the Redcine-X rendered timeline and the offline from Avid shows that an additional 7 frames has been added, there are a total of 7 edits including the ending cut of the test timeline and when re-syncing the video tracks at the second cut, the next mismatch occurs at the next cut. This means Redcine-X adds one frame at each cut.

Redcine also gives this LOG about the EDL:

EDL - only video edits supported 4
EDL - only video edits supported 5
EDL - only video edits supported 7
EDL - only video edits supported 8
EDL - only video edits supported 10
EDL - only video edits supported 11
EDL - only video edits supported 13
EDL - only video edits supported 14
EDL - only video edits supported 16
EDL - only video edits supported 17
EDL - only video edits supported 19
EDL - only video edits supported 20
EDL - only video edits supported 22
EDL - only video edits supported 23

Resolve however seems to link correctly

The most important thing in my opinion right now is to either change the naming in camera to the native naming that Avid Media Composer use. I do not know why Avid prompted Red to use these names for the different codec qualities, but either Avid Media Composer needs to work with them during exports or Red needs to change the naming in the next firmware. As of now, exporting a timeline edited with proxy media from the Weapon will create very long render times for both offlines and online through Avid. It could add hours of unnecessary coding for the post production workflow, especially when working with feature films or episodic content.
 
To continue, I've installed Avid MediaComposer v8.6 and the latest Red AMA and codec support (including according to Avid the DNxHD/HR from the Weapon). The problems still exist; 444 doesn't work in native MXF media structure and the other codecs won't work with QT ref and Same as Source outputs.

The two images shows how Weapon produce the DNxHD codecs and what Avid use as native codecs. These need to be the same, otherwise we could just work with ProRes instead, making DNxHD unnecessary.
 

Attachments

  • Ska?rmavbild 2016-07-04 kl. 15.59.51.jpg
    Ska?rmavbild 2016-07-04 kl. 15.59.51.jpg
    5.5 KB · Views: 0
  • Ska?rmavbild 2016-07-04 kl. 16.00.05.jpg
    Ska?rmavbild 2016-07-04 kl. 16.00.05.jpg
    9.7 KB · Views: 0
To continue, I've installed Avid MediaComposer v8.6 and the latest Red AMA and codec support (including according to Avid the DNxHD/HR from the Weapon). The problems still exist; 444 doesn't work in native MXF media structure and the other codecs won't work with QT ref and Same as Source outputs.

If you haven't already, I suggest you also start talking with AVID support.

The two images shows how Weapon produce the DNxHD codecs and what Avid use as native codecs. These need to be the same, otherwise we could just work with ProRes instead, making DNxHD unnecessary.

I'm not sure what we are looking at here. I know you keep mentioning that we need to use the Mbit notation for our naming, but that is JUST NAMING - it does NOT affect our encoded data. In fact, even if we changed the naming in camera to the old Mbit notation the files generated would be exactly the same. I think you are getting hung up on the naming differences and somehow missing what the real problem is.

If you can detail exactly what steps you are taking and what you are expecting vs what happens then we can work with AVID to determine what is wrong and how to fix it.

Can we please keep this discussion here and not continue it in here and in the release announcement thread? Thanks.
 
Understand that files that open in Avid are on request. But still, DNXHD files that can open in a PC without prores capability is step forward.

Sure if it´s a problem for red with the naming Avid can sort it in next release.
 
If you haven't already, I suggest you also start talking with AVID support.
I'm not sure what we are looking at here. I know you keep mentioning that we need to use the Mbit notation for our naming, but that is JUST NAMING - it does NOT affect our encoded data. In fact, even if we changed the naming in camera to the old Mbit notation the files generated would be exactly the same. I think you are getting hung up on the naming differences and somehow missing what the real problem is.

If you can detail exactly what steps you are taking and what you are expecting vs what happens then we can work with AVID to determine what is wrong and how to fix it.

Can we please keep this discussion here and not continue it in here and in the release announcement thread? Thanks.

I'm not sure I'm getting hung up on the naming more than the fact that Avid doesn't work with a simple Same as Source export. Just try it, shoot at a mid-qual MXF, load it into the media structure, edit a short timeline and export that timeline as same as source. If I'm doing this with media rendered in Redcine-X from R3D originals into MXF DNxHD 120 and then do the same, those will work with both QT ref and Same as Source export options.

The main problem here is that even though you say that the codecs are exactly the same as traditional MXF wrapped DNxHD files, they do not perform the same within Avid. DNxHD 444 does not work at all while lesser quality DNxHD MXFs load up into Avid and work for editing but do not work at export, giving the error seen in the first image. What it means is that there is a difference between the codec generated in-camera compared to media generated into the same DNxHD quality within media composer. If I do a mixdown of the timeline where I edited the in-camera generated DNxHD files -into DNxHD 120 (which should be the same quality as the in-camera files), the new codec shown has the correct codec name and can be exported as a QT ref and Same as Source fine.

So, this isn't about naming, it's about those file not working as they should. They show up with a different name and Avid prompts them as being different, disabling export options needed for a functioning workflow.
 

Attachments

  • Ska?rmavbild 2016-07-04 kl. 17.12.27.jpg
    Ska?rmavbild 2016-07-04 kl. 17.12.27.jpg
    9.3 KB · Views: 0
  • Ska?rmavbild 2016-07-04 kl. 17.15.59.jpg
    Ska?rmavbild 2016-07-04 kl. 17.15.59.jpg
    7.3 KB · Views: 0
Back
Top