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.
| Requirement | Detail |
|---|---|
| Operating system | Windows, macOS or Linux. Mixed fleets are fine — a Windows master can drive Linux and macOS workers. |
| FFmpeg | Not required. A tested build ships inside the bundle, in bin/. |
| Python | Not required. The services are frozen single-file executables. |
| Database | Not required. SQLite is embedded and created on first run. |
| Network | A LAN the machines share. Workers find the master automatically over mDNS. |
| Disk | Scratch space on each worker for its chunks, plus room for the finished file on the master. |
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.
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.