mplayer не умеет декодировать h.264 в несколько потоков? (1080 видео конретно тормозит)

[tull]

Удачи со сборкой. Сюзи тоже не предназначена для компиляции.

правда?! вот интересно, из чего же вы такой вывод сделали? чего же это в suse не хватает для компиляции?
а это ничего, что я на своей рабочей машине (opensuse 10.3) много чего компилировал? включая mplayer из снэпшотов

Kido,
а зачем чего-то там пихать в rpm, если в данном случае достаточно просто заменить /usr/bin/mplayer на новый?

[Denjs]

Удачи со сборкой. Сюзи тоже не предназначена для компиляции.

<_< оппа, приехали...
выискался блин сын балмера, внук бармалея, любитель линуXP, потомок лейтенанДа шмиДта в 4-м колене, ...
>>
уберите кто-нибудь двоечников от экранов ?
:-)))

[sspphheerraa]

Let's floods begin!?
/Suse это RPM-based дистрибутив. И компилить в ней имхо все равно, что забивать гвозди микроскопом.

выискался блин сын балмера, внук бармалея, любитель линуXP, потомок лейтенанДа шмиДта в 4-м колене, ...

Переходим на личности, Уважаемый?

[tull]

Suse это RPM-based дистрибутив. И компилить в ней имхо все равно, что забивать гвозди микроскопом.

насчет микроскопа это не более, чем ваше имхо.
вы не могли бы КОНКРЕТНО указать, чем SUSE плоха для компиляции вообще и компиляции Mplayer в частности (я когда компилировал, проблем не заметил).
я спрашиваю не в порядке возможного спора, мне как ламеру в линухе просто любопытно (я вообще линух никогда не любил, и поэтому им не пользовался, тем более на настольных системах)

з.ы. вот свинство - дистриб suse 11, который мне привезли, оказался битым
и, кстати, я пробовал mythbuntu 64 bit, разницы в скорости mplayer не заметил

[Gloomy]

разницы в скорости mplayer не заметил

Разумеется, ведь MPlayer в нем старый и в бинарном виде.

[tull]

Разумеется, ведь MPlayer в нем старый и в бинарном виде.

т.е. вы хотите сказать, что разницу в скорости на 32 и 64-битной системе можно почувствовать только после пересборки?

ок, а как вы объясните такой факт. 32-битная система. mplayer в комплекте RC2.
собираю из сегодняшнего снэпшота.
работает на 2-3% МЕДЛЕННЕЙ!
т.е. даже не прибавка скорости, а замедление!

вобщем туфта все это, что пересборка из снэпшота увеличивает производительность... только потерял кучу времени на совершенно бессмысленные эксперименты...

[Gloomy]

т.е. вы хотите сказать, что разницу в скорости на 32 и 64-битной системе можно почувствовать только после пересборки?

Именно. Потому что и на 32, и на 64 бита:
а) бинарник MPlayer собран универсально, под любое железо;
б) старее чем SVN;
Поэтому на бинарниках разница в скорости между 32 и 64 бита вряд ли будет превышать заметную на глаз величину. А вот ручная сборка - совсем другое дело.

работает на 2-3% МЕДЛЕННЕЙ!

Каким образом настолько точно измерена разница, да еще столь незначительная? Чесслово очень интересно, т.к. может послужить методикой для оценки и тестирования.

ок, а как вы объясните такой факт

Объясняю: SVN. Объясняю развернуто: перед тем как была скачана рабочая копия, кто-то из разработчиков внес поправки, отрицательно влияющие на производительность. Я сам наступал на аналогичные грабли, когда вдруг куда-то подевалась поддержка x264, хотя до этого программа всегда собиралась идеально. Подождал пару дней и собрал снова - все вернулось на круги своя.

[Denjs]

Suse это RPM-based дистрибутив. И компилить в ней имхо все равно, что забивать гвозди микроскопом.

ну это не более чем ваше имхо. и имхо - не верное.
например найдите rpm для php4 для SLES10. а мне надо было. тех поддержка новела так и сказала - не будет и не ждите.
потом пришлось ещё и mysql пересобрать кажется. и это не забивание гвоздей микроскопом - это нормальная рабочая ситуация.

С другой стороны - как вы создавать RPM будете если компиляция - это "забивание гвоздей микроскопом" ?
вы все равно должны собрать бинарник, и потом упаковать в RPM.
и на самом деле все только для того что бы использовать преимущества менеджера пакетов RPM и иметь возможность "чистой" деинсталляции. некоторые так и поступают но далеко не все. например я - не собираюсь даже думать о том что бы деинсталлировать mplayer и мне эти преимущества нафиг нужны в данном случае.

