ProtectionCapabilities.IsTypeSupported(String, String) Método
Definição
Importante
Algumas informações se referem a produtos de pré-lançamento que podem ser substancialmente modificados antes do lançamento. A Microsoft não oferece garantias, expressas ou implícitas, das informações aqui fornecidas.
Consulta os recursos de decodificação de vídeo, exibição e subsistemas de proteção de saída para recursos drm.
Aviso
É recomendável que esse método seja usado apenas com o Windows 10, versão 1607 ou versão mais recente do sistema operacional, mesmo estando presente em versões mais antigas do 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
Parâmetros
- type
-
String
Platform::String
winrt::hstring
Cadeia de caracteres que identifica os recursos para os quais o suporte é consultado. Esse parâmetro aceita cadeias de caracteres tipo de conteúdo RFC 2045 para especificar identificadores de tipo de mídia e subtipo e identificadores de Codecs RFC 6381 para os codecs necessários. Essas cadeias de caracteres base são consistentes com as usadas no método HTML5 HTMLMediaElementcanPlayType. 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, <parameter>
é nomeado recurso.
A implementação requer o tipo de mídia RFC 2045 e os identificadores de subtipo, por exemplo, "video/mp4" e o parâmetro codec RFC 6381 codec=”<video codec>[,<audio codec>]”
estar sempre presentes para fornecer resultados de consulta válidos.
Observe que o tipo e o tipo de conteúdo de termos são conhecidos historicamente como tipo MIME.
- keySystem
-
String
Platform::String
winrt::hstring
Uma cadeia de caracteres que identifica o namespace do PlayReady para verificar a 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).
Retornos
Um valor que indica se os recursos consultados provavelmente têm suporte, possivelmente têm suporte ou não têm suporte.
Comentários
O tipo parâmetro de entrada 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 de parâmetro RFC 2045 Codecs 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 compatíveis. 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 compatíveis. 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:
- Somente uma consulta de nomes de recursos mais valores pode ser usada de cada um dos subsistemas em uma única chamada
- 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
- Uma consulta de subsistema de Exibição 1 requer que uma consulta de subsistema de decodificação esteja presente
- Uma consulta de subsistema Display 2 requer uma consulta de subsistema Decode, mas não requer uma consulta de subsistema Display 1.
- Uma consulta de subsistema de proteção de saída (HDCP) pode ser executada com ou sem uma consulta de subsistema Decode, Display 1 ou Display 2, sujeita às restrições nº 3 e nº 4.
A consulta General: Efficiency
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 Talvez resultado só seja permitido do subsistema de proteção de saída e apenas temporariamente. Este Talvez tenha precedência sobre um Provavelmente resultado do AND de todas as outras consultas de recursos, até que o Maybe resolva ao longo do tempo para Provavelmente ou Sem Suporte . O limite de tempo atual para Talvez para resolver é 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 | Decifrar | 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 | Decifrar | 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 | Decifrar | taxa de bits de decodificação | Número positivo em quilobits por segundo (Kbps) | O decodificador de vídeo dá suporte a essa taxa de bits máxima? | Y |
1d | Decifrar | 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 | Decifrar | 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 | Decifrar | 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 | Decifrar | decoder-software-acceleration ** | 1 ou nenhum valor como true | Um decodificador do sistema operacional está presente capaz de decodificar o fluxo? | N |
1h | Decifrar | decoder-software-requires-hardware** | 1 ou nenhum valor como true | A funcionalidade do decodificador do sistema operacional requer que a aceleração de hardware DXVA esteja presente? | N |
2a | Exibição 1 | display-res-x | Número não negativo em pixels | Pelo menos um** exibição de interseção dá suporte a essa resolução no eixo X? | Y |
2b | Exibição 1 | display-res-y | Número não negativo em pixels | Pelo menos uma exibição*** interseção dá suporte a essa resolução no eixo Y? | Y |
2c | Exibição 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 | Exibição 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 | Exibir 2* | Hdr | 1 (com suporte) | O destino dá suporte à renderização de ALTO Intervalo Dinâmico (HDR) | Y |
4 | Proteção de Saída | hdcp | 0 (desativado), 1 (ativado sem restrição HDCP 2.2 Tipo 1), 2 (com restrição HDCP 2.2 Tipo 1 | Todas as exibições habilitadas de interseção dão suporte pelo menos ao nível de proteção de solicitação? | Y |
5 | Geral:** de eficiência | definição de eficiência | 0 (desativado = sem restrição), 1 (em = resolução de limite quando na 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 à resolução mais alta?**** | Y |
6a | Desencriptação | tipo de criptografia | "cenc" ou "cbcs" | 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. | N |
6b | Desencriptação | encryption-iv-size | 8 ou 16 | Esse tamanho de Vetor de Inicialização (IV) (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 somente no Windows 10, versão 1607 e versões mais recentes do sistema operacional
** Com suporte somente no Windows 10, versão 1709 e versões mais recentes do sistema operacional
*** O algoritmo de interseção é:
- Localize todas as exibições em que a região do cliente de vídeo da interface do usuário do aplicativo tem pixels.
- 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.
- Localize todas as exibições 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 dessa política vem da página de interface do usuário de 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 computados como (solicitado x >= conjunto de interseção real máximo x) AND (solicitado y >= conjunto de intersecçã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 primeiro custo de 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 Talvez resultado 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 Maybe provavelmente resultará em uma resposta inválida. O Talvez 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 muda 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. As 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 consulta hdcp=1
na inicialização do aplicativo ou após uma alteração de topologia de saída requer espera de 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, a redução, no nível de proteção de saída geralmente fará com que a reprodução ativa com 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 recurso drm de software são potencialmente ambíguas sobre o desempenho, pois a implementação do H.264 permite decodificação de software ou descarregamento de GPU de DXVA (Aceleração de Vídeo DirectX). No entanto, o H.264 DXVA é 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
será bem-sucedida.
O resultado da consulta de recurso reflete as capacidades teóricas máximas dos subsistemas. Outra atividade na GPU ou em diferentes estados de energia pode reduzir a capacidade real.
Exemplos de consulta DRM de hardware
O seguinte mostra o uso mais comum para conteúdo de 4K de 10 bits hevc standard dynamic range (SDR) 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-3
ou 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
e display-res-y
valores poderão ser definidos abaixo do total de 4K se o provedor quiser enviar por push fluxos de 4K para exibições 3200 x 1800, 3000 x 2000 ou 2560 x 1440, por exemplo.
Como os resultados da consulta de decodificação não devem ser alterados dinamicamente, a sondagem sucessiva para hdcp=2
enquanto em Talvez possa usar uma forma mais curta 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 detectará uma alteração de resolução de monitor dinâmico, mas essa alteração provavelmente interromperia o estabelecimento do HDCP em andamento de qualquer maneira.
O exemplo a seguir mostra o uso mais comum para conteúdo hdr (alto intervalo dinâmico) hevc de 10 bits de 4K 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 o 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.
O seguinte mostra o uso mais comum para conteúdo H.264 SDR de 8 bits de 1080p com DRM de hardware e HDCP sem restrição do Tipo 1 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”’);