Five courses, one path through video delivery

FFmpeg, HLS, DASH and WebRTC get talked about as if they're competing options for "how to stream video." They sit at different points in the same pipeline, and a curriculum that teaches them in the wrong order teaches four disconnected tools instead of one system.

FFmpeg comes first because it's the only one of the four that isn't about delivery. It's the tool that turns a source file into the renditions a delivery method will serve: transcoding to a different codec, scaling to a different resolution, muxing audio and video into a container, applying filters. What gets streamed is something FFmpeg, or a tool doing FFmpeg's job, already prepared, and HLS, DASH and WebRTC only make sense once that's clear.

What segmented delivery means

HLS and DASH solve the same problem the same way. Both cut the encoded video into short segments, a few seconds each, and publish a manifest that lists them: .m3u8 for HLS, an XML .mpd for DASH. A player downloads the manifest, requests segments in order over ordinary HTTP, and can switch to a different quality rendition at the next segment boundary if the network changes. That's what adaptive bitrate means in practice: a player choosing a different file to request next.

The HTTP part is the whole design. Segments are cacheable, so a CDN in front of the origin can serve most requests without touching the encoder again, and no server has to hold a persistent connection per viewer. That buys scale. It costs latency: segments a few seconds long mean a player is, at minimum, a few seconds behind live, often more once buffering is added in.

HLS and DASH differ less in what they do than in where they come from and what plays them natively. HLS came from Apple and plays natively in Safari; most other browsers play it through a JavaScript library such as hls.js. DASH is an MPEG standard with a more general XML manifest, and browsers play it through a library such as dash.js. Teaching them back to back is mostly teaching the same segmented-delivery idea twice, once through each manifest format, which is exactly why the curriculum puts them next to each other.

Where FFmpeg's job ends

Low-latency HLS is the clearest place to see the boundary between FFmpeg's job and HLS's. LL-HLS adds partial segments, smaller chunks published before a full segment is complete, so a player can start rendering a segment before the whole thing has arrived. The playlist tags that make that possible, EXT-X-PART for a published partial segment and EXT-X-PRELOAD-HINT for one that's still being written, are HLS playlist syntax.

FFmpeg's own hls muxer never emits either one. It produces the segment source that a dedicated packager or origin server then slices into parts. FFmpeg prepares the media, and the packager manages the playlist timing that makes low latency work. The BeemMeUp lessons on LL-HLS say that directly and show only the half of the pipeline FFmpeg covers.

WebRTC breaks the model on purpose

WebRTC is the odd one out, and the curriculum puts it last because understanding what it gives up only makes sense once you understand what segmented delivery was providing. There's no manifest, no HTTP segment requests, no CDN caching layer between the source and the viewer. Media moves over a continuous real-time transport built for sub-second latency, the way a phone call or a video conference needs it.

That's the trade in one line: WebRTC gets latency an HLS or DASH pipeline structurally can't, and gives up the HTTP caching and standard CDN distribution that make segmented delivery cheap to scale to a large audience. Neither is the better protocol in the abstract. One is built for a conversation, the other for an audience.

The catalog that came out of that order

Media Pipelines sits after all four for the same reason WebRTC sits after HLS and DASH: it's the course that asks how these pieces connect into an actual system, encode with FFmpeg, package for HLS or DASH, add WebRTC where latency demands it, and that question only has an answer once the pieces it connects are familiar. Taken in order, the five courses follow a video from the encoder to the viewer.