Compartilhar via


Perguntas comuns sobre os Serviços de Mídia do Azure

Este artigo apresenta as respostas das perguntas frequentes sobre os Serviços de Mídia do Microsoft Azure.

Desativação dos Serviços de Mídia do Azure

Onde posso encontrar mais informações sobre a desativação dos Serviços de Mídia do Azure?

Desenvolvendo com SDKs

Onde posso encontrar os SDKs e a API dos Serviços de Mídia?

Devo usar os SDKs de cliente ou gravar diretamente na API REST?

Não recomendamos que você tente encapsular a API REST para Serviços de Mídia do Microsoft Azure diretamente em seu próprio código de biblioteca. Fazer isso corretamente para fins de produção exigiria que você implemente a lógica de repetição completa do Azure Resource Manager e entenda como gerenciar operações de longa execução em APIs do Azure Resource Manager. Os SDKs de cliente para várias linguagens — por exemplo, .NET, Java, TypeScript, Python e Ruby – lidam com isso automaticamente, para reduzir as chances de problemas com lógica de nova tentativa ou chamadas à API com falha.

Onde posso encontrar exemplos dos Serviços de Mídia?

Consulte as páginas de exemplos. Há exemplos para Contas, Ativos, Transmissão Ao Vivo, Streaming de VOD, Proteção de Conteúdo, Codificação, Análise e uso de Players.

Como a paginação em grande conjuntos de resultados (como uma lista de ativos) funciona na API?

Ao usar a paginação, você sempre deve usar o próximo link para enumerar a coleção e não depender de um tamanho de página em particular. Para obter detalhes e exemplos, confira Filtragem, ordenação e entidades de paginação.

Contas

Como posso usar uma identidade gerenciada para criptografar dados para os Serviços de Mídia do Microsoft Azure?

Para obter informações sobre como usar a CLI do Azure para emparelhar Serviços de Mídia do Microsoft Azure com o Azure Key Vault para encriptar seus dados, confira o tutorial Usar uma chave do Azure Key Vault para criptografar dados para uma conta dos Serviços de Mídia do Microsoft Azure.

Como posso usar uma identidade gerenciada para dar aos Serviços de Mídia do Microsoft Azure acesso a uma conta de armazenamento restrita?

Se você quiser que os Serviços de Mídia do Microsoft Azure acessem uma conta de armazenamento quando ela estiver configurada para bloquear solicitações de endereços IP desconhecidos, siga as etapas em Acessar armazenamento com uma identidade gerenciada dos Serviços de Mídia do Microsoft Azure.

Como mover uma conta de uma assinatura a outra dos Serviços de Mídia do Microsoft Azure?

Segurança

Quais funções do Azure podem fazer ações nos recursos dos Serviços de Mídia do Microsoft Azure?

Os Serviços de Mídia dão suporte ao RBAC (controle de acesso baseado em função) refinado?

Os Serviços de Mídia definem as seguintes funções internas:

  • Administrador de conta dos Serviços de Mídia
  • Operador de mídia dos Serviços de Mídia
  • Administrador de política dos Serviços de Mídia
  • Administrador de ponto de extremidade de streaming dos Serviços de Mídia
  • Administrador de eventos ao vivo dos Serviços de Mídia

Essas funções são detalhadas em RBAC (controle de acesso baseado em função) do Azure para contas dos Serviços de Mídia.

Elas podem ser usadas para dar acesso refinado a uma conta dos Serviços de Mídia. Para permitir todo o acesso a uma conta dos Serviços de Mídia, a função "Proprietário" ou "Colaborador" pode ser usada. Os Serviços de Mídia têm uma API mais antiga que será preterida e que não dá suporte ao controle de acesso refinado. Clientes que precisam de controle de acesso refinado não devem selecionar "Habilitar APIs clássicas" ao criar uma conta dos Serviços de Mídia usando o portal (ou usar a versão da API 2020-05-01 se estiverem usando a API para criar contas).

O seguinte Azure Policy interno pode ser usado para bloquear a criação de contas que dão suporte à API antiga: contas dos Serviços de Mídia do Azure que permitem acesso à API v2 herdada devem ser bloqueadas – Microsoft Azure

