Transmitiendo en vivo desde un navegador...con otro navegador

Pero hoy no estamos hablando solo de transmitir en vivo desde el navegador, estamos hablando de transmitir en vivo desde el navegador a través de otro navegador. Esto también probablemente no sea una buena idea para la mayoría de los casos de uso, pero cuando necesitas este tipo de cosas, puede ser un buen camino a seguir. Ya cubrimos algo similar, o otra forma de hacer esto, en la React Summit. Así que vamos a recapitular rápidamente algunos de estos conceptos de alto nivel, solo para estar en la misma página. Pero si quieres más información, también puedes ver esa charla. Puedes encontrarla en YouTube.

Un error común es pensar que la transmisión en vivo es lo mismo que el chat en vivo. En el chat en vivo, tienes dos navegadores que pueden comunicarse, o varios navegadores, que pueden comunicarse directamente entre sí, con una latencia inferior a 500 milisegundos para que puedan hablar de forma sincrónica. En cambio, la transmisión en vivo es de uno a muchos. Tienes una entrada de transmisión para muchos espectadores, y eso puede ser de 50 a un millón de espectadores. La latencia puede ser de 10 segundos o más, está bien, porque no hay realmente una expectativa de poder comunicarse de vuelta con ese transmisor. Debido a esas limitaciones, la misma tecnología no funciona muy bien para ambos casos. Para un chat en vivo, generalmente se utiliza tecnología de navegador como WebRTC o implementaciones propietarias que permiten comunicarse directamente entre los transmisores para tener la menor latencia posible. En cambio, la transmisión en vivo utiliza tecnologías como RTMP y HLS. RTMP es una implementación antigua de Flash que se ha convertido en el estándar de facto para poder ingresar contenido en vivo directamente en un servidor, que luego transcodificará ese contenido y lo transmitirá a través de HLS. No entraremos en los detalles de HLS, pero para nuestros propósitos, nos permite descargar video a través de solicitudes GET en el navegador, y puedes escalarlo como cualquier otra transferencia de archivos, lo cual es muy bueno.

Ok, entonces vamos a tomar WebRTC y convertirlo en RTMP en el navegador, es probablemente lo que estás pensando. Desafortunadamente, no, no podemos llegar lo suficientemente bajo en la pila de red en un navegador para poder hacerlo, así que incluso en nuestro mundo moderno actual de WASM y todas estas otras cosas buenas, simplemente no podemos llegar allí. Pero hablemos de las tecnologías a las que podemos acceder. Así que todo lo que estamos hablando aquí implica un servidor de alguna manera, pero la primera forma es tomar WebRTC y utilizar una implementación de WebRTC en el lado del servidor. Si me hubieras preguntado hace un año, habría dicho, Esto es una locura, ha mejorado mucho. Proyectos como Pyon han avanzado mucho. Es una implementación de hace un año. Así que esto ya no es tan loco, pero aún no es, ciertamente no es la forma más fácil de hacerlo. Y si quieres hacer algo interesante con el video en el lado del servidor, a través de tecnologías del lado del cliente, esto te dejaría un poco en la estacada.

Entonces, para solucionar ese último problema, ¿qué tal si simplemente tomamos WebRTC y lo ejecutamos en un servidor a través de Chrome? Se puede hacer, pero el problema es que ahora estás ejecutando Chrome. O podemos utilizar GetUserMedia, que es solo una parte de las API de WebRTC que te permiten obtener el micrófono y la cámara. Transmitiremos eso a un servidor a través de WebSockets y luego lo codificaremos en RTMP.

Entonces, es posible que estés pensando, ¿cómo funciona eso? Volvamos a este tema de Chrome sin cabeza. Si quieres más información sobre eso, puedes consultar la otra charla que mencioné. O puedes ver la otra charla que mencioné. Así que WebRTC a un WebRTC del lado del servidor a través de Chrome sin cabeza. Bastante interesante. Puedes tener un chat uno a uno, pocos a pocos. Haz que Chrome sin cabeza se una a ese chat y transmita eso a través de RTMP. Muy interesante. Quieres ocultar ese Chrome en el cliente de los otros participantes del chat, pero ese Chrome puede diseñar la interfaz del chat como quiera, agregar superposiciones, cualquier cosa, justo allí.

