News · New this week
Streaming latency: why live video runs behind TV
The delay on a live stream is deliberate. With example numbers, chunks and a player buffer add up to about sixteen seconds, and low-latency mode cuts it to about four.
Your neighbour's cable TV shows the SIX before your phone does, and your internet speed is mostly not the reason. The delay is put there on purpose, so the video doesn't stutter.
This is a classic system design interview question, so it's worth knowing the pipeline.
The path from stadium to phone
The stadium feed is live camera video, and it's very heavy. Sending it raw isn't practical.
First stop is the encoder. It compresses the video to make it smaller, and it also cuts the stream into chunks, which are small pieces of video.
Next is the CDN. That's a server near your city that holds copies of the chunks, so they reach you quickly. Delivery is fast here, so the CDN isn't where the big delay sits.
Last is the player on your phone. It collects a few chunks before it starts playing. That's where the delay really builds up.
Where the seconds go
Two things stack up.
The first is the chunk itself. A chunk can't leave until it's fully made. With a four second chunk, the stream waits four seconds before that piece goes anywhere.
The second is the buffer. The phone holds three chunks before playing, and that stored video is the buffer. Cable TV doesn't work this way.
Take the example numbers from the reel: four second chunks and a three chunk buffer. That comes to roughly sixteen seconds, plus network time. These numbers are illustrative, not measurements from any real service.
Low-latency mode and its cost
Low-latency mode shrinks the chunk. In the reel's example, one second chunks bring the total to about four seconds, against about sixteen before. Same caveat applies, these are illustrative numbers.
The cost is a smaller buffer. Less video sits in reserve, so if your network hiccups there's less stored to play through it, and the video can pause.
That's the trade. Less delay means less smoothness, and more smoothness means more delay. Neither setting is correct everywhere. You pick based on what the viewer cares about more.
What to remember
Next time someone blames a late SIX on a slow connection, walk them through the chain: encoder, chunk, CDN, buffer. Then try the arithmetic yourself with different chunk sizes and buffer sizes, and see how delay and risk of stalling move together. If you get this question in an interview, that trade is the answer they want to hear.
