● Video delivery / 004
Camera-to-cloud video workflows: proxies now, originals when they are ready
Design a camera-to-cloud video workflow around proxies, originals, timecode, resumable staging, bandwidth math, and destination-neutral delivery.
- Published
- Reading time
- 10 minutes
- Source policy
- Primary / official
The practical answer
The practical video workflow is usually two-speed: deliver small, editorially useful proxy files as soon as possible, preserve clip name and timecode for relinking, and move camera originals through a slower resumable path. Some cameras can upload movies directly; others need an external recorder, mobile relay, or post-recording transfer. The exact behavior is model-specific.1,2,3,4
Optimize for time-to-first-useful-file.
Frame.io’s Camera to Cloud documentation distinguishes camera-original uploads from proxy workflows. It defines useful editorial proxies around matching clip name and timecode so post teams can work before originals arrive; it also notes that proxies created by external devices can differ by a few frames at the start or end.1,2
That leads to a more useful field metric than “cloud upload enabled”: how long after cut does an editor receive a file that can be reviewed or cut? Originals and proxies may need different routes, priorities, and retention policies.
“Supports video” can mean four different things.
Sony’s ILME-FX30 FTP guide documents automatic FTP targeting for all movies or movies with Shot Marks. Nikon’s Z6III guide says videos are not auto-uploaded and must be selected from playback, with additional choices for RAW-video and MP4 copies. Frame.io documents both native camera integrations and external encoders that record a camera’s video output.3,4,1
Native original upload
The camera records and uploads its own high-quality file. Fast only when the file size and uplink allow it.
Native proxy upload
The camera records a smaller companion file and uploads that for review or offline editorial.
External recorder / encoder
A connected device records the camera output and uploads a proxy or new media file. Relinking depends on clip name, timecode, and trigger behavior.1,2
Phone or field relay
A mobile or laptop workflow receives media from a camera without practical native transfer, then sends it through the user’s configured route.
A video pipeline must survive a broken connection.
Do not make the FTP or SFTP session wait for Dropbox, Drive, Frame.io, or a NAS. Complete camera ingest into durable staging, verify the object, then schedule each destination independently.
Cloudflare recommends multipart upload for large files or when parallelism and resumability matter. Google Drive resumable uploads can continue after a communication failure. Dropbox upload sessions split larger files across requests. Frame.io V4 can return multiple upload URLs based on file size.5,6,7,8
Spool first
Write an immutable staging object and checksum before routing.
Prioritize proxies
Let small editorial files pass large originals in the delivery queue when the job policy allows it.
Resume destinations
Persist provider session identifiers and byte offsets where the destination API supports them.
Preserve identity
Keep original filename, timecode-related metadata, camera/source identity, capture timestamp, and proxy/original relationship together.
Expire deliberately
Delete temporary objects only after every required route succeeds or a human resolves the failure.
Prove editorial relinking—not just file arrival.
A green upload indicator is not the end-to-end test. The fixture should begin with a recorded clip and end with a reviewer opening the delivered proxy and an editor replacing it with the correct original.
Record
Create clips across normal, long-take, and any off-speed modes the assignment will use.
Interrupt
Drop the uplink mid-transfer and confirm capture continues, incomplete media does not route, and eligible uploads resume.
Fan out
Deliver the same proxy to review and the original to archive without re-uploading from the camera.
Relink
Confirm filename, reel or camera identity, timecode, frame rate, and start/end behavior satisfy the target editor.
Measure
Record cut-to-visible latency, retry time, delivered bytes, and the point at which the original becomes available.
Frequently asked questions
01Can cameras upload video directly over FTP?+
Some can. Sony documents automatic movie FTP on the ILME-FX30, while Nikon documents manual video upload behavior on the Z6III. Support and automation vary by exact model and firmware, so use the manufacturer guide and a body-level field test.3,4
02Should a camera-to-cloud workflow upload proxies or originals first?+
If speed to review or edit is the goal, prioritize a relinkable proxy and move the original on a resumable background path. If immediate access to full-quality media is mandatory and the uplink can sustain it, route the original first. Make the choice per job rather than globally.2
03What makes a video proxy relinkable?+
Frame.io’s workflow guidance centers on matching clip name and timecode. External recorders may create start/end differences, so the exact NLE and conform workflow still needs a test with the production camera and recorder.2
04Why use object storage before the final video destination?+
Durable staging decouples the camera session from slower destination APIs, supports independent retries, and gives multiple routes one verified source object. Multipart object upload is designed for large files and retrying failed parts.5
Official sources
Sources were reviewed on August 26, 2026. Vendor interfaces and documentation can change; follow the linked source and re-test the exact production workflow.
- 01Frame.io / AdobeGetting Started with Camera to Cloud ↗
- 02Frame.io / AdobeComplete Camera to Cloud Proxy Workflow Guide ↗
- 03
- 04
- 05CloudflareCloudflare R2 — Upload objects ↗
- 06
- 07
- 08