- Webontwikkelaars kunnen nu voorspellen of het afspelen vloeiend en energiezuinig zal verlopen .
- Chrome ondersteunt nu HDR-videoweergave op Windows 10 .
- Offline afspelen met permanente licenties wordt nu ondersteund op Windows en Mac.
- De standaard vooraf geladen waarde voor
<video>en<audio>elementen is nu"metadata". - Er wordt nu een foutmelding weergegeven als de afspeelsnelheid van media niet wordt ondersteund.
- Chrome pauzeert nu alle achtergrondmedia met alleen video .
- Audio is niet meer gedempt bij extreme afspeelsnelheid.
Mediamogelijkheden - API voor het decoderen van informatie
Tegenwoordig vertrouwen webontwikkelaars op isTypeSupported() of canPlayType() om vaag te weten of bepaalde media gedecodeerd kunnen worden. De echte vraag zou echter moeten zijn: "hoe goed zou het presteren op dit apparaat?"
Dit is precies een van de problemen die de voorgestelde Media Capabilities wil oplossen: een API om de browser te bevragen over de decodeermogelijkheden van het apparaat op basis van informatie zoals codecs, profiel, resolutie, bitsnelheden, enz. Hiermee zou informatie worden blootgelegd, bijvoorbeeld of het afspelen vloeiend en energiezuinig moet verlopen op basis van eerdere afspeelstatistieken die door de browser zijn geregistreerd.
Kort samengevat, dit is hoe de Decoding Info API momenteel werkt. Bekijk het officiële voorbeeld .
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.');
});
Je kunt verschillende mediaconfiguraties proberen totdat je de beste hebt gevonden ( smooth en powerEfficient ) en deze gebruiken om de juiste mediastream af te spelen. Overigens is de huidige implementatie van Chrome gebaseerd op eerder opgenomen afspeelinformatie. smooth wordt gedefinieerd als 'true' wanneer het percentage verloren frames minder dan 10% is, terwijl powerEfficient 'true' is wanneer meer dan 50% van de frames door de hardware wordt gedecodeerd. Kleine frames worden altijd als energiezuinig beschouwd.
Ik raad u aan een fragment te gebruiken dat vergelijkbaar is met het onderstaande fragment om de beschikbaarheid te detecteren en terug te vallen op uw huidige implementatie voor browsers die deze API niet ondersteunen.
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;
});
}
Beschikbaar voor oorsprongsproeven
Om zoveel mogelijk feedback te krijgen van ontwikkelaars die de Decoding Info API (onderdeel van Media Capabilities) in het veld gebruiken, hebben we deze functie eerder toegevoegd in Chrome 64 als een originele proef.
De rechtszaak werd in april 2018 succesvol afgerond.
Experimenteerintentie | Verzendintentie | Chromestatus Tracker | Chromium-bug
HDR-videoweergave op Windows 10
High Dynamic Range (HDR)-video's hebben een hoger contrast, waardoor precieze, gedetailleerde schaduwen en verbluffende highlights helderder dan ooit worden weergegeven. Bovendien zorgt de ondersteuning voor een breed kleurengamma ervoor dat kleuren levendiger zijn.
Omdat VP9 Profile 2 10-bits weergave nu wordt ondersteund in Chrome voor Windows 10 Fall Creator Update, ondersteunt Chrome ook HDR-videoweergave wanneer Windows 10 in de HDR-modus staat . Technisch gezien ondersteunt Chrome 64 nu het scRGB- kleurprofiel, waardoor media in HDR kunnen worden afgespeeld.
Je kunt het proberen door The World in HDR in 4K (ULTRA HD) op YouTube te bekijken en te controleren of de film HDR kan worden afgespeeld door de kwaliteitsinstellingen van de YouTube-speler te controleren.
Het enige dat u nu nodig hebt, is de Windows 10 Fall Creator Update, een HDR-compatibele grafische kaart en beeldscherm (bijvoorbeeld een NVIDIA 10-serie kaart, LG HDR TV of monitor) en schakel de HDR-modus in via de beeldscherminstellingen van Windows.
Webontwikkelaars kunnen het geschatte kleurengamma dat door het uitvoerapparaat wordt ondersteund, detecteren met de recente media query voor kleurengamma en het aantal bits dat wordt gebruikt om een kleur op het scherm weer te geven met screen.colorDepth . Zo kunt u deze bijvoorbeeld gebruiken om te bepalen of VP9 HDR wordt ondersteund:
// 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"'))
}
De VP9-codecreeks met profiel 2 die in het bovenstaande voorbeeld aan isTypeSupported() is doorgegeven, moet worden bijgewerkt op basis van uw videocoderingseigenschappen.
Houd er rekening mee dat het nog niet mogelijk is om HDR -kleuren te definiëren in CSS , canvas , afbeeldingen en beveiligde content . Het Chrome-team werkt eraan. Blijf op de hoogte!
Blijvende licenties voor Windows en Mac
Persistente licentie in Encrypted Media Extensions (EME) betekent dat de licentie op het apparaat kan worden bewaard, zodat applicaties de licentie in het geheugen kunnen laden zonder een nieuwe licentieaanvraag naar de server te sturen. Dit is hoe offline afspelen wordt ondersteund in EME.
Tot nu toe waren ChromeOS en Android de enige platforms die permanente licenties ondersteunden. Dat is niet langer het geval. Het afspelen van beschermde content via EME terwijl het apparaat offline is, is nu ook mogelijk in Chrome 64 op Windows en 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.
});
U kunt zelf persistente licenties uitproberen door de Sample Media PWA te bekijken en de volgende stappen te volgen:
- Ga naar https://biograf-155113.appspot.com/ttt/episode-2/
- Klik op 'Offline beschikbaar maken' en wacht tot de video is gedownload.
- Schakel uw internetverbinding uit.
- Klik op de knop "Afspelen" en geniet van de video!
Media preload is standaard ingesteld op "metadata"
In overeenstemming met de implementaties van andere browsers stelt Chrome Desktop nu de standaard preloadwaarde voor <video> en <audio> -elementen in op "metadata" om bandbreedte en resourcegebruik te verminderen. Vanaf Chrome 64 is dit nieuwe gedrag alleen van toepassing op gevallen waarin geen preloadwaarde is ingesteld. Houd er rekening mee dat de hint van het preloadkenmerk wordt genegeerd wanneer een MediaSource aan het media-element wordt gekoppeld, omdat de website zijn eigen preload verwerkt.
Met andere woorden, <video> preload-waarde is nu "metadata" terwijl <video preload="auto"> preload-waarde "auto" blijft. Probeer het officiële voorbeeld .
Intentie tot verzending | Chromestatus Tracker | Chromium-bug
Niet-ondersteunde afspeelsnelheid genereert een uitzondering
Na een wijziging in de HTML-specificatie wordt in Chrome 63 een DOMException "NotSupportedError" gegenereerd als playbackRate van media-elementen wordt ingesteld op een waarde die niet door Chrome wordt ondersteund (bijvoorbeeld een negatieve waarde).
const audio = document.querySelector('audio');
try {
audio.playbackRate = -1;
} catch(error) {
console.log(error.message); // Failed to set the playbackRate property
}
Overigens genereert de huidige implementatie van Chrome deze uitzondering wanneer playbackRate negatief, kleiner dan 0,0625 of groter dan 16 is. Probeer het officiële voorbeeld om dit in actie te zien.
Intentie tot verzending | Chromestatus Tracker | Chromium-bug
Optimalisaties van achtergrondvideotracks
Het Chrome-team is altijd op zoek naar nieuwe manieren om de batterijduur te verbeteren. Chrome 63 was daarop geen uitzondering.
Als de video geen audiotracks bevat, wordt de video automatisch gepauzeerd wanneer deze op de achtergrond wordt afgespeeld (bijvoorbeeld in een onzichtbaar tabblad) in Chrome Desktop (Windows, Mac, Linux en ChromeOS). Dit is een vervolg op een vergelijkbare wijziging die alleen van toepassing was op MSE-video's in Chrome 62 .
Verwijder demping voor extreme afspeelsnelheden
Vóór Chrome 64 werd het geluid gedempt wanneer playbackRate lager was dan 0,5 of hoger dan 4, omdat de kwaliteit aanzienlijk afnam. Omdat Chrome is overgestapt op een Waveform- Similarity- Overlap-Add (WSOLA)-aanpak voor kwaliteitsvermindering, hoeft het geluid niet meer gedempt te worden. Dit betekent dat je nu geluid supertraag en supersnel kunt afspelen.