JP2009048762A - マルチメディア・システム - Google Patents

Abstract

【課題】再生装置内にマルチメディア・データを重複して格納したり転送することを回避することで、システムの帯域幅および利用可能な再生メモリを増大させる方法およびシステムが提供される。
【解決手段】マルチメディア・コンポジションは、オーディオおよびビデオのマルチメディア・データの編集された断片を記述する。コンポジションが作成され、再生装置に転送される。コンポジションは、コンポジション内で参照されるマルチメディア・データが再生装置に既に格納されているかどうかを判定するために調査される。データが再生装置に格納されているか、再生装置への移行中である場合、それは再生装置に転送されない。
【選択図】図２

Description

本発明は、マルチメディア・システムにおいて使用するための方法および機器に関係する。なかでも特に、本発明は、複数のマルチメディア・コンポジションが同じマルチメディア・データを共有することができるように、マルチメディア・コンポジションを編集し、転送し、格納し、再生することに関係する。

マルチメディア・データを効率的に編集し、再生し、放送することは、ニュース産業における優先事項である。マルチメディア・データは、ビデオカメラ、衛星、ビデオ・テープ、オーディオ・テープ、コンパクトディスクなどのような様々なソースから集められたオーディオ・データおよびビデオ・データを含む。編集者が、通常はマルチメディア・データのソース資料からニュース・クリップを生成し、その編集したニュース・クリップが、放送用の再生装置へ物理的に転送される。

ネットワーキングの進歩により、編集されたニュース・クリップを再生装置へ転送するプロセスが自動化されている。そのようなシステムでは、ニュース・クリップがソース資料から作成され、ネットワークに接続された複数の編集用ワークステーションのうちの１つで編集される。編集されたクリップは、識別子（ＩＤ）を与えられ、そしてこのワークステーションから再生装置へ電子的に転送され、そしてこの再生装置は、放送用に後で再生するためにそのクリップを格納することができる。その後、プロデューサーがクリップのＩＤを待ち行列に入れると、再生装置がそのニュースストーリを放送用に再生する。

しかしながら、上記のネットワークは、編集された異なるクリップの中で用いられている同じマルチメディア・データを再度送信したり、再度格納したりすることにより、帯域幅とメモリを浪費することがある。例えば、編集者は再生装置へ完成したニュース・クリップを送り、それから小幅な変更を行うことを望むことがある。編集者は、先に再生装置へ送った３０秒のニュース・クリップを５秒削減することを望むことがある。そのような場合、編集者は、ワークステーションでそのクリップを編集して、削減した５秒を差し引いた全クリップを再送する。したがって、再生装置は２個のクリップを格納することになるが、それらの両方がマルチメディア・データの同じ部分を含んでいる。

帯域幅の浪費の別の例は、プロモーション用のクリップがストーリと共に使用されるニュース・ジャーナリズムの中で一般的に発生することである。そのような場合、より大きなニュース・クリップから短いクリップが、プロモーション用のクリップとして使用するために作成されることになる。

プロモーション用クリップだけから成るクリップは、送信される必要があり、また、ニュースストーリが放送される時に用いられる、プロモーション用クリップを含むより大きなクリップが、別に送信され、再生装置に格納されることになる。したがって、上で引用した両方の例において、同一のマルチメディア・データが、再生装置内の２つのロケーションに転送され格納されることになる。

再生装置内にマルチメディア・データを重複して格納したり転送することを回避することで、システムの帯域幅および利用可能な再生メモリを増大させる方法およびシステムを、提供する。編集されたソース資料を編纂したものであるマルチメディア・コンポジションを作成し、再生装置に転送する。コンポジションを調べることにより、コンポジションの中で参照するマルチメディア・データが再生装置に既に格納されているかどうかを判定する。データが、再生装置に格納されているか、再生装置へ移行中である場合、それは再生装置に転送しない。

本発明の１つの側面では、データを参照するマルチメディア・コンポジションを作成するステップと、第１ロケーションにマルチメディア・コンポジションを転送するステップと、マルチメディア・コンポジションによって参照されるデータが、第１ロケーションに関係するストレージ領域に保持されているかどうかを判定するステップと、そのデータがまだストレージ領域にない場合にのみ、マルチメディア・コンポジションによって参照されるデータをストレージ領域に転送するステップと、を含むデータを共有するための方法を提供する。

別の実施例では、データを参照するマルチメディア・コンポジションを作成するための少なくとも１つのワークステーションと、ワークステーションによって作成されたマルチメディア・コンポジションを格納し再生するためにワークステーションに結合された再生装置と、転送ツールとを含むマルチメディア・システムを提供する。転送ツールは、マルチメディア・コンポジション、およびマルチメディア・コンポジションによって参照されるデータを、ワークステーションから再生装置へ転送する。転送ツールは、マルチメディア・コンポジションによって参照される、再生装置に格納されていないデータのみを転送するように構成される。

