Skip to content

PATTERN Cited by 1 source

Centralized cloud media library

Centralized cloud media library is the architectural pattern of uploading all production media into one cloud-addressable asset namespace once at ingest, and having every downstream consumer (editorial, VFX, DI, archive, monitoring) read from that single library — instead of physically distributing media copies between consumers.

Problem

Traditional film + TV post-production workflows distribute media physically between consumers:

  • Original Camera Files (OCF) written to LTO tape from set.
  • Tape shipped to post vendor; duplicates shipped to other vendors.
  • "Wall of portable hard drives at their facility, with media being hand-carried between vendors because alternatives are not available."
  • Every downstream consumer manages its own copy; status checks happen by phone.

Properties of this model:

  • Non-scalable — drive logistics is linear in title count + vendor count + revision count. Netflix's ~200–700 TB per title across hundreds of titles per year × dozens of vendors per title saturates the physical model.
  • High latency — per-airplane-shipment cross-region handoffs.
  • High error rate — human handling, inconsistent organisational conventions, physical drives lost or damaged.
  • Exclusionary — only markets with mature physical post infrastructure can participate efficiently.
  • No shared observability — status lives in individual vendor inboxes + phone calls.

Solution

Upload media to a cloud library once at ingest. Serve every downstream consumer from that one namespace:

Ingest   → Cloud Library (one asset namespace)
                │
                ├→ Editorial (pull proxies)
                ├→ Dailies workflow (pull for QC + colour + render)
                ├→ VFX vendor N  (VFX Pulls → Workspace folder)
                ├→ DI facility   (Conform Pulls → online package)
                ├→ Remote editorial workstation
                ├→ Archive tier  (automatic tier-2 copy)
                └→ Monitoring dashboard (activity stream)

Properties of this model:

  • Scales sub-linearly — adding a consumer is adding a read path, not adding a shipping lane.
  • Low-latency access — every consumer reads from the library; no drive travel.
  • Shared observability — the library's activity stream is the status source of truth; no phone calls.
  • Inclusive — any market with internet access to an ingest centre + the library can participate on the same footing as tier-1 markets.
  • Eliminates per-vendor I/O surface drift — one Workspaces- style standard I/O method replaces N per-vendor bespoke methods.

Requirements

For the pattern to work at film-production scale, several preconditions:

  1. Hybrid-cloud ingest — edge ingest centres close to production sites, connected by CDN-class backhaul to the cloud. Otherwise the library can't be populated fast enough.
  2. Open media standards — ACES / ASC MHL / ASC FDL / OTIO so downstream automation can consume the library without per-title bespoke scripting.
  3. Standard I/O surface — Workspaces-style shared folder so VFX + DI vendors don't each invent their own file-transfer method.
  4. Durable archive tier — the library is both serving surface and archive; automatic tier-2 backup is a requirement not an option.

Canonical wiki instance — Netflix MPS (2025-04-01)

Netflix's Media Production Suite inside Content Hub is the first wiki-documented instance:

  • Gateway: Footage Ingest populates the library from production drives at ingest centres.
  • Library + I/O: Media Library + Workspaces (Google-Drive- style shared folders inside Content Hub) are the read surface.
  • Downstream consumers: Dailies, Remote Workstations, VFX Pulls, Conform Pulls, Media Downloader — all MPS tools.
  • Observability: Content Hub's Footage Ingest dashboard surfaces upload + archive + pipeline status for any stakeholder without out-of-band phone calls.
  • LTO default off: "When utilizing MPS, we don't require LTO tapes to be written unless there are title-specific needs." A structural change from industry norm.

Worked example — Senna (2023 Brazilian F1 series, geographically distributed across Argentina / Uruguay / Brazil / UK / Spain / Canada / US / India). No hand-carried drives between VFX vendors; Footage Ingest + VFX Pulls + Workspaces + Conform Pulls moved material across the global collaboration via the library.

Tradeoffs + caveats

  • Requires cloud-region durability + availability. A library outage blocks every consumer simultaneously. Compare to the legacy model's partial failures (one facility's drive damaged — other facilities keep working).
  • Requires bandwidth at the consumer edge. Remote Workstations shift the bandwidth need from ingest-side to consumer-side; if consumer-side bandwidth is poor, the cloud library advantage degrades.
  • Security surface concentrates. One cloud namespace holds all pre-release OCF for all titles simultaneously — access control + audit logging are now single points of compromise instead of distributed across vendor facilities.
  • Bandwidth cost at fill + egress. The bits pay for themselves vs. LTO + airplane logistics at scale, per Netflix's disclosed adoption (>350 titles), but not quantified in the source.
  • Cold-archive retrieval latency. The post mentions "second tier of cloud-based storage for the final archive" — that tier's retrieval SLA matters for restore use cases.

Adjacent patterns

Seen in

Last updated · 319 distilled / 1,201 read