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 update...

JanneJansson said:
Is the card "flashable"? Would be nice to upgrade the card to support stuff like the new color science and any future version the comes along.
Click to expand...

It is. You can expect improvements in functionality with firmware/software upgrades.
 
Jannard said:
Decode and debayer 4K R3D files realtime. Hyper-accelerated transcode to any system codec.
Click to expand...

Deanan said:
The card can do 4k to 4k debayer plus scaling in realtime. Encoding to another codec happens on the cpu but a codec like prores will be realtime for SD.
Click to expand...

I'm confused about where in the data path transcoding to a system codec takes place. In Jim's original post it he says it happens within the Rocket card, but Deanan's post says it happens on the cpu.

Just wondering about this as the "Hyper-accelerated transcode to any system codec." part is as important to me as the realtime 4k/2k stuff.

I can see the value in being able to quickly output to ProRes 422HQ, or whatever a client might request.
 
Robert Frank said:
I'm confused about where in the data path transcoding to a system codec takes place. In Jim's original post it he says it happens within the Rocket card, but Deanan's post says it happens on the cpu.

Just wondering about this as the "Hyper-accelerated transcode to any system codec." part is as important to me as the realtime 4k/2k stuff.

I can see the value in being able to quickly output to ProRes 422HQ, or whatever a client might request.
Click to expand...

If the card can accelerate transcoding that would be amazing. However, wouldn't that require specialized chipsets? Like for instance, MPEG-2 or AVC chips?

Maybe Jim was saying that the card will functionally accelerate transcoding since all of the work with REDCODE will already be done.
 
Robert Frank said:
I'm confused about where in the data path transcoding to a system codec takes place. In Jim's original post it he says it happens within the Rocket card, but Deanan's post says it happens on the cpu.

Just wondering about this as the "Hyper-accelerated transcode to any system codec." part is as important to me as the realtime 4k/2k stuff.

I can see the value in being able to quickly output to ProRes 422HQ, or whatever a client might request.
Click to expand...

Hyper accelerated transcoding means that almost all the heavy lifting involved in transcoding from R3D at high quality/resolution to another codec is done on Rocket. The CPU is then completely free to do the encoding part as fast as it can.

So if the CPU spent 98% of it's time doing debayer and decoding, with RED Rocket, that 98% is handled by rocket and the CPU is free for the final encoding part.
 
Deanan said:
Hyper accelerated transcoding means that almost all the heavy lifting involved in transcoding from R3D at high quality/resolution to another codec is done on Rocket. The CPU is then completely free to do the encoding part as fast as it can.

So if the CPU spent 98% of it's time doing debayer and decoding, with RED Rocket™™™, that 98% is handled by rocket and the CPU is free for the final encoding part.
Click to expand...

Thanks for the clarification!

Since I'm asking questions, any news yet on the RED Rocket 12volt power supply requirements in a system with a dual 12v connections in use for a high end graphics card?
 
Robert Frank said:
Thanks for the clarification!

Since I'm asking questions, any news yet on the RED Rocket™ 12volt power supply requirements in a system with a dual 12v connections in use for a high end graphics card?
Click to expand...

We're in the process of liberating the external power so it's not needed. This will make things much easier especially on macpros were external 12v power is limited.
 
Deanan said:
We're in the process of liberating the external power so it's not needed. This will make things much easier especially on macpros were external 12v power is limited.
Click to expand...

Great news! This is really looking like the post solution I was hoping for.
 
Deanan said:
We're in the process of liberating the external power so it's not needed. This will make things much easier especially on macpros were external 12v power is limited.
Click to expand...


Uh oh. Do I smell a delay? :-) Hope not...though I guess a sleight one would be okay if it meant losing an extra cable. We're itching to get some real-time.

Kevin
 
Very soon...

Jim
 
Exciting times for sure.
But are there any updates as to system requirements or at least an idea on transcode times depending on system (Xenon vs Nehalem Mac Pro)?
I for one have a deposit on the RedRocket and am painfully holding off on a Mac Pro purchase until I know abit more.
Waiting anxiously...but patiently:-)
 
My understanding is RedRocket will do its thing, handing back fully debayered footage to your CPU in realtime regardless of CPU speed.

If your current machine takes "X" to transcode, that will not change or otherwise speed up.

What does change is waiting 3 seconds for every frame to debayer! That's what we're buying here.

So while transcodes will be drastically sped up, it's because of the realtime debayer. The actual transcode (creation of new file in new CODEC) is handled by your CPU and this will go at the same speed as before. What's removed is the debayer time.
 
jimhare said:
If your current machine takes "X" to transcode, that will not change or otherwise speed up.
Click to expand...

My understanding is that this is exactly what will change.....and speed up tremendously....as debayer is the first half (the BIG half) of a transcode.....from .r3d anyways.....
 
Yes, that's what I meant, I was just talking about the transcode time as opposed to debayer time.

The point is it's not actually the transcode (creating a file in a new CODEC) that was taking the time, it was the debayer.

People shouldn't confuse this with a ProRes hardware card or something, it's job is to debayer the R3Ds in realtime and pass the info to the CPU.

The effect will be a drastically sped up process, but the card is only handling the debayer, not the creation of the new file (transcode.)

I think this is what's still confusing some.

Chris Parker said:
My understanding is that this is exactly what will change.....and speed up tremendously....as debayer is the first half (the BIG half) of a transcode.....from .r3d anyways.....
Click to expand...
 
Has anyone used the new Matrox H.264 card? it seems like it would be a good pairing, a redrocket card and a h.264 card.

Rodney James
 
jimhare said:
Yes, that's what I meant, I was just talking about the transcode time as opposed to debayer time.

The point is it's not actually the transcode (creating a file in a new CODEC) that was taking the time, it was the debayer.

People shouldn't confuse this with a ProRes hardware card or something, it's job is to debayer the R3Ds in realtime and pass the info to the CPU.

The effect will be a drastically sped up process, but the card is only handling the debayer, not the creation of the new file (transcode.)

I think this is what's still confusing some.
Click to expand...

Encoding also goes faster because the CPU is not fighting for resources with the debayer/decoding.

I'm using the term 'encoding' rather than transcoding because transcoding generally means decode->process->encode and with red rocket the decode and process (debayer and color processing) happen on the card, leaving only the encode on the CPU.
 
Thanks for the clarification Deanan. Looking forward to receiving it soon!

After refreshing the sales page for 20 minutes, I think I got my order in within 10 seconds of it going live a couple of weeks back.
 
You must log in or register to reply here.
Back
Top