Metodo IMFExtendedDRMTypeSupport::IsTypeSupportedEx (mfmediaengine.h)

Esegue una query per verificare se il tipo di contenuto specificato è supportato per il sistema di chiavi specificato.

Sintassi

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

Parametri

[in] type

BSTR che identifica le funzionalità per cui viene eseguito il supporto. Questo parametro accetta stringhe RFC 2045 Content-Type per specificare identificatori di tipo multimediale e sottotipo e identificatori codec RFC 6381 per i codec necessari. Queste stringhe di base sono coerenti con quelle usate nel metodo HTML5 HTMLMediaElement canPlayType. RFC 2045 consente parametri personalizzati aggiuntivi come modificatori sotto forma di ";<parameter>=<name>[=<value>] [,<name>[=<value>]". I parser conformi a RFC 2045 devono ignorare questi parametri, se non riconosciuti. Per le query di funzionalità, è denominata funzionalità.

L'implementazione richiede che il tipo di supporto RFC 2045 e gli identificatori di sottotipo, ad esempio "video/mp4" e codec codec="<codec> video[,<codec audio>]" siano sempre presenti per fornire risultati di query validi.

Si noti che i termini tipo di contenuto e tipo sono noti storicamente come tipo MIME.

[in] keySystem

BSTR che identifica lo spazio dei nomi PlayReady per controllare la query su , specificando la protezione hardware o software. Usare "com.microsoft.playready.recommendation.3000" per le query hardware (PlayReady deve disporre del supporto per l'offload hardware), "com.microsoft.playready.recommendation.2000" per eseguire query in modo esplicito per il supporto della protezione software e "com.microsoft.playready.recommendation" per le query generali (deve rispondere al supporto della protezione software per garantire la compatibilità con le versioni precedenti).

[out] pAnswer

Valore dell'enumerazione MF_MEDIA_ENGINE_CANPLAY che indica se è probabile che le funzionalità sottoposte a query siano supportate, siano eventualmente supportate o non siano supportate.

Valore restituito

S_OK al successo.

Commenti

Il parametro di input del tipo deve avere il tipo di supporto RFC 6381 Content-Type e gli identificatori di sottotipo presenti. Deve essere presente anche la stringa del parametro CodecS RFC 2045. MPEG-4 è l'unico contenitore supportato per questa API. H.264 (avc1) e HEVC (hvc1, hev1) sono gli unici codec video che forniscono risposte supportate. MPEG-4 (mp4a), MPEG-1 Layer 3 (mp3), Dolby Digital (ac-3) e Dolby Digital Plus (ec-3) sono gli unici codec audio che forniscono risposte supportate. Le stringhe supportate sono:

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

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

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

A partire dalla Windows 10, versione 1709, sono supportati anche gli elementi seguenti:

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

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

La parte delle funzionalità della stringa di query viene aggiunta a una delle stringhe precedenti usando un delimitatore punto e virgola. Il driver grafico sottostante e l'hardware impongono vincoli sulla modalità di query delle funzionalità. Per i sottosistemi video si applicano i requisiti seguenti:

1. È possibile usare una sola query di nomi di funzionalità e valori da ognuno dei sottosistemi in una singola chiamata
2. È possibile eseguire una query del sottosistema Decode senza una query Display 1, Display 2 o Output Protection
3. Per una query del sottosistema Display 1 è necessario che sia presente una query del sottosistema Decode
4. Una query del sottosistema Display 2 richiede una query del sottosistema Decode, ma non richiede una query del sottosistema Display 1.
5. È possibile eseguire una query del sottosistema di protezione di output (HDCP) con o senza una query decode, display 1 o display 2 sottosistema, soggetta a vincoli n. 3 e 4.

La General: Efficiency query può essere combinata con qualsiasi altra query del sottosistema.

Il risultato restituito è l'AND logico di tutte le singole query di funzionalità, con il chiarimento seguente: un risultato forse è consentito solo dal sottosistema di protezione dell'output e solo temporaneamente. Questo potrebbe avere la precedenza su un risultato probabilmente risultante dall'AND di tutte le altre query di funzionalità, fino a quando forse non viene risolto nel tempo in Probabilmente o Non supportato. Il limite di tempo corrente per La risoluzione potrebbe essere di 10 secondi.

La tabella seguente elenca le singole query di funzionalità supportate, organizzate per sottosistema video:

^*Supportato solo in Windows 10, versione 1607 e versioni più recenti del sistema operativo

^**Supportato solo in Windows 10, versione 1709 e versioni più recenti del sistema operativo

^*** L'algoritmo di intersezione è:

1. Trovare tutti i display in cui l'area client dell'interfaccia utente dell'applicazione ha pixel.
2. Trovare tutte le schede grafiche che guidano gli schermi dal passaggio 1. Per una query DRM hardware, questo set di adattatori viene filtrato solo per tali adattatori con supporto DRM hardware.
3. Trovare tutte le visualizzazioni connesse alle schede grafiche dal passaggio 2.

^**** Il provider di contenuto deve scegliere il limite di risoluzione da usare quando questo criterio è attivo. È consigliabile usare un limite di 1080p, ma è possibile usare 720p. Si noti che l'input per questo criterio proviene dalla pagina interfaccia utente Impostazioni video aggiunta in Windows 10 versione 1709.

Le coppie per gli elementi 1a e 1a e 2a e 2b vengono calcolate come (richieste x >= effettive intersecting set massimo x) AND (richiesto y >= effettivo intersecting set massimo y), con una modifica che la visualizzazione verticale viene normalizzata in orizzontale scambiando x e y in base alle esigenze.

La query hdcp (elemento 4) ha un costo di chiamata di calcolo costoso. HDCP deve essere attivato a livello richiesto per verificare se il livello richiesto può essere soddisfatto con la topologia di visualizzazione attiva. Il risultato forse dovuto a HDCP valutato in modo asincrono e richiede fino a diversi secondi con HDCP 2.2, ma la query in fase sincrona con il blocco minimo, richiede che il chiamante usi ripetutamente la query fino al termine del risultato come probabilmente o non supportato. La modifica del livello HDCP richiesto in una query durante lo stato Forse potrebbe causare una risposta non valida. Il timeout forse è di circa 10 secondi.

È consigliabile non richiamare una query hdcp più spesso di una volta ogni 250 millisecondi, a causa dei costi di calcolo sottostanti. 500 millisecondi è il minimo preferito. La memorizzazione nella cache viene eseguita per ridurre al minimo questo costo, ma qualsiasi modifica della topologia di visualizzazione durante il polling invalida la memorizzazione nella cache.

Come dettaglio dell'implementazione, le schede grafiche possono scegliere di usare HDCP 2.2 se tutti i nodi lo supportano, anche se la restrizione del tipo 2.2 HDCP 2.2 non è stata impostata. HDCP 2.2 può richiedere molto più tempo di HDCP 1.x per interagire. Le osservazioni sulle tv di generazione corrente mostrano tempi fino a 8 secondi, rispetto a circa 1 secondo per i dispositivi HDCP 1.x, inclusi i ripetitori. Pertanto, una prima hdcp=1 query sull'avvio dell'applicazione o dopo una modifica della topologia di output richiede l'attesa fino a 8 secondi più margine per questo caso peggiore. Usando 10 secondi come attesa massima, è consigliabile eseguire la query di avvio dell'applicazione quando l'utente è meno previsto per selezionare un titolo, ad esempio in un'interfaccia utente iniziale. Se non si verificano modifiche alla topologia, tutte le query hdcp aggiuntive saranno secondarie. Se il contenuto ha lo stesso requisito di output HDCP della query , la memorizzazione nella cache eljmina la attesa multi-secondo che si verifica di nuovo all'avvio della riproduzione.

In una modifica della topologia di output, le tv a risoluzione elevata e i monitoraggi richiedono spesso diversi secondi per stabilizzare il desktop. Una modifica e soprattutto una riduzione del livello di protezione dell'output genererà la riproduzione attiva con DRM hardware non riuscita in base alla progettazione. In questo caso, una reazione a un errore di MF_POLICY_UNSUPPORTED (0xC00D7159 ) deve essere quello di nascondere l'errore dall'utente, riquery e riprendere con una versione del contenuto appropriata per le funzionalità modificate. In effetti, questo funge da estensione del tempo di stabilizzazione "hotplug".

Le query di decodifica delle funzionalità DRM software sono potenzialmente ambigue sulle prestazioni perché l'implementazione H.264 consente l'offload della GPU DXVA (Software Software Decoding o DirectX Video Acceleration). Tuttavia, H.264 DXVA è molto comune in tutti gli endpoint di Windows.

Una limitazione funzionale con le query di decodifica DRM software è che il decodifica-bpc non viene valutato. Windows non supporta la decodifica H.264 a 10 bit, ma una query con decode-bpc=10 avrà esito positivo.

Il risultato della query delle funzionalità riflette le funzionalità teoriche massime dei sottosistemi. Altre attività nella GPU o in diversi stati di potenza possono ridurre la capacità effettiva.

Esempi di query DRM hardware

Di seguito viene illustrato l'utilizzo più comune per il contenuto SDR (HEVC Standard Dynamic Range) a 4K 10 bit con drm hardware e restrizione 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”’);

Dove mp4a può essere sostituito con mp3, ac-3o ec-3. La velocità in bit decodifica può essere modificata per la codifica del provider di contenuti. decode-fps può essere impostato su 60 anziché 30, ma può essere gated by velocità effettiva del processore di sicurezza DRM hardware. display-res-x e display-res-y i valori possono essere impostati meno di 4K completi se il provider vuole eseguire il push dei flussi 4K a 3200 x 1800, 3000 x 2000 o 2560 x 1440, ad esempio.

Poiché i risultati della query di decodifica non devono cambiare dinamicamente, il polling successivo per hdcp=2 mentre in Forse può usare un modulo più breve come piccola ottimizzazione

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

Naturalmente, questa ottimizzazione non intercetta una modifica della risoluzione del monitoraggio dinamico, ma tale modifica probabilmente interromperà l'istituzione di HDCP in corso comunque.

Di seguito viene illustrato l'utilizzo più comune per il contenuto HDR (HEVC High Dynamic Range) a 4K a 10 bit con drm hardware e restrizione hdcp 2.2 di 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”’);

Nota: per Windows 10, versione 1607, hdr=1 indica che il supporto MPO a 10 bit 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 è presente o che la chiave del Registro di sistema HighColor di sola sviluppo è presente ed è stata impostata: HKLM\SOFTWARE\Microsoft\Windows\DWM key HighColor come valore DWORD pari a 1.

Di seguito viene illustrato l'utilizzo più comune per il contenuto SDR a 8 bit a 1080p con DRM hardware e HDCP senza restrizione di 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”’);

Requisiti

Vedi anche

MF_MEDIA_ENGINE_CANPLAY