Esta página foi traduzida pela API Cloud Translation.

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

François Beaufort

Os desenvolvedores Web agora podem prever se a reprodução será simples e com baixo consumo de energia.
O Chrome agora é compatível com a reprodução de vídeo HDR no Windows 10.
Reprodução off-line com licenças persistentes são compatíveis com Windows e Mac.
O valor de pré-carregamento padrão para <video> e Os elementos <audio> agora são "metadata".
Agora, um erro é gerado quando a mídia A velocidade do vídeo não é compatível.
O Chrome agora pausa todas as mídias somente vídeo em segundo plano.
O áudio não está mais desativado para taxa de reprodução extrema.

Recursos de mídia - API de decodificação de informações

Atualmente, os desenvolvedores Web dependem do isTypeSupported() ou do canPlayType() para vagar se alguma mídia pode ou não ser decodificada. No entanto, a verdadeira pergunta deve ser: "Qual seria o desempenho desse dispositivo?"

Essa é exatamente uma das coisas 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. exporia informações, por exemplo, se a reprodução deve ser suave e de baixo consumo de energia com base em estatísticas de reprodução anteriores registradas pelo navegador.

Em resumo, veja como a API Deencoding Info funciona por enquanto. Consulte o 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 configurações de mídia diferentes até encontrar a melhor (smooth e powerEfficient) e use-o para reproduzir a mídia adequada riacho. Aliás, a implementação atual do Chrome é baseada nos dados informações de reprodução gravadas. Ela define smooth como verdadeira quando a porcentagem de frames perdidos é inferior a 10%, enquanto powerEfficient é verdadeiro quando mais de 50% dos frames são decodificados pelo hardware. Frames pequenos são sempre considerado eficiente em termos de energia.

Observação:o resultado retornado de navigator.mediaCapabilities.decodingInfo vai sempre será relatada como suave e de baixo consumo energético se a configuração de mídia for compatível e as estatísticas de reprodução ainda não foram registradas pelo navegador.

Recomendo usar um snippet semelhante ao abaixo para detectar disponibilidade e voltar para sua implementação atual para navegadores que não têm suporte para esta 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;
  });
}

Atenção:o snippet acima precisa usar canPlayType() em vez de isTypeSupported(). se o tipo de configuração de mídia for "file".

Disponível para testes de origem

Para obter o máximo de feedback possível dos desenvolvedores usando o módulo "Decodificação" API Info (parte das Capacidades de mídia) no campo; já adicionamos isso no Chrome 64 como um teste de origem.

O teste terminou em abril de 2018.

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

Reprodução de vídeos em HDR no Windows 10

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

Comparação entre SDR simulado e HDR (para ver o HDR real é preciso ter uma tela HDR)

Como o VP9 Profile 2 em 10 bits agora é compatível com o Chrome para Windows 10 Fall Atualização para criadores de conteúdo: o Chrome também oferece suporte à reprodução de vídeos em HDR no Windows 10 está no modo HDR. Observação técnica: o Chrome 64 agora é compatível com a cor scRGB que permite a reprodução de mídia em HDR.

Teste esse recurso assistindo ao vídeo O mundo em HDR em 4K (ULTRA HD) no YouTube e verifique se ele é reproduzido em HDR nas configurações de qualidade do player do YouTube.

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

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

Os desenvolvedores Web podem detectar a gama aproximada de cores aceita pela saída dispositivo com a consulta de mídia da gama recente de cores e o número de bits usados para mostrar uma cor na tela com screen.colorDepth. Aqui está uma maneira de usar 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 o perfil 2 passada para isTypeSupported() no exemplo acima precisa ser atualizado 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údos protegidos. A equipe do Chrome está trabalhando nisso. Não perca!

Licenças persistentes para Windows e Mac

A licença persistente no Encrypted Media Extensions (EME) significa que a licença pode mantidos 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 é suportada no EME.

Até agora, ChromeOS e Android eram as únicas plataformas com suporte a discos permanentes licenças. Não é mais verdade. Assistir conteúdo protegido usando o EME enquanto o dispositivo também está off-line 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:

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

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

Correspondendo a outros navegadores implementações, a área de trabalho do Chrome agora define pré-carregar o valor dos elementos <video> e <audio> para "metadata" a fim de reduzir o uso de recursos e largura de banda. A partir do Chrome 64, esse novo comportamento se aplica apenas aos casos em que nenhum valor de pré-carregamento está definido. A classe do atributo pré-carregamento A dica é descartada quando um MediaSource é anexado ao elemento de mídia como o site lida com o próprio pré-carregamento.

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

Intent de envio | Rastreador Chromestatus | Bug do Chromium

A taxa de reprodução sem suporte gera uma exceção

Após uma alteração na especificação HTML, quando o código-fonte dos elementos de mídia playbackRate for definido com 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
}

Aliás, a implementação atual do Chrome gera essa exceção quando playbackRate é negativo, menor que 0, 0625 ou maior que 16. Faça um teste ao exemplo oficial para ver isso em ação.

Intent de envio | Rastreador Chromestatus | Bug do Chromium

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

A equipe do Chrome está sempre buscando 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 nenhuma faixa de áudio, ele será automaticamente pausado quando reproduzido em segundo plano (por exemplo, em uma guia não visível) no Chrome computador (Windows, Mac, Linux e ChromeOS). Este é um acompanhamento de um mudança semelhante que se aplicava apenas a vídeos de MSE no Chrome 62.

Bug do Chromium

Remoção do silenciamento para taxas de reprodução extremas

Antes do Chrome 64, o som era desativado quando o playbackRate estava abaixo de 0,5 ou superior a 4. já que a qualidade piorou significativamente. Como o Chrome mudou para uma Abordagem de onda, similaridade, sobreposição e adição (WSOLA, na sigla em inglês) para degradação da qualidade, som não precisa mais ser silenciado. Significa que você pode tocar um som muito devagar e super-rápido agora.

Bug do Chromium