Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 106
Вопрос к фэнсабберам. Они задают во многом тот формат, который будет популярен. Именно они продвинули mkv, именно они в своё время популяризовали h264, именно они могут похоронить его.
Во внутрь AVI text stream вполне пакуется, кстати, тоже. Так же как несколько аудио-потоков.
Только в стандарте AVI субтитров нет, к сожалению. И все, что есть — сторонние хаки.
Да весь контейнер AVI — это один большой, морально устаревший и малофункциональный костыль. Там и вставка нескольких аудиопотоков тоже, можно сказать, через хаки делается. Давно пора его забыть и перейти повсеместно на Matroska, Ogg Media или MP4.
Э… «Стандарта» AVI не существует. В том смысле, что то, что было сделано (RIFF) описывает не то, что мы обычно видим внутри AVI. Например, RIFF описывает в CHUNK относительную длинну, а в AVI всё имеет абсолютное положение (могу врать по старости у кого что, но именно так). С PADDING'ом там тоже всё сильно запутано.
А наличие потоков с всякой дрянью, кстати, вполне в формат riff укладывается.
А наличие потоков с всякой дрянью, кстати, вполне в формат riff укладывается.
Как это не существует? И VfW тоже нет в природе?
И как вы собирались упаковывать субтитры в поток RIFF, если там даже меток времени нет?
И как вы собирались упаковывать субтитры в поток RIFF, если там даже меток времени нет?
VfW нарушает стандарт RIFF. Я лично писал парсер для RIFF, так что я там чуть-чуть знаю что где находится. А метки времени — это проблемы формата субтитров, нет?
Да какая разница, нарушает или нет. Естественно нарушает, если RIFF убог. Мы говорили о вообще факте его существования, а не о том, хороший он или плохой.
Нет, проблемы не только формата субтитров. Вопрос в синхронизации.
Нет, проблемы не только формата субтитров. Вопрос в синхронизации.
Насколько я знаю, сабы просто грузятся целиком в память, благо не такие они большие. Если читать их в потоковом режиме, то да, можно нарваться на underflow/overflow. Но, опять же, это вопрос к тому, кто пакует сабы — чисто технически никто не мешает правильно разложить чанки с сабами внутри интерлива так, чтобы *flow не было.
Так а зачем хоронить его? Кодируют-то в H.264 High Profile, а он лучше, чем VP8. И, патентная чистота для релизов на торрент-трекерах всегда была до лампочки. Так что как сжимали в H.264, так и будут. И, собственно, ничего плохого в этом нет.
В выводах вы пишите, что они VP8 и h264 одинаковы по параметрам и вполне себе подходят для веба. Но вот только время кодирования, у VP8 оно огромно, получается что например ютубу нужно трать в 4 раза больше процессорного времени для кодирования — это огромный жирный минус.
Все-таки рано, имхо, говорить о скорости кодирования VP8. Давайте подождем полгода и там уже будет проще сориентироваться. Google и команда Youtube отлично понимают чего стоит минута вычислений. Да и проект то по сути уже стал «народным» — думаете не «проимпрувят пефоманс»?
Думаете у Google не хватает людей и ресурсов, чтобы провести аналогичное сравнение?
Думаю, они в курсе такой разницы во времени кодирования, но сознательно пошли на это. Почему — другой вопрос.
Ну и конечным пользователям довольно фиолетово, сколько процессорного времени тратит YouTube
Думаю, они в курсе такой разницы во времени кодирования, но сознательно пошли на это. Почему — другой вопрос.
Ну и конечным пользователям довольно фиолетово, сколько процессорного времени тратит YouTube
Мне кажется, что Google будет поступать так же, как они в свое время поступили с видео для iPhone, т.е. будут перекодировать видео в WebM постепенно, начиная с самых популярных роликов в соответствии со спросом. На сегодняшний день время введения кодека не критично, пока флэш установлен на большинстве компьютеров пользователей, и h264 бесплатен. Так что с кодированием можно не торопиться, вести его малыми темпами.
Для пользователя это будет означать, что иногда он будет видеть текущий плейер YouTube, но все чаще и чаще вместо него видео будет запускаться через тэг video и стандартный плейер браузера.
Для пользователя это будет означать, что иногда он будет видеть текущий плейер YouTube, но все чаще и чаще вместо него видео будет запускаться через тэг video и стандартный плейер браузера.
Мне кажется, что Google будет поступать так же, как они в свое время поступили с видео для iPhone, т.е. будут перекодировать видео в WebM постепенно, начиная с самых популярных роликов в соответствии со спросом.Точнее, начиная не с популярных, а с новых.
После того, как поставил новую Оперу и включил на Youtube тестовый режим HTML5-видео, то сразу обратил внимание, что на Youtube многие новинки уже представлены в WebM (в плеере сразу появляется пометка: HTML5 • WEBM). Например, Канобувости, которые периодически анонсируют на Хабре.
Т.е. процесс перехода на WebM в секторе онлайн-видеохостинга еже идёт.
Наконец-то грамотное сравнение. Я, на самом деле не сомневался что high profile h.264 будет лучше vp8. Просто vp8 это хорошая альтернатива ныне существующему h.264.
Зачем этот пост? все же и так ясно — сторонники VP8 и Theora есть упоротые фанатики которые не верят ничему и твердят про открытость. Разработчики x264 в день релиза VP8 сразу же сделал его обзор и поржали. А сами On2 уверяли, что уже сейчас (год назад, лол) VP8 обходит x264 по всем позициям.
On2 уверяли что обходят x264 BP? Да, обходят.
У Theora есть фанатики больше из-за временного фактора + успехов Ogg в индустрии аудио.
x264 действительно чуток придавило.
У Theora есть фанатики больше из-за временного фактора + успехов Ogg в индустрии аудио.
x264 действительно чуток придавило.
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
Тут столько маркетинга вокруг, что я сориентировался только на некий «индекс качества», в целом же, вы правы. Опять же, под сомнением находится ситуация с оптимизацией используемого в замерах снапшота и его конфигурации.
Ну он действительно менее интенсивно рассчитывает, потому и долго! :)
Ну он действительно менее интенсивно рассчитывает, потому и долго! :)
Маркетоидные тексты с одной стороны против некорректного теста (разное число потоков, непонятно как собрано) с другой. Я даже не знаю, чему верить :)
А вы не приравнивайте On2 к Google. Не факт, что изначальный код был лицензионно чист с точки зрения Гугла и его не пришлось исправлять, чтобы лишний раз перестраховаться. Мы же не знаем всей «кухни».
On2 уверял, что обходят x264 BP?
Да, обходят в 4 раза по времени времени кодирования для сравнимого качества.
Что фактически означает, что VP8 в 4 раза хуже
Да, обходят в 4 раза по времени времени кодирования для сравнимого качества.
Что фактически означает, что VP8 в 4 раза хуже
Разработчики x264 по определению предвзятые люди, как впрочем и On2. Только мнению первых вы почему-то доверяете больше.
Пока факты говорят, что VP8 обходит по качеству x264 Base Profile. А большего для веба и не нужно, все равно HP никто не таргетит, потому что он поддерживается не всеми устройствами.
Пока факты говорят, что VP8 обходит по качеству x264 Base Profile. А большего для веба и не нужно, все равно HP никто не таргетит, потому что он поддерживается не всеми устройствами.
это бизнес, так что объективного мнения тут никогда не будет. Я как юзер радуюсь конкуренции между разработчиками
Разработчикам x264 можно доверять, поскольку все их заявления обычно можно проверить самому. Они выкладывают все исходники и настройки, ведут дискуссии на doom9.
А On2 до релиза только картинки показывали, руками потрогать на давали. После релиза оказалось, что их обещания были необоснованными.
А On2 до релиза только картинки показывали, руками потрогать на давали. После релиза оказалось, что их обещания были необоснованными.
Чем же они не обоснованы? VP8 нисколько не устапает x264 BP, а часто даже превосходит. А всякие продвинутые режимы x264 не актуальны для Web видео потому что не на каждом устройстве проигрываются.
Когда VP8 вышел, разработчик x264 провёл тесты, и заявил, что VP8 слегка превзошёл x264 BP, но не сильно не дотянул до x264 HP. При этом он измерял на одном видео на самых тяжёлых настройках кодеков.
On2 же заранее обещали заметное превосходство над H.264 HP при меньшей вычислительной сложности. Ни того, ни другого мы не получили.
On2 же заранее обещали заметное превосходство над H.264 HP при меньшей вычислительной сложности. Ни того, ни другого мы не получили.
В професионализме разработчиков х264 я не сомневаюсь, а вот в посетителях хабра — ололололлоло. BP это профиль для телефонов и тостеров, но ждать 4 дня вместо 1 никто не будет.
Производительность — это чисто технический вопрос и со временем он решится. В общем-то они уже над этим работают:
webmproject.blogspot.com/2010/06/vp8-codec-optimization-update.html
А насчет BP — контент для веба кодируют так, чтобы он работал и на телефонах. Что странного в таком требовании?
А насчет BP — контент для веба кодируют так, чтобы он работал и на телефонах. Что странного в таком требовании?
«Тут без комментариев, всё и так понятно» — Пожалуйста, поясняйте графики.
На столбчатых диаграммах показано отношение битрейта (а в итоге размера файла) при одинаковом качестве.
Т.е. для ролика battle вариант с компрессией x264 HP весит 0.84 (т.е. на 16% меньше) от VP8 при примерно том же качестве, а вариант с компрессией x264 BP весит 1.18 (т.е. на 18% больше) от VP8 при примерно том же качестве.
Ну и так далее по всем остальным роликам.
Т.е. для ролика battle вариант с компрессией x264 HP весит 0.84 (т.е. на 16% меньше) от VP8 при примерно том же качестве, а вариант с компрессией x264 BP весит 1.18 (т.е. на 18% больше) от VP8 при примерно том же качестве.
Ну и так далее по всем остальным роликам.
Видеокодеки по скриншотам сравнивать — это круто
Подкрутив настройки под конкретный материал можно получить результат еще лучше. Вот только кто будет этим заниматься, WebM предназначен для сервисов вроде Youtube, а не для кодирования фильмов под какой-нибудь Blu-ray.
Youtube все равно перекодирует исходный материал в 5 внутренних форматов с разными разрешениями и заранее неизвестными для вас настройками. Т.е. вы на этот процесс в принципе никак не можете повлиять, а Youtube'у нужны такие настройки, чтобы результирующий материал проигрывался на максимальном числе устройств (т.е. фактически Base Profile и никаких продвинутых фич x264).
Я думаю Google вполне устраивает h264 с технической точки зрения, но он не подходит для всех браузеров из-за патентнов (например, Mozilla и Opera не хотят его поддерживать).
Я думаю Google вполне устраивает h264 с технической точки зрения, но он не подходит для всех браузеров из-за патентнов (например, Mozilla и Opera не хотят его поддерживать).
Да нет, это не денежный вопрос. За h264 им все равно придеться платить еще много лет (Chrome, Android, Youtube для неподдерживающих WebM устройств), а если подсчитать, сколько денег было потрачено на покупку On2, то финансово смена кодека точно не окупиться.
К тому же на h264 есть Payment Cap, т.е. стоимость лицензирования ограничена сверху 5 миллионами долларов, не зависимо от того, в каком объеме его собирается использовать Google. Для сравнения, On2 обошелся в $133 миллиона, + с настоящего момента постоянные затраты на его поддержку и развитие.
Зато теперь некоммерческие сайты вроде Wikipedia смогут использовать достаточно современный кодек бесплатно.
К тому же на h264 есть Payment Cap, т.е. стоимость лицензирования ограничена сверху 5 миллионами долларов, не зависимо от того, в каком объеме его собирается использовать Google. Для сравнения, On2 обошелся в $133 миллиона, + с настоящего момента постоянные затраты на его поддержку и развитие.
Зато теперь некоммерческие сайты вроде Wikipedia смогут использовать достаточно современный кодек бесплатно.
>>Скриншоты должны быть в PNG, все скриншоты должны быть рядом, кликабельны для разворота в полный экран.
Ух, командир-то какой!!!
Ух, командир-то какой!!!
Ооткуда этот чудесный заяц с аватары?
Скриншоты VP8 мне субъективно гораздо больше понравились, особенно Old town cross.
Ссылка Big buck bunny x264 HP 600kbps ведет на оригинальную картинку без сжатия.
Поправьте, а то я все глаза сломал, пока надпись Source не заметил =)
Поправьте, а то я все глаза сломал, пока надпись Source не заметил =)
Можно долго спорить, кто визуально лучше. Обычно при субъективных сравнениях берут много пользователей, потом результат усредняют, и отбрасывают те, которые сильно отличаются от среднего. Ещё перед сравнениям у тестеров проверяют цветовое восприятие.
Насчёт смытой черепицы, посмотрите в эту область:
Там результат у x264 HP лучше.
То, что у VP8 на небе, напоминает легкий блокинг.
Всё субъективно =)
Насчёт смытой черепицы, посмотрите в эту область:
Там результат у x264 HP лучше.
То, что у VP8 на небе, напоминает легкий блокинг.
Всё субъективно =)
Скриншоты в архиве на файлообменнике? А что не в статье?
От себя могу добавить
webmproject.blogspot.com/2010/06/vp8-codec-optimization-update.html
p.s. кстати, в блоге разработчики довольно-таки регулярно пишут об обновлениях ;)
webmproject.blogspot.com/2010/06/vp8-codec-optimization-update.html
p.s. кстати, в блоге разработчики довольно-таки регулярно пишут об обновлениях ;)
Была надежда, что чистое видео, без флэша, будет играться шустрее. Все таки — лишний слой абстракции исчезает. Проверил на ютубе — в хромиуме загрузка процессора один в один такая же, что с флэшем, что с webm.
А в альфе файрфокса с webm — вообще тормозит прилично.
А в альфе файрфокса с webm — вообще тормозит прилично.
у меня на макоси с html5 тупит намного сильнее. изображение идет рывками, во флеше нет такого
Отличное сравнение, спасибо!
Но у вас некоторые ссылки перепутаны, например Toys x264 HP ведёт на зайца.
Но у вас некоторые ссылки перепутаны, например Toys x264 HP ведёт на зайца.
Качественны обзор. Спасибо за потраченные усилия. Учли многие замечания к предыдущему сравнению libtheora/x264.
Что касается результатов, то многое для меня было ожидаемо. Надеюсь на дальнейшее развитие libvpx, и в первую очередь в направлении оптимизации процессорных ресурсов, многопоточности, а также в направлении использования GPU.
Что касается результатов, то многое для меня было ожидаемо. Надеюсь на дальнейшее развитие libvpx, и в первую очередь в направлении оптимизации процессорных ресурсов, многопоточности, а также в направлении использования GPU.
Ёклм, сколько раз твердили, если не знаете, какие опции в x264 за что отвечают, то не используйте их. Пересеты специально для этого создавались, если и пресеты не осилили, то «x264 -o output input». У вас же тихий ужас в командных строках.
Второе, x264dev.multimedia.cx/?p=458 про оптимизацию кодеров под SSIM/PSNR и сравнение.
Второе, x264dev.multimedia.cx/?p=458 про оптимизацию кодеров под SSIM/PSNR и сравнение.
Я думаю, все уже обсуждали тут эту статью. Но можно в конце концов посмотреть своими глазами на скриншоты, более адекватного способа я не знаю (видео на глаз сравнивать сложнее).
Правильный способ как раз видео на глаз сравнивать. Ещё при этом не зная, где какой кодек. И при большом количестве тестеров.
Если нет возможности подобное организовать, используются метрики качества, чтобы не потерять, например, те проблемные кадры, которые я привёл для VP8, и представлять картину в целом.
В статье критикуется использование метрики PSNR, так как она уже устарела. Например, адаптивное квантование улучшает SSIM и визуальное качество, но просаживает PSNR. То есть кодек может иметь худший PSNR, при этом картинка будет лучше.
Если нет возможности подобное организовать, используются метрики качества, чтобы не потерять, например, те проблемные кадры, которые я привёл для VP8, и представлять картину в целом.
В статье критикуется использование метрики PSNR, так как она уже устарела. Например, адаптивное квантование улучшает SSIM и визуальное качество, но просаживает PSNR. То есть кодек может иметь худший PSNR, при этом картинка будет лучше.
Про второе. Я ж PSNR в итоге вообще не мерял. В чём проблема?
Про первое. Давайте конкретно, что не так? Мой пресет несильно отличается от slow. Только число --ref я увеличивать не стал и включил --trellis 2.
Про первое. Давайте конкретно, что не так? Мой пресет несильно отличается от slow. Только число --ref я увеличивать не стал и включил --trellis 2.
--b-pyramid normal — параметр по умолчанию;
--partitions all --8x8dct — выставляются автоматически на основе выбранного уровня;
--no-psy — почему?
--no-fast-pskip — эффект плацебо, замедляющий процесс кодирования.
Раз близоко к slow, так и используйте --preset slow и не городите сущности.
И в дополнение, x264 намного больше «любит», когда ratecontrol задаётся через crf, а не битрейтом. Если нет цели попасть в определённый размер, то разумно будет использовать crf, подбирая значение параметра в диапазоне от 16 до 22 (меньше — лучше).
--partitions all --8x8dct — выставляются автоматически на основе выбранного уровня;
--no-psy — почему?
--no-fast-pskip — эффект плацебо, замедляющий процесс кодирования.
Раз близоко к slow, так и используйте --preset slow и не городите сущности.
И в дополнение, x264 намного больше «любит», когда ratecontrol задаётся через crf, а не битрейтом. Если нет цели попасть в определённый размер, то разумно будет использовать crf, подбирая значение параметра в диапазоне от 16 до 22 (меньше — лучше).
Ничего страшного, что я указал параметры по умолчанию. Не имею привычки их запоминать наизусть.
--no-psy потому что сравнение объективное, а не субъективное. psy-rdo просаживает SSIM и PSNR.
--no-fast-pskip — проверил. Не знаю почему, но при его отключении уменьшается и fps, и SSIM. То есть влияние на скорость в пределах погрешности, а по SSIM всё-таки выигрыш.
Выбор ref я обосновал. Ну да, bframe на один отступил от дефолта, ой простите, простите, как я посмел.
Про crf. Не знаю, откуда пошёл этот миф. После первого прохода кодек как раз и оценивает crf, c которым он будет кодировать второй. Модель распределения битов по потоку известна на обоих проходах. И у меня была цель попасть в определённый размер, так как у VP8 нет crf-подобного режима, разумно их сравнивать в одинаковых usecase'ах.
--no-psy потому что сравнение объективное, а не субъективное. psy-rdo просаживает SSIM и PSNR.
--no-fast-pskip — проверил. Не знаю почему, но при его отключении уменьшается и fps, и SSIM. То есть влияние на скорость в пределах погрешности, а по SSIM всё-таки выигрыш.
Выбор ref я обосновал. Ну да, bframe на один отступил от дефолта, ой простите, простите, как я посмел.
Про crf. Не знаю, откуда пошёл этот миф. После первого прохода кодек как раз и оценивает crf, c которым он будет кодировать второй. Модель распределения битов по потоку известна на обоих проходах. И у меня была цель попасть в определённый размер, так как у VP8 нет crf-подобного режима, разумно их сравнивать в одинаковых usecase'ах.
миф
Это рекомендации разработчиков.
После первого прохода кодек как раз и оценивает crf
Он приблизительно оценивает будущие финальные квантайзеры кадров, а не ваш тык пальцем в небо.
Если уж для VP8 следуете рекомендациям разработчиков, то почему не удосужились сходить на #x264@freenode и спросить того же Dark_Shikari: «Я тут хочу сравнить кодеки. Как мне лучше выбрать настройки для х264?»
Это рекомендации разработчиков.
После первого прохода кодек как раз и оценивает crf
Он приблизительно оценивает будущие финальные квантайзеры кадров, а не ваш тык пальцем в небо.
Если уж для VP8 следуете рекомендациям разработчиков, то почему не удосужились сходить на #x264@freenode и спросить того же Dark_Shikari: «Я тут хочу сравнить кодеки. Как мне лучше выбрать настройки для х264?»
Расскажите, где можно подробней прочитать про все эти настройки, что они дают, и какая их комбинация дают лучшее качество? Заранее спасибо
Вы про профайлы лучше почитайте. Они действительно называются baseline и high.
Я не стал выкручивать количественные параметры, потому что они существенно просаживают скорость, давая небольшой прирост в качестве. К тому же при больших числах bframes и ref ещё и растут требования по памяти, что неприемлемо для железных проигрывателей. Вы думаете youtube использует большие значения?
Мы всё-таки кодеки для веба сравниваем, а не для рипов на торренты.
На практике редко полезен ref выше 6 и bframes выше 8.
А настройки я выбираю в зависимости от задачи. Поскольку я недалеко ушёл от дефолта, можете ещё предъявить претензии разработчику, почему у него такие низкие дефолтные настройки.
Я не стал выкручивать количественные параметры, потому что они существенно просаживают скорость, давая небольшой прирост в качестве. К тому же при больших числах bframes и ref ещё и растут требования по памяти, что неприемлемо для железных проигрывателей. Вы думаете youtube использует большие значения?
Мы всё-таки кодеки для веба сравниваем, а не для рипов на торренты.
На практике редко полезен ref выше 6 и bframes выше 8.
А настройки я выбираю в зависимости от задачи. Поскольку я недалеко ушёл от дефолта, можете ещё предъявить претензии разработчику, почему у него такие низкие дефолтные настройки.
Замыл и блокинг потому что битрейта не хватает. Специально выбрал второй по порядку битрейт, потому что на нём визуально разница хорошо заметна.
Профайлы имеют отношение к формату, а пресеты к кодеку.
Про кодирование на лету я не говорил. Но вообще нельзя не учитывать скорость.
83 минуты я оставил просто потому что это только первая версия кодека. Ему ещё расти и расти.
> Никто сейчас не кодирует с subme 8 (ну кроме тех, кому пофиг на качество).
Кодируют те, кому не пофиг на скорость.
Профайлы имеют отношение к формату, а пресеты к кодеку.
Про кодирование на лету я не говорил. Но вообще нельзя не учитывать скорость.
83 минуты я оставил просто потому что это только первая версия кодека. Ему ещё расти и расти.
> Никто сейчас не кодирует с subme 8 (ну кроме тех, кому пофиг на качество).
Кодируют те, кому не пофиг на скорость.
Честно говоря, посмотрел я на ВСЕ эти картинки… И, честно говоря, не нашёл РАЗИТЕЛЬНОЙ разницы между H.264 HP, кодированным с помощью x264, и VP8 ВООБЩЕ (за редким исключением, который вынесен отдельно, в кролике и терминаторе, хотя даже кадр в терминаторе вполне хороший). Честно говоря, по моему скромному потребительскому взгляду — они РАВНЫ. Плюс — сейчас его ещё пилят, а значит баги, которые есть сейчас — пропадут (надеюсь). Поэтому ИМХО особо то выбирать то и не надо, тот что ближе по душе тот и использовать надо — VP8 АБСОЛЮТНО НИЧЕМ НЕ ХУЖЕ для конечного пользования, чем H.264 HP, кодированный с помощью x264, по восприятию глазом.
Здесь визуально VP8 оказался ненамного лучше, чем x264 BP. У них на разных сценах по-разному замылена картинка. По SSIM VP8 оказался всё-таки выше. x264 HP заметно лучше.
Да ну?
comparescreenshots.slicx.com/comparison/63448
comparescreenshots.slicx.com/comparison/63449
А по-моему наоборот VP8 почти идентичен с оригиналом, а x264 HP все замылил.
Вот график SSIM по всему видео на битрейте 600. Сравниваются x264 HP (красный) и VP8 (синий). Этот кадр просто попал в один из тех удачных моментов, когда VP8 хорошо себя показал. В статье я это отметил.
Но в среднем у VP8 результат хуже, и есть несколько совсем неудачных сцен. Вот ещё одна, буквально через 11 кадров.
i7.fastpic.ru/big/2010/0620/0c/e2bcfa1ab299c35f5d1894b257e6a50c.png
i7.fastpic.ru/big/2010/0620/11/38cca441b40d62a575f1dd1ebeaa3e11.png
i7.fastpic.ru/big/2010/0620/24/f61e075e964a40b4960c3f03546eda24.png
i7.fastpic.ru/big/2010/0620/52/bafd31614a7d36c12192abd6e7758752.png
i7.fastpic.ru/big/2010/0620/e5/9821ee824ef6bca096954498851f9fe5.png
Можете сами посмотреть видео.
Но в среднем у VP8 результат хуже, и есть несколько совсем неудачных сцен. Вот ещё одна, буквально через 11 кадров.
i7.fastpic.ru/big/2010/0620/0c/e2bcfa1ab299c35f5d1894b257e6a50c.png
i7.fastpic.ru/big/2010/0620/11/38cca441b40d62a575f1dd1ebeaa3e11.png
i7.fastpic.ru/big/2010/0620/24/f61e075e964a40b4960c3f03546eda24.png
i7.fastpic.ru/big/2010/0620/52/bafd31614a7d36c12192abd6e7758752.png
i7.fastpic.ru/big/2010/0620/e5/9821ee824ef6bca096954498851f9fe5.png
Можете сами посмотреть видео.
А как насчёт слепого тестирования?
Подобрать 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 и т.д. При этом он заранее не знал, кто из них был пожат каким кодеком.
Вы собираете эти данные и, зная кто есть кто, составляете сводную таблицу оценок каждому кодеку по каждому ролику.
Если наберётся несколько десятков протестировавших, то можно будет составить некий объективный результат слепого тестирования.
Подобрать 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 и т.д. При этом он заранее не знал, кто из них был пожат каким кодеком.
Вы собираете эти данные и, зная кто есть кто, составляете сводную таблицу оценок каждому кодеку по каждому ролику.
Если наберётся несколько десятков протестировавших, то можно будет составить некий объективный результат слепого тестирования.
Когда готовил это сравнение, думал над этим.
Самая большая проблема в честности тестеров. Если известны кодеки-участники, можно задаться целью выяснить, кто есть кто. (Просто закодировать с примерным попаданием в метрики, добиться похожести результатов.) Ещё хуже, если кто-то эту инфу опубликует. Или будет сабмитить в гугл-докс несколько раз.
А так, идея хорошая. Но не думаю, что стоит проводить это в ближайшем будущем. Хочется дождаться, когда VP8 доведут до ума, чтобы результаты не обесценились в короткий срок.
Кстати, как я написал в начале, слепое тестирование сейчас готовит Jason, но там будет одно видео и зоопарк кодеков.
Самая большая проблема в честности тестеров. Если известны кодеки-участники, можно задаться целью выяснить, кто есть кто. (Просто закодировать с примерным попаданием в метрики, добиться похожести результатов.) Ещё хуже, если кто-то эту инфу опубликует. Или будет сабмитить в гугл-докс несколько раз.
А так, идея хорошая. Но не думаю, что стоит проводить это в ближайшем будущем. Хочется дождаться, когда VP8 доведут до ума, чтобы результаты не обесценились в короткий срок.
Кстати, как я написал в начале, слепое тестирование сейчас готовит Jason, но там будет одно видео и зоопарк кодеков.
Самая большая проблема в честности тестеров. Если известны кодеки-участники, можно задаться целью выяснить, кто есть кто.Да ну бросьте. Думаете, троллям будет не лень пережимать видео с теми же параметрами, чтобы выявить кодеки и накрутить счётчики? Вряд ли.
Для пущей безопасности можете до окончания слепого тестирования:
а) не выкладывать исходное видео;
б) не сообщать все параметры видеокомпрессии.
Тогда сэмулировать ту же компрессию и подтасовать результаты будет сложнее.
А заниматься накруткой, когда реальные участники тестирования не угадываются наверняка, это бесперспективное занятие, т.к. не знаешь, чей же именно рейтинг ты накручиваешь.
Плюс можно для большей объективности результатов увеличить разнообразие:
т.е. кроме x264 hp; x264 bp и libvpx добавить в сравнение ещё несколько участников в виде других H.264-кодеков (например, DivX H.264, Mainconcept H.264, Elecard H.264 и др.) или же тот же x264, но с другими параметрами компрессии.
Когда на один ролик будет штук 5-6 вариантов с x264 (лучше, хуже и сравнимых с VP8 по качеству), там уже сложнее угадать вслепую, кто есть кто, чтобы вытянуть липовым голосованием нужного кандидата.
т.е. кроме x264 hp; x264 bp и libvpx добавить в сравнение ещё несколько участников в виде других H.264-кодеков (например, DivX H.264, Mainconcept H.264, Elecard H.264 и др.) или же тот же x264, но с другими параметрами компрессии.
Когда на один ролик будет штук 5-6 вариантов с x264 (лучше, хуже и сравнимых с VP8 по качеству), там уже сложнее угадать вслепую, кто есть кто, чтобы вытянуть липовым голосованием нужного кандидата.
Нельзя не выкладывать исходное видео, так как сама задача сравнения — оценка похожести на исходник.
Насчёт добавить других кандидатов. Да, можно. Но тут есть ограничения на общее количество последовательностей, которые просматривает тестер. Если их будет много, то под конец теряется внимательность. Так что при добавлении других кодеков придётся уменьшать количество разных сэмплов.
Насчёт добавить других кандидатов. Да, можно. Но тут есть ограничения на общее количество последовательностей, которые просматривает тестер. Если их будет много, то под конец теряется внимательность. Так что при добавлении других кодеков придётся уменьшать количество разных сэмплов.
Сравнение идёт на больших битрейтах не имеет смысла — мобильные каналы передачи данных и энергосбережение вот что важно. Разница в 10% разве разница, когда файлы весят по 1 гигабайту?
Ptalarbvorm как раз под это дело оптимизирован.
Вот на 280 было бы интересно
Ptalarbvorm как раз под это дело оптимизирован.
Вот на 280 было бы интересно
По-моему, на первой картинке кролик Бак иронизирует, но я не уверен, лицо как-то смазано, впрочем, как и вся фигура.
Уже здесь и сейчас. Youtube для SD использует Main Profile, а для HD — High Profile.
Почему такая зацикленность на самом убогом Baseline — в недоумении. Хотя, догадываюсь (
Почему такая зацикленность на самом убогом Baseline — в недоумении. Хотя, догадываюсь (
www.linux.org.ru/news/multimedia/5052563 — Собственный декодер VP8 для FFmpeg.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение кодеков VP8, x264 и libtheora