I Bloom
Well-known member
I've got a few Redcode clips on my laptop now, and I'm trying to come to an understanding of how cutting RED in FCP6 will work.
The difference that I see between REDCODE footage and say DVCProHD footage off of a P2 system, is that when we move P2 footage through the P2 importer, it creates quicktimes on our scratch disk that contain the actual footage.
When you export your P2 timeline as a "Non-self contained" quicktime, it contains pointers to parts of various clips in your capture scratch and render files. Likewise when you export self contained, it splices all that data together into a quicktime container.
RED footage is sort of twice removed. We already have quicktimes as soon as transfer footage from of CF cards, but these quicktimes simply point to R3D files and add some meta-data that tells the quicktime player, how to interpret the files (i.e. size and look information). We can take these quicktimes in FCP and start cutting (though right now it needs rendering (though even more interestingly, I can watch the clips moving in near realtime by scrubbing!!!))
I made a project in FCP with 2 redcode clips, I cut them down and I rendered them and then exported them as a non self contained quicktime. I opened the exported file up in quicktime player and it played back fine. I wanted to know what file was being referenced so I deleted the files from my Render files folder and found that quicktime player could no longer play back the file, because it was looking for the render file... as expected. As was also expected the Renderfile is in the native codec of my timeline, in this case ProRes. This is one current workflow, though I've heard that higher quality results can be achieved other ways, currently.
So why do I find all this so interesting, well because we've heard that in the future FCP is going to cut RedCode natively. But what is a RED quicktime, except a reference file to a .R3D file. That means in FCP you aren't cutting actual R3D files just reference files. When you export a native redcode quicktime as a "Non-self contained" quicktime, are you making a reference file to reference files???
Now as a former programmer, I think this stuff is straight genius. It eliminates the need for EDL's or pull lists or whatever, when conforming Red footage back to 4K. If you have a color correction program that can read these quicktimes, you can simply export and take it into say "Scratch" (heaven forbid, Lucas we'll be doing this on a PC
) and start grading. Scratch has access to the original R3D files and all the metadata you may have created. You might even import other kinds of quicktimes into FCP (say you have stuff that you exported from Shake and then needed to trim a bit in FCP) and the quicktime container might just carry them along.
I know that this is what has been advertised, but I'm just starting to try to understand it's implementation. It seems to me that EDL's and any intermediate file format, will be unneccessary for RED post when working in FCP, and that Apple Workflow will have a major advantage over any other NLE, simply because it will remain the only one that is quicktime based.
Am I understanding this correctly?
IBloom
The difference that I see between REDCODE footage and say DVCProHD footage off of a P2 system, is that when we move P2 footage through the P2 importer, it creates quicktimes on our scratch disk that contain the actual footage.
When you export your P2 timeline as a "Non-self contained" quicktime, it contains pointers to parts of various clips in your capture scratch and render files. Likewise when you export self contained, it splices all that data together into a quicktime container.
RED footage is sort of twice removed. We already have quicktimes as soon as transfer footage from of CF cards, but these quicktimes simply point to R3D files and add some meta-data that tells the quicktime player, how to interpret the files (i.e. size and look information). We can take these quicktimes in FCP and start cutting (though right now it needs rendering (though even more interestingly, I can watch the clips moving in near realtime by scrubbing!!!))
I made a project in FCP with 2 redcode clips, I cut them down and I rendered them and then exported them as a non self contained quicktime. I opened the exported file up in quicktime player and it played back fine. I wanted to know what file was being referenced so I deleted the files from my Render files folder and found that quicktime player could no longer play back the file, because it was looking for the render file... as expected. As was also expected the Renderfile is in the native codec of my timeline, in this case ProRes. This is one current workflow, though I've heard that higher quality results can be achieved other ways, currently.
So why do I find all this so interesting, well because we've heard that in the future FCP is going to cut RedCode natively. But what is a RED quicktime, except a reference file to a .R3D file. That means in FCP you aren't cutting actual R3D files just reference files. When you export a native redcode quicktime as a "Non-self contained" quicktime, are you making a reference file to reference files???
Now as a former programmer, I think this stuff is straight genius. It eliminates the need for EDL's or pull lists or whatever, when conforming Red footage back to 4K. If you have a color correction program that can read these quicktimes, you can simply export and take it into say "Scratch" (heaven forbid, Lucas we'll be doing this on a PC
) and start grading. Scratch has access to the original R3D files and all the metadata you may have created. You might even import other kinds of quicktimes into FCP (say you have stuff that you exported from Shake and then needed to trim a bit in FCP) and the quicktime container might just carry them along.I know that this is what has been advertised, but I'm just starting to try to understand it's implementation. It seems to me that EDL's and any intermediate file format, will be unneccessary for RED post when working in FCP, and that Apple Workflow will have a major advantage over any other NLE, simply because it will remain the only one that is quicktime based.
Am I understanding this correctly?
IBloom
