Funkcje multimedialne Chrome zostały zaktualizowane w wersji 75. W tym artykule omawiam nowe funkcje, takie jak:
- przewidywanie, czy odtwarzanie szyfrowanych multimediów będzie płynne i energooszczędne;
- Obsługa podpowiedzi atrybutu
playsInlineelementu wideo.
Zaszyfrowane multimedia: informacje o dekodowaniu
Od wersji Chrome 66 deweloperzy mogą korzystać z informacji o dekodowaniu, aby zapytać przeglądarkę o możliwości dekodowania czystych treści na urządzeniu na podstawie takich informacji, jak kodeki, profil, rozdzielczość, bitrate itp. Na podstawie poprzednich statystyk odtwarzania zapisanych przez przeglądarkę informacje te wskazują, czy odtwarzanie będzie płynne (w czasie) i energooszczędne.
Specyfikacja interfejsu Media Capabilities API, która definiuje informacje o dekodowaniu, została zaktualizowana, aby obsługiwać również szyfrowane konfiguracje multimediów, dzięki czemu witryny korzystające z szyfrowanych multimediów (EME) mogą wybierać optymalne strumienie multimediów.
Oto, jak działa dekodowanie informacji w przypadku EME. Posłuchaj oficjalnego fragmentu.
const encryptedMediaConfig = {
type: 'media-source', // or 'file'
video: {
contentType: 'video/webm; codecs="vp09.00.10.08"',
width: 1920,
height: 1080,
bitrate: 2646242, // number of bits used to encode a second of video
framerate: '25' // number of frames used in one second
},
keySystemConfiguration: {
keySystem: 'com.widevine.alpha',
videoRobustness: 'SW_SECURE_DECODE' // Widevine L3
}
};
navigator.mediaCapabilities.decodingInfo(encryptedMediaConfig).then(result => {
if (!result.supported) {
console.log('Argh! This encrypted media configuration is not supported.');
return;
}
if (!result.keySystemAccess) {
console.log('Argh! Encrypted media support is not available.')
return;
}
console.log('This encrypted media configuration is supported.');
console.log('Playback should be' +
(result.smooth ? '' : ' NOT') + ' smooth and' +
(result.powerEfficient ? '' : ' NOT') + ' power efficient.');
// TODO: Use `result.keySystemAccess.createMediaKeys()` to setup EME playback.
});
Odtworzenia EME mają specjalistyczne ścieżki kodu dekodowania i renderowania, co oznacza, że obsługa i wydajność kodeków jest inna niż w przypadku odtwarzania z czystym dźwiękiem. Dlatego w obiekcie konfiguracji multimediów przekazanym do navigator.mediaCapabilities.decodingInfo() musi zostać ustawiony nowy klucz keySystemConfiguration. Wartością tego klucza jest słownik zawierający kilka popularnych typów EME. Ta metoda powiela dane wejściowe przekazywane do funkcji requestMediaKeySystemAccess() z jedną ważną różnicą: sekwencje danych wejściowych przekazywane do funkcji requestMediaKeySystemAccess() są spłaszczone do jednej wartości w miejscach, w których sekwencja miała na celu wybranie przez funkcję requestMediaKeySystemAccess() podzbioru, który obsługuje.
Decoding Info opisuje jakość (płynność i oszczędność energii) obsługi pary strumieni audio i wideo bez podejmowania decyzji przez wywołującego. Osoby dzwoniące powinny nadal zamawiać konfiguracje multimediów tak jak w przypadku requestMediaKeySystemAccess(). Teraz same obchodzą listę.
navigator.mediaCapabilities.decodingInfo() zwraca obietnicę realizowaną asynchronicznie z obiektem zawierającym 3 wartości logiczne: supported, smooth i powerEfficient. Jednak gdy kluczkeySystemConfiguration jest ustawiony, a wartośćsupported totrue, zwracany jest też inny obiekt MediaKeySystemAccess o nazwie keySystemAccess. Można go używać do żądania niektórych kluczy multimediów oraz konfigurowania odtwarzania zaszyfrowanych multimediów. Oto przykład:
// Like rMSKA(), orderedMediaConfigs is ordered from most to least wanted.
const capabilitiesPromises = orderedMediaConfigs.map(mediaConfig =>
navigator.mediaCapabilities.decodingInfo(mediaConfig)
);
// Assume this app wants a supported and smooth media playback.
let bestConfig = null;
for await (const result of capabilitiesPromises) {
if (result.supported && result.smooth) {
bestConfig = result;
break;
}
}
if (bestConfig) {
const mediaKeys = await bestConfig.keySystemAccess.createMediaKeys();
// TODO: rest of EME path as-is
} else {
// Argh! No smooth configs found.
// TODO: Maybe choose the lowest resolution and framerate available.
}
Pamiętaj, że dekodowanie informacji o zaszyfrowanych plikach multimedialnych wymaga protokołu HTTPS.
Pamiętaj też, że może ona wywołać prośbę o potwierdzenie na urządzeniach z Androidem i ChromeOS w taki sam sposób jak requestMediaKeySystemAccess(). Nie będzie jednak wyświetlać więcej promptów niż requestMediaKeySystemAccess(), mimo że skonfigurowanie odtwarzania zaszyfrowanych multimediów będzie wymagało większej liczby wywołań.
Intencja eksperymentu | Chromestatus Tracker | Błąd w Chromium
HTMLVideoElement.playsInline
Chrome obsługuje teraz atrybut logiczny playsInline. Jeśli jest obecny, wskazuje przeglądarce, że film powinien być domyślnie wyświetlany „w dokumencie”, ograniczony do obszaru odtwarzania elementu.
Podobnie jak w Safari, gdzie elementy wideo na iPhonie nie przechodzą automatycznie w tryb pełnoekranowy po rozpoczęciu odtwarzania, ten podpowiedź umożliwia niektórym osobom umieszczającym treści automatyczne odtwarzanie filmów w trybie pełnoekranowym. Deweloperzy stron internetowych mogą w razie potrzeby zrezygnować z tej funkcji.
<video playsinline></video>
Chrome na Androidzie i komputerach nie obsługuje automatycznego trybu pełnoekranowego, więc podpowiedź atrybutu elementu wideo playsInline nie jest używana.