R3D in Premiere CC

So one of my colleagues has been working with some R3D cine stuff at one of my jobs in FCP7 and it had to go out for grading, and there was a whole thing with consolidating the transcoded ProRes sequence and setting up relinking options for all the raw stuff which was a bit of a pain, so I decided to bring some of the files home to try them on my Premiere rig.

To my amazement, I could import the R3D 4k files without any kind of transcode and play them immediately in Premiere. On my stock standard iMac. Off a USB drive.

Playback was chunky, but holy cow. That's just .. wow.

In the end I did a render to improve playback, but I have to say I was blown away that it worked at all.

Hey Jude, have you tried lowering the playback resolution? This native thing is just mind blowing. I had a session cutting 5K R3Ds in a 1080p timeline at half rez on a MacPro with good GPU and it was quite amazing. It could play over dissolves without rendering and a blur effect. No dropped frames. Dynamic trimming wasn't fantastic, but overall it is very sweet.



www.strypesinpost.com

Oh, no I didn't think of that. You're right though, I usually run at full res, which would be a struggle for this system on native 4k. I'll give it a shot. But still, I was .. 4k! Native RED! Imac! USB Drive! How is this possible?

And yup - at half res my 25 minute timeline plays fine without render, but I have moved the clips to the main hard drive now, so not sure how it would be running off USB. Not that I care too much, since I wouldn't do that as a rule.

I still get a buzz when I'm cutting R3D native, which is why you have probably seen me defend native editing as much as I do. Coming from the days when I used to spend about an hour doing a full debayer on a handful of R3D footage, to being able to cut R3D almost like it was ProRes and doing it in front of clients.. It's absolutely unbelievable. And I'm not just talking about playback, but also the fact that I can scrub through a sequence.



www.strypesinpost.com

Yep, Premiere's ability to cut almost anything native is one of its great strengths. The time you save by avoiding transcoding especially with red footage is fantastic.

Has anyone cut a long form RED project in Premiere? I cut a 15 minute short and the project file ending up being 100+ mb, so i'm kind of concerned that on a longer project one could end up with a 500-900mb project file, which I could only imagine leading to trouble.

> I cut a 15 minute short and the project file ending up being 100+ mb, so i'm kind of
>concerned that on a longer project one could end up with a 500-900mb project file

Were you cutting that project in Premiere Pro CS6? There has been changes to the Premiere Pro project file in CC and project files are now much smaller. Last project I worked on with over 4TBs of DvcproHD and ProRes footage turned out to be much smaller (under 10MBs), and I had 8 half hour episodes in one project file.

One thing about project file size, media types, RAM and overall stability of an edit system, is that they are separate issues. I'm talking about this in a very general sense. It is impossible to load 4TBs of R3D footage in its decompressed state into only 32GBs of RAM. What a project file does not care about is the type of media that is in the project. By that, I mean that a project file primarily acts as a database and stores the relationship between clips in a project, metadata (such as log notes, etc), and this database is loaded into RAM. FCP can get very crashy with a lot of media and complex clip relationships (multicam), partly because it could only access 2.5 GBs of RAM out of the maximum 4 GBs of RAM that it can actually use. Usually when you load an FCP project, the entire project is loaded into RAM. The same goes for Premiere. This is why you can load an FCP project, delete the project file from disk and continue working until you decide to save the project. This is also why more RAM helps prevent crashes on long form projects, or in FCP's case, as much RAM until you hit the 4GB ceiling. Premiere's case is different as it's a 64 bit app.

RAM is also used to stabilize a bunch of other processes such as real time video decoding, rendering, etc.. So when you play processor intensive media, a lot of data is being stored in RAM, to keep the system stable, because RAM is temporary high speed memory and provides faster to the data than needle and spindle drives. Over a period of time the OS will free up the RAM it feels it doesn't need. When it doesn't, that's when you get memory bloat, which can be seen on the blue portion of the RAM chart when you call up Activity Monitor. In general, I would always recommend using an app such as AtMonitor if you are working with processor intensive applications and purge the RAM every now and then if you see that it is getting filled up.

So yes, although both processes use up RAM, the amount of media stored in a project file and type of media are not directly linked to each other.

This may sound fairly simple but it's not, and there are a lot of other background processes involved, but just so you know, having 20 hours of R3D in a project file doesn't necessarily make a project more or less crashy than having 5 hours of R3D in the same project file if your system has enough RAM to handle it. FCP7 is a different story because it is almost entirely a 32 bit app which began life in the late 1990s and was never designed to work natively with such media in the first place.



www.strypesinpost.com

Thanks for the info Strypes, yes it was CS6.