Publicar e reproduzir
Existem dois recursos principais do WebRTC do servidor no streaming de vídeo: publicação e reprodução. No caso da publicação, o fluxo de vídeo é capturado da webcam 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 do navegador HTML5 <video> na tela do dispositivo.
UDP e TCP
O vídeo pode passar por dois protocolos de transporte: TCP ou UDP. No caso do UDP, os feedbacks RTCP NACK estão trabalhando ativamente, que carregam informações sobre pacotes perdidos e, portanto, determinar a deterioração do canal UDP é uma tarefa bastante simples e reduz a contagem do NACK (ACK negativo) para determinar a qualidade. Quanto mais feedbacks de NACK e PLI (Indicador de perda de imagem), mais perdas reais e pior a qualidade do canal
TCP sem NACK
Neste artigo, estaremos mais interessados no protocolo TCP. Ao usar o WebRTC sobre TCP, os feedbacks NACK RTCP não são enviados e, se forem enviados, não refletem a imagem real das perdas e não é possível determinar a qualidade do canal a partir dos feedbacks. Como você sabe, o TCP é um protocolo de transporte com entrega garantida. Por esse motivo, no caso de degradação do canal, os pacotes na rede serão enviados no nível do protocolo de transporte. Mais cedo ou mais tarde eles serão entregues, mas o NACK não será gerado para essas perdas, porque de fato, não houve perdas. Os pacotes chegarão tarde. Pacotes atrasados simplesmente não serão coletados em quadros de vídeo e serão descartados pelo despacketizer, como resultado do qual o usuário verá algo como esse cheio de artefatos:
Nos feedbacks, tudo ficará bem, mas haverá artefatos na imagem. Abaixo estão as capturas de tela do tráfego Wireshark, que ilustram o comportamento do fluxo publicado nos canais TCP e UDP compactados, bem como as capturas de tela das estatísticas do Google Chrome. As capturas de tela mostram que, no caso do TCP, a métrica NACK não cresce, em contraste com o UDP, apesar do fato de que tudo está muito ruim com o canal.
TCP
UDP
E por que você precisa transmitir via TCP se houver UDP
Pergunta razoável. Resposta: para empurrar grandes resoluções através do canal. Por exemplo, ao transmitir VR (Realidade Virtual), as permissões podem começar em 4k. Não é possível enviar um fluxo dessa resolução e taxa de bits de cerca de 10 Mbps para um canal regular sem perda, o servidor cuspe pacotes UDP e eles começam a se perder em pacotes na rede, depois enviá-los, etc. Grandes quantidades de pacotes de vídeo estragam o vídeo e, no final, a qualidade fica ruim. Por esse motivo, para redes de uso geral e altas resoluções, o Full HD, 4K, WebRTC sobre TCP é usado para entrega de vídeo para eliminar a perda de pacotes de rede ao custo de algum aumento no atraso da comunicação.
RTT para determinar a qualidade do canal
Portanto, não há métrica que garanta que tudo está ruim com o canal. Alguns desenvolvedores tentam confiar na métrica RTT, mas ela não funciona em todos os navegadores e não fornece resultados precisos.
Abaixo está uma ilustração da dependência da qualidade do canal no RTT de acordo com a versão do projeto callstat
Solução REMB
Decidimos abordar esse problema de uma perspectiva um pouco diferente. O REMB funciona 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, no caso de uma propagação grande, oferece ao navegador para diminuir a taxa de bits enviando comandos REMB especiais por meio do protocolo RTCP. 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. Assim, no lado do servidor, um mecanismo para calcular a taxa de bits já foi implementado. A média e a determinação de dispersão são implementadas através do filtro Kalman. Isso permite remover a taxa de bits atual a qualquer momento com alta precisão e filtrar fortes desvios.
O leitor provavelmente terá uma pergunta: "Qual o conhecimento da taxa de bits que o servidor vê no fluxo de entrada?". Isso permitirá entender exatamente o que o vídeo com a taxa de bits está inserindo no servidor, cujo valor foi determinado. Para avaliar a qualidade do canal, é necessário mais um componente.
Taxa de bits de saída e por que é importante
As estatísticas do fluxo WebRTC de publicação mostram com qual taxa de bits o fluxo de vídeo sai do navegador. Como em uma piada de barba: Admin, verificando a máquina: “Do meu lado, as balas voaram. Os problemas estão do seu lado .. ". A idéia de verificar a qualidade do canal é comparar duas taxas de bits: 1) a taxa de bits que o navegador envia 2) a taxa de bits que o servidor realmente recebe.
Admin dispara balas e calcula a velocidade da partida em casa. O servidor calcula a velocidade com que são recebidos em casa. Há outro participante nesse evento, o TCP é um super-herói localizado no meio entre o administrador e o servidor e pode desacelerar os marcadores aleatoriamente. Por exemplo, ele pode frear 10 balas aleatórias de cem por 2 segundos e permitir que elas voem novamente. Aqui está uma matriz.
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, na saída, obtemos uma versão otimizada da taxa de bits do navegador do cliente. Agora, temos quase 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 diz como o servidor vê esse tráfego e qual a taxa de bits que recebe. Obviamente, se a taxa de bits do cliente permanecer alta e a taxa de bits do servidor começar a diminuir em relação ao cliente, isso significa que nem todos os "marcadores voaram" e o servidor não vê parte do tráfego que foi enviado a ele. Com base nisso, concluímos que algo está errado com o canal e é hora de mudar o indicador para vermelho.
Mais por vir
Os gráficos estão correlacionados, mas mudaram um pouco no tempo em relação um ao outro. Para uma correlação completa, é necessário combinar os gráficos de tempo para comparar a taxa de bits do cliente e do servidor no mesmo momento nos dados históricos. A dessincronização é mais ou menos assim:
E parece um gráfico sincronizado com o tempo.
Teste
O caso é pequeno, resta testar. Publicamos o fluxo de vídeo, abrimos e assistimos à programação das taxas de bits publicadas: no lado do navegador e no servidor. De acordo com os gráficos, vemos uma correspondência quase perfeita. O indicador é chamado PERFEITO.
Em seguida, começamos a estragar o canal. Para fazer isso, você pode usar essas ferramentas gratuitas " winShaper " no Windows ou " Network Link Conditioner " no MacOS. Eles permitem que você aperte o canal no valor definido. Por exemplo, se sabemos que um fluxo de 640x480 pode acelerar para 1Mbps, junte-o a 300 kbs. Ao mesmo tempo, lembramos que estamos trabalhando com o TCP. Verificamos o resultado do teste - os gráficos mostram correlação inversa e o indicador cai em RUIM. De fato, o navegador continua enviando dados e até aumenta a taxa de bits, tentando inserir uma nova parte do tráfego na rede. Esses dados se instalam na rede na forma de retransmissões e não chegam ao servidor; como resultado, o servidor mostra a imagem oposta e diz que a taxa de bits que ele vê caiu. Muito ruim.
Realizamos muitos testes que mostram a operação correta do indicador . O resultado é um recurso que permite informar de maneira qualitativa e eficiente o usuário sobre os problemas do canal, tanto para publicar o fluxo quanto para a reprodução (funciona com o mesmo princípio). Sim, pelo bem dessa lâmpada verde-vermelha PERFECT-BAD, cercamos todo esse jardim. Mas a prática mostra que esse indicador é muito importante e sua ausência e incompreensão do status atual podem arruinar bastante a vida de um usuário comum de um serviço de streaming de vídeo via WebRTC.
Referências
WCS 5.2 - um servidor de mídia para o desenvolvimento de aplicativos de vídeo na Web e em dispositivos móveis
Documentação do controle de qualidade do canal WebRTC para publicação e reprodução
REMB - gerenciamento de taxa de bits do lado do servidor
NACK - controle de pacotes perdidos do lado do servidor