12 — Stream: Video Upload, Encoding, and Delivery

"Video hosting on Cloudflare, somehow" was my Stream summary, and it hid why the product exists. The model that pinned it: Stream is a managed pipeline that takes a raw video upload and produces adaptive, globally-delivered playback — encoding, storage, and CDN delivery are all handled, so the application code treats a video as an opaque ID. [1] The complexity of video (codecs, bitrates, resolutions, formats, player compatibility) is the whole reason this product exists; the application shouldn't have to touch any of it.

The framing that landed is what the pipeline replaces. Doing video "by hand" means: encode the source into multiple resolutions and formats, serve them from object storage, wire up a player that picks the right variant based on the viewer's bandwidth, handle range requests for seeking, and cache it globally so a viewer in Tokyo doesn't pull bytes from Virginia. Each of those is a project on its own. Stream collapses all of them into "upload a video, get a playback ID" [1][2].

Video delivery

The core pipeline is end-to-end [2][3]:

• Encoding. A raw upload is transcoded into multiple resolutions and bitrates automatically — typically a ladder from low-resolution (for poor bandwidth) up to full HD or 4K. This is the "adaptive bitrate" set.
• Storage. The encoded variants are stored by Stream; I don't manage the buckets or the files.
• CDN delivery. Playback pulls from Cloudflare's global CDN, so a viewer anywhere gets the bytes from a nearby edge.
• Player. Stream provides a customizable player, or I can use a standard player pointed at the playback URL.

The application-facing surface is a playback ID. Embed the player with that ID, or hit the playback URL, and Stream handles the rest — including the adaptive bitrate negotiation that switches the viewer between resolutions as their bandwidth changes.

Live streaming

Stream also handles live video [4]. A broadcaster sends a live feed from a tool like OBS Studio or Wirecast to an ingest endpoint; Stream takes care of transcoding the live feed into adaptive variants, distributing them through the CDN, and serving them to viewers in real time. From the application's perspective, a live stream has a playback ID the same way a recorded video does — the difference is just that the bytes are arriving live rather than from storage.

This collapses the barrier to "we want to broadcast an event to a global audience." The encoding, the global distribution, the player — all of it is the same pipeline whether the content is on-demand or live.

Video processing

Two layers of processing are worth distinguishing [5]:

• Automatic, built-in. Stream's encoding/transcoding for adaptive bitrate is automatic and unconditional — every upload gets the multi-resolution treatment. That's the baseline.
• Custom, via Workers. For deeper customization — watermarking, metadata injection, intercepting video requests — a Worker can sit in front of Stream the same way it sits in front of R2. The Worker intercepts the request, does its transformation, and returns the (possibly modified) response. This is the "video processing via Workers" pattern.

The split matters because the built-in processing covers the common cases (encode, deliver, seek) for free, and the Worker-based processing is reserved for the cases where I genuinely need to modify the stream — not for basic serving, which Stream already handles.

How Stream relates to R2

Stream is the higher-level product; R2 is the raw layer underneath it. For a video-heavy application, the question is how much of the pipeline I want to own:

• Stream — give me playback, handle the codecs. I treat videos as IDs.
• R2 + a Worker — I store the raw files and build the serving logic myself. More control, more work, and I'm now responsible for encoding, adaptive bitrate, and player behavior.

The default for almost any video use case is Stream. R2 + a Worker becomes the answer only when the video pipeline needs something Stream doesn't provide — a custom encoding step Stream can't do, a non-standard delivery mechanism, or a cost shape that favors owning the raw storage. For everyone else, Stream's "upload and forget" model is the right call.

How I use this

The rule I keep: any video that needs to be played back by humans goes through Stream, full stop. The application stores the playback ID alongside whatever metadata it has (title, owner, permissions), and the actual bytes, codecs, and delivery are Stream's problem. When I find myself reaching for R2 to store video directly, that's the signal to ask what I'm trying to do that Stream doesn't already handle — and most of the time, the answer is "nothing, I should just use Stream."

References

[1] Cloudflare, "Cloudflare Stream — Cloudflare Documentation," Cloudflare Developer Platform. [Online]. Available: https://www.cloudflare.com/developer-platform/products/cloudflare-stream/

[2] Cloudflare, "Delivering videos with Cloudflare," Cloudflare Support Docs. [Online]. Available: https://developers.cloudflare.com/support/more-dashboard-apps/cloudflare-stream/delivering-videos-with-cloudflare/

[3] Cloudflare, "Stream delivery — Cloudflare Stream," Cloudflare Application Services. [Online]. Available: https://www.cloudflare.com/application-services/solutions/stream-delivery/

[4] Cloudflare, "Serverless live streaming with Cloudflare Stream," Cloudflare Blog. [Online]. Available: https://blog.cloudflare.com/stream-live/

[5] Cloudflare, "VOD platform — video-on-demand streaming software," Cloudflare Developer Platform. [Online]. Available: https://www.cloudflare.com/developer-platform/solutions/video-on-demand/