HN presenta: Winamp y otros reproductores multimedia recreados para la web con Web Components
(player.style)- player.style es una colección de temas para reproductores de video y audio basada en Media Chrome, que se puede aplicar de la misma manera a diversos reproductores web y frameworks de aplicaciones
- Después de elegir el tema de reproductor deseado y seleccionar el reproductor y el framework, se pasa a un flujo de código que se puede copiar y pegar
- Permite filtrar temas por condiciones como Video/Audio, HTML, React, Next.js, Vue, Svelte, además de miniaturas en la línea de tiempo, AirPlay, Google Cast, capítulos y tooltips
- La UI del reproductor se puede ajustar solo con HTML y CSS, y también ofrece configuración de colores de tema como Primary, Secondary y Accent
- Experiencias de reproductores multimedia existentes como Sutro, Instaplay, Notflix, YT, Minimal y Winamp se recrean como temas para la web y se pueden aplicar rápidamente
Cómo usar y personalizar player.style
- player.style ofrece temas para reproductores de video y audio creados con Media Chrome
- Su alcance objetivo es “every web player” y “every web app framework”
- El flujo de aplicación consta de 3 pasos simples
- Elegir un tema de reproductor que te guste
- Seleccionar el reproductor y el framework de la app que vas a usar
- Copiar y pegar el código generado
- La UI del reproductor se puede ajustar en detalle solo con HTML y CSS
- Los filtros y opciones de configuración incluyen lo siguiente
- Medio: Video, Audio
- Frameworks: HTML, React, Next.js, Vue, Svelte
- Funciones: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
- Colores: Primary, Secondary, Accent
Galería de temas para reproductores web
- Sutro: un tema elegante y moderno que toma su nombre de la antena de TV de San Francisco
- X-mas: tema navideño con tonos rojos y verdes, luces brillantes y ambiente de fin de año
- Halloween: un tema que añade ambiente de Halloween al reproductor de video
- Instaplay: tema mobile-first inspirado en la experiencia de reproducción de una app popular de redes sociales
- Sutro Audio: tema de audio con la misma descripción que Sutro
- Notflix: tema que sugiere una experiencia sin la “gran N roja” ni el largo autobús rumbo a Los Gatos
- Reelplay: tema de reproductor multimedia retro inspirado en reproductores multimedia del pasado
- Vimeonova: tema que reinterpreta el diseño del reproductor clásico de Vimeo
- YT: homenaje al reproductor moderno y ampliamente usado de YouTube, recreado lo más fielmente posible con Web Components
- Tailwind Audio: tema minimalista de reproductor de audio creado con Tailwind CSS
- Demuxed 2022: tema de reproductor multimedia creado para Demuxed 2022
- Microvideo: tema pensado para contenido corto que no necesita controles de reproducción robustos como los de contenidos largos
- Minimal: tema simple que reduce la experiencia de Mux Player a los controles básicos que necesita el espectador
- Winamp: tema retro inspirado en el reproductor multimedia clásico Winamp
1 comentarios
Comentarios de Hacker News
Si solo necesitas música y no video, también vale la pena ver https://webamp.org/
No hace falta “compilarlo” ni “integrarlo” de forma grandilocuente; simplemente lo incluyes, y la lista de reproducción la genera la app. Ej.: Music
Me gusta esta idea y agradezco que la hayan publicado con licencia MIT
Justo estoy creando una app multimedia, más precisamente un editor de video, y antes también hice algunos reproductores de video con Flash y HTML/JS. Alrededor de 2015 probé usar Web Components en un reproductor, pero siguió siendo doloroso y al final volví a JavaScript común. Curiosamente, en mi app multimedia actual estoy usando Web Components, como una línea de tiempo para un editor de video, y hasta ahora ha funcionado bastante bien. No sé bien qué cambió, o si simplemente la lenta evolución de la web hizo que la compatibilidad ya fuera suficiente
Revisé por encima la documentación de Media Chrome y miré rápido el repositorio de GitHub, pero me gustaron los principios de diseño y las notas de arquitectura. Al adoptar algo así, especialmente viniendo de alguien que ya construyó varias veces este tipo de cosas, lo que más me preocupa son la extensibilidad y el tamaño de los archivos. Por ejemplo, me pregunto qué tan difícil sería adaptar mi componente de línea de tiempo al paradigma de MediaController. Si lo construyes todo tú mismo, tiene la ventaja de incluir solo lo necesario y nada más. Media Chrome seguramente tiene muchas funciones que nunca voy a usar, así que la pregunta es cuánto peso innecesario terminaría cargando por eso. No solo componentes que no uso, sino también funciones que no uso dentro de los componentes que sí uso. A veces, las funciones innecesarias existentes incluso obstaculizan la extensibilidad a un nivel más bajo
Además, el repositorio
media-elements[1] no tiene archivo de licencia. En package.json dice que los elementos también son MIT, pero siempre es bueno tener un archivo LICENSE explícitoAun así, es una biblioteca bastante atractiva. Como mínimo, hasta ahora la página que los incluía era la que conectaba los elementos entre sí, y justo estaba buscando una mejor abstracción, así que probablemente me robe la idea de envolver mis componentes en algo como media-controller
En el medio estuvo la especificación v2 de Web Components, aunque no soy experto en qué cambió exactamente. Ahora ya se ven Web Components por todos lados, especialmente en reproductores multimedia. Por ejemplo, el reproductor web de Apple
Me alegra que te guste la arquitectura del controlador. En las primeras versiones, todos los elementos apuntaban directamente al elemento multimedia, y con la llegada del controlador todo quedó mucho más ordenado. Al menos comparado con la forma en que yo lo hacía, lo recomiendo muchísimo
Veo la UI de un editor de video como una extensión natural de la familia Media Chrome. Estaría bueno que dejes un issue en el repositorio con qué cosas serían más útiles para ese caso
Entiendo muy bien la duda de adoptar algo como Media Chrome por la flexibilidad futura y el tamaño. Para mí, hay 3 puntos que podrían convencerme: 1) puedes incluir solo los componentes de UI que necesitas, y eso marca una gran diferencia de tamaño frente a otros reproductores de video web. 2) Están trabajando en ello algunos de los desarrolladores de reproductores con más experiencia, incluyendo aspectos como accesibilidad y futura internacionalización. 3) Estamos intentando que sea muy configurable mediante slots, CSS parts y variables CSS
Claro que no puede ganarle en tamaño de archivo a un software totalmente hecho a medida, pero creo que se acercará bastante cuando tenga todas las funciones básicas. Gracias por avisar lo de la licencia de elements
La estrategia de marketing de Mux es inteligente
Adquieren proyectos open source o crean nuevos para que los desarrolladores que buscan paquetes de video terminen encontrándose con el nombre de la empresa
Otro ejemplo reciente que vi es https://github.com/cookpete/react-player
Parte de lo que se ve en el lado de los reproductores open source se debe a que, de todos modos, tenemos que dar soporte a esos proyectos. Como no estamos atados a un reproductor, nuestros clientes usan varias soluciones open source, incluidas algunas que no tienen mantenimiento muy activo
Hoy hay muy pocas empresas de video centradas en desarrolladores que contribuyan activamente al open source, así que creo que eso nos beneficia
Mux se ve bien, pero no creo que la empresa vaya a mantener para siempre el nivel gratuito de codificación de video, así que no creo que vaya a construir algo encima de eso.
La codificación on-demand para usuarios también se siente un poco ilógica desde el punto de vista de recursos. El modelo starter consiste en comprar USD 100 en créditos por USD 10. Todo parece un gran producto gancho, y cada vez cuesta más confiar en una empresa que parece quemar dinero todos los días. Preferiría que cobraran algo, aunque fuera poco. Sé que la codificación no es gratis. O bien, si el sitio tuviera una sección que explique cómo pueden seguir operando cobrando menos que todos en la industria, reduciría bastante mis sospechas. Me he quemado demasiadas veces con SaaS.
Lo de “una sección que explique cómo pueden seguir operando cobrando menos que todos en la industria” es un comentario muy bueno y lo voy a agregar a la lista de pendientes. Definitivamente debería existir.
No vamos a ofrecer precios con una economía que no podamos sostener; como mínimo tiene que haber un camino claro para sostenerlos. Todos los precios por volumen son públicos, así que si entiendes conceptos como créditos, no debería pasarte que después del gancho te cambien el precio. Es lo opuesto a algunos competidores que sorprenden a los usuarios con precios nuevos cuando escalan. Odio mucho esa forma de operar.
Internamente tenemos ventaja porque usamos codificación justo a tiempo y otras optimizaciones avanzadas. También hay economías de escala, y pensamos escribir sobre eso.
Dicho eso, la percepción de los clientes es complicada. Algunos clientes entienden la codificación y sus costos, además de beneficios como el streaming adaptativo o el procesamiento de cargas generadas por usuarios. Muchos desarrolladores se acercan al video por primera vez y esperan que cueste lo mismo que subir un MP4 a S3. Algunos mencionan competidores que no cobran por codificación, y otros dicen que debería ser más barato por YouTube. Antes, Mux cobraba por codificación, así que quedaba clasificado como la “opción cara”; por eso estamos creando una nueva estructura de precios que empieza con un nivel de codificación más bajo y económicamente sostenible, y luego permite elegir niveles de mayor costo/valor de codificación si se considera que valen la pena. Parte de esto ya se lanzó y parte está por venir.
Creemos que el video debería estar en muchos más lugares que hoy, pero el video es inherentemente caro comparado con muchos otros costos de crear apps. Por eso vemos como nuestro trabajo seguir bajando costos y ajustando la estructura de precios para que el video pueda usarse en más casos de uso.
Las concesiones de usar codificación gratuita están resumidas aquí: https://docs.mux.com/guides/use-video-quality-levels. Incluso con la codificación basic gratuita, se siguen cobrando almacenamiento y transferencia. Esperamos que, si ayudamos a reducir costos al inicio, podamos crecer juntos.
La codificación on-demand, es decir JIT, realmente parece magia cuando ves lo bien y consistentemente que funciona.
Trabajo en Mux.
Hay algunas cosas algo extrañas con el manejo del foco aquí. Espero que se tome como crítica constructiva; todos tienen el mismo problema.
Si haces clic en el video en sí, las flechas izquierda/derecha permiten avanzar o retroceder en el video. Arriba/abajo no hacen nada.
Si haces clic en la barra de navegación, las flechas izquierda/derecha dejan de funcionar. En cambio, las flechas arriba/abajo empiezan a retroceder/avanzar con intervalos de tiempo diferentes.
Si haces clic en un espacio vacío, como la barra azul estilo Windows 98 del ejemplo de Winamp o de Reelplay, todos estos controles dejan de funcionar y la barra espaciadora tampoco reproduce/pausa.
Lo comprobé en Chrome actual en macOS.
En general, la situación se complica un poco porque se superponen los “atajos” para controlar el video, los controles de accesibilidad de cada componente y las expectativas generales de accesibilidad de toda la página. Por ejemplo, está la pregunta de si cuando el reproductor tiene el foco las flechas arriba/abajo siempre deberían controlar el volumen, o si no deberían hacerlo porque la gente espera usarlas para desplazar la página.
En cualquier caso, esta es un área en la que tenemos que seguir iterando y mejorando, así que el feedback ayuda.
Player.style es excelente.
En mi startup anterior empecé a crear un tema propio para video.js, pero después de unas horas decidí que no valía mi tiempo y usé los valores predeterminados. En adelante, estos temas parecen un punto de partida mucho mejor para crear algo más personalizado.
Ya que hay expertos en video en este hilo, me pregunto si existe alguna implementación de reproductor que permita búsqueda rápida y fluida con audio.
Me refiero a algo parecido a poder recorrer o ver una línea de tiempo en Adobe Premiere a 16x. Supongo que habría que precargar agresivamente algo como una pista de audio mono de 16 kHz y un formato de video de 240p con sprites a 1 fps o solo I-frames, y cambiar a eso al buscar.
No tengo una respuesta exacta, pero quizá convenga mirar el área de WebCodecs, donde se están creando ejemplos de buen rendimiento a más bajo nivel: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...
Los componentes web son excelentes, y Mux está haciendo cosas geniales con ellos.
Se puede adaptar el código para que funcione con embeds de YouTube
Basta con configurar lo siguiente en el
srcdel embed de YouTube:controls=0– elimina los controles del reproductor, como reproducir, pausar y volumenmodestbranding=1– minimiza el logo de YouTube dentro del reproductorrel=0– evita que se muestren videos relacionados al final. Solo funciona mostrando videos del mismo canalshowinfo=0– elimina el título del video y la información del uploader. Este parámetro está obsoleto, peromodestbrandingayudafs=0– desactiva el botón de pantalla completaiv_load_policy=3– oculta anotaciones del video, como notificaciones emergentesLuego, en el código, basta con detectar la URL del embed de YouTube y crear el reproductor con un
iframeen lugar de una etiquetavideo. Por último, hay que mapear los controles del reproductor a la API de embeds de YouTube. Plyr.io hizo algo parecidoHacer algo que se parezca en cierta medida a Winamp no significa que sea Winamp