別の実施例では、マルチメディア・コンポジションを保持している装置の中のマルチメディア・データ、およびマルチメディア・コンポジションによって参照されるデータを削除する方法を、提供する。その方法は、どれだけのコンポジションがマルチメディア・データの特定部分を参照するかを判定するステップと、どのコンポジションも参照しないマルチメディア・データの部分がどれであるかを判定するステップと、どのマルチメディア・コンポジションも参照しないマルチメディア・データを削除するステップとを含む。

図１および２は、典型的なマルチメディア・ネットワーク１の実施例を示している。ネットワーク１はハブ５に結合された編集ワークステーション３を含む。マルチメディア・コンポジションは編集ワークステーション３で作成され、そしてハブ５を通して再生装置７へ転送され、そしてこの再生装置は、再生装置の出力９からデータを放送用に再生するために、メディア・コンポジションおよびそれに関連するマルチメディア・データを格納する。本発明は特定のタイプの再生装置に制限されるものではないが、そのような再生装置の例は、商標「ビデオ・スペース（Video Space）」で、プルト・テクノロジー・インターナショナル社（Pluto Technologies International、Inc.）によって販売されている。

マルチメディア・コンポジションは、編集された１片のオーディオおよびビデオのマルチメディア・データを記述するために使用される１つの構造である。マルチメディア・データはこのコンポジションの一部ではない、すなわち、コンポジションは再生されるべきデータを参照するだけである。コンポジションを表すために使用されるこのデータ構造は、マルチメディア・データのしるしだけ、あるいはそれへの参照だけを含むことによって、実際のマルチメディア・データを排除する。１つのコンポジションは、ビデオ・データまたはオーディオ・データのような具体的なメディアの断片を表す、ソース・コンポーネントあるいはクリップから構成される。このクリップは、ソース資料内での資料の範囲だけでなく、このクリップの元となったソース資料の識別を含む。

コンポジションのデータ構造は、例えばＣ＋＋プログラミング・オブジェクトとすることができる。コンポジションは米国特許５，７２４，６０５号に記載された方法を用いて、あるいは、本文に援用するAvid Technology社のオープン・メディア・フレームワーク（ＯＭＦ）インターチェンジ・スペシフィケーションのバージョン２．１を用いて形成することができる。また、コンポジションは、アドバンスド・オーサリング・フォーマット（ＡＡＦ）仕様に記述された方法で形成することもできる。しかしながら、本発明は特定のタイプのコンポジションに制限されない、もっと正確に言えば、本文で使用する用語である「コンポジション」は、ソース・マルチメディア・データを実際に含むのではなく、単にそのソース・マルチメディア・データの部分を示すデータ構造を記述するだけである。

コンポジションは、ストレージ装置１７内のディスクに格納されたマルチメディア・データとは別個に、再生装置７に転送されサーバ１５に格納される。コンポジションは、マルチメディア・データを実際に含むのではなく、参照するだけなので、複数のコンポジションが、実際にデータを重複させずに、同じマルチメディア・データを参照することができる。コンポジションは、このコンポジションが作成されたワークステーション３で、編集者がそれに割り付けたＩＤによって識別される。このＩＤは、例えば８文字のＡＳＣＩＩ値とすることができる。

このコンポジションが再生装置７によって再生される場合、このコンポジション中で参照するいかなるマルチメディア・データもストレージ・ディスク１７から引き出され、そしてコンポジションによって指示された時間順でデジタル出力９に送られる。

編集ワークステーション３はマルチメディア・コンポジションを作成し編集するために使用することができるコンピューターシステムである。そのようなコンピューターシステムの例は、例えばAvid Technology社によって製造され、商標「NewsCutter」の下で販売されている。本発明は特定の種類の編集用ワークステーションに制限されるものではなく、他のタイプの編集用装置をマルチメディア・コンポジションを形成するために使用してもよいことが理解されるべきである。

ワークステーション３によって、ユーザはソース資料を編集して、コンポジションを作成することができる。編集ワークステーションでコンポジションを作成するために使用されるマルチメディア・データは、ビデオ・テープあるいはオーディオ・テープや、コンパクトディスクのようなソースから採られた元のソース資料を含んでもよいし、あるいはコンピュータで生成されるイメージなどから採ったものでもよい。このコンポジションのためのソース資料は、ローカルにワークステーション３に格納され、その後、再生するためにハブ５を通して再生装置７に転送される。再生装置７は図２に示してあり、これは、編集ワークステーション３からの接続の試みに関してソケット１３を監視する責任を持つ転送ツール１１を含む。そのソケットは、例えばＴＣＰ／ＩＰに使用することができるアプリケーション・プログラミング・インターフェースである。

