- Agora os desenvolvedores da Web podem prever se a reprodução será simples e eficiente em termos de energia.
- O Chrome agora é compatível com a reprodução de vídeo HDR no Windows 10.
- A reprodução off-line com licenças persistentes é compatível com Windows e Mac.
- O valor de pré-carregamento padrão para elementos
<video>
e<audio>
agora é"metadata"
. - Um erro agora é gerado quando a taxa de reprodução de mídia não é aceita.
- Agora o Chrome pausa todas as mídias somente de vídeo em segundo plano.
- O áudio não está mais silenciado para uma taxa de reprodução extrema.
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.
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.
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:
- Acesse https://biograf-155113.appspot.com/ttt/episode-2/
- Clique em "Tornar disponível off-line" e aguarde o download do vídeo.
- Desative a conexão de Internet.
- 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.
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.