JP2018181324A - フォーマット独立メディア・ファイル・インデックシング - Google Patents

Abstract

【課題】メディア・ファイルにおけるワークフローの素早いターンアラウンドを提供する。【解決手段】メディア・ファイル・インデックシング・サービスは、メディア・ファイル自体の外部にある位置に、メディア・ファイル・インデックスを維持し、メディア・ファイルがキャプチャされ共有ストレージに転送されていくに連れて、増分的に構築される。クライアント・システムは、共有ストレージに書き込まれた後に、メディア・ファイル内におけるメディア・エレメントの各メディア・ファイル部分における位置に関する情報を含む生メッセージを受信するか、またはメディア・ファイルに対する変更を示し、関連する位置情報を含まないリファイン・メッセージを受信する。そして、ファイル・キャプチャの間に、特定のメディア・エレメントを求めて、インデックス・サービスによって維持されるインデックスに問い合わせ、キャプチャ同時編集ワークフローを可能にする。【選択図】図１

Description

従来技術

[0001] メディア・ファイルは、一般に、それらの内部にインデックスを含む。インデックスは、ファイル内部における個々のエレメントの位置に関する情報を提供する。ビデオ・ファイルの場合、インデックスは、ファイル内部における個々のビデオ・フレームの位置を示し(provide)、オーディオ・ファイルの場合、インデックスは、ファイル内部における個々のオーディオ・サンプルの位置を示す。この情報が要求されるのは、例えば、メディア処理または編集アプリケーションが特定の部分またはクリップをメディア・ファイルから読み取ることを必要とするときである。インデックスを引用することによって、アプリケーションはクリップの位置を突き止め、再生またはその他の目的のためにそれを引き出すことができる。エレメントの各々が固定サイズを有するファイルでは、メディア・ファイル内におけるその連続位置を知ることによって、特定のエレメントを突き止めることができるであろう。しかしながら、最近のメディア・ファイルは、特にビデオ・ファイルにおいて、可変サイズのエレメントを含むことが多く、各フレームのサイズは、それが圧縮される度合いに依存し、および／またはフレーム間圧縮技法を伴うときには他のフレームに対するその依存性に依存する。このようなファイルでは、各フレームの位置に関する情報に加えて、インデックスはそのフレームの他のフレームに対する依存性についての情報も含む。

[0002] インデックスを有する種々のビデオ・ファイル・フォーマットにおいて、インデックスは、ファイルの終端に配置されるか、またはファイルにわたって分散されたセクション内に配置されるか、またはファイルの先頭において確保された空間に配置され、ファイル・キャプチャまたは転送の間に周期的に更新される。これらのフォーマットの各々において、インデックスは、ビデオ・ファイル全体が現れる(present)まで利用可能でないか、またはファイルが完了する前に部分的に利用可能になるが、レイテンシ、処理コストの増大という代償を払うことになり、そうしないのであれば望ましくないフォーマット、例外ワークフローを使用する必要性や、エラーの危険性が生じる。

[0003] ワークフローの素早いターンアラウンド(turnaround)が増々尊重されるに連れて、メディア編集者にとって、ファイルが完全にキャプチャされる前に、または彼らのメディア処理アプリケーションにアクセス可能なストレージに完全に転送される前に、ビデオ・ファイルを使用して作業できることが必須となっている。これは、特に、キャプチャに長時間かかるファイル、例えば、生のスポーツ競技のファイルには重要であり、またはファイルが大きく利用可能な帯域幅で転送するには時間がかかる場合にも重要である。したがって、素早い「転送同時編集」（ＥＷＴ：edit while transfer）ワークフローを効果的にサポートすることができ、このようなファイルが編集または保管システムに完全に書き込まれるまたは転送される前に、このようなファイルに対して作業することを可能にするシステムおよび方法が求められている。

[0004] 概して言うと、本明細書において説明する方法、システム、およびコンピュータ・プログラム製品は、キャプチャ同時編集ワークフローを容易にするメディア・ファイル・インデックス・サービスを提供する。

[0005] 概して言うと、１つの形態において、メディア・ファイルのインデックスを維持する方法は、第１システムにおいて、メディア・ファイルが受信されることの指示を受信するステップと、第２システムにおいてメディア・ファイルのインデックスを作るステップとを含む。メディア・ファイルの複数の部分の各部分に対して、第１システムは、前記部分を受信するステップと、共有メディア記憶システムに格納するために、前記部分を共有メディア記憶システムに送るステップと、受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を含む生メッセージを、メッセージ・ブローカ・システムに送るステップとを実行する。メッセージ・ブローカ・システムは、生メッセージを受信するステップと、生メッセージをメッセージ・バスにおいてブロードキャストするステップとを実行する。第２システムにおいて、生メッセージをメッセージ・ブローカ・システムから受信するステップと、受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を、インデックスに追加するステップとを含む。

