Руководство по созданию UGC-платформы или сервиса на базе Flussonic¶

Из этого документа вы узнаете, как спроектировать и внедрить UGC-платформу или сервис для стриминга с помощью Flussonic Media Server. Flussonic Media Server — многофункциональный медиасервер для создания высоконагруженных проектов по стримингу видео любого масштаба.
Этот документ предназначен для:

архитекторов ПО,
технических директоров,
продуктовых или проектных менеджеров

компаний, которые хотят построить собственную стриминговую UGC-платформу.
В этом документе не содержится информация об установке или настройке Flussonic Media Server. Информацию об установке Flussonic Media Server и начале работы с ним читайте в разделах Установка и Быстрый старт документации.

Раздел Введение фокусируется на задачах, решаемых Flussonic Media Server для создания стриминговой UGC-платформы, и сферах применения стриминговой UGC-платформы. В разделе Типовое решение для стриминговой UGC-платформы рассматриваются архитектура UGC-платформы, её составляющие, процесс доставка контента до зрителя и методы резервирования и масштабирования для обеспечения надёжности сервиса. Раздел Анализ требований посвящен изучению требований для сервиса или платформы. В разделе Проектирование архитектуры показано как считать пропускную способность сети и что требуется для построения схемы архитектуры сети. Пример реализации решения на базе Flussonic Media Server приведён в разделе Пример разработки стратегии внедрения UGC-сервиса.

Содержание¶

Введение¶

В понятие UGC входят:

трансляции с ультранизкой задержкой менее одной секунды, например, групповые разговоры в Google Meets или Zoom,
трансляции в соцсети с задержкой в пределах нескольких секунд.

Видеостриминговые UGC-платформы используются для потокового вещания разного контента: от прямых трансляций прохождения видеоигр до деловых мероприятий и лекций.

Диапазон сфер применения UGC-платформ ограничивается лишь доступностью Интернета. Они используются в таких сферах, как:

Гейминг. Для вещания прямых трансляций турниров и соревнований по киберспорту, прохождений и обзоров видеоигр.
Спорт. Для организации прямых трансляций и записи турниров, соревнований по разным видам спорта.
Обучение. Для вещания прямых трансляций и записи лекций, семинаров, вебинаров, записи курсов и специализаций.
Религия. Для вещания прямых трансляций и записи богослужений.
Мероприятия. Для вещания презентаций новой модели смартфона, трансляций культурно-массовых мероприятий.

Работа над проектом начинается с определения конечной цели и задач.

Цель проекта — конечный результат, который вы хотите получить, выгодный бизнесу; то, ради чего будет создаваться проект. Пример цели — увеличить доход компании от продаж или снизить издержки.
Задачи проекта — действия, которые необходимо предпринять, чтобы достичь цели.

Flussonic Media Server позволяет решать следующие задачи при создании UGC-сервиса или платформы:

Приём публикаций от авторов контента с максимальным качеством и стабильностью.
Обеспечение использования серверного оборудования при неравномерной нагрузке в зависимости времени суток.
Обеспечение равномерного распределения сетевого трафика между серверами.
Взимание денег с авторов за сервис по ретрансляции и хранению записей.
Запись, хранение и проигрывание зрителям архива трансляции.
Ретрансляция контента в социальные сети.
Обеспечение комфортной среды для общения группы людей в Интернете в формате видео- и аудиоконференций без установки дополнительных приложений.
Взимание денег со зрителей, уплата авторам роялти (royalty).

Определение целей и задач позволяют понять ожидаемый результат и начать проектировать архитектуру решения.

Типовое решение для стриминговой UGC-платформы¶

В этой части вы узнаете:

Ниже представлена схема типового решения для стриминговой UGC-платформы, построенной на Flussonic Media Server:

Схема 1. Схема типового решения для стриминговой UGC-платформы

Устройство UGC-платформы

где:

Publish — сервер публикации,
Transcoder — сервер транскодирования,
DVR — DVR-сервер,
Egress — egress-сервер,
Central — управляющий сервер Flussonic,
Content authors — устройства авторов контента,
Viewers — устройства зрителей.

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

