MPlayerXP-0.6.0 has been released

Для Линукса хоть есть ?

И что, он чем-то лучше, чем просто mplayer?

Нет уж, я лучше svn update проделаю с mplayer...

Если это просто плеер, так же как и mplayer, то это очень глупый проект.
Нужно следовать пути xine: мультимедийный движок отдельно (xine-lib), плееры отдельно (totem, gxine, kaffeine, codeine, xine-ui).

Это позволяет полноценно его использовать, а не выводить картинку в окошко по id.

вечно кто-то что-то не делит... :(

>И что, он чем-то лучше, чем просто mplayer

Лучше-не лучше, но в консоль флуд^Wругается красивше :)

>
MPlayerXP crashes under Linux with VESA
Was found way to get MPlayerXP working under VESA!!! It's not a secret that MPlayerXP produced coredump after start with -vo vesa with mounted ext3fs volume.
Unfortunately, the problem has NO SOLUTION with linux-2.4+linuxthreads :( It seems, that you will be lacky only with linux-2.6.x+nptl (which is part of glibc since 2.3.3 version)!
You need to upgrade your system as described below:
- gcc-3.2.4+
- linux-kernel-2.6.x
- glibc(2.3.4+) + NPTL(new POSIX thread library)

If you prefer to use Linux-2.4.x kernel then only way to have working VESA for you is dismounting of all mounted ext3fs volumes.


LOL! Пивонеская поделка нах.

> И что, он чем-то лучше, чем просто mplayer?

Если с тех пор ничего не изменилось, то это форк мплеера, который умеет асинхронно декодировать видеопоток. Т. е. буферизуются также уже декодированые данные, что может помочь на слабых машинах, которые не справляются с декодированием на отдельных небольших участках. Также он вроде умел параллелить процесс декодирования на несколько нитей (для всяких smp).

Фуфуфу, он про 4.1 гцц кричит как про ансуппортед. Форсировал компиляцию без определения версии ГЦЦ. Но уже щас видно, что кривоватое поделие. Хотя, если он действительно может распараллеливать декодинг, то пригодилось бы на HDTV картинках типа x264 1280*720 или 1920*1080 .

З.Ы. Не скомпилилос. Ставим gcc 3.*

> Также он вроде умел параллелить процесс декодирования на несколько нитей (для всяких smp).

smp-ядро уже изжило себя, и ни капельке не быстрее обычного.

Удовольствия вам, при просмотре фильмов!

^^^

исправьте ошибку, блин! запятая лишняя.

а проект пионЭрский.

> LOL! Пивонеская поделка нах.

Что из них: MplayerXP, Linux2.4.x с родными потоками, драйвер VESA при работе с Linux 2.4.x+потоки или драйвер Ext3 при работе с Linux 2.4.x+потоки ?

> smp-ядро уже изжило себя, и ни капельке не быстрее обычного.

А что делать с современными процессорами, в которых как минимум два ядра ? Использовать в лучшем случае половину ? Может в магазине сразу требовать распила процессора на N частей, где N - это количество ядер ? :)

> smp-ядро уже изжило себя, и ни капельке не быстрее обычного.

ну да, на одно-(процессорно|ядерных) компах оно даже немного медленнее :)

>Что из них: MplayerXP, Linux2.4.x с родными потоками, драйвер VESA при >работе с Linux 2.4.x+потоки или драйвер Ext3 при работе с Linux >2.4.x+потоки ?
а это разве не видно? Как может выдеовыход видеоплеера зависеть от fs или версии ядра? Это только пивонеры так умеют делать.

Это задачи чипсетов и операционной системы. В современных ядрах поддержка нескольких процессоров должна быть предусмотрена изначально, иначе это уже нестандартное ядро.

задача чипсета поддерживать раскидывание потоков по ядрам? :[ ]

ЗЫ: а smp ядро разве не основа ОС? :)

>smp-ядро уже изжило себя, и ни капельке не быстрее обычного.

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

сами себе противоречите ??

>smp-ядро уже изжило себя, и ни капельке не быстрее обычного.

Мдяяяя... Ну что тут можно сказать?

> Как может выдеовыход видеоплеера зависеть от fs или версии ядра?
От ядра ещё как может, всё же linuxthreaads vs nptl.
А вот от fs - это и правда не понятно...

> Изменений много!
Судя по ченджлогу - не очень. :)

