JP4429643B2 - ディジタルデータレートおよび方向つき再生変更を処理する方法およびシステム - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ビデオデータ、オーディオ／ビデオデータ、および類似物などのレンダリング可能なディジタルデータを処理する方法およびシステムに関する。具体的に言うと、本発明は、再生速度変更または再生レート変更および方向変更（すなわち、順方向データ再生および逆方向データ再生）を処理する方法およびシステムに関する。
【０００２】
【従来の技術】
プロセッサ、アクセラレーションハードウェア、およびストレージデバイスの性能が向上を続けるので、通常（すなわち１．０）を超える再生速度が可能である。しかし、バッファリングおよびストリーム位置合わせの問題によって、アプリケーションとユーザが知覚する実際の再生速度の変化の間の対話性の度合が制限される。モノリシックな閉じた環境でこの問題を解くことが可能であるが、この場合に、解決策のすべてのコンポーネントが絡み合う。しかし、オープンでコンポーネント化された解決策の場合には、これははるかに困難な問題である。この問題を解決する複数の試みが行われたが、そのそれぞれが、その有用性を制限する基礎的な欠点および手落ちを有する。
【０００３】
再生レート（再生速度とも称する）によって、データの各フレームが表示される時間の長さが決定される。高い再生レートでは、通常は、低い再生レートより短い時間の期間だけフレームが表示される。高い再生レートは、ほとんどのプロセッサストレージ検索機能およびハードウェア機能を超える可能性がある高い帯域幅要件を有する。通常、高い再生レートは、いわゆる「スキャンモード」を使用して近似され、スキャンモードでは、ストリームのデータの一部を破棄することによって、データストリームの（小さい）部分だけが選択的に提示される。これは、すばやく進行するスライドショーに多少似ている。
【０００４】
コンピュータで実行されるものまたは対話型テレビジョンセットに関して実行されるものなどの多くのビデオアプリケーションが、ソース（またはソースフィルタ）を制御するユーザインターフェースからなる。ソース（またはソースフィルタ）は、最終的にユーザのためにデータをレンダリングできるようにデータを処理するデータ処理パイプラインの一部である。ソースは、メディアファイルを読み取り、通常は、データサンプルまたはバッファ（通常はたとえばＭＰＥＧを使用して圧縮される）を、処理のために他のタイプのデコーダに渡す。デコーダは、データを圧縮解除し、ユーザのためにデータをレンダリングするように構成され、それを行うことができるなんらかのタイプのレンダラに渡す。レンダラは、通常は、内部（または外部）クロックおよびデータサンプル自体に含まれるさまざまなタイミング情報を使用して、サンプルを正しい時刻に提示またはレンダリングする。レンダラが処理を開始する時に、初期レンダリングクロック時刻が、ソースおよびデコーダに渡される。ソースは、初期レンダラ時刻の多少後に開始されるタイムスタンプを有するサンプルを作り始めることができる。タイムスタンプは、プレゼンテーションの作成された時刻に基づいてさまざまなデータサンプルをスケジューリングし、レンダリングするために、レンダラによって使用される。データ処理パイプラインの各ステージの間でサンプルがバッファリングされるので、パイプラインおよび／または処理コンポーネント（フィルタなど）の間の小さい遅延が発生する可能性がある。（グラフまたは）パイプラインの待ち時間は、ソース（フィルタ）からのサンプルの、それが提示されるかレンダリングされる時刻までの累積的伝搬遅延である。システムが、ビデオコンテンツなどのデータを、異なる再生レートで（順方向と逆方向の両方で）スムーズに再生できるようにすることが、開発者の目標である。しかし、データ処理パイプラインの性質およびさまざまなデータフォーマットによって、開発者に課題が提示され続ける。
【０００５】
たとえば、異なるデータフォーマットすなわち、ＭＰＥＧ−２フォーマット、ＤＶＤフォーマット、およびＨＤＴＶフォーマットを検討されたい。
【０００６】
ＭＰＥＧ−２
ＭＰＥＧ−２フォーマットは、「順方向デコーディング（ｆｏｒｗａｒｄ ｄｅｃｏｄｉｎｇ）」フォーマットと称するフォーマットである。ＭＰＥＧ−２フォーマットの例の表現を、図１で、全般的に１０に示す。各ビデオシーケンスは、一連のＧｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ（または「ＧＯＰｓ」）からなる。ＧＯＰは、ピクチャまたはフレームのシーケンスからなる。フレームは、３つのタイプすなわち、イントラフレーム（Ｉフレーム）、順方向予測フレーム（Ｐフレーム）、および両方向予測フレーム（Ｂフレーム）にエンコードすることができる。
【０００７】
Ｉフレームまたは「キーフレーム」（Ｉフレーム１２）などは、過去または未来のフレームを参照せずに、単一のイメージとしてエンコードされる。使用されるエンコード方式は、ＪＰＥＧ圧縮に似る。Ｐフレーム（Ｐフレーム１８など）は、過去の基準フレームに関してエンコードされる。Ｐフレームは、基準フレームに対する変更が含まれるという点で、「デルタフレーム」とみなすこともできる。基準フレームは、ＰフレームまたはＩフレームである。過去の基準フレームは、最も近い前の基準フレームである。Ｂフレーム（または両方向フレーム、フレーム１４および１６など）は、過去の基準フレーム、将来の基準フレーム、または両方のフレームに関してエンコードされる。将来の基準フレームは、最も近い次の基準フレーム（ＩまたはＰ）である。Ｂフレームは、隣接する基準フレームだけの関数である。
【０００８】
ＧＯＰ構造は、シーケンスへのランダムアクセスを支援することを意図されたものである。ＧＯＰは、通常は、Ｉフレームから始まる限り任意のサイズとすることができる、独立のデコード可能な単位である。
【０００９】
ＭＰＥＧ−２フォーマットに関連する問題の１つが、逆方向でデータを再生できるようにすることである。順方向でのデータの再生は、フォーマット自体が順方向デコーディングであり、これは、まずＩフレームをデコードし、その後ＧＯＰ内の他のフレームに移らなければならないことを意味するので、通常は問題でない。しかし、逆方向でのデータの再生は、ＧＯＰを逆方向にデコードできないので、多少はより困難である。
【００１０】
ＤＶＤ
通常は、イメージが、ＤＶＤなどのディスクに記録される時に、ビデオは、実際には所定の時間期間（通常は１／２秒単位またはビデオオブジェクトベーシックユニット（ｖｉｄｅｏ ｏｂｊｅｃｔ ｂａｓｉｃ ｕｎｉｔｓ）（ＶＯＢＵ）を含む小さい単位に分解される。このフォーマットの利点は、ビデオを再生する時に、ビデオユニットを１つずつ進むことができることである。ビデオの任意の部分にジャンプしたい場合には、当のビデオユニットに単純にジャンプすることができ、オーディオとビデオが同期化される。すべてのストリームが同期化される位置を、「クリーンポイント（ｃｌｅａｎ ｐｏｉｎｔ）」と称する。したがって、ビデオユニットおよびオーディオユニットが圧縮される時に、これらは、正確に同時にレンダリングされるユニットに圧縮される、すなわち、オーディオとビデオの間のスキューがない。
【００１１】
ＭＰＥＧ２の文脈で説明する時のＩフレームへのすべての言及を、他のデータフォーマットでキーフレームに拡張することができる。用語Ｉフレームは、ＭＰＥＧ２の文脈の外で説明する時に、キーフレームと同義である。
【００１２】
ＨＤＴＶ：ＡＴＳＣ（Ａｍｅｒｉｃａｎ Ｔｅｌｅｖｉｓｉｏｎ Ｓｔａｎｄａｒｄｓ Ｃｏｍｍｉｔｔｅｅ）およびＤＶＢ（欧州フォーマット）
高品位テレビジョンまたはＨＤＴＶでは、ＭＥＰＧ−２フォーマットも使用される。しかし、ビデオブロックとオーディオブロックが、わずかなスキューを伴って位置合せされる。この場合に、ストリーム内のある点に単純に早送りまたはジャンプすることはできない。というのは、その点にビデオサンプルがある可能性があるが、関連するオーディオサンプルが、ストリーム内の別の位置から開始されるからである。さらに、オーディオサンプルは、ブロックとして順方向にデコードすることだけができる。これは、ストリーム内でバックアップし、関連するオーディオサンプルを探さなければならないことを意味する。特定のフォーマットに依存して、対応するオーディオブロックまたはオーディオサンプルの先頭がどこにあるかを実際に知ることはできない。したがって、当のビデオサンプルおよびオーディオサンプルの両方の前のある点についてストリーム内で後を見続ける必要がある。
【００１３】
オープンでコンポーネント化された解決策について異なる再生レートおよび再正方向を使用可能にすることを試みる時に、これらの異なるタイプのフォーマットに伴って課題が生じる。
【００１４】
ＤＶＤからデータをレンダリングすることができる例示的なシステム２００を示す図２を検討されたい。システム２００には、ＤＶＤ２０６からデータを読み取るソースコンポーネント２０４と通信するアプリケーション２０２が含まれる。ＤＶＤから読み取られるデータには、エンコードされ、一緒に多重化されたオーディオデータおよびビデオデータが含まれる。ソースは、ＤＶＤからデータを読み取る時に、データパケットにタイムスタンプを適用し、このタイムスタンプは、レンダリングのためにパケットを同期化し、スケジューリングするのに使用される。パケットは、デマルチプレクサ２０８に供給され、デマルチプレクサ２０８は、パケットを異なる構成部分すなわち、オーディオパケット、ビデオパケット、および存在する場合にサブピクチャ（ｓｕｂｐｉｃｔｕｒｅ）パケットに分割する。パケットは、その後、デマルチプレクサによって、ビデオデコーダ２１０（ビデオパケットのデコード用）、オーディオデコーダ２１２（オーディオパケットのデコード用）、およびサブピクチャデコーダ２１４（サブピクチャパケットのデコード用）などの関連するデコーダに供給される。パケットのそれぞれが、関連するタイミング情報を有し、このタイミング情報によって、パケットがレンダリングされると思われる時が定義される。さまざまなデコーダは、関連するパケットを圧縮解除し、個々のデータサンプルまたはデータパケット（パケットのタイムスタンプを含む）を、ビデオレンダラ２１６およびオーディオレンダラ２１８などの適当なレンダラに送る。
【００１５】
システム２００には、通常は、グローバルクロック２２０も含まれ、グローバルクロック２２０は、そのタイムスタンプがグローバルクロックによって示される時刻と一致するデータサンプルをレンダリングする時を確認するために、さまざまなレンダラによって使用される。
【００１６】
ユーザが、アプリケーション２０２を介して、異なる、おそらくはより速いレートでデータサンプルをレンダリングさせることを望むことを示すと仮定する。
【００１７】
順方向レート変更を調整する過去の手法は、グローバルクロック２２０を操作することである。すなわち、データを通常のレートの２倍の速度で再生したい場合には、グローバルクロックの速度を操作することによって、望みのレート変更を実施することができる。この手法に関する問題は、オーディオレンダラが、周波数シフトおよびひずんだオーディオ出力（ユーザの経験の質が下がる）に関連する問題を経験する可能性があることである。さらに、ビデオレンダラが、クロック変更に従うことを試みる時に、ビデオレンダラの処理が遅れ、これによって、レンダラが、追い付こうとしてサンプルを捨てる結果になる可能性がある。この全体的な結果は、オーディオの周波数シフトと、ビデオのタグアンドプル（ｔｕｇ−ａｎｄ−ｐｕｌｌ）である。サブピクチャ成分（ビデオレンダラに送られるデータがそれから生じる可能性がある）も、グローバルクロック変更に関連する問題を有する可能性があり、したがって、たとえばサブピクチャが不適切な時刻にまたは不適切なビデオに関連してレンダリングされることになる可能性がある。したがって、出力の品質が、大きく劣化する可能性がある。
【００１８】
順方向レート変更に対処することを試みるもう１つの手法は、ソース２０４に、デマルチプレクサ２０８に通知させ、デマルチプレクサ２０８に、ビデオデコーダ２１０に通知させて、適当なレート変更を行うことである。デコーダ２１０は、サンプルのタイムスタンプに対するスケーリング動作を行って、異なるレートでビデオ再生を行うことができる。この手法に関する問題は、ビデオデコーダ２１０、オーディオデコーダ２１２、およびサブピクチャデコーダ２１４が、同一の技法およびアルゴリズムを使用してサンプルを処理することの保証がないことであり、これは、異なるデコーダが異なるベンダ製である場合に特にそうである。したがって、レート変更が、わずかに異なる速度で行われる可能性があり、これによって、ビデオとオーディオがずれ始めることになる可能性がある。さらに悪いことに、サブピクチャが、同期化されなくなる可能性があり、これによって、誤った時にサブピクチャが表示される可能性がある。
【００１９】
さらに、この２つの手法は、順方向再生されるビデオに関してのみ実際に使用され、逆方向再生されるビデオには使用されなかった。これらの過去の手法を使用すると、実際には、ビデオを逆方向に再生するようにビデオレンダラに伝える方法がなかった（かつ、現在もない）。ビデオレンダラは、通常は、ビデオをディスクから読み取る方法を制御できず、それに関する知識を有しない。
【００２０】
【発明が解決しようとする課題】
本発明の目的は、レンダリング可能なディジタルデータを処理する改善された方法およびシステムを提供することである。
【００２１】
【課題を解決するための手段】
さまざまな方法およびシステムによって、ビデオデータ、オーディオ／ビデオデータ、オーディオ／ビデオ／サブピクチャデータ、および類似物などのディジタルデータを、順方向と逆方向の両方での再生を可能にする形で処理できるようにする。さまざまな実施形態は、ユーザの経験を強化できる形での再生レート変更の処理にも対処する。
【００２２】
【発明の実施の形態】
概要
下で説明するさまざまな方法およびシステムによって、ビデオデータ、オーディオ／ビデオデータ、およびオーディオ／ビデオ／サブピクチャデータなどのディジタルデータを、順方向と逆方向の両方でのスムーズな再生を可能にする形で処理できるようになる。さらに、再生レート変更を、ユーザの経験を強化する形で処理することができる。
【００２３】
例示的なコンピューティングシステム
図３に、下で説明するシステムおよび関連する方法を実施することができる適切なコンピューティング環境３００の例を示す。
【００２４】
コンピューティング環境３００は、適切なコンピューティング環境の１つの例にすぎず、メディア処理システムの使用の範囲または機能性に関する制限を暗示することを意図されたものではない。また、コンピューティング環境３００を、例示的なコンピューティング環境３００に示された任意のコンポーネントまたはその組合せに対する依存性または要件を有するものと解釈してもならない。
【００２５】
説明されるさまざまな実施形態は、多数の他の汎用または特殊目的のコンピューティングシステム環境またはコンピューティングシステム構成と共に動作することができる。メディア処理システムと共に使用するのに適する可能性がある周知のコンピューティングシステム、コンピューティング環境、および／またはコンピューティング構成の例に、パーソナルコンピュータ、サーバコンピュータ、シンクライアント、シッククライアント、ハンドヘルドデバイス、ラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、および類似物が含まれるが、これに制限はされない。
【００２６】
いくつかの実施形態で、このシステムおよび関連する方法を、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の全般的な文脈で説明することができる。一般に、プログラムモジュールには、特定のタスクを実行するか特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。これらの実施形態は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境でも実践することができる。分散コンピューティング環境では、プログラムモジュールを、メモリストレージデバイスを含むローカルおよびリモートの両方のコンピュータ記憶媒体に配置することができる。
【００２７】
図３に示された例の実施形態によれば、コンピューティングシステム３００は、１つまたは複数のプロセッサまたは処理ユニット３０２、システムメモリ３０４、およびシステムメモリ３０４を含むさまざまなシステムコンポーネントをプロセッサ３０２に結合するバス３０６を含むものとして図示されている。
【００２８】
バス３０６は、メモリバスまたはメモリコントローラ、周辺バス、ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ、およびさまざまなバスアーキテクチャのいずれかを使用するプロセッサバスまたはローカルバスを含む、複数のタイプのバス構造のいずれかの１つまたは複数を表すことを意図されている。制限ではなく例として、そのようなアーキテクチャに、Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、Ｅｎｈａｎｃｅｄ ＩＳＡ（ＥＩＳＡ）バス、Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ（ＶＥＳＡ）ローカルバス、およびメザニンバスとも称するＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ（ＰＣＩ）バスが含まれる。
【００２９】
コンピュータ３００には、通常はさまざまなコンピュータ可読媒体が含まれる。そのような媒体は、コンピュータ３００によってローカルにおよび／またはリモートからアクセス可能なすべての使用可能媒体とすることができ、これには、揮発性および不揮発性の両方の媒体、取外し可能および取外し不能の両方の媒体が含まれる。
【００３０】
図３では、システムメモリ３０４に、ランダムアクセスメモリ（ＲＡＭ）３１０などの揮発性の形のコンピュータ可読媒体および／または読取専用メモリ（ＲＯＭ）３０８などの不揮発性メモリの形のコンピュータ可読媒体が含まれる。起動中などにコンピュータ３００内の要素の間で情報を転送するのを助ける基本ルーチンを含む基本入出力システム（ＢＩＯＳ）３１２が、通常はＲＯＭ３０８に保管される。ＲＡＭ３１０には、通常は、処理ユニット３０２から即座にアクセス可能かつ／または処理ユニット３０２によって現在操作されるデータおよび／またはプログラムモジュールが含まれる。
【００３１】
コンピュータ３００に、さらに、他の取外し可能／取外し不能の揮発性／不揮発性のコンピュータ記憶媒体を含めることができる。例としてのみ、図３に、取外し不能不揮発性磁気媒体（図示せず、通常は「ハードドライブ」と称する）から読み取り、それに書き込むハードディスクドライブ３２８、取外し可能不揮発性磁気ディスク３３２（たとえば、「フロッピー（登録商標）ディスク」）から読み取り、それに書き込む磁気ディスクドライブ３３０、およびＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光学媒体などの取外し可能不揮発性光ディスク３３６から読み取り、それに書き込む光ディスクドライブ３３４を示す。ハードディスクドライブ３２８、磁気ディスクドライブ３３０、および光ディスクドライブ３３４は、それぞれ、１つまたは複数のインターフェース３２６によってバス３０６に接続される。
【００３２】
ドライブおよびそれに関連するコンピュータ可読媒体は、コンピュータ３００の、コンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供する。本明細書で説明する例示的実施形態では、ハードディスク３２８、取外し可能磁気ディスク３３２、および取外し可能光ディスク３３６が使用されるが、当業者は、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、および類似物など、コンピュータによってアクセス可能なデータを保管することができる他のタイプのコンピュータ可読媒体も、例示的オペレーティング環境で使用できることを諒解されたい。
【００３３】
制限ではなく例としてオペレーティングシステム３１４、１つまたは複数のアプリケーションプログラム３１６（たとえば、マルチメディアアプリケーションプログラム３２４）、他のプログラムモジュール３１８、およびプログラムデータ３２０を含む複数のプログラムモジュールを、ハードディスク３２８、磁気ディスク３３２、光ディスク３３６、ＲＯＭ３０８、またはＲＡＭ３１０に保管することができる。ユーザは、キーボード３３８およびポインティングデバイス３４０（「マウス」など）などの入力デバイスを介してコンピュータ３００にコマンドおよび情報を入力することができる。他の入力デバイスに、オーディオ／ビデオ入力デバイス３５３、マイクロホン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、シリアルポート、スキャナ、または類似物（図示せず）を含めることができる。これらおよび他の入力デバイスは、バス３０６に結合される入力インターフェース３４２を介して処理ユニット３０２に接続されるが、パラレルポート、ゲームポート、またはｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌｂｕｓ（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。
【００３４】
モニタ３５６または他のタイプのディスプレイデバイスも、ビデオアダプタまたはビデオ／グラフィックスカード３４４などのインターフェースを介してバス３０６に接続される。モニタのほかに、パーソナルコンピュータには、通常は、スピーカおよびプリンタなどの他の周辺出力デバイス（図示せず）が含まれ、これらの周辺出力デバイスを、出力周辺インターフェース３４６を介して接続することができる。
【００３５】
コンピュータ３００は、リモートコンピュータ３５０などの１つまたは複数のリモートコンピュータへの論理接続を使用して、ネットワーク化された環境で動作することができる。リモートコンピュータ３５０には、通常は、コンピュータに関して本明細書で説明する要素および特徴の多数またはすべてを含めることができる。
【００３６】
図３からわかるように、コンピューティングシステム３００は、ローカルエリアネットワーク（ＬＡＮ）３５１および一般的な広域ネットワーク（ＷＡＮ）３５２を介して、リモートデバイス（たとえば、リモートコンピュータ３５０）に通信的に結合される。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでありふれたものである。
【００３７】
ＬＡＮネットワーキング環境で使用される時には、コンピュータ３００は、ネットワークインターフェースまたはネットワークアダプタ３４８を介してＬＡＮ３５１に接続される。ＷＡＮネットワーキング環境で使用される時には、コンピュータ３００に、通常はモデム３５４または、ＷＡＮ３５２を介する通信を確立する他の手段が含まれる。モデム３５４は、内蔵または外付けとすることができるが、ユーザ入力インターフェース３４２または他の適当な機構を介してシステムバス３０６に接続することができる。
【００３８】
ネットワーク化された環境では、パーソナルコンピュータ３００に関して図示されたプログラムモジュール、またはその一部を、リモートメモリストレージデバイスに保管することができる。制限ではなく例として、図３に、リモートコンピュータ３５０のメモリデバイスに常駐するものとしてリモートアプリケーションプログラム３１６を示す。図示のネットワーク接続が、例示的であり、コンピュータの間で通信リンクを確立する他の手段を使用することができることを諒解されたい。
【００３９】
第１の例示的実施形態−逆方向再生／レート変更
図４に、あるタイプのメディアで実施されるディジタルデータを処理し、その結果、そのデータを逆方向にレンダリングできるようにする第１の実施形態を概略的に示す。この例では、システムに、ユーザが、処理されレンダリングされる特定のディジタルメディアと対話できるインターフェースを提供するアプリケーション４００が含まれる。このシステムには、レンダリングされるデータを読み取るための１つまたは複数のソース４０２、レンダリングされるデータをデコードまたは圧縮解除する１つまたは複数のデコーダ４０６、およびデータをレンダリングする１つまたは複数のレンダラ４０８も含まれる（各タイプのコンポーネントは１つだけ図示）。レンダラ４０８によってレンダリングされるディジタルメディアは、メディア４１０で提供され、メディア４１０には、この例では、ＤＶＤなどのディスクが含まれる。しかし、どのタイプのメディアでも、ディジタルメディアを保管するのに使用することができる。ソース、デコーダ、およびレンダラが、別々の個々のコンポーネントとして図示されているが、それぞれの機能性をより集積された形で提供できることを諒解されたい。
【００４０】
メディア４１０は、通常は、レンダリングすることができる大量のデータを保持する。データは、通常は、論理ユニットに編成される。論理ユニットは、ブロックとして表される。用語「ブロック」は、特定のタイプのデータまたはメディアを指定することを意図されたものではない。そうではなく、この用語は、この実施形態がその下で動作する原理を示すために使用される。したがって、図示されるブロックは、通常はキーフレームから始まるセクションにデータを分割する異なるタイプまたは異なるフォーマットのデータを表すことができる。たとえば、ブロックに、ＭＰＥＧ−１フォーマットまたはＭＰＥＧ−２フォーマットでデータをフォーマットするのに使用されるＧＯＰを含めることができる。ブロックは、ＤＶＤでデータをフォーマットするのに使用されるものなどのＶＯＢＵを表すこともできる。
【００４１】
そのようなブロックの特性の１つが、個々のブロックが、ブロックの副コンポーネントを表す副部分からなることである。したがって、ブロックがＧＯＰを表す場合には、個々の副部分に、１つのＩフレームおよび１つまたは複数のＰフレームまたはＢフレームを含めることができる。各ブロックの副部分は、各ブロック内で数字によって示される。たとえば、ブロック１は、副部分１、２、３、および４からなり、これらの副部分のそれぞれが、ビデオフレームを表す。
【００４２】
ブロックは、ブロックとして処理されるために下流コンポーネントに渡される、より小さい独立の副ブロックに分解することもできる。たとえば、ＤＶＤでは、ＶＯＢＵに、複数のＧＯＰを含めることができる。ＶＯＢＵブロックを、それぞれが１つのＧＯＰを含む複数の副ブロックに分解することができる。これは、コンテンツを逆方向に再生する時に有用である。というのは、より大きいブロックを、より小さいブロックに分解でき、これらの小さいブロックの順序が、下流に送られる時に逆転されるからである。新しい副ブロックのそれぞれについて新しいタイムスタンプを計算する必要がある（図１４参照）。
【００４３】
ユーザが、アプリケーション４００を介して、特定のデータ（ビデオデータなど）を逆方向に再生することを望むことを示す時に、アプリケーション４００は、逆方向再生が意図されていることをソース４０２に通知する。アプリケーションは、通常は、逆方向再生が行われる時間範囲またはソース時間も示すことができる。ソース４０２が、逆方向再生が行われる時間期間に入った時に、ソースは、相対ソース時間内のデータのブロックを逆に読み取る。
【００４４】
たとえば、図４を検討されたい。メディア４１０に、３つの個々のブロック（ブロック１、ブロック２、およびブロック３として示されている）がグループＡとして含まれることが図示されていることに留意されたい。実際には、メディア４１０に、図示されたものより多数のブロックが含まれる。しかし、この例では、ユーザが、グループＡのブロックを逆方向に再生することを望むことを、アプリケーション４００を介してソース４０２に示したと仮定する。
【００４５】
ソースは、メディア４１０からデータを読み取る際に、ソース時間を記憶し、ソース時間がブロック１から３と一致する時に、ブロック１から３を逆の順序で読み取る。具体的に言うと、ブロック３が最初に読み取られ、その後、ブロック２、その後、ブロック１が読み取られる。したがって、ソース４０２の左で、グループＢを定義するために、読み取られるブロックの順序付けがブロック３／ブロック２／ブロック１であることに留意されたい。その後、ソース４０２は、１つまたは複数のフラグをブロックに追加して、それらが逆方向再生を意図されていることを示す。具体的に言うと、スタートフラグが、ブロック３に追加され、エンドフラグが、ブロック１に追加されることに留意されたい。フラグの任意の適切な配置を使用して、逆方向再生に関してブロックを指定することができる。たとえば、フラグを、各ブロックの終りに追加することができる。ソース４０２は、ブロックにタイムスタンプを追加することによってブロックを処理することもできる。これは、各ブロックのソース時間を、レンダリングアクティビティをスケジューリングするのにレンダラによって使用される単調増加するタイムスタンプにマッピングすることによって行うことができる。
【００４６】
その後、各ブロックが、ソース４０２によってデコーダ４０６に供給される。デマルチプレクサまたはスプリッタをソースとデコーダの間に入れることができるが、図を簡単にするために図示されていないことを諒解されたい。したがって、たとえば、ブロック３をデコーダ４０６に供給し、その後、ブロック２を、最後にブロック１を供給することができる。その代わりに、ソースが、ブロックを事前に解析し、処理またはデコード／圧縮解除のためにデコーダに逆の順序で一時にブロックのより小さい副ブロックを送ることができる。これによって、デコーダに伝搬されるブロックのサイズが減る。
【００４７】
デコーダ４０６は、ブロックを受け取る時に、左から右へとデコードする。しかし、ブロックのフラグによって、デコーダに、ブロックをデコードし、レンダラ４０８に発行されるブロックの副部分（フレーム）の順序を逆転しなければならないことが示される。具体的に言うと、デコーダ４０６は、ブロック３を受け取り、普通にそのブロックをデコードし、他のブロックを処理している間、デコードされたブロック部分をバッファリングすることができる。デコーダ４０６は、ブロック２および１を同様に処理する。デコーダが、エンドフラグに達した時に、デコーダは、逆方向再生が行われる特定のブロックシーケンスが定義済みであることを知る。デコーダは、ブロック副部分のタイムスタンプを逆転することができ、そのブロック副部分をレンダラ４０８に逆の順序で発行することができる。発行されたブロック副部分は、グループＣとして表される。
【００４８】
上記からわかるように、レンダラは、ストリームが順方向再生される場合に有する順序に対して逆転されたデータのストリームを受け取る。レンダラは、レンダリングのためにストリームをスケジューリングすることができる。レンダラは、ここで、ストリームが逆方向で再生されることを知らない。というのは、その詳細が、ソースコンポーネントおよびデコーダコンポーネントの中に閉じこめられているからである。
【００４９】
ユーザが、再生レートを変更するためにレート変更を実施することを望むと仮定する。この実施形態では、レート変更を下記のように実施することができる。ユーザが、通常すなわち１倍速より高速または低速のレートでデータをレンダリングさせることを望むと仮定する。レート変更を、アプリケーション４００を介してソース４０２に通信することができる。レート変更情報を、ソースからデコーダ４０６に供給することができ、その結果、レート変更処理を、デコーダによって実行することができる。この実施形態では、デコーダが、それが処理するサンプルまたはブロック副部分のタイムスタンプを操作することによって、レート変更処理を実行することができる。たとえば、サンプルのグループが、１倍速でレンダリングされ、ｔ_１からｔ_４まで伸びるタイムスタンプを有する場合に、タイムスタンプをｔ_１−ｔ_４からｔ_１−ｔ_２（ただし、ｔ_２−ｔ_１＝（ｔ_４−ｔ_１）／２）に変更することによって、そのようなサンプルを２倍速でレンダリングすることができる。
【００５０】
図５は、一実施形態による方法のステップを説明する流れ図である。この方法は、適切なハードウェア、ソフトウェア、ファームウェア、またはその組合せで実施することができる。図示の例では、この方法を、図４に図示されそれに関して説明されたシステムに関連して実施することができる。
【００５１】
ステップ５００で、逆方向再生が望まれることの指示を受け取る。このステップは、逆方向再生が望まれることの通信または呼出しをソフトウェアから受け取ることによって実施することができる。この通信に、逆方向再生が望まれるソース時間の範囲を含めることができる。ステップ５０２で、１つまたは複数のデータブロックを配置して、再生順序を定義する。このステップは、指示されたソース時間範囲に対応するブロックを逆方向で読み取ることによって実施することができる。これを行うことができる方法の１つの例を、上で示した。ステップ５０４で、１つまたは複数のフラグをデータブロックに関連付ける。このフラグは、当の１つまたは複数のブロックが、逆方向再生の対象であることを示すことを意図されたものである。逆方向再生スタートフラグおよび逆方向再生エンドフラグを、当のブロックに関連付けることができる。
【００５２】
ステップ５０６で、ブロックを個々のブロック副部分にデコードし、さらに、所望の逆方向再生に従ってブロック副部分を処理することができる。これには、たとえば、所定の時間期間の間のブロック副部分のバッファリングを含めることができる。たとえば、ブロック副部分を、逆方向再生を意図されたブロック副部分のすべてがデコードされるまでバッファリングすることができる。その代わりにまたはそれに追加して、ブロック副部分を、所定の数または量の副部分がバッファリングされるまでバッファリングすることができる。バッファリングされたデコードされたデータを、圧縮ソースデータと共に使用して、逆方向再生ストリームを完全に再生成することもできる。さらに、ブロック副部分を処理して、それに関連するタイムスタンプを操作することもできる。これには、個々の副部分のタイムスタンプの有効な順序を逆転することを含めることができる。これには、要求される可能性があるレート変更に起因するすべてのタイムスタンプ処理を含めることもできる。そのようなタイムスタンプ処理に、タイムスタンプの値の変更を含めることができる。
【００５３】
ステップ５０８で、逆の順序でブロック副部分を発行する。このステップでは、ステップ５０４のフラグを使用して、ブロック副部分を逆の順序で発行しなければならないことを示すことができる。したがって、たとえば、デコーダ４０６（図４）が、ブロック副部分を処理する時に、フラグの存在によって、デコーダがブロック副部分を逆の順序で発行しなければならないことを示すことができる。デコーダは、ブロック副部分を逆の順序で発行することができる。これを行う方法の１つの例を、上で示す。ステップ５１０で、副部分が発行されたのと逆の順序で、発行されたブロック副部分をレンダリングする。
【００５４】
同一のアルゴリズムを適用して、ブロックを副ブロックに分割することができ、この副ブロックは、ソースまたはデコーダなどの上位コンポーネントが使用することができる。効果的に、ソースは、ビデオ全体を副ブロック（ＤＶＤの場合にはＶＯＢＵ）に分割し、それらを、逆転されたタイムスタンプと共に逆の順序で発行する。デコーダは、ＶＯＢＵを読み取り、キャッシングし、その後、キャッシングされたデータを逆の順序で発行することによって、ＶＯＢＵをＧＯＰブロックに分割してレンダラに渡すことができる。
【００５５】
上で説明した処理およびシステムは、デコードされたブロック副部分をバッファリングするために、より多くのメモリの要件を有する。しかし、この手法の長所に、下記が含まれる。第１に、いくつかのシステムは、効果的に位置において後ろにジャンプし、複数のフレームを順方向に再生し、その後、もう一度位置において後ろにジャンプし、複数のフレームを順方向に再生する処理を繰り返すことによって、逆方向再生の達成を試みる。この処理は、作業が反復されるので計算的に極度に非効率的になる可能性があり、通常はユーザの経験の質が低下する。他の手法では、一時に１データブロックだけが操作される。
【００５６】
上のシステムおよび方法では、実際に、逆方向再生が望まれる時に複数のブロックの順序を変更することができる。さらに、フラグを使用することによって、システムが、個々のブロック副部分またはフレームを逆の順序で実際にレンダリングできるようになる。また、ブロック副部分のタイムスタンプを操作することによって、レート変更をスムーズに提供することができる。他の長所は、当業者に明白であろう。
【００５７】
性能の利点として、上で説明した方法およびシステムは、グラフィックスプロセッサ内のさまざまなパイプライン化されたビデオアクセラレーション技法を利用することができる。これは、デコーダについて特にそうである。これによって、データパイプラインが、継続的に効率的に動作できるようなり、初期化スタートアップコストを防ぐことができる。さまざまなパイプライン化されたビデオアクセラレーション技法が、米国特許出願第０９／８３９６８２号（発明の名称：拡張可能なマルチメディアアプリケーションプログラムインターフェイスおよび関連する方法、出願日：２００１年４月２０日、その開示内容は参照されることによってこの明細書に組み込まれる）。
【００５８】
第２の例示的実施形態−逆方向再生／レート変更
上で説明した実施形態では、デコーダが、アプリケーションからのすべてのレート変更要求ならびにすべての逆方向再生要求を処理するように構成された。しかし、レンダリング可能なデータを処理するシステムのチェーンまたは処理パイプラインに、より多くのコンポーネントが含まれる可能性がある。たとえば、処理パイプラインの１タイプを、フィルタグラフ（ｆｉｌｔｅｒ ｇｒａｐｈ）と称する。フィルタグラフは、フィルタ（または処理ユニット）の有向ネットワーク（ｄｉｒｅｃｔｅｄ ｎｅｔｗｏｒｋ）である。フィルタグラフには、最終的にレンダリングされるデータを処理するように構成された多数の異なるタイプのフィルタを含めることができる。ソースフィルタおよびデコーダフィルタのほかに、そのようなフィルタグラフに、変換フィルタ、効果フィルタ、ネットワークリンク、分析フィルタ、および類似物を含めることができる。
【００５９】
再生およびレート変更処理を、システム、パイプライン、またはフィルタグラフにまたがって分散させることが有利になる可能性がある。この理由の１つが、実装の柔軟性が高まること、ならびに、オープンで拡張可能なアーキテクチャである。たとえば、ユーザが、既にデコーダによって処理されたが、レート変更を行うことができない下流コンポーネントでキューイングされているサンプルのレート変更を要求する場合に、すべてではないにしてもほとんどの現在のシステムが、通常は、そのレート変更を無視する。
【００６０】
通常、レート変更は、２つの形の１つで行うことができる。第１に、ユーザは、レート変更を現在または今、行うことを要求することができる。おそらく、ユーザは、再生レートに影響する、ＵＩ内のスライダを操作する。第２に、レート変更を、ソースコンテンツ内の所与の位置でスケジューリングすることができる。たとえば、おそらく、ユーザは、ソース時間００：００：０５から開始される２倍速へのレート変更が望ましいことを示す。この２つのシナリオは、根本的に異なる。第１のシナリオは、要求のタイミングおよびその瞬間の処理パイプラインの状態のゆえに、より困難なシナリオである。ソースコンテンツが、既にソースによって読み取られ、パイプラインの次のコンポーネントに転送されている可能性がある。第２のシナリオは、レート変更が行われる場所がわかっており、したがって、レート変更を前もってスケジューリングすることができるので、より容易な問題である。
【００６１】
上で注記したように、ソースは、データを処理する時に、特定のメディアからデータを読み取り、データに関連するソース時間を、レンダリングのスケジューリングに使用されるタイムスタンプにマッピングする。たとえば、次の表に、１倍速での順方向再生についてソースによって実行されるマッピング動作の表現を示す。
【００６２】
【表１】