Основные элементы, из которых состоит стриминговый UGC-сервис:

Cервер публикации — сервер, который принимает поток от автора.
Cервер транскодирования — сервер, который преобразовывает входящий поток в поток с несколькими видеодорожками разного разрешения и битрейта. Необязательный компонент.
DVR-сервер — сервер, который принимает входящие потоки, записывает и хранит их, а затем отправляет по запросу. Необязательный компонент.
Egress-сервер — сервер, раздающий контент.
Central — управляющий сервер, обеспечивающий единую точку доступа для управления конфигурацией серверов. Необязательный компонент.
- Авторизационный бэкенд — средство авторизации пользователей.
- Конечная точка config_external — механизм управления конфигурацией потоков.

Сервер публикации¶

Сервер публикации позволяет решать следующие задачи:

Приём публикации от авторов контента с максимально возможным качеством и стабильностью.
Ретрансляция контента в социальные сети.

Flussonic принимает публикации потоков в режиме реального времени по следующим протоколам:

WebRTC
- Не требует установки дополнительного ПО для начала трансляции, что обеспечивает низкий порог входа для авторов. Достаточно браузера и выхода в Интернет.
- Позволяет автоматически подстраивать качество видеоизображения под скорость интернет-соединения с использованием алгоритма адаптивного битрейта (ABR). Чем выше битрейт, тем лучше качество аудио- и видеосигнала для автора.
SRT
- Обеспечивает низкую задержку (latency) и бесперебойность публикации за счёт снижения качества видеоизображения.
RTMP
- Позволяет использовать практически любое оборудование для монтажа видео и opensource-решения.

Сервер публикации переупаковывает входящий поток во внутренний Flussonic-протокол M4S* и отправляет его одному из следующих серверов:

серверу транскодирования,
DVR-серверу,
egress-серверу.

Это зависит от выстроенной архитектуры сервиса и поставленных задач.

Note

M4S — протокол потоковой передачи в реальном времени между серверами Flussonic, обеспечивающий низкую задержку при передаче данных. Этот протокол поддерживает все кодеки Flussonic.

Сервер транскодирования¶

Сервер транскодирования решает задачу подготовки контента для доставки зрителю с максимально возможным качеством.

Чтобы решить эту задачу, требуется следующее:

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

Подготовка мультибитрейтного потока¶

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

Ниже приведены оптимальные профили для доставки контента зрителям:

1920x1080p,
1280x720p,
896x504p.

Выбор профиля для доставки контента зависит также от конечного устройства зрителя. Так для большинства смартфонов оптимальным профилем качества является 896x504p, а для ТВ — 1920x1080p. Транскодер может как понизить, так и повысить разрешение потока для доставки зрителям. Например, автор публикует поток в разрешении 720p, а транскодер увеличивает разрешение до 1080p для доставки зрителям.

Note

Чем выше разрешение и битрейт потока, тем больше задержка сигнала.

Если вы получаете потоки из разных источников сразу, например, браузера, веб-камеры, OBS или видеоэнкодера по протоколам WebRTC, RTMP и SRT, то транскодируйте эти потоки, а не переупаковывайте их. Видеостриминговые протоколы WebRTC, RTMP и SRT поддерживают разные и не до конца совместимые кодеки.

Транскодер вносит следующие задержки:

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

Балансировка нагрузки серверов транскодирования¶

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

Мониторинг объёма транскодированного трафика¶

Объём транскодированного трафика — это сумма битрейтов дорожек в профиле. Имея это значение, можно определить, во сколько вам обойдётся транскодирование для каждого автора.

В зависимости от битрейта исходного потока можно использовать комбинацию профилей. Например, если исходный поток 1920x1080p имеет битрейт 5 Мбит/с, то рекомендуемыми профилями являются 1920x1080p при 4 Мбит/с, 1280x720p при 2 Мбит/с и 896x504p при 900 Кбит/с. Тогда объемы транскодированного трафика составляют:

Для 1920x1080p: 4000 Кбит/с + 192 Кбит/с = 4192 Кбит/с
Для 1280x720p: 2000 Мбит/с + 128 Кбит/с = 2128 Кбит/с
Для 896x504p: 900 Кбит/с + 96 Кбит/с = 996 Кбит/с

Для транскодирования используются специализированные выделенные устройства, центральный процессор или видеокарта: внешняя или встроенная в процессор. В Flussonic Media Server есть встроенный транскодер. Он поддерживает транскодирование на графическом процессоре GPU и с использованием центрального процессора CPU. Для транскодирования вы можете использовать медиасервер или Flussonic Coder.

Транскодирование — вычислительно дорогой процесс, создающий большую нагрузку на CPU и GPU. Изменение кодека, разрешения или битрейта видео сопровождается высоким потреблением ресурсов системы, в отличие от трансмуксинга, или пакетайзинга. Для трансмуксинга не требуется транскодер.

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

Note

Если вам необходима консультация и профессиональная помощь в подборе оборудования для транскодирования, обратитесь в нашу службу технической поддержки support@flussonic.com.

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

DVR-сервер¶

DVR-сервер решает задачу записи и хранения архива трансляций.

С использованием DVR-сервера у ваших зрителей появляется возможность ставить на паузу, перематывать назад и вперёд, пересматривать и смотреть прямой эфир в записи.

Flussonic Media Server предоставляет инструменты для работы с архивом, например:

Flussonic Media Server умеет работать как с локальными, так и с облачными хранилищами. Он может загружать записи в облачное хранилище и выгружать их. В качестве места для выгрузки архива можно указать как каталог на сервере Flussonic, так и, например, бакет Amazon S3. Кроме того, Flussonic Media Server позволяет экспортировать фрагменты архива в формате MP4-файлов.
Подробнее об экспорте фрагментов архива в формате MP4-файлов см.:

Чтобы снизить нагрузку на хранилище и ускорить раздачу VOD-контента, настройте кэширование на SSD.

Подробнее о DVR и его возможностях см. DVR.

Note

Если вам необходима квалифицированная помощь по организации распределенного DVR-сервиса, обратитесь в нашу службу технической поддержки support@flussonic.com.

Egress-сервер¶

Egress-сервер позволяет решать задачи:

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

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

Создать ощущение живого общения между участниками беседы за счёт задержки в пределах одной секунды.
Автоматически подстраивать качество видеоизображения под скорость интернет-соединения благодаря алгоритму адаптивного битрейта (ABR). Это даёт возможность расширить аудиторию приватных чатов и смотреть трансляцию зрителям с нестабильным или медленным интернет-соединением.
Смотреть трансляцию на любом устройстве.
Не использовать дополнительное ПО. Достаточно браузера и выхода в Интернет.

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

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

Egress-сервер забирает потоки с одного из следующих серверов:

сервера транскодирования,
DVR-сервера,
сервера публикации.

Затем egress-сервер доставляет контент зрителям напрямую либо через сторонний сервис CDN. Это зависит от поставленных задач и выстроенной архитектуры сети.

Подробнее см. Отправка потоков на другие серверы.

Чтобы показывать зрителям контент, вы можете использовать веб-плеер Flussonic и вставить его на свой сайт. Чтобы интегрировать плеер с вашим веб-сайтом, используйте Flussonic Streaming API.

Central¶

Central помогает решать такие задачи, как:

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

Central выполняет роль управляющего сервера, обеспечивая единую точку доступа для:

управления конфигурацией серверов в процессе доставки контента,
аутентификации и авторизации авторов и зрителей.

Central позволяет сделать доступной всю конфигурацию со всех серверов в процессе доставки видео. Не требуется настраивать конфигурацию для каждого сервера вручную. Взаимодействие между Central и другими серверами осуществляется с помощью внутреннего механизма Flussonic — config_external.

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

Flussonic предоставляет API для взаимодействия с Central — Flussonic Central API.

Авторизацию авторов можно настроить напрямую во Flussonic либо с помощью внешнего бэкенда, к которому будет обращаться сервер Flussonic.

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

