?

Log in

No account? Create an account

Previous Entry | Next Entry

В прошедшую субботу мы провели закрытые семинары для организаторов компьютерного фестиваля Chaos Constructions. Часов семь обсуждали различные вопросы, весьма продуктивно. Среди прочего, обсуждалась проблема показа на фестивале конкурсных работ, заставок, видеороликов. На данный момент существуют три варианта её решения: 1) Старый, весьма неудобный и негибкий (как на CC4..CC8) 2) Использование PartyMeister/Boobs 3) Создание собственной системы. Random рассказал про второй вариант (в рамках рассказа про PartyMeister), я - про первый и третий.
В этом посте я решил написать об этих вариантах более развернуто.
 

КАК БЫЛ РЕАЛИЗОВАН ПОКАЗ РАБОТ ДО СИХ ПОР
Начиная с CC'2004 в организации произошли значительные позитивные (если сравнивать с E'95-97 и CC'99-01) изменения. В том числе, это коснулось показа конкурсных работ и различных видеороликов.
Показ вёлся с двух одинаковых компьютеров, видеовыходы которых вручную коммутировались на проектор Большого Экрана и контрольный монитор. На компьютерах стоял Windows Media Player с необходимыми кодеками. Оба компьютера были объединены локальной сетью (максимально достижимой пропускной способности) с файлсервером и компьютером видеомонтажа.

Конкурсные работы регистрировались на сайте (авторами либо нами). Для каждой работы дополнительно указывался файл который будет показываться, порядковый номер показа и время его показа. Поддержание актуальности базы по сотням работ (причём на фестивале эти данные регулярно менялись и уточнялись) было отдельной сложной организационной задачей.
Для demo, intro и игр файл для показа нужно было ещё получить. На CC4,5,6 применялась (с небольшими вариациями) следующая технология:

На одном компьютере запускалась работа. S-Video выход видеокарты этого компьютера был подключён к S-Video входу mini-DV видеокамеры. Firewire выход видеокамеры был подключён ко второму компьютеру, на котором получаемый DV поток (в котором каждый кадр является кейфреймом) писался в .avi файл. Далее от файла отрезалось лишнее в начале и в конце и он перекачивался на одну из машин показа.

Эта технология позволяла а) избежать проблем с зависанием и сбоями demo/intro б) полностью автоматизировать сам процесс показа.
Однако позднее мы отказались от неё по следующим причинам:

а) Качество видео получаемого с S-Video выхода недостаточно высоко для показа на большом экране (хуже 800x600), соответственно некоторые работы выглядили "замыленными". В случае со Спектрумовскими работами дополнительно возникали проблемы с некорректным видеосигналом и хитрыми видеорежимами (например, получения большого числа цветов за счёт быстрой смены двух картинок).
Бытовых HD видеокамер на тот момент не существовало, а запись и обработка видеосигнала SVGA качества требовала профессионального оборудования, нам абсолютного недоступного.

б) Размер получаемых DV avi файлов измерялся гигабайтами, из-за чего их оперативная передача по локальной сети была неразрешимой проблемой. 100 мбитная сеть не справлялась с такими потоками в принципе. Гигабитная теоретически могла бы, но это требовало нормальных сетевых карт и нормальных роутеров (т.е. от них требовалось нечто большее, чем надпись "1Gbit"), так что по факту гигабитной сети тоже было совершенно недостаточно. Кроме того, сам процесс перекачки файла на диск компьютера приводил к заметным замедлениям и рывкам при проигрывании другого файла на нём же.
Поскольку передача больших объемов данных интересовала нас ещё и с точки зрения оперативной подготовки и показа видеорепортажей, мы искали пути решения проблемы. Всерьёз рассматривались два варианта: сети хранения (аренда дисков и контроллеров для них оказалось слишком дорогой - их толком ни у кого в городе не было) и передача данных через FireWire. Второй вариант показался нам довольно интересным. Суть в том, что по FireWire, взависимости от стандарта, при некоторых условиях можно достичь скоростей близких к теоретическим 400-800mbps. Для этого все компьютеры вешаются на одну шину, хабы не используются - соответственно между рядом стоящими компьютерами скорость обмена будет очень высокой. Увы, при дешевизне и простоте решения оказалось, что Windows XP, несмотря на заявленную поддержку, не может устойчиво работать с сетями на Firewire.
В итоге использовалась комбинация обычного ethernet'a и внешних USB дисков.
Здесь стоит сразу отметить что вариант пережатия DV потока в MPEG-2 непосредственно в процессе получения данных с камеры тоже не подошёл (в первую очередь из-за стоимости оборудования, которое могло бы это делать в реальном времени).

