JP5147180B2 - ソフトウェアベースオーディオレンダリング - Google Patents

Description

本発明は、メディアレンダリングに関し、具体的にはソフトウェアベースオーディオレンダリングに関する。

メディアコンテンツを聞き、かつ／または見ることに関する大きい消費者需要がある。そのようなメディアコンテンツは、多数のソースからたやすく入手可能である。消費者は、そのようなメディアを見、かつ／または聞くときに良質の経験を望む。さらに、消費者は、複数の機能を実行でき、なおかつ良質のユーザ経験を提供できる単一の多用途消費者デバイスを高く評価する。

パーソナルコンピュータ（ＰＣ）は、メディアを見、かつ／または聞く多用途プラットフォームを提供する。ＰＣは、メディアを入手し、適宜、オーディオデータおよびビデオデータに解析する。次に、ＰＣは、メディアをデコードし、ディスプレイデバイスおよび／またはスピーカを介するなど、ユーザへの提示のためにデータをレンダリングする。ＰＣは、ソフトウェアベースコンポーネントを単独で、またはハードウェアコンポーネントと組み合わせて利用して、メディアをデコードし、レンダリングする。ＰＣプラットフォームのソフトウェアベースコンフィギュレーションは、さまざまなメディアフォーマットを再生するように適合可能なので、多用途である。さらに、新しいフォーマットが開発されたときに、その新しいフォーマットを処理するようにＰＣをアップデートすることができる。しばしば、そのようなアップデートは、ユーザの努力をほとんどまたは全く伴わずに、自動的に行うことができる。ハードウェアベースプラットフォームなどの他のプラットフォームは、製造時に「構成」され、そのような機能を全く有しないか制限されているので、より多用途でない。

ＰＣのこの多用途性が、広い消費者の受け入れにつながった。しかし、その多用途性を活用するために、ＰＣプラットフォームは、他のものよりも、さまざままな設計パラメータに優先順位を与えている。たとえば、オーディオサンプルがライブソースから収集される場合に、既存ＰＣプラットフォームでのオーディオレンダリングは、オーディオハードウェアレンダレートをオーディオサンプルキャプチャレートと調整する能力を有しない場合がある。この２つの間の相違は、些細ではあるが、チェックされない場合に長い再生時間にわたって大きくなる。

たとえば、オーディオサンプルが、地上波、ケーブル、または衛星のラジオ放送システムまたはＴＶ放送システムなどのライブソースからキャプチャされる場合に、ソースクロックとオーディオレンダハードウェアクロックの間のドリフトは、最終的に、いくつかのオーディオサンプルが捨てられるか、無音がライブオーディオストリームに挿入されるほどに非常に大きくなる場合がある。そのようなシナリオは、より不満足なユーザ経験をもたらす可能性がある。さらに、オーディオレンダリングコンポーネントが、しばしばメディアソースまたはビデオレンダリングコンポーネントと同期化されない可能性があるそれ自体のクロックに基づいてレンダリングするＰＣプラットフォームでは、オーディオプレゼンテーションが、見る人が簡単に気付く程度までに、対応するビデオプレゼンテーションと同期はずれになるシナリオが発生し得る。そのようなシナリオは、映画の再生または長時間の単一のＴＶチャネルの視聴時など、長い再生時間によって悪化する。

技術が進歩するにつれて、消費者は、消費者デバイスおよびシナリオのますます拡大されるニッチを満たすために、高められたイメージ品質および／またはサウンド品質と組み合わされた現在のＰＣのソフトウェアベースプラットフォームによって提供される柔軟性を望む。

ソフトウェアベースオーディオレンダリングについて説明する。

具体的な実装に、ドリフトが閾値に達するまで外部クロックとオーディオクロックの間の第１ドリフトレートを測定するように構成されたコンピュータ可読媒体が含まれる。ドリフトが閾値に達することに応答して、第１ドリフトレートに基づいて、この実装は、オーディオクロックを操作して、より小さい値および第１ドリフトレートと反対の極性を有する第２ドリフトレートを達成する。

別の実装は、第１オーディオサンプルの潜在的なオーディオレンダリング時刻を判定する。この実装は、第１ビデオフレームの潜在的なビデオレンダリング時刻を確かめる。この実装は、潜在的なオーディオレンダリング時刻および潜在的なビデオレンダリング時刻のうちの遅い方で第１オーディオサンプルおよび第１ビデオフレームをレンダリングする。

概要
次の説明は、ソフトウェアベースオーディオレンダリングならびに／あるいは外部クロックを用いるオーディオレンダリングプロセスおよび／またはビデオレンダリングプロセスの同期化の方法およびシステムに関する。

ディジタルオーディオコンテンツは、ユーザのためのサウンドを作るために、所与のソースレートで処理されるように構成された複数のサンプルと考えることができる。ソースは、ソースクロックに従って、所与のオーディオサンプリングレートでオーディオサンプルを供給する。オーディオデコーダは、オーディオサンプルをデコードし、デコードされたコンテンツの個々のサンプルをレンダリングに使用可能にする。オーディオサンプルを、オーディオハードウェアにレンダリングすることができる。オーディオハードウェアは、所与のソースレートに従う処理サイクルセットを有する。オーディオハードウェアは、オーディオハードウェアのクロックに従うソースサンプリングレートでサンプルを処理または消費するが、このクロックが、ソースハードウェアのクロックとわずかに異なる場合がある。

ソフトウェアベースオーディオレンダリングプロセスは、ソースからのオーディオコンテンツの生産と、オーディオハードウェアでのそのコンテンツの消費または処理を調整することができる。ソフトウェアベースオーディオレンダリングプロセスは、オーディオクロック時間を利用して、レンダリングプロセスを調整する。オーディオクロックは、１単位の時間にオーディオハードウェアによって消費されるオーディオサンプルの個数から導出され、この時間は、オーディオハードウェアのクロックを反映する。

一実装で、ソフトウェアベースオーディオレンダリングプロセスは、外部クロックに対するオーディオクロックのレートを測定することによって、そのオーディオクロックを外部クロックと同期化する。たとえば、オーディオレンダリングプロセスは、ドリフトが閾値に接近しつつある第１状態中にレートを測定することができる。この閾値は、システムジッタより大きいが、顕著な口合わせ（リップシンク）不一致を作る値より小さい、ある範囲の値から選択することができる。次に、オーディオレンダリングプロセスは、測定されたレートに基づいて、第２状態に過剰補償し、その結果、クロックドリフトが打ち消される。いくつかの実装は、オーディオクロックレートが測定されたレートの周囲で発振するように、測定されたレートとオーディオレートの間のドリフトのレートを微調整するさらなるステップを行う。これらの実装は、オーディオレートが測定されたレートの周囲でどのように発振するかを選択するときに、システムジッタおよびリップシンク不一致などの問題を予期することができる。オーディオクロックが測定されたレートの周囲で発振するときに、累積ドリフトが打ち消されて、非常に満足なユーザ経験が提供される。

いくつかの実装は、個々のフレームを捨てるか多くを捨てる（デシメートする）ことまたは状況に応じて個々のフレームを複数回レンダリングすることを伴うレート再サンプリングを利用することによって、オーディオクロックを操作する。オーディオクロックレートを操作する手段としてのレート再サンプリングを、以下で詳細に説明する。

ユーザのためにビデオイメージを作るために、ディスプレイデバイスおよび関連するグラフィックスハードウェアは、ユーザが「モーションビデオ」として知覚する一連のシーケンシャルイメージを生成するように構成される。ディスプレイデバイスは、標準規格のセットに従って構成されて、非常に正確なディスプレイサイクルまたは動作サイクルに従う。各ディスプレイサイクルの一貫した期間の間に、ディスプレイデバイスは、使用可能なビデオフレームからイメージを生成する。ソフトウェアベースビデオレンダリングプロセスは、このディスプレイサイクルを追跡するように構成される。ソフトウェアベースビデオレンダリングエンジンは、この追跡に基づいて、ディスプレイサイクルの適切な点でディスプレイデバイスのために個々のビデオフレームをレンダリングすることができる。モーションビデオのユーザの知覚しまたは見る経験は、一連の個々のフレームがディスプレイデバイスのディスプレイサイクルに従ってレンダリングされたときに質を高められる。

さらに、ユーザの見る経験は、対応するオーディオデータおよびビデオデータが同期化された形でユーザに提示されるときに質を高められる。オーディオプレゼンテーションとビデオプレゼンテーションを同期化する実装を説明する。たとえば、ユーザが、ムービーなどに関する再生コマンドを発行したときに、同期化プロセスは、そのムービーの第１オーディオサンプルの潜在的なオーディオレンダリング時刻を判定することができ、そのムービーの第１ビデオサンプルの潜在的なビデオレンダリング時刻を確かめることができる。次に、同期化プロセスは、潜在的なオーディオレンダリング時刻および潜在的なビデオレンダリング時刻のうちの遅い方で第１オーディオサンプルおよび第１ビデオフレームをレンダリングすることができ、オーディオプレゼンテーションとビデオプレゼンテーションが同時に開始されるようになる。

以下で説明する実装は、コンピューティング環境に関して説明される。さまざまなコンフィギュレーションを、パーソナルコンピュータすなわちＰＣなどのコンピュータによって実行される、プログラムモジュールなどのコンピュータ実行可能命令またはコード手段によって実装することができる。一般に、プログラムモジュールに、特定のタスクを実行するか特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、および類似物が含まれる。

さまざまな実施形態を、ＰＣ以外のコンピュータシステムコンフィギュレーションで実装することができる。たとえば、さまざまな実施形態を、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのまたはプログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、および類似物で実現することができる。さらに、テクノロジが進歩を続けるので、さまざまな実施形態を、これから識別されるクラスのデバイスで実現することができる。たとえば、さらに高まる処理能力と組み合わされた本発明の多用途性は、全般的な物理的外見において現在のセル電話機に似ているが、デバイスの処理機能、データ伝送機能、および／またはディスプレイ機能を介してさまざまな組み合わされた機能性を実行できるデバイスを作ることができる。これは、説明される実装に関する、多数の既存のおよび開発されるコンフィギュレーションの１つにすぎない。

その代わりにまたはそれに加えて、さまざまな実施形態を、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実践することもできる。分散コンピューティング環境では、プログラムモジュールを、ローカルとリモートの両方のメモリストレージデバイスに配置することができる。

さまざまな実施形態を、上で提案した多数のタイプのオペレーティング環境に組み込むことができるが、この文書の末尾の見出し「例示的なオペレーティング環境」の下で詳細に説明する普通のコンピューティングデバイスの形の例示的な汎用コンピューティングデバイスに関して、１つのみの例示的な環境の説明を、図２に示す。

例示的実装
図１に、ソフトウェアベースオーディオレンダリングおよび／またはソフトウェアベースビデオレンダリングを実行する例示的なシステム１００を示す。システム１００に、ディスプレイデバイス１０４に結合された、ＰＣなどのコンピューティングデバイス１０２が含まれる。コンピューティングデバイス１０２を、全般的に１０６に示されているように、インターネットなどのネットワークにも結合することができる。

コンピューティングデバイス１０２に、ソース１１０、パーサ１１２、オーディオデコーダ１１４、２つのオーディオバッファ１１５Ａ、１１５Ｂ、ソフトウェアベースオーディオレンダリングエンジン１１６、およびオーディオハードウェア１１８を含めることができる。このコンピューティングデバイスに、ソフトウェアベースビデオデコーダ１２０、２つのビデオバッファ１２２Ａ、１２２Ｂ、ソフトウェアベースビデオレンダリングエンジン１２４、グラフィックスハードウェア１２６、およびＴＶエンコーダ１２８も含まれる。この特定のシステムコンフィギュレーションで、パーサ１１２、オーディオデコーダ１１４、オーディオバッファ１１５Ａ、１１５Ｂ、オーディオレンダリングエンジン１１６、ビデオデコーダ１２０、バッファ１２２Ａ、１２２Ｂ、およびビデオレンダリングエンジン１２４は、ソフトウェアモジュールとして実装される。これらのモジュールは、メモリに保管され、１つまたは複数のプロセッサによって実行される。メモリおよびプロセッサは、図１に明示的に図示されてはいないが、そのようなコンピューティングシステムの１つの例示的なコンフィギュレーションを、図５に示す。

ソース１１０は、ビデオコンテンツおよび／またはオーディオコンテンツのローカルストアを表し、このローカルストアに、これらのコンテンツがさまざまなフォーマットで保管される。ソース１１０は、データストレージまたはメモリデバイスとして実装することができる。ソース１１０の代わりにまたはこれに加えて、コンピューティングデバイス１０２は、ネットワーク１０６を介して外部ソースにアクセスすることもできる。パーサ１１２は、ソース１１０からまたはネットワーク１０６を介して受け取られたオーディオコンテンツおよび／またはビデオコンテンツのさまざまなデータフォーマットを認識するように構成される。パーサ１１２は、オーディオデータをソフトウェアベースオーディオデコーダ１１４に配信し、ビデオデータをソフトウェアベースビデオデコーダ１２０に配信する。

