JP2014183488A - ストリーミング受信装置 - Google Patents

Abstract

【課題】本発明の目的は、ネットワークを有効に利用することができるストリーミング受信装置を提供することを課題とする。
【解決手段】配信装置１は、動画像データ３１をストリーミング受信装置２にストリーミング送信する。ストリーミング受信装置２は、動画像データ３１を再生して表示する。
ストリーミング受信装置２は、再生中の動画像データ３１の表示状態が変更された場合、変更された表示状態に応じて動画像データ３１の通信帯域を決定する。ストリーミング受信装置２は、決定した通信帯域に対応する動画像データ３１のストリーミング送信を配信装置１に要求する。
【選択図】図４

Description

本発明は、ネットワークを介して配信装置からストリーミング送信される動画像を受信するストリーミング受信装置に関する。

ストリーミング技術を利用した双方向テレビ会議システムが実用化されている。双方向テレビ会議システムにおいて、カメラ及びマイクが、会議に参加する拠点ごとに設置される。カメラにより撮影された動画像及びマイクに入力された音声が、複数の拠点にストリーミング送信される。各拠点に設置されたＰＣ（Personal Computer）などの端末装置は、ストリーミング送信される動画像及び音声を再生する。

再生される動画像の数は、双方向テレビ会議システムに参加する拠点の数とともに増加する。従って、各拠点の動画像を見やすく表示するために、各拠点の動画像のレイアウトをリアルタイムに変更する多画面合成装置が、特許文献１に開示されている。

多画面合成装置は、動画像とともに再生される音声のレベルをチェックし、一番大きいレベルの音声を送信する端末が発言端末であると判断する。多画面合成装置は、発言端末から送信される動画像を７５％の縮小率で表示し、それ以外の端末から送信される動画像を２５％の縮小率で表示する。

また、テレビ会議に参加する各クライアント端末の通信環境に応じて、クライアント端末に送信する符号化データを変更する技術が、特許文献２に開示されている。特許文献２において、送信側のクライアント端末は、複数レイヤから構成される符号化データを生成する。受信側の受信状態が良好である場合、送信側は、全てのレイヤを受信側に配信する。受信側の受信状態が良好でない場合、送信側は、複数レイヤのうち基本レイヤのみを配信する。

特開平０９−１４９３９６号公報 特開２００５−１３０４２８号公報

特許文献１において、多画面合成装置は、動画像データの表示サイズに関係なく、受信した動画像を縮小して表示する。したがって、過剰な品質の動画像を多画面合成装置に送信しなければならず、ネットワークを有効に利用することができない。

また、特許文献２においても、受信側のクライアント端末の受信状態が良好である場合、受信側のクライアント端末が高画質の動画像を表示する必要がなくても、全てのレイヤを含む符号化データが受信側のクライアントに送信される。従って、特許文献１と同様に、ネットワークを有効に利用することができない。

本発明の目的は、ネットワークを有効に利用することができるストリーミング受信装置を提供することである。

上記課題を解決するため、請求項１に係る発明は、ストリーミング受信装置であって、ネットワークを介して配信装置からストリーミング送信される動画像データを再生して表示する再生部と、前記再生部により再生される動画像データの表示状態を変更する変更部と、前記変更部により前記動画像データの表示状態が変更された場合、変更された表示状態に応じて前記動画像データの通信帯域を決定する帯域決定部と、前記帯域決定部により決定された通信帯域に対応する前記動画像データのストリーミング送信を前記配信装置に要求する要求部と、を備える。

請求項２記載の発明は、請求項１に記載のストリーミング受信装置であって、前記変更部は、前記再生部により再生される動画像データのサイズを変更し、前記帯域決定部は、前記動画像データのサイズの変化率に応じて、前記通信帯域を決定する。

請求項３記載の発明は、請求項２に記載のストリーミング受信装置であって、前記変更部が前記動画像データのサイズを大きくした場合、前記帯域決定部は、サイズが変更される前の通信帯域よりも大きくなるように、サイズが変更された後の通信帯域を決定する。

請求項４記載の発明は、請求項１ないし請求項３のいずれかに記載のストリーミング受信装置であって、前記帯域決定部は、前記動画像データの表示状態が変更された場合、変更された後の表示状態に基づいて前記動画像データのストリーミング送信を一時的に停止させるか否かを判断する。

請求項５記載の発明は、請求項４に記載のストリーミング受信装置であって、前記帯域決定部は、前記動画像データの全部または一部が非表示に変更された場合、前記動画像データの配信を一時的に停止させるか否かを判断する。

請求項６記載の発明は、請求項５に記載のストリーミング受信装置であって、前記帯域決定部は、表示されている動画像データの領域と表示されていない動画像データの領域との比率に基づいて、前記動画像データの配信を一時的に停止させるか否かを判断する。

請求項７記載の発明は、請求項４ないし請求項６のいずれかに記載のストリーミング受信装置であって、前記帯域決定部が前記動画像データの配信を一時的に停止させると判断した場合、前記要求部は、前記動画像データの通信帯域を０にするように前記配信装置に要求する。

請求項８記載の発明は、請求項１ないし請求項７のいずれかに記載のストリーミング受信装置であって、前記帯域決定部は、前記動画像データとともに再生される音声データの送信の可否を前記配信装置に通知する。

