Publicar e reproduzir
Existem duas funções principais da operação do WebRTC no lado do servidor no campo de streaming de vídeo: publicação e reprodução. No caso da publicação, o fluxo de vídeo é capturado da câmera da web e passa do navegador para o servidor. No caso de reprodução, o fluxo se move na direção oposta, do servidor para o navegador, é decodificado e reproduzido no elemento <video> HTML5 do navegador na tela do dispositivo.
UDP e TCP
O vídeo pode se mover através de dois protocolos de transporte: TCP ou UDP. No caso do UDP, os feedbacks do NACK RTCP funcionam ativamente, carregando as informações sobre os pacotes perdidos, devido às quais é uma tarefa bastante simples detectar a deterioração do canal UDP, é resumido na contagem do NACK (Negative ACK) para determinar a qualidade. Quanto mais feedbacks NACK e PLI (Picture Loss Indicator) houver, mais perdas reais haverá e menor será a qualidade do canal.
TCP sem NACK
Neste artigo, vamos nos concentrar mais no protocolo TCP. Quando o WebRTC é usado sobre TCP, os feedbacks do NACK RTCP não são enviados e, mesmo se forem enviados, eles não refletem a imagem real das perdas, e não parece possível determinar a qualidade do canal pelos feedbacks. Como é sabido, o TCP é um protocolo de transporte com entrega garantida. Por esse motivo, no caso de a qualidade do canal se deteriorar, o restante dos pacotes que existem na rede serão enviados no nível do protocolo de transporte. Mais cedo ou mais tarde, eles serão entregues, mas um NACK não será gerado para essas perdas porque, de fato, não houve perdas. Como resultado, os pacotes chegarão ao seu destino com um atraso. Os pacotes atrasados simplesmente não se agrupam nos quadros de vídeo e serão descartados pelo despacketizer, como resultado do qual o usuário verá uma imagem como esta, cheia de artefatos:
Os feedbacks mostrarão que está tudo bem, mas a imagem conterá artefatos. Abaixo, você pode ver capturas de tela do tráfego do Wireshark, ilustrativas do comportamento do fluxo publicado nos canais TCP e UDP compactados, além de capturas de tela das estatísticas do Google Chrome. Nas capturas de tela, você pode ver que, no caso do TCP, a métrica NACK não cresce ao contrário do UDP, mesmo que o estado do canal seja muito ruim.
TCP
UDP
Por que transmitir em TCP, se houver UDP
Esta é uma pergunta razoável a ser feita. A resposta é, para empurrar grandes resoluções através do canal. Por exemplo, no caso de streaming de realidade virtual (VR), as resoluções podem começar a partir de 4k. Não parece possível enviar um fluxo com essa resolução e com uma taxa de bits de cerca de 10 Mbps para um canal regular sem perdas, o servidor cuspe os pacotes UDP e eles começam a se perder na rede em grupos, depois o restante deles começa a ser enviado, e assim por diante. Grandes quantidades de pacotes de vídeo descartados corrompem o vídeo, e o resultado líquido é que a qualidade fica muito ruim. Essa é a razão pela qual o WebRTC sobre TCP é usado para entregar o vídeo em redes de uso geral e com altas resoluções, como Full HD e 4K, para descartar perdas de pacotes de rede à custa de um ligeiro aumento na latência da comunicação.
RTT para determinar a qualidade do canal
Portanto, não há métrica para garantir que o canal esteja em um estado muito ruim. Alguns desenvolvedores tentam confiar na métrica RTT, mas está longe de poder trabalhar em todos os navegadores e não fornece resultados precisos.
Abaixo, você encontra uma ilustração da dependência da qualidade do canal no RTT, de acordo com o projeto callstat
Solução baseada em REMB
Decidimos adotar uma abordagem ligeiramente diferente para esse problema. Há o REMB trabalhando no lado do servidor , que calcula a taxa de bits de entrada para todos os fluxos de entrada, calcula seu desvio da média e sugere que o navegador diminua a taxa de bits no caso de uma dispersão significativa, enviando comandos REMB especializados pelo RTCP protocolo. O navegador recebe essa mensagem e reduz a taxa de bits do codificador de vídeo para os valores recomendados: é assim que funciona a proteção contra sobrecarga de canal e degradação do fluxo de entrada. Dessa maneira, o mecanismo de cálculo da taxa de bits já foi implementado no lado do servidor. A média e determinação da dispersão foram realizadas através do filtro Kalman. Isso permite obter a taxa de bits atual a qualquer momento com alta precisão e filtrar desvios significativos.
O leitor certamente terá a seguinte pergunta: “Como isso me ajudará a saber a taxa de bits que o servidor pode ver para o fluxo que entra?” Isso só permitirá que você entenda que há vídeo entrando no servidor com uma taxa de bits. dos quais foi possível determinar. Para avaliar a qualidade do canal, será necessário mais um componente.
A taxa de bits final e por que é importante
As estatísticas do fluxo WebRTC de publicação mostram com a taxa de bits que o fluxo de vídeo sai do navegador. Como diz uma piada antiga, um administrador do site diz ao verificar seu rifle de assalto: “Do meu lado, as balas voaram. Os problemas estão do seu lado ... ”A idéia de verificar a qualidade do canal envolve comparar duas taxas de bits: 1) a taxa de bits enviada pelo navegador, 2) a taxa de bits realmente recebida pelo servidor.
O administrador do site dispara as balas e calcula a velocidade em que voam ao seu lado. O servidor calcula a velocidade em que são recebidos ao seu lado. Há mais um participante deste evento, o TCP, este é um super-herói localizado no meio entre o administrador e o servidor e pode parar os marcadores aleatoriamente. Por exemplo, ele pode parar 10 marcadores aleatórios de 100 por 2 segundos e depois deixá-los voar novamente. Essa é a Matrix que vemos aqui.
No lado do navegador, obtemos a taxa de bits atual das estatísticas do WebRTC, depois suavizamos o gráfico com o filtro Kalman na implementação JavaScript e obtemos uma versão otimizada da taxa de bits do navegador do cliente no final do processo. Agora, temos praticamente tudo o que precisamos: a taxa de bits do cliente nos diz como o tráfego sai do navegador e a taxa de bits do servidor nos diz como esse tráfego é visto pelo servidor e com que taxa de bits é recebido. É óbvio que, se a taxa de bits do cliente permanecer alta e a taxa de bits do servidor começar a diminuir em relação à taxa de bits do cliente, significa que nem todos os marcadores "atingiram o destino" e o servidor não consegue ver parte do tráfego que foi enviado a ele. Com base nisso, podemos concluir que algo está errado com o canal e é hora de mudar a cor do indicador para vermelho.
E tem mais
Os gráficos se correlacionam, mas são ligeiramente alterados no tempo em relação um ao outro. Para uma correlação completa, é necessário fazer uma correspondência temporal dos gráficos para comparar a taxa de bits do cliente e do servidor no mesmo ponto do tempo com os dados históricos. A dessincronização é mais ou menos assim:
E é assim que um gráfico sincronizado com o tempo se parece.
Vamos testar
Ainda temos um pouco a fazer, só precisamos testá-lo. Vamos publicar um fluxo de vídeo, abri-lo e ver o gráfico das taxas de bits publicadas: no lado do navegador e no lado do servidor. Os gráficos demonstram praticamente uma combinação perfeita. E este é o nome do indicador, PERFEITO.
Então, vamos começar a corromper o canal. Para fazer isso, podemos usar as seguintes ferramentas gratuitas: winShaper for Windows ou Network Link Conditioner for MacOS. Eles permitem comprimir o canal para o valor predefinido. Por exemplo, se sabemos que um fluxo de 640x480 pode atingir uma velocidade de 1 Mbps, vamos compactá-lo para 300 kbs. Ao fazer isso, não devemos esquecer que estamos trabalhando com o TCP. Vamos verificar o resultado do nosso teste: há correlação inversa nos gráficos e o indicador está caindo para RUIM. De fato, o navegador continua enviando dados e está aumentando ainda mais a taxa de bits na tentativa de inserir uma nova parte do tráfego na rede. Esses dados se acumulam na rede na forma de retransmissões e não alcançam o servidor, como resultado, o servidor demonstra uma imagem inversa e diz que a taxa de bits que pode ver caiu. Na verdade, é ruim.
Realizamos muitos testes que mostram a operação correta do indicador . Como resultado disso, temos um recurso que possibilita informar o usuário de maneira confiável e imediata sobre quaisquer problemas com o canal, tanto para publicação quanto para reprodução em fluxo (trabalhando pelo mesmo princípio). Sim, todo esse barulho foi por essa lâmpada verde e vermelha, PERFEITO-RUIM. Mas a prática mostra que esse indicador é muito importante, e sua ausência, juntamente com a falta de compreensão do status atual, pode criar grandes problemas para um usuário comum de um serviço de streaming de vídeo WebRTC.
Ligações
O WCS 5.2 é um servidor de mídia de streaming para desenvolvimento de aplicativos móveis e na Web
Controle de qualidade do canal do editor e do player
REMB - Taxa de bits máxima estimada do receptor usada para controle de largura de banda
NACK - confirmação negativa usada para perda de controle de pacote e retransmissão