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