JP6465541B2 - 通信装置、再生装置、及びその方法、並びにプログラム - Google Patents

Description

本発明は、通信装置、再生装置、及びその方法、並びにプログラム通信機器及び方法、並びにプログラムに関し、特に、ネットワークを経由してストリーミング配信を行う通信装置、再生装置、及びその方法、並びにプログラムに関する。

近年、ネットワークを経由してストリーミングを行うための技術として、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（以下、「ＨＬＳ」と称する）が提案されている（例えば、非特許文献１参照）。ＨＬＳは、ＨＴＴＰを用いた通信プロトコルであり、ストリーミングサーバ機能を備える配信サーバと、クライアント機能を備えるプレーヤ機器との間でストリーミングを実現する。具体的には、プレーヤ機器が配信サーバに対してプレイリストの取得を要求する。そして、取得したプレイリストに記載されるビデオセグメントデータ（以下、単に「セグメント」と呼ぶ）を取得するためのセグメント取得ＵＲＬに対してセグメントの取得を要求し、取得したセグメントをデコード再生し、プレーヤ機器が備えるモニタに表示する。これらの一連の処理を連続的に実行することにより、ストリーミングが実現できる。

ＨＬＳは、様々なネットワーク製品に適用することが可能である。例えば、サーバ機能をデジタルカメラ（カメラ）に適用し、クライアント機能をＰＣ側のアプリケーションに適用することによって、カメラの撮影画像（撮影された動画）をネットワーク経由でリアルタイムにＰＣ上で表示させるシステムを構築することができる。

また、ＨＬＳは、一対一の構成に限定されるものではなく、ネットワーク上に接続された複数のカメラの撮影画像を、ＰＣ側で選択的に表示させるシステムを構築することもできる。この場合ＰＣは、映像を表示するカメラを選択し、選択したカメラにアクセスしてプレイリストおよびセグメントを取得する。

ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ ｄｒａｆｔ−ｐａｎｔ ｏｓ−ｈｔｔｐ−ｌｉｖｅ−ｓｔｒｅａｉｎｇ−０８（Ａｐｐｌｅ Ｉｎｃ． Ｍａｒｃｈ ２３， ２０１２）

しかしながら、上述したようなネットワーク上に接続された複数のカメラの撮影画像をＰＣ側で選択的に表示させるシステムでは、映像ソースの切替えはプレーヤ機器であるＰＣで行うことが前提となってしまう。なぜなら、ＨＬＳはＨＴＴＰベースであるため、すべてのリクエストはクライアントであるＰＣ側から発行され、サーバであるカメラからＰＣに対して映像ソースの切替えを要求するリクエストを送信できないためである。このように、上記従来の技術では、映像ソース切替えボタンのようなユーザインターフェースをカメラ側に提供することが難しい。

本発明は、複数の通信装置から動画再生端末へのストリーミング配信が可能なネットワーク環境において、ストリーミング動画の再生装置に表示される映像を配信側から切り替えることが可能となる技術を提供することを目的とする。

上記目的を達成するために、本発明の通信装置は、外部装置からのセグメント要求に応じて、所定時間分の映像データを記録したセグメントを前記外部装置に配信する通信装置であって、前記セグメントの配信元の情報を記述したセグメントリストを生成する生成手段と、前記外部装置からの前記セグメントリストの取得要求に応じて、前記セグメントリストを送信する送信手段と、前記外部装置に対するデータの配信が可能な複数の他の通信装置の管理情報を保持する保持手段と、前記保持手段により管理情報が保持されている通信装置のうち、前記外部装置にデータを配信する通信装置の選択をユーザから受け付ける受け付け手段とを有し、前記受け付け手段により、前記外部装置にデータを配信する通信装置の選択がユーザから受け付けられた場合、前記生成手段は、前記ユーザによって選択された通信装置をセグメントの配信元とするようにセグメントリストを生成し、前記ユーザによって選択された通信装置をセグメントの配信元とするように生成されたセグメントリストは、前記外部装置からの前記セグメントリストの取得要求に応じて、前記送信手段により送信されることを特徴とする。

本発明によれば、複数の通信装置から動画再生端末へのストリーミング配信が可能なネットワーク環境において、ストリーミング動画の再生装置に表示される映像を配信側から切り替えることが可能となる。

本発明の第１の実施形態に係る通信装置が接続されたネットワークシステムの一例を示す図である。 （ａ）図１におけるカメラの概略構成を示すブロック図、（ｂ）図１におけるＰＣの概略構成を示すブロック図である。 １台のカメラとＰＣとの間のストリーミング配信時のやりとりを示すシーケンスである。 （ａ）図３のＳ３０２で生成されるプレイリストの一例を示す図、（ｂ）図３のＳ３０７で送信されるプレイリストの一例を示す図、（ｃ）図９のＳ９０３でＰＣに送信されるプレイリストの一例を示す図、（ｄ）図９のＳ９０８でＰＣに送信されるプレイリストの一例を示す図である。 本発明の第１の実施形態のカメラにおけるストリーミング開始処理の流れを示すフローチャートである。 （ａ）図５のステップＳ５０１で生成されるカメラ管理テーブルの一例を示す図、（ｂ）図７のステップＳ７０２で更新されたカメラ管理テーブルの一例を示す図、（ｃ）第４の実施形態におけるカメラ管理テーブルの一例を示す図である。 本発明の第１の実施形態におけるカメラ選択処理の流れを示すフローチャートである。 （ａ）図５のステップＳ５０３で表示部に表示されるカメラ選択画面の一例を示す図、（ｂ）第２の実施形態におけるカメラ選択画面の一例を示す図、（ｃ）第３の実施形態におけるカメラ選択画面の一例を示す図、（ｄ）第４の実施形態におけるカメラ選択画面の一例を示す図である。 ３台のカメラとＰＣとの間のストリーミング配信時のやりとりを示すシーケンスである。 ＨＬＳにおけるプレイリスト送信の時間間隔の一例を示す図である。 本発明の第３の実施形態のカメラにおけるストリーミング開始処理の流れを示すフローチャートである。 本発明の第４の実施形態におけるカメラ稼働状態確認処理の流れを示すフローチャートである。