в) Поскольку невозможно было добиться чёткого выполнения deadline'a на приём работ, некоторые вещи приносились за несколько часов до соответствующего конкурса (тоже касается Realtime конкурсов). Оцифровка в таком темпе требовала наличия свободных компьютеров и чрезвычайно слаженной работы организаторов. В совокупности с проблемами перекачки данных это приводило к значительным задержкам начала конкурсов (может быть, за исключением CC5) .


В итоге, начиная примерно с 2007 года от оцифровки работ в DV файлы мы отказались (за исключением съёмкой камерой демок и игр с мобильных телефонов и КПК). Для показа нужной работы, после демонстрации заставки, происходило ручное переключение коммутатора на комп-машину, на которой вживую запускалась работа. Соответственно, с этого момента мы стали использовать вместо S-Video сигнала обычный VGA.


Помимо самих видео/аудио/графических файлов нужно было также показывать заставки вида "Следующий конкурс __", "Следующая работа ___", "Вы смотрели работу _____". Эти заставки создавались по данным из базы данных при помощи картинок-шаблонов и PHP скрипта, через GD2. Дизайн заставок разработан iz0, кроме cc6 - там шаблоны были от I-FREE.

Итак, имея файлы для показа и данные по работам в базе данных, непосредственно перед конкурсом, генерился ASX файл.
ASX - это XML плейлист, в котором указано, какой видео/аудио/графический файл показывать и в течении какого времени. Кстати, возможность понимать плейлист с с принудительным ограничением на время проигрывания и умением корректно показывать графические файлы была одной из решающих в выборе именно WMPlayer'a.

Фрагмент ASX:

<ASX Version = "3.0">
<TITLE>Combined HandDrawn Graphics</TITLE>
<ENTRY CLIENTSKIP = "YES">
<TITLE>Заставка начала работы N 1: Clouds</TITLE>
<DURATION VALUE="00:00:10" />
<REF HREF="1_entrystart_1.png" />
</ENTRY>
<ENTRY CLIENTSKIP = "YES">
<TITLE>Пауза</TITLE>
<DURATION VALUE="00:00:02" />
<REF HREF="cc_blackscreen.png" />
</ENTRY>
<ENTRY CLIENTSKIP = "YES">
<TITLE>Работа N 1: Clouds</TITLE>
<DURATION VALUE="" />
<REF HREF="clouds.png" />
</ENTRY>
....
</ASX>


В итоге для того чтобы начать показывать конкурс мы должны иметь:
1) заставки по всем конкурсам и всем работам
2) показываемые файлы для всех работ
3) всё это должно находиться на диске одного из компьютеров показа.
4) должен быть сгенерён ASX плейлист
5) должен быть проведён ускоренный пробный показ по этому плейлисту, чтобы убедиться что нет битых или отсутствующих файлов.

Для чего нужны два компьютера показа? Во-первых, пока с одного идёт показ конкурса, на другой можно перекачивать файлы для следующего (и проверять их). Во-вторых, на втором компьютере можно показывать непредвиденные объявления и видеоролики которыми мы заполняли паузы между конкурсами, о чем скажем особо:
Постепенно у нас накопилась значительная база видео различных demo,intro (в виде avi), интересных видео на компьютерные темы. Для того чтобы каждый ролик предварялся заставкой с указанием его названия, автора и т.п., запускался скрипт для подготовки всё того же ASX плейлиста. Но информация для заставок в этом случае бралась не из базы, как для конкурсных работ, а из имён файлов самих видеороликов. Все они назывались в специальном формате вида:

64k_Paradise_by_RGBA_from_Euskal'2004_1p.avi
movie_Commodore_64_Orchestra.wmv
movie_Virtual_Megascreen_75x13_from_Assembly'2008.mp4
4k_Sincere_by_TBC_from_Solskogen'2008_2p.flv

и т.п.
(на данный момент это около 250 файлов общим объёмом порядка 50гб. Каждый продолжительностью 1..10 минут)
Перед фестивалем скрипт генерил по одному ASX на каждый видеоролик, так что можно было вручную выбрать любой и он автоматически показывался с нужными заставками и информацией. Так же можно было сгенерить ASX включающий тематически видеоролики (например, "вся реклама старых компьютеров")

