JP2016100841A - 通信装置、撮像装置、通信装置の制御方法、及びプログラム - Google Patents

Abstract

【課題】端末機器（外部装置）が表示する画像データを送信するサーバ機器（通信装置）における電力の浪費を抑制する。【解決手段】外部装置に対する送信用画像データを生成する生成手段と、前記送信用画像データを前記外部装置へ送信する送信手段と、前記外部装置が、前記送信手段から受信した前記送信用画像データを表示する所定の状態であるか否かを判定する判定手段と、前記外部装置が前記所定の状態でないと判定された場合に、前記生成手段に対する少なくとも一部の給電を停止する制御手段と、を備えることを特徴とする通信装置を提供する。【選択図】図４

Description

本発明は、通信装置、撮像装置、通信装置の制御方法、及びプログラムに関する。

インターネットを介してサーバ機器からライブストリーミング配信されたコンテンツを、スマートフォンやタブレット端末などの端末機器で閲覧するユースケースが普及してきている。また、昨今では、デジタルビデオカメラ等の撮像装置が上記サーバ機器としての機能を持つことも増えてきている。このような撮像装置は、例えばＷｉ−Ｆｉ（登録商標）（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）による無線通信によって、上記端末機器との間でライブストリーミングを行うことができる。その際に使用される通信方式は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）やＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）などが一般的である。ＨＴＴＰはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）タイプのプロトコルであり、通信において確認応答、順序制御、再送制御などが可能である。ストリーミング方法の１つとして、ストリーミングデータを一定時間に分割したセグメントデータとその情報を記述したプレイリストを利用したストリーミング方法がある。

一方で、サーバ機器と端末機器の通信において、電力消費の低減を目的とした制御の技術が提案されている。特許文献１は、サーバ機器本体が電力消費を抑えるモードを持ち、電力消費を抑えるモードが選択されると、端末機器との通信に関する一部の動作を停止することを開示している。

特開２００２−１０１０３７号公報

ライブストリーミング中に、サーバ機器から配信したコンテンツを端末機器が表示せず、ユーザが端末機器においてコンテンツを目視できない状態になる場合がある。そのような状態の例として、端末機器がスリープ状態に遷移した場合や、端末機器においてコンテンツを表示するアプリケーションがバックグラウンド状態に遷移した場合などが挙げられる。このような場合にサーバ機器がライブストリーミングを継続すると、それに伴う電力消費が無駄になるが、従来の技術は、このような問題に対処することができない。

本発明はこのような状況に鑑みてなされたものであり、端末機器（外部装置）が表示する画像データを送信するサーバ機器（通信装置）における電力の浪費を抑制する技術を提供することを目的とする。

上記課題を解決するために、本発明は、外部装置に対する送信用画像データを生成する生成手段と、前記送信用画像データを前記外部装置へ送信する送信手段と、前記外部装置が、前記送信手段から受信した前記送信用画像データを表示する所定の状態であるか否かを判定する判定手段と、前記外部装置が前記所定の状態でないと判定された場合に、前記生成手段に対する少なくとも一部の給電を停止する制御手段と、を備えることを特徴とする通信装置を提供する。

なお、その他の本発明の特徴は、添付図面及び以下の発明を実施するための形態における記載によって更に明らかになるものである。

本発明によれば、端末機器（外部装置）が表示する画像データを送信するサーバ機器（通信装置）における電力の浪費を抑制することが可能となる。

第１及び第２の実施形態に係るビデオカメラ１００の構成を示すブロック図。 第１の実施形態に係る端末機器２００の構成を示すブロック図 ビデオカメラ１００と端末機器２００との間で行われるライブストリーミングのシーケンス図。 端末機器２００の状態遷移を示す図。 ビデオカメラ１００によるライブストリーミング処理を示すフローチャート。 端末機器２００のステータス情報を含むＪＳＯＮデータを示す図。 第２の実施形態に係る端末機器６００の構成を示すブロック図。

以下、添付図面を参照して、本発明の実施形態を説明する。なお、本発明の技術的範囲は、特許請求の範囲によって確定されるのであって、以下の個別の実施形態によって限定されるわけではない。また、実施形態の中で説明されている特徴の組み合わせすべてが、本発明に必須とは限らない。

［第１の実施形態］
図１は、第１の実施形態に係るビデオカメラ１００の構成を示すブロック図である。ビデオカメラ１００は、撮像装置としての機能に加えて、サーバ機器（通信装置）としての機能を有する。ビデオカメラ１００は、レンズ１０１、ＣＭＯＳ（Ｃｏｍｐｌｅｍｅｎｔａｒｙ Ｍｅｔａｌ Ｏｘｉｄｅ Ｓｅｍｉｃｏｎｄｕｃｔｏｒ）１０２、カメラ信号処理部１０３、記録媒体１０４、電源１０５、及び操作部１０６を有する。ビデオカメラ１００はまた、入力Ｉ／Ｆ１０７、ＲＯＭ１０８、ＲＡＭ１ １０９、ＲＡＭ２ １１０、ＣＯＤＥＣ１ １１１、ＣＯＤＥＣ２ １１２、出力Ｉ／Ｆ１１３、ＬＣＤパネル１１４、及びＣＰＵ１１５を有する。ビデオカメラ１００はまた、通信制御部１１６、無線モジュール１１７、アンテナ１１８、及びデータバス１１９を有し、各構成要素はデータバス１１９を介してデータの入出力を行う。

レンズ１０１は、フォーカス、絞り機構などを含む撮影レンズであり、被写体の光学像を形成する。ＣＭＯＳ１０２は、撮像素子であり、Ａ／Ｄ変換器を含み、光学像をアナログ電気信号に変換した後、デジタル信号に変換する。なお、撮像素子はＣＭＯＳに限定される訳ではなく、代わりにＣＣＤ（Ｃｈａｒｇｅ Ｃｏｕｐｌｅｄ Ｄｅｖｉｃｅ Ｉｍａｇｅ Ｓｅｎｓｏｒ）などであってもよい。