【００６３】
上の表では、００：００：０１から００：００：０５に対応するソース時間が、レンダリングされる特定のフレームと一致するタイムスタンプにマッピングされる。たとえば、００：００：０１は、フレーム１に対応するタイムスタンプにマッピングされ、００：００：０２は、フレーム２に対応するタイムスタンプにマッピングされるなどである。したがって、１倍速での順方向再生に関して、１対１マッピング関係がある。
【００６４】
逆方向再生の要求がある時に、マッピング動作が、多少変更される。この例では、ソースで、まだソース時間がタイムスタンプにマッピングされる。しかし、ソースは、タイムスタンプの連続的な単調増加するストリームを提供するだけではなく、逆方向再生要求も考慮に入れた形でそれを行う。たとえば、下の表に、ソース時間範囲００：００：０１から００：００：０５までの、１倍速での逆方向再生に関するマッピング動作を示す。
【００６５】
【表２】

【００６６】
ソース時間が、逆方向再生を反映して再割り当てされているが、対応するタイムスタンプが、単調増加し続けることに留意されたい。したがって、レンダラは、このデータサンプルを受け取る時に、逆方向再生に影響するようにレンダリングをスケジューリングする。
【００６７】
ソースコンテンツの別の部分へのジャンプがあると仮定する。おそらく、ソースコンテンツは、ソース時間範囲００：００：０１から００：００：０５までについてレンダリングされ、その後、ソース時間範囲００：００：２０から００：００：２４までへのジャンプがある。この場合に、マッピング動作によって、下記の単調増加するタイムスタンプのストリームが作られる。
【００６８】
【表３】

