Perguntas comuns sobre os Serviços de Multimédia do Azure

Veja o guia de descontinuação dos Serviços de Multimédia do Azure

Eis uma listagem:

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

Não recomendamos que tente moldar a API REST dos Serviços de Multimédia diretamente no seu próprio código de biblioteca. Fazê-lo corretamente para fins de produção exigiria que implementasse toda a lógica de repetição do Azure Resource Manager e compreendesse como gerir operações de execução prolongada em APIs Resource Manager. Os SDKs de cliente para vários idiomas - por exemplo, .NET, Java, TypeScript, Python e Ruby - processam-no automaticamente para reduzir as hipóteses de problemas com a lógica de repetição ou chamadas à API falhadas.

Veja as páginas de exemplos. Existem exemplos para Contas, Recursos, Transmissão em Fluxo em Direto, Transmissão em Fluxo VOD, Proteção de Conteúdos, Codificação, Análise e utilização de Jogadores.

Quando estiver a utilizar a paginação, deve utilizar sempre a ligação seguinte para enumerar a coleção e não depender de um tamanho de página específico. Para obter detalhes e exemplos, veja Entidades de filtragem, ordenação e paginação.

Para obter informações sobre como utilizar a CLI do Azure para emparelhar os Serviços de Multimédia com o Azure Key Vault para encriptar os seus dados, veja o tutorial Utilizar uma chave de Key Vault para encriptar dados numa conta dos Serviços de Multimédia.

Se quiser que os Serviços de Multimédia acedam a uma conta de armazenamento quando a conta de armazenamento estiver configurada para bloquear pedidos de endereços IP desconhecidos, siga os passos no Armazenamento do Access com uma identidade gerida dos Serviços de Multimédia.

Veja Mover uma conta dos Serviços de Multimédia entre subscrições.

Veja Controlo de acesso baseado em funções do Azure (RBAC do Azure) para contas de Serviços de Multimédia.

Os Serviços de Multimédia definem as seguintes funções incorporadas:

• Administrador de Conta dos Serviços de Multimédia
• Operador de Multimédia dos Serviços de Multimédia
• Administrador de Políticas de Serviços de Multimédia
• Administrador de Pontos Finais de Transmissão em Fluxo dos Serviços de Multimédia
• Administrador de Eventos em Direto dos Serviços de Multimédia

Estas funções são detalhadas no controlo de acesso baseado em funções do Azure (RBAC do Azure) para contas de Serviços de Multimédia.

Estas funções podem ser utilizadas para conceder acesso detalhado a uma conta dos Serviços de Multimédia. Para permitir todo o acesso a uma conta dos Serviços de Multimédia, pode utilizar a função "Proprietário" ou "Contribuidor". Os Serviços de Multimédia têm uma API mais antiga no caminho de preterição que não suporta um controlo de acesso detalhado. Os clientes que necessitam de um controlo de acesso detalhado não devem selecionar "Ativar APIs clássicas" ao criar uma conta dos Serviços de Multimédia com o portal (ou utilizar a versão da API 2020-05-01 se estiverem a utilizar a API para criar contas).

Os seguintes Azure Policy incorporados podem ser utilizados para bloquear a criação de contas que suportam a API antiga: as contas dos Serviços de Multimédia do Azure que permitem o acesso à API v2 legada devem ser bloqueadas – Microsoft Azure

Um recurso dos Serviços de Multimédia é um contentor de conta de Armazenamento do Azure que é utilizado para cada ficheiro de vídeo que carrega. Tem um identificador exclusivo que é utilizado com transformações e outras operações. Veja Recursos nos Serviços de Multimédia do Azure v3.

Sempre que quiser carregar um ficheiro de multimédia e fazer algo com o mesmo, como codificar ou transmitir em fluxo, cria um recurso para armazenar o ficheiro de multimédia e os ficheiros associados. Os recursos são criados automaticamente se utilizar o portal do Azure. Se não estiver a utilizar o portal para carregar ficheiros, primeiro tem de criar um recurso.

Os formatos de codificação comuns estão disponíveis com o Codificador Standard dos Serviços de Multimédia. Para obter uma lista de todos os formatos, veja Formatos e codecs do Codificador Standard.

