Transmitiendo en Vivo desde un Navegador...con Otro Navegador

Hola a todos, mi nombre es Matthew McClure. Soy uno de los cofundadores de Mux, y hacemos infraestructura de video en línea para desarrolladores. Así que una de nuestras características es una API para transmisión en vivo, y ahí es donde recibimos un montón de preguntas de los desarrolladores sobre cómo ayudar a sus clientes a transmitir en vivo. Están en un mundo donde quieren simplemente construir una aplicación en el navegador, permitir que el usuario simplemente inicie sesión e inmediatamente transmita en vivo sin necesidad de descargar software de terceros como OBS o algo así para poder hacerlo. Totalmente tiene sentido.

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 probablemente también sea una mala idea para la mayoría de los casos de uso, pero cuando necesitas este tipo de cosas, esto puede ser un gran camino a seguir. Así que cubrimos algo similar, u otro camino para hacer esto en 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 podrías querer ver esa charla. Puedes encontrarla en YouTube.

Una idea errónea común es que la transmisión en vivo es lo mismo que el chat en vivo. Así que en el chat en vivo, tienes dos navegadores que pueden comunicarse, o algunos navegadores, que pueden comunicarse directamente entre sí, con menos de 500 milisegundos de latencia para que puedan hablar sincrónicamente. La transmisión en vivo, por otro lado, es de uno a muchos. Así que tienes un flujo de entrada hacia 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 realmente no hay una expectativa de poder comunicarse de vuelta con ese transmisor. Así que debido a esas limitaciones, la misma tecnología realmente no funciona muy bien para ambos. Para un chat en vivo, generalmente está impulsado por tecnologías de navegador como WebRTC o implementaciones propietarias que te permiten comunicarte directamente entre los transmisores para que tengas la menor latencia posible. La transmisión en vivo, por otro lado, está impulsada por tecnologías como RTMP y HLS. RTMP es una especie de implementación antigua de flash que se ha convertido en el estándar de facto para poder ingerir 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, te permite descargar video a través de solicitudes git en el navegador, y puedes escalarlo como lo harías con cualquier otra transferencia de archivos, lo cual es realmente agradable.

Bien, así que simplemente tomemos WebRTC y luego convirtámoslo en RTMP en el navegador, probablemente es 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 qué tecnologías podemos acceder. Así que todo lo que estamos hablando aquí, involucra un servidor de alguna manera, pero la primera forma es que podemos tomar WebRTC y luego usar una implementación de WebRTC del lado del servidor. Así que si me hubieras preguntado hace un año, habría dicho, Esto es una locura, esto ha mejorado mucho. Proyectos como Pyon han avanzado mucho. Es una implementación de hace un año. Así que esto en realidad ya no es tan loco, pero aún no, ciertamente no es la forma más fácil de lograr esto. Y si quieres poder 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 el frío.

Entonces, para solucionar eso último, ¿qué tal si simplemente tomamos WebRTC, 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 tomar GetUserMedia, que es solo algunas de las APIs de WebRTC que te permiten obtener como el micrófono y la cámara. Transmitiremos eso a un servidor a través de WebSockets, y luego lo codificaremos en RTMP.

Entonces, podrías estar pensando, ¿cómo funciona eso? Volvamos a esto de Chrome en modo headless. Si quieres más información sobre eso, puedes hablar sobre la otra charla que mencioné. O puedes ir a ver la otra charla que mencioné. Así que WebRTC a un WebRTC del lado del servidor a través de Chrome en modo headless. Bastante genial. Puedes simplemente tener un chat, uno a uno, pocos a pocos. Hacer que Chrome en modo headless se una a ese chat, transmitir eso vía RTMP. Realmente interesante. Quieres ocultar ese Chrome en el cliente de los otros participantes del chat, pero ese Chrome puede entonces diseñar la interfaz del chat como quiera, agregar superposiciones, cualquier cosa así, justo ahí.

Entonces, ¿qué pasa con estos inconvenientes? Tienes que ejecutar un Chrome por cada flujo de entrada o por cada flujo de salida. Y así tienes toda la orquestación que viene con eso. Así que si usas Chrome como tu navegador normal, podrías notar que es intensivo en recursos. Eso también se aplica en el servidor. El problema más grande, sin embargo, es que no es el camino más transitado. Mucha gente está haciendo esto. Simplemente no están hablando de ello. 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 la transmisión de uno a muchos, o de pocos a muchos.

Así que hay algunos caminos para lograr esto, que vienen con algunos compromisos. Uno es hacer este enfoque estilo getUserMedia y luego transmitir eso a un servidor de web sockets. Podrías estar pensando como, espera, ¿por qué estamos hablando de esto de nuevo? En realidad no es getUserMedia. Ahora vamos a usar el Chrome.tabCapture, pero usa una API muy similar internamente. Es el mismo interno que la API de MediaRecorder, que es lo que usaríamos en esa implementación. Así que aquí tomamos WebRTC, el mismo proceso donde lo tenemos en el navegador, que se une, llama a la API de TabCapture, transmite eso vía WebSocket a un servidor que lo codifica en RTP y va al resto del flujo de trabajo. Esos pueden estar en el mismo servidor, pero eso es más o menos el nivel alto. Los pros son que puedes ejecutar Chrome en modo headless, lo que significa que obtienes mucho más multi-inquilino, mucho más fácil acceso multi-inquilino, obtienes todas estas características del navegador, podemos usar el flujo de trabajo elegante de WebSocket. La desventaja es que todavía usa la API de MediaRecorder, que es un poco un desastre.

Si no hay cambios en la pestaña, no enviará ningún cuadro, lo que puede hacer que los codificadores se bloqueen, y es la API de MediaRecorder, ese proceso para codificar video es realmente ineficiente, por lo que puede usar muchos recursos, incluso más que el propio Chrome. Así que esta es probablemente la forma más común en que ves esto hecho en la práctica, sorprendentemente. Sin embargo, creemos que hay una mejor manera.

¿Qué pasaría si simplemente tomáramos WebRTC, tuviéramos una instancia completa de Chrome que realmente esté allí, y luego transmitiéramos eso vía RTMP? Así que, aquí hay un script de muy alto nivel. Podemos revisar esto, pero el flujo de trabajo se ve algo así. Inicias tu servidor. Esto te dará los archivos estáticos que deseas servir. Date una pantalla para trabajar, realmente en el servidor a través de XPFB. Captura esa pantalla con FFmpeg, y luego comienza a transmitirla a algún lugar, y luego abre Chrome en una página con tu transmisión en ella, y luego lo que hagas a partir de ahí depende de tu imaginación. Quieres abrir Chrome en, como, modo de pantalla completa, pero eso es todo.

Así que las ventajas son que no hay API de MediaRecorder. Es más confiable transmitir porque estás usando 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 tienes esto funcionando, puedes hacer lo que quieras con la transmisión antes de enviarla, lo cual es increíble. Además, está componiendo y todo. Así que, si quieres más información sobre, como, el proceso de hacer esto, consulta la charla de Nick de All Things RTC, muxing slash chromium broadcast demo si quieres ver la fuente. De lo contrario, muchas gracias a todos. Realmente aprecio su tiempo. Pregúntame si tienes alguna pregunta.