[John Heagy]

Thanks for the tip David!

[John Heagy]

Hi Dave,

Thanks for the response!

[David McGavran] “What does it mean to have a reference movie pointing to mixed media codecs like .r3d, h.264, .arri, .mxf etc… Ref movies only work if you have a standard QuickTime based format for your timeline.”

Correct, and that’s what we do. There’s never time, as the deadline approaches, to render so we take it at the beginning and transcode everything to ProRes.

[David McGavran] “QuickTime 32 bit is overly deprecated by apple and ref movie isn’t really a feature in the 64 bits api’s so it is kind of a dead tech.”

Yes, but AVFoundation does open Ref.mov and without any Windows alternative I don’t see 32bit QT going away anytime soon.

[David McGavran] “Our solution is to focus on smart rendering.”

… where QT Ref would fit in nicely.

As far as being useful, I would equate the usefulness to symbolic links in Unix/Linux. It allows us to present media to processes like transcoding and syncing “virtually” keeping the originals protected while saving time and disk space.

Like symbolic links it is an advanced user tool and will cause havoc in anything short of a buttoned down shared environment. All our ingests are done using Ref.mov to support growing files, in the case of B4M, or VTR emulation, including insert edits, using our own app. EVS uses ref.mov for growing files as well. Again an advanced tool for advanced users. FCP7 is the only app that creates self contained recordings in our current workflow.

Like I mentioned, of all the QT APIs, QT ref is the easiest/lightest to call given the output is essentially a .txt file. Most any app that opens .mov will open ref.mov as the only difference is the wrapper doesn’t point to itself. So the use case for the future is pretty solid, it’s just Ref.mov creation that’s in peril.

Thanks
John Heagy

[John Heagy]

Quicktime reference is super useful and without things will happen much slower for us.

There’s nothing preventing an app from calling 32bit Quicktime. QT ref is little more than a .txt file. No real penalty in calling on a 32 bit API to create a .txt file.

Avid 6.5, and I’d assume 7.0, still export QT ref.

John

[John Heagy]

The big selling point for Isilon is easy expandability and increased resiliency the bigger it gets.

Editshare can’t be expanded once a volume is created and Smalltree is very limited to how large it can grow. Can’t comment on Facillis. Isn’t that a block level SAN system?

We have high hopes for GBLabs and will be testing a system. While expandable and redundant, it is far more complicated to achieve.

The IT market Isilon targets is both good and bad. Bad that it expends resources to cater to that huge market, but good in that helps keep the company in the black. A small media only focused company, like GBLabs, does limit it’s market and therefore it’s sustainability.

John

[John Heagy]

We do ProRes LT for the mass ingest.

ProRes SQ for everything else.

[John Heagy]

Interesting you mention 16 channels of ingest. That’s how many we send to each volume for a total of 32. We do require growing file playback also.

You mention connecting clients TO a node. Don’t all the node and client connections go to a switch?

I agree that the cost and the typical IT targeting are drawbacks. I put them in the same category as NetApp.

Thanks
John

[John Heagy]

Thanks for the detailed reply David.

You mentioned you had no issue with bandwidth. Can you describe the workflows the Isilon volume supported? Any live ingest?

Thanks
John

[John Heagy]

[Bob Zelin] “what “non propriatary” software are you aware of for .tar ? “

Any major linux distribution will support writing .tar to LTO. OS X has the commands but Apple has not included any LTO drivers. Can’t speak to Windows.

check out ioscsitape

https://code.google.com/p/ioscsitape/

[John Heagy]

The only thing that comes to mind is they want the files written as tar, or a series of tar files, via linux/BSD commands.

I’d ask them for examples of non-proprietary hardware and software and how they plan to restore data from the tapes.

[John Heagy]

If you manually create a timeline with 300 identical slates spaced out as you need you can export that as XML. Via some find and replace trickery you can modify each slates info in the XML and import that back into FCP.