【００６９】
したがって、この実施形態で、ソースの責任は、アプリケーションから要求を受け取り、ソースデータの位置（すなわちソース時間）に基づくコンテキストを単調増加する出力タイムスタンプにマッピングすることである。それを行う際に、データの連続的なストリームを、レンダリングのためにレンダラに供給することができる。これは、他のコンポーネントが、タイムスタンプおよび特定のプロセスのどこにいるかを記憶する必要がないという点で、他のコンポーネント、特にレンダラの観点から、有利である。そうではなく、他のコンポーネントは、単純に、タイムスタンプの線形ストリームを有するサンプルを受け取り、処理することができる。
【００７０】
ソースでの処理を容易にするために、ソースが、レート変更を行った時およびそのレート変更が将来に発生するイベントのリストのどこにマッピングされたかのヒストリを維持することができる。その場合に、アプリケーションが、特定の時でのレート変更の要求を始める場合に、ソースは、過去にレート変更をどのように編成したかを知っている。ソースは、レート変更に関連するソースコンテンツが、既に処理のために下流コンポーネントに渡されたかどうかも知っている。すでに渡されている場合に、ソースは、たとえばレート変更要求を下流コンポーネントに渡し、これらのコンポーネントにレート変更実施の関連処理を行わせることによって、レート変更を実施させることを試みるステップを行うことができる。他の手法では、既にソースから出たソースコンテンツに関するそのようなレート変更要求は、単純に削除されていた。
【００７１】
コンポーネント能力を確かめるためのパイプラインへの照会
上および下で説明する実施形態のいくつかの有利な特徴の１つが、ソースが、コンポーネントの機能を確かめるために処理パイプライン内のコンポーネントに照会する能力を有することである。たとえば、ソースは、デコーダなどのコンポーネントに照会して、そのコンポーネントが逆再生をサポートするかどうか、サポートされる再生レート、最大再生レート、最小再生レート、および類似物を確かめることができる。それを行うことによって、ソースは、ソースデータを読み取る方法と、いくつかの場合に、他のコンポーネントに送るソースデータのフォーマットを、知的に判断できるようになる。
【００７２】
一例として、下記を検討されたい。レート変更を実施し、それを知的に行うために、ソースが、パイプライン全体またはフィルタグラフによってサポートされる最大レートを知ることが有利になる可能性がある。これは、順方向再生と逆方向再生の両方にあてはまる可能性がある。この実施形態では、１つまたは複数のパイプラインコンポーネントに、ソースが照会することのできるインターフェース（単に呼出し可能なメソッドの集合である）が与えられる。パイプラインを構成するかインスタンス化する時に、ソースは、１つまたは複数のインターフェースに照会して、コンポーネントの機能を確かめることができる。たとえば、ソースは、コンポーネントに照会して、それらのどれかが逆方向再生をサポートするかどうかを確かめることができる。そうでない場合には、これによって、ソースが、逆方向再生をサポートしない、より単純なモードに入り、それをアプリケーションに示すようにすることができ、これによって、アプリケーションが、よりスマートなＵＩをユーザに提示するようになる。これには、たとえば、ブロック全体を逆に読み取り、適当なフラグを用いてタグを付けるのではなく（いずれにせよデコーダが操作することはできない）、逆の順序でブロックのキーフレームを読み取ることを含めることができる。さらに、ソースは、サポートされる再生レートを確かめるために照会することができる。これを知ることによって、ソースは、その処理を適応させて、パイプラインを圧倒しないことを保証することができる。たとえば、特定の再生速度が、パイプラインによってサポートされない場合に、ソースは、パイプラインによるさらなる処理のために、あるブロック部分だけ（たとえばＩフレームだけ）を送ることができる。これは、パイプラインが、効率的に処理できないデータの重荷を過度に負わされないことを保証すると同時に、できる限り要求された再生レートに近いレンダリングされたディスプレイを提供するのを試みるのに役立つ。
【００７３】
照会処理を実施する方法の１つは、次の通りである。ソースは、最初に始動されるかインスタンス化される時に、直接にまたは間接的に、パイプラインのすべてのコンポーネントに、その機能、たとえば最大順方向レートおよび最大逆方向レートを照会する。これを行う方法の１つが、ソースが、最初の下流コンポーネントに照会し、最初の下流コンポーネントが、その最初の下流コンポーネントに照会し、以下同様に繰り返すことである。一例として、図６を検討されたい。図６には、ソース６０２、デマルチプレクサ６０４、デコーダ６０６および６０６ａ、コンポーネント６０８、６０８ａ、６１０、および６１０ａ（任意の適当なコンポーネントとすることができる）、およびレンダラ６１２および６１２ａを含む例示的なパイプライン６００が示されている。この場合に、ソース６０２が、デマルチプレクサ６０４に照会し、デマルチプレクサ６０４が、デコーダ６０６および６０６ａに照会し、以下同様である。その後、照会結果を、パイプラインの上流に返すことができる。
【００７４】
この例では、ソースが、さまざまなコンポーネントの最大順方向再生レートに関心を持つと仮定する。この例では、コンポーネントの最大レートのそれぞれが、そのコンポーネントの真下に示されている。したがって、たとえば、レンダラ６１２の最大レートは、２倍速であり、レンダラ６１２ａの最大レートは、３倍速である。ソースがパイプラインの最大レート全般に関して判断を行える形は、２つある。まず、ソースは、保守的な形で、さまざまなコンポーネントのすべてのレートの最小値を単純にとることができる。したがって、この特定の例では、すべてのレートの最小値は２倍速である。したがって、この知識から、ソースは、２倍速未満の要求されたレートのすべてを、有意な量のデータを除去する必要なしにスムーズにレンダリングできると仮定することができる。第２の、より積極的な手法は、さまざまなコンポーネントの間に乗法的効果があると仮定することである。たとえば、第１のコンポーネントが２倍速をサポートでき、その下流のコンポーネントが３倍速をサポートできる場合に、これらのコンポーネントが一緒になって提供できる最大レート変更は、６倍速である。したがって、この図で、レンダラ６１２は、コンポーネント６１０によって照会される時に、２倍速（コンポーネントの間の括弧内に示されている）の再生レートを報告する。したがって、コンポーネント６１０は、乗法的効果のゆえに、４倍速の再生レートをコンポーネント６０８に報告することができる。同様に、コンポーネント６０８は、８倍速の再生レートをコンポーネント６０６に報告することができ、以下同様である。この例では、デマルチプレクサ６０４が、１倍速再生レートだけをサポートすると仮定する。デマルチプレクサ６０４は、ソース６０２に、２つの再生レートすなわち１６倍速および３２倍速を報告することができる。この手法によれば、ソースは、２つの再生レートうちの低い方すなわち１６倍速を、全般的にスムーズな再生レートを達成するためにパイプラインによってサポートされる最大再生レートとして選択することができる。
【００７５】
ソースが、パイプラインのレート能力（たとえば１６倍速）を知ったならば、ソースは、要求されたレートが１６倍速以下である時にデータブロック全体をパイプラインに供給できることを知り、そのデータが、このレートでレンダリングされる。ソースは、１６倍速を超える要求されたレート変更について、より高いレートを提供することを試みるためになんらかの追加処理を行わなければならないことを知ることができる。これには、パイプラインによる処理のために切り捨てられたおよび／または選択的なブロックだけを送ることを含めることができる。このモードを、「スキャンモード」と称し、このモードでは、たとえば、キーフレームだけを、処理のためにソースによってパイプラインに送ることができる。
【００７６】
図７は、一実施形態による方法のステップを説明する流れ図である。この方法は、適切なハードウェア、ソフトウェア、ファームウェア、またはその組合せで実施することができる。図示の例では、この方法を、図６に図示されそれに関して説明されたシステムに関連して実施することができる。
【００７７】
ステップ７００で、データ処理パイプラインを設ける。任意の適切なデータ処理パイプラインを設けることができる。適切なパイプラインには、通常は、なんらかのタイプのメディア（ディスクなど）からソースデータを読み取るか、データを個々のデータストリームに多重化解除するか、なんらかの形でデータをデコードし、処理するか、ユーザが楽しむためにデータをレンダリングする、１つまたは複数のコンポーネントが含まれる。これらの異なる機能性は、異なるコンポーネントによって実行される傾向があるが、そうである必要ない。
【００７８】
ステップ７０２で、再生サポート機能の提供に関してコンポーネントに照会する。再生サポート機能の例には、再生レート（最大、最小、および／またはレートの範囲）、再正方向（順方向、逆方向）、および類似物が、制限なしに含まれる。ステップ７０４で、照会されたコンポーネントの下流にコンポーネントがあるかどうかを判定する。ある場合には、ステップ７０６で、次のコンポーネントに進み、ステップ７０２に戻って、そのコンポーネントに照会して、その再生サポート機能を提供する。追加の下流コンポーネントがない場合には、ステップ７０８で、再生サポート機能をデータ処理パイプラインの上へ報告する。
【００７９】
このステップは、２つの異なる形で実施することができる。まず、上で注記したように、各コンポーネントの機能を、ソースに報告することができ、ソースは、その後、知的なデータ処理判断を行うことができる。たとえば、コンポーネントのそれぞれの再生レートをソースに報告することができ、その結果、ソースが、最小再生レートを選択できるようになる。第２に、コンポーネントのそれぞれの機能を、他のすべてのコンポーネントの機能に関して検討することができる。たとえば、特定のパイプラインまたは副パイプライン内のすべてのコンポーネントの再生レートを乗算することができ、その結果、パイプラインまたは副パイプラインによってサポートされる全体的な有効再生レートを確かめることができる。確かめられたならば、ソースは、上で注記したようにデータを処理する方法について知的な判断を行うことができる。
【００８０】
上で説明した例では、すべての適切に構成されたコンポーネント（フィルタ）を、データマニピュレータ（ｄａｔａ ｍａｎｉｐｕｌａｔｏｒ）と見なすことができる。すなわち、個々のコンポーネントが、データを部分的に処理し、データをどのように操作したかに関する適当なヒントを渡すことができる。次のコンポーネントは、さらに、所望の再生レートまたは方向の達成に向かってデータを処理することができる。
【００８１】
必要であれば、たとえば、ソースが、デコーダに供給するデータの量を減らすと同時に、データに関するタイミング情報（レート変更など）を維持することができる。これによって、デコーダに、レート変更が望まれることのヒントが与えられる。デコーダは、ソースからデータを受け取ることができ、デコードのほかに、レート変更の達成を試みる形でそのデータを処理することができる。チェーン内のコンポーネントは、所望の再生の達成に対処する形でデータを処理するという選択肢を有することができ、あるいは、コンポーネントは、レート変更に関する情報と共にデータを次のコンポーネントに渡すことができる。そのような処理には、データブロック部分の逆転、逆方向再生要求を受け取った場合のタイムスタンプの再割り当て、およびデータからの関連するフラグの除去を含めることができる。
【００８２】
したがって、この例では、ソースが、ブロックレベルでストリームを逆にし、逆方向再生が意図されていることを示すフラグを追加することができる。ブロックは、その後、下流の他のコンポーネントに伝搬される。コンポーネントは、逆方向フラグを有するデータに出会った時に、ブロックを別の下流のコンポーネントに渡すこと、または、データを処理して、たとえばフレームの順序を逆にし、フラグを除去し、データを次のコンポーネントにプッシュすることという選択肢を有する。最終的に、レンダラが、適当に増加するタイムスタンプを有する順方向ストリームに見えるものを受け取る。
【００８３】
ソースから出たブロックのレート変更
上で説明した実施形態は、レート変更が所与の時刻に行われ、レート変更が実施されるデータブロックをソースがまだ読み取っていない時に良好に動作する。もう１つの状況があり、この場合には、上で簡単に述べたように、ソースがデータブロックを読み取り、かつ／または処理のために下流コンポーネントにブロックを渡した後に、レート変更要求が受け取られる。
【００８４】
これから説明する実施形態では、処理をコンポーネントパイプラインまたはフィルタグラフにまたがって分散させることによって、柔軟性が強化される。具体的に言うと、アプリケーションは、特定の時刻またはソース時間にレート変更を実行するようにソースコンポーネントに要求することができる。その後、レート変更情報が、レート変更に関連するソース時間を有するデータサンプルがそのキューに含まれるコンポーネントに出会うまで、パイプラインに沿って伝搬される。そのコンポーネントは、レート変更要求をキューに入れることができ、その結果、レート変更が、そのサンプルについて処理されるようになる。対応するサンプルが、コンポーネントによって処理される時に、コンポーネントは、出力データ（たとえばサンプルのタイムスタンプ）の変更などの必要な処理をすべて実行することができる。さらなる処理が必要な場合には、コンポーネントは、レート変更要求（ならびにすべての他の有用な情報）を、各出力サンプルと共に渡すことができる。最終的に、レンダラが、サンプルを受け取り、レンダリングをスケジューリングすることができる。分散処理の一部として再生またはレート変更の処理を実施するようにレンダラを構成することもできることを諒解されたい。
【００８５】
もう１つの重要な利点は、ソースのレート変更キューが、まだ送っていないか読み取っていないデータだけに制限されることである。キューの残りは、パイプラインに沿って分散され、このパイプラインは、ほとんどの場合に比較的短い。
【００８６】
例として、下記を検討されたい。アプリケーションが、レート変更要求をソースに送る時に、ソースは、そのバッファを調べ、レート変更がそれに関して行われるデータが、バッファに置かれているかどうかを確かめる。ソースは、通常は、レート変更が行われるソース時間を記録することによってこれを行うことができる。ソースのバッファ内のデータが、レート変更が行われるソース時間より後の対応するソース時間を有する場合に、データサンプルは、既に下流コンポーネントに渡されている。ソースは、レート変更の対象になるデータを含むバッファを突き止めた場合に、レート変更情報をそのサンプルに関連付けることができる。
【００８７】
すなわち、この実施形態によれば、すべてのデータサンプルに、（１）すべてのレート変更、（２）サンプルを再生しなければならない時間範囲、および（３）サンプルを順方向または逆方向のどちらで再生するかを定義するプロパティを含むリストが含まれる。このリストは、データサンプルと共に伝搬され、その結果、パイプライン内のコンポーネントが、過去に行われたすべてのレート変更のリストを維持する必要がなくなる。
【００８８】
ソースが、そのバッファを検査し、レート変更が行われるサンプルが見つからない場合には、ソースは、レート変更要求を次の下流コンポーネントに送る。次のコンポーネントは、そのバッファを検査して、そのバッファにレート変更が行われるサンプルが含まれるかどうかを確かめることによって、同様の処理を実行する。コンポーネントが、適当なデータサンプルを見つけた場合には、そのコンポーネントは、サンプルを処理する時にレート変更情報をサンプルに追加するか、バッファを調べ、バッファ内のサンプルにレート変更情報をアタッチするのいずれかを行うことができる。この処理は、データパイプライン内の適切に構成されたコンポーネントによって実行することができる。
【００８９】
図８は、一実施形態による方法のステップを説明する流れ図である。この方法は、適切なハードウェア、ソフトウェア、ファームウェア、またはその組合せで実施することができる。図示の例では、この方法を、図６に図示されそれに関して説明されたシステムに関連して実施することができる。
【００９０】
ステップ８００で、特定のソース時間に関するレート変更要求を受け取る。通常、レート変更要求は、アプリケーションから発し、ソースに渡される。レート変更要求の受け取りに応答して、ステップ８０２で、１つまたは複数のバッファを検査して、レート変更が行われる対応するデータサンプルが存在するかどうかを確かめる。検査されるバッファは、レート変更要求を受け取ったコンポーネントに関連するバッファである。サンプルが見つかる場合に（ステップ８０４）、ステップ８０６で、レート変更情報をサンプルにアタッチする。このステップは、２つの形で実施することができる。たとえば、レート変更情報を、サンプルがバッファにある間にサンプルにアタッチすることができる。これは、バッファが読取／書込キューである時に実施することができる。その代わりに、レート変更情報を、キャッシングし、サンプルがコンポーネントによって処理される時にサンプルにアタッチすることができる。このステップは、バッファが読取専用キューである時に実施することができる。
【００９１】
その一方で、サンプルが、コンポーネントのバッファ内で見つからない場合には、ステップ８０８で、レート変更要求を次の下流コンポーネントに送る。ステップ８１０で、下流コンポーネントに関連するバッファを検査する。このステップは、レート変更要求を受け取ったコンポーネントによって実施することができる。サンプルが見つかる場合に（ステップ８１２）、この方法は、ステップ８０６に分岐することができる。その一方で、サンプルが見つからない場合には、ステップ８１４で、別の下流コンポーネントがあるかどうかを判定する。そうである場合には、この方法は、ステップ８０８に分岐し、レート変更要求を次のコンポーネントに送る。その一方で、追加の下流コンポーネントがない場合には、ステップ８１６で、レート変更要求を破棄する。おそらく、このステップは、レンダラによって実施される。レート変更要求の破棄は、レンダリングの出力レートに対する一時的な影響だけを有する。
【００９２】
クリーンポイントがないデータのレート変更
多重化されたデータストリーム（ＡＴＳＣ ＭＰＥＧ２など）は、ビデオのキーフレームで位置合せされる二次ストリーム（ｓｅｃｏｎｄａｒｙ ｓｔｒｅａｍ）を必ずしも有しない場合がある。これによって、コンテンツを、キーフレームによって区切られた別個のブロックに分割することを試みる時に問題が生じる。
【００９３】
主ストリーム（ｐｒｉｍａｒｙ ｓｔｒｅａｍ）データのブロックに対応する任意の時間間隔の二次ストリームのデータを生成するには、下記の２つの解決策がある。
【００９４】
１）トリミング
ソースは、すべてのストリームがその間隔に存在し、各ストリームがその間隔の開始タイムスタンプにスキップするように指示されるように、コンテンツを後ろ向きに検索する。
【００９５】
２）フラグメント（ｆｒａｇｍｅｎｔ）の破棄
ソースは、主ストリームの先頭を探し、二次ストリームは、次のフレームの先頭までブロックフラグメントを破棄する。ストリームは、この間隔の間のデータがなく、不連続性を、間隔の先頭で送らなければならない。
【００９６】
この時間間隔の後のデータを終了するために、切捨マーカー（ｔｒｕｎｃａｔｉｏｎ ｍａｒｋｅｒ）を各ストリームに挿入する必要がある。図１６に、二次ストリームについて余分なデータを読み取る方法と、ビデオストリーム間隔と一致するように二次ストリームを修正できる方法を示す。順方向再生について、フルフレームモード中の同一方向のレート変更は、クリーンポイントによって影響されない。
【００９７】
順方向および逆方向のキーフレームスキャンモードについて、二次ストリームは、トリミングまたはフラグメント化を必要としない。大量のデータが、スキップされつつあるので、フラグメント化によってソースの設計が単純になるのでフラグメント化が好ましい場合がある。より複雑なシークを、機能強化として追加することができるが、これによって、シークおよびリーダとの対話に起因する性能コストが生じる場合がある。
【００９８】
スムーズ逆方向再生について、トリミングされた二次ストリームが、連続的な逆方向オーディオのために必要である。しかし、ソースでのバッファリング要件（バッファ空間の２倍）および余分な高速デコード／破棄が、実現可能でない場合がある。しかし、オーディオデコードは、ビデオデコードと比較して比較的高速である。
ソースは、トリミング範囲の外のサンプルを破棄する責任を負う。
【００９９】
実施例
上で説明した実施形態の諸態様を、具体的な実施例に関して説明する。下で説明する例が、例示を目的とし、請求される主題の応用分野を制限するものと解釈されてはならないことを理解されたい。
【０１００】
これから説明する例では、下記のアーキテクチャ的態様が使用される。ＩＲａｔｅＣｈａｎｇｅＤａｔａインターフェースは、各サンプルに対して設けられ、レート変更情報、フラグ、およびレート変更位置を維持するのに使用される。サンプルアロケータが、ＩＲａｔｅＣｈａｎｇｅＤａｔａインターフェースをサポートするサンプルを作成する。インターフェースＩＲａｔｅＣｈａｎｇｅＣｏｎｔｒｏｌ（通常は、フィルタの入力ピンまたはコンポーネントへの入力ピンにある）は、レート変更挿入を要求する：：ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅメソッドを提供する。このインターフェースは、順方向および逆方向の最大デコードレートを照会するメソッド：：ＧｅｔＭａｘＲａｔｅもサポートする。メソッド：：ＧｅｔＦｕｒｔｈｅｓｔＰｏｓｉｔｉｏｎは、まだ処理されていない最も遠いストリーム時間を照会し、その後でレート変更をスケジューリングできる時間間隔を判定するために提供される。
【０１０１】
もう１つのメソッド：：ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅＮｏｗでは、次の使用可能な時間位置でレート変更をスケジューリングすることと、実際の位置を返すことを要求する。このメソッドは、失敗したレート変更から回復することが最も少なく可能であるストリームに対して呼び出すことができる。：：ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅメソッドは、：：ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅＮｏｗによって返される位置を使用する他のストリームに対して呼び出すことができる。
【０１０２】
さらに、この例では、データフォーマットに関する下記の仮定にそって描かれる。スムーズな逆転、逆方向および順方向のスキャン再生（用語「スキャン」は、パイプラインまたはグラフによってサポートされる最大レートを超える再生速度に起因する切り捨てられた再生を表すのに使用される）について、通常は、ソースが、ストリームをクリーンポイントによって区切られるばらばらのブロックに分解できなければならない。クリーンポイントは、圧縮データ内で、すべてのストリームが同期化される位置である（すなわち、各ストリームが、新しいサンプルで同一のプレゼンテーションタイムスタンプで開始される）。たとえば、ＤＶＤソースでは、ソースブロックとしてＶＯＢＵが使用される。他のコンテンツフォーマットについて、ソースは、ストリームをＧＯＰに分解する。というのは、ビデオおよびオーディオのストリームで、キーフレーム境界で新しいフレームが開始されるからである。一般的なＭＰＥＧ−２コンテンツなどのクリーンポイントがないコンテンツについては、前の節の「クリーンポイントがないデータのレート変更」を参照されたい。
【０１０３】
レート変更要求のスケジューリングおよび処理に関して：
・フィルタは、ＩＲａｔｅＣｈａｎｇｅＣｏｎｔｒｏｌ：：ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅ要求をデコーダに送って、特定のソースタイムスタンプにミッドサンプル（ｍｉｄ−ｓａｍｐｌｅ）レート変更を挿入する。デコーダは、レート変更位置を含むサンプルに出会うかどうかを判定する。そのタイムスタンプを既に処理したか、レート変更を処理しない場合に、デコーダは、入力ピンに対応させることによって制御される出力ピンのそれぞれにレート変更要求を渡す。
【０１０４】
・その代わりに、即時レート変更をスケジューリングするために、フィルタは、ＩＲａｔｅＣｈａｎｇｅＣｏｎｔｒｏｌ：：ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅＮｏｗ要求をデコーダ（通常は、たとえば顕著な「音飛び」を引き起こすオーディオなど、データ消失から簡単には回復できないストリームのデコーダ）に送って、次の使用可能なソースタイムスタンプにミッドサンプルレート変更を挿入する。この要求は、あるコンポーネントが、このレート変更挿入要求を処理しなければならないと判断するまで、再帰的に下流に渡される。実際の位置が、ストリームを介して最初のフィルタまで返される。フィルタは、ＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅＮｏｗ要求によって返されるタイムスタンプを使用して、他のストリームにレート変更要求を伝搬させる。
【０１０５】
・デコーダが要求を処理する時に、デコーダは、レート変更タイムスタンプを含むサンプルを受け取る時に、処理されるレート変更情報を内部的にキューイングする。サンプルに出会った時に、デコーダは、すべてのレート変更補間を実行し、レート変更情報を、出力サンプルのＩＲａｔｅＣｈａｎｇｅＤａｔａインターフェースにコピーする。
【０１０６】
・データストリーム内のタイムスタンプ情報は、ソースまたは中間フィルタによって直接には変更されない。各フィルタが、単純に、ストリームの内容を修正する。
【０１０７】
レート変更の計算に関して：
・ソースフィルタは、ＩＲａｔｅＣｈａｎｇｅＣｏｎｔｒｏｌ：：ＧｅｔＭａｘＲａｔｅメソッドを使用して、デコーダの順方向および逆方向の最大再生ビットレートを照会する。グローバルフラグに真がセットされている場合には、フィルタは、対応する出力ピンおよびその最大内部レートの両方の最大レートを計算し、返さなければならない。
【０１０８】
ＩＲａｔｅＣｈａｎｇｅＤａｔａインターフェースに関して：
・ＩＲａｔｅＣｈａｎｇｅＤａｔａインターフェースは、レート変更の存在を示すことと、サンプルに関連するレート変更情報を保管することの両方に使用される。
【０１０９】
・ＩＲａｔｅＣｈａｎｇｅＤａｔａインターフェースは、下記の情報を維持する：
○ＬＯＮＧ Ｒａｔｅ−符号付き固定小数点スケール値（×１００００）。負の値は、逆方向再生を示す。０の値は、レート変更イベントがこのサンプルに存在しないことを示す（フラグフィールドにまだサンプル情報が含まれる場合があるが）。
○ＲＥＦＥＲＥＮＣＥＴＩＭＥ Ｌｏｃａｔｉｏｎ−レート変更のソースタイムスタンプ位置。
○ＤＷＯＲＤ Ｆｌａｇｓ−下記のフラグのビット単位のＯＲ。
★Ｆｌａｇ＿ＲｅｖｅｒｓｅＳｔａｒｔ−サンプルの「逆方向再生」グループの最初のサンプル。
★Ｆｌａｇ＿ＲｅｖｅｒｓｅＥｎｄ−サンプルの「逆方向再生」グループの最後のサンプル。
★Ｆｌａｇ＿ＳｃａｎＭｏｄｅ−順方向または逆方向のスキャンモードでのビデオセクションの部分。
★Ｆｌａｇ＿ＴｒｕｎｃａｔｉｏｎＰｏｉｎｔ−サンプルをこの点で切り捨てなければならないことの位置指定。「Ｒａｔｅ」フィールドは使用されない。
★Ｆｌａｇ＿ＳｋｉｐＰｏｉｎｔ−サンプルの先頭からこの点までを切り捨てなければならないことの位置指定。「Ｒａｔｅ」フィールドは使用されない。
【０１１０】
異なる再生レートでのタイムスタンプおよびデータの解釈に関して：
・ソースフィルタは、タイムスタンプが連続し、単調増加することを保証する責任を負う。タイムスタンプは、連続的な線形のビデオに見えるように修正される。不連続は、ソースデータに途切れがあることを示す。
【０１１１】
・再正方向の変更は、サンプル境界でのみ発生することができ、サンプルの「逆方向再生」グループの中途では発生しない（下を参照されたい）。
【０１１２】
・スムーズ順方向再生で（最大順方向レート未満）、サンプルは、図９に示されているように普通に送られる。
【０１１３】
・スムーズ逆方向再生に関して、デコーダが、サンプルのブロックを順方向にデコードし、その後、フレームを逆の順序で送達すると仮定する。Ｆｌａｇ＿ＲｅｖｅｒｓｅＳｔａｒｔフラグ（ＩＲａｔｅＣｈａｎｇｅＤａｔａ：：Ｆｌａｇｓデータフィールド内の）によって、このサンプルが、逆方向に再生されることを意図されたサンプルのグループの最初のサンプルであることが示される。Ｆｌａｇ＿ＲｅｖｅｒｓｅＥｎｄフラグによって、サンプルが、サンプルの「逆方向再生」グループの最後のサンプルであることが示される。サンプルが再生される間隔の最初と最後のタイムスタンプは、変更されない。データの表示順序は、図１０に示されているように逆転される。
【０１１４】
・最初の間隔のフレームの表示タイムスタンプは、下記のように計算される：
R_frame=IntervalStart + IntervalLength - Offset
=R_s3 + (R_e3 - R_s3) - (R_old - R_s3)
=(R_e3 - R_old) + R_s3
【０１１５】
・最大レートを超える順方向（または逆方向）スキャン再生中には、キーフレーム（Ｉフレーム）だけが、時間間隔に表示されるビデオの近似としてデコーダに送られる（不連続性なしに）。出力タイムスタンプは、図１１に示されているように、元の間隔の終了タイムスタンプと同一である。タイムスタンプは、１倍速で再生される線形のビデオとして見えるように修正される。開始タイムスタンプおよび終了タイムスタンプによって、サンプルが再生される期間が示される。
【０１１６】
・スキャン（キーフレームだけを送る）とスムーズモード（すべてのビデオを送る）の間の推移によって、本来的に実際のデータが変更される。最大レート未満のレートでのレート変更によって、サンプルがスムーズモードで送られることが指示され、そうでない場合には、サンプルがスキャンモードで送られる。各サンプルのＩＲａｔｅＣｈａｎｇｅＤａｔａフラグに、デコーダがサンプルのモード（スムーズまたはスキャン、逆方向または順方向）を決定するのを助けるヒントが含まれる。
【０１１７】
・方向変更は、レートの符号の変化によって示される。方向変更は、サンプル境界でのみ行うことができ、サンプルの「逆方向再生」グループの途中で行うことはできない。
【０１１８】
・図１２に示されているように、複数の同一方向のレート変更を、１つのサンプル内で、およびスキャンモードと非スキャンモードの混合されたサンプルにまたがって、行うことができる。
【０１１９】
・この例のレート変更機構では、ビデオフォーマットを、キーフレームによって分離されたブロックに分割できることだけが仮定される。タイムスタンプが単調増加することを保証するために、各ブロック（キーフレームの間）の長さは、終了タイムスタンプと後続キーフレームの次のタイムスタンプを計算するために、ソースフィルタが計算可能でなければならない。
【０１２０】
・タイムスタンプは、通常は、パイプラインを介して伝搬する際に、フィルタによって修正されない。レンダラが、タイムスタンプを修正して（レート変更コマンドストリームを使用して）、出力タイムスタンプを作る。コンポーネントは、タイムスタンプを修正しない場合に、位置について照会された時またはレート変更情報を下流に伝搬する時に、すべての出力タイムスタンプ情報を入力タイムスタンプにマッピングしなければならない（逆も同様）。
【０１２１】
・ソースフィルタが、タイムスタンプをサンプルに付加せずに、それらが逆方向再生ブロックの一部であることを示すことが可能である。この状況では、インバンドタイムスタンプを読み取る最初のフィルタが、ブロック全体に属するサンプルに対して単調に増加するタイムスタンプを生成する責任を負う。
【０１２２】
・中間フィルタは、図１３に示されているように、逆方向サンプルを、受け取られた順序と逆の順序で送られる、より小さい逆方向サンプルに分割することを許可される。
【０１２３】
上で説明した例によって、複数の長所が実施される。第１に、レート変更が、同一方向かつ同一モードである場合に、レート変更をリアルタイムの対話的変更として提供することができる。さらに、スキャンモードで最大個数のフレームが表示される時に、デコーダのビットレートを超えない。さらに、タイムスタンプは、レンダラのみによって修正され、タイムスタンプマッピングコードを、集中化し、隠すことができる。
【０１２４】
インターフェース
この特定の実施例では、下記のインターフェースを使用することができる：

