Editing over ethernet using FCP 7?

[weskennison]

Hi all!
I manage operations at a video production house, we've been doing corporate productions for years and are looking to set up multiple user access to our Drobo servers which house all video archiving data, FCP files, assets,etc. All editors will be using FCP 7. We really just want to set up three access points to these Drobos using a mac mini set up as a server to manage access. All machines are in relative proximity to one another (45 ft or less).
I've heard several takes on the best way to do this and want to solicit some input from the community. The easiest way involves an ethernet network, with each editor accessing files and editing in real time over the ethernet network.

Has anyone tried this? Any input is welcome, thanks!

[edDV]

What format are the files?

In most cases you will get better performance and less latency downloading the files to an internal hard drive (not the OS drive) for editing.

[weskennison]

The files will all be pro res 422. Worst case scenario we'll be copying to local machines and editing, then copying back to the Drobo. But the idea here is to keep the drobo updated in real time, so that's not really the preferred method, not as efficient.

[edDV]

The files will all be pro res 422. Worst case scenario we'll be copying to local machines and editing, then copying back to the Drobo. But the idea here is to keep the drobo updated in real time, so that's not really the preferred method, not as efficient.

Prores 422 won't work on a conventional server the bit rate is too high. Normally an expensive SAN server is used for shared video networking in a post house.

ProRes422

http://www.appleinsider.com/articles/07/04/18/a_closer_look_at_apples_new_prores_422_v...eo_format.html

SAN-Attached servers
http://www.enterprisestorageforum.com/technology/features/article.php/3701021
http://www.enterprisestorageforum.com/sans/features/article.php/3711286/Storage-Networ...ed-Servers.htm
http://www.apple.com/xsan/deployments/video.html
http://forums.creativecow.net/thread/197/857956

Warning, these get expensive and are complex to install and maintain. Consult an expert that has done post houses before.

[aedipuss]

how are going to keep 2 people from working a file at the same time? all edits by one will be overwritten by the second save. i'm not sure fcp can lock a file from a file server. unless the mini has some file management software running the show.

[bhilgenkamp]

If you're only editing a single stream of ProRes on each computer than a single 1Gb ethernet to each machine will suffice. Your server however will need to have multiple ports to handle the users.
To get you some better answers:
Which Drobo are you using, how many Drobos, and what is the current storage capacity
How many streams per computer will you be using
How many editors/machines will be accessing the footage at a single time
Do you currently have a server? Mac or PC? OS Version?
If you have a server is it currently sharing the Drobo? What network protocol? (AFP, CIFS, NFS)
Do you have a budget in mind for this

There are a lot of variables here, so the more you can answer the better result you'll have.

[budwzr]

That's a pipe dream. It doesn't even make sense.

[bhilgenkamp]

What doesn't make sense?

[bhilgenkamp]

Sorry, I misread your original post and missed the Mac mini part of it. Do you already own the mini or would you you be purchasing that? Please refer to my previous questions as well. I've been in the same position and have come up with some crazy ideas in the past that have worked.

[budwzr]

What doesn't make sense?

Sharing video files over a NAS to be edited.

In the case of conflicts, who would win? How would you know which version had the correct edits? You're going to "watch" the clip? Hahaha.

What about errors? What if FCP crashes during a render or edit? And creates a corrupted file? Or you have to restore from a backup?

What if the NAS crashes? Or you need to "roll back"? How are you going to notify and control all the users?

A video file is not "distributable" like database tuples. It's just a big chunk. Like a wheelbarrow with one big rock in it. Database date is in pebbles. Pebbles can be numbered, indexed, etc. and DISPLAYED as a rock. A rock cannot be displayed as pebbles.

Operating a NAS in a shared environment requires a whole IT department.

And using Macs just further complicates things because their OS is very limited. I don't even know if they have something like Enterprise or Exchange Server. And you're going to pay through the nose for anything that advanced.

[budwzr]

I perused the Drobo site, and they seem to cater to Mac people because it's a lot of sizzle and few specs. And they like to "Brand" common functions as their own invention.



