JP2013123194A - ファイル処理装置、及びファイル受信方法 - Google Patents

Abstract

【課題】完全な状態のＭＸＦファイルの取得が可能となる。
【解決手段】実施形態のファイル処理装置は、受信手段と、判定手段と、送信手段と、を備える。受信手段は、ファイルを配信する配信装置から、ＭＸＦ（Material eXchange Format）で定義されているＭＸＦファイルを受信する。判定手段は、受信したＭＸＦファイルに、ＭＸＦで定義されているフッタまで含まれているか否かを判定する。送信手段は、判定手段によりフッタが含まれていないと判定された場合、配信装置に対して、ＭＸＦファイルの再送要求を送信する。
【選択図】図２

Description

本発明の実施形態は、ファイル処理装置、及びファイル受信方法に関する。

地上デジタル放送の進展、通信・放送の融合が進展する中、益々放送分野におけるデジタル化が進んでいる。

従来、物理的なパッケージメディアに記録されていた番組素材は、テープの標準規格が厳密に決められていたために、物理的に相互互換性が明確に保証されていた。しかしながら、番組素材がファイルとして装置に取り込まれると、フォーマットは論理的な意味付けとして捉えられ、物理フォーマットとは独立になる。こうした背景から、多種多様のフォーマットが他のフォーマットと互換性を持たずに混在している。

このような互換性の混在による煩雑さを解消するために、放送業界の統一ファイル交換フォーマットを目指してＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）によってＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）規格が制定された。ＭＸＦは、コード化された様々な映像データや音声データをメタデータとともに梱包するための「容器」あるいは「包装紙」のようなものである。このＭＸＦ規格を用いることで、ネットワークを介した番組素材データのファイル交換を容易に行うことが可能となった。

そして、ＭＸＦ規格でファイル交換等を行っている場合であっても問題が生じることがある。例えば、ＭＸＦファイルの送受信を行う際に、送信元で当該ＭＸＦファイルに格納されている動画像データの書き込み中の場合に、ＭＸＦファイルが完全な状態で転送されないという問題が生じることもある。そこで、ＭＸＦファイル転送時に生じる問題を解消するために、様々な技術が提案されている。

特開２０１１−９０７３３号公報

しかしながら、従来技術では、ファイル交換等で不完全になったＭＸＦファイルを修復する技術が提案されているが、ＭＸＦファイルに格納されていたデータが完全であるか否かは考慮されていない。

実施形態のファイル処理装置は、受信手段と、判定手段と、送信手段と、を備える。受信手段は、ファイルを配信する配信装置から、ＭＸＦ（Material eXchange Format）で定義されているＭＸＦファイルを受信する。判定手段は、受信したＭＸＦファイルに、ＭＸＦで定義されているフッタまで含まれているか否かを判定する。送信手段は、判定手段によりフッタが含まれていないと判定された場合、配信装置に対して、ＭＸＦファイルの再送要求を送信する。

図１は、実施形態にかかる映像処理システムのネットワーク構成を示した図である。 図２は、実施形態にかかる映像収録再生装置の全体構成を示したブロック図である。 図３は、ＭＸＦファイルのデータ構造を示した図である。 図４は、ＭＸＦファイルのヘッダ部の“Header Partition Pack”の一部の構造を示した図である。 図５は、実施の形態にかかる映像収録再生装置における、ＭＸＦファイルの処理の手順を示すフローチャートである。

図１は、本実施形態にかかる映像処理システムのネットワーク構成を示した図である。図１に示すように、映像処理システムは、ビデオカメラ１６１と、再生デッキ１６２と、ノンリニア編集機１６３と、ファイルサーバ１５０と、映像収録再生装置１００と、映像確認用モニタ１２０と、放送設備１６０と、を備えている。

ビデオカメラ１６１は、撮像した映像信号をエンコードした後に出力し、ファイルサーバ１５０に書き込まれる。同様に、再生デッキ１６２は、映像信号をエンコードした後に出力し、ファイルサーバ１５０に書き込まれる。そして、当該映像信号をエンコードして、ファイルサーバ１５０に書き込まれるまでに要する時間は、当該映像信号の再生時間とほぼ同等となる。また、ノンリニア編集機１６３がノンリニアで編集したＭＸＦ（Ｍａｔｅｒｉａｌ ｅＸｃｈａｎｇｅ Ｆｏｒｍａｔ）ファイルを、ファイルサーバ１５０に書き出す場合も、映像信号の再生時間とほぼ同等の時間を要する可能性がある。

