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

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

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

Содержание

1. Введение в UGC-платформы
2. Базовая архитектура UGC-платформы
   2.1. Составляющие
   2.1.1. Сервер публикации
   2.1.2. Сервер транскодирования (необязательно)
   2.1.3. DVR-сервер (необязательно)
   2.1.4. Origin-сервер
   2.1.5. Контрольная панель автора
   2.1.6. Контрольная панель зрителя
3. Процесс доставки до зрителя
4. Делаем надёжный сервис
   4.1. Несколько точек публикации
   4.2. Кластер транскодирования с балансировкой нагрузки
   4.3. Кластер DVR
   4.4. CDN
5. Анализируем и запускаем: реальный пример
   5.1. Этап анализа
   5.1.1. Шаг 1. Определяем нишу
   5.1.2. Шаг 2. Определяем целевую аудиторию
   5.1.3. Шаг 3. Определяем вид контента и профили авторов
   5.1.4. Шаг 4. Определяем основные возможности платформы/сервиса
   5.2. Этап составления технических требований
   5.2.1. Сеть
   5.2.2. Контрольная панель автора
   5.2.3. Контрольная панель зрителя
   5.2.4. Сервер(ы) захвата
   5.2.5. Сервер(ы) транскодирования
   5.2.6. Сервер(ы) DVR
   5.2.7. Origin-сервер(ы)

Введение в UGC-платформы

User-generated Content (UGC) — это пользовательский контент, т.е. любая форма контента (видео, аудио, фото, посты, отзывы и т.д.), созданная людьми и опубликованная в Интернете.

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

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

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

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

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

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

Вот некоторые из возможностей, которые платформы/сервисы UGC предлагают своим клиентам:

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

Базовая архитектура UGC-платформы

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

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

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

Схема 1. Пример схемы устройства UGC-платформы.

Сначала рассмотрим основные составляющие UGC-платформ и зачем же они нужны.

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

Основные элементы, использующиеся для построения UGC-платформ:

• сервер публикации,
• сервер транскодирования (необязательно),
• DVR-сервер (необязательно),
• origin-сервер,
• контрольная панель автора,
• контрольная панель зрителя.

Далее мы разберём каждый из них подробнее.

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

Сервер публикации необходим для приема потока из любого ПО трансляции или веб-браузера. Сервер публикации принимает поток от источника и передаёт его либо серверу транскодирования (при необходимости), либо origin-серверу.

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

Flussonic Media Server может принимать потоки с разными кодеками и контейнерами. Подробнее о вариантах источников и способу их настройки во Flussonic см.: Варианты источников.

О том, как отправить поток из OBS во Flussonic см. Публикация из OBS Studio в Flussonic Media Server.

Для наглядности мы свели всю информацию в таблицу ниже:

Сервер транскодирования (необязательно)

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

Давайте разберемся, что такое транскодирование и что им не является.

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

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

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

Транскодирование — это изменение видео- и/или аудиокодека (типа сжатия). Например, вы можете взять видео MPEG2 и преобразовать его в видео H.264.

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

Транссайзинг — это изменения размера видеокадра или разрешения видео. Например, уменьшение разрешения 3840×2160 (4K) до 1920×1080p и/или 1280×720p, 640×480p и т.д.

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

Трансрейтинг — это процесс понижения битрейта потока. Например, видео 4K со скоростью 45 Мбит/с можно преобразовать в один или несколько потоков с более низким битрейтом: 4K со скоростью 15 Мбит/с, Full HD (1080p) со скоростью 5 Мбит/с, HD (720p) со скоростью 2 Мбит/с, 480p со скоростью 1 Мбит/с и т. д.

Схема 2. Пример транскодирования.

После сжатия видео- и аудиопотоки упаковываются в контейнер — обёртку, в которой хранится видеопоток, аудиопоток и метаданные (битрейт, разрешение, субтитры и т.д.). На этом этапе получается видеофайл, который в дальнейшем может быть передан по протоколу доставки, например, HLS, MPEG-DASH и т.д.

Процесс изменения контейнера и протокола доставки без изменения видео- и/или аудиоконтента называется трансмуксингом (также называемый пакетайзинг, перепаковка). Получение RTMP-потока от IP-камеры и преобразование его в HLS-поток для проигрывания является примером трансмуксинга.

Транскодирование ≠ трансмуксинг, поскольку они работают на разных уровнях (транскодирование — на уровне контента/данных, трансмуксинг — на уровне контейнера и протокола доставки) и не должны вызывать путаницу.

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

