CC BY
433
УДК 681.3.07
Оценка качества передачи потокового видео в телекоммуникационных сетях с помощью программно-аппаратных средств
О.И. Шелухин, д.т.н., профессор Российского государственного университета туризма и сервиса (РГУТиС), г. Москва, e-mail: sheluhin@mail.ru
Ю.А. Иванов, аспирант Чувашского государственного университета (ЧГУ), г. Чебоксары, e-mail: yurasic@mail.ru
Представлены принципы построения программно-аппаратного комплекса, предназначенного для оценки качества потокового видео, передаваемого по реальным или имитируемым сетям связи; приведены описания параметров и функциональных возможностей подобных комплексов.
Aufbau principle of hardware-software systems (HSS) of video streaming quality ratings over real or simulated networks is shown; functional capabilities and parameters of such HSS are described.
Ключевые слова: MPEG, потоковое видео, кодеры, декодеры, качество видео, видеотрассы, MSE, PSNR.
Key words: MPEG, video streaming, encoder, decoder, video streaming quality, trace file, MSE, PSNR.
Постановка задачи
Большинство современных телекоммуникационных систем предоставляет услуги передачи видео в реальном времени, при этом вопрос о качестве видео является очень важным. Известно множество публикаций [1, 2, 3], посвященных механизмам обеспечения требуемого качества обслуживания (QoS), однако лишь в некоторых из них удалось достичь удовлетворительных результатов, имеющих практическое значение [4, 5], поскольку влияние параметров QoS на качество передачи видео невозможно однозначно определить из-за большого многообразия схем кодирования, методов восстановления после ошибок или обработки.
В некоторых работах для оценки качества видео часто используют синхронизацию кадров на передающей и приемной стороне, что означает отсутствие возможности оценки качества в случае потери кадров или ошибок декодирования [6, 7]. Известны способы оценки качества видео, искаженного передачей, например [3, 5], однако их программное обеспечение недоступно массовому пользователю.
В данной статье рассматривается оценка качества видео, передаваемого по реальным или имитируемым сетям связи, с помощью набора инструментов, имеющего модульную структуру.
Наряду с оценкой таких параметров QoS сети, как коэффициент потерь, задержка и джиттер, предусмотрена также оценка качества полученного видео, основанная на вычислении показателей
PSNR (от англ. Power Signal-To-Noise Ratio) и MOS (от англ. Mean Opinion Score).
Структура комплекса для оценки качества потокового видео
На рис. 1 представлена структурная схема программно-аппаратного комплекса (ПАК) для оценки качества потокового видео при передаче в различных телекоммуникационных сетях. В этой схеме отражено взаимодействие между модулями при передаче цифрового видео от источника через сеть связи к зрителю.
Для проведения оценки качества необходимо иметь данные видеофайла до передачи по сети (на передающей стороне) и после приема из сети (на приемной стороне). На передающей стороне необходимыми данными являются: исходное некоди-рованное видео в формате YUV, закодированное видео в формате MPEG-4, а также время отправки и тип каждого отправленного в сеть пакета.
На приемной стороне необходимо получить следующие данные: время приема и тип каждого принятого из сети пакета, закодированное видео (возможно, искаженное) в формате MPEG-4 и декодированное видео в формате YUV для отображения.
Оценка данных производится при сравнении передаваемой информации с принятой. На практике несжатое видео может быть очень большого объема, например 680 Мб для 3-минутного видео, рассчитанного для просмотра на маленьком дисплее карманного компьютера. Поэтому целесообразно пе-
Источник
Сеть
о
О
4
5 со >
о
О
X
п
о
X
о
S
О
<D
Cf
Xj
cq
<D
О
XI
XI
сз
ffl
О
CL
X)
cf
О
J
г)г
Видео
трасса
от
Cl
| Потери / В з
задержка CL
Трасса
передачи
Искаженное
.видео
вв
Восстановленное YUV видео
Буфер
Зритель
Трасса
приема
Искаженное
видео
YUV видео
Результаты:
Потери кадра/джиттер кадра Полученное качество
Н PSNRI---и MOS
MOS^—
Рис. 1. Структура программно-аппаратного комплекса: ВП - видеопередатчик; ОТ - оценка трассы; ВВ - восстановление видео; PSNR - оценка качества
редавать только дополнительную информацию в виде файла с записью времени получения каждого пакета. Это удобней, чем передавать передатчику полный (искаженный и декодированный) видеофайл с приемной стороны.
Обработка данных осуществляется в три этапа.
На первом этапе анализируется время приема и отправки каждого пакета с обеих сторон и его тип. В результате появляется запись о типе кадра и времени между переданным и принятым пакетами. Кроме того, файл искаженного видео на приемной стороне восстанавливается путем использования оригинального закодированного видеофайла и информации о потерянных пакетах. После чего видео декодируется для отображения зрителю. На этом этапе возникает обычная проблема оценки качества видео. Показатели качества видео всегда требуют сравнения принятого (возможно, искаженного) и соответствующего исходного кадра. В случае полной потери кадра отсутствует необходимая синхронизация кадров до и после передачи по сети.
На втор о м э т а п е обработки эта проблема решается на основе анализа информации о потерях. Синхронизация кадров восстанавливается путем добавления последнего отображенного кадра вместо потерянных. Это позволяет провести дальнейшую покадровую оценку качества.
На третьем этапе для анализа качества декодированного видео используются восстановленный и исходный видеофайл.
Взаимодействие между модулями ПАК и сетью осуществляется с помощью трасс, содержащих все необходимые данные. Таким образом, для функционирования ПАК необходимы две трассы, исходный видеофайл и декодер. Сеть является просто «черным ящиком» и вводит задержку, потери и, возможно, переупорядочивает пакеты. Она может быть как реальной сетью (такой как Ethernet или WLAN), так и ее имитацией. В качестве имитатора сети может выступать программная среда NS-2 [8], поддерживающая большинство протоколов в проводных и беспроводных (наземных и спутниковых) сетях.
Функциональные модули ПАК
На рис.2 представлена функциональная схема ПАК. Рассмотрим назначение основных файлов и модулей, входящих в состав ПАК.
Представление исходных файлов и формат видео. Цифровое видео представляет собой некоторую последовательность изображений. Независимо от того, как эта последовательность закодирована - с использованием пространственной (как JPEG) или временной (как MPEG или H.263) избыточности, в конечном итоге каждый видеокодек производит последовательность из «сырых» изображений (пиксель за пикселем), которые можно затем отобразить. Обычно таким изображением является просто двухмерное множество пикселей. Каждый пиксель соответствует одному из трех
Исходное YUV видео
Видеокодек
mpeg4encoder.exe
Видео
передатчик
MP4.exe
Восстановленное YUV видео
Искаженное YUV видео
Восстановление
видео
myfixyuv.exe
f Имитация NS-2
Видео трасса
Трасса приема
Вычисление задерж
ки сети и поте
ри пакетов
Видеодекодер
mpeg4decoder.exe
Оценка трассы
et.exe
Рис. 2. Функциональная схема ПАК
цветов RGB - красному, синему или зеленому. Однако при кодировании видео пиксели представлены как комбинация яркости (Y) и значений хроматических данных: цвету (U) и насыщенности (V). Соответствие RGB и YUV представлено следующими уравнениями:
Y = 0,299R + 0,578G + 0,1145;
U = 0,565(5 - Y);
V=0,713(R - Y);
R = Y + 1,403 V;
G = Y- 0,344U-0,714V;
5 = Y+1,770U.
Известно, что визуальное восприятие человека наиболее чувствительно к яркостному компоненту, чем к компонентам хроматических данных. Именно поэтому при кодировании видео компонент яркости вычисляется для каждого пикселя, а два остальных компонента часто усредняются по более чем четырем пикселям.
В качестве исходного (незакодированного) видеоматериала обычно используется формат YUV QCIF (176x144) или YUV CIF (352x288). Такие файлы могут быть получены из различных источников [9, 10, 11].
Кодирование исходного видео производится программой mpeg4encoder.exe следующим образом:
mpeg4encoder.exe [example.par] где example.par - файл настроек кодека, в котором можно указать разрешение видео, тип кодирования, число кадров и др.
После кодирования исходного видео получают mpeg-4 файл.
Модуль видеопередатчика. Целью работы модуля ВП является генерация видеотрассы из закодированного видео (mpeg-4 файла). В файле видеотрассы (табл. 1) содержатся следующие данные: номер кадра, тип кадра, размер и число сегментов при разделении кадра на UDP- (от англ. User Data Protocol) пакеты. Последний столбец информирует только о передаче видео по UDP так, чтобы можно было видеть время передачи (отражает скорость кадров видео, например 40 мс при 25 кадр/с или 33 мс при 30 кадр/с).
Возможно, что все или некоторые кадры превышают максимальный размер пакета сети MTU (от англ. Maximum Transfer Unit), т.е максимально поддерживаемого размера пакета (например, Ethernet = = 552, Fast Ethernet = 1500 и WLAN = 2312 байтов). Эти кадры должны быть разбиты на меньшие пакеты, чтобы соответствовать MTU сети.
Таблица 1. Формат файла видеотрассы
Номер кадра Тип кадра Размер кадра Число UDP-пакетов Время передачи, мс
0 H 24 1 40
1 I 9379 10 80
2 P 2549 3 120
3 B 550 1 160
Каждый кадр в видеотрассе упаковывается в целое число пакетов. Размер каждого 552 байта (размер MTU сети Ethernet). Например, если кадр равен 1800 байтам (1800=552^3,26) или 2100 байтам (2100=552x3,80), создаются три и четыре пакета соответственно (рис.3). Хотя такое округление в большую сторону и усечение вызывают ненужное дополнение и удаление байтов, они не влияют отрицательно на результат моделирования.
После того как каждый кадр упакован, передача пакетов, принадлежащих одному кадру, равномерно распределена в первой половине длины кадра (каждая длина кадра - 40 мс, поскольку частота кадров 25 кадров в секунду). Распределение передачи пакетов помогает избежать внезапной перегрузки буфера из-за проблемы больших MPEG кадров.
В результате передачи видео по UDP получаются файлы трасс передачи (табл. 2) и приема (табл. 3), которые содержат в себе следующие данные пакетов: время передачи /приема, уникальный идентификатор id (от англ. identifiers) и размер. Эти две трассы используются для определения потерянных в сети пакетов. Если используется реальная сеть, трасса приема формируется с помощью анализатора трафика сети TCP-dump или Win-dump [12, 13]. Если происходит моделирование сети, то этот файл формируется объектом приемника моделирования [14].
Таблица 2. Формат файла трассы передачи
Время передачи, с id пакета Размер нагрузки
0,033333 id 0 udp 29
0,066666 id 1 udp 1000
0,066666 id 2 udp 1000
0,066666 id 3 udp 1000
0,066666 id 4 udp 36
0,099999 id 5 udp 659
Таблица З. Формат файла трассы приема
Время приема, с id пакета Размер нагрузки
0,047958 id 0 udp 29
0,126 id 1 udp 1000
0,171689 id 2 udp 1000
0,217377 id 3 udp 1000
0,219451 id 4 udp 36
0,250482 id 5 udp 659
Файлы трасс содержат полную информацию о передаче видео по сети, необходимую для дальнейших оценок ПАК. Модуль ВП позволяет сгенерировать такие трассы для различного видео и с разными размерами пакетов, которые могут далее передаваться в сеть (или его имитатор). Сеть вносит задержку и, возможно, потери и переупорядочение пакетов.
Необходимо отметить, что IP-уровень сегментирует UDP-пакеты, превышающие MTU, и повторно собирает их на приемной стороне. Если один сегмент (IP-фрагмент) отсутствует, целый пакет (UDP) считается потерянным. Так как желательно получить остальную часть сегментов из пакета, то рекомендуется по возможности использовать дополнительную функцию MTU сегментации в ВП.
Функция модуля ВП выполняется программой MP4.exe:
MP4.exe [команда] [тред4-файл] > [имя файла видеотрассы],
где команда —parse выводит информацию о видео файле; -trace генерирует трассу видео файла; -send [IP адрес] [порт UDP] [размер пакета] фрагментирует каждый кадр на пакеты определенного размера.
IP-адрес и порт - необязательны, поскольку достаточно получить информацию о кадрах (сохраняется в файле видеотрассы). Максимальный размер пакета может быть 1 028 байт, включая заголовки IP (20 байт) и UDP (8 байт).
Сеть. Закодированный поток, разбитый на пакеты, передается в сеть. В данном случае сеть имитируется программой NS-2, включающей в себя несколько объектов (агентов). Объект MyTraffic-Trace используется для вычисления типа и размера
Размер кадра, байт
Размер
пакета,
байт
Трасса MPEG до паке тирования
кадр 1 = 1800 байт = 3.26 пакетов =3 пакета
кадр 2 = 2100 байт = 3.80 пакетов =4 пакета
40
Время, мс
Трасса MPEG после пакетирования
все пакеты по 552 байта
пакеты из кадра 1 пакеты из кадра 2
20 20 20 Время, мс
Рис. З. Метод пакетирования MPEG кадров
кадра видеотрассы, генерируемого модулем ВП. Кроме того, этот объект разбивает видеокадры на пакеты и отправляет их на уровень ИБР в соответствующее время, согласно параметрам настройки пользователя, определенным при моделировании.
По существу, МуИБР является объектом ИБР. Этот объект записывает в файл отправляемой трассы время передачи каждого пакета, id пакета, и размер полезной нагрузки пакета (см. табл. 2). Работа объекта МуИБР аналогична работе программ ТСР-dump или ’^п-1итр, проводимой в реальных сетях.
Объект МуИБР8тк - объект приема пакетов фрагментированных кадров, отправленных МуИБР. Этот объект записывает время, id пакета и размер полезной нагрузки каждого полученного пакета в файл трассы приема (см. табл. 3).
Модуль оценки трассы. Это наиболее важный модуль ПАК, в котором происходит вычисление потерь пакета/кадра и задержки/джиттера. Для вычисления этих данных необходимо три трассы: видеотрасса, трасса приема и трасса передачи. Вычислить потери при рассмотрении доступности уникального id пакета весьма легко. С помощью видеотрассы каждому пакету назначается тип. Каждый пакет этого типа, не включенный в трассу приемника, считается потерянным. Потеря кадра вычисляется при рассмотрении любого кадра, если один из его пакетов был потерян. Если первый пакет кадра теряется, то кадр считается потерянным, поскольку видеодекодер не сможет декодировать кадр, у которого отсутствует первая часть.
Потеря пакета. Потери пакета обычно вычисляются на основе идентификаторов пакета (^). Следовательно, сеть, представленная в виде «черного ящика», должна обеспечить уникальный id пакета. В измерениях id пакета часто берется от заголовка 1Р, что обеспечивает его уникальность. Уникальный id пакета используется также для избежание переупорядочения. При передаче видео интересен не только потерянный пакет, но и тип данных в нем. Например, кодек MPEG-4 определяет четыре различных типа кадров (I, Р, В, S) [15]. Так как часто важно знать, какой вид данных потерян (или сохранен), то необходимо различать различные виды пакетов. Оценка потерь должна зависеть от типа кадра, а также его заголовка. Потеря пакета, выраженная в процентах, определяется как
РЬТ = 100
Тотпр
Тпрн
(1)
пТо-шр - число отправленных пакетов типа Т; пТпрн - число принятых пакетов типа Т.
Потеря к а д р а . Видеокадр, являющийся фактически одним закодированным изображением, может быть относительно большим. Причем не только в случае переменной, но и в случае постоянной скорости передачи. 1-кадр обычно значительно больше всех остальных кадров (рис. 4).
1
ы АД .Лу'-' лл ДА ЛА ЧЛ м Чл1 у М1
0 10 20 30 40 50 60 70 80 90 100
Номер кадра
Рис. 4. Размер кадров видеопоследовательности 1ВВРВВРВВ
Однако разбиение кадров на пакеты затрудняет вычисление потерь. В принципе число потерянных кадров может быть получено из числа потерянных пакетов. Но этот процесс зависит от используемого декодера, поскольку некоторые декодеры могут обработать кадр, даже если некоторые части отсутствуют, а некоторые не могут. Если первый пакет отсутствует, то кадр невозможно будет декодировать. Таким образом, при вычислении числа потерянных кадров ЕЬт необходимо учитывать способности определенных декодеров. Потеря кадра определяется как
(2)
ЕЬТ = 100
Тотпр
Тпрн
где Т- тип данных в пакете (заголовок, I, Р, В, 8);
Задержка и джиттер. При передаче видео важна не только фактическая потеря кадров, но и время задержки, а также вариация задержки, обычно называемая «джиттер кадра». Цифровое видео состоит из кадров, которые отображаются последовательно при постоянной скорости. Отображение кадра до или после определенного времени приводит к «скачкам» видео [5]. Эту проблему решает буфер, который поглощает джиттер. Очевидно, что достаточно большой буфер может компенсировать любой джиттер. Вместе с тем, можно выделит два крайних случая.
В первом случае, если размер буфера будет равен объему всего видео, а отображение начнется только после получения последнего кадра, возможно устранить любой джиттер, однако при этом увеличится задержка времени передачи.
0
Во втором крайнем случае, когда объем буфера равен длительности одного кадра, дополнительная задержка не вводится, но джиттер устранить будет невозможно.
Джиттер можно оценить следующими соотношениями.
Время между пакетами ИР0 = 0,
^Рп tPn-\, (3)
где tPn - время п-го пакета.
Время между кадрами itF0 = 0,
^Ет tFm tFm-\,
где tFm - время последнего сегмента т-го кадра. Джиттер пакета
\ Ы -]р = N £(^ - **)2, (4)
™ i=\
где N - число пакетов; - среднее время между
пакетами.
Джиттер кадра \ м
^ £ (Пг - ^м )2, (5)
М1=(
где М- число кадров; йм - среднее время между кадрами.
«Время кадра» определяется как время получения последней части сегментированного кадра. Вычисление времени между пакетами производится согласно уравнениям (3) и (4). Уравнения (4) и (5) показывают вариацию времени задержки кадров и пакетов. Все же в случае потери пакета эти формулы не могут использоваться однозначно, поскольку время для потерянного пакета в трассе приемника не известно. Возникает вопрос, как вычисляется время между пакетами, если один из двух последующих пакетов теряется? Одним из возможных решений является установка «ошибочного» значения времени между пакетами в случае потери, например, 0. Если затем пакет фактически получен, ищется действительное значение. Время между пакетами в этом случае было бы
Пакета - ^осл. получ. пакет. Это неудобно при получении
значения каждый раз, и время между пакетами может стать очень большим. Именно поэтому ОТ использует другой подход. Если по меньшей мере один из пакетов отсутствует (из двух, используемых в вычислении), то значение будет «предположительным», т.е. вычисляется предположительное время прибытия потерянного пакета. Это фактически означает, что для потерянных пакетов используется ожидаемое значение времени отправки между пакетами. При относительно небольшой потере пакетов этот метод незначительно влияет
на статистику джиттера. В другом случае, если коэффициент потерь велик, необходимо вычислять только пары полученных пакетов и отдельно потерянные пакеты.
Время прибытия потерянных пакетов вычисляется по формуле
t О t п ^ (t о t о ) ,
кп Оп-1 х еп еп-1 '
где : t е - вр е мя отправки п-го пакета; tR - время
получения (неполучения) п-го пакета.
Теперь, имея значение времени для каждого пакета, может быть вычислена задержка между пакетами (и между кадрами), согласно (3).
Другой задачей ОТ является генерация искаженного (из-за потерь) видеофайла. Этот искаженный файл необходим для выполнения непрерывной оценки качества видео, т.е. для ОТ нужен исходный закодированный видеофайл. В принципе генерация искаженного видео производится путем копирования пакетов исходного видео, при котором потерянные пакеты упускаются. Нужно обратить внимание на фактическую способность обработки ошибок в используемом декодере. Возможно, что декодер вставляет специальные метки в случае недостатка данных, например, специальные кодовые слова, или просто опустошает (заполняет нулями) буфер вместо недостающего пакета.
Функцию модуля ОТ выполняет программа et.exe. Фактически она изменяет исходный mpeg4-файл, основываясь на трассах передачи и приема следующим образом:
et.exe [трасса передачи] [трасса приема] [видео трасса] [mpeg4-файл] [имя mpeg4-файла искаженного видео] [имя файла потерь] [размер буфера]
После выполнения программы выводится отчет о потерях кадров и пакетов в следующем виде:
р->пД:1022, р->п1:350, р->пР:222, р->пВ:449 р->1А:161, р->11:109, р->1Р:22, р->1В:30 Г->пД:301, Г->п!:34, Г->пР:67, Г->пВ:199 Г->!А:54, Г->!!:20, Г->!Р:13,1->!В:21 Первая строка отчета показывает общее число отправленных пакетов (р->пА), равное 1022, которое включает в себя 350 пакетов I-кадров (р->п1), 222 пакета Р-кадров (р->пР) и 449 пакетов В- кадров (р->пВ).
Вторая строка отчета показывает общее число потерянных пакетов (р->1А), равное 161, которое включает в себя 109 пакетов 1-кадров (р->11), 22 пакета Р-кадров (р->1Р) и 30 пакетов В- кадров (р->1В).
Третья и четвертая строки показывают аналогичную информацию для кадров.
Если в программе указать размера буфера (в секундах), данный отчет выводится с учетом до и после обработки данных буфером.
Декодирование и отображение. Стандарт MPEG использует три типа кадров, а именно, I, Р и В. 1-кадр содержит полное изображение, которое может быть декодировано независимо, при использовании только пространственной избыточности. Р-кадры являются предсказывающими кадрами, они содержат закодированные векторы движения (перемещения), которые вычисляются в зависимости от предыдущих I- или Р-кадров. Р-кадры используют и пространственную и временную избыточность. Эти кадры могут быть полностью декодированы, только если доступны предыдущие I- или Р-кадры. В-кадры кодируются исключительно в зависимости от предыдущего и последующего кадра (I или Р). В-кадры используют только временную избыточность. Они могут быть декодированы полностью, только если доступны предыдущие и последующие I- или Р-кадры. Порядок реорганизации кадров MPEG перед передачей, позволяющей непосредственно декодировать любой полученный кадр, представлен в табл. 4. Таблица 4. Порядок декодирования и отображения МРЕО-
кадров
Порядок отображения Тип кадра Порядок декодирования
1 I 2
2 B З
З B 1
4 P 5
5 B 6
6 B 4
Из-за проблемы переупорядочения закодированные кадры не соответствуют декодированным (УЦУ) кадрам. Модуль ВВ решает эту проблему при согласовании отображаемых (УЦУ) и передаваемых (закодированных) кадров, согласно табл. 4. При других схемах кодирования принцип переупоря-дочивания остается таким же.
Декодирование полученного видео в УИУ производит следующая программа:
mpeg4decoder.exe [тред4-файл искаженного видео] [имя файла искаженного УиУ видео] [разрешение видео] [имя файла статуса декодирования]
После декодирования искаженного mpeg-4 файла формируется искаженное видео УИУ-формата.
Модуль восстановления видео. Оценка качества цифрового видео выполняется кадр за кадром.
Возникает вопрос, как нужно рассматривать потерянные кадры, если декодер не производит «пустые» кадры вместо потерянных. Модуль ВВ необходим, только если используемый кодек не может восстановить потерянные кадры. Другой проблемой является возможное неравенство числа декодированных и исходных кадров, вызванное потерями, вследствие чего невозможно провести оценку качества. Хороший декодер может декодировать каждый кадр, даже если была получена только его часть. Но некоторые декодеры не могут декодировать часть кадра или B-кадр, если отсутствует «родительский» I- или Р-кадр, т.е тот, от которого он был получен. При потере кадра есть два возможных решения. Первый заключается в том что, можно вставить «пустой» кадр вместо неде-кодированного кадра (пустой кадр - кадр, не содержащий в себе никакой информации). Определенные декодеры отображают пустой кадр как черное (или белое) изображение. Это не совсем правильное решение, поскольку между двумя последовательными видеокадрами мало различия. Таким образом, ВВ использует вторую возможность, в которой вместо пустого кадра в случае потери вставляется последний успешно декодированный кадр.
Функцию модуля ВВ выполняет программа myfixyuv.exe следующим образом:
myfixyuv.exe [файл статуса декодирования] [разрешение видео] [число кадров] [файл искаженного YUV видео] [имя файла восстановленного YUV видео]
Результатом работы программы будет восстановленное видео YUV-формата.
Оценка качества видео
Существуют два типа методов оценки качества цифрового видео, а именно субъективные и объективные. Объективные методы описаны в ITU [16, 17], ANSI [18, 19] и MPEG [20]. Субъективная оценка качества всегда опирается на впечатление зрителя, но является чрезвычайно дорогостоящей, очень трудоемкой и требует специального оборудования. Традиционно субъективное качество видео определяется путем экспертной оценки и подсчетом среднего балла MOS, имеющего значения от 1 до 5 (шкала ITU), где 1 - наихудшее, а 5 -наилучшее полученное качество видео (табл. 5).
Традиционные показатели искажения сигнала для определения качества системы используют абсолютную разность между оригинальным и обработанным сигналом.
Таблица 5. Таблица оценки качества видеоизображения ITU-R
Значение MOS Качество Ухудшение изображения
5 Прекрасное Незаметно
4 Хорошее Заметно, но не раздражает
3 Удовлетв. Слегка раздражает
2 Плохо Раздражает
1 Очень плохое Сильно раздражает
Объективное качество видео обычно измеряется среднеквадратической ошибкой MSE (от англ. Mean Square Error) и пиковым отношением сигнала к шуму PSNR, который вычисляется из RMSE и является логарифмическим показателем инверсии этой меры. MSE и его производный показатель PSNR являются традиционными метриками, позволяющими сравнить любые два изображения. Можно именовать RMSE как «искажение» и PSNR как «качество». По сравнению с другими объективными показателями PSNR легко вычисляется и наиболее понятен большинству пользователей. Однако оба показателя не соотносятся с субъективным качеством восстановленного изображения и должным образом не отражают малые ухудшения интенсивности [21]. Уравнение (6) является определением PSNR между компонентами яркости Y исходного (S) и полученного (D) изображения:
PSNR„ = 20logu
255
1
N N
і j)-YD(n,i::j)]2
столбца ряда i=0 j=0
(6)
PSNR, дБ MOS, % Качество по шкале ITU
Более 37 31 -37 25 -31 20 - 25 Менее 20 81 -100 61 - 80 41 -60 21 - 40 0 -20 5 Прекрасное 4 Хорошее 3 Удовлетворительное 2 Плохое 1 Очень плохое
Оценки PSNR. Р8КЯ - основной показатель качества, который не может быть вычислен, если два изображения эквивалентны, т.е. среднеквадратическая ошибка равна нулю. Это решается путем вычисления PSNR между исходным и принятым видеофайлом. Это гарантирует, что различие между изображениями будут всегда, так как все современные видеокодеки добавляют потери. Возможно использование других пока-
зателей и другого программного обеспечения вместо модуля PSNR/MOS, например [5, 22, 23].
Оценка объективного качества полученного видеопотока в ПАК вычисляется модулем Р8КЯ с помощью программы psnr.exe:
psnr.exe [разрешение кадра] [формат УиУ] [файл исходного УиУ видео] [файл восстановленного УиУ видео] > [имя файла с результатами РБЫР]
Результатом будут значения Р8КЯ, вычисленные формулой (6) между исходными и искаженными кадрами (рис. 5).
Номер кадра
На основе оценки Р8КЯ можно вычислить оценки MOS, а также процент кадров, у которых MOS хуже, чем у исходного видео. В табл. 6 представлено соответствие PSNR со шкалой MOS.
Таблица 6. Соответсвие РБЖ и МОБ
Рис. 5. Пример покадрового значения РБЫЪ видеопоследовательности
Дополнительно программой avgpsnr.exe может быть вычислено среднее значение Р8МЯ.
Вычисление MOS. Субъективные оценки качества видео (М08) могут быть оценены по показателю Р8КЯ. Как показано на рис. 6, градации оценки качества видео могут быть легко получены. Правый столбец иллюстрирует качество видео при отсутствии потерь, средний - коэффициент потерь пакетов (5 %). Крайний левый столбец показывает качество видео передачи с коэффициентом потерь 25%. Качество восприятия пользователей («удовлетворение пользователей») вычисляется на основании результатов MOS, полученных в ПАК. Для оценки качества видео при различных способах моделирования используются наборы инструментов, описанные в [1, 24], и измерения из [4].
Рис. б. Пример оценки видео на основании результатов MOS
N
Предложено использовать ПАК для оценки качества потокового видео передаваемого по сетям произвольной структуры, путем вычисления показателей качества PSNR, MSE, MOS и др. Разработанный комплекс может использоваться с различными видео- и аудиокодеками.
ЛИТЕРАТУРА
1. Aguiar A. C., Hoene C., Klaue J., Karl H., Wolisz A., and Miesmer H. Channel-aware schedulers for voip and MPEG-4 based on channel prediction. to be published at MoMuC, 2003.
2. Sanneck H., Mohr W., Le L., Hoene C., and Wolisz A. Quality of service support for voice over ip over wireless. Wireless IP and Building the Mobile Internet, December 2002.
3. Wu D., Hou Y. T., Zhu W., Lee H.-J., Chiang T., Zhang Y.-Q., and Chao H. J. On end-to- end architecture for transporting mpeg-4 video over the internet. IEEE Transactions on Circuits and Systems for Video Technology, 10(6) pp. 923-941, September 2000.
4. Hertrich D. MPEG4 video transmission in wireless LANs - basic QoS support on the data link layer of 802.11b. Minor Thesis, 2002.
5. WolfS. and Pinson M. Video quality measurement techniques. Technical Report 02 392, U.S. Department of Commerce, NTIA, June 2002.
6. Sarnoff Corporation. Jndmetrix-iq software and jnd: A human vision system model for objective picture quality measurements, 2002.
7. Project P905-PF EURESCOM. Aquavit - assessment of quality for audio-visual signals over Internet and UMTS, 2000.
8. http://www.isi.edu/nsnam/ns/ns-documentation.html
9. MPEG-4 Industry Forum (http://www.m4if.org/ resources.php)
10. MPEG (http://mpeg.nist.gov/)
11. http://trace.eas.asu.edu/index.html
12. http://www.tcpdump.org
13. http://windump.polito.it
14. http://www.tkn.tu-berlin.de/research/evalvid/fw.html
15. ISO-IEC/JTC1/SC29/WG11. ISO/IEC 14496: Information technology - Coding of audiovisual objects, 2001.
16. ITU-R Recommendation BT.500-10. Methodology for the subjective assessment of the quality of television pictures, March 2000.
17. ITU-T Recommendations P.910 P.920 P.930. Subjective video quality assessment methods for multimedia applications, interactive test methods for audiovisual communications, principles of a reference impairment system for video, 1996.
18. ANSI T1.801.01/02-1996. Digital transport of video teleconferencing / video telephony signals. ANSI, 1996.
19 ANSI T1.801.03-1996. Digital transport of one-way video signals - parameters for objective performance assessment. ANSI, 1996.
20. ISO-IEC/JTC1/SC29/WG11. Evaluation methods and procedures for july mpeg-4 tests, 1996.
21. Hanzo L., Cherriman P. J. and Streit J. Wireless Video Communications. Digital & Mobile Communications. IEEE Press, 445 Hoes Lane, Piscataway, 2001.
22. Berts J. and Persson A. Objective and subjective quality assessment of compressed digital video sequences. Master’s thesis, Chalmers University of Technology, 1998.
23. Sarnoff Corporation. Jndmetrix-iq software and jnd: A human vision system model for objective picture quality measurements, 2002.
24. Klaue J., Gross J., Karl H., and Wolisz A. Semantic-aware link layer scheduling of mpeg- 4 video streams in wireless systems. In Proc. of Applications and Services in Wireless Networks (AWSN), Bern, Switzerland, July 2003.
Поступила 12.02.2009 г.
