Compartilhar via

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

  • Artigo

Consulta se o tipo de conteúdo especificado tem suporte para o sistema de chaves especificado.

Sintaxe

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

Parâmetros

[in] type

Um BSTR que identifica os recursos para os quais o suporte é consultado. Esse parâmetro aceita cadeias de caracteres de Tipo de Conteúdo RFC 2045 para especificar identificadores de tipo de mídia e subtipo e identificadores codecs RFC 6381 para os codecs necessários. Essas cadeias de caracteres base são consistentes com as usadas no método HTML5 HTMLMediaElement canPlayType. O RFC 2045 permite parâmetros personalizados adicionais como modificadores na forma de ";<parameter>=<name>[=<value>] [,<name>[=<value>]". Os analisadores compatíveis com RFC 2045 devem ignorar esses parâmetros se não forem reconhecidos. Para as consultas de recurso, é chamado de recurso.

A implementação requer que o tipo de mídia RFC 2045 e os identificadores de subtipo, por exemplo , "video/mp4" e o parâmetro codec codec="<video codec>[,<audio codec>]" da RFC 6381 estejam sempre presentes para fornecer resultados de consulta válidos.

Observe que os termos tipo de conteúdo e tipo são conhecidos historicamente como tipo MIME.

[in] keySystem

Um BSTR que identifica o namespace do PlayReady para marcar consulta, especificando a proteção de hardware ou software. Use "com.microsoft.playready.recommendation.3000" para consultas de hardware (o PlayReady deve ter suporte para descarregamento de hardware), "com.microsoft.playready.recommendation.2000" para consultar explicitamente o suporte à proteção de software e "com.microsoft.playready.recommendation" para consultas gerais (deve responder pelo suporte à proteção de software para garantir a compatibilidade com versões anteriores).

[out] pAnswer

Um valor da enumeração MF_MEDIA_ENGINE_CANPLAY indicando se os recursos consultados provavelmente têm suporte, possivelmente têm suporte ou não têm suporte.

Retornar valor

S_OK sobre o sucesso.

Comentários

O parâmetro de entrada de tipo deve ter o tipo de mídia Tipo de Conteúdo RFC 6381 e identificadores de subtipo presentes. Ele também deve ter a cadeia de caracteres do parâmetro Codecs RFC 2045 presente. MPEG-4 é o único contêiner com suporte para essa API. H.264 (avc1) e HEVC (hvc1, hev1) são os únicos codecs de vídeo que fornecem respostas com suporte. MPEG-4 (mp4a), MPEG-1 Camada 3 (mp3), Dolby Digital (ac-3) e Dolby Digital Plus (ec-3) são os únicos codecs de áudio que fornecem respostas com suporte. As cadeias de caracteres com suporte são:

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

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

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

A partir do Windows 10, versão 1709, também há suporte para o seguinte:

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

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

A parte dos recursos da cadeia de caracteres de consulta é acrescentada a uma das cadeias de caracteres acima usando um delimitador de ponto e vírgula. O driver gráfico subjacente e o hardware impõem restrições sobre como os recursos podem ser consultados. Para os subsistemas de vídeo, os seguintes requisitos se aplicam:

  1. Somente uma consulta de nomes de recursos mais valores pode ser usada de cada um dos subsistemas em uma única chamada
  2. Uma consulta de subsistema de decodificação pode ser executada sem uma consulta de Exibição 1, Exibição 2 ou Proteção de Saída
  3. Uma consulta de subsistema Decodificar 1 requer que uma consulta de subsistema de decodificação esteja presente
  4. Uma consulta de subsistema Decodificar 2 requer uma consulta de subsistema de decodificação, mas não requer uma consulta de subsistema Decodificar.
  5. Uma consulta de subsistema de proteção de saída (HDCP) pode ser executada com ou sem uma consulta de subsistema Decodificar, Exibir 1 ou Exibir 2, sujeita às restrições nº 3 e nº 4.

