ファイルはデバイスから出ません

最近、ブラウザ内で完全に動作し、FFmpegコアを搭載した動画変換ツールという小さなユーティリティのコーディングに時間を費やしました。その機能をテストするため、16GB RAMを搭載したMacBook Air M3をテスト機として使い、Google Chrome上で直接古いAVIファイルをMP4に変換してみました。

得られた結果は面白く（笑）、技術的にも興味深いものでした。ストップウォッチは正確に747.44秒（12.5分強）で止まり、発熱が少ないことで有名なM3チップにより、アルミニウム製の筐体が触ってわかるほどに熱くなりました。

では、なぜ現在市場で最も強力なチップの一つを搭載したコンピュータが、単に動画のフォーマットを変更するだけで12分以上も「汗をかく」必要があったのでしょうか？ 本記事では、このプロセスを支える技術的な仕組みを解剖し、「そんなに遅いのであれば、なぜブラウザベースの処理ツールが必要なのか？」という究極の疑問にお答えします。

1. 最初のボトルネック：RemuxとTranscode

テストにこれほど時間がかかった最大の理由は、マシンではなく、元のファイルにありました。私が選んだファイルは、DivXやXvidのような古い圧縮規格（コーデック）を使用した古いAVIフォーマットでした。

動画処理の世界では、2つの重要な概念を区別する必要があります：

• Remux（コピー - 非常に高速）： 元の動画がすでにH.264のような最新のコーデックを使用している場合、FFmpegは動画と音声の「コア」を抽出し、新しいMP4の「ラッパー」に詰め込むだけです。このプロセスは基本的にあるフォルダから別のフォルダにデータをコピーするようなもので、わずか数秒しかかかりません。
• Transcode（DecodeとEncode - 非常に低速）： 私のAVIファイルはMP4と互換性のない時代遅れの規格を使用していたため、FFmpegは「ゼロから再構築」することを余儀なくされました。古い動画のすべてのフレームをDecodeし、その膨大なフレームの山を最新のH.264 / H.265規格にEncodeする必要があったのです。このピクセルごとの処理は、CPUに信じられないほどの負荷をかけます。

2. ブラウザにおけるWebAssembly (WASM) の現実

...

ウェブにおけるマルチメディア処理は急速な進歩を遂げています。WebCodecs APIとWebAssembly（WASM）の登場により、専用ハードウェアを活用したクライアントサイドでの高負荷な動画処理が、ついに現実のものとなりました。

しかし、理論と実践は別物です。この技術は実際のところどう機能するのでしょうか？それを確かめるため、私は高負荷なストレステストを実施しました。自作の動画圧縮ツールを使用し、すべてブラウザ上で完結させた状態で、300MBを超える1080pの動画ファイルを処理させました。その結果は、現代のブラウザがデバイスのハードウェアとどのように相互作用するのかについて、非常に興味深い技術的教訓を与えてくれました。

1. 「実環境」でのテスト設定

全てのアプリを閉じ、RAMをクリアにしたような無菌状態のベンチマーク環境ではなく、私たちが日常的に行っている一般的な作業環境と全く同じ条件でテストを実行することにしました。

• テスト環境ブラウザ： Chrome バージョン 150.0.7871.187 (Official Build) (arm64)
• デバイス： MacBook Air M3、16GB RAM (ファンレス)
• マルチタスク環境： ブラウザでは他の作業タブが5〜6個開かれており、サブモニターではFirefox（Slackを使用）が同時に稼働。
• 入力データ： Computerphileチャンネルの非常に高精細な学術的動画（"How AI 'Understands' Images (CLIP)"）。再生時間：18分。フォーマット：MP4 1080p。元のファイルサイズ：327MB。

このテストの目的は、16GBのユニファイドメモリがマルチタスク負荷により激しく共有されている状態で、WebCodecs APIがハードウェア・アクセラレーションをいかに効率的かつ安定して利用できるかを確認することでした。

2. 処理フェーズ：ハードウェア・アクセラレーションの威力

ファイルをツールに読み込ませて処理を開始した直後から動作は非常にスムーズで、開いている他のChromeタブにラグやつっかかりが生じることは全くありませんでした。

これこそが、現代のフォーマット（MP4など）に対するWebCodecsのキラー機能です。CPUに依存したソフトウェア経由の動画エンコード処理（これは簡単にブラウザをフリーズさせます）を行う代わりに、WebCodecs APIはコンピュータの専用メディアエンジン（Media Engine）を直接呼び出し、エンコードおよびデコードのタスクを処理します。

ファンレス設計であるため、Mac M3の底面全体のシャーシは処理中かなり熱くなりました。これは、ブラウザ環境とハードウェア・アクセラレータ間でデータバッファを絶え間なくシャッフルするため、ハードウェア（特にメディアエンジン）が限界まで駆動していたことを示す明確な物理的証拠です。

...