以下、本発明の実施の形態を図面を参照して詳細に説明する。

［第１の実施形態］
図１は、本発明の第１の実施形態に係る通信装置（以下通信機器ともいう）が接続されたネットワークシステムの一例を示す図である。

図１において、カメラ１００ａ，１００ｂ，１００ｂは、無線通信機能を備え、動画や静止画の撮影が可能な撮像装置であり、上述したストリーミングサーバ機能を備える通信機器の一例である。ＰＣ２００は、無線通信機能を備えたパーソナルコンピュータや携帯情報端末等の情報処理装置であり、カメラ１００ａ等から無線通信によりストリーミング配信される動画等を受信して閲覧することが可能なプレーヤ機器の一例である。ＡＰ５００は、ルータ機能を備える無線ＬＡＮアクセスポイントである。

カメラ１００ａ〜１００ｃとＰＣ２００のそれぞれは、ＡＰ５００との間でインフラストラクチャモードにて無線ＬＡＮ通信接続を確立することができる。カメラ１００ａ〜１００ｃとＰＣ２００には、事前にＩＰアドレスが設定されており、ＡＰ５００のルータ機能によって、ＩＰアドレスを指定した相互通信が可能である。例えば、カメラ１００ａ〜１００ｃとＰＣ２００のＩＰアドレスは次の通りとする。

カメラ１００ａ ： １０．１．１２３．１０１
カメラ１００ｂ ： １０．１．１２３．１０２
カメラ１００ｃ ： １０．１．１２３．１０３
ＰＣ２００ ： １０．１．１２３．２００
ＰＣ２００は、上述したストリーミング技術におけるプレイリストを取得するためのＵＲＩの情報を予め備える。このＵＲＩは「ｈｔｔｐ：／／１０．１．１２３．１０１／Ｐｌａｙｌｉｓｔ」であり、プレイリストはカメラ１００ａからのみ送信される。

カメラ１００ａ〜１００ｃでは、撮像部による撮影処理が実行される。カメラ１００ｂ，１００ｃでは、ストリーミングサーバ機能が有効となっている。上記設定は、図示のネットワークシステムにおける初期設定状態である。

なお、図示のネットワークシステムは、簡単なＬＡＮ（ローカルエリアネットワーク）としたが、この限りではない。カメラ１００ａ〜１００ｃが属するネットワークと、ＰＣ２００が属するネットワークが異なる、電話回線網などを利用したＷＡＮ（ワイドエリアネットワーク）の構成であってもよい。

図２（ａ）は、図１におけるカメラ１００ａの概略構成を示すブロック図である。なお、カメラ１００ａ〜１００ｃは略同一の構成を有するものとし、カメラ１００ａについてのみ説明する。

図２（ａ）において、カメラ１００ａは、制御部１０１と、ＲＡＭ１０２と、撮像部１０３と、表示部１０４と、操作部１０５と、記録部１０６と、無線通信部１０７と、内部バス１０８を備える。

制御部１０１は、不図示のＣＰＵ（Central Processor Unit）やＲＯＭを備え、カメラ１００ａを構成する全ての処理ブロックの制御を行う。制御部１０１は、ストリーミング開始処理、カメラ選択処理、プレイリスト送信処理、セグメント送信処理に相当する処理プログラムを実行する。これら各種処理の詳細については後述する。制御部１０１内のＲＯＭには、上記処理プログラムが格納されている。

なお、制御部１０１が装置全体を制御する代わりに、複数のハードウェアが処理を分担することで、装置全体を制御するように構成してもよい。

ＲＡＭ１０２は、主に制御部１０１のワークエリアや、データの一時記憶領域として使用されるメモリである。ＲＡＭ１０２は、図６（ａ）に示すカメラ管理テーブルを格納する目的等にも使用される。

撮像部１０３は、不図示の光学レンズ、ＣＭＯＳセンサ、デジタル画像処理部等を備え、光学レンズを介して入力されるアナログ信号をデジタルデータに変換して撮影画像を取得する処理ブロックである。撮像部１０３によって取得された撮影画像は、ＲＡＭ１０２に一時的に格納され、制御部１０１の制御に基づいて処理される。例えば、記録部１０６による記録媒体（不図示）への記録や、無線通信部１０７による外部機器（ＰＣ２００等）への送信などである。

また、撮像部１０３は、レンズ制御部（不図示）も備えており、制御部１０１からの指令に基づいて、ズーム、フォーカス、絞り調整等の制御を行う。

表示部１０４は、液晶パネルまたは有機ＥＬパネル等で構成され、制御部１０１の指示に基づいて、操作画面や撮影画像等の表示を行う。なお、表示部１０４は、必ずしもカメラ１００ａが内蔵する必要はない。カメラ１００ａは内部又は外部の表示部１０４と接続することができ、表示部１０４の表示を制御する表示制御機能を少なくとも有していればよい。

操作部１０５は、ボタン、十字キー、タッチパネル、またはリモコン等によって構成され、ユーザの操作指示を受け付ける。操作部１０５から入力された操作情報は、制御部１０１に送信される。制御部１０１は、受信した操作情報に基づいて各処理ブロックの制御を実行する。

記録部１０６は大容量の記録媒体（不図示）によって構成され、制御部１０１の指示に基づいて記録媒体に様々なデータを格納したり読み出したりする処理ブロックである。記録媒体は、例えば内蔵フラッシュメモリ、内蔵ハードディスク、或いは着脱可能なメモリカード等で構成される。記録媒体はカメラ１００ａに着脱可能に構成してもよいし、カメラ１００ａに内蔵されていてもよい。すなわち、カメラ１００ａは少なくとも記録媒体にアクセスする手段を有していればよい。

