Medienupdates in Chrome 63/64

François Beaufort
François Beaufort
GitHub

Media Capabilities – Decoding Info API

Heute nutzen Webentwickler isTypeSupported() oder canPlayType(), um ungefähr zu wissen, ob bestimmte Medien decodiert werden können oder nicht. Die eigentliche Frage sollte jedoch lauten: „Wie gut würde es auf diesem Gerät funktionieren?“

Genau das soll mit den vorgeschlagenen Media Capabilities gelöst werden: Eine API, die den Browser anhand von Informationen wie Codecs, Profil, Auflösung, Bitrate usw. zu den Dekodierungsfunktionen des Geräts befragt. So können Informationen wie die Frage, ob die Wiedergabe flüssig und energieeffizient sein soll, anhand der vom Browser erfassten bisherigen Wiedergabestatistiken offengelegt werden.

Hier sehen Sie in aller Kürze, wie die Decoding Info API vorerst funktioniert. Sehen Sie sich 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.');
});

Du kannst verschiedene Medienkonfigurationen ausprobieren, bis du die beste gefunden hast (smooth und powerEfficient), und mit dieser den entsprechenden Medienstream abspielen. Die aktuelle Implementierung von Chrome basiert übrigens auf zuvor aufgezeichneten Wiedergabeinformationen. Er definiert smooth als „true“, wenn der Prozentsatz der verworfenen Frames weniger als 10% beträgt, während powerEfficient „true“ ist, wenn mehr als 50% der Frames von der Hardware decodiert werden. Kleine Frames gelten immer als energieeffizient.

Ich empfehle, ein Snippet ähnlich dem unten stehenden zu verwenden, um die Verfügbarkeit zu prüfen und bei Browsern, die diese API nicht unterstützen, auf Ihre aktuelle Implementierung zurückzugreifen.

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 der Media Capabilities) in der Praxis verwenden, haben wir diese Funktion bereits 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 zeigen präzise, detaillierte Schatten und beeindruckende Lichter mit mehr Klarheit als je zuvor. Außerdem werden Farben durch die Unterstützung eines breiten Farbraums lebendiger dargestellt.

Simulierter Vergleich zwischen SDR und HDR (für echtes HDR ist ein HDR-Display erforderlich)
Vergleich zwischen simuliertem SDR und HDR (Real-HDR erfordert ein HDR-Display)

Da die 10-Bit-Wiedergabe von VP9-Profil 2 jetzt in Chrome für das Windows 10-Fall Creators Update unterstützt wird, unterstützt Chrome zusätzlich die Wiedergabe von HDR-Videos, wenn Windows 10 im HDR-Modus ist. Hinweis: Chrome 64 unterstützt jetzt das Farbprofil scRGB, wodurch Medien in HDR wiedergegeben werden können.

Probier es doch mal aus: Sieh dir Die Welt in HDR in 4K (ULTRA HD) auf YouTube an und prüfe in den Qualitätseinstellungen des YouTube-Players, ob HDR wiedergegeben wird.

Qualitätseinstellung des YouTube-Videoplayers mit HDR
Qualitätseinstellung des YouTube-Players mit HDR

Du benötigst nur das Windows 10 Fall Creator Update, eine HDR-kompatible Grafikkarte und ein HDR-kompatibles Display (z. B. eine NVIDIA-Grafikkarte der 10er-Reihe, ein LG-HDR-Fernseher oder -Monitor) und musst den HDR-Modus in den Windows-Displayeinstellungen aktivieren.

Webentwickler können mit der neuen Mediaabfrage für den Farbraum den ungefähren Farbraum ermitteln, der vom Ausgabegerät unterstützt wird, und mit screen.colorDepth die Anzahl der Bits, die zum Darstellen einer Farbe auf dem Bildschirm verwendet werden. So kannst du beispielsweise prüfen, 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 VP9-Codec-String mit Profil 2, der im Beispiel oben an isTypeSupported() übergeben wird, muss anhand deiner Videocodierungseigenschaften aktualisiert werden.

