MPlayerXP-0.6.2 вышел

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

а проку от многопоточности плейера, если кодек, который ему придется использовать, однопоточен?

>а проку от многопоточности плейера, если кодек, который ему придется использовать, однопоточен?

иногда надо несколько потоков проигрывать (сиречь - разжимать/сжимать снова), без просмотра, а еще h264 вроде как многопоточен, а еще тут важна многопоточность не при просмотре (ща любое одно ядро тянет легко) а при сжатии, ща буду качать и смотреть, может жать оно умеет мультипоточно - во будет здорово %)

> иногда надо несколько потоков проигрывать (сиречь - разжимать/сжимать снова), без просмотра, а еще h264 вроде как многопоточен, а еще тут важна многопоточность не при просмотре (ща любое одно ядро тянет легко) а при сжатии, ща буду качать и смотреть, может жать оно умеет мультипоточно - во будет здорово %)

многопоточно h.264 жать может собственно сам x264, который и используется в качестве кодера во всех проектах (включая mplayer/mencoder, ffmpeg и т.д.). у бинарника x264 есть опция типа --threads где указывается во сколько тредов проводить кодирование. По моим наблюдениям скорость кодирования увеличивается линейно при увеличении тредов т.е. два треда жмут быстрее почти в два раза чем один. При этом главное, что бы количество тредов было не больше физического количества процов - иначе эффект может быть отрицательным :)

> а проку от многопоточности плейера, если кодек, который ему придется использовать, однопоточен?

щас кодек жрет небольшую часть. основную - постпроцессинг (deblocking, и т.д.). его и можно распихать в разные потоки.

> многопоточность не при просмотре

Ну-ну. Как раз на просмотре и важно - одно ядро декодирует видео, другое занимается постпроцессингом и декодированием звука.

> ща любое одно ядро тянет легко

Посмотрю я, как ты на чем-нибудь класса A64 3500+ (ну или A64 X2 4400+) - вроде современный проц, да? будешь декодировать 1080p h264 поток без потерь кадров.

> может жать оно умеет мультипоточно

RTFM, жать мультипоточно умеет и стандартный mencoder! Опция threads для кодеров lavc или x264. Причем threads=2 дает ощутимое ускорение даже при использовании старого пня с HT. Но сам понимаешь, качество кодирования при включении мультитрединга всегда будет ниже.

>Посмотрю я, как ты на чем-нибудь класса A64 3500+ (ну или A64 X2 4400+) - вроде современный проц, да? будешь декодировать 1080p h264 поток без потерь кадров.

дружище, я может че та не то делаю... у меня A64 X2 3800+ и смотрел 1080p с помощью VLC... ниче не дропалось. Давай так, дай линк на небольшой кусок видео которое у тебя тормозит (у меня канал узкий, всего ~300кбс) я качну и проверю.

Я как это 1080p получал то.. В майке рендерил видео, и... жал правда в обычный mpeg4. Видео было довольно нестатичным - моделирование ядерного взрыва. Одно ядро проца при воспроизведении загружалось ну может процентов на 30.. хз, или я чета делал не так, или...

да, видео - набортное 6100 Может оно чета там акселирирует ? Дрова - 9746 Система - ubuntu 64 6.10, соотв. vlc тоже 64 бит. Плиз кинь кусок маленький видео - самому интересно.

> смотрел 1080p

Угу.

> 1080p h264

Читать умеем? Что mpeg4 будет декодироваться - сомнений нет, вот только кто его кодить таким будет? Сейчас другие времена - новые разрешения, новые кодеки. Эффективность h264 реально заметно выше, чем mpeg4, разница куда больше, чем между mpeg1 и mpeg4. h264 экономит прилично битрейта, но требует больше ресурсов.

> Давай так, дай линк на небольшой кусок видео

Небольшого нет, а так - http://images.apple.com/movies/us/hd_gallery/gl1800/bbc_1080p.zip

93 мега. h264 + aac.

Вот еще хороший кусочек (103M, h264 + dts, много сабтитров - для моделирования реальной ситуации полезно включить их или mplayer'овский OSD, наложение сабов отнимает ощутимые ресурсы в высоком разрешении)

http://omnidatagrup.ro/~taipan/mkv/Sin.City.2005.1080p.HDTV.DTS.x264.Sample-E...

Народ, о чем вы говорите, какое нафиг в MPlayerXP многопоточное сжатие видео? MPlayerXP - это тока проигрыватель. Нету в нем mencoder'а никакого в помине...

>Небольшого нет, а так - http://images.apple.com/movies/us/hd_gallery/gl1800/bbc_1080p.zip

ну 93 мега это и есть небольшое, санкс, качаю %) сольеццо - отпишусь. Про h264 не надо меня лечить, я лет 7 в СМИ работаю, просто в тот момент был под рукой тока обычный мпег4 %)