オーディオ
ディジタルオーディオコンテンツは、ユーザのためにサウンドを累積的に作るために所与のソースレートで処理されるように構成された複数のサンプルと考えることができる。ソース１１０などのソースは、ソースクロックまたは外部クロック（具体的に指定されない）に従って所与のソースレートでオーディオサンプルを供給する。たとえば、所与のソースレートが、１０００サンプル毎秒またはヘルツ（Ｈｚ）である場合に、そのソースは、ソースクロックに従って１０００ｈｚのレートでサンプルを作る。他のソースレートが以下で説明する技法に適するが、ソースレートは、一般に、２００００ヘルツから５００００ヘルツの範囲で動作する。そのように高いサンプル毎秒では、人間は、一般に個々のサンプルを検出することができない。以下で明白になるように、この事実を、オーディオクロック同期化に有利に使用することができる。

オーディオデコーダ１１４は、ソースによって作られたオーディオサンプルをデコードし、個々のデコードされたサンプルを、オーディオバッファ１１５Ａを介してオーディオレンダリングエンジン１１６から使用可能にする。これらのオーディオサンプルを、オーディオハードウェア１１８にレンダリングすることができる。オーディオハードウェアは、所与のソースレートに従ってセットされた処理サイクルを有する。たとえば、ソースレートが１０００サンプル毎秒である場合に、オーディオハードウェアの処理サイクルは、毎秒１０００個のオーディオサンプルが消費されるようにセットされる。オーディオハードウェアは、それ自体は読取可能なクロック時間を有しない場合があるが、ハードウェアの処理レートは、外部クロックでの単位時間ごとに消費されるサンプル数として、またはオーディオハードウェアによって消費されるサンプルに対するソースで作られるサンプル数として判定することができる。

オーディオレンダリングエンジン１１６は、オーディオクロックを使用して、オーディオレンダリングプロセスのタイミングを決定する。オーディオクロックレートは、単位時間あたりにオーディオハードウェアによって消費されるサンプルの個数から導出される。ソフトウェアベースオーディオレンダリングエンジン１１６は、外部クロックに対するオーディオクロックを追跡または測定するように構成される。ソフトウェアベースオーディオレンダリングエンジンは、さらに、オーディオクロックと外部クロックの間の累積ドリフトを減らすためにアクションを行うことができる。したがって、たとえば、ソースプレゼンテーション時間が１時間であると仮定する。ソフトウェアベースオーディオレンダリングプロセスは、オーディオクロックと外部クロックが１時間の持続時間中の特定の瞬間的な時点に正確に同期化されている場合でもそうでない場合でも、１時間の再生時間の過程でこの２つのクロックの間の累積ドリフトを減らすアクションを行うことができる。さらに、以下で説明するように、オーディオクロックを測定されたレートに正確に一致させることを試みるのではなく、オーディオレンダリングエンジンは、オーディオクロックレートが測定されたレートの周囲で発振して、すべての累積ドリフトを効果的に打ち消すように、オーディオクロックを操作することができる。

ソフトウェアベースオーディオレンダリングエンジンを実装して、オーディオクロックと外部クロックの間の累積ドリフトを減らすことができるプロセスのより詳細な例を、以下で図３〜４に関して説明する。

ビデオ
ソフトウェアベースビデオデコーダ１２０は、パーサ１１２からビデオコンテンツを受け取り、ビデオコンテンツの個々のフレームをデコードする。ソフトウェアベースビデオデコーダ１２０は、デコードされたフレームをバッファ１２２Ａにバッファリングする。ソフトウェアベースビデオレンダリングエンジン１２４は、バッファ１２２Ａにアクセスし、バッファ１２２Ａに置かれたデコードされたフレームをビデオデコーダ１２０によってレンダリングする。フレームがレンダリングされると、ソフトウェアベースビデオレンダリングエンジンは、レンダリングされたフレームをグラフィックスハードウェア１２６に出力する。レンダリングされたフレームは、バッファ１２２Ｂにも保管され、ここで、このフレームを、ビデオデコーダ１２０によってダウンストリームフレームのデコードに使用することができる。この特定のシステムコンフィギュレーションでは、２つのバッファが使用される。しかし、他のシステムコンフィギュレーションでは、３つ以上のバッファを使用することができる。さらに、この特定のシステムコンフィギュレーションでは、２つのＦＩＦＯ（先入れ先出し）バッファが利用される。

バッファ１２２Ａ、１２２Ｂは、ソフトウェアベースビデオレンダリングエンジン１２４が、ソフトウェアベースビデオデコーダ１２０と独立に、非同期に動作することを可能にする。ビデオデコーダ１２０は、あるレートでビデオフレームを処理し、キューイングすることができ、ビデオレンダリングエンジン１２４は、異なるレートでフレームを抽出し、処理することができる。これによって、ビデオデコーダ１２０が、ビデオフレーム表示レートより速いレートでビデオフレームをデコードすることが可能になる。したがって、たとえば、表示レートが３０フレーム毎秒（ｆｐｓ）である場合に、デコーダは、ある時間期間に４０ｆｐｓをデコードすることができる。デコーダがバッファフレームを蓄積することを可能にすることによって、この実装は、より高い優先順位のアクティビティを有する他のソフトウェアモジュールの突然の急増に起因して、ソフトウェアベースビデオデコーダが遅れずにビデオフレームをデコードするのに十分なＣＰＵサイクルを得られない状況で、満足に実行することができる。余分にバッファリングされたフレームは、ソフトウェアベースビデオデコーダ１２０が、そのような状況を補償するために前もって少し多いフレームをデコードすることを可能にすることによって、これの発生を減らすことができる。

ソフトウェアベースビデオレンダリングエンジン１２４は、個々のビデオフレームをグラフィックスハードウェア１２６にレンダリングする。このグラフィックスハードウェアは、レンダリングされたフレームをＴＶエンコーダ１２８に提示する。ＴＶエンコーダは、ビデオフレームをスキャンし、そのデータを、イメージを生成するためにディスプレイデバイス１０４によって利用される形で提示する。イメージのシーケンシャルシリーズが、ユーザが知覚できるモーションビデオを作る。

ＮＴＳＣ標準規格に従って、ディスプレイデバイス１０４およびＴＶエンコーダ１２８は、定義されたディスプレイサイクルに従って２つのスキャニングサイクルまたはＶＢＩサイクルに各フレームを表示する。１ディスプレイサイクル内で、第１のスキャニングサイクルは、偶数フィールドに関し、第２のスキャニングサイクルは、奇数フィールドに関する。各スキャニングサイクルは、標準規格によって指定された持続時間だけ続く。第１のスキャニングサイクルで、イメージが、フレームの偶数フィールドから作成され、第２のスキャニングサイクルで、イメージが、偶数フィールドとインターレースされた奇数フィールドから作成される。偶数フィールドでは、ＴＶエンコーダ１２８が、フレームの偶数走査線をスキャンし、奇数フィールドでは、ＴＶエンコーダ１２８が、フレームの奇数走査線をスキャンする。

すべてのフィールドについて、ＴＶエンコーダ１２８は、スクリーンの左上から始めて走査線をスキャンし、スクリーンの右下に達するまで１つおきの走査線に沿って水平にスキャンする。右下に達した時に、ＴＶエンコーダ１２８は、ディスプレイの右下角から左上に戻るときに、スキャンしない垂直帰線消去期間（ＶＢＩ）イベントを通る。各フィールドは、１つのスキャニングサイクルまたはＶＢＩサイクルに表示され、ここで、ＶＢＩサイクルは、あるＶＢＩイベントから次のＶＢＩイベントまでにまたがるものとして定義される。ＮＴＳＣ標準規格によれば、各ＶＢＩサイクルは、１６．６７ミリ秒（ｍｓ）だけ続く。各フレームが、２つのＶＢＩサイクルの間表示されるので、フレームのディスプレイサイクルは、３３．３４ｍｓである。

ユーザのためのオーディオ出力とビデオ出力の同期化
ソフトウェアベースオーディオレンダリングエンジン１１６およびソフトウェアベースビデオレンダリングエンジン１２４は、システム１００が、ユーザのために対応するオーディオとビデオを同期化することを可能にする。たとえば、ソフトウェアベースビデオレンダリングエンジンは、個々のビデオフレームが、ディスプレイデバイスでの表示のためにスキャンされるディスプレイサイクルに入る実際の時刻を判定することができる。ソフトウェアベースビデオレンダリングエンジンは、この時刻をソフトウェアベースオーディオレンダリングエンジンに伝えることができ、このソフトウェアベースオーディオレンダリングエンジンは、対応するオーディオサンプルを適当な時刻にレンダリングすることができ、その結果、サウンド作成が、ビジュアルイメージに対応するようになる。そのようなプロセスを、以下で少なくとも図８〜９に関して説明する。

例示的なオペレーティング環境
図２に、上で説明したソフトウェアベースビデオレンダリングプロセスを実装するのに使用できる例示的なコンピューティングデバイスを示す。コンピューティングデバイス２４２に、１つまたは複数のプロセッサまたは処理ユニット２４４、システムメモリ２４６、およびシステムメモリ２４６を含むさまざまなシステムコンポーネントをプロセッサ２４４に結合するバス２４８が含まれる。マルチスレッディング技法を１つまたは複数のプロセッサで使用して、複数のタスクの並列処理を可能にすることができる。

バス２４８は、メモリバスまたはメモリコントローラ、周辺バス、ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ、およびさまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む複数のタイプのバス構造のいずれかの１つまたは複数を表す。システムメモリ２４６に、読取専用メモリ（ＲＯＭ）２５０およびランダムアクセスメモリ（ＲＡＭ）２５２が含まれる。スタートアップ中などにコンピューティングデバイス２４２内の要素の間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）２５４が、ＲＯＭ ２５０に保管される。

コンピューティングデバイス２４２に、さらに、ハードディスク（図示せず）から読み取り、これに書き込むハードディスクドライブ２５６、リムーバブル磁気ディスク２６０から読み取り、これに書き込む磁気ディスクドライブ２５８、ＣＤ ＲＯＭまたは他の光学媒体などのリムーバブル光ディスク２６４から読み取るか、これに書き込む光ディスクドライブ２６２を含めることができる。ハードディスクドライブ２５６、磁気ディスクドライブ２５８、および光ディスクドライブ２６２は、ＳＣＳＩインターフェース２６６または他の適当なインターフェースによってバス２４８に接続される。ドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータの不揮発性ストレージをコンピュータ２４２に提供する。本明細書で説明する例示的な環境は、ハードディスク、リムーバブル磁気ディスク２６０、およびリムーバブル光ディスク２６４を使用するが、当業者は、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、および類似物などの、コンピュータによってアクセス可能なデータを保管できる他のタイプのコンピュータ可読媒体も、例示的なオペレーティング環境で使用できることを諒解するであろう。

オペレーティングシステム２７０、（ユーザエージェントまたはブラウザなどの）１つまたは複数のアプリケーションプログラム２７２、他のプログラムモジュール２７４、およびプログラムデータ２７６を含む、複数のプログラムモジュールを、ハードディスク２５６、磁気ディスク２６０、光ディスク２６４、ＲＯＭ ２５０、またはＲＡＭ ２５２に保管することができる。ユーザは、キーボード２７８およびポインティングデバイス２８０などの入力デバイスを介して、コンピュータ２４２にコマンドおよび情報を入力することができる。他の入力デバイス（図示せず）に、マイクロホン、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナ、または類似物を含めることができる。上記および他の入力デバイスは、しばしば、バス２４８に結合されたインターフェース２８２を介して処理ユニット２４４に接続される。モニタ２８４または他のタイプのディスプレイデバイスも、ビデオハードウェア２８６などのインターフェースを介してバス２４８に接続される。モニタに加え、パーソナルコンピュータに、通常、スピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）が含まれる。

コンピュータ２４２は、一般に、リモートコンピュータ２８８などの１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク化された環境で動作する。リモートコンピュータ２８８は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、通常は、上でコンピュータ２４２に関して説明した要素の多くまたはすべてが含まれる。図４に示された論理接続に、ローカルエリアネットワーク（ＬＡＮ）２９０および広域ネットワーク（ＷＡＮ）２９２が含まれる。そのようなネットワーキング環境は、オフィス、会社全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。

ＬＡＮネットワーキング環境で使用されるとき、コンピュータ２４２は、ネットワークインターフェースまたはネットワークアダプタ２９４を介してローカルネットワークに接続される。ＷＡＮネットワーキング環境で使用されるとき、コンピュータ２４２に、通常は、インターネットなどの広域ネットワーク２９２を介する通信を確立する、モデム２９６または他の手段が含まれる。モデム２９６は、内蔵または外付けとすることができるが、シリアルポートインターフェース２６８を介してバス２４８に接続される。ネットワーク化された環境では、パーソナルコンピュータ２４２に関して図示されたプログラムモジュールまたはその一部を、リモートメモリストレージデバイスに保管することができる。図示のネットワーク接続が例示的であり、コンピュータの間の通信リンクを確立する他の手段を使用できることを諒解されたい。

コンピュータに、アナログまたはディジタルのチューナコンポーネント２９８も含めることができる。チューナコンポーネントを、ＰＣＩなどの内部バスまたは拡張バス、あるいはＵＳＢバス、ＩＥＥＥ−１３９４バスなどの外部バスのいずれかを介してシステムにリンクすることができる。チューナコンポーネントは、システムが、地上波、ケーブル、および衛星などの標準ＴＶ放送媒体を介して放送ＴＶを受信できるようにする。

