Поделиться через

Метод IMFExtendedDRMTypeSupport::IsTypeSupportedEx (mfmediaengine.h)

  • Статья

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

Синтаксис

HRESULT IsTypeSupportedEx(
  [in]  BSTR                    type,
  [in]  BSTR                    keySystem,
  [out] MF_MEDIA_ENGINE_CANPLAY *pAnswer
);

Параметры

[in] type

Объект BSTR, определяющий функции, для которых запрашивается поддержка. Этот параметр принимает строки Content-Type RFC 2045 для указания идентификаторов типов мультимедиа и подтипов, а также идентификаторы кодеков RFC 6381 для необходимых кодеков. Эти базовые строки согласуются с теми, которые используются в методе HTML5 HTMLMediaElement canPlayType. RFC 2045 допускает дополнительные настраиваемые параметры в качестве модификаторов в виде ";<parameter>=<name>[=<value>] [,<name>[=<value>]". Средства синтаксического анализа, совместимые с RFC 2045, должны игнорировать эти параметры, если они не распознаны. Для запросов функций имеет имя feature.

Реализация требует, чтобы тип носителя RFC 2045 и идентификаторы подтипа, например video/mp4, и параметр кодека RFC 6381 codec="<video codec>[,<audio codec>]" всегда присутствовал, чтобы предоставить допустимые результаты запроса.

Обратите внимание, что термины тип контента и тип хорошо известны как тип MIME.

[in] keySystem

Объект BSTR, определяющий пространство имен PlayReady, к проверка запрос с указанием аппаратной или программной защиты. Используйте "com.microsoft.playready.recommendation.3000" для аппаратных запросов (PlayReady должна иметь поддержку аппаратной разгрузки), "com.microsoft.playready.recommendation.2000" для явного запроса на поддержку защиты программного обеспечения и "com.microsoft.playready.recommendation" для общих запросов (должен отвечать на поддержку защиты программного обеспечения, чтобы гарантировать обратную совместимость).

[out] pAnswer

Значение из перечисления MF_MEDIA_ENGINE_CANPLAY , указывающее, поддерживаются ли запрашиваемые возможности, поддерживаются ли они или не поддерживаются.

Возвращаемое значение

S_OK на успех.

Комментарии

Входной параметр типа должен иметь идентификаторы типов мультимедиа Content-Type и подтипов RFC 6381. В ней также должна присутствовать строка параметра CODECS RFC 2045. MPEG-4 — единственный контейнер, поддерживаемый для этого API. H.264 (avc1) и HEVC (hvc1, hev1) являются единственными видеокодеками, предоставляющими поддерживаемые ответы. Mpeg-4 (mp4a), MPEG-1 Layer 3 (mp3), Dolby Digital (ac-3) и Dolby Digital Plus (ec-3) являются единственными аудиокодеками, предоставляющими поддерживаемые ответы. Поддерживаемые строки:

video/mp4;codecs=”avc1,<audio codec>”

video/mp4;codecs=”hvc1, <audio codec>”

video/mp4;codecs=”hev1, <audio codec>”

Начиная с Windows 10 версии 1709, также поддерживаются следующие компоненты:

Video/mp4;codecs=”vp9,<audio codec>”

Video/mp4;codecs=”vp09,<audio codec>”

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

  1. Из каждой подсистемы в одном вызове можно использовать только один запрос имен компонентов и значений.
  2. Запрос подсистемы декодирования может выполняться без запроса Display 1, Display 2 или Output Protection
  3. Запрос подсистемы отображения 1 требует наличия запроса подсистемы декодирования
  4. Для запроса подсистемы отображения 2 требуется запрос подсистемы декодирования, но не запрос подсистемы Отображения 1.
  5. Запрос подсистемы защиты вывода (HDCP) может выполняться с запросом подсистемы decode, Display 1 или Display 2 или без нее с ограничениями 3 и 4.

Запрос General: Efficiency может быть объединён с любыми другими запросами подсистемы.

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

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