Pode criar uma tarefa no portal do Azure com a CLI do Azure, REST ou qualquer um dos SDKs. Veja os exemplos dos Serviços de Multimédia para obter o idioma que preferir.

Sim. Veja Codificar com uma escada de velocidade de transmissão gerada automaticamente.

Sim. Os Serviços de Multimédia podem efetuar uma análise de dois passes num vídeo. Em seguida, pode recomendar o melhor conjunto de velocidades de transmissão adaptável, resoluções e definições de codificação com base no conteúdo do vídeo.

Sim. Para obter detalhes e ligações para uma aplicação de exemplo que mostra como carregar um ficheiro MP4 de velocidade de transmissão única pré-codificado e gerar o manifesto do servidor (.ism) e o manifesto de cliente (.ismc), consulte a resposta à pergunta "Posso transmitir em fluxo ficheiros MP4 existentes pré-codificados ou codificados noutra solução?" na secção sobre empacotamento e entrega. Essa resposta também descreve o impacto no desempenho na origem.

Não o recomendamos. Os conteúdos muito curtos com menos de um minuto ou dois de duração não são ideais para transmissão em fluxo de velocidade de transmissão adaptável. Se pretender transmitir ficheiros de formato muito curto, recomendamos que codifija previamente o conteúdo para um formato que seja facilmente transmitido em fluxo com uma única velocidade de transmissão.

Uma vez que a maioria dos leitores de velocidade de transmissão adaptável precisa de tempo para colocar em memória intermédia vários segmentos de vídeo, bem como tempo para analisar a largura de banda de rede antes de "deslocar" para cima ou para baixo na escada de velocidade de transmissão adaptável, muitas vezes é inútil fornecer muitas velocidades de transmissão para conteúdos com menos de 30 segundos de duração. Quando o jogador bloquear o algoritmo heurístico na velocidade de transmissão certa para ser reproduzido com base nas condições de rede, o ficheiro será feito em fluxo.

Além disso, alguns jogadores têm a predefinição de colocar em memória intermédia até três segmentos de vídeo. Cada segmento pode ter entre dois a seis segundos de duração. Para vídeos de formato muito curto, é provável que o leitor intermédia e inicie a reprodução da primeira velocidade de transmissão selecionada do conjunto de velocidade de transmissão adaptável. Por este motivo, recomendamos a utilização de um ficheiro MP4 de velocidade de transmissão única e o carregamento para um recurso se precisar da geração de manifestos HLS ou DASH. Para obter detalhes sobre como fazê-lo, consulte a resposta à pergunta "Posso transmitir em fluxo ficheiros MP4 existentes que estão pré-codificados ou codificados noutra solução?" na secção sobre empacotamento e entrega.

É necessário entregar os ficheiros no formato HLS ou DASH apenas se quiser beneficiar das capacidades desses protocolos. Para fluxos de velocidade de transmissão única, ainda podem oferecer muito - como uma procura mais rápida, suporte de gestão de direitos digitais (DRM) e maior dificuldade em transferir através de URL (mas ainda possível!) do que um MP4 de transferência progressiva no armazenamento de blobs. O suporte de legendas para VTT e IMSC1 é outro benefício. Além disso, a capacidade de vincular representações de áudio adicionais ou dobragem em idiomas alternativos faz com que esta seja uma escolha valiosa para algumas situações.

Se estiver à procura de formas de utilizar um codificador dos Serviços de Multimédia para fazer coisas como rodar um vídeo, subclipar um vídeo, coser vídeos, criar miniaturas e sprites, temos uma tonelada de amostras de código na página Exemplos de Código . Os idiomas de exemplo disponíveis incluem Node.JS, Python, .NET e Java.

Um evento em direto dos Serviços de Multimédia é o processo de ingerir feeds de vídeo em direto e difundi-los através de um protocolo RTMPS ou de Uma Transmissão em Fluxo Uniforme. Para obter mais informações, veja Eventos em direto e saídas em direto nos Serviços de Multimédia.

O primeiro passo é escolher um codificador no local. Fornecemos exemplos para criar um evento em direto com Wirecast e OBS. Se preferir começar com uma descrição geral dos eventos em direto dos Serviços de Multimédia, veja Tipos de eventos em direto.

