Передача видеоинформации

Видеоинформация может передаваться по сети без сжатия или со сжатием. В последнем случае говорят о так называемом «сжатом видео». Для передачи видео без сжатия определен ряд форматов, требующих определенной пропускной способности. При этом в зависимости от установленного разрешения кадр может заполнять как весь экран, так и его часть (табл. 18.1). При передаче используется общий промежуточный формат CIF (Common Intermediate Format), который также называют FCIF (Full CIF). Стандартными производными от последнего формата являются форматы QCIF (Quarter CIF) и SQSIF (Subquarter CIF).

Таблица 18.1. Требования к пропускной способности (видео без сжатия)

Формат	Разрешение по горизонтали	Разрешение по вертикали	Количество пикселов в кадре	Частота посылки, кадры в секунду	Полоса пропускания, Мбит/с
Полный экран			307 200
Полный экран			307 200
1/2 экрана			153 680
1/2 экрана			153 680
CI			101 376
CIF
1/4 экрана			76 800
1/4 экрана
QCIF
QCIF
1/16 экрана
1/16 экрана
SQCIF
SQCIF

Примечание: все данные приведены в предположении глубины цвета в 16 бит.

В настоящее время передача видеоинформации без сжатия используется довольно редко. Это связано с широкой полосой пропускания, которая необходима для такой передачи. Несжатая видеоинформация обычно используется в сетях тех организаций, которые не испытывают проблем с предоставлением достаточной пропускной способности. Различные форматы изображений (в зависимости от размера картинки, ее разрешения и количества кадров, передаваемых в секунду) требуют различной пропускной способности. В табл. 18.2 описаны требования к пропускной способности для различных форматов изображения, используемых как в мире персональных компьютеров (предназначенных для видеостандартов EGA, VGA и т. д.), так и тех, что применяются в телевидении (например, PAL и SECAM).

Применяя различные схемы кодирования видеоинформации, которые зависят от мощности процессоров обрабатывающих устройств и требуемого качества, можно значительно уменьшить необходимую пропускную способность. Для этого были разработаны различные схемы кодекса. Название этого устройства (codec) произошло от английских слов compressor и decompressor. To есть, это устройство, которое сжимает входящую видеоинформацию и восстанавливает ее в исходную форму на выходе.

Таблица 18.2. Требования к пропускной способности (полноэкранное видео без сжатия)

Формат	Пикселов налимий	Линии в кадре	Пикселов в кадре	Кадров в секунду	Пикселов в секунду (в миллионах)	Бит на пиксел	Мегабит в секунду
CGA			128 000		7.7		30.7
EGA			224 000		13.4	б	80.6
VGA			307 200		18.4	б	110.6
SVGA			480 000		34.6		276.5
NTSC			291 000		8.7		209.5
PAL			333 500		16.7		400.2
SECAM			333 500		16.7		400.2

Существует несколько форматов сжатия видеоинформации, одни из которых являются фирменными решениями, а другие – открытыми стандартами. Протоколы, реализующие эти форматы, включают методы оцифровки изображения (преобразования из аналогового сигнала в цифровой и обратно), а также компрессии и декомпрессии. При этом сжатие может производиться как внутри каждого кадра (так называемое пространственное сжатие), так и между кадрами. И то, и другое осуществляется с помощью специальных схем. Эти протоколы обеспечивают совместимость с протоколами низших уровней и проведение мультиплексирования различных потоков аудио- и видеоинформации от отдельных отправителей с последующим демультиплексированием на другом конце. Например, в наборе протоколов Н.320, используемых для видеоконференций, протокол Н.221 служит в качестве надстройки над протоколами низших уровней и отвечает за мультиплексирование, в то время как протокол Н.261 – это протокол для компрессии и декомпрессии видео.

В 1988 году была создана группа MPEG, основной задачей которой была разработка стандартов по сжатию аудио- и видеоинформации. В разработанных стандартах определялся входной битовый поток с неявным описанием алгоритмов кодирования и декодирования. В результате производители получили возможность, с одной стороны, реализовывать свои фирменные алгоритмы кодирования и декодирования, с другой стороны, им была обеспечена совместимость с промышленным стандартом. В сентябре 1990 года был представлен предварительный стандарт кодирования MPEG-1, а в январе 1992 года работа над ним была завершена. После этого был разработан и принят стандарт MPEG-2, который определяет потоки данных со скоростью от 3 до 10 Мбит/с.