Предположим, вы хотите вещать киберспортивное мероприятие онлайн в прямом эфире в разрешении 4K со скоростью 45 Мбит/с через SRT с использованием кодека H.264. Если вы попробуете доставить такой поток до зрителей напрямую, то у них возникнут трудности с подключением к трансляции и воспроизведением такого контента. Вот почему:

• Не все устройства поддерживают разрешение 4K. Некоторые экраны не поддерживают разрешение 4K, что приводит к невозможности воспроизведения контента.
• Недостаточная пропускная способность сети для 4K. При нестабильном интернет-соединении пакеты данных 4K могут загружаться очень долго либо вообще не загружаться, что приведёт к бесконечной буферизации плеером.

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

С помощью Flussonic вы можете провести все необходимые операции по транскодированию и трансмуксингу, т.е. преобразованию видео- и аудиопотоков.

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

Тогда:

DVR-сервер (необязательно)

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

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

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

DVR — необязательный элемент UGC-платформы. Если вы не планируете предоставлять какие-либо услуги по записи и хранению онлайн-трансляций, то вы можете обойтись и без DVR. Однако сложно представить современный UGC-сервис без функций перемотки трансляции.

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

Origin-сервер

Origin-сервер (также сервер-источник) осуществляет доставку контента прямиком до зрителей. Сервер-источник забирает потоки у сервера транскодирования (если есть) или сервера публикации и осуществляет их передачу до зрителя.

Получается:

Контрольная панель автора

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

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

Резюмируя вышесказанное:

Контрольная панель зрителя

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

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

Тогда:

От автора до зрителя

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

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

1. Автор <-> Контрольная панель автора

Между автором и контрольной панелью автора устанавливается двунаправленная связь типа "запрос-ответ". Сообщение между ними происходит следующим образом:

1. Запрос URL и ключа трансляции

Перед началом трансляции автору необходимо настроить программное обеспечение для трансляции. Чтобы завершить настройку, автору необходимо получить URL и ключ трансляции, которые дают программному обеспечению знать, куда отправлять контент (точка публикации). Запрашивает URL и ключ трансляции автор у контрольной панели автора.

1. Сохранение конфигурации потока

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

1. Предоставление URL и ключа трансляции

Затем контрольная панель возвращает автору URL и ключа трансляции для получения доступа к точке публикации.

2. Контрольная панель автора <-> Сервер публикации

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

3. Автор -> Программное обеспечение для трансляций

Затем автор предоставляет URL и ключ трансляции программному обеспечению для потокового вещания или браузеру, чтобы начать трансляцию.

4. Программное обеспечение или веб-браузер -> Сервер публикации

Когда настройка программного обеспечения завершена, автор может начать трансляцию. Автор запускает трансляцию и поток отправляется на сервер публикации через WebRTC (для браузеров), RTMP или SRT (для программного обеспечения для трансляций).

5. Сервер публикации -> Сервер транскодирования (необязательно)

Сервер публикации позволяет осуществлять многопоточную трансляцию в социальные сети и на другие платформы, такие как YouTube, LinkedIn и т.д.

Сервер публикации перепаковывает входящий поток в собственный Flussonic-to-Flussonic M4S-протокол и направляет поток на транскодер, DVR или origin-сервер, в зависимости от пайплайна.

6. Сервер транскодирования -> DVR-сервер (необязательно)

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

DVR-сервер захватывает M4S-потоки от сервера транскодирования и хранит копии этих потоков.

7. DVR-сервер -> Origin-сервер (необязательно)

Origin-сервер захватывает M4S-потоки с DVR-сервера и доставляет их зрителям.

8. Зритель <-> Контрольная панель зрителя

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

1. Запрос URL для просмотра потока

Для просмотра потока зрителю необходим URL. Поэтому зритель запрашивает эту информацию у контрольной панели автора.

1. Возврат URL

Когда URL воспроизведения создан, контрольная панель зрителя возвращает его зрителю.

9. Контрольная панель зрителя -> Контрольная панель автора

Контрольная панель зрителя запрашивает ключ сессии (PLAY_KEY) из базы данных управления системой в контрольной панели автора для создания URL потока для проигрывания.

10. Плееры, веб-браузеры <-> Origin-сервер

Наконец, origin-сервер доставляет потоки зрителям. В зависимости от приложения, зритель может открыть URL в браузере или медиаплеере.

Делаем надёжный сервис

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

Несколько точек публикации

Обеспечение надёжности работы системы при приёме публикации потоков мы называем резервированием точек публикации.

Резервирование точек публикации предполагает выделение отдельного пула серверов для приёма публикации потоков с учётом загрузки серверов или географического расположения автора публикации. Как мы реализовали резервирование точек публикации в Flussonic Cloud:

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

Получается:

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

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

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