請求項９記載の発明は、ストリーミングシステムであって、動画像データをストリーミング送信する配信装置と、前記配信装置からストリーミング送信される動画像データを受信する受信装置と、を備え、前記配信装置から受信した動画像データを再生して表示する再生部と、前記再生部により再生される動画像データの表示状態を変更する変更部と、前記変更部により前記動画像データの表示状態が変更された場合、変更された表示状態に応じて前記動画像データの通信帯域を決定する帯域決定部と、前記帯域決定部により決定された通信帯域に対応する前記動画像データのストリーミング送信を前記配信装置に要求する要求部と、を備え、前記配信装置は、前記受信装置から要求された通信帯域に応じて、前記動画像データの通信帯域を変更する帯域変更部、を備える。

請求項１０記載の発明は、ネットワークを介して配信装置からストリーミング送信される動画像データを受信するストリーミング受信装置に搭載されるコンピュータに、受信した動画像データを再生して表示するステップと、再生される動画像データの表示状態を変更するステップと、前記動画像データの表示状態が変更された場合、変更された表示状態に応じて前記動画像データの通信帯域を決定するステップと、決定された通信帯域に対応する前記動画像データのストリーミング送信を前記配信装置に要求するステップと、を実行させるためのプログラムである。

本発明のストリーミング受信装置は、配信装置からストリーミング送信される動画像データの表示状態が変更された場合、変更後の表示状態に応じて動画像データの通信帯域を決定して配信装置に要求する。表示状態に応じて動画像データの通信帯域が制御されるため、ネットワークを有効に利用することができる。

本発明の第１の実施の形態に係るストリーミングシステムの構成を示す機能ブロック図である。 図１に示すストリーミング受信装置の構成を示す機能ブロック図である。 図１に示す配信装置の構成を示す機能ブロック図である。 図１に示すストリーミングシステムのシーケンス図である。 図２に示す品質テーブルの一例を示す図である。 図１に示すストリーミング受信装置のモニタに表示された動画像データを示す図である。 図６に示す動画像データの表示サイズが変更された状態を示す図である。 図６に示す動画像データが隠された状態を示す図である。 本発明の第２の実施の形態に係るテレビ会議システムの構成を示す機能ブロック図である。 図９に示すクライアント端末の構成を示す機能ブロック図である。 図９に示すテレビ会議システムのシーケンス図である。 図９に示すクライアント端末に表示されるウィンドウの一例を示す図である。 図１２に示すウィンドウにおいて、動画像データの表示サイズが変更された後の動画像データの配置を示す図である。 図９に示すクライアント端末に表示されるウィンドウの他の例を示す図である。

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

＜第１の実施の形態＞
［１．ストリーミングシステムの全体構成］
図１は、本実施の形態に係るストリーミングシステム１００の構成を示す機能ブロック図である。図１に示すように、ストリーミングシステム１００は、配信装置１と、ストリーミング受信装置２とを備える。ストリーミング受信装置２は、インターネット３を介して配信装置１と接続される。以下、ストリーミング受信装置２を、単に「受信装置２」と呼ぶ。

配信装置１は、受信装置２の要求に応じて、動画像データ３１をストリーミング送信する。送信中の動画像データ３１のビットレートは、受信装置２の要求に応じて変更される。受信装置２は、ストリーミング送信された動画像データ３１を再生して表示する。

受信装置２は、ユーザの操作により動画像データ３１の表示サイズ（表示面積）が変更された場合、変更後の表示サイズに応じて、動画像データ３１のビットレートの変更を要求する。受信装置２は、変更後の表示サイズに基づいて、配信装置１から送信される動画像データ３１のビットレートを決定し、ビットレートの変更を配信装置１に要求する。配信装置１は、要求されたビットレートで動画像データ３１をストリーミング送信する。

ここで、動画像データ３１のビットレートは、動画像データ３１の画質を決定するパラメータであり、動画像データ３１のストリーミング送信に必要な通信帯域を意味する。

動画像データ３１の表示サイズが拡大された場合、配信される動画像データ３１のビットレートは、拡大率に応じて大きくなる。動画像データ３１のビットレートが、表示サイズが拡大されたにも関わらず維持された場合、動画像データ３１が粗く表示され、画質が劣化する。しかし、動画像データ３１のビットレートを拡大率に応じて大きくすることにより、表示サイズが拡大された場合であっても、動画像データ３１の画質劣化を防ぐことができる。また、表示サイズに応じて動画像データ３１のビットレートが制御されるため、ネットワークを有効に利用できる。

［２．ストリーミング受信装置２の構成］
図２は、受信装置２の構成を示す機能ブロック図である。図２に示すように、受信装置２は、ＣＰＵ（Central Processing Unit）２１と、ＲＡＭ（Random Access Memory）２２と、操作部２３と、モニタ２４と、ネットワークインタフェース２５と、ＨＤＤ（Hard Disk Drive）２６とを備える。受信装置２は、例えば、ＰＣである。ＰＣは、動画再生プログラム２８がインストールされることにより、受信装置２として機能する。動画再生プログラム２８は、ストリーミング送信される動画像データ３１を再生してモニタ２４に表示させるために用いられる。

ＣＰＵ２１は、ＨＤＤ２６に格納されたプログラムを実行する。ＲＡＭ２２は、受信装置２のメインメモリである。ＣＰＵ２１は、プログラムをＲＡＭ２２にロードし、ロードされたプログラムを実行して、受信装置２を制御する。

操作部２３は、受信装置２に対するユーザの各種操作を受け付ける。操作部２３は、例えば、キーボードやマウスである。

ネットワークインタフェース２５は、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet Protocol）などのプロトコルを用いて、インターネット３に接続されたコンピュータと通信する。

