Размещено на http://www.allbest.ru/

5

Содержание

• Введение
• 1. Обзор существующих решений
• 2. Организация видеоданных
• 2.1 Стандарт H.264. Общие сведения
• 2.2 Группа кадров
• 2.3 Методы восстановления видеоряда при потерях в канале передачи данных
• 2.4 Битовая скорость данных
• 3. Алгоритм адаптации потока видеоданных
• 3.1 Клиент-серверная архитектура
• 3.2 Задачи и ограничения алгоритма
• 3.3 Протокол взаимодействия
• 3.4 Общий вид алгоритма
• 3.5 Уровни скорости передачи данных источника
• 3.6 Робастная оценка потерь. Допустимые потери
• 4. Помехоустойчивое кодирование
• 4.1 Существующие решения
• 4.2 Метод наложения избыточности
• 4.3 Внедрение помехоустойчивого кодирования в алгоритм адаптации видеопотока
• Заключение
• Список литературы
• Введение
• Видеоконференция - информационная технология, обеспечивающая двустороннюю передачу видео- и аудиоданных по сети в реальном времени с учетом передачи управляющих сигналов. При этом качество видеоконференции зависит в целом от качества связи между всеми участниками конференции, которое определяется наличием шума в канале передачи данных, пропускной способностью канала передачи данных, используемыми алгоритмами, стандартами сжатия видеоданных, мощностями кодирующего и декодирующего устройств, типа и класса устройств, обеспечивающих захват изображения. Единственное, на что мы с трудом можем повлиять - это динамические (т.е. изменяющиеся во времени) параметры сети, которые непосредственно влияют на процесс передачи данных. К таким параметрам относятся: пропускная способность сетевого канала, степень шума в сетевом канале (термин «шум» необходимо интерпретировать в данных условиях как наличие потерянных пакетов), от чего не спасает выбор самого надежного интернет оператора.
• С ростом вычислительных мощностей и совершенствования интернет технологий, задача обеспечения корректной передачи данных в канале с шумом, и задача минимизации эффекта потерь информации становится более актуальной для данной технологии (далее по тексту сокр. «задача видеоконференции»). С появлением так называемых «облачных» технологий [1], «задача видеоконференции» приобретает качественно другой вид. Так, мы не можем позволить видимые, ощутимые для пользователя задержки, прерывания видеоряда, так как это в конечном итоге замедляет работу пользователя, и несет ущерб коммерческой безопасности сервиса.
• К чему же с практической точки зрения сводится разработка алгоритма адаптации видеопотока в канале передачи данных, позволяющая частично или полностью решить данную проблему? Видеоданные перед отправкой в сеть разбиваются на пакеты и от источника отправляются к приемнику. Даже из-за одного потерянного пакета качество видеоряда ухудшается настолько, что пользователь не может воспринимать информацию, при условии, что отключены стандартные методы восстановления видеоряда при потерях в канале передачи данных. Современные технологии могут позволить до 0,5 - 1 % потерь. Одним из следствий из теоремы Шеннона [2] является тот факт, что при бесконечно большом запасе времени для передачи данных (пакета), мы можем гарантировать передачу данных с вероятностью близкой к единице, при условии, что вероятность потерь так же близка к единице. Но одной из особенностей «задачи видеоконференции» является ограничение по времени кодирующего устройства до 40 - 60 мс, а в облачных сервисах - до 15 мс, а так же отсутствие буферизации данных. Это означает, что каждые T мс кодирующее устройство генерирует группу пакетов видеоданных, которые незамедлительно должны отправиться к приемнику. Но если мы имеем такие жесткие ограничения, то какой допустимый максимальный процент потерь пакетов мы можем позволить при передаче видеоданных в сетевом канале?
• Таким образом, главная цель данной дипломной работы - разработка алгоритма адаптации видеопотока при передаче данных в сетевом канале с шумом, который позволяет увеличить максимально допустимый процент потерь пакетов в сети и адаптирует параметры потока видеоданных в соответствии с изменяющимися параметрами канала передачи данных в условиях ограниченного времени. В ходе достижения поставленной цели необходимо решить ряд задач: разработать механизм адаптации видеопотока, механизм борьбы с искажениями видеоряда по причине шума в канале передачи данных, механизм внедрения избыточности и объединить полученные механизмы общей логикой взаимодействия. Итоговое решение и будет являться алгоритмом адаптации видеопотока. Результаты данной дипломной работы применимы в «облачных» технологиях связанных с передачей потока видеоданных - класса «облачных сервисов», которые предоставляют доступ к удаленно запущенному приложению (в том числе и компьютерным играм - игровые «облачные» сервисы), а так же для решения «задачи видеоконференции».

