Publica y juega
Hay dos características principales de WebRTC del lado del servidor en la transmisión de video: publicación y reproducción. En el caso de la publicación, la transmisión de video se captura desde la cámara web y se mueve desde el navegador al servidor. En el caso de la reproducción, la transmisión se mueve en la dirección opuesta: del servidor al navegador, se decodifica y se reproduce en el elemento del navegador HTML5 <video> en la pantalla del dispositivo.
UDP y TCP
El video puede moverse sobre dos protocolos de transporte: TCP o UDP. En el caso de UDP, las retroalimentaciones RTCP NACK están trabajando activamente, lo que lleva información sobre los paquetes perdidos, y por lo tanto, determinar el deterioro del canal UDP es una tarea bastante simple y se reduce a contar NACK (ACK negativo) para determinar la calidad. Cuantos más comentarios NACK y PLI (Indicador de pérdida de imagen), más pérdidas reales y peor calidad del canal
TCP sin NACK
En este artículo, estaremos más interesados en el protocolo TCP. Cuando se usa WebRTC sobre TCP, las retroalimentaciones NACK RTCP no se envían, y si lo hacen, no reflejan la imagen real de las pérdidas, y no es posible determinar la calidad del canal por retroalimentaciones. Como saben, TCP es un protocolo de transporte con entrega garantizada. Por este motivo, en caso de degradación del canal, los paquetes en la red se enviarán a nivel de protocolo de transporte. Tarde o temprano se entregarán, pero NACK no se generará por estas pérdidas, porque no hubo pérdidas de hecho. Los paquetes eventualmente llegarán tarde. Los paquetes tardíos simplemente no se recopilarán en fotogramas de video y serán desechados por el desempaquetador, como resultado de lo cual el usuario verá algo como esto lleno de artefactos:
En los comentarios, todo estará bien, pero habrá artefactos en la imagen. A continuación se muestran capturas de pantalla del tráfico de Wireshark, que ilustran el comportamiento de la transmisión publicada en canales TCP y UDP pinzados, así como capturas de pantalla de las estadísticas de Google Chrome. Las capturas de pantalla muestran que, en el caso de TCP, la métrica NACK no crece, en contraste con UDP, a pesar de que todo está muy mal con el canal.
TCP
UDP
¿Y por qué necesita transmitir a través de TCP si hay UDP?
Pregunta razonable Respuesta: para empujar grandes resoluciones a través del canal. Por ejemplo, cuando se transmite VR (Realidad Virtual), los permisos pueden comenzar en 4k. No es posible insertar un flujo de esta resolución y velocidad de bits de aproximadamente 10 Mbps en un canal normal sin pérdida, el servidor escupe paquetes UDP y comienzan a perderse en paquetes en la red, luego se envían, etc. Grandes descargas de paquetes de video estropean el video y, al final, la calidad se vuelve mala. Por esta razón, para redes de propósito general y alta resolución, Full HD, 4k, WebRTC sobre TCP se utiliza para la entrega de video para eliminar la pérdida de paquetes de red a costa de algún aumento en el retraso de la comunicación.
RTT para determinar la calidad del canal
Por lo tanto, no hay una métrica que garantice que todo sea malo con el canal. Algunos desarrolladores intentan confiar en la métrica RTT, pero no funciona en todos los navegadores y no proporciona resultados precisos.
A continuación se muestra una ilustración de la dependencia de la calidad del canal en RTT según la versión del proyecto callstat
Solución REMB
Decidimos abordar este problema desde una perspectiva ligeramente diferente. REMB funciona en el lado del servidor , que calcula la tasa de bits entrante para todas las secuencias entrantes, calcula su desviación del promedio y, en el caso de una gran extensión, ofrece al navegador reducir la tasa de bits enviando comandos REMB especiales a través del protocolo RTCP. El navegador recibe dicho mensaje y reduce la tasa de bits del codificador de video para los valores recomendados: así es como funciona la protección contra la sobrecarga del canal y la degradación del flujo de entrada. Por lo tanto, en el lado del servidor, ya se ha implementado un mecanismo para calcular la tasa de bits. El promedio y la determinación de dispersión se implementan a través del filtro de Kalman. Esto le permite eliminar la tasa de bits actual en cualquier momento con alta precisión y filtrar grandes desviaciones.
El lector probablemente tendrá una pregunta: "¿Qué le dará el conocimiento de la velocidad de bits que ve el servidor en la transmisión entrante?". Esto proporcionará una comprensión exacta de lo que el video con la tasa de bits ingresa en el servidor, cuyo valor se determinó. Para evaluar la calidad del canal, se requiere un componente más.
Bitrate saliente y por qué es importante
Las estadísticas del flujo de WebRTC de publicación muestran con qué tasa de bits sale el flujo de video del navegador. Como en una broma con barba: Admin, revisando la máquina: “De mi lado salieron las balas. Los problemas están de tu lado ... ". La idea de verificar la calidad del canal es comparar dos velocidades de bits: 1) la velocidad de bits que envía el navegador 2) la velocidad de bits que el servidor realmente recibe.
El administrador dispara balas y calcula la velocidad de su partida en casa. El servidor calcula la velocidad a la que se reciben en casa. Hay otro participante en este evento, TCP es un superhéroe que se encuentra en el medio entre el administrador y el servidor y puede ralentizar las balas al azar. Por ejemplo, puede frenar 10 balas aleatorias de cien durante 2 segundos y luego permitirles volar nuevamente. Aquí hay una matriz así.
En el lado del navegador, tomamos la tasa de bits actual de las estadísticas de WebRTC, luego suavizamos el gráfico con el filtro de Kalman en la implementación de JavaScript y en la salida obtenemos una versión suavizada de la tasa de bits del navegador del cliente. Ahora tenemos casi todo lo que necesitamos: la tasa de bits del cliente nos dice cómo sale el tráfico del navegador, y la tasa de bits del servidor indica cómo el servidor ve este tráfico y qué tasa de bits recibe. Obviamente, si la tasa de bits del cliente sigue siendo alta y la tasa de bits del servidor comienza a disminuir en relación con el cliente, esto significa que no todas las "balas han volado" y el servidor no ve realmente parte del tráfico que se le envió. En base a esto, concluimos que algo está mal con el canal y es hora de cambiar el indicador a rojo.
Más por venir
Las gráficas están correlacionadas, pero ligeramente desplazadas en el tiempo entre sí. Para una correlación completa, es necesario combinar los gráficos de tiempo para comparar la tasa de bits del cliente y del servidor al mismo tiempo en los datos históricos. La desincronización se parece a esto:
Y parece un gráfico sincronizado en el tiempo.
Prueba
El caso es pequeño, queda por probar. Publicamos la transmisión de video, abrimos y vemos la programación de las tasas de bits publicadas: en el lado del navegador y en el lado del servidor. Según los gráficos, vemos una combinación casi perfecta. El indicador se llama PERFECTO.
A continuación, comenzamos a estropear el canal. Para hacer esto, puede usar tales herramientas gratuitas " winShaper " en Windows o " Network Link Conditioner " en MacOS. Le permiten pellizcar el canal al valor establecido. Por ejemplo, si sabemos que un flujo de 640x480 puede acelerar a 1 Mbps, pellizque a 300 kbs. Al mismo tiempo, recordamos que estamos trabajando con TCP. Verificamos el resultado de la prueba: los gráficos muestran correlación inversa y el indicador cae en MALO. De hecho, el navegador continúa enviando datos e incluso aumenta la tasa de bits, tratando de empujar una nueva porción de tráfico en la red. Estos datos se instalan en la red en forma de retransmisiones y no llegan al servidor, como resultado, el servidor muestra la imagen opuesta y dice que la tasa de bits que ve ha disminuido. Muy mal
Realizamos muchas pruebas que muestran el correcto funcionamiento del indicador . El resultado es una característica que le permite informar cualitativa y eficientemente al usuario sobre los problemas con el canal tanto para publicar la transmisión como para la reproducción (funciona según el mismo principio). Sí, por el bien de esta bombilla verde-roja PERFECTA-MALA, cercamos todo este jardín. Pero la práctica muestra que este indicador es muy importante y su ausencia y malentendido del estado actual puede arruinar enormemente la vida de un usuario común de un servicio de transmisión de video a través de WebRTC.
Referencias
WCS 5.2: un servidor de medios para desarrollar aplicaciones de video web y móviles
Documentación de control de calidad del canal WebRTC para publicación y reproducción
REMB - gestión del bitrate del lado del servidor
NACK - control de paquetes perdidos desde el lado del servidor