Home Artigos técnicos Codificação de vídeo na nuvem para transmitir eventos ao vivo de grande escala
Applications

Codificação de vídeo na nuvem para transmitir eventos ao vivo de grande escala

About The Author

Outline

À medida que os dólares de publicidade e os telespetadores continuam a afastar-se da televisão tradicional, os proprietários de conteúdos e as emissoras estão à procura de transmissões de eventos ao vivo com suporte a anúncios para envolver novos públicos e aumentar a receita através da transmissão over-the-top (OTT). A OTT oferece novas oportunidades de distribuição, que permitem que um editor transmita e monetize conteúdo licenciado que anteriormente não tinha lugar na televisão de transmissão. Mas antes que um editor possa começar a transmitir eventos ao vivo, obstáculos técnicos na primeira etapa do fluxo de trabalho de streaming de vídeo devem ser considerados:

  • A qualidade da conexão e a disponibilidade de largura de banda entre o local e o ponto de entrada podem ser um link fraco no fluxo de trabalho. Redundância e confiabilidade devem ser incorporadas.
  • Os feeds ao vivo devem ser codificados em vários formatos e protocolos de taxa de bits adaptáveis, como Apple HLS e MPEG-DASH, minimizando a latência.
  • As soluções de upload e codificação devem ser à prova de futuro, confiáveis e escaláveis para lidar com o surgimento de 4K e outros formatos de alta qualidade.
  • O fluxo de trabalho de vídeo deve ser capaz de suportar a inserção de anúncios no lado do servidor para obter a melhor experiência de visualização e as estratégias de monetização mais oportunas.

Neste blog de tecnologia, nós olhamos como construímos nossa plataforma para permitir que um editor otimize o primeiro passo no fluxo de trabalho de streaming de vídeo, veja alguns dos desafios envolvidos e explique como codificamos o fluxo ao vivo para permitir streaming ao vivo de alto desempenho, baixa latência e com suporte a anúncios.

‍Background: O Slicer

Antes de mergulharmos nas considerações técnicas da codificação, precisamos explicar nossa tecnologia chamada “Slicer”. Um poderoso cliente de software, o Slicer, aumenta a transmissão ao vivo do seu local para a nossa plataforma de vídeo em nuvem. Simplifica uma tarefa extraordinariamente complexa sem sacrificar a flexibilidade e a funcionalidade. O Slicer é uma razão fundamental pela qual os radiodifusores com recursos técnicos extensos e aqueles sem nenhum podem aproveitar nossa plataforma para criar experiências OTT poderosamente diferenciadas.

O Slicer prepara seu conteúdo para codificação, calcula as configurações de codificação ideais e gerencia marcadores de inserção de anúncios. Você pode executar o Slicer em seu hardware seguro ou escolher a economia de custos e a escalabilidade de locais agnósticos em nuvem que suportam vários formatos, incluindo SDI, vídeo IP, RTP/FEC e RTMP.

O Slicer transforma seu conteúdo em pequenos pedaços e criptografa-os antes de enviá-los para nossa pilha de codificação em nuvem certificada ISO, dando a você a paz de espírito que vem com saber que seu conteúdo é sempre seguro. Ele oferece uma gama flexível de fluxos de trabalho, desde configurações simples de um clique a scripts mais avançados na linguagem de programação escolhida até funções de nuvem de escrita que acionam fluxos de trabalho para notificações, processamento de trabalhos e integrações de aprendizado de máquina.

Nosso “Live Slicer”, uma versão do Slicer, é otimizado para streaming de eventos ao vivo. Os feeds HD-SDI ou baseados em IP são rapidamente ingeridos e fragmentados em segmentos criptografados de 2 ou 4 segundos com a taxa de bits mais alta desejada, reduzindo os requisitos de largura de banda para 3 a 5 Mbps para 1080p e cerca de 15 Mbps para 4K. Nosso processo retém automaticamente metadados e mensagens dentro e fora da banda para acionar quebras de programas e anúncios ou substituir conteúdo. Nossa arquitetura de plugins permite que você crie scripts personalizados que lidam com seus requisitos exclusivos de eventos de sinalização. O Live Slicer também pode ouvir mensagens SCTE 35 / 104 ou receber chamadas de API para inserir quebras de anúncios, início de conteúdo ou gatilhos de blecaute.

Um fluxo OTT é gerado a partir de um feed linear ao vivo com investimento inicial mínimo e requisitos de largura de banda baixa.

Minimizando a largura de banda

