- Les développeurs Web peuvent désormais prédire si la lecture sera fluide et économe en énergie.
- Chrome est désormais compatible avec la lecture de vidéos HDR sur Windows 10.
- La lecture hors connexion avec des licences persistantes est désormais compatible avec Windows et Mac.
- La valeur de préchargement par défaut pour les éléments
<video>et<audio>est désormais"metadata". - Une erreur est désormais générée lorsque la vitesse de lecture multimédia n'est pas acceptée.
- Chrome met désormais en pause tous les contenus multimédias en arrière-plan uniquement.
- Le son n'est plus coupé pour une fréquence de lecture extrême.
Media Capabilities – API Decoding Info
Aujourd'hui, les développeurs Web s'appuient sur isTypeSupported() ou canPlayType() pour vaguement savoir si certains médias peuvent être décodés ou non. La vraie question devrait cependant être :
« Quelles seraient ses performances sur cet appareil ? »
C'est exactement l'une des solutions proposées par les Media Capabilities: une API pour interroger le navigateur sur les capacités de décodage de l'appareil en fonction d'informations telles que les codecs, le profil, la résolution, le débit, etc. Cela permettrait de déterminer si la lecture doit être fluide et économe en énergie en se basant sur les statistiques de lecture précédentes enregistrées par le navigateur.
En résumé, voici comment fonctionne l'API Decoding Info pour le moment. Découvrez l'extrait officiel.
const mediaConfig = {
type: 'media-source', // or 'file'
audio: {
contentType: 'audio/webm; codecs=opus',
channels: '2', // audio channels used by the track
bitrate: 132266, // number of bits used to encode a second of audio
samplerate: 48000 // number of samples of audio carried per second
},
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
}
};
navigator.mediaCapabilities.decodingInfo(mediaConfig).then(result => {
console.log('This configuration is' +
(result.supported ? '' : ' NOT') + ' supported,' +
(result.smooth ? '' : ' NOT') + ' smooth and' +
(result.powerEfficient ? '' : ' NOT') + ' power efficient.');
});
Vous pouvez essayer différentes configurations multimédias jusqu'à ce que vous trouviez la meilleure (smooth et powerEfficient) et l'utiliser pour lire le flux multimédia approprié. L'implémentation actuelle de Chrome est basée sur les informations de lecture précédemment enregistrées. Il définit smooth comme vrai lorsque le pourcentage d'images perdues est inférieur à 10 %, tandis que powerEfficient est vrai lorsque plus de 50% des images sont décodées par le matériel. Les petits frames sont toujours
considérés comme économes en énergie.
Nous vous recommandons d'utiliser un extrait semblable à celui ci-dessous afin de détecter la disponibilité et de revenir à votre implémentation actuelle pour les navigateurs qui ne sont pas compatibles avec cette API.
function isMediaConfigSupported(mediaConfig) {
const promise = new Promise((resolve, reject) => {
if (!('mediaCapabilities' in navigator)) {
return reject('MediaCapabilities API not available');
}
if (!('decodingInfo' in navigator.mediaCapabilities)) {
return reject('Decoding Info not available');
}
return resolve(navigator.mediaCapabilities.decodingInfo(mediaConfig));
});
return promise.catch(_ => {
let fallbackResult = {
supported: false,
smooth: false, // always false
powerEfficient: false // always false
};
if ('video' in mediaConfig) {
fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.video.contentType);
if (!fallbackResult.supported) {
return fallbackResult;
}
}
if ('audio' in mediaConfig) {
fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.audio.contentType);
}
return fallbackResult;
});
}
Disponible pour les phases d'évaluation
Afin de recueillir autant de commentaires que possible de la part des développeurs utilisant l'API Decoding Info (qui fait partie de Media Capabilities) sur le terrain, nous avons précédemment ajouté cette fonctionnalité dans Chrome 64 en tant que phase d'évaluation.
L'essai a pris fin en avril 2018.
Intention de test | Intention de livraison | Outil de suivi de l'état de Chrome | Bug Chromium
Lecture de vidéos HDR sur Windows 10
Les vidéos HDR (High Dynamic Range) présentent un contraste plus élevé et révèlent des ombres précises et détaillées ainsi que des tons clairs magnifiques avec plus de clarté que jamais. De plus, la prise en charge de la large gamme de couleurs signifie que les couleurs sont plus vives.
Comme la lecture VP9 Profile 2 10 bits est désormais compatible avec Chrome pour Windows 10 Fall Creator Update, Chrome permet également la lecture de vidéos HDR lorsque Windows 10 est en mode HDR. Notez que Chrome 64 est désormais compatible avec le profil de couleur scRGB, qui permet de lire des contenus multimédias en HDR.
Pour essayer, regardez la vidéo The World in HDR in 4K (ULTRA HD) sur YouTube et vérifiez qu'elle fonctionne en HDR en examinant le paramètre de qualité du lecteur YouTube.
Pour l'instant, vous n'avez besoin que de la mise à jour Windows 10 Fall Creator Update, d'une carte graphique et d'un écran compatibles HDR (par exemple, une carte NVIDIA série 10, d'un téléviseur ou d'un écran LG HDR), et d'activer le mode HDR dans les paramètres d'affichage de Windows.
Les développeurs Web peuvent détecter la gamme de couleurs approximative acceptée par l'appareil de sortie à l'aide de la requête média couleur-gamut récente et du nombre de bits utilisés pour afficher une couleur à l'écran avec screen.colorDepth. Voici une façon de les utiliser pour détecter si le format VP9 HDR est compatible, par exemple:
// Detect if display is in HDR mode and if browser supports VP9 HDR.
function canPlayVp9Hdr() {
// TODO: Adjust VP9 codec string based on your video encoding properties.
return (window.matchMedia('(color-gamut: p3)').matches &&
screen.colorDepth >= 48 &&
MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01"'))
}
La chaîne de codec VP9 avec le profil 2 transmise à isTypeSupported() dans l'exemple ci-dessus doit être mise à jour en fonction de vos propriétés d'encodage vidéo.
Notez qu'il n'est pas encore possible de définir des couleurs HDR en CSS, canvas, images et contenus protégés. L'équipe Chrome travaille à sa résolution. mais revenez plus tard !
Licences persistantes pour Windows et Mac
La licence persistante dans les extensions multimédias chiffrées (EME) signifie que la licence peut être conservée sur l'appareil afin que les applications puissent la charger en mémoire sans envoyer une autre demande de licence au serveur. Voici comment la lecture hors connexion est disponible dans l'EME.
Jusqu'à présent, ChromeOS et Android étaient les seules plates-formes compatibles avec les licences persistantes. Ce n'est plus vrai. La lecture de contenu protégé via EME lorsque l'appareil est hors connexion est désormais possible dans Chrome 64 sur Windows et Mac.
const config = [{
sessionTypes: ['persistent-license'],
videoCapabilities: [{
contentType: 'video/webm; codecs="vp09.00.10.08"',
robustness: 'SW_SECURE_DECODE' // Widevine L3
}]
}];
navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(access => {
// User will be able to watch encrypted content while being offline when
// license is stored locally on device and loaded later.
})
.catch(error => {
// Persistent licenses are not supported on this platform yet.
});
Vous pouvez essayer vous-même les licences persistantes en consultant l'exemple de PWA Media et en procédant comme suit:
- Accédez à https://biograf-155113.appspot.com/ttt/episode-2/.
- Cliquez sur "Rendre disponible hors connexion", puis attendez que le téléchargement de la vidéo soit terminé.
- Désactivez votre connexion Internet.
- Cliquez sur le bouton de lecture et profitez de la vidéo !
Le préchargement des contenus multimédias est défini par défaut sur "metadata"
Comme pour les implémentations d'autres navigateurs, Chrome pour ordinateur définit désormais la valeur de préchargement par défaut sur "metadata" pour les éléments <video> et <audio> afin de réduire l'utilisation de la bande passante et des ressources. À partir de Chrome 64, ce nouveau comportement ne s'applique qu'aux cas où aucune valeur de préchargement n'est définie. Notez que l'indice de l'attribut de préchargement est supprimé lorsqu'un MediaSource est associé à l'élément multimédia, car le site Web gère son propre préchargement.
En d'autres termes, la valeur de préchargement <video> est désormais "metadata", tandis que la valeur de préchargement <video
preload="auto"> reste "auto". Essayez l'exemple officiel.
Intention de livraison | Outil de suivi de l'état de Chrome | Bug Chromium
Une exception est générée
Suite à une modification de la spécification HTML, lorsque la valeur playbackRate des éléments multimédias est définie sur une valeur non compatible avec Chrome (par exemple, une valeur négative), une "NotSupportedError" DOMException est générée dans Chrome 63.
const audio = document.querySelector('audio');
try {
audio.playbackRate = -1;
} catch(error) {
console.log(error.message); // Failed to set the playbackRate property
}
À ce propos, l'implémentation actuelle de Chrome génère cette exception lorsque playbackRate est soit négatif, inférieur à 0,0625, ou supérieur à 16. Essayez l'exemple officiel pour observer son fonctionnement.
Intention de livraison | Outil de suivi de l'état de Chrome | Bug Chromium
Optimisations des pistes vidéo en arrière-plan
L'équipe Chrome cherche toujours de nouvelles façons d'améliorer l'autonomie de la batterie, et Chrome 63 ne fait pas exception.
Si la vidéo ne contient aucune piste audio, elle est automatiquement mise en pause lorsqu'elle est lue en arrière-plan (par exemple, dans un onglet non visible) dans Chrome pour ordinateur (Windows, Mac, Linux et ChromeOS). Cet article fait suite à une modification similaire qui ne s'appliquait qu'aux vidéos MSE dans Chrome 62.
Supprimer la désactivation du son pour les taux de lecture extrêmes
Avant Chrome 64, le son était coupé lorsque playbackRate était inférieur à 0,5 ou supérieur à 4, car la qualité se détériorait considérablement. Étant donné que Chrome est passé à l'approche WSOLA (Waveform-Similarity-Overlap-Add) pour dégrader la qualité, il n'est plus nécessaire de couper le son. Cela signifie que vous pouvez maintenant jouer
avec un son très lent et très rapide.