Na primeira parte, implantamos uma CDN dinâmica simples para a transmissão de fluxos WebRTC para dois continentes e garantimos que os atrasos nessa CDN sejam realmente baixos, usando o temporizador de contagem regressiva como exemplo.
No entanto, além da baixa latência, é importante oferecer aos espectadores uma boa qualidade de transmissão, porque eles pagam por isso. Na vida real, os canais entre servidores e assinantes do Edge podem ser diferentes em largura de banda e qualidade. Por exemplo, publicamos um fluxo com uma resolução de 720p com uma taxa de bits de 2 Mbps, e o usuário o reproduz em um smartphone Android usando uma conexão 3G na área de recepção insegura do sinal, e a resolução máxima na qual a imagem será suave, apenas 360p com uma taxa de bits de 400 Mbps .
Os dispositivos e navegadores usados pelos espectadores são muito diferentes. Por exemplo, publicamos um fluxo WebRTC usando o codec VP8 do navegador Chrome em um PC, e o visualizador reproduz o fluxo no Safari no iPhone, que suporta apenas o codec H264. Ou vice-versa, publicamos o fluxo RTMP do OBS Studio, codificando vídeo em H264 e áudio em AAC, e o cliente usa um navegador baseado em Chromium, que suporta apenas VP8 ou VP9 para vídeo e opus para som.
Você também pode precisar melhorar a qualidade da publicação original. Por exemplo, distribuímos o fluxo da câmera IP em alguma reserva, na maioria das vezes a imagem é estática, a câmera fornece uma frequência de 1 quadro por segundo. Ao mesmo tempo, queremos que o visualizador reproduza 24 quadros por segundo. E se for impossível substituir a câmera ou alterar suas configurações?
Em todos esses casos, será necessária a transcodificação do fluxo no servidor, isto é, a decodificação de cada quadro recebido e a codificação subsequente com novos parâmetros. Além disso, os parâmetros que devem ser alterados geralmente são conhecidos apenas no lado do cliente. Vamos ver como é possível fornecer transcodificação na CDN, equilibrando a qualidade da transmissão e as cargas do servidor.
Transcodificação: como, onde e por quê?
Suponha que conheçamos os parâmetros de fluxo que o cliente deseja receber. Por exemplo, o visualizador começou a reproduzir um fluxo e o número de perdas de quadros nas estatísticas do WebRTC nos informa que a resolução e a taxa de bits devem ser reduzidas até que o cliente tenha trocado de canal . Nesse caso, por padrão, o fluxo será transcodificado no servidor de Borda ao qual o visualizador está conectado.
Se o cliente não suportar o codec usado ao publicar o fluxo, você poderá atribuir a transcodificação aos servidores Edge e Origin.
Tanto isso como outro podem ser apenas uma solução temporária, desde que a configuração dos servidores Origin e / ou Edge tenha sido escolhida com uma margem. A transcodificação é sempre realizada quadro a quadro, por isso é muito exigente em recursos do processador. Portanto, um núcleo de processador é capaz de transcodificar um número muito pequeno de threads:
Mesmo se iniciarmos um processo de transcodificação para todos os assinantes que exigem os mesmos parâmetros de fluxo de mídia, é provável que vários visualizadores com parâmetros diferentes selecionem todos os recursos do servidor.
Portanto, a solução correta seria selecionar servidores especiais na CDN para tarefas de transcodificação e escolher a configuração do servidor com base nessas tarefas.
Adicionar nós do transcodificador à CDN
Portanto, implantaremos um servidor em nossa CDN com a função Transcoder nos data centers europeus e americanos
Configurando Servidores Transcodificadores:
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder
Os parâmetros de transcodificação de fluxo devem ser descritos nos servidores de Borda como perfis especiais no arquivo cdn_profiles.yml . Como exemplo, considere três perfis padrão:
- transcodificação para resolução de 640x360, 30 quadros por segundo, um quadro-chave é transmitido para cada 90 quadros, codec de vídeo H264 usando o codificador OpenH264, codec de áudio Opus 48 kHz
-640x360: audio: codec : opus rate : 48000 video: width : 640 height : 360 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
- transcodificação para resolução 1280x720, codec de vídeo H264 usando o codificador OpenH264, sem transcodificação de áudio
-720p: video: height : 720 codec : h264 codecImpl : OPENH264
- transcodificando para uma resolução de 1280x720, 30 quadros por segundo, um quadro-chave é transmitido para cada 90 quadros, taxa de bits de 2 Mbit / s, codec de vídeo H264 usando o codificador OpenH264, sem transcodificação de áudio
-720p-2Mbps: video: height : 720 bitrate : 2000 gop : 90 fps : 30 codec : h264 codecImpl : OPENH264
Publicamos o fluxo de test com uma resolução de 720p no o-eu1 e o reproduzimos no e-eu1 , especificando o perfil no nome do fluxo, por exemplo, test-640x360
O fluxo é transcodificado!
Agora podemos descrever vários perfis nos servidores de Borda, por exemplo, -240p, -360p, -480p e, no lado do cliente, de acordo com as estatísticas do WebRTC, um grande número de quadros perdidos é diagnosticado, solicitando automaticamente o fluxo novamente com uma resolução mais baixa.
Agrupar nós CDN por continente
Agora, nossos servidores Transcoder são iguais. Mas e se quisermos transcodificar os fluxos por geografia: para espectadores americanos na América, para espectadores europeus na Europa? A propósito, isso reduzirá a carga nos canais transatlânticos, pois neste caso apenas os fluxos originais irão dos servidores Origin EU para os Estados Unidos e vice-versa, e nem todas as versões transcodificadas.
Nesse caso, nas configurações dos nós do transcodificador, você deve especificar o grupo
cdn_enabled=true cdn_ip=t-eu1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
cdn_enabled=true cdn_ip=t-us1.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
Além disso, o grupo deve ser adicionado às configurações dos servidores de Borda.
cdn_groups=EU
cdn_groups=US
Reinicie os nós com as novas configurações. Publicamos o fluxo de test com uma resolução de 720p no o-eu1 , reproduzimos esse fluxo no e-eu1 com transcodificação
Certifique-se de que o fluxo seja transcodificado para t-eu , para isso, abrimos a página de estatísticas http://t-eu1.flashphoner.com:8081/?action=stat e vemos o codificador e decodificador de vídeo na seção Native resources
Ao mesmo tempo, não há codificadores de vídeo no t-us1 nas estatísticas
Mais transcodificadores: balanceamento de carga
Digamos que o número de espectadores continue a crescer e as capacidades de um servidor Transcoder no continente já não são suficientes. Ok, adicione mais um servidor
cdn_enabled=true cdn_ip=t-eu2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=EU
cdn_enabled=true cdn_ip=t-us2.flashphoner.com cdn_point_of_entry=o-eu1.flashponer.com cdn_nodes_resolve_ip=false cdn_role=transcoder cdn_groups=US
No entanto, agora estamos diante do problema do balanceamento de carga entre dois transcodificadores. Para não permitir todos os threads através de um servidor, limitaremos a carga média máxima permitida do processador nos nós do Transcoder
cdn_node_load_average_threshold=0.95
Quando a carga média do processador, dividida pelo número de núcleos disponíveis, atingir esse valor, o servidor deixará de aceitar solicitações para transcodificar novos encadeamentos.
Você também pode limitar o número máximo de codificadores de vídeo em execução simultânea
cdn_transcoder_video_encoders_threshold=10000
Quando esse valor é atingido, o servidor também deixará de aceitar solicitações de fluxos de transcodificação, mesmo que o carregamento do processador ainda permita.
De qualquer forma, o servidor Transcoder continuará distribuindo aos servidores de Borda os fluxos que já foram transcodificados nele.
O final segue
Portanto, implantamos servidores dedicados para transcodificar fluxos de mídia em nossa CDN e, portanto, podemos oferecer aos nossos visualizadores uma qualidade de transmissão dependendo das capacidades de seus equipamentos e da qualidade dos canais. No entanto, ainda não abordamos a questão de restringir o acesso aos threads. Vamos considerá-lo na parte final.
Referências
A CDN de streaming WebRTC de baixa latência é uma rede de entrega de conteúdo baseada em servidor de chamadas da Web.