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

REDline render slower now?

Looks like its with redspace only. could it be because the clips are from build 15? Any Red people?
 
It's using fewer processors at the moment because we haven't optimized the multithreading after all the changes were made to support b16 and 16:9.
 
Ok. How are you guys doing with that? Is it a big problem or can we expect a new optimized version any time soon?

I guess I can use the old Redline/RedAlert for now because we're still on b15 (don't want to change during last week of production).
 
Run multiple redlines at the same time for now.
 
Already doing that. Rendering 3 clips at the same time in 3 redline terminal windows. I'm DIT'ing and rendering on set for the director and DP so that they can see the footage in full HD. This has worked great so far with the time it takes to render. But after installing the new versions the time it takes to render has increased. So.. Changing back to previous RedAlert/Redline untill the problem is resolved.
 
Unfortunately not just RedSpace - CamRGB to DPX also very slow.

I'm used to all 8 cores running like olympic sprinters on steroids, now they just bobble along like old ladies on their way to the local bridge club...

Sure it will be threading related and I'm equally sure it'll get fixed, in time...
 
I wonder how much this is related to the encryption of the RAW data that is now happening inside the Red One camera (which is one of the biggest changes in Build 16).

Decryption takes CPU time and is slower than direct access and processing of the RAW data. Sure, everything can be optimized again, but without encryption everything would be faster anyway.

It would be funny (if it would not be so tragic) that a company like Red seems so much afraid of 3rd parties accessing their files so that they sacrifice CPU time in-camera and in their post-tools to lock them out...
 
Mike Zinner said:
I wonder how much this is related to the encryption of the RAW data that is now happening inside the Red One camera (which is one of the biggest changes in Build 16).
Click to expand...

Huh?! The reason things aren't optimized is because the threading for the rendering got moved from one place to another as part of the SDK work and REDalert/REDline's threading has not caught up yet.
 
Full of half Debayer and Render times?

Full of half Debayer and Render times?

I've been doing some experimenting on batching dailies with REDline and the render time jumps exponentially when I select "full render resolution" vs "half render resolution"

Can anyone point me to someone who has done tests and determined what is gained/lossed by doing a full/half dabayer?

And what do the QT ref movies generated by the camera have associated with them? (full/half/quarter/colorspace?)

Or is this due to the changes mentioned above? I'm looking at 2.5hrs (full debayer) vs 38min(half debayer) render time (to 2K ProRes) for a full 8GB CF card on an 8-core MacPro w/8GB RAM

Any info would be greatly appreciated.
 
Full res debayer gives you the best quality output.
half res debayer is a special debayer that goes from say 4k to 2k but does a good quality render that's not aliasy.
 
Render Times for 2k to Prores?

Render Times for 2k to Prores?

I was wondering if the render times of 2.5 hours per 8 GB CF raw files to Pro res on a 8 core machine is an average render time, or is this an anormality? And could one just edit the proxy files and them render after the off line is complete?
 
You must log in or register to reply here.
Back
Top