RU2759595C1 - System for fault-tolerant transcoding and output of direct streams in hls format - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to computer technology. The fault-tolerant transcoding system and the issuance of direct streams in the HLS format contains a geographically distributed network infrastructure (CDN) for the issuance of chunklists and chunks of video produced by transcoding servers, and when requesting chunklists and chunks of video from the CDN, the CDN, due to a predefined configuration, performs an alternate search for chunklists and chunks of video on each of the cluster servers; load balancer for generating and sending commands to transcoding servers; a cluster of video transcoding servers under the unified control of the load balancer and made with the ability to: create chunklists and chunks of video; synchronization of chunks with each other through a distributed file system, moreover: video chunks are not synchronized between servers, but are located only on the server on which they are created, while by means of intermediate servers between the CDN and the transcoding cluster, all new chunks from the chunklist are forcibly and preemptively cached, and by means of the transcoder, when the transcoding server is changed, the existing file, the chunklist is read.

EFFECT: increasing the fault tolerance of video transcoding.

1 cl, 2 dwg

Description

FIELD OF TECHNOLOGY

This technical solution relates to the field of computer technology, in particular to systems of fault-tolerant transcoding and delivery of direct streams in the HLS format.

LEVEL OF TECHNOLOGY

From the prior art, a solution is known that is selected as the closest analogue, US 2012254456 A1, 04.10.2012. This solution relates to the field of computing, namely to a method and apparatus for creating universal streams with adaptive bit rate using a universal container format for storing audio, video and additional data that provide transcoding from one adaptive streaming format to another.

However, it should be noted that the prior art does not disclose information on ensuring high resiliency of transcoding.

The proposed technical solution is aimed at eliminating the shortcomings of the state of the art and differs from the known solutions in that the proposed system does not contain a centralized storage of transcoded video, thereby significantly reducing the load on the network, speeding up delivery, simplifying interconnections and eliminating an additional point of failure in the form of storage.

SUMMARY OF THE INVENTION

The technical problem to be solved by the claimed solution is the creation of a fault-tolerant transcoding system and the issuance of direct streams in the HLS format.

The technical result consists in increasing the fault tolerance of video transcoding.

The stated result is achieved by implementing a fault-tolerant transcoding system and issuing direct streams in the HLS format, which contains:

geographically distributed network infrastructure (CDN), capable of issuing chunklists and video chunks produced by transcoding servers, and when requesting chunklists and video chunks from a CDN, the CDN, due to a predetermined configuration, alternately searches for chunklists and video chunks on each of the cluster servers;

a load balancer that is configured to generate and send commands to transcoding servers;

a cluster of video transcoding servers, under the unified control of the load balancer and made with the ability to:

creating chunklists and video chunks;

synchronization of chunklists with each other via the network file system, moreover:

video chunks are not synchronized between servers, but are located only on the server on which they are created;

video chunks are uniquely numbered;

when playing a video, the chunklist is downloaded from any server, and to receive a video chunk, it is searched for on one of the servers.

DESCRIPTION OF DRAWINGS

The implementation of the invention will be described in the following in accordance with the accompanying drawings, which are presented to explain the essence of the invention and in no way limit the scope of the invention. The following drawings are attached to the application:

FIG. 1 illustrates the general scheme of the system operation.

2 illustrates a diagram of a computing device.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of an implementation of the invention, numerous implementation details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art how the present invention can be used, with or without these implementation details. In other instances, well-known techniques, procedures, and components have not been described in detail so as not to obscure the details of the present invention.

In addition, it will be clear from the above description that the invention is not limited to the above implementation. Numerous possible modifications, changes, variations and substitutions, while retaining the spirit and form of the present invention, will be apparent to those skilled in the art.

Key terms.

HTTP (English HyperText Transfer Protocol - "Hypertext Transfer Protocol") - the protocol of the application layer of data transfer initially - in the form of hypertext documents in the "HTML" format, currently used to transfer arbitrary data. HTTP is based on the "client-server" technology, that is, it is assumed that:

• Consumers (clients) who initiate the connection and send the request;

