Сравнение кодеков VP8, x264 и libtheora

    Месяц назад Google открыл спецификации формата VP8, который должен стать основным форматом видео в вебе. VP8 свободен от патентов в отличие от H.264, при этом по заявлениям разработчиков должен превзойти конкурента по качеству. На сайте компании On2 уже давно висит многообещающий график. Когда кодек появился в открытом доступе, мне стало интересно, выполнили ли они обещание.

    Те сравнения, которые появились в сети после релиза, были достаточно поверхностны. Jason Garrett-Glaser, разработчик x264, также готовит своё субъективное сравнение большого количества кодеков, где будет представлен и VP8, но он его ещё пока не опубликовал.

    Картинка для привлечения внимания

    Так я взялся проделать своё небольшое объективное сравнение.

    Готовить сравнение я начал ещё на той же неделе, на которой был релиз VP8, поэтому все кодеры примерно месячной давности.

    Участники сравнения


    VP8


    Референсный кодер, версия от 18 мая 2010 года, собирал в VS2008 в конфигурации Release.

    x264


    Представителем семейства H.264 будет кодек x264 версии r1602. Думаю, многие о нём уже слышали: он бесплатен, широко доступен и является одним из передовых. Поскольку VP8 заявлен как веб-оптимизированный кодек, то разумно сравнивать его с Baseline-профайлом x264. Но я также измерил данные по High-профайлу x264, чтобы составить полную картину.
    Основные отличия baseline-профайла заключаются в отсутствии b-кадров и арифметического кодирования. B-кадров у VP8 тоже нет, а вот арифметическое кодирование есть. Более подробно про профайлы H.264 можно посмотреть в Википедии.

    libtheora


    Интересно посмотреть, сколько мы наиграли относительно другого полностью открытого кодека. Так что в сравнении участвует новый билд Ogg Theora. Сейчас идёт разработка новой версии кодера, которую назвали Ptalarbvorm, и в сети как раз появилась демо. Билд версии ptalarbvorm-svn17230. MediaInfo его распознаёт как libtheora 1.1+ 20100314 (Ptalarbvorm).

    Для декодирования результатов Теоры и x264 я использовал AviSynth-плагин FFMpegSource2 версии 2-2.13. Для декодирования VP8 — референсный декодер.

    Пресеты кодеков


    У всех кодеков установлен интервал между I-кадрами равный 250. Настройки выставлены под более гибкий rate control. Для x264 количество референсных кадров поставил три, так как больше не поддерживается конкурентами. VP8 настроен в соответствии с рекомендациями c сайта webmproject.org.

    x264 High Profile:
    --keyint 250 --bframes 4 --b-adapt 2 --b-pyramid normal --ref 3 --rc-lookahead 50 --no-psy --partitions all --8x8dct --direct auto --me umh --subme 8 --trellis 2 --no-fast-pskip

    x264 Baseline Profile:
    --keyint 250 --bframes 0 --ref 3 --rc-lookahead 50 --no-psy --partitions all --direct auto --me umh --subme 8 --trellis 2 --no-fast-pskip --no-cabac --profile baseline

    VP8:
    --good --end-usage=0 --undershoot-pct=100 -p 2 --kf-max-dist=250 --drop-frame=0 --resize-allowed=0 --static-thresh=0 --profile=0 --auto-alt-ref=1 --lag-in-frames=16

    libtheora:
    --soft-target --two-pass -k 250 -z 0

    Видеопоследовательности


    Для сравнения я взял четыре видеопоследовательности, две из них в SD и две в HD.

    Toys and calendar



    640x352, 250 кадров
    Плавное движение, много деталей и сложные текстуры. Это видео мне понравилось в предыдущем сравнении, решил использовать его и в этом.

    Big buck bunny



    704x480, 926 кадров
    Фрагмент мультфильма Big buck bunny, трёхмерная анимация. Это видео я чаще всего встречал на демках разных открытых кодеков и не мог пройти мимо =) Исходник анаморфный, то есть пропроции слегка искажены.

    Battle



    1280x544, 586 кадров
    Фрагмент из фильма Терминатор. Очень динамичное видео, много движения, частые смены сцен.

    Old town cross



    1280x720, 500 кадров
    Видео с плавным движением. Большое количество деталей, но есть равномерная область (небо). Также есть небольшая зернистость.

    Методика сравнения


    Вместо замера на одном битрейте, как в прошлый раз, сейчас я решил сделать несколько замеров на разных битрейтах. И данные по всем замерам можно представить на одном графике в виде ломаной. Диапазон изменения битрейта я подбирал за несколько проб, исходя из визуального качества результатов.
    Кодирование проводил в два прохода с заданным битрейтом. Битрейт, естественно, переменный. Quality-based режима у VP8 нет, если что.
    Для оценки качества использовал метрику SSIM. Как показывает практика, она ближе к результатам визуального сравнения, чем PSNR. Для измерения SSIM использовал MSU Video Quality Measurement Tool.
    Кстати, у x264 есть параметр --tune ssim, который позволяет слегка улучшить показатель SSIM, просаживая при этом PSNR. Не включил этот параметр, так как я изначально хотел считать обе метрики. Но не стал, потому что объём работы удваивается, а полезность малая — результаты обычно очень похожи.
    Отклонение битрейта в этот раз учтено за счёт того, что точки на график наносились в соответствии с реальным показанным битрейтом. На некоторых графиках можно заметить, что точки находятся не точно на отметке.

    Результаты


    VP8 оказался между двумя профайлами x264, а Теора сильно от них отстала. Чтобы можно было разглядеть на графиках разницу в результатах x264 и VP8, пришлось от Теоры оставить только два-три замера на самых высоких битрейтах.
    Скриншоты к результатам даю отдельными ссылками, так как куча картинок только замусорит статью. Да и рассматривать их, переключаясь между табами, всё равно удобнее.

    Toys and calendar



    Здесь результаты x264 и VP8 визуально отличаются незначительно. VP8 лучше сохранил текстуры, чем x264 Baseline Profile, а x264 High Profile это удалось ещё чуть лучше. У Теоры картинка сильно размыта.
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    Big buck bunny



    Здесь визуально VP8 оказался ненамного лучше, чем x264 BP. У них на разных сценах по-разному замылена картинка. По SSIM VP8 оказался всё-таки выше. x264 HP заметно лучше. Теора заметно хуже.

    Пример типичной ситуации:
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    Пример сцены, где хорошо заметен отрыв VP8 от x264 BP.
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    Ещё у VP8 бывают проблемы с распределением битрейта по видео (хотя и двухпроходное кодирование). Например вот, сама сцена статичная, только кролик двинулся, за что очень сильно пострадал. Тут даже Теора выглядит лучше. Такие штуки встречаются в порядке исключения, но встречаются.
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    Battle



    Несмотря на более высокие показатели SSIM у всех кодеков, результаты на этом видео визуально хуже, чем на других. В основном у VP8 картинка менее замыленная, чем у x264 BP.
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    И вот ещё пример, когда VP8 сильно испоганил сцену.
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    Old town cross



    На этом видео визуально отличия еле заметны. Везде смыта зернистость, замылена черепица на крышах. Основные отличия в том, насколько грубо/точно переданы мелкие детали. Ну и Теора всё размыла.
    Скриншоты: Исходник Theora VP8 x264 BP x264 HP

    Относительный битрейт


    Цифры и картинки — это интересно и занимательно. Но есть ещё чисто практический вопрос: соотношение размер/качество. Есть простой способ его примерно оценить: пересечь графики результатов горизонтальной линией, фиксирующей SSIM, и посмотреть битрейт в точках пересечения. Да, это только приблизительная оценка, но она достаточно информативна. Картину происходящего она отражает, а на других видео того же типа результаты всё равно будут слегка отличаться.
    В качестве уровня SSIM на каждом графике я взял самый высокий результат x264 BP. За 100% на графике относительного битрейта принял результат VP8.

    По графикам видно, что битрейт (и, как следствие, размер файла) у x264 BP больше, чем у VP8, на 12-39 процентов. При этом на «настоящем» видео со сменами сцен x264 BP проиграл меньше. Выигрыш x264 HP относительно VP8 составил от 16 до 33 процентов.
    Замечу ещё, что здесь счёт идёт на проценты, а не на разы, как было в случае с Теорой.

    Скорость кодирования


    Привожу время кодирования всех последовательностей, на которых проходило тестирование.

    x264 High Profile: 20 минут 12 секунд
    x264 Baseline Profile: 10 минут 21 секунда
    VP8: 83 минуты 59 секунд
    Theora: 21 минута 59 секунд

    Конфигурация: Intel Core2Duo T6670 2.2 GHz, 3 GB RAM

    Тут VP8 получил огромную фору. Я не стал его подгонять под остальные, так как это ещё альфа-версия. Правда, кодер уже был оптимизирован, в том числе и за счёт SIMD-инструкций.
    Отрыв можно было компенсировать за счёт увеличения у x264 параметров --ref, --bframes, --me-range и --subme. Тем самым слегка улучшить качество. Но я оставил те настройки, которыми обычно пользуюсь, из практических соображений. Заодно получил на будущее примерный ориентир для VP8 по времени.

    x264 работал в два потока, Theora умеет только в один, VP8 работал тоже в одном потоке, так как разработчики рекомендуют число потоков = (число ядер CPU – 1). Но даже при идеальной многопоточности VP8 получился бы в четыре раза медленнее x264 BP. Вы готовы ждать час вместо пятнадцати минут, или четыре дня вместо одного?

    Как достаточно корректно измерить скорость декодирования, я не знаю. По-хорошему, нужно тестировать несколько разных декодеров на нескольких аппаратных конфигурациях. В том числе и на мобильных устройствах. А это отдельная большая работа, для которой ещё и технические ресурсы нужны. Возможно такие замеры появятся после того, как VP8 получит более широкое распространение. А пока есть только данные разработчика x264, по которым VP8 заметно уступает. И его результатам я верю больше, чем обещаниям маркетологов On2 и Google.

    Мысли вслух


    Если рассматривать VP8 как кодек для веба, то он вполне удался. Качество результатов сравнимо с кодеками стандарта H.264, в плане лицензий и патентов всех устраивает, и благодаря Google он получит достаточно широкую поддержку. Youtube — отличная стартовая площадка. Chrome, Opera, Firefox — это приличная доля рынка браузеров. Плюс Adobe обещают к концу года добавить поддержку WebM в Flash, у которого инсталляционная база порядка 90%. И плюс ещё Chrome frame для пользователей IE. На мобильных устройствах поначалу тоже через Flash, потом будет и аппаратная поддержка. Непонятно, правда, чего ждать от Apple с их iPhone.

    По технической части из этого сравнения видны проблемы у VP8 с rate control'ом. Испорченные сцены — следствие неправильного распределения битов по всему видео. Несмотря на то, что видео кодировалось в два прохода. И нужно заметно уменьшить время кодирования. Понятно, что это только альфа, кодек будет дорабатываться.

    Насчёт патентной чистоты вопрос пока открыт. Видно будет через год-два, появятся ли претензии, и если появятся, то как они будут решены. И я не понимаю всеобщей паники вокруг royalty-free H.264 до 2016 года. Должны же MPEG-LA его продлить, зачем губить большую пользовательскую базу. Денег у компаний-разработчиков и так хватает — за счёт девайсов, которые они продают.

    Кстати, VP8 вряд ли подвинет H.264 где-либо, кроме веба. В других сферах свобода от патентов не является решающим преимуществом, так что пользователи торрентов и медиаиндустрия вряд ли будут что-то менять. Хотя на torrents.ru были чудаки, которые предлагали начать клепать DVD-рипы Теорой, так как они считали, что по качеству она превосходит H.264. Также производители разных устройств для записи видео (видеокамеры, фотоаппараты, телефоны и пр.) вряд ли будут заморачиваться с новым форматом и, соответственно, аппаратной поддержкой кодирования VP8. Цифровое ТВ тоже вряд ли перейдёт на VP8, а то ведь придётся всем менять телевизоры (или STB), а телекомпаниям в придачу оборудование для кодирования (тоже вопрос аппаратной поддержки).

    И хотя стандарт H.264 был принят в 2003 году, он продолжает развиваться. В 2007 и 2009 годах были приняты два расширения формата: Scalable Video Coding и Multiview Video Coding. Не уверен, что мы скоро увидим широкое использование первого, а вот второе вполне может в ближайшие годы пойти в массы, так как 3D-видео становится всё более распространённым. И здесь VP8 тоже оказывается в роли догоняющего.

    Выводы


    Формат VP8 вполне подходит для веба. Он намного лучше Ogg Theora и сравним с H.264 по параметру размер/качество. Вопросы о патентной чистоте и скорости декодирования остаются пока открытыми. Получит ли формат распространение — это вопрос скорее коммерческого и политического успеха, нежели технического.

    Материалы


    Выкладываю исходное видео и результаты кодирования.
    Результат VP8 у меня без контейнера, raw stream. Если кто-то правильно смуксит это в матрёшку и поделится с людьми, будет здорово.
    Результаты кодирования
    Исходное видео
    Share post

    Comments 106

      +1
      Вопрос к фэнсабберам. Они задают во многом тот формат, который будет популярен. Именно они продвинули mkv, именно они в своё время популяризовали h264, именно они могут похоронить его.
      • UFO just landed and posted this here
          +1
          Во внутрь AVI text stream вполне пакуется, кстати, тоже. Так же как несколько аудио-потоков.
            +2
            Только в стандарте AVI субтитров нет, к сожалению. И все, что есть — сторонние хаки.
              +5
              Да весь контейнер AVI — это один большой, морально устаревший и малофункциональный костыль. Там и вставка нескольких аудиопотоков тоже, можно сказать, через хаки делается. Давно пора его забыть и перейти повсеместно на Matroska, Ogg Media или MP4.
              • UFO just landed and posted this here
                0
                Э… «Стандарта» AVI не существует. В том смысле, что то, что было сделано (RIFF) описывает не то, что мы обычно видим внутри AVI. Например, RIFF описывает в CHUNK относительную длинну, а в AVI всё имеет абсолютное положение (могу врать по старости у кого что, но именно так). С PADDING'ом там тоже всё сильно запутано.

                А наличие потоков с всякой дрянью, кстати, вполне в формат riff укладывается.
                  0
                  Как это не существует? И VfW тоже нет в природе?

                  И как вы собирались упаковывать субтитры в поток RIFF, если там даже меток времени нет?
                    0
                    VfW нарушает стандарт RIFF. Я лично писал парсер для RIFF, так что я там чуть-чуть знаю что где находится. А метки времени — это проблемы формата субтитров, нет?
                      0
                      Да какая разница, нарушает или нет. Естественно нарушает, если RIFF убог. Мы говорили о вообще факте его существования, а не о том, хороший он или плохой.

                      Нет, проблемы не только формата субтитров. Вопрос в синхронизации.
                        0
                        Насколько я знаю, сабы просто грузятся целиком в память, благо не такие они большие. Если читать их в потоковом режиме, то да, можно нарваться на underflow/overflow. Но, опять же, это вопрос к тому, кто пакует сабы — чисто технически никто не мешает правильно разложить чанки с сабами внутри интерлива так, чтобы *flow не было.
                        • UFO just landed and posted this here
              +19
              Так а зачем хоронить его? Кодируют-то в H.264 High Profile, а он лучше, чем VP8. И, патентная чистота для релизов на торрент-трекерах всегда была до лампочки. Так что как сжимали в H.264, так и будут. И, собственно, ничего плохого в этом нет.
              +2
              В выводах вы пишите, что они VP8 и h264 одинаковы по параметрам и вполне себе подходят для веба. Но вот только время кодирования, у VP8 оно огромно, получается что например ютубу нужно трать в 4 раза больше процессорного времени для кодирования — это огромный жирный минус.
                +15
                Все-таки рано, имхо, говорить о скорости кодирования VP8. Давайте подождем полгода и там уже будет проще сориентироваться. Google и команда Youtube отлично понимают чего стоит минута вычислений. Да и проект то по сути уже стал «народным» — думаете не «проимпрувят пефоманс»?
                  0
                  Думаете у Google не хватает людей и ресурсов, чтобы провести аналогичное сравнение?
                  Думаю, они в курсе такой разницы во времени кодирования, но сознательно пошли на это. Почему — другой вопрос.

                  Ну и конечным пользователям довольно фиолетово, сколько процессорного времени тратит YouTube
                  • UFO just landed and posted this here
                      +2
                      Мне кажется, что Google будет поступать так же, как они в свое время поступили с видео для iPhone, т.е. будут перекодировать видео в WebM постепенно, начиная с самых популярных роликов в соответствии со спросом. На сегодняшний день время введения кодека не критично, пока флэш установлен на большинстве компьютеров пользователей, и h264 бесплатен. Так что с кодированием можно не торопиться, вести его малыми темпами.

                      Для пользователя это будет означать, что иногда он будет видеть текущий плейер YouTube, но все чаще и чаще вместо него видео будет запускаться через тэг video и стандартный плейер браузера.
                        +2
                        Мне кажется, что Google будет поступать так же, как они в свое время поступили с видео для iPhone, т.е. будут перекодировать видео в WebM постепенно, начиная с самых популярных роликов в соответствии со спросом.
                        Точнее, начиная не с популярных, а с новых.
                        После того, как поставил новую Оперу и включил на Youtube тестовый режим HTML5-видео, то сразу обратил внимание, что на Youtube многие новинки уже представлены в WebM (в плеере сразу появляется пометка: HTML5 • WEBM). Например, Канобувости, которые периодически анонсируют на Хабре.

                        Т.е. процесс перехода на WebM в секторе онлайн-видеохостинга еже идёт.
                    +13
                    Наконец-то грамотное сравнение. Я, на самом деле не сомневался что high profile h.264 будет лучше vp8. Просто vp8 это хорошая альтернатива ныне существующему h.264.
                      +2
                      Тем более, что на том же YouTube high profile h.264 и не использовался, насколько мне помнится.
                      –37
                      Зачем этот пост? все же и так ясно — сторонники VP8 и Theora есть упоротые фанатики которые не верят ничему и твердят про открытость. Разработчики x264 в день релиза VP8 сразу же сделал его обзор и поржали. А сами On2 уверяли, что уже сейчас (год назад, лол) VP8 обходит x264 по всем позициям.
                        +2
                        On2 уверяли что обходят x264 BP? Да, обходят.

                        У Theora есть фанатики больше из-за временного фактора + успехов Ogg в индустрии аудио.

                        x264 действительно чуток придавило.
                          +6
                          x264 Baseline Profile: 10 минут 21 секунда
                          VP8: 83 минуты 59 секунд

                          www.on2.com/index.php?564:
                          Encode Faster. Playback Easier. Reach the Largest Possible Audience.
                          Much less compute intensive than H.264 to encode and playba
                            0
                            Тут столько маркетинга вокруг, что я сориентировался только на некий «индекс качества», в целом же, вы правы. Опять же, под сомнением находится ситуация с оптимизацией используемого в замерах снапшота и его конфигурации.

                            Ну он действительно менее интенсивно рассчитывает, потому и долго! :)
                              0
                              Маркетоидные тексты с одной стороны против некорректного теста (разное число потоков, непонятно как собрано) с другой. Я даже не знаю, чему верить :)
                                +1
                                А вы не приравнивайте On2 к Google. Не факт, что изначальный код был лицензионно чист с точки зрения Гугла и его не пришлось исправлять, чтобы лишний раз перестраховаться. Мы же не знаем всей «кухни».
                                –2
                                On2 уверял, что обходят x264 BP?

                                Да, обходят в 4 раза по времени времени кодирования для сравнимого качества.

                                Что фактически означает, что VP8 в 4 раза хуже
                                +4
                                Разработчики x264 по определению предвзятые люди, как впрочем и On2. Только мнению первых вы почему-то доверяете больше.

                                Пока факты говорят, что VP8 обходит по качеству x264 Base Profile. А большего для веба и не нужно, все равно HP никто не таргетит, потому что он поддерживается не всеми устройствами.
                                  +1
                                  это бизнес, так что объективного мнения тут никогда не будет. Я как юзер радуюсь конкуренции между разработчиками
                                    0
                                    Разработчикам x264 можно доверять, поскольку все их заявления обычно можно проверить самому. Они выкладывают все исходники и настройки, ведут дискуссии на doom9.

                                    А On2 до релиза только картинки показывали, руками потрогать на давали. После релиза оказалось, что их обещания были необоснованными.
                                      +2
                                      Чем же они не обоснованы? VP8 нисколько не устапает x264 BP, а часто даже превосходит. А всякие продвинутые режимы x264 не актуальны для Web видео потому что не на каждом устройстве проигрываются.
                                        +1
                                        Когда VP8 вышел, разработчик x264 провёл тесты, и заявил, что VP8 слегка превзошёл x264 BP, но не сильно не дотянул до x264 HP. При этом он измерял на одном видео на самых тяжёлых настройках кодеков.

                                        On2 же заранее обещали заметное превосходство над H.264 HP при меньшей вычислительной сложности. Ни того, ни другого мы не получили.
                                          –4
                                          Склоняюсь к мысли, что Гугль потратил деньги впустую.

                                          Лучше бы он детей в Африке накормил
                                      –4
                                      В професионализме разработчиков х264 я не сомневаюсь, а вот в посетителях хабра — ололололлоло. BP это профиль для телефонов и тостеров, но ждать 4 дня вместо 1 никто не будет.
                                        +1
                                        Производительность — это чисто технический вопрос и со временем он решится. В общем-то они уже над этим работают:

                                  +1
                                  Чудесно, что есть результаты и исходник в архиве. Не очень объективно видео сравнивать по скринам, а не по потоку
                                    +4
                                    «Тут без комментариев, всё и так понятно» — Пожалуйста, поясняйте графики.
                                      +2
                                      На столбчатых диаграммах показано отношение битрейта (а в итоге размера файла) при одинаковом качестве.
                                      Т.е. для ролика battle вариант с компрессией x264 HP весит 0.84 (т.е. на 16% меньше) от VP8 при примерно том же качестве, а вариант с компрессией x264 BP весит 1.18 (т.е. на 18% больше) от VP8 при примерно том же качестве.
                                      Ну и так далее по всем остальным роликам.
                                        0
                                        Статью поправьте. Я тоже не понял, но не стал ничего писать…
                                          0
                                          У меня нет возможности править чужие статьи. Да и не чувствую за собой такого морального права.
                                            0
                                            Блин, думал, это коммент автора ) Сорри и всё такое )
                                      –9
                                      Видеокодеки по скриншотам сравнивать — это круто
                                      • UFO just landed and posted this here
                                      • UFO just landed and posted this here
                                        • UFO just landed and posted this here
                                          • UFO just landed and posted this here
                                              +5
                                              Подкрутив настройки под конкретный материал можно получить результат еще лучше. Вот только кто будет этим заниматься, WebM предназначен для сервисов вроде Youtube, а не для кодирования фильмов под какой-нибудь Blu-ray.
                                              • UFO just landed and posted this here
                                                  +4
                                                  Youtube все равно перекодирует исходный материал в 5 внутренних форматов с разными разрешениями и заранее неизвестными для вас настройками. Т.е. вы на этот процесс в принципе никак не можете повлиять, а Youtube'у нужны такие настройки, чтобы результирующий материал проигрывался на максимальном числе устройств (т.е. фактически Base Profile и никаких продвинутых фич x264).

                                                  Я думаю Google вполне устраивает h264 с технической точки зрения, но он не подходит для всех браузеров из-за патентнов (например, Mozilla и Opera не хотят его поддерживать).
                                                  • UFO just landed and posted this here
                                                      +1
                                                      Да нет, это не денежный вопрос. За h264 им все равно придеться платить еще много лет (Chrome, Android, Youtube для неподдерживающих WebM устройств), а если подсчитать, сколько денег было потрачено на покупку On2, то финансово смена кодека точно не окупиться.

                                                      К тому же на h264 есть Payment Cap, т.е. стоимость лицензирования ограничена сверху 5 миллионами долларов, не зависимо от того, в каком объеме его собирается использовать Google. Для сравнения, On2 обошелся в $133 миллиона, + с настоящего момента постоянные затраты на его поддержку и развитие.

                                                      Зато теперь некоммерческие сайты вроде Wikipedia смогут использовать достаточно современный кодек бесплатно.
                                            +11
                                            >>Скриншоты должны быть в PNG, все скриншоты должны быть рядом, кликабельны для разворота в полный экран.

                                            Ух, командир-то какой!!!
                                            • UFO just landed and posted this here
                                            0
                                            Ооткуда этот чудесный заяц с аватары?
                                              +4
                                              www.bigbuckbunny.org/

                                              Фильм свободный, поэтому часто используется в таких сравнениях.
                                              0
                                              Скриншоты VP8 мне субъективно гораздо больше понравились, особенно Old town cross.
                                                0
                                                Ссылка Big buck bunny x264 HP 600kbps ведет на оригинальную картинку без сжатия.
                                                Поправьте, а то я все глаза сломал, пока надпись Source не заметил =)
                                                  0
                                                  Тоже заметил.
                                                  Интересно, не делались ли и замеры тоже на оригинале. А то уж слишком график на Big buck bunny x264 HP выбивается из общей картины.
                                                    0
                                                    Если бы замеры были на оригинале, SSIM бы был равен единице. Просто небольшой миссклик. Хорошо, что заметили.
                                                    0
                                                    Поправил, спасибо.
                                                  • UFO just landed and posted this here
                                                      0
                                                      Можно долго спорить, кто визуально лучше. Обычно при субъективных сравнениях берут много пользователей, потом результат усредняют, и отбрасывают те, которые сильно отличаются от среднего. Ещё перед сравнениям у тестеров проверяют цветовое восприятие.

                                                      Насчёт смытой черепицы, посмотрите в эту область:

                                                      Там результат у x264 HP лучше.
                                                      То, что у VP8 на небе, напоминает легкий блокинг.
                                                      Всё субъективно =)
                                                    –4
                                                    Скриншоты в архиве на файлообменнике? А что не в статье?
                                                      +1
                                                      От себя могу добавить
                                                      webmproject.blogspot.com/2010/06/vp8-codec-optimization-update.html

                                                      p.s. кстати, в блоге разработчики довольно-таки регулярно пишут об обновлениях ;)
                                                        0
                                                        Была надежда, что чистое видео, без флэша, будет играться шустрее. Все таки — лишний слой абстракции исчезает. Проверил на ютубе — в хромиуме загрузка процессора один в один такая же, что с флэшем, что с webm.
                                                        А в альфе файрфокса с webm — вообще тормозит прилично.
                                                          0
                                                          у меня на макоси с html5 тупит намного сильнее. изображение идет рывками, во флеше нет такого
                                                            0
                                                            6.0.437.3 dev
                                                              0
                                                              Странно, у меня та же версия, правда в линухе. Загрузка процессора — порядка 40%, что во флэще, что в webm варианте.

                                                              Может быть на маках у флэша уже есть аппаратное ускорение? У VP8 его пока что точно нету.
                                                              0
                                                              Есть такое. У меня при проигрывании одного и того же HD-720 ролика загрузка проца в Chrome — около 120% в режиме HTML 5, около 80% в режиме Flash.

                                                              В тоже время в Safari — 80% в режиме Flash, порядка 35% в HTML 5.

                                                              Сам долго удивлялся таким результатам :)
                                                            +1
                                                            Отличное сравнение, спасибо!

                                                            Но у вас некоторые ссылки перепутаны, например Toys x264 HP ведёт на зайца.
                                                              0
                                                              Поправил. Если ещё заметили подобные ошибки, скиньте в личку.
                                                              +1
                                                              Качественны обзор. Спасибо за потраченные усилия. Учли многие замечания к предыдущему сравнению libtheora/x264.

                                                              Что касается результатов, то многое для меня было ожидаемо. Надеюсь на дальнейшее развитие libvpx, и в первую очередь в направлении оптимизации процессорных ресурсов, многопоточности, а также в направлении использования GPU.
                                                                –1
                                                                Ёклм, сколько раз твердили, если не знаете, какие опции в x264 за что отвечают, то не используйте их. Пересеты специально для этого создавались, если и пресеты не осилили, то «x264 -o output input». У вас же тихий ужас в командных строках.

                                                                Второе, x264dev.multimedia.cx/?p=458 про оптимизацию кодеров под SSIM/PSNR и сравнение.
                                                                  0
                                                                  Я думаю, все уже обсуждали тут эту статью. Но можно в конце концов посмотреть своими глазами на скриншоты, более адекватного способа я не знаю (видео на глаз сравнивать сложнее).
                                                                    0
                                                                    Правильный способ как раз видео на глаз сравнивать. Ещё при этом не зная, где какой кодек. И при большом количестве тестеров.

                                                                    Если нет возможности подобное организовать, используются метрики качества, чтобы не потерять, например, те проблемные кадры, которые я привёл для VP8, и представлять картину в целом.

                                                                    В статье критикуется использование метрики PSNR, так как она уже устарела. Например, адаптивное квантование улучшает SSIM и визуальное качество, но просаживает PSNR. То есть кодек может иметь худший PSNR, при этом картинка будет лучше.
                                                                      0
                                                                      Это все понятно, но на неподвижной картинке проще рассмотреть детали. Лично я бы, конечно, легко смог увидеть в движении разницу между Theora и x264 HP, но вот скажем между VP8 и x264 BP… Хотя, если знать на что смотреть и заранее искать определенные недостатки, то наверное можно и так.
                                                                        0
                                                                        Дело в том, что во время просмотра видео вы больше обращаете внимание на одни артефакты и меньше на другие. Это тоже важно. В видео вы обращаете внимание на движущиеся объекты больше, чем на задний план. Наверняка, можно ещё придумать причины, по которым нужно смотреть именно видео.
                                                                    0
                                                                    Про второе. Я ж PSNR в итоге вообще не мерял. В чём проблема?

                                                                    Про первое. Давайте конкретно, что не так? Мой пресет несильно отличается от slow. Только число --ref я увеличивать не стал и включил --trellis 2.
                                                                      0
                                                                      --b-pyramid normal — параметр по умолчанию;
                                                                      --partitions all --8x8dct — выставляются автоматически на основе выбранного уровня;
                                                                      --no-psy — почему?
                                                                      --no-fast-pskip — эффект плацебо, замедляющий процесс кодирования.

                                                                      Раз близоко к slow, так и используйте --preset slow и не городите сущности.

                                                                      И в дополнение, x264 намного больше «любит», когда ratecontrol задаётся через crf, а не битрейтом. Если нет цели попасть в определённый размер, то разумно будет использовать crf, подбирая значение параметра в диапазоне от 16 до 22 (меньше — лучше).
                                                                        0
                                                                        Ничего страшного, что я указал параметры по умолчанию. Не имею привычки их запоминать наизусть.
                                                                        --no-psy потому что сравнение объективное, а не субъективное. psy-rdo просаживает SSIM и PSNR.
                                                                        --no-fast-pskip — проверил. Не знаю почему, но при его отключении уменьшается и fps, и SSIM. То есть влияние на скорость в пределах погрешности, а по SSIM всё-таки выигрыш.

                                                                        Выбор ref я обосновал. Ну да, bframe на один отступил от дефолта, ой простите, простите, как я посмел.

                                                                        Про crf. Не знаю, откуда пошёл этот миф. После первого прохода кодек как раз и оценивает crf, c которым он будет кодировать второй. Модель распределения битов по потоку известна на обоих проходах. И у меня была цель попасть в определённый размер, так как у VP8 нет crf-подобного режима, разумно их сравнивать в одинаковых usecase'ах.
                                                                          0
                                                                          миф
                                                                          Это рекомендации разработчиков.

                                                                          После первого прохода кодек как раз и оценивает crf
                                                                          Он приблизительно оценивает будущие финальные квантайзеры кадров, а не ваш тык пальцем в небо.

                                                                          Если уж для VP8 следуете рекомендациям разработчиков, то почему не удосужились сходить на #x264@freenode и спросить того же Dark_Shikari: «Я тут хочу сравнить кодеки. Как мне лучше выбрать настройки для х264?»
                                                                      • UFO just landed and posted this here
                                                                          0
                                                                          Расскажите, где можно подробней прочитать про все эти настройки, что они дают, и какая их комбинация дают лучшее качество? Заранее спасибо
                                                                          • UFO just landed and posted this here
                                                                              0
                                                                              Верно, но раз вы говорите, что x264 настроен неправильно, так можно поиграться с более лучшими настройками ) Может — увижу разницу )
                                                                            0
                                                                            Вы про профайлы лучше почитайте. Они действительно называются baseline и high.
                                                                            Я не стал выкручивать количественные параметры, потому что они существенно просаживают скорость, давая небольшой прирост в качестве. К тому же при больших числах bframes и ref ещё и растут требования по памяти, что неприемлемо для железных проигрывателей. Вы думаете youtube использует большие значения?
                                                                            Мы всё-таки кодеки для веба сравниваем, а не для рипов на торренты.

                                                                            На практике редко полезен ref выше 6 и bframes выше 8.

                                                                            А настройки я выбираю в зависимости от задачи. Поскольку я недалеко ушёл от дефолта, можете ещё предъявить претензии разработчику, почему у него такие низкие дефолтные настройки.
                                                                            • UFO just landed and posted this here
                                                                                0
                                                                                Замыл и блокинг потому что битрейта не хватает. Специально выбрал второй по порядку битрейт, потому что на нём визуально разница хорошо заметна.

                                                                                Профайлы имеют отношение к формату, а пресеты к кодеку.
                                                                                Про кодирование на лету я не говорил. Но вообще нельзя не учитывать скорость.
                                                                                83 минуты я оставил просто потому что это только первая версия кодека. Ему ещё расти и расти.

                                                                                > Никто сейчас не кодирует с subme 8 (ну кроме тех, кому пофиг на качество).
                                                                                Кодируют те, кому не пофиг на скорость.
                                                                        0
                                                                        Честно говоря, посмотрел я на ВСЕ эти картинки… И, честно говоря, не нашёл РАЗИТЕЛЬНОЙ разницы между H.264 HP, кодированным с помощью x264, и VP8 ВООБЩЕ (за редким исключением, который вынесен отдельно, в кролике и терминаторе, хотя даже кадр в терминаторе вполне хороший). Честно говоря, по моему скромному потребительскому взгляду — они РАВНЫ. Плюс — сейчас его ещё пилят, а значит баги, которые есть сейчас — пропадут (надеюсь). Поэтому ИМХО особо то выбирать то и не надо, тот что ближе по душе тот и использовать надо — VP8 АБСОЛЮТНО НИЧЕМ НЕ ХУЖЕ для конечного пользования, чем H.264 HP, кодированный с помощью x264, по восприятию глазом.
                                                                          0
                                                                          Продолжу немного — по мне, на всех скринах, представленных здесь (за исключением тех двух сбойных), VP8 достаточно заметно лучше H.264 BP.

                                                                          Всё вышесказанное разумеется ИМХО
                                                                          +1
                                                                          Здесь визуально VP8 оказался ненамного лучше, чем x264 BP. У них на разных сценах по-разному замылена картинка. По SSIM VP8 оказался всё-таки выше. x264 HP заметно лучше.

                                                                          Да ну?

                                                                          comparescreenshots.slicx.com/comparison/63448
                                                                          comparescreenshots.slicx.com/comparison/63449

                                                                          А по-моему наоборот VP8 почти идентичен с оригиналом, а x264 HP все замылил.
                                                                          +6
                                                                          А как насчёт слепого тестирования?

                                                                          Подобрать 5-6 разноплановых видеороликов (с разной динамикой, детализацией и цветностью). Можно те, что у вас есть, а можно расширить этот список. Например:
                                                                          — 3D-анимация (а-ля big buck bunny и пиксаровских мультиков);
                                                                          — плоская контурная анимация (а-ля Симпсоны, Футурама, Саузпарк, Гриффины);
                                                                          — динамичный боевичок с машинами, погонями, выстрелами, огнём и взрывами;
                                                                          — сцены дикой природы с животными и растительностью;
                                                                          — сцены с высокой детализацией и обилием мелких объектов;
                                                                          — тёмное видео со слабой освещённостью;
                                                                          — другие сложные сцены с туманом, дымом, рябью на воде.
                                                                          Из каждого нарезать по 20-30 секунд самых типовых для данного типа видео фрагментов. Пожать в трёх вариантах:
                                                                          1) x264 (H.264 High-Profile);
                                                                          2) x264 (H.264 Baseline-profile);
                                                                          3) libvpx (VP8)

                                                                          Дальше видео декодируется и пережимается каким-либо lossless видеокодеком. Ни в имени, ни в заголовках внутри файла не должно остаться никакой информации об их прежней компрессии. Все файлы-ролики именуются случайным порядком (известным только вам).
                                                                          Например, ролик bunny:
                                                                          bunny-1.mkv — libvpx (VP8)
                                                                          bunny-2.mkv — x264 BP
                                                                          bunny-3.mkv — x264 HP
                                                                          А ролик helicopter уже:
                                                                          helicopter-1.mkv — x264 HP
                                                                          helicopter-2.mkv — libvpx (VP8)
                                                                          helicopter-3.mkv — x264 BP
                                                                          и т.д. (порядок нумерации хаотичный, без всякой логики)

                                                                          В таком виде ролики выкладываются на общественный суд. Объёмы будут приличные, но если сделать torrent-раздачу, то по сети bittorrent быстрее можно распространить.
                                                                          На каком-нить google-docs создаётся опросник для сбора мнения по роликам и с простановкой им оценок по 5-бальной (или для простоты трёхбальной) шкале для разных вариантов одного ролика. Например, ролику bunny некий зритель-тестер поставил первому 3 балла, второму 1, третьему тоже 1 балл. Ролику helicopter он поставил первому 3 балла, второму 2, третьему 1 и т.д. При этом он заранее не знал, кто из них был пожат каким кодеком.

                                                                          Вы собираете эти данные и, зная кто есть кто, составляете сводную таблицу оценок каждому кодеку по каждому ролику.
                                                                          Если наберётся несколько десятков протестировавших, то можно будет составить некий объективный результат слепого тестирования.
                                                                            0
                                                                            Когда готовил это сравнение, думал над этим.

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

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

                                                                            Кстати, как я написал в начале, слепое тестирование сейчас готовит Jason, но там будет одно видео и зоопарк кодеков.
                                                                              0
                                                                              Самая большая проблема в честности тестеров. Если известны кодеки-участники, можно задаться целью выяснить, кто есть кто.
                                                                              Да ну бросьте. Думаете, троллям будет не лень пережимать видео с теми же параметрами, чтобы выявить кодеки и накрутить счётчики? Вряд ли.

                                                                              Для пущей безопасности можете до окончания слепого тестирования:
                                                                              а) не выкладывать исходное видео;
                                                                              б) не сообщать все параметры видеокомпрессии.
                                                                              Тогда сэмулировать ту же компрессию и подтасовать результаты будет сложнее.

                                                                              А заниматься накруткой, когда реальные участники тестирования не угадываются наверняка, это бесперспективное занятие, т.к. не знаешь, чей же именно рейтинг ты накручиваешь.
                                                                                0
                                                                                Плюс можно для большей объективности результатов увеличить разнообразие:
                                                                                т.е. кроме x264 hp; x264 bp и libvpx добавить в сравнение ещё несколько участников в виде других H.264-кодеков (например, DivX H.264, Mainconcept H.264, Elecard H.264 и др.) или же тот же x264, но с другими параметрами компрессии.

                                                                                Когда на один ролик будет штук 5-6 вариантов с x264 (лучше, хуже и сравнимых с VP8 по качеству), там уже сложнее угадать вслепую, кто есть кто, чтобы вытянуть липовым голосованием нужного кандидата.
                                                                                  0
                                                                                  Нельзя не выкладывать исходное видео, так как сама задача сравнения — оценка похожести на исходник.
                                                                                  Насчёт добавить других кандидатов. Да, можно. Но тут есть ограничения на общее количество последовательностей, которые просматривает тестер. Если их будет много, то под конец теряется внимательность. Так что при добавлении других кодеков придётся уменьшать количество разных сэмплов.
                                                                            0
                                                                            Сравнение идёт на больших битрейтах не имеет смысла — мобильные каналы передачи данных и энергосбережение вот что важно. Разница в 10% разве разница, когда файлы весят по 1 гигабайту?

                                                                            Ptalarbvorm как раз под это дело оптимизирован.

                                                                            Вот на 280 было бы интересно
                                                                              +1
                                                                              По-моему, на первой картинке кролик Бак иронизирует, но я не уверен, лицо как-то смазано, впрочем, как и вся фигура.
                                                                              • UFO just landed and posted this here
                                                                                +3
                                                                                Уже здесь и сейчас. Youtube для SD использует Main Profile, а для HD — High Profile.
                                                                                Почему такая зацикленность на самом убогом Baseline — в недоумении. Хотя, догадываюсь (
                                                                                  0
                                                                                  www.linux.org.ru/news/multimedia/5052563 — Собственный декодер VP8 для FFmpeg.

                                                                                  Only users with full accounts can post comments. Log in, please.