Mises à jour multimédias dans Chrome 75

François Beaufort

Les fonctionnalités multimédias de Chrome ont été mises à jour dans la version 75. Dans cet article, je vais vous présenter ces nouvelles fonctionnalités, qui incluent les suivantes :

• Prédire si la lecture sera fluide et économe en énergie pour les contenus multimédias chiffrés
• Prise en charge de l'indice d'attribut playsInline de l'élément vidéo.

Éléments multimédias chiffrés : informations de décodage

Depuis Chrome 66, les développeurs Web peuvent utiliser les informations de décodage pour interroger le navigateur sur les capacités de décodage du contenu clair de l'appareil en fonction d'informations telles que les codecs, le profil, la résolution, les débits, etc. Il indique si la lecture sera fluide (à temps) et économe en énergie en fonction des statistiques de lecture précédentes enregistrées par le navigateur.

La spécification de l'API Media Capabilities, qui définit les informations de décodage, a depuis été mise à jour pour gérer également les configurations multimédias chiffrées afin que les sites Web utilisant des contenus multimédias chiffrés (EME) puissent sélectionner les flux multimédias optimaux.

Voici un résumé du fonctionnement des informations de décodage pour EME. Essayez l'extrait officiel.

const encryptedMediaConfig = {
  type: 'media-source', // or 'file'
  video: {
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    width: 1920,
    height: 1080,
    bitrate: 2646242, // number of bits used to encode a second of video
    framerate: '25' // number of frames used in one second
  },
  keySystemConfiguration: {
    keySystem: 'com.widevine.alpha',
    videoRobustness: 'SW_SECURE_DECODE' // Widevine L3
  }
};

navigator.mediaCapabilities.decodingInfo(encryptedMediaConfig).then(result => {
  if (!result.supported) {
    console.log('Argh! This encrypted media configuration is not supported.');
    return;
  }

  if (!result.keySystemAccess) {
    console.log('Argh! Encrypted media support is not available.')
    return;
  }

  console.log('This encrypted media configuration is supported.');
  console.log('Playback should be' +
      (result.smooth ? '' : ' NOT') + ' smooth and' +
      (result.powerEfficient ? '' : ' NOT') + ' power efficient.');

  // TODO: Use `result.keySystemAccess.createMediaKeys()` to setup EME playback.
});

Les lectures EME disposent de chemins de code de décodage et de rendu spécialisés, ce qui signifie que la compatibilité et les performances des codecs sont différentes par rapport aux lectures claires. Par conséquent, une nouvelle clé keySystemConfiguration doit être définie dans l'objet de configuration multimédia transmis à navigator.mediaCapabilities.decodingInfo(). La valeur de cette clé est un dictionnaire contenant un certain nombre de types EME bien connus. Cela reproduit les entrées fournies à requestMediaKeySystemAccess() de l'EME avec une différence majeure : les séquences d'entrées fournies à requestMediaKeySystemAccess() sont aplaties en une seule valeur partout où l'intention de la séquence était de demander à requestMediaKeySystemAccess() de choisir un sous-ensemble qu'il prend en charge.

Les informations de décodage décrivent la qualité (fluidité et efficacité énergétique) de la prise en charge d'une seule paire de flux audio et vidéo sans prendre de décision pour l'appelant. Les appelants doivent toujours commander des configurations multimédias comme ils le font avec requestMediaKeySystemAccess(). Ce n'est que maintenant qu'ils parcourent la liste eux-mêmes.

navigator.mediaCapabilities.decodingInfo() renvoie une promesse qui se résout de manière asynchrone avec un objet contenant trois valeurs booléennes : supported, smooth et powerEfficient. Toutefois, lorsqu'une clé keySystemConfiguration est définie et que supported est true, un autre objet MediaKeySystemAccess nommé keySystemAccess est également renvoyé. Il peut être utilisé pour demander certaines clés multimédias et configurer la lecture multimédia chiffrée. Exemple :

// Like rMSKA(), orderedMediaConfigs is ordered from most to least wanted.
const capabilitiesPromises = orderedMediaConfigs.map(mediaConfig =>
  navigator.mediaCapabilities.decodingInfo(mediaConfig)
);

// Assume this app wants a supported and smooth media playback.
let bestConfig = null;
for await (const result of capabilitiesPromises) {
  if (result.supported && result.smooth) {
    bestConfig = result;
    break;
  }
}

if (bestConfig) {
  const mediaKeys = await bestConfig.keySystemAccess.createMediaKeys();
  // TODO: rest of EME path as-is
} else {
  // Argh! No smooth configs found.
  // TODO: Maybe choose the lowest resolution and framerate available.
}

Notez que le décodage des informations pour les contenus multimédias chiffrés nécessite HTTPS.

De plus, sachez qu'il peut déclencher une invite utilisateur sur Android et ChromeOS de la même manière que requestMediaKeySystemAccess(). Toutefois, il n'affiche pas plus d'invites que requestMediaKeySystemAccess(), bien qu'il nécessite davantage d'appels pour configurer la lecture multimédia chiffrée.

Intention de test | Outil de suivi de l'état Chrome | Bug Chromium

HTMLVideoElement.playsInline

Chrome est désormais compatible avec l'attribut booléen playsInline. S'il est présent, il indique au navigateur que la vidéo doit être affichée "intégrée" dans le document par défaut, en fonction de la zone de lecture de l'élément.

Comme dans Safari, où les éléments vidéo sur iPhone ne passent pas automatiquement en mode plein écran au début de la lecture, cette indication permet à certains intégrateurs de bénéficier d'une expérience de lecture vidéo en plein écran automatique. Les développeurs Web peuvent l'utiliser pour désactiver cette expérience si nécessaire.

<video playsinline></video>

Comme Chrome sur Android et sur ordinateur n'implémente pas le plein écran automatique, l'indice d'attribut de l'élément vidéo playsInline n'est pas utilisé.

Intent to Ship | Outil de suivi de l'état de Chrome | Bug Chromium