Чтобы узнать, как настроить отказоустойчивый кластер транскодирования в Flussonic, см. Резервирование транскодеров с cluster ingest.

Запросы к серверам публикации должны быть распределены равномерно по нагрузке между серверами кластера транскодирования для предотвращения перегрузки. См. Балансировка нагрузки в Flussonic, чтобы узнать, как настроить балансировку нагрузки в Flussonic.

Кластер DVR

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

Flussonic предоставляет широкий набор инструментов для резервного копирования архива DVR и поддержания его доступности в любое время:

• репликация

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

Чтобы узнать больше о репликации и её настройке, см. Репликация

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

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

Чтобы узнать больше о кросс-репликации её режимах и настройке, см. Кросс-репликация DVR

• Flussonic RAID

Flussonic RAID — это программный RAID-массив (Redundant Array of Independent Disks), обеспечивающий высокую надёжность, эффективность и удобство при записи видеоданных на десятки дисков, образующих единый массив. Использование RAID позволяет повысить отказоустойчивость и производительность системы, а также увеличить объём хранилища.

Чтобы узнать больше о Flussonic RAID, его особенностях и настройке, см. Flussonic RAID для DVR.

• кластеризация DVR и кэширование сегментов

Для записи архива используются несколько DVR-серверов, один из которых — основной, а другие — вторичные. По статистике, до 90% всех просмотров записей трансляций приходится на последние сутки, поэтому при вещании масштабных событий необходимо использовать SSD, чтобы снять нагрузку с HDD. Flussonic даёт возможность использовать отдельный сегментный кэш на SSD для снятия нагрузки с HDD. Вы можете использовать сегментный кэш на вторичном сервере для хранения DVR, но фактически управлять всем архивом будет основной сервер.

Чтобы узнать больше о сегментном кэше и его настройке, см. Кластеризация DVR.

CDN

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

Здесь появляется CDN (сеть доставки контента). Имея множество серверов, распределенных по различным географическим точкам, CDN обеспечивает эффективную доставку контента по всему миру, сокращая расстояние между edge-сервером и зрителем и, следовательно, минимизируя задержку и обеспечивая более быстрый доступ к контенту. CDN кэширует контент в различных PoP (точках присутствия), чтобы доставить его непосредственно зрителю. CDN также повышает общую производительность онлайн трансляции, распределяя рабочую нагрузку на несколько серверов и разгружая origin-сервер для поддержания его работоспособности.

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

Чтобы узнать больше о CDN в Flussonic, см. Организация CDN. Flussonic также работает с другими CDN, например Akamai, см. Копирование потока в CDN Akamai.

Анализируем и запускаем: реальный пример

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

Этап анализа

На этапе анализа вы разберёте что, для кого и как вы будете делать. Будем двигаться последовательно:

Шаг 1. Определяем нишу

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

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

Шаг 2. Определяем целевую аудиторию

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

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

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

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

Шаг 3. Определяем вид контента и профили авторов

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

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

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

Шаг 4. Определяем основные возможности платформы/сервиса

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

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

• поддержка использования VMix, OBS, Atemi, HDMI-RTMP конвертеры, пульты видеомонтажа, различных браузеров для публикации потоков на сервер,
• запись онлайн-трансляций и их хранение,
• многопотоковая трансляция в социальные сети,
• отказоустойчивость и резервное копирование,
• подготовка мультибитрейтных потоков,
• масштабируемость и балансировка нагрузки,
• доступность с любого устройства и браузера,
• данные и аналитика,
• встроенный медиаплеер,
• загрузка предварительно записанных потоков,
• система авторизации,
• монетизация,
• система подписок и т.д.

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

Например, наша платформа для виртуальных мероприятий будет:

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

Этап составления технических требований

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

• оценке необходимой пропускной способности сети на входе и на выходе для каждого шага пайплайна доставки видео (источник, транскодер, DVR, origin-сервер) на примере платформы для трансляции онлайн-мероприятий;
• построению схемы архитектуры сети на примере платформы для трансляции онлайн-мероприятий.

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

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

Для нашей платформы для трансляции онлайн-мероприятий таблица будет выглядеть следующим образом:

На основе вышеприведённых данных составим схему сети:

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

На схеме выше показано, что для реализации проекта понадобится четыре сервера Flussonic. Два из них будут принимать публикации и транскодировать видео (transcoding server №1 и transcoding server №2), а два других — вести запись архива и доставлять контент клиентам (origin server №1 и origin server №2).

Сеть

Посчитаем пропускную способность сети на входе. Будем опираться на данные выше:

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

Таким образом, значение пропускной способности сети на входе равно 50 Мбит/с.