A General: Efficiency consulta pode ser combinada com qualquer outra consulta de subsistema.

O resultado retornado é o AND lógico de todas as consultas de recursos individuais, com o seguinte esclarecimento: Um resultado Talvez só é permitido do subsistema de proteção de saída e apenas temporariamente. Isso talvez tenha precedência sobre um resultado Provavelmente do AND de todas as outras consultas de recursos, até que o Talvez resolva ao longo do tempo para Provavelmente ou Não Suportado. O limite de tempo atual para Talvez resolve é de 10 segundos.

A tabela a seguir lista as consultas de recursos individuais com suporte, organizadas pelo subsistema de vídeo:

Item Subsistema de Vídeo Nome do recurso Valor do recurso Descrição Obrigatório para esse subsistema
1a Decodificar decode-res-x Número não negativo em pixels O decodificador de vídeo dá suporte a essa resolução máxima no eixo X? Y
1b Decodificar decode-res-y Número não negativo em pixels O decodificador de vídeo dá suporte a essa resolução máxima no eixo Y? Y
1c Decodificar decode-bitrate Número positivo em quilobits por segundo (Kbps) O decodificador de vídeo dá suporte a essa taxa máxima de bits? Y
1d Decodificar decode-fps 24, 25, 29,97, 30, 50, 59,94 ou 60 O vídeo decodificado dá suporte a esse valor de FPS (quadros máximos por segundo)? Y
1e Decodificar decode-bpc (decode-bpp foi preterido) 0, 8, 10 ou 12 O decodificador de vídeo pode consumir essa profundidade de cor por pixel? Y
1f Decodificar decoder-hardware-acceleration** 1 ou nenhum valor como true A aceleração de hardware DXVA está disponível independentemente de um decodificador do sistema operacional estar presente? N
1g Decodificar decoder-software-acceleration ** 1 ou nenhum valor como true Um decodificador do sistema operacional está presente capaz de decodificar o fluxo? N
1h Decodificar decoder-software-requires-hardware** 1 ou nenhum valor como true A funcionalidade do decodificador do sistema operacional exige que a aceleração de hardware DXVA esteja presente? N
2a Tela 1 display-res-x Número não negativo em pixels Pelo menos uma exibição de interseção** dá suporte a essa resolução no eixo X? Y
2b Tela 1 display-res-y Número não negativo em pixels Pelo menos uma exibição de interseção*** dá suporte a essa resolução no eixo Y? Y
2c Tela 1 taxa de atualização de exibição 24, 25, 29,97, 30, 50, 59,94 ou 60 A exibição está configurada (conforme entendido pelo Windows) para pelo menos a taxa de atualização solicitada? N
2d Tela 1 display-bpc (display-bpp foi preterido) 8 ou 10 Todas as exibições de interseção com ≥ resolução necessária percebem pelo menos essa profundidade de cor? N
3 Tela 2* Hdr 1 (com suporte) O destino dá suporte à renderização de HDR (Alto Alcance Dinâmico) S
4 Proteção de Saída Hdcp 0 (desativado), 1 (ativado sem restrição HDCP 2.2 Tipo 1), 2 (ativado com restrição HDCP 2.2 Tipo 1 Todas as exibições habilitadas para intersecção dão suporte pelo menos ao nível de proteção de solicitação? Y
5 Geral: Eficiência** configuração de eficiência 0 (desativado = sem restrição), 1 (em = resolução de limite quando houver energia da bateria) O usuário deseja a duração da bateria, a sobrecarga de streaming e/ou a velocidade de download em preferência para a resolução mais alta?**** Y
6a Descriptografia tipo de criptografia "cenc" ou "cbcs", com sufixo opcional "-clearlead". Esse tipo de criptografia tem suporte para descriptografia com o codec/key-system especificado? Se o valor não for especificado, o valor padrão de "cenc" será usado. A partir do Windows Build 22621, há suporte para o sufixo "-clearlead". Quando "-clearlead" é acrescentado ao valor do tipo de criptografia, o suporte para usar conteúdo claro no início do conteúdo criptografado também é solicitado. Limpar o conteúdo no início do conteúdo acelera o tempo para apresentar o primeiro quadro. Se "-clearlead" for adicionado ao tipo de criptografia, o número de versão do codec solicitado será verificado. Os codecs AV1 e VP9 serão verificados para a versão principal 2 e HEVC será verificado para v2.0.53421 ou superior. N
6b Descriptografia encryption-iv-size 8 ou 16 Esse tamanho do IV (Vetor de Inicialização) (em bytes) tem suporte para descriptografia com o codec/key-system especificado? Se o valor não for especificado, o valor padrão de 8 será usado. N

*Com suporte apenas em Windows 10, versão 1607 e versões mais recentes do sistema operacional

**Com suporte apenas em Windows 10, versão 1709 e versões mais recentes do sistema operacional

*** O algoritmo de interseção é:

  1. Encontre todas as exibições em que a região do cliente de vídeo da interface do usuário do aplicativo tem pixels.
  2. Encontre todos os adaptadores gráficos que conduzem as exibições da etapa 1. Para uma consulta DRM de hardware, esse conjunto de adaptadores é filtrado apenas para os adaptadores que têm suporte para DRM de hardware.
  3. Localize todas as telas conectadas aos adaptadores gráficos da etapa 2.

**** Cabe ao provedor de conteúdo escolher o limite de resolução a ser usado quando essa política estiver ativada. Um limite de 1080p é recomendado, mas 720p pode ser usado. Observe que a entrada para essa política vem da página interface do usuário configurações de vídeo adicionada no Windows 10, versão 1709.

Os pares dos itens 1a e 1b e 2a e 2b são calculados como (solicitado x >= conjunto de interseção real máximo x) AND (solicitado y >= conjunto de interseção real máximo y), com uma modificação de que a exibição retrato é normalizada para paisagem trocando x e y conforme necessário.

A consulta hdcp (item 4) tem um custo de primeira invocação computacionalmente caro. O HDCP deve ser ativado no nível solicitado para investigar se o nível solicitado pode ser atendido com a topologia de exibição ativa. O resultado de Maybe devido ao HDCP ser avaliado de forma assíncrona e levar até vários segundos com o HDCP 2.2, mas a consulta ser síncrona com o bloqueio mínimo, requer que o chamador use a consulta repetidamente até que o resultado seja finalizado como Provavelmente ou Sem Suporte. Alterar o nível de HDCP solicitado em uma consulta enquanto ainda estiver no estado Talvez provavelmente resultará em uma resposta inválida. Talvez o tempo limite seja de aproximadamente 10 segundos.

É altamente recomendável não invocar uma consulta hdcp com mais frequência do que uma vez a cada 250 milissegundos, devido ao custo computacional subjacente. 500 milissegundos é o mínimo preferencial. O cache é executado para minimizar esse custo, mas qualquer topologia de exibição é alterada ao sondar invalidar o cache.

Como um detalhe de implementação, os adaptadores gráficos poderão optar por usar o HDCP 2.2 se todos os nós deem suporte a ele, mesmo que a restrição HDCP 2.2 Tipo 1 não tenha sido definida. O HDCP 2.2 pode levar significativamente mais tempo do que o HDCP 1.x para ser ativado. Observações em TVs de geração atual mostram tempos de até 8 segundos, contra cerca de 1 segundo para dispositivos HDCP 1.x, incluindo repetidores. Portanto, uma primeira hdcp=1 consulta na inicialização do aplicativo ou após uma alteração de topologia de saída requer aguardar até 8 segundos mais margem para esse pior caso. Usando 10 segundos como uma espera máxima, é recomendável executar a consulta de inicialização do aplicativo quando o usuário é menos esperado para escolher um título, por exemplo, em uma interface do usuário inicial. Se nenhuma alteração de topologia ocorrer, todas as consultas hdcp adicionais serão sub-segundos. Se o conteúdo tiver o mesmo requisito de saída HDCP que a consulta , o cache eljminará a espera de vários segundos ocorrendo novamente no início da reprodução.

Em uma alteração de topologia de saída, as TVs e monitores de alta resolução geralmente levam vários segundos para estabilizar a área de trabalho. Uma alteração e, especialmente, uma redução, no nível de proteção de saída geralmente fará com que a reprodução ativa com o DRM de hardware falhe por design. Aqui, uma reação a um erro de MF_POLICY_UNSUPPORTED (0xC00D7159) deve ser ocultar o erro do usuário, requery e retomar com uma versão de conteúdo apropriada para quaisquer recursos alterados. Efetivamente, isso atua como uma extensão do tempo de estabilização "hotplug".

As consultas de recursos de decodificação de DRM de software são potencialmente ambíguas no desempenho, pois a implementação do H.264 permite a decodificação de software ou o descarregamento de GPU DXVA (Aceleração de Vídeo DirectX). No entanto, a DXVA H.264 é muito comum em todos os pontos de extremidade do Windows.

Uma limitação funcional com consultas de decodificação drm de software é que o decode-bpc não é avaliado. O Windows não dá suporte à decodificação H.264 de 10 bits, mas uma consulta com decode-bpc=10 terá êxito.

O resultado da consulta de recurso reflete as capacidades teóricas máximas dos subsistemas. Outras atividades na GPU ou em diferentes estados de energia podem reduzir a capacidade real.

Exemplos de consulta DRM de hardware

Veja a seguir o uso mais comum para conteúdo de SDR (Intervalo Dinâmico Padrão) HEVC de 4K de 10 bits com drm de hardware e restrição hdcp 2.2 tipo 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”’);

