FCP 6.01 and redcode raw

[sbaechler]

If you cannot recompress then you will not be able to add titles or effects to your project and stay native.

Right now I assume most people will take their Final Cut Projects with media to a post house and output to HDCAM or HDCAM SR. And DVD so they can give it to their client / friends. :)

[Stokestack]

If you cannot recompress then you will not be able to add titles or effects to your project and stay native.

Once you change the image, there's no value in "staying native" in a lossy format (except maybe to avoid mixed codecs in a timeline). That just adds another generation of compression. And remember that you'll add yet another if you write out the material to a delivery medium like HDCam.

Once you alter the camera-original images (in a way that can't be reproduced on the fly in your NLE or color-correcting system), you should archive to an uncompressed or lossless format.

The idea of compression with Redcode does bring up an interesting question, though: Is the codec going to reBayer the incoming RGB data?

[Rocco Schult]

Recompress is opposite to native.
REDcode makes much more sense in my opinion to be a source codec compared to Cineform for example.
Re-Encoding might be of interest for compositings though.
Wonder if there will be a colaboration between RED and Cineform. Would love to see that. Joined forces.

[Chris Kenny]

Once you change the image, there's no value in "staying native" in a lossy format (except maybe to avoid mixed codecs in a timeline).

That's sort of a big deal, though, because it's the way Final Cut works. Except for a couple of special cases, there's no way to set one codec as the native codec for a timeline, but then have FCP do rendering in that timeline to a different codec.

And going lossless or uncompressed for renders would be impractical for a desktop indie workflow even if FCP did make it more convenient. The rendered clips would have data rates high enough to require a fairly high-end RAID setup to play.

The ideal case for desktop finishing with Red footage is that Red develops a single QuickTime component which decodes REDCODE RAW, which can also encode to REDCODE RGB (with data rates in the same ballpark), and which can hide the distinction between the two of these from apps which use the codec. This would let you toss REDCODE RAW clips on a timeline and edit with them normally, rendering things when necessary, without ever having to deal with huge data rates. As far as I'm aware this is still the eventual plan.

[Nick Shaw]

Except for a couple of special cases, there's no way to set one codec as the native codec for a timeline, but then have FCP do rendering in that timeline to a different codec.

I wonder whether Apple may extend the 'use ProRes for rendering' option currently only available for HDV and XDCam HD to be available for any codec. Since ProRes is highly optimised for RT playback, it might well make sense.

Currently (as in what was shown at IBC) the REDCODE QT component is decode only, but FCP sees encoding as available. This is probably just a temporary cheat to allow REDCODE to be set as the timeline codec.