- Chrome supporta la decodifica video AV1.
- È ora disponibile l'esecuzione di query sugli schemi di crittografia supportati tramite EME.
- Gli sviluppatori web possono sperimentare query sulla possibilità di applicare un determinato criterio HDCP.
- Le Media Source Extensions ora utilizzano la PTS per gli intervalli con buffer e i valori della durata.
- Gli utenti di Android Go possono aprire i contenuti audio, video e immagini scaricati in Chrome.
- Gli eventi bloccati per gli elementi multimediali che utilizzano la funzione MSE vengono rimossi.
Decodificatore video AV1
Tracker di stato di Chrome | Bug di Chromium
EME: supporto per lo schema di crittografia di query
Alcune piattaforme o sistemi chiave supportano solo la modalità CENC, mentre altri supportano solo la modalità CBCS. Altri ancora supportano entrambi. Questi due schemi di crittografia sono incompatibili, pertanto gli sviluppatori web devono essere in grado di fare scelte intelligenti in merito ai contenuti da pubblicare.
Per evitare di dover determinare su quale piattaforma sono utilizzati per verificare il supporto di schemi di crittografia "noti",
una nuova chiave encryptionScheme viene aggiunta nel
dizionario di MediaKeySystemMediaCapability per consentire ai siti web di specificare
quale schema di crittografia potrebbe essere utilizzato in Encrypted Media Extensions (EME).
La nuova chiave encryptionScheme può essere uno dei due seguenti valori:
'cenc'Esempio completo in modalità AES-CTR e crittografia del sottocampione NAL video.'cbcs'Crittografia con pattern video NAL parziale in modalità AES-CBC.
Se non specificato, indica che qualsiasi schema di crittografia è accettabile. Tieni presente che Clear Key supporta sempre lo schema 'cenc'.
L'esempio seguente mostra come eseguire query su due configurazioni con schemi di crittografia diversi. In questo caso, ne verrà selezionato solo uno.
await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [
{
label: 'configuration using the "cenc" encryption scheme',
videoCapabilities: [{
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cenc'
}],
audioCapabilities: [{
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cenc'
}],
initDataTypes: ['keyids']
},
{
label: 'configuration using the "cbcs" encryption scheme',
videoCapabilities: [{
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cbcs'
}],
audioCapabilities: [{
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cbcs'
}],
initDataTypes: ['keyids']
},
]);
Nell'esempio seguente, viene eseguita una query solo su una configurazione con due diversi schemi di crittografia. In questo caso, Chrome eliminerà tutti gli oggetti funzionalità che non è in grado di supportare, quindi la configurazione accumulata potrebbe contenere uno schema di crittografia o entrambi.
await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [{
videoCapabilities: [
{ // A video capability using the "cenc" encryption scheme
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cenc'
},
{ // A video capability using the "cbcs" encryption scheme
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cbcs'
},
],
audioCapabilities: [
{ // An audio capability using the "cenc" encryption scheme
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cenc'
},
{ // An audio capability using the "cbcs" encryption scheme
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cbcs'
},
],
initDataTypes: ['keyids']
}]);
Intento di implementazione | Tracker dello stato di Chrome | Bug di Chromium
EME: controllo dei criteri HDCP
Al giorno d'oggi, HDCP è un requisito dei criteri comune per lo streaming ad alta risoluzione di contenuti protetti. E gli sviluppatori web che vogliono applicare un criterio HDCP devono attendere il completamento dello scambio della licenza o avviare lo streaming di contenuti a bassa risoluzione. Questa è una situazione spiacevole che l'API HDCP Policy Check mira a risolvere.
L'API proposta consente agli sviluppatori web di verificare se è possibile applicare un determinato criterio HDCP, in modo che la riproduzione possa essere avviata alla risoluzione ottimale per ottimizzare l'esperienza utente. Consiste in un semplice metodo per eseguire query sullo stato di una chiave ipotetica associata a un criterio HDCP, senza dover creare un MediaKeySession o recuperare una licenza reale. Non è necessario che MediaKeys sia collegato
a elementi audio o video.
L'API HDCP Policy Check funziona semplicemente chiamando mediaKeys.getStatusForPolicy() con un oggetto che ha una chiave minHdcpVersion e un valore valido. Se HDCP è disponibile nella versione specificata, la promessa restituita
si risolve con un valore MediaKeyStatus pari a 'usable'. In caso contrario, la promessa
viene risolta con altri valori di errore pari a MediaKeyStatus, come
'output-restricted' o 'output-downscaled'. Se il sistema di chiavi non supporta il controllo dei criteri HDCP (ad esempio, Clear Key System), la promessa viene rifiutata.
In breve, ecco come funziona l'API per il momento. Dai un'occhiata al campione ufficiale per provare tutte le versioni di HDCP.
const config = [{
videoCapabilities: [{
contentType: 'video/webm; codecs="vp09.00.10.08"',
robustness: 'SW_SECURE_DECODE' // Widevine L3
}]
}];
navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(mediaKeySystemAccess => mediaKeySystemAccess.createMediaKeys())
.then(mediaKeys => {
// Get status for HDCP 2.2
return mediaKeys.getStatusForPolicy({ minHdcpVersion: '2.2' })
.then(status => {
if (status !== 'usable')
return Promise.reject(status);
console.log('HDCP 2.2 can be enforced.');
// TODO: Fetch high resolution protected content...
});
})
.catch(error => {
// TODO: Fallback to fetch license or stream low-resolution content...
});
Disponibile per le prove dell'origine
Per ricevere feedback dagli sviluppatori web, in precedenza abbiamo aggiunto la funzionalità API HDCP Policy Check in Chrome 69 per computer (ChromeOS, Linux, Mac e Windows).
La prova è terminata con successo a novembre 2018.
Intenzione di esperimento | Tracker dello stato di Chrome | Bug di Chromium
Conformità MSE PTS/DTS
Gli intervalli e i valori della durata sottoposti a buffer sono ora riportati dagli intervalli PTS (Presenttion Time Stamp), anziché dagli intervalli Decode Time Stamp (DTS) in Media Source Extensions (MSE).
Quando la tecnologia MSE era nuova, l'implementazione di Chrome è stata testata rispetto a WebM e MP3, alcuni formati di stream multimediali in cui non esisteva alcuna distinzione tra PTS e DTS. Tutto funzionava bene fino all'aggiunta di ISO BMFF (alias MP4). Questo contenitore spesso contiene flussi temporali fuori dall'ordine rispetto a quelli di decodifica (ad esempio per codec come H.264), con conseguente differenza tra DTS e PTS. Di conseguenza, Chrome ha segnalato (di solito solo leggermente) intervalli di buffer e valori di durata diversi rispetto al previsto. Questo nuovo comportamento verrà implementato gradualmente in Chrome 69 e renderà la sua implementazione MSE conforme alla specifica MSE.
Questa modifica interessa MediaSource.duration (e di conseguenza
HTMLMediaElement.duration), SourceBuffer.buffered (e di conseguenza
HTMLMediaElement.buffered) e SourceBuffer.remove(start, end).
Se hai dubbi su quale metodo venga utilizzato per segnalare intervalli con buffer e valori di durata, puoi andare alla pagina chrome://media-internals interna e cercare nei log "ChunkDemuxer: buffering by PTS" o "ChunkDemuxer: buffering by DTS".
Intenzione di implementazione | Bug di Chromium
Gestione degli intent di visualizzazione di contenuti multimediali su Android Go
Android Go è una versione leggera di Android progettata per gli smartphone di base. A questo scopo, non viene necessariamente fornito con alcune applicazioni di visualizzazione dei contenuti multimediali, quindi se un utente prova ad aprire un video scaricato, ad esempio, non avrà alcuna applicazione per gestire questo intento.
Per risolvere questo problema, Chrome 69 su Android Go ora rimane in ascolto degli intent di visualizzazione dei contenuti multimediali per consentire agli utenti di visualizzare l'audio, i video e le immagini scaricati. In altre parole, sostituisce le applicazioni di visualizzazione mancanti.
Tieni presente che questa funzionalità di Chrome è attiva su tutti i dispositivi Android con Android O e versioni successive con massimo 1 GB di RAM.
Rimozione degli eventi "in stallo" per gli elementi multimediali che utilizzano MSE
Viene generato un evento "in stallo" su un elemento multimediale se il download dei dati multimediali non è riuscito per circa 3 secondi. Quando utilizzi Media Source Extensions (MSE), l'app web gestisce il download e l'elemento multimediale non è a conoscenza del suo avanzamento. Di conseguenza, Chrome ha generato eventi "bloccati" in momenti inappropriati ogni volta che il sito web non ha aggiunto nuovi blocchi di dati multimediali con SourceBuffer.appendBuffer() negli ultimi 3 secondi.
Poiché i siti web potrebbero decidere di aggiungere grandi blocchi di dati a bassa frequenza, questo non è un indicatore utile del buffering. La rimozione degli eventi "in stallo" per gli elementi multimediali che utilizzano MSE elimina la confusione e rende Chrome più in linea con la specifica MSE. Tieni presente che gli elementi multimediali che non utilizzano MSE continueranno a generare eventi "in stallo" come fanno attualmente.
Intento di ritiro e rimozione | Tracker di stato di Chrome | Bug di Chromium