変換されたデジタル信号は、カメラ信号処理部１０３により、後述するＣＰＵ１１５を介して、所定の画素補間・縮小といったリサイズ処理や色変換、各種補正処理等が行われる。更に、デジタル信号は、後述するＣＯＤＥＣ１ １１１によって所定のビットレート、フォーマット形式での圧縮符号化が行われる。また、ＣＯＤＥＣ１ １１１においては、映像圧縮符号化データの復号も行われる。なお、音声については特に図示していないが、レンズ１０１とＣＭＯＳ１０２をマイク、後述するＬＣＤパネル１１４をスピーカに見立てれば、ほぼ同様の処理により音声信号も扱うことが可能である。映像記録時には映像と共に音声も同時に収録され、ＣＯＤＥＣ１ １１１で映像と音声を多重化することで、音声付映像データを生成することが可能である。

記録媒体１０４は、撮影した映像データ及び音声データや、ＣＰＵ１１５の制御に必要な情報などを記録する。電源１０５は、ＡＣ電源やバッテリーであり、ビデオカメラ１００の各部に必要な電源の供給を行う。操作部１０６は、ビデオカメラ１００がライブストリーミングを行う際に、端末機器２００（図２）からの映像データ及び音声データの要求を受けて、映像データ及び音声データを送信するライブストリーミングモードに、ビデオカメラ１００を遷移させる。また、操作部１０６は、ユーザからの操作を受け付ける。受け付けた操作情報は、入力Ｉ／Ｆ１０７を介して、後述するデータバス１１９に入力される。ＲＯＭ１０８は、ビデオカメラ１００を起動するプログラムが格納されており、操作部１０６によって電源１０５から電気信号が供給されると、プログラムがＣＰＵ１１５によって、ＲＡＭ１ １０９に読み出される。ＲＡＭ１ １０９は、ＣＰＵ１１５のワークエリアとして機能する。また、ＲＡＭ１ １０９には、後述する通信制御部１１６にて受信した端末機器２００のステータス情報も格納される。なお、ＣＰＵ１１５のワークエリアは、ＲＡＭ１ １０９に限られるものではなく、図示しないハードディスク装置等の外部記録装置等であってもよい。ＲＡＭ２ １１０は、通信制御部１１６から送信する映像データ及び音声データを格納する。

ＣＯＤＥＣ１ １１１は、ＲＡＭ１ １０９や記録媒体１０４に記録されている映像データ及び音声データを再生する。再生された映像データは後述するＬＣＤパネル１１４に表示される。また、再生された音声データは図示しないスピーカ部に供給され出力される。ＣＯＤＥＣ２ １１２は、記録媒体１０４に記録されている映像データ及び音声データを復号し、通信制御部１１６から送信する際のデータ単位に、圧縮符号化する。出力Ｉ／Ｆ１１３は、ＣＰＵ１１５がプログラムに従い生成したＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）などの表示データに基づき、ＬＣＤパネル１１４に対して表示させるための表示信号を出力する。また、ＬＣＤパネル１１４は、ＣＯＤＥＣ１ １１１にて再生した映像データを出力Ｉ／Ｆ１１３を介して受信して表示する。ＣＰＵ１１５は、ＲＯＭ１０８からＲＡＭ１ １０９にロードされたプログラムを実行する。

通信制御部１１６は、無線モジュール１１７を介して、端末機器２００からステータス情報を受信する。また、通信制御部１１６は、無線モジュール１１７を介して、外部装置である端末機器２００への映像データ及び音声データの送信、及び、受信したデータに対するレスポンス信号の送信を行う。アンテナ１１８は、無線信号を送受信する。アンテナ１１８で受信された映像データ及び音声データは、無線モジュール１１７を介して通信制御部１１６に供給される。映像データ及び音声データは、通信制御部１１６で復調された後、パケットデータから変換され、ＣＯＤＥＣ２ １１２にて復号後、受信される。受信された映像データ及び音声データは、ＲＡＭ２ １１０のバッファ領域に保存される。また、受信を完了した際に端末機器２００に送信するレスポンス信号は、通信制御部１１６で、ＣＰＵ１１５を介してパケットデータに変換され、搬送波の周波数帯の変調信号として生成されて、アンテナ１１８から無線信号として端末機器２００に送信される。

次に、図２を参照して、端末機器２００の構成について説明する。端末機器２００は、電源２０１、操作部２０２、入力Ｉ／Ｆ２０３、ＲＯＭ２０４、ＲＡＭ２０５、記録媒体２０６、及びＣＯＤＥＣ２０７を有する。端末機器２００はまた、出力Ｉ／Ｆ２０８、ＬＣＤパネル２０９、通信制御部２１０、無線モジュール２１１、アンテナ２１２、ＣＰＵ２１３、及びデータバス２１４を有し、各構成要素はデータバス２１４を介してデータの入出力を行う。

電源２０１は、ＡＣ電源やバッテリーであり、端末機器２００の各部に必要な電源の供給を行う。操作部２０２は、ユーザ操作を受け付ける入力デバイスとして、キーボードといった文字情報入力デバイスや、マウスやタッチパネルといったポインティングデバイスなどを有する。なお、タッチパネルは、例えば平面的に構成された入力部に対して接触された位置に応じた座標情報が出力されるようにした入力デバイスである。特に、操作部２０２は、端末機器２００上で動作するアプリケーションの起動に使用される。また、操作部２０２には、端末機器２００に対する電源２０１からの電源供給の開始と停止を制御するスイッチも含まれる。操作部２０２で入力されたユーザからの操作は、入力Ｉ／Ｆ２０３を介して、データバス２１４に入力される。

