доклад "Использование технологий Windows Media" для Izhevsk .NET User Group

Обсуждаем разработку программного обеспечения

Сообщение vva » 28 янв 2009, 13:38

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

Пункт публикации по требованию выполняет потоковую передачу содержимого только в том случае, если клиент подключился для получения потока. Для каждого нового клиента сервер Windows Media поддерживает отдельное подключение. Передача содержимого от пункта публикации передаётся всегда как одноадресный поток (unicast).
Пункт публикации по требованию можно также использовать для передачи широковещательного потока от WMEncoder а, удаленного сервера или другого пункта публикации. Любой из перечисленных источников можно использовать в качестве отдельного источника содержимого или добавить в качестве части списка воспроизведения (playlist а). Если источником содержимого является не WMS, пользовать сможет полноценно использовать элементы управления воспроизведением в проигрывателе, только выкачав весь фрагмент данных (чтобы приостанавливать, перематывать вперед и назад, а также пропускать элементы списка или останавливать воспроизведение).

Для создания пункта публикации «по требованию» в простейшем сценарии для WMS нужно просто указать файл или директорию а также URL по которым они должны быть доступны.
При реализации сценария с пунктами публикации по требованию нужно помнить:
• Возможность управления содержимым из списка воспроизведения на сервере доступна только в проигрывателе Windows Media 9 Series или в любом другом проигрывателе использующем элемент управления ActiveX проигрывателя Windows Media 9 Series. Пользователи, использующее проигрыватели предыдущих версий при подключении будут получать содержимое с начала списка воспроизведения на сервере.
• Если пункт публикации предоставляет доступ к файлам на компьютере с ОС Windows 2000 Server, то могут возникнуть проблемы при потоковой передаче содержимого из-за различий механизмов авторизации учетных записей и привилегий в системах Windows 2000 Server и Windows Server 2003. Как устранить подобные проблемы описано в документации к серверу Windows Media.
• Так как передача содержимого от пункта публикации по требованию происходит как одноадресный поток, то необходимо определить какое количество пользователей будет использовать Ваш сервер Windows Media. Для каждого пункта публикации и сервера в целом можно установить ограничения на количество подключений и полосу пропускания.
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение vva » 28 янв 2009, 13:38

Рассмотрим сценарий, когда источником содержимого пункта публикации является поток от кодировщика.
Существует два варианта организации взаимодействия между кодировщиком и сервером Windows Media. (1) Передача потока кодировщиком на сервер и (2) прием запроса кодировщиком.

В первом случае кодировщик передает поток на специальную Push*-точку публикации. Можно настроить автоудаление этого пункта публикации после завершения процесса кодирования.

Во-втором случае создается пункт публикации по требованию или широковещательный пункт публикации, источником содержимого которого является поток от кодировщика.

Что бы использовать в качестве источника содержимого поток кодировщика нужно указать в списке воспроизведения сервера или в источнике пункта публикации строку подключения до кодировщика. Строка подключения выглядит как обычные HTTP-url с указанием имени компьютера или IP-адреса компьютера, с которого осуществляется кодирование потока кодировщиком, и порт.

При разработке системы управления потоковым видео наша команда столкнулась с интересной особенностью взаимодействия сервера Windows Media и WMEncoder. Запрос содержимого от кодировщика происходит по протоколу HTTP. Поэтому, даже если пункт публикации является широковещательным сервер все равно при каждом новом подключении клиента создаст отдельное подключение до кодировщика. Чтобы избежать нагрузки на сеть следует создать отдельный широковещательный пункт публикации, назовем его, например, Encoder.Proxy, а доставку содержимого до клиента осуществлять через другой широковещательный пункт публикации, источником содержимого которого является пункт публикации Encoder.Proxy. В этом случае будет создано одно подключение до кодировщика и при большом количестве пользователей нагрузка на сеть будет значительно снижена.
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение vva » 28 янв 2009, 13:39

Язык 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 «по требованию».


Вложения
traffic.PNG
traffic.PNG (28.87 KiB) Просмотров: 7598
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение vva » 28 янв 2009, 13:43

"Обратная" модель взаимодействия с сервером

Как наверно уже догадались слушатели, система описанная выше получается довольно большая.
Понятно что администрирование и настройка всего этого хозяйства в гетерогенной среде ВУЗ а является непростой задачей. Для облегчения работы администраторов был принят ряд архитектурных решений в ущерб простоте программирования:

