Alterações de terminologia e entidade entre os Serviços de Mídia V2 e V3
Importante
Não é mais necessário migrar do Serviço de Mídia do Azure v2 para v3, pois a substituição da API V2 se alinhará à desativação dos Serviços de Mídia do Azure. Consulte o guia de desativação dos Serviços de Mídia do Azure para obter mais informações.
Este artigo descreve as diferenças de terminologia entre os Serviços de Mídia do Azure v2 para v3.
Alterações de terminologia
- Um localizador
agora é chamado delocalizador de streaming de . - Um do Canal
agora é chamado dede eventos ao vivo . - Um programa de
agora é chamado dede saída ao vivo . - Uma de Tarefa
agora é chamada de JobOutput, que faz parte de um trabalho.
Alterações de entidade
de Entidade V2 | de Entidade V3 | de diretrizes de |
Acessível à V3 | Atualizado por V3 |
---|---|---|---|---|
AccessPolicy |
A entidade AccessPolicies não existe na V3. |
Não | Não | |
Asset |
Asset |
Sim | Sim | |
AssetDeliveryPolicy |
StreamingPolicy |
Sim | Não | |
AssetFile |
A entidade AssetFiles não existe na V3. Embora os arquivos (blobs de armazenamento) carregados ainda sejam considerados arquivos.Use as APIs de Armazenamento do Azure para enumerar os blobs em um contêiner. Há duas maneiras de aplicar uma transformação aos arquivos com um trabalho: Arquivos já carregados no armazenamento: o URI incluiria a ID do ativo para trabalhos a serem feitos em ativos em uma conta de armazenamento. Arquivos a serem carregados durante o processo de transformação e trabalho: o ativo é criado no armazenamento, uma URL SAS é retornada, os arquivos são carregados no armazenamento e, em seguida, a transformação é aplicada aos arquivos. |
Não | Não | |
Channel |
LiveEvent |
Eventos ao vivo substituem Canais da API v2. Eles carregam a maioria dos recursos e têm mais recursos novos, como transcrições ao vivo, modo de espera e suporte para ingestão de RTMPS. Consulte evento ao vivo em de transmissão ao vivo baseada em cenário |
Não | Não |
ContentKey |
ContentKeys não é mais uma entidade, agora é uma propriedade de um localizador de streaming.Na v3, os dados da chave de conteúdo são associados ao StreamingLocator (para criptografia de saída) ou ao ativo em si (para criptografia de armazenamento do lado do cliente). |
Sim | Não | |
ContentKeyAuthorizationPolicy |
ContentKeyPolicy |
Sim | Não | |
ContentKeyAuthorizationPolicyOption
|
ContentKeyPolicyOptions estão incluídos no ContentKeyPolicy . |
Sim | Não | |
IngestManifest |
A entidade IngestManifests não existe na V3. Carregar arquivos na V3 envolve a API de armazenamento do Azure. Os ativos são criados primeiro e, em seguida, os arquivos são carregados no contêiner de armazenamento associado. Há muitas maneiras de obter dados em um contêiner de Armazenamento do Azure que podem ser usados.
JobInputHttp também fornece uma maneira de baixar uma entrada de trabalho de uma determinada URL, se desejado. |
Não | Não | |
IngestManifestAsset |
Há muitas maneiras de obter dados em um contêiner de Armazenamento do Azure que podem ser usados.
JobInputHttp também fornece uma maneira de baixar uma entrada de trabalho de uma determinada URL, se desejado. |
Não | Não | |
IngestManifestFile |
Há muitas maneiras de obter dados em um contêiner de Armazenamento do Azure que podem ser usados.
JobInputHttp também fornece uma maneira de baixar uma entrada de trabalho de uma determinada URL, se desejado. |
Não | Não | |
Job |
Job |
Crie um Transform antes de criar um Job . |
Não | Não |
JobTemplate |
Transform |
Em vez disso, use um Transform . Uma transformação é uma entidade separada de um trabalho e é reutilizável. |
Não | Não |
Locator |
StreamingLocator |
Sim | Não | |
MediaProcessor |
Em vez de procurar o MediaProcessor a ser usado pelo nome, use a predefinição desejada ao definir uma transformação. A predefinição usada determinará o processador de mídia usado pelo sistema de trabalho. Consulte tópicos de codificação em de codificação baseada em cenário. |
Não | NA (readonly in V2) | |
NotificationEndPoint |
As notificações na v3 são tratadas por meio da Grade de Eventos do Azure. O NotificationEndpoint é substituído pelo registro de assinatura da Grade de Eventos, que também encapsula a configuração dos tipos de notificações a serem recebidas (que na v2 foi manipulada pelo JobNotificationSubscription do Trabalho, o TaskNotificationSubscription da Tarefa e o ComponentMonitoringSetting de Telemetria). A Telemetria v2 foi dividida entre a Grade de Eventos do Azure e o Azure Monitor para se ajustar aos aprimoramentos do ecossistema maior do Azure. |
Não | Não | |
Program |
LiveOutput |
As saídas dinâmicas agora substituem programas na API v3. | Não | Não |
StreamingEndpoint |
StreamingEndpoint |
Os pontos de extremidade de streaming permanecem principalmente os mesmos. Eles são usados para empacotamento dinâmico, criptografia e entrega de conteúdo HLS e DASH para streaming ao vivo e sob demanda direto de origem ou por meio da CDN. Os novos recursos incluem suporte para uma melhor integração e gráfico do Azure Monitor. | Sim | Sim |
Task |
JobOutput |
Substituído por JobOutput (que não é mais uma entidade separada na API). Consulte tópicos de codificação em de codificação baseada em cenário. |
Não | Não |
TaskTemplate |
TransformOutput |
Substituído por TransformOutput (que não é mais uma entidade separada na API). Consulte tópicos de codificação em de codificação baseada em cenário. |
Não | Não |
Inputs |
Inputs |
Entradas e saídas agora estão no nível do trabalho. Consulte tópicos de codificação em de codificação baseada em cenário | Não | Não |
Outputs |
Outputs |
Entradas e saídas agora estão no nível do trabalho. Na V3, o formato de metadados foi alterado de XML para JSON. As saídas ao vivo começam na criação e param quando excluídas. Consulte tópicos de codificação em de codificação baseada em cenário | Não | Não |
Outras alterações | V2 | V3 |
---|---|---|
de armazenamento | Os SDKs V3 agora são dissociados do SDK de Armazenamento, o que lhe dá mais controle sobre a versão do SDK de Armazenamento que você deseja usar e evita problemas de controle de versão. | |
de codificação | ||
Taxas de bits de codificação | taxas de bits medidas em kbps ex: 128 (kbps) | bits por segundo ex: 128000 (bits/segundo) |
Codificação de drm fairplay | Nos Serviços de Mídia V2, o vetor de inicialização (IV) pode ser especificado. | Nos Serviços de Mídia V3, o FairPlay IV não pode ser especificado. |
Codificador Premium | Codificador Premium e Indexador Herdado | O do Codificador Premium Consulte tópicos de codificação em de codificação baseada em cenário |
transformações e trabalhos | ||
Processamento baseado em trabalho https | Para processamento de trabalho baseado em arquivo, você pode usar uma URL HTTPS como entrada. Você não precisa ter conteúdo já armazenado no Azure, nem precisa criar Ativos. | |
Modelos do ARM para trabalhos | Os modelos do ARM não existiam na V2. | Uma transformação pode ser usada para criar configurações reutilizáveis, para criar modelos do Azure Resource Manager e isolar as configurações de processamento entre vários clientes ou locatários. |
eventos ao vivo | ||
de ponto de extremidade de streaming | Um ponto de extremidade de streaming representa um serviço de streaming que pode fornecer conteúdo diretamente para um aplicativo player cliente ou para uma CDN (Rede de Distribuição de Conteúdo) para distribuição adicional. | Os pontos de extremidade de streaming permanecem principalmente os mesmos. Eles são usados para empacotamento dinâmico, criptografia e entrega de conteúdo HLS e DASH para streaming ao vivo e sob demanda direto de origem ou por meio da CDN. Os novos recursos incluem suporte para uma melhor integração e gráfico do Azure Monitor. |
Canais de eventos ao vivo | Os canais são responsáveis pelo processamento de conteúdo de transmissão ao vivo. Um Canal fornece um ponto de extremidade de entrada (URL de ingestão) que você fornece a um transcodificador dinâmico. O canal recebe fluxos de entrada ao vivo do transcodificador ao vivo e o disponibiliza para transmissão por meio de um ou mais pontos de extremidade de streaming. Os canais também fornecem um ponto de extremidade de visualização (URL de visualização) que você usa para visualizar e validar seu fluxo antes de processamento e entrega adicionais. | Eventos ao vivo substituem Canais da API v2. Eles carregam a maioria dos recursos e têm mais recursos novos, como transcrições ao vivo, modo de espera e suporte para ingestão de RTMPS. |
Programas de eventos ao vivo | Um programa permite controlar a publicação e o armazenamento de segmentos em uma transmissão ao vivo. Os canais gerenciam programas. A relação canal e programa é semelhante à mídia tradicional em que um canal tem um fluxo constante de conteúdo e um programa tem escopo para algum evento cronometrado nesse canal. Você pode especificar o número de horas que deseja manter o conteúdo gravado para o programa definindo a propriedade ArchiveWindowLength . Esse valor pode ser definido de um mínimo de 5 minutos para um máximo de 25 horas. |
As saídas dinâmicas agora substituem programas na API v3. |
Comprimento do evento ao vivo | Você pode transmitir eventos ao vivo 24/7 ao usar os Serviços de Mídia para transcodificar um único feed de contribuição de taxa de bits em um fluxo de saída que tem várias taxas de bits. | |
Latência de evento ao vivo | Novo suporte de transmissão ao vivo de baixa latência em eventos ao vivo. | |
Versão prévia do evento ao vivo | O Live Event Preview dá suporte ao Empacotamento Dinâmico e à Criptografia Dinâmica. Isso permite a proteção de conteúdo na versão prévia, bem como no empacotamento DASH e HLS. | |
Evento ao vivo RTMPS | Suporte aprimorado ao RTMPS com maior estabilidade e mais suporte ao codificador de origem. | |
Ingestão segura rtmps de evento ao vivo | Ao criar um evento ao vivo, você obtém 4 URLs de ingestão. As 4 URLs de ingestão são quase idênticas, têm o mesmo token de streaming AppId , apenas a parte do número da porta é diferente. Duas das URLs são primárias e backup para RTMPS. |
|
de transcrição de evento ao vivo | O Serviço de Mídia do Azure fornece vídeo, áudio e texto em protocolos diferentes. Quando você publica sua transmissão ao vivo usando MPEG-DASH ou HLS/CMAF, juntamente com vídeo e áudio, nosso serviço fornece o texto transcrito no TTML compatível com IMSC1.1. | |
Modo de espera de evento ao vivo | Não havia modo de espera para V2. | O modo stand-by é um novo recurso v3 que ajuda a gerenciar pools de eventos dinâmicos. Os clientes agora podem iniciar um Evento Ao Vivo no modo de espera a um custo menor antes de fazer a transição para o estado em execução. Isso melhora os horários de início do canal e reduz os custos de operações de pools quentes para start-ups mais rápidas. |
Cobrança de evento ao vivo | A cobrança de eventos ao vivo é baseada em medidores do Canal Ao Vivo. | |
Saídas ao vivo | Os programas tinham que ser iniciados após a criação. | As saídas ao vivo começam na criação e param quando excluídas. |
Obter ajuda e suporte
Você pode entrar em contato com os Serviços de Mídia com perguntas ou seguir nossas atualizações por um dos seguintes métodos:
- Q & A
-
stack overflow. Marcar perguntas com
azure-media-services
. - @MSFTAzureMedia ou use @AzureSupport para solicitar suporte.
- Abra um tíquete de suporte por meio do portal do Azure.