ＲＯＭ２０４は、端末機器２００を起動するプログラムを格納しており、操作部２０２によって電源２０１から電気信号が供給されると、プログラムがＣＰＵ２１３によって、ＲＡＭ２０５に読み出される（ＣＰＵ２１３及びＲＡＭ２０５は後述する）。ＲＡＭ２０５は、ＣＰＵ２１３のワークエリアとして機能する。また、ＲＡＭ２０５には、後述する通信制御部２１０を介してビデオカメラ１００から受信した映像データ及び音声データも格納される。なお、ＣＰＵ２１３のワークエリアは、ＲＡＭ２０５に限られるものではなく、図示しないハードディスク装置等の外部記録装置等であってもよい。記録媒体２０６は、ＣＰＵ２１３を制御する情報を保持する。

ＣＯＤＥＣ２０７は、ＲＡＭ２０５や記録媒体２０６に記録されている映像データ及び音声データを再生する。再生された映像データは、後述するＬＣＤパネル２０９に表示される。また、再生された音声データは、図示しないスピーカ部に供給され出力される。ＣＯＤＥＣ２０７は、所定のビットレート、フォーマット形式での圧縮符号化、又は、映像圧縮符号化データの復号を行う。出力Ｉ／Ｆ２０８は、ＣＰＵ２１３がプログラムに従い生成したＧＵＩなどの表示データに基づき、ＬＣＤパネル２０９に対して表示させるための表示信号を出力する。また、ＬＣＤパネル２０９は、ＣＯＤＥＣ２０７にて再生した映像データを出力Ｉ／Ｆ２０８を介して表示する。

通信制御部２１０は、無線モジュール２１１を介して、ビデオカメラ１００から映像データ及び音声データを受信し、また、受信したデータに対するレスポンス信号を送信する。アンテナ２１２は、無線信号を受信する。アンテナ２１２で受信された映像データ及び音声データは、無線モジュール２１１を介して通信制御部２１０に供給される。映像データ及び音声データは、通信制御部２１０で復調された後、パケットデータに変換され、復号されることで、受信される。受信された映像データ及び音声データは、ＲＡＭ２０５のバッファ領域に保存される。また、受信を完了した際にビデオカメラ１００に送信するレスポンス信号は、通信制御部２１０で、ＣＰＵ２１３を介してパケットデータに変換され、搬送波の周波数帯の変調信号として生成される。そして、アンテナ２１２から無線信号としてビデオカメラ１００に送信される。ＣＰＵ２１３は、ＲＯＭ２０４からＲＡＭ２０５にロードされたプログラムを実行する。

次に、図３Ａを参照して、ビデオカメラ１００と端末機器２００との間で行われるライブストリーミングの仕組みについて説明する。図３Ａの左側は、ビデオカメラ１００と端末機器２００との間で行われるプレイリスト及びセグメントデータの送受信を示す。ライブストリーミングを行う場合、事前準備として、ユーザはビデオカメラ１００において、操作部１０６からライブストリーミングモードを指示する。すると、ビデオカメラ１００は、ＣＰＵ１１５の制御により、通信制御部１１６を通信可能状態とする。また、ユーザは端末機器２００おいて、操作部２０２を操作して通信接続処理及びライブストリーミングに必要なアプリケーション（以下、ライブストリーミングアプリ）の起動を行う。すると、端末機器２００のＣＰＵ２１３は、ＲＯＭ２０４又は記録媒体２０６に格納されたプログラムに従い、通信制御部２１０を制御し、ビデオカメラ１００との通信を開始し、接続処理を行う。ここで、ビデオカメラ１００及び端末機器２００は、通信プロトコルとしてＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を使用するものとする。また、ここで、ビデオカメラ１００及び端末機器２００は、通信接続においてＵＰｎＰ（Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）に対応しているものとする。ＵＰｎＰ対応の機器は、ネットワークに接続すると、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）又はＡｕｔｏＩＰによるＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスの設定を行う。ＩＰアドレスを取得した機器は、ネットワーク上の他の機器を相互に認識するために、「デバイスディスカバリーとコントロール」によって、デバイス検索と、応答デバイスの種別やサービス機能などの情報取得を行う。

本実施形態の例では、Ｓ３００で、端末機器２００は、ビデオカメラ１００に対して、機器情報、及び機器固有のプレイリスト取得先情報の取得を要求する。Ｓ３０１で、ビデオカメラ１００は、Ｓ３００における端末機器２００からの要求に応えて、機器情報、及び機器固有のプレイリスト取得先情報などを送信する。これにより、ビデオカメラ１００と端末機器２００の接続処理が完了する。その後、ビデオカメラ１００は、ライブストリーミングを開始する。ライブストリーミングにおいて、ビデオカメラ１００のＣＰＵ１１５は、ＣＭＯＳ１０２からの信号出力を開始し、その出力（撮像画像データ）をカメラ信号処理部１０３により適切な映像データに変換し、ＣＯＤＥＣ１ １１１へ映像データを渡す。ＣＯＤＥＣ１ １１１は、受け取った映像データを所定のビットレート、フォーマット形式で圧縮符号化する。圧縮符号化された映像データ（符号化画像データ）は、更に、ＣＰＵ１１５を介してＣＯＤＥＣ２ １１２にて所定の時間長Ｔｓで分割され、セグメントデータ３０２（送信用画像データ）として、ＲＡＭ２ １１０又は記録媒体１０４に保存される。ＣＰＵ１１５は、セグメントデータの保存先と関連させたパス情報を生成する。パス情報は、端末機器２００がセグメントデータを取得する際の取得先情報として使用するものである。ＣＰＵ１１５は、プレイリスト３０３を作成し、パス情報と併せてセグメントデータを記録する。

