События, Информационные технологии, LiveJournal cr_it - архив

15 декабря 2008, 20:32 (5851 день назад, №8751)Процесс показа работ и видео на Chaos Constructions - технологии и организация

В прошедшую субботу мы провели закрытые семинары для организаторов компьютерного фестиваля 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. Только надо хорошо понимать, что никаких денег это не принесёт. А вот работать придётся. И делать не всегда то, что нравится.
В чём же тогда смысл - объяснять не буду. Пусть вливаются те, кто это понимает, или хотя бы догадывается :)

Опубликовано: Пётр Соболев