Видеоинформация, сжатая в соответствии с форматами MPEG-1 и MPEG-2, различается по своему качеству. Хотя алгоритм MPEG-1 может работать с разрешениями до 720х480, обычно, видео кодируется при значительно меньшем разрешении (это делается, чтобы уменьшить интенсивность потока данных), что приводит к ухудшению качества изображения. MPEG-1 обычно ассоциируется с форматом SIF (разрешение 352х240), что аналогично качеству VHS (то есть бытового видеомагнитофона).

Формат MPEG-2 позволяет поддерживать более высокие разрешения (в том числе, 720х480). При этом скорость передачи видеоинформации примерно в четыре раза больше скорости передачи, которую способен поддерживать MPEG-1, что позволяет передавать с помощью формата MPEG-2 полноэкранные фильмы с телевизионным качеством. Важной особенностью формата MPEG-2 является наличие в нем расширений, которые служат для разделения видео на несколько независимо кодируемых потоков, что позволяет создавать независимые потоки с определенной интенсивностью в рамках одного видеосигнала.

В отличие от алгоритмов Motion-JPEG (которые кодируют кадры независимо, при этом каждый кадр кодируется по технологии JPEG) технология MPEG использует поточное сжатие видеоинформации, при котором происходит обработка не каждого кадра в отдельности, а производится анализ изменений отдельных фрагментов изображений и кодируется именно изменение сигнала, а не сам сигнал. При этом также происходит устранение избыточности. Так как в большинстве случаев фон изображения остается достаточно долго без изменений, а действие происходит только на переднем плане, то алгоритм MPEG начинает сжатие с создания исходного кадра. Эти кадры являются отправными для воссоздания фона на принимающей стороне; они размещаются последовательно через каждые 10-15 кадров, несущих «картинку» переднего плана. Только некоторые фрагменты изображений, которые находятся между ними, претерпевают изменения, и именно эта разница сохраняется при сжатии.

Одним из последних кодеков для видео в реальном времени является Real-Video. Компания Microsoft анонсировала кодек MPEG-4, предназначенный для видео в реальном времени. С другой стороны, кодек Н.263 уже поддерживается несколькими системами для проведения видеоконференций.

Использование различных методов сжатия видеоинформации позволяет значительно снизить требования к пропускной способности сети. В табл. 18.3 перечислены требования к пропускной способности при использовании существующих стандартов на сжатие.

Таблица 18.3. Требования к пропускной способности (сжатое видео)

Формат (стандарта)/Требование	Ориентировочная пропускная способность	Коэффициент сжатия
Motion 3PEG	10-20 Мбит/с	7-27:1
MPEG-1	1.2-2.0 Мбит/с	100:1
Н.261	64 Кбит/с–2 Мбит/с	24:1
DVI	1.2-1.5 Мбит/с	160:1
CDI	1.2-1.5 Мбит/с	100:1
MPEG-2	4-60 Мбит/с	30-100:1
CCIR 723	32-45 Мбит/с	3-5:1
Фирменные методы поставщиков (например, PictureTel SG3)	0.1-1.5 Мбит/с	100:1
Программное сжатие	2 Мбит/с,	6:1

Механизмы предоставления качества видео частично предусмотрены и в самих стандартах. Например, используя формат MPEG-2, уровень сжатия видеоинформации можно контролировать, добиваясь тем самым различного качества воспроизведения в зависимости от имеющейся пропускной способности. Для того чтобы оценить реальные потребности в пропускной способности сети, можно привести требования, предъявляемые видео различного качества, сжатого по алгоритму MPEG-2 (табл. 18.4).

Таблица 18.4. Требования к пропускной способности видео различного качества

Качество	Пропускная способность
Студийное	7 Мбит/с
Широковещательное	5Мбит/с
VHS	1.5 Мбит/с

