JP2009213167A - 連続的媒体フィードの継ぎ目のない再生を実現するための方法および装置 - Google Patents

Abstract

【課題】ビデオの連続的フィードを記憶させるための方法およびシステムを提供する。
【解決手段】内容データがより小さいファイル４０２−４１４のグループに記憶されている。より小さいファイルの各々がバッファ処理された内容データのサブセットを記憶している。図示する実施例では、ファイル４０２−４１２の各々が２時間に値する内容を記憶している。ファイル４１４は現在１時間の内容を記憶している。現在の挿入点はファイル４１４の最後である。ファイル４１４が２時間の内容に達すると、ファイル４１４は閉じられ、新しい内容ファイルが作られる。内容ファイルが古くなると、より古い内容ファイルが削除されて新しいファイルのためのディスク空間を空ける。再生中、ファイルは内容データがクライアントに送られるときにビデオポンプによって継ぎ目なく結合される。
【選択図】図４

Description

［関連出願］
この出願は、引用によりここに援用される、１９９７年１０月２２日付でDaniel Weaver、Mark A. PorterおよびDavid J. Pawsonにより出願された米国特許出願第０８／９５６，２６１号（代理人書類番号第３０１８−１００号）「媒体の同時のエンコードおよびタグ付けを行なうための方法および装置（“METHOD ANDAPPARATUS FOR CONCURRENTLY ENCODING AND TAGGING MEDIA”）」に関連する。

この出願はまた、引用によりここに援用される、１９９７年１０月２２日付でDaniel Weaver、Mark A. PorterおよびDavid J. Pawsonにより出願された米国特許出願第０８／９５６，２６３号（代理人書類番号第３０１８−１２８号）「インプログレスビデオフィードへの非順次アクセスのための方法および装置（“METHOD AND APPARATUS FOR NON-SEQUENTIAL ACCESS TO AN IN-PROGRESS VIDEO FEED”）」に関連する。

［発明の分野］
この発明はオーディオビジュアル情報を処理するための方法および装置に関し、特に、ライブコンテンツの流れにおいて表わされるオーディオビジュアル情報への非順次アクセスを与えるための方法および装置に関する。

近年、メディア産業は伝統的なアナログ技術を超えてその範囲を拡大してきた。オーディオ、写真、そして映画さえもが現在ではデジタル形式に記録または変換されている。製作物間の適合性を促進するために、標準形式が多くのメディア部門で開発されている。

おそらく期待されるように、デジタルビデオを見る人は、ビデオカセットレコーダ上のアナログビデオテープを見る際に楽しむような同じ機能をデジタルビデオの提供者から得ることを望む。たとえば、それを見る人々はビデオの前方への飛越し、後方への飛越し、早送り、早巻戻し、遅送り、遅巻戻しおよびフレームの停止を行なうことができるように望む。

デジタルビデオデータの非順次再生を与えるためにさまざまなアプローチが展開されてきた。デジタルビデオデータでは、非順次再生とは、エンコードされたフレームのすべてをそれらがエンコードされた正確な順序ではプレーしない再生動作を指す。たとえば、前方飛越し動作および早送り動作はいくつかのフレームがスキップされる点で非順次である。任意の速度での巻戻し動作は、巻戻し動作の間にフレームがエンコードされたシーケンスでプレーされない点で非順次である。

ここではタグベースのアプローチと呼ぶ、デジタルビデオデータの非順次再生を与えるあるアプローチが、引用によりここに援用する、１９９７年８月１９日付でPorter他に発行された米国特許第５，６５９，５３９号「デジタルオーディオビジュアル情報のフレームの正確なアクセスのための方法および装置（“Method and Apparatus for Frame Accurate Access of Digital Audio-visual Information”）」に説明されている。タグベースのアプローチによると、記憶されているデジタルビデオファイルが解析されて、ファイル内の個々のフレームに関する「タグ情報」を発生する。

具体的に、タグファイルは、デジタル表現をデコードするために用いられる１つ以上の
ステートマシンの状態に関する情報を含む。状態情報はオーディオビジュアル作品をエンコードするために用いられる特定の技術によって異なる。たとえばＭＰＥＧ−２ファイルでは、タグファイルはプログラムエレメンタリストリームステートマシン、ビデオステートマシンおよびトランスポート層ステートマシンの状態に関する情報を含む。

オーディオビジュアル作品の上演の間、デジタル表現からのデータがビデオポンプからデコーダへと送られる。タグファイル内の情報はオーディオビジュアル作品の上演の間に、シーク、早送り、早巻戻し、遅送りおよび遅巻戻し動作を行なうために用いられる。シーク動作が行なわれるのは、ビデオポンプに、デジタル表現の現在の位置からのデータ送信を停止させ、かつデジタル表現の新たな位置からデータ送信を開始させることによる。タグファイル内の情報はデータ送信を始めるべき新しい位置を決定するために検査される。ビデオポンプによって送信されるデータの流れが適用可能なビデオ形式との適合性を維持することを確実とするため、適切なヘッダ情報を含む接頭語データが新しい位置からのデータ送信の前にビデオポンプによって送信される。

早送り、早巻戻し、遅送りおよび遅巻戻し動作は、タグファイル内に含まれる情報と望ましい提示速度とに基づいてビデオフレームを選択し、かつ選択されたビデオフレームを表わすデータを含むデータストリームを発生することによって行なわれる。選択プロセスは、データが送られるべきチャネルのデータ転送速度と、フレームのフレームタイプと、最小埋込率と、デコーダ上でのバッファオーバフローの可能性とを含むさまざまな要因を考慮に入れる。接頭語データおよび接尾語データは、デコーダによって予期されるデータストリーム形式との適合性を維持するために、フレームごとにデータの前および後で送信されるデータストリームへと挿入される。

元のデジタルビデオストリームがタグ情報を発生するために解析させられるのに十分な時間が、元のデジタルビデオストリームが作り出されてからデジタルビデオストリームが見られるまでにある場合は、タグベースのアプローチはうまく作用する。しかしながら、デジタルビデオストリームが発生されている途中で見られる場合は、デジタルビデオストリームの解析は非実用的となる。デジタルビデオストリームをそれが到着したときに解析するのに必要な演算力は非常に高価であろう。他方、多くのタイプのビデオフィード（たとえば、スポーツイベント）が発生してから、このようなフィードが視聴者のために利用可能となるまでの待ち時間を延ばすことは容認可能とは考えられない。

ビデオストリームがその発生の完了前に見られ得る場合、このビデオストリームは「ライブフィード」と呼ばれる。実務レベルでは、非線形デジタルエディタが１人のユーザのためのライブフィードの場面を高速で見直すために用いられ得る。しかしながら、これらのシステムは多くのユーザを対象とはしておらず、それに容易には適合可能ではない。たとえば、１００名のユーザが同じライブフィードを見ているが異なる時にフィードを巻戻し、停止し、早送りすることを望めば、各ユーザが別個の非線形デジタルエディタを必要とするであろう。

ライブデジタルビデオストリームへの非線形アクセスを与えるのに関連した他の問題は、ユーザがまだ存在していないビデオストリームの部分へと早送りしようと試みるかもしれないことである。たとえば、実際にはまだ終わっていないゲームの最終スコアを見るために、視聴者はライブフィードを早送りしようとするかもしれない。デコーダがフリーズしたりビデオストリームが壊れたりしないことを確実とするように、このような状況を扱うための技術を提供することが望ましい。

以上に基づき、ライブデジタルビデオの不連続フレームを順次表示するための方法および装置を提供することが明らかに望ましい。さらに、各視聴者が非常に高価なハードウェ
アを動作させる必要のないようにライブデジタルビデオへのこのような非順次アクセスを与えることが望ましい。また、まだ存在していないライブデジタルビデオストリームの部分にアクセスしようとする試みに対する保護を与えることが望ましい。

ビデオの連続的フィードを記憶させるための方法およびシステムが提供される。この発明の一局面に従うと、連続的フィードはデジタルビデオ形式にエンコードされてデジタルデータストリームを生み出す。一連の内容ファイルが、（１）デジタルデータストリームを現在のファイルに記憶させるステップと、（２）現在のファイルが予め定められた条件を満たすと、現在のファイルとして新しいファイルを確立するステップとを繰返し行なうことによって生み出される。その一連の内容ファイルが予め定められた量よりも多い連続的フィードを含めば、一連の内容ファイルのうち最も古い内容ファイルが削除される。

この発明の他の局面に従うと、最も古い内容ファイルの削除はそれが現在アクセスされていれば遅延され得る。削除が遅延され得るのは、最も古い内容ファイルがもはやアクセスされなくなるか、またはそれがアクセスされていたという事実がなければ削除されていたであろうときからある量の時間が経過するまでである。

