JP2017046183A - 送信装置、受信装置及び通信システム - Google Patents

Abstract

【課題】必要度が高い等と評価されるメディアデータの部分を効率的に送受信する。【解決手段】メディアデータを端末に送信するカメラ１００であって、メディアデータの一部に対応するセグメントデータを生成する生成手段と、生成手段で生成したセグメントデータを評価する評価手段と、評価手段の評価に基づいて、セグメントデータについての情報の一覧であるセグメントリストを管理する管理手段と、管理手段で管理するセグメントリストを送信する第１送信手段と、生成手段で生成したセグメントデータを送信する第２送信手段と、を備える。【選択図】図１

Description

本発明は、メディアデータを送信する送信装置、メディアデータを受信する受信装置、送信装置と受信装置とを備える通信システム、送信装置及び受信装置の制御方法、並びに、送信装置及び受信装置を制御するためのプログラムに関する。

近年、ネットワークカメラやビデオ会議システム等において、ネットワークを介して動画データや音声データ等のメディアデータをリアルタイムに送受信するライブストリーミングの技術が実用化されている。ライブストリーミングにおいて、従来ファイル転送等に用いられていたプロトコルを使用して、ストリーミング映像データの転送を行う方法がある。なお、従来ファイル転送等に用いられていたプロトコルとしては、ＨＴＴＰ（Hypertext Transfer Protocol）及びＴＣＰ（Transmission Control Protocol）がある。
ところで、カメラでの撮影において、意図しない乱れた映像や、必要のない映像が撮られてしまうことがある。これに対し、加速度センサー・被写体動き検知・フォーカス合焦判断等を用いて撮影映像の必要度を判断し、エンコードビットレートを変更することで記録媒体の記録可能容量の消費量を抑制するものがある（特許文献１）。また、デジタル放送番組を記録媒体に録画した後、データ再生時にコマーシャルコンテンツをカットして放送番組コンテンツのみを再生するものがある（特許文献２）。

特開２００８−３１１７６３号公報 特開２００５−１７５７１０号公報

しかしながら、ライブストリーミングでは、ネットワークの通信路の状況や機器のバッファリングにより、輻輳遅延が発生することがあり、メディアデータ中の必要度の高い部分を効率的に送受信できないことがある。一方で、特許文献１及び２には、ライブストリーミングにおいて、メディアデータ中の必要度の高い部分を効率的に送受信する技術は開示されていない。
そこで、本発明は、必要度が高い等と評価されるメディアデータの部分を効率的に送受信することを目的とする。

本発明は、メディアデータを受信装置に送信する送信装置であって、メディアデータの一部に対応するセグメントデータを生成する生成手段と、前記生成手段で生成したセグメントデータを評価する評価手段と、前記評価手段の評価に基づいて、セグメントデータについての情報の一覧であるセグメントリストを管理する管理手段と、前記管理手段で管理する前記セグメントリストを送信する第１送信手段と、前記生成手段で生成したセグメントデータを送信する第２送信手段と、を備えることを特徴とする。

本発明は、送信対象の一部に対応するセグメントデータの評価に基づいて、セグメントデータについての情報の一覧であるセグメントリストが送信装置で管理され、このセグメントリストが受信装置に送信される。このため、送信装置又は受信装置は、セグメントデータの評価に基づくセグメントリストから、送受信するセグメントデータを決定できる。したがって、必要度が高い等と評価されるセグメントデータを効率的に送受信できる。

第１実施形態のカメラのブロック図である。 第１実施形態の端末のブロック図である。 第１実施形態の通信システムのシーケンス図である。 第１実施形態のプレイリストを示す図である。 第１実施形態の通信システムの輻輳時を含むプレイリストの推移を示す図である。 第１実施形態のカメラの処理を示すフローチャートである。 第１実施形態の端末の処理を示すフローチャートである。 第１実施形態の端末の画面の例を示す図である。 第２実施形態の通信システムの輻輳時を含むプレイリストの推移を示す図である。 第２実施形態のカメラの処理を示すフローチャートである。 第２実施形態の端末の処理を示すフローチャートである。

以下、添付図面を参照して、本発明の好適な実施形態について説明する。
＜第１実施形態＞
本実施形態の通信システムは、送信装置の一例であって撮像装置であるカメラ１００と、受信装置の一例であって情報処理装置である端末２００とを備える。カメラ１００は、後述の通り、映像データ等のストリーミングデータを端末２００に送信する。端末２００は、受信したストリーミングデータを表示する。なお、カメラ１００には、撮影機能を主とするスチルカメラやビデオカメラの他に、カメラ付き携帯電話やいわゆるタブレット端末を用いてもよい。また、端末２００には、一般的なパーソナルコンピュータの他に、いわゆるスマートフォン等の携帯電話やいわゆるタブレット端末、テレビ等を用いてもよい。

次に、図１を参照して、カメラ１００の構成を説明する。図１は、カメラ１００のブロック図である。カメラ１００は、内部バス１１０と、内部バス１１０に接続するＣＰＵ（Central Processing Unit）１０１及びＲＯＭ（Read Only Memory）１０２とを備える。また、カメラ１００は、内部バス１１０に接続するＲＡＭ（Random Access Memory）１０３、入力処理部１０４、出力処理部１０６及び通信制御部１０８を備える。また、カメラ１００は、内部バス１１０に接続する記録媒体制御部１１１、カメラ信号処理部１１５及び符号・復号処理部１１６を備える。内部バス１１０に接続される各部は、内部バス１１０を介して互いにデータのやりとりができる。また、カメラ１００は、さらに操作部１０５、表示部１０７、通信インタフェース１０９、光学系１１３、撮像素子１１４及び記録媒体１１２を備える。

ＣＰＵ１０１は、ＲＯＭ１０２又は記録媒体１１２に格納されるプログラムに従い、ＲＡＭ１０３をワークメモリとして用いて、カメラ１００の各部を制御する。
ＲＯＭ１０２は、ＣＰＵ１０１が動作するための各種プログラムや設定データを格納する。ＲＯＭ１０２にはフラッシュメモリが含まれてもよい。
ＲＡＭ１０３は、ＣＰＵ１０１が動作時に必要とするプログラム、変数及び作業用の一時データ等を適宜記憶する。
入力処理部１０４は、操作部１０５でのユーザ操作を受け付け、操作に応じた制御信号を生成し、ＣＰＵ１０１に供給する。
操作部１０５は、入力処理部１０４に接続して、ユーザ操作を受け付ける入力デバイスである。操作部１０５として、キーボードといった文字情報入力デバイスや、マウスやタッチパネルといったポインティングデバイス等が使われる。また、赤外線リモコン等の遠隔操作可能なものもが使われてもよい。なお、タッチパネルは、例えば平面的に構成された入力部に対して接触された位置に応じた座標情報が出力されるようにした入力デバイスである。入力処理部１０４及び操作部１０５により、カメラ１００に対し、ユーザ操作に応じた動作を行わせることができる。
出力処理部１０６は、ＣＰＵ１０１がプログラムに従い生成したＧＵＩ（Graphical User Interface）等の表示データに基づき、表示部１０７に対して表示させるための表示信号を出力する。
表示部１０７は、出力処理部１０６に接続して、画像等を表示する。
なお、操作部１０５としてタッチパネルを用いる場合、操作部１０５と表示部１０７とを一体的に構成できる。例えば、光の透過率が表示部１０７の表示を妨げないようにタッチパネルを構成し、表示部１０７の表示面の上層に取り付ける。そして、タッチパネルにおける入力座標と、表示部１０７上の表示座標とを対応付ける。これにより、あたかもユーザが表示部１０７上に表示された画面を直接的に操作可能であるかのようなＧＵＩを構成できる。

