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

Confira o guia de desativação dos Serviços de Mídia do Azure

Aqui está uma listagem:

• Especificação OpenAPI (Swagger)
• CLI do Azure
• .NET
• Java
• Python
• Node.js
• Go

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.

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.

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.

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.

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.

Confira Mover uma conta de uma assinatura a outra dos Serviços de Mídia do Microsoft Azure.

Confira RBAC (controle de acesso baseado em função) do Azure para contas de Serviços de Mídia.

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

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.

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.

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.

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.

Sim. Confira Codificar com uma escada de taxa de bits gerada automaticamente.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.

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.

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.

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.

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

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

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.

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.

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

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.

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.

Use a Grade de Eventos do Azure para monitorar seu evento ao vivo sem um serviço de sondagem. Consulte Criar e monitorar eventos dos Serviços de Mídia com a Grade de Eventos usando o portal do Azure.

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.

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

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.

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.

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

Confira o Guia de preços dos Serviços de Mídia do Microsoft Azure.

Confira Cotas e limites dos Serviços de Mídia do Microsoft Azure.

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