この発明の他の局面に従うと、デジタルデータストリームに含まれるフレームに関する情報を示すタグ情報が発生される。タグ情報はデジタルデータストリームの初めに対するフレームのタイミングを示すタイムスタンプを含む。初期時間値は、デジタルデータストリームの初めに対応する絶対時間を示す。

特定の絶対時間から再生を求めるクライアントからの要求が受取られると、初期時間値が相対時間を定めるために特定の絶対時間から減算される。タグ情報は相対時間に対応するデジタルデータストリームの場所を識別するために用いられる。デジタルデータストリームは次に、相対時間に対応するデジタルデータストリームの場所からクライアントに送信される。

この発明の実施例に従うビデオ配信システムを示すブロック図である。 ＭＰＥＧファイルの形式を示すブロック図である。 この発明の実施例に従う例示的タグファイルのブロック図である。 この発明の実施例に従うＭＰＥＧ−１ファイル内のフレームごとに発生されるタグ情報を示すブロック図である。 この発明の実施例に従うＲＡＩＤ誤り訂正技術を用いる記憶システムを示すブロック図である。 この発明の実施例に従うＲＡＩＤ誤り訂正技術とディスクストライピングとを組合せる記憶システムを示すブロック図である。 この発明に従う連続的フィードの内容を記憶させるために用いられる一連の内容ファイルを示すブロック図である。 古いタグファイル内のタグデータの期限切れに応答する、古いタグファイルから新しいタグファイルへのタグ情報の移行を示すブロック図である。

この発明は、同じ参照番号が同様の要素を示す添付の図面を参照して、限定的ではなく例示的に説明される。

ライブデジタルビデオストリームへの非順次アクセスを与えるための方法および装置を
説明する。以下の説明において、説明の目的のために、数多くの具体的な細部がこの発明の完全な理解を与えるために記載される。しかしながら、この発明がこれらの特定の細部なしで実現され得ることは当業者には明らかであろう。他の例では、この発明を不必要に不明確にすることを避けるために周知の構造および装置がブロック図の形式で示される。

機能概観
この発明の一局面に従うと、タグベースのアプローチをライブデジタルビデオフィードに適用することにかかわる困難が、入来するデジタルビデオストリームをリアルタイムで解析する必要をなくすことによって対処される。デジタルビデオストリームを解析することによってタグデータを発生する代わりに、ライブフィードをエンコードするためのユニットが、いかにデータがエンコードされたかについての情報を保持し、その情報をエンコードされたデータとともにビデオサーバに送信する。タグ情報は対応の内容とともにビデオサーバに到着するので、内容自体は解析される必要がない。

この発明の他の局面に従うと、ビデオサーバは、クライアントが受信された内容の終わりを越えてシークまたはスキャンできないことを確実とするよう構成される。内容の到着時間と内容のタグの到着時間との間には、いくらかの量のスキューがあるという事実のため、サーバは、タグが時期尚早に、すなわち、それらがサーバに利用可能な内容の終わりを越えさせるように、用いられないことを確実とするよう構成される。

例示的システム
図１は、ライブデジタルビデオフィードを配信し、それへの非順次アクセスを与えるための例示的オーディオビジュアル情報配信システム１００を示すブロック図である。オーディオビジュアル情報配信システム１００は一般にエンコーダ１０１、ビデオサーバ１０６、メディアデータ記憶装置（ＭＤＳ）１１２、データベース１１６、ストリームサーバ１１８、ビデオポンプ１２０およびクライアント１２２を含む。

エンコーダ
エンコーダ１０１はオーディオビジュアル入力を受取り、特定の形式に従ってオーディオビジュアル入力をエンコードするデータのデジタルストリームを発生する。数多くのビデオエンコード形式が開発されており、業界に周知である。たとえば、ＭＰＥＧ形式はＩＳＯ／ＩＥＣ １３８１８−１，２，３（ＭＰＥＧ−２）およびＩＳＯ／ＩＥＣ １１１７２−１，２，３（ＭＰＥＧ−１）という国際規格において詳細に説明されている。これらの規格（以下では「ＭＰＥＧ仕様」と呼ぶ）を説明する文書はISO/IEC Copyright Office Case Postale 56, CH 1211, Geneve 20, Switzerland）から入手可能である。特定の形式が説明の目的のためにここで引用され得るが、この発明は何らかの特定のデジタルストリーム形式に制限されない。

エンコーダ１０１はコーダ／デコーダ（ＣＯＤＥＣ）１０２およびマルチプレクサ（ＭＵＸ）１０４を含む。ＣＯＤＥＣ１０２は入力源からのビジュアルまたはオーディオビジュアル情報を圧縮されたデジタルデータに変換する。たとえば、ＣＯＤＥＣ１０２はフラクタル圧縮器またはＭＰＥＧ圧縮器であってもよい。説明の目的のために、ＣＯＤＥＣ１０２が捕捉するビデオソースはライブソースであり、その結果としてＣＯＤＥＣ１０２がリアルタイムに対して１Ｘでビデオをエンコードすると想定する。しかしながら、ビデオソースは代替的に、ＣＯＤＥＣ１０２がリアルタイムに対して任意の速度でエンコードする記憶されたビデオソースであってもよい。

ＭＵＸ１０４はＣＯＤＥＣ１０２によって発生された圧縮されたオーディオおよびビジュアル情報を多重化して、圧縮されたビデオストリームを発生する。圧縮されたビデオストリームでは、ビデオフレームを表わすデータとオーディオとがマージされ、エンコーダ
１０１によって支持される特定のデジタル形式に従って形式化される。マージプロセスの間に行なわれる具体的な動作は、用いられるエンコードのタイプに基づいて変化する。たとえば、マージプロセスは、ストリーム中でのデジタル化オーディオおよびビデオの部分の順序および配置を定め、ストリーム内のさまざまな点にメタデータを挿入することを含んでもよい。たとえば、メタデータはストリーム内での「パケット」の開始点および内容を識別するヘッダ情報の形を取ってもよい。ＭＵＸ１０４によって構成される圧縮されたオーディオビジュアル情報の流れは、通信チャネル１２８によってエンコーダ１０１からビデオサーバ１０６へと送信される。

制御情報
この発明の一局面に従うと、エンコーダ１０１はビデオストリームと並行して、通信チャネル１３０によってビデオサーバ１０６へと制御情報を送る。チャネル１３０によって送られる制御情報は、如何にエンコーダ１０１がビデオストリームを構成したかに関する具体的な情報を含む。制御情報はビデオストリームへの非順次アクセスを与えるためにストリームサーバ１１８によって用いられるタグデータを含む。具体的に、制御情報は、ビデオストリームにおいてエンコードされたさまざまなフレームのタイプ、長さおよび境界に関する情報と、圧縮比、ビット速度、ビデオサーバ１０６がビデオストリーム処理法を決定するために必要な他のタイプの情報を特定するヘッダ情報とを含んでもよい。

重要なことに、制御情報の発生に必要な付加的演算力は最小である。これは、ＭＵＸ１０４が内容ストリームの構成の間に既に情報のほとんどを発生しているためである。具体的に、ＭＵＸ１０４はＣＯＤＥＣ１０２からデジタルビデオおよびオーディオデータを配置し、カプセル生成を行なう（encapsulates）。ＭＵＸ１０４が内容をパッケージングするので、ＭＵＸ１０４はパッケージの内容とパッケージ間の境界とを知っている。

エンコーダとビデオサーバとの間の通信
ＣＯＤＥＣ１０２は一般にハードワイヤード回路において実現されるが、ＭＵＸ１０４は好ましくはプログラム制御回路、たとえば、メモリに記憶されている命令の特定のシーケンスを実行するようプログラムされた処理装置によって実現される。その結果、ＭＵＸ１０４は、ビデオサーバ１０６との通信を制御するソフトウェアライブラリに連結されており、かつそれを呼出す従来の多重化プログラムを実行する処理装置を含んでもよい。

エンコーダ１０１とビデオサーバ１０６との間で送信される全データが好ましくは信頼できる通信機構を用いて送られる。一実施例に従うと、通信チャネル１２８上のビデオ内容は簡単なバイトの流れとして扱われ、軽い信頼できるプロトコルにより送信される。たとえば、ＴＣＰが負荷の軽いネットワークでは十分である。通信チャネル１３０上の制御情報およびメタデータはより多くの複雑なデータタイプを含み、オブジェクト指向プロトコル、たとえば共通オブジェクト・リソース・ブローカー・アーキテクチャ・インターフェイス定義語（Common Object Resource Broker Architecture Interface Definition Language、“CORBA IDL”）によって送られる。

エンコーダ１０１とビデオサーバ１０６との間の通信はセッションで起こる。一実施例に従うと、セッションはＯＰＥＮ、ＳＥＮＤおよびＣＬＯＳＥの３段階で行なわれる。各段階の間に行なわれる動作は以下のとおりである。