[0006] 種々の実施形態は、以下の特徴の内１つ以上を含む。メディア・ファイルの複数の部分の各々に含まれるデータの量が、第１システムのファイル・システム・キャッシュの記憶容量に対応する。メディア・ファイルがビデオ・ファイルであり、複数のメディア・エレメントの各メディア・エレメントが、ビデオ・ファイルのビデオ・フレームである。メディア・ファイルがオーディオ・ファイルであり、複数のメディア・エレメントの各メディア・エレメントがオーディオ・ファイルのオーディオ・サンプルである。受信した生メッセージをリファイン・メッセージに変換するステップであって、リファイン・メッセージが、メディア・ファイルが変更されており、受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を含まないという通知を含む、ステップと、リファイン・メッセージをメッセージ・ブローカに送るステップとを実行する。メッセージ・ブローカは、メッセージ・バスを介してリファイン・メッセージを受信およびブロードキャストするステップを実行する。第３システムが、メッセージ・バスおよび共有ストレージに接続され、第３システムが、メッセージ・ブローカによってブロードキャストされた生メッセージを受信するステップと、メディア・ファイルの受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を使用して、共有ストレージから、複数のエレメントの内メディア・ファイルの受信した部分を含む１つ以上を引き出すステップと、第３システムにおいて実行するメディア編集アプリケーションのユーザが、複数のエレメントの内引き出した１つ以上を含むメディア・ファイルの部分を視認および編集することを可能にするステップとを実行する。第３システムが、メッセージ・バスおよび共有ストレージに接続され、第３システムが、メッセージ・ブローカから生メッセージを受信するように構成され、共有ストレージから以前に引き出したことがないメディア・ファイルのエレメントを要求する。更に、第３システムは、要求したエレメントが共有ストレージから入手可能か否かを指定する情報を、第３システムが以前に受信した生メッセージから得られる(has)か否か判定するステップと、要求したエレメントが共有ストレージから入手可能であるという情報を、第３システムが、以前に受信した生メッセージから得られる場合、メディア・ファイル内における要求したエレメントの位置を定める情報を使用して、要求したエレメントを共有ストレージから引き出すステップと、要求したエレメントが共有ストレージから入手可能であるという情報を、第３システムが以前に受信した生メッセージから得られない場合、インデックスが要求したエレメントのエントリを含むか否か判定するために、第２システムにクエリを発し、インデックスが要求したエレメントのエントリを含む場合、要求したエレメントについての位置情報をインデックスから引き出し、位置情報を使用して要求したエレメントを共有ストレージから引き出すステップとを実行する。第３システムが、第２システムから、インデックスが要求したエレメントのエントリを含まないという応答を受けた場合、第３システムのディスプレイ上に、要求したエレメントが未だ入手可能でないという指示を表示するステップを含む。第３システムが、メッセージ・バスおよび共有ストレージに接続され、第３システムが、リファイン・メッセージをメッセージ・ブローカから受信するように構成され、以前に共有ストレージから引き出したことがないメディア・ファイルのエレメントを要求する。更に、インデックスが要求したエレメントのエントリを含むか否か判定するために第２システムにクエリを発し、インデックスが要求したエレメントのエントリを含む場合、要求したエレメントについての位置情報を引き出し、要求したエレメントを共有ストレージから引き出すステップと、第３システムが、第２システムから、インデックスが要求したエレメントのエントリを含まないという応答を受けた場合、要求したエレメントが共有ストレージに存在すると予測されるまで待った後、インデックスが要求したエレメントのエントリを含むか否か判定するために、第２システムに第２クエリを発するステップと、インデックスが要求したエレメントのエントリを含む場合、インデックスから要求したエレメントについての位置情報を引き出し、位置情報を使用して、要求したエレメントを共有ストレージから引き出すステップとを含む。いつ要求したエレメントが存在すると予測されるかに関する情報は、第３システムによって受信される生メッセージ内に含まれる。いつ要求したエレメントが存在すると予測されるかに関する情報は、第３システムによって受信されるリファイン・メッセージ内に含まれる。第３システムが、メッセージ・バスおよび共有ストレージに接続され、第３システムが、リファイン・メッセージをブローカから受信するように構成され、共有ストレージから以前に引き出されたことがないメディア・ファイルのエレメントを要求し、要求したエレメントが、メディア・ファイルの最後にキャプチャされたエレメントに時間的に近い、メディア・ファイル内における時間位置に対応する。更に、第３システムが、リファイン・メッセージを受信するステップと、リファイン・メッセージを受信したことに応答して、インデックスが要求したエレメントのエントリを含むか否か判定するために、第２システムにクエリを発し、インデックスが要求したエレメントのエントリを含む場合、インデックスから要求したエレメントについての位置情報を引き出し、位置情報を使用して要求したエレメントを共有ストレージから引き出すステップとを含む。

[0007] 概して言うと、他の形態において、インデックシング・システムは、コンピュータ読み取り可能命令を格納するメモリと、このメモリに接続されたプロセッサと、
を含み、プロセッサがコンピュータ読み取り可能命令を実行すると、インデックシング・システムに、メディア・ファイルのインデックスを維持する方法を実行させる。この方法は、メディア・ファイルを共有ストレージに書き込む書き込みシステムによって、メディア・ファイルが受信されることになっているという指示を受信したことに応答して、インデックシング・システムにおいてメディア・ファイルのインデックスを作るステップと、書き込みシステムによって受信されるメディア・ファイルの複数の部分の各々について、メッセージ・バスを介してメッセージ・ブローカから生メッセージを受信するステップであって、生メッセージが、メッセージ・ブローカによって書き込みシステムから受信され、生メッセージが、メディア・ファイルの受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を含む、ステップと、メディア・ファイルの受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を、インデックスに追加するステップとを含む。

[0008] 種々の実施形態は、以下の特徴の内１つ以上を含む。受信した生メッセージをリファイン・メッセージに変換するステップであって、リファイン・メッセージが、メディア・ファイルが変化し、受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を含まないという通知を含む、ステップと、リファイン・メッセージをメッセージ・バスを介してブロードキャストするために、リファイン・メッセージをメッセージ・ブローカに送るステップとを含む。メディア・ファイルの内指定された１つ以上のエレメントについての、メディア・ファイル内における位置情報を求めるクエリを読み取りシステムから受信したことに応答して、インデックスが、メディア・ファイルの内指定された１つ以上のエレメントのエントリを含む場合、メディア・ファイルの内指定された１つ以上のエレメントについての位置情報を含む応答を、読み取りシステムに供給するステップを含む。メディア・ファイルのインデックスを維持する方法は、更に、インデックスが、メディア・ファイルの内指定された１つ以上のエレメントのエントリを含まない場合、メディア・ファイルの最後に受信したエレメントの時間位置に関する情報を含む応答を、読み取りシステムに供給するステップを含む。

[0009] 概して言うと、更に他の形態において、コンピュータ・プログラム製品は、コンピュータ・プログラム命令がエンコードされた非一時的コンピュータ読み取り可能媒体を含み、コンピュータ・プログラム命令が、インデックシング・システムによって処理されると、インデックシング・システムに、メディア・ファイルのインデックスを維持する方法を実行させる。この方法は、メディア・ファイルを共有ストレージに書き込む書き込みシステムによって、メディア・ファイルが受信されることになっているという指示を受信したことに応答して、インデックシング・システムにおいてメディア・ファイルのインデックスを作成するステップと、書き込みシステムによって受信されるメディア・ファイルの複数の部分の各々について、メッセージ・バスを介して、生メッセージをメッセージ・ブローカから受信するステップであって、生メッセージが書き込みシステムからメッセージ・ブローカによって受信され、生メッセージが、メディア・ファイルの内受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を含む、ステップと、メディア・ファイルの受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報をインデックスに追加するステップとを含む。

[0010] 種々の実施形態は、以下の特徴の内１つ以上を含む。受信した生メッセージをリファイン・メッセージに変換するステップであって、リファイン・メッセージが、メディア・ファイルが変化し、受信した部分を含む複数のメディア・エレメントのメディア・ファイル内における位置を定める情報を含まないという通知を含む、ステップと、リファイン・メッセージをメッセージ・バスを介してブロードキャストするために、リファイン・メッセージをメッセージ・ブローカに送るステップとを含む。メディア・ファイルの内指定された１つ以上のエレメントについての、メディア・ファイル内における位置情報を求めるクエリを読み取りシステムから受信したことに応答して、インデックスが、メディア・ファイルの内指定された１つ以上のエレメントのエントリを含む場合、メディア・ファイルの内指定された１つ以上のエレメントについての位置情報を含む応答を、読み取りシステムに供給するステップを含む。インデックスが、メディア・ファイルの内指定された１つ以上のエレメントのエントリを含まない場合、メディア・ファイルの最後に受信したエレメントの時間位置に関する情報を含む応答を、読み取りシステムに供給するステップを含む。