無線通信部１０７は、不図示のアンテナ、無線ＬＡＮ処理ハードウェア等を備え、ＩＥＥＥ８０２．１１ｎ／ａ／ｇ／ｂ方式の無線通信を行う処理ブロックである。

また、無線通信部１０７は、ＡＰ５００と無線通信で接続し、当該アクセスポイント経由でＰＣ２００と無線通信を行う。なお、無線通信部１０７による通信は、ＩＥＥＥ８０２．１１ｎ／ａ／ｇ／ｂの方式に限定されるものではない。例えば、ＩＥＥＥ８０２．１１ａｃなどを採用してもよいし、無線ＬＡＮとは別の規格の通信（例えば赤外線通信やＢｌｕｅＴｏｏｔｈ(登録商標)など）を採用してもよい。

内部バス１０８は、カメラ１００ａ内の各処理ブロックを相互に接続するためのバスである。

図２（ｂ）は、図１におけるＰＣ２００の概略構成を示すブロック図である。

図２（ｂ）において、ＰＣ２００は、制御部２０１と、ＲＡＭ２０２と、表示部２０３と、操作部２０４と、無線通信部２０５と、内部バス２０６を備える。

制御部２０１は、不図示のＣＰＵやＲＯＭを備え、ＰＣ２００を構成する全ての処理ブロックの制御を行う。制御部２０１は、カメラ１００ａからプレイリスト（図３（ｂ）参照）を取得し、取得したプレイリストに基づいてセグメントを取得して表示する処理プログラムを実行する。制御部２０１内のＲＯＭには、上記処理プログラムが格納されている。

ＲＡＭ２０２は、主に制御部２０１のワークエリアとして使用されるメモリである。また、ＲＡＭ２０２は、カメラ１００ａから受信した撮影画像の一時記憶領域としても使用される。

表示部２０３は、液晶ディスプレイ等によって構成され、制御部２０１の指示に基づいて、カメラ１００ａから受信した撮影画像の表示を行う。操作部２０４は、ボタン、十字キー、タッチパネル、またはリモコン等によって構成され、ユーザの操作指示を受け付ける。操作部２０４から入力された操作情報は、制御部２０１に送信される。制御部２０１は、受信した操作情報に基づいて各処理ブロックの制御を実行する。

無線通信部２０５は、不図示のアンテナ、無線ＬＡＮ処理ハードウェア等を備え、ＩＥＥＥ８０２．１１ｎ／ａ／ｇ／ｂ方式の無線通信を行う処理ブロックである。

また、無線通信部２０５は、ＡＰ５００と無線通信で接続し、当該アクセスポイント経由でカメラ１００ａと無線通信を行う。

内部バス２０６は、ＰＣ２００内の各処理ブロックを相互に接続するためのバスである。

次に、カメラ１００ａにて撮影された動画をＰＣ２００にてストリーミングにより閲覧する際に、カメラ１００ａとＰＣ２００との間でやりとりされるＨＬＳプロトコルについて図３を参照して説明する。なお、初期状態として、カメラ１００ａとＰＣ２００との間は無線通信接続が確立されているものとする。また、ＰＣ２００は、カメラ１００ａのプレイリスト取得要求のためのＵＲＩの情報を予め備えているものとする。また、カメラ１００ａでは、撮像部１０３による撮影処理が実行されており、撮影された動画をストリーミング送信するためのストリーミングサーバ機能が有効となっているものとする。

図３は、カメラ１００ａとＰＣ２００との間のストリーミング配信時のやりとりを示すシーケンスである。

図３において、Ｓ３０１では、ＰＣ２００におけるユーザからの操作によって、カメラ１００ａへの接続指示が入力される。例えば、表示部２０３にストリーミングアプリケーション画面（図示せず）が表示され、ユーザがストリーミング画像を表示したいカメラを選択することによって接続指示が入力される。ＰＣ２００では、この接続指示の入力を検知したことに応じて、ストリーミングアプリケーションに従って、カメラ１００ａに対してプレイリスト取得要求を送信する。プレイリスト取得要求は、ＨＴＴＰリクエストを用いて送信される要求メッセージであり、ＵＲＩは、例えば“ｈｔｔｐ：／／ｃａｍｅｒａ／ｐｌａｙｌｉｓｔ”である。ここで、“ｃａｍｅｒａ”は、カメラ１００ａのネットワークホスト名である。

Ｓ３０２において、カメラ１００ａの制御部１０１は、ＰＣ２００から送信されるプレイリスト取得要求（動画再生要求）を、無線通信部１０７を介して受信する。

制御部１０１は、ＵＲＩを解析してプレイリスト取得要求であると判定し、プレイリストをＲＡＭ１０２上に生成する。ここで生成されるプレイリストの一例を図４（ａ）に示す。

図４（ａ）において、４０１は、ファイルのフォーマットがＭ３Ｕ形式であることを示すタグ情報である。４０２は、プレイリストに記載されるセグメントの最大の再生時間を示すタグ情報であり、図示例では５秒であることを示す。４０３は、プレイリストのシーケンス番号を示すタグ情報であり、図示例では１番目であることを示す。４０４は、プレイリストに記載されるセグメントの再生時間を示すタグ情報であり、図示例では５秒であることを示す。４０５はセグメント取得ＵＲＩである。セグメント取得ＵＲＩ４０５における「ｓｅｇｍｅｎｔ１．ｔｓ」はセグメントのファイル名を示す。拡張子の「．ｔｓ」は、ＭＰＥＧ２トランスポートストリームのファイル形式であることを示す。ＨＬＳプロトコルにおいて、セグメントのビデオ形式、オーディオ形式に特に制限は無く、例えばビデオはＨ．２６４形式、オーディオはＨＥ−ＡＡＣ形式のものであってよい。