Entonces, ¿qué hay de estos inconvenientes? Debes ejecutar un Chrome por cada flujo de entrada o salida. Por lo tanto, tienes toda la orquestación que conlleva eso. Si usas Chrome como tu navegador normal, es posible que notes que consume muchos recursos. Eso también se aplica en el servidor. El problema más grande, sin embargo, es que no es el camino más común. Muchas personas lo están haciendo, simplemente no lo están mencionando. La excepción son proyectos de código abierto como Jitsi, que si no estás familiarizado, es como un competidor de Zoom de código abierto. Así es como hacen transmisiones de uno a muchos o de pocos a muchos.

Entonces, hay algunas formas de hacer esto, cada una con sus ventajas y desventajas. Una es utilizar el enfoque estilo getUserMedia y luego transmitir eso a un servidor a través de WebSockets. Es posible que estés pensando, espera, ¿por qué estamos hablando de esto de nuevo? En realidad no es getUserMedia. Ahora vamos a utilizar Chrome.tabCapture, pero utiliza una API muy similar en el fondo. Son las mismas características internas que la API MediaRecorder, que es lo que usaríamos en esa implementación. Aquí tomamos WebRTC, el mismo proceso en el que lo tenemos en el navegador, que se une, llama a la API TabCapture, transmite eso a través de WebSocket a un servidor que lo codifica en RTP y continúa con el resto del flujo de trabajo. Esos pueden estar en el mismo servidor, pero esa es la idea general. Las ventajas son que realmente puedes ejecutar Chrome en modo sin cabeza, lo que significa que obtienes un acceso multiinquilino mucho más fácil, obtienes todas estas funciones del navegador, podemos utilizar el flujo de trabajo WebSocket sofisticado. La desventaja es que aún utiliza la API MediaRecorder, que es un desastre.

Si no hay cambios en la pestaña, no enviará ningún fotograma, lo que puede hacer que los codificadores se bloqueen, y es la API MediaRecorder, el proceso de codificación de video es realmente ineficiente, por lo que puede utilizar muchos recursos, incluso más que Chrome en sí. Entonces, esta es probablemente la forma más común en que se hace esto en la práctica, sorprendentemente. Sin embargo, creemos que hay una mejor manera.

¿Qué tal si simplemente tomamos WebRTC, tenemos una instancia completa de Chrome que esté realmente allí y luego transmitimos eso a través de RTMP? Aquí hay un script de alto nivel. Podemos revisarlo, pero el flujo de trabajo se ve algo así. Inicias tu servidor. Esto te dará los archivos estáticos que deseas servir. Te das una pantalla con la que trabajar, en realidad en el servidor a través de XPFB. Capturas esa pantalla con FFmpeg y luego comienzas a transmitirla en algún lugar, y luego abres Chrome en una página con tu transmisión, y luego lo que hagas a partir de ahí depende de tu imaginación. Quieres abrir Chrome en modo de pantalla completa, pero eso es todo.

Las ventajas son que no hay API de MediaRecorder. Es más confiable para transmitir porque estás utilizando FFmpeg, que está diseñado y construido para esto. Es una herramienta mucho mejor para este caso de uso. La desventaja es que necesitas un contenedor Docker completo o una instancia completa para cada transmisión. Pero una vez que tengas esto funcionando, puedes hacer lo que quieras con la transmisión antes de enviarla, lo cual es increíble. También está la composición y todo eso. Entonces, si deseas obtener más información sobre el proceso de hacer esto, consulta la charla de Nick en All Things RTC, la demostración de transmisión / difusión de multiplexación de cromo si deseas ver la fuente. De lo contrario, muchas gracias a todos. Aprecio mucho su tiempo. Pregúntame si tienes alguna pregunta. [♪ música ♪]