Руководство по внедрению Flussonic для IPTV/OTT провайдеров¶

Вы запускаете свой IPTV/OTT сервис? Или только рассматриваете возможность его реализации? Если хоть на один из этих вопросов Вы ответили положительно, то это руководство для Вас. В этом руководстве Вы познакомитесь с IPTV/OTT сервисом и тем, как его реализовать с помощью Flussonic Media Server.

Часть "Обзор решения" даёт краткое описание базовой структуры IPTV/OTT сервиса. В части "Архитектура решения" рассматриваются базовая архитектура, составляющие и их сообщение между собой более детально. Пример реализации решения приведён в части "Определение требований и разработка".

Содержание¶

В последние годы рынок IPTV/OTT сервиса растёт быстрыми темпами. По оценкам исследователей Allied Market Research, стоимость рынка IPTV/OTT в 2019 году составляла 121,61 млрд долларов, а к 2027 году может достичь 1,039 трлн долларов. Количество подписчиков стриминговых сервисов и платформ значительно возросло с начала пандемии 2020 года. Люди всё больше времени проводят за просмотром ТВ-шоу, фильмов и трансляций.

Люди часто смотрят любимые сериалы и фильмы на ходу. Вы наверняка видели как в вагоне метро сидит человек с наушниками в ушах и, уткнувшись в экран своего смартфона, что-то внимательно смотрит. И, если приглядеться, то можно заметить, что это очередной эпизод многосерийного фильма или, возможно, какой-то прямой эфир. IPTV/OTT позволяет своим зрителям управлять просмотром так, что зрители могут смотреть любимые передачи в удобное для них время и в подходящем месте. Гибкость в управлении просмотром контента является отличительной чертой IPTV/OTT сервиса.

Так что же такое IPTV/OTT?

В русском сообществе провайдеров IPTV и OTT эта тема остаётся дискуссионной. Каждый определяет IPTV и OTT по-своему, что вызывает волну обсуждений и споров, не приводящих, в итоге, к единому мнению. Одни считают, что IPTV и OTT — два абсолютно разных понятия, характеризующих две разные технологии передачи цифрового сигнала, другие же уверены, что чёткой границы между этими двумя понятиями не существует, а значит, и в их разделении нет большого смысла.

Таким образом, в первую очередь необходимо дать определение понятию IPTV/OTT.

Обзор решения¶

IPTV/OTT — технология передачи видеоконтента по открытой сети Интернет.

Для Flussonic нет как таковой разницы в том, какую технологию внедрять — IPTV или OTT, значение имеет способ доставки контента до конечного пользователя (именно поэтому мы пишем это понятие через слэш "/"). Таким образом, во Flussonic нет чёткого разделения этих двух понятий. Мы стараемся помочь нашим клиентам создать действительно качественный и эффективный сервис, который позволит абонентам наслаждаться его использованием.

Итак, базовыми составляющими структуры IPTV/OTT являются:

головная станция,
сервер захвата,
транскодер,
DVR (опционально),
рестример (+ локальный архив опционально),
плеер или STB.

Note

Состав компонентов может изменяться в зависимости от выбранной схемы доставки контента. Так, например, если Вы хотите вещать только live-трансляции, то архив DVR вам не понадобится.

Давайте посмотрим как происходит доставка контента до конечного пользователя.

Головная станция осуществляет захват видеопотоков с различных источников в различных стандартах цифрового телевизионного вещания: DVB, ATSC или ISDB. Затем выход головной станции передаётся по закрытой IP-сети на вход серверу захвата. Далее сигнал передаётся транскодеру, который осуществляет некоторые преобразования входных потоков для того, чтобы в дальнейшем смотреть контент на различных устройствах с различной пропускной способностью Интернета. После этого транскодер отправляет преобразованные потоки на вход DVR по закрытой IP-сети (этот этап опционален и зависит от того, используете ли Вы DVR). В DVR осуществляется запись и хранение копий видеопотоков для их дальнейшего использования. Впоследствии потоки передаются рестримеру по той же закрытой IP-сети. На этом этапе происходит подключение системы аутентификации и DRM для защиты доступа к контенту. Затем по требованию зрителя рестример предоставляет желаемый канал по открытой сети Интернет.

Подробнее см. IPTV/OTT.

Разработка и внедрение¶

Первым шагом в запуске собственного IPTV/OTT проекта является составление плана. Планирование — наше всё, не так ли?

Требования к IPTV/OTT-сервису¶

Первое, что необходимо сделать при запуске своего стримингового сервиса или стриминговой платформы — определить требования. Ответьте на несколько вопросов: Как Вы хотите, чтобы работал ваш сервис? Какие услуги хотите предоставлять пользователю? Какими техническими средствами располагаете? и т.д.

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

Определение списка телепрограмм для вещания¶

Итак для определения списка телепрограмм для вещания Вам сначала необходимо исследовать Вашу целевую аудиторию. Что смотрит, где, когда и как? Что зрители смотрят чаще: live-трансляции или VoD?

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

Flussonic может осуществлять захват всех трёх типов источников, так что нет необходимости выбирать лишь один из них.

Определение требований для "последней мили", медиаплеера, STB-приставки и поставщика middleware, их выбор¶

В наши дни стандарты для IPTV/OTT сервисов достаточно высоки. Избирательность зрителей в выборе контента, качестве вещания, скорости загрузки, списка предлагаемых услуг и т.д. становится настоящим испытанием для IPTV/OTT провайдеров. Потребители ожидают, что просмотр контента будет возможен из любого места, в любое время и с любого устройства. Таким образом, IPTV/OTT провайдерам необходимо подстраиваться под запросы потребителей, чтобы остаться на рынке.

"Последняя миля"¶

Прежде чем мы пойдём дальше, давайте дадим определение термину "последняя миля". Последняя миля — это фраза, используемая в индустрии телекоммуникаций, описывающая канал, соединяющий клиентское оборудование с узлом доступа провайдера (оператора связи).

Это последнее звено связи между зрителем и провайдером описывает как физически будет осуществляться доставка сигнала. Так способы организации "последней мили" делятся на две категории: проводные (например, LAN) и беспроводные (Wi-Fi) в зависимости от характера среды передачи информации.

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