1. Обзор существующих решений

«Облачные» технологии - относительно новый вид технологий, который построен на объединении уже имеющихся. Как показал первичный анализ, существующих решений готового алгоритма адаптации потока видеоданных нет, но есть ряд работ, патентов в сфере близкой к «облачным» технологиям

Так анализ методом черного ящика [3] известного западного «облачного» игрового сервиса показал, что в используемом решении нет адаптации под изменяющуюся пропускную способность канала, о чем свидетельствовали искажения видеоряда, связанные с потерями пакетов данных.

Анализ патентов, готовых решений в этой области проводился в несколько этапов:

1. ручной поиск патентов с использованием инструмента Google Search Patent;

2. запрос в международное патентное бюро с целью найти аналог алгоритма адаптации потока видеоданных;

3. запрос в международное патентное бюро с целью найти способы применения избыточности данных в рамках поставленной задачи (подробнее см. гл. 5);

4. анализ научных статей с целью найти способы применения избыточности в рамках поставленной задачи (подробнее см. гл. 5).

Результаты 1-го и 2-го этапов сводились к патентам в области «облачных» технологий, которые носят более общий характер, например работа «Quality of service management system and method of forward error correction» Atul Apte [4].

Результаты 3-го и 4-го этапов оказались малоприменимы из-за ряда вводимых ограничений на алгоритм адаптации потока видеоданных (подробнее см. гл. 4.2). Так, например, в ходе работы К.В. Шинкаренко, А.М. Корикова, «Помехоустойчивое кодирование данных мультимедиа данных в компьютерных сетях» [5] удалось уменьшить буферизацию данных до параметра k = 100 - 1000 пакетов (для сравнения в кодах Лаби и их модификациях значение k достигает 10000), что составляет буферизацию от 1,5 - 2 с и является неприемлемым для «облачных» сервисов.

2. Организация видеоданных

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

Первый параметр - формат пикселя. Пиксель - наименьший логический элемент двумерного цифрового изображения. Если мы говорим о единице видеоряда - кадре, то он состоит из пикселей, которые могут быть представлены некоторым количеством бит информации. Способ представления, глубина цвета (возможность представления большего количества оттенков) полностью зависят от формата пикселя. Формат пикселя - это структура данных о цвете, и способ их интерпретации. Для несжатого (исходного или восстановленного кадра) наиболее распространенный формат - RGB (от англ. Red Green Blue). В данной цветовой модели один пиксель состоит из трех каналов. При смешении основных цветов получаются новые цвета, так, например, при смешении синего и красного мы получаем пурпурный цвет. Широкое распространение в вычислительной технике и способах представления данных получили форматы семейства RGB - ARGB (от англ. Alpha, составляющая, характеризующая степень прозрачности пикселя), RGB32 (в данном случае цифра 32 указывает на количество отведенных бит для интерпретации одного пикселя) и другие. Количество бит, отведенное под представление одного пикселя, характеризует такую величину, как глубина цвета. Чем эта величина больше, тем изображение лучше воспринимается человеческим глазом. Существуют и качественно другие форматы, например, формат YUV, в котором цвет представляется как 3 компоненты - яркость (Y) и две цветоразностных (U, V).