Как видно, изображение с очень хорошим качеством (студийным) требует от сети пропускной способности менее 10 Мбит/с, что вполне может предоставить коммутируемое подключение Ethernet. Однако требования к пропускной способности возрастают, если по тем или иным причинам видеоинформацию сжимать нельзя. В некоторых приложениях (например, в медицине) даже небольшая потеря качества, вызываемая сжатием, недопустима. С другой стороны, если через одну и ту же инфраструктуру требуется передавать несколько видеопотоков, то пропускной способности в 10 Мбит/с, предоставляемой коммутируемым Ethernet, все равно становится недостаточно.

Необходимо отметить, что выбор кодека зависит от того, какая требуется пропускная способность и то, какое именно видео необходимо передавать: по требованию или в реальном времени.

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

Записанная видеоинформация может, грубо говоря, рассматриваться как большой массив данных. Для передачи этого массива данных пропускная способность, как правило, не резервируется, и он передается при доступных сетевых ресурсах. Такой массив данных может быть записан на CD-диски и передан потребителям видеоинформации по сети в необходимое время, или тогда, когда нагрузка на сеть минимальна – это пример подхода к передаче видео, как к передаче данных.

Некоторые производители предлагают организациям начать внедрение параллельной сети (дополняющей уже существующую сеть), которая предназначалась бы исключительно для передачи видеоинформации. Однако большое количество уже установленного оборудования и широкий спектр разработанных административных правил управления сетью делают это решение неподходящим для широкого внедрения. Исключением могут быть случаи, когда видеоконференции очень важны для обеспечения работы организации. Такой подход реализован сегодня в корпорациях, которые используют оборудование, поддерживающее стандарт Н.320.

Очевидное достоинство передачи видеоинформации по сети данных в том, что пользователи могут использовать существующую инфраструктуру, будь то традиционная локальная сеть или ATM.

Хотя сегодня аудиоинформация, видеоинформация и данные разделены, в будущем тенденция к интеграции различных услуг в одной сети усилится. Наиболее вероятным сценарием объединения будет следующий: на первом этапе произойдет интеграция передачи видеоинформации с передачей данных. После всесторонней эксплутационной «доводки» этой интегрированной технологии можно будет, опираясь на новые стандарты, приниматься за дальнейшее развитие системы передачи голоса по сети. А учитывая тенденцию объединения локальных сетей с сетями ATM, наметившийся симбиоз имеет все шансы стать широко доступным и повсеместно распространенным.

Видео в реальном времени и записанное видео предъявляют к сети определенные требования, необходимые, чтобы гарантировать высокое качество. К ним относятся: достаточная полоса пропускания, низкая задержка, небольшое дрожание и эффективный механизм групповой доставки. Достаточность полосы пропускания определяется объемом передаваемой информации и применяемыми методами сжатия. Низкая задержка необходима для организации сеансов связи «в прямом эфире», когда пользователи общаются непосредственно друг с другом в реальном времени. Устранение дрожания требуется приложениям, обеспечивающим однонаправленную передачу, – это необходимо для избежания «скольжения» кадров или потери синхронизации между звуком и изображением. И, наконец, групповая доставка нужна для того, чтобы видеоинформация не дублировалась несколько раз для нескольких пользователей.

Следует отметить, что если отправитель и получатель являются членами одной физической сети, процесс передачи и приема групповых сообщений на канальном уровне достаточно прост. Отправитель указывает IP-адрес группы получателей, а сетевая плата выполняет процедуру трансляции этого адреса в соответствующий групповой Ethernet-адрес и посылает кадр. Если отправитель и получатель находятся в разных подсетях, которые, однако, связаны маршрутизаторами, то доставка пакетов затруднена. В этом случае маршрутизаторы в сети должны поддерживать один из групповых протоколов маршрутизации (DVMRP, MOSPF, PIM). Этот протокол построит дерево доставки и передаст групповой трафик.

В основном, при использовании стандартных методов сжатия, таких как MPEG-2, видеоприложения предъявляют следующие конкретные требования к пропускной способности и задержкам (рис. 18.1).

Задержке	Приложения
≥300 мс (в одном направлении)	Обучение с помощью видео	Медицина
<300 мс (в двух направлениях)	Видеоконференции и видео по требованию	Интерактивное видео
	≤20Мбит/с	≥20 Мбит/с
	Полоса пропускания на пользователя

Рис. 18.1. Требования к задержке различных приложений

