- Webentwickler können jetzt vorhersagen, ob die Wiedergabe reibungslos und energieeffizient verläuft.
- Chrome unterstützt jetzt die HDR-Videowiedergabe unter Windows 10.
- Die Offline-Wiedergabe mit dauerhaften Lizenzen wird jetzt auf Windows und Mac unterstützt.
- Der Standardwert für das Vorabladen für die Elemente
<video>
und<audio>
ist jetzt"metadata"
. - Wenn jetzt die Medienwiedergaberate nicht unterstützt wird, wird jetzt ein Fehler ausgegeben.
- Chrome pausiert jetzt alle Medien im Hintergrund.
- Der Ton ist für eine extrem hohe Wiedergaberate nicht mehr stummgeschaltet.
Medienfunktionen – Decoding Info API
Heutzutage verlassen sich Webentwickler auf isTypeSupported()
oder canPlayType()
, um vage zu wissen, ob bestimmte Medien decodiert werden können oder nicht. Die eigentliche Frage sollte jedoch lauten:
„Wie gut funktioniert es auf diesem Gerät?“
Dies ist genau eines der Aufgaben, die die vorgeschlagenen Medienfunktionen lösen möchten: eine API, die den Browser anhand von Informationen wie Codecs, Profil, Auflösung, Bitraten usw. nach den Decodierungsfähigkeiten des Geräts abfragen kann. Anhand der zuvor vom Browser aufgezeichneten Wiedergabestatistiken werden beispielsweise Informationen darüber offengelegt, ob die Wiedergabe reibungslos und energieeffizient sein sollte.
Hier sehen Sie kurz, wie die Decoding Info API vorerst funktioniert. Sehen Sie sich dazu das offizielle Beispiel an.
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.');
});
Sie können verschiedene Medienkonfigurationen ausprobieren, bis Sie die am besten geeignete (smooth
und powerEfficient
) gefunden haben, und damit den entsprechenden Medienstream wiedergeben. Übrigens basiert die aktuelle Implementierung von Chrome auf zuvor aufgezeichneten Wiedergabeinformationen. Sie definiert smooth
als „true“, wenn der Prozentsatz der abgebrochenen Frames weniger als 10% beträgt. powerEfficient
ist „true“, wenn mehr als 50% der Frames von der Hardware decodiert werden. Kleine Frames gelten immer
als energieeffizient.
Ich empfehle Ihnen, ein Snippet wie das folgende zu verwenden, um die Verfügbarkeit zu ermitteln und auf Ihre aktuelle Implementierung für Browser zurückzugreifen, die diese API nicht unterstützen.
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;
});
}
Verfügbar für Ursprungstests
Um möglichst viel Feedback von Entwicklern zu erhalten, die die Decoding Info API (Teil von Media Capabilities) verwenden, haben wir diese Funktion zuvor in Chrome 64 als Ursprungstest hinzugefügt.
Der Testzeitraum endete im April 2018.
Intent to Experiment | Intent to Ship | Chromestatus-Tracker | Chromium-Fehler
HDR-Videowiedergabe unter Windows 10
HDR-Videos (High Dynamic Range) haben einen höheren Kontrast und ermöglichen präzise, detaillierte Schatten und atemberaubende Spitzlichter mit mehr Schärfe als je zuvor. Darüber hinaus bedeutet die Unterstützung eines breiten Farbraums, dass die Farben kräftiger sind.
Da die 10-Bit-Wiedergabe von VP9 Profil 2 in Chrome für Windows 10 Fall Creator Update unterstützt wird, unterstützt Chrome zusätzlich die HDR-Videowiedergabe, wenn Windows 10 im HDR-Modus ist. Technischer Hinweis: Chrome 64 unterstützt jetzt das Farbprofil scRGB, das wiederum die Wiedergabe von Medien in HDR ermöglicht.
Du kannst es ausprobieren, indem du dir auf YouTube Die Welt in HDR in 4K (ULTRA HD) ansiehst. Prüfe in der Qualitätseinstellung des YouTube-Players, ob HDR wiedergegeben wird.
Fürs Erste brauchen Sie nur das Windows 10 Fall Creator Update, eine HDR-kompatible Grafikkarte und ein HDR-kompatibles Display (z.B. eine NVIDIA-Karte der 10-Serie, einen LG HDR-Fernseher oder einen Monitor) und den HDR-Modus in den Windows-Anzeigeeinstellungen zu aktivieren.
Webentwickler können den ungefähren Farbraum ermitteln, der vom Ausgabegerät unterstützt wird. Dazu wird die aktuelle Medienabfrage für Farbgamut und die Anzahl der Bits verwendet, die zur Darstellung einer Farbe auf dem Bildschirm mit screen.colorDepth verwendet wurden. Hier ist eine Möglichkeit, um herauszufinden, ob VP9 HDR unterstützt wird:
// 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"'))
}
Der im Beispiel oben an isTypeSupported()
übergebene VP9-Codec-String mit Profil 2 muss basierend auf den Videocodierungseigenschaften aktualisiert werden.
Es ist noch nicht möglich, HDR-Farben in CSS, Canvas, Bildern und geschützten Inhalten zu definieren. Das Chrome-Team arbeitet an einer Lösung. Mehr dazu demnächst!
Dauerhafte Lizenzen für Windows und Mac
Eine persistente Lizenz in Encrypted Media Extensions (EME) bedeutet, dass die Lizenz auf dem Gerät beibehalten werden kann, sodass Anwendungen die Lizenz in den Arbeitsspeicher laden können, ohne eine weitere Lizenzanfrage an den Server zu senden. So wird die Offline-Wiedergabe in EME unterstützt.
Bisher waren ChromeOS und Android die einzigen Plattformen, die persistente Lizenzen unterstützen. Das stimmt nicht mehr. Das Abspielen geschützter Inhalte über EME im Offlinemodus ist jetzt in Chrome 64 auch für Windows und Mac möglich.
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.
});
Sie können persistente Lizenzen selbst testen. Dazu sehen Sie sich die Beispielmedien-PWA an und gehen so vor:
- Rufen Sie https://biograf-155113.appspot.com/ttt/episode-2/ auf.
- Klicke auf "Offline verfügbar machen" und warte, bis das Video heruntergeladen wurde.
- Deaktiviere deine Internetverbindung.
- Klicke auf die Wiedergabeschaltfläche und sieh dir das Video an.
Vor dem Laden von Medien wird standardmäßig „metadata“ verwendet
Entsprechend den Implementierungen anderer Browser wird in der Chrome-Desktop-App jetzt der Standardwert für das Vorabladen für die Elemente <video>
und <audio>
auf "metadata"
festgelegt, um die Bandbreite und die Ressourcennutzung zu reduzieren. Ab Chrome 64 gilt dieses neue Verhalten nur dann, wenn kein Wert für das Vorabladen festgelegt ist. Der Hinweis des Preload-Attributs wird verworfen, wenn ein MediaSource
an das Medienelement angehängt wird, da die Website ihr eigenes Vorabladen verarbeitet.
Mit anderen Worten: Der Vorladewert von <video>
beträgt jetzt "metadata"
, während der Vorladewert von <video
preload="auto">
bei "auto"
bleibt. Dann probiere das offizielle Hörprobe aus.
Intent to Ship | Chromestatus-Tracker | Chromium-Fehler
Wenn die Wiedergaberate nicht unterstützt wird, wird eine Ausnahme ausgelöst
Wenn das playbackRate
der Medienelemente nach einer Änderung der HTML-Spezifikation auf einen von Chrome nicht unterstützten Wert gesetzt ist (z.B. ein negativer Wert), wird in Chrome 63 ein "NotSupportedError"
-DOMException
ausgelöst.
const audio = document.querySelector('audio');
try {
audio.playbackRate = -1;
} catch(error) {
console.log(error.message); // Failed to set the playbackRate property
}
Übrigens löst die aktuelle Implementierung von Chrome diese Ausnahme aus, wenn playbackRate
entweder negativ, kleiner als 0, 0625 oder größer als 16 ist. Probieren Sie das offizielle Beispiel aus, um dies in Aktion zu sehen.
Intent to Ship | Chromestatus-Tracker | Chromium-Fehler
Optimierung von Videotracks im Hintergrund
Das Chrome-Team ist immer auf der Suche nach neuen Möglichkeiten, die Akkulaufzeit zu verlängern. Chrome 63 war da keine Ausnahme.
Wenn das Video keine Audiotracks enthält, wird es bei der Hintergrundwiedergabe (z.B. auf einem nicht sichtbaren Tab) in Chrome für Computer (Windows, Mac, Linux und ChromeOS) automatisch angehalten. Dies ist eine Folge einer ähnlichen Änderung, die nur für MSE-Videos in Chrome 62 galt.
Stummschaltung bei extremer Wiedergabegeschwindigkeit entfernen
Vor Chrome 64 wurde der Ton stummgeschaltet, wenn playbackRate
unter 0,5 oder über 4 lag, da sich die Qualität erheblich verschlechtert hat. Da Chrome zur Qualitätsverschlechterung auf den WSOLA-Ansatz (Waveform-Relatedity-Overlap-Add) umgestiegen ist, muss der Ton nicht mehr stummgeschaltet werden. So können Sie Sound jetzt
superlangsam und superschnell abspielen.