Correctness & QC
What gets checked before a job is called complete, and what evidence is kept afterwards. This page is aimed at anyone who has to defend a delivery.
If you are encoding for yourself, the baseline verification described first is all you need. If you deliver to a broadcaster, a streamer or a client with a specification, the rest of this page is the part that matters — it is the difference between believing output is correct and being able to show it.
Why this exists#
Distributed encoding introduces a failure that local encoding does not: the output is assembled from pieces produced on different machines. If one machine differs — a different FFmpeg build, a different accelerator, a different colour interpretation — the result is a file that plays, passes a casual look, and is wrong somewhere in the middle.
Compounding it, FFmpeg exits successfully in many of the cases you would want it to fail. A truncated encode, a silent audio track, a dropped caption track — all exit 0. Verification exists because "the encoder did not complain" is not evidence of anything.
The baseline check#
Every job, on every configuration, passes through this before it is reported complete:
- The assembled duration must match the source within a one-frame tolerance.
- If the source carried audio, the output must carry audio.
A job that fails either is reported failed rather than delivered. This is not configurable and does not need enabling.
Correctness verifiers#
Beyond the baseline, a set of verifiers examines properties that only matter because the encode was distributed. Each produces a recorded outcome rather than a pass/fail opinion.
| Verifier | What it establishes |
|---|---|
| Quality metrics | PSNR, SSIM and VMAF sampled around every chunk boundary — the places a seam would show. |
| Timing continuity | Walks the packet timeline and asserts strict monotonicity, so no stream jumps backwards where two chunks were joined. |
| Audio concatenation | Compares cumulative sample counts at each boundary, catching sample-level drift a listener would perceive as sync error. |
| Colour consistency | Confirms every chunk shares one colour signature. Mismatched chunks are refused at assembly rather than blended into the output. |
| Codec conformance | Scores the bitstream against the specification for the codec and profile you asked for. |
| Determinism | Audits the encoder arguments for anything that would make output vary between runs or between workers. |
| Reproducibility | Encodes twice and compares bitstream hashes for bit-exactness. |
| Source fixity | Records the source at submission and re-checks it at completion. |
Quality at the seams#
The quality metrics do not sample the whole file at random. They sample frames around each chunk boundary, because that is where distributed encoding fails and nowhere else is interestingly different from a local encode.
This is the measurement that answers the objection a technically literate client will raise — that splitting a video across machines must introduce artefacts at the joins. The metrics are per-boundary evidence that it did not.
Determinism and reproducibility#
These two are related and often confused.
Determinism is a property of the instructions. Some encoder settings introduce variation by design — anything drawing on wall-clock time, thread scheduling or a random seed. The determinism audit inspects the arguments before the encode and flags settings that would make the same input produce different output.
Reproducibility is a property of the result. It encodes the same input twice and compares hashes of the two bitstreams. Identical hashes mean bit-exact reproduction.
Bit-exact reproducibility means a delivery can be regenerated later and proven identical to what shipped. Without it, re-running a job a year on gives you a file that is probably the same, which is not the same as the same.
Source fixity#
The source is recorded when the job is submitted and re-checked when it completes. If the file changed underneath a running job — someone overwrote it, a sync client updated it, a transfer was still in progress when you submitted — that is caught and reported.
This is a more common failure than it sounds in a shared-storage facility, and without a fixity check it produces an output that is internally consistent and does not correspond to any single version of the source.
QC profiles#
Correctness asks whether the encode is sound. QC asks whether it meets a delivery specification — a different question with a different answer per customer.
Loudness is measured against the target of the profile you select. Three common specifications ship:
| Profile | Integrated loudness | True-peak ceiling | Typically for |
|---|---|---|---|
| ATSC A/85 | −24 LUFS | −2 dBTP | North American broadcast |
| EBU R128 | −23 LUFS | −1 dBTP | European broadcast |
| Netflix delivery | −27 LUFS | −2 dBTP | Streaming, with a tighter quality floor |
These profiles measure and report. A file that fails a loudness target is reported as failing it — the encode is not silently corrected to pass. Normalising audio to a spec is a mix decision, and making it automatically would hide the fact that the delivered mix was not what the mixer approved.
Using the evidence#
Results are attached to the job and readable from its expanded row in the queue, alongside the exact encoder arguments each chunk ran. Between them you can answer the two questions a delivery dispute turns on: what settings produced this file, and what was measured about the result.
Keep the master's database if the record matters to you. It holds the job history, the verification outcomes and the audit trail — the backup command exists for exactly this reason.
Verification coverage is strongest on jobs that actually distribute. A source short enough to encode as a single chunk exercises far less of the machinery described here, because most of it is checking properties that only exist where chunks meet. Prove your pipeline on a realistic source, not on a ten-second test clip.