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

François Beaufort
François Beaufort
GitHub

API Media Capabilities - Decoding Info

Hoje, os desenvolvedores da Web usam isTypeSupported() ou canPlayType() para saber vagamente se alguma mídia pode ser decodificada ou não. A pergunta real, no entanto, deve ser: "Qual seria o desempenho dele neste dispositivo?"

Esse é exatamente um dos problemas que a Media Capabilities proposta quer 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 exporia informações como se a reprodução seria suave e eficiente em termos de energia com base em estatísticas de reprodução anteriores registradas pelo navegador.

Em resumo, veja como a API Decoding Info funciona por enquanto. Confira a amostra 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 stream de mídia adequado. A propósito, a implementação atual do Chrome é baseada em informações de reprodução gravadas anteriormente. Ele define smooth como verdadeiro quando a porcentagem de frames descartados é inferior a 10%, enquanto powerEfficient é verdadeiro quando mais de 50% dos frames são decodificados pelo hardware. Frames pequenos são sempre considerados eficientes em termos de energia.

Recomendo usar um snippet semelhante ao abaixo para detectar a disponibilidade e voltar à sua 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 das Capacidades de mídia) no campo, adicionamos esse recurso no Chrome 64 como um teste de origem.

O teste foi concluído em abril de 2018.

Intenção de testar | Intenção de lançar | Rastreador do Chromestatus | Bug do Chromium

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

Os vídeos em alto alcance dinâmico (HDR) têm maior contraste, revelando sombras precisas e detalhadas e destaques impressionantes 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 verdadeiro, é necessário ter uma tela HDR)
Comparação simulada de SDR e HDR. Para ver o HDR verdadeiro, é necessário um display HDR.

Como a reprodução de 10 bits do VP9 Profile 2 agora é compatível com o Chrome para a atualização do Windows 10 Fall Creator, o Chrome também oferece suporte à reprodução de vídeo HDR quando o Windows 10 está no modo HDR. Em uma observação 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 vídeo está sendo 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

Por enquanto, você só precisa do Windows 10 Fall Creator Update, uma placa de vídeo e uma tela compatíveis com HDR (por exemplo, placa NVIDIA série 10, TV ou monitor HDR LG) e ativar o modo HDR nas configurações de exibição do Windows.

Os desenvolvedores da Web podem detectar a gama de cores aproximada compatível com o dispositivo de saída usando a consulta de mídia color-gamut e o número de bits usados para mostrar uma cor na tela com screen.colorDepth. Veja uma maneira de usar esses recursos 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 de 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, canvas, imagens e conteúdo protegido. A equipe do Chrome está trabalhando nisso. Não perca!

Licenças permanentes para Windows e Mac

A licença persistente em Encrypted Media Extensions (EME) significa que ela 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 ao servidor. É assim que a reprodução off-line é compatível com EME.

Até agora, o ChromeOS e o Android eram as únicas plataformas compatíveis com licenças permanentes. Isso não é mais verdade. Agora também é possível reproduzir conteúdo protegido usando 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.
});

Você pode testar as licenças persistentes conferindo o PWA de mídia de amostra e seguindo estas etapas:

  1. Acesse https://biograf-155113.appspot.com/ttt/episode-2/
  2. Clique em "Disponibilizar 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 pré-carregamento de mídia usa "metadata" como padrão

Assim como outros navegadores, o Chrome para computador agora define o valor de pré-carregamento padrão para elementos <video> e <audio> como "metadata" para reduzir o uso de largura de banda e recursos. A partir do Chrome 64, esse novo comportamento só se aplica a 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é-carga <video> agora é "metadata", enquanto o valor de pré-carga <video preload="auto"> permanece "auto". Teste a amostra oficial.

Intenção de envio | Rastreador do Chromestatus | Bug do Chromium

Unsupported playbackRate raises an exception

Após uma mudança na especificação HTML, quando o playbackRate dos elementos de mídia é definido como um valor não compatível com o Chrome (por exemplo, um valor negativo), um "NotSupportedError" DOMException é gerado 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 propósito, a implementação atual do Chrome gera essa exceção quando playbackRate é negativo, menor que 0, 0625 ou maior que 16. Confira a amostra oficial para ver isso em ação.

Intenção de envio | Rastreador do Chromestatus | Bug do Chromium

Otimizações de faixas 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 uma 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 era aplicada apenas 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 ficava abaixo de 0,5 ou acima de 4, já que a qualidade diminuía significativamente. Como o Chrome mudou para uma abordagem de Waveform-Similarity-Overlap-Add (WSOLA) para degradação da qualidade, não é mais necessário silenciar o som. Isso significa que agora você pode tocar o som super lento e super rápido.

Bug do Chromium