一般に、コンピュータ２４２のデータプロセッサは、異なる時にこのコンピュータのさまざまなコンピュータ可読記憶媒体に保管される命令によってプログラムされる。プログラムおよびオペレーティングシステムは、通常、たとえばフロッピディスクまたはＣＤ−ＲＯＭで配布される。そこから、プログラムおよびオペレーティングシステムが、コンピュータの二次メモリにインストールまたはロードされる。実行時に、プログラムおよびオペレーティングシステムは、少なくとも部分的に、コンピュータの主電子メモリにロードされる。本明細書に記載のシステムに、他のデータプロセッサのマイクロプロセッサと共に、説明されるブロックを実装する命令またはプログラムを含む時の、上記および他のさまざまなタイプのコンピュータ可読記憶媒体が含まれる。説明されているシステムに、本明細書で説明する方法および技法に従ってプログラムされた時の、コンピュータ自体も含めることができる。

例示のために、オペレーティングシステムなどのプログラムおよび他の実行可能プログラムコンポーネントを、本明細書では別個のブロックとして示すが、そのようなプログラムおよびコンポーネントが、さまざまな時にコンピュータのさまざまなストレージコンポーネントに存在し、コンピュータのデータプロセッサによって実行されることを諒解されたい。

ソフトウェアベースビデオレンダリングに関する実施形態を、構造的特徴および／または方法に固有の言葉で説明したが、添付請求項の主題が、説明された特定の特徴または方法に必ずしも制限されないことを理解されたい。そうではなく、特定の特徴および方法は、ソフトウェアベースビデオレンダリングの例示的な実装として開示されたものである。

例示的なオーディオレンダリング実装
図３に、全般的に３００に示された、外部クロックとソフトウェアベースオーディオレンダリングクロックの間の累積ドリフトを制限する例示的なソフトウェアベースオーディオレンダリングプロセスを示す。

動作３０２で、ソフトウェアベースオーディオレンダリングプロセスが、ソースサンプルレートを確かめる。ソースに、一般に、ソースサンプルが提示されるように構成されたレートであるソースサンプルレートを示すある基準が含まれる。たとえば、一般的なソースサンプルレートは、４４．１キロヘルツ（ＫＨｚ）である。ソースサンプルレートが４４．１ＫＨｚである場合に、そのソースは、ソースクロックまたは外部クロックに対して４４．１ＫＨｚでサンプルを作るべきであり、オーディオハードウェアは、オーディオハードウェアクロックに対して４４．１ＫＨｚでサンプルを作るべきである。

動作３０４で、ソフトウェアベースオーディオレンダリングプロセスが、外部クロックとそのソフトウェアベースオーディオレンダリングプロセスによって使用されるソフトウェアベースオーディオレンダクロックの間のドリフト閾値（以下では「閾値」）を選択する。この閾値は、外部クロックとオーディオハードウェアクロックの間のクロック差の正確な測定を実現するのに十分に大きくなるべきであるが、顕著なリップシンク問題を生じないのに十分に小さくなるべきである。たとえば、１つの例のみで、１６ｍｓの閾値が利用される。

動作３０６で、ソフトウェアベースオーディオレンダリングプロセスが、外部クロックレートに対してソフトウェアベースオーディオレンダクロックレートを測定する。ソースの再生が開始され、サンプルが、ソースで作られ、デコードされ、レンダリングされ、その後、オーディオハードウェアで処理される。一実装で、ソフトウェアベースオーディオレンダリングプロセスは、サンプルがソースによって作られるレートに対する、サンプルがオーディオハードウェアによって消費されるレートを追跡する。測定された差を利用して、このプロセスは、このプロセスの後続動作でオーディオクロックレートを操作するときに利用されるレート調整を判断する。レート調整は、以下で述べるアルゴリズムに関して詳細に説明する。次の説明を単純にするために、レート調整の値が、この例について１サンプル毎秒として決定されると仮定する。

動作３０８で、ソフトウェアベースオーディオレンダリングプロセスが、基準クロックとオーディオクロックの間のドリフトが閾値に達するまで、第１状態を追跡する。

説明のために、図３と組み合わせて図４を検討されたい。図４に、全般的に４００に示された、例示的なソフトウェアベースオーディオレンダクロック同期化プロセスのグラフィカル表現を示す。外部クロック時間が、全般的に線４０２によって示されている。ソフトウェアベースオーディオレンダクロック時間は、全般的に線４０４によって示されている。例のために、ユーザ「再生」コマンドに応答して、オーディオクロックおよび外部クロックが、４０６に示された時刻０に同時に開始されると仮定する。

やはり説明のために、ソースレートが１０００ヘルツであると仮定する。外部クロックでの１秒の終りに、ソースは、１０００個のサンプルを提示し終えている。同様に、ハードウェア消費レートは、オーディオハードウェアが１秒に１０００個のサンプルを処理すべきであるとセットされている。しかし、外部クロックでの１秒の終りに、オーディオハードウェアが、１００２個のサンプルを消費したと仮定する。したがって、基準クロックレートに対して、測定されたレートは、基準クロックより毎秒２サンプル速い。したがって、オーディオクロックは、測定された２サンプル毎秒のレートで外部クロックから離れてドリフトする。そのような例が、第１状態４０８によって全般的に示されており、第１状態４０８は、５秒後に、ドリフトの最高点に達して、閾値４１０に達する。

動作３０８でドリフトが第１閾値に達したことに応答して、ソフトウェアベースオーディオレンダリングプロセスは、動作３１０で、第１状態のドリフトを過剰に訂正する応答アクションを行うことができる。たとえば、ソフトウェアベースオーディオレンダリングプロセスは、オーディオクロックレートを操作して、第１状態と反対方向で、第１閾値と反対の極性を有する第２閾値に向かうドリフトを引き起こすことができる。説明を簡単にするために、この例では、第１閾値と第２閾値の両方について、同一の閾値大きさ１０を利用する。他の実装は、第１閾値の大きさより小さい第２閾値大きさを利用する。

この例では、このプロセスが、オーディオクロックレートを操作して、動作３０６で判定された１フレーム毎秒のレート調整値を達成する。この例では、ソフトウェアベースオーディオレンダリングプロセスは、オーディオクロックレートが測定されたクロックレートより遅い、全般的に４１２に示された第２状態を作成することによって、第１状態のドリフトを過剰補償する。第２状態では、ソフトウェアベースオーディオレンダクロックが、測定されたレートからのドリフトの大きさが反対方向の所定の値と等しくなるまで、効果的に第１状態と反対方向に、より低いレートでドリフトする。

したがって、たとえば、第６秒から始まる期間に、ソフトウェアベースオーディオレンダリングプロセスは、ソースから受け取った１０００個のフレームのうちのいくつかを２回レンダリングし、より多くのサンプルが１秒のスパンにオーディオハードウェアにレンダリングされるようにすることによって、過剰補償する。サンプルを複数回レンダリングすることを、「挿入」と呼ぶことができる。というのは、その影響が、１サンプル期間中に消費される余分なサンプルを作成することだからである。前に判定されたように、オーディオハードウェアは、１秒に１００２個を処理することができる。したがって、ソフトウェアベースレンダリングプロセスは、これらのフレームのうちの３つを２回レンダリングすることによって３つの余分なサンプルを挿入することによって、オーディオクロックを操作する。ここで、オーディオクロックは、測定されたレートよりわずかに低い有効クロックレートを有する。第２状態４１２では、ソフトウェアベースオーディオレンダクロックが、５秒目から１５秒目の間に外部クロックに向かって逆にドリフトし、１５秒目で、ドリフトが、第１状態で発生したのと反対の方向に累積し始める。このプロセスの２５秒目に、ドリフトが、もう一度、１０の大きさを有する閾値４１０に達するが、この大きさの値は、ドリフトが第１状態と反対方向であることを示す、第１状態と反対の値である。

動作３１２で、第２状態で閾値に達したことに応答して、ドリフトが第１状態に向かって発振するようにオーディオクロックレートを操作することができる。この例では、オーディオクロックレートを、調整要因と一貫する量だけ測定されたレートより速くなるように操作することができる。たとえば、そのような操作に、後続の秒にフレームをデシメートすることを含めることができる。デシメーティングは、単に、そうでなければレンダリングされるはずの複数のフレームを単位時間内に捨てることを意味することができる。

この形で、挿入およびデシメーティングの上記の動作は、測定されたレートの周囲でオーディオクロックレートを発振させるように働くことができる。その結果、オーディオクロックレートと測定されたレートの間の累積ドリフトが、減るかなくなる。以下で説明するアルゴリズムは、ドリフト調整値を、ここで説明したものより正確な範囲に調整できる、洗練された実装を提供する。

例示的なアルゴリズム
次のアルゴリズムをソフトウェアベースオーディオレンダリングプロセスによって利用して、外部クロックとソフトウェアベースオーディオレンダクロックの間のドリフトを減らすかなくすことができる。このアルゴリズムは、オーディオクロックが外部クロックより低速の第１状態とオーディオクロックが外部クロックより高速の第２状態との間で交番することによって、ソフトウェアベースオーディオレンダクロックと外部クロックの間の累積ドリフトをなくすことができる。

ハードウェアクロックに基づくソフトウェアクロック実装は、他の要因の中でも、分解能、精度、およびエラー累積によって制限されているので、完全になることができない。これを認識して、次のソフトウェアクロック同期化アルゴリズムは、オーディオクロックを、外部クロックに対して所定の大きさのプラス／マイナス値（反対の極性）の間でドリフトさせることを可能にする。そのような実装は、上で述べた有害な要因からのある度合の免疫を提供することができる。いくつかの例で、このソフトウェアクロック同期化アルゴリズムは、すべてのそのような要因からの完全な免疫を提供することができる。そのような実装は、直接の訂正応答を用いてドリフトに反応する、以前の試みと対照的である。これらの、以前の技法は、ドリフト値が非常に短い時間期間の間に測定され、したがって非常に信頼できないので、うまく動作しない。従来の解決策の少なくとも１つの重要な短所は、ソフトウェアクロック実装が、非常に短い時間期間にわたって測定されるドリフトより通常は２〜３桁大きいジッタを有することである。これは、しばしば、誤った不釣り合いに大きい反応につながり、これによって、オーディオレンダリング品質が大きく低下する。

クロックドリフトに対する比例したほぼ対称の訂正を提供するために、オーディオレンダリングレートを、十分に長い期間にわたって外部クロックに対して測定して、測定されたドリフトレート（測定されたレート）を作成するべきである。次に、測定されたレートを、オーディオハードウェア再生レートを調整することによるか、オーディオサンプリングレートを調整することによって（オーディオ再サンプリング技法を使用して）、後続のドリフト訂正に使用することができる。後者の技法は、前者の技法とほとんど同等である。それでも、オーディオ再サンプリングは、基礎になるオーディオハードウェアから独立であり、したがって、レート調整分解能および最大ハードウェアレートなどの可能なオーディオハードウェア制限を減らすか回避する。次の説明では、オーディオサンプリングレート調整技法を述べる。しかし、オーディオハードウェアが上で述べたものなどの制限を課さない場合のハードウェア再生レートの調整に適用可能なアルゴリズムを説明する。

上で説明したように、再生時に、ソフトウェアベースオーディオレンダリングプロセスは、ドリフトが第１閾値に達するまで、外部クロックに対するソフトウェアベースオーディオレンダクロックのドリフトを測定する。その後、このプロセスは、次の式を使用する。
ΔＳ×Ｔ＝ΔＴ×Ｓ_ａ （１）
式（１）では、ΔＳは、オーディオソースレートに、ソフトウェアベースオーディオレンダクロックと外部クロックの間のクロックレートの差を乗じたものであり、Ｔは、ドリフトが閾値を超えた時の時刻であり、ΔＴは、閾値であり、Ｓ_ａは、オーディオサンプリングレートである。この２つのクロックの間の差のよい測定値をもたらすのに十分に大きいが、リップシンクが問題にならないのに十分に小さい閾値を選択するべきである。

したがって、外部クロックに従って、オーディオハードウェアは、レートＳ_ｍでオーディオを提示しており、ここで、
Ｓ_ｍ＝Ｓ_ａ＋ΔＳ （２）
である。

この式は、オーディオハードウェア再生レートに関する。オーディオハードウェア再生レートが、ソースオーディオレートにセットされている場合に、調整された再生レートは、ΔＲ＝ΔＴ／Ｔである。

説明のために、ソフトウェアベースオーディオレンダクロックが、外部クロックより低速であると仮定するが、次の数式は、この仮定と独立である。この仮定に基づけば、ΔＳ＜０である。ΔＳは、非常に小さいものにすることができるので、次のアルゴリズムは、計算に整数算術および固定小数点算術を利用するように構成される。したがって、このプロセスは、値への右シフトをスケーリングする。現在の例では、８の右シフト値が利用されるが、これは、値に２５６を乗ずることと同等である。この右シフトによって、０．００４Ｈｚと小さいレートへのオリジナルオーディオのレート再サンプリングが可能になる。この点からこの例の終りまでで、すべてのＳ値を、２５６によってスケーリングされていると考える。

ソフトウェアベースオーディオレンダクロックが外部クロックより低速である場合に、例示的なソフトウェアベースオーディオレンダリングプロセスは、オリジナルサンプリングレートより低いレートにオーディオデータを再サンプリングする。したがって、このプロセスは、オーディオクロックドリフトの方向を逆転するために、オーディオハードウェアがより高いレートで再生しているように見えるようにする。より低いレートにオーディオサンプルを再サンプリングするときに、このプロセスは、サンプル期間中にある個数のサンプルを捨てるかデシメートする。

