Система вещания на основе Windows Media Services 9. Часть 2

МИХАИЛ ПЛАТОВ

Система вещания на основе Windows Media Services 9
Часть 2

В прошлый раз (см. №4 за 2005 г.) мы установили медиасервер, настроили многоадресное вещание с TV-тюнера и обеспечили on-demand доступ к небольшой видеотеке. Сегодня мы продолжим наше знакомство с Windows Media Services 9, в процессе которого создадим маленькую радиостанцию, а также рассмотрим варианты настройки «живого» вещания с веб-камер.

Делаем радиостанцию

Для нашей радиостанции мы будем использовать набор файлов, расположенных в определенной папке жесткого диска. Несмотря на то что сервер Windows Media позволяет организовывать вещание музыкальных файлов, хранящихся как в формате .mp3, так и формате wma, предпочтительным является использование «родного» формата – wma. Дело в том, что при использовании файлов mp3 вещание все равно будет вестись в формате wma, при этом сервер «на лету» будет перекодировать поток в wma. Кроме того, при предоставлении доступа к сервису из Интернета настоятельнол рекомендуется использовать файлы, закодированные с одинаковым битрейтом, иначе при переключении между композициями битрейт будет «скакать», что вряд ли обрадует пользователей, подключенных через низкоскоростное соединение.

Любителям командной строки посвящается

Надеюсь, я смог убедить вас в том, что для организации вещания необходимо заранее перекодировать все имеющиеся файлы в формат .wma с жестко заданным битрейтом (например, 32 Кбит). Для решения этой задачи теоретически можно воспользоваться уже знакомым нам интерфейсом кодировщика Windows Media Encoder, однако на практике так лучше не делать. Интерфейс не позволяет выбрать для кодирования сразу несколько файлов (или папок), поэтому такой процесс перекодирования может несколько утомить. Но тот факт, что «интерфейс не позволяет», еще не означает, что «кодировщик не умеет». В нашем случае необходимой функциональностью обладает скрипт WMCmd.vbs, входящий в стандартную поставку кодировщика Windows Media Encoder. Данный скрипт написан на Visual Basic и является не чем иным как «оберткой», использующей те же самые COM-объекты графического приложения Windows Media Encoder. Файл скрипта располагается в папке установки кодировщика (по умолчанию это C:Program FilesWindows Media ComponentsEncoder), а для его запуска используется «консольный» сервер сценариев WSH (Windows Scripting Host.) – cscript. При запуске без параметров (cscript WMCmd.vbs) кодировщик сообщит о возможных ключах вызова.

Полный список ключей очень велик, поэтому позволю себе привести пример вызова данного скрипта, при котором кодировщик в два прохода перекодирует содержимое папки c:music_mp3 к формату .wma с постоянным битрейтом 32К:

cscript WMCmd.vbs -input "e:\music_mp3" -output "e:\music_wma" -a_mode 1 -profile a32

Пишем ноты для оркестра

Таким образом, подготовительная часть закончена, и теперь можно приступить непосредственно к настройке сервера. В принципе, для решения поставленной задачи вполне можно обойтись способом вещания всех файлов из папки, рассмотренным в предыдущей статье [1]. Но для разнообразия мы рассмотрим другой способ – с использованием серверных списков воспроизведения (server-side playlist). В этом случае из произвольного набора файлов, папок, потоков с кодировщиков и с других точек распространения можно собрать общий список воспроизведения, содержимое которого будет «вещаться» в указанном нами режиме (unicast или multicast) и порядке. Кроме того, вышеперечисленный контент можно дополнительно «разбавить» с помощью так называемых «рекламных заставок», (например, медиафайлы, описывающие нашу радиостанцию, рекламу спонсора или хостинг-провайдера).

Итак, откроем уже знакомую нам оснастку сервера Windows Media и создадим broadcast-точку вещания radio, работающую по списку воспроизведения (см. рис. 1).

Рисунок 1. Создание точки распространения для радиостанции

Выберем только что созданную точку вещания, перейдем на закладку «Source», нажмем на кнопку «View playlist editor», в появившемся окне выберем «Create a new playlist» и нажмем «OK». Перед нами предстанет окно редактора списков воспроизведения – Windows Media Playlist Editor. Интерфейс добавления объектов в список воспроизведения интуитивно понятен, а вот на типах добавляемых объектов остановимся более подробно. В редакторе play-листов можно определить элементы следующих типов:

• Media – основной элемент любого списка воспроизведения. Используется для указания медиа-ресурса (файлы, потоки с кодировщика или медиа-сервера и т. д.), вещаемого в сеть.
• Advertisement – позволяет вставить в список рекламный ролик. Данный пункт особенно интересен, когда в качестве источника рекламных вставок используется ASP- и CGI-скрипт.
• Sequence – объект-последовательность. Определяет последовательность воспроизведения. Все медиа-источники, перечисленные в рамках элемента sequence, будут воспроизводиться в строго указанном порядке.
• Switch – объект-переключатель. Позволяет определить «альтернативные» медиа-источники, которые будут использованы в случае, если основной источник будет недоступен. Данный объект очень полезен при организации вещания «живых» источников, например, его можно использовать для обработки ситуаций, в которых источник временно не доступен.
• Exclusive – позволяет определить набор медиа-источников, порядок воспроизведения которых может меняться (например, один медиа-файл может «прерывать» воспроизведение другого).
• priorityClass – данный параметр определяет, как один объект прерывает воспроизведение другого. Обычно он используется совместно с параметром Exclusive.
• clientData – позволит отображать дополнительную информацию (исполнитель, название альбома и т. д.) о медиа-источнике во время ее воспроизведения.

Итак, перейдем к созданию простого списка воспроизведения для нашей радиостанции. Первым элементом будет вступительная заставка (advertisement), объясняющая пользователю, к чему он подключился. Порядок воспроизведения файлов нам не важен, поэтому в качестве второго элемента выберем Directory и укажем папку, содержащую музыкальные файлы для нашей радиостанции.

Рисунок 2. Редактор списков воспроизведения

Сохраним список воспроизведения и перейдем к настройке параметров точки вещания.

Учим сервер «петь»

В предыдущий раз мы определяли параметры вещания в разделе «Properties» соответствующей точки распространения. Это место не является единственным. В Windows Media Services параметры точки распространения определяются на двух уровнях: для всего сервера и для каждой конкретной точки распространения. Параметры точки распространения (если, конечно, они заданы) имеют более высокий приоритет и переопределяют соответствующие настройки уровня сервера. В то же время некоторые из них (например, для плагинов протоколов HTTP, RTSP и MMS встроенные парсеры медиа-форматов mp3, jpeg и др.) можно задать только для сервера. К серверным настройкам мы еще вернемся, а пока займемся точками распространения.

Первым делом включим режимы «Loop» и «Shuffle» (чтобы медиа-файлы бесконечно долго воспроизводились в случайном порядке). Для этого соответствующим образом изменим параметры плагина: «Playlist Transform -> WMS Playlist Transform -> Properties».

В разделе «General» отключим опцию «Start publishing point when first client connects» (для работы в режиме multicast) и включим опции «Enable Broadcast Auto-Start» и «Enable Advanced Fast Start».

Перейдем к настройкам аутентификации. В Windows Media поддерживается три варианта аутентификации:

• Anonymous. При использовании данного варианта доступ к медиа-файлам осуществляется с правами заданного для точки вещания (или для всего сервера) пользователя. Схема удобна при организации доступа к ресурсу со стороны большого количества пользователей, в особенности из Интернета.
• NTLM/Kerberos. Способ удобен при разграничении прав доступа к контенту для клиентов, находящихся в одном домене (или в доменах, с которыми установлены отношения доверия). Как следует из названия, при аутентификации используются протоколы NTLM или Kerberos.
• Digest. Этот метод аутентификации применяется в тех случаях, когда использовать NTLM/Kerberos оказывается затруднительно. Например, при необходимости разграничить доступ к точкам вещания для клиентов, подключающихся через Интернет.

Мы планируем предоставлять открытый доступ к точке вещания для пользователей Интернета, поэтому включим плагин «WMS Anonymous User Authentication». При необходимости зададим имя и пароль для пользователя анонимного доступа. Также не лишней будет установка ограничений для точки вещания (раздел «Limits»). Разрешим два одновременных подключения с суммарной пропускной способностью не более 70 Кбит. Для вещания в режиме multicast включим плагин «WMS Multicast Data Writer» (категория «Multicast Streaming»).