Говоря о передачи видеоданных или изображений, следует упомянуть формат YCbCr семейства форматов YUV. Известно, что органы зрения человека менее чувствительны к цвету предметов, чем к их яркости (светимости). В цветовом пространстве RGB все три цвета считаются одинакового важными и обычно сохраняются с одинаковой глубиной цвета (количеством отводимых бит на канал). Формат YCbCr позволяет интерпретировать точно такие же данные более эффективно (т.е. меньшим количеством бит), отделив яркость от цветовой информации и представив ее с большим разрешением, нежели цветовую составляющую. Это позволяет сократить объем информации для представления хроматических компонент без заметного ухудшения качества передачи цветовых оттенков изображения. Использование большего разрешения для компоненты яркости по сравнению с хроматическим и компонентами является простым, но весьма эффективным приемом при сжатии изображений.

Второй параметр - размер кадра, или разрешение. Разрешение характеризуется количеством пикселей, отводимых под ширину и высоту изображения. Соответственно, чем больше величина произведения ширины, высоты и глубины цвета, тем больше данных необходимо сжать. Величины разрешений для различных стандартов телевещания следующие: 640х480, 720х480, 720х576, 1280х720, 1920х1080.

Третий параметр - частота кадров. Под частотой кадров понимают количество кадров, сгенерированных устройством или программой в единицу времени. С точки зрения игровых «облачных» технологий этот параметр, наряду с разрешением кадра, является ключевым. С точки зрения сжатия потока видеоданных, видеоряд с большей частотой кадра занимает большее количество бит, нежели видеоряд с меньшей частотой кадров.

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

Основная проблема, с которой сталкиваются сервисы, транслирующие видеоданные в интернете - большой размер передаваемой информации. Так, например 30 с видео в разрешении 720p (1280х720, прогрессивная развертка) в несжатом формате занимало бы место на диске равное примерно 30 Гб информации. Очевидно, что столь огромный объем данных передать в любом телекоммуникационном канале в условиях современного состояния технологий связи невозможно. С целью сокращения объема данных, передаваемых в сети, записываемых на носители, были изобретены стандарты сжатия видеоданных и изображений.

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

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

Несжатый поток данных поступает на вход кодирующего устройства, который работает по принципу черного ящика [3] и имеет ряд управляющих команд для контроля параметров [7] сжатого потока на выходе.

Сжатый поток далее поступает к сетевому источнику. Его цель - привести данные, которые структурированы согласно стандарту видеосжатия, к формату используемого сетевого протокола.

Видеоданные от источника по сетевому каналу идут к приемнику. При этом возможны перестановки, потеря, дублирование пакетов данных.

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

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

На сегодняшний день самым распространенным стандартом видеосжатия является стандарт AVC/H.264 [6]. В рамках данной дипломной работы использовались потоки видеоданных, сжатых по стандарту H264. В данной главе будут рассмотрены составляющие стандарта, которые влияют на разработанный алгоритм адаптации потока видеоданных. Так же, поскольку представленный в данной дипломной работе алгоритм адаптации потока видеоданных изменяет входные параметры кодирующего устройства (см. гл. 4), в рамках главы 3 рассмотрено только описание кодирующего устройства, а так же структуры данных и механизмов борьбы с потерями данных. Ответная реакция декодирующего устройства заключается в изменении параметров инициализации и не рассматривается в данной дипломной работе.

2.1 Стандарт H.264. Общие сведения

В 2003 году группой экспертов по видеокодированию (Video Coding Experts Group, VCEG) - рабочей группой международного союза по телекоммуникациям (International Telecommunication Union, ITU-T) была инициирована разработка стандарта H264, который был нацелен на эффективное и надежное сжатие видеоданных. Ключевыми признаками стандарта являются следующие элементы: эффективность сжатия (обеспечивающая значительное улучшение показателя сжатия данных по сравнению с другими стандартами), эффективность передачи данных (с множеством встроенных деталей, поддерживающих надежную и устойчивую передачу по различным каналам и сетям) и ориентированность на популярных приложениях видеосжатия.

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

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

Видеокодек - программа, алгоритм, реализующий процесс сжатия (кодирования), и восстановления (декодирования) данных в рамках одного или нескольких стандартов видеосжатия. Иначе: видеокодек - это объединение кодирующего алгоритма и декодирующего в одно программное решение. Если рассматривать копии видео данных на входе (кодирующее устройство) и выходе (декодирующее устройство) кодека для одного кадра, то процесс сжатия данных является процессом сжатия данных без потерь тогда, когда эти копии полностью совпадают, иначе - процессом сжатия данных с потерями. Качество переданной информации в последнем случае определяется битовой разностью двух видеокопий так, что чем больше разность копий, тем больше отличие исходного кадра от восстановленного. Важно отметить, что качество переданной информации обратно пропорционально зависит от степени сжатия, а значит, при большем коэффициенте сжатия генерируется менее качественный видеоряд. В рамках данной главы говоря о видеокодеке, будем говорить о видеокодеке стандарта H.264.

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