Коммутация видеосигнала с компьютеров показа (и других источников, таких как видеокамеры) на проектор большого экрана осуществлялась так:
В 2004-2005-2006 годах - с помощью электромеханического переключателя S-Video сигнала (это давало срывы синхронизации и было опасно для электроники)
В 2007 (CCA7) году - сложная схема. Частично тот же переключатель, частично двухканальный электронный коммутатор, частично переключением входов проектора с помощью дистанционного управления (к проектору шли сразу два кабеля - S-Video и VGA).
В 2007 (CCH7) и 2008 году - новый Kramer'овский видео коммутатор VP-719XL , который мы купили для этой цели. В идеале, хотелось бы больше VGA входов, но по соотношению цена/возможности это был единственный приемлимый вариант.

Во всех случаях использовались S-Video и VGA кабели длиной 15-25 метров. На 25 метрах мы не наблюдали каких-либо значительных потерь качества, а кабели >25 метров в продаже не встречались. Замечу, что в 1997 году проблемы были даже на 10-15 метровых кабелях (в тех же видеорежимах). Очевидно, с тех пор либо кабели стали заметно лучше, либо в видеокартах что-то поменялось.
Отдельно стоит сказать про показ с не-PC компьютеров.

С ZX Spectrum (выход RGB и Sync) - использовался сначала композитный, а позднее S-Video сигнал. Это зависело в первую очередь от RGB-PAL кодера который удавалось найти или собрать.
С Commodore Amiga, Commodore 64 - поскольку там стандартный композитный и S-Video выходы, то никаких проблем не возникало.
С нестандартных устройств, мобильных телефонов, КПК - изображение снималось mini-DV камерой, непосредственно с экрана, затем скачивалось на компьютер.

Что касается переключения звука, то практически на всех CC он переключался и регулировался независимо от видео - обычным микшером (источники - компьютеры и радиомикрофон, выход на усилитель). Такой подход был признан удачным.
Последним звеном перед началом показа были люди. Должность ответственных за показ на всех CC была чуть ли не самой ответственной. Это были два человека так как один должен был всегда (12..16 часов в сутки, двое суток подряд) находиться около компьютеров показа. Они должны были обладать минимальным здравым смыслом для принятия решений что показывать в случае какой-либо заминки. Уметь чётко пресекать попытки других, пробегающий мимо, организаторов запустить на этих компьютерах что-либо или переткнуть какой-либо провод. Кроме того, они переключали видеокоммутатор и иногда делали объявления в микрофон. В разные года этим ответственным делом занимались: starguest, theta, alien, kirill, 3ym, pocomaxa.
Ремарки:
Вопрос с показом различных актуальных объявлений до сих пор так и не был полностью решён в разные годы для этого использовалось разное программное обеспечение, каждый раз неподходящее по разным причинам.
В 2006 году мы на один год схема была немного изменена, так как вместо WMPlayer'a использовался движок I-FREE. Двумя характерными последствиями были а) красивые анимационные заставки б) большое количество проблем с показом конкретным видео и графических файлов из-за того что не было времени протестировать и довести движок для нашей задачи.


ВАРИАНТ ПОКАЗА С ИСПОЛЬЗОВАНИЕМ PARTYMEISTER

Про Partymeister можно вкратце прочесть в другом моём посте. http://cr-it.livejournal.com/4276.html Что касается конкретно показа, то там используется подсистема Boobs http://www.partymeister.org/features_boobs.php , которая показывает видео через FFMPEG.
Из плюсов:

- Умеет красиво показывать заставки и переходы между роликами (OpenGL)
- Вроде бы есть плагин для показа SWF (не проверялось)
- Поскольку неоднократно использовалась на зарубежных demo party, то как минимум базовому набору требований удовлетворяет.
- Можно назначать плейлисты на разные машины показа (т.е. разные проекторы)

Из минусов:

- Поддержка видеоформатов ограничена (относительно, к примеру, WMP с набором кодеков). Хотя, все основные поддерживаются.
- Удалённое управление сделано довольно примитивно. Клиента как такового нет (управлять можно из вебинтерфейса partymeistera). Связь с управляющей машиной осуществляется через shared директорий, что предъявляет определенные требования к конфигурации сети (Oldayn, Random могут дополнить).
Поскольку способ управления недокументирован, написать свой клиент невозможно.
- Автор отказывается (или не имеет возможности) поделиться исходниками
- Веб интерфейс работает только с мозиллой
- Проблемы с русскими буквами


ВАРИАНТ ПОКАЗА С РАЗРАБОТКОЙ СОБСТВЕННОЙ СИСТЕМЫ


Итак, задача формулируется следующим образом - необходимо удалённо (через локальную сеть) управлять программой-video-player'ом. При этом:

а) возможность добавления в плейлист указанных файлов, типичные операции типа PLAY, STOP, PAUSE, MUTE, REWIND, причем вмешательство в проигрывание в любой момент (с задержкой не хуже секунды), регулярное получение информации о состоянии плейера (что именно играется, на какой секунде).
б) плейер должен понимать разнообразные видео-аудио и графические форматы (как минимум любые, для которых установлены соответствующие кодеки) и адекватно их отображать (к примеру, если формат jpeg'а не соответствует формату экрана - не должно быть геометрических искажений).
Предлагаемое мной решение использует Windows Media Player по следующим причинам:
1). Он имеет ясно и чётко документированный API для управления из JS ( [1] , [2] )
2). Надёжно и устойчиво работает, что было проверено как минимум на четырёх CC (с оговоркой, что ставить его рекомендуется на чистые WinXP, только с необходимыми для работы кодеками и не подсовывать битые видеофайлы).
3). Понимает большое количество аудио, видео, графических форматов (в т.ч. SWF).
Схематически решение изображено на рисунке. На словах идея в следующем:
Есть три компьютера - компьютер управления, сервер, компьютер показа (функции любых двух можно объединить в одном, но решение потеряет некоторые вкусности).
На компьютере показа, с которого будет проигрываться контент, делаем HTML страничку, в которую вставляем (через <OBJECT>) Windows Media Player. Там же пишем немного Java Script'a, который каждую секунду дёргает PHP скрипт на сервере чтобы а) узнать, не появилось ли новой команды б) передать обратно текущий статус плейера.

На компьютере управления запускаем клиент (например, на Flex'e, хотя можно на чём угодно, хоть в виде простой HTML формы) с функциональностью плейлиста, кнопок PLAY, STOP, и т.п., выбора файлов и их добавления/удаления из плейлиста.
При нажатии на кнопки, изменении плейлиста, клиент дёргает PHP скрипт на сервере, который добавляет полученную команду в очередь (реализованную в виде таблицы в БД или в виде файлов на диске) и возвращает текущий статус плейера.

Сервер тут нужен для двух вещей: 1) чтобы как-то связать два клиента (основная причина) 2) для повышения гибкости системы - например чтобы можно было команды через открытый Интернет передавать (это уже бонус).
Дополнительные плюсы всего решения:
а).Может быть сколько угодно каких угодно клиентов. Например, можно сделать клиент для мобильного телефона и с него управлять проигрыванием на большом экране (может быть удобно когда берёшь интервью и нужно в определённый момент остановить показываемый видеоролик или показать нужную заставку).
б) Может быть сколько угодно компьютеров показа - как с индивидуальными плейлистами, так и одинаковыми. И управлять ими можно как с одного компьютера (запустив несколько клиентов), так и с разных. В любой комбинации
в) Посетителям фестиваля и сайта можно в реальном времени отображать информацию о том, что в данный момент на каком экране показывается, что показывалось и что планируется показать следующим.
г) Используя показ SWF'ок (что умеет Windows Media Player, при некоторых дополнительных усилиях) можно показывать красиво оформленные тексты которые будут браться непосредственно из базы данных (текущий график фестиваля, следующая работа, предыдущая, срочные объявления и пр.)
Минусы:
а) Надо программировать (мною был написан пример, демонстрирующий работоспособность решения, но до конечного, вдобавок надежно работающего варианта - как до Луны).
б) Не является комплексным решением по организации фестиваля (по сравнении с PartyMeister'ом).
Решение может быть несколько модифицировано, если использовать другой плейер или другие способы управления плейером. Единственной известной альтернативой теоретически отвечающей основным критериям является VLC Player. Им можно управлять извне, но документация на этот счёт невнятная.

Лирическое отступление:

Между прочим, интересующимся ещё не поздно влиться в стройные ряды организаторов Chaos Constructions. Только надо хорошо понимать, что никаких денег это не принесёт. А вот работать придётся. И делать не всегда то, что нравится.
В чём же тогда смысл - объяснять не буду. Пусть вливаются те, кто это понимает, или хотя бы догадывается :)

