Just to confirm, is there any difference at ALL (i.e. performance or any other capability) between AMA linking to a DNxHD .mov file and importing the same file using the same parameters?  As far as I can tell the only difference is that with the AMA link, you can choose the location of the file, whereas with the import, Avid takes care of the media location.

Is this essentially correct, or are there potential disadvantages to AMA linking rather than importing?  The documentation says that AMA linking could have lower performance, but it seems like this would not apply to .mov files that are already encoded using DNxHD.  The documentation is not entirely clear on this, however, so I wanted to confirm.

Thanks,

Larry

You should have better performance if you import the files. You can fast import if you choose 601/709 pixel mapping, which is very fast.

As all it does is demux the video and audio and rewraps them in the MXF Op-Atom wrapper. This is a better way to store footage for video editing that should allow more reliable and faster access.

BobbyMurcerFan:

You should have better performance if you import the files. You can fast import if you choose 601/709 pixel mapping, which is very fast.

As this is native media, I think ama link and consolidate is the way to go, faster and also safer as this process uses a crc check to verify the consolidation of the media.

If you only want to use a part of the origin file, consolidating the Sequense it is placed on only consolidates that part of the file and that is of course also a lot faster that importing the entire file.

I don't think there is any reason to consolidate given that I'm utilizing nearly 100% of the footage I import or AMA link.  This is simply the nature of this particular project -- there is VERY little overhead.  In other words, I use essentially every second of every file I import or link, so consolidating doesn't reduce the storage by any meaningful amount.  Rather, it simply duplicates everything.

Regarding performance, is there data or documentation confirming that MXF wrappers offer a performance advantage over mov wrappers when using the same encoding, which in this case is 175X (1080p/23.98)?  I thought that the codec bascially made all the difference and that the wrapper had little effect in this regard.

I ask because if I can edit just as effectively using the AMA linked files directly, it will cut the storage requirements down substantially compared to AMA linking and then transcoding (which duplicates everything.)  I can only create .mov DNxHD source files in my current pipeline, so using the mov files encoded with DNxHD 175X offers me a real space saving workflow.  Unless, of course, there are any downsides to using the original mov files without transcoding them to mxf.

Note that I can't delete the original mov DNxHD files, so the question is whether or not there is any disadvantage to using these files directly instead of transcoding them to mxf in Avid.  The only information I've found is about Avid imports/transcodes working faster than AMA linking in general, but these reports do not include using DNxHD files to start with.

The bottom line is that it seems redundant to AMA link to DNxHD files, then transcode using the exact same DNxHD format.  The whole AMA workflow is new to me, however, so I'm looking for feedback on this.

Thanks,

Larry

The first time we used AMA in a 1 hour programme a few years ago, we found out how useful/useless AMA was  for longform editing.  When we reached 30 minutes into the timeline, it got very laggy and unresponsive, an editors nightmare, and got so bad we trasncoded everthing to DNX36 and proceeded from there.  AMA is fine for short form but needs transcoded/consolidated for longform.  We also couldn't quicktinme reference from AMA linked media as well which is a function we use a lot.

AMA and consolidate or fast import achievt eh same thing (AMA lets you subclip if needed)

And both give you Avid managed media without the AMA RAM over head.

AMA direct linked editing is ok for small fast jobs.

I generally suggest avoiding import (even fast) as you can get slight level shifts etc and AMA tends to get the most development.

But it's done a on a job by job basis.

Also remember that at conform stage AMA can be much quicker where as import requires the whole clips to be re-imported. 

My experience is that long clips on the source side can become unworkably sluggish in AMA compared to consolidated mxf.

But really, as long as you can reference your clips from the timeline, you can always try it and see how it works for you.

I can't point to any documentation that states that DNxHD wrapped as MOV and accessed via AMA performs worse than DNxHD wrapped as MXF Op-Atom. I guess you could make a test for yourself. It would be interesting to learn the results.

But I do know that MXF Op-Atom was designed specifically with the needs of NLE's in mind, while QT clearly was not.

From experience importing is much faster then consolidating/transcoding but it can cause more trouble related to color space, frame rate etc.... convertion.

