JP6160066B2

JP6160066B2 - 映像表示システム及び映像表示装置

Info

Publication number: JP6160066B2
Application number: JP2012260945A
Authority: JP
Inventors: 博信阿倍; 川浦　健央; 健央川浦; 敏志山田; 峯　慎吾; 慎吾峯; 裕希川野
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2012-11-29
Filing date: 2012-11-29
Publication date: 2017-07-12
Anticipated expiration: 2032-11-29
Also published as: JP2014107796A

Description

本発明は、映像データを送信する映像送信装置とネットワークを介して接続された映像表示装置に複数の映像を表示させる映像表示システム及び映像表示装置に関するものである。

ネットワークを介して接続された映像表示装置に対して映像データを送信（配信）して映像表示する映像表示システムにおいては、映像表示装置のメモリ、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＧＰＵ（ＧｒａｐｈｉｃＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）等のリソース不足により映像の表示品質が劣化しないように、映像データを送信する映像送信装置が予め映像表示装置に対してテスト用映像データを送信し、テスト結果に基づいて映像表示装置のリソース、装置能力を把握して、映像表示装置に適した映像データを送信する技術が知られている（例えば、特許文献１参照）。

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

しかしながら、従来の映像表示システムでは、映像送信装置側において映像データの表示品質の制御を行うので、例えば１台の映像表示装置にて同時に複数の映像を表示させるような場合においては、映像送信装置が映像表示装置の消費リソースの情報に基づき映像データそれぞれについて表示品質の制御を行ってから映像表示装置に送信するので、映像表示装置において映像を表示させるまでの処理遅延が生じるという課題があった。

本発明は、上述した課題を解決するためになされたものであり、映像表示装置にて表示させる映像の表示品質を選択することにより処理の遅延を防ぐことができる映像表示システムを提供することを目的とする。

本発明に係る映像表示システムは、映像データを送信する映像送信装置と、前記映像送信装置とネットワークを介して接続され前記映像送信装置からの前記映像データを受信して表示する映像表示装置とを備える映像表示システムであって、前記映像送信装置は、第１のプロファイルのテスト用映像データと第２のプロファイルのテスト用映像データとを送信するテスト用映像データ送信部と、前記映像データを、前記第１のプロファイルと前記第２のプロファイルでエンコードして、それぞれ送信する映像データ送信部と、を備え、前記映像表示装置は、前記第１のプロファイルのテスト用映像データと前記第２のプロファイルのテスト用映像データと、前記第１のプロファイルの映像データと前記第２のプロファイルの映像データとを受信する映像データ受信部と、前記映像データ受信部で受信された前記第１のプロファイルのテスト用映像データに基づく映像を表示する場合の第１の消費リソースと、前記第２のプロファイルのテスト用映像データに基づく映像を表示する場合の第２の消費リソースとを計測するリソース計測部と、前記リソース計測部で計測された前記第１の消費リソースと前記第１のプロファイルとが対応付けられるとともに、前記第２の消費リソースと前記第２のプロファイルとが対応付けられたリソース情報を記憶するリソース情報記憶部と、前記映像データ受信部で受信した前記映像データのプロファイルを、前記リソース情報に基づき、前記第１のプロファイルまたは前記第２のプロファイルのいずれかに選択するプロファイル選択部と、を備えたことを特徴とすることを特徴とする。

本発明に係る映像表示装置は、映像送信装置から送信された第１のプロファイルのテスト用映像データと第２のプロファイルのテスト用映像データと、前記第１のプロファイルの映像データと前記第２のプロファイルの映像データと、を受信する映像データ受信部と、前記映像データ受信部で受信された前記第１のプロファイルのテスト用映像データに基づく映像を表示する場合の第１の消費リソースと、前記第２のプロファイルのテスト用映像データに基づく映像を表示する場合の第２の消費リソースとを計測するリソース計測部と、前記リソース計測部で計測された前記第１の消費リソースと前記第１のプロファイルとが対応付けられるとともに、前記第２の消費リソースと前記第２のプロファイルとが対応付けられたリソース情報を記憶するリソース情報記憶部と、前記映像データ受信部で受信した映像データのプロファイルを、前記リソース情報に基づき、前記第１のプロファイルまたは前記第２のプロファイルのいずれかに選択するプロファイル選択部と、を備えたことを特徴とする。

本発明の映像表示システム及び映像表示装置によれば、映像表示装置が、テスト用映像データを表示する場合に計測された消費リソースとプロファイルとが対応付けられたリソース情報に基づき、受信した映像データのプロファイルを選択して表示するので、映像を表示させるまでの処理遅延を防ぐことができる。

実施の形態１に係る映像表示システムの構成例を示す図である。実施の形態１に係るプロファイルの例を示す図である。実施の形態１に係る消費リソースの例を示す図である。実施の形態１に係るリソース情報の設定処理についての動作例を示すフローチャートである。実施の形態１に係るプロファイルの他の例を示す図である。実施の形態１に係るリソース情報の例を示す図である。実施の形態１に係る複数のテスト用映像データを表示させた場合のリソース情報の例を示す図である。実施の形態１に係る異なるプロファイルのテスト用映像データを表示させた場合のリソース情報の例を示す図である。実施の形態１に係るプロファイル選択処理についての動作例を示すフローチャートである。実施の形態１に係る映像ソースの例を示す図である。実施の形態１に係る受信パラメータの例を示す図である。実施の形態１に係る受信条件の例を示す図である。実施の形態１においてユーザに選択された映像の表示を説明するための図である。実施の形態１に係る表示映像数の増減を説明するための図である。実施の形態２に係る映像表示システムの構成例を示す図である。実施の形態２に係るプロファイル選択処理についての動作例を示すフローチャートである。

