À 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 atrair 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 a uma editora transmitir e rentabilizar conteúdos licenciados que anteriormente não tinham lugar na televisã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 ligação e a disponibilidade da largura de banda entre o local e o ponto de entrada podem ser um elo fraco no fluxo de trabalho. Redundância e confiabilidade devem ser incorporadas.
- As transmissões em tempo real devem ser codificadas 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 do 4K e de 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 a melhor experiência de visualização e as estratégias de monetização mais oportunas.
Neste blog de tecnologia, vemos como construímos nossa plataforma para permitir que um editor otimizasse o primeiro passo no fluxo de trabalho de streaming de vídeo, olhasse para alguns dos desafios envolvidos e explicasse como codificamos o fluxo ao vivo para permitir o fluxo 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 a 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 emissores com extensos recursos técnicos e aqueles sem nenhum podem aproveitar a nossa plataforma para criar experiências OTT poderosamente diferenciadas.
O Slicer prepara o seu conteúdo para a codificação, calcula as definições de codificação ideais e gere 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 o seu conteúdo em pequenos pedaços e criptografa-os antes de enviá-los para a nossa pilha de codificação em nuvem com certificação ISO, dando-lhe a paz de espírito que vem com saber que o seu conteúdo é sempre seguro. 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.
O nosso “Live Slicer”, uma versão do Slicer, é otimizado para transmissão de eventos ao vivo. Os feeds HD-SDI ou baseados em IP são rapidamente ingeridos e fragmentados em segmentos encriptados de 2 ou 4 segundos com a taxa de bits mais elevada pretendida, reduzindo os requisitos de largura de banda para 3 a 5 Mbps para 1080p e cerca de 15 Mbps para 4K. O nosso processo retém automaticamente metadados e mensagens dentro e fora da banda para ativar programas e quebras de anúncios ou substituir conteúdo. A nossa arquitetura de plug-ins permite criar scripts personalizados que lidam com os seus requisitos únicos 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 blackout.
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 razão vamos desenvolver um componente de software de primeira linha para mover transmissões ao vivo de eventos para a nuvem. Por que os editores não podiam enviar por um fluxo RTMP (Real-Time Messaging Protocol), por exemplo? (Você pode fazer isso se quiser, mas a maioria dos 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 dos 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, é necessário preservar o máximo possível de alimentação original, com um olho para formatos de maior qualidade e para o 4K. Por outro lado, você precisa otimizar o fluxo para que ele possa ser entregue de forma eficiente sem ser atolado por despesas adicionais, 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, 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. Na nossa observação, baseada na transmissão de milhões de horas de imagens ao vivo para milhares de milhões de espetadores em todo o mundo, a abordagem alternativa de enviar um fluxo RTMP significativamente maior para a nuvem não resulta num 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 retorno podem aumentar rapidamente. Se as suas necessidades são tais que você precisa de um uplink de satélite, um caminhão de banda Ka, por exemplo, renda por cerca de $2 000 dólares por dia, e largura de banda custa cerca de $400 dólares 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 desportivos em todo o mundo, o resultado é que é sempre uma boa ideia reduzir os requisitos de largura de banda de carregamento 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 a diferentes taxas de bits, resoluções e níveis de qualidade. Então 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 que contém uma lista de URLs que apontam 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 grandes protocolos de transmissão de vídeo aumentam a complexidade, e outros podem precisar de ser suportados para cobrir a miríade de possíveis dispositivos de reprodução. HLS é um protocolo de comunicação de transmissão de mídia baseado em HTTP implementado pela Apple. 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. Talvez você também precise adicionar suporte para o Microsoft Smooth Streaming para consoles de jogos.
O DRM também pode complicar a codificação, exigindo o seu próprio conjunto de múltiplos formatos para suportar grandes requisitos de audiência. Por exemplo, os jogadores mais velhos que não suportam o DRM precisam de HLS e de AES-128. Dispositivos iOS mais antigos requerem HLS e FairPlay. Dispositivos iOS mais recentes suportam HLS e FairPlay e CMAF CBC. Windows e Android mais antigos só suportam CMAF CTR. O Android, o Windows e o iOS mais recentes devem suportar todos os formatos CMAF. O seu conteúdo deve ser empacotado em vários formatos para permitir a reprodução em todos os dispositivos.
Se isso soa como muito trabalho de codificação, você está certo. À medida que as resoluções aumentam e os codecs se tornam mais complexos, torna-se mais difícil codificar uma escada de codificação ABR completa numa ú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, talvez seja necessário reduzir o número de degraus 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 fluxo para codificador 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 na nuvem. O sistema de corretagem recebe os pedaços de conteúdo das instâncias Slicer e move-os 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 a mover-se através do sistema para armazenamento e para os visualizadores.
O processo de corretagem aumenta a nossa infraestrutura de encoders de nuvem de forma perfeita e, mais importante, automática.
Na nossa implementação, uma instância de corretagem atua como um gerente falando entre o Slicer e os codificadores. O corretor garante que qualquer novo Slicer recebe os seus dados encaminhados para o codificador adequado e verifica se o codificador pode lidar com a carga de trabalho. Além disso, temos uma infraestrutura de escala muito capaz. Se, de repente, formos despejados com um milhão de horas de conteúdo de VOD que precisa ser codificado, podemos aumentar rapidamente as instâncias do servidor e começar a processar o conteúdo. Também podemos reduzir a escala tão rapidamente para conservar recursos. Este processo de corretagem gere toda a nossa infraestrutura de nuvem de forma simples e, mais importante, automática.
Codificadores sem estado
Claro, o sistema de corretagem seria de valor limitado se tudo o que poderia fazer fosse apontar um Slicer para um único codificador que pode ou não ser capaz de acompanhar as exigências da transmissão ao vivo, um problema sério com o 4K. A solução que desenvolvemos envolve o uso de codificadores sem estado. 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 os primings, como informações de entrada e saída. Neste ponto, o segmento completo é completado e pronto para ir, libertando 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 trava durante o processamento de um segmento, o mesmo segmento inicia-se noutra máquina e é feito a tempo antes de quaisquer problemas serem notados no fluxo.
Esta abordagem também permite o uso de hardware mais rentável. Por exemplo, se sabemos que uma máquina mais lenta pode levar 8 segundos para processar um arquivo de 4 segundos a partir 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. Depois, os blocos foram entregues sem problemas porque todos foram completados em um tempo previsível. Como mostrado no gráfico abaixo, este 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 exigências em tempo real. Se você quisesse configurar uma infraestrutura de codificação usando um modelo tradicional, precisaria investir em máquinas caras de alto desempenho ou hardware especializado, cada uma delas capaz de processar todo o vídeo recebido sem assistência em tempo real. Aproveitando 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 ao vivo económica
Para os produtores de conteúdo ao vivo, as considerações técnicas para preparar o vídeo ao vivo para streaming na nuvem podem apresentar obstáculos formidáveis. Você enfrentará vários problemas que vão desde limitações de largura de banda do local a questões complexas envolvendo 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 os espetadores esperam.
