HN vorgestellt: Winamp und andere Media Player mit Web Components fürs Web neu umgesetzt

 (player.style)
3 Punkte von GN⁺ 2024-10-09 | 1 Kommentare | Auf WhatsApp teilen
  • player.style ist eine Sammlung von Video- und Audio-Player-Themes auf Basis von Media Chrome, die sich einheitlich auf verschiedene Web-Player und App-Frameworks anwenden lässt
  • Nach der Auswahl des gewünschten Player-Themes wählt man Player und Framework aus und gelangt zu einem Code-Flow, den man kopieren und einfügen kann
  • Themes lassen sich nach Kriterien wie Video/Audio, HTML, React, Next.js, Vue, Svelte sowie Timeline-Thumbnails, AirPlay, Google Cast, Kapitel und Tooltips eingrenzen
  • Die Player-UI kann ausschließlich mit HTML und CSS angepasst werden; außerdem gibt es Theme-Farbeinstellungen wie Primary, Secondary und Accent
  • Sutro, Instaplay, Notflix, YT, Minimal, Winamp und weitere bekannte Media-Player-Erlebnisse werden als Web-Themes neu umgesetzt und lassen sich schnell anwenden

Nutzung und Anpassung von player.style

  • player.style bietet Video- und Audio-Player-Themes, die mit Media Chrome erstellt wurden
  • Der Zielbereich umfasst „every web player“ und „every web app framework“
  • Der Ablauf besteht aus drei einfachen Schritten
    • Ein Player-Theme auswählen, das einem gefällt
    • Den zu verwendenden Player und das App-Framework auswählen
    • Den generierten Code kopieren und einfügen
  • Die Player-UI lässt sich ausschließlich mit HTML und CSS im Detail anpassen
  • Filter und Einstellungen umfassen unter anderem
    • Medien: Video, Audio
    • Frameworks: HTML, React, Next.js, Vue, Svelte
    • Funktionen: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
    • Farben: Primary, Secondary, Accent