【０１２５】
メソッドＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅ（）によって、レート変更挿入を要求する。
・ＳｏｕｒｃｅＰｏｓｉｔｉｏｎパラメータによって、レート変更を実行するタイムスタンプを、ソースタイムスタンプに関して指定する。
【０１２６】
・Ｒａｔｅによって、レート×１００００を指定する。このレートは、逆方向再生の場合に負になる。
【０１２７】
メソッドＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅＮｏｗ（）によって、最も早い使用可能な時にレート変更挿入が要求され、このメソッドは、そのレート変更が行われる時刻を返す。
・ｐＡｃｔｕａｌＳｏｕｒｃｅＰｏｓｉｔｉｏｎパラメータによって、レート変更がスケジューリングされた実際のタイムスタンプが返される。
【０１２８】
・Ｒａｔｅによって、レート×１００００を指定する。このレートは、逆方向再生の場合に負になる。
【０１２９】
メソッドＳｃｈｅｄｕｌｅＴｒｕｎｃａｔｉｏｎ（）によって、データ切捨を要求する。
・ＳｏｕｒｃｅＰｏｓｉｔｉｏｎパラメータによって、サンプルを切り捨てるタイムスタンプを指定する。
【０１３０】
・メソッドＳｃｈｅｄｕｌｅＳｋｉｐ（）によって、サンプルの先頭からのデータスキップを要求する。
【０１３１】
・ＳｏｕｒｃｅＰｏｓｉｔｉｏｎパラメータによって、サンプルの先頭からの、スキップされるタイムスタンプを指定する。
【０１３２】
メソッドＧｅｔＭａｘＲａｔｅ（）によって、最大順方向デコードレートおよび最大逆方向デコードレートを照会する。
・ｐＦｏｒｗａｒｄＲａｔｅパラメータおよびｐＢａｃｋｗａｒｄＲａｔｅパラメータによって、最大相対順方向再生レートおよび最大相対逆方向再生レートを示す正の値が返される。
【０１３３】
・ＩｎｃｌｕｄｅＤｏｗｎｓｔｒｅａｍフラグによって、コンポーネントがその計算に下流依存性を含めなければならないことが示される。
メソッドＧｅｔＦｕｒｔｈｅｓｔＰｏｓｉｔｉｏｎ（）によって、まだ処理されていないもっとも遠いストリーム時刻を照会する。
【０１３４】
・ｐＳｏｕｒｃｅＰｏｓｉｔｉｏｎは、出力の現在のタイムスタンプ（ソースタイムスタンプに関する）を示す戻りパラメータである。
【０１３５】
・ｐＶａｌｉｄＰｅｒｉｏｄは、レート変更をスケジューリングできるソース位置の後の持続時間（すなわち、このソース位置の次の使用可能なソース位置までの時間）を示す戻りパラメータである。
【０１３６】
コンポーネントの責任
この特定の実施例では、さまざまなコンポーネントが、下で概要を示す責任を有する。これらの責任が、読者に責任の１つの可能な割振りを示すために説明されることを諒解されたい。下の説明は、請求される主題の応用分野を特定の実施形態に制限することを意図されたものではない。
【０１３７】
一般に、ソースは、連続するデータストリームを生成する責任を負い、デコーダは、ストリームを修正する責任を負い、レンダラは、最終的にレート変更コンポーネントである。レンダラが、レート変更機構をサポートしない場合には、前のフィルタが、レート変更を実行するためにタイムスタンプを変更することによって、レンダラの代わりに動作する責任を負う。
【０１３８】
ソース
ソースは、タイムスタンプ情報を生成し、管理する責任を負う。ソースは、タイムスタンプ不連続性を置き換え、逆方向再生ブロックを順方向ストリームブロックに反転し、それぞれに逆方向で再生するタグを付けることによって、単調に増加するストリームを生成しなければならない。
【０１３９】
ソースは、特定の位置でのレート変更に関するユーザ要求を実施する方法を見つける責任も負う。また、ソースは、「今」実行しなければならないレート変更をスケジューリングする方法を、下記のいずれかによって見つける。
【０１４０】
・下流フィルタの位置を照会し、使用可能な位置および使用可能な時間間隔に基づいて実際の変更をスケジューリングする場所を判断することによって。ソースは、使用可能な位置からの最短距離を実施して、コンポーネントを介する伝搬遅延を考慮に入れることができる。
【０１４１】
・ストリームに対してＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅＮｏｗメソッドを実行し、要求の（返された）位置をＳｃｈｅｄｕｌｅＲａｔｅＣｈａｎｇｅを使用して他のストリームに伝搬することによって。
【０１４２】
サンプルは、変化するフォーマット（たとえば、順方向サンプル対逆方向サンプル）で送られるので、ソースは、最も最近の方向変更のブロック（たとえば、ＧＯＰまたはＶＯＢＵ）ヒストリを維持する。異なる方向でのレート変更は、最も最近の方向変更の後でのみ行われる可能性がある。
【０１４３】
デコーダおよび中間コンポーネント
デコーダは、主に、レンダラを助けるストリームプリプロセッサとして働く（例えば、ビットレートの切捨、スローモーション用のデータの追加、および類似物によって）。レート変更を受け取る時に、デコーダは、できる限り補間を実行する。デコーダは、後続処理のために次のフィルタにレート変更を渡すこともできる。
【０１４４】
デコーダは、逆方向再生ブロックを、レンダラによる処理のためにより小さい逆方向ブロックに分解することがもできる。たとえば、ＤＶＤデータの場合に、元のＶＯＢＵブロックを、複数のより小さいサブブロック（この例ではＧＯＰ）に分解することができる。サブブロックの順序は、逆転され、そのタイムスタンプも、逆転される（図１４を参照されたい）。レンダラは、新しいブロックを受け取り、受け取る時に各ブロックを逆転することができる。これは、レンダラが維持を必要とするバッファリングされる未圧縮データの量を減らすという長所を有する。
【０１４５】
次のフィルタ（通常はレンダラ）が、レート変更をサポートしない場合には、デコーダが、出力タイムスタンプを修正して、レート変更を実行しなければならない。
【０１４６】
レンダラ
レンダラは、最終的にレート変更を実施する。レンダラは、レート変更後の有効プレゼンテーションタイムスタンプを計算する。レンダラは、レート変更ヒストリも維持し、その結果、たとえばレート変更を行えない時、またはレンダラが過去に発生したレート変更要求を受け取る時に、サルベージ／障害状況を処理できるようにする。
【０１４７】
さらに、レンダラは、出力フレームのバッファリングを実行できる場合に、アクセラレーション技法を使用して、実際に逆方向再生を実行することができる。レンダラは、デコーダから逆の順序のサンプルを受け取り、デコードされたフレームの記録またはキャッシングを開始する。逆ブロックの終りに達したならば、キャッシングされたフレームを、逆の順序でレンダリングすることができる。
【０１４８】
レンダラのタイムスタンプマネージャ
タイムスタンプマネージャコードを、上で注記したように、レンダラが入力タイムスタンプ（およびレート変更要求とおそらくは現在のクロック位置）をサンプルの出力タイムスタンプにマッピングするのに使用することができるレート変更管理機能に抽象化することができる。
【０１４９】
一例として、図１４および以下の説明を検討されたい。図１４に、指定された場所でユーザによって行われるレート変更要求を示す。１２フレームのコンテンツが、さまざまなブロックサイズでレンダラに送られたと仮定する。ユーザは、時刻００：００：１５に２倍速のレート変更を要求した。
【０１５０】
ソースは、コンテンツ固有の位置を、対応する出力サンプル７のタイムスタンプにマッピングする。レート変更要求を、各出力ピンに送って、次のフィルタがレート変更を挿入することを要求する。この例では、ビデオデコーダが、バッファリングされたサンプル７を有し、しがって、ビデオデコーダは、レート変更情報をサンプル７に付加する。オーディオデコーダは、既にサンプル７を処理しており、したがって、要求をオーディオレンダラに渡す。レンダラは、次のバッファを、異なるレートで再生される２つのセクションに分割する。各レンダラは、タイムスタンプマネージャに問い合わせて、各入力タイムスタンプを出力タイムスタンプにマッピングする。
【０１５１】
ユーザが即座にレートを変更することを望む時に、第２の状況が発生する。ソースは、次に使用可能なタイムスタンプおよびそれが発生するまでの使用可能な時間の長さを照会する。このタイムスタンプを使用して、ソースが、パイプラインまたはフィルタグラフを介してレート変更を伝搬させる。
【０１５２】
次に使用可能なタイムスタンプは、タイムスタンプマネージャによって、または分散された再帰的な形で計算することができる。タイムスタンプマネージャは、チェーンに沿った各フィルタがストリームに対するレート変更を考慮に入れる（レート変更について各キューイングされたサンプルを照会することによって）必要がないという長所を有する。例として、図１５を検討されたい。
【０１５３】
この図では、タイムスタンプマネージャにレジストリが含まれる。各レンダラは、その現在の進行状況をタイムスタンプマネージャに登録し、更新する。タイムスタンプマネージャは、次の使用可能な時刻を計算して、レート変更をスケジューリングし、その時刻をソースに渡すことができる（たとえば、フレーム５で、レート変更を伝搬させるのに２フレーム）。ソースは、レンダラが（ソースタイムスタンプで）どこにあるかを見つけることもでき、アプリケーションに対するソース位置を計算することができる。タイムスタンプマネージャは、各レンダラの位置を外挿し、ソースに返す。
【０１５４】
タイムスタンプマッピング機能およびレジストリ機能を中央位置で行わせることによって、これらの機能を他のパイプライン内のコンポーネントから除去できるという点で、標準化および均一性が強化される。さらに、タイムスタンプマッピングの集中化された位置を提供することによって、エラーを減らすことができる。
【０１５５】
結論
上で説明した方法およびシステムは、レンダリング可能なディジタルデータを処理する改良された方法およびシステムを提供することができる。さまざまな方法およびシステムによって、ビデオデータ、オーディオ／ビデオデータ、オーディオ／ビデオ／サブピクチャデータ、および類似物などのディジタルデータを、ユーザの経験を強化する形での順方向と逆方向の両方での再生を可能にする形で処理できるようにする。さまざまな実施形態は、ユーザの経験を強化できる形での再生レート変更も処理することができる。
【０１５６】
構造的特徴および／または方法論的ステップに固有の言語で本発明を説明したが、請求項で定義される発明が、説明した特定の特徴またはステップに必ずしも制限されないことを理解されたい。そうではなく、特定の特徴およびステップは、請求される発明を実施する好ましい形として開示されたものである。
【図面の簡単な説明】
【図１】１つまたは複数の実施形態に従って処理することができるデータの例示的ブロックを示す図である。
【図２】データブロックを処理するシステムのブロック図である。
【図３】説明される実施形態の原理をその中で実施することができる例示的コンピューティング環境のブロック図である。
【図４】一実施形態によるデータブロックを処理するシステムのブロック図である。
【図５】一実施形態による方法のステップを説明する流れ図である。
【図６】１つまたは複数の説明される実施形態のデータブロックを処理するシステムおよびある態様を示すブロック図である。
【図７】一実施形態による方法のステップを説明する流れ図である。
【図８】一実施形態による方法のステップを説明する流れ図である。
【図９】１つまたは複数の説明される実施形態を理解するのに有用な形で例示的なデータブロックを示す図である。
【図１０】１つまたは複数の説明される実施形態を理解するのに有用な形で例示的なデータブロックを示す図である。
【図１１】１つまたは複数の説明される実施形態を理解するのに有用な形で例示的なデータブロックを示す図である。
【図１２】１つまたは複数の説明される実施形態を理解するのに有用な形で例示的なデータブロックを示す図である。
【図１３】１つまたは複数の説明される実施形態を理解するのに有用な形で例示的なデータブロックを示す図である。
【図１４】一実施形態によるデータブロックを処理する例示的システムのブロック図である。
【図１５】一実施形態によるデータブロックを処理する例示的システムのブロック図である。
【図１６】一実施形態による複雑なデータを処理する技法を示す図である。
【符号の説明】
２００ システム
２０２ アプリケーション
２０４ ソースコンポーネント
２０６ ＤＶＤ
２０８ デマルチプレクサ
２１０ ビデオデコーダ
２１２ オーディオデコーダ
２１４ サブピクチャデコーダ
２１６ ビデオレンダラ
２１８ オーディオレンダラ
２２０ グローバルクロック

