Atualizações de mídia no Chrome 69

François Beaufort

• 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.

Bug do Chromium

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