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:
- Prédire si la lecture sera fluide et économe en énergie pour les contenus multimédias chiffrés
- Prise en charge de l'optimisation de l'attribut
playsInlinede l'élément vidéo.
Médias chiffrés: informations sur le décodage
Depuis Chrome 66, les développeurs Web peuvent utiliser les informations de décodage pour interroger le navigateur sur les capacités claires de décodage du contenu de l'appareil en fonction d'informations telles que les codecs, le profil, la résolution, le débit, etc. Cela indique si la lecture sera fluide (en temps opportun) 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 les configurations multimédias chiffrées afin que les sites Web utilisant des médias chiffrés (EME) puissent sélectionner les flux multimédias optimaux.
En résumé, voici comment fonctionne les informations de décodage pour les EME. Essayez l'exemple 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 ont des chemins de code spécialisés pour le décodage et l'affichage, ce qui signifie que la compatibilité et les performances des codecs sont différentes de celles des 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 qui contient un certain nombre de types EME bien connus. Cette opération réplique les entrées fournies au requestMediaKeySystemAccess() d'EME avec une différence majeure: les séquences d'entrées fournies à requestMediaKeySystemAccess() sont aplaties en une seule valeur chaque fois que l'objectif de la séquence était de faire en sorte que requestMediaKeySystemAccess() choisisse un sous-ensemble compatible.
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 ordonner les 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 défini sur true, un autre objet MediaKeySystemAccess nommé keySystemAccess est également renvoyé. Il permet de demander des clés multimédias et de configurer la lecture de contenus multimédias chiffrés. 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 concernant les contenus multimédias chiffrés nécessite le protocole HTTPS.
Notez également qu'elle peut déclencher une invite utilisateur sur Android et ChromeOS de la même manière que requestMediaKeySystemAccess(). Toutefois, il n'affichera pas plus d'invites que requestMediaKeySystemAccess(), bien qu'il nécessite plus d'appels pour configurer la lecture multimédia chiffrée.
Intention de test | Outil de suivi de l'état de Chrome | Bug Chromium
HTMLVideoElement.playsInline
Chrome accepte désormais 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, limitée à la zone de lecture de l'élément.
De la même manière dans Safari, où les éléments vidéo sur l'iPhone ne passent pas automatiquement en mode plein écran au début de la lecture, cette suggestion permet à certaines intégrations vidéo de bénéficier d'une expérience de lecture automatique en plein écran. Les développeurs Web peuvent l'utiliser pour désactiver cette expérience si nécessaire.
<video playsinline></video>
Étant donné que Chrome sur Android et sur ordinateur n'implémente pas le plein écran automatique, l'indice de l'attribut d'élément vidéo playsInline n'est pas utilisé.
Intention de livraison | Outil de suivi de l'état de Chrome | Bug Chromium