Na primeira parte , implantamos uma CDN dinâmica simples para transmitir fluxos WebRTC para dois continentes e provamos no exemplo de um temporizador de contagem regressiva que a latência nesse tipo de CDN é realmente baixa.
No entanto, além da baixa latência, é importante fornecer boa qualidade de transmissão aos usuários. Afinal, é isso que eles estão pagando. Na vida real, os canais entre servidores e usuários do Edge podem diferir na capacidade e qualidade da largura de banda. Por exemplo, estamos publicando um fluxo de 720p a 2 Mbps, o usuário está reproduzindo-o em um telefone Android usando conexão 3G em uma área de recepção de sinal instável e a resolução máxima de 360p que fornece imagens suaves a 400 Mbps é de 360p.
Os dispositivos e navegadores que os espectadores estão usando podem diferir bastante. Por exemplo, estamos publicando um fluxo WebRTC usando o codec VP8 no Chrome no PC e o visualizador está reproduzindo o fluxo no Safari em um iPhone, que suporta apenas o codec H264. Ou vice-versa, estamos publicando um fluxo RTMP do OBS Studio, codificando o vídeo em H264 e o som no AAC, e o cliente está usando um navegador baseado em Chromium que suporta apenas VP8 ou VP9 para o vídeo e Opus para o som.
Também podemos precisar melhorar a qualidade da publicação inicial. Por exemplo, estamos compartilhando um fluxo de uma câmera IP em um parque natural, na maioria das vezes a imagem é estática e a câmera a entrega em 1 quadro por segundo. No entanto, queremos fornecer aos espectadores 24 quadros por segundo. O que deve ser feito, se não houver possibilidade de substituir a câmera ou modificar suas configurações?
Em todos esses casos, precisaremos transcodificar o fluxo no servidor, que é decodificar cada quadro recebido e depois codificá-lo com novos parâmetros. Além disso, os parâmetros a serem modificados geralmente são conhecidos apenas no lado do cliente. Vamos dar uma olhada em como alcançar a transcodificação na CDN, mantendo um equilíbrio entre a qualidade da transmissão e a carga do servidor.
Transcodificação: como, onde e por quê?
Suponha que estamos cientes dos parâmetros de fluxo que o cliente deseja receber. Por exemplo, o visualizador começou a reproduzir o fluxo, e o número de perdas de quadros nas estatísticas do WebRTC nos diz que a resolução e a taxa de bits precisam ser reduzidas antes que o cliente mude para outro programa . Nesse caso. o fluxo será transcodificado por padrão no servidor de borda ao qual o visualizador está conectado.
Se o cliente não suportar o codec usado durante a publicação de fluxo, a transcodificação poderá ser imposta nos servidores Edge e Origin.
Ambos os métodos funcionam apenas como uma solução temporária, desde que as configurações do servidor Origin e / ou Edge sejam definidas com uma margem. A transcodificação é sempre realizada quadro a quadro, portanto, é muito exigente os recursos da CPU. Assim, um único núcleo da CPU é capaz de transcodificar apenas um pequeno número de fluxos:
Mesmo se formos executar um único processo de transcodificação para todos os usuários que precisam de parâmetros iguais de fluxo de mídia, é altamente provável que alguns visualizadores com parâmetros diferentes consumam totalmente os recursos do servidor.
Dessa maneira, a decisão correta é separar servidores dedicados na CDN para executar a tarefa de transcodificação e escolher a configuração do servidor, levando em consideração essa tarefa.
Adicionando nós do transcodificador à CDN
Agora, vamos implantar dois servidores Transcoder em nossa CDN: um no data center europeu e outro no americano.
Configuração dos servidores Transcoder:
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 por meio de perfis especiais no arquivo cdn_profiles.yml . Como exemplo, observe os três perfis usados por padrão:
- transcodificando para resolução de 640x360, 30 quadros por segundo, o quadro-chave será enviado a 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 de 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 resolução de 1280x720, 30 quadros por segundo, o quadro-chave será enviado a cada 90 quadros, taxa de bits de 2 Mbps, 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
Vamos publicar o fluxo de test 720p no servidor o-eu1 e reproduzi e-eu1 no e-eu1 especificando o perfil no nome do fluxo, por exemplo, test-640x360
O fluxo está sendo transcodificado!
Agora podemos descrever vários perfis nos servidores de Borda, por exemplo, -240p, -360p, -480p e, se um grande número de quadros perdidos for diagnosticado no lado do cliente de acordo com as estatísticas do WebRTC, poderemos repetir automaticamente a solicitação de um fluxo de resolução mais baixa.
Agrupando nós CDN por continentes
Atualmente, temos servidores Transcoder de mesmo nível. Mas e se quisermos transcodificar os fluxos com base na distribuição geográfica: para os telespectadores americanos na América, para os telespectadores europeus na Europa? A propósito, isso permitirá reduzir a carga nos canais transatlânticos, porque o servidor Origin EU transmitirá para a América e receberá apenas os fluxos originais, em vez de todas as variantes dos canais transcodificados.
Nesse caso, é necessário especificar o grupo CDN necessário nas configurações do nó Transcoder
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 do servidor de Borda.
cdn_groups=EU
cdn_groups=US
Vamos reiniciar os nós com novas configurações. Em seguida, vamos publicar o fluxo de test 720p no servidor o-eu1 e reproduzi-lo no e-eu1 com transcodificação.
Para garantir que o fluxo esteja sendo transcodificado no t-eu , precisamos abrir a página de estatísticas em http://t-eu1.flashphoner.com:8081/?action=stat e veremos o codificador e o decodificador na seção Recursos nativos.
Além disso, não há codificadores de vídeo em t-us1 nas estatísticas.
Mais transcodificadores: equilibrando a carga
Suponha que o número de visualizadores continue aumentando e que a capacidade de um servidor Transcoder por continente não seja mais suficiente. Ótimo, vamos adicionar mais um servidor para cada continente.
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
Agora, no entanto, experimentamos a questão de equilibrar a carga entre dois transcodificadores. Para evitar a transmissão de todos os fluxos por um servidor, definiremos o limite para a média de carga máxima permitida da CPU nos nós do Transcoder.
cdn_node_load_average_threshold=0.95
Quando a média de carga da CPU dividida pelo número de núcleos disponíveis atingir esse limite, o servidor deixará de aceitar solicitações para transcodificar novos fluxos.
Também podemos definir um limite para o número máximo permitido de codificadores de vídeo em execução simultânea.
cdn_transcoder_video_encoders_threshold=10000
Quando esse número é atingido, o servidor também para de aceitar solicitações de transcodificação de fluxo, mesmo que a carga da CPU ainda permita.
De qualquer forma, o servidor Transcoder continuará compartilhando os fluxos que estão sendo transcodificados nos servidores de Borda.
A ser concluído
Em resumo, implantamos em nossos servidores CDN dedicados para transcodificar fluxos de mídia e, portanto, somos capazes de fornecer boa qualidade de transmissão aos nossos espectadores, dependendo das capacidades de seus dispositivos e da qualidade dos canais. No entanto, ainda não abordamos o assunto da restrição de acesso ao fluxo. Vamos dar uma olhada nisso na parte final.
CDN para streaming WebRTC de baixa latência - rede de entrega de conteúdo baseada em Web Call Server.