Кодирующее устройство состоит из трех основных функциональных единиц:

- временная модель;

- пространственная модель;

- энтропийный кодер.

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

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

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

Рис. 1. Последовательность единиц данных NAL

Стандарт H.264 делает различие между модулем кодирования видео VLC (англ. Video Layer Coding) и абстрактным сетевым модулем NAL (англ. Network Abstract Layer). Выходом процесса кодирования и служат данные типа VLC - последовательность битов, представляющая закодированные видеоданные, которые преобразуются в единицы NAL перед передачей или хранением. Каждая единица NAL состоит из байтовой последовательность данных RBSP (англ. Raw Bytes Sequence Payload), т.е. из цифровой информации, соответствующей закодированной информации, а так же из заголовка, содержащего сведения об этой последовательности данных. Закодированная видеопоследовательность представлена в виде ряда единиц NAL (рис. 1), который можно переслать по сети пакетной передачи данных или по каналу связи битовых потоков, а также сохранить в файле. Целью раздельной спецификации модулей VCL и NAL является разграничение процесса видеокодирования (VCL) и подготовки данных к их транспортировки или хранению (NAL).

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

В стандарте H.264 определены три профиля, каждый из которых поддерживает определенный набор функций кодирования, например, таких, как методы кодирования на основе P-слоев и I-слоев (это будет рассмотрено ниже), контекстное арифметической энтропийное кодирование CABAC (англ. Context-Based Adaptive Arithmetic Coding), избыточные слои, группы слоев, взвешенный прогноз и другие [6]. Эти наборы функций обозначают, что требуется от кодера и декодера, от видеокодека в целом, для его подчинения выбранному профилю - базовому, расширенному, или основному. При этом пределы производительности кодеков конкретного профиля определяются множеством факторов, которые накладывают ограничения на такие параметры кодирования, как скорость отбора и обработки частей кадра, размер кадра, битовая скорость кодирования и объем требуемой памяти. Потенциальными сферами применения базового профиля являются видеотелефония, организация видеоконференций и беспроводных коммуникаций, а так же решение любой задачи близкой к задаче транспортировки потока видеоданных с минимальными задержками на кодирование-декодирование и транспортировку в сети (англ. Low-latency streaming). Основной профиль применим для телевизионного вещания (разрешены задержки порядка 2 - 5 минут, означающие допустимую буферизацию данных) и хранения видеоданных, а расширенный - в потоковом вещании видеоданных. Хотя эти профили и являются определенными в стандартах, производители видеокодеков в своих продуктах реализуют значительно большее количество доступных профилей, включающих в себя различные наборы методов и инструментов кодирования в рамках стандарта H.264. Количество профилей для видеокодека стандарта H.264 на сегодняшний день доходит до 12 - 16 профилей (например открытая библиотека x264 для языка С++).

В данной дипломной работе использовался базовый профиль стандарта H.264, так как с точки спецификации стандарта данный профиль является наиболее подходящим для решения поставленной задачи.

2.2 Группа кадров

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

При попадании на вход кодирующего устройства исходный (т.е. несжатый) кадр в первую очередь проходит конвертацию цветового пространства в YCbCr. Далее кадр разбивается на некоторое количество прямоугольных блоков, или далее по тексту макроблоков, размером I_a на I_b, где I_а и I_b - соответственно ширина и высота макроблока, а I_x (x = a,b) может принимать значения 2, 4, 8, 16, определяемые реализацией кодирующего устройства. До сжатия энтропийным кодером (не путать с кодером, который является часть видеокодека, энтропийный кодер - часть кодирующего устройства стандарта H.264), битовая последовательность данных формата H.264 так же остается сегментированной по макроблокам. Макроблок - минимальная единица, которой оперирует кодирующее устройство, при этом на выходе кодирующего устройства кадр качественнее и большего размера тогда, когда I_x меньшее из возможных значений.

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

