(57)【要約】【課題】ストリーミングコンテンツをクライアント再生デバイスに配信するホストデバイスとクライアントデバイスとの間のクロックドリフトを検出する方法を提供する。【解決手段】クライアントデバイス上のバッファモニタは、クライアントバッファを監視し、クライアントバッファ内のデータのレベルを示すバッファ占有量レポートを生成する。バッファモニタは、バッファ占有量レポートをホストデバイス上のクロックドリフト検出および復旧コンポーネントに送信する。クロックドリフト検出および復旧コンポーネントは、バッファ占有量レポートから、クライアントデバイスクロックとホストデバイスクロックとの間のクロックドリフトの程度を判別する。【選択図】図２
2006222976.tif 000002
【特許請求の範囲】
【請求項１】
ホストデバイスからストリーミングコンテンツを受信すること、
前記ストリーミングコンテンツのデータをクライアントデバイスバッファ内に保持すること、
前記バッファ内のデータのレベルを反映するバッファ占有量レベルを監視すること、および、
前記監視することに基づき、ホストクロックとクライアントクロックとの間にクロックドリフトが存在するかどうかを判定すること
を備えることを特徴とする方法。
【請求項２】
前記判定することは、
一定時間間隔でバッファ占有量レベルをプロットすること、
前記プロットすることにより形成される直線の平均勾配を計算すること、および、
前記直線の前記平均勾配を監視すること
を備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記直線の前記平均勾配はゼロであり、前記判定することは前記ホストクロックと前記クライアントクロックとの間にクロックドリフトがないと判定することを備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記直線の前記平均勾配は負であり、前記判定することは前記クライアントクロックが前記ホストクロックよりも速いと判定することを備えることを特徴とする請求項２に記載の方法。
【請求項５】
前記直線の前記平均勾配は正であり、前記判定することは前記クライアントクロックが前記ホストクロックよりも遅いと判定することを備えることを特徴とする請求項２に記載の方法。
【請求項６】
前記計算することは、前記ストリーミングコンテンツが伝送されるネットワークの帯域幅変動を除去することを備えることを特徴とする請求項２に記載の方法。
【請求項７】
前記監視することおよび前記判定することは前記ホストデバイス上で実行され、前記監視することはバッファ占有量レベルレポートを前記クライアントデバイスから前記ホストデバイスに送信することを備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記判定することは、前記ホストクロックと前記クライアントクロックとの間にクロックドリフトがある場合に前記ホストデバイスに通知することを備え、前記監視すること、および前記判定することは、
前記クライアントデバイス、および、
前記ホストデバイスおよび前記クライアントデバイスと異なる第３のデバイス
を含むグループから選択されるデバイス上で実行されることを特徴とする請求項１に記載の方法。
【請求項９】
【数１】
2006222976.tif 000005
にしたがって、クロックドリフト量を計算することをさらに備え、
ただし、
前記クロックドリフト量はｃｈ−ｃｃに等しく、
ｃｈは、前記ホストクロックの周波数であり、
ｃｃは、前記クライアントクロックの周波数であり、
ｄｐｃは、単位をビット／秒とする前記ホストデバイス上の指定されたデータ生成速度であり、
ｆ０は、時刻０における前記バッファ占有量レベルであり、
ｆｔは、時刻ｔにおける前記バッファ占有量レベルである
ことを特徴とする請求項１に記載の方法。
【請求項１０】
前記ホストクロックと前記クライアントクロックとの間の前記クロックドリフトを除去するクロック復旧方法を実施することをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１１】
前記実施することは、
前記クライアントクロックを調整すること、
前記ホストクロックを調整すること、
前記ホストデバイスからの前記ストリーミングコンテンツを変更すること、および、
前記クライアントデバイス上でデータフレームを落とすこと
を含むグループから選択されることを特徴とする請求項１０に記載の方法。
【請求項１２】
プロセッサ実行可能命令を格納するプロセッサ読み取り可能記録媒体であって、前記命令は、
ホストデバイスからクライアントデバイスへストリーミングコンテンツを伝送し、
一定の測定時間間隔にわたって前記クライアントデバイス上のデータバッファのバッファ占有量レベルを監視し、
前記監視に基づき、前記ホストデバイス上のホストクロックと前記クライアントデバイス上のクライアントクロックとの間にクロックドリフトが存在するかどうかを判定する
ように構成されることを特徴とするプロセッサ読み取り可能記録媒体。
【請求項１３】
前記判定することは、
前記一定の測定時間間隔にわたる前記バッファ占有量レベルの変化率を計算すること、および、
前記バッファ占有量レベルの前記変化率に基づき、前記クロックドリフトは存在すると判定すること
を備えることを特徴とする請求項１２に記載のプロセッサ読み取り可能記録媒体。
【請求項１４】
前記バッファ占有量レベルの前記変化率は一定の正の変化率であり、前記クロックドリフトが存在するとの前記判定は前記クライアントクロックが前記ホストクロックよりも低い周波数で動作していると判定することを備えることを特徴とする請求項１３に記載のプロセッサ読み取り可能記録媒体。
【請求項１５】
前記バッファ占有量レベルの前記変化率は一定の負の変化率であり、前記クロックドリフトが存在するとの前記判定は前記クライアントクロックが前記ホストクロックよりも高い周波数で動作していると判定することを備えることを特徴とする請求項１３に記載のプロセッサ読み取り可能記録媒体。
【請求項１６】
前記バッファ占有量レベルの前記変化率に基づきクロックドリフト量を計算するように構成されたプロセッサ実行可能命令をさらに格納することを特徴とする請求項１３に記載のプロセッサ読み取り可能記録媒体。
【請求項１７】
前記クロックドリフト量は、
【数２】
2006222976.tif 000006
にしたがって計算され、
ただし、
前記クロックドリフト量はｃｈ−ｃｃに等しく、
ｃｈは、前記ホストクロックの周波数であり、
ｃｃは、前記クライアントクロックの周波数であり、
ｄｐｃは、単位をビット／秒とする前記ホストデバイス上の指定されたデータ生成速度であり、
ｆ０は、時刻０における前記バッファ占有量レベルであり、
ｆｔは、時刻ｔにおける前記バッファ占有量レベルである
ことを特徴とする請求項１６に記載のプロセッサ読み取り可能記録媒体。
【請求項１８】
ホストデバイスからメディアコンテンツを受信し、前記メディアコンテンツを再生するように構成されたクライアントデバイス、
クライアントバッファを監視し、前記クライアントバッファ内のデータ量を示すバッファ占有量レポートを生成するように構成された前記クライアントデバイス上のバッファモニタ、および、
前記バッファ占有量レポートからホストクロックとクライアントクロックとの間にクロックドリフトが存在するかどうかを判定するように構成されたクロックドリフト検出および復旧モジュール
を備えることを特徴とするシステム。
【請求項１９】
前記クロックドリフト検出および復旧モジュールは、前記バッファモニタから前記バッファ占有量レポートを受信し、前記クロックドリフトを修正する復旧方法を実施するように前記ホストデバイス上で構成されることを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記ホストデバイス上にクロック復旧モジュールをさらに備え、前記クロックドリフト検出および復旧モジュールは、さらにクロックドリフト情報を前記クロック復旧モジュールに送信するように構成され、前記クロック復旧モジュールは、前記クロックドリフトを修正する復旧方法を実施するように構成されることを特徴とする請求項１８に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、一般に、デジタルメディア再生システムに関し、より詳細には、そのようなシステム内でメディアストリームの再生を調整することに関する。
【背景技術】
【０００２】
オーディオ、ビデオ、および／またはテキストメディアコンテンツのストリーミングなどのデジタルメディアストリーミングは、ますます普及しつつある。「ストリーミング」という用語は、通常、メディアコンテンツを表すデータが、ネットワーク経由でホストコンピュータデバイスによりクライアントデバイス（すなわち、デスクトップＰＣ、ノートブックまたはポータブルコンピュータ、携帯電話またはその他の無線通信デバイス、携帯情報端末（ＰＤＡ）、ゲーム機、ＩＰセットトップボックス、ハンドヘルドＰＣなどの様々な従来のコンピューティングデバイスとして実装されるメディア再生デバイス）に提供されることを示すために使用される。クライアントデバイスは、すべてのコンテンツまたは完全な「ファイル」が配信されるのを待つことなく、ストリーミングコンテンツをホストから受信しながらストリーミングコンテンツをレンダリングする。
【０００３】
メディアコンテンツは、ネットワーク経由で「ストリーミング」される場合、通常、データパケットの形でストリーミングされる。しかし、データパケットが、送信されたときの順序と同じ順序で送信先に届くという保証はなく、あるいは、その送信先に届くという保証さえも常にあるわけではない。さらに、通常、データパケットが送信元から送信先へ伝わるのに要する時間は特定の持続時間であるという保証も、あるいは、その時間が異なるデータパケットについても同じであるという保証もない。
【０００４】
クライアントデバイスへのデータ配信のこれらの変動に対処するため、クライアントデバイスでは、通常、データのバッファを保持する。バッファを使用することにより、クライアントデバイスはデータ配信の変動を除去し、コンテンツの再生時にユーザに気付かれないようにすることができる。そのため、例えば、ネットワーク輻輳によってネットワーク帯域幅に短い障害が生じても（例えば、ネットワーククロストラフィック（network cross-traffic）、干渉、無線受信不良）、ほとんどの場合、バッファ内のデータ量によりクライアントデバイスはメディアコンテンツの再生を続けることができ、ユーザは障害の影響（例えば、再生の中断または一時停止）を受けることがない。しかし、場合によっては、例えば、ネットワークの障害によりデータ配信に変動が生じると、バッファ内のデータが枯渇し、再生の中断または一時停止が生じることがある。
【０００５】
クライアントバッファが断続的に不足し、メディアコンテンツ再生中に周期的な中断を引き起こす別の問題は、ホストデバイス（すなわち、ストリーミングコンテンツを符号化し、送信するソースデバイス）およびクライアントデバイス（すなわち、ストリーミングコンテンツを受信し、再生するデバイス）に異なるクロック周波数が存在することである。すなわち、クライアントデバイス上の再生を調整するクライアントクロックは、ホスト／ソースデバイス上の符号化プロセスを調整するホストクロックとわずかに異なる周波数で動作する場合がある。ホストクロックとクライアントクロックとの間にクロックドリフトがあると、クライアントバッファは、再生のメディアコンテンツを使い果たす場合がある。クライアントクロックの動作がホストクロックよりも速い場合、クライアントは、ホストが補充できる速度よりもわずかに速い速度でクライアントバッファのメディアコンテンツを消費することになる。この場合、クライアントバッファは、断続的にメディアコンテンツを使い果たし、バッファの回復のために、周期的な一時停止または中断がメディア再生時に発生する。逆に、クロックドリフトは、クライアントバッファをメディアコンテンツでオーバーフローさせる原因となる場合もある。クライアントクロックの動作がホストクロックよりも遅い場合、クライアントは、ホストがバッファに補充する速度よりもわずかに遅い速度でクライアントバッファからのメディアコンテンツを消費することになる。この場合、クライアントバッファはメディアコンテンツでオーバーフローする。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
したがって、ストリーミングコンテンツをクライアント再生デバイスに配信するホストデバイスとクライアントデバイスとの間のクロックドリフトを検出する方法が必要とされる。
【課題を解決するための手段】
【０００７】
デジタルメディアシステムおよび方法では、クライアントバッファ占有量レポートを使用して、ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間のクリックドリフトを検出する。
【０００８】
一実施形態では、クライアントデバイス上のバッファモニタは、クライアントバッファを監視し、クライアントバッファ内のデータのレベルを示すバッファ占有量レポートを生成する。バッファモニタは、バッファ占有量レポートをホストデバイス上のクロックドリフト検出および復旧コンポーネントに送信する。クロックドリフト検出および復旧コンポーネントは、バッファ占有量レポートから、クライアントデバイスクロックとホストデバイスクロックとの間のクロックドリフトの程度を判別する。クライアントクロックとホストクロックとの間にクロックドリフトがある場合、クロックドリフト検出および復旧コンポーネントは、クロックを同期させる復旧方法を実施する。
【０００９】
他の実施形態では、クライアントデバイス上のバッファモニタは、バッファ占有量レポートをクライアントデバイス上のクロックドリフト検出および復旧コンポーネントに送信する。クライアントデバイス上のクロックドリフト検出および復旧コンポーネントは、クライアントクロックとホストクロックとの間のクロックドリフトの程度を判別し、クロックを同期させる復旧方法をクライアントデバイス上で実施する。さらに他の実施形態では、クライアントデバイス上のクロックドリフト検出および復旧コンポーネントは、検出されたクロックドリフトに関するメッセージをホストデバイスに送信し、ホストデバイス上のクロック復旧コンポーネントは、クロックを同期させる復旧方法を実施する。クロックドリフト検出および復旧コンポーネントは、さらに、第３のデバイス（例えば、専用制御デバイス）上に存在し、バッファ占有量レポートをクライアントから受信することもできる。ここでもまた、クロックドリフト検出および復旧コンポーネントは、クライアントクロックとホストクロックとの間のクロックドリフトの程度を判別し、クロックを同期させる復旧方法を実施する。
【発明を実施するための最良の形態】
【００１０】
（はじめに）
以下の説明は、ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間のクロックドリフトを検出するデジタルメディアシステムおよび方法に関する。ホストクロックは、ホストデバイス上のストリーミングメディアの符号化を調整し、クライアントクロックは、クライアントデバイス上のストリーミングメディアの再生を調整する。説明されているシステムおよび方法の利点は、ストリーミングメディアコンテンツの再生時の再生中断を低減すること、およびホスト／ソースデバイスにより符号化された「ライブ」コンテンツがクライアントデバイス上の再生を通じて「ライブ」コンテンツとして実際に体験できる可能性を高めることを含む。
【００１１】
（例示的環境）
図１は、ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間のクロックドリフトを検出するのに好適な例示的環境１００を示している。ネットワーク１０６は、様々な従来のネットワークプロトコル（公開および／または非標準プロトコルを含む）のいずれかを使用して、様々な従来のネットワークトポロジおよびタイプ（光、有線および／または無線ネットワークを含む）のいずれかを表すことが意図されている。例えば、ネットワーク１０６は、家庭ネットワーク、企業ネットワーク、またはインターネットに加え、場合によっては、１つまたは複数のローカルエリアネットワーク（ＬＡＮ）および／またはワイドエリアネットワーク（ＷＡＮ）の少なくとも一部を含むことができる。
【００１２】
ホスト／ソースデバイス１０２は、一般に、メディアファイルなどの格納されたメディアコンテンツ、および／または生放送のケーブルテレビ配信またはウェブ放送などのライブメディアコンテンツへのアクセスを提供する。ホストデバイス１０２は、要求があると、クライアント再生デバイス１０４にメディアコンテンツをストリーミングする。クライアントデバイス１０４は、一般に、ホストデバイス１０２からストリーミングメディアコンテンツを受信し、ユーザに対してストリーミングメディアコンテンツを再生する。クライアントデバイス１０４からのホストデバイス１０２上で利用可能なストリーミングメディアコンテンツの要求は、ネットワーク１０６を介してクライアントデバイス１０４からホストデバイス１０２に送られる。ホストデバイス１０２は、ネットワーク１０６を介して、その要求を受信し、要求されたコンテンツを要求元クライアントデバイス１０４に返す。
【００１３】
ホストデバイス１０２は、格納されたメディアコンテンツおよび／またはライブメディアコンテンツをクライアントデバイス１０４にストリーミングするために構成可能な、例えばデスクトップＰＣ、ノートブックまたはポータブルコンピュータ、ワークステーション、メインフレームコンピュータ、インターネット家電、それらの組合せなどを含む、様々な従来のコンピューティングデバイスのいずれかとして実装することができる。クライアント再生デバイス１０４もまた、例えばデスクトップＰＣ、ノートブックまたはポータブルコンピュータ、ワークステーション、メインフレームコンピュータ、インターネット家電、ゲーム機、ハンドヘルドＰＣ、携帯電話またはその他の無線通信デバイス、携帯情報端末（ＰＤＡ）、セットトップボックス、それらの組合せなどを含む、様々な従来のコンピューティングデバイスのいずれかとして実装することができる。ホストデバイス１０２およびクライアントデバイス１０４を実装するための例示的コンピューティング環境は、図８を参照しながら以下でより詳しく説明する。
【００１４】
ホストデバイス１０２は、オーディオ、ビデオ、テキスト、イメージ、アニメーションなどのコンテンツを含む様々なデータを、クライアント再生デバイス１０４へストリーミングするのに利用できる状態にすることができる。しかし、後述の例示的実施形態に関して本明細書で使用されているように、メディアコンテンツ２００は、オーディオ／ビデオ（Ａ／Ｖ）コンテンツまたは単なるビデオコンテンツを表すことが意図されている。さらに、本明細書の「メディアコンテンツ」、「ストリーミングメディア」、「ストリーミングビデオ」、「ビデオコンテンツ」、およびそれらの変更形態に対する言及は、一般に、オーディオ／ビデオコンテンツを含むことが意図されている。「ストリーミング」という用語は、メディアコンテンツを表すデータがネットワーク経由でクライアント再生デバイス１０４に提供されること、およびコンテンツ全体が配信される前にコンテンツの再生が開始できることを示すために使用される。データは、公開利用可能とすることも、あるいは制限することもできる（例えば、特定のユーザにのみ制限する、適切な料金が支払われる場合のみ利用可能とする、特定のネットワークへのアクセス権を有するユーザに制限する、など）。さらに、データは、「オンデマンド」（例えば、事前に記録され、格納されている既知のサイズのコンテンツ）、あるいはライブ「ブロードキャスト」（例えば、コンサートが上演され、取込み後まもなくストリーミングで利用できる状態にするときに取込まれているコンサートのデジタル表現などの、既知のサイズを有さないもの）とすることができる。
【００１５】
（例示的実施形態）
図２は、ストリーミングメディアコンテンツを配信するホスト／ソースデバイス１０２上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス１０４上のクロックとの間のクロックドリフトを検出するのに好適なデジタルメディアシステムの例示的実施形態を示している。ホストデバイス１０２は、一般に、ホストデバイス１０２のホストクロック２０２により調整される速度でメディア／ビデオコンテンツ２００を符号化するように構成される。その後、ホストデバイス１０２は、ネットワーク１０６経由で、符号化されたメディア／ビデオコンテンツ２００をクライアントデバイス１０４に格納および／またはストリーミングすることができる。クライアントデバイス１０４は、一般に、ストリーミングメディア／ビデオコンテンツ２００を受信し、クライアントデバイス１０４のクライアントクロック２０４により調整される速度でストリーミングコンテンツを再生するように構成される。
【００１６】
本実施形態では、ホストデバイス１０２は、クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在するかどうかを判定するために構成されたクロックドリフト検出および復旧モジュール２０６を備える。検出および復旧モジュール２０６は、（１つ以上の）クライアントメディアバッファ２０８に関してクライアントデバイス１０４から受信する情報に基づきクロックドリフトを判定する。クライアントデバイス１０４は、バッファ占有量レポート２１０という形態で、バッファ情報をホストデバイス１０２に提供する。バッファ占有量レポート２１０は、ホストデバイス１０２からクライアントデバイス１０４にメディアコンテンツ２００をストリーミングしているときにクライアントデバイス１０４上で（１つ以上の）クライアントメディアバッファ２０８に存在するデータのレベルを示す。バッファ占有量レポート２１０により示されるデータのレベルは、オーディオバッファ２０８（１）内のオーディオデータ２１２のレベルおよび／またはビデオバッファ２０８（２）内のビデオデータ２１４のレベルを含むことができる。ホストデバイス１０２上のクロックドリフト検出および復旧モジュール２０６は、以下で詳しく説明するように、クライアントデバイス１０４から受け取ったバッファ占有量レポート２１０（２）に基づいてクロックドリフトを判定する。
【００１７】
ホストデバイス１０２は、クライアントデバイス１０４上のメディア再生アプリケーション２１６により選択可能なメディアコンテンツ２００の１つまたは複数のファイルを保持する（例えば、メディア再生アプリケーション２１６を経由するユーザ入力に応答して）。さらに、ホストデバイス１０２は、要求があった場合にクライアント再生デバイス１０４にストリーミングする生放送のケーブルテレビ配信またはウェブ放送などのライブコンテンツへのアクセスを提供する。本実施形態では、メディアコンテンツ２００は、通常、オーディオコンポーネントを備えるビデオコンテンツと考えられる。したがって、上述したように、本明細書の「メディアコンテンツ」、「ストリーミングメディア」、「ストリーミングビデオ」、「ビデオコンテンツ」、およびそれらの変更形態に対する言及は、一般に、オーディオ／ビデオ（Ａ／Ｖ）および／またはビデオコンテンツを意味することが意図されている。ホストデバイス１０２は、要求されたメディアコンテンツ２００をネットワーク１０６経由でデータのストリームとしてクライアントデバイス１０４上のメディア再生アプリケーション２１６に送信する。
【００１８】
クライアントデバイス１０４は、ネットワーク１０６経由でのデータ配信の変動（例えば、ネットワーククロストラフィック、干渉、無線受信不良などにより生じるネットワーク障害）を除去する手段として、（１つ以上の）メディアバッファ２０８を保持するため、その変動はコンテンツの再生中にユーザに気付かれない。良好なネットワーク条件下では、（１つ以上の）バッファ２０８の占有量レベルは、比較的高く（例えば、占有率８０％より大）、正常な占有量レベルを示すであろう。（１つ以上の）バッファ２０８の占有量レベルが高い場合は、一般に、（１つ以上の）バッファ２０８内のすべてのメディアンコンテンツだけでなくホストデバイス１０２からの残りのストリーミングメディアコンテンツのリアルタイム再生が可能となる。
【００１９】
クライアントデバイス１０４上のバッファモニタ２１８は、メディアコンテンツ２００がホストデバイス１０２からストリーミングされている間に、（１つ以上の）バッファ２０８の占有量レベルを監視し、バッファ占有量レポート２１０（１）を生成するように構成される。バッファ占有量レポート２１０は、クライアントデバイス１０４がバッファ占有量情報をホストデバイス１０２にレポートする場合に使用する機構である。一般に、この情報は、クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在するかどうかを判定するために、ホストデバイス１０２上のクロックドリフト検出および復旧モジュール２０６によって使用される。
【００２０】
図３は、ホストデバイス１０２がメディアコンテンツをクライアントデバイス１０４にストリーミングする際の時間経過とともにクライアントメディアバッファ２０８の占有量レベルがどのように変わるかを示す４つの事例を示している。各事例において、バッファ２０８は、約８０％の比較的高いまたは正常な占有量レベルで始まる。プロットされた直線３００により示される第１の事例では、バッファ占有量レベルは時間経過とともに緩やかに増加している。これは、バッファ２０８内のデータが消費されるよりも速く補充されていることを示す。この事例では、バッファ２０８は最終的にデータでオーバーフローし、その結果、通常、オーバーフローデータ（フレーム）は、クライアント１０４により破棄され／落とされて再生されないか、またはホストデバイス１０２上のホストバッファ（図示せず）に格納される。プロットされた直線３０２により示される第２の事例では、バッファ占有量レベルは時間が経過しても同じままである。これは、バッファ２０８内のデータが消費されるのと同じ速さで補充されていることを示す。プロットされた直線３０４により示される第３の事例では、バッファ占有量レベルは時間経過とともに緩やかに減少している。これは、バッファ２０８内のデータが消費されるよりも遅く補充されていることを示す。第３の事例では、バッファ２０８は最終的に枯渇し、バッファ２０８を回復する（すなわち、データが補充される）間、クライアントデバイス１０４上でメディア再生の一時停止または中断が生じることになる。プロットされた直線３０６により示される第４の事例では、バッファ占有量は時間経過とともに急激に減少するが、これは、バッファ２０８内のデータが、消費されるよりもかなり遅い速度で補充されていることを示す。
【００２１】
クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在するかどうかを判定するために、ホストデバイス１０２上のクロックドリフト検出および復旧モジュール２０６は、クライアントデバイス１０４上のバッファモニタ２１８により生成されたバッファ占有量レポート２１０（２）を受け取り、バッファ占有量レポート２１０（２）の中に示されているように、経時的にバッファ占有量レベルをプロットする。したがって、クロックドリフト検出および復旧モジュール２０６は、図３に関して上で例示され、説明されているようなプロットを生成することができる。クロックドリフト検出および復旧モジュール２０６は、プロットにより生成された直線の勾配を監視し、クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在するかどうかを判定する。一般に、緩やかに傾斜する直線は、正の勾配でも負の勾配でも、クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在することを示す。以下で詳しく説明するように、ネットワークジッタを除去するため、経時的に勾配の平均をとる。
【００２２】
例えば、図３を再び参照すると、直線３００などの直線をプロットしている間に、クロックドリフト検出および復旧モジュール２０６は、直線３００が緩やかな勾配を持つため、クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在することを示していると判定する。さらに、直線３００の勾配は正であるため、クロックドリフト検出および復旧モジュール２０６は、ホストデバイス１０２（ホストクロック２０２により調整される）がデータを補充するよりも遅い速度でバッファ２０８内のデータが消費される（すなわち、クライアント１０４上の再生アプリケーション２１６により再生される）ので、クライアントクロック２０４はホストクロック２０２よりも遅い速度で動作していると判定する。同様に、バッファ占有量プロット２１０（２）から生成される他のプロットについて、検出および復旧モジュール２０６は、プロットされた直線の勾配からクライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在したかどうかを判定する。例えば、図３に示される直線３０２に関して、検出および復旧モジュール２０６は、直線３０２の勾配がゼロであるためクロックドリフトはないと判定する。直線３０４に関して、検出および復旧モジュール２０６は、直線の緩やかな負の勾配から、クロックドリフトが存在していたこと、およびホストデバイス１０２がデータを補充するよりも速い速度でバッファ２０８内のデータが消費されるので、クライアントクロック２０４はホストクロック２０２よりも速い速度で動作していたと判定する。直線３０６に関して、検出および復旧モジュール２０６は、直線３０６の急激な負の勾配から、クライアントバッファ２０８の急速な減少を引き起こしている、ネットワーク機能停止などの、単なるクロックドリフトを超えた状況にあると判定する。ネットワークから入ってくるメディアコンテンツの速度はネットワーク機能停止の場合にはゼロに近づくが、ネットワーク機能停止ではない場合には平均して、一定のままである可能性が高いので、ネットワーク機能停止は、クロックドリフトと区別できる。さらに、ネットワーク輻輳時には、メディアコンテンツの流れは遅くなる場合があるが、完全にゼロに落ちることはない。例えば、ネットワーク容量がストリームのビットレートよりも低い場合（例えば、５．５Ｍｂｐｓのネットワーク上で６Ｍｂｐｓのストリームを送信しようとした場合）、クライアントデバイス１０４上のバッファ占有量は、時間経過とともに枯渇することがある。ネットワークレベルでの再送／損失パケットの数、時間経過による往復時間の変動、または他の統計量などの追加的な統計量を監視すると、そのようなネットワーク過負荷を識別することができる。したがって、ネットワーク制限によるものと判断されるバッファ枯渇の結果は、クロックドリフトがホストクロックとクライアントクロックとの間に存在するかどうかを判定するときに除去することができる。
【００２３】
図４は、プロットされた直線４００によって示されるように、ネットワーク帯域幅の変動に起因してバッファ占有量レベルが時間経過とともに変動する、追加的な事例を示している。この事例では、バッファ占有量は、時間経過とともに直線的に増加または減少するように見えないかもしれない。しかし、ネットワーク帯域幅の変動は、時間範囲を広くとってバッファ占有量を平均し、その結果をプロットすることにより除去することができる（例えば、プロットされた直線４０２）。その後、検出および復旧モジュール２０６は、プロットされた直線４０２の勾配を計算し、バッファ占有量は、実際に、一定速度で減少していると判定することができる。したがって、上述したように、検出および復旧モジュール２０６は、直線４０２の緩やかな負の勾配から、クロックドリフトが存在し、クライアントクロック２０４がホストクロック２０２よりも速い速度で動作していると判定する。
【００２４】
クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在するかどうかを判定することに加えて、検出および復旧モジュール２０６は、ホストクロック２０２とクライアントクロック２０４との間のクロック速度差を計算する。様々な数学的モデル（例えば、数学的ローパスフィルタ処理、統計解析など）は、クライアントバッファ２０８からのバッファ占有量データに基づいて、ホストクロック２０２とクライアントクロック２０４との間のクロック速度差を計算するときに有用である。一実施例においては、ホストクロック２０２とクライアントクロック２０４との間のクロック速度差は、以下の定義および式（１）、（２）、および（３）により定義される。    
ｒｈ−ｒｃ＝ｄｐｃ＊（ｃｈ−ｃｃ）          （１）
【００２５】
ｃｈは、ホストクロック２０２の実速度であり、単位はヘルツ（Ｈｚ）である。
【００２６】
ｃｃは、クライアントクロック２０４の実速度であり、単位はヘルツである。
【００２７】
ｄｐｃは、データストリームの仕様上の（すなわち、指定される値に基づく予想値）データ速度を示す定数である。すなわち、ｄｐｃは、ホストデバイス１０２とクライアントデバイス１０４の両方の仕様上のデータ速度に等しい。
【００２８】
ｒｈは、ホストデバイス１０２上のデータ生成の実速度であり、ヘルツを単位とする、仕様上のデータ速度（ビット／秒）＊ｃｈ／仕様上のホストクロック速度で表される。したがって、以下のようになる。    
ｒｈ＝ｃｈ＊ｄｐｃ
【００２９】
ｒｃは、クライアントデバイス１０４上のデータ消費の実速度であり、ヘルツを単位とする、仕様上のデータ速度（ビット／秒）＊ｃｃ／仕様上のクライアントクロック速度で表される。したがって、以下のようになる。    
ｒｃ＝ｃｃ＊ｄｐｃ
【００３０】
したがって、上記の式（１）は、ｒｈからｒｃを引くことにより導かれる。式（１）は、それに代わって、以下の定義および式（２）によりバッファ占有量と時間に関して表すことができる。    
ｒｈ−ｒｃ＝（ｆｔ−ｆ０）／ｔ          （２）
【００３１】
ｆ０は、時刻０でのバッファ占有量（データのビット数）であり、時刻０でのバッファ占有率にバッファ２０８のサイズ（ビット数）を乗じたものである。
【００３２】
ｆｔは、時刻ｔでのバッファ占有量（データのビット数）であり、時刻ｔでのバッファ占有率にバッファ２０８のサイズ（ビット数）を乗じたものである。
【００３３】
上記の式（１）と（２）を等しいとおくことによって、ホストクロック２０２とクライアントクロック２０４との間のクロック速度差（すなわち、クロックドリフト量）についての解は、以下の式（３）のように明らかである。    
ｄｐｃ＊（ｃｈ−ｃｃ）＝（ｆｔ−ｆ０）／ｔ
【００３４】
【数１】
2006222976.tif 000003
【００３５】
ｆｔ、ｆ０、およびｔの値は、グラフを生成するために使用されたデータから（すなわち、バッファ占有量レポート２１０（２）のデータから）決定することができる。数量（ｆｔ−ｆ０）／ｔは、バッファ占有量レポート２１０（２）に基づいてプロットされた直線の勾配から求められる。したがって、クロックドリフト検出および復旧モジュール２０６は、式（３）に基づいて、クライアントクロック２０４とホストクロック２０２との間のクロックドリフト量を容易に計算することができる（すなわち、数量ｃｈ−ｃｃにより示されるクロック速度差）。
【００３６】
上記の計算において、平均ネットワーク容量は、時間を通じてホストデバイス１０２によって送信されているメディアストリームのビットレートよりも高いと仮定している。ネットワーク容量がストリームのビットレートよりも低い場合、クライアントデバイス１０４上のバッファ占有量も、時間経過とともに枯渇する可能性がある。ネットワーク過負荷を識別できるネットワークレベルでの再送／損失パケット数、時間経過に伴う往復時間の変動、または他の統計量などの追加的な統計量を監視することで、ネットワーク容量が時間を通じてストリームのビットレートよりも低い可能性がある場合について上述した結果を改善することができる。
【００３７】
クライアントクロック２０４とホストクロック２０２との間にクロックドリフトがあると判定し、クロックドリフト量を計算した後、検出および復旧モジュール２０６は、クロックを同期させる復旧方法を実施することができる。例えば、ホストデバイス１０２は、クロック変更要求をクライアント１０４に送信し、クライアントにクライアントクロック２０４の速度を上げる、または下げるよう指示することができる。クライアントクロック２０４がホストクロック２０２よりも遅れる場合、ホストデバイス１０２は、ホストクロック２０２に対するクライアントクロック２０４の遅れを取り戻すため、クライアント１０４にストリーミングするメディアコンテンツ２００から一部のビデオフレームを落とすこともできる。ホストデバイス１０２は、さらに、クロックを同期させるため自クロックを調整することもできる。クライアントクロック２０４およびホストクロック２０２を同期させることにより、ホストクロック２０２よりも速い速度でクライアントクロック２０２が動作する結果としてクライアントバッファ２０８が枯渇するときに生じる可能性がある再生中断を低減することができる。さらに、クライアントクロック２０４とホストクロック２０２を同期させることにより、ホストクロック速度でホストデバイス１０２により符号化されている「ライブ」コンテンツを、ホストデバイス１０２上で符号化されるのと同じ速度の「ライブ」コンテンツとして、クライアントデバイス１０４上で経験または再生できることが保証される。
【００３８】
図５は、ストリーミングメディアコンテンツを配信するホストデバイス１０２上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス１０４上のクロックとの間のクロックドリフトを検出するのに好適なデジタルメディアシステムの１つまたは複数の追加の例示的実施形態を示している。ホストデバイス１０２およびクライアントデバイス１０４は、一般に、図２に示される実施形態に関して上述のように構成される。しかし、図５に示される一実施形態では、クライアントデバイス１０４は、さらに、クライアントクロック２０４とホストクロック２０２との間にクロックドリフトが存在するかどうかを判定し、上述したものと類似の方法でホストクロック２０２とクライアントクロック２０４との間のクロック速度差を計算するクロックドリフト検出および復旧モジュール５０２を備えるように構成することができる。さらに、クロックドリフトを検出し、ホストクロック２０２とクライアントクロック２０４との間のクロック速度差を計算した後、クライアントデバイス１０４の検出および復旧モジュール５０２は、クライアントクロック２０４をホストクロック２０２と同期させるクロック復旧方法（例えば、一定の割合でクライアントクロック２０４の速度を調整する）を実装することができる。他の実施形態では、ホストデバイス１０２は、クライアントデバイス１０４上のクロックドリフト検出および復旧モジュール５０２からクロック復旧要求および／または情報を受信するように構成されたクロック復旧モジュール５００を備えることができる。そのような要求および／または情報を受信したときには、クロック復旧モジュール５００は、図２に示される実施形態に関して上記で説明されているようなクロック復旧方法を実施することができる。
【００３９】
（例示的方法）
ストリーミングメディアコンテンツを配信するホスト／ソースデバイス１０２上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス１０４上のクロックとの間のデジタルメディアシステム内のクロックドリフトを検出するための例示的方法は、図６および７に示す流れ図を主に参照しながら説明する。これらの方法は、図１〜５に関して上記で説明された例示的実施形態に適用される。１つまたは複数の方法が、流れ図およびそれらの流れ図のブロックに関連付けられたテキストを用いて開示されているが、説明されている方法の要素は、必ずしも、提示される順序で実行されなくてもよく、また別の順序でも類似の利点が得られることは理解されるであろう。さらに、これらの方法は、排他的ではなく、単独で、または互いに組み合せて実行することができる。説明されている方法の要素は、例えば、ＡＳＩＣ上のハードウェア論理ブロックまたはプロセッサ読み取り可能媒体上で定義されるプロセッサ読み取り可能命令の実行などを含む適切な手段により実行することができる。
【００４０】
本明細書で使用されているように、「プロセッサ読み取り可能媒体」は、プロセッサにより使用または実行される命令を、含む、格納する、伝達する、伝搬する、または移送することができる任意の手段とすることができる。プロセッサ読み取り可能媒体は、電子、磁気、光、電磁気、赤外線、または半導体のシステム、装置、デバイス、または伝搬媒体とすることができるが、これらに限定されるものではない。プロセッサ読み取り可能媒体のより具体的な実施例として、特に、１つまたは複数の電線を有する電気接続（電子）、ポータブルコンピュータのディスケット（磁気）、ランダムアクセスメモリ（ＲＡＭ）（磁気）、読み取り専用メモリ（ＲＯＭ）（磁気）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）、光ファイバ（光）、書き換え可能コンパクトディスク（ＣＤ−ＲＷ）（光）、およびポータブルコンパクトディスク読み取り専用メモリ（ＣＤＲＯＭ）（光）が挙げられる。
【００４１】
方法６００のブロック６０２で、クライアント再生デバイス１０４は、ホストデバイス１０２からネットワーク１０６を介してストリーミングメディアコンテンツを受信する。例えば、メディアコンテンツは、オーディオ／ビデオおよび／またはビデオコンテンツを含む。ブロック６０４で、クライアントデバイス１０４は、クライアントバッファ２０８内にメディアコンテンツのデータを保持する。ストリーミングメディアコンテンツの再生時に、バッファを使用して、ネットワーク帯域幅の変動によるデータ配信の変動（例えば、ネットワーククロストラフィック、干渉、無線受信不良などにより生じるネットワーク障害による）を除去し、コンテンツの再生中にユーザに気付かれないようにする。ブロック６０６で、バッファモニタ２１８はバッファ２０８内のデータの占有量レベルを監視し、ブロック６０８で、バッファ占有量レポート２１０（１）がバッファ監視に基づいて生成される。したがって、メディアコンテンツがバッファ内にストリーミングされ、クライアント再生デバイス１０４により消費されると、バッファモニタにより、コンテンツストリーミング中の様々な時点においてバッファ内に存在するデータ量を示すバッファ占有量レポートが生成される。
【００４２】
方法６００のブロック６１０で、クロックドリフト検出および復旧モジュール（２０６、５０２）は、メディアンコンテンツのストリーミングを調整するホストデバイス１０２上のクロックとメディアコンテンツの再生を調整するクライアントデバイス１０４上のクロックとの間にクロックドリフトが存在するかどうかを判定する。続く図７に示し、以下に記載する方法７００によって、さらに、クロックドリフトの判定方法を説明する。
【００４３】
方法６００のブロック６１２で、クロックドリフト量が計算される。上記で説明されているように、クロックドリフト量は以下の式にしたがって計算されるが、ｄｐｃは定数であり、ｆｔ、ｆ０、およびｔは、グラフを生成するために使用されるデータから（すなわち、バッファ占有量レポート２１０（２）内のデータから）決定することができる。    
【００４４】
【数２】
2006222976.tif 000004
【００４５】
方法６００のブロック６１４で、クロックドリフト検出および復旧モジュール（２０６、５０２）またはクロック復旧モジュール５００は、クライアントクロック２０４をホストクロック２０２に同期させるクロック復旧方法を実施する。例えば、復旧方法は、クライアントクロックの調整、ホストクロックの調整、ホストデバイスからのストリーミングコンテンツの変更（例えば、フレームを落とす）などを含むことができる。
【００４６】
上述したように、図７に示す方法７００により、さらに、クロックドリフト検出および復旧モジュール（２０６、５０２）によってホストクロックとクライアントクロックとの間にクロックドリフトが存在するかどうかを判定する方法を説明する。方法７００のブロック７０２で、検出および復旧モジュール（２０６、５０２）は、クライアントデバイス１０４へのメディアコンテンツのストリーミング中に、一定時間間隔でバッファ占有量レベルをプロットする。ブロック７０４で、プロットにより形成される直線の平均勾配が計算される。平均勾配の計算は、広い時間範囲にわたってバッファ占有量の平均を計算すること、および、その結果をプロットすることを含むことができ、これらを含まなければバッファ占有量レベルの変化を示す可能性のあるネットワーク帯域幅の変動を除去することができる。
【００４７】
ブロック７０６で、クロックドリフト検出および復旧モジュール（２０６、５０２）は、（１つ以上の）クライアントバッファ２０８の枯渇を引き起こす可能性があるネットワーク制限などの、クロックドリフト以外の要因が存在するかどうかを判定する。例えば、ネットワーク容量がストリームのビットレートよりも低い場合、クライアントデバイス１０４上のバッファ占有量も時間経過とともに枯渇することがある。ネットワークレベルでの再送／損失パケットの数、時間経過による往復時間の変動、または他の統計量などの追加的な統計量を監視すると、ネットワーク過負荷を識別することができる。したがって、ネットワーク制限によるものと判断されるバッファ枯渇の結果は、クロックドリフトがホストクロックとクライアントクロックとの間に存在するかどうかを判定する場合に除去することができる。
【００４８】
ブロック７０８で、検出および復旧モジュール（２０６、５０２）は、直線の平均勾配を監視し、ホストクロックとクライアントクロックとの間にクロックドリフトが存在するかどうかを判定する。直線の平均勾配がゼロの場合、検出および復旧モジュール（２０６、５０２）は、ブロック７１０に示されるように、クロックドリフトが存在しないと判定する。直線の平均勾配が負の場合、検出および復旧モジュール（２０６、５０２）は、ブロック７１２に示されるように、クライアントクロックはホストクロックよりも速いと判定する。直線の平均勾配が正の場合、検出および復旧モジュール（２０６、５０２）は、ブロック７１４に示されるように、クライアントクロックはホストクロックよりも遅いと判定する。
【００４９】
（例示的コンピューティング環境）
図８は、図１〜７を参照しながら上記で説明されているホストデバイス１０２およびクライアント再生デバイス１０４などのコンピュータデバイスを実装するのに好適な例示的コンピューティング環境を示している。１つの具体的な構成が図８に示されているが、そのようなコンピューティングデバイスは、他のコンピューティング構成においても実装することができる。
【００５０】
コンピューティング環境８００は、コンピュータ８０２の形態の汎用コンピューティングシステムを備える。コンピュータ８０２のコンポーネントとして、１つまたは複数のプロセッサまたは処理装置８０４、システムメモリ８０６、およびプロセッサ８０４を含む様々なシステムコンポーネントをシステムメモリ８０６に連結するシステムバス８０８を備えることができるが、これらに限定されるものではない。
【００５１】
システムバス８０８は、メモリバスまたはメモリコントローラ、周辺バス、アクセラレーテッドグラフィックスポート、および様々なバスアーキテクチャのいずれかを使用するプロセッサまたはローカルバスを含む数種類のバス構造のうちの１つまたは複数を表している。システムバス８０８の例として、メザニンバスとしても知られる周辺コンポーネント相互接続（ＰＣＩ）バスが挙げられる。
【００５２】
コンピュータ８０２は、様々なコンピュータ読み取り可能媒体を備える。そのような媒体は、コンピュータ８０２によってアクセス可能な媒体であればどのような媒体でも使用可能であり、揮発性および不揮発性媒体、着脱可能および着脱不能媒体を含む。システムメモリ８０６は、ランダムアクセスメモリ（ＲＡＭ）８１０などの揮発性メモリ、および／または読み取り専用メモリ（ＲＯＭ）８１２などの不揮発性メモリの形態のコンピュータ読み取り可能媒体を備える。起動時などにコンピュータ８０２内の要素間の情報伝送を助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）８１４は、ＲＯＭ８１２に格納される。ＲＡＭ８１０は、処理装置８０４が直ちにアクセス可能であり、および／または処理装置８０４によって現在操作されているデータおよび／またはプログラムモジュールを格納する。
【００５３】
コンピュータ８０２は、他の着脱可能／着脱不能、揮発性／不揮発性コンピュータ記録媒体も備えることができる。例えば、図８には、着脱不能な不揮発性磁気媒体（図示せず）に対して読み書きを行うハードディスクドライブ８１６、着脱可能な不揮発性磁気ディスク８２０（例えば、「フロッピー（登録商標）ディスク」）に対して読み書きを行う磁気ディスクドライブ８１８、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはその他の光媒体などの着脱可能な不揮発性光ディスク８２４に対して読み出しおよび／または書き込みを行う光ディスクドライブ８２２が示されている。ハードディスクドライブ８１６、磁気ディスクドライブ８１８、および光ディスクドライブ８２２は、それぞれ、１つまたは複数のデータ媒体インターフェース８２５を介してシステムバス８０８に接続される。その代わりとして、ＳＣＳＩインターフェース（図示せず）を介しても、ハードディスクドライブ８１６、磁気ディスクドライブ８１８、および光ディスクドライブ８２２は、システムバス８０８に接続することができる。
【００５４】
ディスクドライブおよびそれらに関連するコンピュータ読み取り可能媒体は、コンピュータ８０２にコンピュータ読み取り可能命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶を提供する。図８には、ハードディスク８１６、着脱可能な磁気ディスク８２０、および着脱可能な光ディスク８２４が例示されているが、磁気カセットまたはその他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光記憶、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能プログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）などの、コンピュータによりアクセス可能なデータを格納することができる他のタイプのコンピュータ読み取り可能媒体も、この例示的コンピューティングシステムおよび環境を実装するために使用できることは理解されるであろう。
【００５５】
例えば、オペレーティングシステム８２６、１つまたは複数のアプリケーションプログラム８２８、その他のプログラムモジュール８３０、およびプログラムデータ８３２を含む、多くのプログラムモジュールは、ハードディスク８１６、磁気ディスク８２０、光ディスク８２４、ＲＯＭ８１２、および／またはＲＡＭ８１０に格納することができる。そのようなオペレーティングシステム８２６、１つまたは複数のアプリケーションプログラム８２８、その他のプログラムモジュール８３０、およびプログラムデータ８３２（またはそれらのいずれかの組合せ）はそれぞれ、ユーザネットワークアクセス情報に対するキャッシングスキームの一形態を有することができる。
【００５６】
コンピュータ８０２は、通信媒体として識別される様々なコンピュータ／プロセッサ読み取り可能媒体を備えることができる。通信媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または搬送波もしくはその他の移送機構など変調データ信号内のその他のデータを表現するものであり、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号中の情報を符号化するような方法で設定または変更された特性の１つまたは複数を有する信号を意味する。例えば、限定はしないが、通信媒体には、有線ネットワークまたは直接配線接続などの有線媒体、および音波、ＲＦ、赤外線、およびその他の無線媒体などの無線媒体が含まれる。上記のいずれの組合せもコンピュータ読み取り可能媒体の範囲に含まれる。
【００５７】
ユーザはキーボード８３４およびポインティングデバイス８３６（例えば、「マウス」）などの入力デバイスを介してコンピュータシステム８０２にコマンドおよび情報を入力することができる。他の入力デバイス８３８（特に図示されてはいない）として、マイク、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、シリアルポート、スキャナなどが挙げられる。これらの入力デバイスおよびその他の入力デバイスは、システムバス８０８に結合されている入力／出力インターフェース８４０を介して処理装置８０４に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造により接続されることもある。
【００５８】
モニタ８４２またはその他のタイプのディスプレイ装置も、ビデオアダプタ８４４などのインターフェースを介してシステムバス８０８に接続できる。モニタ８４２に加えて、他の出力周辺装置は、スピーカ（図示せず）およびプリンタ８４６などのコンポーネントを含み、入力／出力インターフェース８４０を介してコンピュータ８０２に接続できる。
【００５９】
コンピュータ８０２は、リモートコンピューティングデバイス８４８などの１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク接続環境で動作することができる。例えば、リモートコンピューティングデバイス８４８は、パーソナルコンピュータ、ポータブルコンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、または他の共通ネットワークノードなどとすることができる。リモートコンピューティングデバイス８４８は、コンピュータシステム８０２に関して本明細書で説明されている要素および特徴の多くまたはすべてを備えることができるポータブルコンピュータとして例示されている。
【００６０】
コンピュータ８０２とリモートコンピュータ８４８との間の論理接続は、ローカルエリアネットワーク（ＬＡＮ）８５０と一般的なワイドエリアネットワーク（ＷＡＮ）８５２として表されている。このようなネットワーキング環境は、オフィス、企業全体にわたるコンピュータネットワーク、イントラネット、およびインターネットでは一般的である。ＬＡＮネットワーキング環境で実装される場合、コンピュータ８０２は、ネットワークインターフェースまたはアダプタ８５４を介してローカルネットワーク８５０に接続される。ＷＡＮネットワーキング環境で実装される場合、コンピュータ８０２は、ワイドエリアネットワーク８５２上での通信を確立するためのモデム８５６または他の手段を備える。モデム８５６は、コンピュータ８０２に内蔵されても、外付けされてもよいが、入力／出力インターフェース８４０または他の適切な機構を介してシステムバス８０８に接続することができる。図示されているネットワーク接続は例示的なものであり、コンピュータ８０２と８４８との間の通信リンクを確立する他の手段も使用できることは理解されるであろう。
【００６１】
コンピューティング環境８００とともに例示されるようなネットワーク接続環境では、コンピュータ８０２に関して示されたプログラムモジュールまたはその一部は、リモートメモリ記憶装置に格納することができる。例えば、リモートアプリケーションプログラム８５８は、リモートコンピュータ８４８のメモリ装置に存在する。説明の目的上、アプリケーションプログラムおよびオペレーティングシステムなどの他の実行可能なプログラムコンポーネントは、本明細書では、離散ブロックとして例示されているが、そのようなプログラムおよびコンポーネントは、様々な時点において、コンピュータシステム８０２の異なる記憶コンポーネント内に存在し、コンピュータの（１つ以上の）データプロセッサにより実行されることは理解されるであろう。
【００６２】
（結論）
本発明は構造的特性および／または方法的動作に特有の言語で説明されているが、添付の特許請求の範囲で定められる発明は、説明されている具体的な特性または動作に必ずしも限られないことを理解されたい。むしろ、具体的な特性および動作は特許請求されている発明を実施するための例示的形態として開示されている。
【図面の簡単な説明】
【００６３】
【図１】ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間のクロックドリフトを検出するのに好適な例示的環境を示す図である。
【図２】ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間のクロックドリフトを検出するのに好適なデジタルメディアシステムの例示的実施形態を示す図である。
【図３】ホストデバイスがメディアコンテンツをクライアントデバイスにストリーミングするときに時間経過とともにクライアントメディアバッファ占有量レベルがどのように変化するかを示す事例の図である。
【図４】ネットワーク帯域幅変動により時間経過とともにバッファ占有量レベルが変動する場合、クライアントメディアバッファ占有量レベルがどのように変化するかを示す追加事例の図である。
【図５】ストリーミングメディアコンテンツを配信するホストデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間のクロックドリフトを検出するのに好適なデジタルメディアシステムの追加の例示的実施形態を示す図である。
【図６】ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間の、デジタルメディアシステム内のクロックドリフトを検出するための例示的方法を示す流れ図である。
【図７】ストリーミングメディアコンテンツを配信するホスト／ソースデバイス上のクロックとストリーミングメディアコンテンツを受信するクライアント再生デバイス上のクロックとの間の、デジタルメディアシステム内のクロックドリフトを検出するための例示的方法を示す流れ図である。
【図８】図１〜７を参照しながら説明されるホストコンピュータデバイスおよびクライアント再生デバイスを実装するのに好適な例示的コンピューティング環境を示す図である。
【符号の説明】
【００６４】
１０２  ホストデバイス
１０４  クライアントデバイス
２０２  ホストクロック
２０４  クライアントクロック
２０６、５０２  クロックドリフト検出および復旧モジュール
２０８  （１つ以上の）メディアバッファ
２１８  バッファモニタ
２１０（１）、２１０（２）  バッファ占有量レポート
５００  クロック復旧モジュール
【図１】
2006222976.tif 000007
【図２】
2006222976.tif 000008
【図３】
2006222976.tif 000009
【図４】
2006222976.tif 000010
【図５】
2006222976.tif 000011
【図６】
2006222976.tif 000012
【図７】
2006222976.tif 000013
【図８】
2006222976.tif 000014