ファイルサーバ１５０は、入力処理された映像信号をＭＸＦファイルとした後、ＭＸＦファイル記憶部に格納して、ＭＸＦファイルを管理する。そして、ファイルサーバ１５０は、他の機器からの送信要求に応じて、当該ＭＸＦファイルを提供する。

ファイルサーバ１５０と、映像収録再生装置１００と、の間は、ＬＡＮで接続されている。

本実施形態では、ファイルサーバ１５０が、他の機器（例えば映像収録再生装置１００）にＭＸＦファイルを転送する方式として、ＦＴＰ（File Transfer Protocol）を用いる。例えば、ファイルサーバ１５０がＦＴＰサーバとなり、映像収録再生装置１００がＦＴＰクライアントとなる。

本実施形態にかかるファイルサーバ１５０が管理するＭＸＦファイルには、放送局で使用する番組、ＣＭなどの素材となる映像データが格納されている。

そして、映像収録再生装置１００が、ファイルサーバ１５０に、ＭＸＦファイルの転送を要求する場合、ＭＸＦファイル名を指定した上でＲＥＴＲコマンドをファイルサーバ１５０に送信し、ＭＸＦファイルの転送を要求する。これにより、ファイルサーバ１５０は、映像収録再生装置１００にＭＸＦファイルを転送する。

このように、ＦＴＰは一般的に利用されているプロトコルのため、ファイルサーバ１５０と他の機器との接続が容易となる。なお、本実施形態はＦＴＰに制限するものではないため、他のプロトコルを用いても良い。

映像収録再生装置１００は、ファイルサーバ１５０から転送されてきたＭＸＦファイルを記憶装置に蓄積する。そして、映像収録再生装置１００は、蓄積しているＭＸＦファイルを再生し、映像確認用モニタ１２０や放送設備１６０に対して映像信号として出力する。

映像確認用モニタ１２０は、映像収録再生装置１００で再生されている映像信号を確認するためのモニタとする。放送設備１６０は、放送局内から放送アンテナに対して映像信号を提供するための設備とする。

本実施形態にかかる映像処理システムにおいては、映像収録再生装置１００からの送信要求に応じて、ファイルサーバ１５０が、ＦＴＰを用いて映像収録再生装置１００にＭＸＦファイルを転送する。この転送対象となったＭＸＦファイル又は当該ＭＸＦファイルの元となる映像信号が、例えば他のファイルサーバから転送中、ビデオカメラ１６１又は再生デッキ１６２からエンコード収録中、又はノンリニア編集機１６３からノンリニアエディタなどでファイル書き出し中の場合が存在する。このような場合、ファイルサーバ１５０は、転送要求を受信したタイミングまでに作成された部分までのＭＸＦファイルを転送した後、当該転送が停止してしまっていた。または、ファイルサーバ１５０のＦＴＰ転送中に書き出し中の映像データの終端に追いつき、そこでＭＸＦファイルの転送が停止してしまっていた。そして、これらの転送の停止により、映像収録再生装置１００に格納されたＭＸＦファイルが不完全なファイルとなるという問題が生じていた。

そこで、本実施形態にかかる映像収録再生装置１００は、転送されてきたＭＸＦファイルが不完全であるか否かの確認を行うこととした。そして、映像収録再生装置１００が転送されてきたＭＸＦファイルを不完全であると判定した場合、再び、ファイルサーバ１５０に対して転送要求を行い、ＭＸＦファイルの転送を要求することとした。これにより、映像収録再生装置１００は、完全な状態のＭＸＦファイルを取得することができる。

図２は、本実施形態にかかる映像収録再生装置１００の全体構成を示したブロック図である。図２に示すように映像収録再生装置１００は、受信部２０１と、解析部２０２と、制御部２０３と、番組データ記憶部２０４と、ユーザインターフェイス部２０５と、デコーダ２０６と、送信部２０７と、を備える。

