Implementación de WebRTC en un servidor de medios: práctica y política

1. Transmisión en tiempo real a los navegadores: no hay solución. O hay

Desde hace unos 20 años, el ancho de banda de red y las capacidades informáticas de las computadoras han permitido la compresión y transmisión de sonido y video a través del protocolo IP en modo casi en tiempo real. Durante este tiempo, organizaciones centrales de estandarización como el W3C e IETF, así como muchas compañías grandes y pequeñas, han desarrollado cientos de estándares y protocolos para comprimir, empaquetar, reenviar, sincronizar y reproducir eficientemente contenido de audio y video en computadoras y dispositivos móviles. Se prestó especial atención a la captura, compresión y transmisión de video en tiempo real a través de IP, porque, en primer lugar, IP es la más barata y accesible en todos los niveles, y en segundo lugar, las tecnologías de videoconferencia y videovigilancia son vitales y tienen una gran demanda.

Parece que han pasado tantos años y se ha trabajado tanto. ¿Qué logros maravillosos en esta área podemos observar después de 20 años? Quitemos la tapa de la caja (por supuesto, esta no es la caja de Pandora y no la "lata de gusanos") y veamos qué maravillosas tecnologías y capacidades han estado disponibles después de muchos años de trabajo de decenas de miles de ingenieros de software con talento. Un programador de 1998, que envió el sonido por primera vez a través de la red, un médico que quiere una solución de telemedicina simple, barata y confiable, un maestro que necesita llevar a cabo una lección remota: ahora abren esta tapa, llenos de brillantes esperanzas, y ¿qué ven? En una sartén ofensiva llena de marketing alucinante, capitalismo cínico e intentos desesperados de los entusiastas para mejorar las cosas, flotan todo tipo de códecs, protocolos, formatos y aplicaciones.Esto es lo que la sopa de TI "comunitaria" ofrece al consumidor en tiempo real. Detente a ti mismo que huele menos, prueba, prueba, compra. No existe una solución simple y efectiva. A diferencia de la transmisión, que no requiere tiempo real: todavía durante 5 años ha habido un estándar HLS que funciona en cualquier navegador y dispositivo donde el proveedor de soluciones simplemente puede instalar el segmentador HLS en su servidor y dormir tranquilo.

Aquí está RTSP: muchas consolas y equipos profesionales lo juegan, pero los navegadores no funcionan. Aquí está RTMP: Safari no quiere jugarlo en iOS y no todos los androides lo juegan. Chrome lo prohíbe como no confiable. Aquí está MPEG2-TS: los navegadores tampoco lo reproducen. Extensiones de origen de medios HTML5 (MSE): bueno para segmentos de video de 5 a 10 segundos de duración (es decir, para HLS / Dash), pero para segmentos cortos de menos de un segundo, no siempre estable, funciona de manera diferente en diferentes navegadores y nuevamente no es compatible con iOS.

¿Cómo, uno se pregunta, el jardín de niños envía videos desde cámaras instaladas en grupos a los padres que desean abrir el navegador en cualquier momento en cualquier dispositivo y sin instalar ningún complemento para ver a sus hijos en tiempo real? ¿Por qué todos los jardines de infancia no ofrecen tales servicios? Sí, porque proporcionar ese servicio es muy costoso. Necesitamos desarrollar aplicaciones para dispositivos móviles, donde se reproducirá el video, porque los navegadores no se reproducen. Necesito mucho mas

Definamos el concepto de "cerca del tiempo real". Esto es menos de 5 segundos de retraso para video vigilancia y menos de 1 segundo para videoconferencia. El retraso promedio del protocolo HLS es de 20-30 segundos. Tal vez sea de alguna manera adecuado para jardines de infantes, pero para video vigilancia de seguridad, videoconferencia y seminarios web, se necesita otra tecnología.

