HN公開: Web ComponentsでWeb上に再構成したWinampとその他のメディアプレーヤー

 (player.style)
3 ポイント 投稿者 GN⁺ 2024-10-09 | 1件のコメント | WhatsAppで共有
  • player.style は、Media Chrome ベースの動画・音声プレーヤーテーマ集で、さまざまなWebプレーヤーやアプリフレームワークに同じ方法で適用できる
  • 好みの プレーヤーテーマ を選んだあと、プレーヤーとフレームワークを選択すると、コピー＆ペーストできるコードフローに進める
  • Video/Audio、HTML、React、Next.js、Vue、Svelte に加え、timeline thumbnails、AirPlay、Google Cast、chapters、tooltips といった条件でテーマを絞り込める
  • プレーヤーUIは HTMLとCSS だけで調整でき、Primary、Secondary、Accent などのテーマカラー設定も用意されている
  • Sutro、Instaplay、Notflix、YT、Minimal、Winamp など、既存のメディアプレーヤー体験をWeb向けテーマとして再構成し、すばやく適用できる

player.style の使い方とカスタマイズ

  • player.style は、Media Chrome で作られた 動画・音声プレーヤーテーマ を提供する
  • 対象範囲は「every web player」と「every web app framework」
  • 適用フローはシンプルな3ステップで構成される
    • 気に入ったプレーヤーテーマを選ぶ
    • 使用するプレーヤーとアプリフレームワークを選ぶ
    • 生成されたコードをコピー＆ペーストする
  • プレーヤーUIは HTMLとCSS だけで細かく調整できる
  • フィルターと設定項目には以下が含まれる
    • メディア: Video, Audio
    • フレームワーク: HTML, React, Next.js, Vue, Svelte
    • 機能: timeline thumbnails, AirPlay, Google Cast, chapters, tooltips
    • 色: Primary, Secondary, Accent

Webプレーヤーテーマギャラリー

  • Sutro: SF TVアンテナの名前に由来する、洗練されたモダンなテーマ
  • X-mas: 赤と緑のトーン、きらめく照明、年末ムードを備えた クリスマステーマ
  • Halloween: 動画プレーヤーにハロウィンの雰囲気を加えるテーマ
  • Instaplay: 人気ソーシャルメディアアプリの再生体験に着想を得た モバイルファースト テーマ
  • Sutro Audio: Sutro と同じ説明を持つオーディオテーマ
  • Notflix: 「大きな赤いN」と Los Gatos 行きの長いバスを除いた体験をほのめかすテーマ
  • Reelplay: 往年のメディアプレーヤーに着想を得た レトロメディアプレーヤー テーマ
  • Vimeonova: クラシックな Vimeo プレーヤーデザインを新しく解釈したテーマ
  • YT: 現代的で広く使われている YouTube プレーヤーへのオマージュであり、Web Components でできる限り近く再構成されている
  • Tailwind Audio: Tailwind CSS で作られたミニマルなオーディオプレーヤーテーマ
  • Demuxed 2022: Demuxed 2022 向けに作られたメディアプレーヤーテーマ
  • Microvideo: 長いコンテンツに必要な強力な再生コントロールを必要としない 短尺コンテンツ 向けのテーマ
  • Minimal: Mux Player の体験を、視聴者に必要な基本コントロール中心に絞ったシンプルなテーマ
  • Winamp: クラシックな Winamp メディアプレーヤーに着想を得たレトロテーマ

関連記事