> * Initial x86-64 support
А до сих пор он был x86-only, чтоли? В чём заключалась его
непортируемость, кто-небудь знает? Это из-за поддержки виндовых
кодеков, или были какие-то другие проблемы?

> а это разве не видно? Как может выдеовыход видеоплеера зависеть от fs или версии ядра? Это только пивонеры так умеют делать.

Да ? Интересно, почему же тогда на 2.6 она работает ?

> Это задачи чипсетов и операционной системы.

И всё ? Ты меня улыбаешь :)

Делаем раз: программа обработки двух массивов работает последовательно с каждым из них. Вопрос - будет ли приращение производительности при переходе с однопроцессорной системы на двухпроцессорную ?

Делаем два: программа обработки двух массивов запускает два потока, которые выполняются параллельно и каждый из них обрабатывает свой массив. Вопрос тот же - будет ли приращение производительности при переходе с однопроцессорной системы на двухпроцессорную ?

> От ядра ещё как может, всё же linuxthreaads vs nptl. > А вот от fs - это и правда не понятно...

Почему непонятно ? Если, скажем, запрос на чтение информации приходит сразу от двух потоков, linuxthreaads отдает их драйверу fs одновременно (ну лочка где-то не поставлена - мало ли какие в нем баги имеются), а драйвер понятия не имеет что делать в таком случае (см. предыдущие скобки), то и вот... Ядро легко может отлупить процесс с сегфолтом.

>Почему непонятно ? Если, скажем, запрос на чтение информации приходит сразу от двух потоков, linuxthreaads отдает их драйверу fs одновременно (ну лочка где-то не поставлена - мало ли какие в нем баги имеются), а драйвер понятия не имеет что делать в таком случае (см. предыдущие скобки), то и вот... Ядро легко может отлупить процесс с сегфолтом.

гыгы. Все-таки не надо опускать авторов fs ниже плинтуса. multithreads приложений кроме mplayerxp дофига, а косячит почему только он. Просто аффтар MPXP ниасилил как надо писать thread-safe код.

> а драйвер понятия не имеет что делать в таком случае (см. предыдущие
> скобки), то и вот... Ядро легко может отлупить процесс с сегфолтом.
Ну знаете ли... ext3 всё же считается production-stable, а вы
говорите, что в нём "лочка не проставлена" и он может отправить
приложению сегфолт? Слабо верится... И почему, кстати, сегфолт?
Тогда уж порча данных была бы, как мне кажется... Если драйвер
из-за собственной ошибки кидает приложение в сегфолт, то при этом
он должен выдать Oops с бэктрейсом.

> гыгы. Все-таки не надо опускать авторов fs ниже плинтуса. multithreads приложений кроме mplayerxp дофига, а косячит почему только он.

Эээ... И все эти приложения активно работают с VESA ? :) Заметь, глюк проявляется только в комплексе VESA-драйвер+Linux 2.4.x+его потоки+ext3-драйвер. Если бы он провлялся при любых раскладах, то можно было бы грешить исключительно на плеер. А так... Я больше склоняюсь к глюкам ядра с его потоками и драйверами.

Короче нихера не компилится

>Эээ... И все эти приложения активно работают с VESA ? :) Заметь, глюк проявляется только в комплексе VESA-драйвер+Linux 2.4.x+его потоки+ext3-драйвер. Если бы он провлялся при любых раскладах, то можно было бы грешить исключительно на плеер. А так... Я больше склоняюсь к глюкам ядра с его потоками и драйверами.

как правильно заметил предыдущий ананимус, если баг в ядре, где oops? А так получается, что ядро все правильно говорит, и глибцы все правильно передают, а вот кривулька программа не умеет эти ответы обрабатывать и память портит.

> Эээ... И все эти приложения активно работают с VESA ? :)
Как именно происходит работа с VESA? vesafb? svgalib? vesatng? lrmi?
vm86? Или ещё как? Как это может быть связано с fs, чисто теоретически
даже?