• Providers (servers) that are waiting for a connection to receive a request, take the necessary actions and return a message with the result.

HLS (HTTP Live Streaming) is an HTTP-based media streaming communication protocol developed by Apple as part of QuickTime, Safari, OS X and iOS software. The work is based on the principle of dividing a whole stream into small fragments that are sequentially downloaded via HTTP. The stream is continuous and theoretically could be infinite. At the beginning of the session, a playlist in M3U format is downloaded, containing metadata about the available sub-streams.

MPEG-DASH (from MPEG and English Dynamic Adaptive Streaming over HTTP) is an adaptive streaming technology that provides the ability to deliver streaming multimedia content over the Internet using the HTTP protocol. It is the first adaptive bitrate streaming solution to achieve international standard status.

Chunklist - a constantly updated list of generated chunk names.

Chunkivideo - pieces of video from 2 to 5 seconds long.

CDN - Content Delivery Network or Content Distribution Network (CDN) is a geographically distributed network infrastructure that optimizes the delivery and distribution of content to end users on the Internet. The use of CDN by content providers contributes to an increase in the download speed of audio, video, software, game and other types of digital content by Internet users at the points of presence of the CDN network.

Transcoding - converting a file from one encoding method (i.e. file format) to another.

Shielding is a situation when an additional server is located between the CDN servers and the "original" server, through which traffic passes. Thus, requests for the "original" server come from only one server, and not from multiple servers, which is easier for the client to manage and greatly reduces the load on his servers.

The proposed technical solution carries out its work autonomously, without the need to organize a centralized storage for video. Usually, transcoding systems upload the created video to some server, which is already responsible for fault tolerance. In the proposed system, all servers can both transcode video and can be sources of transcoded video.

The system is a cluster of video transcoding servers under a single load balancer control. At the input, the system receives the original video stream, and at the output it provides a transcoded adaptive stream available over HTTP (HLS, it is also possible to output in MPEG-DASH).

The main problem that appears when a single video storage is excluded from the system is to ensure the consistency and unambiguity of data when the current transcoding server is changed. The proposed technical solution uses a number of techniques to solve this problem.

Brief description of the data consistency problem

In the absence of a unified storage of video files, the user will need to search for files for a specific video stream on each of the transcoding servers. However, if the transcoding session is restarted on different servers in the cluster (due to server failure or load rebalancing, or for other reasons), then as a result, different files with the same name are obtained to access the stream on different servers. The problem could be partially solved by full synchronization of all files between the cluster servers, however, this will lead to an increase in traffic between servers, an increase in the required storage on each of the transcoders, an increase in the load on disks and, as a result, an increase in latency during video transcoding.

The proposed system makes it possible to solve the indicated problem practically without any additional increase in the load.

The system includes:

• Several (at least three) equivalent transcoding servers.

• Management system-load balancer.

• CDN for delivery of files produced by transcoding servers.

All transcoder servers create chunklists and video chunks.

Servers synchronize the chunklist with each other via the network file system.

Chunks of videos are not synchronized between servers, but are located only on the server on which they are created, so as not to create network traffic

Chunks of videos are numbered uniquely. This avoids problems when restarting transcoding on another server.

When watching a video, the chunklist is downloaded from any server, and to receive a video chunk, it is searched for on one of the servers

The CDN configuration is responsible for searching for chunklists and video chunks on servers.

All video delivery using the HLS protocol is a periodic update of the chunklist (a list of links to current video chunks) and a request for video chunks (video fragments) using links from this chunklist.

The user makes a request for chunklists and video chunks from the CDN, and the CDN searches for these files one by one on each of the cluster servers. The chunklists will be found on any of the servers, since the chunklist is constantly synchronized between the servers, and the video chunk is only on one of them (because it exists only where it was created).

Receiving the output transcoded stream from the input one using the HLS technology is as follows:

• The transcoding process starts on the transcoding server.

• Receive the original stream from the signal source server and transforms it.

• The transcoded stream is fragmented into small parts, most often 2 to 5 seconds long, and added to a periodically updated chunklist (a list of links to such fragments). This method is convenient for distributing video using the popular HTTP protocol, since the entire video stream is a set of final video files.

