Medienupdates in Chrome 69

François Beaufort
François Beaufort

AV1-Videodecoder

Chromestatus-Tracker | Chromium-Programmfehler

EME: Unterstützung von Verschlüsselungsschemas abfragen

Einige Plattformen oder Schlüsselsysteme unterstützen nur den CENC-Modus, andere nur CBCS-Modus. Wieder andere unterstützen beides. Diese beiden Verschlüsselungsschemata sind inkompatibel, sodass Webentwickler in der Lage sein müssen, intelligente Entscheidungen welche Inhalte bereitgestellt werden sollen.

Um nicht ermitteln zu müssen, auf welcher Plattform sie sich befinden, um nach „bekannt“ zu suchen. Verschlüsselungsschema unterstützt, wird ein neuer encryptionScheme-Schlüssel hinzugefügt in MediaKeySystemMediaCapability-Wörterbuch, mit dem Websites angegeben werden können welches Verschlüsselungsschema in Encrypted Media Extensions (EME) verwendet werden kann.

Der neue encryptionScheme-Schlüssel kann einer von zwei Werten sein:

  • 'cenc': NAL-Teilstichprobenverschlüsselung im AES-CTR-Modus.
  • 'cbcs' Teilvideoverschlüsselung mit NAL-Muster im AES-CBC-Modus.

Wenn keine Angabe erfolgt, bedeutet dies, dass jedes Verschlüsselungsschema akzeptabel ist. Hinweis dass Taste löschen immer das Schema 'cenc' unterstützt.

Das folgende Beispiel zeigt, wie Sie zwei Konfigurationen mit unterschiedlichen Verschlüsselungsschemata. In diesem Fall wird nur eine Option ausgewählt.

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [
    {
      label: 'configuration using the "cenc" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      }],
      initDataTypes: ['keyids']
    },
    {
      label: 'configuration using the "cbcs" encryption scheme',
      videoCapabilities: [{
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      }],
      audioCapabilities: [{
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      }],
      initDataTypes: ['keyids']
    },
  ]);

Im folgenden Beispiel wurde nur eine Konfiguration mit zwei unterschiedlichen Verschlüsselungen abgefragt werden. In diesem Fall verwirft Chrome alle Funktionsobjekte wird nicht unterstützt, sodass die kumulierte Konfiguration möglicherweise genau eine Verschlüsselung oder beides.

await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [{
    videoCapabilities: [
      { // A video capability using the "cenc" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cenc'
      },
      { // A video capability using the "cbcs" encryption scheme
        contentType: 'video/mp4; codecs="avc1.640028"',
        encryptionScheme: 'cbcs'
      },
    ],
    audioCapabilities: [
      { // An audio capability using the "cenc" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cenc'
      },
      { // An audio capability using the "cbcs" encryption scheme
        contentType: 'audio/mp4; codecs="mp4a.40.2"',
        encryptionScheme: 'cbcs'
      },
    ],
    initDataTypes: ['keyids']
  }]);

Implementierungsabsicht | Chromestatus-Tracker | Chromium-Fehler

EME: HDCP-Richtlinienüberprüfung

HDCP ist heutzutage eine gängige Richtlinienanforderung für das Streaming hoher Auflösungen. von geschützten Inhalten. Webentwickler, die eine HDCP-Richtlinie durchsetzen möchten muss entweder warten, bis der Lizenzaustausch abgeschlossen ist, oder mit dem Streaming beginnen Inhalte mit niedriger Auflösung. Es ist wirklich schade, dass die HDCP-Richtlinie Check API löst dieses Problem.

Mit dieser vorgeschlagenen API können Webentwickler abfragen, ob eine bestimmte HDCP-Richtlinie kann erzwungen werden, damit die Wiedergabe mit der optimalen Auflösung für User Experience zu schaffen. Es besteht aus einer einfachen Methode zur Abfrage des Status einen hypothetischen Schlüssel, der mit einer HDCP-Richtlinie verknüpft ist, ohne eine MediaKeySession oder rufen Sie eine echte Lizenz ab. MediaKeys muss nicht Audio- oder Videoelementen verbunden sind.

Die HDCP Policy Check API funktioniert einfach durch Aufrufen mediaKeys.getStatusForPolicy() durch ein Objekt, das einen minHdcpVersion-Schlüssel hat und einen gültigen Wert. Wenn HDCP unter der angegebenen Version verfügbar ist, wird die zurückgegebene Promise löst sich mit einem MediaKeyStatus von 'usable' auf. Andernfalls wird das Versprechen wird mit anderen Fehlerwerten von MediaKeyStatus behoben, z. B. 'output-restricted' oder 'output-downscaled'. Wenn das Schlüsselsystem keine HDCP-Richtlinienprüfung unterstützt (z.B. Clear Key System), wird das Versprechen abgelehnt.

Im Folgenden wird kurz erläutert, wie die API vorerst funktioniert. Sehen Sie sich das offizielle Beispiel an. um alle HDCP-Versionen zu testen.

