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

Rate this content
Bookmark

Existen otras formas de transmitir video en vivo desde un navegador a un punto final RTMP, pero ¿qué pasa si queremos interactuar con ese flujo primero? Y no solo interactuar escribiendo filtros oscuros de ffmpeg, sino simplemente con buen HTML y CSS. ¡Hagámoslo! Hablaremos sobre cómo permitir que tus transmisores vayan en vivo directamente desde su navegador utilizando Chrome sin cabeza y ffmpeg.

8 min
18 Jun, 2021

Video Summary and Transcription

Esta charla discute el chat en vivo y la transmisión en vivo utilizando WebRTC y RTMP. Explora cómo ejecutar WebRTC en un servidor a través de Chrome y enfoques alternativos como el uso de GetUserMedia y la API Chrome.tabCapture. También se discute el uso de una instancia completa de Chrome para la transmisión en vivo de WebRTC y RTMP, destacando los pros y los contras de este enfoque. La charla recomienda consultar la charla de Nick en All Things RTC para obtener más información.

Available in English

1. Introducción a la Transmisión en Vivo y WebRTC

Short description:

Hola a todos, mi nombre es Matthew McClure. Soy uno de los cofundadores de Mux, y nos dedicamos a la infraestructura de video en línea para desarrolladores. Hoy hablaremos sobre cómo transmitir en vivo desde el navegador a través de otro navegador. El chat en vivo y la transmisión en vivo son diferentes en términos de comunicación y tecnología. El chat en vivo utiliza WebRTC para una comunicación síncrona de baja latencia entre navegadores, mientras que la transmisión en vivo utiliza RTMP y HLS para la transmisión de uno a muchos. No podemos convertir WebRTC en RTMP en el navegador, pero podemos utilizar una implementación de WebRTC en el lado del servidor. Sin embargo, este enfoque puede no ser el más fácil o flexible para el procesamiento de video en el lado del servidor.

Soy uno de los cofundadores de Mux, y nos dedicamos a la infraestructura de video en línea para desarrolladores. Una de nuestras características es una API para transmisión en vivo, y es ahí donde recibimos muchas preguntas de los desarrolladores sobre cómo ayudar a sus clientes a transmitir en vivo. Estamos en un mundo en el que quieren construir una aplicación en el navegador, permitir que el usuario inicie sesión y transmita en vivo de inmediato sin necesidad de descargar software de terceros como OBS o algo así para poder hacerlo. Tiene total 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 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.

2. Ejecutando WebRTC en un servidor a través de Chrome

Short description:

Para solucionar el problema de ejecutar WebRTC en un servidor a través de Chrome, un enfoque alternativo es utilizar GetUserMedia para capturar el micrófono y la cámara, transmitirlo a un servidor a través de WebSockets y codificarlo en RTMP. Esto implica ejecutar un Chrome por cada flujo de entrada o salida, lo cual puede consumir muchos recursos. Sin embargo, proyectos de código abierto como Jitsi han implementado este método para transmisiones de uno a muchos o de pocos a muchos. Otro enfoque es utilizar la API Chrome.tabCapture, que tiene internamente características similares a la API MediaRecorder. Esto permite ejecutar Chrome en modo sin cabeza, lo que proporciona un acceso multiinquilino más fácil y funciones del navegador, pero aún depende de la API MediaRecorder.

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.

3. WebRTC con instancia de Chrome y transmisión RTMP

Short description:

Si no hay cambios en la pestaña, no enviará ningún fotograma, lo que puede hacer que los codificadores se bloqueen. La API MediaRecorder para codificar video es ineficiente y utiliza muchos recursos. Una mejor manera es utilizar WebRTC con una instancia completa de Chrome y transmitir a través de RTMP. El flujo de trabajo implica iniciar el servidor, capturar la pantalla con FFmpeg y transmitirla. Las ventajas son la ausencia de la API MediaRecorder y una transmisión más confiable con FFmpeg. La desventaja es la necesidad de un contenedor Docker completo o una instancia para cada transmisión. Tienes flexibilidad para manipular la transmisión antes de enviarla. Para obtener más información, consulta la charla de Nick en All Things RTC.

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 ♪]

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!
JSNation 2023JSNation 2023
25 min
Pushing the Limits of Video Encoding in Browsers With WebCodecs
High quality video encoding in browsers have traditionally been slow, low-quality and did not allow much customisation. This is because browsers never had a native way to encode videos leveraging hardware acceleration. In this talk, I’ll be going over the secrets of creating high-quality videos in-browsers efficiently with the power of WebCodecs and WebAssembly. From video containers to muxing, audio and beyond, this talk will give you everything you need to render your videos in browsers today!
React Summit Remote Edition 2021React Summit Remote Edition 2021
34 min
Creating Videos Programmatically in React
Introduction to Remotion, a new library with which we can turn React code into MP4 videos, create our motion graphics programmatically and server-side render them. I give an overview of the priciples, the philosophy and of course we are going to code a video!
React Summit 2020React Summit 2020
16 min
Getting Weird with Video Manipulation and HTML5 Canvas
In this lightning talk we will be pushing the boundaries of HTMl5 Canvas browser APIs. Join us while we do some experiments with video in the browser to see what’s truly possible. DISCLAIMER: No promises of cross-browser compatibility. Not for the faint of heart. Must be this tall to ride. Attending this lightning talk may result in serious injury or death. All participants must bring a life jacket.
React Summit Remote Edition 2020React Summit Remote Edition 2020
13 min
Going Live from your Browser without WebRTC
When developers think about broadcasting live from the browser, the immediate assumption is to use WebRTC. While WebRTC is amazing technology, server-side implementations are...lacking right now. We'll talk about a (totally hacky) way to get video from the browser via technology you're using today.
React Summit Remote Edition 2021React Summit Remote Edition 2021
7 min
Remember CSS Sprites? Let's Do That with Video!
Synchronizing multiple streams, particularly multiple live streams, and especially when the audio is critical too, can be incredibly difficult. How, then, could you build an experience where you have a few camera angles and you want a viewer to be able to seamlessly pick one? We'll walk through a hack technique that allows you to do just that without ever having to worry about synchronization.

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
138 min
Build Your Own Live Streaming Platform
Workshop
In this workshop we will go over the basics of streaming video over the internet including technologies like HLS and WebRTC. We will then build our own React app to play live streams and recordings of live streams.