79991

Интеграция DivX Plus Streaming с платформой Windows Phone 8

Дипломная

Информатика, кибернетика и программирование

На основании информации которую предоставляют контакты из фильтров строится граф фильтров filter grph или медиаконвейер multimedi pipeline который производит все необходимые действия от открытия медиаконтейнера до визуализации его содержимого. Управлением графами фильтров занимается менеджер графа фильтров filter grph mnger. В других мультимедийных фреймворках с которыми знаком автор работы менеджер графа фильтров часто именуется сессией session или медиасессией medi session. Любой граф фильтров обладает следующими свойствами:...

Русский

2015-02-15

1.08 MB

0 чел.

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ
ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

Факультет информатики

Кафедра программной инженерии


УДК 681-3

                                                                                       ДОПУСТИТЬ К ЗАЩИТЕ В ГАК

                                                                                       Зав.кафедрой, проф., д. ф.-м.н.

                                                                                       ____________________ О.А. Змеев

                                                                                       «_____» _________________ 2013



БАКАЛАВРСКАЯ РАБОТА

Интеграция  DivX Plus Streaming с платформой Windows Phone 8

по основной образовательной программе подготовки бакалавров
010400 Информационные технологии


Неживой Федор Андреевич


Научный руководитель                                                                                  Иванов А.М.

Ст.менеджер компании Rovi

 


Исполнитель                                                                                                    Неживой Ф.А.

студ. гр. 1493

Электронная версия бакалаврской работы Администратор электронной
помещена в электронную библиотеку. библиотеки факультета
_____________ Якунина Е.Н.
подпись

Томск – 2013

Реферат

Дипломная работа 34 с.,  15 рис., 1 табл., 4 источника

ADAPTIVE STREAMING, АДАПТИВНОЕ ПОТОКОВОЕ ВЕЩАНИЕ, WINDOWS PHONE 8, DIVX PLUS STREAMING, WINDOWS RUNTIME, .NET FRAMEWORK, MICROSOFT MEDIA FOUNDATION

Объект разработки – прототип приложения, реализующий интеграцию DivX Plus Streaming с платформой Windows Phone 8.

Цель работы – разработать прототип приложения, поддерживающий адаптивное вещание DivX Plus Streaming и работающий на платформе Windows Phone 8, который впоследствии будет использован в качестве базы для написания полноценного приложения компании Rovi под указанную платформу.

Метод разработки – экспериментальный на ЭВМ.

Результаты работы: разработан прототип приложения, реализующий интеграцию DivX Plus Streaming с платформой Windows Phone 8.

Содержание

 

Введение…………………………………………………………………………………

4

1

Анализ предметной области……………………………………………………….

6

  1.  Адаптивное потоковое вещание……………………………………………….

6

1.2 Медиаконтейнеры……………………………………………………………....

8

1.3 Медиаконвейер………………………………………………………………….

10

1.4 Технические требования и задачи……………………………………………..

13

2

Мультимедийные фреймворки в Windows Phone 8………………………………

14

  1.  Введение………………………………………………………………………...

14

2.2 Microsoft Media Foundation…………………………………………………….

15

2.2.1 Архитектура Microsoft Media Foundation…………………………………

15

2.2.2 Архитектура медиаконвейера в Microsoft Media Foundation……………

17

  2.2.3 Определение необходимых интерфейсов………………………………...

19

  2.2.4 Список поддерживаемых форматов………………………………………

21

2.3 .NET Framework………………………………………………………………...

22

  2.3.1 Необходимые классы………………………………………………………

22

  2.3.2 Список поддерживаемых форматов………………………………………

23

2.4 Вывод……………………………………………………………………………

24

3

Реализация…………………………………………………………………………..

25

3.1. Windows Phone Runtime Component и C++/CX………………………………

25

   3.2 Реализация фильтра-источника……………………………………………..

27

      3.2.1 Процесс обработки медиаконтента…………………………………….

27

      3.2.2 Управления состояниями и очередями сэмплов………………………

30

3.3 Скриншоты приложения……………………………………………………….

32

Заключение………………………………………………………………………………

33

Список использованных источников и литературы…………………………………..

34

Введение

В настоящее время существует множество различных способов доставки медиаконтента до конечного потребителя: телевидение, радио, кинотеатры, Интернет и т.д. В случае с бесплатным контентом пользователь всегда имеет возможность записать понравившийся материал для последующего неограниченного просмотра. Однако одна из основных особенностей предоставления легального медиаконтента конечному потребителю связана с желанием пользователя повторно просмотривать контент и его готовностью переплачивать за эту возможность. С платным контентом дело обстоит сложнее. Например, если речь идет о кинотеатре, мы не можем легально записать фильм  в кинозале. Что же делать пользователю, если у него возникает потребность вновь посмотреть понравившийся фильм? Одним из выходов может служить покупка диска для просмотра в любое удобное время. Однако возникает новая проблема: пользователь оказывается привязан к дискам и месту, где расположено устройство способное проигрывать диски. Также довольно трудно заранее предугадать, какой из множества фильмов нашей коллекции мы захотим посмотреть, например, в машине по пути в соседний город.

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

