Chris Kenny
Well-known member
First... do we have any idea when Final Cut will can support for real-time playback of 4KHD _M proxies? The issue here, of course, is that FCP doesn't seem recognize 960x540 as a valid resolution for Unlimited RT, and you can't play back Red footage without rendering on timelines that don't have Unlimited RT enabled. If you drag the proxies into a 1024x576 timeline (the _M resolution for 4K 16:9), then you can enable unlimited RT. But of course FCP needs to scale the proxies to get them to fill the frame, and our 8-core Mac Pro doesn't seem to be fast enough to scale them while play back at full frame rate.
If you import the _H proxies from 4KHD footage into FCS you can enable Unlimited RT (1920x1080 is obviously a supported resolution). But the _H proxies don't play back in real-time without dropping frames normally, so this isn't any help.
Basically, there's currently no way to edit footage shot in 4KHD mode from proxies or QT-wrapped Redcode data imported via Log & Transfer. This is very frustrating. It's particularly bad, in fact, because of the fact that the FCP/Color workflow does a "Half Res High" debayer. This means if you're working with 4K 16:9 footage, it has to be decoded to 2048x1152 and then downscaled to 1920x1080, which is going to result in artifacts. Given that most of the footage fed through this workflow is probably destined for 1080p deliverables rather than 2K deliverables, this seriously needs fixing.
Secondly... rewrapping Redcode data in QT files is a massive waste of hard drive space. It's not like you can just delete your original R3D files after rewrapping their data, the way most people do with P2 data. Doing this with Red footage, you'll cut off access to many of your future options for working with the footage.
Instead of doubling the disk space requirements of every project, it makes far more sense to just work from the proxies. Now, I understand that Color has issues when it's fed proxy files that point to multiple R3D files. But it seems to me like there's a much better solution to this problem than requiring all the R3D data into those files to be re-wrapped. My understanding is, long shots are broken up into multiple R3D files because the Red Drive is formatted FAT32, which has a 4GB file size limit. Why not offer a utility to join those files once they're copied to a desktop system? Or, better yet, why not offer an ingesting utility that joins those files as they're copied off the magazines? That would give you joined files without requiring any extra data copying.
To work around these two issues (and get more responsive editing performance), I'm trying to put together a workflow where we can offline in 720p draft-quality ProRes (which Redcine can output nearly in real-time on our Mac Pro), and a script will then spit out a list of only the shots used in the final edit so they can be ingested through Log & Transfer, the ProRes media can be re-linked to the resulting QT-wrapped R3D files, and then the timeline can be sent to color.
Now, it's not that I don't enjoy pulling out Ruby every now and then for some XML slinging, but... it seems like there are pretty good workflow solutions for the mid-range and high-end (respectively, SCRATCH, and just transcoding everything to DPX for a traditional DI workflow), but every low-cost commodity workflow has something a little screwy about it. Either you have to generate hundreds of gigabytes of extra files, or you don't preserve access to the raw data, or you have to write scripts to mess with FCP XML files (or buy third-party tools that do do it for you), or you have to transcode footage you don't end up using, or you have to give up access to the full raw data before you get into grading, or some combination of those.
Fix the two issues above (and offer an option to feed Color 1080p or 2K data that's derived from scaling down from a full debayer, instead of performing a half-res debayer), and I will be completely satisfied in the Red/FCP/Color workflow.
If you import the _H proxies from 4KHD footage into FCS you can enable Unlimited RT (1920x1080 is obviously a supported resolution). But the _H proxies don't play back in real-time without dropping frames normally, so this isn't any help.
Basically, there's currently no way to edit footage shot in 4KHD mode from proxies or QT-wrapped Redcode data imported via Log & Transfer. This is very frustrating. It's particularly bad, in fact, because of the fact that the FCP/Color workflow does a "Half Res High" debayer. This means if you're working with 4K 16:9 footage, it has to be decoded to 2048x1152 and then downscaled to 1920x1080, which is going to result in artifacts. Given that most of the footage fed through this workflow is probably destined for 1080p deliverables rather than 2K deliverables, this seriously needs fixing.
Secondly... rewrapping Redcode data in QT files is a massive waste of hard drive space. It's not like you can just delete your original R3D files after rewrapping their data, the way most people do with P2 data. Doing this with Red footage, you'll cut off access to many of your future options for working with the footage.
Instead of doubling the disk space requirements of every project, it makes far more sense to just work from the proxies. Now, I understand that Color has issues when it's fed proxy files that point to multiple R3D files. But it seems to me like there's a much better solution to this problem than requiring all the R3D data into those files to be re-wrapped. My understanding is, long shots are broken up into multiple R3D files because the Red Drive is formatted FAT32, which has a 4GB file size limit. Why not offer a utility to join those files once they're copied to a desktop system? Or, better yet, why not offer an ingesting utility that joins those files as they're copied off the magazines? That would give you joined files without requiring any extra data copying.
To work around these two issues (and get more responsive editing performance), I'm trying to put together a workflow where we can offline in 720p draft-quality ProRes (which Redcine can output nearly in real-time on our Mac Pro), and a script will then spit out a list of only the shots used in the final edit so they can be ingested through Log & Transfer, the ProRes media can be re-linked to the resulting QT-wrapped R3D files, and then the timeline can be sent to color.
Now, it's not that I don't enjoy pulling out Ruby every now and then for some XML slinging, but... it seems like there are pretty good workflow solutions for the mid-range and high-end (respectively, SCRATCH, and just transcoding everything to DPX for a traditional DI workflow), but every low-cost commodity workflow has something a little screwy about it. Either you have to generate hundreds of gigabytes of extra files, or you don't preserve access to the raw data, or you have to write scripts to mess with FCP XML files (or buy third-party tools that do do it for you), or you have to transcode footage you don't end up using, or you have to give up access to the full raw data before you get into grading, or some combination of those.
Fix the two issues above (and offer an option to feed Color 1080p or 2K data that's derived from scaling down from a full debayer, instead of performing a half-res debayer), and I will be completely satisfied in the Red/FCP/Color workflow.
