EME? Cdm? DRM? CENC? IDK! O que você precisa para criar seu próprio player de vídeo em um navegador

O que significam todas essas abreviações? O que é necessário para desenvolver um player de código aberto para assistir a vídeos da Amazon, Sky e outras plataformas e assistir a vídeos de qualquer provedor? Sebastian Golasch falou sobre como o processo de streaming de vídeo ocorre na conferência HolyJS 2018 Piter. Sob o corte - vídeo e tradução de seu relatório.



Sebastian Golasch é atualmente desenvolvedor da Deutsche Telekom. Ele trabalhou com Java e PHP por um longo tempo e depois mudou para JS, Python e Rust. Nos últimos sete anos, ele trabalha na plataforma doméstica inteligente Qivicon.

Um pouco sobre a história do streaming de vídeo

Primeiro, vamos olhar para a história da web, já que passamos do QuickTime para a Netflix em 25 anos. Tudo começou nos anos 90, quando a Apple inventou o QuickTime. Seu uso na Internet começou em 1993-1994. Naquele momento, o player podia reproduzir vídeo com uma resolução de 156 × 116 pixels e uma frequência de 10 FPS, sem aceleração de hardware (usando apenas recursos do processador). Esse formato foi focado em uma conexão dial-up de 9600 baud - 9600 bps, incluindo informações gerais.

Era a hora do navegador Netscape. O vídeo no navegador não parecia muito bom, porque não era nativo da Web. Para jogar, usamos um software externo (o mesmo QuickTime) com sua própria interface, que foi visualizada no navegador usando a tag embed.



A situação ficou um pouco melhor quando a Macromedia lançou o Shockwave Player (após a aquisição da Macromedia pela Adobe, ficou conhecida como Adobe Flash Player). A primeira versão do Shockwave Player foi lançada em 1997, mas a reprodução de vídeo apareceu apenas em 2002.

Eles usaram o codec Sorenson Spark aka H.263. Foi otimizado para pequenas resoluções e arquivos pequenos. O que isso significa? Por exemplo, um vídeo de 43 segundos usado para testar o Shockwave Player pesava apenas 560 KB. Obviamente, não seria muito agradável assistir a um filme dessa qualidade, mas a tecnologia em si era interessante para a época. No entanto, como no caso do QuickTime, para o Shockwave Player funcionar no navegador, era necessário um software adicional. Esse player teve muitos problemas de segurança, mas o mais importante é que o vídeo ainda era um complemento do navegador.

Em 2007, a Microsoft lançou o Silverlight, que lembra o Flash. Não vamos nos aprofundar, mas todas essas soluções tinham algo em comum - uma caixa preta. Todos os jogadores trabalharam como um complemento do navegador, e você não tinha ideia do que estava acontecendo lá dentro.

Elemento < Video/ >

Em 2007, o Opera propôs o uso da tag < Video/ >, ou seja, a criação de vídeo nativo em um navegador. Nós o usamos hoje. É fácil e conveniente, e qualquer vídeo pode não apenas ser visualizado, mas também baixado. E mesmo que não desejemos permitir o download de vídeos, não podemos proibir o download para o navegador. O máximo é dificultar o download do vídeo.



A <Video/> é exatamente o oposto da caixa preta, e visualizar o código fonte é muito simples.

DRM

No entanto, você não pode simplesmente clicar com o botão direito do mouse em um vídeo no Netflix e selecionar "Salvar como". A razão para isso é DRM (Gerenciamento de restrições digitais). Esta não é uma única tecnologia ou um único aplicativo que executa qualquer tarefa. Este é um termo geral para conceitos como:

• Autenticação e criptografia de usuário
• Criptografia baseada em conteúdo
• Definição de direitos e aplicação de restrições
• Feedback e atualização
• Controle de saída e proteção de link
• Exame e rastreamento de intrusos
• Gerenciamento de chaves e licenças

Para entender o que é DRM, precisamos estudar seu ecossistema, ou seja, para descobrir quais empresas estão envolvidas. Isto é:

• Os proprietários de conteúdo estão no topo do ecossistema. Por exemplo, Disney, MGM ou FIFA. Essas empresas produzem conteúdo e têm direitos sobre ele.
• Os núcleos DRM são empresas que fornecem tecnologia DRM (por exemplo, Google, Apple, Microsoft etc.) Atualmente, existem entre 7 e 8 tecnologias DRM de diferentes empresas.
• Provedores de serviços - Desenvolva um software de servidor que criptografa o vídeo.
• Navegadores que são realmente jogadores.
• Os provedores de conteúdo são empresas como Netflix, Amazon, Sky etc. Como regra geral, eles não possuem os direitos do conteúdo, licenciam e distribuem o conteúdo.
• Os fornecedores de chips / dispositivos também estão envolvidos no ecossistema, porque o DRM não é apenas tecnologia de software. Algumas empresas (principalmente chinesas) estão desenvolvendo chips que codificam e decodificam vídeos.

Você já se perguntou por que, ao assistir um vídeo no Netflix em um navegador, ele não possui uma resolução muito alta (SD), mas se você assistir o mesmo vídeo em uma Apple TV ou Android TV Box, o mesmo conteúdo será reproduzido em Full HD ou em 4K? O DRM também é responsável por isso. O fato é que os fabricantes sempre têm medo de piratas roubarem conteúdo. Portanto, quanto menos seguro o ambiente em que a decodificação de vídeo é executada, pior a qualidade é mostrada ao usuário. Por exemplo, se a decodificação for realizada de forma programática (por exemplo, no Chrome ou Firefox), o vídeo será mostrado com a pior qualidade. Em um ambiente em que os recursos de hardware para decodificação são usados ​​(por exemplo, se o Android usa uma GPU), as possibilidades de cópia ilegal de conteúdo são menores e, aqui, a qualidade da reprodução é maior. Por fim, o ambiente mais seguro é totalmente de hardware (Apple TV ou Android TV Box), onde a decodificação e a reprodução são realizadas sem envolver o software.



Mas se falamos de navegadores, a decodificação neles é quase sempre realizada por software. Navegadores diferentes usam sistemas diferentes para DRM. Chrome e Firefox usam Widevine. Essa empresa é de propriedade do Google e licencia seus aplicativos DRM. Assim, para decodificação, o Firefox baixa a biblioteca DRM do Google. No navegador, você pode ver de onde vem o download.



A Apple usa seu próprio sistema FairPlay, que foi criado quando a empresa lançou o primeiro iPhone e iPad. A Microsoft também usa seu próprio desenvolvimento chamado PlayReady, embutido no Windows. Em outros casos, o Widevine é usado com mais frequência. Esse sistema existe tanto como aplicativo quanto como solução de hardware - chips que decodificam o vídeo.

Cdm

A abreviação CDM significa Content Decryption Module. Este é um software ou hardware que pode funcionar de várias maneiras:

• Descriptografe o vídeo, após o qual é renderizado no navegador usando a tag <Video />.
• Descriptografe e decodifique o vídeo e transfira os quadros brutos do vídeo para reprodução no navegador.
• Descriptografe e decodifique o vídeo e transfira os quadros brutos do vídeo para reprodução usando a GPU.

Apesar do suporte da GPU, a segunda opção é mais usada (pelo menos no que diz respeito ao Chrome e Firefox).

Decodificando e decodificando camadas no navegador

Então, como tudo isso funciona juntos? Para entender isso, observe as camadas de decodificação e descriptografia no navegador. Eles são divididos em:

• Aplicativo JavaScript - informa ao computador qual vídeo eu vou assistir.
• Um navegador é um player que reproduz conteúdo de vídeo.
• Módulo de descriptografia de conteúdo.
• O gerenciamento de direitos digitais tem tudo a ver com decodificação de vídeo (não consegui criar uma notação melhor, então chamei assim).
• Tempo de execução confiável.
• Nesse caso, os dois primeiros componentes são um player DRM, o módulo de descriptografia de conteúdo é um cliente DRM e os dois últimos componentes são o núcleo DRM.

O que acontece quando você reproduz um vídeo em um navegador é mostrado na imagem abaixo. Ela, é claro, é um pouco confusa: há muitas setas e cores. Eu passo a passo passo a passo, usando casos reais para deixar mais claro



Usaremos o Netflix como exemplo. Eu escrevi um aplicativo de depuração.