Ｓ３０４で、端末機器２００は、ライブストリーミング開始後、約Ｔｓ秒後に、Ｓ３０２において取得したプレイリスト取得先に対して、プレイリスト取得要求（ＨＴＴＰ ＧＥＴメソッド）を行う。Ｓ３０５で、ビデオカメラ１００は、Ｓ３０４における要求に対する応答として、セグメントデータ３０２が１つ記述されたプレイリスト３０３を送信する。Ｓ３０６で、端末機器２００は、受信したプレイリスト３０３を解析し、セグメントデータ取得先に対して、セグメント取得要求（ＨＴＴＰ ＧＥＴメソッド）を行う。Ｓ３０７で、ビデオカメラ１００は、Ｓ３０６における要求に対する応答として、要求されたセグメントデータ３０２を送信する。端末機器２００は、受信したセグメントデータ３０２をＣＯＤＥＣ２０７に渡し、復号化した後、ＣＰＵ２１３にて、出力Ｉ／Ｆ２０８を介してＬＣＤパネル２０９で再生表示を行う。

ライブストリーミング中、ビデオカメラ１００は、約Ｔｓ秒毎にセグメントデータ生成及びプレイリスト更新を行う。また、ビデオカメラ１００は、取得されたセグメントデータは削除する。端末機器２００は、約Ｔｓ秒毎にプレイリスト取得要求（Ｓ３０４）を行い、プレイリスト３０３に記載されたセグメントデータ取得先情報に基づき、セグメントデータ取得要求（Ｓ３０６）を行う。

次に、図３Ａの右側を参照して、ビデオカメラ１００と端末機器２００との間で行われるステータス情報の送受信について説明する。本実施形態では、ビデオカメラ１００によるステータス情報取得要求については、ＨＴＴＰ ＧＥＴメソッドのＵＲＩで行うものとする。また、ステータス情報取得要求に対するレスポンスは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）データフォーマットであるものとする。

ＪＳＯＮデータフォーマットの具体例は、図５に示すデータフォーマットである。ＪＳＯＮデータは、ステータス情報取得要求を正常に受信できたかどうかを示すタグ”ｒｅｓ”、及び、現在のステータス情報取得要求が何番目であるかを示すタグ”ｓｅｑ”を含む。また、ＪＳＯＮデータは、現在の端末機器２００のライブストリーミングアプリの状態を示すタグ”ＶｉｅｗＳｔａｔｅ”を含む。図５に示すＪＳＯＮデータは、２番目のステータス情報取得要求が正常に受信できたことを示すレスポンスであり、端末機器２００のライブストリーミングアプリがバックグラウンド状態に遷移した状態であることを示している。

ビデオカメラ１００は、ライブストリーミングモードになると、端末機器２００に対するステータス情報取得要求を開始する。最初に、Ｓ３０８で、ビデオカメラ１００は、端末機器２００に対するステータス情報取得要求を行う。端末機器２００は、ビデオカメラ１００からのステータス情報取得要求をアンテナ２１２、無線モジュール２１１、及び通信制御部２１０を介して受信し、ＲＡＭ２０５に格納する。Ｓ３１０で、端末機器２００は、ＣＰＵ２１３により、ＪＳＯＮデータ３０９をＲＡＭ２０５に生成する。そして、端末機器２００は、Ｓ３０８における要求に対する応答として、通信制御部２１０、無線モジュール２１１、及びアンテナ２１２を介して、ＪＳＯＮデータ３０９をビデオカメラ１００に送信する。ところで、端末機器２００は、Ｓ３０８において受信したステータス情報取得要求が初回のものであるかどうかを、ＣＰＵ２１３を介して判別する。ステータス情報取得要求が初回のものであった場合、端末機器２００は、このステータス情報取得要求を受信した時点での、ＲＡＭ２０５及び記録媒体２０６に保持されたステータス情報を全て用いて、ＪＳＯＮデータ３０９を生成する。従って、ＪＳＯＮデータ３０９は、全てのステータス情報を含む。

Ｓ３１１で、ビデオカメラ１００は、端末機器２００に対する２回目のステータス情報取得要求を行う。端末機器２００は、初回でないステータス情報取得要求を検出すると、ＲＡＭ２０５及び記録媒体２０６に保持されたステータス情報のうち、前回ビデオカメラ１００に送信した時点から更新された情報のみを用いて、ＪＳＯＮデータ３１２を生成する。端末機器２００は、ＪＳＯＮデータ３１２を、ＲＡＭ２０５に格納する。Ｓ３１３で、端末機器２００は、Ｓ３０８における要求に対する応答として、ＪＳＯＮデータ３１２をビデオカメラ１００に送信する。その後、Ｓ３１１及びＳ３１３における要求及び応答が繰り返される。

なお、ＪＳＯＮデータの”ｓｅｑ”タグの値は、ビデオカメラ１００からのステータス情報取得要求毎に更新してもよいし、端末機器２００の状態が更新されたときに更新してもよい。

続いて、図３Ｂを参照して、端末機器２００の状態遷移について説明する。図３Ｂの上側は、スリープ状態への遷移を示す。画面３１４には、端末機器２００がライブストリーミングにより受信した画像データが表示されている。この状態（通常状態）では、端末機器２００のＣＰＵ２１３は、ライブストリーミングアプリを実行することにより、アンテナ２１２、無線モジュール２１１、及び通信制御部２１０を介して、ビデオカメラ１００から画像データを受信する（図３Ａの左側参照）。端末機器２００のＣＰＵ２１３は、受信した画像データをＲＡＭ２０５に格納する。端末機器２００のＣＰＵ２１３は、画像データを、ＣＯＤＥＣ２０７及び出力Ｉ／Ｆ２０８を介してＬＣＤパネル２０９に表示する。この状態において、ユーザにより端末機器２００の操作部２０２や電源２０１が操作されることにより、端末機器２００はスリープ状態に遷移する。スリープ状態とは、端末機器２００がＬＣＤパネル２０９を非表示にすると共に、スリープ状態から復帰するための所定の操作以外、ユーザ操作も受け付けない状態である。従って、スリープ状態において、ライブストリーミングアプリは、ビデオカメラ１００からの画像データの受信、画像データの再生、及び表示を一時的に停止する状態となり、画面３１５には何も表示されない。但し、ビデオカメラ１００と端末機器２００との間のステータス情報の送受信は続いている。即ち、図３Ａの右側の処理は継続している。