Ativos, carregamento e armazenamento

O que é um ativo dos Serviços de Mídia do Microsoft Azure?

Um ativo dos Serviços de Mídia do Microsoft Azure é um contêiner da conta de Armazenamento do Microsoft Azure que é usado para cada arquivo de vídeo que você carrega. Ele tem um identificador exclusivo que é usado com transformações e outras operações. Confira Ativos nos Serviços de Mídia do Microsoft Azure v3.

Como criar um ativo dos Serviços de Mídia do Microsoft Azure?

Sempre que você quiser carregar um arquivo de mídia e fazer algo com ele, como codificação ou streaming, crie um ativo para armazenar o arquivo de mídia e outros arquivos associados a ele. Os ativos serão criados automaticamente se você usar o portal do Azure. Se você não estiver usando o portal para carregar arquivos, precisará criar um Ativo primeiro.

Codificação

Quais formatos de codificação estão disponíveis com os Serviços de Mídia do Microsoft Azure?

Os formatos de codificação comuns estão disponíveis com o Codificador Padrão dos Serviços de Mídia. Para ver uma lista de todos os formatos, confira Formatos e codecs do Codificador Padrão.

Como posso criar um trabalho dos Serviços de Mídia do Microsoft Azure?

Você pode criar um trabalho no portal do Microsoft Azure usando o CLI do Azure, REST ou qualquer um dos SDKs. Confira os exemplos dos Serviços de Mídia do Microsoft Azure para a linguagem de programação que você preferir.

Posso usar os Serviços de Mídia para criar uma escada de taxa de bits gerada automaticamente?

Os Serviços de Mídia do Microsoft Azure dão suporte à codificação com reconhecimento de conteúdo?

Sim. Serviços de Mídia do Microsoft Azure podem realizar uma análise de duas etapas em um vídeo. Em seguida, ele pode recomendar o melhor conjunto de taxas de bits adaptável, resoluções e configurações de codificação com base no conteúdo do vídeo.

Posso usar um arquivo MP4 codificado externamente ou existente nos Serviços de Mídia do Microsoft Azure?

Sim. Para obter detalhes e links para um aplicativo de exemplo que mostra como carregar um arquivo MP4 de taxa de bits única pré-codificado e gerar o manifesto do servidor (.ism) e o manifesto do cliente (.ismc), confira a resposta à pergunta "Posso transmitir arquivos MP4 existentes que são pré-codificados ou codificados em outra solução?" na seção sobre empacotamento e entrega. Essa resposta também descreve o impacto no desempenho na origem.

É possível usar os Serviços de Mídia do Microsoft Azure na codificação de conteúdo de arquivo de formato muito curto?

Não recomendamos isso. Um conteúdo muito curto com duração menor do que um ou dois minutos não é ideal para um streaming de taxa de bits adaptável. Se você pretende transmitir por streaming arquivos de forma muito curta, é recomendável codificar previamente o conteúdo em um formato que seja facilmente transmitido usando uma taxa de bits única.

Como a maioria dos players de taxa de bits adaptável precisa de tempo para armazenar vários segmentos de vídeo em buffer, bem como tempo para analisar a largura de banda da rede antes de aumentar ou reduzir a escada de taxa de bits adaptável, geralmente é inútil fornecer muitas taxas de bits para conteúdos com duração menor do que 30 segundos. No momento em que o player bloqueia o algoritmo heurístico na taxa de bits correta para ser reproduzido devido às condições de rede, o arquivo será feito em streaming.

Além disso, alguns players padronizam o armazenamento em buffer de até 3 segmentos de vídeo. Cada segmento pode ter de dois a seis segundos. Para vídeos de formato muito curto, o player provavelmente armazenará em buffer e começará a reprodução da primeira taxa de bits selecionada do conjunto da taxa de bits adaptável. Por esse motivo, é recomendável usar um arquivo MP4 de taxa de bits única e carregá-lo em um ativo se você precisar de uma geração de manifesto HLS ou DASH. Para obter detalhes sobre como fazer isso, confira a resposta à pergunta "Posso transmitir arquivos MP4 existentes que são pré-codificados ou codificados em outra solução?" na seção sobre empacotamento e entrega.

