FORUMS: list search recent posts

Sharing

COW Forums : Apple Final Cut Pro X Debates

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
James Ewart
Sharing
on Dec 22, 2013 at 12:16:59 pm

Okay so I get Libraries can be shared now on SANs.

But only by one user at a time. I work alone often and do not often need to share stuff but have a project coming up where there may be a couple of people on different workstations.

Can somebody tell me whether Avid or Premier have the capacity for editors to have access to Media at the same time?


Return to posts index

Oliver Peters
Re: Sharing
on Dec 22, 2013 at 2:13:14 pm

If your media is external to the Library, multiple editors can access the same media with FCP X. That's essentially how FCP 7 and Premiere Pro both works. If you have Media Composer, AMA-linked media files are external and can be accessed, as long as the volumes are READ-ONLY. To have true media sharing (with internally managed media) and Avid project sharing, you need a Unity/ISIS system. EditShare also offers a workaround solution.

In the scenario you describe, FCP X would be perfectly functional. Look through this:
http://ww.10dot1.co.uk/content/FCPXInASharedEnvironment_FINAL.pdf

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

James Ewart
Re: Sharing
on Dec 22, 2013 at 3:04:20 pm
Last Edited By James Ewart on Dec 22, 2013 at 3:43:45 pm

And then two editors can access the same "library" (for want of a better word) and also access the sae individual files?

Does that mean this step with 10.1 from Apple will not satisfy the Avid users?

So what systems do most of the large broadcasters (news sports etc) use? Is Avid their only solution?

Thanks


Return to posts index


Andy Neil
Re: Sharing
on Dec 22, 2013 at 4:20:03 pm

News and sports editing don't really rely on project sharing. At most, they only need media sharing which FCPX can provide. Project sharing is more the workflow of series/reality TV. For this reason, most of those facilities which work on that kind of show use Avid which offers the best project sharing workflow.

However, FCP7 made serious inroads into production facilities (at least here in LA) despite the fact that it never had the ability to project share. It looks like there may be a roadmap to providing better project sharing in X, but as of now it's not any better than FCP7 or Premiere's solutions.

Andy

http://www.timesavertutorials.com


Return to posts index

Ronny Courtens
Re: Sharing
on Dec 22, 2013 at 4:25:01 pm

And then two editors access the same individual files?

Yes, this could be done in earlier versions of FCPX as well.

Does that mean this step with 10.1 from Apple will not satisfy the Avid users?

