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