Не секрет, что в проводной организации связи сети используются кабели. Известно, что этот тип соединения быстрее, чем беспроводной. Но разница не слишком уж велика. Однако проводная связь считается более надёжной, по сравнению с беспроводной. Поскольку беспроводная технология не использует провода и передаёт сигнал по воздуху, то и вызвать помехи в таком случае гораздо легче.
Прокладывать кабель далеко не всегда удобно. В некоторые места просто невозможно провести провод. Кроме того, у Вас может не быть прав на такие действия с юридической точки зрения. Самый главные камень преткновения проводных сетей — привязка к роутеру. С одной стороны — клиентское устройство (ПК, STB-приставка, игровая консоль, Smart TV), а с другой — вход роутера. Заметим, что подключение мобильных устройств в таком случае — невозможно. Таким образом, мы подошли к ещё одному ограничению проводных технологий организации сетей — отсутствие мультиплатформенности.

Для беспроводного соединения вам не нужны провода и кабели, чтобы передавать данные потребителю. Так устройства могут находится на некотором расстоянии от роутера и оставаться подключенными к сети. Это гораздо удобнее для пользователей, поскольку они не зависят от места, в отличие от проводного соединения. Несмотря на это, этот тип организации сети менее надёжный. Однако его проще подготовить и установить. К тому же он поддерживает мультиплатформенность.

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

Медиаплееры и STB-приставки¶

На этапе проигрывания контента в игру вступает медиаплеер и STB-приставка.

Медиаплеер — главное звено для проигрывания контента.

Существует достаточное количество медиаплееров, совместимых с широким списком платформ, таких как Windows, Linux, Mac OS, Android и т.п.). Вот несколько примеров мультиплатформенных медиаплееров: Kodi, OTT Player, VLC, Ott-play (by Alex), Telebreeze.

Ниже мы привели таблицу с плеерами и поддерживаемыми ими протоколами для проигрывания:

Плееры	Протоколы
Kodi	AirPlay/AirTunes, UPnP, SMB/SAMBA/CIFS, AFP, Zeroconf/Avahi/Bonjour, NFS, HTTP, HTTPS, FTP, RTSP (RTSPU, RTSPT), MMS (MMSU, MMST), TCP, UDP, SFTP, RTP and RTMP (including RTMP, RTMPT, RTMPE, RTMPTE, RTMPS), DHCP, NTP, WebDAV
OTT Player	HLS, RTSP, TS by UDP, RTMP
VLC	HLS, RTMP, DASH, MPEG-TS, RTP/RTSP, ISMA/3GPP PSS, MMS
Ott-play (by Alex)	HLS, HTTP, RTMP
Telebreeze	UDP, TCP, RTP, HLS, HTTP, RTMP (MPEG-TS)

Во Flussonic есть собственный медиаплеер — MSE Player, который позволяет добиться низкой задержки при проигрывании.

Подробнее о Flussonic MSE PLayer см. MSE PLayer.

Выбор медиаплеера также зависит от кодека входного потока.

У платформ имеются встроенные ("дефолтные") медиаплееры. Например, если вы разрабатываете мобильное приложение, то Вам необходимо исследовать набор протоколов и кодеков, поддерживаемых мобильными браузерами. Рассмотрите, например, таблицу ниже:

Кодек/ Браузер	MPEG-4 (H.264 format)	HEVC/H.265	HLS	MPEG-DASH	RTSP (and RTMP)
Safari	+	+	+	-	-
Chrome for Android	+	+	+	-	-
Samsung Internet	+	-	+	-	-
UC Browser for Android	~ (partial support)	-	+	-	-
Android Browser	+	-	+	-	-

В ней указаны плееры и поддерживаемые ими кодеки и протоколы.

Какие устройства можно использовать для просмотра IPTV/OTT?

Smart TV;
Планшет;
Смартфон;
ПК;
Игровая консоль.

В принципе любое устройство, на которое можно установить медиаплеер.

Note

Необходимо, чтобы выбранные Вами конечные устройства также поддерживали нужные Вам протоколы.

Flussonic может передавать данные по таким протоколам, как MPEG-TS, HLS, MSS, RTMP, RTSP, SRT, WebRTC и DASH. Вы также можете ограничить количество протоколов для проигрывания. Подробнее см. Проигрывание.

Middleware¶

Ответственность за логику сообщения между различными системами, необходимыми для функционирования IPTV/OTT, за интерфейс и ряд других услуг, предоставляемых абонентам, несёт Middleware.

Middleware — программное обеспечение промежуточного слоя. Оно выполняет роль координатора взаимодействия различных систем, необходимых для функционирования IPTV/OTT-платформы, и находится между ними.

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

Middleware может предоставлять широкий спектр услуг. Например:

Линейный просмотр ТВ.
EPG (Electronic Program Guide), т.е. расписание телепередач.
Организация каналов по платным пакетам.
Каталогизация каналов (по жанрам, интересам).
Родительский контроль (контент 16+, 18+).
Catch up TV (просмотр записанных телепередач).
Информационные сервисы (например, прогноз погоды, курс валют) и реклама.
"Видео по запросу", или VOD (Video On Demand), т.е. просмотр фильмов и сериалов.
Функция отложенного просмотра, или таймшифт (возможность отмотки назад прямого эфира и возвращения к его текущему моменту).
Интеграция с биллинг-системой.
Пользовательский доступ.
Интеграция с DRM.

Flussonic можно интегрировать практически с любым Middleware, например, со Stalker (см: Middleware Stalker и Flussonic), iptvportal (Flussonic Media Server входит в состав пакета), CloudWare, Telebreeze

Интеграцию с другими Middleware можно провести по Вашему запросу. Для этого Вам необходимо обратиться к Вашему поставщику Middleware и проверить совместимость с Flussonic Media Server самостоятельно.

Подробнее о Middleware и его интеграции с Flussonic см. Middleware.

Определение требований для поставщика DRM, его выбор¶

Для эффективной работы IPTV/OTT-платформы Вам необходимо принять меры предосторожности, чтобы избежать нежелательного доступа к контенту. Для этого Вам необходима система защиты доступа к контенту — DRM.

DRM (Digital Rights Management) — система или комплекс программно-аппаратных средств защиты контента. Используется с целью ограничения доступа к контенту и его защиты от копирования и нежелательного распространения.

Что важно при выборе системы DRM? Чем нужно руководствоваться?

Необходимо, чтобы система DRM была, в первую очередь, совместима с Middleware, поскольку именно через Middleware осуществляется взаимодействие клиента c DRM.

