REDline render slower now?

[Kjetil Haugen]

Seems so... Anybody else tested?

[Kjetil Haugen]

Looks like its with redspace only. could it be because the clips are from build 15? Any Red people?

[Deanan]

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.

[Kjetil Haugen]

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

[Deanan]

Run multiple redlines at the same time for now.

[Kjetil Haugen]

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.

[Anthony S. Pratt]

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

[Mike Zinner]

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

[Deanan]

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


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.

[RickyH]

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.

[Deanan]

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.

[EditSource]

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?