Atualizações de mídia no Chrome 69

François Beaufort
François Beaufort

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
PTS/DTS

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
Gerenciador de intent de mídia

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.

Bug do Chromium

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