映像情報処理ファイルシステム
【課題】 ユーザがアプリケーションソフトがファイルデータのフォーマット及び映像圧縮形式に対応しているか否かを意識せずに操作することを可能にする。
【解決手段】 本発明は、ファイルシステムが、ファイルデータの映像品質パラメータ（フォーマット及び映像圧縮形式）を取得し、取得した映像品質パラメータをディレクトリ階層構成として管理し、ユーザからディレクトリ階層構成のファイルにアクセスすることで要求する映像品質パラメータを取得し、当該映像品質パラメータでファイルデータ（映像データ）を変換して、要求元のユーザに返却する。
【解決手段】 本発明は、ファイルシステムが、ファイルデータの映像品質パラメータ（フォーマット及び映像圧縮形式）を取得し、取得した映像品質パラメータをディレクトリ階層構成として管理し、ユーザからディレクトリ階層構成のファイルにアクセスすることで要求する映像品質パラメータを取得し、当該映像品質パラメータでファイルデータ（映像データ）を変換して、要求元のユーザに返却する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像情報処理ファイルシステムに係り、特に、映像製作時に利用する映像情報を提供及び取得するための映像情報処理ファイルシステムに関する。
【背景技術】
【０００２】
電子計算機上において、独自フォーマットファイルのデータを扱う場合、はじめに、当該データをユーザやアプリケーションソフトが読み込み可能なフォーマットに変換した後で、利用することが必要になる。特に、映像ファイルを編集作業する場合には、用いる映像編集アプリケーションソフトが映像ファイルフォーマットに対応している必要がある。しかし、そうでない場合には、
（１）対象映像圧縮ファイルフォーマットをアプリケーションソフトに読み込むためのプラグインソフトを作成する；
（２）事前に対象映像ファイルをTIFFフォーマットなどの汎用的静止画ファイルフォーマットの連番ファイルとして伸張変換を行った後で、アプリケーションソフトに読み込む；
ことが必要になる。（１）では、プラグインソフトを開発するための時間的、金銭的コストがかかり、（２）の圧縮ファイルを伸張変換する場合には、一時ファイルとして非圧縮映像データが生成されるために膨大な記憶容量が必要になる。
【０００３】
また、映像技術において、さまざまな映像フォーマット、および、映像品質が存在し、ユーザ環境によって、取り扱い可能な映像フォーマット、映像品質は異なる。そのため、事前処理として、編集対象となる映像ファイルから、適宜映像品質を変換してユーザに提供しなければならない。例えば、解像度がHD(High Definition)品質(1920画素 x 1080画素)かつフレームレートが60fpsの映像ファイルを編集する場合に、ユーザの使用する映像編集アプリケーションソフトがSD(Standard Definition)品質(720画素 x 480画素)かつフレームレートが30fpsの映像フォーマットのみサポートする場合、事前処理として解像度変換、および、フレームレート変換が必要になる。
【０００４】
また、ファイルの属性を考慮してディレクトリ階層をファイルシステムとして実装し、それぞれのディレクトリで可能な操作を制限し、編集操作ミスを防ぐデータシステムがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１９７２４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献１の技術は、ファイル属性と仮想ファイルシステム上のディレクトリ構成を対応付けるものであり、ファイルの操作制限に主眼を置いている。そのため、ユーザの望む品質で映像ファイルを取得することはできないという問題がある。
【０００７】
また、映像コンテンツのトランスコードや編集処理を行う場合、一般的に膨大な計算リソースが必要になる。映像を扱うユーザ全てがこうした環境を構築するのは現状では不可能である。また、処理した映像データを複数のユーザで利用する場合、映像データ形式や機器環境が異なる等の理由により、ユーザ間での映像データの共有ができないことがある。さらに、映像データ形式だけでなく、解像度や色深度などの映像プロパティの要件などもユーザ毎に異なる。従来のシステムでは、同じ映像コンテンツに対してあらゆる形式、プロパティのデータを用意して対応している。しかし、新しい形式やプロパティが追加されるたびに対応するデータを用意する必要があるが、そのファイル数が膨大になってしまうため現実的ではない。
【０００８】
また、ユーザが映像編集ソフトなどのアプリケーションから非対応映像データを扱う場合には、プラグインソフトウェアを利用してデータの入出力を行う。しかし、プラグインソフトウェアはアプリケーション毎に異なる仕様であるため、複数のアプリケーションで利用する場合には、それぞれのプラグインソフトウェアを用意する必要がある。
【０００９】
本発明は、上記の点に鑑みなされたもので、自社等で独自に開発した独自フォーマットファイルを利用する場合に、ユーザ及びアプリケーションソフトが要求するファイルフォーマットで容易に取り込みが可能で、また、独自フォーマットファイルである映像圧縮ファイルを編集する場合に、使用するユーザの要求するファイル形式、映像品質で編集対象ファイルへのアクセス手段を提供することが可能な映像情報処理ファイルシステムを実現することを目的とする。
【００１０】
また、更に、多様なフォーマットや形式の映像データをユーザが、その作業環境に関係なく扱うことが可能な映像情報処理ファイルシステムを実現することを目的とする。
【課題を解決するための手段】
【００１１】
上記の課題を解決するために、本発明（請求項１）は、電子計算機上で独自に開発されたフォーマットの画像データをフォーマットファイルで管理する映像情報処理ファイルシステムであって、
前記映像データのディレクトリ階層、ファイル名を含む映像品質パラメータを取得するパラメータ取得手段と、
前記フォーマットファイルから前記映像品質パラメータに対応するファイルを抽出し、該ファイルのバイナリデータフォーマットの変換を行い、要求元に変換結果を返却するファイルデコード手段と、を有する。
【００１２】
また、本発明（請求項２）は、前記ファイルデコード手段に、
前記パラメータ取得手段で取得した前記映像品質パラメータに基づいて、映像圧縮フォーマットファイルを変換する手段を含む。
【００１３】
また、本発明（請求項３）は、前記映像品質パラメータに基づいて、対応可能なデコード品質を示すディレクトリ構成を生成するディレクトリ階層形成手段を更に有する。
【００１４】
また、本発明（請求項４）は、前記パラメータ取得手段において、
デコード対象とする対象圧縮ファイルフォーマットから指定可能な映像品質パラメータを取得する手段を含む。
【００１５】
本発明（請求項５）は、電子計算機上で独自に開発されたフォーマットの画像データを仮想ファイルで管理する映像情報処理ファイルシステムであって、
クライアント部とサーバ部とがネットワークを介して接続され、
前記クライアント部は、
映像データをキャッシュするローカルキャッシュバッファを制御するローカルキャッシュ制御手段と、
コーデックリスト、コンテンツリスト、映像処理リストを含む映像処理パラメータリスト記憶手段と、
前記仮想ファイルシステムからファイルパスと、該ファイルパスに対応する映像処理コマンドを取得し、該映像処理コマンドの処理を行う仮想ファイル処理手段と、
前記ファイルパスを分解して１つ以上のパラメータを取得し、該パラメータに基づいて前記映像処理パラメータリスト記憶手段を参照して、該パラメータが有効であるかを判定し、有効であると判断された前記パラメータに対応する映像データが前記ローカルキャッシュバッファにある場合は、前記仮想ファイル処理手段に送り、ない場合は該パラメータに対応するコマンドを前記サーバ部に送信し、該サーバ部から映像処理データを取得して該仮想ファイル処理手段に送るファイルパス制御手段と、
を有し、
前記サーバ部は、
映像データをキャッシュするリモートキャッシュテーブルを制御するリモートキャッシュ制御手段と、
前記クライアント部から前記映像コマンドを受信すると、前記リモートキャッシュテーブルに該映像コマンドに対応する映像データがキャッシュされているか判定し、キャッシュされている場合は該映像データを該クライアント部に送信し、キャッシュされていない場合は、該映像コマンドに応じた映像処理を行うトランスコード映像処理手段と、を有する。
【００１６】
また、本発明（請求項６）は、前記サーバ部の前記トランスコード映像処理手段において、
前記映像コマンドの処理対象ファイルに対して連続するファイルがある場合は、該映像コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成し、生成されたコマンドの映像処理データが前記リモートキャッシュにキャッシュされていない場合は該生成されたコマンドを実行する予測変換処理手段を含む。
【００１７】
また、本発明（請求項７）は、前記予測変換処理手段において、
前記生成されたコマンドを実行した後、前記リモートキャッシュ制御手段に対してキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う手段を含む。
【発明の効果】
【００１８】
上記のように、本発明は、映像圧縮されたファイルをはじめとした、独自フォーマットのファイルを操作する際に、従来のファイル変換過程を経ずに、ユーザやアプリケーションソフトがファイルフォーマットを意識せずにファイルデータを利用すること、また、使用目的に最適なファイルフォーマットをディレクトリ構造とファイル名により、統一したインタフェースにより即時に利用することが可能となる。
【００１９】
また、独自フォーマットファイルの仕様を公開することなく、一般ユーザやアプリケーションソフトアが当該ファイルフォーマットのデータを利用することが可能となる。
【００２０】
さらに、映像を取り扱う場合に、対象映像形式やサイズなどをユーザが要求する形式で提供することが可能になる。また、ネットワーク上の計算機資源を用いることができるため、ユーザの作業環境の機器性能に関係なく映像処理を行うことが可能になる。
【図面の簡単な説明】
【００２１】
【図１】本発明の第１の実施の形態におけるFUSEを用いた映像情報処理ファイルシステムの構成例である。
【図２】本発明の第１の実施の形態における仮想ファイルディレクトリ構造を示す図である。
【図３】本発明の第１の実施の形態におけるユーザによるディレクトリ操作を示す図である。
【図４】本発明の第１の実施の形態におけるユーザによるデコードデータ取得す操作を示す図である。
【図５】本発明の第１の実施の形態におけるマウント処理部の動作のフローチャートである。
【図６】本発明の第１の実施の形態における独自JPEG2000フォーマットプロパティ情報取得部のフローチャートである。
【図７】本発明の第１の実施の形態におけるディレクトリ階層形成部の動作のフローチャートである。
【図８】本発明の第１の実施の形態におけるファイルデコード部の動作のフローチャートである。
【図９】本発明の第２の実施の形態におけるシステム構成図である。
【図１０】本発明の第２の実施の形態におけるファイルパスの規定形式である。
【図１１】本発明の第２の実施の形態におけるファイルパス制御部の映像処理の制御のフローチャートである。
【図１２】本発明の第２の実施の形態における映像処理パラメータ制御部の構成図である。
【図１３】本発明の第２の実施の形態におけるローカルキャッシュ制御部のローカルキャッシュテーブルの例である。
【図１４】本発明の第２の実施の形態におけるローカルキャッシュ制御部の動作のフローチャートである。
【図１５】本発明の第２の実施の形態における通信制御部の初期化動作のシーケンスチャートである。
【図１６】本発明の第２の実施の形態におけるトランスコード映像処理部の動作のフローチャートである。
【図１７】本発明の第２の実施の形態における予測変換制御部の動作のフローチャートである。
【発明を実施するための形態】
【００２２】
以下図面と共に、本発明の実施の形態を説明する。
【００２３】
［第１の実施の形態］
本実施の形態では、OSのユーザ空間で処理を定義できるFUSE(Filesystem in Userspace)を用いたシステムの実装について、以下に説明する。
【００２４】
図１は、本発明の第１の実施の形態におけるFUSEを用いた映像情報処理ファイルシステムの構成例を示す。
【００２５】
同図に示すシステムは、JPEG2000ファイルフォーマットプロパティ取得部５０、マウント処理部６０、ディレクトリ階層形成部７０、ファイルデコード部８０によって構成される、これらの機能部をＯＳの基本機能として提供される仮想ファイルシステム３０とユーザ空間でファイル操作定義を可能にするFUSE４０を用いて制御することで、JPEG2000をベースにした独自フォーマットファイル（以後、JPEG2000独自フォーマット）を利用ユーザが意識することなく汎用ファイルフォーマットとして利用可能にするものである。
【００２６】
独自JPEG2000フォーマットプロパティ取得部５０は、JPEG2000フォーマットファイルを利用するユーザから指定されたディレクトリ階層、ファイル名（ファイルパス）に基づいてファイルの解像度、レイヤ数などのプロパティ情報を取得する。
【００２７】
マウント処理部６０は、JPEG2000独自フォーマットの製作者であるユーザから指定されたJPEG2000独自フォーマットファイルをマウントポイントに登録する。ここで、マウントポイントとは、当該ユーザが当該システムにアクセスするための最初の（最上位の）ディレクトリ位置を指す。
【００２８】
ディレクトリ階層形成部７０は、プロパティ情報（ファイルの解像度、レイヤ数等）に基づいて、対応可能なデコード品質を示すディレクトリ構造を形成する。
【００２９】
ファイルデコード部８０は、独自JPEG2000フォーマットプロパティ取得部５０で取得したプロパティ情報に基づいて、JPEG2000独自フォーマットファイルから該当ファイル（バイナリデータフォーマット）を抽出しデコード（バイナリフォーマットに変換）する。
【００３０】
一般に、JPEG2000圧縮形式は、解像度、ＳＮＲスケーラビリティ(レイヤ数)を持ち合わせており、圧縮データから該当する箇所のみをデコードすることで、目的の解像度、品質が得られる特徴をもつ。本システムで用いられるJPEG2000独自フォーマットファイル２０においても、以上の性質を継承している。例えば、3840画素×1260画素の解像度を持ち、レイヤ数が3であるJPEG2000独自フォーマットファイルの場合、対応可能な解像度は3480画素2160画素(ディレクトリでは3840と表記)、1920×1080画素(ディレクトリでは1920と表記)である。また、対応可能なデコードレイヤ数は、L1のみ(ディレクトリではL1と表記)、L1とL2(ディレクトリではL2と表記)、L1からL3まですべて(ディレクトリではL3と表記)となる。
【００３１】
図２は、本発明の第１の実施の形態における仮想ファイルディレクトリ構造を示したものである。本システムでマウントされたJPEG2000独自フォーマットファイルは、図２のようなディレクトリ階層を用いてユーザからアクセス可能である。ディレクトリの各階層は、最上位にはマウントルートのディレクトリ、第２階層にはデコード可能な解像度、第３階層にはデコード可能なレイヤ数、第４階層にはデコード可能なファイル形式、第5階層にはデコード可能なビット深度、第６階層にはフレーム数をファイル名に持つデコードファイルでそれぞれ構成される。
【００３２】
図３は、本発明の第１の実施の形態におけるユーザによるディレクトリ操作を示す図であり、製作側のユーザが本システムを用いてJPEG2000独自フォーマットファイルをマウントし、ディレクトリを移動する操作を示している。
【００３３】
まず、JPEG200独自フォーマットの製作者は、初めに、mntj2kコマンドを用いて"MOVIE1"というファイル名を持つJPEG2000独自フォーマットファイルを"/MOUNTPOINT"にマウントする。"mntj2k"コマンドは本システムをFUSE４０を用いて実装した場合の実行ファイル名である。このときFUSE４０を通して、本システムのマウント処理部６０が呼び出されマウントが完了する（ステップ１０１）。
【００３４】
続いて、"/MOUNTPOINT"ディレクトリを指定し（ステップ１０２）、"ls"コマンドを用いて、FUSE４０にファイル一覧の取得を指示する（ステップ１０３）。このとき、FUSE４０を通してディレクトリ階層形成部７０が呼び出され、ディレクトリを構成するファイル名から対応可能な解像度として、例えば、"3840"及び"1920"を返す（ステップ１０４）。これを各階層繰り返すことで、ファイルパスを用いてユーザの求める品質のデコードデータを指定することができる（ステップ１０５〜ステップ１１６）。
【００３５】
図４は、本発明の第１の実施の形態におけるユーザによるデコードデータ取得操作を示す図であり、ユーザが本システムを用いてJPEG2000独自フォーマットファイルにアクセスしデコードデータを取得する操作を示している。
【００３６】
ユーザが"/MOUNTPOINT"ディレクトリを指定し（ステップ２０１）、ファイルパス"./3840/L3/TIFF/16/00000.tif"コマンドによりFUSE４０を介して、JPEG2000独自フォーマットファイルに対して、解像度3840画素×1920画素、レイヤ数3、TIFF静止画形式、16ビット深度、00000番目のデータを取得している（ステップ２０２、２０３）。このとき、FUSE４０を通してファイルデコード部８０が呼び出され、デコードデータがユーザに返される。
【００３７】
図５は、本発明の第１の実施の形態におけるマウント処理部の動作のフローチャートである。
【００３８】
はじめに、独自JPEG2000フォーマットプロパティ取得部５０において、FUSE４０からファイルの解像度、レイヤ数などのプロパティ情報を取得する（ステップ３０１）。
【００３９】
続いて、マウント処理部６０は、ステップ３０１で取得したプロパティ情報に基づいて、対応可能なデコード品質を示すディレクトリ構造を形成するディレクトリ階層形成部７０をFUSE４０のreaddirコールバック関数に登録する。また、FUSE４０のreadコールバックにファイルデコーダ部８０を登録する（ステップ３０３）。
【００４０】
図６は、本発明の第１の実施の形態における独自JPEG2000フォーマットプロパティ情報取得部のフローチャートである。
【００４１】
JPEG2000フォーマットプロパティ情報取得部５０は、はじめに、ユーザから指定された対象ファイルが本システムで対応可能なフォーマットであるかを判別する（ステップ４０１）。本発明のシステムで用いるJPEG2000ファイルには、ファイルバイナリの先頭に事前に定義されたヘッダ識別"0xFFFFFFF0"が配置されており、この識別子の有無で対応可能か否かの判別を行う。対応可能である場合には（ステップ４０１、Yes）、当該ファイルに含まれる映像フレーム数、フレームレート、圧縮色空間、解像度、分割タイル数、JPEG2000圧縮レイヤ数、JPEG2000圧縮ウェーブレットレベル数を取得する（ステップ４０２〜４０８）。これらの情報を基にして、本システムのディレクトリ構成、デコード品質指定を行う。
【００４２】
図７は、本発明の第１の実施の形態におけるディレクトリ階層形成部の動作のフローチャートである。
【００４３】
ディレクトリ階層形成部７０は、はじめに、現在のファイルパス階層からどの品質を示すディレクトリ階層にいるのかを取得する（ステップ５０１）。現在のディレクトリが第１階層、すなわち本システムのマウントルートである場合には（ステップ５０２、Yes）、対応可能な解像度の一覧をディレクトリ名としてFUSE４０に返す（ステップ５０３）。現在のディレクトリが第2階層、すなわち解像度を示す階層である場合には（ステップ５０４、Yes）、対応可能なレイヤ数の一覧をディレクトリ名として返す（ステップ５０５）。現在のディレクトリが第3階層、すなわちレイヤ数階層である場合には（ステップ５０６、Yes）、対応可能なデコードファイル形式の一覧をディレクトリ名として返す（ステップ５０７）。現在のディレクトリが第4階層、すなわちデコードファイル形式階層である場合には（ステップ５０８、Yes）、対応可能なビット深度の一覧をディレクトリ名として返す（ステップ５０９）。現在のディレクトリが第5階層、すなわちビット深度階層である場合には（ステップ５１０、Yes）、映像フレームの番号列をファイル名として返す（ステップ５１１）。
【００４４】
以上により、ディレクトリ階層的にデコードする映像品質、形式が一意的に表現される。
【００４５】
図８は、本発明の第１の実施の形態におけるファイルデコード部の動作のフローチャートである。
【００４６】
ファイルデコード部８０は、ユーザから与えられたファイルパスからデコードの解像度、レイヤ数、デコードファイル形式、ビット深度、フレーム番号を、デコードのためのデコード品質パラメータとして取得する（ステップ６０１〜６０５）。続いて、これらのデコード品質パラメータでデコード可能であるかを判別する（ステップ６０６）。デコード可能であるかを判断するのは、ディレクトリ階層を辿り、目的のファイルにアクセスする場合には、デコード不可能なパラメータを含むファイルパスになることはないが、ファイルシステムに直接ファイルパスを指定することも可能であり、この場合に、デコード不可能なパラメータを含むファイルパスを渡すことも考えられるためである。デコード可能であると判別されると（ステップ６０６、Yes）、JPEG2000独自フォーマットファイルから該当ファイルを抜き出し、デコード品質パラメータに基づいてデコードし（ステップ６０７）、デコード結果を要求元のユーザに返す（ステップ６０８）。
【００４７】
[第２の実施の形態]
前述の第１の実施の形態では、各ユーザ端末に高い性能やデータ保持を必要とするため、利用できるユーザが限定されるが、本実施の形態では、映像情報処理ファイルシステムの機能のうち、多くの計算機資源を必要とする機能をサーバ部に、計算機資源をあまり必要としない機能をクライアント部に分担し、両者がネットワークを介して協調する形態を説明する。
【００４８】
図９は、本発明の第２の実施の形態におけるシステム構成を示す。
【００４９】
同図に示すシステムは、クライアント側処理制御部１００とサーバ側処理制御部２００がネットワークにより接続されている。但し、この例に限定されることなく、ネットワーク接続をユーザ計算機内のループバックネットワークとして、同計算機内にサーバ部とクライアント部を導入することで、ユーザのローカル環境時に閉じて本実施の形態を適用することも可能である。
【００５０】
クライアント側システム１００は、仮想ファイル処理部１１０、ファイルパス制御部１２０、映像パラメータリスト部１４０、ローカルキャッシュ処理部１５０、クライアント側通信制御部１３０で構成される。
【００５１】
一方のサーバ側処理制御部２００は、サーバ側通信制御部２１０、トランスコード映像処理部２２０、映像蓄積サーバ３００、映像処理器プール２０１、コーデックプール２０２で構成される。
【００５２】
本システムで用いるファイルパスの規定形式を図１０に示す。ファイルパスは、1つ以上のパラメータで構成される。各パラメータは、処理識別するためのパラメータ識別子と、続いてその処理のオプション指定などを表す個別パラメータで構成される。例えば、映像蓄積サーバ３００に蓄積されている"clip0123"という映像ファイルをデコードするという処理を示すパラメータは、"DEC_clip0123"と表すことができ、ここでは"DEC_"がパラメータ識別子、"clip0123"が個別パラメータになる。実際のファイルパスは、例えば、"/DEC_clip0123/ENC_TIFF/ENC_OPT_DEPTH_16/PROC_RESIZE_50P"のように1つ以上のパラメータで構成される。この時、それぞれのパラメータの順序は任意である。
【００５３】
通常のファイルパスは階層構造を持っており、パスの順序によって指定するファイルやオブジェクトが変化する。映像処理をファイルにマッピングするには、映像処理に該当する実行コマンドをファイルパスと１対１に対応させることと等価である。本実施の形態では、処理順序が予め一意に決まり、フィアルパスの階層構造に伴う処理順序は意味を持たない。例えば、本実施の形態での映像処理では、まず、はじめにデコード処理を、続いて指定があれば、中間の映像処理を行い、最後にエンコード処理を行うことになる。そこで、本システムでは、ファイルパスの階層構造を無視し、異なる階層構造の場合においても意味する処理構成が変化しないファイルパスを規定し、これを用いる。
【００５４】
クライアント側処理制御部１００の仮想ファイル処理部１１０は、OSの一部である仮想ファイルシステム１０２からのコールバック呼び出しに対応する処理を行う。基本的に、仮想ファイルシステム１０２からの呼び出しのうち、read命令に関する処理が要求された場合に、そのときに仮想ファイルシステム１０２から受けたファイルパスをファイルパス制御部１２０に送る。
【００５５】
ファイルパス制御部１２０は、仮想ファイル処理部１１０から受けたファイルパスに基づき、映像処理の制御を行う。この時の処理を図１１に示す。
【００５６】
フィルパス制御部１２０は、ファイルパスを分解し(ステップ７０１)、１つ以上のパラメータとして認識する。続いて、パラメータリスト部１４０を参照して(ステップ７０２)、分解したすべてのパラメータが有効であるかを確かめる(ステップ７０３)。一つでも無効のパラメータがあった場合は(ステップ７０３、No)、エラー結果を仮想ファイル処理部１１０に返す(ステップ７０４)。すべてのパラメータが有効であった場合には(ステップ７０３、Yes)、ローカルキャッシュ処理部１５０を参照し、このパラメータに該当する映像処理データがローカルキャッシュにあるかを確認する(ステップ７０５)。もし、ローカルキャッシュに所望の映像処理データがある場合には(ステップ７０５、Yes)、それを仮想ファイル処理部１１０に送る(ステップ７０６)。そうでない場合には、クライアント通信制御部１３０を介してサーバ側処理制御部２００にパラメータに対応するコマンドを送信する(ステップ７０７)。その後、サーバ側処理制御部２００から映像処理データを受信し(ステップ７０８)、ローカルキャッシュ制御部１５０に対して、キャッシュ要求を行う(ステップ７０９)。その後、仮想ファイル処理部１１０に映像データを送信する(ステップ７１０)。
【００５７】
映像処理パラメータリスト部１４０の構成を図１２に示す。
【００５８】
映像処理パラメータリスト部１４０は、本システムで対応可能なコーデックリスト１４１、映像処理リスト１４２、コンテンツリスト１４３を保持し、ファイルパスに含まれるパラメータと実際の処理に用いられるコマンドとの対応関係を解決する。
【００５９】
例えば、コーデックリスト１４１には、図１２に示すように、対応コーデックの種類とその該当するコマンドが記述されている。
【００６０】
エントリ"ENC_MPEG2：encode mpeg2"は"ENC_MPEG2"というパラメータが有効であること、その時のエンコードのコマンドが"encode mpeg2"であることを示している。ここで、本システムで"encode mpeg2"というコマンドによって実行できるものとする。また、エントリ"ENC_MPEG2_OPT_BPS_%f"は"ENC_MPEG2"パラメータのオプションであることを示しており、対応するコマンドオプションが"-bitrate %f"で与えられることを示している。ここで、"%f"は少数表現の数を示している。これより、例えばパラメータが"/ENC_MPEG2/ENC_MPEG2_OPT_BPS_12.34"で与えられている場合、コーデックリスト１４１を参照することにより、対応するコマンドが"encode mpeg2 -bitrate 12.34"であると解決される。
【００６１】
映像処理パラメータリスト部１４０に含まれる映像処理リスト１４２に関しても同様の処理によりファイルパスに含まれるパラメータから映像処理のコマンドを解決することが可能である。また、コンテンツリスト１４３は、映像蓄積サーバ３００にある利用可能な映像コンテンツの一覧である。
【００６２】
コーデックリスト、映像処理リスト、コンテンツリストは、クライアント側処理制御部とサーバ側処理制御部との接続初期化のときに更新される。
【００６３】
ローカルキャッシュ処理部１５０は、ローカルキャッシュ制御部１５１とローカルキャッシュバッファ１５２とから構成される。ローカルキャッシュバッファ１５２は、映像処理データの一時的なキャッシュの保存領域として使われ、ローカルキャッシュ制御部１５１がそのデータ管理を行う。ローカルキャッシュ制御部１５１では、ローカルキャッシュテーブルを用いてローカルキャッシュバッファ１５２の管理を行う。
【００６４】
ローカルキャッシュテーブル１５１１を図１３に示す。ローカルキャッシュテーブル１５１１は、構成フィールドとして、エントリ番号(No)、コマンド、更新時間、キャッシュバッファ上のアドレス、ファイルサイズを持つ。例えば、当該ローカルキャッシュテーブル１５１１に、
"1, decode clip0123; resize 50p; enc tiff -depth 16;, 2011.01.02.19.11, 0x0000001f, 5461200"
というエントリがあった場合、エントリ番号1として、コマンド"decode clip0123; resize 50p; enc tiff -depth 16;"の映像処理データが時刻2011年1月2日19時11分にキャッシュバッファ１５２上のアドレス0x0000001fの位置から5461200バイトの領域にキャッシュされているという情報を管理している。
【００６５】
ローカルキャッシュ制御部１５１の動作を図１４に示す。
【００６６】
はじめに、ファイルパス制御部１２０から参照対象のコマンドを受信する（ステップ８０１）。その後、ローカルキャッシュテーブル１５１１に該当コマンドがあるかを検索する。もしなければ(ステップ８０２、No)、ローカルキャッシュバッファ１５２に該当映像処理データがないことをファイルパス制御部１２０に通知する(ステップ８０３)。もしあれば(ステップ８０２、Yes)、ローカルキャッシュテーブル１５１１を参照し、該当する映像処理データをファイルパス制御部１２０に返す(ステップ８０４)。また、このときローカルキャッシュテーブル１５１１の更新時間を更新する(ステップ８０５)。
【００６７】
クライアント側通信制御部１３０およびサーバ側通信制御部２１０は、ネットワーク接続されたクライアント側制御部１００とサーバ側制御部２００との間のコマンドおよびデータの通信を行う。
【００６８】
図１５にこれら通信制御部の初期化の動作を示す。
【００６９】
まず、クライアント側通信制御部１３０からサーバ側通信制御部２１０に対して接続要求を行い(ステップ９０１)、それに対する応答通知を交換する(ステップ９０２)。その後、映像処理パラメータリスト部１４０に含まれるコーデックリスト１４１、映像処理リスト１４２、および、コンテンツリスト１４３の更新を行う（ステップ９０３〜９０８）。最後に、初期化完了通知を交換し、初期化が終了する（ステップ９０９〜９１１）。初期化後もネットワークのセッションを保持して、サーバ側通信制御部２１０はコマンドを受け付ける状態に入る(Listen状態)。これ以降は、クライアント側通信制御部１３０から送信されるコマンド要求を受け付けることが可能になる。
【００７０】
サーバ側処理制御部２００のトランスコード映像処理部２２０は、デコード処理部２２１、0または1つ以上の映像処理部２２２、エンコード処理部２２３、中間データバッファ２２４、リモートキャッシュ制御部２２５、予測変換処理部２２６から構成される。
【００７１】
図１６にトランスコード映像処理部２２０の動作を示す。
【００７２】
サーバ通信制御部２１０からクライアント側通信制御部１３０から送信されたコマンドを受信し(ステップ１００１)、リモートキャッシュ制御部２２５を参照し、当該コマンドがキャッシュされているかを確認する(ステップ１００２)。キャッシュされている場合には(ステップ１００２、Yes)、該当する映像処理データをサーバ側通信制御部２１０に返す(ステップ１００３)。キャッシュされていない場合には(ステップ１００２、No)、コマンドの映像処理を実行する(ステップ１００４)。この処理は、デコード処理部２２１、映像処理部２２２、エンコード処理部２２３上で行われ、要求された処理コマンドに基づき、それぞれの処理を実行する。処理データは中間データバッファ２２４を介して逐次的に次の処理部に渡される。
【００７３】
その後、最終的な映像処理データおよびその該当コマンドがリモートキャッシュ制御部２２５に通知され、キャッシュ情報の更新を行う(ステップ１００５)。続いて、前ステップで実行したコマンドを予測変換制御部２２６に通知する（ステップ１００６）。最後に、映像処理データをサーバ通信制御部２１０に返す(ステップ１００７)。
【００７４】
リモートキャッシュ制御部２２５は、クライアント側処理制御部１００のローカルキャッシュ制御部１５０と同様に、キャッシュテーブルを保持し、これに基づきリモートキャッシュの管理を行う。ここで用いられるキャッシュテーブルの構造は、図１３に示したローカルキャッシュテーブル１５１１と同様である。
【００７５】
予測変換制御部２２６は、データ参照の局所性を利用し、今後要求されると予想される映像処理を実行しキャッシュする予測変換を行う。予測変換制御部２２６の動作を図１７に示す。
【００７６】
はじめに、上記のステップ１００６の処理により、トランスコード制御部２２０で実行したコマンドの通知を受ける（ステップ１１０１）。このコマンド内の処理対象ファイルに対して、連続するファイルがあるかを判別する。例えば処理対象ファイルが映像フレーム単位である場合、それに続くフレームに該当するファイルがあるか否かを判別する(ステップ１１０２)。連続するファイルがあると判別された場合(ステップ１１０２、Yes)、トランスコード制御部２２０内で実行した映像処理コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成する(ステップ１１０３)。続いて、リモートキャッシュ制御部２２５を参照し、前ステップで生成されたコマンドの映像処理データがキャッシュされているかを確認する(ステップ１１０４)。もし、キャッシュされていない場合(ステップ１１０４、No)、生成されたコマンドを実行する(ステップ１１００５)映像処理の実行が完了した後、リモートキャッシュ制御部２２５にキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う(ステップ１１０６)。予測変換制御部２２６で生成された映像処理データも、通常の映像処理データと同一のキャッシュテーブルで管理されるため、トランスコード制御部２２０では、両者の区別をすることなくキャッシュされている映像処理データの管理が可能である。
【００７７】
サーバ側処理制御部２００に接続される映像蓄積サーバ３００、映像処理器プール２０１、コーデックプール２０２はそれぞれ、処理対象の映像データ、映像処理プログラム、コーデックプログラムが蓄積されている。
【００７８】
本実施の形態では、トランスコードを含めた映像処理をファイルにマッピングすることで、ＯＳの基本機能であるファイルシステムを用いて映像処理手段を提供する。これにより、アプリケーション毎にプラグインソフトウェアを用意する必要がなくなり、統一した形式でユーザ所望の映像形式で映像コンテンツを取り扱うことが可能になる。また、本実施の形態は映像処理に関して、多くの計算機資源を必要とするサーバ部（サーバ側処理制御部）と、計算機資源をあまり必要としないクライアント部[クライアント側処理制御部]に分け、両者をネットワーク接続する構成をとる。これにより、計算機環境が乏しいユーザでも、ネットワークを介して計算機資源が豊富なサーバ部に接続さえすれば、映像処理が可能になる。
【００７９】
また、本実施の形態では、ネットワークの資源を使うことを前提にしているため、複数のユーザが一つのサーバにアクセスすることで本システムの同時利用が可能である。ユーザ側では、ファイルパスの処理とデータのキャッシュ処理のみを行う。これはテキスト処理とデータコピー処理のみで完結するため、ユーザ側での処理負荷は非常に低い。
【００８０】
サーバ部に含まれるキャッシュ(リモートキャッシュ)では、ファイルアクセスの局所性を考慮して、過去に処理した映像データのキャッシュと今後アクセスが予想される映像処理を予測して実行する。これにより、サーバ部の計算機資源を有効に使うことができ、ユーザから要求される映像処理に対して高速に応答することが可能になる。
【００８１】
実際に映像処理の計算処理を行うサーバ部では、複数のユーザからの映像処理が要求されるため、サーバ部にあるリモートキャッシュには多くの処理結果がキャッシュされるため、キャッシュヒットの可能性が高くない。また、キャッシュの要求を毎回受けると処理負荷が高くなる。そこで、本システムでは、ユーザ環境内にもキャッシュ機構(ローカルキャッシュ)を設けることで、各ユーザのキャッシュヒットの高効率性を実現する。
【００８２】
また、本発明は、上記で説明した図１の独自JPEG2000フォーマットプロパティ取得部、マウント処理部、ディレクトリ階層形成部、ファイルデコード部の各機能部の処理、及び、図９に示したクライアント側処理制御部、サーバ側処理制御部の各機能部の処理をプログラムとして構築し、映像情報処理ファイルシステム（装置）として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８３】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００８４】
１０ 汎用ファイルフォーマット
２０ JPEG2000独自フォーマットファイル
３０ 仮想ファイルシステム
４０ FUSE
５０ 独自JPEG2000フォーマットプロパティ取得部
６０ マウント処理部
７０ ディレクトリ階層形成部
８０ ファイルデコード部
１００ クライアント側処理制御部
１０１ ユーザアプリケーション
１０２ 仮想ファイルシステム
１１０ 仮想ファイル処理部
１２０ ファイルパス制御部
１３０ クライアント側通信制御部
１４０ 映像処理パラメータリスト部
１５０ ローカルキャッシュ処理部
１５１ ローカルキャッシュ制御部
１５２ ローカルキャッシュバッファ
２００ サーバ側処理制御部
２０１ 映像処理器プール
２０２ コーデックプール
２１０ サーバ側通信制御部
２２０ トランスコード映像処理部
２２１ デコード処理部
２２２ 映像処理部
２２３ エンコード処理部
２２４ 中間データバッファ
２２５ リモートキャッシュ制御部
２２６ 予測変換処理部
３００ 映像蓄積サーバ
【技術分野】
【０００１】
本発明は、映像情報処理ファイルシステムに係り、特に、映像製作時に利用する映像情報を提供及び取得するための映像情報処理ファイルシステムに関する。
【背景技術】
【０００２】
電子計算機上において、独自フォーマットファイルのデータを扱う場合、はじめに、当該データをユーザやアプリケーションソフトが読み込み可能なフォーマットに変換した後で、利用することが必要になる。特に、映像ファイルを編集作業する場合には、用いる映像編集アプリケーションソフトが映像ファイルフォーマットに対応している必要がある。しかし、そうでない場合には、
（１）対象映像圧縮ファイルフォーマットをアプリケーションソフトに読み込むためのプラグインソフトを作成する；
（２）事前に対象映像ファイルをTIFFフォーマットなどの汎用的静止画ファイルフォーマットの連番ファイルとして伸張変換を行った後で、アプリケーションソフトに読み込む；
ことが必要になる。（１）では、プラグインソフトを開発するための時間的、金銭的コストがかかり、（２）の圧縮ファイルを伸張変換する場合には、一時ファイルとして非圧縮映像データが生成されるために膨大な記憶容量が必要になる。
【０００３】
また、映像技術において、さまざまな映像フォーマット、および、映像品質が存在し、ユーザ環境によって、取り扱い可能な映像フォーマット、映像品質は異なる。そのため、事前処理として、編集対象となる映像ファイルから、適宜映像品質を変換してユーザに提供しなければならない。例えば、解像度がHD(High Definition)品質(1920画素 x 1080画素)かつフレームレートが60fpsの映像ファイルを編集する場合に、ユーザの使用する映像編集アプリケーションソフトがSD(Standard Definition)品質(720画素 x 480画素)かつフレームレートが30fpsの映像フォーマットのみサポートする場合、事前処理として解像度変換、および、フレームレート変換が必要になる。
【０００４】
また、ファイルの属性を考慮してディレクトリ階層をファイルシステムとして実装し、それぞれのディレクトリで可能な操作を制限し、編集操作ミスを防ぐデータシステムがある（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−１９７２４４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上記特許文献１の技術は、ファイル属性と仮想ファイルシステム上のディレクトリ構成を対応付けるものであり、ファイルの操作制限に主眼を置いている。そのため、ユーザの望む品質で映像ファイルを取得することはできないという問題がある。
【０００７】
また、映像コンテンツのトランスコードや編集処理を行う場合、一般的に膨大な計算リソースが必要になる。映像を扱うユーザ全てがこうした環境を構築するのは現状では不可能である。また、処理した映像データを複数のユーザで利用する場合、映像データ形式や機器環境が異なる等の理由により、ユーザ間での映像データの共有ができないことがある。さらに、映像データ形式だけでなく、解像度や色深度などの映像プロパティの要件などもユーザ毎に異なる。従来のシステムでは、同じ映像コンテンツに対してあらゆる形式、プロパティのデータを用意して対応している。しかし、新しい形式やプロパティが追加されるたびに対応するデータを用意する必要があるが、そのファイル数が膨大になってしまうため現実的ではない。
【０００８】
また、ユーザが映像編集ソフトなどのアプリケーションから非対応映像データを扱う場合には、プラグインソフトウェアを利用してデータの入出力を行う。しかし、プラグインソフトウェアはアプリケーション毎に異なる仕様であるため、複数のアプリケーションで利用する場合には、それぞれのプラグインソフトウェアを用意する必要がある。
【０００９】
本発明は、上記の点に鑑みなされたもので、自社等で独自に開発した独自フォーマットファイルを利用する場合に、ユーザ及びアプリケーションソフトが要求するファイルフォーマットで容易に取り込みが可能で、また、独自フォーマットファイルである映像圧縮ファイルを編集する場合に、使用するユーザの要求するファイル形式、映像品質で編集対象ファイルへのアクセス手段を提供することが可能な映像情報処理ファイルシステムを実現することを目的とする。
【００１０】
また、更に、多様なフォーマットや形式の映像データをユーザが、その作業環境に関係なく扱うことが可能な映像情報処理ファイルシステムを実現することを目的とする。
【課題を解決するための手段】
【００１１】
上記の課題を解決するために、本発明（請求項１）は、電子計算機上で独自に開発されたフォーマットの画像データをフォーマットファイルで管理する映像情報処理ファイルシステムであって、
前記映像データのディレクトリ階層、ファイル名を含む映像品質パラメータを取得するパラメータ取得手段と、
前記フォーマットファイルから前記映像品質パラメータに対応するファイルを抽出し、該ファイルのバイナリデータフォーマットの変換を行い、要求元に変換結果を返却するファイルデコード手段と、を有する。
【００１２】
また、本発明（請求項２）は、前記ファイルデコード手段に、
前記パラメータ取得手段で取得した前記映像品質パラメータに基づいて、映像圧縮フォーマットファイルを変換する手段を含む。
【００１３】
また、本発明（請求項３）は、前記映像品質パラメータに基づいて、対応可能なデコード品質を示すディレクトリ構成を生成するディレクトリ階層形成手段を更に有する。
【００１４】
また、本発明（請求項４）は、前記パラメータ取得手段において、
デコード対象とする対象圧縮ファイルフォーマットから指定可能な映像品質パラメータを取得する手段を含む。
【００１５】
本発明（請求項５）は、電子計算機上で独自に開発されたフォーマットの画像データを仮想ファイルで管理する映像情報処理ファイルシステムであって、
クライアント部とサーバ部とがネットワークを介して接続され、
前記クライアント部は、
映像データをキャッシュするローカルキャッシュバッファを制御するローカルキャッシュ制御手段と、
コーデックリスト、コンテンツリスト、映像処理リストを含む映像処理パラメータリスト記憶手段と、
前記仮想ファイルシステムからファイルパスと、該ファイルパスに対応する映像処理コマンドを取得し、該映像処理コマンドの処理を行う仮想ファイル処理手段と、
前記ファイルパスを分解して１つ以上のパラメータを取得し、該パラメータに基づいて前記映像処理パラメータリスト記憶手段を参照して、該パラメータが有効であるかを判定し、有効であると判断された前記パラメータに対応する映像データが前記ローカルキャッシュバッファにある場合は、前記仮想ファイル処理手段に送り、ない場合は該パラメータに対応するコマンドを前記サーバ部に送信し、該サーバ部から映像処理データを取得して該仮想ファイル処理手段に送るファイルパス制御手段と、
を有し、
前記サーバ部は、
映像データをキャッシュするリモートキャッシュテーブルを制御するリモートキャッシュ制御手段と、
前記クライアント部から前記映像コマンドを受信すると、前記リモートキャッシュテーブルに該映像コマンドに対応する映像データがキャッシュされているか判定し、キャッシュされている場合は該映像データを該クライアント部に送信し、キャッシュされていない場合は、該映像コマンドに応じた映像処理を行うトランスコード映像処理手段と、を有する。
【００１６】
また、本発明（請求項６）は、前記サーバ部の前記トランスコード映像処理手段において、
前記映像コマンドの処理対象ファイルに対して連続するファイルがある場合は、該映像コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成し、生成されたコマンドの映像処理データが前記リモートキャッシュにキャッシュされていない場合は該生成されたコマンドを実行する予測変換処理手段を含む。
【００１７】
また、本発明（請求項７）は、前記予測変換処理手段において、
前記生成されたコマンドを実行した後、前記リモートキャッシュ制御手段に対してキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う手段を含む。
【発明の効果】
【００１８】
上記のように、本発明は、映像圧縮されたファイルをはじめとした、独自フォーマットのファイルを操作する際に、従来のファイル変換過程を経ずに、ユーザやアプリケーションソフトがファイルフォーマットを意識せずにファイルデータを利用すること、また、使用目的に最適なファイルフォーマットをディレクトリ構造とファイル名により、統一したインタフェースにより即時に利用することが可能となる。
【００１９】
また、独自フォーマットファイルの仕様を公開することなく、一般ユーザやアプリケーションソフトアが当該ファイルフォーマットのデータを利用することが可能となる。
【００２０】
さらに、映像を取り扱う場合に、対象映像形式やサイズなどをユーザが要求する形式で提供することが可能になる。また、ネットワーク上の計算機資源を用いることができるため、ユーザの作業環境の機器性能に関係なく映像処理を行うことが可能になる。
【図面の簡単な説明】
【００２１】
【図１】本発明の第１の実施の形態におけるFUSEを用いた映像情報処理ファイルシステムの構成例である。
【図２】本発明の第１の実施の形態における仮想ファイルディレクトリ構造を示す図である。
【図３】本発明の第１の実施の形態におけるユーザによるディレクトリ操作を示す図である。
【図４】本発明の第１の実施の形態におけるユーザによるデコードデータ取得す操作を示す図である。
【図５】本発明の第１の実施の形態におけるマウント処理部の動作のフローチャートである。
【図６】本発明の第１の実施の形態における独自JPEG2000フォーマットプロパティ情報取得部のフローチャートである。
【図７】本発明の第１の実施の形態におけるディレクトリ階層形成部の動作のフローチャートである。
【図８】本発明の第１の実施の形態におけるファイルデコード部の動作のフローチャートである。
【図９】本発明の第２の実施の形態におけるシステム構成図である。
【図１０】本発明の第２の実施の形態におけるファイルパスの規定形式である。
【図１１】本発明の第２の実施の形態におけるファイルパス制御部の映像処理の制御のフローチャートである。
【図１２】本発明の第２の実施の形態における映像処理パラメータ制御部の構成図である。
【図１３】本発明の第２の実施の形態におけるローカルキャッシュ制御部のローカルキャッシュテーブルの例である。
【図１４】本発明の第２の実施の形態におけるローカルキャッシュ制御部の動作のフローチャートである。
【図１５】本発明の第２の実施の形態における通信制御部の初期化動作のシーケンスチャートである。
【図１６】本発明の第２の実施の形態におけるトランスコード映像処理部の動作のフローチャートである。
【図１７】本発明の第２の実施の形態における予測変換制御部の動作のフローチャートである。
【発明を実施するための形態】
【００２２】
以下図面と共に、本発明の実施の形態を説明する。
【００２３】
［第１の実施の形態］
本実施の形態では、OSのユーザ空間で処理を定義できるFUSE(Filesystem in Userspace)を用いたシステムの実装について、以下に説明する。
【００２４】
図１は、本発明の第１の実施の形態におけるFUSEを用いた映像情報処理ファイルシステムの構成例を示す。
【００２５】
同図に示すシステムは、JPEG2000ファイルフォーマットプロパティ取得部５０、マウント処理部６０、ディレクトリ階層形成部７０、ファイルデコード部８０によって構成される、これらの機能部をＯＳの基本機能として提供される仮想ファイルシステム３０とユーザ空間でファイル操作定義を可能にするFUSE４０を用いて制御することで、JPEG2000をベースにした独自フォーマットファイル（以後、JPEG2000独自フォーマット）を利用ユーザが意識することなく汎用ファイルフォーマットとして利用可能にするものである。
【００２６】
独自JPEG2000フォーマットプロパティ取得部５０は、JPEG2000フォーマットファイルを利用するユーザから指定されたディレクトリ階層、ファイル名（ファイルパス）に基づいてファイルの解像度、レイヤ数などのプロパティ情報を取得する。
【００２７】
マウント処理部６０は、JPEG2000独自フォーマットの製作者であるユーザから指定されたJPEG2000独自フォーマットファイルをマウントポイントに登録する。ここで、マウントポイントとは、当該ユーザが当該システムにアクセスするための最初の（最上位の）ディレクトリ位置を指す。
【００２８】
ディレクトリ階層形成部７０は、プロパティ情報（ファイルの解像度、レイヤ数等）に基づいて、対応可能なデコード品質を示すディレクトリ構造を形成する。
【００２９】
ファイルデコード部８０は、独自JPEG2000フォーマットプロパティ取得部５０で取得したプロパティ情報に基づいて、JPEG2000独自フォーマットファイルから該当ファイル（バイナリデータフォーマット）を抽出しデコード（バイナリフォーマットに変換）する。
【００３０】
一般に、JPEG2000圧縮形式は、解像度、ＳＮＲスケーラビリティ(レイヤ数)を持ち合わせており、圧縮データから該当する箇所のみをデコードすることで、目的の解像度、品質が得られる特徴をもつ。本システムで用いられるJPEG2000独自フォーマットファイル２０においても、以上の性質を継承している。例えば、3840画素×1260画素の解像度を持ち、レイヤ数が3であるJPEG2000独自フォーマットファイルの場合、対応可能な解像度は3480画素2160画素(ディレクトリでは3840と表記)、1920×1080画素(ディレクトリでは1920と表記)である。また、対応可能なデコードレイヤ数は、L1のみ(ディレクトリではL1と表記)、L1とL2(ディレクトリではL2と表記)、L1からL3まですべて(ディレクトリではL3と表記)となる。
【００３１】
図２は、本発明の第１の実施の形態における仮想ファイルディレクトリ構造を示したものである。本システムでマウントされたJPEG2000独自フォーマットファイルは、図２のようなディレクトリ階層を用いてユーザからアクセス可能である。ディレクトリの各階層は、最上位にはマウントルートのディレクトリ、第２階層にはデコード可能な解像度、第３階層にはデコード可能なレイヤ数、第４階層にはデコード可能なファイル形式、第5階層にはデコード可能なビット深度、第６階層にはフレーム数をファイル名に持つデコードファイルでそれぞれ構成される。
【００３２】
図３は、本発明の第１の実施の形態におけるユーザによるディレクトリ操作を示す図であり、製作側のユーザが本システムを用いてJPEG2000独自フォーマットファイルをマウントし、ディレクトリを移動する操作を示している。
【００３３】
まず、JPEG200独自フォーマットの製作者は、初めに、mntj2kコマンドを用いて"MOVIE1"というファイル名を持つJPEG2000独自フォーマットファイルを"/MOUNTPOINT"にマウントする。"mntj2k"コマンドは本システムをFUSE４０を用いて実装した場合の実行ファイル名である。このときFUSE４０を通して、本システムのマウント処理部６０が呼び出されマウントが完了する（ステップ１０１）。
【００３４】
続いて、"/MOUNTPOINT"ディレクトリを指定し（ステップ１０２）、"ls"コマンドを用いて、FUSE４０にファイル一覧の取得を指示する（ステップ１０３）。このとき、FUSE４０を通してディレクトリ階層形成部７０が呼び出され、ディレクトリを構成するファイル名から対応可能な解像度として、例えば、"3840"及び"1920"を返す（ステップ１０４）。これを各階層繰り返すことで、ファイルパスを用いてユーザの求める品質のデコードデータを指定することができる（ステップ１０５〜ステップ１１６）。
【００３５】
図４は、本発明の第１の実施の形態におけるユーザによるデコードデータ取得操作を示す図であり、ユーザが本システムを用いてJPEG2000独自フォーマットファイルにアクセスしデコードデータを取得する操作を示している。
【００３６】
ユーザが"/MOUNTPOINT"ディレクトリを指定し（ステップ２０１）、ファイルパス"./3840/L3/TIFF/16/00000.tif"コマンドによりFUSE４０を介して、JPEG2000独自フォーマットファイルに対して、解像度3840画素×1920画素、レイヤ数3、TIFF静止画形式、16ビット深度、00000番目のデータを取得している（ステップ２０２、２０３）。このとき、FUSE４０を通してファイルデコード部８０が呼び出され、デコードデータがユーザに返される。
【００３７】
図５は、本発明の第１の実施の形態におけるマウント処理部の動作のフローチャートである。
【００３８】
はじめに、独自JPEG2000フォーマットプロパティ取得部５０において、FUSE４０からファイルの解像度、レイヤ数などのプロパティ情報を取得する（ステップ３０１）。
【００３９】
続いて、マウント処理部６０は、ステップ３０１で取得したプロパティ情報に基づいて、対応可能なデコード品質を示すディレクトリ構造を形成するディレクトリ階層形成部７０をFUSE４０のreaddirコールバック関数に登録する。また、FUSE４０のreadコールバックにファイルデコーダ部８０を登録する（ステップ３０３）。
【００４０】
図６は、本発明の第１の実施の形態における独自JPEG2000フォーマットプロパティ情報取得部のフローチャートである。
【００４１】
JPEG2000フォーマットプロパティ情報取得部５０は、はじめに、ユーザから指定された対象ファイルが本システムで対応可能なフォーマットであるかを判別する（ステップ４０１）。本発明のシステムで用いるJPEG2000ファイルには、ファイルバイナリの先頭に事前に定義されたヘッダ識別"0xFFFFFFF0"が配置されており、この識別子の有無で対応可能か否かの判別を行う。対応可能である場合には（ステップ４０１、Yes）、当該ファイルに含まれる映像フレーム数、フレームレート、圧縮色空間、解像度、分割タイル数、JPEG2000圧縮レイヤ数、JPEG2000圧縮ウェーブレットレベル数を取得する（ステップ４０２〜４０８）。これらの情報を基にして、本システムのディレクトリ構成、デコード品質指定を行う。
【００４２】
図７は、本発明の第１の実施の形態におけるディレクトリ階層形成部の動作のフローチャートである。
【００４３】
ディレクトリ階層形成部７０は、はじめに、現在のファイルパス階層からどの品質を示すディレクトリ階層にいるのかを取得する（ステップ５０１）。現在のディレクトリが第１階層、すなわち本システムのマウントルートである場合には（ステップ５０２、Yes）、対応可能な解像度の一覧をディレクトリ名としてFUSE４０に返す（ステップ５０３）。現在のディレクトリが第2階層、すなわち解像度を示す階層である場合には（ステップ５０４、Yes）、対応可能なレイヤ数の一覧をディレクトリ名として返す（ステップ５０５）。現在のディレクトリが第3階層、すなわちレイヤ数階層である場合には（ステップ５０６、Yes）、対応可能なデコードファイル形式の一覧をディレクトリ名として返す（ステップ５０７）。現在のディレクトリが第4階層、すなわちデコードファイル形式階層である場合には（ステップ５０８、Yes）、対応可能なビット深度の一覧をディレクトリ名として返す（ステップ５０９）。現在のディレクトリが第5階層、すなわちビット深度階層である場合には（ステップ５１０、Yes）、映像フレームの番号列をファイル名として返す（ステップ５１１）。
【００４４】
以上により、ディレクトリ階層的にデコードする映像品質、形式が一意的に表現される。
【００４５】
図８は、本発明の第１の実施の形態におけるファイルデコード部の動作のフローチャートである。
【００４６】
ファイルデコード部８０は、ユーザから与えられたファイルパスからデコードの解像度、レイヤ数、デコードファイル形式、ビット深度、フレーム番号を、デコードのためのデコード品質パラメータとして取得する（ステップ６０１〜６０５）。続いて、これらのデコード品質パラメータでデコード可能であるかを判別する（ステップ６０６）。デコード可能であるかを判断するのは、ディレクトリ階層を辿り、目的のファイルにアクセスする場合には、デコード不可能なパラメータを含むファイルパスになることはないが、ファイルシステムに直接ファイルパスを指定することも可能であり、この場合に、デコード不可能なパラメータを含むファイルパスを渡すことも考えられるためである。デコード可能であると判別されると（ステップ６０６、Yes）、JPEG2000独自フォーマットファイルから該当ファイルを抜き出し、デコード品質パラメータに基づいてデコードし（ステップ６０７）、デコード結果を要求元のユーザに返す（ステップ６０８）。
【００４７】
[第２の実施の形態]
前述の第１の実施の形態では、各ユーザ端末に高い性能やデータ保持を必要とするため、利用できるユーザが限定されるが、本実施の形態では、映像情報処理ファイルシステムの機能のうち、多くの計算機資源を必要とする機能をサーバ部に、計算機資源をあまり必要としない機能をクライアント部に分担し、両者がネットワークを介して協調する形態を説明する。
【００４８】
図９は、本発明の第２の実施の形態におけるシステム構成を示す。
【００４９】
同図に示すシステムは、クライアント側処理制御部１００とサーバ側処理制御部２００がネットワークにより接続されている。但し、この例に限定されることなく、ネットワーク接続をユーザ計算機内のループバックネットワークとして、同計算機内にサーバ部とクライアント部を導入することで、ユーザのローカル環境時に閉じて本実施の形態を適用することも可能である。
【００５０】
クライアント側システム１００は、仮想ファイル処理部１１０、ファイルパス制御部１２０、映像パラメータリスト部１４０、ローカルキャッシュ処理部１５０、クライアント側通信制御部１３０で構成される。
【００５１】
一方のサーバ側処理制御部２００は、サーバ側通信制御部２１０、トランスコード映像処理部２２０、映像蓄積サーバ３００、映像処理器プール２０１、コーデックプール２０２で構成される。
【００５２】
本システムで用いるファイルパスの規定形式を図１０に示す。ファイルパスは、1つ以上のパラメータで構成される。各パラメータは、処理識別するためのパラメータ識別子と、続いてその処理のオプション指定などを表す個別パラメータで構成される。例えば、映像蓄積サーバ３００に蓄積されている"clip0123"という映像ファイルをデコードするという処理を示すパラメータは、"DEC_clip0123"と表すことができ、ここでは"DEC_"がパラメータ識別子、"clip0123"が個別パラメータになる。実際のファイルパスは、例えば、"/DEC_clip0123/ENC_TIFF/ENC_OPT_DEPTH_16/PROC_RESIZE_50P"のように1つ以上のパラメータで構成される。この時、それぞれのパラメータの順序は任意である。
【００５３】
通常のファイルパスは階層構造を持っており、パスの順序によって指定するファイルやオブジェクトが変化する。映像処理をファイルにマッピングするには、映像処理に該当する実行コマンドをファイルパスと１対１に対応させることと等価である。本実施の形態では、処理順序が予め一意に決まり、フィアルパスの階層構造に伴う処理順序は意味を持たない。例えば、本実施の形態での映像処理では、まず、はじめにデコード処理を、続いて指定があれば、中間の映像処理を行い、最後にエンコード処理を行うことになる。そこで、本システムでは、ファイルパスの階層構造を無視し、異なる階層構造の場合においても意味する処理構成が変化しないファイルパスを規定し、これを用いる。
【００５４】
クライアント側処理制御部１００の仮想ファイル処理部１１０は、OSの一部である仮想ファイルシステム１０２からのコールバック呼び出しに対応する処理を行う。基本的に、仮想ファイルシステム１０２からの呼び出しのうち、read命令に関する処理が要求された場合に、そのときに仮想ファイルシステム１０２から受けたファイルパスをファイルパス制御部１２０に送る。
【００５５】
ファイルパス制御部１２０は、仮想ファイル処理部１１０から受けたファイルパスに基づき、映像処理の制御を行う。この時の処理を図１１に示す。
【００５６】
フィルパス制御部１２０は、ファイルパスを分解し(ステップ７０１)、１つ以上のパラメータとして認識する。続いて、パラメータリスト部１４０を参照して(ステップ７０２)、分解したすべてのパラメータが有効であるかを確かめる(ステップ７０３)。一つでも無効のパラメータがあった場合は(ステップ７０３、No)、エラー結果を仮想ファイル処理部１１０に返す(ステップ７０４)。すべてのパラメータが有効であった場合には(ステップ７０３、Yes)、ローカルキャッシュ処理部１５０を参照し、このパラメータに該当する映像処理データがローカルキャッシュにあるかを確認する(ステップ７０５)。もし、ローカルキャッシュに所望の映像処理データがある場合には(ステップ７０５、Yes)、それを仮想ファイル処理部１１０に送る(ステップ７０６)。そうでない場合には、クライアント通信制御部１３０を介してサーバ側処理制御部２００にパラメータに対応するコマンドを送信する(ステップ７０７)。その後、サーバ側処理制御部２００から映像処理データを受信し(ステップ７０８)、ローカルキャッシュ制御部１５０に対して、キャッシュ要求を行う(ステップ７０９)。その後、仮想ファイル処理部１１０に映像データを送信する(ステップ７１０)。
【００５７】
映像処理パラメータリスト部１４０の構成を図１２に示す。
【００５８】
映像処理パラメータリスト部１４０は、本システムで対応可能なコーデックリスト１４１、映像処理リスト１４２、コンテンツリスト１４３を保持し、ファイルパスに含まれるパラメータと実際の処理に用いられるコマンドとの対応関係を解決する。
【００５９】
例えば、コーデックリスト１４１には、図１２に示すように、対応コーデックの種類とその該当するコマンドが記述されている。
【００６０】
エントリ"ENC_MPEG2：encode mpeg2"は"ENC_MPEG2"というパラメータが有効であること、その時のエンコードのコマンドが"encode mpeg2"であることを示している。ここで、本システムで"encode mpeg2"というコマンドによって実行できるものとする。また、エントリ"ENC_MPEG2_OPT_BPS_%f"は"ENC_MPEG2"パラメータのオプションであることを示しており、対応するコマンドオプションが"-bitrate %f"で与えられることを示している。ここで、"%f"は少数表現の数を示している。これより、例えばパラメータが"/ENC_MPEG2/ENC_MPEG2_OPT_BPS_12.34"で与えられている場合、コーデックリスト１４１を参照することにより、対応するコマンドが"encode mpeg2 -bitrate 12.34"であると解決される。
【００６１】
映像処理パラメータリスト部１４０に含まれる映像処理リスト１４２に関しても同様の処理によりファイルパスに含まれるパラメータから映像処理のコマンドを解決することが可能である。また、コンテンツリスト１４３は、映像蓄積サーバ３００にある利用可能な映像コンテンツの一覧である。
【００６２】
コーデックリスト、映像処理リスト、コンテンツリストは、クライアント側処理制御部とサーバ側処理制御部との接続初期化のときに更新される。
【００６３】
ローカルキャッシュ処理部１５０は、ローカルキャッシュ制御部１５１とローカルキャッシュバッファ１５２とから構成される。ローカルキャッシュバッファ１５２は、映像処理データの一時的なキャッシュの保存領域として使われ、ローカルキャッシュ制御部１５１がそのデータ管理を行う。ローカルキャッシュ制御部１５１では、ローカルキャッシュテーブルを用いてローカルキャッシュバッファ１５２の管理を行う。
【００６４】
ローカルキャッシュテーブル１５１１を図１３に示す。ローカルキャッシュテーブル１５１１は、構成フィールドとして、エントリ番号(No)、コマンド、更新時間、キャッシュバッファ上のアドレス、ファイルサイズを持つ。例えば、当該ローカルキャッシュテーブル１５１１に、
"1, decode clip0123; resize 50p; enc tiff -depth 16;, 2011.01.02.19.11, 0x0000001f, 5461200"
というエントリがあった場合、エントリ番号1として、コマンド"decode clip0123; resize 50p; enc tiff -depth 16;"の映像処理データが時刻2011年1月2日19時11分にキャッシュバッファ１５２上のアドレス0x0000001fの位置から5461200バイトの領域にキャッシュされているという情報を管理している。
【００６５】
ローカルキャッシュ制御部１５１の動作を図１４に示す。
【００６６】
はじめに、ファイルパス制御部１２０から参照対象のコマンドを受信する（ステップ８０１）。その後、ローカルキャッシュテーブル１５１１に該当コマンドがあるかを検索する。もしなければ(ステップ８０２、No)、ローカルキャッシュバッファ１５２に該当映像処理データがないことをファイルパス制御部１２０に通知する(ステップ８０３)。もしあれば(ステップ８０２、Yes)、ローカルキャッシュテーブル１５１１を参照し、該当する映像処理データをファイルパス制御部１２０に返す(ステップ８０４)。また、このときローカルキャッシュテーブル１５１１の更新時間を更新する(ステップ８０５)。
【００６７】
クライアント側通信制御部１３０およびサーバ側通信制御部２１０は、ネットワーク接続されたクライアント側制御部１００とサーバ側制御部２００との間のコマンドおよびデータの通信を行う。
【００６８】
図１５にこれら通信制御部の初期化の動作を示す。
【００６９】
まず、クライアント側通信制御部１３０からサーバ側通信制御部２１０に対して接続要求を行い(ステップ９０１)、それに対する応答通知を交換する(ステップ９０２)。その後、映像処理パラメータリスト部１４０に含まれるコーデックリスト１４１、映像処理リスト１４２、および、コンテンツリスト１４３の更新を行う（ステップ９０３〜９０８）。最後に、初期化完了通知を交換し、初期化が終了する（ステップ９０９〜９１１）。初期化後もネットワークのセッションを保持して、サーバ側通信制御部２１０はコマンドを受け付ける状態に入る(Listen状態)。これ以降は、クライアント側通信制御部１３０から送信されるコマンド要求を受け付けることが可能になる。
【００７０】
サーバ側処理制御部２００のトランスコード映像処理部２２０は、デコード処理部２２１、0または1つ以上の映像処理部２２２、エンコード処理部２２３、中間データバッファ２２４、リモートキャッシュ制御部２２５、予測変換処理部２２６から構成される。
【００７１】
図１６にトランスコード映像処理部２２０の動作を示す。
【００７２】
サーバ通信制御部２１０からクライアント側通信制御部１３０から送信されたコマンドを受信し(ステップ１００１)、リモートキャッシュ制御部２２５を参照し、当該コマンドがキャッシュされているかを確認する(ステップ１００２)。キャッシュされている場合には(ステップ１００２、Yes)、該当する映像処理データをサーバ側通信制御部２１０に返す(ステップ１００３)。キャッシュされていない場合には(ステップ１００２、No)、コマンドの映像処理を実行する(ステップ１００４)。この処理は、デコード処理部２２１、映像処理部２２２、エンコード処理部２２３上で行われ、要求された処理コマンドに基づき、それぞれの処理を実行する。処理データは中間データバッファ２２４を介して逐次的に次の処理部に渡される。
【００７３】
その後、最終的な映像処理データおよびその該当コマンドがリモートキャッシュ制御部２２５に通知され、キャッシュ情報の更新を行う(ステップ１００５)。続いて、前ステップで実行したコマンドを予測変換制御部２２６に通知する（ステップ１００６）。最後に、映像処理データをサーバ通信制御部２１０に返す(ステップ１００７)。
【００７４】
リモートキャッシュ制御部２２５は、クライアント側処理制御部１００のローカルキャッシュ制御部１５０と同様に、キャッシュテーブルを保持し、これに基づきリモートキャッシュの管理を行う。ここで用いられるキャッシュテーブルの構造は、図１３に示したローカルキャッシュテーブル１５１１と同様である。
【００７５】
予測変換制御部２２６は、データ参照の局所性を利用し、今後要求されると予想される映像処理を実行しキャッシュする予測変換を行う。予測変換制御部２２６の動作を図１７に示す。
【００７６】
はじめに、上記のステップ１００６の処理により、トランスコード制御部２２０で実行したコマンドの通知を受ける（ステップ１１０１）。このコマンド内の処理対象ファイルに対して、連続するファイルがあるかを判別する。例えば処理対象ファイルが映像フレーム単位である場合、それに続くフレームに該当するファイルがあるか否かを判別する(ステップ１１０２)。連続するファイルがあると判別された場合(ステップ１１０２、Yes)、トランスコード制御部２２０内で実行した映像処理コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成する(ステップ１１０３)。続いて、リモートキャッシュ制御部２２５を参照し、前ステップで生成されたコマンドの映像処理データがキャッシュされているかを確認する(ステップ１１０４)。もし、キャッシュされていない場合(ステップ１１０４、No)、生成されたコマンドを実行する(ステップ１１００５)映像処理の実行が完了した後、リモートキャッシュ制御部２２５にキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う(ステップ１１０６)。予測変換制御部２２６で生成された映像処理データも、通常の映像処理データと同一のキャッシュテーブルで管理されるため、トランスコード制御部２２０では、両者の区別をすることなくキャッシュされている映像処理データの管理が可能である。
【００７７】
サーバ側処理制御部２００に接続される映像蓄積サーバ３００、映像処理器プール２０１、コーデックプール２０２はそれぞれ、処理対象の映像データ、映像処理プログラム、コーデックプログラムが蓄積されている。
【００７８】
本実施の形態では、トランスコードを含めた映像処理をファイルにマッピングすることで、ＯＳの基本機能であるファイルシステムを用いて映像処理手段を提供する。これにより、アプリケーション毎にプラグインソフトウェアを用意する必要がなくなり、統一した形式でユーザ所望の映像形式で映像コンテンツを取り扱うことが可能になる。また、本実施の形態は映像処理に関して、多くの計算機資源を必要とするサーバ部（サーバ側処理制御部）と、計算機資源をあまり必要としないクライアント部[クライアント側処理制御部]に分け、両者をネットワーク接続する構成をとる。これにより、計算機環境が乏しいユーザでも、ネットワークを介して計算機資源が豊富なサーバ部に接続さえすれば、映像処理が可能になる。
【００７９】
また、本実施の形態では、ネットワークの資源を使うことを前提にしているため、複数のユーザが一つのサーバにアクセスすることで本システムの同時利用が可能である。ユーザ側では、ファイルパスの処理とデータのキャッシュ処理のみを行う。これはテキスト処理とデータコピー処理のみで完結するため、ユーザ側での処理負荷は非常に低い。
【００８０】
サーバ部に含まれるキャッシュ(リモートキャッシュ)では、ファイルアクセスの局所性を考慮して、過去に処理した映像データのキャッシュと今後アクセスが予想される映像処理を予測して実行する。これにより、サーバ部の計算機資源を有効に使うことができ、ユーザから要求される映像処理に対して高速に応答することが可能になる。
【００８１】
実際に映像処理の計算処理を行うサーバ部では、複数のユーザからの映像処理が要求されるため、サーバ部にあるリモートキャッシュには多くの処理結果がキャッシュされるため、キャッシュヒットの可能性が高くない。また、キャッシュの要求を毎回受けると処理負荷が高くなる。そこで、本システムでは、ユーザ環境内にもキャッシュ機構(ローカルキャッシュ)を設けることで、各ユーザのキャッシュヒットの高効率性を実現する。
【００８２】
また、本発明は、上記で説明した図１の独自JPEG2000フォーマットプロパティ取得部、マウント処理部、ディレクトリ階層形成部、ファイルデコード部の各機能部の処理、及び、図９に示したクライアント側処理制御部、サーバ側処理制御部の各機能部の処理をプログラムとして構築し、映像情報処理ファイルシステム（装置）として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。
【００８３】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。
【符号の説明】
【００８４】
１０ 汎用ファイルフォーマット
２０ JPEG2000独自フォーマットファイル
３０ 仮想ファイルシステム
４０ FUSE
５０ 独自JPEG2000フォーマットプロパティ取得部
６０ マウント処理部
７０ ディレクトリ階層形成部
８０ ファイルデコード部
１００ クライアント側処理制御部
１０１ ユーザアプリケーション
１０２ 仮想ファイルシステム
１１０ 仮想ファイル処理部
１２０ ファイルパス制御部
１３０ クライアント側通信制御部
１４０ 映像処理パラメータリスト部
１５０ ローカルキャッシュ処理部
１５１ ローカルキャッシュ制御部
１５２ ローカルキャッシュバッファ
２００ サーバ側処理制御部
２０１ 映像処理器プール
２０２ コーデックプール
２１０ サーバ側通信制御部
２２０ トランスコード映像処理部
２２１ デコード処理部
２２２ 映像処理部
２２３ エンコード処理部
２２４ 中間データバッファ
２２５ リモートキャッシュ制御部
２２６ 予測変換処理部
３００ 映像蓄積サーバ
【特許請求の範囲】
【請求項１】
電子計算機上で独自に開発されたフォーマットの画像データをフォーマットファイルで管理する映像情報処理ファイルシステムであって、
前記映像データのディレクトリ階層、ファイル名を含む映像品質パラメータを取得するパラメータ取得手段と、
前記フォーマットファイルから前記映像品質パラメータに対応するファイルを抽出し、該ファイルのバイナリデータフォーマットの変換を行い、要求元に変換結果を返却するファイルデコード手段と、
を有することを特徴とする映像情報ファイルシステム。
【請求項２】
前記ファイルデコード手段は、
前記パラメータ取得手段で取得した前記映像品質パラメータに基づいて、映像圧縮フォーマットファイルを変換する手段を含む
請求項１記載の映像情報ファイルシステム。
【請求項３】
前記映像品質パラメータに基づいて、対応可能なデコード品質を示すディレクトリ構成を生成するディレクトリ階層形成手段を更に有する
請求項１記載の映像情報ファイルシステム。
【請求項４】
前記パラメータ取得手段は、
デコード対象とする対象圧縮ファイルフォーマットから指定可能な映像品質パラメータを取得する手段を含む
請求項１記載の映像情報ファイルシステム。
【請求項５】
電子計算機上で独自に開発されたフォーマットの画像データを仮想ファイルで管理する映像情報処理ファイルシステムであって、
クライアント部とサーバ部とがネットワークを介して接続され、
前記クライアント部は、
映像データをキャッシュするローカルキャッシュバッファを制御するローカルキャッシュ制御手段と、
コーデックリスト、コンテンツリスト、映像処理リストを含む映像処理パラメータリスト記憶手段と、
前記仮想ファイルシステムからファイルパスと、該ファイルパスに対応する映像処理コマンドを取得し、該映像処理コマンドの処理を行う仮想ファイル処理手段と、
前記ファイルパスを分解して１つ以上のパラメータを取得し、該パラメータに基づいて前記映像処理パラメータリスト記憶手段を参照して、該パラメータが有効であるかを判定し、有効であると判断された前記パラメータに対応する映像データが前記ローカルキャッシュバッファにある場合は、前記仮想ファイル処理手段に送り、ない場合は該パラメータに対応するコマンドを前記サーバ部に送信し、該サーバ部から映像処理データを取得して該仮想ファイル処理手段に送るファイルパス制御手段と、
を有し、
前記サーバ部は、
映像データをキャッシュするリモートキャッシュテーブルを制御するリモートキャッシュ制御手段と、
前記クライアント部から前記映像コマンドを受信すると、前記リモートキャッシュテーブルに該映像コマンドに対応する映像データがキャッシュされているか判定し、キャッシュされている場合は該映像データを該クライアント部に送信し、キャッシュされていない場合は、該コマンドに応じた映像処理を行うトランスコード映像処理手段と、
を有することを特徴とする映像情報処理ファイルシステム。
【請求項６】
前記サーバ部の前記トランスコード映像処理手段は、
前記映像コマンドの処理対象ファイルに対して連続するファイルがある場合は、該映像コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成し、生成されたコマンドの映像処理データが前記リモートキャッシュにキャッシュされていない場合は該生成されたコマンドを実行する予測変換処理手段を含む
請求項５記載の映像情報処理ファイルシステム。
【請求項７】
前記予測変換処理手段は、
前記生成されたコマンドを実行した後、前記リモートキャッシュ制御手段に対してキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う手段を含む
請求項６記載の映像情報処理ファイルシステム。
【請求項１】
電子計算機上で独自に開発されたフォーマットの画像データをフォーマットファイルで管理する映像情報処理ファイルシステムであって、
前記映像データのディレクトリ階層、ファイル名を含む映像品質パラメータを取得するパラメータ取得手段と、
前記フォーマットファイルから前記映像品質パラメータに対応するファイルを抽出し、該ファイルのバイナリデータフォーマットの変換を行い、要求元に変換結果を返却するファイルデコード手段と、
を有することを特徴とする映像情報ファイルシステム。
【請求項２】
前記ファイルデコード手段は、
前記パラメータ取得手段で取得した前記映像品質パラメータに基づいて、映像圧縮フォーマットファイルを変換する手段を含む
請求項１記載の映像情報ファイルシステム。
【請求項３】
前記映像品質パラメータに基づいて、対応可能なデコード品質を示すディレクトリ構成を生成するディレクトリ階層形成手段を更に有する
請求項１記載の映像情報ファイルシステム。
【請求項４】
前記パラメータ取得手段は、
デコード対象とする対象圧縮ファイルフォーマットから指定可能な映像品質パラメータを取得する手段を含む
請求項１記載の映像情報ファイルシステム。
【請求項５】
電子計算機上で独自に開発されたフォーマットの画像データを仮想ファイルで管理する映像情報処理ファイルシステムであって、
クライアント部とサーバ部とがネットワークを介して接続され、
前記クライアント部は、
映像データをキャッシュするローカルキャッシュバッファを制御するローカルキャッシュ制御手段と、
コーデックリスト、コンテンツリスト、映像処理リストを含む映像処理パラメータリスト記憶手段と、
前記仮想ファイルシステムからファイルパスと、該ファイルパスに対応する映像処理コマンドを取得し、該映像処理コマンドの処理を行う仮想ファイル処理手段と、
前記ファイルパスを分解して１つ以上のパラメータを取得し、該パラメータに基づいて前記映像処理パラメータリスト記憶手段を参照して、該パラメータが有効であるかを判定し、有効であると判断された前記パラメータに対応する映像データが前記ローカルキャッシュバッファにある場合は、前記仮想ファイル処理手段に送り、ない場合は該パラメータに対応するコマンドを前記サーバ部に送信し、該サーバ部から映像処理データを取得して該仮想ファイル処理手段に送るファイルパス制御手段と、
を有し、
前記サーバ部は、
映像データをキャッシュするリモートキャッシュテーブルを制御するリモートキャッシュ制御手段と、
前記クライアント部から前記映像コマンドを受信すると、前記リモートキャッシュテーブルに該映像コマンドに対応する映像データがキャッシュされているか判定し、キャッシュされている場合は該映像データを該クライアント部に送信し、キャッシュされていない場合は、該コマンドに応じた映像処理を行うトランスコード映像処理手段と、
を有することを特徴とする映像情報処理ファイルシステム。
【請求項６】
前記サーバ部の前記トランスコード映像処理手段は、
前記映像コマンドの処理対象ファイルに対して連続するファイルがある場合は、該映像コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成し、生成されたコマンドの映像処理データが前記リモートキャッシュにキャッシュされていない場合は該生成されたコマンドを実行する予測変換処理手段を含む
請求項５記載の映像情報処理ファイルシステム。
【請求項７】
前記予測変換処理手段は、
前記生成されたコマンドを実行した後、前記リモートキャッシュ制御手段に対してキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う手段を含む
請求項６記載の映像情報処理ファイルシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【公開番号】特開２０１２−１２４８８６（Ｐ２０１２−１２４８８６Ａ）
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願番号】特願２０１１−２１３４６７（Ｐ２０１１−２１３４６７）
【出願日】平成２３年９月２８日（２０１１．９．２８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２４年６月２８日（２０１２．６．２８）
【国際特許分類】
【出願日】平成２３年９月２８日（２０１１．９．２８）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]