С третьей стороны - как вы объясните назначение по факту существующих RPM пакетов с исходниками? их задача - "создавать ситуацию забивания гвоздей микроскопом"?

RPM - не более чем способ контроля установленных пакетов. хороший, удобный, приятный. но не более.
и он никак не мешает сборке и установке программ из исходников.
SUSE одинаково хорошо поддерживает оба способа установки и запуска ПО.

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

[tull]

т.е. вы хотите сказать, что разницу в скорости на 32 и 64-битной системе можно почувствовать только после пересборки?

Именно. Потому что и на 32, и на 64 бита:
а) бинарник MPlayer собран универсально, под любое железо;
б) старее чем SVN;
Поэтому на бинарниках разница в скорости между 32 и 64 бита вряд ли будет превышать заметную на глаз величину. А вот ручная сборка - совсем другое дело.

гыыыы!
а в жизни все оказалось совсем не так.
более внимательно посмотрев, я увидел, что 64-битный mplayer работает почти на 10% быстрее.
проверялось на 32-битной mythdora (fedora) и 64-битной mythbuntu (ubuntu). на обоих системах mplayer rc2, с автоопределением типа проца.

Каким образом настолько точно измерена разница, да еще столь незначительная? Чесслово очень интересно, т.к. может послужить методикой для оценки и тестирования.

да элементарно, ватсон! что может быть проще-то?!
запускаю фильм, ставлю более-менее сложный момент (ессно всегда один и тот же; и ессно я запускаю mplayer с одинаковыми параметрами). дальше вывожу терминал вперед, и смотрю какая загрузка. делаю это на 2-3 фильмах, на одних и тех же эпизодах.

как результат этих измерений -
mythdora 32 бит, mplayer rc2 дает на конкретном эпизоде загрузку 76-78%, а собранный вручную - 78-80%
mythbuntu 64-bit, mplayer rc2 на этом же эпизоде дает 70-73%
я, к сожалению, не могу пока проверить вариант самосборного mplayer на 64-битной системе. на mythbuntu фиг соберешь. а 64-битная suse у меня появится только к концу недели. но я чего-то уже заранее уверен в результате...

Объясняю: SVN. Объясняю развернуто: перед тем как была скачана рабочая копия, кто-то из разработчиков внес поправки, отрицательно влияющие на производительность. Я сам наступал на аналогичные грабли, когда вдруг куда-то подевалась поддержка x264, хотя до этого программа всегда собиралась идеально. Подождал пару дней и собрал снова - все вернулось на круги своя.

это мне конечно приходило в голову. но каждый день качать и проверять я не готов...

и плиз насчет поддержки x264 можно чутка подробней. вы про
--disable-x264 disable x264 [autodetect] ?
у меня он получается выключенный, а если сделать --enable-x264, то когда make делаешь, вылетает с ошибкой.


Denjs,
вы выше писали:

пересобрал. итог : тот-же мувик - нагрузка на проц упала до 2-х раз

вы можете мне дать этот бинарник? а еще лучше собрать под 64-битную систему? я оччччень хочу посмотреть, как загрузка упадет "до 2-х раз".
это бы в принципе решило все мои проблемы. потому что на данный момент, разогнав комп до 2820 МГц (я поставил проц на 2400, и увеличил частоту шины с 200 до 235), я все равно имею тормоза на некоторых особо тяжелых сценах. даже с -lavdopts skiploopfilter=all:lowres=1:fast. точнее не тормоза, а отставание картинки.


кстати, я вот чего еще не понимаю. все нормально воспроизводится только когда загрузка проца до 70-75%
а вот когда 80 и выше, то появляется отставание звука. я-то был уверен, что все, что до 100% - это должно быть нормальное воспроизведение. а фиг...
я ессно использую -autosync, но я вообще не понял, на что он влияет. пробовал и 30, и 100, и 300.

и мне тут еще одна мысль в голову пришла - я ведь звук пускаю по s/pdif на внешний процессор. может можно как-то отключить декодирование звука mplayer'ом? это по идее даст чутка снижения нагрузки (правда видимо совсем чуть-чуть)

[Gloomy]

64-битный mplayer работает почти на 10% быстрее

Сегодня на ЛОРе очень кстати подвернулась ссылочка на тестирование производительности систем 32 vs 64 бита. К большому сожалению тестировали только Bubuntu, Fedora и OpenSUSE, но результаты все равно интересные. Со своей стороны их подверждаю.