モニタ２４は、ストリーミング送信される動画像データ３１を表示する。モニタ２４に表示される動画像データ３１の表示サイズは、ユーザの操作に応じて変更される。

ＨＤＤ２６は、品質テーブル２７と、動画再生プログラム２８とを格納する。品質テーブル２７は、モニタ２４に表示される動画像データ３１の表示サイズと動画像データ３１のビットレートとの関係を示す。品質テーブル２７の詳細については後述する。

［３．配信装置１の構成］
図３は、配信装置１の構成を示す機能ブロック図である。図３に示すように、配信装置１は、ＣＰＵ１１と、ＲＡＭ１２と、ネットワークインタフェース１３と、ＨＤＤ１４とを備える。配信装置１は、例えば、サーバである。サーバは、配信プログラム１５がインストールされることにより、配信装置１として機能する。

ＣＰＵ１１、ＲＡＭ１２、及びネットワークインタフェース１３は、受信装置２が備えるＣＰＵ２１、ＲＡＭ２２、及びネットワークインタフェース２５と同様であるため、その詳細な説明を省略する。

ＨＤＤ１４は、配信プログラム１５と、動画像データ３１と、品質テーブル２７とを格納する。配信プログラム１５を実行する配信装置１は、受信装置２からの要求に応じて、動画像データ３１をストリーミング送信する。

［４．ストリーミング送信の流れ］
図４は、ストリーミングシステム１００の動作を示すシーケンス図である。図４において、配信装置１が配信プログラム１５を実行しているときの動作と、受信装置２が動画再生プログラム２８を実行しているときの動作を示している。図５は、品質テーブル２７の一例を示す図である。

図４及び図５を参照しながら、受信装置２が動画像データ３１のストリーミング送信を要求してから、ストリーミング送信される動画像データ３１のビットレートが変更されるまでの各装置の動作を説明する。

［４．１．表示サイズの変更時の動作］
ユーザは、受信装置２を操作して、動画像データ３１のストリーミングを指示する。受信装置２は、品質テーブル２７を参照して、動画像データ３１のビットレートを初期値の６４ｋｂｐｓに設定する（ステップＳ１）。受信装置２は、品質テーブル２７を参照することにより、６４ｋｂｐｓのビットレートで配信される動画像データ３１の表示サイズ、解像度、フレームレートを事前に把握することができる。

品質テーブル２７は、動画像データ３１の初期設定時及び拡大表示時における表示サイズ、画素数、面積比率、フレームレート、及びビットレートを記録したデータである。初期設定時のビットレートは、６４ｋｂｐｓである。初期設定時の表示サイズは、横１６０×縦１２０ピクセルである。初期設定時のフレームレートは、５ｆｐｓである。拡大表示時の画素数は、１９２００である。

一方、拡大表示時のビットレートは、２５６ｋｂｐｓである。拡大表示時の表示サイズは、３２０×２４０ピクセルである。拡大表示時のフレームレートは、１０ｆｐｓである。拡大表示時の画素数は、７６８００である。面積比率は、初期設定時の表示サイズと拡大表示時の表示サイズとの比率を示す。拡大表示時において、縦サイズ及び横サイズがそれぞれ初期設定時の２倍となっているため、拡大表示時の面積比率は、４に設定される。

受信装置２は、動画像データ３１を特定するデータと、初期設定で設定されたビットレート（６４ｋｂｐｓ）とを含むストリーミング開始要求を配信装置１に送信する（ステップＳ２）。配信装置１は、ストリーミング開始要求で指定されたビットレート（６４ｋｂｐｓ）に基づいて、動画像データ３１のビットレートを変更する（ステップＳ３）。具体的には、配信装置１は、ＨＤＤ１４に格納された品質テーブル２７を参照して、受信装置２によって指定されたビットレート（６４ｋｂｐｓ）に対応する表示サイズ（１６０×１２０ピクセル）、画素数（１９２００）、及びフレームレート（５ｆｐｓ）を特定する。配信装置１は、特定した表示サイズ、画素数、及びフレームレートに基づいて、動画像データ３１のビットレートを６４ｋｂｐｓに変更する。

配信装置１は、ビットレートが６４ｋｂｐｓの動画像データ３１のストリーミング送信を開始する（ステップＳ４）。受信装置２は、ストリーミング送信される動画像データ３１を受信し、動画像データ３１の再生を開始する（ステップＳ５）。

図６は、動画像データ３１の再生が開始された時のモニタ２４を示す図である。動画像データ３１は、モニタ２４に表示されるウィンドウ２４ａ内で再生される。再生される動画像データ３１の表示サイズ及びフレームレートは、それぞれ１６０×１２０ピクセル及び５ｆｐｓである。

拡大ボタン２４ｂは、再生中の動画像データ３１の表示サイズの拡大を指示するボタンである。拡大ボタン２４ｂがクリックされた場合、受信装置２は、再生中の動画像データ３１の表示サイズを１６０×１２０ピクセルから３２０×２４０ピクセルに変更する（ステップＳ６）。

図７は、表示サイズが拡大された動画像データ３１を示す図である。図７に示すように、再生中の動画像データ３１の表示サイズが変更された場合（ステップＳ６）、受信装置２は、品質テーブル２７を参照して、再生中の動画像データ３１のビットレートを新たに決定する（ステップＳ７）。変更後の表示サイズが３２０×２４０ピクセルであるため、受信装置２は、再生中の動画像データ３１のビットレートを２５６ｋｂｐｓに決定する。

