Video and large files

Video needs nothing switching on. A file up to 10 MB is fetched and stored whole; a larger one is fetched from your origin in 5 MB pieces as it is watched, so a viewer waits for a piece rather than the whole file, a seek costs a piece rather than the file, and a part of the file nobody watches is never fetched.

How a large file is served#

• The first request for any file asks your origin for its first 10 MB (10,485,760 bytes) with a Range header, from the start of the file whatever range the viewer asked for. A file that fits is stored whole from that answer; a larger one is stored as pieces from then on, and that first viewer is answered once those first two pieces have arrived.
• Each piece is 5 MB. A viewer's request is served from the pieces it needs, and within the range a viewer asked for the edge fetches up to two pieces ahead of the one being played, so playback does not wait for your origin at every boundary.
• A seek into a part of the file the edge has not seen costs one piece fetch before the viewer is answered, plus the two read ahead, never the whole file.
• Viewers in the same location watching the same piece at the same time share one fetch; with a Home PoP, one fetch serves every location. A viewer whose player accepts brotli and one whose player does not are two copies, because the compression bucket is part of the cache key (see How caching works).
• Files are stored up to 20 GB. Beyond that a file is passed through from your origin to the viewer, unstored.

What your origin needs#

Byte ranges. Every fetch of a large file carries a Range header and expects a 206, which web servers and object stores return by default. An origin that ignores Range and answers 200 with the whole file still works: files up to 10 MB are stored normally, and larger ones are passed through to the viewer without being stored, on every request, which costs origin bandwidth and denies viewers a shared copy. Check with curl -sI -H "Range: bytes=0-0" https://origin.example.com/film.mp4: the answer should be 206 with a Content-Range header.

Give files an ETag or a Last-Modified header, which every server does by default. The edge sends it back with each piece fetch as If-Range (a strong ETag, or else the Last-Modified date), so a file you replace at the origin is never spliced together from old and new pieces. The request that notices the change is answered with the 502 page, or cut off if it was already playing, the old pieces are dropped, and the next request fetches the new file. Purge the file or the zone after replacing it if you want the old pieces gone at once rather than at their expiry. See Purging.

Ranges from viewers#

A viewer's Range request is answered with a 206 and the bytes asked for, from the copy where the edge has them and from your origin where it does not. One range per request: a request for several ranges at once is answered with the first of them, as a plain 206 rather than a multipart body. A range that starts past the end of the file gets 416 with a Content-Range: bytes */size header and no body. A malformed range gets the whole file with 200.

HLS and DASH#

Segments are files like any other and follow the rules above; under Respect Origin Cache-Control a segment whose origin sends no Cache-Control or Expires is kept for seven days. Playlists and manifests (.m3u8, .mpd) are held for 10 seconds under that setting unless your origin sends a max-age of its own, so a playlist that is still being written reaches viewers quickly; a fixed Cache Expiration Time applies to playlists too, with no cap, so a zone set to 1 Day holds a live playlist for a day. If you sign your links, sign the folder rather than the playlist, or the player's segment requests fail: see Token authentication. There is no ingest, no transcoding and no player: the edge delivers the files your origin serves, a playlist your encoder keeps rewriting included.

What is counted#

Your statistics and your invoice count the bytes delivered to viewers. The pieces the edge fetches from your origin, the ones it reads ahead included, are origin traffic: shown on the statistics page as such and never charged. See Statistics.