In-Camera Proxy Workflow
In-Camera Proxy Workflow Questions & Considerations
-
GENERAL - While NETFLIX doesn’t ban the use of in-camera proxy workflows, we do think productions should have a clear understanding of what they stand to gain and/or risk from adopting one. Conversations should be had on a case by case basis to ensure it’s the right decision.
-
TIME - In most cases, the main motivation for adopting an in-camera proxy workflow is the presumed speed gain that comes with no longer needing to generate editorial and streaming proxies from the full resolution OCF in post. However, when following best practices a full QC still needs to be performed on the OCF material to ensure healthy image essence and file integrity. Since this QC process requires the same computationally expensive processing and playback of OCF material generally required by a traditional workflow when generating proxies in post, it rarely leads to a net gain in speed/time.
-
QUALITY - In-camera proxy files are generated by internal hardware often necessitating real-time speeds or faster. Certain shortcuts in processing may be implemented by the manufacturer to aid in this. As such, these in-camera files are often of a lesser quality than those generated in post with dedicated software able to utilize more sophisticated processing algorithms. It should also be noted that in-camera proxies are often derived from an alternate internal signal path than the OCF. Do the in-camera proxies provide post production a 1:1 match with traditional post generated proxies? Will there be costly hiccups in post due to metadata mismatches? Has the color pipeline been vetted for inconsistencies between the in-camera proxies and OCF? Are the proxies the same FOV as the OCF? Are the proxies spanned or non-spanned? Will this present a problem?
-
RISK - If a production ultimately decides to go with an in-camera proxy workflow, it’s important to be aware of the potential issues that may arise. If a full QC isn’t performed on the OCF material at or near the time of capture, it’s possible that issues with the high quality OCF won’t be flagged until the DI. At which point, performing necessary reshoots may no longer be possible or cost effective. Can you edit or cut around lost shots? Is the filmmaker comfortable using low quality proxy files in the final delivery? If so, will that pass QC?
-
COST - Are you actually saving money with this approach? Have any presumed cost savings been quantified and verified? Will your recorded data rate increase when simultaneously capturing proxy files? Will an increase in recorded data translate into longer offload times for the Data Manager or DIT? Are the proxy files being saved to the same media or is there additional media that must be purchased and maintained? Factoring in the QC being performed on the OCF material, will there be any cost savings in no longer processing dailies in post?
-
BANDWIDTH - Camera systems have a limited internal bandwidth. By enabling proxy recording you may begin to eat into that available bandwidth. This may inhibit the maximum allowable quality of the OCF capture. For example, some systems require you to increase the compression settings of your RAW capture in order to enable simultaneous proxy recording. Does the increased compression settings still meet NETFLIX approved camera requirements? Are you okay with potentially degrading your OCF capture for the sake of in-camera proxies?
-
RELIABILITY - In-camera proxy workflows have yet to be widely adopted across the industry. This gives us a limited sample size to judge the robustness and reliability of such practices. For example, is corruption more common when recording in-camera proxies? Is there an increase in camera errors when recording proxies? Some camera systems require the attachment of external recorders for proxy recording, is this introducing an additional point of failure in the capture system? Do the practical real world benefits outweigh the potential risks involved? Are there additional camera errors that can occur with proxy recording enabled
Best Practices Example
-
Record OCF and in-camera proxy files in camera native log / wide color space. (Highly recommend not baking LUT or Look into Proxy files as this limits the captured color gamut and dynamic range of the proxy file. This is a precaution in the event there’s an issue with the OCF necessitating the use of the proxy file in the final deliverable)
-
Offload both OCF and proxy to high-speed fault tolerant storage (think RAID 5), generating checksums for all files.
-
Compare number of OCF and Proxy files to each other to initially verify that they are the same in number and file naming.
-
Check both OCF proxy file metadata against camera report. Make sure timecode, frame count / duration and file naming match.
-
Open all of the OCF: Playback the first 4-5 seconds and scrub through. Playback the last 4 or 5 seconds.
-
Either generate dailies and streaming proxies from your in-camera proxy files or ship the proxies as they are to editorial for them to start syncing, logging and cutting from.
-
Archive OCF and in-camera proxies following our archiving rules of 3 copies on 2 types of media with 1 set of backups in another location.
-
Once QC and 3-2-1 backups are completed, wipe the camera card and make it ready for re-use or mark the card as ready for re-use and let camera know it's available.
Change Log:
2019-06-11
- "Best Practices" section moved to bottom of the article.
- "Who Ultimately Makes The Decision" section removed and information incorporated into "In-Camera Proxy Workflow Questions & Considerations" section.