Entonces, hasta ahora, más precisamente hasta el verano de 2017, no había un estándar o protocolo único para transmitir audio-video a cualquier navegador en cualquier dispositivo en tiempo real. Las razones de esta situación, las consideraremos en este artículo más adelante. No son de naturaleza técnica, estas razones. Mientras tanto, veamos qué sucedió en el verano de 2017, que al menos, pero que aún proporciona una tecnología que nos permite resolver los problemas anteriores. Esta tecnología es WebRTC, se ha escrito mucho sobre ella tanto en este recurso como en la red en general. Ya no se puede llamar completamente nuevo, y al momento de escribir este artículo, W3C considera WebRTC 1.0 como un proyecto completado. No hablaremos aquí sobre qué es WebRTC; Si el lector no está familiarizado con esta tecnología, le sugerimos que realice una búsqueda en el centro o en Google y se familiarice,para qué se utiliza y cómo funciona en términos generales. Aquí solo decimos que esta tecnología se desarrolló para la comunicación entre pares en los navegadores, con la que puede implementar video chat y aplicaciones de voz sin ningún servidor: el navegador se comunica directamente con el navegador. WebRTC es compatible con todos los navegadores en todos los dispositivos, y en el verano de 2017, Apple finalmente se acercó a nosotros y lo agregó a su Safari en iOS. Fue este evento el que convirtió a WebRTC en la tecnología más universal y generalmente aceptada para la transmisión en tiempo real a los navegadores, desde la puesta de sol de RTMP, que comenzó en 2015.WebRTC es compatible con todos los navegadores en todos los dispositivos, y en el verano de 2017, Apple finalmente se acercó a nosotros y lo agregó a su Safari en iOS. Fue este evento el que convirtió a WebRTC en la tecnología más universal y generalmente aceptada para la transmisión en tiempo real a los navegadores, desde la puesta de sol de RTMP, que comenzó en 2015.WebRTC es compatible con todos los navegadores en todos los dispositivos, y en el verano de 2017, Apple finalmente se acercó a nosotros y lo agregó a su Safari en iOS. Fue este evento el que convirtió a WebRTC en la tecnología más universal y generalmente aceptada para la transmisión en tiempo real a los navegadores, desde la puesta de sol de RTMP, que comenzó en 2015.

Sin embargo, ¿qué tiene que ver con la transmisión a los navegadores desde las cámaras? Pero el hecho es que WebRTC es muy flexible en su funcionalidad y le permite enviar audio-video solo a uno de los dos participantes (pares), y solo acepta al otro. Por lo tanto, la idea nació para adaptar WebRTC en servidores de medios. El servidor de medios puede recibir video de la cámara, establecer comunicación con el navegador y aceptar que solo se enviará y el navegador recibirá. Por lo tanto, el servidor de medios puede enviar video simultáneamente desde la cámara a muchos navegadores / visores. Por el contrario, un servidor de medios puede recibir un flujo de un navegador y reenviarlo a, por ejemplo, muchos otros navegadores, implementando la función deseada de "uno a muchos".

Entonces, ¿finalmente todo se formó? Akuna Matata y el jardín de infantes podrán instalar dicho servidor de medios en algún lugar del alojamiento o en AWS, enviar una transmisión desde cada cámara allí, y desde allí ya se distribuirá a los navegadores de los padres, todo con un retraso de no más de un segundo. En general, sí, la vida está mejorando. Pero hay problemas. Y estos problemas están relacionados con el hecho de que WebRTC es, por así decirlo, exagerado para tales tareas; no fue diseñado para ellas y no es muy adecuado para ellas. Los problemas, además de la compatibilidad del códec, existen principalmente con la escalabilidad de dicho servidor de medios. Es decir, al mismo tiempo, se puede atender a 100 padres desde una computadora servidor, y 500 ya es difícil. Aunque la red lo permite. Y observe la carga del procesador en el servidor con 100 conexiones: ya está cerca del 90%. ¿Cómo es eso? Después de todo, solo envíe un video de sonido.

Con la misma transmisión, si se envía a través del protocolo RTMP al reproductor Flash, puede admitir fácilmente 2000 conexiones simultáneas desde un servidor. ¿WebRTC es solo 100?
¿Por qué? Hay dos razones: en primer lugar, el protocolo WebRTC en sí es mucho más costoso desde el punto de vista computacional: allí, por ejemplo, el cifrado de todos los datos es obligatorio y requiere mucho tiempo de procesador. Y la segunda razón, que discutiremos con más detalle, es la implementación extremadamente ineficiente del protocolo por parte de su creador, Google, que proporciona el código fuente de c ++ para esta implementación para la adaptación en servidores, puertas de enlace y otras aplicaciones que desean admitir WebRTC: webrtc.org/native-code

