- Chrome obsługuje dekodowanie wideo AV1.
- Zapytanie, które schematy szyfrowania są obsługiwane Funkcja EME jest już dostępna.
- Programiści stron internetowych mogą eksperymentować, sprawdzając, czy można wyegzekwować określone zasady HDCP.
- Rozszerzenia źródeł multimediów korzystają teraz z PTS dla buforowanych zakresów i wartości czasu trwania.
- Użytkownicy Androida Go mogą otwierać pobrane pliki audio, wideo i obrazy w Chrome.
- Zdarzenia zapisane w przypadku elementów multimedialnych korzystających z MSE są usuwane.
Dekoder wideo AV1
Tracker Chromestatus | 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. Inne są również w obu tych przypadkach. Te 2 schematy szyfrowania nie są zgodne, więc programiści stron internetowych muszą być w stanie dokonywać inteligentnych wyborów o tym, jakie treści wyświetlać.
Aby uniknąć konieczności sprawdzania, na której platformie się znajduje,
obsługi schematu szyfrowania, dodawany jest nowy klucz encryptionScheme w
słownik MediaKeySystemMediaCapability umożliwiający określanie stron internetowych
który schemat szyfrowania można zastosować w Szyfrowanych rozszerzeniach multimediów (EME).
Nowy klucz encryptionScheme może mieć jedną z 2 wartości:
'cenc'Pełne szyfrowanie próbki i podpróbki NAL w trybie AES-CTR.'cbcs'Częściowe szyfrowanie wzorców NAL filmu w trybie AES-CBC.
Jeśli go nie podasz, oznacza to, że każdy schemat szyfrowania jest akceptowalny. Notatka
że funkcja Clear Key zawsze obsługuje schemat 'cenc'.
Przykład poniżej pokazuje, jak wysłać zapytanie do 2 konfiguracji o różnych parametrach schematy szyfrowania. W tym przypadku zostanie wybrana tylko jedna opcja.
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 przykładzie poniżej tylko jedna konfiguracja z 2 różnymi rodzajami szyfrowania dla schematów. W takim przypadku Chrome odrzuci wszystkie obiekty możliwości. nie jest w stanie go obsłużyć, więc skumulowana konfiguracja może zawierać jedno szyfrowanie lub oba te schematy.
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: sprawdzanie zasad HDCP
Obecnie zasady dotyczące HDCP są obowiązkowe w przypadku strumieniowania w wysokich rozdzielczościach. treści chronionej. Dla programistów stron internetowych, którzy chcą egzekwować zasady HDCP musi zaczekać na zakończenie wymiany licencji lub rozpocząć strumieniowanie w niskiej rozdzielczości. To przykra sytuacja, ponieważ zasady dotyczące HDCP Sprawdzanie interfejsu API ma na celu rozwiązanie problemu.
Ten proponowany interfejs API pozwala programistom stron internetowych na sprawdzanie, czy określona zasada HDCP
można wymuszać, tak aby odtwarzanie mogło być uruchamiane w optymalnej rozdzielczości
i zapewniają użytkownikom najlepsze wrażenia. Obejmuje prostą metodę wysyłania zapytań o stan
hipotetyczny klucz powiązany z zasadą HDCP, bez konieczności tworzenia
MediaKeySession lub pobierz prawdziwą licencję. Nie musi być: MediaKeys
do elementów audio lub wideo.
Interfejs HDCP Policy Check API polega na wywołaniu
mediaKeys.getStatusForPolicy() za pomocą obiektu, który ma klucz minHdcpVersion
oraz prawidłową wartość. Jeśli HDCP jest dostępny w określonej wersji, zwracany jest parametr
obietnica rozwiązuje się z MediaKeyStatus o wartości 'usable'. W przeciwnym razie obietnica
rozwiązuje się z innymi wartościami błędu o wartości MediaKeyStatus, takimi jak
'output-restricted' lub 'output-downscaled'. Jeśli system kluczy nie
w ogóle nie obsługuje kontroli zasad HDCP (np. system Clear Key System), obietnica odrzuca.
Oto w skrócie, jak obecnie działa interfejs API. Zobacz oficjalną próbkę aby wypróbować wszystkie wersje HDCP.
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 umożliwić nam zbieranie opinii od twórców stron internetowych, dodaliśmy wcześniej zasady dotyczące HDCP Sprawdź funkcję interfejsu API w Chrome 69 na komputery (ChromeOS, Linux, Mac i Windows).
Okres próbny zakończył się w listopadzie 2018 roku.
Zamiar eksperymentowania | Narzędzie do śledzenia stanu Chrome | Błąd Chromium
Zgodność z MSE PTS/DTS
Zbuforowane zakresy i wartości czasu trwania są teraz raportowane przez sygnaturę czasową prezentacji w odstępach (PTS), a nie w odstępach czasu dekodowania DTS w multimediach. Source Extensions (MSE).
W nowej wersji MSE implementacja Chrome została przetestowana pod kątem WebM i MP3, formatów strumieni multimediów, w których nie ma rozróżnienia między PTS a DTS. oraz Program działał poprawnie do momentu dodania pliku ISO BMFF (inaczej MP4). Ten kontener często zawiera prezentację w złej kolejności lub dekoduje strumienie czasu (na (np. H.264) przez co różnią się DTS i PTS. Co spowodowało Chrome zgłasza (zwykle nieznacznie) różne buforowane zakresy i czas trwania niż oczekiwano. To nowe zachowanie będzie wdrażane stopniowo w Chrome 69 i zapewnić zgodność jej implementacji MSE ze specyfikacją MSE.
Ta zmiana wpływa na MediaSource.duration (i w konsekwencji
HTMLMediaElement.duration), SourceBuffer.buffered (a w konsekwencji
HTMLMediaElement.buffered) i SourceBuffer.remove(start, end).
Jeśli nie wiesz, która metoda jest używana do raportowania buforowanych zakresów i czasu trwania
możesz przejść do wewnętrznej strony chrome://media-internals i wyszukać
„ChunkDemuxer: buforowanie według PTS” lub „ChunkDemuxer: buforowanie przez DTS” w
dzienników.
Zamiar wdrożenia | Błąd Chromium
Obsługa intencji wyświetlenia multimediów w Androidzie Go
Android Go to lekka wersja Androida przeznaczona dla początkujących użytkowników. na smartfonach. Dlatego nie zawsze jest udostępniany w postaci treści multimedialnych, aplikacji, więc jeśli użytkownik spróbuje na przykład otworzyć pobrany film, nie będzie mieć żadnych aplikacji obsłużonych tę intencję.
Aby rozwiązać ten problem, Chrome 69 na Androidzie Go nasłuchuje intencji związanych z oglądaniem multimediów, użytkownicy mogą wyświetlać pobrane pliki audio, wideo i obrazy. Innymi słowy, miejsce brakujących aplikacji do wyświetlania.
Pamiętaj, że ta funkcja Chrome jest włączona na wszystkich urządzeniach z Androidem. O i nowsze z 1 GB pamięci RAM lub mniejszą.
Usunięcie stanu „Nieaktywny” zdarzeń dotyczących elementów multimedialnych korzystających z MSE
„Zawieszony” jest wywoływane w elemencie multimedialnym, jeśli pobieranie danych multimedialnych
nie udało się przejść przez około 3 sekundy. Podczas korzystania z rozszerzeń źródeł multimediów
(MSE), aplikacja internetowa zarządza pobieraniem, a element multimedialny nie wie,
o jego postępach. To spowodowało, że Chrome się zawiesił wydarzenia o nieodpowiedniej treści
za każdym razem, gdy witryna nie dodała nowych fragmentów danych multimedialnych z
SourceBuffer.appendBuffer() w ciągu ostatnich 3 sekund.
Witryny dołączają duże porcje danych z niską częstotliwością, więc nie jest przydatnym wskaźnikiem stanu buforowania. Usuwam „zawieszone” wydarzenia dla korzystanie z multimediów z wykorzystaniem MSE pomaga wyeliminować nieporozumienia i spójnie z zawartością Chrome ze specyfikacją MSE. Pamiętaj, że elementy multimedialne, które nie korzystają z MSE, nie przestawaj wyświetlać „zawieszonego” zdarzenia tak jak obecnie.
Plan wycofania i usunięcia | Narzędzie do śledzenia stanu Chrome | Błąd Chromium