Comecei com onde, penso, cada um de vocês começaria: observei os pedidos que a Netflix faz quando inicio um vídeo e vi um grande número de gravações.



No entanto, se você deixar apenas aqueles que realmente são necessários para reproduzir o vídeo, ocorrerá apenas três deles: manifesto, licença e o primeiro fragmento do vídeo.



O aparelho Netflix está escrito em JavaScript e contém mais de 76.000 linhas de código e, é claro, não consigo analisá-lo completamente. Mas eu gostaria de mostrar as principais partes necessárias para a reprodução de vídeo protegido.

Começaremos com o modelo:

EME

Porém, antes de nos aprofundarmos nas funções, precisamos nos familiarizar com outra tecnologia - EME (Extensões de mídia criptografada, extensões de mídia criptografada). Essa tecnologia não executa descriptografia e decodificação, é apenas uma API do navegador. O EME serve como uma interface para CDM, para KeySystem, para um servidor com uma licença e para um servidor em que o conteúdo é armazenado.

Então, vamos começar com o getKeySystemConfig.



Deve-se ter em mente que depende do provedor, portanto, a configuração que apresento aqui funciona para a Netflix, mas não funciona, por exemplo, para a Amazon.

Nesta configuração, devemos informar ao sistema de back-end qual nível de tempo de execução confiável podemos oferecer. Isso pode ser decodificação segura de hardware ou decodificação segura de software. Ou seja, estamos dizendo ao sistema que hardware e software serão usados ​​para reprodução. E isso determinará a qualidade do conteúdo.



Após a configuração, configure a criação de um MediaKeySystem inicial.



É aqui que a interação com o módulo de descriptografia de conteúdo começa. Você deve informar à API qual sistema DRM e KeySystem usamos. No nosso caso, isso é Widevine.



O próximo passo é opcional para todos os sistemas, mas necessário para o Netflix. Novamente, sua necessidade depende do provedor. Precisamos aplicar um certificado de servidor em nossas mediaKeys. Os certificados de servidor são texto sem formatação em um arquivo Netflix Cadmium.js que pode ser facilmente copiado. E quando a aplicamos ao mediaKeys, toda a comunicação entre o servidor com a licença e nosso navegador se torna segura graças ao uso deste certificado.



Quando isso for feito, devemos voltar ao elemento original do vídeo e dizer: “Ok, este é o sistema principal que queremos usar, e essa é a tag olá vídeo. Vamos unir você.



E aqui está a última função que você precisa para configurar o sistema de vídeo.



Esta é uma sessão DRM, ou MediaKeySession. Esses são apenas os dados que vão do provedor ao módulo de descriptografia que assina os pedidos com eles. Esses dados também são texto simples, oculto por trás de várias funções no arquivo do Netflix, de onde eu as copiei.



Quando chamamos create.Session no objeto mediaKeys, precisamos informar qual vídeo suportamos. Nesse caso, é mp4. Isso nos leva de volta ao contexto de mensagens com o nosso sistema CDM. Também precisamos que a Netflix aplique o certificado do servidor base64 em cada formulário, mas toda essa configuração na sessão de criação é novamente fornecida, dependendo do sistema DRM.



A última função aqui abaixo - keySession.generateRequest cria uma solicitação de licença em segundo plano. Ou o CDM está criando uma solicitação de licença em segundo plano. Em outras palavras, são dados binários brutos que devemos enviar ao servidor licenciado para obter uma licença válida em troca.



Aqui cenc é de interesse. É um padrão de criptografia ISO que define um esquema de segurança para vídeo mp4. No WebM, isso é chamado de maneira diferente, mas a função executa o mesmo.

handleMessage é a interface EventListener que configuramos. Quando esse evento é gerado pelo evento de mensagem em keySession, sabemos que estamos prontos para obter uma licença do servidor.



E nesse retorno de chamada, apenas recebemos uma solicitação para um servidor com uma licença que fornece alguns dados binários (eles também podem diferir dependendo do provedor). Usamos esses dados para atualizar a sessão atual adicionando uma licença. Ou seja, assim que recebemos uma licença válida do servidor, nosso CDM sabe que podemos decodificar e descriptografar o vídeo.



