Pull to refresh

Трансляция онлайн-видео с минимальной задержкой

Working with video
Не так давно к нам обратился клиент, который занимается видео-трансляциями аукционов и лошадиных скачек в прямом эфире. Сами мероприятия проходят в Австралии, а вот ставки на них делаются игроками в Макао — игровой столице Юго-Восточной Азии. Разумеется, он столкнулся с задержкой сигнала — как без неё. Задержка — это время между взятием кадра и его появлением на экране конечного устройства. И если обычному зрителю задержка в 5 или даже 10 секунд не критична, то тем, кто ставит на тотализаторе, подобная разница может стоить огромных денег. Отсюда возникла задача — свести к минимуму время прохождения видео от источника к зрителю.

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

Мы подумали, что некоторые техники, которые мы применили, будут интересны не только нам.

Итак, цепочку доставки видео схематично можно разделить на 6 этапов: съёмку, сжатие, передачу по локальной сети от энкодера к медиа-серверу, передача через интернет, декодирование и отображение на устройстве пользователя.



Посмотрим, чем определяются издержки на каждом из этапов и как их можно сократить.

1. Съёмка видео


Тут всё просто — всё зависит от камеры, которая используется в съёмке. Задержка здесь — меньше 1 мс, поэтому при выборе устройства можно сосредоточиться на потребительских качествах — кодеках и протоколах, качестве картинки, цене и т.п.

2. Сжатие (энкодинг)


Сжатие видео (encoding) — это обработка исходного видео с целью уменьшить размер передаваемых данных. Цель — пожать поток с помощью подходящего для задачи кодека. В настоящее время стандартом де-факто является видео в H.264 с аудио в AAC.

Работа на этом шаге влияет на всю цепочку в дальнейшем.

Предпочтение лучше отдать аппаратным решениям, т.к. программные добавляют время, нужное для работы с ресурсами, и накладные расходы операционной системы. Правильно настроенный энкодер не добавляет сколько-нибудь ощутимой задержки, но он задаёт битрейт результирующего потока и его тип. Различают переменный битрейт (variable bitrate, VBR) и постоянный (constant bitrate, CBR).

Главное преимущество VBR — он выдаёт поток с наилучшим соотношением качества изображения и количества занимаемых данных. Однако для него нужно больше вычислительных мощностей. Кроме того, если битрейт в отдельный момент времени превосходит пропускную способность канала, это далее повлечет за собой буферизацию на этапе декодирования. Поэтому для передачи видео в реальном времени с малой задержкой рекомендуется использовать CBR.

Однако с CBR тоже не всё так просто. На деле постоянный битрейт не является постоянным в каждый отдельный момент времени, т.к. поток H.264 содержит кадры разной величины. Поэтому в энкодере есть контроль усреднения битрейта на отдельных промежутках времени, чтобы объём данных был одинаковым на протяжении всей трансляции. Усреднение это делается, конечно же, в ущерб качеству. Чем меньше период усреднения, тем меньше буфер на этапе декодирования и тем хуже качество передаваемого видео.

Энкодеры промышленного уровня предоставляют разнообразные средства управления битрейтом, призванные давать CBR минимальным воздействием на качество. Их описание выходит за рамки нашей статьи, можно лишь упомянуть о таких параметрах как гранулярность контроля битрейта (Rate Control Granularity) и контентно-адаптивный контроль битрейта (Content-Adaptive Rate Control).

3. Передача от энкодера к медиа-серверу


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

Протокол передачи данных нужно выбирать исходя из возможностей энкодера и медиа-сервера, который будет раздавать данные конечным пользователям. Для передачи видео в реальном времени наиболее подходят RTSP, RTMP или MPEG2-TS.

4. Передача через Интернет на устройство пользователя


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

Первый фактор в этой цепочке — буферизация внутри медиа-сервера при транзмаксинге (перепаковке) потока из одного протокола в другой.

Второй фактор связан со спецификой каждого протокола.
Если собираетесь использовать протоколы на базе HTTP, например HLS или MPEG-DASH, будьте готовы к существенному увеличению задержки. Дело здесь в самом принципе работы этих протоколов — они основаны на разбиении контента на сегменты, или чанки, которые выдаются последовательно. Размер сегментов зависит от протокола и параметров передачи, однако их не рекомендуется делать меньше 2 секунд. Apple рекомендует размет чанков в 10 секунд. Поэтому при использовании HLS надо или уменьшать размер, или смириться с потерями времени.
Можно предположить, что можно построить доставку на HLS или DASH, максимально уменьшив размер сегментов и сведя все остальные потери времени к минимуму. И для большинства кейсов это сработает. Однако для передачи в реальном масштабе времени (ведь в нашем примере — аукционы) нужно использовать протоколы RTMP или RTSP.

Кроме того, мы выпустили свой протокол живого вещания с малыми задержками, SLDP. Использует вебсокеты, поэтому работает в большинстве современных браузеров. Плюс есть SDK для мобильных платформ.

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


(полная версия карты кабелей — здесь)

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

5. Декодирование


Это шаг может сильно влиять на скорость передачи. Чтобы отыграть возможную недостачу данных при передаче (помним про предыдущие шаги), буфер проигрывания должен содержать данные одного полного усреднённого периода с учетом сетевых задержек. Поэтому буфер может содержать от нескольких GOP-ов (GOP = group of pictures) до нескольких кадров, в зависимости от параметров энкодера и состояния сети. Многие плееры принимают минимальное значение буфера проигрывания равным 1 секунде и меняют его по ходу работы. Минимально возможный буфер достигается при использовании аппаратных декодеров (плееров), например на базе Raspberry Pi.

6. Отображение


Здесь, как и на первом шаге, время задержки пренебрежимо мало — всё покрывается возможностями железа.

Возвращаясь к примеру с нашим клиентом, цепочка доставки строилась из следующих частей. Видео снималось камерой и отдавалось на аппаратный энкодер Beneston VMI-EN001-HD. Далее от него поток по RTMP шёл на Nimble Streamer, который был настроен на максимальную производительность. В Макао данные шли также по RTMP, где в зале для приёма ставок стоит Raspberry Pi для декодировки и отображения на больших мониторах. Пинг от Австралии до Макао составил 140 мс. В RTMP-плеере на Raspberry Pi буфер был выставлен на 300 мс. Результирующая задержка сигнала для потока 1080p30 варьировалась между 500 и 600 миллисекундами, что вполне покрывает требования заказчика. Простые зрители по всему миру видят картинку с опозданием 3-4 секунды — не с последнюю очередь потому, что предпочитают смотреть через HLS на мобильных устройствах. В данном случае эта величина также приемлема.

В общем, живое вещание — штука непростая во всех смыслах. Достижение высоких показателей производительности — серьёзная задача и уменьшение времени прохождения сигнала требует подбора правильных компонент и их кропотливой настройки.
Tags:видеотрансляции в интернеттрансляция видеоэнкодердоставка контентаlatencyhigh performance
Hubs: Working with video
Total votes 15: ↑10 and ↓5 +5
Views42.6K

Comments 32

Only those users with full accounts are able to leave comments. Log in, please.

Popular right now

Top of the last 24 hours