Давно хотел спросить - существует ли какой-нибудь патч для mplayer/mplayerxp который позволяет использовать mencoder с mpi?

mplayerxp не поддерживает encoding.
А mpi - это из какой оперы?

mpi -- нет, вряд ли... но можно взять transcode, он поддерживает cluster batch encoding, не через mpi, а так, нативно.

А в Матрокс G450 когда сделают ускоренный BES/TV-Out? CRTC2 в mga_vid работает, но картинка плывет вверх ... шаманство с таймингами не помогло, хотя меняло скорость прокрутки, сдвиги влево-вправо и пр.

MPI - Message Passing Interface, чтобы на нескольких нашинах паралельно кодировать... Кластер короче использовать для превращения dvd в divx :-).

А все таки Мicrosoft рулит... Стоило назвать свою ОС с приставкой XP, так многие кинулись поддерживать модное слово. AthlonXP чего стоит. Тут же и MPlayer почему то XP стал. Профессионалы в маркетинге, что и говорить.

а чо такое XP?как расшыфровать?

XP=cross platform ???

Насчёт шифрования - вы чё - русского не заете??? "Х" и "Р" - сокращение от хрен

а это мплаерХП довольно неплох - вот фильмик полный экран с диска до 19 персентов - с тем как мплаер 0.60 36 съедал - а вот провинду не надо - там под 80-100 персентов и качество такоежэ

XP - extra performance
но это не про windows

Анонимосу, что написал "расшыфровать". ЖИ,ШИ пишется через "И", грамотей. Хакер должен знать родной язык на 5!

Бля - с чего ты взял что это хакер ?????

>Хакер должен знать родной язык на 5!
Это "Це" что ли? али ассемблЯр?:=)

> Тут же и MPlayer почему то XP стал.

Дятел, это два РАЗНЫХ проекта. Хоть и ОЧЕНЬ похожих :-))) Пока еще... :-))))

Смысл аббревиатуры "XP" зависит от контекста. Например, в WinXP - eXperience Problems (если кто не знает)

Вообще-то аббревиатура XP - eXtreme Programming использовалась задолго до вин-хп, см. на http://www.extremeprogramming.org: "In March of 1996 Kent (Beck) started a project at DaimlerChrysler using new concepts in software development. The result was the Extreme Programming (XP) methodology."

>А в Матрокс G450 когда сделают ускоренный BES/TV-Out?
По поводу mga_vid - это лучше всего выяснить в avifile
поскольку Kabi выглядит более способным на такие штуки
чем Matrox владельцы из девелоперов mplayer.

>MPI - Message Passing Interface,
Thanks! Просто сейчас слишком много аббрев пошло (mvi, mpp)
По поводу кластеров - не знаю но по-моему было бы легче
как-то заставить этим заниматься libpthread и тогда все нитевые
приложения стали бы готовы к кластрной работе. (Хотя multimedia
требует очень широкий сетевой bandwidth)
И еще одно - на сколько мне известно Arpi - крайне отрицательно
относится к нитям (да и к vfork тоже) - так что c mencoder похоже
что никогда!

XP=cross platform ??? Пока только для *nix систем! В основном для Linux! В смысле процессоров - работает на x86, dec-alpha, sun, ppc, ...

Я на кластере dvd в divx кодировал путем запуска кучи процессов mplayer'а, по одному на chapter... За 40 минут (если быть точным, то за 41.32 минуты) весь star wars ep 1 конвертнулся :-). В кластере было 1 dual athlon MP 1.7, 3 athlon XP 1.6, 2 duron 950 и 1 celeron 700 :-).

Но ИМХО это неправильный подход, все руками надо делать (типа, mplayer N34 идет на машину 1, mplayer N53 идет на машину 4...). Вот если бы mpi туда прикрутить то процессы сами бы по машинам разбегались :-).

Кстати, если уж заговорили о кодировании. Кто-нибудь
знает, есть ли линуксячий аналог виндового VirtualDub-а?

Хм, а вот правда ли, что для кластеров, особенно
неоднородных, лучше всего подходит PVM (Parallel
Virtual Machine), а не MPI, который, в свою очередь,
предназначен для SMP? По-крайней мере, povray
на кластерах работает именно через PVM.

> Я на кластере dvd...

А я без кластера на одном athlon-1400 кодирую любой фильм ровно столько, сколько он сам длится. То есть, в реальном времени. Если фильм длится 120 минут, то кодирование занимает столько же.
http://www.linux.org.ru/gallery/big4c4qO3.jpg

Кстати, эта программа умеет распараллеливать кодирование на кластер.