вывожу терминал вперед, и смотрю какая загрузка

А попутно оценить качество декодирования мысль не приходила? Ведь растет не только скорость, но и качество картинки, и плавность воспроизведения. Так что повышение загрузки проца вполне может быть вызвано этими аспектами. Игры оценивают по FPS, а вот как же оценивать видео?

--disable-x264 disable x264 [autodetect]

Оно самое. Для поддержки x264 в системе должна быть установлена одноименная библиотека. Если MPlayer ее не находит даже при явном указании пути - значит грабли в ревизии SVN. И стоит попробовать откатиться на пару-тройку ревизий назад.

может можно как-то отключить декодирование звука mplayer'ом

Да, это тоже хорошая идея:

Код: Выделить всё

mplayer -afm hwac3
или
mplayer -afm hwac3 -ao alsa:device=spdif

(не уверен какой вариант правильный т.к. не юзаю S/PDIF, стоит попробовать оба)

вы можете мне дать этот бинарник

Если что, мой бинарник тут (3 Мб).
Зависимости:

Код: Выделить всё

libxxf86dga   libxv   libmad   libungif   cdparanoia   sdl   lame   libtheora   xvidcore   libgl  smbclient   aalib   jack-audio-connection-kit   x264>=20080625   faac   lirc-utils   ttf-dejavu

Оптимизировано под AMD Athlon 64 X2.

[tull]

А попутно оценить качество декодирования мысль не приходила? Ведь растет не только скорость, но и качество картинки, и плавность воспроизведения.

конечно не приходило. потому что я далек от мысли, что mplayer может динамически менять качество декодирования в зависимости от загрузки проца. при загрузке до 70-75% проблем нет никаких, при 80% и больше начинает отставание видео от звука.
значит до 70% с плавностью и т.п. все в порядке.
подчеркиваю, что при сравнениях я запускаю mplayer с идентичными параметрами.

а вот как же оценивать видео?

глазами, как же еще?!

Для поддержки x264 в системе должна быть установлена одноименная библиотека. Если MPlayer ее не находит даже при явном указании пути - значит грабли в ревизии SVN.

я когда еще с 32-битной mythbuntu мульковал, ставил libx264-dev_0.svn20071224-0.0ubuntu1_i386.deb и x264_0.svn20071224-0.0ubuntu1_i386.deb. но пути правда не указывал.
это оно, или надо что-то другое?
и что дает эта бибилотека? у меня ведь и так h.264 видео вопроизводится.


звук отключить попробую, напишу тогда результаты

Если что, мой бинарник тут (3 Мб).
Зависимости:

Код: Выделить всё

libxxf86dga   libxv   libmad   libungif   cdparanoia   sdl   lame   libtheora   xvidcore   libgl  smbclient   aalib   jack-audio-connection-kit   x264>=20080625   faac   lirc-utils   ttf-dejavu

Оптимизировано под AMD Athlon 64 X2.

я так понимаю, на 64-битной системе собиралось? сейчас буду пробовать.
а alsa там нет? вообще через чего правильней всего выводить звук, если я по s/pdif подключаю?

[Denjs]

Denjs,
вы выше писали:

пересобрал. итог : тот-же мувик - нагрузка на проц упала до 2-х раз

вы можете мне дать этот бинарник? а еще лучше собрать под 64-битную систему? я оччччень хочу посмотреть, как загрузка упадет "до 2-х раз".
это бы в принципе решило все мои проблемы. потому что на данный момент, разогнав комп до 2820 МГц (я поставил проц на 2400, и увеличил частоту шины с 200 до 235), я все равно имею тормоза на некоторых особо тяжелых сценах. даже с -lavdopts skiploopfilter=all:lowres=1:fast. точнее не тормоза, а отставание картинки.

ну думаю что собранное под мою машину - Celeron 2400 mHz будет хорошо, (и будет-ли ?)работать у вас - двухядерный amd 2100 MHz.
а пересобирать под другую конфу/ядро/процессор признаться даже не знаю как.

я не знаю что там происходит, но один и тот-же мувик на "релизенной" (1.02rc) до пересборки "жрал" 80-100% процессора, после сборки (версия из SVN) - это 40-80% с кратковременными всплесками до 100%.
(и я думаю фраза "до 2-х раз" достаточно точно описывает ситуацию.)

