Publica y juega
Existen dos funciones principales de la operación WebRTC en el lado del servidor en el campo de 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 reproducción, la transmisión se mueve en la dirección opuesta, desde el servidor al navegador, se decodifica y reproduce en el elemento HTML5 <video> del navegador en la pantalla del dispositivo.
UDP y TCP
El video puede moverse a través de dos protocolos de transporte: TCP o UDP. En el caso de UDP, las retroalimentaciones NACK RTCP funcionan activamente, llevando la información sobre los paquetes perdidos, debido a lo cual es una tarea bastante simple detectar el deterioro del canal UDP, se reduce a contar el NACK (ACK negativo) para determinar La calidad. Cuantas más retroalimentaciones NACK y PLI (Indicador de pérdida de imagen) haya, más pérdidas reales habrá y menor será la calidad del canal.
TCP sin NACK
En este artículo, nos centraremos más en el protocolo TCP. Cuando WebRTC se utiliza a través de TCP, las retroalimentaciones NACK RTCP no se envían, e incluso si se envían, no reflejan la imagen real de las pérdidas, y no parece posible determinar la calidad del canal por las retroalimentaciones. Como se conoce comúnmente, TCP es un protocolo de transporte con entrega garantizada. Por esta razón, en caso de que la calidad del canal se deteriore, el resto de los paquetes que hay en la red se enviarán al nivel del protocolo de transporte. Tarde o temprano se entregarán, pero no se generará un NACK para esas pérdidas porque, de hecho, no hubo pérdidas. Como resultado, los paquetes llegarán a su destino con retraso. Los paquetes retrasados simplemente no se agruparán en cuadros de video y serán desechados por el desempaquetador, como resultado de lo cual el usuario verá una imagen como esta, llena de artefactos:
Los comentarios mostrarán que todo está bien, pero la imagen contendrá artefactos. A continuación puede ver capturas de pantalla del tráfico de Wireshark que ilustran el comportamiento de la transmisión que se publica en canales TCP y UDP comprimidos, así como capturas de pantalla de las estadísticas de Google Chrome. En las capturas de pantalla, puede ver que en el caso de TCP, la métrica NACK no crece a diferencia del UDP, a pesar de que el estado del canal es muy malo.
TCP
UDP
¿Por qué transmitir a través de TCP si hay UDP?
Esta es una pregunta razonable para hacer. La respuesta es, para empujar grandes resoluciones a través del canal. Por ejemplo, en el caso de la transmisión de realidad virtual (VR), las resoluciones pueden comenzar desde 4k. No parece posible empujar un flujo con tal resolución y con una tasa de bits de aproximadamente 10 Mbps en un canal regular sin pérdidas, el servidor escupe los paquetes UDP y comienzan a perderse en la red en grupos, luego el resto de ellos comienza a ser enviado, y así sucesivamente. Grandes cantidades de paquetes de video descartados corrompen el video, y el resultado neto es que la calidad se vuelve muy pobre. Esta es la razón por la cual WebRTC sobre TCP se utiliza para entregar el video en redes de propósito general y con altas resoluciones, como Full HD y 4k, para descartar pérdidas de paquetes de red a expensas de un ligero aumento en la latencia de la comunicación.
RTT para determinar la calidad del canal
Por lo tanto, no hay una métrica que le diga con certeza que el canal está en muy mal estado. Algunos desarrolladores intentan confiar en la métrica RTT, pero está lejos de ser capaz de funcionar en todos los navegadores, y no proporciona resultados precisos.
A continuación puede encontrar una ilustración de la dependencia de la calidad del canal en RTT de acuerdo con el proyecto callstat
Solución basada en REMB
Hemos decidido adoptar un enfoque ligeramente diferente a este problema. Existe el REMB trabajando en el lado del servidor , que calcula la tasa de bits entrante para todas las secuencias entrantes, calcula su desviación de la media y sugiere que el navegador reduzca la tasa de bits en el caso de una dispersión significativa, enviando comandos REMB especializados a través del RTCP protocolo 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 entrante. De esta manera, el mecanismo de cálculo de velocidad de bits ya se ha implementado en el lado del servidor. El promedio y la determinación de la dispersión se han realizado a través del filtro Kalman. Esto permite obtener la tasa de bits actual en cualquier momento con gran precisión y filtrar cualquier desviación significativa.
El lector seguramente tendrá esta pregunta: "¿Cómo me ayudará a saber la tasa de bits que el servidor puede ver para la transmisión que ingresa?" Esto solo le permitirá comprender que hay video entrando en el servidor con una tasa de bits del valor de los cuales fue posible determinar. Para evaluar la calidad del canal, se requerirá un componente más.
La tasa de bits próxima y por qué es importante
Las estadísticas para la transmisión del flujo de WebRTC muestran con qué tasa de bits sale el flujo de video del navegador. Como dice una vieja broma, un administrador del sitio dice que al revisar su rifle de asalto, “De mi lado, las balas han salido volando. Los problemas están de su lado ... ”La idea de verificar la calidad del canal implica comparar dos tasas de bits: 1) la tasa de bits enviada por el navegador, 2) la tasa de bits realmente recibida por el servidor.
El administrador del sitio dispara las balas y calcula la velocidad a la que vuelan a su lado. El servidor calcula la velocidad a la que se reciben en su lado. Hay un participante más de este evento, TCP, este es un superhéroe que se encuentra en el medio entre el administrador y el servidor y puede detener las balas al azar. Por ejemplo, puede detener 10 balas aleatorias de 100 durante 2 segundos y luego dejarlas volar nuevamente. Esa es la matriz que vemos aquí.
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 obtenemos una versión suavizada de la tasa de bits del navegador del cliente al final del proceso. Ahora tenemos prácticamente 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 nos dice cómo el servidor ve ese tráfico y con qué tasa de bits se recibe. Es obvio que si la tasa de bits del cliente sigue siendo alta y la tasa de bits del servidor comienza a reducirse en relación con la tasa de bits del cliente, significa que no todas las viñetas han "alcanzado el objetivo", y el servidor en realidad no puede ver una parte del tráfico que le fue enviado Sobre esta base, podemos concluir que algo está mal con el canal y es hora de cambiar el color del indicador a rojo.
Y hay mas
Los gráficos se correlacionan pero están ligeramente desplazados en el tiempo en relación entre sí. Para una correlación completa, es necesario hacer coincidir los gráficos en el tiempo para comparar la tasa de bits del cliente y el servidor en el mismo punto de tiempo con los datos históricos. La desincronización se ve aproximadamente así:
Y así es como se ve un gráfico sincronizado en el tiempo.
Probémoslo
Nos queda un poco por hacer, solo tenemos que probarlo. Publiquemos una secuencia de video, ábrala y mire el gráfico de las tasas de bits publicadas: en el lado del navegador y en el lado del servidor. Los gráficos demuestran prácticamente una combinación perfecta. Y este es el nombre del indicador, PERFECTO.
Entonces, comencemos a corromper el canal. Para hacerlo, podemos utilizar las siguientes herramientas gratuitas: winShaper para Windows o Network Link Conditioner para MacOS. Permiten comprimir el canal al valor preestablecido. Por ejemplo, si sabemos que un flujo de 640x480 puede alcanzar una velocidad de 1 Mbps, comprimámoslo a 300 kbs. Al hacerlo, no debemos olvidar que estamos trabajando con TCP. Verifiquemos el resultado de nuestra prueba: hay una correlación inversa en los gráficos y el indicador se desliza a MALO. De hecho, el navegador continúa enviando datos e incluso está aumentando la tasa de bits al intentar empujar una nueva porción de tráfico en la red. Estos datos se acumulan en la red en forma de retransmisiones y no llegan al servidor, como resultado, el servidor muestra una imagen inversa y dice que la tasa de bits que puede ver se ha reducido. De hecho, es malo.
Hemos realizado bastantes pruebas que muestran el correcto funcionamiento del indicador . Como resultado de eso, tenemos una función que permite informar de manera confiable y rápida al usuario sobre cualquier problema con el canal, tanto para la publicación como para la reproducción de transmisiones (trabajando según el mismo principio). Sí, todo este alboroto fue por esta lámpara verde y roja, PERFECT-BAD. Pero la práctica muestra que este indicador es muy importante y su ausencia, junto con la falta de comprensión del estado actual, puede crear grandes problemas para un usuario común de un servicio de transmisión de video WebRTC.
Enlaces
WCS 5.2 es un servidor de transmisión de medios para el desarrollo de aplicaciones web y móviles
Control de calidad del canal de editor y reproductor
REMB : tasa de bits máxima estimada del receptor utilizada para el control del ancho de banda
NACK : acuse de recibo negativo utilizado para el control de pérdida de paquetes y retransmisiones