- O Chrome é compatível com a decodificação de vídeo AV1.
- Consulte quais esquemas de criptografia são compatíveis por meio de O EME já está disponível.
- Os desenvolvedores Web podem fazer experimentos consultando se uma determinada política HDCP pode ser aplicada.
- As extensões de origem de mídia agora usam PTS para intervalos e valores de duração em buffer.
- Os usuários do Android Go podem abrir áudio, vídeo e imagens transferidos por download no Chrome.
- Os eventos parados de elementos de mídia que usam MSE são removidos.
Decodificador de vídeo AV1
Rastreador Chromestatus | Bug do Chromium
EME: consulta ao suporte a esquemas de criptografia
Algumas plataformas ou sistemas importantes oferecem suporte apenas ao modo CENC, enquanto outros só são compatíveis Modo CBCS. Outros ainda são capazes de manter os dois. Esses dois esquemas de criptografia são incompatíveis, e os desenvolvedores da Web precisam fazer escolhas inteligentes sobre qual conteúdo veicular.
Para evitar ter que determinar em qual plataforma ele verifica se há "conhecidas"
suporte a esquema de criptografia, uma nova chave encryptionScheme
será adicionada
MediaKeySystemMediaCapability
dicionário para permitir que os sites especifiquem
qual esquema de criptografia pode ser usado no Encrypted Media Extensions (EME).
A nova chave encryptionScheme
pode ter um destes dois valores:
'cenc'
Amostra completa do modo AES-CTR e criptografia de subamostra NAL do vídeo.'cbcs'
Criptografia de padrão NAL de vídeo parcial do modo AES-CBC.
Se não for especificado, qualquer esquema de criptografia será aceito. Observação
que Clear Key sempre oferece suporte ao esquema 'cenc'
.
O exemplo abaixo mostra como consultar duas configurações com diferentes esquemas de criptografia. Neste caso, apenas um será escolhido.
await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [
{
label: 'configuration using the "cenc" encryption scheme',
videoCapabilities: [{
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cenc'
}],
audioCapabilities: [{
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cenc'
}],
initDataTypes: ['keyids']
},
{
label: 'configuration using the "cbcs" encryption scheme',
videoCapabilities: [{
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cbcs'
}],
audioCapabilities: [{
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cbcs'
}],
initDataTypes: ['keyids']
},
]);
No exemplo abaixo, apenas uma configuração com duas chaves de criptografia é consultado. Nesse caso, o Chrome vai descartar todos os objetos de recursos ele não é compatível. Portanto, a configuração acumulada pode conter um código ou ambos.
await navigator.requestMediaKeySystemAccess('org.w3.clearkey', [{
videoCapabilities: [
{ // A video capability using the "cenc" encryption scheme
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cenc'
},
{ // A video capability using the "cbcs" encryption scheme
contentType: 'video/mp4; codecs="avc1.640028"',
encryptionScheme: 'cbcs'
},
],
audioCapabilities: [
{ // An audio capability using the "cenc" encryption scheme
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cenc'
},
{ // An audio capability using the "cbcs" encryption scheme
contentType: 'audio/mp4; codecs="mp4a.40.2"',
encryptionScheme: 'cbcs'
},
],
initDataTypes: ['keyids']
}]);
Intenção de implementar | Rastreador Chromestatus | Bug do Chromium
EME: verificação da política HDCP
Atualmente, o HDCP é um requisito de política comum para streaming em alta resolução de conteúdo protegido. E desenvolvedores Web que quiserem aplicar uma política HDCP precisa aguardar a conclusão da troca de licenças ou iniciar o streaming conteúdo em baixa resolução. É uma situação triste que a Política do HDCP API Check, tem como objetivo resolver.
Com a API proposta, os desenvolvedores Web podem consultar se uma determinada política HDCP
podem ser aplicadas para que a reprodução seja iniciada na resolução ideal para
a melhor experiência do usuário. Ele consiste em um método simples para consultar o status de
uma chave hipotética associada a uma política de HDCP, sem a necessidade de criar uma
MediaKeySession
ou busque uma licença real. Não é necessário que MediaKeys
seja
a qualquer elemento de áudio ou vídeo.
A API HDCP Policy Check funciona simplesmente chamando
mediaKeys.getStatusForPolicy()
por um objeto que tem uma chave minHdcpVersion
.
e um valor válido. Se HDCP estiver disponível na versão especificada, o
promessa é resolvida com um MediaKeyStatus
de 'usable'
. Caso contrário, a promessa
é resolvido com outros valores de erro de MediaKeyStatus
, como
'output-restricted'
ou 'output-downscaled'
. Se o sistema de chaves
oferecer suporte à verificação de política HDCP (por exemplo, Clear Key System), a promessa será rejeitada.
Em resumo, veja como a API funciona por enquanto. Confira o exemplo oficial para testar todas as versões da HDCP.
const config = [{
videoCapabilities: [{
contentType: 'video/webm; codecs="vp09.00.10.08"',
robustness: 'SW_SECURE_DECODE' // Widevine L3
}]
}];
navigator.requestMediaKeySystemAccess('com.widevine.alpha', config)
.then(mediaKeySystemAccess => mediaKeySystemAccess.createMediaKeys())
.then(mediaKeys => {
// Get status for HDCP 2.2
return mediaKeys.getStatusForPolicy({ minHdcpVersion: '2.2' })
.then(status => {
if (status !== 'usable')
return Promise.reject(status);
console.log('HDCP 2.2 can be enforced.');
// TODO: Fetch high resolution protected content...
});
})
.catch(error => {
// TODO: Fallback to fetch license or stream low-resolution content...
});
Disponível para testes de origem
Para receber feedback dos desenvolvedores Web, adicionamos a política HDCP Confira o recurso da API no Chrome 69 para computador (ChromeOS, Linux, Mac e Windows).
O teste terminou em novembro de 2018.
Intenção de fazer experimentos | Rastreador Chromestatus | Bug do Chromium
Compliance com MSE PTS/DTS
Os intervalos e valores de duração em buffer agora são informados pelo carimbo de data/hora da apresentação (PTS), em vez de decodificar intervalos de carimbo de data/hora (DTS) em Mídia Source Extensions (MSE).
Quando o MSE era novo, a implementação do Chrome era testada em WebM e MP3, alguns formatos de streaming de mídia sem distinção entre PTS e DTS. E estava funcionando bem até a adição do ISO BMFF (também conhecido como MP4). Este contêiner frequentemente contém apresentação fora de ordem versus fluxos de tempo de decodificação (por codecs como H.264, por exemplo) fazendo com que DTS e PTS sejam diferentes. Isso causou Chrome para informar (geralmente um pouco) intervalos e durações diferentes em buffer valores do que o esperado. Esse novo comportamento será lançado gradualmente no Chrome 69 e fazer com que a implementação do MSE fique em conformidade com a especificação do MSE.
Essa mudança afeta o MediaSource.duration
(e, consequentemente,
HTMLMediaElement.duration
), SourceBuffer.buffered
(e, consequentemente,
HTMLMediaElement.buffered)
e SourceBuffer.remove(start, end)
.
Se você não tiver certeza de qual método é usado para informar os intervalos e a duração em buffer
você pode ir para a página interna do chrome://media-internals
e pesquisar
"ChunkDemuxer: armazenamento em buffer pelo PTS" ou "ChunkDemuxer: buffering by DTS" no
ou de sistemas operacionais de contêineres.
Intenção de implementar | Bug do Chromium
Processamento de intents de visualização de mídia no Android Go
O Android Go é uma versão leve do Android projetada para e smartphones. Para isso, ele não é necessariamente enviado com algum tipo de visualização de mídia aplicativos. Assim, se um usuário tentar abrir um vídeo baixado, por exemplo, ele não terá aplicativos para lidar com essa intent.
Para corrigir isso, o Chrome 69 no Android Go agora detecta intents de visualização de mídia os usuários podem acessar áudio, vídeos e imagens baixados. Em outras palavras, é preciso no lugar dos aplicativos de visualização ausentes.
Esse recurso do Chrome está ativado em todos os dispositivos com Android O e versões posteriores com 1 GB de RAM ou menos.
Remoção de "parado" eventos para elementos de mídia usando EQM
Um erro "parado" é gerado em um elemento de mídia se o download dos dados de mídia
não conseguiu avançar por cerca de 3 segundos. Ao usar extensões da fonte de mídia
(MSE), o app da Web gerencia o download e o elemento de mídia não tem conhecimento
seu progresso. Isso fez com que o Chrome gerasse eventos inadequados
vezes que o site não anexar novos blocos de dados de mídia com
SourceBuffer.appendBuffer()
nos últimos 3 segundos.
Como os sites podem decidir anexar grandes blocos de dados a uma frequência baixa, isso não é um indicador útil sobre a integridade do buffer. Removendo "parados" eventos para elementos de mídia que usam o MSE, simplificando o processo e alinhando o Chrome com a especificação MSE. Os elementos de mídia que não usam MSE vão continuar com a geração "interrompida" e eventos da mesma forma que acontece atualmente.
Intenção de descontinuar e remover | Rastreador Chromestatus | Bug do Chromium