ＯＰＥＮ−ビデオサーバ１０６がネットワークまたはディスク帯域幅またはディスク空間のために行なう必要がある準備が生じる。ビデオストリームデータ（「内容」）のためのパイプが作られる。

ＳＥＮＤ ＴＡＧＳおよびＳＥＮＤ ＤＡＴＡ−これらの読出は内容がエンコードされ
るときに複数回行なわれる。ビデオサーバ１０６は全内容を直ちにディスクに記憶させ、ファイル終了位置を更新する。タグは、付随する内容データが記憶されるまでメモリに保持される。タグはさらなる期間にわたって保持されて、そのタグへのシークが成功する、すなわち、ビデオポンプ１２０がデータを切らさないことを保証する。

ＣＬＯＳＥ−内容パイプが分解される。サーバ資源は解放され、内容サービスおよびクライアントはフィードが内容の通常の静的なものになったことを通知される。

エンコーダ１０１は並行して内容データおよび制御データを発生する。しかしながら、内容の特定の場所に関連した制御データが内容の特定の部分と同時にエンコーダ１０１によって発生されるとは限らない。たとえば、エンコーダ１０１は実際には、エンコーダ１０１が実際にフレームを並べる前に内容を並べる方法を決定する。これらの状況下では、フレームが並べられる方法を示す制御データが、そのフレームを含む内容データの前にエンコーダ１０１によって送信されるかもしれない。

ビデオサーバ
ビデオサーバ１０６はエンコーダ１０１からビデオストリームおよび制御データを受信し、データをＭＤＳ１１２に記憶させる。図示されるシステムでは、ビデオサーバ１０６はＭＰＥＧビデオストリームをＭＤＳサーバ１１０に送り、ＭＤＳサーバ１１０がＭＰＥＧビデオストリームをＭＰＥＧファイル１３４内に記憶させる。並行して、ビデオサーバ１０６はライン１３０によって受信された制御データから抽出されたタグ情報をＭＤＳサーバ１１０に送る。タグデータはディスク１１４上のタグファイル１３２に記憶される。ビデオサーバ１０６はまたタグデータを含む内容に関する情報をデータベース１１６に記憶させるために送る。

一旦タグデータがビデオサーバ１０６によって送信されると、ビデオポンプ１２０を含むシステム内の他のエンティティが、そのタグデータを用いてタグデータと関連した内容にアクセスしようと試みるかもしれない。したがって、ＭＤＳサーバ１１０へのタグデータの即座の送信が、たとえばタグデータが対応の内容データより前にビデオサーバ１０６に到着する場合のエラーを引起こすかもしれない。したがって、タグデータをＭＤＳ１１０に送る前に、ビデオサーバ１０６は、ビデオポンプ１２０のようなエンティティがタグデータ項目と関連した内容にアクセスすることが安全となるまで、タグバッファ１０８内の各タグデータ項目をバッファ処理する。内容データの早すぎる読出を避けるためのタグバッファ１０８の使用については以下により詳細に説明する。

例示的ＭＰＥＧファイル
デジタルオーディオビジュアル記憶形式は、圧縮されていようといまいと、さまざまな構造のステートマシンおよびパケットを用いる。ここに説明する技術はこのような記憶形式のすべてに当てはまる。この発明は特定のデジタルオーディオビジュアル形式に限定されないが、ＭＰＥＧ−２トランスポートファイル構造を例示の目的のために説明する。

図２ａを参照すると、ＭＰＥＧ−２トランスポートファイル１３４の構造がより詳細に示される。ＭＰＥＧファイル１３４内のデータはプログラムエレメンタリストリーム（「ＰＥＳ」）層、トランスポート層およびビデオ層の３層にパッケージングされる。これらの層についてはＭＰＥＧ−２仕様において詳しく説明する。ＰＥＳ層では、ＭＰＥＧファイル１３４はＰＥＳパケットのシーケンスからなる。トランスポート層では、ＭＰＥＧファイル１３４はトランスポートパケットのシーケンスからなる。ビデオ層では、ＭＰＥＧファイル１３４はピクチャパケットのシーケンスからなる。各ピクチャパケットはビデオの１フレームに対するデータを含む。

各ＰＥＳパケットはＰＥＳパケットの長さおよび内容を識別するヘッダを有する。図示する例では、ＰＥＳパケット２５０はヘッダ２４８と後続のトランスポートパケット２５１−２６２のシーケンスとを含む。ＰＥＳパケットの境界は有効トランスポートパケットの境界と一致する。各トランスポートパケットは１つのタイプのみのデータを含む。図示する例では、トランスポートパケット２５１、２５６、２５８、２５９、２６０および２６２がビデオデータを含む。トランスポートパケット２５２、２５７および２６１がオーディオデータを含む。トランスポートパケット２５３が制御データを含む。トランスポートパケット２５４がタイミングデータを含む。トランスポートパケット２５５が埋込（パディング）パケットである。

各トランスポートパケットがヘッダを有する。ヘッダはそのパケットのためのプログラムＩＤ（「ＰＩＤ」）を含む。ＰＩＤ ０を割当てられたパケットが制御パケットである。たとえば、パケット２５３はＰＩＤ ０を割当てられ得る。他の制御パケットを含む他のパケットはＰＩＤ ０パケット内を参照させられる。具体的に、ＰＩＤ ０制御パケットはＰＩＤ ０制御パケットの直後にあるパケットのパケットタイプを識別するテーブルを含む。ＰＩＤ ０制御パケットではないすべてのパケットに対して、ヘッダは、そのパケットの直前にあるＰＩＤ ０制御パケットに含まれるテーブルを指すポインタとなるＰＩＤを含む。たとえば、ＰＩＤ １００のパケットに含まれるデータタイプは、そのパケットの直前のＰＩＤ ０制御パケットのテーブルにあるＰＩＤ １００と関連したエントリを調べることによって判断されるであろう。

ビデオ層では、ＭＰＥＣファイル１３４はフレームデータの境界に従って分割される。上述のように、ビデオフレームを表わすデータの境界とトランスポートパケットの境界との間には相関関係はない。図示する例では、あるビデオフレーム「Ｆ」のためのフレームデータが括弧２７０によって示されるように配置される。具体的に、フレーム「Ｆ」のためのフレームデータは、ビデオパケット２５１内の点２８０からビデオパケット２５１の終わりまでと、ビデオパケット２５６内と、ビデオパケット２５８の初めからビデオパケット２５８内の点２８２までとに配置される。したがって、点２８０および２８２はフレーム「Ｆ」のためのピクチャパケットの境界を表わす。第２のビデオフレーム「Ｇ」のためのフレームデータは括弧２７２によって示されるように配置される。フレーム「Ｇ」のためのピクチャパケットの境界は括弧２７６によって示される。

ＭＰＥＧ−２トランスポートストリームに対して上述したものと類似の構造もＭＰＥＧ−１形式、Quicktime形式、ＡＶＩ形式、Proshare形式およびＨ．２６１形式を含む他のデジタルオーディオビジュアル記憶形式において存在する。好ましい実施例では、ビデオアクセス点、タイムスタンプ、ファイル位置等の標識は、多数のデジタルオーディオビジュアル記憶形式が同じサーバによってアクセスされて広範囲の記憶形式からの異なるクライアントに対処できるように記憶される。好ましくは、形式に特定的な情報および技術のすべてがタグ発生器およびストリームサーバに組込まれる。サーバの他の要素のすべてが形式に依存する。

例示的タグファイル
例示的タグファイル１３２の内容をここで図２ｂを参照して説明する。図２ｂでは、タグファイル１３２はファイルタイプ識別子２０２、長さ指示子２０４、ビット速度指示子２０６、プレー持続指示子２０８、フレーム数指示子２１０、ストリームアクセス情報２１２および初期ＭＰＥＧタイムオフセット２１３を含む。ファイルタイプ識別子２０２はＭＰＥＧファイル１３４上の物理的ラッピングを示す。たとえば、ファイルタイプ識別子２０２はＭＰＥＧファイル１３４がＭＰＥＧ−２ファイルであるか、ＭＰＥＧ−１ファイルであるかを示すであろう。

長さ指示子２０４はＭＰＥＧファイル１３４の長さを示す。ビット速度指示子２０６はＭＰＥＧファイル１３４の内容が再生中にクライアントに送られるべきビット速度を示す。プレー持続指示子２０８は、通常の再生動作の間に、ＭＰＥＧファイル１３４の内容全体を再生するために必要な時間の量をミリ秒単位で特定する。フレーム数指示子２１０はＭＰＥＧファイル１３４内で表わされるフレームの総数を示す。

