(57)【要約】【課題】通信で取得されるデータに関する情報を、効率的に生成する技術を提供する。【解決手段】本発明に係る映像供給装置は、映像データの一部を示すセグメントデータを外部装置に順次送信する映像供給装置であって、外部装置が受信したセグメントデータを格納するための、外部装置のバッファ手段に関する情報を取得する取得手段と、外部装置に送信するセグメントデータを格納する格納手段と、セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを生成する生成手段と、リストを外部装置に送信する送信手段と、を有する。ここで、生成手段は、外部装置のバッファ手段に関する情報に基づいてリストの生成方法を決定する。【選択図】図８
2017208672.tif 000002
【特許請求の範囲】
【請求項１】
映像データの一部を示すセグメントデータを外部装置に順次送信する映像供給装置であって、
前記外部装置が受信したセグメントデータを格納するための、前記外部装置のバッファ手段に関する情報を取得する取得手段と、
前記外部装置に送信するセグメントデータを格納する格納手段と、
前記セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを生成する生成手段と、
前記リストを前記外部装置に送信する送信手段と、を有し、
前記生成手段は、前記外部装置のバッファ手段に関する情報に基づいて前記リストの生成方法を決定することを特徴とする映像供給装置。
【請求項２】
前記外部装置のバッファ手段に関する情報は、前記外部装置のバッファ手段に保存可能な容量に応じて定まる、ことを特徴とする請求項１に記載の映像供給装置。
【請求項３】
前記バッファ手段に関する情報は、前記外部装置のバッファ手段に保存される前記セグメントデータのデータ量を示す指標であることを特徴とする請求項１又は２に記載の映像供給装置。
【請求項４】
前記指標は数値を含み、
前記生成手段は、前記数値が小さいほど前記リストが示すセグメントデータの数を制限する、ことを特徴とする請求項３項に記載の映像供給装置。
【請求項５】
前記生成手段は、前記リストが示すセグメントデータの数が前記外部装置のバッファ手段に関する情報が示す保存可能なセグメントデータの数より多い場合、前記リストに含まれる前記取得先情報のうち、前記外部装置によって受信されていない、最も古い前記セグメントデータの前記取得先情報を前記リストから削除する、ことを特徴とする請求項１から４のいずれか１項に記載の映像供給装置。
【請求項６】
前記生成手段は、新たに前記バッファ手段に保存される前記セグメントデータの前記取得先情報を前記リストに追加し、前記外部装置によって受信された前記セグメントデータの前記取得先情報を前記リストから削除する、ことを特徴とする請求項５に記載の映像供給装置。
【請求項７】
前記取得手段は、前記リストの送信に対する要求を前記外部装置から受信することにより、前記外部装置のバッファ手段に関する情報を取得する、ことを特徴とする請求項１から６のいずれか１項に記載の映像供給装置。
【請求項８】
前記生成手段は、前記外部装置において前記映像データが第１の使用用途で使用される場合、第２の使用用途で使用される場合より前記リストが示すセグメントデータの数を制限し、
前記第１の使用用途は、前記第２の使用用途よりも前記映像データのデータ欠損が許容される、ことを特徴とする請求項１から７のいずれか１項に記載の映像供給装置。
【請求項９】
前記第１の使用用途は、前記外部装置における前記映像データのライブ視聴を含み、前記第２の使用用途は、前記外部装置における前記映像データの記録を含む、ことを特徴とする請求項８に記載の映像供給装置。
【請求項１０】
撮像素子を更に有し、
前記映像データは前記撮像素子からの出力に基づく、ことを特徴とする請求項１から９のいずれか１項に記載の映像供給装置。
【請求項１１】
映像データの一部を示すセグメントデータを外部装置から順次受信する映像取得装置であって、
前記外部装置から受信したセグメントデータを格納するためのバッファ手段と、
前記外部装置に、前記バッファ手段に関する情報を通知する通知手段と、
前記セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを取得するリスト取得手段と、
前記リストに含まれる前記取得先情報に基づいて前記セグメントデータを受信する受信手段と、を有し、
前記リストは、前記通知手段により通知された前記バッファ手段に関する情報に基づきその内容が異なることを特徴とする映像取得装置。
【請求項１２】
前記バッファ手段に保存可能なデータ量を設定する設定手段を更に有し、
前記バッファ手段に関する情報は、前記設定手段により設定された前記バッファ手段に保存可能なデータ量に応じて定まる、ことを特徴とする請求項１１に記載の映像取得装置。
【請求項１３】
前記設定手段は、前記バッファ手段に保存可能なデータ量を前記映像データの使用用途に応じて設定することを特徴とする請求項１２に記載の映像取得装置。
【請求項１４】
前記設定手段は、第１の使用用途で前記映像データを使用する場合、第２の使用用途で使用する場合より前記バッファ手段に保存可能なデータ量を小さく設定し、
前記第１の使用用途は、前記第２の使用用途よりも前記映像データのデータ欠損が許容される、ことを特徴とする請求項１３に記載の映像取得装置。
【請求項１５】
前記バッファ手段に保存された前記セグメントデータを読み出して表示する表示手段を更に有する、ことを特徴とする請求項１１から１４のいずれか１項に記載の映像取得装置。
【請求項１６】
映像取得装置と、映像データの一部を示すセグメントデータを前記映像取得装置に順次送信する映像供給装置とを含む映像供給システムであって、
前記映像供給装置は、
前記映像取得装置が受信したセグメントデータを格納するための、前記映像取得装置のバッファ手段に関する情報を取得する取得手段と、
前記映像取得装置に送信するセグメントデータを格納する第１の格納手段と、
前記セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを生成する生成手段と、
前記リストを前記映像取得装置に送信する送信手段と、を有し、
前記映像取得装置は、
前記映像供給装置から受信したセグメントデータを格納するためのバッファ手段と、
前記映像供給装置に、前記バッファ手段に関する情報を通知する通知手段と、
前記映像取得装置から前記リストを取得するリスト取得手段と、
前記リストに含まれる前記取得先情報に基づいて前記セグメントデータを受信する受信手段と、を有し、
前記映像供給装置の前記生成手段は、前記外部装置のバッファ手段に関する情報に基づいて前記リストの生成方法を決定する、ことを特徴とする映像供給システム。
【請求項１７】
映像データの一部を示すセグメントデータを外部装置に順次送信する映像供給装置の制御方法であって、
取得手段が、前記外部装置が受信したセグメントデータを格納するための、前記外部装置のバッファ手段に関する情報を取得する取得工程と、
格納手段が、前記外部装置に送信するセグメントデータを格納する格納工程と、
生成手段が、前記セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを生成する生成工程と、
送信手段が、前記リストを前記外部装置に送信する送信工程と、を有し、
前記生成工程では、前記外部装置のバッファ手段に関する情報に基づいて前記リストの生成方法を決定することを特徴とする映像供給装置の制御方法。
【請求項１８】
映像データの一部を示すセグメントデータを外部装置から順次受信し、前記外部装置から受信したセグメントデータを格納するためのバッファ手段を有する映像取得装置の制御方法であって、
通知手段が、前記外部装置に、前記バッファ手段に関する情報を通知する通知工程と、
リスト取得手段が、前記セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを取得するリスト取得工程と、
受信手段が、前記リストに含まれる前記取得先情報に基づいて前記セグメントデータを受信する受信工程と、を有し、
前記リストは、前記通知手段により通知された前記バッファ手段に関する情報に基づきその内容が異なることを特徴とする映像取得装置の制御方法。
【請求項１９】
コンピュータを、請求項１から１０のいずれか１項に記載の映像供給装置の各手段として機能させるためのプログラム。
【請求項２０】
コンピュータを、請求項１１から１４のいずれか１項に記載の映像取得装置の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像供給装置、映像取得装置、それらの制御方法及びプログラム、並びに映像供給システムに関する。
【背景技術】
【０００２】
映像や音声のデータをダウンロードしながら同時に再生するストリーミング技術のうち、配信側が映像や音声をリアルタイムにエンコードして配信する、ライブストリーミング技術が知られている。従来のライブストリーミング技術では、リアルタイム性を重視してＵＤＰ（User Datagram Protocol）を用いたＲＴＰ（Realtime Transport Protocol）を利用するものが一般的であった。しかし、この技術では、データの到達が保証されないためデータの欠損などが発生することがあり、映像や音楽などのストリーミングデータを受信端末で記録したい場合などには不向きであった。このため、ネットワークを介して映像を送信するカメラにおいて、撮影した映像を連続的に送信する通常モードと、映像を一旦ファイルに格納して転送するファイル転送モードとをクライアントからの指示で切り替えるものが提案されている（特許文献１）。この技術は、ネットワークの負荷が重い場合には予め格納したファイルを転送することで欠損のないデータをクライアントが取得するものであるが、記録する映像が長時間である場合、ファイルの格納及び転送に時間がかかりリアルタイム性が失われてしまう。
【０００３】
一方、ＴＣＰ（Transmission Control Protocol）およびＨＴＴＰ（HyperText Transfer Protocol）を利用して低容量に分割したファイルを転送するライブストリーミング技術も提案されている。その方法の一つとして、ストリーミングデータを一定時間の低容量のファイルに分割したセグメントとこのセグメントの取得先を含むプレイリストとを利用したストリーミング方法がある。このストリーミング方法では、サーバが定期的にセグメントを生成するとともに新しいセグメントの取得先を示すプレイリストを更新する。クライアントは、サーバから送信されたプレイリストを取得・解析し、プレイリストに列挙された順に取得先からセグメントを取得して映像を再生する。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１５８５５２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、例えば上述のプレイリストを利用したストリーミング方法では、セグメントをデータの到達が保証される方法で転送するため、ネットワークの状況によって遅延した古いセグメントが蓄積するとセグメントの取得先を記述したプレイリストの情報量が増大してしまう。このような古いセグメントの情報は、例えばライブ試聴では不要な場合が多い。一般に通信で情報を伝える以上、その情報量は少ない方が望ましく、なるべく不要なデータを含まない方が効率的である。
【０００６】
本発明は、上述の問題点に鑑みてなされたものである。すなわち、通信で取得されるデータに関する情報を、効率的に生成する技術の提供を目的とする。
【課題を解決するための手段】
【０００７】
この課題を解決するため、例えば本発明の映像供給装置は以下の構成を備える。すなわち、映像データの一部を示すセグメントデータを外部装置に順次送信する映像供給装置であって、外部装置が受信したセグメントデータを格納するための、外部装置のバッファ手段に関する情報を取得する取得手段と、外部装置に送信するセグメントデータを格納する格納手段と、セグメントデータごとの取得先を示す取得先情報を１つ以上含むリストを生成する生成手段と、リストを外部装置に送信する送信手段と、を有し、生成手段は、外部装置のバッファ手段に関する情報に基づいてリストの生成方法を決定する、ことを特徴とする。
【発明の効果】
【０００８】
本発明によれば、通信で取得されるデータの取得に関する情報を、効率的に生成することが可能になる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態に係る映像供給装置の一例としてのデジタルカメラの機能構成例を示すブロック図
【図２】本実施形態に係る映像取得装置の一例としてのスマートフォンの機能構成例を示すブロック図
【図３】本実施形態に係るプレイリストを利用したライブストリーミングの概要を説明する図
【図４】本実施形態に係るプレイリストの一例を示す図
【図５】本実施形態に係るストリーミングアプリケーションの画面例を示す図
【図６】本実施形態に係る、輻輳が発生した場合に送受信されるプレイリスト及びセグメントの格納状態の例を説明する図（１）
【図７】本実施形態に係る、輻輳が発生した場合に送受信されるプレイリスト及びセグメントの格納状態の例を説明する図（２）
【図８】本実施形態に係るストリーミングデータの送信処理に係る一連の動作を示すフローチャート
【図９】本実施形態に係るストリーミングデータの受信処理に係る一連の動作を示すフローチャート
【発明を実施するための形態】
【００１０】
（実施形態１）
以下、本発明の例示的な実施形態について、図面を参照して詳細に説明する。なお、以下では映像供給装置の一例として、外部装置にストリーミングデータを送信可能な任意のデジタルカメラを用いる例を説明する。しかし、本実施形態は、デジタルカメラに限らず、データをストリーミングで送信可能な任意の機器にも適用可能である。これらの機器には、例えばスマートフォンを含む携帯電話機、ゲーム機、タブレット端末、時計型や眼鏡型の情報端末、医療機器、監視用システムのカメラやサーバ、車載用機器、データセンタで動作するサーバ機器や仮想マシンなどが含まれてよい。また、映像取得装置の一例として、外部装置からのストリーミングデータを受信可能な任意のスマートフォンを用いる例を説明する。しかし、本実施形態は、スマートフォンに限らず、ストリーミングデータを受信可能な任意の機器に適用可能である。これらの機器には例えばスマートフォン、ヘッドマウントディスプレイ、テレビ、上述した映像供給装置に適用可能な機器のいずれかが含まれてよい。
【００１１】
（デジタルカメラ１０００の構成）
図１は、本実施形態の映像供給装置の一例としてデジタルカメラ１０００の機能構成例を示すブロック図である。なお、図１に示す機能ブロックの１つ以上は、ＡＳＩＣやプログラマブルロジックアレイ（ＰＬＡ）などのハードウェアによって実現されてもよいし、ＣＰＵやＭＰＵ等のプログラマブルプロセッサがソフトウェアを実行することによって実現されてもよい。また、ソフトウェアとハードウェアの組み合わせによって実現されてもよい。従って、以下の説明において、異なる機能ブロックが動作主体として記載されている場合であっても、同じハードウェアが主体として実現されうる。
【００１２】
制御部１００１は、例えばＣＰＵ(Central Processing Unit)を含み、不揮発性メモリ１００２又は記録媒体１０１２に格納されたプログラムを実行してデジタルカメラ１０００の各部を制御する。また、制御部１００１は、ユーザからの操作を受け付ける操作部１００５からの操作信号に応じて、デジタルカメラ１０００の各部を制御する。
【００１３】
不揮発性メモリ１００２は、例えばフラッシュメモリ等で構成されるＲＯＭ(Read Only Memory)を含み、制御部１００１が動作するための各種プログラムや定数を記憶する。揮発性メモリ１００３は、例えばＤＲＡＭ等のＲＡＭ(Random Access Memory)を含み、動画データや静止画データ、音声データ等の各種のデータ、或いは、動作時に必要なプログラム、変数、作業用の一時データなどを記憶する。
【００１４】
入力処理部１００４は、操作部１００５に対するユーザ操作を受け付けて操作に応じた制御信号を生成し、制御部１００１に供給する。操作部１００５は、ユーザ操作を受け付ける入力デバイスを含み、例えば、キーボードといった文字情報入力デバイスや、マウスやタッチパネルといったポインティングデバイスなどを含む。また、赤外線リモコンなどの遠隔操作可能なものも含む。タッチパネルは、例えば平面的に構成された入力部に対する接触を受け付け、接触された位置に応じた座標情報を出力する。制御部１００１は、例えばタッチパネルに対するユーザ操作を特定し、デジタルカメラ１０００にユーザ操作に応じた動作を行わせることができる。
【００１５】
表示制御部１００６は、制御部１００１がプログラムに従って生成したＧＵＩ(Graphical User Interface)等の表示データに基づき、表示部１００７に表示させるための表示信号を出力する。表示部１００７は、液晶又は有機ＥＬ等の表示パネルを含み、表示制御部１００６が出力する表示信号を表示する。操作部１００５としてタッチパネルが用いられる場合、表示部１００７と操作部１００５とを一体的に構成することができる。例えば、光の透過率が表示部１００７の表示を妨げないようにタッチパネルを構成し、当該タッチパネルを表示部１００７の表示面の上層に取り付ける。そして、タッチパネルにおける入力座標と、表示部１００７上の表示座標とを対応付ける。これにより、ユーザが表示部１００７上に表示された画面を直接的に操作可能であるかのようなＧＵＩを構成することができる。
【００１６】
通信制御部１００８は、例えば通信制御用の回路を含み、コネクタ／アンテナ１００９を介してスマートフォン２０００と通信する。通信制御部１００８及びコネクタ／アンテナ１００９は、通信方式として、例えば３ＧやＬＴＥ、無線ＬＡＮを含むＩＥＥＥ８０２．１１、Ｂｌｕｅｔｏｏｔｈ（登録商標）又は有線のＩＥＥＥ８０２．３等を用いることができる。
【００１７】
内部バス１０１０は、デジタルカメラ１０００の各部を電気的に接続して、各部のデータの送受信を可能にする。記録媒体制御部１０１１は、接続された記録媒体１０１２からのデータの読み出しや当該記録媒体１０１２に対するデータの書き込みを行う。記録媒体１０１２は、ＨＤＤ等の磁気ディスクやメモリカード等の半導体メモリを含み、撮影した映像データや画像データを記録するほか、制御部１００１の制御に必要な情報を記録することができる。なお、記録媒体１０１２は、不図示のソケット等を介して着脱可能に構成されてよい。
【００１８】
光学系１０１３は、フォーカス、絞り、ズーム機構などを含む撮影レンズを含み、被写体の光学像を形成する。撮像素子１０１４は、例えば、ＣＣＤ又はＣＭＯＳ素子等で構成され、撮像素子に結像された光学像を電気信号に変換させた後、内部に有するＡ／Ｄ変換器によってアナログ電気信号をデジタル信号に変換する。
【００１９】
カメラ信号処理部１０１５は、例えば画像処理回路を含み、撮像素子１０１４から出力された画像データに対し、例えば、所定の画素補間、縮小等のリサイズ処理、色変換等の、各種補正処理等を行う。
【００２０】
符号・復号処理部１０１６は、カメラ信号処理部１０１５で処理されたデジタル信号を所定のビットレート、所定の形式で圧縮符号化を行うと共に、映像圧縮符号化データの復号化を行う。
【００２１】
なお、音声についてはとくに図示していないが、音声付き映像を順次送信する場合には、マイクロホン、音声のアナログ信号をデジタル化するＡ／Ｄ変換器、デジタルデータを符号化する構成を含むことになる。当然、映像記録時には映像と共に音声も同時に収録され、符号・復号処理部１０１６で映像と音声を多重化することで、音声付映像データを生成することになる。
【００２２】
（スマートフォン２０００の構成）
図２のスマートフォン２０００の機能構成例における制御部２００１〜記録媒体２０１２は、それぞれデジタルカメラ１０００について説明した制御部１００１〜記録媒体１０１２と同様の機能構成をとることができる。このため、デジタルカメラ１０００と説明が重複する制御部２００１〜記録媒体２０１２までの説明は省略する。符号・復号処理部２０１３は、制御部２００１の制御に基づき、映像圧縮符号化データの復号化、および必要に応じて復号化したデータの再符号化を行う。
【００２３】
（プレイリストを利用したライブストリーミングの概要）
次に、図３〜図５を参照して、本実施形態に係る、プレイリストを利用したライブストリーミングの概要について説明する。本実施形態に係る映像供給システムは、デジタルカメラ１０００とスマートフォン２０００とから構成され、デジタルカメラ１０００が送信側、スマートフォン２０００が受信側として動作してプレイリストを利用したライブストリーミングを行う。プレイリストを利用したライブストリーミングの基本的な動作は以下の通りである。
【００２４】
（１）デジタルカメラ１０００は、映像データの一部を所定の時間長のセグメントとし、そのセグメントを取得するためのアドレス（セグメント取得先）を１つ以上含むプレイリストを生成する。ライブストリーミングの場合には、定期的にセグメントが生成されるため、例えばスライドウインドウ型プレイリストが用いられる。スライドウインドウ型プレイリストは、新しいセグメントが生成されると、動的に新しい内容のプレイリストに更新（削除、追記）される。
【００２５】
（２）スマートフォン２０００は、プレイリストを取得してその内容を解析し、プレイリストに列挙されたセグメント取得先に基づいて、その列挙順に各セグメントを取得する。そして、（３）スマートフォン２０００は、取得したセグメントを再生表示し、又は記録する。（４）デジタルカメラ１０００とスマートフォン２０００は、プレイリストの終了（すなわちストリーミングの終了）まで、上述した（１）〜（３）の処理を繰り返す。
【００２６】
図３は、上述したライブストリーミングの基本的な動作を、より具体的に示している。デジタルカメラ１０００において、ユーザが操作部１００５を介してライブストリーミングモードの開始を指示すると、デジタルカメラ１０００は、制御部１００１の制御により、通信制御部１００８を通信可能状態にする。
【００２７】
一方、スマートフォン２０００において、ユーザが操作部２００５を介してデジタルカメラ１０００との通信の接続と、ライブストリーミングに必要なアプリケーションの起動とを指示する。このユーザの指示により、スマートフォン２０００の制御部２００１は、不揮発性メモリ２００２又は記録媒体２０１２に格納されたプログラムに従って通信制御部２００８を制御し、デジタルカメラ１０００との接続処理を開始する。
【００２８】
デジタルカメラ１０００とスマートフォン２０００とは、例えば通信プロトコルとしてＨＴＴＰ（HyperText Transfer Protocol）を使用し、ＵＰｎＰ（Universal Plug and Play）に対応した接続処理を行う。すなわち、スマートフォン２０００は、ユーザによって指定されたＩＰ(Internet Protocol)アドレス、或いは指定がない場合にはＤＨＣＰ(Dynamic Host Configuration Protocol)又はＡｕｔｏＩＰによるＩＰアドレスの設定を行う。
【００２９】
そして、Ｓ３００１において、スマートフォン２０００は、ネットワーク上の他の機器を認識するための「デバイスディスカバリとコントロール」によって、機器発見を行う。例えば、スマートフォン２０００は、デバイス検索を行うと共に応答デバイスの種別、サービス機能などの情報を取得するための要求を送信する。
【００３０】
Ｓ３００２において、デジタルカメラ１０００は、スマートフォン２０００のデバイス検索要求に対して、機器情報や機器固有情報としてプレイリスト取得先情報などを応答する。これにより、スマートフォン２０００は、デジタルカメラ１０００がライブストリーミングを提供可能なデバイスであること、及びデジタルカメラ１０００が提供するプレイリスト取得先情報を把握することができる。デジタルカメラ１０００とスマートフォン２０００の接続処理が完了すると、デジタルカメラ１０００はライブストリーミングを開始する。
【００３１】
ライブストリーミングが開始された際の動作を説明する前に、図５を参照して、スマートフォン２０００において動作するライブストリーミングアプリケーションの画面例について説明する。なお、図５に示す画面例は、タッチパネルのように操作部２００５と表示部２００７とが一体的に構成された例を示している。ライブストリーミングデータは、表示エリア５００１に表示され、デジタルカメラ１０００の各種ステータス（状態）を表す情報として、例えば、ズーム位置５００２、記録状態５００３、バッテリー状態５００４等が表示される。さらに、バッファサイズ設定５００８が押下された場合、一時的に格納するストリーミングデータの時間長（すなわちバッファの大きさ）を設定するためのバッファサイズ選択５００９が表示される。バッファサイズ選択５００９では、例えばユーザが選択可能な項目がセグメントの時間長Ｔｓの倍数で表示される。しかし、実際に割り当てるバッファサイズは、セグメントの最大ビットレートから算出可能である。
【００３２】
ＷＩＤＥ／ＴＥＬＥボタン５００５は、スマートフォン２０００からの遠隔操作によってデジタルカメラ１０００のズーム状態を変更するためのボタンである。また、カメラＲＥＣボタン５００６は、ユーザがデジタルカメラ１０００における記録開始・停止指示を実行するためのボタンである。また、端末ＲＥＣボタン５００７は、スマートフォン２０００において受信したライブストリーミングの記録開始・停止指示の各操作を行うためのボタンである。
【００３３】
再び図３を参照して、ライブストリーミングが開始された際の各装置の動作について説明する。デジタルカメラ１０００の制御部１００１は、撮像素子１０１４に信号出力を開始させ、その出力をカメラ信号処理部１０１５により適切な映像データにして、そのデータを符号・復号処理部１０１６へ入力する。このとき、ズーム倍率（もしくは焦点距離）等のデジタルカメラ１０００の各種ステータスに関する情報も合わせて入力する。符号・復号処理部１０１６は、入力された映像データ等を、所定のビットレート、所定の形式で圧縮符号化し、さらに所定の時間長Ｔｓで分割して、セグメント３５０２を生成する。生成されたセグメント３５０２は、符号・復号処理部１０１６から出力されて揮発性メモリ１００３又は記録媒体１０１２に保存される。なお、本実施形態では、Ｔｓは例えば０．５秒に設定される。
【００３４】
デジタルカメラ１０００の制御部１００１は、スマートフォン２０００からアクセス可能なセグメント３５０２と関連させたパス情報を生成する。パス情報は、スマートフォン２０００がセグメントを取得するための取得先を示す取得先情報である。なお、本実施形態ではパス情報はＵＲＬ形式で記述するが、これは現実のセグメントの物理的な保存先を示すものである必要はなく、単にセグメントとＵＲＬを関連付けしておけばよい。したがって、必ずしもＵＲＬを用いる必要はなく、他の識別子を用いてもよい。更に、制御部１００１は、後に図４で示すように、生成したパス情報を含んだプレイリスト３５０１を生成する。
【００３５】
図４には、本実施形態に係るプレイリスト３５０１の一例を示している。プレイリスト３５０１は、Ｅｘｔｅｎｄｅｄ  Ｍ３Ｕ形式のプレイリストであり、最初の行にはこのプレイリストの形式を示す識別子タグ４０１１が記述され、例えば「ＥＸＴＭ３Ｕ」と記述される。２行目には、バージョンタグ４０１２とプレイリストのバージョンを示すバージョンとが記述される。図４の例ではバージョンは例えば“３”である。３行目には、セグメント３５０２の時間長を示す時間長タグ４０１３と、整数又は小数で記述されるセグメントの時間長（秒）とが記述される。本実施形態では、例えばセグメントの時間長Ｔｓが０．５（秒）に設定されるため、記述される時間長は“０．５”となる。４行目には、セグメント３５０２のパス情報を示す取得先パス４０１４が記述される。このパス情報は、必要に応じてクエリパラメータを含んでもよい。クエリパラメータは例えばバッファサイズ等の数値を含む。３行目の時間長タグ４０１３と４行目の取得先パス４０１４とは、セグメント３５０２に関する情報として、続けて記述することができる。以降の説明では、時間長タグ４０１３と取得先パス４０１４の情報を合わせてセグメント情報ともいう。
【００３６】
ライブストリーミングが開始されると、Ｓ３００３において、スマートフォン２０００は、約Ｔｓ（秒）の経過ごとにプレイリスト取得要求（ＨＴＴＰ  ＧＥＴメソッド）を送信する。このとき、プレイリスト取得要求は、Ｓ３００２において得られたプレイリスト取得先に対して送信される。なお、スマートフォン２０００は、セグメント３５０２の所定の時間長Ｔｓを、例えば、予め記憶させた不揮発性メモリ２００２から読み出すか、デジタルカメラ１０００の機器情報に含まれる情報として取得する。Ｓ３００４において、デジタルカメラ１０００は、セグメント情報（すなわち時間長タグ４０１３及び取得先パス４０１４）が例えば１つ記述されたプレイリスト３５０１を、プレイリスト応答としてスマートフォン２０００に送信する。
【００３７】
Ｓ３００５において、スマートフォン２０００は、受信したプレイリスト３５０１を解析したうえで、セグメント情報に含まれる取得先パス４０１４に基づいて、セグメント取得要求（ＨＴＴＰ  ＧＥＴメソッド）をデジタルカメラ１０００に送信する。
【００３８】
これに対して、Ｓ３００６において、デジタルカメラ１０００は、セグメント応答として、要求されたセグメント３５０２をスマートフォン２０００に送信する。スマートフォン２０００は、受信したセグメント３５０２を、揮発性メモリ２００３又は記録媒体２０１２に設けた格納先の受信バッファ（再生バッファともいう）に一時的に格納（保存）する。そして、ストリーリングの受信開始時には、設定されたバッファサイズ設定に応じた時間分のデータを受信バッファに保存し、その後、バッファ内に保存されたセグメント３５０２を、符号・復号処理部２０１３によって復号化する。更に、スマートフォン２０００は、復号化したセグメント３５０２を、表示制御部２００６を介して表示部２００７に表示する。ユーザから端末ＲＥＣボタン５００７への操作が入力された場合、スマートフォン２０００は、復号化したセグメント３５０２（又はセグメント３５０２からヘッダ等を除いたデータ部）を、記録媒体２０１２に記録する。更に、順次受信するセグメント３５０２を結合して記録媒体２０１２に記録していく。
【００３９】
デジタルカメラ１０００は、ストリーミングを行っている際には、約Ｔｓ（秒）毎にセグメントの生成とプレイリストの更新とを繰り返す。また、プレイリストを更新する際には、スマートフォン２０００に取得されたセグメント情報をプレイリストから削除する。
【００４０】
スマートフォン２０００は、約Ｔｓ（秒）毎にプレイリスト取得要求（Ｓ３００３）を送信してプレイリストを取得するため、デジタルカメラ１０００において逐次更新される最新のプレイリストを取得することができる。そして、取得したプレイリストに記載されたセグメント情報に基づき、セグメントを取得する。
【００４１】
デジタルカメラ１０００とスマートフォン２０００の間の通信状況が良好である場合、プレイリスト取得要求（Ｓ３００３）からセグメント応答（Ｓ３００６）までの一連の処理が定期的に行われる。しかし、輻輳などにより通信状況が良好でなくなった場合、上記一連の処理が定期的に行えなくなる場合がある。このような場合、スマートフォン２０００では、セグメントが符号・復号処理部２０１３へ定期的に供給されなくなり、データの欠損が生じてストリーミングされた動画データをなめらかに再生することが困難になる。一般に、動画データの再生を安定させるため、再生を開始する前に（つまりセグメントを符号・復号処理部２０１３に渡すまでに）所定の時間分のセグメントをバッファに保存し、保存したデータを読み出して再生する。保存した所定の時間分のセグメントが多いほど、通信状況が悪化した際の影響を受けにくく、再生や記録時のデータの欠損は少なくなる。しかし、多くのセグメントを保存するほど、再生するセグメントの遅延（すなわちデジタルカメラ１０００で撮影されている映像に対する遅延）が大きくなる。このため、スマートフォン２０００では、デジタルカメラ１０００の撮影映像に対して遅延の少ない再生を優先するライブ視聴のような用途には、保存するデータ量を小さくしてリアルタイム性を向上させる。一方、遅延が大きくてもデータ欠損を抑制することを優先する記録時や滑らかな再生を要する用途では、保存するデータ量を大きくしてストリーミングデータの品質を向上させる。ユーザは、この保存可能なデータ量を、上述したストリーミングアプリケーションのバッファサイズ設定５００８において、用途に応じて設定することができる。
【００４２】
なお、スマートフォン２０００の要求処理（Ｓ３００３，３００７）には端末、又はアプリケーションの固有のＩＤを付加してよい。そして、本実施形態のデジタルカメラ１０００は、最初に要求のあったＩＤの要求のみに対してストリーミングを行う。つまり、本実施形態のデジタルカメラ１０００とスマートフォン２０００は１対１接続でのみストリーミングを行う。
【００４３】
（輻輳が発生した場合に送受信されるプレイリスト及びセグメントの格納状態の例）
次に、図６及び図７を参照して、輻輳が発生した場合に送受信されるプレイリスト及びセグメントの格納状態の例を説明する。図６は、バッファサイズを１に設定した場合のプレイリスト及びセグメントの格納状態の例を、図７は、バッファサイズを４に設定した場合のプレイリスト及びセグメントの格納状態の例を、それぞれ示している。
【００４４】
図６を参照すると、まず、デジタルカメラ１０００は、１番目（ｓｅｑ＝１）のセグメントを生成し、生成したセグメントを送信バッファに格納する。このとき、送信バッファのサイズが６つ分のセグメントを格納するように確保されている。このため、最も古いセグメントが格納される送信バッファの１番目の領域にセグメント（ｓｅｑ＝１）が格納されており、他の２〜６番目の領域は空の状態である。
【００４５】
一方、スマートフォン２０００では、例えばライブ視聴の用途のためにバッファサイズを１に設定しているため、受信バッファのサイズが１つ分のセグメントを格納するように確保されている。なお、スマートフォン２０００はセグメントを未だ受信していないため、受信バッファは空の状態である。
【００４６】
スマートフォン２０００は、プレイリストを取得するために、プレイリスト取得要求を送信する。このとき、スマートフォン２０００は、設定したバッファサイズが１であることを示すクエリパラメータ（ｂｎ＝１）を指定する（バッファサイズ通知）。すなわち、このクエリパラメータは、スマートフォン２０００がバッファに保存可能なセグメントデータのデータ量を示す指標となる。
【００４７】
デジタルカメラ１０００は、プレイリスト取得要求を受信すると、セグメント（ｓｅｑ＝１）に関するセグメント情報を含むプレイリスト６０１０（プレイリスト応答）をスマートフォン２０００に送信する。また、デジタルカメラ１０００は、プレイリスト取得要求のクエリパラメータに基づいて、受信バッファのバッファサイズを１に変更する。図６の送信バッファの例では、「Ｘ」の部分は送信バッファの領域として確保されていないことを表しており、バッファサイズ通知を受信した後の送信バッファはセグメント１つ分のバッファサイズに制限されている。スマートフォン２０００は当該プレイリスト６０１０を受信し、プレイリストの記述内容に応じて、例えばセグメント（ｓｅｑ＝１）に対するセグメント取得要求を送信する。
【００４８】
デジタルカメラ１０００は、セグメント取得要求を受信すると、セグメント（ｓｅｑ＝１）を送信する。デジタルカメラ１０００は、セグメント（ｓｅｑ＝１）の送信を完了（例えばスマートフォン２０００からａｃｋを受信）すると、送信バッファからセグメントを削除し、更にプレイリストから対応するセグメント情報を削除してプレイリスト６０１１に更新する。スマートフォン２０００は、セグメント（ｓｅｑ＝１）を受信すると、受信バッファに当該セグメントを格納し、その後再生のタイミングに応じて受信バッファからセグメントを読み出して再生する。読み出されたセグメントは受信バッファから削除される。
【００４９】
デジタルカメラ１０００は、新たなセグメント（ｓｅｑ＝２）を生成すると、送信バッファに格納し、プレイリストを対応するプレイリスト６０１２に更新する。輻輳が発生する等の通信状況の悪化がない場合、上記の処理を繰り返す。
【００５０】
デジタルカメラ１０００がセグメント（ｓｅｑ＝２）を送信した後に輻輳が発生した場合、デジタルカメラ１０００はスマートフォン２０００が送信するプレイリスト取得要求を受信することができない。輻輳が発生している間、デジタルカメラ１０００は定期的にセグメントを生成しているため、セグメントの生成に応じてプレイリストをプレイリスト６０３０から６０３２に順次更新する。このとき、送信バッファのサイズが１に設定されているため、セグメントが未送信であっても送信バッファに格納されるセグメントの数の上限が１であり、最も新しいセグメントのみが格納される。結果として、プレイリストのセグメント情報の数の上限も１であり、送信バッファに格納された１つのセグメントの情報のみが記述される。その後、輻輳が消滅すると、上述した輻輳発生前の処理が実行される。
【００５１】
次に、図７を参照して、バッファサイズを４に設定した場合のプレイリスト及びセグメントの例について説明する。なお、図７の説明では、ｓｅｑ＝７〜９のセグメントはすでにスマートフォン２０００によって受信されており、デジタルカメラ１０００はｓｅｑ＝１０のセグメントを生成するところから開始される。
【００５２】
スマートフォン２０００は、プレイリスト取得要求を送信する。このとき、スマートフォン２０００は、設定したバッファサイズが４であることを示すクエリパラメータ（ｂｎ＝４）を指定する（バッファサイズ通知）。当該プレイリスト取得要求を受信したデジタルカメラ１０００は、クエリパラメータに基づいて、送信バッファのバッファサイズを４に設定する。そして、デジタルカメラ１０００は、図６に示した例と同様に、セグメントの生成及びプレイリストの更新を行う（プレイリスト７０１０、７０１２）。
【００５３】
輻輳が発生すると、デジタルカメラ１０００は、送信バッファに格納可能な数（上限が４）までセグメントを格納する。すなわち、デジタルカメラ１０００は、送信バッファのサイズを４に制限しているため、４つまで増加したセグメント（ｓｅｑ＝１２〜１５）を蓄積することができる。プレイリストには４つのセグメント（例えばｓｅｑ＝１２〜１５）に対応するセグメント情報を記述し、その後４つのセグメント情報の更新を続ける（プレイリスト７０３０〜７０３２）。一方、スマートフォン２０００は、受信バッファに格納されたセグメントを再生タイミングに合わせて読み出すが、セグメントは新たに追加されない。
【００５４】
輻輳が消滅すると、デジタルカメラ１０００は、スマートフォン２０００からプレイリスト取得要求を受信して、蓄積されたセグメントのセグメント情報を含むプレイリスト７０３２を送信する。スマートフォン２０００はプレイリストに記述された先頭のセグメントから順次取得（順次受信）して受信バッファに格納し、その後格納されたセグメントを読み出して再生する。以降、輻輳発生前の処理を繰り返す。
【００５５】
このように、スマートフォン２０００の使用用途を反映したバッファサイズの設定に応じて、デジタルカメラ１０００でプレイリストの生成方法（すなわちプレイリストに記述するセグメントの数）を決定する。このようにすれば、スマートフォン２０００においてデータ欠損が許容されているにも関わらず、デジタルカメラ１０００側で不必要な古いセグメントを含んで巨大化し得るプレイリストを処理する計算資源の無駄を低減することができる。また、送信するプレイリストの情報量を小さくすることができるため、ネットワーク資源の効率化が可能になる。加えて、スマートフォン２０００においても、必要以上に大量のセグメント情報を含んだプレイリストを受信して、各セグメントにアクセスする処理の無駄を低減することができる。
【００５６】
なお、図６及び図７に係るバッファサイズの説明では、説明の便宜上、セグメントの数を例に説明した。しかし、バッファサイズの指定は、格納するセグメントのデータ量に対応するものであればデータサイズ、セグメントの再生時間、データ量に関連付けたスマートフォンの使用用途やアプリケーションの種類等、他の指定であってよい。
【００５７】
（ストリーミングデータの送信処理に係る一連の動作）
次に、図８を参照して、デジタルカメラ１０００におけるストリーミングデータの送信処理に係る一連の動作を説明する。なお、本処理は、デジタルカメラ１０００とスマートフォン２０００とが接続を確立したときに開始される。また、本処理は、制御部１００１が不揮発性メモリ１００２に記憶されたプログラムを揮発性メモリ１００３の作業用領域に展開、実行することにより実現される。
【００５８】
Ｓ８００１では、制御部１００１は、ライブストリーミングの開始に伴って、セグメントの生成を開始する。具体的に、撮像素子１０１４が制御部１００１の指示に応じて信号出力を開始し、その出力をカメラ信号処理部１０１５が適切な映像データに処理する。更に符号・復号処理部１０１６はカメラ信号処理部１０１５からの映像データを所定のビットレート、所定の形式で圧縮符号化し、さらに所定の時間長Ｔｓで分割する。また、制御部１００１は、バッファサイズを初期設定して、設定したバッファサイズを揮発性メモリ１００３に記憶する。初期設定として設定されるバッファサイズは、例えば、予め定めたスマートフォン２０００用の初期値や、制御部１００１がスマートフォン２０００の機器情報等から推定した値等である。
【００５９】
Ｓ８００２では、制御部１００１は、１つのセグメント（すなわち０．５秒分のデータ）の生成が完了したか否かを判定する。例えば、制御部１００１は、生成された０．５秒分のセグメントが、揮発性メモリ１００３又は記録媒体１０１２に一時的に格納されているかを判定する。生成されたセグメントの格納が完了している場合、制御部１００１は、セグメントの生成が完了したと判定してＳ８００３へ処理を進める。一方、セグメントの生成が完了していない場合、Ｓ８００７へ処理を進める。なお、本ステップの判定は、定期的な問い合わせ（ポーリング）を行って判定する例を説明したが、生成したセグメントが揮発性メモリ１００３等に書き込まれたことを検出した割り込み通知を受ける等の方法によって実現してもよい。
【００６０】
Ｓ８００３では、制御部１００１は、Ｓ８００２において生成したセグメントに対応するセグメント情報を生成する。制御部１００１は、セグメント情報に、生成したセグメントの時間長と、当該セグメントの取得先情報（保存先アドレス又はファイル名などに関連付けたパス情報）とを設定する。
【００６１】
Ｓ８００４では、制御部１００１は、プレイリストに含まれるセグメント情報の内容に、Ｓ８００３で生成したセグメントの内容を追記した場合に、セグメント情報に対応するセグメントのデータ量がバッファサイズを超えないかを判定する。例えば、制御部１００１は、追記によりセグメント情報が２つのセグメントを含むことになり、当該２つのセグメントのデータ量がＳ８００１で設定したバッファサイズを超える場合、処理をＳ８０１１へ進める。一方、当該２つのセグメントのデータ量がＳ８００１で設定したバッファサイズを超えない場合、処理をＳ８００６へ進める。なお、バッファサイズが後述するＳ８００９において更新されている場合、Ｓ８００１で設定したバッファサイズの代わりに、当該更新されたバッファサイズが用いられる。
【００６２】
Ｓ８００５では、制御部１００１は、バッファサイズを超えるセグメントを削除するとともに、当該セグメントに関する情報をプレイリストから削除する。例えば、制御部１００１は、送信バッファに格納されている最も古いセグメントを削除し、当該セグメントに対応するセグメント情報をプレイリストから削除する。このような処理を行うことにより、デジタルカメラ１０００で記憶するセグメントが、スマートフォン２０００のバッファサイズ（すなわち映像データの使用用途）に対して適正化される。
【００６３】
Ｓ８００６では、制御部１００１は、Ｓ８００３で生成したセグメント情報をプレイリストに追記する。Ｓ８００４からＳ８００６の処理により、単純に新たなセグメント情報が追加された場合、例えば図６に示したプレイリスト６０１１がプレイリスト６０１２のようになる。また、Ｓ８００５においてセグメント情報が削除された場合、プレイリスト６０３０がプレイリスト６０３１のようになる。
【００６４】
Ｓ８００７では、制御部１００１は、スマートフォン２０００から送信されたプレイリスト取得要求を受信しているかを判定する。制御部１００１は、例えば通信制御部１００８からの通知に基づいて、スマートフォン２０００からプレイリスト取得要求を受信したと判定した場合、Ｓ８００８へ処理を進める。一方、スマートフォン２０００からプレイリスト取得要求を受信していないと判定した場合、Ｓ８０１３へ処理を進める。
【００６５】
Ｓ８００８では、制御部１００１は、プレイリスト取得要求において通知されるクエリパラメータ（すなわちスマートフォン２０００の格納先に関する情報）が存在するか否かを判定する。制御部１００１は、プレイリスト取得要求に、スマートフォン２０００のバッファサイズが含まれている場合、Ｓ８００９へ処理を進める。一方、プレイリスト取得要求に当該バッファサイズが含まれていない場合、Ｓ８０１０へ処理を進める。
【００６６】
Ｓ８００９では、制御部１００１は、プレイリスト取得要求に含まれるクエリパラメータからバッファサイズを取得して、Ｓ８００１において設定したバッファサイズを更新する。なお、本一連の動作の説明では、バッファサイズを最大記憶セグメント数とする例を説明する。バッファサイズを最大記憶セグメント数とした場合の最大メモリサイズは、例えば最大セグメント数と、ストリーミングデータの最大ビットレート、セグメント時間に基づいて算出可能である。なお、バッファサイズは、他の情報からメモリサイズが算出可能であれば、最大記憶セグメント数以外の他の情報を用いてもよい。
【００６７】
Ｓ８０１０では、制御部１００１は、プレイリストに含まれるセグメント情報に対応するセグメントのデータ量が、Ｓ８００９で更新されたバッファサイズを超えていないかを判定する。なお、バッファサイズが更新されていない場合、Ｓ８００１において設定されたバッファサイズを用いる。制御部１００１は、セグメント情報に対応するセグメントのデータ量が、バッファサイズを超えていると判定した場合、Ｓ８０１１へ処理を進める。
【００６８】
Ｓ８０１１では、制御部１００１は、Ｓ８００５と同様に、バッファサイズを超えたセグメントを削除するとともに、当該セグメントに関する情報をプレイリストから削除する。このような処理を行うことにより、デジタルカメラ１０００で記憶するセグメントが、スマートフォン２０００のバッファサイズ（すなわちスマートフォン２０００における映像データの使用用途）に対して適正化される。Ｓ８０１２では、制御部１００１は、プレイリスト取得要求に応答して、通信制御部１００８を介してプレイリストを含んだプレイリスト応答を送信する。
【００６９】
Ｓ８０１３では、制御部１００１は、スマートフォン２０００からセグメント取得要求を受信したかを判定する。制御部１００１は、通信制御部１００８からの通知に基づいて、セグメント取得要求を受信したと判定した場合、Ｓ８０１４へ処理を進める。一方、予め定めた時間の間、セグメント取得要求を受信しなかったと判定した場合、Ｓ８００２へ再び処理を戻す。
【００７０】
Ｓ８０１４では、制御部１００１は、スマートフォン２０００から受信したセグメント取得要求に係るセグメントが有効か否かを判定する。例えば、制御部１００１は、セグメント取得要求に記述されたセグメントの識別子を参照して、当該識別子を有するセグメントが送信バッファに存在するかを判定する。制御部１００１は、要求された識別子のセグメントが受信バッファに存在する場合、セグメントが有効であると判定してＳ８０１５へ処理を進める。一方、既に受信バッファから該当するセグメントが削除されている等によりセグメントが存在しない場合、セグメントが無効であると判定してＳ８０１６へ処理を進める。
【００７１】
Ｓ８０１５では、制御部１００１は、セグメント取得要求に対する応答として、通信制御部１００８を介して該当するセグメントを送信する。その後、制御部１００１は、当該送信済みとなったセグメントを送信バッファから削除するとともに、当該セグメント対応するセグメント情報をプレイリストから削除する。このとき、例えばプレイリスト６０３０はセグメントが送信されてプレイリスト６０１１のようになる。
【００７２】
Ｓ８０１６では、制御部１００１は、セグメント取得要求に対する応答として、通信制御部１００８を介してエラーステータスを送信する。そして、Ｓ８０１７において、制御部１００１は、ストリーミングを終了するかを判定し、ストリーミングを終了しない場合、処理を再びＳ８００２に戻して上述した処理を繰り返す。一方、ストリーミングを終了すると判定した場合、本一連の動作を終了する。
【００７３】
なお、本一連の動作における判定ステップＳ８００２、Ｓ８００７、Ｓ８０１３は、順に問い合わせが発生する場合を例に説明したが、各条件のイベント待ちを並行して行う場合には、イベント発生順に各処理を実行してもよい。上記の説明から明らかなように、デジタルカメラ１０００は撮像素子１０１４によって新たなセグメントが生成されたタイミングやセグメントをスマートフォン２０００に送信したタイミングで、プレイリストを更新する処理を行うことができる。
【００７４】
（ストリーミングデータの受信処理に係る一連の動作）
次に、図９を参照して、スマートフォン２０００におけるストリーミングデータの受信処理に係る一連の動作を説明する。なお、本処理は、デジタルカメラ１０００とスマートフォン２０００とが接続を確立したときに開始される。また、本処理は、制御部２００１が不揮発性メモリ２００２に記憶されたプログラムを揮発性メモリ２００３の作業用領域に展開、実行することにより実現される。このとき、制御部２００１は、受信したセグメントを一時的に格納する受信バッファを、上述したバッファサイズ設定５００８のバッファサイズ選択５００９により設定された時間（Ｔｓの倍数（Ｎｔ））分、揮発性メモリ２００３又は記録媒体２０１２に確保する。
【００７５】
Ｓ９００１では、制御部２００１は、接続時に取得したプレイリスト取得先情報から、プレイリスト取得先を取得し、保持する。また、制御部２００１は、上述の受信バッファを確保するために用いたバッファサイズの設定を取得する。Ｓ９００２では、制御部２００１は、所定時間経過したか否かを判定する。例えば、制御部２００１は、不図示のタイマーのカウントに応じて所定時間が経過したかを判定し、所定時間が経過したと判定した場合、Ｓ９００３へ処理を進める。一方、所定時間が経過していないと判定した場合、再度Ｓ９００２を繰り返す。ここで所定時間とは、通常デジタルカメラ１０００が生成する所定の時間長Ｔｓと同等或いは短めの値にすることが望ましい。
【００７６】
Ｓ９００３では、制御部２００１は、ユーザがバッファサイズ設定５００８によってバッファサイズを変更したかを判定する。制御部２００１は、例えばＳ９００１において取得したバッファサイズと現在のバッファサイズとを比較して、バッファサイズが変更されているか否かを判定する。制御部２００１は、バッファサイズが更新されていないと判定した場合、Ｓ９００４へ処理を進める。一方、バッファサイズが更新されていると判定した場合、Ｓ９００５へ処理を進める。なお、バッファサイズが最大記憶セグメント数（Ｎｔ）に設定されているものとして説明する。
【００７７】
Ｓ９００４では、制御部２００１は、Ｓ９００１で取得したプレイリスト取得先情報に基づき、通信制御部２００８を介してプレイリスト取得要求を送信する。そして、デジタルカメラ１０００からプレイリストを取得（受信）する。一方、Ｓ９００５では、制御部２００１は、Ｓ９００３で更新されたバッファサイズをプレイリスト取得要求のクエリパラメータとして付加して、プレイリスト取得要求を送信する。プレイリスト取得要求は、Ｓ９００１で取得したプレイリスト取得先情報に基づき、通信制御部２００８を介して送信される。その後、制御部２００１は、デジタルカメラ１０００からプレイリストを取得する。
【００７８】
Ｓ９００６では、制御部２００１は、取得したプレイリストを解析する。プレイリストの解析では、識別タグによるプレイリスト形式とバージョンの確認を行った後に、セグメント情報を取得する。Ｓ９００７では、制御部２００１は、Ｓ９００６でセグメント情報が存在したか否かを判定する。制御部２００１は、例えば、プレイリストに含まれるセグメント情報の数（セグメント数：Ｓｎ）をカウントし、セグメント数に基づいてセグメント情報が存在するか否かを判定する。制御部２００１は、セグメント数が１以上である場合、セグメント情報が存在すると判定してＳ９００８へ処理を進める。一方、セグメント数が０である場合、セグメント情報が存在しないと判定してＳ９００３へ処理を戻す。
【００７９】
Ｓ９００８では、制御部２００１は、取得したセグメント情報に含まれるセグメント数Ｓｎが複数（すなわちＳｎ≧２）であるか否かを判定する。制御部２００１は、セグメント数に基づいてＳｎ≧２であると判定した場合、Ｓ９０１１へ処理を進める。一方、Ｓｎ＝１であると判定した場合、Ｓ９００９へ処理を進める。
【００８０】
Ｓ９００９では、制御部２００１は、プレイリストに含まる（１つの）セグメント情報の取得先パスに対してセグメント取得要求を送信し、デジタルカメラ１０００からセグメントを取得する。制御部２００１は、セグメント取得要求に、セグメント情報に記述されたセグメントの識別子を含める。Ｓ９０１０では、制御部２００１は、取得したセグメントを、揮発性メモリ２００３又は記録媒体２０１２に確保した受信バッファに格納する。
【００８１】
Ｓ９０１１では、制御部２００１は、プレイリスト内の１番目（最古）のセグメント情報の取得先パスに対してセグメント取得要求を送信し、デジタルカメラ１０００からセグメントを取得（受信）する。制御部２００１は、Ｓ９００９と同様、セグメント情報に記述されたセグメントの識別子をセグメント取得要求に含める。Ｓ９０１２では、制御部２００１は、取得したセグメントを、揮発性メモリ２００３又は記録媒体２０１２に用意した受信バッファに格納する。
【００８２】
Ｓ９０１３では、制御部２００１は、Ｓ９０１１において取得したセグメントの数の分だけセグメント数Ｓｎを減算（Ｓｎ＝Ｓｎ−１）した上でＳｎを評価する。制御部２００１は、Ｓｎ＞０である場合、残されたセグメントを取得するために、Ｓ９０１１に処理を戻す。一方、Ｓｎ＝０である場合、取得するセグメントがないため、Ｓ９０１４に処理を進める。なお、Ｓ９０１１からＳ９０１３の処理時間が、デジタルカメラ１０００で生成されるセグメントがプレイリストに追記される時間Ｔｓに対して、大幅に長くならないことを前提としている。しかし、Ｓ９０１３でＹｅｓであった場合であっても、さらにＳ９００４のプレイリスト取得からの経過時間を判定し、所定の時間を超える場合には、Ｓ９００３へ処理を戻してもよい。
【００８３】
Ｓ９０１４において、制御部２００１は、ストリーミングを終了するかを判定し、ストリーミングを終了しない場合、処理を再びＳ９００２に戻して上述した処理を繰り返す。一方、ストリーミングを終了すると判定した場合、本一連の動作を終了する。
【００８４】
なお、上述した実施形態では、デジタルカメラ１０００がクエリバラメータに応じてバッファサイズを変更し、当該バッファサイズの変更によりプレイリストに記述されるセグメント情報の数が変動するようにした。しかし、デジタルカメラ１０００は受信したクエリパラメータに応じて、プレイリストに記述されるセグメント情報の数を直接制御してもよい。このようにしても、プレイリストを効率的に生成することができる。
【００８５】
以上説明したように本実施形態では、スマートフォン２０００のバッファサイズの設定（格納先に関する情報）に応じて、デジタルカメラ１０００で格納するセグメントの数とプレイリストのセグメント情報の数とを制限するようにした。このようにすれば、ライブ視聴のようなリアルタイム性を優先する使用用途において、デジタルカメラ１０００側で不必要な古いセグメントを含むプレイリストを処理する計算資源の無駄を低減することができる。また、送信するプレイリストの情報量を小さくすることができるため、ネットワーク資源の効率化が可能になる。換言すれば、通信で取得されるデータの取得に関する情報を、効率的に生成することが可能になる。
【００８６】
（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００８７】
１００１…制御部、１００３…揮発性メモリ、１００８…通信制御部、１０１２…記録媒体、１０１４…撮像素子、２００１…制御部、２００５…操作部、２００６…表示制御部、２００８…通信制御部
【図１】
2017208672.tif 000003
【図２】
2017208672.tif 000004
【図３】
2017208672.tif 000005
【図４】
2017208672.tif 000006
【図５】
2017208672.tif 000007
【図６】
2017208672.tif 000008
【図７】
2017208672.tif 000009
【図８】
2017208672.tif 000010
【図９】
2017208672.tif 000011