Язык SMIL для WMS
WMS умеет передавать по сети не просто содержимое одного файла, а объединять одним потоком данные из многих источников, определённые в специальном списке воспроизведения (playlist е). При этом WMS берёт на себя все проблемы предварительной буфферизации разных элементов списка воспроизведения, их доступности и унификации формата, умеет выравнивать их по размеру или задавать фиксированное время начала разных элементов playlist а, синхронизировать воспроизведение с различными событиями.
Другими словами playlist для WMS это не просто линейная последовательность фрагментов, а структура сложного вида описанная на XML-based языке SMIL 2.0 (Synchronized Multimedia Integration Language -
http://www.w3.org/AudioVideo/ ). Для начала трансляции playlist а WMS должен сначала обработать этот файл, подготовить где можно буфферы и т.п. При этом точность позиционирования отдельных элементов playlist а в документации Windows Media Services 9.0 указывается в 5 секунд (для сравнения точность в предудыщих версиях – 20 секунд).
Основными конструктивными элементами ы языке SMIL являются:
1. media – элемент указывающий метонахождение источника мультимедиа (любой источник поддерживаемый мервером Windows Media: файл,)
2. seq – линейная последовательность элементов (media или более сложных)
3. switch – алтернативные источники, которые используются в случае недоступности одного из них (ну или нескольких по порядку). Т.е. WMS последовательно пытается подключаться к разным альтернативам
4. excl – элемент контейнер, в котором за один раз может быть воспроизведен только один медиа элемент, причем порядок воспроизведения может быть определен временем старта элемента или вызовом события.
5. priorityClass – элемент позволяющий задавать «слоя» списка воспроизведения. То есть определить когда один медиа элемент должен прервать другой медиалемент и нужно ли сохранить состояние прерванного элемента.
Язык SMIL понимает также WMPlayer, кроме того, WMS в качестве элемента своего playlist а может также принимать поток с другого WMS. Другими словами playlist ы могут оказаться вложенными друг в друга. Для синхронизации между ними используется система событий.
Multicast, broadcast, unicast
При использовании tcp/ip intranet сети для передачи тяжёлого медиаконтента естественным образом встаёт вопрос об оптимизации трафика. В наиболее распространённых сценариях передачи ip пакетов, пакету явно указывается ip-адрес назначения. Такой сценарий называется unicast. В случае если передавать по сети один и тот же multimedia поток (например спутниковый канал) unicast ом то общий трафик получается прямопропорционален количеству потребителей такого потока.
Есть другой вариант, когда отсылаются так называемые широковещательные broadcast пакеты без указания конкретного ip-адреса. В таком случае один и тот же спутниковый канал можно отдавать в сеть одним потоком для многих потребителей. Понятно что полноценно такую схему можно реализовать только для udp-протокола, без подтверждения приёма пакетов от адресатов. Т.е. адресаты (потребители) должны уметь работать пропуская часть пакетов. Понятно что WMS и WMPlayer умеют работать с такими потоками, пропуская отдельные ip пакеты.
Помимо описанных проблем, в большой сети можно также ограничивать широковещательные потоки, идущие в отдельные локальные сети (другими словами фильтровать широковещательные пакеты на роутерах). Такой метод называется multicast вещанием, и при нём пакеты отправляются на ip адреса определённой подсетки из выделенного для этой цели диапазона. Роутер принимая решения передавать ли такой пакет в свою локальную сеть, смотрит есть в этой сети точки в нужной подсетке.
http://en.wikipedia.org/wiki/Unicast
http://en.wikipedia.org/wiki/Multicast
http://en.wikipedia.org/wiki/Broadcasting_(computing)
IGMP-snooping
Для доставки медиаконтента на автономные плазменные панели заказчика идеальным решением было бы использование unicast доставки контента. При этом плееры плазменных панелей, отображающие один и тот же контент должны принадлежать одной unicast подсетке. Заказчик же хочет управлять всей инфраструктурой вещания и в том числе тем, что отображается на каждой конкретной панели. Такое пожелание накладывает дополнительные требования к инфраструктуре маршрутизации в сети, потому что при решении «в лоб» нужно уметь быстро переназначать подсетки к которым принадлежат разные плееры.
Для прозрачного и дешёвого решения такой задачи придуман специальный протокол управления группами (Internet Group Management Protocol (IGMP) -
http://en.wikipedia.org/wiki/IGMP ) который поддерживают многие сетевые устройства маршрутизации, например у нас в проекте используются switch и фирмы Cisco, и в частности они поддерживают IGMP snooping (
http://en.wikipedia.org/wiki/IGMP_snooping ).
Грубо говоря, свитч просто слушает кто из конечных клиентов в его подсетке обращается на сервер за конкретным multicast потоком и передаёт необходимые multicast сообщения заинтересованным клиентам.
Вся инфрастуктура доставки и воспроизведения Windows Media (WMS и WMPlayer) хорошо поддерживают multicast потоки с использованием данного протокола.
WMPlayer
Заказчик изъявил желание иметь на автономных плазменных плеерах сложно устроенные экраны, составленные из нескольких примитивных экранов (экран в экране, сетка экранов, бегущая строка и т.п.). Кроме того захотел иметь html-экраны с бегущей строкой, статическим текстом и т.п.
Тут перед нами вставал выбор как формировать изображение на таких экранах
1. можно было бы попробовать формировать всё сложное изображение прямо на сервере и подавать на плеер единым потоком
2. можно формировать несколько окон на стороне плеера и подавать на каждое из них свой поток
Кроме того, при отображении текстового содержимого
1. можно было попробовать использовать возможности самого WMPlayer а для отображения текстовой информации
2. можно отображать текстовую информацию используя стандартный компонент для отображени HTML
В результате нами было принято решение писать специальный агент воспроизведения (Display agent), который отображает отдельные потоки в своих окнах, а для текста использует стандартный компонент. Просто хороших готовых средств для формирования из разных потоков одного по принципу «экран в экране» мы не нашли, а писать что то своё посчитали слишком дорого. Это конечно сказывается на объёме трафика. Использование стандартного HTML компонента было продиктовано бедными возможностями стандартного WMPlayer а для отображения текста и неуверенностью что их хватит.
Работа со сменой раскладок
Одна из непростых задач решаемых WMPlayer ом является смена раскладки монитора. Display Agent получает задание на смену раскладки заранее, за некоторое время до момента её реальной смены. В задании указана новая раскладка экрана – перечисление элементарых экранов с координатами, цветом фона и URL ом того контента который должен в них отображаться.
Для корректного и гладкого выполнения этой операции агент должен готовить окна с видеоконтентом заранее, заранее проводить для них предьуфферизацию. Ещё ранее должны быть созданы новые точки публикации на стороне WMS. Всё это накладывает высокие требования к синхронизации работы этих механизмов.
Помимо проблем со сменой раскладки возможна ситуация, когда «автономный» плеер становится действительно автономным и у него появляются проблемы со связью с сервером вещания WMS. Эта задача также решается использованием механизма SMIL и конкретно элемента switch в нём. WMPlayer хорошо поддерживает эту технологию.
Для объединения отдельных окошек в один сложный экран использовалась технология WPF, в которой уже гладко объединялись и WMPlayer компоненты и компоненты для отображения HTML. Мы не можем однозначно сказать что это было правильным решением. Всё таки преиумуществами WPF в такой задаче воспользоваться не получается, а WPF обёртки как выяснилось реализуют не весь интерфейс WMPlayer а, по крайней мере часть функций наши программисты найти не смогли (связанные с получением статуса отображения, количества принятых кадров и т.п.)
Использование WMS для записи
Одной из задач поставленных заказчиком была одновременное «безстыковое» использование одного источника живого потока. В принципе такими возможностями обладает WMEncoder который стоит сразу на приёме живого потока в системе. Но! Параметры запущенного сеанса WMEncoder нельзя менять «на лету». Т.е. для использования WMEncoder а придётся либо каждый раз при новом задании на запись/трансляцию перезапускать WMEncoder с новыми параметрами, что понятно не выход, либо держать по одному экземпляру WMEncoder а для каждого задания, и получается несколько – для каждого источника живого потока. Понятно что это тоже не очень хорошо, и по соображению производительности и исходя из того соображения что не все источники живого потока могут отдавать контент одновременно в несколько WMEncoder ов
С другой стороны, функцией записывать трафик в файл обладает точка публикации WMS. Таким образом родилось решения использовать отдельный сервер WMS только для записи. WMS просто создаёт отдельные точки публикации для записи контента, получаемого по сети.
Общая схема системы
Итак, общая система поставляемая заказчику сложилась из:
1. набора серверов с установленными на них агентами управления WMEncoder ами и зарегестрированными на них источниках «живого» потока – tv tuner ов, видеокамер, карт приёма сигнала со спутника и т.п. (несколько десятков)
2. серверов для транскодирования файлов из файлов же (из файлов в форматах, принесённых пользователями, просто пережатие и т.п.) на данный момент это одна машина.
3. Сервера с RAID массивом для хранения внутренней медиатеки. На нём же установлен WMS “для записи”
4. Сервера вещания WMS
5. Управляющего сервера с установленным и настроенным на нём IIS и web сервером управления
6. Более сотни автономных плазменных панелей с установленнымы Display агентами ена них
Для серверов выделена свои сеть со своим выделенным роутером, предполагается что в этой сети трафик будет довольно большим.
Постоянно поднятые encoder ы и точки публикации
Как уже было рписано ранее для работы одновременно и записи и трансляции живого потока, экземпляр WMEncoder а поднимается один раз. Логично задать вопрос, а нужно ли вообще отслеживать поднятие начало работы WMEncoder а.
В нашей системе мы приняли решение держать экземпляры WMEncoder постоянно для каждого живого потока-источника. На стороне WMS вещания точно также для каждого живого потока-источника создаётся «прокси» точка публикации. Теперь, когда этот живой поток нужно транслировать наружу, WMS вещания в качестве источника использует свою же «proxy» точку. Когда создаётся задача для записи живого потока источника, WMS записи использует в качестве источника ту же «прокси» точку публикации с WMS. Реально «прокси» точка вещания начинает качать данные с WMEncoder а только тогда, когда эти данные понадобились приёмникам (широковещательной точке публикации WMS или точке ). Таким образом, система имеет постоянно поднятые WMEncoder ы, настроенные на вещание в сеть и точки публикации WMS тоже настроенные на вещание, но данные для них реально передаются не всё время а только тогда, когда это нужно. Точно также происходит и с точками публикации WMS «по требованию».