Фото: TEKTRONIX
Создание IP-инфраструктуры для видеопроизводства — это процесс объединения двух «миров» — видеоинженерии и сетевой IT-инженерии. Этот процесс порождает еще одну серьезную проблему. Видеоинженеры привыкли работать в среде SDI, пользоваться коаксиальными кабелями, патч-панелями, «черными полями», синхросигналами и т.д. Главной задачей, вставшей перед видеоинженерами в новых реалиях, стало понимание IT-технологий и влияния IT-инфраструктуры на видеосигналы. С другой стороны, сетевым инженерам понятны и знакомы IP-потоки, протоколы, сетевой трафик, маршрутизация, протоколы точного времени (PTP) и сетевого времени (NTP) для синхронизации. И если в большинстве IP-приложений потерянные пакеты можно безболезненно отправить повторно, то при работе с IP-видео с высоким битрейтом такой подход не работает. Задача сетевых инженеров в работе с IP-видео — понимание видеотехнологии и ее влияния на IT-инфраструктуру. И уж без чего точно не обойтись первым и вторым, так это без инструментов диагностики, мониторинга и анализа работы инфраструктуры IP-видео.
Какие проблемы могут возникнуть в IP-сетях?
Большинство причин, которые могут вызвать проблемы в IP-сетях, можно отследить по джиттеру пакетов. Чрезмерный джиттер может привести к переполнению буфера, потере пакетов и задержке получения данных. Другие разновидности проблем могут возникнуть из-за задержек синхронизации и асимметричности потока PTP-пакетов.
Фото: TEKTRONIX
В гибридных SDI-IP сетях, помимо прочего, необходимо обеспечить согласованность между видеоинтерфейсами SDI и IP, чтобы гарантировать бесшовное переключение между потоками. Этого можно достигнуть путем измерения соотношения между синхросигналами Black Burst/Tri-Level Sync и часами PTP, а также внесения необходимой коррекции смещения SDI-сигнала относительно эталонной синхронизации PTP.
Из-за чего возникает джиттер IP-пакетов?
В цифровой системе джиттер представляет собой отклонение или смещение периодичности сигнала. В IP-сетях, содержащих данные с постоянной скоростью потока, джиттер — это отклонение от периодичности интервала времени получения пакетов приемным устройством. Как правило, джиттер может возникать из-за неверной очередности пакетов или настройки оборудования. Но если принять, что все элементы сети настроены и работают правильно, то наиболее распространенная его причина — перегрузка сети на интерфейсах маршрутизаторов и коммутаторов.
Джиттер пакетов — это отклонение от периодичности интервалов времени прихода пакетов
Джиттер свойственен любой IP-сети в силу ее асинхронной природы. Очевидно, что любое устройство, работающее в сети, требует передачи данных в неповрежденном виде и, как следствие, в приемных устройствах реализуют так называемый буфер де-джиттера. Благодаря такому подходу, устройство получает пакеты данных не напрямую, а с выхода буфера с постоянной скоростью и выровненной периодичностью следования пакетов.
Какие бывают последствия от большого джиттера?
Скорость, с которой буфер получает данные, называется скоростью наполнения буфера. В свою очередь, скорость, с которой буфер отдает пакеты данных, называется скоростью опустошения буфера. На практике выбор размера буфера имеет принципиально важное значение, поскольку, если буфер будет слишком мал, скорость опустошения превысит скорость наполнения и в результате поток остановится. И наоборот, когда скорость наполнения превышает скорость опустошения, буфер переполнится и это приведет к потере пакетов. Однако если размер буфера слишком велик, тогда сетевое устройство будет вносить чрезмерную задержку.
Применительно к потоковому видео с высоким битрейтом избыточная буферизация, равно как и переполнение буфера, неизбежно приведут к ухудшению качества изображения. Следует также отметить, что перегруженность портов также приведет к неизбежной потере пакетов.
Измерение джиттера в RTP-ориентированных сетях
Ранее мы отметили, что в сетях передачи данных с постоянным битрейтом джиттер представляет собой девиацию (отклонение) времени прихода пакетов в приемник и при наличии в приемнике точных часов, можно легко измерить джиттер как разность между расчетным (по тактам) и реальным временем прихода пакетов.
Данный метод полезен для определения отклонения джиттера с течением времени, однако не менее полезно иметь возможность строить график распределения интервалов прихода пакетов по отношению к частоте появления пакетов в виде гистограммы. Помимо этого, актуально производить и подсчет пакетов, потерянных в результате большого джиттера, который буфер де-джиттера не в состоянии корректно устранить. Возможность определить данные отклонения — это значительная помощь в понимании, может ли джиттер в сети быть причиной потери пакетов или нет.
График зависимости интервала прихода пакетов от времени
При непрерывной передаче данных с постоянным высоким битрейтом, широкая форма гистограммы распределения джиттера показывает вероятность перегруженности сети и потери пакетов. Как следствие, если форма гистограммы распределения джиттера в сети достаточно узкая, а система при этом теряет пакеты данных, то причина кроется точно не в перегрузке сети.
Из этого можно сделать вывод, что измерение распределения джиттера можно использовать для оценки размера буфера, необходимого для устранения джиттера-потока. По существу, серия пакетов с длинными интервалами времени между ними неизбежно приведет к соответствующей серии пакетов с короткими интервалами времени. Это как раз тот вариант трафика, который может создать условия переполнения буфера и потери пакетов.
Неравномерность времени поступления пакетов приводит к переполнению буфера, если:
скорость наполнения > скорости опустошения для ∆t > размера оставшегося временного буфера.
Гистограмма — график зависимости временного интервала прихода пакетов от частоты их появления
Определение необходимого размера буфера де-джиттера
Мы уже видели, что простое измерение интервала времени прихода пакетов нельзя в реальности использовать для прогнозирования необходимого размера буфера де-джиттера. Помимо описанной выше методики, есть альтернативный метод измерения джиттера, известный как Delay Factor (DF) и который также можно использовать для определения размера буфера де-джиттера. Delay Factor это измерение во времени, которое в случае высокой скорости потока выражается в микросекундах и показывает, сколько времени необходимо для опустошения виртуального буфера в данном сетевом узле. В любой заданный момент времени Delay Factor отображает размер временного буфера на этом узле, который необходим для де-джиттера потока.
Одна из форм измерения DF использует информацию о метке времени, присутствующей в протоколе RTP и описанной в RFC 3550. Она отражает момент выборки первого байта в пакете данных RTP (формат метки схож с одноименным в NTP). Это измерение получило название Time-Stamped Delay Factor, или TS-DF, и подробно описано в EBU Tech 3337. TS-DF базируется на корреляции времени прихода сетевых пакетов с полем метки времени в заголовке RTP-пакета.
TS-DF представляет размер временного буфера, необходимого для устранения джиттера в микросекундах
Измерение TS-DF базируется на относительном времени прохождения Relative Transit Time, описанном в RFC 3550 (RTP: A Transport Protocol for Real-Time Applications). Оно определяется как разница между временной меткой пакета RTP (расположенной в заголовке RTP-пакета) и встроенными часами приемника в момент прихода пакета. Период измерения TS-DF составляет одну секунду. В данном алгоритме первый пакет в начале периода измерения используется как эталонный, то есть не имеющий джиттера, а для каждого последующего пакета, который поступает в течение периода измерения, рассчитывается время относительного прохождения (Relative Transit Time) между ним и эталонным пакетом. По окончании измерений извлекаются максимальные и минимальные значения, а фактор TS-DF рассчитывается по следующей формуле:
TS-DF = D(Max) — D(Min)
В отличие от алгоритма измерения джиттера RFC 3550, данный алгоритм не учитывает коэффициент сглаживания и поэтому дает мгновенный и точный результат. Современные гибридные SDI-IP платформы-анализаторы позволяют измерять как джиттер прихода IP пакетов, так и RTP измерение TS-DF.
Поиск главной причины
Для уверенной работы в сетях необходимо понимать, являются ли первопричиной возникших нарушений ошибки в IP-сети или какие-либо другие неисправности. Сопоставляя временные метки видеоошибок с отметками времени ошибок пакетов RTP, можно установить, действительно ли ошибки пакетов стали основной причиной ошибок в видео.
Ошибка CRC-видео сама по себе не указывает явно на то, что видео имеет какие-либо проблемы. В дополнение к анализу ошибок, отображающихся в лог-файлах, желательно пользоваться традиционными средствами визуального контроля качества картинки и звука, такими как видеомониторы и ТВ-осциллографы.
Коррелированные во времени Видео и IP ошибки
Что такое PTP?
IP-сети — это по природе своей сети асинхронные, поскольку у них нет такого понятия, как системное время. Протокол точного времени PTP (Precision Time Protocol) обеспечивает синхронизацию часов в различных узлах сети в реальном времени. Следует отметить, что протокол PTP не делает сеть синхронной (как в случае с Синхронными Сетями и технологией SyncE). Самая новая версия протокола — это IEEE 1588-2008, также известная как PTPv2, на основе которой SMPTE разработала стандарт, предназначенный специально для вещательных видео приложений, известный как SMPTE ST 2059.
Использование IP-видео совместно с протоколом PTP для синхронизации времени в различных узлах сети подразумевает наличие в такой сети сервера точного времени, который обеспечит функционал генератора тактовой частоты (genlock), эквивалентный генератору синхроимпульсов, использующемуся в сетях SDI. Любая логическая группа синхронизированных между собой часов называется PTP-доменом. Важно учесть, что часы в одном домене могут быть не синхронизированы с часами в другом домене.
Сервер времени в PTP-сети обычно называют Главным мастером (Grandmaster), а устройство, которое получает от него информацию о точном времени, — ведомым (slave). Кроме того, существует сервер, называемый Мастер (Master). Он обеспечивает время в конкретном домене PTP. Обычно сервер Grandmaster получает сигналы точного времени по GPS и ГЛОНАСС.
Как доставляется время по PTP-сети?
Сеть ведомых Slave-устройств, подключенных к одному ведущему (Master), известна как PTP-домен, в пределах которого существует несколько типов сообщений, используемых для установки точного времени. Сообщения анонса (Announce messages) используются для установки иерархии синхронизации и предоставления статуса часов и критериев времени, необходимых для определения того, какие часы становятся главным мастером. Сообщения Sync и Follow-up передаются главным мастером и используются ведомыми устройствами для получения времени. Сообщения Delay Request представляют собой запросы о времени — они отправляются от ведомых устройств к главному мастеру для того, чтобы определить задержку распространения на обратный путь. Сообщения Delay Response отправляется главным мастером и содержат время получения им запроса Delay Request.
Сообщения PTP передают точное время между Master и Slave
Стандарт PTP — это метод распределения времени по сети с одним главным мастером, обеспечивающим источник времени, для синхронизации одного или нескольких ведомых устройств. Grand Master периодически передает сообщения Sync и Follow up, из которых ведомые устройства получают время. В идеальном случае, задержка сети может быть записана в каждом ведомом Slave устройстве и использована для получения правильного времени из пришедшего пакета. Такую симметрию можно использовать только в IP-соединениях «точка-точка». К сожалению, задержка в IP-сетях c коммутацией и маршрутизацией может отличаться в разных сетевых узлах, а также может быть асимметричной. Для учета этой задержки ведомые устройства должны периодически отправлять главному мастеру сообщения запроса Delay Request. Главный мастер вставляет точное время получения в эти запросы и отправляет их обратно в ведомое устройство в сообщении Delay Response.
Используя приведенную на рисунке выше методику, ведомое устройство может рассчитать разницу между своим временем и временем главного мастера. Чтобы время ведомого устройства было абсолютно правильным, задержка распространения должна быть одинаковой в обоих направлениях.
Алгоритм Best Master Clock
Фундаментальный компонент протокола PTP — алгоритм Best Master Clock или BMCA, который работает на всех часах в сети. BMCA необходим для обеспечения устойчивости в сети и способен взять на себя функцию «генератора» точного времени в случае, если действующий Grand Master вышел из строя. Основными причинами его выхода из строя могут быть потеря сигнала GPS, отключение от сети и другое.
Выбор того, какие часы должны взять на себя функцию главного мастера, определяются следующими критериями BMCA в порядке приоритетности.
1. Поле «Приоритета 1» (в диапазоне от 0 до 255. По умолчанию выбирается 255 для ведомых устройств и
2. Тип часов (GPS или автономные);
3. Точность часов;
4. Отклонение часов (джиттер и погрешность хода);
5. Поле «Приоритета 2» (в диапазоне от 0 до 255. По умолчанию выбирается 255 для ведомых устройств и
6. Clock Source Port ID (обычно это MAC-адрес устройства).
Определение состояния часов Master/Slave
Как обеспечить резервирование Grand Master
Для автоматического переключения между основным и резервным Grand Master используется «Поле приоритета 2», которое определяет основные и резервные часы между двумя или более резервными серверами Grand Master следующим образом.
- Основной сервер Grand Master (Поле первого приоритета = 128; Поле второго приоритета = 127);
- Резервный сервер Grand Master (Поле первого приоритета = 128; Поле второго приоритета = 128);
Если оба одинаковых сервера синхронизированы от GPS/GLONASS, они имеют одинаковую точность часов, поэтому самое низкое значение «Поля приоритета 2» будет определять, кто является Главным Мастером. Если основной сервер теряет GPS-сигнал, тогда резервный Grand Master становится наиболее предпочтительным и берет на себя роль Grand Master.
Настройка основного и резервного Grand Master для автоматического резервирования
Стоит отметить, что, если сервер Master теряет сигнал GPS, то он переходит в режим внутренней синхронизации. Как бы ни был хорош внутренний осциллятор, через определённый период времени его фаза сместится относительно GPS. После повторного захвата GPS, если петля фазовой автоподстройки внутреннего генератора (PLL) быстро синхронизируется с GPS, происходит подрыв синхронизации. Этот подрыв может быть приемлемым для IT задач, но крайне нежелателен для видеопроизводства. Некоторые генераторы синхросигналов и PTP имеют возможность удерживать частоту и фазу при пропадании GPS и обеспечить бесподрывную синхронизацию при его восстановлении.
Измерение и мониторинг PTP
Рассматривая точность PTP-синхронизации, важно понимать, насколько сеть асимметрична. То есть необходимо определить, насколько задержка пакета от ведущего устройства к ведомому отличается от задержки в обратном направлении — от ведомого устройства к ведущему. Если задержка в оба направления различна, то ведомое устройство сдвигается к «правильному», подстраивая свои часы на половину измеренного значения асимметрии. Время ведомого устройства циклически корректируется до тех пор, пока задержка от ведомого к ведущему и от ведущего к ведомому не станет равнозначной.
Измерения асимметрии задержки прохождения пакетов Slave-to-Master/Master-to-Slave и изменения времени задержки пакетов (PDV — Packet Delay Variation)
Помимо этого, для обеспечения точности синхронизации необходимо, чтобы маршрутизаторы и коммутаторы учитывали собственные задержки и имели поддержку протокола PTP. Такие устройства могут работать в двух режимах: граничный (Boundary Clock) и сквозной (Transparent Clock). Граничные часы получают время PTP от Grand Master и выступают в качестве ведомого Slave-устройства. Такое устройство использует это время для фазовой автоподстройки своих внутренних часов, после чего начинает выступать в роли мастера, создавая на своих выходных портах сообщения Sync и Announce. Таким образом, граничная задержка упраздняется, поскольку на выходе устройства появляется новое время PTP.
Устройства, работающие в режиме сквозных часов, измеряют время транзита сообщений PTP через себя, после чего они сообщают это время ведомому устройству в специальном поле коррекции сообщений PTP. Поскольку задержка такого коммутатора удаляется из результата расчета, то это время не влияет на задержку очереди пакетов в коммутаторе.
Устройства в одной и той же сети должны находиться в одном домене, и очень важно, чтобы приоритеты BMCA были правильно настроены. Это гарантирует, что правильный Master выбран как Grand Master и что выбран верный резервный сервер на случай отказа этого Grand Master.
Гибридные Black Burst/Tri-Level — PTP сети
В ближайшем будущем многие телевизионные комплексы будут работать в комбинированном SDI-IP режиме. При таком сценарии крайне важно обеспечить синхронизацию Black Burst/Tri-Level с PTP для гарантированного «бесшовного» переключения между потоками. Этого можно достичь путем измерения разницы времени/фазы между PTP и Black Burst/Tri-Level и последующей настройкой смещения в гибридном SPG/PTP генераторе Grand Master.
Измерение разницы времени между BB / Tri-Level и PTP
В реальных рабочих условиях сетевые инженеры могут и не принимать участия в процессе производства контента, а сетевое IP-оборудование и вовсе может находиться в труднодоступном месте. Поэтому крайне желательно, чтобы диагностическое и измерительное оборудование имело возможность удаленного управления.
Заключение
В заключение хочется повторить, что использование IP-инфраструктуры для видеопроизводства не только дает дополнительные возможности, но и вносит свои сложности. В ситуации, когда сталкиваются миры видео- и IT-инженерии, необходимы инструменты анализа и диагностики, понятные специалистам обеих областей.
В условиях принципиально разных подходов к обеспечению качества видео- и IT-специалистов, описанные выше измерения становятся критически важными и обеспечивают бесперебойную работу процессов телекомпании.
Наконец, переход на IP -технологии, уже происходящий семимильными шагами в ТВ-производстве, требует надежных инструментов для генерации, диагностики и анализа в гибридных SDI/IP сетях.
Обложка: TEKTRONIX