- 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.
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;
});
}
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.
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.
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.
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.