É necessário entregar os arquivos no formato HLS ou DASH apenas se você quiser se beneficiar dos recursos desses protocolos. Para fluxos de taxa de bits única, eles ainda podem oferecer muito, como busca mais rápida, suporte ao gerenciamento de direitos digitais (DRM), e maior dificuldade de baixar via URL (mas ainda é possível!) do que um MP4 de download progressivo no armazenamento de blobs. O suporte a legendas para VTT e IMSC1 também é outro benefício. Além disso, a capacidade de associar posteriormente renderizações de áudio adicionais ou dublagens em idiomas alternativos torna essa uma opção valiosa para algumas situações.

Como girar um vídeo, sub-recortar um vídeo, costurar vídeos, criar miniaturas e sprites etc?

Se você está procurando maneiras de usar um codificador dos Serviços de Mídia para girar um vídeo, sub-recortar um vídeo, costurar vídeos, criar miniaturas e sprites, temos inúmeros exemplos de código na página Exemplos de código. As linguagens de exemplo disponíveis incluem Node.JS, Python, .NET e Java.

Transmissão ao vivo

O que é um evento ao vivo dos Serviços de Mídia do Microsoft Azure?

Um evento ao vivo dos Serviços de Mídia é o processo de ingerir feeds de vídeo ao vivo e transmiti-los por meio de um protocolo RTMPS ou Smooth Streaming. Para mais informações, confira Eventos e saídas ao vivo nos Serviços de Mídia do Microsoft Azure.

Como posso criar um evento ao vivo dos Serviços de Mídia do Microsoft Azure?

A primeira etapa é escolher um codificador local. Fornecemos exemplos para criar um evento ao vivo com Wirecast e OBS. Se você preferir começar com uma visão geral dos eventos ao vivo dos Serviços de Mídia do Microsoft Azure, confira Tipos de evento ao vivo.

Como fazer transcrição dinâmica com um evento ao vivo dos Serviços de Mídia do Microsoft Azure?

Os Serviços de Mídia do Microsoft Azure fornecem vídeo, áudio e texto em diferentes protocolos. Quando você publica sua transmissão ao vivo usando MPEG-DASH ou HLS/CMAF, juntamente com vídeo e áudio, nosso serviço entrega o texto transcrito no IMSC1.1 compatível com TTML. Para obter mais informações, confira transcrição ao vivo.

Como posso monitorar a integridade do evento ao vivo?

Você pode assinar os eventos da Grade de Eventos do Azure para acompanhar eventos ao vivo. Para obter mais informações, confira o esquema da Grade de Eventos do Azure. Você pode:

  • Assinar os eventos de nível de streaming Microsoft.Media.LiveEventEncoderDisconnected e interromper e excluir o evento ao vivo após algum tempo sem reconexões.
  • Assinar os eventos de pulsação no nível de rastreamento. Se a taxa de bits de todas as faixas cair a 0 ou o último carimbo de data/hora parar de aumentar, você poderá desligar com segurança o evento ao vivo. Os eventos de pulsação acontecem a cada 20 segundos para cada faixa, portanto, isso pode ser detalhado demais.

Posso reutilizar a mesma URL de streaming ao reiniciar um evento ao vivo?

Não, você não poderá usar facilmente a mesma URL de streaming se parar e iniciar um evento ao vivo. Cada vez que você cria e publica uma nova saída ao vivo (e ativo), uma nova URL de streaming (GUID) será usada para o novo localizador. Dessa forma, você tem certeza de que não haverá conflito de cache no ponto de extremidade de streaming e na rede de distribuição de conteúdo (CDN). Você pode preparar (e conhecer) as URLs de streaming com antecedência, pois você pode forçar um GUID específico para o localizador de streaming e, em seguida, decidir o nome do manifesto a ser usado para a saída ao vivo.

Digamos que você decida usar o GUID 1a7ed69e-a361-433d-8A56-29c61872744f para a saída em tempo real que criará amanhã. Quando chega o dia, você inicia o evento ao vivo e cria uma saída ao vivo. Você pode optar por usar "conference1" para o manifesto e forçar o GUID para o localizador.

A URL de streaming é previsível e é http://<youraccountname>-<azureregion>.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.

