How about having Avid be the first NLE to natively support Red Rocket?
I just spent a few hours at a professional colorist's studio in Hollywood. Red has really invaded the market place. I asked about Avid and he said he gets some Avid material but the vast majority is from FCPS.
Apple has made quite a name for itself in the Red world. If Avid were the first NLE to support Red Rocket, that would go some way to dispell those feelings.
Avid DS as of yesterdays release now supports the RED SDK so i assume Red Rocket.
You can of course use Avid for offline and HD tv workflow if you transcode to DnX, full RED workflow is expensive for the TV market on tight budgets.
RED ROCKET acelerated the debayer process for the full 4K frame. Media Composer doe not have a 4K frame size. So DS could take advnatage of it, as well as MetaFuze which is being looked into now. There is still addiitonal workflow issues is that the card only decodes a single stream. What happens in the case of a dissolve? Layer. VFX? A render must happen. And since the camera is the only device that can create R3D, you are rendering to another format - which mow means a LUT for that format. As you can see, things can get complex rather quickly when you move beyond the straight cut type composition.
I would also bet that most of that FCP edited material was done from a transcode to ProRes. A render to ProRes is the same workflow as a render to DNxHD. For some reason, many people think that going to ProRes is still native.
Michael
____________ Anything 24fps
Michael, reading back on post, I can see how it could be a little unclear. I'm aware that MC and Symphony don't have 2 or 4K frame sizes or 4:4:4 color depth so they can't work w/ R3D natively. So I wasn't posting that MC and Symphony should be able to work w/ RedRocket to natively edit R3D. That's a huge undertaking that I wouldn't so glibly suggest.
I was/am referring to having MetaFuze take advantage of RedRocket (which is why I posted this in the MetaFuze forum).
I just feel it would send a strong message to be able to say that AVID (via MetaFuze) is the first NLE to take advantage of RedRocket.
And you are absolutely correct, that the FCP material given to this post house is ProRes. Which is exactly why I think getting MetaFuze to work with RedRocket ASAP would be to Avid's benefit. Because Avid's transcode to DNxHD would be faster than the transcode to ProRes.
Then we're both saying the same thing.
We have a RED ROCKET in house and development is moving along on it. There are also some other interesting things happening we will speak to when ready.
Actually, DS has been supporting the RED SDK for a while now. I believe it was the previous release 10.1 that introduced RED support.
Igor Ridanovic
www.HDhead.com
I think the value of your idea is in generating the notion that Avid plays well with RED.
On the practical side, you can setup several MetaFuze servers for the price of RED Rocket. Such render farm could debayer RED faster than real time. It would be just plain faster than RED Rocket.
Igor Ridanovic:On the practical side, you can setup several MetaFuze servers for the price of RED Rocket.
The thing is: i would not have a clue how to set such a thing up. I've never been involved in any networking beyond my Lanshare.
Any tips where to start reading up on how to set up render farms? What server machines would you recommend using for that?
Because of my infamiliarity with render farms, my gut feeling would make me go for a one-system solution (possibly with something like Red Rocket).
Thanks.
Render farms are tricky beasts.
Unfortunately there's no straight answers - every application's render has it's own quirks.
The general challenges are:- Managing the renders to ensure all necessary frames/clips are rendered.- Ensuring all necessary assets are available to all render nodes.- Consistent settings/environment.- Collectiong finished results in a single place.
In Metafuze the transcode is handled on a clip by clip basis, meaning that you basically gather together a collection of computers to each render full clips until everything is done. Evert render node has to have access to the source R3D files (or other source), the information needed to do the transcode (settings basically) and somewhere to put the finished clip.
To centralise this you then have each render node access the R3D file over a network share from a single location. And to simplify the gathering process with the end product you then get each node to render back to a network path - however this can introduce perfomance problems, as the bitrates we're talking about could quite easily swamp the network and slow everything down.
My app is aimed to manage the job contol - ensuring that render nodes are given work to do, and that results are tracked, but the other complications remain just that, complicated.
In terms of choosing hardware - well it depends on what you're rendering. Ideally you build/buy computers that are reach a good balance between performance and cost. Typically you're looking for processor power and RAM, and for some applications graphics hardware is a consideration. Typically I'd say $200-300 per node should be plenty (not including operating system).
Dylan Reeve - Editor and StuffAuckland, New Zealand
My opinions are my own.
Dylan's Templater - Basic Avid project templating tool.BatchFuze - MetaFuze batch transcoding tools.
Hi there!I would like to have a single workstation equipped with plenty of storage, meta fuze and a red rocked card to take the system wherever the shooting takes place. With that setup i could create offline mxf files for editing on site! We have many clients that would be more then happy with this sort of digital film lab! in an ideal world i would buy a dvs clipster, but if budgets are tight, a simple XW8600 with SAS raid should just be fine!
So, if metafuze could take advantage of the red rocket renderpower ......
..... a man can dream!
Avid Technology, Inc. brands: Digidesign | M-Audio | Sibelius | Pinnacle Systems | Sundance Digital
© Copyright 2000-2008 Avid Technology, Inc. All Rights Reserved — Legal Notices | Privacy Policy | RSS Feeds | Site Map