実施の形態１．
以下図面を用いて本発明の実施の形態１を説明する。

図１は実施の形態１に係る映像表示システムの構成例を示す図である。映像表示システムは、映像送信装置１と、映像送信装置１とネットワーク２を介して接続される映像表示装置３とを備える。図１の例では映像表示装置３は１台のみの構成となっているが、これに限定されない。例えば、複数台の映像表示装置３がネットワーク２を介して映像送信装置１に接続され、映像を複数の映像表示装置３に跨って表示する映像表示システムであってもよい。

映像送信装置１は、例えば映像配信サーバ、映像配信レコーダ、監視カメラ等により実現され、映像データを映像表示装置３に送信する。映像送信装置１から映像表示装置３への映像データの配信方式は、映像表示装置３間で映像データの同期を取りやすいマルチキャスト方式を採用するが、映像データの同期を取る仕組みがシステムに導入されている場合はユニキャスト方式を採用してもよい。

映像表示装置３は、例えばＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）により実現され、ユーザが操作を行うと、当該操作に応じた映像をディスプレイ上に表示する処理を行う。ここでいう操作には、映像を表示する操作のみならず、例えばウィンドウのオープンまたはクローズ、ウィンドウの拡大、縮小、ドラッグ等の操作も含まれる。

ネットワーク２は、有線、無線を問わず、例えばインターネット、無線ネットワーク等であればよい。

まず、映像送信装置１の詳細な構成について説明する。映像送信装置１は、ネットワーク処理部１１と、映像データ記憶部１２と、テスト用映像データ送信部１３と、映像データ送信部１４と、プロファイル情報記憶部１５とを備える。

ネットワーク処理部１１は、ネットワーク２への各機器の接続処理と所定のデータ伝送プロトコルの制御を行う。

映像データ記憶部１２は、映像表示装置３へ送信するための映像データと、映像表示装置３のメモリ、ＣＰＵ、ＧＰＵ等の消費リソースを測定するためのテスト用映像データとが記憶されている。テスト用映像データは、テスト映像の元データであるテスト用映像ソースが、映像データの表示品質を決定するためのパラメータであるプロファイルを用いてエンコードされることにより生成され、映像データ記憶部１２には、複数の異なるプロファイルを用いてエンコードされた複数のテスト用映像データが記憶される。これらの複数のテスト用映像データは、映像ソースは全て同一であっても、異なるプロファイルによりエンコードされるため、異なる映像データとなる。

図２は実施の形態１に係るプロファイルの例を示す図である。この例では、プロファイルを識別するためのプロファイルＩＤ「１」、プロファイル名「ｎｏｒｍａｌ＿ｈ２６４」、コーデック「Ｈ．２６４」、ｆｐｓ（ｆｒａｍｅｐｅｒｓｅｃｏｎｄ）「３０」、解像度（Ｗ）「６４０」、解像度（Ｈ）「４８０」、品質「８０」（０〜１００で１００を最高品質とする）、配信アドレス「２２４．１．０．１：４７０００」となる。

なお、必ずしも映像データ、テスト用映像データをデータ形式で記憶しておく必要はなく、例えば映像送信装置１が監視カメラ等の場合は、映像ソースをリアルタイムでプロファイルを用いてエンコードして映像表示装置３に送信してもよい。

テスト用映像データ送信部１３は、映像データ記憶部１２に記憶されるテスト用映像データ及びそのテスト用映像データを生成するために用いられたプロファイルに関する情報を、ネットワーク処理部１１を介して映像表示装置３に送信する。また、テスト用映像データ送信部１３は、後述する受信パラメータを映像表示装置３に送信する。

映像データ送信部１４は、映像データ記憶部１２に記憶される映像データを、ネットワーク処理部１１を介して映像表示装置３に送信する。なお、ここでは説明のためテスト用映像データ送信部１３と映像データ送信部１４とが別々に設けられた構成としているが、これに限定されず、同一の送信部から映像データまたはテスト用映像データを送信するものとしてもよい。

プロファイル情報記憶部１５には、映像送信装置１が映像表示装置３に送信したテスト用映像データのプロファイルの情報が記憶される。例えば、図２に示すプロファイルを用いてエンコードされたテスト用映像データが映像表示装置３に送信されると、プロファイルＩＤ「１」に関するプロファイル情報がプロファイル記憶部１４に記憶される。

次に、映像表示装置３の詳細な構成について説明する。映像表示装置３は、ネットワーク処理部３１と、映像データ受信部３２と、映像表示部３３と、リソース計測部３４と、リソース情報記憶部３５と、ＵＩ（ＵｓｅｒＩｎｔｅｒｆａｃｅ）部３６と、プロファイル選択部（映像データ選択部）３７とを備える。

