RED Rocket

[Stephen Gentle]

Will Redrocked by the same card for mac and Pc?

thanks

G

I don't see any reason they would be different.

[Jarred Land]

yes same card...

[Gabriele Turchi]

well sometimes they are not the same (Graphic card for example...)

Good to know that will be the same.

Thanks

G

[Shane Betts]

OK, almost halfway to the earlier expressed sale date. Are we still looking good for late June? (Not that anyone's counting the days or anything)

[Adam Glick]

OK, almost halfway to the earlier expressed sale date. Are we still looking good for late June? (Not that anyone's counting the days or anything)

One quick question, Shane - what are you going to DO with the Red Rocket device assuming you get your hands on one in June?

There is no software vendor support for this device. There have been no announcements made about software vendor support for this device. As far as I can tell, none of the software vendors has ever seen a Red Rocket card or the required SDK -let alone begun to develop plugins or support for it.

We're all looking forward to learning more about Red Rocket - it could seriously change everything about how RED post gets done. And then again, there is a great chance that it may not.

In any case, it's helpful to remember to put timelines into perspective and consider the realities of delivering a working product that's ready for your production work. Regadless of when the first Red Rocket cards are "shipped", a working Red Rocket-based solution could -and IMHO is- many months away.

Adam
BOXXlabs

[jimhare]

Adam,

Even if it only worked with RC, RA and RR, this would be a must have for anyone working with large amounts of footage from the beginning.

I process about 12 hours of 4k at a time from 7 cameras on 2 Mac Pros running 24-7. Red Rocket will be a dream come true for me from day one, even if it only works with Red apps.

Jim

[Adam Glick]

Adam,

Even if it only worked with RC, RA and RR, this would be a must have for anyone working with large amounts of footage from the beginning.

I process about 12 hours of 4k at a time from 7 cameras on 2 Mac Pros running 24-7. Red Rocket will be a dream come true for me from day one, even if it only works with Red apps.

Jim

You're assuming that Red Rocket will be helpful in dramatically decreasing your transcode times for HD or 2K deliverables. I havn't seen or heard anything yet to make me think that it will.

[jimhare]

Excellent point.

I have been thinking about this very thing since the announcement and I agree, if it is playback only it's use will be limited.

Hard to believe this would be the case. After taking all the pressure off the CPU to debayer, you would think it would pass the data on.

Looking forward to clarification on this.

[Harry Lipnick]

I realize RED has not officially announced any formal plans for software vendor support, but you've got to figure they've been working on it. RED has proven time and time again that they're not a dumb company, and certainly not one that would release a $5000 dollar card without the programs to drive it.
Now I understand your concern, and of course my assertion is pure assumption, but to paraphrase Jim, "Sleep tight, they're on it."
Peace,

-Harry

[Lee Saxon]

You're assuming that Red Rocket will be helpful in dramatically decreasing your transcode times for HD or 2K deliverables. I havn't seen or heard anything yet to make me think that it will.

This isn't a $250 mass market gaming graphics card. Nobody in the market for a $5000 hardware accelerator is dumb enough to buy one that doesn't work therefore only an idiot would build and try to sell a $5000 hardware accelerator that doesn't work. Looking at Oakley, RedOne, RPP, I think it's safe at this point to assume that Jim Jannard is no such idiot.

The proof you seek will be offered once the thing is ready. More importantly, no one is asking or expecting you to fork over your money before you've seen that proof. Calm down.

Edit : dudeguy37 we were both typing basically the same post at the same time! haha

[Harry Lipnick]

dudeguy37 we were both typing basically the same post at the same time! haha

Nice.
Peace,

-Harry

[Steve Sherrick]

Just to sum up Jim and Jarred's info on RED Rocket, as that's what we have to go on. Everything else is conjecture.


RED Rocket.

R3D Decode, debayer and playback high quality REALTIME 4k at 30fps (or 5K at 25fps).

Will accelerate FCP, Premiere, After Effects, RED Alert!, REDCINE, REDrushes or any application using the REDCODE SDK.

PCI-Express, Output interfaces will include Quad-DVI and Quad-HD-SDI. Works with Mac, PC and Linux.

Under $5k.


Yes to 5k@25fps.


About two months...


The RED Rocket can be driven by any application that uses the RED SDK.

Assimliate/Scratch has just confirmed that they will support the card on arrival.



Full specs well before delivery... best we can do right now.


It will be PCI-E


Just think of it as an r3d REDCODE SDK accelerator. Final details before we take orders.

[tillHavis]

Just one observation, for tv work (ER, Discovery, TV Pilots/Dramas etc.) final output is normally to a Sony HD CAM deck. I hope the Rocket will allow direct output to decks such as the Sony HD Cam, Panasonic D5 and Digibeta without having to go back and use an AJA or Blackmagic Cards. These Decks are still the chosen method for most tv broadcast and will be for a while, why not integrate this final step into the Rocket workflow.

Just my 2 cents.

[Roberto Lequeux]

Nice work Steve. Thank you for that. While it is (might be) fresh in your head, what was the time-stamp on the two month post?

[Steve Sherrick]

Nice work Steve. Thank you for that. While it is (might be) fresh in your head, what was the time-stamp on the two month post?

April 22nd 12:03PM
May 1st 10:52PM

[Roberto Lequeux]

Thank you. And wow... time flies. June 22nd is so very close.

DSMC release is also getting close... I hope things are working out smoothly.

[Shane Betts]

One quick question, Shane - what are you going to DO with the Red Rocket device assuming you get your hands on one in June?

There is no software vendor support for this device. There have been no announcements made about software vendor support for this device. As far as I can tell, none of the software vendors has ever seen a Red Rocket card or the required SDK -let alone begun to develop plugins or support for it.

We're all looking forward to learning more about Red Rocket - it could seriously change everything about how RED post gets done. And then again, there is a great chance that it may not.

In any case, it's helpful to remember to put timelines into perspective and consider the realities of delivering a working product that's ready for your production work. Regadless of when the first Red Rocket cards are "shipped", a working Red Rocket-based solution could -and IMHO is- many months away.

Adam
BOXXlabs

Yes, we are all looking forward to learning more - and that's not going to happen with it in LA and me in Melbourne. As others have pointed out, even if it allows me to view RedCine on a monitor it will be of huge benefit. You're also failing to acknowledge that things like the FCP plug-in were actually written by Red - not Apple - so if Red knows what they're doing, they will release these around the same time. Another point is that Deenan has mentioned the demands of flowing data back from the card to the bus, indicating the card may in fact be able to deliver an RGB stream to devices other than a monitor.

Everything at this stage is conjecture but we will know more once it's delivered. Jim mentioned two months at NAB time and I've seen how quickly products can be brought to market during my time with BMD. I'm just itching to get a couple of these things and see how it will impact on our future purchases. Maybe that might include some Boxx boxes in which to house it:-)

[Steven Caesare]

One quick question, Shane - what are you going to DO with the Red Rocket device assuming you get your hands on one in June?

There is no software vendor support for this device. There have been no announcements made about software vendor support for this device. As far as I can tell, none of the software vendors has ever seen a Red Rocket card or the required SDK -let alone begun to develop plugins or support for it.

We're all looking forward to learning more about Red Rocket - it could seriously change everything about how RED post gets done. And then again, there is a great chance that it may not.

In any case, it's helpful to remember to put timelines into perspective and consider the realities of delivering a working product that's ready for your production work. Regadless of when the first Red Rocket cards are "shipped", a working Red Rocket-based solution could -and IMHO is- many months away.

Adam
BOXXlabs

While we obviously don't know the details, Steve Sherrick's quote in his post regarding the RED SDK is likely significant.

If the original SDK provided the decoding libraries (as .DLL's, .NET assemblies, etc...) that were then redistributed with end-user products (as is often the case) that worked with .r3d files, then there is an abstracted interface in to the .r3d file manipulation routines that can be easily upgraded in the field.

That is, it's likely that existing products using the SDK call a function such as "DebayerR3DFrame" and pass it frame(s) from the .r3d file. That function is implmented in a .dll that accepts the frame, performs the required math on the CPU, and returns an RGB frame to the application.

Red could easily distribute an update with the REDRocket that updates the installed version of the SDK libraries/.DLL's installed on the machine the Rocket is installed in. These libraries then accept the bayer frames from the app, and instead of decoding them on the CPU, pass them to the Rocket for decode, and return the RGB results to the calling application.

In this way anything that already makes proper use of the RED SDK automagically takes advantage of the Rocket. This also sheds interesting insight on RED's insistance some time back that using a common supported method for decoding .r3d files was in everybody's best interest, as opposed to some 3rd parties opting to implment their own routines.

-Steve

[Jarred Land]

In this way anything that already makes proper use of the RED SDK automagically takes advantage of the Rocket. This also sheds interesting insight on RED's insistance some time back that using a common supported method for decoding .r3d files was in everybody's best interest, as opposed to some 3rd parties opting to implment their own routines.

-Steve

There usually is a method to our madness, believe it or not. :)

[Steven Caesare]

There usually is a method to our madness, believe it or not. :)

Indeed.... just trying to remind those with short (or bitter) memories. :thumbsup:

[Adam Glick]

Everybody's points are well-taken. These approaches would make a ton of sense. The benefits of Red Rocket-enabled software tools with some of these technological underpinnings clearly will be of great benefit for many needs and workflows.

Be that as it may (and back to my original point a few posts up), I still have not heard anybody explain how Red Rocket could do much to speed up transcode times for HD or 2K deliverables much more than can already be done currently.

I am also a little curious that we've heard nothing about how a Red Rocket-enabled would approach the specifics of color correction and image scaling, etc. Practically ALL of the software apps for editorial, VFX and DI workflows now utililize "pixel shaders" or other methods which make calls to the system's GPU for handling color correction, etc. I guess I am having a problem conceptualizing how to to keep data moving freely assuming software venodrs are unwilling to change how they are handling this part of the image processing.

Imagine a round trip that the data might need to make: from host system-->to Red Rocket-->back to host system-->to GPU-->back to system-->back to Red Rocket for SDI encoding, metadata insersion, etc.

Am I way off base here? ;)

