Aggiornamenti di contenuti multimediali in Chrome 69

François Beaufort
François Beaufort
GitHub

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.

PTS/DTS
. PTS/DTS

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.

ALT_TEXT_HERE
. Gestore di intent multimediali

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.

Bug di Chromium

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