Using a CDN for live streaming helps speed up content delivery and reduce delays when viewers are far from the source server. In this case, the content will be streamed from the nearest cache server.
For online streaming via a CDN, we use the HLS (HTTP Live Streaming) protocol. Here’s how it works: Streams are divided into playlists (.m3u8) and chunks (video fragments inside playlists with the .ts extension) that are sequentially downloaded via HTTP.
This is how live broadcasts differ from other static content distributed through a CDN (images, scripts, or videos).
Therefore, the task arises to ensure uninterrupted delivery, as even minimal delays and buffering at the climax of the broadcast (for example, at the moment of a goal scored) can significantly reduce viewers’ satisfaction. Most likely, a user who noticed the freezes will go looking for another resource with the same content, rather than waiting for the broadcast to resume.
To minimize latency and eliminate buffering, we’ve optimized our CDN and made it easier for our customers to configure live streams.
The standard caching mechanism in a CDN assumes that content for distribution to end users is stored on the hard drives on cache servers.
In the case of live broadcasts, this is not ideal, as it takes time to render content from drives, meaning additional delays.
That’s why we cache live streams in the RAM. This way they are delivered faster from the source server to end users. To do so, simply enable the “Live Streaming” preset in the CDN control panel on the resource used for broadcasting.
A preset is a predefined set of settings that is applied to a resource and can’t be changed. A preset is always associated with a specific resource.
For more information about caching files through RAM, see the knowledge base article “HLS (HTTP Live Streaming)”.
The HLS protocol means that you should specify the time of caching for playlists and chunks.
Playlists. We recommend caching playlists for 1–2 seconds, so that when requested, the viewer doesn’t receive an outdated playlist with irrelevant chunks from the cache.
Chunks. It is best to cache chunks for a time slightly longer than the chunk itself. We recommend 1 minute. This time is longer than the lifetime of the playlist, because the viewer may have a slow internet connection. This means, that when the viewer is watching a specific fragment of the .ts file, a playlist with other .ts files may already be given at the source. It’s important to give such a viewer the correct chunk from the cache, because the source of this particular chunk may no longer exist.
This is where our templates help.
A template is a set of ready-made settings that can be instantly applied to a CDN resource.
You can either use ready-made system templates or create your own to quickly set up rules for CDN resources.
Ready-made rule templates allow you to create a rule with recommended settings for playlists and chunks in just a couple of clicks. When creating a rule using this template, you can change the settings.
Rule templates are already available for setting up streaming via CDN:
Read more about templates in the knowledge base article: “Rule templates”.
Broadcast live streams with minimal latency and no buffering with G-Core Labs CDN.
Or sign up for Streaming Platform and enjoy the full streaming feature set.