← Field notes

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 · 10 min read

The short answer

The practical video workflow runs at two speeds. Deliver small, editorially useful proxy files first, and preserve clip name and timecode so editors can relink later. Move camera originals through a slower, resumable path behind them. Some cameras upload movies directly. Others need an external recorder, a mobile relay, or a transfer after the recording stops. The exact behavior depends on the model.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 a useful editorial proxy as one that matches clip name and timecode, so post teams can work before the originals arrive. It also notes that proxies from external devices can differ by a few frames at the start or end.1,2

That suggests a better field metric than “cloud upload enabled”: the time between cut and an editor receiving a reviewable, cuttable file. 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 video is not uploaded automatically. You select it from playback, with added 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. It’s fast only when the file size and the 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 that has no practical native transfer, then sends it through your 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 the editor can relink the file.

A green upload indicator only tells you the file arrived. Build the fixture to start with a recorded clip and end with a reviewer opening the delivered proxy and an editor swapping in 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

Can cameras upload video directly over FTP?

Some can. Sony documents automatic movie FTP on the ILME-FX30. Nikon documents manual video upload behavior on the Z6III instead. Support and automation vary by exact model and firmware. Check the manufacturer guide, then confirm with a body-level field test.3,4

Should 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 job by job, not as one fixed policy.2

What makes a video proxy relinkable?

Frame.io’s workflow guidance centers on matching clip name and timecode. External recorders can create small start and end differences. Test the exact NLE and conform workflow with your production camera and recorder before you rely on it.2

Why use object storage before the final video destination?

Durable staging decouples the camera session from slower destination APIs, supports independent retries, and gives every route one verified source object. Multipart upload splits a large file into parts, so a failed part can retry on its own.5

Sources

Sources were last reviewed on . Vendor interfaces and documentation can change; follow the linked source and re-test the exact production workflow.

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08
Sony ILME-FX30FTP setup guide