図３に戻り、Ｓ３０３において、制御部１０１は、無線通信部１０７を介して、生成したプレイリストをＰＣ２００に送信する。プレイリストはＨＴＴＰレスポンスとして送信される。

Ｓ３０４において、ＰＣ２００は、Ｓ３０３で取得したプレイリストに記載されたセグメント取得ＵＲＩに基づいて、カメラ１００ａにセグメント取得要求を送信する。セグメント取得要求は、プレイリスト取得要求と同様に、ＨＴＴＰリクエストを用いて送信される要求メッセージであり、ＵＲＩは、図４（ａ）に示すように、“ｈｔｔｐ：／／ｃａｍｅｒａ／ｓｅｇｍｅｎｔ１．ｔｓ”となる。

カメラ１００ａの制御部１０１は、ＰＣ２００から送信されるセグメント取得要求を、無線通信部１０７を介して受信する。制御部１０１は、ＵＲＩを解析してセグメント取得要求であると判定し、撮像部１０３から入力される撮影画像を用いて、５秒間の動画データとしてＭＰＥＧ２トランスポートストリーム形式にファイル化されたセグメントを生成する。

Ｓ３０５において、制御部１０１は、無線通信部１０７を介して、生成したセグメントをＰＣ２００に送信する。セグメントはＨＴＴＰレスポンスとして送信される。セグメントを受信したＰＣ２００は、デコード処理を施して表示部２０３に動画を再生表示する。なお、図３において、「表示」と記載された下向きの矢印は、ＰＣ２００にて動画が再生される時間を示す。

続くＳ３０６からＳ３０９までのステップは、Ｓ３０２からＳ３０５までのステップと同様の処理となる。

Ｓ３０７において送信されるプレイリストの一例を図４（ｂ）に示す。

図４（ｂ）において、４０６に示すプレイリストのシーケンス番号は前回からひとつプラスされて２となる。４０７に示すセグメント取得ＵＲＩは、二つ目のセグメントであることを示すように、ファイル名の記述が変更されている。ただし、この変更では必須ではなく、“ｓｅｇｍｅｎｔ１．ｔｓ”であってもよい。カメラ１００ａは、ＵＲＩを解析する際、“ｃａｍｅｒａ／”に続く文字列が“ｓｅｇｍｅｎｔ”であれば、その後に続く番号が何であれ、セグメント取得要求であると判定する。

図３に戻り、Ｓ３０９におけるセグメントの送信処理は、ＰＣ２００の表示部２０３におけるシームレスな動画再生を実現させるために、Ｓ３０５で開始した５秒間の動画再生が完了する前に実行される。このタイミングの管理は、ＰＣ２００の制御部２０１によって行われる。Ｓ３０９以降のステップは、Ｓ３０６〜Ｓ３０９と同様のステップの繰り返しとなり、この繰り返しによってＰＣ２００でのシームレスなライブストリーミング再生が実現される。

以上が、１対１でのライブストリーミング再生の概要である。

続いて、本実施形態のカメラ１００ａの動作について、複数の映像ソースを映像配信側から切り替えるための処理を中心に説明する。

図５は、本実施形態のカメラ１００ａにおけるストリーミング開始処理の流れを示すフローチャートである。このフローチャートに示される処理は、制御部１０１が、制御部１０１内のＲＯＭからプログラムをロードしてＲＡＭ１０２に展開して実行することにより実現される。以降のカメラ１００ａにおける処理を示すフローチャートも同様である。また、このフローチャートは、デジタルカメラ１００にてストリーミングサーバ機能の開始を、例えばユーザによるメニュー操作等によって指示されることに応じて開始される。

まず、制御部１０１は、ストリーミングサーバ機能の開始に先立って、ステップＳ５０１において、カメラ１００ａ〜１００ｃのＩＰアドレスの登録処理を行う。具体的には、制御部１０１は、ＲＡＭ１０２にカメラ管理テーブルを生成する。生成されたカメラ管理テーブルの一例を図６（ａ）に示す。

図６（ａ）において、「Ｎｏ．」の列は、登録されたカメラの番号を示す。「カメラ名」の列は、カメラを識別するための名前を示す。「カメラ名」は予め固定されたものでよい。なお、「ＣａｍＡ」は、自機器であるカメラ１００ａを示す。

「ＩＰアドレス」の列は、登録されたそれぞれのカメラのＩＰアドレスを示す。自機器以外であるＣａｍＢ、ＣａｍＣのＩＰアドレスは、例えば表示部１０４にＩＰアドレス入力画面を表示し、ユーザの手入力によって登録されるように構成されている。

「映像ソース」の列は、どのカメラがプレーヤ機器に撮影画像（セグメント）を送信するかを示す。登録されているカメラのうち、いずれかひとつのカメラが「ＹＥＳ」となる。「映像ソース」の初期設定は、自機器であるＣａｍＡが「ＹＥＳ」となる。なお、ステップＳ５０１で生成されたカメラ管理テーブルは、続くステップＳ５０２で開始されるストリーミングサーバ機能が稼働する限り、ＲＡＭ１０２に保持される。

図５に戻り、ステップＳ５０２において、制御部１０１は、ストリーミングサーバ機能を稼働し、ＰＣ２００からのプレイリスト取得要求を受付可能な状態にする。

ステップＳ５０３において、制御部１０１は、図８（ａ）に示すカメラ選択画面を表示部１０４に表示し、ユーザからの操作部１０５を介してのカメラ選択指示を受付可能な状態にする。

図８（ａ）において、８０１は、撮像部１０３による撮影画像である。８０２はカメラ選択画面である。カメラ選択画面８０２には、ＣａｍＡを選択するためのボタン８０３、ＣａｍＢを選択するためのボタン８０４、ＣａｍＣを選択するためのボタン８０５がそれぞれ表示される。撮影画像上にカメラ選択画面を表示することにより、ユーザは自身が撮影している動画を確認しながらセグメント送信用のカメラ選択を行うことが可能である。

