Windows 開発: Microsoft Media Foundation について


注: 記事は著者によって翻訳および整理されています。転載の場合は出典を示してください。

前文

導入

Microsoft Media Foundation は、Windows 用の次世代マルチメディア プラットフォームであり、開発者、消費者、およびコンテンツ プロバイダーが、堅牢性、比類のない品質、シームレスな相互作用を備えた高度なコンテンツの新しい波を受け入れることを可能にします。
Media Foundation には、Windows Vista 以降が必要です。コンポーネント オブジェクト モデル (COM) を使用し、C/C++ が必要です。Microsoft は、Media Foundation 用のマネージ API を提供していません。
Media Foundation API は、Windows SDK の一部です。Media Foundation アプリケーションを開発するには、最新バージョンのWindows SDKをインストールします。

利用可能な基本ツール

基本概念

ストリーム ストリーム

ストリームは、統一された形式の一連のメディア データです。最も一般的なのはオーディオ ストリームとビデオ ストリームですが、ストリームには、テキスト、スクリプト コマンド、静止画など、ほぼすべての種類のデータを含めることができます。この記事の「ストリーム」という用語は、特にネットワーク トランスポートのストリームを指すものではありません。ローカル再生用のメディア ファイルには、「ストリーム」も含まれます。
通常、メディア ファイルには、単一のオーディオ ストリーム、またはビデオ ストリームとオーディオ ストリームのいずれかが含まれます。ただし、メディア ファイルには同じ種類のストリームが多数含まれる場合もあります。たとえば、ビデオ ファイルには複数の言語のオーディオ ストリームが含まれている場合があります。アプリケーションは、実行時にオーディオを再生する言語を選択します。

圧縮

圧縮は、冗長な情報を削除してデータ ストリームのサイズを縮小するプロセスです。
圧縮アルゴリズムは、次の 2 つのカテゴリに分類されます。

  • 無損失圧縮: 無損失アルゴリズムを使用して、復元されたデータは元のデータと同じです
  • 非可逆圧縮: 非可逆アルゴリズムを使用すると、復元されたデータは元のデータの近似値になりますが、正確な値ではありません

他のほとんどのドメインでは、非可逆圧縮は受け入れられません。(スプレッドシートの「概算」を想像してみてください!) しかし、非可逆圧縮方式がオーディオとビデオに最適な理由は 2 つあります。
最初の理由は、人間の知覚の物理学に関係しています。音楽録音などの複雑な音を聞くとき、その音に含まれる情報の一部は聞こえません。信号処理理論の助けを借りて、知覚できない周波数を分析して分離することができます。これらの周波数は、知覚的な影響なしにキャンセルできます。再構築されたオーディオは元のオーディオと完全には一致しませんが、リスナーには同じように聞こえます。同様の原則がビデオにも当てはまります。
第二に、意図された目的によっては、音質または画質の多少の劣化が許容される場合があります。たとえば、テレフォニーでは、オーディオが高度に圧縮されることがよくあります。結果は、電話での会話には十分ですが、音楽を聴くには十分ではありません.
圧縮はエンコードとも呼ばれ、エンコードを行うデバイスはエンコーダーと呼ばれます。逆のプロセスはデコードであり、デバイスは当然デコーダーと呼ばれます。エンコーダーとデコーダーの総称がコーデックです。コーデックは、ハードウェアまたはソフトウェアで実装できます。

メディア コンテナ メディア コンテナ

生のオーディオまたはビデオ ストリームをファイルとして保存したり、ネットワーク経由で直接送信したりすることはめったにありません。一方では、使用するコーデックを事前に知らずに、このようなストリームをデコードすることは不可能です。したがって、メディア ファイルには通常、次の要素の少なくとも一部が含まれます。

  • ストリームの数、各ストリームの形式などを記述するために使用されるファイル ヘッダー。
  • コンテンツへのランダム アクセスを可能にするインデックス。
  • コンテンツを説明するメタデータ (ファイルの作成者やタイトルなど)。
  • ネットワーク送信またはランダム アクセス用のパケット ヘッダー。

このドキュメントでは、「コンテナ」という用語を使用して、ストリーム、ヘッダー、インデックス、メタデータなどのパッケージ全体を説明します。一部のコンテナ形式はライブ ストリーミング用に設計されているため、「ファイル」の代わりに「コンテナ」という用語が使用されます。アプリケーションは、コンテナをファイルに保存せずにオンザフライで生成できます。

メディア コンテナの初期の例は、AVI ファイル形式でした。その他の例として、MP4 や Advanced Systems Format (ASF) などがあります。コンテナーは、ファイル拡張子 (.mp4 など) または MIME タイプで識別できます。

