NFS capture with FCP 6
by Anthony Paremal
on
Feb 14, 2008 at 1:18:19 pm
Hi,
Currently we are using two intel Mac Pros, one G5 and one G4. All are connected using gigabit ethernet.
The gigabit switch is Linksys 24 port model with web control.
The video server is Gentoo Linux with NFS Version 3.
So far all is working great. We are using NFS version 3 over UDP.
The video captured are DVC Pro 50 and normal DV. We did some simple test with DVC Pro HD and it seems to work and need to do more testing with DVC Pro HD.
We are capturing and editing directly into/from the linux server using NFS over UDP.
Here comes the real question.
We noticed that on OS X 10.4 and FCP 6, the video files on the server are broken into 2Gb files.
On OS X 10.3 and FCP 4.5, the video files are larger than 2Gb. There seems to be no limit. On both the tests, the server is the same linux server running NFS version 3.
We than took a 5Gb video file and dragged it to the nfs server . The file stayed as one file of 5Gb. This test was done on Mac OS X version 10.3 and 10.4.
Wanted to know if anyone eles is encountering the same behaviour?
It seems that FCP 6 is causing this. I do not think the os is the issue. FCP 4.5 does not break the file into smaller files.
In both the FCP preference the file size limit is not ticked.
Re: NFS capture with FCP 6 by Kevin Monahan on Feb 14, 2008 at 7:41:24 pm
In the Windows realm, there is a 2GB limit to QT files. Not sure why it works in 4.5, perhaps a fluke?
The only way multiple FCP stations are supposed to work is via Xsan. Have you tried that? Everything else is not supported. Amazing that you've got works so far, even with its limitations.
Re: NFS capture with FCP 6 by Michael Hancock on Feb 14, 2008 at 11:01:22 pm
[Kevin Monahan]"In the Windows realm, there is a 2GB limit to QT files."
Actually, that's wrong. There's a 2GB limit to FAT-32 formatted drives, which is the only drive formatting that can be seen by both Windows and the Mac OS without additional software. It's a limitation of the drive formatting, not Windows. I've rendered out 40 and 50GB quicktime files from After Effects on our Windows machines, but the drives were formatted to NTFS. You'd need Macdrive or a similar program to use these drives on a Mac.
Re: NFS capture with FCP 6 by Jack McGee on Feb 14, 2008 at 10:41:45 pm
I don't the particular answer to your problem, but maybe related to ours. We drop self contained quicktime movies onto a networked (windows) Cleaner machine. We cannot make Final Cut Pro render the file across the network. It's been awhile, but I think it was file size related. However, we can create the self contained movie on the mac and copy it to the networked drive just fine.
Re: NFS capture with FCP 6 by Shai Harmelin on Apr 1, 2008 at 7:47:03 am
Hi,
I'm seeing the same behavior on other NFS servers: FreeBSD 6 and Solaris 9. Interestingly when I use an Xserver 10.4.9 as the NFS server the capture does not get split into 2GB files. The only difference I can tell is in the NFS server FSINFO response in which the max file size is set to 'FFFF FFFF FFFF FFFF' (all '1's). All other NFS servers max file size is 4TB. Maybe there's some unspoken agreement between Max clients and servers to not split files if the NFS max file size is set to all '1's but that is purely a shot in the dark.
If you find a solution or have a different theory please let me know.
Re: NFS capture with FCP 6 by Anthony Paremal on May 15, 2008 at 7:06:52 pm
Just in case someone needs to know this information. Please note that I am not a
programmer. I am just hacking away.
Most of the credit for the hack goes to the person in the forum mentioned above
for finding the Mac NFS behavior.
The changes done seem to work well. I am dissapointed that Apple make changes to
NFS to a point that we have to use an Apple NFS. I thought that NFS is open.
Anyway this problem only happens from with in the video editing application,
Final Cut Pro, an Apple product. I hope someday a good video editing application
comes to Linux. I am willing to pay for Linux video editing application. It must
be good that is.