O Serviço de Multimédia do Azure fornece vídeo, áudio e texto em vários protocolos. Quando publica a sua transmissão em direto utilizando MPEG-DASH ou HLS/CMAF, juntamente com vídeo e áudio, o serviço fornece o texto transcrito no TTML compatível com IMSC1.1. Para obter mais informações, consulte Transcrição em direto.

Pode monitorizar eventos em direto subscrevendo Azure Event Grid eventos. Para obter mais informações, veja o esquema de eventos do Event Grid. Pode:

• Subscreva os eventos Microsoft.Media.LiveEventEncoderDisconnected ao nível do stream e monitorize que não existem ligações durante algum tempo para parar e eliminar o seu evento em direto.
• Subscreva os eventos de heartbeat ao nível da pista. Se todas as faixas tiverem uma velocidade de transmissão a cair para 0 ou o último carimbo de data/hora já não estiver a aumentar, pode encerrar o evento em direto em segurança. Os eventos de heartbeat chegam a cada 20 segundos para cada pista, pelo que pode ser um pouco verboso.

Não, não pode utilizar facilmente o mesmo URL de transmissão em fluxo se parar e iniciar um evento em direto. Sempre que criar e publicar uma nova saída em direto (e um recurso), será utilizado um novo URL de transmissão em fluxo (GUID) para o novo localizador. Desta forma, tem a certeza de que não haverá nenhum conflito de cache no ponto final de transmissão em fluxo e na rede de entrega de conteúdos (CDN). Pode preparar (e saber) os URLs de transmissão em fluxo com antecedência porque pode forçar um GUID específico para o localizador de transmissão em fluxo e, em seguida, decidir o nome do manifesto a utilizar para a saída em direto.

Imaginemos que decide utilizar o GUID 1a7ed69e-a361-433d-8a56-29c61872744f para o resultado em direto que irá criar amanhã. Quando chegar o dia, inicia o evento em direto e cria uma saída em direto. Pode decidir utilizar "conference1" para o manifesto e forçar o GUID para o localizador.

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

Não pode reutilizar o mesmo recurso ou saída em direto várias vezes. Pense na combinação da saída em direto e do elemento como uma gravação em banda. Depois de a saída em direto ter sido gravada no recurso, não pode reutilizá-la para outra gravação. Se voltar a fazê-lo, haverá conflitos ou substituições de blobs. A menos que planeie remover completamente os blobs na conta de armazenamento e remover completamente a CDN, haverá problemas. É provável que ainda haja problemas porque os fragmentos já estão em cache a jusante na CDN ou em caches de dispositivos cliente (por exemplo, a cache do browser).

Uma das razões mais comuns é não ter o ponto final de transmissão em fluxo a partir do qual está a tentar reproduzir no estado em execução.

Nos Serviços de Multimédia, um ponto final de transmissão em fluxo representa um serviço de origem e empacotamento dinâmico (just-in-time) que pode fornecer o seu conteúdo em direto e a pedido diretamente a uma aplicação de leitor de cliente através de um dos protocolos comuns de transmissão em fluxo (HLS ou DASH). Além disso, o ponto final de transmissão em fluxo fornece encriptação dinâmica (just-in-time) para sistemas DRM líderes do setor. Para obter mais informações, veja Pontos finais de transmissão em fluxo (origem) nos Serviços de Multimédia do Azure.

Para disponibilizar vídeos aos clientes para reprodução, crie um localizador de transmissão em fluxo e, em seguida, crie URLs de transmissão em fluxo. Os localizadores de transmissão em fluxo também são utilizados para aplicar políticas de transmissão em fluxo que contêm regras para a forma como os ficheiros de multimédia são consumidos.

Para criar um URL de transmissão em fluxo, crie primeiro um localizador de transmissão em fluxo. Em seguida, concatena o nome do anfitrião do ponto final de transmissão em fluxo e o caminho do localizador de transmissão em fluxo.

As políticas de transmissão em fluxo permitem-lhe definir protocolos de transmissão em fluxo e opções de encriptação para os seus localizadores de transmissão em fluxo. Os Serviços de Multimédia v3 fornecem algumas políticas de transmissão em fluxo predefinidas. Para obter mais informações, veja Políticas de transmissão em fluxo.

Para obter uma lista de políticas predefinidas que pode utilizar para começar, veja Políticas de transmissão em fluxo.