И у меня не собирается :(

gcc: /usr/local/lib/mplayerxp/codecs/: No such file or directory make[2]: *** [libavutil.so] Ошибка 1

>> * Initial x86-64 support

>А до сих пор он был x86-only, чтоли? В чём заключалась его непортируемость, кто-небудь знает?

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

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

А что, обязательно должны быть oops-ы ?
Последние возникают в случае нарушений обращений в районе памяти ядра и дров. Точнее, если ядерный процесс ломится в левую область памяти. Если же ядерный код просто отдает левую ссылку на память программе, а уже сама программа или кусок glibc, который получил этот адрес, ломится по этой ссылке, то отвалится только программа.

> Как именно происходит работа с VESA? vesafb? svgalib? vesatng? lrmi? > vm86? Или ещё как?

Через int 10h ;D

> Как это может быть связано с fs, чисто теоретически даже?

Чисто теоретически, все эти компоненты (vesa, ext3, управление потоками и mplayerxp) связываются двумя большими программами, типа ядерный менеджер процессов и ядерный менеджер памяти. Баг в любом из компонентов может повлиять на работоспособность другого как ядерного так и не ядерного компонента. В данном случае исключение составляет mplayerxp, ибо он не может повлиять на работоспособность других компонентов.

Кстати, еще про oops-ы. У меня есть одна fs с каким-то глюком. Построена на базе xfs. При попытке чтения/записи/удаления любого из определенного каталога драйвер xfs вываливает ошибки и отмонтирует fs. При этом всё остальное продолжает работать как ни в чем не бывало.

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

PS. А еще я сталкивался когда-то с ситуацией, когда ядро вываливало регистры, но продолжало себе работать. И связано это было с заменой so-шки, которая в данный момент использовалась многопоточным процессом. И было это как раз на каком-то 2.4, но с бэкпортом nptl. При этом процесс тоже отваливался с сегфолтом.

> А что, обязательно должны быть oops-ы ?
Если именно ядро кидает процесс в сегфолт, т.е. процесс сдыхает
во время системного вызова и его обработчик SIGSEGV не вызывается,
то да, обязательно должен быть Oops.

>MPlayerXP crashes under Linux with VESA
>Was found way to get MPlayerXP working under VESA!!! It's not a secret >that MPlayerXP produced coredump after start with -vo vesa with mounted >ext3fs volume.
>Unfortunately, the problem has NO SOLUTION with linux-2.4+linuxthreads >:( It seems, that you will be lacky only with linux-2.6.x+nptl (which >is >part of glibc since 2.3.3 version)!
>You need to upgrade your system as described below:
>- gcc-3.2.4+
>- linux-kernel-2.6.x
>- glibc(2.3.4+) + NPTL(new POSIX thread library)
>
>If you prefer to use Linux-2.4.x kernel then only way to have working >VESA for you is dismounting of all mounted ext3fs volumes.
>
>
>LOL! Пивонеская поделка нах.

MPlayer с win32 кодеками, которые используют нити испытывает теже траблы! Я юзерам mplayer'а уже ссылку на этот материал подкидывал!

>> Как именно происходит работа с VESA? vesafb? svgalib? vesatng? lrmi?
>> vm86? Или ещё как?
> Через int 10h ;D
Вы таки не указали механизм. Дураку понятно, что через int10h.
Каким именно способом риалмодовый int10h вызывается из защ. режима?
Кроме тех механизмов, что я перечислил, думаю, мало что ещё есть,
так что выберите из списка, ну или впишите свой вариант. :)

vesatng не через int10

> vesatng не через int10
По-моему vesa/PM не даёт возможность менять режимы, так что для
смены режимов всё равно приходится использовать int10h. Или я уже
что-то запамятовал?

> Если именно ядро кидает процесс в сегфолт, т.е. процесс сдыхает во время системного вызова и его обработчик SIGSEGV не вызывается, то да, обязательно должен быть Oops.

А если ядро просто отдает процессу левые данные, а сам процесс уже с ними работает ?

>> Если именно ядро кидает процесс в сегфолт, т.е. процесс сдыхает во
>> время системного вызова и его обработчик SIGSEGV не вызывается, то
>> да, обязательно должен быть Oops.
> А если ядро просто отдает процессу левые данные, а сам процесс уже с
> ними работает ?
Было чётко сказано (вами или другим анонимусом):
"Ядро легко может отлупить процесс с сегфолтом."
А это - только Oops. Раньше был ещё один случай - когда обработчик
сигнала записывал фигню в sigcontext, ядро тоже бросало процесс в
сегфолт, но без Oopsa. Совсем недавно этот случай исключили.

> Вы таки не указали механизм. Дураку понятно, что через int10h.

Эээ... Интересный вариант :)
Вообще-то через int 10h работать надежно, но оооочень медленно. Не то что хотя бы 24 fps не сделать. С ним и одного fps сделать не успеешь :)

