HN en clair : Winamp et d’autres lecteurs multimédias recréés sur le web avec des Web Components

• player.style est une collection de thèmes de lecteurs vidéo et audio basés sur Media Chrome, pouvant être appliqués de la même manière à divers lecteurs web et frameworks d’application
• Après avoir choisi le thème de lecteur souhaité, il suffit de sélectionner le lecteur et le framework pour obtenir un flux de code prêt à copier-coller
• Il est possible de filtrer les thèmes par Video/Audio, HTML, React, Next.js, Vue, Svelte, ainsi que par fonctionnalités comme les miniatures de la timeline, AirPlay, Google Cast, les chapitres ou les infobulles
• L’interface du lecteur peut être ajustée uniquement avec du HTML et du CSS, avec aussi des réglages de couleurs de thème comme Primary, Secondary et Accent
• Des expériences de lecteurs multimédias existantes comme Sutro, Instaplay, Notflix, YT, Minimal ou Winamp ont été recréées sous forme de thèmes web afin d’être appliquées rapidement

---

Utilisation et personnalisation de player.style

• player.style propose des thèmes de lecteurs vidéo et audio créés avec Media Chrome
• Le périmètre visé est « every web player » et « every web app framework »
• Le processus d’intégration se résume à 3 étapes simples
  • choisir un thème de lecteur qui vous plaît
  • sélectionner le lecteur et le framework d’application à utiliser
  • copier-coller le code généré
• L’interface du lecteur peut être affinée uniquement avec du HTML et du CSS
• Les filtres et options comprennent notamment
  • média : Video, Audio
  • frameworks : HTML, React, Next.js, Vue, Svelte
  • fonctionnalités : timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
  • couleurs : Primary, Secondary, Accent

Galerie de thèmes de lecteurs web

• Sutro : un thème élégant et moderne dont le nom vient de l’antenne TV de San Francisco
• X-mas : un thème de Noël aux tons rouges et verts, avec des lumières scintillantes et une ambiance de fin d’année
• Halloween : un thème qui ajoute une ambiance d’Halloween au lecteur vidéo
• Instaplay : un thème mobile-first inspiré de l’expérience de lecture des applications sociales populaires
• Sutro Audio : un thème audio décrit de la même manière que Sutro
• Notflix : un thème qui évoque une expérience sans le « grand N rouge » ni le long bus pour Los Gatos
• Reelplay : un thème de lecteur multimédia rétro inspiré des anciens lecteurs multimédias
• Vimeonova : un thème qui réinterprète le design classique du lecteur Vimeo
• YT : un hommage au lecteur YouTube moderne et largement utilisé, recréé au plus près avec des Web Components
• Tailwind Audio : un thème minimaliste de lecteur audio créé avec Tailwind CSS
• Demuxed 2022 : un thème de lecteur multimédia conçu pour Demuxed 2022
• Microvideo : un thème pensé pour les contenus courts, qui n’ont pas besoin de contrôles de lecture avancés adaptés aux contenus longs
• Minimal : un thème simple qui réduit l’expérience Mux Player aux contrôles essentiels dont le spectateur a besoin
• Winamp : un thème rétro inspiré du lecteur multimédia classique Winamp

[GN⁺]

Commentaires sur Hacker News

• Si vous avez seulement besoin de musique et pas de vidéo, https://webamp.org/ vaut aussi le détour.
  Pas besoin de le « compiler » ou de l’« intégrer » de façon grandiloquente : il suffit de l’inclure, et l’application peut générer la playlist. Ex. : Music

  • L’implémentation est vraiment bonne. Si on le voulait, il semblerait aussi assez facile d’y ajouter la prise en charge de la vidéo, et j’imagine qu’en interne il utilise simplement des éléments média.

