Video.js v10 - 88%小さくなったオープンソース動画プレーヤー

 (videojs.org)
13 ポイント 投稿者 GN⁺ 2026-03-25 | 1件のコメント | WhatsAppで共有
  • 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件のコメント

 
GN⁺ 2026-03-25
Hacker Newsのコメント

  • 念のため気になる人向けに言うと、このウェブサイトのシンタックスハイライトのカラーテーマは「gruvbox」
    個人的にとても気に入っているが、これを突き止めるのにかなり時間がかかった
    gruvbox GitHubリンク

    • ちなみにこのウェブサイトが何の技術で作られているか知っている人いる？ デザインとUIが本当に気に入った
    • 参考までに、このテーマはVSCodeでも使える

  • 自分はvideo.jsを使ったことがないのだが、サイトや広告はすでに詳しい人向けのように感じた
    読みながら気になったのは、これがHTML videoタグと何が違うのかという点。単にコントローラーが違うだけ？

    • もっともな指摘。サイトでもその点をもっと明確に説明する必要がある
      videoタグは最近かなり良くなっているが、Video.jsはブラウザ間での一貫したスタイリング、高度な機能（分析、DRM、360度動画など）、**さまざまなストリーミング形式のサポート（HLS、DASHなど）**といった点で差別化されている
      結局のところvideoタグでも実装はできるが、そうしていくと最終的にはVideo.jsのようなものを自作することになる
    • すべての環境でvideoタグがきちんと動くわけではない。ブラウザごとにエッジケースが多い
      安定したプレーヤーやストリーミング機能が必要ならVideo.jsを使うのがよい
      参考までに、自分はジョージア向けのTV放送プレーヤーを作ったことがあり、2009年のLGスマートTVから最新ブラウザまで対応した
    • ほとんどのブラウザはHLSやDASHをサポートしていない
      これが重要なのは動的ビットレート調整のため。キャッシュ効率も高くなる

  • WebVTTについて、最近状況が変わったのか気になる
    以前字幕レンダリングをカスタマイズしようとしたが、あまりにも難しかった

  • なぜこれをWeb Componentとして配布しなかったのか気になる
    自分には完璧なユースケースに思える — 意味のあるオブジェクトに組み込みコントロールがあるわけだから

    • いい質問。以前media-chromeとMux PlayerをWeb Componentとして作ろうとして、React統合の問題で苦労した
      最終的にはReact向けshimを作って解決したが、それがまた別の問題を生んだ
      VJS 10ではheadlessコア + レンダリングレイヤー構造で折衷案を見つけた
      そのおかげでReactコンポーネントとWeb Componentの両方をサポートしている
      media-chrome GitHubリンク
    • Web Componentは見た目は魅力的だが、実際にはスタイリングとSSRの問題でかなり時間を取られる
      Shadow DOMのバグやフレームワーク間の互換性のせいで、結局プレーヤー本体より環境設定に多くの時間を使うことになる
      ほとんどのユーザーはそんなことを気にしない。ただJSライブラリ + きれいなAPIのほうがずっとよいと思う
    • 実際にはReactコードがHTML Custom Elementsにコンパイルされるので、広い意味ではすでにWeb Componentとも言える
      ただしReactを使う理由は、tree-shakingのおかげで必要なコードだけを含められるから
      通常のHTMLではまだそうした最適化が難しいため、ビルドパイプラインが一種のWeb Component生成器の役割を果たしている

  • Plyrを使っていた自分のオーディオプレーヤーをVideo.jsに置き換えようとしたが、デフォルト設定ではいくつか機能差があった
    1倍速未満の再生速度がない、モバイルで音量調整ができない、シークボタンがない、色のカスタマイズが難しい、デモが少ないなど

    • 良いフィードバック。これらはIssue登録する予定
      現在はPlyrなどとの**機能同等性(feature parity)**を目標にしており、GA時点（年半ば）を目指している

  • 自分は動画ホスティングには詳しくないが、HTML5動画プレーヤーを使ったことはある
    サーバー側で動画チャンクを直接配信するエンドポイントを作る必要があるのか気になる
    ffmpegで2MB単位に分割するとしたら、それをどこに置くのがよいのだろう？ CDN？ 自前サーバー？
    Video.jsが最もスムーズに動くには、どんな構成が最適だろう？

    • 単にHLSに変換すればよい。1〜2秒単位で自動的にチャンク化され、nginxで静的ファイルとして配信できる
      Video.jsと相性がよく、LG TVでもタグベース再生が可能
    • 実行時のバージョン切り替え（ABR）が不要なら、手動でチャンク化する必要もない
      サーバーがRangeリクエストをサポートしていれば、ブラウザが勝手に処理してくれる
      自分はDO Spacesのようなオブジェクトストレージ + CDNの組み合わせを使っているが、うまく動いている
    • ただしチャンクはIDRキーフレームで始める必要があるので、単純ではない
      エンコードとセグメント分割を同時に処理する必要がある（例: ffmpegのdash formatter）
      音声と映像のセグメント長を合わせるにはGOP計算機が便利
      一般的には高品質な元データから複数解像度にエンコードした後、HLS/DASHマニフェストとともにS3のような場所へアップロードする
      プレーヤーはマニフェストURLひとつで必要なすべてのリソースを見つけにいく
    • MPE-DASHも検討の価値がある

  • ブログ記事が本当によく書けていた
    読者を専門家として尊重する説明の仕方が印象的だった。こういう製品発表がもっと増えてほしい

  • Steveおめでとう！
    昔JW Playerで働いていたとき、Video.jsのシンプルさとテーマシステムに感銘を受けた
    今回のバージョンも大きな成功を収めてほしい

    • 久しぶりだね Zach! 会えてうれしい
      FOMSやいろいろなカンファレンスでJWチームと話したのは楽しかった
      動画技術は今でも熱い分野だから、いつでも戻ってきてほしい

  • 88%という数字には驚いた
    最大の改善ポイントが何だったのか気になる — おそらくプラグインシステムではないかと思う
    リライトの過程で主要な統合機能が壊れなかったのかも知りたい

  • リライト過程でのアーキテクチャの変化と、以前のVideo.js設計と比べたトレードオフが何だったのか気になる