бинарник могу конечно выложить куда.... 10 мегабайт...
но не уверен что оно будет работать.
во первых у меня собрано с поддержкой дополнительно установленных библиотек - XviD (нужно было кодировать видео), live555 (пооковое тв), libdts (не помню что такое, но кажется доп. де-кодеки звука) и libmp3lame - это все нужно будет вам для работы моего банарника. Думаю включая и последние libavcodec (идущие в комплекте сисходниками).... тем более - у мну SuSe - у вас ubuntu и пути до библиотек верно разные...
думаю шансов что мой бинарник заработает с полпинка - не много.

[tull]

значиццо печальные итоги такие:
если даже полностью отключить звук (-ao none), то это на производительность не влияет

mplayer сборки Gloomy быстрее, чем RC2 (кстати, пришлось 3 библиотеки доустановить, чтобы запустить его)
быстрее аж на 1.5%. т.е. ни о каком "падении нагрузки до 2-х раз" не идет и речи...

и самое неприятное, и непонятное. запускаю mplayer с ключами -lavdopts skiploopfilter=all:lowres=1:fast
загрузка 55-65% (т.е. более чем приемлимая). но при этом видео все равно начинает отставать от звука!!! (этот все тот же наиболее сложный эпизод робокопа 1080р, который без lavdopts дает загрузку за 100%)
а еще через несколько секунд начинают сыпаться ошибки:

Too many video packets in the buffer: (62 in 8424947 bytes).
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.
A: 101.9 V: 101.9 A-V: 0.005 ct: -0.004 0/ 0 63% 24% 2.8% 830 0

попробовал на другом фильме (оригинал Титаника), аналогично.
там размер этого буфера никак подкрутить нельзя?

у меня уже не осталось никакой надежды смотреть оригиналы 1080р под линухом (тот же Титаник прекрасно воспроизводится под виндой с помощью powerdvd)

[tull]

ну думаю что собранное под мою машину - Celeron 2400 mHz будет хорошо, (и будет-ли ?)работать у вас - двухядерный amd 2100 MHz.
а пересобирать под другую конфу/ядро/процессор признаться даже не знаю как.

ну, у меня уже 2800 МГц (вынул проц из рабочей машины и разогнал его)
собрать под другую архитектуру очень просто: --target=x86_64-linux или --target=amd64

бинарник могу конечно выложить куда.... 10 мегабайт...
но не уверен что оно будет работать.

если только собранный под мою архитектуру...

это все нужно будет вам для работы моего банарника

я думаю --enable-static помог бы

а у вас от какого числа снэпшот? послезавтра у меня будет suse 11.0-64 бит, я бы попробовал под ней.

но все таки тут дело в чем-то другом - я выше написал про переполнение какого-то буфера

[Gloomy]

mplayer может динамически менять качество декодирования в зависимости от загрузки проца

Все правильно, только в точности до наоборот - загрузка проца может меняться в зависимости от качества декодирования.

глазами, как же еще

Если глазами - на 64 бита и сборке SVN оно работает быстрее. Может быть срабатывает эффект плацебо, но результат в том что файлы перестают тормозить.

вообще через чего правильней всего выводить звук, если я по s/pdif подключаю?

Увы, не могу ответить, никогда ничего не подключал по S/PDIF Но может быть кто-нибудь другой подскажет

там размер этого буфера никак подкрутить нельзя?

Можно: -cache X (где Х - килобайты).

Too many video packets in the buffer

Иногда помогали опции:

Код: Выделить всё

mplayer -ao alsa -framedrop -autosync 100 -lavdopts fast:skiploopfilter=all:threads=8

Причем еще приходилось играться значением параметра autosync, устанавливая его в 10, 30, 100 и 300.

у меня уже не осталось никакой надежды смотреть оригиналы 1080р под линухом

Я все-таки надеюсь смотреть его с комфортом когда сам куплю Blu-ray-привод и стану правильно делать корректные рипы, которые не будут сыпать ошибками "Too many video packets in the buffer"

[tull]

Все правильно, только в точности до наоборот - загрузка проца может меняться в зависимости от качества декодирования.

а вот в этом я нисколько не сомневался но вот динамически меняться качество декодирования не может

Увы, не могу ответить, никогда ничего не подключал по S/PDIF Но может быть кто-нибудь другой подскажет

при -ac hwac3 звука на s/pdif у меня нет

Можно: -cache X (где Х - килобайты).

так это просто кэш файла. я пробовал вплоть до 128Мб, не влияет никак. насколько я знаю, это для медленных винтов или двд-приводов актуально

mplayer -ao alsa -framedrop -autosync 100 -lavdopts fast:skiploopfilter=all:threads=8