С помощью «Multicast Announcement Wizard» создадим файлы анонса, необходимые для доступа к точке вещания со стороны клиентов.

Рисунок 3. Вариант интерфейса музыкального сервера

После размещения этих файлов на веб-сервере мы получим собственную радиостанцию с доступом из Интернета, подключиться к которой смогут все пользователи, имеющие проигрыватель Windows Media Player 9 или выше.

Выбор веб-камеры

Согласно разработанному в прошлый раз «генеральному плану» [1], мы хотим организовать вещание с веб-камер, установленных в интересующих нас местах. Какую камеру выбрать, как правильно ее подключить? Постараемся разобраться в этом вопросе и посмотрим, какие типы решений присутствуют на рынке. Мне известно о существовании 3 типов веб-камер:

• Веб-камеры с интерфейсом USB. Самые дешевые представители камер данного типа не умеют ничего, кроме как показывать то, на что их настроили. «Продвинутые» модели данного вида могут комплектоваться более функциональным ПО, обладать более высокой разрешающей способностью, способны передавать звук и изменять угол обзора. Как самые дешевые, так и более дорогие USB-веб-камеры с легкостью используются в системах вещания на базе Windows Media, т.к. главным условием работы является наличие Capture-драйвера, осуществляющего захват картинки. Самый большой плюс камер данного типа – цена (от 30$), минус – расстояние, на которое такую камеру можно «отнести» от компьютера (по спецификации USB не более 5 метров).
• Веб-камеры c интерфейсом Ethernet. Данные камеры подключаются напрямую к сети Ethernet. Управление ими может осуществляться либо через встроенный веб-сервер, либо при помощи специализированного ПО, устанавливаемого на компьютер администратора. Некоторые модели имеют возможность записи по сигналу от встроенного детектора движения, что является немаловажным в системах наблюдения. Отличительным плюсом камер данного типа является то, что благодаря использованию интерфейса Ethernet, камеру можно «отнести» от компьютера-кодировщика практически на любое расстояние. Платой за такую «переносимость» является цена, которая в среднем превышает значения для аналогичных USB-собратьев.
• Беспроводные веб-камеры. Во многом похожи на камеры второго типа, за исключением того, что вместо проводного Ethernet 802.3 беспроводные камеры используют 802.11a/b/g. Соответственно, для них обязательным условием является наличие отдельного питания.

Теоретически в системах вещания на основе Windows Media можно использовать любые типы веб-камер, главное, чтобы на компьютере-кодировщике был установлен соответствующий драйвер захвата изображения (если для данного типа камеры он вообще существует). Если такой драйвер для камеры есть, то для просмотра «картинки» можно использовать не только прилагаемое в комплекте ПО (или встроенный веб-сервер), но и обычный проводник Windows и кодировщик Windows Media. Описываемая далее система вещания будет создаваться с использованием самых обычных (и, вероятно, наиболее распространенных) веб-камер Logitech QuickCam Express с интерфейсом USB.

Основная проблема при работе с USB-камерами – недостаточная длина USB-кабеля (все-таки на 1,8 метра особо не разгуляешься). Для ее устранения можно воспользоваться как минимум тремя способами:

• Способ 1. Кабель USB удлиняется с помощью обычных пассивных удлинителей, продающихся во всех компьютерных магазинах. Таким способом вы сможете увеличить длину кабеля еще метра на три. Еще немного (до +1 метра) вы выиграете, если самостоятельно изготовите USB-удлинитель, использовав при этом экранированную витую пару (STP). Хотя лучше, конечно, обратить внимание на следующий способ.
• Способ 2. Для увеличения длины USB можно использовать активные USB-удлинители. С их помощью удавалось «относить» камеру метров на 15 от компьютера. И хотя на некоторых форумах имеется информация о возможности достижения гораздо большей длины, все-таки использовать более 2 активных удлинителей лучше не стоит. Все-таки веб-камеры, как и активные USB-удлинители, для питания используют USB. Соответственно, при злоупотреблении вторыми питания камере может банально не хватить, а внешнего интерфейса питания на USB-веб-камерах обычно не бывает.
• Способ 3. Использование «специализированных» USB-удлинителей. С их помощью можно работать с USB-устройствами, отдаленными на достаточно большое расстояние (до 500 м) [2]. В состав таких удлинителей входят два модуля – локальный (устанавливается в компьютер) и удаленный (устанавливается поблизости от USB-устройства). Для соединения модулей используется либо обычная витая пара 5-й категории (до 100 м) либо оптоволокно (до 500 м). Использование такого рода удлинителей для веб-камер мне кажется несколько сомнительным хотя бы потому, что стоимость одного удлинителя скорее всего будет в несколько раз превышать стоимость веб-камеры.

