В Интернете достаточно часто встречаются сравнения кодеков... Данные сопоставления, как правило, длинные и не очень, эмоциональные и не очень, явно пристрастные и не явно. Но большинство из авторов подобных сравнений просто приводят кадры из двух фильмов и, словно сговорившись, игнорируют следующие вещи:
- Любой кодек дает разное качество по кадрам одного и того же фильма.
- Разные кодеки "затачиваются" под разные типы фильмов.
- Качество сжатия конкретного фильма может сильно зависеть от параметров кодирования.
Подробнее про каждый из пунктов:
Любой кодек дает разное качество по кадрам одного и того же фильма
Это связано со многими факторами. Во-первых, в кодеке работает такой механизм как управление битрейтом, которое дает колебания качества даже у хороших кодеков. Во-вторых, сам пользователь выбирает разные стратегии битрейта, и в случае выбора CBR (или постоянный битрейт) на медленных сценах качество будет высоким, а на быстрых - низким. В-третьих, у кодеков есть т.н. ключевые кадры, качество которых обычно изменяется отдельно, и отличается от качества остальных кадров. В-четвертых, на качество влияет префильтрация (которая есть у всех современных кодеков)... В-пятых... В-шестых... В-седьмых... :)
Это означает, что на любом достаточно длинном фильме (а средний фильм это 150000-200000 кадров) можно подобрать как достаточно хорошие, так и достаточно плохие кадры. Особенно если использовалось однопроходное CBR сжатие на достаточно динамичном фильме.
Т.е., имея один длинный фильм, кодеки А и Б (которые примерно равны по качеству), и несложные средства автоматизации сравнения качества (или много религиозной преданности своему кодеку :), можно легко и с примерами доказать, и что А заметно лучше Б ("посмотрите на эти кадры!"), и что Б заметно лучше А ("посмотрите на эти (другие) кадры!"). :) Что "с успехом" и проделывается достаточно массово. Как в пресс-релизах (святое дело!), так и на сайтах посвященных обработке видео.
 |
На графике приведено качество в метрике PSNR (чем выше, тем лучше качество). Если привести в качестве сравнения кадры "с пиками", то VP будет лучше DivX, иначе - наоборот. |
Разные кодеки "затачиваются" под разные типы фильмов
Многие знают, что в свое время существовали DivX 3.11 LowMotion & DivX 3.11 FastMotion. Притом, что они проигрывали фильмы одинаково, их внутренние параметры были "заточены" у одного на слабое движение, а у второго - на сильное. В результате они с заметно разным качеством сжимали фильмы. Заметьте еще раз - ФОРМАТ, в который они жали, был один! А сжатие в него осуществлялось по-разному! В результате при одинаковом размере файлов их качество получалось разным. Аналогичная "заточенность" под "свой" тип данных характерна абсолютно для всех кодеков. Кто-то лучше жмет высокие битрейты. Кто-то - наоборот низкие. Кто-то затачивается под сильное движение, кто-то под слабое. И даже так - кто-то затачивается под мультфильмы, а кто-то под реальное видео. Кто-то под "шумные" фильмы, кто-то под "чистые" и т.д. Имея исходные тексты кодека, можно, не меняя его формат, т.е. не изменяя декомпрессор, заточить его практически под любой тип фильмов. И этим с успехом пользуются на практике. Это означает, что имея кодеки А и Б (примерно равного качества), можно легко подобрать фильмы, на которых А будет заметно лучше Б, и на которых Б будет заметно лучше А. При этом забавно, что, формально, фильм может быть и один, просто DVD-копия и "тряпичная" пиратская копия, снятая с экрана в кинотеатре, могут дать заметно разный результат на двух кодеках. Т.е. фильм будет "один", но "лучшие" (в мире) кодеки будут различаться. :)
 |  |
Исходный | Divx 3.1 |
 |