-ao alsa использую. frmadrop разумеется нет (нафига мне такое видео?!)
autosync вообще не понимаю как влияет (100 тоже пробовал).
-lavdopts fast:skiploopfilter=all ухудшает картинку (на производительность на самом деле влияет в основном skiploopfilter=all)
про threads писал с самого начала - это для мпега (в мане про это ясно написано)

Я все-таки надеюсь смотреть его с комфортом когда сам куплю Blu-ray-привод и стану правильно делать корректные рипы

2 вопроса:
зачем делать рипы, если будут оригиналы?
вас жаба не душит покупать диски по 1500-2000 руб?


что еще выяснил:

-nosound во многом решает проблему переполнения. т.е. надо искать способ выводить звук напрямую на s/pdif, без какого-либо декодировния плеером

и главное:
-vo x11 оказался намного хуже, чем xv
тот же робокоп на -vo x11 начинает давать переполнение почти сразу
-vo xv дает уже гораздо позже. а если сделать -lavdopts skiploopfilter=all то вообще не дает (и с -nosound не дает)

проблема в том, что под mythbuntu64 -vo xv не работает (я так понимаю, ядро надо пересобирать?)

[xfn]

про threads писал с самого начала - это для мпега (в мане про это ясно написано)

и главное:
-vo x11 оказался намного хуже, чем xv
тот же робокоп на -vo x11 начинает давать переполнение почти сразу
-vo xv дает уже гораздо позже. а если сделать -lavdopts skiploopfilter=all то вообще не дает (и с -nosound не дает)

проблема в том, что под mythbuntu64 -vo xv не работает (я так понимаю, ядро надо пересобирать?)

threads в последних версиях в том числе и для h264, в русском мане этого нет, в английском есть(у меня Федора 9, в 8-ке тоже самое)
из мана:

threads=<1-8> (MPEG-1/2 and H.264 only)
number of threads to use for decoding (default: 1)

другое дело, что реализовано пока еще не полностью.

-vo x11 естественно будет ниже -vo xv, поскольку последний пишет напрямую в видеопамять, т.е. через оверлей, поэтому и вывод через xv быстрей. Для того, чтобы заработал через xv, для Nvidia и ATI нужны проприетарные драйвера видеокарты

[tull]

threads в последних версиях в том числе и для h264, в русском мане этого нет, в английском есть(у меня Федора 9, в 8-ке тоже самое)

ваша правда. в мане из снэпшота нашел про это.
но у меня это не влияет на загрузку никак. только что попробовал threads=2,4,8. загрузка на сложной сцене как была 120-130%, так и осталась
из мана:

Для того, чтобы заработал через xv, для Nvidia и ATI нужны проприетарные драйвера видеокарты

ставил atiшные драйвера (скачанные с официального сайта). насколько я помню -vo xv после этого не заработал.


-ac hwac3 у меня теперь на s/pdif заработал. но вот только на переполнение буфера это не влияет.
буфер не перполняется только если -nosound сделать (только загрузка проца при этом не падает)

что еще заметил: с -vo xv если загрузка даже 90%, видео уже не отстает. так что надо только такой видеовывод использовать.

[Gloomy]

зачем делать рипы, если будут оригиналы

Терпеть не могу смотреть видео напрямую с болванки. Любой DVD сперва копирую на винт, а потом уже смотрю.

вас жаба не душит покупать диски по 1500-2000 руб?

А много ли действительно пригодных к покупке фильмов? Мне пальцев на одной руке хватит их пересчитать. Так что на такое количество дисков я как-нибудь наскребу. Да и пиратки никто не отменял...

под mythbuntu64 -vo xv не работает (я так понимаю, ядро надо пересобирать?)

Ну, это было бы уже слишком сурово! Достаточно поставить заголовочные файлы X'ов. Насколько помнится, в "шляпообразных" дистрах типа OpenSUSE таковые файлы имеются в т.н. "пакетах разработчика" с постфиксами "-dev" или "-devel". Ну и дрова nVidia/ATI должны быть.

буфер не перполняется только если -nosound сделать

Все-таки грешу на кривой рип/сжатие. В моей локалке несколько терабайт не сжатого или слабо сжатого HDV и примерно половина из него не идет, выдавая "переполнение буфера". Хотя с другой стороны вполне может быть что у меня просто слишком маломощный комп...

[tull]

Терпеть не могу смотреть видео напрямую с болванки. Любой DVD сперва копирую на винт, а потом уже смотрю.