2 Compatibilidad con la API nativa de WebRTC de Google y el servidor de medios

Recuerde que WebRTC se creó para transferir audio-video del navegador al navegador y que no había tareas para soportar muchas conexiones simultáneas. Por lo tanto, y no solo por lo tanto, la implementación de WebRTC en el navegador no se preocupó por el principio básico del diseño y la arquitectura de los sistemas técnicos: elegancia (nada más), eficiencia, alto rendimiento. Se hizo hincapié en la fiabilidad y la capacidad de gestión con errores y situaciones extremas en la red: pérdida de paquetes, conexiones, etc. Lo cual, por supuesto, es bueno. Sin embargo, después de un examen más detallado, resulta que esto es lo único bueno en la implementación de Google de WebRTC.

Veamos los puntos principales por los cuales el uso de la implementación de Google de WebRTC para servidores de medios es extremadamente problemático.

2.a El código es 10 veces más de lo que debería ser y es extremadamente ineficiente.

Este es un número comprobado. Para comenzar, descargue aproximadamente 5 gigabytes de código, de los cuales solo 500 megabytes son relevantes para WebRTC. Luego intentas deshacerte del código innecesario. Después de todo, para las necesidades de un servidor de medios no necesita codificación / decodificación; el servidor solo debe recibir contenido y reenviarlo a todos. Cuando eliminaste todo lo innecesario que pudiste (y pudiste eliminar mucho menos de lo que quisieras), aún tienes 100 megabytes de código. Esta es una figura monstruosa. Es ella quien es 10 veces más grande de lo que debería ser.

Por cierto, en este punto, muchos dirán: ¿cómo no es necesaria la codificación / decodificación? ¿Qué pasa con la transcodificación de AAC a Opus y viceversa? ¿Qué pasa con la transcodificación VP9-> H264? Si va a realizar dicha transcodificación en el servidor, tampoco podrá extraer 5 conexiones simultáneas. Si es realmente necesario, la transcodificación no debe ser realizada por un servidor de medios, sino por otro programa.

Pero volvamos al problema del código hinchado e ilustrelo. ¿Cuál crees que es la profundidad de la pila de llamadas de función al enviar un cuadro de video ya comprimido? ¿Una llamada a winsock (en Windows) de la función enviar o enviar a (WSASend / WSASendTo)? No, por supuesto, se necesita hacer más trabajo. En el caso de WebRTC, debe empaquetar el marco sobre el protocolo RTP y cifrarlo, lo que en total nos da el protocolo SRTP. Es necesario guardar la trama en caso de pérdida de paquetes para enviarla nuevamente más tarde. ¿Cuántos objetos y subprocesos de C ++ deberían estar involucrados en esto?

Así es como lo hace WebRTC 61:



como puede ver en esta captura de pantalla, desde el momento en que alimentamos el marco comprimido a WebRTC hasta la cola del objeto Paced_Sender, la profundidad de la pila de llamadas es 8 (!) ¡Y 7 objetos están involucrados!

Luego, un subproceso separado (subproceso) PacedSender extrae nuestro marco de la cola y lo envía más allá para su procesamiento:



y finalmente, llegamos al paso 4, donde el marco ya encriptado y empaquetado con RTP se basa en la cola que se enviará a la red, que participa en otro subproceso. En este punto, la profundidad de la pila de llamadas (en el subproceso PacedSender) es 7, y hay 3 nuevos objetos más involucrados. El subproceso ocupado que se envía llamará al WSASend / WSASendTo final también después de 3-4 llamadas a funciones anidadas e involucrará 3-4 objetos nuevos más.

Entonces, vimos 3 hilos, cada uno de los cuales hace un gran trabajo. Todos los que programaron tales sistemas tienen una idea de cómo se hacen esas cosas y qué es lo que realmente hay que hacer. Según nuestras estimaciones, al menos el 90% de los objetos y el código aquí son superfluos y violan los principios de la programación orientada a objetos.