Tags:

Comments

( 29 comments — Leave a comment )
kgbplus
Dec. 17th, 2008 09:33 am (UTC)
mpc тоже управляется удаленно. примерно так же, как и vlc
cr_it
Dec. 17th, 2008 10:28 am (UTC)
Сразу два вопроса - что есть mpc (ссылку давай). Второй - по большому счёту я так и не нашёл информации о том как управлять vlc. Из документации это не ясно (мне), а предложивший это aim вдруг замолчал когда я начал уточнять конкретику :-)
kgbplus
Dec. 17th, 2008 11:13 am (UTC)
Media Player Classic http://mpc.darkhost.ru/
можно много говорить о плюсах и минусах. показывает много того, чего не показывает wmp, имеет удаленное управление и т.п. я с ним разбирался немного в октябре (нужно было показ организовать), но не понадобилось.
Про vlc могу поискать, вроде тоже одно время разбирался, но уже не помню. Кстати, про vlc я говорил еще перед СС этого года, куда меня послали помнишь? =)
cr_it
Dec. 17th, 2008 01:36 pm (UTC)
Ага, я сходу не понял что такое mpc.
ОК, скачал только что свежий дистрибутив, поставил. Подсунул ему .png файл - cannot render. Дальше смотреть не стал. Почему-то я уверен, что ты сам и не пытался проверять, отвечает ли он нашим требованиям к показу работ. А предлагаешь как решение.
Точно так же и aim - публично предлагает vlc, а, как выясняется, сам он даже доку по нему не читал в смысле управления. И том что не пробовал - я уже не говорю.
Грустно всё это, товарищи.. Серьёзнее надо быть.


Edited at 2008-12-17 01:47 pm (UTC)
kgbplus
Dec. 17th, 2008 01:57 pm (UTC)
Петр, я ничего не предлагаю. В общем твою мысль я понял...
_dyn
Dec. 17th, 2008 10:43 am (UTC)
Не очень понятно зачем необходимо отдельно выделять сервер.
Судя по диаграмме. на сервере, фактически, не производится никаких действий кроме переадресации и стека запросов. Поэтому клиент может напрямую общаться с совмещенной машиной сервер-показ.
Связывание нескольких машин (то, что указано в плюсах разделения) может быть сделано в самом клиенте, ибо все равно в случае поддержки нескольких машин это все равно придется выводить на клиенте.
Или под связыванием понимается что-либо более функциональное?

Единственное, исходя из прочитанного, для чего, на мой взгляд, может быть необходим сервер из диаграммы - для хранения списка машин показа, но тогда проще файлик положить в общий доступ :)
cr_it
Dec. 17th, 2008 01:39 pm (UTC)
Сервер нужен для того, чтобы связать два клиента (клиент управления и WMPlayer). То, что сервер может быть на машине показа - у меня явным образом написано. Просто это ничего принципиально не меняет в логике решения (зато из-за частых запросов к базе может начать дёргаться проигрывание).
_dyn
Dec. 17th, 2008 01:49 pm (UTC)
"зато из-за частых запросов к базе может начать дёргаться проигрывание"
Во первых, приоритет приложения никто не отменял.
А во вторых, откуда там частые запросы? Не верю, что плейлист будет изменяться с средней скоростью чаще чем раз в 15-20 секунд.

