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 ist eine kurze Zusammenfassung der Funktionsweise der Decoding Info API: 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. smooth ist wahr, wenn der Prozentsatz der verlorenen Frames unter 10% liegt. powerEfficient ist wahr, 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 deine 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 Test wurde im April 2018 erfolgreich abgeschlossen.

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)
Simulierter Vergleich zwischen SDR und HDR (für echtes HDR ist ein HDR-Display erforderlich)

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.

Sie können es ausprobieren, indem Sie sich Die Welt in HDR in 4K (ULTRA HD) auf YouTube ansehen und in den Qualitätseinstellungen des YouTube-Players prüfen, ob HDR wiedergegeben wird.

Qualitätseinstellung des YouTube-Videoplayers mit HDR
Qualität des YouTube-Players mit HDR-Unterstützung

Alles, was du dafür benötigst, ist 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 die Aktivierung des HDR-Modus in den Windows-Displayeinstellungen.

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. Schalten Sie die Internetverbindung aus.
  4. Klicke auf die Schaltfläche „Wiedergabe“ und genieße das Video.

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

Ähnlich wie bei anderen Browsern wird in Chrome für Desktop-Computer jetzt der Standardwert für das Vorladen von <video>- und <audio>-Elementen auf "metadata" festgelegt, um die Bandbreiten- und Ressourcennutzung zu reduzieren. Ab Chrome 64 gilt dieses neue Verhalten nur, wenn kein Vorab-Ladewert festgelegt ist. Hinweis: Der Hinweis des Attributs „preload“ wird verworfen, wenn dem Medienelement ein MediaSource angehängt ist, da die Website ihr eigenes Preloading verarbeitet.

Mit anderen Worten: Der Preloading-Wert für <video> ist jetzt "metadata", während der Preloading-Wert für <video preload="auto"> weiterhin "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. Im offiziellen Sample kannst du dir das ansehen.

Intent to Ship | Chromestatus-Tracker | Chromium-Fehler

Optimierungen für Hintergrund-Videotracks

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

Ausblendung bei extremen Wiedergaberaten entfernen

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

Chromium-Fehler