2.b se asignan 4-5 hilos por conexión

Sin duda, con la cantidad de hilos en este ejemplo, todo está en orden. Es necesario proporcionar un procesamiento asincrónico, no bloquear a nadie, y se necesitan los 3 hilos. En general, un PeerConnection WebRTC asigna 4-5 hilos. Bueno, sería posible mantenerse dentro de 3. Pero no menos. ¡El problema es que esto es para cada conexión! En el servidor, por ejemplo, puede guardar 3 hilos, pero servirán todas las conexiones juntas, y no asignarán 3 hilos a cada conexión. El grupo de subprocesos es una solución de servidor indudable para tales tareas.

2.c Sockets asíncronos que funcionan a través de mensajes de Windows

El código Google WebRTC en Windows usa sockets asíncronos a través de WSAAsyncSelect. Los programadores de servidores saben que usar la función de selección en el servidor es un suicidio, y WSAAsyncSelect, aunque mejora la situación, pero no en un orden de magnitud. Si desea admitir cientos y miles de conexiones, hay una mejor solución en Windows que los sockets asíncronos. Los sockets superpuestos y los puertos de finalización de E / S deben estar habilitados, enviando notificaciones al grupo de subprocesos que está haciendo el trabajo.

2.d Conclusión

Por lo tanto, podemos concluir: es posible aplicar el código WebRTC de Google, sin cambios importantes, a un servidor de medios, pero el servidor no podrá extraer cientos de conexiones simultáneas. Puede haber dos soluciones:

Hacer cambios serios en el código de Google es, sin exagerar, casi imposible: después de todo, todos estos objetos están muy unidos entre sí, no encapsulan la funcionalidad, no son bloques independientes que realizan cierto trabajo, como debería ser. Involucrarlos sin cambios en otros escenarios es imposible.

No use el código de Google en absoluto, pero implemente todo usted mismo usando bibliotecas abiertas como libsrtp y similares. Quizás esta sea la forma correcta, pero además del hecho de que también es un trabajo enorme, puede encontrar el hecho de que su implementación no será totalmente compatible con Google y, en consecuencia, no funcionará o no funcionará en todos los casos, para por ejemplo, con cromo, que no se puede tolerar. Luego puedes discutir con los chicos de Google durante mucho tiempo, demostrar que has cumplido con el estándar, pero que no lo han hecho, y tendrás razón mil veces. Pero ellos, en el mejor de los casos, dirán: "lo arreglaremos, quizás de alguna manera más tarde". Tienes que ajustarte a Chrome ahora mismo. Y el punto.

3. ¿Por qué está todo tan triste?

Esta situación con la transmisión a los navegadores en tiempo real es una ilustración muy característica de lo que a veces lleva la "tecnología impulsada por los negocios". La tecnología motivada por los negocios se está desarrollando en la dirección en que es necesaria para los negocios y en la medida en que sea agradable para este negocio. Gracias al enfoque comercial, ahora tenemos computadoras personales y teléfonos móviles: ningún gobierno o ministerio de planificación central podría estar tan interesado en desarrollar e introducir todas estas tecnologías de consumo a las masas. Las empresas privadas, motivadas por el beneficio personal de sus propietarios, lo hicieron tan pronto como surgió una oportunidad técnica.

Desde hace tiempo se sabe, se comprende y se acepta que los bienes y servicios de consumo no esenciales, aquellos sin los cuales se puede vivir en paz, están mejor desarrollados por empresas privadas, entonces las cosas que son vitalmente necesarias para una persona (energía, carreteras, policía y educación escolar) deben desarrollarse de manera centralizada. instituciones controladas por el estado.

Nosotros, los niños de la Unión Soviética y la mentalidad "hagamos una tecnología técnicamente correcta y fuerte para que la gente pueda usarla y todo esté bien", podríamos decir, por supuesto, que en un sistema soviético planificado (si el gobierno decidiera de repente), la tecnología de transmisión La IP en tiempo real podría desarrollarse e implementarse en un año y sería un orden de magnitud mejor que lo que el negocio ha ganado ahora en 20 años. Pero también entendemos que entonces no se desarrollaría, se volvería obsoleto y, al final, a la larga, aún perdería parte de la tecnología occidental comercial.