Certifique-se de que tem (format=m3u8-cmaf) no final do seu caminho (após a parte /manifesto do URL) para indicar ao servidor de origem da transmissão em fluxo que devolva conteúdo HLS para consumo em dispositivos nativos de iOS da Apple. Para obter detalhes, veja Entregar conteúdo.

Sim, o servidor de origem dos Serviços de Multimédia (ponto final de transmissão em fluxo) suporta o empacotamento dinâmico de ficheiros MP4 para o formato de transmissão em fluxo HLS ou DASH. No entanto, o conteúdo tem de ser codificado em formato GOP fechado, com GOPs curtos no intervalo de duração de dois a seis segundos. Recomendamos as seguintes definições: GOPs de dois segundos, fotograma de chave máximo e distância mínima de dois segundos, codificação de velocidade de transmissão constante (modo CBR). A maioria dos conteúdos neste formato codificados através do codec de vídeo H.264 ou HEVC, juntamente com o formato de áudio AAC, podem ser suportados. Também podem ser suportados formatos de áudio adicionais pré-codificados, como Dolby DD+.

A chave para fazê-lo funcionar é criar um recurso, carregar os recursos pré-codificados para o contentor do recurso através de SDKs de cliente Armazenamento de Blobs do Azure e, em seguida, gerar o manifesto de servidor necessário (.ism) e os ficheiros de manifesto de cliente. Para obter detalhes, veja o projeto de exemplo .NET nos ficheiros MP4 existentes do Stream.

Tenha em atenção que existem implicações de desempenho ao utilizar esta abordagem, uma vez que o codificador incorporado nos Serviços de Multimédia também gera índices binários (ficheiros.mpi) que melhoram o tempo de acesso aos ficheiros MP4. Sem estes ficheiros, o servidor pode utilizar um pouco mais de CPU a uma carga elevada. Para obter mais informações, veja Transmissão em fluxo de um ficheiro MP4 de velocidade de transmissão única existente com HLS ou Dash.

Quando estiver a aumentar verticalmente com esta abordagem, deve monitorizar a carga da CPU do ponto final de transmissão em fluxo. Se estiver a planear aceder à produção com uma grande biblioteca de ficheiros MP4 pré-codificados fora dos Serviços de Multimédia, envie um pedido de suporte para que a sua arquitetura seja revista e pergunte sobre formas de melhorar o desempenho do servidor de origem de conteúdos MP4 pré-codificados.

Os localizadores de transmissão em fluxo criados com a API v2 continuarão a funcionar depois de a nossa API v2 estar desativada. Assim que os dados do Localizador de Transmissão em Fluxo forem criados na base de dados de back-end dos Serviços de Multimédia, não existe nenhuma dependência na API REST v2 para transmissão em fluxo. Não removeremos registos específicos v2 da base de dados quando a v2 estiver desativada em fevereiro de 2024.

Existem algumas propriedades de recursos e localizadores criados com v2 que não podem ser acedidos ou atualizados com a nova API v3. Por exemplo, o v2 expõe uma API de Ficheiros de Recursos que não tem uma funcionalidade equivalente na API v3. Muitas vezes, isto não é um problema para a maioria dos nossos clientes, uma vez que não é uma funcionalidade amplamente utilizada e ainda pode transmitir em fluxo localizadores antigos e eliminá-los quando já não forem necessários.

Após a migração, deve evitar efetuar chamadas à API v2 para modificar localizadores ou recursos de transmissão em fluxo.

A encriptação dinâmica está a proteger o suporte de dados a partir do momento em que sai do computador através do armazenamento, processamento e entrega. Com os Serviços de Multimédia, pode fornecer os seus conteúdos em direto e a pedido encriptados dinamicamente com o Advanced Encryption Standard (AES-128) ou qualquer um dos três principais sistemas DRM: Microsoft PlayReady, Google Widevine e Apple FairPlay. Para obter mais informações, veja Proteger os seus conteúdos com encriptação dinâmica dos Serviços de Multimédia.