В компании Rovi разработана система доставки медиаконтента пользователю. В данную систему входят серверы для хранения медиаконтента, серверы авторизации и, в том числе, клиентские приложения под различные мобильные платформы для просмотра данного медиаконтента. На упрощенной диаграмме развертывания на рис.1 обведены мобильные операционные системы, под которые уже существуют соответствующие приложения. С выходом новой операционной системы Windows Phone 8 появилась необходимость в создании приложения под данную платформу.

Целью данной выпускной квалификационной работы является демонстрация интеграции решения для адаптивного вещания DivX Plus Streaming на примере создания приложения для платформы Windows Phone 8.

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

рис. 1 Диаграмма развертывания

  1.  Анализ предметной области

  1.  Адаптивное потоковое вещание

Как будет рассмотрено ниже, любой видео файл может состоять из множества различных потоков данных: видео, аудио, субтитры.

Видеопотоки требуют гораздо большей пропускной способности сети (100 kbps – 200 Mbps), чем аудиопотоки (8 kbps – 128 kbps). Соответственно при просмотре видео высокого качества во время изменений пропускной способности сети мы рискуем оказаться в ситуации, когда придется длительное время ожидать загрузки очередной порции данных. С точки зрения конечного пользователя этот факт является чрезвычайно неприятным.

Для решения данной проблемы была сформулирована идея адаптивного потокового вещания. Адаптивное потоковое вещание (adaptive streaming) – это технология, которая используется для воспроизведения видео через компьютерные сети. В то время как ранее использовались специализированные протоколы, такие как RTP и RTSP, сейчас наметилась тенденция к использованию HTTP протокола.

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

  •  эффективное использование ресурсов конечного устройства, на котором осуществляется воспроизведение медиаконтента;
  •  существенно сокращенное время до начала воспроизведения;
  •  спорадическое возникновение ситуации, в которой мы ожидаем подгрузки медиаконтента.

Существует множество различных реализаций идеи адаптивного потокового вещания. Самые популярные из них:

  •  MPEG-DASH (Dynamic Adaptive Streaming over HTTP);
  •  Adobe Dynamic Streaming for Flash;
  •  Apple HTTP Adaptive Streaming;
  •  Microsoft Smooth Streaming;
  •  DivX Plus Streaming.

В ходе данной работы используется DivX Plus Streaming, так как работа выполняется в рамках компании Rovi. Подробный обзор остальных реализаций выходит за рамки данной работы.

Схематично принцип адаптивного потокового вещания изображен на рисунке ниже (рис. 2)

рис. 2 Адаптивное потоковое вещание

  1.  Медиаконтейнеры

Поскольку в данной работе речь идет о заранее подготовленном медиаконтенте, кратко опишем его специфику.

Заранее подготовленный (on-demand) медиаконтент представляет собой некоторый файл с различными потоками данных. Существуют три разновидности таких потоков:

  •  видеопоток – это массив байтов, в котором содержится информация о конкретных кадрах видео;
  •  аудиопоток – это массив байтов, в котором содержится информация о конкретных кадрах аудио;
  •  субтитры – это массив байтов, в котором содержится информация о символах, которые могут быть показаны вместе с изображением.

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

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

Медиаконтейнер (мультимедиаконтейнер) – это формат файла, спецификации которого определяют только способ сохранения данных (а не алгоритм кодирования) в пределах одного файла.

Существует множество различных спецификаций медаконтейнеров. Самыми популярными из них являются: AVI, MKV, MP4.

В общем случае медиаконтейнер состоит из следующих блоков (рис. 3):

  •  метаинформация – блок, содержащий информацию о типе медиаконтейнера, количестве потоков, временной продолжительности медиаконтента;
  •  видеопоток – непосредственно поток видеоданных;
  •  аудиопоток – непосредственно поток аудиоданных;
  •  дополнительная информация – блок, содержащий различную дополнительную информацию, которая может быть использована при воспроизведении видео (например, субтитры).

рис. 3 Общий вид медиаконтейнера

  1.  Медиаконвейер

