Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 | Следующая страница реферата

end;

Теперь пришло время объяснить, почему поля cpCurrent и cpExtent заданы типами с плавающей точкой. Дело в том, что в поле cpExtent элемента массива опорного кадра хранится величина изменения цветовой плоскости за один кадр повтора, а не за весь его период. Когда величина изменения за весь период делится на количество повторов, остаются дробные части. Отбрасывать дробные части нельзя, потому что динамика изменения цветовой плоскости может быть разная. Из кадра в кадр поле cpCurrent изменяется на величину поля cpExtent. Представьте, что за 100 кадров цветовая плоскость пикселя изменилась всего на 1 процент. Разделив 1 на 100 кадров и округлив результат, мы получим 0. В результате точка на протяжении 100 кадров не изменится на 1 процент, ведь мы будем добавлять к полю cpCurrent нулевое значение поля cpExtent. А вот если мы будем добавлять с дробными частями, точка за 100 кадров плавно достигнет изменения в 1 процент. Округление до целого числа выполняется только в момент вывода цветовых плоскостей пикселя в реальный кадр на экране, но внутри опорного кадра все вычисления делаются исключительно с дробными частями.

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

// вычисляем индекс следующего поведения в наборе

Inc(Frame[I].cpBehaviour);

// если в наборе еще не закончились поведения, тогда

// читаем следующее поведение из набора, иначе

// сбрасываем cpIndex в 0FFFFh и читаем поведение из общего видеопотока

if (Frame[I].cpBehaviour 0) and 

(Frame[I].cpBehaviour = Header.FrameCount then Halt;

end;

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

За счет чего происходит сжатие

В качестве примера я взял из фильма "Шестой день" поведение красной цветовой плоскости произвольного пикселя в центральной части кадра. Всего взято 100 кадров, что равно 4 секундам фильма при скорости 25 кадров в секунду. Специально выбрал фрагмент фильма, где развивается динамичное действие. Через кадр быстро проезжает машина, а за ней появляется новая сцена с вертолетом. А теперь посмотрим, как вела себя цветовая плоскость R на протяжении 100 кадров.

185, 193, 194, 194, 192, 197, 197, 207, 207, 204, 204, 201, 201, 197, 200, 197, 208, 210, 208, 206, 209, 209, 216, 216, 216, 215, 214, 214, 214, 214, 214, 214, 217, 217, 216, 216, 215, 216, 079, 030, 028, 009, 047, 021, 008, 017, 060, 025, 024, 018, 013, 015, 015, 017, 017, 017, 017, 017, 017, 016, 016, 016, 012, 011, 015, 015, 015, 014, 005, 006, 008, 008, 008, 008, 008, 004, 011, 012, 012, 012, 012, 012, 012, 012, 012, 012, 012, 012, 012, 012, 007, 007, 006, 053, 054, 058, 053, 052, 050, 047

Здесь указаны непосредственные значения красной цветовой плоскости пикселя для каждого из 100 извлеченных кадров. Значение цветовой плоскости всегда лежит в пределах одного байта, а значит, изменяется только от 0 до 255. Как вы можете заметить, в малых значениях добавлены ведущие нули. Я сделал это для того, чтобы выровнять значения для их удобного просмотра при любом размере текстового окна.

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

000, 008, 001, 000, 002, 005, 000, 010, 000, 003, 000, 003, 000, 004, 003, 003, 011, 002, 002, 002, 003, 000, 007, 000, 000, 001, 001, 000, 000, 000, 000, 000, 003, 000, 001, 000, 001, 001, 137, 049, 002, 019, 038, 026, 013, 009, 043, 035, 001, 006, 005, 002, 000, 002, 000, 000, 000, 000, 000, 001, 000, 000, 004, 001, 004, 000, 000, 001, 009, 001, 002, 000, 000, 000, 000, 004, 007, 001, 000, 000, 000, 000, 000, 000, 000, 000, 000, 000, 000, 000, 005, 000, 001, 047, 001, 004, 005, 001, 002, 003

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

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

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

00, 03, 00, 00, 00, 01, 00, 03, 00, 01, 00, 01, 00, 01, 01, 01, 04, 00, 00, 00, 01, 00, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01, 00, 00, 00, 00, 00, 53, 19, 00, 07, 14, 10, 05, 03, 16, 13, 00, 02, 01, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01, 00, 01, 00, 00, 00, 03, 00, 00, 00, 00, 00, 00, 01, 02, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 00, 01, 00, 00, 18, 00, 01, 01, 00, 00, 01

Вы видите, какие получились маленькие значения, какое количество нулей. К слову сказать, MPEG стремится к такому же большому количеству нулей, но за счет множественных потерь информации. Но PBC-кодировщику мало достигнуто результата. В его арсенале есть еще массив поведений. Закодировав полученный набор из 100 байт аналогично RLE (PBC-алгоритм в своей основе использует метод, похожий на RLE, но несколько измененный), кодировщик начинает отыскивать в сжатом фрагменте похожие участки. Нужно сказать, что данный сжатый фрагмент представляет собой поток поведений 100 кадров красной цветовой плоскости. Когда в потоке поведений (общий видеопоток) обнаруживается более одного похожего участка, кодировщик извлекает их из потока и забрасывает в свободный элемент массива поведений, а на место извлеченных участков ставит одно единственное поведение со ссылкой (с индексом) на этот элемент массива. Помещаемые в массив похожие участки поведений называются наборами поведений. Например, в окончательном наборе байт часто повторяются "не эффективно" кодируемые участки типа (00, 01), (00, 02) и (00, 03), которые сбрасываются в массив, а вместо них в поток поведений ставится одно поведение со ссылкой на соответствующие элементы массива поведений. Естественно, участки типа (00, 01) и т.п. забрасываются в массив поведений не как значения 0 и 1, а как их PBC-сжатый вариант. Принцип заполнения массива поведений чем-то похож на LZW-сжатие.

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

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

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

Рекомендуем скачать другие рефераты по теме: краткий доклад, література реферат.



Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки