ブラウザ動画処理パフォーマンスベンチマーク：FFmpeg WASM vs WebCodecs vs ネイティブ

ブラウザ動画処理のパフォーマンス主張は大抵 2 種類：「十分速い、信じてくれ」か「WASM はネイティブより 2 倍遅い」。どちらも役に立たない。この記事は実際のハードウェアでの実際のデータで、方法論と生データを添えて、ブラウザがワークロードを処理できるか自分で判断できるようにする。

テスト構成

ハードウェア：

• Mac：MacBook Pro M2 Pro（12 コア）、32GB RAM、macOS 14.5
• Windows：ThinkPad X1 Carbon Gen 11（Intel i7-1370P、14 コア）、32GB RAM、Windows 11 23H2
• ミッドレンジ：Acer Aspire 5（Ryzen 5 5500U、8GB RAM）、Windows 11

ブラウザ（すべて 2026 年 7 月時点の最新安定版）：

• Chrome 127
• Firefox 127
• Safari 17.5

ワークロード：

1. 1080p HLS → MP4 リマックス——30 分動画、300 TS セグメント、約 500MB
2. 4K HLS → MP4 リマックス——30 分動画、300 TS セグメント、約 2.5GB
3. 8K HLS → MP4 リマックス——10 分動画、100 TS セグメント、約 4GB
4. デコード + フレーム抽出（1080p、毎秒 1 フレーム、1800 フレーム）——WebCodecs の記事 で説明
5. DASH → MP4 リマックス——#1 と同じ動画だが DASH ソース（TS デマルチプレクス不要）

テスト手法：

• ネイティブ FFmpeg（CLI、ベースライン）——ffmpeg -f concat -safe 0 -i list.txt -c copy -f mp4 out.mp4
• FFmpeg WASM（シングルスレッド）——@ffmpeg/ffmpeg 0.12.x、pthreads なし
• FFmpeg WASM（マルチスレッド）——@ffmpeg/ffmpeg 0.12.x、CORE_THREADS=8
• WebCodecs + Worker——デコードワークロードのみ、リマックスはしない

各テストは 5 回実行、中央値を報告。すべてのシナリオでばらつきは 5% 未満。

結果：1080p HLS → MP4 リマックス（30 分動画）

結論： マルチスレッド FFmpeg WASM はネイティブの約 2-3 倍、シングルスレッドの 3-4 倍。ミッドレンジハードウェアではシングルスレッド FFmpeg WASM は 1080p でギリギリ使える（30 分を 180 秒 = リアルタイムの 0.16 倍）。マルチスレッドは問題なし（65 秒 = リアルタイムの 0.036 倍）。

結果：4K HLS → MP4 リマックス（30 分動画、2.5GB）

結論： 4K リマックスはシングルスレッド FFmpeg WASM が破綻する境界点。ミッドレンジハードウェア（8GB）ではメモリ圧力でクラッシュ——WASM の単一インスタンスメモリ上限は 2-4GB、セグメントバッファ + デコード状態を加えると超える。マルチスレッドはハイエンドハードウェアで 4K を処理可能、ただしネイティブより 2-3 倍遅い。

ミッドレンジでのクラッシュこそ見る価値がある部分。チャンク処理（一度に N セグメント処理、OPFS に書き込み、メモリ解放）しても、4K TS デマルチプレクスは大量の作業メモリを必要とする。修正は OPFS ストリーミングモード——出力全体をメモリに載せないこと。

結果：8K HLS → MP4 リマックス（10 分動画、4GB）

結論： 2026 年時点で FFmpeg WASM は 8K を処理できない。4GB の単一インスタンスメモリ上限がハードな壁。チャンクストリーミングでも、8K HEVC TS デマルチプレクスは PTS 再整列のために複数の 100MB+ セグメントを同時に保持する必要がある。

これは既知の制限。提案中の WASM memory64 仕様が 64 ビットアドレッシングに引き上げるが、2026 年時点で Chrome の flag の後ろにあり、Firefox/Safari にはない。

結果：DASH リマックス（TS デマルチプレクスなし）

同じ 1080p/4K コンテンツだが DASH ソース（fMP4 セグメント、デマルチプレクス不要）：

結論： DASH はデマルチプレクスステップがないのでずっと速い——リマックスの記事 で理由を説明。純 JS 結合（FFmpeg を完全に使わない）は DASH で可能、メモリ帯域幅の限界近くまで走る。

これが FlowPick の DASH パスが HLS パスより速い理由——HLS は MPEG-TS をデマルチプレクスする必要、DASH はない。

結果：デコード + フレーム抽出（30 分 1080p、1800 フレーム）

結論： WebCodecs + worker プールがブラウザで最速の選択肢——ハイエンドハードウェアでネイティブの 2 倍以内。ハードウェアアクセラレーションが本当に効く。ミッドレンジハードウェアでは FFmpeg WASM マルチスレッドが WebCodecs 単一 worker と同等——Ryzen 5 5500U の GPU が弱いため。

worker プールのスケーリングが重要：4 worker は 1 worker より約 2.5 倍速い（GPU の競合でサブリニア）。8 worker はあまり役立たない——GPU は 4-6 の並発デコードで飽和する。

結果：ブラウザ比較（Mac M2、1080p リマックス）

結論： Chrome がすべての選択肢を走らせられる唯一のブラウザ。Firefox は WASM pthreads と WebCodecs の両方を欠く（2026 年半ばで WebCodecs はまだ flag の後ろ）。Safari は WebCodecs を持つが codec サポートが限定（AV1 なし、VP9 限定）。

これが FlowPick が Chrome を推奨する理由——v1.0.0 リリースノート を参照。

メモリ使用

ピークメモリ（Chrome 127、Mac M2、1080p リマックス）：

4K リマックスのピークメモリは約 2 倍の 500MB（FFmpeg WASM マルチスレッド）——ブラウザタブの 2GB ソフト上限内だが、近いので他のタブを閉じる必要があるかも。

メモリプロファイルは UX に影響する。4K リマックスが 8GB マシンでタブをクラッシュさせるのは最悪の体験。FlowPick のチャンク処理（一度に 50 セグメント処理、OPFS に書き込み、メモリ解放）は 4K のピークメモリも 300MB 以内に抑える。

ストリーミングダウンロードのベンチマーク

セグメント自体をどれだけ速くダウンロードできるか？ これはネットワークがボトルネックの部分。

テスト：300 セグメント、各約 1.7MB、計 500MB、CloudFront CDN から。

結論： 6-8 並列接続がスイートスポット。それを超えると CDN が IP ごとにレート制限を開始。FlowPick はデフォルト 6。

「実効帯域幅」は CDN で制限され、ブラウザで制限されない。並列を無限に増やしても CDN が許可する上限を超えられない。

方法論の詳細

ウォームアップ： 各テストは 2 回実行、最初は破棄（WASM コンパイル、JIT ウォームアップなど）。

電源： ラップトップは電源接続、パフォーマンスモード。バッテリーモードでは Mac が約 30%、Windows が約 50% クロックダウン。

他のタブ： なし。バックグラウンドタブは CPU/メモリを競合する。

サーマル： すべてのラップトップは冷却パッドの上に配置。熱スロットリングは実在する——アクティブ冷却なしで継続的な 4K リマックスを 5 分続けると 15-20% 落ちる。

FFmpeg パラメータ： -c copy -f mp4 -movflags +faststart でリマックス。フィルタなし、トランスコードなし。

WASM バージョン： @ffmpeg/core 0.12.10、マルチスレッド版は CORE_THREADS=8。SharedArrayBuffer サポートのための COEP/COOP ヘッダーを正しく設定。

これらの数字が何を意味するか

1080p コンテンツ（最も一般的）： ブラウザは対応可能。FFmpeg WASM マルチスレッドは 30 分 1080p を 22-65 秒、ハードウェアによる。WebCodecs が使えればさらに速い。ネイティブは 2-3 倍速いがインストールが必要。

4K コンテンツ： ハイエンドハードウェア（16GB+ RAM、最近の CPU）ではブラウザが対応可能。ミッドレンジハードウェアは苦戦。チャンク処理が必須。

8K コンテンツ： 2026 年のブラウザは対応不可。memory64 WASM を待つか、ネイティブを使う。

デコード集約型（フレーム抽出、解析）： WebCodecs + worker プールが明確な勝者。良いハードウェアでネイティブの 2 倍以内。

広範な codec サポート： FFmpeg WASM。WebCodecs はブラウザがサポートする codec に限定（H.264、H.265、VP9、AV1——ブラウザごとに注意点あり）。

私の見解：ブラウザは 90% のシナリオで十分

「ブラウザは本物の動画処理ができない」という言い分は時代遅れ。1080p リマックスとデコード——実際の使用の大部分をカバー——は現代ハードウェアで Chrome がネイティブの 2-3 倍以内で処理。十分速い。数秒の遅延の差（30 分動画で数秒余分に待つ）は、ワークフローの差（インストール不要、PATH 設定不要、FFmpeg インストール不要）に比べれば重要ではない。

残り 10%——ミッドレンジハードウェアでの 4K、どこでも 8K、珍しい codec——はまだネイティブが必要。それでいい。道具は仕事に合わせる。

FlowPick の賭け：ブラウザで 90% のシナリオを最適化し、残り 10% には「yt-dlp を使って」と提案。FlowPick vs. yt-dlp 比較 でいつどちらを使うかを説明。

参考資料

• FFmpeg WASM ドキュメント——セットアップとスレッド設定
• WebCodecs ブラウザサポート——互換性テーブル
• Memory64 提案——WASM の 4GB メモリ上限を引き上げる提案

まとめ

ブラウザ動画処理は 1080p ワークロードでは現代ハードウェアで実行可能、4K はハイエンドハードウェアで実行可能。8K は WASM が memory64 をリリースするまで不可。FFmpeg WASM マルチスレッドが最良の汎用ツール。WebCodecs + worker はデコード集約型タスクでより速いが codec 制限あり。

ここでの方法論は再現可能——テストファイルは参考資料にリンク、FFmpeg パラメータは記載、ハードウェアは指定。異なるワークロードなら、同じパターンで自分でテストを。

これらの数字を支える実装パターンは、WebCodecs の記事 と リマックスの記事 で。何を処理できるかの法的考慮は、ストリーミングダウンロードの合法性ガイド で。

おすすめ記事

• WebCodecs + Web Workers + OPFS：ブラウザ動画処理実戦——ここでテストした実装パターン
• ブラウザでの動画リマックス：fMP4、ISOBMFF、トランスコードしない理由——リマックスがなぜ速く、トランスコードがなぜ速くないか
• FlowPick はどうやってブラウザだけで数百の動画セグメントを 1 つの MP4 にまとめるのか——FlowPick の具体的な実装
• FlowPick vs. yt-dlp——ブラウザかネイティブかの選択の時期
• HLS ディープ：暗号化、マルチトラック、覚えておくべき EXT-X タグ——ここでベンチマークした HLS フォーマット
• FlowPick v1.1.0：より賢いメディア検出——大きなファイルのチャンク処理を追加したバージョン