Свой вариант - установка режима через программирование портов видеоконтроллера. Работа - зависит от требований. Для потокового видео - скорее перекачка информации с помощью DMA или расширений SSE*.
Если честно, в низком уровне я стал достаточно плавуч за посление N лет :)

> Вообще-то через int 10h работать надежно, но оооочень медленно. Не то
> что хотя бы 24 fps не сделать. С ним и одного fps сделать не успеешь
> :)
Что вы имеете ввиду? Почему не сделать? Через int10h устанавливаешь
режим, получаешь физический адрес lfb, а дальше уже всё, int10h
больше не требуется.

> Свой вариант - установка режима через программирование портов
> видеоконтроллера.
Вариант хороший, но, к сожалению, к VESA никакого отношения не имеет.

> Для потокового видео - скорее перекачка информации с помощью DMA
2 вопроса:
1. Как предполагается делать DMA из user-space?
2. Какое это имеет отношение к VESA?

> Если честно, в низком уровне я стал достаточно плавуч за посление
> N лет :)
Больше дела, меньше слов. :)

Так никто и не сказал, как именно mplayerXP работает с VESA, кстати.

> Было чётко сказано (вами или другим анонимусом):
> "Ядро легко может отлупить процесс с сегфолтом."
> А это - только Oops.

Давайте тогда определимся, что в данном обсуждении подразумевается под oops-ом ? Первоначальная фраза: "Если драйвер из-за собственной ошибки кидает приложение в сегфолт, то при этом он должен выдать Oops с бэктрейсом" - навела меня на мысль, что имеется ввиду отвал драйвера или всего ядра с рисованием регистров.
Собственно, я считаю, что при ошибках в коде ядра или драйвера такой отвал совсем необязателен, поскольку не факт, что сам код ядра или драйвера "выполнит недопустимую операцию".

> Что вы имеете ввиду? Почему не сделать? Через int10h устанавливаешь > режим, получаешь физический адрес lfb, а дальше уже всё, int10h > больше не требуется.

Имелся ччиду вывод на экран с помощью int 10h :)

> Так никто и не сказал, как именно mplayerXP работает с VESA, кстати.

Видимо, через API драйвера vesa ? :)

> Давайте тогда определимся, что в данном обсуждении подразумевается под
> oops-ом ?
Сообщение в логе, начинающееся со слова Oops. Обычно так же
содержит значения регистров и бэктрейс.

> навела меня на мысль, что имеется ввиду отвал драйвера или всего
> ядра с рисованием регистров.
Это вы, наверное, с Panic путаете.

> Собственно, я считаю, что при ошибках в коде ядра или драйвера такой
> отвал совсем необязателен
Именно по этому после Oops ядро обычно нормально работает, только
процесс получает SIGSEGV, который нельзя перехватить.

> Имелся ччиду вывод на экран с помощью int 10h :)
Зачем он нужен то? На случай если это VESA 1.2, в которой нет lfb?
Дык нет же, banked mode всё равно должен быть, насколько я знаю.

> Видимо, через API драйвера vesa ? :)
Что именно за драйвер, ссылку на API можно? Он не входил в
представленный выше список? Очень интересно было бы взглянуть.

> Именно по этому после Oops ядро обычно нормально работает, только процесс получает SIGSEGV, который нельзя перехватить.

Определились. Теперь возьмем такую вот чисто гипотетическую ситуацию. Вызов malloc() выделил процессу память по адресу 0x123456, в области ядра всё сохранилось правильно, но в программу вернулся указатель на 0x234567. Будет ли oops при обращении программы к полученному адресу ?

> Определились.
... с азбучными истиннами. :)

> сохранилось правильно, но в программу вернулся указатель на 0x234567.
> Будет ли oops при обращении программы к полученному адресу ?
Разумеется нет. Прога получит SIGSEGV, который сможет обработать.
Но главное отличие не в этом. А в том, что исключение вызовет
пользовательский код, а не ядрёный. Нельзя будет сказать, что
ядро брякнуло процесс с сегфолтом - он сам брякнется, и слетит
только если обработчик SIGSEGV не установил.
Хотя, возможно, я к словам предрался, так как термины тут все весьма
жаргонные. :)