Simulating a streaming stack
Video-on-demand and live video solve different problems on different timelines. A streaming platform usually runs both at once, alongside a third system, the edge network, that neither one owns but both depend on. BeemMeUp's Cloud Video, Platform Architectures and Media Network tools each model one of those shapes, which makes the differences between them easy to see side by side.
The VOD chain has time on its side
Video-on-demand starts with a finished file. No viewer is waiting on the other end yet, so everything after upload can take as long as it needs to. The chain runs in order. The file lands in storage. A transcoder reads it and produces a ladder of renditions at different bitrates and resolutions. A packager slices each rendition into segments and writes a manifest that lists them. The packaged output moves into origin storage, and a CDN in front of that origin is what viewers actually hit when they press play.
Cloud Video Lab walks that sequence through a cloud provider's services (upload, transcode, package, store, distribute), so the chain shows up as five separate stages. The stage that matters most for cost and quality is the transcode step: the ladder's bottom rung has to be low enough for a bad connection, the top rung high enough to look right on a large screen, and every rung in between is a bitrate a viewer's player will actually switch to mid-playback if their network changes.
Live ingest has no room to redo anything
Live changes the order of operations. There's no finished file to start from, only a continuous signal arriving from an encoder, over RTMP, SRT or WebRTC depending on what's sending it. The packager has to segment that signal as it arrives, appending each new segment to a manifest that works as a sliding window: old segments drop off the front as new ones join the back. Nothing in that path gets a second pass. A frame that arrives corrupted or late is a frame the packager has already committed to before it can be corrected.
Platform Architectures models this as an ingest-to-CDN topology: the encoder feeding the ingest point, and the path from there out to viewers. The whole thing races the clock in both directions. The source is still generating video behind it, and every viewer's player is a few seconds behind live, trying not to fall further back.
The edge network is shared infrastructure, and it can fail on its own
Both pipelines end at the same place: an origin that holds the authoritative copy of a manifest or segment, and a network of edge caches in front of it that actually answer viewer requests. The point of that edge layer is distance. An edge node close to a viewer serves a cached segment in milliseconds; a request that has to travel back to the origin costs however far away the origin physically is, every time it happens.
That split creates its own failure modes, independent of whether the video behind it is live or on demand. A cache miss sends a request past the edge to the origin. If enough requests miss at once, say a cache expiring under heavy load, the origin can see a spike of traffic it was never sized to absorb directly. Media Network Lab maps that origin-and-edge topology, with cache hits and misses visible as they happen. A user can trigger an incident on it too, an edge node going down or an origin overload, and watch where the request goes instead.
One player, three different jobs to prove
All three labs share a single playback component: whatever pipeline produced a manifest, VOD, live, or a cache-simulated origin fetch, the same player element is what actually renders the result. Building that piece once, before any of the three labs, meant each pipeline only had to hand the player a manifest and a set of segments.
Chain, timeline, network: those are the three axes a real streaming stack gets built along, and a viewer only ever sees the last few seconds of all three working, or not, at once.