Aktualności multimedialne w Chrome 63 i 64

François Beaufort
François Beaufort
GitHub

Możliwości dotyczące multimediów – interfejs API Decoding Info

Obecnie deweloperzy stron internetowych polegają na isTypeSupported() lub canPlayType(), aby w przybliżony sposób określić, czy można odkodować określone media. Powinno być jednak pytanie: „jak skuteczne byłyby na tym urządzeniu”.

To właśnie jest jednym z problemów, które ma rozwiązać proponowana funkcja Media Capabilities: interfejs API do wysyłania zapytań do przeglądarki o możliwości dekodowania urządzenia na podstawie informacji takich jak kodeki, profil, rozdzielczość, bitrate itp. Na podstawie poprzednich statystyk odtwarzania zapisanych przez przeglądarkę interfejs API udostępniałby informacje o tym, czy odtwarzanie powinno być płynne i energooszczędne.

Oto w skrócie, jak obecnie działa interfejs Decoding Info API. Zapoznaj się z oficjalnym przykładem.

const mediaConfig = {
  type: 'media-source', // or 'file'
  audio: {
    contentType: 'audio/webm; codecs=opus',
    channels: '2', // audio channels used by the track
    bitrate: 132266, // number of bits used to encode a second of audio
    samplerate: 48000 // number of samples of audio carried per second
  },
  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
  }
};

navigator.mediaCapabilities.decodingInfo(mediaConfig).then(result => {
  console.log('This configuration is' +
      (result.supported ? '' : ' NOT') + ' supported,' +
      (result.smooth ? '' : ' NOT') + ' smooth and' +
      (result.powerEfficient ? '' : ' NOT') + ' power efficient.');
});

Możesz wypróbować różne konfiguracje multimediów, aż znajdziesz najlepszą (smooth i powerEfficient), i użyć jej do odtworzenia odpowiedniego strumienia multimediów. Przy okazji warto wspomnieć, że obecna implementacja w Chrome opiera się na wcześniej zarejestrowanych informacjach o odtwarzaniu. Określa ona wartość smooth jako prawda, gdy odsetek zgubionych klatek jest mniejszy niż 10%, a wartość powerEfficient jako prawda, gdy ponad 50% klatek jest dekodowanych przez sprzęt. Małe ramki są zawsze uważane za energooszczędne.

Zalecamy użycie fragmentu kodu podobnego do tego poniżej, aby wykryć dostępność i zrezygnować z obecnej implementacji w przypadku przeglądarek, które nie obsługują tego interfejsu API.

function isMediaConfigSupported(mediaConfig) {

  const promise = new Promise((resolve, reject) => {
    if (!('mediaCapabilities' in navigator)) {
      return reject('MediaCapabilities API not available');
    }
    if (!('decodingInfo' in navigator.mediaCapabilities)) {
      return reject('Decoding Info not available');
    }
    return resolve(navigator.mediaCapabilities.decodingInfo(mediaConfig));
  });

  return promise.catch(_ => {
    let fallbackResult = {
      supported: false,
      smooth: false, // always false
      powerEfficient: false // always false
    };
    if ('video' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.video.contentType);
      if (!fallbackResult.supported) {
        return fallbackResult;
      }
    }
    if ('audio' in mediaConfig) {
      fallbackResult.supported = MediaSource.isTypeSupported(mediaConfig.audio.contentType);
    }
    return fallbackResult;
  });
}

Dostępne w wersjach próbnych origin

Aby w pełni poznać jak najwięcej opinii od deweloperów korzystających z interfejsu Decoding Info API (część funkcji Media Capabilities), dodaliśmy tę funkcję w Chrome 64 do wersji próbnej origin.

W kwietniu 2018 r. zakończyliśmy testowanie.

Zamiar zakupu | Zamiar wysyłki | Narzędzie do śledzenia stanu Chrome | Błąd w Chromium

Odtwarzanie filmów HDR w systemie Windows 10

Filmy w technologii High Dynamic Range (HDR) mają większy kontrast, dzięki czemu odznaczają się precyzyjnymi, szczegółowymi cieniami i oszałamiającymi światłami. Ponadto obsługa szerokiej palety kolorów oznacza, że kolory są bardziej żywe.

Symulowane porównanie obrazu SDR i HDR (aby zobaczyć prawdziwy obraz HDR, musisz mieć wyświetlacz HDR)
Symulowane porównanie SDR i HDR (aby zobaczyć prawdziwy HDR, musisz mieć wyświetlacz HDR)

Odtwarzanie 10-bitowego formatu VP9 Profile 2 jest teraz obsługiwane w Chrome na system Windows 10 z aktualizacją Twórców. Chrome obsługuje też odtwarzanie filmów HDR, gdy system Windows 10 jest w trybie HDR. Ze względów technicznych Chrome 64 obsługuje teraz profil kolorów scRGB, co z kolei umożliwia odtwarzanie multimediów w trybie HDR.

Możesz to sprawdzić, oglądając film The World in HDR in 4K (ULTRA HD) w YouTube. Sprawdź, czy odtwarzanie w HDR działa, patrząc na ustawienia jakości odtwarzacza w YouTube.

Ustawienie jakości odtwarzacza YouTube z HDR
Ustawienie jakości odtwarzacza YouTube z HDR

Na razie potrzebujesz tylko jesiennej aktualizacji programu dla twórców w systemie Windows 10, karty graficznej i wyświetlacza zgodnej z HDR (np. karty NVIDIA 10, telewizora lub monitora LG HDR) oraz włączenia trybu HDR w ustawieniach wyświetlacza w Windows.

