- Chrome unterstützt die AV1-Videodecodierung.
- Ab sofort können Sie abfragen, welche Verschlüsselungsschemata unterstützt werden.
- Webentwickler können mit Abfragen testen, ob eine bestimmte HDCP-Richtlinie erzwungen werden kann.
- Mediaquellen-Erweiterungen verwenden jetzt PTS für zwischengespeicherte Bereiche und Dauerwerte.
- Android Go-Nutzer können heruntergeladene Audio-, Video- und Bilder-Inhalte in Chrome öffnen.
- Angehaltene Ereignisse für Medienelemente, die MSE verwenden, werden entfernt.
AV1-Videodecoder
Chromestatus-Tracker | Chromium-Fehler
EME: Unterstützung für Verschlüsselungsschemas abfragen
Einige Plattformen oder Schlüsselsysteme unterstützen nur den CENC-Modus, während andere nur den CBCS-Modus unterstützen. Wieder andere können beides unterstützen. Diese beiden Verschlüsselungsschemata sind nicht kompatibel, sodass Webentwickler in der Lage sein müssen, intelligente Entscheidungen darüber zu treffen, welche Inhalte bereitgestellt werden.
Damit Sie nicht herausfinden müssen, auf welcher Plattform sie zur Prüfung auf die Unterstützung „bekannter“ Verschlüsselungsschemas prüfen müssen, wird dem MediaKeySystemMediaCapability-Wörterbuch ein neuer encryptionScheme-Schlüssel hinzugefügt. Damit können Websites angeben, welches Verschlüsselungsschema in verschlüsselten Medienerweiterungen (EME) verwendet werden kann.
Der neue Schlüssel encryptionScheme kann einer von zwei Werten sein:
'cenc'Verschlüsselung für vollständiges Sample im AES-CTR-Modus und NAL-Video-NAL-Substichprobe.'cbcs'Verschlüsselung von Teilvideo-NAL-Muster im AES-CBC-Modus.
Falls keine Angabe erfolgt, wird damit angegeben, dass jedes Verschlüsselungsschema akzeptabel ist. Beachten Sie, dass Schlüssel löschen immer das Schema 'cenc' unterstützt.
Das folgende Beispiel zeigt, wie Sie zwei Konfigurationen mit unterschiedlichen Verschlüsselungsschemata abfragen. In diesem Fall wird nur eine 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 wird nur eine Konfiguration mit zwei verschiedenen Verschlüsselungsschemata abgefragt. In diesem Fall verwirft Chrome alle nicht unterstützten Funktionsobjekte, sodass die akkumulierte Konfiguration ein Verschlüsselungsschema oder beide enthalten kann.
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']
}]);
Intent to Implement | Chromestatus-Tracker | Chromium-Fehler
EME: HDCP-Richtlinienprüfung
Mittlerweile ist HDCP eine gängige Richtlinienanforderung für das Streaming hoher Auflösungen von geschützten Inhalten. Webentwickler, die eine HDCP-Richtlinie erzwingen möchten, müssen entweder warten, bis der Lizenzaustausch abgeschlossen ist, oder Inhalte mit einer niedrigen Auflösung streamen. Dies ist eine traurige Situation, die die HDCP Policy Check API lösen möchte.
Mit dieser vorgeschlagenen API können Webentwickler abfragen, ob eine bestimmte HDCP-Richtlinie erzwungen werden kann, um die Wiedergabe mit der optimalen Auflösung für eine optimale Nutzererfahrung zu starten. Sie besteht aus einer einfachen Methode, um den Status eines hypothetischen Schlüssels abzufragen, der mit einer HDCP-Richtlinie verknüpft ist, ohne eine MediaKeySession erstellen oder eine echte Lizenz abrufen zu müssen. MediaKeys muss auch nicht an Audio- oder Videoelemente angehängt werden.
Die HDCP Policy Check API funktioniert ganz einfach durch Aufrufen von mediaKeys.getStatusForPolicy() mit einem Objekt, das einen minHdcpVersion-Schlüssel und einen gültigen Wert hat. Wenn HDCP in der angegebenen Version verfügbar ist, wird das zurückgegebene Promise mit einem MediaKeyStatus von 'usable' aufgelöst. Andernfalls wird das Promise mit anderen Fehlerwerten wie MediaKeyStatus wie 'output-restricted' oder 'output-downscaled' aufgelöst. Wenn das Schlüsselsystem die HDCP-Richtlinienprüfung überhaupt nicht unterstützt (z.B. Clear Key System), wird das Promise abgelehnt.
Hier sehen Sie kurz, wie die API vorerst funktioniert. Im offiziellen Beispiel können Sie alle HDCP-Versionen ausprobieren.
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 in Chrome 69 für Desktop-Computer (ChromeOS, Linux, Mac und Windows) die Funktion HDCP Policy Check API hinzugefügt.
Der Testzeitraum endete im November 2018.
Intent to Experiment | Chromestatus-Tracker | Chromium-Fehler
MSE PTS/DTS-Compliance
Gepufferte Bereiche und Dauerwerte werden jetzt in PTS-Intervallen (Presentation Time Stamp) und nicht mehr in DTS-Intervallen (Decode Time Stamp) in Media Source Extensions (MSE) angegeben.
Als MSE neu war, wurde die Implementierung von Chrome mit WebM und MP3 getestet, d. h. einigen Medienstreamformaten, bei denen es keine Unterscheidung zwischen PTS und DTS gab. Und es funktionierte einwandfrei, bis ISO BMFF (MP4) hinzugefügt wurde. Dieser Container enthält häufig falsche Präsentationszeit- im Vergleich zu Decodierungszeitstreams (z. B. für Codecs wie H.264). Dadurch unterscheiden sich DTS und PTS. Das hat dazu geführt, dass Chrome (normalerweise nur geringfügig) andere Werte für zwischengespeicherte Bereiche und Dauer als erwartet meldet. Dieses neue Verhalten wird in Chrome 69 schrittweise eingeführt und macht die MSE-Implementierung mit der MSE-Spezifikation kompatibel.
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, mit welcher Methode gepufferte Bereiche und Dauerwerte gemeldet werden, können Sie die interne Seite chrome://media-internals aufrufen und in den Logs nach „ChunkDemuxer: buffering by PTS“ oder „ChunkDemuxer: buffering by DTS“ suchen.
Intent to Implement | Chromium-Fehler
Umgang mit Medienaufruf-Intents unter Android Go
Android Go ist eine einfache Version von Android für Einsteiger-Smartphones. Daher ist es nicht unbedingt mit einigen Anwendungen zur Medienwiedergabe enthalten. Wenn ein Nutzer beispielsweise versucht, ein heruntergeladenes Video zu öffnen, hat er keine App, die diesen Zweck erfüllt.
Um dieses Problem zu beheben, wartet Chrome 69 unter Android Go jetzt auf Medienwiedergabe-Intents, damit Nutzer heruntergeladene Audioinhalte, Videos und Bilder ansehen können. Mit anderen Worten, es ersetzt die fehlenden Anzeigeanwendungen.
Diese Chrome-Funktion ist auf allen Android-Geräten mit Android O und höher und bis zu 1 GB RAM aktiviert.
Entfernung von „verzögerten“ Ereignissen für Medienelemente, die MSE verwenden
Ein „verzögertes“ Ereignis wird für ein Medienelement ausgelöst, wenn das Herunterladen von Mediendaten etwa drei Sekunden lang fehlgeschlagen ist. Wenn Sie Media Source Extensions (MSE) verwenden, verwaltet die Webanwendung den Download und das Medienelement erfasst nicht den Fortschritt. Dadurch hat Chrome zu unangemessenen Zeiten „verzögerte“ Ereignisse ausgelöst, wenn der Website in den letzten 3 Sekunden keine neuen Mediendatenblöcke mit SourceBuffer.appendBuffer() angehängt wurden.
Da Websites möglicherweise große Datenblöcke mit niedriger Häufigkeit anhängen, ist dies kein nützliches Signal für die Zwischenspeicherung. Durch das Entfernen von „verzögerten“ Ereignissen für Medienelemente mithilfe von MSE wird Verwirrung beseitigt und Chrome besser der MSE-Spezifikation entspricht. Beachten Sie, dass Medienelemente, die nicht MSE verwenden, weiterhin „verzögerte“ Ereignisse auslösen.
Abzustufen und Entfernen | Chromestatus-Tracker | Chromium-Fehler