ストリームアクセス情報２１２はＭＰＥＧファイル１３４内に記憶されているビデオおよびオーディオストリームにアクセスするのに必要な情報である。ストリームアクセス情報２１２はビデオエレメンタリストリームＩＤおよびオーディオエレメンタリストリームＩＤを含む。ＭＰＥＧ−２ファイルでは、ストリームアクセス情報２１２はビデオＰＩＤおよびオーディオＰＩＤも含む。タグファイルヘッダはまた他の特徴を実行するために用いられ得る他の情報を含んでもよい。

上述の一般的な情報に加え、タグファイル１３２はＭＰＥＧファイル１３４内の各フレームのためのエントリを含む。ビデオフレームのためのエントリはフレームを表わすデータの位置に対するさまざまなＭＰＥＧ層の状態に関する情報を含む。ＭＰＥＧ−２ファイルでは、各エントリがＭＰＥＧ−２トランスポートステートマシンの状態と、プログラムエレメンタリストリームステートマシンの状態と、ビデオステートマシンの状態とを含む。ＭＰＥＧ−１ファイルでは、各エントリがパックシステムＭＰＥＧストリームの現在の状態とをビデオステートマシンの状態とを含む。

タグファイルエントリ２１４は個々のＭＰＥＧ−２ビデオフレーム「Ｆ」のために記憶されるタグ情報をより詳細に示す。プログラムエレメンタリストリームステートマシンの状態に関し、タグエントリ２１４は表１に示す情報を含む。

ビデオステートマシンの状態に関し、タグエントリ２１４は表２に示す情報を含む。

トランスポート層ステートマシンの状態に関し、タグエントリ２１４は表３に示す情報を含む。

たとえばエントリ２１４が図２ｂのフレーム「Ｆ」のためのものであると想定する。フレーム「Ｆ」と関連したサイズ２２０は括弧２７４によって囲まれるビットであろう。非ビデオパケットの数２２２は５（パケット２５２、２５３、２５４、２５５および２５７）であろう。埋込パケットの数２２４は１（パケット２５５）であろう。開始位置２２６はＭＰＥＧファイル１３４の初めと点２８０との間の距離であろう。開始オフセット２３
４はパケット２４１の初めと点２８０との間の距離であろう。終了オフセット２３６は点２８２とパケット２５８の終わりとの間の距離であろう。

ＭＰＥＧ−１ファイルのフレームごとに発生されるタグ情報を図２ｃに示す。図２ｃを参照して、エントリ２１４は、システムステートマシン、パックステートマシンおよびビデオステートマシンの３つのステートマシンの状態を示すデータを含む。具体的に、タグエントリ２１４は表４に示す情報を含む。

タグ情報はビデオフレームの初めにおける関連したステートマシンの状態を示すデータ
を含む。しかしながら、他のデジタルオーディオビジュアル形式によって採用されるステートマシンは、ＭＰＥＧ−１形式において採用されるステートマシンがＭＰＥＧ−２において採用されるものとは異なるように、上述のものとは異なる。したがって、ビデオのフレームごとに記憶される特定のタグ情報は、対応するファイルのデジタルオーディオビジュアル形式に基づいて変化する。

ＭＤＳ
ＭＤＳ１１２はＭＤＳサーバ１１０とディスク１１４のような１つ以上の不揮発性記憶装置とを含む。図示する実施例では、ＭＰＥＧファイル１３４が数多くのディスク１１４にまたがって記憶されてシステムの障害許容力を高める。たとえば図３に示すマルチディスクシステム３００を考える。システム３００はＮ＋１個のディスクドライブを含む。ＭＰＥＧファイルがＮ＋１個のディスクのうちＮ個に記憶される。ＭＰＥＧファイルはセクション３５０、３５２、３５４および３５６に分割される。各セクションはＮ個のブロックに分割され、ＮはＭＰＥＧファイルを記憶するために用いられるディスクの数である。各ディスクは種々のセクションからの１ブロックを記憶する。

図示する例では、ＭＰＥＧファイルの第１のセクション３５０がディスク３０２、３０４および３０６にそれぞれ記憶されたブロック３１０、３１２および３１４を含む。第２のセクション３５２がディスク３０２、３０４および３０６にそれぞれ記憶されたブロック３１６、３１８および３２０を含む。第３のセクション３５４がディスク３０２、３０４および３０６にそれぞれ記憶されたブロック３２２、３２４および３２６を含む。第４のセクション３５６がディスク３０２、３０４および３０６にそれぞれ記憶されたブロック３２８、３３０および３３２を含む。

ＭＰＥＧファイルを記憶するために用いられないディスク３０８は、検査ビットを記憶するために用いられる。検査ビットの各組がＭＰＥＧファイルのセクションに対応し、対応のセクションに属するさまざまなブロックに基づいて構成される。たとえば、検査ビット３３４はセクション３５０に対応し、第１のセクション３５０内の全ブロックに対して排他的ＯＲ演算を行なうことによって発生される。同様に、検査ビット３３６、３３８および３４０はセクション３５２、３５４および３５６内の全ブロックに対してそれぞれ行なわれる排他的ＯＲの積である。

システム３００は、システム内の任意のディスクが正しく動作しなくなると悪いディスクの内容が残りのディスクの内容に基づいて復元され得るので、単一のディスクシステムよりも高い障害許容力を有する。たとえば、ディスク３０４が機能しなくなると、ブロック３１２の内容がセクション３５０内の残りのブロックとセクション３５０に関連した検査ビット３３４とに基づいて復元され得る。同様に、ブロック３１８はセクション３５２内の残りのブロックとセクション３５２に関連した検査ビット３３６とに基づいて構成され得る。この誤り検出および訂正技術は「安価なディスクの冗長アレイ」またはＲＡＩＤとして一般に知られている。

ＲＡＩＤを用いるリアルタイムの再生の間、ビデオポンプ１２０は、全情報がディスクから読出された誤りのあるデータを復元するために利用可能であるように、セクションごとにＭＰＥＧファイルを読出し、処理する。リアルタイムでＲＡＩＤを行なうための技術は、引用によりここに援用される米国特許第５，６２３，５９５号「冗長アレイデータ記憶システムにおける破壊データの透過的リアルタイム復元のための方法および装置（“METHOD AND APPARATUS FOR TRANSPARENT, REAL TIME RECONSTRUCTION OF CORRUPTED DATA IN A REDUNDANT ARRAY DATASTORAGE SYSTEM”）」に説明されている。

通常の再生動作の間、前のセクションからのデータがＭＰＥＧデータストリーム内で送
信されている間に、セクション全体を読出すために必要なディスクアクセスを行なうための十分な時間がある。しかしながら、早送りおよび早巻戻し動作の間では、ＭＰＥＧデータストリーム内で送られるセクション内のデータはすべてではない。送られるデータがより少ないので、データ送信にかかる時間はより短い。したがって、後のセクションを読出、処理するために利用可能な時間はより少ない。

たとえば、セクション３５０からの１つのフレームＸだけが早送り動作の間に表示するよう選択されたと想定する。フレームＸのためにセグメントを送信するのにかかる時間の間、次に選択されたフレームＹのためのデータが読出され、処理される。次のフレームＹがセクション３５２内にあると想定する。ＭＰＥＧファイルが（ＲＡＩＤに対して必要とされるように）セクションごとに読出され、処理されるならば、セクション３５２内の全ブロックが単一のフレームＸの送信の間に読出され、処理される。割当てられた時間内でセクション３５２の全ブロックを読出し、処理することが可能であっても、必要なディスクアクセスを行なう際に消費されるであろう資源のためにそれを行なうことはなお望ましくないかもしれない。

以上を鑑み、ビデオポンプ１２０は早送り動作および早巻戻し動作の間にＲＡＩＤを用いない。むしろ、ビデオポンプ１２０はストリームサーバ１１８から受取るコマンドにおいて示されるデータのみを読出し、処理し、送信する。したがって、上の例では、フレームＦのためのフレームデータのみがフレームＸのためのセグメントの送信の間に読出され、処理されるであろう。早送り動作および早巻戻し動作の間にＲＡＩＤをバイパスすることによって、ディスク帯域幅は通常の再生動作の間に用いられるのと同じレベルからそれよりも下のレベルであり続ける。

ＲＡＩＤがリアルタイムの早送り動作および早巻戻し動作の間に用いられないので、誤りのあるデータはこれらの動作の間に復元可能ではない。したがって、ビデオポンプ１２０が選択されたフレームのためのデータが破損しているか利用不可能であることを検出すると、ビデオポンプ１２０は問題のフレームに関連したセグメント全体を破棄する。このように、フレームに関連したデータを送ることができなければ、そのフレームのための接頭語データおよび接尾語データも送られない。しかしながら、接頭語データまたは接尾語データとともに送られるべきであった埋込パケットはなお送られる。

