Skip to content

SYSTEM Cited by 2 sources

Netflix Media Production Suite (MPS)

Media Production Suite (MPS) is Netflix's cloud-based toolchain for film + television production, hosted inside Content Hub. It covers the full production lifecycle from on-set capture through picture finishing, using a centralised cloud media library as its load-bearing architectural substrate.

MPS was described publicly in Netflix TechBlog's 2025-04-01 post Globalizing Productions with Netflix's Media Production Suite, which names the seven component tools, the hybrid-cloud infrastructure shape, and a Senna (Brazilian F1 series) case study. As of that post, >350 titles have used at least one MPS tool across UCAN, EMEA, SEA, LATAM, and APAC.

Design stance

The bet underneath MPS is a centralised cloud media library — upload once, serve every downstream consumer — instead of the traditional workflow of LTO tapes + hand-carried drives moving physically between production, editorial, VFX, and DI vendors. Given an average Netflix title produces ~200 TB of Original Camera Files (OCF) with outliers up to ~700 TB, the physical-media model does not scale across hundreds of titles per year, and it structurally excludes emerging-market productions without local post-production infrastructure.

The second bet is standards-driven automation: lean on ACES / AMF / ASC MHL / ASC FDL / OTIO so the per-title customisation burden that mature post- production facilities do by hand (hot-folder scripts, per-vendor sidecar schemas) becomes automatable at Netflix scale. See concepts/open-media-standards for the per-standard mapping.

Infrastructure

MPS runs on hybrid cloud infrastructure: AWS as the durable substrate, Netflix Open Connect as the high-bandwidth transit backbone, and per-region ingest centres deployed globally to provide high-speed internet connectivity where production facilities don't already have it. Drives are plugged in at an ingest centre, uploaded in "a matter of hours," and the downstream MPS tools consume the cloud-hosted assets without any further physical movement.

Component tools

The 2025-04-01 post enumerates seven tools:

  1. Footage Ingest — drive-plug-in application that validates the drive manifest, uploads OCF + OSF, runs checksum validation, inspects + extracts metadata, builds playable proxies for viewing / sharing / downloading, and backs everything up to a tier-2 cloud archive. This is the gateway tool: every other MPS component reads from the library that Footage Ingest populates.
  2. Media Library — central search + preview + share + download surface over the ingested asset corpus. The Google-Drive-ish "Workspaces" feature inside Content Hub composes Media Library assets into shared folders for VFX vendor handoff.
  3. Dailies — operational-team-backed workflow providing automated QC of footage, sound sync, application of colour, rendering, and delivery of dailies directly to editorial.
  4. Remote Workstations — cloud-hosted editorial workstations + associated storage; lets editors anywhere in the world work against the centralised library without local media copies.
  5. VFX Pulls — EDL-driven automation: editorial uploads an EDL, MPS transcodes the referenced shots, consolidates associated colour + framing files, and places everything in a Workspace folder the VFX editor can farm out to vendors. Replaces per- vendor I/O methods with a single Workspaces-based I/O surface.
  6. Conform Pulls — post-lock workflow used by DI facilities: upload an EDL, run QC across the referenced media to ensure smooth conform, then consolidate + trim + package all required media for picture finishing.
  7. Media Downloader — automated pull that kicks off when media lands in the Netflix cloud, for the handful of downstream consumers that still need local copies.

Matching layer

Both VFX Pulls and Conform Pulls depend on resolving EDL references against ingested OCF. The current system supports:

  • Exact metadata match — default path.
  • Fuzzy metadata match — "several variations of fuzzy matching that can take place" when EDL metadata is imperfect.
  • Perceptual CV match — "a current investigation in using one of our perceptual matching algorithms, allowing for a perceptual conform using computer vision, instead of solely relying on metadata."

The fallback hierarchy is a reusable architectural shape for any pipeline that resolves references by identifier and can fall through to content-similarity probes when metadata is missing or imperfect.

Automation surface

MPS's automation is enabled by Netflix's commitment to open media standards instead of bespoke per-title JSON configurations:

  • ACES + AMF — colour pipeline management.
  • ASC MHL — file-management / checksum verification.
  • ASC FDL — framing interoperability (camera formats, lens choices, safety areas).
  • OTIO — timeline interchange between editorial, VFX, and DI.

Per the article: "Leaning into standards like this means that many things can be automated at scale and more importantly, high- complexity workflows can be offered to markets or shows that don't normally have access to them."

