Realizar transmisiones en vivo desde tu navegador sin WebRTC

Entonces, empecemos. Mi nombre es Matthew McClure, soy cofundador de una empresa llamada Mux. Proporcionamos una API para la infraestructura de video en línea y una de las cosas que ofrecemos es esta solución de transmisión en vivo. Entonces, puedes crear transmisiones en vivo, te devolvemos una clave de transmisión y luego puedes enviar feeds RTMP a ella. Es genial para transmisiones en vivo, pero una pregunta muy común que recibimos es cómo puedo permitir que mis usuarios transmitan en vivo directamente desde un navegador. Por lo general, las recomendaciones actuales son usar software nativo como Open Broadcast Studio o Wirecast o algo similar. Pero las personas quieren poder mantener a las personas en sus propias aplicaciones y no enviar a otra solución para que descarguen y aprendan una nueva tecnología. Es comprensible por qué lo quieren, pero desafortunadamente no es tan fácil.

Entonces, hablemos de un truco en el que he estado trabajando y que probablemente sea una idea realmente terrible. Primero, hablemos de lo que queremos decir con transmisión en vivo. Algunos antecedentes rápidos aquí. La transmisión en vivo no es un chat en vivo. Es una idea muy común, pero estas dos cosas son bastante diferentes.

En el chat en vivo, solo tienes a dos personas, dos usuarios que hablan directamente entre sí. Pueden compartir video potencialmente incluso de igual a igual. Por lo tanto, no es necesario que pase por un servidor centralizado. Puede ir directamente de uno a otro. Esta latencia debe ser de 300 milisegundos o menos. Si la latencia llega a 500 milisegundos, se vuelve muy difícil tener esa conversación de uno a uno. Tal vez incluso puedas tener algunos pares aquí. Entonces, eso puede ser 3, 5, 10, realmente depende de cuánto ancho de banda pueda tener cada usuario, porque estás limitado por la persona que tiene menos ancho de banda para poder compartir video de ida y vuelta entre todas las personas en el chat.

La transmisión en vivo, por otro lado, es desde una fuente de cámara hacia cientos, miles, decenas de miles, cientos de miles de personas a la vez. Ahora, ya no estamos hablando de una comunicación uno a uno ya que es una persona transmitiendo a un grupo. Necesitas poder escalarlo, necesitas tener costos asequibles, pero luego esos espectadores no necesariamente necesitan recibir una respuesta en tiempo real. Por lo tanto, una latencia de 10 segundos, 15 segundos, está bien. Para cuando una persona responda en el chat, debería ser bastante receptivo. Por las mismas razones, la misma tecnología no funciona bien para ambos casos. Entonces, el chat en vivo funciona con tecnologías de navegador como WebRTC, que es un conjunto de API que se pueden utilizar para que los navegadores se comuniquen entre sí, de igual a igual, obtener los medios del navegador, todas esas cosas. La transmisión en vivo, por otro lado, funciona con tecnologías como RTMP. RTMP es un protocolo de servidor, un protocolo de comunicación para la entrega video. Solía usarse mucho para la entrega, pero ahora es estándar para obtener una transmisión en un servidor. Luego, ese servidor transcodificará eso a algo para entregar a los usuarios finales que sea un poco más económico y escalable, como HLS. HLS es un formato que básicamente toma video, lo divide en pequeños fragmentos, enumera esos fragmentos en un manifiesto y luego los reproductores pueden descargar el manifiesto y seguir descargándolo para obtener actualizaciones. Pero puede alojarse en CDNs normales, se entrega como archivos normales, es solo HTTP, por lo que es muy fácil de escalar y entender, y es económico, relativamente hablando. Bueno, probablemente estés pensando, si necesito llegar a RTMP primero, simplemente usemos WebRTC a RTMP en el navegador. Los navegadores en su mayoría dicen que no. Desafortunadamente, no puedes llegar a un nivel lo suficientemente bajo en el nivel de red para poder comunicarte a través de RTMP. ¿Entonces, qué hay de la tecnología a la que no podemos acceder? ¿Qué hay de las cosas que tenemos en nuestro conjunto de herramientas? Entonces, spoiler alert, un servidor estará involucrado de cualquier manera.

Simplemente no podrás llegar de un navegador a RTMP sin involucrar de alguna manera a un servidor. Por lo tanto, las implementaciones de WebRTC en el lado del servidor, se pueden hacer, es un poco complicado, la especificación de WebRTC es grande e intimidante. Esto ha mejorado mucho recientemente, hay proyectos como Pyon que realmente facilitan esto mucho más, pero aún es bastante intimidante.

Entonces, estás pensando en una implementación de WebRTC en el lado del servidor, pero ahora esa implementación es simplemente Chrome sin cabeza, y esto se puede hacer. En realidad, se hace muy bien, una vez que básicamente puedes tener un chat, la instancia de Chrome sin cabeza simplemente puede unirse a ese chat y grabarlo. Y lo bueno aquí es que estás utilizando tecnologías de navegador, puedes hacer superposiciones, puedes hacer lo que harías en el navegador, y luego está en la transmisión. Es realmente genial. El problema es que ahora tienes que ejecutar Chrome a gran escala para cada persona que quiera hacer una transmisión en vivo, lo que puede ser complicado.