転送ツールは、例えばＣ＋＋プログラミング・オブジェクトのような、サーバ１５のソフトウェア・アプリケーションとしてもよい。編集者が再生装置７へ完成したコンポジションを送りたい場合、ワークステーション３は接続要求を出す。編集ワークステーション３から接続要求を受け取ると、転送ツールは、ワークステーション３からデータ・ストレージ１７へのデータ転送のプロセスを管理する。

コンポジションは、転送ツールによってワークステーション３から転送される。コンポジションは転送ツールによって、メモリ常駐構造へ「デコンポーズ」される。この構造はそのコンポジションを再生するために必要な情報を含む。コンポジションのように、デコンポーズされたコンポジションの構造は、再生される実際のメディアを含んでいるのではなく、それはマルチメディア・データのセグメントの再生リストである。このコンポジションのデコンポーズは、コンポジションを検索してマルチメディア・データのセグメントへの参照を求め、これらは、再生される順に引き出され、連続してリストされる。したがって、デコンポーズされたコンポジションは、オリジナル・テープの識別やエフェクトの識別などのように、編集する立場から必要であるコンポジション・データのいかなるものも含まないことになる。

セグメントは、再生される実際のオーディオかビデオのマルチメディア・データである。１つのセグメントの構造は、サイズが変動し、１メガバイトより大きくてもよい。デコンポーズは、オープン・メディア・フレームワーク・スペシフィケーションのバージョン２．１で提案された方法で実行することもできる。

セグメント自身は、ＩＤ（コンポジションＩＤとは異なる）と、再生されるソース資料の実際のフレーム番号とで定義される。マルチメディア・データが格納されているかどうかを判定するために、サーバは、ストレージ１７に転送された特定のソースからのマルチメディア・データのセグメントを参照するコンポジションについて、それらコンポジションからのデータのクリップのテーブルを維持する。

コンポジション構造のそれらクリップはまた、それらに関連する別個のＩＤ（コンポジションＩＤとも異なる）を持っている。クリップ内のデータは、クリップＩＤと関連したマルチメディア・オブジェクトのどのセグメントがストレージ１７中にあるかを正確に定義する。クリップは、このクリップのデータのうちのいくつかあるいは全部を使用する、デコンポーズされたコンポジションの数である参照計数を維持する。クリップはさらに、そのデータがストレージ・ディスク１７のどこに存在するかに関する情報を維持する。したがってクリップ構造は、セグメントが始まるディスク・ブロック番号を含む。これは、クリップＩＤとセグメントを、ディスクの物理ロケーションと関係付けることができる１つの伝達手段である。

コンポジションＩＤはさらに、サーバ１５に格納されたデコンポーズされたコンポジションと関連付けられる。上で説明したように、デコンポーズされたコンポジションはセグメントの再生リストである。デコンポーズされたコンポジションは、デコンポーズされる前のそれに対応するコンポジションに関連付けられたのと同じＩＤによって識別される。

コンポジションが転送ツールによってデコンポーズされた後、転送ツールはデコンポーズされたコンポジションの構造（つまりセグメントの再生リスト）を解析して、必要なマルチメディア・データを捜す。オーディオかビデオのマルチメディア・データのセグメントをその構造が参照する場合、転送ツールは、それがストレージ１７に保持されているかどうかを判定するためにサーバ１５に問い合わせる。サーバは、ストレージ１７の中のデータを表すクリップのリスト（再生装置に転送されたコンポジションから作成された）の中を検索することによって、これを遂行する。

サーバ１５は、そのセグメントが欠けているか、存在するか、移行中であるかを示すことにより、その問い合わせに答える。データがすべて存在する場合、転送ツール１１はその構造を解析し続け、デコンポーズされたコンポジション全体の解析を完了するまで、必要とされるメディア・セグメントに対する問い合わせを行う。

サーバ１５は、１つのセグメントのうちのいくらかあるいは全部が欠けている、つまり、ストレージ装置１７内に存在しないことを示すことにより、その問い合わせに答えることがある。転送ツールは、欠けているそのデータのすべてをワークステーション３から再生装置７へ転送する。サーバはまた、データが移行中であると示すことにより問い合わせに答えることがある。転送ツールは、移行中であったデータがストレージ１７に転送されたことを確認するために、後でサーバに問い合わせを行う。

欠けているマルチメディア・データ・セグメントを、ワークステーション３からストレージ装置１７に転送するために、転送ツール１１は、例えばPluto International社のVideoSpace再生装置中のＥＲＡＭと呼ばれるストレージ・マネージャ１９に、ストレージ装置１７中のメモリの一部を要求することから始める。このストレージ・マネージャは、ストレージ装置１７内のディスクへのインターフェースである。データは、ストレージ・マネージャｌ９に要求することにより、ストレージ装置１７に格納したり、そこから取り出したりする。転送ツールは、ワークステーション３からストレージ・マネージャ１９中に、メディアを一度に１ブロック、例えば一度に１０フレームのビデオを移動させる。ストレージ・マネージャは、そのフレームに対してストレージ装置１７内のメモリを割り当てる。

