- Webontwikkelaars kunnen nu voorspellen of het afspelen soepel en energiezuinig zal verlopen .
- Chrome ondersteunt nu het afspelen van HDR-video 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 fout gegenereerd wanneer de afspeelsnelheid van media niet wordt ondersteund.
- Chrome pauzeert nu alle achtergrondmedia met alleen video .
- Audio wordt niet meer gedempt voor extreme afspeelsnelheid.
Mediamogelijkheden - API voor het decoderen van informatie
Tegenwoordig vertrouwen webontwikkelaars op isTypeSupported() of canPlayType() om vaag te weten of sommige media kunnen worden gedecodeerd of niet. De echte vraag zou echter moeten zijn: "hoe goed zou het presteren op dit apparaat?"
Dit is precies een van de dingen die de voorgestelde Media Capabilities willen oplossen: een API om de browser te ondervragen over de decodeermogelijkheden van het apparaat op basis van informatie zoals de codecs, profiel, resolutie, bitrates, enz. Het zou informatie blootleggen zoals of het afspelen soepel en energiezuinig moet zijn op basis van eerdere afspeelstatistieken die door de browser zijn vastgelegd.
In een notendop is dit hoe de Decoding Info API voorlopig 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.');
});
U kunt verschillende mediaconfiguraties uitproberen totdat u de beste vindt ( 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. Het definieert smooth als true als het percentage verloren frames minder dan 10% bedraagt, terwijl powerEfficient true is als meer dan 50% van de frames door de hardware wordt gedecodeerd. Kleine frames worden altijd als energiezuinig beschouwd.
Ik raad aan een fragment te gebruiken dat lijkt op 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 herkomstproeven
Om zoveel mogelijk feedback te krijgen van ontwikkelaars die in het veld de Decoding Info API (onderdeel van Media Capabilities) gebruiken, hebben we deze functie eerder toegevoegd aan Chrome 64 als origin-proefversie.
De proef is in april 2018 succesvol afgerond.
Intentie om te experimenteren | Intentie om te verzenden | Chromestatustracker | Chroombug
HDR-video afspelen op Windows 10
High Dynamic Range (HDR)-video's hebben een hoger contrast, waardoor nauwkeurige, gedetailleerde schaduwen en verbluffende highlights helderder dan ooit zichtbaar zijn. Bovendien betekent ondersteuning voor een breed kleurengamma dat kleuren levendiger zijn.
Omdat VP9 Profile 2 10-bits afspelen nu wordt ondersteund in Chrome voor Windows 10 Fall Creator Update, ondersteunt Chrome bovendien het afspelen van HDR-video wanneer Windows 10 in de HDR-modus staat . Technisch gezien ondersteunt Chrome 64 nu het scRGB- kleurprofiel, waardoor media kunnen worden afgespeeld in HDR.
Je kunt het proberen door The World in HDR in 4K (ULTRA HD) op YouTube te bekijken en te controleren of HDR wordt afgespeeld door naar de kwaliteitsinstelling van de YouTube-speler te kijken.
Het enige wat je nu nodig hebt is de Windows 10 Fall Creator Update, een HDR-compatibele grafische kaart en beeldscherm (bijv. NVIDIA 10-serie kaart, LG HDR TV of monitor), en schakel de HDR-modus in in de Windows-weergave-instellingen.
Webontwikkelaars kunnen bij benadering het kleurengamma detecteren dat door het uitvoerapparaat wordt ondersteund met de recente mediaquery over het kleurengamma en het aantal bits dat wordt gebruikt om een kleur op het scherm weer te geven met screen.colorDepth . Hier is een manier om deze te gebruiken om bijvoorbeeld te detecteren 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 waarbij Profiel 2 is doorgegeven aan isTypeSupported() in het bovenstaande voorbeeld 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 inhoud . Het Chrome-team werkt eraan. Blijf op de hoogte!
Permanente licenties voor Windows en Mac
Permanente licentie in Encrypted Media Extensions (EME) betekent dat de licentie op het apparaat kan worden gehandhaafd, zodat toepassingen de licentie in het geheugen kunnen laden zonder nog een 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. Het is niet meer waar. Het afspelen van beveiligde inhoud 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 permanente licenties proberen door de Sample Media PWA te bekijken en deze 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!
Voorgeladen media is standaard ingesteld op 'metagegevens'
In overeenstemming met de implementaties van andere browsers stelt Chrome Desktop nu de standaard vooraf geladen waarde voor <video> - en <audio> -elementen in op "metadata" om de bandbreedte en het bronnengebruik te verminderen. Vanaf Chrome 64 is dit nieuwe gedrag alleen van toepassing op gevallen waarin geen vooraf geladen waarde is ingesteld. Houd er rekening mee dat de hint van het preload-attribuut wordt genegeerd wanneer een MediaSource aan het media-element wordt gekoppeld, aangezien de website zijn eigen preload afhandelt.
Met andere woorden: de preloadwaarde <video> is nu "metadata" terwijl <video preload="auto"> preloadwaarde "auto" blijft. Probeer het officiële monster eens.
Intentie om te verzenden | Chromestatustracker | Chroombug
Niet-ondersteunde playbackRate veroorzaakt een uitzondering
Na een wijziging in de HTML-specificatie , wanneer playbackRate van media-elementen is ingesteld op een waarde die niet wordt ondersteund door Chrome (bijvoorbeeld een negatieve waarde), wordt er een "NotSupportedError" DOMException gegenereerd in Chrome 63.
const audio = document.querySelector('audio');
try {
audio.playbackRate = -1;
} catch(error) {
console.log(error.message); // Failed to set the playbackRate property
}
Overigens veroorzaakt de huidige implementatie van Chrome deze uitzondering wanneer playbackRate negatief is, minder dan 0,0625 of meer dan 16. Probeer het officiële voorbeeld eens om dit in actie te zien.
Intentie om te verzenden | Chromestatustracker | Chroombug
Optimalisaties van achtergrondvideotracks
Het Chrome-team probeert altijd nieuwe manieren te vinden om de levensduur van de batterij te verbeteren en 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 op een niet-zichtbaar tabblad) in het Chrome-bureaublad (Windows, Mac, Linux en ChromeOS). Dit is een vervolg op een soortgelijke 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 als playbackRate lager was dan 0,5 of hoger dan 4, omdat de kwaliteit aanzienlijk verslechterde. Omdat Chrome is overgestapt op een Waveform-Similarity-Overlap-Add (WSOLA)-benadering voor kwaliteitsvermindering, hoeft het geluid niet meer te worden gedempt. Het betekent dat je nu super langzaam en super snel geluid kunt afspelen.