Agora que você entende o licer S, você pode estar se perguntando por que vamos desenvolver um componente de software front-end para mover transmissões ao vivo de eventos para a nuvem. Por que os editores não puderam enviar por um fluxo RTMP (Real-Time Messaging Protocol), por exemplo? (Você pode fazer isso se quiser, mas a maioria de nossos clientes se aproveita do Slicer.)A resposta tem tanto a ver com as expetativa dos consumidores em transmissões ao vivo de alta qualidade como com trabalhar em torno de desafios de largura de banda em locais ao vivo. É uma questão de encontrar o equilíbrio certo entre muitos fatores concorrentes. Por um lado, você precisa preservar o máximo possível do feed original, com um olho para formatos de maior qualidade e 4K. Por outro lado, você precisa otimizar o fluxo para que ele possa ser entregue de forma eficiente sem ficar atolado por sobrecarga adicional, como publicidade personalizada. Encontrar o equilíbrio certo é fundamental para esta etapa do fluxo de trabalho de vídeo.

Aqui é onde o Slicer é essencial. Como observado acima, ele reduz significativamente a largura de banda necessária para um determinado feed, criando o perfil de taxa de bits mais alta no site e enviando apenas esse perfil para a nuvem. Em nossa observação, baseada no streaming de milhões de horas de filmagens ao vivo para bilhões de espetadores em todo o mundo, a abordagem alternativa de enviar um fluxo RTMP significativamente maior para a nuvem não resulta em um aumento apreciável na qualidade da experiência de visualização. Mas aumenta significativamente a largura de banda, o que aumenta os custos.

Os custos de backhaul podem aumentar rapidamente. Se suas necessidades são tais que você precisa de um uplink satélite, um caminhão Ka-band, por exemplo, aluga por cerca de $2 000 por dia, e largura de banda custa cerca de $400 por hora. Dadas as condições inconsistentes e restritas de largura de banda em alguns locais, como hotéis ou centros de conferências, ou mesmo locais esportivos em todo o mundo, o resultado é que é sempre uma boa ideia reduzir os requisitos de largura de banda de upload ao máximo possível, garantindo que você esteja oferecendo uma experiência de transmissão aos seus espetadores.

Encoding obstáculos

Uma vez que o feed de vídeo ao vivo sai do local, o próximo passo no fluxo de trabalho é a codificação. Aqui, um codificador de vídeo cria várias versões ou variantes do áudio e vídeo em diferentes taxas de bits, resoluções e níveis de qualidade. Em seguida, segmenta as variantes em pequenos arquivos ou segmentos de mídia. Várias etapas adicionais devem ser executadas, como criar uma lista de reprodução de mídia para cada variante contendo uma lista de URLs apontando para os segmentos de mídia da variante. A lista de reprodução principal resultante é a escolha do leitor da variante mais adequada para o dispositivo e a largura de banda atualmente medida ou disponível.

Dois protocolos principais de streaming de vídeo aumentam a complexidade, e outros podem precisar ser suportados para cobrir a miríade de dispositivos de reprodução em potencial. HLS é um protocolo de comunicação de streaming de mídia baseado em HTTP implementado pela Apple. Ele oferece suporte para todos os dispositivos Apple e a maioria dos navegadores e dispositivos Google, Android, Linux e Microsoft. A maioria, mas não todos. Você também precisa de MPEG-DASH, um protocolo de streaming de mídia baseado em HTTP concorrente. Você também pode precisar adicionar suporte para o Microsoft Smooth Streaming para consoles de jogos.

O DRM também pode complicar a codificação, exigindo seu próprio conjunto de vários formatos para suportar requisitos de grande público. Por exemplo, jogadores mais antigos que não suportam DRM precisam de HLS e AES-128. Dispositivos iOS mais antigos requerem HLS e FairPlay. Os dispositivos iOS mais recentes suportam HLS e FairPlay e CMAF CBC. Windows e Android mais antigos só suportam CMAF CTR. Android, Windows e iOS mais recentes devem suportar todos os formatos CMAF. Seu conteúdo deve ser empacotado em vários formatos para permitir a reprodução em todos os dispositivos.

Se isso soa como um monte de trabalho de codificação, você está certo. À medida que as resoluções aumentam e os codecs ficam mais complexos, torna-se mais difícil codificar uma escada de codificação ABR completa em uma única máquina, seja na nuvem ou no local. Se o seu hardware de codificação não está à altura da tarefa de acompanhar o feed ao vivo, pode ser necessário reduzir o número de rungs na escada de codificação, o que pode afetar a experiência do seu público.

Para acompanhar os requisitos de codificação mais complexos, o modelo tradicional significa que os produtores devem investir continuamente em novos hardwares para manter a velocidade e a qualidade. Em última análise, para um serviço de streaming como o Edgio, antigo Verizon Digital Media Services, o modelo de stream-to-encoder 1:1 não consegue fornecer a confiabilidade, a flexibilidade e a escalabilidade de que precisamos para atender às expetativa dos nossos clientes.