const config = [{
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(mediaKeySystemAccess => mediaKeySystemAccess.createMediaKeys())
.then(mediaKeys => {

  // Get status for HDCP 2.2
  return mediaKeys.getStatusForPolicy({ minHdcpVersion: '2.2' })
  .then(status => {
    if (status !== 'usable')
      return Promise.reject(status);

    console.log('HDCP 2.2 can be enforced.');
    // TODO: Fetch high resolution protected content...
  });
})
.catch(error => {
  // TODO: Fallback to fetch license or stream low-resolution content...
});

Verfügbar für Ursprungstests

Um Feedback von Webentwicklern zu erhalten, haben wir die HDCP-Richtlinie hinzugefügt Sehen Sie sich die API-Funktion in Chrome 69 für Computer (ChromeOS, Linux, Mac und Windows) an.

Der Testzeitraum endete im November 2018.

Experimentelle Absicht | Chromestatus-Tracker | Chromium-Fehler

MSE PTS-/DTS-Konformität

Werte für zwischengespeicherte Bereiche und Dauer werden jetzt durch den Darstellungszeitstempel ausgegeben. PTS-Intervalle (Decode Time Stamp, DTS-Intervalle) in Medien Source Extensions (MSE).

Als MSE neu war, wurde die Chrome-Implementierung mit WebM und MP3 getestet, einige in denen es keinen Unterschied zwischen PTS und DTS gab. Und Es funktionierte einwandfrei, bis ISO BMFF (auch MP4) hinzugefügt wurde. Dieser Container enthält häufig eine falsche Darstellung im Vergleich zu decodierten Zeitströmen (für Codecs wie H.264), wodurch sich DTS und PTS unterscheiden. Das verursachte Chrome meldet (normalerweise nur geringfügig) verschiedene zwischengespeicherte Bereiche und die Dauer als erwartet. Dieses neue Verhalten wird nach und nach in Chrome 69 eingeführt. und sorgen Sie dafür, dass die MSE-Implementierung der MSE-Spezifikation entspricht.

<ph type="x-smartling-placeholder">
</ph> PTS/DTS <ph type="x-smartling-placeholder">
</ph> PTS/DTS

Diese Änderung betrifft MediaSource.duration (und folglich HTMLMediaElement.duration), SourceBuffer.buffered (und folglich HTMLMediaElement.buffered) und SourceBuffer.remove(start, end).

Wenn Sie nicht sicher sind, welche Methode zum Melden zwischengespeicherter Bereiche und Dauer verwendet wird können Sie zur internen chrome://media-internals-Seite wechseln und nach „ChunkDemuxer: buffering by PTS“ (ChunkDemuxer: Zwischenspeichern durch PTS) oder "ChunkDemuxer: buffering by DTS" in der Logs.

Implementierungsabsicht | Chromium-Programmfehler

Umgang mit Medienaufruf-Intents in Android Go

Android Go ist eine einfache Version von Android, die für Einsteiger entwickelt wurde. Smartphones. Zu diesem Zweck sind nicht unbedingt einige Medienformate enthalten, Wenn ein Nutzer beispielsweise ein heruntergeladenes Video öffnen möchte, und es gibt keine Anwendungen, die diesen Zweck bewältigen können.

Um dieses Problem zu beheben, erfasst Chrome 69 unter Android Go jetzt Intents zum Medienaufrufen, Nutzer können heruntergeladene Audioinhalte, Videos und Bilder ansehen. Mit anderen Worten: Es muss die fehlenden Anzeigeanwendungen ersetzen.

<ph type="x-smartling-placeholder">
</ph> ALT_TEXT_HERE <ph type="x-smartling-placeholder">
</ph> Media-Intent-Handler

Diese Chrome-Funktion ist auf allen Android-Geräten mit Android O und höher mit maximal 1 GB RAM.

Fehler in Chromium

„salled“ wurde entfernt Ereignisse für Medienelemente mit MSE

Ein „verzögertes“ wird für ein Medienelement ausgelöst, wenn für den Download von Mediendaten nach etwa 3 Sekunden nicht voran. Bei Verwendung von Medienquellenerweiterungen (MSE) verwaltet wird, verwaltet die Web-App den Download und das Medienelement über den Fortschritt zu informieren. Dies hat dazu geführt, dass Chrome Ereignisse mit unangemessenen wenn die Website keine neuen Mediendatenblöcke mit SourceBuffer.appendBuffer() in den letzten 3 Sekunden.

Da Websites möglicherweise große Datenmengen mit geringer Häufigkeit anhängen, ist kein nützlicher Hinweis auf die Pufferung. Entfernen von „salled“ Events für MSE beseitigt Missverständnisse und optimiert die Nutzung von Chrome mit der MSE-Spezifikation. Bei Medienelementen, die nicht MSE verwenden, „verzögert“ weiter erhöhen wie heute.

Beabsichtigte Einstellung und Entfernung | Chromestatus-Tracker | Chromium-Fehler