図１は、メディア・ファイル・インデックスをメディア・ファイルの外部に維持するためのシステムを示す上位図である。 図２は、先行技術のメディア・ファイルのインデックスの図である。 図３は、メディア・ファイルの一部が共有ストレージに書き込まれるときに、図１に示すシステムによって実行されるステップの上位流れ図である。 図４は、リーダ・システムが生のインデックス関係メッセージに登録されている(subscribe)間に、図１のリーダ・システムがメディア・ファイルからのエレメントを要求するときに実行されるステップの上位流れ図である。 図５は、リーダ・システムがリファイン・インデックス関係メッセージ(refined index-related messages)に登録されている(subscribe)間に、図１のリーダ・システムがメディア・ファイルからのエレメントを要求するときに実行されるステップの上位流れ図である。

[0016] インデックスされるメディア・ファイルは、３つのカテゴリの１つに該当する。第１に、インデックスはファイルの終端に配置される。このようなインデックスは、ファイル全体がキャプチャまたは転送されたときにのみ、ファイルに書き込むことができる。第２のカテゴリでは、インデックスはセクションに分割され、ファイル内の種々の位置に書き込まれる。このようなファイルにおけるインデックスは断片化されているので、特定のエレメントにアクセスする必要があるアプリケーションは、最初に、要求するエレメントの位置情報を含む(contain)インデックスのセクションを突き止め、次いで、この突き止めたセクション内でその情報を調べなければならない。第３のカテゴリでは、インデックス空間は、ファイル内の先頭(up-front)に確保され、ファイルがキャプチャされている間周期的に更新される。これは、前もってファイル長が分かっていないと柔軟性が低下する。何故なら、一旦確保された空間が消失した(expire)ならキャプチャは終了しなければならないからである。また、逆に、予期したよりも早くファイルが終了した場合（即ち、予測したよりもファイルが小さかった）、確保されたインデックス空間の一部は無駄になる。これらのインデックシング方法の各々は、レイテンシ、処理要件、または柔軟性の内１つ以上に関して欠点がある。

[0017] 本明細書において説明するシステムおよび方法は、メディア・ファイルのフォーマットには独立しており、レイテンシおよび処理要件を低減し、柔軟性を高める。更に、これらは、メディア・ファイルがキャプチャされ続けており、またはクライアントに転送され続けており、したがって不完全にある間であっても、クライアント・システムを使用する編集者が、メディア・ファイルにアクセスしそれを操作することを可能にする。このような状況は、長い時間期間に対応する大きなメディア・ファイルがキャプチャされている間に、発生する可能性がある。このようなメディアは、衛星フィードによって、あるいはカメラまたは１組のマイクロフォンのようなメディア・キャプチャ・デバイスから直接受信される場合もある。例には、スポーツ競技または芸術的演技のような生の行事、あるいはニュース・フィードが含まれ、これらは長時間(many minutes or hours)かかるかもしれない。ファイルが完了するまで待つ、即ち、スポーツ競技または芸術的演技が終了するまで待つのではなく、メディアがキャプチャされ続けている間に既にキャプチャされたファイルの部分に基づいて、あるいは競技または演技が終了した直後に、断片(pieces)を生成するために、編集者がこのファイルからのメディアを使用しなければならない場合もある。例えば、様々なパートがある生スポーツ競技において、編集者が、次のパートが開始する前に、休憩中に１つのパートのハイライトの大意を放映する用意をすることを望むとしてもよい。ニュース・フィードでは、編集者が、速報についての報告全体が入手可能になる前に、この速報の概要またはプレビューを作ることを望むとしてもよい。他の例として、キャプチャされたメディアから編集した抜粋を含むウェブ・ブロードキャストが、生行事の間に公表される(issue)としてもよい。

[0018] 説明するメディア・ファイル・インデックシング・システムの種々のコンポーネントの上位ブロック図を図１に示す。ライタ・システム１０２は、キャプチャされる過程にあるメディア、または１つのシステムから他のシステムに転送されているメディアを（メディア・エレメントとして、またはバイトのストリームとして）受信しているコンピュータ・システムである。本明細書では、メディア・キャプチャ・アプリケーションを参照してこのシステムの使用について説明するが、これはメディア転送にも同様に適用することができる。ライタ・システムは、マサチューセッツ州、BurlingtonのAvid Technology Inc.,から入手可能なＡｉｒＳｐｅｅｄ（登録商標）システムのような、ビデオ・サーバによって実現されてもよい。リーダ・システム１０４は、ライタ・システム１０２からキャプチャまたは転送されているメディア・ファイルを読み取っているコンピュータである。ライタ・システムは、取り込んだメディアの部分を増分的に(incrementally)共有ストレージ１０６に書き込み、メディアはメディア・ファイル１０８内に格納される。メディアがキャプチャされている間、共有ストレージに書き込まれる各増分部分(incremental portion)は、通常、直前の部分が共有ストレージに書き出されて以来書き込みシステムによってキャプチャされ受け入れられたメディアとなる。このような増分書き込み動作が完了すると、ライタ・システム１０２は、書き込まれた新たなフレームのオフセットに関する情報を含む生メッセージを、フレームについての記述情報と共に公開する(publish)。この生メッセージは、メッセージ・ブローカ１１０によって受信される。メッセージ・ブローカ１１０は、受信した生メッセージをブロードキャストする。この生メッセージは、生メッセージ・チャネルに登録されたシステムによって受信される。インデックス・サービス・システム１１２は、この生メッセージ・チャネルに登録されており、全てのブロードキャストされた生メッセージを受信する。インデックス・サービスは、ファイルに書き込まれた各エレメントのメディア・ファイル内における位置を指定するインデックス１１４を、メディア・ファイル１０８のために維持する。インデックス・サービスには低レイテンシが望ましいので、インデックス１１４は大抵の場合ＲＡＭに格納される。

[0019] 図２は、メディア・インデックスの例示的な構造の上位図である。インデックスにおけるエントリにはエレメント番号２０２がキーとして添付され(keyed)、各エントリはエレメントのバイト・オフセット２０４、エレメント・サイズ２０６、およびエレメントについての情報２０８を含む。図２は、ビデオ・ファイルのインデックスを示し、ビデオ・ファイルでは、エレメントはフレームであり、各エレメントについての情報は、フレーム間（ピクチャー・ベースのグループ）圧縮方式におけるＩ、Ｐ、またはＢのようなフレーム・タイプである。インデックス・サービス・システム１１２は、ライタ・システム１０２および／またはリーダ・システム１０４にローカルに配置され、ローカル・エリア・ネットワークによってこれらのシステムに接続されてもよい。他の実施形態では、インデックス・サービス・システムは、リモートであってもまたはクラウド内にあってもよく、インターネットによってライタおよびリーダ・システムに接続されてもよい。再度図１を参照すると、リーダ・システム１０４はメッセージ・バスにも接続されており、メッセージ・ブローカからメッセージを受信することができる。リーダ・システム１０４は、メディア・ファイル１０８からのメディアを要求するメディア編集アプリケーションを実行する。このようなメディア編集アプリケーションの例に、米国特許第５，２６７，３５１号、第５，３５５，４５０号、および第５，９３０，４４５号に部分的に記載されている、マサチューセッツ州、BurlingtonのAvid（登録商標）Technology, Inc.からのビデオ編集アプリケーションＭｅｄｉａ Ｃｏｍｐｏｓｅｒ（登録商標）がある。これらの特許をここで引用したことにより、その内容が本願にも含まれるものとする。オーディオ編集では、このようなメディア編集アプリケーションの例には、ディジタル・オーディオを記録、編集、および格納するためのソフトウェア・アプリケーションを引用する(refer to)ディジタル・オーディオ・ワークステーションがある。このようなディジタル・オーディオ・ワークステーションの例に、これもAvid Technology, Inc.からのＰｒｏ Ｔｏｏｌｓ（登録商標）がある。メディア編集アプリケーションは、クライアントにおいて、あるいはクライアント−サーバまたはクラウド・ベース環境においてローカルにホストされてもよい。

