- Chrome supporta la decodifica video AV1.
- Eseguire query su quali schemi di crittografia sono supportati La funzionalità EME è ora disponibile.
- Gli sviluppatori web possono provare a eseguire query per verificare se un determinato criterio HDCP può essere applicato.
- Media Source Extensions ora utilizza PTS per intervalli inseriti nel buffer e valori di durata.
- Gli utenti di Android Go possono aprire audio, video e immagini scaricati in Chrome.
- Gli eventi bloccati per gli elementi multimediali che utilizzano la funzionalità MSE vengono rimossi.
Decoder video AV1
Tracker dello stato di Chrome | Bug di Chromium
EME: supporto dello schema di crittografia per query
Alcune piattaforme o sistemi chiave supportano solo la modalità CENC, mentre altri supportano solo Modalità CBCS. Altri ancora sono in grado di supportarle entrambe. Questi due schemi di crittografia sono incompatibili, pertanto gli sviluppatori web devono poter fare scelte intelligenti sui contenuti da pubblicare.
Per evitare di dover stabilire su quale piattaforma si trovano per verificare la presenza di informazioni "note"
per lo schema di crittografia, viene aggiunta una nuova chiave encryptionScheme
MediaKeySystemMediaCapability
dizionario per consentire ai siti web di specificare
quale schema di crittografia può essere utilizzato in Encrypted Media Extensions (EME).
La nuova chiave encryptionScheme
può avere uno di due valori:
'cenc'
Crittografia completa di campioni e sottocampionati video NAL in modalità AES-CTR.'cbcs'
Crittografia con pattern NAL per video parziale in modalità AES-CBC.
Se non specificato, indica che qualsiasi schema di crittografia è accettabile. Nota
che Clear Key supporti sempre lo schema 'cenc'
.
L'esempio seguente mostra come eseguire query su due configurazioni con diverse schemi di crittografia. In questo caso, ne verrà scelta una sola.
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, solo una configurazione con due opzioni di crittografia diverse viene eseguita una query. In questo caso, Chrome eliminerà qualsiasi oggetto di funzionalità non può essere supportata, quindi la configurazione accumulata potrebbe contenere schematica 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
Attualmente, il criterio HDCP è un requisito delle norme comune per lo streaming ad alta risoluzione. di contenuti protetti. Gli sviluppatori web che vogliono applicare un criterio HDCP devi attendere il completamento dello scambio di licenze o avviare lo streaming contenuti a bassa risoluzione. È una triste situazione che le norme HDCP L'API Check mira a risolvere.
L'API proposta consente agli sviluppatori web di chiedere se un determinato criterio HDCP
può essere applicato in modo che la riproduzione possa essere avviata alla risoluzione ottimale per
la migliore esperienza utente possibile. Consiste in un semplice metodo per interrogare lo stato
una chiave ipotetica associata a un criterio HDCP, senza la necessità di creare un
MediaKeySession
o recupera 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, il valore
si risolve con un MediaKeyStatus
di 'usable'
. In caso contrario, la promessa
si risolve con altri valori di errore di MediaKeyStatus
come
'output-restricted'
o 'output-downscaled'
. Se il sistema chiavi non
non supportano HDCP Policy Check (ad es. Clear Key System), la promessa viene rifiutata.
In breve, ecco come funziona attualmente l'API. Dai un'occhiata all'esempio 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 le norme HDCP Verifica la funzionalità API in Chrome 69 per computer (ChromeOS, Linux, Mac e Windows).
Il periodo di prova è terminato a novembre 2018.
Intenzione di sperimentare | Tracker dello stato di Chrome | Bug di Chromium
Conformità MSE PTS/DTS
Gli intervalli e i valori di durata sottoposti a buffer sono ora registrati in base all'ora della presentazione (PTS), anziché in base a quelli della decodifica di data e ora (DTS) in Media Source Extensions (MSE).
Quando il servizio MSE era nuovo, l'implementazione di Chrome veniva testata su WebM e MP3, formati di stream multimediali in cui non esisteva alcuna distinzione tra PTS e DTS. e funzionava bene fino all'aggiunta di ISO BMFF (noto anche come MP4). Questo contenitore spesso contiene presentazioni non in ordine rispetto a flussi temporali di decodifica (ad codec come H.264, ad esempio) con differenze tra DTS e PTS. Ciò ha causato Chrome deve segnalare (di solito solo leggermente) diversi intervalli nel buffer e durata del previsto. Questo nuovo comportamento verrà implementato gradualmente in Chrome 69 e rendere 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 non sai quale metodo viene utilizzato per segnalare intervalli e durata presenti nel buffer
aggiuntivi, puoi andare alla pagina chrome://media-internals
interna e cercare
"ChunkDemuxer: buffering per PTS" o "ChunkDemuxer: buffering per DTS" nel
logaritmi.
Intento di implementazione | Bug di Chromium
Gestione degli intent di visualizzazione dei contenuti multimediali su Android Go
Android Go è una versione leggera di Android progettata per i principianti smartphone. A tal fine, non include necessariamente alcuni contenuti multimediali applicazioni. Ad esempio, se un utente tenta di aprire un video scaricato, non avranno applicazioni per gestire questo intento.
Per risolvere il problema, Chrome 69 su Android Go ora ascolta gli intent di visualizzazione dei contenuti multimediali, gli utenti possono visualizzare audio, video e immagini scaricati. In altre parole, ci vuole al posto delle applicazioni di visualizzazione mancanti.
Tieni presente che questa funzionalità di Chrome è attiva su tutti i dispositivi Android con sistema operativo Android. O e versioni successive con massimo 1 GB di RAM.
Rimozione dei contenuti "in stallo" eventi per elementi multimediali che utilizzano MSE
Uno "in stallo" viene generato su un elemento multimediale se i dati multimediali sono stati scaricati
non è riuscito ad avanzare per circa 3 secondi. Quando si utilizzano Media Source Extensions
(MSE), l'app web gestisce il download e l'elemento multimediale non è a conoscenza di
i suoi progressi. Di conseguenza, Chrome ha visualizzato lo stato "bloccato" in modo inappropriato
volte in cui il sito web non ha aggiunto nuovi blocchi di dati multimediali con
SourceBuffer.appendBuffer()
negli ultimi 3 secondi.
Poiché i siti web possono decidere di aggiungere grandi blocchi di dati a bassa frequenza, non è un indicatore utile dello stato del buffering. Rimozione di elementi "in stallo" in corso... eventi per gli elementi multimediali che utilizzano l'MSE facilitano la confusione e allineano meglio Chrome con la specifica MSE. Tieni presente che gli elementi multimediali che non utilizzano l'MSE continuano a raccogliere dati per i video "in stallo" come avviene oggi.
Intento di ritiro e rimozione | Tracker dello stato di Chrome | Bug di Chromium