オーディオハードウェアは、まだ、サンプルレートでサンプルを消費する。しかし、オーディオハードウェアは、サンプル期間に関連する全コンテンツより少量を消費する。たとえば、オーディオソースレートが１ｋＨｚであると仮定する。したがって、１秒に１０００個のサンプルが含まれる。オーディオハードウェアは、オーディオハードウェアクロックに従って、１秒に１０００個のサンプルを処理すべきである。しかし、外部クロックに対して、オーディオハードウェアが、１秒に９９９個のサンプルしか処理できないと仮定する。このプロセスが、１秒分のコンテンツから１サンプルを捨てた場合に、オーディオハードウェアは、外部クロックの１秒の時間期間に、対応するコンテンツの９９９個のサンプルを消費するだけでよく、この９９９個のサンプルを消費するのにオーディオハードウェアが費やす時間は、正確に１秒である。

このアクションを行うことによって、効果的に、オーディオハードウェアが、外部クロックに従って１秒にコンテンツの１秒分を再生するようになる。もちろん、１０００個のうちの１サンプルがユーザのために処理されないので、このコンテンツは正確に同一ではない。他のアルゴリズムを使用することもできるが、そのようなアルゴリズムは、この例で説明した挿入再サンプリングアルゴリズムより多くの処理リソースを利用する可能性がある。たとえば、３タップから５タップの有限インパルス応答（ＦＩＲ）フィルタなどのローパスフィルタを使用する１次元信号レート再サンプリングアルゴリズムは、レート再サンプリングされたオーディオを作って、満足なユーザ経験を提供することができる。

人間の耳は、約３０Ｈｚと約２００００Ｈｚの間の周波数成分を有する音しか聞くことができない。ほとんどの人間の音声は、主に３０００Ｈｚ未満である。人間の耳は、周波数が２００００Ｈｚに近付くにつれて、音にはるかに鈍感になる。ほとんどの消費者品質ディジタルオーディオは、主に説明を簡単にするために本明細書で選択された１０００Ｈｚではなく、４４１００ヘルツ（Ｈｚ）以上でサンプリングされる。これは、実際に偶然ではない。というのは、ナイキスト理論から、サンプリングされた音声信号が、サンプリングレートの半分未満の周波数を有するすべてのサウンドを再生できることが示されるからである。これは、４４１００Ｈｚでサンプリングされたオーディオが、人間の可聴周波数範囲を十分に超える２２０５０Ｈｚまでの周波数成分を正確に再生できることを意味する。

外部ソースとのオーディオレンダリングの同期化の場合に、オーディオレンダハードウェアと外部ソースの間のクロック差は、多くとも数ヘルツであり、しばしば、１ヘルツの小さい分数である。したがって、数千個または数万個のオーディオサンプルの中からの単一のオーディオサンプルの単純な複製またはデシメーションを使用することは、消費者品質オーディオについて低域フィルタを使用することよりはるかに効率的であり、それとほぼ同等の品質を達成する。例として、４４１００Ｈｚでディジタルサンプリングされたオーディオについて、オーディオサンプルは、２３ミリ秒よりわずかに短い時間だけ続く。このプロセスが、数千サンプルのうちの１サンプルを捨てると仮定すると、このオーディオサンプルが、その隣接する近傍がその値に近い領域にあるか、その２つの隣接する近傍の一方または両方が、それと非常に異なるのいずれかである。前者の場合に、このサンプルを捨てることは、人間の感覚の観点から、波形のひずみをほとんど作らない。後者の場合に、捨てられるサンプルは、非常に短い時間の間に劇的に変化する非常に高周波の信号のサンプルであり、そのサンプルは、そもそも人間にほとんど可聴でない。

いくつかのコンフィギュレーションで、オーディオハードウェアが、たやすく読み取り可能な時刻を有しない場合がある。その代わりに、オーディオ時間を、その直接メモリアクセス（ＤＭＡ）カーソル位置から導出することができる。ＤＭＡカーソルは、オーディオハードウェアが、オーディオドライバソフトウェアによって提供できるものなど、オーディオソフトウェアによって提供されるＤＭＡバッファ内でオーディオサンプルを入手している場所をポイントする。これによって、オーディオドライバが、ＤＭＡカーソルが読み取られた時にオーディオハードウェアが何個のオーディオサンプルを処理済みであるかを判定できるようになる。オーディオ時間増分は、オーディオサンプルレートでオーディオハードウェアによって消費されたオーディオサンプルの個数から導出される。オーディオハードウェアが、オーディオサンプルレートＳ_ｊである量のオーディオサンプルΔＡ_ｊを消費した期間ｊ中に、この期間内のオーディオ時間は、
δｔ_ｊ＝ΔＡ_ｊ／Ｓ_ｊ （３）
から計算される。したがって、動作状態に入ってからのソフトウェアベースオーディオレンダリングプロセスの総オーディオ時間は、

である。したがって、式４は、すべてのｊに関する式３の合計である。

この特定のアルゴリズムは、オーディオハードウェア再生レートを操作して、ソフトウェアベースオーディオレンダクロックと外部クロックの間のドリフトを、レート再サンプリングの使用に似た形で減らす。しかし、この特定のアルゴリズムでは、ハードウェアオーディオ再生レートが変更されるときに、オーディオハードウェアがオーディオサンプルを消費するレートが、物理的に変更される。オーディオレートが変更された直後のこの点まで、この点までに消費されたオーディオサンプルを読み取って、消費されたオーディオサンプルの量（ΔＡ_ｊ）を判定する。ソフトウェアレート再サンプリングと同様に、式４を使用して、オーディオ時間を計算する。

しかし、測定されたレートが、まだある度合の誤差を有する場合がある。オーディオレート再サンプリング、特に高々３２ビットの固定小数点計算を使用するものは、限られた精度を有する。その結果、計算丸め誤差が累積する可能性がある。同様に、外部クロックは、とりわけソフトウェア実行待ち時間のゆえに、２ミリ秒ほどの大きさになる可能性がある、ある量のジッタを有する。このソフトウェア待ち時間は、とりわけオペレーティングシステムおよび／または適用可能なアプリケーションプログラミングインターフェースによって引き起こされる待ち時間から生じる可能性がある。オーディオクロックと外部クロックの間の完全な同期点の周囲でゆっくり振動するようにこのアルゴリズムを構成することによって、このアルゴリズムは、これらの誤差を減らすか、これに免疫性になる。別の形で説明すると、オーディオレートは、
Ｓ_ｃ＝Ｓ_ｍ±δＳ_ｃ （５）
である。ここで、δＳ_ｃは、Ｓ_ｍ＋δＳ_ｃを使用するときにオーディオクロックが外部クロックよりわずかに高速であることと、Ｓ_ｍ−δＳ_ｃを使用するときにオーディオクロックが外部クロックよりわずかに低速であることと、次の条件が満足されることとを保証する最小の正の値である。この特定のアルゴリズムは、オーディオクロックが事前定義の閾値の正の値と負の値の間でドリフトするように構成される。順方向または正のドリフトで累積される誤差は、逆方向または負のドリフトで累積される誤差を打ち消す。したがって、このアルゴリズムは、累積誤差を減らすかなくす。したがって、正の閾値と負の閾値の間のドリフト時間が、固定小数点誤差累積が大きくなるのに十分に長くならないように値を選択することができる。

このプロセスがＳ_ｍを得た後のオーディオクロック時間は、δＳ_０＝ｓｉｇｎ（ΔＳ）×ΔＳ／２によって計算される。ここで、２による除算は、整数値の右シフトと同等である。したがって、ｊ＜ｃの場合に、
Ｓ_ｊ＝Ｓ_ｍ＋（−１）^ｊ＋１×ｓｉｇｎ（ΔＳ）×δＳ_ｊ （６）
かつ
δＳ_ｊ＋１＝δＳ_ｊ／２ （７）
であり、ｊ≧ｃの場合に、
δＳ_ｊ＝δＳ_ｃ （８）
である。

ｊ＝０で、（−１）^ｊ＋１×ｓｉｇｎ（ΔＳ）×δＳ_ｊ＞０であり、同等の再生レートは、外部クロックレートより高速である。したがって、オーディオクロックレートは、負の値から正の値に向かってドリフトする。オーディオ再サンプル間隔は、λ_ｊであり、
λ_ｊ＝Ｓ_ａ／｜Ｓ_ａ−Ｓ_ｊ｜ （９）
から計算され、Ｓ_ｊ＞Ｓ_ａの場合の１デシメーションの剰余およびＳ_ｊ＜Ｓ_ａの場合の挿入は、
γ_ｊ＝１．０×Ｓ_ａ／｜Ｓ_ａ−δＳ_ｊ｜−λ_ｊ （１０）
である。

再サンプリングプロセスは、固定小数点計算を使用して、サンプルを挿入するかデシメートする場所を見つける。ｊが増分されるときにＡに０がセットされ、その点で、オーディオレンダプロセスが、再サンプリングレートをセットしてドリフト方向を反転すると仮定する。オーディオレンダプロセスが、Ｌ個のサンプルを含む新しいオーディオサンプルバッファを受け取るときは必ず、Ａ＝Ａ＋Ｌである。Ａが、オーディオ再サンプル間隔（λ_ｊ）以上である場合に、このプロセスは、Ａからλ_ｊを引き、Ａ＝Ａ−λ_ｊになる。ρが、累積した剰余であり、Ａに０がセットされるときに０がセットされると仮定すると、このプロセスは、γ_ｊにρを加算する。この点で、ρが、スケーリングされた１（この例では２５６）以上である場合に、このプロセスは、（Ａ＋１）番目のサンプルを挿入／デシメートし、ρ＝ρ−２５６をセットする。そうでない場合に、このプロセスは、Ａ番目のサンプルを挿入／デシメートする。このプロセスは、Ａ＜λ_ｊになるまで継続する。その後、ソフトウェアベースオーディオレンダリングプロセスは、次のオーディオサンプルバッファがオーディオデコーダから来るのを待つ。このプロセスは、オーディオレンダリングプロセスが、たとえばｊをもう一度増分するなど、ドリフト方向をもう一度反転すると判断するまで繰り返される。

いくつかの実施形態で、式６を用いて、このプロセスは、ｊ＝０で開始され、オーディオクロックレートが、負の値から０に向かう。この点で、このプロセスは、閾値として最大ドリフト値をセットする。このプロセスは、このプロセスがドリフト方向の反転を開始するときに、オーディオが閾値をわずかに超えてドリフトし続けることを可能にするように、閾値マージンも与えられる。これは、前のレート（ｊ−１）で再サンプリングされたオーディオデータが、この時にオーディオハードウェアによって完全に消費されない場合があるからである。オーディオが、新たに最終的にセットされた最大ドリフト値以上の正の値までドリフトしたならば、このプロセスは、ｊを１の値まで増分する。この点で、オーディオ再生レートは、Ｓ_ｍより遅く見える。オーディオは、負の値に向かってドリフトし始める。δＳ_１の値は、δＳ_０の値の半分なので、ドリフトが要する時間は、負の閾値までドリフトする時間の約２倍である。このプロセスは、ｊの増分がもはやドリフト方向を反転しなくなるまで繰り返され、ドリフト方向を反転しないことは、増分値が、オーディオクロックのソフトウェア実装によって導入される誤差の補償に十分でないことを意味する。上のプロセスがドリフト方向の反転に失敗する時には、ｃ＝ｊ−１が、このプロセスがδＳを減らすことを試みる最後の時であり、収束値δＳ_ｃに達している。

最初に述べたように、このプロセスは、あるタイムスパン、たとえば１５分までに、正の閾値と負の閾値の間または疎の逆のオーディオクロックドリフトに制限を設けて、このアルゴリズムがさまざまなソースからの影響の累積に免疫性になるようにもする。これによって、前の段落で説明したδＳ_ｃに達する前のある状況でのδＳ_ｃの最小値を効果的に定めることができる。これは、このプロセスが、たとえばδＳ_ｊがもはや半分にされないように、タイムスパンが１５分を超えるときにｃ＝ｊをセットすることを意味する。ΔＳが極端に小さい場合に、δＳ_ｃをδＳ_０より大きく、２^ｎ×δＳ_０などにしなければならない場合がありえる。もう１つの条件は、最大サンプリング間隔を、２^３１≧Ｓ_ａ／｜Ｓ_ａ−Ｓ_ｊ｜までに制限し、その結果、必ず、３２ビット固定小数点計算をオーディオレート再サンプリングに使用できるようにすることである。式２および６に基づいて、δＳ_ｃの最小値に対する制限を定めることもできる。δＳ_ｃを、δＳ_０より大きく、２^ｎ×δＳ_０などにしなければならない場合がありえる。

要約すると、この実装について、測定されたレートからの調整されたレート変更またはレート変更デルタは、オーディオクロックが外部クロックに対してプラスおよびマイナスの値の閾値の間で継続的にドリフトすることを可能にすると同時に、オーディオクロックが、たとえば負の閾値と正の閾値の間でドリフトするのに要する時間が長いが長すぎない、最小の値にするべきである。たとえば、他の値の間でも、約１分から１時間以上のの期間が、適切な実装を提供することができる。収束レート調整デルタの判断基準を利用して、オーディオクロックが外部クロックと完全に同期して見えるが、その状態が実際にはソフトウェアクロック実装の不完全性から生じる状況に対して保護する。上で述べたほとんど対称の訂正は、最終的なレート調整デルタが決定される時に、オーディオクロックが負の閾値から正の閾値にドリフトする時間が、オーディオクロックが正の閾値から負の閾値にドリフトするのに要する時間とほぼ同一であることを意味する。

