- O Chrome tem suporte à decodificação de vídeo AV1.
- A consulta quais esquemas de criptografia são compatíveis com a EME já está disponível.
- Os desenvolvedores da Web podem consultar se uma determinada política de HDCP pode ser aplicada.
- As extensões de origem de mídia agora usam PTS para intervalos em buffer e valores de duração.
- Os usuários do Android Go podem abrir áudios, vídeos e imagens transferidos por download no Chrome.
- Os eventos interrompidos de elementos de mídia que usam o MSE são removidos.
Decodificador de vídeo AV1
Chromestatus Tracker | Bug do Chromium
EME: consulta ao suporte a esquemas de criptografia
Algumas plataformas ou principais sistemas oferecem suporte apenas ao modo CENC, enquanto outros oferecem suporte apenas ao modo CBCS. Ainda há outras pessoas que oferecem suporte a ambos. Esses dois esquemas de criptografia são incompatíveis, portanto, os desenvolvedores da Web precisam ser capazes de fazer escolhas inteligentes sobre qual conteúdo veicular.
Para evitar ter que determinar em qual plataforma eles estão para verificar o suporte ao esquema
de criptografia "conhecido", uma nova chave encryptionScheme
é adicionada no
dicionário MediaKeySystemMediaCapability
para permitir que os sites especifiquem
qual esquema de criptografia pode ser usado nas extensões de mídia criptografada (EME, na sigla em inglês).
A nova chave encryptionScheme
pode ser um destes dois valores:
'cenc'
Amostra completa no modo AES-CTR e criptografia de subamostra NAL de vídeo.'cbcs'
Criptografia do padrão NAL de vídeo parcial no modo AES-CBC.
Se não for especificado, indica que qualquer esquema de criptografia é aceitável. Observe
que Clear Key sempre oferece suporte ao esquema 'cenc'
.
O exemplo abaixo mostra como consultar duas configurações com esquemas de criptografia diferentes. Nesse 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 dois esquemas de criptografia diferentes é consultada. Nesse caso, o Chrome vai descartar todos os objetos de recursos que não podem ter suporte. Assim, a configuração acumulada pode conter um esquema de criptografia 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']
}]);
Intent de implementação | Chromestatus Tracker | Bug do Chromium
EME: verificação da política HDCP
Atualmente, o HDCP é um requisito de política comum para transmitir em alta resolução de conteúdo protegido. Os desenvolvedores da Web que quiserem aplicar uma política de HDCP precisam aguardar a conclusão da troca de licença ou iniciar o streaming de conteúdo em baixa resolução. Esta é uma situação triste que a API HDCP Policy Check busca resolver.
Essa API proposta permite que os desenvolvedores da Web consultem se é possível aplicar uma determinada política HDCP
para que a reprodução possa ser 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 um
MediaKeySession
ou buscar uma licença real. Ele também não exige que MediaKeys
seja
anexado a elementos de áudio ou vídeo.
A API HDCP Policy Check funciona simplesmente chamando
mediaKeys.getStatusForPolicy()
com um objeto que tenha uma chave minHdcpVersion
e um valor válido. Se HDCP estiver disponível na versão especificada, a promessa retornada será resolvida com um MediaKeyStatus
de 'usable'
. Caso contrário, a promessa
é resolvida com outros valores de erro de MediaKeyStatus
, como
'output-restricted'
ou 'output-downscaled'
. Se o sistema de chaves não for compatível com a verificação de política HDCP (por exemplo, o sistema de chave de limpeza), a promessa será rejeitada.
Em resumo, é assim que a API funciona por enquanto. Confira o exemplo oficial (link em inglês) para testar todas as versões do 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 de desenvolvedores da Web, já adicionamos o recurso HDCP Policy Check API no Chrome 69 para computador (ChromeOS, Linux, Mac e Windows).
O teste terminou em novembro de 2018.
Intenção de fazer um experimento | Chromestatus Tracker | Bug do Chromium
Compliance com MSE PTS/DTS
Os intervalos armazenados em buffer e os valores de duração agora são informados pelos intervalos do carimbo de data/hora da apresentação (PTS), em vez de intervalos de decodificação do carimbo de data/hora (DTS, na sigla em inglês) nas extensões de fonte de mídia (MSE, na sigla em inglês).
Quando o MSE era novo, a implementação do Chrome foi testada em relação a WebM e MP3, alguns formatos de stream de mídia em que não havia distinção entre PTS e DTS. E estava funcionando bem até o ISO BMFF (também conhecido como MP4) ser adicionado. Esse contêiner geralmente contém fluxos de tempo de decodificação e apresentação fora de ordem (para codecs como H.264, por exemplo), fazendo com que o DTS e o PTS sejam diferentes. Isso fez o Chrome relatar (geralmente um pouco) intervalos em buffer e valores de duração diferentes do esperado. Esse novo comportamento será lançado gradualmente no Chrome 69 e tornará a implementação do MSE compatível com a especificação do MSE (em inglês).
![PTS/DTS](https://developer.chrome.com/static/blog/media-updates-in-chrome-69/image/ptsdts-a029a068bdd9b.png?authuser=5&hl=pt)
Essa mudança afeta MediaSource.duration
e, consequentemente,
HTMLMediaElement.duration
), SourceBuffer.buffered
(e, consequentemente,
HTMLMediaElement.buffered)
e SourceBuffer.remove(start, end)
).
Se você não souber qual método é usado para informar intervalos armazenados em buffer e valores de duração, acesse a página interna do chrome://media-internals
e pesquise "ChunkDemuxer: buffering by PTS" ou "ChunkDemuxer: buffering por DTS" nos registros.
Intent de implementação | 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 smartphones básicos. Por isso, ele não é necessariamente fornecido com alguns aplicativos de visualização de mídia. Portanto, se um usuário tentar abrir um vídeo salvo, por exemplo, ele não terá nenhum aplicativo para processar essa intent.
Para corrigir isso, o Chrome 69 no Android Go agora detecta intents de visualização de mídia para que os usuários possam conferir áudios, vídeos e imagens transferidos por download. Em outras palavras, ele substitui os aplicativos de visualização que estão faltando.
![ALT_TEXT_HERE](https://developer.chrome.com/static/blog/media-updates-in-chrome-69/image/alttexthere-0d5b0859fc0e3.png?authuser=5&hl=pt)
Esse recurso do Chrome está ativado em todos os dispositivos Android com Android O e versões mais recentes com 1 GB de RAM ou menos.
Remoção de eventos "parados" para elementos de mídia usando o MSE.
Um evento "parado" será gerado em um elemento de mídia se o download de dados de mídia não
progredir por cerca de três segundos. Ao usar extensões de origem de mídia
(MSE, na sigla em inglês), o app da Web gerencia o download, e o elemento de mídia não está ciente do
progresso. Isso fazia com que o Chrome gerasse eventos "parados" em momentos
inadequados sempre que o site não adicionasse novos blocos de dados de mídia com
SourceBuffer.appendBuffer()
nos últimos três segundos.
Como os sites podem decidir anexar grandes blocos de dados em uma frequência baixa, esse não é um indicador útil sobre a integridade do armazenamento em buffer. A remoção de eventos "parados" de elementos de mídia que usam o MSE esclarece a confusão e deixa o Chrome mais alinhado com a especificação do MSE. Os elementos de mídia que não usam o MSE vão continuar gerando eventos "parados" como já ocorre atualmente.
Intent de descontinuação e remoção | Chromestatus Tracker | Bug do Chromium