Что такое Видеотракт?

04.04.2022

IT-специалисты давно знакомы с понятием “пайплайн”:

  • Системные администраторы знают как собрать цепочку консольных утилит в “мощный” однострочник. Вывод одной команды перетекает на вход другой программы, образуя бесшовный конвейер обработки данных.
  • Разработчики собирают CI/CD, описывающий путь сборки и доставки приложения до тестовых и боевых серверов.
  • Сетевые специалисты начинают изучение работы сети с понимания работы протоколов TCP/IP и OSI. Затем собирают собственные сети, выбирая необходимое оборудование, физические каналы связи, протоколы и еще раз протоколы. Сеть – это тоже “конвейер” передачи данных: с одной стороны вошло, с другой – вышло.

Статья на википедии описывает и другие виды пайплайнов: в вычислениях, графике, продажах, логистике, любом промышленном производстве и даже водопроводе. (К сожалению, русская версия википедии содержит лишь половину тех статей, что есть в английской по теме “pipelines”).

Передача видео – тоже конвейер. В работе мы часто упоминаем этот термин – знакомим клиентов с тем “video pipeline”, который строим.

С чего начинается Video pipeline

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

“Видео-конвейер” начинается (как и заканчивается) всегда в одном и том же месте:

На входе: объектив камеры захватывает картинку
На выходе: зритель своими глазами просматривает с экрана устройства

От объектива до глаза – это и есть полный тракт. Зритель видит и слышит тот контент, который для него подготовили.

Основные элементы видеотракта

  • Захват сырого видео
  • Сжатие видео
  • Упаковка в медиа контейнер
  • Доставка по сети
  • Распаковка медиа контейнера
  • Разжатие видео
  • Проигрывание

Давайте посмотрим на эти шаги на примере IP-камеры и VLC плеера:

  • Матрица оцифровывает сигнал с объектива, превращая свет в поток байт, разбитых на отдельные кадры. Это и называется сырое видео: последовательность несжатых кадров.
  • Процессор камеры сжимает видео с помощью одного из кодеков (H264, H265), что позволяет снизить объем данных для передачи через Интернет.
  • RTSP-сервер камеры упаковывает H264 кадры с помощью RTP.
  • RTP пакеты идут по сети по TCP или UDP.
  • Приемник накапливают буфер кадров из потока RTP.
  • Плеер разжимает видео.
  • Изображение отображается в окне плеера.

Я бы не смог показать все эти шаги на примере Flussonic Media Server, т.к. в его задачи не входит проигрывание и отображение контента. Полный тракт с использованием Flussonic будет больше и сложнее – так и бывает в реальных сервисах.

Больше и сложнее

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

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

Итак, на входе у нас UDP Multicast с кодеками H264(interlaced) + MPEG-2 Audio, иногда ac3 на HD каналах. На выход нам нужно дать мультибитрейтный HLS и DASH.

Как это будет выглядеть в рамках одного сервера:

  1. Захват UDP
  2. Распаковка контейнеров, чтение MPEG-TS и извлечение "фреймов" (в данном случае аудио и видео пакеты можно назвать одним словом)
  3. Распаковка оригинальных кодеков (получаем сырое видео и аудио)
  4. Кодирование видео в несколько качеств (1080, 720, 576, 480) кодеком H264 с прогрессивной разверткой. Звук кодируется в AAC
  5. Сжатое видео, строго по GOP, упаковывается в MPEG-TS и MP4 контейнеры
  6. Формирование HLS и DASH манифестов (m3u8 и xml)
  7. Раздача абонентам live-контента по протоколу HTTP

Однако, в реальности, на одном сервере выполнить всю работу невозможно. С одной стороны – много каналов, с другой – много абонентов. Разделим один сервер на два, назначив им разные роли: “Захват и транскодирование” и “Раздача” (для удобства выделены разными цветами):

  1. Захват UDP
  2. Распаковка оригинальных кодеков (получаем сырое видео и аудио)
  3. Кодирование видео в несколько качеств (1080, 720, 576, 480) кодеком H264 с прогрессивной разверткой; звук кодируется в AAC
  4. Упаковка кадров в M4F, codec-agnostic контейнер для передачи между Flussonic-серверами
  5. Передача видео по протоколу HTTP
  6. Прием M4F, извлечение кадров
  7. Сжатое видео, строго по GOP, упаковывается в MPEG-TS и MP4 контейнеры
  8. Формирование HLS и DASH манифестов (m3u8 и xml)
  9. Раздача абонентам live-контента по протоколу HTTP

Можно пойти дальше и добавить запись архива на сервер. Получается три роли: “Захват и Транскодирование” (Ingest+Transcoding), “DVR”, “Раздача” (Edge).

И не забываем, что транскодирование – ресурсоемкая задача, поэтому транскодеров у нас много. Зрителей – тоже много, и для обслуживания их запросов также понадобится несколько серверов. Запись же можно сделать на одном сервере:

  1. Захват UDP
  2. Распаковка оригинальных кодеков (получаем сырое видео и аудио)
  3. Кодирование видео в несколько качеств (1080, 720, 576, 480) кодеком H264 с прогрессивной разверткой (на входе черестрочка, она нам не нужна!), а звук кодируем в AAC.
  4. Упаковка кадров в M4F – codec-agnostic контейнер для передачи между Flussonic-серверами
  5. Передача видео по протоколу HTTP
  6. Прием M4F
  7. Запись данных на диск, с группировкой по часовым интервалам
  8. Передача видео по протоколу HTTP
  9. Прием M4F
  10. Кеширование на SSD архивных запросов
  11. Сжатое видео, строго по GOP, упаковывается в MPEG-TS и MP4 контейнеры
  12. Формирование HLS и DASH манифестов (m3u8 и xml)
  13. Раздача абонентам live и dvr контента по протоколу HTTP

В итоге мы построили цепочку из 13 шагов (напомню, в примере с IP-камерой, у нас их всего было 7). Причем, это лишь “кусочек” пути, которое проделывает видео. Ведь кадры как-то пришли к Flussonic по спутнику, сжатые с помощью кодека, упакованные в медиаконтейнер – а значит, еще 5-15 шагов видео прошло ДО Flussonic.

Наша задача выполнена: мы мультиплицировали сигнал с одного коаксиального кабеля в Интернет, попутно адаптировав его под полосу и требования конечных устройств. Дальше путь видео также не заканчивается – его снова ждет распаковка и декодирование на конечном устройстве. А, возможно, и ретрансляция дальше, другими медиа-серверами в другие сети. Может быть, даже, кабельные.

Поэтому, video pipeline и напоминает промышленный трубопровод c километрами “труб” и соединений: десятки стыков между программами, протоколами, физическими средами, серверами, кодеками. Одно и тоже видео проходит через несколько этапов сжатия, проходит тысячи километров по разным физическим средам, меняет несколько кодеков и контейнеров.

Автор:
Максим Клюшков