**edit** - in fact, how would the system keep track of R3D metadata at all in this scenario???

**edit #2** - ah right - I guess the SDK would handle this of course. duh.
(note to self - no more posting to the board after multiple beers)

[Kyle Mallory]

To really be of benefit, for compositing and secondary color correction, you'll need this pipeline anyway... I don't see it being a problem.

[Steven Caesare]

Everybody's points are well-taken. These approaches would make a ton of sense. The benefits of Red Rocket-enabled software tools with some of these technological underpinnings clearly will be of great benefit for many needs and workflows.

Be that as it may (and back to my original point a few posts up), I still have not heard anybody explain how Red Rocket could do much to speed up transcode times for HD or 2K deliverables much more than can already be done currently.

I am also a little concerned that I've heard nothing about how a Red Rocket-enabled would approach the specifics of color correction and image scaling, etc. Practically ALL of the software apps for editorial, VFX and DI workflows now utililize "pixel shaders" or other methods which make calls to the system's GPU for handling color correction, etc. I guess I am having a problem conceptualizing how to to keep data moving freely assuming software venodrs are unwilling to change how they are handling this part of the image processing.

Imagine a round trip that the data might need to make: from Red Rocket-->back to host system-->to GPU-->back to system-->back to Red Rocket for SDI encoding, metadata insersion, etc.