Don't get fooled into paying a whole bunch for seemingly impressive features. Every NAS has user share control and JBOD. None of them require managing physical drives, whether JBOD, striped, mirrored, or RAID, to create shares.

My consumer-level NAS has "Smart Volumes" too.

No doubt Drobo is highly scalable, to accommodate HD video, but it's still just a NAS.

[budwzr]

If I had to do something like this I would draw it out on paper first, and focus on the structure of the user shares, and how files can be moved along a combination of read-only and read/write shares with emphasis on permissions.

Maybe create two or more pipelines? Something like a filing cabinet with three drawers. The first drawer is open to read/write, the second limited to a middle manager, and the third maybe like a final destination.

A system that has stops in place, and doesn't allow moving anything backwards, except by a project manager. This is what share-level security is all about. It allows you to build a ladder that you can climb down from.

I would not use ANY automated process that doesn't allow for manual full rollback including the entire NAS itself. Editing output is far too valuable, and unique to be simply "done over". It's like asking DaVinci to repaint the Mona Lisa, he could never do it exactly the same.

[bhilgenkamp]

And using Macs just further complicates things because their OS is very limited. I don't even know if they have something like Enterprise or Exchange Server

What the heck does Enterprise Server or Exchange have to do with sharing a volume to a few clients?

And FWIW this is a screenshot of my Mac Pro running OS X Server as an example of what OS X can do. BTW those are capital "B"s, as in Bytes/sec.

[JimmyS]

If your budget is slightly below unlimited, you could go with Apples solution. About $1K per seat plus compatible hardware.

http://www.apple.com/xsan/deployments/video.html

[bhilgenkamp]

In the case of conflicts, who would win? How would you know which version had the correct edits? You're going to "watch" the clip? Hahaha.

How often are two editors writing to the exact same location with the exact same file name? I'm guessing rarely, if ever.

What about errors? What if FCP crashes during a render or edit? And creates a corrupted file? Or you have to restore from a backup?

Then delete the corrupted file. Nothing major here.

What if the NAS crashes? Or you need to "roll back"? How are you going to notify and control all the users?

Sounds like he has a few workstations there. I'm guessing he could get up from the chair, walk to each users' desk, and verbally tell them.

A video file is not "distributable" like database tuples. It's just a big chunk. Like a wheelbarrow with one big rock in it. Database date is in pebbles. Pebbles can be numbered, indexed, etc. and DISPLAYED as a rock. A rock cannot be displayed as pebbles.

Not really sure what your metaphor is trying to say here.

Operating a NAS in a shared environment requires a whole IT department.

No, it doesn't.

And using Macs just further complicates things because their OS is very limited. I don't even know if they have something like Enterprise or Exchange Server. And you're going to pay through the nose for anything that advanced.

See my previous post.

If I had to do something like this I would draw it out on paper first, and focus on the structure of the user shares, and how files can be moved along a combination of read-only and read/write shares with emphasis on permissions.

A good idea actually.

Maybe create two or more pipelines? Something like a filing cabinet with three drawers. The first drawer is open to read/write, the second limited to a middle manager, and the third maybe like a final destination.

Overkill for the amount of users' in his scenario.

A system that has stops in place, and doesn't allow moving anything backwards, except by a project manager. This is what share-level security is all about. It allows you to build a ladder that you can climb down from.

Based on his oroginal idea of serving from a Mac Mini this would still be doable.

I would not use ANY automated process that doesn't allow for manual full rollback including the entire NAS itself. Editing output is far too valuable, and unique to be simply "done over". It's like asking DaVinci to repaint the Mona Lisa, he could never do it exactly the same.

Not sure what the "automated process" is you're talkiing about. Just backup your data that can't be recreated and you're done.

The OP just wanted to ask a question. I'm trying to help him. Yes, a FC SAN would be nice, but not everyone can afford that.

[bhilgenkamp]

If your budget is slightly below unlimited, you could go with Apples solution. About $1K per seat plus compatible hardware.

http://www.apple.com/xsan/deployments/video.html

If you're running OS 10.7 then the licensing is free (it's now built in). The other costs are servers, SAN fabric, metadata controllers, FC storage, FC HBAs for each client, cabling, etc. The cost skyrockets really quickly with XSan. Ideal, yes, but also very expensive.

