Rocket support for Color - please help us test

[Rainer Fritz]

Thx Kaku for the Info....

Whats up with 4,5k WS Material? Do we get also Full Debayer and Rocket Acc. with this footage ? Very important....

 

[Kaku Ito]

I don't have 4.5K materials at this moment, I will ask Peter to give me some and let you know after checking.

 

[Nook Kim]

Peter says with Color, video outs from video I/Os should work... Nook, wait a minute, what time over there now? It's 1am in Tokyo.

Now it's 3am ;-).

I've just did a quick test with proper video out via Kona 3 to
my cinemage. Well, I should admit that I was a bit too quick to
express my excitement last night. With video out enabled, I'm
getting 14fps playback from the souce R3D in my FC storage that
gives about 650MB read speed. When I disable the video out,
I get about 22fps, which is not ideal for my work. I mean I can't
work without the video out.

Hmmm...

 

[Gavin Stokes]

Does whatever trick you guys are using to support the Rocket in Color get us any closer to Rocket-accellerated QT proxy playback? I remember one of the things preventing that was that QT only asks codecs to decode frames one at a time, and the Rocket needs to work with multiple frames for efficiency.

We're looking at Rocket acceleration for general QT; it's a question of payoff for the customers vs. the engineering time required. As more applications themselves gain Rocket acceleration, do you the customers really need a QT component for the shrinking number of apps that don't have it already? The question becomes even more important as we consider the limited lifespan of 32-bit QuickTime components in a soon-to-be-64-bit world.

It's working... There is a speed-up, but it seems to stutter more than without the Rocket enabled.

I suspect that there's a lot of memory allocation and deallocation going on in Color for these big frames; without Rocket acceleration, that activity wasn't apparent because rendering time was the limiting factor. I found that toggling the "Maintain frame rate" option back and forth (playing in between each switchover) seems to reduce the stuttering sometimes even when you've returned that setting to its original state.

 

[Chris Kenny]

We're looking at Rocket acceleration for general QT; it's a question of payoff for the customers vs. the engineering time required. As more applications themselves gain Rocket acceleration, do you the customers really need a QT component for the shrinking number of apps that don't have it already? The question becomes even more important as we consider the limited lifespan of 32-bit QuickTime components in a soon-to-be-64-bit world.

Fair point. But unless you guys know something we don't, it seems unlikely that 64-bit QuickTime will be arriving before 10.7, and unlikely that 10.7 will be arriving before Q4 2011. QT proxies that played back as smoothly as uncompressed HD (except without even the requirement for a RAID) sure would be handy to have before then. And if you could also support RMD from QuickTime, that would enable some seriously convenient workflows.

 

[Luca Immesi]

I've got 22 fps for 4k 16:9 files and 24 fps for 4k files resized in a 2k timeline, settings the proxy resolution to full. The playback is pretty good, the render is damned slow compared to rcx. As first rocket support I'm quite happy.

 

[Gunleik Groven]

Fair point. But unless you guys know something we don't, it seems unlikely that 64-bit QuickTime will be arriving before 10.7, and unlikely that 10.7 will be arriving before Q4 2011. QT proxies that played back as smoothly as uncompressed HD (except without even the requirement for a RAID) sure would be handy to have before then. And if you could also support RMD from QuickTime, that would enable some seriously convenient workflows.

Sounds good to me!

+1

 

[Rob Lohman]

Thanks for the testing and feedback guys. We're gonna take a look at video out speed, but there's lots of constraints we have to work with, unfortunately.

