(57)【要約】【課題】従来の問題点を解消し、ＥＤＬによるカット編集機能を持つマルチメディア情報編集装置を提供する。【解決手段】バッファサーバが、端末からのマルチメディア情報受信時に、当該受信したマルチメディア情報の構成単位であるフレームに付与されたフレーム番号、タイムコード、および、当該フレームの格納先のストレージサーバ番号の組を対応表として記録し、当該記録した対応表をデータベースサーバに格納し、データベースサーバが、カット編集用に入力されたＥＤＬ内のタイムコード情報を、対応表を参照して再生フレーム番号の列であるプレイリストに変換して、バッファサーバに転送し、バッファサーバが、前記プレイリストに含まれるフレーム番号を持つフレームを、クラスタ間接続ネットワークを経由して、複数のストレージサーバから読み出す。【選択図】図１
2007184777.tif 000002
【特許請求の範囲】
【請求項１】
端末と、
配信用ネットワークと、
分散型マルチメディアサーバと、
制御部と、
前記制御部とデータ通信が可能なデータベースサーバとを備え、
前記分散型マルチメディアサーバは、前記配信用ネットワークを経由して前記端末とマルチメディア情報の送受信を行なう少なくとも１つのバッファサーバと、
ランダムアクセス可能な蓄積装置を保持し、当該蓄積装置に対してマルチメディア情報の蓄積／読み出しを行なう少なくとも１つのストレージサーバと、
前記少なくとも１つのバッファサーバと前記少なくとも１つのストレージサーバとを接続する、高速かつ低負荷なクラスタ間接続ネットワークと、
前記少なくとも１つのバッファサーバと前記少なくとも１つのストレージサーバと、前記制御部とを接続するローカルエリアネットワークとを有し、
１つのマルチメディア情報を前記少なくとも１つのストレージサーバの前記蓄積装置に分散して絡納するマルチメディア情報編集装置であって、
前記少なくとも１つのバッファサーバは、前記配信用ネットワークを介して前記端末からのマルチメディア情報受信時に、当該受信したマルチメディア情報の構成単位であるフレームに付与されたフレーム番号、タイムコード、および、当該フレームの格納先のストレージサーバ番号の組を対応表として記録し、当該記録した対応表を、前記ローカルエリアネットワーク経由で前記制御部へ転送するＴＣ／フレーム番号対応記録部と、
前記ローカルエリアネットワーク経由で前記制御部からプレイリストを受信し、当該プレイリストに含まれるフレーム番号を持つフレームを前記少なくとも１つのストレージサーバに対して要求したのち、前記クラスタ間接続ネットワークを経由して、前記プレイリストに含まれるフレーム番号を持つフレームを受信し、前記配信用ネットワークを介して前記端末に転送するプレイリスト解釈部とを有し、
前記制御部は、前記少なくとも１つのバッファサーバの前記ＴＣ／フレーム番号対応記録部から受信した前記対応表を前記データベースサーバに転送し、あるいは、前記データベースサーバから受信した前記プレイリストを、前記少なくとも１つのバッファサーバのプレイリスト解釈部に転送し、
前記データベースサーバは、前記制御部から受信した前記対応表を格納するデータ管理部と、
カット編集用に入力されたＥＤＬ内のタイムコード情報を、前記対応表を参照して再生フレーム番号の列であるプレイリストに変換し、前記制御部に転送するプレイリスト作成部とを有することを特徴とするマルチメディア情報編集装置。
【請求項２】
端末と、
配信用ネットワークと、
分散型マルチメディアサーバと、
制御部と、
前記制御部とデータ通信が可能なデータベースサーバとを備え、
前記分散型マルチメディアサーバは、前記配信用ネットワークを経由して前記端末とマルチメディア情報の送受信を行なう少なくとも１つのバッファサーバと、
ランダムアクセス可能な蓄積装置を保持し、当該蓄積装置に対してマルチメディア情報の蓄積／読み出しを行なう少なくとも１つのストレージサーバと、
前記少なくとも１つのバッファサーバと前記少なくとも１つのストレージサーバとを接続する、高速かつ低負荷なクラスタ間接続ネットワークと、
前記少なくとも１つのバッファサーバと前記少なくとも１つのストレージサーバと、前記制御部とを接続するローカルエリアネットワークとを有し、
１つのマルチメディア情報を前記少なくとも１つのストレージサーバの前記蓄積装置に分散して絡納するマルチメディア情報編集装置であって、
前記少なくとも１つのバッファサーバは、前記配信用ネットワークを介して前記端末からのマルチメディア情報受信時に、当該受信したマルチメディア情報の構成単位であるフレームに付与されたタイムコードと、当該フレームの格納先のストレージサーバ番号の対を対応表として記録し、記録したデータを前記ローカルエリアネットワーク経由で前記制御部へ転送するＴＣ記録部と、
前記ローカルエリアネットワーク経由で前記制御部からプレイリストを受信し、当該プレイリストに含まれるタイムコードを持つフレームを前記少なくとも１つのストレージサーバに対して要求したのち、前記クラスタ間接続ネットワークを経由して、前記プレイリストに含まれるタイムコードを持つフレームを受信し、前記配信用ネットワークを介して前記端末に転送するプレイリスト解釈部とを有し、
前記制御部は、前記少なくとも１つのバッファサーバの前記ＴＣ／フレーム番号対応記録部から受信した前記対応表を前記データベースサーバに転送し、あるいは、前記データベースサーバから受信した前記プレイリストを、前記少なくとも１つのバッファサーバのプレイリスト解釈部に転送し、
前記データベースサーバは、前記制御部から受信した前記対応表を格納するデータ管理部と、
カット編集用に入力されたＥＤＬ内のタイムコード情報と前記対応表を参照して、各カットを構成するフレームのタイムコードと、当該フレームの格納先ストレージサーバ番号を示すプレイリストに変換し、前記制御部に転送するプレイリスト作成部とを有することを特徴とするマルチメディア情報編集装置。
【請求項３】
前記各ストレージサーバは、フレーム先読み制御部を有し、
前記少なくとも１つのバッファサーバの前記プレイリスト解釈部は、全てのストレージサーバに対して前記プレイリストを転送し、
前記各ストレージサーバのフレーム先読み制御部は、前記プレイリストを参照し、前記少なくとも１つのバッファサーバからの転送要求到着前のフレームを、前記記録装置から随時先読みさせることを特徴とする請求項１または請求項２に記載のマルチメディア情報編集装置。
【請求項４】
前記ストレージサーバの前記フレーム先読み制御部は、前記バッファサーバ毎に設けられることを特徴とする請求項３に記載のマルチメディア情報編集装置。
【請求項５】
前記端末は、映像／ＩＰ変換装置を有し、
前記映像／ＩＰ変換装置は、入力されるマルチメディア情報の構成単位であるフレームを、複数のＩＰパケットに分割して前記少なくとも１つのバッファサーバに転送し、あるいは、前記少なくとも１つのバッファサーバから受信したＩＰパケットを、一まとめにして前記フレームを再構成することを特徴とする請求項１ないし請求項４のいずれか１項に記載のマルチメディア情報編集装置。
【請求項６】
前記少なくとも１つのバッファサーバは、ＩＰ送受信部を有し、
前記ＩＰ送受信部は、前記映像／ＩＰ変換装置から受信したＩＰパケットを、一まとめにして前記フレームを再構成し、あるいは、前記映像／ＩＰ変換装置に転送することを特徴とする請求項５に記載のマルチメディア情報編集装置。
【請求項７】
端末と、
配信用ネットワークと、
分散型マルチメディアサーバと、
制御部と、
前記制御部とデータ通信が可能なデータベースサーバとを備え、
前記分散型マルチメディアサーバは、前記配信用ネットワークを経由して前記端末とマルチメディア情報の送受信を行なう少なくとも１つのバッファサーバと、
ランダムアクセス可能な蓄積装置を保持し、当該蓄積装置に対してマルチメディア情報の蓄積／読み出しを行なう少なくとも１つのストレージサーバと、
前記少なくとも１つのバッファサーバと前記少なくとも１つのストレージサーバとを接続する、高速かつ低負荷なクラスタ間接続ネットワークと、
前記少なくとも１つのバッファサーバと前記少なくとも１つのストレージサーバと、前記制御部とを接続するローカルエリアネットワークとを有し、
１つのマルチメディア情報を前記少なくとも１つのストレージサーバの前記蓄積装置に分散して絡納するマルチメディア情報編集装置のマルチメディア編集方法であって、
前記少なくとも１つのバッファサーバが、前記配信用ネットワークを介して前記端末からのマルチメディア情報受信時に、少なくとも、当該受信したマルチメディア情報の構成単位であるフレームに付与されたタイムコードと、当該フレームの格納先のストレージサーバ番号の組を対応表として記録し、当該記録した対応表を、前記ローカルエリアネットワーク経由で前記制御部へ転送するステップ１と、
前記制御部が、前記少なくとも１つのバッファサーバから受信した前記対応表を前記データベースサーバに転送するステップ２と、
前記データベースサーバが、前記対応表を格納するステップ３と、
前記データベースサーバが、カット編集用に入力されたＥＤＬ内のタイムコード情報と、前記対応表を参照して、カットを構成するフレームと、当該フレームの格納先ストレージサーバを示すプレイリストに変換し、前記制御部に転送するステップ４と、
前記制御部が、前記データベースサーバから受信した前記プレイリストを、前記少なくとも１つのバッファサーバに転送するステップ５と、
前記少なくとも１つのバッファサーバが、前記ローカルエリアネットワーク経由で前記制御部からプレイリストを受信し、当該プレイリストで示されるフレームを前記少なくとも１つのストレージサーバに対して要求したのち、前記クラスタ間接続ネットワークを経由して、前記プレイリストに示されるフレームを受信し、前記配信用ネットワークを介して前記端末に転送するステップ６とを有することを特徴とするマルチメディア情報編集方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア情報編集装置およびマルチメディア情報編集方法に係り、特に、映像や音声などのマルチメディア情報を記録媒体に蓄積したり、記録媒体に蓄積されたマルチメディア情報を再生する機能を有する蓄積／再生装置のうち、放送局業務などで行なわれるオンライン編集に使用される装置のように、蓄積されたマルチメディア情報の中の一部分からなるカットを切り出す（カット編集）方法を記述した編集決定データリスト（ＥＤＬ；Edit Decision List)を入力し、そのデータで指示された通りにカットの並びを自動的に連続再生して１つにまとめる（自動アセンブリ）編集機能に関する。
【背景技術】
【０００２】
放送局などにおいて、収録素材に対して行なわれる編集作業の一般的な工程を図１に示す。なお、図１では、収録素材の記録媒体としてテープを仮定している。
最初の工程であるワークコピーは、実際の編集作業の前段にあたる作業で、これから行なう編集作業用にオリジナルの収録素材（オリジナルテープ）のコピー（ワークテープ）を作成する工程である。
ワークコピー後の編集工程は、オフライン編集とオンライン編集の２段階に分かれる。オフライン編集とは、実際のマルチメディア情報の加工処理以外の編集作業のことで、作品の構成を練り、マルチメディア情報に加工を施す箇所（編集点）や加工方法の決定を行なう工程である。オンライン編集では、オフライン編集の決定どおりに、マルチメディア情報を加工処理し、最終的な作品を完成させる。
オンライン編集において、マルチメディア情報を加工処理する際の処理内容には様々なものがあるが、本発明は、素材となるマルチメディア情報から幾つかの特定のシーンを切り出し、それらをつなぎ合わせる作業であるカット編集に関するものである。
さらに、一般にカット編集を行なう方法として、ＶＴＲなどの再生装置の手動操作に基づくものと、オフライン編集工程の結果決定した切り出すカットのならびを記述したデータであるＥＤＬ（Edit Decision List)を再生装置に入力して、自動的に行なう方法（自動アセンブリ）とがあるが、本発明は、後者に関するものである。
【０００３】
ＥＤＬとは、放送業務等で使用される編集装置で幅広くサポートされている編集指示データで、図２のような構造をしたテキストデータである。
１つ行のplay_in、play_out、rec_in、rec_outの４つの数値の組が１つのカットに対応している。これらの数値は、全て映像信号のフレームに付与されているタイムコード（ＴＣ）で、ＥＤＬの１つの行は、ワークテープ内のplay_inのタイムコードが付与された映像フレームから始まってplay_outのタイムコードが付与された映像フレームで終わるカットを、rec_inから始まってrec_outで終わるタイムコードを付与して編集テープに記録せよ、という指示を表している。図３に、タイムコード（ＴＣ）の構造を示す。
この４つの数値の組から成る行が、取り出したいカットの数だけ並んでいる。なお、ここでいう映像フレームとは、１画面分の映像データのことで、例えば、ＨＤＴＶの規格では、１秒間に２９．９７回、あるいは、３０回（ＨＤＴＶにも複数の種類の規絡が存在し、規格毎にフレームレートは異なる）表示される画面データのことを指す。
ＥＤＬには、このタイムコードの他にも編集指示に関する幾つかの情報が含まれている。このうち、リールナンバーは、マルチメディア情報のソースが複数ある楊合に、ソースを特定するための番号で、例えば、映像ソースに複数のテープを使用しているような場合は、それぞれのカットのソースとなるテープを識別する番号である。
ＥＤＬに含まれるその他の情報については本特許の内容に関係しないため、それらの説明は割愛する。
【０００４】
図４に標準的なオンライン編集装置の構成を示す。この図４に示す編集装置は、マルチメディア情報の記録媒体にテープメディアを用い、ＶＴＲ６により編集データの入ったテープを再生しながら、一方で、編集済みデータを格納するテープヘと録画する形で、テープからテープヘとマルチメディア情報を転送して編集作業を行なうタイプのものである。
Ｉ／Ｏインタフェース５として、ＲＳ４２２のシリアルインタフェースを介して、ＶＴＲ６が中央制御部１に複数接続されている。中央制御部１は、このシリアルインタフェースを介して、ＶＴＲ６に制御信号を送信し、ＶＴＲ６を操作する。
ルーティングスイッチャ８は、マルチメディア情報の伝送路で、中央制御部１からの制御によりスイッチの接続構成が変更できる。
図４中のＭＩＸ’ｅｒ７、ＶＴＲ６、スピーカ９、ビデオモニター１０のマルチメディア情報送受信用の信号線（図中の太線）はルーティングスイッチャ８に接続され、これによりマルチメディア情報がこれらの装置間でスイッチングされる。
ＭＩＸ’ｅｒ７は、音声合成に用いられる装置で、スピーカ９、ビデオモニター１０は、それぞれ音声／映像のモニタに用いられる。また、表示部３は中央制御部１のモニタに用いられる。
【０００５】
本装置を用いたオンライン編集作業の概要を図５に示す。まず、ワークコピーの工程で作成されたワークテープとオンライン編集の結果を格納するテープがＶＴＲ６にセットされる。
次に、オフライン編集の工程で作成された編集データ（ＥＤＬ）を、ＦＤＤやＨＤＤの内部記録装置４に格納する。これらが完了すると、操作卓２からの指令により編集作業が開始される。
中央制御部１は、ＥＤＬの内容を解釈しながら、ＲＳ４２２のシリアルインタフェースを介してＶＴＲ操作用の制御信号を送信する。
カット編集の場合、基本的には以下の（１）から（４）の動作をＥＤＬで指定された編集内容を実現するまで繰り返し、編集済テープを完成させる。
（１）ＥＤＬのリールナンバーを参照し、対応するワークテープを選択する。
（２）（１）で選択したワークテープの内容が編集結果格納用テープヘ送られるようにスイッチ構成を変更するための制御信号を、ルーティングスイッチャ８に対して発行する。
（３）ＥＤＬで指定されたplay_in点までワークテープを進めるための制御信号をワークテープを格納したＶＴＲ６に対して発行する。
（４）play_inからplay_out点までを再生する制御信号をワークテープを格納したＶＴＲ６に対して発行する。同時に、編集結果格納用テープを格納したＶＴＲ６に対して、ワークテープからルーティングスイッチャを介して送られてきたマルチメディア情報を、rec_in点からrec_out点へ録画するための制御信号を発行する。
【０００６】
図６は、マルチメディア情報の蓄積装置にハードディスクドライブ（ＨＤＤ）を用いる編集装置の例である。
図４に示す編集装置は、マルチメディア情報の蓄積にテープメディアを使用しているため、マルチメディア情報の蓄積・再生時に記録装置に対してリニアアクセス（記録メディアに対し、ある点から前に進む、あるいは、後ろに戻るかのどちらかの一次元的なアクセス方法）しかできない。
これに対し、図６に示す編集装置のＨＤＤで構成される蓄積装置１１は、任意の箇所へのランダムなアクセスが可能なため、図６のような編集装置は、一般に、ノンリニア編集装置と呼ばれ、図４のタイプの編集装置に代わって主流になりつつある。
このタイプの編集装置の本体（中央制御装置）１は、パーソナルコンピュータ（以下、ＰＣという。）やワークステーション（以下、ＷＳという。）などの汎用小型計算機からなるハードウェアに、編集機能を実現したソフトウェアを搭載したものとなっている。
この中央制御装置１に、オリジナルの収録素材を供給するためのＶＴＲ６と、ワークコピーの結果生成されるマルチメディア情報（テープメディアの場合のワークテープの内容に相当するもの）や編集結果のマルチメディア情報（テープメディアの場合の編集済テープの内容に相当するもの）を格納するための蓄積装置（ＨＤＤ）１１が接続されている。
【０００７】
本装置を用いたオンライン編集作業の概要を図７に示す。
まず、収録素材が入ったテープを格納したＶＴＲ６から、収録素材を蓄積装置１１へ転送する（ワークコピー）。
次に、このようにして蓄積装置１１に格納した素材を随時参照しながら、本装置上でオフライン編集を行なう。なお、ノンリニア編集装置は、主にオフライン編集作業を行なう装置であるが、自動アセンブリによるオンラィン編集も可能である。この編集装置上でオンライン編集も行なうことを想定している場合は、オフライン編集で決定した編集操作内容をＥＤＬとして内部記憶装置４に格納する。
オフライン編集が完了し編集決定内容を記録したＥＤＬが完成すると、中央制御装置１はＥＤＬの指示内容にしたがって、ＨＤＤ上の素材のplay_in点からplay_out点までの内容をメモリ１２に読み込み、rec_in点からrec_outまでのＴＣを付与して、編集済みの新しいファイルとして蓄積装置１１に格納する。このような作業を繰り返してカット編集作業が行なわれる。
ノンリニア編集装置の場合、ワークコピー以外の工程では全て、ランダムアクセス可能な蓄積装置１１上でマルチメディア情報に対するアクセスを行なうため、ＶＴＲ６をベースとした図４のような編集装置よりも効率的な作業が行なえる。
【０００８】
なお、本願発明に関連する先行技術文献としては以下のものがある。
【非特許文献１】君山，小倉，清水，川野，釘本，丸山，”ＰＣクラスタを用いたＩＰベースの非圧縮ＨＤＴＶ10多重ストリームサーバ，”マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ 2005）シンポジウム予稿集，pp.797-800,2005.
【非特許文献２】InfiniBand Network Architecture，Tom Shanley 著，Joe Winkles 編集，Addison-Wesley Pub，ISBN;0321117654.
【非特許文献３】持田，川野，”10ギガビットネットワークにおける非圧縮ＨＤＴＶ映像多重伝送技術「i-Vistoゲートウェイ ＸＧ」，”ＮＴＴ技術ジャーナル，Vol.17,No.2,pp.46-49,Feb.2005.
【発明の開示】
【発明が解決しようとする課題】
【０００９】
図４に示す編集装置においては、マルチメディア情報の記録媒体がリニアアクセスしかできないテープである。このため、オンライン編集時には、ワークテープの１つのカットのplay_in点からplay_out点までを再生して、編集結果格納テープのrec_in点からrec_out点に収録する作業において、この部分の素材の収録時間と同じ作業時間が必ず必要となる。
さらに、ワークテープの１つのカットの再生が終了してから、次のカットの再生を開始するまでに、前のカットのplay-put点から次のカットのplay_in点へのテープ移動に要する時間がかかる。オンライン編集作業に要する時間がこれらの時間に支配されてしまうという問題がある。
さらに、マルチメディア情報の伝送路に関しては、多ポートのルーティングスイッチャ８を使用して比較的自由に装置間の接続を変更できるものの、ＶＴＲ６への制御信号を送信するＲＳ４２２のシリアルインタフェースの信号線については、これを多数収容可能なスイッチャが一般にはなく、中央制御部１とＶＴＲ６との間は基本的に１対１の接続となる。
このため、接続可能なＶＴＲ６の台数が中央制御部のＲＳ４２２のシリアルインタフェース数に制限される、中央制御部１とＶＴＲ６の接続変更が面倒である、という問題がある。
さらに、ＶＴＲ制御には、比較的高速なビットレートのＲＳ４２２信号が一般的に使用されるため、信号線の最大長もあまり長くとれず、ＶＴＲ６と中央制御部１との間の距離にも制約がある。
【００１０】
図６に示すノンリニア編集装置においては、マルチメディア情報の記録媒体にランダムアクセス可能な蓄積装置１１を用いるため、図４に示す編集装置で見られたような、記憶媒体へのアクセス時間に起因する作業効率低下の問題はない。
また、中央制御部１と蓄積装置１１との間の接続インタフェースにファイバチャネルなどをベースとしたＳＡＮ（Storage Area Network）を用いれば、両者間の距離を１０Ｋｍ程度まで伸ばすことができ、ＲＳ４２２信号によるＶＴＲ制御の場合よりも距離の制約は小さい。
また、蓄積装置１１を構成するＨＤＤの容量が許す限りのワークコピーがＨＤＤ上に作成でき、それらをすべて編集に使用することができるので、図４に示す編集装置で見られるようなＶＴＲ６の接続台数の制限に起因するワークコピー数の制限もない。
しかし、中央制御部１に単体のＰＣやＷＳを使用しており、マルチメディア情報の加工処理に加えて、蓄積装置１１を構成するＨＤＤからのマルチメディア情報の読み出し処理、書き込み処理など、あらゆる処理がこの中央制御部１で実行される構成となっている。
このため、単位時間当たりに編集処理できるマルチメディア情報の量が中央制御部１の処理能力で決まってしまい、現在のＰＣやＷＳをベースにしたシステムでは、非圧縮ＨＤＴＶなどの高品質なギガビットクラスの映像ストリーム（実時間伝送する場合に、１秒あたり１ギガビット以上もの伝送速度が必要となる映像）なら同時に１〜２本程度しか扱えないという問題がある。
本発明は、前記従来技術の問題点を解決するためになされたものであり、本発明の目的は、ＶＴＲベースの編集装置に見られるような、記憶媒体へのアクセス時間に起因する作業効率低下の問題、制御信号送信用Ｉ／Ｏインタフェースの接続形態の制約や距離の制約の問題、さらに、ノンリニア編集装置に見られるような、単体の中央制御部から成る構成に起因する処理性能の制約の問題を解決するような、ＥＤＬによるカット編集機能を持つマルチメディア情報編集装置とマルチメディア情報編集方法を提供することにある。
本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述及び添付図面によって明らかにする。
【課題を解決するための手段】
【００１１】
本発明では、前記課題を解決するため、マルチメディア情報の蓄積／再生部分に、例えば、前述の非特許文献１に記載のシステム（ここでは、分散型マルチメディアサーバシステムと呼ぶ）を用いた編集装置を提案する。
図８に、分散型マルチメディアサーバを用いた編集装置のシステム構成例を示す。
本システムは、分散型マルチメディアサーバ２０と、それを制御するための制御端末９５と、各種情報管理用のデータベースサーバ９０、マルチメディア情報の蓄積や配信要求を発行する端末７０と、端末７０と分散型マルチメディアサーバ２０との間でマルチメディア情報を伝送するための配信用ネットワーク４２とを有する。
この配信用ネットワーク４２は、マルチメディア情報を伝送する十分な性能があれば、ＩＰネットワークなどの一般的な通信媒体で良い。制御端末９５、および、データベースサーバ９０は、ＰＣなどの汎用計算機で構成され、これらの接続にもＩＰネットワークなどの一般的な通信媒体を用いる。
まず、図８中の分散型マルチメディアサーバ２０の部分について説明する。
分散型マルチメディアサーバ２０は、バッファサーバ３０、ストレージサーバ５０、蓄積装置（ＨＤＤ）６０、クラスタ間接続ネットワーク４０、および、ローカルエリアネットワーク（ＬＡＮ）４１を有している。
まず、バッファサーバ３０とストレージサーバ５０の間に介在するクラスタ間接続ネットワーク４０について説明する。この部分には、例えば、前述の非特許文献２に記載のInfiniBandを用いる。
本分散型マルチメディアサーバ２０では、前述の非特許文献１に記載のように、InfiniBandが持つ遠隔ダイレクトメモリアクセス機能（ＲＤＭＡ；remote direct memory access）を利用し、ＩＰネットワークなどを使った通信に比べて高遠で低負荷なデータ通信を実現している。
【００１２】
図９および図１０に、ＲＤＭＡによるデータ通信の詳細を示す。
図９は、バッファサーバ上の１つのデータ送信主体３２からストレージサーバ上の１つのデータ受信主体５３ヘマルチメディア情報を転送する際の通信手順である。これは、分散型マルチメディアサーバ２０の蓄積装置６０ヘマルチメディア情報を蓄積する場合に相当する。
まず、バッファサーバ上のデータ送信主体３２は、ストレージサーバ上のデータ受信主体５３に対して、書き込み要求という形でデータの転送先となるストレージサーバ５０内のメモリアドレス情報を要求する。（図９の１０１）
この要求を受信したデータ受信主体５３は、データを受信することが可能な自身のメモリのアドレスについての情報を、メモリアドレス情報として返信する。（図９の１０２）。
そして、このメモリアドレス情報を受信したデータ送信主体３２は、InfiniBandのＲＤＭＡ write機能を用いて、指定されたストレージサーバ５０のメモリアドレス宛てにデータを送信する。（図９の１０３）。
このデータ送信は、宛先のメモリアドレスを直接指定して行なえるため、ＯＳなどの中間ソフトウェアの介在なしに、高速かつ低いＣＰＵ負荷で行なわれる。
【００１３】
図１０は図９とは逆に、ストレージサーバ上の１つのデータ送信主体５２からバッファサーバ上の１つのデータ受信主体３３ヘマルチメディア情報を転送する際の手順を示している。これは、分散型マルチメディアサーバ２０からマルチメディア情報を配信する場合に相当する。
この場合も、データが格納されているストレージサーバ５０のメモリアドレスをバッファサーバ上のデータ受信主体３３から問い合わせた後（図１０の１１１、１１２）、ＲＤＭＡ read機能を起動する形でデータ転送を行なう。（図１０の１１３）
本分散型マルチメディアサーバ２０では、１回のＲＤＭＡ転送でマルチメディアストリームの１つのフレームを転送する。
次に、ローカルエリアネットワーク４１について説明する。
これは、バッファサーバ３０とストレージサーバ５０間で、マルチメディア情報以外のメッセージの交換に用いる。このローカルエリアネットワーク４１は、ＲＤＭＡなどの特殊な機能を持つ必要はなく、ＩＰネットワークなどの一般的な通信媒体で良い。
蓄積装置６０については、図７で述べたノンリニア編集装置が搭載している蓄積装置と同様に、ＨＤＤなどのランダムアクセスが可能な記録装置である。
以上が分散型マルチメディアサーバ２０の各構成要素の説明である。
【００１４】
次に、この分散型マルチメディアサーバ２０における、マルチメディア情報の格納方式である分散ＲＡＩＤ方式について説明する。
図１１は、分散ＲＡＩＤ方式に基づくマルチメディア情報の格納方法を示す図である。
端末７０からストリームを受信したバッファサーバ上のデータ送信主体３２は、ストリーム内のフレームを各ストレージサーバ５０に１つずつ順番にクラスタ間接続ネットワーク４０を介して送信する。
例えば、配信用ネットワーク４２を経由して端末１（７０−１）からマルチメディア情報ストリーム１を受信しているバッファサーバ１上のデータ送信主体３２は、受信したあるフレーム（フレーム＃１とする）を、ストレージサーバ１上のデータ受信主体５３へ転送したとすると、次に受信したフレーム＃２は、ストレージサーバ２（５０−２）へ、さらにその次に受信したフレーム＃３はストレージサーバ３（５０−３）へ、というように順番にフレームを送信していく。
そして、最後のストレージサーバヘのフレーム送信が終ると、次のフレームからは再びストレージサーバ１（５０−１）に戻って順番に送信する動作を繰り返す。
１つのフレームを転送する際の手順は図９に示した通りである。すなわち、バッファサーバ上のデータ送信主体３２は、フレーム転送の宛先となるストレージサーバ上のデータ受信主体５３を毎回変更しながらＲＤＭＡ writeによるフレーム転送を繰り返す。
【００１５】
本方式では、マルチメディア情報のデータは必ず全ての蓄積装置６０にまたがって蓄積される。このような方式は一般に分散ＲＡＩＤ方式と呼ばれる。
なお、ストレージサーバ上のデータ受信主体５３は、バッファサーバ１（３０−１）からフレームを受信する度に、そのフレームのデータを自ストレージサーバ５０に接続された蓄積装置へ書き込んでいく。
図１２は、分散ＲＡＩＤ方式に基づくマルチメディア情報の配信方法を示す図である。
配信の場合、バッファサーバ上のデータ受信主体３３は、各々のストレージサーバ５０のデータ送信主体５２から順番に１つずつフレームを受信し、各々のストレージサーバ５０から受信したフレームを結合して１本のストリームに再構成し、所望の端末７０へと配信する。
１つのフレームを転送する際の手順は図１０に示した通りである。すなわち、バッファサーバ上のデータ受信主体３３は、フレームの供給元となるストレージサーバ５０を毎回変更しながらＲＤＭＡ readによるフレーム転送を繰り返す。
【００１６】
前述のデータ送信主体とデータ受信主体の組を、図１３に示すように、バッファサーバ上、および、ストレージサーバ上に複数搭載すれば、分散型マルチメディアサーバ２０において、分散ＲＡＩＤ方式の枠組のもとで複数のマルチメディア情報ストリームを同時に扱うことが可能となる。
図１３では、マルチメディア情報ストリームの蓄積動作、および、配信動作に応じてデータ送信、受信の動作を切替えることが可能な動作主体（以下、データ通信主体と呼ぶ）３１を各バッファサーバ上に１つ配置し、そのバッファサーバ上のデータ通信主体３１とクラスタ間接続ネットワーク４０を介して、データの送受信を行なうデータ通信主体５１を各ストレージサーバ上に１つずつ配置している。この構成により、バッファサーバ上のデータ通信主体の総数（図１３では３）だけのマルチメディア情報ストリームを同時に扱うことができる。
図１４は、図１３に示す構成のシステム上で、バッファサーバ１（３０−１）でマルチメディア情報ストリームを受信しながら蓄積し、同時にバッファサーバ３（３０−３）から別のマルチメディア情報ストリームを配信している例である。
分散ＲＡＩＤ方式には、同一のマルチメディア情報に対して複数の異なる端末７０から配信要求が発生しても、データの読み出し負荷が各蓄積装置に均等に分散される場合が多いというという利点もある。
これは、同一のマルチメディア情報に対する配信要求であっても、蓄積装置からのフレーム読み出しを行なっているストレージサーバ５０は、各瞬間で要求毎に異なる場合が普通であるためである。
【００１７】
図１５は、この様子を説明する図である。
図１５は、端末１（７０−１）、端末２（７０−２）から同一のマルチメディア情報に対する配信要求が発生した場合を表しているが、端末１（７０−１）への配信を行なうバッファサーバ１（３０−１）がストレージサーバ１（５０−１）の蓄積装置１（６０−１）からフレームデータの読み出しを行なっている（実線）瞬間に、端末２（７０−２）への配信を行なうバッファサーバ３（３０−３）がストレージサーバ２（５０−２）の蓄積装置２（６０−２）からフレームデータの読み出しを行なっている様子を表している。
このように、本方式では、蓄積装置６０へのアクセス負荷を分散することが可能なため、マルチメディア情報へのアクセスパターンに関係なく、性能低下を起こす確率を低く抑えながらマルチメディア情報の蓄積・配信を行なうことができる。
また、このような特徴から、バッファサーバ３０、ストレージサーバ５０、蓄積装置６０、および、バッファサーバ上のデータ通信主体３１やストレージサーバ上のデータ通信主体５１の数を増やす毎に、システム全体として扱えるマルチメディア情報の数もそれらへのアクセスパターンに関係なく増える傾向にあり、拡張性に優れた方式である。
このような利点を有する分散型マルチメディアサーバ２０によるマルチメディア情報の蓄積／配信は、前述の[発明が解決しようとする課題]で述べた課題のうち、単体の中央制御部から成るノンリニア編集装置が有する処理性能の制約の間題を解決する手段を与える。以上が図８における分散型マルチメディアサーバについての説明である。
【００１８】
次に、図８のシステム構成において、カット編集機能を実現する方法を述べる。
本発明では、図８のシステム構成においてカット編集機能を実現するため、図１６に示すように、バッファサーバ上、および、ストレージサーバ上に、太線黒枠に示す要素機能を持ったデータ通信主体（３１，５１）を配置する。
本発明は、データ通信主体（３１，５１）が、これらの要素機能を有していることを特徴とする。なお、図１６の分散型マルチメディアサーバ２０は、Ｎ台のバッファサーバ（３０−１〜３０−ｎ）と、Ｎ台のストレージサーバ（５０−１〜５０−ｎ）から構成され、各バッファサーバ上のデータ通信主体３１は、図１３と同様に、全てのストレージサーバ上のデータ通信主体５１との間でデータ送受信ネットワークを構成する。
すなわち、バッファサーバ１上のデータ通信主体１（３１−１）は、ストレージサーバ上のデータ通信主体１−１（５１−１−１）、データ通信主体２−１（５１−２−１）ないしデータ通信主体Ｎ−１（５１−Ｎ−１）と、バッファサーバ２上のデータ通信主体２（３１−２）は、ストレージサーバ上のデータ通信主体１−２（５１−１−２）、データ通信主体２−２（５１−２−２）ないしデータ通信主体Ｎ−２（５１−Ｎ−２）と、以下同様にして、バッファサーバＮ上のデータ通信主体Ｎ（３１−Ｎ）は、ストレージサーバ上のデータ通信主体１−Ｎ（５１−１−Ｎ）、データ通信主体２−Ｎ（５１−２−Ｎ）ないしデータ通信主体Ｎ−Ｎ（５１−Ｎ−Ｎ）とデータ通信を行なう。
【００１９】
以下に、図１６に示す編集装置の動作を説明する。
先ず、始めに、端末７０からマルチメディア情報のストリームを受信して蓄積装置６０に蓄積するまでの動作を図１７に示す。
配信用ネットワーク４２を経由して端末７０から送信されてくるマルチメディア情報は、フレームと呼ばれるデータ単位が連続したストリームである。
１つ１つのフレームには、フレームを識別するためのシーケンス番号（以下、フレーム番号）、および、タイムコード（ＴＣ）が付与されているものとする。ここでは、バッファサーバ１（３０−１）に対してマルチメディア情報ストリームが送信されてきたものとする。
バッファサーバ１上のデータ通信主体１内のＴＣ／フレーム番号対応記録部１（３５−１）では、１つのフレームを受信する度に、そのフレームのフレーム番号とＴＣの対を、ＴＣ／フレーム番号対応表３７に追記していく。
また同時に、バッファサーバ１上のデータ通信主体１（３１−１）は、宛先のストレージサーバ５０を順番に変更しながら、受信したフレームをストレージサーバ５０へ転送していく。このようにして、フレーム内のマルチメディアデータが蓄積装置６０へ蓄積されていく。
なお、本例では、ストレージサーバ５０ヘフレームを転送する際、フレームのＴＣは転送せず、フレーム番号とフレーム内のマルチメディアデータだけを転送するものとする。これは、ストレージサーバ５０においては、フレーム番号だけでデータの管理を行う方が簡単なためである。
１つのストリームの最後のフレームの受信が終ると、バッファサーバ１上のＴＣ／フレーム番号対応記録部１（３５−１）は、完成したＴＣ／フレーム番号対応表３７をローカルエリアネットワーク４１経由で、制御部８０へ転送する。
これを受信した制御部８０は、受信したＴＣ／フレーム番号対応表３７をデータベースサーバ９０のデータ管理部９２へ転送する。以上で、１本のマルチメディアストリームの受信が完了する。
【００２０】
次に、このようにして蓄積したマルチメディア情報に対し、取り出したいカットをＥＤＬで指定して、それらのカットだけを連続再生する際の動作を図１８に示す。
まず、図２に示した構造を持つＥＤＬが制御部８０へ入力されると、制御部８０はこのＥＤＬをデータベースサーバ９０へ転送する。
ＥＤＬを受け取ったデータベースサーバ９０のプレイリスト作成部９１は、データ管理部９２に保管してあるＴＣ／フレーム番号対応表３７を参照して、ＥＤＬ内のＴＣの並びをフレーム番号の並びに変換した表（プレイリストと呼ぶ）を作成し、これを制御部８０へ転送する。
制御部８０は、このプレイリストを、マルチメディア情報のストリームを端末７０へ向けて配信するバッファサーバ（図１８では、バッファサーバＮ（３０−Ｎ））に対しローカルエリアネットワーク４１を介して転送する。
プレイリストを受信したバッファサーバＮ（３０−Ｎ）は、マルチメディア情報のフレームデータの読み出しを開始する前に、このプレイリストを全てのストレージサーバ５０へ転送する。これにより、各ストレージサーバ５０のフレーム先読み制御部５５は、バッファサーバＮ（３０−Ｎ）からフレームを要求される前に、あらかじめ蓄積装置６０からフレームデータを先読みしておくことができ、フレームデータの読み出し性能を向上させることができる。
ストレージサーバ５０ヘのプレイリストの転送が完了すると、バッファサーバＮ（３０−Ｎ）のプレイリスト解釈部Ｎ（３６−Ｎ）は、プレイリストを参照しながら、フレーム番号を指定してストレージサーバ５０に対しフレームの読み出しを要求する。
【００２１】
そして、ストレージサーバ５０から所望のフレームを受信すると、新しいＴＣ（そのフレームの、当該カットの先頭フレームからのオフセットに相当する時間だけ、rec_inの値から時間をずらしたＴＣ）をそのフレームに対して付与したのち、配信用ネットワーク４２を介して、マルチメディア情報受信端末へ配信する。
以降、バッファサーバＮ（３０−Ｎ）からのフレーム転送要求に、各ストレージサーバ５０がこのように応答する形で、所望のフレームのみが配信され、カット編集動作が実現される。
以上述べた編集装置と、この編集装置の制御方法によれば、分散型マルチメディアサーバ２０により複数のマルチメディア情報の蓄積／配信が可能となるため、単体の中央制御部から成るノンリニア編集装置が有する処理性能の制約の問題を解決できる。
また、マルチメディア情報の蓄積装置として、ランダムアクセス可能なＨＤＤを用いるため、ＶＴＲベースの編集装置に見られるような記憶媒体へのアクセス時間に起因する作業効率低下の問題も解決される。
さらに、マルチメディア情報の蓄積／配信を行なう分散型マルチメディアサーバ２０を制御する制御部８０は、ＩＰネットワークなどの伝送距離や接続変更の自由度が高いネットワーク媒体を使用可能なため、ＶＴＲをシリアルインタフェースで制御するリニア編集装置で見られるような、制御信号送信用Ｉ／Ｏインタフェースの接続形態の制約や距離制約の問題も解決できる。
【発明の効果】
【００２２】
本願において開示される発明のうち代表的なものによって得られる効果を簡単に説明すれば、下記の通りである。
本発明によれば、分散型マルチメディアサーバにより複数のマルチメディア情報の蓄積／配信が可能となり、マルチメディア情報の処理性能を向上させることが可能となる。
また、マルチメディア情報の蓄積装置にＨＤＤ等のランダムアクセス可能な記録媒体を用いるため、記録媒体へのアクセス時間に起因する作業効率低下の問題もない。
さらに、マルチメディア情報の蓄積／配信を行なう分散型マルチメディアサーバを制御する制御部は、ＩＰネットワークなどの伝送距離や接続変更の自由度が高いネットワーク媒体を使用可能なため、制御信号の送信路の接続形態の制約や距離の制約の問題がなく、システム構成の柔軟性を向上させることが可能となる。
【発明を実施するための最良の形態】
【００２３】
以下、図面を参照して本発明の実施例を詳細に説明する。
なお、実施例を説明するための全図において、同一機能を有するものは同一符号を付け、その繰り返しの説明は省略する。
[実施例１]
図１９は、本発明の実施例１のシステム構成を示すブロック図である。本実施例では、マルチディア情報を送受信する端末に、前述の非特許文献３に記載の映像／ＩＰ変換装置７１を用いる。
この映像／ＩＰ変換装置７１は、ハイビョンテレビ（ＨＤＴ）用のＨＤ−ＳＤＩや、標準テレビ信号用のＳＤ−ＳＤＩなどの信号線上を伝送されるデジタル映像信号と、インターネットなどで用いられるＩＰパケットとの相互変換を行なう装置である。
本実施例では、この映像／ＩＰ変換装置７１は、ＨＤ−ＳＤＩ信号線を介して、非圧縮のＨＤＴＶ映像信号を扱うものとする。
映像／ＩＰ変換装置１（７１−１）には、ＨＤ−ＳＤＩの信号線経由でＨＤＴＶ用のＶＴＲ７２が接続されており、ここから分散型マルチメディアサーバ２０へ蓄積する素材映像が送信されるものとする。
映像／ＩＰ変換装置２（７１−２）および映像／ＩＰ変換装置３（７１−３）には、ＨＤ−ＳＤＩの信号線経由でＨＤＴＶ用モニタ７３が接続されており、分散型マルチメディアサーバ２０から配信されてきた映像を受信し、モニタできるものとする。なお、制御部１（８０−１）、制御部２（８０−２）、制御部３（８０−３）は、それぞれ映像／ＩＰ変換装置１（７１−１）、映像／ＩＰ変換装置２（７１−２）、映像／ＩＰ変換装置３（７１−３）を操作する作業者が専用に用いる。
【００２４】
配信用ネットワーク４２とローカルエリアネットワーク４１には、ＩＰネットワークを用いる。配信用ネットワーク４２は、ＩＰパケット化された非圧縮ＨＤＴＶの映像信号を実時間伝送する際のデータ転送速度（約１．５Ｇｂｐｓ）に十分耐えられる伝送速度を有するものとする。
配信用ネットワーク４２とローカルエリアネットワーク４１は相互に接続されているが、ローカルエリアネットワーク４１上には映像信号は流れず、制御信号だけを流すものとする。このため、ローカルエリアネットワーク４１は配信用ネットワーク４２よりも低速度なネットワークでよい。
分散型マルチメディアサーバ２０は、バッファサーバ３０、および、ストレージサーバ５０それぞれＮ台から構成されており、これらのバッファサーバ３０とストレージサーバ５０同士がクラスタ間接続ネットワーク４０で相互接続されている。
各バッファサーバ上、および、ストレージサーバ上には、図１６と同様にデータ通信主体が存在し、各バッファサーバ上のデータ通信主体（３１−１〜３１−Ｎ）は、全てのストレージサーバ上のデータ通信主体（５１−１〜５１−Ｎ）との間でデータ送受信ネットワークを構成する。
すなわち、バッファサーバ１上のデータ通信主体１（３１−１）は、ストレージサーバ上のデータ通信主体１−１（５１−１−１）、データ通信主体２−１（５１−２−１）ないしデータ通信主体Ｎ−１（５１−Ｎ−１）と、バッファサーバ２上のデータ通信主体２（３１−２）は、ストレージサーバ上のデータ通信主体１−２（５１−１−２）、データ通信主体２−２（５１−２−１）ないしデータ通信主体Ｎ−１（５１−Ｎ−２）と、以下、同様にして、バッファサーバＮ上のデータ通信主体Ｎ（３０−Ｎ）は、ストレージサーバ上のデータ通信主体１−Ｎ（５１−１−Ｎ）、データ通信主体２−Ｎ（５１−２−Ｎ）ないしデータ通信主体Ｎ−Ｎ（５１−Ｎ−Ｎ）とデータ通信行なう。
なお、クラスタ間接続ネットワーク４０は、分散型マルチメディアサーバ内部における映像データの転送路となるため、これも非圧縮ＨＤＴＶ映像を伝送可能な速度を有するものとする。本実施例では、InfiniBandを用いるものとする。
【００２５】
バッファサーバ上のデータ通信主体（３１−１〜３１−Ｎ）とストレージサーバ上のデータ通信主体（５１−１〜５１−Ｎ）は、図９、図１０に示した方式で映像フレームの伝送を行なう。
図２０に、バッファサーバ上、および、ストレージサーバ上の各データ通信主体の内部構成を示す。通信主体制御部（３１ａ，５１ａ）は、外部の端末と制御信号をやりとりする構成要素である。
バッファサーバ上のデータ通信主体（３１−１〜３１−Ｎ）のＩＰ送受信部３１ｂは、配信用ネットワーク４２を介して、映像／ＩＰ変換装置７１からＩＰパケットを受信して、それらを映像フレームに再構成する処理、あるいは、映像フレームをＩＰパケットに分割してそれらを配信用ネットワーク４２を介して、映像／ＩＰ変換装置７１へ送信する処理を行なう。クラスタ内送受信部（３１ｃ、５１ｃ）は、図９、１０に示した方式で映像フレームを送受信する構成要素である。
ストレージサーバ上のデータ通信主体（５１−１〜５１−Ｎ）の蓄積装置制御部５１ｂは、ストレージサーバ５０に接続された蓄積装置６０にアクセスし、映像フレームをファイルの形で蓄積装置６０上に格納したり、逆にファイルの形で蓄積されているデータを読み出して映像フレームの形にする構成要素である。
データバッファ（３１ｄ，５１ｄ）は、配信用ネットワーク４２を介して送受信されるＩＰパケット、および、クラスタ間接続ネットワーク上を伝送される映像フレームの一時的な格納場所である。
各バッファサーバ３０は、ローカルエリアネットワーク４１、クラスタ間接続ネットワーク４０、および配信ネットワークと接続されている。
また、各ストレージサーバ５０は、ローカルエリアネットワーク４１、クラスタ間接続ネットワーク４０、および、蓄積装置６０と接続されている。
【００２６】
以下では、先ず始めに、マルチメディア情報を映像／ＩＰ変換装置１（７１−１）から分散型マルチメディアサーバ２０へ送信し、分散型マルチメディアサーバ２０内の蓄積装置６０へ映像データを蓄積するまでの動作を説明する。
図２１に、本実施例において、映像データの蓄積が開始されるまでの制御信号の流れ（正常終了時のメッセージシーケンス）を示す。
映像／ＩＰ変換装置１（７１−１）を操作してマルチメディア情報を分散型マルチメディアサーバ２０に蓄積しようとする作業者は、まず、制御部１（８０−１）からデータベースサーバ９０へ問い合わせを行ない（図２１の１２１）、これから蓄積しようとするマルチメディア情報のストリームに対する新規のストリームＩＤの割り当て、および、マルチメディア情報の送信先となるバッファサーバ３０の指定を受ける。（図２１の１２２）なお、データベースサーバ９０が、これらの情報を管理・指定する具体的な方法については、本明細書では規定しない。ここでは、バッファサーバ１（３０−１）が指定されたものとする。
これらの情報を受け取ると、次に、制御部１（８０−１）から指定されたバッファサーバ１（３０−１）の通信主体制御部１（３１ａ−１）に対して蓄積動作の開始要求を発行する。（図２１の１２３）
【００２７】
この蓄積開始要求には、データベースサーバ９０から割り当てを受けた新規のストリームＩＤが含まれる。
この蓄積開始要求は、制御部１（８０−１）から配信用ネットワーク４２、および、ローカルエリアネットワーク４１を経由して、バッファサーバ１上の通信主体制御部１（３１ａ−１）へ到達する。
この蓄積開始要求を受信したバッファサーバ１上の通信主体制御部１（３１ａ−１）は、ストレージサーバ１（５０−１）からストレージサーバＮ（５０−Ｎ）の全てのストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）に対して蓄積開始要求を発行する。（図２１の１２４）
この蓄積開始要求にも、前述のストリームＩＤが含まれる。この発行が完了すると、全てのストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）から蓄積開始正常通知が返されるのを待つ。
蓄積開始要求を受信した各ストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）は、自ストレージサーバ５０の蓄積装置上に映像データが正常に蓄積できることが確認できれば、バッファサーバ１上の通信主体制御部１（３１ａ−１）に対して蓄積開始正常通知を返信する。（図２１の１２５）そして、映像データ受信待ち状態へ移る。
バッファサーバ１上の通信主体制御部１（３１ａ−１）は、全てのストレージサーバ５０から蓄積開始正常通知を受信することができた場合には、制御部１（８０−１）へ正常開始通知を送信する。（図２１の１２６）
【００２８】
図２２に、本実施例において、映像データの蓄積が開始されるまでの制御信号の流れ（異常終了時のメッセージシーケンス）を示す。
図２２の１３１から１３４までは、図２１と同じであるので再度の説明は省略する。
もし蓄積装置６０に何らかの異常があれば、各ストレージサーバ上の通信主体制御部５１ａは、バッファサーバ１上の通信主体制御部１（３１ａ−１）に対して蓄積開始異常通知を返信する。（図２２の１３５）
バッファサーバ３０上の通信主体制御部１（３１ａ−１）は、蓄積開始異常通知を返信してきたストレージサーバ５０が１つでもあれば、全てのストレージサーバ上の通信主体制御部５１ａに対して蓄積終了要求を送信し（図２２の１３６）、全てのストレージサーバ上の通信主体制御部５１ａから蓄積終了通知を受信（図２２の１３７）した後、制御部１（８０−１）へ異常終了通知を返信し（図２２の１３８）、動作を終了する。
また、制御部１（８０−１）は、データベースサーバ９０に対して異常終了通知を返信する。（図２２の１３９）
【００２９】
バッファサーバ３０上の通信主体制御部１（３１ａ−１）のここまでの動作を図２３のフローチャートに示す。
図２３のステップ１４０〜ステップ１４２により、制御部１（８０−１）からの蓄積動作開始要求を判断し、図２３のステップ１４３〜ステップ１４６により、全てのストレージサーバ上の通信主体制御部５１ａに対して蓄積開始要求を発行する。
そして、図２３のステップ１４７〜ステップ１５０により、全てのストレージサーバ上の通信主体制御部５１ａから蓄積開始応答を受信し、図２３のステップ１５１により、当該蓄積開始応答が全て蓄積開始正常応答か否かを判断する。
図２３のステップ１５１において、全て蓄積開始正常応答であれば、図２３のステップ１５７において、制御部に正常開始通知を送信する。
図２３のステップ１５１において、蓄積開始異常通知が１つでもあれば、図２３のステップ１５２〜ステップ１５５により、全てのストレージサーバ上の通信主体制御部５１ａに対して蓄積終了要求を送信し、図２３のステップ１５６において、制御部へ異常終了通知を返信する。
前述の作業者は、データベースサーバから送信先のバッファサーバ番号を通知された後、任意の時点で映像／ＩＰ変換装置１（７１−１）からバッファサーバ１（３０−１）への映像データの送信を開始できる。
【００３０】
図２４に、映像／ＩＰ変換装置１（７１−１）が配信用ネットワーク４２へ映像データを送信する場合の動作を示す。ＨＤＴＶ ＶＴＲからＨＤ−ＳＤＩ信号線上を伝送されるＨＤＴＶデジタル映像信号は、フレームと呼ばれる単位で伝送されている。
これは、１画面分の映像データを含んだデータ単位で、例えば、ＨＤＴＶの規格では、１つのフレームのサイズは約６メガバイトであり、１秒あたり、２９．９７レーム、あるいは３０フレームなどのフレームレートで伝送される。１つ１つのフレームには、図３に示した構造を持つタイムコード（ＴＣ）が付与されている。
ＨＤＴＶ ＶＴＲからＨＤ−ＳＤＩ信号線を介して、映像／ＩＰ変換装置１（７１−１）に到着したフレームは、そのままのデータサイズ（約６メガバイト）では大き過ぎて、通常ＩＰネットワーク上へ送信することはできない。このため、映像／ＩＰ変換装置１（７１−１）は、受信したフレームをより小さいサイズのデータ単位であるＩＰパケットに分割する。そして、それらのＩＰパケットを配信用ネットワーク４２を経由してバッファサーバ１（３０−１）へ向けて送信する。
配信用ネットワーク４２に、１０Ｇｂｐｓイーサネットを想定した場合、各ＩＰパケットのサイズは数キロバイト程度の大きさとなる。
【００３１】
図２４に示すように、映像／ＩＰ変換装置１（７１−１）は、映像フレームをＩＰパケットに分割する際、まず、受信した各フレームに対して連続した値の整数値（以下、フレーム番号と呼ぶ）を仮想的に付与する。
フレーム番号を新たに付与する理由は、分散型マルチメディアサーバ２０の蓄積装置上にフレームデータが蓄積された後でデータ管理を行なう際、ＴＣよりもフレーム番号に基づく管理方式の方が簡明であるためである。
そして、このフレームをＩＰパケットに分割する際、各ＩＰパケットのヘッダ部分に、このフレーム番号とタイムコード（ＴＣ）、および、そのＩＰパケットがフレームから生成された幾つめかパケットであるかを示すパケット番号（０スタートとする）、そのＩＰパケットが元のフレームから生成された最後のパケットであるか否かを示す最終パケットフラグ（１の場合は最終パケット、０の場合はそれ以外とする）を格納する。
したがって、同一のフレームから生成されたＩＰパケットには全て、同じフレーム番号とＴＣが格納されている。また、各ＩＰパケットのペイロード（データ部分）には、元のフレームの映像データを順次格納していく。
このようにして、ＨＤ−ＳＤＩ信号線上の映像フレームは、ＩＰパケットに変換され、配信用ネットワーク４２を経由してバッファサーバ３０上のＩＰ送受信部１へ送信される。
図２４では、ＨＤＴＶの１つの映像フレームがパケット番号０からＭまでの（Ｍ＋１）個のＩＰパケットに分割された様子を表している。
【００３２】
次に、バッファサーバ１（３０−１）のＩＰ送受信部１（３１ｂ−１）の動作を説明する。
まず、ＩＰ送受信部１（３１ｂ−１）を制御するバッファサーバ上の通信主体制御部１（３１ａ−１）の動作のフローチャートを図２５（図２３の続き）に示す。
また、バッファサーバ３０のＩＰパケット受信時の動作の概要を図２６に示し、その時のバッファサーバ上のＩＰ送受信部１（３１ｂ−１）、クラスタ内送受信部１（３１ｃ−１）の動作を表すフローチャートをそれぞれ図２７、図２８に示す。
図２５のステップ１６１、ステップ１６２において、制御部１（８０−１）へ正常開始通知を通知した通信主体制御部１（３１ａ−１）は、同じデータ通信主体内のクラスタ内送受信部１（３１ｃ−１）とＩＰ送受信部１（３１ｂ−１）に対して蓄積動作の開始を指示する。
図２７のステップ１８１、ステップ１８２により、通信主体制御部１（３１ａ−１）からの蓄積動作開始指示を受けたＩＰ送受信部１（３１ｂ−１）は、図２７のステップ１８３〜ステップ１８６により、まず配信用ネットワーク４２からパケット番号０のパケットが到着するまで、それまでに受信したＩＰパケットを廃棄する。これは、映像フレームの途中のＩＰパケットから受信動作を開始するのを防ぐためである。
なお、本実施例における配信用ネットワーク４２上では、ＩＰパケットの順序入れ換えや損失は起こらないものとする。すなわち、映橡／ＩＰ変換装置１（７１−１）から送信されたＩＰパケットは、途中で失われることなく、送信されたままの順番でバッファサーバ３０に到着する。
【００３３】
そして、パケット番号が０のパケットを受信すると、図２７のステップ１８７〜ステップ１９５により、受信したＩＰパケットの映像データを１つに繋げて元のフレームを再構築する処理を開始する。ＩＰパケットをフレームに再構築する理由は、蓄積装置６０に蓄積された映像データは、それ以降もブレーム単位で扱われることが多いことと、クラスタ間接続ネットワーク４０上で１回のＲＤＭＡで転送するデータのサィズが大きい方が転送効率が良いことによる。
このフレーム再構築処理の概要を図２６に示す。
ＩＰ送受信部１（３１ｂ−１）は、ＩＰパケットを受信する度に、その中の最終パケットフラグの値をみて、このフラグの値が１であるＩＰパケットを受信するまで、ＩＰパケットのペイロードに含まれる映像データを１つ繋げてフレームを再構築する処理を繰り返す。最終パケットフラグの値が１であるＩＰパケットの受信が完了すると、１つのフレームの再構築が完了する。
再構築されたフレームには、１フレーム分の映像データの他に、ＩＰパケットに格納されていたフレーム番号、および、蓄積動作開始要求メッセージとともに渡されたストリームＩＤが付加情報として含まれている。
図２７のステップ１８９〜ステップ１９２により、１つのフレームの先頭のＩＰパケットを受信する度に、ＩＰ送受信部内のＴＣ／フレーム番号対応記録部３５では、そのフレームのフレーム番号、ＴＣ、および、転送先ストレージサーバ５０番号から成る３つの数値の組を、ＴＣ／フレーム番号対応表３７に記録する。この表の用途については後述する。
【００３４】
このように、図２７のステップ１９６〜ステップ１９９により、ＩＰ送受信部１（３１ｂ−１）は、同じデータ通信主体内の通信主体制御部１（３１ａ−１）から蓄積終了指示を受信するまで、ＩＰパケットの受信とフレーム再構築の動作を繰り返す。
データバッファ１（３１ｄ−１）内に再構築が完了したフレームが存在すると、クラスタ内送受信部１は、それをストレージサーバ５０へ転送する。なお、本明細書では、データバッファの具体的な管理方法については規定しない。
図２８のステップ２０１、ステップ２０２により、バッファサーバ１上のクラスタ内送受信部１（３１ｃ−１）は、同じデータ通信主体内の通信主体制御部１（３１ａ−１）から蓄積動作開始指示を受信すると、図２８のステップ２０３〜ステップ２０８により、バッファサーバ１上のクラスタ内送受信部１（３１ｃ−１）は、フレームの転送先となるストレージサーバ５０を１つのフレームの転送毎に順番に変更しながら、クラスタ間接続ネットワーク４０が持つＲＤＭＡ write機能を用いて、当該ストレージサーバ５０上の対向のデータ通信主体内データバッファ５１ｄヘフレームを転送する。
フレーム転送毎に宛先のストレージサーバ５０を変更することにより、映像データが複数のストレージサーバ５０上の記録装置に分散して格納される。
以上が、バッファサーバ３０の映像データ蓄積時の動作説明である。
【００３５】
次に、ストレージサーバ５０の動作を説明する。
ストレージサーバ５０の映像データ蓄積動作の概要を図２９に、ストレージサーバ上のデータ通信主体１−１（５１−１−１）の通信主体制御部１（５１ａ−１−１）の蓄積時の動作フローを図３０に、クラスタ内送受信部１−１（５１ｃ−１−１）の蓄積時の動作フローを図３１に、蓄積装置制御部１−１（５１ｂ−１−１）の蓄積時の動作フローを図３２に示す。
図３０のステップ２１０〜ステップ２１５により、ストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）は、バッファサーバ上の通信主体制御部１（３１ａ−１）からの蓄積開始要求に対して、自ストレージサーバ５０の蓄積装置６０に正常なデータ蓄積が可能であることを確認し、同じデータ通信主体内の蓄積装置制御部１−１（５１ｂ−１−１）とクラスタ内送受信部１−１（５１ｃ−１−１）に動作の開始を指示した後、蓄積開始正常通知を返信する。
図３１のステップ２３１により、前述の動作開始指示を受けたクラスタ内送受信部１−１（５１ｃ−１−１）は、図３１のステップ２３２〜ステップ２３５に示すように、対向のバッファサーバ１上のクラスタ内送受信部１（３１ｃ−１）からのフレーム書き込み要求が到着する度に、自データバッファ上にフレームを受信するための空き領域があることを確認したのち、当該バッファサーバ上のクラスタ内送受信部１（３１ｃ−１）に対して、その空き領城のアドレスを含んだメモリアドレス情報を返信する。
この後、当該バッファサーバ１上のクラスタ内送受信部１（３１ｃ−１）のＲＤＭＡ   write動作により、フレームがデータバッファ内の前述の空き領域に転送される。以降、通信主体制御部１−１（５１ａ−１−１）から蓄積停止指示を受けるまでこの動作を繰り返す。
【００３６】
蓄積装置制御部１−１（５１ｂ−１−１）は、図３２のステップ２４１、ステップ２４２により、通信主体制御部１−１（５１ａ−１−１）から動作開始指示を受けると、図２９に示すように、バッファサーバ１（３０−１）から受信したフレームのペイロードから映像データを取り出し、それを記録装置上のファイルに書き込み、映像データを蓄積する。
図３２のステップ２４３〜ステップ２４９により、データバッファ１−１（５１ｄ−１−１）に未処理のフレームがあると、それが当該ストリームの自ストレージサーバ１（５０−１）における最初の受信フレームであった場合は、蓄積装置上に新しくファイルをオープンし、そのファイルの先頭にフレーム内の映像データを格納するとともに、その先頭フレームのフレーム番号を記録する。
以降、自データバッファ上に存在する同じストリームのフレームについて、前述の先頭フレーム番号と当該フレームのフレーム番号の差によって定まるオフセットを計算し、前述のファイルの先頭位置からこのオフセットだけ離れた位置に当該フレームの映像データを格納する処理を繰り返す。
【００３７】
前述のオフセットの計算方法は、Ｎをシステム内のストレージサーバ５０の総数として、まず、[（受信フレームのフレーム番号−先頭フレームのフレーム番号）／Ｎ]の計算式によって、当該フレームが自ストレージサーバ１（５０−１）に格納される当該ストリームのフレームの中で何番目のフレーム（先頭フレームは０番目とする）であるかを求め、この値にフレームサイズを乗ずることで求める。
蓄積装置制御部１−１（５１ｂ−１−１）は、前述の処理を繰返し、図３２のステップ２５０、ステップ２５１により、通信主体制御部１−１（５１ａ−１−１）から蓄積停止指示を受けると、当該ファイルをクローズして動作を終了する。
以上が分散型マルチメディアサーバ２０における映像データの蓄積処理の概要である。
本蓄積処理は、映像データを受信しているバッファサーバ上の通信主体制御部１（３１ａ−１）に対して制御部１（８０−１）から蓄積終了要求を発行することで終了する。
【００３８】
蓄積処理終了時の制御情報のシーケンスを図３３に示す。
図２５のステップ１６３において、制御部１（８０−１）から蓄積終了要求を受信（図３３の２６０）したバッファサーバ１上の通信主体制御部１（３１ａ−１）は、図２５のステップ１６４、ステップ１６５により、同じデータ通信主体のＩＰ送受信部１（３１ｂ−１）、並びに、クラスタ内送受信部１（３１ｃ−１）に対して蓄積動作の終了指示を発行する。
そして、図２５のステップ１６６〜ステップ１６９により、全てのストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）に対して蓄積終了要求を発行し（図３３の２６１）、これらの応答を待つ。
図３０のステップ２１６において、蓄積終了要求を受信した各ストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）は、図３０のステップ２１７、ステップ２１８により、同じデータ通信主体内の蓄積装置制御部１−１（５１ｂ−１−１）ないし蓄積装置制御部Ｎ−１（５１ｂ−Ｎ−１）と、クラスタ間送受信部１−１（５１ｃ−１−１）ないしクラスタ間送受信部Ｎ−１（５１ｃ−Ｎ−１）に対して蓄積動作の停止指示を発行する。
この蓄積動作の停止指示を受けた蓄積装置制御部１−１（５１ｂ−１−１）ないし蓄積装置制御部Ｎ−１（５１ｂ−Ｎ−１）は、図３２のステップ２５０、ステップ２５１により、記録装置上に映像データの蓄積用にオープンしていたファイルをクローズする。
蓄積装置制御部１−１（５１ｂ−１−１）ないし蓄積装置制御部Ｎ−１（５１ｂ−Ｎ−１）と、クラスタ間送受信部１−１（５１ｃ−１−１）ないしクラスタ間送受信部Ｎ−１（５１ｃ−Ｎ−１）の動作が停止すると、図３０のステップ２１９により、ストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）は、バッファサーバ１上の通信主体制御部１（３１ａ−１）に対して蓄積終了通知を返信する。（図３２の２６２）
【００３９】
図２５のステップ１７０〜ステップ１７４により、バッファサーバ１上の通信主体制御部１（３１ａ−１）は、全てのストレージサーバ上の通信主体制御部１−１（５１ａ−１−１）ないし通信主体制御部Ｎ−１（５１ａ−Ｎ−１）より蓄積終了通知を受信すると、制御部１（８０−１）に対して蓄積終了通知を送信する。（図３２の２６３）
このとき、図２７のステップ２００に示すように、この蓄積終了通知と一緒に、ＴＣ／フレーム番号対応表記録部１（３５−１）で作成したＴＣ／フレーム番号対応表３７を制御部１（８０−１）に対して送信する。
図３４はこのＴＣ／フレーム番号対応表の例である。
この例は、ストレージサーバ５０が０番から４番までの５台存在し、６時２５分３０秒丁度にフレーム番号２３４５６７９番のフレームからストリームの受信を開始した場合の例である。
バッファサーバ１上の通信主体制御部１（３１ａ−１）から蓄積終了通知を受信した制御部１（８０−１）は、この蓄積終了通知と一緒に受信したＴＣ／フレーム番号対応表３７をデータベースサーバ９０に送信する。（図３３の２６４）
データベースサーバ９０に送信されたＴＣ／フレーム番号対応表３７は、最終的に同データベースサーバ９０内のデータ管理部９２に格納される。
この時点で映像データの蓄積処理が全て完了する。以上が映像データの蓄積処理の説明である。
【００４０】
次に、分散型マルチメディアサーバ２０内に蓄積された映像データの再生処理について説明する。
ここでは、図１９中の映像／ＩＰ変換装置２（７１−２）と制御部２（８０−２）を操作する作業者が、分散型マルチメディアサーバ２０に蓄積された１つの映像ストリームの中から再生したい部分映像（カットの並び）をＥＤＬによって指定し、分散型マルチメディアサーバ２０が指定された部分映像だけを配信用ネットワーク４２に送信し、映像／ＩＰ変換装置２（７１−２）を経由してモニタ上に再生されるまでの流れを例に説明する。
なお、以降の説明には、映像ストリームの部分映像だけでなく全映像を再生する場合も含まれるものとする。すなわち、本実施例においては、映像ストリームの全映像を再生する場合は、映像ストリームの全映像を１カットとして指定したＥＤＬを用いて再生処理を行なうものとする。
まず、図３５に映像データの再生動作開始時のメッセージシーケンスを示す。
映像データの再生を要求する作業者は、ＥＤＬを含んだ再生開始要求を、制御部２（８０−２）からデータベースサーバ９０に対して送信する。（図３５の２７１）
このＥＤＬで、分散型マルチメディアサーバ２０に蓄積されている複数の映像データ（ファイル）の中から、再生したい映像データ（ファイル）を特定し、さらに、その映像データ（ファイル）の中から切り出したいカットの並びを指定する。
【００４１】
この再生開始要求を受信したデータベースサーバ９０のプレイリスト作成部９１は、受信したＥＤＬと、自データベースサーバ９０内のデータ管理部９２に格納されている複数のＴＣ／フレーム番号対応表３７を用いて、ＥＤＬで指定された各カットのplay_in、play_outのタイムコード（ＴＣ）を、そのタイムコードが付与された映像フレームのフレーム番号に変換したリスト（プレイリストと呼ぶ）を作成する。プレイリストは、図３６に示すように、再生したい各カットの情報を並べた構成となっている。
本分散型マルチメディアサーバ２０は、蓄積装置６０上に格納した映像データの管理を、フレームに付与されていたＴＣではなくフレーム番号で行う。そのため、プレイリストでは、ＥＤＬ内の各カットのplay_in、play_outのＴＣを、start_frame、end_frameのフレーム番号に変換している。
プレイリスト内の各カットは、以下のような情報から構成される。
先ず、ストリームＩＤは、そのカットを含んだ元の映像ストリームを指定するＩＤである。ＥＤＬにおけるリール番号に対応するもので、複数の異なる映像ストリームからカットを取り出して再生する場合に、各カットのソースと成る映像ストリームを識別するために用いられる。
複数のコンテンツをまたがるカット集を作成したり、本映像の前後にＢＢ（ブラックバースト信号）やカラーバーなどの本映像とは別の特殊映像を付与する場合に有効である。
ストレージサーバ番号は、当該カットのstart_frameが格納されているストレージサーバ５０の番号である。
start_frame、end_frameはそれぞれ、当該カットの開始点、終了点を指定したＥＤＬ内のplay_in、play_outのタイムコードを、それらのタイムコードを付与された映像フレームのフレーム番号に変換したものである。rec_in、rec_outは、ＥＤＬ内の当該カットのrec_in、rec_out そのものである。
【００４２】
データベースサーバ９０のプレイリスト作成部９１が、制御部２（８０−２）からの再生開始要求で受信したＥＤＬ、および、データ管理部９２に格納されているＴＣ／フレーム番号対応表３７を用いてプレイリストを作成する例を図３７に示す。
先ず、ＥＤＬのリールナンバーに対応するストリームＩＤを決定する。なお、本明細書では、このリール番号とストリームＩＤの具体的な対応方法については規定しない。
そのストリームについてのＴＣ／フレーム番号対応表３７をデータ管理部９２から検索する。図３７の例では、ＥＤＬ中のリールナンバー００１、００２にそれぞれ対応するストリームＩＤ１、ストリームＩＤ２のＴＣ／フレーム番号対応表３７を抽出している。
ＴＣ／フレーム番号対応表３７の検索が完了すると、次に、ＥＤＬとＴＣ／フレーム番号対応表３７を参照して、各カットのplay_in、play_outのタイムコードをフレーム番号に変換する。
図３７の例では、ＥＤＬで指定されたリールナンバー００１の映像ソースの６時２５分３０秒から始まって６時２５分３４秒の２９フレームで終了するカットを、対応するストリームＩＤ１のＴＣ／フレーム番号対応表３７を参照して、フレーム番号２３４５６７９から始まって２３４５８２８で終了するカットとして指定している。
【００４３】
また、このカットの先頭であるフレーム番号２３４５６７９のフレームが格納されているストレージサーバ番号０を、先頭フレームのストレージサーバ番号としている。なお、この例では、０〜４の５台のストレージサーバ５０の蓄積装置上に順番に各フレームが格納されているものとする。また、ＥＤＬで指定された、rec_in、rec_outの値はそのままプレイリストに書き込まれる。
図３７の例では、カット２についても、リールナンバー００２に対応するストリームＩＤ２のＴＣ／フレーム番号対応表３７を用いて、１３時０２分４１秒の０４フレームから１３時０２分５１秒の０３フレームまでの指定を、フレーム番号３４５６７９３から３４５７０９２までの指定に変換している。このようにして、ＥＤＬの全てのカットのタイムコード指定をフレーム番号指定に変換した時点でプレイリストが完成する。
以上がプレイリストに関する説明である。
【００４４】
データベースサーバ９０で作成されたプレイリストは、再生動作の開始を要求した制御部２（８０−２）に送信される。（図３５の２７２）
このとき同時に、映像データの送信元となるバッファサーバを識別する番号も送信される。なお、データベースサーバ９０がこのバッファサーバ番号を決定する具体的な方法については、本明細書では規定しないが、ここでは、バッファサーバ２（３０−２）が映像データの送信元として指定されたものとする。
これらの情報を受信した制御部２（８０−２）は、データベースサーバ９０から指定されたバッファサーバ２（３０−２）の通信主体制御部２（３１ａ−２）に対して、映像データの再生開始要求をプレイリストと共に送信する。（図３５の２７３）
図３８のステップ２８１において、前述の再生開始要求を受信したバッファサーバ２（３０−２）上の通信主体制御部２（３１ａ−２）は、図３８のステップ２８２〜ステップ２８５により、全てのストレージサーバ上の通信主体制御部１−２（５１ａ−１−２）ないし通信主体制御部Ｎ−２（５１ａ−Ｎ−２）に対し、再生開始要求をプレイリストと共に送信する。（図３５の２７４）
バッファサーバ２（３０−２）上の通信主体制御部２（３１ａ−２）から再生開始要求とプレイリストを受信した各ストレージサーバ上の通信主体制御部１−２（５１ａ−１−２）ないし通信主体制御部Ｎ−２（５１ａ−Ｎ−２）は、図３９のステップ２９１〜ステップ２９３により、自データ通信主体内のクラスタ内送受信部１−２（５１ｃ−１−２）ないしクラスタ内送受信部Ｎ−２（５１ｃ−Ｎ−２）と、蓄積装置制御部１−２（５１ｂ−１−２）ないし蓄積装置制御部Ｎ−２（５１ｂ−Ｎ−２）に対して再生動作開始指示を発行した後、再生開始要求とプレイリストの送信元であるバッファサーバ２上の通信主体制御部２（３１ａ−２）に対して再生開始通知を発行する。（図３５の２７５）
【００４５】
図３８のステップ２８７〜ステップ２９０により、全てのストレージサーバ上の通信主体制御部１−２（５１ａ−１−２）ないし通信主体制御部Ｎ−２（５１ａ−Ｎ−２）から、再生開始通知を受信（図３５の２７５）したバッファサーバ２（３０−２）上の通信主体制御部２（３１ａ−２）は、制御部２（８０−２）に対して正常開始通知を発行する。（図３５の２７６）
そして、図４０のステップ３０１、ステップ３０２により、自データ通信主体内のクラスタ内送受信部２（３１ｃ−２）と、ＩＰ送受信部２（３１ｂ−２）に対して再生動作の開始指示を発行する。
ここまでの処理により、再生映像データの送信元となるバッファサーバ２（３０−２）のクラスタ内送受信部２（３１ｃ−２）と、ＩＰ送受信部２（３１ｂ−２）、および、ストレージサーバ上のデータ通信主体内のクラスタ内送受信部１−２（５１ｃ−１−２）ないしクラスタ内送受信部Ｎ−２（５１ｃ−Ｎ−２）と、蓄積装置制御部１−２（５１ｂ−１−２）ないし蓄積装置制御部Ｎ−２（５１ｂ−Ｎ−２）の動作が開始され、以降、実際の映像データの再生処理が始まる。
【００４６】
以下では、これらの各処理部の動作を説明する。
先ず、ストレージサーバ上の蓄積装置制御部１−２（５１ｂ−１−２）の動作を説明する。図４１に動作のフローチャートを示す。
図４１のステップ３２１〜ステップ３３７により、蓄積装置制御部１−２（５１ｂ−１−２）は、プレイリスト内の処理中のカット（カットＣ_num）に対して、そのカットの先頭のフレームのフレーム番号、および、そのカットの先頭フレームが格納されているストレージサーバ番号の情報を元に、自ストレージサーバの蓄積装置内に格納されているフレームのフレーム番号を順次検索し、当該ストリームＩＤに相当する蓄積装置上のファイルの先頭からそのフレームデータが格納されている位置までのオフセットを計算して、当該フレームデータを蓄積装置１（６０−１）からデータバッファヘ読み出す処理を繰り返す。
この処理は、図４１のステップ３２８において、プレイリスト中の全てのカットのフレーム読み出しが終了するか、あるいは、図４１のステップ３３０において、通信主体制御部１−２（５１ａ−１−２）から再生動作の終了指示が到着するまで繰り返される。再生動作が終了すると、図４１のステップ３３８において、蓄積装置上のファイルを閉じる。
図４１のフローチャートから分かるように、蓄積装置制御部１−２（５１ｂ−１−２）は、データバッファ内にフレームを格納する空きスペースが存在する限り、他の処理部の動作と独立してフレームの読み出し処理を繰り返す。
これにより、バッファサーバ２（３０−２）からのフレーム転送要求に先んじてフレームデータの読み出し処理を行なうことができ、当該映像ストリームの再生時のデータ転送レートの低下を防ぐことができる。
【００４７】
次に、ストレージサーバ上のクラスタ内送受信部１−２（５１ｃ−１−２）の動作を説明する。図４２に動作のフローチャートを示す。
図４２のステップ３４０〜ステップ３４３により、通信主体制御部１−２（５１ａ−１−２）から再生動作の開始指示を受けたクラスタ内送受信部１−２（５１ｃ−１−２）は、対向のバッファサーバ（本実施例の場合はバッファサーバ２（３０−２））上のクラスタ内送受信部２（３１ｃ−２）からフレーム読み出し要求を受信すると、そのフレーム読み出し要求で指定されたフレーム番号が付与されたフレームが自データバッファの中に存在するかどうかを検索する。
蓄積装置制御部１−２（５１ｂ−１−２）が既に蓄積装置１（６０−１）から当該フレームを読み出していて、当該フレームが自データバッファの中に存在すると、そのフレームが格納されている自データバッファのメモリアドレス情報を対向のバッファサーバ上のクラスタ内送受信部２（３１ｃ−２）に対して返信する。
この動作を通信主体制御部１−２（５１ａ−１−２）から再生動作の終了指示が到着するまで繰り返す。
以上がストレージサーバ５０の映像再生動作の説明である。図４３に、前述した蓄積装置制御部１−２（５１ｂ−１−２）、および、クラスタ内送受信部１−２（５１ｃ−１−２）の動作の概要を示す。
【００４８】
次に、バッファサーバ２（３０−２）の映像再生動作を説明する。
まず、クラスタ内送受信部２（３１ｃ−２）の動作を図４４のフローチャートに基づいて説明する。
クラスタ内送受信部２（３１ｃ−２）は、プレイリスト内の各カットについて、そのカットの先頭フレーム（start_frame）から最終フレーム（end_frame）まで順番に１つずつ映像フレームをストレージサーバ５０から読み出す処理を行なう。
このフレーム読み出し処理の具体的な手順は以下の通りである。
先ず、図４４のステップ３５０〜ステップ３５５により、自バッファサーバ内のデータバッファにフレーム格納用の空きスペースがあることを確認する。
次に、図４４のステップ３５２、ステップ３５９、ステップ３６２、ステップ３６３により、そのカットの先頭フレームのフレーム番号と格納先ストレージサーバ番号の情報を元に、当該読み出しフレームの格納先ストレージサーバ番号を算出し、図４４のステップ３５６により、そのストレージサーバ上の対向のデータ通信主体のクラスタ内送受信部に対してフレーム読み出し要求を発行する。このフレーム読み出し要求では、要求するフレームのフレーム番号を指定する。
そして、図４４のステップ３５７、ステップ３５８により、当該フレームが格納されているストレージサーバ上の当該データバッファのメモリアドレス情報が到着すると、そのアドレスに対してＲＤＭＡ readオペレーションを発行する。これにより、当該フレームが自データバッファ上の空き領城へ転送される。
図４４のステップ３５９、ステップ３６２、ステップ３６２、ステップ３６３により、カットの最終フレーム（end_frame）の読み出しが終了すると、次のカットに移って、再び先頭フレームから順番にフレーム読み出しを行なう。
バッファサーバ上のクラスタ内送受信部２（３１ｃ−２）は、図４４のステップ３６０において、プレイリスト内の全カットの全フレームの読み出しを終了するか、または、図４４のステップ３５４において、通信主体制御部２（３１ａ−２）から再生動作の終了指示を受信するまで、前述の処理を繰り返す。
【００４９】
次に、ＩＰ送受信部２（３１ｂ−２）の動作を説明する。図４５に動作のフローチャートを示す。
図４５のステップ３７１〜ステップ３８２により、ＩＰ送受信部２（３１ｂ−２）は、バッファサーバ２（３０−２）のデータバッファ内の映像フレームをＩＰパケットに分割し、配信ネットワークを介して映像／ＩＰ変換装置２（７１−２）へ送信する処理を繰り返す。
図４５のフローチャートに示すように、ＩＰパケットに付与するフレーム番号は、データバッファ内にある当該映像フレームに付与されているフレーム番号をそのまま用いる。
タイムコードについては、当該フレームが、プレイリスト中の各カットのstart_frame、または、end_frameの場合は、それぞれrec_in、rec_outで指定された値を付与し、それ以外の場合は、当該カットの先頭フレーム番号とrec_inの値、および、当該フレームのフレーム番号を元に算出した値を、当該フレームヘ付与すべきタイムコードとして付与する。
フレーム番号、および、タイムコード（ＴＣ）の値は、当該フレームから生成した全てのＩＰパケットに対して同じ値を付与する。パケット番号は、当該フレームから生成したＩＰパケットの通し番号を付与する。また、そのパケットが当該フレームから生成した最後のＩＰパケットの場合には最終パケットフラグの値を１に、それ以外の場合は０に設定する。
【００５０】
以上の手順でデータバッファ内の映像フレームをＩＰパケットに分割し、各ＩＰパケットを配信用ネットワーク４２を介して所望の映像／ＩＰ変換装置２（７１−２）へ送信する。
この動作をデータバッファ内の映像フレームが無くなるまで繰返し、図４５のステップ３８３により、通信主体制御部２（３１ａ−２）から再生終了指示を受信した時点で動作を終了する。以上がバッファサーバ２（３０−２）の映像再生動作の説明である。
図４６に、前述したＩＰ送受信部２（３１ｂ−２）、および、クラスタ内送受信部２（３１ｃ−２）の動作の概要を示す。
バッファサーバ２（３０−２）からＩＰパケットを受信した映像／ＩＰ変換装置２（７１−２）は、図４７に示すように、ＩＰパケットに分割された映像データを一まとめにしてＨＤＴＶフレームを再構成し、ＨＤ−ＳＤＩ信号線上へ送信する。ＨＤ−ＳＤＩ信号線上を伝送されたＨＤＴＶフレームはモニタ上で映像として再生される。
これらのフレームは、プレイリストにより抽出された映像ストリームの中の部分映像からなるフレームであり、これによりＥＤＬで指定したカットだけが連続再生される。
以上が映像データのカット再生処理の概要である。本カット再生処理は、映像データを送信しているバッファサーバ２上の通信主体制御部２（３１ａ−２）に対して制御部２（８０−２）から再生終了要求を発行することで終了する。
【００５１】
再生処理終了時の制御情報のシーケンスを図４８に示す。
図４０のステップ３０３〜３０５により、制御部２（８０−２）から再生終了要求を受信（図４８の３９０）したバッファサーバ２上の通信主体制御部２（３１ａ−２）は、先ず、同じデータ通信主体のＩＰ送受信部２（３１ｂ−２）、ならびに、クラスタ内送受信部２（３１ｃ−２）に対して再生動作の終了指示を発行する。
そして、図４０のステップ３０６〜ステップ３０９により、全てのストレージサーバ上の通信主体制御部１−２（５１ａ−１−２）ないし通信主体制御部Ｎ−２（５１ａ−Ｎ−２）に対して再生終了要求を発行し、これらの応答を待つ。（図４８の３９１）
この再生終了要求を受信した各ストレージサーバ上の通信主体制御部５１ａは、図３９のステップ２９４〜ステップ２９６により、同じデータ通信主体内の蓄積装置制御部５１ｂとクラスタ間送受信部５１ｃに対して再生動作の停止指示を発行する。
この再生動作の停止指示を受けた蓄積装置制御部は、記録装置上に映像データの再生用にオープンしていたファイルをクローズする。
【００５２】
蓄積装置制御部５１ｂとクラスタ間送受信部５１ｃの動作が停止すると、図３９のステップ２９７により、ストレージサーバ上の通信主体制御部５１ａは、バッファサーバ２上の通信主体制御部２（３１ａ−２）に対して再生終了通知を返信する。（図４８の３９２）
図４０のステップ３１０〜ステップ３１４により、バッファサーバ２上の通信主体制御部２（３１ａ−２）は、全てのストレージサーバ上の通信主体制御部１−２（５１ａ−１−２）ないし通信主体制御部Ｎ−２（５１ａ−Ｎ−２）より再生終了通知を受信すると、制御部２（８０−２）に対して再生終了通知を送信する。（図４８の３９３）
そして、制御部２（８０−２）はデータベースサーバ９０に対して再生終了通知を送信する。（図４８の３９４）以上でカット再生の全ての動作が完了する。
図１９に示す本実施例の構成においては、蓄積／配信処理あわせて、バッファサーバ上のデータ通信主体の総数Ｎと同数の映像ストリームを同時に扱うことが可能である。
さらに、バッファサーバ３０やストレージサーバ５０の性能に応じて、各バッファサーバ上に配置するデータ通信主体の数を増やし、それらに対向するデータ通信主体を全ストレージサーバ上に配置するようにして、分散型ストレージサーバ上で同時に扱える映像ストリームの数を増加させることも可能である。
【００５３】
[実施例２]
本発明の実施例２のシステム構成を図４９に示す。
本実施例と、図１９に示した実施例１のシステム構成との違いは、ストレージサーバ上のデータ通信主体５１にフレーム先読み制御部５５を持たない点である。
図４９に示したデータ通信主体の内部構成を図５０に示す。ストレージサーバ上のデータ通信主体５１にフレーム先読み制御部を持たない点が、図２０に示した実施例１におけるデータ通信主体５１の内部構成と異なっている、
本実施例の映像データの蓄積動作については、実施例１との違いはない。映像データのカット再生時において、以下の２点が実施例１の動作と異なる。
（１）カット再生開始時にバッファサーバ上の通信主体制御部３１ａからストレージサーバ上の通信主体制御部５１ａに対して再生開始要求を送信する際、プレイリストの送信は行なわない。
（２）ストレージサーバ上のデータ通信主体の蓄積装置制御部５１ｂは、バッファサーバ上の対向のデータ通信主体３１のクラスタ内送受信部３１ｃから送信されるフレーム読み出し要求に同期して、蓄積装置６０からのフレーム読み出しを行なう。（本動作の概要を図５１に示す）。
【００５４】
即ち、バッファサーバ上のクラスタ内送受信部３１ｃは、ストレージサーバ上のクラスタ内送受信部５１ｃに対して、フレーム読み出し要求を発行する。（図５１の４０１）
このフレーム読み出し要求は、ストレージサーバ上のクラスタ内送受信部５１ｃから蓄積装置制御部５１ｂを介して蓄積装置６０に到達する。（図５１の４０２、４０３）
次に、蓄積装置６０は、蓄積装置制御部５１ｂに対してフレームデータを転送し（図５１の４０４）、蓄積装置制御部５１ｂは、クラスタ内送受信部５１ｃに対してフレーム読み出し終了通知を発行する。（図５１の４０５）
次に、ストレージサーバ上のクラスタ内送受信部５１ｃは、バッファサーバ上のクラスタ内送受信部３１ｃに対して、データバッファのメモリアドレス情報を通知し（図５１の４０６）、ストレージサーバ上のクラスタ内送受信部５１ｃは、ＲＤＭＡ read機能によりフレームデータを読み出す。（図５１の４０７）
このように、前述の実施例１では、ストレージサーバ上の蓄積装置制御部５１ｂはバッファサーバ３０からのフレーム読み出し要求の到着とは非同期に、プレイリストを参照して先行的に蓄積装置６０からフレーム先読み処理を行うのに対し、本実施例では、この先読み処理を行なわない点が異なっている。
映像データの蓄積装置６０からの読み出し速度が十分に速く、蓄積装置６０からの先読み処理をおこなう必要がない場合は、本実施例のような構成も可能である。
【００５５】
[実施例３]
本発明の実施例３のシステム構成を図５２に示す。図１９に示す実施例１のシステム構成との違いは、バッファサーバ上のデータ通信主体に、ＴＣ／フレーム番号対応記録部３５の代わりにＴＣ記録部３９を持つ点である。
図５２に示したデータ通信主体の内部構成を図５３に示す。
バッファサーバ上のデータ通信主体に、ＴＣ／フレーム番号対応記録部３５の代わりにＴＣ記録部３９を持つ点が、図２０に示した実施例１におけるデータ通信主体の内部構成と異なっている。
本実施例と実施例１との違いは、映像データをフレーム番号ではなく、タイムコードを用いて管理する点である。
バッファサーバ上のデータ通信主体３１のＩＰ送受信部３１ｂは、映像データの蓄積時において、配信用ネットワーク４２からＩＰパケットを受信して映像フレームを再構築する際も、そのフレームのフレーム番号ではなくタイムコードを付与してストレージサーバ５０へ転送する。
この様子を図５４に示す。また、このとき、ＴＣ記録部３９は、図５５に示すように、フレームのタイムコードと転送先ストレージサーバ番号の対を順次記録する。
【００５６】
ストレージサーバ上のデータ通信主体５１の蓄積装置制御部５１ｂは、バッファサーバ３０からフレームを受信する毎に、当該フレームと自ストレージサーバ５０へ届いた先頭フレームのタイムコードの差をフレーム数の差に変換し、さらにその値をシステム内のストレージサーバ５０の総数Ｎで割って、当該フレームが自ストレージサーバ５０に格納される当該ストリームのフレームの中で何番目のフレーム（先頭フレームは０番目とする）であるかを求める。
その値を自ストレージサーバ内フレーム番号とし、[オフセット＝自ストレージサーバ５０内フレーム番号×フレームサイズ]の式によって決定される、当該ストリームＩＤに対応するファイル内のオフセットの位置に当該フレームを格納する。
映像データのカット再生時に、データベースサーバ９０によって作成されるプレイリストは、図５７に示すように、フレーム番号ではなくＥＤＬで指定されたタイムコードをそのまま用いる。
バッファサーバ上のプレイリスト解釈部３６は、このプレイリストを使用し、タイムコードで要求フレームを指定する。
ストレージサーバ上のフレーム先読み制御部５５もこのプレイリストを使用し、図５６に示したフレーム蓄積処理の場合と同様の方法で所望のフレームのファイル上の格納揚所を特定し、蓄積装置６０からの読み出しを行なう、
本実施例では、ストレージサーバ上の蓄積装置制御部５１ｂにおけるフレームデータ管理において、タイムコードの差分をフレーム番号の差分に変換する処理が必要であり、実施例１に比べてやや繁雑であるが、本実施例のような構成も可能である、
【００５７】
[実施例４]
本発明の実施例４のシステム構成を図５８に示す。図１９に示した実施例１のシステム構成との違いは、バッファサーバ上のデータ通信主体に、ＴＣ／フレーム番号対応記録部３６の代わりにＴＣ記録部３９を持つ点、および、ストレージサーバ上のデータ通信主体にフレーム先読み制御部５５を持たない点である。
図５８に示したデータ通信主体の内部構成を図５９に示す。バッファサーバ上のデータ通信主体に、ＴＣ／フレーム番号対応記録部３６の代わりにＴＣ記録部３９を持つ点、および、ストレージサーバ上のデータ通信主体にフレーム先読み制御部５５を持たない点が図２０に示した実施例１におけるデータ通信主体の内部構成と異なっている。
本実施例は、実施例２、および、実施例３の実施例１に対する差分を合わせ持つ例で、その動作についても、実施例２、および、実施例３に記載の内容を合わせ持つものとする。
以上、本発明者によってなされた発明を、前記実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。
【図面の簡単な説明】
【００５８】
【図１】放送局などにおいて、収録素材に対して行われる編集作業の一般的な工程を示す図である。
【図２】ＥＤＬ（Edit Decision List）を説明するための図である。
【図３】タイムコードの構造を示す図である。
【図４】ＶＴＲベースの編集装置の概略構成を示すブロック図である。
【図５】ＶＴＲベースの編集装置によるオンライン編集の概要を説明するための図である。
【図６】ノンリニア編集装置の概略構成を示すブロック図である。
【図７】ノンリニア編集装置によるオンライン編集の概要を説明するための図である。
【図８】分散型マルチメディアサーバを用いた編集装置の概略システム構成を示すブロック図である。
【図９】バッファサーバからストレージサーバヘのマルチメディア情報転送手順を説明するための図である。
【図１０】ストレージサーバからバッファサーバヘのマルチメディア情報転送手順を説明するための図である。
【図１１】分散ＲＡＩＤ方式に基づくマルチメディア情報の格納方法を示す図である。
【図１２】分散ＲＡＩＤ方式に基づくマルチメディア情報の配信方法を示す図である。
【図１３】複数のデータ送受信主体間のネットワークを示す図である。
【図１４】複数のマルチメディア情報ストリームの同時送受信を示す図である。
【図１５】蓄積装置上に記録された同一のマルチメディア情報に対する複数の配信要求において、性能低下が発生しない例を示す図である。
【図１６】カット編集を実現するための要素機能（太線黒枠部）を示す図である。
【図１７】ＴＣ／フレーム番号対応表の作成を説明するための図である。
【図１８】プレイリストに基づくカット再生を説明するための図である。
【図１９】本発明の実施例１のシステム構成を示すブロック図である。
【図２０】本発明の実施例１のデータ通信主体の内部構成を示すブロック図である。
【図２１】本発明の実施例１における、映像データの蓄積開始時のメッセージシーケンス（正常時）を示す図である。
【図２２】本発明の実施例１における、映像データの蓄積開始時映像データの蓄積開始時のメッセージシーケンス（異常終了時）を示す図である。
【図２３】本発明の実施例１のバッファサーバ上の通信主体制御部の蓄積動作時の処理手順を示すフローチャートである。
【図２４】本発明の実施例１の映像／ＩＰ変換装置の動作（映像信号からＩＰパケットヘの変換時）を説明するための図である。
【図２５】本発明の実施例１のバッファサーバ上の通信主体制御部の蓄積動作時の処理手順を示すフローチャートである。（図２３の続き）
【図２６】本発明の実施例１のバッファサーバ上のデータ通信主体のＩＰパケット受信時の動作を説明するための図である。
【図２７】本発明の実施例１のバッファサーバ上のＩＰ送受信部の蓄積動作時の処理手順を示すフローチャートである。
【図２８】本発明の実施例１のバッファサーバ上のクラスタ内送受信部の蓄積動作時の処理手順を示すフローチャートである。
【図２９】本発明の実施例１のストレージサーバ上のデータ通信主体の映像データ蓄積動作を説明するための図である。
【図３０】本発明の実施例１のストレージサーバ上の通信主体制御部の蓄積動作時の処理手順を示すフローチャートである。
【図３１】本発明の実施例１のストレージサーバ上のクラスタ内送受信部の蓄積動作時の処理手順を示すフローチャートである。
【図３２】本発明の実施例１のストレージサーバ上の蓄積装置制御部の蓄積動作時の処理手順を示すフローチャートである。
【図３３】本発明の実施例１の映像データ蓄積処理停止時のメッセージシーケンスを示す図である。
【図３４】本発明の実施例１のＴＣ／フレーム番号対応記録部で作成されたＴＣ／フレーム番号対応表の一例を示す図である。
【図３５】本発明の実施例１の映像データの再生開始時のメッセージシーケンスを示す図である。
【図３６】本発明の実施例１のプレイリストの構造を示す図である。
【図３７】本発明の実施例１のＥＤＬからプレイリストを作成する処理を説明するための図である。
【図３８】本発明の実施例１のバッファサーバ上の通信主体制御部の再生動作時の処理手順を示すフローチャートである。（図２３からの続き）
【図３９】本発明の実施例１のストレージサーバ上の通信主体制御部の再生動作時の処理手順を示すフローチャートである。（図３０からの続き）
【図４０】本発明の実施例１のバッファサーバ上の通信主体制御部の再生動作時の処理手順を示すフローチャートである。（図３８からの続き）
【図４１】本発明の実施例１のストレージサーバ上の蓄積装置制御部の再生動作時の処理手順を示すフローチャートである。（図３２からの続き）
【図４２】本発明の実施例１のストレージサーバ上のクラスタ内送受信部の再生動作時の処理手順を示すフローチャートである。（図３１からの続き）
【図４３】本発明の実施例１のストレージサーバ上のデータ通信主体の映像データ再生動作を説明するための図である。
【図４４】本発明の実施例１のバッファサーバ上のクラスタ内送受信部の再生動作時の処理手順を示すフローチャートである。（図２８からの続き）
【図４５】本発明の実施例１のバッファサーバ上のＩＰ送受信部の再生動作時の処理手順を示すフローチャートである。（図２７からの続き）
【図４６】本発明の実施例１のバッファサーバのＩＰパケット送信時の動作を説明するための図である。
【図４７】本発明の実施例１の映像／ＩＰ変換装置の動作（ＩＰパケットから映像信号への変換時）を説明するための図である。
【図４８】本発明の実施例１の映像データの再生停止時のメッセージシーケンスを示す図である。
【図４９】本発明の実施例２のシステム構成を示すブロック図である。
【図５０】本発明の実施例２のデータ通信主体の内部構成を示すブロック図である。
【図５１】本発明の実施例２におけるフレーム読み出し手順を示す図である。
【図５２】本発明の実施例３のシステム構成を示すブロック図である。
【図５３】本発明の実施例３のデータ通信主体の内部構成を示すブロック図である。
【図５４】本発明の実施例３のバッファサーバ上のデータ通信主体のＩＰパケット受信時の動作を示す図である。
【図５５】本発明の実施例３のＴＣ記録部で作成されたタイムコード表の一例を示す図である。
【図５６】本発明の実施例３のストレージサーバ上のデータ通信主体の映像データ蓄積動作を説明するための図である。
【図５７】本発明の実施例３のプレイリストの構造を示す図である。
【図５８】本発明の実施例４のシステム構成を示すブロック図である。
【図５９】本発明の実施例４のデータ通信主体の内部構成を示すブロック図である。
【符号の説明】
【００５９】
１  中央制御装置
２  操作卓（キーボード）
３  表示部（ディスプレイ）
４  内部記憶装置（ＦＤＤ／ＨＤＤ）
５  シリアルインタフェース（Ｉ／Ｏ）
６  ＶＴＲ
７  ＭＩＸ’ｅｒ
８  ルーティングスイッチャ
９  スピーカ
１０  ビデオモニター
１１  蓄積装置（ＨＤＤ）
１２  メモリ
２０  分散型マルチメディアサーバ
３０  バッファサーバ
３１，５１  データ通信主体
３１ａ  通信主体制御部
３１ｂ  ＩＰ送受信部
３１ｃ，５１ｃ  クラスタ内送受信部
３１ｄ，５１ｄ  データバッファ
３２，５２  データ送信主体
３３，５３  データ受信主体
３５  ＴＣ／フレーム番号対応記録部
３６  プレイリスト解釈部
３７  ＴＣ／フレーム番号対応表
３９  ＴＣ記憶部
４０  クラスタ間接続ネットワーク
４１  ローカルエリアネットワーク（ＬＡＮ）
４２  配信用ネットワーク
５０  ストレージサーバ
５１ａ  通信主体制御部
５１ｂ  蓄積装置制御部
５５  フレーム先読み制御部
６０  蓄積装置（ＨＤＤ）
７０  端末
７１  映像／ＩＰ変換装置
７２  ＨＤＴＶ  ＶＴＲ
７３  モニタ
８０  制御部
９０  データベースサーバ
９１  プレイリスト作成部
９２  データ管理部
９５  制御端末
【図１】
2007184777.tif 000003
【図２】
2007184777.tif 000004
【図３】
2007184777.tif 000005
【図４】
2007184777.tif 000006
【図５】
2007184777.tif 000007
【図６】
2007184777.tif 000008
【図７】
2007184777.tif 000009
【図８】
2007184777.tif 000010
【図９】
2007184777.tif 000011
【図１０】
2007184777.tif 000012
【図１１】
2007184777.tif 000013
【図１２】
2007184777.tif 000014
【図１３】
2007184777.tif 000015
【図１４】
2007184777.tif 000016
【図１５】
2007184777.tif 000017
【図１６】
2007184777.tif 000018
【図１７】
2007184777.tif 000019
【図１８】
2007184777.tif 000020
【図１９】
2007184777.tif 000021
【図２０】
2007184777.tif 000022
【図２１】
2007184777.tif 000023
【図２２】
2007184777.tif 000024
【図２３】
2007184777.tif 000025
【図２４】
2007184777.tif 000026
【図２５】
2007184777.tif 000027
【図２６】
2007184777.tif 000028
【図２７】
2007184777.tif 000029
【図２８】
2007184777.tif 000030
【図２９】
2007184777.tif 000031
【図３０】
2007184777.tif 000032
【図３１】
2007184777.tif 000033
【図３２】
2007184777.tif 000034
【図３３】
2007184777.tif 000035
【図３４】
2007184777.tif 000036
【図３５】
2007184777.tif 000037
【図３６】
2007184777.tif 000038
【図３７】
2007184777.tif 000039
【図３８】
2007184777.tif 000040
【図３９】
2007184777.tif 000041
【図４０】
2007184777.tif 000042
【図４１】
2007184777.tif 000043
【図４２】
2007184777.tif 000044
【図４３】
2007184777.tif 000045
【図４４】
2007184777.tif 000046
【図４５】
2007184777.tif 000047
【図４６】
2007184777.tif 000048
【図４７】
2007184777.tif 000049
【図４８】
2007184777.tif 000050
【図４９】
2007184777.tif 000051
【図５０】
2007184777.tif 000052
【図５１】
2007184777.tif 000053
【図５２】
2007184777.tif 000054
【図５３】
2007184777.tif 000055
【図５４】
2007184777.tif 000056
【図５５】
2007184777.tif 000057
【図５６】
2007184777.tif 000058
【図５７】
2007184777.tif 000059
【図５８】
2007184777.tif 000060
【図５９】
2007184777.tif 000061