通信制御部１０８は、ＣＰＵ１０１の制御に基づき、通信インタフェース１０９を介して、外部装置との通信を行う。なお、本実施形態では、通信制御部１０８は端末２００と通信を行う。通信方法としては、無線のＩＥＥＥ８０２．１１やＢｌｕｅｔｏｏｔｈ（登録商標）、有線のＩＥＥＥ８０２．３等を用いることができる。
通信インタフェース１０９は、アンテナ及びコネクタの少なくとも一方を備え、通信制御部１０８と接続して外部装置との通信を行う。無線での通信を行う場合、通信インタフェース１０９のアンテナが使われる。有線での通信を行う場合、通信インタフェース１０９のコネクタが使われる。
記録媒体制御部１１１は、記録媒体１１２が接続され、ＣＰＵ１０１の制御に基づき、記録媒体１１２からのデータの読み出しや、記録媒体１１２に対するデータの書き込みを行う。
記録媒体１１２は、記録媒体制御部１１１に接続するデータの記録が可能な媒体である。記録媒体１１２には、ＨＤＤ（hard disk drive）や不揮発性の半導体メモリ等が使われる。なお、記録媒体１１２には、不図示のソケット等を介して記録媒体制御部１１１へ着脱可能に接続できるメモリカード等の不揮発性の半導体メモリを用いてもよい。

光学系１１３は、フォーカス、絞り機構等を含む撮影レンズであり、被写体の光学像を形成する。
撮像素子１１４は、ＣＣＤやＣＭＯＳ素子等で構成され、本実施形態ではＡ／Ｄ変換器を含み、光学像をアナログ電気信号に変換した後、デジタル信号に変換する。
カメラ信号処理部１１５は、ＣＰＵ１０１の制御に基づき、撮像素子１１４で変換されたデジタル信号に対し、所定の画素補間及び縮小といったリサイズ処理や色変換、各種補正処理等を行う。
符号・復号処理部１１６は、ＣＰＵ１０１の制御に基づき、カメラ信号処理部１１５で処理されたデジタル信号を所定のビットレート、フォーマット形式で圧縮符号化したり、映像圧縮符号化データを復号化したりする。
なお、カメラ１００が音声付き映像を端末２００に送信するには、カメラ１００は、マイクロホン、音声のアナログ信号をデジタル化するＡ／Ｄ変換器、及び、音声のデジタルデータを符号化する符号部を備える必要がある。カメラ１００は、映像記録時には映像と共に音声も同時に収録し、符号・復号処理部１１６で映像と音声を多重化して、音声付映像データを生成する。

次に、図２を参照して、端末２００の構成を説明する。図２は、端末２００のブロック図である。端末２００は、内部バス２１０と、内部バス２１０に接続するＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、入力処理部２０４、出力処理部２０６、通信制御部２０８、記録媒体制御部２１１及び符号・復号処理部２１３とを備える。端末２００は、さらに操作部２０５、表示部２０７、通信インタフェース２０９及び記録媒体２１２を備える。
符号・復号処理部２１３は、ＣＰＵ２０１の制御に基づき、映像圧縮符号化データを復号化したり、必要に応じて復号化したデータを再符号化したりする。なお、図２に示す端末２００の各部は、図１に示すカメラ１００の同名称の部分と同様の機能をもつため、詳細な説明を省略する。

次に、本実施形態の通信システムで行われるライブストリーミングについて説明する。本実施形態の通信システムは、プレイリストを利用したライブストリーミングを行う。そこで、まずプレイリストを用いたストリーミングの基本的な動作を説明する。
第１の動作として、サーバとなるカメラ１００は、ストリーミングに使われる音声データや映像データ等のメディアデータ（以下、ストリーミングデータという）の記録を行う。カメラ１００は、所定時間記録を行った後、この所定時間分のデータをストリーミングデータの一部に対応するセグメント（セグメントデータともいう）として保存する。そして、カメラ１００は、セグメントの情報であるセグメント情報を作成する。さらに、カメラ１００は、セグメント情報の一覧が含まれるプレイリストを作成し管理する。なお、プレイリストは、本発明のセグメントリストに相当する。
セグメント情報には、後述の通り、セグメントの取得先のアドレスであるセグメントアドレスが含まれる。リアルタイムでのストリーミングであるライブストリーミングの場合、カメラ１００は定期的にセグメントを生成し、新しいセグメントを生成すると動的にプレイリストを更新する。すなわち、ライブストリーミングの場合はスライドウインドウ型プレイリストが使われる。プレイリストの更新には、プレイリストからの特定のセグメント情報の削除や、プレイリストへの新しいセグメント情報の追記が含まれる。

次に、第２の動作として、クライアントとなる端末２００は、カメラ１００からプレイリストを受信して解析する。そして、端末２００は、プレイリストに列挙されたセグメント情報の順に、セグメント情報に含まれるセグメントアドレスにセグメント取得要求を送信し、この要求の応答としてセグメントを受信する。
次に、第３の動作として、端末２００は、受信したセグメントの再生表示又は保存を行う。
カメラ１００及び端末２００は、ストリーミングの終了まで、上述の第１から第３の動作を繰り返す。

次に、図３を参照して、本実施形態の通信システムで行われるライブストリーミングの動作を説明する。図３は、本実施形態の通信システムのシーケンス図である。
図３に示す動作に先立って、ユーザは、カメラ１００の操作部１０５を操作してカメラ１００のライブストリーミングの機能の実行を指示する。カメラ１００のＣＰＵ１０１は、通信制御部１０８を通信可能な状態にする。
また、ユーザは、端末２００の操作部２０５を操作して、カメラ１００との通信接続処理及びライブストリーミングに必要なアプリケーションの起動を指示する。端末２００のＣＰＵ２０１は、端末２００のＲＯＭ２０２又は記録媒体２１２に格納された当該アプリケーションのプログラムを実行して、端末２００の通信制御部２０８を制御し、カメラ１００との通信を開始する。なお、カメラ１００及び端末２００は、通信プロトコルとしてＨＴＴＰを使用するものとする。また、端末２００は、通信接続においてＵＰｎＰ（Universal Plug and Play）に対応しているものとする。

ＵＰｎＰ対応の端末２００は、ネットワークに接続すると、ＩＰ（Internet Protocol）アドレスの設定を行う。ＩＰアドレスの設定にはＤＨＣＰ（Dynamic Host Configuration Protocol）又はＡｕｔｏＩＰが使われる。ＩＰアドレスを取得した端末２００は、ネットワーク上の他の機器を相互に認識するために、図３のステップＳ３０３及びＳ３０４に示す「デバイスディスカバリーとコントロール」を行う。
ステップＳ３０３において、端末２００は、デバイス検索要求を送信する。カメラ１００はこの要求を受信する。
ステップＳ３０４において、カメラ１００は、デバイス検索要求に対する応答として、機器情報、機器固有情報であるプレイリスト取得先の情報、及び、サービス情報等を、端末２００に送信する。端末２００はこの情報を受信する。
ステップＳ３０４により接続処理が完了し、カメラ１００はライブストリーミングを開始する。

ライブストリーミングが開始すると、カメラ１００は所定の周期で、セグメント３０２の生成、及び、プレイリスト３０１の更新を行う。まずセグメント３０２について説明する。
ライブストリーミング実行時に、カメラ１００のＣＰＵ１０１は、撮像素子１１４からの信号出力を開始する。カメラ１００のカメラ信号処理部１１５は、この出力を適切な映像データになるように処理し、処理された映像データ、及び、ズーム倍率（又は焦点距離）等のカメラステータスを符号・復号処理部１１６に送る。
符号・復号処理部１１６は、受け取った映像データ等を所定のビットレート及びフォーマット形式で圧縮符号化し、さらに所定の再生時間Ｔｓとなるセグメント３０２を生成する。ＣＰＵ１０１は、セグメント３０２をＲＡＭ１０３又は記録媒体１１２に保存する。本実施形態では再生時間Ｔｓを０．５秒とする。
なお、端末２００は、セグメント３０２の所定の再生時間Ｔｓを事前に記憶しているものとする。ただし、図３のステップＳ３０４で、カメラ１００は再生時間Ｔｓをカメラ１００の機器情報に含めて端末２００に送信し、端末２００は、この機器情報から再生時間Ｔｓを取得してもよい。

カメラ１００のＣＰＵ１０１は、セグメント３０２のアドレスであるセグメントアドレスを生成する。セグメントアドレスは、端末２００がセグメント３０２を取得する際のアドレスとして使用するものであり、例えばＵＲＬ（Uniform Resource Locator）で表される。ＣＰＵ１０１は、プレイリスト３０１を作成し、プレイリスト３０１にセグメント３０２のセグメントアドレスを含んだセグメント情報を記録する。

次に、図４を参照して、プレイリスト３０１について説明する。図４はプレイリスト３０１の例を示す図である。プレイリスト３０１は、Ｅｘｔｅｎｄｅｄ Ｍ３Ｕ形式のプレイリストである。プレイリスト３０１は、識別子４１１とバージョン情報４１２とセグメント情報４１５とを含む。
識別子４１１は、プレイリスト３０１がＥｘｔｅｎｄｅｄ Ｍ３Ｕ形式であることを示す識別子タグである。識別子４１１は、プレイリスト３０１の第１行目に記述される。
バージョン情報４１２は、プレイリスト３０１のバージョンである。バージョン情報４１２は、バージョン情報を示すタグと共にプレイリスト３０１の第２行目に記述される。本実施形態では、バージョンとして「３」が記述される。

セグメント情報４１５は、１つのセグメントについての情報であり、セグメントの再生時間４１３とセグメントアドレス４１４とを含む。セグメント情報４１５は、プレイリスト３０１の第３行目以降に記述される。
再生時間４１３は、セグメント情報４１５が表すセグメントの再生時間である。再生時間４１３は、再生時間を示すタグと共にプレイリスト３０１に記述される。再生時間４１３は、例えば、単位を秒とし、整数又は小数で記述される。本実施形態では、再生時間Ｔｓが０．５秒であるため、再生時間として０．５と記述される。
セグメントアドレス４１４は、セグメント情報４１５が表すセグメントについてのセグメントアドレスである。セグメントアドレスは、上述の通りＵＲＬで表され、クエリパラメータを含む。再生時間４１３とセグメントアドレス４１４とは、所定のセグメントに関する情報として、続けて記述する必要がある。プレイリスト３０１が複数のセグメントについての情報を含むときは、プレイリスト３０１はセグメント情報４１５を複数備える。

ここで図３の説明に戻ると、図３のステップＳ３０５において、端末２００は、ライブストリーミングが開始してから約Ｔｓ（秒）後に、ステップ３０４で取得したプレイリスト取得先へ、プレイリスト取得要求を送信する。この送信にはＨＴＴＰのＧＥＴメソッドが使われる。カメラ１００は、このプレイリスト取得要求を受信する。
ステップＳ３０６において、カメラ１００は、セグメント情報４１５が例えば１つ記述されたプレイリスト３０１を、プレイリスト取得要求の応答として端末２００に送信する。端末２００は、このプレイリスト３０１を受信する。
ステップＳ３０７において、端末２００は、受信したプレイリスト３０１を解析し、プレイリスト３０１のセグメント情報４１５に含まれるセグメントアドレスに対してセグメント取得要求を送信する。この送信にはＨＴＴＰのＧＥＴメソッドが使われる。カメラ１００は、このセグメント取得要求を受信する。
ステップＳ３０８において、カメラ１００は、要求されたセグメント３０２を、セグメント取得要求の応答として端末２００に送信する。端末２００は、このセグメント３０２を受信する。

ライブストリーミング実行中、カメラ１００は、約Ｔｓ（秒）毎にセグメント３０２の生成、及び、プレイリスト３０１の更新を行う。カメラ１００は、端末２００が取得したセグメント３０２についてのセグメント情報４１５を、プレイリスト３０１から削除する。
端末２００は、カメラ１００がプレイリスト３０１の更新を行う度、すなわち、約Ｔｓ（秒）毎に、ステップＳ３０５に示すプレイリスト取得要求をカメラ１００に送信する。そして、端末２００は、ステップＳ３０６で受信したプレイリスト３０１に記載のセグメント情報４１５に基づいて、ステップＳ３０７でセグメント取得要求を送信し、ステップＳ３０８でセグメント３０２を受信する。
このようにして、端末２００によるセグメント３０２の取得が続けられる。

なお、ステップＳ３０５及びＳ３０７で端末２００からカメラ１００へ送信されるプレイリスト取得要求及びセグメント取得要求には、端末２００又はアプリケーションの固有のＩＤが含まれる。カメラ１００は、最初の要求に含まれるＩＤと一致するＩＤを含む要求のみに対して応答する。つまり、本実施形態のカメラ１００と端末２００は１対１接続でのみストリーミングを行う。

端末２００は、受信したセグメント３０２を符号・復号処理部２１３に渡し、復号化した後、出力処理部２０６を介して、表示部２０７で再生表示を行う。ここで、図８を参照して、端末２００の表示部２０７に表示されるライブストリーミング実行時の画面の例を説明する。図８は、端末２００の画面の例を示す図である。なお、図８には、タッチパネル等が使われて操作部２０５及び表示部２０７が一体化された端末２００の画面の例が示されている。
図８に示す端末２００の表示部２０７の画面は、表示エリア８０１と、ズーム情報部８０２と、記録状態部８０３と、バッテリー情報部８０４と、ズーム制御ボタン８０５とを備える。さらに、表示部２０７の画面は、カメラ記録ボタン８０６と、端末記録ボタン８０７とを備える。

表示エリア８０１には、端末２００がカメラ１００から受信したストリーミングデータ、すなわちセグメント３０２が表示される。
ズーム情報部８０２、記録状態部８０３及びバッテリー情報部８０４には、それぞれ、カメラ１００のズームに関する情報、カメラ１００が記録しているか否か、カメラ１００のバッテリーの残量が表示される。
ズーム制御ボタン８０５は、カメラ１００のズーム倍率を変更するためのボタンである。ユーザがズーム制御ボタン８０５を操作することで、端末２００からカメラ１００に、カメラ１００のズーム倍率変更の命令が送信される。カメラ１００は、この命令を受信して、命令に応じてズーム倍率を変更する。
カメラ記録ボタン８０６は、カメラ１００での記録を開始したり終了したりするためのボタンである。ユーザがカメラ記録ボタン８０６を操作することで、端末２００からカメラ１００に、カメラ１００の記録の開始命令又は終了命令が送信される。カメラ１００は、この命令を受信して、命令に応じて記録の開始又は終了を行う。
端末記録ボタン８０７は、端末２００での記録を開始したり終了したりするためのボタンである。ユーザが端末記録ボタン８０７を操作することで、端末２００は、記録の開始又は終了を行う。端末２００での記録が行われているときは、端末２００で復号化したデータ、又は、セグメント３０２からヘッダ等を除いたデータ部を記録媒体２１２に記録保存する。そして、順次受信したセグメントデータを結合し記録していく。

次に、ライブストリーミング実行時に輻輳が発生した場合の動作について、図５を参照して説明する。図５は、輻輳時を含むプレイリストの推移を示す図である。図３を参照して説明した通り、通信状況が良好である場合、プレイリスト取得要求（ステップＳ３０５）からセグメント応答（ステップＳ３０８）までの一連の処理が定期的に行われる。しかし、実際には、輻輳等により通信が定期的に行えなくなることがある。輻輳が発生しているときは、図５に示す通り、端末２００はプレイリスト及びセグメントの取得が行えない。なお、図５に示すプレイリストの説明は、図６に示す処理の説明の中で行う。

次に、図６を参照して、ライブストリーミング実行時のカメラ１００の処理を説明する。図６は、カメラ１００のＣＰＵ１０１が実行する処理を示すフローチャートである。図６の処理は、カメラ１００が端末２００と接続を確立した後に開始する。
ステップＳ６０１において、カメラ１００のＣＰＵ１０１は、ライブストリーミング開始に伴う、セグメント生成の処理を開始する。セグメント生成の処理は、次のような処理である。すなわち、ＣＰＵ１０１は、撮像素子１１４からの信号出力を開始し、その出力をカメラ信号処理部１１５により適切な映像データに処理し、処理された映像データを符号・復号処理部１１６に渡す。符号・復号処理部１１６は、受け取った映像データを所定のビットレート及びフォーマット形式で圧縮符号化し、さらに所定の再生時間Ｔｓを持つセグメントを生成する。本実施形態では、上述の通り再生時間Ｔｓは０．５秒である。ＣＰＵ１０１は、撮像素子１１４より得られた映像データを０．５秒単位に符号化してセグメントを作成し、セグメントを１つのファイルとしてＲＡＭ１０３又は記録媒体１１２に蓄積する。ステップＳ６０１で、このようなセグメント生成の処理が開始する。なお、このセグメント生成の処理は生成手段による処理の一例である。

ステップＳ６０２において、カメラ１００のＣＰＵ１０１は、一つのセグメントの生成が完了したか否かの判定を行う。ＣＰＵ１０１は、再生時間Ｔｓを持つデータが、ＲＡＭ１０３又は記録媒体１１２に一時的に保存されたことを確認し、保存が完了しているときは、一つのセグメントの生成が完了したと判定してステップＳ６０３へ処理を進める。ＣＰＵ１０１は、保存が完了していないときは、一つのセグメントの生成が完了していないと判定してステップＳ６０６へ処理を進める。なお、本ステップは問い合わせ（ポーリング）による判定で説明したが、ＣＰＵ１０１は、再生時間Ｔｓを持つセグメントを書き込んだことを検出して割り込み通知を行う等の方法によって、セグメント生成完了を判定するようにしてもよい。

ステップＳ６０３において、カメラ１００のＣＰＵ１０１は、セグメント情報を生成する。上述の通り、セグメント情報には、セグメントの再生時間及びセグメントアドレスが含まれる。ＣＰＵ１０１は、再生時間を上述の通り０．５秒とする。また、ＣＰＵ１０１は、セグメントのファイル名等に関連付けたパス情報を使って、セグメントアドレスを生成する。なお、セグメントアドレスには、セグメントのファイル名のパス情報を使わず、セグメントを特定できるアドレスを使ってもよい。

ステップＳ６０４において、カメラ１００のＣＰＵ１０１は、セグメントの評価を実行する。セグメントの評価方法は、カメラ１００の撮影モードによって異なる。カメラ１００の撮影モードには、ポートレートモードとスポーツモードと風景モードとがある。
ポートレートモードは、人物の撮影に適した撮影モードである。カメラ１００がポートレートモードのとき、ＣＰＵ１０１は、セグメントの映像データから顔検出がされるか否かによって評価する。ＣＰＵ１０１は、セグメントの映像データから顔検出がされると必要度の高いセグメントと評価し、顔検出されないと必要度の低いセグメントと評価する。
スポーツモードは、動いている人物等の撮影に適した撮影モードである。カメラ１００がスポーツモードのとき、ＣＰＵ１０１は、セグメントの映像データに動きがあるか否かによって評価する。ＣＰＵ１０１は、セグメントの映像データに動きがあるとき必要度の高いセグメントと評価し、動きがないとき必要度の低いセグメントと評価する。また、カメラ１００がスポーツモードのとき、ＣＰＵ１０１は、セグメントの音声データの音量が所定値以上か否かよって評価してもよい。ＣＰＵ１０１は、セグメントの音声データの音量が所定値以上のとき必要度の高いセグメントと評価し、所定値未満のとき必要度の低いセグメントと評価する。
風景モードは、風景の撮影に適した撮影モードである。カメラ１００が風景モードのとき、ＣＰＵ１０１は、セグメントの映像データに所定以上の振動を検知するか否かによって評価する。ＣＰＵ１０１は、セグメントの映像データに所定以上の振動を検知するとき必要度の低いセグメントと評価し、所定以上の振動を検知しないとき必要度の高いセグメントと評価する。
また、カメラ１００がどの撮影モードであっても、セグメントの映像データが黒一色のとき、ＣＰＵ１０１は必要度の低いセグメントと評価する。
そして、ＣＰＵ１０１は、セグメントの必要度が低いと判定したときステップＳ６０６に処理を進め、セグメントの必要度が高いと判定したときステップＳ６０５に処理を進める。なお、ステップＳ６０４で行うセグメントの評価は、評価手段による処理の一例である。

ステップＳ６０５において、カメラ１００のＣＰＵ１０１は、セグメント情報をプレイリストに追記する。
ここで、ライブストリーミング実行後、Ｎ回目に生成されたセグメントを第Ｎセグメントというと、例えば第１セグメントについてのセグメント情報５００Ａは、図５のプレイリスト５１０に示されるように生成される。また、カメラ１００が管理するプレイリストがプレイリスト５２０のときに第４セグメントが生成されたとすると、プレイリスト５２０に第４セグメントのセグメント情報５００Ｂが追記されたプレイリスト５３０が生成される。その後、第５セグメントが生成されると、プレイリスト５３０に第５セグメントのセグメント情報５００Ｃが追記されたプレイリスト５４０が生成される。
しかし、ステップＳ６０４でセグメントの必要度が低いと評価されたときは、ステップＳ６０５の処理が行われないため、必要度が低いセグメントのセグメント情報はプレイリストに追記されない。例えば、カメラ１００が管理するプレイリストがプレイリスト５１１のときに、第３セグメントが生成され、第３セグメントは必要度が低いと評価されたとする。このとき、プレイリスト５１１には第３セグメントのセグメント情報は追記されず、第３セグメント生成後のプレイリスト５２０はプレイリスト５１１と同じ内容となる。
このように、図６のステップＳ６０４で、ＣＰＵ１０１が、セグメントの評価に応じて、ステップＳ６０５に進めるかステップＳ６０６に進めるかの判定は、プレイリストにセグメント情報を追記するか否かの判定になるといえる。なお、ステップＳ６０４のこの判定、及びステップＳ６０５は、管理手段による処理の一例である。

ステップＳ６０６において、カメラ１００のＣＰＵ１０１は、通信制御部１０８を介して、端末２００からのプレイリスト取得要求を受信したか否かを判定する。このプレイリスト取得要求の受信は図３のステップＳ３０５に対応する。ＣＰＵ１０１は、プレイリスト取得要求を受信したときステップＳ６０７に処理を進め、プレイリスト取得要求を受信していないときステップＳ６０８に処理を進める。
ステップＳ６０７において、カメラ１００のＣＰＵ１０１は、プレイリスト取得要求に対する応答として、通信制御部１０８を介して、端末２００にプレイリストを送信する。このプレイリストの送信は、図３のステップＳ３０６に対応する。なお、ステップＳ６０７は、送信装置の第１送信手段による処理の一例である。

ステップＳ６０８において、カメラ１００のＣＰＵ１０１は、通信制御部１０８を介して、端末２００からのセグメント取得要求を受信したか否かを判定する。このセグメント取得要求の受信は図３のステップＳ３０７に対応する。ＣＰＵ１０１は、セグメント取得要求を受信したときステップＳ６０９に処理を進め、セグメント取得要求を受信していないときステップＳ６１２に処理を進める。
ステップＳ６０９において、カメラ１００のＣＰＵ１０１は、ステップＳ６０８で受信したセグメント取得要求で要求されるセグメントが有効か否かの判定を行う。ＣＰＵ１０１は、セグメントが有効のときステップＳ６１０に処理を進め、無効のときはステップＳ６１１に処理を進める。

ステップＳ６１０において、カメラ１００のＣＰＵ１０１は、セグメント取得要求に対する応答として、通信制御部１０８を介して、要求されたセグメントを端末２００に送信する。このセグメントの送信は、図３のステップＳ３０８に対応する。また、ＣＰＵ１０１は送信したセグメントをＲＡＭ１０３又は記録媒体１１２から削除する。
さらに、ＣＰＵ１０１は、送信したセグメントについてのセグメント情報をプレイリストから削除する。例えば、カメラ１００が管理するプレイリストが図５に示すプレイリスト５１０のときに、カメラ１００がセグメント情報５００Ａに記載されている第１セグメントを端末２００に送信したとする。このとき、カメラ１００は、プレイリスト５１０からセグメント情報５００Ａを削除して、プレイリスト５１１を生成する。同様に、カメラ１００が管理するプレイリストがプレイリスト５４０のときに、カメラ１００が、セグメント情報５００Ｂに記載されている第４セグメントを端末２００に送信したとする。このとき、カメラ１００は、プレイリスト５４０からセグメント情報５００Ｂを削除して、プレイリスト５４１を生成する。
そして、ＣＰＵ１０１は、ステップＳ６１２に処理を進める。なお、ステップＳ６１０でセグメントを送信する処理は、送信装置の第２送信手段による処理の一例である。

ステップＳ６１１において、カメラ１００のＣＰＵ１０１は、セグメント取得要求に対する応答として、通信制御部１０８を介して、端末２００にエラーステータスを送信し、ステップＳ６１２に処理を進める。
ステップＳ６１２において、カメラ１００のＣＰＵ１０１は、ライブストリーミングを終了するか否かの判定を行う。この判定は、例えば、ユーザがライブストリーミングの終了を指示したか否かで行われる。ライブストリーミングを終了するとき、ＣＰＵ１０１は図６の処理を終了し、ライブストリーミングを終了しないときＣＰＵ１０１はステップＳ６０２へ処理を戻す。

なお、図６に示す処理では、セグメント生成の完了イベント待ち（ステップＳ６０２）、プレイリスト取得要求の受信イベント待ち（ステップＳ６０６）及びセグメント取得要求の受信イベント待ち（ステップＳ６０８）を順番に行う。しかし、カメラ１００は、これらのイベント待ちを同時に行い、発生したイベントに対応する処理を行うようにしてもよい。

次に、図７を参照して、ライブストリーミング実行時の端末２００の処理を説明する。図７は、端末２００のＣＰＵ２０１が実行する処理を示すフローチャートである。図７の処理は、端末２００がカメラ１００と接続を確立した後に開始する。
ステップＳ７０１において、端末２００のＣＰＵ２０１は、カメラ１００からプレイリスト取得先情報を受信し保持する。プレイリスト取得先情報の受信は、図３のステップＳ３０４に対応する。
ステップＳ７０２において、端末２００のＣＰＵ２０１は、所定時間経過したか否かの判定を行う。ＣＰＵ２０１は、所定時間が経過したときステップＳ７０３へ処理を進め、経過していないとき再度ステップＳ７０２で所定時間の経過を待つ。所定時間は、セグメントの再生時間Ｔｓと同等の値にすることが望ましい。

ステップＳ７０３において、端末２００のＣＰＵ２０１は、ステップＳ７０１で取得したプレイリスト取得先情報を用いて、通信制御部２０８を介して、プレイリスト取得要求をカメラ１００に送信する。このプレイリスト取得要求の送信は、図３のステップＳ３０５に対応する。
その後、ＣＰＵ２０１は、通信制御部２０８を介して、プレイリストをカメラ１００から受信する。そして、ＣＰＵ２０１は、受信したプレイリストを解析する。ＣＰＵ２０１は、プレイリストに含まれる識別子タグ及びバージョンを確認した後、プレイリストに含まれるセグメント情報を取得する。図７から分かるように、ステップＳ７０３は、所定時間の周期で実行される。すなわち、ＣＰＵ２０１は、所定の周期でプレイリストをカメラ１００から受信する。なお、本ステップでプレイリストをカメラ１００から受信する処理は第１受信手段による処理の一例である。
ステップＳ７０４において、端末２００のＣＰＵ２０１は、プレイリストにセグメント情報が存在するか否かの判定を行う。ＣＰＵ２０１は、セグメント情報が存在するときステップＳ７０５へ処理を進め、存在しないときステップＳ７０３に処理を戻す。

ステップＳ７０５において、端末２００のＣＰＵ２０１は、取得したプレイリストから、最も古いセグメント（最古セグメント）についてのセグメント情報（最古セグメント情報）を取得する。ＣＰＵ２０１は、取得したプレイリストに含まれるセグメント情報が１つのとき、このセグメント情報を最古セグメント情報とする。ＣＰＵ２０１は、取得したプレイリストに含まれるセグメント情報が複数のとき、最初のセグメント情報を最古セグメント情報とする。
そして、ＣＰＵ２０１は、最古セグメント情報に含まれるセグメントアドレスに対して、通信制御部２０８を介して、最古セグメントについてのセグメント取得要求を送信する。このセグメント取得要求の送信は、図３のステップＳ３０７に対応する。その後、カメラ１００からセグメントを受信する。ＣＰＵ２０１は、受信した最古セグメントを、ＲＡＭ２０３又は記録媒体２１２に記録して、符号・復号処理部２１３に渡す。符号・復号処理部２１３はセグメントを復号化する。ＣＰＵ２０１は、復号化されたデータを、出力処理部２０６を介して、表示部２０７で再生表示（映像表示）する。また、ライブストリーミングアプリケーションにより端末での記録がされるとき、ＣＰＵ２０１は、本処理フローとは別の処理により、復号化したデータ、又はセグメントからヘッダ等を除いたデータを、記録媒体２１２に保存する。なお、本ステップでセグメントを受信する処理は第２受信手段による処理の一例である。

ステップＳ７０６において、端末２００のＣＰＵ２０１は、ライブストリーミングを終了するか否かの判定を行う。この判定は、例えば、ユーザがライブストリーミングの終了を指示したか否かで行われる。ＣＰＵ２０１は、ライブストリーミングを終了するとき図７の処理を終了し、ライブストリーミングを終了しないときステップＳ７０２へ処理を戻す。

以上のように、本実施形態では、必要度が低いと評価されたセグメントのセグメント情報はプレイリストに記載されない。このため、必要度が低いと評価されたセグメントは、カメラ１００から端末２００に送信されることがない。したがって、ネットワーク上のパケットを減らすことができ、必要度が高いと評価されるセグメントを効率的に送受信できる。

上述の図６の処理では、必要度が低いと評価されたセグメントのセグメント情報はプレイリストに追記しない。しかし、輻輳等の影響でプレイリストに所定数以上のセグメント情報が記載された状態になったときのみに、セグメントの評価を行い、必要度が低いと評価されたセグメントのセグメント情報をプレイリストに追記しないようにしてもよい。
また、セグメントの評価は常に行う一方で、プレイリストに所定数未満のセグメント情報が記述されているときは、セグメントの評価に関わらず、セグメント情報をプレイリストに追記してもよい。そして、プレイリストに所定数以上のセグメント情報が記述された場合に、プレイリストから、必要度が低いと評価されたセグメントのセグメント情報を削除してもよい。
これらの場合、ネットワークに余裕があるとき、すべてのセグメントが端末２００に送信され、ユーザは必要度が低いと評価されるセグメントであっても、セグメントの映像データを参照できる。一方で、通信の輻輳等によりネットワークに余裕がなくなってきたとき、必要度が低いと評価されたセグメントは、カメラ１００から端末２００に送信されなくなる。したがって、ネットワーク上のパケットを減らすことができ、必要度が高いと評価されるセグメントを効率的に送受信できる。

また、図６の処理では、セグメントの評価は、必要度が高いか低いかの２つのレベルで行われる。しかし、セグメントの評価は３つ以上のレベルで行われてもよい。そして、プレイリストに含まれるセグメント情報の数に応じて、プレイリストに追記するセグメントのレベルを変化させてもよい。すなわち、プレイリストに含まれるセグメント情報の数が多くなるほど、より必要度の高いセグメントについてのセグメント情報をプレイリストに追記するようにしてもよい。
また、必要度が低いと評価されるセグメントをプレイリストに追記するか否かを、ユーザが設定できるようにしてもよい。

＜第２実施形態＞
第１実施形態では、セグメントの評価に応じてセグメント情報をプレイリストに追記するか否かをカメラ１００が決定する。これに対して、本実施形態では、カメラ１００は必要度が低いと評価されたセグメントのセグメント情報もプレイリストに追記し、端末２００が、必要度が低いと評価されたセグメントを受信するか否かを判定する例を説明する。
カメラ１００及び端末２００は第１実施形態と同様の構成であるものとし、説明を省略する。また、第１実施形態と同様に、セグメントの再生時間Ｔｓは０．５秒であり、カメラ１００及び端末２００は１対１の接続でのみストリーミングを行うものとする。なお、これら以外の第１実施形態と同様の点については、説明を省略又は簡略化する。

まず、図９及び１０を参照して、本実施形態におけるライブストリーミング実行時のカメラ１００の処理を説明する。図９は、輻輳時を含むプレイリストの推移を示す図である。図１０は、カメラ１００のＣＰＵ１０１が実行する処理を示すフローチャートである。図１０の処理は、カメラ１００が端末２００と接続を確立した後に開始する。
図１０のステップＳ６０１からステップＳ６１２までは、以下に説明する点の除き、図６のステップＳ６０１からステップＳ６１２までと同様の処理である。以下では、図６との相違点を中心に、図１０のカメラ１００の処理を説明する。

図１０のステップＳ６０４では、図６のステップＳ６０４と同様の処理が行われる。ただし、セグメントの必要度が低いと判定されたとき、ＣＰＵ１０１はステップＳ６５０に処理を進め、セグメントの必要度が高いと判定されたときＣＰＵ１０１はステップＳ６０５に処理を進める。
ステップＳ６５０において、カメラ１００のＣＰＵ１０１は、必要度が低いと判定されたセグメントのセグメント情報にフラグをセットする。フラグは、セグメント情報内のセグメントアドレスにクエリパラメータとしてセットする。本実施形態では、ステップＳ６０３において、セグメントアドレスのクエリパラメータに、フラグの初期値として「ｆｌｇ＝０」を含めておく。そして、ステップＳ６５０において、ＣＰＵ１０１は、セグメントアドレスのクエリパラメータを「ｆｌｇ＝１」と設定しなおすことで、セグメント情報にフラグをセットする。

図１０のステップＳ６０５において、図６のステップＳ６０５と同様に、カメラ１００のＣＰＵ１０１は、セグメント情報をプレイリストに追記する。ただし、上述の通り、セグメント情報のセグメントアドレスには、セグメントの評価を表すフラグが含まれる。
図９を参照して、ステップＳ６０５で生成されるプレイリストの例を説明する。ＣＰＵ１０１が第１セグメントを生成し、第１セグメントは必要度が高いと評価されたとする。このときのプレイリストは、プレイリスト９１０のように、第１セグメントのセグメント情報９００Ａに「ｆｌｇ＝０」が含まれる。
また、カメラ１００が管理するプレイリストがプレイリスト９１１のときに、第３セグメントが生成され、第３セグメントは必要度が低いと評価されたとする。このとき、「ｆｌｇ＝１」が含まれる第３セグメントのセグメント情報９００Ｂがプレイリスト９１１に追記されたプレイリスト９２０が生成される。同様に、カメラ１００が管理するプレイリストがプレイリスト９３０のときに、第５セグメントが生成され、第５セグメントは必要度が低いと評価されたとする。このとき、「ｆｌｇ＝１」が含まれる第５セグメントのセグメント情報９００Ｄがプレイリスト９３０に追記されたプレイリスト９４０が生成される。

図１０のステップＳ６１０において、図６のステップＳ６１０と同様に、カメラ１００のＣＰＵ１０１は、セグメント取得要求に対する応答として、通信制御部１０８を介して、要求されたセグメントを端末２００に送信する。そして、ＣＰＵ１０１は、セグメントをＲＡＭ１０３又は記録媒体１１２から削除し、送信したセグメントについてのセグメント情報をプレイリストから削除する。
図９を参照して、送信したセグメントについてのセグメント情報が削除される例を説明する。カメラ１００が管理するプレイリストがプレイリスト９１０のときに、カメラ１００がセグメント情報９００Ａに記載されている第１セグメントを送信したとする。このとき、カメラ１００は、プレイリスト９１０からセグメント情報９００Ａを削除して、プレイリスト９１１を生成する。同様に、カメラ１００が管理するプレイリストがプレイリスト９５０のときに、カメラ１００がセグメント情報９００Ｄに記載されている第５セグメントを送信したとする。このとき、カメラ１００は、プレイリスト９５０からセグメント情報９００Ｄを削除して、プレイリスト９５１を生成する。

図１０のステップＳ６１０において、ＣＰＵ１０１は、送信したセグメントより古いセグメントがある場合、この古いセグメントをＲＡＭ１０３又は記録媒体１１２から削除する。また、この古いセグメントについてのセグメント情報をプレイリストから削除する。
図９を参照して、古いセグメントについてのセグメント情報が削除される例を説明する。カメラ１００が管理するプレイリストがプレイリスト９４０のときに、カメラ１００がセグメント情報９００Ｃに記載されている第４セグメントを送信したとする。このとき、カメラ１００は、プレイリスト９４０から第４セグメントのセグメント情報９００Ｃを削除する。さらに、カメラ１００は、プレイリスト９４０から、第４セグメントより古いセグメントである第３セグメントのセグメント情報９００Ｂも削除して、プレイリスト９４１を生成する。

次に、図１１を参照して、ライブストリーミング実行時の端末２００の処理を説明する。図１１は、端末２００のＣＰＵ２０１が実行する処理を示すフローチャートである。図１１の処理は、端末２００がカメラ１００と接続を確立した後に開始する。
図１１のステップＳ７０１からステップＳ７０６までは、以下に説明する点を除き、図７のステップＳ７０１からステップＳ７０６までと同様の処理である。以下では、図７との相違点を中心に、図１１の端末２００の処理を説明する。

図１１のステップＳ７０４では、図７のステップＳ７０４と同様の処理が行われる。ただし、ＣＰＵ２０１は、セグメント情報が存在するときステップＳ７５０へ処理を進め、存在しないときはステップＳ７０３に処理を戻す。
ステップＳ７５０において、端末２００のＣＰＵ２０１は、カメラ１００が所定数以上のセグメントを保持しているか否かを判定する。
ライブストリーミングでは、輻輳等によりカメラ１００と端末２００との間での通信が行えなくなると、カメラ１００のバッファ、すなわち、ＲＡＭ１０３又は記録媒体１１２にセグメントがたまっていく。そして、カメラ１００が生成するプレイリストには、カメラ１００のバッファにたまったセグメントと同数のセグメント情報が含まれる。例えば、図９に示すように、カメラ１００が第３セグメントを生成したときに、ネットワークが輻輳になり、カメラ１００と端末２００との間での通信が行えなくなったとする。このときでも、上述の通り、カメラ１００は再生時間Ｔｓの間隔でセグメントを生成し、生成したセグメントのセグメント情報をプレイリストに追記する。このため、カメラ１００は、第４セグメントを生成して保存するときに第４セグメントのセグメント情報９００Ｃが追記されたプレイリスト９３０を生成する。同様に、カメラ１００は、第５セグメントを生成して保存するときに第５セグメントのセグメント情報９００Ｄが追記されたプレイリスト９４０を生成する。
端末２００のＣＰＵ２０１は、受信したプレイリストに含まれるセグメント情報の数が所定値以上のとき、カメラ１００が所定数以上のセグメントを保持していると判定して、ステップＳ７５１に処理を進める。ＣＰＵ２０１は、受信したプレイリストに含まれるセグメント情報の数が所定値未満のとき、カメラ１００が所定数以上のセグメントを保持していないと判定して、ステップＳ７０５に処理を進める。なお、本実施形態は、ステップＳ７５０の判定に使われる所定値を３とする。

図１１のステップＳ７０５において、端末２００のＣＰＵ２０１は、図６のステップＳ７０５と同様に、最古セグメントをカメラ１００から受信する。このとき、ＣＰＵ２０１は、セグメントの評価を表すフラグ、すなわち、受信したプレイリストに含まれるセグメントアドレス内のフラグを考慮しない。
図９を参照して、端末２００が最古セグメントを受信する例を説明する。端末２００がプレイリスト９１０を受信したとする。このとき、プレイリスト９１０にはセグメント情報として、第１セグメントのセグメント情報９００Ａのみが記載されている。このため、端末２００のＣＰＵ２０１は、第１セグメントを最古セグメントと判定して、カメラ１００から第１セグメントを取得する。また、端末２００がプレイリスト９５０を受信したとする。このとき、プレイリスト９５０にはセグメント情報として、第５セグメントのセグメント情報９００Ｄ及び第６セグメントのセグメント情報９００Ｅが記載されている。このため、端末２００のＣＰＵ２０１は、第５セグメントを最古セグメントと判定して、カメラ１００から第５セグメントを取得する。

図１１のステップＳ７５１において、端末２００のＣＰＵ２０１は、取得したプレイリストに含まれるセグメント情報から、フラグがセットされていない（必要性が高いと評価された）セグメントの中で最も古いセグメントのセグメント情報を取得する。なお、以降では、フラグがセットされていないセグメントの中で最も古いセグメントをフラグ未セット最古セグメントという。
その後、ＣＰＵ２０１は、フラグ未セット最古セグメントの取得要求をカメラ１００に送信し、カメラ１００からの応答でフラグ未セット最古セグメントを受信する。そして、ＣＰＵ２０１は、受信したフラグ未セット最古セグメントを、ＲＡＭ２０３又は記録媒体２１２に記録したり、表示部２０７で再生表示したりする。なお、ステップＳ７５０及びステップＳ７５１のフラグ未セット最古セグメントの取得要求は、受信装置の第１送信手段による処理の一例である。

図９を参照して、端末２００がフラグ未セット最古セグメントを受信する例を説明する。端末２００がプレイリスト９４０を受信したとする。プレイリスト９４０には、第３から第５セグメントについてのセグメント情報９００Ｂ、Ｃ、Ｄが含まれる。このうち、フラグがセットされていないのは、第４セグメントについてのセグメント情報９００Ｃのみである。このため、端末２００のＣＰＵ２０１は、第４セグメントをフラグ未セット最古セグメントと判定して、カメラ１００から第４セグメントを取得する。このとき、カメラ１００は、第４セグメントのセグメント情報９００Ｃ、及び、端末２００に送信した第４セグメントより古いセグメントである第３セグメントのセグメント情報９００Ｂをプレイリスト９４０から削除する。このため、カメラ１００が管理するプレイリストはプレイリスト９４１になる。

このように、本実施形態では、輻輳等によってカメラ１００に未送信のセグメントがたまると、端末２００は、必要度が高いと評価されたセグメントを優先的にカメラ１００から受信する。そして、カメラ１００では、必要度が低いと評価されたセグメントが削除されていき、必要度が低いと評価されたセグメントは端末２００に送信されない。したがって、通信の輻輳の抑制や緩和ができる。そして、端末２００は、必要度が高いと評価されたセグメントを効率的に受信できる。

本実施形態では、カメラ１００に未送信のセグメントが所定数たまると、端末２００は、必要度が高いと評価されたセグメントをカメラ１００から受信するようになる。しかし、端末２００は、カメラ１００の未送信のセグメントの数によらずに、必要度が高いと評価されたセグメントをカメラ１００から受信するようにしてもよい。
この場合、端末２００は、必要度が高いと評価されたセグメントを優先的にカメラ１００から受信する。そして、カメラ１００では、必要度が低いと評価されたセグメントが削除されていき、必要度が低いと評価されたセグメントは端末２００に送信されない。したがって、端末２００は、必要度が高いと評価されたセグメントを効率的に受信できる。

