TeraAirlift

Media Workflows

A Better Workflow for Sending Footage to Remote Video Editors

A step-by-step footage workflow designed to reduce missing files, ambiguous versions, and wasted editor time.

Richard Parker8 min read

Card reader with one SD slot and one TF slot

A reliable remote-editor handoff has seven explicit stages: prepare, upload, notify, download, verify, ingest, and retain or delete. Assign one owner, send a manifest, model both network legs, and define what “delivered” means before starting. That prevents most missing-file, expired-access, version, and status-chasing failures.

1. Prepare one unambiguous package

Freeze the handoff version before transfer. Use a root folder containing the project identifier, camera-original folders or selected media, synced audio, reports, LUTs, graphics, project files, and a plain-language manifest. Preserve camera card structures where the NLE or conform workflow needs them.

The manifest should record:

  • package/version identifier and creation time;
  • included and intentionally excluded folders;
  • file count and total decimal bytes;
  • expected folder structure at the destination;
  • checksum method and results, if used;
  • contact and escalation owner;
  • whether the set is proxies, originals, or both.

Remove caches, previews, and obsolete exports unless they are deliberately required. Test that representative media and the project open on a clean workstation.

2. Decide whether proxies go first

Adobe defines proxies as lightweight copies attached to high-resolution originals for editing, with originals used again for final output. Proxies can unblock editorial without pretending the original-media handoff is complete.

Apple's target rates show the scale difference. Six hours of 4096×2160/24p ProRes 422 HQ are about 2,034 decimal GB; six hours of ProRes 422 Proxy are about 420 GB. The proxy set is approximately 79% smaller under those named assumptions. Codec targets are theoretical planning inputs, and practical file sizes vary.

Document naming and relink rules before generating proxies. A smaller package that cannot reconnect to originals creates a later conform problem instead of solving delivery.

3. Model the complete online path

Measure upload at the sender and download at the editor during the intended window. Include source read speed, destination write speed, shared network contention, sleep settings, and available disk capacity.

At 300 Mbps, a 420 GB proxy set takes about 3 h 29 m for the upload in the current calculator model. If the editor downloads at 200 Mbps, upload plus download take about 8 h 43 m. The model uses decimal bytes and a 12% planning allowance; notification, verification, and ingest remain additional.

If that path misses the deadline, split by priority, send proxies first, or compare physical media using the shipping calculator. Do not start by silently opening an unrelated consumer share.

4. Upload with named ownership

Queue jobs in editorial priority order. Keep the source unchanged while it is being read, prevent workstation sleep, and leave adequate free space. One person should own the queue, watch exceptions, and communicate a revised estimate when the plan changes.

Many small files can add transaction overhead. AWS recommends batching files smaller than 1 MB for Snowball workflows and documents directory-count guidance; treat that as platform-specific evidence of a general file-shape issue, not a universal archive rule. Test a representative project tree on the actual tool.

5. Notify with access instructions

Tell the editor what is available, its version, where it belongs, how access works, and when access ends. Confirm recipient identity before sending. Short-lived storage credentials improve control but require a workflow that can refresh access without forcing the sender to invent a new package.

Microsoft recommends HTTPS-only storage access, a revocation plan, and short expiry for a service SAS without a stored access policy. That is Azure-specific guidance, not a universal one-hour delivery-link rule. Your procedure should separate temporary storage credentials from the recipient's business access window.

6. Verify before ingest

The recipient should compare byte and file counts, validate checksums where provided, and open representative clips before editing. Verification answers “did the bytes arrive?”; ingest answers “are they in the correct project storage and usable by the NLE?”

Copy or link the package into the approved working location, preserve the version identifier, attach proxies correctly, and record acceptance. Do not announce completion merely because an upload UI reached 100%.

7. Apply a retention decision

Keep sender originals until the recipient confirms a verified, usable copy and the production's protection policy is satisfied. Temporary transfer storage is not automatically an archive. Record who deletes the transfer copy, when, and under which client or studio policy. Azure's cool, cold, and archive tiers have different minimum retention economics and archive rehydration delays; those cloud-storage rules should not be mistaken for a transfer service's retention promise.

Use the post-production delivery-night checklist for a repeatable preflight. The remote large-video guide covers method selection, while waiting-cost economics and hidden IT operations cover ownership.

Where TeraAirlift fits

TeraAirlift is a Windows-first desktop operations console with file/folder queues, progress and ETA, cancellation, retry-friendly operations, transfer history, diagnostics, recipient-controlled delivery, and SHA-256 integrity verification. It can make state and verification visible without guaranteeing throughput or defining your archive policy. Review the post-production workflow.

Sources

Plan your next large-file transfer

Schedule a demo or download the Windows client to explore the TeraAirlift workflow.

End-to-end desktop clients — you send from the app; your recipient opens TeraAirlift and pulls from Available Downloads.