なぜブラウザベースの動画処理ツールを構築したのか

ウェブ用の動画ツールを構築しようと決めたとき、従来の常識は明確でした：動画処理はサーバーで行うべきだ。ファイルをアップロードし、FFmpegを実行し、結果を返す。シンプルで実績があり、帯域幅、コスト、プライバシーによって深く制限されていました。

私たちは、もっと良い方法があるはずだと考えました。結局のところ、それはずっと私たちのブラウザの中にあったのです。

現状：ffmpeg.wasm

過去数年間、ffmpeg.wasmはブラウザ内動画処理の頼りになるソリューションでした。FFmpegをWebAssemblyにコンパイルすることで、FFmpegの全ツールキットにブラウザ内で直接アクセスできます。これは機能しますが、重大な欠点があります：

私たちのベンチマークでは、50MBのMP4動画を70%の品質で圧縮するのに、ffmpeg.wasmでは45〜60秒かかりました。悪くはないですが、素晴らしいとも言えません。

WebCodecs APIは、比較的新しいブラウザAPIで、ブラウザのネイティブメディアコーデックに直接アクセスできます — YouTube、Netflix、その他すべてのストリーミングプラットフォームで動画再生に使用されているものと同じです。主な利点は以下の通りです：

ただし、WebCodecsは低レベルです。デマルチプレックス、フレームごとのエンコード、コンテナフォーマット、その他すべてを自分で処理する必要があります。それは多くの配管作業です。

私たちは、WebCodecsをシンプルで人間工学に基づいたAPIでラップする軽量ライブラリ、mediabunnyを構築しました。これにより、複雑な部分が処理されます：

全体的に3〜5倍高速で、メモリ使用量が劇的に少なく、バンドルオーバーヘッドはゼロです。

パフォーマンスは素晴らしいですが、ブラウザベースの処理を本当に際立たせるのはこれです：アーキテクチャによるプライバシー。

サーバーベースのツールでは、あなたのデータを他人に委ねることになります。善意のサービスであっても、サーバーは侵害されたり、召喚されたり、誤って設定されたりする可能性があります。VideosKitでは：

これを構築することは課題なしではありませんでした：

ブラウザはランダムなファイルアクセスを提供しません。私たちはFile APIとストリーミングを使用して、ファイル全体をメモリにロードすることなく、動画をフレームごとに処理します。これには、慎重なバッファ管理とガベージコレクションの調整が必要でした。

WebCodecsはChrome 94+、Edge 94+、Safari 16.4+でサポートされています。Firefoxはバージョン130でサポートを追加しました。私たちは機能を検出し、サポートされていないブラウザにはメッセージを表示して適切にフォールバックします。

動画フレームは大きいです — 単一の4Kフレームは非圧縮で約33MBです。4Kコンテンツでもメモリ使用量を抑えるために、フレームプーリングとストリーミングパイプラインを実装しました。

ユーザーはどれくらい待つ必要があるかを知る必要があります。フレーム位置に基づいて進捗を報告し、正確なリアルタイム更新を提供するコールバックシステムを構築しました。

VideosKitとmediabunnyはどちらもオープンソースです。コードをご覧ください：

貢献、問題、フィードバックを歓迎します。

WebCodecsはまだ進化しています。AV1エンコーディング、WebGPUを活用した処理、改良されたMediaSource Extensionsにより、ブラウザベースの動画はさらに強力になるでしょう。私たちは、可能なことの限界を押し広げることに興奮しています。

まだVideosKitを試していない方は、videoskit.ccにアクセスしてください。動画の圧縮、変換、トリミング、検査をすべてブラウザで、すべて無料で。