Данные media foundation что это

Общие сведения об архитектуре Media Foundation

В этом разделе описывается общий дизайн Microsoft Media Foundation. Сведения об использовании Media Foundation для конкретных задач программирования см. в разделе Media Foundation Guide по программированию.

На следующей схеме показано высокоуровневое представление архитектуры Media Foundation.

Media Foundation предоставляет две различные модели программирования. Первая модель, показанная в левой части диаграммы, использует сквозной конвейер для данных мультимедиа. Приложение инициализирует конвейер, например, предоставляя URL-адрес файла для воспроизведения, а затем вызывает методы для управления потоковой передачей. Во второй модели, показанной в правой части схемы, приложение либо извлекает данные из источника, либо передает их в назначение (или и то, и другое). Эта модель особенно полезна, если необходимо обработать данные, так как приложение имеет прямой доступ к потоку данных.

Примитивы и платформа

Начиная с нижней части диаграммы, примитивы являются вспомогательными объектами, используемыми во Media Foundation API:

Интерфейсы api Media Foundation платформы предоставляют некоторые основные функции, используемые конвейером Media Foundation, например асинхронные обратные вызовы и рабочие очереди. Некоторым приложениям может потребоваться вызывать эти API напрямую; Кроме того, они понадобятся вам при реализации пользовательского источника, преобразования или приемника для Media Foundation.

Конвейер мультимедиа

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

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

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

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

Средство чтения исходного кода и модуль записи приемника предоставляют альтернативный способ использования основных компонентов Media Foundation (источников мультимедиа, преобразований и приемников носителей). Модуль чтения исходного кода размещает источник мультимедиа и ноль или более декодеров, в то время как модуль записи приемника содержит приемник мультимедиа и ноль или более кодировщиков. Модуль чтения исходного кода можно использовать для получения сжатых или несжатых данных из источника мультимедиа и использования модуля записи приемника для кодирования данных и отправки данных в приемник мультимедиа.

средство чтения исходного кода и модуль записи приемника доступны в Windows 7.

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

Источник

О Media Foundation

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

для Media Foundation требуется Windows Vista или более поздней версии. Он использует объектную модель COM и требует C/C++. Корпорация Майкрософт не предоставляет управляемый API для Media Foundation.

Media Foundation интерфейсы api являются частью Windows SDK. чтобы разработать приложение Media Foundation, установите последнюю версию Windows SDK.

Качество звука и видео

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

Ускорение видео DirectX (ДКСВА) 2,0 предлагает более эффективное ускорение видео по сравнению с ДКСВА 1,0, благодаря более надежному и упрощенному декодированию видео и расширенному использованию оборудования при обработке видео. с помощью дксва 2,0 Windows может справиться с наиболее требовательным содержимым высокой четкости с высоким качеством и повышенной устойчивостью к сбоям.

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

Улучшенный модуль подготовки видео (Евр) обеспечивает лучшую поддержку времени, улучшенную обработку видео и повышает устойчивость к сбоям. Улучшена поддержка воспроизведения в полноэкранном режиме, и воспроизведение видео в окне режима было минимальным.

Media Foundation использует службу диспетчера классов мультимедиа (MMCSS), новую системную службу в Windows Vista. Служба MMCSS позволяет приложениям мультимедиа гарантировать, что их обработка с учетом времени получит приоритетный доступ к ресурсам ЦП.

Доступ к содержимому

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

Кроме того, Media Foundation расширяемость позволяет различным системам защиты содержимого взаимодействовать друг с другом.

О Media Foundation

В этом разделе содержатся общие сведения об API-интерфейсах Media Foundation. Подробные сведения о программировании можно найти в Media Foundationном руководством по программированию.

Источник

Media Foundation: основные понятия

Если вы не знакомы с цифровыми носителями, в этом разделе рассматриваются некоторые понятия, которые необходимо знать перед написанием Media Foundation приложения.

Потоки

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

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

Сжатие

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

В большинстве других доменов сжатие с потерей данных неприемлемо. (Imagine получения «приближения» к таблице!) Но схемы сжатия с потерей данных хорошо подходят для аудио и видео по нескольким причинам.

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

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

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

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

Контейнеры мультимедиа

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

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

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

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