送信部２０７は、ＬＡＮを介して接続された他の機器に対してデータを送信する。例えば、送信部２０７は、ファイルサーバ１５０に対して、ＦＴＰを用いて、送信要求（例えばＲＥＴＲコマンド）を送信する。

受信部２０１は、ＬＡＮを介して接続された他の機器からデータを受信する。例えば、受信部２０１は、ファイルサーバ１５０から、ＭＸＦファイルを受信する。本実施形態にかかるＭＸＦファイルに格納されたデータは、映像データ（動画像データ）と音声データとの組み合わせとするが、ＭＸＦファイルに格納されるデータを制限するものではなく、例えば音声データ又は映像データのいずれか一方であっても良い。さらに、ＭＸＦファイルに格納されている映像データは、放送局から放送される番組データ等とする。

解析部２０２は、受信部２０１が受信したＭＸＦファイルを解析する。解析部２０２は、ＭＸＦファイルのヘッダ部やフッタ部等に含まれている様々な情報を読み出して、制御部２０３に出力する。また、解析部２０２は、解析が終了したＭＸＦファイルを、ＭＸＦファイル形式を保持した状態で番組データ記憶部２０４に記憶させる。

図３は、ＭＸＦファイル３００のデータ構造を示した図である。図３に示されるように、ＭＸＦファイル３００は、ヘッダ部３０３と、ボディ部３０１と、フッタ部３０２と、で構成されている。ヘッダ部３０３は、ＨＰＰ（Header Partition Pack）と“Header Metadata”とを含んでいる。ボディ部３０１は、ＢＰＰ(Body Partition Pack)と“Index Table”と“Edit Unit”とを含んでいる。フッタ部３０２は、ＦＰＰ(Footer Partition Pack)と“Index Table”と“Random Index Pack”とを含んでいる。

ＭＸＦファイルには、“Edit Unit”が複数個（例えばEdit Unit0〜Edit Unit m）含まれている。ＭＸＦのラッピング形式がフレームラッピングの場合、１個の“Edit Unit”毎に、１フレーム分のデータが格納されている。例えば、ＮＴＳＣ形式の映像データをＭＰＥＧ２に圧縮してＭＸＦにラッピングする場合、“Edit Unit”１個あたり（１フレームあたり）29.97msの時間長となる。そして、ＭＸＦファイルは、映像データの再生時間長に応じて、格納される“Edit Unit”の個数が切り替わる。例えば、映像データの時間が299.7秒の時間データの場合、ＭＸＦファイルには10000個の“Edit Unit”が格納されることになる。

そして、完全な状態のＭＸＦファイルにはフッタ部３０２が最後に付与されている。例えば、ファイルサーバ１５０から映像収録再生装置１００にＭＸＦファイルの転送中に、当該転送が途切れた場合、映像収録再生装置１００が受信したＭＸＦファイルには、フッタ部３０２が含まれていないことになる。そこで、本実施形態にかかる映像収録再生装置１００では、受信したＭＸＦファイルにフッタ部３０２が付与されているか否かを判定することで、完全な状態のＭＸＦファイルを受信できたか否かの認証を行うこととした。

そして、“Edit Unit”３１０は、１フレームあたりの、“System(option)”と映像データと音声１〜ｐと“ANC Data”とを含んでいる。

図４は、ＭＸＦファイルのヘッダ部４００の“Header Partition Pack”の一部の構造を示した図である。図４に示すように、ＭＸＦファイルのヘッダ部４００の“Header Partition Pack”には、予め定められた規格に従って様々な情報を含んでいる。例えば、ヘッダ部４００の“Header Partition Pack”には、“Sequence(Timecode)”４０１が格納されている。

“Sequence(Timecode)”４０１は、“Sequence”と、“Length”と、“Instance UID”と、“Generation UID”と、“Data Definition”と、“Duration”４１１と、“Structural Components”と、を含んでいる。そして、“Duration”４１１には、上述した“Edit Unit”の個数が格納されている。“Edit Unit”に格納されている映像データの時間長は予め定められている。このため、“Duration”４１１に格納されている数値を参照することで、当該ＭＸＦファイルに格納されている映像データの総時間長を確認することができる。つまり、本実施形態では、“Duration”４１１が、映像データの再生時間を示した再生時間情報として機能する。例えば、“Duration”４１１に“10000”が設定されていた場合、“29.97ms×10000”から導き出される299.7秒が、ＭＸＦファイルに格納されている映像データの時間長となる。