[0020] 図３は、ライタ・システム１０２がメディア・ファイルの一部を共有ストレージ１０６に書き込むとき（ステップ３０２）に行われるステップのシーケンスを示す上位流れ図である。書き込み動作を完了した後、ライタ・システムは生メッセージをメッセージ・ブローカ１１０に送る（ステップ３０４）。この生メッセージは、メディア・ファイルにおいて書き込まれた部分における各エレメントのバイト・オフセットを定める情報を含む。書き込まれるメディア・エレメントが各々一定サイズである実施形態では、生メッセージは、各エレメントの位置を個々に指定する代わりに、エレメント・サイズと、書き込まれたフレームのフレーム番号（または範囲）を指定すればよい。こうすると、生メッセージのサイズは短縮するが、受信システムにおいてソフトウェアの複雑さが高くなる。また、生メッセージは、エレメントについての何らかの記述的情報も含む。例えば、メディア・ファイルがビデオ・ファイルであり、ファイルを圧縮するためにフレーム間圧縮が使用されている場合、この記述的情報は、各フレームのタイプ、即ち、Ｉ、Ｐ、またはＢを指定することができる。

[0021] メッセージ・ブローカは、生メッセージを受信し、それをメッセージ・バスを介してブロードキャストする（ステップ３０６）。リーダ・システム１０４が生メッセージに登録されている場合、リーダ・システム１０４はメッセージを受信する（ステップ３０８）。インデックス・サービス・システム１１２は、生メッセージ・チャネルに登録されており、ブロードキャストされた生メッセージを受信する（ステップ３１０）。これは、メッセージが含む情報を使用して、メディア・ファイル・インデックスを作成し（メディア・ファイルが開かれている場合）、更新し、閉じる（メディア・ファイルが完成した場合）（ステップ３１０）。インデックスを更新するとき、メディア・ファイルに新たに追加されたエレメントについての位置情報がインデックス１１４に追加される。次いで、インデックス・サービス・システム１１２は、生メッセージのリファイン・バージョンを生成し、これをメッセージ・ブローカに送る（ステップ３１２）。メッセージ・ブローカは、リファイン・メッセージ(refined message)を受信し、これをメッセージ・バスにおいてブロードキャストする。リファイン・メッセージは、これらが導かれた生メッセージよりも少ない情報を含む。説明するシステムでは、リファイン・メッセージは、メディア・ファイルが開かれたか否か、修正されたか否か、または閉じられた否かに関する通知を含む。また、これは、ファイルに書き込まれた最新のエレメントの時間的位置に関する情報も含み、これはレコード・ヘッドの位置にほぼ対応する。必要に応じて、リファイン・メッセージはコール・バック情報(call back information)も含む。コール・バック情報は、リーダがクエリをインデックス・サービスに発するときに、このクエリが特定のリファイン・メッセージに関係することを指定するために使用することができる。リファイン・メッセージは、新たに書き込まれたメディア・ファイル・エレメントの位置情報を含まない。リファイン・メッセージは生メッセージよりも少ない情報を含むので、メッセージ・バスを介したこれらのブロードキャストがネットワークに負わせる負荷は、生メッセージのブロードキャストよりも少ない。

[0022] これより、（ｉ）リーダ・システム１０４が生メッセージ・チャネルに登録されている場合、および（ｉｉ）リファイン・メッセージ・チャネルに登録されている場合という２つの事例について、例示的な流れ図を説明する。前者の事例から始めると、図４は、生メッセージ・チャネルに登録されているリーダ・システムがメディア・ファイルからのエレメントを要求するときに行われるステップのシーケンスを示す上位流れ図である。要求されるエレメントは、ビデオ・ファイルからの１つ以上のビデオ・フレーム、またはオーディオ・ファイルからの１つ以上のサンプルであってもよい。このプロセスは、リーダ・システムがメディア・ファイルからのエレメントを要求するが、このメディア・ファイルが以前に共有ストレージから引き出されていないときに開始する（ステップ４０２）。このエレメントは、編集者がメディア・エレメントを編集または再生することを望む場合に要求されるのでもよい。リーダは、最初に、以前に受信された生メッセージから得られた情報をチェックして、共有ストレージにおける要求されたエレメントについての位置情報を有するか否か判定する（ステップ４０４）。このような情報がないということは、（ｉ）要求されたエレメントが未だ共有ストレージに書き込まれていないこと、または（ｉｉ）例えば、リーダ・システムが生メッセージに登録し始める前にブロードキャストされた場合、リーダ・システムはその情報を受信していないこと、または（ｉｉｉ）リーダ・システムはその情報を受信したが、リーダ・システムの記憶および処理容量によっては生メッセージのコンテンツの一部しか保持することができないために、それを保持していないことを示す可能性がある。あるシステムでは、以前に受信した通知が表に纏められていることや、通知の特定部分のみが保持されていることもある。例えば、編集者の対象領域がメディア・ファイル内における特定の時間位置にある場合、この対象領域付近の部分に関する通知は保持されるが、他の位置、例えば、遙かに早いまたは遅い位置からの通知は破棄されていることもある。

[0023] 以前に受信したメッセージからのインデックス情報の内リーダ・システムによって保持される量は、システムのユーザ・コンテキストに依存する。低レイテンシが優先される場合、リーダ・システムは、できるだけ多くのインデックス情報を保持して、必要とされるエレメントを引き出すためにインデックス・サービスにクエリを発する必要性によって発生する遅延を発生させないようにする。このような状況が生ずるのは、ビデオ・プログラムのクラフト編集(craft editing)の間に、編集者がメディアから正確に選択された部分を再生し、高い応答性が必要となるときである。作業が遅くなることは別にして、予期せぬレイテンシは、編集システムによって引き起こされた遅延による問題ではなく、メディア自体による問題であるかのように思われかねない。他のコンテキストでは、低レイテンシはさほど重要ではない。この状況では、リーダ・システムは、生メッセージにおいて受信したインデックス情報の一部のみを保持することによってメモリを保存することができ、またはリファイン・メッセージのみに登録し、新たなフレームが必要とされるときにだけ、インデックスに問い合わせてもよい。このようなコンテキストの例は、メディアがログに記録されている(log)ときに発生する。何故なら、これはほぼ正確であり短い遅延はプロセスには影響を及ぼさないからである。

