Agora, parece impossível encontrar um messenger sem o recurso de chamada. Isso é conveniente para os usuários, porque todas as comunicações podem ser conduzidas em um aplicativo. Se combinarmos todas as estatísticas disponíveis na mídia, as pessoas conversam pela Internet mais de um bilhão de minutos por dia. E com o desenvolvimento da tecnologia, a participação da comunicação por vídeo está aumentando, porque o vídeo transmite melhor as emoções do interlocutor e permite criar o efeito da presença.

Um novo desafio para o serviço de videochamada é reunir ao mesmo tempo uma família inteira ou um grupo de amigos localizados em diferentes partes do mundo, ou colegas trabalhando remotamente no mesmo projeto, para planejar.

O chefe de desenvolvimento das plataformas de vídeo e fita, Alexander Tobol ( alatobol ), mostrará que, sob o capô, existe um serviço de chamada de vídeo, quais tecnologias e hacks usar para criar seu servidor de conferência e como transferir o vídeo corretamente. Venha e aprenda como transferir um serviço de chamada individual para chamadas em grupo para 100 pessoas e por que você precisa de suporte para tantos participantes.


O artigo é baseado em um relatório sobre o HighLoad ++ Siberia , no qual Alexander Tobol tenta fornecer uma imagem completa. Se você já conhece outros materiais sobre o tópico (por exemplo, sobre os recursos de transmissão de vídeo e protocolos de rede ), pode pular a parte teórica e ir direto para a solução .

O esboço do artigo:

• Histórico e chamadas de dispositivo.
• Transição de chamadas individuais para chamadas em grupo.
• Serviço de chamada de grupo DIY.
• Servidor de conferência: explore os concorrentes e faça melhor.

Histórico de chamadas

O primeiro aplicativo conhecido para chamadas, e com o vídeo, foi o Skype, apareceu em 2006. Em Odnoklassniki, lançamos chamadas com base em uma solução da Adobe em 2010-2012 ... Há alguns anos, nós a refizemos completamente no WebRTC (mais sobre esse lançamento aqui ), no ano passado, adicionamos chamadas de grupo. Essa transição será discutida no artigo.

Por que acho que posso lhe dizer como fazer isso? Porque nosso público-alvo mensal usando chamadas excede 10 milhões de pessoas e temos mais de 2 milhões de chamadas por dia . Além disso, mais da metade acontece em plataformas móveis.

As chamadas em grupo são o serviço que mais cresce, e nosso objetivo é 100 participantes simultâneos da conferência. Por que tanto? Em primeiro lugar, às vezes você deseja compartilhar uma bela foto com seus amigos e colegas de classe ou realizar um seminário. Em segundo lugar, mesmo se você acha que seu serviço não precisa de algo, tudo pode mudar.

Agora, pode parecer que videoconferências para 100 participantes não são necessárias e, cinco anos atrás, eles me perguntaram por que estamos lançando vídeo em 4K. Agora, uma TV 4K é comum e estávamos prontos em 2014.

O ponto não está adiantado. Se você deseja prestar um bom serviço, aumente sua barra de requisitos.

Se você puder fazer chamadas de bom funcionamento para 50 a 100 pessoas, para 6 a 10 usuários tudo funcionará bem.

Cada serviço de chamada possui 4 componentes relativamente independentes:

• Sinalização A tarefa é ligar para o assinante, trocar dados iniciais, informar o que cada assinante pode fazer e estabelecer um canal através do qual os dados de vídeo possam ser transmitidos.
• Vídeo / áudio. Os dados de vídeo e áudio são compactados usando codecs.
• Rede. É necessário garantir o trabalho em redes ruins, implementar recuperação de pacotes, conexões P2P, etc.
• Topologia - adicionada em caso de chamadas em grupo.

Você pode falar sobre qualquer uma dessas partes separadamente. Mas eu quero dar uma visão geral de como as chamadas funcionam, então tentarei encaixar tudo em uma história.

Antes de começar a trabalhar no serviço, você precisa identificar os requisitos :

