WebCodecsをマスターする：時間的ノイズリダクションによるビデオ品質の向上

ウェブベースのビデオコミュニケーション、ストリーミング、リアルタイムアプリケーションの世界では、品質が最も重要です。世界中のユーザーは、ビジネス会議、ライブイベントの視聴、リモートサービスとの対話など、どのような状況でも鮮明でクリアなビデオを期待しています。しかし、ビデオストリームはしばしば、持続的で邪魔なアーティファクトであるノイズに悩まされます。このデジタルノイズは、しばしばざらざらした、または静的なテクスチャとして見え、視聴体験を低下させ、驚くべきことに帯域幅の消費を増加させる可能性があります。幸いなことに、強力なブラウザAPIであるWebCodecsは、開発者にこの問題に正面から取り組むための前例のない低レベルの制御を提供します。

この包括的なガイドでは、特定の、影響の大きいビデオ処理技術である時間的ノイズリダクションにWebCodecsを使用する方法を深く掘り下げていきます。ビデオノイズとは何か、なぜそれが有害なのか、そしてVideoFrameオブジェクトを活用してブラウザで直接フィルタリングパイプラインを構築する方法を探ります。基本的な理論から実践的なJavaScript実装、WebAssemblyによるパフォーマンスの考慮事項、そしてプロフェッショナルグレードの結果を達成するための高度な概念まで、すべてをカバーします。

ビデオノイズとは何か、そしてなぜそれが重要なのか？

問題を解決する前に、まずそれを理解しなければなりません。デジタルビデオにおいて、ノイズとはビデオ信号の輝度や色情報のランダムな変動を指します。これは、画像キャプチャおよび伝送プロセスの望ましくない副産物です。

ノイズの原因と種類

• センサーノイズ： 主な原因です。低照度条件下では、カメラセンサーは入力信号を増幅して十分に明るい画像を生成します。この増幅プロセスは、ランダムな電子的変動も増幅し、目に見える粒子感（グレイン）を生じさせます。
• 熱ノイズ： カメラの電子機器によって発生する熱が電子のランダムな動きを引き起こし、光量とは無関係なノイズを生成することがあります。
• 量子化ノイズ： アナログからデジタルへの変換および圧縮プロセス中に導入され、連続的な値が限られた離散レベルのセットにマッピングされる際に発生します。

このノイズは通常、ガウスノイズとして現れ、各ピクセルの強度がその真の値の周りでランダムに変動し、フレーム全体に微細でちらつくような粒子感を生み出します。

ノイズの二重の影響

ビデオノイズは単なる見た目の問題ではありません。それは重大な技術的および知覚的な結果をもたらします：

1. ユーザー体験の低下： 最も明白な影響は視覚的な品質です。ノイズの多いビデオはプロフェッショナルに見えず、気を散らし、重要な詳細を識別するのを困難にする可能性があります。テレビ会議のようなアプリケーションでは、参加者がざらざらして不鮮明に見え、存在感を損なうことがあります。
2. 圧縮効率の低下： これは直感的ではありませんが、同様に重要な問題です。現代のビデオコーデック（H.264、VP9、AV1など）は、冗長性を利用して高い圧縮率を達成します。それらはフレーム間（時間的冗長性）および単一フレーム内（空間的冗長性）の類似性を探します。ノイズはその性質上、ランダムで予測不可能です。それはこれらの冗長性のパターンを破壊します。エンコーダーはランダムなノイズを保存しなければならない高周波の詳細と見なし、実際のコンテンツの代わりにノイズをエンコードするためにより多くのビットを割り当てることを強制されます。これにより、同じ知覚品質でファイルサイズが大きくなるか、同じビットレートで品質が低下するかのどちらかになります。

エンコード前にノイズを除去することで、ビデオ信号をより予測可能にし、エンコーダーがより効率的に動作できるようにします。これにより、より良い視覚品質、より低い帯域幅の使用、そして世界中のユーザーにとってよりスムーズなストリーミング体験がもたらされます。

WebCodecsの登場：低レベルビデオ制御の力

長年、ブラウザでの直接的なビデオ操作は限られていました。開発者は主に<video>要素とCanvas APIの機能に制約されており、それらはしばしばGPUからのパフォーマンスを著しく低下させるリードバックを伴いました。WebCodecsは、その状況を完全に変えます。

WebCodecsは、ブラウザに組み込まれたメディアエンコーダーとデコーダーに直接アクセスできる低レベルAPIです。これは、ビデオエディタ、クラウドゲーミングプラットフォーム、高度なリアルタイムコミュニケーションクライアントなど、メディア処理に対する精密な制御を必要とするアプリケーション向けに設計されています。

私たちが焦点を当てるコアコンポーネントはVideoFrameオブジェクトです。VideoFrameはビデオの単一フレームを画像として表現しますが、単なるビットマップ以上のものです。これは、様々なピクセルフォーマット（RGBA、I420、NV12など）でビデオデータを保持でき、以下のような重要なメタデータを運ぶ、非常に効率的で転送可能なオブジェクトです：

• timestamp: フレームの表示時間（マイクロ秒単位）。
• duration: フレームの持続時間（マイクロ秒単位）。
• codedWidth と codedHeight: フレームの寸法（ピクセル単位）。
• format: データのピクセルフォーマット（例：'I420'、'RGBA'）。

重要なことに、VideoFrameはcopyTo()というメソッドを提供しており、これにより生の非圧縮ピクセルデータをArrayBufferにコピーすることができます。これが、分析と操作のための私たちのエントリーポイントです。生のバイトデータを取得したら、ノイズリダクションアルゴリズムを適用し、変更されたデータから新しいVideoFrameを構築して、処理パイプラインのさらに下流（例えば、ビデオエンコーダーやキャンバス）に渡すことができます。

時間的フィルタリングの理解

ノイズリダクション技術は、大きく分けて空間的と時間的の2種類に分類できます。

• 空間的フィルタリング： この技術は単一のフレームを単独で操作します。隣接するピクセル間の関係を分析してノイズを特定し、滑らかにします。簡単な例はぼかしフィルターです。ノイズの低減には効果的ですが、空間フィルターは重要なディテールやエッジもぼかしてしまい、画像がシャープでなくなる可能性があります。
• 時間的フィルタリング： これが私たちが焦点を当てている、より洗練されたアプローチです。これは時間を通じて複数のフレームにわたって操作します。基本的な原則は、実際のシーンのコンテンツはフレームから次のフレームへと相関している可能性が高いのに対し、ノイズはランダムで相関がないということです。特定の場所にあるピクセルの値を複数のフレームにわたって比較することで、一貫した信号（実際の画像）とランダムな変動（ノイズ）を区別できます。

時間的フィルタリングの最も単純な形式は時間的平均化です。現在のフレームと前のフレームがあると想像してください。どのピクセルについても、その「真の」値は現在のフレームの値と前のフレームの値の間のどこかにある可能性が高いです。それらをブレンドすることで、ランダムなノイズを平均化することができます。新しいピクセル値は、単純な加重平均で計算できます：

new_pixel = (alpha * current_pixel) + ((1 - alpha) * previous_pixel)

ここで、alphaは0から1の間のブレンド係数です。alphaが高いほど現在のフレームをより信頼することを意味し、ノイズリダクションは少なくなりますが、モーションアーティファクトも少なくなります。alphaが低いほど強力なノイズリダクションを提供しますが、動きのある領域で「ゴースティング」や残像を引き起こす可能性があります。適切なバランスを見つけることが鍵です。

単純な時間的平均化フィルターの実装

この概念をWebCodecsを使って実践的に実装してみましょう。私たちのパイプラインは、主に3つのステップで構成されます：

1. VideoFrameオブジェクトのストリームを取得します（例：ウェブカメラから）。
2. 各フレームに対して、前のフレームのデータを使用して時間的フィルターを適用します。
3. 新しくクリーンアップされたVideoFrameを作成します。

ステップ1：フレームストリームのセットアップ

VideoFrameオブジェクトのライブストリームを取得する最も簡単な方法は、MediaStreamTrackProcessorを使用することです。これはMediaStreamTrack（getUserMediaからのものなど）を消費し、そのフレームを読み取り可能なストリームとして公開します。

概念的なJavaScriptのセットアップ：

