Camera to Cloud on a Crew of Three: What Moves and What Stays

Camera to cloud changes where the first copy of anything lands, and who can see it the same hour. On a crew of three, nobody is the VTR tech, so the question is less about the gear and more about who owns each copy once it exists.

Frame.io's own pitch is that a shooting day could save "a day or more in post-production" compared with physical media. That is vendor marketing with no measured figures behind it, so we read it as a direction, not a number. Local offload, checksums and drives are a separate subject, and we wrote that up in our note on data wrangling on a small crew. This note is about what the cloud leg adds.

What we noticed

It uploads proxies, not originals. According to Frame.io's technical guide, the camera sends a signal over SDI to a cloud-connected encoder such as a Teradek Cube. The start flag carries the clip name and timecode, the encoder records a proxy, and when the camera cuts, the proxy goes up. The originals stay on the cards. Nothing in that chain replaces the offload, and the same guide says the DIT's work still feeds the traditional dailies process.

So the crew of three still has a card-to-drive routine, and now also an upload queue. Per the guide, the device needs WiFi with internet access or a modem, and ASC coverage of the launch lists LTE, 5G or WiFi. If the connection drops, the device stores files locally and uploads when a connection returns. The documentation gives no bandwidth requirement, no queue limit, no retry behavior. Those are the numbers you'd want, and you only get them by testing.

What a small crew gets in return is real. Because the proxies keep the original filenames and timecode, an editor can cut with them and relink to the camera originals later, and a producer in another city can watch a take on a phone minutes after the cut. Frame.io itself frames this as supplementing a VTR, not replacing one, and for a crew without a VTR tech that is the honest reading: instant playback, with the careful work still waiting downstream.

The encoder is also one more thing to power and carry, next to the backup recorder we keep. The device names in those sources date from the launch, so check what is certified today before planning around any of them.

What we changed or kept

We'd keep two verified copies on separate drives before any card is formatted. Fastio's dailies guidance puts the minimum at two, and nothing about proxies in the cloud lowers it. Proxies are for looking, not for recovering a lost take.

We'd add a test. The same guidance recommends uploading real proxy footage over the connection you will actually have, measuring throughput and checking playback, and warns that hundreds of gigabytes to a consumer cloud drive "can take many hours." It also suggests a written fallback for outages: a second upload location, a courier for drives, or a mobile hotspot. On a small crew, writing down who makes that call is part of the plan.

Uploads can be paused per device or for a whole project, which matters if the same thin connection also has to carry something else. And hero dailies still come from the originals whenever custom color, framing or sound sync is needed, so the cloud proxy is the fast look, not the finished one.

The practical result is a job description more than a workflow. Someone watches the queue. Someone owns the cards. On a crew of three, they're rarely the same person in the same hour. We would settle that before the first camera roll, and treat it as part of the film's plan, not the post schedule.