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

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 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 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, <o parâmetro> é chamado de recurso.

A implementação requer o tipo de mídia RFC 2045 e os identificadores de subtipo, por exemplo, "vídeo/mp4" e codec codec="<codec> de vídeo[,<codec> de áudio]" do RFC 6381 para estar sempre presente 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.

[in] keySystem

Um BSTR 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).

[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.

Valor de retorno

S_OK com sucesso.

Observações

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 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:

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 de Exibição 1 requer que uma consulta de subsistema de decodificação esteja presente
4. Uma consulta de subsistema Display 2 requer uma consulta de subsistema Decode, mas não requer uma consulta de subsistema Display 1.
5. 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 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 recurso, até que o Maybe resolva ao longo do tempo para Provavelmente ou Não Suportado. O limite de tempo atual para Talvez resolver é de 10 segundos.

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

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

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

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

1. Localize 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 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 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 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 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 Maybe 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 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 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, 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-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 e display-res-y os valores poderão ser definidos abaixo do total de 4K se o provedor quiser enviar fluxos 4K por push 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 são esperados para mudar dinamicamente, a sondagem sucessiva por hdcp=2 enquanto em Talvez pode 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”’);

Requisitos

Consulte também

MF_MEDIA_ENGINE_CANPLAY