ネットワーク処理部３１は、ネットワーク処理部１１と同様、ネットワーク２への各機器の接続処理と所定のデータ伝送プロトコルの制御を行う。

映像データ受信部３２は、映像送信装置１から送信された映像データまたはテスト用映像データを受信する。

映像表示部３３は、映像データ受信部３２により受信された映像データまたはテスト用映像データに基づく映像を表示する。ただし、映像表示部３３は、映像データ受信部３２により受信された複数の映像データをそのまま全て表示するというわけではなく、複数の映像データのうち、ユーザにより選択された映像データのみを表示する。

リソース計測部３４は、映像データ受信部３２で受信されたテスト用映像データに関する映像を映像表示部３３にて再生する場合の消費リソースを計測する。

図３は実施の形態１に係る消費リソースの例を示す図である。図３に示すように、例えばプロファイルＩＤ「１」を用いてエンコードされたテスト用映像データに基づく映像を映像表示部３３にて表示する際の消費リソースは、メモリ（ＭＢ）が６００、ＣＰＵ（％）が１４、ＧＰＵ（％）が２０であることがわかる。

リソース情報記憶部３５には、リソース計測部３４にて計測対象となったテスト用映像データのプロファイルと、計測された消費リソースとが対応付けてリソース情報として記憶される。リソース情報の詳細な説明については後述する。

ＵＩ制御部３６は、ＧＵＩ（ＧｒａｐｈｉｃａｌＵｓｅｒＩｎｔｅｒｆａｃｅ）制御を行い、ユーザ操作を認識する。

プロファイル選択部３７は、映像データ送信部１４から送信された複数の映像データを映像データ受信部３２が受信した場合に、リソース情報記憶部３５に記憶されるリソース情報に基づき、映像表示部３３に表示するための映像データのプロファイルを選択する。言い換えると、プロファイル選択部３７は、受信された複数の映像データのうち、選択されたプロファイルの映像データを映像表示部３３に表示させる映像データ選択部として機能するとも言える。

次に、実施の形態１の動作について説明する。まずは、映像表示装置３におけるリソース情報の設定処理について説明する。図４は実施の形態１に係るリソース情報の設定処理についての動作例を示すフローチャートである。

まず、映像送信装置１のテスト用映像データ送信部１３が、映像データ記憶部１２に記憶されるテスト用映像データ及びそのテスト用映像データのプロファイル情報を、ネットワーク処理部１１を介して映像表示装置３に送信する（ステップＳ１）。

図５は実施の形態１に係るプロファイルの他の例を示す図である。ここでは、テスト用映像ソースに対し、図５に示す異なる２種類のプロファイル（プロファイルＩＤ「１」、「２」）を用いてエンコードしたテスト用映像データを送信する場合を例に説明する。なお、以下の説明では、プロファイルＩＤ「１」を第１のプロファイル、プロファイルＩＤ「２」を第２のプロファイルと呼称してもよい。テスト用映像データ送信部１３は、まずプロファイルＩＤ「１」でエンコードした１個のテスト用映像データと、プロファイルＩＤ「１」に関するプロファイル情報とを映像表示装置３に送信する。

映像送信装置１は、プロファイル情報記憶部１５にプロファイルＩＤ「１」に関するプロファイル情報を記憶する（ステップＳ２）。

映像表示装置３の映像データ受信部３２は、映像送信装置１からネットワーク２、ネットワーク処理部３１を介して受信したテスト用映像データを受信し、リソース計測部３４が、受信したテスト用映像データを映像表示部３３に表示する際に消費するリソースを計測する（ステップＳ３）。

ここでは、プロファイルＩＤ「１」のテスト用映像データを映像表示部３３に表示すると、図３に示すリソースを消費することとなる。

次に、映像表示装置３は、映像表示部３３にて表示したテスト用映像データの消費リソースと、そのテスト用映像データのプロファイル情報（プロファイルＩＤ「１」）とを対応付けてリソース情報としてリソース情報記憶部３５に記憶する（ステップＳ４）。

図６は実施の形態１に係るリソース情報の例を示す図である。図６に示すように、リソース情報は、表示したテスト用映像データのプロファイル情報と、表示したテスト用映像データの消費リソースとがそれぞれテーブル形式（プロファイルテーブル及びリソーステーブル）で対応付けられているが、必ずしもこの形式に限定されない。

映像送信装置１が映像表示装置３に対してテスト用映像データを所定回数送信した場合（ステップＳ５−Ｙｅｓ）、ステップＳ６に移る。一方で、テスト用映像データを所定回数送信していない場合（ステップＳ５−Ｎｏ）、ステップＳ１からステップＳ４までの処理を繰り返す。なお、所定回数については任意に定めてよいものとする。

ここでは、所定回数を１０回とすると、プロファイルＩＤ「１」のテスト用映像データは１回しか送信していないので、ステップＳ１の処理に戻る。ステップＳ１では、テスト用映像データ送信部１３は、前サイクルで送信したプロファイルＩＤ「１」のテスト用映像データと同一のデータ及びプロファイル情報を、再び映像表示装置３に送信する。