転送ツールがデータの各ブロックを受け取ると、転送ツールは、ストレージ・マネージャがストレージ１７に保持されているディスクにそのメディアを格納するよう要求する。ブロックのいっぱいまでデータを格納することがより効率的であるので、転送ツールは、コンポジションによって要求されたフレーム数を、最も近いブロック・サイズまで丸めることになる（例えば、フレーム７〜１１３に対する要求は１〜１２０に丸める）。このことはまた、丸めたデータ（例えばフレーム１１４〜１２０）が後で別のコンポジションによって使用される場合、それがストレージ装置１７内に既にあり、このデータを転送する必要がなくなるので、有利である。１０フレームのブロックが便宜のために選ぶが、本発明は特定のブロック・サイズに制限されるものではなく、特定のマルチメディア・システムの要件に依存して他のブロック・サイズを使用してもよい。

ストレージ・マネージャ１９がディスクへのマルチメディア・データの格納を完了した時、ストレージ・マネージャは、うまく完了したことを転送ツールに知らせ、転送ツールは次のマルチメディア・ブロックをワークステーション３から転送する。必要とされるデータがすべてストレージ１７に存在するようになるまで、このデータ転送プロセスは継続する。マルチメディアがすべて転送された後、転送ツールは、転送が完了したことをストレージ・マネージャに通知し、そして参照されるデータの次のセグメントを捜すためにデコンポーズされたコンポジションの解析に戻る。

最終的に、デコンポーズされたコンポジション全体を解析し、コンポジションが要求するマルチメディア・データのすべてが、ディスクに存在する状態になる。この時点で、転送ツールは、後で再生するために呼び出すことができるように、サーバ１５に格納されたテーブル中に、このデコンポーズされたコンポジションを登録する。

個々のデコンポーズされたコンポジションは、それに関連付けられたＩＤによって識別され、そしてこれは、ディスクに格納されたビデオおよびクリップの関連するセグメントを指し示す再生リストを保持する。このデコンポーズされたコンポジションは、ストレージ１７内のセグメントの時系列順のリストである。例えば再生装置と関連付けたユーザ・インタフェース（図示せず）で１つのＩＤが選択されると、そのＩＤに関連したリストのセグメントが再生される。

デコンポーズされたコンポジションは、非線形のデジタル・ディスク・レコーダ／プレーヤーのようなビデオ・システムを制御するのに使用されるシリアル通信プロトコルを通して再生される。このプロトコルの例は、Louth Automationによるビデオ・ディスク・コミュニケーション・プロトコル（Video Disc Communication Protocol）である。

ワークステーションから再生装置までコンポジションおよびオーディオ／ビデオ・メディアを転送するために、ファイバー・チャンネルとイーサネット（登録商標）のインターフェースを共に、そしてまた適切なネットワーク・エレメントといっしょに使用してもよい。イーサネット（登録商標）・ネットワークはコンポジションおよび制御情報を転送するために使用することができ、ファイバー・チャンネル接続はマルチメディア・データを転送するために使用することができる。ファイバー・チャンネルは、高帯域幅のポイント・ツー・ポイントのネットワーキング技術である。再生装置７へのファイバー・チャンネル接続は、ファイバー・チャンネルのアダプター・カードに５５２６ＰＣＩのようなインターフェースを介して行うことができる。これと同じカード・タイプは、各ワークステーション３内に存在させることができる。本発明はワークステーション３と再生装置７の間の特定の通信インターフェースに制限されるものではなく、代替のインターフェースを使用してもよいことに注意すべきである。

図３は、ワークステーション３から再生装置７にメディアを転送する際に関係するステップの１つの実施例をより詳細に示す。ある１つのコンポジションを作成するために、ソース資料をワークステーション３のうちの１つにロードする。メディア・オブジェクトをこのソース・メディアに対して作成する。メディア・オブジェクトは、固有のＩＤを含む一次データ構造であり、これは、メディア・データの物理ソースを識別する。このメディア・オブジェクトを使用すると、デジタル・メディアとは別個にコンポジションを作成することや、メディアを再現するために他のアプリケーションが使用できるソース情報を格納することが可能になる。コンポジションのように、メディア・オブジェクトはＣ＋＋プログラミング・オブジェクトとすることができる。

ステップ１００で、編集者は１つ以上のソースから１つのコンポジションを作成し、そしてこのコンポジションにＩＤ、例えばネーム１を与える。そのコンポジションは、ソース資料から作成された１つ以上のメディア・オブジェクト内の特定範囲のビデオ・フレームを指し示す。その後、ステップ１１０で編集者は、ワークステーション３から再生装置７へ、このコンポジションの転送を開始する。転送ツールはソケット接続を待機し、そしてワークステーション３からソケット接続が通知される。

