Gunleik Groven
REDuser Sponsor
Currently the bottleneck seems to be the transcoding of RAW files.
If one was to process huge amounts of Red footy - like in a TV station - every day, the transcoding of RAW files seems to currently be the worst bottleneck - as the QT ref-files are too heavy to use practically (or am I wrong?)
As i have understood, the current practical workflow is RedAlert to ProRes/DPX/TIF and edit as you're used to.
I understand that down the line there's going to be a way to edit the RAW files directly in FCP, but the catch seems to be that the de-bayering and applying of metadatata of the files seems too costly -in processor cycles - to really have a use in a high throughput environment (or am I wrong?)
So, let's say you work in an envirmonment where you have to process 40 hours of RAW footy pr day, one would need something like an automated procedure for back-up and pre-processing and a cluster/RAID/SAN comes to immediate use.
But are there solutions like this, down the line?
In an ideal world, one could stay in RAW untill either final delivery or compositing (which in the mentioned scenario would be rare).
But as far as I can see, there is as of now, no real practical solution that lets you stay in RAW for cuts, dissolves and colors - unless that's what Scratch means (but Luki hasn't answered my PM's as of yet, so I'll wait -
.
So
Is it planned for solutions where one could "farm out" the transcoding procedures to clusters that would approach realtime?
At the studio we have an 128-core Linux cluster for Maya and other renders. Seems like a probable suspect - if it wasn't for the non-linux nature of Red.
But I wouldn't mind an XSERVE (we have 5 stacked up in a small SAN for close to realtime Shake keying/comp'ing in uncompredssed HD) or a windows-cluster either.
Any thoughts from Red or others on this?
Gunleik
If one was to process huge amounts of Red footy - like in a TV station - every day, the transcoding of RAW files seems to currently be the worst bottleneck - as the QT ref-files are too heavy to use practically (or am I wrong?)
As i have understood, the current practical workflow is RedAlert to ProRes/DPX/TIF and edit as you're used to.
I understand that down the line there's going to be a way to edit the RAW files directly in FCP, but the catch seems to be that the de-bayering and applying of metadatata of the files seems too costly -in processor cycles - to really have a use in a high throughput environment (or am I wrong?)
So, let's say you work in an envirmonment where you have to process 40 hours of RAW footy pr day, one would need something like an automated procedure for back-up and pre-processing and a cluster/RAID/SAN comes to immediate use.
But are there solutions like this, down the line?
In an ideal world, one could stay in RAW untill either final delivery or compositing (which in the mentioned scenario would be rare).
But as far as I can see, there is as of now, no real practical solution that lets you stay in RAW for cuts, dissolves and colors - unless that's what Scratch means (but Luki hasn't answered my PM's as of yet, so I'll wait -
.So
Is it planned for solutions where one could "farm out" the transcoding procedures to clusters that would approach realtime?
At the studio we have an 128-core Linux cluster for Maya and other renders. Seems like a probable suspect - if it wasn't for the non-linux nature of Red.
But I wouldn't mind an XSERVE (we have 5 stacked up in a small SAN for close to realtime Shake keying/comp'ing in uncompredssed HD) or a windows-cluster either.
Any thoughts from Red or others on this?
Gunleik
