Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Red Rocket Speed

J

Joel Mains

Member
Joined
Feb 15, 2011
Messages
7
Reaction score
0
Points
0
I'm working on and independent 3D feature. Have RED footage shot in 4K and are planning to post in FCP w/Neo3D. I'm needing to convert the footage to 2K (2048x1556 -- Cineform Codec) in RedCine-X and have rented a Red Rocket Card. I'm doing the conversion but these are still taking a lot of time (i.e. 10 minutes for a 2 minute clip.) and I'm not sure I'm going to get through footage in time.

I'm running on a 2.8 GHz 8 core Mac Pro, with 6 Gigs of RAM on OS 10.6.6
I've updated the firmware and drivers on the Rocket.

1) Is this normal time for the Rocket -- if so, I'll just relax and deal with it. (It's still faster than my NiVida was doing in ReMaster, but I've read posts about real, or slightly over real time encodes? What can this newbie to to make sure this is correct?

2) As this is all of our first time using RED, (other than the RED camera operator who is now onto other shoots.) I'm open to the barrage of, "what the heck are you thinking?" if it can keep us from some major mistakes down the road.

Thanks
 
I get pretty much realtime encoding to ProRes in REDCINE-X when using a RED ROCKET card, so it does sound like something isn't right.

Have you tried converting to ProRes to see if it is the Cineform encoding that is slowing things down?

Fire up Activity Monitor and look at your disk reads and writes... is all the available disk bandwidth maxed out?

What about CPU Activity? On an 8-core 3 GHz machine I've got every core running at about 70-80% while encoding to ProRes, and I think a lot of that processor usage is the ProRes encoding. If all your cores are maxed out, it could be the Cineform encoding that is slowing things down.

As for RAM, I've also got 6 GB and never see more than about 2-3 GB being used, so I don't expect that to be problem.
 
Hi Joel,

In addition to what Stephen has said, a quick test is to see if you are getting realtime playback in the viewer at full resolution. If you are, your bottleneck is most likely not the Rocket card.

Also, make sure you are using Build 356 from the support site, if you are not already.

David
 
What slot is the RR card in?

What are you transcoding to, over what bus?

Are the drives you're transcoding to fragged, have they been reformatted recently, are they new etc

Is it a brand-new Westmere Mac, or a Nehalem, and are you running the 32 or 64 bit version of RC-X?
 
Thanks for everyone's help! I'll try to take these as I can figure them out.
1) I'm using RedCine Build 356 (64 bit)
2) I'm NOT getting real time playback in the Viewer at full resolution, but Yes at 1/2.
3) RR is in Slot 2 over over the PCI bus
4) I'm sending the transcoding to a new 8TB drive in a Raid 5 (via FireWire 800)
5) My make is a 2008 model, so not brand new
Test
7) 1 min clip from 4K 4096x2304 transcoded to ProResHQ 2K (at 2048x1556) = 1:45
8) Same clip transcoded to Cineform 2K (at 2048x1556) = 4:45
9) When I look at my Activity monitor, I'm not anywhere close to 70-80% as you are,
ProRes = User = 30% System = 12% Idle = 57%
Cineform is User = 20% System = 9% Idle = 70% any tips on beefing this up?

Probably forgot something in there, but any ideas?
 
Why are you transcoding to 2048x1556? That's 1.3:1 and you shot 1.78:1. This is probably why it's taking so long to transcode. Try leaving your framing controls set to Fit Width (in other words, leave it at default settings), set your output resolution at 1920 x 1080 in your export settings, and see what happens. FCP will probably have to render everything in 2048x1556, it only works without rendering in a few resolutions and that ain't one of them I think...

Somebody will correct me if I'm wrong here, but unless your 2008 MacPro has the capability of booting in 64 bit mode, and you are holding down the 6 and 4 keys on start-up, then your computer is running 32 bit, and you might want to switch to the 32 bit version of RC-X.

Also transcoding to FW 800 might be slowing things up, you can get a 2 port eSata card for one of your PCIe slots for $35
 
Why 2048x1556?

Why 2048x1556?

