- Chrome obsługuje dekodowanie wideo AV1.
- Udostępniliśmy w EME zapytanie, które schematy szyfrowania są obsługiwane.
- Programiści stron internetowych mogą eksperymentować z zapytaniami, czy można egzekwować określoną zasadę HDCP.
- Rozszerzenia źródła multimediów używają teraz wskaźnika lokalizacji dla buforów i wartości czasu trwania.
- Użytkownicy Androida Go mogą otwierać pobrane pliki audio, wideo i obrazy w Chrome.
- Wstrzymane zdarzenia związane z elementami multimedialnymi korzystającymi z MSE są usuwane.
Dekoder wideo AV1
Narzędzie do śledzenia stanu Chrome | Błąd Chromium
EME: obsługa schematu szyfrowania zapytań
Niektóre platformy i systemy kluczy obsługują tylko tryb CENC, a inne – tylko tryb CBCS. Jeszcze inne obsługują oba te tryby. Te 2 schematy szyfrowania są niekompatybilne, więc programiści muszą mieć możliwość dokonywania inteligentnych wyborów dotyczących wyświetlanych treści.
Aby uniknąć konieczności sprawdzania, na jakiej platformie korzysta klient w celu sprawdzenia obsługi „znanego” schematu szyfrowania, do słownika MediaKeySystemMediaCapability dodawany jest nowy klucz encryptionScheme. Dzięki temu witryny mogą określać schematy szyfrowania, których można użyć w rozszerzeniach zaszyfrowanych multimediów (EME).
Nowy klucz encryptionScheme może mieć jedną z 2 wartości:
'cenc'Pełne szyfrowanie próbek w trybie AES-CTR i podprzykładowe szyfrowanie NAL wideo.'cbcs'Częściowe szyfrowanie NAL obrazu wideo w trybie AES-CBC.
Jeśli jej nie podasz, będzie to oznaczać, że każdy schemat szyfrowania jest akceptowany. Pamiętaj, że klucz Wyczyść zawsze obsługuje schemat 'cenc'.
Z przykładu poniżej dowiesz się, jak utworzyć zapytanie o 2 konfiguracje o różnych schematach szyfrowania. W tym przypadku zostanie wybrana tylko jedna z nich.
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']
},
]);
W poniższym przykładzie zapytanie obejmuje tylko 1 konfigurację z 2 różnymi schematami szyfrowania. W takim przypadku Chrome odrzuci wszystkie obiekty funkcji, których nie obsługuje, więc skumulowana konfiguracja może zawierać 1 schemat szyfrowania lub oba.
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']
}]);
Zamiar wdrożenia | Narzędzie do śledzenia stanu Chrome | Błąd Chromium
EME: kontrola zasad HDCP
Obecnie HDCP jest częstym wymogiem przesyłania strumieniowego w wysokiej rozdzielczości treści chronionych. Programiści stron internetowych, którzy chcą egzekwować zasadę HDCP, muszą poczekać na zakończenie wymiany licencji lub rozpocząć strumieniowe przesyłanie treści w niskiej rozdzielczości. Problem ten ma rozwiązać HDCP Policy Check API.
Ten proponowany interfejs API pozwala programistom stron internetowych na sprawdzanie, czy określona zasada HDCP może być egzekwowana, co pozwala na rozpoczęcie odtwarzania w optymalnej rozdzielczości zapewniającej najlepsze wrażenia użytkownika. Obejmuje prostą metodę wysyłania zapytań o stan hipotetycznego klucza powiązanego z zasadą HDCP, bez konieczności tworzenia MediaKeySession ani pobierania rzeczywistej licencji. Nie wymaga MediaKeys dołączania
do żadnych elementów audio ani wideo.
Interfejs HDCP Policy Check API działa przez wywołanie mediaKeys.getStatusForPolicy() z obiektem, który ma klucz minHdcpVersion i prawidłową wartość. Jeśli HDCP jest dostępny w określonej wersji, zwrócona obietnica jest traktowana jako MediaKeyStatus o wartości 'usable'. W przeciwnym razie obietnica zostanie uzupełniona o inne wartości błędu MediaKeyStatus, takie jak 'output-restricted' lub 'output-downscaled'. Jeśli system kluczy w ogóle nie obsługuje sprawdzania zasad HDCP (np. Clear Key System), obietnica jest odrzucana.
Oto jak obecnie działa ten interfejs API. Wszystkie wersje HDCP znajdziesz w oficjalnej próbce.
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...
});
Dostępne w przypadku testowania origin
Aby uzyskać opinie od programistów stron internetowych, dodaliśmy wcześniej funkcję HDCP Policy Check API w Chrome 69 na komputery (ChromeOS, Linux, Mac i Windows).
Okres próbny zakończył się w listopadzie 2018 roku.
Zamiar eksperymentu | Narzędzie do śledzenia stanu Chrome | Błąd Chromium
Zgodność ze standardem MSE PTS/DTS
Zakresy buforowane i wartości czasu trwania są teraz raportowane według interwałów znacznika czasu prezentacji (PTS), a nie według interwałów dekodowania sygnatury czasowej (DTS) w rozszerzeniach źródeł multimediów (MSE).
Gdy MSE było nowe, implementacja Chrome została przetestowana pod kątem WebM i MP3, czyli formatów strumieni multimediów, w których nie było rozróżnienia między PTS a DTS. I było dobrze, dopóki nie dodano ISO BMFF (nazywanego również MP4). Ten kontener często zawiera nieuporządkowane strumienie czasu prezentacji i dekodowania (np. kodeki H.264), co powoduje różnice między DTS i PTS. W związku z tym Chrome zgłasza (zwykle tylko nieznacznie) inne niż oczekiwane zakresy buforowane i wartości czasu trwania. To nowe zachowanie będzie wdrażane stopniowo w Chrome 69 i zapewni zgodność implementacji MSE ze specyfikacją MSE.
Ta zmiana wpływa na MediaSource.duration (a w konsekwencji na HTMLMediaElement.duration), SourceBuffer.buffered (a w konsekwencji na HTMLMediaElement.buffered) oraz SourceBuffer.remove(start, end)).
Jeśli nie masz pewności, która metoda jest używana do raportowania zakresów zbuforowanych i wartości czasu trwania, wejdź na wewnętrzną stronę chrome://media-internals i wyszukaj w logach ciąg „ChunkDemuxer: buffering by PTS” lub „ChunkDemuxer: buffering by DTS”.
Zamiar wdrożenia | Błąd Chromium
Obsługa intencji wyświetlania multimediów na Androidzie Go
Android Go to lekka wersja Androida zaprojektowana z myślą o podstawowych smartfonach. W związku z tym niekoniecznie musi to być aplikacja do wyświetlania multimediów, więc jeśli użytkownik spróbuje otworzyć np. pobrany film, nie będzie mieć żadnej aplikacji obsługującej ten cel.
Aby rozwiązać ten problem, Chrome 69 na Androidzie Go nasłuchuje teraz intencji związanych z oglądaniem multimediów, aby użytkownicy mogli wyświetlać pobrane pliki audio, filmy i obrazy. Innymi słowy, zastąpią one brakujące aplikacje do wyświetlania.
Ta funkcja Chrome jest włączona na wszystkich urządzeniach z Androidem O lub nowszym, które mają nie więcej niż 1 GB pamięci RAM.
Usuwanie „wstrzymanych” zdarzeń z elementów multimedialnych za pomocą MSE
Jeśli pobieranie danych multimedialnych nie zostanie wykonane przez około 3 sekundy, w elemencie multimedialnym zostanie zgłoszone zdarzenie „wstrzymane”. Gdy używasz rozszerzeń źródeł multimediów (MSE), pobieraniem zarządza aplikacja internetowa, a element multimedialny nie wie o postępach tego procesu. Spowodowało to, że Chrome zgłaszał zdarzenia „przestoju” w nieodpowiednich momentach, gdy w ciągu ostatnich 3 sekund witryna nie dodała nowych fragmentów danych multimedialnych z parametrem SourceBuffer.appendBuffer().
Witryny mogą dołączać duże porcje danych o niskiej częstotliwości, więc nie jest to przydatny sygnał o stanie buforowania. Usunięcie zawieszonych zdarzeń z elementów multimedialnych za pomocą MSE rozjaśnia dezorientację i sprawia, że Chrome jest bardziej zgodny ze specyfikacją MSE. Pamiętaj, że elementy multimediów, które nie używają MSE, nadal będą wywoływać „zatrzymane” zdarzenia, tak jak ma to miejsce obecnie.
Zamiar wycofania i usunięcia | Narzędzie do śledzenia stanu Chrome | Błąd Chromium