「セグメント」全体のデータを送ることによって、デジタルオーディオビジュアル形式との適合性が維持される。一実施例では、ビデオポンプ１２０がラインを満たすために埋込パケットを送って、正しい表示速度を維持する。好ましい実施例では、この動作はクライアントによって選択可能である。

データストライピング
上述のＲＡＩＤ技術は（アレイにおける全ディスクからの全データが並行して読出されるために）処理量と（誤り訂正による）信頼性との両方を改善する。処理量をさらに高めるため、ＲＡＩＤがデータストライピングに関連して用いられてもよい。データストライピングを用いて、論理的に連続したデータのセグメントが総当たり式に複数の物理装置（または物理装置の組）に書込まれる。総当たりシーケンスにおける各記憶素子に記憶されるデータの量は「ストライプ」と呼ばれる。総当たりシーケンスにおける各記憶素子がＲＡＩＤディスクのアレイである場合、データの各セグメントはＲＡＩＤストライプと呼ばれる。

図３Ｂは、データストライピングがＲＡＩＤと関連して用いられるシステムを示す。図３Ｂのシステムは、図３Ａの各ディスクが一連のＭ個のディスクに置き換えられたことを除き、図３Ａのそれと類似している。したがって、ディスク３０２はディスク３０２−１
から３０２−Ｍに置き換えられている。ディスク３０２上に記憶されるセグメント部分は順次、総当たり式にディスク３０２−１から３０２−Ｍ上に記憶されている。たとえば、ＭＰＥＧファイルが５０個のセグメントに分割され、ディスク３０２が２５個のディスクに置き換えられていると想定する。これらの状況下では、ディスク３０２−１がセグメント１および２６の第１の部分を記憶するであろう。ディスク３０２−２がセグメント２および２７の第１の部分を記憶するであろう。以下同様である。

データストライピングは、異なる処理が異なるディスクアレイからの読出を並行して行なうことができるので処理量を高める。たとえば、あるデータポンプがディスク＿１，１からディスク＿１，Ｎ＋１を含むＲＡＩＤアレイからのＭＰＥＧファイルの第１のセグメントを読出している間に、別のデータポンプがディスク＿２，１からディスク＿２，Ｎ＋１を含むＲＡＩＤアレイからの同じＭＰＥＧファイルの第２のセグメントを同時に読出すことができる。

処理性能の理由のため、読出および書込は別個のチャンク、一般にはディスクＲＡＩＤストライプにおいて起こる。代表的なデジタルビデオ配信システムでは、各アクセスユニットが２５６ｋＢまたは２メガビットであり、内容は２Ｍｂ／ｓｅｃＭＰＥＧである。したがって、各ＲＡＩＤストライプがビデオの約１秒にほぼ対応するが、これは内容ビット速度およびサーバ構成に依存して１ストライプ当たり約０．２秒から約１０秒の範囲で容易に変動可能である。

クライアント
オーディオビジュアル情報配信システム１００は、１つ以上のクライアント、たとえばクライアント１２２を含む。クライアント１２２はデジタルオーディオビジュアルデータのストリームに含まれるオーディオビジュアル情報をデコードするように構成された装置を一般に表わす。たとえば、クライアント１２２はテレビのような出力装置に結合された１組のトップコンバータボックス（a set top converter boxes）であってもよい。クライアント１２２は、デジタルデータストリームをデコードするためのデコーダ１２６と、情報をストリームサーバ１１８に通信するための制御ユニット１２４とを含む。

ストリームサーバ１１８は制御ネットワーク１４０によってクライアント１２２からの情報を受信できる。制御ネットワーク１４０は２つ以上の装置の間の通信を与えるいかなるネットワークであってもよい。たとえば、制御ネットワーク１４０は高帯域幅ネットワーク、Ｘ．２５回路または電子機械工業会（ＥＩＡ）２３２（ＲＳ−２３２）シリアルラインであってもよい。

クライアント１２２は制御ネットワーク１４０によってストリームサーバ１１８およびデータベース１１６と通信する。たとえば、クライアント１２２は問合わせをデータベース１１６に送って、何を現在見ることができるのかに関する情報を要求する。データベース１１６は要求された情報をクライアント１２２に戻すことによって応答する。クライアント１２２のユーザは次に、特定の位置および特定の速度で始まる特定のオーディオビジュアル作品を見ることを選択できる。クライアント１２２はオーディオビジュアルデータストリームおよび制御情報の送信の開始を要求して、ネットワーク１４０からストリームサーバ１１８への進行中のデジタルオーディオビジュアル送信の再生に影響を及ぼす。

ビデオポンプおよびストリームサーバ
ビデオポンプ１２０はストリームサーバ１１８に結合され、ストリームサーバ１１８からコマンドを受取る。ビデオポンプ１２０は、ビデオポンプ１２０がディスク１１４からデータを記憶し、引出すようにディスク１１４に結合される。

ストリームサーバ１１８との通信に加え、クライアント１２２が高帯域幅ネットワーク１５０によってビデオポンプ１２０から情報を受信する。高帯域幅ネットワーク１５０は大量のデータを送信可能な回路型ネットワークリンクの如何なるタイプであってもよい。回路型ネットワークリンクは、データの宛先が送信プロトコルではなく基礎をなすネットワークによって保証されるように構成される。たとえば、高帯域幅ネットワーク１５０は非同期伝送モード（ＡＴＭ）回路または物理タイプのライン、たとえばＴ１またはＥ１ラインであってもよい。さらに、高帯域幅ネットワーク１５０は光ファイバケーブル、ツイストペア導体、同軸ケーブル、または無線通信システム、たとえばマイクロ波通信システムを利用してもよい。

ネットワーク１５０は代替的に、比較的低い帯域幅のネットワークか、または高帯域幅通信媒体と低帯域幅通新媒体との組合せであってもよい。たとえば、ネットワーク１５０の一部が比較的高い帯域幅のＡＴＭ回路を含んでもよいが、２８．８Ｋモデムのような比較的低い帯域幅の装置がビデオ情報をネットワークからクライアント１２２へと伝えるために下流で用いられる。

オーディオビジュアル情報配信システム１００は、ビデオポンプ１２０のようなサーバに大量のデータをディスク１１４から、高帯域幅ネットワークによってクライアント１２２へと最小のオーバーヘッドで送信させる。加えて、オーディオビジュアル情報配信システム１００は、クライアント１２２に制御ネットワーク１４０による標準的ネットワークプロトコルを用いて要求をストリームサーバ１１８に送信させる。好ましい実施例では、高帯域幅ネットワーク１５０と制御ネットワーク１４０とのための基礎をなすプロトコルは同じである。ストリームサーバ１１８は単一のコンピュータシステムからなってもよく、サーバとして構成された複数の演算装置からなってもよい。同様に、ビデオポンプ１２０は単一のサーバ装置からなってもよく、複数のこのようなサーバからなってもよい。

特定のデジタルオーディオビジュアルファイルからデジタルオーディオビジュアルデータストリームを受信するために、クライアント１２２は要求をストリームサーバ１１８に送信する。この要求に応答して、ストリームサーバ１１８はコマンドをビデオポンプ１２０に送信して、ビデオポンプ１２０に、要求されたデジタルオーディオビジュアルデータストリームを、そのデジタルオーディオビジュアルデータストリームを要求したクライアントまで送信させる。ライブフィードでは、ビデオサーバ１０６が、ビデオポンプ１２０がファイル１３４からのビデオストリームをクライアント１２２へと送るのと同時に、ビデオストリームをビデオファイル１３４へと記憶させる。

ストリームサーバ１１８からビデオポンプ１２０へと送られるコマンドは、クライアントの要求に特定的な制御情報を含む。たとえば、制御情報は、所望のデジタルオーディオビジュアルファイル、デジタルオーディオビジュアルファイル内の所望のデータの初めのオフセットと、クライアントのアドレスとを識別する。特定のオフセットで有効なデジタルオーディオビジュアルストリームを生み出すために、ストリームサーバ１１８はまた「接頭語データ」をビデオポンプ１２０に送り、ビデオポンプ１２０に対して接頭語データをクライアントに送るよう要求する。以下により詳細に説明するように、接頭語データは、クライアントがデジタルオーディオビジュアルファイル内の特定の位置からのデジタルオーディオビジュアルデータを受取る準備をさせるデータである。

ストリームサーバ１１８からコマンドおよび制御情報を受信した後、ビデオポンプ１２０はディスク１１４上の特定のデジタルオーディオビジュアルファイル内の特定の位置からデジタルオーディオビジュアルデータを引出し始める。説明の目的のため、オーディオビジュアル情報配信システム１００は１つ以上のＭＰＥＧ形式に従ってオーディオビジュアル情報を配信すると想定する。したがって、ビデオポンプ１２０はディスク１１４上の
ＭＰＥＧファイル１３４からオーディオビジュアルデータを引出す。

