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 :)

91 Q&A from last night

I forgot to ask about RED Rocket compatibility with FCP or other NLE. I thought that was coming from what I recall from the original RR thread.

Oops, I should have read the thread before posting.


Cüneyt Kaya said:
debayering is done through CPU asfaik.
thats the reason why you need monster computers to play back r3d files at higher resolutions (full debayer for example).....or apps supporting rocket for playback.
Click to expand...
 
Jeff Kilgroe said:
It has been said more than once in the past couple months; NO. I don't see it changing either. Most everyone has made Stage-2 / 3 decisions accordingly.
Click to expand...

Remember This;
"Everything in life changes... including our camera specs and delivery dates..."
:laugh::laugh::laugh:
Still hoping for LeBron to join the Knicks
 
Where are you planning additional selling points?
--
(Good morning, by the way.)

Suggestions?

Jim
Click to expand...

Since the thread closed before we really got time to answer that, I would personally love an additional selling point within the European Union.
 
Cüneyt Kaya said:
debayering is done through CPU asfaik.
thats the reason why you need monster computers to play back r3d files at higher resolutions (full debayer for example).....or apps supporting rocket for playback.
Click to expand...

Not necessarily so. I can't be specific, but there are aps that do the de-bayer with GPU and they do it really well...

:) Peter
 
Currently no solution out there is doing GPU debayer of R3D footage. If they are, they are not using the RED SDK debayer tools and are in violation of RED's IP as RED has given no one permission to release software that does a debayer process on the footage any other way than how RED wants it done, and via their SDK. Others have come and gone doing their own debayer process -- like Cineform.

GPUs are powerful for certain tasks and not so powerful for the type of tasks they are not designed for. GPUs actually don't offer much power for processing bayer patterns. There's this perception out there that GPUs are these magical little processors that can do anything and that simply is not true. If it were, we would be building workstations around processors from nVidia instead of Intel. Don't get me wrong though, there are plenty of ways GPUs can accelerate the REDCODE workflow process...

There are many solutions coming about now that use the GPU a lot more for many operations in tandem with the RED SDK debayer tools. GPUs offer many advantages for offloading a lot of post-debayer processing from the CPU. This includes, but isn't limited to, color transformations and LUT applications, scaling, layering, stenciling, masks, etc.. This is currently the most practical method until we start seeing widespread installation of multiple GPUs in professional systems with an industry-standard way to access and use them (OpenCL). Properly multithreaded and optimized CPU debayer plus GPU transform can play back full res, full quality 4K in real-time on a 3GHz quad-core PC with some headroom to spare.

Remember, the debayer process is only part of the equation when using REDCODE. The old REDCINE could play back 4K R3D files at half-high on a decent quad-core system with a mediocre GPU. It only used GPU acceleration for color transforms mostly, but some acceleration was there. Much has changed since. I believe that REDCINE-X will eventually show some serious speed gains in this department as the SDK tools, and system hardware have advanced a lot since then. However, REDCINE-X is still being optimized for the RED Rocket and has a ways to go for all areas of performance.

I've seen some things in the works, possibly some of what Peter is talking about, that is really impressive. Much of this new software does use GPU acceleration quite heavily for many aspects of the image creation process. GPUs can, and are, being used to accelerate REDCODE.
 
i am just curious to see how the scarlet user should work with r3d files without beeing able to afford a rocket.

dunno if transcoding (double the amount of data)offline/online is what they can afford...or should be the way for scarlet users

guess a lot would be happy to edit scarlet footage on an imac.
 
Cüneyt Kaya said:
i am just curious to see how the scarlet user should work with r3d files without beeing able to afford a rocket.

dunno if transcoding (double the amount of data)offline/online is what they can afford...or should be the way for scarlet users

guess a lot would be happy to edit scarlet footage on an imac.
Click to expand...

Vegas Pro and Premiere Pro will edit to finish real time with a beefy enough computer. Rendering to final output may take longer.
 
Cüneyt Kaya said:
i am just curious to see how the scarlet user should work with r3d files without beeing able to afford a rocket.

dunno if transcoding (double the amount of data)offline/online is what they can afford...or should be the way for scarlet users

guess a lot would be happy to edit scarlet footage on an imac.
Click to expand...

would this depend a lot on what redcode you shoot in ?


if you shoot redcode 250 you will need a lot more processing power than redcode 42, correct?

thats what the big difference frame rates and data rate s
 
Cüneyt Kaya said:
i am just curious to see how the scarlet user should work with r3d files without beeing able to afford a rocket.
Click to expand...

I'm betting that when Scarlet comes out, we will suddenly get multi-threaded R3D decoding :)

BTW, Peter, thanks for this. It's a pity they didn't answer your excellent 3D questions in the original thread though! Well, I guess they might have been in the "disclosing too much to the competition" category?

Bruce Allen
www.boacinema.com
 
You must log in or register to reply here.
Back
Top