受信装置２は、動画像データ３１のビットレートを２５６ｋｂｐｓに指定したビットレート変更要求を配信装置１に送信する（ステップＳ８）。配信装置１は、ビットレート変更要求を受信した場合、ビットレート変更要求で指定されたビットレートに対応する動画像データ３１を品質テーブル２７に基づいて生成する（ステップＳ９）。具体的には、ＨＤＤ１４に格納されている動画像データ３１のビットレートが、２５６ｋｂｐｓに変更される。２５６ｋｐｂｓの動画像データ３１のフレームレートは、１０ｆｐｓであり、総画素数は、７６８００である。

配信装置１は、６４ｋｂｐｓのビットレートで送信中の動画像データ３１に代えて、ビットレートが２５６ｋｂｐｓである動画像データ３１のストリーミング送信を開始する（ステップＳ１０）。配信装置１は、ストリーミング送信を最初からやり直すのではなく、６４ｋｂｐｓの動画像データ３１のフレームのうち最後に送信したフレームの次のフレームから、ビットレートが２５６ｋｂｐｓの動画像データ３１の送信を開始する。これにより、動画像データ３１の表示が途切れることを防止できる。

受信装置２は、ストリーミング送信される２５６ｋｂｐｓの動画像データ３１を再生して、ウィンドウ２４ａ内に表示する（図７参照）。この結果、表示サイズが拡大された動画像データ３１は、表示サイズが拡大される前の動画像データ３１（図６参照）と変わらない画質で表示される。

また、受信装置２のユーザは、図７に示すように、縮小ボタン２４ｃをクリックすることにより、動画像データ３１の現在の表示サイズ（３２０×２４０ピクセル）を、初期設定時の表示サイズ（１６０×１２０ピクセル）に縮小することができる。この場合、受信装置２は、ステップＳ５〜Ｓ８を実行して、ビットレートが６４ｋｂｐｓの動画像データ３１を送信するように配信装置１に要求する。

再生中の動画像データ３１の表示サイズが縮小された場合、受信装置２は、２５６ｋｂｐｓよりも低いビットレートの動画像データ３１を用いても、再生中の動画像データ３１の画質を維持することができる。このため、受信装置２は、品質テーブル２７と縮小後の表示サイズとに基づいて、ビットレートが６４ｋｂｐｓの動画像データ３１の送信を要求する（ステップＳ８）。過剰な画質の動画像データ３１（２５６ｋｂｐｓ）が送信されることがないため、ネットワークを有効に利用することができる。

［４．２．非表示に変更された際の動作］
図８は、図６に示す再生中の動画像データ３１が隠された状態を示す図である。図８に示すように、受信装置２は、ウィンドウ２４ａ内の動画像データ３１の全部がウィンドウ２４ｄにより隠された場合、動画像データ３１のストリーミング送信の一時停止を配信装置１に要求する。

図６に示すように、動画像データ３１が、１６０×１２０ピクセルの表示サイズでウィンドウ２４ａ内に表示されていると仮定する。その後、図８に示すように、ユーザが、文章作成アプリケーションや、地図表示ソフトウェアなどのウィンドウ２４ｄをウィンドウ２４ａの上に配置する。動画像データ３１がウィンドウ２４ｄによって隠されるため、再生中の動画像データ３１は、表示状態から非表示状態に変更される（ステップＳ６）。

受信装置２は、動画像データ３１のストリーミング送信を一時停止させるために、動画像データ３１のビットレートを０ｋｂｐｓに決定する（ステップＳ７）。ビットレートが０ｋｂｐｓに指定されたビットレート変更要求が、配信装置１に送信される（ステップＳ８）。配信装置１は、ビットレート変更要求で指定されたビットレートが０ｋｂｐｓであるため、動画像データ３１のストリーミング送信を一時的に停止する。この場合、配信装置１は、動画像データ３１に含まれる音声データの送信のみを継続してもよい。

受信装置２のユーザが、ウィンドウ２４ａを一番上に表示することにより、動画像データ３１の全てが表示された場合（ステップＳ６）、受信装置２は、動画像データ３１が表示状態に変更されたと判断し、動画像データ３１のビットレートを現在の表示サイズ（１６０×１２０ピクセル）に対応する６４ｋｂｐｓに決定する（ステップＳ７）。ビットレートが６４ｋｂｐｓに指定されたビットレート変更要求が、配信装置１に送信される（ステップＳ８）。配信装置１は、動画像データ３１のストリーミング送信を、送信を停止した位置から再開する（ステップＳ１０）。動画像データ３１のストリーミング送信の一時停止が行われる前後で、動画像データ３１のビットレートが変更されていないため、ステップＳ９は、実行されない。

このように、再生中の動画像データ３１が非表示に変更された場合、受信装置２のユーザは、動画像データ３１を視聴していないため、配信装置１は、動画像データ３１を送信する必要がない。受信装置２は、動画像データ３１が非表示に変更された場合、動画像データ３１の送信の一時停止を配信装置１に要求する。これにより、無駄なデータが送信されないため、ネットワーク帯域の圧迫を防止することができる。

また、ウィンドウ２４ａ内の動画像データ３１の一部がウィンドウ２４ｄにより隠される場合がある。この場合、受信装置２は、表示されている領域と隠された領域との比率に応じて、ストリーミング送信を一時停止させるか否かを決定すればよい。例えば、隠された領域の比率が５０％を超える場合、受信装置２は、一時停止を決定する。一方、隠された領域の比率が５０％以下である場合、受信装置２は、ストリーミング送信の継続を決定する。