Rocket QuickTime codec acceleration is just not going to happen. QuickTime is doing I/O for codecs and thus our codec has no access to the original R3D (it doesn't know where the R3D is located). This means we cannot locate the RMD sidecar file either. But, you can regenerate the QuickTime reference files in REDCINE-X with new image processing settings (RMD settings basically).

What will be coming down the pipe is better multi threading support for our codec. This will make it possible to playback our QuickTime files at a higher resolution with higher framerates for Mac Pro's with many CPU's in them.

We're always trying to find ways to improve workflow and getting upgrades and new tools in the hands of our customers. QuickTime just doesn't always allow for that! Also, the question is how long QuickTime 7 is going to be around for, and what will, or will not, work with QuickTime X, now and in the future (QT X and 10.7 were very absent at WWDC this year).

If we can find a way to get better tools to you we're going to make it happen. I hope this Rocket color update and support for REDlog Film in the final release shows this.

Thanks everyone!

 

[Gunleik Groven]

RLF is the best thing since... redraw... -

Thanks Rob!

 

[Chris Kenny]

Thanks for the testing and feedback guys. We're gonna take a look at video out speed, but there's lots of constraints we have to work with, unfortunately.

Rocket QuickTime codec acceleration is just not going to happen. QuickTime is doing I/O for codecs and thus our codec has no access to the original R3D (it doesn't know where the R3D is located). This means we cannot locate the RMD sidecar file either. But, you can regenerate the QuickTime reference files in REDCINE-X with new image processing settings (RMD settings basically).

Regenerating proxies with new look data is pretty much just as good as RMD support. If the only issue with Rocket support in QuickTime is that you can't do read-ahead tricks because you can't directly load the file... I'm imagining devious tricks like having RCX embed the HFS+ catalog ID for the file in the QuickTime metadata (where I assume it could get passed to your codec, like the look metadata you store there).

But I fully admit I have no idea what I'm talking about.

What will be coming down the pipe is better multi threading support for our codec. This will make it possible to playback our QuickTime files at a higher resolution with higher framerates for Mac Pro's with many CPU's in them.

I appreciate the commitment.

 

[Kaku Ito]

Now it's 3am ;-).

I've just did a quick test with proper video out via Kona 3 to
my cinemage. Well, I should admit that I was a bit too quick to
express my excitement last night. With video out enabled, I'm
getting 14fps playback from the souce R3D in my FC storage that
gives about 650MB read speed. When I disable the video out,
I get about 22fps, which is not ideal for my work. I mean I can't
work without the video out.

Hmmm...

That's what I thought. The best solution right now is to use DVI or HDMI capable display as the second monitor, switch to the dual monitor mode, then enable full screen view when you want to playback. This way you can even calibrate with EyeOne, too. As long as what we see on Color viewer would be rendered the same then it could be good.

It seems to give the best performance at 8-bit pixel format setting (naturally) then switching to 10 and float would make it stutter more. But the 8bit is pretty much smooth. We can work with float then switch to 8 bit to playback for now.

 

[Kaku Ito]

Mine is working 23fps at 8bit.

EDIT:

Correction, somehow it shows 24fps with float pixel format with 4096 x 2304 material and the project with full debayer. I'm gonna dig into calibrating my consumer plasma.

Also, our staff Suguru pointed out while panning, high contrast area shows shifting in color while playback but not when it stopped. It seems that GPU is not catching up or something. Can this be eliminated when optimized? My GPU is 4830 at this point and I will try with 285 later.

More report:

I rendered a R3D footage to DPX and ProRes422HQ, and I see a slight gamma shift. With DPX, the range from 20% to 40% changes slightly, but the not really noticeable on the monitor, but the ProRes422HQ shifts more and I notice the slight difference.

 

[Daniel Dávila]

NOT WORKING

NOT WORKING

When Rocket activated in System Preferences, Color frozens while opening the project with the R3D's. Disable Rocket and the project opens (without rocket support, of course). Mac Pro 2009 8GB rocket on PCI #2 (16x).

Any ideas?

Thanks,

 

[Kaku Ito]

Things to check are:

The firmware and the driver for the RR
Obviously the new RED installer for the Color

But actually, I never opened a previously edited Color project file with R3D yet.

 

[Rob Lohman]

When Rocket activated in System Preferences, Color frozens while opening the project with the R3D's. Disable Rocket and the project opens (without rocket support, of course). Mac Pro 2009 8GB rocket on PCI #2 (16x).

Can you copy & paste what's in the plugin's log (see the first post on the thread) when you have the Rocket enabled and Color hangs?

 

[Daniel Dávila]

It's odd, I left the computer half an hour turned off and coming back Color worked fine. If it happens again I'll send you the log.

Thanks!

 

[Sean Rawls]

Sweet. Love the unexpected bonuses. Updates to Color's Red Tab would be nice, but this really keeps Color useable with all this new competition.

Keep rolling team RED!

 

[Kaku Ito]

Rob,

The color shift we see, is this the performance of GPU dragging?

 

[Nook Kim]

Conflict with Kona-3 or FCP..

Conflict with Kona-3 or FCP..

Important thing to report:

I was impressing my regular client with speedy render last night on a music
video. After the render I was getting the dropped frames warning on FCP
that I'd never get (okay, maybe once in every year). I tried everything
I knew about that error message.. for about an hour while my client was
waiting to see the final output with the music.. Every 5 second or so, I'd
get that message.

Finally, I don't know why it didn't occur to me sooner, but I decided to pull
the RR from my system. Viola! That message gone. Oh, before this, I switched it off on the system setting, but didn't help.

Please look at this..

 

[Dan Graetz]

Important thing to report:

I was impressing my regular client with speedy render last night on a music
video. After the render I was getting the dropped frames warning on FCP
that I'd never get (okay, maybe once in every year). I tried everything
I knew about that error message.. for about an hour while my client was
waiting to see the final output with the music.. Every 5 second or so, I'd
get that message.

Finally, I don't know why it didn't occur to me sooner, but I decided to pull
the RR from my system. Viola! That message gone. Oh, before this, I switched it off on the system setting, but didn't help.

Please look at this..

That's interesting Nook. I've been pulling my hair out for...now that I think about it...every since installing RR...with sync issues and dropped frames in FCP. I have a Kona 3 also. Thought the problem was related to my machine but I'm now on a brand new 12-core with a fresh install and the issues continue. First thing tomorrow I shall reluctantly pull my beloved RR card and see if things improve.

Gavin/Rob - don't spose you've heard of similar issues with RR and Kona3?