If Avid would remove the "multple files at the same time" during consolidation (or make it optional) ama could/should be just as fast as importing and therefor the preferred method.

Jeroen van Eekeres:

From experience importing is much faster then consolidating/transcoding but it can cause more trouble related to color space, frame rate etc.... convertion.

If Avid would remove the "multple files at the same time" during consolidation (or make it optional) ama could/should be just as fast as importing and therefor the preferred method.

Thats an intereting point currently an AMA conslidate will try and process multiple sources at once to optimise core count but if you are coming off optical media (rather than a copy off hard disk) the seek and re-seek overhead becomes massive and the ingest speed really suffers.

Okay -- I'm convinced that directly editing the AMA linked files is NOT the way to go in the long run.  I've been reading up on transcoding to a lower quality (DNxHD36) just for editing, but I'm still real fuzzy on the overall process so that I can go back to the higher quality DNxHD 175X (the original source quality) at some point.  I see various workflow suggestions, some of which talk about renaming the mediafiles folder.  Is this really necessary?  I "thought" I read that Avid was natively designed to be able to relink to lower quality files, then relink back to the higher quality ones later.  Can anyone outline the steps or point me to the documentation explaining how to do this?

At the moment, I've got my original source material in a folder on the hard drive -- this was endocded to DNxHD 175X from blu-ray sources (all legally.)  The 175X material is RGB.  The thing I'm missing are the actual steps that would take me to DNxHD 36 for edting, then back to 175X for final QTRef output?  I remember seeing some documentation about this a while back, but I have been unable to find it again.

Thanks for any help with understanding the specifics of the workflow process here.

Larry

Here's the thing that's confusing me at the moment:

I AMA link to the 175X files, which are now organized in my bins.  I select the clips and transcode them to DNxHD 36, which creates new clips.  I create a sequence using these lower quality clips.  I now want to output a high quality QTRef of the sequence, so I need to relink the clips back to their original 175X sources -- THIS is the part I'm still fuzzy on.

Can I simply relink the transcoded DNxHD 36 clips to the original 175X clips using the "relink" command and selecting "highest quality" for the relink method?  Will this work even though the clip has a different name (it has the "new.01" at the end of the filename)?

The documentation I've been able to find so far (including some extra Avid "guides" I downloaded) has not been very clear on this. 

Thanks,

Larry

After testing, it looks like the answer to my previous question is "yes" -- you can relink the "new.01" file back and fourth between the 36 and 175X quality levels.  It turns out that this is not necessary, however, given that I only need to transcode the clips and not "relink" them.  It's the sequence that I need to relink.

So my workflow is starting to look like this:

- AMA link to the 175X files.

- Transcode all the clips to DNxHD 36.

- Create/edit the sequence using the lower quality clips.

- Transcode the entire sequence selecting "highest quality" for the relink method.

Do I understand correctly that the new "Relinked.01 sequence will now use all of the original 175X clips?  This appears to be what's happening in my tests, but confirmation would be welcome.

One question:  The video in the final sequence now shows the original clips and not the lower quality "new.01" clips -- i.e. the clips have gone back to the original clips without the "new" extension.  The audio, however, all still has the "new" extension on the filenames.  Does this matter?  Is this simply an artifact of the round trip that had to be done for the video, or is there a way to go back to the original audio clips as well (i.e. the ones that don't say "new" on them)?  I just want to make sure that even though the audio clips all say "new" on them, there has been no quality loss.

Thanks,

Larry

Interesting post. Has anyone figured out if there is a different in performance with ama linking DNX .mov or .mxf op1a files vs transoding and working natively with op-atom .mxf files. Anyone have any conclusive answers. Some say that generally AMA linking causes lag for long/larger projects, but would this still be true for ama linking DNX .mov or .mxf op1a files?

I am trying to figure which route to go immediately with a project I am prepping. Any answers to the above questions would be immensly appreciated. 

In addition to points made above, when the .mov is imported as .mxf, the audio tracks are written as seperate files.

The flexibility of being able to access only the files required for a given operation (video FX or audio processing), could well offer better performance in a large. complex project, over using a single .mov file.

Regards,

Richard