- Chrome est compatible avec le décodage vidéo AV1.
- Il est désormais possible d'interroger les schémas de chiffrement compatibles via EME.
- Les développeurs Web peuvent tester les requêtes pour savoir si une règle HDCP peut être appliquée.
- Les extensions Media Source utilisent désormais PTS pour les valeurs de plages mises en mémoire tampon et de durée.
- Les utilisateurs d'Android Go peuvent ouvrir dans Chrome les fichiers audio, vidéo et les images qu'ils ont téléchargés.
- Les événements bloqués pour les éléments multimédias utilisant la MSE sont supprimés.
Décodeur vidéo AV1
Outil de suivi de l'état de Chrome | Bug Chromium
EME: compatibilité des schémas de requête de chiffrement
Certaines plates-formes ou certains systèmes de clés ne sont compatibles qu'avec le mode CNC, tandis que d'autres ne sont compatibles qu'avec le mode CBCS. D'autres encore sont en mesure de prendre en charge les deux. Ces deux schémas de chiffrement sont incompatibles. Les développeurs Web doivent donc être en mesure de faire des choix intelligents concernant le contenu à diffuser.
Pour éviter d'avoir à déterminer la plate-forme sur laquelle ils utilisent pour vérifier la compatibilité des schémas de chiffrement "connus", une nouvelle clé encryptionScheme
est ajoutée dans le dictionnaire MediaKeySystemMediaCapability
. Cela permet aux sites Web de spécifier le schéma de chiffrement pouvant être utilisé dans les extensions multimédias chiffrées (EME).
La nouvelle clé encryptionScheme
peut avoir l'une des deux valeurs suivantes:
'cenc'
Mode AES-CTR : échantillon complet et chiffrement de sous-échantillons NAL vidéo.'cbcs'
: chiffrement partiel des vidéos en mode AES-CBC.
S'il n'est pas spécifié, tous les schémas de chiffrement sont acceptables. Notez que l'option Clear Key (Effacer la clé) est toujours compatible avec le schéma 'cenc'
.
L'exemple ci-dessous montre comment interroger deux configurations avec des schémas de chiffrement différents. Dans ce cas, un seul sera choisi.
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']
},
]);
Dans l'exemple ci-dessous, une seule configuration avec deux schémas de chiffrement différents est interrogée. Dans ce cas, Chrome supprimera tout objet de capacité qu'il n'est pas compatible. La configuration accumulée peut donc contenir un schéma de chiffrement ou les deux.
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']
}]);
Intention d'implémentation | Outil de suivi de l'état de Chrome | Bug Chromium
EME: vérification du respect des règles HDCP
De nos jours, le HDCP est une exigence de règle courante pour le streaming de contenus protégés en haute résolution. Les développeurs Web qui souhaitent appliquer une règle HDCP doivent attendre la fin de l'échange de licence ou commencer à diffuser du contenu en basse résolution. C'est une triste situation que l'API HDCP Policy Check cherche à résoudre.
Cette API proposée permet aux développeurs Web de demander si une certaine règle HDCP peut être appliquée afin que la lecture puisse être lancée avec la résolution optimale pour une expérience utilisateur optimale. Elle consiste en une méthode simple permettant d'interroger l'état d'une clé hypothétique associée à une stratégie HDCP, sans avoir à créer un MediaKeySession
ni à extraire une licence réelle. MediaKeys
ne doit pas nécessairement être associé à des éléments audio ou vidéo.
L'API HDCP Policy Check fonctionne simplement en appelant mediaKeys.getStatusForPolicy()
avec un objet possédant une clé minHdcpVersion
et une valeur valide. Si HDCP est disponible dans la version spécifiée, la promesse renvoyée se résout avec un MediaKeyStatus
de 'usable'
. Sinon, la promesse est résolue avec d'autres valeurs d'erreur de MediaKeyStatus
telles que 'output-restricted'
ou 'output-downscaled'
. Si le système de clés n'est pas du tout compatible avec la vérification des règles HDCP (par exemple, Clear Key System), la promesse est rejetée.
Voici, en bref, comment fonctionne l'API pour le moment. Consultez l'exemple officiel pour essayer toutes les versions de 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...
});
Disponible pour les phases d'évaluation
Pour recueillir les commentaires des développeurs Web, nous avons déjà ajouté la fonctionnalité d'API HDCP Policy Check dans Chrome 69 pour ordinateur (ChromeOS, Linux, Mac et Windows).
L'essai a pris fin en novembre 2018.
Intention de test | Outil de suivi de l'état de Chrome | Bug Chromium
Conformité MSE PTS/DTS
Les plages mises en mémoire tampon et les valeurs de durée sont désormais indiquées par des intervalles d'horodatage de présentation (PTS) plutôt que par des intervalles d'horodatage de décodage (DTS) dans les extensions de source multimédia (MSE).
Lorsque MSE était nouveau, l'implémentation de Chrome a été testée par rapport aux formats WebM et MP3, certains formats de flux multimédia qui ne distinguaient pas PTS et DTS. Et cela fonctionnait bien jusqu'à ce que le format ISO BMFF (également appelé MP4) soit ajouté. Ce conteneur contient fréquemment une présentation désordonnée et des flux temporels décodés (pour des codecs tels que le H.264, par exemple), ce qui entraîne des différences entre DTS et PTS. Chrome signale alors (généralement un peu) des valeurs de durée et de plages mises en mémoire tampon différentes de celles attendues. Ce nouveau comportement sera déployé progressivement dans Chrome 69 et rendre son implémentation MSE conforme à la spécification MSE.
![PTS/DTS](https://developer.chrome.com/static/blog/media-updates-in-chrome-69/image/ptsdts-a029a068bdd9b.png?authuser=6&hl=fr)
Cette modification affecte MediaSource.duration
(et donc HTMLMediaElement.duration
), SourceBuffer.buffered
(et donc HTMLMediaElement.buffered)
et SourceBuffer.remove(start, end)
).
Si vous ne savez pas quelle méthode est utilisée pour signaler les plages mises en mémoire tampon et les valeurs de durée, vous pouvez accéder à la page chrome://media-internals
interne et rechercher "ChunkDemuxer: buffering by PTS" ou "ChunkDemuxer: buffering by DTS" dans les journaux.
Intention d'implémentation | Bug Chromium
Gérer les intents de vue multimédia sur Android Go
Android Go est une version légère d'Android conçue pour les smartphones d'entrée de gamme. À cette fin, il n'est pas nécessairement fourni avec certaines applications de visionnage multimédia. Par conséquent, si un utilisateur tente d'ouvrir une vidéo téléchargée par exemple, aucune application ne sera disponible pour gérer cet intent.
Pour résoudre ce problème, Chrome 69 sur Android Go écoute désormais les intents de visionnage des contenus multimédias afin que les utilisateurs puissent afficher les contenus audio, les vidéos et les images téléchargés. En d'autres termes, elle remplace les applications de visualisation manquantes.
![ALT_TEXT_HERE](https://developer.chrome.com/static/blog/media-updates-in-chrome-69/image/alttexthere-0d5b0859fc0e3.png?authuser=6&hl=fr)
Notez que cette fonctionnalité Chrome est activée sur tous les appareils Android équipés d'Android O ou d'une version ultérieure avec 1 Go de RAM ou moins.
Suppression des événements "bloqués" pour les éléments multimédias utilisant la MSE
Un événement "bloqué" est déclenché sur un élément multimédia si le téléchargement des données multimédias n'a pas abouti pendant environ trois secondes. Lorsque vous utilisez des extensions de source multimédia (MSE), l'application Web gère le téléchargement et l'élément multimédia n'a pas connaissance de sa progression. Chrome provoquait donc des événements "bloqués" à des moments inappropriés, chaque fois que le site Web n'avait pas ajouté de nouveaux fragments de données multimédias avec SourceBuffer.appendBuffer()
au cours des trois dernières secondes.
Étant donné que les sites Web peuvent décider d'ajouter de grands segments de données à faible fréquence, ce signal n'est pas utile concernant la mise en mémoire tampon de l'état. La suppression des événements "bloqués" pour les éléments multimédias à l'aide de la MSE permet de dissiper la confusion et de rendre Chrome plus conforme à la spécification MSE. Notez que les éléments multimédias qui n'utilisent pas la MSE continueront de déclencher des événements "bloqués" comme ils le font actuellement.
Intention d'abandon et de suppression | Outil de suivi de l'état de Chrome | Bug Chromium