Ну в общем на самом деле конечно, это не самое принципиальное. Просто как уже писал ниже - к чему усложнять цепочку, тем более, что на машине просмотра тоже будет вебсервер?
Хотя в вышеупомянутом mplayer по ходу возможно просто порт открыть.
cr_it
Dec. 17th, 2008 09:52 pm (UTC)
Как часто будет меняться плейлист - не имеет значение. Просто информация туда и обратно должна поступать не реже раза в секунду (лучше чаще). Чтобы если оператор захочет остановить показ или запустить - реакция системы была не хуже секунды. И, соответственно, если файл закончил играться - узнать об этом тоже надо как можно быстрее.
Приоритеты приложений здесь погоды не сделают. У тебя в любом случае один диск.
Я на самом деле не говорю, что оно обязательно будет дёргаться. Но может. Мой вариант в качестве промежуточного звена использовал файлы - там всё было нормально. Но обращение к базе - это совсем не то что обращение к файлу..
Про mplayer (mpc?) я уже писал.
_dyn
Dec. 17th, 2008 10:20 pm (UTC)
"Приоритеты приложений здесь погоды не сделают. У тебя в любом случае один диск."
Это ты зря. Диск-то конечно один. Но разные процессы получают к нему доступ в разное время. А у проигрывателей к тому же всегда есть буфер в несколько секунд. Я понимаю, что речь не идет об обязательном присутствии лага, но это как раз и есть та "подстраховка".

про media player classic:
у меня открылся на проверку jpg и png
вообще проехали с ним :)
_dyn
Dec. 17th, 2008 10:50 am (UTC)
да и еще в схеме есть потенциальный минус - цепочка длиннее.

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

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

Пример, конечно слегка утрированный, но я думаю понятный.
cr_it
Dec. 17th, 2008 01:46 pm (UTC)
Хотя, повторюсь, то где именно будет находиться серверная часть - вопрос непринципиальный, проблема о который ты пишешь (если я правильно понял смысл) решается на уровне протокола взаимодействия. Пакеты поступающие в очередь можно помечать номером или датой/временем и в случае пропадания сервера, будет известно на каком пакете это произошло, соответственно возобновить заполнение очереди и показ можно с нужного места.
Да неважно это, на самом деле. В случае проблем с сервером или машиной показа показ просто будет остановлен на текущем пункте плейлиста и всё. При восстановлении - вручную продолжен. Всё равно проблемы с любой из машин будут решаться вручную. А что именно показывать при возникновении этих проблем - прописывается в логике JS на странице с плейером.
_dyn
Dec. 17th, 2008 06:55 pm (UTC)
кстати, а PHP/JS/FLEX это принципиально? :)
cr_it
Dec. 17th, 2008 09:58 pm (UTC)
строго говоря - нет. Просто надо учитывать что выбранная платформа:

1.Должна позволить реализовать то что нужно
2.Быть простой в установке (на сервер, имею ввиду)
3.Должны быть люди которые будут под неё писать.

Если PHP можно заменить на какой-нибудь Perl или Python (правда зачем..), то на что ты будешь менять JS и Flex? Кроме JS можно управлять WMP из веб страницы, видимо, только ASP. Что касается клиента, то он по-любому должен быть rich. Т.е. это либо традиционные delphi/c, либо Flex/Silverlight/Java. Учитывая предназначение этой вещи, Java я бы сразу исключил. Под Silverlight программеров искать будет непросто. Писать это на Delphi/C - просто неэффективно с точки зрения процесса разработки (тот же результат будет достигнут несопоставимо большими усилиями).
Короче в таком духе соображения.
_dyn
Dec. 17th, 2008 10:09 pm (UTC)
ну я имел ввиду silverlight + asp.net
и то, и другое первым двум пунктам вроде не противоречит (windows media player отлично управляется из .net).
ну а по поводу третьего - я готов за это взяться. собственно веб разработка используя дотнет это сейчас моя работа :)

"Под Silverlight программеров искать будет непросто."
Если учесть, что под него пишется на .net языках - не так уж и сложно. просто для большинства народу silverlight еще в диковинку. :)
cr_it
Dec. 18th, 2008 11:49 am (UTC)
А как будет выглядеть в этом случае серверная часть? Ставить IIS не предлагай :) Или будет законченное приложение которое при запуске будет сервером?
_dyn
Dec. 18th, 2008 01:52 pm (UTC)
Т.е. апач поставить на виндовую машину это не проблема? А встроенный IIS - не предлагать? :)

В принципе можно работать по сокетам. Это тоже не особая проблема. Просто не понятно, чем iis не угодил :)
cr_it
Dec. 18th, 2008 02:35 pm (UTC)
Встроенный во что?
Апач я не планировал ставить на винды (хотя можно конечно - на моём ноуте стоит). Это ты предложил совместить сервер с плейером :)
Идеальный вариант был бы конечно в виде .net приложения которое бы принимало-передавало команды-статус через сокеты и управляло WMP. Без установки отдельно сервера.
_dyn
Dec. 18th, 2008 03:20 pm (UTC)
встроенный в винду.

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


