ハクソク

世界を動かす技術を、日本語で。

HNに表示: 16年ぶりにVideo.jsを引き継ぎ、88%小型化しました

45日前原文(videojs.org)

概要

  • Video.js v10.0.0 beta が公開、全面的な再設計を実施
  • Plyr, Vidstack, Media Chrome など複数のOSSプロジェクトが協力
  • バンドルサイズ大幅削減 や カスタマイズ性向上 を実現
  • React, Typescript, Tailwind など最新技術に対応
  • 新アーキテクチャで AI連携や将来拡張 も視野に

Video.js v10.0.0 betaリリースの背景と特徴

  • Video.js v10.0.0 beta は、16年ぶりの大規模な再構築を実施
  • Plyr、Vidstack、Media Chrome 等の著名OSS開発者が共同参画
  • 合計 75,000 GitHubスター、月間数百億再生規模のエコシステム
  • 旧来の Flash→HTML5移行時代 の設計から脱却し、現代的な開発スタイルに最適化
  • AI連携や拡張 を見据えた基盤設計

バンドルサイズの劇的削減

  • デフォルトバンドルサイズを88%削減 （従来比）

  • ABR（アダプティブビットレート）機能の分離 により、用途に応じた最小構成が可能

  • React版プレイヤー ではさらに軽量化（例: Video Player [React]は18KB gzip）

  • 新設計により、 不要な機能を含まない構成 が容易に

    • 例：UI不要時は完全に除外可能、ボリューム機能も不要ならバンドルされない
    • createPlayer関数 で必要機能のみを選択

新ストリーミングエンジン「SPF」の導入

  • Streaming Processor Framework（SPF） により、用途別に最小限のストリーミングエンジンを構築
  • シンプルなHLS用途 なら、従来比19%のファイルサイズに
  • SPFエンジン単体 はHLS.js-lightの12%のサイズ（12.1KB gzip）
  • 高度な用途には従来エンジンも利用可能、 柔軟な選択肢

UIカスタマイズの進化

  • React/Web Components を活用したUIプリミティブ群を提供
  • ベータ版では 2種類のスキン （デフォルト・ミニマル）を同梱
  • shadcn/ui や Base UI、Radix 等に着想を得た設計
  • スキンの「eject」（コピー&ペーストで全コード取得）も可能、CLI対応予定
  • デザイン責任者にPlyrのSam Potts氏 を起用し、洗練された美しいUIを実現

用途別プリセットの提供

  • 動画、音声、背景動画 など、よくある用途別に最適化したプリセットを用意
  • プリセットは スキン、機能、メディア設定 の組み合わせ
  • 必要な機能のみを搭載した 最小限構成 でスタート可能
  • 教育用、ショート動画、クリエイタープラットフォーム 向けなど、今後さらに拡充予定

新アーキテクチャのメリット

  • State、UI、Media を独立したコンポーネントで設計
  • 各コンポーネントは API契約 で連携、 柔軟な拡張・交換 が容易
  • 不要な機能は完全にバンドルから除外 可能
  • パフォーマンス最適化 と 拡張性 の両立

OSS連携と今後の展望

  • Video.js, Plyr, Vidstack, Media Chrome の開発者が協力し、OSSとして再出発
  • AIによる開発支援 や 新機能追加 を見据えた設計
  • ベータ公開中につき、 フィードバック歓迎

まとめ

  • Video.js v10.0.0 beta は、現代的な開発・拡張・カスタマイズ性を大幅に向上
  • バンドルサイズ削減 と 用途別最適化 で、あらゆるWeb動画体験を刷新
  • OSSコミュニティ主導 で今後も進化予定

Hackerたちの意見

いいね！動画.jsは以前トラブルが多くてオフにしちゃったけど、この新しいバージョンを試すのが楽しみだな。

└

ありがとう！私はVideo.jsチームの一員で、ぜひライブラリを試してフィードバックをもらいたいんだ。特に、過去にv8を使ったり試したりした開発者からの意見を聞きたいな。新しいコンセプトをたくさん取り入れた新しいアプローチをしてるから、ベータ期間中に何がうまくいってるか、何がダメかを知るのにあなたのフィードバックがすごく役立つよ。

見た目がいいね。もう少し落ち着いたら試してみるつもり。ところで、最近この分野で何が起こってるか知ってる人いる？去年は色々変わった気がする。例えば、react-playerの新バージョンが出て、Muxに引き継がれたし。あと、Video.jsがMuxにスポンサーされてるのも気づいた。いろんな会社が協力してるみたいだね。

└

OPとMuxの共同創設者だから、これについては全部わかってるよ。たくさんのことが変わった。数年前にMuxがReact Playerのメンテナンスを手伝うことになったんだ。頻繁にアップデートされてなかったし、MuxはOSSプレイヤーエコシステム全体に利害関係があるからね（たとえ私たちが作ったわけじゃなくても）。Mux Video（ホスティング）はプレイヤーに依存しないから、どのプレイヤーにもサポートリクエストが来るんだ。@luwesが新バージョンに向けて作業して、Media Chromeのメディア要素をReact Playerで使えるようにしたり、開発の取り組みをまとめたりしたよ。私たちはまだ小さなプレイヤーチームだから、それは重要だった。React Playerを廃止する予定は今のところないし、エコシステムの中で特別な存在だと思うけど、video.js v10との重複はあると思う。もし特定の機能が気になるとか、足りないと感じることがあったら、ここで声を上げてほしい。VidstackやPlyrでも似たようなことがあって、最初にMuxがプロジェクトをスポンサーしたんだ。そこでRahimとSamに出会って、プレイヤーの未来について共通のビジョンを話し合ったんだよ。