HDR-Farben in CSS, Canvas, Bildern und geschützten Inhalten können noch nicht definiert werden. Das Chrome-Team arbeitet daran. 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 gespeichert werden kann, damit Anwendungen die Lizenz in den Arbeitsspeicher laden können, ohne eine weitere Lizenzanfrage an den Server zu senden. So wird die Offlinewiedergabe in EME unterstützt.

Bisher waren ChromeOS und Android die einzigen Plattformen, die persistente Lizenzen unterstützten. Das ist nicht mehr der Fall. Das Abspielen geschützter Inhalte über EME, während das Gerät offline ist, ist jetzt auch in Chrome 64 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.
});

Du kannst persistente Lizenzen selbst ausprobieren. Lade dazu die Beispiel-Media-PWA herunter und folge dieser Anleitung:

  1. Rufe https://biograf-155113.appspot.com/ttt/episode-2/ auf.
  2. Klicke auf „Offline verfügbar machen“ und warte, bis das Video heruntergeladen wurde.
  3. Deaktivieren Sie die Internetverbindung.
  4. Klicke auf die Schaltfläche „Wiedergabe“ und genieße das Video.

Standardmäßig ist „metadata“ für das Vorladen von Medien festgelegt.

Entsprechend der Implementierung anderer Browser wird in der Chrome-Desktop-App jetzt der Standardwert für das Vorabladen von <video>- und <audio>-Elementen auf "metadata" festgelegt, um die Bandbreite und die Ressourcennutzung zu reduzieren. Ab Chrome 64 gilt dieses neue Verhalten nur, wenn kein Vorab-Ladewert festgelegt ist. Der Hinweis des Preload-Attributs wird verworfen, wenn ein MediaSource an das Medienelement angehängt wird, da die Website das eigene Vorabladen übernimmt.

Mit anderen Worten: Der Preloading-Wert für <video> ist jetzt "metadata", während der Preloading-Wert für <video preload="auto"> bei "auto" bleibt. Probieren Sie das offizielle Beispiel aus.

Intent to Ship | Chromestatus-Tracker | Chromium-Fehler

Nicht unterstützte Wiedergabegeschwindigkeit löst eine Ausnahme aus

Nach einer Änderung der HTML-Spezifikation wird in Chrome 63 eine "NotSupportedError" DOMException geworfen, wenn die playbackRate von Medienelementen auf einen Wert festgelegt ist, der von Chrome nicht unterstützt wird (z. B. ein negativer Wert).

const audio = document.querySelector('audio');
try {
  audio.playbackRate = -1;
} catch(error) {
  console.log(error.message); // Failed to set the playbackRate property
}

Übrigens: In der aktuellen Chrome-Implementierung wird diese Ausnahme ausgelöst, wenn playbackRate negativ, kleiner als 0,0625 oder größer als 16 ist. Probieren Sie das offizielle Beispiel aus, um dies in der Praxis zu sehen.

Intent to Ship | Chromestatus-Tracker | Chromium-Fehler

Optimierung von Videotracks im Hintergrund

Das Chrome-Team sucht immer nach neuen Möglichkeiten, die Akkulaufzeit zu verbessern. Chrome 63 ist da keine Ausnahme.

Wenn das Video keine Audiotracks enthält, wird es in Chrome für Computer (Windows, Mac, Linux und ChromeOS) automatisch pausiert, wenn es im Hintergrund (z. B. auf einem ausgeblendeten Tab) wiedergegeben wird. Diese Änderung ist eine Folge einer ähnlichen Änderung, die nur für MSE-Videos in Chrome 62 galt.

Chromium-Fehler

Stummschaltung bei extremen Wiedergaberaten aufheben

Vor Chrome 64 wurde der Ton stummgeschaltet, wenn der Wert für playbackRate unter 0,5 oder über 4 lag, da sich die Qualität erheblich verschlechterte. Da Chrome auf einen WSOLA-Ansatz (Waveform-Similarity-Overlap-Add) umgestellt hat, um die Qualität zu verschlechtern, muss der Ton nicht mehr stummgeschaltet werden. Das bedeutet, dass du den Ton jetzt super langsam und super schnell abspielen kannst.

Chromium-Fehler