JP4491151B2 - ストリーミング情報受信機のデータ・フォーマット - Google Patents

Description

【０００１】
（発明の背景）
本発明は、ストリーミング情報に関するものである。更に詳細には、本発明は、ストリーミング情報を記録しそしてこの格納した情報を選択的なプレイバックのため検索することに関している。
【０００２】
より高速のプロセッサ、向上したグラフィックス等を含む技術の進歩により、デスクトップ・コンピュータは、容易にストリーミング情報を受けそしてこのストリーミング情報をユーザに提示することができる。ストリーミング情報の一般的な例には、インターネットのようなワイド・エリア・ネットワークを介して配信されるストリーミング・ビデオ／オーディオが含まれる。例えば、テレビジョン放送信号は、そうでない場合には、衛星、テレビジョン送信機等を使って無線で送信されるものであるが、これは、エンコードされ、そしてインターネットを介してリモートのコンピュータ・ユーザに対し伝送するために利用可能とされる。デスクトップ・コンピュータ・ユーザによる要求があった時、オーディオ／ビデオ・データを包含するこのエンコードしたデータ・パケットは、デスクトップ・コンピュータ・ユーザに対しシーケンシャルで送られる。このデータ・パケットは、受け取られた時、デスクトップ・コンピュータが順番にデコードし処理して、可能な限りほぼリアルタイムでそのストリーミング情報をユーザに対しレンダリングする。レンダリングまたは提示の後、このデータ・パケットは捨てられる。
【０００３】
上述のようにストリーミング情報を処理することは有用であるが、多くの欠点が存在する。現在は、ストリーミング情報は、各々のデスクトップ・コンピュータの要求時に提供している。したがって、各々のユーザは、所望のストリーミング情報を受け取るため、ストリーミング情報のソースとの個別の接続を形成しなければならない。一旦開始されると、ユーザは、ストリーミング情報をレンダリングする態様を制御することができない。例えば、ユーザは、別の多数を実行するために一時的にその入来するストリーミング情報を“ポーズ”させ、そしてまた希望するときにビューイングを再開させる、ということができない。同様に、ユーザは、データ・パケットが捨てられるため先にレンダリングした部分を繰り返したり、あるいはデータ・パケットをまだ受け取っていないことのために先へとスキップすることができない。
【０００４】
したがって、ストリーミング情報をレンダリングする方法を改良することに対するニーズがまだある。デスクトップ・コンピュータおよびインターネットから受けるストリーミング情報に関連させて上述したが、改良したプロセスは、他の情報機器または計算デバイス並びに他の形態のストリーミング情報に対しても適用可能である。
（発明の摘要）
ストリーミング用データ・ブロック・フォーマットは、第１データ・ブロック・サイズ・フィールド、および第２データ・ブロック・サイズ・フィールドを含み、各フィールドはデータ・ブロックのサイズを示す。このデータ・ブロック・フォーマットにおいて、ペイロード・フィールドが第１データ・ブロック・サイズ・フィールドおよび第２データ・サイズに隣接している。
（好ましい実施形態の詳細な説明）
オーバービュー
図１は、これに関連する論述は、本発明を実現可能な第１の例示の計算環境の全体的な説明を手短に行うことを意図するものである。必ずしも必要ではないが、本発明の説明は、少なくとも部分的に、コントローラ、プロセッサ、パーソナル・コンピュータまたは他の計算デバイスが実行するプログラム・モジュールのようなコンピュータ実行可能命令の一般的なコンテキストで行うこととする。一般に、プログラム・モジュールは、特定のタスクを実行したり、あるいは特定の抽象的データ・タイプを使用する、ルーチン・プログラム、オブジェクト、コンポーネント、データ構造等を含む。プログラム・モジュールが実行するタスクは、以下においてブロック図およびフローチャートを使って説明する。当業者であれば、説明、ブロック図、フローチャートをプロセッサ実行可能の命令に実装することができ、この命令は、コンピュータ読み取り可能媒体上に書くことができる。加えて、当業者には理解されるように、本発明は、ハンドヘルド・デバイス、マルチプロセッサ・システム、マイクロプロセッサをベースとするあるいはプログラマブルの消費者用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレーム・コンピュータ等を含む、その他の情報機器で実施可能である。また、本発明は、分散型計算機環境において、通信ネットワークを通じてリンクしたリモート処理デバイスによってタスクを実行するという実施も可能である。ある分散型計算機環境においては、プログラム・モジュールは、ローカルおよびリモートのメモリ・ストレージ・デバイスの双方に配置することができる。
【０００５】
図１を参照すると、本発明を実施するための第１の例示のシステムは、従来のパーソナル・コンピュータ２０の形態とした汎用計算デバイスを含み、これは、処理ユニット（ＣＰＵ）２１、システム・メモリ２２、およびシステム・メモリから処理ユニット２１までを含む種々のシステム・コンポーネントを結合するシステム・バス２３を含む。システム・バス２３は、種々のバス・アーキテクチャのいずれかを用いたメモリ・バスまたはメモリ・コントローラ、周辺バス、およびローカル・バスを含む、数種類のバス構造のいずれでもよい。このシステム・メモリは、リード・オンリ・メモリ（ＲＯＭ）２４、およびランダム・アクセス・メモリ（ＲＡＭ）２５を含む。起動中等においてパーソナル・コンピュータ２０内のエレメント間の情報転送に供する基本ルーチンを収容する基本入出力システム（ＢＩＯＳ）２６は、ＲＯＭ２４に格納してある。また、パーソナル・コンピュータ２０は、ハード・ディスク（図示せず）の読み取りおよび書き込みを行うハード・ディスク・ドライブ２７、リムーバブル磁気ディスク２９の読み取りおよび書き込みを行う磁気ディスク・ドライブ２８、並びにＣＤ−ＲＯＭまたはその他の光媒体のようなリムーバブル光ディスク３１の読み取りおよび書き込みを行う光ディスク・ドライブ３０も含むことができる。ハード・ディスク・ドライブ２７、磁気ディスク・ドライブ２８、および光ディスク・ドライブ３０は、ハード・ディスク・ドライブ・インターフェース３２、磁気ディスク・ドライブ・インターフェース３３、および光ドライブ・インターフェース３４によって、それぞれシステム・バス２３に接続してある。これらのドライブおよびそれに関連するコンピュータ読み取り可能媒体は、コンピュータ読み取り可能命令、データ構造、プログラム・モジュール、およびパーソナル・コンピュータ２０用のその他のデータの不揮発性格納を行う。
【０００６】
ここに記述する例示の環境は、ハード・ディスク、リムーバブル磁気ディスク２９およびリムーバブル光ディスク３１を採用するが、当業者により理解されるべきであるが、磁気カセット、フラッシュ・メモリ・カード、ディジタル・ビデオ・ディスク（ＤＶＤ）、ベルヌーイ・カートリッジ、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）等のような、コンピュータによるアクセスが可能なデータを格納することができる、他の種類のコンピュータ読み取り可能媒体も、この例示の動作環境において使用可能である。
【０００７】
多数のプログラム・モジュールは、ハード・ディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５上に格納することができ、オペレーティング・システム３５、１つ以上のアプリケーション・プログラム３６、その他のプログラム・モジュール３７、およびプログラム・データ３８を含む。ユーザは、キーボード４０、ポインティング・デバイス（マウス）４２のようなローカル入力デバイスによって、コマンドおよび情報をパーソナル・コンピュータ２０に入力することができる。他の入力デバイス（図示せず）として、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ（satellite dish）、スキャナ等を含むことができる。これらおよびその他の入力デバイスは、多くの場合、システム・バス２３に結合したシリアル・ポート・インターフェース４６を介して、処理ユニット２１に接続しているが、サウンド・カード、パラレル・ポート、ゲーム・ポートまたはユニバーサル・シリアル・バス（ＵＳＢ：universal serial bus）のようなその他のインターフェースによって接続することも可能である。モニタ４７または別のタイプのディスプレイ・デバイスも、ビデオ・アダプタ４８のようなインターフェースを介して、システム・バス２３に接続する。モニタ４７に加えて、パーソナル・コンピュータ２０は、通常、サウンド・カード５７に接続したスピーカ４５やプリンタ（図示せず）のような、その他の周辺出力デバイスを含むこともできる。
【０００８】
パーソナル・コンピュータ２０は、リモート・コンピュータ４９のような１つ以上のリモート・コンピュータへの論理接続を用いて、ネットワーク形環境で動作することも可能である。リモート・コンピュータ４９は、別のパーソナル・コンピュータ、ハンドヘルド・デバイス、サーバ、ルータ、ネットワークＰＣ、ピア・デバイス、またはその他のネットワーク・ノードとすることができ、通常、パーソナル・コンピュータ２０に関して先に記載したエレメントの多くまたは全てを含むが、メモリ・ストレージ・デバイス５０だけを図１に示す。図１に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）５１およびワイド・エリア・ネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、オフィス規模、企業規模のコンピュータ・ネットワーク・イントラネットおよびインターネットでは一般的である。
【０００９】
ＬＡＮネットワーキング環境で用いる場合、パーソナル・コンピュータ２０は、ネットワーク・インターフェースまたはアダプタ５３を介して、ローカル・エリア・ネットワーク５１に接続する。ＷＡＮネットワーキング環境で用いる場合、パーソナル・コンピュータ２０は通常、モデム５４またはインターネットのようなワイド・エリア・ネットワーク５２上で通信を確立するその他の手段を含む。モデム５４は、内蔵型でも外付け型でもよく、シリアル・ポート・インターフェース４６を介してシステム・バス２３に接続する。ネットワーク環境では、パーソナル・コンピュータ２０に関して図示したプログラム・モジュールまたはその一部を、リモート・メモリ・ストレージ・デバイスに格納することも可能である。理解されるように、図示のネットワーク接続は一例であり、コンピュータ間に通信リンクを確立するその他の手段も使用可能である。例えば、ネットワークの１つ以上の部分間に、無線通信リンクを確立することもできる。
【００１０】
ストリーミング情報は、多くの既知の方法および技術を使ってコンピュータ２０により受けることができる。一般に、ストリーミング情報のソースは、リモート・コンピュータであって、コンピュータ２１が、このリモート・コンピュータに対し有線または無線のモデムを使って接続されている。この技術は、ストリーミング情報を代表的にはディジタル形態でイントラネットまたはインターネットを通して提供するときに使用されることが多い。ディジタル・ストリーミング情報は、更に、衛星受信機、ディッシュ等により受ける衛星信号で構成することもできる。
【００１１】
しかし、ストリーミング情報はまた、アナログ信号としても到来することがある。例えば、ストリーミング情報は、放送のラジオまたはテレビジョンの信号で構成することもできる。このような場合、コンピュータ２０は、その放送信号を受けそしてこのアナログ信号をシステム・バス２３を介して伝送するためディジタル形態に変換するラジオ・チューナ６０およびテレビジョン・チューナ６２を含む。
【００１２】
理解されるべきであるが、本発明は、上記のコンピュータ２０の他に、他の計算デバイスにおいて使用することができる。図２は、モバイル・デバイス６８のブロック図であり、これは、別の例示の計算環境である。モバイル・デバイス６８は、マイクロプロセッサ７０と、メモリ７２と、入出力（Ｉ／Ｏ）コンポーネント７４と、例えばコンピュータ２０と通信するための通信インターフェース７６とを含む。１実施形態では、上述のコンポーネントは、互いに通信するため、適当なバス７８を介して結合している。
【００１３】
メモリ７２は、バッテリ・バックアップ・モジュール（不図示）を備えたランダム・アクセス・メモリ（ＲＡＭ）のような不揮発性の電子メモリとして実現し、これによって、メモリ７２に格納された情報が、モバイル・デバイス６８への全体の電力が遮断されたときに失われないようにする。メモリ７２の一部分は、好ましくは、プログラム実行のためアドレス可能なメモリとして割り当て、他方、メモリ７２の別の部分は、好ましくは、例えばディスク・ドライブ上の記憶をシミュレートするために記憶のために使用する。
【００１４】
メモリ７２は、オペレーティング・システム８０と、アプリケーション・プログラム８２並びにオブジェクト・ストア８４とを備えている。動作の間においては、オペレーティング・システム８０は、好ましくはメモリ７２からプロセッサ７０が実行する。オペレーティング・システム８０は、１つの好ましい実施形態では、“WINDOWS CE”ブランドのオペレーティング・システムであり、マイクロソフト社から市販されている。オペレーティング・システム８０は、好ましくはモバイル・デバイス用に設計されたものであり、そしてデータベース・フィーチャを実装し、このデータベース・フィーチャは、アプリケーション・プログラム８２が、１組の露出したアプリケーション・プログラミング・インターフェースおよびメソッドを通して利用することができる。オブジェクト・ストア８４内のオブジェクトは、アプリケーション・プログラム８２とオペレーティング・システム８０が、その露出したアプリケーション・プログラミング・インターフェースおよびメソッドに対するコールに応答して少なくとも部分的に維持する。
【００１５】
通信インターフェース７６は、種々のデバイスおよび技術を表しており、これは、モバイル・デバイス６８がストリーミング情報を受け取ることができるようにする。それら種々のデバイスは、コンピュータ２０に関連して上述したものと同様のものであり、そしてこれらには、いくつかを挙げれば、有線および無線のモデム、衛星受信機、放送チューナが含まれる。また、モバイル・デバイス６８は、コンピュータ２０に直接接続することによって、それとの間でデータを交換できる。このような場合では、通信インターフェース７６は、赤外線送受信機、あるいはシリアルまたはパラレルの通信接続とすることができ、これらは全て、ストリーミング情報を送信する能力を有している。
【００１６】
図３は、モバイル・デバイス６８の簡略化した模式図である。モバイル・デバイス６８は、マイクロソフト社から提供されるソフトウエアを有する名称Ｈ／ＰＣで販売されているデスクトップ・アシスタントとすることができる。１実施形態では、モバイル・デバイス６８は、小型化したキーボード８３と、ディスプレイ８５と、スタイラス８６とを備えている。図３に示したこの実施形態では、ディスプレイ８５は、液晶ディスプレイ（ＬＣＤ）であり、これは、スタイラス８６と共にコンタクト感知型ディスプレイ・スクリーンを使用する。スタイラス８６は、ディスプレイ８５を、指示された座標にて押圧するかあるいはコンタクトすることによって、ある一定のユーザ入力機能を達成する。小型化キーボード８３は、好ましくは、小型英数字キーボードとして実現し、これには、任意の適当なまた所望の機能キーを備え、これは、ある一定のユーザ入力機能を達成するために設けている。他の既知の実施形態では、キーボード８３を省き、そして“ソフト”キーボードを、コンタクト感知ディスプレイ・スクリーンを通して設ける。更に他の実施形態では、文字認識モジュールを用いることにより、スタイラス８６を使ってコンタクト感知ディスプレイ・スクリーン上に書かれた文字を認識するようにする。
【００１７】
図４は、本発明が動作できる更に別の例示の環境を示している。図４においては、エンタテイメント機器９０を示しており、これは、処理ユニット２１と、システム・メモリ２２と、システム・バス２３を備えている。ハード・ディスク・ドライブ２７または上述の任意の他の記憶デバイスは、システム・バス２３に更に結合し、そしてプログラム・アプリケーション、データ等の一時的並びに恒久的な記憶のために使用する。上述のコンピュータ２０のような代表的なデスクトップ・コンピュータとは異なり、エンタテイメント機器９０は、レシーバ９４と共に動作可能なハンドヘルド・リモート９２のような限られた入力デバイスを使用することもでき、そのレシーバは、赤外線レシーバ、無線レシーバ等とすることができる。エンタテイメント機器９０においては、情報は、ユーザに対し、ビデオ・アダプタ４８でシステム・バス２３に結合したモニタ４７または他のディスプレイ・デバイスを使ってレンダリングする。また、オーディオ情報もレンダリングし、これは、スピーカ４９で示している。スピーカ４９は、サウンド・カード５７でシステム・バス２３に結合し、そしてこれは、ビデオ・アダプタ４８と組み合わせることによって、所望ならば信号デバイスを形成することができる。更に理解されるべきであるが、オーディオ／ビデオ情報は、モニタ４７およびスピーカ４９へと更に接続した増幅器等のような外部コンポーネントに対し提供することができる。
【００１８】
ストリーミング情報は、エンタテイメント機器９０に対し通信インターフェース９８を介して提供する。通信インターフェース９８は、２つの前述の環境に関して上述したデバイスおよび技術の任意のものとすることができる。
【００１９】
ディレイ・フィルタ
図５は、ストリーミング情報を処理するためのシステム１１０を示す全体ブロック図である。システム１１０は、ディレイ・フィルタ１１２を含み、これは、ストリーミング情報ソース１１４から受けるストリーミング情報を一時的に格納するためのものである。ディレイ・フィルタ１１２は、更に、レンダリング・デバイスまたはデバイス１１６に結合し、これによってユーザによる要求時にストリーミング情報をレンダリングする。また、図５に示しているのはエンコーダ１１８とデコーダ１２０である。必ずしも必要ではないが、エンコーダ１１８とデコーダ１２０とは、システム性能を向上させることができ、エンコーダ１１８は、ストリーミング情報ソース１１４を受けそしてディレイ・フィルタ１１２への転送および格納の前にストリーミング情報を圧縮する。デコーダ１２０は、ディレイ・フィルタ１１２に一時的に格納された圧縮フォーマットのストリーミング情報を受け、そしてこのストリーミング情報をレンダリング・デバイス１１６に転送する前に圧縮解除する。
【００２０】
ここで注意されたいことは、システム１１０は、上述の計算環境のいずれにおいても、あるいはそれと同様の計算環境においても動作させることができることである。当業者には認識されるように、ディレイ・フィルタ１１２、レンダリング・デバイス１１６、エンコーダ１１８およびデコーダ１２０は、ハードウエア、ソフトウエアあるいはこれらの組み合わせで実現することができる。例示としての１実施形態では、ディレイ・フィルタ１１２は、オペレーティング・システムにおいて具体化する。高レベルのアプリケーション・プログラムあるいはオペレーティング・システムの他の部分は、当該分野でよく知られたアプリケーション・プログラム・インターフェース（ＡＰＩ）を使ってディレイ・フィルタ１１２の機能にアクセスすることができる。
【００２１】
動作については、ストリーミング情報ソース１１４は、情報ストリームを（オプションとしてエンコーダ１１８を介して）ディレイ・フィルタ１１２に供給する。一般に、ストリーミング情報は、コンテンツ情報の１つ以上のチャンネルを表すディジタル・データから構成される。例えば、ストリーミング情報ソース１１４は、上述の通信インターフェースを介して利用可能なイントラネットまたはインターネットから成ることができる。同様に、ストリーミング情報ソース１１４は、アナログまたはディジタルのテレビジョン・チューナで構成でき、これにおいては、別個のオーディオ、ビデオおよびデータ（例えば、クローズド・キャプショニング）の情報ストリームは単一のチャンネルから成る。他のストリーミング情報のソースには、オーディオ・チューナ、衛星受信機等を含むが、但しこれには限られない。
【００２２】
図示した実施形態では、エンコーダ１１８は、ストリーミング情報を受け、そしてこのストリーミング情報をエンコードあるいは圧縮して、既知のフォーマット、例えば使用するならば、“ＭＰＥＧ”、“ＡＶＩ”、“ＭＯＶ”（Ａｐｐｌｅ（登録商標）ＱｕｉｃｋＴｉｍｅ（登録商標）、“ＷＡＶ”にするが、但し、本発明は任意の特定の１つのエンコーディング・フォーマットに限定されない。
【００２３】
一般に、以下で述べるように、ディレイ・フィルタ１１２は、ライタ（writer）モジュール１２２、サーキュラ・バッファ１２４、１つ以上のリーダー（reader）モジュール１２６を備えている。ライタ・モジュール１２２は、ストリーミング情報ソース１１４が供給するストリーミング情報を受け、そしてこのストリーミング情報をサーキュラ・バッファ１２４に書き込む。サーキュラ・バッファ１２４は、上述の任意の記憶デバイスで構成することができ、例えばハード・ディスク２７またはＲＡＭメモリである。リーダー・モジュール１２６は、サーキュラ・バッファ１２４にアクセスすることにより、ストリーミング情報をレンダリングすべきとき、このストリーミング情報を検索する。サーキュラ・バッファ１２４に格納されたストリーミング情報がエンコードあるいは圧縮されている場合、デコーダ１２０は、このストリーミング情報をデコードまたは圧縮解除し、そしてこれを次にレンダリング・デバイス１１６に供給する。
【００２４】
図６は、ディレイ・フィルタ１１２のより詳細な模式的表現である。この図示実施形態では、ストリーミング情報は、テレビジョンの信号またはチャンネルから成り、これは、オーディオ、ビデオ、データ（クローズド・キャプショニング）のストリームを含んでいる。このストリーミング情報は、最初に、ストリーム・アナライザ１３０に供給し、そしてこれは、その入来ストリームを分析し、そしてこの情報を、そのストリームの各々内に存在することのある同期ポイントとして提供する。同期ポイントは、ある種のタイプのストリーミング情報をレンダリングするのに使用し、そしてこれは、以下で詳細に説明する。
【００２５】
ストリーミング情報および同期ポイント情報は、ライタ・モジュール１２２に供給する。１実施形態では、図示のように、ライタ・モジュール１２２は、ｍｕｘライタで構成し、これは、サーキュラ・バッファ１２４内への格納のためにマルチ・ストリームのストリーミング情報を受ける。上で示したように、１つ以上のリーダー・モジュール１２６（ここでは、１２６１，１２６２，１２６３としてラベルを付す）を設けることにより、サーキュラ・バッファ１２４からストリーミング情報を読み取る。ライタ・モジュール１２２は、同期情報をインデックス１３２に格納する。リーダー・モジュール１２６は、ストリーミング情報のうちの特定の部分の位置を見つけそしてこのストリーミング情報を適切にレンダリングするためにインデックス１３２にアクセスすることができる。ライタ・モジュール１２２、サーキュラ・バッファ１２４、リーダー・モジュール１２６およびインデックス１３２の動作は、以下で詳細に説明する。
【００２６】
図示した実施形態では、２つの別々のプレイバック・リーダー・モジュール１２６１、１２６２は、ストリーミング情報を別々のビデオ、オーディオおよびデータのデコーダ１２０とレンダリング・デバイス１１６に供給する出力を有するものとして図示している。一般に、これは、別々のリーダー・モジュール１２６が、サーキュラ・バッファ１２４から、このサーキュラ・バッファ１２４内の異なったポイントにてストリーミング情報を読み取ることができることを示しており、したがって、別々の個人がそれに格納されたデータをアクセスしていることを表している。加えて、他のリーダー・モジュール１２６（例えば１３６で示したもの）を実装することができ、これにより、後でのビューイングのため、サーキュラ・バッファ１２４内のストリーミング情報を保管し格納することができる。一般に、アーカイブ・システム１３６においては、リーダー・モジュール１２６３は、ストリーミング情報をｍｕｘフォーマッタ１３８に供給し、そしてこれは次に、その情報を、ハード・ディスク２７のような上述の記憶デバイスの任意のものへの格納のためにライタ・モジュール１４０に供給する。
【００２７】
サーキュラ・バッファ
再度サーキュラ・バッファについて言及するが、サーキュラ・バッファ１２４は「浮動小数点」始点および終点を有し、これらを論理「ヘッド」１５０および「テール」１５２と呼ぶ。ヘッド１５０は、サーキュラ・バッファ１２４内における有効データの論理ヘッドに対応し、テール１５２はサーキュラ・バッファ１２４内における有効データの論理テールに対応する。ライタ・モジュール１２２は常にバッファ１２４の先頭に書き込みを行なうが、矢印１５４の方向にバッファ全体にわたり巡回して移動する。したがって、バッファ１２４は記録可能なデータに対し、常に最大固定時間割当を有することになる。例えば、時間シフティング・マルチメディア（例えば、オーディオおよびビデオ）コンテンツの場合、ライタ・モジュール１２２は、ストリーミング・マルチメディア情報を受け取り、この情報をサーキュラ・バッファ１２４に格納する。ユーザは、格納したマルチメディア・コンテンツを、リーダー・モジュール１２６の１つを通じて見る。バッファ１２４のサーキュラ構造によって、ストリーミング情報の一部を、ユーザが、例えば、バッファに「時間シフティング」データで「満杯」にさせることなく、要求に応じて「直ちにリプレイ」したり、あるいは「一時停止」することが可能となる。サーキュラ・バッファ１２４は、ランダム・アクセス・メモリ（ＲＡＭ）、ハード・ディスク、フロッピ・ディスク、または光ディスクのような揮発性または不揮発性メモリ内に実現することができる。一実施形態では、サーキュラ・バッファ１２４は、ハード・ディスク・ドライブ２７内に実現する。
【００２８】
図７は、サーキュラ・バッファ１２４に対するインターフェースを示す、ディレイ・フィルタ１１２のブロック図である。バッファＩＯレイヤ２００が、サーキュラ・バッファ１２４とバッファのクライアントとの間のインターフェースとなる。クライアントは、ライタ・モジュール１２２およびリーダー・モジュール１２６を含む（１２６₁〜１２６_Nで示す。ここで、Ｎは１以上の整数変数である）。バッファＩＯレイヤ２００は、バッファ１２４の巡回性を実現し、ライタ・モジュール１２２をリーダー・モジュール１２６₁〜１２６_Nと同期させる。バッファＩＯレイヤ２００は、巡回性を実現する際、上位インターフェース２０４〜１０７においてバッファ１２４内部の論理位置を識別するために用いられる論理アドレスと、下位インターフェース２０８において用いられバッファ１２４内部の特定の物理アドレスを識別するための物理（ラップ・アラウンド）アドレスとの間で変換を行なう。論理アドレスは、常に、時間と共に増大（または減少）し、周回する(wrap around)することはない。論理アドレスは、必要性に応じて、周期的にリセットすることができる。物理アドレスは、サーキュラ・バッファのサイズによって決定される頻度で周回する（即ち、バッファの最上位アドレスからバッファの最下位アドレスに移る）。ストリーミング情報の連続する各ブロックがライタ・モジュール１２２によって受け取られる毎に、ブロックをそれぞれの論理アドレスまたは論理アドレス範囲と関連付ける。アドレスは、連続する各ブロック毎に増加する。バッファＩＯレイヤ２００は、論理アドレスを対応する物理アドレスに変換し、サーキュラ・バッファ１２４にアクセスするために用いる。一実施形態では、バッファＩＯレイヤ２００は、論理アドレスのバッファ・サイズ（即ち、サーキュラ・バッファ１２４内の記憶ロケーションの数）に対するモジュロの関数として、論理アドレスを物理アドレスに変換する。バッファ・レイヤＩＯ２００は、例えば、オペレーティング・システム内に実現することができる。
【００２９】
ライト／リードの同期
ライタ・モジュール１２２およびリーダー・モジュール１２６₁〜１２６_Nは互いに独立して、しかも異なるデータ・レートで動作することができるので、バッファＩＯレイヤはライタ・モジュール１２２およびリーダー・モジュール１２６₁〜１２６_Nの同期を取り、ライトおよびリード間に所定の時間的順序を維持する。一実施形態では、バッファＩＯレイヤ２００は、いずれのリーダー１２６₁〜１２６_Nであっても、未だ論理的に使用可能ではないデータを読み取ることを禁止し、更にライタ・モジュール１２２が、１つ以上のリーダー・モジュール１２６₁〜１２６_Nによって読み取られている途中のデータに上書きすることを禁止する。サーキュラ・バッファ１２４では、所与の物理位置が多数の論理位置に対応する。同期を取らないと、バッファ・サイズに近い距離だけ離れた後続のライタ・モジュール１２２であるリーダー・モジュールが、ライタ・モジュール１２２が書き込んでいる同じ物理エリアから読み出すという可能性がある。また、バッファＩＯレイヤ２００は、リーダー・モジュール１２６₁〜１２６_Nができるだけ密接にライタ・モジュール１２２に従い、レイテンシを極力抑えることができるようにする。
【００３０】
バッファＩＯレイヤ２００は、ライタ・モジュール１２２およびリーダー・モジュール１２６₁〜１２６_Nに対して同期アルゴリズムを実装する。ライタ・モジュール１２２がデータをバッファＩＯレイヤ２００に渡そうとする毎に、その対応するアプリケーションが同期アルゴリズムをコールする。同様に、リーダー・モジュール１２６₁〜１２６_Nの１つがバッファＩＯレイヤ２００からデータを読み出そうとする毎に、その対応するアプリケーションが同期アルゴリズムをコールする。同期アルゴリズムは、要望に応じて、ハードウエア、ソフトウエア、または双方の組み合わせで実現することができる。
【００３１】
同期アルゴリズムは、「ブロッキング」を用いて、（１）書き込みが未だ行われていないデータを読み取ろうとしているリーダー・モジュール１２６₁〜１２６_Nを阻止する。および／または（２）ライタ・モジュール１２２が、リーダー・モジュール１２６₁〜１２６_Nの内１つが現在読み取っているサーキュラ・バッファ１２４のエリアに書き込みを行なおうとしている場合、これを阻止する。双方の場合、一方のコンポーネントを阻止するのは、他方のコンポーネントが違反条件(offending condition)を除去するために必要な動作を完了してしまうまでである。例えば、ライタ・モジュール１２２を阻止する場合、書き込もうとしているエリアから読み取りを行なっているリーダー・モジュール１２６₁〜１２６_N全てがその読み取りを完了するまで、阻止し続ける。リーダー・モジュールを阻止する場合、ライタ・モジュール１２２が、当該リーダー・モジュールによって要求されたデータの全てを書き込み終えるまで、これを阻止し続ける。
【００３２】
同期アルゴリズムは、複数の共有変数を用いる。各クライアントは、それ自体１組の変数を有し、これらを他のクライアントと共有する。図８では、サーキュラ・バッファ１２４は０から無限大まで直線状の時間ラインに沿って配列されている。同期アルゴリズムは、サーキュラ・バッファ１２４内における有効データの論理的終端を示す整数変数である、「テール・ポインタ２３０」を維持している。「ヘッド・ポインタ２３２」は、サーキュラ・バッファ１２４内における有効データの論理的先頭を示す整数変数である。リード動作を連続するためには、サーキュラ・バッファ１２４内における論理的な読み取り位置は、テール・ポインタ２３０以上であり、しかもヘッド・ポインタ２３２以下でなければならない。バッファ１２４はサーキュラであるので、テール・ポインタ２３０の論理的位置は、ヘッド・ポインタ２３２の論理的位置よりも論理的に「手前」でもある。
【００３３】
ライタ・モジュール１２２がライト・コマンドを発行すると、これは、現在の書き込み位置２３４から開始する、バッファ１２４内における書き込むエリアを指定する。「ライタ・ブロック・オン」(Writer Blocked On)整数変数２３６は、書き込むべきエリアの全てまたは一部が１つ以上のリーダー・モジュール１２６₁〜１２６_Nによって閉鎖 (blocked)される場合に、書き込むべきデータの後端に対応する論理的位置を特定するために用いる。ライタ・ブロック・オン変数は、リーダー・モジュール１２６₁〜１２６_Nの１つが現在当該エリアから読み出しを行なっている場合にセットする。例えば、あるリーダー・モジュールが現在、位置２３４および２３６の間にあるエリアである論理位置２３５から読み出しを行なっている場合もある。「ライタ・ブロック・オン」変数の値が「０」の場合、ライタ・モジュール１２２は、リーダー・モジュール１２６₁〜１２６_Nのいずれにも現在阻止されていないことを示す。
【００３４】
「現読み取り位置」(Currently Reading From)整数変数を、各リーダー・モジュール１２６₁〜１２６_N毎に維持する。現読み取り位置変数は、リーダー・モジュールが、サーキュラ・バッファ１２４のこの論理位置から開始して、読み取りを現在行なっていることを示すために用いる。例えば、図８において、リーダー・モジュールは、現在サーキュラ・バッファ１２４内の論理位置２３５から現在読み取りを行なっている。現読み取り位置変数は、リーダー・モジュールが論理位置２３５から読み取りを行なっている間、論理位置２３５におけるデータを上書きするのを防止するために用いる。特定のリーダー・モジュール１２６₁〜１２６_Nが現在サーキュラ・バッファ１２４から読み取りを行なっていない場合、それに対応する現読み取り位置変数を無限大にセットする。
【００３５】
「ライタ・ブロック解除イベント」(Writer Unblocked Event)変数は、ライタ・モジュール１２２がその所望のライト・コマンドを実行できるときに、このライタ・モジュールを「起動」(wake up)するために用いる。例えば、ライタ・ブロック解除変数は、ライタ・モジュール１２２が阻止されていないときにアクティブ状態にセットされ、ライタ・モジュール１２２が阻止されるとインアクティブ状態にリセットされる。ライタ・ブロック解除イベントは、Windows（登録商標）イベント（「Win32」イベント）、または当業者にはなじみのあるその他のあらゆる同期機構として実現することができる。
【００３６】
「リーダー・ブロック解除イベント」変数は、各リーダー・モジュール１２６₁〜１２６_Nが要求しているデータが使用可能であるときに、当該リーダー・モジュールを「起動」するために、各リーダー・モジュール毎に用いられる。例えば、リーダー・ブロック解除イベント変数は、対応するリーダー・モジュール１２６₁〜１２６_Nが阻止されていないときにアクティブにセットされ、対応するリーダー・モジュール１２６₁〜１２６_Nが阻止されるとインアクティブにリセットされる。
【００３７】
「クリティカル・セクション」(Critical Section)変数は、前述の共有変数の各々に対するアクセスを禁止するために用いる。例えば、「Win32」クリティカル・セクションを用いることができ、あるいは、当業者には公知の相互排除「mutex」オブジェクトのような他の同様の同期機構であればいずれでも用いることができる。
【００３８】
図９Ａ、図９Ｂ、図１１Ａおよび図１１Ｂは、併せて、本発明の一例による同期アルゴリズムのフローチャートを形成する。ライト中に実行するステップを図９Ａに示し、３００〜３１７と付番する。ステップ３００において、ライタ・モジュール１２２を駆動するアプリケーションがデータをバッファＩＯレイヤ２００に渡したい場合、アプリケーションはアルゴリズム２９０をコールする。ステップ３０１において、アルゴリズム２９０はクリティカル・セクションをロックし、ステップ３０２〜３０５において用いられる変数に対するアクセスを禁止する。ステップ３０２において、アルゴリズム２９０は、ライト・コマンドの後端に対応するサーキュラ・バッファ１２４内の論理位置に、「テール・ポインタ」を進める。この論理位置は、ライタ・モジュール１２２が書き込んでいるデータ量に応じて異なる。データの長さは、ライト・コマンドまたはデータ・ブロック毎に異なり、データは任意のデータ・フォーマットを有することができ、これもライト・コマンドまたはデータ・ブロック毎に変更することができる。
【００３９】
図１０は、サーキュラ・バッファ１２４内におけるテール・ポインタの前進を示す図である。テール・ポイント２５０は、論理位置２６０から倫理位置２６２に進められる。テール・ポインタ２５０を進めると、ライタ・モジュール１２２が実際にデータの書き込みを開始できるようになるまで待たなければならなくても、今後のリードのために、（進められたテール・ポインタ２５０の後ろの）書き込むべきエリアを直ちに無効化する。その結果、一旦ライタ・モジュール１２２が、ライタ・アルゴリズムをコールすることによって、サーキュラ・バッファ１２４内のあるエリアに書き込みを行ないたいことをバッファＩＯレイヤ２００に通知すると、新たなリーダー・モジュールはそのエリアから読み取りを開始することができない。これによって、ライタ・モジュール１２２がリーダー・モジュール１２６₁〜１２６_Nを待たなければならない時間を極力抑え、ライタが永続的に阻止されるのを防止する。
【００４０】
図９Ａに戻って、同期アルゴリズム２９０は、ステップ３０３において、リーダー１２６₁〜１２６_Nの「現在読み取り位置」変数のいずれかが「テール・ポインタ」変数よりも小さい（即ち、それよりも後ろ）か否か判定を行なう。例えば、図１０において、リーダー・モジュールが、進められたテール・ポインタ２５０の論理位置２６２未満であるサーキュラ・バッファ１２４内の論理位置２７２を指し示す現読み取り位置変数２７０を有する場合がある。この場合、同期アルゴリズム２９０は、ライタ・モジュール１２２を阻止するかまたは遅延させ、競合するリーダー・モジュールが「邪魔にならないように」ようにする。リーダー・モジュールの「現読み取り位置」変数のいずれもが、進んだテール・ポインタ変数未満でない場合、同期アルゴリズム２９０は直接ステップ３１１（図９Ｂに示す）に進み、データをサーキュラ・バッファ１２４に書き込む。
【００４１】
ステップ３０４において、アルゴリズム２９０は「ライタ・ブロック・オン」変数を「テール・ポインタ」変数２５０の値にセットする。これは、ライタ・モジュール１２２がデータを書き込めるようになる前に、リーダー・モジュール１２６₁〜１２６_Nをクリアしなければならない、サーキュラ・バッファ１２４内における最も大きな論理位置を示す。次に、ステップ３０５において、アルゴリズム２９０は、「ライタ・ブロック解除」イベントをインアクティブ状態にリセットすることによって、ライタ・モジュール１２２を阻止する。ライタ・モジュール１２２を阻止したので、ステップ３０６においてクリティカル・セクションのロックを解除する。ステップ３０７において、アルゴリズム２９０は、書き込むべきエリアにアクセスしている競合リーダーの同期アルゴリズムが、「ライタ・ブロック解除」イベント変数を活性化するのを待つ。競合リーダー・モジュールが「ライタ・ブロック解除」イベントを活性化したなら、アルゴリズム２９０はステップ３０８においてクリティカル・セクションをロックし、次いでステップ３０９において「ライタ・ブロック・オン」変数を０にリセットする。アルゴリズム２９０は、再度ステップ３１０においてクリティカル・セクションのロックを解除し、ステップ３１１（図９Ｂに示す）に進む。
【００４２】
ステップ３１１において、バッファＩＯレイヤ２００は、先頭論理アドレスをサーキュラ即ち物理アドレスに変換し、その物理アドレスから開始して、データをサーキュラ・バッファ１２４に書き込む。一旦データを書き込んだなら、アルゴリズム２９０は、ステップ３１３〜３１５において用いる変数のためにクリティカル・セクションをロックし、ライタ・モジュール１２２が書き込んだデータの後端に対応する、サーキュラ・バッファ１２４内の論理位置に、「ヘッド・ポインタ」変数を進ませる。図１０に示す例では、ヘッダ・ポインタ２７４は、位置２７６から位置２７８（進められたテール・ポインタ２５０よりも「後ろ」であると見ることもできる）に進められる。ヘッド・ポインタ２７４を進めると、ヘッド・ポインタ２７４およびテール・ポインタ２５０間にある、新たに書き込まれたデータが有効となる。
【００４３】
ステップ３１４において、アルゴリズム２９０は、リーダー・モジュール１２６₁〜１２６_Nの「リーダー・ブロック・オン」変数のいずれかが、進められた「ヘッド・ポインタ」変数２７４未満であるか否か判定を行なう。いずれも未満ではない場合、ライタ・モジュール１２２が書き込んだデータを待っていたリーダー・モジュール１２６₁〜１２６_Nはなかったことになり、アルゴリズム２９０はステップ２１６に進む。いずれかが未満であった場合、１つ以上のリーダー・モジュール１２６₁〜１２６_Nがライタ・モジュール１２２を待っていたことになる。ライタ・モジュール１２２は今では所望の論理位置を有効化してある。アルゴリズム２９０は、ステップ３１５において、このような「リーダー・ブロック解除」イベント変数のいずれかをセットし、対応するリーダー・モジュールのロックを解除する。
【００４４】
図１０に示す例では、ヘッド・ポインタ２７４が論理位置２７６を指し示していたときに、既に使用可能ではない論理位置２８０において、あるリーダー・モジュールがデータを読み取るために待っているという場合があり得る。この場合、当該リーダー・モジュールは、矢印２８８で示すように、論理位置２８０を指し示す「リーダー・ブロック・オン」変数を有していたであろう。今や「ヘッド・ポインタ」変数２７４は、論理位置２８０よりも進んでいる、論理位置２７８を指し示しているので、位置２８０におけるデータを読み取ることができ、アルゴリズム２９０は、当該リーダー・モジュールの「リーダー・ブロック解除」イベント変数をアクティブ状態にセットすることによって、このリーダー・モジュールのブロックを解除する。
【００４５】
図９Ｂに戻るが、ステップ３１６において対応するクリティカル・セクションのロックを解除し、ステップ３１７においてアルゴリズムが終了する。
図１１Ａおよび図１１Ｂは、併せて、同期アルゴリズム２９０のリード部分を示し、ステップ３５１〜３７２を含む。リーダー・モジュール１２６₁〜１２６_Nの１つがサーキュラ・バッファ１２４からデータを読み取りたい場合、ステップ３５１において、当該リーダー・モジュールは、バッファＩＯレイヤ２００内のアルゴリズム２９０をコールする。ステップ３５２において、アルゴリズム２９０はクリティカル・セクションをロックし、ステップ３５３〜３５５において用いる変数を保護する。ステップ３５３において、アルゴリズム２９０は、読み取るべきデータ量が、「ヘッド・ポインタ」の論理位置を超えるサーキュラ・バッファ１２４内の論理位置に及び、所望のデータの一部が未だ有効でないか否か判定を行なう。そうでない場合、アルゴリズム２９０は直接ステップ３６０に進む。
【００４６】
図１２は、要求データがヘッド・ポインタを超えて延びる場合のサーキュラ・バッファ１２４の一例を示す図である。サーキュラ・バッファ１２４は、論理位置３３２にテール・ポインタ３３０を有し、論理位置３３６にヘッド・ポインタ３３４を有する。リーダー・モジュールが、論理位置３３７から開始し、ヘッド・ポインタ３３４の論理位置３３６を超える論理位置３３８にまで及ぶデータを要求する場合、矢印３４０で示すように、アルゴリズム３５０はこのリーダー・モジュールの「リーダー・ブロック・オン」変数を、要求したリード・データの後端に対応する論理位置（例えば、論理位置３３８）にセットする。図１１Ａに戻り、アルゴリズム３５０は、ステップ３５５において、「リーダー・ブロック解除」イベント変数をリセットし、対応するリーダー・モジュールを阻止する。リーダー・モジュールを阻止したので、アルゴリズム３５０はステップ３５６において対応するクリティカル・セクションのロックを解除する。ステップ３５７において、アルゴリズム３５０は、このリーダーに対して「リーダー・ブロック解除」変数がセットされるのを待つ（図９Ｂにおけるステップ３１５）。一旦「リーダー・ブロック解除」変数をセットしたなら、ステップ３５８において対応するリーダー・モジュールのブロックが解除され、クリティカル・セクションがロックされる。次に、ステップ３５９において、このリーダーに対する「リーダー・ブロック・オン」変数を無限大にリセットし、アルゴリズム３５０はステップ３６０に進む。
【００４７】
ステップ３６０において、アルゴリズム３５０は、要求データの先頭に対応する論理位置が、「テール・ポインタ」変数の論理位置の前にあるか否か判定を行なう。前にある場合、要求データは無効となる。何故なら、これは既にライタ・モジュール１２２によって上書きされているからである。この場合、アルゴリズム３５０はステップ３６１においてクリティカル・セクションのロックを解除し、ステップ３６２において要求されたリード動作を断念する。ステータス変数のような種々の機構を通じて、この断念を対応するリーダー・モジュールに伝えることができる。
【００４８】
要求データが「テール・ポインタ」変数よりも前でない論理位置において開始する場合、アルゴリズム３５０はステップ３６３（図１１Ｂに示す）に進む。ステップ３６３において、アルゴリズム３５０は、当該リーダーの「現読み取り位置」変数を、要求データの先頭である論理位置にセットする。ステップ３６４において、クリティカル・セクションのロックを解除し、先頭論理アドレスを、サーキュラ・バッファ１２４のサーキュラ即ち物理アドレス（図７に示す）に変換する。ステップ３６５において、バッファＩＯレイヤ２００は、変換した論理アドレスから始まる、要求された量のデータを読み取り、ステップ３６５においてこのデータを対応するリーダー・モジュールに供給する。ステップ３６６において、アルゴリズム３５０はクリティカル・セクションをロックする。ステップ３６７において、リード動作が終了したので、リーダーに対する「現読み取り位置」変数を無限大にリセットする。
【００４９】
ステップ３６８において、アルゴリズム３５０は、「ライタ・ブロック・オン」変数が、読み取り位置よりも大きい、サーキュラ・バッファ１２４内の論理位置を指し示しているか否か判定を行なう。読み取り位置は、読み取るべきデータの先頭に対応するサーキュラ・バッファ１２４内の論理位置である。「ライタ・ブロック・オン」変数がこの論理位置よりも大きくない場合、このリーダー・モジュールは、ライタ・モジュール１２２を阻止していたのではないことになる。次いで、アルゴリズム３５０はステップ３６９においてクリティカル・セクションのロックを解除し、ステップ３７０においてその機能を終了する。
【００５０】
「ライタ・ブロック・オン」変数がこの位置よりも大きい場合、このリーダー・モジュールはライタ・モジュール１２２を阻止していたことになり、アルゴリズム３５０はステップ３７１に進み、他にもいずれかのリーダー・モジュールがライタ・モジュール１２２を阻止しているか否か判定を行なう。阻止していない場合、アルゴリズム３５０はステップ３７２において「ライタ・ブロック解除」イベント変数をセットし、ライタ・モジュール１２２のブロックを解除する。ライタ・モジュール１２２を阻止しているリーダー・モジュールが他にもある場合、アルゴリズム３５０は、「ライタ・ブロック解除」イベント変数をセットすることなく、ステップ３６９に進む。
【００５１】
図９および図１１に示すアルゴリズムは、代替実施形態では、種々の方法で変更することができる。例えば、ライタ・ブロック１２２を阻止することが望ましくない場合もある。ライタ・モジュール１２２をテレビジョン・チューナに結合した場合のように、ライタ・モジュール１２２がかなりの時間遅れた場合にライタ・モジュール１２２に供給するストリーミング情報が失われるとすると、ライタ・モジュール１２２を遅延させないことが望ましい。これらの実施形態では、図９Ａおよび図９Ｂのアルゴリズム２９０を変更し、ライタ・モジュール１２２を遅らせるように機能するステップ３０３〜３１０を削除する。アルゴリズム２９０はステップ３０２から直接ステップ３１１に進む。同様に、図１１Ａおよび図１１Ｂのアルゴリズム２９０を変更して、選択的にライタ・モジュール１２２のブロックを解除するように機能するステップ３６６〜３６９、３７１および３７２を削除する。
【００５２】
加えて、アルゴリズム２９０は、ステップ３６５でリードを実行する前または後、あるいは双方において、ステップ３６０〜３６２（リード動作の有効性を判断する）を実行するように変更することもできる。実際のリード動作の前にリード動作の有効性を判断することによって、無駄なリードを回避する。しかしながら、望ましければ、ステップ３６６の後にステップ３６０〜３６２を実行することもできる。また、ステップ３６０〜３６５は、ステップ３６５の前および後双方に実行することもできる。
【００５３】
図９および図１１に示す同期アルゴリズムは、図６に示したようなサーキュラ・バッファを必要としない。また、同期アルゴリズムは、僅かな変更で、バッファのサイズに基づいた頻度で周回する論理アドレスおよび物理アドレス双方を有する直線状バッファにおいて用いることも可能である。しかしながら、サーキュラ・バッファでは、リーダー・モジュールをライタ・モジュールに対して時間的にシフトし、要求に応じた「瞬時リプレイ」のためにストリーミング情報の一部をユーザが利用できるようにすることが可能となる。サーキュラ・バッファは、ユーザがプログラムを一時停止することを許可するが、ユーザが不用意に時間シフティング・データでバッファを満杯にすることは許可しない。ライタ・モジュールは常にバッファの「先頭」に書き込んでおり、これは、バッファ全体を巡回して移動するポイントである。
【００５４】
また、図９および図１１に示す同期アルゴリズムは、バッファ内に格納されているデータをユーザが早送りすることも可能にする。ユーザがリーダー・モジュールを一時停止したためにライタ・モジュールが当該リーダーよりも遥か先にある場合、ユーザまたはアプリケーションは、リーダー・モジュールを早送りして、ライタ・モジュールに追い付くようにする選択肢を有する。しかしながら、同期アルゴリズムは、リーダー・モジュールがライタ・モジュールに追い付いたときに早送りを停止する。例えば、リーダー・モジュールがライタ・モジュールによって阻止されているときはいつでも、リーダー・モジュールは「DirectShow」イベント（またはソフトウエア環境で使用可能なその他の適切なイベント機構）を開始することができる。アプリケーションはこのイベントを検出し、リーダー・モジュールの状態を早送りから通常プレイ・モードに切り替える。ライタ・モジュールがリーダー・モジュールに追い付いた場合、データが使用可能になるまでリーダーを阻止する、（２）リーダーが邪魔にならなくなるまでライタを阻止する、または（３）リーダーを一時停止しないかあるいは早送りしてリーダーを先に進ませることによって、ライタ・モジュールによる衝突を回避することができる。
【００５５】
ユーザ動作許可チェック
一実施形態では、ディレイ・フィルタ１１２（図６に示す）は、更に、フィルタにおいて一貫した動作状態を維持する、ユーザ動作許可チェックおよび報告機構も含む。図１３は、ディレイ・フィルタ１１２によって、各データ・ストリームまたはチャネル毎に、このフィルタが維持するステータス・レジスタ４２０を示す図である。ディレイ・フィルタ１１２は、例えば、ＲＡＭまたはその他のあらゆる記憶媒体にレジスタ４２０を維持することができる。ステータス・レジスタ４２０は、複数のフィールドを含み、各フィールドは１つ以上のビットを有する。図１３に示す例では、ステータス・レジスタ４２０のビット０〜１０は、それぞれ、ユーザ動作フィールドＵＯＰ０〜ＵＯＰ１０に対応する。ビット１１〜２７は、予約フィールドに対応する。ビット２８〜３１は、ステータス・レジスタ４２０と関連のあるライタ・モジュール１２２およびリーダー・モジュール１２６₁〜１２６_Nによって、特定のデータ・ストリームを識別するチャネル・ストリーマＩＤフィールドに対応する。各ユーザ動作フィールドＵＯＰ０〜ＵＯＰ１０は、対応するユーザ動作が許可されているかまたは禁止されているかを示す二進値を有する。例えば、対応するフィールドにおける二進値が「１」の場合、ユーザ動作が許可されていることを示す。ユーザ動作フィールドにおける二進値が「０」の場合、当該ユーザ動作が禁止されていることを示す。図１４は、ユーザ動作フィールドＵＯＰ０〜ＵＯＰ１０に対応するユーザ動作の例を列挙したテーブルである。ディレイ・フィルタ１１２は、そのリーダー・モジュールの状態に基づいて、各ストリームまたはチャネル毎にＵＯＰフィールドを維持する。ディレイ・フィルタ１１２は、リーダー・モジュールの状態が変化したときはいつでも、ユーザ動作ビットを更新する。
【００５６】
ユーザ動作によっては、ディレイ・フィルタがある状態にある場合にのみ、許可されるものもある。禁止した動作を用いると、ディレイ・フィルタおよびユーザ・インターフェースにおける動作に矛盾が生ずる場合がある。例えば、サーキュラ・バッファ１２４におけるポイントＸにおいて、マルチメディア・コンテンツの「時間シフティング」を実行しているリーダー・モジュールを一時停止したと仮定する。その間、ライタ・モジュール１２２はサーキュラ・バッファ１２４にデータをなおも書き込んでいる。サーキュラ・バッファ１２４のサイズ、およびリーダー・モジュールを一時停止した時間によっては、リーダー・モジュールを一時停止したポイントＸにライタ・モジュール１２２が追い付いてしい、データを上書きしようとする可能性がある。この場合、ディレイ・フィルタ１１２は強制的にリーダー・モジュールの「一時停止を解除」し、一時停止していたリーダー・モジュールを解除したことの通知をアプリケーションに送る。リーダーの「一時停止を解除」する時刻と、アプリケーションが通知を受け取る時刻との間には、小さな時間枠がある。この時間枠の間に、アプリケーションは、順方向スキャンのような、禁止されているユーザ・コマンドを発行する可能性がある。ここで、リーダー・モジュールは、リーダー・モジュールの一時停止を解除したことの通知をアプリケーションが受け取った時点において、順方向スキャンを実行し、通常速度でプレイしている。したがって、アプリケーションおよびディレイ・フィルタ１１２は矛盾した状態となる。
【００５７】
この問題を回避するために、ディレイ・フィルタ１１２は、ユーザ動作を発行した場合にはいつでも、アプリケーションがユーザ動作ビットをチェックし、その動作の有効性をチェックすることができるようにしている。また、ユーザ動作ビットが変化したときはいつでも、ディレイ・フィルタ１１２はこの変化をアプリケーションに報告する。したがって、アプリケーションはそのユーザ・インターフェースを更新し、無効のユーザ動作がディレイ・フィルタ１１２に発行されていないことを確認することができる。
【００５８】
図１５は、例えば、ユーザが動作を要求したときまたはユーザ動作ステータス・ビットが変化したときにはいつでも、アプリケーション・プログラム・インターフェース（「ＡＰＩ」）を通じてアプリケーションがコールすることができるソフトウエア・モジュールまたはオブジェクトのフローチャートである。ステップ４３０において、アプリケーションは、ユーザが動作を要求するのを待つ。一旦ユーザ動作が要求されたなら、ステップ４３１において、アプリケーションは対応するユーザ動作のステータスをチェックする。ステップ４３２において、動作が許可された場合、ステップ４３３において、アプリケーションは要求された動作をディレイ・フィルタ１１２に発行する。要求された動作が禁止された場合、ステップ４３４においてこの動作を拒絶する。
【００５９】
図１６は、ディレイ・フィルタ１１２が各ステータス・レジスタ毎にユーザ動作ビットを維持する際に実行するステップを示すフローチャートである。ステップ４４０において、ディレイ・フィルタは、リーダー・モジュールの１つの状態変化を検出する。ステップ４４１において、対応するストリームまたはチャネルに対するステータス・レジスタのユーザ動作ビットを、状態変化の関数として更新する。次に、ステップ４４２において、ディレイ・フィルタ１１２は、例えば、当該ストリームまたはチャネルのＡＰＩを通じて、状態変化についてアプリケーションに通知する。次に、アプリケーションはユーザ・インターフェースを更新し、図１４に列挙したユーザ動作から選択したサブセットをディスエーブルまたはイネーブルすることができる。ユーザ・インターフェースの更新は、例えば、光インディケータのセットまたはリセット、可聴警報の発生、または画面表示の変更を含むことができる。アプリケーションは、特定のストリームまたはチャネルに対するユーザ動作ビットについてディレイ・フィルタ１１２に問い合わせることによって、ユーザ・インターフェースを更新すべきか否か判定を行なうことができる。
【００６０】
時間シフティング
例示の実施形態によって示す別の広義な発明の態様は、ストリーミング情報をレンダリングするときの「時間シフティング(time shifting)」の概念を含む。一般に、ストリーミング情報を受ける情報機器(information appliance)は、バッファ（一実施形態ではサーキュラ・バッファ１２４）、ストリーミング情報のブロックを受け取りブロックをバッファに書き込むライタ・モジュール、および選択的にブロックをバッファから読み出す少なくとも１つのリーダー・モジュール１２６を含ませることによって、を実現する。
【００６１】
全ての信号処理機器は生来的に信号伝搬遅延を含むが、ここで用いる場合の「」は、以下に論ずる理由のために、単独でもまたはあらゆる組み合わせでも区別が可能である。第１の例では、量（即ち、サーキュラ・バッファ１２４におけるいずれか１つのリーダー・モジュール１２６のライタ・モジュール１２２に対する相対的な位置）は選択的であり、しかも調節可能である。第１動作モードでは、ユーザは、あらゆる所望の順序で、「巻き戻し」、「一時停止」、「早送り」、および「プレイ」を実行することによって、サーキュラ・バッファ１２４内におけるライタ・モジュール１２２の位置に対する関連のリーダー・モジュール１２６の相対的読み出し位置を変更することができる。したがって、ライタ・モジュール１２２が書き込んだストリーミング情報から、レンダリングしたストリーミング情報（リーダー・モジュール１２６によって開始する）を時間的に遅らせる。
【００６２】
別の動作モードでは、システムの動作に基づいて、ユーザの介入なしに、「」量を調節するロジックを設ける。例えば、ユーザがリーダー・モジュールを「一時停止」してサーキュラ・バッファ１２４内におけるリーダー・モジュール１２６の現位置を維持する場合、リーダー位置を進ませ始め、ライタ・モジュール１２２が新たなストリーミング情報をサーキュラ・バッファ１２４に格納できるようにすることが必要となる場合もある。この状況では、ストリーミング情報をサーキュラ・バッファ１２４に書き込んでいるレートよりも高いか少なくとも等しいレートで、リーダー・モジュール１２６がサーキュラ・バッファ内において順方向に移動開始する必要がある。
【００６３】
また、サーキュラ・バッファ１２４内におけるリーダー・モジュール１２６の位置の自動調整も、「プレイ」、「一時停止」、「巻き戻し」、および「早送り」のような、リーダー・モジュール１２２の位置の移動とは直接関連のないユーザ・コマンドによって開始することができる。恐らく一例を通じて最良に示されようが、ディレイ・フィルタ１１２へのストリーミング情報１１４のソースは、テレビジョン・チューナのような、多放送チャネル・デバイスとすることができる。ユーザが選択した放送チャネルにしたがって情報をレンダリングし始め、一時停止し、再度同じ放送チャネル上で情報のレンダリングを再開した場合、リーダー・モジュール１２６の関連する位置は、それに応じて変化し、サーキュラ・バッファ１２４におけるリーダー・モジュール１２６およびライタ・モジュール１２２の位置との相対的な距離が増大する。次に、ユーザが異なる放送チャネル、例えば、異なるテレビジョン・チャネルを選択してレンダリングする場合、ライタ・モジュール１２２は、サーキュラ・バッファ１２４内に新たな放送チャネルに関連するストリーミング情報を記録する。しかしながら、リーダー・モジュール１２６の位置は、ユーザが一時停止した時間量に比例する遅延だけ、ライタ・モジュール１２２の位置から「時間的にずれて」いるので、リーダー・モジュール１２６が、放送チャネルの変更によって与えられたサーキュラ・バッファ１２４内の新たなストリーミング情報に到達するまで、ユーザは新たな放送チャネルの選択を知らせないことになる。前述のことによって生ずる問題を未然に防ぐために、リーダー・モジュール１２６の位置を、ライタ・モジュール１２２の位置に隣接するサーキュラ・バッファ１２４内の位置に自動的に進める。この技法により遅延量が減少するので、多放送チャネル環境において、ストリーミング情報のレンダリングは、実質的に放送チャネルの選択に追従することになる。
【００６４】
ここで用いる「時間シフティング」と典型的な信号伝搬遅延との間における別の差別的特徴は、ストリーミング情報を記録するために用いる媒体にある。即ち、先に論じたように、サーキュラ・バッファ１２４は、ＲＡＭメモリ、ハード・ディスク２７等のような、前述の記憶装置のいずれを用いても具体化可能である。加えて、サーキュラ・バッファ１２４内に入るメモリ量は、望ましければ、ユーザに知覚可能な遅延を与えるのにも十分である。一実施形態では、サーキュラ・バッファ１２４の広さ(extent)は、ストリーミング情報の書き込みおよびレンダリングの間に少なくとも５分の遅延を設ける。別の実施形態では、サーキュラ・バッファ１２４の広さは、ストリーミング情報の書き込みおよびレンダリングの間に少なくとも３０分の遅延を設けるのに十分である。更に別の実施形態では、サーキュラ・バッファ１２４の広さは、少なくとも１時間の遅延を設けるのに十分である。
【００６５】
ここで用いる「時間シフティング」の更に別の差別的な特徴は、単一のライタ・モジュール１２２および複数の独立したリーダー・モジュール１２６₁〜１２６_Nの存在を含む。
【００６６】
一実施形態では、ストリーミング・ソース１１４から受け取ったあらゆる情報は、ストリーミング情報をユーザにレンダリングする前に、最初にサーキュラ・バッファ１２４に記録する。言い換えると、ユーザにレンダリングする情報は全て、関連するリーダー・モジュール１２６によって、サーキュラ・バッファ１２４から読み取られる。この場合、ストリーミング・ソース１１４からレンダリング・デバイス１１６への直接的な接続は存在しない。ストリーミング情報をレンダリングする前に記録しサーキュラ・バッファ１２４から読み出すが、サーキュラ・バッファ１２４内のリーダー・モジュール１２６の位置が、ライタ・モジュール１２２の位置にほぼ隣接しているときは、伝搬遅延が僅かに増大するだけで済み、常にサーキュラ・バッファ１２４に書き込みそしてここから読み出すことの利点は、システム設計および動作の簡略化を含み、これによってシステムの安定性が高まる。システム内には、実質的に「生の」ストリーミング情報およびディレイ・フィルタ１１２によって供給される、時間シフトしたストリーミング情報から切り替える切り替え機構を設けることもできるが、切り替え機構は、ソフトウエア、ハードウエア、またはその組み合わせであれ、このシステム内に別のコンポーネントを必要とするため、これを設計して、システムの残りのコンポーネントとの動作試験を行なわなければならない。更に、ストリーミング情報のソース１１４とレンダリング・デバイス１１６との直接的な接続をなくし、レンダリングの前に常にサーキュラ・バッファ１２４から読み出すことによって、レンダリングする情報の品質が一定となる。言い換えると、全ての情報が同じシステム・コンポーネントを通過するので、レンダリングするストリーミング情報の品質（例えば、画質または音質）には変化がない。更にまた、常にサーキュラ・バッファ１２４に対してライトおよびリードを行なうことによって、ユーザは、例えば、「瞬時リプレイ」を行なうためにストリーミング情報を記録するように、特定のコマンドを実行することを覚えておく必要がない。このように、ユーザが既にストリーミング情報の一部をレンダリングし終えているとしても、ユーザは、ストリーミング情報のセグメント全体（テレビジョン・ショー等）を検索し保存することもできる。したがって、ユーザがショーを見ており、次いで後にこのショーを保存することを決めた場合、アーカイブ・システム１３６を呼び出し、サーキュラ・バッファ１２４におけるショーの開始時に開始して、より永続的なファイルにストリーミング情報のコピーを転送することができる。後者は、ショーを見ながらでも、別個のリーダー・モジュール１２６を用いて行なうこともできる。しかしながら、ユーザは、ライタ・モジュール１２２が所望のストリーミング情報のいずれをも上書きする前に、保存即ち保管し始めなければならないが、好適な実施形態では、サーキュラ・バッファ１２４は、何時間にもわたるのではないにしても、数十分の情報格納には十分な長さを有する。
【００６７】
データ・ブロック構造
図１７は、ストリーミング情報のマルチ・ストリーム・ソースの１ストリームに対して、サーキュラ・バッファ１２４に格納したデータ・ブロック５００の図式表現である。全体的に、データ・ブロック５００は、ヘッダ部５０２、データまたはペイロード部５０４、およびテールまたは後端部５０６を含む。ヘッダ部５０２は、データ・ブロックのサイズや、それが属するチャネルというような、関連情報を収容する。即ち、ヘッダ部５０２は、フィールド５０８を含み、このフィールドを含むブロック全体のサイズを格納する。フィールド４１０は、データ・ブロックの先頭から、実際のストリーミング情報即ちペイロードをデータ・ブロック５００に格納するまでの距離を与える。フィールド５１１は、実際のデータ即ちペイロード５０４のサイズを示す値を与える。一実施形態では、フィールド５０８〜５１１の各々は、固定長であり、これらのデータ・ブロック５００内におけるロケーションがわかるようにしてある。
【００６８】
一実施形態では、フィールド５１２もヘッダ部５０２に設ける。フィールド５１２は、ストリーミング情報に関する他の情報を与える。ここで用いる場合、フィールド５１２を、実際のデータ即ちペイロード５０２に対するその関係を考慮して、「プレフィックス・フィールド」と呼ぶことにする。一実施形態では、プレフィックス・フィールド５１２は可変長であり、したがって情報の長さを制限する必要はない。望ましければ、フィールド５１３も設け、プレフィックス・フィールド５１２のサイズを示す。典型的に、フィールド５１３も、フィールド５０８〜５１１と同様、固定長である。
【００６９】
プレフィックス・フィールド５１２は、以下で論ずる、同期インディケータのような情報、同じストリームに属する次のデータ・ブロックへのポインタ、または所望に応じてその他の情報を格納するために用いることができる。当業者には認められようが、プレフィックス・フィールド５１２に収容する情報にフォーマットを指定し、関連情報を容易にデコードできるようにする。しかしながら、プレフィックス・フィールド５１２はいずれの長さにすることもできるので、必要に応じて追加情報を格納することによって、データ・ブロック５００を変調可能とすることができる。
【００７０】
尚、プレフィックス・フィールド５１２は、選択した「充填」(fill)データの量も含むことができることも注記しておく。充填データは、データ・ブロック５００のサイズを、サーキュラ・バッファ１２４における処理または格納に望ましいと思われる所定長に調節する即ち増大するために用いられる。
【００７１】
データ即ちペイロード・フィールド５０４は、ストリーミング情報のソース１１４から受け取ったディジタル・データを格納する。このディジタル・データをレンダリングする。
【００７２】
図示する実施形態では、テール即ち後端部５０６は、２つのフィールド５２０および５２１を含む。フィールド５２０は、ここでは「サフィックス・フィールド」と呼ぶが、同一ストリームにおいて連続するデータ・ブロックまたは直前のデータ・ブロックに関する情報を格納するために用いることができるという点で、プレフィックス・フィールド５１２に類似している。一実施形態では、サフィックス・フィールド５２０は、データ・ブロック５００の後端から既知のロケーションにあり、同じチャネルに対応する直前のデータ・ブロックのロケーションを示すポインタを格納する。この情報は、サーキュラ・バッファ１２４内に収容してあるストリーミング情報に対して「巻き戻し」動作を実行することが必要となり得る場合に特に有用である。また、サフィックス・フィールド５２０は、フィールド５１１およびフィールド５１３に関連するデータのように、データ・ブロック５００内にある他の情報も含むことができる。プレフィックス・フィールド５１２と同様に、サフィックス・フィールド５２０内に収容する情報のフォーマットは予め決められており、関連情報をそこから得られるように、リーダー・モジュールにはわかっている。サフィックス・フィールド５２０は、固定長とすることも、あるいは可変長とすることも可能であり、可変長の場合には、サフィックス・フィールド５２０の長さを示す、フィールド５１３と同様の追加フィールドを設けることが望ましい場合もある。サフィックス・フィールド５２０は、所望であれば、「充填データ」を格納するためにも用いることができる。
【００７３】
フィールド５２１は、データ・ブロック５００のサイズを与え、したがって、ヘッダ部５０２におけるフィールド５０８と同一である。フィールド５２１は、リーダー・モジュールが逆方向にサーキュラ・バッファ１２４を進む場合に特に有用である。このようにして、リーダー・モジュールは、フィールド５２１内に収容されている値を読み取ることによって、データ・ブロック５００のサイズを確認することができ、その値のポイントにおいて、リーダー・モジュールは、直前のブロックの後端がどこに位置するか判定した。フィールド５２１がないと、リーダー・モジュールは別の方法でデータ・ブロック５００をスキャンし、そのサイズまたは先頭ロケーションを判定しなければならないので、処理時間を浪費する可能性がある。
【００７４】
図１８は、マルチ・ストリーム・ストリーミング情報ソースからのデータ・ブロック５３０のシーケンスを示す。即ち、データ・ブロック５３２Ａ、５３２Ｂおよび５３２Ａが第１ストリームの一部を構成し、データ・ブロック５３４Ａおよび５３４Ｂが第２ストリームの一部を構成し、データ・ブロック５３６Ａおよび５３６Ｂが第３ストリームの一部を構成する。データ・ブロック５３２Ａ〜５３２Ｃ、５３４Ａ〜５３４Ｂ、および５３６Ａ〜５４６Ｂが一緒になって単一のチャネルを構成し、（例えば、オーディオ、ビデオ、およびデータ）、通常図１８に示すように介挿される。しかしながら、一般的に、特定の順序に従う必要はない。
【００７５】
先に示したように、プレフィックス・フィールド５１２およびサフィックス・フィールド５２０は、ストリーム・ストリームの各々における直前のデータ・ブロックおよび連続するデータ・ブロックを示すポインタを格納するために用いることができる。図１８の図では、矢印５３４が、データ・ブロック５３０のプレフィックス・フィールド５１２が、それぞれ、ストリームの各々において直後のデータ・ブロックのポインタまたはアドレスを格納することを表わす。同様に、矢印５３６は、データ・ブロックの各々のサフィックス・フィールド３２０が、それぞれ、各ストリームにおける直前のデータ・ブロックのポインタまたはアドレスを格納することを表わす。一実施形態では、プレフィックス・フィールド５１２の各々は、直後のデータ・ブロックにおけるプレフィックス・フィールド５１２のアドレスを格納し、一方サフィックス・フィールド５２０の各々は直前のデータ・ブロックにおけるサフィックス・フィールド５２０のアドレスを格納する。このように、リーダー・モジュール１２６は、ストリーミング情報の特定のストリームに対して、直ちにデータ・ブロックを突き止め処理することができる。
【００７６】
図１９は、データ・ブロック５５０の第２シーケンスを示す。シーケンス５５０において、データ・ブロック５５２、５５４および５５６は、ストリーミング情報ソース１１４から受け取ったストリーミング情報に属し、先に論じ更に以下でも論ずる態様で、レンダリング・デバイス１１６によって、選択的にレンダリングする。しかしながら、シーケンス５５０は、更に、データ・ブロック５５８および５６０も含む。これらは、シーケンス５５０に「詰め物」(pad)をするためであり、レンダリングするストリーミング情報を全く収容しない。むしろ、データ・ブロック５５８および５６０は、所望であれば、サーキュラ・バッファ１２４またはその他の記憶装置に格納してあるシーケンス５５０を所望の態様で編成または構造化するために用いられる。例えば、サーキュラ・バッファ１２４に格納したデータ・ブロックが、セクタまたはクラスタ境界というような、既定の媒体境界と一致することが望ましい場合がある。図１９では、所望の境界を５６２Ａおよび５６２Ｂで示す。データ・ブロック５５２、５５４および５５４は、適当なサイズまたは長さのパディング・データ・ブロック(padding data block)５６０と共に、データ・ブロック５６４が境界５６２Ｂにおいて開始するように編成される。所望であれば、複数のパディング・データ・ブロックを用いることができ、ストリーミング情報データ・ブロックおよびパディング・データ・ブロックの順序を変更して、あらゆる所望の基準も満たすようにすることも可能である。図１９のシーケンスは、シーケンス構造の一例に過ぎない。
【００７７】
尚、各データ・ブロックのフィールド５０９は、パディング・データ・ブロックを他のストリーミング情報データ・ブロックから識別するために用いることができ、ライタ・モジュールは、ストリーミング情報データ・ブロックの処理および形成の間、必要に応じてパディング・データ・ブロックを生成可能であることを注記しておく。更に、パディング・データ・ブロックは、所望であれば、プレフィックス・フィールド５１２またはサフィックス・フィールド５２０に設けた「充填」データと組み合わせて用いることも可能である。Muxフォーマッタ１３８およびライタ・モジュール１４０は、パディング・データ・ブロック、および／またはプレフィックス・フィールド５１２やサフィックス・フィールド５２０内に収容した充填データの使用を実現することもできる。
【００７８】
バッファ当たり多数のリーダー
場合によっては、いつでも一度に複数のユーザにストリーミング情報にアクセスさせることが望ましいときもあり得る。これは、多数の異なる方法のいずれでも行なうことができる。例えば、ストリーミング情報を複製し、ストリーミング情報の各コピー毎に、１つのリーダー・モジュールを設けることができる。しかしながら、これには大量のストレージが必要となり、更にストリーミング情報のコピーを多数作成するため、および複製コピーにアクセスするための処理能力増大が必要となる可能性もある。また、一旦ストリーミング情報のコピーを所定数使用すると、新たなユーザを追加することが非常に困難になる可能性もある。
【００７９】
図２０は、前述の図６に類似している。しかしながら、図２０は、システム６１０の複数の部分をより詳細に示し、明確化のためにその他の部分を削除してある。例えば、図２０は、システム６１０がサーキュラ・バッファ１２４、複数のユーザ（それぞれ、ユーザ６３０〜６３６）と関連付けた（前述のリーダー・モジュール１２６と同一または同様とすることができる）複数のリーダー・モジュール６１４、６１６、６１８および６２０を含むことを示す。更に、図２０は、各リーダー・モジュールが、それぞれ、インターフェース６２２、６２４、６２６および６２８を含むことも示す。インターフェース６２２〜６２８については、以下で更に詳細に説明する。
【００８０】
図２０に示す例示の実施形態では、複数のユーザ６３０、６３２、６３４および６３６は、それぞれ、インターフェース６２２〜６２８に結合して示されている。図示した実施形態では、ユーザ６３０および６３２はビューアまたはレンダリング・アプリケーションであり、サーキュラ・バッファ内に格納してあるストリーミング情報を見るかまたはレンダリングする。一方、ユーザ６３４および６３６はデータ記憶部位であり、サーキュラ・バッファ１２４に格納してあるストリーミング情報を保管するために用いられる。また、図２０は、インターフェース６２２〜６２８に別個に結合されている、単独のアプリケーション・プログラム６３８も示す。
【００８１】
再度注記すべきは、図２０は例示に過ぎず、あらゆる数のユーザまたはアプリケーション・プログラムでもあらゆる数のリーダー・モジュールに結合可能であるということである。同様に、ユーザは、サーキュラ・バッファ１２４に格納されているストリーミング情報にアクセスしたい適当な種類のユーザであれば、そのいずれでも可能であり、図２０に示すようなビューイング、保管の目的以外の理由で情報にアクセスしてもよい。同様に、本発明のこの態様によれば、バッファしてあるストリーミング情報をサーキュラ・バッファ１２４に必ずしも格納する必要はなく、線形バッファまたは他のいずれの形式のバッファにでも格納可能である。と言いつつもサーキュラ・バッファ１２４を示すのは、簡略化の目的のために過ぎない。
【００８２】
例示の一実施形態では、リーダー・モジュール６１４〜６２０は、ＣＯＭオブジェクト指向プログラミング・モデルに準拠したオブジェクトとして実現する。各リーダー・モジュール即ち「リーダー・オブジェクト」は、バッファしてあるストリーミング情報に独立してアクセスすることができる。各リーダー・モジュール６１４〜６２０は、サーキュラ・バッファ１２４上の異なるロケーションにおいてストリーミング情報にアクセスするように描いてある。これは、リーダー・モジュール６１４〜６２０が、バッファしてある情報ストリームにおいて異なる時点でバッファしてある情報にアクセス可能であることを示す。これによって、多数のユーザ６３０〜６３６が個別に、前述の時間シフティングの特徴全てを採用することができ、バッファしてある情報ストリームにアクセスしている他のユーザと干渉することはない。例えば、一人のユーザが後で見るためにストリーミング情報を保管し、同時に他のユーザがその情報を見ることができる。
【００８３】
同様に、アーカイブ・ユーザ(archival user)は、ビューア(viewer)がアクセスしているデータ・バッファの時点またはロケーションとは異なる、データ・バッファの時点またはロケーションから、バッファしてあるストリーミング情報を格納することができる。例えば、アーカイブ・ユーザは、情報をサーキュラ・バッファ１２４に記録しながら、この情報を読み取り、そしてこれをアーカイブ・ストレージに格納することが簡単にできる。対照的に、ビューアはデータを見ることができるが、間欠的に一時停止して休みを取ったり、他のタスクを実行する。したがって、ビューアに関連するリーダー・モジュールは、アーカイブ・プロセスに関連するリーダー・モジュールとは時間的に変位したバッファ１２４のロケーションに位置付けることも可能である。
【００８４】
このために、図２０は、多数のリーダー・モジュールが、バッファしてあるストリーミング情報にアクセス可能なシステムを示す。図示するシステムは、ストリーミング情報をバッファする１つのみのライタ・モジュール、および１つのみのストリーミング情報のコピーがあればよい。これによって、必要な記憶量が大幅に減少し、更に必要な処理能力も減少する。同様に、例示の一実施態様では、リーダー・モジュールは単にバッファ１２４内の情報にアクセスするように構成されたオブジェクトに過ぎないので、事実上あらゆる数のオブジェクトでもシステムに追加することができ、システムの計算資源によって制限されるだけである。これは、単に他のリーダー・オブジェクトをインスタンス化することによって達成することができる。
【００８５】
サーキュラ・バッファ１２４内に書き込まれたストリーミング情報は、１つ以上のチャネルで形成することができ、各チャネルは複数のストリーム（例えば、オーディオ、ビデオ、クローズド・キャプショニング等）を有するので、リーダー・モジュール６１４〜６２９の各々からの出力は、複数の効果的なピン(pin)を有する可能性が高く、各ピンはストリーミング情報における所与のチャネルのストリームの１つを搬送する。システム６１０は、複数の異なるリーダー・モジュールを用いて、バッファしてある同じストリーミング情報にアクセスすることができるので、これは、克服すべき障害となる可能性がある。
【００８６】
例えば、ストリーミング・アーキテクチャによっては、各リーダー・モジュール６１４〜６２９に関連するピンを集合化し、ユーザ、アプリケーションまたはリーダー・モジュールからデータを受け取るその他のあらゆるコンポーネントが、どのピンが当該リーダー・モジュールと関連付けられているのかわかるようにしておく必要性が生ずる場合もある。本発明にしたがって用いることができるストリーミング・アーキテクチャの一例は、DirectShow サービスとして知られているアーキテクチャである。
【００８７】
DirectShowサービスとは、市販されている公知のアーキテクチャである。しかしながら、本発明のある態様をより良く理解するために、DirectShowサービス・システムについて端的に説明すると有効であろう。
【００８８】
DirectShowサービスは、フィルタ・グラフとして知られているコンフィギュレーションに配置された、フィルタとして知られるプラグ可能コンポーネントのモジュール状システムのことを言う。フィルタ・グラフ・マネージャと呼ばれるコンポーネントが、これらのフィルタの接続を監視し、そこを通過するストリーミング情報の流れを制御する。フィルタ・グラフの一例は、異なる種類のフィルタの集合体で構成されている。
【００８９】
殆どのフィルタは、以下の３種類の内の１つに分類することができる。
１．ソース・フィルタは、ディスク・ファイル、カムコーダ、衛星フィード、インターネット・サーバ、またはＶＣＲのようなソースからデータを取得し、このデータをフィルタ・グラフに導入する。
【００９０】
２．変換フィルタは、データを処理し、フィルタ・グラフの他の部分と共に、またはフィルタ・グラフの外部にこれを受け渡す。
３．レンダリング・フィルタは、ハードウエア・デバイスまたはメディア入力を受け入れるいずれかのロケーション（メモリまたはディスク・ファイル等）にデータをレンダリングする。
【００９１】
これら３種類のフィルタに加えて、他の種類のフィルタもある。他のフィルタの例には、データ型を変更することなく効果を追加する効果フィルタ、およびソース・データのフォーマットを理解し、どのようにして正確なバイトを読み取るかを把握し、タイム・スタンプを作成し、シーク動作を実行するように構成されているパーザ・フィルタが含まれる。
【００９２】
更に、フィルタによっては、フィルタ形式、または関数の組み合わせを表わすことも大いに可能性がある。DirectShowアーキテクチャでは、フィルタはストリーミング情報を「下流の」次に続くフィルタに渡すと言う。「上流フィルタ」とは、データを下流のフィルタに渡すフィルタのことを言い、「下流フィルタ」とは、ラインにおいてデータを受け取る、次のフィルタのことを言う。例示の一実施形態では、フィルタは、いずれかの言語で書かれたプログラム・モジュールであり、コンポーネント・オブジェクト・モデル（ＣＯＭ）プログラミングに関与するオブジェクトを生成することができる。勿論、ＣＯＭプログラミングとは、オブジェクトがどのように単一のアプリケーションと、またはアプリケーション間で、相互作用するかを定義するオブジェクト指向プログラミング・モデルのことを言う。ＣＯＭにおいては、クライアント・ソフトウエアが、オブジェクト上の、メソッドと呼ぶ、１組の関連する関数を有するインターフェース（例えば、ＡＰＩ）に対するポインタを介して、オブジェクトにアクセスする。
【００９３】
一例としてに過ぎないが、フィルタ・グラフ６４０は、ファイルからＭＰＥＧ圧縮ビデオ情報をプレイ・バックすることを目的とし、図２０Ａに明記する形態を取ることができる。フィルタ・グラフ６４０は、ソース・フィルタ６４２、ＭＰＥＧパーザ６４４、ビデオ伸長変換フィルタ６４６、オーディオ伸長変換フィルタ６４８、ビデオ・レンダ・フィルタ６５０、およびオーディオ・レンダ・フィルタ６５２を含む。ソース・フィルタ６４２は、ディスクからデータを読み取り、これをストリーミング情報としてＭＰＥＧパーザ６４４に供給する。ＭＰＥＧパーザ６４４は、ストリーミング情報を解析して、そのオーディオおよびビデオ・ストリームに分類する。変換フィルタ６４６および６４８は、対応するストリームにおけるビデオおよびオーディオ・データを伸長する。レンダ・フィルタ６５０および６５２は、画面上にビデオ・データを表示し、オーディオ情報をサウンド・カードに送るようにそれぞれ作動する。
【００９４】
このように、DirectShowアーキテクチャのようなある種のストリーミング・アーキテクチャを用いる場合、リーダー・モジュール６１４〜６２０のいずれかからストリーミング情報を受け取るアプリケーションまたはその他のプログラミング・モジュールは、どの出力ピンがどのリーダー・モジュールに対応するか把握することが重要であると言える。例えば、リーダー・モジュール６１４〜６２０の各々によって読み込まれているストリーミング情報は、複数のストリームを有するチャネルを含むことができるので、いずれかの所与のリーダーから情報を受け取るユーザまたはアプリケーション・プログラムが、当該リーダーに関連する全てのストリームを受け取り、他のリーダーのストリームを受け取らないことが重要である。言い換えると、アプリケーション・プログラム（または、例えば、レンダリング・フィルタ）がリーダー・モジュール６１４からオーディオ・ストリームを受け取るが、リーダー・モジュール６１６からビデオ・ストリームおよびクローズド・キャプショニング・ストリームを受け取ることは望ましくない。リーダー・モジュール６１６は、バッファ１２４内においてリーダー・モジュール１６４とは異なるロケーションからストリーム情報を読み込んでいることも当然あり得る。したがって、オーディオおよびクローズド・キャプション・ストリームは、ビデオ・ストリームには対応しない。
【００９５】
この障害に取り組むために、本発明の特徴の１つは、新たなＣＯＭインターフェースを含む。これは、リーダー・モジュール６１４〜６２０外部のオブジェクトが、当該特定のリーダー・モジュールに属する出力ピンを列挙することができるようにしたものである。言い換えると、リーダー・モジュール６１４〜６２０をオブジェクトとして実現した実施形態では、これらのオブジェクトは、関連するインターフェース６２２〜６２８を通じてメソッドをアプリケーション（または、リーダー・モジュールとの接触を有する他の外部コンポーネント）に露出させ、オブジェクトの操作を可能にするように構成されている。インターフェース６２２〜６２８によって露出されるメソッドの一例を、IenemChannelStreamPinと呼ぶ。これは、外部オブジェクトによって呼び出されると、問い合わせを受けた特定のリーダー・モジュールに属する特定の出力ピンの表を作成する。このように、外部オブジェクトは、それに関連するインターフェース６２２〜６２８を通じて、所与のリーダー・モジュール６１４〜６２０のいずれに属する特定のピンについても、その表を素早く簡単に取得することができる。
【００９６】
また、インターフェース６２２〜６２８は、そのグループのエニュメレータ(enumerator)オブジェクトに対して、いずれのリーダー・モジュール６１４〜６２０が出力したいずれの特定のピンにも問い合わせができるようにする、他のメソッドも露出させる。言い換えると、外部オブジェクトは、いずれのピンにも問い合わせを行い、当該ピンを含むグループに対応する特定のエニュメレータのアイデンティティを取得するために接触することができる。このように、最近出力ピンに対するアクセスを獲得したばかりのユーザまたはアプリケーション・プログラムは、当該出力ピンに問い合わせを行い、当該出力ピンに関連するエニュメレータを求めることができる。そして、外部コンポーネントは、エニュメレータによって露出されたメソッドを呼び出し、そのチャネルに対応するピンの完全な表を取得する。こうして、外部コンポーネントは、システム６１０が出力する、いずれの所与のリーダー・モジュール、またはチャネルに関連するピンについても、そのアイデンティティを素早くしかも精度高く取得することができる。
【００９７】
インデックス化およびシーク
先に論じたように、インデックサ１３２は、シークに用いるインデックス・エントリを収容したインデックスを生成する。言い換えると、リーダー・モジュール６１４〜６２０の各々は、インデックス内に対応するエントリを有する、バッファ１２４内のいずれのポイントでもシークすることができる。場合によっては、ストリーミング情報の特質にしたがって、バッファ１２４内における実質的にあらゆるポイントでもインデックス化することができる。しかしながら、他の種類のストリーミング情報では、ストリーミング情報内のあるポイントのみをインデックス化することが望ましい場合もある。ここでは、このようなポイントを同期ポイントと呼ぶ。言い換えると、ストリーミング情報の特質によっては、ストリーミング情報内のあるポイントをシークし、そのポイントにおいてデータのレンダリングを開始することが正当でない、または望ましくないという場合もあり得る。
【００９８】
例えば、あるビデオ・ストリーミング情報は、公知のＭＰＥＧ２ビデオ・フォーマットに対して作用する。このようなフォーマットは、多数の異なる種類のフレームを含み、Ｉフレーム、Ｂフレーム、およびＰフレームと呼んでいる。Ｉフレームは、レンダリングに他の情報を必要としないが、ＢおよびＰフレームは依存性フレームであり、レンダリングするためには、先行するＩフレームにおける情報を必要とする。このような例では、ＢまたはＰフレームで始まるバッファ１２４内のポイントをシークすることは望ましくない場合がある。実際に、従来のビデオ・デコーダの多くは、直前のＩフレームに収容されている必要な情報がないと、ＢまたはＰフレームから供給されるデータをデコードすることすらできない場合もある。したがって、このようなビデオ・フレームがバッファ１２４上に格納されている場合、その中のＩフレームのみをインデックス化することが非常に望ましいと言えよう。
【００９９】
同様に、ストリーミング情報が、クローズド・キャプショニングの筆記テキストのようなストリームを含む場合、ユーザに、単語の開始または後端、文章の開始または後端、あるいは節の開始または後端に対応するポイントをシークさせることが望ましい場合もある。オーディオ・ストリームについても同じである。言い換えると、オーディオ・ストリーム内におけるあるスポットのみをユーザにシークさせることが望ましい場合がある。このようなスポットは、文章または単語の境界等に対応する可能性がある。
【０１００】
したがって、本発明の代表的な特徴の１つは、図２１Ａに示すような、ストリーム・アナライザ６５４を含む。ストリーム・アナライザ６５４は、ストリーミング情報のソース６５６、およびストリーミング情報のシンク６５８に結合されているように示されている。ストリーミング・アナライザ６５４は、（ソフトウエア・オブジェクトとして実現することができる）ソース６５６からストリーミング情報を受け取るように構成されている。
【０１０１】
例示の一実施形態では、ストリーム・アナライザ６５４は、ソース６５６が供給するストリーミング情報の編成に関する知識を具体化する。また、アナライザは、一例として、情報内の論理的な境界の検出に関する知識を具体化し、これらの境界（同期ポイント）のロケーションを取得する。次に、同期ポイントのロケーションを、情報を望む他のいずれかのソフトウエアまたはハードウエア・コンポーネントに提示し、ストリーミング情報を通じた順方向または逆方向の飛ばし(skipping)を、一層実用的に行なうことが可能となる。
【０１０２】
ストリーム・アナライザ６５４は、一例として、２つの方法の内１つで、同期ポイントの指示を与える。第１の実施形態では、ストリーム・アナライザ６５４は、ストリーミング情報が情報シンク６５８に供給される際に、同期ポイントのロケーションをストリーミング情報自体の中に埋め込む。これを派生同期ポイント情報の帯域内(in-band)通信と呼ぶ。
【０１０３】
代替実施形態では、ストリーム・アナライザ６５４は、破線の矢印６６０で示すように、シンク６５８に供給されるストリーミング情報とは別個に、同期ポイント情報を供給することができる。これを派生同期ポイント情報の帯域外(out-of-band)通信と呼ぶ。
【０１０４】
例示の一実施形態では、ストリーム・アナライザ６５４は、クラスを用いたＣ＋＋プログラミング言語で実現し、ＣＯＭインターフェースを用いて別のソフトウエア・オブジェクトと通信する。しかしながら、このような実施態様は例示に過ぎず、本発明はこの特定的なメソッドの実施態様には限定される訳ではない。
【０１０５】
勿論、情報シンク６５８は、下流フィルタ（ストリーム・アナライザ６５４の下流にある）、アプリケーション・プログラム、レンダリング・フィルタ、またはその他のプログラム・モジュール等とすることができる。シンク６５８は、派生同期情報自体を用いることができ、あるいは派生同期ポイント情報を使いたい他のコンポーネントがあれば、これらに単に受け渡すこともできる。例示の一実施形態では、派生同期ポイント情報はディレイ・フィルタ１１２に供給され、ディレイ・フィルタ１１２はインデックスを生成する際にこれを用いる。これについては、以下で更に詳しく説明する。
【０１０６】
例示の別の実施形態では、ストリーム・アナライザ６５４は、着信するストリーミング情報を分析して、同期ポイントとして用いることができる論理的な境界を求めるだけでなく、ストリーム・アナライザ６５４は、着信ストリーミング情報を分析して、望ましい同期ポイントとなり得る、関心ポイント(point of interest)の情報も求める。このような関心ポイントは、ユーザにとって興味深い可能性があると思われるポイントであれば、実質的にあらゆるポイントとすることができる。したがって、このような実施形態では、ストリーム・アナライザ６５４は、着信ストリーム内の情報の形式およびフォーマットに関する知識だけでなく、ユーザにとって関心があるイベントの形式に関する知識も具体化する。同様に、ストリーム・アナライザ６５４は、着信ストリーミング情報におけるこれら関心ポイントをどのようにして検出するかに関する知識を収容するように構成され、これら関心ポイントに対応するデータ・ストリーム内のロケーションを報告する機構が設けられている。
【０１０７】
図２１Ｂおよび２１Ｃは、本発明の例示の実施形態によるストリーム・アナライザ６５４を示す、更に詳細なブロック図である。図２１Ｂは、派生同期ポイント情報を帯域外で供給するストリーム・アナライザ６５４の一実施形態を示し、一方図２１Ｃは、派生同期ポイント情報を帯域内で供給する実施形態を示す。
【０１０８】
図２１Ｂでは、ストリーム・アナライザ６５４は、関心ポイント（ＰＯＩ）分析コンポーネント６６４、およびストリーミング情報インターフェース・コンポーネント６６６を含む。ソース６５６から関心ポイント分析コンポーネント６６２に、ストリーミング情報を供給される。関心ポイント分析コンポーネント６６２は、ストリーミング情報に収容されている情報の情報形式および情報の編成に関する知識、およびユーザにとって関心のあるポイントに関する知識を要求する。ＰＯＩ分析コンポーネント６６２は、次に、ストリーミング情報内の関心ポイントを特定し、関心ポイントのロケーションを示す（即ち、同期ポイントを示す出力６６８を供給する）。出力６６８は、ＰＯＩインターフェース６６４に供給され、シンク６５８が使用できる情報を作成する。同様に、ＰＯＩ分析コンポーネント６２２は、着信ストリーミング情報をストリーミング情報インターフェース６６６に受け渡し、ストリーミング情報が別個にシンク６５８に使用できるようにする。
【０１０９】
図２１Ｃは、図２１Ｂと同様であり、同様の構成には、対応する番号を付してある。しかしながら、同期ポイント情報およびストリーミング情報に対して２つの別個のインターフェース６６４および６６６を有する代わりに、図２１Ｃに示すストリーム・アナライザ６５４は、単一の結合インターフェース６６９を有する。これは、関心ポイント（即ち、同期ポイント）情報をストリーミング情報に統合し、これを帯域内出力としてシンク６５８に供給する。勿論、同期ポイント情報の統合は、ＰＯＩ分析コンポーネント６６２においても達成可能であることは気が付いて当然である。いずれの場合においても、ストリーミング情報の単一出力（帯域内同期ポイント情報を収容する）を、シンク６５８に供給する。
【０１１０】
図２１Ｄは、関心ポイント分析コンポーネント６６２の一実施形態の更に詳細なブロック図である。ここでは、その出力に供給されるストリーミング情報に同期ポイント情報を統合することは、関心ポイント分析コンポーネント６２において行われる。ＰＯＩコンポーネント６６２は、図２１Ｄに示す例示の実施形態では、解析コンポーネント６７０、筆記言語分析コンポーネント６７２、ビデオ分析コンポーネント６７４、およびオーディオ分析コンポーネント６７６を含む。あらゆる形式の情報分析コンポーネントでも使用可能であるが、単に例示の目的のために、コンポーネント６７２、６７４および６７６を図示する。ＰＯＩ分析コンポーネント６６２は、統合化コンポーネント６７８９も含む。
【０１１１】
解析コンポーネント６７０は、ストリーミング情報をその入力において受け取る。図示する実施形態では、ストリーミング情報は、筆記テキスト・ストリーム（例えば、クローズド・キャプション情報）、ビデオ・ストリーム、およびオーディオ・ストリームのような、複数のストリームを含むことができる（とは言え、１つのストリームのみでも同様に処理可能である）。解析コンポーネント６７０は、着信ストリーミング情報を解析し、それぞれのストリーム・コンポーネントに分類し、これらのコンポーネントを適切な分析ブロック６７２、６７４および６７６に供給する。
【０１１２】
分析コンポーネント６７２、６７４および６７６は着信ストリームを分析し、潜在的な関心ポイントを特定し、これら関心ポイントのロケーションを示す情報を生成する。次いで、各分析コンポーネント６７２〜６７６から統合化コンポーネント６７８にストリーミング情報および同期ポイント情報を供給される。図示する実施形態では、統合化コンポーネント６７８は、ストリームを元のストリーミング情報に再統合し、更にストリーミング情報内の適切なロケーションに、同期ポイント情報を埋め込む。このようにして、帯域内同期ポイント情報は、統合化コンポーネント６７８の出力において、データ・ストリームに与えられる。
【０１１３】
尚、分析コンポーネント６７２〜６７６は、実質的にあらゆる所望の関心ポイントでも摘出可能であることを注記しておく。例えば、筆記言語コンポーネント６７２は、文章の境界または単語の境界を摘出するように構成することができる。文章の境界を摘出する際には、分析コンポーネントは、単に着信ストリームにおいてピリオドを摘出するように構成することができる。単語の境界を摘出するためには、コンポーネント６７２は、単に着信ストリームにおける空白を摘出するように構成することができる。また、言語分析コンポーネント６７２は、自然言語処理または自然言語分析コンポーネントのように、一層精巧化した分析コンポーネントとすることができ、その場合、コンポーネント６７２は、ある種の句、添え字(surname)、音声の一部等を識別するように構成可能であることも注記しておく。いずれの場合にせよ、コンポーネント６７２が識別する筆記言語の関心ポイントを示す情報は、コンポーネント６７２に供給され、着信ストリームにおいて所望の関心ポイントを識別することができる。
【０１１４】
同様に、ビデオ分析コンポーネント６７４は、あらゆる数の異なる関心ポイントでも識別するために用いることができる。例えば、コンポーネント６７４は、コマーシャルの中断を識別したり、前述のＩ、ＢおよびＰフレームを識別するように構成することができる。着信ビデオ・ストリームにおいてコマーシャルの中断を識別する際、ビデオ分析コンポーネント６７４は、単にある所定の時間量の間存在する黒画面を摘出するように構成することができる。同様に、ＭＰＥＧ２ビデオ・フォーマットでは、Ｉ、ＢおよびＰフレームは、これらをそのように識別するマーカを含むか、あるいはフレームを識別するフレームがこれらの前に位置する。したがって、ビデオ分析コンポーネント６７４は、ストリーム内の識別情報を摘出するように構成することができる。
【０１１５】
また、オーディオ分析コンポーネント６７６も、広い範囲の関心ポイントを摘出するように構成することができる。一例として、着信ストリームが、ホラー関係の映画、戦争関係の映画、またはアクション関係の映画、あるいはテレビジョン番組からの場合、オーディオ分析コンポーネントは、金切り声、銃声、または車の追跡時の騒音のような煩い雑音を摘出するように構成することができる。その場合、コンポーネント６７６は、単に、所定のスレシホルドを超過する振幅情報を摘出するように構成することができる。同様に、コンポーネント６７６は、スピーチ認識コンポーネントまたはボイス認識コンポーネントのような、一層進んだコンポーネントとすることができる。コンポーネント６７６がスピーチ認識コンポーネントを含む場合、文章または単語の境界を摘出するように構成することができ、あるいは特定の単語または句を摘出するように構成することができる。例えば、コンポーネント６７６は、不敬な単語を識別するために用いることができる。これらには印を付け、後に削除することができる。同様に、コンポーネント６７６がボイス認識コンポーネントを含む場合、ある男優または女優の声、あるいはそのように識別可能な他のエンティティであればそのいずれでも識別するように構成することができる。
【０１１６】
再度述べておくべきは、関心ポイント分析コンポーネント６６２は、識別可能な実質的にあらゆる関心ポイントのロケーションを識別するように構成可能であるということである。コンポーネント６６２には、分析対象の関心ポイントを示す情報、およびこれに供給されるストリーム内で受け取る情報の形式および情報のフォーマットを示す情報を提供するだけでよい。前述の具体的な実施形態は、例として提示したのであり、本発明のこの特徴の用途を限定するように見なしてはならない。
【０１１７】
図２２は、ＰＯＩ分析コンポーネント６６２の動作を更に詳細に示すフロー図である。まず、ＰＯＩ分析コンポーネント６６２は、ストリーミング情報を受け取る。これをブロック６８０で示す。次に、解析コンポーネント６７０がストリーミング情報を解析し、関心ポイント分析のためにそれぞれのストリームに分類する。これをブロック６８２に示す。関心ポイント分析に先立ついずれかの時点において、識別すべき関心ポイントを示す関心ポイント分析情報を、ＰＯＩ分析コンポーネント６６２内にある種々の分析コンポーネントに提供しなければならない。これをブロック６８４で示す。次に、ブロック６８６で示すように、受け取った関心ポイント情報に基づいて、ストリームを分析する。
【０１１８】
一旦ストリームから関心ポイント情報を得たなら、次にストリームを再統合し、統合したストリームと共に、関心ポイント情報を帯域内または帯域外のいずれかで提供する。これをブロック６８８で示す。次に、データ・ストリームおよび関心ポイント情報を下流コンポーネント（ディレイ・フィルタ１１２等）に伝達し、更に処理を進める。この場合も、注記すべきは、関心ポイント情報は、帯域内または帯域外のいずれでも提供可能であることである。これを図２２のブロック６９０で示す。
【０１１９】
図２３Ａ、図２３Ｂおよび図２３Ｃは、筆記言語分析コンポーネント６７２、ビデオ分析コンポーネント６７４、およびオーディオ分析コンポーネント６７６の動作を示す、更に詳細なフロー図である。図２３Ａは、筆記言語分析コンポーネント６７２が最初に筆記言語ストリーム情報（クローズド・キャプション情報等）を受け取ることを示す。これをブロック６９２で示す。次に、コンポーネント６７２は、ストリーム情報を分析し、単語または文章の境界、ある句、添え字、あるいはスピーチの他の部分等を突き止める。この場合も、識別した関心ポイントは、コンポーネント６７２を適正に構成する、実質的にあらゆる関心ポイントとすることができる。これをブロック６９４で示す。次に、コンポーネント６７２は、関心ポイントが位置する、ストリーミング情報内のロケーションの指示を与える。これをブロック６９６で示す。
【０１２０】
図２３Ｂは図２３Ａと同様であり、同様の構成には対応した番号が付してある。しかしながら、テキスト関心ポイントを突き止める代わりに、ビデオ分析コンポーネント６７４は、ビデオ・ストリーム情報を分析して、黒画面、画像変化（所望の場面変化に対応する可能性がある）、Ｉ、ＢおよびＰフレーム・マーカ等を求める。
【０１２１】
図２３Ｃは、図２３Ａおよび図２３Ｂと同様であり、同様の構成には対応した番号が付してある。しかしながら、筆記言語またはビデオ情報を分析する代わりに、コンポーネント６７６はオーディオ・ストリーム情報を分析する。図２３Ｃに示す実施形態では、コンポーネント６７６は、オーディオ・ストリーム情報を分析して、振幅変化、文章または単語の境界、あるコンテンツの単語（例えば、不敬）、ある人の声等を求める。これをブロック７００で示す。
【０１２２】
インデックス生成
前述のように、システム６１０内のリーダー・モジュール６１４〜６２０は、バッファ１２４内においていずれかのインデックス・ポイントをシークできるように構成されている。同期ポイントを有さない情報ストリームについては、リーダー・モジュールがバッファ１２４内にある実質的にあらゆるサンプルをシークすることが合理的である。したがって、このような情報ストリームでは、いずれのサンプルもインデックス化することができる。このような実施形態では、インデックサ１３２がインデックス・エントリを生成する。これは、単に、インデックサの所望の粒度に対応する。例えば、あるストリームでは、時間的に約０．２５秒だけ離間したポイントをインデックス化することが望ましい場合もある。他の情報を用いて、２秒以上離間したポイントをインデックス化することが望ましい場合もある。同期ポイントを有さない情報ストリームでは、インデックサ１３２は、単に、インデックサの所望の粒度だけ分離した、バッファ１２４内のロケーションを識別するインデックス・エントリを生成する。
【０１２３】
しかしながら、前章で論じたように、多くのデータ・ストリームには同期ポイントが設けられている。これらの場合、インデックサ１３２が、同期ポイントのみに対応するインデックス・エントリを生成することが望ましい場合もある。勿論、同期ポイントがインデックス生成部の所望の粒度よりも頻繁に現れる場合、各同期ポイントを１つずつインデックス化しなくてもよい場合もあることを注記しておく。しかしながら、インデックス生成部の所望の粒度よりも頻繁に同期ポイントが現れない場合、実質的にあらゆる同期ポイントをインデックス化すればよい。
【０１２４】
このような構成の下では、問題が生ずる可能性がある。例えば、所与のストリーミング・アーキテクチャでは、前述のストリーム・アナライザ６５４が存在しない場合もあり、あるいはこれが受け取っているストリーミング情報が同期ポイントを含むか否か未だわからない場合もある。そのような場合、インデックサ１３２は、ストリーム情報を受け取り始める時点では、単にその粒度にしたがってサンプルをインデックス化し始めなければならないのか、あるいは待機して同期ポイントのみをインデックス化すべきかわからない可能性がある。図２４は、この問題に取り組んだインデックサ１３２の動作を示すフロー図である。
【０１２５】
最初に、インデックサ１３２は単にストリーム・アナライザ６５４に対してクエリを実行し、ストリーム・アナライザ６５４が、着信ストリーミング情報が同期ポイントを含むか否かに関する情報を提供することができるか否か判定を行なう。これをブロック７０２で示す。ストリーム・アナライザ６５４は、応答を与えない場合すらあり得るし、あるいはストリーミング情報が同期ポイントを含むか否か未だわからないことを示す応答を与える場合もある。分析部６５４が、同期ポイントが存在するか否かを示す情報が得られることを示す応答を与えた場合、フラグをセットする。このフラグは、図２４では、「同期ポイント情報許可」(Sync Point Info Is Authoritative)フラグと呼んでいる。これをブロック７０３および７０４で示す。同期ポイントが存在するか否かを示す情報が得られない場合、このフラグをリセットする。これをブロック７０３および７０５で示す。
【０１２６】
次に、同期ポイントの有無に関する情報が得られる場合、実際に同期ポイントがあるか否か判定を行なう。これをブロック７０６で示す。ストリーム・アナライザ６５４が既に着信ストリーミング情報において同期ポイントを識別している場合、同期ポイントが存在することを示す応答をインデックサ１３２に供給する。その場合、インデックサ１３２は、同期ポイント・フラグを、着信データが実際に同期ポイントを含むことを示す値にセットする。これをブロック７０７で示す。しかしながら、ストリーム・アナライザ６５４が応答しない場合、または着信ストリーミング情報内で同期ポイントを未だ突き止めておらず、それを示す出力をインデックサ１３２に供給した場合、インデックサ１３２は、当面、着信ストリーミング情報には同期ポイントがないと想定し、同期ポイント・フラグをリセットする。これをブロック７０８で示す。次に、ブロック７１０で示すように、インデックサ１３２はストリーミング情報のサンプルを受け取る。
【０１２７】
サンプルを受け取ると、インデックサ１３２はこのサンプルを分析し、サンプルに同期ポイントとして印が付いているか否か調べる。これをブロック７１２および７１４で示す。サンプルに同期ポイントとしての印が付いていない場合、インデックサ１３２は同期ポイント・フラグを検査し、同期ポイント・フラグがセットされているか否か調べる。これをブロック７１６で示す。ブロック７１６において、同期ポイント・フラグが実際にセットされていると判定した場合、これは、処理対象のストリーミング情報が同期ポイントを含んでいることを示し、このサンプルに同期ポイントとしての印を付けない。したがって、インデックサ１３２は、分析中のサンプルをインデックス化せず、単にブロック７１０の処理に戻る。
【０１２８】
しかしながら、ブロック７１６において、同期ポイント・フラグがセットされていないと判定した場合、インデックサ１３２は、着信ストリーミング情報内には同期ポイントが存在しないと未だ想定していることになる。したがって、インデックサは、当該インデックサの所望の粒度に基づいて、単にこの分析中のサンプルをインデックス化すべきか否か判定を行なう。言い換えると、インデックサ１３２が（例えば）１／２秒毎よりも頻繁にポイントをインデックス化する場合、インデックサ１３２は、以前にインデックス化したサンプルから少なくとも１／２秒だけこのサンプルが時間的に離れているか否か判定を行なう。離れている場合、このサンプルをインデックス化する。離れていない場合、処理は単にブロック７１０に戻る。これをブロック７１８で示す。
【０１２９】
ステップ７１４において、インデックサ１３２がこのサンプルには同期ポイントとしての印が付いていると判定した場合、インデックサ１３２は同期ポイント・フラグが現在セットされているか否か判定を行なう。これをブロック７２０に示す。同期ポイント・フラグが現在セットされている場合、インデックサ１３２は単にブロック７１８の処理に進み、直前のインデックス・エントリから十分な時間的変位に達しており、本同期ポイントをインデックス化できるか印加について判定を行なう。
【０１３０】
しかしながら、ブロック７２０において、このサンプルに同期ポイントとしての印は付いているが、同期ポイント・フラグがセットされていないと判定した場合、インデックサ１３２は、ブロック７２１において、「同期ポイント・フラグ承認」フラグがセットされているか否か判定を行なう。セットされていない場合、インデックサ１３２は、分析中のストリーミング情報には同期ポイントが存在しないと想定していたが、実際には同期ポイントが存在することを認める。したがって、インデックサ１３２は、ブロック７２２に示すように、以前のインデックス・エントリ全てを破棄し（これらは非同期ポイント・サンプルに対応するので）、ブロック７２４で示すように、同期ポイント・フラグをセットする。次に、処理は再びブロック７１８に関して継続する。同様に、ブロック７２１において、「同期ポイント情報承認」フラグがセットされていると判定した場合、処理はブロック７１８に進む。
【０１３１】
したがって、図２４に示すアルゴリズムを用いることによって、本発明のこの特徴は、インデックサが現在ストリーミング情報内に同期ポイントがあるか否か把握しているか否かには関係なく、ストリーミング情報内のポイントを精度高くインデックス化するために使用できることがわかる。同期ポイントがない場合、インデックサの所望の粒度にしたがって、サンプルをインデックス化する。同期ポイントがある場合、同期ポイントのみをインデックス化する。
【０１３２】
多数のストリームを用いた時間シフト・シーク
前述のように、バッファ１２４に格納してあるストリーミング情報は、多数のストリームを含むことができる。また、前述のように、インデックサ１３２がインデックス化したストリーミング情報内の種々のポイントをリーダー・モジュール６１４〜６２０（図２０に示す）にシークさせることが望ましい場合もある。これは多少困難である。シークを要求した後に、バッファ１２４内のどの特定のファイル・オフセットで、特定のリーダー・モジュールが読み込み始めるべきか判定することは困難である。この判断が難しいのは多数の要因による。
【０１３３】
例えば、ストリームは、バッファ１２４内に位置するファイルの中で同期が外れている可能性がある。言い換えると、オーディオ情報がビデオ情報の前または後に、異なる記憶ブロックで格納されている可能性があり、この２つが直接一致しないことがある。また、リーダー・モジュールは、同期ポイントをインデックスしていない、バッファ１２内の位置（特定のタイム・サンプルを有するサンプル）をシークするように要求する場合もある。言い換えると、先に明記したように、インデックサ１３２は全ての単一サンプルをインデックス化する訳ではない。代わりに、それ自体の粒度に基づいて、または同期ポイントに基づいてインデックス化するに過ぎない。したがって、リーダー・モジュールは、インデックス・エントリが得られないタイム・スタンプをシークするように要求する場合がある。更に、あるストリームは同期ポイントを含み、他のストリームは含まない場合もある。加えて、同期ポイント全てがインデックス化されている訳ではない。何故なら、これらは、インデックスの所望の粒度よりも頻繁に現れる可能性があるからである。本発明の代表的な特徴の１つは、多数のストリームを有するチャネル全体をシークする際のこれらの障害に取り組むことを目的とする。
【０１３４】
図２５は、バッファ１２４の一部の一例を示し、複数のバッファ・サンプルに分割されている。サンプル７３０は、第１方向の斜線を有し、第１ストリームのサンプルを表わす。サンプル７３２は、反対方向の斜線を有し、第２ストリームのサンプルに対応する。斜線のないサンプル７３４Ａ、７３４Ｂ、７３４Ｃおよび７３４Ｄは、第３ストリームのサンプルに対応する。
【０１３５】
本発明の例示の一実施形態は、先に特定した障害に取り組むためのシーク・アルゴリズムであり、図２５および図２６に関して説明する。このアルゴリズムでは、シークを行なう特定のリーダー・モジュールが、バッファ１２４内における最大のファイル・オフセットをシークする。これは、ストリームの個々のシーク要件の各々を満たすのに適している。次に、リーダー・モジュールはストリーミング情報を開始するが、各ストリームに対して実際にプレイすべき最初のサンプルよりも前に読み取られた、読み取り中のストリームの各々に介する情報を欠落させる。加えて、正確なタイム・スタンプを有する同期ポイントがインデックス化されていない場合、所望のシーク位置の前で最も近い同期ポイントを、潜在的な開始点とする。しかし、所望のシーク位置の前で最も近い同期ポイントが余りに遠い過去ではないことを条件とする。ストリームには同期ポイントを含まないものもあるので、本発明は、同期ポイントがないストリームでは、各サンプルを同期ポイントとする。最後に、同期ポイントを全てインデックス化していない場合もあるので、シーク・アルゴリズムは、最初に、所望のシーク位置前後の最も近いインデックス化同期ポイントを求め、次いで２つのインデックス化したシーク・ポイント間の差を判定し、これら２つの間に、インデックス化されていない同期ポイントが未だあり得るか否か調べる。ある場合、２つのインデックス化同期ポイント間のデータを読み取り、追加の同期ポイント（および所望のシーク・ポイントに更に近い同期ポイント）が存在するか否か判定を行なう。
【０１３６】
更に具体的には、図２６は、本発明の代表的な特徴の１つによるシーク動作を示すフロー図である。バッファ１２４内の位置（図２５に示す）をシークするために、指定されたリーダー・モジュールは最初にシーク要求を受け取り、時点Ｔを示すタイム・スタンプを有する、バッファ１２４内の位置をシークする。これをブロック７４０で示す。図２５において、タイム・スタンプＴはサンプル７３４Ｃに対応する。例示の実施形態では、サンプル７３４Ｃはインデックス化されていない。
【０１３７】
次に、変数FILEOFFSETを無限大（または非常に大きな数）にセットする。これをブロック７４２で示す。
次に、複数のストリームの内最初のストリームを選択して分析する。これをブロック７４４で示す。
【０１３８】
最初のストリームに対して、時間変数Ｔ１を、所望のシーク時点Ｔよりも前で最大のタイム・スタンプを有するインデックス・エントリにセットする。図２５において、指定のストリームに対するサンプル７３４Ａは、所望のシーク時点Ｔよりも前で最大のタイム・スタンプを有するインデックス・エントリＴ１に対応することがわかる。このようなインデックス・エントリが存在しない場合、Ｔ１をＴ−Ｚにセットする。例示の一実施形態では、Ｚ＝１００である。このため、基本的に、Ｔ１は破棄されることになる。これは後の処理において示すこととする。これをブロック７４６で示す。
【０１３９】
次に、時間期間Ｔ２を、所望のシーク時点Ｔ後で最小のタイム・スタンプを有する、選択したストリームに対するインデックス・エントリにセットする。サンプル７３４Ｄは、インデックス化され、時点Ｔの右側（例えば、時点Ｔの後）で最小のタイム・スタンプを有する、選択したストリーム内のサンプルに対応することがわかる。このようなインデックス・エントリが存在しない場合、ファイル・オフセットを計算する目的のために現在選択してあるストリームを無視し、新たなストリームを選択する。これをブロック７４８で示す。
【０１４０】
このように、ブロック７４８における処理の後、時点Ｔの各側に位置し、時点Ｔに最も近い２つのインデックス・エントリを特定したことが分かる。これらのインデックス・エントリは、時点Ｔ１およびＴ２に対応する。所望の時点Ｔと直前のインデックス化時点Ｔ１との間の時間的変位は、Ｘ＝Ｔ−Ｔ１で表わされる。所望のシーク時点Ｔと続くインデックス・エントリＴ２との間の時間的変位は、Ｙ＝Ｔ２−Ｔで表わされる。
【０１４１】
ＸおよびＹ双方が、所定の時間間隔（例えば、５秒）よりも大きい場合、これはインデックス化サンプルＴ１およびＴ２双方が、所望のシーク位置Ｔから離れ過ぎていてなす術がないことを示す。この判定をブロック７５０で示す。ＸおよびＹが所定の時間間隔よりも大きい場合、単にFILEOFFSETの計算において、本ストリームを無視する。これをブロック７５２で示す。次いで、処理はブロック７５４に進み、ここで追加のストリームが存在するか否か判定を行なう。存在する場合、ブロック７５６において次のストリームを選択し、ブロック７４６に関して処理を継続する。追加のストリームが存在しない場合、ブロック７４５においてシークを実行する。これについては以下で更に詳しく説明する。
【０１４２】
ブロック７５０において、値ＸおよびＹ双方が所定の時間間隔よりも大きくないと判定した場合、ＸまたはＹのどちらが所定の時間間隔よりも大きいか判定を行なう。例えば、ブロック７６０において、値Ｘ（Ｔ−Ｔ１に対応する）が５秒よりも大きいか否か判定を行なう。大きい場合、値Ｙは５秒未満でなければならず、変数FILE OFSET THIS STREAMをインデックス値Ｔ２にセットする。これをブロック７６２で示す。
【０１４３】
ブロック７６０において、Ｘの値が５秒以下であると判定した場合、次に値Ｙが５秒よりも大きいか否か判定を行なう。大きい場合、値Ｔ２を無視することができ、変数FILE OFFSET THIS STREAMを値Ｔ１にセットする。これをブロック７６４および７６６で示す。
【０１４４】
基本的に、ブロック７６０〜７６６は、インデックス値Ｔ１またはＴ２のいずれかが、所望のシーク時点Ｔから遠くに離れ過ぎていてなす術がないか否か判定を行なう。離れ過ぎている場合、これらは以降の計算から排除する。
【０１４５】
しかしながら、ブロック７６４において、値Ｙが５秒以下であると判定した場合、これは、値Ｔ１およびＴ２に対応する双方のサンプルが、所望のシーク時点Ｔに十分近く、対象となり得ることを意味する。その場合、Ｔ１およびＴ２間に別の同期ポイントが存在し得るか否か判定を行なう。言い換えると、Ｔ１およびＴ２間の距離が非常に小さく、（インデックサの所望の粒度に基づいて）これらの間では他の同期ポイントをインデックス化できない場合、追加の同期ポイント・サンプルＴ１およびＴ２間に存在する可能性がある。これらは、所望のシーク位置Ｔにより近いが、インデックサの粒度が十分でなく追加のインデックス・エントリを収容できなかったために単にインデックスから省略されたのである。
【０１４６】
したがって、探索アルゴリズムを実行し、選択したストリームの内サンプルＴおよびＴ１間にあるサンプルを探索して、これらが実際に同期ポイントであるか否か判定を行なう。同期ポイントである場合、これらの同期ポイントは所望のシーク位置Ｔに時間的に接近しており、そのシーク位置よりも時間的に前にあることを意味する。これが真である場合、変数FILE OFFSET THIS STREAMを、識別した同期ポイントに対応する値にセットする。これをブロック７６８および７７０で示す。
【０１４７】
したがって、この処理の時点において、分析中のストリームに対する所望のファイル・オフセットは、Ｔ１、Ｔ２、またはＴ１およびＴ間の値のいずれかに選択されていることになる。次に、分析中のストリームに対して、シーク・アルゴリズムは、ストリーミング・プロセスにおいて後続のフィルタを要求し、バッファ１２から読み出したデータ・サンプルの内、変数FILE OFFSET THIS STREAMによって識別されたものよりも以前のタイム・スタンプを有するあらゆるデータ・サンプルを無視する。
【０１４８】
一旦変数FILE OFFSET THIS STREAMが得られたなら、その値が変数FILEOFFSETの現在値未満であるか否か判定を行なう。これが最初に選択したストリームである場合、その値は、無限大にセットされているFILEOFFSETの現在値未満である。しかしながら、これが第２、第３、またはそれ以降に選択されたストリームであった場合、分析中の現ストリームに対するファイル・オフセットは、変数FILEOFFSETに対する現在値よりも左にある（即ち、時間的に早い）場合にのみ、変数FILEOFFSETに対する値として用いられる。これは、バッファ１２４におけるシークに実際に用いられるシーク・ポイントを、バッファ内において十分左側に遠いポイントに移動させ、ストリームの個々のシーク要件を全て満たすという効果がある。
【０１４９】
次に、処理はブロック７５４に進み、追加のストリームを分析する必要があるか否か判定を行なう。必要がある場合、処理はブロック７５６に進む。必要がない場合、処理はブロック７５８に進む。ブロック７５８では、選択したリーダー・モジュールに、変数FILEOFFSETによって特定したサンプルをシークし、バッファ１２４のそのポイントからデータの流出を開始するように命令する。ブロック７７２において、各ストリームに対して、当該ストリームに対する所望の同期ポイント以前のストリーム・データを無視することを示す値をセットしたので、当該データが、当該所与のストリームに対して特定された（そして、変数FIEL OFFSET THIS STREAMによって特定された）最も早い同期ポイントと一致するか、またはそれより後でない限り、バッファ１２４から流出したデータは、所与のストリームに対してレンダリングされない。
【０１５０】
図２６のフロー図に対応する疑似コードの一実施形態を以下に明記する。
【０１５１】
【表１】