В данный момент можно выделить два наиболее общих типа архитектуры, используемых в мультимедиа приложениях:

  •  Монолитная. Данный тип архитектуры предполагает, что всю работа по воспроизведению выполняет одна программа/компонента. Одним из главных минусов такой архитектуры является слишком большая трудоемкость ее расширения.
  •  Компонентная. Эта архитектура основана на принципе разделения ответственности за отдельные потоки работ на отдельные компоненты.

В последнее время де-факто стандартом является вторая архитектура. Она используется во множестве мультимедийных фреймворков, поэтому в дальнейшем весь процесс обработки медиаконтента мы будем рассматривать на примере именно этой архитектуры.

Вся работа по обработке медиаконтента разделяется между отдельными компонентами, именуемыми фильтрами (filters). Все такие фильтры могут иметь не менее одного входа и не менее одного выхода, которые именуются контактами (pins). Однако необходимо обратить внимание на то, что данная терминология распространена в связи с популярностью фреймворка Direct Show в прошлом и до сих пор используется специалистами в области мультимедиа, однако она может не совпадать с терминологией, используемой в других фреймворках. Входные контакты определяет список поддерживаемых форматов данных для фильтра, а выходные контакты определяют формат данных, который получится в результате деятельности данного фильтра. На основании информации, которую предоставляют контакты из фильтров, строится граф фильтров (filter graph) или медиаконвейер (multimedia pipeline), который производит все необходимые действия от открытия медиаконтейнера до визуализации его содержимого. Управлением графами фильтров занимается менеджер графа фильтров (filter graph manager). В других мультимедийных фреймворках, с которыми знаком автор работы, менеджер графа фильтров часто именуется сессией (session) или медиасессией (media session).

В зависимости от типа выполняемой деятельности фильтры можно разделить на три категории:

  •  источник (source) – фильтр читающий/принимающий медиаданные и предоставляющий их в граф;
  •  преобразователь (transform) – фильтр, выполняющий различные преобразования медиапотоков медиаконтейнера;
  •  визуализатор (renderer) – фильтр, передающий медиапотоки медиаконтейнера на различные устройства ввода/вывода видео- и аудиоданных.

Любой граф фильтров обладает следующими свойствами:

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

Очень схематично граф фильтров представлен на следующем рисунке (рис. 4).

рис. 4 Граф фильтров

Для того чтобы определиться, к какому из фильтров мы имеем непосредственное отношение, рассмотрим диаграмму (рис. 5), которая отражает деятельности, происходящие в процессе обработки видео, и определим на ней границы фильтров, которые занимаются той или иной деятельностью.

Отдельно необходимо отметить два момента. Во-первых, разделение различных потоков называется демультиплексированием или демуксированием (demultiplexing/demuxing). А во-вторых, определение типа медиаконтейнера происходит для того, чтобы мы точно знали, сможет ли наш фильтр-источник работать с данным медиаконтейнером или нет; в этом случае мы не получим совершенно неожиданное поведение, если данные упакованы не так, как мы ожидаем.

Обратим внимание на то, что идея адаптивного потокового вещания должна быть реализована на этапе работы фильтра-источника, потому что именно он отвечает за получение данных из сети. Библиотека DivX Plus Streaming помимо реализации алгоритмов переключения между различными качествами медиаконтента реализует часть работы, которую должен реализовывать фильтр-источник, а именно:

  •  получает данные из сети;
  •  определяет медиаконтейнер;
  •  отдает нам блоки прочитанных данных.

рис. 5 Диаграмма деятельности

  1.  Технические требования и задачи

В рамках поставленной цели были сформулированы следующие технические требования:

  1.  Для решения данной задачи необходимо использовать готовую библиотеку DivX Plus Streaming, реализующую клиентскую часть механизма адаптивного потокового вещания (далее унаследованный код). Данная библиотека используется во многих продуктах компании Rovi, поэтому необходимо использовать ее в том виде, в котором она существует, без внесения каких-либо сложных изменений.
  2.  Процесс разработки необходимо максимально упростить с целью написания наименьшего количества кода за наиболее короткий промежуток времени.
  3.  Для декодирования медиаконтента крайне желательно использование возможностей аппаратного декодирования. Это обусловлено тем фактом, что процесс программного декодирования мультимедиа данных является очень ресурсоемким. На большинстве мобильных устройств до сих пор недостаточно вычислительных мощностей для программного декодирования видео высокого качества.

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

Исходя из всего вышесказанного, можно сформулировать следующие задачи:

  1.  рассмотреть мультимедиа фреймворки целевой платформы и выбрать наиболее подходящий для поставленной цели;
  2.  разработать исполняемый эволюционный прототип приложения.

  1.  Мультимедийные фреймворки в Windows Phone 8

2.1 Введение

