В статье описаны протоколы передачи аудио- и видеопотоков по линиям Ethernet.
Разработка стандарта IEEE 802.1 по реализации мостов для аудио- и видеопотоков (ABV — audio/video bridging) близится к завершению. Протоколы IEEE 802.1 базируются на технологии Ethernet, но отличаются рядом усовершенствований, позволяющих передавать синхронизованные по времени потоковые данные с малыми задержками. Сети Ethernet используются повсеместно, поэтому их удобно использовать для передачи аудио- и видеосигналов в режиме реального времени.
Транспортный протокол IEEE 1722 (AVBTP — AVB Transport Protocol), предназначенный для сетей Ethernet AVB, основан на стандарте IEEE 1394 и поддерживает полный набор медиаформатов и механизмов шифрования и синхронизации, определенных в IEEE 1394.
Устройства, поддерживающие интерфейсы AVB и AVBTP, в настоящее время активно выходят на рынок.
Стандарты IEEE 802.1
Рассмотрим более подробно основные стандарты IEEE 802.1 AVB.
IEEE 802.1AS Precision Time Protocol (PTP) — протокол установки точного времени. Разработан на основе стандарта синхронизации IEEE 1588:2002.2. Устройства PTP обмениваются стандартными сообщениями Ethernet, чтобы синхронизировать работу всех узлов сети и привязать их к общей шкале времени. В протоколе определены алгоритмы выбора главных (master) часов, порядок обмена сообщениями, механизмы измерения и компенсации задержки на линии, методы коррекции скорости.
Изначально протокол PTP создавался как упрощенная версия IEEE 1588. Принципиальная разница между ними заключается в том, что протокол PTP относится к уровню 2 модели OSI, это не IP-протокол. Как и IEEE 1588, PTP определяет автоматический метод ведения переговоров главных часов сети и алгоритм выбора лучших ведущих часов (BMCA — best master clock algorithm). По качеству тактирования узлам PTP можно назначить один из восьми уровней приоритетности. Алгоритм BMCA определяет основные механизмы переговоров, в процессе которых выявляется эталонное синхронизующее устройство сети — AVB LAN Grandmaster. Как только оно будет выбрано, процесс синхронизации начнется автоматически.
Вкратце процедура выглядит следующим образом. Пока сообщение РТР обрабатывается узлом 802.1AS, протокол PTP Ethertype запускает процесс выборки значения локального счетчика, работающего в режиме реального времени (RTC). Подчиненные узлы (slave) сравнивают показания своего времени и эталонного. Учитывая задержку на линии, они корректируют показания. После того как все устройства настроят счетчики, производится регулировка скорости передачи. Для этого периодически высылаются сообщения SYNC и FOLLOW_UP.
Таким образом, все PTP-узлы синхронизованы с эталонными часами (Wall Clock, «настенные часы») с точностью 1 мкс на отрезке, содержащем не более семи сегментов сети.
IEEE 802.1Qat Stream Reservation Protocol (SRP) — протокол резервирования ресурсов. Стандарты Ethernet не предусматривают детерминированную и приоритетную передачу критичных ко времени потоков. Для обеспечения гарантированного качества обслуживания протокол SRP предоставляет сквозную доступность полосы пропускания для передачи аудио- или видеоданных. Для других данных канал остается заблокированным до тех пор, пока не будет явно или неявно освобожден от потоковых данных. В стандарте SRP для передачи запросов описания потока, запросов резервирования канала и ответных сообщений используется протокол обмена IEEE 802.1ak Multiple Registration Protocol.
Протоколы SRP могут резервировать и защищать до 75% имеющихся ресурсов выбранного канала сети в т.н. защитном облаке (Defended Cloud).
IEEE 802.1Qav Queuing and Forwarding Protocol (Qav) — протокол установки очередности. Он следит за тем, чтобы наследственный асинхронный трафик не попадал в потоковые данные AVB. Большая часть протокола реализуется внутри коммутаторов Ethernet, но некоторые требования предъявляются и к источникам медиаданных.
Для наглядности рассмотрим устройство, посылающее аудиопоток в сеть. В процессе обработки (захват, оцифровка и отправка в сеть) аналоговый звуковой сигнал делится на изохронные блоки. Такие сигналы удовлетворяют всем требованиям стандарта 802.1Qav и подходят для передачи по сети AVB.
Проблемы возникают при работе с неизохронными потоками. Например, по каналу Gigabit Ethernet невозможно осуществлять передачу со скоростью, превышающей 1 Гбит/с. В связи с этим в сетях AVB гарантируется пересылка потоков со скоростью до 750 Мбит/с, а оставшиеся 250 Мбит/с предназначены для асинхронных данных. Протокол 802.1Qav определяет соотношение, в котором должен быть поделен канал между потоковыми и асинхронными данными, а также приоритетность каждого типа данных в коммутаторах Ethernet AVB. Ранее это выполнялось с помощью буферов для сглаживания скачков трафика, однако это очень затратный путь. Стандарты AVB снижают стоимость сети как раз за счет отказа от буферной памяти, гарантируя задержку не более 2 мс на участке в семь сегментов сети.
Более строгое определение стандарта 802.1Qav дано на сайте организации IEEE: «Этот стандарт позволяет мостам гарантировать передачу чувствительного ко времени и потерям аудио- или видеопотока в режиме реального времени. Он устанавливает приоритетность входных потоков и очередность обработки критических ко времени данных, а также отвечает за восстановление приоритетов. Этот стандарт использует ту же шкалу времени, что и IEEE 802.1AS. Для разделения управляемых и неуправляемых очередей используются метки VLAN, содержащие значение приоритета. Это позволяет одновременно работать как с аудио- и видеотрафиком, так и создавать мосты для других типов данных по проводным или беспроводным каналам».
Протоколы AVBTP
Назначение протоколов AVBTP — обеспечить логическое соединение, пусть и с задержкой, физически удаленных друг от друга кодеков. В более широком смысле стандарт AVBTP разделяет каналы передачи, чтобы создать виртуальное соединение распределенных аудио- и видеокодеков по каналам Ethernet.
Рассмотрим стек AVBTP. Как показано на рисунке 1, протоколы AVBTP находятся между стандартом IEEE 802.1 AVB и уровнем приложений. Они выступают в качестве посредника между MAC-устройствами Ethernet и потоковыми приложениями.
Рис. 1. Стек протоколов AVBTP |
Набор поддерживаемых медиаформатов включает в себя как необработанные, так и сжатые аудио- и видеоданные, в т.ч. I2S, IEC 60958 SPDIF, MPEG2/4, H.264, Bt.601/656 (несжатый) и т.д. По сути, с помощью протоколов AVBTP медиапотоки преобразуются в пакеты IEEE 1722 Ethernet и обратно.
При использовании устройств различных производителей необходимо удостовериться в их совместимости. Обычно сравнивается список поддерживаемых медиаформатов, а также структура размещения медиаданных в кадре AVBTP Ethernet.
Структура пакета
На рисунке 2 показан принцип записи несжатых аудиоданных IEC 61883-6 AM824 в кадр Ethernet. Поле Ethertype служит для уникальной идентификации кадра Ethernet AVBTP. По значению поля Payload Info определяется тип содержимого пакета.
Рис. 2. Структура пакета IEEE 1722 |
Первоначальный вариант протокола поддерживает только стандарт IEC 61883, однако в AVBTP предусмотрена возможность расширения и поддержки других, в т.ч. пока не существующих стандартов.
Поддерживаемые типы медианосителей
Протоколы AVBTP используют форматы и механизмы синхронизации, указанные в стандарте IEC 61883 и предназначенные для устройств IEEE 1394 FireWire.
Перечислим форматы IEC 618837 (части 1—8):
– 61883-2 SD-DVCR;
– сжатое видео 61883-4 MPEG2-TS;
– несжатое аудио 61883-6;
– спутниковое ТВ MPEG 61883-7;
– видео 61883-8 Bt.601/656;
– несжатый формат для технической съемки IIDC.
Благодаря тому, что стандарт AVBTP основан IEC 61883, у него появляется значительное преимущество — легкость, с которой шлюзы FireWire встраиваются в сети АVВ.
Синхронизация
Процесс синхронизации в сети АVВ осуществляется с помощью протокола PTP, который отвечает за настройку хода всех локальных часов в соответствии с эталоном, но не за синхронизацию локальных часов между собой.
Важным преимуществом такого подхода является то, что в сети может одновременно существовать нескольких независимых временных доменов, а значит, и несвязанных аудио- и видеопотоков.
Временные метки
AVBTP предполагает, что локальные часы узлов тактируются самовозбуждающимися осцилляторами. Кроме того, предполагается, что внутренние часы идут в такт с эталонными. Внутренние часы узлов сети вставляют свои временные метки AVBTP Presentation Timestamps в пакет P1722 (см. рис. 2). На рисунке 3 показана взаимосвязь между эталонным временем PTP и временными метками.
Рис. 3. Выставление временных меток |
Метки вставляются не во все пакеты. Частота генерации меток определяется значением поля DBC (счетчик блоков данных) в заголовке AVBTP. Обычно каждая восьмая выборка медиаданных преобразуется в 32-разрядное значение (в течение нескольких нс) и суммируется с нормированным значением задержки. Мы рассмотрим этот процесс позже.
Восстановление синхронизации
При восстановлении синхронизации используется та же процедура, но она выполняется в обратном порядке.
Значение поля DBC в заголовке пакета P1722 задает частоту, с какой подчиненные устройства AVB должны восстанавливать фронт синхроимпульса.
Механизм восстановления схематично показан на рисунке 4. Один из возможных способов реализации распределенной схемы синхронизации приведен на рисунке 5.
Рис. 4. Восстановление синхронизации |
Рис. 5. Схема синхронизации AVBTP |
Норирование задержки
У временных меток помимо основного — восстановления синхронизации, есть и еще одно назначение. По ним приемники медиапотока определяют, когда (по системе времени PTP) они должны выслать полученные аудио- или видеоданные. Этот простой, но эффективный механизм позволяет производить синхронизацию медиапотоков между несколькими узлами.
Стандарт AVBTP устанавливает, что конечные точки AVB могут буферизовать до 2 мс медиаданных с целью нормирования задержки (см. рис. 6). При необходимости эта величина уменьшается на прикладном уровне.
Рис. 6. Нормирование задержки |
Защищенное облако
Как мы уже говорили, качество передачи потоковых данных (QoS) гарантируется внутри т.н. «защищенного облака» — объединенной локальной медиасети с поддержкой основных протоколов AVB: IEEE 802.1AS Precision Time Protocol (PTP), IEEE 802.1Qat SRP и IEEE 802.1Qav.
Для установки защищенного облака сначала выбираются эталонные часы PTP. Далее с помощью протокола РТР производится синхронизация локальных часов AVB-устройств внутри облака. Вещающие устройства объявляют, какие аудио- и видеопотоки они могут передавать. В ответ принимающие устройства резервируют полосу. На этом этапе передача потоковых данных уже гарантирована. Для потокового трафика внутри облака может быть зарезервировано до 75% любого канала связи. По меньшей мере, пропускная способность сети остается свободной для наследственного трафика на 25%.
После установки и синхронизации (погрешность менее 1 мкс) защищенного облака гарантируется, что поток будет доставлен с задержкой менее 2 мс (на длине в семь сегментов сети).
Наследственные устройства могут обмениваться данными через защищенное облако по любому стандартному протоколу Ethernet, однако они всегда имеют самый низкий приоритет (см. рис.7). Доставка данных по таким протоколам как TCP/IP останется гарантированной, но, возможно, займет гораздо больше времени. Тем не менее сеть AVB будет на 100% обратно совместима с существующими сетями Ethernet.
Рис. 7. Обмен через защищенное облако |
Единая инфраструктура
По экономическим соображениям, в медиасетях будущего широкое распространение получит только одна технология, скорее всего Ethernet. Во всем мире тысячи разработчиков активно работают над усовершенствованием инфраструктуры Ethernet, в т.ч. над проводными и беспроводными устройствами физического слоя, контроллерами МАС, коммутаторами, схемами резервирования, системами диагностики и т.д. Рабочие группы IEEE уже активно трудятся над расширением стандартов AVB на беспроводные сети Ethernet.
Ведется работа по внедрению медиатехнологий Ethernet в потребительские, профессиональные и автомобильные аудио- и видеосети.
Для потребителей сети AVB позволят объединять медиаданные между всеми бытовыми устройствами в квартире или доме. Цифровые видеомагнитофоны (DVR), медиасерверы, сетевые устройства хранения (NAS), радиоприемники AM/FM-диапазонов, а также приемники спутниковых сигналов и т.д. будут располагаться централизованно в одном аппаратном блоке, обслуживающем все медиапотоки. Похожие системы уже довольно хорошо развиты (например, UPnP/DLNA). Использование в них транспортных протоколов AVB позволит расширить сферу применения и сделать их более доступными. Все устройства будут иметь один и тот же разъем RJ45.
Профессиональные аудио- и видеосистемы также выиграют от перехода на единую сеть, обслуживающую все три типа информации. Во-первых, существенно снизятся затраты на организацию и эксплуатацию сети. Кроме того, появится централизованное управление, схемы резервирования и диагностики.
В автомобильных системах применение Ethernet AVB позволило бы расширить пропускную способность и повысить гибкость. В настоящее время идет разработка автомобильных систем, совмещающих в себе развлекательные и информационные (помощники водителя и пр.) приложения с использованием стандарта.
Литература
1. R. Boatright. Understanding IEEE’s new audio video bridging standards//wcww.embedded.com/217201257?pgno=1.