Atualizações de mídia no Chrome 63/64

François Beaufort
François Beaufort
GitHub

Media Capabilities - Decoding Info API

Atualmente, os desenvolvedores da Web dependem de isTypeSupported() ou canPlayType() para saber vagamente se alguns tipos de mídia podem ser decodificados ou não. A pergunta real, no entanto, é: "Qual seria o desempenho dele nesse dispositivo?"

Essa é exatamente uma das coisas que os Media Capabilities propostos querem resolver: uma API para consultar o navegador sobre as capacidades de decodificação do dispositivo com base em informações como codecs, perfil, resolução, taxas de bits etc. Ela expõe informações, como se a reprodução precisa ser suave e eficiente com base nas estatísticas de reprodução anteriores gravadas pelo navegador.

Em resumo, confira como a API Decoding Info funciona por enquanto. Confira o exemplo oficial.

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

Você pode testar diferentes configurações de mídia até encontrar a melhor (smooth e powerEfficient) e usá-la para reproduzir o fluxo de mídia adequado. A implementação atual do Chrome é baseada em informações de reprodução gravadas anteriormente. Ela define smooth como "true" quando a porcentagem de frames descartados é menor que 10%, enquanto powerEfficient é "true" quando mais de 50% dos frames são decodificados pelo hardware. Os frames pequenos são sempre considerados eficientes em termos de energia.

Recomendamos usar um snippet semelhante ao abaixo para detectar a disponibilidade e usar a implementação atual para navegadores que não oferecem suporte a essa 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;
  });
}

Disponível para testes de origem

Para receber o máximo de feedback possível dos desenvolvedores que usam a API Decoding Info (parte dos Capabilities de mídia) no campo, adicionamos esse recurso no Chrome 64 como um teste de origem.

O teste foi encerrado em abril de 2018.

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

Reprodução de vídeo HDR no Windows 10

Os vídeos em HDR (High Dynamic Range) têm maior contraste, revelando sombras precisas e detalhadas e destaques incríveis com mais clareza do que nunca. Além disso, o suporte à ampla gama de cores significa que as cores são mais vibrantes.

Comparação simulada de SDR x HDR (para ver o HDR real, é necessário ter uma tela HDR)
SDR simulado x comparação HDR (para ver o HDR real, é necessário ter uma tela HDR)

Como a reprodução VP9 Profile 2 de 10 bits agora tem suporte no Chrome para a atualização de outono do Windows 10 para criadores, o Chrome também oferece suporte à reprodução de vídeo HDR quando o Windows 10 está no modo HDR. Em uma nota técnica, o Chrome 64 agora oferece suporte ao perfil de cor scRGB, que permite a reprodução de mídia em HDR.

Para testar, assista The World in HDR in 4K (ULTRA HD) no YouTube e verifique se o conteúdo é reproduzido em HDR na configuração de qualidade do player do YouTube.

Configuração de qualidade do player do YouTube com HDR
Configuração de qualidade do player do YouTube com HDR

Tudo o que você precisa por enquanto é o Windows 10 Fall Creator Update, uma placa gráfica e uma tela compatíveis com HDR (por exemplo, placa NVIDIA 10-Series, LG HDR TV ou monitor) e ativar o modo HDR nas configurações de tela do Windows.

Os desenvolvedores da Web podem detectar a gama de cores aproximada suportada pelo dispositivo de saída com a recente consulta de mídia de gama de cores e o número de bits usados para exibir uma cor na tela com screen.colorDepth. Confira uma maneira de usar essas informações para detectar se o VP9 HDR é compatível, por exemplo:

// 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"'))
}

A string do codec VP9 com perfil 2 transmitida para isTypeSupported() no exemplo acima precisa ser atualizada com base nas propriedades de codificação de vídeo.

Ainda não é possível definir cores HDR em CSS, tela, imagens e conteúdo protegido. A equipe do Chrome está trabalhando nisso. Não perca!

Licenças persistentes para Windows e Mac

Uma licença persistente em Extensões de mídia criptografada (EME) significa que a licença pode ser mantida no dispositivo para que os aplicativos possam carregar a licença na memória sem enviar outra solicitação de licença para o servidor. É assim que a reprodução off-line tem suporte no EME.

Até agora, o ChromeOS e o Android eram as únicas plataformas com suporte a licenças persistentes. Isso não é mais verdade. Agora é possível reproduzir conteúdo protegido pelo EME enquanto o dispositivo está off-line no Chrome 64 para 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.
});

Para testar as licenças persistentes, confira o exemplo de PWA de mídia e siga estas etapas:

  1. Acesse https://biograf-155113.appspot.com/ttt/episode-2/.
  2. Clique em "Tornar disponível off-line" e aguarde o download do vídeo.
  3. Desative sua conexão de Internet.
  4. Clique no botão "Reproduzir" e aproveite o vídeo.

O padrão de pré-carregamento de mídia é "metadados"

Combinando as implementações de outros navegadores, o Chrome para computador agora define o valor de pré-carregamento padrão dos elementos <video> e <audio> como "metadata", reduzindo o uso da largura de banda e de recursos. A partir do Chrome 64, esse novo comportamento só se aplica aos casos em que nenhum valor de pré-carregamento está definido. A dica do atributo de pré-carregamento é descartada quando um MediaSource é anexado ao elemento de mídia, já que o site processa o próprio pré-carregamento.

Em outras palavras, o valor de pré-carregamento de <video> agora é "metadata", enquanto o valor de pré-carregamento de <video preload="auto"> permanece "auto". Teste o exemplo oficial.

Intent to Ship | Rastreador do Chromestatus | Bug do Chromium

playbackRate não compatível gera uma exceção

Após uma mudança na especificação do HTML, quando a playbackRate dos elementos de mídia é definida como um valor sem suporte do Chrome (por exemplo, um valor negativo), uma "NotSupportedError" DOMException é gerada no Chrome 63.

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

A implementação atual do Chrome gera essa exceção quando playbackRate é negativo, menor que 0,0625 ou maior que 16. Teste a amostra oficial para conferir isso em ação.

Intent to Ship | Rastreador do Chromestatus | Bug do Chromium

Otimizações de faixa de vídeo em segundo plano

A equipe do Chrome sempre tenta encontrar novas maneiras de melhorar a duração da bateria, e o Chrome 63 não foi exceção.

Se o vídeo não tiver faixas de áudio, ele será pausado automaticamente quando for reproduzido em segundo plano (por exemplo, em uma guia não visível) no Chrome para computador (Windows, Mac, Linux e ChromeOS). Essa é uma continuação de uma mudança semelhante que só era aplicada a vídeos MSE no Chrome 62.

Bug do Chromium

Remover o silenciamento para playbackRates extremos

Antes do Chrome 64, o som era silenciado quando playbackRate estava abaixo de 0,5 ou acima de 4, porque a qualidade estava muito ruim. Como o Chrome mudou para uma abordagem de Waveform-Similarity-Overlap-Add (WSOLA, na sigla em inglês) para a redução de qualidade, o som não precisa mais ser silenciado. Isso significa que você pode tocar um som muito lento e rápido agora.

Bug do Chromium