その後のステップＳ３では、リソース計測部３４は、プロファイルＩＤ「１」のテスト用映像データを２個同時に映像表示部３３に表示させた場合の消費リソースを計測する。

そして、ステップＳ４では、テスト用映像データを２個同時に表示させた場合の消費リソースをリソース情報に追記し、リソース情報を更新する。この一連の処理を、所定回数１０回になるまで行う。

図７は実施の形態１に係る複数のテスト用映像データを表示させた場合のリソース情報の例を示す図である。図７に示すリソース情報は、プロファイルＩＤ「１」のテスト用映像データを２〜１０個同時に表示させた場合の消費リソースの情報が、図６からさらに追記されている。例えば、プロファイルＩＤ「１」のテスト用映像データを同時に３個表示する場合は、消費リソースはメモリ（ＭＢ）６４５、ＣＰＵ（％）２８、ＧＰＵ（％）４４となる。また、図７のリソース情報には、テスト用映像データを表示しない場合の消費リソースについての情報も追記されている。このようなテスト用映像データを表示しない場合の消費リソースの情報は、予め算出して記憶しておいてもよいし、ステップＳ１〜Ｓ５の途中で算出して記憶するようにしてもよい。

なお、これまで、テスト用映像データ送信部１３はテスト用映像データを１個ずつ送信する構成について説明してきたが、必ずしもこれに限定されず、複数個のテスト用映像データを同時に送信するようにしてもよい。その場合は、映像表示装置３側で、複数個のテスト用映像データを同時に受信して表示させた場合の消費リソースを計測することになる。

ステップＳ６に進んで、映像送信装置１が映像表示装置３に対して全てのプロファイルのテスト用映像データを送信した場合（ステップＳ６−Ｙｅｓ）、映像表示装置３における設定処理が終了する。一方、全てのプロファイルテスト用映像データを送信していない場合は（ステップＳ６−Ｎｏ）、ステップＳ１からＳ５までの処理を再度繰り返す。

ここでは、映像送信装置１は、プロファイルＩＤ「２」のテスト用映像データを映像表示装置３に送信していないので、ステップＳ１の処理に戻り、テスト用映像データ送信部１３は、映像表示装置３に対しプロファイルＩＤ「２」のテスト用映像データを送信する。プロファイルＩＤ「２」のテスト用映像データについても、プロファイルＩＤ「１」のテスト用映像データと同様にステップＳ１からステップＳ５までの処理が繰り返され、リソース情報にプロファイルＩＤ「２」のテスト用映像データを表示する際の消費リソースの情報が追記される。

図８は、実施の形態１に係る異なるプロファイルのテスト用映像データを表示させた場合のリソース情報の例を示す図である。図８に示すリソース情報は、プロファイルＩＤ「２」のテスト用映像データを１個表示させた場合、１個も表示させない場合、また２〜１０個を同時に表示させた場合の消費リソースの情報がそれぞれ、図７からさらに追記されている。つまり、リソース情報には、プロファイルＩＤ「１」のテスト用映像データを１または複数表示した場合の消費リソースについての情報が含まれるとともに、プロファイルＩＤ「２」のテスト用映像データを１または複数表示した場合の消費リソースについての情報が含まれる。なお、プロファイルＩＤ「１」のテスト用映像データを１または複数表示する場合の消費リソースを第１の消費リソース、プロファイルＩＤ「２」のテスト用映像データを１または複数表示する場合の消費リソースを第２の消費リソースと呼称してもよい。

次に、映像表示装置３が映像送信装置１から映像データを受信した場合の、プロファイル選択処理について説明する。図９は、実施の形態１に係るプロファイル選択処理についての動作例を示すフローチャートである。

まず、映像データ送信部１４が、映像表示装置３に対して、映像データ記憶部１２に記憶される複数の映像データを送信する（ステップＳ０１）。

映像データ送信部１４から送信される映像データ、言い換えると映像データ記憶部１２に記憶される映像データは、複数の映像ソースがそれぞれ異なるプロファイルでエンコードされた映像データであり、エンコードに用いられるプロファイルは、図４で説明した設定処理の動作においてプロファイル情報記憶部１５に記憶されたプロファイルが該当する。そのため、例えば映像ソースが１０個で、かつ、映像データのプロファイルが図５の例で示すプロファイルＩＤ「１」、「２」の２つの場合、映像データの個数としては２０個となる。つまり、各映像ソースについて２つの異なるプロファイルでエンコードされた映像データが存在するので１０×２で２０個となり、これら２０個の映像データがマルチキャスト送信される。

図１０は実施の形態１に係る映像ソースの例を示す図である。図１０の例では映像ソースは１０個あり、それぞれの映像ソースに対し映像ＩＤ、名称、形式、アドレス等の項目が設けられている。なお、アドレスは、形式が「ライブ」の場合は映像ソースのＩＰアドレスが該当し、形式が「記録」の場合は映像ファイルのパスが該当する。

また、映像データ送信部１４は、映像データに加え、送信される映像データの受信アドレスを示した受信パラメータを映像表示装置３に送信する。

