BUGGED qt proxies!

[Mark Toia]

I'm having QT proxie problems in FCP.

I have 16gig of ram, I'm running through a big RAID, I'm on a 8 core that has everything chucked at it for performance reasons. I'm at low compression, unlimited RT, the latest RED updates etc etc etc... and still I get pop ups saying dropped frames. PISSING ME OFF big time. For the last 6 months I have had perfect work flow. Now BLAH!

The crazy thing is this, We have just finished a 4 RED camera shoot.
One of the cameras was build 15 and these proxies work perfectly in the 2k sequence time line. No FCP dropped frames.
Yet in the same time line sequence we have put 3 different camera QT proxie movies in with the B15 that works (all build 16). 1 of these work perfect, no drop outs. Yet the other 2 cameras QT proxies are crap. Errors, drop frames etc etc. So why does some cameras make perfect QT's that we can cut and view perfectly and other cameras (SAME BUILDS, SAME FCP Settings, Same timeline) play like shit.

CAN SOMEONE AT RED PLEEEEEEEEEEEEASE GIVE US A SOLUTION.:help:

thanks in advance

 

[Scott Webster]

Out of interest, have you tried regenerating the proxies from Red Alert and seen if you have the same issue in FCP?

 

[Mark L. Pederson]

So why does some cameras make perfect QT's that we can cut and view perfectly and other cameras (SAME BUILDS, SAME FCP Settings, Same timeline) play like shit.

CAN SOMEONE AT RED PLEEEEEEEEEEEEASE GIVE US A SOLUTION.:help:

thanks in advance

Well ... it s very possible, that depending on how much detail is in the image, it can take more horsepower to debayer. You say you have multiple cameras on the same build - but the images are most likely different, right?

We keep testing this workflow - when there is a new codec - new FCP - new QT version - etc. - we have NEVER found it stable enough for a commercial job. NEVER.

It's getting better - but Apple is moving to a whole new QT, another version of Leopard, etc. - you can transcode to prores EXTREMELY fast if you make a cluster(s) - and your edit will have a MUCH better, stable experience -

Sure, EVENTUALLY, the "just edit the QT reference files from camera" will be more stable - but FCP has also has some underlying issues with LARGE PROJECTS with many LINKED or REFERENCE QTs - so you are really running uphill with this workflow - NOT RECOMMENDED.

 

[Mark Toia]

Out of interest, have you tried regenerating the proxies from Red Alert and seen if you have the same issue in FCP?

yes... one of the first thing I tried.

thanks.

So weird that 2 cameras QT's are good, the other to camera QT's are crap.

Ill figure it out, but would love a bit of RED input. hint hinit

 

[Mark Toia]

FCP has also has some underlying issues with LARGE PROJECTS with many LINKED or REFERENCE QTs - so you are really running uphill with this workflow - NOT RECOMMENDED.

RED say to do it this way, but really its the wrong way... Man this is getting way to left field.

The word RENDER was not part of RED's vocabulary. This is why I went the QT proxie scenario like the P2. This is another reason why I bought RED.
Having to transcode and render to other formats is turning a once very easy workflow solution into a pain in the arse.

For that last 6 months, Ive shot, edited without the need to RENDER to pro res till the end, grade it, out put to SR. Done easy finished.

Now I have to transcode, convert, render..... etc etc etc
What once was easy and fantastic is now turning slow and awkward.

Why I ask, WHY!

Lets hope someone at RED is thinking this out. Lets hope someone at APPLE is thinking this out.
The more complex and awkward the work flow becomes the less RED's they are going to sell.

 

[Rainer Fritz]

When you use Redcine for batch converting to 1k prores files and switch the gui resolution to 1/4 res you can render the offline files in realtime... or faster... edit... and use crimson for the online conform.... also a fast way in my opinion....