Компания Google представила (http://blog.webmproject.org/2011/03/vp8-codec-sdk-bali-relea...) VP8 Codec SDK (libvpx 0.9.6 (http://www.webmproject.org/code/#libvpx_the_vp8_codec_sdk)), третий релиз свободного видеокодека VP8 (http://www.webmproject.org), выпущенный под кодовым именем "Bali". Отдельно отмечается, что изменения в новой версии коснулись только оптимизации работы кодека и не затронули формат кодирования, связанные с VP8 и WebM спецификации не изменились. При подготовке версии "Bali" работа была сфокусирована на увеличении производительности кодировщика на на увеличении качества кодирования видео.
Ключевые изменения в коде кодировщика:- Скорость кодирования в режиме максимального качества (режим "Best") на x86-процессорах увеличилась в 4.5 раза по сравнению с первым вариантом (http://www.opennet.me/opennews/art.shtml?num=26656) кодировщика или в 1.35 раза по сравнению с прошлым выпуском (http://www.opennet.me/opennews/art.shtml?num=28488);
- В режиме хо...
URL: http://blog.webmproject.org/2011/03/vp8-codec-sdk-bali-relea...
Новость: http://www.opennet.me/opennews/art.shtml?num=29849
> по сравнению с первым вариантом кодировщикаДа, хорошо сравнивать с 1913 годом.
Если что ещё и года не прошло.
Для тех, кто не помнит -- при Союзе была традиция сравнивать любые показатели (производство чугуна, количество автомобилей на душу населения) с 1913 годом. Получали умопомрачительные проценты прогресса, даже во времена застоя.Так и тут, сравнивать третью версию с первой, давным давно улучшенной ко второй, -- это просто такой грязный маркетинговый трюк, чтобы числа внушительнее выглядели. В том, что стало быстрее в 4.7 раза, заслуга не столько третьей версии (в 1.35), как второй (в 3.3). Сравнивать новую версию имеет смысл только с предыдущей (если, разумеется, в предыдущей не было регресса), точнее -- с лучшей из прошлых.
>Для тех, кто не помнит - при Союзе была традицияУ кого была традиция? И что все 74 года производство чугуна и т.д. сравнивали с 1913 годом?
Да!
за все 74 года не скажу, а в 75-90 сравнивали именно с ним. Посмотри любой учебник по истории этого периода.
> Да!
> за все 74 года не скажу, а в 75-90 сравнивали именно с
> ним. Посмотри любой учебник по истории этого периода.Ссылку гони на учебник ибо есть мнение, что сравнивали не только с 1913, а и с довоенным и послевоенным дабы показать прогресс. Что есть правильно.
Враньё. Не только с 1913 сравнивали. А в тех случаях, когда был 1913 (и такое было) так сравнивали с самым успешным годом по Российской империи. Если бы с 1914 или 1915 сравнивали, тогда бы и свистел о подтасовках.
3 месяца же!
> Качества кодирования в режиме "Best" по сравнению с прошлой версией увеличено на 6.3%
> За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа;
> Значительно улучшено качество
> Улучшено качество кодированияРадость! Несмотря на нетронутый формат файла, по-видимому ещё есть куда увеличивать качество. Догоним и перегоним H.264!
Ну конечно есть. В лучшем качестве (я кодировал несколько видео с разной динамикой и длинной) в среднем в h264 получалось например 3 Мб, а в WebM - 4,5 Мб, при полностью одинаковом качестве получившегося видео. Стремиться куда есть.
>В лучшем качестве (я кодировал несколько видео с разной динамикой и длинной) в среднем в h264 получалось например 3 Мб, а в WebM - 4,5 Мб, при полностью одинаковом качестве получившегося видео.Ой не смеши. До сих пор сами разработчики x264 спорят со страшной силой улучшилось ли качество картинки при добаылении психовизуальных оптимизаций, можно ли ставнивать квчество видеопотока по отдельным кадрам, стоит ли доверять стввнению PSNR или даже SSIM и так далее. И это при настоящих слепых тестах (кто то выкладывает серию видеофрагментов без подписчи какими опциями сжато а остальные должны угадать). Банально кому то нравится больше теплое ламповое сглаживание артефактов кодировщика WebM, ктото прется от высокочастотного шума ошибок на x264 думая что это и есть детали изображения.
Я вот так же скажу :
В лучшем качестве (я кодировал несколько видео с разной динамикой и длинной) в среднем в Webm получалось например 3 Мб, а в x264 - 4,5 Мб, при полностью одинаковом качестве получившегося видео.
Единственно где x264 гарантировано уделывал первые версии WebM это рипы длиннющих ворованых фильмов, в режиме нарушающем стандарт то есть при допущении любых вариаций потока без ограничений что можно распаковать только на топовом железе и никакая встроеная железка не проглотит. Подозреваю что
>За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа;
и есть эта самая фишка, раньше пишут что в начале клипа было слишкомхорошее качество а к концу соответственно ниже среднего.
> Подозреваю что
>>За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа;
> и есть эта самая фишка, раньше пишут что в начале клипа было слишкомхорошее качество а к концу соответственно ниже среднего.Кстати, о том же подумал. Помню, в первых версиях писали об ошибке распределения битрейта, который вычисляется в первом проходе, по фильму во втором проходе, сдвиг по времени там что ли какой-то был, который весь профит от первого прохода сводил на нет.
Сразу видно грамотного собеседника> в режиме нарушающем стандарт то есть при допущении любых вариаций потока без ограничений что можно распаковать только на топовом железе и никакая встроеная железка не проглотит
Просьба не путать валидный битовый поток с ограничениями профайлов.
> За счет использования улучшенного двухпроходного режима контроля интенсивности потока достигнут более постоянный высокий уровень качества для всего видео клипа
Двухпроходное кодирование используется для попадания в размер, а не для улучшения качества.
> Двухпроходное кодирование используется для попадания в размер, а не для улучшения качества.В том числе и для улучшения качества, выделяя из среднего битрейта ту дозу, которая требуется для конкретного кадра и уменьшая его для того кадра, где большой не требуется.
Да полно вам. Кодировщику вполне достаточно выделяемого буфера для хранения и обсчета опорных кадров.
> Да полно вам. Кодировщику вполне достаточно выделяемого буфера для хранения и обсчета
> опорных кадров.В выделяемый буфер особо много кадров не положишь - посчитайте размер одного кадра HD видео. И скажите сколько их таких вы готовы закешировать для анализа "в будущем"? Оператива то не резиновая, а кодек не единственная программа на компе, вы прикиньте?! А при 2-проходном кодировании вы наперед знаете сложность ВСЕХ сцен в будущем (по логу первого прохода) - можно принимать решение о выделении битов уже "заранее" зная что подсунут, так что кодек куда точнее может оценить сколько битов куда раскинуть следует, не проявляя необоснованного пессимизма который в 1-проходном режиме неизбежен чтобы избежать длительного многократного превышения желаемой скорости которое вызовет опустошение буфера и срыв воспроизведения (для онлайн видео сие как бы весьма и весьма актуально).
> Просьба не путать валидный битовый поток с ограничениями профайлов.Да, только вот железок способных прожевать ЛЮБОЙ битовый поток, включая high профайл на этой планете не так уж много. А большая часть согласны жрать лишь базовый профайл, особенно этим грешат мобильные девайсы. А у базового профайла качество - вполне сравнимо с VP8, так что гугл весьма грамотно подсуетился и правильно нагнул распоясавшихся MPEG LA. А то они совсем оборзели - вплоть до изменения условий лицензирования задним числом.
> Двухпроходное кодирование используется для попадания в размер, а не для улучшения качества.Оно позволяет при равном размере файла получить более хорошее качество картинки. При одном проходе есть довольно противная проблема: кодек не знает что ему подсунут через N кадров в будущем, насколько сцена будет сложна в кодировании и какой резерв битов на самом деле у него есть на момент кодирования текущего кадра. Это вынуждает кодек проявлять некий пессимизм чтобы избежать ситуации "полчаса подряд битрейт был в 3 раза выше изначально желаемого среднего битрейта - буфер постоянно опустошался, юзер чертыхался". В случае 2-проходного кодирования кодек знает сложность сцен в будущем и может куда более точно оценить куда и сколько битов оптимальнее было бы выделить, что ессно способствует более качественной картинке - "добавочные" биты более точно попадают в сцены которые в них нуждаются, что хорошо влияет на отсутствие видимых артефактов в этих сценах :)
> при полностью одинаковом качестве получившегося видеоА чем сравнивал, глазами?
Инопланетяне на форуме! А ты чем смотришь?
это он 20й-раз рассказывает свою иссторию о том как он сначало закодировал видио из рабочего стола (баги программы Wine) в какойто-MPEG-формат хорошего качества (НО С ПОТЕРЯМИ!) ,, а потом перекодировал это: в WebM/Vp8 и H.264
и в WebM/Vp8 -- получилось размера больше (оно и ясно -- перекодировка всётаки играет свою роль)
> видиоВидио? Ты не поверишь, но у меня дневник есть, и я туда выкладываю видЕо с тэгом <video>.
>Ты не поверишь, но у меня дневник естьЯ верю. =)
Глазами конечно. Вот например Theora сльно напоминает WMV с одинаковым битрейтом, а WebM - h264, но при одинаковом качестве размер файла чуть больше.
Скорость кодирования/декодирования не замерял?
И откуда источники видео первоначально были сняты (камера, тв)
и в каком формате yuv420 или yuv422?
yuv420, Web-камера + с экрана монитора спецпрограммой. Скорость кодирования не замерял, субъективно WebM заметно быстрее кодирует.
> а WebM - h264, но при одинаковом качестве размер файла чуть больше.У webm артефакты какие-то другие. Менее заметные чем "звон" вокруг четких границ и квадратики типичные для мпега на мою имху. У VP8 картинка просто становится более размытой, но квадратиков практически не видно, в отличие от. Кстати понравиолсь что гугловцы грамотно твиканули кодирование переходов между сценами.
>скорость кодированияВсё же это не совсем правильный термин.
За год они даже близко не приблизились к показателям DivX.
Xvid больше нравиться. И по качеству и по стабильности.
Тем более.
> За год они даже близко не приблизились к показателям DivX.А что есть DivX? Если вы про простые MPEG4 кодеки с данным названием - то vp8 уже давно на его уровне и даже получше, пожалуй, на нежатом контенте. Если вы про DivX Plus который H.264 в матрешке - так там от дивикса только название и осталось, пожалуй, а проблемы все те же что и у H.264 как то - без геморроя и не заплатив юзать его данный формат можно сильно местами, там где у США и мпеглы руки коротки :)))