Авторизация по паролю при публикации потока: система проверяет пароль при публикации потока.
passphrase для защиты публикации по SRT: система проверяет пароль при публикации потока по SRT.
Конфигуратор бэкендов: с его помощью можно создавать авторизационные бэкенды в файле конфигурации без написания скриптов.
passphrase для защиты проигрывания по SRT: система проверяет пароль при проигрывании потока по SRT.

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

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

Flussonic также предоставляет API для работы с авторизационным бэкендом — Flussonic Authorization Backend API.

Для вашего удобства мы свели всю информацию о составляющих и их функциях в Табл.1:

Табл.1. Составляющие процесса доставки потоков и их функции

Составляющая	Функции
Сервер публикации	- приём видеопотоков, - ретрансляция на другие стриминговые площадки и в социальные сети
Сервер транскодирования	- изменение параметров видео и аудио (кодек, битрейт, разрешение), - создание мультибитрейтного потока
DVR-сервер	- запись и хранение потоков, - возможность работать с архивом и использовать его возможности (запись прямого эфира, перемотка вперёд и назад и т.п.), - проигрывание потоков из архива (перемотка, просмотр текущей трансляции с начала)
Egress-сервер	доставка до зрителей: - транскодированных потоков для зрителей live-вещания, - копий транскодированных потоков для пользователей DVR
Central	- управление конфигурацией серверов в процессе доставки контента, - аутентификация и авторизация авторов и зрителей, - балансировка нагрузки между серверами

Процесс доставки контента от автора до зрителя¶

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

Для этого мы снова обратимся к схеме типового решения для стриминговой UGC-платформы:

Устройство UGC-платформы

Направление чёрных стрелок на схеме указывает направление передачи потоков, а розовых — направление отправки запросов.

1. Автор <-> Сервер публикации <-> Central¶

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

Чтобы начать трансляцию, автору необходимо авторизоваться и инициировать публикацию потока на сервер публикации по SRT, WebRTC (WHIP) или RTMP в зависимости от источника. Вот как происходит публикация потока автором:

Запрос автора уходит DNS-серверу.
DNS-сервер перенаправляет запрос на адрес одного из доступных серверов публикации в кластере. Подробнее о DNS-балансировке см. ниже.
Сервер публикации отправляет запрос Central для авторизации автора.
Как только сервер публикации получает положительный ответ, он запрашивает конфигурацию для потока у Central.
Central возвращает необходимую конфигурацию серверу публикации.
Автор публикует поток.

2. Сервер публикации -> Central -> Сервер транскодирования¶

Транскодирование

Сервер публикации перепаковывает входящий поток в собственный Flussonic-to-Flussonic протокол M4S и отправляет его кластеру серверов транскодирования.
Балансировщик нагрузки Central с учётом состояния и загрузки серверов направляет поток серверу с наименьшей загрузкой.
Сервер транскодирования получает M4S-поток, распаковывает и декодирует его, получая необработанное видео и аудио.
Транскодер преобразует поток в поток с несколькими видеодорожками, адаптированными под разные разрешения и битрейт.

Note

Особенность Flussonic – переупаковка потоков. При получении потока Flussonic Media Server распаковывает поток и снова запаковывает. Так стабильность выходного потока повышается.

3. Сервер транскодирования -> Central <-> DVR-сервер¶

DVR

DVR-сервер:

Запрашивает конфигурацию потока у Central.
Захватывает M4S-потоки у сервера транскодирования.
Записывает потоки и хранит копии этих потоков.

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

4. DVR-сервер <-> Central <-> Egress-сервер <-> Зрители¶

Доставка зрителям

Перед началом просмотра трансляции зрители проходят аутентификацию и авторизацию.

Зритель заходит на сайт со своего устройства и вводит свои имя пользователя и пароль.
Запрос на аутентификацию отправляется серверу Central.
Central проверяет зрителя и аутентифицирует его.
После успешной аутентификации зритель отправляет запрос балансировщику нагрузки Central.
Central перенаправляет запрос на минимально загруженный и доступный egress-сервер в кластере.
Egress-сервер посылает запрос серверу Central для авторизации зрителя.
Central проверяет права зрителя и либо разрешает, либо запрещает ему проигрывать поток.
На основе полученного ответа egress-сервер либо отправляет поток зрителю, либо нет.