Будем считать, что, используя вышеприведенную информацию, мы смогли выбрать и разместить камеры, и теперь самое время перейти к их настройке, но сначала:

«Обучаем» сервер

При работе с веб-камерами мы будем использовать режим «push», инициатором передачи в котором выступает сама машина с веб-камерой. Первое, что нам необходимо сделать, – создать «шаблон точки распространения», который будут использовать все кодировщики при создании собственных «точек» на медиасервере. Для этого откроем уже знакомую нам оснастку «Windows Media Services» и создадим точку распространения wc_template:

Рисунок 4. Создание шаблона push-вещания для веб-камер

Перейдем на закладку «Properties» и отредактируем параметры вещания. Для режима multicast необходимо определить следующее:

• Multicast Streaming -> WMS Multicast Data Writer -> Enable (в свойствах этого плагина включим «Enable unicast rollover» на ту же самую точку вещания).
• General -> Start publishing point when first client connects -> Disabled.
• Limits -> Limit player connections -> 2.

Для того чтобы картинка достигала клиента с минимальной задержкой, определим следующие параметры:

• Networking -> Enable buffering -> Disable buffering
• General -> Enable Fast Cache -> Disable
• General -> Enable Advanced Auto-Start
• Cache/Proxy -> Stream splitting expiration -> Immediately

Для предоставления доступа к веб-камерам из Интернета определим следующее: «Authentication -> WMS Anonymous User Authentication -> Enable».

На всякий случай настроим централизованную запись со всех веб-камер: «Archiving -> WMS Archive Data Writer -> Enable» (в свойствах плагина отметим «Start archiving when publishing point starts», а также при необходимости изменим путь расположения файлов архива).

Как нам уже известно, при использовании режима push, кодировщик сам «помещает» поток на сервер, при этом пользователь, с правами которого работает кодировщик, проходит аутентификацию и авторизацию (в режиме pull этого естетственно нет). Из соображений безопастности, при настроках по умолчанию только администраторы имеют право помещать медиа-потоки на сервер. А так как лишняя программа, работающая с правами доменного администратора нам не нужна, создадим обычного доменного пользователя webcams и добавим ему необходимые права.

На сервере Windows Media включим плагин: «Control protocol -> WMS HTTP Server Control Protocol -> Enable», с привязкой к порту с номером 7979.

Кроме того, определим следующие параметры для точки вещания:

• Authentication -> WMS Negotiate Authentication -> Enable.
• Authorization -> WMS Publishing Points ACL Authorization -> Enabled.

В параметрах плагина авторизации добавим пользователя webcams c правами allow: read, write, create. Откроем оснастку Component Services и в свойствах объекта: «Components Services -> Computers -> My Computer -> DCOM Config -> Windows Media Services», разрешим пользователю webcam удаленный доступ, запуск и активацию объекта.

Рисунок 5. Настройка безопасности DCOM-компонентов WMS

На этом процесс создания «шаблон вещания» будем считать законченным, самое время перейти к кодировщикам.

Настройка кодировщика

Отличия от уже рассмотренного нами в прошлый раз способа минимальны. Во-первых, при вещании можно не кодировать звук, т.к. используемая мною Logitech QuickCam Express (впрочем, как и подавляющее большинство недорогих USB-веб-камер) попросту не позволяет его записывать. Второе отличие заключается в использовании другого режима. При использовании режима push нам необходимо определить значения 3 параметров. В качестве «имени сервера» укажем полное DNS-имя сервера с WMS HTTP-портом:

wms.local.ru:7979

В поле «Publishing point» укажем имя точки вещания для данного кодировщика – wc1. В третьем поле укажем имя созданного нами шаблона – wc_template, параметры которого будут использоваться при создании точки вещания. Значение «Remove publishing point automatically» оставим без изменений и нажмем «Next». В следующих диалоговых окнах определим параметры сжатия и дополнительные атрибуты потока. При нажатии кнопки «Finish» кодировщик попытается соединиться с сервером и создать на нем собственную точку вещания. Если в процессе этой операции возникнут ошибки, то перед нами предстанет соответствующее сообщение. Например, вот такое:

Рисунок 6. Ошибка кодировщика

Если же все пройдет успешно, то мы увидим уже знакомый нам диалог анонсирования multicast-точек распространения. Создадим файлы анонса и поместим их на веб-сервер. При правильных настройках после нажатия кнопки «Start Encoding» кодировщик примется за работу, на сервере Windows Media автоматически активизируется точка вещания, и поток с камеры «польется» ко всем клиентам (не забываем, что мы используем multicast).

Когда возможностей кодировщка не хватает

Иногда при использовании служб Windows Media возможностей стандартного кодировщика оказывается недостаточно. Например, при организации вещания с большого количества веб-камер настраивать и запускать кодировщик вручную на каждой машине надоедает достаточно быстро. Кроме того, если для кодирования используются современные офисные машины (производительности которых с лихвой хватает для работы офисных приложений), то работающим за этими машинами людям может не понравиться постоянное присутствие «постороннего приложения».

Еще больше данная ситуация не будет нравиться администратору, которому для обеспечения нормальной работы камер придется «бороться» с пользователями, закрывающими «лишние окна». И хотя попытаться «скрыть» работу кодировщика можно и с помощью стандартных средств (например, при помощи описанной выше «VBS-обертки», работающей в командной строке), получить стабильно работающее решение таким способом вряд ли получится.

В этом случае на помощь приходит пакет Windows Media Encoder SDK. Как и другие пакеты для разработчиков, данный SDK содержит все необходимое для создания собственных приложений с использованием функциональности кодировщика Windows Media Encoder. Помимо исчерпывающей документации, описывающей интерфейсы объектов кодировщика, в состав SDK также входят законченные приложения и примеры вызовов методов объектов для трех языков программирования: C++, C# и Visual Basic.

С использованием этого богатого инструментария было разработано специальное приложение-кодировщик, обладающее следующими возможностями:

• Работа в качестве системной службы.
• Автоматическое возобновление сессии кодирования после сбоев (при временном извлечении камеры или потере связи с сервером).
• Работа со стандартными файлами кодировщика (.wme).
• Автоматическое создание файлов анонсов.
• Возможности журналирования и оперативного оповещения (системный журнал, e-mail).
• Автоматическая активация драйвера веб-камеры.

На данный момент приложение распространяется только в исходных кодах, для компиляции которых используется среда MS Visual Studio.NET 2003.

Использовать службу достаточно просто. Первое, что вам потребуется сделать, – настроить кодирование с требуемыми параметрами с помощью стандартного кодировщика Windows Media. Затем необходимо убедиться, что все работает как нужно, и сохранить настройки в файле с расширением .wme. После чего необходимо скомпилировать исполняемый файл службы и зарегистрировать его в системе с помощью прилагаемой утилиты (попутно указав имя учетной записи, с правами которой служба будет работать). Сразу же после этого, если все настройки заданы правильно, служба запустится, создаст все необходимые файлы анонсов и начнет кодирование. На сервере в это время будет активирована соответствующая точка вещания, и передаваемый поток станет доступен вам для просмотра:

Рисунок 7. Система вещания с веб-камер

Само приложение, а также инструкцию по его сборке и установке можно найти на сайте проекта [3].

Подводим итоги

Итак, теперь наш медиасервер способен передавать видео-данные с TV-тюнера (часть 1) и веб-камер, предоставлять совместный доступ к музыкальным файлам, а также к материалам маленькой видеотеки. Но не следует думать, что на этом возможности Windows Media заканчиваются. Вместе с технологией DRM (Digital Rights Managment) возможно создание коммерческих систем, совместно с Microsoft Producer for PowerPoint можно с легкостью организовывать вещание презентаций, а благодаря наличию хорошего SDK ко всем компонентам применение Windows Media ограничивается только одним – полетом ваших мыслей!

Литература, ссылки:

1. Платов М. Система вещания на основе Windows Media Services 9. – Журнал «Системный администратор», №4, апрель 2005 г. – 28-33 с.
2. http://www.ihse.de/russian/417-xx.htm.
3. http://sourceforge.net/projects/wcstreaming.