その後、ステップ１２０で、このコンポジションを、サーバが解析できる構造（つまりセグメントの再生リスト）にデコンポーズする。それから、転送ツールはこのコンポジションＩＤを問い合わせてこのＩＤがサーバ１５に格納されて既に存在しているかどうかを確かめる（ステップ１３０）。ＩＤがサーバ１５に存在する状況は、後で処理される。ＩＤがサーバ内にリストされていない場合、ステップ１４０で、そのＩＤに、サーバが「移行中」としてのマークを付ける。ステップ１５０で、サーバは、デコンポーズされたコンポジションの解析を開始して、このコンポジションが参照するマルチメディア・データを捜す。

例えば、コンポジションＮＡＭＥ１は、これが作成されたソース・メディア・オブジェクトのフレーム１〜５００を指しているとする。ステップ１６０で、転送ツールは、データ・セグメント（フレーム１〜５００）がストレージ１７に存在しているかどうかについて、サーバ１５に問い合わせる。サーバは、ストレージ１７内のそのデータを表すクリップのリスト（再生装置に転送されたコンポジションから作られたもの）を検索することによって、これを遂行する。そのメディアが存在する状況は、この後で処理される。

そのセグメントがストレージ内に存在しない場合、ステップ１７０で転送ツールは、その欠けているマルチメディア・データを記述するクリップ構造を作成する。ステップ１８０で、そのデータが存在していないので、移行中というフラグを、転送中のセグメントに対して設定する。今作成したそのクリップ構造は、その欠けている対応セグメントを指し示し、またそれに関係する参照計数を持ち、そしてこの計数は、このクリップが記述するデータのセグメントがコンポジションによって使用される毎に増分される。したがって、この場合、そのセグメントを参照する新たに作成されたクリップは、１だけ増分される。この参照計数は、ストレージ・ディスク１７に格納されたマルチメディア・データの使用頻度を追跡するために使用する。以下で説明するように、この参照計数は後で使用されて、再生装置のクリーンアップ中に、どのデータがストレージから削除されるべきかを判定する。

ステップ２００で、欠けているセグメント（つまり実際のマルチメディア・データ）を編集ワークステーション３からストレージ・ディスク１７に転送する。このステップは、転送ツールがストレージ・マネージャ１９を呼び出し、ストレージ・マネージャが転送中のメディアにメモリを割り当て、転送ツールに物理アドレスを返すステップを含む。次に、転送ツールは編集ワークステーション３からストレージ・マネージャ１９にそれらフレームを転送する。ストレージ・マネージャは、ディスク１７にそのデータを書き込むための手順を実行する。ストレージ・マネージャはまた、成功した書き込みの状況を転送ツールに返す。このようにしてその後、転送ツールは、ワークステーション３からストレージ１７に保持されたディスクまで、データをブロックで転送するステップを繰り返す。

すべてのデータが転送された後、転送ツールは、転送が完了したことを示すコマンドを、サーバ１５へ出す。ここで、ステップ２１０において、サーバは移行中フラグをそのセグメントから取り除く。その後、転送ツールはステップ１５０に戻り、さらに必要とされるマルチメディア・データ（つまり別のセグメント）を捜すために再生リストを解析する。いったんステップ１５５でコンポジションに残っているデータが無くなったという判定がなされると、ステップ２２０にプロセスが移り、このとき、デコンポーズされたコンポジションが要求したデータがすべてディスクに転送されており、またコンポジションＩＤがストレージ１７内の不揮発性メモリに格納されている。コンポジションＩＤに対する移行中のフラグが外され、そしてサーバは、再生装置７からコンポジションを再生するために使用されるプロトコルに、その新たなＩＤが利用可能であると通知する（ステップ２３０）。

説明した例においては、メディア・オブジェクトのフレーム１〜５００が再生装置７内のディスク１７に格納された。続いて、編集者が、例えば、同じメディア・オブジェクトのフレーム１〜５００のうちのフレーム２００〜４００を含むコンポジションを作成したとすれば、ステップ１００〜１６０が同じ方法で実行され、新たなコンポジションＩＤ（例えばＮＡＭＥ２）がそれらのフレーム（前のコンポジション中で使用されたフレームの部分集合である）のために作成されることになる。しかしながら、ステップ１６０に移る時、転送ツールはセグメント（フレーム２００〜４００）が存在するかどうかを判定するためにサーバ１５に問い合わせ、そしてサーバはそのマルチメディア・データの全部が存在するという指示を返す。