• Estabeleça rapidamente uma conexão para que a conexão seja estabelecida imediatamente após o interlocutor atender o telefone.
• Alta qualidade de chamada para que o vídeo não se desfaça e não congele.
• O número de participantes na chamada , para que você possa ligar em bate-papos, nos quais até 100 participantes.
• Baixa latência entre os chamadores. Latência de 1,3 s, uma vez que a Polycom não nos convém.

Aqui estão os significados específicos nos quais esses requisitos para chamadas de grupo são expressos: início de uma chamada não mais que 1 segundo; uma rede na qual o vídeo de 300 Kbps funciona de forma estável; latência do chamador para o ouvinte não mais que 0,5 segundos; 100 usuários em uma chamada.

O que está no caminho?

Como você sabe, os dados nas redes são transmitidos em pacotes: há um soquete, você envia um fluxo de dados para lá, tudo voa para longe, como se em uma caixa preta, ele fosse montado e funcionasse.

Mas as redes são diferentes. Metade das chamadas são feitas através de redes móveis e nem sempre parecem uma via expressa.

As redes podem ser sobrecarregadas, os dados serão perdidos e precisarão ser restaurados, carregando ainda mais a rede. Existem redes com as quais tudo parece estar em ordem, mas os pacotes ainda desaparecem - por exemplo, devido ao fato de o roteador Wi-Fi estar localizado atrás de um muro de concreto armado.

Funcionalidades de rede

Analisaremos as principais características que descrevem a qualidade da rede.

RTT

Tempo de ida e volta - o tempo entre o servidor enviar os dados para o cliente e receber a confirmação de volta.

Lembre-se, queremos estabelecer uma conexão em 1 segundo. Se o tempo de ida e volta for de 200 ms, com a conexão sendo estabelecida, por exemplo, através de TCP, além de alguns TLS, você poderá perder 500 ms apenas na conexão . Restam apenas 500 ms, ou seja, mais algumas solicitações, após as quais a conexão deve ser estabelecida. Portanto, com solicitações extras com RTT, você precisa trabalhar com muito cuidado.

Um exemplo:

$ ping google.com 64 bytes from 173.194.73.139: icmp_seq=5 ttl=44 time=211.847 ms round-trip min/avg/max/stddev = 209.471/220.238/266.304/19.062 ms RTT = 220ms $ curl -o /dev/null -w "HTTP time taken: %{time_connect}\nHTTPS time taken: %{time_appconnect}\n" -s https://www.google.com HTTP time taken: 0.231 HTTPS time taken: 0.797 HTTP = 230ms HTTPS = 800ms 

Com RTT = 220ms, receber uma resposta via https leva até 800 ms. Portanto, se você tiver uma conexão segura de soquete da Web, com esse ping, o segundo inteiro desaparecerá.

A tabela mostra os atrasos no handshake medidos em redes móveis ( neste relatório, mais detalhes sobre a operação de aplicativos em redes móveis).

Rendimento

Você pode enviar pacotes para a rede como quiser: em lotes ou martelar imediatamente tudo no buffer, eles ainda chegarão ao cliente uniformemente. O número de pacotes ou dados por segundo é a largura de banda ou largura de banda.

O problema é que a largura de banda nas redes móveis está mudando constantemente . Se houver uma queda acentuada e os dados forem transmitidos com a mesma taxa de bits, eles obviamente sofrerão perdas e a chamada do usuário será interrompida. Isso também terá que lutar.

Perda de pacotes

Ao transferir dados, o pacote pode ser perdido. Nesse caso, há uma opção: pular parte dos pacotes e obter distorções ou tentar retransmitir pacotes e obter um quadro de congelamento.

Jitter

O fato é que os pacotes não chegam uniformemente, um de cada vez, mas em pacotes agrupados em algum intervalo.


O jitter é fácil de medir:

 PING highload.ru (178.248.233.16): 56 data bytes icmp_seq=11 ttl=43 time=117.177 ms icmp_seq=12 ttl=43 time=132.868 ms icmp_seq=13 ttl=43 time=176.413 ms icmp_seq=14 ttl=43 time=225.981 ms 

