Medienupdates in Chrome 63/64

François Beaufort
François Beaufort

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.

Vergleich von simuliertem SDR und HDR (für echtes HDR-Bild ist ein HDR-Display erforderlich)
Vergleich zwischen simuliertem SDR und HDR (für das echte HDR-Bild ist ein HDR-Display erforderlich)

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.

Einstellung für die YouTube-Player-Qualität mit HDR
YouTube-Player-Qualitätseinstellung mit HDR

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:

  1. Rufen Sie https://biograf-155113.appspot.com/ttt/episode-2/ auf.
  2. Klicke auf "Offline verfügbar machen" und warte, bis das Video heruntergeladen wurde.
  3. Deaktiviere deine Internetverbindung.
  4. 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.

Chromium-Programmfehler

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.

Chromium-Programmfehler