Claims (75)

1. ディジタルデータの逆方向再生指示を受け取り、
   前記指示の受け取りに応答して、逆方向再生の対象である前記ディジタルデータの１つまたは複数のデータブロックが下流コンポーネントに渡されたかどうかを判定することであって、
   前記１つまたは複数のデータブロックが下流コンポーネントに渡されていないと判定される場合、少なくとも部分的に逆方向再生順序を定義するように前記１つまたは複数のデータブロックを配列し、
   前記配列されたデータブロックを下流コンポーネントに送り、
   前記１つまたは複数のデータブロックが下流コンポーネントに渡されたと判定される場合、前記１つまたは複数のデータブロックに関して逆方向再生を実施させることを試みるように前記指示を下流コンポーネントに渡すこと
   を含むことを特徴とする方法。
2. 前記指示を受け取る動作が、前記逆方向再生の対象である前記１つまたは複数のデータブロックを読み取るように構成されたソースコンポーネントによって実行されることを特徴とする請求項１に記載の方法。
3. 前記配列する動作は、１つまたは複数のデータブロックを、前記データブロックを含む媒体から逆の順序で読み取ることを含むことを特徴とする請求項１に記載の方法。
4. 前記配列する動作は、１つまたは複数のフラグを１つまたは複数のデータブロックに関連付けることを含み、前記１つまたは複数のフラグは、少なくとも１つの下流コンポーネントに、前記データブロックが逆方向再生の対象であることを示すことを特徴とする請求項１に記載の方法。
5. １つまたは複数のフラグを使用して前記データブロックの副部分の順序を変更し、逆方向再生をもたらすことをさらに含むことを特徴とする請求項４に記載の方法。
6. 前記ディジタルデータは、ビデオデータを含むことを特徴とする請求項１に記載の方法。
7. 前記データブロックは、キーフレームを含む副部分を有することを特徴とする請求項１に記載の方法。
8. 前記１つまたは複数のデータブロックを逆方向再生順序でレンダリングすることをさらに含むことを特徴とする請求項１に記載の方法。
9. コンピュータ実行可能命令をその上に有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサによって実行される際に、１つまたは複数のプロセッサに、
   ディジタルデータの逆方向再生指示を受け取り、
   前記指示の受け取りに応答して、逆方向再生の対象である前記ディジタルデータの１つまたは複数のデータブロックが下流コンポーネントに渡されたかどうかを判定することであって、
   前記１つまたは複数のデータブロックが下流コンポーネントに渡されていないと判定される場合、前記１つまたは複数のデータブロックを配列して少なくとも部分的に逆方向再生順序を定義し、
   前記配列されたデータブロックを下流コンポーネントに送り、
   前記１つまたは複数のデータブロックが下流コンポーネントに渡されたと判定される場合、前記１つまたは複数のデータブロックに関して逆方向再生を実施させることを試みるように前記指示を下流コンポーネントに渡すこと
   を行わせることを特徴とするコンピュータ可読媒体。