да, кстати, смысла от постпроцессинга при таком качестве как то не видится. Кто его реально использует, если поток соотв. разрешению видео ? Ну лично я обычно только гамму поправлю, ну может констраст.. но это аппаратно через оверлей видюхи все...

> Но сам понимаешь, качество кодирования при включении мультитрединга всегда будет ниже.

Почему? А если двупроходное кодирование?

ну и кому оно нафиг нужно, когда есть vlc?

> да, кстати, смысла от постпроцессинга при таком качестве как то не видится. Кто его реально использует, если поток соотв. разрешению видео ?

В h.264 deblocking идет уже при сжатии.

Это ведь bugfix немажорной версии...

PS: Если бы с такими темпами выкладывали новости о Mplayer-SVN...

Наверное был бы уже самым популярным плеером :)

>а проку от многопоточности плейера, если кодек, который ему придется использовать, однопоточен?

декодирование видеофильма состоит из:
* декодирование видео потока
* декодирования аудио потока
* постпроцессинга и рендеринга видео потока
* постпроцессинга и рендеринга аудио потока
иногда ещё можно добавить кеширование входного потока!
Это уже нитки, как минимум!

Кто-нибудь на 64 бит собрал? У меня сразу же вывалил

mplayer.c:1: error: bad value (x86_64) for -march= switch mplayer.c:1: error: bad value (x86_64) for -mtune= switch make[1]: *** [mplayer.o] Error 1

и все.

>Небольшого нет, а так - http://images.apple.com/movies/us/hd_gallery/gl1800/bbc_1080p.zip

Ааа, тормозит :(((. p4 1.8@2.8.

А если сравнить с VLC этот плеер, что лучше?

>Небольшого нет, а так - http://images.apple.com/movies/us/hd_gallery/gl1800/bbc_1080p.zip

mplayer играет, вроде бы даже ни одного кадра не сбросил. vlc тормозит абсолютно.

AMD Athlon(tm) 64 X2 Dual Core Processor 4200+

Это - тот самый плеер, который падает при работе через svgalib, если файл на ext3 лежит? Или я что-то путаю?

Да ладно уже, вы что-ли фильмы смотрите с flac звуком, сжатым на максимуме? Это же мелочи, зачем еще их упоминать.

Валится на компиляции с dvdnav

Да и в общем-то вообще никак не собирается :(

> х264 ... скорость кодирования увеличивается линейно при увеличении тредов...

4.2 .Это ваше ИМХО. Вот:

> выдержка из x264/doc/threads.txt

x264 -B1000 -b2 -m1 -Anone
threads speed psnr
old new old new
1: 1.000x 1.000x 0.000 0.000
2: 1.168x 1.413x -0.038 -0.007
3: 1.208x 1.814x -0.064 -0.005
4: 1.293x 2.329x -0.095 -0.006
5: 2.526x -0.007
6: 2.658x -0.001
7: 2.723x -0.018
8: 2.712x -0.019

Меня настораживает название сего проекта...

>Меня настораживает название сего проекта...

У AMD была серия процов Athlon XP - тоже настораживала? :)

И еще в догонку - у RPGшников сокращение XP (означавшее экспу) в ходу еще аж с конца 80-х, если не раньше (просветите неграмотного - во всяких DnD ее так не обзывали?).Еще XP значит Extreme Programming (довольно любопытная парадигма разработки ПО, во многом схожая с моделью, обычно применяемой при разработке F/OSS программ).

>>>Это - тот самый плеер, который падает при работе через svgalib, если файл на ext3 лежит? Или я что-то путаю?<<<

Это не проблема плейера а ядра!
Формула была:
mplayerxp(linux-2.4+ext3+threads+vesa)=segfault

переход на linux-2.6 + nptl решает все проблемы!

Good luck!

Автору этого чуда надо что с самим собой поделать - я столько варнингов при компиляции даже в самом страшном кошмаре не видел, да ещё и ассемблер понатыкан кое-как - вообщем я плюнул на сборку после третьего набора ошибок в асме (х86_64). особенно задели `апичятки` типа "popl %,%...", "gcc -march=x86_64...", и т.д.

попробуй ffmpeg собрать, увидишь много нового :)

Ужо собирал, просто надо кучу флагов в configure втыкать, а так ничего особого. кстати я однажды собрал ядро, ОО.о, KDE, gcc, amarok... за пару-тройку суток. по мне ведь этого не скажешь, правда? но тем не менее, сейчас я постоянно использую рпм-репы.

>>>Автору этого чуда надо что с самим собой поделать - я столько варнингов при компиляции даже в самом страшном кошмаре не видел, да ещё и ассемблер понатыкан кое-как - вообщем я плюнул на сборку после третьего набора ошибок в асме (х86_64). особенно задели `апичятки` типа "popl %,%...", "gcc -march=x86_64...", и т.д.<<<<

проект ждёт портеров на x86_64 платформу!

Оно еще дышит? Когда поставят на рельсы gtk2 ?

А на фига gtk2 плейеру?

ну для любителей консоли можно и без него , и вообще без gtk а gtk2 юзать хотя бы потому, что у меня mplayer только один использует gtk

Ибо GTK1 - RIP, и туда ему и дорога

косяк. афтар явно накурился.
1) чтото не помню, чтоб нагрузка неравномерной была. На ноуте 1.8 турион64 с оверлеем при hdtv divx график загрузки был довольно равномерный, на уровне где-то 20%.

2) кому нужно это поделие???
а) кодеков мало
б) кодера нет!