DRM предоставляет следующую функциональность:

Защита от копирования (ограничение прав пользователей на копирование, сохранение и распространение контента).
Защита от клонирования (ограничение прав пользователей на просмотр контента на нескольких устройствах одновременно с использованием одного и того же ID).
Ограничение прав на запись экрана и скриншоты.
Управление сроком доступа к контенту (ограничение времени, в течение которого пользователь может просматривать контент, или количества раз, которое он может это делать).
Настройка стоп-листа (ограничение доступа к контенту с помощью создания списка IP-адресов, местоположений или устройств, для которых этот доступ может быть запрещён/разрешён).
Наложение водяных знаков.

Flussonic поддерживает работу со следующими системами DRM: EzDRM, DRM Conax, DRM Conax для Nagra, BuyDRM (KeyOS), Widevine, PallyCon, Irdeto, PlayReady DRM, GS DRM, Solocoo.

Подробнее о работе DRM и её интеграции с Flussonic см. Защита контента с помощью DRM.

Определение требований для ТВ-сервиса и качества предоставления услуг: профили абонентов¶

Определение требований для мониторинга¶

Как оценить насколько хорошо работает ваш сервис/платформа? Как узнать хватает ли ресурсов для вашей системы? Как вовремя заметить ошибки в работе сервиса и предотвратить остановку его работы?

Ответ на эти и другие подобные вопросы — мониторинг. Мониторинг — это процесс постоянного наблюдения за работой сервера и его процессами для поиска и установления проблем производительности сервера и оценки использования его ресурсов. Некоторые их таких ресурсов включают в себя использование CPU и RAM, трафик (вход/выход) и пропускная способность сети (вход/выход), дисковый ввод и вывод и др. Для оценки работы IPTV/OTT-сервиса обычно используются значения следующих параметров:

использование и загрузка CPU,
использование и загрузка RAM,
пропускная способность сети (вход/выход),
трафик сети (вход/выход),
дисковый ввод и вывод,
число потоков/телеканалов (активных, с ошибками),
число зрителей (активных, пики) и др.

Мониторинг необходим для:

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

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

Для мониторинга работы Flussonic Media Server вы можете использовать:

сервис статистики Retroview

Flussonic собирает статистику по работе сервера и визуализирует эти данные на вкладке Статистика в личном кабинете на my.flussonic.com. Вы можете использовать эти данные для анализа нагрузки и работы системы в ретроспективе.

текущее состояние параметров системы во вкладке Pulse в Flussonic UI,
логирование.

Логирование позволяет вам регистрировать действия на вашем сервере. Отслеживая логи, вы можете диагностировать проблемы и предотвращать их появление в дальнейшем. Чтобы узнать подробнее о том, как настроить логирование событий во Flussonic, см. Events API. Актуальный список событий Flussonic вы можете найти в API Reference.

Мы рассмотрели основные аспекты, на которые стоит обратить внимание при планировании вашего IPTV/OTT-проекта: список телепрограмм для вещания, "последняя миля", медиаплеер, STB-приставка, поставщик Middleware, поставщик DRM, мониторинг. Теперь от планирования к активным расчётам.

План внедрения: технические требования¶

Поле того, как вы определили организацию сети, её структуру, можно перейти к техническим требованиям. С чего начать?

В этой части мы разберёмся с требованиями к сети на входе и на выходе, требованиями для транскодера, DVR и рестримера.

Как определить требования для сети?¶

Чтобы определить требования для сети, вам необходимо знать: тип входящего сигнала(ов) (эфир, кабель, спутник), число входящих потоков, примерное количество зрителей, тип(ы) конечных устройств, на которые вы ориентированы, тип(ы) транспортных протоколов, кодеки, тип контента для вещания и т.п.

В таблице ниже приведён список профилей и соответствующих им значений битрейта:

Note

Значение битрейта варьируется в пределах одного и того же профиля и зависит от таких факторов, как скорость изменения картинки, степень сжатия, значение FPS (Frames Per Second).

Профиль	Скорость (битрейт)	Разрешение	Видеокодек	Частота кадров (FPS)	Аудиокодек	Скорость (битрейт) аудио
SD (Низкий)	400-600 Кбит/с	480x270p	H.264, AVC	25 или 30	AAC	64 Кбит/с
SD (Средний)	600 Кбит/с-1 Мбит/с	640x360p	H.264, AVC	25 или 30	AAC	96 Кбит/с
SD (Высокий)	1-1.5 Мбит/с	854x480p	H.264, AVC	25 или 30	AAC	96 Кбит/с
HD (720p)	2-4 Мбит/с	1280x720p	H.264, AVC	25 или 30	AAC	128 Кбит/с
Full HD (1080p)	3-8 Мбит/с	1920x1080p	H.264, AVC	25 или 30	AAC	192 Кбит/с
Ultra HD (4K)	8-15 Мбит/с	3840x2160p	H.264, AVC	25 или 30	AAC	192 Кбит/с

Как рассчитать пропускную способность сети на входе для захвата контента?

Допустим, нам необходимо захватить 100 каналов (60 Full HD (1080p) и 40 HD (720p)) по UDP. Пусть на один Full HD канал приходится до 6 Мбит/с, а на один HD — до 3 Мбит/с. Тогда значение пропускной способности для входного сигнала будет рассчитываться так: (6 Мбит/с * 60) + (3 Мбит/с * 40) = 480 Мбит/с.

Теперь каждый из 60 каналов Full HD (1080p) нам необходимо транскодировать в 3 профиля:

Full HD (1080p), H.264, 4 Мбит/с;
HD (720p), H.264, 2 Мбит/с;
SD (480p), H.264, 1 Мбит/с.

А также 40 каналов HD (720p) в 2 профиля:

HD (720p), H.264, 2 Мбит/с;
SD (480p), H.264, 1 Мбит/с.

Аудиопоток для всех профилей — AAC, 128 Кбит/с.

Рассчитаем битрейт на выходе транскодера: (4 Мбит/с + 2 Мбит/с + 1 Мбит/с + 0.128 Мбит/с) * 60 + (3 Мбит/с + 1 Мбит/с + 0.128 Мбит/с) * 40 ≈ 593 Мбит/с.

Мы также будем использовать DVR для записи архива. Рассчитывать ориентировочный объем жесткого диска для записи архива телеканалов мы будем немного позже.

