Streaming Platform Products
Virtual & Dedicated Servers Products
Serverless Computing Products
AI & Machine Learning Products
Private and Hybrid Solutions Products
Custom Services Products
Media & Entertainment
IT / Technology
Security & Protection
We’ve implemented a new technology in our Streaming Platform. It is a system providing failsafe transcoding and delivering live streams in the HLS format. The new technology will improve transcoding stability and enhance the delivery of video content to the audiences that exceed 1,000,000 viewers.
In this article we will tell you how this system is going to help our clients improve streaming quality.
The failsafe transcoding and stream delivery system is a cluster composed of transcoding servers managed by a load balancer. The cluster receives the original video stream and returns transcoded adaptive files available via HTTP, i.e., in the HLS or, alternatively, in the MPEG-DASH format.
Major system elements:
The key feature of such a transcoding system is that there is no centralized repository where adaptive files are stored. We distribute the elements while streaming video content, which allows us to:
The absence of a centralized repository can create some additional difficulties (for example, the data may become inconsistent in case the transcoding server changes). But our developers have covered all the details and solved all the problems.
It starts with the load balancer generating the necessary parameters, selecting the most appropriate server from the cluster based on these parameters, and sending a command to the server using a Redis-based messaging server.
The server receives the command and the original stream in the RTMP format (or in any other suitable video transmission format).
The server transcodes the video to the HLS format. The stream involves two file types:
Each chunk has its own unique name connected with the transcoding time. This is necessary in case the transcoding session gets restarted on different servers (for example, this can happen if the load gets redistributed or if a server fails). Unique names make it impossible for different files to overlap, which solves the problem of data consistency.
But the name of the chunk list file must be the same on all servers. Chunk lists are stored separately from the chunks in order to avoid creating several irrelevant files. The folder where they are stored is constantly synchronized with every server, so that each server always has an up-to-date chunk list.
Chunk lists are small files, this is why constant server synchronization does not create any significant network load and doesn’t result in increased delays.
Since all servers have an up-to-date chunk list, there is no need to re-code ready chunks in case the transcoding server is changed. All transcoded pieces will remain in the chunk list and they will be loaded from the previous server.
When transcoded, the stream is transferred to the content delivery network and sent to the users.
All transcoding cluster servers are specified as a content source for the CDN.
As mentioned above, if the transcoding server is changed, there is no need to re-code the chunks because the necessary fragments are downloaded from the previous server. But what if the previous server goes out of order, and all the transcoded fragments become unavailable? In this case, the viewer won’t be able to rewind the video back.
We can solve this problem in two ways.
Way #1: caching ready-made chunks on an intermediate server between the CDN and the transcoding system. In Gcore CDN, it’s the origin shielding that plays the role of such a server. All fragments will invariably be stored in the shielding cache and remain available in case of a failure.
Way #2: creating a pair of servers within a cluster that exchange ready-made chunks. This slightly increases the server load. But if only two servers are involved, the load isn’t going to increase much, while fault tolerance will be achieved.
It’s up to our clients to decide which way to choose. Note that origin shielding is a paid option. But if you broadcast videos to a large audience, opting for the paid variant makes sense because shielding also protects the system against extreme loads.
This technology is now available for all clients of our Streaming Platform by default.
Our platform uses advanced video content delivery technologies. It allows you to easily broadcast your videos in up to 8K quality on all device types with minimal delays and without buffering, even if your audience exceeds 1,000,000 viewers.
Make your video content available to your users in high quality on any device using our Streaming Platform.
We are excited to announce a new Gcore development: our JIT (Just-In-Time) Packager. This solution facilitates simultaneous streaming across six…
In this article, we’ll show you how to integrate video calls into your iOS app in 15 minutes. You don’t have…
This is a step-by-step guide on Gcore’s solution for adding a new VOD feature to your iOS application in 15…