async function setupVideoStream() { const stream = await navigator.mediaDevices.getUserMedia({ video: true }); const track = stream.getVideoTracks()[0]; const trackProcessor = new MediaStreamTrackProcessor({ track }); const reader = trackProcessor.readable.getReader(); let previousFrameBuffer = null; let previousFrameTimestamp = -1; while (true) { const { value: frame, done } = await reader.read(); if (done) break; // ここで各 'frame' を処理します const processedFrame = await applyTemporalFilter(frame, previousFrameBuffer); // 次のイテレーションのために、*オリジナル*の現在のフレームのデータを保存する必要があります // ここで、閉じる前にオリジナルのフレームデータを 'previousFrameBuffer' にコピーします。 // メモリを解放するためにフレームを閉じるのを忘れないでください！ frame.close(); // processedFrame で何かを行います（例：キャンバスへの描画、エンコード） // ...そして、それも閉じてください！ processedFrame.close(); } }

ステップ2：フィルタリングアルゴリズム - ピクセルデータの操作

これが私たちの作業の中心です。applyTemporalFilter関数内で、入力フレームのピクセルデータにアクセスする必要があります。簡単にするために、フレームが'RGBA'フォーマットであると仮定しましょう。各ピクセルは4バイトで表現されます：赤、緑、青、そしてアルファ（透明度）。

async function applyTemporalFilter(currentFrame, previousFrameBuffer) { // ブレンド係数を定義します。0.8は新しいフレームの80%と古いフレームの20%を意味します。 const alpha = 0.8; // 寸法を取得します const width = currentFrame.codedWidth; const height = currentFrame.codedHeight; // 現在のフレームのピクセルデータを保持するためのArrayBufferを割り当てます。 const currentFrameSize = width * height * 4; // RGBAの場合、ピクセルあたり4バイト const currentFrameBuffer = new Uint8Array(currentFrameSize); await currentFrame.copyTo(currentFrameBuffer); // これが最初のフレームである場合、ブレンドする前のフレームはありません。 // そのまま返しますが、次のイテレーションのためにそのバッファを保存します。 if (!previousFrameBuffer) { const newFrameBuffer = new Uint8Array(currentFrameBuffer); // この関数の外で、グローバルな 'previousFrameBuffer' をこれで更新します。 return { buffer: newFrameBuffer, frame: currentFrame }; } // 出力フレーム用に新しいバッファを作成します。 const outputFrameBuffer = new Uint8Array(currentFrameSize); // メインの処理ループ。 for (let i = 0; i < currentFrameSize; i++) { const currentPixelValue = currentFrameBuffer[i]; const previousPixelValue = previousFrameBuffer[i]; // 各カラーチャンネルに時間的平均化の式を適用します。 // アルファチャンネル（4バイトごと）はスキップします。 if ((i + 1) % 4 !== 0) { outputFrameBuffer[i] = Math.round(alpha * currentPixelValue + (1 - alpha) * previousPixelValue); } else { // アルファチャンネルはそのままにします。 outputFrameBuffer[i] = currentPixelValue; } } return { buffer: outputFrameBuffer, frame: currentFrame }; }

YUVフォーマット（I420, NV12）についての注意： RGBAは理解しやすいですが、ほとんどのビデオは効率のためにネイティブにYUV色空間で処理されます。YUVの扱いはより複雑で、色（U, V）と輝度（Y）の情報が別々に（「プレーン」に）保存されます。フィルタリングのロジックは同じですが、各プレーン（Y, U, V）を別々に反復処理し、それぞれの寸法（カラープレーンはしばしば解像度が低い、クロマサブサンプリングと呼ばれる技術）に注意する必要があります。

ステップ3：新しいフィルタリング済み`VideoFrame`の作成

ループが終了した後、outputFrameBufferには新しくクリーンになったフレームのピクセルデータが含まれています。これを新しいVideoFrameオブジェクトでラップし、元のフレームからメタデータをコピーすることを確認する必要があります。

// applyTemporalFilterを呼び出した後のメインループ内で... const { buffer: processedBuffer, frame: originalFrame } = await applyTemporalFilter(frame, previousFrameBuffer); // 処理されたバッファから新しいVideoFrameを作成します。 const newFrame = new VideoFrame(processedBuffer, { format: 'RGBA', codedWidth: originalFrame.codedWidth, codedHeight: originalFrame.codedHeight, timestamp: originalFrame.timestamp, duration: originalFrame.duration }); // 重要：次のイテレーションのために前のフレームバッファを更新します。 // フィルタリングされたデータではなく、*オリジナル*のフレームデータをコピーする必要があります。 // フィルタリングの前に別のコピーを作成する必要があります。 previousFrameBuffer = new Uint8Array(originalFrameData); // これで 'newFrame' を使用できます。描画したり、エンコードしたりします。 // renderer.draw(newFrame); // そして重要なこととして、メモリリークを防ぐために、使い終わったら閉じてください。 newFrame.close();

メモリ管理は非常に重要です： VideoFrameオブジェクトは大量の非圧縮ビデオデータを保持でき、JavaScriptヒープ外のメモリに裏打ちされている場合があります。使い終わったすべてのフレームでframe.close()を呼び出す必要があります。これを怠ると、すぐにメモリが枯渇し、タブがクラッシュします。

パフォーマンスに関する考慮事項：JavaScript vs. WebAssembly

上記の純粋なJavaScript実装は学習やデモンストレーションには最適です。しかし、30 FPS、1080p（1920x1080）のビデオでは、私たちのループは毎秒2億4800万回以上の計算を実行する必要があります！（1920 * 1080 * 4バイト * 30 fps）。現代のJavaScriptエンジンは非常に高速ですが、このピクセルごとの処理は、よりパフォーマンス指向の技術であるWebAssembly (Wasm)の完璧なユースケースです。

WebAssemblyアプローチ

WebAssemblyを使用すると、C++、Rust、Goなどの言語で書かれたコードをブラウザでほぼネイティブの速度で実行できます。私たちの時間的フィルターのロジックは、これらの言語で簡単に実装できます。入力バッファと出力バッファへのポインタを受け取り、同じ反復的なブレンド操作を実行する関数を作成します。

Wasm用の概念的なC++関数：

extern "C" { void apply_temporal_filter(unsigned char* current_frame, unsigned char* previous_frame, unsigned char* output_frame, int buffer_size, float alpha) { for (int i = 0; i < buffer_size; ++i) { if ((i + 1) % 4 != 0) { // アルファチャンネルをスキップ output_frame[i] = (unsigned char)(alpha * current_frame[i] + (1.0 - alpha) * previous_frame[i]); } else { output_frame[i] = current_frame[i]; } } } }

JavaScript側からは、このコンパイルされたWasmモジュールをロードします。主要なパフォーマンス上の利点は、メモリを共有することから得られます。JavaScriptでWasmモジュールのリニアメモリに裏打ちされたArrayBufferを作成できます。これにより、高価なコピーなしでフレームデータをWasmに渡すことができます。その後、ピクセル処理ループ全体が単一の高度に最適化されたWasm関数呼び出しとして実行され、JavaScriptの`for`ループよりも大幅に高速になります。

高度な時間的フィルタリング技術

単純な時間的平均化は素晴らしい出発点ですが、モーションブラーや「ゴースティング」を導入するという重大な欠点があります。オブジェクトが動くと、現在のフレームのピクセルが前のフレームの背景ピクセルとブレンドされ、残像が作成されます。真にプロフェッショナルグレードのフィルターを構築するには、動きを考慮に入れる必要があります。

動き補償時間的フィルタリング (MCTF)

時間的ノイズリダクションのゴールドスタンダードは、動き補償時間的フィルタリングです。MCTFは、ピクセルを前のフレームの同じ(x, y)座標のピクセルと盲目的にブレンドする代わりに、まずそのピクセルがどこから来たかを突き止めようとします。

プロセスには以下が含まれます：

1. 動き推定： アルゴリズムは現在のフレームをブロック（例：16x16ピクセル）に分割します。各ブロックについて、前のフレームを検索して最も類似したブロック（例：絶対差の合計が最も低い）を見つけます。これら2つのブロック間の変位は「動きベクトル」と呼ばれます。
2. 動き補償： 次に、ブロックをその動きベクトルに従ってシフトさせることにより、前のフレームの「動き補償」バージョンを構築します。
3. フィルタリング： 最後に、現在のフレームとこの新しい動き補償された前のフレームとの間で時間的平均化を実行します。

これにより、動いているオブジェクトは、それがちょうど覆い隠した背景ではなく、前のフレームの自分自身とブレンドされます。これにより、ゴースティングアーティファクトが大幅に減少します。動き推定の実装は計算集約的で複雑であり、しばしば高度なアルゴリズムを必要とし、ほとんどの場合、WebAssemblyまたはWebGPUコンピュートシェーダーの仕事です。

適応フィルタリング

もう一つの強化点は、フィルターを適応的にすることです。フレーム全体に固定のalpha値を使用する代わりに、局所的な条件に基づいてそれを変化させることができます。

• 動き適応性： 動きが大きく検出された領域では、alphaを（例えば0.95や1.0に）増やして、ほぼ完全に現在のフレームに依存させ、モーションブラーを防ぎます。静的な領域（背景の壁など）では、alphaを（例えば0.5に）減らして、より強力なノイズリダクションを行います。
• 輝度適応性： ノイズは画像の暗い領域でより目立つことが多いです。フィルターは、影の部分ではより積極的に、明るい部分ではディテールを保持するためにより控えめにすることができます。

実用的なユースケースとアプリケーション

ブラウザで高品質なノイズリダクションを実行できる能力は、数多くの可能性を切り開きます：

• リアルタイムコミュニケーション (WebRTC)： ユーザーのウェブカメラフィードをビデオエンコーダーに送信する前に前処理します。これは低照度環境でのビデオ通話にとって大きな勝利であり、視覚品質を向上させ、必要な帯域幅を削減します。
• ウェブベースのビデオ編集： ブラウザ内ビデオエディタの機能として「ノイズ除去」フィルターを提供し、ユーザーがサーバーサイドの処理なしでアップロードした映像をクリーンアップできるようにします。
• クラウドゲーミングとリモートデスクトップ： 入力されるビデオストリームをクリーンアップして、圧縮アーティファクトを減らし、よりクリアで安定した画像を提供します。
• コンピュータビジョン前処理： ウェブベースのAI/MLアプリケーション（オブジェクト追跡や顔認識など）では、入力ビデオのノイズを除去することでデータが安定し、より正確で信頼性の高い結果につながる可能性があります。

課題と将来の方向性

強力である一方、このアプローチには課題がないわけではありません。開発者は以下に注意する必要があります：

• パフォーマンス： HDまたは4Kビデオのリアルタイム処理は要求が高いです。効率的な実装、通常はWebAssemblyを使用することが必須です。
• メモリ： 1つ以上の前のフレームを非圧縮バッファとして保存すると、大量のRAMを消費します。注意深い管理が不可欠です。
• レイテンシー： すべての処理ステップはレイテンシーを追加します。リアルタイムコミュニケーションのためには、このパイプラインは顕著な遅延を避けるために高度に最適化されなければなりません。
• WebGPUとの未来： 新たに登場するWebGPU APIは、この種の作業に新たなフロンティアを提供するでしょう。これにより、これらのピクセルごとのアルゴリズムをシステムのGPU上で高度に並列化されたコンピュートシェーダーとして実行できるようになり、CPU上のWebAssemblyさえも上回るパフォーマンスの大きな飛躍がもたらされます。

結論

WebCodecs APIは、ウェブ上での高度なメディア処理の新時代を告げます。それは従来のブラックボックスである<video>要素の障壁を取り払い、開発者に真にプロフェッショナルなビデオアプリケーションを構築するために必要なきめ細かい制御を与えます。時間的ノイズリダクションは、その力の完璧な例です：ユーザーが知覚する品質と基礎となる技術的効率の両方に直接対処する洗練された技術です。

個々のVideoFrameオブジェクトを傍受することで、ノイズを低減し、圧縮性を向上させ、優れたビデオ体験を提供するための強力なフィルタリングロジックを実装できることを見てきました。単純なJavaScript実装は素晴らしい出発点ですが、本番環境で使えるリアルタイムソリューションへの道は、WebAssemblyのパフォーマンス、そして将来的にはWebGPUの並列処理能力を通じて続きます。

次にウェブアプリでざらざらしたビデオを見たとき、それを修正するツールが今や初めてウェブ開発者の手に直接渡されていることを思い出してください。ウェブ上でビデオを構築するのにエキサイティングな時代です。