Подготовка к разработке прототипа приложения была начата еще до официального выхода Windows Phone 8. Поэтому для анализа использовались исходные коды, неофициально на тот момент попавшего в сеть SDK, и, частично, официальная документация.

В процессе анализа было обнаружено два мультимедийных фреймворка: Microsoft Media Foundation и .NET Framework. Необходимо отметить, что .NET Framework сам по себе не является мультимедийным фреймворком, однако в нем есть набор классов и интерфейсов, реализующих необходимую нам функциональность. Более подробно остановимся на каждом и них.

  1.  Microsoft Media Foundation

  1.  Архитектура Microsoft Media Foundation

Media Foundation – это мультимедийный фреймворк, созданный корпорацией Microsoft для работы с мультимедийным контентом в операционных системах семейства Windows. Согласно планам Microsoft, он заменит DirectShow, Windows Media SDK, DirectX Media Objects (DMOs) и более старые мультимедийные API, такие, как Audio Compression Manager (ACM) и Video for Windows (VfW). В Windows XP и более старых операционных системах использование MF не планируется.

Архитектура Media Foundation разделена на три слоя (рис. 6): слой управления (control layer), слой платформы (platform layer) и слой ядра (core layer).


рис. 6 Архитектура Microsoft Media Foundation

Слой управления выполняет множество различных функций по организации процесса обработки медиаконтента. Именно слой управления подбирает подходящие фильтры и выстраивает из них граф.

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

Слой платформы – это слой различных низкоуровневых служб и классов. В ответственность этого слоя входит синхронизация различных фильтров графа, организация обмена сообщениями между участниками процесса обработки, а также вся низкоуровневая работа с элементарными потоками.

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

  1.  Архитектура медиаконвейера в Microsoft Media Foundation

Медиаконвейер в Microsoft Media Foundation, который официально именуется Media Foundation Pipeline, может быть организован двумя различными способами (рис. 7).

Первый способ, изображенный на рисунке слева, представляет уже описанный ранее граф фильтров. В нем присутствуют:

  •  Media Session – менеджер графа фильтров;
  •  Media Source – фильтр-источник;
  •  MFT (Media Foundation Transforms) – фильтры-преобразователи;
  •  Media Sink – фильтр-визуализатор.

В качестве контактов у фильтров выступают медиа типы (Media Types), которые заполняются в процессе работы соответствующих фильтров.

Второй способ, который изображен на рисунке справа, представляет собой устаревший вариант организации обработки медиапотоков. В данном варианте Source Reader используется для чтения/получения данных и получения из них несжатых потоков, а Source Writer выполняет действия по обратной логике – сжимает потоки и записывает их или выводит на устройство вывода.

рис. 7 Архитектура медиаконвейера в Microsoft Media Foundation

Отметим, что для наших целей больше подходит первый вариант организации медиаконвейера. Во-первых, он является более гибким, а во-вторых, второй вариант официально объявлен компанией Microsoft устаревшим (deprecated).

Одним из главных минусов данного фреймворка является факт отсутствия информации о том, будут ли готовые реализации фильтров-преобразователей и фильтров-визуализаторов подстраиваться под новые входные данные автоматически. Иначе говоря, мы имеем две возможные ситуации:

  •  мы должны уничтожить текущий граф фильтров и построить его заново, переконфигурировав новыми данными;
  •  мы можем надеяться на то, что готовые реализации фильтров, которые мы будем использовать, подстроятся под новые входные данные.

В первом случае возникает сразу две проблемы. Во-первых, это проблема производительности: поскольку части для переключения качества, на которые разделен входной медиаконтент, имеют сравнительно небольшую длину (2 секунды), в случае частых скачков скорости интернета мы рискуем постоянно пересобирать граф фильтров, что неминуемо скажется на производительности. Во-вторых, остается неясным, как поступать с данными, которые уже были прочитаны, но еще не были воспроизведены. В случае, когда мы пересобираем граф фильтров, мы можем их просто потерять и, конечно, это не пройдет незаметно для пользователя, у которого неминуемо станет обрываться изображение и звук.

  1.  Определение необходимых интерфейсов

Для реализации необходимой нам функциональности Microsoft Media Foundation предоставляет набор интерфейсов, которые нам необходимо реализовать, а именно:

  •  IMFMediaSource;
  •  IMFByteStreamHandler;
  •  IMFMediaStream;
  •  IMFAsyncCallback;
  •  IMFAsyncResult;
  •  IMFPresentationDescriptor;
  •  IMFStreamDescriptor;
  •  IMFSample.

Остановимся на этих интерфейсах чуть более подробно и рассмотрим, для чего они нужны.

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