ビデオポンプ１２０は接頭語データをクライアントに送信し、次に特定の位置から始まるディスク１１４から引出されたＭＰＥＧデータをクライアントへと継ぎ目なく送信する。接頭語データは、特定の位置にあるＭＰＥＧデータが続く場合、ＭＰＥＧ適合性遷移パケットを生み出すパケットヘッダを含む。第１のパケットに続くデータがＭＰＥＧファイル１３４から順次引出され、したがって一連のＭＰＥＧ適合性パケットを構成する。ビデオポンプ１２０はこれらのパケットを高帯域幅ネットワーク１５０によって要求するクライアントへと送信する。

要求するクライアントは接頭語データから始まるＭＰＥＧデータストリームを受信する。クライアントはＭＰＥＧデータストリームをデコードして、ＭＰＥＧデータストリームにおいて表わされるオーディオビジュアルシーケンスを複製する。

時期尚早の読出の回避
ＭＰＥＧストリームがエンコーダ１０１によって発生されているのと同時にクライアント１２２がＭＰＥＧストリームをプレーしているとき、クライアント１２２が機能停止する（有効な内容データの終わりに達したため）、または悪いデータをプレーする（現在利用可能な内容データの終わりを超えて読出したため）ことが確実にないようにするため保護策が取られなければならない。ビデオポンプ１２０が行なうディスク１１４のストライプの読出が早すぎれば、ビデオポンプ１２０は無効データをクライアント１２２に送り、意図しない内容または不要部分（不適切な内容）を表示させてしまう。このような早すぎる読出は、たとえばディスク１１４上にまだ記憶されていないビデオストリームの部分を表示するようユーザが要求した場合に起こる。これを防ぐため、ＭＰＥＧファイル１３４のためのファイル終わり情報が維持されて現在のファイルの終わり１３４を示す。より多くの内容データがファイル１３４に加えられると、新しいデータがアクセス可能となるようにファイル終わり情報が更新される。

早すぎる読出を避けるアプローチの１つは、ディスク１１４上の内容のテーブルを新しいファイル終わり値で繰返し更新し、ビデオポンプ１２０にディスク１１４からストライプを読出す前にこの値を検査させることである。ＭＤＳサーバ１１０はファイルの終わりを更新して、新しい内容がディスク１１４へとうまく記憶されたことが証明された後にのみ、内容ファイル１３４が新しい内容を含むことを示す。残念ながら、このファイル終わり情報がダイナミックメモリに保持されることが保証されなければ、この技術は更新の待ち時間の期間における予測困難なジッタに繋がる。

早すぎる読出を避ける他のアプローチは、内容を読出している全処理に対してＭＤＳサーバ１１０が新しいファイル終わり情報を能動的に送ることである。したがって、ＭＤＳサーバ１００は内容データをディスク１１４上のファイル１３４へと記憶させ、内容が記憶されたことが確認されるのを待ち、次に、新しく記憶された内容の存在を示すメッセージを内容データを読出す全処理（たとえば、ビデオポンプ１２０）に対して送信する。ＭＤＳサーバ１１０は、周期的に（たとえば、５秒ごとに）または予め定められた量の新しい内容データがうまく記憶された後に（たとえば、１メガバイトごとに）このようなファイル終わり通知メッセージを作ってもよい。残念ながら、通知時間もまた内容の到着時間のばらつきのためにジッタを起こし、これはエンコーダ１０１と、それとビデオサーバ１０６との間のネットワークと次第である。

一実施例に従うと、タグ情報は現在のファイルの終わりを示すように用いられる。具体的に、ビデオサーバ１０６はタグバッファ１０８からのタグ情報をＭＤＳ１１２による記憶のために送ることによって、ファイル１３４のファイルの終わりを効果的に更新する。
内容の特定的な部分に対応するタグ情報がビデオサーバ１０６によって送信されるとすぐに、ビデオポンプ１２０がビデオの特定的な部分を自由にシークすることができるようになる。ビデオの特定的な部分に対応するタグ情報が解放されるまで、ビデオポンプ１２０はビデオの対応の部分のシークを行なわないかもしれない。最新のタグ情報が現在のファイルの終わりを示すので、新しく接続されたユーザは最新のタグ情報に関連した内容をシークし、リアルタイムの速度でフィードをプレーし始めればよい。

最小タグ遅延期間
クライアント１２２が機能停止したり、悪いデータをプレーしたりすることがないようにするために、タグバッファ１０８からＭＤＳ１１２へのタグデータの送信が遅延される。好ましくは、遅延の持続期間は関連の内容データのアクセスが早すぎないことを確実とするのに十分な長さである。他方、必要以上に長いタグデータ遅延は内容がエンコードされてからユーザが内容をシークまたはスキャンできるようになるまでの待ち時間を増大させる。したがって、最小のタグ遅延期間を決定し、最小のタグ遅延期間のためにタグバッファ１０８内のタグデータをバッファ処理することが望ましい。タグデータ項目に対する最小のタグ遅延期間はエンコーダ１０１からビデオポンプ１２０への対応の内容データの配信にかかわる最大の待ち時間によって決定される。

ビデオサーバ１０６はネットワークバッファ１５２および書込バッファ１５４を含む。一般に、ビデオサーバ１０６は、書込バッファ１５４からの内容データをディスク１１４へと書込むのと同時にチャネル１２８からの内容データをネットワークバッファ１５２へと読出す。ＲＡＩＤ記憶技術を用いる実施例では、内容データは１つのＲＡＩＤストライプに対応する単位でビデオサーバ１０６内において受信され、バッファ処理される。

ビデオポンプ１２０はプリフェッチユニット１４６およびバッファ１４４を含む。ビデオポンプ１２０はディスク１１４からの内容データを非同期に読出す。内容データを読出すため、プリフェッチユニット１４６は内容データの特定の部分の送信を要求し、ディスク１１４は要求された内容データを送るかまたは要求されたデータを送ることができないと示すことによって応答する。待ち時間の中には、プリフェッチユニット１４６がデータを要求したときからデータがビデオポンプ１２０によって受信されるときの間に起こるものもある。

ファイル１３４からの内容データがビデオポンプに到着すると、ビデオポンプ１２０はファイル１３４からの内容データをバッファ１４４へと記憶させる。帯域幅がネットワーク１５０上で利用可能となると、ビデオポンプ１２０は内容データをバッファ１４４からネットワーク１５０によってクライアント１２２へと送信する。ビデオサーバ１０６におけるのと同様に、内容データは、ＲＡＩＤ記憶技術が用いられる場合は１つのＲＡＩＤストライプに対応する単位ごとにビデオポンプ１２０内でプリフェッチされ、バッファ処理される。

上述のように、ビデオポンプ１２０は一般に、あるＲＡＩＤストライプからのデータをネットワークバッファへとコピーし、次のストライプをプリフェッチする。同様に、ビデオサーバ１０６は一般に内容のあるＲＡＩＤストライプをデータ記憶装置へと書込み、ネットワークから第２のメモリバッファへのデータを受取る。したがって、一般に「通過状態」のＲＡＩＤストライプが４つあるので、任意の内容データが発生されてからそれがプレー可能とされるようになるまでの待ち時間は、ほぼ４つのＲＡＩＤストライプに相当するデータを配信するのにかかる時間である。

ＲＡＩＤストライプは通常１ディスク当たり１２８Ｋビットまたは２５６Ｋビットである。ＲＡＩＤストライプにおける全ディスクの合計はしたがって１から２メガビットであ
る。代表的なＭＰＥＧファイルでは、各ＲＡＩＤストライプがビデオの１秒にほぼ対応する。したがって、４つのＲＡＩＤストライプを通過状態にさせると約４秒の最小待ち時間となる。

タグデータに対する意味は、対応の内容がプレーできる（すなわち、２秒間ディスク上に継続して記憶された）ときに、他のエンティティによる使用のために所与のタグがビデオサーバ１０６によって解放されるにすぎないことを示す。したがって、内容配信が４秒の待ち時間であるビデオ配信システムにおいて、タグバッファ１０８に保たれるタグデータが送信されるのは対応の内容が発生してからわずか４秒後である。

一実施例に従うと、ジッタおよび機能停止の両方がタグバッファ１０８からのタグデータのバッチを１２秒ごとにＭＤＳ１１２に送信することによって回避される。１２秒ごとに送信されるタグデータバッチは少なくとも１２秒経ているタグバッファ１０８内の全タグ情報を含む。発生してから１２秒未満のタグデータはタグバッファ１０８に保たれ、次の１２秒の終わりで一括してＭＤＳ１１２に送信される。ＭＤＳサーバ１１０はビデオファイル１３４を読出しているさまざまなエンティティ（たとえば、ビデオポンプ１２０）へとタグデータを送り、次にタグ情報をディスク１１４上に記憶させる。