＜第２の実施の形態＞
以下、本発明の第２の実施の形態について詳しく説明する。上記第１の実施の形態と重複する点についての説明は、省略する。

［１．テレビ会議システム２００の全体構成］
図９は、第２の実施の形態に係るテレビ会議システム２００の構成を示す機能ブロック図である。図９に示すように、テレビ会議システム２００は、配信装置１と、クライアント端末４〜６とを備える。配信装置１とクライアント端末４〜６とは、インターネット３を介して相互に接続されている。なお、図９に示していないが、クライアント端末４〜6以外のクライアント端末も、テレビ会議システム２００を構成する。

クライアント端末４〜６は、テレビ会議システムに参加するユーザが操作する機器である。クライアント端末４は、カメラ４ａにより撮影された映像と、マイク４ｂに入力された音声データとが符号化された動画像データ３４を配信装置１にリアルタイムに送信する。同様に、クライアント端末５，６も、動画像データ３５，３６を配信装置１にリアルタイムに送信する。動画像データ３４〜３６の初期設定時のビットレートは、６４ｋｂｐｓである。

配信装置１は、クライアント端末４〜６から送信される動画像データ３４〜３６を中継してストリーミング送信する。動画像データ３４は、配信装置１を経由してクライアント端末５，６にストリーミング送信される。動画像データ３５は、配信装置１を経由してクライアント端末４，６にストリーミング送信される。動画像データ３６は、配信装置１を経由してクライアント端末４，５にストリーミング送信される。クライアント端末４〜６は、ストリーミング送信される動画像データを再生する。クライアント端末４〜６のユーザは、再生される動画像データを見ながらテレビ会議を行う。

クライアント端末４のユーザが、再生中の動画像データ３５の表示サイズを拡大した場合、クライアント端末４は、拡大された表示サイズに応じたビットレート（２５６ｋｂｐｓ）で動画像データ３５をストリーミング送信するように、配信装置１に要求する。配信装置１は、２５６ｋｂｐｓの動画像データ３１を取得するために、動画像データ３５の送信元（クライアント端末５）に対してビットレートが２５６ｋｂｐｓに設定された動画像データ３５の送信を指示する。これにより、配信装置１は、２５６ｋｂｐｓの動画像データ３１をクライアント端末４にストリーミング送信する。詳細については後述するが、クライアント端末６に対しては、６４ｋｂｐｓの動画像データ３５が引き続きストリーミング送信される。

［２．クライアント端末４の構成］
図１０は、クライアント端末４の構成を示す機能ブロック図である。以下、図１０を参照しながら、クライアント端末４の構成を説明する。クライアント端末５，６の構成は、クライアント端末４と同様であるため、その説明を省略する。なお、配信装置１の構成は、図３に示す通りである。

クライアント端末４は、例えば、ＰＣである。ＰＣは、テレビ会議プログラム４８がインストールされることにより、クライアント端末として機能する。テレビ会議プログラム４８は、ＰＣをテレビ会議システムのクライアント端末として動作させるために用いられる。

クライアント端末４は、ＣＰＵ４１と、ＲＡＭ４２と、操作部４３と、モニタ４４と、ネットワークインタフェース４５と、ＨＤＤ４６と、ＵＳＢ（Universal Serial Bus）インタフェース４７とを備える。

ＣＰＵ４１、ＲＡＭ４２、操作部４３、モニタ４４、及びネットワークインタフェース４５は、受信装置２が備える構成と同様である。ＵＳＢインタフェース４７は、カメラ４ａ，マイク４ｂをクライアント端末４に接続するために用いられる。ＨＤＤ４６は、品質テーブル２７及びテレビ会議プログラム４８を格納する。

［３．テレビ会議システム２００の動作］
図１１は、テレビ会議システム２００のシーケンス図である。図１１を参照しながら、配信装置１及びクライアント端末４〜６の動作を説明する。なお、クライアント端末４〜６は、テレビ会議プログラム４８をそれぞれ実行しており、配信装置１は、配信プログラム１５を実行している。

［３．１．テレビ会議の開始］
配信装置１は、テレビ会議に参加するクライアント端末４〜６を予め登録しており、動画像データ３４〜３６がクライアント端末４〜６から送信されるまで待機する。

クライアント端末４〜６は、動画像データ３４〜３６を配信装置１に送信するための初期設定を行う（ステップＳ２１〜Ｓ２３）。クライアント端末４は、品質テーブル２７を参照して、動画像データ３４のビットレートを初期値の６４ｋｂｐｓに設定する。

配信装置１は、テレビ会議が開始される際、クライアント端末４〜６から送信される６４ｋｂｐｓの動画像データをそのまま中継する。具体的には、クライアント端末５は、動画像データ３５のリアルタイム送信を開始する（ステップＳ２４）。具体的には、クライアント端末５は、カメラが撮影した映像及びマイクに入力された音声を符号化して、ビットレートが６４ｋｂｐｓの動画像データ３５を生成する。生成された動画像データ３５が、配信装置１に順次送信される。配信装置１は、クライアント端末５から送信された動画像データ３５を、そのままクライアント端末４，６にストリーミング送信する（ステップＳ２５，Ｓ２６）。

同様に、クライアント端末４は、ビットレートが６４ｋｂｐｓの動画像データ３４のリアルタイム送信を開始する（ステップＳ２７）。配信装置１は、動画像データ３４をクライアント端末５，６にストリーミング送信する（ステップＳ２８，Ｓ２９）。クライアント端末６は、動画像データ３６のリアルタイム送信を開始する（ステップＳ３０）。配信装置１は、動画像データ３６をクライアント端末４，５にストリーミング送信する（ステップＳ３１，Ｓ３２）。