Задержка критична в ситуациях, когда происходит двунаправленное общение, так как в этом случае задержка в ответе одного из абонентов приводит к очевидным неудобствам в общении (что можно довольно часто наблюдать в наших новостях, когда диктор в студии в Москве общается с корреспондентом, находящимся где-нибудь в Вашингтоне). Один из абонентов должен ожидать до тех пор, пока удаленный абонент не закончит всю фразу целиком. В противном случае, из-за задержек, фраза может быть понята неправильно. Такая проблема достаточно ощутима, например, при использовании приложений стандарта Н.320. Хотя считается, что задержка больше зависит от времени компрессии и декомпрессии (например, у аппаратуры, предназначенной для поддержки видеоконференций, проведение компрессии и декомпрессии занимает порядка 220 мс), чем от коммутаторов или маршрутизаторов, сама сеть (особенно в крупных организациях) также может вносить значительные задержки. Вообще говоря, именно задержка определяет то, насколько пользователям удобно работать. Совокупная задержка при передаче видеоинформации представляет собой сумму задержек, вносимых при компрессии/декомпрессии на конечных станциях, и задержек на промежуточных устройствах в сети между абонентами. В результате, совокупная задержка может изменяться в зависимости от объема трафика в сети в определенный момент времени. Например, если говорить о передаче аудиоинформации, то проведенные исследования показали, что задержка в 50 мс практически не ощутима; если задержка находится в пределах 250-300 мс, это может вызвать некоторое раздражение абонентов, а при задержке в 600 мс и более качество воспроизведения речи становится неприемлемым.

Задержка при передаче информации по сети – а она, как мы видели, должна быть прибавлена к общей задержке – меняется в широких пределах. Для видеоконференций Н.320 по коммутируемым каналам ISDN задержка в сети составляет менее 10 мс и является постоянной величиной. В локальной сети на базе коммутаторов задержки составляют, как правило, менее 80 мс, но иногда возникают ситуации, когда они оказываются намного больше этого значения.

Существует достаточно жесткая схема привязки стандартов передачи видеоинформации к тем или иным сетевых технологиям. Организацией ITU разработана система рекомендаций по использованию различных стандартов для реализации тех или иных приложений. Эти рекомендации перечислены в табл. 18.5.

Технические требования к передаче видеоинформации в сетях ATM

Как уже не раз отмечалось, ATM была разработана как технология, поддерживающая передачу голоса, видео и данных. Можно сказать, что ATM разрабатывалась для работы с видеоприложениями, поддерживающими появлявшиеся в то время стандарты группы MPEG. С учетом того, что наиболее распространенным стандартом для проведения видеоконференций в настоящее время считается Н.320, появилась необходимость такой адаптации ATM, которая обеспечила бы контроль за задержкой и дрожанием.

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

q Коэффициент потери ячеек в сети не должен превышать 1.7 10^-9;

q Задержка при доставке ячейки через сеть не должна превышать 4 мс, а при прохождении через коммутатор – 150 мкс;

q Изменения в задержках при доставке через сеть должны варьироваться в пределах 500 мкс.

Если коммутаторы ATM удовлетворяют выдвинутым требованиям, то они могут принимать участие в процессе передачи высококачественной видеоинформации по сети.

Особенностью двунаправленного взаимодействия является необходимость реализации более строгого контроля за задержкой (по сравнению с однонаправленной передачей), о чем говорилось выше. При всей, казалось бы, жесткости ограничений по времени, видно, что даже для двунаправленной передачи видеоинформации средняя задержка и дрожание измеряется в миллисекундах, а не в микросекундах Это позволяет производителям иметь достаточный временной «зазор», облегчающий выпуск продуктов. В табл. 18.6 перечислены допустимые задержки и дрожание применительно к видео различного качества.

Таблица 18.6. Допустимые значения задержки и дрожания

Тип приложения	Приложение	Средняя допустимая задержка, мс	Среднее допустимое дрожание, мс
Начального уровня	Видеоконференция 64 Кбит/с
Сжатое видео 16 Кбит/с
Среднего уровня	1.5 Мбит/с МРЕG (видео)		6.5
	256 Кбит/с MPEG (голос)		9.1
Высокого уровня	20 Мбит/с HDTV-видео	0.8

