CC BY
163
X КОДИРОВАНИЕ И ПЕРЕДАЧА ИНФОРМАЦИИ
УДК 621.397
АНАЛИЗ КАЧЕСТВА ПЕРЕДАЧИ ПОТОКОВОГО ВИДЕО В БЕСПРОВОДНЫХ AD-НОС-СЕТЯХ
Ф. А. Таубин,
доктор техн. наук, профессор
А. В. Чуйков,
аспирант Санкт-Петербургский государственный университет аэрокосмического приборостроения
Рассматривается передача потокового видео в беспроводной сети, использующей режим 802.11 ad-hoc. Качество передачи оценивается пиковым отношением сигнал/шум и сквозной задержкой декодированного видео. Для двух типичных топологий сети с помощью моделирования анализируется влияние степени компрессии потокового видео на качество передачи.
Ключевые слова — потоковое видео, беспроводные сети, топология сети, RTP/UDP пакеты, симулятор NS-3, пиковое отношение сигнал/шум, сквозная задержка, сетевой джиттер.
Введение
Доставка мобильным беспроводным пользователям видеоконтента, включая потоковое видео, и обеспечение доступа к таким видеосервисам, как видеотелефония и видеоконференции, составляют доминирующую долю трафика в локальных и региональных беспроводных сетях, а также в сотовых 3G- и LTE-сетях [1]. Одним из наиболее быстро развивающихся сегментов локальных беспроводных сетей являются ad-hoc-сети, обладающие такими привлекательными качествами, как быстрота развертывания, гибкость структуры, мобильность и живучесть [2, 3]. Проблемы, связанные с организацией эффективной передачи видео в беспроводных ad-hoc-сетях, весьма многообразны и порождаются, главным образом, следующими факторами. Во-первых, для такого рода сетей характерно случайное изменение во времени величины доступной скорости (the available throughput) передачи между передающим и приемным узлами. Это объясняется как мобильностью пользователей, так и изменением текущей топологии сети. Во-вторых, передача пакетов в такой сети характеризуется сравнительно высоким уровнем вероятности неправильного приема и (или) стирания пакетов. В качестве третьего фактора следует выделить появление задержек и сетевого джиттера в процессе доставки пакетов, изменение порядка следования пакетов, а также потерю пакетов вследствие
перегрузки сети. В интерактивных сервисах, таких как видеоконференции, допустимая сквозная задержка (end-to-end latency) жестко ограничена и, как правило, не должна превышать 150 мс [4]. Дополнительные проблемы вносит и возможная потеря локальной синхронизации в битовом потоке компрессированного видео.
В связи с тем, что доступная скорость передачи априори неизвестна и меняется в процессе передачи, а введение переспросов приводит, как правило, к неприемлемо большим задержкам, рациональный метод передачи видеоконтента должен базироваться на адаптации параметров видеокодека (в первую очередь, скорости кодирования) к текущей доступной скорости передачи, оцениваемой на основе получаемой информации
о состоянии сети.
Интуитивно понятно, что для простейшей топологии типа «точка-точка» передача видео со скоростью, близкой к доступной скорости в канале, обеспечит, видимо, наилучшее качество доставленного видео. В то же время, при наличии промежуточных и (или) интерферирующих узлов такая стратегия передачи, возможно, будет сопровождаться заметным возрастанием доли потерянных и (или) ошибочных пакетов, что приведет к существенному ухудшению качества доставленного видео. При уменьшении скорости кодирования видео, с одной стороны, снижается нагрузка на сеть и тем самым возрастают надежность и своевременность доставки пакетов. С дру-
гой стороны, уменьшение скорости кодирования сопровождается ухудшением отношения сигнал/ шум (ОСШ) в компрессированном видео. Кроме того, высокая степень сжатия приводит к большей чувствительности компрессированного видео к ошибкам, возникающим в процессе передачи. Таким образом, можно говорить о своего рода оптимальной (в рамках некоторой модели) скорости кодирования (степени сжатия) видеоконтента, предназначенного для передачи в ad-hoc-сети. В более общем контексте возникает задача выбора скорости кодирования видео, согласованной с протоколом передачи и текущим состоянием сети, включающим такие характеристики, как топология, метод маршрутизации, количество промежуточных и (или) интерферирующих узлов и т. д.
Данная работа посвящена рассмотрению одного из аспектов этой задачи — анализу влияния такого фактора, как наличие промежуточных и интерферирующих узлов ad-hoc-сети, во-первых, на соотношение оптимальной скорости кодирования видео и доступной скорости передачи в сети и, во-вторых, на величину суммарного времени задержки при доставке видеокадров получателю.
Модель передачи рассматриваемой сети
В работе исследуется передача видео в локальной беспроводной WiFi-сети, функционирующей на основе стандарта 802.11Ь. Номинальная скорость передачи V составляет 1, 2, 5 и 11 Мбит/с в зависимости от выбранного вида модуляции-кодирования. Распределение общего ресурса сети между активными пользователями, базирующееся на процедуре ОЯМА/ОА, подчиняется правилу, согласно которому скорость передачи, выделяемая активному пользователю, примерно обратно пропорциональна числу таких пользователей. В результате при нескольких активных пользователях в сети доступная скорость передачи оказывается заметно меньше номинальной скорости.
Рассматриваемая в работе схема передачи представлена на рис. 1. В качестве передаваемого
видео в работе использовались стандартные видеоклипы Foreman и Ref7, характерной особенностью которых является наличие существенной доли динамических фрагментов. Для создания компрессированных видеофайлов использовался открытый проект FFmpeg [5], на основе которого формируется большое число мультимедиаприложений. Широкий выбор кодеков, настроек процедуры кодирования, высокая скорость работы и постоянные обновления делают FFmpeg эффективным инструментом кодирования/декодирования видео. В данной работе FFmpeg использовался для компрессии видео и создания RTP-потока [6], а также восстановления (декодирования) RTP-потока.
Текущие ограничения в FFmpeg не позволяют сохранять RTP-пакеты в файл или читать их из файла. Вывод и ввод производятся UDP-пакетами на адрес и порт, указанные в файле протокола управления сессией (Session Description Protocol — SDP) [7]. Вспомогательная утилита сохраняет пакеты, которые будут использоваться в дальнейшем для моделирования процесса передачи. Эта же утилита способна воспроизводить сохраненные RTP-пакеты для восстановления видео с помощью FFmpeg.
Для оценки качества восстановленного видео в работе используется наиболее распространенная метрика — пиковое ОСШ (Peak Signal-to-Noise Ratio — PSNR). Примерное соотношение между PSNR и метрикой, базирующейся на субъективном восприятии (Mean Option Score — MOS), приведено в работе [8].
Среда моделирования
В качестве моделирующей программы был выбран Network Simulator 3, NS-3 [9]. Этот симулятор дискретных событий предназначен для исследования протоколов сетей (в том числе Интернета) и моделирования больших систем. Разработка моделей с использованием NS-3 близка по своей сути к созданию классических объектноориентированных многопоточных приложений на языке C++. Можно выделить три основные части программы.
1. Инициализация узлов сети (тип трафика, расположение и т. д.) и настройка характеристик (скорости передачи, очереди приемников и передатчиков и т. д.). Выбор топологии сети и ее характеристик.
2. Непосредственно моделирование работы сети. Следует отметить, что моделирование работы сети отнюдь не сводится к организации передачи трафика между узлами. Во время моделирования возможно включение и (или) удаление узлов из сети, изменение интенсивности трафика
Оригинальный
клип
Восстановлен -ный клип
Видеокодер (FFmpeg) SDP Настройки для воспроизве- SDP Видеодекодер
дения (SDP) (FFmpeg)
Компрессированное видео
т
і
Компрессированное видео
RTP-dump
RTP-
пакеты
т„ \ Параметры восстановления
Кодек, скорость, GOP гг
RTP-dump
Размер пакета
UDP-пакеты
Параметры канала, топология сети
і т У т
Массив UDP-пакетов UDP- ь Моделирование
пакеты передачи
UDP- пакеты и временные метки
UDP- пакеты - и временные
Массив UD P-пакетов и меток
■ Рис. 2. Схема программной модели
метки
и его типа, перемещение узлов в пространстве и изменение характеристик среды.
3. Моделирование заканчивается сбором статистики и ее обработкой. Условие окончания моделирования настраивается пользователем.
Модель передачи видео в ad-hoc-сети, построенная с использованием симулятора NS-3 (рис. 2), включает в себя фиксированные и настраиваемые параметры. Под параметрами понимаются настройки всех программ в комплексе моделирования, а именно NS-3, FFmpeg и утилиты. К фиксированным, т. е. жестко запрограммированным параметрам относятся:
— размер UDP-пакета, равный 2000 Б;
— минимальный квант времени, который используется при описании топологии и составляет 1 мс;
— протокол маршрутизации в сети (в модели используется OLSR (Optimized Link-State Routing) — оптимизированная маршрутизация по состоянию канала [10]);
— стандарт связи — IEEE 802.11b.
Все узлы полагаются неподвижными, но расположение узлов при запуске может быть случайным. К настраиваемым параметрам модели относятся:
— передаваемые видеоклипы: 1) Foreman (разрешение SIF 352 х 288 пикселей с частотой 30 кадров/с, цветовое пространство YCbCr 4:2:0), длительность 300 кадров и 2) Ref7 (разрешение DVD 720 х 576 пикселей с частотой 30 кадров/с, цветовое пространство YCbCr 4:2:0), длительность 220 кадров;
— кодек из множества MPEG1, MPEG2 и MPEG4;
— скорость кодирования R от 200 Кбит/с до 4000 Мбит/с;
— порядок следования кодированных кадров (group of pictures — GOP). Как правило, GOP-последовательность IP...PIP...P... выбирается из условия, что время между соседними I кадрами не превышает 1 с;
— номинальная скорость передачи V (1; 2; 5,5 и 11 Мбит/с);
— топология сети (рассматривается ниже);
ИМ^ 4Ї
— допустимая задержка на приемной стороне от начала приема до начала декодирования.
Очевидно, многие из настраиваемых (а также частично фиксированных) параметров будут меняться при рассмотрении других кодеков (например, VP8), клипов и беспроводных сетей (например, IEEE 802.16s).
Топология сети и доступная скорость
В программе моделирования используется стек протокола IPv4 (с небольшими изменениями его можно заменить на IPv6). Все узлы лежат в одной подсети 10.1.1.0/24, начиная с адреса 10.1.1.1 и до 10.1.1.254. Расположение узлов в одной сети позволяет с минимальными изменениями конфигурационных файлов легко настраивать топологию. Топология сети описывается в конфигурационном файле. Каждая строчка файла, которая не начинается со знака диез #, описывает одну сущность — узел или соединение.
Узел описывается следующей строкой:
node тип_узла соединение тип_координат вектор_координат.
Возможные значения и описание параметров узла приведены в табл. 1.
Пример описания узла:
node normal 0 const 30 90 0 node src 2 uniformr 15 30 45 5 0 0
Для задания параметров соединения используется схожий синтаксис:
link соединение тип_трафика параметры_трафика размер_пакета
Возможные значения и описание параметров соединения приведены в табл. 2.
Пример описания соединений:
link 0 const 30 1000 link 2 uniform 20 50 1000
В работе используются две топологии, иллюстрирующие односкачковую (single-hop) и много-скачковую (multi-hop) ad-hoc-сети. Топология 1 тривиальна и содержит два узла (передатчик и приемник), расположенных в прямой видимости друг от друга. Такая топология позволяет получить результаты, которые являются верхней границей (в смысле качества передачи) для дру-
■ Таблица 1. Значения и описания параметров узла
Имя параметра Значение Описание
тип_узла src Источник пакетов
dst Приемник пакетов
normal Промежуточный узел
соединение Целое число, больше или равное 0 Номер соединения, значение 0 зарезервировано для передачи видео
тип_координат const Постоянное положение задается тремя координатами по осям X, У, Z в метрах в параметре вектор_координат
uniform Положение выбирается случайно с равномерным распределением в интервалах от хт1п до от ут1п до утах и от до ^ах в метрах в параметре вектор_координат
uniformr Положение выбирается случайно с равномерным распределением в интервалах от X - Ях до X + Ях, от У - до У + и от Z - Я, до Z + Я, в метрах. Таким образом, в параметре вектор_координат задаются пары центр и радиус для каждой координаты
вектор_координат Вектор вещественных чисел См. тип_координат
■ Таблица 2. Значения и описания параметров соединения
Имя параметра Значение Описание
соединение Целое число, больше или равное 0 Номер соединения; значение 0 зарезервировано для передачи видео, которое игнорирует нижеследующие параметры
тип_трафика const Постоянная интенсивность, задаваемая в скалярном параметре параметры_ трафика
uniform Случайная интенсивность, равномерно распределенная в интервале от £т1п до £тах в параметре параметры_трафика
параметры_трафика Вектор целых чисел См. тип_трафика
размер_пакета Целое число Целое положительное число, которое задает размер пакета
гих, более сложных топологий. Топология 2 включает промежуточные и интерферирующие узлы.
Топология 1:
node src 0 const 0 0 0 node dst 0 const 30 0 0 link 0 const 30 1000
Топология 2:
node src 0 const 0 0 0 node normal 0 const 30 0 0 node normal 0 const 60 0 0 node normal 0 const 90 0 0 node dst 0 const 120 0 0 node src 2 uniformr 15 30 45 5 0 0 node dst 2 uniformr 45 30 45 5 0 0 node src 1 uniformr 15 30 65 5 0 0 node dst 1 uniformr 45 30 65 5 0 0 link 0 const 30 1000 link 2 uniform 20 50 1000 link 1 uniform 500 600 1000
Как видно из описания топологии 2, видео
должно пройти от узла (0, 0, 0) до узла (120, 0, 0)
через три промежуточных узла. Два интерферирующих соединения расположены в непосредственной близости от промежуточных узлов, участвующих в передаче видео. Схематичное изображение топологий 1 и 2 представлено на рис. 3, а и б. Расстояние между соседними узлами выбрано с учетом того, что при максимальной скорости 11 Мбит/с предельная дальность (Tx range), позволяющая обеспечить приемлемую вероятность ошибки, на практике близка к 30 м [11].
Для обеих топологий путем моделирования передачи UDP-пакетов были определены значения доступной скорости передачи С при номинальных скоростях 1; 2; 5,5 и 11 Мбит/с. По результатам, представленным в табл. 3, видно, что
' Узлы видеопередачи
о-----------а—►
ЗО
б)
Узлы помехи ) с 45 Узлы видеопередачи З 4 5
15
1 2
1 J KJ «■ ЗО ЗО ЗО ЗО
■ Рис. 3. Схематичное изображение топологий 1 (а) и 2 (б)
■ Таблица 3. Доступные скорости для топологий 1 и 2
Номинальная скорость V, Мбит/с Доступная скорость (throughput) С, Мбит/с
Топология 1 Топология 2
1 О,92 О,42
2 1,75 О,2І
5,5 4,1З 1,2
11 6,75 1,74
доступная скорость С оказывается существенно меньше номинальной скорости V даже для соединения «точка-точка». Это объясняется, главным образом, тем, что заметную долю в общем трафике составляет служебная информация, а именно заголовки и RTS/CTS/ACK пакеты. Для многоскачковой сети к указанному фактору добавляется эффект разделения скорости между частью узлов, что в еще большей степени снижает доступную скорость. Более того, в рассматриваемой многоскачковой сети увеличение номинальной скорости с 1 до 2 Мбит/с сопровождается снижением доступной скорости с 0,42 до
0,21 Мбит/с. Этот парадокс объясняется следующим обстоятельством. При номинальных скоростях 1 и 2 Мбит/с предельная дальность передатчика превышает 60 м, поэтому протокол маршрутизации обнаруживает, что узел 3 доступен для узла 1 без промежуточного узла 2 и, соответственно, назначает ему маршрут без промежуточного узла 2. В результате отношение сигнал/помеха на входе приемника узла 3 падает примерно на 6 дБ, что оказывается более критичным при номинальной скорости 2 Мбит/с (для нее изначально отношение сигнал/помеха на 3 дБ меньше, чем для скорости 1 Мбит/с ).
Организация передачи RTP-пакетов
Каждый компрессированный кадр видео в формате RTP разбивается согласно указанным в работе [12] правилам на п пакетов. Величина п зависит от скорости компрессированного видео Я (чем выше скорость, тем больше величина п), типа кадра (ключевой кадр требует, в общем случае, большего значения п) и природы видео. За время длительности кадра т следует отправить п пакетов длины 1к, £ = 1, 2, ..., п, для одного видеокадра при доступной скорости передачи С. Таким образом, время, затрачиваемое на передачу одного кадра:
*=1(1) ск=1
Для больших битовых скоростей большинство RTP-пакетов подвергаются разбиению на пакеты максимально возможной длины 1тах; это означа-
йй^ 43
ет, что время передачи одного кадра можно оценить сверху в виде
* £ ^Лпах. (2)
_ С
Если I < т, то передача следующего кадра начинается через интервал т относительно начала передачи текущего. Если время передачи текущего кадра оказывается больше т, то кадры, следующие за текущим, отбрасываются до тех пор, пока текущий кадр не передан. Количество отброшенных кадров
nd =
-1 =
ln
тс ^lk т Ck=1
-1. (3)
Используя оценку (2) в выражении (3), получаем верхнюю границу для количества отброшенных кадров
п1ша
nd <
т C
-1, (4)
позволяющую, в свою очередь, оценить степень ухудшения качества принятого видео. Указанная стратегия гарантирует отправку текущего кадра и, как показывает анализ, в сочетании с подходящей процедурой маскирования пропущенных кадров в большинстве ситуаций оказывается более эффективной с точки зрения качества, чем частичная отправка нескольких кадров.
Результаты моделирования
В процессе моделирования оба видеоклипа кодировались тремя видеокодеками (MPEG1, MPEG2 и MPEG4) со скоростями кодирования (компрессии) R в диапазоне 200 -г- 4000 Кбит/с (для клипа Foreman) и 1000 -г- 4000 Кбит/с (для клипа Ref7). Отметим, что для обоих клипов даже на нижней границе диапазона скоростей кодирования обеспечивается отличное либо хорошее качество по шкале MOS. Кодированное видео передавалось по сети с возможными номинальными скоростями V = 1; 2; 5,5 и 11 Мбит/с.
Топология 1. На рис. 4 представлены результаты вычисления ОСШ (PSNR) в декодированном клипе Foreman для указанных значений доступных скоростей. В качестве верхней границы на рис. 4 (и последующих рисунках) используется функция «PSNR — скорость кодирования», соответствующая видеокодеку MPEG4. Для клипа Ref7 результаты, характеризующие PSNR в декодированном видео, показаны на рис. 5. По результатам можно сделать выводы, что, во-первых, при номинальных скоростях 1 и 2 Мбит/с оптимальная (в смысле максимума PSNR) скорость кодирования R0 несколько превосходит доступную скорость C (отношение R0 / C находится в ин-
тервале от 1,04 до 1,31). Во-вторых, если скорость кодирования Я не превосходит оптимальную скорость Я0, влияние канала на качество принятого видео практически несущественно (ухудшение составляет от 0,01 до 0,5 дБ). В-третьих, при превышении оптимальной скорости кодирования Я0 качество принятого видео быстро падает до неприемлемых значений (плохое качество по шкале МОЯ).
Топология 2. В этой топологии, как указано выше, присутствуют узлы, генерирующие ин-
a)
PSNR, дБ
Скорость ко мпрессии, Кбит/с
Скорость ко мпрессии, Кбит/с
б)
PSNR, дБ
2ОІ________._________________________________________________._._._._._J
О 5ОО ІООО І5ОО 2ООО 25ОО ЗООО 35ОО
Скорость компрессии, Кбит/с
г)
Скорость компрессии, Кбит/с
■ Рис. 4. PSNR в декодированном видео: топология 1, клип Foreman, номинальная скорость V = = 1 Мбит/с (а); 2 Мбит/с (б); 5,5 Мбит/с (б); 11 Мбит/с (г)
PSNR, дБ
1000
MPEG1 MPEG2 MPEG4
Верхняя граница
1500 2000 2500 3000
Скорость компрессии, Кбит/с
а)
35 30 25 20
б)
38
36 З4 З2 30
1000 1500 2000 2500 3000
Скорость ко мпрессии, Кбит/с
б)
38 PSNR, дБ.......................................
PSNR, дБ
MPEG1 30 t/V/ MPEG1
MPEG2 MPEG2
MPEG4 25 / MPEG4
-■■-Верхняя граница -*■-Верхняя граница
3500
36 34 32 30
1000 1500 2000 2500 3000 3500 4000
Скорость ко мпрессии, Кбит/с
■ Рис. 5. PSNR в декодированном видео: топология 1, клип Ref7, номинальная скорость V = = 2 Мбит/с (а); 5,5 Мбит/с (б); 11 Мбит/с (б)
MPEG1 - 30 MPEG1
MPEG2 MPEG2
MPEG4 - 25 MPEG4
-■■-Верхняя граница -■^Верхняя граница
a)
35
30
25
20
І5
І0
PSNR, дБ
MPEG1
- MPEG2 -
MPEG4
-■^Верхняя граница
100 200 300 400 500 600 700 800 900
Скорость ко мпрессии, Кбит/с
б)
40
35
PSNR, дБ
400 800 І200 І600
Скорость компрессии, Кбит/с
2000
б)
40
35
PSNR, дБ
20
500 1000 1500 2000 2500 3000
Скорость компрессии, Кбит/с
■ Рис. б. PSNR в декодированном видео: топология 2, клип Foreman, номинальная скорость V = = 1 Мбит/с (а); 5,5 Мбит/с (б); 11 Мбит/с (б)
терферирующую помеху, и дополнительные промежуточные узлы. Влияние интерферирующей помехи и промежуточных узлов проявляется следующим образом. Интерферирующий трафик, во-первых, потребляет какую-то часть доступной скорости передачи в сети (в силу механизма доступа CSMA/CA) и, во-вторых, искажает передаваемый сигнал, приводя к дополнительным ошибкам в передаче. Промежуточные узлы, в свою очередь: а) также занимают какую-то часть доступной скорости передачи; б) могут отбрасывать пакеты из-за переполнения буфера и в) могут пропускать отправку кадра, если предыдущий кадр еще не завершил передачу. Рис. 6 иллюстрирует влияние перечисленных факторов при передаче клипа Foreman.
Для сети с топологией 2 характерно следующее (см. рис. 6). Во-первых, оптимальная скорость кодирования R0 вновь оказывается близка к доступной скорости C (отношение R0 / C находится в интервале от 0,95 до 1,04); во-вторых, проигрыш (относительно варианта передачи в то-
пологии 1) составляет 5-6 дБ. Для клипа Ref7 передача даже с наибольшей компрессией из рассмотренного диапазона (скорость кодирования Я = 1 Мбит/с) сопровождалась неприемлемым качеством при номинальных канальных скоростях
1 и 2 Мбит/с. Результаты моделирования для скорости 11 Мбит/с показаны на рис. 7. Как видим, здесь отношение Я0 / С = 1,15, а проигрыш (отно-
PSNR, дБ
35 -30 25 20
І000
MPEG1 MPEG2 MPEG4
Верхняя граница
1500 2000 2500 3000 3500
Скорость ко мпрессии, Кбит/с
■ Рис. 7. PSNR в декодированном видео: топология 2, клип Ref7, номинальная скорость V = 11 Мбит/с
Время задержки, мс
■ Рис. 8. Текущее суммарное время задержки для клипа Foreman: топология 2, скорость кодирования R = 200 Кбит/с, номинальная скорость V = 1 Мбит/с
сительно варианта передачи в топологии 1) составляет около 5 дБ.
Таким образом, проведенные эксперименты показывают, что: 1) для обеих топологий оптимальная скорость кодирования R0 оказывается близка к доступной скорости передачи C и 2) увеличение дальности передачи в 4 раза, достигаемое при использовании многоскачковой сети с интерферирующими узлами, сопровождается ухудшением PSNR на 5-6 дБ (при этом качество остается отличным по шкале MOS).
Суммарное время задержки. Анализ причин задержки при доставке видеокадров в рамках топологии 2 показал следующее. Задержки возникают вследствие затрат времени на передачу сообщения, его ожидание в очереди и необходимости ретрансляции на другой узел. Соседние узлы могут занимать общую среду, увеличивая время на передачу. Основным фактором, определяющим величину задержки, является соотношение скорости кодирования и доступной скорости передачи. Для оценки влияния этого соотношения были рассмотрены три варианта передачи с номинальной скоростью передачи V = 1 Мбит/с, что соответствует доступной скорости C = 420 Кбит/с. В первом варианте скорость кодирования R составляла 200 Кбит/с. На рис. 8 приведены текущие значения суммарного времени задержки при доставке видеокадров для клипа Foreman.
Как видно из графика, максимальное значение задержки не превосходит 150 мс, а джиттер находится в приемлемом диапазоне, так что буфер подходящего размера обеспечит плавное воспроизведение видео. При небольшом увеличении
скорости кодирования (до 230 Кбит/с) задержка резко увеличилась почти в 7 раз, достигнув 1 с. И, наконец, при Я = 400 Кбит/с задержка в течение первой же секунды с момента начала передачи стала лавинообразно нарастать и достигла 8 с. Такая задержка допустима, если речь идет просто о доставке видео. Вместе с тем для интерактивных приложений приемлемая скорость кодирования, как видим, оказалась примерно вдвое меньше величины С, что, в свою очередь, привело к снижению PSNR примерно на 3 дБ.
Заключение
В данной работе анализировалось качество передачи видео в односкачковой и многоскачковой а^Иое-сетях. Ключевым фактором, определяющим качество передачи, является отношение скорости кодирования видео Я к доступной скорости передачи в сети С. С точки зрения максимизации PSNR в доставленном видео, оптимальное значение отношения Я / С оказалось близким к 1 для обеих топологий. Увеличение дальности передачи вчетверо, достигаемое при переходе от одно-скачковой топологии к рассмотренной в работе многоскачковой топологии с интерферирующими узлами, сопровождалось ухудшением величины PSNR на 5-6 дБ. Тем не менее, качество доставленного видео оставалось отличным по шкале MOS. В интерактивных приложениях (с допустимой задержкой порядка 150 мс) оптимальное отношение Я / С при передаче в многоскачковой сети оказалось существенно меньше 1: в наших экспериментах это отношение было близко к 0,5. Как следствие, PSNR в доставленном видео дополнительно снизилось примерно на 3 дБ.
Одним из инструментов улучшения качества передачи видео в а^Иое-сетях представляется совершенствование использованного в работе алгоритма маршрутизации OLSR с тем, например, чтобы исключить появление парадоксов, аналогичных тому, что был отмечен при обсуждении полученных при моделировании доступных скоростей передачи в сети (см. табл. 3). Желательно, в частности, чтобы алгоритм маршрутизации учитывал не только доступность узлов, но и уровень отношения сигнал/шум на входе узла. Это позволит трафику с высокой чувствительностью к потерям пакетов проходить по более надежным каналам, пусть и с большим числом промежуточных узлов. Для менее чувствительного трафика или трафика с низкой интенсивностью можно использовать «прямой» маршрут с худшим значением сигнал/шум на входе узла. Такая модификация протокола маршрутизации позволит, как представляется, увеличить доступную скорость передачи в многоскачковой а^Иое-сети.
Литература
1. Cai L., Shen X., Mark J. W. Multimedia Services in Wireless Internet // Modeling and Analysis. June 2009. P. 52-57.
2. Ramanathan R., Radi R. A Brief Overview of Ad Hoc Networks: Challenges and Directions // IEEE Communication Magazine. May 2002. Р. 20-22.
3. Винель А. В., Дудин А. Н., Андреев С. Д., Тюрли-ков А. М. Анализ алгоритмов распространения тревожного сообщения c глобальным знанием в беспроводных сетях передачи данных с линейной топологией // Информационно-управляющие системы. 2010. № 3. С. 56-60.
4. Apostolopoulos J. G., Tan W.-T., Wee S. Video Streaming: Concepts, Algorithms and Systems // Technical Report HPL-2002-260. HP Laboratories, Sept.
2002. P. 1-34.
5. FFmpeg Multimedia System. http://ffmpeg.org/doc-umentation.html (дата обращения: 25.01.2012).
6. RTP: A Transport Protocol for Real-Time Applications // Request for Comments (RFC) 3550. July
2003. http://www.linuxdig.com/rfc/individual/3550. php (дата обращения: 25.01.2012).
7. Handley M., Jacobson V. SDP: Session Description Protocol // Request for Comments (RFC) 2327. Apr. 1998. http://www.linuxdig.com/rfc/individual/2327. php (дата обращения: 25.01.2012).
8. Ohm J.-R. Multimedia Communication Technology. — Heidelberg: Springer, 2004. — 859 р.
9. Network Simulator 3. http://www.nsnam.org/docs/ release/manual.pdf (дата обращения: 25.01.2012).
10. OLSR: Optimized Link State Routing Protocol // Request for Comments (RFC) 3626. Oct. 2003. http://www.linuxdig.com/rfc/individual/3626.php (дата обращения: 25.01.2012).
11. Anastasi G., Borgia E., Conti M., Gregory E. Wi-Fi in ad hoc mode: a measurement study: Proc. of IEEE Int. Conf. on Pervasive Computing and Communications. Mar. 2004. Р. 145-154.
12. Чуйков А. В. Влияние размера пакета передачи видеоинформации на качество восстановленных видеопоследовательностей в беспроводных сетях // Телекоммуникации и транспорт. 2010. № 3. С. 32-34.
Международная выставка «Охрана, безопасность, противопожарная защита — SIPS 2012»
16—18 октября 2012
Место проведения: г. Краснодар, ВЦ «КраснодарЭКСПО»
Организатор
Выставочная компания ITE Moscow
При поддержке
МВД России
Министерства транспорта РФ Федеральной таможенной службы МЧС Краснодарского края Администрации Краснодарского края ВДПО
Основные разделы выставки
Технические средства обеспечения безопасности Системы охранного телевидения и наблюдения Защита информации, смарт-карты Современные системы связи, оповещения и телекоммуникаций Пожарная безопасность Таможенный контроль Пограничный контроль
Выставка SIPS 2012 по традиции будет проходить в рамках проекта IDES, объединившего на одной выставочной площадке 7 специализированных выставок. По признанию специалистов IDES, это уникальный отраслевой коммуникационный проект, сумевший охватить основные направле-
ния экономики края и объединить вокруг себя профессионалов.
Выставка представляет полный спектр продукции и услуг для комплексного обеспечения безопасности во всех сферах современной жизни. Важным стимулом для участия и посещения выставки является насыщенная деловая программа, представленная конференциями, семинарами, круглыми столами. Участники — специалисты строительных компаний, проектно-монтажных организаций, торговли, органов управления, банков, армии, НИИ, представители отраслей промышленности.
Участникам выставки SIPS 2012 предоставится уникальная возможность встретиться на одной площадке с представителями отраслевых министерств и департаментов Южного федерального округа, специалистами ведущих нефтегазовых и энергетических компаний края.
Формирование выставочной экспозиции и деловой программы продолжается.
Дополнительная информация и справки Тел.: +7 (495) 935-73-50, доб. 4242 Эл. адрес: ides@ite-expo.ru
Сайт: http://www.ides-expo.ru/home/exhibitions/ sips.aspx
ИНФОРМАЦИОННО-УПРАВЛЯЮЩИЕ СИСТЕМЫ 47