Слой (англ. Slice) - это некоторая область на кодируемом снимке, в рамках которой макроблоки могут иметь ссылки друг на друга, либо на макроблоки из других кадров. Алгоритм кодирования минимизирует возможность распространения ссылок между макроблоками, принадлежащим разным слоям одного кадра. Наиболее часто используемые кодирующими устройствами способы разделения кадра на слои: перемешивание (рис. 2), рассеивание (рис. 3), передний план и задний план (рис. 4).

Рис. 2. Способ разделения кадра на слои - перемешивание. Цифрами обозначены различные слои.

Рис. 3. Способ разделения кадра на слои - рассеивание. Цифрами обозначены различные слои.

Рис. 4. Способ разделения кадра на слои - передний план и задний план. Цифрами обозначены различные слои.

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

Кодирующее устройство H.264 может использовать один или два списка снимков в качестве ссылок для формирования прогноза компенсации движения при кодировании макроблоков или их частей. Порядок и способы формирования этих списков в данной дипломной работе не будут рассмотрены [7]. Это позволяет кодирующему устройству искать лучшую «схожесть» частей текущего макроблока в более широком множестве снимков по сравнению с использованием, например, только одного предыдущего снимка. Таким образом, и кодирующее и декодирующее устройство строят по несколько одинаковых списков ссылочных кадров, которые используются при кодировании или декодировании нового.

Тип кадра (см. далее) определяет типы используемых слоев, а тип используемого слоя, определяет типы макроблоков и способы нахождения ссылок для них. В стандарте H.264 определены несколько типов слоев.

I - слой (от англ. слова intra). Содержит только макроблоки I типа, которые прогнозируются по ранее закодированным данным того же слоя. Область применения - все профили.

P - слой (от англ. cлова predicted). Может содержать макроблоки I типа, а так же макроблоки P типа. Макроблоки P типа полностью или частично ссылаются на ранее закодированные кадры. Область применения - все профили.

B - слой (от англ. сочетания bi - predictive). Может содержать макроблоки I типа, а так же макроблоки B типа. Макроблоки B типа являются полной аналогией макроблоков P типа, за тем отличием, что имеют ссылки на будущие кадры. Область применения - расширенный и основной профили.

SP и SI - слои (от англ. switch P/I). Данные слои позволяют осуществлять переключение между кодируемыми потоками. Область применения - расширенный профиль.

Кадр кодируется в один или несколько слоев, в каждом из которых содержится целое число макроблоков - от одного до полного числа макроблоков на снимке (случай, когда кадр разбит только на один слой). Как видно из описания выше, базовый профиль, используемый в данной дипломной работе, поддерживает закодированные последовательности, в которые входят слои P и I типа. Кадры I типа, могут содержать слои I типа, а кадры P типа - слои типа P. Поскольку базовый профиль стандарта использует только P (ссылки на прошлые закодированные) и I (ссылки внутри кадра) слои кодирующее и декодирующее устройства при работе в режиме базового профиля имеют лишь ссылки на ранее закодированные кадры. Эти кадры хранятся в буфере декодированных списков DPB (от англ. Decoded Picture Buffer) как кодирующим устройством, так и декодирующим.

Какой же представляется последовательность закодированных кадров на выходе кодирующего устройства? Первый кадр видеопотока всегда является кадром I типа. Остальные кадры, в зависимости специфики выполняемой задачи, могут быть как кадрами P типа, так и I типа. Если два кадра I типа имеют номера n и k, при сквозной нумерации кадров видеопотока, при условии, что n < k, то группой кадров (англ. GOP - Group Of Picture) назовем все кадры c номерами f_x, которые удовлетворяют следующему условию n ? f_x < k. Подобный видеоряд изображен на рисунке 5.

Рис. 5. Группа кадров. Стрелками обозначены ссылки между кадрами.