番組データ記憶部２０４は、番組で用いるＭＸＦファイルを記憶する。

ユーザインターフェイス部２０５は、ユーザから操作の入力を受け付けるインターフェイスとする。例えば、ユーザインターフェイス部２０５は、番組データ記憶部２０４に記憶されているＭＸＦファイルのうち、放送設備１６０に提供するＭＸＦファイルの再生命令を受け付ける。当該ユーザインターフェイス部２０４が当該命令を受け付けることで、制御部２０３が、番組データ記憶部２０４に記憶されているＭＸＦファイルを参照し、当該ＭＸＦファイルに格納されている映像データ等を、デコーダ２０６に送信する。

デコーダ２０６は、番組データ記憶部２０４に記憶されているＭＸＦファイル内の映像データ等をデコード（復号化）する。デコーダ２０６は、映像データを再生する場合に使用される。

ところで、本実施形態では、解析部２０２が、受信したＭＸＦファイルのヘッダ部４００から抽出した情報を、制御部２０３に出力している。このため、制御部２０３は、解析部２０２から入力された情報に基づいて、受信したＭＸＦファイルの状態を認識することができる。

制御部２０３は、映像収録再生装置１００の各部と接続して全体を制御するものである。また、制御部２０３は、図示しない記憶手段に記憶されている制御プログラムを読み出して、実行することで、受信制御部２１１と、送信制御部２１２と、判定部２１３と、決定部２１４と、を実現する。

受信制御部２１１は、受信部２０１を制御して、ファイルサーバ１５０から、ＭＸＦ（Material eXchange Format）形式のＭＸＦファイルを受信制御する。

ところで、ファイルサーバ１５０に書き出し中のＭＸＦファイルを、ＦＴＰによって映像収録再生装置１００に転送しようとした際に、転送要求を出したタイミングまでに作成された部分までのＭＸＦファイルを転送した後、転送が止まる、あるいは、転送中に書き出し中のファイルの終端に追いつき、転送が止まることとなり、映像収録再生装置１００に格納されたＭＸＦファイルが不完全なファイルとなる。

そこで、判定部２１３は、受信したＭＸＦファイルに対して、ＭＸＦとして定義されたフッタ部まで含まれているか否かを判定する。上述したように完全なＭＸＦファイルの終端部（フッタ部）には、ＦＰＰ（Footer Partition Pack）が付与されている。そこで、本実施形態にかかる判定部２１３は、ＭＸＦファイルのＦＰＰの有無で、ＭＸＦファイルの完全性を判定する。当該判定でＦＰＰが存在しない、またはＦＰＰが存在しても不完全と判定された場合、判定部２１３は、ＭＸＦファイルが途中までしか転送されていないと判定する。

さらに、判定部２１３は、受信したＭＸＦファイルにＦＰＰが含まれていない又はＦＰＰが不完全と判定した場合、換言すればＭＸＦファイルが不完全だと判定した場合、ＭＸＦファイルのヘッダ部の“Duration”に記載されている個数分の“Edit Unit”が、既に受信したＭＸＦファイルに格納されているか否かを判定する。そして、判定部２１３は、“Duration”に記載されている個数分の“Edit Unit”が、既に受信したＭＸＦファイルに格納されていなかった場合に、ＭＸＦファイルに映像データが完全に格納されていないものとして、再送要求を行うと判定する。

なお、本実施の形態において、判定部２１３が、ＦＰＰが付与されていない場合に、さらに、“Duration”に記載されている個数分の“Edit Unit”が、既に受信したＭＸＦファイルに格納されているか否かの判定を行うこととしたのは、ＦＰＰが付与されていなくとも、映像データが完全に格納されていれば、当該映像データの再生に支障がない場合も存在するからである。

判定部２１３により再送要求を行うと判定された場合、映像収録再生装置１００が、すぐにＭＸＦファイルの再送要求を行っても、当該ＭＸＦファイルがまだ書き込み中の場合も考えられる。この場合、再送要求を行ったとしても再び不完全なＭＸＦファイルを受信することになる。このため、映像収録再生装置１００は、ファイルサーバ１５０に対してＭＸＦファイルの書き込みが終了するまで待機し、書き込み終了に再送要求を行う方が好ましい。そこで、本実施形態にかかる映像収録再生装置１００では、再送要求を行うまでの待機時間を、決定部２１４が決定する。