Em vez disso, desenvolvemos um sofisticado sistema de corretagem que permite o uso de quantos codificadores precisamos, todos rodando em uma infraestrutura baseada em nuvem. O sistema de corretagem recebe os pedaços de conteúdo das instâncias Slicer e os move para o codificador mais ideal. Esta ação impede que os processos de codificação sobrecarregem uma máquina específica e mantém os blocos se movendo através do sistema para armazenamento e para os espetadores.

O processo de corretagem amplia nossa infraestrutura de encoders de nuvem de forma perfeita e, mais importante, automática.

Em nossa implementação, uma instância de corretor atua como um gerente falando entre o Slicer e os codificadores. O corretor garante que qualquer novo Slicer obtenha seus dados roteados para o codificador adequado e verifica se o codificador pode lidar com a carga de trabalho. Além disso, temos uma infraestrutura de dimensionamento muito capaz. Se de repente formos despejados com um milhão de horas de conteúdo VOD que precisa ser codificado, podemos aumentar as instâncias do servidor rapidamente e começar a processar o conteúdo. Também podemos reduzir a escala tão rapidamente para conservar recursos. Esse processo de broker gerencia toda a nossa infraestrutura de nuvem de forma transparente e, mais importante, automática.

Codificadores sem estado

Claro, o sistema de corretagem seria de valor limitado se tudo o que poderia fazer é apontar um Slicer para um único codificador que pode ou não ser capaz de acompanhar as demandas da transmissão ao vivo, um problema sério com 4K. A solução que desenvolvemos envolve o uso de codificadores stateless. Em vez de dedicar uma única máquina a todo o fluxo, cada codificador recebe apenas um único segmento de vídeo de 2 ou 4 segundos de cada vez. Cada segmento inclui informações suficientes para preparar o codificador para que ele possa codificar esse segmento e descartar qualquer coisa desnecessária para primings, como informações de entrada e saída. Neste ponto, o segmento completo é concluído e pronto para ir, liberando o codificador para que ele possa começar a codificar outro pedaço de conteúdo de outro canal ou qualquer outra coisa.

Este modelo também tem uma quantidade considerável de redundância incorporada no sistema. Por exemplo, se um codificador falhar durante o processamento de um segmento, o mesmo segmento será iniciado em outra máquina e será feito a tempo antes que quaisquer problemas sejam notados no fluxo.

Essa abordagem também permite o uso de hardware mais econômico. Por exemplo, se sabemos que uma máquina mais lenta pode levar 8 segundos para processar um arquivo de 4 segundos de um Slicer, podemos espalhar a carga de trabalho por vários codificadores, como mostrado abaixo: O servidor A recebe a fatia 1, o servidor B recebe a fatia 2 e assim por diante. Em seguida, os blocos foram entregues sem problemas porque todos eles foram concluídos em um momento previsível. Como mostrado no gráfico abaixo, esse exemplo resultaria em latência atrás do tempo real de 16 a 20 segundos.

O uso de vários codificadores na nuvem minimiza a latência e permite o uso de servidores que, de outra forma, não seriam capazes de acompanhar um feed em tempo real.

Em última análise, o volume de servidores na nuvem, mesmo que os servidores individuais sejam mais lentos, significa que os processos de codificação podem sempre acompanhar as demandas em tempo real. Se você quisesse configurar uma infraestrutura de codificação usando um modelo tradicional, você precisaria investir em máquinas caras de alto desempenho ou hardware especializado, cada um capaz de processar todo o vídeo recebido sem assistência em tempo real. Ao aproveitar a escalabilidade da nuvem, reduzimos significativamente os custos de codificação.

Outra vantagem da codificação de nuvem sem estado é que podemos mover facilmente cargas de trabalho para provedores de nuvem alternativos, uma vez que não temos requisitos de servidor especializados. Com uma rede de mais de 250 Tbps de capacidade, uma abordagem multi-nuvem oferece vantagens inerentes.

Transmissão em direto económica

Para os produtores de conteúdo ao vivo, as considerações técnicas para preparar o vídeo ao vivo para streaming em nuvem podem apresentar obstáculos formidáveis. Você enfrentará vários problemas que vão desde limitações de largura de banda do local até perguntas complexas em torno de codificadores e protocolos de streaming. Embora não elimine a necessidade de alguma conetividade no local, um fluxo de trabalho simplificado com requisitos de largura de banda reduzidos no front-end pode reduzir drasticamente os gastos iniciais e contínuos, enquanto fornece os fluxos de alta qualidade e baixa latência que seus espetadores esperam.