2048x1556 is full 2K, and is a direct aspect match to 35mm. (That's off the AJA 2K white sheet at least.) I was pushing for using 1920x1080, as that is digital cinema standard, but the editor (who is currently burried editing a 2D ProRes image) feels like they are going to be doing a number of push-ins, for coverage, and doesn't want to lose the screen space if they have to shift the image up. I felt like I could reframe shots that we needed, but it didn't fly. I'm concerned they will need to do this all over if this is done wrong, but based on budget constraints I'm coming in later in the game.

Has anyone edited 2048x1556 in FCP? If it's not going to work, then this really seems like it's not the way to go, and I've only wasted three days of encoding. I'd rather stop now an do this right and not waste another day.

The desire is to get the best possible file for a 3D screening (say off a timeline). But leave the final 35mm conform to the studio if it gets picked up for distribution.

Thanks for the help, I've ordered the eSata card and will look into the 32 bit issue.
 
I also only get realtime playback in the viewer at 1/2 res, but my full-res transcodes run realtime.

For the times you've given, your ProRes transcode seems a bit slow compared to what I'm used to, but the Cineform taking nearly 3 times longer goes a long way to explain why it is taking so long overall. Cineform is a much more complex wavelet-based codec, than the DCT-based codec like ProRes.

It also looks like Cineform might not be taking full advantage of all of your cores while it's encoding. The CPU usage window in Activity Monitor is a great way of seeing if all cores are being utilized equally, or if only one core is maxed and all the others are virtually idle.

As Joe pointed out, you've got your aspect ratios all wrong. 2048x1556 is 1.3:1 and yes, that is 35mm 2K, but you didn't shoot 35mm - you shot RED. And your RED footage is 1.78:1 if it's 4096x2304.

You should be transcoding to 2048x1152. Otherwise, not only are you requiring a ton more computing power to do that odd scaling, you are also screwing up the aspect ratio significantly (unless it is cropping in on your frame or letterboxing, but I expect it would be running faster if that was the case.)

I'm sure you'll find your ProRes and Cineform encodes will both run a lot faster that way, although no matter what you do, the Cineform will always take longer.

I've never done 2048x1152 in FCP myself, but you should test it yourself - and quickly. As it stands, I think everything you've done up to now at 2048x1556 will indeed be a wasted three days of encoding. If you've never used a certain workflow before, you should test it before committing all of your time to it.
 
You'll definitely want to run the 64-bit version of RCX. It's still the best version to run even if you're booting a 32-bit kernel (which is the default on some machines unless you hold down 6 and 4 at startup like Joe said).
 
You guys rock! Okay, so I edit FCP like a fiend, but I'm basically always the same aspect ratio all the time. This type of thing is a stretch to get my head around. The director was told that "Hey, with 4K you can just push in when you need to." So he shot wide on a lot of shots. As I go through the footage some are larger files than others. (i.e.4K, 3K, 2K) Now the videographer was no slouch, and the 3D guys new their stuff, but budget ran out for 3D post. In comes me, a strong editor, who was asked to take over the 3D post. (Welcome to Independant films) Not how I'd have choosen it, as I'm learning everything the hard way. Is there a chart for aspect ratios? Should I assume even if they changed the file sizes, the aspect ratio should stay the same?
Sorry guys, I'm back to being a baby all over again.
 
Joel Mains said:
Should I assume even if they changed the file sizes, the aspect ratio should stay the same?
Sorry guys, I'm back to being a baby all over again.
Click to expand...

Yes, they should have stayed in the same project settings, which includes base framerate, aspect ratio and quality settings. They changed from 4k to 3k or 2k because they either shot slo-mo, or the lenses they used didn't quite cover the sensor.
 
Joel, it might be also that your harddrives are the limiting factor - giving the fact that you are not able to fully use all cores.
You said that you render to an external RAID5 via FW800.
And I guess the RAW footage sits on your internal drive, right?
Have a look at the activity monitor in the harddrive section. For the external RAID the maximum transfer rate over FW800 will be about 70 MB/s - that's slower than even a current single drive can transfer data. If activity monitor shows that, than you know whats the bottleneck.
 
RED Color Space in QT

RED Color Space in QT

Such a big help everyone. I'm looking into the drives. I was on another site, and the person said that "RED Cine-X can't wrap the QuickTime for Final Cut in 4:4:4 color space, (in CineForm Codec -- which I need for 3D) and that would hurt us on the back end for Color Correction." Yikes, is this correct?

Thanks.
 
Joel has been in discussion with the CineForm support team. The best solution if RedCine-X must be used is to output DPX, then batch convert those to CineForm 3D files. Remaster can be used for R3D conversions, but it is not RedRocket accelerated. The PC CineForm tools are RedRocket accelerated, where we can encode as fast as RedRocket produces frames.

As for speculation of CineForm native performance vs other intermediate codecs, that data more reflection a QuickTime implementation, not the codec itself. On the CineDeck the CineForm encoding takes less CPU for RT capture than all other intermediate codecs that product offers. Encoding 2048x1556 444 would be real time on a nice MacPro if QuickTime wasn't in the way. For this reason most vendors use our SDK.

For Color Correction, the new DaVinci tools are CineForm native, and I believe they now support the 3D modes. Color is just not even supporting QuickTime based codec. Additional chooses for CineForm native color correction is provide by Nucoda, BaseLight, Iridas, etc.
 
So, may I ask if ProRes really gets 10 bit (or 12 with ProRes 4by4) ?
 
Clarification . . . for the weak of mind.

Clarification . . . for the weak of mind.

David, thanks for the input, but I just need this broken down a bit. Since I don't know what "b64a" pixels are, I'm kind of scratching my head.

I read you are saying (post #15) if I'm going to use the Red Rocket, I need to output DPX, and then batch convert them back in Cineform ReMaster. Am I reading correctly? This seems like a path that will be no faster than than just starting in ReMaster in the first place. So, since I'm on a Mac, that doesn't seem like an ideal workflow for me.

Next you were saying, "CineForm, is actually a fast encoding process, (unlike the times Joel was talking about in his earlier posts) but it's the QuickTime" -- which I need to use if using FCP -- "that slows things down."
So most people use your SDK (i.e. ReMaster?) to do this encoding.

Then, you were saying if I want to Color Correct in FCP, "Apple Color itself doesn't even support QuickTime" (which is a fault IMO) so in a FCP workflow with CineForm you'd recommend any of the higher-end CC applications.

Finally in post #17, you seem to be saying, "Okay, in an updated version of RedCine-X, I did get b64a pixels." So, are you saying that RedCine-X actually does 4:4:4 color space in QuickTime?" Or is this a fully different issue the Uli brought up?

So, basically, and I'm probably going to sound like an idiot here, but my issue is, I'm renting a Red Rocket, I need to return it, or keep it for another week. The rental house speaks yes or no, dumb it down for me :). I need to know if (for our Mac, FCP, Neo3D workflow) it has any particular value for me if I need 2K QT files in 4:4:4 that Neo3D can currently utilize? Thanks for your help, and probable patience as I struggle to fully understand your comments.
 
Last edited:
Sorry to be switching back and forward on this, RedCineX is sending 'b64a' (16-bits per channel RGBA), but QuickTime is converting it to 8-bit before we can encode it. This is only happening on the Mac, PC versions are fine. There is bug in the way the QuickTime interface is initialized, we will write that up and report to Red (an engineer is doing that for me now.) However we are developing a work-around that shouldn't require a Redcine patch.

Now to your questions. If you want simple answers, support might be the way to go, but prefer the technically accurate, so sometimes it may seem geek speak (I try and reduce that.)

b64a = 16-bit per channel RGBA pixels.

DPX output is currently the quality way to extract data image data from RedcineX. It might be faster if you have a disksystem that is speedy. For real-time you will need a RAID that sustains 300MB/s.

FCP is using Quicktime, but decoding is less of a bottleneck than encoding. Most are using the SDK for decoding as well, simple because QuickTime has so many faults, like gamma changes and converting 16-bit data to 8-bit.

We can't recommend Color due to its limitations, but basically everything else works fine.

Today only the PC version of RedCine-X is successful rendering 444 pixel >8-bit into CineForm. We will recommend changes to RedCine to address this (it relates to how QuickTime is initialized for codec like ours,) but we are working on a patch ourselves to solve this (in a few days we hope.) The patch will be a checkbox something like "force 16-bit". We can't default this on, as that crashed FCP, seriously, QuickTime has many faults.

Keep the card if you output to DPX, return it today if not. As today you can't get the quality you need through RCX to CineForm. We intend to solve this shortly, not today.
 
David,

If you could send that report to me, that would be great.

david dot ibbitson at red dot com

Cheers,
David
 
You must log in or register to reply here.
Back
Top