10. 前記命令は、１つまたは複数のデータブロックを、前記データブロックを含む媒体から逆の順序で読み込むことによって、１つまたは複数のプロセッサに前記データブロックを配列させることを特徴とする請求項９に記載のコンピュータ可読媒体。
11. 前記命令は、１つまたは複数のプロセッサに、１つまたは複数のフラグを１つまたは複数のデータブロックに関連付けさせ、前記１つまたは複数のフラグは、少なくとも１つの下流コンポーネントに、前記データブロックが逆方向再生の対象であることを示すことを特徴とする請求項９に記載のコンピュータ可読媒体。
12. 前記命令は、１つまたは複数のプロセッサに、
    １つまたは複数のフラグを１つまたは複数のデータブロックに関連付けて、前記１つまたは複数のフラグは、少なくとも１つの下流コンポーネントに、前記データブロックが逆方向再生の対象であることを示し、
    前記１つまたは複数のフラグを使用して前記データブロックの副部分の順序を変更し逆方向再生もたらすこと
    を行わせることを特徴とする請求項９に記載のコンピュータ可読媒体。
13. ディジタルデータの逆方向再生指示を受け取り、
    前記指示の受け取りに応答して、逆方向再生の対象である前記ディジタルデータの１つまたは複数のデータブロックが下流コンポーネントに渡されたかどうかを判定することであって、
    前記１つまたは複数のデータブロックが下流コンポーネントに渡されていないと判定される場合、
    前記１つまたは複数のデータブロックを、前記データブロックを含む媒体から逆の順序で読み込んで少なくとも部分的に逆方向再生順序を定義し、
    １つまたは複数のフラグを前記１つまたは複数のデータブロックに関連付けて、前記１つまたは複数のフラグは、少なくとも１つの下流コンポーネントに、前記データブロックが逆方向再生の対象であることを示し、
    前記フラグを関連付けられた前記データブロックを下流コンポーネントに送り、
    前記１つまたは複数のデータブロックが下流コンポーネントに渡されたと判定される場合、前記１つまたは複数のデータブロックに関して逆方向再生を実施させることを試みるように前記指示を下流コンポーネントに渡すこと
    を含むことを特徴とする方法。