В зависимости от того, прямой это эфир или запись, доставка потоков до зрителей может осуществляться с egress-серверов одним из двух способов:

Напрямую.

Когда зрители запрашивают трансляцию в прямом эфире через браузер или мобильное устройство, то доставка потока осуществляется через WebRTC и MSE-LD. WebRTC и MSE-LD обеспечивают минимальную задержку при проигрывании потока.
Через CDN.

Когда зрители запрашивают трансляцию в записи через браузер или мобильное устройство, то доставка потока осуществляется через HLS и MPEG-DASH через CDN. CDN позволяет ускорить доставку контента до зрителя, а также снизить затраты на каналы связи и оптимизировать нагрузку на серверы.

Методы резервирования и масштабирования сервиса¶

В этом разделе приведены методы обеспечения надёжности и отказоустойчивости системы на этапе проектирования архитектуры сервиса. Надёжный сервис должен отвечать следующим требованиям:

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

Кластер серверов публикации и DNS-балансировка¶

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

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

Чтобы вы могли оказывать отказоустойчивый сервис при публикации потоков по протоколам SRT и RTMP, не поддерживаемым на прикладном уровне (application layer), используйте DNS-балансировку. Для балансировки публикаций по WebRTC (WHIP) используйте встроенный балансировщик Flussonic.

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

При DNS-балансировке сервер, на который будет отправлен запрос, выбирается на основе определённого алгоритма, например, round robin. Узнать адрес сервера, на который необходимо направить запрос автора, можно разными способами: запросить через API (рекомендуется) или вернуть подходящий сетевыми средствами. Это зависит от структуры вашей сети.

Однако у DNS есть существенный минус — он не учитывает статус загрузки серверов в кластере. По этой причине авторы могут быть перенаправлены на сервер, который в данный момент может быть перегружен или выключен.

Нужно также учитывать, что:

