- 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 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 du contenu multimédia n'est pas prise en charge.
- Chrome met désormais en pause tous les contenus multimédias vidéo uniquement en arrière-plan.
- Le son n'est plus coupé pour les vitesses de lecture extrêmes.
API Media Capabilities - Decoding Info
Aujourd'hui, les développeurs Web s'appuient sur isTypeSupported() ou canPlayType() pour savoir approximativement si certains contenus multimédias peuvent être décodés ou non. La vraie question devrait plutôt être :
"Quelles seraient ses performances sur cet appareil ?"
C'est précisément l'un des problèmes que la proposition de l'API Media Capabilities vise à 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 binaires, 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.
En résumé, voici comment fonctionne 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 de contenu multimédia jusqu'à trouver la meilleure (smooth et powerEfficient), puis l'utiliser pour lire le flux multimédia approprié. Pour information, l'implémentation actuelle de Chrome est basée sur des informations de lecture enregistrées précédemment. Elle définit smooth comme "true" lorsque le pourcentage d'images abandonnées est inférieur à 10 %, tandis que powerEfficient est défini comme "true" lorsque plus de 50 % des images sont décodées par le matériel. Les petits cadres sont toujours considérés comme économes en énergie.
Je vous recommande d'utiliser un extrait de code 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 tests d'origine
Afin de recueillir le plus de commentaires possible auprès 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 qu'essai Origin Trial.
La période d'essai s'est terminée en avril 2018.
Intent to Experiment | Intent to Ship | Chromestatus Tracker | Chromium Bug
Lecture de vidéos HDR sur Windows 10
Les vidéos HDR (High Dynamic Range) offrent un contraste plus élevé, ce qui permet de révéler des ombres précises et détaillées, ainsi que des tons clairs époustouflants avec une clarté inégalée. De plus, la prise en charge de la large gamme de couleurs signifie que les couleurs sont plus vives.
La lecture VP9 Profile 2 10 bits étant désormais prise en charge dans Chrome pour la mise à jour Windows 10 Fall Creator, Chrome prend également en charge la lecture de vidéos HDR lorsque Windows 10 est en mode HDR. D'un point de vue technique, Chrome 64 est désormais compatible avec le profil de couleur scRGB, qui permet à son tour de lire les contenus multimédias en HDR.
Pour l'essayer, regardez The World in HDR in 4K (ULTRA HD) sur YouTube et vérifiez que la vidéo est lue en HDR en consultant le paramètre de qualité du lecteur YouTube.
Pour l'instant, vous n'avez besoin que de la mise à jour Windows 10 Fall Creators, d'une carte graphique et d'un écran compatibles HDR (par exemple, une carte NVIDIA 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 acceptée par le périphérique de sortie avec la récente requête média color-gamut et le nombre de bits utilisés pour afficher une couleur à l'écran avec screen.colorDepth. Voici une façon d'utiliser ces informations pour détecter si le VP9 HDR est pris en charge, 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 des propriétés d'encodage de votre vidéo.
Notez qu'il n'est pas encore possible de définir des couleurs HDR en CSS, canvas, images et contenu protégé. L'équipe Chrome travaille sur ce problème. Tenez-vous informé !
Licences persistantes pour Windows et Mac
Une licence persistante dans Encrypted Media Extensions (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 prise en charge dans EME.
Jusqu'à présent, ChromeOS et Android étaient les seules plates-formes à prendre en charge les licences persistantes. Ce n'est plus le cas. Il est désormais possible de lire des contenus protégés via EME lorsque l'appareil est hors connexion 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 la PWA d'exemple de contenu multimédia et en procédant comme suit :
- Accédez à https://biograf-155113.appspot.com/ttt/episode-2/.
- Cliquez sur "Rendre disponible hors connexion" et patientez pendant le téléchargement de la vidéo.
- Désactivez votre connexion Internet.
- Cliquez sur le bouton "Lecture" et profitez de la vidéo !
La valeur par défaut du préchargement du contenu multimédia est "metadata"
Conformément aux implémentations des autres navigateurs, Chrome pour ordinateur définit désormais la valeur de préchargement par défaut des é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 l'indication de l'attribut de préchargement est ignoré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 <video> est désormais "metadata", tandis que la valeur de préchargement <video
preload="auto"> reste "auto". Essayez l'exemple officiel.
Intention d'expédition | Outil de suivi Chromestatus | Bug Chromium
Une exception est générée si la valeur playbackRate n'est pas acceptée.
Suite à une modification de la spécification HTML, lorsqu'une valeur non prise en charge par Chrome (par exemple, une valeur négative) est définie pour playbackRate des éléments multimédias, 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
}
À titre d'information, 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.
Intention d'expédition | Outil de suivi Chromestatus | Bug Chromium
Optimisations des pistes vidéo en arrière-plan
L'équipe Chrome s'efforce constamment 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 sera automatiquement mise en pause lorsqu'elle sera lue en arrière-plan (par exemple, dans un onglet non visible) dans Chrome pour ordinateur (Windows, Mac, Linux et ChromeOS). Cette modification fait suite à une modification similaire qui ne s'appliquait qu'aux vidéos MSE dans Chrome 62.
Supprimer la mise en sourdine pour les fréquences 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égradait considérablement. Comme Chrome est passé à une approche Waveform-Similarity-Overlap-Add (WSOLA) pour la dégradation de la qualité, le son n'a plus besoin d'être coupé. Vous pouvez désormais lire le son très lentement ou très rapidement.