FCP 6.01 and redcode raw

[Simon Blackledge]

..Is it working now? is it just a codec we need?

if so, when is it going to be freely available?

I take it exporting via fcp from redcode raw is a no-no ?


So many q's! :)

s

[David Battistella]

..Is it working now? is it just a codec we need?

if so, when is it going to be freely available?

I take it exporting via fcp from redcode raw is a no-no ?


So many q's! :)

s

Flame.

From what I understand Red Alert installs the QT component on your machine. This means it is an accessible codec like anything other on on your mac. THis is why the guys were able to post a 2K H.264 movie they made last night.

Since this is the case, you could be exporting to other codecs too, so if they wanted to start editing in FCP I am sure they could set up a timeline with REDCODE or transcode to any codec (in the meantime) to edit the footage. There was no TC on teh H.264 movie.

I am pretty sure this will flush out in the next few days.

The power of REDCODE will be the ability to edit proxies, relink to 4K or 2K masterclips, never having to create additional copies of the shot material (besides the back up of course).

When people realize that this workflow is occuring in data rates close to that of SD, then we will see the RED post revolution.

What I am getting at here is:

I am sure you will see many people color correcting 2K redcode on FW 800 drives and sending DOWNCONVERTS of that sequence (VIA KONA) 1080P to HDCAM SR masters. The 2K could go to a filmout. A one hour show will be about 120GIG.

This is going to change everything. It will be 35mm quality in a DVCPRO HD sized workflow.

Crazy!!!!



David

[Simon Blackledge]

Crazy.. and Now :)

[Adrian T.]

FCP works! Read here:
http://www.reduser.net/forum/showthread.php?t=4142

[David Battistella]

FCP works! Read here:
http://www.reduser.net/forum/showthread.php?t=4142

This is exactly why it's going to be a post revolution as well. It will be nice to see the first RED to filmprint when the films shot this summer come out.

David

[Rob Lohman]

Yes, it's working now. Current codec only does decompression.

[Simon Blackledge]

Possibility of re-compression later? for archive maybe ?

s

[David Battistella]

Yes, it's working now. Current codec only does decompression.

Thanks Rob.

It's good to know that it is only one way at the moment. Could this codec be used in "other" HD and standard def workflows when it is fully enabled?

David

[Nick Shaw]

Since 1k 16x9 is 1024x576, in theory a REDCODE quarter rez Quicktime shot at 25 fps should be editable in real time in a PAL 16x9 ProRes timeline in FCP 6 (same number of scan lines, so only horizontal scaling by FCP required) and monitored on a broadcast monitor with an AJA or Decklink card. Graeme/Rob, does this work?

[Rob Lohman]

Haven't looked at all that stuff yet, that will happen later.

[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.