Welcome to our community

Be a part of something great, join today!

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

Status
Not open for further replies.
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)
 
BOXXLabs said:
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???
Click to expand...

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!
 
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.
 
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?)
 
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.
 
Jarred Land said:
There usually is a method to our madness, believe it or not. :)
Click to expand...

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
 
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?
 
Axel Mertes said:
PS: Will RED Rocket do RED RAY encoding in realtime?
Click to expand...

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.
 
Axel Mertes said:
...
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?
Click to expand...

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

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. ;)
 
Axel Mertes said:
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...
Click to expand...

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
 
Baab said:
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
Click to expand...

thats what i want to know too. all I do know is im waiting on a lot of post
purchases until July.
 
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.
 
Axel Mertes said:
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?
Click to expand...

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.
 
Tim Whitcomb said:
thats what i want to know too. all I do know is im waiting on a lot of post
purchases until July.
Click to expand...

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
 
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
 
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
 
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
 
Axel Mertes said:
Does it require external storage on the Clipster or is the internal disk array sufficient for storing DPX files in realtime?
Click to expand...

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.
 
Status
Not open for further replies.
Back
Top