DNS кешируется до трёх дней. Если в кэше окажутся серверы, которые выключены или находятся в закрытой сети, то таймаут подключения может быть очень долгим.
В RTMP не встроен механизм редиректов. Временные решения, сделанные для обхода, не работают. Load balancing with WHIP publications {#live-webrtc-publish-load_balancing}

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

Рассмотрим использование DNS-балансировки на примере облачной платформы, которая предоставляет UGC-сервис для реализации различных проектов.

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

Так вы получаете:

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

Кластер транскодеров с балансировкой нагрузки¶

Аварийные ситуации в работе сервера транскодирования могут привести к остановке или прекращению работы вашего сервиса. Чтобы этого избежать:

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

В нашей схеме используется кластеризация с балансировкой нагрузки через Central.

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

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

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

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

Кластер DVR с репликацией¶

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

Репликация позволяет копировать архив на другие серверы для:

обеспечения надёжности,
автовосстановления после сбоев.

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

Основной сервер захватывает и хранит потоки из источника.
Вторичный сервер захватывает потоки из основного сервера (см. схему).

Flussonic предоставляет и другие инструменты для резервного копирования архива DVR и обеспечения его доступности:

CDN¶

С увеличением числа зрителей и объёма выходного трафика egress-сервер в какой-то момент перестанет справляться с доставкой потоков в одиночку. По мере расширения зоны распространения контента системе станет всё сложнее предоставлять зрителям качественный сервис.

CDN (сеть доставки контента) даёт возможность:

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

Имея множество серверов, распределённых по различным географическим точкам, CDN:

Сокращает расстояние между egress-сервером и зрителем.
Минимизирует задержку.
Обеспечивает быстрый доступ к контенту.
Разгружает egress-сервер, поддерживая его работоспособность.

Чтобы обеспечить эффективную доставку контента по всему миру, CDN использует следующие методы:

Кэширует контент в различных PoP (point of presence, точка присутствия).
Распределяет рабочую нагрузку на несколько серверов.

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

Анализ требований¶

Чтобы определить требования:

Определитесь с нишей.
Изучите целевую аудиторию.
Определите контент и его авторов.
Определите основные возможности платформы или сервиса, изучив представленные на рынке.

Определите нишу¶

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

Определение ниши очень важно для определения задач стримингового UGC-сервиса или платформы, изучения целевой аудитории, выработки стратегии развития и дальнейшей работы. Изучите рынок, посмотрите что предлагают конкуренты.

Изучите целевую аудиторию¶

Определите, кто ваша целевая аудитория и что она хочет. Ответьте на такие вопросы, как:

Что объединяет вашу аудиторию?
С какой целью аудитория смотрит контент (образование, развлечения, спорт и др.)?
Какие устройства используют зрители для просмотра контента (ПК, смартфон на базе Android или iOS и др.)?
Какое примерное число одновременных подключений зрителей должен выдерживать ваш сервис или платформа?

Это даст вам понимание вашей аудитории и того, что она ожидает от вашего сервиса или платформы.

Например, целевой аудитории игровой индустрии интересны: видеоигры, их обзоры и прохождения, киберсоревнования и др. Зрители обычно смотрят такой контент на различных устройствах: ПК, ноутбуках, смартфонах (Android, iOS), планшетах. Это пример развлекательного контента, который смотрят сотни тысяч зрителей.

Определите контент и профили авторов¶

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

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

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

Определите основные возможности платформы или сервиса¶

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

Ниже перечислены некоторые возможности стриминговых UGC-платформ:

авторам: проведение трансляций с помощью разных устройств, таких как VMix, OBS, Atemi, HDMI-RTMP конвертер, пульт видеомонтажа и браузеров;
зрителям: просмотр контента с любого устройства, например, ПК, смартфон на базе Android или iOS, ноутбук;
запись, хранение и проигрывание онлайн-трансляций;
одновременная трансляция в социальные сети и на другие платформы, например, YouTube, VK, Одноклассники, RUTUBE, Twitch;
непрерывное и стабильное проигрывание контента;
загрузка предварительно записанных потоков;
онлайн-трансляции с минимальной задержкой: трансляция с задержкой, которой достаточно, чтобы отреагировать на чат, но недостаточно, чтобы общаться со зрителями в прямом эфире;
встроенный медиаплеер;
система авторизации;
система подписок и др.

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

Проектирование архитектуры сети¶

Эта часть посвящена:

Оценке необходимой пропускной способности сети на входе и на выходе для сервера публикации, сервера транскодирования, DVR-сервера, egress-сервера.
Построению схемы архитектуры сети.

Чтобы посчитать необходимую пропускную способность сети на входе и на выходе и построить схему архитектуры сети, ответьте на следующие вопросы:

Табл.2. Уточняющие вопросы для определения требований к сети

Тема	Вопросы
Источник (вход)	1) Какой тип источника сигнала (камера, программный энкодер, аппаратный энкодер, браузер)? 2) Какие характеристики входного потока (кодек, битрейт, разрешение, кадры в секунду (FPS))? 3) Какой протокол передачи видео от источника (RTMP, SRT, WebRTC и т.д.)? 4) Какое общее число входящих потоков с источника?
Транскодер	1) Какие профили выходного видеопотока (кодек, битрейт, разрешение)? 2) Какое общее число выходных потоков для раздачи? 3) Необходимо ли транскодирование звука? Если да, то какие профили выходного аудиопотока (кодек, битрейт)? (Например, Opus (WebRTC) -> AAC (HLS, DASH))
DVR архив (запись и хранение)	1) Есть ли необходимость в записи потоков? Если да, то как вы планируете использовать DVR (запись потоков для экспорта в VOD, запись с возможностью просмотра зрителями (catch-up) и т.д.)? 2) Какая требуется глубина архива (день, неделя, месяц)? 3) Куда будет записываться архив (в облако, на диск, RAID)?
Egress-сервер (выход)	1) Какие типы конечных устройств (мобильные устройства, ПК и т.д.)? 2) Какой протокол раздачи видео (HLS, MPEG-DASH, WebRTC и т.д.)? 3) Какое предполагаемое число зрителей? 4) Планируется ли раздача контента своими мощностями или с помощью сторонних CDN (Akamai и др.)?
Безопасность и защита	1) Необходима ли авторизация зрителей? Если да, то какими средствами: внешний бэкенд или внутренние инструменты Flussonic? 2) Необходимо ли шифрование контента (DRM)?
Другие требования	1) Планируются ли аудиодорожки с разными языками? 2) Нужен ли дополнительный контроль каких-либо параметров видео? и т.д.

