- 16年ぶりに全面的に書き直された Video.js v10 は、バンドルサイズを88%削減し、現代的な開発環境に合わせた構造へと生まれ変わった
- React・TypeScript・Tailwind を第一級でサポートし、美しいデフォルトUI と AIフレンドリーなドキュメント構造 を提供
- 新しい Streaming Processor Framework(SPF) により、必要な機能だけを組み合わせられる モジュール型ストリーミングエンジン を実装し、HLS.js比で12%水準まで軽量化を達成
- コンポジションベースのアーキテクチャ と React/Web Components スキンシステム により、UIと機能を自由に置き換え・削除可能
- 2026年の正式リリースを目標としており、AI協調開発と拡張可能なプリセットエコシステム を通じて次世代オープンソースメディアプラットフォームへと発展中
Video.js v10 ベータ概要
- Video.js v10.0.0 ベータは、16年ぶりの全面的な再設計であり、Video.js だけでなく Plyr, Vidstack, Media Chrome など複数のオープンソースプロジェクトの協業成果でもある
- 合計 7万5千 GitHub スター と、毎月数十億回再生規模のエコシステムが参加しており、現代的な開発方式と AI支援開発環境 を考慮した構造として新たに設計された
- 主な目標は バンドルサイズ88%削減、React・TypeScript・Tailwind の第一級サポート、美しいデフォルトUI、AIフレンドリーなドキュメント構造 の提供である
バンドルサイズと性能改善
- 基本の Video.js v10 プレーヤーは、v8 比で 基本バンドルサイズが88%減少し、ABR(Adaptive Bitrate) 機能を除いても 66%減少
- 例: v8 基本 260.5kB(minified) → v10 HTML ビデオプレーヤー 97.4kB(minified)、React 版は 62.0kB
- 新しい Streaming Processor Framework(SPF) の導入により、必要な機能だけを組み合わせられる モジュール型ストリーミングエンジン を構成可能
- 単純な HLS 利用時、v10+SPF は v8+VHS 比で ファイルサイズ19%水準
- SPF エンジン自体は HLS.js-light の12%サイズ(38.5kB minified) で、単純な ABR 処理に最適化されている
- SPF は HLS.js, Shaka, dash.js など既存エンジンと すべて互換性 があり、複雑な DRM・広告機能が不要な場合は 極限まで軽量化 できる
コンポジションベースのアーキテクチャ
- v10 は State, UI, Media を分離したコンポーネント構造を採用し、各要素を独立して置き換え・削除できる
createPlayer() 関数は features 配列を受け取り、必要な機能だけを含める- 例: オーディオ機能が不要なら
volume, mute コードはバンドルに含まれない
- UI を削除したい場合は単にスキンを読み込まなければよく、不要なコードを完全に除外可能
- 最小構成の React 例は 5kB未満(gzipped) で動作し、単純な再生/一時停止ボタンのみを含む
UIカスタマイズとスキンシステム
- v10 は React と Web Components ベースのスキンシステム を提供し、Base UI, Radix などに着想を得た unstyled UI primitives 構造を採用
- 各 UI コンポーネントは単一の HTML 要素を出力するため、直接制御 が可能
- 既存の v8 では CSS 擬似要素で制御していたタイムラインハンドルが、v10 では 実際の DOM 要素 として提供され、スタイリングが簡素化
- ベータには2種類のスキンを同梱
- 基本スキン: 半透明(frosted)の美学、滑らかなアニメーション
- ミニマルスキン: カスタマイズ向けの簡潔な基本形
- スキンの エラーダイアログデザイン も統一され、視覚的完成度が向上
プリセットシステム
- v10 は 用途別プリセット(preset) の概念を導入し、スキン・機能・メディア構成を組み合わせた すぐに使えるプレーヤーテンプレート を提供
- Video preset: 一般的なWeb動画向け
- Audio preset: ポッドキャストなどオーディオ専用
- Background video preset: 背景動画向け、コントロール・オーディオを削除
- プリセットは素早い出発点を提供しつつ、すべての構成要素を置き換え可能 で、完全な拡張性を維持
- 今後 教育向け、ショートフォーム、クリエイタープラットフォーム向け プリセットを追加予定
AIフレンドリーな設計
- v10 は AIエージェントと共に開発できる構造 を目指している
- 非抽象化コンポーネント と unstyled UI primitives によりコード理解度を向上
- ドキュメント探索効率のための llms.txt ファイルを提供し、フレームワーク別バージョンも含む
- すべてのドキュメントを Markdown 形式 で提供し、AI が不要な HTML コンテキストなしで直接アクセス可能
- リポジトリ内の AIスキルセット を通じて、今後ユーザー開発支援を予定
ベータ利用案内
- API はまだ安定化前 であり、正式リリース前まで一部インターフェースが変更される可能性がある
- 現時点では 基本的なWebサイト再生機能中心 で、アクセシビリティ・字幕・多様なフォーマットには対応可能だが、設定メニューなどは未実装
- GitHub Issues および Discord フィードバック を積極的に収集中
- 既存バージョン利用者には、移行ガイド公開後の移行を推奨
今後のロードマップ
- 2026年半ばの正式リリース(GA) を目標
- Plyr, Vidstack, Media Chrome 水準の機能同等性を確保予定
- 広告機能サポート は 2026年下半期を計画
- 移行ガイドおよび追加プリセット を提供予定
1件のコメント
Hacker Newsのコメント
念のため気になる人向けに言うと、このウェブサイトのシンタックスハイライトのカラーテーマは「gruvbox」
個人的にとても気に入っているが、これを突き止めるのにかなり時間がかかった
gruvbox GitHubリンク
自分はvideo.jsを使ったことがないのだが、サイトや広告はすでに詳しい人向けのように感じた
読みながら気になったのは、これがHTML videoタグと何が違うのかという点。単にコントローラーが違うだけ？
videoタグは最近かなり良くなっているが、Video.jsはブラウザ間での一貫したスタイリング、高度な機能（分析、DRM、360度動画など）、**さまざまなストリーミング形式のサポート（HLS、DASHなど）**といった点で差別化されている
結局のところvideoタグでも実装はできるが、そうしていくと最終的にはVideo.jsのようなものを自作することになる
安定したプレーヤーやストリーミング機能が必要ならVideo.jsを使うのがよい
参考までに、自分はジョージア向けのTV放送プレーヤーを作ったことがあり、2009年のLGスマートTVから最新ブラウザまで対応した
これが重要なのは動的ビットレート調整のため。キャッシュ効率も高くなる
WebVTTについて、最近状況が変わったのか気になる
以前字幕レンダリングをカスタマイズしようとしたが、あまりにも難しかった
なぜこれをWeb Componentとして配布しなかったのか気になる
自分には完璧なユースケースに思える — 意味のあるオブジェクトに組み込みコントロールがあるわけだから
最終的にはReact向けshimを作って解決したが、それがまた別の問題を生んだ
VJS 10ではheadlessコア + レンダリングレイヤー構造で折衷案を見つけた
そのおかげでReactコンポーネントとWeb Componentの両方をサポートしている
media-chrome GitHubリンク
Shadow DOMのバグやフレームワーク間の互換性のせいで、結局プレーヤー本体より環境設定に多くの時間を使うことになる
ほとんどのユーザーはそんなことを気にしない。ただJSライブラリ + きれいなAPIのほうがずっとよいと思う
ただしReactを使う理由は、tree-shakingのおかげで必要なコードだけを含められるから
通常のHTMLではまだそうした最適化が難しいため、ビルドパイプラインが一種のWeb Component生成器の役割を果たしている
Plyrを使っていた自分のオーディオプレーヤーをVideo.jsに置き換えようとしたが、デフォルト設定ではいくつか機能差があった
1倍速未満の再生速度がない、モバイルで音量調整ができない、シークボタンがない、色のカスタマイズが難しい、デモが少ないなど
現在はPlyrなどとの**機能同等性(feature parity)**を目標にしており、GA時点（年半ば）を目指している
自分は動画ホスティングには詳しくないが、HTML5動画プレーヤーを使ったことはある
サーバー側で動画チャンクを直接配信するエンドポイントを作る必要があるのか気になる
ffmpegで2MB単位に分割するとしたら、それをどこに置くのがよいのだろう？ CDN？ 自前サーバー？
Video.jsが最もスムーズに動くには、どんな構成が最適だろう？
Video.jsと相性がよく、LG TVでもタグベース再生が可能
サーバーがRangeリクエストをサポートしていれば、ブラウザが勝手に処理してくれる
自分はDO Spacesのようなオブジェクトストレージ + CDNの組み合わせを使っているが、うまく動いている
エンコードとセグメント分割を同時に処理する必要がある（例: ffmpegのdash formatter）
音声と映像のセグメント長を合わせるにはGOP計算機が便利
一般的には高品質な元データから複数解像度にエンコードした後、HLS/DASHマニフェストとともにS3のような場所へアップロードする
プレーヤーはマニフェストURLひとつで必要なすべてのリソースを見つけにいく
ブログ記事が本当によく書けていた
読者を専門家として尊重する説明の仕方が印象的だった。こういう製品発表がもっと増えてほしい
Steveおめでとう！
昔JW Playerで働いていたとき、Video.jsのシンプルさとテーマシステムに感銘を受けた
今回のバージョンも大きな成功を収めてほしい
FOMSやいろいろなカンファレンスでJWチームと話したのは楽しかった
動画技術は今でも熱い分野だから、いつでも戻ってきてほしい
88%という数字には驚いた
最大の改善ポイントが何だったのか気になる — おそらくプラグインシステムではないかと思う
リライトの過程で主要な統合機能が壊れなかったのかも知りたい
リライト過程でのアーキテクチャの変化と、以前のVideo.js設計と比べたトレードオフが何だったのか気になる