Разработчик проекта x264, ранее опубликовавший (http://www.opennet.me/opennews/art.shtml?num=26658) критическую статью, в которой был проведен анализ недостатков открытого компанией Google видеокодека VP8, представил (http://x264dev.multimedia.cx/?p=499) обзор текущего состояния альтернативной свободной реализации декодера VP8 - ffvp8, подготовленной (http://www.opennet.me/opennews/art.shtml?num=27126) в рамках совместной работы участников проектов FFmpeg и x264. Тестирование производительности показало заметное преимущество кода ffvp8, способного выдать на современных процессорах примерно на 30% больше кадров в секунду при показе видео с разрешением 1080p.
<center><img src="http://www.opennet.me/opennews/pics_base/27425_1280053352.jp... style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></center>
Небольшой отрыв в скорости на процессорах Atom объясняется тем, что разработчики ffvp8 еще не приступили к оптимизации производительности для этого...URL: http://x264dev.multimedia.cx/?p=499
Новость: http://www.opennet.me/opennews/art.shtml?num=27425
во жгут ребята..
респект..
Суровые мужики показали как нужно работать:)
Гыы, Мак при более мощьном проце, выдаёт более низкие показатели) Что очередной раз подтверждает уже и без того, подтверждённую теорию "платно - не значит качественно".
Где Вы это увидели?
Как бы, на диаграме, которая красуется наверху, в этой новости.
Как бы на диаграмме C2D под макосью обошел более крутой i7.
i5 - камень как бы тоже другого уровня.
> i5 - камень как бы тоже другого уровня.А вон там рядом с атомом уж не мак ли? И производительность почти как у атома несмотря на кор :). Еще напрашивается вывод что интел конкурирует сам с собой. Или какого фига i5 натягивает с аццким отрывом i7? Сие как-то не дружит с позиционированием интеля что выводок i5 - это такой удешевленный i7 :)
"Оптимизация ещё в работе" как бы намекает, что где-то не эффективно используется распаралеливание (и7 имеет меньше частоту, хоть и болше ядер/потоков) и кеш.
В данном случае у i7 частота в полтора раза меньше, так что неудивительно.Впрочем, что интел в линейки процов заигрался - согласен.
А на индекс посмотреть, не? QM. Это мобильный. У него занижена частота, может ещё что-то не то, см. спеки.
>А на индекс посмотреть, не? QM. Это мобильный.Это на две буквы больше, чем нужно пользователю АМД. :->
>Это на две буквы больше, чем нужно пользователю АМД. :->Судя по чертыханиям в коментах на сайте x264dev - я не один такой кто не понимает юмора с такими именованием серий процов :P.
Если смотреть на индекс, то такого процессора вобще не существует :)
Вот все мобильные камни http://ark.intel.com/ProductCollection.aspx?familyID=43402&M...
Процессора с индексом 620QM там нет. Поиск по сайту ничего не дал.
Чего там ребята тестировали – хз
Тестировали на i7-720QM с включенным турборежимом.
http://x264dev.multimedia.cx/?p=499#comment-5792
> У него занижена частота, может ещё что-то не то, см. спеки.А теперь попробуйте объяснить юзерам что "вон тот i7 - это, дескать, карманный вариант героя, поэтому он дескать проигрывает даже удешевленной версии героя" :).Удачи в этом начинании.
>>>А вон там рядом с атомом уж не мак ли? И производительность почти как у атома несмотря на кор :)Ну и что? Рядом тоже мак и производительность на уровне. Сейчас это ни о чем не говорит.
По диаграммам я вижу только одно – слабая оптимизация кодека. Причем ощущение, что оптимизировали на одной-двух железяках с расчетом, что этого хватит на весь спектр процессоров.>>>Еще напрашивается вывод что интел конкурирует сам с собой.
Так и есть. Особенно это видно в нижнем сегменте.
На самом деле скорей всего никто не ждет качества от платных продуктов (точнее его ждут от всех стабильных продуктов). От платных продуктов скорее ждут ответственности. Обычно эта ответственность оплачивается деньгами и закрепляется юридически - договором.В бесплатных продуктах от ответственности могут отказываться. Так что ИМХО теорию "платно - не значит качественно" подтверждать и не надо.
>На самом деле скорей всего никто не ждет качества от платных продуктов
>(точнее его ждут от всех стабильных продуктов). От платных продуктов скорее
>ждут ответственности. Обычно эта ответственность оплачивается деньгами и закрепляется юридически -
>договором.
>
>В бесплатных продуктах от ответственности могут отказываться. Так что ИМХО теорию "платно
>- не значит качественно" подтверждать и не надо.Хмм... Если что-то не так работает в платном продукте, это не значит, что производитель обязуется это исправлять. Кроме слуечаев, если у Вас прямые крупные договора (как у МС и ХП). А их можно пересчитать по пальцам (ну ноги, возможно, понадобятся).
В остальном уровень ответственности у бесплатных продуктов порой выше, ввиду, зачастую, более прозрачной возможности общения с разработчиком(упрощённый бюрократический аппарат).
Так в юзерской лицензии того же микрософта написано, что компания не несёт ответственности за любой ущерб, причинённый софтом. Более того, не гарантирует что работа софта соответствует ожиданиям пользователя. Хоть эти самые ожидания и возникают в процессе чтения рекламы. ;-)Уж не такой ли ответственности ждут от проприетарного софта?
Возьмите тот же Ред Хат: софт свободный (качай бесплатно с оф. сайта), договор - на обслуживание. Юридическая ответственность за поддержку есть, с софтом делай что хочешь (в рамках GPL). По-моему схемка гораздо приятнее.
Я это с самого начала и имел ввиду) Что приятнее пользоваться свободным ПО, а поддержку если надо - прикупить. Чем купить ПО, неизвестно какие баги в нём встретишь, неизвестно как их исправлять или писать подробный отчёт о них, и неизвестно вообще через сколько лет обновят его с исправлением. Потом тупо несёшь все балванки с платным ПО в мусорный ящик) ну или rm -rfЯ тут не конкретно о Яблочниках или М$-дае говорю, а вообще в целом. Это относится и к платным и закрытым движкам/cms сайтов, и о платной и закрытой телефонной платформе, и о всяких прошивках к мобильным устройствам, и причём всё, что делается на базе открытого ПО, закрывается и продаётся - в некачественном виде.
PS перечислил то, с чем мне приходилось сталкиваться и на что плеваться %)
Dark Shikari респект
Хорошее дело делают люди
Всегда их уважал, и теперь они не разочаровали!
Вот это правильно.
Так и должно быть: открытая спецификация и свободные реализации.
>Так и должно быть: открытая спецификация и свободные реализации.ага ага ознакомься с сабжем
открытая спецификация не совпадает (!) с референсным кодеком
гугл-вей
>>Так и должно быть: открытая спецификация и свободные реализации.
>
>ага ага ознакомься с сабжем
>открытая спецификация не совпадает (!) с референсным кодеком
>гугл-вейНу, тут на гугл валить не стоит. Явно это не их вина, а еще On2. А гугл поступил как праз правильно - в максимально короткие сроки выкатил WebM - хоть какой, но есть. И теперь параллельно идут его допиливание и встраивание в браузеры. Иначе все дружно жрали бы h264.
>Ну, тут на гугл валить не стоитОткуда столько любви к этой мерзкой конторке?
>Явно это не их вина, а еще On2
On2 практически нет, а "спецификацию" гугель обубликовал спустя многие месяцы после покупки. Запрет исправления багов!!!! - сугубо их вина.
>А гугл поступил как праз правильно - в максимально короткие сроки выкатил WebM
И кому он нужен, простите, этот ваш webm? Все как юзали h.264 и xvid, так и юзают.
И кому он нужен, простите, этот ваш firefox? Все как юзали IE, так и юзают.
>И кому он нужен, простите, этот ваш firefox?Пропал бы он завтра - даже не заметили бы. Опера рулит, а хром подруливает.
> Например, когда результат "a-b", где переменные "a" и "b" могут попадать в
> диапазон от -255 до +255, является отрицательным, требуется привлечение
> дополнительного девятого знакового битаМне кажется, или здесь действительно ошибка ? Если а и б в указанных пределах то они и так уже 9 битовые.
Перевод, как обычно, жжот.
> A simple example in the case of x86 is abs(a-b), where a and b are 8-bit unsigned integers. The result of “a-b” requires a 9-bit signed integer (it can be anywhere from -255 to 255), so it can’t fit in 8-bit.Простой пример в случае для архитектуры x86: abs(a-b), где a и b это 8-битные без-знаковые целые значения. Результат вычисления "a-b" требует 9-битное число со знаком (может быть на промежутке от -255 до 255) и таким образом не может вместиться в 8 бит.
Т.е. значения a и b попадают в диапазон от 0 до 255, а вот их разница...
0 - 255, Сколько будет?Правильно - 11111111 + знаковый бит.
Кстати, там ещё рассказывается про операцию satsub, которая здесь лишь указана. Она возвращает разницу если она положительна и 0 если разница отрицательна. После вычисления a-b и b-a для значений выполняется операция or (или), которая и возвращает не нулевое значение если оно там есть.
Не видно результатов для процессоров AMD.
Троллям советую аргументировать свои претензии к АМД, а не голословно высказываться.
>Не видно результатов для процессоров AMD.не помешали б, но для определения динамики и этого достаточно. Они ж сравнивают не производительность процов, а разницу в работе кодеков.
На самом деле всё вообще может быть гораздо быстрее чем оно есть. Я в этом окончательно уверился увидев как на моей системе (старенький ноут с видео Intel 82852/82855, которая даже ни про какие шейдеры ничего не знает) летает Enlightenment e17 со всеми эффектами и, самое чудесное, как на ней играется видео командой "mplayer -vo x11 %F"- наприемер при проигрывании FLV (проигрывание которого в браузере "как положено" жрёт 100% CPU) проц (при полностью софтовом декодировании и воспроизведении) загружен всего на 4% и при этом, внимание!, даже к самому видео без всякой запинки применяются эффекты композиции (прозрачность) в любых наслоениях!
Это вы о чем сейчас? "Реклама моего домашнего компа"?
>Это вы о чем сейчас? "Реклама моего домашнего компа"?Основная мысль какбы в первом предложении, а дальше иллюстрация.
>>Это вы о чем сейчас? "Реклама моего домашнего компа"?
>
>Основная мысль какбы в первом предложении, а дальше иллюстрация.+1 и 100500
>На самом деле всё вообще может быть гораздо быстрее чем оно естьМысль философская, ничего не скажешь.
>самое чудесное, как на ней играется видео командой "mplayer -vo x11 %F"-Посмотрите сколько % проца при этом кушает только вывод на экран. А если HD подсунуть? Половина проца уйдет на чисто вывод видео на экран :). Посему вас думается еще ждут сюрпризы по обнаружению того что это не предел и с акселерированным выводом видео можно еще больше :)
>наприемер при проигрывании FLV (проигрывание которого в браузере "как
>положено" жрёт 100% CPU) проц (при полностью софтовом декодировании и воспроизведении)У флеша удивительно тормозной вывод видео на экран. Связано сие с тем что как я понимаю, вывод декодера должен комбинироваться с картинкой нагенеренной остальным флешом. Ессно сие аццки тормозит.
>загружен всего на 4%Наверное это был мувик 320х240 на интернетовском битрейте. Такое извините даже дохлый ARM на 400МГц декодирует...
>и при этом, внимание!
Какой восторг. Человек только что обнаружил что флеш - тормозилово :)
>У флеша удивительно тормозной вывод видео на экран. Связано сие с тем
>что как я понимаю, вывод декодера должен комбинироваться с картинкой нагенеренной
>остальным флешом. Ессно сие аццки тормозит.В этом и прикол, от это меня и поразило, что если включить прозрачность, сквозь играющееся в mplayer видео видно то, что под ним. Причём можно открыть насколько mplayer-ов и расположить друг над другом, и видео в них будет играться и комбинироваться. И при этом нагрузка на проц копеечная. А если смотреть тот же видеоклип в браузере, то нагрузка на проц 100%.