Теперь давайте рассчитаем пропускную способность для выходного сигнала Edge-сервера, или рестримера.

Предположим, у нас на сервере одновременно 4000 зрителей, из которых половина просматривает телеканалы в Full HD (1080p), 1200 — в HD (720p), 800 — в SD (576p). Пусть на один Full HD канал приходится 6 Мбит/с, на HD — 3 Мбит/с, а на SD — 1 Мбит/с. Итого получается (6 Мбит/с * 2000) + (3 Мбит/с * 1200) + (1 Мбит/с * 800) = 16.4 Гбит/с. Таким образом, пропускная способность нашей сети должна быть не меньше 16.4 Гбит/c.

Чтобы узнать о системных требованиях для вашего проекта, см. Системные требования.

Как определить требования к серверу с транскодером?¶

Транскодирование — самая затратная операция в вашем видеотракте, поэтому отдельно рассмотрим, как определять требования для серверов с транскодером. Подробнее о том, что такое транскодер в Flussonic, см. ниже на этой странице.

Практически невозможно произвести универсальный расчет, по результатам которого вы поймете, что вам подойдет та или иная аппаратная конфигурация. Для такого расчета нужно учитывать слишком много факторов, например, доступные ресурсы, бюджет, характеристики входных и выходных потоков и т.д. Каждый случай индивидуален. Если вы планируете приобретать свой сервер, то мы можем посоветовать только поиск перебором: возьмите один любой сервер на 5–20 каналов и проведите тестирование. Если результат вас не удовлетворит, возьмите другой сервер. Повторяйте до тех пор, пока не достигните требуемой производительности.

Но есть и другой путь. Мы предлагаем собственный сервер для транскодирования, упаковки и доставки видео — Flussonic Coder. Он спроектирован так, чтобы обеспечивать максимальную производительность при работе с видео, и мы гарантируем, что вы сможете транскодировать указанное в спецификации количество каналов.

Посчитаем, сколько кодеров нам понадобится для рассмотренного выше примера с расчетами сети.

Нам нужно создать мультибитрейтные потоки из 60 каналов Full HD (1080p) и 40 каналов HD (720p). Также мы знаем, сколько каналов Flussonic Coder может транскодировать в три профиля (это то число потоков, которое указано в спецификации). Достаточно разделить одно на другое, чтобы узнать количество кодеров. Составим небольшую таблицу:

Разрешение	Требуется	Поддерживается	Кол-во кодеров
Full HD	60	48	60/48 = 1.25 ≈ 2
HD	40	56	40/56 = 0.72 ≈ 1
		Итого	3

Таким образом, нам понадобится всего 3 устройства Flussonic Coder для транскодирования по указанной схеме. Однако HD каналы мы транскодируем в два профиля, а не в три, за счет чего высвобождаются дополнительные ресурсы, и возможно вам будет достаточно и двух кодеров.

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

Архитектура решения¶

Flussonic Media Server — это инструмент, который Вы можете настроить под себя и свои нужды. Он может выполнять функции головной станции, транскодера, DVR или рестримера в зависимости от того, как Вы его настроите. Всё начинается с целей и задач, которые вы определяете для своего проекта, а также какой набор сервисов вы хотите предоставить своим абонентам.

Составляющие¶

Как мы уже замечали, для внедрения IPTV/OTT технологии необходимы:

Повторимся, что это лишь базовый набор элементов структуры. Также необходимо определить ряд параметров, которые мы рассмотрим чуть позже.

Головная станция¶

Головная станция — необходимый элемент для захвата видеопотоков с разных источников, таких как телевышки, спутники или кабели одного или нескольких контент-провайдеров.

Так на входе в головную станцию Flussonic видеопотоки могут быть в формате следующих стандартов цифрового телевизионного вещания: DVB и ISDB (-T (телевышка), -S (спутник), -C (кабель)), ATSC (телевышка/кабель). В качестве транспортного протокола для передачи ТВ-сигнала используется MPEG-2.

Какого же назначение головной станции? Она выполняет следующие функции:

Захват видеопотоков с разных источников.

Захват сигналов стандартов DVB, ISDB, ATSC по мультипрограммному транспортному протоколу MPEG-2 (MPEG-TS, MPTS "Multiple Program Transport Stream").

Дескремблирование видеопотоков.

Большинство принятых каналов заскремблированы, т.е. некоторым образом защищены. Такая мера защиты необходима для предотвращения доступа к контенту сторонним зрителям, не оплатившим услугу. Процедура же обратная скремблированию называется дескремблированием. Это и делает головная станция.

Подробнее о дескремблировании см. Дескремблирование.

Демультиплексирование видеопотоков.

Видеопотоки поступают в головную станцию в виде MPTS (Multiple Program Transport Stream), состоящих из некоторого числа программ, т.е. отдельных каналов. Головная станция осуществляет демультиплексирование, т.е. разбирает эти видеопотоки на отдельные каналы для дальнейшей передачи по закрытой IP-сети. Одна программа соответствует одному ТВ-каналу (например, Первый канал, СТС, ТНТ или т.п.).

Подробнее об MPTS см. MPTS.

Отправка потоков по UDP мультикастом.

UDP-потоки (эти самые отдельные каналы) транслируются мультикастом в закрытую IP-сеть.

Подведём итоги:


Вход	телевышки, спутники или кабели одного или нескольких контент-провайдеров
Назначение	1. захват видеопотоков 2. дескремблирование видеопотоков 3. демультиплексирование видеопотоков 4. отправка потоков по UDP мультикастом
Выход	несколько SPTS потоков (один UDP поток для каждого ТВ-канала)

Транскодер¶

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

Транскодирование — самая затратная в вычислительном отношении операция во всём видеотракте. Вопрос в том, что же такое транскодирование? Что понимается под этим термином? Какой смысл в него вкладывается?

Часто понятие транскодирование обобщают настолько, что включают в него практически все манипуляции с потоком, что в корне неверно. Давайте развеем мифы о транскодировании и поймём, что значит этот термин, в каких случаях транскодирование необходимо, а когда без него можно обойтись.

Что такое транскодирование?¶

Итак как мы во Flussonic понимаем транскодирование. Перед тем, как перейти к пониманию понятия транскодирования необходимо ввести понятия кодирования и декодирования.

