- 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 sous Windows 10.
- La lecture hors connexion avec des licences persistantes est désormais disponible sur 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 des contenus multimédias n'est pas acceptée.
- Chrome met désormais en pause tous les contenus multimédias vidéo uniquement en arrière-plan.
- Le son n'est plus coupé en cas de taux de lecture extrême.
Fonctionnalités multimédias : API Decoding Info
Aujourd'hui, les développeurs Web s'appuient sur isTypeSupported() ou canPlayType() pour savoir vaguement si certains contenus multimédias peuvent être décodés ou non. La vraie question devrait toutefois être : "Comment cet appareil fonctionnera-t-il ?"
C'est précisément l'un des problèmes que les capacités multimédias proposées visent à résoudre : une API permettant d'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, les débits, etc. Elle exposerait des informations telles que la fluidité et l'efficacité énergétique de la lecture en fonction des statistiques de lecture précédentes enregistrées par le navigateur.
Voici un résumé du fonctionnement de l'API Decoding Info pour le moment. Consultez l'exemple 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'à trouver la meilleure (smooth et powerEfficient) et l'utiliser pour lire le flux multimédia approprié. Par ailleurs, l'implémentation actuelle de Chrome est basée sur des informations de lecture enregistrées précédemment. Il définit smooth comme "true" lorsque le pourcentage de trames perdues est inférieur à 10 %, tandis que powerEfficient est défini sur "true" lorsque plus de 50 % des trames sont décodées par le matériel. Les petits cadres sont toujours considérés comme économes en énergie.
Nous vous recommandons d'utiliser un extrait semblable à celui ci-dessous pour détecter la disponibilité et 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 essais d'origine
Afin de recueillir autant de commentaires que possible de la part des développeurs qui utilisent l'API Decoding Info (qui fait partie des fonctionnalités multimédias) dans le domaine, nous avons précédemment ajouté cette fonctionnalité dans Chrome 64 en tant qu'essai Origin Trial.
L'essai a bien été terminé en avril 2018.
Intent to Experiment | Intent to Ship | Chromestatus Tracker | Bug Chromium
Lecture de vidéos HDR sous Windows 10
Les vidéos HDR (High Dynamic Range) offrent un contraste plus élevé, révélant des ombres précises et détaillées et des tons clairs époustouflants avec plus de clarté que jamais. De plus, la prise en charge de la large gamme de couleurs permet d'obtenir des couleurs plus vives.
Étant donné que la lecture 10 bits du VP9 Profile 2 est désormais prise en charge dans Chrome pour Windows 10 Fall Creator Update, Chrome prend également en charge la lecture de vidéos HDR lorsque Windows 10 est en mode HDR. Note technique : Chrome 64 est désormais compatible avec le profil de couleur scRGB, ce qui permet de lire des contenus multimédias en HDR.
Vous pouvez essayer en regardant Le monde en HDR en 4K (ULTRA HD) sur YouTube et vérifier que la lecture est en HDR en consultant le paramètre de qualité du lecteur YouTube.
Pour le moment, tout ce dont vous avez besoin est la mise à jour Fall Creators de Windows 10, une carte graphique et un écran compatibles HDR (par exemple, une carte NVIDIA de la série 10, un téléviseur ou 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 prise en charge par l'appareil de sortie avec la requête multimédia de gamme de couleurs récente et le nombre de bits utilisés pour afficher une couleur à l'écran avec screen.colorDepth. Voici un moyen d'utiliser ces éléments pour détecter si le HDR VP9 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 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 dans CSS, Canvas, les images et les contenus protégés. L'équipe Chrome y travaille. Tenez-vous informé !
Licences persistantes pour Windows et Mac
Une 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. C'est ainsi que la lecture hors connexion est prise en charge dans EME.
Jusqu'à présent, ChromeOS et Android étaient les seules plates-formes compatibles avec les licences persistantes. Ce n'est plus le cas. La lecture de contenus protégés 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 les licences persistantes vous-même en consultant l'exemple de PWA multimédia et en procédant comme suit :
- Accédez à https://biograf-155113.appspot.com/ttt/episode-2/.
- Cliquez sur "Rendre disponible hors connexion", puis patientez jusqu'à ce que la vidéo soit téléchargée.
- Désactivez votre connexion Internet.
- Cliquez sur le bouton de lecture et profitez de la vidéo !
La valeur par défaut du préchargement multimédia est "metadata".
Pour s'adapter aux implémentations d'autres navigateurs, Chrome pour ordinateur définit désormais la valeur de préchargement par défaut pour les éléments <video> et <audio> sur "metadata" afin de réduire la bande passante et l'utilisation 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 la suggestion de l'attribut de préchargement est supprimée 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 de <video> est désormais "metadata", tandis que la valeur de préchargement de <video
preload="auto"> reste "auto". Essayez l'exemple officiel.
Intent to Ship | Outil de suivi de l'état de Chrome | Bug Chromium
La valeur playbackRate non prise en charge génère une exception
Suite à une modification de la spécification HTML, lorsque le playbackRate des éléments multimédias est défini sur une valeur non compatible avec Chrome (par exemple, une valeur négative), une DOMException "NotSupportedError" 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
}
Par ailleurs, l'implémentation actuelle de Chrome génère cette exception lorsque playbackRate est négatif, inférieur à 0,0625 ou supérieur à 16. Essayez l'exemple officiel pour voir comment cela fonctionne.
Intent to Ship | Outil de suivi de l'état de Chrome | Bug Chromium
Optimisations des pistes vidéo en arrière-plan
L'équipe Chrome essaie toujours de trouver 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). Il s'agit d'une modification similaire qui ne s'appliquait qu'aux vidéos MSE dans Chrome 62.
Supprimer le masquage pour les vitesses de lecture extrêmes
Avant Chrome 64, le son était coupé lorsque la valeur de playbackRate était inférieure à 0,5 ou supérieure à 4, car la qualité se dégradait considérablement. Comme Chrome a adopté une 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 lire le son très lentement et très rapidement.