Aggiornamenti di contenuti multimediali in Chrome 63/64

François Beaufort
François Beaufort
GitHub

API Media Capabilities - Decoding Info

Oggi, gli sviluppatori web si affidano a isTypeSupported() o canPlayType() per sapere vagamente se alcuni contenuti multimediali possono essere decodificati o meno. La vera domanda, però, dovrebbe essere: "quanto funzionerebbe bene su questo dispositivo?"

Questo è esattamente uno dei problemi che la proposta Media Capabilities vuole risolvere: un'API per interrogare il browser sulle capacità di decodifica del dispositivo in base a informazioni quali codec, profilo, risoluzione, bit rate e così via. Esporrebbe informazioni come la fluidità e l'efficienza energetica della riproduzione in base alle statistiche di riproduzione precedenti registrate dal browser.

In breve, ecco come funziona per ora l'API Decoding Info. Dai un'occhiata al campione ufficiale.

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.');
});

Puoi provare diverse configurazioni dei contenuti multimediali finché non trovi quella migliore (smooth e powerEfficient) e utilizzarla per riprodurre lo stream multimediale appropriato. L'attuale implementazione di Chrome si basa su informazioni di riproduzione registrate in precedenza. Definisce smooth come vero quando la percentuale di frame eliminati è inferiore al 10%, mentre powerEfficient è vero quando più del 50% dei frame viene decodificato dall'hardware. I piccoli frame sono sempre considerati a basso consumo energetico.

Ti consiglio di utilizzare uno snippet simile a quello riportato di seguito per rilevare la disponibilità e ripristinare l'implementazione corrente per i browser che non supportano questa 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;
  });
}

Disponibile per le prove dell'origine

Per ottenere il maggior numero possibile di feedback dagli sviluppatori che utilizzano l'API Decoding Info (parte di Media Capabilities) sul campo, in precedenza abbiamo aggiunto questa funzionalità in Chrome 64 come prova dell'origine.

La prova è terminata correttamente ad aprile 2018.

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

Riproduzione video HDR su Windows 10

I video High Dynamic Range (HDR) hanno un contrasto più elevato, rivelando ombre precise e dettagliate e luci straordinarie con una nitidezza mai vista prima. Inoltre, il supporto della gamma cromatica ampia significa che i colori sono più vivaci.

Confronto simulato tra SDR e HDR (per vedere l'HDR reale è necessario un display HDR)
Confronto simulato tra SDR e HDR (per vedere l'HDR reale è necessario un display HDR)

Poiché la riproduzione VP9 profilo 2 a 10 bit è ora supportata in Chrome per Windows 10 Fall Creator Update, Chrome supporta anche la riproduzione di video HDR quando Windows 10 è in modalità HDR. Da un punto di vista tecnico, Chrome 64 ora supporta il profilo di colore scRGB, che a sua volta consente la riproduzione dei contenuti multimediali in HDR.

Puoi provarlo guardando The World in HDR in 4K (ULTRA HD) su YouTube e verificando che la riproduzione sia in HDR controllando l'impostazione della qualità del player di YouTube.

Impostazione della qualità del video player di YouTube con HDR
Impostazione della qualità del video player di YouTube con HDR

Per ora ti servono Windows 10 Fall Creator Update, una scheda grafica e un display compatibili con HDR (ad es. scheda NVIDIA serie 10, TV o monitor LG HDR) e attivare la modalità HDR nelle impostazioni di visualizzazione di Windows.

Gli sviluppatori web possono rilevare la gamma di colori approssimativa supportata dal dispositivo di output con la recente query multimediale color-gamut e il numero di bit utilizzati per visualizzare un colore sullo schermo con screen.colorDepth. Ecco un modo per utilizzarli per rilevare, ad esempio, se è supportato 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"'))
}

La stringa del codec VP9 con profilo 2 passata a isTypeSupported() nell'esempio precedente deve essere aggiornata in base alle proprietà di codifica video.

Tieni presente che non è ancora possibile definire i colori HDR in CSS, canvas, immagini e contenuti protetti. Il team di Chrome ci sta lavorando. Continua a seguirci.

Licenze permanenti per Windows e Mac

La licenza persistente in Encrypted Media Extensions (EME) significa che la licenza può essere mantenuta sul dispositivo in modo che le applicazioni possano caricarla in memoria senza inviare un'altra richiesta di licenza al server. Ecco come la riproduzione offline è supportata in EME.

Fino ad ora, ChromeOS e Android erano le uniche piattaforme a supportare le licenze persistenti. Non è più così. La riproduzione di contenuti protetti tramite EME mentre il dispositivo è offline è ora possibile anche in Chrome 64 su Windows e Mac.

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.
});

Puoi provare le licenze persistenti consultando la PWA di esempio per contenuti multimediali e seguendo questi passaggi:

  1. Vai alla pagina https://biograf-155113.appspot.com/ttt/episode-2/
  2. Fai clic su "Rendi disponibile offline" e attendi il download del video.
  3. Disattiva la connessione a internet.
  4. Fai clic sul pulsante "Riproduci" e guarda il video.

Il precaricamento dei contenuti multimediali è impostato su "metadati" per impostazione predefinita

In linea con le implementazioni di altri browser, Chrome desktop ora imposta il valore di precaricamento predefinito per gli elementi <video> e <audio> su "metadata" per ridurre l'utilizzo di larghezza di banda e risorse. A partire da Chrome 64, questo nuovo comportamento si applica solo ai casi in cui non è impostato alcun valore di precaricamento. Tieni presente che il suggerimento dell'attributo di precaricamento viene ignorato quando un MediaSource viene allegato all'elemento multimediale perché il sito web gestisce il proprio precaricamento.

In altre parole, il valore di precaricamento di <video> ora è "metadata", mentre il valore di precaricamento di <video preload="auto"> rimane "auto". Prova il campione ufficiale.

Intent to Ship | Chromestatus Tracker | Chromium Bug

playbackRate non supportato genera un'eccezione

A seguito di una modifica delle specifiche HTML, quando playbackRate degli elementi multimediali è impostato su un valore non supportato da Chrome (ad es. un valore negativo), viene generato un "NotSupportedError" DOMException in Chrome 63.

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

A proposito, l'attuale implementazione di Chrome genera questa eccezione quando playbackRate è negativo, inferiore a 0, 0625 o superiore a 16. Prova l'esempio ufficiale per vedere questa funzionalità in azione.

Intent to Ship | Chromestatus Tracker | Chromium Bug

Ottimizzazioni della traccia video in background

Il team di Chrome è sempre alla ricerca di nuovi modi per migliorare la durata della batteria e Chrome 63 non fa eccezione.

Se il video non contiene tracce audio, verrà messo automaticamente in pausa quando viene riprodotto in background (ad es. in una scheda non visibile) nella versione desktop di Chrome (Windows, Mac, Linux e ChromeOS). Si tratta di un aggiornamento di una modifica simile che si applicava solo ai video MSE in Chrome 62.

Bug di Chromium

Rimuovere la disattivazione dell'audio per playbackRate estremi

Prima di Chrome 64, l'audio veniva disattivato quando playbackRate era inferiore a 0,5 o superiore a 4, in quanto la qualità si deteriorava in modo significativo. Poiché Chrome è passato a un approccio Waveform-Similarity-Overlap-Add (WSOLA) per la riduzione della qualità, l'audio non deve più essere disattivato. Ora puoi riprodurre il suono a velocità molto bassa e molto alta.

Bug di Chromium