Межкадровая разница показывает, насколько сильно отличаются кадры. Черный цвет свидетельствует о том, что разницы нет; синий, зеленый и красный по возрастающей показывают различия, имеющиеся в изображениях. Если привести эти кадры в качестве сравнения, то Divx 3.1 будет лучше Divx 5.1. |
Divx 5.1 |
Качество сжатия конкретного фильма может сильно зависеть от параметров кодирования
Большинство об этом не задумывается (должны же были авторы кодеков ВСЕ предусмотреть! :), но у кодеков, как правило, есть достаточно много параметров, позволяющих при том же размере файла заметно (а то и кардинально) изменить качество. В первую очередь это параметры стратегии битрейта, особенно режимы "quality - based" & "bitrate - based". Потом параметры префильтрации. В частности, deinterlacing, ибо встречаются фильмы, которые сжимали в чересстрочной развертке в MPEG-4 (и, видимо, удивлялись слабому качеству :), denoising (подавление шумов), deflicking (подавление мерцания) и т.д. Существуют параметры управления частотой ключевых кадров, маской использования B-frames, управление зависимости префильтра от фильма и т.д. Это означает, что имея кодеки А и Б (примерно равного качества), можно легко установить один кодек в режим Maximum Perfomance (все ручки сдвинуть до предела в сторону скорости сжатия), а другой в режим 2-pass Maximum Quality (все ручки до предела в сторону максимального качества), можно получить 2 фильма одного размера, но существенно разного качества. Можно даже эти фильмы на сайт выложить и предложить убедиться! :) Что с успехом многие компании и делают. При этом душераздирающие подробности того, что один кодек работал в 10 раз меньше другого, предпочитают оставлять за кадром. Зачем людям (тем более журналистам) знать лишнее? :) При этом исходный несжатый файл никто не кладет, обосновывая это его большим размером. А почему не кладут параметры сжатия - вы теперь знаете.
В этом кодеке из-за ошибки в rate control на одном из битрейтов резко падает качество (да, ошибки в кодеках тоже бывают :). Для этого кодека данный битрейт будет весьма неудачным параметром.
На самом деле существуют и другие, более тонкие способы получать как реальное преимущество, так и "преимущество". (Например, не существует методик, определяющих, насколько пропуск кадров критичен для восприятия и т.д.) Но эти - основные. Итак! Если хорошо вникнуть в методы "надувательства" при сравнении 2 кодеков, то становится понятно, что для корректного сравнения необходимо достаточно глобальное тестирование. Т.е., как минимум, нужно сравнивать разные по характеру фильмы с разными битрейтами, причем с использованием интегральных (средних) характеристик качества по всему фильму. Именно для этого и было проведено настоящее сравнение. Всего было протестировано 32 доступных кодека. В качестве тестовых были выбраны 9 последовательностей разного характера. Для того, чтобы проверить все кодеки на разных битрейтах, пришлось прогнать их более 2400 раз с разными параметрами (и то фактически тестировались только параметры по умолчанию)! Суммарное время счета составило больше 11 суток, причем реальное время было больше, поскольку из-за ошибок (в т.ч. ошибок в кодеках) часть последовательностей приходилось пересчитывать.Часть 1: Методология тестирования
Метрика PSNR
Описание метрики
В рамках данного тестирования критерием оценки качества сжатия служит метрика PSNR (peak signal to noise ratio/пиковое отношение сигнала к шуму, измеряется в дБ). Использование именно этой метрики обусловлено ее популярностью, ее используют во многих научных статьях и сравнениях в качестве меры потерь качества. Как и все существующие метрики, она не идеальна и имеет свои достоинства и недостатки. Для понимания приведенных ниже цифр, необходимо знать лишь то, что значение метрики тем больше, чем больше разница между сравниваемыми изображениями. Программу для PSNR-анализа можно загрузить здесь.
Смысл графиков PSNR/Frame size
На графике изображена зависимость показателя метрики от среднего размера кадра. Каждая ветвь соответствует определенному кодеку. Ветви построены на опорных точках, каждая из которых соответствует конкретному битрейту. Очевидно, на каждой ветви находится по десять точек (каждая последовательность сжимается на 10 настройках битрейта). Бывает, что кодек не удерживает битрейт и с разными настройками битрейта сжимает одинаково. В таких случаях, очевидно, на ветви кодека расположено менее десяти опорных точек. Для сравнения кодеков на этих графиках следует обращать внимание на то, как высоко расположены ветви кодеков. Чем выше находится ветвь – тем выше качество последовательности, сжатой данным кодеком. На приведенном рисунке видно, что на низком битрейте качество последовательности, сжатой кодеком Morgan Multimedia JPEG 2000, выше, чем у последовательности другого кодека. Однако на высоком битрейте Visicron J сжал последовательность с меньшими потерями качества по сравнению с кодеком MM JPEG2000.
Смысл графиков PSNR/Frame size (with drop frames)
Drop-фреймами называются кадры, которые кодек пропускает; на их место в видеопоследовательности подставляется последний сжатый кадр. Drop-фреймы являются средством понижения битрейта сжимаемой последовательности. Однако при большом количестве drop-фреймов в последовательности наблюдается эффект «слайд-шоу» - вместо динамической сцены кодируется лишь один кадр, который и будет показан в нужный интервал времени при проигрывании сжатого видео. Графики этого вида позволяют оценить количество реальных кадров в видеопоследовательности.
При сравнении кодеков на данных графиках следует обращать внимание на то, как близко к оси ординат расположены ветви на графике, отражающем использование drop-фреймов. Чем левее находится ветвь кодека, тем меньшие средние размеры кадров характерны для соответствующей сжатой последовательности. И следовательно, тем больше FPS на выходе. Таким образом, кодеки, чьи ветви расположены левее, дают на выходе больше FPS при том же качестве.
Методика тестирования
Последовательность действий
В тестировании участвует девять фильмов (см. ниже). Каждый фильм сжимается десять раз с разными битрейтами (кбит/с.): 100, 225, 340, 460, 700, 938, 1140, 1340, 1840, 2340. Для компрессии фильмов используется программа VirtualDub 1.4.13. Таким образом, для каждого кодека генерируется 90 фильмов. Затем для каждого фильма вычисляется метрика PSNR и количество drop-фреймов. Причем указанная метрика вычисляется как для каждого кадра, так и для всей последовательности – среднее значение по всем кадрам. Далее для построения графика используются соответствующие числа, в зависимости от типа графика.
Правила тестирования
- При возникновении ошибок на этапе сжатия процесс компрессии повторяется.
- При тестирования кодека, на компьютере не установлены другие кодеки (помимо кодеков, установленных ОС). Таким образом, и компрессия, и декомпрессия гарантированно используют нужную dll.
- Для визуального сравнения кодеков кадры выбираются так, чтобы последний key-frame был не ближе 20 кадров к нему, если это возможно.
- Для сравнения качества используются последовательности, сжатые с одинаковыми битрейтами, если такие возможно подобрать. Если нет – выбираются последовательности с близкими битрейтами. Это правило соблюдается в разделе покадрового и визуального сравнения кодеков.
- В разделе 2 для некоторых последовательностей не приведено соответствующей графики – пропущенные диаграммы не содержат принципиальной информации о работе кодека, не имеющейся на приведенных рисунках.
- В части «Методология» для некоторых кодеков даны кадры из сжатых последовательностей с указанием битрейта. Указанный битрейт не является реальным – это битрейт, заданный в настройках кодека при сжатии. Поэтому некорректно сравнивать рисунки для разных кодеков, т.к. очень вероятно, что кодек повышает указанный в настройках битрейт.
- Описанные в данной статье особенности работы кодеков справедливы для настроек по умолчанию. Т.е. при тестировании настройки кодека не изменяются (за исключением настройки битрейта).
- Все графики в разделе «Методология» построены для последовательности bus.
- Нарушение каждого из описанных правил сопровождается явной оговоркой.
Кодеки с потерями
CODEC | ПРОИЗВОДИТЕЛЬ | ВЕРСИЯ |
AngelPotion | AngelPotion | 1.0 |
MPEG4 | Microsoft | 1.0, 2.0, 3.0 |
I.263 | Intel | |
Indeo Video | Intel | R3.2 |
MPEG4 | Kristal Studio | Pack 4.3.3 |
Indeo Video | Ligos | 3.2 |
Indeo Video | Ligos | 4.5 |
Indeo Video | Ligos | 5.11 |
VP | On2 | 3.2.0.1 |
Motion Wavelets | Aware | 1.7 |
JPEG2000 | Morgan Multimedia | 1.0 |
JPEG | Morgan Multimedia | 2.0 |
Cinepak | Radius | 1.1 |
MPEG4 Video | Microsoft | 1.0, 2.0 |
Xvid | XVID | 1.01 |
Divx | DivXNetworks | 3.1 fast motion |
Divx | DivXNetworks | 3.1 low motion |
Divx | DivXNetworks | 4.02 |
Divx | DivXNetworks | 5.02 |
VSS | VANGUARD Software Solutions | 1.2 |
D4 | 3IVX | 4.0.3 |
Visicron Dynamic | Visicron Division | 1.0.3 |
Visicron Static | Visicron Division | 1.0.3 |
Visicron J mode | Visicron Division | 1.0.3 |
Кодеки без потерь
CODEC | ПРОИЗВОДИТЕЛЬ | ВЕРСИЯ |
| JPEG | LEAD | 1.0 |
| GZIP | CamStudio | 1.0 |
| PICVideo | Pegasus | --- |
| AVIzlib | Kenji Oshima | 2.2.3 |
| MSU lab beta | MSU Graphics & Media Lab | 0.1.0 |
| HuffYuv | Ben Rudiak-Gould | 2.1.1 |
Последовательности
Фильм | Число кадров | Размер исходного фильма | Разрешение и цветовое пространство |
bankomatdi | 376 | 120286 K | 704 x 352 ( RGB ) |
battle | 1599 | 351268 K | 704 x 288 ( RGB ) |
bbc 3 di | 374 | 263400 K | 704 x 576 ( RGB ) |
bus | 150 | 20761 K | 352 x 288 ( RGB ) |
foreman | 300 | 38481 K | 352 x 288 ( RGB ) |
helicopterdi | 113 | 41112 K | 704 x 352 ( RGB ) |
NDDP 7 di | 188 | 90089 K | 720 x 576 ( RGB ) |
susidi | 374 | 235618 K | 704 x 576 ( RGB ) |
tensdi | 373 | 323308 K | 704 x 576 ( RGB ) |
Графики Y-PSNR - Frame Size
На этих графиках хорошо видна динамика зависимости качества сжатого фильма от его размера. Координатами опорных точек диаграммы являются средние по фильму значения метрики и размера кадра. Таким образом, каждая ветвь имеет по десять точек, соответствующих разным битрейтам.
 Sequence SUSIdi |