【０１５２】

【０１５３】
このように、図２６に示したアルゴリズムは、多数の問題を解決することが分かる。ファイルにおいて同期が外れている可能性があるストリームに関して、アルゴリズムは、あらゆるストリームの個々のシーク要件を満たすのに適した最大のファイル・オフセットをシークする。次いで、リーダー・モジュールは、そのポイントから流出を開始するが、各所与のストリーム毎に実際にプレイすべき最初のサンプルよりも前の全てを欠落させる。同様に、正確なタイム・スタンプ（所望のシーク位置）を有する同期ポイントが存在しない場合、最も近い同期ポイントが左に寄り過ぎていない（過去に離れ過ぎていない）限り、所望のシーク位置よりも前で最も近い同期ポイントにシーク位置をセットする。また、あるストリームがシーク・ポイントを含み、他のストリームがシーク・ポイントを含まない場合もあるので、シーク・ポイントを有さないストリーム内のあらゆるサンプルを適当なシーク・ポイントと見なす。最後に、全てのシーク・ポイントをインデックス化する訳ではないので、シーク・アルゴリズムは最初に所望のシーク位置前後で最も近いインデックス化シーク・ポイントを求め、次いでこれらインデックス化したポイント間の差を調べ、これらの間に同期ポイントが存在するか否か判定を行なう。存在する場合、所望のシーク位置よりも左側にあるサンプルを読み取り、追加の同期ポイントを摘出する。
【０１５４】
以上、好適な実施形態を参照しながら本発明について説明したが、発明の精神および範囲から逸脱することなく、形態および詳細において変更が可能であることを当業者は認めよう。
【図面の簡単な説明】
【図１】 図１は、本発明のための第１の例示的環境のブロック図。
【図２】 図２は、本発明のための第２の例示的環境のブロック図。
【図３】 図３は、モバイル・デバイスの透視図。
【図４】 図４は、本発明のための第３の例示的環境のブロック図。
【図５】 図５は、ストリーミング情報を処理するためのシステム。
【図６】 図６は、ディレイ・フィルタのブロック図。
【図７】 図７は、このフィルタ内のサーキュラ・バッファとのインターフェースを示すディレイ・フィルタ１１２のブロック図。
【図８】 図８は、直線のタイム・ラインに沿ったサーキュラ・バッファ１２４を示す図。
【図９】 図９Ａおよび図９Ｂは、併せて、本発明の１実施形態による同期アルゴリズムのライト部分のためのフローチャートを形成する。
【図１０】 図１０は、サーキュラ・バッファ内のテール・ポインタ変数の進行を示す図。
【図１１】 図１１Ａおよび図１１Ｂは、併せて、本発明の１実施形態による同期アルゴリズムのリード部分のためのフローチャートを示す。
【図１２】 図１２は、リーダー・モジュールがライタ・モジュールを追い抜いたときのサーキュラ・バッファの例を示す図。
【図１３】 図１３は、状態レジスタを示す図であり、この状態レジスタは、各データ・チャンネルに対し、このチャンネルの現在の状態においてどのユーザが許可されているかあるいは禁止されているかを明記するために維持される。
【図１４】 図１４は、図１３のユーザ操作フィールドＵＯＰ０〜ＵＯＰ１０に対応するユーザ操作の例をリストしたテーブル。
【図１５】 図１５は、ユーザ操作要求に応答してアプリケーションがコールするソフトウエア・オブジェクトのフローチャート。
【図１６】 図１６は、図１３に示した状態レジスタのユーザ操作ビットを維持する際にディレイ・フィルタが実行するステップを示すフローチャート。
【図１７】 図１７は、データ・ブロックの模式的表現である。
【図１８】 図１８は、データ・ブロックの第１のシーケンスの模式的表現である。
【図１９】 図１９は、データ・ブロックの第２のシーケンスの模式的表現である。
【図２０】 図２０は、本発明によるシステムの別の実施形態のブロック図。
図２０Ａは、フィルタ・グラフの１例のブロック図。
【図２１】 図２１Ａ〜図２１Ｄは、ストリーム分析を示すブロック図。
【図２２】 図２２は、ストリーム分析を示すブロック図
【図２３】 図２３Ａ〜図２３Ｃは、ストリーム分析を示すブロック図。
【図２４】 図２４は、インデックス動作を示すフロー図。
【図２５】 図２５は、データ・バッファの一部分の図。
【図２６】 図２６は、シーク動作を示すフロー図。