1件のコメント

 
GN⁺ 2024-10-09
Hacker News の意見

  • 音楽だけが必要で動画ではないなら、https://webamp.org/も見る価値あり
    「コンパイル」したり、大げさに「統合」したりする必要はなく、ただ埋め込めばよく、プレイリストはアプリで生成すればよい。例：Music

    • 実装が本当に良い。望むなら動画対応も簡単に付けられそうだし、内部的には単にメディア要素を使っているのだと思う

  • このアイデアは気に入っているし、MIT ライセンスで公開してくれてありがたい
    ちょうどメディアアプリ、正確には動画編集ソフトを作っていて、以前にも Flash と HTML/JS で動画プレイヤーをいくつか作ったことがある。2015年ごろ、あるプレイヤーで Web Components を使ってみたが、ずっと苦痛だったので結局普通の JavaScript に戻った。奇妙なことに、今のメディアアプリでは動画編集タイムラインのような Web Components を使っているが、今のところかなりうまくいっている。何が変わったのか、あるいは Web のゆっくりした進化のおかげで互換性が十分に高まったのかはよく分からない
    Media Chrome のドキュメントをざっと読み、GitHub リポジトリも軽く見ただけだが、設計原則とアーキテクチャメモは気に入った。こういうものを導入するとき、特にこの種のものを自分で何度も作ってきた立場としては、拡張性とファイルサイズが一番の懸念だ。たとえば、自分のタイムラインコンポーネントを MediaController のパラダイムに合わせるのがどれほど難しいのか気になる。全部自作すれば、必要なものだけがあり、それ以上はないという利点がある。Media Chrome には自分が絶対に使わない機能も多いはずで、そのためにどれだけ不要な重さを背負うことになるのかが疑問だ。使わないコンポーネントだけでなく、使うコンポーネント内の使わない機能についても同じだ。既存の不要な機能が、より低レベルの拡張性を妨げることもある
    付け加えると、media-elements リポジトリ [1] にはライセンスファイルがない。package.json では要素も MIT とされているが、明示的な LICENSE ファイルがあると常にありがたい
    それでもかなり魅力的なライブラリだ。少なくともこれまでは、埋め込むページ側が要素をつなぎ合わせていたが、より良い抽象化が欲しいと思っていたところなので、自分のコンポーネントを media-controller のような要素で包むというアイデアは拝借しそうだ

    1. https://github.com/muxinc/media-elements
    • 2015年ごろは Web Components についてかなり楽観的で、頑固でもあったと思う。本当にうまくいってほしいと思っていたが、実際にプロダクションへ入れたのは2020年ごろになってからだった
      その間に Web Components 仕様 v2 があったが、何が変わったのかについて専門家ではない。今では Web Components をあちこちで見るようになり、特にメディアプレイヤーではよく見かける。たとえば Apple の Web プレイヤーがある
      コントローラーアーキテクチャを気に入ってくれてうれしい。初期バージョンでは、すべての要素がメディア要素を直接指す方式だったが、コントローラーが入ってかなり整理された。少なくとも私がやっていた方式と比べれば強くおすすめする
      動画編集 UI は Media Chrome ファミリーの自然な拡張だと思っている。そちらで何がもっと役に立つか、リポジトリに Issue として残してくれるとうれしい
      将来の柔軟性とサイズのために Media Chrome のようなものを導入するのをためらう気持ちは深く分かる。私なら説得されるポイントが3つある。1) 必要な UI コンポーネントだけを含められ、これはサイズ面で他の Web 動画プレイヤーとの大きな違いだ。2) アクセシビリティや今後の国際化なども含め、最も経験豊富なプレイヤー開発者たちが取り組んでいる。3) slot、CSS parts、CSS 変数の組み合わせで、非常に設定しやすいものにしようとしている
      もちろん完全なカスタムソフトウェアのファイルサイズには勝てないが、基本機能がすべて揃えばかなり近づけると思う。elements のライセンスの件を教えてくれてありがとう

  • Mux のマーケティング戦略は賢い
    動画パッケージを探している開発者が最終的に会社名に触れるように、オープンソースプロジェクトを買収したり新しく作ったりしている
    最近見た別の例は https://github.com/cookpete/react-player だ

    • ありがとう。「賢い」というのは褒めすぎかもしれない。大部分は、開発者が動画をどう使っているかを見て、その領域の問題を解決しようとしていることに近い。Next-video.dev も誇りに思っている例だ
      オープンソースプレイヤー周辺で見られる現象の一部は、いずれにせよ私たちがそうしたプロジェクトをサポートする必要がある面があるからだ。私たちはプレイヤーに依存しないので、顧客はメンテナンスが活発でないプロジェクトも含め、さまざまなオープンソースを使っている
      現在、開発者中心の動画企業の中でオープンソースに積極的に貢献しているところは非常に少ないため、私たちが恩恵を受けていると思う

  • Mux は良さそうだけど、同社が無料の動画エンコード枠を維持し続けるとは信じていないので、その上に何かを作ることはなさそう。
    ユーザー向けのオンデマンドエンコードも、リソース面では少し筋が通らない感じがする。スターターモデルは10ドルで100ドル分のクレジットを買う仕組み。全部が大きな客寄せ商品に見えるし、毎日お金を燃やしているような会社をこれ以上信用するのは難しい。むしろ少しでも課金してくれたほうがいい。エンコードが無料ではないことは分かっている。あるいは、業界の誰よりも低い価格を出しながら、どうやって事業を継続できるのかを説明するセクションがサイトにあれば、疑念をかなり減らせると思う。SaaS にはあまりに何度も痛い目に遭わされてきた。

    • これは答えとして本一冊でも書けそう。
      「業界の誰よりも低い価格を出しながら、どうやって事業を継続できるのかを説明するセクション」は本当に良いフィードバックで、ToDo リストに入れておく。絶対に必要だ。
      私たちは維持できない経済性の価格を出すつもりはないし、少なくとも維持するための明確な道筋はあるべきだ。すべてのボリューム別価格は公開されているので、クレジットのような概念を理解していれば、客寄せの後で価格変更を食らうことはないはず。規模が大きくなったときに新しい価格でユーザーを驚かせる一部の競合とは逆だ。そういうやり方は本当に嫌いだ。
      内部的にはジャストインタイムエンコードや他の高度な最適化を使って優位性がある。スケールメリットもあり、それについての記事を書く予定だ。
      ただ、顧客の認識は難しい。エンコードとそのコスト、そしてアダプティブストリーミングやユーザー生成アップロードの処理といった利点を理解している顧客もいる。多くの開発者は動画が初めてなので、MP4 を S3 にアップロードするのと同じコストだと期待する。エンコード費用がない競合を引き合いに出す人もいれば、YouTube を理由にもっと安いはずだと言う人もいる。以前の Mux はエンコード費用を請求していたため「高い選択肢」に分類されていた。そこで、経済的に維持可能なより低いエンコードレベルから始め、価値があると判断したら、より高いエンコード費用／価値のレベルを選べる新しい価格体系を作っている。一部はすでにリリース済みで、一部は予定している。
      私たちは、動画は今よりもっと多くの場所にあるべきだと考えているが、アプリを作る際の他の多くのコストと比べて、動画は本質的に高い。だからこそ、コストを下げ続け、価格体系を洗練させて、より多くのユースケースで動画を使えるようにすることが私たちの仕事だと考えている。
    • ユーザー生成コンテンツのように、エンコードが大きなコスト要因になるユースケースがあり、そうしたモデルでも Mux の上で作れるようにしたかった。
      無料エンコードを使う場合のトレードオフはここにまとめられている: https://docs.mux.com/guides/use-video-quality-levels。無料の basic エンコードでも、ストレージと配信の費用は引き続き発生する。立ち上げ時のコスト削減を助けられれば、一緒に成長できることを願っている。
      オンデマンド、つまり JIT エンコードは、実際にどれほど一貫してうまく動くかを見ると魔法のようだ。
      Mux で働いている。

  • ここにはフォーカス処理が少しおかしい部分がある。建設的な批判として受け取ってもらえればうれしいし、すべて同じ問題がある。
    動画自体をクリックすると、左右の矢印キーで動画を前後に移動できる。上下は何もしない。
    シークバーをクリックすると、左右の矢印キーが動かなくなる。代わりに上下の矢印キーが、別の時間間隔で巻き戻し／早送りを始める。
    Winamp の例や Reelplay の例にある Windows 98 風の青いバーのような空白部分をクリックすると、これらのコントロールがすべて効かなくなり、スペースバーでの再生／一時停止もできない。
    macOS の最新 Chrome で確認した。

    • 良いフィードバック。Media Chrome のリポジトリに関連する Issue がある: https://github.com/muxinc/media-chrome/issues/957
      一般に、動画を制御する「ショートカット」、各コンポーネントのアクセシビリティコントロール、ページ全体に対する一般的なアクセシビリティ上の期待が重なって、状況が少し複雑になっている。たとえば、プレイヤーにフォーカスがあるときに上下矢印を常に音量制御として扱うべきか、それともユーザーはページスクロールに使うと期待しているのでそうすべきでないのか、といった問題がある。
      いずれにせよ、この部分は今後さらに反復改善していく必要があるので、フィードバックは助かる。

  • Player.style は素晴らしい。
    前回のスタートアップで video.js のテーマを自作し始めたものの、数時間後に自分の時間を使うほどの価値はないと判断してデフォルトを使った。今後は、こうしたテーマがよりカスタマイズされたものを作る際のはるかに良い出発点になりそうだ。

    • 独自テーマを作るときにまだ摩擦があるなら、私たちの仕事は終わっていない。教えてほしい。

  • このスレッドに動画の専門家がいるついでに、音声付きの高速で滑らかなシークを可能にするプレイヤー実装があるのか気になっている。
    Adobe Premiere でタイムラインを16倍速でざっとなぞったり見たりできるような機能のことだ。おそらく 16kHz のモノラル音声トラックと、1fps のスプライトまたは I フレームだけの 240p 動画フォーマットのようなものを事前に積極的にロードしておき、シーク時にそれへ切り替える必要がありそうだ。

    • フレーム単位で正確、または滑らかなシークは、video 要素の抽象化レベルでは常に難しかった。
      正確な答えはないが、より低レベルで高性能な例が作られている WebCodecs の領域を見てみるとよさそう: https://developer.mozilla.org/en-US/docs/Web/API/WebCodecs_A...

  • Web Components は素晴らしく、Mux はそれで見事な仕事をしている。

    • 小さなフィードバックを一つ: adoptedStyleSheets の利用を検討してみるとよさそう。今ではサポートが非常に充実しており、繰り返し要素でパフォーマンス向上をもたらす。フォールバックも可能だ。

  • コードを YouTube 埋め込みと連携するように調整できる
    YouTube 埋め込みの src に次を設定すればよい
    controls=0 – 再生、一時停止、音量などのプレイヤーコントロールを削除する
    modestbranding=1 – プレイヤー内の YouTube ロゴを最小限にする
    rel=0 – 最後に関連動画を表示しないようにする。同じチャンネルの動画だけを表示する方式でのみ動作する
    showinfo=0 – 動画タイトルとアップロード者情報を削除する。このパラメータは廃止されたが、modestbranding が役に立つ
    fs=0 – 全画面ボタンを無効にする
    iv_load_policy=3 – ポップアップ通知のような動画アノテーションを隠す
    その後、コードで YouTube 埋め込み URL を検出し、video タグの代わりに iframe でプレイヤーを作ればよい。最後にプレイヤーコントロールを YouTube 埋め込み API にマッピングすればよい。Plyr.io も同様のことをしていた

  • Winamp にある程度似たものを作ったからといって、Winamp になるわけではない