Элемент Подсистема видео Имя функции Значение функции Описание Обязательный для этой подсистемы
1а Декодирование decode-res-x Не отрицательное число в пикселях Поддерживает ли декодер видео это максимальное разрешение на оси X? Да
1б Декодирование decode-res-y Не отрицательное число в пикселях Поддерживает ли декодер видео это максимальное разрешение на оси Y? Да
1с Декодирование скорость декодирования Положительное число в килобитах в секунду (Кбит/с) Поддерживает ли декодер видео эту максимальную скорость? Да
1d Декодирование decode-fps 24, 25, 29,97, 30, 50, 59,94 или 60 Поддерживает ли декодированные видео это максимальное значение кадров в секунду (FPS)? Да
1e Декодирование decode-bpc (decode-bpp не рекомендуется) 0, 8, 10 или 12 Может ли декодер видео использовать эту глубину цвета для каждого пикселя? Да
1f Декодирование декодерное аппаратное ускорение** 1 или нет значения в качестве true Доступно ли аппаратное ускорение DXVA независимо от наличия декодера ОС? N
1 ГБ Декодирование декодерное программное ускорение ** 1 или нет значения в качестве true Способен ли имеющийся декодер ОС декодировать поток? N
1 ч Декодирование Декодер-программное обеспечение-требуется-оборудование** 1 или нет значения в качестве true Требуется ли для работы декодера ОС наличие аппаратного ускорения DXVA? Нет
2a Дисплей 1 display-res-x Не отрицательное число в пикселях Поддерживает ли хотя бы один пересекающийся** дисплей это разрешение на оси X? Да
2b Дисплей 1 display-res-y Не отрицательное число в пикселях Поддерживает ли хотя бы один пересекающийся*** дисплей такое разрешение на оси Y? Да
2c Дисплей 1 обновление экрана 24, 25, 29,97, 30, 50, 59,94 или 60 Настроена ли на дисплее (в соответствии с windows) по крайней мере запрошенная частота обновления? Нет
2D Дисплей 1 display-bpc (display-bpp не рекомендуется) 8 или 10 Все ли пересекающиеся дисплеи с необходимым разрешением ≥ реализуют хотя бы эту глубину цвета? N
3 Дисплей 2* hdr 1 (поддерживается) Поддерживает ли целевой объект отрисовку с высоким динамическим диапазоном (HDR) Да
4 Защита выходных данных Hdcp 0 (выключено), 1 (включено без ограничения HDCP 2.2, тип 1), 2 (включено с ограничением HDCP 2.2 Type 1 Все ли включенные пересечения отображают поддержку по крайней мере уровня защиты запроса? Да
5 Общие сведения: эффективность** настройка эффективности 0 (выкл. = без ограничений), 1 (on = ограничение разрешения при заряде батареи) Требуется ли пользователю время работы батареи, затраты на потоковую передачу и (или) скорость скачивания с учетом максимального разрешения?**** Да
6a Расшифровка тип шифрования "cenc" или "cbcs", с необязательным суффиксом "-clearlead". Поддерживается ли этот тип шифрования для расшифровки с помощью указанного кодека или key-system? Если значение не указано, используется значение по умолчанию cenc. Начиная со сборки Windows 22621, поддерживается суффикс -clearlead. При добавлении "-clearlead" к значению типа шифрования также запрашивается поддержка использования прозрачного содержимого в самом начале зашифрованного содержимого. Очистка содержимого в начале содержимого ускоряет представление первого кадра. Если к типу шифрования добавляется "-clearlead", проверяется номер версии запрошенного кодека. Кодеки AV1 и VP9 будут проверяться на наличие основной версии 2, а HEVC — для версии 2.0.53421 или более поздней. Нет
6b Расшифровка encryption-iv-size 8 или 16 Поддерживается ли этот размер вектора инициализации (IV) (в байтах) для расшифровки с помощью указанного кодека или key-system? Если значение не указано, используется значение по умолчанию 8. N

*Поддерживается только в Windows 10 версии 1607 и более поздних версиях ОС

**Поддерживается только в Windows 10 версии 1709 и более поздних версиях ОС

*** Алгоритм пересечения:

  1. Поиск всех дисплеев, где область видео-клиента пользовательского интерфейса приложения имеет пиксели.
  2. Найдите все графические адаптеры, которые находятся на дисплеях из шага 1. Для аппаратного запроса DRM этот набор адаптеров фильтруется только для адаптеров с поддержкой аппаратного DRM.
  3. Найдите все дисплеи, подключенные к графическим адаптерам из шага 2.

**** Поставщик содержимого может выбрать ограничение разрешения, используемое при включении этой политики. Рекомендуется использовать ограничение 1080p, но можно использовать 720p. Обратите внимание, что входные данные для этой политики поступают со страницы пользовательского интерфейса параметров видео, добавленной в Windows 10 версии 1709.

Пары для элементов 1a и 1b и 2a и 2b вычисляются как (запрошено x >= фактическое пересечение максимальное значение x) AND (запрошено y >= фактическое пересекающееся максимальное значение y) с изменением, которое книжное отображение нормализуется до альбомной ориентации путем замены x и y при необходимости.

Запрос HDCP (элемент 4) имеет ресурсоемкие затраты на первый вызов. Необходимо включить HDCP на запрошенном уровне, чтобы проверить, может ли запрошенный уровень соответствовать активной топологии дисплея. Результат Может быть из-за асинхронной оценки HDCP и занимает до нескольких секунд с HDCP 2.2, но запрос синхронный с минимальной блокировкой, требует, чтобы вызывающий объект использовал запрос несколько раз, пока результат не будет завершен как Вероятно или Не поддерживается. Изменение запрошенного уровня HDCP в запросе в состоянии Может, скорее всего, приведет к недопустимому ответу. Время ожидания может быть приблизительно 10 секунд.

Настоятельно рекомендуется не вызывать запрос hdcp чаще, чем один раз каждые 250 миллисекунд, из-за базовых затрат на вычисления. 500 миллисекундах является предпочтительным минимумом. Кэширование выполняется для минимизации этих затрат, но любые изменения топологии отображения при опросе делают кэширование недействительным.

В качестве сведений о реализации графические адаптеры могут использовать HDCP 2.2, если ее поддерживают все узлы, даже если ограничение HDCP 2.2 типа 1 не задано. Использование HDCP 2.2 может занять значительно больше времени, чем HDCP 1.x. Наблюдения на телевизорах текущего поколения показывают время до 8 секунд по сравнению с 1 секундой для устройств HDCP 1.x, включая ретрансляторы. Таким образом, первый hdcp=1 запрос при запуске приложения или после изменения топологии выходных данных требует ожидания до 8 секунд плюс маржа в этом худшем случае. Используя 10 секунд в качестве максимального ожидания, рекомендуется выполнять запрос запуска приложения, когда пользователь меньше всего должен выбрать название, например в начальном пользовательском интерфейсе. Если изменения топологии не происходят, все последующие запросы HDCP будут иметь подсекундное значение. Если содержимое имеет те же требования к выходным данным HDCP, что и запрос , кэширование приведет к повторному выполнению многосекундного ожидания при запуске воспроизведения.

При изменении топологии вывода телевизоры и мониторы с высоким разрешением часто занимают несколько секунд, чтобы стабилизировать рабочий стол. Изменение и особенно снижение уровня защиты выходных данных обычно приводит к сбою активного воспроизведения с аппаратным управлением цифровыми правами. Здесь реакция на ошибку MF_POLICY_UNSUPPORTED (0xC00D7159) должна быть скрытием ошибки от пользователя, повторным запросом и возобновлением с соответствующей версией содержимого для всех измененных возможностей. Фактически это действует как продление времени стабилизации "горячего отключения".

Запросы функций декодирования drm программного обеспечения потенциально неоднозначны по производительности, так как реализация H.264 позволяет выполнять декодирование программного обеспечения или разгрузку GPU с ускорением видео DirectX (DXVA). Однако H.264 DXVA очень распространен во всех конечных точках Windows.

Функциональное ограничение для запросов декодирования DRM программного обеспечения заключается в том, что decode-bpc не вычисляется. Windows не поддерживает 10-разрядное декодирование H.264, но запрос с decode-bpc=10 запросом будет выполнен успешно.

Результат запроса функции отражает максимальные теоретические возможности подсистем. Другие действия в GPU или различные состояния питания могут снизить фактические возможности.

Примеры запросов аппаратного управления цифровыми правами

Ниже показано наиболее распространенное использование 10-разрядного содержимого 10-разрядного динамического диапазона HEVC (SDR) с аппаратным DRM и ограничением HDCP 2.2 type 1.

IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”decode-res-x=3840,decode-res-y=2160,decode-bitrate=20000,decode-fps=30,decode-bpc=10,display-res-x=3840,display-res-y=2160,display-bpc=8,hdcp=2”’);

