Aggiornamenti di contenuti multimediali in Chrome 63/64

François Beaufort
François Beaufort
GitHub

Funzionalità multimediali - API 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: "Che prestazioni avrebbe su questo dispositivo?"

Questa è esattamente una delle cose che le funzionalità multimediali proposte vogliono risolvere: un'API per eseguire una query al browser sulle capacità di decodifica del dispositivo in base a informazioni quali codec, profilo, risoluzione, velocità in bit e così via. Verranno mostrate informazioni quali se la riproduzione deve essere fluida ed efficiente in base alle precedenti statistiche di riproduzione registrate dal browser.

In breve, ecco come funziona al momento l'API Decoding Info. Guarda l'anteprima 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 utilizzarlo per riprodurre lo stream multimediale appropriato. A proposito, l'attuale implementazione di Chrome si basa sulle informazioni di riproduzione registrate in precedenza. Definisce smooth come true quando la percentuale di frame interrotti è inferiore al 10%, mentre powerEfficient è vero quando più del 50% dei frame viene decodificato dall'hardware. I frame piccoli sono sempre considerati a basso consumo.

Ti consiglio di utilizzare uno snippet simile a quello riportato di seguito per rilevare la disponibilità e utilizzare l'implementazione attuale 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 ricevere il maggior numero possibile di feedback dagli sviluppatori che utilizzano sul campo l'API Decoding Info (che fa parte delle funzionalità multimediali), in precedenza abbiamo aggiunto questa funzionalità in Chrome 64 come prova dell'origine.

La prova è terminata con successo ad aprile 2018.

Intenzione all'esperimento | Intento di spedizione | Tracker di Chromestatus | Bug di Chromium

Riproduzione di video HDR su Windows 10

I video HDR (High Dynamic Range) hanno un contrasto più elevato, rivelando ombre precise e dettagliate e alte luci sorprendenti con una nitidezza senza precedenti. Inoltre, il supporto di un'ampia gamma di colori significa che i colori sono più vivaci.

Confronto tra SDR e HDR simulato (per vedere la tecnologia HDR occorre un display HDR)
Confronto tra SDR e HDR simulato (per vedere la tecnologia HDR è necessario un display HDR)

Poiché la riproduzione a 10 bit di VP9 Profile 2 è ora supportata in Chrome per l'aggiornamento dei creator autunnali di Windows 10, Chrome supporta inoltre la riproduzione di video HDR quando Windows 10 è in modalità HDR. Una nota tecnica, Chrome 64 ora supporta il profilo colore scRGB, che a sua volta consente la riproduzione dei contenuti multimediali in HDR.

Puoi provare Il mondo in HDR in 4K (ULTRA HD) su YouTube e controllare che la riproduzione sia in HDR controllando l'impostazione di qualità del player di YouTube.

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

Per il momento tutto ciò di cui hai bisogno è Windows 10 Fall Creator Update, una scheda grafica e un display compatibili con HDR (ad esempio scheda NVIDIA 10-series, TV HDR o monitor LG) 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. Ad esempio, ecco un modo per rilevare se VP9 HDR è supportato:

// 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 se ne sta occupando. Continua a seguirci.

Licenze permanenti per Windows e Mac

Per licenza permanente in Encrypted Media Extensions (EME) è possibile mantenere la licenza 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.

Finora, ChromeOS e Android erano le uniche piattaforme a supportare le licenze permanenti. Non è più vero. 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 permanenti autonomamente consultando la PWA Media di esempio 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 che il video sia stato scaricato.
  3. Disattiva la connessione a internet.
  4. Fai clic sul pulsante "Riproduci" e goditi il video.

L'impostazione predefinita per il precaricamento dei contenuti multimediali è "metadata"

In base alle implementazioni di altri browser, Chrome per desktop ora imposta il valore di precaricamento predefinito per gli elementi <video> e <audio> su "metadata", in modo da 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 preload viene ignorato quando un MediaSource viene associato all'elemento multimediale mentre 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.

Intenzione di spedizione | Tracker dello stato di Chrome | Bug di Chromium

La velocità di riproduzione non supportata genera un'eccezione

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

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 solleva questa eccezione quando playbackRate è negativo, inferiore a 0, 0625 o maggiore di 16. Prova il campione ufficiale per vedere come funziona.

Intenzione di spedizione | Tracker dello stato di Chrome | Bug di Chromium

Ottimizzazioni della traccia video in background

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

Se il video non contiene tracce audio, verrà automaticamente messo in pausa quando riprodotto in background (ad esempio, in una scheda non visibile) sul desktop Chrome (Windows, Mac, Linux e ChromeOS). Questa è una risposta a una modifica simile che si applicava solo ai video MSE in Chrome 62.

Bug di Chromium

Rimuovi la disattivazione dell'audio per velocità di riproduzione estreme

Prima di Chrome 64, l'audio veniva disattivato quando playbackRate era inferiore a 0,5 o superiore a 4 poiché la qualità si deteriorava notevolmente. Dal momento che Chrome è passato a un approccio Waveform- somiglianza-sovrapposizione-Aggiungi (WSOLA) per il degrado della qualità, l'audio non deve più essere disattivato. Significa che puoi riprodurre un suono super lento e superveloce ora.

Bug di Chromium