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

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

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

Синтаксис

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

Параметры

[in] type

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

Реализация требует наличия идентификаторов мультимедиа и подтипов RFC 2045, например video/mp4, и RFC 6381 codec 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 на успех.

Замечания

Входной параметр типа должен иметь тип носителя rfC 6381 Content-Type и идентификаторы подтипов. Он также должен содержать строку параметра RFC 2045 Codecs. 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. Для запроса подсистемы Display 1 требуется наличие запроса подсистемы декодирования
  4. Для запроса подсистемы Display 2 требуется запрос подсистемы декодирования, но не требуется запрос подсистемы Display 1.
  5. Запрос подсистемы защиты выходных данных (HDCP) может выполняться с декодированием, отображением 1 или запросом подсистемы отображения 2 при условии ограничений #3 и #4.

Запрос General: Efficiency может сочетаться с другими запросами подсистемы.

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

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

Товар Подсистема видео Имя компонента Значение компонента Описание Обязательный для этой подсистемы
1a Расшифровывать декодирование-res-x Неотрицательное число в пикселях Поддерживает ли декодировщик видео это максимальное разрешение в оси X? У
1b Расшифровывать декодирование-res-y Неотрицательное число в пикселях Поддерживает ли видеодекодер это максимальное разрешение по оси Y? У
1c Расшифровывать битрейт декодирования Положительное число в килобитах в секунду (кб/с) Поддерживает ли декодировщик видео эту максимальную скорость? У
1 дн. Расшифровывать декодирование fps 24, 25, 29.97, 30, 50, 59.94 или 60 Поддерживает ли декодирование видео это максимальное значение кадров в секунду (FPS) ? У
1e Расшифровывать decode-bpc (decode-bpp устарело) 0, 8, 10 или 12 Может ли декодировщик видео использовать эту глубину цвета на пиксель? У
1f Расшифровывать декодер-аппаратное ускорение** 1 или отсутствие значения как true Доступно ли аппаратное ускорение DXVA независимо от наличия декодера ОС? Н
1g Расшифровывать декодер-программное ускорение ** 1 или отсутствие значения как true Может ли декодировщик ОС декодировать поток? Н
1 ч Расшифровывать декодер-software-requires-hardware-hardware** 1 или отсутствие значения как true Требуется ли для работы декодера ОС наличие аппаратного ускорения DXVA? Н
2a Отображение 1 разрешение-дисплея-по-х Неотрицательное число в пикселях Поддерживает ли по крайней мере одно пересекающееся** разрешение в оси X? У
2b Отображение 1 разрешение экрана по оси y Неотрицательное число в пикселях Поддерживает ли по крайней мере одно пересекающееся*** разрешение в оси Y? У
2c Отображение 1 частота обновления экрана 24, 25, 29.97, 30, 50, 59.94 или 60 Настроен ли дисплей (как показано в Windows) по крайней мере для запрошенной частоты обновления? Н
2д Отображение 1 display-bpc (display-bpp — не рекомендуется) 8 или 10 Отображаются ли все пересекающиеся дисплеи с требуемым разрешением ≥ по крайней мере, с этой глубиной цвета? Н
3 Отображение 2* hdr 1 (поддерживается) Поддерживает ли целевой объект отрисовку с высоким динамическим диапазоном (HDR) У
4 Защита выходных данных hdcp 0 (отключено), 1 (включено без ограничения HDCP 2.2 Тип 1), 2 (включено с ограничением HDCP 2.2 Тип 1) Поддерживают ли все пересекающиеся включенные экраны как минимум заданный уровень защиты? У
5 Общие: эффективность** настройка эффективности 0 (отключено = без ограничений), 1 (включено = ограничить разрешение при использовании батареи) Требуется ли пользователю время работы батареи, затраты на потоковую передачу и (или) скорость загрузки в выборе максимального разрешения?**** У
6a Расшифровка тип шифрования "cenc" или "cbcs", с необязательным суффиксом "-clearlead". Поддерживается ли этот тип шифрования для расшифровки с помощью указанного кодека или системы ключей? Если значение не указано, используется значение по умолчанию cenc. Начиная с Windows 11 сборки 22621 и Windows 10 сборки 19045.5796 или более поздней версии, поддерживается суффикс "-clearlead". При добавлении "-clearlead" к значению типа шифрования также запрашивается поддержка использования чистого содержимого в самом начале зашифрованного содержимого. Очистить содержимое в начале содержимого ускоряется до представления первого кадра. Если "-clearlead" добавляется в тип шифрования, будет проверен номер версии запрошенного кодека. Кодеки AV1 и VP9 будут проверяться на наличие основной версии 2, а HEVC будет проверяться для версии 2.0.53421 или более поздней. Н
6b Расшифровка encryption-iv-size 8 или 16 Поддерживается ли этот размер вектора инициализации (в байтах) для расшифровки с указанным кодеком или системой ключей? Если значение не указано, используется значение по умолчанию 8. Н

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры запросов аварийного восстановления оборудования

Ниже показано наиболее распространенное использование содержимого 4K 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 в то время как в может использоваться короче форма в качестве небольшой оптимизации

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

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

Ниже показано наиболее распространенное использование содержимого 4K 10-разрядной версии HEVC High Dynamic Range (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.

Ниже показано наиболее распространенное использование для 1080p 8-разрядного содержимого H.264 SDR с аппаратным DRM и HDCP без ограничения типа 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