図１１は実施の形態１に係る受信パラメータの例を示す図である。図１０に示す１０個の映像ソースに対してプロファイルＩＤ「１」、「２」でエンコードされた映像データであるので、上記したように合計２０個の映像データの受信アドレスの情報が含まれる。

映像表示装置３の映像データ受信部３２は、映像送信装置１から送信された２０個の映像データを受信する（ステップＳ０２）。

映像データ受信部３２にて映像データを受信すると、プロファイル選択部３７は、リソース情報記憶部３５に記憶されたリソース情報と、設定された消費リソースの閾値に関する情報とから、受信条件を設定する（ステップＳ０３）。

図１２は実施の形態１に係る受信条件の例を示す図である。受信条件は、リソース情報に含まれるプロファイルテーブル及びリソーステーブルと、閾値テーブルから構成される。図１２の例では、図８で説明したプロファイルテーブルに、さらに単位メモリ（ＭＢ）、単位ＣＰＵ（％）、単位ＧＰＵ（％）の項目が付加されている。これらの項目は所定のプロファイルの映像データを１個新たに表示する際の平均の消費リソースを意味する。例えば、プロファイルＩＤ「１」の映像データを新たに１個追加で表示する場合は、消費リソースは、メモリが２．３ＭＢ、ＣＰＵが５．７％、ＧＰＵが７％となる。つまり、受信条件におけるリソース情報には、プロファイルＩＤ「１」のテスト用映像データに基づく映像とプロファイルＩＤ「２」のテスト用映像データに基づく映像とを同時に表示した場合の消費リソースについての情報が含まれる。

閾値テーブルについては、予め映像表示装置３内で設定されていてもよいし、プロファイル選択部３７が動的に設定するようにしてもよい。図１２の例では、同時に受信できる映像数は１０、メモリ閾値（ＭＢ）は１０００、ＣＰＵ閾値（％）は５０、ＧＰＵ閾値（％）は８０となる。

図９に戻って、ＵＩ制御部３６がユーザ操作を検知すると（ステップＳ０４−Ｙｅｓ）、プロファイル選択部３７は、受信条件に基づいて選択された映像データのプロファイルを選択する（ステップＳ０５）。

図１３は実施の形態１においてユーザに選択された映像の表示を説明するための図である。映像データ受信部３２により映像データを受信された段階においては、図１３（Ａ）に示すように、映像は表示されていない。

ここで、ステップＳ０４において、ユーザがプロファイルＩＤ「１」、映像ＩＤ「１」の映像データを選択すると、プロファイル選択部３７は、図１２の受信条件に基づき、図１１の受信パラメータに示す映像ＩＤ「１」のプロファイルとしてプロファイルＩＤ「１」を選択し、その受信アドレス「２２４．２．０．１：４７０００」を検索する。

つまり、プロファイル選択部３７は、受信条件におけるリソース情報に基づいて、１つの映像データ（ＩＤ「１」）を表示する場合の消費リソース（メモリ６００ＭＢ、ＣＰＵ１４％、ＧＰＵ１０％）は閾値（メモリ閾値１０００ＭＢ、ＣＰＵ閾値５０％、ＧＰＵ閾値８０％）以下であると判断し、プロファイルＩＤ「１」を選択する。

図９に戻って、映像表示部３３には映像ＩＤ「１」の映像以外は表示されていないので、ステップＳ０６における処理は「Ｎｏ」となり、映像ＩＤ「１」の映像が映像表示部３３に表示される（ステップＳ０８）。そうすると、図１３（Ｂ）に示すように、映像ＩＤ「１」、プロファイルＩＤ「１」の映像Ａが映像表示装置３の映像表示部３３にて表示される。

さらにユーザ操作があると（ステップＳ０９−Ｙｅｓ）、ステップＳ０５以降の処理を繰り返す。

ここで、ユーザがプロファイルＩＤ「１」、映像ＩＤ「２」の映像データを新たに選択すると、プロファイル選択部３７は、リソース情報から、プロファイルＩＤ「１」の映像データを２個同時に表示した場合の消費リソース（メモリ６２０ＭＢ、ＣＰＵ２５％、ＧＰＵ２０％）の情報を読み取り、閾値未満であると判定する。そして、プロファイル選択部３７は、映像ＩＤ「２」の受信アドレス「２２４．１．０．２：４７０１０」を検索し、映像表示部３３に表示させる。

プロファイル選択部３７は、上記したように、プロファイル「１」の映像データを２個同時に表示しても消費リソースが閾値未満であると判断するので、ステップＳ０６の処理は「Ｎｏ」となり、映像ＩＤ「１」の映像データのプロファイルは変更されない。そして、図１３（Ｃ）に示すように、映像ＩＤ「１」、プロファイルＩＤ「１」の映像Ａと、映像ＩＤ「２」、プロファイルＩＤ「１」の映像Ｂとが、映像表示装置３の映像表示部３３にて表示される。

こういった処理を繰り返し、ユーザによりプロファイルＩＤ「１」の映像データが６個表示されている場合について説明する。６個の映像データの映像ＩＤはそれぞれ「１」、「２」、「３」、「４」、「５」、「６」であるとする。図９のステップＳ０９において、ユーザが新たに７個目の映像データ（映像ＩＤ「７」）を選択すると、プロファイル選択部３７は、受信条件におけるリソース情報から、プロファイルＩＤ「１」の映像データを７個同時に表示した場合の消費リソースを読み取る。その場合、図１２に示すように、ＣＰＵの消費リソースは５０％となり、閾値以上となってしまう。

