WO2022066066A1 - Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls - Google Patents

Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls Download PDF

Info

Publication number
WO2022066066A1
WO2022066066A1 PCT/RU2021/050397 RU2021050397W WO2022066066A1 WO 2022066066 A1 WO2022066066 A1 WO 2022066066A1 RU 2021050397 W RU2021050397 W RU 2021050397W WO 2022066066 A1 WO2022066066 A1 WO 2022066066A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
servers
transcoding
chunks
cdn
Prior art date
Application number
PCT/RU2021/050397
Other languages
English (en)
French (fr)
Inventor
Григорий Петрович ДМИТРЕНКО
Original Assignee
Общество С Ограниченной Ответственностью "Джи-Кор Рус"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Общество С Ограниченной Ответственностью "Джи-Кор Рус" filed Critical Общество С Ограниченной Ответственностью "Джи-Кор Рус"
Publication of WO2022066066A1 publication Critical patent/WO2022066066A1/ru

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]

Definitions

  • the present technical solution relates to the field of computer technology, in particular, to systems for fault-tolerant transcoding and issuance of direct streams in the HLS format.
  • 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.
  • the technical problem to be solved by the claimed solution is the creation of a system of fault-tolerant transcoding and issuance of direct streams in the HLS format.
  • the technical result is to increase the fault tolerance of video transcoding.
  • the claimed result is achieved through the implementation of a fault-tolerant transcoding system and the issuance of direct streams in the HLS format, which contains: a geographically distributed network infrastructure (CDN) configured to issue chunklists and video chunks produced by transcoding servers, and when requesting chunklists and video chunks from CDN , CDN, due to a predetermined configuration, searches in turn for chunklists and video chunks on each of the cluster servers; a load balancer that is configured to generate and send commands to the transcoding servers; a cluster of video transcoding servers, which is under the unified control of a load balancer and is configured to: create chunklists and video chunks; synchronization of chunklists with each other via a 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 have a unique numbering; when playing a video, the chunklist is downloaded from any server, and to get a chunk of video, it is searched for on one of the servers.
  • CDN geographically
  • Fig. 1 illustrates the general scheme of the system operation.
  • FIG. 2 illustrates a diagram of a computing device.
  • HTTP HyperText Transfer Protocol - “hypertext transfer protocol”
  • HTTP HyperText Transfer Protocol
  • HTTP HyperText Transfer Protocol
  • client-server technology
  • HLS HTTP Live Streaming
  • M3U M3U format
  • MPEG-DASH from MPEG and English Dynamic Adaptive Streaming over HTTP
  • MPEG-DASH 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.
  • Chunkyvideos are pieces of video that are 2 to 5 seconds long.
  • CDN content delivery (and distribution) network (English Content Delivery Network or Content Distribution Network, CDN) - a geographically distributed network infrastructure that allows you to optimize the delivery and distribution of content to end users on the Internet.
  • CDN content delivery (and distribution) network
  • CDN International Content Delivery Network or Content Distribution Network
  • Shielding is a situation when there is an additional server between the CDN servers and the "original" server through which traffic passes.
  • requests to the "original” server come from only one server, and not from many servers, which is easier to manage for the client and greatly reduces the load on its servers.
  • the proposed technical solution performs its work autonomously, without the need to organize a centralized storage for video.
  • transcoding systems upload the created video to some server that is already responsible for failover.
  • all servers can both transcode video and can be sources of transcoded video.
  • the system is a cluster of video transcoding servers under the unified control of a load balancer. At the input, the system receives the initial video stream, and at the output it provides a transcoded adaptive stream available via HTTP (HLS, output to MPEG-DASH is also possible).
  • HTTP HyperText Transfer Protocol
  • the main problem that arises when a single video storage is excluded from the system is to ensure the consistency and unambiguity of data when the current transcoding server changes.
  • the proposed technical solution uses a number of techniques to solve this problem.
  • the proposed system allows to solve this problem practically without any additional increase in load.
  • the system includes:
  • All transcoder servers create chunklists and video chunks.
  • Servers synchronize the chunklist with each other via the network file system.
  • Video chunks are not synchronized between servers, but are located only on the server on which they are created, so as not to create network traffic
  • Video chunks have a unique numbering. This avoids problems when restarting transcoding on another server.
  • the chunklist is downloaded from any server, and to get a chunk of video, 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 (the list of links to actual video chunks) and a request for video chunks (video fragments) using links from this chunklist.
  • Chunklists will be found on any of the servers, since the chunklist is constantly synchronized between servers, and the video chunk is only on one of them (because it is only there where it was created). Obtaining the output transcoded stream from the input using HLS technology is as follows:
  • the transcoded stream is fragmented into small parts, most often lasting from 2 to 5 seconds, and added to a periodically updated chanklist (list of links to such fragments).
  • This method is convenient for distributing video using the common HTTP protocol, since the entire video stream is a set of end video files.
  • the load balancer generates and sends a command to the transcoding server.
  • the formation and sending of the command is carried out as follows:
  • a video transcoding command is formed
  • the balancer selects the most suitable server from the transcoding cluster;
  • the load balancer sends a transcode command to the selected server via a Redis-based messaging server.
  • the transcoding server After receiving the command, the transcoding server receives the original stream (via RTMP protocol or any other suitable video transmission) and starts transcoding according to the received parameters into the HLS format.
  • This format represents the transcoded video stream in the form of files of the following form:
  • Video chunks are video chunks that are approximately 2 to 5 seconds long.
  • Chunklists a constantly updated list of generated video chunk names.
  • the user When playing a video, the user constantly re-requests the chunklist at a certain unchanging and known URL in advance, receives from it a list of URLs of actual chunks, and then requests the required video chunks for playback.
  • video chunks have a strictly unique name tied to the start time of transcoding, for example 2019010101124501.ts, thus, file names cannot fundamentally overlap if the transcoding session is restarted on different servers.
  • the name of the chanklist file must be the same on all servers, since this name is predefined and explicitly specified to users when accessing the stream, for example streams/123/480p/index.m3u8. If the transcoding session is run on different servers, this will result in one or more outdated files on different servers, and the user will not be able to unambiguously determine which file he needs to watch at the moment.
  • this problem is solved by storing the chunklist files separately from the chunks.
  • the folder with chanklists is constantly synchronized between servers using any distributed file system (in a specific case, GlusterFS is used).
  • Chunklists are small files, but they are updated very often (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.
  • G-Core CDN is used to distribute video streams.
  • This is a classic CDN (Content Delivery Network) designed to deliver traffic to a wide audience using a network of geo-distributed servers.
  • the network servers take video traffic from the source servers, cache it and distribute it to end users.
  • G-Core CDN configuration options it becomes possible to specify in its settings the possibility of using all servers of the video transcoding cluster as a file source. With each request for any file, CDN looks for it on any of the servers in the cluster (traversing the entire list in turn, determined each time randomly for load balancing, until it finds the desired file).
  • CDN works as follows:
  • 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.
  • the transcoder does not start the process again, but reads the chanklist 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 at the moment both before and after the switch, and video chunks will be downloaded both from the previous and from the new server in this case.
  • intermediate servers are used between the CDN and the transcoding cluster, which will force and proactively cache all new chunks from the chunklist.
  • this is implemented using the shielding service. Shielding allows you to reduce the load on the video traffic source servers using intermediate caching servers.
  • the second available technology for solving this problem with minimal cost is the creation of pairs of servers within the considered cluster, within which they will exchange video chunks. If chunks were exchanged between all cluster servers, 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 paired, the load will be 2 * M, which is quite acceptable for most cases.
  • the proposed system is suitable for delivering video over HTTP with low latency.
  • FIG. 2 shows a general diagram of a computing device (200), which is configured to provide the data processing necessary to implement the claimed solution, and a server can act as a computing device.
  • the device (200) contains such components as: one or more processors (201), at least one memory (202), a data storage medium (203), input/output interfaces (204), an I/O means ( 205), networking tools (206).
  • processors 201
  • memory 202
  • data storage medium 203
  • input/output interfaces 204
  • I/O means 205
  • networking tools 206
  • the processor (201) of the device performs the basic computing operations necessary for the operation of the device (200) or the functionality of one or more than its components.
  • the processor (201) executes the necessary machine-readable instructions contained in the main memory (202).
  • the memory (202) is typically in the form of RAM and contains the necessary software logic to provide the desired functionality.
  • the data storage means (203) can be 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 long-term storage of various types of information, for example, the above-mentioned 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 part, for example, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire, etc.
  • interfaces (204) depends on the specific implementation of the device (200), which can be a personal computer, mainframe, server cluster, thin client, smartphone, laptop, and the like.
  • the keyboard must be used.
  • the keyboard hardware can be any known: it can be either a built-in keyboard used on a laptop or netbook, or a separate device connected to a desktop computer, server, or other computer device.
  • the connection can be either wired, in which the keyboard connection cable 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.
  • the following I/O devices can also be used: joystick, display (touchscreen), projector, touchpad, mouse, trackball, light pen, speakers, microphone, etc.
  • Means of network interaction (206) are selected from a device that provides network reception and transmission of data, for example, an Ethernet card, WLAN/Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc.
  • a device that provides network reception and transmission of data for example, an Ethernet card, WLAN/Wi-Fi module, Bluetooth module, BLE module, NFC module, IrDa, RFID module, GSM modem, etc.
  • the organization of data exchange over a wired or wireless data transmission channel for example, WAN, PAN, LAN (LAN), Intranet, Internet, WLAN, WMAN or GSM.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Техническое решение относится к области вычислительной техники. Технический результат заключается в повышении отказоустойчивости транскодирования видео. Система отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS содержит: географически распределённую сетевую инфраструктуру (CDN), выполненную с возможностью выдачи чанклистов и чанки видео, производимых серверами транскодирования, причем при запросе чанклистов и чанки видео с CDN, CDN за счет заранее заданной конфигурации осуществляет поочередный поиск чанклистов и чанки видео на каждом из серверов кластера; балансировщик нагрузки, который выполнен с возможностью формирования и отправки команд серверам транскодирования; кластер серверов транскодирования видео, находящийся под единым управлением балансировщика нагрузки и выполненный с возможностью: создания чанклистов и чанки видео; синхронизации чанклистов друг с другом через сетевую файловую систему, причем: чанки видео не синхронизируются между серверами, а находятся только на том сервере, на котором создаются; чанки видео имеют уникальную нумерацию; при воспроизведении видео чанклист скачивается с любого сервера, а для получения чанка видео осуществляется его поиск на одном из серверов.

Description

СИСТЕМА ОТКАЗОУСТОЙЧИВОГО ТРАНСКОДИРОВАНИЯ И ВЫДАЧИ ПРЯМЫХ ПОТОКОВ В ФОРМАТЕ HLS
ОБЛАСТЬ ТЕХНИКИ
Настоящее техническое решение относится к области вычислительной техники, в частности, к системам отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS.
УРОВЕНЬ ТЕХНИКИ
Из уровня техники известно решение, выбранное в качестве наиболее близкого аналога, US 2012254456 А1 , 04.10.2012. Данное решение относится к области вычислительной техники, а именно к способу и устройству для создания универсальных потоков с адаптивной скоростью передачи битов с использованием универсального формата контейнера для хранения аудио, видео и дополнительных данных, которые обеспечивают транскодинг из одного адаптивного потокового формата в другой.
Однако стоит отметить, что в известном уровне техники, не раскрыта информация об обеспечении высокой отказоустойчивости транскодирования.
Предлагаемое техническое решение направлено на устранение недостатков современного уровня техники и отличается от известных решений тем, что предложенная система не содержит централизованное хранилище транскодированного видео, тем самым значительно снижая нагрузку на сеть, ускоряя доставку, упрощая взаимосвязи и исключая дополнительную точку отказа в виде хранилища.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
Технической проблемой, на решение которой направлено заявленное решение, является создание системы отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS.
Технический результат заключается в повышении отказоустойчивости транскодирования видео.
Заявленный результат достигается за счет осуществления системы отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS, которая содержит: географически распределённую сетевую инфраструктуру (CDN), выполненную с возможностью выдачи чанклистов и чанки видео, производимых серверами транскодирования, причем при запросе чанклистов и чанки видео с CDN, CDN за счет заранее заданной конфигурации осуществляет поочередный поиск чанклистов и чанки видео на каждом из серверов кластера; балансировщик нагрузки, который выполнен с возможностью формирования и отправки команд серверам транскодирования; кластер серверов транскодирования видео, находящийся под единым управлением балансировщика нагрузки и выполненный с возможностью: создания чанклистов и чанки видео; синхронизации чанклистов друг с другом через сетевую файловую систему, причем: чанки видео не синхронизируются между серверами, а находятся только на том сервере, на котором создаются; чанки видео имеют уникальную нумерацию; при воспроизведении видео чанклист скачивается с любого сервера, а для получения чанка видео осуществляется его поиск на одном из серверов.
ОПИСАНИЕ ЧЕРТЕЖЕЙ
Реализация изобретения будет описана в дальнейшем в соответствии с прилагаемыми чертежами, которые представлены для пояснения сути изобретения и никоим образом не ограничивают область изобретения. К заявке прилагаются следующие чертежи:
Фиг. 1 , иллюстрирует общую схему работы системы.
Фиг.2, иллюстрирует схему вычислительного устройства.
ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
В приведенном ниже подробном описании реализации изобретения приведены многочисленные детали реализации, призванные обеспечить отчетливое понимание настоящего изобретения. Однако, квалифицированному в предметной области специалисту, будет очевидно каким образом можно использовать настоящее изобретение, как с данными деталями реализации, так и без них. В других случаях хорошо известные методы, процедуры и компоненты не были описаны подробно, чтобы не затруднять излишне понимание особенностей настоящего изобретения.
Кроме того, из приведенного изложения будет ясно, что изобретение не ограничивается приведенной реализацией. Многочисленные возможные модификации, изменения, вариации и замены, сохраняющие суть и форму настоящего изобретения, будут очевидными для квалифицированных в предметной области специалистов.
Ключевые термины.
HTTP (англ. HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных изначально — в виде гипертекстовых документов в формате «HTML», в настоящий момент используется для передачи произвольных данных. Основой HTTP является технология «клиент-сервер», то есть предполагается существование:
• Потребителей (клиентов), которые инициируют соединение и посылают запрос; • Поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HLS (HTTP Live Streaming) — коммуникационный протокол для потоковой передачи медиа на основе HTTP, разработанный компанией Apple как часть программного обеспечения QuickTime, Safari, OS X и iOS. В основе работы лежит принцип разделения цельного потока на небольшие фрагменты, последовательно скачиваемые по HTTP. Поток непрерывен и теоретически может быть бесконечным. В начале сессии скачивается плейлист в формате M3U, содержащий метаданные об имеющихся вложенных потоках.
MPEG-DASH (от MPEG и англ. Dynamic Adaptive Streaming over HTTP) — технология адаптивной потоковой передачи данных, предоставляющая возможность доставки потокового мультимедиа-контента через Интернет по протоколу HTTP. Является первым решением по потоковой передаче данных с адаптивным битрейтом, получившим статус международного стандарта.
Чанклист - постоянно обновляемый список имен генерируемых чанков.
Чанкивидео — кусочки видео длиной от 2 до 5 секунд.
CDN - сеть доставки (и дистрибуции) содержимого (англ. Content Delivery Network или Content Distribution Network, CDN) — географически распределённая сетевая инфраструктура, позволяющая оптимизировать доставку и дистрибуцию содержимого конечным пользователям в сети Интернет. Использование контент-провайдерами CDN способствует увеличению скорости загрузки интернет-пользователями аудио-, видео-, программного, игрового и других видов цифрового содержимого в точках присутствия сети CDN.
Транскодирование - преобразование файла из одного метода кодирования (т.е. формата файла) в другой.
Шилдинг - ситуация, когда между серверами CDN и «оригинальным» сервером находится дополнительный сервер, через который проходит трафик. Таким образом, запросы на «оригинальный» сервер идут только с одного сервера, а не с множества серверов, что легче в управлении для клиента и сильно снижает нагрузку на его сервера.
Предлагаемое техническое решение осуществляет свою работу автономно, без необходимости организовывать централизованное хранилище для видео. Обычно системы транскодирования загружают созданное видео на какой-либо сервер, который уже отвечает за отказоустойчивость. В предлагаемой системе все сервера могут как транскодировать видео, так и могут являться источниками транскодированного видео.
Система представляет собой кластер серверов транскодирования видео под единым управлением балансировщика нагрузки. На входе система получает исходный видеопоток, а на выходе предоставляет транскодированный адаптивный поток, доступный по HTTP (HLS, также возможна выдача в MPEG-DASH).
Главной проблемой, которая появляется при исключении единого хранилища видео из системы, является обеспечение консистентности и однозначности данных при изменении текущего сервера транскодирования. Предлагаемое техническое решение использует ряд техник для решения этой проблемы.
Краткое описание проблемы консистентности данных
В случае отсутствия единого хранилища видеофайлов пользователю потребуется искать файлы для определенного видеопотока на каждом из серверов транскодирования. Однако, если сессия транскодинга будет перезапускаться на разных серверах кластера (из- за отказа сервера либо перебалансировки нагрузки, либо по другим причинам), то в результате получают разные файлы с одинаковым именем для доступа к потоку на разных серверах. Проблему можно было бы частично решить с помощью полной синхронизации всех файлов между серверами кластера, однако, это приведет к росту трафика между серверами, увеличению требуемого хранилища на каждом из транскодеров, увеличению нагрузки на диски и как итог увеличению задержки при транскодировании видео.
Предлагаемая система позволяет решить указанную проблему практически без какого-либо дополнительного увеличения нагрузки.
В состав системы входят:
• Несколько (по меньшей мере три) равноценных серверов транскодинга.
• Управляющая система-балансировщик нагрузки.
• CDN для выдачи файлов, производимых серверами транскодинга.
Все сервера-транскодеры создают чанклисты и чанки видео.
Сервера синхронизируют чанклист друг с другом через сетевую файловую систему.
Чанки видео не синхронизируются между серверами, а находятся только на том сервере, на котором создаются, чтобы не создавать сетевой трафик
Чанки видео имеют уникальную нумерацию. Это позволяет избежать проблем при рестарте транскодирования на другом сервере.
При просмотре видео чанклист скачивается с любого сервера, а для получения чанка видео осуществляется его поиск на одном из серверов
За поиск чанклистов и чанков видео на серверах отвечает конфигурация CDN.
Вся доставка видео с помощью протолока HLS — это периодическое обновление чанклиста (списка ссылок на актуальные чанки видео) и запрос чанков видео (видеофрагментов) по ссылкам из этого чанклиста.
Пользователь осуществляет запрос чанклистов и чанки видео с CDN, a CDN ищет эти файлы поочередно на каждом из серверов кластера. Чанклисты будут найдены на любом из серверов, поскольку чанклист постоянно синхронизируется между серверами, а чанк видео - только на одном из них (потому что он есть только там, где создан). Получение выходного транскодированного потока из входного по технологии HLS происходит следующим образом:
• На сервере транскодинга запускается процесс транскодирования.
• Получают исходный поток с сервера-источника сигнала и производит его преобразование.
• Т ранскодированный поток фрагментируется на небольшие части, чаще всего длительностью от 2 до 5 секунд, и добавляется в периодически обновляемый чанклист (список ссылок на такие фрагменты). Данный способ удобен для раздачи видео с помощью распространенного протокола HTTP, так как весь видеопоток представляет собой набор оконечных видеофайлов.
Принцип работы системы.
Балансировщик нагрузки формирует и отправляет серверу транскодирования команду. Формирование и отправка команды осуществляются следующим образом:
1. На основании желаемых параметров, заданных пользователем (разрешение выходного видео, битрейт, количество кадров в секунду и других), формируется команда транскодирования видео;
2. На основании текущего алгоритма балансировки (например Round-Robin, когда случайным образом выбирается один из серверов, либо наименее загруженный по процессору сервер) балансировщик осуществляет выбор наиболее подходящего сервера из кластера транскодирования;
3. Балансировщик отправляет выбранному серверу команду транскодирования через сервер обмена сообщениями на основе Redis.
После получения команды сервер транскодирования получает исходный поток (по протоколу RTMP или любому другому подходящему для передачи видео) и начинает транскодирование согласно полученным параметрам в формат HLS. Данный формат представляет транскодированный видеопоток в виде файлов следующего вида:
• Чанки видео — кусочки видео длиной примерно от 2 до 5 секунд.
• Чанклисты — постоянно обновляемый список имен генерируемых чанков видео.
При воспроизведении видео пользователь постоянно перезапрашивает чанклист по определенному неизменяемому и известному заранее URL, получает из него список URL актуальных чанков, и далее запрашивает требуемые для воспроизведения чанки видео.
В рамках предлагаемой системы чанки видео имеют строго уникальное имя, привязанное к времени начала транскодирования, например 2019010101124501. ts, таким образом, имена файлов принципиально не могут пересечься, если сессия транскодирования будет перезапускаться на разных серверах.
Однако, имя файла чанклиста должно быть одинаковым на всех серверах, так как это имя заранее определено и явно указывается пользователям при доступе к потоку, например streams/123/480p/index.m3u8. Если сессия транскодирования будет запускаться на разных серверах, это приведет к наличию одного или нескольких неактуальных файлов на разных серверах, и пользователь не сможет однозначно определить, какой из файлов ему нужно смотреть в данный момент.
В предлагаемой системе эта проблема решается путем хранения файлов чанклистов отдельно от чанков. При этом папка с чанклистами постоянно синхронизируется между серверами с помощью любой распределенной файловой системы (в конкретном случае используется GlusterFS).
Чанклисты — файлы небольшого объема, но обновляются очень часто (раз в 1 -2 секунды). Распределенная файловая система может легко и быстро синхронизировать эти файлы между серверами с минимальной нагрузкой на сеть и диски каждого из серверов.
Таким образом, на каждом сервере мы получаем идентичный файл-чанклист и множество файлов с чанками видео, имеющих уникальное имя и потому не имеющими проблем с консистентностью.
Настройка CDN для просмотра видео.
Пользователь получает доступ к видеопотоку через CDN. По умолчанию для раздачи видеопотоков используется G-Core CDN. Это классический CDN (Content Delivery Network), предназначенный для доставки трафика на широкую аудиторию с помощью сети геораспределенных серверов. Сервера сети забирают видеотрафик с исходных серверов, кэшируют у себя и раздают конечным пользователям. Используя возможности настройки G-Core CDN появляется возможность указать в его настройках возможность использования в качестве источника файлов все сервера кластера транскодирования видео. При каждом запросе любого файла, CDN ищет его на любом из серверов кластера (проходя весь список по очереди, определяемой каждый раз случайным образом для выравнивания нагрузки, пока не найдет нужный файл).
В предлагаемой системе CDN работает следующим образом:
• При поиске чанклиста — используется первый попавшийся чанклист, так как все чанклисты синхронизированы между серверами.
• При поиске чанка видео — осуществляется поиск по всем серверам, благодаря уникальности имени.
В конечном счете CDN осуществляет поиск всех необходимых пользователю файлов для просмотра видеопотока. Зритель не будет знать об устройстве кластера транскодирования видео, а будет использовать только внешние ссылки на CDN.
Процедура при смене сервера транскодирования.
В случае изменения текущего сервера транскодирования, транскодер начинает процесс не заново, а считывает уже имеющийся у него файл-чанклист. Таким образом, все ссылки на предыдущие чанки видео останутся в чанклисте и зритель не почувствует никакой разницы в чанклисте после смены сервера. Зритель сможет перематывать видео на момент как до переключения, так и после, а чанки видео будут скачиваться как с предыдущего, так и с нового сервера в данном случае.
Ограниченная отказоустойчивость при падении одного из серверов кластера.
Так как чанки с видео никак не реплицируются, выход из строя текущего сервера транскодинга приведет к тому, что после перезапуска процесса транскодирования на новом сервере старые чанки будут недоступны, и перемотка назад для зрителя работать не будет.
Для решения данной проблемы используются промежуточные сервера между CDN и кластером транскодирования, которые будут принудительно и упреждающе кэшировать все новые чанки из чанклиста. В рамках инфраструктуры G-Core CDN это реализуемо с помощью сервиса шилдинга. Шилдинг позволяет снизить нагрузку на сервера-источники видеотрафика с помощью промежуточных кэширующих серверов.
Второй доступной технологией для решения данной проблемы с минимальными затратами является создание пар серверов в рамках рассматриваемого кластера, в рамках которых они будут обмениваться чанками с видео. Если бы обмен чанками производился между всеми серверами кластера, нагрузка на сеть и диски была бы N*M, где N — это количество серверов, а М — количество потков. Если сервера объединить в пары, нагрузка будет 2*М, что достаточно приемлемо для большинства случаев.
Использование предлагаемой системы для Low-Latency стриминга.
Предалагемая система подходит для доставки видео по протоколу HTTP с низкой задержкой.
Различные имеющиеся на данный момент техники Low-Latency стриминга предполагают, что система может обновлять чанклисты часто и быстро, и предоставлять доступ к чанкам максимально быстро после их создания.
Так как в предлагаемой системе отсутствуют любые синхронные взаимодействия, помимо быстрой синхронизации маленьких чанклистов, это позволяет максимально быстро получать доступ к создаваемым чанкам и чанклистам.
На Фиг. 2 представлена общая схема вычислительного устройства (200), которое выполнено с возможностью обеспечивать обработку данных, необходимую для реализации заявленного решения, причем в качестве вычислительного устройства может выступать сервер.
В общем случае устройство (200) содержит такие компоненты, как: один или более процессоров (201), по меньшей мере одну память (202), средство хранения данных (203), интерфейсы ввода/вывода (204), средство В/В (205), средства сетевого взаимодействия (206).
Процессор (201) устройства выполняет основные вычислительные операции, необходимые для функционирования устройства (200) или функциональности одного или более его компонентов. Процессор (201) исполняет необходимые машиночитаемые команды, содержащиеся в оперативной памяти (202).
Память (202), как правило, выполнена в виде ОЗУ и содержит необходимую программную логику, обеспечивающую требуемый функционал.
Средство хранения данных (203) может выполняться в виде HDD, SSD дисков, рейд массива, сетевого хранилища, флэш-памяти, оптических накопителей информации (CD, DVD, MD, Blue-Ray дисков) и т.п. Средство (203) позволяет выполнять долгосрочное хранение различного вида информации, например, вышеупомянутых файлов с наборами данных пользователей, базы данных, содержащих записи измеренных для каждого пользователя временных интервалов, идентификаторов пользователей и т.п.
Интерфейсы (204) представляют собой стандартные средства для подключения и работы с серверной частью, например, USB, RS232, RJ45, LPT, COM, HDMI, PS/2, Lightning, FireWire и т.п.
Выбор интерфейсов (204) зависит от конкретного исполнения устройства (200), которое может представлять собой персональный компьютер, мейнфрейм, серверный кластер, тонкий клиент, смартфон, ноутбук и т.п.
В качестве средств В/В данных (205) в любом воплощении системы, реализующей описываемый способ, должна использоваться клавиатура. Аппаратное исполнение клавиатуры может быть любым известным: это может быть, как встроенная клавиатура, используемая на ноутбуке или нетбуке, так и обособленное устройство, подключенное к настольному компьютеру, серверу или иному компьютерному устройству. Подключение при этом может быть, как проводным, при котором соединительный кабель клавиатуры подключен к порту PS/2 или USB, расположенному на системном блоке настольного компьютера, так и беспроводным, при котором клавиатура осуществляет обмен данными по каналу беспроводной связи, например, радиоканалу, с базовой станцией, которая, в свою очередь, непосредственно подключена к системному блоку, например, к одному из USB-портов. Помимо клавиатуры, в составе средств В/В данных также может использоваться: джойстик, дисплей (сенсорный дисплей), проектор, тачпад, манипулятор мышь, трекбол, световое перо, динамики, микрофон и т.п.
Средства сетевого взаимодействия (206) выбираются из устройства, обеспечивающий сетевой прием и передачу данных, например, Ethernet карту, WLAN/Wi- Fi модуль, Bluetooth модуль, BLE модуль, NFC модуль, IrDa, RFID модуль, GSM модем и т.п. С помощью средств (205) обеспечивается организация обмена данными по проводному или беспроводному каналу передачи данных, например, WAN, PAN, ЛВС (LAN), Интранет, Интернет, WLAN, WMAN или GSM.
Компоненты устройства (200) сопряжены посредством общей шины передачи данных (210). В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.

Claims

ФОРМУЛА ИЗОБРЕТЕНИЯ
1 . Система отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS содержащая: географически распределённую сетевую инфраструктуру (CDN), выполненную с возможностью выдачи чанклистов и чанки видео, производимых серверами транскодирования, причем при запросе чанклистов и чанки видео с CDN, CDN за счет заранее заданной конфигурации осуществляет поочередный поиск чанклистов и чанки видео на каждом из серверов кластера; балансировщик нагрузки, который выполнен с возможностью формирования и отправки команд серверам транскодирования; кластер серверов транскодирования видео, находящийся под единым управлением балансировщика нагрузки и выполненный с возможностью: создания чанклистов и чанки видео; синхронизации чанклистов друг с другом посредством распределенной файловой системы, причем: чанки видео не синхронизируются между серверами, а находятся только на том сервере, на котором создаются; чанки видео имеют уникальную нумерацию; при воспроизведении видео чанклист скачивается с любого сервера, а для получения чанка видео осуществляется его поиск на одном из серверов, при этом, посредством промежуточных серверов между CDN и кластером транскодирования, осуществляется принудительное и упреждающее кэширование всех новых чанки из чанклиста, причем посредством транскодера при смене сервера транскодирования осуществляется считывание имеющегося у него файл-чанклиста.
PCT/RU2021/050397 2020-09-28 2021-11-26 Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls WO2022066066A1 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
RU2020131840 2020-09-28
RU2020131840A RU2759595C1 (ru) 2020-09-28 2020-09-28 Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls

Publications (1)

Publication Number Publication Date
WO2022066066A1 true WO2022066066A1 (ru) 2022-03-31

Family

ID=78607167

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2021/050397 WO2022066066A1 (ru) 2020-09-28 2021-11-26 Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls

Country Status (2)

Country Link
RU (1) RU2759595C1 (ru)
WO (1) WO2022066066A1 (ru)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140379871A1 (en) * 2011-12-29 2014-12-25 Koninklijke Kpn N.V. Network-Initiated Content Streaming Control
US20150288736A1 (en) * 2014-04-03 2015-10-08 Cisco Technology Inc. Method for Enabling Use of HLS as a Common Intermediate Format
RU2647654C2 (ru) * 2012-08-27 2018-03-16 Броадпик Система и способ доставки аудиовизуального контента в клиентское устройство
US20180227648A1 (en) * 2015-10-29 2018-08-09 Le Holdings (Beijing) Co., Ltd. Method for live broadcast based on hls protocol and electronic device

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107222480A (zh) * 2017-05-27 2017-09-29 中国联合网络通信集团有限公司 一种流媒体播放方法、终端设备及cdn服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140379871A1 (en) * 2011-12-29 2014-12-25 Koninklijke Kpn N.V. Network-Initiated Content Streaming Control
RU2647654C2 (ru) * 2012-08-27 2018-03-16 Броадпик Система и способ доставки аудиовизуального контента в клиентское устройство
US20150288736A1 (en) * 2014-04-03 2015-10-08 Cisco Technology Inc. Method for Enabling Use of HLS as a Common Intermediate Format
US20180227648A1 (en) * 2015-10-29 2018-08-09 Le Holdings (Beijing) Co., Ltd. Method for live broadcast based on hls protocol and electronic device

Also Published As

Publication number Publication date
RU2759595C1 (ru) 2021-11-15

Similar Documents

Publication Publication Date Title
CA3018723C (en) Playback synchronization among adaptive bitrate streaming clients
US11350139B2 (en) Video live broadcast method and apparatus
US11665218B2 (en) Fast encoding of live streaming media content
US8145782B2 (en) Dynamic chunking for media streaming
CN107743708B (zh) 经由dash来参与abr流传送会话的方法、装置和节点
CA2988320C (en) Http live streaming (hls) video client synchronization
CN109791557B (zh) 用于管理资产存储的计算机实现的方法以及存储系统
WO2014007083A1 (ja) 送信装置、送信方法およびネットワーク装置
US20140165119A1 (en) Offline download method, multimedia file download method and system thereof
US20110191446A1 (en) Storing and streaming media content
AU2010202740B1 (en) Dynamic indexing for ad insertion in media streaming
AU2013240578B2 (en) Dynamic audio track selection for media streaming
US8954540B2 (en) Dynamic audio track selection for media streaming
EP3868071B1 (en) Distributed state recovery in a system having dynamic reconfiguration of participating nodes
KR102019654B1 (ko) 적응형 스트리밍 서버를 전환하기 위한 방법
US10523755B1 (en) Peer-based cloud storage for media broadcasts
RU2759595C1 (ru) Система отказоустойчивого транскодирования и выдачи прямых потоков в формате hls
US10021205B2 (en) Rules-based multipoint routing of real-time information using client-server architecture
Prasad et al. Social Educational Streaming Platform Using HTML Live Streaming
EP3292698B1 (en) Http live streaming (hls) video client synchronization
Nekrasov et al. Distributed load balancing for the adaptive video streaming using CDN with ring system of server consolidation by circulant topology
US11870830B1 (en) Embedded streaming content management
KR20160063182A (ko) 분산 멀티미디어 스트리밍 서비스 제공 시스템 및 스트리밍 서비스의 제공 방법
US20200260144A1 (en) Video Stream Switching Service
Kolekar et al. Design of Clustered Streaming Servers to Balance the Network Load for VoD Applications.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21873053

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21873053

Country of ref document: EP

Kind code of ref document: A1