Ahora, parece imposible encontrar un mensajero sin la función de llamada. Esto es conveniente para los usuarios, ya que todas las comunicaciones se pueden realizar en una sola aplicación. Si combinamos todas las estadísticas disponibles en los medios, resulta que la gente habla por Internet durante más de mil millones de minutos al día. Y con el desarrollo de la tecnología, la participación de la comunicación por video está creciendo, porque el video transmite mejor las emociones del interlocutor y le permite crear el efecto de la presencia.
Un nuevo desafío para el servicio de videollamadas es reunir en una conferencia a toda la familia o un grupo de amigos ubicados en diferentes partes del mundo, o colegas que trabajan de forma remota en el mismo proyecto, para la planificación.
El jefe de desarrollo de las plataformas de Video y Cinta, Alexander Tobol (
alatobol ), mostrará que debajo del capó hay un servicio de videollamadas, qué tecnologías y hacks usar para hacer su servidor de conferencia, y cómo transferir video correctamente. Entra en el corte y aprende cómo transferir un servicio de llamadas individuales a llamadas grupales para 100 personas y por qué necesitas apoyo para tantos participantes.
El artículo se basa en un informe sobre
HighLoad ++ Siberia , en el que Alexander Tobol intenta dar una imagen completa. Si ya está familiarizado con otros materiales sobre el tema (por ejemplo,
sobre las características de transmisión de video y
protocolos de red ), puede omitir la parte teórica e ir directamente a la
solución .
El bosquejo del artículo:Historial de llamadas
La primera aplicación conocida para llamadas, y con el video, fue Skype, apareció en 2006. En Odnoklassniki, lanzamos llamadas basadas en una solución de Adobe en 2010-2012 ... Hace un par de años lo rehicimos por completo en WebRTC (más sobre este lanzamiento
aquí ), agregamos llamadas grupales el año pasado. Esta transición se discutirá en el artículo.
¿Por qué creo que puedo decirte cómo hacer esto? Porque nuestra audiencia mensual que usa llamadas supera los 10 millones de personas, y
tenemos más de 2 millones de llamadas por día . Además, más de la mitad de ellos ocurren a través de plataformas móviles.
Las llamadas grupales son el servicio de más rápido crecimiento, y nuestro objetivo son 100 participantes simultáneos en la conferencia. ¿Por qué tanto? En primer lugar, a veces quieres compartir una hermosa foto con tus amigos y compañeros de clase o realizar un seminario. En segundo lugar, incluso si cree que su servicio no necesita algo, todo puede cambiar.
Ahora puede parecer que no se necesitan videoconferencias para 100 participantes, y hace cinco años me preguntaron por qué estamos lanzando videos en 4K. Ahora, un televisor 4K es un lugar común, y estábamos listos en 2014.
El punto no está adelantado. Si desea hacer un buen servicio, aumente su nivel de requisitos.
Si puede hacer llamadas que funcionen bien para 50-100 personas, entonces para 6-10 usuarios todo funcionará bien.
Cada servicio de llamadas tiene 4 componentes relativamente independientes:
- Señalización La tarea es llamar al suscriptor, intercambiar datos iniciales, informar lo que puede hacer cada suscriptor y luego establecer un canal a través del cual se puedan transmitir los datos de video.
- Video / audio. Los datos de video y audio se comprimen usando códecs.
- Red. Es necesario garantizar el trabajo en redes defectuosas, implementar la recuperación de paquetes, conexiones p2p, etc.
- Topología : se agrega en caso de llamadas grupales.
Puede hablar sobre cualquiera de estas partes por separado. Pero quiero dar una idea general de cómo funcionan las llamadas, así que intentaré encajar todo en una historia.
Antes de comenzar a trabajar en el servicio, debe identificar los
requisitos :
- Establezca rápidamente una conexión para que la conexión se establezca inmediatamente después de que el interlocutor levante el teléfono.
- Alta calidad de llamada para que el video no se desmorone y no se congele.
- El número de participantes en la llamada , para que pueda llamar en chats, en los que hasta 100 participantes.
- Baja latencia entre las personas que llaman. La latencia de 1.3 s como Polycom no nos conviene en absoluto.
Estos son los significados específicos en los que se expresan estos requisitos para las llamadas grupales: inicio de una llamada no más de 1 segundo; una red en la que el video de 300 Kbps funciona de manera estable; latencia de la persona que llama al oyente no más de 0.5 segundos; 100 usuarios en una llamada.
¿Qué hay en el camino?
Como sabe, los datos en las redes se transmiten en paquetes: hay un socket, envía un flujo de datos allí, todo se va volando, como si estuviera en una caja negra, está ensamblado y funciona.
Pero las redes son diferentes. La mitad de las llamadas se realizan a través de redes móviles, y no siempre parecen una autopista.
Las redes se pueden sobrecargar, luego los datos se perderán y deberán restaurarse, lo que cargará aún más la red. Hay redes con las que todo parece estar en orden, pero los paquetes aún desaparecen, por ejemplo, debido al hecho de que el enrutador Wi-Fi está ubicado detrás de un muro de hormigón armado.
Funciones de red
Analizaremos las características principales que describen la calidad de la red.
RTT
Tiempo de ida y vuelta: el tiempo entre el servidor que envía los datos al cliente y recibe el acuse de recibo.
Recuerde, queremos establecer una conexión en 1 segundo. Si el tiempo de ida y vuelta es de 200 ms, entonces, con la conexión establecida, por ejemplo, a través de TCP, más algunos TLS,
puede perder 500 ms solo cuando se establece la conexión . Solo quedarán 500 ms, es decir Un par de solicitudes más, después de lo cual se debe establecer la conexión. Por lo tanto, con solicitudes adicionales con RTT, debe trabajar con mucho cuidado.
Un ejemplo:
$ 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
Con RTT = 220 ms, recibir una respuesta a través de https lleva hasta 800 ms. Por lo tanto, si tiene una conexión segura de socket web, con un ping de este tipo desaparecerá todo el segundo.
La tabla muestra los retrasos del protocolo de enlace medidos en redes móviles (en
este informe, más detalles sobre el funcionamiento de las aplicaciones en redes móviles).
Rendimiento
Puede enviar paquetes a la red como lo desee: en lotes o martillar inmediatamente todo en el búfer, aún llegarán al cliente de manera uniforme. El número de paquetes o datos por segundo es el ancho de banda o el ancho de banda.
El problema es que el
ancho de banda en las redes móviles cambia constantemente . Si cae bruscamente y los datos se transmiten con la misma tasa de bits, obviamente sufrirán pérdidas y la llamada del usuario se "colgará". Esto también tendrá que ser combatido.
Pérdida de paquetes
Al transferir datos, el paquete puede perderse. En este caso, hay una opción: omitir parte de los paquetes y obtener distorsiones, o tratar de retransmitir paquetes y obtener un cuadro congelado.
Nerviosismo
El hecho es que los paquetes no llegan de manera uniforme uno a la vez, sino en paquetes agrupados en algún intervalo.
Jitter es 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 varias veces (ping es un valor inestable, es necesario promediar), obtuvimos el jitter promedio:
((132-117)+(176-132)+(225-176)) / 3 = (14 + 44 + 79) / 3 = 46 .
Supongamos que transmitimos un video, y un cuadro es un paquete de red. Se juegan varios fotogramas sin interrupción, pero el tercer pájaro se retrasa debido a la fluctuación: obtenemos un cuadro congelado. Por lo tanto, debe acumular paquetes en algún lugar e igualar este efecto.
Es decir, para caracterizar redes inalámbricas, es suficiente conocer los siguientes valores: RTT (tiempo de ida y vuelta); ancho de banda BW (ancho de banda); porcentaje de pérdida de paquetes; nerviosismo
¿Cómo se ve el usuario?
Antes de comenzar a optimizar su experiencia de red, debe averiguar qué tipo de Internet tienen los usuarios; tal vez todos tengan una red perfecta, cualquier solución funcionará.
En el 80% de los casos, el usuario final usa una conexión inalámbrica: es una red móvil o Wi-Fi.
En Rusia, fuera de la región occidental y las grandes ciudades, las características promedio de la red son: RTT - 200 ms, ancho de banda - 1.1 Mbps, pérdida de paquetes - 0.6%, jitter - 5ms.
Dividimos estos valores por tipos de redes y nos dimos cuenta de que aprender a trabajar en esto es necesario.
Funciones de desarrollo de llamadas
Mucha gente lo olvida, pero LTE y 3G son canales de comunicación asimétricos: el enlace descendente siempre es más que un enlace ascendente. Dependiendo del tipo de protocolo, esta relación puede variar de 15/85 a 30/70. Al diseñar llamadas, esto es importante.
¿Cómo verificar qué canal tienen sus clientes?
Puedes ver speedtest, cuál es la relación de velocidad en el mundo entre Internet móvil y fijo. Resultó que en todo el mundo la Internet fija también es asimétrica. Afortunadamente, en Rusia resultó ser simétrico: la relación de enlace ascendente / enlace descendente en un Internet fijo a través de Wi-Fi en Rusia es 50/50. Nos centraremos en tales valores.
En pocas palabras: las redes inalámbricas son populares e inestables.
- Más del 80% de los clientes usan internet inalámbrico.
- La configuración inalámbrica está cambiando dinámicamente.
- Las redes inalámbricas tienen altas tasas de pérdida de paquetes, fluctuaciones, reordenamiento.
- Canal ascendente / descendente asimétrico en una proporción de 30/70.
Llamadas
Con esta reserva de conocimiento, volvamos a la implementación de llamadas grupales. Considere un algoritmo para una llamada grupal simple, que luego refinamos.
Paso 1. Alice quiere llamar a Boris y le envía una oferta, en la que informa todo lo que puede, que admite protocolos, configuraciones, etc.
Paso 2. Boris responde a Alice, después de lo cual se establece una conexión de transporte.
Paso 3. Después de eso, comienza el intercambio de datos de audio / video.
La arquitectura de cualquier llamada se parece al diagrama a continuación.
Siempre hay un servidor compartido, pero cuando se establece la conexión, los usuarios ya pueden transferir datos p2p oa través de servidores de terceros.
Los datos son capturados por una cámara que los codifica en el dispositivo y los envía a la conexión de socket. Pasan a través de la red, se reproducen en el otro lado mediante el códec y se muestran en la pantalla.
Considere todos los pasos del algoritmo en detalle e intente cambiar de llamadas 1 a 1 a llamadas grupales.
Señalización
Tarea: informar una llamada y establecer conexiones de datos.
Todo es bastante simple:
- Alice llama, se envía una notificación a Boris en un dispositivo móvil o navegador.
- Se establece un socket web o cualquier otra conexión.
- Después de esto, se produce una negociación: Alice y Boris están de acuerdo.
- Cuando se levanta el auricular en un dispositivo, la llamada finaliza automáticamente en el otro.
La plataforma de llamadas en Odnoklassniki admite varios clientes y transportes. Todos están cerca de algún tipo de servidor, que se dedica a atender una llamada y reenviar mensajes.
En caso de un bloqueo del servidor o instalación de actualizaciones, hay un almacenamiento persistente en el que se graban todos los mensajes. En caso de pérdida del servidor, puede cambiar fácilmente a otro. Esto es lo que hace ZooKeeper.
La única dificultad es
exactamente una vez . No queremos aplicar algunos mensajes dos veces. Este problema se resuelve simplemente: todos los mensajes tienen un número de serie: dos veces no llegará un solo mensaje.
Además, debe tener cuidado al crear una llamada. Una persona puede crear una llamada, colgar y crear otra llamada. O puede que no se cuelgue, pero aún así cree otro. Todas estas llamadas no son únicas: no está claro si se trata de una retransmisión o si el usuario hizo doble clic en el botón de llamada. Se repara fácilmente: se genera una identificación única en el cliente y se realiza la deduplicación. En principio,
no hay dificultades en la señalización .
La señalización p2p al grupo se finaliza fácilmente.
Las mismas ofertas y respuestas que Alice ahora envía no solo a Boris, sino también a Dima. Los reciben, de acuerdo, los canales de intercambio de datos aparecen entre ellos.
Audio / Video
Para hacer frente a una llamada grupal y comprender qué tecnologías se necesitan, tendremos que hablar un poco sobre qué es el video.
El video es de 24 o 60 cuadros por segundo. Para comprimirlos, se utilizan códecs. La esencia principal de los códecs es que cada pocos cuadros hay un cuadro de referencia (como JPEG), y los cuadros intermedios se determinan mediante cambios.
En la imagen de arriba, el primer cuadro con la máquina es el de referencia, y en el cuadro siguiente, solo se codifican los cambios (movimiento de la máquina), y la próxima vez solo se codifican también los cambios.
Esto se llama grupo de imágenes: un conjunto independiente de tramas interconectadas que se pueden decodificar. Codec es un algoritmo de transformación entre cuadros. Cuanto más inclinado es el códec, mejor comprime los datos y más recursos necesita.
Sobre la relación de tasas de bits de códec hay reglas generales (ver
enlace ).
Los códecs más populares utilizados para las llamadas son
H.264 y VP8 . H.264 es bueno porque funciona en todas partes y no consume batería. Pero generalmente en teléfonos un codificador (codificador) y 4 decodificadores. Para todo lo demás, necesita el software VP8, que consume una buena batería. Vale la pena cambiar la prioridad a H.264 para llamadas grupales (vea el
enlace sobre cómo hacerlo).
El códec puede codificar con una variable (tasa de bits variable) o una tasa de bits constante (tasa de bits constante). Muchos códecs en dispositivos no admiten una tasa de bits constante, por lo que debe vivir con la imagen de la izquierda.
Códecs de audio
Existen varios códecs heredados para audio, como el G711. El códec Opus es muy popular: resuelve el problema de codificación tanto a velocidades de bits bajas como a altas, porque en su interior contiene SILK de Skype y el códec CELT para música.
Vale la pena decir que Opus tiene un algoritmo de corrección de errores proactivo (FEC). Para el audio, este algoritmo funciona así: en cada paquete hay datos en alta calidad y datos de cuadros anteriores durante algún tiempo en baja calidad. En consecuencia, si se pierde el paquete anterior, puede obtener los datos del paquete anterior en baja calidad y de alguna manera perder. En promedio, resulta bastante bueno.
Cuando se trabaja con códecs de audio, es interesante observar el gráfico, que muestra la relación entre la calidad de la señal de entrada y la tasa de bits.
Se puede ver que Opus resuelve casi todos los problemas. Es interesante prestar atención a AAC, que se usa al codificar video en varios servicios de alojamiento, y al antiguo códec Speex, que se usaba exclusivamente para audio y funciona hasta 32 Kbps.
Datos de patología mediática
Para comprender cómo funcionan las topologías, qué características tienen, debe comprender cómo un códec de video maneja las pérdidas.
En el primer caso, no se perdió nada, y vemos una buena imagen. En la segunda línea, se pierde un cuadro aleatorio: hay pequeños artefactos en la imagen. En el tercer caso, el marco de referencia desapareció, por lo tanto, hasta el siguiente marco de referencia, se mostrarán cambios superpuestos aleatoriamente.
Obviamente, hacer marcos de referencia a menudo es costoso porque la tasa de bits está creciendo. Por lo tanto, casi todos los servicios de llamadas de alguna manera admiten la capacidad de solicitar un marco de referencia en caso de pérdida. En WebRTC, esto se llama INTRA-frame completo.
La topología más simple es enviar todos sus videos a todos los demás participantes de la conferencia.
Comenzamos un códec y comenzamos a transferir video. Alice enciende la cámara, el códec, envía su video a Boris y Dima. Pero si Dima tiene una mala conexión a Internet, Boris sufre porque necesita reducir la calidad de todo el video. Y si Dima perdió el tiro y solicitó uno de apoyo, Boris también lo recibirá, aunque no lo necesitaba.
Por otro lado, puedes pegar todos los videos en una secuencia. Esto requerirá un equipo especial y, posiblemente, habrá demoras adicionales, pero también existe una solución.
Transporte o entregue video y audio con un retraso mínimo
Tenemos la opción de protocolos TCP o UDP.
Probablemente todos recuerden que TCP es un protocolo confiable, que en caso de pérdida de paquetes los envía nuevamente. Es por eso que este orden de cuadros es posible, como en la imagen a continuación.
Si falta un paquete en el paquete, puede omitir libremente este uno de los 24 fotogramas en el video, pero TCP no le permitirá recibir lo siguiente hasta que envíe el perdido.
La entrega de video a través de TCP es extremadamente ineficiente. UDP se recomienda para tales tareas, y todos los servicios de llamadas lo usan.
Este
artículo proporciona todas las características de ambos protocolos y explica por qué toda la transmisión funciona en UDP. Como parte del tema de hoy, es suficiente para nosotros saber que UDP no está disponible en todas partes, no funciona en el 3% de las redes.
En general, los usuarios pueden establecer conexiones P2P entre ellos.
Esto es lo más rentable, porque si nos llamamos en Novosibirsk, es mucho mejor comunicarse directamente y no usar un servidor adicional que proporcione apalancamiento.
Pero existe NAT, y más del 97% de los usuarios ahora se encuentran detrás de él; pocos tienen IP externas. Por un lado, este problema tarde o temprano será resuelto por IPv6. Por cierto, en Rusia, MTS fue el primero en lanzarlo. Ahora son totalmente compatibles con IPv6, y todos sus clientes tienen IP blancas.
NAT puede abrirse paso, puede no abrirse paso, y luego tendrá que usar el respaldo a través del servidor. También hay un
artículo sobre cómo romper NAT.
Jitter buffer entre transporte y tramas
Seguimos adelante. Ahora necesitamos jitter buffer para nivelar el efecto de jitter
Comenzamos proactivamente a mostrar cuadros con cierto retraso y, mientras tanto, alineamos cuadros en el mismo intervalo en el búfer.
El búfer aumenta dinámicamente.
Si se pierde el marco y la imagen se congela, el búfer aumenta, y ya estamos trabajando con un búfer de este tamaño.
Pero puede haber una situación inversa cuando necesite reducir el búfer. Por ejemplo, la red se ha estabilizado y es necesario recuperar el tiempo. Si simplemente reduce el búfer, será ridículo, la gente comenzará a hablar muy rápido con la voz de un gnomo. Por lo tanto, existen algoritmos especiales que ajustan imperceptiblemente la velocidad del audio: elimine las pausas entre palabras o colapse los sonidos que son demasiado largos en el habla.
Si desea transcodificar un video y arreglar algo, primero debe tener un búfer de fluctuación, y su latencia no será menor que la fluctuación de fase de esta red. Es decir, definitivamente aumenta la latencia, y recordamos que realmente queremos mantenernos dentro de 0.5 s.
Exhala: ¡la teoría ha terminado!
Llamadas a OK
Antes de las llamadas grupales, teníamos llamadas p2p, se usaba la biblioteca WebRTC, se recopilaban clientes web y móviles, se escribía la señalización.
Análisis de la competencia.
Cuando no sabes qué hacer, mira a tus competidores. Como referencia, elegimos un conjunto: Skype, WhatsApp, Hangouts, ICQ, Zoom. Medimos el número máximo de participantes en una llamada grupal, latencia, consumo de batería y calidad.
Lo más interesante es determinar el retraso. Lo hacemos de esta manera: enciende el temporizador, comienza a grabar un video, realiza una llamada.
100 ms: retraso de la cámara desde el momento en que el video golpea la lente, antes de que se dibujara en la matriz del teléfono. Después de eso, el video se envía a la red y vemos un retraso de 310 ms en la llamada.
No olvide medir el uso de la CPU en el dispositivo. Comenzando con iOS 12, se hizo posible hacer esto sistemáticamente, pero usamos un pirómetro a la antigua usanza.
Obtuve los siguientes resultados:
WhatsApp e ICQ tienen un máximo de 4 participantes, Skype tiene 25 (Skype for Business 250) y 100 Hangouts y Zoom cada uno. Hangouts solía tener unos 35 miembros, y ahora saltó a la sección de más de 100.
El zoom tiene un retraso un poco más largo, pero Hangouts consume más batería. Me pareció que Zoom tiene mejor calidad, pero hay artículos que dicen lo contrario: esta es una métrica subjetiva.
Algunos servicios usan WebRTC abierto, otros usan protocolos propietarios. Pero es obvio que el tipo de transporte que usa a continuación no afecta el número de participantes en la llamada. Hay soluciones con 100 llamadas y con sus propios protocolos (Zoom) y con WebRTC (Hangouts).
Escala de 2 a N
Considere un caso interesante: hay un cliente con un canal asimétrico, entrada 3 Mbit / s, salida 1.5 Mbit / s, pérdida de paquetes 0.6%, jitter 50 ms. Hay video en HD (1280x720) con una tasa de bits de 1.5 Mbps y video con una resolución de 640x360 (llamemos BAJO) a 600 Kbps. Queremos transmitir videos geniales.
En caso de que dos personas llamen p2p, entonces todo es simple. Tienen suficiente red de entrada, la red de salida es lo suficientemente estrecha, porque el canal es asimétrico y no hay problemas con los códecs: todos los códecs son gratuitos.
Cuando comenzamos a hacer llamadas grupales, necesitamos volver a conectar a todos. La versión más simple de la topología es
Mesh o "todos para todos".
Es genial que no se necesiten servidores intermedios, pero se está volviendo problemático darles a todos su video para clientes con tales características. Y si el cliente no puede distribuir el video a alguien solo, entonces debe reducir la calidad, porque la transmisión común está codificada para todos.
En este caso, para 5 participantes, ni 3 ni 4 Mbps son suficientes.
Por lo tanto, en WhatsApp en una llamada grupal hay un máximo de 4 participantes, y ya no será así mientras usen Mesh.
Otra opción es
recopilar la imagen completa
en el servidor . Esto es lo más rentable para el cliente: tiene una conexión con el servidor, el servidor recoge la imagen, el cliente la recibe.
Pero supongamos que nuestros usuarios de Petropavlovsk-Kamchatsky, Komsomolsk-on-Amur y Novosibirsk quieren chatear a través de un servidor de Moscú. Naturalmente, saldrá muy mal. La presencia de CDN ayudará un poco, pero aún obtendrá una gran cantidad de amortiguadores de jitter, lo que en total será una adición decente a la latencia.
La siguiente topología,
Finalizar la mezcla , sugiere no recopilar una imagen general en el servidor para evitar estos retrasos, sino simplemente lanzar paquetes.
Es decir, el servidor en esta topología es simplemente un relé que transfiere datos.
Todo está mejorando un poco: el usuario recibe transmisiones de todos los demás participantes en la llamada y envía las suyas solo una vez. Pero de nuevo hay problemas:
- Calidad. Todos los destinatarios de su transmisión tienen una red diferente. Si una persona se conectó a Internet deficiente, entonces el video debe ser entregado a él en baja resolución y, en consecuencia, la imagen será mala para todos.
- Marcos de referencia de tormenta . Si una persona con Internet deficiente solicita constantemente un marco de referencia, entonces todos también comienzan a recibir oporniks. Este es un uso ineficiente de la tasa de bits, la calidad disminuye nuevamente.
Si
se utiliza un
sistema centralizado, es decir, todo el video se recopila en el servidor. Esto requiere muchas etapas de codificación, que añaden latencia y requieren hardware adicional. Al final de la mezcla, por el contrario, todo es rápido y fácil.
Contras topologías:- Malla - máximo 4 miembros.
- Centralizado: problemas con la transcodificación y la fluctuación de fase.
- Fin de la mezcla: límite de calidad y marcos de referencia de tormenta
Solo ICQ y Skype funcionan en la topología de malla, y todo lo demás son mezclas finales. Pero, como recordamos, todos los servicios son diferentes en términos de características, lo que significa que no solo hay que finalizar la mezcla, sino algo más.
Hangouts hizo el truco con End mix.
Se lanzan dos codificadores en cada cliente: H.264 en alta calidad y VP8 en baja calidad. En consecuencia, para los usuarios con buena Internet, el servidor transmite video de alta calidad, para aquellos que tienen una Internet pobre, es peor, y la mala calidad se adapta a la peor red. Dos cualidades son buenas, pero esto es tráfico extra de los clientes y consumo de batería. Pero no hay jitter buffer
La tabla muestra que, con Hangouts ejecutándose, el teléfono se calienta más que nada, tiene retrasos mínimos, pero la calidad sufre, porque la baja calidad aún se come la alta tasa 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 , —.
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 , .
Conclusiones
, . , : signaling; / ; . , , .
?
/ .
, , —
. , latency, . , ! - :)
HighLoad++ . ( ) , 6-7 2020 . , .