次に、プロファイル選択部３７は、受信条件におけるリソース情報から、プロファイルＩＤ「１」の映像データ６個とプロファイルＩＤ「２」の映像データ１個とを同時に表示した場合の消費リソースを読み取る。その場合、図１２に示すように、ＣＰＵの消費リソースは、５０．４（４７＋３．４）％となり、これでも閾値以上となってしまう。

そのため、プロファイル選択部３７は、他の映像データのプロファイルの変更が必要と判断し（ステップＳ０６−Ｙｅｓ）、ステップ０７の処理に移り、既にプロファイルＩＤ「１」で表示している６個の映像データのプロファイルの変更を行う。プロファイル選択部３７は、受信条件におけるリソース情報から、プロファイルＩＤ「１」の映像データ５個と、プロファイルＩＤ「２」の映像データ２個とを同時に表示した場合の消費リソースを読み取る。その場合、図１２に示すように、メモリが７０１．６（６８２＋９．８×２）ＭＢ、ＣＰＵが４６．８（４０＋３．４×２）％、ＧＰＵが６１（５０＋５．５×２）となり、いずれも閾値未満となるので、プロファイル選択部３７は、既に表示されている６個の映像データと、新たに選択された１個の映像データについて、プロファイルＩＤ「１」が５個、プロファイルＩＤ「２」が２個となるようにプロファイルを変更する。

ここで、既に表示されている６個のプロファイルＩＤ「１」の映像データのうち、プロファイルＩＤを「１」から「２」へ変更する映像データの決定方法について説明する。プロファイルＩＤが「１」から「２」へ変更されると、図５に示されるようにｆｐｓが下がるので、通常ユーザにとって優先度の低い映像データのプロファイルが「１」から「２」に変更されることになる。

例えば、プロファイル選択部３７は、ユーザの操作中の映像データのプロファイルＩＤは変更せず、以下（Ａ）から（Ｄ）のいずれかの規則に従ってプロファイルＩＤを変更する映像データを決定すればよい。（Ａ）ユーザの操作履歴を取得し、最も操作されていない映像データから順に変更する、（Ｂ）表示サイズが小さい映像データから順に変更する、（Ｃ）映像データの表示ウィンドウの並び順（オーダ）が低い映像データから順に変更する、（Ｄ）表示位置が画面中央から最も遠い映像データから順に変更する。なお、表示ウィンドウの表示サイズ、表示ウィンドウの並び順、映像の表示位置等の情報については、映像表示部３３により取得され、プロファイル選択部３７に通知される。

次に、プロファイルＩＤ「１」の映像データが５個、プロファイルＩＤ「２」の映像データが２個表示されている場合において、ユーザ操作により１個の映像データに関する表示ウィンドウが閉じられた場合の処理について説明する。

ユーザにより表示ウィンドウが閉じられたことをＵＩ制御部３６が検知してプロファイル選択部３７に通知すると、プロファイル選択部３７は、図１２に示す受信条件におけるリソース情報から、プロファイルＩＤ「１」の映像データが６個同時に表示された場合の消費リソースは、メモリ７１０ＭＢ、ＣＰＵ４７％、ＧＰＵ５５％であり、これらはいずれも閾値未満であることを読み取る。そして、プロファイル選択部３７は、プロファイルＩＤ「２」で表示されている映像データについて、プロファイルＩＤを「１」に変更する。結果として、映像表示部３３には、プロファイルＩＤ「１」の映像データに関する映像が６個同時に表示されることとなる。

以上のように、本発明の実施の形態１によれば、映像表示装置３が、受信した各プロファイルのテスト用映像データを１つまたは複数同時に表示した場合の消費リソースをリソース計測部３４で計測し、計測された消費リソースとプロファイルとがそれぞれ対応付けられたリソース情報に基づいて、プロファイル選択部３７は表示する映像データのプロファイルを選択するので、映像を表示させるまでの処理遅延を防止することができる。

つまり、映像送信装置１が、映像表示装置３の消費リソースについての情報を取得し、当該情報に基づいて送信する映像データのプロファイルを設定する必要がなく、映像表示装置３側で受信した映像データのプロファイルを選択して映像を表示するので、映像送信装置１側におけるプロファイル設定のための処理を省くことができ、処理遅延が防止される。

なお、これまで、表示する映像数が増減する場合の例については、ユーザにより新たな映像データが選択される場合、または、ユーザにより映像データの表示ウィンドウが閉じられた場合が該当するとして説明をしたが、これに限らない。例えば、映像送信装置１に複数の映像表示装置３がネットワーク２を介して接続される映像表示システムの構成である場合、以下で説明するようなユーザ処理により表示する映像の増減が生じる。このような映像表示システムにおいては、映像は、各映像表示装置３の画面を跨って表示されることが可能となる。