Так как даже задержка в несколько сотен миллисекунд является приемлемой (для приложения начального уровня) при организации двунаправленного обмена видеоинформацией, то сеть ATM может легко справляться с такой нагрузкой. С точки зрения передачи высококачественного видео хорошие скоростные возможности сети ATM позволяют нейтрализовать некоторые «всплески задержек». Каждое приложение имеет некоторую рабочую область, границы которой определяют верхние и нижние допустимые значения задержки (или других параметров). На рис. 18.2 показаны рабочие области некоторых приложений в аспекте изменения двух параметров – времени задержки и надежности доставки.

С одной стороны, некоторые временные выбросы задержек сглаживаются возможностями технологии ATM, с другой стороны, их негативные последствия призваны устранить верхние уровни MPEG, точнее, их специальные механизмы. В частности, кодеки имеют внутренние буфера, которые позволяют «выровнять» сигнал при его небольшом дрожании. Более того, передача временной информации (нечто вроде временных меток) в потоках стандартов MPEG позволяет восстановить синхронизацию при наличии дрожания в сети. Так как значительное дрожание может привести к потере пакетов, то верхние уровни (выше сетевого) должны более эффективно оберегать поток видеоинформации от возможных потерь такого рода. Частично соответствующие возможности уже заложены в существующие спецификации MPEG. Ожидается, что они будут усилены с принятием нового видеостандарта, такого как цифровое телевидение высокого качества.

Одна из причин, по которой Форум ATM выделил спецификацию VBR (Variable Bit Rate – переменная скорость передачи), состояла в необходимости обеспечения передачи видеоинформации с переменной скоростью. Необходимость использования переменной скорости диктовалась применяемой схемой кодирования – при использовании для сжатия методов MPEG или Н.261 скорость передачи меняется в зависимости от интенсивности движения в кадрах. Уровень взрывообразности (то есть изменений интенсивности) для движущегося изображения зависит от качества видео (табл. 18.7)

Выделение полосы пропускания и проверка ее достаточности с помощью механизма САС (напомним, что он позволяет проверить наличие сетевых ресурсов для установления соединения) для видеоинформации и данных различных приоритетов как раз и позволяет обеспечивать такую передачу с определенным качестном обслуживания. Трафик с постоянной скоростью передачи, например, будет требовать наивысшего приоритета, в то время как нечувствительным к задержкам данным может быть предоставлен самый низкий приоритет. Трафику rtVBR может быть присвоен либо высокий, либо низкий приоритет в зависимости от требований пользователей.

Таблица 18.7. «Взрывообразность» видео

Тип видео	Отношение пиковой пропускной способности к средней
Видео студийного качества	1.9
Видео широковещательного качества	2.7
Видеоконференции	3.1
Видеотелефон	4.4

Нельзя говорить о широком развертывании в сети ATM видеоприложений и игнорировать при этом требования UPC (функции контроля за использованием полосы пропускания), которые гарантируют, что входящий трафик будет удовлетворять трафик-контракту, заключенному между пользователем и сетью. Без таких функций уже установленные соединения могут потерять свою производительность из-за неправомерных действий пользователей, нарушающих свои трафик-контракты. В результате, использование функций UPC является необходимым условием для сети ATM, которая должна поддерживать обмен видеоинформацией. Эти функции гарантируют, что трафик всех типов будет соответствовать своим трафик-контрактам и получит запрошенный уровень производительности от сети.

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

Важным параметром для передачи аудио- и видеоинформации является коэффициент потери ячеек (Cell Loss Rate, CLR). В целях снижения уровня потери ячеек при работе в сети ATM блоки данных уровня адаптации ATM (AAL PDU), содержащие мультимедийную информацию, кодируются с помощью процедуры коррекции ошибок Рида-Соломона (Reed-Solomon). Использование этой процедуры делает возможным корректировать потерю до четырех байт в блоке из 128. Если длина блока данных составляет только один байт, то эта процедура может скорректировать потерю до четырех ячеек. Теоретические исследования показывают, что когда поток ячеек следует через семь коммутаторов, каждый из которых выполняет до семи стадий коммутации, вероятность потери ячейки в блоке (длиной более четырех ячеек) очень мала. В табл. 18.8 показаны приемлемые коэффициенты потери ячеек (CLR) и битовых ошибок (Bit Error Rate, BER) для различных видеоприложений.

Дата добавления: 2015-07-13