Não é possível reutilizar a mesma saída ou ativo ao vivo várias vezes. Considere a combinação da saída ao vivo e do ativo como uma gravação em fita. Depois que a saída ao vivo tiver sido gravada no ativo, você não poderá reutilizá-lo para outra gravação. Haverá conflito de blob ou substituições se você fizer isso novamente. A menos que você planeje limpar completamente os blobs na conta de armazenamento e limpar o CDN completamente, haverá problemas. Provavelmente, ainda haverá problemas porque os fragmentos já estão em cache downstream no CDN ou em caches de dispositivo do cliente (por exemplo, o cache do navegador).

Empacotamento e entrega

carreguei, codifiquei e publiquei um vídeo. Por que o vídeo não é reproduzido quando faço streaming?

Um dos motivos mais comuns é que o ponto de extremidade de streaming do qual você está tentando reproduzir não está no estado de execução.

O que é um ponto de extremidade de streaming dos Serviços de Mídia do Microsoft Azure?

Nos Serviços de Mídia do Microsoft Azure, um ponto de extremidade de streaming representa um serviço de origem e empacotamento dinâmico (Just-In-Time) que pode fornecer seu conteúdo ao vivo e sob demanda diretamente para um aplicativo de reprodução de cliente, usando um dos protocolos de mídia de transmissão comuns (HLS ou DASH). Além disso, o ponto de extremidade de streaming fornece criptografia dinâmica (just-in-time) para sistemas DRMs líderes do setor. Para obter mais informações, confira Pontos de extremidade de streaming (origem) nos Serviços de Mídia do Microsoft Azure.

O que é um localizador de streaming dos Serviços de Mídia do Microsoft Azure?

Para disponibilizar vídeos para reprodução por clientes, você precisa criar um Localizador de Streaming e criar URLs de streaming. Os localizadores de streaming também são usados para aplicar políticas de streaming que contêm regras de como os arquivos de mídia são consumidos.

Como posso criar um localizador de streaming dos Serviços de Mídia do Microsoft Azure?

Para criar uma URL de streaming, primeiro crie um localizador de streaming. Depois, você precisa concatenar o nome do host do ponto de extremidade de streaming com o caminho do localizador de streaming.

O que é uma política de streaming?

As políticas de streaming permitem que você defina protocolos de streaming e opções de criptografia dos localizadores de streaming. Os Serviços de Mídia do Microsoft Azure v3 fornecem algumas políticas de streaming predefinidas. Para obter mais informações, confira Políticas de streaming.

Como posso criar uma política de streaming dos Serviços de Mídia?

Para uma lista de políticas predefinidas que você pode usar para começar, confira Políticas de streaming.

Como posso transmitir conteúdo de formato HLS para dispositivos Apple?

Certifique-se de que (format=m3u8-cmaf) está inserido no final do caminho (após a parte /manifest da URL) para informar ao servidor de origem do streaming para retornar conteúdo de HLS para consumo em dispositivos nativos iOS da Apple. Veja mais detalhes em Entregando conteúdo.

Posso transmitir por streaming arquivos MP4 existentes pré-codificados ou codificados em outra solução?

Sim, o servidor de origem dos Serviços de Mídia do Microsoft Azure (ponto de extremidade de streaming) dá suporte ao empacotamento dinâmico de arquivos MP4 para o formato de streaming HLS ou DASH. No entanto, o conteúdo deve ser codificado no formato closed-GOP, com GOPs curtos no intervalo de duração de 2-6 segundos. Recomendamos as seguintes configurações: GOPs de 2 segundos, distância máxima e mínima de quadro chave de 2 segundos, codificação de taxa de bits constante (modo CBR). Pode ter suporte para a maior parte do conteúdo nesse formato, que é codificado por meio do codec de vídeo H264 ou HEVC, juntamente com o formato de áudio AAC. Formatos de áudio adicionais que são previamente codificados também podem ter suporte, como Dolby DD+.

A chave para fazer isso funcionar é criar um ativo, carregar os ativos pré-codificados no contêiner do ativo usando SDKs de cliente de Armazenamento de Blobs do Azure e, em seguida, gerar o manifesto do servidor necessário (.ism) e os arquivos de manifesto do cliente. Para obter detalhes, confira o projeto de amostra NET: Transmitir por streaming arquivos MP4 existentes.