14. 前記１つまたは複数のフラグを関連付けた後に、１つまたは複数のデータブロックを個々のデータブロックの副部分にデコードすることをさらに含むことを特徴とする請求項１３に記載の方法。
15. 前記１つまたは複数のフラグを関連付けた後に、
    １つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    １つまたは複数のフラグを使用して前記データブロックの副部分を逆の順序で下流コンポーネントに送ること
    をさらに含むことを特徴とする請求項１３に記載の方法。
16. 前記１つまたは複数のフラグを関連付けた後に、
    １つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    １つまたは複数のフラグを使用して前記データブロックの副部分を逆の順序で下流コンポーネントに送ること
    をさらに含み、前記データブロックの副部分は、レンダリングに関する前記副部分のスケジューリングおよび前記副部分のタイムスタンプの順序のさらなる操作に使用することができる１つまたは複数の関連する前記タイムスタンプを有する
    ことを特徴とする請求項１３に記載の方法。
17. 前記１つまたは複数のフラグを関連付けた後に、
    １つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    前記データブロックの副部分を逆の順序で下流コンポーネントに送るために１つまたは複数のフラグを使用すること
    をさらに含み、前記データブロックの副部分は、レンダリングに関する前記副部分のスケジューリングおよび前記副部分のタイムスタンプの順序のさらなる操作に使用することができる１つまたは複数の関連する前記タイムスタンプを有し、
    前記操作することは、タイムスタンプ値を操作することによってレート変更を実施することをさらに含む
    ことを特徴とする請求項１３に記載の方法。
18. 前記１つまたは複数のフラグを関連付けた後に、
    １つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    １つまたは複数のフラグを使用して個々のデータブロックの副部分を逆の順序で下流コンポーネントに送ること
    をさらに含み、前記データブロックの副部分は、レンダリングに関する前記副部分のスケジューリングおよび前記副部分のタイムスタンプの順序のさらなる操作に使用することができる１つまたは複数の関連する前記タイムスタンプを有し、
    前記操作することは、前記送られたデータブロックの副部分の前記タイムスタンプの有効な順序を逆転することを含む
    ことを特徴とする請求項１３に記載の方法。
19. 前記１つまたは複数のフラグを関連付けた後に、１つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    １つまたは複数のフラグを使用して前記データブロックの副部分の順序を逆転すること
    をさらに含むことを特徴とする請求項１３に記載の方法。
20. 前記１つまたは複数のフラグを関連付けた後に、１つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    デコーダを用いて、１つまたは複数のフラグを使用して前記データブロックの副部分の順序を逆転すること
    をさらに含むことを特徴とする請求項１３に記載の方法。
21. 前記ディジタルデータは、ビデオデータを含むことを特徴とする請求項１３に記載の方法。
22. 前記データブロックは、キーフレームを含む副部分を有することを特徴とする請求項１３に記載の方法。
23. 前記１つまたは複数のデータブロックを逆方向再生順序でレンダリングすることさらに含むことを特徴とする請求項１３に記載の方法。
24. コンピュータ実行可能命令をその上に有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサによって実行される際に、１つまたは複数のプロセッサに、請求項１３に記載の方法を実施させることを特徴とする１つまたは複数のコンピュータ可読媒体。
25. ソースコンポーネントを用いて、ディジタルデータの逆方向再生指示を受け取り、
    ソースコンポーネントによって下流コンポーネントに照会して、どの下流コンポーネントが逆方向再生を備える機能をサポートするかを確かめ、
    前記指示の受け取りに応答して、前記ソースコンポーネントによって、逆方向再生を指示された前記ディジタルデータの１つまたは複数のデータブロックが前記ソースコンポーネントから下流コンポーネントに渡されたかを判定することであって、
    前記１つまたは複数のデータブロックが下流コンポーネントに渡されていないと判定される場合、
    前記ソースコンポーネントを用いて、前記１つまたは複数のデータブロックを、前記データブロックを含む媒体から逆の順序で読み込んで、少なくとも部分的に逆方向再生順序を定義し、
    前記ソースコンポーネントを用いて、１つまたは複数のフラグを１つまたは複数のデータブロックに関連付けて、前記１つまたは複数のフラグは、少なくとも１つの下流コンポーネントに、前記データブロックが逆方向再生の対象であることを示し、
    前記フラグを関連付けられたデータブロックを下流コンポーネントに送り、
    前記１つまたは複数のデータブロックが下流コンポーネントに渡されたと判定される場合、
    前記ソースコンポーネントによって、逆方向再生機能をサポートする下流コンポーネントが少なくとも１つあるかを判定し、ある場合、前記ソースコンポーネントによって、前記１つまたは複数のデータブロックに関して逆方向再生を実施させることを試みるように前記指示を下流コンポーネントに渡し、前記逆方向再生は、逆方向再生をもたらす形で前記１つまたは複数のデータブロックの各々に関連するタイムスタンプを再割り当てすることにより下流コンポーネントによって実施されること
    を含むことを特徴とする方法。
26. 前記１つまたは複数のフラグを関連付けた後に、デコーダを用いて、１つまたは複数のデータブロックを個々のデータブロックの副部分にデコードすることをさらに含むことを特徴とする請求項２５に記載の方法。
27. 前記１つまたは複数のフラグを関連付けた後に、
    デコーダを用いて、１つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    １つまたは複数のフラグを使用して前記データブロックの副部分を逆の順序で下流コンポーネントに送ること
    をさらに含むことを特徴とする請求項２５に記載の方法。
28. 前記１つまたは複数のフラグを関連付けた後に、
    デコーダを用いて、１つまたは複数のデータブロックを個々のデータブロックの副部分にデコードし、
    １つまたは複数のフラグを使用して、前記データブロックの副部分であって、レンダリングに関する前記副部分のスケジューリングおよび前記副部分のタイムスタンプの順序のさらなる操作に使用することができる１つまたは複数の関連するタイムスタンプを有する前記データブロックの副部分を逆の順序で下流コンポーネントに送ること
    をさらに含むことを特徴とする請求項２５に記載の方法。
29. 前記ディジタルデータは、ビデオデータを含むことを特徴とする請求項２５に記載の方法。
30. 前記データブロックは、キーフレームを含む副部分を有することを特徴とする請求項２５に記載の方法。
31. レンダラを用いて、前記１つまたは複数のデータブロックを逆方向再生順にレンダリングすることをさらに含むことを特徴とする請求項２５に記載の方法。
32. コンピュータ実行可能命令をその上に有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサによって実行される際に、１つまたは複数のプロセッサに、請求項２５に記載の方法を実施させることを特徴とする１つまたは複数のコンピュータ可読媒体。
33. ディジタルデータの逆方向再生指示を受け取るように構成された第１コンポーネントであって、前記指示の受け取りに応答して、逆方向再生の対象である前記ディジタルデータの１つまたは複数のデータブロックが前記第１コンポーネントの下流の第２コンポーネントに渡されたかどうかを判定し、
    前記１つまたは複数のデータブロックが前記第２コンポーネントに渡されていないと判定される場合、
    前記１つまたは複数のデータブロックを、前記データブロックを含む媒体から逆の順序で読み込むように構成されて、少なくとも部分的に逆方向再生順序を定義する、第１コンポーネント
    を含み、前記第１コンポーネントが、さらに、１つまたは複数のフラグを１つまたは複数のデータブロックに関連付けるように構成され、前記１つまたは複数のフラグは、前記データブロックが逆方向再生の対象であることを少なくとも１つの下流コンポーネントに示し、
    １つまたは複数のフラグを付けられたデータブロックを受け取り、下流コンポーネントに逆の順序で前記データブロックの副部分を送るように構成される、第２コンポーネントを含み、
    前記１つまたは複数のデータブロックが前記第２コンポーネントに渡されていないと判定される場合、前記１つまたは複数のデータブロックに関して逆方向再生を実施させることを試みるように前記指示を前記第１コンポーネントから前記第２コンポーネントに渡すことを特徴とするシステム。
