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

Jarred Land said:
Red Rocket support will be integrated into the SDK so developing for it will be pretty simple for anyone building with the current SDK.
Click to expand...

Hmm... I was under the impression that all apps that already used the SDK magically would work straight of on RedRocket. Does this quote mean differently?

If it does not mean differently and that all current SDK apps will utilize RR, what kind of other apps/utilities do you think we can see coming that uses RR? What I mean is that if current apps with current SDK uses RR, what more can be achieved with it available in the SDK?
 
Henrik Cednert said:
Hmm... I was under the impression that all apps that already used the SDK magically would work straight of on RedRocket. Does this quote mean differently?

If it does not mean differently and that all current SDK apps will utilize RR, what kind of other apps/utilities do you think we can see coming that uses RR? What I mean is that if current apps with current SDK uses RR, what more can be achieved with it available in the SDK?
Click to expand...

Since the RR is new, it is highly unlikely that anything exists that talks to it, we will have to wait for the updated SDK and developers to write applications and/or support. Hopefully the new SDK gets out well before July 1st or at minimum Red will include a simple application to get us started.
 
Ok so is it true to say that if I buy a RedRocket, available in a month, I will be able to stick it in my MacPro and instantly get real time debayering, HD output and 4K DVI from Funal Cut Pro on release date? Will I have a control panel appearing in FCP or in System Preferences?

Other question, how well does it work with a Kona 3 card?

Second other question, will it be able to do TCBI on output for daillies?

Oh... yeah... Is Silverado the only reseller or are you gonna have a canadian reseller too?

Thanks a lot.
 
digitalfx said:
Since the RR is new, it is highly unlikely that anything exists that talks to it, we will have to wait for the updated SDK and developers to write applications and/or support. Hopefully the new SDK gets out well before July 1st or at minimum Red will include a simple application to get us started.
Click to expand...

Maybe an exciting new version of REDCine will accompany the release of the rocket? That is my hope anyways.
 
Henrik Cednert said:
Hmm... I was under the impression that all apps that already used the SDK magically would work straight of on RedRocket. Does this quote mean differently?

If it does not mean differently and that all current SDK apps will utilize RR, what kind of other apps/utilities do you think we can see coming that uses RR? What I mean is that if current apps with current SDK uses RR, what more can be achieved with it available in the SDK?
Click to expand...


There will be a new version of the SDK that takes advantage of REDrocket. The changes to the host app to use REDrocket will be minor.
 
Mine too. If REDCine/Alert/Rushes support it from day one, this would alone justify the price of admission!

For me it's all about transcoding quickly and at high quality.

Chris Parker said:
Maybe an exciting new version of REDCine will accompany the release of the rocket? That is my hope anyways.
Click to expand...
 
Convert back to R3D

Convert back to R3D

Deanan,

Since it has the HDSDI outputs it should be able to connect to decks and broadcast monitors.
Click to expand...
That's the intention behind the dual link output on the board.
Click to expand...
Click to expand...
So, let's say I'm conforming my edit on my grading system in the grading suite (this is pretty much our workflow for the moment). Even without the Rocket, IO was never an issue. It was the CPU hit you took decoding the R3D data. Now that we have the rocket, this will no longer be any problem. Wonderful.

So we go into the grading suite, we do a bunch of primary and secondary work, get all the footage right where we want it and we're ready to layoff the D5 broadcast master. It's all great, but with all the grading effects on all the shots my machine won't make rate. It's not IO, not even decoding of the 4k stream, but sadly we may (likely) be GPU constrained. Just like the old days with the Onyx2, there just comes a point where the graphics isn't cutting it, you've got too much happening on each shot... bummer.. so, in the old days we'd just render out a sequene of dpx files and play them back.. no biggie, but it eats disk and necessitates having a big (350+ MB/sec capable) JBOD disk array hung off the grading machine.

Seems having the ability to write back all your rendered output to R3D is the way forward here. Then you just rip it right to your HDCAM/D5/'insert favorite HD deck here' right through the rocket and you're done.

I think this is what _almost_ all of us are after who have to deal with this stuff on a facility level, a straightforward, render once workflow (that and maybe a higher bit rate R3D archiving format).

What's obviously missing is the ability to go back to R3D.

This is further complicated if there's VFX in your show and you have converted stuff to linear exr or 16 bit tiffs so your footage is in a gamut consistent with your vfx pipeline (see Spitzak's early rantings on the linear floating point workflow circa his early DD days).

Having the ability to get the footage into a common format when you go to conform for grading is the obvious best way to work here, but there are obvious limitations imposed by most of the various formats, IO and the ability to support all the information in the frame essentially restricts you to either floating point or 16 bit linear formats (tif, exr, etc.).

R3D, again, seems like an obvious choice. Compressed exr's hit the CPU so hard you can't make rate with anything over 1k, even with a box of nehalems, and uncompressed formats of any other type are going to require massive amounts of local disk.