Как видно из рисунка, P кадр может ссылаться и за пределы группы. Существуют и определенные модификации I кадров, содержащие в себе дополнительные команды декодирующему устройству, запрещающие ссылки на кадры из других групп. Данные кадры, а так же механизмы борьбы с искажением видеопотока, вызванными потерями NAL частей при передачи по сети, будут рассмотрены в следующей главе.

2.3 Методы восстановления видеоряда при потерях в канале передачи данных

Кодирующее устройство на выходе формирует битовый поток, состоящий из последовательности единиц NAL (минимум одна единица NAL, а максимум зависит от конкретной реализации кодирующего устройства). NAL объекты сегментируются на пакеты размером MTU (англ. maximum transmission unit - максимальный размер данный, который может быть передан без фрагментации в рамках протокола транспортного уровня модели OSI [7]) и далее отправляются по сетевому каналу на принимающее устройство. Если один или несколько пакетов будут потеряны в процессе передачи данных по сети, то декодирующие устройство неверно интерпретирует часть информации, и как следствие восстановит текущий кадр с заметными для человеческого глаза искажениями. Следующие кадры будут декодированы с большим количеством искажений, за счет наличия ссылок «здоровых» макроблоков на «зараженные». Распространение искажений, вызванные потерями частей битового потока, носят так называемый лавинный характер и способны со временем занять все кадровое пространство. Какие средства стандарта H.264, помимо использования нескольких слоев, призваны уменьшить распространение потерь?

Первый из них IDR кадр (от англ. Instantaneous Decoder Refresh) - кадр, который состоит из слоев I типа и содержит команду для декодирующего устройства, после получения которой, декодирующее устройство «очищает» ссылочный буфер, т.е. помечает все кадры этого буфера как «неиспользуемые для ссылок». При генерации IDR кадра кодирующее устройство проводит аналогичный процесс. Группа кадров для битового потока, содержащего IDR снимки, представлена на рисунке 6.

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

Следующие два способа, призванные исправить уже полученные искажения в восстановленном битовом потоке - Intra Refresh (от англ. Refresh - обновление) и Invalidate Reference (перевод: «объявить ссылку недействительной»). Во многих реализациях видеокодеков и библиотек видеосжатия эти методы являются взаимоисключающими.

Intra Refresh (обновление) - особая команда для кодирующего устройства, после получения которой количество следующих кадров равное периоду обновления, будут иметь уникальные для периода обновления макроблоки, прогнозируемые в рамках одного кадра (т.е. без ссылок на предыдущие кадры - прогнозируемые в моде Intra). Понятие период обновление определяется как количество кадров, за которое проходит обновление. Каждый кадр кодируется одинаковым количеством макроблоков. Если все макроблоки пронумеровать от 0 до n, то в период обновления каждый макроблок будет закодирован в моде Intra и при том только один раз. Данный процесс схематично изображен на рисунке 7.

Рис. 6. Группа кадров с IDR снимками. Стрелками обозначены ссылки между кадрами.

Рис. 7. Метод обновления (Intra Refresh). Стрелками обозначены ссылки между кадрами. А - область кадра, обновленная макроблоками мода Intra в рамках периода обновления.

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



Рис. 8. Метод удаления ссылок (Invalidate Reference) для ликвидации искажения восстановленного видеоряда. Стрелками обозначены ссылки между кадрами

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

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

2.4 Битовая скорость данных

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

Рис. 9. Вариации битовой скорости. Иллюстрирующий график

На рис. 9 изображен иллюстрирующий график вариаций битовой скорости. Первый кадр является кадром I типа и занимает около 10000 Кбит. Дальше в группе кадров идут P кадры, которые, в зависимости от степени сложности видеоряда (высокое количество движения, наличие мелких деталей и т.п.), занимают от 2000 до 10000 Кбит. Такие скачки битовой скорости могут породить большие проблемы для многих протоколов транспортировки и хранения. Например, канал с постоянной скоростью (канал с коммутацией) неспособен передавать потоки данных с переменной скоростью. Сети на основе коммутации пакетов могут поддерживать переменную скорость передачи данных, но средняя пропускная способность в любой момент времени ограничена определенными факторами, зависящими от скорости связи и перегруженности. В этих случаях необходим контроль и адаптация битовой скорости, производимой кодирующий устройством, для ее соответствия скорости транспортировки.