デジタルチャネル
スポーツイベントのような特定のオーディオビジュアル作品に対して発生されたビデオファイルはその長さが有限である。したがって、それらの対応の内容ファイルが消費する記憶媒体の量も有限であり、後の観察のために内容ファイル全体を永続的に記憶することが実用的となる。しかしながら、伝統的なテレビ「チャネル」はオーディオビジュアル作品の決して終わりのないシーケンスからなる。デジタルチャネルの全内容を永続的に保持すると、記憶媒体が容認不可能に高い速度で連続して消費されるであろう。他方、元々放送された時間にユーザが見ることができなかったかもしれないプログラムをユーザが見ることができるのが望ましい。たとえば、デジタルチャネルによって放送されたプログラムの最後の２４時間に視聴者がアクセスできることが望ましいであろう。この発明の一実施例に従うと、より古いデータが「期限切れ」して新しいデータで上書きされる、無限フィードに対する履歴ビューイング（historical viewing）が連続的有限バッファの使用によって設けられる。

内容の期限切れ
データ、たとえば生涯、女性のためのテレビ（Lifetime, Television for Women）の最後の２４時間の連続的バッファ処理を与えるために、より古い内容は対応のタグとともに削除される必要がある。このような連続的バッファを実現するためにさまざまなアプローチが取られ得る。

内容データに関し、連続的バッファを実現するための最も簡単なアプローチは２４時間のフィート数を保持するのに十分な大きさの単一のファイルを作ることである。ファイルは次に循環バッファとして扱われる。具体的に、初めの２４時間のファイルが作られた後、ＭＤＳサーバ１００が現在の「挿入点」としてファイルの初めを確立するであろう。ＭＤＳサーバ１１０は次に挿入点において古いデータ上に新しい内容データを記憶させ、挿入点を新しいデータの最後に移動させるであろう。挿入点がファイルの最後に当たれば、それは再びファイルの初めに循環する。

残念ながら、この単一ファイル循環バッファアプローチはファイルの時間の延長または短縮を困難にする。たとえば、挿入点がファイルの真ん中にあり、４８時間にわたるようファイルを拡大する決定が行なわれると想定する。これらの状況下では、ＭＤＳサーバ１１０は、挿入点がファイルの最後に達したときにさらなる１２時間にわたって時間を延長
し始めることができないであろう。単一循環バッファのアプローチを用いると、クライアントが再生を停止し、「水平方向に」それを移動させたか、したがって、クライエントが再開したときにそれが見ていた内容が上書きされているかどうかの検出が困難である。

図４は予め定められた量の無限ビデオフィードのバッファ処理に対する代替的でより融通性のあるアプローチを示す。図４を参照すると、内容データがより小さいファイル４０２−４１４のグループに記憶されている。より小さいファイルの各々がバッファ処理された内容データのサブセットを記憶している。図示する実施例では、ファイル４０２−４１２の各々が２時間に値する内容を記憶している。ファイル４１４は現在１時間の内容を記憶している。現在の挿入点はファイル４１４の最後である。ファイル４１４が２時間の内容に達すると、ファイル４１４は閉じられ、新しい内容ファイルが作られる。内容ファイルが古くなると、より古い内容ファイルが削除されて新しいファイルのためのディスク空間を空ける。再生中、ファイルは内容データがクライアントに送られるときにビデオポンプによって継ぎ目なく結合される。

図４に示すバッファ処理技術が用いられると、緩やかな期限切れ方針が設定可能である。具体的には、全クライアントが（ファイルと、そのファイルに先行する任意のファイルとに対して）終了するまでファイルが削除されないという方針が確立され得る。たとえば、ユーザはフィードの最後の１２時間にアクセスを許されると想定する。ファイル４１４が完了すると、ファイル４０４−４１４が最近の１２時間を含むので、ファイル４０２はもはや必要とされない。しかしながら、クライアントは現在ファイル４０２の内容を見ているかもしれない。したがって、ファイル４０２は直ちには削除されない。新しいクライアントがファイル４０２へのアクセスを防がれるが、現在ファイル４０２にアクセスしているクライアントはファイル４０２のプレーを完了させることを許される。最後のクライアントがファイル４０２のプレーを終えると、ファイル４０２は削除される。

既存のファイルの数の上限を定めるために、クライアントが古いファイルのプレーを終えるための時間の制限が確立され得る。たとえば、ファイル４１４が完了すると、新しいクライアントがファイル４０２へのアクセスを妨げられるだけでなく、ファイル４０２に現在アクセスしているクライアントがファイル４０２のプレーを終えるために２時間を与えられる。２時間後任意のクライアントがなおファイル４０２を読出しているかどうかにかかわらずファイル４０２は削除されてディスク空間を空ける。

タグ期限切れ
内容ファイル（たとえば、ファイル４０２）が削除されると、削除された内容ファイルに対応するタグが「期限切れした」と見なされ、したがってこれもまた削除可能である。理想的には、古いタグの容易な削除と新しいものの追加とを可能にするデータベーステーブルのような形式にタグが記憶される。残念ながら、データベーステーブルからのタグの記憶および引出に関連したオーバーヘッドは非常にコストがかかるので、ライブフィードの条件下では実用的ではない。アクセスの容易さおよび速度のために、タグはしたがって典型的に平坦なファイルに記憶される。

図５を参照すると、平坦なタグファイル５００が示される。平坦なタグファイル５００はヘッダ５０２とそれに続く１組のタグ５０４とを含む。ヘッダ５０２は、タグファイル５００内のタグが対応する内容ファイルの組を含んだタグファイル５００の内容に関する情報を含む。

新しいタグが到着すると、そのタグはタグファイル５００に付加される。タグファイル５００が連続的フィードと関連付けられるので、タグファイル５００は期限切れタグを削除するための機構が設けられなければ無限に成長する。しかしながら、タグファイル５０
０自身はタグファイル５００内のいくつかのタグ（たとえば、タグ５１０）の期限切れ後でさえも有効であり続けるべきであり、これは、クライアントがまだ期限切れしていないタグファイル５００内のタグ５１２のアクセスおよび使用を続けるかもしれないためである。したがって、期限切れ機構はタグファイル５００からの期限切れタグ５１０を単に削除することはできない。

タグファイル５００から期限切れしたタグを直接的に削除するのではなく、一時タグファイル５１４が、新しいヘッダ５０６を構成し、かつ新しいヘッダ５０６に古いタグファイル５００からの期限切れしていないタグ５１２のコピーを付加することによって作られる。新しいヘッダ５０６は、削除された内容ファイルのためのタグを含むことをタグファイル５００が示すが、ヘッダ５０６内のデータは示さないことを除き、古いヘッダ５０２と同じ情報を含む。

新しいタグファイル５１４が作られている間、新しいタグデータは新しいタグファイル５１４と古いタグファイル５００との両方に付加される。新しいタグファイル５１４が作られた後、新しいタグデータは古いタグファイル５００ではなく新しいタグファイル５１４に付加される。新しいタグデータがタグデータ５１２の後に付加されることを確実とするため、コピーされるタグ５１２のための記憶場所が新しいタグファイル５１４内で予め割当てられ、新しいタグは、既存のタグ５１２が予め割当てられた記憶場所へとコピーされている間にはその予め割当てられた記憶場所の後に付加される。

期限切れしていないタグ５１２のすべてが新しいタグファイル５１４にコピーされると、古いタグファイル５００は閉じられ、新しいタグファイルが古いタグファイル５００の上で別名を付けられる。新しいタグファイル５１４が別名を付けられた後、古いタグファイル５００を用いていたタグファイルリーダ（たとえば、ストリームサーバ１１８）が、新しいタグファイル５１４のヘッダに含まれる情報に基づいてリセットされる。一実施例（「プッシュモデル」）に従うと、メッセージがタグファイルリーダに送られて、それらに、タグファイルが変更されたこと、それらが新しいタグファイル５１４内のヘッダ情報に基づいて自ら更新すべきことを明らかに伝える。

代替的な「プルモデル」実施例に従うと、タグファイルリーダは明らかには伝えられない。それらは、タグを読出そうとする試みが失敗すれば新しいタグファイルのヘッダ情報に基づいて読出、自らを更新するよう構成される。プルモデルアプローチは、多くの状況では不必要なメッセージの送信が回避されるという利点を有する。

特定の内容セグメントと関連したタグが削除されるとき、クライアントは内容セグメントを見続けることができる。しかしながら、クライアントは早送りおよび巻戻しのような、削除されたタグ情報を必要とする非順次アクセスを行なうことができない。

