-
Importing Proxies instead of originals
I see that we can now relink proxies separate from original media. We start all our edits with proxies, then relink to original media during finishing.
When I first import media, Final Cut treats it as original media. Does anyone know if I can import media so that Final Cut sees it as proxy media?
-
12 Replies
-
Hi Chad,
Mark and Steve at Ripple Training recently posted a YouTube video about this.
https://www.youtube.com/watch?v=0j7zNEoc8tg
or
https://www.youtube.com/watch?v=IHL9gFwm85M
Some contents or functionalities here are not available due to your cookie preferences!This happens because the functionality/content marked as “Google Youtube” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.
-
Yes, I don’t think there’s a way, currently, to import proxy media and identify it as such. You need to start with an original, and then relink (or create) to a proxy version.
-
It is possible to initially import only proxies as original media, edit, then later relink to full-res media, then also relink the proxies as FCP proxies. I have tested this with the camera-generated proxies from my A7SIII.
As always there are certain relink criteria for FCP. Any planned workflow involving relinking should thoroughly test this at a small scale before committing to a larger project. Known FCP relink criteria:
– Files must have the same audio config (same number of channels), but sample rate can differ.
– Pixel aspect ratio should be the same, but it may relink even if different. This could result in a squeezed or stretched frame.
– Relinked file duration must be the same or longer as the timeline *clip*. Note this is timeline clip not file clip. Absent a timeline you can relink to shorter files. But if used in a timeline the file must be long enough to cover the timeline clip.
– File name including suffix must be the same.
– Codec need not be the same, e.g. you can transcode ProRes originals to 720p H264 and relink those.
– If the clip timecode does not match the original file, it will not relink. The error is “The original file and new file have no shared media range”. This is due to metadata in the video header labeled “time code of first frame”.
– After relinking to a different resolution file, the viewer may show a window-boxed screen. This is typically a cache issue and can sometimes be resolved by deleting the FCPX cache, which is either stored in the library or outside as defined by the library inspector. The cache is a file bundle named LibraryName.fcpcache.
If relink fails it is often beneficial to try and relink a single file. In that case (but not the multi-file case), FCPX may state why the relink failed.
It is often informative to use the 3rd-party tool Invisor to compare side-by-side the video header metadata from the two files when relink fails: https://apps.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12
-
Robert, thanks for the video.
Jeremy, thanks for clarifying what I am seeing. I look forward to the day that I can add proxies first, then relink to originals when ready (probably a long wait?).
-
“I look forward to the day that I can add proxies first, then relink to originals when ready (probably a long wait)”
As I said in the above post, this is possible right now, given the relink constraints are met.
-
It’s possible, Joe, but the media is treated as “original” and not proxy. So if you import proxy material first, there’s no way to switch to proxy or proxy preferred. You’d have to edit as original, then relink to original media as original, then relink the proxy as proxy. There is no way that I know of to start with “import proxy” without having original media first. This would be a solid feature request.
-
But now that we have proxy relink, I don’t see much practical difference for the OP case. He initially planned on using (or had access to) just the proxies. What difference does it make whether he edits proxies as originals or proxies as proxies? He can’t select “proxy preferred” if he didn’t (or couldn’t) import the originals. He can later relink to full res media, then relink to the proxies he was already using.
The hypothetical feature for proxy-only import as proxies would save you a grand total of one relink, which typically takes seconds. A study of the internal SQL tables used by FCP indicates the current data design might not permit proxy-only import as proxies. It appears the SQL rows describing the proxy files depend on rows already existing for original media files, and there is inadequate descriptive info in those tables to support stand-alone true proxies without ever having imported the originals. Of course you can do anything with software but the schema implies it might be a major effort in the current design.
When implementing that planned feature, you might *also* theoretically provide more adjustability like other NLEs have. E.g, options to disregard filename extensions during relink, ignore x characters of filename, disregard audio check, etc. But those are separate improvements independent of a “proxy-only import as proxies” feature.
-
Joe, you are correct that bringing footage in as proxies doesn’t make a large difference. The only think it would save would be relinking time which, on our documentaries and Jellyfish SMB shares, can be time 1-3 hours of annoyance. I would love to be able to leave the proxies relinked so I have the option to flip back to them quickly.
Ultimately my current workflow works well and I was just curious if I was missing something. 🙂
-
1-3 hr to relink is interesting; I have relinked large documentaries including 8,500 clips and 220 hours of 4k material and it took about 45 min on a locally-attached OWC Thunderbay 4. That was several versions ago and there were some significant relink performance issues that I think have been improved since then.
The good news is by ingesting proxies for edit, later relinking to originals and using the new feature to then relink to proxies as proxies, it at least preserves the proxies. On a previous project it took me several days to regenerate proxies because proxy relink was not supported.
But you have an interesting point — if it takes up to 3 hr to relink, it would be nice to avoid that. If proxy-only import as proxies was supported it would help.
My question is if it takes 1-3 hr to relink, why? It shouldn’t take that long to enumerate 10,000 or so files and attributes. Much of the metadata is already indexed by spotlight, but if it had to actually read each file header for video metadata, that would still only be about 60 seconds. I just re-tested my 48 TB OWC RAID-0 array and it can do about 130 non-cached random 32 KB reads per sec. But FCP must match each of those against the stored attribute data in SQLite tables inside the library. If each of those is an indexed access, that also should be very fast. This implies there is some bottleneck in the SQLite access path or associated code for a relink.
-
My question is if it takes 1-3 hr to relink, why?
This is fairly normal on SMB shares and FCPX libraries. The act of moving the old symlink out of the library and replacing with the new symlink (or alias file) takes a lot of time due to the nature of the very small files. I don’t know how Jellyfishes work, but spotlight data might not help, it doesn’t work on my server as the server is a totally different disk format than HFS or APFS.
Reply to this Discussion! Login or Sign Up