[0024] 読み取りシステムが、以前に受信された生メッセージから、共有ストレージにおける要求されたエレメントの位置を含む情報を有することがわかった場合、このシステムはこのような情報を使用して、要求したエレメントを引き出す（ステップ４０６）。次いで、要求されここで引き出されたエレメントを含むメディア・ファイルの一部を編集または再生するために、リーダ・システムにおいて実行するメディア編集アプリケーションによって、この要求されたエレメントを使用することができる（ステップ４０８）。

[0025] リーダ・システムが、以前に受信した生通知から、要求したエレメントが入手可能であるという情報を有していない場合、リーダ・システムはインデックス・サービスに問い合わせる（ステップ４１０）。インデックス・サービスが、要求されたエレメントのエントリを含まない場合、リーダ・システムは、「メディア・キャプチャ実行中」というような指示をユーザに表示する（ステップ４１２）。また、インデックス・サービスは、最後に追加されたインデックス・エントリの現在の時間位置についての情報を戻すこともでき、この情報はレコード・ヘッドの位置に対する接近(approximation)を示す(provide)（ステップ４１２）。リーダ・システムは、レコード・ヘッドの位置に関する情報を、要求したエレメントの時間位置と比較することによって、共有ストレージにおいて、要求したエレメントがいつ入手可能になるか推定し、再度インデックス・サービスに問い合わせる（ステップ４１０）前にこの推定時間量だけ待つ（ステップ４１４）ことができる。インデックス・システムが、このクエリに対して、要求されたエレメントについての位置情報を含む応答で応答したとき（ステップ４１６）、リーダ・システムはこの位置情報をインデックス・サービスから受信し、要求したエレメントを共有ストレージから引き出す（ステップ４１８）。次いで、リーダ・システムにおいて実行するメディア編集アプリケーションを使用して、要求したエレメントを含むメディア・ファイルの部分を編集または再生することができる。（ステップ４０８）。

[0026] リーダ・システムが、新たに追加されたメディア・エレメントがメディア・ファイルに追加された時点における位置情報を必要としない場合、リファイン・メッセージに登録すればよく、これによってメッセージ・バスにおける不要なトラフィックを低減する。この状況は、編集者が読み取りシステムを使用して、既に共有ストレージに書き込まれているメディア・ファイルの一部において作業しており、それよりも後に追加されたメディアを必要としないときに、発生する場合がある。逆に、編集者が、しばらくの間キャプチャされることが予期されないメディアを編集または再生することを計画するときにも発生する場合がある。つまり、メディアが予期されるまで待つことができ、その後インデックス・サービスからのメッセージに注意を払えばよいときにも発生する場合がある。図５は、リーダ・システムがインデックス・サービスからのリファイン・メッセージに登録する（そして、生メッセージには登録しない）場合を示す上位流れ図である。このシーケンスは、リーダ・システムが、共有ストレージから未だ引き出していないメディア・ファイルのエレメントを要求するときに開始する（ステップ５０２）。リーダ・システムは、要求するエレメントのエントリがインデックス内に存在するか否か判定するために、インデックス・サービスに問い合わせる（ステップ５０４）。インデックスが、この要求したエレメントのエントリを含む場合、インデックス・サービスは、このクエリに対して、要求したエレメントについての位置情報で応答する。リーダ・システムは、インデックス・サービスから、この位置情報を含む応答を受け、これを使用して、共有ストレージから必要なエレメントを引き出す（ステップ５０６）、ここで、編集者はリーダ・システムにおいて実行するメディア編集アプリケーションを使用して、必要なエレメントを含むメディア・ファイルの部分を編集または再生することができる（ステップ５０８）。

[0027] リーダ・システムがインデックス・サービスに問い合わせたときに、必要とするエレメントがインデックス内に存在しない場合、この主旨の応答をリーダ・システムに、最後に追加されたフレームの時間位置に関する情報と共に送る。この情報は、レコード・ヘッドの位置にほぼ対応する。リーダ・システムは、２つの再生状態の内１つにある可能性がある。１つの状態では、編集者が、レコード・ヘッドに近接するメディアを使って作業をしており、恐らくは、メディアを受信しつつ再生および編集までも行っている。この場合、リーダ・システムは、このメディア・ファイルに対する更に他の変更はいずれも、共有ストレージにおいてメディア・ファイルに書き込まれつつあるメディアの最新部分に対応し、このメディアを要求することになるであろうと予測する。したがって、次のリファイン・メッセージを受信するまで待ち（ステップ５１０）、次いで別のクエリをインデックス・サービスに発する（ステップ５０４）。したがって、インデックス内には、必要なエレメントのエントリが存在することが予測され、更にリーダ・システムは処理を進めて、位置情報を引き出し、必要なエレメントを引き出し、編集者が必要なエレメントを視認または編集する処理を進めることを可能にする（ステップ５０６、５０８）ことができると予測される。他の再生状態では、編集者が、レコード・ヘッドよりもかなり先にあるメディアを使って作業することを望む。即ち、丁度説明したばかりの再生状態におけるような、レコード・ヘッドの近くにあるのではないメディアを使って作業することを望む。この場合、必要なエレメントは、しばらくの間キャプチャされず、共有ストレージに書き込まれないであろう。リファイン・メッセージは、最後にメディア・ファイルに書き込まれたエレメントの時間位置に関する情報を含むので、リーダ・システムは、この情報を、編集者が求めたメディアの時間位置と共に使用して、必要なエレメントがいつ共有ストレージに書き込まれるか推定することができる。次いで、リーダ・システムは、要求したエレメントは未だ入手可能でないことの指示をユーザに表示し、例えば、「メディア・キャプチャ実行中」という説明文を表示する（ステップ５１２）。繰り返してインデックス・サービスに無駄に問い合わせるのを避けるために、リーダ・システムは、要求したエレメントが共有ストレージに書き込まれるであろうと推定する時点まで待ち（ステップ５１４）、別のクエリをインデックス・サービスに発する（ステップ５０４）。推定が正確であれば、その時点で、インデックスは求められた位置情報を含み、この位置情報がリーダ・システムに戻され、次いでリーダ・システムは要求したエレメントを共有ストレージから引き出し（ステップ５０６）、リーダ・システムにおいてメディア編集アプリケーションを使用する編集者が、必要なエレメントを含むメディア・ファイルの部分を編集または再生することを可能にする（ステップ５０８）。リーダの推定が不正確であった場合、リーダは、失敗したクエリにおいて戻された情報に基づいて、クエリをインデックスに再び発する新たな時点を推定し直すことができる。新たなフレームが到達するまで待つ間に、リーダ・システムは、既にわかっており共有ストレージに格納されているメディア・エレメントで編集者に作業させるために、並行して作業し続けることができる。

