(57)【要約】【課題】ストリーミングでの視聴において、サーバ側の状況を考慮した遅延時間を算出する技術を実現する。【解決手段】撮像装置と通信可能な通信装置であって、前記撮像装置により得られた映像データを所定の時間長に分割し、分割したセグメントの情報を記述したリストの要求を前記撮像装置に送信する第１の送信手段と、前記撮像装置から、前記要求したリストを受信する第１の受信手段と、前記撮像装置から受信したリストに記述されたセグメントの数と時間長とから遅延時間を算出する算出手段と、前記撮像装置から受信したリストに記述されたセグメントの要求を前記撮像装置に送信する第２の送信手段と、前記要求に応じて前記撮像装置から送信されたセグメントを受信する第２の受信手段と、を有する。【選択図】図３
2015023416.tif 000002
【特許請求の範囲】
【請求項１】
撮像装置と通信可能な通信装置であって、
前記撮像装置により得られた映像データを所定の時間長に分割し、分割したセグメントの情報を記述したリストの要求を前記撮像装置に送信する第１の送信手段と、
前記撮像装置から、前記要求したリストを受信する第１の受信手段と、
前記撮像装置から受信したリストに記述されたセグメントの数と時間長とから遅延時間を算出する算出手段と、
前記撮像装置から受信したリストに記述されたセグメントの要求を前記撮像装置に送信する第２の送信手段と、
前記要求に応じて前記撮像装置から送信されたセグメントを受信する第２の受信手段と、を有することを特徴とする通信装置。
【請求項２】
前記算出手段で算出した遅延時間を表示する表示手段をさらに有することを特徴とする請求項１に記載の通信装置。
【請求項３】
前記撮像装置に対して、全てまたは指定された数のセグメントの情報を前記リストから削除する指示を行う指示手段をさらに有することを特徴とする請求項１または２に記載の通信装置。
【請求項４】
通信装置と通信可能な撮像装置であって、
撮像手段と、
前記撮像手段により得られた映像データを所定の時間長のセグメントに分割して保持する保持手段と、
前記保持手段に保持されたセグメントの情報を記述したリストを作成する作成手段と、
前記通信装置から、リストの要求を受信する第１の受信手段と、
前記通信装置から要求された前記リストを前記通信装置に送信する第１の送信手段と、
前記通信装置から前記リストに記述されたセグメントの要求を受信する第２の受信手段と、
前記通信装置から要求されたセグメントを前記通信装置に送信する第２の送信手段とを備え、
前記作成手段は、前記通信装置から受信した削除要求に応じて、全てまたは指定された数のセグメントの情報を前記リストから削除することを特徴とする撮像装置。
【請求項５】
前記作成手段は、セグメントを得るたびに、得られたセグメントの情報を前記リストに追記すると共に、前記第２の送信手段によりセグメントを送信した場合、対応するセグメントの情報を前記リストから削除することを特徴とする請求項４に記載の撮像装置。
【請求項６】
撮像装置と通信可能な通信装置の制御方法であって、
前記撮像装置により得られた映像データを所定の時間長に分割し、分割したセグメントの情報を記述したリストの要求を前記撮像装置に送信する第１の送信ステップと、
前記撮像装置から、前記要求したリストを受信する第１の受信ステップと、
前記撮像装置から受信したリストに記述されたセグメントの数と時間長とから遅延時間を算出する算出ステップと、
前記撮像装置から受信したリストに記述されたセグメントの要求を前記撮像装置に送信する第２の送信ステップと、
前記要求に応じて前記撮像装置から送信されたセグメントを受信する第２の受信ステップと、を有することを特徴とする通信装置の制御方法。
【請求項７】
通信装置と通信可能な撮像装置の制御方法であって、
撮像手段により得られた映像データを所定の時間長のセグメントに分割し、分割したセグメントの情報を記述したリストを作成する作成ステップと、
前記通信装置から、リストの要求を受信する第１の受信ステップと、
前記通信装置から要求された前記リストを前記通信装置に送信する第１の送信ステップと、
前記通信装置から前記リストに記述されたセグメントの要求を受信する第２の受信ステップと、
前記通信装置から要求されたセグメントを前記通信装置に送信する第２の送信ステップとを備え、
前記作成ステップでは、前記通信装置から受信した削除要求に応じて、全てまたは指定された数のセグメントの情報を前記リストから削除することを特徴とする撮像装置の制御方法。
【請求項８】
コンピュータを、請求項１ないし３のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。
【請求項９】
コンピュータを、請求項４または５に記載の撮像装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はネットワークを介した二つの機器間におけるデータ伝送に関するものである。
【背景技術】
【０００２】
従来より、ストリーミングの技術として、従来ファイル転送などに用いられていたＨＴＴＰ（Hypertext Transfer Protocol）／ＴＣＰ（Transmission Control Protocol）プロトコルを利用して、ストリーミングデータの転送を行う方法がある。この方法でストリーミングを行うと、ネットワーク状況により輻輳遅延が発生する。これに対して、クライアントのバッファに蓄積されている動画パケットの通常再生時間をフレーム数及びフレームレートに基づいて計算すると共にバッファ内合計再生時間を算出し、時間の大小に応じて動画再生速度を決定する技術がある（特許文献１）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１１−２４４０９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記特許文献１では、クライアント（動画再生端末）のバッファのみを考慮して遅延時間を算出しており、動画配信サーバ側の状況を考慮した遅延時間が算出できない。
【０００５】
本発明は、上記課題に鑑みてなされ、その目的は、ストリーミングでの視聴において、サーバ側の状況を考慮した遅延時間を算出する技術を実現することである。
【課題を解決するための手段】
【０００６】
上記課題を解決し、目的を達成するため、本発明の通信装置は、撮像装置と通信可能な通信装置であって、前記撮像装置により得られた映像データを所定の時間長に分割し、分割したセグメントの情報を記述したリストの要求を前記撮像装置に送信する第１の送信手段と、前記撮像装置から、前記要求したリストを受信する第１の受信手段と、前記撮像装置から受信したリストに記述されたセグメントの数と時間長とから遅延時間を算出する算出手段と、前記撮像装置から受信したリストに記述されたセグメントの要求を前記撮像装置に送信する第２の送信手段と、前記要求に応じて前記撮像装置から送信されたセグメントを受信する第２の受信手段と、を有する。
【発明の効果】
【０００７】
本発明によれば、ストリーミングでの視聴において、サーバ側の状況を考慮した遅延時間を算出することが可能となる。
【図面の簡単な説明】
【０００８】
【図１】本発明に係る実施形態の撮像装置の構成を例示するブロック図。
【図２】本発明に係る実施形態の通信装置の構成を例示するブロック図。
【図３】本実施形態のシステムによるライブストリーミング動作を説明する図。
【図４】本実施形態のプレイリストを例示する図。
【図５】本実施形態の撮像装置の動作を示すフローチャート。
【図６】本実施形態の通信装置の動作を示すフローチャート。
【図７】実施形態２の撮像装置の動作を示すフローチャート。
【図８】本実施形態の通信装置におけるライブストリーミング画面を例示する図。
【発明を実施するための形態】
【０００９】
以下に、添付図面を参照して本発明を実施するための形態について詳細に説明する。尚、以下に説明する実施の形態は、本発明を実現するための一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されるべきものであり、本発明は以下の実施の形態に限定されるものではない。
【００１０】
以下、本発明を、サーバとしての撮像装置１０００と、クライアントとしての通信装置２０００とを通信可能に接続したシステムを例に説明する。この例では、撮像装置１０００で撮影された映像をリアルタイムに順次送信することで、通信装置２０００でライブストリーミングにより映像が視聴可能となる。なお、ライブストリーミングの詳細については後述する。本実施形態では、撮像装置１０００をデジタルビデオカメラ、通信装置２０００をスマートフォンなどの通信端末に適用した例を説明するが、本発明は、これに限られない。例えば、本発明は、撮像装置として、カメラ付き携帯電話や携帯型のメディアプレーヤ、いわゆるタブレット端末など、通信装置として、パーソナルコンピュータなどの情報処理装置や携帯電話、タブレットデバイス端末、テレビなどにも適用できる。
【００１１】
＜撮像装置の構成＞図１を参照して、本発明に係る実施形態の撮像装置の構成及び機能の概略について説明する。
【００１２】
図１に示す撮像装置（以下、カメラ）１０００において、内部バス１０１０に対してＣＰＵ(Central Processing Unit)１００１、ＲＯＭ(Read Only Memory)１００２、ＲＡＭ(Random Access Memory)１００３、入力処理部１００４、出力処理部１００６、通信制御部１００８、記録媒体制御部１０１１、カメラ信号処理部１０１５、符号・復号処理部１０１６が接続される。内部バス１０１０に接続される各部は、内部バス１０１０を介して互いにデータのやりとりを行える。
【００１３】
ＲＯＭ１００２は、ＣＰＵ１００１が動作するための各種プログラムや設定データが格納される。また、フラッシュメモリなども含まれる。ＲＡＭ１００３は、ＣＰＵ１００１が動作時に必要とするプログラムや変数、作業用の一時データなどが適宜記憶される。
【００１４】
ＣＰＵ１００１は、ＲＯＭ１００２または記録媒体１０１２に格納されるプログラムに従い、ＲＡＭ１００３をワークメモリとして用いて、このカメラ１０００の各部を制御する。
【００１５】
光学系１０１３は、フォーカス、絞り機構などを含む撮影レンズであり、被写体の光学像を形成する。撮像素子１０１４は、ＣＣＤやＣＭＯＳ素子等で構成され、ここではＡ／Ｄ変換器を含み、光学像をアナログ電気信号に変換した後、デジタル信号に変換する。
【００１６】
カメラ信号処理部１０１５は、ＣＰＵ１００１の制御に基づき、撮像素子１０１４で変換されたデジタル信号に対し、所定の画素補間・縮小といったリサイズ処理や色変換、各種補正処理等を行う。
【００１７】
符号・復号処理部１０１６は、ＣＰＵ１００１の制御に基づき、カメラ信号処理部１０１５で処理されたデジタル信号を所定のビットレート、フォーマット形式で圧縮符号化、または映像圧縮符号化データの復号を行う。
【００１８】
なお、音声についてはとくに図示していないが、音声付き映像を配信する場合には、マイクロホン、音声のアナログ信号をデジタル化するＡ／Ｄ変換器、デジタルデータを符号化する構成を持つことになる。当然、映像記録時には映像と共に音声も同時に収録され、符号・復号処理部１０１６で映像と音声を多重化することで、音声付映像データを生成することになる。
【００１９】
入力処理部１００４は、操作部１００５でのユーザ操作を受け付け、操作に応じた制御信号を生成し、ＣＰＵ１００１に供給する。例えば、操作部１００５は、ユーザ操作を受け付ける入力デバイスとして、キーボードといった文字情報入力デバイスや、マウスやタッチパネルといったポインティングデバイスなどを有する。また、赤外線リモコンなどの遠隔操作可能なものも含む。なお、タッチパネルは、例えば平面的に構成された入力部に対して接触された位置に応じた座標情報が出力されるようにした入力デバイスである。これにより、カメラ１０００に対し、ユーザ操作に応じた動作を行わせることができる。
【００２０】
出力処理部１００６は、ＣＰＵ１００１がプログラムに従い生成したＧＵＩ(Graphical User Interface)などの表示データに基づき、表示部１００７に対して表示させるための表示信号を出力する。
【００２１】
なお、操作部１００５としてタッチパネルを用いる場合、操作部１００５と表示部１００７とを一体的に構成することができる。例えば、タッチパネルを光の透過率が表示部１００７の表示を妨げないように構成し、表示部１００７の表示面の上層に取り付ける。そして、タッチパネルにおける入力座標と、表示部１００７上の表示座標とを対応付ける。これにより、あたかもユーザが表示部１００７上に表示された画面を直接的に操作可能であるかのようなＧＵＩを構成することができる。
【００２２】
記録媒体制御部１０１１は、ＨＤＤや不揮発性の半導体メモリなどの記録媒体１０１２が接続され、ＣＰＵ１００１の制御に基づき、接続された記録媒体１０１２からのデータの読み出しや、当該記録媒体１０１２に対するデータの書き込みを行う。なお、記録媒体制御部１０１１が接続可能な記録媒体１０１２は、不図示のソケットなどを介して、例えばメモリカードなどの着脱可能な不揮発性の半導体メモリを接続するものとしても良い。
【００２３】
記録媒体１０１２は、撮影した映像データのほか、ＣＰＵ１００１の制御に必要な情報も記録することが可能である。
【００２４】
通信制御部１００８は、ＣＰＵ１００１の制御に基づき、コネクタ(有線)/アンテナ(無線)１００９を介して、通信装置２０００その他の外部装置との通信を行う。通信方法としては、無線のＩＥＥＥ８０２．１１やＢｌｕｅｔｏｏｔｈ（登録商標）、有線のＩＥＥＥ８０２．３などを用いることが可能である。
【００２５】
なお、ハードウェアの構成は図１に示すものに限定されず、例えば１つのハードウェアが表示制御、通信制御、記録制御、画像処理制御などを行い、カメラ１０００の各手段として機能してもよい。また、複数のハードウェアが協働して１つの手段として機能してもよい。
【００２６】
＜通信装置の構成＞次に、図２を参照して、本発明に係る実施形態の通信装置の構成及び機能の概略について説明する。
【００２７】
図２に示す通信装置（以下、端末）２０００において、多くの部分はカメラ１０００と同様となるため、カメラ１０００と説明が重複するＣＰＵ２００１〜記録媒体２０１２までの説明は省略する。符号・復号処理部２０１３は、ＣＰＵ２００１の制御に基づき、映像圧縮符号化データの復号、および必要に応じて復号したデータの再符号化を行う。
【００２８】
＜ライブストリーミング動作の説明＞次に、本実施形態のシステムによるプレイリストを利用したライブストリーミング動作について説明する。
【００２９】
まず、本実施形態のシステムにおけるプレイリストを用いたストリーミングの基本動作について説明する。
１．カメラ（サーバ）は、ストリーミングデータを一定時間のセグメントに分割し、そのセグメント取得先を列挙したプレイリストを作成する。ライブストリーミングの場合には、リアルタイムにコンテンツが生成されることに応じて定期的にセグメントが生成される。このため、ライブストリーミングの場合には、新しいセグメントが生成されると、動的に新しい内容のプレイリストに更新（削除、追記）するスライドウインドウ型プレイリストを用いる。
２．端末（クライアント）は、プレイリストを取得・解析し、列挙順にセグメントデータ取得先からデータ取得を行う。
３．端末（クライアント）は、取得したデータの再生表示、または保存を行う。
４．カメラ（サーバ）と端末（クライアント）は、プレイリスト終了（ストリーミング終了）まで、１〜３を繰り返す。
【００３０】
上記基本動作を踏まえ、図１ないし図３、図８を参照して、本実施形態のシステムによるプレイリストを利用したライブストリーミング動作について説明する。
【００３１】
ユーザがカメラ１０００において、操作部１００５からライブストリーミングモードを実行すると、カメラ１０００は、ＣＰＵ１００１の制御により、通信制御部１００８を通信可能状態とする。
【００３２】
さらにユーザは端末２０００において、操作部２００５を操作して通信接続処理およびライブストリーミングに必要なアプリケーションの起動を行う。これに応じて、端末２０００のＣＰＵ２００１は、ＲＯＭ２００２または記録媒体２０１２に格納された当該プログラムに従い、通信制御部２００８を制御し、カメラ１０００との通信を開始し、接続処理を行う。
【００３３】
ここで、カメラ１０００と端末２０００は、通信プロトコルとしてＨＴＴＰ（Hypertext Transfer Protocol）／ＴＣＰ（Transmission Control Protocol）を使用するものとする。また、通信接続においてＵＰｎＰ（Universal Plug and Play）に対応しているものとする。ＵＰｎＰ対応の端末２０００は、機器をネットワークに接続すると、ＤＨＣＰ(Dynamic Host Configuration Protocol)または、ＡｕｔｏＩＰによるＩＰ(Internet Protocol)アドレスの設定を行う。ＩＰアドレスを取得した機器は、ネットワーク上の他の機器を相互に認識するために、「デバイスディスカバリとコントロール」によって、デバイス検索と応答デバイスの種別、サービス機能などの情報取得を行う（ステップ３００３）。カメラ１０００は、端末２０００のデバイス検索要求に対して、機器情報と機器固有情報のプレイリスト取得先情報などを応答する（ステップ３００４）。
【００３４】
カメラ１０００と端末２０００の接続処理が完了すると、カメラ１０００はライブストリーミングを開始する。
【００３５】
図８は、端末２０００における、ライブストリーミングにおけるアプリケーション画面例であり、操作部２００５、表示部２００７が一体化された例を示している。ライブストリーミングデータは、表示エリア８００１に表示され、カメラ１０００のステータスはズーム位置情報８００２、記録状態８００３、バッテリー情報８００４、後述する遅延時間８００８などを表示している。また、操作手段としてズーム指示８００５、カメラＲＥＣ８００６、端末ＲＥＣ８００７、後述する遅延短縮８００９などを備えている。
【００３６】
ライブストリーミングにおいて、カメラ１０００のＣＰＵ１００１は、撮像素子１０１４からの信号出力を開始し、その出力をカメラ信号処理部１０１５により適切な映像データに処理し、符号・復号処理部１０１６へデータを送出する。
【００３７】
図３の説明に戻り、符号・復号処理部１０１６では、受け取った映像データ等を所定のビットレート、フォーマット形式で圧縮符号化し、さらに所定の時間長Ｔｓで分割し、セグメントデータ（３００２）としてＲＡＭ１００３または記録媒体１０１２に保存する。なお、本実施形態ではＴｓ＝０．５秒として、以下説明する。
【００３８】
ＣＰＵ１００１は、上記セグメントデータの保存先と関連させたパス情報を生成する。パス情報は、端末２０００がセグメントを取得する際の取得先情報として使用するもので、ＣＰＵ１００１は、プレイリスト３００１を作成し、上記パス情報と併せてセグメント情報を記録する。
【００３９】
ここで、図４を参照して、プレイリスト３００１について説明する。
【００４０】
図４（ａ）に示すプレイリスト４０１０は、Ｅｘｔｅｎｄｅｄ  Ｍ３Ｕ形式のプレイリストであり、最初の行４０１１に識別子タグを記述し、２行目４０１２にはプレイリストバージョンを示すタグとバージョンを記述する。本例ではバージョンを“３”としている。３行目４０１３はセグメントデータ３００２の時間を示すタグとその時間（秒）を整数または小数で記述する。本実施形態では、セグメントデータ時間長をＴｓ＝０．５（秒）としていることから、本例でも“０．５”としている。４行目４０１４はセグメントデータ３００２の取得先パス（クエリパラメータを含む）を記述する。３行目４０１３および４行目４０１４はセグメントデータ３００２に関する情報として、必ず続けて記述する必要がある。
【００４１】
また、プレイリスト４０１０は、セグメント情報４０１３、４０１４を記録した図３のプレイリスト３００１の内容例となる。
【００４２】
端末２０００は、セグメントデータ３００２の所定の時間長Ｔｓを事前に記憶しているか、カメラ１０００の機器情報に含めることで機器情報取得時に得ることができているものとする。
【００４３】
端末２０００は、ライブストリーミング開始後、約Ｔｓ（秒）後にステップ３００４で取得したプレイリスト取得先へ、プレイリスト取得要求（ＨＴＴＰ  ＧＥＴメソッド）を行う（ステップ３００５）。
【００４４】
カメラ１０００は、応答プレイリストとして、セグメント情報４０１３、４０１４が一つ記述されたプレイリスト３００１（＝４０１０）を送信する（ステップＳ３００６）。
【００４５】
端末２０００は、受信したプレイリスト４０１０を解析し、遅延時間の算出を行う。また、端末２０００は、受信したプレイリスト４０１０を解析し、セグメント情報の取得先に対して、セグメント取得要求（ＨＴＴＰ  ＧＥＴメソッド）を行う（ステップ３００７）。
【００４６】
カメラ１０００は、応答セグメントとして、要求されたセグメント３００２を送信する（ステップ３００８）。
【００４７】
端末２０００は、受信したセグメント３００２を符号・復号処理部２０１３に渡し、復号した後、出力処理部２００６を介して、表示部２００７で再生表示を行う。また、ライブストリーミングアプリケーションにより、ユーザから端末ＲＥＣ８００７への指示入力があると、復号したデータ、またはセグメント３００２からヘッダなどを除いたデータ部を、記録媒体２０１２に記録する。そして、さらに順次受信するセグメントデータについても受信済みのデータと結合し記録していく。
【００４８】
ストリーミング中、カメラ１０００は、約Ｔｓ（秒）毎にセグメント生成、プレイリスト更新を行う。また、端末２０００に取得されたセグメント情報はプレイリストから削除する。
【００４９】
端末２０００は、カメラ１０００にてプレイリストの更新を行う度、その約Ｔｓ（秒）毎にそのプレイリスト取得（ステップ３００５）を行い、プレイリスト３００１に記載されたセグメント情報に基づき、当該セグメントデータを取得要求する。
【００５０】
通信状況が良好である場合、上記プレイリスト取得（ステップ３００５）から応答セグメント（ステップ３００８）までの一連の処理が定期的に行われることになる。しかし、実際には、輻輳などにより通信が定期的に行えなくなることがある。図４（ｂ）は、輻輳時を含んだプレイリスト４０２０の例を示している。プレイリスト４０２０には、３つのセグメント情報が記述されている。
【００５１】
なお、端末２０００の要求処理（ステップ３００５、３００７）には端末、またはアプリケーションの固有のＩＤを付加する。そして、本実施形態のカメラ１０００は、最初に要求のあったＩＤの要求のみに対してストリーミングを行う。つまり、本実施形態のカメラ１０００と端末２０００は１対１接続でのみストリーミングを行うものとする。
【００５２】
＜システムの動作説明＞次に、図５および図６を参照して、本実施形態のシステムを構成するカメラ１０００および端末２０００の動作について説明する。
【００５３】
まず、図５を参照して、カメラ１０００が端末２０００と接続確立後、カメラ１０００が実行する処理を説明する。なお、以下の処理はカメラ１０００のＣＰＵ１００１が各種プログラムや入力信号に基づきカメラ１０００の各部を制御することで実現する。
【００５４】
ステップＳ５００１では、ライブストリーミング開始に伴う、セグメントデータ生成の開始処理を行う。ＣＰＵ１００１は、撮像素子１０１４からの信号出力を開始し、その出力をカメラ信号処理部１０１５により適切な映像データに処理し、符号・復号処理部１０１６へデータを渡す。符号・復号処理部１０１６では、受け取った映像データを所定のビットレート、フォーマット形式で圧縮符号化し、さらに所定の時間長Ｔｓ（本実施形態では０．５秒とする）で分割する処理を開始する。
【００５５】
ステップＳ５００２では、一つのセグメント（０．５秒）生成が完了したか否かの判定を行う。０．５秒で分割されたデータが、ＲＡＭ１００３または記録媒体１０１２に一時的に保存されたことを確認し、完了していた場合にはステップＳ５００３へ進み、完了していない場合にはステップＳ５００５へ進む。なお、本ステップは問い合わせ（ポーリング）による判定で説明したが、分割したセグメントデータを書き込んだことを検出して割り込み通知を行う等の方法によって、生成完了を判定することも可能である。
【００５６】
ステップＳ５００３では、セグメント情報の生成を行う。生成されたセグメントデータの時間長と、当該セグメントデータを特定できる保存先アドレス、またはファイル名などに関連付けたパス情報を生成する。ここで、本実施形態の説明では、セグメントの時間長は０．５秒固定となる。
【００５７】
ステップＳ５００４では、ステップＳ５００３で生成したセグメント情報をプレイリストに追記する。
【００５８】
ステップＳ５００５では、端末２０００からのプレイリスト取得要求（ステップ３００５）の有無の判定を行う。プレイリスト取得要求があった場合にはステップＳ５００６へ進み、なかった場合にはステップＳ５００７へ進む。
【００５９】
ステップＳ５００６では、プレイリスト取得要求（ステップ３００５）に対する応答として、プレイリストの送信を行う（ステップ３００６）。
【００６０】
ステップＳ５００７では、端末２０００からのセグメント取得要求（ステップ３００７）の有無の判定を行う。セグメント取得要求があった場合にはステップＳ５００８へ進み、なかった場合にはステップＳ５００９へ進む。
【００６１】
ステップＳ５００８では、セグメント取得要求（ステップ３００７）に対する応答として、該当するセグメント送信（ステップ３００８）を行う。その後、当該送信済みとなったセグメントを削除するとともに、当該セグメントに関する情報をプレイリストから削除し、ステップＳ５００９へ進む。
【００６２】
ステップＳ５００９では、処理を終了するか否かの判定を行い、終了する場合以外はステップＳ５００２へ戻る。
【００６３】
なお、本フローでの各イベント判定ステップＳ５００２、Ｓ５００５、Ｓ５００７は、順に問い合わせによる判定で説明したが、各条件のイベント待ちを同時に行う場合には、イベント発生順に各処理を実行しても良い。
【００６４】
次に、図６を参照して、端末２０００がカメラ１０００と接続確立後、ＣＰＵ２００１が実行する処理を説明する。
【００６５】
ステップＳ６００１では、接続時に取得した機器・プレイリスト取得先情報（ステップ３００４）から、プレイリスト取得先情報を取得し、保持する。
【００６６】
ステップＳ６００２では、所定時間経過したか否かの判定を行う。所定時間が経過した場合にはステップＳ６００３へ進み、経過していない場合には再度ステップＳ６００２を繰り返す。ここで所定時間とは、カメラ１０００が生成する所定の時間長Ｔｓと同等の値にすることが望ましい。
【００６７】
ステップＳ６００３では、ステップＳ６００１で取得したプレイリスト取得先情報を用いて、プレイリストの取得要求（ステップ３００５）を行い、カメラ１０００から取得したプレイリストの解析を行う。プレイリストの解析では、識別タグによるプレイリスト形式とバージョンの確認を行った後、セグメント情報を取得する。
【００６８】
ステップＳ６００４では、ステップＳ６００３で取得したプレイリストの解析結果から、下記に示す式（１）にしたがって遅延時間の算出を行う。
【００６９】
遅延時間＝プレイリスト内のセグメント数×セグメントの時間長０．５秒・・・（１）
式（１）に示すように、本実施形態ではカメラ１０００側にどれだけのセグメントが溜まっているか、つまりカメラ１０００側のバッファ状況を考慮した遅延のみで遅延時間を算出している。しかしバッファ状況のみならず、その他の工程によって発生する遅延を加算して遅延時間を算出しても良い。
【００７０】
遅延時間の算出の例としては、例えばカメラ１０００のバッファ状況と自機（端末２０００）のバッファ状況の両方を考慮して遅延時間を算出しても良い。端末２０００側のバッファにセグメントが滞留する場合とは、例えば端末２０００の描画処理がセグメントの受信処理に対して遅い場合などが考えられる。
【００７１】
なお、算出結果を表示部２００７に渡し、図８に示した遅延時間８００８の表示を行うことも可能である。
【００７２】
ステップＳ６００５では、ステップＳ６００３でセグメント情報が存在したか否かの判定を行う。セグメント情報が存在した場合にはステップＳ６００６に進み、存在しない場合にはステップＳ６００３へ戻る。
【００７３】
ステップＳ６００６では、プレイリスト内の最古のセグメント情報の取得先パスに対してセグメントの取得要求（ステップ３００７）を行い、カメラ１０００からセグメントを取得する。ここで、取得したセグメント情報が１つならば、そのセグメントを最古セグメントとする。また、取得したセグメント情報が複数ならば最も古いセグメントを最古セグメントとする。取得したセグメントは、ＲＡＭ２００３または記録媒体２０１２に記録した後、符号・復号処理部２０１３に渡され、復号した後、出力処理部２００６を介して、表示部２００７で再生表示（映像表示）を行う。また、ライブストリーミングアプリケーションにより端末ＲＥＣ８００７が実行されている場合、本フローとは別の処理により、復号したデータ、またはセグメントからヘッダなどを除いたデータ部を、記録媒体２０１２に保存する。
【００７４】
ステップＳ６００７では、処理を終了するか否かの判定を行い、終了する場合以外はステップＳ６００２へ戻る。
【００７５】
［実施形態２］次に、実施形態２について説明する。
【００７６】
本実施形態は、端末２０００からの指示に従い、カメラ１０００のバッファデータを削除する例である。なお、本実施形態のシステム構成は実施形態１と同様であるため、その説明は省略する。また、セグメントの長さＴｓは、０．５秒とする点も実施形態１と同じである。
【００７７】
図８に示したライブストリーミング画面で、ユーザが表示エリア８００１に表示された遅延短縮８００９をタッチすることで、任意のタイミングでバッファデータの全削除を実行することができる。これにより、滞留していたセグメントの送信がキャンセルされ、遅延を解消することができる。具体的には、ユーザにより遅延短縮８００９が操作されると、ＣＰＵ２００１は、入力処理部２００４から削除指示を受け、通信制御部２００８を介して、プレイリスト取得要求およびセグメント取得要求とは異なる通信内容のバッファデータ全削除要求を行う。
【００７８】
図７は、端末２０００がカメラ１０００と接続確立後、ＣＰＵ２００１が実行する処理を示している。なお、図７のステップＳ７００１〜ステップＳ７００８は、図５のステップＳ５００１〜ステップＳ５００８と同様の処理であるため、その説明は省略する。
【００７９】
ステップＳ７００９では、端末２０００からのバッファデータ全削除要求の有無の判定を行う。バッファデータ全削除要求があった場合にはステップＳ７０１０へ進み、なかった場合にはステップＳ７０１１へ進む。
【００８０】
ステップＳ７０１０では、全セグメントを削除すると共に、全セグメント情報をプレイリストから削除する。例えば図４（ｂ）のプレイリスト４０２０は図４（ｃ）のプレイリスト４０３０となる。
【００８１】
ステップＳ７０１１では、処理を終了するか否かの判定を行う。終了する場合以外はステップＳ７００２へ戻る。
【００８２】
なお、本フローでの各イベント判定ステップＳ７００２、Ｓ７００５、Ｓ７００７、Ｓ７００９は、順に問い合わせによる判定で説明したが、各条件のイベント待ちを同時に行う場合には、イベント発生順に各処理を実行してもよい。
【００８３】
なお、本実施形態での削除要求は、バッファ内の全データとしたが、これに限らず、任意のデータ量を指定できるようにしても良い。
【００８４】
［他の実施形態］本発明は、以下の処理を実行することによっても実現される。即ち、上記実施形態の機能を実現するソフトウェア（プログラム）をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムコードを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
【図１】
2015023416.tif 000003
【図２】
2015023416.tif 000004
【図３】
2015023416.tif 000005
【図４】
2015023416.tif 000006
【図５】
2015023416.tif 000007
【図６】
2015023416.tif 000008
【図７】
2015023416.tif 000009
【図８】
2015023416.tif 000010