Muitas vezes, os clientes questionam-se se devem utilizar a encriptação AES ou um sistema DRM. A principal diferença entre os dois sistemas é que, com a encriptação AES, a chave de conteúdo é transmitida ao cliente através de TLS. A chave é encriptada em trânsito sem qualquer encriptação adicional ("em claro"). Como resultado, a chave utilizada para desencriptar o conteúdo é acessível ao leitor de cliente e pode ser visualizada num rastreio de rede no cliente em texto simples. A encriptação de chaves claras AES-128 é adequada para casos de utilização em que o visualizador é uma parte fidedigna (por exemplo, encriptar vídeos empresariais distribuídos numa empresa para serem visualizados pelos funcionários).

Sistemas DRM como PlayReady, Widevine e FairPlay fornecem um nível adicional de encriptação na chave que é utilizada para desencriptar o conteúdo, em comparação com uma chave clara AES-128. A chave de conteúdo é encriptada para uma chave protegida pelo runtime de DRM, além de qualquer encriptação ao nível do transporte fornecida pelo TLS. A desencriptação é processada num ambiente seguro ao nível do sistema operativo, onde é mais difícil para um utilizador malicioso atacar. Recomendamos a DRM para casos de utilização em que o visualizador pode não ser uma entidade fidedigna e precisa do nível mais elevado de segurança.

Não tem de utilizar nenhum fornecedor de tokens específico, como o Azure Active Directory (Azure AD). Pode criar o seu próprio fornecedor JWT (o chamado Serviço de Token Seguro ou STS) através da encriptação de chave assimétrica. No STS personalizado, pode adicionar afirmações com base na sua lógica de negócio.

Certifique-se de que o emissor, a audiência e as afirmações correspondem exatamente entre o que está no JWT e o ContentKeyPolicyRestriction valor utilizado em ContentKeyPolicy.

Para obter mais informações, veja Proteger os seus conteúdos através da encriptação dinâmica dos Serviços de Multimédia.

Para produção, tem de ter o Serviço de Token Seguro (ou seja, um serviço Web), que emite um token JWT após um pedido HTTPS. Para testar, pode utilizar o código apresentado no GetTokenAsync método definido em Program.cs.

Depois de um utilizador ser autenticado, o leitor faz um pedido ao STS para esse token e atribui-o como o valor do token. Pode utilizar a API do Leitor de Multimédia do Azure.

Para obter um exemplo de execução de STS com uma chave simétrica ou uma chave assimétrica, veja a ferramenta JWT. Para obter um exemplo de um leitor baseado no Leitor de Multimédia do Azure que utiliza um token JWT, veja a ferramenta de teste de multimédia do Azure. (Expanda a ligação player_settings para ver a entrada do token.)

A abordagem correta é utilizar o Serviço de Tokens Seguros. No STS, dependendo do perfil de utilizador, adicione afirmações diferentes (como "Utilizador Premium", "Utilizador Básico" ou "Utilizador de Avaliação Gratuita"). Com afirmações diferentes num JWT, o utilizador pode ver conteúdos diferentes. Para diferentes conteúdos ou recursos, ContentKeyPolicyRestriction terá o valor correspondente RequiredClaims .

Utilize as APIs dos Serviços de Multimédia do Azure para configurar a entrega de licenças/chaves e encriptar os seus recursos (conforme mostrado neste exemplo).

Este comportamento parece ser por predefinição da aplicação de exemplo. Quando está presente uma faixa de áudio alternativa (que é o caso do HLS) durante o modo offline, o iOS 10 e o iOS 11 são predefinidos para a faixa de áudio alternativa. Para compensar este comportamento no modo offline do FPS, remova a faixa de áudio alternativa da transmissão em fluxo. Para o fazer nos Serviços de Multimédia, adicione o filtro de manifesto dinâmico audio-only=false. Por outras palavras, um URL HLS termina com .ism/manifest(format=m3u8-aapl,audio-only=false).

Dependendo da estrutura da chave de cache para a rede de entrega de conteúdos, o conteúdo pode ser colocado em cache. Remova a cache.

A estrutura de ficheiros transferida num dispositivo iOS é semelhante à seguinte captura de ecrã. A pasta _keys armazena licenças FPS transferidas, com um ficheiro armazenado para cada anfitrião do serviço de licenças. A pasta .movpkg armazena conteúdo de áudio e vídeo.

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

Eis um ficheiro de boot.xml de exemplo:

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

Uma vez que os Serviços de Multimédia v3 permitem que um recurso tenha várias StreamingLocator instâncias, pode ter:

• Uma ContentKeyPolicy instância com license_type = "persistent", ContentKeyPolicyRestriction com uma afirmação em "persistent"e a respetiva StreamingLocator instância.
• Outra ContentKeyPolicy instância com license_type="nonpersistent", ContentKeyPolicyRestriction com uma afirmação em "nonpersistent" e a respetiva StreamingLocator instância.
• Duas StreamingLocator instâncias com valores diferentes ContentKey .

Consoante a lógica de negócio do STS personalizado, são emitidas afirmações diferentes no token JWT. Com o token, apenas a licença correspondente pode ser obtida e apenas o URL correspondente pode ser reproduzido.

A Descrição Geral da Arquitetura DRM widevine da Google define três níveis de segurança. No entanto, a documentação dos Serviços de Multimédia do Azure sobre o modelo de licença Widevine descreve cinco níveis de segurança (requisitos de robustez do cliente para reprodução).

O Google Widevine define ambos os conjuntos de níveis de segurança. A diferença está no nível de utilização: arquitetura ou API. Os cinco níveis de segurança são utilizados na API Widevine. O serviço de licença widevine dos Serviços de Multimédia do Azure anula a serialização do content_key_specs objeto, que contém security_levele transmite-o ao serviço de entrega global Widevine. A tabela seguinte mostra o mapeamento entre os dois conjuntos de níveis de segurança.

Utilize o Azure Monitor para controlar o que está a acontecer com os seus recursos dos Serviços de Multimédia. Para obter mais informações, veja Monitorizar os Serviços de Multimédia. Os guias de procedimentos são listados no final da página.

Utilize Azure Event Grid para monitorizar o seu evento em direto sem um serviço de consulta. Veja Criar e monitorizar eventos dos Serviços de Multimédia com o Event Grid através do portal do Azure.

Os Serviços de Multimédia funcionam com muitos jogadores. Veja a lista de leitores de multimédia compatíveis ou experimente os exemplos de jogadores de terceiros.

Para obter informações sobre os Serviços de Multimédia e a elevada disponibilidade, veja Elevada disponibilidade com os Serviços de Multimédia e Vídeo a Pedido (VOD).

Criámos um guia abrangente para a migração da v2 para a v3. Estamos interessados em saber mais sobre a sua experiência e necessidades de migração, por isso não hesite em fornecer feedback através de um problema do GitHub ou pedido de suporte.

Documentámos códigos de erro nas seguintes referências: Códigos de erro de ponto final de transmissão em fluxo, códigos de erro de eventos em direto e Códigos de erro de tarefas. Se não conseguir encontrar respostas, crie um pedido de suporte.

Pode repor as credenciais da conta com a CLI do Azure.

Veja o Guia de preços dos Serviços de Multimédia.

Veja Quotas e limites dos Serviços de Multimédia.

Os clientes anexam as suas próprias contas de armazenamento às respetivas contas dos Serviços de Multimédia do Azure. Todos os dados de recursos são armazenados nestas contas de armazenamento associadas e o cliente controla a localização e o tipo de replicação deste armazenamento.

Os dados adicionais associados a uma conta dos Serviços de Multimédia (incluindo chaves de encriptação de conteúdo, chaves de verificação de tokens, URLs jobInputHttp e outros metadados de entidade) são armazenados no armazenamento pertencente à Microsoft na região selecionada para a conta dos Serviços de Multimédia.

Devido aos requisitos de residência dos dados no Sul e Sudeste Asiático do Brasil, os dados de conta adicionais são armazenados de forma com redundância entre zonas e estão contidos numa única região. Para o Sudeste Asiático, todos os dados de conta adicionais são armazenados em Singapura. Para o Sul do Brasil, os dados são armazenados no Brasil. Em regiões que não o Sul do Brasil e sudeste asiático, também podem ser armazenados dados de conta adicionais no armazenamento da Microsoft na região emparelhada.

Os Serviços de Multimédia do Azure são um serviço regional e não fornecem elevada disponibilidade ou replicação de dados. Incentivamos os clientes que precisam destas funcionalidades a criar uma solução com contas dos Serviços de Multimédia em várias regiões. Um exemplo que mostra como criar uma solução para elevada disponibilidade com vídeo dos Serviços de Multimédia a pedido está disponível como guia.