Квантизатор видео что это
Манипуляции с матрицами квантования. Часть 2
Это продолжение статьи, в которой я больше расскажу о теории и практике кодирования видео с помощью Xvid, а также представлю улучшенную версию своей матрицы, в которой показатель «качество/размер» стал больше. Подробности под катом.
Недавно кодеку Xvid исполнилось 7 лет, а вообще данный принцип сжатия видео существует 15 лет, но в инете на русском языке путёвой информации по вопросам кодирования немного. Для затравки можете почитать это: сжатие видео, MPEG-4, Xvid.
Я же только кратко коснусь теории (подробней, честно говоря, знаю не особо). Перед кодированием картинка разбивается на блоки 8х8, для каждого блока находятся средние значения яркости и цвета, а все пикселы преобразуются в математическую зависимость от средних величин. К полученной матрице применяется дискретно-косинусное преобразование с использованием матриц квантования. Матрица Intra для ключевых кадров, Inter для всех остальных. Левый верхний угол матриц используется для квантизации значений, которые мало отличаются от средней величины, соответственно правый нижний угол – для значений, которые сильно отличаются от средней величины. Чем больше коэффициент в матрице, тем больше огрубление значений яркости и цвета. Коэффициенты бывают в диапазоне 8-255. На этом квантизация не закончена, перед итоговой упаковкой все значения блока делятся на квантизатор, указанный в настройке кодека Xvid. На фото Target quantizer (выделен красным, фото после фото матрицы).
Квантизация – это огрубление сигнала. При кодировании значение сигнала делится на определённое число, а при декодировании умножается. Поскольку дробная часть отбрасывается, то при больших значениях квантизатора теряется много деталей и блоки 8х8 становятся слишком заметными. Но и размер файла при этом весьма мал. Поэтому задача кодирования сводится к тому, чтобы уменьшить квадратичность в файлах малого размера. И разработка собственной матрицы просто необходима.
Типы кадров. Проще говоря, кадры бывают ключевые и неключевые. Неключевые зависят от ключевых, они показывают изменение картинки (движение). На фото настроек Xvid показано стандартное значение интервала ключевых кадров 300, настройки вызываются нижней кнопкой «more» в основном окне настроек Xvid. Поскольку неключевой кадр занимает в 5 раз меньше места, чем ключевой, то малым размером файла мы обязаны именно ему. Значение больше 300 обычно не используется, ибо этого интервала хватает на 10-12 секунд просмотра. По объёму ключевые кадры при такой настройке займут 5-7 % вашего файла без учёта аудио.
На фотографиях ниже я покажу, как влияют коэффициенты матрицы квантования и квантизатор на качество картинки.
Для эксперимента я использовал следующую матрицу Intra: 
Как видите, первые коэффициенты я сделал максимальными, чтобы увидеть, в каких местах будут наибольшие искажения.
Все фотки в масштабе 300%. Это картинка до сжатия:
Это сжатие с квантизатором 2:
Это сжатие с квантизатором 4:
Как видим, квантизатор 4 делает квадраты более заметными, а коэффициенты 255 в матрице огрубляют большую часть значений яркости и цвета, так что блок расплывается в квадратное пятно. Если бы блоки были круглыми, то это выглядело бы как боке – фон, который не в фокусе. А то, что детали картинки всё ещё видны, это потому, что мы остальные коэффициенты оставили минимальными. Квантизатор 1 использовать категорически не рекомендуется из-за особенностей кодека, а больше 4 я не использую, потому что при этом сильно искажаются блоки.
Теперь о моей матрице. Её новый вид таков:
Она может применятся в трёх режимах. Настройки для всех режимов одинаковы, кроме одного параметра, основного квантизатора Target quantizer (выделен красным).
Важные настройки, выделенные красным, рекомендуется ставить как на фотке (подробно в первом посте).
1. Качественный. Target quantizer 2. Качество отличное, размер файла 80% (за 100% принимается размер файла при кодировании стандартной матрицей H263 с теми же настройками. От этого размера «пляшем» во всех режимах).
2. Компромисный. Target quantizer 3. Качество нормальное, размер 54%.
3. Сжатый. Target quantizer 4. Качество удовлетворительное, размер 40%.
Как видим, в третьем режиме имеем файл в 2 раза меньший, чем в первом (без аудио), но значительно жертвуем качеством. Хотя слово «значительно» имеет очень относительный смысл. Дело в том, что я сравнивал образцы, одновременно открытые в отдельных окнах VirtualDub’ом, покадрово в масштабах 200% и 300%. Если вы закодируете фильм с разрешением 1280х720 в третьем режиме и просто будете его просматривать в плеере, то может и не заметите разницу. Первый режим рекомендуется для видео с низким разрешением или для роликов, очень дорогих сердцу. Второй режим подходит для большинства фильмов, а третий для видео с большим разрешением или для роликов, где важно не качество, а сам материал.
Выбирая третий режим, не забудьте о качестве звука, ибо аудио в формате 5:1 384 Кбит занимает немало места (в фильме обычно 300 Мб). Для переноса аудио из любого формата в mp3 рекомендую Format Factory. Он бесплатен, кодирует видео и аудио. Ещё для информации: минимальный формат аудио mp3, при котором сохраняется нормальное звучание, это mono 48 Kbit 44 KHz. Не кодируйте в 22 KHz, ибо это значительно хуже на любом битрейте. Также не кодируйте в 48 KHz, если у вас исходник меньшей частоты или вы её не знаете. Изменение частоты обычно приводит к искажениям. 44 KHz – самая безопасная частота.
У многих возникнет вопрос: почему надо кодировать с постоянным квантизатором? Потому что в любом другом режиме (двухпроходный режим, постоянный битрейт) вы не контролируете квантизатор. А именно квантизатор в первую очередь отвечает за квадратичность (см. выше эксперимент). Также почитайте в первом посте о дополнительных настройках Xvid, без них использование моей матрицы не будет эффективным.
Постоянный квантователь в сравнении с многопроходностью
Возможно кодировать Ваш фильм, широко варьируя качество. С современными видеокодерами и небольшим сжатием перед кодированием (уменьшением размера и шумов) возможно достичь очень хорошего качества при размере 700 МБ для 90-110-минутного широкоэкранного фильма. Более того, всё, кроме самых длинных фильмов, может быть кодировано с почти безупречным качеством на 1400 МБ.
Есть три подхода при кодировании видео: постоянный битпоток (CBR), постоянный квантователь и многопроходность (ABR или усреднённый битпоток).
Сложность кадров фильма и, таким образом, число битов, нужных для их сжатия может существенно отличаться от одной сцены к другой. Современные видеокодеры могут подстраиваться под это в процессе работы и варьировать битпоток. Однако, в таких простых режимах как CBR кодеры не знают загруженность битпотока в последующих сценах и т.о. не могут превысить затребованный битпоток для больших промежутков времени. Более совершенные режимы, такие как многопроходный режим, могут учитывать статистику предыдущих проходов; это решает проблему, упомянутую выше.
Замечание:
Большинство кодеков, поддерживающих ABR кодирование, поддерживают только двупроходный режим, в то время как некоторые другие, такие как x264, Xvid и libavcodec поддерживают многопроходность, несколько улучшающую качество на каждом проходе, однако, это улучшение не измеримо и не заметно после 4-го прохода или около того. Поэтому, в данном разделе дву- и многопроходность будут использоваться взаимозаменяемо.
В каждом из этих режимов видеокодек (такой как libavcodec) разбивает видеокадр на макроблоки размером 16х16 пикселей и потом применяет квантователь к каждому макроблоку. Чем меньше квантоваль, тем лучше качество и выше битпоток. Метод, используемый видео кодером для определения того, какой квантователь использовать для данного макроблока, варьируется и подлежит тонкой настройке. (Это крайнее упрощение реального процесса, но основная концепция полезна для понимания.)
Когда Вы указываете постоянный битпоток, видеокодек будет кодировать видео, отбрасывая детали столько, сколько необходимо и настолько мало, насколько это возможно с целью оставаться ниже заданного битпотока. Если Вас действительно не волнует размер файла, Вы можете также использовать CBR и указать бесконечный битпоток. (На практике это означает значение, достаточно большое для обозначения отсутствия предела, например, 10000 Кбит.) В результате, без реального ограничения битпотока, кодек использует наименьший возможный квантователь для каждого макроблока (как указано опцией vqmin для libavcodec, равной 2 по умолчанию). Как только Вы укажите настолько низкий битпоток, что кодек будет вынужден использовать более высокий квантователь, Вы почти наверняка испортите качество Вашего видео. Чтобы избежать этого, Вам, вероятно, придётся уменьшить размеры Вашего видео, согласно методу, описанному далее в этом руководстве. В общем, Вам следует избегать CBR совсем, если Вы заботитесь о качестве.
С постоянным квантователем кодек использует для всех макроблоков один и тот же квантователь, указанный в опции vqscale (для libavcodec). Если Вы хотите рип наивысшего возможного качества, снова не взирая на битпоток, Вы можете использовать vqscale=2. Это приведёт к тому же битпотоку и PSNR (пику отношения сигнала к шуму), что и CBR с vbitrate=бесконечности и значением по умолчанию vqmin, равным 2.
Проблема с постоянным квантованием заключается в том, что кодек использует заданный квантователь вне зависимости от того, требуется это для макроблока или нет. То есть возможно использование большего квантователя для макроблока без ухудшения видимого качества. Зачем тратить биты на излишне низкий квантователь? У Вашего процессора есть столько тактов, сколько есть времени, но имеется лишь ограниченное число битов на жёстком диске.
При двупроходном кодировании первый проход создаст рип фильма так, как будто это был CBR, но сохранит лог свойств для каждого кадра. Эта информация затем будет использована во время второго прохода для принятия интеллектуальных решений о том, какой квантователь следует использовать. Во время быстрого движения или сцен с высокой детализацией с большой вероятностью будут использованы большие квантователи, а во время медленного движения или сцен с низкой детализацией — меньшие. Обычно количество движения играет существенно более важную роль, чем количество деталей.
Если Вы используете vqscale=2, то Вы теряете биты. Если Вы используете vqscale=3, то Вы не получаете рип наивысшего качества. Предположим, Вы делаете рип DVD, используя vqscale=3, результат получается 1800 Кбит. Если Вы сделаете двупроходное кодирование с vbitrate=1800, получившееся видео будет обладать лучшим качеством для того же битпотока.
После того, как Вы сейчас убедились, что два прохода — это путь к действию, возникает вопрос о том, какой битпоток использовать? Ответ таков, что нет единого ответа. В идеале, Вы хотите выбрать битпоток, при котором достигается наилучший баланс между качеством и размером файла. Здесь возможны вариации в зависимости от исходного видеоматериала.
Если размер не важен, хорошей отправной точкой для рипа очень высокого качества будет 2000 Кбит +/- 200 Кбит. Для видеоматериала с быстрым движением или высокой детализацией или просто если у Вас очень разборчивый глаз, Вы можете использовать 2400 или 2600. Для некоторых DVD Вы не заметите разницы на 1400 Кбит. Хорошей идеей является экспериментирование со сценами на разных битпотоках, чтобы почувствовать разницу.
x264 + VirtualDub vs XviD. Исследуем возможности, повышаем эффективность
Краткая информация
Кодек x264 — очень успешная реализация стандарта H.264, созданная под крылом сообщества VideoLAN (автора VLC media player) со свободной лицензией. Обычно экспортируется консольный вариант, ориентированный в первую очередь на юниксоидов, под винды также есть варианты с графическим интерфесом. Собственно, недружественность опенсорсных разработчиков с рядовыми пользователями (вечные проблемы с документацией и графическим интерфейсом успешно и по сей день отделяют Microsoft от многих хороших и бесплатных проектов) и стала тормозным фактором на пути выхода кодека к широким массам и любителям видеоколлекций. Но, слава Всевышнему, не всё так уныло на сегодняшний день и есть достойные графические варианты. Теперь будьте внимательны, потому что речь пойдёт именно о релизе 2273 от Komisar (ссылка здесь). Сам файл, который установится в систему, это x264vfw.dll. Установить его можно на любой диск, а установщик позаботится, чтобы этот путь попал в реестр винды. Также вы можете иметь установленным этот кодек, если у вас есть полный K-Lite Codec Pack. Если там иная версия, установите 2273. Я пробовал версию 2274 с другим интерфейсом — категорически не советую, если только вы не собираетесь вникать в консольные команды. Чтобы вы не запутались, смотрите скриншоты.
Маркёром выделены ключи, которые мы будем разбирать и менять. Поехали.
Quantizer — квантизатор, который огрубляет итоговый сигнал, чем больше, тем хуже качество. Я кодирую только квантизатором и только в один проход, почему — смотрите предыдущий пост.
Здесь он отличается от того, что в XviD, поэтому я прикинул, что нужно брать значения кратные 4. Вот резюме:
4, 8 — рекомендуется только тем, кто занимается обработкой видео, так как качество идеальное, но большой размер файла;
12, 16 — для любителей качественных роликов небольшого размера в домашней коллекции;
20 — мой выбор, самый оптимальный квантизатор, подходит для фильмов;
24, 28 — компромиссный вариант, нормальное качество, подходит для большинства фильмов и сериалов, а также для загрузки роликов на ютуб;
32 и выше — бывают и такие случаи.
Во второй вкладке много интересных и полезных настроек.
Блок Analysis — разбивка блоков на части, фишка стандарта H.264, призвана обеспечить лучшее качество, но на поверку оказалась практически бесполезной — размер файла увеличивается, улучшение качества нужно искать с микроскопом, так что отключайте все «пташки».
Subpixel ME refinement — сложность оценки движения, значения от 1 до 11.
Чем больше, тем меньше размер и скорость. На самом деле размер уменьшался до 5, с цифры 6 размер стал расти, а скорость падать, видимо, это связано с Psy RDO, который до цифры 6 не работает. Так что вывод такой: если хотите максимальную скорость, то ставьте 1 и жертвуйте несколькими мегабайтами, если же не хотите жертвовать мегабайтами, а минутами, то ставьте 5.
Max GOP size — максимальный интервал между ключевыми кадрами, подробнее в предыдущем посте. Ставьте в пределах 200-300 и не партесь.
Max consecutive B-frames — максимальная последовательность B-кадров, чем их больше, тем меньше размер, но с этим нужно быть осторожней, могут быть проблемы с воспроизведением. Рекомендую 1 или 2.
Мы подошли к блоку Encoding и это, пожалуй, наиболее интересная часть настроек.
Deblocking filter (птичка и два числовых значения) — решает проблему квадратов, так ненавистных у XviD. По-умолчанию стоят значения 0, максимум 6. Мне 0 показалось мало и я попробовал 6 — понравилось. Теперь всегда буду ставить 6. Компромисс — 3.
Intra / Inter Deadzone — сглаживающий фильтр, работает по принципу Гаусса. Интересно, что в VirtualDub есть подобный фильтр и я им часто пользовался, но теперь он особого смысла не имеет. Дело в том, что при использовании его только в VirtualDub кодек в итоге всё равно оставляет шумы, а если использовать его только в кодеке — никаких проблем с шумами. Я выбрал максимум 32, потому что некоторые моменты просто восторгают — проезжающая машина даёт перламутровый блеск, море и небо просто загляденье. Некоторые заметят, что есть недостаток замыливания мелких деталей, тогда советую меньшие значения, кратные 4. Отключить совсем можно при квантизаторе меньше 16. На скорость не влияет.
Остальные ключи на этой вкладке объяснять не буду — просто поставьте, как на скриншоте.
Теперь третья вкладка, скриншота нет и не нужно. Там только нужно изменить два значения раз и навсегда. QP factor — выставьте оба в 1, если не хотите сюрпризов в виде неожиданного ухудшения качества.
Теперь важная инормация для тех, кто пользуется внешним плеером. Если есть проблемы с воспроизведением, сделайте следующие настройки:
Max frame refs = 1, Max consecutive B-frames = 0, CABAC = выкл.
Не все эти настройки одновременно влияют на совместимость, поэтому экспериментируйте.
На скорость могут влиять Subpixel ME refinement, Max frame refs, Max consecutive B-frames. За счёт использования многоядерности x264 оставляет позади XviD. С теми настройками, которые на скриншотах, размер файла сопоставим с XviD со средним квантизатором, но качество гораздо лучше. Так что прощай старый добрый XviD, ты много отнял у меня времени и нервов, а также дискового пространства, но тебе пора на заслуженный покой.
Для особо интересующихся здесь можно почитать о настройках x264 на русском.
Профессиональное сжатие видео
профессиональное сжатие видео
крис касперски ака мыщъх, no-email
эта публикация открывает цикл статей, посвященный вопросам обработки видеоинформации в домашних условиях, и в первую очередь — осмысленной настройке MPEG2/MPEG4 кодеков, увеличивающей степень сжатия (без видимой потери качества) в несколько раз по сравнению с «сертифицированными профилями», установленными по умолчанию.
введение
Научно-технический прогресс развращает, приучая все делать одним взмахом мыши, в результате чего мы имеем DVD-диск от SUPERBIT и EXTRABIT «непревзойденного качества», подготовленные с помощью Ahead Nero (о чем честно свидетельствует поле Source Media Implementation Identifier, хранящееся на DVD-диске вместе с прочей служебной информацией) и записанные с грубыми нарушениями стандарта, в результате чего мы имеем проблемы — от появления «артефактов» и ухудшения качества, до полной невозможности воспроизведения диска на определенных моделях DVD-плееров (особенно стационарных).
Сжатие цифрового видео — очень сложная тема, намного более кромешная и запутанная, чем это кажется до попытки основательно разобраться в ней. Начав исправлять ошибки лицензионных DVD (исключительно в целях домашнего просмотра!), автор зарылся в стандарты, обложился спецификациями, скачал исходные коды всех доступных кодеков и… на несколько месяцев погрузился в пучину бесчисленных экспериментов, в результате чего стал сжимать намного качественнее и плотнее, чем окружающие. «Качественнее» — это значит лучше, чем на _оригинальном_ DVD-носителе (см. рис. 18, 19). Не верите? Говорите: «чудес не бывает»? А разве алгоритмы сжатия звука и видео — это уже само по себе не чудо? Немного людей знает на каких принципах они базируются и еще меньше готовы написать свой собственный кодек или усовершенствовать имеющийся.
Да что там! Подавляющее большинство использует настройки по умолчанию или пытается манипулировать ими вслепую. Журналы и пестрят сравнительными тестами различных кодеков, демонстрирующими один и тот же кадр, рассматриваемый под большим увеличением. И невдомек им, что при популярном двухпроходном сжатии и дробном quantizer’e разные кадры сживаются с разным качеством (поскольку quantizer дробным не бывает и если для достижения заданного объема целевого файла кодер решил, что нужно использовать quantizer == 2.5, в практическом плане это означает, что половина кадров закодируется с quantizer == 2, а половина — с 3 и результаты теста в большой степени зависят от того какой кадр мы возьмем). Так же, при динамическом битрейте кодек стремиться отдать больше битов тем сценам, в которых по ему мнению они сильнее всего нуждаются, отнимая их у всех остальных. Алгоритм перераспределения битов у всех кодеков разный и потому сравнивая _один_ и _тот_ _же_ кадр, сжатый разными кодеками, мы можем получить драматический разрыв в качестве, но… делать глобальные выводы на этом основании нельзя!
Это, так сказать, для затравки. Чтобы пробудить исследовательский интерес. Зная, как работает кодек, мы сможем осмысленно крутить его настройки для достижения максимального сжатия с минимальной потерей качества. Источником видеоматериала может выступать и цифровая камера, и карта видео-захвата, и TV-тюнер, и куча прочего потребительского барахла… но мы (для удобства) остановимся на DVD как на самом удобном и «послушном» носителе информации.
Естественно, законы многих стран запрещают перезапись лицензионных DVD даже в домашних целях (что есть полный абсурд), но в нашей стране Фемида намного более лояльна и до тех пор, пока мы не начнем _распространять_ скопированный (и пережатый) DVD тем или иным образом, можно смело экспериментировать и ничего не опасаться.
Причин же для копирования DVD имеется как минимум две: во-первых, лицензионные DVD (да и не лицензионные тоже) сплошь и рядом записаны с теми или иными ошибками, которые неплохо бы устранить (тем более, что технически это возможно), а во-вторых, DVD-диски занимают слишком много места (геометрического) и каждый раз рыться с завалах коробок — занятие не из приятных. Намного удобнее держать фильмы на жестком диске (кстати, законы — даже Американские — это позволяют, при условии, что диск используется только как кэш и дальше его фильмы никуда не уходят).
Короче, будем считать, что я вас заинтриговал. Правда, первую часть статьи, посвященную основам теории сжатия, придется поскучать и пошевелить мозгами, зато во второй пройдет чистая практика с кучей полезных советов.
требование к читателю
Предполагается, что читатель уже имеет некоторое представление о цифровом видео и хотя бы в общих чертах понимает, чем MPEG отличается от AVI. На всякий случай, вот несколько хороших FAQ по этому поводу:
q Introduction to MPEG:
o http://www. faqs. org/faqs/compression-faq/part2/section-2.html;
q The Unofficial XviD FAQ:
o http://ronald. vslcatena. nl/docs/xvidfaq. html;
q Современные методы и стандарты экономного кодирования видеоинформации:
o http://compression. *****/download/articles/video/standards/state-of-the-art-video-compression. pdf;
свет и цвет
Существует множество систем кодирования светоцветовой информации, воспринимаемой человеком. Большинство методов построено на сложении (вычитании) трех или четырех основных цветов. В частности, CRT-телевизоры формируют изображение путем трех лучевых пушек — красной (Red), зеленой (Green) и синей (Blue) и соответствующая ей цветовая схема называется RGB. Она же используется и в большинстве видео-карт. Популярный режим RGB32 (True-Color 32) на кодирование каждого пикселя расходует по 8 бит, плюс еще 8 бит отводится под канал прозрачности. Итого 3*8+8 = 32.
Нетрудно подсчитать, сколько байт потребуется для кодирования «картинки» с любым разумным разрешением. Такое количество информации очень трудно сохранить и еще труднее передать по радиоканалу. А при проектировании цветных телевизоров перед разработчиками поставили задачу — любой ценой вложиться в полосу пропускания отведенную для Ч/Б телевизоров, в которую RGB никак не желала укладываться и пришлось пойти на рад хитростей.
Считается, что нормальный человеческий глаз (художников мы не берем в расчет) способен распознать до 16 миллионов цветовых оттенков, в то время как 32-битный RGB дает 4.294.967.296, что _намного_ больше, то есть явный перебор. Сколько же бит _реально_ необходимо? Прибегнув к логарифмам нетрудно подсчитать, что 24 бита кодируют 16.777.216 оттенков. Но 24 бита это все равно очень и очень много. С другой стороны, далеко не все оттенки равнозначны…
Цветоощущенье — подарок природы, появившийся на поздних стадиях эволюции (многие животные его лишены и до сих пор!), в силу чего, глаз гораздо более чувствителен к изменению яркости, чем к положению в спектре (т. е. цветности). Отталкиваясь от этого факта, перед передачей в эфир исходные RGB-сигналы преобразуются в сигнал яркости Y (он же Luminance или Luma) и два цветоразностных сигнала U и V (Chroma), вычисляемых по следующей формуле:
Формула 1 перевод RGB-сигналов в YUV форму
Коэффициенты подобраны с учетом особенной человеческого восприятия: максимум воспринимаемой глазом световой энергии сосредоточено в зеленой (точнее, желто-зеленой) области спектра, поэтому ему выделяется наибольшее количество бит. Как видно, кодирование сигнала происходит с большими потерями, но… это неизбежная плата за узкие полосы пропускания. Радиодиапазон ведь не резиновый, а вещать хотят все…
Естественно, перед выводом на экран приходится осуществлять обратное преобразование:
Формула 2 перевод YUV сигналов в RGB
Подробнее об этом можно прочитать в любой книжке по ремонту и настройке цветных телевизоров или в следующей статье: http://www. *****/Articles/Article2.html. Какое отношение имеют телевизоры к компьютерам и (тем более!) к сжатию информации? Самое прямое. Поскольку, сжимать в основном приходится не RGB32, сграбленный с экрана, а видеоматериал, предназначенный для эфирной трансляции, то в нем _уже_ отсутствует _вся_ информация о 2^32 оттенках и потому MPEG-кодеры работают с «телевизионными» цветовыми схемами. В MPEG1 это YUV420 (она же YUV12 и YV12), в которой значение яркости (Y) сохраняется для каждого пикселя, а цветоразностные компоненты (U&V) получаются путем усреднения значений 4’х пикселей, образующий матрицу 2×2. На все компоненты отводится по 8 бит, в результате чего на одни пиксель приходится 12 бит (отсюда и название). Главным недостатком подобной схемы становится не только низкое цветовое разрешение, но и невозможность работы с черезстрочечным (interlaced) видеоматериалом, т. к. из-за объединения соседних вертикальных линий возникают сильные искажения.
В MPEG2 используется более продвинутая цветовая схема YUV422 (она же YUY2), которая, так же, как и предыдущая сохраняет яркостной сигнал (Y) для всех точек, а вот сигнал цветности усредняется у двух соседних пикселей по горизонтали, в результате чего появляется возможность работать с черезстрочечным видеоматериалом, цветовое разрешение возрастает вдвое, а на один пиксель уже приходится 16 бит.
В MPEG4-кодеках может использоваться как та, так и другая схема. YV12 встречается гораздо чаще, поскольку обладает более высоким сжатием, экономящим 35% бит по сравнению с YUY2. Кстати, именно по этой причине многие MPEG-4 кодеки первого поколения (такие, как DivX, например) не могли работать с черезстрочечным видео и перед его сжатием приходилось выполнять операцию de-interlaced, что не только требовало время, приводило к появлению «артефактов», но и ухудшало сжимаемость, но постепенно разработчики кодеков решили эту проблему и теперь при включении одноименной опции, черные промежуточные полосы _не_ сжимаются вообще, существенно сокращая размер выходного файла.
Ладно, это все была сухая теория. Переходим к суровой практике. При сжатии MPEG4-кодеком видеоматериала, представленного в формате YUY2 (например, DVD), искажения будут происходить не только из-за потери информации о цветности, но и… ошибок преобразования YUY2 в YV12 и последующей конвертации YV12 в RGB при выводе на экран монитора. Искажения цветопередачи зачастую оказываются весьма значительными и кристально чистая небесная голубизна превращается в унылую серую грязь. Чтобы понять почему так происходит (и что сделать, чтобы этого не происходило) необходимо разобраться в этом вопросе более подробно и основательно.
Начнем, как водится с канонов. Группа MSSG (MPEG Software Simulation Group) прилагает к стандарту рефересную (reference – эталон) версию библиотеки mpeg2, последнюю версию которой можно скачать по адресу: ftp://ftp. /pub/mpeg/mssg/mpeg2v12.zip (для доступа требуется логин и пароль) или утянуть ее прямо из института Беркли без всяких логинов и паролей: http://bmrc. berkeley. edu/ftp/pub/multimedia/mpeg/mpeg2/software/mpeg2v12.zip
В файле \src\mpeg2enc\readpic. c содержится исходный код функции readpic. c, преобразующий RGB в YUV2, ключевой фрагмент которой приведен ниже:
for (i=0; i > SCALEBITS_OUT); \
*(uint16_t *) (x_ptr+((ROW)*x_stride)+0) = C1(r[ROW], g[ROW], b[ROW]); \
rgb_y = RGB_Y_tab[ y_ptr[y_stride*(ROW) + 1] ]; \
*(uint16_t *) (x_ptr+((ROW)*x_stride)+2) = C1(r[ROW], g[ROW], b[ROW]);
Листинг 2 макрос из XviD’а, отвечающий за преобразование YUV в RGB
Чем плоха целочисленная арифметика? А тем, что ошибки округления приводят к искажению цветопередачи, которое в ряде случаев оказывается просто драматическим (особенно, если сравнивать сконвертированное изображение с оригиналом).
Для борьбы с этим явлением разработчики видео-карт придумали такую штуку как оверлей (overlay mode), позволяющую части экрана иметь цветовую схему, отличную от текущей. В overlay-mode видеоинформация проходит «транзитом» сквозь карту и поступает на монитор, не затрагивая остальные узлы, минуя в видеопамять и… освобождая центральный процессор от необходимости выполнения преобразования одной цветовой схемы в другую. Вот только… монитор, он ведь на входе совсем не YUV ожидает увидеть и потому оверлей не снимает проблему конвертации, а просто перекладывает ее на плечи карты. Причем, если программный алгоритм преобразования цветовых пространств легко поменять (выбирав из всех самый удачный), то с железом не поспоришь и карта выдает то, что в нее заложено.
Часть карт вообще не поддерживает overlay-mode, часть — поддерживает, но выдает изображение такого скверного качества, что на него практически невозможно смотреть (в особенности это относится к картам NVIDA). У почитаемого мной Matrox’а G450 с цветопередачей в режиме оверлея все нормально, но вот драйвера… при попытке перехода в overlay-mode они частенько обрушивают систему в голубой экран смерти, что совсем не добавляет оптимизма.
Стандартный Microsoft Media Player всегда стремится использовать оверлей и никой возможности отключить эту функцию у него нет (может быть и есть, где-нибудь в глубине реестра, да и то навряд ли). Плееры сторонних производителей (и в частности BSPlayer – http://www. bsplayer. org/) позволяют отключать оверлей установкой галочки «Force RGB mode» (см. рис. 2).
Рисунок 2 форсирование RGB-режима в BSPlayer’е
Ниже приводятся два кадра из одного и того же фильма. Первый получен в форсированном RGB-режиме, второй — в overlay-mode на карте NVIDA GeForce 6600. Как говориться, почувствуйте разницу!
Рисунок 3 кадр, полученный в RGB режиме (с кодеком FFDShow)
Рисунок 4 кадр, полученный в режиме оверлея на карте NVIDIA GeForce 6600
А разница такова, что в RGB-mode у мужика вид сильно поддатого грузчика 🙂 Зато в overlay-mode море и сгустившийся над ним туман приобретают грязно-серый цвет, а низ каната (если присмотреться повнимательнее!) окашивается в зеленый цвет! Уж не водорослями он успел обрасти за это время?!
Уже упомянутый кодек FFDShow имеет функцию высококачественного преобразования YV12 в RGB, активируемую установкой флажка «High quality VY12 to RGB conversion». Она отнимает дополнительные такты, но дает значительно лучший результат (см. рис. 5):
Рисунок 5 активирование функции высококачественного преобразования YV12 в RGB в кодеке FFDShow
Лицо приобретает нормальный телесный оттенок (см. рис. 6), но вот океан… Впрочем, не видя оригинала, трудно сказать насколько (не)качественно выполнено преобразование. Но по крайней мере, мы можем выбирать из всех вариантов преобразования тот, что наиболее приятен нашему глазу.
Рисунок 6 форсированный RGB-режим, кодек FFDShow (функция высококачественного цветового преобразования)
На этой ноте разборки с цветовыми схемами будем считать законченными и приступим к по-настоящему серьезным вещам.
дискретное косинусное преобразование
Фундаментом всех систем сжатия с потерями (JPEG, MP3, MPEG1/2/4) является дискретное косинусное преобразование (Discrete Cosine Transform или сокращенно DCT), представляющего собой разновидность косинусного ортогонального преобразования для вектора действительных чисел. Понять, что такое DTC можно на примере широко известного дискретного преобразования Фурье — Discrete Fourier Transform или DFT (дискретное косинусное преобразование представляет собой гомоморфизм его векторного пространства).
В общем случае DTC-преобразование осуществляется умножением вектора на матрицу преобразования:
Формула 3 DTC преобразование, записанное в матричной форме, здесь: [X] – начальная матрица, [C] и [CT] – матрицы с коэффициентами преобразования, где CT означает транспонированную матрицу
Алгоритмы MPEG1, MPEG2 и MPEG4 разбивают каждый кадр (фрейм) на блоки по 8×8 пикселей, над которыми осуществляется DCT-преобразование — сначала для каждой строки, а затем для каждого столбца матрицы, поэтому такое преобразование часто обозначается как DCT8 (число «восемь» означает 8 векторов).
После выполнения дискретного косинусного преобразования в Y-матрице уже нет пикселей и она превращается в совокупность волн с различными частотами и амплитудами. Низкие частоты, сосредоточенные в левом вернем углу матрицы, соответствуют крупным деталям исходного изображения. Высокие частоты, соответствующие мелким деталям, оккупируют правый нижний угол (см. рис. 7).
Обходя матрицу в зигзагообразном порядке от левого верхнего угла к правому нижнему, кодируем ее содержимое методом Хаффмана или Арифметическим кодированием или любым другим методом энтропийного кодирования, использующего коды переменной длинны. Как уже несложно догадаться, наиболее короткие коды достаются коэффициентам, расположенным в левом верхнем углу. Уже за счет одно лишь DCT-преобразования, мы добиваемся некоторого сжатия, причем это сжатие происходит без потерь, что, впрочем, не дает никаких оснований для радости, поскольку степень сжатия невелика и сопоставима с обычными архиваторами.
Чтобы увеличить сжатие, необходимо отсечь наименее значимые детали, практически не воспринимаемые человеческим глазом, но кодируемые наиболее длинными кодами. После выполнения DСT-преобразование эта задача выполняется элементарно, поскольку делали уже разделены на значимые и незначимые. Как говориться отсекай и властвуй. Операция отсечения осуществляется при помощи матрицы квантования, подробно описанной в одноименном разделе, там же где описан процесс квантования, определяющий качество сжатия в целом.
Закодированная матрица (или, точнее, все, что от нее осталось, поскольку после квантования большинство коэффициентов правого нижнего угла обращаются в нули) помещается в сжатый MPEG-файл и кодировщик переходит к обработке следующего 8×8 блока.
Для вывода картинки на экран декодер, естественно, должен превратить совокупность волн в привычные нам пиксели, выполняя операцию обратного дискретного косинусного преобразования — Inverse Discrete Cosine Transformation или, сокращено, IDCT. Понятное дело, что она уже не будет соответствовать оригиналу и часть деталей окажется безвозвратно утеряна.
матрица квантования
После выполнения DCT-преобразования мы получаем матрицу, наиболее значимые детали которой сосредоточены в левом вернем углу, а наименее значимые — в левом нижнем. Возникает естественное желание — отбросить незначимые детали, сократив размер целевого файла. Это достигается путем квантования.
Квантованием (применительно к обработке сигналов) называется деление величины сигнала на некоторое целое число, называемое квантом (quant), обычно обозначаемый буквой Q, а обратный ему процесс — деквантированием. С математической точки зрения X/Q = X*Q, но целочисленная арифметика «огрубляет» сигнал (см рис 8, 9), причем это «огрубление» тем сильнее, чем больше квант. При Q = 1 мы не теряем никаких деталей, при Q превышающим половину амплитуды сигнала — теряем все.
Рисунок 8 сигнал, переведенный в цифровую форму
Рисунок 9 оцифрованный сигнал после квантования
Применительно к MPEG сжатию операция квантования выполняется дважды — первый раз при наложении на DCT-матрицу специальной Матрицы Квантования (Quantization Matrix или QM) и второй раз — при квантовании коэффициентов матрицы, образующейся после наложения.
Стандартная MPEG-2 Матрица Квантования выглядит так (см. листинг 3):
Листинг 3 стандартная MPEG-2 Матрица Квантования
* needs 17 bit shift (16 causes slight errors when q > 19) */
#define SCALEBITS 17
#define FIX(X) ((1UL > SCALEBITS;
Листинг 5 псевдокод, иллюстрирующий наложение QM-матрицы и квантование заданным quantizer’ом (позаимствован из исходных текстов XviD’а)
Quantizer представляет собой целое число от 1 до 31 включительно. При Q = 1 мы сохраняем максимум деталей, а при Q = 31 – теряем все («теряем все» — в пределах одного 8×8 блока, который заливается одним цветом, и мы получаем мозаику из 8×8 квадратов, из которой еще кое-что можно разобрать).
На самом деле, 31 — это _очень_ большое число и уже при Q > 6 на изображение без содрогания смотреть становится невозможно. С другой стороны, учитывая, что DVD диски обычно записываются с Q = 2, становится ясно, что для большинства видеоматериалов имеет смысл использовать только Q от 2 до 6.
Ниже представлен ряд изображений, сжатых с разными quantizer’ами для сравнения:
Рисунок 10 изображение, сжатое с Q = 1
Рисунок 11 левая половина — Q = 1, правая — Q = 6
Рисунок 12 левая половина — Q = 1, правая — Q = 13
Рисунок 13 левая половина —Q = 1, правая — Q = 31
Откуда взялись эти числа — 1 и 31? Ну, с «1» все понятно. Поскольку, на ноль делить нельзя, то 1 — это наименьший возможный quantizer, кстати говоря, не выполняющий никакого квантования, поскольку от деления на единицу коэффициенты матрицы не меняются. Но вот почему максимальный quantizer равен 31?
Ответ хранится в исходных текстах кодека MPEG-2, а точнее — в функции квантования quant_intra(), находящейся в файле \src\mpeg2enc\quantize. c, ключевой фрагмент которой приведен ниже.
y = (y+d)/(2*mquant); /* (y+0.75*mquant) / (2*mquant) */
/* clip to syntax limits */
if (y > 255) if (mpeg1) y = 255; else if (y > 2047) y = 2047;
Листинг 6 quant_intra( \src\mpeg2enc\quantize. c
Немного подумаем. Максимальное значение индекса матрицы равно 255 (в MPEG-2 – 2047 или 7FFh). Минимальный коэффициент квантования в левом верхнем углу матрицы — 8. Тогда при quantizer >= 31 весь блок 8×8 _гарантированно_ обращается в ноль, т. е. теряется _вся_ информация, хотя, как уже говорилось выше, использование таких высоких Q бессмысленно, разве, что в экспериментальных целях, но не будем углубляться в теорию, а лучше вернемся обратно к практике.
Чем больше Q, тем выше степень сжимаемости видеоматериала, но и тем ниже его качество. Варьируя значение Q можно получить файл заданного размера, например, ужать DVD до размеров одного CD. Но часто бывает так, что при Q = 4 файл на диск никак не влезает, а при Q = 5 влезает с большим запасом.
Практически во всех кодеках, которые мне только доводилось видеть quantizer представляется дробным числом с несколькими знаками после запятой (см. рис. 14).
Рисунок 14 задание дробного quantizer’а в настойках XviD’a
Непосвященному в тонкости кодирования это кажется вполне нормальным, но после разбора приведенных выше фрагментов исходных текстов кодеков MPEG-2 и XviD возникает резонный вопрос: как же quantizer может быть дробным, если он по жизни целый?! Дробных quantizer не бывает. И ведь правда — не бывает. Просто не встречается в живой природе. Выбор нецелого quantizer’а приводит к тому, что часть фреймов кодируются с одним Q, а часть — с другим (см. рис. 15). Усредненное значение и даст нужное нам (псевдодробное) значение Q.
Рисунок 15 результат использования дробного quantizer’а — различные фреймы сжимаются с различным Q, и все вместе они дают усреднение (по горизонтали откладывается Q, по вертикали — количество фреймов, сжатых с данным Q, типы фреймов [I/P/B] мы рассмотрим в следующий раз)
Психофизическая модель, используемая кодеками, отталкивается от того факта, что при быстром мелькании качественных (т. е. детализированных) и некачественных (т. е. с потерей деталей) кадров, человеческий глаз, а точнее мозг, улавливает детали и игнорирует размытость, в результате чего при чередовании кадров с Q и Q+1, субъективное качество приближается к Q.
А вот это для кого как! Лично у меня субъективное качество в первую очередь обуславливается наименее качественными кадрами, вплотную приближаясь к Q+1 и даже становясь хуже его! Чередование Q и Q+1 создает некоторое, трудное передаваемое словами, ощущения «дрожания» изображения и фильм сжатый с Q+1 субъективно (опять-таки субъективно!) воспринимается более приятно, чем с Q/Q+1. Но это — сугубо индивидуальные ощущения. Тем не менее, они подтверждаются большим количеством моих знакомых. К тому же тут еще вот какое обстоятельство прослеживается: при просмотре фильма с потерянными деталями (о существовании которых мы даже не подозреваем), субъективное качество остается вполне приемлемым даже при завышенном quantizer’е, но… стоит только глазу показать несколько кадров, где эти детали сохранены, как он моментально перестраивается и меняет оценку с «приемлемой» до «неудовлетворительной». Это можно сравнить с тем, что газетный лист на кажется белым до тех пор пока рядом с ним не окажется кусок мелованной бумаги.
Отсюда вывод: выбор целого значения quantizer’а обеспечит лучшее качество изображения, чем дробное. А как же в этом случае «подгонять» сжатый файл под требуемый размер? Целочисленный quantizer — слишком уж грубое средство… Действительно грубое, ведь он квантует сигнал, уже подвергшийся квантованию!
Редактирование матрицы квантования — это, конечно, высший пилотаж, требующий опыта и глубоких теоретических познаний, иначе качество можно только ухудшить, но правильно составленная матрица квантования позволяет ужимать файл до любого (разумного) размера с максимальным качеством и с минимальным потерей деталей.
Кстати говоря, в XviD’е имеется экспериментальный «Modulated QM«, стремящийся выбрать наиболее адекватную матрицу квантования для данного Q. Увы, алгоритм его работы постоянно меняется. Сначала он использовал H.263 матрицы (обеспечивающие лучшее сжатие, но дающие более высокую размытость) для фреймов с Q = 4, что вызывало массу негативных откликов. Действительно, зачем _портить_ качество «мыльной» матрицей на низкий Q и зачем подчеркивать резкость потерянных деталей при высоких Q?! В следующий версиях стратегия модулятора изменилась на прямо противоположную и теперь он стал выбирать MPEG-2 матрицы для фреймов с Q = 4, что обеспечивает лучше качество при большей степени сжатия (примечание: quantizer выбирается для каждого 8×8 блока индивидуально, хотя в подавляющем большинстве случаев весь блок кодируется с одним Q).
Подробнее о матрицах квантования мы поговорим в следующей статье, а пока вернемся с заоблачных небес на грешную землю, на которой творятся такие дела, что даже язык не поворачивается, чтобы их описать… в двухпроходном режиме сжатия (самом популярном на данный момент) кодек не позволяет задавать quantizer, требуя от нас указать средний битрейт (average bitrate) или же сразу желаемый размер файла.
Битрейт — это просто количество битов в секунду. Зная размер (в битах) и частоту (в fps) кадров, не составит труда рассчитать размер конечного файла, равно как и наоборот — размер файла однозначно обуславливает его битрейт. Величина самого битрейта, естественно, зависит от степени сжимаемости видеоматериала, и поскольку кодек не пророк он сжимает исходный видеоматериал за два прохода. В первом проходе никакого сжатия не выполняется, а лишь оценивается степень сжимаемости каждого фрейма, затем на основе полученной информации вычисляется необходимый quantizer, с которым видеоматериал реально сжимается во втором проходе.
Для достижения максимального качества, кодек стремится отдать больше битов тем сценам, которые сильнее всего в них нуждаются, отобрав их у остальных. Алгоритмы перераспределения битов по фильму непрерывно совершенствуются, но… до сих пор находятся в зачаточном состоянии. Наиболее типичная ошибка — выделив некоторым сценам низкий Q (соответствующий, как мы помним, высокому качеству), кодек вынужден сжимать остальные сцены с высоким Q (соответствующему низкому качеству).
Пример такого поведения продемонстрирован на рис 16. Из-за того, что кодек выделил некоторым сценам Q >> врезка лучше чем DVD
Quantizer равный 3 обладает одним очень интересным свойством — убирая наименее значимые детали он действует как отличный «шумодав», что весьма актуально для очистки «зашумленных» DVD (а таких среди них — большинство). Ниже приведены два кадра. Один — с оригинального DVD, другой после сжатия XviD’ом с Q = 3 и H.263 матрицей.
Рисунок 18 кадр с оригинального DVD (обратите внимание на шум)
Рисунок 19 тот же самый кадр после сжатия (куда подевался шум?!)