- Chrome unterstützt die AV1-Videodecodierung.
- Abfragen, welche Verschlüsselungsschemas unterstützt werden EME ist jetzt verfügbar.
- Webentwickler können mit der Abfrage, ob eine bestimmte HDCP-Richtlinie erzwungen werden kann experimentieren.
- Medienquellenerweiterungen verwenden jetzt PTS für zwischengespeicherte Bereiche und Werte für die Dauer.
- Android Go-Nutzer können heruntergeladene Audio-, Video- und Bildinhalte in Chrome öffnen.
- Angehaltene Ereignisse für Medienelemente, die MSE verwenden, werden entfernt.
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">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">Diese Chrome-Funktion ist auf allen Android-Geräten mit Android O und höher mit maximal 1 GB RAM.
„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