Михаил Платов

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

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

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

n  системы с одноадресным вещанием (unicast);

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

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

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

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

n  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.