The principle of the system.

The load balancer generates and sends a command to the transcoding server. Formation and sending of a command is carried out as follows:

1. Based on the desired parameters specified by the user (output video resolution, bit rate, number of frames per second, etc.), a video transcoding command is formed;

2. Based on the current balancing algorithm (for example, Round-Robin, when one of the servers is randomly selected, or the server with the least CPU load), the balancer selects the most suitable server from the transcoding cluster;

3. The balancer sends a transcoding command to the selected server through the Redis-based messaging server.

After receiving the command, the transcoding server receives the original stream (via the RTMP protocol or any other suitable for video transmission) and starts transcoding according to the received parameters into the HLS format. This format represents a transcoded video stream in the form of files of the following type:

• Chunks of video - pieces of video approximately 2 to 5 seconds long.

• Chunklists - constantly updated list of generated video chunk names.

When playing a video, the user constantly re-requests the chunklist for a certain unchangeable and known in advance URL, receives from it a list of URLs of current chunks, and then requests the required video chunks for playback.

Within the framework of the proposed system, video chunks have a strictly unique name tied to the start time of transcoding, for example 2019010101124501.ts, thus, the file names fundamentally cannot overlap if the transcoding session is restarted on different servers.

However, the chunklist file name must be the same on all servers, since this name is predefined and explicitly indicated to users when accessing the stream, for example streams / 123 / 480p / index.m3u8. If a transcoding session is launched on different servers, this will lead to the presence of one or several irrelevant files on different servers, and the user will not be able to unambiguously determine which of the files he needs to watch at the moment.

The proposed system solves this problem by storing chunklist files separately from chunks. In this case, the folder with chunklists is constantly synchronized between servers using any distributed file system (in this particular case, GlusterFS is used).

Chunklists are small files, but they are updated very often (once every 1-2 seconds). A distributed file system can easily and quickly synchronize these files between servers with minimal network and disk load on each server.

Thus, on each server we get an identical chunklist file and many files with video chunks that have a unique name and therefore have no problems with consistency.

Setting up a CDN for watching videos.

The user accesses the video stream via the CDN. By default, the G-Core CDN is used to distribute video streams. It is a classic CDN (Content Delivery Network) designed to deliver traffic to a wide audience using a network of geo-distributed servers. Network servers collect video traffic from source servers, cache them and distribute them to end users. Using the G-Core CDN settings, it becomes possible to specify in its settings the possibility of using all servers of the video transcoding cluster as a source of files. With each request for any file, the CDN looks for it on any of the cluster servers (going through the entire list in turn, randomly determined each time to balance the load, until it finds the required file).

In the proposed system, CDN works as follows:

• When searching for a chunklist - the first found chunklist is used, since all chunklists are synchronized between servers.

• When searching for a video chunk - a search is carried out across all servers, due to the uniqueness of the name.

Ultimately, the CDN searches for all the files the user needs to view the video stream. The viewer will not know about the device of the video transcoding cluster, but will only use external links to the CDN.

Procedure when changing the transcoding server.

If the current transcoding server is changed, the transcoder does not start the process anew, but reads the chunklist file it already has. Thus, all links to previous video chunks will remain in the chunklist and the viewer will not feel any difference in the chunklist after changing the server. The viewer will be able to rewind the video for the moment both before and after the switch, and the video chunks will be downloaded both from the previous and from the new server in this case.

Limited fault tolerance in the event of a failure of one of the cluster servers.

Since the chunks from the video are not replicated in any way, the failure of the current transcoding server will lead to the fact that after restarting the transcoding process on the new server, the old chunks will not be available, and rewinding will not work for the viewer.

To solve this problem, intermediate servers are used between the CDN and the transcoding cluster, which will force and proactively cache all new chunks from the chunklist. Within the framework of the G-Core CDN infrastructure, this is implemented using a shielding service. Shielding allows you to reduce the load on the video traffic source servers by using intermediate caching servers.

