ProtectionCapabilities.IsTypeSupported(String, String) Metodo
Definizione
Importante
Alcune informazioni sono relative alla release non definitiva del prodotto, che potrebbe subire modifiche significative prima della release definitiva. Microsoft non riconosce alcuna garanzia, espressa o implicita, in merito alle informazioni qui fornite.
Funzionalità di query di decodifica video, visualizzazione e sottosistemi di protezione dell'output per le funzionalità DRM.
Avvertimento
È consigliabile usare questo metodo solo con Windows 10 versione 1607 o successiva del sistema operativo, anche se è presente nelle versioni precedenti di 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
Parametri
- type
-
String
Platform::String
winrt::hstring
Stringa che identifica le funzionalità per cui viene eseguito il supporto su cui viene eseguita una query. 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 HTMLMediaElementcanPlayType. 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à, <parameter>
è denominato funzionalità.
L'implementazione richiede il tipo di supporto RFC 2045 e gli identificatori di sottotipo, ad esempio "video/mp4" e il parametro codec RFC 6381 codec=”<video codec>[,<audio codec>]”
essere sempre presenti per fornire risultati di query validi.
Si noti che i termini tipo di contenuto e tipo sono noti storicamente come tipo MIME.
- keySystem
-
String
Platform::String
winrt::hstring
Stringa 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).
Restituisce
Valore che indica se le funzionalità sottoposte a query sono probabilmente supportate, sono probabilmente supportate o non sono supportate.
Commenti
Il tipo parametro di input deve avere il 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:
- È possibile usare una sola query di nomi di funzionalità e valori da ognuno dei sottosistemi in una singola chiamata
- È possibile eseguire una query del sottosistema Decodifica senza una query Display 1, Display 2 o Output Protection
- Per una query del sottosistema Display 1 è necessario che sia presente una query del sottosistema Decode
- Una query del sottosistema Display 2 richiede una query del sottosistema Decode, ma non richiede una query del sottosistema Display 1.
- È 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 query General: Efficiency
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 Forse risultato è consentito solo dal sottosistema di protezione dell'output e solo temporaneamente. Questo forse ha la precedenza su un probabilmente risultato dall'AND di tutte le altre query di funzionalità, fino a quando il Forse risolve nel tempo in probabilmente o non supportato. Il limite di tempo corrente per Forse da risolvere è di 10 secondi.
Nella tabella seguente sono elencate le singole query di funzionalità supportate, organizzate in base al sottosistema video:
Articolo | Video Sub-system | Nome funzionalità | Valore della funzionalità | Descrizione | Obbligatorio per questo sottosistema |
---|---|---|---|---|---|
1a | Decodificare | decode-res-x | Numero non negativo in pixel | Il decodificatore video supporta questa risoluzione massima nell'asse X? | Y |
1b | Decodificare | decode-res-y | Numero non negativo in pixel | Il decodificatore video supporta questa risoluzione massima nell'asse Y? | Y |
1c | Decodificare | decode-bitrate | Numero positivo in kilobit al secondo (Kbps) | Il decodificatore video supporta questa velocità in bit massima? | Y |
1d | Decodificare | decode-fps | 24, 25, 29.97, 30, 50, 59.94 o 60 | Il video decodificato supporta questo valore massimo di fotogrammi al secondo (FPS) ? | Y |
1e | Decodificare | decode-bpc (decode-bpp è deprecato) | 0, 8, 10 o 12 | Il decodificatore video può utilizzare questa profondità di colore per pixel? | Y |
1f | Decodificare | ** di accelerazione hardware-decodificatore | 1 o nessun valore come true | L'accelerazione hardware DXVA è disponibile indipendentemente dal fatto che sia presente un decodificatore del sistema operativo? | N |
1g | Decodificare | decodificatore-software-accelerazione ** | 1 o nessun valore come true | Un decodificatore del sistema operativo è in grado di decodificare il flusso? | N |
1h | Decodificare | decodificatore-software-richiede-hardware** | 1 o nessun valore come true | La funzionalità del decodificatore del sistema operativo richiede che sia presente l'accelerazione hardware DXVA? | N |
2a | Visualizzazione 1 | display-res-x | Numero non negativo in pixel | Almeno un** di intersecazione supporta questa risoluzione nell'asse X? | Y |
2b | Visualizzazione 1 | display-res-y | Numero non negativo in pixel | Almeno un*** di intersecazione supporta questa risoluzione nell'asse Y? | Y |
2c | Visualizzazione 1 | display-refreshrate | 24, 25, 29.97, 30, 50, 59.94 o 60 | La visualizzazione è configurata (come indicato da Windows) per almeno la frequenza di aggiornamento richiesta? | N |
2d | Visualizzazione 1 | display-bpc (display-bpp è deprecato) | 8 o 10 | Tutti gli schermi che si intersecano con ≥ risoluzione necessaria realizzano almeno questa profondità di colore? | N |
3 | Visualizza 2* | Hdr | 1 (supportato) | La destinazione supporta il rendering HDR (High Dynamic Range) | Y |
4 | Protezione output | hdcp | 0 (disattivato), 1 (in senza restrizione di tipo 1 hdCP 2.2), 2 (su con restrizione di tipo 1 HDCP 2.2) | Tutte le visualizzazioni abilitate per intersecare supportano almeno il livello di protezione delle richieste? | Y |
5 | Generale:** di efficienza | impostazione dell'efficienza | 0 (off = no restriction), 1 (on = limit resolution when on battery power) | L'utente vuole la durata della batteria, l'overhead di streaming e/o la velocità di download in preferenza alla risoluzione più alta?**** | Y |
6a | Decrittazione | tipo di crittografia | "cenc" o "cbcs" | Questo tipo di crittografia è supportato per la decrittografia con il codec/key-system specificato? Se il valore non è specificato, viene usato il valore predefinito "cenc". | N |
6b | Decrittazione | encryption-iv-size | 8 o 16 | Questa dimensione del vettore di inizializzazione (IV) (in byte) è supportata per la decrittografia con il codec/key-system specificato? Se il valore non è specificato, viene usato il valore predefinito 8. | N |
* supportato solo in Windows 10 versione 1607 e versioni più recenti del sistema operativo
** supportato solo in Windows 10 versione 1709 e versioni successive del sistema operativo
*** L'algoritmo di intersezione è:
- Trova tutti i display in cui l'area del client video dell'interfaccia utente dell'applicazione ha pixel.
- Trovare tutte le schede grafiche che guidano gli schermi dal passaggio 1. Per una query DRM hardware, questo set di adattatori viene filtrato in base solo a quelle schede con supporto DRM hardware.
- Trovare tutti gli schermi connessi alle schede grafiche 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 questo criterio proviene dalla pagina dell'interfaccia utente 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 x) AND (richiesto y >= effettivo set di intersecing massimo 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 Forse risultato a causa della valutazione asincrona di HDCP e che 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 finché il risultato non viene finalizzato 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 Forse timeout è 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 query hdcp=1
all'avvio dell'applicazione o dopo una modifica della topologia di output richiede l'attesa fino a 8 secondi più margine per questo peggiore caso. 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 all'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-3
o 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é su 30, ma può essere gestito dalla funzionalità di velocità effettiva del processore di sicurezza DRM hardware.
display-res-x
e i valori display-res-y
possono essere impostati in modo inferiore a 4K completo 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 oppure 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”’);