図７は、本発明の第１の実施形態のカメラ１００ａにおけるカメラ選択処理の流れを示すフローチャートである。このフローチャートは、図８（ａ）の画面の表示に併せて開始される。つまり、図５のフローチャートに続いて実行されるものである。ここでは説明のため、フローチャートを分けているが、これらのフローチャートで示される各処理は、それぞれ個別のプログラムの実行によって実現されてもよいし、一つのプログラムの実行によって実現されてもよい。以降のカメラ１００ａにおける処理を示すフローチャートも同様である。

ステップＳ７０１において、制御部１０１は、ユーザによるカメラ選択の指示を、操作部１０５を介して受け付ける。ユーザは、図８（ａ）に示すカメラ選択画面８０２を参照しながら操作する。

ステップＳ７０２において、制御部１０１は、ステップＳ７０１での選択指定に基づいてカメラ管理テーブルを更新する。例えば、ステップＳ７０１においてＣａｍＢが選択された場合の更新後のカメラ管理テーブルの一例を図６（ｂ）に示す。図６（ｂ）に示すように、「映像ソース」の列のＣａｍＢに該当する箇所が「ＹＥＳ」に変更され、他のカメラの箇所は「ＮＯ」となる。この結果、ＰＣ２００からの要求に対して、カメラ１００ａで撮影される映像データを映像ソースとするのではなく、カメラ１００ｂおよびカメラ１００ｃで撮影される映像データを映像ソースとして、ＰＣ２００に配信することができる。このテーブルの更新によって、映像配信側から配信する映像ソースを切り替える手順について、図９を用いて説明する。

図９は、３台のカメラ１００ａ〜１００ｃとＰＣ２００との間のストリーミング配信時のやりとりを示すシーケンスである。なお、本実施形態では、初期状態として、前述したストリーミング開始処理が完了しており、ＲＡＭ１０２上に図６（ａ）に示すカメラ管理テーブルが生成されているものとする。

Ｓ９０１において、ＰＣ２００側のユーザ操作によって、カメラ１００ａへの接続指示が入力される。例えば、ＰＣ２００の表示部２０３にストリーミングアプリケーション画面（図示せず）が表示され、ユーザがストリーミング画像を表示したいカメラを選択することによって接続指示が入力される。

Ｓ９０２において、カメラ１００ａの制御部１０１は、ＰＣ２００から送信されるプレイリスト取得要求を、無線通信部１０７を介して受信する。プレイリスト取得要求は、ＨＴＴＰのＧＥＴリクエストを用いて送信される要求メッセージである。ＵＲＩは、上述したように、“ｈｔｔｐ：／／１０．１．１２３．１０１／Ｐｌａｙｌｉｓｔ”である。

カメラ１００ａの制御部１０１は、ＵＲＩを解析してプレイリスト取得要求であると判定し、最新のカメラ管理テーブル（図６（ａ））の内容に基づいて、ＲＡＭ１０２上にプレイリストを生成する。

図６（ａ）において、「映像ソース」の列が「ＹＥＳ」となっているカメラは「ＣａｍＡ」であるため、セグメント取得ＵＲＩは、ＣａｍＡのＩＰアドレスに基づいて、“ｈｔｔｐ：／／１０．１．１２３．１０１／ｓｅｇｍｅｎｔ１．ｔｓ”となる。Ｓ９０２にて生成されるプレイリストの一例を図４（ｃ）に示す。

Ｓ９０３において、カメラ１００ａの制御部１０１は、無線通信部１０７を介して、生成したプレイリストをＰＣ２００に送信する。プレイリストはＨＴＴＰレスポンスとして送信される。

Ｓ９０４において、ＰＣ２００の制御部２０１は、Ｓ９０３で受信したプレイリストに記載されたセグメント取得ＵＲＩに基づいて、カメラ１００ａにセグメント取得要求を送信する。

カメラ１００ａの制御部１０１は、ＰＣ２００から送信されるセグメント取得要求を、無線通信部１０７を介して受信する（Ｓ９０４）。このＨＴＴＰリクエストのＵＲＩは、図４（ｃ）に示すように、“ｈｔｔｐ：／／１０．１．１２３．１０１／ｓｅｇｍｅｎｔ１．ｔｓ”である。カメラ１００ａの制御部１０１は、ＵＲＩを解析してセグメント取得要求であると判定し、撮像部１０３から入力される撮影画像を用いて、５秒間の動画データとしてＭＰＥＧ２トランスポートストリーム形式にファイル化されたセグメントを生成する。

Ｓ９０５において、カメラ１００ａの制御部１０１は、無線通信部１０７を介して、生成したセグメントをＰＣ２００に送信する。セグメントはＨＴＴＰレスポンスとして送信される。

セグメントを受信したＰＣ２００は、デコード処理を施して表示部２０３に表示する。図９にて「表示」と記載された下向きの矢印は、動画が再生される時間を示す。

さて、ここで、Ｓ９０６においてカメラ１００ａの制御部１０１が、操作部１０５を介して、セグメント送信を行うカメラの選択指示を受け付ける場合を例に挙げて説明する。本ステップの処理の詳細については、図７を参照して既に説明済みであるため、内容を割愛する。本ステップでは、ＣａｍＢが選択され、カメラ管理テーブルが図６（ｂ）の内容に更新されたものとして説明を続ける。

Ｓ９０６でカメラ管理テーブルが更新された後、Ｓ９０７において、カメラ１００ａの制御部１０１は、ＰＣ２００から送信されるプレイリスト取得要求を、無線通信部１０７を介して受信する。プレイリスト取得要求の内容は、Ｓ９０２と同様である。

カメラ１００ａの制御部１０１は、ＵＲＩを解析してプレイリスト取得要求であると判定し、最新のカメラ管理テーブル（図６（ｂ））の内容に基づいて、ＲＡＭ１０２上にプレイリストを生成する。