例示的なビデオレンダリング実装
ディスプレイサイクルを説明するために、図１および５を集合的に検討されたい。図５に、それぞれ全般的に５０２、５０４、および５０６の、ソフトウェアベースビデオレンダリングエンジン１２４によって追跡される３つの連続するビデオフレームＡＡ、ＢＢ、およびＣＣのディスプレイサイクルのタイムライン５００を示す。タイムライン５００では、時間が左から右に進行する。タイムライン５００の左端領域に示されているように、現在のフレームＡＡのディスプレイサイクルが、全般的に５０２に示されている。上で述べたように、ディスプレイサイクルには、２つのスキャニングサイクルまたはＶＢＩサイクルが含まれ、偶数フィールドが第１ＶＢＩサイクルにスキャンされ、その後、奇数フィールドが第２ＶＢＩサイクルにスキャンされる。各ＶＢＩサイクルは、イメージ生成に寄与しないＶＢＩイベントで最高点に達する。

ＶＢＩイベント５０８Ａは、ディスプレイサイクル５０２の終りおよびフレームＢＢのディスプレイサイクル５０４の始めを画定する。ディスプレイサイクル５０４に、第１ＶＢＩサイクルすなわち偶数ＶＢＩサイクル５１０と、第２ＶＢＩサイクルすなわち奇数ＶＢＩサイクル５１２が含まれる。ディスプレイサイクル５０４がフレームＢＢからのイメージを正しく表示するために、そのフレームが、ＶＢＩイベント５０８Ａの直前に、レンダリングのためにグラフィックスハードウェアから使用可能になっているべきである。

レンダリングプロセスを、時々、サーフェスフリッピング（ｓｕｒｆａｃｅ ｆｌｉｐｐｉｎｇ）またはフリップフロッピング（ｆｌｉｐ−ｆｌｏｐｐｉｎｇ）と称し、ここで、新しいフレームＢＢが、グラフィックスハードウェアによるアクセスのためにバックバッファサーフェスからフロントバッファサーフェスにフリップされると同時に、現在のフレームＡＡが、これに対応してフロントからバックにフリップされる。

フレームＢＢのディスプレイサイクル５０４は、ＶＢＩイベント５０８Ｂで最高点に達する偶数ＶＢＩサイクル５１０と、ＶＢＩイベント５０８Ｃで最高点に達する奇数ＶＢＩサイクル５１２からなる。ＶＢＩイベント５０８Ｂに応答して、後続フレームＣＣがレンダリングされ、その結果、このフレームＣＣをディスプレイサイクル５０６にスキャンできるようになるが、このフレームの偶数ＶＢＩサイクルだけが、図５に表されている。

標準規格に従って、ＴＶエンコーダ１２８は、１６．６７ｍｓという定義されたスキャニングサイクルすなわちＶＢＩサイクルを厳守する。ＴＶエンコーダは、このサイクルから意図的に逸脱はせず、他のシステムコンポーネントの動作を考慮に入れない。たとえば、ＴＶエンコーダは、個々のＶＢＩサイクルを短縮または延長する裁量を有しない。各ディスプレイサイクルに、２つのＶＢＩサイクルすなわち３３．３４ｍｓが含まれる。グラフィックスハードウェア１２６およびＴＶエンコーダ１２８のＶＢＩサイクルは、ＴＶエンコーダクロックまたはグラフィックスハードウェアのグラフィックスクロック（具体的には図示せず）のいずれかに関して維持される。

ソフトウェアベースレンダリングエンジン１２４に、ソフトウェアベースレンダリングクロック（具体的には図示せず）を含めることができる。ＴＶエンコーダ１２８および／またはグラフィックスハードウェア１２６のディスプレイサイクルを監視することによって、レンダリングエンジン１２４のレンダリングクロックは、ＴＶエンコーダのディスプレイサイクルに関してイベントをスケジューリングすることができる。ディスプレイサイクルを監視するプロセスの一例を、以下で図７Ａ〜７Ｂに関して説明する。

図１に示されているように、ソフトウェアベースビデオレンダリングエンジン１２４は、コンピューティングデバイス１０２の内部または外部とすることができるソースからビデオフレームを受け取る。このビデオフレームに、外部クロックまたはソースクロックなどの基準クロックによって確立されたプレゼンテーション時刻またはタイムスタンプを含めることができる。タイムスタンプを作成する外部クロックは、ＴＶエンコーダのディスプレイサイクルを知らず、グラフィックスハードウェアのクロックさえも知らない。ソフトウェアベースビデオレンダリングエンジン１２４は、グラフィックスハードウェア１２６のディスプレイサイクルを監視して、グラフィックスハードウェアのディスプレイサイクルに関してフレームを表示できる実際の時刻を予測する。次に、ビデオレンダリングエンジン１２４は、この予測に基づいて、ビデオフレームをビデオハードウェアにいつレンダリングするかを決定する。さらに、ソフトウェアベースビデオレンダリングエンジンは、この予測に基づいてレンダリングをスケジューリングすることができるが、ソフトウェアベースビデオレンダリングエンジンは、ディスプレイサイクルの監視を継続して、ビデオフレームが適当な時にレンダリングされることを保証する。

図６に、レンダリングエンジン１２４が個々のビデオフレームの実際のプレゼンテーション時刻を決定する、１つの例を示す。タイムライン６００が、１００ｍｓの持続時間について示されている。このタイムラインは、単一のＶＢＩサイクルに関連する１６．６７ｍｓの増分で区切られている。２つのＶＢＩサイクルの連続するセット（または３３．３４ｍｓ）が、１つのディスプレイサイクルを画定し、３つのディスプレイサイクル６０４、６０６、および６０８が、この例に示されている。第１ディスプレイサイクル６０４は、ビデオフレームＤＤを表示する。第２ディスプレイサイクル６０６は、第２ビデオフレームＥＥを表示し、第３ディスプレイサイクル６０８は、第３ビデオフレームＦＦを表示する。

ビデオフレームＥＥは、２０ミリ秒のプレゼンテーションタイムスタンプ６１０を有する。説明のために、このタイムスタンプを確立したクロックが、ディスプレイサイクルと同期化されていると仮定する。ＴＶエンコーダのディスプレイサイクルの監視から、ソフトウェアベースレンダリングエンジン１２４は、ビデオフレームＤＤが、０．０ｍｓから３３．３４ｍｓまでスキャンされ、したがって、ビデオフレームＥＥの実際のプレゼンテーションをこの時の後になるまで開始できないことを知る。したがって、ソフトウェアベースレンダリングエンジンは、ビデオフレームＥＥの実際のプレゼンテーション時刻を、３３．３５ｍｓから始まり、６６．６７ｍｓまで続く次のディスプレイサイクル６０６にするべきであることを知る。

同様に、ビデオフレームＦＦは、４０ｍｓのプレゼンテーション時刻６１２を有する。ソフトウェアベースレンダリングエンジンは、次に使用可能なディスプレイサイクル６０８が、６６．６８ｍｓに始まり、したがって、実際のプレゼンテーション時刻がその後に始まることを知る。レンダリングエンジンは、ディスプレイサイクル６０６の第２の半分にビデオフレームＦＦをレンダリングするようにスケジューリングすることができる。ソフトウェアベースレンダリングエンジンは、望ましくない結果が作られる可能性があるので、ディスプレイサイクル６０６の第１の半分がタイムスタンププレゼンテーション時刻６１２により近い場合であっても、ディスプレイサイクル６０６の第１の半分にフレームＦＦをレンダリングするようにはスケジューリングしない。そのような望ましくない結果を、図７Ａ〜７Ｂに関して以下で詳細に説明する。

図６に、ソフトウェアベースビデオレンダリングエンジンが、どのようにして個々のビデオフレームの実際のプレゼンテーション時刻を決定し、それに従ってこれらをレンダリングできるかが示されている。さまざまなシステムコンフィギュレーションが、レンダリング側および／またはグラフィックスハードウェア側のある度合の待ち時間を有する場合がある。この待ち時間は、さらに正確な実際のプレゼンテーション時刻を計算し、かつ／またはレンダリング時刻をスケジューリングするために、いくつかの実装によって計算に入れられる。ソフトウェアベースビデオレンダリングエンジンは、個々のビデオフレームの実際のレンダリング時刻をオーディオデコーダ１１４および／またはオーディオレンダリングエンジン１１６に通信することもでき、その結果、オーディオレンダリング時刻をそれ相応に調整できるようになる。

上で説明したように、ソフトウェアベースビデオレンダリングエンジンは、望まれる場合に、ディスプレイサイクルを監視して、個々のビデオフレームのレンダリング時刻および／またはプレゼンテーション時刻を決定することができる。ソフトウェアベースビデオレンダリングエンジンは、ビデオフレームをレンダリングする直前までディスプレイサイクルからＶＢＩ信号などのリアルタイム信号を入手し続けるので、これらの所定の値に頼る必要がない。いくつかの実装は、最終的に、所定の時間ではなくリアルタイム信号に基づいてビデオフレームをレンダリングすることができる。

ビデオハードウェアのディスプレイサイクルに従ってビデオフレームをレンダリングすることによって、結果のモーションビデオのユーザ経験の質を高めることができる。ビデオフレームをいつレンダリングするかを決定するためのディスプレイサイクルの監視の例示的なプロセスを、以下で図７Ａ〜７Ｂに関して説明する。

例示的なビデオレンダリングプロセス
図７Ａ〜７Ｂは、ビデオデータをレンダリングするソフトウェアベースプロセスを表す。この特定の実装は、ｎａｔｉｏｎａｌ ｔｅｌｅｖｉｓｉｏｎ ｓｔａｎｄａｒｄｓ ｃｏｍｍｉｔｔｅｅ（ＮＴＳＣ）によって確立された、他の国の中でも米国で利用されている標準規格に基づく。以下で説明する概念は、とりわけ、欧州で利用されているｐｈａｓｅ ａｌｔｅｒｎａｔｉｎｇ ｌｉｎｅ（ＰＡＬ）、ディジタル多用途ディスク（ＤＶＤ）、および４８０ｐなどの他の標準規格に適用可能である。１つのコンフィギュレーションで、このプロセスを、図１および２に関して説明したものなどのシステムを使用して実装することができる。説明されるソフトウェアベースビデオレンダリングプロセスに、動作７０２〜７３４が含まれる。動作７０２〜７２４は、全般的に、ビデオレンダリングプロセスに関し、動作７２６〜７３４は、全般的に、外部クロックとレンダリングプロセスクロックの間の潜在的なクロックドリフトへの対処に関する。このソフトウェアベースビデオレンダリングプロセスは、動作７０２のスタートアッププロセスで開始される。

動作７０２で、このソフトウェアベースビデオレンダリングプロセスは、メディアプレイヤアプリケーションがユーザによって開かれることに応答して、ビデオレンダリングエンジンスレッドを作成する。次に、このプロセスは、ユーザからの再生コマンドなど、実行イベント信号を待つ。グラフィックスハードウェアは、ＶＢＩサイクリング中に特定の割込み信号線に出会ったときに、割込み信号を生成する。この割込み信号が、ＣＰＵに割り込む。それに応答して、ＣＰＵが、割込み信号の発生およびそれを生成した割込み信号線を記録する。ＣＰＵは、割込み信号をドライバ割込みハンドラに配信する。ＣＰＵは、待機中スレッドキューを調べ、ＣＰＵが、その割込み信号を待っているスレッドを識別した場合に、ＣＰＵは、識別されたスレッドを待機中スレッドキューからレディスレッドキューに移動する。この例では、レンダリングエンジンスレッドが、割込み信号を待っており、レディスレッドキューに移動される。次に、ＣＰＵは、現在動作中のスレッドに対してビデオレンダリングエンジンスレッドの優先順位を調べ、ビデオレンダリングエンジンスレッドが優先順位を有する場合に、ＣＰＵは、ビデオレンダリングエンジンスレッドを実行し、現在のスレッドをレディキューに移動する。次に、このプロセスは、最初のビデオサンプルまたはフレームがビデオデコーディングプロセスから到着するのを待つ。

動作７０４で、ソフトウェアベースビデオレンダリングプロセスから使用可能なビデオフレームがバッファに到着した時に、このプロセスは、システムが新しいフレームの準備ができているかどうかを問い合わせる。この動作は、このプロセスが、システムの動作状態を検査して、ビデオフレームが実際に望まれていることを保証することを可能にする。この動作は、処理能力および／または他のリソースが浪費される機会を減らす。たとえば、ユーザが、「再生」を押したが、このプロセスがこの点に達した時までに、ユーザが「一時停止」を押す場合があり、あるいは、ユーザが、チャネルを変更しており、これによって、ビデオフレームをレンダリングする必要がなくなる場合がある。この例では、ユーザが一時停止を押した場合に、システムは、新しいフレームの準備ができていない。ビデオフレームが望まれない場合には、このプロセスは動作７０２に戻る。

ビデオフレームが望まれている場合に、ソフトウェアベースビデオレンダリングプロセスは、ＶＢＩサイクルのＶＢＩ極性を獲得する（動作７０６）。ＶＢＩサイクルは、ハードウェアサブシステムで発生し、このハードウェアサブシステムは、ディスプレイデバイスと共同で動作して、所与のビデオフレームからイメージを作る。各ビデオフレームは、あるディスプレイサイクルに表示され、このディスプレイサイクルは、２つのＶＢＩサイクルからなる。第１ＶＢＩすなわち偶数ＶＢＩは、ビデオフレームの偶数フィールドをスキャンする。第２ＶＢＩすなわち奇数ＶＢＩは、ビデオフレームの奇数フィールドをスキャンする。ＶＢＩ極性を獲得することによって、このプロセスは、個々のフレームのディスプレイサイクルが、第１ＶＢＩサイクルまたは第２ＶＢＩサイクルのどちらであるかを知る。ディスプレイサイクルおよびＶＢＩサイクルの例は、上で図２〜３に関して説明した。