Onde mp4a pode ser substituído por mp3, ac-3ou ec-3. A taxa de bits de decodificação pode ser ajustada de acordo com a codificação do provedor de conteúdo. decode-fps pode ser definido como 60 em vez de 30, mas pode ser fechado pela capacidade de taxa de transferência do processador de segurança DRM de hardware. display-res-x Os valores e display-res-y poderão ser definidos abaixo do total de 4K se o provedor quiser efetuar push de fluxos 4K para exibições de 3200 x 1800, 3000 x 2000 ou 2560 x 1440, por exemplo.

Como não se espera que os resultados da consulta decodificação sejam alterados dinamicamente, a sondagem sucessiva por hdcp=2 enquanto em Talvez possa usar um formulário mais curto como uma otimização pequena

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

É claro que essa otimização não capturará uma alteração de resolução de monitor dinâmico, mas essa alteração provavelmente interromperá o estabelecimento do HDCP em andamento de qualquer maneira.

Veja a seguir o uso mais comum para conteúdo HDR (High Dynamic Range) HEVC de 4K de 10 bits com drm de hardware e restrição hdcp 2.2 tipo 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”’);

Observação: para Windows 10, versão 1607, hdr=1 indica que o suporte a MPO de 10 bits com DXGI_COLOR_SPACE_YCBCR_FULL_G22_LEFT_P2020 ou DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 ou DXGI_COLOR_SPACE_RGB_FULL_G2084_NONE_P2020 está presente ou que a chave do Registro HighColor somente para desenvolvimento está presente e foi definida: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor como um valor DWORD de 1.

Veja a seguir o uso mais comum para conteúdo H.264 SDR de 8 bits de 1080p com DRM de hardware e HDCP sem restrição 2.2 Tipo 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”’);

Requisitos

   
Cabeçalho mfmediaengine.h

Confira também

MF_MEDIA_ENGINE_CANPLAY