Посчитаем пропускную способность сети на выходе транскодера. После транскодирования десяти 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 тыс.) и самое высокое качество потока (FHD):

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

Контрольная панель автора

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

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

• авторизация с помощью пароля при публикации потока (проверяет пароль при публикации потока);

• passphrase для защиты публикации по SRT (проверяет пароль при публикации потока по протоколу SRT);

• конфигуратор бэкендов (с его помощью можно создавать авторизационные бэкенды в файле конфигурации без написания скриптов).

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

Контрольная панель зрителя

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

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

• авторизация по токену (обращается к указанному бэкенду и проверяет полученный токен);

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

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

• passphrase для защиты проигрывания по SRT (проверяет пароль при проигрывании потока по протоколу SRT);

• конфигуратор бэкендов (с его помощью можно создавать авторизационные бэкенды в файле конфигурации без написания скриптов).

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

Сервер(ы) захвата

Серверы захвата должны поддерживать приём публикации по протоколам от источника. Flussonic Media Server поддерживает приём публикации по таким протоколам, как RTMP, SRT, WebRTC (WHIP) (подробнее см. Публикация видео на сервер) и др.

RTMP позволяет использовать open-source решения и практически любое оборудование для монтажа. SRT обеспечивает бесперебойность публикации потока в реальном времени без потерь и с минимальной задержкой (latency). Поддержка WebRTC (WHIP) для публикации потоков даёт авторам возможность использовать браузеры вместо специального оборудования и ПО.

В нашей схеме серверы transcoding server №1 и №2 занимаются приёмом публикации по RTMP и SRT и транскодированием. Transcoding server №1 будет основным, а transcoding server №2 — резервным. Если основной сервер будет недоступен, то произойдёт бесшовное переключение на резервный сервер. Если оба сервера (основной и резервный) будут недоступны, то включится файл-заглушка и в архив будет записываться заглушка. Такая логика работы обеспечивает отказоустойчивость системы в случае возникновения трудностей с серверами захвата.

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

Транскодирование — самая вычислительно затратная операция во всём пайплайне доставки видео.

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

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

Вы можете воспользоваться нашим программно-аппаратным комплексом для транскодирования потоков — Flussonic Coder. Узнайте больше на нашем веб-сайте.
Один Flussonic Coder может транскодировать 48 Full HD (FHD) потоков в три профиля (FHD, HD и SD) и состоит из восьми модулей NVIDIA Jetson. Один модуль NVIDIA Jetson способен транскодировать примерно шесть Full HD потоков. Мы рекомендуем вам провести нагрузочное тестирование на ваших потоках, чтобы определить точное количество серверов Flussonic Coder или их модулей, необходимых для оптимальной работы, и понять устраивает ли вас производительность Flussonic Coder.

Для транскодирования десяти Full HD (1080p) потоков в три профиля (1080p, 720p, 360p) необходимы два модуля NVIDIA Jetson.

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

Сервер(ы) DVR

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

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

Максимальное число просмотров записи онлайн-мероприятия приходится на первые сутки после его окончания. Если зритель не может вовремя подключиться к трансляции, то ему необходимо иметь возможность посмотреть эту трансляцию в записи в удобное для него время. Эта технология называется catch-up (“вслед за эфиром”) (см. подробнее Catch-up TV). Частое обращение зрителей за записью создаёт большую нагрузку на хранилище. Для того, чтобы снизить нагрузку на хранилище и ускорить раздачу VOD-контента, настройте кэширование на SSD.

Для нашей платформы мы выстроили следующую схему организации записи и хранения архива:

Два сервера для записи архива и отдачи клиентам через CDN — origin server №1 и №2. Серверы захватывают потоки с сервера транскодирования по внутреннему протоколу M4S и записывают онлайн-трансляции. После окончания мероприятия Flussonic выгружает записи в формате MP4-файлов в облачное хранилище S3, чтобы зрители могли посмотреть трансляцию мероприятия в записи. При первом запросе MP4-файла с записью онлайн-трансляции файл будет кеширован локально на SSD. Все последующие запросы будут обслуживаться уже с этого SSD, чтобы каждый раз не обращаться к основному хранилищу S3. Если к файлу кеша не обращаются в течение суток, то файл удаляется. Если суммарный объем файлов в кеше превышает 100 Гб., то Flussonic удаляет файлы из кеша, начиная с самого старого. Количество запросов, после которых запись перейдёт в кеш, максимальный объём кеша и время, в течение которого файл будет храниться в кеше, можно настраивать под себя.

Origin-сервер(ы)

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

В нашем проекте мы используем два origin-сервера — origin server №1 и №2 и гибридную схему работы балансировщика нагрузки. При такой схеме:

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

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