説明のために、このプロセスが、奇数ＶＢＩ極性を獲得すると仮定する。奇数ＶＢＩ極性を獲得することによって、このプロセスは、現在のフレームの第２フィールドがＴＶエンコーダ１２８によってスキャンされつつあることを知る。

動作７０８で、ソフトウェアベースビデオレンダリングプロセスは、次のＶＢＩ信号を待つ。上で説明したように、ＶＢＩイベントは、ＶＢＩサイクルの終りに発生し、ＶＢＩサイクルの垂直帰線消去フェーズの始めを示す。グラフィックスハードウェアは、各ＶＢＩイベントにおいてＶＢＩ信号を作成し、このＶＢＩ信号が、ソフトウェアベースビデオレンダリングエンジンによって検出される。偶数フィールドのスキャンの終りでのＶＢＩ信号の受取は、次のＶＢＩサイクルが奇数極性を有することを示す。同様に、奇数フィールド後のＶＢＩ信号の受取は、次のＶＢＩサイクルが偶数極性を有することを示す。したがって、ＶＢＩ信号の受取時に、偶数ＶＢＩサイクルを奇数ＶＢＩサイクルから分離することによって、現在のフレームのディスプレイサイクルが次のＶＢＩ信号の直前に完了することが示される。ＶＢＩ極性を獲得し、ＶＢＩ信号を待つことによって、ソフトウェアベースビデオレンダリングプロセスは、近付きつつある奇数ＶＢＩサイクルに次のフレームをレンダリングするようにスケジューリングすることができる。

動作７１０で、ソフトウェアベースビデオレンダリングプロセスは、ＶＢＩサイクルを追跡する。ＶＢＩサイクルを追跡することによって、このプロセスが、獲得に単一ＶＢＩサイクルより長い時間を要する可能性があるＶＢＩ極性を再確認する必要がなくなる。まずＶＢＩ極性を獲得し、次にＶＢＩサイクルを追跡することによって、ソフトウェアベースビデオレンダリングエンジンは、ビデオレンダリングエンジンのビデオレンダリングクロックに対する各ディスプレイサイクルの点を知る。他の利益の中でも、この特徴は、ソフトウェアベースビデオレンダリングエンジンが、現在のフレームの偶数サイクルがスキャン済みであるときに限って新しいフレームをレンダリングする可能性を回避することを可能にすることができる。そのような技法がない、いくつかの既存のプロセスは、偶数フィールドＶＢＩサイクル中に新しいフレームがレンダリングされるようにスケジューリングされ、現在のフレームの第２サイクルまたは奇数サイクルが省略され、新しいフレームがその代わりにスキャンされるというシナリオにつながる可能性がある。そのようなシナリオは、より不満足なユーザ経験につながる可能性がある。そのような場合に、新しいフレームが、時間的に逆の順序でスキャンされる可能性がある。たとえば、偶数フィールドとその後に奇数フィールドではなく奇数フィールドとその後に偶数フィールドになり、これは、ユーザの満足をさらに減らす可能性がある。

さらに、ＶＢＩサイクルを追跡することによって、ソフトウェアベースビデオレンダリングエンジンは、各ＶＢＩサイクルが正確に１６．６７ｍｓを要するので、グラフィックスクロックに基づいて、それ相応にビデオレンダリングクロックを更新することができる。したがって、たとえば、ＶＢＩ信号が検出されるたびに、ビデオレンダリングクロックを、それ相応に上に移動することができる。これによって、レンダリングプロセスが、そのアクティビティのタイミングをディスプレイサイクルとより正確に合わせることが可能になる。たとえば、ソフトウェアレンダリングエンジンがあるＶＢＩサイクルに完了する他のタスクを設けることができる。

その代わりにまたはそれに加えて、各ＶＢＩイベントの検出時にビデオレンダリングクロックを更新し、そのビデオレンダリングクロックを基準クロックの時間と比較することによって、グラフィックスクロックと基準クロックの間のクロックドリフトを減らすこともできる。

以下で詳細に述べるように、動作７１０のクロック同期化プロセスは、ソフトウェアベースビデオレンダリングプロセスを、地上波、ケーブル、および衛星ソースなどの標準ＴＶ放送媒体からのライブビデオソースクロックに従属させることを可能にすることができる。

また、以下で詳細に述べるように、正確なビデオレンダクロックを保つことによって、ソフトウェアベースビデオレンダリングプロセスが他のコンポーネントおよび／またはプレゼンテーションを同期化することが可能になる。たとえば、ソフトウェアベースビデオレンダリングプロセスは、イメージが所与のビデオフレームから生成される実際の時を決定することができる。

ソフトウェアベースビデオレンダリングプロセスは、次に、実際のプレゼンテーション時刻を利用して、オーディオビジュアル不一致を減らすことができる。たとえば、ソフトウェアベースビデオレンダリングプロセスは、ビデオフレームの実際の表示時刻をオーディオデコーダおよび／またはオーディオレンダリングエンジンに通信することができ、その結果、オーディオ態様およびビジュアル態様を同期化できるようになる。

たとえば、現在のフレームの奇数フィールドの始めにＶＢＩ信号を受け取った時に、ソフトウェアベースビデオレンダリングプロセスは、約１６．６７ｍｓで次のＶＢＩ信号を受け取った時に次のフレームをレンダリングすることを知る。ソフトウェアベースビデオレンダリングプロセスは、次のフレームのスキャンがその時点で開始されることも知る。したがって、ソフトウェアベースビデオレンダリングプロセスは、オーディオレンダリングエンジンに、関連するオーディオパケットを１６．６７ｍｓ後にレンダリングするように指示することができる。そのような同期化プロセスは、人間の知覚をはるかに下回る明確な上限以内のオーディオビデオ同期化を作ることができる。

動作７１２で、ソフトウェアベースビデオレンダリングプロセスは、システムが新しいフレームの準備ができているかどうかをもう一度検査する。このステップでは、システムの動作状態を検査して、リソースが不必要なレンダリングに浪費されないことを保証する。システムが、次のフレームの準備ができていない場合（すなわち、「Ｎｏ」分岐）、このプロセスは、システムの準備ができるまで待つ。システムの準備ができたならば（すなわち、「Ｙｅｓ」分岐）、ソフトウェアベースビデオレンダリングプロセスがレンダリングサイクルであるかどうかを判定する（動作７１４）。たとえば、ソフトウェアベースビデオレンダリングプロセスは、それが次の３３．３４ｍｓでフレームをレンダリングするようにスケジューリングされているか否かを調べるために検査することができる。そのようなスケジューリングの一例を、上で図３に関して説明した。

この動作は、他の属性の中でも、改善されたリソース割り当てを考慮に入れることができる。ソフトウェアベースビデオレンダリングプロセスが、ビデオレンダリングサイクルである量のリソース、特にグラフィックスハードウェアリソースを予約する望みを予測した場合に、ソフトウェアベースビデオレンダリングプロセスは、それのために予約されたリソースを保持する。ソフトウェアベースビデオレンダリングプロセスが、所与のレンダリングサイクルにビデオレンダリングを完了した場合に、ソフトウェアベースビデオレンダリングプロセスは、その予約された処理リソースの一部を他のプロセスに利用させることができる。ディスプレイサイクルおよび／またはＶＢＩサイクルを追跡することによって、ソフトウェアベースビデオレンダリングプロセス用に予約された処理リソースを他の処理タスクに再割り当てできる時が生じる場合がある。ＶＢＩサイクルを追跡し、ビデオレンダリングクロックを更新することによって、ソフトウェアベースビデオレンダリングプロセスが、リソースをソフトウェアベースビデオレンダリングプロセスのために予約すべきときと、これらが他の処理タスクから使用可能であるときとを知ることが可能になる。

たとえば、ソフトウェアベースビデオレンダリングプロセスが、レンダリングＶＢＩサイクルでサーフェスフリップをスケジューリングできる前に、特定の動作タスクを実行するために特定のグラフィックスハードウェアユニットを必要とすると仮定する。サーフェスフリッピングは、上で図２に関して説明した。さらに、ユーザインターフェース（ＵＩ）モジュールなどの他のモジュールが、同一のグラフィックスハードウェアユニットを使用すると仮定する。ソフトウェアベースビデオレンダリングプロセスは、レンダリングプロセスに優先順位を与え、その結果、レンダリングプロセスが、そのタスクを遅れずに完了できるようにする。レンダリングプロセスがそのスケジューリングされたタスクを完了したならば、ＵＩモジュールなどの他のコンポーネントが処理リソースを利用することを許可することができる。

ソフトウェアベースビデオレンダリングプロセスがその処理タスクをタイムリーに達成できることを保証する技法の１つが、ソフトウェアベースビデオレンダリングプロセスが、グラフィックスユニットにタスクを発行することを望む他のソフトウェアモジュールにグラフィックスユニットへのアクセスを与えるか拒否することを可能にすることである。たとえば、ソフトウェアベースビデオレンダリングプロセスは、ソフトウェアベースビデオレンダリングプロセスが予約すべきグラフィックスユニットリソースの比率を測定することができる。ソフトウェアベースビデオレンダリングプロセスが、グラフィックスユニットのリソースの１００％を必要とする極端な場合に、ソフトウェアベースビデオレンダリングプロセスは、レンダリングＶＢＩサイクルが満了する前に、ソフトウェアベースビデオレンダリングプロセスがサーフェスフリップのスケジューリングに成功するためにグラフィクスユニットのリソースの１００％を有するべき最後のタイムスパンを判定することができる。したがって、ソフトウェアベースビデオレンダリングプロセスは、他のソフトウェアモジュールによるグラフィックスユニットの使用をそれ相応に制限またはゲーティングすることができる。たとえば、ソフトウェアベースビデオレンダリングプロセスは、ソフトウェアベースビデオレンダリングプロセスがサーフェスフリップをスケジューリングした直後にリソースゲートをオンにするが、将来のある時までＵＩモジュールがグラフィックスユニットのある比率だけを使用することを許可することができる。次に、ソフトウェアベースビデオレンダリングプロセスは、スケジューリングされたすべてのタスクがレンダリングＶＢＩサイクル内へのある時間の前に完了するように、他のソフトウェアモジュールへのリソースゲートをオフにし、その結果、ソフトウェアベースビデオレンダリングプロセスがスケジューリングできるタスクを、十分な安全マージン付きで完了できて、ソフトウェアベースビデオレンダリングプロセスがレンダリングＶＢＩサイクル満了の前にサーフェスフリップをスケジューリングすることを可能にする。

ソフトウェアベースビデオレンダリングプロセスが、レンダリングサイクルでない場合に、このプロセスは、動作７１６に進む。プロセスがレンダリングサイクルである場合に、このプロセスは動作７１８に進む。

動作７１６で、ソフトウェアベースビデオレンダリングプロセスは、フリップされたサーフェスすなわち前にスキャンされたフレームを解放する。前に述べたように、バックサーフェスにアタッチされたメモリバッファが、フロントサーフェスのメモリバッファとスワップされることに留意されたい。したがって、このプロセスは、現在のバックサーフェスを、それにアタッチされたバッファと共にバッファキューに解放することができる。ビデオデコーダは、プレゼンテーションタイムスタンプの順序で、新たにデコードされたビデオフレームをバッファに書き込むために、解放されたバッファを獲得することができる。そのようなバッファは、図１ではビデオバッファ１２２Ｂとして指定されている。この時点で、このプロセスは動作７０８に進む。

動作７１８では、ソフトウェアベースビデオレンダリングプロセスがレンダリングＶＢＩサイクルであるが、このプロセスは、次のフレームが使用可能であるかどうかを検査する。いくつかのコンフィギュレーションで、次のビデオフレームは、図１に関して説明したフレームバッファ１２２ＡなどのバッファＦＩＦＯからの獲得および消費のために、ソフトウェアベースビデオレンダリングプロセスから使用可能になっているべきである。この特定のＦＩＦＯバッファキューは、フレームプレゼンテーションタイムスタンプに従う時間順でソフトウェアベースビデオデコーディングプロセスによって書き込まれる。１つのシナリオで、ソフトウェアベースビデオデコーディングプロセスは、１つまたは複数のフレームをデコード済みであり、図１に関して説明したビデオバッファ１２２Ｂから獲得されたバッファにこれらを書き込み済みであり、ソフトウェアベースビデオレンダリングエンジンによる受取のために図１のビデオバッファ１２２Ａにビデオフレームを配置済みである。もう１つのシナリオでは、グリッチが、ソフトウェアベースビデオデコーディングプロセスが遅れずに次のビデオフレームを配信することを妨げる場合がある。この後者の状況が発生し、次のビデオフレームが、ＶＢＩレンダリングサイクル中に使用可能でない場合には、ソフトウェアベースビデオレンダリングプロセスは、動作７２０に進む。次のフレームが使用可能である場合には、ソフトウェアベースビデオレンダリングプロセスは、キューからそれをとり、動作７２４に進む。