図６（ｂ）において、「映像ソース」の列が「ＹＥＳ」となっているカメラは「ＣａｍＢ」であるため、セグメントＵＲＩは、ＣａｍＢのＩＰアドレスに基づいて、“ｈｔｔｐ：／／１０．１．１２３．１０２／ｓｅｇｍｅｎｔ２．ｔｓ”となる。ここで生成されるプレイリストの一例を図４（ｄ）に示す。

図４（ｄ）において、４０８に示すプレイリストのシーケンス番号は前回からひとつプラスされて２となる。４０９に示すセグメント取得ＵＲＩは、前述したように、ＣａｍＢのＩＰアドレスに基づいて、“ｈｔｔｐ：／／１０．１．１２３．１０２／ｓｅｇｍｅｎｔ２．ｔｓ”となる。なお、ファイル名については、二つ目のセグメントであることを示すように変更されている。ただし、この変更では必須ではなく、“ｓｅｇｍｅｎｔ１．ｔｓ”であってもよい。

Ｓ９０８において、カメラ１００ａの制御部１０１は、無線通信部１０７を介して、生成したプレイリストをＰＣ２００に送信する。本ステップは、Ｓ９０３と同様である。

Ｓ９０９において、ＰＣ２００の制御部２０１は、Ｓ９０８で受信したプレイリストに記載されたセグメント取得ＵＲＩに基づいてセグメント取得要求を送信する。この処理は、図５のＳ３０４やＳ３０８と同様である。ただし、Ｓ９０３においてカメラ１００ａがＰＣ２００に送信したプレイリストには、カメラ１００ａではなく、カメラ１００ｂのＩＰアドレスに基づくセグメント取得ＵＲＩが記載されている。それゆえ、本ステップにおいては、セグメント取得要求は、カメラ１００ａではなく、カメラ１００ｂに送信される。このように、ＰＣ２００は、１対１の場合と同様に、プレイリストに記載されたＵＲＩに基づいて要求を発信する。つまり、映像配信側ではプレイリストに記載するＵＲＩを適切に変更することで、ＰＣ２００に特別な動作を要求することなく、映像配信側から映像ソースを切り替えることができる。

カメラ１００ｂの制御部１０１は、ＰＣ２００から送信されるセグメント取得要求を受信する（セグメント取得要求受信）。

カメラ１００ｂの制御部１０１は、ＵＲＩを解析してセグメント取得要求であると判定し、カメラ１００ｂの撮影画像を用いて、５秒間の動画データとしてＭＰＥＧ２トランスポートストリーム形式にファイル化されたセグメントを生成する。

Ｓ９１０において、カメラ１００ｂの制御部１０１は、生成したセグメントをＰＣ２００に送信する。セグメントはＨＴＴＰレスポンスとして送信される。セグメントを受信したＰＣ２００は、デコード処理を施して、Ｓ９０５で受信したセグメントの再生を完了した後に、シームレスに表示部２０３に表示する。

上記第１の実施形態によれば、カメラ１００ａでは、ＰＣ２００に対するストリーミング配信が可能な複数のカメラの管理情報（カメラ管理テーブル）が登録され、ＰＣ２００にストリーミング配信を行うカメラの選択をカメラ選択画面上で受け付ける。そして、選択されたカメラからＰＣ２００に対してストリーミング配信されるようにカメラ管理テーブルを更新する。ＰＣ２００からプレイリストの取得要求を受信すると、更新されたカメラ管理テーブルに基づいてプレイリストを生成してＰＣ２００に返信する。これにより、図１のような複数のカメラからＰＣ２００へのストリーミング配信が可能なネットワーク環境において、ストリーミング動画の再生装置（以下再生機器ともいう：ＰＣ２００）に表示される映像を配信側であるカメラ１００ａで切り替えることが可能となる。

上記第１の実施形態では、通信機器の一例としてカメラ１００ａとしたが、撮像機能は本発明の必須の条件ではない。セグメント送信機能を備えていなくても、ストリーミング開始処理、カメラ選択処理、およびプレイリスト送信処理を実行できるものであればよく、例えばＰＣやタブレット端末、スマートフォン等に適用してもよい。

［第２の実施形態］
次に、本発明の第２の実施形態について説明する。なお、上記第１の実施形態と同様の部分については同一の符号を付してそれらの説明を省略する。以下に、上記第１の実施の形態と異なる点のみを説明する。

本第２の実施形態では、図５のストリーミング開始処理において、カメラの選択指示を受け付けた後に、ＰＣ２００に表示中の撮影画像が、選択されたカメラの撮影画像に切り替わるまでのおおよその残り時間が表示される構成が追加されている。

図５のステップＳ５０３において、制御部１０１は、図８（ｂ）に示すカメラ選択画面を表示部１０４に表示し、ユーザからの操作部１０５を介してのカメラ選択指示を受付可能な状態にする。

図８（ｂ）において、８０６は、カメラの選択指示が行われてからＰＣ２００に表示中の撮影画像が、選択されたカメラの撮影画像に切り替わるまでのおおよその残り時間が表示される。

ここで、８０６に表示される残り時間の計算方法について図１０を用いて説明する。

図１０において、１００１，１００２，１００３は、カメラ１００ａからプレイリストを送信した時間を示し、１００４は現在の時間を示す。１００１，１００２，１００３は、図９のＳ９０３およびＳ９０８のステップが実行されるタイミングに相当する。

一般的にＨＬＳにおいて、プレイリスト取得要求が送信される時間間隔は、デコード再生時間に依存する。本実施形態では、セグメントあたりの再生時間は常に固定時間（５秒）を前提としているため、図１０に示すように、プレイリスト送信は一定周期で行われ、またその時間間隔はセグメントの再生時間に等しくなると考えられる。