図３Ｂの右側は、バックグラウンド状態への遷移を示す。本実施形態における端末機器２００は、複数のアプリを並行して起動させることができるが、１度にユーザが操作できるのは１つのアプリだけである。どのアプリを操作するかは、ユーザ操作により選択可能である。現在選択中のアプリをフォアグラウンド状態にあるといい、現在選択されていないアプリをバックグラウンド状態にあるという。画面３１４に示す状態（通常状態）において、ユーザによって端末機器２００の操作部２０２が操作されることで、端末機器２００において「Ｂｒｏｗｓｅｒ」アプリがフォアグラウンド状態に遷移する（画面３１６参照）。その結果、ライブストリーミングアプリがバックグラウンド状態に遷移する。バックグラウンド状態において、ライブストリーミングアプリは、ビデオカメラ１００からの画像データの受信、画像データの再生、及び表示を一時的に停止する。但し、ビデオカメラ１００と端末機器２００との間のステータス情報の送受信は続いている。即ち、図３Ａの右側の処理は継続している。

なお、ライブストリーミングアプリがバックグラウンド状態であるということは、端末機器２００がライブストリーミングアプリをバックグラウンドで実行している状態であるということである。従って、以下の説明においては、ライブストリーミングアプリがバックグラウンド状態であるということを、「端末機器２００がバックグラウンド状態である」と言う場合もある。

ここまで、スリープ状態とバックグラウンド状態について説明したが、いずれの状態においても、端末機器２００のユーザは、ライブストリーミングされた画像データを閲覧可能な状態ではない。従って、いずれの状態においても、ビデオカメラ１００からの画像データの送信を制限することで、ビデオカメラ１００における処理負荷、ひいては電力消費を低減することができる。

一方で、スリープ状態とバックグラウンド状態とでは、通常状態に復帰する可能性が異なる。スリープ状態の場合、ユーザが端末機器２００そのものを操作する意思がない可能性が高い。これに対し、バックグラウンド状態の場合、すぐにライブストリーミングアプリがフォアグラウンド状態（即ち、通常状態）に戻る可能性が高い。従って、本実施形態では、以下に詳述する通り、端末機器２００がスリープ状態の場合とバックグラウンド状態の場合とで、ビデオカメラ１００は異なる制御を行う。

図４は、ビデオカメラ１００によるライブストリーミング処理を示すフローチャートである。本フローチャートの各ステップの処理は、特に断らない限り、ビデオカメラ１００のＣＰＵ１１５が、ＲＯＭ１０８からＲＡＭ１ １０９にロードされたプログラムを実行することにより実現される。

Ｓ４００で、ユーザがビデオカメラ１００にて、操作部１０６からライブストリーミングモードを指示すると、ビデオカメラ１００はライブストリーミングを開始する。この時、端末機器２００側も、ユーザが操作部２０２から、ライブストリーミングアプリを起動することで、ライブストリーミングを開始する。

Ｓ４０１で、ビデオカメラ１００は、端末機器２００からの要求に応えて、機器情報、及び機器固有のプレイリスト取得先情報を送信する。Ｓ４０１における処理の詳細は、図３ＡのＳ３００及びＳ３０１において説明した通りである。

Ｓ４０２で、ビデオカメラ１００は、端末機器２００からの要求に応えて、プレイリストを送信する。Ｓ４０２における処理の詳細は、図３ＡのＳ３０４及びＳ３０５において説明した通りである。

Ｓ４０３で、ビデオカメラ１００は、端末機器２００からの要求に応えて、セグメントデータを送信する。Ｓ４０３における処理の詳細は、図３ＡのＳ３０６及びＳ３０７において説明した通りである。

Ｓ４０４で、ビデオカメラ１００は、端末機器２００からステータス情報を取得する。Ｓ４０４における処理の詳細は、図３ＡのＳ３０８、Ｓ３１０、Ｓ３１１、及びＳ３１３において説明した通りである。

Ｓ４０５で、ビデオカメラ１００は、Ｓ４０４において取得したステータス情報に基づき、端末機器２００がバックグラウンド状態であるか否かを判定する。ステータス情報は、レスポンス情報であるため、図５で示されるＪＳＯＮフォーマットである。具体的には、図５に示すタグ”ＶｉｅｗＳｔａｔｅ”の値”ｂａｃｋｇｒｏｕｎｄ”が「１」であれば、端末機器２００（のライブストリーミングアプリ）がバックグラウンド状態である。この場合、処理はＳ４０６に進む。値”ｂａｃｋｇｒｏｕｎｄ”が「０」の場合、端末機器２００はバックグラウンド状態ではない。この場合、処理はＳ４０８に進む。