[0028] 記録および編集が進むに連れて、図４および図５に示すステップのシーケンスが繰り返され、リーダのエントリ・ポイント（ステップ４０２、５０２）が繰り返し呼び出される。

[0029] インデックス・サービスは、キャプチャの間、複数のファイルをサービスすることができる。共有ストレージに書き込まれる各メディア・ファイルは、それ自体のライタおよびリーダによって処理され、以上で説明したのと同じライタ・システム（１０２）およびリーダ・システム（１０４）において実行する異なるプロセスとして実現することができる。ライタ・システムおよびリーダ・システムを参照して以上で説明したステップは、ライタ・システムおよびリーダ・システムにおいて実行するソフトウェア実装プロセスにも等しく当てはまる。インデックス・サービスは、ファイルの各々に別個のインデックスを維持する。共通使用の場合には、編集者が、１つ以上のビデオ・トラックと１つ以上のオーディオ・トラックとを含むメディア・プロジェクトを編集することを伴う。このような場合、複数のファイルに対するリーダ・プロセスは、ビデオ・トラックおよびオーディオ・トラックの各々に１つずつであり、リーダ・システムにおいて実行する１つのメディア処理アプリケーションにサービスする。

[0030] 本明細書において説明したインデックシング・サービスは、リーダがインデックスにアクセスできない、または不完全なファイル内に位置するインデックスを使ってしなければならない従来のシステムと比較して、様々な利点を提供する。第１の利点は、メッセージを受信したときの共有ストレージにおけるメディア・ファイルの状態に関する明確な情報が、リーダによって受信されることによって得られる。これは、リーダに、新たな到達したエレメントは何かに関して通知し続けるので、未だ存在しないエレメントを連続的に求めて時間を無駄にすることがない。書き込みプロセスにおいてエラーが発生した場合、何が起こっているかに関して、メッセージがリーダに通知し続ける。対照的に、メディア・ファイルを直接読み取ろうとするとき、リーダはエラーを受ける可能性があり、エラーの原因に関する情報を有することができない。この情報は、ネットワークの停止、信頼できないメディア・エレメントまたは部分的に書き込まれたメディア・エレメント、あるいはアーカイブからの再現中断の場合に発生することがあるような、不完全なファイル同期を示す可能性がある。このようなエラーを受けたとき、リーダ・システムは、エラー状態が解消し読み取りが再開できるようになるには、未知の時間期間待たなければならない。

[0031] 説明したインデックス・サービスの他の利点は、インデックスのフォーマット独立性である。リーダは、各メディア・ファイル・フォーマットの詳細を知る必要がなく、インデックス内に格納された情報のみを使用することによって、メディア・キャプチャの間にメディア・ファイル内のエレメントにアクセスすることができる。対照的に、リーダが、インデックスを含むファイルを直接読み取る場合、どこでインデックスを見つけるか知る必要があり、またはインデックスがセクションに分割されている場合は、インデックスの１つ以上の部分をどこで見つけるか知る必要がある。

[0032] 本明細書において説明した種々のシステムの種々のコンポーネントは、汎用コンピュータ・システムを使用するコンピュータ・プログラムとして実現することができる。このようなコンピュータ・システムは、通例、情報をユーザに表示する出力デバイス、および入力をユーザから受ける入力デバイスの双方に接続された主ユニットを含む。主ユニットは、一般に、相互接続メカニズムを介してメモリ・システムに接続されたプロセッサを含む。また、入力デバイスおよび出力デバイスも、相互接続メカニズムを介して、プロセッサおよびメモリ・システムに接続される。

[0033] １つ以上の出力デバイスをコンピュータ・システムに接続することができる。出力デバイスの例には、液晶ディスプレイ（ＬＣＤ）、プラズマ・ディスプレイ、陰極線管、ビデオ投影システムおよび他のビデオ出力デバイス、プリンタ、ネットワーク・インターフェース・デバイス、ケーブル・モデムを含む、低または高帯域幅ネットワークを介して通信するためのデバイス、およびディスクまたはテープのような記憶デバイスが含まれるが、これらに限定されるのではない。１つ以上の入力デバイスをコンピュータ・システムに接続することができる。入力デバイスの例には、キーボード、キーパッド、トラック・ボール、マウス、ペンおよびタブレット、タッチスクリーン、カメラ、通信デバイス、およびデータ入力デバイスが含まれるが、これらに限定されるのではない。本発明は、コンピュータ・システムと組み合わせて使用される特定の入力または出力デバイスにも、本明細書において説明したものにも限定されない。

[0034] コンピュータ・システムは、コンピュータ・プログラミング言語、スクリプティング言語、またはアセンブリ言語ですら使用してプログラミング可能な汎用コンピュータ・システムであってもよい。また、コンピュータ・システムは、特殊にプログラミングされた、特殊目的ハードウェアであってもよい。汎用コンピュータ・システムでは、プロセッサは、通例、市販のプロセッサである。また、汎用コンピュータは、通例、オペレーティング・システムを有する。オペレーティング・システムは、他のコンピュータ・プログラムの実行を制御し、スケジューリング、デバッギング、入力／出力制御、アカウンティング、コンパイル、ストレージ割り当て、データ管理およびメモリ管理、ならびに通信制御および関連サービスを行う。コンピュータ・システムは、ローカル・ネットワークおよび／または、インターネットのような、ワイド・エリア・ネットワークに接続することもできる。接続されたネットワークは、コンピュータ・システムにおよびコンピュータ・システムから、コンピュータにおける実行のためのプログラム命令を転送することができ、ビデオ・データ、静止画像データ、またはオーディオ・データのようなメディア・データ、メタデータ、メディア組成(composition)についての見直しおよび承認情報、メディア表記(annotation)、ならびに他のデータを転送することができる。

[0035] メモリ・システムは、通例、コンピュータ読み取り可能媒体を含む。この媒体は、揮発性または不揮発性、書き込み可能または書き込み不可能、ならびに／あるいは書き換え可能または書き換え不可能であってもよい。メモリ・システムは、通例、データを二進形態で格納する。このようなデータは、マイクロプロセッサによって実行されるアプリケーション・プログラム、またはアプリケーション・プログラムによって処理されるためにディスクに格納される情報を定めることができる。本発明は、特定のメモリ・システムに限定されることはない。時間ベース・メディアを磁気、光、またはソリッド・ステート・ドライブに格納すること、およびこれらのドライブから入力することができる。これらのドライブは、ローカル・ディスクまたはネットワーク接続ディスクのアレイを含んでもよい。