ステップ２４０で、サーバは、別のコンポジションがこのクリップのセグメントを参照したことを示すために、フレーム１〜５００のために作成されたクリップ構造に対する参照計数を増分する。したがって、２つのコンポジションが同じマルチメディア・データを使用することになる。その後、プロセスはステップ１５０に戻り、デコンポーズされたコンポジションに対する次のセグメントを求めて、再生リストを解析する。この例では、コンポジションはフレーム２００〜４００だけから構成されるとしたため、コンポジションがすべて解析されたことによりフローはステップ１５５からステップ２２０に移る。ステップ２２０で前に説明したように、その新たなコンポジション用のＩＤであるＮＡＭＥ２が格納される。

したがって、この例で見られるように、上述のメディア転送システムは、従来の方法と異なり、新たなコンポジションに対してフレーム２００〜４００を転送しないが、なぜならこれらのフレームが前のコンポジションに関連して既に格納されているからである。この方法で、同一のマルチメディア・データを、複数のコンポジションの間で共有することができ、帯域幅およびストレージ・スペースを節約できる。

コンポジションが、存在するいくつかのメディア・データと、存在しないいくつかのメディア・データを参照する場合について、これから説明する。例えば、先に示した例において、コンポジションＮＡＭＥ１およびＮＡＭＥ２を作成したところのメディア・オブジェクトの、フレーム３００〜６００を参照する第３コンポジションを作成することができるだろう。そのような場合には、フレーム３００〜５００が存在しているので、プロセスはそのセグメントに対してステップ２４０に移ることになる。しかしながら、フレーム５００〜６００については、プロセスはステップ１６０から１７０に移り、また欠けているメディアは、上で記述されたように、ステップ２００で転送を行うことになる。

上述したように、ステップ１６０で、転送ツールは、メディア・セグメントがストレージ１７に存在するかどうかを判定するためにサーバに問い合わせる。この問い合わせへの３つの可能性のある答えは次のとおりである。（１）データは存在しない。（２）データは存在する。そして（３）データは移行中である（ステップ１８０を参照）。状況（１）および（２）については上述した。状況（３）について説明すると、例えば、新たなコンポジションで要求するマルチメディア・データを、別のコンポジションが既に要求していた場合、そのデータは移行中である。データが移行中である場合、フローはステップ２５０に移る。

ステップ２５０で、転送ツールはマルチメディア転送プロセスを、しばらくの間、眠らせる。眠り期間の後、プロセスは起きてステップ１６０に戻り、欠けているセグメントを再び問い合わせる。眠り期間後に、うまくマルチメディア・データのすべてがストレージ１７に転送されていたなら、「移行中」フラグはもはや立てない。そのデータが転送されていたなら、プロセスは上記の説明にしたがって、ステップ２４０に行き、そしてステップ１５０に戻る。

上記のプロセスに対し行うことができる変更は、転送ツールが問い合わせるべきいくつかのセグメントを持っており、コンポジション再生リストの第１のセグメントが移行中であると指示される場合である。第１セグメントの転送の完了を待機するためにこの時点で、転送ツールは眠りにつくことはない。むしろ、それはリストにその移行中のセグメントを置き、そして移行中でない残りのセグメントの解析を続ける。転送ツールに対するすべての作業が、移行中でないセグメントに関して尽きた後、転送ツールは移行中セグメントのリストに行き、移行中の各セグメントについて再び問い合わせを行う。いずれかのセグメントがまだ移行中である場合には、眠るプロセスに入ることが適切である、つまり、再びセグメントを問い合わせるまで待つ間は、何もしない。

ステップ１３０における問い合わせで、そのコンポジションＩＤは既にサーバに格納されて存在すると応答されるかもしれない。この状況は、例えば特定のコンポジションを変更するか書き直すべきであると編集者が判断する場合に、発生する可能性がある。例えば、編集者は、ビデオを別のフレームからスタートさせたいと判断することがある。この場合、プロセスは、ステップ１３０からステップ１５０に移り、ここで、その新たなコンポジションに対して欠けているすべてのマルチメディア・セグメントを編集ワークステーション３から転送させる。すべてのデータが存在する場合（例えば、セグメントの最初のフレームが削除される場合、そうなる）、プロセスはステップ２１５に移り、ここでそのコンポジションＩＤが存在していると指示される。この場合、既に存在するＩＤが格納されようとしている。サーバは、これがそのテーブルに格納されているＩＤであると認識し、これはＩＤを更新するリクエストであるとみなす。こうして、図４で後述する方法と同じように、サーバは古いＩＤに関連付けられたコンポジションを削除する。

ステップ２２５において、古いＩＤのデコンポーズされたコンポジションを解析し、そしてステップ２３５で、古いコンポジションＩＤによって参照されるセグメントのどれかを参照するクリップ構造を、そのセグメントを使用するクリップ構造毎に減分する。これは、セグメントが残らなくなるまで続き（ステップ２４５で）、そして残らなくなったときステップ２５５で、古いＩＤをサーバに格納されたテーブル内の新たなＩＤと置き換える。これにより、コンポジションＩＤを更新する本プロセスは完了する。