図１４は実施の形態１に係る表示映像数の増減を説明するための図である。図１４の例では、映像は、映像表示装置３Ａ、３Ｂ、３Ｃ、３Ｄに跨っての表示が可能である。ユーザ操作前では、映像表示装置３ＡではプロファイルＩＤ「１」の映像Ａが表示され、映像表示装置３ＢではプロファイルＩＤ「１」の映像Ｂが表示されている。

ここで、ユーザが映像Ａを拡大する操作を行うと、映像表示装置３Ｂ、３Ｃ、３Ｄでは新たにプロファイルＩＤ「１」の映像Ａが１個表示されるので、表示映像数が１増加する。この際、映像表示装置３Ｂは、必要があれば、図９のステップＳ０５〜０７にて説明したように、映像Ｂのプロファイルを変更する。なお、図１４には図示しないが、ユーザが映像Ａをドラッグして映像表示装置３Ｂに移動させたような場合は、映像表示装置３Ａは表示映像数が１減少し、映像表示装置３Ｂは表示映像数が１増加する。なお、映像表示装置３Ｃ、３Ｄの映像表示数は増減しない。

実施の形態２．
以下図面を用いて本発明の実施の形態２について説明する。実施の形態１では、テスト用映像データを表示する際に計測した消費リソースを予測値として記憶し、受信した映像データのプロファイル選択に用いていたが、実施の形態２では、映像表示装置３が消費するリソースの実測値を測定し、当該実測値が閾値以上であった場合はプロファイルの変更処理を行う。

図１５は実施の形態２に係る映像表示システムの構成例を示す図である。実施の形態２の映像表示システムを構成する映像表示装置３０は、実施の形態１の映像表示装置３の構成に加えて、新たにリソース実測値監視部３８を備えている点において実施の形態１と異なる。実施の形態２に係る映像表示装置３０における他の構成については実施の形態１と同じであるので、図１と同一符号を付してその説明を省略する。

リソース実測値監視部３８は、映像表示装置３０が映像を表示する際の消費リソースの実測値を常時監視（計測）し、その値をプロファイル選択部３７に通知する。

次に、実施の形態１におけるプロファイル選択処理について説明する。図１６は実施の形態２に係るプロファイル選択処理についての動作例を示すフローチャートである。なお、リソース情報の設定処理の動作については実施の形態１と同様であるためその説明を省略する。

図１６において、ステップＳ００１からステップＳ００９は、実施の形態１の図９で説明したステップＳ０１からステップＳ０９と同じであるため、説明を省略する。ここで、実施の形態１と同様に、６個のプロファイルＩＤ「１」の映像データが表示されており、ユーザにより新たに７個目の映像データ（プロファイルＩＤ「１」）が選択された場合について説明する。

ユーザが新たに７個目の映像データを選択すると、プロファイル選択部３７は、受信条件におけるリソース情報から、プロファイルＩＤ「１」の映像データを７個同時に表示した場合の消費リソースを読み取る。その場合、図１２に示すように、ＣＰＵの消費リソースは５０％で閾値以上となってしまうので、プロファイルＩＤ「１」が５個、プロファイルＩＤ「２」が２個となるように映像データのプロファイルを変更する。このときの消費リソースは、図１２から、メモリ７０１．６（６８２＋９．８×２）ＭＢ、ＣＰＵ４６．８（４０＋３．４×２）％、ＧＰＵ６１（５０＋５．５×２）となり、いずれも閾値未満である。

しかしながら、これらの値は推定値であるので、環境要因が変化すると、必ずしもその通りの値でない場合がある。環境要因が変化する例としては、例えば、テスト用映像データを送信し消費リソースを計測してリソース情報の設定処理が完了した後、新たにアプリケーションが追加でインストールされていた場合が該当し、この場合、リソース情報に基づく消費リソースと、消費リソースの実測値とが必ずしも一致しない。また、消費リソースのうちＣＰＵは時刻変動が激しいため、消費リソースの推定値が閾値未満でも、消費リソースの実測値としては瞬間的に閾値を超える場合がある。

リソース実測値監視部３８は、計測している消費リソースの実測値をプロファイル選択部３７に通知する。プロファイル選択部３７は、通知された消費リソース実測値が図１２に示す閾値以上であるか否かを判定し、閾値以上でなければ（ステップＳ００１０−Ｎｏ）、選択したプロファイルのまま表示を続けるようにする。つまり、プロファイルＩＤ「１」の映像が５個と、プロファイルＩＤ「２」の映像２個とを同時に表示したままにする。

プロファイル選択部３７は、通知された消費リソース実測値が図１２に示す閾値以上である場合（ステップＳ００１０−Ｙｅｓ）、消費リソース実測値が閾値未満となるよう、表示している映像のプロファイルを変更する。例えば、プロファイル選択部３７は、プロファイルＩＤ「１」の映像４個と、プロファイルＩＤ「２」の映像３個とを同時に表示するようにすればよい。ここで新たにプロファイルＩＤ「１」から「２」に変更される映像データの決定方法については、実施の形態１で説明した方法を用いればよい。

以上のように、本発明の実施の形態２によれば、リソース実測値監視部３８が消費リソースの実測値を計測し、プロファイル選択部３７は、リソース情報に基づく消費リソースが閾値未満であっても、消費リソースの実測値が閾値以上の場合は表示している映像のプロファイルを変更して消費リソースの実測値が閾値未満となるようにするので、環境要因による消費リソースの変動の影響を受けることなく処理遅延を防止することができる。