Кодирование — процесс сжатия "сырых" необработанных данных (например, SDI) с помощью некоторого кодека (например, H.264). Декодирование — процесс обратный кодированию, т.е. это получение необработанных данных из сжатых.

Так транскодирование предполагает декодирование и кодирование. Теперь мы можем дать определение.

Транскодирование — это процесс декодирования данных потока и их последующее кодирование с использованием некоторого кодека. Сначала контент декодируется с помощью кодека, затем над контентом совершаются какие-либо преобразования, и после этого он кодируется с помощью другого кодека либо того же самого, только с другими настройками. Проще говоря, транскодирование подразумевает некоторое изменение самого контента.

Рассмотрим пример. Вы обучаетесь в университете. Ваш научный руководитель попросил вас подкорректировать текст вашей научной статьи, присланной ему ранее. Ваш преподаватель присылает вам сжатый файл формата .rar, в котором находится документ (.docx). Однако внести изменения в текст документа на этом этапе ещё не получится, сначала нужно распаковать этот архив. Напоминает процесс декодирования, не правда ли? Как только Вы внесли необходимые изменения в текст статьи, документ необходимо отправить обратно руководителю на утверждение. Для этого Вы сжимаете Ваш файл (например, в формат .zip), т.е. запаковываете его в архив, и пересылаете его. Подобный принцип лежит и в основе кодирования. Нет разницы в том, какой формат сжатия Вы выбрали: .rar либо любой другой. Самым главным здесь является то, что вы взаимодействовали с самими данными (документом).

Понятие транскодирования покрывает такие процессы как:

Транссайзинг

Изменение размеров видеокадра. Например, уменьшение размеров из 1920×1080 (1080p) в 1280x720.

Трансрейтинг

Изменение битрейта потока без изменения видеоконтента, профиля, контейнера или кодека. Например, 4K-видео может быть преобразовано в один или несколько более низких по битрейту потоков.

Наложение водяных знаков и логотипов
Изменение размера GOP

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

Теперь давайте перейдём к другому процессу, который путают с транскодированием — трансмуксинг или пакетайзинг.

Чем транскодирование отличается от трансмуксинга?¶

Если транскодирование имеет дело с изменением самого контента, то трансмуксинг затрагивает лишь изменение формата медиаконтейнера, или просто контейнера.

Трансмуксинг — это процесс перепаковки потока без изменения самого файла. Таким образом, изменению подвергается только формат медиаконтейнера.

В каком случае транскодирование необходимо?¶

Транскодирование необходимо в случаях:

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

Допустим, что Вы хотите вещать всего лишь один канал с рекламой на STB-приставку (например, реклама в отеле), то в таком случае транскодирование не имеет смысла.

Flussonic Транскодер¶

Входом транскодера являются UDP мультикаст потоки ТВ-каналов. Перейдём к более подробному рассмотрению процесса транскодирования.

Flussonic транскодер осуществляет следующие операции:

Декодирование входного потока данных в "сырые" данные.
Обработка и кодирование "сырых" потоков в соответствии с настроенными параметрами с целью дальнейшей передачи по сети Интернет.

Таким образом, транскодер:

Изменяет параметры видео:
- Кодек
С целью обработки и проигрывания видеопотока на разных устройствах.
- Битрейт
Для приспособления к пропускной способности Интернета зрителей с целью обеспечения наилучшего возможного качества видео. Зависит от качества входного потока.
- Размер входного потока
Для передачи потока на следующий этап наиболее эффективно и с минимальными потерями качества.
Создаёт мульти-битрейтный поток.

При транспортировке HD-каналов по сети Интернет, транскодер сжимает потоки, преобразуя их в несколько качеств: от HD до SD для компенсации перегруженных каналов.

Наложение логотипа поверх видеопотока.

Подробнее о транскодировании, поддерживаемых кодеках и протоколах см.: Транскодирование, Поддерживаемые протоколы и кодеки.

Так мы получаем несколько потоков для одного ТВ-канала. Соотвественно, выходом Flussonic транскодера являются преобразованные для каждого ТВ-канала потоки. Мы настоятельно рекомендуем использовать транспортный протокол M4F во Flussonic для дальнейшей передачи потоков с целью достижения наилучшего результата.

Подводя итог:


Вход	UDP мультикаст потоки
Назначение	1. изменение параметров видео (кодек, битрейт, размер входного потока) 2. создание мульти-битрейтного потока 3. наложение логотипа поверх видеопотока 4. отправка потоков по закрытой IP сети (рекомендуется протокол M4F)
Выход	транскодированные потоки для каждого ТВ-канала

DVR¶

Flussonic Media Server позволяет записывать потоки и хранить их в архиве, а также работать с этим архивом. Эта функциональность называется Digital Video Recording (DVR).

Вход DVR — транскодированные потоки для каждого ТВ-канала, т.е. выход транскодера, поскольку этап DVR следует за транскодированием.

Flussonic Media Server предоставляет широкий спектр возможностей для работы с архивом, например, запись телепередач (для зрителей), т.е. catch-up, вещание в разных часовых зонах/поясах (для провайдеров), т.е. сдвинутое во времени вещание, или таймшифт и т.п.

Подробнее о DVR и его возможностях см. DVR, Запись передач (Catch-up TV), Сдвинутое во времени вещание в разных часовых поясах/зонах (Таймшифт).

Таким образом, выходом Flussonic DVR являются те же преобразованные для каждого ТВ-канала потоки для зрителей live-вещания, а также копии этих самых потоков для пользователей DVR. Никаких преобразований над потоками на этом этапе не совершается.

Следовательно:


Вход	транскодированные потоки для каждого ТВ-канала
Назначение	1. запись и хранение потоков 2. возможность работать с архивом и использовать его возможности (запись телепередач, таймшифт и т. п.)
Выход	1. транскодированные потоки для каждого ТВ-канала (для зрителей live-вещания) 2. копии транскодированных потоков для каждого ТВ-канала (для пользователей DVR)

Рестример¶

Flussonic Media Server Рестример может подключиться к другому Flussonic Media Server (источнику), получить список запущенных и доступных по запросу потоков, а затем раздавать, или рестримить, их. Вы также получаете прозрачный доступ к архиву на источнике.

Flussonic Рестример — это HTTP-сервер, позволяющий вещать контент тысячам зрителей одновременно на различные устройства по различным протоколам. Flussonic Рестример выполняет роль edge-сервера, храня кэш и дополнительно функционируя в качестве DVR (таким образом, нет необходимости в прокси-сервере).

