-
I did not know that! Send to compressor info
Something I was not aware of and maybe I’m the only one. “Sending” a timeline to compressor ignores the timeliene’s codec and render files and completely rerenders the sequence from SCRATCH to whatever codec you’ve chosen in COMPRESSOR. It does not render to the sequence settings, and then utilize that intermediate data to compress. It ignores existing render files AND the sequence codec.
Why is this cool? Because it can make your DVDs and BluRays and h.264s look much better. Many of us here have been sending out a file as a self-contained quicktime file at current settings and claiming/thinking that is the best quality you can export from your timeline. Not true. All your texts and renders will be subject to whatever codec you are using on your timeline. And if you’re going to take that “current settings” export and use compressor to make a h.264 you are doing a small disservice to your graphics an effects because you’re just gone down a generation as well.
To put it in perspective, perhaps you’re working in a DV sequence for example’s sake. Maybe everything was shot DV, but you have a couple really nice pro res 444w/alpha anims mixed in. DV is going to add some nice noise to those anims. Then, you export a self contained current settings QT and take that into compressor which makes a h.264 of that noise.
If instead you send to compressor from the timeline, even if that 444 graphic has been rendered, it will ignore the renders and the sequence codec and simply render the raw files to h.264 AS IF your sequence was set to h.264. and h.264 will be a lot nicer to those graphics than DV. The resulting h.264 will be free of DV artifacting around the text.
But if everyone already knew this -great. Maybe it’s new in version 6 or 7 and it certainly explains why it’s always slower to do it this way, even on a rendered sequence. I tested it myself. Take a nice pro res seqeunce and change the codec to sorensen or something nasty. Render a little bit. Make sure it looks like hell. Then take that rendered little section and send to compressor and choose a high quality h.264 codec. The result looks pristine. It ignores the render files AND the sequence codec completely. Using the original media to compress the h.264 from the ground up.
To quote the manual…
When Should You Export Directly to Compressor?
The advantage of exporting a sequence to Compressor directly from Final Cut Pro is that rendering happens as part of the transcoding process, potentially saving you time and eliminating unwanted artifacts.Given, the above is all subject to practicality. If you’re working in uncompressed or prores 422HQ it’s probably not going to get that much better. Especially if you’d be facing a 10 hour send to compressor vs. a 20 minute compressor encoding. But I have seen a regular pro res seq butcher some thin lined graphics that an xdcam seq didn’t oddly enough. Different codecs have different strengths. So even pro res isn’t the ultimate answer. (For those of your AE folks out there, sending to compressor is just like using the render que in AE.)
-
12 Replies
-
[Bret Williams] “Something I was not aware of and maybe I’m the only one. “Sending” a timeline to compressor ignores the timeliene’s codec and render files and completely rerenders the sequence from SCRATCH to whatever codec you’ve chosen in COMPRESSOR. It does not render to the sequence settings, and then utilize that intermediate data to compress. It ignores existing render files AND the sequence codec.”
Right like that.
Whatever you put on a time-line gets read and processed as a full 444 signal with the colorfield and bit depth up to the sequence setting. The Sequence Codec is ‘applied” over this Uncompressed picture when rendering or exporting. FC sends this picture directly to Compressor.
IMHO this path is a total waist of time (making Multipass H264, all your sequence needs to be rendered THRE TIMES!!).
You get the same and faster, rendering at high quality and exporting SElf-contained to an Uncompressed codec.[Bret Williams] “To put it in perspective, perhaps you’re working in a DV sequence for example’s sake. Maybe everything was shot DV, but you have a couple really nice pro res 444w/alpha anims mixed in. DV is going to add some nice noise to those anims. Then, you export a self contained current settings QT and take that into compressor which makes a h.264 of that noise. “
With the actual codecs rendering to DV makes no much sense unless you need to deliver DV.
I edit my DV sequence and render to Prores (High Precision, etc). I apply Nattresse Chroma Smooth/Sharpen and that doesn’t look like DV anymore).
Then I import my Prores master to Compressor or whatever other application to make a DVD, H264 or whatever.
rafael -
My point is that when using SEND to compressor, the sequence codec is NOT applied to the Uncompressed 444 image and is rendered exactly one time, during the transcoding, to whatever codec you\\\’ve chosen in compressor. Just like the manual states. It is the highest quality export you can obtain. High quality graphics in your timeline like pro res 444 would greatly benefit from going straight to h264 vs being compressed to pro res LT and even regular pro res in some cases.
There may be exceptions with certain plugins, codecs or fx, I\’m not sure.
Yes, it\\\’s definitely tedious and might not be practical most of the time, but in a world of high def/blu-ray and high def web video every little counts sometimes.
In the case of DV, it might be impractical for someone to work in anything but DV because they\’re mastering to DV and shot on DV. But a certain project might have a highly graphic section with lots of fine text or saturated colors that DV butchers. Using send to compressor would alleviate this problem on any copies of the project destined for the web or DVD by skipping the DV compression altogether, UNLIKE exporting a self contained movie from that sequence. And I, for one, did not know that and find it very interesting and possibly useful.
Yes you could accomplish similar results by switching you sequence codec to uncompressed and then rendering/exporting, but that would actually be 2 render passes instead of one.
-
A high quality self contained master of your finished edit is no bad thing to have Bret … if you tend to work in DV, mastering to DV etc this does not preclude archiving a much higher quality file based master, I think most of us will do this as a matter of course regardless of edit codec. If you have such a master then using it as a source directly in Compressor for repurposing for DVD, web etc is usually going to be faster and more convenient than the direct Send To option from FCP. But certainly I wouldn’t dispute that “every little counts sometimes” and your understanding of FCP 7’s “Send To” is correct, as in that method will preserve whatever quality is available without intermediate compression.
-
[Bret Williams] “My point is that when using SEND to compressor, the sequence codec is NOT applied to the Uncompressed 444 image and is rendered exactly one time, during the transcoding, to whatever codec you\\\’ve chosen in compressor. “
Yes if you are converting to Prores, DV, or any of the habitual codecs. Those are all “One pass”.
The 444 is compressed to that on the fly.
If you are converting to a “Double Pass MPEG-2 this doesn’t happens. The sequence is rendered in 444 and send for the first pass, but this files doesn’t get stored nowhere; it gets lost and needs to be rendered again for the second pass.
This happens twice with “Double Pass MPEG-2”, with a Multipass H264 it happens THREE times. Your sequnce needs to be renderd three times. Beside this, Compressor needs to resize or change the field order (if needed) tree times too.Why that 444 Uncompressed sequence is not stored?
Imagine that you are sending a 3 hours program to make a H264: You would need lot of memory to store 3 hours 8/10b Unc 444 stuff.[Bret Williams] “High quality graphics in your timeline like pro res 444 would greatly benefit from going straight to h264 vs being compressed to pro res LT and even regular pro res in some cases. “
So, why to go to LT or plain Prores?
Go to 10b Unc or Prores HQ.[Bret Williams] “In the case of DV, it might be impractical for someone to work in anything but DV because they\’re mastering to DV and shot on DV. But a certain project might have a highly graphic section with lots of fine text or saturated colors that DV butchers. Using send to compressor would alleviate this problem on any copies of the project destined for the web or DVD by skipping the DV compression altogether, UNLIKE exporting a self contained movie from that sequence. And I, for one, did not know that and find it very interesting and possibly useful.”
You are right here. Is not Compressor that makes a better job, is that you avoid the killing DV re-compression. This is why I said that there is not reason to re-compress to DV than the need of printing to DV tape.
Bret, as a rule of thumb, whatever the footage you are using, render always to the less compressed option at hand. That’s the only way of, if not improving a picture, at least degrade it less. Also is the only way to keep what you add with your effects, graphics, etc.
How to get this on FC/compressor?
“Sending to Compressor”, or exporting from FC an Uncompressed file.
The theoretical advantage of sending a 444 Uncompress vs a 422 Uncompressed will get lost as soon as on Compressor you transcode it to any no-444 codec.
The real con is the waist of time.[Bret Williams] “Yes you could accomplish similar results by switching you sequence codec to uncompressed and then rendering/exporting, but that would actually be 2 render passes instead of one.”
Compressor will make the two passes but on a fully rendered movie.. Compressor will only need to run twice the “frame Control’ (for resizing and de-interlacing) if was set ON,on each of the two passes (analice and transcoding), but won’t needs to render all your sequence (effects, animations, graphics,..) twice.
rafael -
An important caveat worth mentioning is that the “send to Compressor” option does not support virtual clusters. Hence, if your computer is configured as a virtual cluster in order to let Compressor take full advantage of multiple processor cores, “send to Compressor” can’t be used.
https://support.apple.com/kb/TS1099
-
For what its worth Bret, I believe FCP has behaved this way since the beginning. Definitely it has worked this way since the “send to Compressor” option was added (v4? v3? — I don’t remember).
Using the “Send to Compressor” option has the added benefit of auto-generating “I” frames on every edit point, which can lead to nicer looking encodes.
In the past I’ve done a lot of tests comparing encode times via different export methods (using FCP v4). This was pre-virtual clusters. The rendering times using “send to compressor” were basically identical to encoding stand-alone via Compressor. In a sense, they were faster, since you could skip the “export self contained quicktime” step. BUT, these were on SD timelines with minimal effects, graphics, overlays, no resizing or field order conversions, etc.
Of course, running an encode on a virtual cluster will generally smoke the “send to Compressor” option.
[Rafael Amador] “If you are converting to a “Double Pass MPEG-2 this doesn’t happens. The sequence is rendered in 444 and send for the first pass, but this files doesn’t get stored nowhere; it gets lost and needs to be rendered again for the second pass.”
Rafael, I get what you are saying about having FCP re-cache your frames for every step, but you are describing a worst case scenario.
For example, if you’ve “Force rendered” your timeline and then you “send to Compressor,” your machine will just reference the render files on disc. The time it takes to cache these files into a 444 image buffer will be trivial. But you’ve also lost the benefits of rendering in 444 space, since your sequence is already rendered at the compression settings of your timeline.
Now, if you’ve left your timeline unrendered, its a different story. Your render times are going to be highly dependent on the source material. If it’s a simple timeline, with little or no effects, then your render will be relatively efficient; the amount of time it takes to cache your frames to a 444 image buffer will be trivial compared to the other steps of the process. BUT, if you have lots of effects, then this may no longer be true.
So, like lots of things in FCP, I don’t think a definitive answer is possible. There’s a lot of variables going on here. In the end, I think each user needs to test for themselves and decide when each encoding approach is appropriate.
Matt Lyon
Editor
Toronto -
Great point. As well as Rafael’s about multipass h264 and mpeg. Like I said originally, it may not be practical. I just didn’t know that’s how it functioned.
I think in the end, the combination of I-frame features and highest possible encoding path might make it a candidate for those really important high end projects. If I ever get one, I’ll give it a try.
-
[Bret Williams] “I think in the end, the combination of I-frame features and highest possible encoding path might make it a candidate for those really important high end projects.”
Buy a good application to compress and you won’t need to care about these I-frames 🙂
rafael -
[Matt Lyon] “For example, if you’ve “Force rendered” your timeline and then you “send to Compressor,” your machine will just reference the render files on disc”
I’m not much sure about this Matt.
On my experience, Compressor never looked at the FC render files, but it may be something from the past.
The truth is that I can’t remember the last time I “Sent” something to Compressor.
Is easy to make a test, and probably with an slow computer will be easier to spot the fact.
rafael -
ha ha, yes I hope I’m not mis-remembering too! 🙂
This statement was based on my memory of an old bug I remember dealing with. It used to be that if you “sent to compressor,” then the final output would sometimes give strange results with certain kinds of generators. The font size and placement, for example, would not match the FCP viewer. But if you pre-rendered the timeline, then it wouldn’t be a problem (if memory serves me correct). So my conclusion was that Compressor was reading the render files, not generating new renders on the fly.
Matt Lyon
Editor
Toronto
Reply to this Discussion! Login or Sign Up