>есть ли линуксячий аналог виндового VirtualDub-а? полнофункционального - нет! Но какую-то часть функциональности реализует mencoder (в смысле - если надо вырезать куски, изменить яркость и т.п.)

1) povray на кластерах работает и через MPI
2) MPI есть на всех "больших" кластерах top500, PVM - не всегда,
и вообще MPI это стандарт де-факто. Соотв. MPI есть под все среды
передачи данных используемые для кластеров (Миринет,....).
3) Заставить паралельное API с общей памятью
работать через API с прохождением сообщений теоретически можно :-)
Но с практической точки зрения - одна из сложнейших задач, тем более
что программа написанная без учета задержек среды передачи данных
превращается на такой архитектуре в гнусное тормозилово :-)
4) Авторитетно заявляю MPImencoder - это был бы рулез :-)
5) Самый простой способ его написания, и фактически единственно
приемлемый - это анализ потока данных предназначенного для
кодирования на предмет их зависимости. То есть например послать первые
5 минут на один узел, вторые 5 минут на другой итд. А потом
собрать перекодированные данные в один файл. Качество сжатия при
этом ухудшится но - может господин nick чего нибудь посоветует
на предмет этого ? Типа может не по кадрам например разбивать а еще
как -то - или в процессе чем то обмениватся ?

2 anonymous (*) (2002-11-19 15:11:24.163)

А можно узнать, что за софтину пользуешь для рипания DVDюков?

POVRAY через mpi тоже работает. Два патча есть в google - pvmpov и mpipov :-).

а набросали-бы добрые люди ссылочек на тему этих pvm, mpi с точки зрения программиста начинающего с этим топиком знакомиться? польза была-бы :)

2anonymous (*) (2002-11-19 16:35:14.196)
Софтина dvdrip (http://www.exit1.org/dvdrip/). Висит в секции скриншотов
http://www.linux.org.ru/view-message.jsp?msgid=249531

MPI, PWM и т.д. для данной конкретной задачи (рипание DVD) вовсе необязательно. У каждого DVD есть главы, примерно равной длины. Разбросать эти главы по машинам можно простеньким скриптом. И не надо мудрить там, где можно сделать работу не мудрствуя лукаво.

Пытаюсь собрать и вот такое чудо появляется: gmake[2]: *** [aclib.o] Error 1 gmake[2]: Leaving directory `/usr/home/sourcer/mplayerxp-0.1.9/mplayerxp-0.1.9/mplayerxp/libvo' gmake[1]: *** [libvo/libvo.a] Ошибка 2 gmake[1]: Выход из каталог `/usr/home/sourcer/mplayerxp-0.1.9/mplayerxp-0.1.9/mplayerxp' gmake: *** [all] Ошибка 2 Уже который раз, а mplayer из портов на ура, в чем дело? P.S: OS FreeBSD 4.6 gcc 2.95.4

>А можно узнать, что за софтину пользуешь для рипания DVDюков? mencoder - тоже подойдет! ;)

>Пытаюсь собрать и вот такое чудо появляется: gmake[2]: *** [aclib.o] Error 1 gmake[2]: Leaving directory
Нельзя ли запостить полный багрепорт в mplayerxp-general@lists.sourceforge.net или
в секцию [Bugs] на страничке mplayerxp - тут слишком мало информации
для выводов!

anonymous (*) (2002-11-19 15:09:07.645):
> а вот правда ли, что для кластеров, особенно неоднородных, лучше всего подходит
> PVM ..., а не MPI,
Нет, вернее, не совсем.
MPI как раз для кластеров и подходит, а PVM больше подходит для очень гетерогенной
среды, которую и кластером назвать трудно. Т.е., ответ таков: PVM лучше подходит
для ОЧЕНЬ неоднородных кластеров.

>... который, в свою очередь, предназначен для SMP?
А вот на SMP он (MPI) как раз не очень хорошо ложится, поскольку его идейной основой
является сериализация.

anonymous (*) (2002-11-20 00:27:14.89)
...а набросали-бы добрые люди ссылочек на тему этих pvm, mpi ...

В качестве MPI "для пешеходов" посмотри шедевр Сапожникова:
http://www.jinr.ru/~tsap/Koi/Publ/parallel.htm

А, вообще, стартуй (в смысле ссылок) отсюда:
http://parallel.ru/

2nick cc -c ./stubs.s -o stubs.o ld --shared -soname libloader.so -o libloader.so ldt_keeper.o pe_image.o module.o ext.o win32.o driver.o pe_resource.o resource.o registry.o elfdll.o afl.o vfl.o cpudetect.o get_path.o stubs.o -lc -lm -lpthread /usr/libexec/elf/ld: cannot find -lpthread у меня фря в чем дело?