動作７２０では、ソフトウェアベースデコーディングプロセスが、遅れずにビデオフレームを配信しないので、ソフトウェアベースビデオレンダリングプロセスは、現在表示されているビデオフレームの表示を１つまたは複数のＶＢＩサイクルにわたって延長する。１つの手法は、現在のフレームを２つのＶＢＩサイクルすなわち約３４ｍｓだけ延長することである。このプロセスは、次に、動作７２２に進む。

動作７２２では、ソフトウェアベースビデオデコーディングプロセスがロスを埋め合わせることを可能にし、デコーディングプロセスが追い付くことを可能にするために、ソフトウェアベースビデオレンダリングプロセスが、後続ビデオフレームを捨てるようにデコーディングプロセスに指示する。

処理リソースは、ソフトウェアベースビデオデコーディングプロセスが、遅れたフレームについて補償するために捨てられる後続フレームを選択できるようにすることによって節約することができる。たとえば、圧縮ビデオストリームに、基準フレームおよび非基準フレームが含まれると仮定する。ソフトウェアベースビデオデコーディングプロセスは、すべての基準フレームをデコードしなければならず、これらの基準フレームは、他のフレームをデコードするのに使用される。したがって、デコーディングプロセスは、非基準フレームをデコードしないことを選択することができる。通常、非基準フレームは、デコードに数倍多いシステムリソースを要する。１つまたは複数の非基準フレームが、通常、２つの基準フレームの間に存在する。したがって、非基準フレームをデコードしないことによって、ソフトウェアベースビデオデコーディングプロセスは、２フレーム時間以内に追い付くことができる。たとえば、次にデコードされるフレームが非基準フレームである場合に、ビデオデコーダは、そのフレームを捨てることができる。次のフレームが基準フレームである場合に、それに続くフレームは、非基準フレームであるべきであり、ビデオデコーダは、そのフレームを捨てることができる。これによって、表示されるビデオフレームのプレゼンテーションタイムスタンプが、対応するレンダリングされるオーディオサンプルのプレゼンテーションタイムスタンプから、２つ以下のディスプレイサイクルについて３４ｍｓ以下だけずれることが許容され、その後、オーディオとビデオを再同期化することができる。

具体的な例として、ＭＰＥＧ−２／４／１０またはＷＭＶ９ビデオなどの標準規格ベースのビデオ圧縮のメインプロファイルに、Ｂ（両方向予測）フレームが含まれるが、Ｂフレームは他のフレームを構築するための基準フレームとして使用されないので、Ｂフレームをデコードする必要はない。また、Ｂフレームは、他のフレームタイプと比較したときに、デコードにより多くのシステムリソースを要する。したがって、ソフトウェアベースビデオデコーディングプロセスは、動作７２２のフレームを捨てるコマンドを受け取った後に最初に出会うＢフレームをデコードしないことを選択することができる。

図７Ａに示されていない代替の手法が、もう１つのＶＢＩサイクルだけ表示について現在のフレームを延長し、次のＶＢＩサイクルをレンダリングサイクルと指定することである。新しいビデオフレームが次のＶＢＩサイクルに使用可能である場合に、その新しいフレームが、１ＶＢＩサイクルだけ表示される。この方式は、次の４ＶＢＩサイクル内の動作７２０の発生ごとに１回に制限することができる。単一の発生の後に、現在のフレームを、動作７２０で説明したようにもう２ＶＢＩサイクルだけ表示して、ビデオデコーディングプロセスが追い付けるようにすることができる。

動作７２２の代替のシナリオで、ソフトウェアベースビデオレンダリングプロセスが、スケジューリングされたレンダ時刻の後に次のビデオフレームを受け取り、次のディスプレイサイクルが現在のフレームでもう一度開始された場合に、ソフトウェアベースビデオレンダリングプロセスは、そのディスプレイサイクルがディスプレイサイクルの前半であるかどうかを判定する。次のビデオフレームが、ディスプレイサイクルの前半すなわち第１ＶＢＩサイクルまたは偶数ＶＢＩサイクル中に受け取られた場合に、このプロセスは、遅れて到着したフレームをレンダリングし、ビデオフレームが遅れずにレンダリングされたかのように動作７３０に進む。このプロセスステップは、デコーダから遅れて到着するフレームをそのディスプレイサイクルの後半に表示することを可能にする。動作７２２で、ビデオデコーダにフレームを捨てるように指示する場合には、ソフトウェアベースレンダリングプロセスは、動作７０８に進む。

動作７２４で、ソフトウェアベースビデオレンダリングプロセスが、次のビデオフレームを入手する。

動作７２５で、ソフトウェアベースビデオレンダリングプロセスは、次のビデオフレームが前のフレームと連続しているかどうかを検査する。ソフトウェアベースビデオレンダリングプロセスは、前のフレームのプレゼンテーションタイムスタンプに関して、動作７２４で入手されたビデオフレームのプレゼンテーションタイムスタンプの連続性を検査する。この検査では、動作７２２によって引き起こされた不連続性のすべてが除外される。不連続性が存在する場合に、ソフトウェアベースビデオレンダリングプロセスは、動作７２６に進む。フレームが連続的である場合に、ソフトウェアベースビデオレンダリングプロセスは、動作７２８に進む。

動作７２６では、不連続性が存在するので、ソフトウェアベースビデオレンダリングプロセスは、前のフレームのプレゼンテーションタイムスタンプと次のフレームのプレゼンテーションタイムスタンプの間の差まで、現在のフレーム表示時間を延長する。

次のフレームと前のフレームの間のそのような不連続性を引き起こすことができる例の１つが、ソフトウェアベースビデオレンダリングプロセスを用いる、ＤＶＤムービーなどのＤＶＤ再生の文脈で発生する可能性がある。そのような例では、ＤＶＤメニューが、ムービーのビデオストリーム内でユーザのために表示される場合がある。そのようなシナリオの１つで、メニューが、ユーザコマンドによって呼び出され、かつ／または除去される。たとえば、ユーザが、再生の「一時停止」を選択した場合に、メニューを表し、一時停止状態を表すフレームを、ビデオストリームにビデオフレームとして挿入することができる。したがって、ＤＶＤメニューは、ムービーのビデオストリームの一部ではない。さらに、ムービーのビデオフレームは、ソースによって挿入されたタイムスタンプを有する。メニューには、タイムスタンプが含まれる場合とそうでない場合がある。メニューがタイムスタンプを有しない場合に、ムービーフレームのタイムスタンプに対する相関がほとんどまたは全くない可能性が高い。したがって、メニューがビデオストリームに挿入されるか除去されるたびに、不連続性が生じる。ＤＶＤメニューが、ユーザによって呼び出された場合にいつでも表示される可能性があることに留意されたい。さらに、ユーザがいつでも選択を行うことができるので、１つの静止フレームがどれだけ長く表示されるかを正確に判断することも困難である。ユーザが、前の再生状態を再開した場合に、メニューフレームが除去され、ビデオストリームの別の不連続性が生じる可能性がある。次フレームの表示時間を延長した後に、ソフトウェアベースビデオレンダリングプロセスは、動作７０８に戻る。

動作７２８で、ソフトウェアベースビデオレンダリングプロセスが、次のビデオフレームのレンダリングをスケジューリングする。次のフレームをレンダリングする動作は、次のフレームバッファを含むサーフェスをフリップすることによって達成することができる。

上で説明したソフトウェアベースビデオレンダリングプロセスステップは、プロセスステップ７０４〜７０８を介してディスプレイサイクルを監視する。次に、ソフトウェアベースビデオレンダリングプロセスは、現在のフレームの奇数フィールドのスキャンの最高点で生成されたリアルタイムＶＢＩ信号を受け取った時に、使用可能であれば次のフレームをレンダリングする。レンダリングプロセスは、まさにこのとおりである必要はない。他の例示的なプロセスは、ディスプレイサイクルを監視し、現在のフレームのディスプレイサイクルが半分以上完了した後のいつにでも次のフレームをレンダリングすることができる。上で図２に関して説明したように、現在のフレームのフィールドがスキャンのためにフリップされたならば、次のフレームをレンダリングすることができ、ビデオハードウェアは、次のディスプレイサイクルまでそれをスキャンしない。したがって、たとえば、あるソフトウェアベースビデオレンダリングプロセスは、下流コンポーネントが現在のディスプレイサイクルの第２の半分を開始したことを確かめるや否や、次のフレームをレンダリングすることができる。

動作７２８の後に、ソフトウェアベースビデオレンダリングプロセスは、動作７０８に戻る前に、動作７３０で開始されるクロック同期化サブルーチンに進んで、レンダリングプロセスを繰り返す。動作７３０で、ソフトウェアベースビデオレンダリングプロセスは、ビデオレンダクロック時間と基準クロックの間の差を計算する。基準クロックとビデオレンダクロックの比較は、上で動作７１０に関して説明した。ビデオレンダクロック時間と基準クロック時間の間の差の絶対値が、フレームディスプレイサイクル持続時間未満である場合には、ソフトウェアベースビデオレンダリングプロセスは、動作７０８に進む。

ビデオレンダクロック時間と基準クロック時間の間の差が、ビデオフレームディスプレイサイクルより大きい正の値である（これはビデオレンダクロックまたはグラフィックスハードウェアクロックが基準クロックより速いことを示す）場合に、ソフトウェアベースビデオレンダリングプロセスは、動作７３２に進む。

ビデオレンダクロック時間と基準クロック時間の間の差が、ビデオフレームディスプレイサイクルより大きい負の値である（これはビデオレンダクロックまたはグラフィックスハードウェアクロックが基準クロックより遅いことを示す）場合に、ソフトウェアベースビデオレンダリングプロセスは、動作７３４に進む。

動作７３２で、ソフトウェアベースビデオレンダリングプロセスは、普通の２ＶＢＩサイクルではなく４ＶＢＩサイクルの間、次のフレームを表示する。言い換えると、ソフトウェアベースビデオレンダリングプロセスは、第２ＶＢＩサイクルではなく第４ＶＢＩサイクルを次のレンダリングＶＢＩサイクルとして指定することによって、次のビデオフレームの表示時間を２倍にする。また、ソフトウェアベースビデオレンダリングプロセスは、ビデオクロック時間から１ビデオフレーム時間の量を差し引く。ソフトウェアベースビデオレンダリングプロセスは、次に、動作７０８に戻って、レンダリングプロセスを繰り返す。

動作７３４で、ソフトウェアベースビデオレンダリングプロセスは、１フレームを捨て、１ビデオフレーム時間の量だけビデオクロック時間を増分するようにビデオデコーダに指示する。次のフレームが任意のディスプレイサイクルだけ後に受け取られたときに、非常に似た原理を適用することができる。次に、ソフトウェアベースビデオレンダリングプロセスは、動作７０８に戻って、レンダリングプロセスを繰り返す。

動作７３２および／または動作７３４で行われるビデオクロック調整の結果として、ビデオクロックドリフト時間が、１ビデオフレーム時間または基準クロックの３３ｍｓ以内に戻され、ソフトウェアベースビデオレンダリングプロセスが、動作７０８に進むことができる。

上で説明したプロセスステップは、ＮＴＳＣ以外の標準規格に従うビデオに適用可能であり、かつ／またはこれに適合させることができる。たとえば、プログレッシブ標準規格に関して、ソフトウェアベースビデオレンダリングプロセスは、ＶＢＩ極性がインターレース式コンテンツだけに関連するので、ＶＢＩ極性を使用しない。

同様に、ソフトウェアベースビデオレンダリングプロセスは、他のサイクル持続時間を有する標準規格に適用可能である。そのような実装のいくつかで、ソフトウェアベースビデオレンダリングプロセスは、逆テレシネを行うことができる。これは、たとえば、このプロセスが、フレームレートが３０フレーム毎秒（ｆｐｓ）であるかのようにビデオフレームをレンダリングすることによって、効果的に２４ｆｐｓレートを達成できることを意味する。次に、ソフトウェアベースビデオレンダリングプロセスは、４つごとのフレームフリップ間隔に標準の２ではなく４をセットすることができ、これは、４つごとのフレームが、３つの先行するフレームの２倍の長さだけ表示されることを意味する。これらは、上で説明したソフトウェアベースビデオレンダリングプロセスの応用例の可能な例のうちの少数にすぎない。

例示的なオーディオおよびビデオのプレゼンテーション時刻スケジューリング
いくつかの実装で、ソフトウェアベースオーディオレンダリングプロセスおよびソフトウェアベースビデオレンダリングプロセスが、同期化プロセスで互いに通信して、再生時の待ち時間を減らすと同時に、捨てられる最初のフレームの発生を最小にすることができる。さらに、同期化プロセスは、ソフトウェアベースオーディオレンダリングプロセスおよびソフトウェアベースビデオレンダリングプロセスが出会うさまざまなオーディオフォーマットおよびビデオフォーマットならびに関連する圧縮技法および圧縮解除技法に動的に適応的とすることができる。そのようなオーディオビデオ同期化の例を、以下で、再生コマンド受取時のスタートアップおよび一時停止コマンドに応答する一時停止の文脈で説明する。

図８は、時間がこのページの上から下へ進行する、全般的に８００として示された、そのようなオーディオビデオ同期化スタートアッププロセスの１つを表す。オーディオデコーダ８０２、オーディオレンダ８０４、ビデオレンダ８０６、およびビデオデコーダ８０８が、８１０で実行コマンドを受け取る。この実行コマンドが、ムービーを再生することであると仮定する。８１２で、このムービーからの第１オーディオサンプルが、オーディオデコーダ８０２からオーディオレンダ８０４に配信される。オーディオレンダは、このオーディオサンプルをレンダリングできる最も早い潜在的な時刻を判定する。８１４で、オーディオレンダ８０４が、オーディオサンプルの最も早い潜在的なオーディオレンダ時刻についてビデオレンダ８０６に通知する。いくつかの実装で、通信チャネルおよび／または関連する通信プロトコルを事前に確立して、待ち時間を減らしながらスタートアップを容易にすることができる。

