Комментарии 38
Оставьте деблокинг деблокингом, пришлось смотреть оригинал, чтобы понять, что имеется в виду под «фильтром артефактов кодирования».
Молодцы. Но свежий mplayer заикается на втором файле (который sintel). Ещё пилить и пилить.
… учитывая неполность официальной спецификации. Многие части спецификации вообще были неправильными и противоречили коду…
В начале 21-ого столетия в психиатрии произошло открытие нового заболевания, распространявшегося небывалыми темпами, опережавшими депрессию: «венда головного мозга» — врачи бьют тревогу.
Энциклопедия истории психиатрии. Том 1024. Июль 2210 год.
Термин «saturation» не надо переводить как «насыщенность цвета». Он в данном контексте к цвету не имеет отношения.
Автор про обычную арифметику с насыщением говорил, когда int8(150) + int8(150) == 255
Автор про обычную арифметику с насыщением говорил, когда int8(150) + int8(150) == 255
Ждём ответа от Гугла)
Выйдут дрова Ati Catalyst 10.7 буду тестить DXVA2 в VLC 1.1.1
Посмотрим поближе, пока собрал ffmpeg из svn, понаблюдаем.
Вообще конечно данная новость напоминает о том, что переход на html5 будет еще не таким быстрым, как хотелось, т.к. очень медленно стандарты устаканиваются, появляются новые инструменты кодирования (енкодеры), развиваются браузеры.
Наверное еще пройдет года два пока можно будет на HTML5 переходить веб-хостингам, а то так настроишь кодирование видео через кодек X для перегонки в формат Y, который поддерживает RANDOM из N браузеров, а потом появляется кодек Z и все начинай сначала…
Но безусловно радует, что уже что-то начинает вырисовываться, год назад еще все было довольно печально.
Наверное еще пройдет года два пока можно будет на HTML5 переходить веб-хостингам, а то так настроишь кодирование видео через кодек X для перегонки в формат Y, который поддерживает RANDOM из N браузеров, а потом появляется кодек Z и все начинай сначала…
Но безусловно радует, что уже что-то начинает вырисовываться, год назад еще все было довольно печально.
Правильно ли я понял, что ffvp8 был сделан при участии автора x264?
Собственно, это он x264dev.multimedia.cx/?page_id=2
ну он не автор, а один из основных ментейнеров, насколько я знаю.
А пиписка у линуксах на графиках нефигово длинная, завидую
На адекватность не претендую, но у меня вышло такое на четырехядерника, x86-64, Debian:
libvpx — 29s
vp8 — 4.7s
0_o
Конечно одного замера мало, но больше мне делать лень, тут врядли что-то поменяется, удивляет только разрыв, полученный у меня в 4 раза.
Видео взял первое попавшееся, в mp4
libvpx — 29s
vp8 — 4.7s
0_o
Конечно одного замера мало, но больше мне делать лень, тут врядли что-то поменяется, удивляет только разрыв, полученный у меня в 4 раза.
Видео взял первое попавшееся, в mp4
Intel, AMD? А то в заметке тесты на исключительно Intel'овских процессорах, может быть, на AMD'шных ffvp8 ведет себя лучше?
Под mp4 Вы контейнер имеете в виду? Вряд ли он существенно влияет.
Под mp4 Вы контейнер имеете в виду? Вряд ли он существенно влияет.
да, контейнер, подразумевая, что внутри x264
AMD, забыл уточнить. Скорее всего вы правы — на AMD производительнее выходит.
AMD, забыл уточнить. Скорее всего вы правы — на AMD производительнее выходит.
Стоп. Я теряю нить. Внутри — x264? Тогда причём тут декодеры для потока VP8?
«перегоняем» из x264 в webm. По сути идиотский тест, о чем я изначально и сказал, но разница удивляет даже на таком простом случае.
А, всё, въехал :)
Нормальный тест при соблюдении равных условий, в связи с чем вопрос: а декодирование 264 точно шло одним и тем же декодером?
Нормальный тест при соблюдении равных условий, в связи с чем вопрос: а декодирование 264 точно шло одним и тем же декодером?
Я не делал несколько тестов, сделал по одному на каждый из предлагаемых — libvpx и vp8
Кстати, интересный момент. VLC 1.1.1 падает на sintel_trailer. Причем внутри VLC 1.1.1, по идее, ещё libvpx, а не ffvp8. Интересно, беда — в либе, или в VLC?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Представляем самый быстрый декодер VP8 в мире: ffvp8