A video mixdown isn't a render. A video mixdown creates a new master clip linked to newly created media. That clip/media is used to replace the video content of a sequence prior to export so the export process isn't having to transcode just re-wrap the media.

Doing a fix or change in the sequence only involves a new short video mixdown of that section that is then cut into the earlier video mixdown.

Renders however are easier to break and harder to patch. Rendering has it's place and Video Mixdowns have their limitations but used correctly both are useful and time savers.

Thanks Pat. I know what a render is and what a video mixdown is. I never said a video mixdwon is a render but what I experienced with most difficult sequences (Sequences that rendering would take an entire night or 2 days and then when you make one single change at the end or beginning of that seuqence and not the big effect or what causes the sequence to take for ever on the rendering) is that instead of rendering the sequence to later mixdown or collapse and export as QT ref or as "self" is that a mixdown does both things because otherwise you wouldn't be able to playback that newly created media...it would have to be rendered in order to playback normally. Anyway I mentioned things like RGB444, Rec709 projects, 350x 444, etc....hoping to learn more about these specific workflows. Rendering, outputting/exporting and concecuently uploading short videos without sacrificing much quality....uploaded hundreeds of them but a lot to learn still...

 

 

One more small comment about mixdown vs. fully rendered Same As Source sequence.

If you are planning on using the Same As Source export of a fully rendered sequence, you should pay close attention to having only 1 codec in the sequence.

We recently recieved a DNx .mov made with the Same As Source method.  When it was opened in Resolve, certain scenes were black.  Upon some research, we found that those section were different codec than the very first codec in the sequence.  Why do I say the very first codec?  It is my understanding that the first codec seen during a Same As Source export is what is placed in the files meta data.  And the fact that the codec changed in the course of the export can screw things up.  As we saw. 

The solution was a mixdown / same as source export.  That worked.

It is rare that I have a sequence with only one codec.  So for me, the mixdown solves mulitiple issues.  And, like Pat, I am used to just cutting out an area needing revision from the mixdown, fixing, then making a mixdown patch.

The only thing I do not like about mixdowns is that they do not seem to truly have time code baked in the media.  Not sure about that.  But I have run into situations where a mixdown file did not act the way I felt is should have when it came to respecting time code of it's "parent".

Just a bit to think about.

Jef

Job ter Burg:

Pat, your example is confusing, as you are not just 'rendering' but transcoding.

I'm talking about a sequence with MXF media generated from the get go.

I found Pat's example very relevant. I'll only transcode to MXF if I have to and even cutting multicam it's only XAVC in HD that I find myself transcoding because it's very heavy. Plus the original question was

Do Video Mixdowns Increase Speed of Export?  (nothing in there about MXF only seq's)

Basically what Pat is saying is that given the same set of parameters and what a lot of us work with in the real world - mixed media sequences, that video mixdown is much faster. I'm not sure why but it simply is. It is also safer as Jef pointed out, as you know you will end up with a one format sequence and it is also available for QTRef export.

It would also be great if Avid introduced background rendering of video mixdowns - I think a number of users have asked for this.

Job ter Burg:

P.S.: just did a test. 2-minute sequence consisting of DNxHD clips, each of them with a source-side color correction, save for one. Render in-out took 29 seconds. Video Mixdown (to the same flavor of DNxHD) took 26 seconds.

Even in the example you gave which is the ideal foreground rendering still took 11.5% longer. 

As Pat said both workflows have their place but particularly for me I'm finding that video mixdown is extremely quick and efficient, but a little more manual when it comes to updating a timeline. So I guess it depends on how you work. And that should be the answer to the OP - try it and see if its a good fit for your workflow. 

Truly, the best thing to take away here is an understanding of the pros and cons of both so that you can choose the best route depending on the task.

Jef

This may need its own topic but seeing as this may be related, thought i would ask. Not to concerned about speeding the process up, more carrying out 'correct' procedure (aware though that there are many 'correct' procedures when it comes to Avid!)

I have always used mixdowns (audio and video)/QT Ref files exported into Squeeze for compression. Having read through this post, i was wondering if doing mixdowns, it's essential to render effects before exporting the mixdown? Could i get away with not rendering any effects and just carrying out mixdowns and then export a QT Ref file?

Again sorry if this should be posted elsewhere or it has been touched on.

benholden:

i was wondering if doing mixdowns, it's essential to render effects before exporting the mixdown?

Rendering effects is NOT required, or IMO even particularly desirable before exporting mixdown timelines.

benholden:

Could i get away with not rendering any effects and just carrying out mixdowns and then export a QT Ref file?

YES. I have worked this way for almost exclusively for a decade or more. (since HD)

Why? For me having a top layer top video layer full of mixdowns gives me single stream playback at any time. (client progress viewing)  It reduces my need for having the latest and fastest computers and expensive RAIDs. Using mixdowns rather than rendering throughout the edit allows me complete confidence of a very quick QT reference or Same as Source export at any time during the edit. Keeping all my mixdowns in a "Mixdown" bin allows me easy media cleanup at the end of the project. 

benholden:

I have always used mixdowns (audio and video)/QT Ref files exported into Squeeze for compression. Having read through this post, i was wondering if doing mixdowns, it's essential to render effects before exporting the mixdown? Could i get away with not rendering any effects and just carrying out mixdowns and then export a QT Ref file?

Memory is a bit foggy, but I believe I had an issue just a week ago where a mix down prior to rendering showed severe banding.  Rendering THEN doing a mixdown solved the issue.  I was quite surprised by this.  So I am now suggesting the opposite of Andrew.

As an aside, this was a sequence with several different codecs and the banding was seen when a title with a soft edged semi transparent background fadeing up was involved.

Jef

jef:

So I am now suggesting the opposite of Andrew.

Which only goes to re-enforce your previous sage advice Jef.

jef:

the best thing to take away here is an understanding of the pros and cons of both so that you can choose the best route depending on the task

Having not experienced your issue I will continue with my workflow but become even more vigilant with my QC. Out of curiosity how were the titles generated? Thanks

AndrewAction:

 

Having not experienced your issue I will continue with my workflow but become even more vigilant with my QC. Out of curiosity how were the titles generated? Thanks

After Effects rendered as PNG files (these were single frame IDs) transcoded to DNx 175x (probably) over top of a different codec.  Banding seen during  a slow fade up of the title.

Jef

jef:

After Effects rendered as PNG files

In AE were these from 8, 10,12 or 16 bit. If 8 bit then creating 10 bit DNx175X files may be the cause.  Or reducing 16bit  to 10 bit.

jef:

transcoded to DNx 175x

Transcoded or Imported?

(Sorry to digress from the threads mixdown topic)

AE project was probably 8bit.  (As noted, memory is vague now)

PNG was imported to DNx 175x.

But remember that my symptom was banding after Mixdown with no render first but NO BANDING in a render before Mixdown workflow.

It would seem that there should be no difference.

Jef