Galerie der Web-Player-Themes

  • Sutro: Ein elegantes, modernes Theme, benannt nach einer TV-Antenne in San Francisco
  • X-mas: Ein Weihnachts-Theme mit Rot- und Grüntönen, funkelnden Lichtern und Jahresend-Stimmung
  • Halloween: Ein Theme, das dem Video-Player Halloween-Atmosphäre verleiht
  • Instaplay: Ein Mobile-first-Theme, inspiriert vom Wiedergabeerlebnis populärer Social-Media-Apps
  • Sutro Audio: Ein Audio-Theme mit derselben Beschreibung wie Sutro
  • Notflix: Ein Theme, das ein Erlebnis andeutet — abzüglich des „großen roten N“ und der langen Busfahrt nach Los Gatos
  • Reelplay: Ein Retro-Media-Player-Theme, inspiriert von Media Playern aus früheren Zeiten
  • Vimeonova: Eine neue Interpretation des klassischen Vimeo-Player-Designs
  • YT: Eine Hommage an den modernen, weit verbreiteten YouTube-Player, mit Web Components so originalgetreu wie möglich neu umgesetzt
  • Tailwind Audio: Ein minimalistisches Audio-Player-Theme, erstellt mit Tailwind CSS
  • Demuxed 2022: Ein Media-Player-Theme, das für Demuxed 2022 erstellt wurde
  • Microvideo: Ein Theme für kurze Inhalte, die keine starken Wiedergabesteuerungen für längere Inhalte benötigen
  • Minimal: Ein schlichtes Theme, das das Mux-Player-Erlebnis auf die grundlegenden Controls reduziert, die Zuschauer benötigen
  • Winamp: Ein Retro-Theme, inspiriert vom klassischen Winamp-Media-Player

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-10-09
Hacker-News-Kommentare

  • Wenn man nur Musik braucht und kein Video, ist auch https://webamp.org/ einen Blick wert.
    Man muss es nicht „kompilieren“ oder groß „integrieren“, sondern kann es einfach einbinden; die Playlist erzeugt dann die App. Beispiel: Music

    • Die Umsetzung ist wirklich gut. Wenn man möchte, ließe sich vermutlich auch Video-Support leicht hinzufügen; intern nutzt es wahrscheinlich einfach Media-Elemente.

  • Mir gefällt diese Idee, und danke, dass ihr sie unter der MIT-Lizenz veröffentlicht habt.
    Ich baue gerade ebenfalls eine Medien-App, genauer gesagt einen Video-Editor, und habe früher schon ein paar Videoplayer in Flash und HTML/JS gebaut. Um 2015 herum habe ich bei einem Player Web Components ausprobiert, aber es blieb dauerhaft schmerzhaft, sodass ich am Ende wieder zu normalem JavaScript zurückgekehrt bin. Seltsamerweise verwende ich in der aktuellen Medien-App Web Components, etwa für die Timeline eines Video-Editors, und bisher funktioniert das ziemlich gut. Ich weiß nicht genau, was sich geändert hat – oder ob die langsame Entwicklung des Webs die Kompatibilität inzwischen einfach ausreichend verbessert hat.
    Ich habe die Media-Chrome-Dokumentation überflogen und auch nur kurz in das GitHub-Repository geschaut, aber die Designprinzipien und Architektur-Notizen gefallen mir. Wenn ich so etwas einführe, mache ich mir – besonders als jemand, der solche Dinge schon mehrfach selbst gebaut hat – vor allem Sorgen um Erweiterbarkeit und Dateigröße. Zum Beispiel frage ich mich, wie schwierig es wäre, meine Timeline-Komponente an das MediaController-Paradigma anzupassen. Wenn man alles selbst baut, hat man den Vorteil, dass nur das enthalten ist, was man braucht, und nichts darüber hinaus. In Media Chrome gibt es vermutlich viele Funktionen, die ich niemals nutzen werde; die Frage ist, wie viel unnötiges Gewicht ich mir dadurch einhandle. Das gilt nicht nur für ungenutzte Komponenten, sondern auch für ungenutzte Funktionen innerhalb der Komponenten, die man verwendet. Manchmal stehen vorhandene, unnötige Funktionen auch einer Erweiterbarkeit auf niedrigerer Ebene im Weg.
    Nebenbei: Im media-elements-Repository [1] fehlt eine Lizenzdatei. In der package.json steht zwar, dass die Elemente ebenfalls MIT-lizenziert sind, aber eine explizite LICENSE-Datei ist immer gut.
    Trotzdem ist es eine ziemlich reizvolle Library. Bisher hat zumindest die einbettende Seite die Elemente miteinander verdrahtet, aber ich wollte ohnehin eine bessere Abstraktion; die Idee, meine Komponenten in etwas wie ein media-controller-Element einzuhüllen, werde ich mir wohl abschauen.

    1. https://github.com/muxinc/media-elements
    • Um 2015 herum war ich Web Components gegenüber wohl ziemlich optimistisch und hartnäckig. Ich wollte wirklich, dass sie gut funktionieren, aber tatsächlich habe ich sie erst etwa 2020 in Produktion gebracht.
      Dazwischen gab es die Web-Components-Spezifikation v2, aber ich bin kein Experte darin, was sich geändert hat. Inzwischen sieht man Web Components an vielen Stellen, besonders bei Media-Playern. Ein Beispiel ist Apples Web-Player.
      Schön, dass dir die Controller-Architektur gefällt. In frühen Versionen zeigte jedes Element direkt auf das Media-Element; mit dem Controller wurde vieles deutlich aufgeräumter. Zumindest im Vergleich zu meiner früheren Vorgehensweise kann ich das sehr empfehlen.
      Eine Video-Editor-UI sehe ich als natürliche Erweiterung der Media-Chrome-Familie. Es wäre toll, wenn du im Repository ein Issue anlegen würdest, was dafür noch hilfreicher wäre.
      Ich kann sehr gut nachvollziehen, dass man wegen künftiger Flexibilität und Größe zögert, etwas wie Media Chrome einzuführen. Mich würden drei Punkte überzeugen: 1) Man kann nur die UI-Komponenten einbinden, die man braucht; das ist bei der Größe ein großer Unterschied zu anderen Web-Videoplayern. 2) Einige der erfahrensten Player-Entwickler arbeiten daran, inklusive Themen wie Barrierefreiheit und künftiger Internationalisierung. 3) Zwischen Slots, CSS Parts und CSS-Variablen versuchen wir, es sehr konfigurierbar zu machen.
      Natürlich lässt sich die Dateigröße vollständig maßgeschneiderter Software nicht schlagen, aber sobald die Basisfunktionen alle vorhanden sind, dürfte man ziemlich nah herankommen. Danke für den Hinweis zur Lizenz der elements.

  • Die Marketingstrategie von Mux ist clever.
    Sie übernehmen Open-Source-Projekte oder starten neue, damit Entwickler, die nach Videopaketen suchen, am Ende mit dem Firmennamen in Kontakt kommen.
    Ein weiteres Beispiel, das ich kürzlich gesehen habe, ist https://github.com/cookpete/react-player.

    • Danke. „Clever“ ist vielleicht zu viel des Lobes. Meist geht es eher darum, zu beobachten, wie Entwickler Video einsetzen, und Probleme in diesem Bereich zu lösen. Next-video.dev ist ein Beispiel, auf das wir ebenfalls stolz sind.
      Ein Teil dessen, was man bei Open-Source-Playern sieht, liegt daran, dass wir solche Projekte ohnehin in gewisser Weise unterstützen müssen. Da wir playerunabhängig sind, nutzen unsere Kunden eine Vielzahl von Open-Source-Projekten, darunter auch solche, die nicht mehr aktiv gepflegt werden.
      Derzeit gibt es unter den entwicklerorientierten Videounternehmen nur sehr wenige, die aktiv zu Open Source beitragen; insofern profitieren wir davon.

  • Mux sieht gut aus, aber ich glaube nicht, dass das Unternehmen seinen kostenlosen Tier für Video-Encoding dauerhaft beibehalten wird, daher würde ich wohl nichts darauf aufbauen.
    On-Demand-Encoding für Nutzer ergibt aus Ressourcensicht auch irgendwie nicht viel Sinn. Beim Starter-Modell kauft man für 10 Dollar Credits im Wert von 100 Dollar. Das wirkt alles wie ein großer Lockartikel, und es fällt schwer, einem Unternehmen weiter zu vertrauen, das anscheinend jeden Tag Geld verbrennt. Mir wäre es lieber, wenn sie wenigstens irgendetwas berechnen würden. Mir ist klar, dass Encoding nicht kostenlos ist. Oder wenn es auf der Website einen Abschnitt gäbe, der erklärt, wie sie weniger verlangen können als alle anderen in der Branche und trotzdem im Geschäft bleiben, würde das meine Zweifel deutlich verringern. Ich habe mir an SaaS schon zu oft die Finger verbrannt.

    • Darauf könnte man als Antwort ein ganzes Buch schreiben.
      Ein Abschnitt dazu, „wie sie weniger verlangen können als alle anderen in der Branche und trotzdem im Geschäft bleiben“, ist wirklich gutes Feedback und ich nehme ihn in die To-do-Liste auf. Den sollte es unbedingt geben.
      Wir werden keine Preise mit einer Wirtschaftlichkeit anbieten, die wir uns nicht leisten können; zumindest muss es einen klaren Weg geben, wie wir sie tragen können. Alle volumenabhängigen Preise sind öffentlich, daher sollte man, wenn man das Konzept von Credits versteht, nicht nach einem Köder plötzlich eine Preisänderung erleben. Das ist das Gegenteil einiger Wettbewerber, die Nutzer bei größerem Maßstab mit neuen Preisen überraschen. Diese Vorgehensweise hasse ich wirklich.
      Intern haben wir durch Just-in-Time-Encoding und andere fortgeschrittene Optimierungen einen Vorteil. Es gibt auch Skaleneffekte, und wir planen, dazu einen Artikel zu schreiben.
      Schwierig ist allerdings die Wahrnehmung bei Kunden. Manche Kunden verstehen Encoding und dessen Kosten sowie die Vorteile von adaptivem Streaming oder der Verarbeitung nutzergenerierter Uploads. Viele Entwickler sind neu im Bereich Video und erwarten, dass es so viel kostet wie das Hochladen einer MP4 nach S3. Manche verweisen auf Wettbewerber ohne Encoding-Kosten, andere meinen wegen YouTube, es müsse billiger sein. Früher hat Mux Encoding-Kosten berechnet und wurde deshalb als „teure Option“ eingeordnet. Daher entwickeln wir eine neue Preisstruktur, bei der man auf einem wirtschaftlich tragfähigen, niedrigeren Encoding-Niveau starten und dann, wenn man den Wert darin sieht, ein höheres Niveau bei Encoding-Kosten/Wert wählen kann. Ein Teil davon ist bereits gestartet, ein Teil kommt noch.
      Wir sind der Meinung, dass Video an mehr Stellen eingesetzt werden sollte als heute, aber Video ist im Vergleich zu vielen anderen Kosten beim Bau von Apps von Natur aus teuer. Deshalb sehen wir es als unsere Aufgabe, die Kosten weiter zu senken und die Preisstruktur zu verfeinern, damit Video in mehr Use Cases genutzt werden kann.
    • Es gibt Use Cases wie nutzergenerierte Inhalte, bei denen Encoding ein großer Kostentreiber ist, und wir wollten ermöglichen, dass man mit einem solchen Modell trotzdem auf Mux aufbauen kann.
      Die Trade-offs bei kostenlosem Encoding sind hier zusammengefasst: https://docs.mux.com/guides/use-video-quality-levels. Auch beim kostenlosen Basic-Encoding fallen weiterhin Kosten für Storage und Delivery an. Wir hoffen, dass wir gemeinsam wachsen können, wenn wir helfen, die Kosten am Anfang zu senken.
      On-Demand-, also JIT-Encoding, wirkt tatsächlich fast magisch, wenn man sieht, wie konsistent gut es funktioniert.
      Ich arbeite bei Mux.

  • Hier ist die Focus-Behandlung an einigen Stellen etwas seltsam. Ich hoffe, das kommt als konstruktive Kritik rüber; überall liegt im Grunde dasselbe Problem vor.
    Wenn man auf das Video selbst klickt, kann man mit den Pfeiltasten links/rechts im Video vor- und zurückspringen. Oben/unten tut nichts.
    Wenn man auf die Seekbar klickt, funktionieren die Pfeiltasten links/rechts nicht mehr. Stattdessen beginnen die Pfeiltasten oben/unten, in anderen Zeitabständen zurück- bzw. vorzuspringen.
    Wenn man auf eine leere Fläche klickt, etwa die blau wirkende Leiste im Windows-98-Stil im Winamp- oder Reelplay-Beispiel, funktionieren all diese Controls nicht mehr, und auch Wiedergabe/Pause mit der Leertaste geht nicht.
    Beobachtet in der aktuellen Chrome-Version unter macOS.

    • Gutes Feedback. Dazu gibt es ein Issue im Media-Chrome-Repository: https://github.com/muxinc/media-chrome/issues/957
      Generell ist die Lage etwas kompliziert, weil sich „Shortcuts“ zur Videosteuerung, Accessibility-Controls der einzelnen Komponenten und allgemeine Accessibility-Erwartungen an die gesamte Seite überschneiden. Zum Beispiel stellt sich die Frage, ob Pfeil hoch/runter immer für die Lautstärkeregelung abgefangen werden sollte, wenn der Player den Fokus hat, oder ob man das nicht tun sollte, weil Nutzer erwarten, damit die Seite zu scrollen.
      Jedenfalls müssen wir diesen Bereich weiter iterativ verbessern, daher ist das Feedback hilfreich.

  • Player.style ist großartig.
    Bei meinem letzten Startup habe ich angefangen, selbst ein Theme für video.js zu bauen, und nach ein paar Stunden entschieden, dass es meine Zeit nicht wert war, und die Defaults verwendet. Künftig dürften solche Themes ein viel besserer Ausgangspunkt sein, wenn man etwas stärker Angepasstes bauen möchte.

    • Wenn es beim Erstellen eigener Themes weiterhin Reibung gibt, ist unsere Arbeit noch nicht erledigt. Sag uns gern Bescheid.

  • Da in diesem Thread gerade Video-Expertinnen und -Experten unterwegs sind, frage ich mich, ob es eine Player-Implementierung gibt, die schnelles, flüssiges Scrubbing inklusive Audio ermöglicht.
    Ich meine eine Funktion ähnlich wie in Adobe Premiere, wo man die Timeline mit 16-facher Geschwindigkeit durchgehen oder anschauen kann. Vermutlich müsste man dafür so etwas wie einen 16-kHz-Mono-Audiotrack und ein 240p-Videoformat mit 1-fps-Sprites oder nur I-Frames im Voraus aggressiv laden und beim Scrubbing darauf umschalten.

    • Framegenaues oder flüssiges Scrubbing war auf der Abstraktionsebene des video-Elements schon immer schwierig.
      Eine exakte Antwort habe ich nicht, aber es könnte sich lohnen, in den Bereich WebCodecs zu schauen, wo auf niedrigerer Ebene performante Beispiele entstehen: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

  • Web Components sind großartig, und Mux macht damit tolle Dinge.

    • Ein kleines Feedback: Ihr solltet euch die Nutzung von adoptedStyleSheets ansehen. Die Unterstützung ist inzwischen sehr gut und bringt bei wiederholten Elementen Performance-Verbesserungen. Fallbacks sind ebenfalls möglich.

  • Der Code lässt sich so anpassen, dass er mit YouTube-Embeds funktioniert
    Dazu setzt man im src des YouTube-Embeds Folgendes:
    controls=0 – entfernt Player-Steuerelemente wie Wiedergabe, Pause und Lautstärke
    modestbranding=1 – minimiert das YouTube-Logo im Player
    rel=0 – verhindert, dass am Ende verwandte Videos angezeigt werden. Funktioniert nur noch so, dass nur Videos desselben Kanals gezeigt werden
    showinfo=0 – entfernt Videotitel und Uploader-Informationen. Dieser Parameter ist veraltet, aber modestbranding hilft
    fs=0 – deaktiviert den Vollbild-Button
    iv_load_policy=3 – blendet Video-Anmerkungen wie Pop-up-Hinweise aus
    Danach erkennt der Code die YouTube-Embed-URL und erstellt den Player statt mit einem video-Tag mit einem iframe. Abschließend ordnet man die Player-Steuerung der YouTube-Embed-API zu. Plyr.io hat etwas Ähnliches gemacht

  • Nur weil man etwas baut, das Winamp einigermaßen ähnelt, ist es noch lange nicht Winamp