• J’aime cette idée, et merci de l’avoir publiée sous licence MIT.
  Je suis justement en train de créer une application média — plus précisément un éditeur vidéo — et j’ai déjà réalisé plusieurs lecteurs vidéo autrefois avec Flash et HTML/JS. Vers 2015, j’ai essayé d’utiliser des web components dans un lecteur, mais ça restait pénible en permanence, donc je suis finalement revenu au JavaScript classique. Curieusement, dans mon application média actuelle, j’utilise des web components pour des éléments comme la timeline de l’éditeur vidéo, et jusqu’ici ça fonctionne plutôt bien. Je ne sais pas exactement ce qui a changé, ni si c’est simplement grâce à la lente maturation du web qui a fini par rendre la compatibilité suffisante.
  J’ai parcouru la documentation de Media Chrome et seulement survolé le dépôt GitHub, mais j’aime bien les principes de conception et les notes d’architecture. Quand j’envisage d’adopter quelque chose comme ça — surtout après avoir moi-même construit ce genre de chose plusieurs fois — mes principales inquiétudes concernent l’extensibilité et la taille des fichiers. Par exemple, je me demande à quel point il serait difficile d’adapter mon composant de timeline au paradigme de MediaController. Quand on fait tout soi-même, l’avantage est qu’on n’a que ce dont on a besoin, et rien de plus. Media Chrome contient sûrement beaucoup de fonctionnalités que je n’utiliserai jamais ; la question est donc de savoir quelle masse inutile cela m’oblige à embarquer. Cela vaut non seulement pour les composants inutilisés, mais aussi pour les fonctionnalités inutilisées à l’intérieur des composants que j’utilise. Parfois, des fonctionnalités superflues existantes gênent même l’extensibilité à un niveau plus bas.
  Au passage, le dépôt media-elements [1] n’a pas de fichier de licence. Le package.json indique que les éléments sont eux aussi sous MIT, mais c’est toujours mieux d’avoir un fichier LICENSE explicite.
  Cela reste malgré tout une bibliothèque assez séduisante. Jusqu’à présent du moins, c’était la page qui l’incluait qui reliait les éléments entre eux, mais comme je cherchais une meilleure abstraction, je vais probablement reprendre l’idée d’envelopper mes composants dans un élément de type media-controller.

  1. https://github.com/muxinc/media-elements
  • Vers 2015, j’étais sans doute assez optimiste et obstiné au sujet des web components. Je voulais vraiment que ça marche bien, mais je ne les ai effectivement mis en production qu’autour de 2020.
    Entre-temps, il y a eu la spec v2 des web components, mais je ne suis pas expert de ce qui a changé exactement. Aujourd’hui, on voit des web components un peu partout, et particulièrement dans les lecteurs multimédia. Il y a par exemple le lecteur web d’Apple.
    Je suis ravi que l’architecture avec contrôleur vous plaise. Dans les premières versions, tous les éléments pointaient directement vers l’élément média, et l’arrivée du contrôleur a permis de beaucoup clarifier les choses. En tout cas, comparé à la manière dont je procédais avant, je le recommande vivement.
    L’UI d’un éditeur vidéo me semble être une extension naturelle de la gamme Media Chrome. Ce serait bien de laisser un ticket sur le dépôt pour indiquer ce qui pourrait être utile dans cette direction.
    Je comprends profondément l’hésitation à adopter quelque chose comme Media Chrome à cause de la souplesse future et de la taille. À mes yeux, il y a trois arguments convaincants. 1) On peut n’inclure que les composants UI nécessaires, ce qui fait une grande différence de taille par rapport aux autres lecteurs vidéo web. 2) Des développeurs de lecteurs parmi les plus expérimentés travaillent dessus, y compris sur des aspects comme l’accessibilité et la future internationalisation. 3) Nous essayons de le rendre très configurable via les slots, les CSS parts et les variables CSS.
    Bien sûr, on ne pourra jamais battre la taille d’un logiciel entièrement sur mesure, mais une fois toutes les fonctionnalités de base en place, on devrait pouvoir s’en approcher assez fortement. Merci d’avoir signalé la licence des elements.

• La stratégie marketing de Mux est habile.
  Ils rachètent ou créent de nouveaux projets open source pour que les développeurs à la recherche de packages vidéo finissent par tomber sur le nom de l’entreprise.
  Un autre exemple récent que j’ai vu est https://github.com/cookpete/react-player

  • Merci. « Habile » est peut-être un peu flatteur. En grande partie, il s’agit plutôt d’observer comment les développeurs utilisent la vidéo et d’essayer de résoudre les problèmes de cet espace. Next-video.dev est aussi un exemple dont nous sommes fiers.
    Une partie de ce qu’on observe du côté des lecteurs open source vient aussi du fait que, de toute façon, nous devons soutenir ce type de projets. Comme nous ne sommes pas liés à un lecteur particulier, nos clients utilisent différents projets open source, y compris certains dont la maintenance n’est pas très active.
    À l’heure actuelle, il y a très peu d’entreprises vidéo orientées développeurs qui contribuent activement à l’open source, donc je pense que nous en tirons avantage.

