Главная Случайная страница


Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Некоторые алгоритмы H-стандарта.

2.7.1. H.261

Стандарт H.261 специфицирует кодирование и декодирование видеопотока для передачи по каналу p*64 Кбит, где p=1..30. В качестве канала может выступать, например, несколько телефонных линий.

Входной формат изображения - разрешения CIF или QCIF в формате YUV (CCIR 601) частота кадров от 30 fps и ниже. Используется уменьшение разрешения в 2 раза для компонент цветности.

В выходной поток записываются два типа кадров: INTRA - сжатые независимо (соответствуют I-кадрам) и INTER - сжатые со ссылкой на предыдущий кадр (соответствуют Р-кадрам). В передаваемом кадре не обязательно присутствуют все макроблоки изображения, если блок изменился незначительно передавать его обычно нет смысла. Сжатие в INTRA кадрах осуществляется по схеме сжатия отдельного изображения. В INTER кадрах производится аналогичное сжатие разности каждого передаваемого макроблока с "наиболее похожим" макроблоком из предыдущего кадра (компенсация движения). Для сглаживания артефактов ДКП предусмотрена возможность применения размытия внутри каждого блока 8x8 пикселей. Стандарт требует, чтобы INTRA кадры встречались в потоке не реже чем через каждые 132 INTER кадра (чтобы не накапливалась погрешность кодирования и была возможность восстановиться в случае ошибки в потоке).

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

Плюсом алгоритма является, простота в аппаратной реализации, а минусами – невысокая степень сжатия и ограничения на формат.

H.263

Данный стандарт является расширением, дополнением и значительным усложнением H.261. Он содержит "базовый" стандарт кодирования, практически не отличающийся по алгоритмам сжатия от H.261, плюс множество опциональных его расширений. Кратко перечислим наиболее важные отличия:

1. Использование арифметического кодирования вместо кодов Хаффмана. Дает возможность на 5-10% повысить степень сжатия.

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

3. Возможность задания вектора смещения для каждого блока 8x8 в макроблоке, что в ряде случаев существенно увеличивает сжатие и снижает блочность изображения.

4. Появление B-кадров, которое позволяет увеличить степень сжатия, за счет усложнения и увеличения времени работы декодера.

5. Поддержка большого числа форматов входных видеоданных: sub-QCIF, QCIF, CIF, 4CIF, 16CIF и отдельно настраиваемые. Основное отличие от более универсальных форматов заключается в адаптации для нескольких фиксированных разрешений, что позволяет делать менее универсальные, но более быстрые процедуры обработки кадров. Построенный таким образом декодер работает несколько быстрее.

6. Компенсация движения с субпиксельной точностью. Возможность сдвинуть блок на полпиксела также увеличивает степень сжатия, но увеличивает время работы декодера.

7. Особый режим сжатия INTRA макроблоков со ссылкой на соседние макроблоки в обрабатываемом кадре, особый режим квантования и специальная таблица Хаффмана для улучшения сжатия I-кадров в ряде случаев.

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

9. Изменение разрешения и деформирование базового кадра, использующегося в качестве базового при сжатии.

10. Различные режимы квантования и кодирования по Хаффману.

Плюсы: Алгоритм H.263 также как H.261 допускает быструю аппаратную реализацию, однако при этом позволяет добиться большей степени сжатия при том же качестве. Поддерживает сжатие звука.

Минусы: По количеству заложенных идей находится между MPEG-2 и MPEG-4.

Сжатие Н.264

Новейшая технология сжатия видеоизображений H.264 – большой шаг вперед для многих проблемных областей. Применение этого формата позволяет без потери качества изображения получать файлы на 80% меньше, чем при использовании Motion JPEG, и на 50% - чем при использовании стандарта MPEG-4 Part 2. Для передачи и хранения таких файлов требуется значительно меньше ресурсов сети и дискового пространства, что позволяетт либо снизить стоимость систем, либо значительно повысить качество изображения при сохранении прежней скорости передачи битов.

