JP2019068187A - 情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】ユーザの意図を適切に反映したスムーズな映像表示を可能にすることを課題とする。
【解決手段】符号・復号処理部（２１３）は、外部装置から受信したストリーミングのための映像データに基づく映像を再生する。ＣＰＵ（２０１）は、再生される映像を表示するための、予め保持された再生用画面を表示部（２０７）に表示させる。ＲＡＭ（２０３）は、外部装置から受信した映像データを、再生するために所定の記憶領域にバッファする。そして、ＣＰＵ（２０１）は、再生中の映像に関するユーザの操作を受け付けるための操作ＵＩを、再生中の映像とともに再生用画面に表示可能であり、再生用画面への操作ＵＩの表示の有無に応じて、ＲＡＭ（２０３）の映像データのバッファサイズを変更する。
【選択図】図２

Description

本発明は、ストリーミングデータを処理する情報処理装置、情報処理装置の制御方法、及びプログラムに関する。

ストリーミングデータを一定時間ごとに分割したセグメントデータとその情報を記述したプレイリストなどを利用してストリーミングを実現する手法が知られている。また、受信したストリーミングデータを再生する受信装置としては、スマートフォンやタブレット端末などの携帯型の情報処理装置が広く普及している。それら情報処理装置の特徴として、当該装置の利用者が任意のアプリケーションソフトウェア（以下、アプリと記す）を選択して自由にインストールできる点がある。

また、前述の携帯型の情報処理装置の他の特徴として、タッチパネルを備えている点がある。タッチパネルは、従来のボタンやスイッチ等と異なり、ソフトウェアに応じて、様々な操作入力方法をとることが可能である。このため、タッチパネルを応用した様々なアプリ、及び情報処理装置の使い方も提案されている。例えば、操作用のユーザインターフェイス（以下、操作ＵＩとする。）をタッチパネルの画面上に表示し、そのタッチパネル上の操作ＵＩを通じて他の外部装置を遠隔操作することも可能となされている。さらに、情報処理装置のアプリには、当該装置による遠隔操作を禁止して、画面上にストリーミングデータの映像のみを表示させるものも存在する。

その他、ストリーミングに関連した技術として、例えば特許文献１には、ホストが、端末から受信したコマンドに基づいて画質と表示のどちらを優先するのかを判断し、その判断結果を基に、端末側の受信バッファサイズを制御する技術が開示されている。また、特許文献２には、受信装置がネットワークを介してカメラを遠隔操作し、その遠隔操作を基に受信バッファサイズを制御する技術が開示されている。特許文献２に記載の技術では、例えばカメラの遠隔操作中はバッファサイズを小さくすることで、操作が映像に反映するまでの遅延を低減することを可能としている。

特願２００８−２８８６６７号公報 特開２００６−７４４４１号公報