• Mux a l’air bien, mais je ne construirais probablement rien dessus parce que je ne crois pas que l’entreprise conservera durablement le palier gratuit d’encodage vidéo
  Même l’encodage à la demande pour les utilisateurs semble un peu absurde du point de vue des ressources. Le modèle starter consiste à acheter 100 $ de crédits pour 10 $. Tout cela ressemble à un gros produit d’appel, et il devient difficile de faire confiance à une entreprise qui semble brûler de l’argent chaque jour. Je préférerais presque qu’ils facturent au moins quelque chose. Je sais que l’encodage n’est pas gratuit. Ou alors, s’il y avait sur le site une section expliquant comment ils peuvent continuer à opérer tout en étant moins chers que tout le reste du secteur, cela réduirait pas mal mes soupçons. J’ai été trop souvent échaudé par le SaaS

  • Je pourrais écrire un livre entier en réponse à ça
    Une « section expliquant comment nous pouvons continuer à opérer tout en étant moins chers que tout le reste du secteur » est un excellent retour, et je vais l’ajouter à notre liste de choses à faire. Il nous en faut clairement une
    Nous ne proposerons pas des prix dont l’économie n’est pas viable, ou du moins il doit y avoir une voie claire vers cette viabilité. Tous les tarifs par volume sont publics, donc si vous comprenez le principe des crédits, il ne devrait pas y avoir de changement de prix caché derrière un produit d’appel. C’est l’inverse de certains concurrents qui surprennent les utilisateurs avec de nouveaux tarifs une fois qu’ils ont grandi. Je déteste vraiment cette approche
    En interne, nous avons un avantage grâce à l’encodage juste à temps et à d’autres optimisations avancées. Il y a aussi des économies d’échelle, et nous prévoyons d’écrire à ce sujet
    Cela dit, la perception côté clients est difficile. Certains clients comprennent l’encodage, son coût, et les bénéfices comme le streaming adaptatif ou le traitement des uploads générés par les utilisateurs. Beaucoup de développeurs découvrent la vidéo et s’attendent à ce que cela coûte la même chose que de mettre un MP4 sur S3. Certains citent des concurrents sans coût d’encodage, d’autres disent que cela devrait être moins cher à cause de YouTube. Par le passé, Mux facturait l’encodage, ce qui le faisait classer parmi les « options chères », donc nous mettons en place une nouvelle structure tarifaire qui commence à un niveau d’encodage plus bas mais économiquement soutenable, puis permet de choisir un niveau de coût/valeur d’encodage plus élevé si l’on estime que cela en vaut la peine. Une partie est déjà lancée, une autre est à venir
    Nous pensons que la vidéo devrait être présente dans plus d’endroits qu’aujourd’hui, mais elle reste intrinsèquement coûteuse par rapport à beaucoup d’autres coûts liés à la création d’une application. Donc notre travail, c’est de continuer à faire baisser les coûts et à affiner la structure tarifaire pour permettre l’usage de la vidéo dans davantage de cas d’usage
  • Il existe des cas d’usage, comme le contenu généré par les utilisateurs, où l’encodage devient le principal centre de coût, et nous voulions qu’il soit possible de construire sur Mux même avec ce modèle
    Les compromis liés à l’encodage gratuit sont résumés ici : https://docs.mux.com/guides/use-video-quality-levels. Même avec l’encodage basic gratuit, les coûts de stockage et de diffusion restent facturés. Nous espérons qu’en aidant à réduire les coûts au démarrage, nous pourrons grandir avec vous
    L’encodage on-demand, c’est-à-dire JIT, est presque magique quand on voit à quel point cela fonctionne bien de façon constante
    Je travaille chez Mux