クライアント端末４は、ストリーミング送信される動画像データ３５，３６の再生を開始する（ステップＳ３３）。図１１に示していないが、クライアント端末５，６も、ストリーミング送信される動画像データの再生を開始する。

［３．２．動画像データ３５の表示サイズの拡大］
以下、クライアント端末４を例にして、各クライアント端末に表示されるテレビ会議用のウィンドウを説明する。図１２は、テレビ会議に用いられるウィンドウ５０を示す図である。ウィンドウ５０は、クライアント端末４のモニタ４４に表示される。

図１２において、クライアント端末４のユーザの映像（動画像データ３４）が、ウィンドウ５０の左側に表示される。配信装置１からストリーミング送信される動画像データ３５，３６，５１〜５７が、ウィンドウ５０の右側に整列して配置される。動画像データ５１〜５７は、図９に示されていない他のクライアント端末で生成され、配信装置１によりストリーミング送信される。図１２において、動画像データの映像の表示を省略している。動画像データ３５，３６，５１〜５７は、ビットレートが６４ｋｂｐｓであり、１６０×１２０ピクセルで表示される。

図１３は、クライアント端末４において、動画像データ３５の表示サイズが拡大された際のウィンドウ５０を示す図である。クライアント端末４のユーザが、ウィンドウ５０中の動画像データ３５の表示サイズを４倍（３２０×２４０ピクセル）に拡大する（ステップＳ３４）。この結果、動画像データ５５〜５７が非表示となり、ウィンドウ５０に表示される動画像データの数は、９から６に減少する（動画像データ３４を除く）。動画像データ３６，５１〜５４の表示サイズは、変更されず、１６０×１２０ピクセルのままである。クライアント端末４は、動画像データ３５，５５〜５７の表示状態が変更されたため（ステップＳ３４）、動画像データ３５，５５〜５７のビットレートの変更を配信装置１に要求する。

具体的には、クライアント端末４は、動画像データ３５，５５〜５７のビットレートを決定する（ステップＳ３５）。動画像データ３５の表示サイズが３２０×１６０ピクセルに変更されたため、動画像データ３５のビットレートは、品質テーブル２７に基づいて、２５６ｋｂｐｓに決定される。動画像データ５５〜５７が非表示に変更されたため、動画像データ５５〜５７のビットレートは、０ｋｂｐｓに決定される。つまり、クライアント端末４は、非表示に変更された動画像データ５５〜５７のストリーミング送信を一時停止させることを決定する。

クライアント端末４は、動画像データ３５のビットレートを２５６ｋｂｐｓに指定し、動画像データ５５〜５７のビットレートを０ｋｂｐｓに指定したビットレート変更要求を配信装置１に送信する（ステップＳ３６）。

配信装置１は、クライアント端末４からのビットレート変更要求に応じて、クライアント端末４に対する動画像データ５５〜５７のストリーミング送信を停止する（ステップＳ３７）。図１１に示していないが、クライアント端末４以外の端末は、再生中の動画像データ３５の表示サイズを変更していないため、動画像データ５５〜５７は、クライアント端末４以外の端末に引き続きストリーミング送信される。

ビットレート変更要求により、動画像データ３５のビットレートが２５６ｋｂｐｓに指定されているが、ステップＳ２４に示すように、クライアント端末５は、６４ｋｂｐｓの動画像データ３５を配信装置１に送信している。このため、配信装置１は、動画像データ３５のビットレートを２５６ｋｂｐｓに指定したビットレート変更要求をクライアント端末５に送信する（ステップＳ３８）。

クライアント端末５は、配信装置１からのビットレート変更要求に応じて、動画像データ３５の符号化条件を変更する（ステップＳ３９）。具体的には、クライアント端末５は、指定されたビットレート（２５６ｋｂｐｓ）と品質テーブル２７とに基づいて、動画像データ３５のフレームレート、画素数、表示サイズを１０ｆｐｓ、７６８００、３２０×２４０ピクセルにそれぞれ決定する。クライアント端末５は、決定したフレームレート、画素数及び表示サイズに基づいて、ビットレートが２５６ｋｂｐｓの動画像データ３５を生成する。クライアント端末５は、新たな符号化条件に基づいて生成された動画像データ３５（２５６ｋｂｐｓ）の送信を開始する（ステップＳ４０）。

配信装置１は、クライアント端末４から２５６ｋｂｐｓの動画像データ３５の配信を要求されているため、２５６ｋｂｐｓの動画像データ３５をそのままクライアント端末４へストリーミング送信する。（ステップＳ４１）。

一方、クライアント端末６は、動画像データ３５のビットレートの変更を要求していない。このため、配信装置１は、クライアント端末６に対する動画像データ３５（６４ｋｂｐｓ）のストリーミング送信を継続するために、品質テーブル２７に基づいて、ビットレート変換処理を実行する（ステップＳ４２）。配信装置１は、２５６ｋｂｐの動画像データのフレームを間引くことにより、フレームレートを１０ｆｐｓから５ｆｐｓに変更し、２５６ｋｂｐｓの動画像データ３５の表示サイズを３２０×２４０ピクセルから１６０×１２０ピクセルに変更する。このようにして、動画像データ３５のビットレートが、２５６ｋｂｐｓから６４ｋｂｐｓに変更される。配信装置１は、ビットレートが６４ｋｂｐｓに変更された動画像データ３５をクライアント端末６にストリーミング送信する（ステップＳ４３）。