ところで、例えば撮像装置による撮影映像をライブストリーミングにより送信して情報処理装置側で受信して表示する場合において、ユーザ(視聴者）は、ライブストリーミングの映像を確認しながら所望のタイミングで操作ＵＩの操作を行うことがある。ここで、特許文献１に記載の技術の場合、例えば通信の遅延が大きいと、ユーザがライブストリーミングの映像を観ながら操作ＵＩを通じて行った操作が、ユーザの意図通りの操作とならないケースが生ずることがある。また、特許文献１に記載の技術の場合、通信の遅延が大きいと、ユーザが画質と表示のどちらを意図した視聴を行っているのかをホスト側で判断するタイミングが遅れ、端末側の受信バッファサイズを変更するタイミングにも遅れが生ずることになる。また、特許文献２に記載の技術の場合、遠隔操作の実行中か否かでバッファサイズが変更されるため、例えば視聴目的で使用しているのかが明確ではないタイミングでバッファサイズの変化が生じてしまう虞がある。つまり、特許文献１と特許文献２の何れの技術の場合も、ユーザが映像を視聴する際の意図を必ずしも適切に反映できていないタイミングでバッファサイズが変更されることがある。このように、従来の技術の場合、ユーザの意図を必ずしも反映できていない、スムーズとは言い難い映像が表示されることがある。

そこで、本発明では、ユーザの意図を適切に反映したスムーズな映像表示を可能にすることを目的とする。

本発明は、情報処理装置であって、外部装置から受信したストリーミングのための映像データに基づき、映像を再生する再生手段と、前記再生手段により再生される映像を表示するための、前記情報処理装置に予め保持された再生用画面を表示部に表示する表示制御手段と、前記外部装置から受信した映像データを、前記再生手段による再生のために所定の記憶領域にバッファするバッファ手段とを有し、前記表示制御手段は、再生中の映像に関するユーザの操作を受け付けるための操作部を、前記再生中の映像とともに前記再生用画面に表示可能であり、前記再生用画面への前記操作部の表示の有無に応じて、前記バッファ手段は前記映像データのバッファサイズを変更することを特徴とする。

本発明によれば、ユーザの意図を適切に反映したスムーズな映像表示が可能となる。

実施形態のカメラの概略構成例を示す図である。 実施形態の情報端末の概略構成例を示す図である。 通信システムの通信シーケンスを示す図である。 プレイリストの例を示す図である。 情報端末の受信バッファの推移の例を示す図である。 情報端末の処理フローチャートである。 情報端末を縦向き姿勢で使用した時の画面例を示す図である。 情報端末を横向き姿勢で使用した時の画面例を示す図である。

以下、添付図面を参照しながら本発明に係る実施形態を詳細に説明する。
本実施形態は、本発明の情報処理装置の一例である情報端末と、撮影映像をライブストリーミングデータとして送信可能な撮像装置（カメラ）と、を含む通信システムを例に挙げて説明する。図１は本実施形態のカメラ１００の一構成例を示した図であり、図２は本実施形態の情報端末２００の一構成例を示した図である。なお、カメラ１００は、撮影機能をメイン機能として有するいわゆるデジタルスチルカメラやデジタルビデオカメラの他、カメラ機能付きの情報端末やタブレット端末であってもよい。また、カメラ機能を有するものに限定されず、例えば映像配信サーバなどを用いることも可能である。また、情報端末２００は、一般的なパーソナルコンピュータの他、いわゆるスマートフォンやタブレット端末などの携帯型の情報端末、テレビジョン受像機などであってもよい。

＜カメラと情報端末の構成説明＞
図１のカメラ１００は、光学系１１３、撮像素子１１４、操作部１０５、表示部１０７、コネクタ／アンテナ１０９、記録媒体１１２を有する。また、カメラ１００は、ＣＰＵ１０１、ＲＯＭ１０２、ＲＡＭ１０３、入力処理部１０４、出力処理部１０６、通信制御部１０８、記録媒体制御部１１１、カメラ信号処理部１１５、符号・復号処理部１１６を有する。これらは内部バス１１０により接続されており、内部バス１１０を介して互いにデータのやりとりを行うことができるようにされている。

ＲＯＭ１０２は、リードオンリメモリであり、ＣＰＵ１０１が動作するための各種プログラムや設定データを格納する。ＲＯＭ１０２は必ずしもリードオンリである必要はなく、例えば読み書き可能なフラッシュメモリなどを用いてもよい。ＲＡＭ１０３は、ランダムアクセスメモリであり、ＣＰＵ１０１が動作時に必要とするプログラムや変数、作業用の一時データなどを適宜記憶する。ＣＰＵ１０１は、中央処理ユニットであり、ＲＯＭ１０２または記録媒体１１２に格納されているプログラムを実行し、ＲＡＭ１０３をワークメモリとして用いて、このカメラ１００の各部を制御する。

光学系１１３は、フォーカスレンズ、ズームレンズ、絞り機構などを含む撮影レンズであり、被写体の光学像を撮像素子１１４上に形成する。撮像素子１１４は、ＣＣＤやＣＭＯＳ素子等で構成され光学像を撮像してアナログ電気信号に変換する。なお、撮像素子１１４にはＡ／Ｄ変換器も含まれ、光学像を撮像したアナログ電気信号をデジタルデータに変換して出力する。

カメラ信号処理部１１５は、ＣＰＵ１０１による制御に基づき、撮像素子１１４で変換されたデジタルデータの画像に対し、所定の画素補間・縮小といったリサイズ処理や色変換、各種補正処理等を行う。
符号・復号処理部１１６は、ＣＰＵ１０１による制御に基づき、カメラ信号処理部１１５で処理されたデジタルデータを所定のビットレート、フォーマット形式で圧縮符号化する。また、符号・復号処理部１１６は、映像圧縮符号化データの復号化も行う。

なお、音声のための構成は図示を省略しているが、カメラ１００は、マイクロホン、音声のアナログ信号をデジタル化するＡ／Ｄ変換器、音声のデジタルデータを符号化・復号化する構成をも備えており、音声付き映像の配信も可能となされている。このため、映像記録時には映像と共に音声も同時に収録され、符号・復号処理部１１６では、映像と音声を多重化することで音声付映像データを生成することになる。

入力処理部１０４は、操作部１０５を介したユーザ操作を受け付け、ユーザ操作に応じた制御信号を生成して、ＣＰＵ１０１に供給する。例えば、操作部１０５は、ユーザ操作を受け付ける入力デバイスとして、キーボードのような文字情報入力デバイスや、マウスやタッチパネルといったポインティングデバイスなどを有する。また、操作部１０５には赤外線リモコンなどの遠隔操作可能な入力デバイスも含まれる。なお、タッチパネルは、例えば平面的に構成された入力部に対して接触された位置に応じた座標情報が出力されるようにした入力デバイスである。これにより、カメラ１００は、ユーザ操作に応じた動作を行う。

出力処理部１０６は、ＣＰＵ１０１がプログラムを実行して生成したＧＵＩ（グラフィカルユーザインターフェイス）などの表示データに基づき、表示部１０７に対してＧＵＩの表示を行うための表示信号を出力する。
なお、操作部１０５としてタッチパネルが用いられる場合、操作部１０５と表示部１０７とは一体的な構成として使用されることになる。タッチパネルは光の透過率が表示部１０７の表示を妨げないように構成され、表示部１０７の表示面の上層側に配設される。そして、タッチパネルにおける入力座標と、表示部１０７上の表示座標とが対応付けられることで、恰もユーザが表示部１０７上に表示された画面を直接的に操作可能であるかのようなＧＵＩが実現される。

記録媒体制御部１１１は、ＨＤＤや不揮発性の半導体メモリなどの記録媒体１１２が接続され、ＣＰＵ１０１による制御に基づき、接続された記録媒体１１２からのデータの読み出しや、当該記録媒体１１２に対するデータの書き込みを行う。なお、記録媒体制御部１１１が接続可能な記録媒体１１２は、不図示のソケットなどを介して、例えばメモリカードなどの着脱可能な不揮発性の半導体メモリを接続するものとしてもよい。記録媒体１１２は、撮影した映像データのほか、ＣＰＵ１０１の制御に必要な情報も記録することが可能である。

通信制御部１０８は、ＣＰＵ１０１による制御に基づき、コネクタ／アンテナ１０９を介して、外部装置（本実施形態では情報端末２００）との通信を行う。なお、コネクタの場合は有線、アンテナの場合は無線による通信が行われる。通信方法としては、無線のＩＥＥＥ８０２．１１やＢｌｕｅｔｏｏｔｈ（登録商標）、有線のＩＥＥＥ８０２．３などを用いることが可能である。

図２の情報端末２００は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、入力処理部２０４、出力処理部２０６、通信制御部２０８、記録媒体制御部２１１、符号・復号処理部２１３、姿勢検出部２１４を有する。これらは内部バス２１０により接続されており、内部バス２１０を介して互いにデータのやりとりを行うことができるようにされている。また、情報端末２００は、操作部２０５、表示部２０７、コネクタ／アンテナ２０９も有している。

ＲＯＭ２０２は、ＣＰＵ２０１が動作するための各種プログラムや設定データを格納する。ＲＯＭ２０２にはフラッシュメモリなども含まれる。ＲＡＭ２０３は、ＣＰＵ２０１が動作時に必要とするプログラムや変数、作業用の一時データなどを適宜記憶する。ＣＰＵ２０１は、ＲＯＭ２０２または記録媒体２１２に格納されているプログラムを実行し、ＲＡＭ２０３をワークメモリとして用いて、情報端末２００の各部を制御する。

符号・復号処理部２１３は、コネクタ／アンテナ２０９を介して受信した映像圧縮符号化データや音声付映像データの復号化を行う。符号・復号処理部２１３は、圧縮されていない映像データや音声データの符号化や、復号化したデータの再符号化も可能である。

入力処理部２０４は、操作部２０５を介したユーザ操作を受け付けて、そのユーザ操作に応じた制御信号を生成して、ＣＰＵ２０１に供給する。操作部２０５は、前述同様の入力デバイスやポインティングデバイスを有する。情報端末２００がスマートフォンやタブレット端末である場合、操作部２０５は、主にタッチパネルにより構成される。

出力処理部２０６は、ＣＰＵ２０１がプログラムを実行して生成したＧＵＩなどの表示データに基づき、表示部２０７に対して再生用画面としての機能を有するＧＵＩを表示するための表示信号を出力する。操作部２０５がタッチパネルである場合、操作部２０５と表示部２０７とは前述同様に一体的な構成として使用される。そして、タッチパネルにおける入力座標と、表示部２０７上の表示座標とが対応付けられることで、恰もユーザが表示部２０７上に表示された画面を直接的に操作可能であるかのようなＧＵＩが実現される。以下、情報端末２００における操作用のＧＵＩを操作ユーザインターフェイス（操作ＵＩ）と表記する。

記録媒体制御部２１１は、ＨＤＤや不揮発性の半導体メモリなどの記録媒体２１２が接続され、ＣＰＵ２０１による制御に基づき、接続された記録媒体２１２からのデータの読み出しや、当該記録媒体２１２に対するデータの書き込みを行う。記録媒体制御部２１１が接続可能な記録媒体２１２は、不図示のソケットなどを介してメモリカードなどの着脱可能な不揮発性の半導体メモリを接続するものとしてもよい。記録媒体２１２は、映像や音声のデータのほか、ＣＰＵ２０１の制御に必要な情報も記録することが可能である。

通信制御部２０８は、ＣＰＵ２０１による制御に基づき、コネクタ／アンテナ２０９を介して、外部装置（本実施形態ではカメラ１００）との通信を行う。通信方法は、前述同様の各種通信方法を用いることができる。

姿勢検出部２１４は、情報端末２００の姿勢検出を行う。姿勢検出部２１４は、加速度センサおよび周辺回路で構成される。加速度センサは、地球の重力方向の加速度（重力加速度）を測定する。そして、姿勢検出部２１４は、情報端末２００がいわゆる縦向き姿勢か横向き姿勢かを検出する。例えば情報端末２００の外形が長方形状（画面が長方形）である場合、その長方形の長辺が地球の重力方向と略々同一方向である時、情報端末２００の姿勢は縦向き姿勢であるとして検出される。一方、長辺が重力方向に対して略々直角方向である時、情報端末２００の姿勢は横向き姿勢であるとして検出される。
ここまで、カメラ１００及び情報端末２００の構成について説明したが、各装置の構成は本実施形態で説明したものに限定されない。例えば、１つのプロセッサなどのハードウェアが入力信号やプログラムに応じて複数の手段として機能してもよい。また、複数のハードウェアが協働して動作することで１つの手段として機能してもよい。

＜ストリーミング動作の説明＞
前述の図１に示したカメラ１００と図２に示した情報端末２００とからなる通信システムにおいて、ライブストリーミングが行われる場合、カメラ１００は撮影映像データを情報端末２００に送信し、情報端末２００は受信した映像データを画面に表示する。以下、本実施形態の通信システムにおけるライブストリーミングの動作について、図１〜図８の各図を参照しながら説明する。

図３は本実施形態の通信システムにおけるストリーミング時の基本的な通信シーケンスの説明図である。なお、本実施形態の通信システムの場合、カメラ１００と情報端末２００との間の通信は、それぞれＣＰＵによる制御の下で通信制御部がコネクタ／アンテナを介することで行われるが、以下の説明ではそれらの記載は適宜省略する。

本実施形態の通信システムは、カメラ１００が撮影している映像を、プレイリストを用いたライブストリーミングデータとして情報端末２００に送信する。ここで、プレイリストを用いたストリーミングが行われる場合、下記の（１）〜（５）に示すように、接続処理、プレイリストの作成処理及びプレイリストの送信処理、セグメントの生成処理及びセグメントの送信処理等が行われる。

（１）ストリーミングの開始に先立ち、カメラ１００と情報端末２００の間では接続処理が行われる。接続処理では、ＩＰアドレスの設定及び取得、機器間の相互認識処理、機器情報と機器固有情報のプレイリスト取得先情報の相互取得処理などが行われる。この接続処理後、ストリーミングが開始される。
（２）カメラ１００は、ストリーミングデータを一定時間のセグメントに分割し、そのセグメント取得先を列挙したプレイリストを作成する。ライブストリーミングの場合には、定期的にセグメントが生成されるため、新しいセグメントが生成されると、動的に新しい内容のプレイリストに更新（削除、追記）するスライドウインドウ型プレイリストを用いる。
（３）情報端末２００は、プレイリストを取得・解析し、列挙順にセグメントデータ取得先からデータ取得を行い、所定の記憶領域としての受信バッファにデータを一時的に蓄積（バッファリング）する。
（４）情報端末２００は、受信バッファに蓄積したデータの再生表示、または保存を行う。
（５）カメラ１００と情報端末２００は、プレイリスト終了（ストリーミング終了）まで、（２）〜（４）の動作を繰り返す。

図７と図８は、情報端末２００において、ライブストリーミングが行われている際のアプリケーション画面例である。情報端末２００は、前述したように表示部２０７にタッチパネルの操作部２０５が一体化された構成となされているとする。なお、図７は、姿勢検出部２１４により情報端末２００が縦向き姿勢であると検出された場合の画面例である。図８は、姿勢検出部２１４により情報端末２００が横向き姿勢であると検出された場合の画面例である。

図７に示したような縦向き姿勢の場合、情報端末２００は、表示部２０７の画面上に、表示エリア７０１と、ステータス情報と、操作ＵＩとを表示可能である。表示エリア７０１は、ライブストリーミングデータに基づく映像が表示される領域である。ステータス情報はカメラ１００の状態を表す情報である。図７の例の場合、情報端末２００は、カメラ１００のステータス情報として、光学系１１３のズームレンズのズーム位置情報７０２、記録状態を表す記録状態情報７０３、バッテリー残量を示すバッテリー情報７０４等を表示させている。操作ＵＩには、再生中の映像に関するユーザの操作を受け付けるためのＵＩを含む情報端末２００の操作用のＵＩと、カメラ１００の遠隔操作用のＵＩとが含まれる。図７の例の場合、情報端末操作用のＵＩとしては、端末ＲＥＣボタン７０７が用意されている。この端末ＲＥＣボタン７０７がタッチ等されると、情報端末２００は、ライブストリーミングにより受信した映像データを当該端末内の記録媒体２１２に記録する。カメラ遠隔操作用のＵＩとしては、光学系１１３のズームレンズをワイド（ＷＩＤＥ）方向やテレ（ＴＥＬＥ）方向に操作するためのズーム指示ボタン７０５、撮影映像を記録させるカメラＲＥＣボタン７０６等が用意されている。情報端末２００は、ズーム指示ボタン７０５がタッチ等された場合にはカメラ１００に対しズーム位置を移動させるためのコマンドを送り、カメラＲＥＣボタン７０６がタッチ等された場合にはカメラ１００に対し映像記録を行わせるためのコマンドを送る。このように、図７の縦向き姿勢の場合、画面上にライブストリーミングの映像が映し出される表示エリア７０１とともに、操作ＵＩも表示されるため、ユーザは、この操作ＵＩを介してカメラ１００の遠隔操作を行うことができる。これら情報端末操作用及びカメラ遠隔操作用の操作ＵＩは、情報端末２００に予め用意（ＲＯＭ２０２又は記録媒体２１２にプログラムとして保持）されており、情報端末２００のＣＰＵ２０１がそのプログラムを実行することにより生成される。

図８に示した横向き姿勢の場合、情報端末２００は、表示部２０７の画面上に、例えば表示エリア８０１のみを表示する。表示エリア８０１は、ライブストリーミングデータに基づく映像が表示される領域である。つまり、横向き姿勢の場合、情報端末２００は、操作ＵＩを画面上に表示しない。したがって、縦向き姿勢の場合、図７の場合のような操作ＵＩによるカメラ１００の遠隔操作は行えなくなる。なお、操作ＵＩは、図８の例のように非表示とされる場合の他に、ユーザによる入力を受け付けないグレーアウト表示となされてもよい。また、図８では図示していないが、ステータス情報等については表示していてもよいし、表示しないようになされてもよい。このように、横向き姿勢の場合の情報端末２００は、ライブストリーミングの映像を画面全面の広い表示エリア８０１に表示する一方で、画面上には操作ＵＩを表示せず、ユーザによるカメラ１００の遠隔操作等の入力を受け付けない状態となる。

前述したように、本実施形態の情報端末２００は、ユーザにより、当該端末が縦向き姿勢で保持されている場合には図７にように表示エリア７０１とともに操作ＵＩも表示する設定となされている。一方、当該端末が横向き姿勢で保持されている場合、本実施形態の情報端末２００は、図８のように操作ＵＩを非表示として表示エリア８０１のみを表示する設定となされている。したがって、ユーザは、表示エリア７０１とともに操作ＵＩを表示したい場合には、情報端末２００を縦向き姿勢に保持し、表示エリア８０１のみを表示（操作ＵＩを非表示）にしたい場合には、情報端末２００を横向き姿勢に保持することになる。

そして、図７のように表示エリア７０１と共に操作ＵＩをも表示する縦向き姿勢となされた場合、表示エリア７０１の映像を観ながら操作ＵＩを介してカメラ１００を遠隔操作することが、ユーザの意図の中の一つであると考えられる。つまり、情報端末２００を図７のように縦向き姿勢で保持している場合、ユーザは、ライブストリーミングの映像を観つつ、カメラ１００に対する遠隔操作をいつでも行える状態になっていることを望んでいる可能性が高いと考えられる。一方、図８のように表示エリア８０１のみ表示して操作ＵＩを非表示にする横向き姿勢の場合、表示エリア８０１の映像を主に観ることが、ユーザの主要な意図であると考えてよい。つまり、情報端末２００を図８のように横向き姿勢で保持している場合、ユーザは、カメラ１００を遠隔操作することよりも、ライブストリーミングの映像の視聴を楽しむことを望んでいる可能性が高いと考えられる。

ここで、例えば前述した特許文献１に記載の技術のように、ホスト側から端末へ操作ＵＩを送信している場合、例えば輻輳により通信の遅延が発生すると、操作ＵＩのレスポンスも遅延し、ユーザ操作がユーザの意図した操作とならないことがある。
このため、本実施形態では、操作ＵＩを情報端末２００に予め用意しておき、通信遅延が生じていても操作ＵＩに影響が及ばないようにしている。さらに、本実施形態において図７の縦向き姿勢のように操作ＵＩを表示している場合、情報端末２００は、受信バッファのバッファサイズを小さくして、映像の遅延の影響を極力小さくしつつ操作ＵＩとの親和性を高めている。つまり、受信バッファサイズを小さくすることで、カメラ１００から送信された映像と情報端末２００に表示されている映像との間のタイムラグを少なくし、映像を観つつユーザにより行われた操作の意図が、カメラ１００側に即座に反映されるようにしている。一方、本実施形態の場合、図８の横向き姿勢のように、操作ＵＩを非表示にした場合、受信バッファのバッファサイズを大きくして、通信遅延の影響を受け難くして、高画質の映像の視聴の継続を可能としている。つまり、受信バッファサイズを大きくすることで、情報端末２００に表示される映像を途切れ難くしている。このように、本実施形態の情報端末２００は、予め用意されている操作ＵＩの表示の有無に基づき、遠隔操作と映像表示の親和性優先か又は途切れ難い映像表示を行う画質優先の、何れがユーザの意図であるのかを判定してバッファサイズを変更している。これにより、本実施形態の情報端末２００では、カメラ１００からのライブストリーミングの映像を表示する際に、ユーザの意図を適切に反映したスムーズな映像表示が可能となる。

以下、前述の図３に示した基本的な動作を踏まえ、本実施形態の通信システムにおけるライブストリーミングの動作、情報端末２００における操作ＵＩの有無に応じた受信バッファサイズの変更制御について、詳細に説明する。
先ず、カメラ１００は、操作部１０５を介してユーザからライブストリーミングモードの実行指示が入力されると、ＣＰＵ１０１の制御により、通信制御部１０８を通信可能状態とする。

また、情報端末２００は、操作部２０５を介してユーザから通信接続処理およびライブストリーミングに必要なアプリケーションソフトウェア（以下、アプリと記す）の起動指示が入力されると、ＣＰＵ２０１によりそのアプリを起動させる。これにより、情報端末２００のＣＰＵ２０１は、ＲＯＭ２０２または記録媒体２１２に格納された当該アプリのプログラムに従い、通信制御部２０８を制御し、カメラ１００との通信を開始して、接続処理を行う。

ここで、カメラ１００と情報端末２００は、通信プロトコルとしてＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使用するものとする。また、カメラ１００と情報端末２００は、通信接続においてＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）に対応しているものとする。ＵＰｎＰ対応の情報端末２００は、機器をネットワークに接続すると、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）または、ＡｕｔｏＩＰによるＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスの設定を行う。ＩＰアドレスを取得した機器は、ネットワーク上の他の機器を相互に認識するために、「デバイスディスカバリーとコントロール」によって、デバイス検索と応答デバイスの種別、サービス機能などの情報取得を行う。このため、ステップＳ３０３において、情報端末２００はカメラ１００へデバイス検索要求を送り、ステップＳ３０４において、カメラ１００は情報端末２００からのデバイス検索要求に対して機器情報と機器固有情報のプレイリスト取得先情報などを応答する。そして、カメラ１００と情報端末２００の接続処理が完了すると、カメラ１００はライブストリーミングを開始する。

ライブストリーミングを開始した場合、カメラ１００のＣＰＵ１０１は、撮像素子１１４からの信号出力を開始し、その出力をカメラ信号処理部１１５により適切な映像データに処理し、符号・復号処理部１１６へデータを送る。このとき、ズーム倍率（もしくは焦点距離）等のカメラステータスに関する情報も合わせて、符号・復号処理部１１６に送る。

符号・復号処理部１１６は、それら受け取った映像データ等を所定のビットレート、フォーマット形式で圧縮符号化し、図３に示すように、さらに所定の時間長Ｔｓで分割し、セグメントデータ３０２としてＲＡＭ１０３または記録媒体１１２に保存する。なお、本実施形態では、例えば所定の時間長Ｔｓ＝０．５秒として、以下の説明を行う。

また、ＣＰＵ１０１は、セグメントデータ保存先と関連させたパス情報を生成する。パス情報は、情報端末２００がセグメントを取得する際の取得先情報として使用するものである。そして、ＣＰＵ１０１は、プレイリスト３０１を作成し、パス情報と併せてセグメント情報を一時記録する。

ここで、プレイリスト３０１について詳細に説明する。図４は、本実施形態に係るプレイリスト４１０の一例を表す図である。プレイリスト４１０は、例えばＥｘｔｅｎｄｅｄ Ｍ３Ｕ形式のプレイリストとなされる。
カメラ１００のＣＰＵ１０１は、プレイリスト４１０の最初の行４１１には識別子タグを記述し、次（２行目）の行４１２にはプレイリストバージョンを示すタグとバージョンを記述する。図４には、バージョンが"３"の例を挙げている。またＣＰＵ１０１は、３行目の行４１３にはセグメントデータ３０２の時間を示すタグとその時間（秒）を、整数または小数の値で記述する。本実施形態では、セグメントデータ時間長をＴｓ＝０．５（秒）としていることから、図４の例でも時間は"０．５"秒なされている。さらに、ＣＰＵ１０１は、４行目の行４１４にはセグメントデータ３０２の取得先パス（クエリパラメータを含む）を記述する。なお、３行目の行４１３と４行目の行４１４はセグメントデータ３０２に関する情報として、必ず続けて記述する必要がある。このプレイリスト４１０は、セグメント情報（行４１３，４１４の情報）を記録した図３のプレイリスト３０１の内容例となる。

また、情報端末２００は、セグメントデータ３０２の時間長Ｔｓを事前に記憶しているか、カメラ１００の機器情報に含めることで機器情報取得時に得ることが出来ているものとする。
情報端末２００は、ライブストリーミング開始後、ステップＳ３０５において、約Ｔｓ（秒）後に、ステップＳ３０４で取得したプレイリスト取得先へ、プレイリスト取得要求（ＨＴＴＰ ＧＥＴメソッド）を行う。

一方、カメラ１００は、ステップＳ３０６において、応答プレイリストとして、セグメント情報（４１３，４１４）が一つ記述されたプレイリスト３０１（＝４１０）を、情報端末２００へ送信する。
また、情報端末２００は、ステップＳ３０７において、受信したプレイリスト４１０を解析し、セグメント情報の取得先に対してセグメント取得要求（ＨＴＴＰ ＧＥＴメソッド）を行う。
そして、カメラ１００は、ステップＳ３０８において、応答セグメントとして、要求されたセグメントデータ３０２を送信する。

情報端末２００のＣＰＵ２０１は、受信したセグメントデータ３０２をＲＡＭ２０３または記録媒体２１２に一時保存させる。すなわち、情報端末２００では、輻輳時などに映像を途切れ難くするため、一定時間分のデータを蓄積（バッファリング）させる。このように、情報端末２００では、ＲＡＭ２０３または記録媒体２１２が受信バッファとして用いられ、受信バッファには前述のように再生表示されるまで一時的にセグメントデータ３０２が蓄積される。本実施形態の場合、この受信バッファにおいて一時的に蓄積可能なデータ量が、前述した受信バッファサイズに相当する。なお、受信バッファの最大バッファサイズは固定値でも変動値でもよく、ユーザが設定できるようになされていてもよい。

そして、情報端末２００のＣＰＵ２０１は、受信バッファに一定時間分のデータが蓄積されたならば、そのデータを符号・復号処理部２１３に渡して復号化させる。この復号化された映像データは、出力処理部２０６を介して表示部２０７に送られて再生表示される。
また例えば、ユーザにより端末ＲＥＣボタン７０７の操作を介した記録指示の入力があった場合、ＣＰＵ２０１は、前述の復号化されたデータ、またはセグメントデータ３０２からヘッダなどを除いたデータ部を、記録媒体２１２に記録保存させる。この記録の際には、順次受信したセグメントデータを結合したデータが記録される。

また、ライブストリーミング中、カメラ１００のＣＰＵ１０１は、約Ｔｓ（秒）毎にセグメントの生成とプレイリスト３０１の更新を行う。そして、ＣＰＵ１０１は、情報端末２００へ送信して当該情報端末２００で正常に取得されたセグメントデータ３０２についてはプレイリスト３０１から削除する。

情報端末２００は、カメラ１００にてプレイリスト３０１の更新が行われる度、その約Ｔｓ（秒）毎にステップＳ３０５でプレイリスト３０１を取得し、プレイリスト３０１に記載されたセグメント情報に基づき、当該セグメントデータ３０２の取得要求を行う。
なお、情報端末２００のステップＳ３０５，Ｓ３０７における要求処理では、情報端末またはアプリケーションの固有のＩＤが付加される。そして本実施形態のカメラ１００は、最初に要求のあったＩＤの情報端末からの要求のみに対してストリーミングを行う。つまり、本実施形態のカメラ１００と情報端末２００は１対１接続でのみストリーミングを行うものとする。

ここで、通信状況が良好である場合、ステップＳ３０５でのプレイリスト取得からステップＳ３０８の応答セグメントまでの一連の処理が定期的に行われることになる。
しかしながら、実際には、輻輳などにより通信が定期的に行えなくなることがある。
図５は、ライブストリーミングにおいて、情報端末２００の受信バッファ５００のデータ蓄積状態の一例を説明する図である。図５の例では、セグメント（ｓｅｑ＝１）からセグメント（ｓｅｑ＝３）までの通信の後に輻輳が生じた場合を挙げている。また、図５の例の場合、受信バッファ５００のバッファサイズは、例えばセグメントデータ時間長Ｔｓ×３分のデータ量（セグメントデータ三つ分）に相当するサイズであるとする。

図５において、セグメント（ｓｅｑ＝１）のデータを取得した時点で、情報端末２００の受信バッファ５００は、１Ｔｓ分に相当する記憶エリアが使用された状態５１０となる。なお、この時点では再生は開始されておらず、受信バッファ５００からのデータ読み出しは行われていないとする。次に、セグメント（ｓｅｑ＝２）のデータを取得すると、受信バッファ５００は、２Ｔｓ分の記憶エリアが使用された状態５１１となる。なお、この時点でも再生は開始されていないとする。さらに、次のセグメント（ｓｅｑ＝３）のデータを取得すると、受信バッファ５００は、３Ｔｓ分の記憶エリアが使用された状態５１２となる。そして、情報端末２００は、受信バッファ５００に３Ｔｓ分に相当するセグメントデータが蓄積されると、受信バッファ５００からのデータの読み出しを開始して、再生を開始する。

通信状況が良好である場合には、再生開始後は、受信バッファ５００において１Ｔｓ分のデータの書き込みと読み出しが繰り返されることで、再生がスムーズに継続される。すなわち、受信バッファ５００では、セグメントデータが書き込まれた順に順次読み出され、１Ｔｓ分の記憶エリアの空きができると、次の新たなセグメントのデータを書き込むような、書き込みと読み出しが繰り返される。

一方、輻輳等により通信速度の低下等が生ずると、カメラ１００から情報端末２００へのセグメントデータの送信が遅延し、受信バッファ５００に新たなセグメントデータの書き込みが行われるまでの期間が長くなる。一方で、受信バッファ５００からの読み出しは継続される。このため、受信バッファ５００では、３Ｔｓ分の記憶エリアが使用された状態５１２から、２Ｔｓ分の記憶エリアが使用された状態５１３へ、さらに１Ｔｓ分の記憶エリアが使用された状態５１４のように、蓄積されているデータが徐々に減少していく。そして、情報端末２００において、受信バッファ５００の記憶エリアが空いた状態５１５になると再生が停止してしまうことになる。このため、受信バッファ５００のサイズが大きいと、再生が開始されるまでにかかる時間は長くなるが、輻輳時に受信バッファ５００内のデータが無くなってしまうまでの時間も長くなり、再生が停止してしまうまでの時間にある程度の余裕があることになる。すなわち、受信バッファ５００のサイズが大きい場合には、輻輳等で通信速度が低下しても再生される映像が途切れ難くなる。これに対し、受信バッファ５００のサイズが小さいと、再生が開始されるまでにかかる時間は短いが、例えば輻輳時には受信バッファ５００内のデータが無くなってしまうまでの時間も短くなり、再生が停止してしまうまでの余裕が少なくなる。すなわち、受信バッファ５００のサイズが小さい場合には、輻輳時などで通信速度が低下すると映像が途切れ易くなる。

以下、図６を用い、ライブストリーミング時における情報端末２００の処理の流れについて説明する。図６は、カメラ１００との接続が確立した後、情報端末２００のＣＰＵ２０１が表示制御などを実行する処理のフローチャートである。図６のフローチャートの処理は、ＲＯＭ２０２に格納された本実施形態に係るプログラムをＲＡＭ２０３に展開してＣＰＵ２０１が実行することにより実現される。なお、図６のフローチャートの処理の全てがＣＰＵ２０１にて実行される必要はなく、処理の一部または全てがＣＰＵ２０１以外の一つ又は複数の回路等によって行われてもよい。

ステップＳ６０１において、ＣＰＵ２０１は、カメラ１００との接続時に図３のステップＳ３０４で受け取った機器・プレイリスト取得先情報から、プレイリスト取得先情報を取得してＲＡＭ２０３に保持する。
次に、ステップＳ６０２において、ＣＰＵ２０１は、所定時間が経過したか否かの判定を行う。ＣＰＵ２０１は、所定時間が経過したと判定した場合にはＳ６０３へ処理を進め、一方、所定時間が経過していないと判定した場合にはＳ６０６へ処理を進める。ここで、所定時間としては、カメラ１００が生成する所定の時間長Ｔｓと同等の時間にすることが望ましい。

ステップＳ６０３に進むと、ＣＰＵ２０１は、ステップＳ６０１で取得したプレイリスト取得先情報を用いて、図３のステップＳ３０５のプレイリストの取得要求を行い、その後、カメラ１００から受け取ったプレイリスト（Ｐ１）の解析を行う。ＣＰＵ２０１は、プレイリストの解析にて識別タグによるプレイリスト形式とバージョンの確認を行った後、カメラ１００からのセグメント情報の取得を開始する。

次のステップＳ６０４において、ＣＰＵ２０１は、ステップＳ６０３で取得したプレイリストにセグメント情報が存在したか否かの判定を行う。ＣＰＵ２０１は、セグメント情報が存在したと判定した場合にはステップＳ６０５へ処理を進め、一方、セグメント情報が存在していないと判定した場合にはステップＳ６０６へ処理を進める。

ステップＳ６０５の処理に進むと、ＣＰＵ２０１は、取得したセグメント情報が一つならば、そのセグメントを取得セグメントとする。また、ＣＰＵ２０１は、取得したセグメント情報が複数ならば、その中で受信順が最も古いセグメント情報を取得セグメントとする。さらに、ＣＰＵ２０１は、取得セグメント情報の取得先パスに対して、図３のステップＳ３０７のセグメント取得要求を行い、その後、カメラ１００からセグメントを受け取る。なお、取得セグメントは、受信順で最古のセグメントに限定しなくてもよい。

そして、ＣＰＵ２０１は、取得したセグメントデータをＲＡＭ２０３、または記録媒体２１２に一時保存し、前述したように受信バッファサイズまでデータを蓄積させる。受信バッファサイズまでセグメントデータが蓄積された場合、ＣＰＵ２０１は、受信バッファから順次データを読み出して符号・復号処理部２１３に送る。符号・復号処理部２１３による復号化後のデータは、出力処理部２０６を介して表示部２０７に送られ、これにより再生表示（映像表示）が行われる。また、ＣＰＵ２０１は、前述の端末ＲＥＣボタン７０７への指示に基づく記録が実行されている場合、本処理フローとは別の処理により、復号化したデータ、またはセグメントからヘッダなどを除いたデータ部を、記録媒体２１２に保存させる。

次に、ステップＳ６０６において、ＣＰＵ２０１は、姿勢検出部２１４の出力を基に情報端末２００の姿勢検出を行い、姿勢が変更されたか否かの判定を行う。ＣＰＵ２０１は、姿勢が変更されたと判定した場合にはステップＳ６０７へ処理を進め、姿勢が変更されていないと判定した場合にはステップＳ６１１へ処理を進める。

ステップＳ６０７に進むと、ＣＰＵ２０１は、操作部２０５による操作が無効か否かの判定を行う。例えば図８のように、情報端末２００が横向き姿勢となされている場合、ライブストリーミングの映像が表示エリア８０１に表示されて操作ＵＩ等が表示されない状態である場合には、操作無効となる。ＣＰＵ２０１は、操作無効であると判定した場合にはステップＳ６０８へ処理を進め、操作無効でないと判定した場合にはステップＳ６１０へ処理を進める。

ステップＳ６０８に進むと、ＣＰＵ２０１は、過去の一定期間に受信バッファが空になった回数が閾値以上になったか否かの判定を行う。なお、受信バッファが空になるとは、つまり輻輳などにより受信バッファ内にデータが無くなって、再生が停止することを意味する。ＣＰＵ２０１は、ステップＳ６０８の処理に移行する直前までの過去Ｔｂ（秒、ＴｂはＴｓよりも長い時間とする。）間において受信バッファが空になった回数を計測し、その計測した回数が閾値以上になったか否か判定する。そして、ＣＰＵ２０１は、受信バッファが空になった回数が閾値以上になったと判定した場合には、通信環境が良くないと判断し、ステップＳ６０９へ処理を進める。一方、ＣＰＵ２０１は、受信バッファが空になった回数が閾値未満であると判定した場合には、通信環境が良いと判断し、ステップＳ６１０へ処理を進める。なお、閾値は例えばｎ回とし、ｎは予め設定された値でもよいし、ユーザにより任意に設定可能な値でもよい。また、ステップＳ６０８の判定手法では回数と閾値とを比較する手法を例に挙げたが、この例に限定する必要はなく、通信環境が良いか否かを評価できるのであれば、他の方法が用いられてもよい。

ステップＳ６０９に進むと、ＣＰＵ２０１は、受信バッファサイズを、設定可能な最大値（設定可能な最大サイズ）に設定する。ここで、前述した横向き姿勢状態のように操作ＵＩが表示されない操作無効状態である場合、通信遅延による操作不便性を考慮する必要性は少なく、遅延よりもスムーズな再生を優先することが望ましい。このため、操作無効状態の場合には、受信バッファサイズを大きくするように決定し、これにより途切れ難いスムーズな映像再生を実現する。なお、本実施形態では、受信バッファサイズを設定可能な最大値としたが、勿論最大のサイズではない設定値でもよく、例えば所定サイズずつバッファサイズを増加させていってもよい。また、受信バッファサイズの変更を自動と手動の何れかに選択して設定できる場合には、自動設定になっている場合のみ受信バッファサイズの変更を行い、手動の場合には変更しないようにしてもよい。

ステップＳ６１０に進んだ場合、ＣＰＵ２０１は、受信バッファサイズを設定済みのサイズとするように決定する。つまり、前述したステップＳ６０７で操作ＵＩが表示される操作有効な状態であると判定してステップＳ６１０へ進んだ場合には、操作への影響も考慮し、遅延時間を軽減することが望ましい。そのため、ステップＳ６０７からステップＳ６１０へ遷移した場合，ＣＰＵ２０１は、バッファサイズを元々設定されていた値、若しくはユーザが設定した値に戻す。これは、ユーザがカメラ１００を遠隔操作する場合には、再生されている映像を観ながら操作するタイミングを計ると考えられるため、遠隔操作される可能性がある状態では常にバッファサイズは小さめにしておく方が望ましいためである。ステップＳ６０９の後、ＣＰＵ２０１は、ステップＳ６１１へ処理を進める。

一方、ステップＳ６０８で通信環境が良いと判断してステップＳ６１０へ進んだ場合には、輻輳が発生している可能性が少なく、バッファサイズを大きくする必要がないと考えられる。このため、ＣＰＵ２０１は、ステップＳ６０８からステップＳ６１０へ遷移した場合には、バッファサイズを元々設定されていた値、若しくはユーザが設定した値に戻す。ステップＳ６１０の後、ＣＰＵ２０１は、ステップＳ６１１へ処理を進める。

ステップＳ６１１に進むと、ＣＰＵ２０１は、ライブストリーミングの処理を終了するか否かの判定を行う。そして、ＣＰＵ２０１は、例えばライブストリーミングの映像が終わった場合やユーザによる終了指示等がなされた場合には図６のフローチャートの処理を終了し、それ以外の場合にはステップＳ６０２に戻って処理を続ける。

以上説明したように、本実施形態の情報端末２００は、姿勢に応じて映像表示の向きを変更すると共に操作ＵＩの表示の有無（表示又は非表示）を決定しており、操作ＵＩの表示の有無に応じて受信バッファサイズを変更している。例えば、情報端末２００は、横向き姿勢時のようにライブストリーミングでアプリが操作ＵＩを表示せず映像再生のみの状態になった場合には、受信バッファサイズを大きくすることで、よりスムーズな映像再生を可能としている。これにより、本実施形態の情報端末２００では、ライブストリーミングの映像再生停止の瞬間や受信バッファ内の蓄積データが無くなった時の映像飛びが目立たなくなるという効果を期待できる。また、本実施形態の情報端末２００は、縦向き姿勢時のようにライブストリーミングでアプリが操作ＵＩを表示する状態になった場合には、受信バッファサイズを元々のサイズに戻すようになされている。これにより、本実施形態の情報端末２００では、ユーザが映像を観ながら操作する場合の映像と操作の親和性が良くなるという効果を得ることができる。また、本実施形態の場合、操作ＵＩは情報端末２００に予め用意されているものであるため、輻輳等による通信遅延が操作ＵＩに影響を与えることはない。以上のことから、本実施形態によれば、カメラ１００により撮影されているライブストリーミングの映像を情報端末２００に表示する場合において、ユーザの意図を適切に反映したスムーズな映像表示が可能となる。

以上、本発明に係る好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
例えば図６に示す処理では、操作ＵＩの表示中はバッファサイズを設定済みのサイズとし、操作ＵＩを表示しない状態ではバッファサイズを最大とした。しかし、操作ＵＩの表示中はバッファサイズを設定しうる最小値（これはバッファサイズ０、つまりバッファしない設定を含む）とし、操作ＵＩを表示しない状態ではバッファサイズを設定済みのサイズとしてもよい。これは以下の理由による。すなわち、そもそもユーザがバッファを設定する意図は、ユーザが視聴において許容できる遅延を設定しているともいえる。つまり、ユーザが設定したバッファサイズは、視聴をメインとした状態（本実施形態では図８の状態）において適用する方がユーザの意図に適った表示方法とも言えるからである。いずれの方法を採用するにせよ、操作ＵＩが表示されている状態の方が、表示されていない状態よりも遅延が少ない状態になっていることが重要である。
本発明は、上述の各実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
上述の実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。即ち、本発明は、その技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

１００：カメラ、２００：情報端末、２０１：ＣＰＵ、２１４：姿勢検出部、２０８：通信制御部

Claims (8)

1. 情報処理装置であって、
   外部装置から受信したストリーミングのための映像データに基づき、映像を再生する再生手段と、
   前記再生手段により再生される映像を表示するための、前記情報処理装置に予め保持された再生用画面を表示部に表示する表示制御手段と、
   前記外部装置から受信した映像データを、前記再生手段による再生のために所定の記憶領域にバッファするバッファ手段とを有し、
   前記表示制御手段は、再生中の映像に関するユーザの操作を受け付けるための操作部を、前記再生中の映像とともに前記再生用画面に表示可能であり、
   前記再生用画面への前記操作部の表示の有無に応じて、前記バッファ手段は前記映像データのバッファサイズを変更することを特徴とする情報処理装置。
2. 前記操作部は、前記外部装置を遠隔操作するための操作部を含み、
   前記遠隔操作のための操作部への操作に応じて前記外部装置を遠隔操作する遠隔操作手段をさらに有することを特徴とする請求項１に記載の情報処理装置。
3. 情報処理装置の姿勢を検出する検出手段をさらに有し、
   前記表示制御手段は、前記検出された姿勢に応じて、前記映像データに基づく前記映像の表示の向きを決定するとともに、前記操作部を含む前記再生用画面を表示させるか否かを決定し、
   前記バッファ手段は、前記操作部を含まない前記再生用画面が表示される場合、前記バッファサイズを、前記操作部を含む前記再生用画面が表示される場合よりも大きくすることを特徴とする請求項１または２に記載の情報処理装置。
4. 前記表示制御手段は、長方形の前記画面の長辺が重力方向に対して直角方向となる姿勢が前記情報処理装置の姿勢として検出された場合に、前記画面に前記操作部を表示しないことを特徴とする請求項３に記載の情報処理装置。
5. 前記所定の記憶領域に前記映像データが蓄積されていない状態になった回数を計測する計測手段をさらに有し、
   前記バッファ手段は、前記計測された回数が所定の閾値未満である場合には前記バッファサイズを変更しないことを特徴とする請求項１から４の何れか１項に記載の情報処理装置。
6. 前記バッファサイズを、自動で変更するか手動で変更するかを設定する設定手段を有し、
   前記バッファ手段は、前記設定手段により前記バッファサイズを手動で変更するよう設定されている場合には、前記バッファサイズを変更しないことを特徴とする請求項１から５の何れか１項に記載の情報処理装置。
7. 情報処理装置の制御方法であって、
   外部装置から受信したストリーミングのための映像データに基づき、映像を再生する再生工程と、
   前記再生工程により再生される映像を表示するための、前記情報処理装置に予め保持された再生用画面を表示部に表示する表示制御工程と、
   前記外部装置から受信した映像データを、前記再生工程による再生のために所定の記憶領域にバッファするバッファ工程とを有し、
   前記表示制御工程では、再生中の映像に関するユーザの操作を受け付けるための操作部を、前記再生中の映像とともに前記再生用画面に表示可能であり、
   前記再生用画面への前記操作部の表示の有無に応じて、前記バッファ工程では前記映像データのバッファサイズを変更することを特徴とする情報処理装置の制御方法。
8. コンピュータを、請求項１から６の何れか１項に記載の情報処理装置の各手段として機能させるためのプログラム。

Images