VP7.
Кодек VP7 весьма древний, однако его можно отнести к 3+ поколению кодеков. К первому поколению можно отнести кодеки с по кадровым сжатием типа MJPEG, ко второму относятся все кодеки использующие межкадровое сжатие (p-кадры) — из наиболее известных это VP3 (он же многострадальный и все ни как не допиленный theora), H.263/H.263+, к третьему можно отнести MPEG-4 (XviD и DivX), VP6 (VP6F жмет примерно на уровне MPEG-4, однако к сожалению в интернете используется слабо), а к 3+ относится H.264.
VP7 за место b-кадров использует золотые кадры, поэтому утверждения сторонников MPEG/H.xxx, что VP7 дескать не может соревноваться с H.264 потому что у него нет b-кадров безграмотны. Недостатки VP7 совершенно в другом. VP7 проигрывает H.264 в силе кадрового сжатия, межкадрового сжатия и компенсации движения. Компенсируются эти недостатки особенностью работы золотых кадров. Кодек выставляет золотой кадр, после чего идут промежуточные кадры, особенность которых в том что они не затрагивают участки которые не обновились в ходе кодирования, это значит что эти участки будут максимального качества. Участки которые обновились кодируются с минимально необходимым качеством, после чего через максимум 12 кадров кодек снова выставляет золотой кадр. Этот золотой кадр полностью обновляет картинку от артефактов промежуточных кадров. Выигрыш тут в том что неподвижный фон практически не кодируется и при этом будет всегда с максимальным качеством, а движущиеся объекты кодируются с минимальным качеством на этом кодек очень сильно экономит.
При обычном кодировании VP7 действительно уступает H.264, однако у VP7 есть один козырь — это режим no ajust quantizer. Снятие галочки с ajust quantizer переводит кодек в режим кодирования с промежуточными кадрами с постоянным квантайзером. Достоинство этого метода в том что нет перерасхода битрейда на излишнее качество промежуточных кадров. Если кодек в обычном режиме вынужден выставлять квантайзер на промежуточный кадр исходя из сохранения качества по объективной (объективная не потому что она правильная, а потому что она не зависит от человека) метрике, то в этом случае кодек выставляет только заданный квантайзер. Кодировать следует в однопроходном режиме с ограничением по битрейду. Например для видео 720х576 следует выставить битрейд 175кбит/сек и нижний квантайзер выставить в 45.
Сравнение качества VP7 против x264 (vfw 2146kMod --level 5.1 --pass 2 --bframes 7 --ref 3 --psy-rd 1.00:0 --merange 16 --me umh --subme 9), кодирование без титров.
VP7 best, 125кбит/сек, no ajust quantizer, q=56. Битрейд видео 252кбит/сек.
x264 252 кбит/сек
Не трудно заметить, что x264 в хлам слил. При кодировании например Гарри Поттер и принц полукровка x264 настолько сливает что может продемонстрировать разве что квадратики. Единственное в чем тут выигрывает x264 так это в скорости кодирования.
VP7 good 5, 125кбит/сек, no ajust quantizer, q=56. Битрейд видео 270 кбит/сек.
x264 270 кбит/сек
За счет более слабых настроек VP7 и большего битрейда x264 сокращает разрыв.
Разумеется так выглядят не все сцены, однако видно что масса деталей в движении даются x264 с большим трудом. Собственно движение так выглядит потому что кодек экономит битрейд для статичных сцен.
Здесь например на двухъядерном процессоре выигрыш в скорости будет уже у VP7 кодирование VP7 выполняет быстрее x264 (3ч 35мин против 4ч 34 мин), кроме того x264 затрачивает время еще на первый проход (от 1 до 6,5 часов в зависимости от настроек).
VP8.
VP8vfw-mod 0.9.7 best. Битрейд видео 252кбит/сек.
VP8 чем то похож по поведению на x264 — хорошо видны крупные детали на заднем плане и заглажены мелкие в движении, VP7 же оставляет детали с резкими границами и заглаживает все остальное.
VP8-mod 0.9.7 best --arnr-maxframes=15 --arnr-strength=6. Битрейд видео 252кбит/сек.
VP8-mod 0.9.7 best --arnr-maxframes=15 --arnr-strength=3. Битрейд видео 252кбит/сек.
VP8-mod 0.9.7 best --arnr-maxframes=5 --arnr-strength=3. Битрейд видео 252кбит/сек.
В целом --arnr-maxframes=15 --arnr-strength=3 лучше чем --arnr-maxframes=15 --arnr-strength=6 и немного лучше чем --arnr-maxframes=5 —arnr-strength=3
VP8vfw-mod 0.9.7 best. Битрейд видео 504кбит/сек.
Результат потрясает. Включение ar эквивалентно примерно удвоению битрейда.
Для сравнения x264 315 кбит/сек --bframes 0
Из-за артефактности оценить какой выигрыш в битрейде дают b-кадры довольно сложно, однако по данной сцене это примерно 1,25 раза по битрейду.
Надо отметить особенность работы ar кадров — они, по некоторым данным, в отличие от b-кадров не заменяют p-кадры, а дополняют промежуточные.
Здесь хотелось бы заметить что перед выходом VP8 на него из стана разработчиков x264 было вылито море г. Используя впопыхах доводимую к конференции гугла версию 0.9.0 (которая что то там мутно кодировала, демонстрируя скорей саму работоспособность чем эффективность) было сделано тенденциозное заключение, что VP8 чуть лучше MPEG-4. Стояла ли за этим черным пиаром MPEG-LA до сих пор не ясно, однако все было сделано грамотно, по лучшим каноном грязной борьбы: кодек был обосран полностью, при этом потрясалось референсным энкодером с криками - вот видите! При этом то что это можно сказать был демонстратор ни кого не волновало. Так же грамотно было сделано и то что кричал с одной стороны один из разработчиков x264 (т.е. авторитетный товарисч) с другой стороны он как бы был сам по себе и вроде как мнение всего сообщества x264 не выражал. Однако дождаться громогласного опровержения в новостях от самого сообщества так и не удалось, поэтому будем считать что товарисч все таки выражал мнение всего сообщества, которое сидело тихо в сторонке и наслаждалась представлением.
Немного о качестве.
Качество определяется тремя составляющими — это артефакты, детализация и градиенты. Основная проблема VP8 не в артефактах или детализации, а градиентах, у x264 на низких битрейдах артефакты, но с увеличением битрейда количество артефактов уменьшается, а детализация с градиентами улучшается — при увеличении битрейда у VP8 плавность градиентов растет слабо и если в x264 сборках старше 1000 градиенты подтянули (сколько народ вопил на форумах, но подтянули только в преддверии выхода VP8), то VP8 это только предстоит. Собственно VP8 вроде как поддерживает поблочный адаптивный деблокинг, поэтому лечится это довольно просто.
Что касается VP8, то у этого кодека значительно повышенна эффективность кадрового сжатия (примерно до уровня x264), межкадровое сжатие и компенсация движения (примерно в 2 раза по сравнению с VP7), добавлен аналог b-кадров (ar-кадры работают только в два прохода и не совместимы с контейнером AVI, точней впихнуть то ar кадры в контейнер AVI можно, но на каждый крошечный ar-кадр AVI выделит место, что вызовет дикое увеличение размеров контейнера). Но есть серьезные проблемы: с ростом разрешения эффективность VP8 падает относительно VP7, VP8 хуже переносит кодирование H.264 видео (VP7 то же не страдает любовью к H.264, но меньше), в VP8 нет переменного квантайзера для каждого блока в кадре, нет компенсации на яркость блока, нет -bias для золотых кадров, нет ускоренного первого прохода (первых проход делается для видео например 320х240, а потом пересчитывается в нормальное разрешение по битрейду — ускорение от такой функции для HD видео огромно, а реализация проста как три копейки). На мой взгляд VP8 выставляет золотые кадры избыточно часто (особенно вредно влияет шум), при значительно улучшенном кодировании движения, можно было просто удвоить по сравнению с VP7 количество промежуточных кадров до 24 или хотя бы в настройках сделать регулировку золотых кадров и жесткость их выставления.
Отсутствие подвижек с новыми настройками и режимами кодирования и есть самая главная проблема VP8, точней самая главная проблема в тех кто занимается улучшением VP8. Эти опенсорсные идиоты не понимают что надо не только заниматься поиском ошибок в коде и поиском более быстрых и эффективных алгоритмов, но заниматься серьезным тюнингом кодека. Хотя бы для начала вернуть режим no ajust quantizer, потом можно попытаться добавить двунаправленные золотые кадры - это поднимет сжатие еще на 20-30%, за счет в двое более редкого выставления.
Анекдот в тему: почему линукс еще не захватил мир? Потому что линуксоидов мало.
Программисты как и журналисты не понимают того о чем пишут.
Основная проблема таких крупных опенсорсных проектов в том что продвинутые программисты тешащие свое ЧСВ мало задумываются над тем как этот код будет работать в реальных условиях, а простые пользователи не имеющие веса в проекте не могут достучатся и сказать что реализация хреновая. В результате создается порочный круг когда сообщество тратит титанические усилия на улучшения продукта, но эти самые улучшения не заметны для пользователей.
Ситуация напоминает борьбу wma против mp3. МС то же носилась с wma, прикручивала к нему DRM, не сделала нормального энкодора в собственном плеере WMP, сторонние энкодеры были большей частью платные - чему удивляться если wma да же будучи качественнее mp3 используется редко.
гугл конечно не дошел до такого маразма как судебные иски против разработчиков сторонних декодоров и код открыл, однако надо учитывать что сторонников VP8 среди пользователей крайне мало, особенно при активном противодействии сторонников x264. На сегодняшний день в относительно приличном состоянии находится только рефернсный энкодер, ни нормального консольного пользовательского энкодера (makewebm застрял на версии 9.12 с поддержкой VP8 0.9.5 по моему, уступает в качестве кодирования референсному и поддержка AVS у него отвалилась то ли в версии 0.9.7 то ли еще в версии 0.9.5) ни нормальной vfw версии кодека (то что есть от optimasc невыразимо убогий обрубок да же по сравнению с аскетическими настройками VP7). Нет кодеков - нет пользователей - нет пользователей - нет массового распростронения. Ну запихнул гугл в новые планшеты аппаратный декодер, а все остальное? Телевизоры, проигрыватели, телефоны. Зачем прошибать лбом стену и давить на производителей чипов, когда можно просто выложить нормальные енкодеры.
Выводы:
При грамотной настройке VP7 может обойти x264.
Эффективность VP8 зависит от исходного материала и разрешения, однако преимущество VP8 над VP7 может доходить до 1,5-2х раз.
Качество и скорость кодирования VP8 при минимальных затратах можно еще существенно поднять, а не как сейчас когда пыхтя 5 мес что то там улучшили на 5% - осталось что бы до разработчиков дошло. Но надежд я прямо скажу не питаю ни каких.
Эффективность кодирования VP7 (в порядке падения эффективности)
Конференции (мало движения)
Кино
Рисованная анимация
3Д анимация (упрощенная)
Рендеренная анимация.
Эффективность кодирования VP8 (в порядке падения эффективности)
Конференции (мало движения)
Рисованная анимация
3Д анимация (упрощенная)
Кино
Рендеренная анимация.