以上の処理が行われた結果、クライアント端末４は、動画像データ３５の表示サイズが４倍に拡大された後に、ビットレートが２５６ｋｂｐｓの動画像データ３５を再生する。クライアント端末４は、画質を劣化させることなく動画像データ３５を拡大して再生することができる。

また、クライアント端末６は、動画像データ３５の表示サイズを初期値（１６０×１２０ピクセル）のまま変更していないため、配信装置１は、クライアント端末６に対して６４ｋｂｐｓの動画像データ３５のストリーミング送信を継続する。クライアント端末６は、１６０×１２０ピクセルの表示サイズで動画像データ３５を再生する際に、過剰な画質の動画像データ３５（２５６ｋｂｐｓ）を受信しない。したがって、ネットワーク帯域が無駄に圧迫されることがないため、ネットワークを有効に利用できる。

［３．３．動画像データ３５の表示サイズの縮小］
クライアント端末４において、ウィンドウ５０が図１３に示す状態から図１２に示す状態に変更された場合の各機器の動作を説明する。

ウィンドウ５０において、動画像データ３５の表示サイズが３２０×２４０ピクセルから１６０×１２０ピクセルに縮小される（ステップＳ３４）。クライアント端末４は、品質テーブル２７を参照して、動画像データ３５のビットレートを６４ｋｂｐｓに決定する（ステップＳ３５）。

動画像データ３５の表示サイズの縮小に伴って、動画像データ５５〜５７が再び表示される（ステップＳ３４）。クライアント端末４は、動画像データ５５〜５７が表示状態に変更されたため、動画像データ５５〜５７のストリーミング送信の再開を決定する。クライアント端末４は、動画像データ５５〜５７の表示サイズ（１６０×１２０ピクセル）に基づいて、動画像データ５５〜５７のビットレートを６４ｋｂｐｓに決定する（ステップＳ３５）。

クライアント端末４は、動画像データ３５，５５〜５７のビットレートを６４ｋｂｐｓに指定したビットレート変更要求を配信装置１に送信する（ステップＳ３６）。配信装置１は、クライアント端末４に対して、動画像データ５５〜５７（６４ｋｂｐｓ）のストリーミング送信を再開する。このとき、ステップＳ３７は、実行されない。

また、全てのクライアント端末が、動画像データ３５のビットレートを６４ｋｂｐｓに指定したため、配信装置１は、２５６ｋｂｐｓの動画像データ３５を取得する必要がない。このため、配信装置１は、動画像データ３５のビットレートを６４ｋｂｐｓに指定したビットレート変更要求をクライアント端末４に送信する（ステップＳ３８）。クライアント端末５は、６４ｋｂｐｓの動画像データ３５を生成するように符号化条件を変更し（ステップＳ３９）、６４ｋｂｐｓの動画像データ３５の送信を開始する（ステップＳ４０）。

配信装置１は、６４ｋｂｐｓの動画像データ３５をクライアント端末４，６にストリーミング送信する（ステップＳ４１，４３）。クライアント端末４，６が要求する動画像データ３５のビットレートが６４ｋｂｐｓであるため、ビットレート変更処理（ステップＳ４２）は、実行されない。

このように、テレビ会議システム２００において、クライアント端末４は、動画像データ３５の表示サイズが変更された場合、変更後の表示サイズに応じて動画像データ３５のビットレートの変更を配信装置１に要求する。これにより、表示サイズに応じたビットレートの動画像データ３５が配信装置１からクライアント端末４へ送信されるため、ネットワーク帯域を有効に利用できる。

また、クライアント端末４，６が互いに異なるビットレートで動画像データ３５を送信するように要求している。配信装置１は、動画像データ３５（２５６ｋｂｐｓ）のビットレートを６４ｋｂｐｓに変更し、６４ｋｂｐｓの動画像データ３５をクライアント端末に送信する。これにより、クライアント端末６の表示サイズに応じた６４ｋｂｐｓの動画像データ３５が、クライアント端末６にストリーミング送信されるため、ネットワーク帯域が無駄に圧迫されることを防止できる。

また、図１４に示すように、ストリーミング送信される動画像データの表示、非表示を、スクロールバー６０を用いて変更してもよい。例えば、テレビ会議に参加するクライアント端末の数によっては、ストリーミング送信される全ての動画像データをウィンドウ５０に表示できない場合がある。この場合、ユーザは、動画像データ３５，３６，５１〜５７が表示された子ウィンドウ５０ａを、スクロールバー６０を用いてスクロールすることにより、子ウィンドウ５０ａに表示させる動画像データを変更する。子ウィンドウ５０ａのスクロールにより、動画像データの表示、非表示が切り替わった場合、クライアント端末４は、上記と同様に、ビットレートの変更を配信装置１に要求する。

上記実施の形態では、動画像データの表示サイズが変更された場合、動画像データのビットレートが、変更後の表示サイズと品質テーブルとに基づいて決定される例を説明したが、これに限られない。例えば、受信装置２は、表示サイズの変化率に基づいて、動画像データのビットレートを決定してもよい。例えば、第１の実施の形態において、ユーザが、動画像データ３１の表示サイズを１．５倍に拡大した場合、受信装置２は、動画像データ３１の現在のビットレートを１．５倍することにより、新たなビットレートを決定してもよい。