ＰＣ２００が、セグメントを受信してから再生を開始するまでの時間は、ＰＣ２００の制御方法に依存するが、一般的に受信バッファサイズは最適化されているため、セグメント再生時間と比べて極短いと考えてよい。また、プレイリスト送信からセグメント送信までの処理は同期処理であるため、セグメント再生時間と比べて極短い時間で処理されると考えてよい。従って、カメラの選択指示が行われてからＰＣ２００に表示中の撮影画像が切り替わるまでのおおよその残り時間は、次のプレイリスト送信の時刻から現在時刻を引いた値となる。この値は、図１０では、Ｔ３−Ｔｃとなる。

以上説明した方法により、図８（ｂ）の８０６に表示されるおおよその残り時間を算出できる。具体的には、制御部１０１は、プレイリストを送信した時間情報をＲＡＭ１０２に記憶しておき、現在時間との差分時間を常に表示部１０４に表示することで実現できる。この処理は、本発明における時間情報記憶手段、および残時間通知手段に相当する。

上記第２の実施形態によれば、カメラ選択画面上に、ＰＣ２００で表示中の撮影画像が切り替わるまでのおおよその残り時間を常に表示する。これにより、ユーザはタイミングを見計らいながらカメラ選択指示を行うことができる。

［第３の実施形態］
次に、本発明の第３の実施形態について説明する。なお、上記第１の実施形態と同様の部分については同一の符号を付してそれらの説明を省略する。以下に、上記第１の実施の形態と異なる点のみを説明する。

本第３の実施形態では、図５のストリーミング開始処理において、図１のネットワークシステム上の３台のカメラ１００ａ〜１００ｃの撮影画像をカメラ選択画面に表示させる点が異なる。

図１１は、本発明の第３の実施形態のカメラ１００ａにおけるストリーミング開始処理の流れを示すフローチャートである。なお、図５の処理で説明したステップには同一の符号を付して、それらの説明は省略する。

ステップＳ１１０１において、制御部１０１は、ステップＳ５０１で登録したカメラ１００ｂ，１００ｃに対して、セグメント取得要求を送信し、セグメントを受信する（セグメント受信）。この処理は、図９のＳ９０４，Ｓ９０５におけるＰＣ２００をカメラ１００ａに置き換え、カメラ１００ａをそれぞれカメラ１００ｂとカメラ１００ｃに置き換えた場合と同様である。セグメント取得ＵＲＩは、登録したＩＰアドレスに基づいて生成される。

次に、ステップＳ５０３において、制御部１０１は、ステップＳ１１０１で受信したセグメントに基づいて、図８（ｃ）に示すカメラ選択画面を表示部１０４に表示する。

図８（ｃ）において、８０７はカメラ１００ａの撮影画像であり、図８（ａ）における８０１に相当するものである。８０８は、図１１のステップＳ１１０１において受信したカメラ１００ｂの撮影画像である。８０９は、図１１のステップＳ１１０１において受信したカメラ１００ｃの撮影画像である。

８１０は、カメラ１００ａを選択するためのボタンであり、図８（ａ）におけるボタン８０３に相当するものである。８１１は、カメラ１００ｂを選択するためのボタンであり、図８（ａ）におけるボタン８０４に相当するものである。８１２は、カメラ１００ｃを選択するためのボタンであり、図８（ａ）におけるボタン８０５に相当すするものである。

なお、図１１のステップＳ１１０１におけるセグメントを受信する処理は、表示部１０４でのライブストリーミング表示を実現するために繰返し行われる。

本第３の実施形態によれば、カメラ選択画面上に、配信側の複数のカメラで撮影された画像を表示させることによって、ユーザは撮影画像の内容を確認しながらカメラ選択指示を行うことができる。

［第４の実施形態］
以下、本発明の第４の実施形態について説明する。なお、上記第１の実施形態と同様の部分については同一の符号を付してそれらの説明を省略する。以下に、上記第１の実施の形態と異なる点のみを説明する。

本第４の実施形態では、上記第１の実施形態に対して、カメラ１００ｂ，１００ｃが稼動しているかを判定する処理が追加されたものである。

図１２は、本発明の第４の実施形態におけるカメラ１００ｂ，１００ｃのストリーミングサーバ機能の稼働状態を確認するカメラ稼働状態確認処理の流れを示すフローチャートである。

ステップＳ１２０１において、制御部１０１は、カメラ１００ｂ，１００ｃに対してＩＣＭＰプロトコルのＰＩＮＧリクエスト（確認要求）を送信する。

次に、ステップＳ１２０２において、制御部１０１は、所定時間内にＰＩＮＧレスポンスを受信したか否かを判定し、レスポンスを受信しなかった場合は、ステップＳ１２０３に進み、レスポンスを受信した場合は、本処理を終了する。ここで、所定時間とは１秒間未満の短い時間でよい。

ステップＳ１２０３において、制御部１０１は、レスポンスを受信しなかった他のカメラが稼動していないと判断して、カメラ管理テーブルを更新する。更新後のカメラ管理テーブルの一例を図６（ｃ）に示す。

図６（ｃ）は、カメラ１００ｃからのＰＩＮＧレスポンスを受信しなかった場合の更新後のカメラ管理テーブルの内容の一例を示す図である。

図６（ｃ）において、最も右側の「ＰＩＮＧ応答」の列は、ＰＩＮＧ送信の応答結果を示す。初期設定は「あり」である。

図１２に戻り、ステップＳ１２０４において、制御部１０１は、最新のカメラ管理テーブルに基づいて、カメラ選択画面を更新する。具体的には、ＰＩＮＧレスポンスを受信しなかったカメラを、選択ボタンで選択不可能にする。更新後のカメラ選択画面の一例を図８（ｄ）に示す。図８（ｄ）では、図６（ｃ）に示すカメラ管理テーブルにおいて、ＣａｍＣの「ＰＩＮＧ応答」が「なし」となっているため、ＣａｍＣの選択ボタン８１３が選択不可能に表示される。

