Система вещания на основе Windows Media Services 9::Журнал СА4.2005
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 2219
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 2207
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1762
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1277
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1826
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

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

Архив номеров / 2005 / Выпуск №4 (29) / Система вещания на основе Windows Media Services 9

Рубрика: Администрирование /  Продукты и решения

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

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

Вы когда-нибудь слушали интернет-радио? Смотрели любимые телепередачи через спутник или Интернет? Или, быть может, работали с системой видеонаблюдения через сеть? Если ответ на любой из этих вопросов положительный, можете смело причислять себя к пользователям систем вещания! Впрочем, даже если вышеприведенные вещи вам не знакомы, не расстраиваетесь, потому что после прочтения этой статьи вы не только узнаете, что это такое и как оно работает, но и получите представление о том, что происходит «по ту сторону кулис», а именно – о создании систем вещания. Предметом нашего изучения будет один из наиболее популярных продуктов организации систем медиавещания – Microsoft Windows Media Services 9.

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

А каким оно вообще бывает, это «вещание»? Человек, который работал с системами вещания на уровне пользователя, скажет «аудио и видео», люди, которые общались с ними с другой стороны, скорее всего, приведут иную классификацию – по способу доставки медиаданных:

  • системы с одноадресным вещанием (unicast);
  • системы с многоадресным вещанием (broadcast, multicast).

Для того чтобы понять, в чем заключаются плюсы и минусы каждого из способов, давайте более пристально посмотрим на процесс передачи данных. В случае одноадресного вещания данные передаются в рамках установленного TCP-соединения. Соответственно для каждого клиента, подключающегося к нашему серверу, будет создан собственный «канал», по которому клиент получит запрашиваемую информацию. На первый взгляд никаких подводных камней здесь нет, ведь этот же принцип лежит в основе большинства служб Интернета, однако с увеличением количества одновременно обслуживаемых клиентов начинает проявляться проблема, казавшаяся ранее несущественной. Давайте рассмотрим простой пример: пусть у нас есть один аудиопоток с битрейтом 64 Кбит, который необходимо доставлять 100 клиентам одновременно. Для решения этой задачи с использованием режима unicast нам потребуется канал с пропускной способностью 6,4 Мбит!

Во втором подходе данная проблема отсутствует, так как при использовании многоадресного вещания сервер передает данные либо сразу на всю подсеть (режим broadcast), либо на определенную группу многоадресной рассылки (multicast group, адрес сети класса D стандарта 802.3 Ethernet). Соответственно в нашем примере для передачи потока 64 Кбит от сервера требуется возможность обеспечить канал именно в 64 Кбит, независимо от количества подключенных в данный момент клиентов (0 или 10000). Минусом же является то, что сетевая инфраструктура, используемая для передачи вещаемых данных, должна быть соответствующим образом сконфигурирована для передачи multicast – трафика. Как правило, это легко достижимо в корпоративных сетях и с трудом реализуемо в масштабах современного Интернета (представьте себе dial-up-пользователя, который вынужден принимать multicast-поток от радиостанции провайдера при каждом соединении). Поэтому исторически сложилась следующая ситуация:

  • multicast используется в корпоративных сетях, при организации «вещания» для большого количества клиентов, получающих один и тот же неинтерактивный контент (интернет-радио, IP-телевидение, видеоконференции с большим числом «зрителей»);
  • unicast же используется при передаче в Интернете, а также для организации дополнительных сервисов, персонифицированных с конкретным абонентом (Video on Demand, Time Shift, и другие сервисы, при которых клиент может «управлять» передаваемым ему потоком).

А как же обстоит дело с реальными продуктами? Если рассматривать системы коммерческого видеовещания, то безусловными лидерами здесь являются компании Microsoft c продуктом Windows Media Services 9 (вещание в формате wma и wmv) и Real Media с системой вещания Helix Server (в самой функциональной редакции поддерживает вещание в 55 различных форматах). Оба решения поддерживают вещание как аудио, так и видеоданных, нацелены на один сектор рынка и архитектурно очень похожи.

Из «открытых» решений хотелось бы упомянуть о проекте VideoLAN [1], первоначально ориентированном на организации вещания спутниковых DVB-каналов в локальную сеть. На данный момент поддерживается гораздо большее число видов источников, все широкоиспользуемые форматы видеоданных (MPEG1, MPEG2, MPEG4, divx) и большинство распространенных кодеков.

Для поклонников Macintosh и формата QuickTime существует продукт QuickTime Streaming Server 5 (входит в состав Mac OS X Server) и его «открытый» брат Darwin Streaming Server (доступный в том числе и для x86), позволяющие распространять медиаданные в форматах MPEG4 и 3GPP (однако, по моим субъективным впечатлениям, функциональность Darwin Streaming Server сильно уступает ближайшим конкурентам от Microsoft и Real Networks).