Фильтр-источник, именуемый во фреймворке MediaSource, должен состоять как минимум из двух частей:

  •  Presentation Descriptor – описатель содержимого файла, который хранит в себе метаинформацию о том, сколько конкретно в медиаконтейнере медиапотоков, какого типа каждый из них и т.д. Вся сопроводительная информация о медиапотоках хранится в объектах типа IMFSreamDescriptor. Для того чтобы его объявить, необходимо воспользоваться интерфейсом IMFPresentatonDescriptor.
  •  Один или более объектов типа IMFMediaStream. Можно подумать, что объекты, являющиеся инстансами класса, унаследовавшего вышеописанный интерфейс, являются моделями элементарных медиапотоков, однако это не так. На самом деле данные объекты занимаются извлечением данных из элементарных медиапотоков.

В качестве объекта типа IMFPresentationDescriptor может быть использована стандартная реализация, которая уже доступна во фреймворке. Однако класс, который наследует интерфейс IMFMediaStream, придется реализовывать самостоятельно. Сам же фильтр-источник должен обязательно реализовывать интерфейсы IMFMediaSource и IMFAsyncCallback.

В процессе обработки входных данных фильтром-источником мы получаем порции данных, которые затем отправляем далее по медиаконвейеру. Эти данные упаковываются в объекты типа IMFSample в отличие от многих других мультимедийных фреймворков, где данные складываются в буфер, который является областью памяти, доступной фильтру-источнику и фильтру-преобразователю одновременно.

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

  1.  Список поддерживаемых форматов

Согласно техническим требованиям, крайне желательна ситуация, при который мы смогли бы воспользоваться аппаратным способом декодирования видео. Рассмотрим список форматов сжатия видео, для которых доступно аппаратное декодирование:

  •  H.264/AVC;
  •  Windows Media Video (WMV);
  •  MPEG-4 Part 2;
  •  MPEG-4 v1/v2/v3.

В нашем случае ключевыми форматами являются MPEG-4 и H.264/AVC. Именно эти форматы используются в компании Rovi для кодирования видеопотоков. Кроме того, также интересным для нас фактом является поддержка формата AAC для сжатия аудиопотоков; именно этот формат используется в компании Rovi. Хотя у нас нет необходимости использовать аппаратное декодирование для аудиопотоков, но сам факт наличия данного формата в списке свидетельствует о том, что для него существует готовая реализация декодера, что соответственно упрощает разработку.

  1.  .NET Framework

  1.  Необходимые классы

В отличие от Microsoft Media Foundation с множеством его интерфейсов в .NET Framework интерес для нас представляют всего два класса: абстрактный MediaStreamSource и MediaElement.

MediaElement представляет собой класс, который конфигурируется инстансом класса MediaStreamSource и занимается визуализацией проигрываемого медиаконтента. Все, что требуется от разработчика, – это написать реализацию класса, унаследованного от абстрактного MediaStreamSource.

Сама реализация в нашем случае MediaStreamSource заключается в реализации следующих методов:

  •  ReportOpenMediaCompleted;
  •  OpenMediaAsync;
  •  GetSampleAsync;
  •  ReportGetSampleCompleted;
  •  CloseMedia.

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

Кроме того, поскольку MediaElemеnt является в том числе и графическим примитивом, нам не нужно самим определять способы воспроизведения видео и звука. Достаточно разместить данный элемент на форме.

В отличие от Microsoft Media Foundation, где многопоточность реализована на уровне управляющего слоя, при реализации фильтра в рамках данного фреймворка нам придется позаботиться о многопоточности самостоятельно.

  1.  Список поддерживаемых форматов

Список поддерживаемых форматов для данного фреймворка немногим отличается от предыдущего:

  •  H.264/AVC;
  •  MPEG-4 Part 2;
  •  Windows Media Video (WMV);
  •  Video Coding 1 (VC-1).

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

  1.  Вывод

Результат анализа мультимедийных фреймворков мы можем отразить в следующей таблице:

Характеристика

Microsoft Media Foundation

.NET Framework

Простота реализации фильтра-источника  

Нет

Да

Многопоточность

Реализована

Реализуется самостоятельно

Переконфигурация фильтров графа происходит автоматически

Неизвестно

Да

Необходимость написания реализации фильтров-преобразователей и фильтров-визуализаторов

Нет

Нет

Поддержка аппаратного декодирования видео

Да

Да

Таким образом, можно заключить, что для решения нашей задачи более подходит .NET Framework.

Кроме того, автор работы провел консультации на официальном форуме Microsoft для разработчиков относительно того, какой фреймворк лучше использовать для поставленной цели. Разработчики, занимающиеся мультимедиа технологиями в платформе Windows Phone 8, посоветовали использовать .NET Framework. Аналитика, а также учет мнения специалистов-разработчиков обусловили решение остановиться на последнем.

