(57)【特許請求の範囲】
【請求項１】
コンテンツデータ及び当該コンテンツデータに関連付けられたメタデータを提供するサーバ装置であって、
前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成手段と、
前記コンテンツデータ及び前記メタデータと、前記生成手段が生成した前記第２の管理データとを、前記コンテンツデータを利用する外部装置に出力する出力手段と、
を有するサーバ装置。
【請求項２】
前記生成手段は、前記コンテンツデータを前記外部装置に公開するために予め決められたディレクトリ情報をさらに示す前記第２の管理データを生成する
請求項１に記載のサーバ装置。
【請求項３】
前記生成手段は、前記第１の識別データに対して予め決められた処理を施して前記第２の識別データを生成する
請求項１に記載のサーバ装置。
【請求項４】
前記生成手段は、前記第１の識別データに所定の固定値を付加して前記第２の識別データを生成する
請求項３に記載のサーバ装置。
【請求項５】
生成手段と出力手段とを有し、コンテンツデータ及び前記コンテンツデータに関連付けられたメタデータを提供するサーバ装置が実行するデータ処理方法であって、
前記生成手段が、前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成工程と、
前記出力手段が、前記コンテンツデータ及び前記メタデータと、前記生成手段が生成した前記第２の管理データとを、前記コンテンツデータを利用する外部装置に出力する出力工程と、
を有するデータ処理方法。
【請求項６】
生成手段と出力手段とを有し、コンテンツデータ及び前記コンテンツデータに関連付けられたメタデータを提供するサーバ装置の有するコンピュータが実行するプログラムであって、
前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成手順と、
前記コンテンツデータ及び前記メタデータと、前記生成手段が生成した前記第２の管理データとを、前記コンテンツデータを利用する外部装置に出力する出力手順と、
を前記コンピュータに実行させるプログラム。
【請求項７】
サーバ装置からクライアント装置にコンテンツデータ及び前記コンテンツデータに関連付けられたメタデータを送信する通信方法であって、
前記サーバ装置が、前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成工程と、
前記クライアント装置が、前記生成工程で生成した前記第２の管理データを、前記サーバ装置から受信する管理データ受信工程と、
前記クライアント装置が、前記管理データ受信工程で受信した前記第２の管理データを基に所望のコンテンツデータを判別するコンテンツデータ判別工程と、
前記クライアント装置が、前記コンテンツデータ判別工程の結果に基づき、前記サーバ装置から前記所望のコンテンツデータと、当該コンテンツデータに関連付けられた前記メタデータと、を受信するコンテンツ受信工程と、
を有する通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツデータをローカルおよびグローバルに識別させるサーバ装置、データ処理方法、プログラムおよび通信方法に関する。
【背景技術】
【０００２】
ストレージ機器が保有するＡＶ(Audio Visual)素材を用いたアプリケーション、例えばノンリニア編集機にとって、当該ストレージ機器にどのようなＡＶ素材が記録されており、どれが所望のＡＶ素材であるかを早急かつ容易に見つけ出すことは古くからの課題である。
ＡＶ素材がファイルといった形式で当該ストレージ機器に保存、管理されている場合、それが標準的なファイルシステムを利用しているならば、例えばＬＩＳＴなどのコマンドを発行することでそれが保持する“ファイルの一覧”を得ることはできる。
しかしながら、このレベルではそれらの内容がＡＶ素材かメタデータ(例えばＸＭＬ(Extensible Markup Language)文書)、あるいはそれ以外のデータかといった区別は無く、何らかのバイナリデータを保持した同じファイルとして扱われることとなる。
【０００３】
他方、当該ファイルシステム上のアプリケーションとして、ＡＶ素材のファイル、メタデータのファイル、それ以外のファイルなど、それらの内容を区別した上でそれらの間の関係を含めて管理するようなＡＶ素材のデータベース・アプリケーションを想定する。このようなアプリケーションを実現する上での中心的な役割を担うものとして、それが管理するＡＶ素材(ファイル)、メタデータ(ファイル)他の一覧及びその関係などを記述した(ファイルあるいは内部メモリへ展開された形式での)管理データが存在する。しかしそのような管理データは往々にして当該データベースアプリケーション専用のものであり、先述したノンリニア編集機アプリケーションなど外部アプリケーションが当該管理データを利用することについては何ら考慮されていない。
【０００４】
【特許文献１】特開２００４−３２０７５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
このような状況に鑑み、本発明では、所定のサーバ装置においてコンテンツデータがローカルに管理されている場合に、そのコンテンツデータを当該サーバ装置の外部でグローバルに管理することを可能にするサーバ装置、データ処理方法、プログラムおよび通信方法を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上述した従来技術の問題点を解決し、上述した目的を達成するため、本発明のサーバ装置は、コンテンツデータ及び当該コンテンツデータに関連付けられたメタデータを提供するサーバ装置であって、前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成手段と、前記コンテンツデータ及び前記メタデータと、前記生成手段が生成した前記第２の管理データとを、前記コンテンツデータを利用する外部装置に出力する出力手段と、を有する。
【０００７】
本発明のデータ処理方法は、生成手段と出力手段とを有し、コンテンツデータ及び前記コンテンツデータに関連付けられたメタデータを提供するサーバ装置が実行するデータ処理方法であって、前記生成手段が、前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成工程と、前記出力手段が、前記コンテンツデータ及び前記メタデータと、前記生成手段が生成した前記第２の管理データとを、前記コンテンツデータを利用する外部装置に出力する出力工程と、を有する。
【０００８】
本発明のプログラムは、生成手段と出力手段とを有し、コンテンツデータ及び前記コンテンツデータに関連付けられたメタデータを提供するサーバ装置の有するコンピュータが実行するプログラムであって、前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成手順と、前記コンテンツデータ及び前記メタデータと、前記生成手段が生成した前記第２の管理データとを、前記コンテンツデータを利用する外部装置に出力する出力手順と、を前記コンピュータに実行させる。
【０００９】
本発明の通信方法は、サーバ装置からクライアント装置にコンテンツデータ及び前記コンテンツデータに関連付けられたメタデータを送信する通信方法であって、前記サーバ装置が、前記コンテンツデータを前記サーバ装置内でローカルに識別する第１の識別データを使用して、前記コンテンツデータと前記メタデータとを区別して当該サーバ装置内での前記コンテンツデータの管理を行うための第１の管理データを基に、前記コンテンツデータを前記サーバ装置の外部でグローバルに識別する第２の識別データを生成し、前記コンテンツデータと当該コンテンツデータに関連付けられた前記メタデータとを当該第２の識別データにより区別して管理する第２の管理データを生成する生成工程と、前記クライアント装置が、前記生成工程で生成した前記第２の管理データを、前記サーバ装置から受信する管理データ受信工程と、前記クライアント装置が、前記管理データ受信工程で受信した前記第２の管理データを基に所望のコンテンツデータを判別するコンテンツデータ判別工程と、前記クライアント装置が、前記コンテンツデータ判別工程の結果に基づき、前記サーバ装置から前記所望のコンテンツデータと、当該コンテンツデータに関連付けられた前記メタデータと、を受信するコンテンツ受信工程と、を有する。
【発明の効果】
【００１０】
本発明によれば、所定のサーバ装置においてコンテンツデータがローカルに管理されている場合に、そのコンテンツデータを当該サーバ装置の外部でグローバルに管理することを可能にするサーバ装置、データ処理方法、プログラムおよび通信方法を提供することができる。
【発明を実施するための最良の形態】
【００１１】
以下、本発明の実施形態に係わる通信システムについて説明する。
図１に示すクライアント装置２が本発明の外部装置の一例であり、サーバ装置４が本発明のサーバ装置の一例である。
また、図１に示すサーバ処理部３７および図２に示す処理回路２５が本発明の生成手段の一例であり、ＦＴＰ処理部３１および処理回路２５が本発明の出力手段の一例である。
また、サーバ処理部３７および処理回路２５が、本発明の処理手段および加工手段の機能を実現する。
また、本実施形態の変形ＵＭＩＤ(Unique Material Identifier)が本発明の第１の識別データの一例であり、本実施形態のＵＭＩＤが本発明の第２の識別データの一例である。
また、本実施形態のインデックスファイルデータＩＮＤが本発明の第１の管理データの一例であり、本実施形態のメディアプロファイルデータＭＰが本発明の第２の管理データの一例である。
また、図２に示すプログラムＦＴＰ＿ＰＲＧ，ＳＥＲ＿ＰＲＧが本発明のプログラムの一例である。
【００１２】
＜本実施形態の概要＞
図１に示す通信システム１は、サーバ装置４が、インデックスファイルデータＩＮＤを基に、記録メディア３５に記録されたビデオデータおよびオーディオデータ、並びにこれらをインターリーブして得られるクリップデータを管理する。ここで、インデックスファイルデータＩＮＤは、サーバ装置４内でユニークな変形ＵＭＩＤを基に各種データを管理している。
サーバ装置４は、記録メディア３５から読み出したビデオデータおよびオーディオデータをインターリーブしてクリップデータを生成し、これをクライアント装置２に送信する。
また、サーバ装置４は、上記クリップデータをグローバルに識別するＵＭＩＤを用いたメディアプロファイルデータＭＰを、インデックスファイルデータＩＮＤを基に生成し、これをクライアント装置２に送信する。
これにより、各種データを、サーバ装置４内での変形ＵＭＩＤを用いて管理し、サーバ装置４外ではＵＭＩＤを用いて管理できる。
【００１３】
＜本実施形態の詳細＞
図１は、本発明の実施形態に係わる通信システム１の全体構成図である。
図１に示すように、通信システム１は、例えば、クライアント装置２とサーバ装置４とを有し、これらがネットワーク６を介して通信を行う。
本実施形態において、クライアント装置２は、複数でもよい。また、ネットワーク６は、ＬＡＮ(Local Area Network)やインターネットなどである。
また、クライアント装置２は、例えば、コンピュータなどの編集装置であり、サーバ装置４はカムコーダなどである。
【００１４】
［クライアント装置２］
図１に示すように、クライアント装置２は、例えば、クライアント処理部４１およびＦＴＰ処理部４２を有する。
クライアント処理部４１およびＦＴＰ処理部４２の機能は、クライアント装置２のハードウェア構成であるＣＰＵが所定のプログラムを実行して実現される。
クライアント処理部４１は、クライアント装置２の機能を統括的に制御し、例えば、ユーザによる操作部（図示せず）の操作に応じた操作信号を解釈して、ＦＴＰ処理部４２にサーバ装置４に対するＦＴＰコマンドを発行する処理や、ＦＴＰ処理部４２から入力したデータを画面表示する処理などを実行する。
ＦＴＰ処理部４２は、サーバ装置４のＦＴＰ処理部３１との間でＦＴＰ(File Transfer Protocol)によるファイル転送処理を行う。
クライアント処理部４１は、例えば、サーバ装置４から入力したクリップデータを受信し、当該クリップデータ内にシリアライズされたＡＶ素材データ（ビデオデータおよびオーディオデータ）を分離した後に再生処理する。また、クライアント処理部４１は、当該再生処理したＡＶ素材データを編集し、編集後のクリップデータをサーバ装置４に送信する。
【００１５】
本実施形態では、クライアント装置２は、後述するように、ＦＴＰ処理部４２の機能により、メディアプロファイルデータＭＰを受信する。メディアプロファイルデータＭＰは、サーバ装置４が保持する複数のクリップデータをグローバルに識別するＵＭＩＤを用いて管理したデータである。
クライアント装置２のクライアント処理部４１は、メディアプロファイルデータＭＰを基に、サーバ装置４にコンテンツデータを要求すると共に、サーバ装置４から受信したコンテンツデータを管理する。
また、クライアント装置２は、メディアプロファイルデータＭＰを基に、サーバ装置４が保持するコンテンツデータをリスト表示する。
また、クライアント装置２は、サーバ装置４からＦＴＰ通信により受信したクリップデータを、上記インデックスファイルデータＩＮＤが規定する当該クリップデータのＵＭＩＤを用いて、当該クリップデータを他の装置に送信したり、あるいは記録メディアに書き込むなどの処理を行う。
【００１６】
［サーバ装置４］
図１に示すように、サーバ装置４は、例えば、ＦＴＰ処理部３１、記録メディア３５、アクセス部３６およびサーバ処理部３７を有する。
ＦＴＰ処理部３１は、クライアント装置２のＦＴＰ処理部４２との間でＦＴＰによるファイル転送処理を行う。
記録メディア３５は、サーバ装置４の撮像部（図示せず）で撮像したビデオデータと、マイクから入力したオーディオデータとを記録する。
記録メディア３５は、例えば、光ディスク、ビデオテープ、ハードディスクなどである。
アクセス部３６は、サーバ処理部３７からの指示に応じて、記録メディア３５にアクセスして、記録メディア３５に記憶されたデータの読み書きを行う。
【００１７】
サーバ処理部３７は、サーバ装置４の処理を統括的に制御する。
サーバ処理部３７は、撮像部（図示せず）で撮像したビデオデータと、マイクから入力したオーディオデータとを、アクセス部３６を介して記録メディア３５に書き込ませる。なお、サーバ処理部３７は、他の装置から受信したビデオデータおよびオーディオデータを、アクセス部３６を介して記録メディア３５に書き込ませてもよい。
また、サーバ処理部３７は、ＦＴＰ処理部３１を介して受信した編集後のビデオデータおよびオーディオデータを、アクセス部３６を介して記録メディア３５に書き込ませる。
また、サーバ処理部３７は、ＦＴＰ処理部３１を介してクライアント装置２から入力した要求に応じて、アクセス部３６を介して、記録メディア３５に記憶されたビデオデータおよびオーディオデータを読み出し、これをシリアライズしてＡＶ素材データを生成する。サーバ処理部３７は、当該生成したＡＶ素材データを、ＦＴＰ処理部３１を介して、クライアント装置２にファイル転送させる。
【００１８】
図２は、図１に示すサーバ装置４のＦＴＰ処理部３１およびサーバ処理部３７を実現するためのハードウェア構成図である。
図２に示すように、サーバ装置４は、例えば、ネットワークＩ／Ｆ２１、メディアＩ／Ｆ２２、メモリ２４および処理回路２５を有している。
【００１９】
ネットワークＩ／Ｆ２１は、図１に示すネットワーク６を介してクライアント装置２との間でデータおよび要求を入出力するインターフェースである。
メディアＩ／Ｆ２２は、アクセス部３６を介して記録メディア３５に対して読み書きされるＡＶデータ等を入出力するインターフェースである。
メモリ２４は、処理回路２５の処理を規定するプログラム、並びに処理回路２５の処理に用いられるデータを記憶する。
具体的には、メモリ２４は、例えば、プログラムＦＴＰ＿ＰＲＧ，ＳＥＲ＿ＰＲＧを記憶する。
また、メモリ２４は、例えば、インデックスファイルデータＩＮＤと、メディアプロファイルデータＭＰとを記憶する。
ここで、インデックスファイルデータＩＮＤは、例えば、図３〜５に示すように、サーバ装置４がその内部処理において、記録メディア３５に記憶されているビデオデータおよびオーディオデータを識別して管理するために用いられる属性データである。
また、メディアプロファイルデータＭＰは、図６および図７に示すように、サーバ装置４の外部の装置、例えば、クライアント装置２の処理において、記録メディア３５に記憶されているビデオデータおよびオーディオデータを識別して管理するために用いられる属性データである。
【００２０】
処理回路２５は、プログラムＦＴＰ＿ＰＲＧを実行することで、図１に示すＦＴＰ処理部３１の機能を実現する。
また、処理回路２５は、プログラムＳＥＲ＿ＰＲＧを実行することで、図１に示すサーバ処理部３７の機能を実現する。
処理回路２５は、サーバ処理部３７により、メモリ２４から読み出したインデックスファイルデータＩＮＤを基に、メディアプロファイルデータＭＰを生成し、これをメモリ２４に書き込む。
【００２１】
［インデックスファイルデータＩＮＤ］
図３〜図５は、インデックスファイルデータＩＮＤの一例を説明するための図である。
インデックスファイルデータＩＮＤは、記録メディア３５に記憶されたＡＶ素材データのサーバ装置４内における管理を目的としたＸＭＬ文書のファイルである。インデックスファイルデータＩＮＤは、サーバ装置４内での管理を目的としたものであるため、ＵＭＩＤの固定文字列先頭１０バイトを省略した変形ＵＭＩＤ(機器内部で固有の素材識別データ)を用いており、記録メディア３５の内部のディレクトリ構造をそのまま表現したものになっている。これにより、サーバ装置４内における変形ＵＭＩＤの処理に係わる構成を小規模化している。
ＵＭＩＤは、ＳＭＰＴＥ  ３３０Ｍとして規定されたＡＶ素材データの管理を目的とした３２バイトのグローバルに一意（ユニーク）な識別子である。
【００２２】
図３〜図５に示すように、インデックスファイルデータＩＮＤは、インデックスファイルデータＩＮＤの全体に対しての属性を示すブロックＢ１と、第１のクリップについての属性を示すブロックＢ２と、第２のクリップについての属性を示すブロックＢ３と、編集内容についての属性を示すブロックＢ４とを有する。
ブロックＢ１は、インデックスファイルデータＩＮＤの構造を規定したＸＭＬ名前空間識別子、記録メディア３５の(globally uniqueな)識別子[proavId]、クリップデータを構成するビデオデータおよびオーディオデータが格納されているディレクトリへの絶対パス[clip Table path]などを示している。クリップデータが記録された記録メディア３５に直接アクセス可能なドライバを持ったアプリケーションは、当該絶対パスを用いることにより、記録メディア３５に記憶されているクリップのビデオデータおよびオーディオデータを、例えば、“/PROAV/CLPR/C0001V01.MXF”などのファイル名で直接見ることができる。
【００２３】
本実施形態において、クリップとは、１回の撮像によって取得されるＡＶ素材データ、あるいはクリップを編集により分割・結合して得られたＡＶ素材データを意味するものとする。
本実施形態において、各クリップは、１チャンネルのビデオデータと、８チャンネルのオーディオデータを有する。
【００２４】
ブロックＢ２は、第１のクリップ全体の属性を示すブロックＣ１と、ビデオデータの属性を示すブロックＣ２と、８チャンネルのオーディオデータの属性をそれぞれ示すブロックＣ３〜Ｃ１０と、その他の属性を示すブロックＣ１１とを有する。
ブロックＣ１は、第１のクリップの変形ＵＭＩＤ[umid]と、そのファイル名[file]と、第１のクリップのＡＶ素材データの再生フレーム速度fpsと、当該ＡＶ素材データの再生時間durと、オーディオのチャンネル数ｃｈと、画角aspectRatioと、再生可能か否かを示すplayableとを示している。
【００２５】
ブロックＣ２は、第１のクリップのビデオデータの変形ＵＭＩＤと、ファイル名[file]と、ファイル種類[type]と、ファイルヘッダのデータ長[header]とを示している。
ブロックＣ３〜Ｃ１０は、第１のクリップの第１〜８のオーディオデータの変形ＵＭＩＤと、ファイル名[file]と、ファイル種類[type]と、ファイルヘッダのデータ長[header]とを示している。
【００２６】
ブロックＣ１１は、サブストリームの変形ＵＭＩＤと、ファイル名[file]と、ファイル種類[type]と、ヘッダ[header]とを示している。ここで、サブストリームとは当該クリップ(と内容は同様ながら、より高い圧縮率で同時生成されたところ)の低解像度版である。
また、ブロックＣ１１は、第１のクリップのタイトルなど静的な情報を記述したデータ[meta file]と、そのファイル種類[type]とを示している。
また、ブロックＣ１１は、第１のクリップのタイムコードなどフレーム毎に変化するような動的な情報を記述したデータのファイル名[rtmeta file]と、そのファイル種類[type]とを示している。
【００２７】
ブロックＢ３は、第２のクリップの属性を示し、上述したブロックＢ２と同様のフォーマットを有している。
【００２８】
ブロックＢ４は、例えば、第１及び第２のクリップを編集して得られる素材の編集内容を示す編集リストデータを示している。
【００２９】
［メディアプロファイルデータＭＰ］
図６および図７は、メディアプロファイルデータＭＰの一例を説明するための図である。
メディアプロファイルデータＭＰは、サーバ装置４の外部において、記録メディア３５に記憶されたＡＶ素材データの管理を目的としたＸＭＬ文書のファイルである。
メディアプロファイルデータＭＰは、サーバ装置４外での管理を目的としたものであるため、前述した(変形ＵＭＩＤに対する)正規のＵＭＩＤを用いている。
【００３０】
図６および図７に示すように、メディアプロファイルデータＭＰは、ブロックＢ１１〜Ｂ１５を有する。
ブロックＢ１１は、メディアプロファイルデータＭＰの全体に対しての属性を示している。
ブロックＢ１２は、メディアプロファイルデータＭＰを生成した機器（ストレージ機器、本実施形態ではサーバ装置４）およびそれに装着された記録メディア３５の属性を示す要素”Properties”である。
ブロックＢ１３〜Ｂ１５は、ストレージ機器に保有された本素材の一覧を示す要素”Contents”である。なお、本素材が存在しない場合は、要素”Contents”は、生成しない。
【００３１】
以下、ブロックＢ１１〜Ｂ１５をさらに詳細に説明する。
ブロックＢ１１は、ＸＭＬ文書であることの宣言<?xml version=…>と、最上位要素<MediaProfile xmlns…>と、最上位要素の属性"createdAt=…"、" version=…"とを有する。
属性"createdAt=…"は、メディアプロファイルデータＭＰの作成日時を示している。また、属性" version=…"、メディアプロファイルデータＭＰのスキーマバージョンを示している。
【００３２】
ブロックＢ１２は、対象ストレージ機器の記述"System"、対象ストレージ機器の固有識別子としてのネットワークノード番号の16進表記"systemId"、対象ストレージ機器の種類"systemKind"  を有する。すなわち、これらが本発明の機器属性データの一例である。
"systemKind"の直後に"Attached"が生成され、"Attached"は対象ストレージ機器が着脱可能な記録メディアを持つ場合、当該ストレージ機器に装着されメディアプロファイルデータＭＰ記述生成の元となった記録メディアの記述を定義している。特に必要でない限り、ひとつの記録メディアにはひとつのメディアプロファイルデータＭＰ記述を対応させる。なお、対象ストレージ機器が着脱可能な記録メディアを持たない場合、本要素を生成しない。
“mediaId"は、当該記録メディアの識別子の記述。直後のmediaKind属性値との組み合わせにて当該記録メディアを一意に識別可能である。
“dm"は、記録媒体属性データDiscMetaのXML名前空間識別子の省略形であって、DiscMeta記述を構成する要素名の先頭に接頭子として付与されるべきものである。ここでは、記録媒体属性データDiscMetaは、Professional Disc (青紫色レーザーを使用した業務用光ディスクの記録フォーマットとディスクの商標)で規定されている記録メディア３５の属性に関する内容が、例えばディスクのタイトルなどが記述されている。これらが本発明の記録媒体属性データの一例である。
【００３３】
ブロックＢ１３〜Ｂ１５は、"Material"要素である。
Material要素はContents要素の子要素として記述する。本要素は下記の属性を持つ。なおvideoType、audioType、aspectRatio属性を除いて全て必須記述要素である。
・uri属性：uri属性はFTP/FAM接続の際に、対象Clipの本線及びEditList(編集リストデータ)へのアクセスが可能な絶対URLを属性値として持つ。"uri=…"は、例えば、図８に示すように、サーバ装置４の外部から、対応するクリップを見せるディレクトリ階層上の位置を示す。具体的にはuri=”/Clip/Cxxxx.MXF”(Clipの場合)、uri=”/Edit/ExxxxE01.SMI”(EditListの場合)と記述される。また、ClipまたはEditListに別名が付加されている場合uriには別名表記でのURLを記述する。本実施形態において、uriは、サーバ装置４の外部で、uriによって指定されたデータ（ファイル）のディレクトリ階層上での位置を見せるために用いられる。すなわち、サーバ装置４によるメディアプロファイルデータＭＰの記述によって、サーバ装置４が保持する各種データ（クリップデータ、編集データ等）の階層構造を外部に見せる形態を規定できる。
・Title属性：本属性は、素材(Clip, EditList)を識別するための文字列である。
・type属性：本属性は、AV素材(Clip)の場合は”MXF”、EditListの場合は”PD-EDL”と記述する。
・videoType属性：本属性値には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-video要素-type属性の値をそのまま記述する。EditListを表現するMaterial要素内には記述しない。
・audioType属性：本属性値には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-audio要素-type属性の値をch数分だけ列挙して記述する。
・fps属性：本属性値には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-fps属性、または対象EditListのeditlist要素-fps属性の値をそのまま記述する。
・dur属性：本属性には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-dur属性、または対象EditListのeditlist要素-dur属性の値をそのまま記述する。
・ch属性：本属性値には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-ch属性、または対象EditListのeditlist要素-ch属性の値をそのまま記述する。
・aspectRatio属性：本属性値には、インデックスファイルデータＩＮＤ内対象Clipのclip要素-aspectRatio属性、または対象EditListのeditlist要素-aspectRatio属性の値をそのまま記述する。インデックスファイルデータＩＮＤ内に当該属性が存在しない場合は省略する。
・offset属性：本属性値には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-video要素-clipBegin属性の値をそのまま記述する。EditListを表現するMaterial要素内にはoffset属性を記述しない。
・umid属性：本属性値には、インデックスファイルデータＩＮＤ内の対象Clipのclip要素-umid属性の値の先頭に、ＵＭＩＤの先頭10byteのprefix(“060A2B34010101050101”)を付加した図９に示すＵＭＩＤの形式で記述する。なお、本実施形態においては、前述したように、インデックスファイルデータＩＮＤ内の変形ＵＭＩＤは、ファイル長節約のため、ＵＭＩＤの先頭10byte分の固定接頭辞を省略した形で記述されている。
【００３４】
Material要素はProxy要素とRelevantInfo要素をそれぞれ1つずつ子要素として持つ。これらの要素はそれぞれクリップに対応した低解像度素材であるProxy、クリップのタイトルなどクリップの静的情報を記述したNonRealTimeMetaファイルを管理するものである。以下に、それぞれの要素の内容を示す。
【００３５】
・Proxy要素：本要素はProxyに対する情報であり、サーバ装置４（XDCAM）ではClipに対応するMaterial要素の子要素として必ず出現し、EditListに対応するMaterial要素の子要素としては出現しない。本要素は空要素であり、以下の属性を持つ。
・uri属性：uri属性はFTP/FAM接続の際に、対象ClipのProxyへのアクセスが可能な絶対URLを属性値として持つ。
・type属性：サーバ装置４で扱うProxyは常にMXFファイル(OP1a)であるため、本属性値は必ず”MXF”と記述する。
・videoType属性：サーバ装置４で扱うProxyのVideo CodecはPD File Format仕様書で規定されており、本属性値はそのフォーマットを表す”PD_Proxy_Video”と記述する。
・audioType属性：サーバ装置４で扱うProxyのAudio CodecはPD File Format仕様書でA-lawと規定されており、本属性値は”A-Law”と記述する。
・umid属性：本属性値には、インデックスファイルデータＩＮＤ内対象Clipのclip要素-subStream要素-umid属性の値の先頭に、ＵＭＩＤの先頭10byeのprefix(“060A2B34010101050101”)を付加したグローバルなＵＭＩＤの形式で記述する。
【００３６】
・RelevantInfo要素：本要素はNonRealTimeMetaに対する情報であり、サーバ装置４ではMaterial要素の子要素として必ず出現するものとする。本実施形態において、NonRealTimeMetaは、具体的には、クリップのタイトルなど静的な情報を記述したデータを示している。" RelevantInfo"は、本素材データに関連付けられたプロキシＡＶ素材以外のメタデータに関する記述である。本要素は空要素であり、以下の属性を持つ。
・uri属性：uri属性はFTP/FAM接続の際に、対象Clip及びEditListのNonRealTimeMetaへのアクセスが可能な絶対URLを属性値として持つ。具体的には、uri=“/Clip/CxxxxM01.XML"またはuri=“/Edit/ExxxxM01.XML"と記述される。
・type属性：NonRealTimeMetaファイルはＸＭＬ文書であるため、本属性値は”XML”と記述する。
【００３７】
以下、通信システム１の動作を、サーバ装置４の動作を中心に説明する。
［第１の動作例］
サーバ装置４によるメディアプロファイルデータＭＰの生成処理について説明する。
図１０は、第１の動作例を説明するためのフローチャートである。
ステップＳＴ１１：
図２に示すサーバ装置４のサーバ処理部３７は、ネットワーク６を介してクライアント装置２との間の接続が確立したか否かを判断し、接続が確立したと判断したことを条件にステップＳＴ１２に進む。
【００３８】
ステップＳＴ１２：
サーバ装置４のサーバ処理部３７は、図２に示すメモリ２４からインデックスファイルデータＩＮＤを読み出し、これを基にメディアプロファイルデータＭＰを生成する。
当該処理については、第２の動作例で詳細に説明する。
【００３９】
ステップＳＴ１３：
サーバ装置４のサーバ処理部３７は、ステップＳＴ１２で生成したメディアプロファイルデータＭＰを、ＦＴＰ処理部３１を介してＦＴＰ通信でクライアント装置２に送信する。
クライアント装置２は、サーバ装置４から受信したメディアプロファイルデータＭＰを基に、例えば、メディアプロファイルデータＭＰ内の"uri="を用いて、図８に示すように、サーバ装置４が規定した公開形式に従って、記録メディア３５内に記憶されているクリップデータ(Clip)、編集リストデータ(Edit)および低解像度クリップデータ(Sub)を格納したディレクトリを表示する。
また、クライアント装置２は、サーバ装置４からＦＴＰで受信したインターリーブデータ（クリップデータ）を、ＵＭＩＤでグローバルに識別して管理する。
【００４０】
［第２の動作例］
図１０に示すステップＳＴ１３におけるメディアプロファイルデータＭＰの生成処理について詳細に説明する。
図１１は、第２の動作例を説明するためのフローチャートである。
ステップＳＴ２１：
サーバ装置４のサーバ処理部３７は、図１０のステップＳＴ１１で接続が確立したと判断すると、ステップＳＴ２２の処理に進む。
【００４１】
ステップＳＴ２２：
サーバ装置４のサーバ処理部３７は、図２に示すメモリ２４からインデックスファイルデータＩＮＤを読み出し、インデックスファイルデータＩＮＤ内の各クリップの変形ＵＭＩＤを読み出し、その先頭に予め決められたＵＭＩＤの先頭の１０バイト（ＵＭＩＤであることを示す固定文字列）を付加して３２バイトのＵＭＩＤを生成する。
【００４２】
ステップＳＴ２３：
サーバ装置４のサーバ処理部３７は、クリップデータ（インターリーブデータ）の"uri"を決定する。"uri"は、サーバ装置４の外部から対象クリップの本線及び編集リストデータ（EditList）へのアクセスが可能な絶対アドレスを示している。
【００４３】
ステップＳＴ２４：
サーバ装置４のサーバ処理部３７は、インデックスファイルデータＩＮＤから、属性videoType、audioType、fps 、dur 、ch 、aspectRatio 、offset を取得する。
ステップＳＴ２５：
サーバ装置４のサーバ処理部３７は、NonRealTimeMetaなどの本素材に関連付けられたプロキシＡＶ素材以外のメタデータを示すRelevantInfo要素を生成する。
【００４４】
サーバ装置４のサーバ処理部３７は、記録媒体属性データDiscMetaを記録メディアから読み出す。
本実施形態において、記録媒体属性データDiscMetaとは、ディスクのタイトルやディスクの初期化日時などディスクに関する静的な情報を記述している。
【００４５】
サーバ装置４のサーバ処理部３７は、ステップＳＴ２２〜２７で取得および生成したデータと、それら以外の図６および図７に示す各種のデータとを格納してメディアプロファイルデータＭＰを生成する。
【００４６】
＜第３の動作例＞
サーバ装置４が、クライアント装置２からクリップ要求を受けた場合を説明する。
図１２は、第３動作例を説明するためのフローチャートである。
ステップＳＴ３１：
図２に示すサーバ装置４のサーバ処理部３７は、ＦＴＰ処理部３１がＦＴＰ通信により、クライアント装置２からクリップ要求を受信したか否かを判断する。
当該クリップ要求には、例えば、要求対象のクリップのＵＭＩＤが含まれている。
【００４７】
ステップＳＴ３２：
サーバ装置４のサーバ処理部３７は、ステップＳＴ３１で受信したクリップ要求に含まれるＵＭＩＤの先頭１０バイトより後ろの部分に対応した変形ＵＭＩＤを取得する。
そして、サーバ処理部３７は、当該取得した変形ＵＭＩＤと、インデックスファイルデータＩＮＤとを基に、クリップ要求に係わる単数のビデオデータと、８個のオーディオデータへのファイルパスを得る。
【００４８】
ステップＳＴ３３：
サーバ装置４のサーバ処理部３７は、ステップＳＴ３２で取得したファイルパスを基に、クリップ要求に係わる単数のビデオデータと８個のオーディオデータとを記録メディア３５から読み出す。
【００４９】
ステップＳＴ３４：
サーバ装置４のサーバ処理部３７は、ステップＳＴ３３で読み出した単数のビデオデータと８個のオーディオデータとをインターリーブしてクリップデータを生成する。
そして、サーバ処理部３７は、ＦＴＰ処理部３１のＦＴＰ機能により、図２に示すネットワークＩ／Ｆ２１を介してクライアント装置２に上記クリップデータを送信する。
クライアント装置２は、サーバ装置４からのクリップデータを、ＦＴＰ処理部４２の機能により取得し、クライアント処理部４１の機能により、例えば、再生処理する。
【００５０】
＜第４の動作例＞
通信システム１では、例えば、NonRealTimeMeta(NRT)や編集リストデータからのターゲット素材参照にＵＭＩＤを用いる。図１３に示すように、ＮＲＴ属性から、ＮＲＴデータベースによりＵＭＩＤを取得し、ＵＭＩＤ／Ｄｉｓc解決データベースにより、そのターゲットファイルが記録された記録メディアの固有識別子ProavIdを取得する。そして、当該メディア識別子ProavIdを基に、サーバ装置４において記録メディア３５内のファイルデータにアクセスが行われる。
【００５１】
以上説明したように、通信システム１によれば、サーバ装置４において変形ＵＭＩＤを用いたインデックスファイルデータＩＮＤを基に、ＵＭＩＤを用いたメディアプロファイルデータＭＰを生成し、これをクライアント装置２に送信する。
そのため、サーバ装置４においてはビット長の短い変形ＵＭＩＤを基に小規模な構成で処理を行うと共に、クライアント装置２においては、ＵＭＩＤを基にクリップデータ等を管理できる。
【００５２】
また、通信システム１によれば、サーバ装置４は、メディアプロファイルデータＭＰ内の属性"uri"によって、クリップデータ、編集リストデータおよび低解像度データについて、サーバ装置４の外部において見せる階層構造を規定できる。これにより、クライアント装置２がサーバ装置４から実際に受信するデータと、クライアント装置２が見る階層構造およびファイル名とを一致させることができる。
【００５３】
また、通信システム１によれば、サーバ装置４はメディアプロファイルデータＭＰをクライアント装置２に送信することで、サーバ装置４からクライアント装置２に送信する各種データを扱うストレージ機器（サーバ装置４）の属性、並びにその記録メディア３５の属性をクライアント装置２に知らせることができる。
【００５４】
また、通信システム１によれば、サーバ装置４がクライアント装置２に送信するメディアプロファイルデータＭＰ内に、クリップデータが記録されている記録媒体、並びにサーバ装置４の属性情報を格納するため、クライアント装置２はそれらを基に、当該クリップデータを適切な条件で再生・編集できる。
【００５５】
本発明は上述した実施形態には限定されない。
すなわち、当業者は、本発明の技術的範囲またはその均等の範囲内において、上述した実施形態の構成要素に関し、様々な変更、コンビネーション、サブコンビネーション、並びに代替を行ってもよい。
上述した実施形態では、サーバ装置４とクライアント装置２とがＦＴＰ通信する場合を例示したが、本発明は、例えば適切なドライバを介して当該ディスクに記録されたデータを、よく知られたファイルの基本操作APIであるopen(), read(), write(), close()を介してアクセスする場合においても適用可能である。
また、上述した実施形態では、本発明のコンテンツデータの一例として、ビデオデータ、オーディオデータおよびクリップデータなどを例示したが、これらに限定されるものではない。
【図面の簡単な説明】
【００５６】
【図１】図１は、本発明の実施形態の通信システムの全体構成図である。
【図２】図２は、図１に示すサーバ装置のＦＴＰ処理部およびサーバ処理部を実現するためのハードウェア構成図である。
【図３】図３は、インデックスファイルデータＩＮＤの一例を説明するための図である。
【図４】図４は、インデックスファイルデータＩＮＤの一例を説明するための図３の続きの図である。
【図５】図５は、インデックスファイルデータＩＮＤの一例を説明するための図４の続きの図である。
【図６】図６は、メディアプロファイルデータＭＰの一例を説明するための図である。
【図７】図７は、メディアプロファイルデータＭＰの一例を説明するための図６の続きの図である。
【図８】図８は、メディアプロファイルデータを基にクライアント装置に表示される各種データのディレクトリ構造を説明するための図である。
【図９】図９は、変形ＵＭＩＤとＵＭＩＤとの関係を説明するための図である。
【図１０】図１０は、図１に示すサーバ装置によるメディアプロファイルデータＭＰの生成処理について説明するためのフローチャートである。
【図１１】図１１は、図１０に示すステップＳＴ１３におけるメディアプロファイルデータＭＰの生成処理について詳細に説明するためのフローチャートである。
【図１２】図１２は、図１に示すサーバ装置がクライアント装置からクリップ要求を受けた場合に行う処理を説明するためのフローチャートである。
【図１３】図１３は、ＵＭＩＤとファイルパスとの関係を説明するための図である。
【符号の説明】
【００５７】
１…通信システム、２…クライアント装置、４…サーバ装置、２１…ネットワークＩ／Ｆ、２２…メディアＩ／Ｆ、２４…メモリ、２５…処理回路、３１…ＦＴＰ処理部、３５…記録メディア、３６…アクセス部、３７…サーバ処理部、４１…クライアント処理部、４２…ＦＴＰ処理部、ＩＤＦ…インデックスファイルデータ、ＭＰ…メディアプロファイルデータ
【図１】
0004626483.tif 000002
【図２】
0004626483.tif 000003
【図３】
0004626483.tif 000004
【図４】
0004626483.tif 000005
【図５】
0004626483.tif 000006
【図６】
0004626483.tif 000007
【図７】
0004626483.tif 000008
【図８】
0004626483.tif 000009
【図９】
0004626483.tif 000010
【図１０】
0004626483.tif 000011
【図１１】
0004626483.tif 000012
【図１２】
0004626483.tif 000013
【図１３】
0004626483.tif 000014