Observability surface

Content Hub exposes a remote monitoring dashboard over the Footage Ingest activity stream so production + post supervisors can see upload progress, archive status, and downstream pipeline state without the traditional phone-call-the-vendor check-in. This is a secondary but meaningful architectural property of the centralised library model — the library is also the status log.

Worked example — Senna (2023)

Netflix's Senna (Brazilian F1 series) was an early MPS adopter (production started June 2023, MPS in beta at the time). Shot across Argentina, Uruguay, Brazil, and the UK; editorial in Porto Alegre + Spain; VFX in Brazil, Canada, US, and India orchestrated by Scanline VFX. Senna's MPS usage was VFX-heavy: Footage Ingest handled the cross-country upload, then VFX Pulls distributed shots to geographically dispersed VFX vendors through Workspaces, then Conform Pulls handled the online at Brazilian DI facility Quanta. The production did not require LTO tapes — traditionally a default.

Media processing engine — FilmLight FLAPI (2026-04-24 post)

MPS's core studio media-processing engine is FilmLight's FLAPI — the backend-callable API of the same image-processing + colour-science engine that powers FilmLight's Baselight / Daylight desktop products. Netflix's build-vs-partner stance: "building a world-class image processing engine in-house is a significant, long-term commitment: one that would require deep, continuous collaboration with camera manufacturers and the wider industry … Rather than duplicating that work, we chose to integrate" (Source: sources/2026-04-24-netflix-scaling-camera-file-processing-at-netflix). Canonical instance of patterns/industry-api-partner-as-media-engine.

Two load-bearing FLAPI roles inside MPS:

  1. Inspection at ingest. When media lands in Content Hub with ASC-MHL manifests, Footage Ingest calls FLAPI to extract camera metadata, conform workflow-critical fields to Netflix's normalized schema (concepts/camera-metadata-normalization), and make it searchable across the downstream pipeline.
  2. VFX-plate / deliverables generation. Debayer OCF with format-specific parameters; crop + de-squeeze with ASC FDL; apply ACES Metadata Files (AMF) for repeatable colour pipelines; generate deliverables in varied formats. Netflix ships AMFs alongside OpenEXR outputs so downstream recipients know exactly which transforms remain to apply.

Runtime packaging — Cosmos Stratum Functions. FLAPI is bundled in Ubuntu-based Docker images with Java/Python glue and dispatched as Cosmos Stratum Functions that "accept an input clip, output location, and varying parameters such as frame ranges and AMF or FDL files when debayering footage … quickly invoked to process a single clip or sub-segment of a clip and shut down again to free up resources." Canonical instance of patterns/serverless-function-for-media-processing.

Runtime contract — four-part checklist any tool must satisfy:

  • Packageable as Serverless Functions in Linux Docker images.
  • Can run on CPU-only instances (concepts/cpu-only-media-processing) — FLAPI also supports GPU, but Netflix chose CPU to tap the wider encoding pool and free GPUs for other workloads.
  • Headless invocation via Java / Python / CLI (concepts/headless-api-invocation).
  • Stateless operation — terminate and re-launch on failure.

Same Docker image deploys to AWS and on-prem, giving "consistent assessment of footage wherever it may exist" — important for global productions where OCF sometimes never leaves the region it was shot in.

Elastic shared-pool scaling for spiky production workloads (VFX turnovers, finishing pulls) — canonical instance of patterns/elastic-scaling-for-production-spikes. Netflix's framing: "swarm pull requests to get them through quickly, then immediately yield resources back to lower priority workloads … lightning-fast turnaround times and less anxiety around deadlines for our filmmakers."

Desktop ↔ backend coherence as a pre-production validation gate. Because the engine is the same on FLAPI and on Baselight workstations, Netflix's workflow specialists can "use Baselight on their workstations to manually validate pipeline decisions for productions before the first day of principal photography." A separate reimplementation engine would make such validation advisory only.

Ongoing partnership, not vendor contract. Netflix and FilmLight collaborate on roadmap alignment for new camera formats + open standards, joint accuracy + performance validation, real-world edge-case debugging, API evolution, and feedback into open standards (ACES, ASC FDL). Worked example: ACES 2 — FilmLight provided the support roadmap, Netflix collaborated on integration + fed feedback to the ACES technical leadership during that integration.

Seen in

Last updated · 542 distilled / 1,571 read