3 Реализация

3.1 Windows Phone Runtime Component и C++/CX

Выбор фреймворка, с помощью которого будет реализовываться весь дальнейший функционал, мотивировал переход непосредственно к реализации. Однако стоит отметить вопрос, который возник на этом этапе. На данном этапе мы имеем следующее:

  •  библиотека DivX Plus Streaming, реализующая идею адаптивного потокового вещания, написана на С++ и компилируется в машинный код;
  •  приложение и фильтр-источник будут написаны на C# и будут скомпилированы в промежуточный код на Common Intermediate Language (CIL).

Таким образом, мы не можем просто так воспользоваться классами из унаследованного кода. Соответственно перед нами встает вопрос о том, как решить возникшую проблему. Операционные системы Microsoft восьмого поколения предлагают нам способ решения проблем подобного рода.

Windows Runtime является новой моделью программирования от Microsoft, которая используется для написания приложений для операционных систем Windows 8 и Windows Phone 8. Данная модель предоставляет нам возможности по совместному использованию приложений и компонент, написанных на разных языках (С++, С#, Javascript и VB.NET).

Для того чтобы использовать код, написанный на С++, нам предлагается использовать расширение языка, именуемое Common Extensions или C++/CX.

Windows Runtime по существу является API на основе технологии COM. Но официально Microsoft говорит нам о том, что использование аббревиатуры COM в данном случае не совсем корректно, потому как WinRT – это нечто большее, чем просто COM. В рамках данной работы эта информация не является очень существенной, однако автор делает это замечание, дабы у реципиента не сложилось неверное впечатление.

Язык C++/CX практически идентичен языку C++/CLI (хотя и не на 100%). Последний ранее использовался в Common Language Runtime для написания управляемого C++ кода. Из официальной документации по созданию Windows Runtime Component’ов можно выделить строчки, которые в дословном переводе звучат следующим образом: «Есть несколько причин для создания подобного компонента, одна из них – повторное использование кода, который уже написан и протестирован». Стоит отметить, что речь тут идет как раз о С++ коде. В результате было принято решение воспользоваться данной технологией.

В нашем случае был написан Windows Phone Runtime Component. В зависимости к данному проекту была добавлена оригинальная библиотека DivX Plus Streaming. В самом же компоненте был реализован класс DPSWrapper, который по сути является оберткой вокруг исходной библиотеки. Сам класс по правилам C++/CX должен быть объявлен с ключевым слово sealed. Это означает, что от данного класса не может быть унаследован какой-либо другой класс.

Для решения проблем с преобразованием встроенных типов (например, .NET Framework нет типа std::vector, который является частью STL библиотеки для C++) в C++/CX предлагается использовать специальные Windows Runtime типы, которые одинаковы для всех языков в рамках Windows Runtime.

В конечном итоге написанный код был скомпилирован в DLL библиотеку (.winmd), которая может быть легко добавлена в качестве зависимости в любое Windows Store приложение и использоваться без каких-либо дополнительных усилий. Полученный результат можно описать диаграммой пакетов, изображенной на рисунке рис. 8.

рис. 8 Диаграмма пакетов 1

  1.  Реализация фильтра-источника

3.2.1 Процесс обработки медиаконтента

Как уже было сказано ранее, для обработки медиаконтента нам потребуется два класса: MediaStreamSource и MediaElement. Для достижения нашей цели мы объявляем класс DivXStreamSource, который является наследником класса MediaStreamSource, а класс MediaElement мы используем в том виде, в котором он нам предоставлен. В классе DivXStreamSource нам потребуется реализовать ряд методов, которые необходимых для корректной работы. Список этих методов уже был описан ранее. На рис. 9 представлена полученная диаграмма классов, а на рис. 10 итоговая диаграмма пакетов.

рис. 9 Диаграмма классов

рис. 10 Диаграмма пакетов 2

Далее мы конфигурируем объект класса MediaElement объектом класса MediaStreamSource с помощью метода MediaElement.SetSource. Данный метод имеет следующую сигнатуру:

public void SetSource(MediaStreamSource mediaStreamSource).

Объект класса MediaElement меняет состояние объекта класса MediaStreamSource на Opening и вызывает метод MediaStreamSource.OpenMediaAsync.

protected abstract void OpenMediaAsync()

В методе OpenMediaAsync мы обращаемся к библиотеке DivX Plus Streaming с помощью написанного нами Windows Phone Runtime Component’а и получаем из нее данные, необходимые для конфигурации графа фильтров.

Для медиаконтента мы должны собрать следующую информацию:

  •  продолжительность;
  •  поддержка возможности перемещения по файлу.

Данная информация хранится в медиаконтенере в блоке метаинформации. В рамках создания прототипа не было необходимым условием поддерживать возможность перемещения по файлу (хотя медиаконтент поддерживает данную возможность),  поэтому данный параметр не использовался. Кроме уже озвученной информации, необходимо собрать информацию о медиапотоках проигрываемого медиаконтента, которая должна содержать:

  •  идентификаторы способов кодирования медиапотоков;
  •  набор байтов, необходимых для инициализации декодера (codec private data).

Например, для видеопотока, закодированного с помощью формата H.264 информация для инициализации декодера будет выглядеть следующим образом:

0x00000001 SequenceParameterSet 0x00000001 PictureParameterSet

Данная форма является частью стандарта ISO/IEC-14496-10. В данном контексте SequenceParameterSet является набором байт, характеризующих изображение, а PicturePameterSet – байтами самого изображения.

Если в медиаконтенте присутствует видеопоток, нам необходимо также указать ширину и высоту оригинального изображения.

Данная информация передается фреймворку с помощью метода MediaStreamSource.ReportOpenMediaCompleted следующими параметрами:

  •  словарь атрибутов, описывающий медиаконтент;
  •  коллекция объектов типа MediaStreamDescription для видео- и аудиопотоков.

protected void ReportOpenMediaCompleted(

IDictionary<MediaSourceAttributesKeys, string> mediaStreamAttributes,

IEnumerable<MediaStreamDescription> availableMediaStreams

)

Результатом вызова этого метода станет построение графа фильтров, необходимых для обработки медиаконтента.

После этого состояние фильтра-источника изменяется на Streaming (о возможных состояниях мы поговорим чуть позже). На этом этапе у нас начинают запрашивать порции данных, именуемых сэмплами (samples), с помощью метода MediaStreamSource.GetSampleAsync, аргументом которого является тип медиапотока, из которого мы хотим получить данные. Отметим, что об этом процессе мы говорили ранее, называя его демультиплексированием или демуксированием.

protected abstract void GetSampleAsync(MediaStreamType mediaStreamType)

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

protected void ReportGetSampleCompleted(MediaStreamSample mediaStreamSample)

Визуализацию этих процессов можно также увидеть на диаграммах последовательностей на рисунках рис. 11 и рис. 12.

рис. 11 Диаграмма последовательности 1

рис. 12 Диаграмма последовательности 2

3.2.2 Управления состояниями и очередями сэмплов

В то время, как объект класса MediaElement хранит свое состояние внутри себя, состояния объекта класса MediaStreamSource определяются в зависимости от того, какие методы были уже вызваны, но их выполнение еще не было закончено.

Объект класса MediaStreamSource может находиться в следующих состояниях:

  •  «opening» - данное состояние говорит нам о том, что фильтр-источник в данный момент выполняет открытие файла, либо вызов метода MediaStreamSource.OpenMediaAsync не закончился вызовом метода MediaStreamSource.ReportOpenMediaCompleted;
  •  «seeking» - фильтр-источник находится в данном состоянии в случае, когда мы перемещаемся по медиаконтейнеру (в рамках данной работы оно не используется);  
  •  «streaming» - в этом состоянии фильтр-источник находится во время воспроизведения меаконтента, иными словами был вызван метод MediaStreamSource.GetSampleAsync и фильтр-источник ответит на него вызовом метода MediaStreamSource.ReportGetSampleCompleted так скоро, как только это будет возможно;
  •  «buffering» - это состояние говорит нам о том, что фильтр-источник получил запрос на формирование очередного сэмпла (MediaStreamSource.GetSampleAsync), но очередь сэмплов пуста (MediaStreamSource.ReportGetSampleCompleted), поэтому был вызван метод MediaStreamSource.ReportGetSampleProgress;
  •  «mediaEnded» - в данное состояние фильтр-источник переходит после того, как все доступные сэмплы были обработаны, это состояние наступает в тот момент, когда на запрос очередного сэмпла методом MediaStreamSource.GetSampleAsync были отправлены специальные сэмплы, которые означают конец медиапотока;
  •  «closed» - был вызван метод MediaStreamSource.CloseMedia.

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

Одной из наиболее сложных задач в реализации MediaStreamSource является правильная реализация очередей сэмплов. При некорректной реализации появляется риск «голодания» графа фильтров или, иными словами, нехватки данных для обработки. При такой ситуации фильтр-источник будет постоянно оказываться в состоянии «buffering», что сделает бессмысленным использование идеи адаптивного потокового вещания.

Правильная реализация предполагает наличие двух таких очередей:

  •  очередь, в которой располагаются данные вне зависимости от их принадлежности какому-либо медиапотоку;
  •  очереди для каждого конкретного медиапотока, в которой располагаются конкретные сэмплы;

В течение нормального процесса воспроизведения наблюдается следующая последовательность шагов:

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

Кроме реализации двух описанных очередей, на основе статистических данных были подобраны глубины очередей, причем такие, что время нахождения фильтра-источника в состоянии «buffering» в процессе воспроизведения было сведено практически к нулю.

  1.  Скриншоты приложения

Заключение

В результате данной работы был реализован исполняемый эволюционный прототип приложения, реализующий интеграцию DivX Plus Streaming с платформой Windows Phone 8. Данный прототип будет использован в компании Rovi для последующего написания полноценного приложения под указанную платформу.

В ходе данной работы автор познакомился с:

  •  организацией процесса воспроизведения медиаконтента
  •  системами адаптивного потокового вещания на примере DivX Plus Streaming
  •  мультимедийными фреймворками платформы Windows Phone 8

Результаты работы могут быть использованы при обучении студентов-стажеров компании Rovi на начальном этапе стажировки, поскольку область мультимедиа программирования  имеет высокий порог вхождения.

Список использованных источников и литературы

  1.  Англо-русский и русско-английский словарь компьютерной лексики. Авт.–сост.: И. Н. Мизинина, А. И. Мизинина, И. В. Жильцов.-  М.: ОЛМА-Пресс Образование, 2004.- 696с.
  2.  MSDN (Microsoft Developer Network) Library – September 2012
  3.  Polinger A. Developing Microsoft Media Foundation Applications. – Sebastopol: O’Reilly Media, Inc., 2011.
  4.  Streaming media architectures, techniques and applications : recent advances / Ce Zhu, Yuenan Li, and Xiamu Niu, editors. - New York: Hershey, 2011.  - 482 р. - InformatIon scIence reference.

PAGE   \* MERGEFORMAT1

Медиаконтейнер

Метаинформация

Видеопоток

Аудиопоток

Субтитры


 

А также другие работы, которые могут Вас заинтересовать

54383. Конкурсно – розважальна програма: «Міс Екологія» 34 KB
  Людська цивілізація вступила в таку форму розвитку, коли її доля вирішується не науково-технічним прогресом, а глибиною екологічних знань та вмінням діяти відповідно до цих знань. Завданням нашого конкурсу є – визначити творчий потенціал кожної учасниці.
54384. MISTER OF THE 5-В FORM 58.15 KB
  Dear participants, guests, jurors. Thanks you for being so active, diligent and clever. It's high time to score the results of our contest and to announce the nominations.
54385. Виховний захід для третьокласників «Містер класу» 55 KB
  Тоненьке кругленьке серце чорненьке Хто на його слід погляне думку його взнає Олівець Що ми робимо олівцем Малюємо Наступний конкурс 2К Містер художник. Наступний конкурс Містер поет. Містер ерудит На подвір’ї ходить декілька кур.
54386. Основные тенденции развития мировой культуры на рубеже XX - XXI веков 17.12 KB
  Анализируя произошедшие исторические события, развитие научно-технического прогресса, панораму художественной культуры, следует выделить основные тенденции и проблемы развития мировой культуры ХХ-XXI вв.
54387. Європейське середньовічне місто 276.5 KB
  Європейське середньовічне місто. Пояснити причини появи середньовічних міст; охарактеризувати цехове ремесло побут житло і заняття городян показати середньовічне місто як центр ремесла і торгівлі; розвивати навички роботи а групах аналізу документів вміння розв’язувати історичні задачі й проблемні завдання; виховувати інтерес до середньовічної історії. На кінець уроку ми зможемо:...
54388. Раціональні числа. Додавання і віднімання раціональних чисел. Система координат 46.5 KB
  Розмістити числа в порядку зростання. Але ці числа не прості кожному з них відповідає літера. Чому числа бувають додатні і від’ємні Числа люди Країна Модульна Вірш про додатні і від’ємні числа Казка про числа Предмет математика наскільки серйозний що корисно використовувати будьяку нагоду зробити його цікавим.
54389. Значение культурологии в профессиональной деятельности современного специалиста в сфере национальной экономики и управления 14.73 KB
  Культурология - новая дисциплина с пока неустоявшейся предметной областью и огромным познавательным потенциалом — занимает особое место среди гуманитарных дисциплин.
54390. Значение культурологии в разрешении глобальных проблем современности 15.16 KB
  В последнее время остро чувствуется тревога за экологические катастрофы, распространения экстремизма и терроризма, мирового финансового кризиса, дисбаланса базовых ценностей культуры, стихийного развития цивилизаций