Por lo tanto, dado que es bastante posible llevarse bien sin el streaming shimming, se deja a merced de las empresas privadas. Lo cual lo desarrolla en sus propios intereses, y no en interés del consumidor. ¿Cómo no es en interés del consumidor? Pero, ¿qué pasa con la oferta y la demanda? ¿Qué necesita el consumidor y luego ofrecerá el negocio? Pero no ofrece. Todos los consumidores están gritando: Google admite el audio AAC en WebRTC, pero Google nunca lo hará, aunque solo escupe hacerlo. A Apple no le importa en absoluto y no implementa nada de las tecnologías de transmisión tan necesarias en sus dispositivos. ¿Por qué? Sí, porque no siempre el negocio hace lo que el consumidor necesita. No hace esto cuando es monopolista y no teme que el consumidor pierda. Entonces el negocio está ocupado fortaleciendo su posición. Así que Google compró en los últimos años un grupo de fabricantes de códecs de sonido.Y ahora empuja el audio Opus y obliga al mundo entero a transcodificar AAC-> Opus para que coincida con WebRTC, ya que toda la tecnología ha cambiado durante mucho tiempo al audio AAC. Google justifica esto supuestamente con el hecho de que AAC es una tecnología paga, y Opus es gratis. Pero, de hecho, esto se hace para establecer su tecnología como estándar. Como Apple hizo una vez con su miserable HLS, que nos hizo amar, o como Adobe hizo con su irresponsable protocolo RTMP incluso antes. Los artilugios y los navegadores siguen siendo cosas técnicamente bastante difíciles de desarrollar, de aquí surgen los monopolistas, de aquí, como dicen, las cosas están allí. Y el W3C y el IETF están patrocinados por los mismos monopolistas, por lo que la mentalidad de "hagamos una tecnología técnicamente correcta y sólida para que la gente pueda usarla y todo esté bien" no está ahí y nunca lo estará.Pero debería haber sido.

¿Cuál es la salida de esta situación? Aparentemente, solo esperar la tecnología “correcta” impulsada por los negocios, el resultado de la competencia y todo tipo de otras cosas grandiosas, finalmente, surgirá algo democrático, adecuado para un simple médico rural, para que pueda proporcionar servicios de telemedicina con su Internet normal. De hecho, es necesario hacer una enmienda, no para un simple médico rural, sino para aquellos que pueden pagar mucho dinero, el negocio ha estado ofreciendo soluciones de transmisión en tiempo real. Bueno, confiable, que requiere redes dedicadas y equipos especiales. En muchos casos, y no funciona en el protocolo IP. Lo cual, y esta es otra razón para una situación tan triste, no se creó en tiempo real y no siempre lo garantiza. No siempre, pero no en situaciones vitales, es bastante adecuado en este momento.Entonces intentemos WebRTC. Hasta ahora, de todos los males, es el más pequeño y más democrático. Por lo cual, después de todo, debes agradecer a Google.

4. Un poco sobre los servidores de medios que implementan WebRTC

Wowza, Flashphoner, Kurento, Flussonic, Red5 Pro, Unreal Media Server: estos son algunos de los servidores de medios que admiten WebRTC. Proporcionan la publicación de video desde los navegadores al servidor y transmiten video a los navegadores a través de WebRTC desde el servidor.

Los problemas descritos en este artículo, de diferentes maneras y con diferentes grados de éxito, se resuelven en estos productos de software. Algunos de ellos, por ejemplo, Kurento y Wowza, realizan la transcodificación de audio y video directamente en el servidor, otros, por ejemplo, Unreal Media Server, no se transcodifican, pero proporcionan otros programas para esto. Algunos servidores, como Wowza y Unreal Media Server, admiten la transmisión en todas las conexiones a través de un puerto TCP y UDP central, porque WebRTC asigna un puerto separado para cada conexión, por lo que el proveedor tiene que abrir muchos puertos en el firewall, lo que crea problemas de seguridad.

Hay muchos puntos y sutilezas implementados en todos estos servidores de diferentes maneras. Cuánto les conviene al consumidor, juzguen, queridos usuarios.