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

François Beaufort
François Beaufort

Recursos de mídia - API Decoding Info

Atualmente, os desenvolvedores da Web dependem de isTypeSupported() ou canPlayType() para saber vagamente se alguma mídia pode ser decodificada ou não. A pergunta é: "qual seria o desempenho neste dispositivo?".

Esse é exatamente um dos problemas que os recursos de mídia 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. Isso expõe informações como se a reprodução precisa ser estável e confortável em termos de energia com base em estatísticas de reprodução anteriores registradas pelo navegador.

Em poucas palavras, veja como a API Decoding Info funciona por enquanto. Confira o exemplo oficial (link em inglês).

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. Aliás, a implementação atual do Chrome é baseada em informações de reprodução gravadas anteriormente. Ela define smooth como verdadeira quando a porcentagem de frames descartados é menor que 10%, enquanto powerEfficient é definido como verdadeiro quando mais de 50% dos frames são decodificados pelo hardware. Frames pequenos são sempre considerados com baixo consumo de energia.

Recomendamos usar um snippet semelhante ao abaixo para detectar a disponibilidade e voltar à sua implementação atual para navegadores que não são compatíveis com 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 de desenvolvedores que usam a API Decoding Info (parte dos recursos de mídia) no campo, adicionamos anteriormente esse recurso no Chrome 64 como um teste de origem.

O teste terminou em abril de 2018.

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

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

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

Comparação entre SDR e HDR simulado (para ver o HDR verdadeiro requer uma tela HDR)
Comparação entre SDR e HDR simulado (para ver o HDR verdadeiro é necessário usar uma tela HDR)

Como a reprodução de 10 bits do perfil 2 do VP9 agora tem suporte na atualização do Chrome para o Windows 10 Fall Creator, o Chrome também oferece suporte à reprodução de vídeos HDR quando o Windows 10 está no modo HDR. Em termos técnicos, o Chrome 64 agora oferece suporte ao perfil de cor scRGB, que, por sua vez, permite que a mídia seja reproduzida em HDR.

Para testar, assista O Mundo em HDR em 4K (ULTRA HD) no YouTube e confira a configuração de qualidade do player do YouTube para conferir se o conteúdo é reproduzido em HDR.

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 gráfica e tela compatíveis com HDR (por exemplo, placa da série NVIDIA 10, TV ou monitor LG HDR) e ativar o modo HDR nas configurações de exibição do Windows.

Os desenvolvedores da Web podem detectar a gama aproximada de cores compatível com o dispositivo de saída com a consulta de mídia de gama de cores recente e o número de bits usados para mostrar uma cor na tela com screen.colorDepth. Confira uma maneira de usá-los para detectar se há suporte ao VP9 HDR, 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 suas 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 as novidades!

Licenças persistentes para Windows e Mac

Uma licença persistente em Encrypted Media Extensions (EME) significa que ela pode ser mantida no dispositivo para que os apps 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 tem suporte no EME.

Até agora, o ChromeOS e o Android eram as únicas plataformas que aceitavam licenças persistentes. Isso não é mais verdade. A reprodução de conteúdo protegido pelo EME enquanto o dispositivo está off-line também é possível no Chrome 64 no Windows e no 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 licenças persistentes, confira o Sample Media PWA 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 a conexão de Internet.
  4. Clique no botão "Reproduzir" e aproveite o vídeo!

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

Correspondendo às implementações de outros navegadores, o Chrome para computador agora define o valor padrão de pré-carregamento dos elementos <video> e <audio> como "metadata" para reduzir o uso da largura de banda e dos recursos. A partir do Chrome 64, esse novo comportamento só se aplica aos casos em que nenhum valor de pré-carregamento é definido. A dica do atributo 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 <video> agora é "metadata", enquanto o valor de pré-carregamento <video preload="auto"> permanece "auto". Teste o exemplo oficial (link em inglês).

Intent de envio | Rastreador de status do Chrome | Bug do Chromium

A reprodução não compatível gera uma exceção

Após uma mudança na especificação HTML, quando playbackRate dos elementos de mídia é definido como um valor não compatível com o 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
}

Aliás, a implementação atual do Chrome gera essa exceção quando playbackRate é negativo, menor que 0, 0625 ou maior que 16. Teste o exemplo oficial (link em inglês) para ver como isso funciona.

Intent de envio | Rastreador de status do Chrome | Bug do Chromium

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

A equipe do Chrome está sempre tentando 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). Esta é uma continuação de uma alteração semelhante que foi aplicada apenas a vídeos ME no Chrome 62.

Bug do Chromium

Remover o som para taxas extremas de reprodução

Antes do Chrome 64, o som era desativado quando playbackRate estava abaixo de 0,5 ou acima de 4, porque a qualidade era significativamente mais reduzida. Como o Chrome adotou uma abordagem Waveform-Similarity-Overlay-Add (WSOLA) para degradação da qualidade, o som não precisa mais ser desativado. Isso significa que você pode tocar um som muito lento e super-rápido agora.

Bug do Chromium