図４は、コンポジションがもはや使用されないことが決定された場合、そのコンポジションをサーバ１５から削除する方法を示す。ステップ３００で、ユーザは、再生装置７に格納されたコンポジションを削除することを決め、そしてその適切なＩＤを削除するコマンドを入力する。ステップ３１０で、サーバに格納されたデコンポーズされたコンポジションを、メディア・セグメントを求めて解析する。ステップ３２０で、この特定のセグメントを参照する、サーバに格納されたクリップ構造は、その参照計数が減分される。すべての再生リストのセグメント要素が解析され（そして、各セグメントを参照するクリップが減分された）後、サーバはステップ３４０に移り、サーバに格納されたコンポジションのリストからそのコンポジションＩＤを削除する。装置７からの再生を制御する交信オペレーティング・システムは、ステップ３５０で、そのコンポジションＩＤの削除を通知される。

再生装置からマルチメディア・データを、いつ削除するのが適切であるかを判定するために、各クリップに対して保持した参照計数をサーバが使用する。上で説明したように、コンポジションがクリップ中のセグメントを参照する毎に、各クリップの参照計数が増分される。例えば、１つのコンポジションが１クリップ中の３つのセグメントを参照し、別のコンポジションがその同じクリップ中の２つのセグメントを参照した場合、参照計数は５となる。

この参照計数は、データが使用されているか否かを示す。このサーバ・テーブルから１つのＩＤを削除する要求がなされたとき、サーバは、そのＩＤの再生リストを解析しそしてそのクリップによって参照される各セグメントのクリップ参照計数を減分することが要求される。この参照計数が０になったとき、サーバは自動的にクリップを削除しない。むしろ、ストレージ１７の満杯度が特定の割合、例えば５０％より大きくなる場合にのみ、サーバはクリップを削除を開始する。クリップの参照計数が０であっても、これは編集者がそのクリップのメディアを今後使用しないだろうということを意味しない。したがって、０の参照計数を持つクリップを格納したまま保持することは、余剰容量がある間は、クリップのデータが再度使用されるようになる場合、ワークステーション３から再生装置まで再度データを転送する必要性を減少させる。

図５で示すように、サーバはメディアを自動的に削除するため次のステップに従う。すなわち、ステップ５００で、サーバは、ストレージ・ディスク１７の満杯度が特定の割合Ｘであるかどうかについて周期的に問い合わせを行う。その割合は、ある特定のシステムの要件にしたがって選択することができる。その割合に満たない場合、サーバは、クリップを削除するプロセスを継続しない。ディスクの満杯度が特定の割合以上になった場合、サーバは、参照計数０を持つクリップのリストを構築する。参照計数０は、クリップに保持されているデータのいかなるものをもコンポジションが現時点で参照していないことを意味する。その後（ステップ５２０で）、プロセスはこれらのクリップを削除する。

さらにコンポジションには、使用期限をそれに関連して持たせることができる。（代案として、一貫して用いられるコンポジションには、削除保護をそれに関連して持たせてもよい。）従って、満期又は期限切れになったコンポジションＩＤを削除することを望む場合がある。したがって、ステップ５２５で（０参照クリップがステップ５２０で削除された後）、サーバは、ストレージ・ディスクの満杯度が特定の割合「Ｘ」かどうかを判定する。ディスクの満杯度がＸ％未満である場合、本プロセスは終了する。ディスクの満杯度がＸ％である場合、サーバはいずれかのＩＤが期限切れになっているかどうかを判定する（ステップ５２７）。どのＩＤも期限切れになっていない場合、本プロセスは終了する。期限切れになったＩＤがある場合、期限切れになったＩＤのリストをステップ５３０で作成し、図４と同様に、期限切れになったＩＤを削除し、そしてそれに関連するクリップの参照計数を、ステップ５４０で減分する。ストレージ・ディスクの満杯度がＸ％以上であるかどうか、本プロセスは再びステップ５４５で問い合わせをする。Ｘ％以上でなければ、本プロセスは終了する。Ｘ％以上ならば、ユーザは、ストレージ・スペースの不足の通知を受け、そしてそのとき手動でデータを削除するような適切な手段をとることができる。

本ネットワークはまた、再生がこのネットワーク中の最も高い優先順位のものであるという事実の説明となる。したがって、ストレージ・マネージャ１９は、優先順位を、要求されるディスク動作に関連付けることを可能にするインターフェースを提供する。例えば３つの優先順位があってもよい。最も高い優先順位は再生の動作である。次に高いものは転送ツールによるワークステーション３からの読み取り動作である。最後に、最下位の優先順位はサーバからのテーブルに対する要求である。最初の優先事項が持っているのに対して、後の２つの優先順位はいかなるリアルタイム制限も持っていないのに対し、最初の優先順位がそれを持っている。