Am I way off base here? ;)

**edit** - in fact, how would the system keep track of R3D metadata at all in this scenario???

AFAIK, all color correction/picture manipulation packages operate on RGB data. Even something that ingests native .r3d bayer files (i.e. REDCine, Scratch, etc...) is internally converting to RGB in order to than apply the proper correction in a specific color space. (please correct me if I'm wrong...)

So there already today exists the debayer --> correct --> output dataflow internal to the application, regardless of how apps choose to do some of the steps (CPU vs. GPU, etc...). In this case, the discrete step of debayer to RGB simply takes place on the dedicated Rocket hardware, rather than being handled on the CPU/GPU. And given that the Rocket will allow REAL TIME 4K debayer (something not possible on today's CPU/GPU machines), whatever performance hit that may be incurred for a PCI-Express bus trip to the card and back is more than offest by the horsepower the Rocket packs.

As for metadata, why should it change from the way it's handled today? Your application passes the .r3d data (bayer image + metadata) to the Red SDK routines, and it returns RGB data with your metadata applied. Today it does this via software on the CPU. Certainly the Rocket will have hardware support for doing the same, and the SDK libraries will pass that data to the hardware transparently to you.

The point of all of this is that software vendors using the SDK likely WON'T have to change what they are doing today. Those that may not being using the SDK interfaces (Scratch perhaps, as it might implement the debayer natively.... Adobe's stuff is recent enough that undoubtedly RED has a plan in place with them) might have to ship an update.

The nicely baked RGB you get back from the hardware will be indistinguishable form the SW flavor (except that youll get it all back with your evening scotch*, rather than waiting to see it with your morning coffee).



-Steve

* Hi Graeme!

[Brian Broz]

Hoping we'll have an update soon on more features and specifications...

I'm sure lots of people are standing by (like me) to build a Mac Pro / Red Rocket system.

[Michael Neborak]

This is probably a stupid question considering it may have been answered earlier in this post, but will the Red Rocket speed up the render time of REDrushes if I was to render out a 4k file into a 422 mov file and by how much? (I ask this because it says real time for some applications, so does that mean the render time would be the video length?)

[JD Marlow]

There is a big difference between real time playback of an R3D (or proxy file) and a real time transcode. Perhaps I'm missing something, but I've yet to see this subject really get talked about too much. That is, the subject of the Rocket card playing a significant role in the transcode process for something like RedRushes or Monkey Frame Extract.

Of course, the idea here is that you wouldn't need to transcode your "dailies" if you had a Rocket card installed. Depending on your workflow, you could work natively until your final deliverable needs to be created, depending on what that would be.

[Tim Whitcomb]

There usually is a method to our madness, believe it or not. :)