Flussonic Рестример способен осуществлять следующее:

Авторизация зрителя для предоставления доступа к контенту (необходима интеграция с Middleware).
Защита контента с помощью DRM (необходима интеграция со сторонним ПО).
Локальное кэширование и хранение самых просматриваемых видеопотоков с целью предотвращения перегрузки Flussonic Транскодера и DVR.

Осуществляется хранение в локальном архиве на рестримере.
Автоматическая репликации архива.

Репликация предполагает хранение архива на двух и/или более серверах Flussonic. После того, как соединение между основным и вторичным сервером установлено, вторичный сервер сам забирает недостающий поток из основного.

Передача контента через HLS, DASH, MSS и др. протоколы.
Сбор данных сессий зрителя для их последующего анализа.
Передача данных мультикастом (UDP) или юникастом (TCP).

Подробнее о рестриминге и репликации см. Рестриминг и Репликация.

Таким образом:


Вход	1. транскодированные потоки для каждого ТВ-канала (для зрителей live-вещания) 2. копии транскодированных потоков для каждого ТВ-канала (для пользователей DVR)
Назначение	1. вещание контента множеству зрителей 2. авторизация зрителя для предоставления доступа к контенту (необходима интеграция с Middleware) 3. защита контента с помощью DRM (необходима интеграция со сторонним ПО) 4. локальное кэширование и хранение самых просматриваемых видеопотоков с целью предотвращения перегрузки Flussonic Транскодер и DVR 5. передача контента через множество протоколов 6. сбор данных сессий зрителя для последующего анализа
Выход	потоки в HLS, DASH, MSS и др. протоколах

Медиаплееры и приставки¶

Медиаплеер — главное звено для проигрывания контента.

Существует достаточное количество медиаплееров совместимых с широким списком платформ, например, Windows OS, Linux OS, Mac OS, Apple TV, Android и т.п.). Вот несколько примеров мультиплатформенных медиаплееров: Kodi, OTT Player, VLC, Ott-play (by Alex), Telebreeze.

Ниже мы привели таблицу плееров и поддерживаемых ими протоколов проигрывания:

Плееры	Протоколы
Kodi	AirPlay/AirTunes, UPnP, SMB/SAMBA/CIFS, AFP, Zeroconf/Avahi/Bonjour, NFS, HTTP, HTTPS, FTP, RTSP (RTSPU, RTSPT), MMS (MMSU, MMST), Podcasting, TCP, UDP, SFTP, RTP and RTMP (including RTMP, RTMPT, RTMPE, RTMPTE, RTMPS), DHCP, NTP, WebDAV
OTT Player	HLS, RTSP, TS by UDP, RTMP
VLC	HLS, RTMP, DASH, MPEG-TS, RTP/RTSP, ISMA/3GPP PSS, MMS
Ott-play (by Alex)	HLS, HTTP, RTMP
Telebreeze	UDP, TCP, RTP, HLS, HTTP, RTMP (MPEG-TS)

У Flussonic имеется собственный плеер с открытытым исходным кодом — MSE Player, который Вы можете использовать в вашем проекте для достижения низкой задержки видео при его проигрывании. Вы также можете настроить его таким образом, чтобы запретить проигрывание по выбранным протоколам.

Подробнее о Flussonic MSE Player, см. MSE Player.

Выбор плеера зависит от кодеков и протоколов входных потоков.
Вы можете воспользоваться сторонними медиапроигрывателями либо же остановить свой выбор на Flussonic MSE Player.

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

Кодек/ Браузер	MPEG-4 (H.264 format)	HEVC/H.265	HLS	MPEG-DASH	RTSP (and RTMP)
Safari	+	+	+	-	-
Chrome for Android	+	+	+	-	-
Samsung Internet	+	-	+	-	-
UC Browser for Android	~ (частичная поддержка)	-	+	-	-
Android Browser	+	-	+	-	-

Так можно понять какой протокол стоит использовать для передачи потока, чтобы иметь возможность проигрывать его на мобильном устройстве.

STB приставка — маленький компьютер, внутри которого также встроен плеер. Приставка предоставляет большое количество возможностей для организации просмотра контента.

Итак:


Вход	потоки в HLS, DASH, MSS и др. протоколах
Назначение	проигрывание контента
Выход	-

Мы рассмотрели все основные компоненты пайплайна для построения проекта IPTV/OTT, их назначение, функции и возможности.

Пример IPTV/OTT-решения. Сообщение между серверами¶

В данном разделе мы построим с нуля IPTV/OTT-решение для мини-отеля на 100 номеров, используя Flussonic Media Server и его широкий набор функциональных возможностей. Мы рассчитаем количество входящего и выходящего трафика на каждом этапе, а также поймём какая пропускная способность канала связи необходима для успешной реализации такого решения.

Сперва необходимо определиться с набором услуг, который Вы хотите поставлять в рамках Вашего IPTV/OTT-решения (Catch up TV (Телевидение "вслед за эфиром"), Таймшифт (Отложенный просмотр) и т.д.). Мы ожидаем следующее в нашем IPTV/OTT решении:

1) 20 телеканалов: 7 Full HD и 13 SD.

2) Catch up TV.

3) Таймшифт.

4) Источник сигнала: кабель.

5) Мультиплатформенность (ТВ, ноутбуки, смартфоны).

Сначала нам необходимо дать определение некоторым терминам, которые будут встречаться в дальнейшем.
Во Flussonic мы различаем 4 вида передачи потока (см. Рис. 1):

Рис. 1. Виды передачи потока с участием Flussonic Media Server

Захват (с другого сервера)

Flussonic инициирует соединение и захватывает поток.

Приём публикации

Flussonic ожидает соединение и принимает поток.

Отправка (на другой сервер)

Flussonic инициирует соединение и является источником потока.

Проигрывание

Flussonic ожидает соединение и является источником потока.

Flussonic Media Server — это инструмент с широким набором функций, который Вы можете настроить под себя. Он может быть головной станцией, транскодером или рестримером в зависимости от того, каким образом он будет параметризован.

Сначала Вам необходимо определиться с видом ТВ-сигнала, который вы хотите захватить: кабельный, спутниковый, эфирный или их комбинацию.

Этап 1: Захват ТВ-сигнала.

