(57)【要約】【課題】ＨＴＴＰ／１．１で定義される仕様が送信側、受信側、またはその双方で実装されていなくても、ライブでの映像及び音声の配信と受信・再生を可能とし、且つ、受信したデータをコンテンツとして再利用できるようにする。【解決手段】動画配信装置は、クライアントからのリクエスト情報から、配信データのサイズ（Content-length）を算出し、そのサイズを再生装置に通知して、再生処理に必要なメタデータと符号化データをセットにしたブロックを生成し、順次送信する。送出サイズの総計がContent-lengthと等しくなるように符号化データのかわりに無視されるデータを送出する。【選択図】図５
2007324722.tif 000002
【特許請求の範囲】
【請求項１】
映像または音声の少なくとも一方からなる動画像データの発生順序に従って、動画像の符号化データと前記符号化データの管理情報とからなる１つ以上のデータブロックから構成されるように生成する動画像データ生成手段と、
前記動画像データのサイズをあらかじめ概算する動画像データサイズ概算手段と、
前記動画像データサイズ概算手段により概算された動画像データのサイズ情報と第１のデータブロックとを通信手続きに適した形式に生成する第１の通信データ生成手段と、
前記動画像データ生成手段により生成された動画像データを、順次通信手続きに適した形式に生成する第２の通信データ生成手段と、
前記第１の通信データ生成手段及び第２の通信データ生成手段により順次生成された通信データのサイズを積算する通信データ積算手段と、
前記動画像データサイズ概算手段により概算された動画像データのサイズ情報と前記通信データ積算手段により積算された通信データのサイズ情報とから終了を判断する終了判断手段と、
前記終了判断手段により終了と判断された場合に、前記動画像データサイズ概算手段により概算された動画像データのサイズ情報と前記動画像データサイズ概算手段により積算された通信データのサイズ情報の差異に等しいサイズの無視されるデータを生成する第３の通信データ生成手段と、
前記第３の通信データ生成手段により生成された通信データを順次送信する通信手段とを備えることを特徴とする動画像データ配信装置。
【請求項２】
前記動画像データサイズ概算手段は、前記動画像データの符号化レートと前記動画像データの配信時間とから算出される符号化データのサイズと前記符号化データの管理情報との和を概算した動画像データのサイズとすることを特徴とする請求項１に記載の動画像データ配信装置。
【請求項３】
前記終了判断手段は、前記動画像データサイズ概算手段によって概算された動画像データのサイズ情報が、積算された通信データのサイズ情報と、前記動画像データの符号化レートと前記動画像データの次のデータブロックの時間とから算出される符号化データのサイズと、前記符号化データの管理情報と、あらかじめ与えられた０以上の誤差値との和よりも小さいかどうかを判断することにより行われることを特徴とした請求項１に記載の動画像データ配信装置。
【請求項４】
前記動画像データは、ＭＰＥＧ、ＪＰＥＧまたは前記ＭＰＥＧ及びＪＰＥＧに匹敵する符号化データを含み、前記通信手段により配信される通信データの本体がＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ形式またはその派生形式であることを特徴とする請求項１〜３の何れか１項に記載の動画像データ配信装置。
【請求項５】
前記通信手段は、通信手順としてＨＴＴＰまたはＳＯＡＰを利用することを特徴とする請求項１〜３の何れか１項に記載の動画像データ配信装置。
【請求項６】
請求項１〜５の何れか１項に記載の動画像データ配信装置と、
前記動画像データ配信装置と通信を行うクライアント通信手段と前記クライアント通信手段により受信した動画像データを再生する動画像再生手段とを備える再生装置とから構成されることを特徴とする動画像データ通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は動画像データ配信装置及び動画像データ通信システムに関し、例えばデータの送受信に用いて好適な技術に関する。
【背景技術】
【０００２】
近年、犯罪の監視や遠隔地の確認などを目的とした、いわゆる監視カメラが普及しつつある。このような実時間符号化を行った動画映像や音声の配信（以下、ライブ映像配信とする）を実現するものとして、ＲＴＰ（A Transport Protocol for Real-Time Applications）と呼ばれる形式が一般的である。
【０００３】
しかしながら、ＲＴＰを用いたライブ映像配信においては、ネットワークセキュリティ上の観点からファイヤーウォールが設定されていたり、ライブ映像を格納するデータパケットの欠落が発生しやすかったりといった課題もある。このため、より単純なＨＴＴＰ（Hyper Text Transfer Protocol）などのプロトコルによるファイル転送形式を用いたライブ映像配信が検討されてきた。
【０００４】
従来、このような実時間処理を行う事に適したファイル記録形式としては、ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ フォーマットにおけるフラグメント映像形式（Fragmented Movie）がある。フラグメント映像形式は、動画データの全体に係わるメタデータをファイルの先頭に記述し、その後に、一定時間の実際の動画データの一部を記録した後、これに続く動画データのメタデータと対応する動画データの組み合わせを連続して記録するものである。すなわち、ある一定の決められた動画データとそのメタデータの組み合わせをひとつのデータのかたまりとして取り扱うことが可能となっている。このような形式で記録することにより、実時間符号化された動画データを連続して記録する事をより小さな負荷で実現することができる。
【０００５】
また、ＨＴＴＰなどのファイル転送に適したプロトコルについては、その性質上、転送されるデータのサイズをあらかじめ受信側に通知する必要があるため、これに対応する仕組みが拡張されてきた。
【０００６】
ライブ映像配信においてはその終了を配信開始前に知ることができない。このため、例えば、送信されるデータを小さなブロックに分割し、このブロック毎に配信側から受信側に転送サイズを通知することで、配信開始前に全体のサイズを必要としない仕組みがＨＴＴＰにおいては定義されている。
【０００７】
また、受信側から送信側に対して送信要求サイズを通知し、これによって同様の仕組みを実現することも提案されている（例えば、特許文献１参照）。これは、ＨＴＴＰに定義されるＲａｎｇｅ機能を用いて、通信接続を維持したまま、受信側からデータの一部を順次取得することにより、分割受信をするものである。
【０００８】
【特許文献１】特開２００５−２７０１０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかしながら、例えば、前記Ｃｈｕｎｋｅｄ Ｔｒａｎｓｆｅｒ Ｅｎｃｏｄｉｎｇなどの手法を用いて全体の配信ファイルサイズが確定しないライブ映像を配信しようとする場合、ＨＴＴＰ／１．１で定義される仕様が、送信側及び受信側の双方で実装されていなければならない。そして、どちらかがＨＴＴＰのひとつ前の仕様であるＨＴＴＰ／１．０を実装している場合には、これを利用できないという問題点があった。ＣＰＵリソースやメモリなどに制約のある機器の場合、ＨＴＴＰ／１．０相当の実装とせざるをえない場合も多く、このような場合には実現できない。
【００１０】
一方で、配信ファイルサイズが確定できないため、ファイルサイズを通知せずに配信を行い、通信の終了を通信接続の切断により行うことも可能であるが、この場合には、このような通信の切断が例外的なものであるため好ましいものではない。そればかりか、転送が完了しない状態での切断のため、特にプロトコル的な観点からは、受信データが完全ではない状態での終了であることから、受信したファイルが不完全なものとなって、再利用が困難となってしまう問題も発生する。
【００１１】
また、ＨＴＴＰに定義されるＲａｎｇｅ機能を用いる場合、本来この機能は、受信側の判断で都合のよいデータサイズ毎にファイルを取得する事を主眼としている。このため、前記通信接続の切断の問題が発生する可能性があるばかりか、送信側及び受信側の双方が、このような仕組みを相互に了解済みでなければ処理が困難となってしまうという問題点があった。
【００１２】
本発明は前述の問題点に鑑み、ＨＴＴＰ／１．１で定義される仕様が少なくとも送信側、または受信側で実装されていなくても、ライブでの映像及び音声の配信と受信・再生でき、且つ受信したデータをコンテンツとして再利用できるようにすることを目的とする。
【課題を解決するための手段】
【００１３】
本発明は前記課題に鑑みてなされたものであり、映像または音声の少なくとも一方からなる動画像データの発生順序に従って、動画像の符号化データと前記符号化データの管理情報とからなる１つ以上のデータブロックから構成されるように生成する動画像データ生成手段と、前記動画像データのサイズをあらかじめ概算する動画像データサイズ概算手段と、前記動画像データサイズ概算手段により概算された動画像データのサイズ情報と第１のデータブロックとを通信手続きに適した形式に生成する第１の通信データ生成手段と、前記動画像データ生成手段により生成された動画像データを、順次通信手続きに適した形式に生成する第２の通信データ生成手段と、前記第１の通信データ生成手段及び第２の通信データ生成手段により順次生成された通信データのサイズを積算する通信データ積算手段と、前記動画像データサイズ概算手段により概算された動画像データのサイズ情報と前記通信データ積算手段により積算された通信データのサイズ情報とから終了を判断する終了判断手段と、前記終了判断手段により終了と判断された場合に、前記動画像データサイズ概算手段により概算された動画像データのサイズ情報と前記動画像データサイズ概算手段により積算された通信データのサイズ情報の差異に等しいサイズの無視されるデータを生成する第３の通信データ生成手段と、前記第３の通信データ生成手段により生成された通信データを順次送信する通信手段とを備えることを特徴とする動画像データ配信装置等、を提供する。
【発明の効果】
【００１４】
本発明によれば、ライブ映像及び音声を符号化した動画像データの送受信を実現し、受信側ではライブでの画像及び音声の再生が可能であり、受信したデータは再利用が可能な状態で蓄積することができる。
【発明を実施するための最良の形態】
【００１５】
（第１の実施形態）
以下、本発明の通信機能を備えたネットワークカメラに適用した場合の第１の実施形態について図面を参照しながら説明する。
図１は、本実施形態の実施に好適なシステム構成例を示す概念図である。
図１に示すように、このシステムは、動画像を生成しネットワーク上に配信するネットワークカメラ１０１と、配信された動画像を受信して表示する再生装置と１０２から構成されている。
【００１６】
ネットワークカメラ１０１は、通信機能を備えた撮像装置であり、近年、監視用途などで用いられるカメラとして普及している。一方、再生装置１０２は、ネットワークカメラ１０１に対応して、通信機能を備えた動画像の再生を行う装置である。再生装置１０２は、例えば、ＰＣ（パーソナルコンピュータ）上で動作するアプリケーション・プログラムとして実現されている場合もあれば、専用のディスプレイを備えた監視装置の一部として実現される場合もある。
【００１７】
ネットワークカメラ１０１は、概念的な機能面からは、動画像をキャプチャし符号化データを生成する動画像生成モジュール１０３と、符号化された動画像を通信に適したデータに変換する通信データ生成モジュール１０４と、実際に要求に応じて動画像を送出する通信サーバー１０５とから構成されている。
【００１８】
再生装置１０２は、概念的な機能面では、ネットワークカメラ１０１に動画像の要求を行い、動画像を取得する通信クライアント１０６と、受信した動画像の符号化データを復号化して可視化（レンダリング等）する動画像表示モジュール１０６とから構成される。
【００１９】
次に、一般的な処理の流れを説明する。
最初に、利用者により再生装置１０２が操作されて、ネットワークカメラ１０１からの画像を取得するよう指示を行う。このような操作は、例えばＧＵＩ（グラフィカル・ユーザ・インターフェース）を用いてネットワークカメラ１０１のＵＲＬ（Uniform Resource Locator）を入力する操作であってもよい。また、あらかじめ再生装置１０２に通信接続定義しておいた情報を用いて、スイッチを押下するような操作であってもよい。
【００２０】
画像取得の指示は、通信クライアント１０６から通信サーバー１０５に対して、ＨＴＴＰ（Hyper Text Transfer Protocol）のような通信手続き（プロトコル）によりネットワークを介して通知される。
【００２１】
本実施形態では、具体的には、通信クライアント１０６と通信サーバー１０５との間で使用される通信手続きは、ＨＴＴＰであり、通信サーバー１０５は、ＨＴＴＰｄと呼ばれるＨＴＴＰサーバーそのものである。また、要求に利用されるメッセージは、たとえばＵＲＬを利用したＣＧＩ（Common Gateway Interface）の指定などにより行われる。
【００２２】
この場合、ＣＧＩは、動画像を取得するためのプログラムである。ＵＲＬにより、動画像の取得が行われた場合、通信サーバー１０５は、該当のリソースを呼び出し送信処理を行おうとするが、その処理が通信データ生成モジュール１０４の処理である。前述のように、ＣＧＩプログラムであれば、通信データ生成モジュール１０４の処理そのものがＣＧＩによって構成される。
【００２３】
ここで、通信データ生成モジュール１０４は、動画像生成モジュール１０３が生成した動画像を取得し、再生装置１０２に送出するにあたり最適となる形式に整形する。さらに、本実施形態であれば、ＨＴＴＰのヘッダを生成するといった処理を行って、送信用のデータを出力する。通信サーバー１０５は、この送信用のデータを通信クライアント１０６に送出する。
【００２４】
通信クライアント１０６では、ＵＲＬ指定により要求した動画像が要求に対する結果として受信される。受信が成功すれば、この受信データが動画像表示モジュール１０７に受け渡され、ここで、再生表示が行われる。
【００２５】
ここで図１を用いて説明したシステム構成上での処理の概要は、所謂ＷＷＷ（World Wide Web）で一般的に利用されるＨＴＴＰ処理と同等であって、特に特殊な利用方法ではない。ただし、動画像生成モジュール１０３が記録済みの静的なリソースではなく動画像を生成しているという点は除く。
【００２６】
本実施形態の特徴について詳細に述べる前に、ここで、ネットワークカメラ１０１と再生装置１０２とにより構成される本実施形態に好適なシステム構成の装置構成の詳細を図２を用いてさらに説明する。図２は、本実施形態に係るネットワークカメラ１０１の内部構成及び再生装置１０２の内部構成の一例を示すブロック図である。
【００２７】
ネットワークカメラ１０１の内部構成は、次のようになっている。まず、送出される動画像の元となる被写体の画像は、光学系からなる撮影レンズユニット２０１を通って光学センサ２０５にて結像する。
【００２８】
撮影レンズユニット２０１は、例えば、焦点を合わせるためにモーターなどによりレンズ群を移動する仕組みになっており、その直接の制御は、撮影レンズユニット駆動回路２０２によって行われる。この時、絞りを含む絞りユニット２０３が絞りユニット駆動回路２０４によって操作され、結像する光は適切に光量調整されるようになっている。
【００２９】
光学センサ２０５は、固体撮像素子（ＣＣＤやＣＭＯＳなど）によって構成され、入射した光を光学量に応じて電荷に変換、蓄積する性質をもっている。この電荷を読み出し、Ａ／Ｄコンバータ２０７でデジタル化することにより、圧縮されていないデジタル画像が生成される。
【００３０】
光学センサ２０５は、光学センサ駆動回路２０６の出力されるパルス信号などによって適切に制御されており、指示されたタイミングで指示された時間の間に蓄積された電荷を読み出す一連の動作を連続することによって、連続したデジタル画像が得られる。このようにして取得された連続画像は、言うまでもなく動画像である。
【００３１】
次に、連続して取得されるデジタル画像は、圧縮符号化を行うために、画像信号処理回路２０８に受け渡され、ホワイトバランス補正やガンマ補正といった画像の補正を行った上で、符号圧縮回路２０９に受け渡される。このような処理間のデジタル画像の受け渡しは、例えばＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）回路を利用した高速なメモリ２１０のアクセスにより行われる。このメモリ２１０の画像データを圧縮符号化処理するのが符号圧縮回路２０９である。
【００３２】
例えば、連続したＪＰＥＧ（ＩＳＯ／ＩＥＣ  １０９１８）符号化によるいわゆるモーションＪＰＥＧ画像では、画像信号処理回路２０８の入力でデジタル画像がＲＧＢ信号である場合、輝度信号Ｙとクロマ信号ＣｂＣｒからなるＹＣ信号に信号化される。そして、これらを８×８画素のブロックに分割したのち、離散コサイン変換、量子化、ハフマン符号化といった処理が行われて最終的な圧縮画像が出力される。
【００３３】
あるいは、圧縮符号化方式がＭＰＥＧ−２（ＩＳＯ／ＩＥＣ  １３８１８）やＭＰＥＧ−４（ＩＳＯ／ＩＥＣ  １４４９６）などのフレーム間予測を行う形式である場合、圧縮しようとする特定の１枚の画像（フレーム）に対し、前後のフレームを参照する。そして前後のフレームを参照しながら、動き補償予測、マクロブロック処理などを行って、前後が相互に依存した圧縮画像（ビットストリーム）が出力される。
【００３４】
このようにして出力された動画の圧縮画像は、メモリ２１０に一時保管され、記録ファイル形式に整形されてネットワークコントローラ２１１を介し、通信回路２１２を経てネットワーク上に送出される。
【００３５】
この一連の動作を図１で説明したような処理として制御し、通信に最適化する役割は、ＣＰＵ２１４によって行われる。すなわち、一般的な表現で言われる制御プログラム（ファームウェア）によるプログラム動作である。
【００３６】
制御プログラム（ファームウェア）は、静的な情報として、通常ＲＯＭ２１３に格納されている。ネットワークカメラ１０１は、必要に応じて、このＲＯＭより制御プログラム（ファームウェア）を読み出す。そして、ＣＰＵ２１４で処理することにより、全体の動作が行われる。
【００３７】
ＣＰＵ２１４で処理される制御プログラム（ファームウェア）は、これ以外にもいくつかの処理機能を担っており、例えば、先に説明した撮影レンズユニット２０１の動作の指示を行って、ズーム動作（焦点距離の移動）やオートフォーカスといった処理を行う。なお、ここでは、再生装置１０２側からの動画像要求といった処理については、説明を省略している。これは、装置構成の説明において、そのような処理の流れは複雑となるためであって、たとえばこのような動画像要求のメッセージなども通信回路２１２を介して通信されることは言うまでもない。
【００３８】
次に、再生装置１０２について説明する。ここでも同様に、動画像を受信した場合を例に説明をおこなう。再生装置１０２の内部構成は、次のようになっている。
動画像データは、通信回路２２１からネットワークコントローラ２２２を介して再生装置に取り込まれる。このような処理は、たとえばネットワークカメラ１０１と同様に、ＲＯＭ２２８に格納されたプログラムなどによりＣＰＵ２２９上で制御プログラム（ファームウェア）が処理を行う。
【００３９】
受信データは、一次的にメモリ２３０に格納される。もし、必要であれば、Ｉ／Ｏコントローラ２２９により記録装置２２８に格納してもよい。格納された受信データは、符号伸長回路２２３が処理出来る形式に変換され、符号伸長回路２２３により復号化が行われた後、画像信号処理回路２２４にて表示に適切になるように画像処理が行われて表示装置２２６で表示される。
【００４０】
表示装置２２６は、表示装置駆動回路２２７にてリフレッシュのタイミングなどが調整され、あるいは、表示装置がアナログ駆動されるものであれば、Ａ／Ｄコンバータ２２５にてデジタルからアナログ変換される。
【００４１】
なお、図２を説明するにあたって、制御プログラム（ファームウェア）による制御を説明したが、勿論、高速化のためにファームウェア処理の一部、または、全部をハードウェアで処理することも可能である。例えば、プロトコル処理の一部は、一般的にハード化されやすい場合があるとされ、所謂オフローダーと呼ばれる装置構成としてハード化する例も多い。本実施形態では、最も一般的な構成として制御プログラムによる処理として説明しているに過ぎない。
【００４２】
次に、この後の説明を容易にするため、本実施形態に適用されるフラグメント映像データとしてのＭＰ４ファイルについて説明する。本実施形態においては、符号圧縮回路２０９および符号伸長回路２２３が処理する符号化形式は、たとえばＭＰＥＧ−４（ISO/IEC 14496）が利用されるものとする。
【００４３】
ＭＰ４ファイルは、ＭＰＥＧ−４の標準ファイル形式として国際標準化されたファイル形式であり、フラグメント映像データは、Fragmented Movieとして、このＭＰ４ファイル形式内で定義される形式のひとつである。なお、本実施形態では、ＭＰＥＧ−４を用いたＭＰ４ファイル形式を示すが、例えばＭｏｔｉｏｎ−ＪＰＥＧ２０００を用いたＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔのファイル形式であっても同様に動作する。あるいは、符号化形式としてＨ．２６４を用いてもよい。
【００４４】
これらは、符号化形式としては異なるものであるが、後に明らかになるように、符号化形式が異なるものであってもフラグメント映像データであれば本実施形態では適用可能である。
【００４５】
ここで、ＭＰ４ファイル形式及びフラグメント映像データ（Fragmented Movie）の構造について説明する。図３は、Fragmented Movieを含むＭＰ４ファイル形式についてのデータ構造の一例を示す概念図である。
ＭＰ４ファイル形式では、コンテンツ全体のプレゼンテーションを「ムービー」、コンテンツを構成するメディアストリームのプレゼンテーションを「トラック」と呼んでいる。
【００４６】
最初のヘッダであるMovie_BOX （'moov'）３０２には、典型的には、動画像のデータ全体を論理的に取り扱うビデオトラック３０３と音声のデータ全体を論理的に取り扱うオーディオトラック３０７とが含まれている。ビデオトラック３０３とオーディオトラック３０７の基本的な構成内容は、ほとんど同等のものとなっている。すなわち、それぞれのトラックは、実際のメディアデータの様々な属性情報を記録しており、その内容がメディアデータの特性に応じて多少異なっているだけである。
【００４７】
ビデオトラック３０３に含まれるデータは、例えば、符号化データを復号化するための所謂デコーダの構成情報や動画像の矩形サイズなどの情報が含まれる。さらに、メディアデータが実際に記録されているファイル上の位置を示すオフセット３０４や、メディアデータのそれぞれのフレームデータ（ピクチャと呼ばれることもある）のサイズを示すサンプルサイズ３０５、それぞれのフレームデータのデコード時間及びプレゼンテーション時間を示すタイムスタンプ３０６などが記録されている。
【００４８】
ＭＰ４ファイル３０１の全体の構成としては、映像及び音声データの物理的位置、時間的位置や特性情報などを示すヘッダ情報（メタデータ）部分と、符号化された映像・音声データの実体であるメディアデータ部分から構成される。
【００４９】
図３はFragmented Movie独自のBOXを含んだものになっている。ところが、Fragmented Movie構造を持たないシンプルな構造のＭＰ４ファイルでは、Fragmented Movieによる拡張部分の情報を示すMovie_Extends_BOX（'mvex'）３０８を除いたMovie_BOX （'moov'）３０２と、それと対を成すメディアデータ部であるMedia_Data_BOX（'mdat'）３１１のみによって構成される。
【００５０】
一方、Fragmented Movie構造を持つＭＰ４ファイルでは、コンテンツのヘッダ情報およびメディアデータを任意の時間単位で分割することができ、分割された「フラグメント」はファイルの先頭から時系列順に記録される。
【００５１】
この時、コンテンツ全体の属性情報を含む先頭のMovie_BOX （'moov'）３０２には、図３に示すように、フラグメント部分を含む全体の再生時間（duration）などの情報を格納するMovie_Extends_BOX（'mvex'）３０８が配置される。そして、後に続くMedia_Data_BOX（'mdat'）３１１に含まれるデータに関する情報を保持する。
【００５２】
次に出現するMovie_Fragment_BOX（'moof'）３１２はフラグメント部分のヘッダ情報である。そして、Media_Data_BOX（'mdat'）３１３に含まれるデータに関する情報を保持する。以上のように以降同様にMovie_Fragment_BOX（'moof'）とMedia_Data_BOX（'mdat'）の組み合わせが追加されていく形で構成される。
【００５３】
Fragmented Movie構造を持つＭＰ４ファイルでは、Movie_BOX （'moov'）３０２の中にFragmented Movieによる拡張情報を格納しているMovie_Extends_BOX（'mvex'）３０８が存在する。そして、Movie_Extends_BOX（'mvex'）３０８に含まれるデータは、フラグメント部分を含めたムービー全体の再生時間（duration）３０９やフラグメント部分に含まれるメディアデータのサンプルサイズやサンプル毎のdurationなどのデフォルト値などの情報３１０を設定可能である。
【００５４】
ここにデフォルト値を設定することによって、後に続くMovie_Fragment_BOX（'moof'）３１２内のサンプル情報ではデフォルト値を使用する場合、サンプル毎の値の設定を省略することができる。
【００５５】
このように、ＭＰ４ファイル形式のファイルでは、メディアデータに関する各種属性情報をメタデータ領域としてメディアデータと分離して保持する。これにより、メディアデータが物理的にどのように格納されているかに関わらず、所望のサンプルデータに容易にアクセスすることが可能になっている。
【００５６】
また、Fragmented Movie構造によれば、メタデータとメディアデータを1つのブロックとして、複数のブロックが時系列順に連結したファイル構造とすることができる。次に、図１及び図２を念頭に、本実施形態の特徴となる部分をより具体的かつ詳細に説明していく。
【００５７】
図４は、再生装置１０２からネットワークカメラ１０１に対して動画像の要求を行う際に利用するＵＲＬの一例を示す図である。
通信クライアント１０６および通信サーバー１０５は、ＨＴＴＰの処理に適合しており、図４のＵＲＬ例４０１で示したようなＵＲＬで、通信クライアント１０６から通信サーバー１０５に接続を行うものとする。
【００５８】
ＵＲＬ例４０１の５つの例の前半部分はともに同じである。ＨＴＴＰにより（http:）、hostnameで与えられるアドレス（//hostname/）の相対パス（cgi-bin/getmp4.cgi）であるＣＧＩにアクセスを行うことを意味している。これにより、通信サーバー１０５に含まれるＨＴＴＰ処理サーバーがＣＧＩプログラムを起動する。後半部分のパラメータ類はＣＧＩプログラムに引き渡される値である。
【００５９】
図４には、５つの例のうち、最後のものを分解して記載されたブロック全体４０２を示している。プロトコル部分４０３、アドレス部分４０４、相対パス部分４０５が前記で説明した部分である。また、セパレータ部分４０６がそれ以降のパラメータ部分との区切りとなっている。パラメータ部分は、パラメータのセパレータ部分４０８により５つの部分に分けることができる。
【００６０】
第１のパラメータ４０７（duration=180）は、要求する動画像の時間が１８０である事を表現している。この単位は、続く第２のパラメータ４０９（scale=1）で１秒をひとつに分割した単位であることが指定されているため、１秒であり、１８０秒の動画像を指定することになる。
【００６１】
第３のパラメータ４１０（bitrate=512000）は、５１２０００ｂｐｓのビットレートであることを指定する。そして、第４のパラメータ４１１（top=6）と第５のパラメータ４１２（frg=4）で、動画の送出時の最初のデータブロックが６秒であり、その後４秒毎のデータブロックで送出を期待することを指定している。すなわち、この例では、最初６秒のデータブロックでその後４秒のデータブロックとなるような３分間の動画像を５１２ｋｂｐｓで要求することを意味している。
【００６２】
データブロックは、先に説明したフラグメント映像データとしてのＭＰ４ファイルにおける最初のヘッダ（'moov'）とデータ（'mdat'）の組み合わせ、及び、フラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせに相当する。ここで説明してきたＵＲＬの例は、実装上の例であって、パラメータの種類と数、順序、フォーマットなどは、異なる仕様であっても構わないことに注意しなければならない。これらは、純粋にアプリケーションに依存するものである。
【００６３】
また、パラメータ類は、必ずＵＲＬにより受け渡されるかのように説明してきたが、これらのパラメータ類の一部あるいは全部が、あらかじめ、通信サーバー１０５上に定義、保管、記録されていてもよい。そのようにすることにより、もし、必要なパラメータ類が通信クライアント１０６より通知されない場合でもこれを利用することができる。
【００６４】
次に、前記例に従って通信サーバー１０５が起動するＣＧＩプログラムの動作について説明する。
ＣＧＩプログラムは、動画像生成モジュール１０３の出力する動画像の符号化データを送信のために取得する必要がある。
【００６５】
符号化された動画像のデータは、圧縮符号回路２０９を駆動して生成される事は先に説明したが、動作説明を簡略化するため、ＣＧＩプログラムの機能は、通信データ生成モジュール１０４に含まれるものとする。そして、動画像のデータの符号化までを動画像生成モジュール１０３が行うものとする。
【００６６】
また、動画像生成モジュール１０３が停止している場合には、通信データ生成モジュール１０４がこれを起動する必要がある。これは、制御プログラム（ファームウェア）が符号圧縮回路２０９などの駆動を開始することに対応するかも知れないし、或いは単純に、符号化データを取得するためにそのインターフェースの初期化を行うに過ぎないかもしれない。
【００６７】
図５は、ＣＧＩプログラムの動作の一例を示すフローチャートである。
まず、起動されたＣＧＩプログラムは、後段のステップで利用する変数などの初期化を行い（ステップＳ５０１）、受け渡されるパラメータ５３１を取得する（ステップＳ５０２）。
【００６８】
ここに、パラメータ５３１は、図４を用いて説明したパラメータ部分４０２に相当する。このパラメータ５３１を用いて、次に、通信データ長の算出を行う（ステップＳ５０３）。通信データ長の算出するステップＳ５０３の具体的な算出方法は、後にさらに詳細に説明を加えるが、通信データ長は、具体的には、通信サーバー１０５から通信クライアント１０６に送出されるＭＰ４のファイル長である。
【００６９】
ここで注目すべきことは、もし、図４を用いて説明したパラメータが、この説明で用いた例と同じ場合、パラメータにはデータ長が含まれず、３分間の５１２ｋｂｐｓデータといったことのみがＣＧＩプログラムが了解するパラメータであるという点である。すなわち、通信データ長の算出するステップＳ５０３では、パラメータに応じて実際に送出されるＭＰ４ファイルのデータ長を算出することになる。
【００７０】
通信データ長が算出された後に、ＨＴＴＰヘッダが生成される（ステップＳ５０４）。
生成されるＨＴＴＰヘッダについての詳細も後に説明を加えるが、特に重要な点は、ＨＴＴＰヘッダ内に、送出しようとするＭＰ４ファイルのデータ長が記載されている点である。ＭＰ４ファイルのデータ長は、通信データ長の算出するステップＳ５０３ですでに計算済みであり、この値が用いられる。
【００７１】
次に、送出されるＭＰ４ファイルに格納される動画データとして、エンコードバッファ５３２よりエンコードデータを読み出し、第１データブロックを生成する（ステップＳ５０５）。第１データブロックは、先に説明したＭＰ４ファイルにおける最初のヘッダ（'moov'）とデータ（'mdat'）の組み合わせ部分である。このようにして生成されたＨＴＴＰヘッダと第１データブロックは、次のステップであるデータ出力１により通信データ５３４として出力が行われる（ステップＳ５０６）。
【００７２】
一般的なＨＴＴＰサーバーでは、ＣＧＩプログラムから出力される通信データは、オペレーティングシステムの標準入出力を介して、ＨＴＴＰサーバーが接続済みの通信クライアントに対して送信を行うようになっている。ここでは、そのようなＨＴＴＰサーバーの何らかの実装仕様に従って出力が行われることを仮定している。また、動画データは、一般的にそのデータ長が大きいために、一次ファイルなどを用いて出力を行ってもよい。
【００７３】
次に、終了条件の見積もりを行う（ステップＳ５０７）。そして、終了条件を満たしているか否かを判断し（ステップＳ５０８）、終了条件を満たしていれば、ｆｒｅｅデータブロックを生成するステップＳ５１１に進み、満たしていなければ後続データブロックを生成するステップＳ５０９に進む。
【００７４】
ここで、終了条件の見積もりとは、先に通信データ長を算出するステップＳ５０３であらかじめ算出された通信データ長と、実際に出力された通信データ５３４のデータ長の積算値とから判断して、最終的に出力される通信データ５３４のデータ長の積算値が算出された通信データ長を越えないかどうか判断する処理である。もし、これが越えると判断されるならば、ＨＴＴＰプロトコルに従って通信クライアント１０６に通知されたデータ長と矛盾することになる。このような矛盾が発生しないように終了条件が見積もられる。
【００７５】
もし、終了条件を満たしていないのであれば、後続データブロックを生成するステップＳ５０９が実行される。後続データブロックは、先に説明したＭＰ４ファイルにおけるフラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせに相当する。
【００７６】
具体的には、第１データブロック生成処理（ステップＳ５０５）と同様に、エンコードバッファ５３２よりエンコードデータを読み込み、この後続データブロックが生成される。生成された後続データブロックは、第１データブロックの出力であるデータ出力１処理（ステップＳ５０６）と同様に、データ出力２処理（ステップＳ５１０）で通信データ５３４として出力される。このようにして、後続データブロックが出力されたのち、再び終了条件の見積もりステップＳ５０７が行われる。終了条件が満たされない限り、この一連の処理が継続することになる。
【００７７】
なお、データ出力１処理（ステップＳ５０６）が行われた直後の終了条件見積もりステップＳ５０７とデータ出力２処理（ステップＳ５１０）が行われた後での終了条件見積もり処理（ステップＳ５０７）は、基本的には同じ処理である。ところが、実際に出力された通信データ５３４のデータ長の積算値は、明らかにデータ出力２処理（ステップＳ５１０）を通過する毎に増加している点で異なるものである。終了条件見積もりステップＳ５０７の詳細についても、後述する。
【００７８】
一方で、ステップＳ５０８の判断の結果、終了条件が満たされた場合、ｆｒｅｅデータブロック生成が行われる（ステップＳ５１１）。ｆｒｅｅデータブロック生成は、通信データとしては有効であるが、動画像データや動画像データそのものにかかわるデータを含まない特に意味のないデータ領域（'free'）を生成する処理である。このようなある種の無意味な領域は、実装上の都合や動画像の編集処理などで不要となるといった事により、アプリケーションの都合で利用することができるようＭＰ４ファイルなどの国際標準として定義されている。
【００７９】
ｆｒｅｅデータブロック生成処理（ステップＳ５１１）により生成されたデータは、第１データブロックの出力であるデータ出力１処理（ステップＳ５０６）やデータ出力２処理（ステップＳ５１０）と同様である。すなわち、データ出力３処理（ステップＳ５１２）において通信データ５３４として出力される。
【００８０】
このようにして出力された通信データ５３４は、それ自体で正しいＭＰ４ファイルとなっており、最後にＣＧＩプログラムの最終処理としてクローズ処理を行うことにより完結する（ステップＳ５１３）。
【００８１】
ここで、通信データ長の算出処理（ステップＳ５０３）の具体的な算出方法の詳細について説明を加える。通信データ長は、先に説明したように、具体的には、通信サーバー１０５から通信クライアント１０６に送出されるＭＰ４のファイル長である。
【００８２】
フラグメント映像データとしてのＭＰ４ファイルは、ＭＰ４ファイルにおける最初のヘッダ（'moov'）とデータ（'mdat'）の組み合わせ及び０個以上のフラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせから構成される。したがって、ここで算出される通信データ長、より具体的には、ＭＰ４のファイル長は、これらのデータ長を足し合わせたサイズとなる。
【００８３】
しかしながら、これらの個々のデータ長を正確に算出することは困難である。なぜならば、少なくとも圧縮符号化された動画データのデータ長は、符号化前の動画像の複雑さや圧縮符号化時のパラメータに依存するためである。多くの符号化器においては、目標ビットレートを設定し、これに近いビットレートにて圧縮符号化を行うよう設計されているが、厳密さを持ってあらかじめデータ長を決定することはかなり難しい。
【００８４】
また、最初のヘッダ（'moov'）などについても、動画データに比べればそのサイズをあらかじめ見積もることはより容易であると言えるが、それでもなお、そのデータ格納形式に連長圧縮などによる部分が存在するため、困難な場合がある。すなわち、通信データ長の算出処理（ステップＳ５０３）は、厳密であると言うより、想定されるより正確なデータ長を見積もることにほかならない。
【００８５】
最初のヘッダ（'moov'）のほとんどの部分については、ヘッダに含まれるほとんどの項目のデータサイズをあらかじめ見積もることが可能である。
これらのヘッダに含まれるすべての項目について、すべて、見積もりを行う方法を説明する事は冗長であるため、ここではその詳細な説明を省略する。例えば、Ｍｏｖｉｅ Ｈｅａｄｅｒ Ｂｏｘ（'mvhd'）は、あらかじめそのサイズを決定できる項目の典型的な例のひとつである。
【００８６】
一方で、例えば、フレームレートが固定であって、タイムスタンプがタイムスケールとの関係において一定の値で増加するようになっている場合を考える。この場合には、Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ Ｂｏｘ（'stts'）は、これが連長圧縮による記録であるため記録サイズを一定とすることが可能である。
【００８７】
しかしながら、記録されるタイムスタンプの差異が一定では無い場合、記録サイズは一定とならない。このような場合には、最初のヘッダと対で記録される動画データのサンプル数（フレーム数）との関係において、その記録サイズを概算する必要がある。しかしながら、それでもなお、記録サイズの変動は最大で高々サンプル数（フレーム数）を上限とする変動であり、この部分のデータ長の見積もりは、概算値としては比較的容易に行うことが可能である。
【００８８】
より具体的には、このＴｉｍｅ−ｔｏ−ｓａｍｐｌｅ Ｂｏｘの場合、国際標準規格であるＩＳＯ／ＩＥＣ １４４９６−１２には、
aligned(8) class TimeToSampleBox
extends FullBox('stts', version = 0, 0) {
unsigned int(32) entry_count;
int i;
for (i=0; i < entry_count; i++) {
unsigned int(32)    sample_count;
unsigned int(32)    sample_delta;
}
}
と定義されており、最小では２４バイト、最大でも１６バイトと４バイトにサンプル数を乗じたサイズ程度に見積もることができる。
【００８９】
また、例えば、Ｓａｍｐｌｅ Ｓｉｚｅ Ｂｏｘ（'stsz'）は、サンプル数に比例してサイズが増加するよう定義されている。この場合、最初のヘッダ（'moov'）と対となるデータ（'mdat'）のサンプル数からこれを見積もることができる。このように、通信データ長の算出処理（ステップＳ５０３）における最初のヘッダ（'moov'）については、対応するデータ（'mdat'）のサンプル数から、ほぼ正確にそのサイズを見積もることができる。
【００９０】
次に、最初のヘッダ（'moov'）に対応するデータ（'mdat'）部分のサイズ見積もりについて説明する。この部分のサイズ見積もりは、例えば、ビットレートとこのデータブロックの時間（Duration）から概算することができる。もし、ビットレートが８Ｍｂｐｓでありデータブロックの時間が５秒である場合、これらの値から明らかに、８Ｍｂｐｓ×５秒÷８ビットから５Ｍバイトであることが算出できる。もちろん、あらかじめサンプル数（フレーム数）とフレームレートが決められていて、この値からデータブロックの時間を算出するような方法であってもよい。
【００９１】
一般的に、このような値は、何らかの形で定義されており、それに従って符号化の制御を行うようにしている。ここでの問題は、符号化データのデータサイズを厳密に見積もることは、困難であるということである。前述したように、重要であることは、正確な見積もりではなく、想定されるより正確なデータ長を見積もることにある。
【００９２】
ＭＰ４ファイルにおける最初のヘッダ（'moov'）とデータ（'mdat'）の組み合わせと同様にして、フラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせについても、そのデータ長を見積もることができる。
【００９３】
フラグメントのヘッダ（'moof'）も、その格納形式と格納データがヘッダ（'moov'）と異なるとはいえ、ほぼ同様な考え方で定義されるものである。異なる点は、フラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせが複数回発生することにある。例えば、送出されるＭＰ４ファイルの全体が１８０秒で、最初のヘッダ（'moov'）とデータ（'mdat'）の組み合わせが５秒で、その後のひとつのフラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせが４秒の場合を考える。この場合、１８０から最初の５秒を差し引いた１７５秒間にフラグメントが複数回発生する。よって、１７５秒を４秒で除算することにより、４４回のフラグメントが発生すると計算することができる。
【００９４】
まず、１つのフラグメントについて説明する。フラグメントのヘッダであるMovie_Fragment_BOX（'moof'）３１２はMovie_Fragment_BOX（'moof'）３１２が１つにつき、１つのMovie_Fragment_Header_BOX（'mfhd'）と映像や音声のトラック毎にTrack_Fragment_BOX（'traf'）を持つ。更にTrack_Fragment_BOX（'traf'）はトラック毎に１つのTrack_Fragment_Header_BOX（'tfhd'）を持つ。これにより、１つ以上のTrack_Fragment_Run_BOX（'trun'）を持つ構造になっている。
【００９５】
ここで、Track_Fragment_BOX（'traf'）は、Movie_Fragment_BOX（'moof'）３１２と同様に含まれているBOXのコンテナとしての役割を担っているだけであるので、そのサイズは一定（８バイト）である。またMovie_Fragment_Header_BOX（'mfhd'）は、Movie_Fragment_BOX（'moof'）３１２が出現する毎に加算されるシーケンスナンバーを保持しており、BOXのサイズは常に一定（１６バイト）である。
【００９６】
また、Track_Fragment_Header_BOX（'tfhd'）はトラックのIDを保持している。また、オプションとしてそのフラグメントの基準オフセット値やデータ（'mdat'）に格納されているサンプルのサイズやdurationなどのデフォルト値を設定することができる。このため、デフォルト値の設定を行なうか否かでBOXのサイズが異なる。
【００９７】
しかし、一般には、符号化方法や符号化に関わるパラメータによってデフォルト値の設定を行うか否かはファイル生成時には決定されており、同じIDを持つトラックにおいてこれらの設定が動的に変更されることはない。このため、同一ファイル中では同じトラックIDを持つTrack_Fragment_Header_BOX（'tfhd'）のサイズは一定であると見なすことができる。
【００９８】
例えば、オプションとして基準オフセット値（８バイト）を設定した場合、ＩＳＯ／ＩＥＣ １４４９６−１２によると、Track_Fragment_Header_BOX（'tfhd'）は下記のように定義されている。このため、このBOXのサイズは２４バイトとなる。また、下記tf_flagsの設定により、どのオプション・フィールドが有効なのか判断することができる。
aligned(8) class TrackFragmentHeaderBox
extends FullBox('tfhd', 0, tf_flags){
unsigned int(32)      track_ID;
// all the following are optional fields
unsigned int(64)      base_data_offset;
unsigned int(32)      sample_description_index;
unsigned int(32)      default_sample_duration;
unsigned int(32)      default_sample_size;
unsigned int(32)      default_sample_flags
}
【００９９】
ところでトラックが複数存在する場合、データ（'mdat'）内のサンプルデータの格納方法は、ある一定時間分の連続した'サンプルの塊り'毎に異なるトラックのデータが交互に記録（インターリーブ）される方法が一般的である。この'サンプルの塊り'をMP4ファイルフォーマットでは'チャンク'と呼んでいる。
【０１００】
ここで、Track_Fragment_BOX（'traf'）に１つ以上存在するTrack_Fragment_Run_BOX（'trun'）はこの'チャンク'毎のデータの情報を格納している。このため、例えば映像と音声のトラックが存在する場合、データ（'mdat'）内で映像と音声のチャンクがインターリーブされる形で格納され、そのチャンク毎にTrack_Fragment_Run_BOX（'trun'）が存在することになる。
【０１０１】
また、トラックが１つのみであっても、Track_Fragment_Run_BOX（'trun'）は複数存在してもよい。例えば映像データがＭＰＥＧ−４などのフレーム間予測を行うタイプの符号化形式であった場合、符号化データのまとまりであるGOV（Group of VOP , VOP : Video Object Planes）毎にチャンクを一般的に形成する。よって、Track_Fragment_Run_BOX（'trun'）が１つのMovie_Fragment_BOX（'moof'）３１２内にいくつ存在するかは、１データブロックの時間と１チャンクあたりの時間によって確定される。
【０１０２】
また、Track_Fragment_Run_BOX（'trun'）は、そのチャンクに格納されているサンプル数を保持し、オプションとして、サンプル毎のdurationやサイズなどを設定可能である。このオプションの設定に関しては同一ファイル中では、該当するチャンクのサンプル数に依存してBOXのサイズは可変となるが、チャンク毎の時間は通常一定になっている。このため、映像データのフレームレートや音声データのサンプリングレートなどのデータレートが一定であれば、チャンク内のサンプル数も同一トラックID間では一定になる。そして、１データブロック中のサンプル数は１データブロックあたりの時間とメディアトラック毎のデータレートによって確定される。
【０１０３】
よって、Track_Fragment_Run_BOX（'trun'）のデータブロックあたりの個数は、トラック毎に"１フラグメントあたりの時間／１チャンクあたりの時間"で求めることができる。また、１チャンク当たりのサンプル数は"１データブロックの時間／メディアトラック毎のデータレート"で求まる。
【０１０４】
ＩＳＯ／ＩＥＣ １４４９６−１２によると、Track_Fragment_Run_BOX（'trun'）は下記のように定義されている。このため、例えばこのBOXのオプションとして、data_offset、first_sample_flags、サンプル毎に設定されるパラメータのオプションは、sample_duration、sample_size、を設定したとする。すると、このＢＯＸのサイズは『ＢＯＸの数 × ２４バイト ＋ １チャンク当たりのサンプル数 × ８バイト』で求めることができる。
【０１０５】
また、Track_Fragment_Header_BOX（'tfhd'）と同様、下記tr_flagsの設定により、どのオプション・フィールドが有効なのかを判断することができる。
aligned(8) class TrackRunBox
extends FullBox('trun', 0, tr_flags) {
unsigned int(32)                sample_count;
// the following are optional fields
signed int(32)          data_offset;
unsigned int(32)                first_sample_flags;
// all fields in the following array are optional
{
unsigned int(32)      sample_duration;
unsigned int(32)      sample_size;
unsigned int(32)      sample_flags
unsigned int(32)      sample_composition_time_offset;
}[ sample_count ]
}
【０１０６】
以上のことから、Movie_Fragment_BOX（'moof'）３１２のサイズの概算値は、上述したMovie_Fragment_BOX（'moof'）３１２に含まれる各BOXのサイズを総計することで求めることができる。また、フラグメントのデータ（'mdat'）部分の概算値は、最初のヘッダ（'moov'）に対応するデータ（'mdat'）と同様にビットレートと、このデータブロックの時間（Duration）から概算することができる。
【０１０７】
このように算出されたフラグメントのヘッダ（'moof'）とデータ（'mdat'）の概算値および先に説明したフラグメントの数から、すべてのフラグメント部分のデータ長の概算を行うことができる。もちろん、これまで説明してきたようなビットレートと時間からの算出ではなく、あらかじめ、それぞれのデータブロックの目標サイズが決められている。そして、この目標サイズからビットレートを決定し、符号化を行う符号圧縮回路２０９に対して符号化パラメータを設定するようにしてもよい。
【０１０８】
次に、終了条件見積もり処理（ステップＳ５０７）の詳細について説明する。これまで説明してきたように、通信データ長の算出処理（ステップＳ５０３）によりあらかじめ算出された通信データ長は、終了条件見積もり処理（ステップＳ５０７）において、実際に送出された通信データ５４３のデータ長と比較される。
【０１０９】
終了条件見積もり処理（ステップＳ５０７）では、データ出力１処理（ステップＳ５０６）やデータ出力２処理（ステップＳ５１０）において実際に出力された通信データ５４３のデータ長の積算値と、次に出力されるフラグメントのデータブロック長の予想サイズとの和が、あらかじめ算出された通信データ長より大きいかどうかの判断を行う。もし、大きいと判断されれば、終了条件を満たすことになり、小さいと判断されれば、終了条件を満たさないことになる。
【０１１０】
ここで、次に出力されるフラグメントのデータブロック長の予想サイズとは、通信データ長の算出処理（ステップＳ５０３）で算出されたひとつのフラグメントのデータブロック長にほかならない。
【０１１１】
ここで、あらかじめ計算された予想サイズを実際に出力されるデータのサイズが上回る可能性があるため、あらかじめ計算された予想サイズを補正してもよい。すなわち、これまで実際に出力されたフラグメントのデータサイズと予想サイズの最大の差異を加えて比較してもよいし、あらかじめ設定済みの誤差を加えて比較してもよい。
【０１１２】
設定済みの誤差を加える場合には、データ出力１処理（ステップＳ５０６）やデータ出力２処理（ステップＳ５１０）において実際に出力された通信データ５４３のデータ長の積算値と次に出力されるフラグメントのデータブロック長の予想サイズの和に設定済みの誤差の値を加える。そして、これがあらかじめ算出された通信データ長より大きいかどうかの判断を行う。
【０１１３】
次に、ｆｒｅｅデータブロック生成処理（ステップＳ５１１）について説明する。
ｆｒｅｅデータブロック生成処理（ステップＳ５１１）で生成されたデータブロックは、最後のフラグメント（条件によっては、データ出力１処理（ステップＳ５０６）の出力データ）の直後に出力される。
【０１１４】
生成されるデータは、ＭＰ４においては、ｆｒｅｅＢｏｘまたはｓｋｉｐＢｏｘなどと呼ばれるそれ自体は特に意味を持たないデータである。この詳細については、ＭＰ４の規格に定義されているため詳しく述べないが、そのデータ長については説明を加えておく。
【０１１５】
ｆｒｅｅデータブロック生成処理（ステップＳ５１１）で生成されたデータブロックのサイズは、通信データ長の算出処理（ステップＳ５０３）において算出されたデータ長から、これまでに実際に出力されたデータ長を差し引いたものである。もし、ｆｒｅｅＢｏｘを用いるのであれば、その定義に従い、ｆｒｅｅ Ｂｏｘのデータ長と４バイトのｆｒｅｅ Ｂｏｘを示す識別子を含めたサイズがこのデータブロックのサイズとなるようにする。このようにすることにより、通信データ長の算出処理（ステップＳ５０３）において算出されたデータ長と実際に出力されるデータ長を完全に一致させることができる。
【０１１６】
図５を用いたフローチャートに関する説明の最後に、生成されるＨＴＴＰヘッダについて説明を加える。図６は、先に説明した、通信データ５４３の全体像を示す模式図である。
図６において、通信データ５４３は、ＨＴＴＰヘッダ６０１、これに続くＭＰ４ファイルにおける最初のヘッダ（'moov'）とデータ（'mdat'）の組み合わせからなる第１データブロック、ＭＰ４ファイルにおけるフラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせからなる２つの後続データブロック、及びｆｒｅｅデータブロックから構成される。
【０１１７】
図６に示す模式図においては、フラグメントのヘッダ（'moof'）とデータ（'mdat'）の組み合わせが２回発生しているが、説明してきたように、これは、０回以上の任意の回数発生することは言うまでもない。また、データ（'mdat'）が動画のデータを格納する部分であることをわかりやすく示すため、エンコードバッファ５３２からの矢印でこれを示している。
【０１１８】
ＨＴＴＰヘッダ６０１は、ＨＴＴＰプロトコルにおけるステータスラインとレスポンスヘッダの一例であって、必ずしもすべての標準メッセージを記載したものではないが、本実施形態において重要な項目を最小限含むものである。最初の行は、ステータスラインであり、この例では、ＨＴＴＰのリクエストに対して、ＨＴＴＰ／１．０が成功したことを示している。これにより通信クライアント１０６は、正しく処理が行われていることを知ることができる。
【０１１９】
次の行は、レスポンスヘッダの一部であり、ＨＴＴＰに従って送信されるデータのサイズを通知するものである。通信クライアント１０６は、この行により送信されてくる、すなわち受信されるデータのサイズを正確に知ることができる。ここで、送信されるデータのサイズとは、図５を参照しながら説明したフローチャートにおける通信データ長の算出処理（ステップＳ５０３）で算出されたＭＰ４のファイル長にほかならない。通信クライアント１０６は、この情報によって通信サーバー１０５のＣＧＩプログラムが見積もったファイルサイズを取得する。
【０１２０】
一方でＣＧＩプログラムはこのファイルサイズに従って適切にファイルサイズを調整することにより、あたかもあらかじめ正確にファイルとして記録蓄積された動画データを確実にダウンロード取得したかのように処理することが可能となる。
【０１２１】
３行目は、この動画データの形式を示すものである。通信サーバー１０５と通信クライアント１０６があらかじめ動画データの形式を了解しあっていない場合には、この行によって、通信クライアント１０６は、受信データの形式を知ることができる。
【０１２２】
以上のように、この方法によればＨＴＴＰ／１．１で定義される仕様が送信側または受信側、またはその双方で実装されていなくても、ＨＴＴＰ／１．０がサポートされていればライブ映像を配信して受信・再生が可能となる。また受信したデータは、フラグメント映像形式のＭＰ４ファイルとして正しいデータとなるため、コンテンツとして再利用することなども可能となる。
【０１２３】
（第２の実施形態）
第１の実施形態においては、通信プロトコルとしてＨＴＴＰを利用した実施形態を説明してきたが、本実施形態では、ＨＴＴＰ以外の通信形式にも適用可能である。例えば、第１の実施形態で示した通信サーバー１０５と通信クライアント１０６が、ＳＯＡＰ（Simple Object Access Protocol）のような端末間などで機能呼び出しを行う仕組みをもつ。そして、通信クライアント１０６から遠隔関数呼び出しによって動画データを取得する手法が技術的に確立している。
【０１２４】
ＳＯＡＰ自体は、ネットワーク経由でオブジェクト間の通信を行う軽量のプロトコルであり、それを実現する手段としてＨＴＴＰなどを利用することができる。しかしながら、ＳＯＡＰそのものには、動画データをダウンロードするといった記述の標準がないため、実際には、これを利用するアプリケーションが記述方法を定義して利用することになる。
【０１２５】
次に、ＳＯＡＰを用いたメッセージの例を以下に示す。
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<ns:getMP4>
<ns:duration>180</ns:duration>
</ns:getMP4>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
【０１２６】
この例では、「getMP4」という関数名で１８０秒間のデータを要求している。このＳＯＡＰメッセージが通信クライアント１０６から通信サーバー１０５に送信されると、通信サーバー１０５ではＣＧＩと同様にしてこの関数の処理が行われるようになっている。こうした処理の詳細な方法は、実装に依存するものであり、ＣＧＩプログラムで一般的なように別プロセスで処理されてもよいし、メッセージを受信したプログラム内で処理されてもよい。
【０１２７】
このようにして呼び出された関数は、第１の実施形態で図５を用いて示した通信データ長の算出処理（ステップＳ５０３）と同様にして通信データ長の算出を行う。ＳＯＡＰによる処理の結果の一例を以下に示す。
<SOAP-ENV:Envelope>
<SOAP-ENV:Body>
<ns:getMP4Response>
<ns:length>45000000</ns:length>
<ns:source>（データ）</ns:source>
</ns1:getMP4Response>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
【０１２８】
通信クライアント１０６に返された結果は、この例では、「ns:length」で与えられたデータ長と「ns:source」で与えられた実際の動画データである。ここで注目すべき事は、データ長と実際の動画データが、第１の実施形態で図５を用いて示したフローチャートとまったく同様に扱われている点である。
【０１２９】
このように、本実施形態は、ＨＴＴＰ以外の通信形式にも適用可能となっている。また、この例では、動画データをＳＯＡＰメッセージの一部として処理しているが、送信データのエンコーディング上の制約などから、代わりに、動画データの取得のためのプロトコルとアクセス方法を返しても、本発明の技術的背景になんら差異がない。
【０１３０】
（本発明に係る他の実施形態）
本発明は、ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ形式または同様の動画などのメディアデータに加えてその管理情報を時間に沿ってインターリーブする形式であれば適用可能である。このようなファイル形式として、ＡＶＣファイル（MPEG-4 Advanced Video Codingファイル）やＭｏｔｉｏｎ−ＪＰＥＧ ２０００ファイルなどにも適用できる。これらのファイル形式は、すべてＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ形式とその根本的な形式が同一であり、実質的に同等であると考えることができる。
【０１３１】
前述した本発明の実施形態における動画像データ配信装置を構成する各手段、並びに動画像データ配信装置の制御方法の各工程は、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。
【０１３２】
また、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【０１３３】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図５に示すフローチャートに対応したプログラム）を、システムまたは装置に直接、または遠隔から供給する。そして、そのシステムまたは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【０１３４】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【０１３５】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【０１３６】
プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスクなどがある。さらに、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などもある。
【０１３７】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する方法がある。そして、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。
【０１３８】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【０１３９】
また、その他の方法として、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記録媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１４０】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。さらに、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【０１４１】
さらに、その他の方法として、まず記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。そして、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【０１４２】
【図１】本発明の第１の実施形態におけるシステム構成例を示す概念図である。
【図２】本発明の第１の実施形態に係るネットワークカメラ１０１の内部構成及び再生装置１０２の内部構成の一例を示すブロック図である。
【図３】本発明の第１の実施形態において、フラグメント映像形式を含むＭＰ４ファイル形式についてのデータ構造の一例を示す概念図である。
【図４】本発明の第１の実施形態において、ＵＲＬの一例を示す図である。
【図５】本発明の第１の実施形態において、ＣＧＩプログラムの動作の一例を示すフローチャートである。
【図６】本発明の第１の実施形態において、通信データの全体像を示す図である。
【符号の説明】
【０１４３】
１０１  ネットワークカメラ
１０２  再生装置
１０３  動画像生成モジュール
１０４  通信データ生成モジュール
１０５  通信サーバー
１０６  通信クライアント
１０７  動画像表示モジュール
２０１  撮影レンズユニット
２０２  撮影レンズユニット駆動回路
２０３  絞りユニット
２０４  絞りユニット駆動回路
２０５  光学センサ
２０６  光学センサ駆動回路
２０７  Ａ／Ｄコンバータ
２０８  画像信号処理回路
２０９  符号圧縮回路
２１０  メモリ
２１１  ネットワークコントローラ
２１２  通信回路
２１３  ＲＯＭ
２１４  ＣＰＵ
２２１  通信回路
２２２  ネットワークコントローラ
２２３  符号伸張回路
２２４  画像信号処理回路
２２５  Ａ／Ｄコンバータ
２２６  表示装置
２２７  表示装置駆動回路
２２８  記録装置
２２９  Ｉ／Ｏコントローラ
【図１】
2007324722.tif 000003
【図２】
2007324722.tif 000004
【図３】
2007324722.tif 000005
【図４】
2007324722.tif 000006
【図５】
2007324722.tif 000007
【図６】
2007324722.tif 000008