- Os desenvolvedores da Web agora podem prever se a reprodução será suave e eficiente em termos de energia.
- O Chrome agora oferece suporte à reprodução de vídeo HDR no Windows 10.
- A reprodução off-line com licenças persistentes agora é compatível com Windows e Mac.
- O valor de pré-carregamento padrão para os elementos
<video>e<audio>agora é"metadata". - Agora, um erro é gerado quando a taxa de reprodução de mídia não é compatível.
- Agora o Chrome pausa todos os vídeos em segundo plano.
- O áudio não está mais desativado para playbackRate extremos.
Media Capabilities - Decoding Info API
Atualmente, os desenvolvedores da Web dependem de isTypeSupported() ou canPlayType() para saber de forma vaga
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 exibiria informações, como se a reprodução precisa ser suave e eficiente com base em 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. 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. 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.
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.
Tudo o que você precisa agora é da atualização Fall Creator do Windows 10, uma placa de vídeo e uma tela compatíveis com HDR (por exemplo, placa NVIDIA 10-series, 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 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 no 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 a PWA de mídia de exemplo e siga estas etapas:
- Acesse https://biograf-155113.appspot.com/ttt/episode-2/.
- Clique em "Tornar disponível 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 é "metadados"
Assim como outras implementações de navegador, o Chrome para computador agora define o valor de pré-carga
padrão para os elementos <video> e <audio> como "metadata" para
reduzir o uso de recursos e largura de banda. A partir do Chrome 64, esse novo comportamento só se aplica
a casos em que nenhum valor de pré-carregamento é 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
A playbackRate sem suporte 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.
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 era degradada significativamente. 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 reproduzir o som muito lento e
muito rápido agora.