Docs / How-to guides

Work on Video and Audio Projects Between Two Computers

Editor and colorist, narrator and engineer, two rooms, one media folder.

The pattern

Media files are huge and mostly read. Project files are small and constantly written. Treat them differently:

• Source footage, audio stems, and renders live in the shared folder. They stream on demand; nobody waits for a 40 GB copy.
• The project file travels by turn-taking: one person works, saves, hands off.
• Application project databases stay on the machine that owns them.

Share the media, not the project database

Point your editor's media pool at the shared folder. DaVinci Resolve, Premiere Pro, Final Cut, and DAWs relink media by path like they do for any drive.

Applications that keep a project library in a database (DaVinci Resolve's project library, Audacity's .aup3, DAW session databases) should keep that database on local disk. A database is an always-open file, and two machines must not run one concurrently over any shared storage; KeibiDrop is no exception (why). Export or hand off instead.

Scrub remote footage

Open a clip from the shared folder and scrub. Playback reads stream on demand with read-ahead: on a measured intercontinental link (~200 ms round-trip), a paced 1 GB playback ran with zero stalls and a worst single read of 70 ms. Seeking to the middle of a clip fetches that region, not the file so far. The numbers and their conditions are in Performance.

On a thin connection, resist the urge to prefetch everything; the default on-demand mode keeps seeks responsive. See prefetch_auto_mb in the configuration reference before changing anything.

Hand off the project file

Keep the project file (.prproj, .fcpxml, .drp export, DAW session file) in the shared folder and take turns: A edits and saves, tells B, B opens. Saved-file sync is sub-second; the handoff cost is saying "your turn".

If both of you save the project at the same moment anyway, the newer save keeps the name and the other version appears as a conflict file on both machines. Nothing is silently lost, but resolving a project-file conflict by hand is no fun; the turn-taking habit avoids it.

Renders and exports

Render into the shared folder and the result lands on the other machine as it is read. Command-line pipelines work the same way; ffmpeg reading sources from the mount and writing results back is part of KeibiDrop's test battery:

ffmpeg -i ~/KeibiDrop/Mount/raw/clip.mov -c:v libx264 ~/KeibiDrop/Mount/renders/clip-review.mp4

Only the changed bytes of re-exported files transfer on a re-render of the same name.

What to avoid

• Both machines editing the same project file at the same time. Autosaves race, and a conflict copy of a binary project file is hard to merge by hand. The media folder is fine to use from both sides at all times; the turn-taking applies to the project file only.
• Project databases on the mount. Keep them local; share media and exports.
• Prefetch on a thin link. It starves the seeks your playback needs.

The media streaming, the save patterns, and the pipeline tools around this workflow are what KeibiDrop's tests cover; the editing applications themselves change between versions. If your application does something odd on the mount, send a log.