昨日HLS用にv10を試してみたけど、今のところすごくいい感じだよ。

└

聞けて嬉しい！

ちょっと気になったんだけど、これをウェブコンポーネントとして配布しないのはなぜ？セマンティックなオブジェクトで、内蔵のコントロールやクロームがあるから、完璧な使い方だと思うんだけど。

└

それはウェブコンポーネントじゃないの？記事によると、すべてのReactの要素はHTMLカスタムエレメントに変換されて、クライアントサイドのJSがそれを登録する形になってるみたい。クライアントサイドのJSは、React SPAのコードバンドルに埋め込まれていても「ウェブコンポーネント」だよね？もし「なぜReactやバンドルが必要なの？minifiedのvideo.jsライブラリをスクリプトタグやES6モジュールインポートとして直接含められないの？」って言いたいなら、できると思うけど、実際には誰もそうしたくないはず。ここでの半分のポイントは、カスタムエレメントを支えるプレイヤーJSが、使ってるカスタムエレメントの組み合わせに必要なJSだけに小さくなってるからなんだ。それを実現するには、「コンパイル時」にツリーシェイキングのロジックが、あなたのビューからプレイヤーライブラリのコンポーネントへの参照を理解できる必要がある。今は、あなたのビューがReactコンポーネントのときは可能だけど、普通のHTMLにHTMLカスタムエレメントが含まれている場合はまだできない（私の知る限り）。こう考えると、あなたのビルドスクリプトやアセットパイプラインが、最終的なカスタムテーラードウェブコンポーネントを生成するウェブコンポーネント工場として機能していると言えるかもね。

└

ああ…その合理的な質問でちょっと痛いところを突かれたね。media-chrome[1]やMux Playerで、ウェブコンポーネントを作ろうとしたときに厳しい教訓を学んだよ。Reactの部分がちょっと厄介で、もっと自然なReact体験を提供するためにReactシムを作ったんだ。ウェブコンポーネントもレンダリングできたけど、まあそれ自体は良かったけど、新たな問題も生まれた。ウェブコンポーネントを選んだ理由は、フレームワーク特有のコードを書かなくて済むようにするためだったのに、結局どちらもやる羽目になった。VJS 10では、かなり合理的な中間地点に落ち着いたと思うよ。コアライブラリは「ヘッドレス」で、その上にレンダリングレイヤーがある。真のReactコンポーネントと素敵なウェブコンポーネントの利点があるね。[1] https://github.com/muxinc/media-chrome

スティーブ、おめでとう！ JW Playerにいたのはもう何年も前だけど、それ以来動画には触れてないんだ。でも、video.jsのシンプルさ（特にテーマの部分）にはいつも感心してたよ。この新しいバージョンが大成功することを願ってる！

└

おお、ザック！懐かしいね。元気にしてる？お祝いの言葉ありがとう。FOMSやカンファレンスでJWチームと話すのはいつも楽しかったよ。もし動画技術に戻りたくなったら、ここは水が温かいよ！

createPlayerのfeature-arrayアプローチは賢いね。モノリスを機能ごとのパッケージに分けるのをやったことがあるけど、一番難しかったのはその境界をどうするかだった。二つの機能は独立しているように見えるけど、実はどちらも持ちたくない状態を共有していることに気づくんだ。ここでのクロス機能の状態依存をどう扱うのか、ちょっと気になるね。

└

ここにVJSのコアコントリビューターがいるよ。私たちもその懸念を感じてるし、まだ決定的な解決策はないんだ。おそらく、何らかの代替実装や機能の拡張が必要になると思う。今は、PiPとフルスクリーンの相互関係のように、もう少しアドホックな方法で進めているところだよ（例えば、ここを見てね: https://github.com/videojs/v10/blob/main/packages/core/src/d...）。

└

AI生成のコメントはもうやめてください。あなたの投稿履歴はそれでいっぱいです。

先日、私のレガシーウェブアプリで使っているvideo.jsのサイズについて嘆いてたところなんだ。それを改善する方法を探していたんだよ。v10に移行する方法を探るのがすごく楽しみ！

└

ディスカッションや問題にメッセージを送ってね！あなたが取り組んでいることを聞きたいな。 https://github.com/videojs/v10/discussions

他のフロントエンドフレームワークのサポート予定ってあるの？もし今日、Svelteみたいなもので使いたい場合はどうすればいいの？

└

SvelteやVue、さらにはReact Nativeまでサポートすることを目指してデザインしてるよ！具体的な時期はまだわからないけど、v10のアプローチの大部分は、各フロントエンドフレームワークに最高の体験を提供することなんだ。統合がラッパーみたいに感じないことが大事で、本当にイディオマティックであることが重要なんだ。その間に、カスタム要素がいい代替手段になることを願ってるよ。ほとんどのフレームワーク、特にSvelteはそれをうまくサポートしてるし、どのフレームワークでも使いやすいようにAPIに愛を注いでるんだ。もし裏側が気になるなら、アーキテクチャ的にはTanStackと似たアプローチを取っていて、最初から共有コアを分離してるけど、将来的にRNをサポートするためにDOMも分ける一歩を加えてるんだ。

ちょっと気になるんだけど、今の時代にHLSを選ぶ人っているの？正直、あんまり詳しくないけど、長時間のストリーム（数週間）をやったことがあって、HLSだとプレイリストがかなり大きくなったのに対して、Dashだとmpdは最小限だったんだよね。

これめっちゃクールなんだけど、ReactプレイヤーがHTMLプレイヤーより小さい理由がよくわからない。サイズ比較って実際どうなってるの？