- Chrome unterstützt die AV1-Videodecodierung.
- Sie können jetzt über EME abfragen, welche Verschlüsselungsschemata unterstützt werden.
- Webentwickler können prüfen, ob eine bestimmte HDCP-Richtlinie durchgesetzt werden kann.
- Medienquellenerweiterungen verwenden jetzt PTS für zwischengespeicherte Bereiche und Werte für die Dauer.
- Android Go-Nutzer können heruntergeladene Audioinhalte, Videos und Bilder in Chrome öffnen.
- Angehaltene Ereignisse für Medienelemente, die MSE verwenden, werden entfernt.
AV1-Videodekoder
Chromestatus-Tracker | Chromium-Fehler
EME: Support für Verschlüsselungsschemata 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. Webentwickler müssen also intelligente Entscheidungen darüber treffen können, welche Inhalte ausgeliefert werden sollen.
Damit nicht ermittelt werden muss, auf welcher Plattform sich die Website befindet, um die Unterstützung für „bekannte“ Verschlüsselungsschemata zu prüfen, wird im MediaKeySystemMediaCapability-Wörterbuch ein neuer encryptionScheme-Schlüssel hinzugefügt, mit dem Websites angeben 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'AES-CTR-Modus – Vollständiges Sample und Video-NAL-Subsample-Verschlüsselung'cbcs'Teilvideoverschlüsselung mit NAL-Muster im AES-CBC-Modus.
Wenn keine Angabe erfolgt, bedeutet dies, dass jedes Verschlüsselungsschema akzeptabel ist. Beachte, dass Schlüssel löschen immer das Schema 'cenc' unterstützt.
Das folgende Beispiel zeigt, wie zwei Konfigurationen mit unterschiedlichen Verschlüsselungsschemata abgefragt werden. 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. Die kumulierte Konfiguration kann also ein oder beide Verschlüsselungsschemata enthalten.
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
Heutzutage ist HDCP eine gängige Richtlinienanforderung für das Streamen 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 mit dem Streamen von Inhalten mit einer niedrigen Auflösung beginnen. Das ist eine traurige Situation, die mit der HDCP Policy Check API gelöst werden soll.
Mit dieser vorgeschlagenen API können Webentwickler prüfen, ob eine bestimmte HDCP-Richtlinie erzwungen werden kann, damit die Wiedergabe mit der optimalen Auflösung gestartet werden kann. Es handelt sich um eine einfache Methode, den Status eines hypothetischen Schlüssels abzufragen, der mit einer HDCP-Richtlinie verknüpft ist, ohne dass eine MediaKeySession erstellt oder eine echte Lizenz abgerufen werden muss. MediaKeys muss auch nicht an Audio- oder Videoelemente angehängt sein.
Die HDCP Policy Check API funktioniert einfach, indem mediaKeys.getStatusForPolicy() mit einem Objekt aufgerufen wird, das einen minHdcpVersion-Schlüssel und einen gültigen Wert hat. Wenn HDCP in der angegebenen Version verfügbar ist, wird die zurückgegebene Prüfung mit einer MediaKeyStatus von 'usable' aufgelöst. Andernfalls wird das Versprechen mit anderen Fehlerwerten von 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.
Im Folgenden wird kurz erläutert, wie die API vorerst funktioniert. Im offiziellen Beispiel kannst du alle Versionen von HDCP 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 die HDCP Policy Check API in Chrome 69 für Computer (ChromeOS, Linux, Mac und Windows) hinzugefügt.
Der Test wurde im November 2018 erfolgreich abgeschlossen.
Intent to Experiment | Chromestatus-Tracker | Chromium-Fehler
MSE PTS-/DTS-Konformität
In Media Source Extensions (MSE) werden Pufferbereiche und Dauerwerte jetzt anhand von PTS-Intervallen (Presentation Time Stamp) und nicht anhand von DTS-Intervallen (Decode Time Stamp) gemeldet.
Als MSE neu war, wurde die Chrome-Implementierung mit WebM und MP3 getestet, zwei Medienstream-Formate, bei denen keine Unterscheidung zwischen PTS und DTS vorgenommen wurde. Das funktionierte gut, bis ISO BMFF (auch MP4 genannt) hinzugefügt wurde. Dieser Container enthält häufig falsche Darstellungs- und Decodierungszeitströme (z. B. für Codecs wie H.264), was zu Unterschieden zwischen DTS und PTS führt. Daher meldete Chrome (normalerweise nur geringfügig) andere Werte für zwischengespeicherte Bereiche und Dauer als erwartet. Dieses neue Verhalten wird in Chrome 69 schrittweise eingeführt und sorgt dafür, dass die MSE-Implementierung der MSE-Spezifikation entspricht.
Diese Änderung betrifft MediaSource.duration (und damit auch HTMLMediaElement.duration), SourceBuffer.buffered (und damit auch HTMLMediaElement.buffered) und SourceBuffer.remove(start, end).
Wenn du nicht sicher bist, mit welcher Methode gepufferte Bereiche und Dauerwerte erfasst werden, kannst du auf der internen Seite chrome://media-internals nach „ChunkDemuxer: buffering by PTS“ oder „ChunkDemuxer: buffering by DTS“ suchen.
Intent to Implement | Chromium-Fehler
Umgang mit Intents für die Medienansicht auf Android Go
Android Go ist eine schlanke Version von Android, die für Einsteiger-Smartphones entwickelt wurde. Zu diesem Zweck ist sie nicht unbedingt in einigen Anwendungen zum Ansehen von Medien enthalten. Wenn ein Nutzer beispielsweise versucht, ein heruntergeladenes Video zu öffnen, hat er keine Anwendungen, die diesen Zweck verarbeiten können.
Um dieses Problem zu beheben, prüft Chrome 69 unter Android Go jetzt auf Intents für die Medienwiedergabe, damit Nutzer heruntergeladene Audioinhalte, Videos und Bilder ansehen können. Mit anderen Worten, sie ersetzt die fehlenden Anzeigeanwendungen.
Diese Chrome-Funktion ist auf allen Android-Geräten mit Android O und höher mit bis zu 1 GB RAM aktiviert.
Entfernung von „angehaltenen“ Ereignissen für Medienelemente mit MSE
Wenn der Download von Mediendaten etwa 3 Sekunden lang nicht ausgeführt werden konnte, wird das Ereignis „Angehalten“ für ein Medienelement ausgelöst. Bei der Verwendung von Media Source Extensions (MSE) verwaltet die Web-App den Download und das Medienelement erkennt den Fortschritt nicht. Dadurch wurden in Chrome zu unpassenden Zeiten „angehaltene“ Ereignisse ausgelöst, wenn die Website in den letzten drei Sekunden keine neuen Media-Daten-Chunks mit SourceBuffer.appendBuffer() angehängt hatte.
Da Websites möglicherweise große Datenmengen mit niedriger Häufigkeit anhängen, ist dies kein nützlicher Hinweis auf die Zwischenspeicherung. Das Entfernen von „angehaltenen“ Ereignissen für Medienelemente mithilfe von MSE behebt Verwirrung und passt Chrome stärker an die MSE-Spezifikation an. Bei Medienelementen, für die MSE nicht verwendet wird, werden weiterhin „angehaltene“ Ereignisse ausgelöst.
Ankündigung der Einstellung und Entfernung | Chromestatus-Tracker | Chromium-Fehler