And it is even more interesting that the timing of the RED ROCKET release appears to coincide with the new FCP 3 release (rumored heavily to be fully 64 bit and will be tuned to leverage Snow Leopard)

Snow Leopard locked the API's and is in final beta, meaning developers can
now work with grand central and not worry about changes.

I think the safest best is to say that the summer of 2009 going to be VERY interesting indeed

[Axel Mertes]

We all will see what RED Rocket will do and if they can match that timeframe of two month.

I would not speculate to much at this point. Two month isn't far away, so waiting for it will tell us more.

Clearly I wonder which kind of host system would allow us to send a ~40 MByte/s R3D stream into the RED Rocket card, return uncompressed RGB debayered with RED algorythm in hardware at ~1.5 GByte/s, process that in the host in *realtime* (another 1.5 GByte/s "creation copy") and finally sending the results out to the RED Rocket once more to output via its 4 * DVI or 4 * SDI outs, ie. sending another 1.5 GByte/s.

This easily totals in >4.5 GByte/s data transaction, if not more if you have to send it through a GPU for instance. Imagine: We have not saved back the results to disk at that speed yet...

I hope the new dual 3.2 GHz Nehalem will do... What else is the choice?

Axel
PS: Will RED Rocket do RED RAY encoding in realtime?

[Curran Giddens]

PS: Will RED Rocket do RED RAY encoding in realtime?

I would think that the best quality RED RAY encoding would not be realtime. It may be realtime at a lower quality. But to get the best quality, the encoding is usually done in two passes.

[Adam Glick]

...
Clearly I wonder which kind of host system would allow us to send a ~40 MByte/s R3D stream into the RED Rocket card, return uncompressed RGB debayered with RED algorythm in hardware at ~1.5 GByte/s, process that in the host in *realtime* (another 1.5 GByte/s "creation copy") and finally sending the results out to the RED Rocket once more to output via its 4 * DVI or 4 * SDI outs, ie. sending another 1.5 GByte/s.

This easily totals in >4.5 GByte/s data transaction, if not more if you have to send it through a GPU for instance. Imagine: We have not saved back the results to disk at that speed yet...

I hope the new dual 3.2 GHz Nehalem will do... What else is the choice?


That's a great question.

Theoretically, the new intel Nehalem microarchitecture will accommodate this massive data throughput across it's new "QPI" (Quick Path Interconnect)

