NLE round-trip
Proxies the editor can relink, timeline formats read and written, and the protections applied when TRNSCODE writes to a project file.
Proxies and conformed media are useful only when the editor can reconnect to them. This page describes how TRNSCODE operates within an existing edit workflow.
Round-trip overview#
A round-trip has two directions.
- Out — from camera originals to edit proxies. TRNSCODE produces proxies in the format the editor expects, named and structured so relinking works.
- Back — from a finished cut to a conform against the originals rather than the proxies. TRNSCODE reads the timeline to determine which media is used.
Formats read and written#
| Format | Used by | Direction |
|---|---|---|
| FCPXML 1.10+ | Final Cut Pro, and DaVinci Resolve via 1.10 | Read and written |
| FCP7 XML (xmeml) | Premiere Pro — the legacy interchange format | Read and written |
| CMX 3600 EDL | Effectively every system, as a lowest common denominator | Read |
| AAF | Avid | Read, for cut points |
| OpenTimelineIO | Pipeline tooling and Hiero | Read |
Cut points from a timeline identify which parts of a source are used. On a camera roll where the edit uses two minutes of a forty-minute take, cut points are the difference between conforming the required range and re-encoding the entire take.
Proxies and reattach#
Seven proxy presets are named for the application that will open them — Avid DNxHD 36 and DNxHR LB in MXF, Final Cut ProRes Proxy, Premiere in H.264 and ProRes, and two for Resolve. See Choosing a preset.
Reattachment, not generation, is where proxy workflows typically fail. Dedicated reattach paths therefore exist per editor rather than one generic mechanism: Resolve, Premiere and FCPXML each have their own, because each application locates and matches media differently.
The output is a sidecar file the editor opens to reconnect; clip-by-clip relinking is not required.
The reattach path is colour-managed rather than a direct transcode. A proxy that does not match the original's colour interpretation results in grading against material that differs from the finishing source. Check one proxy against its original before proxying a full shoot.
Project-file write protections#
Some operations write to customer-owned files: a Resolve project, an FCPXML, a Premiere project. These are the highest-risk operations in the product. Three protections apply.
Before any write to a customer-owned file, the current contents are snapshotted and recorded with a checksum. Restoring is a single operation against that record.
Content is written to a temporary file and then moved into place, so an interrupted write cannot leave a half-written project file. Either the previous version is intact or the new version is complete.
Snapshots are recorded as well as written to disk. The activity log shows which file was touched and when; the history does not need to be reconstructed.
These protections cover the file. They do not cover an application holding it open with unsaved state. Close the project in the editor before running an operation that writes to it.
Resolve database relink#
A path exists that connects directly to a Resolve project database and relinks media in place, without going through an exported XML. It is the most convenient option and carries the most risk.
This operation writes directly to a customer's Resolve project database. Two gates protect it, both by design.
Schema gate. The connector inspects the database schema when it opens and refuses to operate against a version it does not recognise. At present it ships knowing one synthetic test schema. Real Resolve 18, 19 and 20 databases are enabled only after an operator has hand-verified the schema shape against an actual installation.
Dry-run gate. A relink will not execute unless a dry run was performed first and its result is passed to the real operation. A relink cannot be executed without a preceding dry run.
Do not plan a facility workflow around direct Resolve database relinking without confirming that the Resolve version in use has been verified. Until then, use the XML round-trip; it passes through the same backup protections and does not touch the project database.
Markers and chapters#
Timeline markers and chapter atoms survive the encode when a job opts in. The source's chapters are read and written back in the form the output container expects — a metadata sidecar for MP4, MOV and MKV, or WebVTT for HLS — so chapter navigation still works in the delivered file.
The feature is off unless requested. Writing chapter data into a deliverable that was not specified to carry it is a change that must be requested explicitly rather than applied by default.
Submitting from a timeline#
Instead of submitting file by file, submit a timeline and TRNSCODE derives the jobs. An OpenTimelineIO timeline is walked and converted into a set of jobs covering the media the edit references.
Batching a timeline
This is the highest-fan-out path in the product. One uploaded timeline is expanded into one job per clip, across every video track. Each spawned job links back to the clip it came from, so a queue of two hundred jobs remains traceable to the edit that produced it.
One timeline can become hundreds of jobs. The link back to the source clip keeps the batch traceable, but an incorrect preset applied to a batch is applied hundreds of times. Run one clip through before submitting the full timeline.
Snapping chunks to editorial cuts
Cut points read from an EDL, AAF or FCPXML can do more than trim: they can be used to place chunk boundaries on editorial cuts rather than at positions chosen by the scene detector.
This behaviour is opt-in. It aligns the encoder's chunk boundaries with the cuts the picture already contains, which matters where seam placement is a concern.
Timeline submission suits conform and finishing work, where the requirement is to produce every deliverable a sequence needs rather than to encode a single file. It is also the path that scales to a facility, because it removes the manual step of reading a list and typing paths.