Realizar transmisiones en vivo desde tu navegador sin WebRTC

Rate this content
Bookmark

Cuando los desarrolladores piensan en transmitir en vivo desde el navegador, la suposición inmediata es utilizar WebRTC. Si bien WebRTC es una tecnología increíble, las implementaciones del lado del servidor son... deficientes en este momento. Hablaremos sobre una forma (totalmente chapucera) de obtener video desde el navegador a través de la tecnología que estás utilizando hoy.

13 min
02 Aug, 2021

Video Summary and Transcription

Mux proporciona una API para transmisiones en vivo y tiene como objetivo mantener a los usuarios en sus propias aplicaciones. La transmisión en vivo y el chat en vivo son diferentes, con el chat en vivo utilizando WebRTC y la transmisión en vivo utilizando RTMP y HLS. WebRTC se puede implementar utilizando Chrome sin cabeza o el proceso getUserMedia. Mux se dirige a los desarrolladores que construyen plataformas y sugiere el uso de HTML semántico. Ionic admite aplicaciones nativas y vistas nativas personalizadas.

Available in English

1. Introducción a la transmisión en vivo y la experiencia del usuario

Short description:

Soy Matthew McClure, cofundador de Mux. Proporcionamos una API para transmisión en vivo. A menudo, los usuarios preguntan cómo permitir que sus usuarios transmitan en vivo desde un navegador. Las recomendaciones actuales implican el uso de software nativo, pero las personas quieren mantener a los usuarios en sus propias aplicaciones.

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.

2. Diferencia entre Transmisión en Vivo y Chat en Vivo

Short description:

La transmisión en vivo y el chat en vivo a menudo se confunden, pero son diferentes. El chat en vivo es para la comunicación directa entre dos usuarios, mientras que la transmisión en vivo es para que una persona transmita a muchos. El chat en vivo utiliza WebRTC, mientras que la transmisión en vivo utiliza RTMP y HLS. WebRTC no puede comunicarse directamente con RTMP, por lo que se necesita un servidor para la conversión.

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.

3. WebRTC a RTMP Streaming

Short description:

Puedes implementar WebRTC en el lado del servidor utilizando Chrome sin cabeza, lo que te permite incorporar tecnologías y superposiciones del navegador en la transmisión en vivo. Sin embargo, ejecutar Chrome a gran escala para cada usuario puede ser complejo. Alternativamente, puedes utilizar el proceso de obtener medios del usuario para capturar el micrófono y la cámara del navegador, y enviar la transmisión a través de WebSockets. En el lado del servidor, puedes utilizar FFmpeg para procesar los datos de WebSocket y entregarlos a través de RTMP. Este método funciona bien y hay una demostración disponible en Glitch.

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.

QnA

Q&A: MUX Mercado Objetivo y Uso de un Div como Botón

Short description:

Me adentro un poco más en ello. Somos un producto orientado a desarrolladores, puramente APIs para que los desarrolladores las integren en sus plataformas. Si eres un streamer que solo quiere transmitir en vivo sin escribir código alguno, Twitch y YouTube son excelentes plataformas para usar. Si estás intentando construir una plataforma, probablemente seamos una mejor opción. Colocar HTML dentro de un botón no es realmente HTML semántico. Por lo tanto, podrían envolver ese contenido en un div y convertirlo en un botón accesible en lugar de poner un botón alrededor de él.

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.

Agradecimiento por el Soporte de Mesh y Ionic Native

Short description:

No es realmente una pregunta, solo quería expresar mi agradecimiento por Mesh. En Albert Heijn, lo hemos estado usando y ha sido un placer. ¿Ionic admite aplicaciones nativas como React Native, o es más como una aplicación estándar de Cordova con una interfaz web? Es una combinación de ambos, permitiendo la integración con vistas nativas personalizadas. Gracias a todos por la charla, y hasta luego por ahora.

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.

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 Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Top Content
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit Remote Edition 2020React Summit Remote Edition 2020
32 min
AHA Programming
Top Content
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.
React Summit US 2023React Summit US 2023
21 min
The Epic Stack
Modern web development is fantastic. There are so many great tools available! Modern web development is exhausting. There are so many great tools available! Each of these sentiments is true. What's great is that most of the time, it's hard to make a choice that is wrong. Seriously. The trade-offs of most of the frameworks and tools you could use to build your application fit within the constraints of the vast majority of apps. Despite this, engineers consistently struggle with analysis paralysis.Let's talk about this, and a solution I am working on for it.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Top Content
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Top Content
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

Prerequisites:
IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)