[0036] 本明細書において説明したようなシステムは、ソフトウェア、ハードウェア、ファームウェア、またはこれら３つの組み合わせで実現することができる。システムの種々のエレメントは、個々にまたは組み合わせて、１つ以上のコンピュータ・プログラム製品として実現することができ、コンピュータ・プログラム命令は、コンピュータによる実行のために、コンピュータ読み取り可能媒体に格納されるか、あるいは接続されたローカル・エリアまたはワイド・エリア・ネットワークを介してコンピュータ・システムに転送される。プロセスの種々のステップは、このようなコンピュータ・プログラム命令を実行するコンピュータによって実行することができる。コンピュータ・システムは、マルチプロセッサ・コンピュータ・システムであってもよく、またはコンピュータ・ネットワークを介して接続された複数のコンピュータを含んでもよい。本明細書において説明したコンポーネントは、コンピュータ・プログラムの別個のモジュールであってもよく、または別個のコンピュータにおいて動作可能であってもよい、別個のコンピュータ・プログラムでもよい。これらのコンポーネントによって生成されたデータは、メモリ記憶システムに格納することができ、または搬送波信号のような種々の通信媒体によって、コンピュータ・システム間で送信することができる。

[0037] 以上実施形態例について説明したが、以上のことは限定ではなくて例示に過ぎず、一例として紹介しただけであることは、当業者には明白なはずである。数多くの変更や他の実施形態も、当業者の範囲内であり、本発明の範囲に該当すると考えられる。

Claims (20)

1. メディア・ファイルのインデックスを維持する方法であって、
   第１システムにおいて、メディア・ファイルが受信されることの指示を受信するステップと、
   第２システムにおいて前記メディア・ファイルのインデックスを作るステップと、
   前記メディア・ファイルの複数の部分の各部分に対して、
   前記第１システムが、
   前記部分を受信するステップと、
   共有記憶システムにおいて格納するために、前記部分を共有メディア記憶システムに送るステップと、
   前記受信した部分を含む複数のメディア・エレメントの前記メディア・ファイル内における位置を定める情報を含む生メッセージを、メッセージ・ブローカ・システムに送るステップと、
   を実行し、
   前記メッセージ・ブローカ・システムが、
   前記生メッセージを受信するステップと、
   前記生メッセージをメッセージ・バスにおいてブロードキャストするステップと、
   を実行し、
   前記第２システムにおいて、
   前記生メッセージを前記メッセージ・ブローカ・システムから受信するステップと、
   前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を、前記インデックスに追加するステップと、
   を含む、方法。
2. 請求項１記載の方法において、前記メディア・ファイルの前記複数の部分の各々に含まれるデータの量が、前記第１システムのファイル・システム・キャッシュの記憶容量に対応する、方法。
3. 請求項１記載の方法において、前記メディア・ファイルがビデオ・ファイルであり、前記複数のメディア・エレメントの各メディア・エレメントが、前記ビデオ・ファイルのビデオ・フレームである、方法。
4. 請求項１記載の方法において、前記メディア・ファイルがオーディオ・ファイルであり、前記複数のメディア・エレメントの各メディア・エレメントが前記オーディオ・ファイルのオーディオ・サンプルである、方法。
5. 請求項１記載の方法であって、更に、
   前記第２システムが、
   前記受信した生メッセージをリファイン・メッセージに変換するステップであって、前記リファイン・メッセージが、前記メディア・ファイルが変更されており、前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を含まないことの通知を含む、ステップと、
   前記リファイン・メッセージを前記メッセージ・ブローカに送るステップと、
   を実行し、
   前記メッセージ・ブローカが、前記メッセージ・バスを介して前記リファイン・メッセージを受信およびブロードキャストするステップを実行する、方法。
6. 請求項１記載の方法であって、更に、前記メッセージ・バスおよび前記共有ストレージに接続された第３システムを含み、前記第３システムが、
   前記メッセージ・ブローカによってブロードキャストされた前記生メッセージを受信するステップと、
   前記メディア・ファイルの前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を使用して、前記共有ストレージから、前記複数のエレメントの内前記メディア・ファイルの受信した部分を含む１つ以上を引き出すステップと、
   前記第３システムにおいて実行するメディア編集アプリケーションのユーザが、前記複数のエレメントの内引き出した１つ以上を含む前記メディア・ファイルの部分を視認および編集することを可能にするステップと、
   を実行する、方法。
7. 請求項１記載の方法であって、更に、前記メッセージ・バスおよび前記共有ストレージに接続された第３システムを含み、前記第３システムが、
   前記メッセージ・ブローカから生メッセージを受信するように構成され、
   前記共有ストレージから以前に引き出したことがない前記メディア・ファイルのエレメントを要求し、
   更に、前記第３システムが、
   前記要求したエレメントが前記共有ストレージから入手可能か否かを指定する情報を、前記第３システムが以前に受信した生メッセージから得られるか否か判定するステップと、
   前記要求したエレメントが前記共有ストレージから入手可能であるという情報を、前記第３システムが以前に受信した生メッセージから得られる場合、前記メディア・ファイル内における前記要求したエレメントの位置を定める情報を使用して、前記要求したエレメントを前記共有ストレージから引き出すステップと、
   前記要求したエレメントが前記共有ストレージから入手可能であるという情報を、前記第３システムが以前に受信した生メッセージから得られない場合、前記インデックスが前記要求したエレメントのエントリを含むか否か判定するために、前記第２システムにクエリを発し、前記インデックスが前記要求したエレメントのエントリを含む場合、前記要求したエレメントについての位置情報を前記インデックスから引き出し、前記位置情報を使用して前記要求したエレメントを共有ストレージから引き出すステップと、
   を実行する、方法。
8. 請求項７記載の方法であって、更に、
   前記第３システムが、前記第２システムから、前記インデックスが前記要求したエレメントのエントリを含まないという応答を受けた場合、前記第３システムのディスプレイ上に、前記要求したエレメントが未だ入手可能でないという指示を表示するステップを含む、方法。
9. 請求項１記載の方法であって、更に、前記メッセージ・バスおよび前記共有ストレージに接続された第３システムを含み、前記第３システムが、
   リファイン・メッセージを前記メッセージ・ブローカから受信するように構成され、
   以前に共有ストレージから引き出したことがない前記メディア・ファイルのエレメントを要求し、
   更に、
   前記インデックスが前記要求したエレメントのエントリを含むか否か判定するために前記第２システムにクエリを発し、前記インデックスが前記要求したエレメントのエントリを含む場合、前記要求したエレメントについての位置情報を引き出し、前記要求したエレメントを共有ストレージから引き出すステップと、
   前記第３システムが、前記第２システムから、前記インデックスが前記要求したエレメントのエントリを含まないという応答を受けた場合、
   前記要求したエレメントが前記共有ストレージに存在すると予測されるまで待った後、前記インデックスが前記要求したエレメントのエントリを含むか否か判定するために、前記第２システムに第２クエリを発するステップと、
   前記インデックスが前記要求したエレメントのエントリを含む場合、前記インデックスから前記要求したエレメントについての位置情報を引き出し、前記位置情報を使用して、前記要求したエレメントを共有ストレージから引き出すステップと、
   を含む、方法。
