 | ||||||||||||||||||||||||||||||||
 |
 |
 | ||||||||||||||||||||||||||||||
 |
 |
 | ||||||||||||||||||||||||||||||
 |
 |
 | ||||||||||||||||||||||||||||||
Исследование влияния коэффициента перегрузки канала на качество передаваемого видео потокаГончаров А.А. (ИТЭФ), А.Ю.Ильин (РОСНИИРОС), Семенов Ю.А. (ИТЭФ/МФТИ) 1. ВведениеШирокое внедрение IP-телефонии, цифрового ТВ поверх Интернет, P2P ТВ и других мультимедиа приложений ставит проблему обеспечения гарантированного качества передачи в условиях кратковременных и долговременных перегрузок. Мы исследовали влияние долговременных перегрузок на качество передачи потокового видео. Нами передавался видеоролик через тестовый канал, показанный на рис. 1  Рис. 1. Схема тестового канала На исходящем интерфейсе маршрутизатора на канальном уровне использовался протокол ATM. На канальном уровне ATM нами используется класс VBR-rt (Variable Bit Rate real-time) [1]. Всего в видеопотоке посылалось 300 кадров и это занимало 10 сек. Входной поток был практически постоянным. Обозначим его скорость через l[бит/сек], а пропускную способность на выходе канала обозначим m[бит/сек].. Если l≥m, l?m, потери качества передаваемого видеоролика не происходит. В противном случае возникает перегрузка канала. В зависимости от длительности перегрузки, маршрутизатор может помещать пакеты в буфер отправки либо отбрасывать их. В современном Интернете перегрузка каналов является обычным явлением. Но, несмотря на то, что большинство из нас работает через перегруженные каналы, мы всё же можем продолжать работать в сети. Цель нашего эксперимента заключалась в исследовании границ приемлемой перегрузки для передачи потокового видео. Как бы ни был перегружен канал, часть кадров из видео потока дойдут до получателя. Но сможет ли получатель что-нибудь увидеть и разобрать по цветным пятнам на экране и обрывкам звуков. Где та граница перегрузки канала, при которой ещё имеет смысл транслировать видео ролик по сети? Целью данной работы была попытка ответить на этот вопрос. 2. Описание экспериментаДля передачи видео использовался пакет программ Evalvid 2.1. [2] и кодек «Ffmpeg» [3] для кодирования и декодирования видеопотока. Для видеопотока мы варьировали соотношение l/m в пределах от 0,8 до 2,5 с шагом 0,1. Незакодированный файл видеоролика в формате YUV420 [4] занимал 45 Мбайт. В аббревиатуре YUV: Y – яркость, U=R-Y - разность между красной компонентой и яркостью, V=B-Y - разность между голубой компонентой сигнала и яркостью. Для передачи по сети файлы сжимались кодеком, затем производилась разбивка полученного файла по пакетам, и происходила передача данных через канал. Чтобы просмотреть видео ролик получатель должен получить пакеты и декодировать их. Во время передачи видео ролика по сети интервал следования пакетов может варьироваться, для компенсации этого эффекта на стороне получателя используют входной буфер. Для оценки качества принятого кадра используют следующие характеристики: Peak Signal-to-Noise Ratio (PSNR) и Mean Opinion Score (MOS) [5]. Качество видеоизображения – это субъективная характеристика. Метрика качества изображения основана на особенностях восприятия человека. Численная характеристика, основанная на субъективном восприятии человека, обозначается MOS и оценивается по пятибалльной шкале.
Рис. 2. ITU-R таблица оценок качества видеоизображения (MOS) В качестве объективного параметра качества переданного изображения по сравнению с эталонным изображением используют величину Peak Signal-to-Noise Ratio (PSNR) [5], которая может быть вычислена по формуле:
Значение PSNR вычисляется для каждого кадра. Если видео ролик содержит нескольких сотен или тысяч кадров, то вычисление PSNR представляет собой трудоёмкую задачу. Кроме этого очень интересной характеристикой является искажение изображения в процессе трансляции видео ролика по сети. Мы сравнивали полученный по сети искаженный образ видео ролика с его прообразом, т.е. вычисляли PSNR канала. Другим вариантом анализа является вычисление значения MOS. Существует общепринятая таблица соответствия между MOS и PSNR.
По умолчанию на маршрутизаторе максимальная длина очереди для потока default = 75 пакетов. Мы оставили значение по умолчанию, так как оборудование фирмы Cisco широко применяется практически всеми сервис-провайдерами. При кодировании исходного видео образа в формат MPEG-4 несколько ухудшается качество каждого видео кадра.  Рис. 3. Ухудшение качества исходного видео ролика при кодировании из формата YUV420 в формат MPEG-4 При передаче по сети каждый из 300 кадров разбивается на RTP пакеты. После разбиения получается 363 RTP пакета. В случае перегрузки часть RTP пакетов формирующих кадр может быть потеряна, и кадр не будет декодирован. Приведём зависимость процента потерянных за время эксперимента пакетов от коэффициента перегрузки, показанную на рис.4.  Рис. 4. Зависимость процента потерянных пакетов от коэффициента перегрузки Из рисунка 4 видно, что вероятность потери пакета монотонно возрастает с ростом перегрузки. Рис. 4 нам нужен, чтобы прокомментировать зависимость среднего (по 300 фреймам) значения PSNR от величины перегрузки l/m. Проверка качества производится попиксельно.  Рис. 5. Зависимость среднего (по 300 фреймам) значения PSNR от величины перегрузки l/m Зависимость PSNR (рис. 5) немонотонна. Это связанно с тем, что один фрейм не всегда кодируется одним пакетом RTP. Из рис. 5. видно, что иногда может возникнуть ситуация, при которой рост числа потерянных пакетов, не приводит к ухудшению качества. Дело в том, что передаваемые кадры неэквивалентны по влиянию на качество изображения. Потеря I-кадра (базового изображения) оказывает длительное и весьма существенное воздействие на качество картинки, потеря же других кадров (транспортирующих дифференциальные видеоданные) не столь существенна. Ссылки
|
||||||||||||||||||||||||||||||||