Наш отель будет принимать кабельное телевидение. Значит, нам необходим ТВ-тюнер, или ресивер, который будет принимать сигнал по коаксиальному кабелю.

Мы будем использовать одну из карт Decklink для захвата ТВ-сигнала с ресивера. На входе мы получаем MPTS, в котором 7 Full HD (2 Мбит/с) and 13 SD (1 Мбит/с) каналов. Входной и выходной трафик будет равен:

7 * 2 Мбит/с + 13 * 1 Мбит/с = 27 Мбит/с.

Flussonic поддерживает захват с карт Decklink, DekTec PCIe, Stream Labs, AJA.

Головная станция Flussonic -> Flussonic транскодер¶

Головная станция Flussonic может осуществлять захват сигнала с разных источников, таких как телебашня, спутники и т.д., осуществлять некоторые преобразования и отдавать его по UDP мультикастом в IP-сеть на вход Flussonic Транскодеру. Когда головная станция осуществляет захват, она выступает в качестве инициатора соединения и принимает видеопоток.

В нашем примере головная станция со встроенной картой Decklink захватывает сигнал с ресивера и передаёт его в транскодер. На практике лучше использовать 2 головные станции. Одна будет основной, а вторая — запасной, на тот случай, если основная по каким-либо причинам перестанет работать.

Итак Головная станция Flussonic принимает 27 Мбит/с MPTS и демультиплексирует его, разделяя на отдельные потоки.

Передача мультикаста осуществляется только в рамках локальной сети LAN, соответственно, вещать мультикаст в публичную сеть Интернет вот так просто нельзя. Однако Flussonic может принимать юникаст и мультикаст, а также передавать последний по сети Интернет.

Когда выход головной станции передаётся на вход транскодеру, головная станция инициирует соединение и выступает в роли источника видеопотока. Таким образом, это отправка (на другой сервер). Условимся, что передача данных осуществляется по локальной сети (LAN), если не сказано иначе.

Flussonic транскодер -> Flussonic DVR¶

Flussonic Транскодер находится в ожидании соединения. Как только оно установлено, он принимает видеопоток. Этот вид передачи видео называется приёмом публикации.

Нам необходимо осуществить конвертацию в 4 профиля транскодирования: 7 Full HD (720i) потоков перевести в 720p и 576p, а 13 SD (576i) потоков в 576p и 480p. Таким образом, на вход поступает 27 Мбит/с, а выход рассчитывается по следующей формуле:

7 * (2 Мбит/с + 1 Мбит/с) + 13 * (1 Мбит/с + 1 Мбит/с) = 47 Мбит/с

После некоторых преобразований, которые мы описывали ранее, выход транскодера отправляется на вход Flussonic DVR, поскольку транскодер инициирует соединение и выступает источником видеопотока. Мы рекомендуем осуществлять передачу потоков между транскодером и DVR по нашему внутреннему протоколу M4S.

DVR ожидает соединения и после его установления принимает поток. Соответственно, этот тип передачи потока относится к публикации.

Flussonic DVR -> Flussonic рестример¶

Как мы знаем, DVR хранит копии принятых потоков в своём архиве. На этом этапе Вам необходимо определиться, за какое количество времени Вы хотите хранить копии потоков в архиве (в днях), например, за 3 дня, 5 дней, неделю и т.д. Это значение называется глубиной архива.

Теперь необходимо понять количество дискового пространства архива, которое понадобится для хранения потоков. Считать будем по следующей формуле:

глубина_архива (в секундах) * количество_потоков (одного профиля) * входной_битрейт_потока

Специально для этой цели мы сделали DVR калькулятор, которым Вы можете воспользоваться для простоты вычислений.

Итак, внеся наши данные в калькулятор и произведя необходимые расчёты, мы получаем значение дискового пространства равное 2.07 ТБ.

Больше информации о DVR и его возможностях см. DVR.

Передачу потоков между Flussonic DVR и Flussonic Рестримером мы рекомендуем осуществлять по нашему внутреннему протоколу M4F. Подробнее см.О протоколе M4F.

Flussonic Рестример устанавливает соединение, запрашивая необходимый поток, и после установления соединения между DVR и рестримером принимает поток. Значит, это захват.

Теперь следует подумать о защите контента. Существует несколько способов предотвратить несанкционированный доступ к Вашему контенту. В качестве примера мы рассмотрим интеграцию рестримера с DRM и авторизационным бэкендом.

Интеграция: Flussonic рестример <-> DRM¶

DRM (аббр. от англ. Digital Rights Management) — технические средства защиты авторских прав. DRM используется также для управления доступом к контенту, его модификации, копирования, просмотра и т.д. Эта система защиты позволяет предотвратить несанкционированные действия с контентом.

Подробнее о DRM и его настройке во Flussonic см. DRM.

Как же происходит сообщение между рестримером Flussonic и системой DRM?

1) Как только зритель включает ТВ-канал, Flussonic запрашивает и получает ключ для шифрования контента от сервера ключей и URL этого ключа.

2) Клиент получает шифрованный контент и URL ключа для дешифровки от Flussonic.

3) Сервер ключей получает от клиента запрос на получение ключа для дешифрования и принимает решение отдавать ключ или нет.

4) Плеер затем осуществляет дешифровку и проигрывание контента для зрителя.

Перейдём к авторизационному бэкенду.

Интеграция: Flussonic рестример <-> Авторизационный бэкенд¶

Во Flussonic Media Server реализован механизм идентификации пользователей и отслеживания подключений с помощью авторизационног бэкенда.

Подробнее о том, как работает этот механизм и как его можно настроить см. Авторизация через бэкенд.

В нашем примере мы будем его использовать с целью идентификации гостей отеля и предоставления им услуги IPTV. Для авторизации мы можем использовать, например, информацию о гостях: номер их аппартаментов и их фамилии. Эти данные занесены в базу данных отеля.

Flussonic рестример <-> Медиаплееры¶

Для показа какого-либо ТВ-канала медиаплеер инициирует соединение, запрашивая определённый видеопоток у источника — рестримера. Это пример такого вида передачи видео как проигрывание. Как только плеер получает сигнал, он может быть доступен для просмотра зрителем. Передача данных между рестримером и плеером осуществляется с помощью публичной сети Интернет (Wi-Fi), а не локальной (LAN). Таким образом ваши клиенты имеют возможность осуществлять просмотр телевидения с помощью различных устройств, например, Smart TV или STB-приставка в номере, ноутбук или смартфон на территории отеля, где имеется достаточно стабильное и быстрое интернет-соединение (Wi-Fi).

