Documentation

TRNSCODE

A distributed video encoder you run on your own machines. One master coordinates, any number of workers encode, and FFmpeg does the work.

TRNSCODE splits a video into chunks, hands those chunks to every machine on your network, and reassembles the result. A job that pins one computer for an hour finishes in minutes across six. Nothing leaves your network, and there is no per-minute bill.

It runs the same way whether you are one editor with a spare desktop under the desk or a facility with forty nodes on a wired VLAN. The difference is how many workers you start.

Pick your path#

Both routes land in the same place. Choose by what you have in front of you today.

What you need#

Less than most tools of this kind. The distribution is portable and self-contained.

RequirementDetail
Operating systemWindows, macOS or Linux. Mixed fleets are fine — a Windows master can drive Linux and macOS workers.
FFmpegNot required. A tested build ships inside the bundle, in bin/.
PythonNot required. The services are frozen single-file executables.
DatabaseNot required. SQLite is embedded and created on first run.
NetworkA LAN the machines share. Workers find the master automatically over mDNS.
DiskScratch space on each worker for its chunks, plus room for the finished file on the master.
Note

There is no installer, no service registration and no admin-only setup step. You unzip a folder and run it. That is the whole install on every platform.

Who this is written for#

This documentation assumes you understand video files and what an encode is. It does not assume you have run a distributed system before. Where a page covers something aimed squarely at facility operators — colour management, QC evidence, MAM integration — it says so at the top, and you can skip it until you need it.

  • Editors and prosumers — start with Install the master, then Run your first job. You can ignore everything else until a job fails or you want more speed.
  • Post-production professionals — read How it works first. It explains chunk boundaries, codec parity and what the verifier checks, which is what determines whether output is deliverable.
  • Facility operators — the same path, then the configuration reference for enrollment tokens, worker approval and fleet policy.

One thing to know up front#

A worker that connects to the master is not immediately allowed to encode. It registers, reports what it can do, and then waits in pending_approval until you approve it. This is deliberate — it is the gate that stops an unknown machine joining your fleet and quietly taking work.

Heads up

If you start a worker and it never picks up a chunk, this is almost always why. Approve it on the Workers page. Add a worker covers the whole flow.