Форматы

В цифровом носителе термин Формат неоднозначна. Формат может ссылаться на тип кодировки, например H. 264 Video или контейнер, например MP4. Это различие часто вызывает путаницу для обычных пользователей. Имена, предоставленные форматам мультимедиа, не всегда помогают. Например, MP3 ссылается как на формат кодирования (звуковой слой MPEG-1 3), так и на формат файла.

Различие очень важно, так как чтение файла мультимедиа фактически состоит из двух этапов:

Этот факт довольно естественно подходит для проектирования программного обеспечения, где отдельные компоненты используются для анализа контейнеров и декодирования потоков. Кроме того, этот подход предоставляется модели подключаемых модулей, чтобы сторонние стороны могли предоставлять собственные средства синтаксического анализа и кодеки. в Windows модель COM предоставляет стандартный способ отделения API от реализации, что является требованием для любой модели подключаемых модулей. По этой причине (в других случаях) Media Foundation использует COM-интерфейсы.

На следующей схеме показаны компоненты, используемые для чтения файла мультимедиа.

Для записи файла мультимедиа также необходимо выполнить два действия:

На следующей схеме показаны компоненты, используемые для записи файла мультимедиа.

Источник

Новые возможности для Media Foundation

Microsoft Media Foundation был введен в Windows Vista в качестве замены DirectShow. конечно, DirectShow по-прежнему поддерживается в Windows 7, но разработчикам рекомендуется использовать Media Foundation в своих новых цифровых мультимедийных приложениях.

Улучшения Media Foundation можно суммировать следующим образом.

Улучшенная поддержка формата

Media Foundationный конвейер аудио/видео был реализован в Windows Vista, но поддерживал ограниченный набор форматов и контейнеров файлов, что означало, что некоторые приложения должны возвращаться к старым технологиям, таким как DirectShow. в Windows 7 Media Foundation содержит следующие новые кодеки, источники мультимедиа и приемники мультимедиа:

Приемник файлов в формате MP3 не включает кодировщик аудио MP3.

Поддержка аппаратных устройств

Media Foundation теперь поддерживает следующие типы аппаратных устройств в конвейере аудио/видео:

Аппаратные кодеки могут выполнять очень быстрое перекодирование видео. например, приложение может передавать Windows файлы мультимедиа видео (WMV) на сотовый телефон, который поддерживает только файлы 3GP. С помощью аппаратного кодировщика приложение может перекодировать файл в баккгаунд, непосредственно перед его передачей на устройство.

Аппаратные устройства представлены в Media Foundation прокси-объектом и используются в конвейере так же, как программные компоненты.

Упрощенная модель программирования

в Windows Vista Media Foundation представляет собой набор интерфейсов api относительно низкого уровня. Эти API являются гибкими, но слишком сложны для простых задач. Windows 7 добавляет новые высокоуровневые api, упрощающие написание мультимедийных приложений на C++. Ниже приведены новые высокоуровневые API-интерфейсы.

Вы по-прежнему можете использовать низкоуровневые API в Media Foundation. Это можно сделать, если вам нужен больший контроль над конвейером аудио/видео.

Усовершенствования платформы

Windows 7 включает многочисленные улучшения для базовых api-интерфейсов Media Foundationной платформы. Расширенные приложения могут использовать эти API напрямую; другие приложения будут косвенно получать преимущества. В них сочетаются все лучшие возможности веб-заданий, а также добавлены некоторые улучшения, среди которых:

Изменения пакета SDK

Новые Windows 8

некоторые из новых обновлений для Media Foundation с Windows 8:

Источник

Второй выпуск, включенный в Windows 7, представляет расширенную поддержку медиаформатов и DXVA HD для ускорения HD-контента при использовании драйверов WDDM 1.1.

СОДЕРЖАНИЕ

Архитектура

Практические архитектуры MF

Теоретически существует только одна архитектура Media Foundation, и это модель Media Session, Pipeline, Media Source, Transform и Media Sink. Однако эта архитектура может быть сложной в настройке, и существуют значительные возможности для легких, относительно простых в настройке компонентов MF, предназначенных для обработки медиаданных для простых точечных решений. Таким образом, практические соображения вызвали необходимость реализации вариаций фундаментальной конструкции конвейера, и были разработаны такие компоненты, как Source Reader и Sink Writer, которые работают вне модели конвейера. Некоторые источники разделяют архитектуру Media Foundation на три основных класса.