QPI is essentially a replacement of the old "front side bus"
You can find out more about QPI here (http://en.wikipedia.org/wiki/Intel_QuickPath_Interconnect)

Do note that the speeds listed here are supplied by intel and are "theoretical" in nature. No system will see anywhere near 32GB/s of internal bandwidth between PCI slots and the hosts system's memory or CPU's under normal use.

it'll be interesting to see how all this shakes out. ;)

[Bob Torrance]

This easily totals in >4.5 GByte/s data transaction, if not more if you have to send it through a GPU for instance. Imagine: We have not saved back the results to disk at that speed yet...


Was the DVS clipster at NAB perhaps doing this? It was outputting r3d files to a 4K monitor in realtime (at full quality). I don't suppose RED would speak to this but it was very impressive.

Bob Torrance

[Tim Whitcomb]

Was the DVS clipster at NAB perhaps doing this? It was outputting r3d files to a 4K monitor in realtime (at full quality). I don't suppose RED would speak to this but it was very impressive.

Bob Torrance

thats what i want to know too. all I do know is im waiting on a lot of post
purchases until July.

[Shane Betts]

I can't help but wonder if Red Rocket will operate as a downstream device, leaving the CPU to handle the job of finding and sending the data to the card based on pixel address? Although I guess that if that were the case it would be basically acting as a graphics card and would need to have OS calls written for it as well handling pixel shading. Hmmm. Or does it need to send the 4k stream back to the CPU from the PCI bus or just onto other devices on the bus, like the GPU for instance?

Ahh, the classic pastime of Red Speculation. As has been said before in this thread, it's hard to believe that Jim & Co haven't thought it through and come up with something outside the box to make it work.

[Steven Caesare]

We all will see what RED Rocket will do and if they can match that timeframe of two month.

I would not speculate to much at this point. Two month isn't far away, so waiting for it will tell us more.

Clearly I wonder which kind of host system would allow us to send a ~40 MByte/s R3D stream into the RED Rocket card, return uncompressed RGB debayered with RED algorythm in hardware at ~1.5 GByte/s, process that in the host in *realtime* (another 1.5 GByte/s "creation copy") and finally sending the results out to the RED Rocket once more to output via its 4 * DVI or 4 * SDI outs, ie. sending another 1.5 GByte/s.

This easily totals in >4.5 GByte/s data transaction, if not more if you have to send it through a GPU for instance. Imagine: We have not saved back the results to disk at that speed yet...

I hope the new dual 3.2 GHz Nehalem will do... What else is the choice?

Axel
PS: Will RED Rocket do RED RAY encoding in realtime?

Well, PCIe v2.0 does 500MB/s per lane theoreaical max. So a x8 or x16 lane (a x4 lane is probably a little too close for comfort with overhead), shouldn't struggle too hard to do this.

And, as Adam mentioned, the QPI architecture is pretty beefy.

I don't think internal bandwidth will be too much of an issue. It will be whatever manipulation that the CPU/GPU need to do for the actual correction/preocessing that may be a bottleneck..

Jim did mention that that Rocket has quad video outputs on it... so realtime should be there if you are playing a .r3d with metadata correctons. For other apps (FCP, etc...) he said "accelerated", so there are likely some constraints depending on what the app is doing outside the RED SDK.

[Axel Mertes]

thats what i want to know too. all I do know is im waiting on a lot of post
purchases until July.

I can confirm that it plays R3D in realtime. Just played with it on my own recently in private demo session. And surely it can write back to disk rather fast too (didn't check myself, missed to do this, unfortunately).

But it plays full 4K DPX in realtime as well. Pretty powerful subsystem.

Honestly, 4K playback is just jaw-dropping, but the quality of the panels isn't on par with HD panels to date. The same for projections. Its on its way, so it'll be there when we really need it.

I would not expect the RED Rocket to compete with the Clipster in what it does, because the Clipster consists of many processing boards doing many things in guaranteed realtime. But its definetly another price class, depending on what you aim to do.

For those who need 4K playback now, Clipster seems to be the only option.

Cheers,
Axel

[Rainer Fritz]

Can someone from RED estimate a release date? (End of June/July I saw somewhere... Jim ?)

So we are going to shoot a TV series in September.... it will be the missing puzzle in a fast TV workflow. 4k Full debayer to DPX or uncompressed QT or AVID MXF in realtime or nearly realtime would give us an additional big PLUS in satisfying our producers on the RED Camera and Workflow.
Doing First Light Correction and blowing the material into the edit in full quality is absolutely the TV Series workflow.....

We also can minimize the Onlining time for feature films.

thx

rainer

[Colin Hubick]

About two months...

Jim

One month and counting :-) Hey Jim, any new information for us post people?

[Billy]

just tested the new clipster that was at NAB this year. Playsback all builds of RED files in real time. also has real time creation of DPX files from original R3D files. just thought people should know

[Axel Mertes]

Good point Billy, just missed to test myself.

Thanks for pointing this out.

Does it require external storage on the Clipster or is the internal disk array sufficient for storing DPX files in realtime?

Axel

[M Most]

Does it require external storage on the Clipster or is the internal disk array sufficient for storing DPX files in realtime?


DPX has always been the Clipster's native format, it was designed for just that purpose, and has been around for at least 8 years.

[Axel Mertes]

I know that. I guess I was the first one who ever tested a Clipster, quite a bunch of years ago...

What I meant is if the DPX 4K data from RED R3D can be written to the INTERNAL disk array or if it requires an external FC SAN to store it. I know Clipsters internal disk array is technically sufficient, but the question is if it simply works or not.

Thanks,
Axel

[M Most]

What I meant is if the DPX 4K data from RED R3D can be written to the INTERNAL disk array or if it requires an external FC SAN to store it. I know Clipsters internal disk array is technically sufficient, but the question is if it simply works or not.


4K support is an option, but as far as I know, it's still self contained.