Global Video Delivery Network

When a creator uploads a movie, the first job is to keep the original file safe in long term storage. Everything else is made from it, so if a later step goes wrong, we can always start again from the original.

Next, the video is cut into short pieces, called chunks or segments, usually a few seconds long. One giant file would keep one computer busy for hours. Many short pieces can be shared out to many computers at once, like a class splitting a big puzzle so each kid builds one corner.

The cuts must land on keyframes. A video does not store every picture in full. Most pictures only store what changed since the one before, like a flip book where most pages say, same as before, but the ball moved a bit. A keyframe is a page drawn in full. A chunk that starts on a keyframe can be played on its own, which is exactly what we need. The trade-off is size: more keyframes make cutting and jumping around easier, but each full page takes extra space, so the file grows.

Transcoding means turning a video into a different size or format, like redrawing a big painting as a postcard. For each chunk, we put a job ticket in a queue. A large group of worker computers each grab the next ticket, transcode that chunk, save the results, and come back for another.

Because the chunks do not depend on each other, a two hour movie can be finished in minutes by spreading it over hundreds of workers. If a worker crashes or a chunk fails, only that one ticket goes back into the queue to be tried again. Nobody starts the whole movie over.

When every chunk is done, a packager labels the pieces and writes the menu files that tell players what exists. The finished files are saved in origin storage, the main warehouse that everything else copies from.

The trade-off is bookkeeping. Something has to track which tickets are finished, make sure every chunk was made with the same settings so the seams never show, and build the final menu only after the very last chunk is done.

Viewers have very different screens and internet speeds. A big TV on fast home internet wants a sharp picture. A phone on a bumpy bus ride wants something smaller that still plays smoothly. So each chunk is made in several versions, called a bitrate ladder. Bitrate is how much data is used for each second of video. More data means a sharper picture, but it needs a faster connection.

A simple ladder might be 1080p at about 5 megabits per second, 720p at about 3, 480p at about 1.5, and 360p at under 1. Big services tune these steps for each title, because a cartoon with flat colors needs far less data than a fast football game to look good.

A codec is the recipe used to squeeze the video into fewer bytes. H.264 is the old, reliable recipe that almost every device can play. Newer recipes such as AV1 often make files around a third smaller for the same quality, which saves a lot of internet traffic. But they take much more computer time to make, and older devices cannot play them. So a popular title, watched millions of times, is worth extra encodes with the newer recipe, while a rarely watched video may only get the basic ladder.

Before the player can order anything, it needs a menu. That menu is called a manifest. It lists the qualities that exist and, for each one, the chunks in order and where to fetch them. The player reads the menu first, then downloads chunks one after another, like eating a meal course by course.

There are two popular menu styles. HLS was created by Apple and uses playlist files ending in .m3u8. MPEG-DASH is an open standard and uses manifest files ending in .mpd. Many devices understand one, and some understand both.

In the past, services often stored every chunk twice, once for each style, which doubled the storage and made caches less useful. CMAF is a shared chunk format, so both menu styles can point to the very same chunk files, and only the small menus differ. The catch is that some older devices cannot play the shared format, so a service may still keep a few extra copies for them.

The clever part happens inside the viewer's player. Before fetching each chunk, it asks two questions. How fast did the last chunks arrive? And how many seconds of video do I already have saved up, waiting to be played? That waiting pile is called the buffer, like snacks stacked on your plate before you get hungry.

If chunks are arriving fast and the buffer is full, the player picks a sharper version for the next chunk. If the internet slows down, for example when a train enters a tunnel, it switches to a smaller version before the buffer runs empty. A blurry picture for a few seconds is much better than a frozen spinning wheel.

Switches happen only between chunks, which is why every version of a chunk starts at the same moment on a keyframe. The trade-off is jumpiness. Switching too eagerly makes the picture flip between sharp and blurry, so good players step down quickly but climb back carefully. Many also start at a lower quality so the video begins fast, then climb.

A CDN, short for content delivery network, is a large set of computers spread around the world that keep copies of files close to viewers. The closest ones are edge servers, like the corner shop on your street. Behind them are bigger regional caches, like a warehouse that serves many shops. Behind those is an origin shield, a single guard in front of the main warehouse, and at the very top is origin storage itself.

When you press play, your player asks a nearby edge. If the edge has the chunk, that is a hit, and it hands it over right away. If not, that is a miss, and the edge asks its regional cache, which asks the shield only if it misses too. Each level keeps a copy on the way back down, so the next viewer nearby gets a hit. For popular videos, the vast majority of requests are answered at the edge.

The shield has a special job. When a brand new episode comes out, many caches may miss at the same moment. The shield collapses those identical requests into one trip to the origin and shares the answer, so the origin is not buried. For big premieres, services also copy the video to the edges ahead of time.

Edge space is limited, so rarely watched videos may only live in the higher tiers, and their first viewer waits a little longer. Live streams add one more twist: their menus change every few seconds as new chunks appear, so menus are cached only very briefly, while the chunks themselves never change and can be cached for a long time.