Streaming - Video CDN [EN]
Video CDN supports MPEG-DASH and HLS protocols. When a video file is uploaded to a storage, CDN on the fly creates a sequential playlist of small video segments, to make your content seamlessly available in the highest possible quality across devices, via most browsers and firewalls, at almost any connection speed.
See also
Built-in url parametrization system
The concept of featuring, which does not require explicit configuration
Url parameter is used for getting manifests of streaming protocols
In the HLS protocol, the main idea is to break a video into small pieces (segments) and serve them over HTTP. Each segment is a separate .ts (Transport Stream) file. The full video (or live stream) is encoded and cut into short fragments, usually 2–10 seconds long. HLS uses playlists (manifests) in the .m3u8 format. These are text files that describe which segments to load and in what order.
Dynamic segment sizing is not supported due to technical limitations.
With DASH protocol, content is served in segments in *.m4s format. Media Presentation Description manifest (*.mpd) specifies the structure of the streams, available video and audio options, and segment access rules. The transmission is carried out over HTTP, which allows for the effective use of existing delivery infrastructure, including caching and CDN.
Due to architectural implementation, in some cases streaming manifests (.m3u8 and *.mpd) may be distributed from edge nodes. In such a case the redirector returns 302 Found instead of 200 OK.
Segments caching at redirectors
Someone might point out that redirection takes time. That’s fair. Every decision has a price.
To makie this price lower, we introduced additional caching functionality at redirectors. It is possible to cache certain important data at redirectors, if it is not too large.
Streaming protocols like HLS and DASH are designed to divide video files into small, sequential segments. This structure enables more efficient request handling and faster playback start times, without introducing extra layers of complexity.
Thanks to this segmented approach, redirectors can cache the manifest and the first two chunks of content. Typically, that’s enough for the browser to begin playback almost instantly. While the video starts playing, the media player seamlessly switches to edge nodes to fetch the remaining segments. This hybrid delivery flow minimizes latency and improves the user experience.
Here’s how it works with HLS (as an example):
No additional setup is required to take advantage of this feature. It works automatically as part of the CDN’s standard streaming architecture.
Repackaging
In most cases, the files you work with (such as MP4 or MKV) are not the formats that modern streaming protocols expect. Streaming delivery relies on segmented containers in TS or M4S formats. This means that before content can be streamed, it usually needs to be repackaged into a container designed for efficient segment-based delivery.
With our platform, this process happens automatically. There is no need for manual preprocessing or additional tooling. Video CDN repackages your files in real time, providing a stream-ready set of segments on the fly. You just need to get a streaming manifest, and the system will generate the list of hyperlinks for downloading segments.
Repackaging ≠ Transcoding. Whereas transcoding involves re-encoding the audio or video streams themselves (e.g., converting H.264 to H.265), repackaging simply changes the container format. The original streams remain intact, so there is no loss of quality or alteration of the media itself. Only the “wrapping” is adapted for delivery.
Video CDN does not support video transcoding! This is a resource-bound process with its own options and additional complexity.
The internal structure of file formats explains video repackaging better.
Analyzing the format allows you to distinguish between the raw media data, which is transferred as-is; the metadata, which may be transformed during processing, and the format-specific syntactic elements required by each individual file type.
MP4 (MPEG-4 Part 14)
The MP4 format is based on the ISO Base Media File Format and is organized as a hierarchy of blocks (boxes/atoms). Each block contains a header with type and size and may include other nested blocks that describe metadata, track structure, and media data location. This structure allows the player to quickly determine the number of tracks with their parameters and find the corresponding fragments in the mdat block.
The simplified structure of an MP4 file looks like this:
MKV (Matroska)
Matroska Video (.mkv) is an open multimedia container format built on EBML (Extensible Binary Meta Language). EBML is a binary analogue of XML, where each element has an identifier (ID), length (Size), and content (Data).
Repackaging of MKV files is an experimental feature. There are no guarantees that it will work in 100% of cases.
The simplified structure of an MKV file looks like this:
TS (Transport Stream)
“TS format” refers to the MPEG Transport Stream (MPEG-2 TS), a standard digital container format for transmitting and storing audio, video, and data, often found in broadcast systems like DVB and IPTV. It breaks streams into small, fixed-size packets with synchronization markers, making it robust for real-time delivery over unreliable media, while also being used on DVDs and for streaming.
The simplified structure of a TS file looks like this:
M4S (MPEG-4 Streaming)
An M4S file is a video segment from an MPEG-DASH (Dynamic Adaptive Streaming over HTTP) stream, essentially a chunk of a larger MP4 (MPEG-4 Part 14) file designed for efficient streaming over the internet. These small segments allow media players to begin playback while the full file is still downloading, rather than requiring the entire file to be downloaded first.