Metodo IMFExtendedDRMTypeSupport::IsTypeSupportedEx (mfmediaengine.h)

Esegue una query 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>]". Se non riconosciuto, i parser conformi a RFC 2045 devono ignorare questi parametri. Per le query sulle funzionalità, <il parametro> è denominato feature.

L'implementazione richiede il tipo di supporto RFC 2045 e gli identificatori del sottotipo, ad esempio "video/mp4" e il codec RFC 6381 codec="<codec> video[,<codec> audio]" 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 le funzionalità sottoposte a query sono probabilmente supportate, sono probabilmente supportate o non sono supportate.

Valore restituito

S_OK al successo.

Osservazioni:

Il parametro di input del tipo deve avere un tipo di supporto RFC 6381 Content-Type e gli identificatori di sottotipo presenti. Deve inoltre avere la stringa del parametro CodecS RFC 2045 presente. 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 da 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 caratteristiche 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 sul modo in cui è possibile eseguire query sulle 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 Decodifica 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 dell'output (HDCP) con o senza una query del sottosistema Decode, Display 1 o Display 2, 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 ottenuto 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.

Nella tabella seguente sono elencate le singole query di funzionalità supportate, organizzate in base al sottosistema video:

^* Supportato solo in Windows 10, versione 1607 e versioni successive del sistema operativo

^** Supportato solo in Windows 10, versione 1709 e versioni successive del sistema operativo

^*** L'algoritmo di intersezione è:

1. Trova tutti i display in cui l'area del client video dell'interfaccia utente dell'applicazione ha pixel.
2. Trova tutte le schede grafiche che controllano gli schermi dal passaggio 1. Per una query DRM hardware, questo set di adattatori viene filtrato per includere solo gli adattatori con supporto DRM hardware.
3. Trova tutti gli schermi connessi agli adattatori grafici del passaggio 2.

^**** Spetta al provider di contenuti scegliere il limite di risoluzione da usare quando questo criterio è attivo. È consigliabile un limite di 1080p, ma è possibile usare 720p. Si noti che l'input per questa policy proviene dalla pagina dell'interfaccia utente delle Impostazioni Video aggiunta in Windows 10, versione 1709.

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

La query hdcp (articolo 4) ha un costo di prima 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 alla valutazione asincrona di HDCP in modo asincrono e richiede fino a diversi secondi con HDCP 2.2, ma la query è sincrona con il blocco minimo, richiede che il chiamante usi ripetutamente la query fino alla finalizzazione del risultato come probabilmente o non supportato. La modifica del livello HDCP richiesto in una query mentre è ancora nello stato Forse genererà 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 del costo di calcolo sottostante. 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 di implementazione, le schede grafiche possono scegliere di usare HDCP 2.2 se tutti i nodi lo supportano, anche se la restrizione hdCP 2.2 di tipo 1 non è stata impostata. HDCP 2.2 può richiedere molto più tempo rispetto a HDCP 1.x per interagire. Le osservazioni sui televisori 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 all'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 deve 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 l'attesa di più secondi che si verifica di nuovo all'avvio della riproduzione.

In una modifica della topologia di output, i televisori e i monitor ad alta risoluzione richiedono spesso alcuni secondi per stabilizzare il desktop. Una modifica, e in particolare la riduzione, nel livello di protezione dell'output in genere causerà l'esito negativo della riproduzione attiva con DRM hardware per impostazione predefinita. In questo caso, una reazione a un errore di MF_POLICY_UNSUPPORTED (0xC00D7159) deve essere nascondere l'errore da parte dell'utente, rieseguire una query 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 sulle funzionalità di decodifica DRM software sono potenzialmente ambigue sulle prestazioni perché l'implementazione H.264 consente la decodifica software o l'offload GPU DXVA (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 decode-bpc non viene valutato. Windows non supporta la decodifica A.264 a 10 bit, ma una query con decode-bpc=10 avrà esito positivo.

Il risultato della query di funzionalità riflette le massime funzionalità teoriche dei sottosistemi. Altre attività nella GPU o in stati di alimentazione variabili possono ridurre le funzionalità effettive.

Esempi di query DRM hardware

Di seguito viene illustrato l'utilizzo più comune per il contenuto SDR (HEVC Standard Range) a 4K a 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 decodificata può essere modificata in base alla codifica del provider di contenuti. decode-fps può essere impostato su 60 anziché 30, ma può essere gestito dalla funzionalità di velocità effettiva del processore di sicurezza DRM hardware. display-res-x I valori e display-res-y possono essere impostati più bassi di 4K completi se il provider desidera eseguire il push di flussi 4K a 3200 x 1800, 3000 x 2000 o 2560 x 1440, ad esempio.

Poiché i risultati della query decode non devono cambiare in modo dinamico, il polling successivo per hdcp=2 mentre in Forse può usare una forma 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à comunque la creazione di HDCP.

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

Vedere anche

MF_MEDIA_ENGINE_CANPLAY