Final Cut Server Edit Proxy

Question

Hi,
I need to do remote editing (with FCP7) over small bandwith WAN (1Mbps) therefore I configure Final Cut Server (V1.5.1) Edit Proxy to use a Quicktime H.264 codec with the following parameters:
File Extension: mov
Estimated size: unknown
Audio Encoder
AAC, Stereo (L R), 48.000 kHz
Video Encoder
Format: QT
Width: (100% of source)
Height: (100% of source)
Pixel aspect ratio: Default
Crop: None
Padding: None
Frame rate: (100% of source)
Frame Controls: Automatically selected: Off
Codec Type: H.264
Multi-pass: Off, frame reorder: On
Pixel depth: 24
Spatial quality: 0
Min. Spatial quality: 25
Temporal quality: 50
Min. temporal quality: 25
The workflow is:
The remote editor choose on Final Cut Server the FCP project he has to work on, do a Check Out of the project on his Final cut Pro 7 local station by selecting "use: edit proxy" and "keep media with project". Project and associated footage are then uploaded from the server to the remote FCP7 station with no problem.
When the upload is complete, the editor simply open the project file to start editing on his station. This workflow was working allright till january: when opening the project the FCP7 doesn't reconnect the media with an error message:
"one or more of the updates requested by Final Cut Server could not be applied. (one or more replacement (s) had unexpected track setting.)" and media files are Offline! When trying to reconnect manually by indicating the proper path for the missing files, I have to uncheck "Matched Name and reel only" to select the edit proxy files. It looks like it was still linked with the original media...
Looking at the project file, the paths for the proxy files are the proper ones...
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>fileSubs</key>
<array>
<dict>
<key>newurl</key>
<string>file://localhost/Users/XXXXX/Desktop/testbdw10/media/_FCS__XXX.XXX.XXX.XXX/dev/3/1670_179_004301.mov</string>
<key>originalurl</key>
<string>file://localhost/Macintosh%20HD/Users/XXXXX/Documents/Final%20Cut%20Pro%20Docume nts/Capture%20Scratch/Untitled%20Project%201/179004301.mov</string>
</dict>
<dict>
<key>newurl</key>
<string>file://localhost/Users/XXXXX/Desktop/testbdw10/media/_FCS__xxx.xxx.xxx.xxx/dev/3/1674_179_003601.mov</string>
<key>originalurl</key>
<string>file://localhost/Macintosh%20HD/Users/XXXX/Documents/Final%20Cut%20Pro%20Documen ts/Capture%20Scratch/Untitled%20Project%201/179003601.mov</string>
</dict>
</array>
<key>version</key>
<integer>0</integer>
<key>versionMin</key>
<integer>0</integer>
</dict>
</plist>
If I change the Edit Proxy setting for ProRes 422 (Proxy) on Final Cut Server edit proxy setting then the reconnection is working OK. I cannot use this workaround as the files are then far too big to be tranferred over a 1Mbps WAN.
The setup with the Quicktime H.264 edit proxy was working fine after, it seems, the installation of Pro applications update 2009-01 issued end of october 2009, but since january 2010 it does not work anymore.
Final Cut Server is version 1.5.1 with Mac Os X server is 10.5.8
Editing station are running Final Cut Pro 7.0.1 and Mac Os X 10.5.8
What could be wrong ? Does anybody encountered this type of problem?
Any suggestions welcomed!
Thanks.

Answer 1

I'm dealing with this issue right now (FCSv 1.5.1 latest pro app updates, 10.6.2, FCP7). I was under the impression that you could make edit proxies that were 25% resolution (as opposed to just using an efficient codec), but Final Cut Pro is having a rough time getting it right. I too am only getting success with ProRes-Proxy, audio passthrough, and 100% res/everything else. I tried using Apple Intermediate Codec with default "100%" settings and audio passthrough but had no luck. It's way heavier than ProRes Proxy anyways.
The only suggestion I can make is try your h264 solution with audio passthrough (or Linear PCM) instead of AAC. If that makes a difference we're on to something. Some people started having this issue after an iTunes update, so maybe AAC is the source of the problem.
The edit proxy workflow really needs tweaking from Apple to cater to internet-based solutions rather than fiber/SAN environments where bandwidth is a non-issue.
I'll report back later after some more testing.