Transmitir eventos ao vivo para grandes audiências

Uma equipe de broadcast, de esportes ou de eventos transmite um evento ao vivo para uma audiência que cresce de milhares para milhões de espectadores em minutos, como exemplo. A equipe tem um encoder no local do evento e nenhuma origem de streaming própria. Todo espectador busca a mesma playlist e os mesmos segmentos quase no mesmo momento, e a playlist muda a cada poucos segundos, enquanto cada segmento nunca muda. Esta página conecta o encoder ao Live Ingest, que converte a transmissão em HLS, e configura uma aplicação que serve a playlist e os segmentos do cache para todos os espectadores. O resultado é medido pelas requisições que chegam ao Live Ingest por espectador conectado durante o pico e pela parcela de requisições respondidas pelo cache.

Este caso de uso não cobre bibliotecas sob demanda, inserção de anúncios nem DRM. Para vídeo sob demanda, consulte Entregar uma biblioteca de vídeos sob demanda.

Pré-requisitos

• Uma aplicação que serve apenas a transmissão, atrás de um workload. Para criar os dois, consulte Primeiros passos com Applications.
• Um hostname para a transmissão que aponta para o workload. Para criar o registro, no Edge DNS ou no seu provedor de DNS, consulte Aponte um domínio para um workload.
• Um encoder que envia RTMP com autenticação por usuário e senha, e as URLs de ingestão e as credenciais que a Azion fornece para um endpoint primário e um de backup. Para o requisito, consulte Ingestão.
• Um personal token, para o procedimento pela API e as consultas GraphQL. Para criar um, consulte Personal tokens.
• Os valores do seu evento. Esta página usa live.example.com para o hostname da transmissão, /<stream>.m3u8 para o caminho da playlist dela e br-east-1 para a região, para um encoder em um local de evento no Brasil. Substitua cada valor pelo seu em todas as etapas.

Produtos necessários

Arquitetura de referência

Esta página monta a Transmissão ao vivo ingerida na Azion: o encoder envia a transmissão ao Live Ingest, e uma aplicação a entrega, sem nenhuma origem de streaming sua.

Leia o diagrama como dois fluxos que se encontram no connector. O fluxo de ingestão começa no encoder, não em uma origem: a ingestão e o empacotamento acontecem na Azion, então nenhum servidor da equipe fica no caminho. O fluxo de requisições começa no player do espectador e termina no Cache sempre que existe uma cópia válida. Apenas uma cópia expirada ou ausente passa pelo connector até Live Ingest.

Fluxo de dados

1. O encoder envia a transmissão por RTMP ao Live Ingest, na região do connector do tipo live_ingest, que é br-east-1 nesta página.
2. Live Ingest converte a transmissão em HLS: uma playlist, .m3u8, e os segmentos que ela lista, .ts.
3. O player de um espectador resolve live.example.com pelo Edge DNS e requisita a playlist ao workload, que entrega a requisição à aplicação.
4. A regra da aplicação nomeia o connector do Live Ingest com Set Connector, e a Azion adiciona o behavior Enforce HLS cache, que faz cache de cada playlist por 5 segundos e de cada segmento por 60 segundos.
5. Enquanto uma cópia em cache é válida, Cache responde todos os espectadores com ela, e apenas uma cópia expirada ou ausente é buscada pelo connector. O player lê a playlist de novo para encontrar os novos segmentos e busca cada um da mesma forma.
6. Real-Time Metrics conta os usuários conectados da transmissão e as requisições que a aplicação respondeu.

Componentes