８１６で、ビデオデコーダ８０８が、このムービーの第１ビデオフレームをビデオレンダ８０６に配信する。ビデオレンダは、第１ビデオフレームの最も早い潜在的なビデオレンダリング時刻を確かめる。８１８で、ビデオレンダ８０６が、そのフレームの最も早いビデオレンダ時刻についてオーディオレンダ８０４に通知する。オーディオレンダ８０４およびビデオレンダ８０６は、潜在的なオーディオレンダリング時刻および潜在的なビデオレンダリング時刻のうちの遅い方でレンダリングするように構成される。したがって、遅い方の潜在的なレンダ時刻に対応する時刻８２０に、オーディオレンダが、８２２でオーディオレンダを開始し、ビデオレンダが、８２４でビデオレンダを開始する。この特定の例では、オーディオレンダおよびビデオレンダが、最も早いレンダリング時刻に関する判定を行う。デコーダなどの他のコンポーネントを、その代わりにまたはそれに加えて、判断プロセスに用いることができる。

別の実施形態で、同期化プロセスを容易にするために、オーディオレンダ８０４がサンプルを受け取り、最も早い潜在的なレンダ時刻を判定したならば、オーディオレンダは、ビデオレンダが対応するビデオフレームを受け取ったかどうかを判定するためにビデオレンダ８０６に問い合わせることができる。肯定の場合に、オーディオレンダ８０４は、ビデオレンダの最も早い潜在的レンダ時刻に関してビデオレンダ８０６に問い合わせることができる。同様に、ビデオレンダがオーディオレンダに問い合わせることができる。

図９は、時間がこのページの上から下へ進行する、全般的に９００として示された、もう１つのオーディオビデオ同期化プロセスを表す。この例では、同期化プロセスに、ユーザ一時停止コマンドが含まれる。オーディオデコーダ９０２、オーディオレンダ９０４、ビデオデコーダ９０６、およびビデオレンダ９０８が、９１０で一時停止コマンドを受け取る。一時停止コマンドが、ムービーの再生の過程中に受け取られ、オーディオレンダ９０４が、ビデオレンダ９０８より早く一時停止コマンドを受け取ると仮定する。オーディオデコーダ９０２およびビデオデコーダ９０６は、一時停止コマンドを受け取ったときに、メディアサンプルを配信するのに使用されるバッファを使い果たすまで、それぞれ、オーディオレンダおよびビデオレンダにデコードされたサンプルを配信することができる（動作９１２、９１４）。

動作９２２で、オーディオレンダが、オーディオハードウェアを一時停止し、その結果、オーディオハードウェアが、もはやオーディオサンプルを消費しなくなる。この時点で、オーディオレンダは、動作状態から一時停止状態への遷移を完了する。しかし、オーディオドライバにキューイングされたオーディオサンプルがある。ＤＭＡカーソル位置は、オーディオハードウェアが動作状態または再生状態に再開されたときにどのオーディオサンプルが消費されるかを示す。動作９２４で、ビデオレンダが、ビデオフレームのレンダリングを停止する。この時点で、ビデオレンダは、動作状態から一時停止状態への遷移を完了する。しかし、レンダリングを待っている、ＦＩＦＯキュー内の少数のデコードされたビデオフレームがある。

オーディオレンダおよびビデオレンダは、一時停止状態ではもはやメディアサンプルを消費しないので、デコードされたサンプルを保持しているバッファは、解放されない。すぐに、デコーダがバッファを使い果たし、したがって、デコーダは、一時停止状態に入る（動作９２６および９２８）。動作９３０で、ユーザがメディアの再生を再開したときに、実行コマンドが、オーディオデコーダ９０２、オーディオレンダ９０４、ビデオデコーダ９０６、およびビデオレンダ９０８を含むすべてのモジュールに送られる。

動作９３０に応答して、オーディオレンダ９０４が、９３２で、ビデオレンダがフレームプレゼンテーションタイムスタンプ（ＰＴＳ）に従ってビデオハードウェアのために次のビデオフレームを正確にいつ作ることができるかに関して問合せを始める。前に述べたように、ビデオレンダは、ビデオハードウェアのディスプレイサイクルによって生成されるＶＢＩ信号を記憶し、その結果、ビデオレンダは、基準クロックに関して、ビデオフレームが表示される正確な時刻を判定することができる。この時刻は、ミリ秒単位でｔ_ｎ＝ｔ_０＋ｎ×３３．３４として表すことができ、ここで、ｔ_０は、現在の基準クロック時刻ｔから次のＶＢＩサイクル時間の終了時刻まで延び、ｎは、整数である（詳細については図６に関する議論を参照されたい）。

同様に、動作９３４で、オーディオレンダは、一時停止したオーディオサンプルＰＴＳおよび動作９３２の第１ビデオフレームと同一のＰＴＳを有するオーディオサンプルについて問い合わせることができる。オーディオハードウェアが一時停止した後のＤＭＡカーソル位置を読み取ることによって、オーディオレンダは、オーディオハードウェアがレンダリングする次のサンプルのＰＴＳを知ることができる。次のビデオフレームＰＴＳと次のオーディオサンプルＰＴＳの間の差（Δｔとして示される）は、ビデオレンダが開始する前にオーディオレンダが開始すべきである時間である。

次のビデオフレームは、ｔ_ｎでなければ開始できず、基準クロックに基づく現在時刻がｔなので、したがって、ｎは、Δｔ／３３．３４に１を加えたものの整数部分であり、オーディオハードウェアは、ｔ_ｎ−Δｔに再生を再開すべきである。言い換えると、オーディオハードウェアが再開する時刻が調整され、その結果、動作９４４で次のビデオフレームが表示されるときに、動作９４２で、Δｔ分のオーディオサンプルが、既に消費されている。したがって、オーディオハードウェアは、ビデオフレームＰＴＳに非常に近いＰＴＳを有するオーディオサンプルのレンダリングを開始する。このイベントの後に、オーディオレンダおよびビデオレンダは、メディアサンプルバッファの解放を開始する。これらのサンプルが消費されたならば、デコーダは、新しいメディアサンプルをレンダに配信することができる（動作９５２および９５４）。これは、オーディオレンダがビデオレンダより後に一時停止コマンドを受け取るΔｔ＜０の場合にも適用され、これは、オーディオハードウェアが、ビデオレンダより｜Δｔ｜だけ後に再開することを意味する。

結論
さまざまな概念を、上でソフトウェアベースのオーディオレンダリングおよびビデオレンダリングに関して説明した。さまざまな実装で、これらの概念を複数のコンフィギュレーションで組み合わせることができる。たとえば、ビデオクロック従属化の概念を利用して、ビデオクロックをソースなどの外部クロックに同期化しながらリアルタイムビデオレンダリングをもたらすことができる。オーディオクロックを、挿入およびデシメーションの概念を利用してビデオクロックに同期化することができる。オーディオおよびビデオのスタートアップ同期化は、オーディオレンダリングプロセスとビデオレンダリングプロセスの間の通信を容易にして、捨てられる最初のフレームの発生を最小にしながら再生時の待ち時間を減らすことができる。

ソフトウェアベースオーディオレンダリングを実装できる例示的なシステムの表現を示す図である。 ソフトウェアベースオーディオレンダリングを実装できるオペレーティング環境の例示的なシステム、デバイス、およびコンポーネントを示す図である。 例示的なソフトウェアベースオーディオレンダリングプロセスを示す流れ図である。 例示的なソフトウェアベースオーディオレンダリング実装に関連するタイムラインおよびイベントの表現を示す図である。 例示的なソフトウェアベースビデオレンダリング実装に関連するタイムラインおよびイベントの表現を示す図である。 例示的なソフトウェアベースビデオレンダリング実装に関連するタイムラインおよびイベントの表現を示す図である。 例示的なソフトウェアベースビデオレンダリングプロセスを示す流れ図である。 例示的なソフトウェアベースビデオレンダリングプロセスを示す流れ図である。 ソフトウェアベースオーディオレンダリングとソフトウェアベースビデオレンダリングを同期化する例示的な実装に関連するタイムラインおよびイベントの表現を示す図である。 ソフトウェアベースオーディオレンダリングとソフトウェアベースビデオレンダリングを同期化する例示的な実装に関連するタイムラインおよびイベントの表現を示す図である。

符号の説明

１０２ コンピューティングデバイス
１０４ ディスプレイデバイス
１１０ ソース
１１２ パーサ
１１４ オーディオデコーダ
１１５Ａ オーディオバッファ
１１５Ｂ オーディオバッファ
１１６ オーディオレンダリングエンジン
１１８ オーディオハードウェア
１２０ ビデオデコーダ
１２２Ａ ビデオバッファ
１２２Ｂ ビデオバッファ
１２４ ビデオレンダリングエンジン
１２６ グラフィックスハードウェア
１２８ ＴＶエンコーダ
２４４ 処理ユニット
２４６ システムメモリ
２４８ バス
２５０ ＲＯＭ
２５２ ＲＡＭ
２５４ ＢＩＯＳ
２６６ ＳＣＳＩインターフェース
２６８ シリアルポート
２７０ オペレーティングシステム
２７２ アプリケーションプログラム
２７４ 他のモジュール
２７６ プログラムデータ
２７８ キーボード
２８２ キーボード／マウスインターフェース
２８６ ビデオハードウェア
２９０ ローカルエリアネットワーク
２９２ 広域ネットワーク
２９４ ネットワークインターフェース
２９６ モデム
２９８ チューナコンポーネント

Claims (9)

1. ソースから受け取ったオーディオサンプルを処理するためのオーディオハードウェアを含むコンピュータに、
   外部クロックとオーディオクロックとの間の差であるドリフトが累積するレートである第１のドリフトレートを測定するステップであって、前記オーディオサンプルは前記ソースにより前記外部クロックにしたがって供給され、前記オーディオサンプルは前記オーディオハードウェアにより前記オーディオクロックにしたがって消費されるステップと、
   前記ドリフトが第１閾値に達したことに応答し、第２ドリフトレートを達成するために、前記オーディオハードウェアにより消費されるオーディオサンプルの数を調整するステップであって、前記第２ドリフトレートは、前記第１ドリフトレートより大きさが小さく、前記第１ドリフトレートと反対の極性を有するステップと
   を実行させることを特徴とするコンピュータプログラム。
2. 前記調整するステップは、
   前記ドリフトが前記第２ドリフトレートで第２閾値に達するように、前記オーディオクロックをさらに操作するステップを含み、前記第２閾値は前記第１閾値より小さい大きさを有し、前記第１の閾値と反対の極性を有することを特徴とする請求項１に記載のコンピュータプログラム。
3. 前記さらに操作するステップは、前記第２のドリフトレートより大きさが小さく、かつ所定の時間内に前記ドリフトを打ち消す第３ドリフトレートを判定するステップを含むことを特徴とする請求項２に記載のコンピュータプログラム。
4. 前記ドリフトが前記所定の時間内に前記第２閾値の対向する極性の間で振動する最小値が確立されるまで、徐々に小さくなるドリフトレートを計算するステップをさらに前記コンピュータに実行させることを特徴とする請求項３に記載のコンピュータプログラム。
5. 前記第２閾値は、前記オーディオクロックに固有のジッタの大きさの少なくとも２倍であり、前記第２ドリフトレートで前記ドリフトが反対の極性の前記第２閾値に達することを特徴とする請求項２に記載のコンピュータプログラム。
6. 前記第２ドリフトレートで、前記ドリフトは、負の極性の前記第２閾値から正の極性の前記第２閾値まで達するのに要する時間と同一の時間で正の極性の前記第２閾値から負の極性の前記第２閾値に達することを特徴とする請求項２に記載のコンピュータプログラム。
7. ソースから受け取ったオーディオサンプルを処理するためのオーディオハードウェアを含むコンピュータに、
   オーディオクロックレートを測定するステップであって、前記オーディオサンプルは前記ソースにより外部クロックにしたがって供給され、前記オーディオサンプルは前記オーディオハードウェアにより前記オーディオクロックにしたがって消費されるステップと、
   前記外部クロックレートと前記オーディオクロックレートとの差であるドリフトが振動するように、前記オーディオハードウェアにより消費される前記オーディオサンプルの数を調整するステップと、
   をコンピュータに実行させ、前記操作するステップは、
   前記第１閾値を選択するステップと、
   前記ドリフトが前記第１閾値と等しいときに、前記ドリフトが累積するレートであるドリフトレートを低減するために前記オーディオクロックを調整するステップと、
   前記ドリフトが前記第２閾値に達したときに、前記ドリフトを打ち消すように前記オーディオクロックをさらに操作するステップであって、前記第２閾値は前記第１閾値より小さい値を有し、前記第１閾値と反対の極性を有するステップと
   を含むことを特徴とするコンピュータプログラム。
8. 前記オーディオクロックを調整するステップは、ソースからの少なくとも１つのオーディオフレームを２回レンダリングするステップを含むことを特徴とする請求項７に記載のコンピュータプログラム。
9. 前記さらに操作するステップは、少なくとも１つのオーディオサンプルを破棄することを含むことを特徴とする請求項７に記載のコンピュータプログラム。

Images