It certainly seems to satisfy the FCPX users (-:

So what systems do most of the large broadcasters (news sports etc) use? Is Avid their only solution?

Not at all. There are many different options for large-scale media sharing (Quantel, EVS, Signiant just to name a few). In our part of the world Quantel is far more popular among the large broadcasters than Avid.

What you want is much easier: just make sure your media is on a shared storage system that is fast enough to deliver multiple simultaneous video streams in the format you are working with, make sure the media is external to your Library (i.e. using simlinks), and multiple FCPX editors will be able to access these media simultaneously. Nothing really difficult about this.

- Ronny


Return to posts index

Joseph W. Bourke
Re: Sharing
on Dec 22, 2013 at 4:29:14 pm

James -

I can give you some firsthand experience with the AVID/ISIS/Unity system. I worked for 14 years at an ABC affiliate. When I started out, we were still tape and A/B roll systems (1", 3/4", BetaSP). We transitioned to Edit* systems - four of them - for News, Promotions, Creative Services, and a daily half-hour magazine format news show. When content had to be shared, Edit* allowed packaging the content as .zip files. It worked ok, plus we had a network with shared media, but only one user could access it at a time. It wasn't great, mostly for News and Promotions, who regularly shared content, and should have been able to work concurrently on projects.

The people actually using the systems pushed to get some demos of the first Adobe CS packages (we were already using AE, Photoshop, and Illustrator), but engineering and the corporate owners pushed for AVID, who had given them a convincing dog and pony show.

They purchased four AVID/ISIS/Unity systems, and from that point on the problems began. What was touted as a system on which users could share projects, turned into a nightmare. Regular crashes locked editors out, and days were spent relinking media, on systems we were told would not work this way. Thousands of dollars were spent bringing AVID engineers in to troubleshoot, production efficiency tanked, and way too much time was spent fixing problems.

After a couple of years of this, we finally convinced the corporate powers to bring in a test workstation running the Adobe CS (I think in was CS3 at the time) suite. It ran circles around the AVID systems, although the multi-user capability (which never really worked well) was gone. But the 30 to 40 percent increase in production efficiency with the Adobe Creative Suites took away the constant fear of crashes at deadlines, and other nightmares inherent with the AVID system. I was in charge of organizing all of our facility media, and I had set up a system (using Adobe Bridge) by which anyone could find any media in a very short space of time, so the loss of multi-tasking was not missed.

Other AVID system users may have a totally different experience, but ours was one in which AVID became the problem, and the Adobe Creative Suite was the solution. Ultimately, all 28 stations went over to the Adobe systems, and the AVIDs are occasionally used for tape capture stations, and are otherwise gathering dust. It was an extremely expensive experiment which didn't work out.

Here's a press release from the time period in which the changeover to Adobe occurred:
https://www.adobe.com/content/dam/Adobe/en/casestudies/creativesuite/produc...

Joe Bourke
Owner/Creative Director
Bourke Media
http://www.bourkemedia.com


Return to posts index


Mark Raudonis
Re: Sharing
on Dec 22, 2013 at 9:42:20 pm

Joe,

You point out that other AVID users may have different experiences, and so I feel should offer up my experience as a counterpoint to what you've described. I don't know the details of what precipitated your
issues, but I can only say that we simply could NOT do what we do (Large scale reality TV shows) without some form of successful project sharing.

We certainly pioneered that workflow with FCP 7 and scaled it up to hundreds of users over three X-SANs.
When we chose to NOT use FCP -X we switched to AVID/ISIS 5000, and again scaled that to hundreds of users over multiple ISIS systems.

You can criticize AVID for their conservative development pace on MEDIA composer, but as far as the ISIS and storage are concerned, it has been ROCK SOLID for years. It just works. Day in day out, with hundreds of users accessing multiple shows. I can't even begin to wrap my head around how we'd do this with FCP-X's scheme. Yes, I read the white paper from those folks in the UK. It gave me a headache.



Return to posts index

Oliver Peters
Re: Sharing
on Dec 22, 2013 at 10:42:57 pm

[Mark Raudonis] "You can criticize AVID for their conservative development pace on MEDIA composer, but as far as the ISIS and storage are concerned, it has been ROCK SOLID for years. It just works. Day in day out, with hundreds of users accessing multiple shows"

I'm with Mark on this one. I do a number of film editor interviews throughout the year and the majority of these editors work on Avid systems. Almost everyone uses an ISIS set-up that frequently connects 5-20 systems, once you count the assistants, VFX editors, etc. They all love it. These are folks who are truly working collaboratively on one project, not bouncing around copies of projects. Since ISIS is ethernet-based, it's also easy for them to add more units, like a laptop, simply by connecting to the system.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Chris Harlan
Re: Sharing
on Dec 23, 2013 at 7:33:21 am

[Oliver Peters] "I'm with Mark on this one. "

A hearty "me too."


Return to posts index


James Ewart
Re: Sharing
on Dec 23, 2013 at 7:47:16 am
Last Edited By James Ewart on Dec 23, 2013 at 8:06:50 am

For what it's worth I do not know of any facilities house (not even small ones) in the UK offing FCPX support. (I do know of one boutique facility where they are taking a serous look).

Not something with which I am pleased (I like to have somewhere to go for finishing) and I have said many times before the Uk were not wary adopters of Legacy.

Does anybody know if The Mill are using FCPX at all for pulling all their stuff together?


Return to posts index

Pete Fausone
Re: Sharing
on Dec 23, 2013 at 2:46:30 pm
Last Edited By Pete Fausone on Dec 23, 2013 at 9:50:38 pm

[Mark Raudonis] "I can't even begin to wrap my head around how we'd do this with FCP-X's scheme. Yes, I read the white paper from those folks in the UK. It gave me a headache."

I do post end to end for network episodic television. Mark is absolutely right on this point. People who keep talking FCPX aren't doing the same workflows
that need something like an ISIS. The new EVO by Studio Network Solutions looks promising and would greatly lower the cost of shared media for Avid or FCP 7.
FCPX is just a non starter in the big leagues. Sorry but that's just the fact. People will take offense to this statement but then you have to look at what they are doing. Now as everyone chimes in on how well FCPX works, look at what they are doing as compared to what Mark is doing.

Pete



Return to posts index

James Ewart
Re: Sharing
on Dec 23, 2013 at 3:49:36 pm
Last Edited By James Ewart on Dec 23, 2013 at 4:32:30 pm

"ISIS 7500 is designed by media professionals for media professionals to address their unique storage needs. Not only does it enable collaboration, it encourages it, allowing more than 300 Avid and non-Avid editors to connect concurrently and simultaneously share the same SD, HD, and high-res media in real time".

Does this really mean that 200 editors can be accessing the same file for their edits concurrently? And all play back a timeline with a clip from that file in their timelines at the same time?

I am beginning get the point here. We are talking good old fashioned broadcast engineering are we not.


Return to posts index


Mark Raudonis
Re: Sharing
on Dec 23, 2013 at 4:31:16 pm

[James Ewart] "Does this really mean that 200 editors can be accessing the sam file for their edits concurrently? And all play back a timeline with a clip from that file in their timelines at the same time?"

Yes! That is exactly what that means. Media lives in ONE location. Anyone with access to the system can use that media AT THE SAME TIME. No copying, no moving, just find it and use it.

EVERYTHING that we do uses more than one editor. At the very least we have an editor and an assistant editor collaborate on a cut. More likely, it is 20-25 people all collaborating on a cut, an episode, a series. So, while most people debate the merits of the "X" timeline, or 4K resolution, I focus on shared workflow. This latest change in "shared libraries" is a step in the right direction, but there's quite a long journey ahead for anyone to deploy "X" at scale.



Return to posts index

James Ewart
Re: Sharing
on Dec 23, 2013 at 4:36:52 pm

I am struggling to get my head round that. Instant? No buffering or delay like on Sky Movies or planes?

The editors can all rename these clips in their "bins" without affecting the names of the original files?

(FCP 7) was really annoying with this. X does not seem to care what you call the clips in your bins/events.


Return to posts index

Mark Raudonis
Re: Sharing
on Dec 23, 2013 at 5:02:18 pm

[James Ewart] "No buffering or delay like on Sky Movies or planes?"

No delay.

Seriously. Click and play.

RE: Renaming. AVID allows for renaming, since it maintains it's own internal database to keep track of every object as a unique item. However, from a practical POV, we do NOT allow editors to do that. It would simply be too confusing for other team members to find something. Therefore, we maintain a logical naming system such as 1225A01CC = (Translation: December 25, A cam, 1st load, Creative Cow).
If you want to rename a clip "swish pan to CU", then put that in the notes column!



Return to posts index


James Ewart
Re: Sharing
on Dec 23, 2013 at 5:09:10 pm

What If I have already made a note in the column for that clip like "swoosh to CU - VG"?

Could I personalise it? Or do my log notes get transposes onto the data of the original clip with Avid?

Who gets to do the original log notes?

Because it seems with FCP X it does not matter if I rename the clip it does not affect its name of the original clip in the "Library".

Hope that question is not banal.


Return to posts index

Andy Neil
Re: Sharing
on Dec 23, 2013 at 5:34:00 pm

[James Ewart] "What If I have already made a note in the column for that clip like "swoosh to CU - VG"?

Could I personalise it? Or do my log notes get transposes onto the data of the original clip with Avid?"


Avid rights and permissions are bin-based. On the hard drive the "project" is really just a folder with .avb files which represent the various bins in the project. As one editor accesses a bin by opening it, they lock the other editors out and retain the only means by which to write to that bin. All other editors can view the contents of the bin and even use the clips inside to continue editing, but they can't save any new clips to that bin or rename anything.

The owner of the bin however, can do both. If they injest a new clip to that bin or rename an existing clip, it will show up to other editors after the owner has saved the bin. Once you close a bin, you lose the lock and the next editor to open it will have permission to make changes.

How this translates to a workflow: Editors who work on the same show typically work on sequences which represent a block or "act" of a show. Each sequence is usually in a separate bin because otherwise only one editor would be able to make changes to those sequences. Editors also typically create their own folders inside a project to organize bins specific to how they like to work. That way, if you needed to organize some clips into a particular order, you'd create a custom bin for that which would live in your folder for easy access. This keeps editors from messing around with the organized bins in a project which contain the main media for editing. That stuff was already organized by the AEs and shouldn't be touched or changed by individual editors because it could screw everyone up.

Andy

http://www.timesavertutorials.com


Return to posts index

Dom Silverio
Re: Sharing
on Dec 24, 2013 at 11:39:23 pm

You can create your own column (e.g. "comment 2")that will travel with the clips.


Return to posts index


Herb Sevush
Re: Sharing
on Dec 23, 2013 at 5:18:44 pm

[Mark Raudonis] "Therefore, we maintain a logical naming system such as 1225A01CC = (Translation: December 25, A cam, 1st load, Creative Cow). If you want to rename a clip "swish pan to CU", then put that in the notes column!"

The importance of proper clip naming conventions cannot be stressed enough. Because of adhering to strict naming conventions I am able to get a lot more power out of the sorting and search features in FCP7. This is one of the reasons I prefer the Aja Ki-Pro to all other digital recorders - it has master control software that enables comprehensive clip naming during production over multiple recorders.

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

James Ewart
Re: Sharing
on Dec 23, 2013 at 5:52:36 pm

Thanks I'm just wondering what options the 200 different editors have for personalising the clips they see in their bins with Avid without affecting the original media file logging notes?


Return to posts index

Andy Neil
Re: Sharing
on Dec 23, 2013 at 6:13:38 pm

Don't get caught up on the 200 editors thing. No one has 200 editors working on the same show. What Mark is describing is a facility that cuts dozens of shows with thousands of media clips being accessed by not only editors, but story producers, logging PAs, and other people who don't actually edit with the clips but sometimes need to view them.

The most important logging info that is added to clips in these shops by the AEs is right there in the name of the clip. That's why most shops use some kind of logical naming convention like Mark said. Avid has numerous other ways that individual editors organize their clips. They copy clips into separate bins, they color label, the assign markers and type comments into the markers, they create sub-clips and store the sub-clips in their personal bins.

Andy

http://www.timesavertutorials.com


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 23, 2013 at 5:13:26 pm

[Mark Raudonis] "Yes! That is exactly what that means. Media lives in ONE location. Anyone with access to the system can use that media AT THE SAME TIME. No copying, no moving, just find it and use it."

To be fair, all major NLEs can do this, including FCPX. We do it all the time.

That's not the tricky part. The tricky part is seeing what everyone else is doing and being able to use parts of their projects and have them update in real time. Or giving back write permissions so someone else can take over from where you left off.

Currently, Avid wins in this regard, although Lightworks has some capabilities too.


Return to posts index

Neil Sadwelkar
Re: Sharing
on Dec 23, 2013 at 5:58:07 am

Joseph,
Were these systems PC or Mac?
And what year was it when you tried out Avid in a shared environment?

Avid project sharing on Mac using Unity has been reasonably painless since 2010.

-----------------------------------
Neil Sadwelkar
neilsadwelkar.blogspot.com
twitter: fcpguru
FCP Editor, Edit systems consultant
Mumbai India


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 22, 2013 at 4:30:41 pm
Last Edited By Jeremy Garchow on Dec 22, 2013 at 4:33:12 pm

Unfortunately, FCPX can't mount read only databases.

I highly recommend you take a few minutes and read the document that Oliver links.

I do have a few quibbles as it mentions an NFS mounted NAS.

John Davidson tried it, and while libraries do work without sparse bundles, it causes other problems like failed Ae renders.

Also, read this and the very last section goes through a potential collaboration scenario: http://images.apple.com/final-cut-pro/docs/Media_Management.pdf

Don't expect to be able to see each other's libraries in real time, or share one library between multiple users at the same time. You can share media in real time.

Avid comes closest to real time sharing, but there are still user based lockouts that have to happen.

Jeremy


Return to posts index

Bob Zelin
Re: Sharing
on Dec 22, 2013 at 5:22:40 pm

that's right boys - FCP X 10.1 sharing only works with an NFS network right now - not AFP, or SMB. I just went thru this with John Davidson (and both of us are upset about this). In the old days (a few days ago), this is how we got "Add SAN Location" to work too (via NFS network) - and this is also now the case with Libraries.
I would LOVE for Apple to discuss this on some forum somewhere !

Bob Zelin

Bob Zelin
Rescue 1, Inc.
maxavid@cfl.rr.com


Return to posts index

John Davidson
Re: Sharing
on Dec 22, 2013 at 7:49:25 pm

You know what I just thought about Bob? We could have set our mount point in NFS manager to be ONLY the subfolders I use for Libraries and not the whole dang RAID. This would give us the benefits of NFS mounting and still kept iTunes over NAS on AFP, After Effects wouldn't have face melted on renders to the NAS, and my overall speeds would have been fine.

That solution would still result in slower FCPX connection to the Library, but the media kept in a different location would still get the benefit of AFP's faster speeds, so that might actually work.

John Davidson | President / Creative Director | Magic Feather Inc.


Return to posts index

John Davidson
Re: Sharing
on Dec 22, 2013 at 7:50:12 pm

But I'm taking the day off today so I"ll test that tomorrow :).

John Davidson | President / Creative Director | Magic Feather Inc.


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 22, 2013 at 5:43:18 pm

Apple thinks of networked storage as if of could. It's just files repository. Of course you can link your original files to several libraries owned by different users to have a multiple access to the same media files - but the metadata database is designed for single user only. Making a library or event read only would do a part of a job, but a real solution is probably of a kind Adobe has developed along with its' Prelude. Here you have a text file that's stored along with the media file - this is where the metadata description is being stored. So what gets blocked from multiple access is the metadata of the clip that's being edited by someone over a network. You can still have access to everything else in the folder (which translates to event pretty much in FCPX).


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 22, 2013 at 6:30:39 pm

If read only Libraries were allowed in fcpx, you'd have a very similar (but not same) situation to Avid bin locking.

It's a lot more than metadata.

Events can have clips, metadata, edited sequences with effects, multicam clips/sync, and whatever else you need and you don't have to leave the interface for another one.

You'd then be able to merge your 'local' Event with the read only.

But alas, it isn't available.


Return to posts index

Oliver Peters
Re: Sharing
on Dec 22, 2013 at 10:38:00 pm

[James Ewart] "And then two editors can access the same "library" (for want of a better word) and also access the sae individual files?"

Libraries, no. Not simultaneously. If the Libraries are liked to external media, then in theory two editors could have local, mirrored Libraries that each link to the same set of media files on a common SAN volume.

[James Ewart] "Does that mean this step with 10.1 from Apple will not satisfy the Avid users?"

The FCP/PPro approach is so far away from what Avid does, it isn't even funny. Whether you need what Avid offers - or have the IT knowledge or resources to support it - is a different matter.

[James Ewart] "So what systems do most of the large broadcasters (news sports etc) use? Is Avid their only solution?"

I worked in some mixed environments where news/sports is connected to Avid and promos/creative services uses FCP or Premiere.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 22, 2013 at 5:25:30 pm

Adobe lets you access your media file just as you'd naturally do it - simply importing them from a network (San or other) location. It's then up to the bandwidth available how many users can really use this for editing. Pretty much the same what was available in FCP 7.

Plus Adobe has this nice solution to reduce playback resolution. The result is pretty much the same as if you used some proxy files - except you don't need to generate them. The soft just reads every other pixel of the video (half the resolution or every fourth if you choose quarter the resolution) the result is that dropped frames vanish and you see smooth playback with frames slightly blurred (hardly visible in most cases).

Plus - Adobe's Prelude stores metadata descriptions within test files that are stored along with media files. Any time you import such media into a PremierePro project, the metadata is loaded as well. Even more - PrepierePro refreshes media at time intervals so from within it you can see new metadata coming up as someone else in the network adds new records to the database.

Adobe's database design is poorer than the one FCPX provides, but it's a real multiuser accessible database. In FCP you can only have a single user connected at a time. But there's no way to have multiclips or preedited sequencies described that way in Premiere / Prelude. FCPX allows for that which is great.


Return to posts index

Michael Sanders
Re: Sharing
on Dec 22, 2013 at 8:28:59 pm

Ive said it elsewhere but would it really be problematic if a library and event was shared but a project or compound clip was locked?

Michael Sanders
London Based DP/Editor


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 22, 2013 at 8:43:22 pm

[Michael Sanders] "Ive said it elsewhere but would it really be problematic if a library and event was shared but a project or compound clip was locked?"

Yes.

To use a really crappy car analogy, you can't have two drivers trying to drive the same car in different directions at the same time.

If two people have access to a Library, and both can write to it at the same time, things will get screwy.


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 22, 2013 at 9:26:45 pm

I think you're wrong. The database is useful if and only if there's a bunch of people that can access and use it. This is most of all about read (and not write) access - which is something not at all allowed under FCPX. You can have a single user accessing a "shared" library at a time. Normally - speaking of databases - you should have a crowd of them. Plus this crowd should instantly see updates made by those who have sufficient privileges. This is not at all possible and even though of in FCPX, which is a shame. So the car analogy doesn't really apply here. What we need is several drivers seeing the same street lights, right?


Return to posts index

Oliver Peters
Re: Sharing
on Dec 22, 2013 at 10:47:47 pm

[Pawel Kasprzak] "The database is useful if and only if there's a bunch of people that can access and use it. "

I wish folks would get over the whole "FCP X is a database" mantra, because it simply is not true. At least not anymore or less than any other NLE. It is not an asset management tool. If you want an actual media database that can be accessed from a range of access points, then look at Avid Interplay, Apple Final Cut Server (now dead), Cat DV or Axle.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 22, 2013 at 11:21:05 pm

It's actually less than it was in FCP 7. Then you could create a project file, make it read only and this project would store the metadata descriptions you needed for a networked workflow. This can't be done now which is a shame really, even though the potentials of database architecture are really great.

I think what's still missing in asset management tools like CatDV is that you can only work directly on media files and not on multiclips or compound clips the way FCPX handles them.

What's also important for networked strategies is how media and metadata are organized. In FCPX you have no other choice that to store everything on the same drive. The only flexibility you have (thanks God) is to leave imported media files where they are, not really copying them. Unfortunately you're not free to do the same with proxies. Nd you badly need proxies when it comes to editing more that 4 streams of HD in multiclips. All proxies or optimized media must reside on the same drive where the rest of your event stuff is recorded. When it comes to San strategies (this is never mentioned in Apple's whitepapers) you end up having media files (so proxies most of all) saved along with billions of tiny thumbnail, audio peaks and other data files, which make your San volume (optimized for large media files) go crazy. Block size parameter remains an issue as well if you choose to store everything locally.


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 23, 2013 at 5:31:06 pm

Almost every NLE creates little tiny cache files, even Avid, even FCP7.

You can stripe your array to help with this process, and our SAN has adjustments that you can make per client for help with this if it ever becomes a problem. It hasn't been a problem for us. Pr used to give us fits with it's constant caching, but an update to Pr solved it.

With FCPX, you don't have to keep the files on the SAN if you don't want to. Moving things around is very very easy.

Every new mac with PCIe storage, regardless of CPU/GPU/Computer power or form factor, has storage that is probably faster than all but the fastest of RAIDS. That sharing PDF that is floating around mentions this.

This means that, for the first time, the SAN is actually the 'bottleneck' in terms of throughput. This, of course, presents new ways of working and perhaps new ways of thinking about what and where media needs to be, and how a team accesses media.

You don't have to believe in what Apple seems to be doing, but in my mind, these aren't half baked ideas despite FCPX not having this capability at launch.


Return to posts index

James Ewart
Re: Sharing
on Dec 23, 2013 at 5:54:02 pm

It looks like it will work for me well. Two editors and one or two assistants.


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 23, 2013 at 8:18:14 pm

Jeremy,

True - back in the old days of FCP 7 and previous versions there were tiny little files as well. At our site we badly needed a central storage of media files and these included render files (so that each sequence could be opened rendered on any of the edit stations). But also cache files (especially waveform cache) were needed - these had to be common as well so that every editor could see them correctly. These - as you sure remember - were kept in a flat structure (single folder), there were lots of them and they were small in size. Stored on xSan volume they tended to slow the entire system down dramatically, so we learned to use another drive (just HFS+ formatted) and everything worked fine.

Such choices are not possible in FCPX anymore. Of course you can use media files that are external to your event folder, but proxies must be kept along with the rest of event. And we badly need proxies, typically using 9 angles multiclips, sound recorded as multiple separate files that must play in sync etc. We typically have way more than a 100 hours of video within a single episode we make and what we actually need is a common pool of over a 1000 hours of video. It's not only a matter of bandwidth but also the fact that some 40 different files are being read on playback at a time. So we have the same volume for everything, the same block size parameter, while in fact this is an either-or choice. Our events tend to swell and beyond some level the system slows (I don't know what really matters here and can only guess - the overall size of the media, the complexity, the sheer number of clips). It takes forever to get an event open and you have to wait quite a while before your playback starts. Pretty annoying when you try to edit to the music so that people dance to it or something. I can't be sure what really causes these performance issues but my bet is that file sizes and inappropriate block sizes are one of the reasons.

You're right - San can be and in fact is a bottleneck for our production, but avoiding San storage solves only a half of the problems we face. We still need RAIDs (even though local) and the formatting optimization remains a problem.

Plus the database mantra as someone pointed this out here - it's a sheer absurd. I myself love the way keywords collections are organized (still some bugs in it though). But what's the use of the database only single user can read at a time?

I am now in charge of another major production here which we chose to do with FCPX and we are having hard time here. Adobe and Premiere Pro is still an option for us. I don't have to generate proxy files - if my San network proves a bottleneck (well it should easily allow for the transfers required, even though it involves 9 streams of HD video plus numerous audio tracks) we can always switch to half or quarter resolution and everything works just fine. It's way faster than switching to proxy playback in FCPX plus I don't need to render and store those files. Adobe's Prelude solution for metadata works fine as well - only the metadata coming with the file that's currently being edited is not accessible (to write - not to read) by other users. The only reason we actually went for FCPX now is that it offers kewords for multiclips and compound clips. I'm now not sure if it was really worthy as several overlapping ranges in keywords (and that's what we need) cause errors.

After years spent with FCP we find it easier to switch to Adobe as it is simply more similar to old FCP. The advantages of FCPX are clear, but I feel it's still a promise rather than a fact.


Return to posts index

Walter Soyka
Re: Sharing
on Dec 23, 2013 at 8:36:14 pm

[Pawel Kasprzak] "if my San network proves a bottleneck (well it should easily allow for the transfers required, even though it involves 9 streams of HD video plus numerous audio tracks) we can always switch to half or quarter resolution and everything works just fine. It's way faster than switching to proxy playback in FCPX plus I don't need to render and store those files. "

I don't think lowering the resolution will save you any disk bandwidth. Frame data is usually compressed and always encoded. Any application has to read the entire compressed frame from disk before it can decompress it for processing.

Even with bayered or wavelet-encoded media, you still have to read the frame data and reducing resolution usually just saves on processing time.

Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog - What I'm thinking when my workstation's thinking
Creative Cow Forum Host: Live & Stage Events


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 23, 2013 at 9:11:09 pm

[Walter Soyka] "I don't think lowering the resolution will save you any disk bandwidth. Frame data is usually compressed and always encoded. Any application has to read the entire compressed frame from disk before it can decompress it for processing."

This is what makes me wonder. I haven't got the slightest idea how this is done, but I saw disk transfers on playback and it decreased when playback got switched to lowered resolution. As if Premiere was reading every other pixel - amazing considering what you wrote, true for sure. As if they got their way into the codec's compression algorithms being able to still read sort of half the data required. Just give it a test - you get dropped frames on full res playback (clearly due to transfer issues), you switch and dropped frames vanish plus you see decreased network / disk transfers.


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 23, 2013 at 8:54:49 pm

[Pawel Kasprzak] "Such choices are not possible in FCPX anymore. "

Yes, the separation of render files from the Event has been a long standing feature request.

And now the ability to separate Generated media out of the Library would also be welcome for all the reasons you state.

For now, you have to do this manually, or generate proxies at every station, locally. Each of these is not ideal, of course.

I am finding that performance with 10.1 seems to be markedly improved. Events/Libraries load much faster, thumbnails load much faster and don't seem to slow things down as much. All in all, I think this is a very significant update.

[Pawel Kasprzak] "Plus the database mantra as someone pointed this out here - it's a sheer absurd. I myself love the way keywords collections are organized (still some bugs in it though). But what's the use of the database only single user can read at a time?"

Yes. I don't know why you can't load a read only Library in FCPX. It seems odd, and it would only seem to add capability in sharing.

FCPX allows a user to change playback quality as well, not as many options as Adobe, but it is an option.

Have you done much testing with Pr on your SAN?


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 23, 2013 at 9:26:05 pm

Jeremy,

No - I'm pretty new to Premiere, but so far I love what I see. I will for sure test it more. And our tests are really going to be crash tests - considering this lots of media we use, concurrent video streams we play etc.

It's interesting what you mention about manually moving the proxies outside the event folder. I tried this - the proxies were stored on our xSan volume and took some tricks to fool FCPX into reading it from there. It didn't work though - I got dropped frames which made editing impossible.

Looking at the transfers I thought FCPX reads San data some other way FCP 7 did. Reading multiclips from San under FCP7 you see pretty much constant transfer rate, under FCPX it gets jumpy.

The only configuration I find working is to store everything locally. New iMacs plus one of those LaCie 20TB thunderbolt arrays seem really great solution, OpenCL acceleration works great etc. Still - as our events swell we are in trouble. Pretty annoying to wait half a day for your events to get updated when your deadline is coming up...


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 22, 2013 at 10:48:48 pm

They can both be riding in the same car, but only one person is driving.

You can't have two drivers, one steering wheel, and multiple destinations.

I'm not "wrong", but it's fine of you think that way, it's just a crappy analogy.

Even with Avid, you can't have two people writing to the same bin at the same time.

Only one person can write to a bin, everyone else can read.

One driver. Many passengers.

Or many drivers in their own cars tracking everyone else's location.

If FCPX allowed read only, it would work somewhat similarly.

You could look at my library and borrow from it, I could look at your library and borrow from it, but we could only change the contents of our own respective Libraries.


Return to posts index

John Davidson
Re: Sharing
on Dec 23, 2013 at 12:05:25 am

[Jeremy Garchow] "You could look at my library and borrow from it, I could look at your library and borrow from it, but we could only change the contents of our own respective Libraries.
"


So it's like...you can pick your nose. And your friend can pick his nose. But you can't pick your friends nose?

John Davidson | President / Creative Director | Magic Feather Inc.


Return to posts index

Oliver Peters
Re: Sharing
on Dec 23, 2013 at 12:57:41 am

[James Ewart] "Can somebody tell me whether Avid or Premier have the capacity for editors to have access to Media at the same time"

Let me add a bit about Premiere Pro, since I've come off of a week-long broadcast gig running PPro in a SAN environment. This is a station that shifted their production edit bays from FCP/XSAN to PCs running Premiere Pro CS6 (not CC yet). They have a fibre SAN using Promise arrays. The content is usually spots for clients and broadcast station promos. Plus a lot of content for the web. Also some 30/60-minute TV shows.

The SAN is file-level locking, like XSAN, so anyone can read/write and the storage shows up as a single drive. Content is organized within various folders and subfolders on the SAN. PPro project files are saved within the appropriate folder along with elements. Media may or may not be saved in the same folder.

The need for sharing is to be able to access any project from any room. Not multiple editors working on one project concurrently. Premiere does this reasonably well with a couple of exceptions. CS6 wants to "conform" all MXF media. This appears to be stored locally (in spite of settings) - at least with CS6. Therefore, if you started in one room and the next day move to another, the files will have to be conformed again in the new room.

The second complaint I have is that only one project can be opened at a time. With FCP 7, you could have multiple projects open and a project could contain only an edited sequence without any master clips. This made it easy in a shared environment to copy a sequence to a new, blank project and save it. Then another editor could open this and do edits to it. With Premiere Pro, you have to import sequences from one project into another. It's workable, but not as simple as in the FCP 7 days.

On the plus side, Premiere strikes me as the absolute best NLE if you want to deal with native media. There isn't another NLE that deals as well with a mishmash of oddball media files, with the exception maybe of Vegas. Build a sequence of mixed camera formats, frame rates and frame sizes? No problem. Friday I had to use FLV files that were temp comps for stock footage. Premiere was perfectly happy with this. I definitely don't advocate native files, but if that's how you want to work, Premiere does a good job.

- Oliver

Oliver Peters Post Production Services, LLC
Orlando, FL
http://www.oliverpeters.com


Return to posts index

Jeremy Garchow
Re: Sharing
on Dec 23, 2013 at 5:51:55 am

[John Davidson] "So it's like...you can pick your nose. And your friend can pick his nose. But you can't pick your friends nose?"







Return to posts index

Herb Sevush
Re: Sharing
on Dec 23, 2013 at 2:09:45 pm

one of my all time favorite movies.

"Princeton can use a guy like you."

"My name is Joel Goodson.
I deal in human fulfillment.
Last nite I grossed over eight thousand dollars."

Herb Sevush
Zebra Productions
---------------------------
nothin' attached to nothin'
"Deciding the spine is the process of editing" F. Bieberkopf


Return to posts index

Joseph W. Bourke
@John
on Dec 23, 2013 at 10:40:52 pm

And of course, you can't wipe your friends on your lapel...

Joe Bourke
Owner/Creative Director
Bourke Media
http://www.bourkemedia.com


Return to posts index

Pawel Kasprzak
Re: Sharing
on Dec 23, 2013 at 9:42:28 pm

[Jeremy Garchow] "Even with Avid, you can't have two people writing to th"

What Avid offers is still not really a database. In a database system only a single record in the database gets blocked and only for editing when some (authorized) user keeps working on it. Others can still read it seeing this record with data prior to last changes. The rest of the bin, folder or table remains accessible (according to privileges) to others in the network. Adobe did it pretty much this way.

You edit files metadata with the soft called Prelude there. What it does is it adds a text file that shares the same file name with your media. This file stores subclip information for use in Premiere and is saved in the same location as media file. Each time you import media to Premiere, the data from this file gets loaded as well. Even more - Premiere uploads current versions of metadata files on configurable time intervals, so from within your Premiere project you see current updates showing up as your loggers add new data. Certainly this all works in the network and only the file corresponding to a single media file that's being edited gets blocked for editing, being readable for others.

I think the car analogy doesn't really apply here. It's not just car - it's a spaceship or something :) It's being steered by a crew of people.


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]