Переменную скорость данных, производимых кодирующим устройством, можно «сгладить» с помощью их буферизации до передачи с использованием специального буфера типа FIFO (от англ. First In/ First Out, «первым вошел - первым вышел»). Суть данного метода такова, что этот буфер освобождается с постоянной битовой скоростью, которая соответствует скорости транспортировки, в то время как заполняется с переменной битовой скоростью данных, генерируемых кодирующим устройством. Точно такой же буфер типа FIFO помещается на входе декодирующего устройства. Он заполняется с фиксированной скоростью транспортировки данных, а освобождается с переменной скоростью, так как декодирующее устройство извлекает некоторое количество бит для декодирования следующего кадра, а число извлеченных бит меняется от кадра к кадру.

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

3. Алгоритм адаптации потока видеоданных

Кодирующее устройство генерирует поток видеоданных с переменной битовой скоростью. Как уже было рассмотрено в главе 2.4, это ведет к увеличению мгновенного интервала между кадрами, что с точки зрения человеческого восприятия выглядит как торможение видео и затем немедленное его ускорение на стороне декодирующего устройства. Если битовая скорость превышает пропускную способность канала, то высока вероятность потери пакетов, составляющих объект NAL, что влечет к искажению видеоряда на стороне декодирующего устройства. В случае если мгновенная битовая скорость меньше пропускной способности канала, вероятность потерь остается не нулевой для некоторых протоколов транспортного уровня, в частности, например, UDP (от англ. User Datagram Protocol). Единичная ошибка восстановления макроблока любого кадра (из-за потери пакетов) через какое-то время может привести к искажению всего пространства кадра. Это происходит за счет того, что макроблоки новых кадров, ссылаются на неверный, искажения растут, этот процесс носит «лавинный» характер.

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

3.1 Клиент-серверная архитектура

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

Рис. 10. Клиент-серверная архитектура. Обозначения: М.З.В - модуль захвата видео, М.К.У - модуль кодирующего устройства, М.Д.У - модуль декодирующего устройства, М.А.В - модуль алгоритма адаптации видео, М.Т. - транспортный модуль, М.В. - модуль видеоплеера. RGB, H.264 - форматы передаваемых данных

В случае облачного сервиса клиент (рис. 10) - это программа, которая имеет транспортный модуль, модуль декодирующего устройства стандарта H.264, а так же модуль видеоплеера, который проигрывает восстановленные кадры в реальном времени.

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

Задача модуля декодирующего устройства - принять битовый поток кадра, восстановить информацию, и передать полученный кадр формата семейства RGB модулю видеоплеера. Так же, модуль декодирующего устройства генерирует внеочередные команды, которые не являются частью кадровых отчетов. Эти команды через транспортный модуль отправляются сразу на сервер.

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

Модуль захвата видео производит поток исходных несжатых данных - кадров формата семейства RGB. Это может быть приложение с реализованной функцией захвата видео из модуля рендеринга (от англ. Rendering - изображать), который призван создавать определенное количество кадров в секунду и генерировать ссылки на эти кадры для DWM модуля (от англ. Desktop Windows Manager - объект операционной системы Windows, призванный формировать изображение рабочего стола), если мы говорим о семействе операционных систем Windows.

Задача серверного транспортного модуля - принять битовый поток сжатого кадра, сегментировать его на пакеты и отправить клиенту по сети. Так же транспортный модуль принимает отчеты от клиента о пропускной способности канала, состоянии сети (наличие перестановок, дублирований пакетов и т.п.), состоянии видеопотока, а также внеочередные команды декодирующего устройства. Эту информацию он передает модулю адаптации видеопотока.

Модуль алгоритма адаптации видеопотока анализирует полученную от транспортного модуля информацию и на основе этого генерирует команду кодирующему устройству о смене характера видеопотока. Так происходит адаптация видеопотока.