Se aplicarmos isso ao diagrama abaixo, obtemos o seguinte: queremos reproduzir o vídeo e o aplicativo JavaScript diz: “Olá, navegador! Eu quero reproduzir o vídeo! ” - usa as extensões de mídia criptografada e solicita uma licença para funções de licença no Widevine CDM. Essa solicitação é retornada ao navegador e podemos trocá-la por uma licença válida no servidor de licenças e, em seguida, precisamos transferi-la novamente para o CDM. Este processo foi mostrado no código acima.



Mas observe que ainda não perdemos um segundo do vídeo e todos precisamos fazer isso para poder reproduzir alguns vídeos no futuro.

MSE

E outra tecnologia que precisamos pesquisar é o MSE (Media Source Extensions). Ela pode ser chamada de meia-irmã do EME (Encrypted Media Extensions). Essa também é uma API do navegador e não tem nada a ver com DRM. Eu vejo isso como uma interface de programação para < Video/ > Src. Com ele, você pode criar fluxos binários em JavaScript e aplicar fragmentos de vídeo ao elemento < Video/ >. Assim, graças a isso, a fonte da tag < Video/ > se torna dinâmica.

Assim, podemos usar as extensões para fontes de multimídia, instanciar e acessar o vídeo, depois baixar os fragmentos de vídeo em partes e aplicá-los à tag < Video/ >.



O ponto é que, quando você assiste a um vídeo de duas horas, não deseja esperar até que ele esteja totalmente carregado. Em vez disso, corte-o em pedaços pequenos, com tamanho variando de 30 segundos a 2 minutos, e aplique-os ao elemento < Video/ >, um de cada vez.

Quando nosso buffer MediaSource estiver pronto e vinculado ao elemento < Video/ >, podemos adicionar um SourceBuffer. Devemos dizer novamente a ele qual formato de vídeo e quais codecs usamos e, em seguida, ele será criado.



Finalmente, agora podemos buscar fragmentos individuais e enviá-los em nosso SourceBuffer usando o método append ao elemento <Video />, recebendo um vídeo criado dinamicamente. Também pode ser usado para outros casos de uso em que as pessoas podem combinar de forma independente diferentes elementos do vídeo, criando seus próprios vídeos, mas eu não gostaria de aprofundar muito nele.



Portanto, este é quase o último passo que devemos dar. Você tem uma rede de distribuição, possui fragmentos e, em seguida, o navegador envia os fragmentos criptografados e compactados para o CDM, onde a descriptografia e, possivelmente, a decodificação são realizadas. Em seguida, os fragmentos descriptografados e descompactados são enviados de volta ao navegador, onde são visualizados e exibidos.

Manifesto

Mas há mais um ponto. Como sabemos de quais fragmentos precisamos baixar, de onde baixá-los e quando? E esta é a última parte, a solicitação ausente do manifesto. Quando consultamos um manifesto no Netflix, ele precisa de muitos dados. Se queremos apenas reproduzir um vídeo, é importante para nós qual sistema DRM usamos, qual vídeo queremos assistir (ID da Netflix, que pode ser copiado da URL) e perfis. Os perfis determinam em que resolução recebemos o vídeo e também em que idioma recebemos as faixas de áudio, em que formato (estéreo, Dolby Digital etc.), se usamos legendas etc.

MPEG-DASH

O formato de manifesto mais usado é o MPEG-DASH. É verdade que a Apple usa um formato diferente - HSL, que parece uma lista de arquivos no antigo reprodutor Winamp. Mas Widevine e Microsoft usam exatamente MPEG-DASH. Ele é baseado em XML e define tudo: duração, tamanho do buffer, tipos de conteúdo, quando os fragmentos são carregados, fragmentos para diferentes resoluções e alternância de taxa de bits adaptável. O último significa que, se um usuário, por exemplo, assiste a um vídeo e ao mesmo tempo a velocidade de download diminui, a reprodução não para, mas a qualidade do vídeo simplesmente se deteriora. Isso ocorre porque o manifesto define as mesmas partes para diferentes resoluções, elas têm a mesma duração e os mesmos índices. Portanto, se a velocidade do download diminuir, o navegador pode simplesmente mudar para um fluxo com uma resolução mais baixa sem interromper o download e sem armazenar em buffer os dados.