• Live Ingest: o Produto que recebe a transmissão RTMP do encoder em uma região e a converte em HLS. A região é o atributo de um connector do tipo live_ingest e decide onde a transmissão entra na Azion, não onde os espectadores se conectam.
• aplicação: o Platform Resource que entrega a transmissão. A regra dela com Set Connector envia as requisições dos espectadores ao connector do Live Ingest, e ela é alcançada pelo hostname de um workload.
• Cache: mantém a playlist e os segmentos sob a política de cache ao vivo do Enforce HLS cache, que ignora as cache settings da própria aplicação. A playlist muda conforme a transmissão avança, então a cópia dela dura segundos; um segmento nunca muda, então a cópia dele dura mais.
• Edge DNS: resolve o hostname da transmissão para o workload, incluindo um domínio apex por um registro ANAME.
• Real-Time Metrics: traz a audiência no dataset connectedUsersMetrics e a parcela de requisições respondidas pelo cache no dataset httpMetrics.

Outros designs para este caso de uso

• Transmissão ao vivo a partir de uma origem de empacotamento do cliente: para equipes que já executam um servidor de mídia ou um packager. A aplicação busca os manifestos e os segmentos dessa origem por um connector e faz cache deles, com Tiered Cache, então o empacotamento fica na origem do cliente, que permanece no fluxo de requisições e no fluxo de falhas, e as regras de cache por manifesto e por segmento se tornam decisões de design.

Configure o connector do Live Ingest

O connector do Live Ingest é onde a transmissão entra na Azion. Ele carrega uma configuração, a região, e a região decide para onde o encoder envia a transmissão, não onde os espectadores se conectam. Esta página usa br-east-1 porque o encoder está em um local de evento no Brasil: a região mais próxima do encoder encurta o caminho que a transmissão percorre antes que a Azion a receba. A região aceita us-east-1, us-east-2, br-east-1, br-east-2 e br-east-3.

Crie o connector como Entregue uma transmissão ao vivo a partir do Live Ingest descreve, com estes valores:

• Name: live-ingest-br, que a regra de entrega seleciona.
• Type: Live Ingest, live_ingest na API.
• Region: br-east-1, a região mais próxima do local do evento.

Na API, o corpo de POST /v4/workspace/connectors é:

A API responde 202 com "state": "pending". O connector existe na sua conta em br-east-1, e nenhuma requisição de espectador chega a ele até que uma regra da aplicação o nomeie.

Configure a entrega a partir do Live Ingest

A regra de entrega envia as requisições dos espectadores ao connector do Live Ingest. A aplicação em live.example.com serve apenas a transmissão, então a regra corresponde a todos os caminhos. Quando a regra nomeia um connector do Live Ingest, a Azion adiciona a ela o behavior Enforce HLS cache. Esse behavior ignora as cache settings da aplicação e aplica a política de cache que a Azion define para HLS ao vivo: a playlist e os segmentos recebem tempos de cache diferentes, porque um muda e o outro não.

1. Toda requisição em live.example.com corresponde à regra live - send to Live Ingest.
2. Uma playlist fica em cache por 5 segundos, então todo espectador fica a segundos do que o encoder escreveu.
3. Um segmento fica em cache por 60 segundos, porque é escrito uma vez e nunca muda.
4. Quando uma cópia expira, a próxima requisição busca o arquivo pelo connector, e uma cópia volta a responder todos os espectadores.

Crie a regra como Entregue uma transmissão ao vivo a partir do Live Ingest descreve, com estes valores:

• Name: live - send to Live Ingest, na Request Phase.
• Criterion: ${uri} starts with /, porque a aplicação em live.example.com serve apenas a transmissão.
• Behavior: Set Connector, nomeando live-ingest-br.

A regra carrega Set Connector e Enforce HLS cache. Não adicione Set Cache Policy a ela: Enforce HLS cache ignora as cache settings da aplicação, então uma cache setting nessas requisições não tem efeito. Uma regra nova leva alguns minutos para se propagar.

Configure o encoder

As configurações do encoder decidem quais players podem reproduzir a transmissão e como a saída HLS é cortada em segmentos. Live Ingest recebe a transmissão por RTMP com autenticação por usuário e senha, então apenas um encoder que tem as credenciais publica no endpoint. A transmissão que o encoder envia é a fonte de todo arquivo que os espectadores buscam.

Configure o encoder com estes valores:

A Azion pode exigir um encoder, uma configuração e um endpoint suportados ou aprovados. Confirme com o suporte da Azion que o seu encoder se qualifica antes do evento.

