Олег Березин, председатель российской секции SMPTE, директор Высшей школы киноинженеров, генеральный директор «Невафильм», выступил с докладом «Применение алгоритма избыточного резервирования передачи медиаданных в IP-сетях стандарта SMPTE ST 2022-7 для распространения телепрограмм в стандарте SMPTE ST 2110» на Online-круглом столе «Broadcasting 2021. Решения для вещания и распространения телепрограмм» 14 октября во время второй ежегодной TKT Tech Week 2021.
Олег Березин: сегодня мы столкнулись с весьма необычной ситуацией, когда наличие трех стандартов приводит не к решению проблемы, а к возникновению новой. Каждый стандарт – ST 2022-7, ST 2110 и ST 2059 сам по себе хорош. Но применение их сегодня одновременно порождает интересные проблемы. Хочется отметить важный момент: стандартизация – это не просто указание, как делать. Стандарт – это способ договориться сообществу, как нужно реализовывать ту или иную задачу так, чтобы решения были совместимы.
Стандарт SMPTE ST 2022-7 первоначально носил название «Бесшовное переключение IP-пакетов в стандартах 2022». То есть он разрабатывался, в первую очередь, для надежной передачи видеопотоков асинхронных и синхронных цифровых последовательных интерфейсов по IP-сетям. В 2013 году одновременно с разработкой ST 2022-7 разрабатывается и стандарт ST 2022-06 передачи SDI-потока в IP-сетях. В последний момент ST 2022-6 и ST 2022-7 были гармонизированы, и в результате появляется алгоритм передачи SDI-сигнала по IP-сетям на большие расстояния с определенной долей надежности за счет использования избыточной передачи данных путем дублирования путей передачи. Таких путей может быть несколько, не обязательно два. Один, к примеру, идет через Владивосток, другой – через Европу, в конечном итоге они сходятся вместе.
Стандарты семейства ST 2110
В 2017 году появляются первые стандарты семейства ST 2110. Изначально появление нового семейства стандартов передачи медиаданных по IP-сетям вызвало воодушевление в индустрии телевещания. Передача медиаданных тоже идет по IP-сетям и дает возможность использовать алгоритм избыточной надежности ST 2022-7. В 2019 году, когда выпускалась новая версия ST 20220-7, ему даже поменяли название. Он стал называться ST 2022-7 «Защищенное бесшовное переключение RTP-пакетов».
Принцип работы ST 2022-7 очень простой: несколько путей, которые сходятся в соответствующее количество раздельных буферов приемника. Приемник просто выбирает первый пакет, который пришел, и ставит его в очередь на реконструкцию общего потока. Если у нас поток картинки, которая идет по первому потоку, каким-то образом рушится, у нас имеется резерв – второй путь. Из него мы забираем копии поврежденных в первом пути пакетов, и на выходе получается идеальная картинка, а зритель ничего не замечает. Вероятность того, что все пакеты даже одного кадра одновременно будут порушены, идея разными путями, очень низкая. Поэтому это очень надежный способ восстановления готовой картинки, даже если оба пути вносят искажения. 
Дальше возникает вопрос: если система построена в режиме ST 2022-7, то куда мы добавим РТР-источник? Если его поставить со стороны передатчика, то есть последний будет ведомым, и все сигналы будут идти по двум маршрутам, и все, вроде бы, должно работать. Но представьте, в чем суть РТР: часы-грандмастер – опорный генератор времени, который работает, периодически посылает сигнал-анонс, который сообщает всем ведомым от него устройствам, что он грандмастер, и что он «жив». Как только этот анонс пропадает, сразу возникает вопрос, что случилось с Грандмастером? Спустя некоторое время устройство начинает опрашивать доступные часы-грандмастеры: давайте выбирать новые. Начинается процесс выбора. Теперь представьте, когда сигнал идет двумя путями и есть приемник, который их получает, то он начинает усиленно думать. Поскольку система берет первый пришедший сигнал и его воспринимает. Следом приходит аналогичный запрос. В результате происходят сбои, поскольку устройства не различают все сигналы, поступающие по разной маршрутизации. Следовательно, такую схему использовать нельзя.
Если поставить два маршрутизатора на первый и второй путь в виде граничных часов и туда поставить по приемнику «А» и «B», эта схема будет работать, если правильно настроить. Но у нее очень сложная топология сети.
В настоящее время, есть два решения.
Одно из них предлагает Imagine Communications – соединить два маршрутизатора специальным линком, по которым передаются только РТР-сообщения. То есть один их маршрутизаторов работает в режиме Лидера (от действующего Грандмастера), РТР-сообщения идут между двумя маршрутизаторами и, в зависимости от того, какие часы активны, маршрутизаторы обеих путей переключаются взаимно попеременно в режим «save» либо «лидер». В такой системе возможно получить синхронизацию, потому что мы передаем только РТР-сообщения, а все сетевые устройства обоих путей синхронизируются от одного Грандмастера, не смешивая основные потоки друг с другом.
Еще одно решение, которое сейчас обсуждается, тоже интересное, но оно сложнее. Мы к каждому маршрутизатору ставим свои часы-грандмастеры, каждые из них работают в режиме Лидера, но разделены, соответственно на собственные РТР-домены. Хитрость состоит в использовании специальных сетевых карт, имеющих два интерфеса и которые обслуживают только РТР-сообщения. Эта карта выбирает только правильные сообщения – announce, syncs, follow_up и так далее. Благодаря этому приемники и передатчики синхронизируются. Данная схема предложена сотрудниками компаний Nvidia и Oregano Systems.
Итоги
- Поведение РТР в сетях ST 2022-7 не описано ни в IEEE стандартах, ни SMPTE
- ST 2110 использует временные метки RTP только полагаясь на ST 2059/PTP
- Не все топологии могут работать в таком решении, а разные поставщики рекомендуют совсем не похожие друг на друга решения
- Поставщики решений начали договариваться об общих правилах. Например, все устройства должны быть ведомы от одного Грандмастера (один ID GM)
- Мы имеем три, в принципе, действующих стандарта ST2022-7,ST 2210и ST2059, но вместе они идеально не работают
- Но самое важное: SMPTE занимается поиском решения!