タイムスタンピング
タグ情報は対応の内容データにおける各フレームのためのタイムスタンプ情報を含む。デコードの目的のため、タイムスタンプ情報は一般にフィードの初めに対する時間（すなわち、「提示時間」）を表わし、その提示時間に対応するフレームの内容ファイル内のバイトオフセットにマッピングされる。しかしながら、連続的フィードでは、このような相対時間値は無意味である。たとえば、局が放送を始めた時間から５，３４５，７８９．７６秒後に始めるのではなく、１９９７年１月２１日１６時３０分２３秒に再生を始めることをユーザが要求するかもしれない。

この発明の一実施例に従うと、絶対時間値は「０」の相対時間値に対応する絶対時間値を記憶させることによって支持される。したがって、クライアントが絶対時間からの再生
を特定すると、「０」に関連した絶対時間値が特定の絶対時間値から減算されて相対時間値を生む。相対時間値は次にストリームサーバ１１８によって用いられて適切なタグ情報を識別し、タグ情報はストリームサーバ１１８によって用いられて、ビデオポンプ１２０に内容ファイル１３４内の適切な場所からの内容の送出しを始めさせる。

一般に、デジタルビデオのトランスポート形式はタイムスタンプを表わすために固定数のビット（たとえば、３３ビット）を与える。連続的フィードの環境では、相対タイムスタンプ値がトランスポート形式において利用可能なビット数によって表わされ得ない数に必然的に達する。これが起こると、タイムスタンプ値は「ラッピング（循環）」を行ない、再び０で始まる。

ラッピングの問題に対処するため、より正確なラップ値（たとえば、６４ビット）が維持される。シークまたは他の非順次アクセスを行なう際、ストリームサーバ１１８はより正確なタイムスタンプ値を用いる。内容をクライアントに送信する際、ビデオポンプ１２０はより精度の低いタイムスタンプを送る。

ここに説明したビデオエンコードおよび配信技術によって、これまではプログ提供者の領域であった機能をユーザが制御可能となる。たとえば、プログラム提供者は現在、スーパーボールのどのプレーを視聴者に対してリプレーするか、それらがリプレーされる速度、それらがリプレーされる回数を決定している。

しかしながら、視聴者はどのプレーが複数回見るに値するかについて非常に異なる意見を持っているかもしれない。たとえば、２人の視聴者が特定の呼出の精度について議論するかもしれない。しかしながら、プログラム提供者はその呼出を起こしたプレーがリプレーするのに十分であるほど重要とは考えないかもしれない。ここに与えられた技術を用いると、どのプレーが直ちにリプレーされるべきか、それらがリプレーされる速度、それらがリプレーされる回数を視聴者が自身で決定することができる。

以上の明細書において、この発明はその具体的な実施例を参照して説明された。しかしながら、この発明のより広い趣旨および範囲から逸脱せずにさまざまな変更および変化が与えられ得ることが明らかである。したがって、明細書および図面は限定的ではなく例示的なものと見なされるべきである。

Claims (16)

1. ビデオの連続的フィードを記憶させるための方法であって、
   デジタルビデオ形式で前記連続的フィードをエンコードすることによって作られるデジタルデータストリームを受信するステップと、
   現在のファイル内に前記デジタルデータストリームを記憶させるステップと、
   前記現在のファイルが予め定められた条件を満たすと前記現在のファイルとして新しいファイルを確立するステップとを繰返して行なうことによって一連の内容ファイルを生じるステップと、
   前記一連の内容ファイルが予め定められた量の前記連続的フィードよりも多い量を含む場合、前記一連の内容ファイルにおける最も古い内容ファイルを削除するステップとを含む、方法。
2. 任意のリーダが前記特定の内容ファイルからの情報を現在プレーしているかどうかを判断するステップと、
   リーダが情報を現在プレーしていれば、前記最も古い内容ファイルから削除するステップを遅延させるステップとをさらに含む、請求項１に記載の方法。
3. 前記遅延させるステップは、
   予め定められた期間が経過するか、または、
   前記最も古い内容ファイルからの情報を現在プレーしているリーダがなくなるまで、削除するステップを遅延させることによって行なわれる、請求項２に記載の方法。
4. 前記一連の内容ファイルが予め定められた量の前記連続的フィードよりも多い量を含む場合、前記一連の内容ファイルにおける前記最も古い内容ファイルからのデータに新しいリーダがアクセスし始めないようにする、請求項１に記載の方法。
5. 前記現在のファイルが予め定められた条件を満たすと前記現在のファイルとして新しいファイルを確立するステップは、前記現在のファイルが第２の予め定められた量の前記連続的フィードを含むと前記現在のファイルとして新しいファイルを確立するステップを含む、請求項１に記載の方法。
6. 前記デジタルデータストリームに含まれるフレームに関する情報を示すタグ情報を発生し、記憶させるステップをさらに含む、請求項１に記載の方法。
7. 前記タグ情報を発生し、記憶させるステップは、
   第１のタグファイルのための第１のヘッダを発生するステップと、
   前記第１のタグファイル内にタグ情報を連続して記憶させるステップと、
   前記第１のタグファイル内の１組のタグが無効になると、
   第２のタグファイルのための第２のヘッダを発生するステップと、
   前記１組のタグ以外の前記第１のタグファイル内のすべてのタグを前記第１のタグファイルから前記第２のタグファイルへとコピーするステップと、
   前記第２のタグファイル内に新しいタグ情報を連続して記憶させるステップと、
   前記第１のタグファイルを削除するステップとを含む、請求項６に記載の方法。
8. 前記第１のタグファイルを削除するステップは、前記第１のタグファイルの上で前記第２のタグファイルに別名を付けるステップを含む、請求項７に記載の方法。
9. ビデオの連続的フィードを記憶させるための命令のシーケンスを記憶したコンピュータ読出可能媒体であって、命令のシーケンスは、
   デジタルビデオ形式で前記連続的フィードをエンコードすることによって作られるデジタルデータストリームを受信するステップと、
   現在のファイル内に前記デジタルデータストリームを記憶させるステップと、
   前記現在のファイルが予め定められた条件を満たすと前記現在のファイルとして新しいファイルを確立するステップとを繰返し行なうことによって一連の内容ファイルを生じるステップとを行なうための命令を含み、
   前記一連の内容ファイルが予め定められた量の前記連続的フィードよりも多い量を含む場合、前記一連の内容ファイルにおける最も古い内容ファイルを削除するステップを含む、コンピュータ読出可能媒体。
10. 任意のリーダが前記最も古い内容ファイルからの情報を現在プレーしているかどうかを判断するステップと、
    リーダが前記最も古い内容ファイルからの情報を現在プレーしていれば、削除するステップを遅延させるステップとを行なうための命令のシーケンスをさらに含む、請求項９に記載のコンピュータ読出可能媒体。
11. 前記遅延させるステップは、
    予め定められた期間が経過するか、または、
    前記最も古い内容ファイルからの情報を現在プレーしているリーダがなくなるまで、削除するステップを遅延させることによって行なわれる、請求項１０に記載のコンピュータ読出可能媒体。
12. 前記一連の内容ファイルが前記連続的フィードの予め定められた量よりも多い量を含む場合、前記一連の内容ファイルにおける前記最も古い内容ファイルからのデータに新しいリーダがアクセスし始めないようにするステップを含む、請求項９に記載のコンピュータ読出可能媒体。
13. 前記現在のファイルが予め定められた条件を満たすと前記現在のファイルとして新しいファイルを確立するステップは、前記現在のファイルが第２の予め定められた量の前記連続的フィードを含むと前記現在のファイルとして新しいファイルを確立するステップを含む、請求項９に記載のコンピュータ読出可能媒体。
14. 前記デジタルデータストリームに含まれるフレームに関する情報を示すタグ情報を発生し、記憶させるステップを行なうための命令のシーケンスをさらに含む、請求項９に記載のコンピュータ読出可能媒体。
15. 前記タグ情報を発生し、記憶させるステップは、
    第１のタグファイルのための第１のヘッダを発生するステップと、
    前記第１のタグファイル内にタグ情報を連続して記憶させるステップと、
    前記第１のタグファイル内の１組のタグが無効になると、
    第２のタグファイルのための第２のヘッダを発生するステップと、前記１組のタグ以外の前記第１のタグファイル内のすべてのタグを前記第１のタグファイルから前記第２のタグファイルへとコピーするステップと、前記第２のタグファイル内に新しいタグ情報を連続して記憶させるステップと、前記第１のタグファイルを削除するステップとを行なうステップとを含む、請求項１４に記載のコンピュータ読出可能媒体。
16. 前記第１のタグファイルを削除するステップは、前記第１のタグファイルの上で前記第２のタグファイルに別名を付けるステップを含む、請求項１５に記載のコンピュータ読出可能媒体。

Images