СИСТЕМА ОТКАЗОУСТОЙЧИВОГО ТРАНСКОДИРОВАНИЯ И ВЫДАЧИ ПРЯМЫХ ПОТОКОВ В ФОРМАТЕ HLS Российский патент 2021 года по МПК H04N21/00 

ОБЛАСТЬ ТЕХНИКИ

Настоящее техническое решение относится к области вычислительной техники, в частности к системам отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS.

УРОВЕНЬ ТЕХНИКИ

Из уровня техники известно решение, выбранное в качестве наиболее близкого аналога, US 2012254456 A1, 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, а 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 — это количество серверов, а M — количество потков. Если сервера объединить в пары, нагрузка будет 2*M, что достаточно приемлемо для большинства случаев.

Использование предлагаемой системы для 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).

В настоящих материалах заявки было представлено предпочтительное раскрытие осуществление заявленного технического решения, которое не должно использоваться как ограничивающее иные, частные воплощения его реализации, которые не выходят за рамки испрашиваемого объема правовой охраны и являются очевидными для специалистов в соответствующей области техники.

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

Система отказоустойчивого транскодирования и выдачи прямых потоков в формате HLS, содержащая:

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

балансировщик нагрузки, который выполнен с возможностью формирования и отправки команд серверам транскодирования;

кластер серверов транскодирования видео, находящийся под единым управлением балансировщика нагрузки и выполненный с возможностью:

создания чанклистов и чанки видео;

синхронизации чанклистов друг с другом посредством распределенной файловой системы, причем:

чанки видео не синхронизируются между серверами, а находятся только на том сервере, на котором создаются;

чанки видео имеют уникальную нумерацию;

при воспроизведении видео чанклист скачивается с любого сервера, а для получения чанка видео осуществляется его поиск на одном из серверов,

при этом посредством промежуточных серверов между CDN и кластером транскодирования осуществляется принудительное и упреждающее кэширование всех новых чанки из чанклиста, причем

посредством транскодера при смене сервера транскодирования осуществляется считывание имеющегося у него файл-чанклиста.