(57)【要約】【課題】  データ転送プロトコルを用いたメディアデータ配信を、データトラフィック及び配信元のデータ処理負荷を低減しながら実現する。【解決手段】  例えばISO Base Media File Formatにおけるフラグメント映像形式（Fragmented Movie）のメディアデータを、ＨＴＴＰなどのデータ転送プロトコルで送信する際、ネットワークカメラ１００からは共通のデータを出力する。そして、中間サーバ１０１で、配信先の再生装置１０２に応じてヘッダ情報を変更して個々の再生装置１０２に配信するためのデータを生成する。【選択図】  図１
2007173987.tif 000002
【特許請求の範囲】
【請求項１】
映像データと音声データの少なくとも１つを含むメディアデータを、通信可能に接続された受信端末装置に配信するためのデータ配信装置であって、
前記受信端末装置に関する情報である受信端末装置情報を管理する情報管理手段と、
予め定められた単位で分割されたメディアデータと、当該メディアデータに対応する第１及び第２の付加データとを受信する受信手段と、
配信先の受信端末装置に対応する前記受信端末装置情報に基づいて、前記第１及び第２の付加情報の一方と、前記分割されたメディアデータとから、前記配信先の受信端末装置用の配信データを生成する配信データ生成手段と、
前記配信データを対応する受信端末装置へ送信する送信手段とを有し、
前記配信データ生成手段が、前記第１の付加情報を用いる場合には、前記第１の付加情報、対応する前記メディアデータとから前記配信データを生成し、前記第２の付加情報を用いる場合には、前記第２の付加情報を、前記配信先の受信端末装置に対応する前記受信端末装置情報に基づいて変更した変更後の前記第２の付加情報と、対応する前記メディアデータとから前記配信データを生成することを特徴とするデータ配信装置。
【請求項２】
前記データ生成手段が、前記配信先の受信端末装置に最初に送信する配信データを生成する場合には前記第１の付加情報を用い、その後は前記第２の付加情報を用いて前記配信データを生成することを特徴とする請求項１記載のデータ配信装置。
【請求項３】
前記受信端末装置が複数存在する場合、前記変更後の前記第２の付加情報が前記受信端末装置毎に異なり、対応する前記メディアデータは共通であることを特徴とする請求項１又は請求項２記載のデータ配信装置。
【請求項４】
前記第１及び第２の付加情報が、異なる種類のヘッダ情報であることを特徴とする請求項１乃至請求項３のいずれか１項に記載のデータ配信装置。
【請求項５】
さらに、前記メディアデータを取得する手段と、
前記メディアデータを前記予め定められた単位で分割する分割手段と、
前記分割したメディアデータに対応する前記第１及び第２の付加情報を生成する付加情報生成手段とを有し、
前記受信手段が、前記負荷情報生成手段から、前記分割したメディアデータと、前記第１及び第２の付加情報を受信することを特徴とする請求項１乃至請求項４のいずれか１項記載のデータ配信装置。
【請求項６】
映像データと音声データの少なくとも１つを含むメディアデータを、受信端末装置に配信するためのデータに変換して出力するデータ出力装置であって、
前記メディアデータを取得する取得手段と、
前記メディアデータを予め定めた単位で分割する分割手段と、
前記受信端末装置に関する情報を記憶する記憶手段と、
前記分割したメディアデータに対応する第１及び第２の付加情報を生成する付加情報生成手段と、
前記分割したメディアデータと、前記第１及び第２の付加情報を前記受信端末装置に配信するためのデータとして送信する送信手段とを有し、
前記付加情報生成手段が、１つの前記分割したメディアデータに対し、１つの前記第１の付加情報と前記受信端末毎の前記第２の付加手段を生成し、前記第２の付加手段を前記受信端末装置に関する情報を用いて生成することを特徴とするデータ出力装置。
【請求項７】
映像データと音声データの少なくとも１つを含むメディアデータを、通信可能に接続された受信端末装置に配信するためのデータ配信装置であって、
前記受信端末装置に関する情報である受信端末装置情報を管理する情報管理手段と、
予め定められた単位で分割されたメディアデータと、当該メディアデータに対応する付加情報であって、１つの第１の付加情報と、前記受信端末毎の第２の付加データとを受信する受信手段と、
配信先の受信端末装置に対応する前記受信端末装置情報に基づいて、前記第１及び第２の付加情報の一方と、前記分割されたメディアデータとから、前記配信先の受信端末装置用の配信データを生成する配信データ生成手段と、
前記配信データを対応する受信端末装置へ送信する送信手段とを有し、
前記配信データ生成手段が、前記第１の付加情報を用いる場合には、前記第１の付加情報、前記分割されたメディアデータとから前記配信データを生成し、前記第２の付加情報を用いる場合には、前記第２の付加情報のうち、前記配信先の受信端末装置に対応するものと、前記分割されたメディアデータとから前記配信データを生成することを特徴とするデータ配信装置。
【請求項８】
請求項６記載のデータ出力装置と、請求項７記載のデータ配信装置とが通信可能に接続され、前記受信手段が、前記データ装置から前記分割されたメディアデータと前記付加情報とを受信することを特徴とするデータ配信システム。
【請求項９】
コンピュータを、請求項１乃至請求項５又は請求項７のいずれか１項に記載のデータ配信装置として機能させるプログラム。
【請求項１０】
請求項９記載のプログラムを格納したコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディアデータの比較的広域な送受信技術に関するもので、より詳細には、ファイルの転送に適したプロトコルによるマルチキャスト的なデータ配信に関するものである。
【背景技術】
【０００２】
近年、防犯目的の監視や遠隔地の様子の確認などを目的とした、いわゆる監視カメラが普及しつつある。監視カメラなどの撮像装置が撮像した映像や音声をリアルタイムで配信（以下、ライブ映像配信とする）する際に用いられるプロトコルとして、ＲＴＰ（A Transport Protocol for Real-Time Applications）が一般的に用いられている。ＲＴＰは、ＩＥＴＦ(Internet Engineering Task Force)によりＲＦＣ１８８９及びＲＦＣ１８９０として規格化された、オーディオデータやビデオデータなどをリアルタイムで転送するためのプロトコルである。
【０００３】
しかしながら、ＲＴＰを用いたライブ映像配信においては、配信先のクライアントの手前にファイヤーウォールが設定されていると配信ができない場合がある。また、リアルタイム性を重視したプロトコルであるため、ライブ映像や音声を格納するデータパケットの欠落が発生する場合があるといった課題が存在する。そのため、より単純なＨＴＴＰ（HyperText Transfer Protocol）などのプロトコルを用いたライブ映像配信が検討されてきた。
【０００４】
従来、このような実時間処理に適したファイル記録形式としては、ISO Base Media File Formatにおけるフラグメント映像形式（Fragmented Movie）がある。
フラグメント映像形式では、動画データの全体にかかわるデータと、ある基準で分割された動画データ（分割動画データ）に対応するメタデータをファイルの先頭に記述し、その後に、メタデータに対応する分割動画データを記録する。そして、以下同様に、分割動画データのメタデータと、対応する分割動画データを、時系列に従って順次記録していく。尚、動画データを分割する基準としては、一定の時間が良く用いられる。
【０００５】
このように、フラグメント映像形式では、１つの分割動画データとそのメタデータとの組み合わせを、ひとかたまりとして取り扱うことが可能である。このような形式で記録することにより、撮像された動画データをある一定の条件により断片化して随時記録する事が可能となる。そのため、断片化した動画データ（すなわち、分割動画データ）を連続してファイル転送して、ライブ映像配信を実現することが検討されている。
【０００６】
また、ＨＴＴＰなどの、ファイル転送に適したプロトコルでは、その性質上、転送されるデータサイズをあらかじめ受信側に通知する必要がある。そのため、このような仕様に対応する仕組みも考えられてきている。
【０００７】
ライブ映像配信においては、最終的に送信すべきデータサイズを、データ送信前に確定することは出来ない。そのため、分割画像データ毎に送信することで、データ送信時にデータサイズを受信側へ通知することが可能になり、ＨＴＴＰなど事前にデータサイズの通知が必要なプロトコルを利用することが可能になる。
【０００８】
あるいは、受信側から送信側に対して送信要求サイズを通知し、送信側では要求されたサイズの分割画像データを送信することによって、同様の仕組みを実現する事も提案されている（特許文献１）。これは、ＨＴＴＰに定義されるＲａｎｇｅ機能を用いて、通信接続を維持したまま、受信側からデータの一部を順次取得することにより、分割受信をするものである。
【０００９】
【特許文献１】特開２００５−２７０１０号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
ところで、ＲＴＰを用いて多数の相手に対して同一の映像配信を行なう場合、一般にマルチキャストという配信方法が用いられる。マルチキャストとは、一つのパケットを特定の多数に送信するための技術であり、マルチキャストが指定されたパケットは、途中の適切なルータによって複製され、各受信端末に送信される。送信元でデータを複製する必要がないため、データトラフィックと送信元のデータ処理負荷の低減が可能になるという利点がある。
【００１１】
一方、前述のフラグメント映像形式を利用し、ＨＴＴＰ等を用いて行う映像配信は、ファイヤーウォールの先にあるクライアントへ送信する場合や、データパケットの欠落を特に嫌う用途などに使用される。しかし、この方法は基本的には動画ファイルの分割転送であり、特にライブ映像配信の場合は、映像データの受信を開始したタイミングによって、映像データに挿入されているメタデータの一部が変化する。そのため、どの相手に対しても同一のデータを配信する、マルチキャストによる映像配信とは異なる。
【００１２】
本発明は以上の問題に鑑みて成されたものであり、データ転送プロトコルを用いたメディアデータ配信を、データトラフィック及び配信元のデータ処理負荷を低減しながら実現することを目的とする。
【課題を解決するための手段】
【００１３】
上述の目的は、映像データと音声データの少なくとも１つを含むメディアデータを、通信可能に接続された受信端末装置に配信するためのデータ配信装置であって、受信端末装置に関する情報である受信端末装置情報を管理する情報管理手段と、予め定められた単位で分割されたメディアデータと、当メディアデータに対応する第１及び第２の付加データとを受信する受信手段と、配信先の受信端末装置に対応する受信端末装置情報に基づいて、第１及び第２の付加情報の一方と、分割されたメディアデータとから、配信先の受信端末装置用の配信データを生成する配信データ生成手段と、配信データを対応する受信端末装置へ送信する送信手段とを有し、配信データ生成手段が、第１の付加情報を用いる場合には、第１の付加情報、対応するメディアデータとから配信データを生成し、第２の付加情報を用いる場合には、第２の付加情報を、配信先の受信端末装置に対応する受信端末装置情報に基づいて変更した変更後の第２の付加情報と、対応するメディアデータとから配信データを生成することを特徴とするデータ配信装置によって達成される。
【００１４】
また、上述の目的は、映像データと音声データの少なくとも１つを含むメディアデータを、受信端末装置に配信するためのデータに変換して出力するデータ出力装置であって、メディアデータを取得する取得手段と、メディアデータを予め定めた単位で分割する分割手段と、受信端末装置に関する情報を記憶する記憶手段と、分割したメディアデータに対応する第１及び第２の付加情報を生成する付加情報生成手段と、分割したメディアデータと、第１及び第２の付加情報を受信端末装置に配信するためのデータとして送信する送信手段とを有し、付加情報生成手段が、１つの分割したメディアデータに対し、１つの第１の付加情報と受信端末毎の第２の付加手段を生成し、第２の付加手段を受信端末装置に関する情報を用いて生成することを特徴とするデータ出力装置によっても達成される。
【００１５】
また、上述の目的は、映像データと音声データの少なくとも１つを含むメディアデータを、通信可能に接続された受信端末装置に配信するためのデータ配信装置であって、受信端末装置に関する情報である受信端末装置情報を管理する情報管理手段と、予め定められた単位で分割されたメディアデータと、当メディアデータに対応する付加情報であって、１つの第１の付加情報と、受信端末毎の第２の付加データとを受信する受信手段と、配信先の受信端末装置に対応する受信端末装置情報に基づいて、第１及び第２の付加情報の一方と、分割されたメディアデータとから、配信先の受信端末装置用の配信データを生成する配信データ生成手段と、配信データを対応する受信端末装置へ送信する送信手段とを有し、配信データ生成手段が、第１の付加情報を用いる場合には、第１の付加情報、分割されたメディアデータとから配信データを生成し、第２の付加情報を用いる場合には、第２の付加情報のうち、配信先の受信端末装置に対応するものと、分割されたメディアデータとから配信データを生成することを特徴とするデータ配信装置によっても達成される。
【発明の効果】
【００１６】
このような構成により、本発明によれば、データ転送プロトコルを用いたメディアデータ配信を、データトラフィック及び配信元のデータ処理負荷を低減しながら実現することができる。
【発明を実施するための最良の形態】
【００１７】
以下、図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。
なお、以下の実施形態では、ライブ映像配信に用いるデータがＭＰ４(MPEG4)ファイル形式である場合を主眼としている。しかし、本発明はＭＰ４形式に類似した他のデータ形式によるライブ映像配信にも適用可能である。
【００１８】
このような他のデータ形式として、例えば、ＩＳＯではＭＰ４形式と同様の基本構造を持つ「Ｍｏｔｉｏｎ ＪＰＥＧ ２０００ファイル形式」（ISO/IEC 15444-3）や、「ＡＶＣファイル形式」（ISO/IEC 14496-15）を規格化している。また、第三世代携帯電話を中心とする無線端末上での利用を前提に制約が課せられた動画ファイル規格（３ＧＰＰ形式や３ＧＰＰ２形式など）もある。このように、ＭＰ４形式と類似のファイル形式およびアーキテクチャが採用されている他の規格に対しても、本発明の一部あるいは全部を適用することが可能である。
【００１９】
（第１の実施形態）
本実施形態は、通信機能を有したネットワークカメラから中間サーバを介して再生装置にコンテンツデータを配信するデータ配信システムに本発明を適用した例である。
【００２０】
図１は、本実施形態に係るデータ配信システムの機能構成例を示すブロック図である。
本実施形態のデータ配信システムは、映像データと音声データの少なくとも１つを含むメディアデータを予め定めた単位毎に分割し、付加情報を付加してブロック化した形式で、再生装置に対してリアルタイム配信するデータ配信システムである。
【００２１】
システムは、通信機能を有するネットワークカメラ１００と、いわゆる代理サーバのような機能を有する中間サーバ１０１と、コンテンツデータの再生処理機能を有する再生装置１０２で構成されている。
【００２２】
ネットワークカメラ１００は、メディアデータを取得して、データ配信用の形式に変換して出力するデータ出力装置として機能する。具体的には例えば通信機能を備えた撮像装置であり、近年、監視用途などで用いられるビデオカメラである。また、データ配信装置として機能する中間サーバ１０１は、通信データのキャッシュ機能を備えた代理サーバであり、一般にプロクシサーバ（又はプロキシサーバ）と呼ばれる。受信端末装置の一例としての再生装置１０２は、ネットワーク通信機能を備えた、動画像の再生を行う装置である。ここでは受信したメディアデータを再生する受信端末を例示しているが、再生機能は必須ではない。
【００２３】
装置例えばＰＣ（パーソナルコンピュータ）上でアプリケーション・プログラムを動作させて実現されている場合もあれば、専用のディスプレイを備えた監視装置の一部として実現される場合もある。
【００２４】
ネットワークカメラ１００において、映像／音声入力部１０３は、所謂ビデオカメラであり、映像及び音声データをキャプチャし、デジタルデータとして出力する。映像／音声データ符号化部１０４は、キャプチャしたデータを、予め定めた単位で（例えば一定時間毎に）分割し、この単位毎に符号化する。また、管理情報生成部１０５は、符号化された映像／音声データ（符号化映像／音声データ）に対応した付加情報としての管理情報を生成する。マスターデータ配信部１０６は、符号化映像／音声データと管理情報（この２つのデータをあわせてマスターデータと呼ぶ）を中間サーバ１０１に配信する。
【００２５】
ネットワークカメラ１００からのマスターデータの配信先となる中間サーバ１０１は複数あっても良い。中間サーバ１０１複数ある場合、ネットワークカメラ１００は、どの中間サーバ１０１に対しても同じマスターデータを配信する。
【００２６】
中間サーバ１０１において、マスターデータ受信部１０７は、ネットワークカメラ１００から配信されるマスターデータを受信する。再生装置情報管理部１１２は、中間サーバ１０１に接続している再生装置１０２の接続情報を保持・管理する。コンテンツデータ生成部１０８は、受信したマスターデータ（符号化映像／音声データと管理情報）と、再生装置情報管理部１１２で保持されている再生装置の接続情報から再生装置１０２での再生処理が可能なコンテンツデータを生成する。コンテンツデータ配信部１０９は、コンテンツデータ生成部１０８が生成したコンテンツデータを、再生装置１０２へ配信する。
【００２７】
再生装置１０２は、中間サーバ１０１と同様に複数あっても良く、尚且つその数は動的に変動しても良い。但し、再生装置１０２が複数ある場合、必要に応じ、再生装置１０２に応じてコンテンツデータ生成部１０８においてデータの一部を書き換えるため、再生装置１０２全てに同じコンテンツデータが配信されるとは限らない。また、再生装置情報管理部１１２では、接続している再生装置１０２の数の増減を検出し、再生装置１０２全ての最新情報を常に管理する。
【００２８】
再生装置１０２は、中間サーバ１０１からコンテンツデータを受信するコンテンツデータ受信部１１０と、コンテンツデータに含まれている符号化映像及び音声データを復号化して表示装置に表示するコンテンツデータ再生処理部１１１から構成される。
【００２９】
次に、図１の構成を有するシステムの一般的な処理の流れを説明する。
まず始めに、再生装置１０２を操作する利用者は、プロクシサーバとして中間サーバ１０１を設定し、更にネットワークカメラ１００からの符号化映像／音声データを取得するよう指示を行う。具体的には、例えばＧＵＩ(Graphical User Interface)を用いてネットワークカメラ１００や中間サーバ１０１のＵＲＬ（Uniform Resource Locator）を入力して指示を行うことができる。或いは、あらかじめ再生装置１０２に通信接続の定義をしておき、その定義を用いて通信を開始するための指示をスイッチの押下などにより指示してもよい。
【００３０】
この時、ネットワークカメラ１００、中間サーバ１０１、再生装置１０２の間のデータ取得に必要な情報は、データ転送プロトコルの一例としてのＨＴＴＰを用いて各機器を接続するネットワークを介してやりとりされる。そして、ネットワークカメラ１００の管理情報生成部１０５では、受信した指示に応答して、符号化映像／音声データに対応した管理情報をフラグメント映像形式に準拠した形で生成する。そして、マスターデータ配信部１０６が、符号化映像／音声データと、対応管理情報とをマスターデータとして中間サーバ１０１に配信する。中間サーバ１０１に配信されたマスターデータは、コンテンツデータ生成部１０８において、フラグメント映像形式のデータ構造に変換され、再生装置１０２に配信される。
【００３１】
ここで、フラグメント映像形式のデータ構造について図を用いて説明する。
図２はフラグメント映像形式を含むＭＰ４ファイル形式のデータ構造を説明するための図である。
ＭＰ４ファイル形式では、ファイルに記録されるデータは「ＢＯＸ」と呼ばれるデータ構造の内部に記述され、ＢＯＸを単位としてファイルに記録される。またＭＰ４ファイル形式では、コンテンツ全体のプレゼンテーションを「ムービー」、コンテンツを構成するメディアストリームのプレゼンテーションを「トラック」と呼ぶ。
【００３２】
最初のヘッダである「Movie_BOX」（'moov'）２０２には、典型的には、映像／音声データ全体を論理的に取り扱うビデオトラック２０３と、音声のデータ全体を論理的に取り扱うオーディオトラック２０７が含まれている。また、ビデオトラック２０３とオーディオトラック２０７の基本的な構成内容は、ほとんど同等である。すなわち、ビデオトラック２０３とオーディオトラック２０７は、いずれも実際のメディアデータの様々な属性情報を記録しており、その内容がメディアデータの特性に応じて多少異なっているだけである。
【００３３】
ビデオトラック２０３に含まれるデータは、例えば、符号化データを復号化するためのデコーダの構成情報や動画像の矩形サイズなどの情報が含まれる。代表的なものを説明すると、オフセット２０４は、メディアデータが実際に記録されているファイル上の位置を示す。サンプルサイズ２０５は、メディアデータのそれぞれのフレームデータ（サンプル、或いは映像データの場合ピクチャと呼ばれることもある）のサイズを示す。タイムスタンプ２０６は、それぞれのフレームデータのデコード時間及びプレゼンテーション時間を示す。
【００３４】
ＭＰ４ファイル２０１の全体の構成としては、映像及び音声データの物理的位置、時間的位置や特性情報などを示すヘッダ情報（メタデータ）部分と、符号化映像・音声データの実体であるメディアデータ部分から構成される。
【００３５】
図２では、フラグメント映像形式独自のＢＯＸを含んだＭＰ４ファイルの構造を示している。フラグメント映像形式の構造を持たないＭＰ４ファイルでは、「Movie_BOX」（'moov'）２０２内に、フラグメント映像形式による拡張部分の情報を示す「Movie_Extends_BOX」（'mvex'）２０８が含まれない。つまり、'mvex'２０８を含まない'moov'２０２と、それに対応するメディアデータ部である「Media_Data_BOX」（'mdat'）２１１のみによって構成される。
【００３６】
一方、フラグメント映像形式のＭＰ４ファイルでは、コンテンツのヘッダ情報およびメディアデータを任意の時間単位でフラグメントに分割することができ、分割されたフラグメントはファイルの先頭から時系列順に記録される。この時、コンテンツ全体の属性情報を含む先頭の「Movie_BOX」（'moov'）２０２には、図２に示すように、フラグメント部分を含む全体の再生時間（duration）などの情報を格納する「Movie_Extends_BOX」（'mvex'）２０８が配置される。mvex２０８は、後に続く「Media_Data_BOX」（'mdat'）２１１に含まれるデータに関する情報を保持する。
【００３７】
次に出現する「Movie_Fragment_BOX」（'moof'）２１２は、フラグメント部分のヘッダ情報であり、「Media_Data_BOX」（'mdat'）２１３に含まれるデータに関する情報を保持する。以降同様に「Movie_Fragment_BOX」（'moof'）２１２と「Media_Data_BOX」（'mdat'）２１３の組み合わせ（フラグメント）が追加されていく形で構成される。
【００３８】
フラグメント映像形式のＭＰ４ファイルでは、前述のように「Movie_BOX」（'moov'）２０２の中にフラグメント映像形式による拡張情報を格納している「Movie_Extends_BOX」（'mvex'）２０８が存在する。「Movie_Extends_BOX」（'mvex'）２０８には、フラグメント部分を含めたムービー全体の再生時間（duration）２０９や、フラグメント部分に含まれるメディアデータのサンプルサイズやサンプル毎のdurationなどのデフォルト値などの情報２１０を設定できる。ここにデフォルト値を設定することによって、後に続く「Movie_Fragment_BOX」（'moof'）２１２内のサンプル情報では、デフォルト値を使用する場合、サンプル毎の値の設定を省略することができる。
【００３９】
このようにフラグメント映像形式では、メタデータとそれに対応するメディアデータの組み合わせを１つのブロックとして、複数のブロックが時系列順に連結したファイル構造とすることが出来る。よって、このファイル形式を利用すれば、ある単位時間毎（又はある単位サイズ毎）に「メタデータとそれに対応するメディアデータのブロック」を生成し、随時配信することにより、一般的なデータ転送プロトコルを用いたライブ映像配信が実現できる。このような映像配信方法を、以下、フラグメント配信と呼ぶ。
【００４０】
図１の管理情報生成部１０５において生成する管理情報は、図２における「Movie_BOX」（'moov'）２０２と「Movie_Fragment_BOX」（'moof'）２１２の２つの管理情報（ヘッダ情報）である。通常、ＭＰ４ファイルでは、同一の符号化データに対して２種類の管理情報を必要としない。しかし、本実施形態では、複数の再生装置１０２に対応したコンテンツデータを生成するため、映像／音声データ符号化部１０４において符号化された同一の映像／音声符号化データに対して２種類の管理情報が生成される。
【００４１】
ライブ映像配信時のデータの流れを、図８を用いてより詳細に説明する。
図８は、ネットワークカメラ１００内の映像／音声データ符号化部１０４からマスターデータ配信部１０６までのデータ処理を模式的に示した図である。
【００４２】
映像／音声データ符号化部１０４では、Video符号化器１０４１とAudio符号化器１０４２により、映像／音声入力部１０３が出力する映像／音声データを符号化する。符号化結果は、Video Data Buffer１０４３とAudio Data Buffer１０４４に随時保管していく。管理情報生成部１０５のＡ／Ｖデータ多重化処理部１０５１は、これらのバッファに保管された符号化映像データと符号化音声データとを必要に応じて特定の条件でインターリーブさせた符号化映像／音声データを生成する。符号化映像／音声データは、マスターデータ配信部１０６内の送信用バッファAudio / Video Data Buffer１０６１に格納する。
【００４３】
また、送信用バッファAudio / Video Data Buffer１０６１に格納した符号化データは、図２の「Media_Data_BOX」（'mdat'）２１１或いは２１３に対応している。そして、このデータに対応した「Movie_BOX」（'moov'）２０２と「Movie_Fragment_BOX」（'moof'）２１２の２つの管理情報を管理情報生成部１０５内で生成する。そして、マスターデータ配信部１０６内の送信用バッファmoov Buffer１０６２とmoof Buffer１０６３にそれぞれ格納する。
【００４４】
そして、マスターデータ配信部１０６は、送信バッファ１０６１〜１０６３に格納されたデータをまとめてマスターデータとして配信する。つまり、中間サーバ１０１のマスターデータ受信部１０７で受信されるマスターデータは、「Media_Data_BOX」（'mdat'）と「Movie_BOX」（'moov'）と「Movie_Fragment_BOX」（'moof'）の３つのデータである。そして、この３つのデータから成るマスターデータは、中間サーバ１０１が複数ある場合、全ての中間サーバに対して共通して配信される。
【００４５】
次に、マスターデータを受信した中間サーバ１０１では、マスターデータと再生装置情報管理部１１２において保持されている再生装置１０２の接続情報をもとに、コンテンツデータ生成部１０８において各再生装置１０２毎のコンテンツデータを生成する。
【００４６】
ここで、フラグメント配信において、複数の再生装置１０２の情報を管理する為の仕組みと、個々の再生装置１０２に適したコンテンツデータを生成する方法について説明する。
図３は、中間サーバ１０１内で複数の再生装置１０２の情報を管理し、個々の再生装置１０２に適したコンテンツデータを生成・配信する処理を説明するフローチャートである。
【００４７】
まず、ある１つの中間サーバ１０１に既に接続している複数の再生装置１０２には、再生装置毎の接続状態を管理するために、個別のＩＤが割り当てられている。そして最初にステップＳ３０１において、既に接続している再生装置が取り外されたか電源ＯＦＦされたか等により切断されたか否かを判断する。切断されている場合はステップＳ３０２において、対応するＩＤのデータを初期化し再利用可能な状態にする。
【００４８】
次にステップＳ３０３において、再生装置１０２の接続要求があるか否かを判断する。接続要求がある場合はステップＳ３０４において、新規或いは再接続の再生装置１０２に対して管理データを識別する為のＩＤを割り当て、再生装置１０２毎の状態管理を可能にする。
【００４９】
次にステップＳ３０５において、再生装置１０２毎の接続情報を参照して、個別の再生装置１０２毎に適したコンテンツデータを生成する。ステップＳ３０６において、再生装置の情報管理として保持しているヘッダータイプの更新を行なう。これらの処理はコンテンツデータ生成部１０８内で行なわれ、処理内容の詳細については後述する。
【００５０】
続いてステップＳ３０７において、生成したコンテンツデータを再生装置１０２に配信する。
【００５１】
中間サーバ１０１では、接続されている再生装置１０２の接続情報の保持・管理のために、例えば図４に示すような再生装置接続情報を再生装置毎に保存する。図４の再生装置接続情報４００は再生装置１０２の接続状態を管理する為のデータ構造体の例であり、再生装置情報管理部１１２にて保持・管理される。
【００５２】
「ST_MOOFClient」は再生装置１０２毎の状態を管理する為のデータ構造体であり、各メンバー変数の意味は以下の通りである。
「FragHeaderType」は、今回配信するコンテンツデータに付加する管理情報のタイプを示しており、「Movie_BOX」（'moov'）２０２と「Movie_Fragment_BOX」（'moof'）２１２のどちらかを識別するために用いられる。０がmoov、１がmoofを意味する。ある再生装置１０２に対して、最初に配信するコンテンツデータには「Movie_BOX」（'moov'）が付加され、以降は「Movie_Fragment_BOX」（'moof'）が付加される。
【００５３】
「SequenceNUM」は「Movie_Fragment_BOX」（'moof'）２１２の管理情報を付加してコンテンツを生成する場合に、「Movie_Fragment_BOX」内の所定の位置に示すべき数字を示す。この数字は最初に「Movie_Fragment_BOX」の管理情報を付加したコンテンツデータを生成・配信する時に１から開始され、以降、コンテンツデータの生成・配信毎にインクリメントされる。
【００５４】
「VideoBaseOffset」と「AudioBaseOffset」は、上述の「SequenceNUM」と同様に「Movie_Fragment_BOX」内に示すべき基準オフセット値を示し、VideoトラックとAudioトラックに関して適切な値を設定する必要がある。
【００５５】
以降の３つのメンバー変数「SequenceNUMPos」と「VideoBaseOffsetPos」と「AudioBaseOffsetPos」は、それぞれ、メンバー変数「SequenceNUM」と「VideoBaseOffset」と「AudioBaseOffset」の記録位置情報である。つまり、メンバー変数「SequenceNUM」、「VideoBaseOffset」及び「AudioBaseOffset」で示された値を、「Movie_Fragment_BOX」（'moof'）２１２内のどこに記録するかを示す情報である。
【００５６】
具体的には、例えば「Movie_Fragment_BOX」（'moof'）の先頭からのオフセット位置を示す。そして、「Movie_Fragment_BOX」（'moof'）内の、メンバ変数「SequenceNUMPos」、「VideoBaseOffsetPos」及び「AudioBaseOffsetPos」が示す位置のデータをそれぞれ書き換え、各再生装置１０２に適したフラグメント配信用のコンテンツデータを生成する。
【００５７】
再生装置接続情報を構成するもう１つのデータ構造体「ST_FragComInfo」は、４つのメンバ変数を有する。
「Client ID」は、再生装置１０２の各々に割り当てられた固有のＩＤである。
「IsAlive」は、「Client ID」で特定される再生装置の接続状況（接続しているか否か）を示す。０は切断を、１は接続を表す。
【００５８】
「TrackConfig」は、トラック構成（例えば受信するオーディオ／ビデオトラックの有無）を示す。０は両トラックの存在を、１はオーディオトラックのみ、２はビデオトラックのみであることを示す。
「ST_MOOFClient」は、対応するデータ構造体「ST_MOOFClient」の先頭のアドレスを保持する。
【００５９】
このように、データ構造体「ST_FragComInfo」により、個々の再生装置１０２の状態を保持・管理することが出来る。
【００６０】
ここで、図３の処理フローにおける「FragHeaderType」に関しての処理についての説明を補足する。
フラグメント映像形式では‘moov’形式のヘッダは、前述のようにファイルの先頭（個々の再生装置１０２に最初に配信されるデータ）のみに付加され、以降は‘moof’形式のヘッダによって管理情報が保持される。そこで、図３のステップＳ３０２における管理データの初期化では、使用していないＩＤに対応する「FragHeaderType」は「Movie_BOX」（'moov'）を示す定数（本実施形態では０）を設定する。そして、ステップＳ３０６における管理データのヘッダータイプ更新では、「FragHeaderType」に「Movie_BOX」（'moov'）を示す定数（０）が設定されているものがあれば、これを「Movie_Fragment_BOX」（'moof'）を示す定数（本実施形態では１）に変更する。これにより、フラグメント映像形式として正しい形式の管理情報が付加されたコンテンツデータを生成することができる。
【００６１】
また、コンテンツデータの生成は、中間サーバ１０１内のコンテンツデータ生成部１０８で処理される。以下、コンテンツデータ生成部１０８において、マスターデータと再生装置接続情報４００をもとにフラグメント配信用のコンテンツデータを生成する処理手順について、図９に示すフローチャートを参照して説明する。
【００６２】
コンテンツデータ生成処理が開始されると、まずステップＳ９０１において、再生装置接続情報４００の「FragHeaderType」の値を参照してヘッダータイプの識別（‘moov'か‘moof’のどちらか）を行なう。
【００６３】
ヘッダータイプが‘moov’であった場合、ステップＳ９０２において、Movie_BOX（'moov'）と、分割されたメディアデータであるMedia_Data_BOX（'mdat'）を連結したデータを配信用データとして生成する。一方、ヘッダータイプが‘moof’であった場合は、まずステップＳ９０３において、再生装置接続情報４００を参照してMovie_Fragment_BOX（'moof'）内のデータの書き換えを行なう。そして、ステップＳ９０４において、内容を一部書き換えたMovie_Fragment_BOX（'moof'）と、分割されたメディアデータであるMedia_Data_BOX（'mdat'）を連結したデータを生成する。
【００６４】
続いてステップＳ９０５において、ステップＳ９０２又はステップＳ９０４において連結したデータを、フラグメント配信用のコンテンツデータとしてコンテンツデータ配信用のバッファなどに保管する。
【００６５】
最後に、ステップＳ９０６において、再生装置接続情報４００の更新を行う。すなわち、「SequenceNUM」を１インクリメントし、「VideoBaseOffset」と「AudioBaseOffset」の値を、生成したデータの大きさに基づいて更新する。
【００６６】
この一連の処理は、個々の中間サーバ１０１において、接続されている再生装置１０２の数だけ、即ち、再生装置１０２毎に割り振られた再生装置接続情報４００の「ClientID」の数だけ繰り返される。これにより、その中間サーバ１０１の管理下にある個々の再生装置１０２に対応するコンテンツデータが生成される。
【００６７】
ここで上述のステップＳ９０３におけるMovie_Fragment_BOX（'moof'）２１２内のデータの書き換え、即ち「SequenceNUM」と「VideoBaseOffset」と「AudioBaseOffset」の書き換えについて図４、及び図５を用いて詳細に説明する。
【００６８】
図５は、本実施形態における、「Movie_Fragment_BOX」（'moof'）２１２内の所定の位置に記録すべき３種類のパラメータ、シーケンスナンバーと基準オフセット（ビデオ、オーディオ）の書き換え処理の説明を行なう為の図である。
【００６９】
シーケンスナンバーは「Movie_Fragment_BOX」（'moof'）２１２内の「Movie_Fragment_Header_BOX」（'mfhd'）２１２１内の所定の位置Ｐ１に、適切な値を設定しなければならない。そして、この書き換え位置は、再生装置接続情報における、メンバ変数「SequenceNUMPos」により、また書き換える値は「SequenceNUM」により、「ClientID」毎に（すなわち、再生装置毎に）管理されている。つまり、メンバ変数「SequenceNUMPos」は図５のシーケンスナンバーポジションに、「SequenceNUM」は、シーケンスナンバーに相当する。
【００７０】
「SequenceNUM」は前述の通り、１を初期値として１づつインクリメントする値であるが、その書き換え位置「SequenceNUMPos」は、moofの先頭からの位置であるから、同様の処理シーケンスを繰り返す場合、通常は固定値となる。しかし、何らかの要因により「SequenceNUMPos」が変更される場合、この値は、マスターデータを生成するネットワークカメラ１００から提供されることが望ましい。
【００７１】
基準オフセットについてもシーケンスナンバーと同様に、「Movie_Fragment_BOX」（'moof'）２１２内の、「VideoBaseOffsetPos」と「AudioBaseOffsetPos」が指す位置Ｐ２のデータを各々「VideoBaseOffset」と「AudioBaseOffset」の値に書き換える。なお、図５ではAudioとVideoの区別はしていないが、実際にはAudioとVideoの各々に対して個別に書き換えを行う。「VideoBaseOffsetPos」と「AudioBaseOffsetPos」はそれぞれ基準オフセットポジションＰ２を指す値であり、「VideoBaseOffset」と「AudioBaseOffset」の値が、書き込まれる基準オフセットに相当する。
【００７２】
基準オフセットの値は、その再生装置に対してそれまでに配信したデータの合計（バイト数）に、今回配信する「Movie_Fragment_BOX」（'moof'）２１２のサイズを加えた値である。
【００７３】
基準オフセットポジション２種類（「VideoBaseOffsetPos」と「AudioBaseOffsetPos」）は、「SequenceNUMPos」と同様、同じ処理シーケンスを繰り返す限り、通常は固定値となる。しかし、何らかの要因（例えば、フレームレートやビットレートの動的な変更など）により、書き換え位置が変更される場合、この値は、マスターデータを生成するネットワークカメラ１００から提供されることが望ましい。
【００７４】
この様な方法により、中間サーバ１０１内のコンテンツデータ生成部１０８で、再生装置１０２毎に適したデータに書き換えられ生成されたコンテンツデータは、コンテンツデータ配信部１０９より、個々の再生装置１０２に配信される。このコンテンツデータは、各再生装置１０２内のコンテンツデータ受信部１１０で受信され、コンテンツデータ再生処理部１１１において再生処理が行なわれる。
【００７５】
受信したコンテンツデータを連結すれば、フラグメント映像形式のデータと同等である。従って、再生装置１０２は、フラグメント映像形式のデータを分割してダウンロード再生しているのと同じであり、結果として連続した一つの映像データとして再生される。
【００７６】
図６は、本実施形態における各装置間のデータの流れを模式的に示す図である。
図６において、ネットワークカメラ１００から３つの中間サーバ１０１ａ〜１０１ｃへ配信されるデータは、符号化映像／音声データと管理情報の２つのデータをあわせたマスターデータであり、全ての中間サーバに同一のマスターデータが配信される。一方、中間サーバ１０１ａから、再生装置１０２ａ−１〜１０２ａ−３に配信されるデータは、各々の再生装置毎の接続情報に基づいて部分的に改変されたコンテンツデータである。同様に、中間サーバ１０１ｂから再生装置１０２ｂ−１〜１０２ｂ−３、中間サーバ１０１ｃから再生装置１０２ｃ−１〜１０２ｃ−３へ配信されるデータも、再生装置毎に異なる。
【００７７】
本実施形態によれば、個々の再生装置に合わせたデータの生成を、中間サーバ１０１が行うようにした。そのため、ネットワークカメラ１００は、再生装置１０２の数や増減に関係なく、全ての中間サーバ１０１に共通したマスターデータを配信すればよい。
【００７８】
結果として、ネットワークカメラ１００が再生装置毎のデータを生成する場合と比較して、ネットワークカメラ１００の処理負荷が大幅に軽減される。また、ネットワークカメラ１００と中間サーバ１０１との間のネットワークトラフィックも、中間サーバ１０１の数にのみ依存するため、やはり大幅に軽減される。
【００７９】
換言すれば、本実施形態において、ネットワークカメラ１００は、再生装置毎のコンテンツデータ生成を中間サーバ１０１ａ〜１０１ｃに任せることでデータ処理負荷を分散する。
【００８０】
（第２の実施形態）
次に第２の実施形態として、第１の実施形態におけるネットワークカメラ１００の中に中間サーバ１０１の機能を取り込んだ形態について説明する。
【００８１】
図１０は、本発明の第２の実施形態に係るデータ配信システムの機能構成例を示すブロック図であり、図１と同じ構成には同じ参照数字を付してある。図１と図１０との比較から明らかなように、本実施形態においては、ネットワークカメラ７００が、第１の実施形態におけるネットワークカメラ１００と中間サーバ１０１の機能を有している。
【００８２】
そして、管理情報生成部１０５が出力する符号化映像／音声データと管理情報とを、各中間サーバ１０１のコンテンツデータ生成部１０８に直接入力する。
【００８３】
図７は、第２の実施形態に係るデータ配信システムにおける各装置間のデータの流れについて説明した図である。図７に示すように、本実施形態では、ネットワークカメラ７００内で直接、複数の再生装置１０２の状態管理を行ない、その状態管理している情報とマスターデータを基に各々の再生装置１０２に適したコンテンツデータを生成し、配信するものである。
【００８４】
本実施形態においても、ネットワークカメラ７００内では、中間サーバ１０１に相当する構成を複数用意することで、内部処理の負荷を分散することが可能である。またこの場合、中間サーバ１０１に相当するものは、１つだけでも複数あっても良く、接続している再生装置の数や内部バスのデータトラフィックの増減などに因って、適応的にその数を変化させても良い。
【００８５】
（第３の実施形態）
第１の実施形態では、マスターデータ内の管理情報のうち「Movie_Fragment_BOX」（'moof'）２１２を個別の再生装置１０２に適した内容に修正する処理は、中間サーバ１０１内のコンテンツデータ生成部で行なう構成とした。本実施形態では、この処理をネットワークカメラ内で行なう。すなわち、本実施形態では、ネットワークカメラがデータ配信装置としても機能する。
【００８６】
本実施形態にかかるデータ配信システムの機能構成は、第１の実施形態と同様、図１に示す構成でよい。ただし、ネットワークカメラ１００における管理情報生成部１０５とマスターデータ配信部１０６、中間サーバ１０１におけるマスターデータ受信部１０７とコンテンツデータ生成部１０８で処理する内容と扱うデータが若干異なる。
【００８７】
即ち、第３の実施形態では、再生装置１０２の状態を管理する再生装置接続情報４００に基づいて、「Movie_Fragment_BOX」（'moof'）２１２を個別の再生装置１０２に適した内容に修正したデータを生成する処理を管理情報生成部１０５で行なう。
【００８８】
従って、再生装置１０２が複数接続している場合、マスターデータ配信部１０６から中間サーバ１０１に配信されるマスターデータは、以下のようになる。「Media_Data_BOX」（'mdat'）、「Movie_BOX」（'moov'）及び、再生装置１０２毎に適した内容を有する複数の「Movie_Fragment_BOX」（'moof'）。つまり、管理情報生成部１０５は、第１の実施形態では一種類のmoofを生成したのに対し、本実施形態では、個々の再生装置１０２に合わせた内容のmoofを生成する。
【００８９】
中間サーバ１０１では、マスターデータ受信部１０７にてこれらのデータを受信する。そして、コンテンツデータ生成部１０８において、マスターデータに含まれるmoofと、再生装置接続情報４００とに基づいて、moov又はmoofと、 mdatを適切に組み合わせることにより、個別の再生装置１０２に対応したコンテンツデータを生成する。
【００９０】
つまり、第１の実施形態との大きな違いは、個別の再生装置１０２に適した「Movie_Fragment_BOX」（'moof'）を生成する処理をネットワークカメラ１００側で行なう点である。そして、中間サーバ１０１側では、マスターデータの内部(moof)は全く改変することなく、「Movie_BOX」（'moov'）と「Movie_Fragment_BOX」（'moof'）のどちらかと「Media_Data_BOX」（'mdat'）を適切に組み合わせることにより、個別の再生装置に適したコンテンツデータを生成することが可能となる。
【００９１】
ネットワークカメラ１００で、再生装置１０２に合わせたmoofを作成するには、ネットワークカメラ１００でも再生装置接続情報４００の情報が必要となる。そのため、中間サーバ１０１内の再生装置情報管理部１１２において保持・管理している再生装置接続情報４００をネットワークカメラ１００が利用可能とする必要がある。
【００９２】
ネットワークカメラ１００が管理情報を生成する際に逐次中間サーバ１０１にアクセスして再生装置接続情報４００を参照もしくは取得することは効率的でない。そのため、例えば、ネットワークカメラ１００は、接続している中間サーバ１０１から再生装置接続情報４００を所定のタイミングで取得し、ネットワークカメラ１００内の図示しない記憶装置に記憶する。また、その後所定のタイミングで再生装置接続情報４００の更新を行い、切断された再生装置１０２に対するmoofの作成による負荷を低減することが好ましい。
【００９３】
なお、再生装置１０２の接続状況は中間サーバ１０１が直接管理しているため、接続状況に変化があり、中間サーバ１０１が保持する再生装置接続情報４００に変化が生じた場合には、中間サーバ１０１からネットワークカメラ１００へ通知を行うようにしても良い。そして、通知に応答してネットワークカメラ１００が最新の再生装置接続情報４００を取得し、カメラ内の再生装置接続情報４００を更新する。もちろん、中間サーバ１０１からネットワークカメラ１００に対して最新の再生装置接続情報４００を送信するようにしても良い。
【００９４】
このように、本実施形態のネットワークカメラ１００は、自らが保持する再生装置接続情報４００に基づいて管理情報（moovと再生装置毎のmoof）を生成し、符号化映像／音声データ（mdat）とともにマスターデータとして中間サーバ１０１に配信する。
【００９５】
中間サーバ１０１のコンテンツデータ生成部は、マスターデータに含まれる、再生装置１０２毎の「Movie_Fragment_BOX」（'moof'）に含まれる、再生装置に固有な情報を参照する。そして、自らが保持する再生装置接続情報４００に含まれる情報と対応させ、どの再生装置に配信するコンテンツデータに使用すべきmoofであるかを識別する。
【００９６】
moofに含まれ、かつ再生装置接続情報４００に含まれる再生装置の固有情報としては、例えば基準オフセット、シーケンスナンバーの少なくともいずれか、好ましくは両方がある。これらの情報に基づいて適切なmoofを識別し、各再生装置１０２に適したコンテンツデータを生成する。なお、ヘッダタイプがmoovの場合には識別処理は不要である。
【００９７】
以上の様に第３の実施形態では、ネットワークカメラ１００から中間サーバ１０１に配信するマスターデータの内容が、
「Media_Data_BOX」（'mdat'）のデータ１つ
「Movie_BOX」（'moov'）のデータ１つ
最大で再生装置１０２の数の「Movie_Fragment_BOX」（'moof'）のデータ
となる。また、個々の再生装置に関する情報を中間サーバから取得する必要もある。
【００９８】
そのため、第１の実施形態と比較して、特に「Movie_Fragment_BOX」（'moof'）のデータを生成する手間と、中間サーバ１０１との間のトラフィックは増加する。しかし、中間サーバ１０１では、マスターデータの中身を改変する必要がなく、中間サーバ１０１の処理負荷は軽減される。
【００９９】
いずれにせよ、ネットワークカメラ１００が再生装置毎のコンテンツデータを生成する従来技術のデータ配信システムと比較すると、処理負荷及びネットワークトラフィックのいずれもを低減することが可能である。
【０１００】
（他の実施形態）
上述の第１から第３の実施形態では、ISO Base Media File Formatにおけるフラグメント映像形式を利用してライブ映像配信を行なうフラグメント配信を用いる方法について説明した。しかし、本発明は、ＨＴＴＰなどのファイル転送プロトコルを用いたライブ映像配信において、複数の再生装置に対して配信しているコンテンツデータ間の差異がヘッダ部分の情報のみであるような場合に適用可能である。
【０１０１】
また、上述の実施形態では、映像と音声の両方のデータを配信するものとして説明したが、いずれか一方のみの配信を行うシステムにも本発明を適用することが可能である。
【０１０２】
また、前述した実施形態の機能を実現するコンピュータプログラムを、コンピュータを含むシステム或いは装置のコンピュータが実行することによって同等の機能が達成される場合も本発明に含む。コンピュータを含むシステム又はコンピュータへのプログラムの供給は、記録媒体から直接行っても、有線／無線通信を用いて行っても良い。
【０１０３】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータに供給、インストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明の機能処理を実現するためのコンピュータプログラム自体も本発明に含まれる。
【０１０４】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【０１０５】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハードディスク、磁気テープ等の磁気記録媒体がある。また、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ等の光／光磁気記憶媒体、不揮発性の半導体メモリなどもある。
【０１０６】
有線／無線通信を用いたプログラムの供給方法としては、以下のような方法がある。コンピュータネットワーク上のサーバに、クライアントコンピュータ上で本発明を形成するコンピュータプログラムとなりうるデータファイル（プログラムデータファイル）を記憶する。そして、接続のあったクライアントコンピュータにプログラムデータファイルをダウンロードする方法である。この場合、プログラムデータファイルを複数のセグメントファイルに分割し、セグメントファイルを異なるサーバに配置することも可能である。プログラムデータファイルとしては、本発明を形成するコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイル等でよい。
【０１０７】
つまり、本発明の機能処理をコンピュータで実現するためのプログラムデータファイルを複数のユーザに対してダウンロードさせるサーバ装置も本発明に含む。
【０１０８】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件を満たしたユーザに対して暗号化を解く鍵情報を、例えばインターネットを介してダウンロードさせることによって供給することもできる。この場合、その鍵情報を使用することにより、暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【０１０９】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現されるだけでなく、他のプログラムを利用することによって実施形態の機能を実現してもよい。例えば、プログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行うことで、前述した実施形態の機能が実現され得る。
【０１１０】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードや、コンピュータに接続された機能拡張ユニットで実行されることで前述した実施形態の機能が実現されてもよい。具体的には、機能拡張ボードや機能拡張ユニットが備えるメモリやＣＰＵによってプログラムが実行され、実際の処理の一部または全部を担っても良い。
【図面の簡単な説明】
【０１１１】
【図１】本発明の第１の実施形態に係るデータ配信システムの機能構成例を示すブロック図である。
【図２】フラグメント映像形式を含むＭＰ４ファイル形式のデータ構造を説明するための図である。
【図３】本発明の第１の実施形態に係る中間サーバ１０１における、個々の再生装置１０２に適したコンテンツデータを生成・配信する処理を説明するフローチャートである。
【図４】本発明の実施形態で用いる再生装置接続情報の例を示す図である。
【図５】本発明の第１の実施形態において、コンテンツデータ生成部で行うシーケンスナンバーと基準オフセットの書き換え処理を説明するための図である。
【図６】本発明の第１の実施形態における各装置間のデータの流れを模式的に示す図である。
【図７】本発明の第２の実施形態に係るデータ配信システムにおける各装置間のデータの流れについて説明した図である。
【図８】本発明の第１の実施形態に係るデータ配信システムにおける、ネットワークカメラ１００内の映像／音声データ符号化部１０４からマスターデータ配信部１０６までのデータ処理を模式的に示した図である。
【図９】本発明の第１の実施形態におけるコンテンツデータ生成部１０８の処理を説明するフローチャートである。
【図１０】本発明の第２の実施形態に係るデータ配信システムの機能構成例を示すブロック図である。
【図１】
2007173987.tif 000003
【図２】
2007173987.tif 000004
【図３】
2007173987.tif 000005
【図４】
2007173987.tif 000006
【図５】
2007173987.tif 000007
【図６】
2007173987.tif 000008
【図７】
2007173987.tif 000009
【図８】
2007173987.tif 000010
【図９】
2007173987.tif 000011
【図１０】
2007173987.tif 000012