Выводы
- На данной последовательности fast motion отработал намного лучше low motion: при сравнительно одинаковой метрике, размер кадра у него в четыре раза меньше, чем у low motion.
- Для Divx 5.02 и Xvid качество почти не меняется при увеличении размера кадра начиная с 5кб.
- На различных битрейтах качество последовательностей Divx 4.02 примерно одинаковое. При шестикратной разнице в размере кадра качество последовательностей на крайних точках ветви отличается на 2дб – минимальная визуально заметная разница качества.
В полной версии сравнения представлены другие типы графиков для различных последовательностей и видеокодеков: стратегия drop-фреймов, U-PSNR , Y-difference и bitrate-handle. Часть 3: Покадровое сравнение видеокодеков
Divx 4.02 и MorganMultimedia JPEG2000 (battle – 1340 кбит/c.)
 |
 |
 |
 |
 |
 |
 |
Выводы
- JPEG2000 идеально удерживает битрейт – см.первый рисунок.
- JPEG2000 лучше сохраняет метрику на динамических сценах, хотя на статических он сильно уступает Divx 4.02.
- U-компонента лучше сохранена JPEG2000.
- Показатели средней метрики отличаются примерно на 0.5 dB. Т.е. при заметном выигрыше в размере, JPEG2000 незначительно лучше сохраняет качество.
- Несмотря на постоянный размер кадра, показатель метрики JPEG2000 сильно изменяется. Особенно хорошо скачки метрики видны на втором графике – их амплитуда достигает 10 dB. Такие перепады метрики, очевидно, имеют негативное влияние на качество сжатой последовательности. Divx 4.02 удерживает метрику намного стабильнее.
Tensdi 1264 кбит/с – 205 кадр
В названиях рисунков в скобках указано превышение битрейта кодеком.
Microsoft v3, MM JPEG2000, MM JPEG v2, Xvid 1.01, Visicron J-mode
|
|
Original | MM JPEG2000 (+7%) |
|
|
JPEG v2 (+138%) | Microsoft v3 (+6%) |
 |  |