Inicie o encoder. A transmissão entra no Live Ingest em br-east-1, e a aplicação em live.example.com serve a playlist e os segmentos dela aos espectadores.

Verifique a configuração

Cada verificação de cache envia uma requisição com o header Pragma: azion-debug-cache, que faz a resposta trazer o header x-cache. Para saber como lê-lo, consulte Verifique o status de cache de uma resposta. Execute as verificações enquanto o encoder estiver transmitindo.

• O hostname resolve para o workload. Consulte o hostname da transmissão:

  dig +short live.example.com

  Quando os resolvers obtêm um registro CNAME, a resposta lista o domínio do workload que você inseriu como valor dele.

• A regra de entrega carrega a política de cache ao vivo. Abra a regra live - send to Live Ingest na aba Rules Engine. Os behaviors dela são Set Connector, nomeando live-ingest-br, e Enforce HLS cache.

• A playlist responde pelo cache. Requisite a playlist duas vezes em até 5 segundos:

  curl -sI -H "Pragma: azion-debug-cache" https://live.example.com/<stream>.m3u8

  A segunda resposta traz x-cache: HIT. A primeira pode trazer MISS, enquanto a aplicação busca a playlist pelo connector.

• Um segmento responde pelo cache. Pegue o nome de um segmento no corpo da playlist e requisite-o duas vezes em até 60 segundos:

  curl -sI -H "Pragma: azion-debug-cache" https://live.example.com/<segment>.ts

  A segunda resposta traz x-cache: HIT.

• Os espectadores conseguem reproduzir a transmissão. Carregue https://live.example.com/<stream>.m3u8 em um player HLS, como a configuração do hls.js em Boas práticas de Connectors. O player inicia a transmissão e continua avançando conforme o encoder a envia.

• A audiência é contada. Consulte o dataset connectedUsersMetrics para live.example.com, como Consulte os usuários conectados do Live Ingest mostra. A API responde 200, e data.connectedUsersMetrics traz linhas para o tempo em que o player esteve conectado.

Uma regra que parece não ter efeito ainda pode estar se propagando. Quando isso persistir depois de alguns minutos, ative Debug Rules para ver quais regras foram executadas na requisição.

Medindo resultados

Boas práticas

• Envie a transmissão para um endpoint primário e um de backup em regiões diferentes. Uma transmissão com um endpoint para quando esse endpoint falha, e dois endpoints em uma região compartilham uma falha localizada. Coloque o primário na região mais próxima do local do evento e o backup em outra região com conectividade equivalente. Antes do evento, envie uma transmissão de teste para cada endpoint e confirme que cada um a aceita. Para o raciocínio, consulte Boas práticas de Connectors.
• Deixe o cache da transmissão para o Enforce HLS cache. O behavior ignora as cache settings da aplicação, então uma cache setting com um TTL diferente nos caminhos da transmissão não muda nada e confunde a próxima pessoa que ler as regras.
• Dê ao player um fallback para erros de carregamento. O player é o último elo da cadeia de entrega, e um espectador vê toda falha que ele não trata. Configure-o para tentar de novo um carregamento de playlist ou de segmento com falha, com backoff exponencial, como o exemplo de hls.js em Boas práticas de Connectors faz.
• Crie um alerta para uma queda de usuários conectados. Uma queda repentina em connectedUsersMetrics pode significar que a transmissão falhou, e um alerta costuma ser o primeiro sinal disso. Ajuste o limite à sua audiência, para que o alerta dispare em uma falha e não na variação normal.
• Faça um teste de carga da configuração antes de um evento de alta demanda. A audiência chega ao pico de uma vez, sem tempo para corrigir uma configuração. Inicie uma transmissão de teste e simule o número esperado de espectadores com uma ferramenta de teste de carga. Uma transmissão de teste é ingerida como uma real, e Live Ingest é cobrado por Data Ingestion, como Limites de Connectors indica.

Guias deste caso de uso