10. 請求項９記載の方法において、いつ前記要求したエレメントが存在すると予測されるかに関する情報が、前記第３システムによって受信される生メッセージ内に含まれる、方法。
11. 請求項９記載の方法において、いつ前記要求したエレメントが存在すると予測されるかに関する情報が、前記第３システムによって受信されるリファイン・メッセージ内に含まれる、方法。
12. 請求項１記載の方法であって、更に、前記メッセージ・バスおよび前記共有ストレージに接続された第３システムを含み、前記第３システムが、
    リファイン・メッセージを前記ブローカから受信するように構成され、
    共有ストレージから以前に引き出されたことがない前記メディア・ファイルのエレメントを要求し、前記要求したエレメントが、前記メディア・ファイルの最後にキャプチャされたエレメントに時間的に近い、前記メディア・ファイル内における時間位置に対応し、
    更に、
    前記第３システムがリファイン・メッセージを受信するステップと、
    前記リファイン・メッセージを受信したことに応答して、前記インデックスが前記要求したエレメントのエントリを含むか否か判定するために、前記第２システムにクエリを発し、前記インデックスが前記要求したエレメントのエントリを含む場合、前記インデックスから前記要求したエレメントについての位置情報を引き出し、前記位置情報を使用して前記要求したエレメントを共有ストレージから引き出すステップと、
    を含む。
13. インデックシング・システムであって、
    コンピュータ読み取り可能命令を格納するメモリと、
    前記メモリに接続されたプロセッサと、
    を含み、前記プロセッサが、前記コンピュータ読み取り可能命令を実行すると、前記インデックシング・システムに、メディア・ファイルのインデックスを維持する方法を実行させ、前記方法が、
    メディア・ファイルを共有ストレージに書き込む書き込みシステムによって、前記メディア・ファイルが受信されることになっているという指示を受信したことに応答して、 前記インデックシング・システムにおいて前記メディア・ファイルのインデックスを作るステップと、
    前記書き込みシステムによって受信される前記メディア・ファイルの複数の部分の各々について、前記インデックシング・システムが、
    メッセージ・バスを介してメッセージ・ブローカから生メッセージを受信するステップであって、前記生メッセージが、前記メッセージ・ブローカによって前記書き込みシステムから受信され、前記生メッセージが、前記メディア・ファイルの前記受信した部分を含む複数のメディア・エレメントの前記メディア・ファイル内における位置を定める情報を含む、ステップと、
    前記メディア・ファイルの前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を、前記インデックスに追加するステップと、
    を含む、インデックシング・システム。
14. 請求項１３記載のシステムにおいて、メディア・ファイルのインデックスを維持する前記方法が、更に、
    前記受信した生メッセージをリファイン・メッセージに変換するステップであって、前記リファイン・メッセージが、前記メディア・ファイルが変化し、前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を含まないことの通知を含む、ステップと、
    前記リファイン・メッセージを前記メッセージ・バスを介してブロードキャストするために、前記リファイン・メッセージを前記メッセージ・ブローカに送るステップと、
    を含む、システム。
15. 請求項１３記載のシステムにおいて、メディア・ファイルのインデックスを維持する前記方法が、更に、
    前記メディア・ファイルの内指定された１つ以上のエレメントについての、前記メディア・ファイル内における位置情報を求めるクエリを読み取りシステムから受信したことに応答して、
    前記インデックスが、前記メディア・ファイルの内前記指定された１つ以上のエレメントのエントリを含む場合、前記メディア・ファイルの前記指定された１つ以上のエレメントについての位置情報を含む応答を、前記読み取りシステムに供給するステップを含む、システム。
16. 請求項１５記載のシステムにおいて、メディア・ファイルのインデックスを維持する前記方法が、更に、
    前記インデックスが、前記メディア・ファイルの前記指定された１つ以上のエレメントのエントリを含まない場合、前記メディア・ファイルの最後に受信したエレメントの時間位置に関する情報を含む応答を、前記読み取りシステムに供給するステップを含む、システム。
17. コンピュータ・プログラム製品であって、
    コンピュータ・プログラム命令がエンコードされた非一時的コンピュータ読み取り可能媒体を含み、前記コンピュータ・プログラム命令が、インデックシング・システムによって処理されると、前記インデックシング・システムに、メディア・ファイルのインデックスを維持する方法を実行するように命令し、前記方法が、
    メディア・ファイルを共有ストレージに書き込む書き込みシステムによって、前記メディア・ファイルが受信されることになっているという指示を受信したことに応答して、 前記インデックシング・システムにおいて前記メディア・ファイルのインデックスを作成するステップと、
    前記書き込みシステムによって受信される前記メディア・ファイルの複数の部分の各々について、
    メッセージ・バスを介して、生メッセージをメッセージ・ブローカから受信するステップであって、前記生メッセージが前記書き込みシステムから前記メッセージ・ブローカによって受信され、前記生メッセージが、前記メディア・ファイルの前記受信した部分を含む複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を含む、ステップと、
    前記メディア・ファイルの前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める情報を、前記インデックスに追加するステップと、
    を含む、コンピュータ・プログラム製品。
18. 請求項１７記載のコンピュータ・プログラム製品において、メディア・ファイルのインデックスを維持する前記方法が、更に、
    前記受信した生メッセージをリファイン・メッセージに変換するステップであって、前記リファイン・メッセージが、前記メディア・ファイルが変化し、前記受信した部分を含む前記複数のメディア・エレメントの前記メディア・ファイル内における位置を定める前記情報を含まないという通知を含む、ステップと、
    前記リファイン・メッセージを前記メッセージ・バスを介してブロードキャストするために、前記リファイン・メッセージを前記メッセージ・ブローカに送るステップと、
    を含む、コンピュータ・プログラム製品。
19. 請求項１７記載のコンピュータ・プログラム製品において、メディア・ファイルのインデックスを維持する前記方法が、更に、
    前記メディア・ファイルの内指定された１つ以上のエレメントについての、前記メディア・ファイル内における位置情報を求めるクエリを読み取りシステムから受信したことに応答して、
    前記インデックスが、前記メディア・ファイルの前記指定された１つ以上のエレメントのエントリを含む場合、前記メディア・ファイルの前記指定された１つ以上のエレメントについての位置情報を含む応答を、前記読み取りシステムに供給するステップを含む、システム。
20. 請求項１９記載のコンピュータ・プログラム製品において、メディア・ファイルのインデックスを維持する前記方法が、更に、
    前記インデックスが、前記メディア・ファイルの前記指定された１つ以上のエレメントのエントリを含まない場合、前記メディア・ファイルの最後に受信したエレメントの時間位置に関する情報を含む応答を、前記読み取りシステムに供給するステップを含む、システム。

Images