Streaming Video Encoding & Packaging Pipeline  ·  View 16 of 22  ·  Operations

Encoder Build Rollout

How a new encoder reaches production without re-encoding 250,000 hours.

Editable source SVG draw.io All views
Source Encoder wrapper repo Upstream encoder open source release Build Reproducible image pinned digest SBOM + signature Determinism gate Byte-identical replay golden corpus Quality regression vs current build Shadow Shadow encode 1% of new titles Score comparison Canary Canary lane one tenant, 48 h Playback telemetry Promote Build registry approved digests New recipes pin it old recipes unchanged non-deterministic: reject decode errors: halt promotion Encoder Build Rollout and Environments Data store External / third party Application we own Security / platform Decision point failure / alternate synchronous A promoted build never re-encodes the catalogue. It is pinned by new recipes only; existing renditions keep their old digest until demand asks for a new one. v 1.0 · owner Media Platform Architecture

A promoted build changes nothing retroactively

  • New recipes pin the new build. Existing recipes and the renditions derived from them keep their digests and are untouched.
  • The catalogue migrates lazily: a rendition is re-encoded under the new build only when demand asks for one that does not exist yet.
  • This is the consequence of content-addressed identity (ADR-04) that makes it affordable rather than terrifying.

The determinism gate is first

  • A build that does not replay a golden corpus byte-identically is rejected before anything else is measured. Non-determinism would invalidate idempotent retries, cache trust and lineage in one step.
  • Quality regression against the current build is a separate gate, because a build can be deterministic and worse.

Assumptions

  • Assumed 1% shadow encode on new titles and a 48-hour single-tenant canary before promotion. Both are judgement calls, both are cheap to change.