Среди систем аудиовещания хотелось бы упомянуть NullSoft ShoutCast (продукт, созданный авторами Winamp) и Open Source-проекты iceCast [2] и SlimServer [3], описание настройки которой можно найти в [4]. На этом позвольте закончить теоретическое отступление и перейти к описанию нашего сегодняшнего героя – Windows Media Services 9.

Так вот он какой, серверный олень!

Windows Media Services (WMS) – это программный продукт, разработанный и распространяемый корпорацией Microsoft как средство для организации вещания аудио- и видеоинформации в локальных сетях, Интернете и беспроводных сетях. Данный продукт представляет собой набор компонентов, работающих под управлением различных версий операционных систем семейства Windows. Помимо средств, позволяющих быстро и просто организовывать различные виды вещания аудио- и видеоинформации, в состав WMS также входят компоненты, обеспечивающие тесную интеграцию с Active Directory и IIS, средства оценки и контроля производительности сервера, а также инструменты сбора статистики об общей работе служб. Серверная часть WMS является частью ОС Windows 2000 Server и Windows Server 2003. Клиентская же часть доступна практически для всех ОС от Microsoft (от Windows 9х до Windows Mobile 2005. Кроме того, поддержка видео в формате Windows Media присутствует в двух наиболее популярных проигрывателях для Linux – xine [5] и mplayer [6].

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

Рисунок 1

Рисунок 1

Итак, в состав Windows Media Services входят следующие основные компоненты:

  • Сервер Windows Media. Этот компонент по праву можно считать «сердцем» системы WMS. Именно он занимается организацией самого процесса вещания и отвечает за «раздачу» медиапотоков конечным пользователям. В качестве источника этих потоков могут выступать .wma-, .wmv- и .mp3-файлы (расположенные либо локально на самом сервере, либо на файл-сервере, доступном по протоколу SMB), а также потоки, получаемые с других серверов или непосредственно с кодировщика Windows Media. Ядро сервера реализовано в виде набора DCOM-компонентов и системных служб, для управления которыми используется стандартный для продуктов Microsoft инструмент – консоль MMC (Microsoft Management Console).
  • Кодировщик Windows Media. Задачей этого компонента является приведение информации к форме, пригодной для передачи сервером Windows Media, или, проще говоря, перекодирование входных данных (будь то аудио- или видеофайлы, сигнал с TV-тюнера или веб-камеры) в потоковый формат .wma или .wmv. Кодировщик распространяется свободно и может быть загружен с сайта Microsoft. В состав этого продукта входят две программы: Windows Media Encoder с графическим интерфейсом и консольный скрипт WMCmd.vbs на языке Visual Basic Scripting. Кроме того, с сайта Microsoft также можно загрузить пакет разработчика (SDK), содержащий все необходимое для разработки собственных приложений, использующих интерфейсы кодировщика Windows Media. Таким образом, можно добавить возможности кодирования в уже существующие приложения.
  • Проигрыватель Windows Media. Задача этого компонента в системе вещания достаточно очевидна – декодирование и воспроизведение потока информации, получаемого с сервера Windows Media. В качестве отличительных особенностей этого проигрывателя можно отметить поддержку защиты авторских прав (DRM) и потоковых кодеков Windows Media.
  • Веб-сервер. Играет вспомогательную функцию и используется для размещения информации об имеющихся на медиасервере потоках. В отличие от предыдущих компонентов в качестве веб-сервера может использоваться практически любой веб-сервер.

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

Тяжело в учении – легко в бою!

Однако прежде давайте определимся, что же мы все-таки хотим получить. Будем считать, что у нас есть маленькая корпоративная сеть, пользователям которой мы хотим предоставить следующие сервисы:

  • круглосуточное вещание музыки (локальный аналог интернет-радио);
  • multicast-вещание в сеть телевизионного канала с TV-тюнера;
  • multicast-вещание в сеть картинки с веб-камер, расположенных в интересующих нас местах;
  • доступ к обширному видеоархиву «важных производственных мероприятий».

Кроме того, будем считать, что у нас есть «толстый» канал в Интернет и нам не жалко отдавать наружу одновременно несколько потоков музыки и пару потоков с «избранной» веб-камеры, общим объемом не более 500 Кбит/сек. При реализации будем руководствоваться общей структурной схемой Windows Media Services (см. выше). Заметим, что для каждого «внешнего» устройства (TV-тюнера или веб-камеры) нам, скорее всего, понадобится отдельная машина. Аудиофайлы для радиостанции и файлы видеоархива будем хранить либо на самом медиасервере, либо на удаленном общем ресурсе (хоть бы и на самбе, включенной в Windows-домен). Также нам понадобится веб-сервер, в качестве которого мы для простоты будем использовать IIS6.0, установленный на компьютере с медиасервером (хотя все то же самое будет великолепно работать практически на любом Linux веб-сервере, включенном в Windows-домен согласно способу, описанному в [7]).

С постановкой задачи мы определились, и теперь можно плавно перейти к ее реализации.

Настройка сервера Windows Media

Сервер Windows Media Services поставляется вместе с операционной системой. Для его установки необходимо воспользоваться мастером установки и удаления компонентов системы: «Start –> Control Panel –> Add/Remove Programs/ Add/Remove Windows components».

Выберем пункт «Windows Media Services», нажмем на «Details» и выберем компоненты «Windows Media Services» и «Windows Media Services Snap-in». При нажатии кнопки «Next» выбранные компоненты будут установлены на компьютер. После завершения процесса установки в списке оснасток появится новая запись – «Windows Media Services», с помощью которой мы и будем управлять нашим сервером.

Рисунок 2

Рисунок 2

Проблем у нас пока нет, кэшировать мы тоже пока ничего не будем, поэтому прямиком направляемся в раздел «Publishing Points». В оснастке WMS точки распространения можно создать двумя способами: с помощью «мастера» и с помощью более функционального «диалогового окна». Интерфейс «мастера» вполне понятен и разобраться с ним самостоятельно не составит большого труда, а вот на содержимом «диалогового окна» хотелось бы остановится поподробнее.

Рисунок 3

Рисунок 3

Первым делом мы определяем тип точки распространения: В WMS их может быть 2:

  • Точки для «загрузки по требованию». Представляют собой инструмент для организации централизованных хранилищ медиаданных. Преимуществами таких хранилищ являются централизованный доступ к размещаемым медиаресурсам, возможность создания динамических play-листов с навигацией (остановка, пауза, переход к следующему файлу и т. д.) между ними, легкая интеграция с различными веб-приложениями, возможность контроля доступа к каждому ресурсу и т. д. Работа с такими точками распространения сильно персонифицирована, поэтому для передачи данных может использоваться только режим unicast. В нашем примере мы будем использовать on-demand точки распространения для создания маленькой корпоративной видеотеки;
  • Точки для «вещания». При использовании точек распространения этого типа возможна организация потокового аудио- и видеовещания (без возможностей остановки, пауз, перемотки и т. д.). В качестве способа доставки видеоданных может использоваться как unicast, так и multicast. Именно этот тип точек распространения будет основным при реализации описанных выше задач.

Затем мы определяем источник медиаданных. В качестве источников могут использоваться:

  • отдельный медиафайл;
  • папка с файлами;
  • play-лист;
  • cgi-скрипт, возвращающий play-лист;
  • кодировщик Windows Media Encoder;
  • другая точка распространения (unicast или multicast).

При использовании в качестве источника кодировщика возможны два способа получения данных: либо сервер WMS самостоятельно «забирает» поток (режим pull), либо активной стороной выступает кодировщик, помещающий поток на сервер и создающий соответствующую точку распространения (режим push). Все, что мы можем сделать – шаблон, который будет использован кодировщиком при создании точки на сервере.). Выбор того или иного режима определяется характером кодируемых данных. Так, если кодировщик работает постоянно (24/7), то имеет смысл использовать более легкий в настройке режим pull. Если же кодируемые данные носят периодический характер (несколько часов в день), то лучше использовать режим push. В нашем случае можно использовать режим pull для ретрансляции TV-канала, и режим push для веб-камер.