Tenha em mente que há implicações de desempenho ao usar essa abordagem, já que o codificador interno nos Serviços de Mídia do Microsoft Azure também gera índices binários (arquivos .mpi) que melhoram o tempo de acesso nos arquivos MP4. Sem esses arquivos, o servidor pode usar um pouco mais de CPU em alta carga. Para obter mais informações, consulte streaming de um arquivo MP4 de taxa de bits única existente com HLS ou Dash.

Quando estiver expandindo com essa abordagem, você deverá monitorar a carga de CPU do ponto de extremidade de streaming. Se você estiver planejando ir para a produção com uma grande biblioteca de arquivos MP4 que são pré-codificados fora dos Serviços de Mídia do Microsoft Azure, registre um tíquete de suporte para que sua arquitetura seja revisada e confira as maneiras de melhorar o desempenho do servidor de origem do conteúdo MP4 codificado previamente.

Os localizadores de streaming v2 continuarão funcionando após fevereiro de 2024?

Os localizadores de streaming criados com a API v2 continuarão funcionando depois que nossa API v2 for desativada. Depois que os dados do localizador de streaming são criados no banco de dado de back-end dos Serviços de Mídia, não há nenhuma dependência da API REST v2 para streaming. Não removeremos registros específicos da v2 do banco de dados quando a v2 for desativada em fevereiro de 2024.

Há algumas propriedades de ativos e localizadores criados com a v2 que não podem ser acessados nem atualizados usando a nova API v3. Por exemplo, a v2 expõe uma API de arquivos de ativo que não tem um recurso equivalente na API v3. Geralmente, isso não é um problema para a maioria de nossos clientes, pois não é um recurso amplamente usado, e você ainda poderá transmitir localizadores antigos e excluí-los quando não forem mais necessários.

Após a migração, você deve evitar fazer chamadas à API v2 para modificar os ativos ou localizadores de streaming.

Proteção de conteúdo

Como posso entregar meu conteúdo de mídia com criptografia dinâmica?

A criptografia dinâmica é a proteção de sua mídia desde o momento que ela sai do seu computador até o armazenamento, o processamento e a entrega. Os Serviços de Mídia do Microsoft Azure permitem que você entregue o conteúdo ao vivo e sob demanda criptografado de forma dinâmica com a criptografia AES (AES-128) ou qualquer um dos três principais sistemas de DRM: Microsoft PlayReady, Google Widevine e Apple FairPlay. Veja mais informações em Proteger conteúdo com a criptografia dinâmica dos Serviços de Mídia do Microsoft Azure.

Devo usar criptografia de chave não criptografada AES-128 ou um sistema de DRM (gerenciamento de direitos digitais)?

Geralmente, os clientes se perguntam se devem utilizar criptografia AES ou um sistema DRM. A principal diferença entre os dois sistemas é que, com a criptografia AES, a chave de conteúdo é transmitida ao cliente por TLS. A chave é criptografada em trânsito sem nenhuma criptografia adicional ("em claro"). Por isso, o player do cliente tem acesso à chave usada para descriptografar o conteúdo, que é exibida em rastreamentos de rede no cliente em texto sem formatação. A criptografia de chave AES-128 não criptografada é adequada para casos de uso em que o visualizador é uma parte confiável (por exemplo, criptografar vídeos corporativos distribuídos em uma empresa para serem visualizados pelos funcionários).

Os sistemas de DRM, como o PlayReady, o Widevine e o FairPlay, oferecem maior criptografia na chave usada para descriptografar o conteúdo, em comparação à chave AES-128 sem criptografia. A chave de conteúdo é criptografada com uma chave protegida pelo runtime do DRM, além da criptografia que o TLS oferece. A descriptografia é identificada em um ambiente seguro no nível do sistema operacional, o qual é mais difícil para um usuário mal-intencionado atacar. Recomendamos o DRM para casos de uso em que o espectador não é confiável e você precisa do máximo nível de segurança.

Como mostrar um vídeo apenas aos usuários que têm uma certa permissão, sem usar o Azure AD?

