Microsoft DirectX 8.0 |
デジタル レシーバのチューニング プロセスはネットワーク タイプによって異なるパラメータ セットが必要となる。チューニング モデルの目的は、これらの違いをオブジェクトとそのオブジェクトを操作するプロシージャの標準セットでカプセル化し、アプリケーションを細かい低レベルのチューニング マネージメントから解放することである。アプリケーションが DVB-S プロバイダからの番組をチューニングしようが、ローカル アナログ放送から来る番組をチューニングしようが、基本的な手順は同じである。この手順はまたその下にあるハードウェアにも依存しない。チューニング モデルのすべてのオブジェクトは標準 COM インターフェイス IPersistPropertyBag をサポートし、ストレージ メカニズムのソートが可能である。
Microsoft® DirectX® 8.0 ベースのアプリケーションは Microsoft チューニング モデルのメリットを十分には受けることができない事への注意は重要だ、なぜなら DirectX 8.0 は標準化されたガイド ストアとチューニング空間を理解するガイド ストア ローダを提供しないからだ。DirectX と Microsoft® Windows® の将来のリリースではこれらのコンポーネントが含まれる予定である。ガイド ストア ローダはトランスポート情報フィルタ上の番組サービス情報 (PSI) ストリームをモニターし、チューニング空間の利用可能なすべてのチャンネルや周波数に対してチューン リクエストを自動的に作成し、ガイド ストア データベースに保存する。これらのコンポーネントで、すべてのアプリケーションが行わねばならないことは、利用可能なチャンネルを見せるユーザー インタフェイスを作成し、ユーザーが選択したとき、ネットワーク プロバイダに準備前のチューン リクエストをサブミットすることである。しかし DirectX 8.0 では、アプリケーションはチューン リクエストの作成が必要となる (それにはチューン リクエストの意味を知らなければならない)。別の方法は、自分自身のガイド ストア ローダとガイド ストアを書くことである。
チューニング オブジェクトの 2 つの基本オブジェクトは チューニング空間 と チューン リクエスト である。チューニング空間はプロバイダと送信ソースを記述する、たとえば、ローカル ケーブル サービスやデジタル衛星ネットワークなど。アプリケーションはチューニング空間コンテナを使ってローカル システム上で利用可能なチューニング空間を列挙し、次にチューニング空間を使ってチューン リクエストを作成する。アプリケーションはネットワーク プロバイダにチューン リクエストをサブミットする、それはグラフ内のソース フィルタである。ネットワーク プロバイダは必要な情報をチューン リクエストから抽出し、その情報をカーネルモード ドライバに送る。次の図はアプリケーションとチューニング モデル オブジェクトと、BDA フィルタ グラフと、カーネル モード ドライバ間の上位レベルの関係を示している。
チューニング空間は個別のネットワーク プロバイダを記述する。チューニング空間の例には、EchoStar®、DirecTV®、アンテナ経由のローカル アナログ放送、ローカル アナログ ケーブル、アンテナ経由のローカル デジタル放送が含まれる。チューニング空間情報にはネットワーク タイプの情報が含まれる、たとえば地上波アナログ放送、ATSC、DVB-T、DVB-C、DVB-S。チューニング空間はチューン リクエストのコンテキストを定義する、各チューン リクエストは個別のチューニング空間以外にとっては意味がない。たとえば ATSC チューニング空間オブジェクトは ATSC チューン リクエストを作成し、CVB チューニング空間オブジェクトは DVB-S チューン リクエストを作成する、等々。チューニング空間オブジェクトとチューン リクエスト オブジェクトは Automation® 互換で、スクリプトあるいは Microsoft® Visual Basic®、C/C++ から構成可能である。
異なったネットワーク タイプは異なったタイプのデータを異なったフォーマットで運ぶので、あるチューニング空間はフィルタ グラフ内で固別のネットワーク プロバイダを必要とする。たとえば、ATSC デジタル フォーマット放送のチャンネルに対するチューン リクエストを作成するには、アプリケーションは IATSCTuningSpace をサポートする ATSC チューニング空間で始め、ATSC のネットワークタイプを持ち、IATSCLocator インターフェイスで構成された (このセッションの後半で説明する) デフォルト ロケータと結合される。アプリケーションが ITuningSpace::CreateTuneRequest を呼び出すと、ITuneRequest インターフェイス ポインタを戻り値として受け取る。アプリケーションはそのインターフェイスを使って IATSCTuneRequest インターフェイスをクエリし、次にそのインターフェイスを使ってチューン リクエストを構成する。チューン リクエストがサブミットされるとき、それは Microsoft ATSC ネットワーク プロバイダ (あるいは ATSC チューニング空間と同様に ITuner をサポートするサードパーティ BDA 互換のチューナー フィルタ) にサブミットされなければならない。
注 このバージョンの Microsoft® Broadcast Driver Architecture では、2 つのネットワーク プロバイダ フィルタが提供される、1 つは ATSC ネットワークであり、もう 1 つは DVB-S ネットワークである。DVB-S プロバイダについてはデフォルト チューニング空間は提供されない、なぜならそれを定義するには個別の情報が必要だからである。アプリケーションは SystemTuningSpaces オブジェクトを使って (C++ では ITuningSpaceContainer インターフェイスを使って)、ユーザーが購読するサービスについてユーザーから提供された基本情報をベースにした、アプリケーション自身の DVB-S チューニング空間を作成しなければならない。
Microsoft チューニング モデルはこのセクションの始めに説明したものとは別のオブジェクトを含む。次の図はすべてのチューニング モデル オブジェクト間のすべての関係を示す。C++ の用語ではこのダイアグラムは基底クラス間の関係を示す。チューン リクエストを作成、サブミットする実際のプロセスでは、アプリケーションは必ず同じタイプのネットワークすべてに固有の派生クラスを使って動作する。
チューニング空間コンテナ はシステムで利用可能なチューニング空間のレジストリを探し、チューニング空間オブジェクトをインスタンス化する。
チューニング空間 には 3 つの基本的役割がある。個別の番組ソースでは、それはネットワーク タイプと、"TV:" モニカ ネーム スペース ルールのコンテンツ パースと、チューン リクエスト オブジェクトの作成である。"TV:" Uniform Resource Identifiers (URIs) は HTML や XML に組み込むことができ、正しいオブジェクト インスタンスへのバインド用にパースされなければならない。バインドは COM オブジェクトをモニカから取得するための COM 用語である。この場合、チューニング空間はネットワーク固有のパースを提供するので、"TV:" URI へのバインドはそのチューニング空間のチューン リクエスト オブジェクトとなる。
ロケータ オブジェクトはチューンスペースと結び付けられ、より詳細の情報を提供する、この情報を使ってデバイス ドライバはチューニング空間内で指定されたチャンネルあるいは周波数をチューンするために使う。
コンポーネントは MPEG-2 番組ストリーム内の基本ストリームを参照する、たとえばビデオ、オーディオ 1、オーディオ 2、オーディオ 3、番組サービス情報 (PSI) 等々。これらの値は新しい周波数にチューンされた後でネットワーク プロバイダが書き込む。
各コンポーネントはコンポーネント タイプ オブジェクトと結び付けられる、それは、どの言語がオディオ基本ストリームで話されているかのような、コンポーネントについての情報を持つ。アプリケーションは各ユーザーが参照するコンポーネント タイプのリストを維持する。現在のユーザーのリストは ITuner を通してネットワーク プロバイダにサブミットされるべきである。 そのようなリストが提供されないと、ネットワークプロバイダはチューニング空間内の デフォルト優先コンポーネント タイプ リストを使用する。サードパーティは新しい優先コンポーネント タイプを定義することができる。各ユーザーの優先コンポーネント タイプのリストを維持することによって、アプリケーションは特別な条件を除いてコンポーネントと直接やりとりすることはない。特別な条件とは次のような場合である、優先言語が英語だが視聴者がドイツ語オーディオを代わりに聞きたいとしたとき、優先オーディオ トラックが AC-3 だが使用者がモノラル トラックに変更しようとしたとき。
ネットワーク プロバイダがチューン リクエストを受け取り、個別のチャンネルあるいは周波数にチューンしたとき、ネットワーク プロバイダはトランスポート情報フィルタが取得した PSI 情報をベースに チューン リクエストのコンポーネント リストを書き込む。次にネットワーク プロバイダは現在のユーザーの優先コンポーネント タイプとその情報を比較し、ユーザーの要求に適合するものが利用可能なら、適切な基本ストリームにチューンする。この最初のチューン リクエストがサブミットされた後で、アプリケーションは現在アクティブなチューン リクエストを取得し、新しいコンポーネント リストにアクセスできる。このチューン リクエストはユーザーの選択命令として、アップデートされたコンポーネント リストで再度サブミットされる。この例はオーディオ トラックをデフォルト優先以外の言語に変更する場合である。優先コンポーネントはチューン リクエストのコンポーネント リストが空あるいは無効の場合のみ使われる。別のコンポーネントがアクティブであろうが非アクティブであろうが、チューン リクエストは何度も再サブミットされ得るのでこれは必要である。