Руководство по созданию 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-сервиса.

Содержание

1. Введение
2. Типовое решение для стриминговой UGC-платформы
   2.1. Составляющие
   2.1.1. Сервер публикации
   2.1.2. Сервер транскодирования
   2.1.3. DVR-сервер
   2.1.4. Egress-сервер
   2.1.5. Central
   2.2. Процесс доставки от автора до зрителя
   2.3. Методы резервирования и масштабирования сервиса
   2.3.1. Кластер серверов публикации и DNS-балансировка
   2.3.2. Кластер транскодеров с балансировкой нагрузки
   2.3.3. Кластер DVR с репликацией
   2.3.4. CDN
3. Анализ требований
   3.1. Определите нишу
   3.2. Изучите целевую аудиторию
   3.3. Определите контент и профили авторов
   3.4. Определите основные возможности платформы/сервиса
4. Проектирование архитектуры сети
5. Пример разработки стратегии внедрения UGC-сервиса
   5.1. Анализ требований
   5.2. Проектирование архитектуры сети
6. Глоссарий

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Схема 1. Схема типового решения для стриминговой 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-серверу.

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

Читайте также:

• Варианты источников в Flussonic.
• Публикация потока из OBS Studio в Flussonic Media Server.

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

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

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

• Подготовить мультибитрейтный поток.
• Балансировать нагрузку серверов транскодирования.
• Мониторить объём транскодированного трафика.

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

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

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

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

• 1920x1080p,
• 1280x720p,
• 896x504p.

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

Если вы получаете потоки из разных источников сразу, например, браузера, веб-камеры, 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. Изменение кодека, разрешения или битрейта видео сопровождается высоким потреблением ресурсов системы, в отличие от трансмуксинга, или пакетайзинга. Для трансмуксинга не требуется транскодер.

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

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

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

DVR-сервер

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

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

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

• live-to-VOD,
• catch-up,
• таймшифт и др.

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

• Экспорт фрагмента записи архива в виде MP4-файла,
• Скачивание фрагмента записи архива в виде файла MP4 или MPEG-TS.

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

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

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. Составляющие процесса доставки потоков и их функции

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

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

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

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

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

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

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

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

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

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

DVR-сервер:

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

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

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

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

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

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

1. Напрямую.

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

2. Через 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}

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

Разберём как в Flussonic Cloud используется DNS-балансировка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• кросс-репликация,
• Flussonic RAID,
• кэширование сегментов.

CDN

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

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

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

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

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

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

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

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

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

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

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

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

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

Определение ниши очень важно для определения задач стримингового 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. Уточняющие вопросы для определения требований к сети

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

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

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

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

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

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

1. Анализ требований.
2. Проектирование архитектуры сети.

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

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

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

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

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

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

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

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

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

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, чтобы вести запись архива и доставлять контент зрителям.

Авторизация

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

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

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

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

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

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

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

Egress-серверы

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

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

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

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

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

1. При первом запросе MP4-файла с записью онлайн-трансляции файл будет кеширован локально на SSD.
2. Все последующие запросы будут обслуживаться уже с этого SSD, чтобы каждый раз не обращаться к основному хранилищу S3.
3. Если к файлу кеша не обращаются в течение суток, то файл удаляется.
4. Если суммарный объем файлов в кеше превышает 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-адресов на одно доменное имя, что позволяет направлять запросы авторов на разные серверы при обращении к одному и тому же домену.