Будущее медиа-технологий уже сегодня: введение (часть 1)
Тема доставки медиа-контента является достаточно актуальной на сегодняшний день. Не так давно были выпущены расширения IIS Media Services, которые позволяют по-другому посмотреть на способы доставки медиа-контента. Этой заметкой я бы хотел открыть серию статей, посвященных этой теме.
Развитие телекоммуникацонной среды позволило всерьез говорить о воспроизведении аудио - и видео-контента через Интернет. При этом необязательно ограничиваться низкокачественным потоком. С другой стороны существует большое количество сценариев, где использование медиа-контента является очень благоприятным. Однако, несмотря на то, что на сегодняшний день в различных частях планеты доступен надежный, высокоскоростной и дешевый доступ в Интернет, разработчики подобных приложений до сих пор испытывают различные трудности. Они связаны с различными аспектами функционирования медиа-приложений. Одной из основных проблем является интерактивность приложения и время его реакции на действия пользователя. Кроме того, разработчики подобных приложений очень часто задаются вопросом оптимизации инфраструктуры для размещения таких приложений и повышения её эффективности. Особенно это справедливо для высоконагруженных приложений. Эти и другие проблемы являются достаточно серьезным ограничением для дальнейшего развития медиа-приложений в Интернет.
Разработчики Microsoft попытались решить эти и другие проблемы в своем новом продукте IIS Media Services. По сути, он является набором расширений для Internet Information Services (IIS), сервера приложений, который входит в состав Windows Server 2008. Поскольку IIS и IIS Media Services являются бесплатными продуктами, они открывают широкие возможности по доставке медиа-контента конечному пользователю. На протяжении этой серии статей мы рассмотрим основные вопросы, связанные с разработкой медиа-приложений, использующих IIS Media Services.
Прежде чем рассматривать особенности IIS Media Services, давайте разберемся с существующими подходами к доставке медиа-контента. Это необходимо для более четкого понимания текущего состояния технологий. В основном мы будем рассматривать видео-контент, поскольку основные проблемы связаны именно с доставкой именно этого типа содержимого.
На сегодняшний день существует два основных подхода к доставке медиа-контента – это традиционное вещание и прогрессивная загрузка. Давайте более подробно разберемся в каждом из этих подходов.
Традиционное вещание (traditional streaming) основывается на непрерывной передаче потока информации от сервера клиенту. После подключения клиента к источнику, сервер постоянно транслирует поток для этого клиента. Если клиенту необходимо вмешаться в процесс воспроизведения, то он отправляет команды серверу, в которых указывает, какое именно действие необходимо совершить. Например, клиент может отправлять на сервер команды перемотки воспроизведения на несколько секунд, или команды остановки и возобновления воспроизведения. Сервер получает эти команды и корректирует поток, который передается клиенту. Таким образом, при использовании этого подхода от сервера клиенту постоянно передается поток информации, а от клиента к серверу приходят управляющие команды, которые управляют воспроизведением.
У этого подхода, безусловно, есть несколько сильных сторон. Во-первых, при использовании традиционного стриминга канал передачи данных используется достаточно эффективно. Это объясняется тем, что в данный момент времени загружается только та часть медиа-контента, которая непосредственно должна быть проиграна. Медиа-контент, который будет проигрываться позже, не загружается. Таким образом, на клиент не будет загружена часть информации, которая не нужна в данный момент. Другой сильной стороной этого подхода является возможность построения отзывчивого пользовательского интерфейса. Поскольку канал передачи данных используется только для передачи контента, воспроизводимого в данный момент, то операции перемотки или возобновления воспроизведения могут быть обработаны за короткий промежуток времени. Кроме того, использование такого подхода позволяет отслеживать активность пользователя на серверной стороне. Поскольку клиент пересылает команды перемотки, остановки и возобновления воспроизведения, можно собирать эту информацию на сервере для последующего анализа. Эта информация может быть очень полезна для владельцев медиа-контента.
Однако, у традиционного вещания существуют и недостатки. Основным недостатком этого подхода является сложность построения инфраструктуры. Поскольку каждый клиент удерживает соединение с сервером на протяжении всего сеанса просмотра видео, это накладывает определенные ограничения на организацию серверной инфраструктуры. Поскольку соединение клиента и сервера является ограниченным ресурсом, необходимо отдельно задумываться над этим вопросом. Этот факт не позволяет организовать всю инфраструктуру на основе классического веб-сервера. Более того, в подобном сценарии отсутствует возможность использовать существующие механизмы кэширования.
Прогрессивная загрузка (progressive download) основывается на другой идеологии. Основной идеей, которая лежит в основе этого подхода является использование существующей инфраструктуры веб-сервера. Процесс доставки медиа-контента в случае прогрессивной загрузки аналогичен обычной загрузке файла с веб-сервера. Однако, клиентский проигрыватель может начать воспроизведение до того момента, как будет загружен весь файл. Фактически проигрыватель загружает часть файла и начинает воспроизведение на клиенте. В этот момент параллельно воспроизведению происходит загрузка оставшейся части файла с сервера.
Использование прогрессивной загрузки обладает рядом преимуществ перед традиционным вещанием. Основное преимущество представленного подхода заключается в том, что становится возможным использовать существующую инфраструктуру размещения контента. Т. е. медиа-контент можно разместить в Интернет, используя обычный веб-сервер по протоколу HTTP. Кроме того, становится возможным масштабировать подобное решение, используя уже существующие механизмы (например, кэширование HTTP).
Тем не менее, прогрессивная загрузка также обладает рядом недостатков. Поскольку этот подход эквивалентен обычной загрузке файла, то появляется такое явление как буферизация. Если скорость соединения клиента с сервером ниже, чем размер атомарной порции медиа-контента, то в какой-то момент времени клиент не сможет загрузить нужное количество информации. В этот момент воспроизведение приостанавливается, и клиент загружает нужное количество информации. Этот отрицательный эффект не будет заметен, если у клиента высокоскоростное соединение с Интернет. Однако, если соединение недостаточно быстрое, то буферизация будет происходить периодически. По этой причине в этом случае пользовательский интерфейс будет не очень дружественным и пользователь может испытывать некоторый дискомфорт. Кроме того, при подобном подходе практически невозможно получить аналитическую информацию о просмотре медиа-контента. Поскольку проигрыватель загружает содержимое как обычный файл, сервер не в состоянии отследить, что именно из этого файла просмотрел пользователь.
Еще более серьезной проблемой, с которой сталкиваются поставщики медиа-контента на основе прогрессивной загрузки, является излишнее потребление трафика. Это справедливо для пользователей с высокоскоростным каналом доступа в Интернет. В тот момент, когда пользователь открывает страницу с медиа-контентом и начинает просматривать видео, за счет высокой скорости соединения видео загружается очень быстро. Однако, после нескольких секунд пользователь может решить, что просматриваемое видео для него не представляет интереса и закрыть страницу. В данной ситуации пользователь загрузил весь видео-файл, однако посмотрел только первые несколько секунд. Поэтому остальная часть трафика была потрачена впустую.
Подводя итог можно выделить основные преимущества и недостатки обоих подходов:
- Традиционное вещание
- Преимущества
- Отзывчивый пользовательский интерфейс Эффективное использование канала передачи данных Отслеживание действий пользователя
- Отсутствие возможности масштабирования классическими средствами (например, кэширование) Необходимость организации специфичной инфраструктуры
- Преимущества
- Работа в рамках обычного веб-сервера Простота построения инфраструктуры Возможность масштабирования, используя средства HTTP
- Ограниченный пользовательский интерфейс Невозможность отслеживания действий пользователя Неэффективное использование канала передачи данных
В целом на сегодняшний день несмотря на все свои недостатки большей популярностью пользуется подход с использованием прогрессивной загрузки. В этом случае наиболее низки расходы на развертывание и поддержание серверной инфраструктуры.
Будущее медиа-технологий уже сегодня: что такое IIS Media Services (часть 2)
IIS Media Services – это расширения для веб-сервера IIS, которые позволяют более эффективно организовать доставку медиа-контента конечному пользователю. Эти расширения включают в себя инструменты для организации более эффективной доставки медиа-контента, используя прогрессивную загрузку, а также предлагают альтернативный подход к организации доставки медиа-контента. Этот подход называется адаптивным вещанием и позволяет клиенту «подстраиваться» под условия, в которых в данный момент находится пользователь. Для работы с IIS Media Services необходимо загрузить и установить соответствующие бесплатные расширения, которые встроятся в инфраструктуру Internet Information Services. Удобней всего это можно сделать, используя Web Platform Installer, который содержит все необходимые компоненты.
Поскольку IIS Media Services затрагивает два подхода к стримингу видео, то впоследствии мы посмотрим на оба эти направления. С точки зрения прогрессивной загрузки IIS Media Services предлагает ряд улучшений, которые могут использоваться в ваших приложениях. Этими улучшениями являются механизмы Bitrate Throttling и Web playlists.
Bitrate Throttling
Механизм Bitrate Throttling пытается решить проблему неэффективного использования трафика при просмотре видео. Как мы поняли ранее, в случае наличия у клиента высокоскоростного соединения с Интернет, видео-файл может слишком быстро загружаться. В этом случае и клиент, и владелец сервера фактически платит за трафик, который оказывается ненужным. Однако с этим эффектом достаточно тяжело бороться, поскольку он вытекает из самой идеологии прогрессивной загрузки.
Расширения IIS Media Services предлагают своё решение этой проблемы. Механизм Bitrate Throttling позволяет определить ограничения по скорости при загрузке содержимого клиентом. При этом первые несколько секунд загружаются на клиент без ограничения скорости. Таким образом, клиент имеет возможность быстро загрузить первые несколько секунд и начать воспроизведение. После этого загрузка ограничивается какой-то фиксированной скоростью. Если пользователю после просмотра начального участка видео этот контент становится неинтересным, то сервер не передает клиенту лишних данных. Ниже показан график изменения скорости при загрузке файла с включенным режимом Bitrate Throttling.
При настройке Bitrate Throttling можно по-разному подойти к определению параметров. IIS Media Services позволяет задать время загрузки на полной скорости исходя из размера файла (в килобайтах) или исходя из времени медиа-файла (в секундах). Это означает, что в настройках можно указать время загрузки на полной скорости, например, первые 20 секунд указанного видео-файла. В другом случае можно определить, что необходимо загружать на максимальной скорости, например, первые 200 килобайт.
Задавать ограничения скорости можно в абсолютных и относительных величинах. Можно задать явное ограничение скорости в абсолютных величинах, например, 300 кбит/сек. В другом случае можно определить ограничение скорости основываясь на качестве медиа-файла (bit rate). Например, в этом случае можно указать серверу, что нужно ограничить скорость значением 100% соответствующем качеству медиа-файла. В этом случае, если качество видео 256 кбит/сек, то передача файла будет ограничена именно этим значением. Если для этого файла установить значение 200%, то скорость будет ограничена значением 512 кбит/сек. Таким образом, значение предельной скорости передачи будет определяться исходя из качества видео-файла. Это ограничение начнет действовать после того, как будет завершена загрузка начального фрагмента файла, при котором ограничение не действует.
Настройка механизма Bitrate Throttling производится для каждого типа медиа-контента отдельно. Это означает, что можно настроить различные параметры для каждого типа файлов отдельно.
Таким образом, механизм Bitrate Throttling позволяет более эффективно использовать канал передачи данных тогда, когда пользователь не просматривает видео-файл целиком. В этом случае данный механизм эффективно решает указанную проблему.
Web playlists
Одним из способов монетизации для поставщиков медиа-контента является продажа рекламы. При этом реклама может быть размещена как непосредственно на сайте с медиа-контентом, так и вставками в начало или конец просматриваемого видео. Последний способ достаточно проблематичен для владельцев подобных сайтов, поскольку требует обработки видео-потока на стороне сервера (для вставки рекламных роликов). С другой стороны, подобный вид рекламы является достаточно востребованным на рынке. Поэтому данная задача требует большего внимания.
Расширения IIS Media Services позволяют элегантно решить эту проблему, используя механизм под названием Web playlists. Этот инструмент позволяет формировать списки воспроизведения на стороне сервера. При этом клиенту будет передаваться единственный URL, используя который он просмотрит все медиа-файлы, включенные в этот список воспроизведения. Для активации этой возможности в IIS необходимо выбрать соответствующий раздел. При настройке списков воспроизведения можно указать нужные файлы, которые будут воспроизводится пользователю, их последовательность и другие параметры. Для списка воспроизведения задается имя файла (для получения конечного URL), название и описание, а также список медиа-файлов.
При добавлении медиа-файлов в список воспроизведения можно также определить ряд настроек. В первую очередь нужно указать адрес медиа-контента. В качестве адреса можно использовать относительный URI, абсолютный URI или физический путь к файлу в файловой системе. Для каждого файла в списке воспроизведения можно задать название. Кроме того, существуют опции, которые позволяют запретить перемотку, переход к предыдущему и следующему файлу. Эти опции актуальны для рекламы, поскольку зачастую пользователи склонны пропустить просмотр рекламы. Используя эти опции, поставщик медиа-контента может гарантировать рекламодателю просмотр рекламных роликов.
После настройки списка воспроизведения будет создан. isx файл, который содержит описание списка воспроизведения. Это описание создается в рамках формата XML и содержит информацию обо всех элементах списка воспроизведения.
Поскольку одной из задач механизма Web Playlists является показ рекламы, то возможно некоторые пользователи захотят обойти данный механизм и перейти к воспроизведению интересующего видео без просмотра рекламы. Поэтому для таких случаев предусмотрен механизм, который исключает подобные сценарии. Как это работает? При обращении к этому списку воспроизведения с клиента, ему будет передан файл XML несколько иного формата. В этом файле будут указаны ссылки на соответствующие медиа-файлы, которые необходимо воспроизвести.
При получении подобного описания клиент начинает поочередное воспроизведение указанных медиа-ресурсов. Если при этом пользователь попытается самостоятельно обратиться к каждому файлу, то сервер в ответ сгенерирует HTTP-ошибку 400 и запретит обращаться к данному ресурсу. Кроме того, каждый адрес до медиа-ресурса содержит идентификатор сессии, который будет различным для каждого клиента.
Полученный список воспроизведения можно использовать в качестве источника для проигрывателя на базе Silverlight или как источник для Windows Media Player. Таким образом, мы получаем инструмент, который позволяет эффективно организовывать списки воспроизведения с необходимой для приложения логикой.