With R3D would also get the nice little bonus of being able to go back into the original gamut (as we'd be writing raw), that would really be a really nice bonus.

If the Rocket could go both ways (decode AND encode) it would solve all of these problems nicely.

So, what's the thought on this? I understand the need to protect the R3D format, but the Rocket kinda solves the problem for you if you use it for re-encoding.

Second question, is the card PCIe 1.0 or 2.0?

Cheers,

:J
 
Chris Parker said:
does that mean metafuze from AVID will be taking advantage of the rocket?

michael?
Click to expand...

Once we see the SDK to support it, I can better answer that one.

Michael
 
nice to hear michael. also what about direct ingest to AVID ala AMA (i know that's a RED question really) or just Import? do you think RR will be optimized across the full AVID chain or just smaller support programs?
and yes im aware of the Quarter boundaries for public disclosure :)

just have to ask anyway hahah
 
Is it possible to release a stripped down version of REDrocket that has no outs and only helps with debayering and is housed to attach to a PCMCI on macbooks?
 
a bit pointless since pcmcia has gone away and express card is gone for all new mac book pros except the 17 inch. thanks apple
 
What? Are you saying you can't do all of your high end work with an SD slot?
 
jonathanf said:
deanan,

so, let's say i'm conforming my edit on my grading system in the grading suite (this is pretty much our workflow for the moment). Even without the rocket, io was never an issue. It was the cpu hit you took decoding the r3d data. Now that we have the rocket, this will no longer be any problem. Wonderful.

So we go into the grading suite, we do a bunch of primary and secondary work, get all the footage right where we want it and we're ready to layoff the d5 broadcast master. It's all great, but with all the grading effects on all the shots my machine won't make rate. It's not io, not even decoding of the 4k stream, but sadly we may (likely) be gpu constrained. Just like the old days with the onyx2, there just comes a point where the graphics isn't cutting it, you've got too much happening on each shot... Bummer.. So, in the old days we'd just render out a sequene of dpx files and play them back.. No biggie, but it eats disk and necessitates having a big (350+ mb/sec capable) jbod disk array hung off the grading machine.

Seems having the ability to write back all your rendered output to r3d is the way forward here. Then you just rip it right to your hdcam/d5/'insert favorite hd deck here' right through the rocket and you're done.

I think this is what _almost_ all of us are after who have to deal with this stuff on a facility level, a straightforward, render once workflow (that and maybe a higher bit rate r3d archiving format).

What's obviously missing is the ability to go back to r3d.

This is further complicated if there's vfx in your show and you have converted stuff to linear exr or 16 bit tiffs so your footage is in a gamut consistent with your vfx pipeline (see spitzak's early rantings on the linear floating point workflow circa his early dd days).

Having the ability to get the footage into a common format when you go to conform for grading is the obvious best way to work here, but there are obvious limitations imposed by most of the various formats, io and the ability to support all the information in the frame essentially restricts you to either floating point or 16 bit linear formats (tif, exr, etc.).

R3d, again, seems like an obvious choice. Compressed exr's hit the cpu so hard you can't make rate with anything over 1k, even with a box of nehalems, and uncompressed formats of any other type are going to require massive amounts of local disk.

With r3d would also get the nice little bonus of being able to go back into the original gamut (as we'd be writing raw), that would really be a really nice bonus.

If the rocket could go both ways (decode and encode) it would solve all of these problems nicely.

So, what's the thought on this? I understand the need to protect the r3d format, but the rocket kinda solves the problem for you if you use it for re-encoding.

Second question, is the card pcie 1.0 or 2.0?

Cheers,

:j
Click to expand...

i hope someone reads this>>> very logical, would solve alot of issues
 
About that idea of Rendering out R3D from a grading system...

Maybe I'm the dumb one, but I don't see that working at all.

First you would get RedCode36 from the camera and then ANOTHER RedCode36 on top of that (unless they would make a higher bitrate for "Renders R3D"). basicly you would end up with double compression. And for some shots I've seen, your on the edge even at one level of compression.

We already have a "common format" for post. DPX. Its a proven workflow. Sure its expensive to buy drives that can play 2K DPX in 25fps, but if you can't spend the money you should stay away from post. Or just render out as 2K ProresHQ if that good enough for you.

Even if we could render out as R3D after grading you still wouldn't have the original footage saved just because it is RAW. Sure if you did your Final Grade in RedAlert, and after that "rendered out a R3D" with the look applyed (only Red settings/tools available) then you would be able to go back to "non graded".
But thats already doable. And you don't even need to render it. Just save it as MetaData and create new QT-Refs. When you play it, just apply the RSX for each clip.
(maybe not doable in reality, but theoreticly it shoudl be possible)

If we were able to render out a High-bitrate-R3D we would have to render in the look aswell. And the way to open it would be Linear I gues (or Log if it should have a LUT applyed for monitoring). And to control the "Exposure" etc would not make any sense...

The only way I see it possible is to render out a format, maybe R3D if you want, and have a super-3D-LUT. Carrying the information of each pixels new/altered values/offset/difference. How would we els get a window or hand-drawn-mask get through this pipeline?


But maybe I'm wrong.
It does sound like a nice idea though.
I really like the fact that I now can use cheap "slow" storage when grading 4K.
I've actually connected a 4TB-Lacie_FireWire800-drive to a mac on my network and mounted that (through GigE) on my Resolve Grading system. And if I'm working from R3D I don't have to eat up a bunch of my Bright-SAN-space witch is kept free for DPX-work. Can't see that workflow working for a uncompressed-RAW camera like Arri or whatever There's always pros and cons I gues.

/carl
 
You must log in or register to reply here.
Back
Top