Video & media
Live streaming - latency against the buffer that saves you
Ingest, segmenting, and the real cost of every second of latency removed
What this board gets wrong on purpose
The tension
The board buys 8 seconds of glass-to-glass latency with a rolling window of three 2-second segments, and those two facts are the same fact: the player is three segments behind live BY CONSTRUCTION, and those three segments are also the entire cushion it has when a Wi-Fi router stutters. Halving the segment length halves both. Chat arrives over a websocket in 200 milliseconds, so every viewer learns about the goal from the chat window seconds before they see it - and the 2-second choice also writes 125,000 objects a second across the platform, which is 54,000 dollars a day in PUT requests alone, before a single byte is stored. Going to 200 ms chunks to fix the chat problem multiplies that by ten and removes the cushion entirely.
1. Requirements
Live is not video-on-demand with a shorter deadline. It is a different system, because the thing every other design leans on - the ability to fetch a byte again - does not exist. A second that is lost is gone.
Functional
- A broadcaster pushes one stream over RTMP or SRT and it is playable worldwide within seconds.
- The stream is transcoded to a ladder in real time, so viewers on poor connections are not excluded from a live event.
- A viewer joining halfway in starts at the live edge, not at the start.
- Chat and stream events are delivered alongside the video.
- The broadcast is recorded: a rolling DVR window during the event, and a permanent replay afterwards.
- A broadcaster can see, live, whether their own upstream is the problem.
Non-functional
- Glass-to-glass latency target of 8 seconds in standard mode, 3 seconds in low-latency mode. It is a target, not a guarantee, and the difference is the point of this board.
- Rebuffer ratio under 0.5 percent - a looser target than video-on-demand, because there is no buffer to hide behind.
- Ingest availability 99.99 percent during a broadcast. A dropped ingest is not a degraded experience, it is the event ending.
- One segment must serve a million viewers. Any per-viewer element in a manifest or URL breaks that and is treated as an outage, not a feature.
- No single-segment loss may stall playback: a missing rung falls back to a lower one within one segment.
Questions to ask before designing this
- What is the latency REQUIREMENT, in the product sense? Betting and auctions need under 2 seconds. A concert needs 10 and would rather never stutter. These are two different systems and the answer changes every box on the diagram.
- How many concurrent channels, and how peaked? 50,000 channels at 4 hours each is a fleet-sizing problem; one channel with 20 million viewers is a fan-out problem. They are not the same build.
- Is chat in scope? If yes, the spoiler problem is in scope, and either chat must be delayed to match video or video must be dragged down to match chat.
- Is DVR required during the broadcast, or only a replay afterwards? Seek-during-live turns a rolling window of three segments into a full manifest of thousands and changes the cache behaviour completely.
- What upstream do broadcasters actually have? Designing for 6 Mbps when the median is 2 means the ladder starts below where you thought.
- Who pays for the egress - the platform or the broadcaster? That answer decides whether the top rung exists.
The rest of this board
Available on Tier Slate
This page publishes the question. The answer — 5 more written pages, an 11-step narrated walkthrough and a 5-table schema — is the board itself, and it opens in Tierslate.
- 5written pages
- 11walkthrough steps
- 5tables31 columns
5 pages behind this one
- Capacity estimation
- Storage estimation
- Availability
- How it works
- Deployment plan
More boards
Upload, transcode, deliver - and pay for the bandwidth.