Что такое Видеотракт? Объясняем значение термина pipeline
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.
Как это будет выглядеть в рамках одного сервера:
- Захват UDP
- Распаковка контейнеров, чтение MPEG-TS и извлечение "фреймов" (в данном случае аудио и видео пакеты можно назвать одним словом)
- Распаковка оригинальных кодеков (получаем сырое видео и аудио)
- Кодирование видео в несколько качеств (1080, 720, 576, 480) кодеком H264 с прогрессивной разверткой. Звук кодируется в AAC
- Сжатое видео, строго по GOP, упаковывается в MPEG-TS и MP4 контейнеры
- Формирование HLS и DASH манифестов (m3u8 и xml)
- Раздача абонентам live-контента по протоколу HTTP
Однако, в реальности, на одном сервере выполнить всю работу невозможно. С одной стороны – много каналов, с другой – много абонентов. Разделим один сервер на два, назначив им разные роли: “Захват и транскодирование” и “Раздача” (для удобства выделены разными цветами):
- Захват UDP
- Распаковка оригинальных кодеков (получаем сырое видео и аудио)
- Кодирование видео в несколько качеств (1080, 720, 576, 480) кодеком H264 с прогрессивной разверткой; звук кодируется в AAC
- Упаковка кадров в M4F, codec-agnostic контейнер для передачи между Flussonic-серверами
- Передача видео по протоколу HTTP
- Прием M4F, извлечение кадров
- Сжатое видео, строго по GOP, упаковывается в MPEG-TS и MP4 контейнеры
- Формирование HLS и DASH манифестов (m3u8 и xml)
- Раздача абонентам live-контента по протоколу HTTP
Можно пойти дальше и добавить запись архива на сервер. Получается три роли: “Захват и Транскодирование” (Ingest+Transcoding), “DVR”, “Раздача” (Edge).
И не забываем, что транскодирование – ресурсоемкая задача, поэтому транскодеров у нас много. Зрителей – тоже много, и для обслуживания их запросов также понадобится несколько серверов. Запись же можно сделать на одном сервере:
- Захват UDP
- Распаковка оригинальных кодеков (получаем сырое видео и аудио)
- Кодирование видео в несколько качеств (1080, 720, 576, 480) кодеком H264 с прогрессивной разверткой (на входе черестрочка, она нам не нужна!), а звук кодируем в AAC.
- Упаковка кадров в M4F – codec-agnostic контейнер для передачи между Flussonic-серверами
- Передача видео по протоколу HTTP
- Прием M4F
- Запись данных на диск, с группировкой по часовым интервалам
- Передача видео по протоколу HTTP
- Прием M4F
- Кеширование на SSD архивных запросов
- Сжатое видео, строго по GOP, упаковывается в MPEG-TS и MP4 контейнеры
- Формирование HLS и DASH манифестов (m3u8 и xml)
- Раздача абонентам live и dvr контента по протоколу HTTP
В итоге мы построили цепочку из 13 шагов (напомню, в примере с IP-камерой, у нас их всего было 7). Причем, это лишь “кусочек” пути, которое проделывает видео. Ведь кадры как-то пришли к Flussonic по спутнику, сжатые с помощью кодека, упакованные в медиаконтейнер – а значит, еще 5-15 шагов видео прошло ДО Flussonic.
Наша задача выполнена: мы мультиплицировали сигнал с одного коаксиального кабеля в Интернет, попутно адаптировав его под полосу и требования конечных устройств. Дальше путь видео также не заканчивается – его снова ждет распаковка и декодирование на конечном устройстве. А, возможно, и ретрансляция дальше, другими медиа-серверами в другие сети. Может быть, даже, кабельные.
Поэтому, video pipeline и напоминает промышленный трубопровод c километрами “труб” и соединений: десятки стыков между программами, протоколами, физическими средами, серверами, кодеками. Одно и тоже видео проходит через несколько этапов сжатия, проходит тысячи километров по разным физическим средам, меняет несколько кодеков и контейнеров.
Автор:
Максим Клюшков
Flussonic Media Server Team Lead
На передовой инноваций Flussonic: отвечает за разработку Flussonic Media Server, видео-аналитики, UI-сервисов