A video CDN is a delivery network that keeps copies of cacheable video files at network locations closer to viewers. A player asks for a manifest and then the video segments it names; the CDN serves a fresh cached copy when it can, or fetches the file from the configured origin when it cannot.
That can reduce repeated work at the origin and shorten the path for many requests, but a CDN is not the encoder or packager. Your video still needs to be prepared in a format the player can use, and cache rules and the origin must suit the content, especially when a live stream is changing.
What a video CDN is
A content delivery network, or CDN, is a layer between the place your content is stored and the people who request it. The origin is the source that serves the content. A CDN has a network of delivery locations, often called edge locations, and routes viewer requests through them. Depending on the provider and configuration, it may retain copies of requested objects so later viewers can receive them without every request going back to the origin.
For video, those objects are often not one enormous file. In common streaming formats such as HLS and MPEG-DASH, the player uses a manifest to learn which media segments are available and in what order to request them. Segments contain portions of the audio and video; captions may be delivered as associated tracks. The manifest and segments are separate requests, which means their freshness, cacheability and access rules can differ.
A CDN can therefore improve the delivery path for assets that are already prepared and served over HTTP. It does not inherently create renditions, package segments, repair a poor source video, or decide which quality a player should use. Google Cloud’s Media CDN overview describes a delivery service with routing, caching and cache filling; the exact names and arrangement of components differ between providers.
For a recorded bhajan programme that viewers replay throughout the day, packaged files may be largely unchanged. For a live news loop, the latest manifest and newly produced segments change continually. Both can use a CDN, but the policy for how long an object remains fresh cannot sensibly be assumed to be identical.
How a player requests manifests and segments
Before the player makes a request, a workflow has to prepare the content. An encoder compresses the video, possibly into multiple renditions at different bitrates or resolutions. A packager then produces a delivery format such as HLS, DASH or CMAF, including manifests and media segments. For video on demand, those prepared assets can sit in storage until someone watches. For live video, ingest, encoding and packaging keep producing current media and updated manifests.
A simplified playback sequence looks like this:
- The player is given a playback URL, often pointing to a manifest.
- It requests that manifest over HTTP. The manifest describes available tracks or renditions and identifies segments to play.
- The player requests the segments it needs, in the order required for playback. It may request additional segments as it continues.
- If several renditions are available, the player can select among them based on its own logic, device capabilities and observed connection conditions.
- For a live stream, the player periodically requests an updated manifest so it can discover newer segments.
The CDN is generally in the path for each of those HTTP requests. It does not send a single uninterrupted video pipe simply because the content is video. A request for a manifest and a request for a media segment may have different cache keys, response headers, freshness periods or authorisation requirements. If a manifest points at a different host for segments, the player may reach a different CDN route or origin altogether.
This distinction matters when diagnosing playback. A viewer might retrieve a manifest successfully but fail to retrieve a segment because of an expired access token, an origin error or a path rule that does not match. A player may also be slow because it has to wait for a segment to be produced, not because the CDN is far away. For a YouTube stream generated from a local file, upstream encoding and a stable source remain important; our guide to checking unstable frame rate in a YouTube RTMP stream from a file addresses a different but related part of the delivery chain.
What happens at the edge cache
When an edge receives a request, it first needs to know how that request should be routed and whether an eligible cached object is available. The cache key identifies what counts as the same object for caching purposes. It can be affected by elements such as the host, path, query string and configured variations. If two requests produce different keys, the edge may treat them as different objects even when they appear to refer to similar content.
If the edge has a fresh object matching the key, it can return that object to the viewer. This is a cache hit: the edge need not fetch the object from the origin for that request. Repeated requests for a popular VOD segment can benefit from this, provided the response is cacheable, has not expired and the requests map to a common key. The viewer still needs a working connection and compatible playback software; a hit is not a guarantee against buffering or any particular playback quality.
A hit depends on policy, not just the presence of a CDN. The origin’s response headers, CDN rules and any query-string or cookie handling can affect whether an object is stored and how long it remains fresh. A very short freshness period can mean frequent refetches. A long period can be unsuitable for an object that is supposed to change. A cache key that includes a unique viewer token can also reduce sharing between viewers, though removing access-related values without care can expose content that should remain restricted.
Live manifests deserve particular attention. A manifest that points to the newest available segments must not be served stale for longer than your playback design allows. Meanwhile, already completed segments may be immutable and suitable for longer caching if the packaging and URL scheme support that. These are general design choices, not universal settings; check the provider’s documentation and test how your own player responds to freshness and expiry.
What happens on a cache miss
If the edge has no fresh matching copy, it has a cache miss. The CDN then obtains the requested object from an origin, or possibly from an intermediate cache layer, and returns it to the viewer. Depending on the rules, it may also keep the fetched response so a later request can be a hit. The origin could be object storage, a media packaging service, or another HTTP server, but it must be configured to serve the requested paths and respond in a way the CDN can use.
A miss is ordinary, not necessarily a fault. The first request for a new VOD segment is likely to be a miss. A newly created live segment cannot already be cached at the edge before it exists. A request can also miss because an earlier copy expired, the response is not cacheable, or the cache key differs from previous requests. In each case, the origin needs to be available and capable of returning the object in time for playback.
This is why “the CDN has many locations” is not enough to assess a setup. If the origin is slow, unavailable, incorrectly configured or distant from the CDN’s fill path, a miss still has to be resolved. The CDN cannot return a file that the origin does not have, nor can it correct a malformed manifest or produce missing segments. A sensible test includes cold-cache requests, not only repeat plays that happen to use a warm cache.
Also inspect range requests if your delivery workflow uses them. Some players request portions of an object rather than a whole object, and some low-latency workflows request bytes from a segment while it is still being written. That behaviour requires support along the path: the CDN must handle the request pattern, and the origin must be able to return the requested partial content when needed. Google documents open-ended byte-range handling for certain Media CDN streaming patterns, but it should not be treated as a promise that every origin or CDN behaves the same way. See Google’s origin documentation and test the particular combination you plan to use.
Origin shielding and repeated requests
Some CDNs offer an additional cache layer between edge locations and the origin, often described as origin shielding or a shield cache. If several edges need the same object, a shield may allow them to share an intermediate copy rather than each asking the origin separately. Some implementations also collapse simultaneous requests for the same key so that a burst of requests can lead to fewer concurrent origin fetches.
The mechanism is useful to understand when a new segment becomes popular quickly, such as when a live programme begins or a widely shared VOD is played. It may reduce repeated origin work, but it does not make the first fetch disappear. If the object is unique to every request, cannot be cached, or is not yet available, shielding cannot turn it into a reusable fresh object. The details and availability of shielding, request collapsing and cache tiers vary by provider and configuration.
For a small channel owner, shielding is usually one part of a wider capacity and cost question rather than a feature to select in isolation. Ask what happens when many viewers request the same segment at once, how a cache miss travels to the origin, whether cache fills are logged, and what charges apply to origin reads and delivery. Google’s caching behaviour guide explains configurable caching concepts for its own service; other providers use their own terminology and controls.
What a CDN does and does not do by itself
A CDN distributes delivery requests and may cache eligible responses. That can help with repeated delivery, viewer geography and reducing the number of requests reaching an origin. It is not the whole video workflow. You still need a source feed or file, encoding, packaging, a configured origin, player compatibility and a policy for access and freshness.
For VOD, packaging typically happens before playback, so the manifests and segments can be checked before viewers arrive. For live delivery, packaging runs continuously and the manifest changes. The choice of segment duration, rendition ladder and live latency target involves the encoder, packager and player as well as the CDN. Moving requests closer to viewers alone does not create low-latency media or ensure that the player has the next segment in time.
A CDN also does not guarantee that every viewer has the same network conditions or device capability. The player may adapt among available renditions, but that is a decision based on its implementation and what the workflow makes available. The CDN’s role is to deliver the requested objects under configured rules; it does not promise a particular quality level or eliminate buffering.
There is an important scope distinction for YouTube creators. A video CDN used by a website or an OTT player delivers packaged assets to that service’s viewers. If you send a pre-recorded file to YouTube Live, YouTube receives the broadcast feed and handles its own downstream playback delivery. You generally do not insert your own public video CDN between YouTube and viewers of the YouTube live page. The practical issue for a 24/7 channel is often keeping the broadcast source running: using a cloud workflow such as StreamNeo means you can upload the video and provide your YouTube stream key without leaving a home computer encoding overnight. For a local setup, the guide to automating a YouTube live playlist with a VPS in India covers the separate question of operating the feed.
Requirements to check when choosing a video CDN
Start with the workflow, not a provider’s headline description. Write down whether you are delivering VOD, live video or both; which formats your players and devices need; where viewers are; and what the origin will be. Then compare provider documentation and test the route from packaging through playback. Google Cloud distinguishes general web acceleration from Media CDN’s large-scale video focus in its CDN product selection guidance. AWS documents CloudFront delivery patterns for on-demand and live streaming video. These describe supported approaches, not an independent ranking of their performance.
| What to compare | Why it matters | What to verify |
|---|---|---|
| Workload and audience | VOD, live, peak concurrency and viewer geography shape request patterns | Expected sustained and peak traffic, audience regions and whether a public or restricted audience is involved |
| Format and player | A CDN cannot compensate for incompatible packaging | HLS, DASH or CMAF support in the actual players and devices, including captions and any DRM needs |
| Freshness and cache keys | Manifests and segments may need different treatment | How headers, query strings, cookies and path rules affect cacheability and object identity |
| Origin path | A miss still requires an origin response | Origin protocol, location, response headers, range support, access restrictions and failover plan |
| Cache protection | Bursts can create repeated fills | Whether shielding or request collapsing is offered, how it is configured and what logs show |
| Operations and cost | Delivery and misses both have consequences | Available logs and metrics, support, resilience options and charges for cache hits, misses and egress |
Do not assume a provider will support a feature in every product tier or configuration. Confirm the exact service, region, routing design and origin type in current documentation. For live delivery, ask specifically whether the origin can serve content while it is being written if your packaging approach depends on that behaviour. Some storage systems expose an object only after it is complete, which may not fit a workflow expecting partial reads.
Run a test that covers a cold cache and a repeated request, a new live segment, an expired manifest, an origin failure and any access control you intend to use. Check that cache keys do not accidentally split identical public content into needless copies, but also that private content is not shared beyond its intended audience. Review logs to see whether a slow request was served from cache or required a fill, then investigate the origin and packaging path accordingly.
If your audience is inside a company or campus and many employees watch the same event over a constrained internal network, peer delivery may be worth examining as an adjacent design. Microsoft’s eCDN technical overview describes an enterprise peer-to-peer approach that can work alongside HTTP CDNs and existing players. It addresses a particular network pattern; it is not a universal substitute for public CDN delivery.
A 24/7 YouTube channel that plays a file directly to YouTube has a different decision to make from a publisher delivering its own HLS library. If your goal is simply to keep a broadcast feed alive while your computer is off, a public video CDN may not be the missing piece. If you publish your own player and packaged assets, then the origin, packaging, cache policy and viewing geography all belong in the design. The guide to running a 24/7 YouTube stream on JioFiber is relevant when the actual weak point is a home connection rather than a viewer-facing CDN.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does a video CDN encode or package my video?
No. Encoding creates compressed renditions, while packaging creates manifests and segments in formats such as HLS or DASH. The CDN delivers eligible objects from the origin or cache; it does not inherently prepare the video.
What is the difference between a cache hit and a cache miss?
A hit means the edge has a fresh cached object matching the request and can return it without fetching that object from the origin. A miss means the CDN must obtain it from the origin or an intermediate cache, and may store it for later if policy allows.
Does a CDN stop buffering?
No. It can improve delivery for cacheable content and reduce repeated origin work, but playback also depends on the origin, packaging, player, device and viewer’s connection. Neither a CDN nor a cache hit guarantees a particular playback quality.
Do I need a video CDN to stream a file to YouTube Live?
Usually the viewer-facing YouTube delivery path is handled by YouTube, so your own CDN is not normally inserted between YouTube and its viewers. You need a reliable way to send the live feed to YouTube; a CDN matters when you deliver packaged video to your own player or service.