Где mp4a можно заменить mp3на , ac-3или ec-3. Скорость декодирования может быть скорректирована в соответствии с кодировкой поставщика содержимого. decode-fps может быть задано значение 60, а не 30, но может быть закрыто пропускной способностью аппаратного обработчика безопасности DRM. display-res-x Значения и display-res-y могут быть ниже полных 4K, если поставщик хочет отправить потоки 4K на 3200 x 1800, 3000 x 2000 или 2560 x 1440, например.

Так как результаты декодирования запроса не должны динамически изменяться, последовательный опрос для hdcp=2 while в может использовать более короткую форму в качестве небольшой оптимизации.

IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”hdcp=2”’);

Конечно, эта оптимизация не перехватит изменение динамического разрешения монитора, но такое изменение, скорее всего, помешает созданию HDCP в любом случае.

Ниже показано наиболее распространенное использование 4K 10-разрядного содержимого HEVC с высоким динамическим диапазоном (HDR) с аппаратным drm и ограничением HDCP 2.2 Type 1.

IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”hvc1,mp4a”;features=”decode-res-x=3840,decode-res-y=2160,decode-bitrate=20000,decode-fps=30,decode-bpc=10,display-res-x=3840,display-res-y=2160,display-bpc=8,hdr=1,hdcp=2”’);

Примечание. Для Windows 10 версии 1607 указывает на hdr=1 поддержку 10-разрядной версии MPO с DXGI_COLOR_SPACE_YCBCR_FULL_G22_LEFT_P2020, DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 или DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 либо что раздел реестра HighColor только для разработки имеется и задан: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor в качестве значения DWORD 1.

Ниже показано наиболее распространенное использование 8-разрядного SDR-содержимого H.264 1080p с аппаратным DRM и HDCP без ограничения 2.2 Type 1.

IsTypeSupported(‘com.microsoft.playready.recommendation.3000’,’video/mp4;codecs=”avc1,mp4a”;features=”decode-res-x=1920,decode-res-y=1080,decode-bitrate=10000,decode-fps=30,decode-bpc=8,display-res-x=1920,display-res-y=1080,display-bpc=8,hdcp=1”’);

Требования

   
Верхняя часть mfmediaengine.h

См. также раздел

MF_MEDIA_ENGINE_CANPLAY