В проприетарных драйверах nVidia для Linux/FreeBSD/Solaris появилась поддержка Pure Video

>сделай это сейчас и проверь.

допустим прямо сейчас всё в xine перестало тормозить (хотя шансов мало).

но несколько лет я наблюдал глотание кадров, рассинхрон и остановку проигрывания видео через xine ,с разными фронтэндами, примерно соответствующего и равному разрешению DVD в формате H.264. плюс декодирование простого divx-а занисало у mplayer-а меньше прочессорного времени.

>Да, уважаемый даун, к одному файлу

Весь этот долбанный флейм начался с того, что ты сказал что невозможно то что мплеер и xine слинкованы с разными либами. При этом кстати обосрал еще кучу дистров.

Ну как тебе не понять что xine тормозит, не умеет читать сабы и как некоторые тут утверждали еще и 5.1 не держит.

>но несколько лет я наблюдал глотание кадров, рассинхрон и остановку проигрывания видео через xine ,с разными фронтэндами, примерно соответствующего и равному разрешению DVD в формате H.264.

Значит ты "несколько лет" не знал, что xine-lib можно собрать по-другому, чтоб этого не было:)

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

Когда я последний раз пробовал (пару лет назад) декодировать что-то xine'ом, он все (даже простенькие аудио-файлы) декодировал не быстрее реального времени. так что с этим я и не спорю:)

mplayer же декодировал с максимально возможной скоростью, если декодирование указывалось в файл.

>Значит ты "несколько лет" не знал, что xine-lib можно собрать по-другому, чтоб этого не было:)

а почему это оно должно было вести себя "по другому"? если в mandrake, mandriva, gentoo, ubuntu оно тормозило и давало рассинхрон? почему все его "неправильно" собирали? в debian уже не пробовал - ни в etch ни в lenny.

>Весь этот долбанный флейм начался с того, что ты сказал что невозможно то что мплеер и xine слинкованы с разными либами.

Я такого не говорил.

>Ну как тебе не понять что xine тормозит

Тормозит. Но не "по сравнению с mplayer".

>не умеет читать сабы

Умеет. Но все.

>еще и 5.1 не держит.

держит

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

А мне сначала показалось, что ты вполне вменяем, просто не владеешь информацией, а tommy - безнадёжный троль. оказалось наоборот:)

А идиотам даже слова мейнтейнера и соразработчика ffmpeg (thresh) и мейнтейнера mplayer, xine-lib, xine-ui, gxine, toxine (с патчами и доработками, принятыми (и "тихо утянутыми") в мейнстрим xine-lib и gxine - пофиг. У даунов - своё виденье мира:)

Кстати, дорогой Led, мною было установлено что даже сейчас мои глюки в HD (в мплеере) происходят из-за слабой звуковой карты, но эти глюки я встречал буквально пару раз, я проводил некоторые опыты с опциями. Так вот, что я хочу сказать, почему ты не допускаешь возможности, что движок xine написан так, что или по какой-то другой причине не зависящей от кодека он тормозит или же он отжирает много процессорного времени? Разговор был начат с того, что движок мплеера единственный адекватный движок в лине, но ты начал с пеной у рта доказывать, что "ксайн во все поля". При этом оскорбляя своих собеседников. Очень плохо.

ЗЫ: Года два-полтора назад у меня xine даже кириллицу не понимал. ЗЫЫ: На видне тоже все должно работать, но ...

>Тормозит. Но не "по сравнению с mplayer".

Имено по сравнению, я пользуюсь мплеером потому что он не тормозит, ну бывает конечно, но тут уже железо слабое виновато.

>а почему это оно должно было вести себя "по другому"? если в mandrake, mandriva, gentoo, ubuntu оно тормозило и давало рассинхрон? почему все его "неправильно" собирали? в debian уже не пробовал - ни в etch ни в lenny.

Как минимум в mandriva, gentoo, Fedora и Debian xine-lib до последнего времени собирался с древним libavcodec, находящимся в дереве xine-lib. Я это знаю, потому что когда искал пару лет назад решение для сборки xine-lib с самой свежей на тот момент системной libavcodec.so, а была кое какая "нестыковка", я пытался найти готовое решение-патч во всех этих дистрибутивах. Его по вышеизложенным причинам не оказалось :( Пришлось решать самому, а вскоре и апстримовый xine-lib "подтянулся" и с того момента особых проблем ни в сборке, ни, тем более, в работе xinelib с системной libavcodec.so.* - не было

>держит

Но при этом когда человек тебя спросил, как что-то там сделать ты не смог найти ответа.

Я тестил с libavcodec свн этого года libxine. Но... Лаги были. Тестил примерно в начале года, потом окончательно забил.

Хы, вот и еще один банящий меня, уже 4-й.

>в debian уже не пробовал - ни в etch ни в lenny.

Кстати, скажу тебе, только что посмотрел в lenny июльская сборка libavcodec и xine слинкован с ней, лол.

вру февральская, но все равно достаточно новая, относительно истории жизни xine.

>Как минимум в mandriva, gentoo, Fedora и Debian xine-lib до последнего времени собирался с древним libavcodec, находящимся в дереве xine-lib.

если не ошибаюсь последним дистром где я пробовал проигрывать через xine был Ubuntu 7.04. плееры были испробованы в том числе kafeine и kmplayer. ничего не пересобирал. глотание кадров и рассинхрон звука были (часто просто дикий и иногда с обрывом проигрывания). переключение kmplayer на mplayer с xine показывало что всё Ok и проц был занят процентов на 30-40 максимум в пике (пишу по памяти).

что надо было сделать - ну извините не знал. если везде всё так плохо - кто мог подумать что может быть лучше. и главное - если никому не надо то почему я будут мучаться. мне mplayer нравится и он меня всегда устраивал больше чем уродские (и глючные сами по себе) GUI к xine-у.

>мне mplayer нравится и он меня всегда устраивал больше чем уродские (и глючные сами по себе) GUI к xine-у.

в 2001 вы его не пробовали ;) Тогда под линуксом была полная жопа с видеоплеерами - уродливый ксайн или сырой мплеер

