Cette page a été traduite par l'API Cloud Translation.

Mises à jour multimédias dans Chrome 69

François Beaufort

Chrome est compatible avec le décodage vidéo AV1.
Pour savoir quels systèmes de chiffrement sont compatibles, La EME est désormais disponible.
Les développeurs Web peuvent interroger pour savoir si une règle HDCP spécifique peut être appliquée.
Les extensions de sources multimédias utilisent désormais les PTS pour les plages mises en mémoire tampon et les valeurs de durée.
Les utilisateurs d'Android Go peuvent ouvrir les fichiers audio, vidéo et images téléchargés dans Chrome.
Les événements historiques pour les éléments multimédias utilisant MSE sont supprimés.

Décodeur vidéo AV1

EME: interroger la compatibilité du schéma de chiffrement

Certaines plates-formes ou systèmes de clés ne sont compatibles qu'avec le mode CENC, tandis que d'autres ne le prennent en charge Mode CBCS D'autres encore peuvent 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 se servent pour rechercher l'état "connu" la compatibilité avec les schémas de chiffrement, une nouvelle clé encryptionScheme est ajoutée dans MediaKeySystemMediaCapability dictionnaire pour permettre aux sites Web de spécifier le schéma de chiffrement pouvant être utilisé dans les extensions multimédias chiffrées (EME, Encrypted Media Extensions) ;

La nouvelle clé encryptionScheme peut avoir l'une des deux valeurs suivantes:

'cenc' Échantillon complet et chiffrement du sous-échantillon NAL vidéo en mode AES-CTR.
'cbcs' Chiffrement NAL partiel en mode AES-CBC.

Si aucune valeur n'est spécifiée, elle indique que n'importe quel schéma de chiffrement est acceptable. Remarque Clear Key (Effacer la clé) accepte toujours le schéma 'cenc'.

L'exemple ci-dessous montre comment interroger deux configurations avec des configurations des schémas de chiffrement. 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 types de chiffrement différents sont interrogés. Dans ce cas, Chrome supprime tout objet de capacités qu'il ne prend pas en charge. La configuration accumulée peut donc contenir un 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']
  }]);

Projet d'implémentation | Chromestatus Tracker | Bug Chromium

EME: vérification de la règle HDCP

À l'heure actuelle, HDCP est une exigence courante dans la règle pour le streaming en haute résolution. de contenu protégé. et les développeurs Web qui souhaitent appliquer une stratégie HDCP doit attendre la fin de l'échange de licences ou démarrer la diffusion en basse résolution. Malheureusement, le Règlement HDCP L'API Check vise à résoudre le problème.

Cette API proposée permet aux développeurs Web de demander si une certaine stratégie HDCP pour que la lecture puisse être lancée à la résolution optimale la meilleure expérience utilisateur. Il s'agit d'une méthode simple pour interroger l'état une clé hypothétique associée à une stratégie HDCP, sans qu’il soit nécessaire de créer un MediaKeySession ou récupérer une véritable licence. Il n'est pas nécessaire que MediaKeys soit à des éléments audio ou vidéo.

Pour utiliser l'API HDCP Policy Check, il vous suffit d'appeler mediaKeys.getStatusForPolicy() par un objet possédant une clé minHdcpVersion ; et une valeur valide. Si HDCP est disponible pour la version spécifiée, la valeur la promesse est résolue avec une MediaKeyStatus de 'usable'. Sinon, la promesse se résout avec d'autres valeurs d'erreur de MediaKeyStatus, telles que : 'output-restricted' ou 'output-downscaled'. Si le système de clés ne sont compatibles avec la vérification de la stratégie HDCP (par exemple, Clear Key System), mais la promesse est refusée.

Voici comment fonctionne l'API pour le moment. Découvrez l'extrait 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 recevoir les commentaires des développeurs Web, nous avons ajouté le règlement HDCP Vérifiez les fonctionnalités de l'API dans Chrome 69 pour ordinateur (ChromeOS, Linux, Mac et Windows).

L'essai a pris fin en novembre 2018.

Intention de test | Chromestatus Tracker | Bug Chromium

Conformité MSE PTS/DTS

Les plages de valeurs mises en mémoire tampon et les valeurs de durée sont désormais indiquées par l'horodatage de la présentation (PTS) au lieu d'intervalles de code temporel de décodage (DTS) dans les Source Extensions (MSE).

Lorsque MSE était une nouvelle fonctionnalité, l'implémentation de Chrome était testée vis-à-vis des formats WebM et MP3, formats de flux multimédia où il n'y avait aucune distinction entre PTS et DTS. Et il fonctionnait correctement jusqu'à ce que le format ISO BMFF (aussi appelé MP4) ait été ajouté. Ce conteneur contient souvent une présentation désordonnée contre des flux temporels de décodage (par exemple, codecs comme H.264 par exemple) provoquant des différences entre DTS et PTS. Cela a causé Chrome pour signaler (généralement légèrement) les plages et durées de mise en mémoire tampon différentes que prévu. Ce nouveau comportement sera déployé progressivement dans Chrome 69 et rendre son implémentation MSE conforme à la spécification MSE.

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 et la durée mises en mémoire tampon vous pouvez accéder à la page chrome://media-internals interne et rechercher "ChunkDemuxer: mise en mémoire tampon par PTS" ou « ChunkDemuxer: buffering by DTS » dans journaux.

Projet d'implémentation | Bug Chromium

Gérer les intents de visionnage multimédia sur Android Go

Android Go est une version légère d'Android conçue pour les débutants les smartphones. C'est pourquoi il n'est pas forcément compatible avec certains types de contenus applications. Ainsi, si un utilisateur essaie d'ouvrir une vidéo téléchargée, par exemple, ne dispose d'aucune application pour gérer cet intent.

Pour résoudre ce problème, Chrome 69 sur Android Go écoute désormais les intents de visionnage de contenu multimédia. les utilisateurs peuvent afficher les contenus audio, vidéos et images téléchargés. En d’autres termes, il faut l'emplacement des applications de visionnage manquantes.

ALT_TEXT_HERE — </ph> Gestionnaire d'intents multimédias

Notez que cette fonctionnalité Chrome est activée sur tous les appareils Android équipés d'Android. O et versions ultérieures avec 1 Go de RAM ou moins.

Bug Chromium

Suppression de "Blocage" événements pour les éléments multimédias à l'aide de MSE

Une annonce "en panne" est déclenché sur un élément multimédia si le téléchargement n'a pas pu progresser pendant environ 3 secondes. Lorsque vous utilisez des extensions de sources multimédias (MSE), l'application Web gère le téléchargement, mais l'élément multimédia n'en a pas connaissance. sa progression. Chrome a donc "bloqué" des événements au niveau fois chaque fois que le site Web n'a pas ajouté de nouveaux fragments de données multimédias avec SourceBuffer.appendBuffer() au cours des 3 dernières secondes.

Comme les sites Web peuvent décider d’ajouter de gros blocs de données à une faible fréquence, cela n'est pas un signal utile concernant l'état de la mise en mémoire tampon. Suppression des "blocages" événements pour d'éléments multimédias à l'aide de MSE pour clarifier la confusion et mieux adapter Chrome avec la spécification MSE. Notez que les éléments multimédias qui n'utilisent pas de MSE continue d'augmenter comme aujourd'hui.

Projet d'abandon et de suppression | Chromestatus Tracker | Bug Chromium