The second available technology for solving this problem with minimal costs is the creation of pairs of servers within the considered cluster, within which they will exchange chunks with video. If chunks were exchanged between all servers in the cluster, the load on the network and disks would be N * M, where N is the number of servers, and M is the number of threads. If the servers are combined in pairs, the load will be 2 * M, which is quite acceptable for most cases.

Using the proposed system for Low-Latency streaming.

The proposed system is suitable for low latency HTTP video delivery.

Various currently available Low-Latency streaming techniques suggest that the system can update chunklists frequently and quickly, and provide access to chunks as quickly as possible after they are created.

Since the proposed system does not have any synchronous interactions, in addition to the fast synchronization of small chunklists, this allows you to get access to the created chunks and chunklists as quickly as possible.

FIG. 2 shows a general diagram of a computing device (200), which is configured to provide data processing necessary to implement the claimed solution, and a server can act as a computing device.

In the general case, the device (200) contains such components as: one or more processors (201), at least one memory (202), data storage means (203), input / output interfaces (204), I / O means ( 205), networking tools (206).

The processor (201) of the device performs the basic computational operations necessary for the operation of the device (200) or the functionality of one or more of its components. The processor (201) executes the necessary computer readable instructions contained in the main memory (202).

Memory (202), as a rule, is made in the form of RAM and contains the necessary program logic that provides the required functionality.

The data storage medium (203) can be performed in the form of HDD, SSD disks, raid array, network storage, flash memory, optical information storage devices (CD, DVD, MD, Blue-Ray disks), etc. The means (203) allows performing long-term storage of various types of information, for example, the aforementioned files with user data sets, a database containing records of time intervals measured for each user, user identifiers, etc.

Interfaces (204) are standard means for connecting and working with the server side, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS / 2, Lightning, FireWire, etc.

The choice of interfaces (204) depends on the specific implementation of the device (200), which can be a personal computer, mainframe, server cluster, thin client, smartphone, laptop, etc.

As means of I / O data (205) in any embodiment of a system that implements the described method, a keyboard should be used. The hardware design of the keyboard can be any known: it can be either a built-in keyboard used on a laptop or netbook, or a stand-alone device connected to a desktop computer, server or other computer device. In this case, the connection can be either wired, in which the connecting cable of the keyboard is connected to the PS / 2 or USB port located on the system unit of the desktop computer, or wireless, in which the keyboard exchanges data via a wireless communication channel, for example, a radio channel, with base station, which, in turn, is directly connected to the system unit, for example, to one of the USB ports. In addition to the keyboard, I / O data can also include: joystick, display (touch screen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.

Networking means (206) are selected from a device that provides network reception and transmission of data, for example, Ethernet card, WLAN / Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc. The means (205) provide the organization of data exchange via a wired or wireless data transmission channel, for example, WAN, PAN, LAN, Intranet, Internet, WLAN, WMAN or GSM.

The components of the device (200) are interfaced through a common data bus (210).

In the present application materials, a preferred disclosure of the implementation of the claimed technical solution was presented, which should not be used as limiting other, particular embodiments of its implementation, which do not go beyond the scope of the claimed scope of legal protection and are obvious to specialists in the relevant field of technology.

Claims (11)

A system of fault-tolerant transcoding and delivery of direct streams in HLS format, containing: geographically distributed network infrastructure (CDN), capable of issuing chunklists and video chunks produced by transcoding servers, and when requesting chunklists and video chunks from a CDN, the CDN, due to a predetermined configuration, alternately searches for chunklists and video chunks on each of the cluster servers; a load balancer that is configured to generate and send commands to transcoding servers; a cluster of video transcoding servers, under the unified control of the load balancer and made with the ability to: creating chunklists and video chunks; synchronization of chunklists with each other via a distributed file system, moreover: video chunks are not synchronized between servers, but are located only on the server on which they are created; video chunks are uniquely numbered; when playing a video, the chunklist is downloaded from any server, and to receive a video chunk, it is searched for on one of the servers, at the same time, by means of intermediate servers between the CDN and the transcoding cluster, forced and proactive caching of all new chunks from the chunklist is carried out, and by means of the transcoder, when the transcoding server is changed, the chunklist file that it has is read.

Images