Xvid 1.01 | Visicron J-mode (+8%) |
 | |
MM JPEG2000 (+7%) | |
|
|
JPEG v2 (+138%) | Microsoft v3 (+6%) |
 |  |
Xvid 1.01 | Visicron J-mode (+8%) |
Выводы
- Качество кадров для MPEG кодеков заметно выше, чем у JPEG кодеков.
- Последовательности JPEG v2 и MM JPEG2000 имеют неприемлемое качество, при этом битрейт для JPEG v2 превышен более чем в два раза.
- Из JPEG-кодеков заметно превосходство Visicron J.
- Microsoft v3 и Xvid 2.1 сохранили качество примерно на одном уровне.
Как было сказано выше, данное сравнение является сильно сокращенным вариантом масштабного тестирования видео кодеков. Полный вариант этого тестирования имеет объем 190 pdf-страниц, содержит сравнения всех указанных в начале статьи видео кодеков, множество графиков и рисунков, не приведенных в данной работе. Полная версия тестирования доступна по адресу http://www.compression.ru/video/codec_comparison/.
Лаборатория компьютерной графики ВМиК МГУ
Руководитель: Дмитрий Ватолин
Замеры, обработка: Сергей Гришин
Перевод: Дарья Калинкина, Станислав Солдатов
Подготовка: Николай Труничкин
