Aktualności multimedialne w Chrome 63 i 64

François Beaufort
François Beaufort
GitHub

Media Capabilities - Decoding Info API

Obecnie deweloperzy stron internetowych korzystają z isTypeSupported() lub canPlayType(), aby w przybliżeniu określić, czy niektóre multimedia można zdekodować. Prawdziwe pytanie powinno brzmieć: „Jak dobrze będzie działać na tym urządzeniu?”.

Jest to jeden z problemów, które ma rozwiązać proponowany interfejs 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ść, szybkość transmisji itp. Umożliwi on udostępnianie informacji, np. czy odtwarzanie powinno być płynne i energooszczędne na podstawie wcześniejszych statystyk odtwarzania zarejestrowanych przez przeglądarkę.

Oto 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 odtwarzania odpowiedniego strumienia multimediów. Obecna implementacja Chrome opiera się na wcześniej zarejestrowanych informacjach o odtwarzaniu. Wartość smooth jest prawdziwa, gdy odsetek pominiętych klatek jest mniejszy niż 10%, a wartość powerEfficient jest prawdziwa, gdy ponad 50% klatek jest dekodowanych przez sprzęt. Małe ramki są zawsze uważane za energooszczędne.

Aby wykryć dostępność i w przeglądarkach, które nie obsługują tego interfejsu API, wrócić do obecnej implementacji, zalecamy użycie fragmentu kodu podobnego do tego poniżej.

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 ramach testów pochodzenia

Aby uzyskać jak najwięcej opinii od programistów korzystających w praktyce z interfejsu Decoding Info API (części Media Capabilities), dodaliśmy tę funkcję w Chrome 64 w wersji próbnej origin.

Okres próbny zakończył się w kwietniu 2018 r.

Intent to Experiment | Intent to Ship | Chromestatus Tracker | Chromium Bug

Odtwarzanie filmów HDR w systemie Windows 10

Filmy HDR mają większy kontrast, dzięki czemu cienie są bardziej precyzyjne i szczegółowe, a podświetlenia bardziej wyraźne niż kiedykolwiek wcześniej. Dodatkowo obsługa szerokiej gamy kolorów sprawia, że kolory są bardziej żywe.

Porównanie symulowanego SDR z HDR (aby zobaczyć prawdziwy HDR, potrzebujesz wyświetlacza HDR)
Symulowane porównanie SDR i HDR (aby zobaczyć prawdziwy HDR, potrzebujesz wyświetlacza HDR)

Odtwarzanie 10-bitowego formatu VP9 Profile 2 jest teraz obsługiwane w Chrome w systemie Windows 10 Fall Creator Update, więc Chrome obsługuje też odtwarzanie filmów HDR, gdy Windows 10 jest w trybie HDR. W kwestiach technicznych: Chrome 64 obsługuje teraz profil kolorów scRGB, który z kolei umożliwia odtwarzanie multimediów w HDR.

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

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

Na razie wystarczy mieć system Windows 10 Fall Creator Update, kartę graficzną i wyświetlacz zgodne z HDR (np. kartę NVIDIA z serii 10, telewizor lub monitor LG HDR) oraz włączyć tryb HDR w ustawieniach wyświetlania systemu Windows.

Deweloperzy stron internetowych mogą wykrywać przybliżoną gamę kolorów obsługiwaną przez urządzenie wyjściowe za pomocą niedawno wprowadzonego zapytania o media color-gamut oraz liczbę bitów używanych do wyświetlania koloru na ekranie za pomocą screen.colorDepth. Oto jeden ze sposobów wykorzystania tych informacji do wykrywania, czy na przykład 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 znaków kodeka VP9 z profilem 2 przekazywany do parametru isTypeSupported() w przykładzie powyżej musi zostać zaktualizowany na podstawie właściwości kodowania wideo.

Pamiętaj, że nie można jeszcze definiować kolorów HDR w CSS, canvas, obrazach i treściach chronionych. Zespół Chrome pracuje nad tym. Więcej informacji już wkrótce.

Trwałe licencje na systemy Windows i Mac

Trwała licencja w Encrypted Media Extensions (EME) oznacza, że licencja może być przechowywana na urządzeniu, dzięki czemu aplikacje mogą ją wczytywać do pamięci bez wysyłania kolejnego żądania licencji do serwera. W ten sposób odtwarzanie offline jest obsługiwane w EME.

Do tej pory tylko ChromeOS i Android obsługiwały licencje trwałe. To już nieprawda. Odtwarzanie treści chronionych za pomocą EME, gdy urządzenie jest offline, jest teraz możliwe w Chrome 64 w systemach 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 wypróbować licencje trwałe, sprawdzając przykładową aplikację PWA do obsługi multimediów i wykonując te czynności:

  1. Otwórz stronę https://biograf-155113.appspot.com/ttt/episode-2/.
  2. Kliknij „Udostępnij w trybie offline” i poczekaj, aż film zostanie pobrany.
  3. Wyłącz połączenie z internetem.
  4. Kliknij przycisk „Odtwórz” i obejrzyj film.

Domyślne wstępne wczytywanie multimediów to „metadata”

Zgodnie z implementacjami innych przeglądarek Chrome na komputery ustawia teraz domyślną wartość wstępnego wczytywania dla elementów <video> i <audio> na "metadata", aby zmniejszyć zużycie przepustowości i zasobów. Od Chrome 64 to nowe działanie jest stosowane tylko w przypadku, gdy nie jest ustawiona żadna wartość wstępnego wczytywania. Pamiętaj, że wskazówka atrybutu preload jest odrzucana, gdy do elementu multimedialnego jest dołączony element MediaSource, ponieważ strona internetowa obsługuje własne wstępne wczytywanie.

Innymi słowy, wartość wstępnego wczytywania <video> to teraz "metadata", a wartość wstępnego wczytywania <video preload="auto"> pozostaje "auto". Wypróbuj oficjalny przykład.

Intent to Ship | Chromestatus Tracker | Chromium Bug

Nieobsługiwana wartość playbackRate powoduje zgłoszenie wyjątku

W związku ze zmianą specyfikacji HTML, gdy element multimedialny ma atrybut playbackRate ustawiony na wartość nieobsługiwaną przez Chrome (np. wartość ujemną), w Chrome 63 zgłaszany jest błąd "NotSupportedError" DOMException.

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

Obecna implementacja Chrome zgłasza ten wyjątek, gdy playbackRate jest ujemne, mniejsze niż 0, 0625 lub większe niż 16. Wypróbuj oficjalny przykład, aby zobaczyć, jak to działa.

Intent to Ship | Chromestatus Tracker | Chromium Bug

Optymalizacje ścieżki wideo w tle

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

Jeśli film nie zawiera ś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). Jest to kontynuacja podobnej zmiany, która była stosowana tylko do filmów MSE w Chrome 62.

Błąd w Chromium

Usuwanie wyciszenia w przypadku ekstremalnych szybkości odtwarzania

W wersjach Chrome wcześniejszych niż 64 dźwięk był wyciszany, gdy wartość playbackRate była mniejsza niż 0,5 lub większa niż 4, ponieważ jakość dźwięku znacznie się pogarszała. Chrome przeszedł na metodę WSOLA (Waveform-Similarity-Overlap-Add), która obniża jakość dźwięku, więc nie trzeba już wyciszać dźwięku. Oznacza to, że możesz teraz odtwarzać dźwięk bardzo wolno i bardzo szybko.

Błąd w Chromium