-
Render test
-
Here you go: https://blogs.adobe.com/premiereprotraining/2011/02/red-yellow-and-green-render-bars.html
From the doc that’s worth noting:
Note: Rendering of previews is only for preview purposes. Preview files will not be used for final output unless you have Use Previews option checked on output—which you should not use except in the case of rough previews. Using preview files for final output will in almost all cases cause a decrease in quality. It can speed things up in some cases, so it may be useful for creating a rough preview in less time.
Jeremy
-
Heres another.
Full post: https://forums.adobe.com/message/3939546
Relevant answer from Adobe: https://forums.adobe.com/message/3939546#3939546
-
[Jeremy Garchow] “Rendering of previews is only for preview purposes. Preview files will not be used for final output unless you have Use Previews option checked on output—which you should not use except in the case of rough previews. Using preview files for final output will in almost all cases cause a decrease in quality. It can speed things up in some cases, so it may be useful for creating a rough preview in less time.”
Yes. Unless you’re using uncompressed preview settings, Premiere Pro will add a generation of compression to preview files on output.
[Jeremy Garchow] “In this sense, fcpx and premiere change the nature of what rendering means. Premiere especially as they don’t use the qt specific reference file architecture… The removal of reference exporting is the first hint, I imagine.”
FCP Classic didn’t use QuickTime reference exclusively, though. When outputting a self-contained movie with existing render files (which were by definition locked to the sequence codec), FCP could copy the data from one QuickTime file (the source clip or render file) into another (the output file) without a decompress/recompress cycle.
Interestingly, this problem has had a long-standing solution outside of QuickTime for decades — image sequences. Almost no one in straight editorial uses them, but almost everyone in animation/effects does and many in finishing work do. I wish Premiere Pro supported image sequence-based previews, but I imagine that’s a pretty niche feature request.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Walter Soyka] “FCP Classic didn’t use QuickTime reference exclusively, though. When outputting a self-contained movie with existing render files (which were by definition locked to the sequence codec), FCP could copy the data from one QuickTime file (the source clip or render file) into another (the output file) without a decompress/recompress cycle.”
We are saying the same thing, just differently.
I was referring to FCP referencing the rendered media and not reencoding it.
In the case of X I was talking about a true reference file (not self contained). X does not have ref files, which means rendering is less important and there’s no gain. Render what you need to to preview your work, but don’t render what you don’t. It’s all going to get transcoded in the export anyway, similar to premiere.
Adobe calls it smart rendering, and apparently it’s QT specific.
What I don’t know is if FCPX uses smart rendering. It seems to with the very informal export tests I’ve don to the same timeline “render” codec: https://forums.creativecow.net/thread/344/7721
-
[Jeremy Garchow] “We are saying the same thing, just differently.”
That’s been known to happen from time to time!
[Jeremy Garchow] “Adobe calls it smart rendering, and apparently it’s QT specific.”
At the moment, yes — though I can’t imagine a reason why Adobe couldn’t write this into a future version of MediaCore. Whatever you call it (and I actually hadn’t seen a name for this feature until an Adobe rep called it smart render), it’s a great feature. Way better than “dumb render.” Decompressing then recompressing every frame for output is for the birds.
Of course, by ditching the movie wrapper and its attendant APIs, you can “smart render” an image sequence with nothing more than Finder (or basic OS file I/O as in Smoke).
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Jeremy Garchow] “It’s my understanding that it’s always a transcode. When using the preview files, even if it’s ProRes or 10 bit, you are still transcoding to whatever your output codec is. “
If the output codec matches the preview codec, then there’s no transcode, AFAIK. This may only be a copy and rewrap. I think the documentation isn’t clear. In the case of Avid, the functions are different, depending on whether you pick “same as source” on export. That’s definitely a copy/rewrap, which is why their ProRes compatibility is now native and transparent. In the case of Adobe, there may be some differences between render, exports and originals, because they are having to encode to ProRes using the QT engine and are not doing it natively like Avid now does (and Apple, of course).
Here’s a simple way to test if you really want to test it. Do the render and exports in Premiere Pro. Then pull the export and the original into After Effects and do a difference composite and see what you get.
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
More info:
https://blogs.adobe.com/VideoRoad/2011/08/a-prores-workflow-end-to-end.html
– Oliver
Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com -
[Walter Soyka] “Yes. Unless you’re using uncompressed preview settings, Premiere Pro will add a generation of compression to preview files on output.”
Which, (using a 10 or 12 bit uncompressed codec for previews), is exactly the optimum way to work with minimum loss on final output. But quite frankly, in my experience the use of most high bit rate codecs for previews yield undetectable loss on output in most situations.
David
AllinOneFilms.com -
[Oliver Peters] “If the output codec matches the preview codec, then there’s no transcode, AFAIK. “
I hate to keep harping on this, but it doesn’t. I know it doesn’t, I have heard from the Adobe guys, it doesn’t work that way.
The preview files are used, but they are decoded then reencoded to your export codec.
It does not work like FCP.
That’s why Adobe says not to use them, unless you need extra speed.
As far as the ProRes end to end, the part about reencoding is conveniently left out.
Jeremy
-
Interesting test Oliver! I think testing to be fair you should turn on 32-bit floating point processing on all softwares. Or at least best possible quality because as we know FCPX is always rendering at 32-bit floating point. I don’t know if it makes any difference but anyway.
Another thing I’ve noted is that some plugins (especially FxFactory plugins) are much slower in FCPX than in Motion. Especially user interfaces. for example UI of Moods plugin.
Best
Tapio HaajaOn-Air Promotion Producer
https://avseikkailuja.blogspot.com/
Reply to this Discussion! Login or Sign Up