Claims (6)

1. ストリーミング情報を処理し、境界によって規定された複数の区分領域を備えるサーキュラ・バッファ内に格納するためのプロセッサ実装方法であって、
   ストリーミング情報のソースからストリーミング情報を受け取るステップと、
   データ・ブロックを形成するステップであって、各データ・ブロックが、
   前記データ・ブロックのサイズを示す第１データ・ブロック・サイズ・フィールドと、
   前記データ・ブロックのサイズを示す第２データ・ブロック・サイズ・フィールドと、
   前記第１データ・ブロック・サイズ・フィールドおよび前記第２データ・ブロック・サイズ・フィールドとで境界された間に設けられたペイロード・フィールドと、
   を含む、データ・ブロックを形成するステップと、
   区分領域を部分的に満たすまで、少なくとも１つのデータ・ブロックを前記サーキュラ・バッファに書き込むステップと、
   を含むことを特徴とする方法。
2. 請求項１に記載の方法において、各データ・ブロックが、前記ストリーミング情報のソースを示す識別フィールドを、さらに含み、前記方法が、
   非ストリーミング情報を示すフィールドと、前記区分領域内の残余空間の関数であるサイズとを有する、少なくとも１つのパディング・ブロックを生成するステップと、
   前記パディング・ブロックを前記サーキュラ・バッファに書き込むステップと、
   をさらに含むことを特徴とする方法。