Итак, создадим on-demand точку распространения с названием «library», источником которой будет являться папка «c:library», содержащая архивные видеозаписи в формате wmv.

Рисунок 4

Рисунок 4

Теперь создадим анонс для точки вещания. Для этого перейдем в раздел «Properties» и в закладке «General» включим опцию «Enable access to directory content using wildcards». После этого перейдем на закладку «Announce» и нажмем на кнопку «Run Unicast Announcement Wizard». В качестве источников файлов выберем «All files in the directory», путь подключения оставим без изменений, для местоположения .asx-файла укажем одну из папок, доступную для веб-сервера. На завершающем шаге мастера убедимся, что флажок «Test files when this wizard finished» отмечен, и нажмем «Finish».

Рисунок 5

Рисунок 5

Если все было сделано правильно, то после нажатия на кнопку «Test» запустится Media Player, воспроизводящий play-лист, состоящий из всех файлов, находящихся в данной папке.

Перейдем к следующему номеру нашей программы – настройке вещания телевизионного канала с TV-тюнера. Для выполнения этого этапа нам понадобится машина с TV-тюнером. В моем случае это был AverMedia Model 203 с драйверами от Ивана Ускова [8].

Первым делом нам нужно установить кодировщик Windows Media Encoder 9. Для этого идем на сайт http://www.microsoft.com, вводим в поле поиска «Windows Media Encoder 9 download» и неспешно загружаем 10-мегабайтный исполняемый файл. После установки и запуска соответствующего ярлыка нас поприветствует очередной мастер настройки. Мы собираемся настраивать более чем «живое» вещание с TV-тюнера, так что выберем наиболее подходящий нам шаблон «Broadcast a live event».