Специалисты полагают, что благодаря таким великолепным показателям, формат H.264 (известный также как MPEG-4 Part 10/AVC – улучшенная система кодирования видео) в ближайшие годы станет наиболее предпочтительным способом сжатия. Эта технология уже используется на новых мобильных телефонах и цифровых видеоплеерах и быстро завоевывает признание пользователей. Поставщики услуг, в том числе владельцы сетей хранения видеофайлов и телекоммуникационные компании, также начинают работать с H.264. Судя по всему, индустрия систем видеонаблюдения не останется в стороне.

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

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

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

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

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

Однако, если сжимаемое изображение интенсивно меняется, дифференциальное кодирование не позволяет достичь значительного сжатия. Для таких случаев больше подходит поблочная компенсация движения

В стандарте H.264 технология сжатия видеоизображения вышла на новый уровень: появилась более совершенная схема внутреннего предсказания, используемая для кодирования I-кадров. Благодаря этой схеме количество битов, необходимых для хранения I-кадра, значительно снижается, а качество изображения остается неизменным. Получить такой результат удается за счет использования моноблоков меньшего размера. Поиск совпадающих пикселей теперь осуществляется среди ранее закодированных пикселей, расположенных по краям нового макроблока. Значения этих пикселей используются повторно. В результате объем, который занимает изображение, значительно уменьшается.

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

При использовании H.264 удается также уменьшить количество артефактов блочности, характерных для Motion JPEG и других стандартов MPEG. Для этой цели в цикле кодирования используется внутренний фильтр деблокинга. В результате применения адаптивных алгоритмов удается сгладить края блоков и получить на выходе видеоизображение почти идеального качества.

Глава 3. Один из последних алгоритмов сжатия видео: рецепторы как кодировщики.
Необычное решение обычной проблемы

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

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

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

И вот когда соизмеряешь все это с принципами устройства живого организма, оказывается, что достаточно лишь следовать этим принципам и никакой сложной математики не нужно вообще. Имитируем микродвижение глаза, и вот получили контурное изображение.

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

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

Любой нацеленный на удаление избыточной информации алгоритм иногда вынужден удалять важную информацию. Вопрос только в том, насколько сильны потери. Обязательно есть места, где алгоритм справляется удачно, и есть места, где происходят большие потери. Очень проблематично найти приемлемое решение. Например, возьмем тот же пример с цветом неба за статуей. При уменьшении объема видеопотока MPEG-алгоритм начинает срезать частотный диапазон тональных переходов неба, в результате чего небо имитируется выложенными рядом квадратиками с близкими цветами.

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

Допустим, у нас есть изображение с возрастающим цветом.

Возьмем из изображения одну горизонтальную линию. В ней 256 зеленых пикселей. Байтовые значения пикселей различаются на 1. Самый левый пиксель имеет значение 0, самый правый - 255. В итоге имеем 256 возрастающих по значениям байт.

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

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

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

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

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

Что касается алгоритма Pixel Behaviour Check: "Рецепторное" преобразование открывает новые возможности в сжатии, поэтому его просто необходимо использовать в PBC-алгоритме. Основная фишка алгоритма - сжатие за счет контроля поведения пикселей видеокадров. Направление контроля - вдоль кадров, а не вдоль линий одиночного кадра, как в обычных алгоритмах. Наверняка такая мысль уже давно обсуждалась, просто никто не предлагал более-менее подходящее ее воплощение. В общем-то, компенсация движения из MPEG немного похожа по сути, но там ведется наблюдение за двигающимися объектами. Здесь же контролируется поведение каждого пикселя кадра, не обращая внимания на двигающиеся объекты. Вполне реально объединить компенсацию движения с контролем поведения остальных пикселей.

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

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

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

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

Сам алгоритм декодирования очень прост и не требует серьезной производительности. Оперировать многопиксельным видеопотоком при декодировании оказалось делом несложным. Совсем другое дело было при кодировании.

Последнее изменение этой страницы: 2016-06-09

lectmania.ru. Все права принадлежат авторам данных материалов. В случае нарушения авторского права напишите нам сюда...