• Il y a ici quelque chose d’un peu étrange dans la gestion du focus. J’espère que ce sera pris comme une critique constructive, et tout semble relever du même problème
  Si on clique sur la vidéo elle-même, on peut naviguer en avant et en arrière dans la vidéo avec les flèches gauche/droite. Haut/bas ne fait rien
  Si on clique sur la barre de navigation, les flèches gauche/droite cessent de fonctionner. À la place, les flèches haut/bas commencent à faire du retour/avance à d’autres intervalles temporels
  Si on clique sur une zone vide, comme la barre bleue qui ressemble à Windows 98 dans l’exemple Winamp ou l’exemple Reelplay, tous ces contrôles cessent de fonctionner et même la barre d’espace ne lance plus ni ne met en pause
  Testé sur la dernière version de Chrome sur macOS

  • Bon retour. Il y a un ticket à ce sujet dans le dépôt Media Chrome : https://github.com/muxinc/media-chrome/issues/957
    En général, la situation est un peu complexe à cause du chevauchement entre les « raccourcis clavier » pour contrôler la vidéo, les contrôles d’accessibilité de chaque composant, et les attentes générales d’accessibilité au niveau de toute la page. Par exemple, quand le focus est sur le player, faut-il toujours capter les flèches haut/bas pour le contrôle du volume, ou ne pas le faire parce que les gens s’attendent à s’en servir pour faire défiler la page ?
    Quoi qu’il en soit, c’est un point que nous devons encore améliorer par itérations, donc ce retour est utile

• Player.style est excellent
  Dans ma précédente startup, j’ai commencé à créer moi-même un thème video.js, puis après quelques heures j’ai décidé que cela ne valait pas le temps que j’y consacrais et j’ai gardé les valeurs par défaut. À l’avenir, ce genre de thèmes semble être un bien meilleur point de départ pour créer quelque chose de plus personnalisé

  • S’il y a encore des frictions quand vous créez un thème vous-même, alors notre travail n’est pas terminé. N’hésitez pas à nous le signaler

• Puisqu’il y a des spécialistes de la vidéo dans ce fil, je me demande s’il existe une implémentation de player permettant une navigation rapide et fluide avec l’audio
  Je parle d’une fonctionnalité similaire à ce qu’on a dans Adobe Premiere, quand on parcourt ou lit la timeline en 16x. J’imagine qu’il faudrait précharger de manière agressive quelque chose comme une piste audio mono 16 kHz et un format vidéo 240p avec sprite à 1 fps ou seulement des I-frames, puis basculer dessus pendant la navigation

  • La navigation précise à la frame près ou fluide a toujours été difficile au niveau d’abstraction de l’élément video
    Il n’y a pas de réponse parfaite, mais cela vaut peut-être le coup de regarder du côté de WebCodecs, où des exemples performants commencent à émerger à un niveau plus bas : https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

• Les web components sont excellents, et Mux fait de très belles choses avec

  • Un petit retour : il pourrait être intéressant d’envisager l’usage de adoptedStyleSheets. Le support est désormais très bon, et cela apporte des gains de performance sur les éléments répétés. On peut aussi prévoir un fallback

• Il est possible d’adapter le code pour qu’il fonctionne avec des embeds YouTube
  Il suffit de définir les paramètres suivants dans le src de l’embed YouTube :
  controls=0 – supprime les contrôles du lecteur comme lecture, pause et volume
  modestbranding=1 – minimise le logo YouTube dans le lecteur
  rel=0 – empêche l’affichage de vidéos associées à la fin. Cela ne fonctionne plus qu’en limitant l’affichage aux vidéos de la même chaîne
  showinfo=0 – supprime le titre de la vidéo et les informations sur l’uploader. Ce paramètre est obsolète, mais modestbranding aide
  fs=0 – désactive le bouton plein écran
  iv_load_policy=3 – masque les annotations de la vidéo, comme les notifications surgissantes
  Ensuite, il suffit dans le code de détecter l’URL d’embed YouTube et de créer le lecteur avec un iframe au lieu d’une balise video. Enfin, il faut faire correspondre les contrôles du lecteur à l’API d’embed YouTube. Plyr.io a fait quelque chose de similaire

• Créer quelque chose qui ressemble plus ou moins à Winamp ne suffit pas à en faire Winamp