決定部２１４は、ＭＸＦファイルのヘッダ部に含まれている“Duration”に基づいて、送信制御部２１２が再送要求を送信するまでの待機時間を決定する。本実施形態にかかる待機時間は、ＭＸＦファイルの転送が停止した時間を基準とした経過時間で示される。

本実施形態にかかる決定部２１４は、判定部２１３により再送要求を行うと判定された場合、再送の対象となるＭＸＦファイルのヘッダ部の“Header Partition Pack”に格納されている“Duration”から、完全なＭＸＦファイルに格納されている映像データの再生時間長を求める。そして、決定部２１４は、求められた再生時間長と、既に受信したＭＸＦファイルに格納されている映像データの再生可能な時間長と、の差分時間を、再送要求を送信するまでの待機時間として決定する。

ところで、解析部２０２による、受信したＭＸＦファイルの解析結果からＭＸＦファイルに何フレーム目までの映像データが格納されているかを認識できる。このため、ＭＸＦファイルに格納されている映像データの再生可能な時間長は、受信したフレーム数と１フレームあたりの時間長から、特定できる。

また、決定部２１４は、受信したＭＸＦファイルに格納されているフレーム数と、“Duration”に格納されているフレーム数と、の差分から、完成まで残り何フレーム必要か算出し、算出したフレーム数に、一フレームあたりの時間長を乗算して、待機時間を求めても良い。

このように決定部２１４が上述した手法で待機時間を決定したのは、ファイルサーバ１５０が、ビデオカメラ１６１若しくは再生デッキ１６２から映像信号の再生収録が行われている場合、又はノンリニア編集機１６３からノンリニア編集されたＭＸＦファイルを書き込んでいる場合、映像信号を再生している場合とほぼ同等の時間を要するからである。このように、映像収録再生装置１００が、決定された待機時間を待機することで、ファイルサーバ１５０へのＭＸＦファイルの書き込みが終了していると推測される。これにより、映像収録再生装置１００が、待機した後にファイルサーバ１５０に送信要求を送信することで、完全な状態のＭＸＦファイルを取得可能となる。

送信制御部２１２は、判定部２１３により再送要求を行うと判定された場合、決定部２１４で決定された待機時間を待機した後、ファイルサーバ１５０に対して、ＭＸＦファイルの再送要求を送信する。このように本実施形態では、受信したＭＸＦファイルにＦＰＰが格納されておらず、ヘッダ部の“Duration”に示された再生時間分の映像データが格納されていない場合に、当該ＭＸＦファイルの再送要求を行うこととした。

映像収録再生装置１００にかかるＭＸＦファイルの再転送手法としては、転送済みのＭＸＦファイルを削除した後、ＦＴＰのＲＥＴＲコマンドを用いて、再びＭＸＦファイルを先頭から転送する手法と、ＭＸＦファイルの未転送の位置をＲＥＳＴコマンドにより指定し、ＭＸＦファイルの未転送部分のみ転送する手法と、がある。

本実施形態では、ファイルサーバ１５０及び映像収録再生装置１００の両方がＲＥＳＴコマンドに対応している場合にＲＥＳＴコマンドを用いる。そして、ファイルサーバ１５０及び映像収録再生装置１００のいずれか１つ以上がＲＥＳＴコマンドに対応していない場合、ＲＥＴＲコマンドを用いることとした。どちらの手法を用いた場合でも、映像収録再生装置１００は、すでに受信しているＭＸＦファイルの“Duration”から、ファイルサーバ１５０側の書き込みが終了するまでの時間を推測し、当該時間を待機してから再転送要求を行うため、不完全な状態でＭＸＦファイルが転送されることを抑止できる。これにより、無駄な再転送を抑止できる。

次に、本実施の形態にかかる映像収録再生装置１００における、ＭＸＦファイルの処理について説明する。図５は、本実施の形態にかかる映像収録再生装置１００における上述した処理の手順を示すフローチャートである。