вообще, можно и через сокеты. Даже наверно лучше.

зы. еще сразу вопрос - сервер на винде планировался или нет?
cr_it
Dec. 21st, 2008 03:00 am (UTC)
Если отдельный - то конечно не на винде. Если на той же машине, что и плейер, то на винде.
Короче говоря, сможешь написать приложение которое бы через сокеты принимало команды и передавало WMP?
_dyn
Dec. 21st, 2008 02:04 pm (UTC)
да. не вопрос.
главное определиться с форматом данных передаваемых по сокетам.
cr_it
Dec. 21st, 2008 08:47 pm (UTC)
Было бы удобно (и просто в разработке) если бы эта программная часть между портом и собственно плейером была практически прозрачной. Т.е. команды и данные которые я через сокеты буду в порт писать - тупо соответствовали тому, что умеет плеер по документации на API. И то что обратно отдаёт - тоже.
_dyn
Dec. 21st, 2008 10:43 pm (UTC)
Что значит соответствовали тому, что умеет плеер?
Ты хочешь писать название метода и параметры к нему в сокеты? А смысл? Большая часть функционала все равно останется за кадром и соответственно специализированных параметров.

зы. Скачал windows media player control. Через несколько дней напишу подетальнее.
cr_it
Dec. 25th, 2008 10:14 pm (UTC)
Смысл в том, чтобы не изобретать дополнительно какие-то свои команды для записи их в сокеты, а просто предоставить возможность посылать и принимать всё, что описано в доке. Это и программировать проще и не надо думать что понадобится в будущем, а что нет..
_dyn
Dec. 26th, 2008 08:45 am (UTC)
по несколько дней я слегка ошибся. перед новым годом куча всяких дел навылезало. так что после нового года примусь.

вообще тут вопрос не стоит в том, чтобы изобретать или не изобретать. в любом случае команды поступающие с сокета необходимо преобразовывать в вызовы команд контрола.
Вообще может ты говоришь о каких-то других доках. Кинь, пожалуйста, ссылку на те доки, о которых идет речь. Те, что с описанием всех доступных функций api. А потом, если не сложно, как в твоем понимании выглядит пакет, который "необходимо просто преобразовать".

"Это и программировать проще и не надо думать что понадобится в будущем, а что нет.."
Первая часть предложения попросту заблуждение, а вторая - правильно, думать в будущем не надо - надо описать функционал сразу. А по поводу расширений - если расширится функционал все равно придется делать изменения. Либо с одной строны, либо с другой.
vrusinov
Dec. 18th, 2008 06:54 am (UTC)
Касательно плееров - очень хорошо управляется mplayer (по крайней мере unix-версия), если не ошибаюсь управление своится к popen() mplaer'а с опцией -slave и чтения/запись в отрктый пайп.
Касательно форматов - вопроизводит практически все на что есть кодеки (с оговоркой на контейнеры, но все основные поддерживаются).

Под Linux весьма неглючен (с нормальными файлами) и стабилен.
cr_it
Dec. 18th, 2008 11:55 am (UTC)
Понимаешь, как я и Oldayn говорили уже многим - "ты лично проверял этот player на соответствие нашим критериям"?
Просто плейеров расплодилось огромное количество. Но 99% - это поделки, которые совершенно не предназначены (и непригодны) для серьезного использования. Пишутся они из расчёта "фильмы посмотреть, музыку послушать" на домашнем компьютере.
В своё время мы с Oldayn'ом пересмотрели кучу плейеров (под Linux - он смотрел) и сейчас посматриваем иногда. Но общая ситуация достаточно уже прояснилась. Каждое новое предложение плейера заканчивается после его просмотра в течении 5 минут после установки (ты наверное видел в соседней ветке - предложили современный mpc, он просто сходу не смог показать наугад взятый png'шник).
die_tinte
Dec. 21st, 2008 06:34 pm (UTC)
По Патимейстеру:
А не придется ли переводить на русский пати-интерфейс? там не так много, но все таки.

cr_it
Dec. 21st, 2008 06:48 pm (UTC)
Вопрос действительно интересный, т.к. у нас далеко не все посетители/участники понимают английский.
To Oldayn, Random: вы смотрели, там есть многоязычность - вынесены сообщения в отдельный файл?
( 29 comments — Leave a comment )