Ok, ¿y si solo usamos una parte de esa especificación de WebRTC, obtener medios del usuario, que es el proceso de obtener el micrófono y la cámara del navegador, y luego simplemente enviaremos eso a través de WebSockets. Los WebSockets son comprensibles. Las limitaciones del lado del servidor son comunes, y son cosas con las que todos hemos trabajado, o muchos de nosotros hemos trabajado en el pasado, así que intentemos eso. Puede que estés pensando, ¿cómo funcionaría eso? Primero, solicitaríamos los medios del navegador, así que me refería a obtener medios del usuario anteriormente. Puedes establecer diferentes restricciones. Simplemente estableceremos audio y video en verdadero, pero podrías ajustarlo si quisieras. Estableceremos ese flujo, lo agregaremos a un elemento video para poder verlo, luego capturaremos ese flujo y luego pasaremos ese flujo al grabador de medios, a una instancia del grabador de medios, o crearemos una nueva instancia de la API del grabador de medios, que simplemente te permite grabar contenido desde un navegador. Y luego, ese grabador expondrá este evento data disponible, por lo que cada vez que ese evento se active, tendremos un fragmento de video, así que simplemente enviaremos ese fragmento de video a través de una conexión WebSocket . Ahora, eso cumplirá con todo el proceso de creación de esa conexión WebSocket, pero suponiendo que tenemos una conexión WebSocket, ahora podemos simplemente enviar ese video a través de esa conexión WebSocket, lo cual es genial. Y luego, el lado del servidor también es bastante simple y directo. Tenemos este WebSocket, y cada vez que recibimos una nueva conexión, iniciaremos un proceso FFmpeg . Aquí, estoy usando un punto final RTMP de MUX, pero podría ser cualquier cosa. Haremos alguna limpieza si el proceso FFmpeg muere, o si el WebSocket se cierra, pero de lo contrario, cada vez que recibamos un nuevo mensaje y sea un búfer, simplemente lo escribiremos en FFmpeg y luego FFmpeg lo entregará a través de RTMP. Entonces esto funciona bastante bien. Si quieres ver una demostración de esto, puedes echar un vistazo a Glitch. Todo está funcionando. Puedes verlo funcionando en el navegador. Es bastante genial. Funciona bastante bien. Aquí, solo tienes que poner una clave de transmisión. Si quieres remixar el Glitch y usar un punto final RTMP diferente, está bien. También escribí una publicación de blog sobre todo esto.

Así que si quieres echarle un vistazo y obtener más detalles, me adentro un poco más en ello. ¡Gracias a todos! ¡Wow! Eso es mucha información en solo 20 o 28 minutos. Cuatro temas geniales. Me gustaría invitar a todos los oradores de las Charlas Relámpago al escenario para hacer la última ronda de preguntas y respuestas del día.

¡Hola a todos! ¡Hola! Hola. ¡Hola! Buenas tardes, noches, lo que sea para ustedes. Voy a ir directo a las preguntas. Comenzaré con la primera pregunta de Matt McClure. ¿A qué mercado están apuntando y por qué alguien usaría MUX en lugar de Twitch o YouTube? Sí, es una pregunta válida. Somos un producto orientado a desarrolladores, puramente APIs para que los desarrolladores las integren en sus plataformas, a diferencia de Twitch y YouTube, que son productos más orientados al consumidor. Entonces, si eres un streamer que solo quiere transmitir en vivo sin escribir código alguno, esas son excelentes plataformas que deberías usar. Si estás intentando construir una plataforma, probablemente seamos una mejor opción. Bueno, creo que se trata más del público objetivo y de tener más control sobre lo que estás haciendo, ¿no? Sí, lo pensaríamos un poco como una mala analogía que mencioné en Slack, son más como PayPal o Venmo. Nosotros somos más como Stripe, si lo piensas en términos de APIs de pago. De acuerdo, gracias.

La siguiente pregunta es para Jen. ¿Cuáles son las razones por las que a un equipo web de React Native le gustaría usar un div como botón? La razón es que colocar HTML dentro de un botón no es realmente HTML semántico. Por lo tanto, podrían envolver ese contenido, por ejemplo, una tarjeta o un bloque de imagen y texto, en un div y convertirlo en un botón accesible en lugar de poner un botón alrededor de él. Sí, por lo tanto, si tienes una tarjeta completamente clickable con diferentes elementos dentro, no puedes hacerlo de manera semántica dentro de un botón. Correcto. En ese caso, querrás hacer un div accesible. Bueno, al menos deberías querer hacerlo. Quizás. Y puedo decir, si no lo haces, Jen vendrá a buscarte. Te tocaré amablemente en el hombro y te haré sugerencias. ¿Qué tal eso? Sí. Sí, pero tocar no funciona. Entonces podría hackearlo. Sí. Sí. No es realmente una pregunta, pero solo para ti, un toque amable en el hombro de Martin van Houten.

No es realmente una pregunta. Solo quiero decir que Mesh se ve increíble. Siempre es agradable escuchar eso. Muchas gracias. Espero que sientas lo mismo y no me odies. Bueno, en realidad, en la empresa para la que trabajo, Albert Heijn, lo estamos usando. Y debo decir que ha sido un placer. Así que, muchas gracias.

Oh, eres mi vecino. Puedo ir a visitarte. Sería gezellig. Mike, ¿Ionic admite aplicaciones nativas, similar a React Native? ¿O es más como una aplicación estándar de Cordova donde es una interfaz web en lugar de una aplicación nativa? Entonces, es una combinación de ambos, donde la mayoría de la interfaz de usuario se muestra en una vista web. Puedes integrar vistas nativas personalizadas o actividades en Android y mezclar qué vista se muestra, la vista web o la vista nativa, o incluso superponer la vista nativa encima de la vista web. Así que obtienes lo mejor de ambos mundos. Eso se siente poderoso.

De acuerdo. Gracias chicos y señorita por esta gran charla. Para las personas que están viendo, también estarán en las salas de Zoom para preguntas. Pero la parte formal ha terminado. Voy a despedirme de ustedes por un rato. Así que, gracias por unirse. Gracias. Gracias. Adiós adiós.