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 :)

"Native" QuickTimes good, but not great

Scott Simmons

Well-known member
Joined
Sep 1, 2007
Messages
243
Reaction score
0
Points
0
Website
www.scottsimmons.tv
I hate to bring us all down from the high we are on with this new update to FCP and the "native" RED QuickTimes but other than making it easier to get a sequence into Color I don't see much of an advantage to this workflow.

I'm talking strictly from an offline, creative editing stand-point here BTW. These "native" RED QuickTimes still have to be edited on a timeline with Unlimited RT, Playback video quality and frame rates set lower, Scrub High Quality turned off etc. There still seems to be huge performance hits as soon as you add a dissolve, effect, title or (what is a must in my world) make a multiclip for a music video edit. It's a + that these files are now self-contained and no longer the QT reference proxies so they can be moved around and such and they can be made very quickly but as far as their overall value for a creative, offline edit .... I'm still going ProRes 90% of the time.

I'd call this a small step for man. IMHO.
 
I hate to bring us all down from the high we are on with this new update to FCP and the "native" RED QuickTimes but other than making it easier to get a sequence into Color I don't see much of an advantage to this workflow.

I'm talking strictly from an offline, creative editing stand-point here BTW. These "native" RED QuickTimes still have to be edited on a timeline with Unlimited RT, Playback video quality and frame rates set lower, Scrub High Quality turned off etc. There still seems to be huge performance hits as soon as you add a dissolve, effect, title or (what is a must in my world) make a multiclip for a music video edit. It's a + that these files are now self-contained and no longer the QT reference proxies so they can be moved around and such and they can be made very quickly but as far as their overall value for a creative, offline edit .... I'm still going ProRes 90% of the time.

I'd call this a small step for man. IMHO.

transcoding to pro res sucks
 
I hate to bring us all down from the high we are on with this new update to FCP and the "native" RED QuickTimes but other than making it easier to get a sequence into Color I don't see much of an advantage to this workflow.

I'm talking strictly from an offline, creative editing stand-point here BTW. These "native" RED QuickTimes still have to be edited on a timeline with Unlimited RT, Playback video quality and frame rates set lower, Scrub High Quality turned off etc. There still seems to be huge performance hits as soon as you add a dissolve, effect, title or (what is a must in my world) make a multiclip for a music video edit. It's a + that these files are now self-contained and no longer the QT reference proxies so they can be moved around and such and they can be made very quickly but as far as their overall value for a creative, offline edit .... I'm still going ProRes 90% of the time.

I'd call this a small step for man. IMHO.

I don't think I would want to edit with the Native files the L&T creates for you either, but I would still work in ProRes and possibly re-conform the Media after picture lock back to the Native files for Color. The best scenario (for me IMHO) would have been take any ProRes transcoded files (from REDCINE, RR, L&T, Etc.) and have those files reference the original R3D's via clip name/XML etc into COLOR along with the option of editing with the Native files if you so choose. I also think it would be great if you had more options in the L&T such as working resolution for transcode, and importing .rcc/rsx files etc. I'm sure its not that simple though and obviously the workflow is the way it is because of a specific reason (not saying its bad, just still young and growing). This is just the beginning though and I'm sure COLOR will support all frame rates, Resolutions etc. in the near future and will grow and evolve as RED post continues to grow as well.
 
Wouldn't it be nice if the FCP timeline picked up the same info accessed
by the _H or _M reference quicktimes
yet still sent all data to Color

Could this be selected during the Log & Transfer stage?

Wishful thinking
 
I'd call this a small step for man. IMHO.

Its a huge step forward for final finishing quality. I see a (to me) huge difference in how the graded image looks, working form the original 12bits, instead of a transcoded 1080p ProRes. There's a refinement to the final image that I'm only used to seeing with telecined film. I'm talking about after a pass through Color. The RAW QTs are not terribly different from proxies, of course.
 
Its a huge step forward for final finishing quality. I see a (to me) huge difference in how the graded image looks, working form the original 12bits, instead of a transcoded 1080p ProRes. There's a refinement to the final image that I'm only used to seeing with telecined film. I'm talking about after a pass through Color. The RAW QTs are not terribly different from proxies, of course.

Oh yea I agree that grading from the .R3Ds beats ProRes grading for sure. I'm just looking at the offline from a performance standpoint of the RED QuickTimes. Sometimes it makes sense to use the proxies or RED QuickTimes, sometimes not.
 
A lot of these problems would be simplified if L&T gave you more options than just 1/2-res when importing. And then if L&T could use Qmaster to distribute it's transcoding tasks....

now THAT's dreaming!
 
Wouldn't it be nice if the FCP timeline picked up the same info accessed
by the _H or _M reference quicktimes
yet still sent all data to Color

Could this be selected during the Log & Transfer stage?

Wishful thinking

To Brent@RED – can the quicktime wrapper be constructed so this can happen?
 
Back
Top