We all know how successful one-click editing with proxies has been in Final Cut Pro X. So good that Adobe has gone and copied developed the workflow as well! But what happens when you want to make the proxies even smaller so they could be transferred over the net to a remote editor? Sam Woodhall and Ben King experimented and found a way to make low resolution proxies to squeeze down a small internet connection.
Sam takes up the story...
It was September 2015, I had a frantic call from Ben King looking for an FCPX editor who could provide DIT and work as the Assistant Editor on site for a last minute job.
The work would be on a two day shoot and to transfer and import the rushes and assemble a feature film 'teaser trailer' which Ben would edit remotely.
The plan was to shoot across the weekend, generate assemble edits to send over to Ben who would be working across the following week to reach deadline by the Friday. No big deal you say. However because of the last minute nature of the job and shifting bookings Ben would be in the middle of the Czech countryside with poor internet connection.
The DOP's camera of choice is the Arri Alexa - which we would shoot using 2K 2048 x 1152 ProRes 4444. This provided our first 'bump in the road' – the files would be too big to upload in their native format.
SneakerNet wasn’t going to cut it, as not only was Ben in another country, he was travelling around and wouldn't be in any one place long enough to get the package. So shipping a drive containing the media wasn't an option.
However Ben had been testing sending sending a stripped down library and Proxies via a Cloud service.
We knew that as long as FCPX has created the Proxies in the first place and that they were inside the proxy folder in the FCPX Library that you could send them to a remote edit system and everything should work fine.
However even using the half-res 1024 x 576 ProRes Proxies, the files sizes were probably going to be an issue due to the slow web speeds. We had to think of a way to get around being able to work at such distances without the luxury of 100Mb connections.
Could we somehow make smaller proxy files just like the days of FCP7 that could be sent more quickly via the Internet and still relink to the original media?
Having used FCPX for many years with it’s specific file handling, we had little confidence that it would work.
Anyone who has ever tried to relink a file that is slightly different from the original imported media will tell you that it just doesn't like it. In FCP7 you could force a relink to use a file with different audio and video codec, with different number of channels and even different frame sizes and length great for crazy workflows but often got less technical editors in relink hell!
We tried all manner of different codecs to see if somehow we could create something like an H.264 proxy workflow. But to no avail.
Then we had a crazy idea instead of reducing the file size by codec we'd simply try a lower resolution of ProRes Proxy.
After all we surmised - FCPX Proxies are 'half-res' and that are dependent on the original size. There is no 'standard' proxy frame size.
With little confidence it would work, we tried a quarter-res (512 x 288) Proxy...
It worked! How far could we go with this? 1/8 res? Boom! Result!
What about really crazy dimensions? 200x200? Nope.
Different audio codec? Different Audio Channels? Nope.
What we were to find through much trial and error and lots of cups of tea, is that as long as the audio is identical (a passthrough of the number of tracks & PCM audio) you can change the frame size of a proxy file to just about anything as long as it's in ProRes Proxy and the pixel aspect ratio is identical to the original.
- Our original files were 2048 x 1152 a PAR of 16:9
- Proxies were made by FCPX @ 1024 x 576 a PAR of 16:9
- We took those Proxies into Apple Compressor simply divided both the horizontal and vertical by 2.
- This gave us a 'quarter-original-res' file size of 512 x 288 with you guessed it a PAR of 16:9
- So as long as the horizontal x vertical pixel dimensions are both divided by the same factor you should be able to create proxies at any resolution! We say 'any resolution' because we even tested making proxies that were larger than the original and they relinked just fine!
What about adding BITC or other burned in metadata?
We added a simple Timecode Generator to our proxies and a watermark to the video and this worked perfectly too. So this means you can send remote editors lower res proxies with copyright or watermark information on in case they get lost or hijacked in transit or timecode reference when necessary!
However that's not the end of the story. We decided to test every favour of ProRes...
So we knew ProRes Proxy worked but what about LT? Straight up 422? HQ, 4444 & XQ?
Well we can happily say that all worked perfectly!
Although the pedantic among you might think it makes little sense to use larger data rate codecs for a proxy workflow, consider this.
Sometimes you might want to have an Alpha channel on your proxy workflow - you cannot do this normally as ProRes Proxy, LT, 422 & HQ do not have Alpha Channel support. So being able to has one or two 'proxies' with an Alpha in ProRes 4444 is ideal.
The only caveat we found was that as soon as you change the pixel dimensions of a ProRes 4444 in Compressor your lose the Alpha as there seems to be a bug (Apple? You might want to take a look at that).
So our suggestion is simply to copy the original 4444 source media to the proxies and take one for the team on the file size until Apple sort out the bug and we can finally make nice half or quarter res ProRes 4444 (with Alpha) of our original files.
We feel this ability to create smaller Proxy files for editing will be of use to people like ourselves wanting to send really tiny proxy files into the cloud, for the paranoid studio that needs to send out rushes with watermarks or BITC, for people wanting to free up space on their storage by making smaller proxy files.
This solution worked great for the two of us working from in different locations. Ben was able to send back cuts that would link up instantly to the original media without needing to relink at each end.
Despite the headache it caused with developing the workflow, when you’ve done it once, it’s very easy to repeat and automate.
Perhaps one day Apple might implement a choice of proxy generation size (1/2, 1/8, 1/16) into FCPX or even the ability to use H.264 proxies which would facilitate using files from Cloud collaboration sites like Frame IO or Kollaborate.
Caveats and annoyances.
Apparently the FCPX Library needs to know it personally and no-one else has made the proxies. So our method requires that FCPX first make the proxies and then you can replace them with the ones you make in Compressor.
We were thinking of editing the FCPXML but the FCPXML does not contain any Proxy information so we could not make FCPX think they had already been done. This means you cannot make proxies externally without first making them in FCPX which might feel like double the effort.
The proxy folder needs to live inside the Library, if it’s external, we found it creates a whole bunch of sim-link issues.
You have to use the original audio files and relink at the other side, but only needs to be done once.
We’ve created a white paper that explains in more “detail” the process of creating and sending low data rate proxies inside of FCPX.
Hope you find this useful in your workflow, and if you have any questions, feel free to get in touch!
Sam Woodhall is a video editor and motion graphics artist from the West Midlands in the UK. Cutting short to feature films, commercial and corporate videos for various clients.
Follow Sam on Twitter @SWDoctor
Ben King is a Film & Broadcast Editor from the, UK and long time 'guru' on all things creative and technical over at LACPUG.
Follow Ben on Twitter @vshjaar