電子計算機上で独自に開発されたフォーマットの画像データをフォーマットファイルで管理する映像情報処理ファイルシステムであって、前記映像データのディレクトリ階層、ファイル名を含む映像品質パラメータを取得するパラメータ取得手段と、前記フォーマットファイルから前記映像品質パラメータに対応するファイルを抽出し、該ファイルのバイナリデータフォーマットの変換を行い、要求元に変換結果を返却するファイルデコード手段と、を有することを特徴とする映像情報ファイルシステム。前記ファイルデコード手段は、前記パラメータ取得手段で取得した前記映像品質パラメータに基づいて、映像圧縮フォーマットファイルを変換する手段を含む請求項1記載の映像情報ファイルシステム。前記映像品質パラメータに基づいて、対応可能なデコード品質を示すディレクトリ構成を生成するディレクトリ階層形成手段を更に有する請求項1記載の映像情報ファイルシステム。前記パラメータ取得手段は、デコード対象とする対象圧縮ファイルフォーマットから指定可能な映像品質パラメータを取得する手段を含む請求項1記載の映像情報ファイルシステム。電子計算機上で独自に開発されたフォーマットの画像データを仮想ファイルで管理する映像情報処理ファイルシステムであって、クライアント部とサーバ部とがネットワークを介して接続され、前記クライアント部は、映像データをキャッシュするローカルキャッシュバッファを制御するローカルキャッシュ制御手段と、コーデックリスト、コンテンツリスト、映像処理リストを含む映像処理パラメータリスト記憶手段と、前記仮想ファイルシステムからファイルパスと、該ファイルパスに対応する映像処理コマンドを取得し、該映像処理コマンドの処理を行う仮想ファイル処理手段と、前記ファイルパスを分解して1つ以上のパラメータを取得し、該パラメータに基づいて前記映像処理パラメータリスト記憶手段を参照して、該パラメータが有効であるかを判定し、有効であると判断された前記パラメータに対応する映像データが前記ローカルキャッシュバッファにある場合は、前記仮想ファイル処理手段に送り、ない場合は該パラメータに対応するコマンドを前記サーバ部に送信し、該サーバ部から映像処理データを取得して該仮想ファイル処理手段に送るファイルパス制御手段と、を有し、前記サーバ部は、映像データをキャッシュするリモートキャッシュテーブルを制御するリモートキャッシュ制御手段と、前記クライアント部から前記映像コマンドを受信すると、前記リモートキャッシュテーブルに該映像コマンドに対応する映像データがキャッシュされているか判定し、キャッシュされている場合は該映像データを該クライアント部に送信し、キャッシュされていない場合は、該コマンドに応じた映像処理を行うトランスコード映像処理手段と、を有することを特徴とする映像情報処理ファイルシステム。前記サーバ部の前記トランスコード映像処理手段は、前記映像コマンドの処理対象ファイルに対して連続するファイルがある場合は、該映像コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成し、生成されたコマンドの映像処理データが前記リモートキャッシュにキャッシュされていない場合は該生成されたコマンドを実行する予測変換処理手段を含む請求項5記載の映像情報処理ファイルシステム。前記予測変換処理手段は、前記生成されたコマンドを実行した後、前記リモートキャッシュ制御手段に対してキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う手段を含む請求項6記載の映像情報処理ファイルシステム。しかしながら、上記特許文献1の技術は、ファイル属性と仮想ファイルシステム上のディレクトリ構成を対応付けるものであり、ファイルの操作制限に主眼を置いている。そのため、ユーザの望む品質で映像ファイルを取得することはできないという問題がある。また、映像コンテンツのトランスコードや編集処理を行う場合、一般的に膨大な計算リソースが必要になる。映像を扱うユーザ全てがこうした環境を構築するのは現状では不可能である。また、処理した映像データを複数のユーザで利用する場合、映像データ形式や機器環境が異なる等の理由により、ユーザ間での映像データの共有ができないことがある。さらに、映像データ形式だけでなく、解像度や色深度などの映像プロパティの要件などもユーザ毎に異なる。従来のシステムでは、同じ映像コンテンツに対してあらゆる形式、プロパティのデータを用意して対応している。しかし、新しい形式やプロパティが追加されるたびに対応するデータを用意する必要があるが、そのファイル数が膨大になってしまうため現実的ではない。また、ユーザが映像編集ソフトなどのアプリケーションから非対応映像データを扱う場合には、プラグインソフトウェアを利用してデータの入出力を行う。しかし、プラグインソフトウェアはアプリケーション毎に異なる仕様であるため、複数のアプリケーションで利用する場合には、それぞれのプラグインソフトウェアを用意する必要がある。本発明は、上記の点に鑑みなされたもので、自社等で独自に開発した独自フォーマットファイルを利用する場合に、ユーザ及びアプリケーションソフトが要求するファイルフォーマットで容易に取り込みが可能で、また、独自フォーマットファイルである映像圧縮ファイルを編集する場合に、使用するユーザの要求するファイル形式、映像品質で編集対象ファイルへのアクセス手段を提供することが可能な映像情報処理ファイルシステムを実現することを目的とする。また、更に、多様なフォーマットや形式の映像データをユーザが、その作業環境に関係なく扱うことが可能な映像情報処理ファイルシステムを実現することを目的とする。上記の課題を解決するために、本発明請求項1は、電子計算機上で独自に開発されたフォーマットの画像データをフォーマットファイルで管理する映像情報処理ファイルシステムであって、前記映像データのディレクトリ階層、ファイル名を含む映像品質パラメータを取得するパラメータ取得手段と、前記フォーマットファイルから前記映像品質パラメータに対応するファイルを抽出し、該ファイルのバイナリデータフォーマットの変換を行い、要求元に変換結果を返却するファイルデコード手段と、を有する。また、本発明請求項2は、前記ファイルデコード手段に、前記パラメータ取得手段で取得した前記映像品質パラメータに基づいて、映像圧縮フォーマットファイルを変換する手段を含む。また、本発明請求項3は、前記映像品質パラメータに基づいて、対応可能なデコード品質を示すディレクトリ構成を生成するディレクトリ階層形成手段を更に有する。また、本発明請求項4は、前記パラメータ取得手段において、デコード対象とする対象圧縮ファイルフォーマットから指定可能な映像品質パラメータを取得する手段を含む。本発明請求項5は、電子計算機上で独自に開発されたフォーマットの画像データを仮想ファイルで管理する映像情報処理ファイルシステムであって、クライアント部とサーバ部とがネットワークを介して接続され、前記クライアント部は、映像データをキャッシュするローカルキャッシュバッファを制御するローカルキャッシュ制御手段と、コーデックリスト、コンテンツリスト、映像処理リストを含む映像処理パラメータリスト記憶手段と、前記仮想ファイルシステムからファイルパスと、該ファイルパスに対応する映像処理コマンドを取得し、該映像処理コマンドの処理を行う仮想ファイル処理手段と、前記ファイルパスを分解して1つ以上のパラメータを取得し、該パラメータに基づいて前記映像処理パラメータリスト記憶手段を参照して、該パラメータが有効であるかを判定し、有効であると判断された前記パラメータに対応する映像データが前記ローカルキャッシュバッファにある場合は、前記仮想ファイル処理手段に送り、ない場合は該パラメータに対応するコマンドを前記サーバ部に送信し、該サーバ部から映像処理データを取得して該仮想ファイル処理手段に送るファイルパス制御手段と、を有し、前記サーバ部は、映像データをキャッシュするリモートキャッシュテーブルを制御するリモートキャッシュ制御手段と、前記クライアント部から前記映像コマンドを受信すると、前記リモートキャッシュテーブルに該映像コマンドに対応する映像データがキャッシュされているか判定し、キャッシュされている場合は該映像データを該クライアント部に送信し、キャッシュされていない場合は、該映像コマンドに応じた映像処理を行うトランスコード映像処理手段と、を有する。また、本発明請求項6は、前記サーバ部の前記トランスコード映像処理手段において、前記映像コマンドの処理対象ファイルに対して連続するファイルがある場合は、該映像コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成し、生成されたコマンドの映像処理データが前記リモートキャッシュにキャッシュされていない場合は該生成されたコマンドを実行する予測変換処理手段を含む。また、本発明請求項7は、前記予測変換処理手段において、前記生成されたコマンドを実行した後、前記リモートキャッシュ制御手段に対してキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う手段を含む。上記のように、本発明は、映像圧縮されたファイルをはじめとした、独自フォーマットのファイルを操作する際に、従来のファイル変換過程を経ずに、ユーザやアプリケーションソフトがファイルフォーマットを意識せずにファイルデータを利用すること、また、使用目的に最適なファイルフォーマットをディレクトリ構造とファイル名により、統一したインタフェースにより即時に利用することが可能となる。また、独自フォーマットファイルの仕様を公開することなく、一般ユーザやアプリケーションソフトアが当該ファイルフォーマットのデータを利用することが可能となる。さらに、映像を取り扱う場合に、対象映像形式やサイズなどをユーザが要求する形式で提供することが可能になる。また、ネットワーク上の計算機資源を用いることができるため、ユーザの作業環境の機器性能に関係なく映像処理を行うことが可能になる。以下図面と共に、本発明の実施の形態を説明する。[第1の実施の形態]本実施の形態では、OSのユーザ空間で処理を定義できるFUSEを用いたシステムの実装について、以下に説明する。図1は、本発明の第1の実施の形態におけるFUSEを用いた映像情報処理ファイルシステムの構成例を示す。同図に示すシステムは、JPEG2000ファイルフォーマットプロパティ取得部50、マウント処理部60、ディレクトリ階層形成部70、ファイルデコード部80によって構成される、これらの機能部をOSの基本機能として提供される仮想ファイルシステム30とユーザ空間でファイル操作定義を可能にするFUSE40を用いて制御することで、JPEG2000をベースにした独自フォーマットファイル以後、JPEG2000独自フォーマットを利用ユーザが意識することなく汎用ファイルフォーマットとして利用可能にするものである。独自JPEG2000フォーマットプロパティ取得部50は、JPEG2000フォーマットファイルを利用するユーザから指定されたディレクトリ階層、ファイル名ファイルパスに基づいてファイルの解像度、レイヤ数などのプロパティ情報を取得する。マウント処理部60は、JPEG2000独自フォーマットの製作者であるユーザから指定されたJPEG2000独自フォーマットファイルをマウントポイントに登録する。ここで、マウントポイントとは、当該ユーザが当該システムにアクセスするための最初の最上位のディレクトリ位置を指す。ディレクトリ階層形成部70は、プロパティ情報ファイルの解像度、レイヤ数等に基づいて、対応可能なデコード品質を示すディレクトリ構造を形成する。ファイルデコード部80は、独自JPEG2000フォーマットプロパティ取得部50で取得したプロパティ情報に基づいて、JPEG2000独自フォーマットファイルから該当ファイルバイナリデータフォーマットを抽出しデコードバイナリフォーマットに変換する。一般に、JPEG2000圧縮形式は、解像度、SNRスケーラビリティを持ち合わせており、圧縮データから該当する箇所のみをデコードすることで、目的の解像度、品質が得られる特徴をもつ。本システムで用いられるJPEG2000独自フォーマットファイル20においても、以上の性質を継承している。例えば、3840画素×1260画素の解像度を持ち、レイヤ数が3であるJPEG2000独自フォーマットファイルの場合、対応可能な解像度は3480画素2160画素、1920×1080画素である。また、対応可能なデコードレイヤ数は、L1のみ、L1とL2、L1からL3まですべてとなる。図2は、本発明の第1の実施の形態における仮想ファイルディレクトリ構造を示したものである。本システムでマウントされたJPEG2000独自フォーマットファイルは、図2のようなディレクトリ階層を用いてユーザからアクセス可能である。ディレクトリの各階層は、最上位にはマウントルートのディレクトリ、第2階層にはデコード可能な解像度、第3階層にはデコード可能なレイヤ数、第4階層にはデコード可能なファイル形式、第5階層にはデコード可能なビット深度、第6階層にはフレーム数をファイル名に持つデコードファイルでそれぞれ構成される。図3は、本発明の第1の実施の形態におけるユーザによるディレクトリ操作を示す図であり、製作側のユーザが本システムを用いてJPEG2000独自フォーマットファイルをマウントし、ディレクトリを移動する操作を示している。まず、JPEG200独自フォーマットの製作者は、初めに、mntj2kコマンドを用いてMOVIE1というファイル名を持つJPEG2000独自フォーマットファイルをMOUNTPOINTにマウントする。mntj2kコマンドは本システムをFUSE40を用いて実装した場合の実行ファイル名である。このときFUSE40を通して、本システムのマウント処理部60が呼び出されマウントが完了するステップ101。続いて、MOUNTPOINTディレクトリを指定しステップ102、lsコマンドを用いて、FUSE40にファイル一覧の取得を指示するステップ103。このとき、FUSE40を通してディレクトリ階層形成部70が呼び出され、ディレクトリを構成するファイル名から対応可能な解像度として、例えば、3840及び1920を返すステップ104。これを各階層繰り返すことで、ファイルパスを用いてユーザの求める品質のデコードデータを指定することができるステップ105~ステップ116。図4は、本発明の第1の実施の形態におけるユーザによるデコードデータ取得操作を示す図であり、ユーザが本システムを用いてJPEG2000独自フォーマットファイルにアクセスしデコードデータを取得する操作を示している。ユーザがMOUNTPOINTディレクトリを指定しステップ201、ファイルパス3840L3TIFF1600000tifコマンドによりFUSE40を介して、JPEG2000独自フォーマットファイルに対して、解像度3840画素×1920画素、レイヤ数3、TIFF静止画形式、16ビット深度、00000番目のデータを取得しているステップ202、203。このとき、FUSE40を通してファイルデコード部80が呼び出され、デコードデータがユーザに返される。図5は、本発明の第1の実施の形態におけるマウント処理部の動作のフローチャートである。はじめに、独自JPEG2000フォーマットプロパティ取得部50において、FUSE40からファイルの解像度、レイヤ数などのプロパティ情報を取得するステップ301。続いて、マウント処理部60は、ステップ301で取得したプロパティ情報に基づいて、対応可能なデコード品質を示すディレクトリ構造を形成するディレクトリ階層形成部70をFUSE40のreaddirコールバック関数に登録する。また、FUSE40のreadコールバックにファイルデコーダ部80を登録するステップ303。図6は、本発明の第1の実施の形態における独自JPEG2000フォーマットプロパティ情報取得部のフローチャートである。JPEG2000フォーマットプロパティ情報取得部50は、はじめに、ユーザから指定された対象ファイルが本システムで対応可能なフォーマットであるかを判別するステップ401。本発明のシステムで用いるJPEG2000ファイルには、ファイルバイナリの先頭に事前に定義されたヘッダ識別0xFFFFFFF0が配置されており、この識別子の有無で対応可能か否かの判別を行う。対応可能である場合にはステップ401、Yes、当該ファイルに含まれる映像フレーム数、フレームレート、圧縮色空間、解像度、分割タイル数、JPEG2000圧縮レイヤ数、JPEG2000圧縮ウェーブレットレベル数を取得するステップ402~408。これらの情報を基にして、本システムのディレクトリ構成、デコード品質指定を行う。図7は、本発明の第1の実施の形態におけるディレクトリ階層形成部の動作のフローチャートである。ディレクトリ階層形成部70は、はじめに、現在のファイルパス階層からどの品質を示すディレクトリ階層にいるのかを取得するステップ501。現在のディレクトリが第1階層、すなわち本システムのマウントルートである場合にはステップ502、Yes、対応可能な解像度の一覧をディレクトリ名としてFUSE40に返すステップ503。現在のディレクトリが第2階層、すなわち解像度を示す階層である場合にはステップ504、Yes、対応可能なレイヤ数の一覧をディレクトリ名として返すステップ505。現在のディレクトリが第3階層、すなわちレイヤ数階層である場合にはステップ506、Yes、対応可能なデコードファイル形式の一覧をディレクトリ名として返すステップ507。現在のディレクトリが第4階層、すなわちデコードファイル形式階層である場合にはステップ508、Yes、対応可能なビット深度の一覧をディレクトリ名として返すステップ509。現在のディレクトリが第5階層、すなわちビット深度階層である場合にはステップ510、Yes、映像フレームの番号列をファイル名として返すステップ511。以上により、ディレクトリ階層的にデコードする映像品質、形式が一意的に表現される。図8は、本発明の第1の実施の形態におけるファイルデコード部の動作のフローチャートである。ファイルデコード部80は、ユーザから与えられたファイルパスからデコードの解像度、レイヤ数、デコードファイル形式、ビット深度、フレーム番号を、デコードのためのデコード品質パラメータとして取得するステップ601~605。続いて、これらのデコード品質パラメータでデコード可能であるかを判別するステップ606。デコード可能であるかを判断するのは、ディレクトリ階層を辿り、目的のファイルにアクセスする場合には、デコード不可能なパラメータを含むファイルパスになることはないが、ファイルシステムに直接ファイルパスを指定することも可能であり、この場合に、デコード不可能なパラメータを含むファイルパスを渡すことも考えられるためである。デコード可能であると判別されるとステップ606、Yes、JPEG2000独自フォーマットファイルから該当ファイルを抜き出し、デコード品質パラメータに基づいてデコードしステップ607、デコード結果を要求元のユーザに返すステップ608。第2の実施の形態前述の第1の実施の形態では、各ユーザ端末に高い性能やデータ保持を必要とするため、利用できるユーザが限定されるが、本実施の形態では、映像情報処理ファイルシステムの機能のうち、多くの計算機資源を必要とする機能をサーバ部に、計算機資源をあまり必要としない機能をクライアント部に分担し、両者がネットワークを介して協調する形態を説明する。図9は、本発明の第2の実施の形態におけるシステム構成を示す。同図に示すシステムは、クライアント側処理制御部100とサーバ側処理制御部200がネットワークにより接続されている。但し、この例に限定されることなく、ネットワーク接続をユーザ計算機内のループバックネットワークとして、同計算機内にサーバ部とクライアント部を導入することで、ユーザのローカル環境時に閉じて本実施の形態を適用することも可能である。クライアント側システム100は、仮想ファイル処理部110、ファイルパス制御部120、映像パラメータリスト部140、ローカルキャッシュ処理部150、クライアント側通信制御部130で構成される。一方のサーバ側処理制御部200は、サーバ側通信制御部210、トランスコード映像処理部220、映像蓄積サーバ300、映像処理器プール201、コーデックプール202で構成される。本システムで用いるファイルパスの規定形式を図10に示す。ファイルパスは、1つ以上のパラメータで構成される。各パラメータは、処理識別するためのパラメータ識別子と、続いてその処理のオプション指定などを表す個別パラメータで構成される。例えば、映像蓄積サーバ300に蓄積されているclip0123という映像ファイルをデコードするという処理を示すパラメータは、DECclip0123と表すことができ、ここではDECがパラメータ識別子、clip0123が個別パラメータになる。実際のファイルパスは、例えば、DECclip0123ENCTIFFENCOPTDEPTH16PROCRESIZE50Pのように1つ以上のパラメータで構成される。この時、それぞれのパラメータの順序は任意である。通常のファイルパスは階層構造を持っており、パスの順序によって指定するファイルやオブジェクトが変化する。映像処理をファイルにマッピングするには、映像処理に該当する実行コマンドをファイルパスと1対1に対応させることと等価である。本実施の形態では、処理順序が予め一意に決まり、フィアルパスの階層構造に伴う処理順序は意味を持たない。例えば、本実施の形態での映像処理では、まず、はじめにデコード処理を、続いて指定があれば、中間の映像処理を行い、最後にエンコード処理を行うことになる。そこで、本システムでは、ファイルパスの階層構造を無視し、異なる階層構造の場合においても意味する処理構成が変化しないファイルパスを規定し、これを用いる。クライアント側処理制御部100の仮想ファイル処理部110は、OSの一部である仮想ファイルシステム102からのコールバック呼び出しに対応する処理を行う。基本的に、仮想ファイルシステム102からの呼び出しのうち、read命令に関する処理が要求された場合に、そのときに仮想ファイルシステム102から受けたファイルパスをファイルパス制御部120に送る。ファイルパス制御部120は、仮想ファイル処理部110から受けたファイルパスに基づき、映像処理の制御を行う。この時の処理を図11に示す。フィルパス制御部120は、ファイルパスを分解し、1つ以上のパラメータとして認識する。続いて、パラメータリスト部140を参照して、分解したすべてのパラメータが有効であるかを確かめる。一つでも無効のパラメータがあった場合は、エラー結果を仮想ファイル処理部110に返す。すべてのパラメータが有効であった場合には、ローカルキャッシュ処理部150を参照し、このパラメータに該当する映像処理データがローカルキャッシュにあるかを確認する。もし、ローカルキャッシュに所望の映像処理データがある場合には、それを仮想ファイル処理部110に送る。そうでない場合には、クライアント通信制御部130を介してサーバ側処理制御部200にパラメータに対応するコマンドを送信する。その後、サーバ側処理制御部200から映像処理データを受信し、ローカルキャッシュ制御部150に対して、キャッシュ要求を行う。その後、仮想ファイル処理部110に映像データを送信する。映像処理パラメータリスト部140の構成を図12に示す。映像処理パラメータリスト部140は、本システムで対応可能なコーデックリスト141、映像処理リスト142、コンテンツリスト143を保持し、ファイルパスに含まれるパラメータと実際の処理に用いられるコマンドとの対応関係を解決する。例えば、コーデックリスト141には、図12に示すように、対応コーデックの種類とその該当するコマンドが記述されている。エントリENCMPEG2:encodempeg2はENCMPEG2というパラメータが有効であること、その時のエンコードのコマンドがencodempeg2であることを示している。ここで、本システムでencodempeg2というコマンドによって実行できるものとする。また、エントリENCMPEG2OPTBPSfはENCMPEG2パラメータのオプションであることを示しており、対応するコマンドオプションがbitratefで与えられることを示している。ここで、fは少数表現の数を示している。これより、例えばパラメータがENCMPEG2ENCMPEG2OPTBPS1234で与えられている場合、コーデックリスト141を参照することにより、対応するコマンドがencodempeg2bitrate1234であると解決される。映像処理パラメータリスト部140に含まれる映像処理リスト142に関しても同様の処理によりファイルパスに含まれるパラメータから映像処理のコマンドを解決することが可能である。また、コンテンツリスト143は、映像蓄積サーバ300にある利用可能な映像コンテンツの一覧である。コーデックリスト、映像処理リスト、コンテンツリストは、クライアント側処理制御部とサーバ側処理制御部との接続初期化のときに更新される。ローカルキャッシュ処理部150は、ローカルキャッシュ制御部151とローカルキャッシュバッファ152とから構成される。ローカルキャッシュバッファ152は、映像処理データの一時的なキャッシュの保存領域として使われ、ローカルキャッシュ制御部151がそのデータ管理を行う。ローカルキャッシュ制御部151では、ローカルキャッシュテーブルを用いてローカルキャッシュバッファ152の管理を行う。ローカルキャッシュテーブル1511を図13に示す。ローカルキャッシュテーブル1511は、構成フィールドとして、エントリ番号、コマンド、更新時間、キャッシュバッファ上のアドレス、ファイルサイズを持つ。例えば、当該ローカルキャッシュテーブル1511に、1decodeclip0123resize50penctiffdepth162011010219110x0000001f5461200というエントリがあった場合、エントリ番号1として、コマンドdecodeclip0123resize50penctiffdepth16の映像処理データが時刻2011年1月2日19時11分にキャッシュバッファ152上のアドレス0x0000001fの位置から5461200バイトの領域にキャッシュされているという情報を管理している。ローカルキャッシュ制御部151の動作を図14に示す。はじめに、ファイルパス制御部120から参照対象のコマンドを受信するステップ801。その後、ローカルキャッシュテーブル1511に該当コマンドがあるかを検索する。もしなければ、ローカルキャッシュバッファ152に該当映像処理データがないことをファイルパス制御部120に通知する。もしあれば、ローカルキャッシュテーブル1511を参照し、該当する映像処理データをファイルパス制御部120に返す。また、このときローカルキャッシュテーブル1511の更新時間を更新する。クライアント側通信制御部130およびサーバ側通信制御部210は、ネットワーク接続されたクライアント側制御部100とサーバ側制御部200との間のコマンドおよびデータの通信を行う。図15にこれら通信制御部の初期化の動作を示す。まず、クライアント側通信制御部130からサーバ側通信制御部210に対して接続要求を行い、それに対する応答通知を交換する。その後、映像処理パラメータリスト部140に含まれるコーデックリスト141、映像処理リスト142、および、コンテンツリスト143の更新を行うステップ903~908。最後に、初期化完了通知を交換し、初期化が終了するステップ909~911。初期化後もネットワークのセッションを保持して、サーバ側通信制御部210はコマンドを受け付ける状態に入る。これ以降は、クライアント側通信制御部130から送信されるコマンド要求を受け付けることが可能になる。サーバ側処理制御部200のトランスコード映像処理部220は、デコード処理部221、0または1つ以上の映像処理部222、エンコード処理部223、中間データバッファ224、リモートキャッシュ制御部225、予測変換処理部226から構成される。図16にトランスコード映像処理部220の動作を示す。サーバ通信制御部210からクライアント側通信制御部130から送信されたコマンドを受信し、リモートキャッシュ制御部225を参照し、当該コマンドがキャッシュされているかを確認する。キャッシュされている場合には、該当する映像処理データをサーバ側通信制御部210に返す。キャッシュされていない場合には、コマンドの映像処理を実行する。この処理は、デコード処理部221、映像処理部222、エンコード処理部223上で行われ、要求された処理コマンドに基づき、それぞれの処理を実行する。処理データは中間データバッファ224を介して逐次的に次の処理部に渡される。その後、最終的な映像処理データおよびその該当コマンドがリモートキャッシュ制御部225に通知され、キャッシュ情報の更新を行う。続いて、前ステップで実行したコマンドを予測変換制御部226に通知するステップ1006。最後に、映像処理データをサーバ通信制御部210に返す。リモートキャッシュ制御部225は、クライアント側処理制御部100のローカルキャッシュ制御部150と同様に、キャッシュテーブルを保持し、これに基づきリモートキャッシュの管理を行う。ここで用いられるキャッシュテーブルの構造は、図13に示したローカルキャッシュテーブル1511と同様である。予測変換制御部226は、データ参照の局所性を利用し、今後要求されると予想される映像処理を実行しキャッシュする予測変換を行う。予測変換制御部226の動作を図17に示す。はじめに、上記のステップ1006の処理により、トランスコード制御部220で実行したコマンドの通知を受けるステップ1101。このコマンド内の処理対象ファイルに対して、連続するファイルがあるかを判別する。例えば処理対象ファイルが映像フレーム単位である場合、それに続くフレームに該当するファイルがあるか否かを判別する。連続するファイルがあると判別された場合、トランスコード制御部220内で実行した映像処理コマンドと同等の処理を連続するファイルに対して実行するためのコマンドを生成する。続いて、リモートキャッシュ制御部225を参照し、前ステップで生成されたコマンドの映像処理データがキャッシュされているかを確認する。もし、キャッシュされていない場合、生成されたコマンドを実行する映像処理の実行が完了した後、リモートキャッシュ制御部225にキャッシュ要求を行い、リモートキャッシュテーブルの更新を行う。予測変換制御部226で生成された映像処理データも、通常の映像処理データと同一のキャッシュテーブルで管理されるため、トランスコード制御部220では、両者の区別をすることなくキャッシュされている映像処理データの管理が可能である。サーバ側処理制御部200に接続される映像蓄積サーバ300、映像処理器プール201、コーデックプール202はそれぞれ、処理対象の映像データ、映像処理プログラム、コーデックプログラムが蓄積されている。本実施の形態では、トランスコードを含めた映像処理をファイルにマッピングすることで、OSの基本機能であるファイルシステムを用いて映像処理手段を提供する。これにより、アプリケーション毎にプラグインソフトウェアを用意する必要がなくなり、統一した形式でユーザ所望の映像形式で映像コンテンツを取り扱うことが可能になる。また、本実施の形態は映像処理に関して、多くの計算機資源を必要とするサーバ部サーバ側処理制御部と、計算機資源をあまり必要としないクライアント部クライアント側処理制御部に分け、両者をネットワーク接続する構成をとる。これにより、計算機環境が乏しいユーザでも、ネットワークを介して計算機資源が豊富なサーバ部に接続さえすれば、映像処理が可能になる。また、本実施の形態では、ネットワークの資源を使うことを前提にしているため、複数のユーザが一つのサーバにアクセスすることで本システムの同時利用が可能である。ユーザ側では、ファイルパスの処理とデータのキャッシュ処理のみを行う。これはテキスト処理とデータコピー処理のみで完結するため、ユーザ側での処理負荷は非常に低い。サーバ部に含まれるキャッシュでは、ファイルアクセスの局所性を考慮して、過去に処理した映像データのキャッシュと今後アクセスが予想される映像処理を予測して実行する。これにより、サーバ部の計算機資源を有効に使うことができ、ユーザから要求される映像処理に対して高速に応答することが可能になる。実際に映像処理の計算処理を行うサーバ部では、複数のユーザからの映像処理が要求されるため、サーバ部にあるリモートキャッシュには多くの処理結果がキャッシュされるため、キャッシュヒットの可能性が高くない。また、キャッシュの要求を毎回受けると処理負荷が高くなる。そこで、本システムでは、ユーザ環境内にもキャッシュ機構を設けることで、各ユーザのキャッシュヒットの高効率性を実現する。また、本発明は、上記で説明した図1の独自JPEG2000フォーマットプロパティ取得部、マウント処理部、ディレクトリ階層形成部、ファイルデコード部の各機能部の処理、及び、図9に示したクライアント側処理制御部、サーバ側処理制御部の各機能部の処理をプログラムとして構築し、映像情報処理ファイルシステム装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において種々変更応用が可能である。