Pré-requisitos
Antes de implementar o DRM offline para FairPlay em um dispositivo iOS 10 +:
- Ler os requisitos de licença e a configuração do Apple FairPlay
- Obter o SDK de FPS da Rede de Desenvolvedor da Apple. O SDK de FPS contém dois componentes:
- O SDK de servidor de FPS, que contém o Módulo de Segurança de Chave (KSM), exemplos de cliente, uma especificação e um conjunto de vetores de teste.
- O Pacote de Implantação de FPS, que contém a especificação da função D, juntamente com instruções sobre como gerar a chave privada específica do cliente do Certificado FPS e a Chave Secreta do Aplicativo. A Apple emite o Pacote de Implantação de FPS apenas para provedores de conteúdo licenciados.
- Os arquivos de certificado .der/.cer que você recebe como parte da geração do certificado FPS contêm uma chave pública e podem ser disponibilizados para o cliente. A chave privada (.pfx) deve ser protegida no Azure Key Vault ou em outro local seguro.
Armazenar uma chave privada fairplay (.pfx) no Azure Key Vault
A chave privada (.pfx) que você recebe da Apple deve ser tratada como um certificado seguro e pode ser armazenada no Azure Key Vault.
- Primeiro, o arquivo de certificado .pfx deve ser convertido em um arquivo de texto base 64 pelo administrador
- Após convertido, esse arquivo pode ser armazenado no Azure DevOps Services como um arquivo de texto seguro.
- Em seguida, a cadeia de caracteres pode ser armazenada no Azure KeyVault manualmente como um "objeto secreto" ou como parte de um script de implantação/build para a solução. Um exemplo de armazenamento do certificado privado do FairPlay no Azure KeyVault pode ser visto no código de exemplo do projeto Gridwich
- Opcionalmente, armazene a senha do arquivo .pfx como um segredo no cofre de chaves.
Exemplo de script da CLI
Para copiar o arquivo de chave privada codificado em base64 para o Azure KeyVault:
set -eu
echo key vault : $SHARED_KV_NAME
echo "Copying FairPlay certificate to key vault as secret"
az keyvault secret set --vault-name $SHARED_KV_NAME -n ams-fairPlay-certificate-b64 -f $(FairPlayCertificate.secureFilePath) --output none
Clonar o exemplo
Clone os exemplos do .Net dos Serviços de Mídia.
git clone https://github.com/Azure-Samples/media-services-v3-dotnet-tutorials.git
Modificar o código
Modifique o código em Criptografar com DRM usando o .NET para adicionar configurações do FairPlay.
Observação
O Widevine não está disponível na região GovCloud.
Pré-requisitos
Antes de implementar o DRM offline para Widevine em dispositivos Android, primeiro você deverá:
Habilitar modo offline
Para habilitar o modo offline para licenças widevine, configure o modelo de licença do Widevine. No objeto policy_overrides , defina a propriedade can_persist como true, conforme mostrado em ConfigureWidevineLicenseTemplate.
A maneira mais fácil de desenvolver um aplicativo de player nativo para dispositivos Android é usar o SDK do Google ExoPlayer, um SDK de player de vídeo de software livre. O ExoPlayer é compatível com recursos que atualmente não são compatíveis com a API do MediaPlayer nativo do Android, incluindo os protocolos de entrega MPEG-DASH e Microsoft Smooth Streaming.
O ExoPlayer versão 2.6 e posterior inclui muitas classes que dão suporte à reprodução DRM offline do Widevine. Em particular, a OfflineLicenseHelper classe fornece funções de utilitário para facilitar o uso do DefaultDrmSessionManager para baixar, renovar e liberar licenças offline. As classes fornecidas na pasta library/core/src/main/java/com/google/android/exoplayer2/offline/ SDK dão suporte ao download de conteúdo de vídeo offline.
A seguinte lista de classes facilita o modo offline no SDK do ExoPlayer para Android:
library/core/src/main/java/com/google/android/exoplayer2/drm/OfflineLicenseHelper.javalibrary/core/src/main/java/com/google/android/exoplayer2/drm/DefaultDrmSession.javalibrary/core/src/main/java/com/google/android/exoplayer2/drm/DefaultDrmSessionManager.javalibrary/core/src/main/java/com/google/android/exoplayer2/drm/DrmSession.javalibrary/core/src/main/java/com/google/android/exoplayer2/drm/ErrorStateDrmSession.javalibrary/core/src/main/java/com/google/android/exoplayer2/drm/ExoMediaDrm.javalibrary/core/src/main/java/com/google/android/exoplayer2/offline/SegmentDownloader.javalibrary/core/src/main/java/com/google/android/exoplayer2/offline/DownloaderConstructorHelper.javalibrary/core/src/main/java/com/google/android/exoplayer2/offline/Downloader.javalibrary/dash/src/main/java/com/google/android/exoplayer2/source/dash/offline/DashDownloader.java
Os desenvolvedores devem referenciar o Guia do Desenvolvedor do ExoPlayer e o Blog do Desenvolvedor correspondente durante o desenvolvimento de um aplicativo.
Trabalhando com dispositivos Android mais antigos
Para alguns dispositivos Android mais antigos, é necessário definir valores para as seguintes propriedades policy_overrides (definidas no modelo de licença do Widevine: rental_duration_seconds, playback_duration_seconds e license_duration_seconds). Como alternativa, você pode defini-los como 0, o que significa que não há restrição de tempo.
Aviso
Os valores precisam ser definidos para evitar um bug de estouro de inteiro. Para obter mais explicações sobre o problema, consulte https://github.com/google/ExoPlayer/issues/3150 e https://github.com/google/ExoPlayer/issues/3112.
Se você não definir os valores explicitamente, serão atribuídos valores muito grandes para PlaybackDurationRemaining e LicenseDurationRemaining (por exemplo, 9223372036854775807, que é o valor positivo máximo para um inteiro de 64 bits). Como resultado, a licença do Widevine aparece expirada e, portanto, a descriptografia não ocorrerá.
Esse problema não ocorre no Android 5.0 Lollipop ou posterior, pois o Android 5.0 é a primeira versão do Android, que foi projetada para dar suporte total ao ARMv8 (Advanced RISC Machine) e a plataformas de 64 bits, enquanto o Android 4.4 KitKat foi originalmente projetado para dar suporte ao ARMv7 a plataformas de 32 bits como ocorre com outras versões mais antigas do Android.
Usar o Xamarin para criar um aplicativo de reprodução do Android
Encontre associações do Xamarin para o ExoPlayer usando os seguintes links:
Além disso, consulte o seguinte thread: associação do Xamarin.
Aplicativos de player do Chrome para Android
A partir do lançamento do Chrome para Android v. 62 há suporte para a licença persistente em EME. Agora, o Widevine L1 também é compatível com o Chrome para Android. Isso permite que você crie aplicativos de reprodução offline no Chrome caso os usuários finais tiverem essa versão (ou superior) do Chrome.
Além disso, o Google produziu um exemplo de PWA (Aplicativo Web Progressivo):
Se você fizer upgrade do navegador móvel Chrome para a v62 (ou superior) em um telefone Android e testar o aplicativo de exemplo hospedado acima, verá que o streaming online e a reprodução offline funcionam.
O aplicativo PWA de software livre acima foi criado no Node.js. Se deseja hospedar sua própria versão em um servidor Ubuntu, os seguintes problemas comuns encontrados que podem impedir a reprodução:
- Problema de CORS: o exemplo de vídeo no aplicativo de exemplo hospedado em https://storage.googleapis.com/biograf-video-files/videos/. A Google configurou o CORS para todas as suas amostras de teste hospedadas no bucket do Google Cloud Storage. Elas trazem cabeçalhos do CORS, especificando explicitamente a entrada do CORS
https://biograf-155113.appspot.com (domínio no qual a Google hospeda sua amostra), impedindo o acesso por outros sites. Se você tentar, verá o seguinte erro HTTP: Failed to load https://storage.googleapis.com/biograf-video-files/videos/poly-sizzle-2015/mp4/dash.mpd: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https:\//13.85.80.81:8080' is therefore not allowed access. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
- Problema de certificado: a partir do Chrome v 58, o EME para Widevine exige HTTPS. Portanto, é necessário hospedar o aplicativo de exemplo em HTTPS com um certificado X509. Um certificado de teste normal não funciona devido aos requisitos a seguir. É necessário obter um certificado que atenda aos seguintes requisitos mínimos:
- O Chrome e Firefox exigem a presença da configuração de SAN (Nome Alternativo da Entidade) no certificado
- O certificado precisa ter uma AC confiável e um certificado autoassinado de desenvolvimento não funciona
- O certificado precisa ter uma correspondência entre o CN e o nome DNS do servidor Web ou do gateway
O formato de arquivo de streaming suave (PIFF) com H264/AAC tem uma associação com o PlayReady (AES-128 CTR). O arquivo .ismv de streaming suave, supondo que o áudio seja muxed em vídeo, é um fMP4 e pode ser usado para reprodução. Se o conteúdo de streaming suave passar pela criptografia PlayReady, cada arquivo .ismv se tornará um fragmento MP4 protegido pelo PlayReady. Você pode escolher um arquivo .ismv com a taxa de bits preferencial e renomeá-lo como .mp4 para download.
Há duas opções para hospedar o MP4 protegido por PlayReady para fazer o download progressivo:
- Você pode colocar o MP4 no mesmo ativo de serviço de contêiner/mídia e usar o ponto de extremidade de streaming dos Serviços de Mídia do Azure para download progressivo.
- Você pode usar a URL sas para download progressivo diretamente do Armazenamento do Azure.
É possível usar dois tipos de entrega de licença do PlayReady:
- Serviço de entrega de licença do PlayReady nos Serviços de Mídia do Azure
- Servidores de licença do PlayReady hospedados em qualquer lugar.
Para obter uma licença do PlayReady com o serviço de entrega ams, consulte o modelo de licença Serviços de Mídia v3 com PlayReady.
Para reprodução de teste, você pode usar um Aplicativo Universal do Windows no Windows 10. Nas amostras do Windows 10 Universal, há um exemplo de player básico chamado exemplo de Streaming adaptável. Adicione o código para escolher o vídeo baixado e use-o como a origem, em vez da fonte de streaming adaptável.