Чтобы посчитать пропускную способность сети, используйте следующую формулу:

число потоков * (битрейт видео + битрейт аудио)

На основе полученных ответов на вопросы из Табл.2, вы можете определить число серверов публикации, серверов транскодирования, DVR-серверов, egress-серверов и построить схему.

Затем переходите к настройке и конфигурации серверов.

Пример разработки стратегии внедрения UGC-сервиса¶

Эта глава посвящена разработке стратегии для небольшого UGC-сервиса — платформы для трансляции мероприятий. Следуйте шагам ниже:

Warning

Эта глава не предполагает предоставление какого-либо программного кода или конфигурации Flussonic Media Server для этого проекта.

Анализ требований¶

Допустим, вы хотите создать платформу для трансляции мероприятий.
Цель проекта — снизить издержки компании на текущий сервис.

Ниша: организация вещания мероприятий.
Целевая аудитория: небольшие и крупные компании.
Тип контента: виртуальные конференции и саммиты, вебинары, онлайн-семинары, виртуальные корпоративные мероприятия, конференции.
Возможности сервиса:
- Поддерживать VMix, OBS.
- Записывать прямые трансляции и сохранять их, чтобы зрители могли посмотреть их позже.
- Обеспечивать отказоустойчивость и резервное копирование для поддержания работоспособности сервиса в случае возникновения каких-либо трудностей.
- Обеспечить, чтобы зрители с медленным интернет-соединением могли смотреть трансляции.
- Эффективно управлять доступными ресурсами при неравномерной загрузке сервера.
- Делать просмотр контента доступным с любого мобильного устройства и браузера.
- Предоставлять статистику производительности системы.
- Заниматься аутентификацией и авторизацией зрителей и авторов.

Проектирование архитектуры сети¶

Вы ответили на вопросы из Табл. 2 следующим образом:

Тема	Описание
Источник (вход)	1) Тип источника: аппаратный энкодер на пультовой либо программный энкодер типа vMix. 2) Характеристики потоков: H.264, 5000 кб/с, 1920х1080p, 25 кадров в секунду. 3) Протоколы: RTMP или SRT. 4) Число потоков на входе: до 10.
Транскодер	1) Транскодирование в три профиля: 1080p, 720p, 360p. 2) Число потоков на выходе: до 30.
DVR архив (запись и хранение)	1) Требуется запись и хранение архива. У зрителей будет возможность посмотреть запись мероприятия когда и где они захотят, а также скачать запись на своё устройство. 2) До 10 часов на все 10 потоков в отдельном ЦОД. Также нужен экспорт записей архива в формате MP4-файлов. 3) Записи трансляций хранятся в облачном хранилище S3.
Egress-сервер (выход)	1) Тип конечных устройств: ПК и мобильные устройства. 2) Протокол раздачи: HLS. 3) Число зрителей: до 100 тыс. 4) Раздача через CDN Akamai.
Безопасность и защита	1) Необходима авторизация пользователей. 2) Шифрование контента не требуется.
Другие требования	1) Необходима интеграция по API, чтобы автоматизировать создание потоков.

Чтобы вычислить пропускную способность сети, воспользуемся следующей формулой:

число потоков * (битрейт видео + битрейт аудио)

Для сети рассчитаем следующие параметры:

пропускная способность сети на входе:

10 потоков * (5000 + 192)Кбит/с ≈ 52 Мбит/с

