Pull to refresh

Comments 38

Оставьте деблокинг деблокингом, пришлось смотреть оригинал, чтобы понять, что имеется в виду под «фильтром артефактов кодирования».
Молодцы. Но свежий mplayer заикается на втором файле (который sintel). Ещё пилить и пилить.
А вы используете mplayer с ffmpeg из svn? Может быть, там эти ошибки уже исправлены?
… учитывая неполность официальной спецификации. Многие части спецификации вообще были неправильными и противоречили коду…

В начале 21-ого столетия в психиатрии произошло открытие нового заболевания, распространявшегося небывалыми темпами, опережавшими депрессию: «венда головного мозга» — врачи бьют тревогу.

Энциклопедия истории психиатрии. Том 1024. Июль 2210 год.
Термин «saturation» не надо переводить как «насыщенность цвета». Он в данном контексте к цвету не имеет отношения.

Автор про обычную арифметику с насыщением говорил, когда int8(150) + int8(150) == 255
Ага. И тут
> где «satsub» вычисляет разницу насыщенности между двумя значениями.
следует писать «насыщенную разность» или «разность с насыщением».
Выйдут дрова Ati Catalyst 10.7 буду тестить DXVA2 в VLC 1.1.1
Посмотрим поближе, пока собрал ffmpeg из svn, понаблюдаем.
Вообще конечно данная новость напоминает о том, что переход на html5 будет еще не таким быстрым, как хотелось, т.к. очень медленно стандарты устаканиваются, появляются новые инструменты кодирования (енкодеры), развиваются браузеры.

Наверное еще пройдет года два пока можно будет на HTML5 переходить веб-хостингам, а то так настроишь кодирование видео через кодек X для перегонки в формат Y, который поддерживает RANDOM из N браузеров, а потом появляется кодек Z и все начинай сначала…

Но безусловно радует, что уже что-то начинает вырисовываться, год назад еще все было довольно печально.
Правильно ли я понял, что ffvp8 был сделан при участии автора x264?
ну он не автор, а один из основных ментейнеров, насколько я знаю.
А пиписка у линуксах на графиках нефигово длинная, завидую
Там пиписька не и линухов, а у процессора.
+ «ffvp8 значительно быстрее libvpx, в особенности, на 64-битных платформах.»
FinikWasHere видимо имеет ввиду, что по сравнению с виндой.
На адекватность не претендую, но у меня вышло такое на четырехядерника, x86-64, Debian:

libvpx — 29s
vp8 — 4.7s

0_o

Конечно одного замера мало, но больше мне делать лень, тут врядли что-то поменяется, удивляет только разрыв, полученный у меня в 4 раза.

Видео взял первое попавшееся, в mp4
Intel, AMD? А то в заметке тесты на исключительно Intel'овских процессорах, может быть, на AMD'шных ffvp8 ведет себя лучше?

Под mp4 Вы контейнер имеете в виду? Вряд ли он существенно влияет.
да, контейнер, подразумевая, что внутри x264

AMD, забыл уточнить. Скорее всего вы правы — на AMD производительнее выходит.
Стоп. Я теряю нить. Внутри — x264? Тогда причём тут декодеры для потока VP8?
«перегоняем» из x264 в webm. По сути идиотский тест, о чем я изначально и сказал, но разница удивляет даже на таком простом случае.
А, всё, въехал :)

Нормальный тест при соблюдении равных условий, в связи с чем вопрос: а декодирование 264 точно шло одним и тем же декодером?
Я не делал несколько тестов, сделал по одному на каждый из предлагаемых — libvpx и vp8

Т.е. условия были равные? А чем, все-таки, декодировался 264-поток?
Условия были равные. Что вы имеете ввиду под «чем декодировался 264-поток»?
Ну, чтобы пережать H.264 в VP8, нужно:
— распаковать поток H.264 в RAW видео
— запаковать RAW видео в поток VP8

не знаю, за меня всем этим занимался ffmpeg, я ему только задал кодек, которым мне нужно запаковать результирующее видео.
Всё, ситуацию понял. Значит, ffmpeg'овский h264-декодер работал в обоих случаях. Значит, результат можно считать честным.
Кстати, интересный момент. VLC 1.1.1 падает на sintel_trailer. Причем внутри VLC 1.1.1, по идее, ещё libvpx, а не ffvp8. Интересно, беда — в либе, или в VLC?
Хм, да он и на parkjoy падает! Ну, дела!
AMD A64x2 4200+, WinXP32
А вот MPC HC svn 2152 (в котором уже есть ffvp8) — играет, и на приемлемой скорости. Athlon 64 X2 4200+, XP32.

(offtopic) Качество картинки, к слову, весьма приятное. Впрочем, 3d жмётся, конечно, лучше чем реальные съемки. (/offtopic)
А если отключить встроенный кодек MPC, и играть через последний ffdshow, включив буферизацию кадров на выходе, Sintel вообще играет плавно и без тормозов. Железо то же. А вот parkjoy уже не тянет.
Only those users with full accounts are able to leave comments. Log in, please.