Os desportos ao vivo são excitantes para assistir. Especialmente durante momentos cruciais, como quando um tiro sai do nada para ganhar o jogo. Estes momentos também podem ser excitantes para a equipa técnica responsável por fornecer uma ação fluida em tempo real. Os fluxos de desporto ao vivo têm de equilibrar várias considerações técnicas e compensações, com uma média de cerca de 30 segundos atrás do jogo em tempo real em campo. Porquê o atraso?
Embora as redes de distribuição de conteúdo sejam essenciais, elas não podem reduzir a latência causada por outras partes do fluxo de trabalho de vídeo. Por exemplo, a latência é adicionada a partir do momento da ingestão quando uma imagem é convertida num sinal. O sinal bruto deve então ser convertido num formato comprimido e transmitido para o centro de processamento de vídeo, geralmente fora do local e muitas vezes na nuvem, o que pode ser afetado pela largura de banda e infraestrutura disponíveis. Em seguida, vem transcodificar e empacotar o conteúdo para vários dispositivos e largura de banda. Finalmente, à medida que o fluxo está a ser reproduzido, a publicidade pode ser inserida dinamicamente no fluxo pouco antes de passar pela última milha da Internet para o dispositivo do espetador. Aqui, os buffers do leitor decodificam, descompacta e renderiza o segmento final do vídeo. Isso é um monte de passos entre o objetivo vencedor do jogo da equipa e a rede de entrega de conteúdo. E eles podem somar, especialmente quando tem que acontecer para milhões de espetadores de uma só vez. A latência em transmissões ao vivo do Super Bowl, por exemplo, média de 28 a 47 segundos .
Reduzir a latência tornou-se um foco para os provedores de serviços de streaming. Para os desportos ligados a apostas de jogos de dois segundos, como corridas de cavalos, os fluxos atrasados colocam os participantes remotos em desvantagem para os que estão no local. Tweets ao vivo de telespetadores e jornalistas no local podem estragar momentos emocionantes para os fãs que o assistem na TV e em streaming ao vivo. E com cada vez mais espetadores a usar um segundo ecrã enquanto assistem a desportos ao vivo, não admira que reduzir o tempo atrás do tempo ao vivo esteja a tornar-se um requisito importante para se manter competitivo e proporcionar uma excelente experiência de visualização.
Reduzir a latência é uma área de foco para nós na Edgecast, agora Edgio. Esse esforço envolve pesquisar e implementar melhorias incrementais em cada etapa de processamento e os outros fatores envolvidos na entrega de fluxos ao vivo. Neste post, nós olhamos para o que está envolvido com um aspeto específico da redução de latência – como a nossa rede de entrega de conteúdo lida com o aumento do volume de pedidos que resulta de uma estratégia cada vez mais popular de baixa latência – a de reduzir o tamanho do segmento.
Na busca por reduzir o tempo atrás do tempo ao vivo, os provedores de serviços de streaming estão começando a adotar o uso de menores durações de segmentos HLS ou DASH. Isso pode reduzir significativamente a latência, mas tem compensações como despesas gerais adicionais e maior risco de rebuffering. Se essas compensações valem a pena depende inteiramente da prioridade colocada na latência em comparação com outras considerações de QV. Em algumas situações, como observado acima, a baixa latência é uma prioridade, enquanto em outras, os níveis de latência atuais podem ser aceitáveis para fornecer publicidade personalizada, programação em 4K ou para permitir a edição de conteúdo ao vivo.
O papel do tamanho do segmento na latência
A indústria de streaming de vídeo tem usado há muito tempo tecnologias de taxa de bits adaptativa (ABR) que quebram um fluxo em muitos segmentos ou pedaços de vídeo individuais. Cada segmento tem a mesma duração ou tamanho, mas é codificado em diferentes níveis de qualidade de vídeo ou taxas de bits, para que o fluxo possa se adaptar à largura de banda disponível do espetador à medida que novos segmentos são solicitados. Ambos os principais protocolos ABR, o HLS da Apple e o MPEG-DASH, fornecem controles para ajustar o tamanho do segmento.
O tamanho do segmento desempenha um papel importante na latência porque o jogador tem que baixar um número pré-definido de segmentos antes que ele possa começar a reproduzir a transmissão ao vivo. Isto é feito para que o leitor de vídeo cliente possa armazenar em buffer vídeo suficiente para garantir uma reprodução suave de vídeo sem rebuffering quando há congestionamento na rede. No entanto, isso também coloca o fluxo para trás ao vivo desde o início. Geralmente, os reprodutores de vídeo incorporados em dispositivos iOS e navegadores da web bufam três segmentos de vídeo antes de iniciar a reprodução. Se um segmento tem quatro segundos de duração e o jogador tem que armazenar três segmentos antes que ele possa começar a jogar, então o cliente já está 12 segundos atrás ao vivo. O protocolo DASH fornece alguma flexibilidade permitindo que os arquivos de manifesto especifiquem quanto de um arquivo precisa ser armazenado em buffer. Ainda assim, muitos jogadores e dispositivos DASH ainda não implementaram esta funcionalidade.
Reduzindo o tempo de vida
Como o buffer de três segmentos é o padrão de facto, a técnica mais popular para reduzir o tempo atrás da vida é diminuir o tamanho ou a duração de cada segmento. No exemplo abaixo, ao reduzir o tamanho do segmento de quatro segundos para dois segundos, o tempo atrás do tempo real diminui para apenas seis segundos – metade do que seria com segmentos de quatro segundos.
Segmentos mais pequenos podem causar rebuffers
Ao usar tamanhos de segmentos menores, o fluxo de trabalho de vídeo tem que ser mais ágil para oferecer uma experiência de streaming de vídeo ao vivo sem buffer. Isto deve-se a dois fatores:
Primeiro, ao reduzir o tamanho do segmento, o jogador, que armazena um número fixo de segmentos, agora armazena menos vídeo. E como tamanhos de segmentos mais curtos significam mais arquivos, o fluxo de trabalho de vídeo e, mais importante, a rede de entrega de conteúdo deve processar e entregar o dobro de pedidos de arquivos dos jogadores ao longo de uma determinada duração do fluxo. Como há menos buffer de vídeo no jogador durante o congestionamento da rede, é mais provável que o congestionamento possa causar um buffer. O jogador é agora mais sensível ao congestionamento, mesmo durante eventos de congestionamento mais pequenos.
Em segundo lugar, como explicámos num recente artigo técnico, Otimizando a CDN para Live Streaming, é comum nos desportos ao vivo ver surtos nos espetadores quando os eventos populares começam ou quando um jogo próximo se aproxima dos minutos finais. À medida que o número de solicitações de arquivos aumenta, a CDN precisa acomodar mais solicitações de arquivos no mesmo período de tempo. Esta tarefa é composta por vários tipos de dispositivos e velocidades de ligação especificados por parâmetros de taxa de bits adaptativa.
Para ilustrar o aumento do volume de arquivos, a Figura 2 mostra um segmento de vídeo de 16 segundos entregue em segmentos de comprimento diferentes. Com segmentos de quatro segundos, apenas quatro arquivos são necessários para entregar o segmento de 16 segundos. Mas quando movemos para segmentos de dois segundos, precisamos de oito arquivos separados – o dobro dos arquivos que precisam ser processados através da CDN.
Melhore o desempenho da entrega do segmento com o Hot Filing
Criámos uma funcionalidade chamada Hot Filing para lidar com o chamado fenómeno “flash crowd” quando muitos espetadores ao vivo juntam-se a uma transmissão ao mesmo tempo. Esta funcionalidade refere-se a replicar rapidamente um segmento popular ou “hot-file” para servidores adicionais dentro de um pop (ponto de presença), para que possa ser entregue aos visualizadores tão rapidamente quanto a demanda aumenta rapidamente.
Ao espalhar a carga para muitos servidores, o Hot Filing impede que qualquer servidor fique sobrecarregado à medida que as solicitações de arquivos aumentam de repente. Quando um servidor é sobrecarregado, semelhante a um ataque de negação de serviço, o servidor será lento para responder a pedidos de arquivos, levando potencialmente a buffer no jogador cliente. Ao identificar e replicar rapidamente arquivos quentes, o risco de sobrecarregar um único servidor é muito menor. Mudanças repentinas na demanda podem agora ser atendidas sem adicionar latência.
A figura 3 mostra como o Hot Filing (Fig. 3.b) melhora o desempenho evitando a sobrecarga do servidor. Sem o Hot Filing (Fig. 3.a), todo o tráfego de um segmento vai para o Server 1 (S1). À medida que a procura do público aumenta, o tráfego adicional flui para o S1, empurrando-o acima da sua capacidade de 100 utilizadores. A situação continua a piorar à medida que o S1 atende 200 espetadores no pico. Em contraste, o Hot Filing (Fig. 3.b) manipula esta carga adicional replicando ficheiros para dois servidores (s1 mais s2) e reencaminhando pedidos de ficheiros para o servidor recém-disponível.
Identificação rápida de ficheiros quentes
Recentemente, aumentámos o Hot Filing diminuindo o tempo para mover ficheiros hot para vários servidores em um segundo. Melhoramos o tempo de reação ao alterar a forma como os ficheiros quentes são identificados num pop. Usamos um processo central para agregar pedidos de arquivos e contagem de bytes para análise. Anteriormente, os dados eram retirados do processo do servidor web em cada servidor. Embora isso funcionasse bem, descobrimos que um servidor web lento poderia abrandar a agregação de dados de arquivos quentes. Para resolver este problema, os servidores agora gravam a sua solicitação e o byte conta para o disco a cada segundo. Como resultado, quando o processo central puxa dados, ele não precisa esperar nos processos do servidor web, uma vez que os dados já estão gravados em um disco de estado sólido. Esta mudança por si só é suficiente para acomodar a carga para a maioria dos eventos ao vivo.
A importância crítica de um tempo de reação rápido para eventos ao vivo é mostrada na Figura 3.c, que oferece uma visão de como o processo de Hot Filing funciona para recrutar recursos adicionais. No exemplo mostrado na Figura 3.c, à medida que o servidor S1 excede a sua capacidade de 100 utilizadores, os ficheiros são rapidamente transferidos para o S2 à medida que atinge a capacidade. Isso permite que o sistema acomode todos os 200 utilizadores de forma rápida e eficiente e use toda a capacidade dos servidores disponíveis.
Hot Filing em várias portas
Para eventos extremamente populares, como jogos de playoffs de futebol profissional ou grandes jogos internacionais de futebol, picos e picos de tráfego podem ser muito significativos. Atender a esse nível de demanda também requer alterar a forma como os segmentos de arquivos são replicados para aumentar a capacidade do servidor. Anteriormente, a rede de distribuição de conteúdo estava limitada a replicar segmentos para uma porta por servidor. Mas agora, podemos replicar arquivos para várias portas em cada servidor. Isso aumenta a taxa de transferência de cada servidor substancialmente para que cada pop possa lidar com mais solicitações e, portanto, eventos ao vivo muito maiores do que antes.
No nosso sistema, o equilíbrio de carga é controlado pelo hash do protocolo de roteamento de matriz de cache (CARP). Para conteúdos regulares, a nossa abordagem tem sido replicar os ficheiros em vários servidores, e usamos o hash CARP para selecionar uma única porta de cada servidor. Fazemos isso para impedir que pedidos duplicados sejam enviados para o servidor de origem e para limitar a comunicação entre processos.
Quando um arquivo fica quente o suficiente, o CARP começa a selecionar várias portas por servidor para suportar ainda mais solicitações. Esta abordagem funciona bem para ficheiros quentes, uma vez que são uma pequena fração dos ficheiros únicos servidos por um servidor. O número de portas abertas depende da procura de um ficheiro de acesso. Esta abordagem aumenta o volume de dados servido por servidor e a quantidade de energia da CPU disponível para processar essas solicitações.
Conclusão
À medida que os provedores de serviços de streaming reduzem o tamanho dos segmentos de vídeo para oferecer um fluxo ao vivo de baixa latência, os recursos de Filamento a quente da plataforma Edgio ajudam a rede de entrega de conteúdo a gerenciar as solicitações aumentadas de arquivos de vídeo, especialmente à medida que o tamanho do público cresce para eventos esportivos populares.