В качестве плеера мы выбрали Kodi.
Учтите также то, какое количество человек сможет одновременно смотреть один и тот же поток. Представим следующую ситуацию: идёт прямой эфир матча чемпионата мира по футболу и все гости одновременно включают трансляцию. Таким образом, нам необходимо обработать 100 запросов на просмотр одного и того же эфирного ТВ-канала Full HD качества (720p) в один момент. В таком случае нам необходимо рассчитать интернет-трафик, необходимый для бесперебойного проигрывания телеканала:

100 * 2 Мбит/с = 200 Мбит/с.

Значит, скорость интернет-соединенияна территории отеля должна быть не меньше 200 Мбит/с, чтобы гости могли следить за развитием событий по ходу футбольного матча.

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

Масштабируемость и отказоустойчивость¶

Представьте, Вы разрабатываете проект для онлайн-трансляций крупных мероприятий: презентаций новых моделей автомобилей или смартфонов, международных конференций и выступлений с участием известных учёных и исследователей, концертов с многотысячной онлайн-аудиторией и т.п. Естественно, что количество зрителей может исчисляться в тысячах или даже десятках тысяч, причём подключаться они будут практически в один момент, что приведёт к резкому скачку трафика. После окончания мероприятия большинство отключится, что незамедлительно отразится на трафике, а точнее, приведёт к его стремительному упадку. Если мы попытаемся изобразить эту ситуацию на графике, то это будет похоже на американские горки. Так же будет вести себя и нагрузка на сервер. Если не предвидеть такую ситуацию и не предпринять необходимых мер, чтобы её избежать, или хотя бы снизить её влияние, то ваш сервер просто не справится с таким скачком нагрузки и упадёт.

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

Масштабируемость — это способность системы справляться с растущим количеством нагрузки и адаптироваться к новым условиям работы.

Отказоустойчивость — это способность системы сохранять работоспособность при выходе из строя самой системы или её отдельных компонентов.

Flussonic предлагает несколько путей для решения вопросов масштабируемости и отказоустойчивости, например: Кластерный захват, Кластеризация DVR, Кросс-репликация DVR, Ретрансляция потоков, Балансировка нагрузки.

Давайте рассмотрим эти способы более детально.

Flussonic кластерный захват¶

Представим следующую ситуацию: Вам необходимо осуществлять захват некоторого количества потоков с источника, но с одним условием: один поток на один сервер. Таким образом, вам необходимо сформировать некую группу серверов, т.е. кластер для захвата.

Кластерный захват — группа серверов (далее кластер), предназначенная для захвата потоков с источника(ов).

Как он работает и чем полезен?

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

Подробее о кластерном захвате и его настройке во Flussonic см. Кластерный захват.

Flussonic транскодер и DVR-кластер¶

DVR обладает широким спектром услуг для пользователя. В архиве хранятся копии оригинальных потоков. Но что, если это данные архива были частично утрачены? В самом худшем случае — все данные могут быть утеряны или стёрты. Для предотвращения подобного развития событий Вам необходимо сделать запасной DVR. В случаях, когда один сервер по какой-либо причине прекращает работу, Ваши данные не будут утеряны и будут доступны на втором сервере.

Flussonic предлагает несколько решений для резервирования архива и бесшовного переключения на "запасной" сервер в аварийных случаях, когда основной сервер выходит из строя:

Кластеризация DVR

Несколько DVR-серверов объединяются в кластер для оптимизации работы с архивом.

Используется для хранения архива в распределенной среде видеодоставки. Чем полезно?

1) Обеспечивает сохранность и доступность архива.
2) Обеспечивает быструю доставку потоков из архива пользователям и снижение уровня нагрузки на серверы-источники;
3) В условиях геораспределенной доставки контента умеет восстанавливать целостность данных архива на вторичных серверах после потери связи с основным сервером-архивом.

Репликация DVR

Репликация предполагает хранение архива на двух или более серверах Flussonic. Flussonic Media Server позволяет осуществлять автоматическую репликацию архива видеопотоков между серверами. После установления соединения между основным и вторичным серверами вторичный сервер сам забирает недостающие потоки из основного архива.

Репликация DVR — такой способ обеспечения сохранности данных, при котором хранение потоков осуществляется на двух или более серверах таким образом, что все вторичные серверы-архивы копируют данные из основного архива.

Чем полезна репликация DVR?

1) Автовосстановление архива после сбоев и ошибок, копирование архива на другие серверы для надёжности.
2) Отложенное вещание в другом часовом поясе с надёжным автоматическим восстановлением недостающего потока.

Подробнее о Репликация DVR во Flussonic см. Репликация DVR.

Кросс-репликация DVR

Кросс-репликация DVR — такой способ обеспечения сохранности данных, при котором для записи используются сразу два (или более) сервера(ов), которые могут обращаться к источнику напрямую, а также забирать записанный архив друг у друга.

Чем полезна кросс-репликация DVR?

Она обеспечивает непрерывную работу архива при временной недоступности одного из DVR-серверов. Если один из серверов становится недоступным, то второй продолжит вести запись архива, обращаясь к источнику напрямую. После восстановления работы вышедшего из строя сервера на нём автоматически начнётся восполнение недостающих данных путём их передачи со второго сервера.

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

Подробнее о Кросс-репликации DVR во Flussonic см. Кросс-репликация DVR

Flussonic рестример HA кластер¶

Кластерная ретрансляция потоков¶

Кластерная ретрансляция потоков — такой способ сетевой доставки контента до конечного пользователя, при котором формируется кластер из рестримеров.

Flussonic Рестример подключается к Flussonic-источнику для получения списка запущенных и доступных по запросу потоков, а затем рестримить их.

Flussonic Media Server позволяет указать несколько серверов-источников и построить отказоустойчивую конфигурацию.

Подробнее о ретрансляции потоков с помощью кластера см. Ретрансляция потоков.

Балансировка нагрузки¶

Для распределения клиентских запросов между серверами используется балансировщик нагрузки.

Балансировка нагрузки — это процесс распределения запросов клиентов между кластером серверов в соответствии с некоторым алгоритмом.

Подробнее о механизме балансировки во Flussonic см. Балансировка нагрузки.