次の図は、メディア コンテナーの一般的な構造を示しています。この図は特定の形式を表しているわけではなく、各形式の詳細は大きく異なります。
ここに画像の説明を挿入
図に示されている構造は階層構造であり、ヘッダー情報はコンテナーの先頭に表示されます。この構造は、多くの (すべてではない) コンテナー形式を表しています。また、データ セクションにはインターリーブされたオーディオおよびビデオ パケットが含まれていることにも注意してください。このインターリーブは、メディア コンテナーで一般的です。多重化という
用語は、オーディオおよびビデオ ストリームをパケット化し、パケットをコンテナにインターリーブするプロセスを指します。パックされたデータからストリームを再構成する逆のプロセスは、逆多重化と呼ばれます。

フォーマット フォーマット

デジタル メディアでは、フォーマットという用語はあいまいです。形式は、エンコードの種類 (H.264 ビデオなど) またはコンテナーの種類 (MP4 など) を参照できます。この区別は、通常のユーザーをしばしば混乱させます。メディア形式の名前は、常に役立つとは限りません。たとえば、MP3 はエンコード形式 (MPEG-1 Audio Layer 3) とファイル形式の両方を指します。
ただし、メディア ファイルの読み取りには実際には次の 2 つの段階があるため、この区別は重要です。

  1. まず、コンテナを解決する必要があります。ほとんどの場合、ストリームの数と各ストリームの形式は、この手順が完了するまでわかりません。
  2. 次に、ストリームが圧縮されている場合は、適切なデコーダーでデコードする必要があります。

この状況から、コンテナーの解析とストリームのデコードに別々のコンポーネントを使用するソフトウェア設計パターンが自然に生まれます。また、このアプローチはプラグイン モデルに適しているため、サード パーティは独自のパーサーとコーデックを提供できます。Windows では、コンポーネント オブジェクト モデル (COM) は、API を実装から分離する標準的な方法を提供します。これは、プラグイン モデルに必要であり、メディア ファンデーションが COM インターフェイスを使用する理由の 1 つです。
次の図は、メディア ファイルの読み取りに使用されるコンポーネントを示しています。
ここに画像の説明を挿入
メディア ファイルの書き込みには、さらに 2 つの手順が必要です。

  1. 非圧縮のオーディオ/ビデオ データをエンコードします。
  2. 圧縮データを特定のコンテナー形式に入れます。

次の図は、メディア ファイルの書き込みに使用されるコンポーネントを示しています。
ここに画像の説明を挿入

拡張ビデオ レンダラー 拡張ビデオ レンダラー (EVR)

Enhanced Video Renderer (EVR) は、ユーザーのモニターにビデオを表示するコンポーネントです。EVR には 2 つのバージョンがあります。

  • メディア ファンデーション アプリケーションで使用するための EVR メディア レシーバー。
  • DirectShow アプリケーションで使用するための EVR フィルター。

どちらのバージョンも同じ内部オブジェクトを使用してビデオをレンダリングし、多くの同じインターフェイスを共有しています。
EVR は、最大 16 のビデオ ストリームを混在させることができます。最初の入力ストリームは参照ストリームと呼ばれます。通常、リファレンス フローはz オーダーの一番上にあります。
(ウィンドウの z オーダーは、ウィンドウのスタック内の位置を示します。ウィンドウのスタックは、仮想軸である Z 軸に沿って画面から伸びます。z オーダーの上部にあるウィンドウは、上に押し付けられます。 z オーダーの最下部にあるウィンドウは、他のウィンドウによって押されます。システムは、z オーダーを 1 つのテーブルに保持します。ウィンドウがトップレベル ウィンドウ、親ウィンドウ、または子ウィンドウの場合、システムはそれらを z オーダーに追加します。トップレベル ウィンドウは、アクティブ ウィンドウかフォアグラウンド ウィンドウかに関係なく、トップレベル以外のすべてのウィンドウの上にスタックされます。) その他の
ストリームサブフローと呼ばれ、参照ストリームの上にブレンドされます。アプリケーションはサブストリームの z オーダーを変更できますが、サブストリームを z オーダーの最初にすることはできません。
サポートされているビデオ形式はグラフィックス ドライバーによって決まりますが、通常は以下に限定されます。

  • 参照ストリーム: 個々のピクセル アルファ値のないプログレッシブまたはインターレース YUV (NV12 や YUY2 など)、またはプログレッシブ RGB。
  • サブストリーム: AYUV や AI44 など、ピクセルごとのアルファを使用するプログレッシブ YUV。

使用可能なサブストリーム形式は、参照ストリームの形式によって異なる場合があります。
内部的には、EVR はミキサーと呼ばれるオブジェクトを使用して、入力ストリームからレンダリング用のサーフェスにフレームを合成します。Mixer は、インターレース解除と色補正も実行します。ミキサーは、最終的に混合ビデオ フレームを出力します。次に、ビデオ フレームは、2 番目のオブジェクト プレゼンターによって画面にレンダリングされます。プレゼンターは、いつフレームをレンダリングするかをスケジュールし、Direct3D デバイスを管理します。アプリケーションは、ミキサーまたはプレゼンターのカスタム実装を提供できます。
ここに画像の説明を挿入

おすすめ

転載: blog.csdn.net/weixin_44339850/article/details/112985888