この優先順位スキームは、ストレージ・マネージャが動作を処理し／優先順位付けするのに役立つ。優先順位の使用は、それが最も必要とされるものに、ストレージ・マネージャの帯域幅を割り当てる。システム帯域幅は、すべてのクライアント（例えば複数のワークステーション３）間で共有されなければならない。例えば、ストレージ・マネージャ帯域幅の合計が８ストリームで、２つの再生ストリームがアクティブであるなら、６つのストリームが転送ツールにとって利用可能である。しかしながら、記録動作が開始されると、転送ツールが全体の転送速度を縮小させ、最終的に転送ツールの１つのストリームを退かせて、合計で９つのアクティブなストリームがあることになる。この転送送信中に、ストレージ・マネージャは、バッファーを備えたすべてのクライアントをサポートしそして転送する。したがって、ストレージ・マネージャの優先順位スキームは、オーバーフロー条件の取り扱いをサポートする。

本発明のある種の実施例について以上に説明したが、様々な修正や変更や改良が、当業者には容易に可能である。そのような修正や変更や改良は、本発明の要旨および範囲内にあることを意図している。したがって、以上の説明は単なる例示であり、限定することを意図したものではない。

マルチメディア・ネットワークの実施例を示す。 図１の再生装置７を示す。 図１の再生装置７にマルチメディア・データを格納するプロセスを示す。 再生装置７からコンポジションＩＤを削除するプロセスを示す。 再生装置７から不使用のクリップを削除するために、図２のサーバ１５によって実行されるプロセスを示す。

Claims (9)

1. マルチメディア・システムにおいてデータを共有するための方法であって、
   （Ａ）データを参照するマルチメディア・コンポジションを作成するステップと、
   （Ｂ）第１ロケーションにマルチメディア・コンポジションを転送するステップと、
   （Ｃ）マルチメディア・コンポジションによって参照されるデータが、第１ロケーションに関連するストレージ領域に保持されているかどうかを判定するステップと
   （Ｄ）マルチメディア・コンポジションによって参照されるデータを、そのデータがストレージ領域にまだない時のみ、ストレージ領域に転送するステップと、
   を備えた方法。
2. 請求項１記載の方法であって、その方法がさらに、マルチメディア・コンポジションによって参照されるデータのいずれかが、ストレージ領域に移行中であるかどうかを判定するステップと、ステップ（Ｄ）が、データが移行中でない時だけ、ストレージ領域にデータを転送するステップを含む、方法。
3. 請求項２記載の方法であって、さらに移行中のデータがストレージ領域への転送が完了したかどうかを判定するステップを含む、方法。
4. マルチメディア・システムであって、
   データを参照するマルチメディア・コンポジションを作成するための少なくとも１つのワークステーションと、
   前記ワークステーションによって作成されるマルチメディア・コンポジションを格納して再生するために、前記少なくとも１つのワークステーションに結合された再生装置と、
   前記マルチメディア・コンポジション、およびマルチメディア・コンポジションによって参照されるデータを、前記少なくとも１つのワークステーションから、前記再生装置へ転送するための転送ツールであって、マルチメディア・コンポジションによって参照されるデータであって再生装置に格納されていない転送データのみを転送するように構成された転送ツールと、
   を備えたシステム。
5. 請求項４記載のシステムであって、転送ツールがさらに、マルチメディア・コンポジションによって参照されるデータであってワークステーションから再生装置に移行中でない転送データのみを転送するように構成された、システム。
6. マルチメディア・コンポジション、およびマルチメディア・コンポジションによって参照されるデータを保持している装置内において、マルチメディア・データを削除する方法であって、
   （Ａ）どれほど多くのコンポジションがマルチメディア・データの特定部分を参照しているかを判定するステップと、
   （Ｂ）どのコンポジションも参照していないマルチメディア・データの部分はどれであるかを判定するステップと、
   （Ｃ）どのマルチメディア・コンポジションも参照していないマルチメディア・データを削除するステップと
   を備えた方法。
7. 請求項６記載のマルチメディア・データを削除する方法であって、装置が特定の量以上のマルチメディア・データを保持している時だけ、ステップ（Ｃ）を実行する、方法。
8. 請求項６記載のマルチメディア・データを削除する方法であって、ステップ（Ａ）が、コンポジションがマルチメディア・データの特定部分を参照する回数に対応する参照計数をキープするステップを含む、方法。
9. 請求項７記載のマルチメディア・データを削除する方法であって、ステップ（Ａ）がさらに、そのデータを参照するコンポジションが装置に転送された時、マルチメディア・データの特定部分に対する参照計数を増加させるステップと、そのデータを参照するコンポジションが削除された時、マルチメディア・データの特定部分に対する参照計数を減少させるステップと、を含む方法。

Images