まず、送信制御部２１２が、送信部２０７を制御して、ファイルサーバ１５０にＭＸＦファイルの転送要求を送信する（ステップＳ５０１）。これにより、ファイルサーバ１５０と、映像収録再生装置１００と、の間で、ＭＸＦファイルの転送が開始される。

次に、受信制御部２１１が、ファイルサーバ１５０から、ＭＸＦファイルの転送完了の応答を受信する（ステップＳ５０２）。これにより、ＭＸＦファイルの転送が終了する。

そして、判定部２１３が、受信したＭＸＦファイルにＦＰＰが含まれているか否かを判定する（ステップＳ５０３）。ＭＸＦファイルにＦＰＰが含まれていると判定した場合（ステップＳ５０３：Ｙｅｓ）、ＭＸＦファイルを完全な状態で受信したものとして処理を終了する。

そして、判定部２１３が、ＭＸＦファイルにＦＰＰが含まれていないと判定した場合（ステップＳ５０３：Ｎｏ）、判定部２１３は、既に転送されたＭＸＦファイルに格納されている最後のフレームまでの再生時間が、ヘッダ部の“Duration”で示される再生時間長と一致するか否かを判定する（ステップＳ５０４）。一致すると判定した場合（ステップＳ５０４：Ｙｅｓ）、ＭＸＦファイルに全ての映像データが格納されているものとして処理を終了する。

一方、判定部２１３が、最後のフレームまでの再生時間が、ヘッダ部の“Duration”で示される再生時間長と一致しないと判定した場合（ステップＳ５０４：Ｎｏ）、ヘッダ部の“Duration”と、転送済みのＭＸＦファイルに格納されている映像データの再生時間長と、に基づいて、転送要求を送信するまでの待機時間を特定する（ステップＳ５０５）。

そして、送信制御部２１２は、特定された待機時間を待機する（ステップＳ５０６）。その後、送信制御部２１２は、送信部２０７を制御して、ファイルサーバ１５０にＭＸＦファイルの転送要求を送信する（ステップＳ５０７）。当該転送要求をトリガーとして、映像収録再生装置１００と、ファイルサーバ１５０と、の間でＭＸＦファイルの転送が開始される。その後、再びステップＳ５０２から処理を行う。

本実施形態にかかる映像収録再生装置１００では、受信したＭＸＦファイルにＦＰＰが含まれていない場合、さらに、ＭＸＦファイルに格納されている映像データの再生時間長について判定を行う例について説明した。しかしながら、上述した実施形態は、当該判定を行うことに制限するものではなく、フッタが含まれているか否かを判定し、フッタが含まれていない場合に再送要求を行うようにしても良い。

以上説明したとおり、本実施形態にかかる映像収録再生装置１００は、ファイルサーバ１５０に対して書き出し中のＭＸＦファイルを転送したため、不完全なＭＸＦファイルを取得した場合でも、上述した構成により、自動的に再度転送要求を行うこととした。これにより映像収録再生装置１００は、完全な状態のＭＸＦファイルを取得することが可能となった。そして、映像収録再生装置１００では、完全な状態のＭＸＦファイルを取得するためのユーザの操作負担を軽減することが可能となった。

さらに、映像収録再生装置１００は、既に受信したＭＸＦファイルに基づいて決定された待機時間を経過した後に、再度ＭＸＦファイルの転送を行うことで、再び不完全なＭＸＦファイルが転送されることを抑止できる。換言すれば、映像収録再生装置１００は、転送に失敗せずに、完成したＭＸＦファイルを取り込むことが可能となる。

なお、本実施形態の映像収録再生装置１００で実行される制御プログラムは、ＲＯＭ等に予め組み込まれて提供される。

本実施形態の映像収録再生装置１００で実行される制御プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。

さらに、本実施形態の映像収録再生装置１００で実行される制御プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、本実施形態の映像収録再生装置１００で実行される制御プログラムをインターネット等のネットワーク経由で提供または配布するように構成しても良い。