処理がＳ４０５からＳ４０６に移行した場合、例えば図３Ｂの画面３１６に示すように、端末機器２００上で、ライブストリーミングアプリ以外のアプリがフォアグラウンド状態になっている。即ち、端末機器２００のライブストリーミングアプリは、ビデオカメラ１００が送信した画像データの表示を行っていない状態である。よって、ビデオカメラ１００としては、ライブストリーミングを行うために動作させるハードウェアの動作を停止することにより、無駄な電力消費を減らすことができる。特に、映像データ及び音声データの符号化や復号化を行うＣＯＤＥＣ１ １１１及びＣＯＤＥＣ２ １１２は、給電を停止することで、大幅な電力消費の低減につながる。一方で、ライブストリーミングアプリはバックグラウンド状態で動作しているので、端末機器２００の操作部２０２がユーザに操作されることにより、即座にバックグラウンド状態が解除されて、端末機器２００上で動作を開始する可能性がある。この場合、ビデオカメラ１００も、バックグラウンド状態が解除されたライブストリーミングアプリと、即座に通信を開始する必要がある。そのため、ビデオカメラ１００は、Ｓ４０６で、ＣＯＤＥＣ２ １１２への給電を停止するが、ＣＯＤＥＣ１ １１１に対する給電は停止しない。また、Ｓ４０７で、ビデオカメラ１００は、ＣＯＤＥＣ２ １１２が使用するＲＡＭ２ １１０への給電を停止する。その後、処理はＳ４０４に戻る。

端末機器２００がバックグラウンド状態でない場合、処理はＳ４０５からＳ４０８に進む。Ｓ４０８で、ビデオカメラ１００は、Ｓ４０４において取得したステータス情報に基づき、端末機器２００がスリープ状態であるか否かを判定する。ステータス情報（図５参照）のタグ”ＶｉｅｗＳｔａｔｅ”の値”ｓｌｅｅｐ”が「１」、値”ｂａｃｋｇｒｏｕｎｄ”が「０」であれば、端末機器２００はスリープ状態である。この場合、処理はＳ４０９に進む。値”ｓｌｅｅｐ”が「０」、値”ｂａｃｋｇｒｏｕｎｄ”が「０」であれば、端末機器２００はスリープ状態でない。この場合、処理はＳ４１２に進む。

処理がＳ４０８からＳ４０９に移行した場合、例えば図３Ｂの画面３１５に示すように、端末機器２００はスリープ状態になっている。即ち、端末機器２００のライブストリーミングアプリは、画像データをＬＣＤパネル２０９に表示していない状態である。また、一般的に、端末機器２００がスリープ状態になるのは、端末機器２００がある一定時間以上ユーザに操作されていなかったり、又は、使用を中断するためにユーザが操作部２０２を操作したりした結果である。そのため、次回の端末機器２００の起動時までに、時間がかかる。ライブストリーミングアプリの動作再開については、バックグラウンド状態からの復帰時間と比較すると、より長い時間がかかることが想定される。そのため、ビデオカメラ１００は、Ｓ４０９で、映像データ及び音声データの符号化、復号化を行うＣＯＤＥＣ１ １１１への給電を停止する。Ｓ４１０及びＳ４１１では、ビデオカメラ１００は、バックグラウンド状態の場合と同様、ＣＯＤＥＣ２ １１２及びＲＡＭ２ １１０への給電を停止する。結果として、ビデオカメラ１００は、全てのＣＯＤＥＣへの給電を停止し、電力消費を大幅に低減することができる。その後、処理はＳ４０４に戻る。

端末機器２００がスリープ状態でない場合、処理はＳ４０８からＳ４１２に進む。Ｓ４１２で、ビデオカメラ１００は、端末機器２００の電源２０１がＯＦＦであるか否かを、ステータス情報取得要求の応答（Ｓ４０４）に基づいて判定する。応答がある場合は、電源２０１はＯＮであると判断される。この場合、処理はＳ４１３に進む。応答が無い場合は、電源２０１はＯＦＦであると判断される。この場合、ライブストリーミングを継続することができないので、Ｓ４１９で、ビデオカメラ１００は、ライブストリーミングを終了し、その後、本フローチャートの処理は終了する。

Ｓ４１３で、ビデオカメラ１００は、ＣＯＤＥＣ１ １１１への給電が停止しているか否かを判定する。ここでは、端末機器２００がスリープ状態から通常状態に復帰した場合に、給電が停止していると判定される。この場合、Ｓ４１４で、ビデオカメラ１００は、ＣＯＤＥＣ１ １１１への給電を再開する。給電が停止していない場合、Ｓ４１４の処理はスキップされる。

Ｓ４１５で、ビデオカメラ１００は、ＣＯＤＥＣ２ １１２への給電が停止しているか否かを判定する。ここでは、端末機器２００がスリープ状態から通常状態に復帰した場合、又はライブストリーミングアプリがバックグラウンド状態からフォアグラウンド状態に復帰した場合に、給電が停止していると判定される。この場合、Ｓ４１６で、ビデオカメラ１００は、ＣＯＤＥＣ２ １１２への給電を再開する。給電が停止していない場合、Ｓ４１６の処理はスキップされる。

Ｓ４１７で、ビデオカメラ１００は、ＲＡＭ２ １１０への給電が停止しているか否かを判定する。ここでは、端末機器２００がスリープ状態から通常状態に復帰した場合、又はライブストリーミングアプリがバックグラウンド状態からフォアグラウンド状態に復帰した場合に、給電が停止していると判定される。この場合、Ｓ４１８で、ビデオカメラ１００は、ＲＡＭ２ １１０への給電を再開する。給電が停止していない場合、Ｓ４１８の処理はスキップされる。

その後、処理はＳ４０１に戻り、ライブストリーミングの処理が継続する。

以上説明した通り、第１の実施形態では、端末機器２００がビデオカメラ１００からライブストリーミングされた画像データを表示しない状態である場合に、ビデオカメラ１００は、構成要素の一部に対する給電を停止する。これにより、ビデオカメラ１００における電力の浪費を抑制することができる。

なお、図４の説明においては、ビデオカメラ１００は、端末機器２００がスリープ状態の場合とバックグラウンド状態の場合とで、異なる給電制御を行った。しかしながら、本実施形態において、スリープ状態とバックグラウンド状態との区別は、必須ではない。また、本実施形態において、給電を停止する対象の構成要素は、図４のＳ４０６及びＳ４０７、又はＳ４０９〜Ｓ４１１に示す組み合わせに限定されない。一般化すると、ビデオカメラ１００は、端末機器２００が画像データを表示する所定の状態（通常状態）でない場合には、ライブストリーミングの送信用画像データを生成するための構成要素に対する少なくとも一部の給電を停止するように構成される。

