Синхронизация нескольких камер: проблема и решение

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

Стоит отметить, что камеры, передающие сигнал по SDI-кабелю, порой проблематично поставить в необходимых местах для хорошего ракурса. Поэтому все чаще для многокамерной съемки используют беспроводные камеры или камеры совместно с беспроводными кодировщиками. Это очень удобно, когда оператор может менять локацию без привязки к SDI-кабелю. В таком варианте, сигналы с разных участков поля передается по WI-fi в центральный компьютер режиссера мероприятия.

Но возникает проблема: в силу особенностей WI-fi сигнал с разных камер может приходить с разной задержкой. Это означает, например, что с одной камеры режиссер видит подлёт мяча к воротам, а с другой камеры, как мяч уже в воротах. Это осложняет сведение картинки и быстрое переключение ракурса. Поэтому, проблема синхронизации видеопотоков с нескольких беспроводных источников достаточно актуальна при проведении современных онлайн трансляций, и в том, что сейчас называют Remote Video Production.

Методы синхронизации присутствуют в топовых Hardware декодерах. Мы в свою очередь, также добавили эту функциональность в наш Software декодер SRTMiniServer. При этом количество линий для синхронизации в нашем продукте существенно больше чем в аналогичных Hardware решениях.

Вкратце опишем основные способы синхронизации видео потоков.

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

После “выравнивания” часов, видеокамеры уже могут вшивать тайм информацию (таймкод) при передаче сигнала. Мы рассмотрим 2 основных метода как это можно сделать.

Как вы знаете, самым распространенным видео кодеком сейчас является H264. Он позволяет передавать внутри себя мета-информацию о каждом кадре. Для этого в нем предусмотрен специальный раздел SEI. В частности, там заложен стандарт для передачи таймкода, включая текущее время и номер кадра.

У этого метода передачи таймкода есть свои плюсы и минусы.

Плюсы:

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

Минусы:

• метод применим только к семейству H264/HEVC
• не все производители стрим-камер и энкодеров поддерживают его
• нет возможности генерировать его програмно, на IOS и Android
• таймкод теряется при следующем цикле кодирования-декодирования

В действительности, очень мало производителей реализует этот метод передачи таймкода. Из тех производителей которые реализуют этот метод мы знаем JVC и Magewell . В камерах и энкодерах других производителей передача таймкода внутри SEI под вопросом.

Мы и наши коллеги тестировали наш SRTMiniServer, со следующими камерами JVC и кодировщиками Magewell:

• JVC GY-HC900
• JVC GY-HC550
• JVC GY-HC500
• Magewell Ultra Encode

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

Плюсы этого метода:

• является старым стандартом (пришел из мира VHS)
• легко реализуется программно, в частности на iOS и Android
• не зависит от видеокодека
• сохраняется при нескольких циклах кодирования-декодирования

Минусы:

• черно-белая полоса немного отнимает полезное пространство у кадра. Обычно это 10 px по высоте вверху кадра, как показано на картинке выше.

По результатам тестов, которые присылали наши коллеги из JVC и других компаний следует, что функция синхронизации в нашем софтверном продукте реализованы на уровне топовых HW решений. В частности, обеспечивается та же точность синхронизации: 1-3 фрейма. При этом в отличие от HW решений, в которых количество каналов жестко фиксировано, в нашем SRTMiniServer это ограничение отсутствует.

Стоит также упомянуть о псевдо-синхронизации. Этот метод применим как для SRT так и для RTMP протоколов. Он применяется если кодировщик не поддерживает передачу таймкода. Например, если вы используете несколько камер GoPro или стриминговое приложение LarixBroadcaster.

В этом случае применяется принцип “удерживать поток как можно ближе к реал-тайму” за счёт сброса запоздавших кадров. В этом случае все потоки будут “близки” к друг другу.

При условии стабильной локальной сети за несколько часов расхождение между потоками может быть в пределах 200-300ms, а количество сброшенных кадров не критичным.

Плюсы:

• работает с любыми SRT и RTMP кодировщиками

Минусы:

• неконтролируемая погрешность. Может достигать 100ms, а может и 400ms. Точность в 2-3 фрейма практически недостижима.
• метод неплохо работает только в локальной сети
• метод предполагает сброс “запоздавших” фреймов.

В нашем SRTMiniServer (и RTMPMiniServer) этот метод также поддерживается путём установления параметра Max buffer. Мы рекомендуем использовать значение в 300ms для этого метода.

Еще со времен работы с RTMP протоколом мы получали запросы от пользователей на синхронизацию нескольких видеоисточников. С появлением SRT протокола мы решили эту задачу и реализовали описанные методы в нашем SRTMiniServer. Будем рады получить от вас обратную связь по использованию этой функциональности в ваших трансляциях.