Куда-то все идут не туда, или я на асфальте в лыжах?! Уже который год жду поддержку dmo/dshow для mplayer_86-64, пробовал пинать девелоперофф - ни ф какую. Voxware Metasound казлина вложила в аудио - будьте нате иметь кросс компиляцию для i386. И вместо того, чтобы наконец добить базовый функционал аффтар выпускает очередное нестабильное/(непригодное для всех и для меня в частности, ибо лень cross-компилить) поделие. IMHO - ни о чём. Лучше бы сделали очередной тест/сравнение mplayer+mencoder vs аналогичный вендовый софт - я бы пофтыкал качественный разбор с удовольствием.

з.ы. VLC - быдлоподелие полное...

>>>косяк. афтар явно накурился.
1) чтото не помню, чтоб нагрузка неравномерной была. На ноуте 1.8 турион64 с оверлеем при hdtv divx график загрузки был довольно равномерный, на уровне где-то 20%.

2) кому нужно это поделие???
а) кодеков мало
б) кодера нет!<<<

Основная идея mplayerxp это показывать каждый кадр не дольше и не меньше чем 40 мс для 25 кадров / сек видео! В своё время меня задолбало смотреть, как mplayer декодирует кадры, что приводило к постоянным замерзаниям кадров на экране. Этот дефект ликвидируется при помощи нитей.

Каких кодеков вам нехватает?

По поводу mencoderxp - у меня на сайте написано, что в мои планы не входит его разработка и поддержка!

> Каких кодеков вам нехватает?

Насколько могу судить по "просто" MPlayer, основной массе юзеров не хватает полноценного аналога win32codecs для 64-битных платформ.

nick а почитать man не пробовал? -autosync -framedrop -mc можно и с -nobps для avi...

>>>nick а почитать man не пробовал? -autosync -framedrop -mc можно и с -nobps для avi...<<<

Нитки это принципиально новое ядро плэйера! Я в своё время много чего перепробовал и понял, что нитки это единственное, что может помочь для спокойного (без рывков) просмотра тех фильмов, что у меня были.

>> Каких кодеков вам нехватает?

> Насколько могу судить по "просто" MPlayer, основной массе юзеров не хватает полноценного аналога win32codecs для 64-битных платформ.

почему не хватает?

emerge mplayer-bin

>з.ы. VLC - быдлоподелие полное...

а можно увидеть Ваш код в каком-нибудь opensource-проекте?

> а можно увидеть Ваш код в каком-нибудь opensource-проекте?

есть поговорка, что иногда лучше молчать, чем что-то говорить...

делаю то, что мне интересно: http://rootshell.be/~sda00/

скоро там же будет статья о включении sub-pixel rendering (с скриншотами и тп)

> > а можно увидеть Ваш код в каком-нибудь opensource-проекте?

> есть поговорка, что иногда лучше молчать, чем что-то говорить...

Именно. Потому я и спросил. :)

Подозреваю, что кому-то Ваши труды по документированию полезны.

Спасибо.