>cannot find -lpthread у меня фря в чем дело?
А обычно она там есть?
Sorry никогда не юзал фрю - но lpthread вообще-то стандартная
штука хотя и часть glibc а на сколько я знаю у fbsd своя libc!

Вообщем - надо root'ом поискать какие там есть *thread*so,
где они лежат и у кого к ним есть доступ.

Может быть -L/path/to/pthread поможет!

XP = eXtremely Pathetical.

kernel

> 5 минут на один узел, вторые 5 минут на другой итд. А потом собрать перекодированные данные в один файл. Качество сжатия при этом ухудшится но - может господин nick чего нибудь посоветует на предмет этого ? Типа может не по кадрам например разбивать а еще как -то - или в процессе чем то обмениватся ?

Я не nick, но свои 5 коп. вставлю :-)))) : AFAIK, в divx формат следующий - поток состоит из блоков, каждый блок - один базовый кадр + серия вычисляющихся от него. Размер блоков (в кадрах) для дивикса задается произвольно. Соответственно входной видеопоток надо просто нарезать ломтями и рассылать на разные узлы - на качество это никак не повлияет.

>Соответственно входной видеопоток надо просто нарезать ломтями
Все зависит от того зачем это надо!
Если вести декодирование - то там все очень просто:
все ключевые кадры известны заранее и блоки типа
ключевой кадр + серия предсказанных вычисчляется очень даже
быстро так что можно декодировать весь фильм за 5 секунд
на кластере из 2000-3000 машин.
Если вести перекодирование (из оджного формата в другой) картина похожая!
Если вести захват изображения в реальном времени - то тут сложней:
раскидать его по сетке (10GBit/sec) и хранить его в кластере как .raw
и потом спокойно обмениваться информацией между компьютерами при
вычислении I и P кадров или придумать что-то еще.
Одно не понятно - любой современный однопроцессорный комп справляется
со всеми этими задачами в реальном времени!
Нафига это надо?

pthreads во FreeBSD

ключ для линкера не -lpthread, а -pthread, если не ошибаюсь. А вообще в таких случаях man pthread_create например может многое о системе рассказать.

> Если вести захват изображения в реальном времени

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

> Нафига это надо?

Скорость.

Читал я читал... MPI, PVM... А ключевого слова MOSIX никто не назвал. Специалисты, блин...

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

Ну самое простое здесь - нарезать поток по 30-100 кадров и
раскидать их по машинам. Если неправильно расчитать ключевые
кадры - это не страшно - все будет работать просто
результирующий размер потока будет больше чем мог бы.

>Скорость.

Если не нужен real-time - то намного быстрее и качественне все эти
машины нагрузить кодированием разных фильмов. Просто если речь идет
о всего одном потоке в месяц - вряд ли кто-то будет все это городить.

Дык подразумевалось что это и так ясно... Только openmosix, а не mosix :-).

nick

> Ну самое простое здесь - нарезать поток по 30-100 кадров и раскидать их по машинам.

О чем я и говорил. Разве что порции я бы сделал по больше, если по етхернету пускать.

> намного быстрее и качественне все эти машины нагрузить кодированием разных фильмов.

Почему ???? 1) почему __НАМНОГО__ быстрее ?? Допольнительная работа - только на обслуживание сокетов (мелочь) и на сборку/нарезку файла (то же, в общем, копейки). Это как раз та задача, которую сам господь велел распараллелить :-)))))) 2) И почему __КАЧЕСТВЕННЕ__ ???? Если жмет одна и та же программа с одними и теми же параметрами одни и те же входные данные ??? Или вы придерживаетесь той точки зрения, что любая прогамма сложней хэлловорлда каждый раз ведет себя сугубо индивидуально ??? :-))))

И еще один вопрос - вы не подскажете какой-нибудь кодек для сжатия черно-белых и grayscale видео ?? Насколько я понимаю, mpeg4 хочет только RGB...

>Почему ???? 1) почему __НАМНОГО__ быстрее ?? Допольнительная работа - >только на обслуживание сокетов (мелочь) и на сборку/нарезку файла (то

передача информации по SCSI шине быстрее чем по ethernet.

>же, в общем, копейки). Это как раз та задача, которую сам господь >велел распараллелить :-)))))) 2) И почему __КАЧЕСТВЕННЕ__ ???? Если >жмет одна и та же программа с одними и теми же параметрами одни и те >же входные данные ??? Или вы придерживаетесь той точки зрения, что >любая прогамма сложней хэлловорлда каждый раз ведет себя сугубо >индивидуально ??? :-))))

Качественне в смысле оптимального поиска ключевых кадров а отсюда -
размер и нагрузка на проц при последующем декодировании.