本実施形態の映像収録再生装置１００で実行される制御プログラムは、上述した各部（受信制御部、送信制御部、判定部、決定部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ（プロセッサ）が上記ＲＯＭから制御プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、受信制御部、送信制御部、判定部、決定部が主記憶装置上に生成されるようになっている。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００…映像収録再生装置、１２０…映像確認用モニタ、１５０…ファイルサーバ、１６０…放送設備、１６１…ビデオカメラ、１６２…再生デッキ、１６３…ノンリニア編集機、２０１…受信部、２０２…解析部、２０３…制御部、２０４…番組データ記憶部、２０５…ユーザインターフェイス部、２０６…デコーダ、２０７…送信部、２１１…受信制御部、２１２…送信制御部、２１３…判定部、２１４…決定部

Claims (10)

1. ファイルを配信する配信装置から、ＭＸＦ（Material eXchange Format）で定義されているＭＸＦファイルを受信する受信手段と、
   受信した前記ＭＸＦファイルに、ＭＸＦで定義されているフッタまで含まれているか否かを判定する判定手段と、
   前記判定手段によりフッタが含まれていないと判定された場合、前記配信装置に対して、前記ＭＸＦファイルの再送要求を送信する送信手段と、
   を備えるファイル処理装置。
2. 前記ＭＸＦファイルのヘッダに含まれている、当該ＭＸＦファイルに含まれているデータの再生時間を特定可能な再生時間情報に基づいて、前記送信手段が前記再送要求を送信するまでの待機時間を決定する決定手段を、
   さらに備える請求項１に記載のファイル処理装置。
3. 前記決定手段は、前記ヘッダに含まれている前記再生時間情報から求められる再生時間長と、既に受信した前記ＭＸＦファイルに格納されている前記データを再生した場合の時間長と、の差分時間を、前記再送要求を送信するまでの待機時間として決定する、
   請求項２に記載のファイル処理装置。
4. 前記再生時間情報は、前記ＭＸＦで定義されているDurationである、
   請求項２又は３に記載のファイル処理装置。
5. 前記判定手段は、既に受信したＭＸＦファイルに前記フッタが含まれていないと判定した場合、さらに、前記ＭＸＦファイルのヘッダに含まれている再生時間情報で示される再生時間分の前記データが、既に受信した前記ＭＸＦファイルに格納されているか否か判定し、
   前記送信手段は、前記判定手段により前記再生時間情報で示される再生時間分の前記データが格納されていないと判定された場合に、前記配信装置に対して、前記ＭＸＦファイルの再送要求を送信する、
   請求項１乃至４のいずれか１つに記載のファイル処理装置。
6. ファイル処理装置で実行されるファイル受信方法であって、
   受信手段が、ファイルを配信する配信装置から、ＭＸＦ（Material eXchange Format）で定義されているＭＸＦファイルを受信する受信ステップと、
   判定手段が、受信した前記ＭＸＦファイルに、ＭＸＦで定義されているフッタまで含まれているか否かを判定する判定ステップと、
   送信手段が、前記判定ステップによりフッタが含まれていないと判定された場合、前記配信装置に対して、前記ＭＸＦファイルの再送要求を送信する送信ステップと、
   を含むファイル受信方法。
7. 決定手段が、前記ＭＸＦファイルのヘッダに含まれている、当該ＭＸＦファイルに含まれているデータの再生時間を特定可能な再生時間情報に基づいて、前記送信ステップが前記再送要求を送信するまでの待機時間を決定する決定ステップを、
   さらに含む請求項６に記載のファイル受信方法。
8. 前記決定ステップは、前記ヘッダに含まれている前記再生時間情報から求められる再生時間長と、既に受信した前記ＭＸＦファイルに格納されている前記データを再生した場合の時間長と、の差分時間を、前記再送要求を送信するまでの待機時間として決定する、
   請求項７に記載のファイル受信方法。
9. 前記再生時間情報は、前記ＭＸＦで定義されているDurationである、
   請求項７又は８に記載のファイル受信方法。
10. 前記判定ステップは、既に受信したＭＸＦファイルに前記フッタが含まれていないと判定した場合、さらに、前記ＭＸＦファイルのヘッダに含まれている再生時間情報で示される再生時間分の前記データが、既に受信した前記ＭＸＦファイルに格納されているか否か判定し、
    前記送信ステップは、前記判定ステップにより前記再生時間情報で示される再生時間分の前記データが格納されていないと判定された場合に、前記配信装置に対して、前記ＭＸＦファイルの再送要求を送信する、
    請求項６乃至９のいずれか１つに記載のファイル受信方法。

Images