また、テスト用映像データによるリソース情報の設定処理が終了した後に環境が変化した場合、例えば新たにアプリケーションをインストールしたような場合であっても、変化後の環境において再度リソース情報の設定処理を行う必要がないので、映像表示システムの管理者にとっての運用負担を軽減することが可能となる。

１映像送信装置、２ネットワーク、３、３０映像表示装置、１１ネットワーク処理部、１２映像データ記憶部、１３テスト用映像データ送信部、１４映像データ送信部、１５プロファイル情報記憶部、３１ネットワーク処理部、３２映像データ受信部、３３映像表示部、３４リソース計測部、３５リソース情報記憶部、３６ＵＩ制御部、３７プロファイル選択部、３８リソース実測値監視部

Claims

映像データを送信する映像送信装置と、前記映像送信装置と接続され前記映像送信装置からの前記映像データを受信して表示する映像表示装置とを備える映像表示システムであって、
前記映像送信装置は、
第１のプロファイルのテスト用映像データと第２のプロファイルのテスト用映像データとを送信するテスト用映像データ送信部と、
前記映像データを、前記第１のプロファイルと前記第２のプロファイルでエンコードして、それぞれ送信する映像データ送信部と、を備え、
前記映像表示装置は、
前記第１のプロファイルのテスト用映像データと前記第２のプロファイルのテスト用映像データと、前記第１のプロファイルの映像データと前記第２のプロファイルの映像データとを受信する映像データ受信部と、
前記映像データ受信部で受信された前記第１のプロファイルのテスト用映像データに基づく映像を表示する場合の第１の消費リソースと、前記第２のプロファイルのテスト用映像データに基づく映像を表示する場合の第２の消費リソースとを計測するリソース計測部と、
前記リソース計測部で計測された前記第１の消費リソースと前記第１のプロファイルとが対応付けられるとともに、前記第２の消費リソースと前記第２のプロファイルとが対応付けられたリソース情報を記憶するリソース情報記憶部と、
前記映像データ受信部で受信した前記映像データのプロファイルを、前記リソース情報に基づき、前記第１のプロファイルまたは前記第２のプロファイルのいずれかに選択するプロファイル選択部と、を備えたことを特徴とする映像表示システム。
前記リソース情報には、前記第１のプロファイルのテスト用映像データに基づく映像を複数同時に表示した場合の消費リソースについての情報が含まれるとともに、前記第２のプロファイルのテスト用映像データに基づく映像を複数同時に表示した場合の消費リソースについての情報が含まれることを特徴とする請求項１に記載の映像表示システム。
前記リソース情報には、前記第１のプロファイルのテスト用映像データに基づく映像と前記第２のプロファイルのテスト用映像データに基づく映像とを同時に表示した場合の消費リソースについての情報が含まれることを特徴とする請求項１または２に記載の映像表示システム。
前記プロファイル選択部は、前記リソース情報に基づき、表示中の映像に基づく消費リソースと、前記映像データ受信部で受信した前記映像データに基づく映像を表示する場合の消費リソースとの合計が、設定された消費リソースの閾値未満となるように前記受信した映像データの前記プロファイルを選択することを特徴とする請求項１乃至３のいずれかに記載の映像表示システム。
前記プロファイル選択部は、前記消費リソースの合計が前記閾値未満となるように前記表示中の映像に関する映像データのプロファイルを変更することを特徴とする請求項４に記載の映像表示システム。
前記プロファイル選択部は、前記表示中の映像が複数ある場合に、優先度に応じて前記プロファイルを変更する前記表示中の映像に関する映像データを決定することを特徴とする請求項５に記載の映像表示システム。
前記プロファイル選択部は、前記表示中の映像に基づく前記消費リソースの実測値と前期受信した映像データに基づく映像を表示する場合の前記消費リソースの実測値との合計が前記閾値以上となる場合に、前記表示中の映像に関する映像データの前記プロファイル又は前記受信した映像データの前記プロファイルのうち少なくともいずれか一方を変更することを特徴とする請求項４乃至６のいずれかに記載の映像表示システム。
映像送信装置から送信された第１のプロファイルのテスト用映像データと第２のプロファイルのテスト用映像データと、前記第１のプロファイルの映像データと前記第２のプロファイルの映像データと、を受信する映像データ受信部と、
前記映像データ受信部で受信された前記第１のプロファイルのテスト用映像データに基づく映像を表示する場合の第１の消費リソースと、前記第２のプロファイルのテスト用映像データに基づく映像を表示する場合の第２の消費リソースとを計測するリソース計測部と、
前記リソース計測部で計測された前記第１の消費リソースと前記第１のプロファイルとが対応付けられるとともに、前記第２の消費リソースと前記第２のプロファイルとが対応付けられたリソース情報を記憶するリソース情報記憶部と、
前記映像データ受信部で受信した映像データのプロファイルを、前記リソース情報に基づき、前記第１のプロファイルまたは前記第２のプロファイルのいずれかに選択するプロファイル選択部と、を備えたことを特徴とする映像表示装置。