>
>И еще один вопрос - вы не подскажете какой-нибудь кодек для сжатия >черно-белых и grayscale видео ?? Насколько я понимаю, mpeg4 хочет

AFAIK - ffmpeg. По крайней мере там есть опция grayscale! Не знаю
насколько она ззадействована mencoder'ом

>только RGB...

Не RGB а YUV! В YUV чтобы получить черно-белое изображеие
достаточно оставить только Y и выкинуть UV. В RGB надо задавать
равную интенсивность всех 3х компонентов.

nick

> передача информации по SCSI шине быстрее чем по ethernet.

А вы полагаете, что в современных х86 узким местом при кодировании является скорость передачи данных из-в, а не проц ?? Я вот этого как-то не заметил.. :-)

> Качественне в смысле оптимального поиска ключевых кадров

А разве есть кодеки (кроме дивикса, и мпг4), которые позволяют задавать произвольное расстояние между ключевыми кадрами ?? Я, признаться, думал, что это фишка divx'a... Да и не самая удачная/нужная, имхо...

> AFAIK - ffmpeg. По крайней мере там есть опция grayscale!

Спасибо, гляну новый ffmpeg. В старом я такого не нашел.

> Не RGB а YUV!

Я судил по divx'у. Он (4.12) у меня YUV и любые RGB, отличные от 24 бит брать отказался.

> В YUV чтобы получить черно-белое изображеие достаточно оставить только Y и выкинуть UV.

Спасибо, воспользуюсь.

>А вы полагаете, что в современных х86 узким местом при кодировании
>является скорость передачи данных из-в, а не проц ?? Я вот этого
>как-то не заметил.. :-)
Не сжатый поток с качеством mpeg2 (720x480@30fps) требует 31.1MB/sec
(как 720*480*3*30)
только для видео части! (Т.е. в терминах ethernet >200MBit/sec канал)
Не знаю как у других - у меня самая быстрая из доступных сетей
только 100MBit/sec)

>А разве есть кодеки (кроме дивикса, и мпг4), которые позволяют
>задавать произвольное расстояние между ключевыми кадрами ?? Я,
>признаться, думал, что это фишка divx'a... Да и не самая
>удачная/нужная, имхо...
Это - очень даже удачная фишка!
И она есть в любом mpeg кодеке mpeg1, mpeg2, mpeg4, divx, ...
(см. спецификацию на форматы на http://www.mpeg.org)

Ключевой кадр - кадр который кодируется целиком - аля jpg картинка
Не ключевой кадр - кадр хранящий только разницу между текущим (current)
и предыдущим (prev). Получается он очень просто - полный кадр делится
на квадратики размером 16x16 пикселей и далее кодируются только те
квадратики где есть изменения!
Теоретически можно все кадры обьявить ключевыми - это тормознет
скорость декодирования и многократно увеличит размер потока.
Можно обьявить ключевым только первый кадр а все остальные -
предсказанными, но при кодировании кадра, где все квадратики имеют
отличия как не ключевого, размер опять таки увеличивается!
Т.е. - самое оптимальное - это обьявлять ключевыми только те кадры
где картина меняется целиком ( например начало новой сцены )
У меня есть фильм где по задумке автора -есть статическая сцена
длительностью 15 секунд. Итого получаем 375 не ключевых кадров
нулевой длины. Если использовать фиксированное расстояние между
ключеывыми кадрами - получим лишних X кадров размером с .jpg файл.

Неудачная фишка mpeg4 - divx форматов - это то что для уменьшения
размеров фильма они могут замыливать 16x16 квадратики (в которых нет
резких деталей) а еще точнее - закрашивать их каким-то одним цветом!


P.S.: Никогда не увлекался вопросами encoding'а, но mencoder
поддерживает 2pass encoding и имхо не случайно.

nick

> Не сжатый поток ... требует 31.1MB/sec

Ну мы же вроде как решили, что обсуждаем сжатие без относительно захвата видео. А скорость передачи данных память-проц AFAIK еще на EDO была под 90 MB/sec. И совсем не обязательно передвать по сети данные в чистом виде, их очень даже можно предварительно пожать. Я скажем капчурую вильм в формат с уже минимальным сжатием (иначе у меня может и винта не хватить :-)) ) А двухгиговый файлик у меня с машины на машину передется куда как быстрее чем жмется.

> и далее кодируются только те квадратики где есть изменения!

Дык в этом то и весь прикол. Если видеопоток был получен отснятием чего-либо реального чем-нить цифровым или оцифровки уже снятой пленки/сигнала, а не получен на компе в результате работы художника, то два кадра одного и того же объекта в одних и тех же условиях будут неизбежно хоть на бит в одном из цветов, но отличаться. Так что не так просто получить кадры нулевой длины.