3. 請求項２に記載の方法において、前記パディング・ブロックを書き込むステップは、前記サーキュラ・バッファ内において、境界に隣接して前記パディング・ブロックを書き込むステップを含むことを特徴とする方法。
4. 請求項１から３のいずれかに記載の方法において、前記データ・ブロックが可変サイズであることを特徴とする方法。
5. 請求項１から４のいずれかに記載の方法において、
   前記データ・ブロックの各々が、続くデータ・ブロックのロケーションを示す第１ポインタ・フィールドと、以前のデータ・ブロックのロケーションを示す第２ポインタ・フィールドとを含み、
   前記形成するステップが、前記ポインタ・フィールドの各々に対してポインタ・データを確認するステップを含む
   ことを特徴とする方法。
6. 請求項１から４のいずれかに記載の方法において、
   前記データ・ブロックが、前記第１データ・ブロック・サイズ・フィールドを含むヘッダ部を有し、
   前記ヘッダ部が、次のデータ・ブロックへのポインタを備えるプレフィックス・フィールドを有し、
   前記データ・ブロックが、前記第２データ・ブロック・サイズ・フィールドを含む後端部を有し、
   前記終端部が、前のデータ・ブロックに対するポインタを備えるサフィックス・フィールドを有する、
   ことを特徴とする方法。

Images