Все самописные сервисы управления (кроме сервиса управления WMS для записи) сгруппированы на одной машине с IIS. Другими словами агенты управления WMEncoder ов и агенты управления автономными плазменными панелями не предоставляют сами удалённого интерфейса управления. Вместо этого они сами регулярно по таймеру обращаются к центральному серверу управления за командами. На таком решении настоял заказчик и мы по опыту действительно согласны с тем, что для администрирования так получается проще (хотя это усложняет программирование). Администратор видит сразу в WEB интерфейсе очнувшиеся в системе агенты, и наоборот, когда агенты длительное время не обращаются на центральный сервер за командой, это служит сигналом того что с конкретной машиной проблемы. От программистов такая схема помимо простого выделения сигнатур методов в классы и обращения интерфейса потребовала тщательного прописывания планировщиков агентов (они вынуждены набирать команды на будущее и планировать свои действия заранее), грамотного написания сервиса управления, который в большинстве случаев (для пустых фоновых запросов) должен отвечать максимально быстро, не обращаясь никуда на диск и используя только данные расположенные в памяти, а также опитимизации трафика «управляющих» команд.

Очевидно что система будет развиваться и встанет задача обновления программных компонентов на целом ряде компьютеров, а в идеале и работа компонентов разных версий одновременно. Поэтому заказчик сразу попросил интерфейс, позволяющий управлять включением-выключением агентов с WEB-интерфейса, а в процессе загрузки скачивания при необходимости новых версий с файлового сервера.
Вложения
reverse_scheme.PNG
reverse_scheme.PNG (38.32 KiB) Просмотров: 7596
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение vva » 28 янв 2009, 13:44

Внешний интерфейс системы и как и чем может помочь IIS

По понятным причинам пользовательский интерфейс системы был создан на основе ВЕБ-сервера IIS (скриншот). Сразу возникают вопросы, что предлагает этот сервер для работы с медиаданными, для каких вещей целесообразно использование IIS а в каких случаях всё таки учще WMS и как они сргласованы.

Действительно целый ряд простых функций для доставки media данных имеет IIS и эти возможности широко представлены сети – короткие видеоролики на форумах и в blog ах теперь не размещает только ленивый. Однако как чётко было рассказано выше о WMS, этот сервис имеет целый ряд функций, отличный от простой загрузки коротких роликов и связанный с быстрым переходом на конкретную позицию фрагмента, распределением прав, подстройкой качество под толщину канала и другое. Часть этих функций действительно постепенно мигрирует в IIS, но вместе с тем видно что ряд богатых возможностей там просто излишни.
Как определённый шаг в направлении обогащения IIS функционалом для работы с media данными можно назвать IIS 7.0 Media Pack. А в для сравнения возможностей IIS с media pack ом и WMS сослаться на статью Windows Media Server or Web Server? от David Nelson (http://learn.iis.net/page.aspx/454/wind ... eb-server/ ), в качестве выжимки из которой можно рассмотреть следующую сравнительную таблицу:

Вложения
evm_media_small.PNG
evm_media_small.PNG (100.52 KiB) Просмотров: 7597
evm_program_small.PNG
evm_program_small.PNG (68.01 KiB) Просмотров: 7598
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Сообщение vva » 28 янв 2009, 13:45

Заключение

Мы описали цельную систему, построенную на технологиях Microsoft. Понятно что в данной предметной области помимо Microsoft представлены и другие решения. В частности например часть ответственная за хранение очень большого архива видеозаписей а также часть отвесттвенная за всяческие монтажные работы и сложную видеообработку строится нашим заказчикам на других технологиях. Однако можно констатировать, что в данном сегменте, для работы с медиаконтентом конечного, массового пользователя технологий Microsoft вполне хватает, по целому ряду параметров эти технологии не имеют себе равных, а их хорошая взаимная увязанность друг с другом вообще делает часто их безальтернативными.
Из проблем так и не решённых можно назвать синхронизацию media потоков на разных устройствах воспроизведения. В частности в нашей системе рассогласование работы двух рядом стоящих плазменных панелей может достигать несколько секунд. Microsoft, по некоторым источникам, намекает что обладает технологиями решения данных проблем, но что то пока в бытовых пакетах их не видно.
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1

cron