［第２の実施形態］
第１の実施形態では、端末機器がライブストリーミングされた画像データを表示しない状態である場合に、サーバ機器におけるライブストリーミングのための電力消費が無駄になることに注目し、この無駄を抑制するための構成について説明した。しかしながら、ライブストリーミングのための電力消費が無駄になるのは、端末機器がライブストリーミングされた画像データを表示しない状態である場合に限られない。例えば、端末機器が通話機能を持つ場合、通話の実行中はユーザが画面を見ない可能性が高いため、端末機器がライブストリーミングされた画像データを表示するか否かに関わらず、ライブストリーミングのための電力消費が無駄になる可能性がある。第２の実施形態では、このような無駄を抑制するための構成について説明する。

第２の実施形態において、ビデオカメラ１００の基本的な構成は、第１の実施形態と同様である（図１参照）。以下、主に第１の実施形態と異なる点について説明する。

図６は、第２の実施形態に係る端末機器６００の構成を示すブロック図である。図６において、図２の端末機器２００と同一又は同様の構成要素には同一の符号を付す。端末機器６００は、通話部６０１と、計時部６０２とを有する。通話部６０１は、他の端末機器との通話を実行する。通話部６０１は、マイク（不図示）にて受信した音声信号を、通信制御部２１０に供給する。音声信号は、通信制御部２１０により変調された後、無線モジュール２１１を介してアンテナ２１２から他の端末機器へ送信される。計時部６０２は、通話部６０１による通話の実行中に、通話が開始してから経過した時間を計測する。ＣＰＵ２１３は、通話部６０１による通話の開始を検出すると、時間の計測を開始するように計時部６０２を制御する。

ライブストリーミング中に、ＣＰＵ２１３は、通話部６０１が閾値以上の時間継続して通話を実行中であるか否かを判定する。判定の閾値は、例えば、ＬＣＤパネル２０９上に表示された、ＣＰＵ２１３がプログラムに従い生成したＧＵＩの表示データから、ユーザによる操作部２０２の操作によって決定された時間である。決定された時間（即ち、閾値）は、ＣＰＵ２１３を介し、ＲＡＭ２０５に格納される。

通話部６０１が閾値以上の時間継続して通話を実行中の場合、端末機器６００は、端末機器６００がスリープ状態であることを示すステータス情報をビデオカメラ１００に送信する。具体的には、端末機器６００は、図５に示すＪＳＯＮデータのタグ”ＶｉｅｗＳｔａｔｅ”の値”ｓｌｅｅｐ”を「１」に設定し、値”ｂａｃｋｇｒｏｕｎｄ”を「０」に設定する。通話部６０１が通話を実行中だが継続時間が閾値未満の場合は、端末機器６００は、端末機器６００がバックグラウンド状態であることを示すステータス情報をビデオカメラ１００に送信する。具体的には、端末機器６００は、値”ｓｌｅｅｐ”を「０」に設定し、値”ｂａｃｋｇｒｏｕｎｄ”を「１」に設定する。

以上の処理により、端末機器６００は、通話部６０１による通話の実行中は、ライブストリーミングされた画像データを表示するか否かに関わらず、端末機器６００がスリープ状態又はバックグラウンド状態であることを示すステータス情報を送信する。そのため、ビデオカメラ１００は、通話部６０１が通話を実行中の場合、端末機器６００がライブストリーミングされた画像データを表示するか否かに関わらず、構成要素の一部に対する給電を停止する。具体的には、通話が開始してからの経過時間が閾値未満の場合、ビデオカメラ１００は、ＣＯＤＥＣ２ １１２及びＲＡＭ２ １１０に対する給電を停止する（図４のＳ４０６及びＳ４０７参照）。また、通話が開始してからの経過時間が閾値以上の場合、ビデオカメラ１００は、ＣＯＤＥＣ１ １１１、ＣＯＤＥＣ２ １１２、及びＲＡＭ２ １１０に対する給電を停止する（図４のＳ４０９〜Ｓ４１１参照）。これにより、端末機器６００の通話部６０１が通話を実行中に、ビデオカメラ１００における電力の浪費を抑制することができる。

＜変形例＞
計時部６０２は、端末機器６００がバックグラウンド状態に移行してからの経過時間の計測にも利用可能である。この場合、ＣＰＵ２１３は、端末機器６００がバックグラウンド状態に移行したことを検出すると（図３Ｂの下側参照）、時間の計測を開始するように計時部６０２を制御する。

また、ＣＰＵ２１３は、端末機器６００が閾値以上の時間継続してバックグラウンド状態であるか否かを判定する。判定の閾値は、例えば、ＬＣＤパネル２０９上に表示された、ＣＰＵ２１３がプログラムに従い生成したＧＵＩの表示データから、ユーザによる操作部２０２の操作によって決定された時間である。決定された時間（即ち、閾値）は、ＣＰＵ２１３を介し、ＲＡＭ２０５に格納される。

端末機器６００が閾値以上の時間継続してバックグラウンド状態である場合、端末機器６００は、端末機器６００がスリープ状態であることを示すステータス情報をビデオカメラ１００に送信する。具体的には、端末機器６００は、図５に示すＪＳＯＮデータのタグ”ＶｉｅｗＳｔａｔｅ”の値”ｓｌｅｅｐ”を「１」に設定し、値”ｂａｃｋｇｒｏｕｎｄ”を「０」に設定する。端末機器６００がバックグラウンド状態だが継続時間が閾値未満の場合は、端末機器６００は、端末機器６００がバックグラウンド状態であることを示すステータス情報をビデオカメラ１００に送信する。具体的には、端末機器６００は、値”ｓｌｅｅｐ”を「０」に設定し、値”ｂａｃｋｇｒｏｕｎｄ”を「１」に設定する。

