Skip to content

CLOUDFLARE Tier 1

Read original ↗

Streamline: custom video pipelines with Cloudflare Stream and Workers

Summary

Cloudflare released Streamline, an open-source developer playground that demonstrates how to build custom (bespoke) video pipelines on the Cloudflare Developer Platform by composing lower-level primitives — Containers (long-lived media processing), Durable Objects (orchestration + preview relay), and Workers (control signaling + monitoring) — around the managed Cloudflare Stream product. The design pulls RTMPS or HLS input from Stream, applies FFmpeg-based operations (overlay, subtitle burn-in, filter, encode), and publishes the result back as a livestream or hosted video, with a low-latency WebSocket preview path. The headline architectural lesson is a control-plane / data-plane split: a media-processing session's lifecycle is decoupled from the request that started it — the Container keeps processing even after the controlling Worker disconnects — which is the right shape for minutes-to-hours media jobs that must outlive any single HTTP request.

Key takeaways

Architecture extracted

Controlling Application (Workers)                Media Engine (Container)
┌─────────────────────────────┐                 ┌──────────────────────────┐
│ UI / agent / embedded client │                 │ Controller (Go HTTP srv) │
│ @cloudflare/streamline/client│──control(API)──▶│   → ops                  │
│                              │                 │ Processor (FFmpeg)       │
│ Orchestrator = Durable Object│◀── fMP4 WS ─────│   filter/overlay/        │
│   session + container        │   (preview)     │   subtitle/encode        │
│   lifecycle + preview relay  │                 └──────────┬───────────────┘
└──────────────┬───────────────┘                            │
       /relay/view (client WS)                   RTMPS/HLS in ◀┘ RTMPS/WS out
               ▼                                              ▼
        browser MediaSource                         Cloudflare Stream (Live)
  • Control plane: Worker (control signaling, monitoring, Access verification, profile → RTMPS-key resolution) + Durable Object (session + container lifecycle
  • preview relay). Data plane: the Container media engine moving RTMPS/HLS/ WebSocket media bytes.
  • Input modes: rtmp/rtmps (from a Stream Live input), hls (a Stream video manifest/video.m3u8), webcam (application-ingested chunks via session.ingest()).
  • Output modes: rtmp/rtmps (to a Stream Live input for broadcast/record), websocket (fMP4 preview via the DO relay).
  • Local vs remote: in local dev the Container is a local Docker instance, the DO is not used, there is a single unauthenticated user, and preview connects directly to a localhost WebSocket. In remote deployment the DO orchestrates and Access enforces identity.

Operational numbers / details

  • Supported pipeline operations: 4 (filter, overlay, subtitle, encode), applied in a fixed engine-defined order.
  • Preview fragment format: fMP4; delivered over WebSocket via the DO relay at /relay/view.
  • Example encode params in the post: h264, presets fast/veryfast, 1500k bitrate, 1280x720, 30 fps, gop: 60.
  • Public playground limits (per the post): one container identity per verified user, one active session per user, plus global admission control, concurrency, media, and session limits; no user can replace another's session.
  • Known bottleneck: "Streamline uses Container CPU for media processing, which introduces a bottleneck at higher qualities or frame-rates."

Caveats

  • Developer-playground / reference architecture, not a managed product. This is an open-source demonstration of how to compose primitives, explicitly modular so the media engine "could be replaced with dedicated encoding products in the future." No production SLOs, throughput numbers, concurrency ceilings, or latency distributions are disclosed.
  • CPU-bound processing is the named scaling limit; no GPU/hardware acceleration today. Forward work named (not shipped): computer-vision pipelines, hardware-accelerated media processing, realtime next-gen protocols (WebRTC, MoQ), and native video encode/decode primitives in Workers.
  • The owner deployment's singleton, single-active-session security model is explicitly not the model for a public multi-user service — the post calls this out directly; the public playground uses a different per-user model.
  • FFmpeg as the processor is "an internal implementation detail rather than part of the user-facing API" — the public contract is the op set, not FFmpeg flags.

Source

Last updated · 771 distilled / 2,233 read