Рисунок 6

Рисунок 6

С помощью соответствующих кнопок «Configure» настраиваем параметры TV-тюнера и звуковой карты. Нажимаем «Next» и переходим к следующему окну. Здесь мы выбираем режим доставки закодированного потока до сервера (pull или push). Выберем pull с портом 2187 и перейдем к следующему шагу – настройке кодеков. Из списка предопределенных шаблонов выберем Live broadcast video и CD Quality Audio для видео и звукового потока соответственно. Разрешение и битрейт оставим по умолчанию – 320x240 и 323 Кбит. Для всех остальных шагов оставим стандартные значения. После завершения мастера кодирования мы увидим следующее сообщение:

Рисунок 7

Рисунок 7

Вообще говоря, для того чтобы «вещать», не обязательно использовать сервер Windows Media. Можно настроить кодировщик на работу в режиме pull и подключать к нему клиентов напрямую. Однако в этом случае о таких вещах как «отслеживание обращений»,«ограничение пропускной способности», «аутентификация с Active Directory», «поддержка multicast» и других возможностях сервера придется забыть. Единственное, что будет нам доступно – возможность запрета/разрешения доступа к потоку кодировщика для конкретных IP-адресов через диалог «Broadcast security» из меню «Tools». Причем даже в нашем случае не лишним будет разрешить доступ к кодировщику только со стороны сервера Windows Media. Итак, после успешного завершения мастера перед нами предстанет картинка с TV-тюнера:

Рисунок 8

Рисунок 8

Далее нажмем на кнопку «Start Encoding» и перейдем к настройке сервера. На сервере нам нужно создать broadcast точку распространения с источником Encoder (Pull). В поле «Location of content» нужно ввести имя машины, на которой работает кодировщик в формате: http://ip_адрес:номер_ порта. Точка вещания создана, и теперь нужно отредактировать некоторые ее свойства. Для этого перейдем на закладку «Properties». В первую очередь нам нужно включить «WMS Multicast Data Writer» из раздела «Multicast Streaming» (там же указать адрес multicast группы и сетевой интерфейс, с которого будет производиться рассылка). При необходимости для данной точки распространения в разделе «Limits» можно задать ограничения на количество одновременно работающих клиентов и отводимой им пропускной способности. Наигравшись вдоволь с настройками, перейдем к следующему шагу – созданию анонса для multicast точки распространения. Для этого перейдем на уже знакомую нам закладку «Announce» и нажмем на кнопку «Run Multicast Announcement Wizard». На первом шаге мастера отметим пункт «Automaticaly create a web page», затем в окне «Stream Formats» добавим источник-кодировщик, точно так же, как и при создании точки распространения.

Рисунок 9

Рисунок 9

В диалоге «Save Multicast Announcement Files» выберем место сохранения файлов (внутри webroot веб-сервера) и перейдем к следующему шагу – диалогу выбора способа доступа к точке вещания. В нашем варианте мы будем обращаться к файлам через веб-сервер, поэтому выберем первый вариант, дополнительно удостоверившись, что имя сервера совпадает с тем, по которому будут обращаться пользователи. Для остальных вопросов используем стандартные ответы, в заключительном окне отметим пункты, отвечающие за активацию точки распространения и ее тестирование. Если все было сделано правильно, то, как и в первом случае, при нажатии кнопки «Test» напротив «Test announcement» запустится Media Player, в котором будет показываться картинка с TV-тюнера. Также можно протестировать веб-страницу.

Рисунок 10

Рисунок 10

В следующей статье мы продолжим изучение Windows Media Services 9 и подробно рассмотрим следующие моменты: настройка параметров авторизации и аутентификации клиентов, использование push-режима для кодировщика, unicast rollover, архивирование передаваемых данных, а также посмотрим, как можно использовать программные интерфейсы Windows Media Encoder 9 в собственных приложениях.

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

  1. http://videolan.org.
  2. http://www.icecast.org.
  3. http://www.slimdevices.com/su_downloads.html.
  4. Яремчук С. Лейся песня или сервер потокового аудио своими руками. – Журнал «Системный администратор», №11, ноябрь 2004 г. – 28-31 с.
  5. http://xinehq.de/index.php/features.
  6. http://mplayerplug-in.sourceforge.net.
  7. Гребенников Р. Танцуем Самбу. – Журнал «Системный администратор», №11, ноябрь 2004 г. – 32-38 c.
  8. http://www.iulabs.com/download/848wdm_iu.zip.

Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru