Compartir a través de


Método IMFExtendedDRMTypeSupport::IsTypeSupportedEx (mfmediaengine.h)

Consulta si se admite el tipo de contenido especificado para el sistema de claves especificado.

Sintaxis

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

Parámetros

[in] type

BSTR que identifica las características para las que se consulta la compatibilidad. Este parámetro acepta cadenas RFC 2045 Content-Type para especificar identificadores de tipo multimedia y subtipo, y identificadores de códecs RFC 6381 para los códecs necesarios. Estas cadenas base son coherentes con las usadas en el método HTML5 HTMLMediaElement canPlayType. RFC 2045 permite parámetros personalizados adicionales como modificadores en forma de ";<parameter>=<name>[=<value>] [,<name>[=<value>]". Los analizadores compatibles con RFC 2045 deben omitir estos parámetros si no se reconocen. Para las consultas de características, se denomina característica.

La implementación requiere que el tipo de medio RFC 2045 y los identificadores de subtipo, por ejemplo, "video/mp4" y el parámetro de códec RFC 6381 codec="<códec de vídeo[,<códec> de> audio]" estén siempre presentes para proporcionar resultados de consulta válidos.

Tenga en cuenta que los términos tipo y tipo son conocidos históricamente como tipo MIME.

[in] keySystem

BSTR que identifica el espacio de nombres de PlayReady con el que comprobar la consulta, especificando la protección de hardware o software. Use "com.microsoft.playready.recommendation.3000" para las consultas de hardware (PlayReady debe tener compatibilidad con la descarga de hardware), "com.microsoft.playready.recommendation.2000" para consultar explícitamente la compatibilidad con la protección de software y "com.microsoft.playready.recommendation" para las consultas generales (debe responder a la compatibilidad con la protección de software para garantizar la compatibilidad con versiones anteriores).

[out] pAnswer

Valor de la enumeración MF_MEDIA_ENGINE_CANPLAY que indica si es probable que se admitan las funcionalidades consultadas, que posiblemente sean compatibles o que no sean compatibles.

Valor devuelto

S_OK en caso de éxito.

Comentarios

El parámetro de entrada de tipo debe tener los identificadores de tipo de contenido y subtipo RFC 6381 presentes. También debe tener la cadena de parámetro RFC 2045 Codecs presente. MPEG-4 es el único contenedor admitido para esta API. H.264 (avc1) y HEVC (hvc1, hev1) son los únicos códecs de vídeo que proporcionan respuestas admitidas. MPEG-4 (mp4a), MPEG-1 Layer 3 (mp3), Dolby Digital (ac-3) y Dolby Digital Plus (ec-3) son los únicos códecs de audio que proporcionan respuestas admitidas. Las cadenas admitidas son:

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

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

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

A partir de la Windows 10, versión 1709, también se admiten lo siguiente:

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

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

La parte de características de la cadena de consulta se anexa a una de las cadenas anteriores mediante un delimitador de punto y coma. El controlador de gráficos subyacente y el hardware imponen restricciones sobre cómo se pueden consultar las características. Para los subsistemas de vídeo se aplican los siguientes requisitos:

  1. Solo se puede usar una consulta de nombres de características más valores de cada uno de los subsistemas en una sola llamada.
  2. Se puede realizar una consulta de subsistema de descodificación sin una consulta De display 1, Display 2 o Output Protection
  3. Una consulta del subsistema Display 1 requiere que esté presente una consulta del subsistema Decode.
  4. Una consulta del subsistema Display 2 requiere una consulta de subsistema de descodificación, pero no requiere una consulta del subsistema display 1.
  5. Una consulta del subsistema de protección de salida (HDCP) se puede realizar con o sin una consulta de subsistema Decode, Display 1 o Display 2, sujeto a restricciones #3 y #4.

La General: Efficiency consulta se puede combinar con cualquier otra consulta del subsistema.

El resultado devuelto es el AND lógico de todas las consultas de características individuales, con la siguiente aclaración: Un resultado tal vez solo se permite desde el subsistema de protección de salida y solo temporalmente. Esto puede tener prioridad sobre un resultado probablemente de and de todas las demás consultas de características, hasta que tal vez se resuelva con el tiempo en Probablemente o No compatible. El límite de tiempo actual para Tal vez resolverse es de 10 segundos.

En la tabla siguiente se enumeran las consultas de características individuales admitidas, organizadas por subsistema de vídeo:

Elemento Subsistema de vídeo Nombre de la característica Valor de característica Descripción Obligatorio para este subsistema
1a Descodificar decode-res-x Número no negativo en píxeles ¿El descodificador de vídeo admite esta resolución máxima en el eje X? Y
1b Descodificar decode-res-y Número no negativo en píxeles ¿El descodificador de vídeo admite esta resolución máxima en el eje Y? Y
1c Descodificar descodificación de velocidad de bits Número positivo en kilobits por segundo (Kbps) ¿El descodificador de vídeo admite esta velocidad de bits máxima? Y
1d Descodificar descodificar fps 24, 25, 29.97, 30, 50, 59.94 o 60 ¿El vídeo descodificado admite este valor máximo de fotogramas por segundo (FPS)? Y
1e Descodificar decode-bpc (decode-bpp está en desuso) 0, 8, 10 o 12 ¿El descodificador de vídeo puede consumir esta profundidad de color por píxel? Y
1f Descodificar decoder-hardware-acceleration** 1 o ningún valor como true ¿Está disponible la aceleración de hardware DXVA independientemente de que un descodificador del sistema operativo esté presente? N
1g Descodificar decoder-software-acceleration ** 1 o ningún valor como true ¿Existe un descodificador del sistema operativo capaz de descodificar la secuencia? N
1h Descodificar decoder-software-requires-hardware** 1 o ningún valor como true ¿La funcionalidad del descodificador del sistema operativo requiere que la aceleración de hardware DXVA esté presente? N
2a Mostrar 1 display-res-x Número no negativo en píxeles ¿Admite al menos una pantalla de intersección** esta resolución en el eje X? Y
2b Mostrar 1 display-res-y Número no negativo en píxeles ¿Admite al menos una pantalla de intersección*** esta resolución en el eje Y? Y
2c Mostrar 1 display-refreshrate 24, 25, 29.97, 30, 50, 59.94 o 60 ¿Se configura la pantalla (tal como se entiende en Windows) para al menos la frecuencia de actualización solicitada? N
2d Mostrar 1 display-bpc (display-bpp está en desuso) 8 o 10 ¿Todas las pantallas de intersección con ≥ resolución necesaria se dan cuenta al menos de esta profundidad de color? N
3 Mostrar 2* hdr 1 (admitido) ¿El destino admite la representación de alto rango dinámico (HDR) S
4 Protección de salida Hdcp 0 (desactivado), 1 (activado sin restricción de tipo 1 de HDCP 2.2), 2 (activado con restricción de tipo 1 de HDCP 2.2 ¿Todas las intersecciones habilitadas admiten al menos el nivel de protección de solicitudes? Y
5 General: Eficiencia** configuración de eficiencia 0 (off = sin restricción), 1 (on = limit resolution when on battery power) ¿Quiere el usuario la duración de la batería, la sobrecarga de streaming o la velocidad de descarga en preferencia a la resolución más alta?**** Y
6a Descifrado tipo de cifrado "cenc" o "cbcs", con sufijo opcional "-clearlead". ¿Se admite este tipo de cifrado para el descifrado con el códec o el sistema de claves especificados? Si el valor no está especificado, se usa el valor predeterminado de "cenc". A partir de la compilación 22621 de Windows, se admite el sufijo "-clearlead". Cuando se anexa "-clearlead" al valor de tipo de cifrado, también se solicita compatibilidad con el uso de contenido no cifrado al principio del contenido cifrado. Borrar el contenido al principio del contenido acelera el tiempo para presentar el primer fotograma. Si se agrega "-clearlead" al tipo de cifrado, se comprobará el número de versión del códec solicitado. Los códecs AV1 y VP9 se comprobarán para la versión 2 principal y HEVC se comprobará para v2.0.53421 o superior. N
6b Descifrado encryption-iv-size 8 o 16 ¿Se admite este tamaño de vector de inicialización (IV) (en bytes) para el descifrado con el códec o el sistema de claves especificados? Si el valor no está especificado, se usa el valor predeterminado de 8. N

*Solo se admite en Windows 10, versión 1607 y versiones más recientes del sistema operativo

**Solo se admite en Windows 10, versión 1709 y versiones más recientes del sistema operativo

*** El algoritmo de intersección es:

  1. Busque todas las pantallas en las que la región de cliente de vídeo de la interfaz de usuario de la aplicación tenga píxeles.
  2. Busque todos los adaptadores de gráficos que impulsan las pantallas del paso 1. Para una consulta DRM de hardware, este conjunto de adaptadores se filtra solo para aquellos adaptadores que tienen compatibilidad con DRM de hardware.
  3. Busque todas las pantallas conectadas a los adaptadores de gráficos del paso 2.

**** Depende del proveedor de contenido elegir el límite de resolución que se usará cuando esta directiva esté activada. Se recomienda un límite de 1080p, pero se puede usar 720p. Tenga en cuenta que la entrada de esta directiva procede de la página de interfaz de usuario configuración de vídeo agregada en Windows 10, versión 1709.

Los pares para los elementos 1a y 1b y 2a y 2b se calculan como (solicitado x = x real intersecting set maximum x) AND (requested y >= real intersecting set maximum y), con una modificación que la visualización vertical se normaliza en horizontal intercambiando x >e y según sea necesario.

La consulta hdcp (elemento 4) tiene un costo de primera invocación computacionalmente costoso. HDCP debe estar activado en el nivel solicitado para sondear si el nivel solicitado se puede cumplir con la topología de visualización activa. El resultado tal vez debido a que HDCP se evalúa de forma asincrónica y tarda hasta varios segundos con HDCP 2.2, pero la consulta es sincrónica con bloqueo mínimo, requiere que el autor de la llamada use repetidamente la consulta hasta que el resultado finalice como Probablemente o No compatible. Cambiar el nivel de HDCP solicitado en una consulta mientras sigue en el estado Tal vez probablemente dará lugar a una respuesta no válida. El tiempo de espera tal vez es de aproximadamente 10 segundos.

Se recomienda encarecidamente no invocar una consulta hdcp con más frecuencia que una vez cada 250 milisegundos, debido al costo computacional subyacente. 500 milisegundos es el mínimo preferido. El almacenamiento en caché se realiza para minimizar este costo, pero cualquier cambio de topología de visualización al sondear invalida el almacenamiento en caché.

Como detalle de implementación, los adaptadores de gráficos pueden optar por usar HDCP 2.2 si todos los nodos lo admiten, aunque no se haya establecido la restricción HDCP 2.2 Type 1. HDCP 2.2 puede tardar significativamente más que HDCP 1.x en interactuar. Las observaciones sobre los televisores de generación actual muestran tiempos de hasta 8 segundos, frente a aproximadamente 1 segundo para dispositivos HDCP 1.x, incluidos los repetidores. Por lo tanto, una primera hdcp=1 consulta en el inicio de la aplicación o después de un cambio de topología de salida requiere esperar hasta 8 segundos más margen para este peor caso. Con 10 segundos como espera máxima, se recomienda realizar la consulta de inicio de la aplicación cuando se espera que el usuario elija un título, por ejemplo, en una interfaz de usuario inicial. Si no se producen cambios en la topología, todas las consultas hdcp adicionales serán de segundo. Si el contenido tiene el mismo requisito de salida de HDCP que la consulta , el almacenamiento en caché eljminará la espera de varios segundos que se produce de nuevo al iniciar la reproducción.

En un cambio de topología de salida, los televisores y monitores de alta resolución suelen tardar varios segundos en estabilizar el escritorio. Un cambio, y especialmente la reducción, en el nivel de protección de salida normalmente provocará un error en la reproducción activa con DRM de hardware por diseño. Aquí, una reacción a un error de MF_POLICY_UNSUPPORTED (0xC00D7159) debe ser ocultar el error del usuario, volver a consultar y reanudar con una versión de contenido adecuada para las funcionalidades modificadas. De hecho, esto actúa como una extensión del tiempo de estabilización de "hotplug".

Las consultas de características de descodificación drm de software son potencialmente ambiguas en cuanto al rendimiento, ya que la implementación de H.264 permite la descarga de GPU de aceleración de vídeo directX (DXVA). Sin embargo, H.264 DXVA es muy común en todos los puntos de conexión de Windows.

Una limitación funcional con las consultas de descodificación drm de software es que no se evalúa el descodificador bpc. Windows no admite la descodificación de 10 bits H.264, pero una consulta con decode-bpc=10 se realizará correctamente.

El resultado de la consulta de características refleja las capacidades teóricas máximas de los subsistemas. Otra actividad en la GPU o distintos estados de energía puede reducir la capacidad real.

Ejemplos de consultas DRM de hardware

A continuación se muestra el uso más común para el contenido de intervalo dinámico estándar (SDR) de 4K de 10 bits con DRM de hardware y restricción de tipo 1 de HDCP 2.2:

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”’);

Donde mp4a se puede reemplazar por mp3, ac-3o ec-3. La velocidad de bits de descodificación se puede ajustar según la codificación del proveedor de contenido. decode-fps puede establecerse en 60 en lugar de 30, pero puede estar controlada por la capacidad de rendimiento del procesador de seguridad DRM de hardware. display-res-x y display-res-y los valores se pueden establecer inferiores a 4K completos si el proveedor desea insertar secuencias de 4K en 3200 x 1800, 3000 x 2000 o 2560 x 1440 pantallas, por ejemplo.

Como no se espera que los resultados de la consulta descodificación cambien dinámicamente, el sondeo sucesivo durante hdcp=2 el tiempo que en Tal vez puede usar un formulario más corto como una optimización pequeña.

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

Por supuesto, esta optimización no detectará un cambio de resolución de supervisión dinámica, pero es probable que este cambio interrumpa el establecimiento de HDCP en curso de todos modos.

A continuación se muestra el uso más común para el contenido de rango dinámico alto (HDR) de 4K de 10 bits con DRM de hardware y restricción 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”’);

Nota: Para Windows 10, versión 1607, hdr=1 indica que la compatibilidad de MPO de 10 bits con DXGI_COLOR_SPACE_YCBCR_FULL_G22_LEFT_P2020 o DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 o DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 está presente, o que la clave del Registro HighColor solo de desarrollo está presente y se ha establecido: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor como valor DWORD de 1.

A continuación se muestra el uso más común de contenido H.264 SDR de 1080p con DRM de hardware y HDCP sin restricción de tipo 1 de 2.2:

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”’);

Requisitos

   
Encabezado mfmediaengine.h

Consulte también

MF_MEDIA_ENGINE_CANPLAY