また、上記実施の形態において、表示される動画像データとともに再生される音声のオン、オフを切り替えるようにしてもよい。例えば、第２の実施の形態において、クライアント端末４は、ユーザが動画像データ３６の音声のミュートを指示した場合、動画像データ３６のミュートを要求するメッセージを配信装置１に送信してもよい。この場合、配信装置１は、クライアント端末４の要求に応じて、符号化された音声データを含まない動画像データ３６をクライアント端末４にストリーミング送信すればよい。クライアント端末５は、動画像データ３６のミュートを要求していないため、配信装置１は、音声データを含む動画像データ３６をクライアント端末６に送信する。

なお、上記実施の形態で説明した各処理を専用回路で実現してもよい。この場合、専用回路をＬＳＩなどの半導体装置により１チップ化してもよいし、一部又は全部の処理を含むように１チップ化してもよい。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。

また、上記各実施の形態の各処理の一部または全部を、ソフトウェアおよびハードウェアの混在処理により実現しても良い。なお、上記実施形態の各処理をハードウェアにより実現する場合、各処理を行うためのタイミング調整を行う必要があるのは言うまでもない。上記実施形態においては、説明便宜のため、実際のハードウェア設計で生じる各種信号のタイミング調整の詳細については省略している。

以上、本発明の実施の形態を説明したが、上述した実施の形態は本発明を実施するための例示に過ぎない。よって、本発明は上述した実施の形態に限定されることなく、その趣旨を逸脱しない範囲内で上述した実施の形態を適宜変形して実施することが可能である。

１００ ストリーミングシステム
２００ テレビ会議システム
１ 配信装置
２ ストリーミング受信装置（受信装置）
４〜６ クライアント端末
１１，２１，４１ ＣＰＵ
１２，２２，４２ ＣＰＵ
２３，４３ 操作部」
２４，４４ モニタ
２７ 品質テーブル
３１，３５，３６，５１〜５７ 動画像データ

Claims (10)

1. ネットワークを介して配信装置からストリーミング送信される動画像データを再生して表示する再生部と、
   前記再生部により再生される動画像データの表示状態を変更する変更部と、
   前記変更部により前記動画像データの表示状態が変更された場合、変更された表示状態に応じて前記動画像データの通信帯域を決定する帯域決定部と、
   前記帯域決定部により決定された通信帯域に対応する前記動画像データのストリーミング送信を前記配信装置に要求する要求部と、
   を備えるストリーミング受信装置。
2. 請求項１に記載のストリーミング受信装置であって、
   前記変更部は、前記再生部により再生される動画像データのサイズを変更し、
   前記帯域決定部は、前記動画像データのサイズの変化率に応じて、前記通信帯域を決定するストリーミング受信装置。
3. 請求項２に記載のストリーミング受信装置であって、
   前記変更部が前記動画像データのサイズを大きくした場合、前記帯域決定部は、サイズが変更される前の通信帯域よりも大きくなるように、サイズが変更された後の通信帯域を決定するストリーミング受信装置。
4. 請求項１ないし請求項３のいずれかに記載のストリーミング受信装置であって、
   前記帯域決定部は、前記動画像データの表示状態が変更された場合、変更された後の表示状態に基づいて前記動画像データのストリーミング送信を一時的に停止させるか否かを判断するストリーミング受信装置。
5. 請求項４に記載のストリーミング受信装置であって、
   前記帯域決定部は、前記動画像データの全部または一部が非表示に変更された場合、前記動画像データの配信を一時的に停止させるか否かを判断するストリーミング受信装置。
6. 請求項５に記載のストリーミング受信装置であって、
   前記帯域決定部は、表示されている動画像データの領域と表示されていない動画像データの領域との比率に基づいて、前記動画像データの配信を一時的に停止させるか否かを判断するストリーミング受信装置。
7. 請求項４ないし請求項６のいずれかに記載のストリーミング受信装置であって、
   前記帯域決定部が前記動画像データの配信を一時的に停止させると判断した場合、前記要求部は、前記動画像データの通信帯域を０にするように前記配信装置に要求するストリーミング受信装置。
8. 請求項１ないし請求項７のいずれかに記載のストリーミング受信装置であって、
   前記帯域決定部は、前記動画像データとともに再生される音声データの送信の可否を前記配信装置に通知するストリーミング受信装置。
9. 動画像データをストリーミング送信する配信装置と、
   前記配信装置からストリーミング送信される動画像データを受信する受信装置と、
   を備え、
   前記配信装置から受信した動画像データを再生して表示する再生部と、
   前記再生部により再生される動画像データの表示状態を変更する変更部と、
   前記変更部により前記動画像データの表示状態が変更された場合、変更された表示状態に応じて前記動画像データの通信帯域を決定する帯域決定部と、
   前記帯域決定部により決定された通信帯域に対応する前記動画像データのストリーミング送信を前記配信装置に要求する要求部と、
   を備え、
   前記配信装置は、
   前記受信装置から要求された通信帯域に応じて、前記動画像データの通信帯域を変更する帯域変更部、
   を備えるストリーミングシステム。
10. ネットワークを介して配信装置からストリーミング送信される動画像データを受信するストリーミング受信装置に搭載されるコンピュータに、
    受信した動画像データを再生して表示するステップと、
    再生される動画像データの表示状態を変更するステップと、
    前記動画像データの表示状態が変更された場合、変更された表示状態に応じて前記動画像データの通信帯域を決定するステップと、
    決定された通信帯域に対応する前記動画像データのストリーミング送信を前記配信装置に要求するステップと、
    を実行させるためのプログラム。

Images