ProtectionCapabilities.IsTypeSupported(String, String) Метод

Ссылка

Определение

Пространство имен:: Windows.Media.Protection

Важно!

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

Изменить

Запрашивает функции подсистем декодирования видео, отображения и защиты вывода для возможностей DRM.

Предупреждение

Этот метод рекомендуется использовать только с Ос Windows 10 версии 1607 или более поздней версии, даже если он присутствует в более ранних версиях Windows 10.

public:
 virtual ProtectionCapabilityResult IsTypeSupported(Platform::String ^ type, Platform::String ^ keySystem) = IsTypeSupported;

ProtectionCapabilityResult IsTypeSupported(winrt::hstring const& type, winrt::hstring const& keySystem);

public ProtectionCapabilityResult IsTypeSupported(string type, string keySystem);

function isTypeSupported(type, keySystem)

Public Function IsTypeSupported (type As String, keySystem As String) As ProtectionCapabilityResult

Параметры

type: String
Platform::String

winrt::hstring

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

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

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

keySystem: String
Platform::String

winrt::hstring

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

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

ProtectionCapabilityResult

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

Входной параметр типа должен иметь идентификаторы типов мультимедиа content-type и подтипов RFC 6381. В ней также должна присутствовать строка параметра кодеков 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>”

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

Из каждой подсистемы в одном вызове можно использовать только один запрос имен компонентов и значений.
Запрос подсистемы декодирования может выполняться без запроса Display 1, Display 2 или Output Protection.
Для запроса подсистемы отображения 1 требуется запрос подсистемы декодирования
Запрос подсистемы Display 2 требует запроса подсистемы декодирования, но не требует запроса подсистемы Display 1.
Запрос подсистемы защиты выходных данных (HDCP) может выполняться с запросом подсистемы Декодирование, Отображение 1 или Дисплей 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	Поддерживает ли декодированные видео это максимальное значение кадров в секунду?	Да
1e	Декодирование	decode-bpc (decode-bpp не рекомендуется)	0, 8, 10 или 12	Может ли декодер видео использовать эту глубину цвета для каждого пикселя?	Да
1f	Декодирование	декодерное аппаратное ускорение^**	1 или нет значения true	Доступно ли аппаратное ускорение DXVA независимо от наличия декодера ОС?	Нет
1 ГБ	Декодирование	декодерное программное ускорение ^**	1 или нет значения true	Способен ли имеющийся декодер ОС декодировать поток?	Нет
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, тип 1)	Поддерживают ли все включенные межсекционные дисплеи по крайней мере уровень защиты запросов?	Да
5	Общие: эффективность^**	настройка эффективности	0 (off = без ограничений), 1 (on = предельное разрешение при заряде батареи)	Требуется ли пользователю время работы от батареи, затраты на потоковую передачу и (или) скорость скачивания с наивысшим разрешением?^****	Да
6a	Расшифровка	тип шифрования	"cenc" или "cbcs"	Поддерживается ли этот тип шифрования для расшифровки с помощью указанного кодека или key-system? Если значение не указано, используется значение по умолчанию cenc.	Нет
6b	Расшифровка	encryption-iv-size	8 или 16	Поддерживается ли этот размер вектора инициализации (IV) (в байтах) для расшифровки с помощью указанного кодека или системы ключей? Если значение не указано, используется значение по умолчанию 8.	N

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

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

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

Поиск всех дисплеев, где область видеоконферентного клиента пользовательского интерфейса приложения содержит пиксели.
Найдите все графические адаптеры, которые находятся на дисплеях из шага 1. Для аппаратного запроса DRM этот набор адаптеров фильтруется только для адаптеров с аппаратной поддержкой DRM.
Найдите все дисплеи, подключенные к графическим адаптерам из шага 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 type 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 позволяет либо декодировать программное обеспечение, либо разгружать видео ускорение DirectX (DXVA) GPU. Однако H.264 DXVA очень распространен во всех конечных точках Windows.

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

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

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

Ниже показано наиболее распространенное использование 4K 10-разрядного содержимого HEVC Standard Dynamic Range (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 могут быть ниже полных 4 КБ, если поставщик хочет отправить потоки 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.

Примечание. Для 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-разрядного содержимого H.264 SDR 1080p с аппаратным 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”’);

Применяется к

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

ProtectionCapabilityResult

Share via