Deweloperzy internetowi mogą wykryć przybliżony zakres kolorów obsługiwany przez urządzenie wyjściowe za pomocą najnowszej zapytania o zakres kolorów oraz liczby bitów użytych do wyświetlania koloru na ekranie za pomocą screen.colorDepth. Oto jeden ze sposobów korzystania z tych informacji do wykrywania, czy obsługiwany jest format VP9 HDR:

// Detect if display is in HDR mode and if browser supports VP9 HDR.
function canPlayVp9Hdr() {

  // TODO: Adjust VP9 codec string based on your video encoding properties.
  return (window.matchMedia('(color-gamut: p3)').matches &&
      screen.colorDepth >= 48 &&
      MediaSource.isTypeSupported('video/webm; codecs="vp09.02.10.10.01.09.16.09.01"'))
}

Ciąg kodeka VP9 z profilem 2 przekazany do isTypeSupported() w powyższym przykładzie wymaga aktualizacji zgodnie z właściwościami kodowania wideo.

Pamiętaj, że nie można jeszcze definiować kolorów HDR w CSS, płótnie, obrazach ani zawartości chronionej. Nasz zespół pracuje nad rozwiązaniem tego problemu. Więcej informacji już wkrótce.

Licencje trwałe dla systemów Windows i Mac

Trwała licencja w zaszyfrowanych rozszerzeniach multimediów (EME) oznacza, że licencja może być przechowywana na urządzeniu, aby aplikacje mogły wczytać ją do pamięci bez wysyłania kolejnego żądania licencji do serwera. W ten sposób obsługiwane jest odtwarzanie offline w EME.

Do tej pory trwałe licencje były obsługiwane tylko na platformach ChromeOS i Android. To już nieprawda. Odtwarzanie treści chronionych przez EME gdy urządzenie jest offline, jest teraz możliwe również w Chrome 64 na urządzeniach z systemem Windows i macOS.

const config = [{
  sessionTypes: ['persistent-license'],
  videoCapabilities: [{
    contentType: 'video/webm; codecs="vp09.00.10.08"',
    robustness: 'SW_SECURE_DECODE' // Widevine L3
  }]
}];

navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(access => {
  // User will be able to watch encrypted content while being offline when
  // license is stored locally on device and loaded later.
})
.catch(error => {
  // Persistent licenses are not supported on this platform yet.
});

Możesz samodzielnie wypróbować licencje trwałe, sprawdzając przykładową aplikację PWA do multimediów i wykonując te czynności:

  1. Wejdź na stronę https://biograf-155113.appspot.com/ttt/episode-2/.
  2. Kliknij „Udostępnij w trybie offline” i poczekaj na pobranie filmu.
  3. Wyłącz połączenie z internetem.
  4. Kliknij przycisk „Odtwórz” i obejrzyj film.

Domyślnie wstępne wczytywanie multimediów jest ustawione na „metadane”.

Aby zmniejszyć wykorzystanie przepustowości i zasobów, Chrome na komputery teraz dopasowuje do implementacji innych przeglądarek domyślną wartość wstępnego wczytania elementów <video> i <audio> do "metadata". Od wersji 64 Chrome to nowe zachowanie dotyczy tylko przypadków, w których nie ustawiono wartości wstępnego wczytania. Pamiętaj, że gdy do elementu multimedialnego dodasz atrybuty MediaSource, sugestia atrybutu wstępnego wczytania zostanie odrzucona, ponieważ witryna sama obsługuje wstępne wczytywanie.

Oznacza to, że wartość wstępnego wczytywania <video> wynosi teraz "metadata", a wartość wstępnego wczytywania <video preload="auto"> pozostaje na "auto". Wypróbuj oficjalny przykładowy dokument.

Intend to Ship | Chromestatus Tracker | Chromium Bug

Nieobsługiwana wartość playbackRate powoduje wyjątek

Po zmianie specyfikacji HTML, gdy parametr playbackRate elementów multimedialnych zostanie ustawiony na wartość nieobsługiwaną przez Chrome (np. wartość ujemną), w Chrome 63 zwracana jest wartość "NotSupportedError" DOMException.

const audio = document.querySelector('audio');
try {
  audio.playbackRate = -1;
} catch(error) {
  console.log(error.message); // Failed to set the playbackRate property
}

Warto zauważyć, że obecna implementacja w Chrome zgłasza to wyjątek, gdy playbackRate jest ujemna, mniejsza niż 0,0625 lub większa niż 16. Aby zobaczyć, jak to działa, wypróbuj oficjalną próbkę.

Zamiar wysyłki | Narzędzie do śledzenia stanu Chrome | Błąd w Chromium

Optymalizacja ścieżki wideo w tle

Zespół Chrome nieustannie szuka nowych sposobów na wydłużenie czasu pracy na baterii, a Chrome 63 nie był wyjątkiem.

Jeśli film nie zawiera żadnych ścieżek audio, zostanie automatycznie wstrzymany, gdy będzie odtwarzany w tle (np. na niewidocznej karcie) w Chrome na komputerze (Windows, Mac, Linux i ChromeOS). Ta aktualizacja jest kontynuacją podobnej zmiany, która dotyczyła tylko filmów MSE w Chrome 62.

Błąd Chromium

Usuwanie wyciszania w przypadku ekstremalnych wartości playbackRate

Przed wersją 64 Chrome dźwięk był wyciszony, gdy wartość playbackRate była poniżej 0,5 lub powyżej 4, ponieważ jakość znacznie się pogarszała. W Chrome wprowadzamy podejście Waveform-Podobieństwo-Pokrywanie się (WSOLA), które obniża jakość dźwięku, więc nie trzeba już go wyciszać. Oznacza to, że teraz możesz odtwarzać dźwięk bardzo wolno lub bardzo szybko.

Błąd w Chromium