Você não precisa usar nenhum provedor de token, como o Azure AD (Azure Active Directory). Você pode criar o seu provedor de JWT (chamado de Serviço de Token Seguro ou STS) com a criptografia de chave assimétrica. No STS personalizado, você pode adicionar declarações com base em sua lógica de negócios.

O emissor, o público e as declarações devem ser exatamente iguais no JWT e no valor do ContentKeyPolicyRestriction usado no ContentKeyPolicy.

Veja mais informações em Proteger conteúdo usando a criptografia dinâmica dos Serviços de Mídia.

Como e onde obter o token de JWT para usá-lo para a licença de solicitação ou a chave?

Para a produção, você precisa ter um STS (ou seja, um serviço Web) que emite o token de JWT após uma solicitação HTTPS. Para teste, você pode usar o código mostrado no método GetTokenAsync definido em Program.cs.

Após a autenticação do usuário, o player solicita o token ao STS e o atribui como o valor do token. Você pode usar o API do Player de mídia do Azure.

Veja um exemplo da execução do STS com uma chave simétrica ou uma chave assimétrica em Ferramenta JWT. Veja um exemplo de player baseado no Player de Mídia do Azure que usa o token do JWT na ferramenta de teste de mídia do Azure. Expanda o link player_settings para ver a entrada do token.

Como autorizar solicitações de transmissão de vídeos com a criptografia AES?

A abordagem correta é usar o STS. No STS, dependendo do perfil do usuário, adicione declarações diferentes (como "Usuário Premium", "Usuário Básico" ou "Usuário de Avaliação Gratuita"). Com diferentes declarações JWT, o usuário pode ver é diferente do conteúdo. Para conteúdos ou ativos diferentes, ContentKeyPolicyRestriction terá o valor correspondente RequiredClaims.

Use APIs de Serviços de Mídia do Azure para configurar a entrega de licença/chave e criptografar seus ativos (como mostra este exemplo).

Por que apenas o áudio é executado, mas nenhum vídeo aparece quando o modo offline do FairPlay é usado?

Esse comportamento parece estar relacionado ao design do aplicativo de exemplo. Quando uma faixa de áudio alternativa está presente (que é o caso de HLS) durante o modo offline, o iOS 10 e o iOS 11 têm como padrão a faixa de áudio alternativa. Para compensar esse comportamento no modo offline de FPS, remova a faixa de áudio alternativa do fluxo. Para fazer isso nos Serviços de Mídia, adicione o filtro de manifesto dinâmico audio-only=false. Em outras palavras, uma URL de HLS termina com .ism/manifest(format=m3u8-aapl,audio-only=false) .

Por que o FairPlay offline executa somente áudio sem modo de vídeo após eu adicionar audio-only=false?

Dependendo do design da chave do cache da rede de distribuição de conteúdo, o conteúdo pode ser armazenado em cache. Limpe o cache.

O que é a estrutura de arquivos offline/baixados em dispositivos iOS?

A estrutura do arquivo baixado em um dispositivo iOS tem a aparência da captura de tela abaixo. A pasta _keys armazena licenças de FPS baixadas, com um arquivo de armazenamento para cada host de serviço de licença. A pasta .movpkg armazena conteúdo de áudio e vídeo.

A primeira pasta com o nome que termina com um traço seguido por um número contém o conteúdo de vídeo. O valor numérico é a largura de banda de pico das representações de vídeo. A segunda pasta com um nome que termina com um traço seguido por 0 contém o conteúdo de áudio. A terceira pasta denominada Dados contém a lista de reprodução mestre do conteúdo de FPS. Por fim, boot.xml fornece uma descrição completa do conteúdo da pasta .movpkg.

Captura de tela que mostra a estrutura de arquivo offline para o aplicativo de exemplo FairPlay iOS.

Veja um arquivo de exemplo boot.xml:

<?xml version="1.0" encoding="UTF-8"?>
<HLSMoviePackage xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://apple.com/IMG/Schemas/HLSMoviePackage" xsi:schemaLocation="http://apple.com/IMG/Schemas/HLSMoviePackage /System/Library/Schemas/HLSMoviePackage.xsd">
  <Version>1.0</Version>
  <HLSMoviePackageType>PersistedStore</HLSMoviePackageType>
  <Streams>
    <Stream ID="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" Path="1-4DTFY3A3VDRCNZ53YZ3RJ2NPG2AJHNBD-0" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(127000)/Manifest(aac_eng_2_127,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
    <Stream ID="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" Path="0-HC6H5GWC5IU62P4VHE7NWNGO2SZGPKUJ-310656" NetworkURL="https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/QualityLevels(161000)/Manifest(video,format=m3u8-aapl)">
      <Complete>YES</Complete>
    </Stream>
  </Streams>
  <MasterPlaylist>
    <NetworkURL>https://example.streaming.mediaservices.windows.net/e7c76dbb-8e38-44b3-be8c-5c78890c4bb4/MicrosoftElite01.ism/manifest(format=m3u8-aapl,audio-only=false)</NetworkURL>
  </MasterPlaylist>
  <DataItems Directory="Data">
    <DataItem>
      <ID>CB50F631-8227-477A-BCEC-365BBF12BCC0</ID>
      <Category>Playlist</Category>
      <Name>master.m3u8</Name>
      <DataPath>Playlist-master.m3u8-CB50F631-8227-477A-BCEC-365BBF12BCC0.data</DataPath>
      <Role>Master</Role>
    </DataItem>
  </DataItems>
</HLSMoviePackage>

Como fornecer licenças persistentes (habilitadas offline) para alguns clientes/usuários e licenças não persistentes (desabilitadas offline) para outros? É necessário duplicar o conteúdo e usar uma chave de conteúdo separada?

Como os Serviços de Mídia v3 permitem que um ativo tenha várias instâncias do StreamingLocator, você pode ter:

  • Uma instância ContentKeyPolicy com license_type = "persistent", ContentKeyPolicyRestriction com uma declaração sobre "persistent" e sua instância StreamingLocator.
  • Outra instância ContentKeyPolicy com license_type="nonpersistent", ContentKeyPolicyRestriction com uma declaração sobre "nonpersistent" e sua instância StreamingLocator.
  • Duas StreamingLocator instâncias que têm valores de ContentKey diferentes.

Dependendo da lógica de negócios do STS personalizado, diferentes declarações são emitidas no token JWT. Com o token, apenas a licença correspondente pode ser obtida e apenas a URL correspondente pode ser reproduzida.

Qual é o mapeamento entre os níveis de segurança do Widevine e do DRM dos Serviços de Mídia?

A Visão geral da arquitetura de DRM do Widevine", do Google, define três níveis de segurança. No entanto, a documentação dos Serviços de Mídia do Azure no modelo de licença do Widevine descreve cinco níveis de segurança (requisitos de robustez do cliente para reprodução).

O Google Widevine define os dois conjuntos de níveis de segurança. A diferença está no nível de uso: arquitetura ou API. Os cinco níveis de segurança são usados na API do Widevine. O serviço de licença do Widewine nos Serviços de Mídia do Microsoft Azure desserializa o content_key_specsobjeto, que contémsecurity_level, e passado para o serviço de entrega global do Widevine pelo serviço de licença do Widevine nos Serviços de Mídia do Azure. A tabela a seguir mostra o mapeamento entre os dois conjuntos de níveis de segurança.

Níveis de segurança definidos na arquitetura do Widevine Níveis de segurança usados na API do Widevine
Nível de Segurança 1: todo o processamento, criptografia e controle de conteúdo é realizado no TEE (Ambiente de Execução Confiável). Em alguns modelos de implementação, o processamento da segurança pode ser feito em diferentes chips. security_level=5: A criptografia, a decodificação e qualquer manipulação da mídia (compactada e descompactada) precisam ser feitas em um TEE com suporte de hardware.

security_level=4: A criptografia e a decodificação do conteúdo precisam ser feitas em um TEE com suporte de hardware.
Nível de segurança 2: a criptografia (mas não o processamento de vídeo) é executada no TEE. Os buffers descriptografados são retornados para o domínio do aplicativo e processados por meio de um hardware ou software de vídeo separado. No entanto, no nível 2, as informações de criptografia ainda são processadas somente no TEE. security_level=3: As operações de criptografia e material de chave precisam ser executadas em um TEE com suporte de hardware.
Nível de segurança 3: não há TEE no dispositivo. Podem ser tomadas medidas apropriadas para proteger as informações de criptografia e o conteúdo descriptografado no sistema operacional do host. Uma implementação de Nível 3 também pode incluir um mecanismo de criptografia de hardware, mas isso melhora apenas o desempenho, não a segurança. security_level=2: A criptografia de software e um decodificador oculto são obrigatórios.

security_level=1: A criptografia white—box baseada em software é obrigatória.

Monitoramento

Como posso monitorar meus recursos dos Serviços de Mídia?

Use o Azure Monitor para acompanhar o que está acontecendo com os recursos dos Serviços de Mídia do Microsoft Azure. Para obter mais informações, confira Monitorar os Serviços de Mídia. Os guias de procedimento estão listados no final da página.

Como posso monitorar meu evento ao vivo dos Serviços de Mídia do Microsoft Azure?

Players

Quais players de vídeo posso usar com os Serviços de Mídia?

Os Serviços de Mídia funcionam com muitos players. Confira a lista de players de mídia compatíveis ou experimente os exemplos de players de terceiros.

Alta disponibilidade

Os Serviços de Mídia dão suporte à alta disponibilidade?

Para mais informações sobre Serviços de Mídia do Microsoft Azure e alta disponibilidade, confira Alta disponibilidade com Serviços de Mídia do Microsoft Azure e Vídeo por Demanda (VoD).

Migrando da v2

Como posso migrar dos Serviços de Mídia v2 para os Serviços de Mídia v3?

Criamos um guia abrangente para a migração da v2 para a v3. Estamos muito interessados em saber sobre sua experiência e necessidades de migração, portanto, fique à vontade para fornecer comentários por meio de um tíquete de suporte ou de problema do GitHub.

Solução de problemas

Como posso descobrir o que esse código de erro significa?

Documentamos códigos de erro nas seguintes referências: códigos de erro do ponto de extremidade de streaming, códigos de erro de evento ao vivo, códigos de erro de trabalho. Se você não encontrar respostas lá, crie um tíquete de suporte.

Como posso redefinir minhas credenciais de conta?

Você pode redefinir suas credenciais de conta com a CLI do Azure.

Cobrança e estimativas de custos

Quanto custam os Serviços de Mídia?

Cotas e limites

Quais cotas e limites existem para os Serviços de Mídia?

Conformidade e dados do cliente

Os Serviços de Mídia do Microsoft Azure armazenam os dados de clientes fora da região de serviço?

Os clientes anexam as próprias contas de armazenamento à conta dos Serviços de Mídia do Microsoft Azure. Todos os dados de ativos são armazenados nessas contas de armazenamento associadas, e o cliente controla a localização e o tipo de replicação do armazenamento.

Outros dados associados à conta dos Serviços de Mídia do Microsoft Azure (incluindo chaves de criptografia de conteúdo, chaves de verificação de token, URLs de JobInputHttp e outros metadados de entidade) são guardados em armazenamento de propriedade da Microsoft na mesma região selecionada para a conta dos Serviços de Mídia do Microsoft Azure.

Devido aos requisitos de residência de dados no Sul do Brasil e no Sudeste da Ásia, os dados de conta adicionais são armazenados com redundância de zona e contidos em uma região. Para o Sudeste da Ásia, todos os dados adicionais são armazenados em Cingapura. Para o Sul do Brasil, todos os dados são armazenados no Brasil. Em outras regiões além do Sul do Brasil e do Sudeste da Ásia, pode haver armazenamento dos dados de conta adicionais no armazenamento de propriedade da Microsoft na região emparelhada.

Os Serviços de Mídia fornecem alta disponibilidade ou replicação de dados?

Os Serviços de Mídia do Azure são um serviço regional, que não oferecem alta disponibilidade nem replicação de dados. Incentivamos os clientes que precisam desses recursos para criar uma solução usando Serviços de Mídia do Microsoft Azure contas em várias regiões. Um exemplo que mostra como compilar uma solução para Alta Disponibilidade com o vídeo por demanda dos Serviços de Mídia do Microsoft Azure.