Medienupdates in Chrome 63/64

François Beaufort
François Beaufort
GitHub

Medienfunktionen – Decoding Info API

Heutzutage verlassen sich Webentwickler nur vage auf isTypeSupported() oder canPlayType() ob bestimmte Medien decodiert werden können. Die eigentliche Frage sollte jedoch lauten: „Wie gut würde sie auf diesem Gerät funktionieren?“

Genau eines der Ziele, das mit den vorgeschlagenen Medienfunktionen erreicht werden soll, Lösen: eine API, mit der der Browser nach den Decodierungsfunktionen des Geräts abgefragt werden kann basierend auf Informationen wie Codecs, Profil, Auflösung, Bitraten usw. würden Informationen offengelegt, wie z. B. ob die Wiedergabe flüssig und flüssig basierend auf zuvor vom Browser aufgezeichneten Wiedergabestatistiken.

Hier sehen Sie in aller Kürze, wie die Decoding Info API vorerst funktioniert. In der offizielles Beispiel.

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 beste gefunden haben (smooth und powerEfficient) und damit die entsprechenden Medien abspielen . Die aktuelle Implementierung von Chrome basiert übrigens Informationen zur aufgezeichneten Wiedergabe. Sie definiert smooth als „true“, wenn der Prozentsatz der verworfenen Frames liegt bei weniger als 10 %, während powerEfficient wahr ist, wenn als 50% der Frames von der Hardware decodiert werden. Kleine Frames sind immer als energieeffizient betrachtet wird.

Ich empfehle Ihnen, ein Snippet wie das folgende zu verwenden, und auf Ihre aktuelle Implementierung für Browser zurückgreifen, diese API nicht unterstützt.

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 so viel Feedback wie möglich von Entwicklern zu erhalten, die die Decodierung verwenden Info API (Teil der Medienfunktionen) in das Feld ein, haben wir bereits in Chrome 64 als Ursprungstest verwenden.

Der Testzeitraum endete im April 2018.

Experimentelle Absicht | Versandabsicht | Chromestatus-Tracker | Chromium-Programmfehler

HDR-Videowiedergabe unter Windows 10

HDR-Videos (High Dynamic Range) haben einen höheren Kontrast, sodass detaillierte Schatten und atemberaubende Spitzlichter mit mehr Klarheit als je zuvor. Außerdem Die Unterstützung eines breiten Farbraums sorgt dafür, dass die Farben lebendiger sind.

<ph type="x-smartling-placeholder">
</ph> Vergleich zwischen simuliertem SDR und HDR (Real-HDR erfordert ein HDR-Display) <ph type="x-smartling-placeholder">
</ph> Vergleich zwischen simuliertem SDR und HDR (Real-HDR erfordert ein HDR-Display)

VP9 Profile 2: 10-Bit-Wiedergabe in Chrome für Windows 10 im Herbst Creator-Update unterstützt Chrome zusätzlich die HDR-Videowiedergabe bei Windows 10 im HDR-Modus ist. Technischer Hinweis: Chrome 64 unterstützt jetzt die Farbe scRGB. sodass Medien in HDR wiedergegeben werden können.

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

<ph type="x-smartling-placeholder">
</ph> Qualitätseinstellung des YouTube-Players mit HDR <ph type="x-smartling-placeholder">
</ph> Qualitätseinstellung des YouTube-Players mit HDR

Alles, was du jetzt brauchst, ist das mit HDR kompatible Windows 10 Herbst-Update Grafikkarte und Display (z.B. NVIDIA 10-Serie-Karte, LG HDR-Fernseher oder -Monitor) und aktiviere den HDR-Modus in den Windows-Anzeigeeinstellungen.

Webentwickler können die ungefähre Farbgamut ermitteln, die von der Ausgabe unterstützt wird Gerät mit der letzten color-gamut-Medienabfrage und der Anzahl der Bits, die für zeigt eine Farbe auf dem Bildschirm mit screen.colorDepth an. Hier ist eine Möglichkeit, zum 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 wird an isTypeSupported() im Beispiel oben muss entsprechend Ihren Videocodierungseigenschaften aktualisiert werden.

Es ist noch nicht möglich, HDR-Farben in CSS, Canvas Bilder und geschützte Inhalte. Das Chrome-Team arbeitet daran. Mehr dazu demnächst!

Persistente Lizenzen für Windows und Mac

Eine persistente Lizenz in Encrypted Media Extensions (EME) bedeutet, dass die Lizenz auf dem Gerät gespeichert werden, sodass Anwendungen die Lizenz in ohne eine weitere Lizenzanfrage an den Server zu senden. So die Offlinewiedergabe in EME unterstützt wird.

Bis jetzt waren ChromeOS und Android die einzigen Plattformen, die die dauerhafte Nutzung Lizenzen. Das stimmt nicht mehr. Wiedergabe geschützter Inhalte über EME während Das Gerät 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.
});

Sie können persistente Lizenzen selbst testen. Sehen Sie sich dazu die Beispiel-Media-PWA an. und führen Sie folgende Schritte aus:

  1. Rufen Sie https://biograf-155113.appspot.com/ttt/episode-2/ auf.
  2. Klicken Sie auf „Offline verfügbar machen“. und warte, bis das Video heruntergeladen wurde.
  3. Deaktivieren Sie die Internetverbindung.
  4. Klicke auf die Wiedergabeschaltfläche und Viel Spaß mit dem Video!

Medien-Vorabladen wird standardmäßig auf „metadata“ gesetzt

Übereinstimmung mit anderen Browsern wird die Chrome-Desktop-App Laden Sie den Wert für die Elemente <video> und <audio> vorab auf "metadata", um die Bandbreiten- und Ressourcennutzung reduzieren. Ab Chrome 64 gilt dieses neue Verhalten nur noch wenn kein Wert für das Vorabladen festgelegt ist. Beachten Sie, dass das Attribut Der Hinweis wird verworfen, wenn MediaSource als Element an das Medienelement angehängt wird. übernimmt das Vorabladen der Website selbst.

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

Versandabsicht | Chromestatus-Tracker | Chromium-Fehler

Nicht unterstützte „playRate“ löst eine Ausnahme aus

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

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 ist entweder negativ, kleiner als 0, 0625 oder größer als 16. Ausprobieren zum offiziellen Beispiel um dies in Aktion zu sehen.

Versandabsicht | Chromestatus-Tracker | Chromium-Fehler

Optimierung von Videotracks im Hintergrund

Das Chrome-Team sucht ständig nach neuen Möglichkeiten, die Akkulaufzeit und Chrome 63 war da keine Ausnahme.

Wenn das Video keine Audiotracks enthält, wird es automatisch abgespielt. Bei Hintergrundwiedergabe in Chrome (z.B. auf einem nicht sichtbaren Tab) pausiert Desktop-Computer (Windows, Mac, Linux und ChromeOS) Dies ist ein Follow-up von einem eine ähnliche Änderung, die nur für MSE-Videos in Chrome 62 galt.

Fehler in Chromium

Stummschalten 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 eine WSOLA-Ansatz (Waveform-Similarity-Overlap-Add) für Qualitätseinbußen, Ton muss nicht mehr stummgeschaltet werden. Das bedeutet, dass Sie den Ton extrem langsam und jetzt superschnell.

Fehler in Chromium