É assim que o manifesto de Guardiões da Galáxia se parece. Nele podemos ver que, em diferentes velocidades de download, as pessoas receberão vídeos com qualidade diferente, além do fato de haver faixas de áudio para pessoas com deficiência auditiva. Também explicita as legendas.



Temos uma duração e uma indicação do tempo a partir do qual iniciar a reprodução. Esta função é usada, por exemplo, quando você interrompe a exibição e depois retorna ao vídeo novamente, começando de onde parou.



Também há robustez novamente, que diz: esse fragmento pode ser perdido apenas se o seu sistema atender aos requisitos. Nesse caso, é a decodificação de hardware - Codecs seguros de hardware.



Para a mesma parte do vídeo, você pode determinar qualquer número de fragmentos com resoluções diferentes.



E então você obtém o URL para carregar o fragmento, e o parâmetro range mostra o intervalo de valores em milissegundos.



Esta é a última parte. Às vezes, você também recebe um manifesto da CDN. Alguns provedores têm um servidor separado para entrega de fragmentos, mas na maioria das vezes eles vêm da mesma máquina que a funcionalidade do manifesto. Quando baixamos o manifesto, sabemos quais fragmentos precisamos baixar, podemos enviar uma solicitação de fragmentos e depois descriptografar e decodificar no CDM.



Em geral, isso é tudo. Tudo o que foi dito acima é suficiente para desenvolver um player de código aberto para assistir a vídeos da Amazon, Sky e outras plataformas e assistir a praticamente qualquer provedor.

Msl

A Netflix considerou que vale a pena adicionar criptografia extra de mensagens entre o navegador e o servidor. Eles o chamavam de "Camada de segurança da mensagem", a Camada de segurança da mensagem ou MSL. Não faz nada diretamente com o vídeo, é apenas uma camada extra de criptografia. Um dos motivos para a implementação do MSL é que o HTTPS não é seguro o suficiente. O MSL , por outro lado, é de código aberto, para que você possa sempre ver como ele funciona. Aqui não vou me aprofundar neste tópico e, se você estiver interessado, sempre poderá encontrar informações sobre o motivo pelo qual a Netflix faz MSL em seu blog. O GitHub possui documentação detalhada sobre sua implementação e implementações de trabalho em Java.

Há também uma implementação Python que escrevemos com os amigos. Até onde eu sei, esse é o único cliente de código aberto que funciona na Netflix. Ele trabalha com o Kodi Media Center. Para visualização, você pode usar o VLC Player ou qualquer outro software adequado.

E novamente a "caixa preta"

Então, você viu o que é necessário para implementar tudo isso e com que frequência mencionei o CDM - a "caixa preta" que é baixada do Google. Assim, voltamos a exibir o vídeo na "caixa preta". O belo elemento <Video /> está novamente escondido de nós. Adicionamos software de terceiros que nos ajuda, mas que ao mesmo tempo é fechado e que não podemos gerenciar. Pode fazer muitas coisas discretas: rastreamento, análise, envio de dados ...



Aqui está o que Tim Berners Lee disse sobre isso: "Então, em geral, é importante manter o EME como um ambiente on-line relativamente seguro, onde você pode assistir filmes, além do mais conveniente e que o torna parte do discurso interconectado da humanidade".

Mas há outras opiniões sobre isso. Em particular, da Electronic Frontiers Foundation, que antes do advento do DRM era membro do W3C. Eis o que eles dizem: “Em 2013, a EFF ficou desapontada ao saber que o W3C assumiu o projeto de padronização de extensões de mídia criptografadas por EME. Na verdade, estamos falando de uma API cuja única função era fornecer ao DRM um papel de liderança no ecossistema do navegador. Continuaremos a lutar para garantir que a Internet seja livre e aberta. "Continuaremos processando o governo dos EUA para revogar leis que tornam o DRM tão tóxico e continuaremos a lutar no nível da lei global".

É difícil para mim dizer como me relacionar com isso. , , , . , Netflix, . , , .

, 24-25 , HolyJS 2018 Moscow , «The Universal Serial Web» : WebUSB, USB- . -, .

PS 1- . , — 50% .