以上の処理により、端末機器６００は、実際にはスリープ状態ではなくバックグラウンド状態であっても、バックグラウンド状態の継続時間が閾値以上の場合は、端末機器６００がスリープ状態であることを示すステータス情報をビデオカメラ１００に送信する。そのため、ビデオカメラ１００は、端末機器６００がバックグラウンド状態であっても、バックグラウンド状態の継続時間が閾値以上の場合には、スリープ状態の場合と同様、ＣＯＤＥＣ１ １１１への給電を停止する（図４のＳ４０９参照）。これにより、ビデオカメラ１００における電力の浪費を更に抑制することができる。

［その他の実施形態］
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１００…ビデオカメラ、１０２…ＣＭＯＳ、１０５…電源、１０９…ＲＡＭ１、１１０…ＲＡＭ２、１１１…ＣＯＤＥＣ１、１１２…ＣＯＤＥＣ２、１１５…ＣＰＵ、１１６…通信制御部、１１７…無線モジュール、１１８…アンテナ、２００…端末機器

Claims (12)

1. 外部装置に対する送信用画像データを生成する生成手段と、
   前記送信用画像データを前記外部装置へ送信する送信手段と、
   前記外部装置が、前記送信手段から受信した前記送信用画像データを表示する所定の状態であるか否かを判定する判定手段と、
   前記外部装置が前記所定の状態でないと判定された場合に、前記生成手段に対する少なくとも一部の給電を停止する制御手段と、
   を備えることを特徴とする通信装置。
2. 前記少なくとも一部の給電が停止している間に、前記外部装置が前記所定の状態であると判定された場合、前記制御手段は、前記生成手段に対する給電を再開する
   ことを特徴とする請求項１に記載の通信装置。
3. 前記生成手段は、
   撮像手段により生成された撮像画像データを符号化することにより符号化画像データを生成する第１の符号化手段と、
   前記符号化画像データを符号化することにより前記送信用画像データを生成する第２の符号化手段と、
   前記送信用画像データを一時的に記録する記録手段と、
   を含み、
   前記外部装置が前記所定の状態でないと判定された場合、前記制御手段は、前記第１の符号化手段、前記第２の符号化手段、及び前記記録手段のうちの少なくとも１つに対する給電を停止する
   ことを特徴とする請求項１又は２に記載の通信装置。
4. 前記判定手段は、前記外部装置がスリープ状態であるか否かを判定し、
   前記外部装置が前記スリープ状態であると判定された場合、前記制御手段は、前記第１の符号化手段、前記第２の符号化手段、及び前記記録手段の全てに対する給電を停止する
   ことを特徴とする請求項３に記載の通信装置。
5. 前記判定手段は、前記外部装置が、前記送信手段から受信した前記送信用画像データを表示するアプリケーションをバックグラウンドで実行しているバックグラウンド状態であるか否かを判定し、
   前記外部装置が前記バックグラウンド状態であると判定された場合、前記制御手段は、前記第１の符号化手段に対する給電を停止せず、前記第２の符号化手段及び前記記録手段に対する給電を停止する
   ことを特徴とする請求項３又は４に記載の通信装置。
6. 前記外部装置が閾値以上の時間継続して前記バックグラウンド状態である場合、前記制御手段は、前記第１の符号化手段、前記第２の符号化手段、及び前記記録手段の全てに対する給電を停止する
   ことを特徴とする請求項５に記載の通信装置。
7. 前記外部装置は、通話を実行する通話手段を備え、
   前記外部装置の前記通話手段が通話を実行中の場合、前記制御手段は、前記外部装置が前記所定の状態であるか否かに関わらず、前記生成手段に対する少なくとも一部の給電を停止する
   ことを特徴とする請求項１に記載の通信装置。
8. 前記生成手段は、
   撮像手段により生成された撮像画像データを符号化することにより符号化画像データを生成する第１の符号化手段と、
   前記符号化画像データを符号化することにより前記送信用画像データを生成する第２の符号化手段と、
   前記送信用画像データを一時的に記録する記録手段と、
   を含み、
   前記外部装置の前記通話手段が通話を実行中の場合、前記制御手段は、前記外部装置が前記所定の状態であるか否かに関わらず、前記第１の符号化手段に対する給電を停止せず、前記第２の符号化手段及び前記記録手段に対する給電を停止する
   ことを特徴とする請求項７に記載の通信装置。
9. 前記外部装置の前記通話手段が閾値以上の時間継続して通話を実行中の場合、前記制御手段は、前記第１の符号化手段、前記第２の符号化手段、及び前記記録手段の全てに対する給電を停止する
   ことを特徴とする請求項８に記載の通信装置。
10. 請求項１乃至９のいずれか１項に記載の通信装置と、
    前記通信装置の前記生成手段による前記送信用画像データの生成の基となる撮像画像データを生成する撮像手段と、
    を備えることを特徴とする撮像装置。
11. 外部装置に対する送信用画像データを生成する生成手段と、前記送信用画像データを前記外部装置へ送信する送信手段と、を備える通信装置の制御方法であって、
    前記通信装置の判定手段が、前記外部装置が、前記送信手段から受信した前記送信用画像データを表示する所定の状態であるか否かを判定する判定工程と、
    前記通信装置の制御手段が、前記外部装置が前記所定の状態でないと判定された場合に、前記生成手段に対する少なくとも一部の給電を停止する制御工程と、
    を備えることを特徴とする制御方法。
12. コンピュータを、請求項１乃至９のいずれか１項に記載の通信装置の生成手段及び送信手段を除く各手段として機能させるためのプログラム。

Images