не, я имел ввиду ессно не копирование, а пережимание видео.

Достаточно поставить заголовочные файлы X'ов. Насколько помнится, в "шляпообразных" дистрах типа OpenSUSE таковые файлы имеются в т.н. "пакетах разработчика" с постфиксами "-dev" или "-devel". Ну и дрова nVidia/ATI должны быть.

дрова поставил, в xorg.conf дрова fglrx, но -vo xv не работает
какие файлы в убунту надо доставить? (ваще насколько я помню, mythbuntu на nvidia у меня работала с -vo xv без установки заголовков)

да и вообще надо ли все это... послезавтра поставлю suse 11 64 бит, и под ней все соберу.

Все-таки грешу на кривой рип/сжатие

а я нет. потому что такая же фигня и с Титаником. который точно оригинал.

кстати, еще один прикол - я звук до этого слушал непойми какой. только с -ac hwac3,hwdts у меня на процессоре загорелись светодиоды соответствующего сигнала. чего там до этого по s/pdif шло - хз.

[Gloomy]

потому что такая же фигня и с Титаником. который точно оригинал

Тогда я вообще запутался Если обобщить информацию из всей темы, можно сделать незамысловатый вывод о том что дело в конкретном плеере. Потому как:

а) в MPC @ CoreAVC и VLC @ ffmpeg кины не идут даже при громадной мощности компа;

б) в PowerDVD все относительно ползает, причем на куда менее слабой тачке;

Невольно закрадывается мысль о происках любителей защиты аффтарских прав и какой-то хитрой фишке, из-за которой одинаковые фильмы по-разному идут в разных плеерах

[kozyr]

Для сравнения быстродействия, наверное можно использовать -benchmark -nosound. Чтобы исключить влияение видео можно -vo none добавить.
Тут предлагали использовать под виндой CoreAVC. Интерсно пробовали ли использовать CoreAVC для декодирования h264 в mplayer?

[Gloomy]

пробовали ли использовать CoreAVC для декодирования h264 в mplayer?

Пробовали - лично у меня не заводится. Эспериментировал долго, но ничего не добился. Поэтому ждем'c покуда разработчики CoreAVC разродятся нативной версией для *nix (которая, согласно их заявлениям, до сих пор не выпущена только потому что есть сомнения относительно ее продаж).

[sspphheerraa]

Итак, год прошел... а что изменилось?
Mplayer, похоже так и не научился многопоточность юзать
По поводу "-lavdopts threads=2" у меня оно не работает ни с x264, ни с mpeg... Одно ядро - 100%, другое балбесничает

[xfn]

Ну почему же, если собрать с поддержкой, то все работает . Нужно лишь собрать с заменой некоторых веток из ffmpeg-mt. Разработчики ffmpeg-mt обещали слить в основную ветку ffmpeg, стало быть будет и в мплеере.

Вот ссылка на статью, как это сделать:
mplayer-mt

[sspphheerraa]

Поставил эту шнягу теперь грузятся оба ядра
по крайней мере при проигрывании x264 кодека. Спасибо.

Джентушнегам как всегда везет, - наш соотечественник написал ебилд, по которому все собралось (link)

[yaleks]

Поставил эту шнягу теперь грузятся оба ядра

то что они грузятся не означает что по делу Проигрываться лучше стало?

[Gena_Zakharov]

Вообще говоря, многие современные видеопроцессоры имеют аппаратное декодирование h.264. Можно попробовать поставить новые дрова на видяху, и если все получится, то вопрос с процом отпадет сам собой.

Ради интереса проверил на каком-то фрагменте под Linux и под виндой. Загрузка проца 5-10%.
Правда у меня карта Nvidia.

[Gloomy]

Можно попробовать поставить новые дрова на видяху

1) предложение действует только для видях не ниже GeForce 9xxx, причем в самых дешевых из них поддержка VDPAU может отсутствовать;
2) любая из видях декодирует лишь часть кодеков - т.о. половину кинов можно будет выбрасывать сразу и еще треть чуть попозже;

[Kido]

Поставил эту шнягу теперь грузятся оба ядра

то что они грузятся не означает что по делу Проигрываться лучше стало?

Был фильм 1080p, на одном из моментов тормозил. Поставил mt-версию mplayer'а - на том же момента торможение стало меньше, но не ушло. При этом smplayer с ним работать не захотел. В итоге вырнулся на обычный mplayer, так как космического прироста производительности, ради которого можно было бы возиться с smplayer'ом не заметил.
Жду когда допилят VDPAU.