[budwzr]

That XSan system mentioned above is managing the shares and versioning. You'd have to trust it 100%. I don't trust ANY automated system 100%.

If there's a deep bug in there and you happen to stumble on it, your career could be over, hahaha.

[JimmyS]

Apple Xsan has been around since 2005. If it did not work dependably, it would have disapeared long ago and most certainly would not have become a standard feature in OS 10.7.

[bhilgenkamp]

Yeah, I'm curious to see what budwzr thinks is a better solution than Xsan. It's still the de facto standard for shared storage with FCP. And I'm still not sure what he means by "automated system".

[budwzr]

And I'm still not sure what he means by "automated system".

By automated system I mean free to make permanent decisions. If you've ever not received an e-mail from someone because somehow it got into the spam filter, you'll understand.

Databases make sync errors occasionally, nothing is 100% perfect. Even my iPad chokes now and then and has to be rebooted, and that's a closed system that should never crash, right?

[bhilgenkamp]

I guess I'm just not following how that relates to the topic.

[budwzr]

I guess I'm just not following how that relates to the topic.

If a file replicates, gets edited, and the replicas get saved as the source file, that's a problem.

Example: I open file A to change a few things and that burrito I had for lunch sends me running to take a dump. Meanwhile, someone else opened the file and made some changes, then saved it to the server. When I come back from the can and save the file, the intermediary edit gets wiped out.

[bhilgenkamp]

From an older version (10.4) of OS X Server

Unified locking—Mac OS X Server unifies file locking across AFP and SMB/CIFS
protocols. This feature lets users working on multiple platforms simultaneously share
files without worrying about file corruption

[budwzr]

From an older version (10.4) of OS X Server

Unified locking—Mac OS X Server unifies file locking across AFP and SMB/CIFS
protocols. This feature lets users working on multiple platforms simultaneously share
files without worrying about file corruption

Yes, but that's ONE file at a time for one user. Anyone else has to wait.

[bhilgenkamp]

So what you're saying is that User A and User B should both be able to open the same file, edit at the same time, and be able to save all without overwriting the same file?

[budwzr]

So what you're saying is that User A and User B should both be able to open the same file, edit at the same time, and be able to save all without overwriting the same file?

I think that's what the OP had in mind. And that's what Xsan does, that's why it's so expensive.

Managing versioning on a network is a tremendously difficult task, and would require tons of storage space because the replica file(s) can never be closed until all of them are closed. They would get parked.

I'm not saying Xsan can't handle it, but experience has proven to me time and again that when EndUsers are involved they will FIND a way to screw things up. Xsans would have to be completely bulletproof, and no software is. I'm sure there are times when rollbacks have to happen and time will be lost.

But maybe it's worth it in the long run.

[bhilgenkamp]

I think that's what the OP had in mind.

I'm not sure that's what he had in mind. I think he just wanted to have shared storage to all the footage.

And that's what Xsans does, that's why it's so expensive.

That's not what Xsan does, and Xsan itself is quite cheap. The hardware for the SAN is what's expensive.

[budwzr]

Hahaha, I just looked more closely at that Xsans. It does EXACTLY what I described above using share-level security. What a joke. I can't believe Mac users can't even figure out how to set up a NAS manually.

It DOES NOT synchronize replicas, it just makes copies and puts them on your own private share.

[bhilgenkamp]

A - I get feeling you're not an FCP editor. It sounds like you are overthinking this, and your points don't seem to relate to a typical editing workflow. Why would two editors open the same project and edit it at the same time? It just doesn't make any sense.
B - $1k per seat is a drop in the bucket if you're going with a full Xsan configuration. It was also mentioned that this is now free and built in to OS 10.7

I don't know why you're trying so hard to make this sound impossible and extremely error-prone, because it's not.

[budwzr]

OK, I'm gone. Good luck with it.

P.S. Don't you Mac people ever wonder why everyone else can edit and save to all different kinds of video formats and codecs, but you only have ONE? Think about it. Does that sound like a robust system? I wish you guys would wake up and revolt, finally. It would do us ALL much good.