また、端末２００は、取得要求を行ったセグメントより古いセグメントの削除要求をカメラ１００に送信してもよい。このとき、カメラ１００は、削除要求がされたセグメントをＲＡＭ２０３又は記録媒体２１２から削除し、削除要求がされたセグメントのセグメント情報をプレイリストから削除する。なお、削除要求の送信は、受信装置の第２送信手段の一例である。
また、端末２００は、プレイリストに、必要度が低いと評価されたセグメントのセグメント情報が、所定数あるとき又は所定数続くときは、必要度が低いと評価されたセグメントであっても、カメラ１００から受信するようにしてもよい。
また、必要度が低いと評価されるセグメントを端末２００からカメラ１００に要求するか否かを、ユーザが設定できるようにしてもよい。

＜その他の実施形態＞
上記の実施形態では、カメラ１００はライブストリーミングを行う。しかし、カメラ１００は、記録媒体１１２等に記録されている、既に存在するメディアデータを端末２００に送信するようにしてもよい。このとき、図６のステップＳ６０１において、カメラ１００のＣＰＵ１０１は、メディアデータを分割して、所定の再生時間Ｔｓを持つセグメントを生成する処理を開始する。
本発明は、上記の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
以上、本発明を実施形態と共に説明したが、上記実施形態は本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００ カメラ
２００ 端末

Claims (19)

1. メディアデータを受信装置に送信する送信装置であって、
   メディアデータの一部に対応するセグメントデータを生成する生成手段と、
   前記生成手段で生成したセグメントデータを評価する評価手段と、
   前記評価手段の評価に基づいて、セグメントデータについての情報の一覧であるセグメントリストを管理する管理手段と、
   前記管理手段で管理する前記セグメントリストを送信する第１送信手段と、
   前記生成手段で生成したセグメントデータを送信する第２送信手段と、を備えることを特徴とする送信装置。
2. 前記管理手段は、前記評価手段が所定の評価をしたセグメントデータの情報を前記セグメントリストに追記しないことを特徴とする請求項１に記載の送信装置。
3. 前記管理手段は、前記セグメントリストに所定数以上のセグメントデータの情報があるとき、前記評価手段が所定の評価をしたセグメントデータの情報を前記セグメントリストに追記しないことを特徴とする請求項２に記載の送信装置。
4. 前記管理手段は、前記セグメントリストに所定数以上のセグメントデータの情報があるとき、前記評価手段が所定の評価をしたセグメントデータの情報を前記セグメントリストから削除することを特徴とする請求項１に記載の送信装置。
5. 前記管理手段は、前記評価手段の評価を前記セグメントリストに含めることを特徴とする請求項１に記載の送信装置。
6. 前記評価手段は、セグメントデータに含まれる映像データから顔検出がされるか否かに基づいて、セグメントデータを評価することを特徴とする請求項１乃至５の何れか１項に記載の送信装置。
7. 前記評価手段は、セグメントデータに含まれる映像データに動きがあるか否かに基づいて、セグメントデータを評価することを特徴とする請求項１乃至５の何れか１項に記載の送信装置。
8. 前記評価手段は、セグメントデータに含まれる音声データが所定値以上の音量であるか否かに基づいて、セグメントデータを評価することを特徴とする請求項１乃至５の何れか１項に記載の送信装置。
9. 前記評価手段は、セグメントデータに含まれる映像データから所定以上の振動が検知されるか否かに基づいて、セグメントデータを評価することを特徴とする請求項１乃至５の何れか１項に記載の送信装置。
10. 前記管理手段は、前記第２送信手段が送信するセグメントデータの情報を前記セグメントリストから削除することを特徴とする請求項１乃至９の何れか１項に記載の送信装置。
11. 前記管理手段は、前記第２送信手段が送信するセグメントデータが表す時間より前の時間を表すセグメントデータについての情報を前記セグメントリストから削除することを特徴とする請求項１０に記載の送信装置。
12. 送信装置からメディアデータを受信する受信装置であって、
    所定の周期で、メディアデータの一部を示すセグメントデータについての情報の一覧であるセグメントリストを受信する第１受信手段と、
    前記セグメントリストに含まれるセグメントデータの評価が所定の評価であるセグメントデータについての取得要求を前記送信装置に送信する第１送信手段と、
    前記送信装置からセグメントデータを受信する第２受信手段と、を備えることを特徴とする受信装置。
13. 前記第１送信手段は、前記セグメントリストに所定数以上のセグメントデータの情報があるとき、前記セグメントリストに含まれるセグメントデータの評価が所定の評価であるセグメントデータについての取得要求を前記送信装置に送信することを特徴とする請求項１２に記載の受信装置。
14. セグメントデータの削除要求を送信する第２送信手段をさらに備えることを特徴とする請求項１２又は請求項１３に記載の受信装置。
15. メディアデータを送信する送信装置とメディアデータを受信する受信装置とを備える通信システムであって、
    メディアデータの一部を示すセグメントデータを生成する生成手段と、
    前記生成手段で生成したセグメントデータを評価する評価手段と、
    前記評価手段の評価が所定の評価であるセグメントデータの送受信を制御する制御手段と、を備えることを特徴とする通信システム。
16. メディアデータを受信装置に送信する送信装置の制御方法であって、
    メディアデータの一部に対応するセグメントデータを生成する生成ステップと、
    前記生成ステップで生成したセグメントデータを評価する評価ステップと、
    前記評価ステップでの評価に基づいて、セグメントデータについての情報の一覧であるセグメントリストを管理する管理ステップと、
    前記セグメントリストを送信する第１送信ステップと、
    前記生成ステップで生成したセグメントデータを送信する第２送信ステップと、を備えることを特徴とする送信装置の制御方法。
17. 送信装置からメディアデータを受信する受信装置の制御方法であって、
    所定の周期で、メディアデータの一部を示すセグメントデータについての情報の一覧であるセグメントリストを受信する第１受信ステップと、
    前記セグメントリストに含まれるセグメントデータの評価が所定の評価であるセグメントデータについての取得要求を前記送信装置に送信する第１送信ステップと、
    前記送信装置からセグメントデータを受信する第２受信ステップと、を備えることを特徴とする受信装置の制御方法。
18. メディアデータを受信装置に送信する送信装置を制御するためのプログラムであって、
    メディアデータの一部に対応するセグメントデータを生成する生成ステップと、
    前記生成ステップで生成したセグメントデータを評価する評価ステップと、
    前記評価ステップでの評価に基づいて、セグメントデータについての情報の一覧であるセグメントリストを管理する管理ステップと、
    前記セグメントリストを送信する第１送信ステップと、
    前記生成ステップで生成したセグメントデータを送信する第２送信ステップと、をコンピュータに実行させるためのプログラム。
19. 送信装置からメディアデータを受信する受信装置を制御するためのプログラムであって、
    所定の周期で、メディアデータの一部を示すセグメントデータについての情報の一覧であるセグメントリストを受信する第１受信ステップと、
    前記セグメントリストに含まれるセグメントデータの評価が所定の評価であるセグメントデータについての取得要求を前記送信装置に送信する第１送信ステップと、
    前記送信装置からセグメントデータを受信する第２受信ステップと、をコンピュータに実行させるためのプログラム。

Images