>в 2001 вы его не пробовали ;) Тогда под линуксом была полная жопа с видеоплеерами - уродливый ксайн или сырой мплеер

В 2001 у меня aviplayer играл всё, что мне попадалось.

и у меня под freebsd

Наконец-то догнали Windows...

>> И интересно, почему никто не говорит о том, что эти патчи не смогут приехать в дистрибутивы, т.к. линковать надо с не GPL-совместимой либой?

GPL этому не мешает. Проблемы могут возникнуть, только если лицензия на эти проприетарные либы прямо запрещает компоновку с GPL'ным софтом.

Если бы было иначе, то GPL'ный софт не мог бы существовать под закрытыми системами типа венды, с насквозь проприетарными "стандартными" библиотеками.

> кстати амд тут как раз недавно пообещалась разрелизить аналог CUDA

обещанного три года ждут

Насколько я понимаю, для подобных случаев с "проприетарными стандартными библиотеками" и есть исключение.

Покажите хоть одну GPL-совместимую либу, которая линкуется с проприетарщиной, плз.

> Наконец-то догнали Windows...

Может это nVidia снизошла до реализации полной поддержки Linux? Вон Amd до сих пор штомает всякие Vista-угодные протоколы которые на Linux никогда работать не будут - типа ATI Hybrid CrossFireX

> Покажите хоть одну GPL-совместимую либу, которая линкуется с проприетарщиной, плз.

gstreamer может использовать проприетарные кодеки

> gstreamer может использовать проприетарные кодеки

Может, всё таки прочитаете мой вопрос?

MeGUI

Написан на C# для .NET.

К тому же скорее всего с vdpau линкуется ffmpeg, а он lgpl, надо бы у экспертов спросить.

http://www.linux.org.ru/view-message.jsp?msgid=3260218&nocache=-843311927

Создал тему, ждем ответа.

Это прикол, чтоли, экспертов на ЛОРе искать?

> К тому же скорее всего с vdpau линкуется ffmpeg, а он lgpl, надо бы у экспертов спросить.

какой такой ffmpeg? бинарник, чтоли? т.е. в патчи вы даже не смотрели.

>какой такой ffmpeg? бинарник, чтоли? т.е. в патчи вы даже не смотрели.

Там патчи для libavcodec есть.

хорошо, libavcodec, но ей тоже нельзя линковаться с проприетарными библиотеками.

>хорошо, libavcodec, но ей тоже нельзя линковаться с проприетарными библиотеками.

Оно как бы lgpl, на сколько я помню lgpl как раз для такого и создавалась.

О кстати, ffsdshow. Получается незаконно?

s/ffsdshow/ffdshow

> Может, всё таки прочитаете мой вопрос?

И чего я должен был там вычитать? В чём принципиальная разница API к проприетарному девайсу от проприетарного кодека? Лицензионно никакой разницы не должно быть, имхо.

Да и нету ее, ffdshow пример свзяки ffmpeg и DirectSHow, очень любим виндузятниками.

> В 2001 у меня aviplayer играл всё, что мне попадалось.

avifile :) Эх, хороший был проект :)

Итак возвращаемся к vdpau. Насколько я понял контейнер файла значения не имеет (180.08), матрешка перепакованная в ts сыпется с теми-же ошибками. Видимо надо как-то хитро кодить в h.264, как в Grey.ts Заметил еще что Grey.ts декодится так >VO: [vdpau] 1920x1088 => 1920x1088 H.264 MAIN VDPAU acceleration а мои файлики что валятся с ошибкой Error at libvo/vo_vdpau.c:826 так >VO: [vdpau] 1280x544 => 1280x544 H.264 HIGH VDPAU acceleration

Вобщем реквестирую правильные опции для x264, транскодить к примеру буду авидемухом

>>Но используется не только Microsoft-ом
>Но и MS-зависимыми, да.
Например, Sun Microsystems

не факт, что она когда нибудь появится в официальных дровах. Может это хитрый ход nvidia, чтобы покупали её карточки? Когда ati/amd только только начали делать сносные дрова под lin.

Анонимус идиот.

Нвидия, в отличии от первого - не идиоты. Им такое и в голову не придёт. )