пропускная способность сети на выходе транскодера. При транскодировании десяти Full HD (1080p, 5000 Кбит/с, H.264) потоков в три профиля:
- Full HD (1080p), H.264, 4000 Кбит/с; AAC, 192 Кбит/с;
- HD (720p), H.264, 2000 Кбит/с; AAC, 128 Кбит/с;
- SD (360p), H.264, 1000 Кбит/с; AAC, 96 Кбит/с.
Получаем:

30 * (4000 + 2000 + 1000 + 192 + 128 + 96)Кбит/с ≈ 223 Мбит/с
пропускная способность сети на выходе для раздачи. Берём максимальное количество зрителей (100 тыс.) и самое высокое качество потока (Full HD):

100,000 * (4,000 + 192)Кбит/с ≈ 420 Гбит/с

На основе полученных ответов составим схему сети:

Схема 3. Схема архитектуры сети для платформы трансляции онлайн-мероприятий

Схема сети платформы для платформы трансляции онлайн-мероприятий

Для реализации проекта понадобится четыре сервера Flussonic:

Transcoding server №1 и transcoding server №2, чтобы принимать публикации и транскодировать видео.
Egress server №1 и Egress server №2, чтобы вести запись архива и доставлять контент зрителям.

Авторизация¶

Для авторизации зрителей в платформе используется авторизация по токену:

Внешняя система генерирует персональный токен для каждого зрителя, чтобы у зрителя не было возможности передавать его другим.
Затем Flussonic сверяет токен с IP-адресом и некоторыми другими параметрами.

Этот метод отлично подходит для закрытых мероприятий.

Серверы транскодирования¶

В нашей схеме серверы transcoding server №1 и №2 занимаются приёмом публикации по RTMP и SRT и транскодированием.

Transcoding server №1 будет основным, а transcoding server №2 — резервным. Так мы можем реализовать следующие сценарии:

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

Egress-серверы¶

Egress server №1 и egress server №2 выполняют следующие задачи:

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

Для записи и хранения архива:

Egress server №1 и egress server №2 захватывают M4S-потоки с сервера транскодирования и записывают онлайн-трансляции.
После окончания мероприятия Flussonic выгружает записи в формате MP4-файлов в облачное хранилище S3, чтобы зрители могли посмотреть трансляцию мероприятия в записи.

Чтобы ускорить доставку VOD-контента, используем кеширование на SSD. Это будет работать следующим образом:

При первом запросе MP4-файла с записью онлайн-трансляции файл будет кеширован локально на SSD.
Все последующие запросы будут обслуживаться уже с этого SSD, чтобы каждый раз не обращаться к основному хранилищу S3.
Если к файлу кеша не обращаются в течение суток, то файл удаляется.
Если суммарный объем файлов в кеше превышает 100 Гб, то Flussonic удаляет файлы из кеша, начиная с самого старого.

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

Для массовых мероприятий используется CDN Akamai с балансировщиком на стороне CDN Akamai. CDN Akamai захватывает контент из egress server №1 и egress server №2 по протоколам HLS и LL-HLS.
Для камерных мероприятий используется балансировщик Flussonic с распределением между двумя egress-серверами. В таком случае egress server №1 выступает также в качестве балансировщика нагрузки.

Раздача контента осуществляется по протоколам HLS и LL-HLS:

LL-HLS — для доставки трансляций в режиме реального времени,
HLS — для записей трансляций.

Глоссарий¶

User-generated Content (UGC)

Пользовательский контент, т.е. любая форма контента, например, видео, аудио или фото, созданная людьми и опубликованная в Интернете.

UGC-платформа

SaaS (англ. software-as-a-service — программное обеспечение как услуга), которое используется для сбора и управления пользовательским контентом. UGC-платформа соединяет автора и зрителя через контент. Особенность UGC-платформы состоит в том, что она использует авторов для производства контента, в отличие от IPTV/OTT-платформ, которые сами являются провайдерами контента.

Сервер публикации

Сервер, который принимает поток от автора.

Сервер транскодирования

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

DVR-сервер

Сервер, который принимает входящие потоки, записывает и хранит их, а затем отправляет по запросу.

Egress-сервер

Сервер, раздающий контент.

Кластер

Группа серверов, работающих вместе для выполнения общих задач.

DNS-балансировка

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