Архитектура конвейера отличается использованием отдельного объекта Media Session и конвейера. Медиа-данные передаются из одного или нескольких источников мультимедиа в один или несколько приемников мультимедиа и, необязательно, проходят через ноль или несколько преобразований мультимедиа. Медиа-сеанс управляет потоком мультимедийных данных через конвейер, и этот конвейер может иметь несколько разветвлений и ответвлений. Приложение MF может получить доступ к мультимедийным данным при переходе от источника мультимедиа к приемнику мультимедиа, реализовав настраиваемый компонент преобразования мультимедиа и вставив его в соответствующее место в конвейере.

Архитектура Reader-Writer использует компонент, называемый Source Reader, для предоставления мультимедийных данных и компонент Sink Writer для их использования. Source Reader действительно содержит тип внутреннего конвейера, но он недоступен для приложения. Источник чтения не является источником мультимедиа, а устройство записи приемника не является приемником мультимедиа, и ни одно из них не может быть напрямую включено в конвейер или управляться сеансом мультимедиа. Как правило, мультимедийные данные передаются от устройства чтения источника к устройству записи приемника действиями приложения. Приложение либо принимает пакеты мультимедийных данных (называемых образцами мультимедиа) из Source Reader и передает их непосредственно в Sink Writer, либо оно настраивает функцию обратного вызова в Source Reader, которая выполняет ту же операцию. Фактически, поскольку оно управляет транспортировкой данных, само приложение выполняет ту же роль, что и сеанс мультимедиа в приложении с архитектурой конвейера. Поскольку приложение MF управляет передачей образцов мультимедиа между устройством чтения источника и записывающим устройством, оно всегда будет иметь доступ к необработанным мультимедийным данным. Компоненты Source Reader и Sink Writer действительно имеют ограниченные возможности по автоматической загрузке Media Transforms, чтобы помочь с преобразованием формата мультимедийных данных, однако это делается внутренне, и приложение мало контролирует это.

Source Reader и Sink Writer обеспечивают простоту использования, а конвейерная архитектура предлагает чрезвычайно сложный контроль над потоком мультимедийных данных. Однако многие компоненты, доступные для конвейера (например, Enhanced Video Renderer), просто не могут быть легко использованы в архитектурном приложении Reader-Writer. Поскольку структура образца мультимедиа, созданного программой чтения исходного кода, идентична тому, что выводится источником мультимедиа, можно настроить конвейерную архитектуру, в которой образцы мультимедиа перехватываются, когда они проходят через конвейер, а копия передается в Медиа-раковина. Это известно как гибридная архитектура, и она позволяет иметь приложение, которое использует преимущества сложных возможностей обработки сеанса мультимедиа и конвейера, используя при этом простоту использования Sink Writer. Sink Writer не является частью конвейера и не взаимодействует с медиа-сеансом. Фактически, мультимедийные данные обрабатываются специальным приемником мультимедиа, который называется приемником захвата образцов, который потребляет мультимедийные данные и передает копию устройству записи приемника. Также возможно реализовать гибридную архитектуру с настраиваемым преобразованием мультимедиа, которое копирует образцы мультимедиа и передает их устройству записи приемника, когда они проходят через конвейер. В обоих случаях специальный компонент в конвейере эффективно действует как простое приложение Reader-Writer и питает Sink Writer. Как правило, гибридные архитектуры используют конвейер и модуль записи приемника. Теоретически можно реализовать механизм, в котором средство чтения исходного кода могло бы каким-то образом вводить образцы мультимедиа в конвейер, но, в отличие от приемника захвата образцов, такого стандартного компонента не существует.

Преобразование Media Foundation

Улучшенное средство визуализации видео

Поддерживаемые медиа-форматы

Воспроизведение MIDI также пока не поддерживается с помощью Media Foundation.

Поддержка приложения

Приложения, поддерживающие Media Foundation, включают:

Любое приложение, использующее Protected Media Path в Windows, также использует Media Foundation.

Источник