図１２で説明したカメラ稼働状態確認処理は、ストリーミングサーバ機能の稼動を開始してから定期的に（例えば１秒間隔で）実行される。これにより、カメラ１００ｂ，１００ｃがバッテリ切れや電源ＯＦＦ等、何らかの原因によりセグメント送信ができない状況になったとしても、すぐにカメラ選択画面に反映され、セグメント送信不可能なカメラが選択されることを防ぐことが可能となる。

また、カメラ稼働状態確認処理は、カメラ選択画面におけるカメラ選択指示の直後に、選択されたカメラに対して実行するようにしてもよい。ここで、カメラからのＰＩＮＧの応答が無い場合は、エラーをユーザに通知し、選択をキャンセルするようにしてもよい。

本第４の実施形態によれば、カメラ稼働状態確認処理を実施することで、何らかの原因でカメラがセグメントを送信できない状況になった場合でも、そのカメラへのセグメント取得要求をＰＣ２００から実行させない。これにより、ＰＣ２００上での画像表示を途切れさせないようにすることが可能となる。

なお、本第３の実施形態におけるカメラ稼働状態確認処理は、第２及び第３の実施形態と組み合わせて実行させることも可能である。

上記第１から第４の実施形態では、ストリーミング配信を受ける側の動画再生機器をパーソナルコンピュータ（ＰＣ）としたが、これに限定されるものではない。例えば、スマートフォンや情報携帯端末等であってもよい。また、ネットワーク環境は、図１に示すものに限定されるものではないし、通信機器の一例であるカメラの数が３台に限定されるものではない。また、通信機器としてデジタルカメラを用いたが、これに限定されるものではない。

以上、本発明の好ましい実施形態について説明したが、本発明は上記の実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

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

１００ａ，１００ｂ，１００ｃ カメラ
１０１ 制御部
１０２ ＲＡＭ
１０４ 表示部
１０５ 操作部
１０７ 無線通信部
２００ ＰＣ
５００ 無線ＬＡＮアクセスポイント（ＡＰ）

Claims (9)

1. 外部装置からのセグメント要求に応じて、所定時間分の映像データを記録したセグメントを前記外部装置に配信する通信装置であって、
   前記セグメントの配信元の情報を記述したセグメントリストを生成する生成手段と、
   前記外部装置からの前記セグメントリストの取得要求に応じて、前記セグメントリストを送信する送信手段と、
   前記外部装置に対するデータの配信が可能な複数の他の通信装置の管理情報を保持する保持手段と、
   前記保持手段により管理情報が保持されている通信装置のうち、前記外部装置にデータを配信する通信装置の選択をユーザから受け付ける受け付け手段とを有し、
   前記受け付け手段により、前記外部装置にデータを配信する通信装置の選択がユーザから受け付けられた場合、前記生成手段は、前記ユーザによって選択された通信装置をセグメントの配信元とするようにセグメントリストを生成し、
   前記ユーザによって選択された通信装置をセグメントの配信元とするように生成されたセグメントリストは、前記外部装置からの前記セグメントリストの取得要求に応じて、前記送信手段により送信されることを特徴とする通信装置。
2. 前記保持手段は、前記他の通信装置の管理情報に加えて、自機の管理情報も保持することを特徴とする請求項１に記載の通信装置。
3. 前記セグメントリストの取得要求を受信した時間と、セグメントあたりの再生時間と、現在の時刻とに基づいて、次のセグメントリストの取得要求を受信する時刻を算出し、当該算出した時刻までの残り時間をユーザに通知する通知手段とをさらに備えることを特徴とする請求項１または２に記載の通信装置。
4. 前記複数の通信装置に対して前記外部装置にデータを配信が可能な状態かを確認するための確認要求を送信する確認手段を更に備え、
   前記確認手段によって送信された確認要求に対して応答がなかった場合、前記生成手段は、応答がなかった通信装置がセグメントの配信元となるセグメントリストを生成しないことを特徴とする請求項１乃至３のいずれか１項に記載の通信装置。
5. 前記複数の通信装置に対してセグメント取得要求を送信するセグメント取得要求手段と、
   前記複数の通信装置からセグメントを受信するセグメント受信手段をさらに備え、
   前記受け付け手段による前記外部装置にデータを配信する通信装置の選択の受け付けは、前記セグメント受信手段により受信したセグメントによる少なくとも１つの動画と自機から前記外部装置に対して配信することが可能な動画との表示と並行して行われることを特徴とするとする請求項１乃至４のいずれか１項に記載の通信装置。
6. 前記管理情報には、当該管理情報を保持する自機のＵＲＩと、前記複数の通信装置のＵＲＩとが含まれることを特徴とする請求項１乃至５のいずれか１項に記載の通信装置。
7. 外部装置との通信は、インターネット越しに行われることを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
8. 外部装置からのセグメント要求に応じて、所定時間分の映像データを記録したセグメントを前記外部装置に配信する通信装置の制御方法であって、
   前記セグメントの配信元の情報を記述したセグメントリストを生成する生成ステップと、
   前記外部装置からの前記セグメントリストの取得要求に応じて、前記セグメントリストを送信する送信ステップと、
   前記外部装置に対するデータの配信が可能な複数の他の通信装置の管理情報を保持する保持ステップと、
   前記保持ステップで管理情報が保持されている通信装置のうち、前記外部装置にデータを配信する通信装置の選択をユーザから受け付ける受け付けステップとを有し、
   前記受け付け手段で前記外部装置にデータを配信する通信装置の選択がユーザから受け付けられた場合、前記生成ステップでは、前記ユーザによって選択された通信装置をセグメントの配信元とするようにセグメントリストを生成し、
   前記ユーザによって選択された通信装置をセグメントの配信元とするように生成されたセグメントリストは、前記外部装置からの前記セグメントリストの取得要求に応じて、前記送信ステップで送信されることを特徴とする通信装置の制御方法。
9. コンピュータに、請求項１乃至７のいずれか１項に記載の通信装置の各手段として機能させるための、コンピュータが読み取り可能なプログラム。

Images