34. 前記データブロックの副部分は、前記副部分をスケジューリングしてレンダリングするのに使用する１つまたは複数の関連するタイムスタンプを有し、前記第２コンポーネントが、さらに、前記データブロックの副部分の前記タイムスタンプの順序を操作するように構成されることを特徴とする請求項３３に記載のシステム。
35. 前記第２コンポーネントは、デコーダコンポーネントを含むことを特徴とする請求項３３に記載のシステム。
36. 前記第２コンポーネントは、レンダラコンポーネントを含むことを特徴とする請求項３３に記載のシステム。
37. 前記第１コンポーネントおよび前記第２コンポーネントは、フィルタグラフの少なくとも一部を含むことを特徴とする請求項３３に記載のシステム。
38. 前記データブロックは、キーフレームを含む副部分を有することを特徴とする請求項３３に記載のシステム。
39. ディジタルデータの逆方向再生の表示を受け取り、
    媒体から前記ディジタルデータの１つまたは複数のデータブロックを読み込み、１つまたは複数のデータブロックを配列して少なくとも部分的に逆方向再生順序を定義し、
    すべてのデータブロックにまたがって単調増加する形で、前記逆方向再生の対象であるデータブロックに加えて、これと同様に、タイムスタンプをデータブロックに関連付け、前記関連付ける動作は、前記データブロックが再生されるレートの変更をもたらす形で前記タイムスタンプを関連付けることを含み、
    レート変更の対象であるデータブロックが下流コンポーネントに渡されたかどうかを判定し、渡された場合、レート変更を実施させることを試みるようにレート変更要求を下流コンポーネントに渡すこと
    を含むことを特徴とする方法。
40. 前記指示を受け取る動作が、前記逆方向再生指示の対象であるデータを読み取るように構成されたソースコンポーネントによって実行されることを特徴とする請求項３９に記載の方法。
41. 前記配列する動作は、１つまたは複数のデータブロックを、前記データブロックを含む媒体から逆の順序で読み込むことを含むことを特徴とする請求項３９に記載の方法。
42. 前記配列する動作は、１つまたは複数のフラグを１つまたは複数のデータブロックに関連付けることを含み、前記１つまたは複数のフラグは、前記データブロックが逆方向再生の対象であることを少なくとも１つの下流コンポーネントに示すことを特徴とする請求項３９に記載の方法。
43. 前記配列する動作は、１つまたは複数のフラグを１つまたは複数のデータブロックに関連付けることを含み、１つまたは複数のフラグは、前記データブロックが逆方向再生の対象であることを少なくとも１つの下流コンポーネントに示し、前記１つまたは複数のフラグを使用して前記データブロックの副部分の順序を変更し逆方向再生をもたらすことをさらに含むことを特徴とする請求項３９に記載の方法。
44. 前記ディジタルデータは、ビデオデータを含むことを特徴とする請求項３９に記載の方法。
45. 前記データブロックは、キーフレームを含む副部分を有することを特徴とする請求項３９に記載の方法。
46. 前記関連付けられたタイムスタンプに従ってデータブロックをレンダリングすることをさらに含むことを特徴とする請求項３９に記載の方法。
47. コンピュータ実行可能命令をその上に有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサによって実行される際に、１つまたは複数のプロセッサに、請求項３９に記載の方法を実施させることを特徴とする１つまたは複数のコンピュータ可読媒体。
48. ソースコンポーネントで、ディジタルデータを再生する再生レートの変更に関するレート変更要求を受け取り、
    前記レート変更要求に関連するデータが、前記ソースコンポーネントから下流コンポーネントに供給されたかどうかを判定し、
    前記データが下流コンポーネントに供給されていない場合に、少なくとも前記データがレート変更要求の対象であることを示すのに有効に前記データを処理し、
    前記データが下流コンポーネントに供給されている場合に、下流コンポーネントに前記レート変更要求を渡して前記レート変更を実施させることを試みること
    を含むことを特徴とする方法。
49. 下流コンポーネントを用いて前記レート変更要求を受け取り、
    前記レート変更要求に関連するデータが別の下流コンポーネントに供給されたかどうかを判定し、
    前記データが別の下流コンポーネントに供給されていない場合に、少なくとも前記データがレート変更要求の対象であることを示すのに有効に前記データを処理し、
    前記データが異なる下流コンポーネントに供給されている場合に、前記異なる下流コンポーネントに前記レート変更要求を渡して前記レート変更を実施させることを試み、前記データが既にレンダリングされている場合に、前記レート変更要求を捨てること
    をさらに含むことを特徴とする請求項４８に記載の方法。
50. 最初の下流コンポーネントは、デマルチプレクサを含むことを特徴とする請求項４８に記載の方法。
51. 最初の下流コンポーネントは、デコーダを含むことを特徴とする請求項４８に記載の方法。
52. 前記下流コンポーネントの１つは、レンダラを含むことを特徴とする請求項４８に記載の方法。
53. 前記下流コンポーネントの１つは、ビデオレンダラを含むことを特徴とする請求項４８に記載の方法。
54. 前記下流コンポーネントの１つは、ビデオデコーダを含むことを特徴とする請求項４８に記載の方法。
55. ソースコンポーネントであって、
    ディジタルデータが再生される再生レートの変更に関するレート変更要求を受け取り、
    前記レート変更要求に関連するデータが前記ソースコンポーネントから第１下流コンポーネントに供給されたかどうかを判定する
    ように構成され、
    前記データが前記第１下流コンポーネントに供給されていない場合に、前記ソースコンポーネントが、少なくとも前記データがレート変更要求の対象であることを示すのに有効に前記データを処理するように構成され、
    前記データが前記第１下流コンポーネントに供給されている場合に、前記ソースコンポーネントが、前記レート変更要求を前記第１下流コンポーネントに渡すように構成されて前記レート変更を実施させることを試みる、
    ソースコンポーネントと、
    第１下流コンポーネントであって、
    前記レート変更要求を受け取り、前記レート変更要求に関連するデータが第２下流コンポーネントに供給されたかどうかを判定する
    ように構成され、
    前記データが前記第２下流コンポーネントに供給されていない場合に、前記第１下流コンポーネントが、少なくとも前記データがレート変更要求の対象であることを示すのに有効に前記データを処理するように構成され、
    前記データが前記第２下流コンポーネントに供給されている場合に、前記第１下流コンポーネントが、前記レート変更要求を前記第２下流コンポーネントに渡すように構成されて前記レート変更を実施させることを試みる、
    第１下流コンポーネントと
    を含むことを特徴とするシステム。
56. 前記下流コンポーネントの１つは、デコーダを含むことを特徴とする請求項５５に記載のシステム。
57. 前記下流コンポーネントの１つは、レンダラを含むことを特徴とする請求項５５に記載のシステム。
58. 前記下流コンポーネントの１つは、ビデオレンダラを含むことを特徴とする請求項５５に記載のシステム。
59. データ処理パイプラインの一部を含むレンダラによってレンダリングされる１つまたは複数のデータサンプルに情報を付加することであって、前記情報は、もしあればデータサンプルがその対象であるレート変更と、データサンプルをレンダリングすべき時に関連するタイムスタンプと、前記データサンプルが順方向または逆方向のどちらでレンダリングされるかとを定義し、
    前記１つまたは複数のデータサンプルおよびそれらに関連する情報を前記パイプラインに沿って伝搬させ、
    データサンプルおよびそれらに関連する情報を、前記データサンプルを媒体から読み込むソースコンポーネントの下流の１つまたは複数のコンポーネントで受け取り、
    前記１つまたは複数の下流コンポーネントで、前記情報に従ってレート変更およびレンダリング方向の一方または両方を実施するのに十分な１つまたは複数のデータサンプルを処理し、前記データサンプルに関連するタイムスタンプ値を少なくとも操作すること
    を含むことを特徴とする方法。
60. 前記処理する動作は、データサンプル順序を逆転して逆方向再生をもたらすことを含むことを特徴とする請求項５９に記載の方法。
61. 前記処理する動作は、データサンプル順序を逆転して逆方向再生をもたらすことを含み、
    タイムスタンプ値を操作する前記動作およびデータサンプル順序を逆転する前記動作の少なくとも１つが、前記レンダラによって実行される
    ことを特徴とする請求項５９に記載の方法。
62. コンピュータ実行可能命令をその上に有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサによって実行される際に、１つまたは複数のプロセッサに、請求項５９に記載の方法を実施させることを特徴とする１つまたは複数のコンピュータ可読媒体。
63. ソースコンポーネントで、特定のソース時間を有するデータサンプルに関するレート変更要求を受け取り、
    前記レート変更要求の受け取りに応答して、前記ソースコンポーネントに関連する１つまたは複数のバッファを調べて前記レート変更が行われる対応するデータサンプルが存在するかどうかを確かめ、
    前記データサンプルが、前記１つまたは複数のバッファで見つかる場合に、レート変更情報を前記データサンプルに付加し、
    前記データサンプルが、前記ソースコンポーネントのバッファで見つからない場合に、前記レート変更要求を次の順番の下流コンポーネントに送ること
    を含むことを特徴とする方法。
64. 前記付加する動作は、前記データサンプルがまだ前記バッファ内にある間に、前記レート変更情報を前記データサンプルに付加することを含むことを特徴とする請求項６３に記載の方法。
65. 前記付加する動作は、前記レート変更情報をキャッシングし、前記データサンプルが前記ソースコンポーネントによって処理される時に前記レート変更情報を前記データサンプルに付加することを含むことを特徴とする請求項６３に記載の方法。
66. 前記次の順番の下流コンポーネントを用いて前記レート変更要求を受け取り、
    前記レート変更要求の受け取りに応答して、前記下流コンポーネントに関連する１つまたは複数のバッファを調べて前記レート変更が行われる対応するデータサンプルが存在するかどうかを確かめ、
    前記データサンプルが、前記下流コンポーネントのバッファで見つかる場合に、レート変更情報を前記データサンプルに付加し、
    前記データサンプルが、前記下流コンポーネントのバッファで見つからない場合に、前記レート変更要求を次の順番の下流コンポーネントに送ること
    をさらに含むことを特徴とする請求項６３に記載の方法。
67. 前記データサンプルが、前記要求を受け取るコンポーネントのすべてのバッファで見つからない場合に、前記レート変更要求がレンダラによって受け取られるまで、前記レート変更要求を下流コンポーネントに送り続けることと、前記レート変更要求が前記レンダラによって受け取られ、前記データサンプルが前記レンダラによってレンダリングされている場合に、前記レート変更要求を破棄することとをさらに含むことを特徴とする請求項６６に記載の方法。
68. 前記ソースコンポーネントから下流のコンポーネントで前記レート変更要求を実施することをさらに含むことを特徴とする請求項６３に記載の方法。
69. 前記ソースコンポーネントから下流のレンダラで前記レート変更要求を実施することをさらに含むことを特徴とする請求項６３に記載の方法。
70. コンピュータ実行可能命令をその上に有する１つまたは複数のコンピュータ可読媒体であって、前記コンピュータ実行可能命令は、１つまたは複数のプロセッサによって実行される際に、１つまたは複数のプロセッサに、請求項６３に記載の方法を実施させることを特徴とする１つまたは複数のコンピュータ可読媒体。
71. レンダリングされるデータサンプルに関連するタイムスタンプ情報を生成し、管理するソースコンポーネントであって、
    順方向再生および逆方向再生の対象であるデータサンプルに関する単調増加するタイムスタンプを生成し、
    逆方向再生をもたらすためにデータサンプルを含むデータブロックの順序を逆転し、
    逆方向で再生される個々のデータブロックにタグを付け、
    レート変更をスケジューリングするために、下流コンポーネントに照会することによって前記レート変更をスケジューリングできるようにする
    ように構成される、ソースコンポーネントと、
    デコーダコンポーネントであって、
    レート変更の受け取りに応答してデータサンプルに対する補間を実行し、
    下流コンポーネントにレート変更を渡し、
    逆方向再生データブロックを、処理のためにより小さい逆方向ブロックに分解し、
    データサンプルの出力タイムスタンプを修正してレート変更の実施を支援する
    ように構成されたデコーダコンポーネントと、
    レンダラコンポーネントであって、
    レート変更に関連するデータサンプルの有効プレゼンテーションタイムスタンプを計算し、
    逆方向再生を意図されたデータサンプルを受け取り、
    データサンプルをキャッシングして前記レンダラコンポーネントが前記データサンプルを逆の順序でレンダリングできるようにする
    ように構成されたレンダラコンポーネントと
    を含むことを特徴とするシステム。
72. コンポーネントは、逆方向再生データブロックを副ブロックに分解することができ、その後、適当に変更されたタイムスタンプと共に逆の順序で前記副ブロックを送ることができることを特徴とする請求項７１に記載のシステム。
73. 前記レンダラによって使用することができ、入力タイムスタンプを出力タイムスタンプにマッピングして、レート変更を実施するタイムスタンプマネージャをさらに含むことを特徴とする請求項７１に記載のシステム。
74. レンダリングされるデータサンプルに関連するタイムスタンプ情報を生成し、管理するソースコンポーネントであって、
    順方向再生および逆方向再生の対象であるデータサンプルに関する単調増加するタイムスタンプを生成し、
    データサンプルを含むデータブロックの順序を逆転して逆方向再生をもたらし、
    逆方向で再生される各データブロックにタグを付け、
    レート変更をスケジューリングするために、下流コンポーネントを照会することによって前記レート変更をスケジューリングできるようにする
    ように構成される、ソースコンポーネントと、
    データサンプルをデコードするように構成されたデコーダコンポーネントと、
    データサンプルをレンダリングするように構成されたレンダラコンポーネントと、
    レート変更を実施するために、次に使用可能なタイムスタンプと、前記タイムスタンプが発生するまでに使用可能な時間の長さとに関して前記ソースによって照会することができるタイムスタンプマネージャと
    を含むことを特徴とするシステム。
75. 前記タイムスタンプマネージャに関連するレジストリをさらに含み、前記レンダラが、前記タイムスタンプマネージャに登録し、データサンプルをレンダリングする時に前記レジストリを更新するように構成されることを特徴とする請求項７４に記載のシステム。

Images