Pinganuli highload.ru várias vezes (o ping é um valor instável, é necessário fazer a média), obtivemos o jitter médio: ((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 .

Suponha que transmitamos um vídeo e um quadro seja um pacote de rede. Vários quadros são reproduzidos sem interrupção, mas o terceiro pássaro está atrasado devido ao tremor - obtemos um quadro congelado. Portanto, você precisa acumular pacotes em algum lugar e equalizar esse efeito.

Ou seja, para caracterizar redes sem fio, basta conhecer os seguintes valores: RTT (tempo de ida e volta); largura de banda BW (largura de banda); porcentagem de perda de pacotes; instabilidade.

Como é o usuário?

Antes de começar a otimizar o trabalho com a rede, você precisa descobrir que tipo de Internet os usuários têm - talvez todo mundo tenha uma rede perfeita, qualquer solução funcionará.

Em 80% dos casos, o usuário final usa uma conexão sem fio: é uma rede móvel ou Wi-Fi.



Na Rússia, fora da região oeste e das grandes cidades, as características médias da rede são: RTT - 200 ms, largura de banda - 1,1 Mbps, perda de pacotes - 0,6%, jitter - 5ms.

Dividimos esses valores por tipos de redes e percebemos que é necessário aprender a trabalhar nisso.

Recursos de desenvolvimento de chamadas

Muitas pessoas esquecem, mas LTE e 3G são canais de comunicação assimétricos: o downlink é sempre mais do que o uplink. Dependendo do tipo de protocolo, essa proporção pode variar de 15/85 a 30/70. Ao projetar chamadas, isso é importante.

Como verificar qual canal seus clientes têm?



Você pode ver o speedtest, qual é a proporção de velocidade no mundo entre a Internet móvel e a fixa. Verificou-se que em todo o mundo a Internet fixa também é assimétrica. Felizmente, na Rússia, acabou sendo simétrico: a taxa de uplink / downlink em uma Internet fixa via Wi-Fi na Rússia é de 50/50. Vamos nos concentrar em tais valores.



Conclusão: as redes sem fio são populares e instáveis.

• Mais de 80% dos clientes usam internet sem fio.
• As configurações sem fio estão mudando dinamicamente.
• As redes sem fio têm altas taxas de perda de pacotes, instabilidade e reordenação.
• Canal assimétrico de ligação ascendente / ligação descendente numa proporção de 30/70.

Chamadas

Com esse armazenamento de conhecimento, voltemos à implementação de chamadas de grupo. Considere um algoritmo para uma chamada de grupo simples, que refinamos.

Etapa 1. Alice quer ligar para Boris e enviar uma oferta, na qual ela relata tudo o que pode, que suporta protocolos, configurações etc.

Etapa 2. Boris responde Alice, após o qual uma conexão de transporte é estabelecida.

Etapa 3. Depois disso, a troca de dados de áudio / vídeo começa.

A arquitetura de qualquer chamada é semelhante ao diagrama abaixo.

Sempre existe um servidor compartilhado, mas quando a conexão é estabelecida, os usuários já podem transferir dados P2P ou através de servidores de terceiros.

Os dados são capturados por uma câmera que os codifica no dispositivo e os envia para a conexão do soquete. Eles passam pela rede, são reproduzidos do outro lado pelo codec e exibidos na tela.

Considere todas as etapas do algoritmo em detalhes e tente alternar de chamadas individuais para grupos.

Sinalização

Tarefa: relatar uma chamada e estabelecer conexões de dados.

Tudo é bem simples:

• Alice liga, uma notificação é enviada para Boris em um dispositivo móvel ou navegador.
• Um soquete da web ou qualquer outra conexão é estabelecida.
• Depois disso, a negociação ocorre - Alice e Boris concordam.
• Quando o telefone é capturado em um dispositivo, a chamada termina automaticamente no outro.

A plataforma de chamada em Odnoklassniki suporta vários clientes e transportes. Todos eles se aproximam de algum tipo de servidor, que atua no atendimento de chamadas e no encaminhamento de mensagens.

No caso de uma falha no servidor ou instalação de atualizações, há um armazenamento persistente no qual todas as mensagens são registradas. Em caso de perda do servidor, você pode facilmente mudar para outro. É isso que o ZooKeeper faz.

A única dificuldade é exatamente uma vez . Não queremos aplicar algumas mensagens duas vezes. Esse problema é resolvido de forma simples: todas as mensagens têm um número de série - duas vezes uma única mensagem não chegará.

Além disso, você precisa ter cuidado ao criar uma chamada. Uma pessoa pode criar uma chamada, desligar e criar outra chamada. Ou pode não travar, mas ainda criar outro. Todas essas chamadas não são exclusivas - não está claro se é um relé ou se o usuário clicou duas vezes no botão de chamada. É facilmente reparado: um ID exclusivo é gerado no cliente e a desduplicação é realizada nele. Em princípio, não há dificuldades em sinalizar .

A sinalização p2p para o grupo é finalizada facilmente.

As mesmas ofertas e respostas que Alice agora envia não apenas para Boris, mas também para Dima. Eles os recebem, concordam, os canais de troca de dados aparecem entre eles.

Áudio / Vídeo

Para lidar com uma ligação em grupo e entender quais tecnologias são necessárias, teremos que falar um pouco sobre o que é o vídeo.

O vídeo tem 24 ou 60 quadros por segundo. Para compactá-los, codecs são usados. A principal essência dos codecs é que, a cada poucos quadros, há um quadro de referência (como JPEG), e os quadros intermediários são determinados através de alterações.

Na figura acima, o primeiro quadro com a máquina é o de referência e, no quadro seguinte, apenas as alterações (movimento da máquina) são codificadas, e da próxima vez também apenas as alterações.

Isso é chamado de grupo de imagens - um conjunto independente de quadros interconectados que podem ser decodificados. Codec é um algoritmo de transformação entre quadros. Quanto mais íngreme o codec, melhor ele comprime os dados e mais recursos são necessários.
Sobre a proporção de taxas de bits do codec, existem regras gerais (consulte o link ).

Os codecs mais populares usados ​​para chamadas são H.264 e VP8 . O H.264 é bom porque em todos os lugares trabalha duro e não consome bateria. Mas geralmente em telefones um codificador (codificador) e 4 decodificadores. Para todo o resto, você precisa do software VP8, que consome uma boa bateria. Vale a pena alterar a prioridade para H.264 para chamadas em grupo (consulte o link sobre como fazer isso).

O codec pode codificar com uma variável (taxa de bits variável) ou uma taxa de bits constante (taxa de bits constante). Muitos codecs nos dispositivos não oferecem suporte a uma taxa de bits constante, então você precisa viver com a imagem à esquerda.

Codecs de áudio

Existem vários codecs legados para áudio, como o G711. O codec Opus é muito popular - resolve o problema de codificação com taxas de bits baixas e altas, porque por dentro contém o SILK do Skype e o codec CELT para música.

Vale dizer que o Opus possui um algoritmo proativo de correção de erros de FEC (Forward Error Correction). Para o áudio, esse algoritmo funciona assim: em cada pacote existem dados em alta qualidade e dados de quadros anteriores por algum tempo em baixa qualidade. Assim, se o pacote anterior for perdido, você poderá obter os dados do pacote anterior com baixa qualidade e, de alguma forma, perder. Em média, resulta muito bom.

Ao trabalhar com codecs de áudio, é interessante observar o gráfico, que mostra a proporção da qualidade do sinal de entrada e da taxa de bits.

Pode-se ver que o Opus resolve quase todos os problemas. É interessante prestar atenção no AAC, usado na codificação de vídeo em vários serviços de hospedagem, e no antigo codec Speex, usado exclusivamente para áudio e até 32 Kbps, funciona bem.

Dados de patologia de mídia

Para entender como as topologias funcionam, quais recursos elas têm, você precisa entender como um codec de vídeo lida com as perdas.

No primeiro caso, nada foi perdido, e vemos uma boa imagem. Na segunda linha, um quadro aleatório é perdido - existem pequenos artefatos na imagem. No terceiro caso, o quadro de referência desapareceu; portanto, até o próximo quadro de referência, serão mostradas alterações que se sobrepõem aleatoriamente.

Obviamente, criar quadros de referência geralmente é caro porque a taxa de bits está aumentando. Portanto, quase todos os serviços de chamada de alguma forma suportam a capacidade de solicitar um quadro de referência em caso de perda. No WebRTC, isso é chamado de quadro INTRA completo.

A topologia mais simples é enviar todo o seu vídeo para todos os outros participantes da conferência.

Começamos um codec e começamos a transferir vídeo. Alice liga a câmera, o codec, envia seu vídeo para Boris e Dima. Mas se o Dima tem Internet ruim, o Boris sofre, porque é preciso diminuir a qualidade de todo o vídeo. E se Dima perdeu o tiro e pediu um de apoio, Boris também receberá, embora ele não precise dele.

Por outro lado, você pode colar todos os vídeos em um fluxo. Isso exigirá equipamento especial e, possivelmente, haverá atrasos adicionais, mas essa solução também existe.

Transporte ou entregue vídeo e áudio com um atraso mínimo

Nós temos uma escolha de protocolos TCP ou UDP.
Provavelmente todos lembram que o TCP é um protocolo confiável, que em caso de perda de pacotes os envia novamente. É por isso que essa ordem de quadros é possível, como na figura abaixo.

Se um pacote estiver faltando, você poderá pular livremente esse dos 24 quadros do vídeo, mas o TCP não permitirá que você receba o seguinte até enviar o perdido. A entrega de vídeo por TCP é extremamente ineficiente. O UDP é recomendado para essas tarefas e todos os serviços de chamada o utilizam.

Este artigo fornece todos os recursos dos dois protocolos e explica por que todo o streaming funciona no UDP. Como parte do tópico de hoje, basta sabermos que o UDP não está disponível em todos os lugares, não funciona em 3% das redes.

Em geral, os usuários podem estabelecer conexões P2P entre si.

Essa é a mais lucrativa, porque, se nos ligarmos em Novosibirsk, é muito melhor se comunicar diretamente e não usar um servidor adicional que forneça alavancagem.

Mas o NAT existe e mais de 97% dos usuários agora estão localizados atrás dele - poucos têm IPs externos. Por um lado, esse problema será resolvido mais cedo ou mais tarde pelo IPv6. Aliás, na Rússia, o MTS foi o primeiro a lançá-lo. Agora eles oferecem suporte total ao IPv6, e todos os seus clientes têm IPs brancos.

O NAT pode romper, pode não romper e, em seguida, você precisará usar o fallback através do servidor. Há também um artigo sobre como romper o NAT.

Buffer de tremulação entre transporte e quadros

Nós seguimos em frente. Agora precisamos do buffer de jitter para nivelar o efeito do jitter

Começamos a mostrar proativamente os quadros com algum atraso e, enquanto isso, alinhamos os quadros no mesmo intervalo no buffer.

O buffer aumenta dinamicamente.

Se o quadro for perdido e a imagem congelada, o buffer aumentará e já estaremos trabalhando com um buffer desse tamanho.

Mas pode haver uma situação inversa quando você precisar reduzir o buffer. Por exemplo, a rede se estabilizou e o tempo precisa ser atualizado. Se você simplesmente reduzir o buffer, será ridículo, as pessoas começarão a falar muito rapidamente com a voz de um gnomo. Portanto, existem algoritmos especiais que ajustam imperceptivelmente a velocidade do áudio: remova pausas entre palavras ou reduza sons que são muito longos na fala.

Se você deseja transcodificar um vídeo e consertar algo, primeiro precisa ter um buffer de instabilidade, e sua latência não será menor que a instabilidade de latência desta rede. Ou seja, definitivamente aumenta a latência e lembramos que realmente queremos manter dentro de 0,5 s.

Expire - a teoria acabou!

Chamadas para OK

Antes das chamadas em grupo, tínhamos chamadas p2p, a biblioteca WebRTC era usada, clientes web e móveis eram coletados, a sinalização era escrita.

Análise do concorrente

Quando você não sabe o que fazer, observe seus concorrentes. Para referência, escolhemos um conjunto: Skype, WhatsApp, Hangouts, ICQ, Zoom. Medimos o número máximo de participantes em uma chamada em grupo, latência, consumo de bateria e qualidade.

O mais interessante é determinar o atraso. Fazemos da seguinte maneira: ligue o timer, comece a gravar um vídeo, faça uma ligação.

100 ms - atraso da câmera a partir do momento em que o vídeo atingiu a lente, antes de ser desenhado na matriz do telefone. Depois disso, o vídeo é enviado para a rede e vemos um atraso de 310 ms na chamada.

Não se esqueça de medir o uso da CPU no dispositivo. A partir do iOS 12, tornou-se possível fazer isso sistematicamente, mas usamos um pirômetro à moda antiga.

Obteve os seguintes resultados:

O WhatsApp e o ICQ têm no máximo 4 participantes, o Skype possui 25 (Skype for Business 250) e o Hangouts e Zoom têm 100 participantes. O Hangouts costumava ter cerca de 35 membros e agora ele passou para a seção 100+.

O zoom demora um pouco mais, mas o Hangouts consome mais energia da bateria. Pareceu-me que o Zoom tem melhor qualidade, mas há artigos que dizem o contrário - essa é uma métrica subjetiva.

Alguns serviços usam WebRTC aberto, outros usam protocolos proprietários. Mas é óbvio que o tipo de transporte usado abaixo não afeta o número de participantes na chamada. Existem soluções com 100 chamadas e protocolos próprios (Zoom) e com WebRTC (Hangouts).

Escala de 2 a N

Considere um caso interessante: existe um cliente com um canal assimétrico, entrada 3 Mbit / s, saída 1,5 Mbit / s, perda de pacotes 0,6%, jitter 50 ms. Há vídeo em HD (1280x720) com uma taxa de bits de 1,5 Mbps e vídeo com uma resolução de 640x360 (vamos chamar de BAIXA) a 600 Kbps. Queremos transmitir vídeos legais.

Caso duas pessoas liguem para p2p, tudo será simples. Eles têm rede de entrada suficiente, a rede de saída é suficientemente rígida, porque o canal é assimétrico e não há problemas com codecs - todos os codecs são gratuitos.

Quando começamos a fazer chamadas em grupo, precisamos reconectar todos. A versão mais simples da topologia é Mesh ou "todos para todos".

É ótimo que servidores intermediários não sejam necessários, mas está se tornando problemático oferecer a todos o seu vídeo para clientes com essas características. E se o cliente não puder distribuir o vídeo para alguém sozinho, será necessário diminuir a qualidade, porque o fluxo comum é codificado para todos.

Nesse caso, para 5 participantes, nem 3 nem 4 Mbps são suficientes.

Portanto, no WhatsApp em uma chamada de grupo, há no máximo 4 participantes e não será mais enquanto eles usarem o Mesh.

Outra opção é coletar a imagem inteira no servidor . Essa é a mais lucrativa para o cliente: ele tem uma conexão com o servidor, o servidor coleta a imagem e o cliente recebe de volta.

Mas suponha que nossos usuários de Petropavlovsk-Kamchatsky, Komsomolsk-on-Amur e Novosibirsk desejam conversar por meio de um servidor de Moscou. Naturalmente, tudo sairá muito mal. A presença da CDN ajudará um pouco, mas ainda assim obterá uma grande quantidade de buffers de jitter, que no total farão uma adição decente à latência.

A próxima topologia - mistura final - sugere não coletar uma imagem geral no servidor para evitar esses atrasos, mas simplesmente lança pacotes.

Ou seja, o servidor nesta topologia é simplesmente um relé que transfere dados.

Tudo está ficando um pouco melhor: o usuário recebe transmissões de todos os outros participantes da chamada e envia os seus apenas uma vez. Mas, novamente, há problemas:

• Qualidade. Todos os destinatários do seu fluxo têm uma rede diferente. Se uma pessoa estiver conectada à Internet com baixa qualidade, o vídeo precisará ser entregue em baixa resolução e, consequentemente, a imagem ficará ruim para todos.
• Quadros de referência do Storm . Se uma pessoa com Internet ruim solicita constantemente um quadro de referência, todos também começam a receber oporniks. Este é um uso ineficiente de taxa de bits, a qualidade diminui novamente.

Se um sistema centralizado for usado , ou seja, todo o vídeo será coletado no servidor. Isso requer muitos estágios de codificação, que adicionam latência e requerem hardware adicional. Na mistura final, pelo contrário, tudo é rápido e fácil.

Contras topologias:

• Malha - no máximo 4 membros.
• Centralizado - problemas com transcodificação e jitter.
• Mistura final - limites de qualidade e quadros de referência de tempestade.

Somente o ICQ e o Skype trabalham na topologia Mesh e todo o resto é mistura final. Mas, como lembramos, todos os serviços são diferentes em termos de características - o que significa que não existe apenas a mistura final, mas outra coisa.

O Hangouts fez o truque com a mixagem final.

Dois codificadores são lançados em cada cliente: H.264 em alta qualidade e VP8 em baixa qualidade. Assim, para usuários com boa Internet, o servidor transmite vídeo de alta qualidade; para quem tem Internet ruim, é pior e a qualidade baixa se adapta à pior rede. Duas qualidades são boas, mas isso é tráfego extra dos clientes e consumo de bateria. Mas não há buffer de instabilidade

A tabela mostra que, com o Hangouts em execução, o telefone aquece acima de tudo, há atrasos mínimos, mas a qualidade é prejudicada, porque a baixa qualidade ainda consome a alta taxa de bits.

, : - , H.264, ( ) End mixing . centralized-, , , , .

, : . , , , , - . , .

.

, , , latency . , , , , . centralized, , , jitter- . , , .

«», . 100, 50, 20 . .

— , 5 . . : , , , — .

«» , , , — . : , - , fps. , — . - , . , .

Mesh 3-4 latency, , Mesh. , HD End mixing, a SD — centralized.

Zoom.

, - , Zoom , WebRTC. WebRTC , .

.

CPU , . — , , , , CPU , . , .

: , , .

screen sharing . screen sharing, , . screen sharing . , fps — , , .

. — centralized, , . , .

, , , . , , .

, , - . .

Packet pacing

-, UDP- . UDP pacing. UDP- , .

, UDP , 21 100%. — .

pacing? , ( ) — , . , , , , , , - .

:

• pacing, .
• pacing, , , , .

: , pacing , —.

packet pacing?

, ( ) , , - . ( ), , , .

— packet loss , pacing.

MTU

TCP , MTU. UDP, , MTU — , .

MTU 1500, MTU 1100, . , , , , , ( ). , MTU .

TCP , . , MTU: - , , , MTU. , MTU, , .

.

, : , , . 98% 1350. MTU = 1350 , , 2% — , .

WebRTC SACK, NACK, FEC. .

, 1–3% — , .

WebRTC negative acknowledgement (NACK).

, , - , .

, TCP acknowledgement, selective acknowledgement. negative acknowledgement , FEC (Forward Error Correction).

, SACK, NACK, FEC, .

FEC , , . : , , . , , — .

FEC — XOR, , , . , - .

, . , , , FEC-. , , , , .

, , . , :

• 90% 500 /.
• — 3-4, Mesh End mixing.
• — 27 (, ).

Check List

:

• Packet pacing.
• MTU discovery.
• .
• C .

, signalling, WebRTC, , , - .

, :

• Packet loss: , packet pacing, FEC, MTU.
• : back pressure , FEC-.
• Jitter jitter buffer, latency.
• RTT: , signaling.

WebRTC — . RTP, , , . WebRTC .

, Zoom, Skype Line, . . . , , UDP- ( , WebRTC), . , , . , Google STADIA.

STADIA — , . WebRTC, , . Google WebRTC. WebRTC SRTP WebRTC QUIC. , , .

QUIC, . Chrome c Android Google YouTube, TCP — QUIC UDP Google. 30% QUIC/UDP.

QUIC 20-30%, TCP. - QUIC , .

Conclusões

, . , : signaling; / ; . , , .

?

• , - , .
• , .

/ .

, , — . , latency, . , ! - :)

HighLoad++ . ( ) , 6-7 2020 . , .