В рассмотренной выше схеме присутствует канал обратной связи, через который осуществляется прием и передача отчетов от клиента к серверу и внеочередных команд декодирующего устройства. Его отсутствие накладывает существенное ограничение на используемые механизмы стандарта H.264 для борьбы с искажениями восстановленных кадров - IDR кадр, механизм удаления ссылок требуют сообщений от декодирующего устройства кодирующему. Иначе, если канала обратной связи нет, мы вынуждены перегружать канал лишней битовой скоростью за счет постоянного использования Intra Refresh с уменьшенным периодом, ведь мы не можем судить о наличии и характере потерь пакетов.

3.2 Задачи и ограничения алгоритма

Перед созданием механизма адаптации видеопотока необходимо определить ряд ограничений на используемый алгоритм, которые диктуют способ реализации последнего. Рассмотренные ниже ограничения вызваны в первую очередь использованием широко распространенного стандарта видеокодирования H.264, а так же спецификой облачных технологий и «задачи видеоконференции».

Передача видеопотока в виде изолированных друг от друга групп пакетов данных. Данная особенность связана напрямую со стандартом H.264. Многие реализации видеокодеков, или кодирующих устройств, генерируют на выходе порции битового потока, которые соответствуют принятым кадрам на входе. Если вычислительная машина справляется с процессом обработки данных, то количество кадров на входе, и соответствующих порций сжатых данных на выходе в единицу времени одинаково. При этом каждый сжатый кадр необходимо тут же отправить на принимающую сторону. В противоположном случае видеоплеер будет проигрывать восстановленные кадры либо замедленно, либо ускоренно и в конечном итоге нарушается постоянное значение воспроизводимой частоты кадров, что существенно влияет на качество воспринимаемого человека видеоряда. При отправке данные разделяются на пакеты, соответствующие пакетам протокола транспортного уровня. В качестве такого протокола был выбран протокол UDP, который, в отличие от протокола TCP, осуществляет передачу данных с меньшей задержкой, но не гарантирует их доставку. Таким образом, алгоритм адаптации должен оперировать информацией о пакетах как возможной неделимой единицей данных.

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

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

Отсутствие буферизации данных, как на стороне получателя, так и на стороне отправителя. О проблемах, вызванных буферизацией данных, шла речь в гл. 2.4. В облачных технологиях ощутимые для человеческого восприятия задержки составляют до 30 - 50 мс, а в видеоконференциях - до 100 мс. Так же следует пояснить, что некоторая буферизация присутствует, но по сравнению с известными технологиями такими, как IPTV, где значение буферизации составляет от 1 - 2 мин [5], в облачных технологиях буферизация не может превосходить значения одного кадрового интервала. Данное ограничение существенно препятствует использованию избыточности данных (подробнее об избыточности данных - глава 5).

3.3 Протокол взаимодействия

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

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

Уникальный идентификатор кадра (сокр. УИК). Данный параметр на всем процессе взаимодействия (рис. 10) определяет порядковый номер кадра с помощью сквозной нумерации. Необходим для определения принадлежности кадра той или иной группе кадров.

Уникальный идентификатор группы пакетов (или NAL объекта, сокр. УИГП). Данный параметр определяет порядковый номер NAL объекта, который необходим для определения принадлежности NAL объекта тому или иному кадру.

Уникальный идентификатор пакета данных (сокр. УИПД). Данный параметр определяет порядковые номера пакетов данных, передаваемых по сети. Этот параметр необходим для выявления кадра с искаженными макроблоками на стороне клиента. Детектируя потерю пакета (факт того, что пакет за отведенное на ожидание всей группы пакетов время не был доставлен по сети транспортному модулю клиента), транспортный модуль клиента формирует отчет, в котором указываются конкретные номера потерянных пакетов. Вместе с тем, как сжатый битовый поток поступает на вход декодирующего устройства, на сервер отправляется отчет, содержащий данные о потерях. На сервере по уникальному идентификатору потерянных пакетов удается восстановить уникальный идентификатор группы пакетов, а так же уникальный идентификатор кадра, что позволяет использовать механизм удаления ссылок стандарта H.264, а значит, последующие кадры не будут ссылаться на искаженный, что предупредит лавинный рост искажений в видеоряде. Информация, определяющая принадлежность пакета NAL объекту и кадру хранится на сервере определенное количество времени в виде связей УИК - УИГП - УИПД.