JP3775455B2 - 会議端末装置および会議関連情報の送信方法 - Google Patents
会議端末装置および会議関連情報の送信方法 Download PDFInfo
- Publication number
- JP3775455B2 JP3775455B2 JP34256697A JP34256697A JP3775455B2 JP 3775455 B2 JP3775455 B2 JP 3775455B2 JP 34256697 A JP34256697 A JP 34256697A JP 34256697 A JP34256697 A JP 34256697A JP 3775455 B2 JP3775455 B2 JP 3775455B2
- Authority
- JP
- Japan
- Prior art keywords
- information
- priority
- conference
- terminal
- priority condition
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Telephonic Communication Services (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、パーソナルコンピュータやワークステーションなどを用いて行う多地点マルチメディア会議システムに適用可能な会議端末装置および音声、映像等の会議関連情報の送信方法に関する。
【０００２】
【従来の技術】
近年、映像や音声などの会議関連情報（以下、映像、音声などの情報をマルチメディアデータという）を、ネットワークを介して伝達することで遠隔多地点間コミュニケーションを行う、いわゆる多地点マルチメディア会議システムが利用されるようになってきている。
【０００３】
図１９は、従来の多地点マルチメディア会議システムの一例の概要を示すものである。図１９において、１ａ〜１ｄは、多地点間マルチメディア会議システムに参加している会議端末装置であり、これら会議端末装置１ａ〜１ｄのそれぞれは、互いに離れた遠隔地であるＡ地点、Ｂ地点、Ｃ地点、Ｄ地点に設置されているが、ネットワーク２を通じて互いに接続されている。そして、ネットワーク２には、さらに、多地点間制御装置（以下ＭＣＵという）３が接続されている。
【０００４】
この図１９の多地点間マルチメディア会議システムにおいては、通常、各会議端末装置１ａ〜１ｄは、カメラで撮像した映像や予め用意した資料映像などの情報と、自分が発言しているときにはその音声を、ネットワーク２を通じてＭＣＵ３に向けて送出する。ＭＣＵ３は、これらの映像や音声などのマルチメディアデータを集め、それらのデータを合成して、ネットワーク２を通じて各会議端末装置１ａ〜１ｄへ配信するようにする。
【０００５】
この場合、ＭＣＵ３は、各会議端末装置１ａ〜１ｄからの映像情報については、それぞれを区分けして、各会議端末装置１ａ〜１ｄのそれぞれにおいて、いずれの端末からの映像情報であるかが分かるように合成する。すなわち、例えば、図２０に示すように、ある会議端末装置のディスプレイ４の画面には、会議に参加している会議端末装置の数の分割画面５ａ〜５ｄからなる映像ウインドウ５が表示されるように、ＭＣＵ３で映像情報の合成がなされる。
【０００６】
ところで、一般的には会議で同時に複数の人間が発言をすることはなく、各会議参加者は、一人の話者（発言者）の映像か、もしくは、話者の提供する映像に注目する。したがって、少なくとも、話者の映像か、もしくは、話者の提供する映像だけは高品質で表示されることが望ましい。なぜなら、話者の表情や唇の動き、もしくは、話者が提供する映像は、話を聞く側の理解を深める手助けをするからである。
【０００７】
しかし、前述したＭＣＵ３を用いて行う多地点マルチメディア会議システムでは、ＭＣＵ３は、各会議端末装置１ａ〜１ｄからの映像情報を均等に取り扱って、前記の分割画像合成の映像ウインドウ５を生成するようにするため、注目したい端末からの映像だけ優先して画質を上げるということはできない。
【０００８】
また、ある会議端末装置からのデータがＭＣＵ３へ到着するのが遅れると、ＭＣＵ３は遅れているデータの到着を待つことになり、他端末すべての映像表示に悪影響を及ぼす。データの到着が遅れている会議端末装置については、その映像品質を低下させて表示してしまうということも可能だが、そのようにすると、当該データの到着が遅れている端末を使用して会議に参加している人が話者である場合には、低品質の画像を見ながら会議を進行させなければならず、会議が非常にしにくくなる。
【０００９】
さらに、現段階でＭＣＵ３は非常に高価であり、できればＭＣＵ３を用いずに多地点マルチメディア会議を行えることが理想である。このＭＣＵ３を用いないという要求を満足するものとして、図２１に示すように、多地点へのマルチメディアデータ配信に、マルチキャストを利用するというアプローチがある。
【００１０】
このマルチキャストを利用するシステムの場合には、会議に参加している会議端末装置１ａ〜１ｅが、それぞれマルチキャストで互いにデータを発信する。そして、会議端末装置１ａ〜１ｅのそれぞれは、会議に参加している他の会議端末装置の数のマルチメディアデータを受信して、その受信データのそれぞれを自端末で処理する。そして、図２２に示すように、会議に参加している他の端末からの映像は、個々に独立して表示するようにする。
【００１１】
図２２は、図２１においてＥ地点の会議端末装置１ｅのディスプレイ４の表示画面を示すもので、６ａ〜６ｄは図２１のＡ地点〜Ｄ地点の端末１ａ〜１ｄより送信される映像情報の復元画像を表示するための独立した映像ウインドウである。
【００１２】
しかし、このマルチキャストを利用するシステムの場合の個々の会議端末装置は、映像のようにデータ量の大きい情報を会議に参加している端末全てについて処理するようにするために、計算機の能力が不足し、たとえ専用のハードウェアを用いても、すべての端末からの映像をスムーズに表示することは非常に困難である。特にマルチメディア会議に参加する端末の数が増えれば、それは一層難しくなる。
【００１３】
送信される映像分の復号器を、各会議端末装置に用意することも考えられるが、これはコスト的にも、ハードウェア規模的にも不利であり、非現実的である。
【００１４】
上記の問題点を解決するための一つの手段として、例えば特開平８−１６３５５６号公報には、受信側端末（ネットワークに接続された複数の会議端末装置のうちの会議関連情報を受信する会議端末装置、以下同じ）にフレームレート変換部を設け、ユーザが受信側端末の計算機処理能力に応じて複数の映像のフレームレートを設定し、注目する必要のない映像のフレームレートを下げるようにすることが提案されている。これによれば、映像を表示する際の計算機パワーの無駄を防止することができるとともに、注目する映像の品質の劣化を防止することができる。
【００１５】
また、例えば特開平９−７４５４８号公報にも、上記の問題点を解決する手段が示されている。すなわち、この特開平９−７４５４８号公報に記載されているシステムにおいては、受信側端末に送信された映像フレームの内、いくつが有効であるかを測定し、その結果を送信側端末（ネットワークに接続された複数の会議端末装置のうちの会議関連情報を送信する、あるいは送信した会議端末装置、以下同じ）に伝達する。送信側端末は、その情報に応じて伝送する動画像のフレームレートを制御する。以上の構成により、受信側端末が常に計算処理能力の範囲で動画像データを処理することができるようにしている。
【００１６】
【発明が解決しようとする課題】
しかしながら、上述の公報に記載の従来技術には次のような課題があった。
【００１７】
すなわち、特開平８−１６３５５６号公報の発明の場合、フレームレートは、受信側端末において、その度毎に、ユーザが自分で操作して設定しなくてはならず、非常に面倒であるという問題がある。例えば、話者が変わるたびに、その話者の端末からのフレームレートを上げるように設定し直していたのでは、とてもわずらわしくて会議に集中することはできない。
【００１８】
また、特開平９−７４５４８号公報の例では、複数の受信側端末の間で処理の能力が異なる場合に、送信側端末がその個々に対応することが難しい。また、一般的に注目したい映像は話者の映像か、もしくは話者の提供する特別な映像であり、その映像が明確に見えないと会議がスムーズに進行せず、会議参加者のストレスとなる。ところが、特開平９−７４５４８号公報の例では、必ずしも受信側端末がその特定の映像を選択的に優先させて高品質で表示するということはできないという問題がある。
【００１９】
この発明は、以上の点にかんがみ、計算機能力が低くて多量の映像データを処理しきれない場合でも、会議中にユーザが特別に意識して操作することなく、常に優先するべき情報を優先的に処理することができるようにした、多地点マルチメディア会議用の会議端末装置を提供することを目的とする。
【００２０】
【課題を解決するための手段】
以上の課題を解決するために、請求項１の発明による会議端末装置は、
ネットワークに接続され、このネットワークを通じて、音声、映像等の会議関連情報を送信するとともに、他の複数個の会議端末装置からの送信信号を前記ネットワークを通じて受信する会議端末装置であって、
会議関連情報の入力を受ける入力部と、
前記会議関連情報に関して、受信側端末で処理を優先させるようにするための優先条件を、ユーザーによる指示を受けて予め設定する優先条件設定手段と、
前記優先条件設定手段で設定された前記優先条件に対応する優先条件情報を、自端末の端末識別子を付加して予め前記ネットワークを通じて他の全ての会議端末装置に送信する手段と、
前記入力部からの会議関連情報について、前記優先条件設定手段で設定された前記優先条件に合致しているか否かを確認する優先条件確認手段と、
前記入力部からの会議関連情報を前記ネットワークに送出する信号に変換する処理を行うとともに、前記優先条件確認手段での確認結果が前記会議関連情報が前記優先条件に合致しているときに、前記ネットワークに送出する信号に、前記優先条件情報と、前記自端末の端末識別子とを付加して、送信信号を生成する情報処理手段と、
前記情報処理手段からの送信信号を前記ネットワークを通じて受信側端末に対して送信するデータ送信手段と、
前記ネットワークを通じて送信されてきた他の会議端末装置からの送信信号を受信するデータ受信手段と、
前記データ受信手段で受信した前記送信信号中に含まれる前記端末識別子を認識して、前記受信したデータを、前記端末識別子に対応した前記他の会議端末装置ごとのバッファメモリに区分けして蓄積するバッファ手段と、
前記バッファ手段に蓄積された受信データの復号化処理を行う復号化手段と、
前記ネットワークを通じて予め送られてくる前記優先条件情報を、前記他の会議端末装置の端末識別子とともに、予め、蓄積する優先条件蓄積手段と、
前記データ受信手段で受信した前記送信信号に含まれる前記優先条件情報と、前記優先条件蓄積手段に蓄積されている優先条件情報のうちの、前記送信信号に含まれる前記端末識別子で識別される前記他の会議端末装置に関する前記優先条件情報とを比較参照して、前記データ受信手段で受信した前記会議関連情報が前記優先条件に合致しているかどうかを判別して、前記優先条件に合致していると判別したときに、当該優先条件に合致していると判別された受信データを蓄積している前記他の会議端末装置用バッファメモリからの情報を、前記復号化手段で優先的に復号化を実行するように制御する優先制御手段と、
を備えることを特徴とする。
【００３２】
【作用】
請求項１の発明は、送信側の会議端末装置であって、予め送信側端末と受信側端末との間で取り決められた特定の情報が、送信する会議関連情報に含まれる場合に、優先度情報が送信信号中に付加される。受信側端末では、この送信信号に含まれる優先度情報により、当該優先すべき送信信号は、他の会議端末装置からの送信信号に優先して処理され、高品質で復号化される。
【００３４】
前述もしたように、会議においては、話者（発言者）の映像か、もしくは、話者の提供する映像に注目するので、少なくとも、話者の映像か、もしくは、話者の提供する映像だけは高品質で表示されることが望ましいが、この請求項１の発明によれば、受信側端末では、例えば、話者となっているユーザーが使用している会議端末装置からの送信信号は、常に、優先して処理され、高品質で復号化されるようにすることができる。
【００３５】
また、この発明の会議端末装置においては、ユーザーによる設定操作に基づく優先条件が参照されて、送信信号に優先条件情報を含ませるか否かが決定されて、当該送信信号が受信側端末に送られる。したがって、必要な場合に送信側でのユーザー指定に応じて優先条件情報が送信信号中に付加され、受信側端末で優先して処理される。
【００３６】
そして、受信側端末では、優先条件情報が付加されている送信信号を、他の送信信号に優先して処理するようになるので、ユーザーが特別に意識して操作することなく、常に優先するべき情報を優先的に処理することができるという効果がある。
【００３７】
また、この発明の会議端末装置においては、予め、ユーザーにより受信側端末で処理を優先させるようにするための条件（優先条件）が設定入力され、優先条件設定手段で設定される。そして、優先条件確認手段で、前記設定された優先条件に入力部から入力された会議関連情報が合致するか否かを判定確認する。情報処理手段は、その確認結果が優先条件に合致していることを示しているときは、送信信号に優先度情報と自端末の識別子とが付加情報として含めるようにする。
【００３８】
受信側端末は、ネットワークを通じてこれを受けると、優先条件情報に基づく判別をすることにより、受信した前記送信信号を優先して処理するか否かを自動的に判定して、復号化処理を実行する。
【００３９】
したがって、ユーザーにより優先条件を設定することができるため、例えばユーザーが高品質で再生する必要のあるとする情報は、ユーザーの意図の通りに再現することができるようになる。
【００４０】
また、この発明においては、優先条件として、どのような情報が送信信号に含まれるときに、受信側端末で優先処理を行わせることを設定することができる。例えば、話者の音声が送信信号に含まれるときのみ、特定の圧縮が施された映像情報が送信信号に含まれるときのみ、のように、ユーザーは設定することができる。例えば、会議映像資料は、ＭＰＥＧ圧縮されたものを使用すると定めた場合に、ＭＰＥＧ圧縮された映像データが送信信号に含まれるときに、自動的に送信信号に優先条件情報が付加挿入され、受信側端末で確実に優先処理させるようにすることができる。
【００４１】
また、優先条件送信手段により、優先条件情報を、自端末の識別子とともに、予め、受信側の会議端末装置に送るようにする。この優先条件情報は、例えば映像、音声などのマルチメディア情報のうちのどのような情報を含むときに、その処理を受信側で優先させるかの情報とすることができる。
【００４２】
したがって、受信側端末では、予め、この優先条件を各送信側の会議情報端末ごとに保存しておくことにより、送信信号を受信したときに、それに含まれる識別子により、いずれの会議端末装置からの送信信号であるかを認識し、そして、その送信信号を構成するマルチメディア情報としてどのような情報を含むかを判別して、予め保存してある当該送信信号を送信してきた会議端末装置についての優先情報を参照することにより、それを優先処理するか否かを自動的に決定することができる。
【００４８】
また、この発明においては、受信側の会議端末装置においては、優先条件蓄積手段に、ネットワークに接続されている他の会議端末装置ごとの優先条件が蓄積されている。この優先条件情報は、会議関連情報のうちの、いずれの情報を含む場合に復号化処理を優先させかという内容の情報である。
【００４９】
優先制御手段では、送信信号を受信したときに、その送信信号を送信してきた会議端末装置について優先条件情報を参照して、その送信信号が当該優先条件情報に合致するか否かを認識する。そして、合致している受信データについては、復号化手段で優先的に復号化を実行するように制御する。
【００５０】
したがって、この発明の場合には、予め受信側の会議端末装置に各会議端末装置ごとの優先条件情報を蓄積しておくことにより、各会議端末装置ごとに異なる優先条件を設定しても、それに対応した優先処理を行うことができる。
【００５２】
【発明の実施の形態】
以下、この発明による会議端末装置のいくつかの実施の形態を、図を参照しながら説明する。以下に説明する実施の形態の会議端末装置は、前述したような多地点マルチメディア会議システムに適用されるものである。そして、この場合の多地点マルチメディア会議システムは、図２１に示したように、ネットワークを通じて多地点に設置された複数個の会議端末装置が互いに接続され、マルチキャストの形式で相互の情報の送受を行うようにする場合である。
【００５３】
［第１の実施の形態］
この第１の実施の形態は、この発明の参考となる会議端末装置を示すもので、多地点マルチメディア会議中に、ユーザーが特に意識して操作することなく、かつ、常に注目するべき画像を優先的に高品質で表示できるようにするために、優先して処理してもらいたい情報を含むデータを送信するときに、優先度情報を付加してマルチメディアデータをパケット化するパケット化手段を備えた送信側端末と、受信情報中に含まれる上記優先度情報を検出して、どの送信側端末からのデータを優先して処理するべきかを選択する優先端末選択手段を備えた受信側端末とによって多地点マルチメディア会議システムを構築する。
【００５４】
そして、この第１の実施の形態では、予め定めた優先データが送信信号に含まれるときに、送信側端末からの送信信号に優先度情報を付加挿入するようにするが、以下に説明する例では、話者（発言者）が使用する会議端末装置からの送信情報を優先して処理するようにするために、優先データは音声情報とされる。
【００５５】
そして、ネットワークに接続される各会議端末装置が、前記の受信側端末の構成および送信側端末の構成を備えるものである。
【００５６】
＜会議端末装置の送信側の構成＞（請求項１、２、７に対応）
図１は、この第１の実施の形態の会議端末装置の送信側の構成例を示すもので、１１ｖは映像情報の入力端子、１１ａは音声情報の入力端子である。また、点線で囲んで示す部分は、情報処理手段を構成する部分である。
【００５７】
映像情報の入力端子１１ｖには、この例の場合には、ビデオカメラ２１の映像信号出力端子が接続される。ビデオカメラ２１は、この会議端末装置のユーザーである会議参加者および説明資料などを含む周辺状況を撮像し、その撮像出力信号を、映像情報の入力端子１１ｖに供給するようにする。
【００５８】
また、音声情報の入力端子１１ａには、会議参加者である当該会議端末装置のユーザーの発言を主として収音するためのマイクロホンの音声信号が供給される。
【００５９】
入力端子１１ｖを通じて入力された映像信号と、入力端子１１ａを通じて入力された音声信号とは、符号化部１２に供給されて、デジタル信号に変換されてそれぞれ符号化される。なお、説明の簡単のため、図１の例では、符号化部１２は、映像信号の符号化部と音声信号の符号化部とをまとめて示している。
【００６０】
この実施の形態における映像情報および音声情報のコーデック方式に関しては、一般にこのようなマルチメディア会議システムで用いられている、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication ）で規格化されているコーデック方式が用いられる。すなわち、映像信号については、Ｈ．２６１やＨ．２６３が用いられ、また、音声信号についてはＧ．７１１、Ｇ．７２２やＧ．７２８などが利用される。
【００６１】
これら複数のコーデック方式のうちのどれを選択するべきかということは、会議端末装置を接続するネットワークに依存し、例えばイーサネットに接続するのであれば、映像および音声のコーデックに、それぞれＨ．２６３、Ｇ．７１１を利用する。
【００６２】
もちろん、ＭＰＥＧやまったく別のコーデックを利用しても構わないし、複数のコーデックを用意しておいて選択して利用する形態にしてもよい。なお、このように複数のコーデックを選択して利用する場合において、例えば映像のコーデックでは多くの場合においてＤＣＴ（Discrete Cosine Transform ）を使うので、ＤＣＴを実行するモジュールだけは、コーデックの形式によらず、共通に利用できるような形態にしておくことが望ましい。
【００６３】
符号化部１２で符号化された映像データおよび音声データは、パケット化部１３に供給される。
【００６４】
また、マイクロホン２２から入力される音声信号は、レベル検出部１５にも供給されて、音声信号レベルが検出される。このレベル検出部１５では、例えば、図２に示すような入力アナログ音声信号を適当な時間間隔でサンプリングし、図３に示すように８ビットのディジタル信号にＡ／Ｄ変換して、音声信号レベルを時系列的に検出する。
【００６５】
このレベル検出部１５からの時系列的に検出された音声信号レベルは、逐次、レベル比較部１６に送られ、あらかじめ設定してある基準レベルと比較されて、ユーザーの発言の有無、すなわち、発言音声の有無が検出される。この基準レベルは、ノイズと、ユーザーが発言した音声とを識別して検出することができるような値に設定される。この基準レベルは、使用するマイクロホンや音源ボードによって変わってくる可能性があるので、各会議端末装置で最初に設定を行い、経験的に求められるノイズのレベルから基準レベルを決定するようにする。したがって、各会議端末装置ごとに基準レベルは異なる値になる場合もある。
【００６６】
レベル比較部１６では、レベル検出部１５で検出された音声信号のレベルが、基準レベルよりも高いときは、この送信側端末から発信されるマルチメディアデータとして音声情報が含まれていると判断する。すなわち、この送信側端末のユーザーが発言中であると判断する。
【００６７】
また、レベル比較部１６は、レベル検出部１５で検出された音声信号のレベルが、基準レベルよりも低いときは、この送信側端末から発信されるマルチメディアデータとして音声が含まれていない、すなわち、送信側端末のユーザーは発言をしていないと判断する。
【００６８】
そして、レベル比較部１６は、その判断結果の情報をパケット化部１３に供給する。
【００６９】
パケット化部１３は、符号化部１２で符号化されたマルチメディアデータをパケット化する。また、このようなマルチメディア会議システムでは、例えばアプリケーションソフトウェアの端末間共有などの機能を備えている場合が多いので、パケット化部１３では、メインバスを通ってＣＰＵ１４から送られてくる、このような機能に関わる映像や音声以外のデータも同様にパケット化する。
【００７０】
そして、パケット化部１３は、前記マルチメディアデータについてのパケット化を行う際に、前記レベル比較部１６からの前記音声信号の有無の判断結果を参照して、送信すべきデータに音声信号が含まれると認識したときには、認識した音声情報と同期して送信するデータのすべてについて、優先度情報を付加する。この優先度情報は、この第１の実施の形態では、受信側端末において、送信側端末から送信されてきたデータに音声が含まれていて、それが優先的に処理されるべきデータであるということを通知するためのものである。
【００７１】
そこで、この第１の実施の形態では、パケット化部１３では、各パケットのヘッダ部に、その優先度情報を含ませるようにする。図４は、この実施の形態の場合のパケットの構造を模式的に示すもので、各パケットは、ヘッダ部とデータ部とからなる。
【００７２】
ヘッダ部には、当該パケットが映像、音声などの、いずれのマルチメディアデータのパケットであるかを示すパケット識別子ＰＩＤ（パケットＩＤ）や、当該データが発生した時間を示すタイムスタンプＴＳや、自己の端末の識別子ＴＩＤ（端末ＩＤ）に加えて、前記優先度情報ＰＲが含まれる。タイムスタンプＴＳを参照することで、同期する情報、すなわち、同じフレーム内の情報であることを検知することができる。また、端末の識別子ＩＤとしては、例えばネットワーク１０上の当該端末のアドレスが利用される。これらの情報の、例えば、ＩＰ（インターネットプロトコル）では、そのデータのヘッダなどに含まれているので、それを使用することができる。
【００７３】
優先度情報ＰＲは、例えば１ビットの情報とされ、例えば、送信信号に音声情報が含まれるときには、その優先度情報ＰＲのビットが「１」とされ、送信信号に音声情報が含まれないときには、その優先度情報ＰＲのビットは「０」とされる。したがって、送信信号に音声情報が含まれるときには、前述したように、音声情報のパケットおよび、その音声情報パケットと同期して送信されるすべてのパケットのヘッダ部の優先度情報ＰＲのビットは「１」となる。この情報は、例えば前述したＩＰのヘッダに用意されているユーザー用のビットなどを割り当てて組み込むようにすることができる。
【００７４】
こうしてパケット化された各データは、多重化部１７に供給される。この多重化部１７では、受信側端末で分離した時に複数のマルチメディアデータ、例えば映像と音声が同期できるように、図５に示すような多重化を行う。図５で、一つのフレーム内にある映像パケットおよび音声パケットが同時刻に発生したデータである。それぞれが１つのパケットに納まりきれるとは限らず、複数のパケットになる場合もある。なお、図５の各パケットの先頭の部分に斜線を付して示したのは、各パケットのヘッダ部である。
【００７５】
以上のようにして、多重化部１７で多重化されたマルチメディアデータのパケットデータは、データ送信部１８に渡され、ネットワーク１０に送出され、受信側の会議端末装置に送信される。
【００７６】
図６および図７は、以上説明した会議端末装置の送信側の動作のフローチャートを示すものである。すなわち、会議端末装置は、映像、音声などのマルチメディアデータの入力を受ける（ステップＳ１）と、これらマルチメディアデータの符号化を行う（ステップＳ２）とともに、入力音声有無の検出チェックを行う（ステップＳ３）。
【００７７】
図７のフローチャートは、入力音声有無の検出チェックの流れを示すものである。すなわち、入力端子１１ａからのアナログ音声信号をサンプリングし（ステップＳ１１）、そのサンプリング値をＤ／Ａ変換して音声レベルを検出する（ステップＳ１２）。そして、各Ｄ／Ａ変換値を基準レベルと比較し（ステップＳ１３）、その比較の結果、Ｄ／Ａ変換値が基準レベルを超えているか否か判別し（ステップＳ１４）、基準レベルを超えていれば音声ありを示す情報を検出チェック結果として出力し（ステップＳ１５）、基準レベルを超えていなければ音声なしを示す情報を検出チェック結果として出力する（ステップＳ１６）。
【００７８】
以上のようにしてステップＳ３で入力音声有無の検出チェック結果が得られると、入力音声があるか否かの判断を行う（ステップＳ４）。そして、入力音声がある、つまり、当該会議端末装置のユーザーが発言をしていると判断したときには、ステップＳ５に進んで、マルチメディアデータの各パケットのヘッダ部に付加する優先度情報を“優先”の状態（優先度情報ＰＲのビットを「１」）にし、また、入力音声がないと判断したときには、ステップＳ６に進んで、各パケットのヘッダ部に付加する優先度情報を“非優先”の状態（優先度情報ＰＲのビットを「０」）にする。
【００７９】
次に、マルチメディアデータの各パケットを多重化し（ステップＳ７）、その多重化したデータをネットワーク１０に送出する（ステップＳ８）。
【００８０】
＜会議端末装置の受信側の構成＞（請求項１０、１２に対応）
次に、会議端末装置の受信側について説明する。図８は、この発明における多地点マルチメディア会議端末装置のデータ受信および復号化処理部分の構成図の一例である。この図８において、点線で囲んだ部分は、情報処理手段を構成する部分である。
【００８１】
データ受信部３１は、ネットワーク１０を通って送られてきた多重化されたマルチメディアデータのパケットを受信する。これらのデータは分離部３２へ送られ、多重化されているパケットを、映像パケット、音声パケット、アプリケーションパケットなどの各メディアごとに分離する。
【００８２】
分離部３２で分離された送信側端末から送信されてきた各メディアごとのパケットは、パケット分解部３３において分解される。前述したように、各パケットには、送信側端末の識別子ＩＤ（送信側端末のアドレス）が付加されているので、ここで、どの送信側端末から送信されてきたマルチメディアデータであるかが判断される。
【００８３】
パケットを分解して取り出された映像および音声のデータは、パケット分解部３３からバッファメモリ３４ａ〜３４ｄのうちの送信側端末に対応するバッファメモリに格納される。バッファメモリ３４ａ〜３４ｄは、ネットワーク１０に接続されている会議端末装置の数分、用意されているものである。図８の例は、図２１におけるＥ地点の会議端末装置の受信側の構成例であって、他のＡ地点〜Ｄ地点の会議端末装置に対応して４つのバッファメモリ３４ａ〜３４ｄが設けられており、送信側端末ごとにマルチメディアデータが仕分けされて、一時蓄積される。さらに、バッファメモリ３４ａ〜３４ｄのそれぞれには、映像および音声などのメディアごとに区別されて、情報が蓄積されている。
【００８４】
バッファメモリ３４ａ〜３４ｄからの映像および音声データは、１フレーム分のデータ単位で、復号化部３５に送られて復号化処理される。復号化部３５は、この実施の形態の場合、バッファメモリ３４ａ〜３４ｄからのデータのすべてを同時に並列処理する構成ではなく、バッファメモリ３４ａ〜３４ｄのうちのいずれか一つからの１フレーム分のデータづつを処理するものである。
【００８５】
バッファメモリ３４ａ〜３４ｄのいずれかに１フレーム分のデータが蓄積されると、そのバッファメモリから、そのことが復号化部３５に伝えられる。復号化部３５では、バッファメモリ３４ａ〜３４ｄから１フレーム分のデータが蓄積されたことの通知が到来すると、その通知が到来したバッファメモリの１フレーム分のデータの復号化処理が可能な状態になったと認識する。そして、そのバッファメモリの１フレーム分のデータの復号を行うようにする。
【００８６】
この場合に、後述するような優先処理の状況でないときには、復号化の順番は、４個のバッファメモリで均等となるように、１フレーム分のデータが復号化される。したがって、このときには、４個の会議端末装置１ａ〜１ｄからの映像の画質に差（この例の場合には、フレーム間引きがあるか否か）は生じない。
【００８７】
この図８では、説明の簡単のために、復号化部３５は映像および音声の復号化部を一体として、まとめて示しているが、実際には、映像情報用の復号化部と、音声情報用の復号化部がある。この復号化部３５は、送信側端末の符号化部１２に採用した符号化方式に対応したものである。もちろん、符号化方式として複数のコーデックを選択して利用する形態の場合には、それに対応して複数のデコーダの機能を復号化部３５が有するように構成する。その場合には、送信側と同様に、コーデックの形式によらず大抵の場合、逆ＤＣＴを使うので、逆ＤＣＴのモジュールだけは、コーデックによらず利用できるような構成にしておくことが望ましい。
【００８８】
また、実際には音声の復号化に比べて映像の復号化は処理に時間がかかるので、例えば遅延回路を挿入して映像と音声の処理遅延の遅延差を無くし、２つのメディア間の同期を取るというようなことが行われるが、この点についてもこの図８では省略してある。
【００８９】
冒頭の従来の技術の欄でも述べたように、復号化部３５の処理能力が非常に高く、バッファメモリ３４ａ〜３４ｄに格納されたデータを滞りなく処理できれば問題ないが、マルチメディア会議に参加している端末の数が多いと復号化部３５が処理しなければならないデータも増大し、現実的には処理しきれなくなる。
【００９０】
そこで、この実施の形態では、送信信号の各パケットごとに含まれる前記優先度情報に基づいて、送信側端末から送られてきた情報が、復号化部３５で優先処理すべきデータがあるときには、復号化部３５で、そのデータを優先的に処理するように制御する。
【００９１】
すなわち、パケット分解部３３は、受信した送信信号の各パケットのヘッダ部に挿入付加されている優先度情報ＰＲを取り出し、端末識別子ＩＤとともに、優先端末選択部３６に、その取り出した優先度情報ＰＲを送る。優先端末選択部３６は、この優先度情報ＰＲを解析し、受信した送信側端末からの送信信号が優先して処理すべきものであるか否か判断する。すなわち、優先度情報ＰＲのビットが「１」であるときには、優先して処理すべきと判断し、「０」であれば、優先処理の必要なしと判断する。そして、その判断結果を情報は、復号化部３５に送る。
【００９２】
この実施の形態の場合、優先端末選択部３６からの判断結果の情報は、復号化部３５での４個のバッファメモリ３４ａ〜３４ｄに関する優先処理指示に関するもので、４ビットの情報とされる。この４ビットの優先処理指示情報の各ビットは、４地点Ａ〜Ｄの各会議端末装置から送られてきた情報を優先処理するか否かの情報を示すもので、この例では、ビットが「１」となっている端末からの情報の優先処理、ビットが「０」となっている端末からの情報は非優先とされる。
【００９３】
図９は、この４ビットの優先処理指示情報の例を説明するための図である。優先端末選択部３６は、パケット分解部３３からの優先度情報を解析することで、図９の表のような形式で各バッファメモリからの情報の優先、非優先の管理を行う。図９において、○はその送信側端末を優先させることを意味し、×は優先させなくてもよいことを意味する。そして、４ビットの優先処理指示情報は、前者（○）に「１」に、後者（×）に「０」を対応させることにより生成する。
【００９４】
図９の例の場合、時点ｔ１，ｔ２，ｔ３では、地点Ａの端末からの情報を優先して処理する状況になっており、時点ｔ３以降、時点ｔｎまでは、いずれの端末からの情報も非優先の状況となっていることを示している。そして、時点ｔｎでは、Ｂ地点の会議端末装置からの送信情報と、Ｃ地点の会議端末装置からの送信情報とが優先して処理されるべき状況となっている。
【００９５】
復号化部３５では、優先端末選択部３６からの４ビットの優先処理指示情報が、いずれかの端末からの情報を優先して処理することを指示している場合には、もし他の端末用のバッファメモリから１フレーム分のデータが蓄積されたことの通知が到来したとしても、優先端末選択部３６からの優先処理指示情報の指示通りに、優先すべき端末からの情報の復号化処理を続けて行うようにする。
【００９６】
図９の時点ｔ１，ｔ２，ｔ３では、バッファメモリ３４ａからの情報が優先されて、復号化部３５において優先復号化処理されることになる。
【００９７】
なお、図９の時点ｔｎのように、優先処理すべき端末が複数個になった場合には、それらの端末の間で交代に復号化処理するようにする。４ビットの優先処理指示情報が「００００」であるときには、優先的に処理する必要がないので、復号化部３５では、４個のバッファメモリ３４ａ〜３４ｂのデータについて、予め定めた順序で、均等に復号化処理を行うようにする。
【００９８】
以上のようにして復号化部３５で復号化された映像および音声のデータは、それぞれ出力端子３８ｖおよび３８ａを通じて、ディスプレイ４１およびスピーカ４２へと出力されて、再生される。
【００９９】
なお、パケット分解部３３において、パケット分解されて取り出された、例えばアプリケーションソフトウェアの端末間共有のような機能に関わる、計算を必要とするデータは、メインバスを通り、ＣＰＵ３７へと送られる。
【０１００】
図１０は、以上説明した第１の実施の形態の会議端末装置の受信側の動作のフローチャートを示すものである。
【０１０１】
すなわち、会議端末装置は、ネットワーク１０から、いずれかの端末からの送信信号である多重化データを取り込み（ステップＳ２１）、その取り込んだ多重化データをパケットごとに分離する（ステップＳ２２）。ついで、各パケットを分解し（ステップＳ２３）、ヘッダ部の付加情報のパケットＩＤや端末ＩＤなどのチェックを行い（ステップＳ２４）、送信側端末に対応したバッファメモリに、音声データや映像データを分離して格納する（ステップＳ２５）。
【０１０２】
このバッファメモリへの格納に伴って、ヘッダ部の優先度情報ＰＲのチェックを行い（ステップＳ２６）、前述したような自己以外の他の会議端末装置の数に対応したビット数、この例では４ビットの信号を生成し、復号化部３５に供給する（ステップＳ２７）。
【０１０３】
復号化に当たっては、４ビットの信号の各ビットの状態を確認して、優先すべき送信側端末からの送信データがあるか否か判断する（ステップＳ２８）。優先すべき送信側端末からのデータがあると判断したときには、その優先すべき情報の復号化を、他の端末からの情報に優先して実行し（ステップＳ２９）、その出力データを出力し、映像および音声を再生する（ステップＳ３３）。
【０１０４】
また、優先される送信側端末からの送信データがないと判断したときには、復号化中か否か判断し、復号化中であれば、復号化部３５での処理が終了するのを待ち（ステップＳ３１）、復号化部３５での処理が終了したら、４個のバッファメモリ３４ａ〜３４ｄからのデータを機会均等に復号化処理するようにする（ステップＳ３２）。そして、その復号結果を出力し（ステップＳ３３）、映像および音声を再生する。
【０１０５】
以上のような構成の多地点マルチメディア会議端末を用いれば、会議端末装置の計算機能力が低くて、多量の映像などのデータを処理しきれない場合でも、会議中にユーザが特に意識して操作することなく、常に注目するべき画像を優先的に高品質で表示でき、会議がスムーズに進行できるようにすることができる。すなわち、注目する画像や音声は、送信されてきたものが、ほぼすべて復号化されて再生されるようになるためである。
【０１０６】
これに対して、優先指定されていない端末からの情報は、他の端末からの情報が優先処理されているために、送信されてきても、対応するバッファメモリに蓄積しきれなくなり、その情報を持ったデータは、廃棄されることになる場合が生じる。そして、優先指定されている端末がなくなると、当該非優先の端末についての映像情報の復号化が実行されるようになる。そのため、当該非優先の端末の映像出力画像は、いわゆる駒落としのような状態になるが、前述したように、もともと、非優先の端末からの画像情報は、ユーザーがその出力画像に注目する度合いが少ないので、会議に支障はほとんど生じない。
【０１０７】
特に、この第１の実施の形態の上述の例では、音声情報の有無を判別して、音声情報が送信信号に含まれる場合、つまり、会議において、発言しているユーザーからの情報を優先処理するようにしたので、受信側端末での再生において、発言者の発言内容がとぎれたり、発言者の動作や、提示する資料の映像が低品質になるのを防止することができる。
【０１０８】
なお、上述の図１の送信側端末の構成において、レベル検出部１５およびレベル比較部１６では、ノイズの影響を除去して、音声信号の有無を確認することができればよいので、これらレベル検出部１５およびレベル比較部１６以外の別の手段によって、音声信号の有無を検出するように構成することももちろんできる。
【０１０９】
また、優先度情報ＰＲは、ヘッダ部ではなく、各パケットのデータ部の先頭部分などの映像情報や音声情報などの情報とは区別できる部位に付加するようにすることもできる。
【０１１０】
また、優先度情報ＰＲは、１ビットである必要はなく、複数ビットで構成されていてももちろんよい。また、優先度情報ＰＲは、常にヘッダ部やデータ部に挿入付加するのではなく、音声情報パケットおよび、その音声情報パケットと同期して送信されるパケットにのみ、挿入付加するようにしてもよい。その場合には、受信側端末では、パケットのヘッダ部やパケットのデータ部に優先度情報が存在するか否かを判別するだけで、優先すべき情報であるか否かを判別することができる。
【０１１１】
さらに、上述の説明では、音声の有無により、優先とするか否かを決めるようにしたが、例えば、特定の画像情報、例えば会議に資料として提出したい情報は、予めＭＰＥＧ圧縮して保存するように規定する場合に、当該ＭＰＥＧ圧縮画像情報が送信信号に含まれる場合に、上述したような優先度情報を送信信号に含ませて送信するように構成することもできる。つまり、優先とするか否かは、音声に限らず、予め定めた情報が送信信号に含まれるか否かにより決定することもできるものである。
【０１１２】
［第２の実施の形態］
上述した第１の実施の形態では、送信側端末から送信されるマルチメディアデータの中に音声などの特定の情報が含まれていた場合に、優先度情報をパケットに付加し、受信側端末がそれを認識して処理する優先度を決定するという形態について説明した。
【０１１３】
しかし、必ずしも処理を優先させる規準が、予めすべての会議端末装置間で共通の特定の情報によるとは限らず、臨機応変に各会議端末装置のユーザが変更したい場合もある。具体的には、例えば、あるユーザーが展示会等で撮影した映像を各受信側端末に提示しながら、その映像に対して説明をしたいとするような場合、少なくともその撮影映像はフレーム落ちなどのない高品質で表示させるようにしたい要望がある。
【０１１４】
この点にかんがみ、以下に説明するこの発明による実施形態としての第２の実施の形態では、ユーザーにより優先指定の条件を設定できるようにする。この優先条件の例として、以下の説明においては、ユーザーが指定した特定の情報が送信信号に含まれるときに、受信側での処理の優先を要求するものとする。優先条件として、例えば、特定ソースの映像が含まれるときや、発言音声が含まれるときなどが、ユーザーにより指定される。
【０１１５】
そして、この第２の実施の形態では、優先条件を送信側において記憶しておき、送信すべき信号がその優先条件に合致しているときに、その優先条件の情報を送信信号に付加して受信側端末に送信するようにする。
【０１１６】
また、送信側端末は、設定した優先条件の情報を、例えば会議開始前などの適当な時点において、予め受信側端末に送信しておく。受信側端末では、この優先条件情報を受信して送信側端末ごとに保存格納しておく。そして、受信側端末で、送信側端末からの送信信号を受信したときに、その受信した送信信号中に含まれる優先条件情報を、予め受信して記憶した優先条件情報と比較して、その一致を確認することにより、優先して処理すべきものであるかどうかを確定し、優先処理するようにする。
【０１１７】
＜会議端末装置の送信側の構成＞（請求項３、４、５、７に対応）
図１１は、この第２の実施の形態における多地点マルチメディア会議端末装置の送信側端末部分、すなわち、符号化処理およびデータ送信部分における構成図の一例である。点線で囲んだ部分は、情報処理手段を構成する部分である。
【０１１８】
この第２の実施の形態の送信側の構成においては、前述の第１の実施の形態のレベル検出部１５とレベル比較部１６は設けられず、その代わりに、優先データ設定操作部５１と、優先条件設定部５２と、優先条件確認部５３と、外部メモリ５４とを設けた構成となっている。その他の構成は、第１の実施の形態の図１の場合の構成と同様である。
【０１１９】
外部メモリ５４は、会議資料として提供したい画像情報を格納しておくもので、この例では、当該画像情報は、ＭＰＥＧ圧縮データとして格納しておくものである。
【０１２０】
設定操作部５１は、受信側端末で優先して処理させたい条件を設定入力するためのものである。この例では、どのようなデータを自端末から送信した場合に受信側端末で特に優先して処理してほしいかという情報を設定入力するようにする。
【０１２１】
この実施の形態の場合には、送信する情報としては、カメラ２１からの会議参加者の撮像映像データと、マイクロホン２２からの音声データ（発言）と、ＣＰＵ１４からのデータと、外部メモリ５４からのＭＰＥＧ圧縮データ形式の資料映像データとの４種のデータが想定されている。優先条件の設定は、この４種のデータのうちのどれが含まれているときに、受信側端末で優先して処理してほしいかを設定することができるようにされる。
【０１２２】
例えば、音声情報が含まれている場合に優先してほしいときは、「音声情報」と設定入力し、前述のＭＰＥＧ圧縮された映像情報が含まれている場合に優先してほしい時には、「ＭＰＥＧ情報」と設定入力するという具合に設定する。
【０１２３】
この設定操作部５１は、キーボードやマウス、またはペンタブレットのような入力デバイスで構成され、これを用いて優先条件である前記の情報の選択設定がなされる。例えば、最も簡単で使いやすい形態として、画面上に、図１２に示すようなプルダウンメニューＭＮを映出し、このプルダウンメニューＭＮから選択させる方法が採用される。
【０１２４】
設定操作部５１により選択設定された、受信側で優先処理してもらいたいデータに関する情報（以下、優先条件情報という）は、優先条件設定部５２に設定される。この優先条件設定部５２はメモリを備え、優先条件情報がメモリに格納される。この優先条件の設定は、会議が始まる前に、この会議端末装置のユーザーにより行われる。
【０１２５】
そして、ユーザーが設定した優先条件情報は、ネットワーク１０を介して複数の受信側端末へ、例えば電子メールのような形態で送信され、後述するように各受信側端末の優先条件情報記憶部に、端末ＩＤとともに、記憶される。優先条件設定部５２のメモリに保存された優先条件情報は、優先条件確認部５３にも供給される。
【０１２６】
優先条件確認部５３には、送信される可能性のある情報のすべてが入力される。すなわち、入力端子１１ｖおよび１１ａからの映像データおよび音声データと、外部メモリ５４からのＭＰＥＧデータと、ＣＰＵ１４からのデータとが入力される。
【０１２７】
この優先条件確認部５３は、会議中に自端末から送信信号をネットワーク１０を通じて他の端末に送信するときに、前記４種の入力信号の有無をそれぞれ検出することにより、当該送信信号がどのようなマルチメディア情報を含んでいるかを認識し、認識した送信信号が、以上のようにして設定された優先条件を参照した結果、優先条件と一致しているマルチメディアデータタイプのときには、その優先条件情報をパケット化部１３に送り、それを送信信号に付加して、ネットワークに送出するように、パケット化部１３に依頼する。
【０１２８】
また、この例では、優先条件確認部５３は、認識した送信信号が、設定された優先条件と一致していないときには、優先指定なしの優先条件情報をパケット化部１３に送り、それを送信信号に付加して、ネットワークに送出するように、パケット化部１３に依頼する。
【０１２９】
パケット部１３は、この第２の実施の形態では、符号化部１２からの映像データおよび音声データのパケット化と、ＣＰＵ１４からのデータ、例えば、アプリケーションソフトウェアの端末間共有などの機能に関わるデータのパケット化、外部メモリ５４からのＭＰＥＧデータのパケット化とを行う。
【０１３０】
そして、そのパケット化の際に、各パケットには、優先度情報を、前述の第１の実施の形態の場合と同様にして付加挿入する。この第２の実施の形態の場合の優先度情報は、受信側端末で当該データを優先して処理すべきか否かを判定する際に使用される情報であり、この第２の実施の形態では、前述した優先条件確認部５３から送られてくる優先条件情報がそのまま使用される。
【０１３１】
すなわち、パケット化部１３は、送信信号が設定されている優先条件に適合する場合には、優先条件確認部５３からの設定されている優先条件情報と等しい情報を、前記優先度情報として、各パケットのヘッダ部に、前述の第１の実施の形態の場合と同様にして付加挿入することになる。また、送信信号が設定されている優先条件に適合していない場合には、優先条件確認部５３からの優先指定なしの情報が、付加する優先度情報として、各パケットのヘッダ部に、同様にして付加挿入されることになる。
【０１３２】
この実施の形態では、優先条件情報は、設定された情報を含む送信マルチメディアデータのタイプとして表される。すなわち、図１３は、マルチメディアデータタイプと、優先条件情報との対応関係を示すものである。この例では、マルチメディアデータタイプとして４種のタイプを想定したので、優先条件情報は、２ビットで表される場合として示している。優先条件が、４種以上を設定可能であれば、優先条件情報は、３ビット以上の情報として構成するようにするのはもちろんである。
【０１３３】
図１３の表に示すように、この例では、設定操作部５１で、優先条件の指定をしなかった場合には、
図１３の表に示すように、この例で想定されるマルチメディアデータタイプは、
▲１▼優先条件の指定無し
▲２▼ＭＰＥＧ映像を含む場合を優先
▲３▼発言音声を含む場合に優先
▲４▼ＭＰＥＧ映像と発言音声を含む場合に優先
の４種とされる。
【０１３４】
そして、▲１▼優先条件の指定無しのマルチメディアデータタイプのときは、２ビットの優先条件情報は「００」、▲２▼ＭＰＥＧ映像を含むマルチメディアデータタイプのときは、２ビットの優先条件情報は「０１」、▲３▼発言音声を含むマルチメディアデータタイプのときは、２ビットの優先条件情報は「１０」、▲４▼ＭＰＥＧ映像と発言音声を含むマルチメディアデータタイプのときは、２ビットの優先条件情報は「１１」、とされる。
【０１３５】
優先条件設定部５２のメモリには、設定操作部５１での設定に応じた２ビットの優先条件情報が書き込まれ、また、同じ情報がネットワーク１０を通じて受信側端末に送信され、その優先条件情報記憶部に記憶される。
【０１３６】
図１４は、上述した各会議端末装置の送信側における優先条件設定部５２の動作のフローチャートである。
【０１３７】
すなわち、まず、設定操作部５１を通じてのユーザーの優先条件の設定選択入力を受け付ける（ステップＳ４１）。そして、設定された優先条件を判定し（ステップＳ４２）、２ビットの優先条件情報をそのメモリに保存する（ステップＳ４３）。次いで、ネットワークを通じて他のすべての受信側端末に、前記２ビットの優先条件情報を、例えば電子メール形式で送信する。以上で、優先条件の設定の終了である。
【０１３８】
例えば、ユーザーによりＭＰＥＧデータが選択設定された場合には、優先条件情報として、優先条件設定部５２のメモリに、優先条件として「０１」が記憶され、この２ビットの情報が他の受信側端末のすべてにネットワーク１０を通じて送られ、各受信側端末に記憶保持されるようにされる。
【０１３９】
その後、会議が始まると、前述したように、優先条件確認部５３は、会議中に自端末から送信信号をネットワークを通じて他の端末に送信するときに、当該送信信号がどのようなマルチメディア情報を含んでいるかを認識し、この優先条件確認部５３での認識結果に応じて、パケット化部に、前述した優先度情報が付加されて受信側端末に向けて送出される。
【０１４０】
この第２の実施の形態の会議端末装置の送信側の会議開始後の動作を、図１５のフローチャートを参照しながら説明する。
【０１４１】
すなわち、会議が始まると、前述した第１の実施の形態と同様に、送信側端末に付属しているカメラ２１およびマイクロホン２２から映像データおよび音声データの入力を受け（ステップＳ５１）と、これらマルチメディアデータの符号化を行う（ステップＳ５２）。
【０１４２】
この符号化と並行して、優先条件確認部５３において、４種の入力信号の有無のチェックにより、送信信号のチェックを行い（ステップ５３）、優先条件設定部５２に予め設定されている優先条件に合致しているか否かの判断を行う（ステップＳ５４）。
【０１４３】
そして、設定されている優先条件に合致していると判断したときには、優先条件確認部５３から、優先条件設定部５２のメモリに格納されている優先条件情報をパケット化部１３に送って、パケット化部１３でその優先条件情報を各パケットのヘッダ部に付加して、各マルチメディアデータのパケットを生成する（ステップＳ５５）。
【０１４４】
例えば、ＭＰＥＧデータが送信信号に含まれるときに優先と設定されていたときには、外部メモリ５４からの情報、つまり、ＭＰＥＧデータの入力を確認すると、送信信号が優先条件と一致しているとして、その２ビットの情報「０１」が、優先度情報として各パケットのヘッダ部に付加されて、各データパケットが生成される。
【０１４５】
一方、ステップＳ５４での判断において、設定されている優先条件に合致していないと判断したときには、この例では、優先条件確認部５３は「指定無し」を意味する「００」をパケット化部１３に送るので、パケット化部１３では、その２ビットの情報「００」が、優先度情報として各パケットのヘッダ部に付加されて、各データパケットが生成される（ステップＳ５６）。
【０１４６】
次に、マルチメディアデータの各パケットを多重化し（ステップＳ５７）、その多重化したデータをネットワーク１０に送出する（ステップＳ５８）。なお、この例の場合には、受信側端末で分離した時に複数のマルチメディアデータ、例えば、この例の場合には、映像と音声に加えてアニメーションが同期できるような多重化を行うことができる。
【０１４７】
＜会議端末装置の受信側の構成＞（請求項１１、１２に対応）
次に、会議端末装置の受信側について説明する。図１６は、この発明における多地点マルチメディア会議端末装置のデータ受信および復号化処理部分の構成図の一例である。この図１６において、点線で囲んだ部分は、情報処理手段を構成する部分である。
【０１４８】
この図１６の構成で、図８に示した第１の実施の形態の場合の会議端末装置のデータ受信および復号化処理部分の構成と異なるのは、この第２の実施の形態では、優先条件情報記憶部６１が設けられる点と、優先端末選択部３６の動作が異なる点である。その他の構成は、第１の実施の形態の図８の場合とほぼ同様であるので、その詳細な説明は省略する。
【０１４９】
すなわち、この第２の実施の形態においては、優先条件情報記憶部６１には、会議の開始に先立ち、ネットワーク１０およびデータ受信部３１を通じて、例えば電子メール形式で送られてくる、各送信側端末で設定された優先条件情報が各送信側端末ごとに記憶される。なお、前述したように、パケットヘッダには、端末ＩＤとしてネットワーク上のアドレスが使用されるが、電子メールアドレスは、当該ネットワーク上のアドレスそのものであるので、優先条件情報記憶部６１には、端末ＩＤをインデックスとして、各送信側端末の優先条件情報が記憶されていることなる。
【０１５０】
この優先条件情報記憶部６１に記憶された優先条件情報は、優先端末選択部３６に供給される。すなわち、優先端末選択部３６は、送信信号から取り出したパケットをパケット分解部３３でパケット分解して得られる端末ＩＤおよび優先度情報を、パケット分解部３３から取得し、当該端末から到来した信号は優先処理すべきかどうかを、優先条件情報記憶部６１に記憶されている当該端末の優先条件情報を参照することにより決定する。そして、その決定結果により、前述の第１の実施の形態の場合と同様に、優先端末選択部３６は、復号化部３５に供給する４ビットの優先処理指示情報を生成する。
【０１５１】
図１７は、この第２の実施の形態において、優先端末選択部３６で４ビットの優先処理指示情報が生成される例を説明するための図である。優先端末選択部３６は、パケット分解部３３からの優先度情報を、優先条件情報記憶部６１からの優先条件情報を参照して解析することで、図１７の表のような形式で各バッファメモリからの情報の優先、非優先の管理を行う。この場合も第１の実施の形態の場合と同様に、４ビットの優先処理指示情報のビットが「１」である端末は優先すべきもの、「０」である端末は優先する必要のないものをそれぞれ意味するものである。
【０１５２】
図１７の例は、地点Ｅの会議端末装置の場合で、地点Ａ，ＢおよびＤの会議端末装置では優先条件の指定をしなかったので、優先条件情報記憶部６１のそれらの会議端末装置のそれぞれの優先条件情報の記憶値は、「００」となっており、また、地点Ｃの会議端末装置では、ＭＰＥＧ映像データが送信信号に含まれるときに、優先処理をしてもらいたいとの設定がなされているので、その会議端末装置Ｃの優先条件情報の記憶値のみが、「０１」となっている場合である。
【０１５３】
この場合、時点ｔ１，ｔ２，では、いずれの地点の端末からも優先指定無しで送信信号が到来している状態で、このときには、優先端末選択部３６からの４ビットの優先処理指示情報は、「００００」となっており、復号化部３５では、４個のバッファメモリからのデータを順番に均等に復号化するようになる。
【０１５４】
そして、時点ｔｉでは、地点Ｃの会議端末装置からの送信信号には、優先度情報として「０１」が付加されているため、これが優先端末選択部３６で検出されて、復号化部３５に供給される４ビットの優先処理指示情報は「００１０」とされる。すなわち、優先条件情報の記憶値が「００」となっている場合は、優先されることがないので、その会議端末の対応するビットは、常に「０」であり、「００」以外になっている場合は、付加されてきた優先度情報と合致した場合にだけ「１」となる。これにより、復号化部３５では、バッファメモリ３５ｃの会議端末装置からの情報を優先して復号化処理されるようになる。
【０１５５】
この第２の実施の形態でも、復号化部３５では、優先端末選択部３６からの４ビットの優先処理指示情報が、いずれかの端末からの情報を優先して処理することを指示している場合には、もし他の端末用のバッファメモリから１フレーム分のデータが蓄積されたことの通知が到来したとしても、優先端末選択部３６からの優先処理指示情報の指示通りに、優先すべき端末からの情報の復号化処理を続けて行うようにする。
【０１５６】
また、優先処理すべき端末が複数個になった場合には、それらの端末の間で交代に復号化処理するようにする。４ビットの優先処理指示情報が「００００」であるときには、優先的に処理する必要がないので、復号化部３５では、４個のバッファメモリ３４ａ〜３４ｂのデータについて、予め定めた順序で、均等に復号化処理を行うようにするのは、第１の実施の形態の場合と同様である。
【０１５７】
図１８は、以上説明した第２の実施の形態の会議端末装置の受信側の動作のフローチャートを示すものである。このフローチャートは、第１の実施の形態の会議端末装置の受信側の動作のフローチャートと、優先度情報のチェックの方法がが異なるだけで、ほぼ同様である。
【０１５８】
すなわち、ステップＳ６１〜Ｓ６５およびステップＳ６８〜Ｓ７３は、第１の実施の形態の図１０のフローチャートのステップステップＳ２１〜Ｓ２５およびステップＳ２８〜Ｓ３３に、それぞれ対応している。この第２の実施の形態では、ステップＳ６６と、ステップＳ６７の優先度情報のチェックから４ビットの優先処理指示情報の形成までの処理部分が、第１の実施の形態と異なる。
【０１５９】
すなわち、この第２の実施の形態では、前述もしたように、送信側端末から送信信号を受信すると、ステップＳ６５までの処理により、送信側端末に対応したバッファメモリに、音声データや映像データが分離されて格納されるとともに、パケット分解部３３から得られる端末ＩＤおよび優先度情報を優先端末選択部３６が受け取る。
【０１６０】
そして、優先端末選択部３６は、優先条件情報記憶部６１に記憶されている当該端末ＩＤで示される送信側端末の優先条件情報を読み出し、読み出した優先条件情報が「００」以外のとき、パケット分解部３３から取得した優先度情報と、その優先条件情報とを比較し、両者が一致したら、４ビットの優先処理指示情報の当該端末に対応するビットを「１」とする。また、比較結果が不一致であれば、４ビットの優先処理指示情報の当該端末に対応するビットは「０」のままとする。また、読み出した優先条件情報が「００」であれば、優先されることはないので、対応するビットは常に「０」とする。
【０１６１】
この結果、優先度情報が優先条件情報に一致していれば、ステップＳ６９で当該端末からの情報が優先して復号化が実行され、そうでなければ、４個のバッファメモリ３４ａ〜３４ｄからのデータが機会均等に復号化処理される。
【０１６２】
以上説明した第２の実施の形態の会議端末装置を用いれば、第１の実施の形態と同様に、端末の計算機能力が低く、多量の映像データを処理しきれない場合でも、会議中にユーザが特に意識して操作することなく、常に注目するべき画像を優先的に高品質で表示でき、会議がスムーズに進行できるようにすることができる。
【０１６３】
そして、この第２の実施の形態の場合には、ユーザーが予め受信側で優先して処理してもらいたい情報を定めておくようにすることができるので、会議の重要な情報は、受信側において優先処理されて、品質が低下するのが防止されるので、会議がスムースに進行するものである。
【０１６４】
なお、会議に先立ち、予め複数の受信側端末に優先条件情報を送る方法は、電子メールによる方法に限るものではなく、パケット伝送方式であってもよいし、その他種々の伝送方式を利用できることは言うまでもない。
【０１６５】
また、会議中に送信する会議関連情報に付加される優先度情報は、ヘッダ部ではなく、各パケットのデータ部の先頭部分などの映像情報や音声情報などの情報とは区別できる部位に付加するようにすることもできる。
【０１６６】
また、前述もしたように、優先度情報つまり優先条件情報は、２ビットである必要はなく、３ビット以上で構成されていてももちろんよい。また、優先度情報は、常にヘッダ部やデータ部に挿入付加するのではなく、送信側端末において優先条件に合致する送信信号のパケットにのみ、挿入付加するようにしてもよい。その場合には、受信側端末では、パケットヘッダやパケットのデータ部に優先度情報が存在するか否かを判別するだけでも、優先すべき情報であるか否かを判別することができるが、受信した優先度情報と、優先条件情報記憶部の優先条件情報との比較検討を行うことにより、誤りなく、優先すべき情報の優先処理を確実に行うことができる。
【０１６７】
また、上述の第２の実施の形態の説明では、会議の最初に優先条件を設定しただけの場合を説明したが、会議の途中で、設定操作部５１により優先条件設定部５２を操作することで、優先条件情報を臨機応変に変更および更新するように構成することも可能である。
【０１６８】
［他の実施の形態］
第２の実施の形態においては、優先条件確認手段では、送信信号が優先条件に合致しているか否かを確認して、合致しているときに、その優先条件情報に等しい優先度情報を付加して送信するようにしたが、送信信号のマルチメディアデータタイプを予め送信側と受信側とで定めておき、必ず、送信信号のパケットには、そのマルチメディアデータタイプを付加するようにすることで、送信側での優先条件の確認処理を不要にすることができる。
【０１６９】
すなわち、図１１の優先条件確認部５３では、単に、４種の入力信号のうちのどれとどれが送信信号に含まれるかを確認し、その含まれる情報に応じたマルチメディアデータタイプを判定確認する。そして、パケット化部１３にそのマルチメディアデータタイプの情報を送るようにする。
【０１７０】
受信側においては、常時、受信した送信信号のマルチメディアデータタイプを判定し、それが予め記憶されている優先条件情報に合致しているか否か確認することで、それが優先処理すべきデータであるか否かを判断することができる。
【０１７１】
このようにすれば、優先条件確認部５３へ優先条件設定部５２から優先条件情報を供給する必要がないとともに、優先条件確認部５３では、優先条件に送信信号が合致しているかどうかを判定する必要がなくなるものである。
【０１７２】
また、第２の実施の形態では、予め、ユーザーが各会議端末装置で設定した優先条件を受信側端末に知らせておくようにするとともに、各受信側端末では、複数の送信側端末で設定されたそれぞれの優先条件情報を集めて記憶しておき、送信信号中に含まれる優先度情報が、記憶している送信側端末の優先条件情報と一致しているか否かにより優先処理するか否かを設定するようにした。
【０１７３】
しかし、送信側端末において、予め設定した優先条件に合致する送信信号を他の受信側端末に送信するときにのみ、第１の実施の形態で説明したような優先度情報ＰＲを挿入することようにすることもできる。この場合には、受信側端末の構成は、第１の実施の形態の場合の図８の構成とするだけでよく、予め、ユーザーが各会議端末装置で設定した優先条件を受信側端末に知らせておくようにしたり、また、受信側端末で各送信側端末ごとの優先条件情報を記憶しておく必要はない。
【０１７４】
また、第１の実施の形態では、送信側端末が音声の有無により優先度情報を受信側端末に知らせる形態を示したが、優先度情報が音声の有無だけによると決めておくのであれば、音声の有無を調べる処理を受信側端末が行うことで、送信側端末に頼ることなく同じ効果を得ることができる。この場合には、送信信号に優先度情報を付加する必要はない。
【０１７５】
［他の変形例］
第１の実施の形態および第２の実施の形態では、共に、外部から入力された映像、音声等の複数のマルチメディアデータを処理する処理手段および送信側端末より送信されてきたマルチメディアデータを処理する処理手段の処理内容に、それぞれ符号化、復号化が含まれている場合について説明したが、この発明ではこれに限るものではない。例えば、受信側の処理においては、ディスプレイへの表示処理のみに適用しても、上述したこの発明の効果が得られる。
【０１７６】
また、第１の実施の形態および第２の実施の形態では、共に、処理する優先度情報を受信側端末に送り、その情報によって受信側端末が優先的に処理する端末を選択する形態である。しかし、もし、明らかに全ての受信側端末での処理能力が足りないということが、予めわかっているのであれば、受信側での優先選択処理に加えて、優先しなくてもよい場合には、送信するデータ量を削減して送るということもできる。
【０１７７】
例えば、第１の実施の形態の場合は音声が、第２の実施の形態の場合は優先条件設定部５１で設定したデータが、それぞれレベル比較部および優先条件確認部５３で認識されなかった場合、フレームレート変換部または解像度変換部などのようなデータ量低減手段によりデータ量を低減したのちに符号化し、パケット化部においてパケット化して送信するようにすることができる。または、データ量を低減するのではなく、新しい映像データを送らないようにしてもよい。
【０１７８】
このようにすれば、この発明の効果に加え、ネットワーク上に流れるデータの量を低減することができるという効果も得られる。
【０１７９】
さらに、第１の実施の形態および第２の実施の形態では、共に、送信側端末および受信側端末とに分けて説明しているが、前述もしたように、マルチメディア会議では、各会議端末装置が送信も受信も行うので、それぞれの会議端末装置が、上述の送信側および受信側の両方の機能を持ち合わせていることは言うまでもない。
【０１８０】
【発明の効果】
以上説明したように、この発明によれば、多地点マルチメディア会議において、会議端末装置の計算機能力が低くて、多量の映像データを処理しきれない場合でも、会議中にユーザが特に意識して操作することなく、常に注目するべき画像を優先的に高品質で表示でき、会議がスムーズに進行できるようにすることができる。
【図面の簡単な説明】
【図１】この発明の参考例としての第１の実施の形態の送信側の構成例を示すブロック図である。
【図２】マイクロホンから入力されるアナログ音声信号の例を示す図である。
【図３】第１の実施の形態における音声の有無の検出方法の例を説明するための図である。
【図４】第１の実施の形態における送信信号の形態の例を説明するための図である。
【図５】第１の実施の形態における送信信号の形態の例を説明するための図である。
【図６】第１の実施の形態の送信側の動作を説明するためのフローチャートである。
【図７】第１の実施の形態の送信側における音声の有無の検出動作を説明するためのフローチャートである。
【図８】第１の実施の形態の受信側の構成例を示すブロック図である。
【図９】第１の実施の形態の受信側での優先端末選択部の動作を説明するための図である。
【図１０】第１の実施の形態の受信側の動作を説明するためのフローチャートである。
【図１１】この発明の実施の形態としての第２の実施の形態の送信側の構成例を示すブロック図である。
【図１２】第２の実施の形態における優先条件の設定選択方法の例を示す図である。
【図１３】第２の実施の形態における優先条件情報の例を説明するための図である。
【図１４】第２の実施の形態における優先条件の設定動作の例を説明するためのフローチャートである。
【図１５】第２の実施の形態の送信側の動作を説明するためのフローチャートである。
【図１６】第２の実施の形態の受信側の構成例を示すブロック図である。
【図１７】第２の実施の形態の受信側での優先端末選択部の動作を説明するための図である。
【図１８】第２の実施の形態の受信側の動作を説明するためのフローチャートである。
【図１９】多地点マルチメディア会議システムの一例を説明するための図である。
【図２０】図１９の会議システムにおける各端末のディスプレイ表示画面の例を示す図である。
【図２１】多地点マルチメディア会議システムの他の例を説明するための図である。
【図２２】図２１の会議システムにおける各端末のディスプレイ表示画面の例を示す図である。
【符号の説明】
１ａ〜１ｅ 多地点マルチメディア会議に参加している会議端末装置
２，１０ ネットワーク
３ ＭＣＵ
４ 会議端末装置のディスプレイ
５ａ〜５ｄ ディスプレイに表示される映像ウィンド
６ａ〜６ｄ ディスプレイに表示される映像ウィンド
１１ｖ 映像情報の入力端子
１１ａ 音声情報の入力端子
１２ 符号化部
１３ パケット化部
１４，３７ ＣＰＵ
１５ レベル検出部
１６ レベル比較部
１７ 多重化部
１８ データ送信部
３１ データ受信部
３２ 分離部
３３ パケット分解部
３４ａ〜３４ｄ バッファメモリ
３５ 復号化部
３６ 優先端末選択部
５１ 設定操作部
５２ 優先条件設定部
５３ 優先条件確認部
５４ 外部メモリ
６１ 優先条件情報記憶部
【発明の属する技術分野】
この発明は、パーソナルコンピュータやワークステーションなどを用いて行う多地点マルチメディア会議システムに適用可能な会議端末装置および音声、映像等の会議関連情報の送信方法に関する。
【０００２】
【従来の技術】
近年、映像や音声などの会議関連情報（以下、映像、音声などの情報をマルチメディアデータという）を、ネットワークを介して伝達することで遠隔多地点間コミュニケーションを行う、いわゆる多地点マルチメディア会議システムが利用されるようになってきている。
【０００３】
図１９は、従来の多地点マルチメディア会議システムの一例の概要を示すものである。図１９において、１ａ〜１ｄは、多地点間マルチメディア会議システムに参加している会議端末装置であり、これら会議端末装置１ａ〜１ｄのそれぞれは、互いに離れた遠隔地であるＡ地点、Ｂ地点、Ｃ地点、Ｄ地点に設置されているが、ネットワーク２を通じて互いに接続されている。そして、ネットワーク２には、さらに、多地点間制御装置（以下ＭＣＵという）３が接続されている。
【０００４】
この図１９の多地点間マルチメディア会議システムにおいては、通常、各会議端末装置１ａ〜１ｄは、カメラで撮像した映像や予め用意した資料映像などの情報と、自分が発言しているときにはその音声を、ネットワーク２を通じてＭＣＵ３に向けて送出する。ＭＣＵ３は、これらの映像や音声などのマルチメディアデータを集め、それらのデータを合成して、ネットワーク２を通じて各会議端末装置１ａ〜１ｄへ配信するようにする。
【０００５】
この場合、ＭＣＵ３は、各会議端末装置１ａ〜１ｄからの映像情報については、それぞれを区分けして、各会議端末装置１ａ〜１ｄのそれぞれにおいて、いずれの端末からの映像情報であるかが分かるように合成する。すなわち、例えば、図２０に示すように、ある会議端末装置のディスプレイ４の画面には、会議に参加している会議端末装置の数の分割画面５ａ〜５ｄからなる映像ウインドウ５が表示されるように、ＭＣＵ３で映像情報の合成がなされる。
【０００６】
ところで、一般的には会議で同時に複数の人間が発言をすることはなく、各会議参加者は、一人の話者（発言者）の映像か、もしくは、話者の提供する映像に注目する。したがって、少なくとも、話者の映像か、もしくは、話者の提供する映像だけは高品質で表示されることが望ましい。なぜなら、話者の表情や唇の動き、もしくは、話者が提供する映像は、話を聞く側の理解を深める手助けをするからである。
【０００７】
しかし、前述したＭＣＵ３を用いて行う多地点マルチメディア会議システムでは、ＭＣＵ３は、各会議端末装置１ａ〜１ｄからの映像情報を均等に取り扱って、前記の分割画像合成の映像ウインドウ５を生成するようにするため、注目したい端末からの映像だけ優先して画質を上げるということはできない。
【０００８】
また、ある会議端末装置からのデータがＭＣＵ３へ到着するのが遅れると、ＭＣＵ３は遅れているデータの到着を待つことになり、他端末すべての映像表示に悪影響を及ぼす。データの到着が遅れている会議端末装置については、その映像品質を低下させて表示してしまうということも可能だが、そのようにすると、当該データの到着が遅れている端末を使用して会議に参加している人が話者である場合には、低品質の画像を見ながら会議を進行させなければならず、会議が非常にしにくくなる。
【０００９】
さらに、現段階でＭＣＵ３は非常に高価であり、できればＭＣＵ３を用いずに多地点マルチメディア会議を行えることが理想である。このＭＣＵ３を用いないという要求を満足するものとして、図２１に示すように、多地点へのマルチメディアデータ配信に、マルチキャストを利用するというアプローチがある。
【００１０】
このマルチキャストを利用するシステムの場合には、会議に参加している会議端末装置１ａ〜１ｅが、それぞれマルチキャストで互いにデータを発信する。そして、会議端末装置１ａ〜１ｅのそれぞれは、会議に参加している他の会議端末装置の数のマルチメディアデータを受信して、その受信データのそれぞれを自端末で処理する。そして、図２２に示すように、会議に参加している他の端末からの映像は、個々に独立して表示するようにする。
【００１１】
図２２は、図２１においてＥ地点の会議端末装置１ｅのディスプレイ４の表示画面を示すもので、６ａ〜６ｄは図２１のＡ地点〜Ｄ地点の端末１ａ〜１ｄより送信される映像情報の復元画像を表示するための独立した映像ウインドウである。
【００１２】
しかし、このマルチキャストを利用するシステムの場合の個々の会議端末装置は、映像のようにデータ量の大きい情報を会議に参加している端末全てについて処理するようにするために、計算機の能力が不足し、たとえ専用のハードウェアを用いても、すべての端末からの映像をスムーズに表示することは非常に困難である。特にマルチメディア会議に参加する端末の数が増えれば、それは一層難しくなる。
【００１３】
送信される映像分の復号器を、各会議端末装置に用意することも考えられるが、これはコスト的にも、ハードウェア規模的にも不利であり、非現実的である。
【００１４】
上記の問題点を解決するための一つの手段として、例えば特開平８−１６３５５６号公報には、受信側端末（ネットワークに接続された複数の会議端末装置のうちの会議関連情報を受信する会議端末装置、以下同じ）にフレームレート変換部を設け、ユーザが受信側端末の計算機処理能力に応じて複数の映像のフレームレートを設定し、注目する必要のない映像のフレームレートを下げるようにすることが提案されている。これによれば、映像を表示する際の計算機パワーの無駄を防止することができるとともに、注目する映像の品質の劣化を防止することができる。
【００１５】
また、例えば特開平９−７４５４８号公報にも、上記の問題点を解決する手段が示されている。すなわち、この特開平９−７４５４８号公報に記載されているシステムにおいては、受信側端末に送信された映像フレームの内、いくつが有効であるかを測定し、その結果を送信側端末（ネットワークに接続された複数の会議端末装置のうちの会議関連情報を送信する、あるいは送信した会議端末装置、以下同じ）に伝達する。送信側端末は、その情報に応じて伝送する動画像のフレームレートを制御する。以上の構成により、受信側端末が常に計算処理能力の範囲で動画像データを処理することができるようにしている。
【００１６】
【発明が解決しようとする課題】
しかしながら、上述の公報に記載の従来技術には次のような課題があった。
【００１７】
すなわち、特開平８−１６３５５６号公報の発明の場合、フレームレートは、受信側端末において、その度毎に、ユーザが自分で操作して設定しなくてはならず、非常に面倒であるという問題がある。例えば、話者が変わるたびに、その話者の端末からのフレームレートを上げるように設定し直していたのでは、とてもわずらわしくて会議に集中することはできない。
【００１８】
また、特開平９−７４５４８号公報の例では、複数の受信側端末の間で処理の能力が異なる場合に、送信側端末がその個々に対応することが難しい。また、一般的に注目したい映像は話者の映像か、もしくは話者の提供する特別な映像であり、その映像が明確に見えないと会議がスムーズに進行せず、会議参加者のストレスとなる。ところが、特開平９−７４５４８号公報の例では、必ずしも受信側端末がその特定の映像を選択的に優先させて高品質で表示するということはできないという問題がある。
【００１９】
この発明は、以上の点にかんがみ、計算機能力が低くて多量の映像データを処理しきれない場合でも、会議中にユーザが特別に意識して操作することなく、常に優先するべき情報を優先的に処理することができるようにした、多地点マルチメディア会議用の会議端末装置を提供することを目的とする。
【００２０】
【課題を解決するための手段】
以上の課題を解決するために、請求項１の発明による会議端末装置は、
ネットワークに接続され、このネットワークを通じて、音声、映像等の会議関連情報を送信するとともに、他の複数個の会議端末装置からの送信信号を前記ネットワークを通じて受信する会議端末装置であって、
会議関連情報の入力を受ける入力部と、
前記会議関連情報に関して、受信側端末で処理を優先させるようにするための優先条件を、ユーザーによる指示を受けて予め設定する優先条件設定手段と、
前記優先条件設定手段で設定された前記優先条件に対応する優先条件情報を、自端末の端末識別子を付加して予め前記ネットワークを通じて他の全ての会議端末装置に送信する手段と、
前記入力部からの会議関連情報について、前記優先条件設定手段で設定された前記優先条件に合致しているか否かを確認する優先条件確認手段と、
前記入力部からの会議関連情報を前記ネットワークに送出する信号に変換する処理を行うとともに、前記優先条件確認手段での確認結果が前記会議関連情報が前記優先条件に合致しているときに、前記ネットワークに送出する信号に、前記優先条件情報と、前記自端末の端末識別子とを付加して、送信信号を生成する情報処理手段と、
前記情報処理手段からの送信信号を前記ネットワークを通じて受信側端末に対して送信するデータ送信手段と、
前記ネットワークを通じて送信されてきた他の会議端末装置からの送信信号を受信するデータ受信手段と、
前記データ受信手段で受信した前記送信信号中に含まれる前記端末識別子を認識して、前記受信したデータを、前記端末識別子に対応した前記他の会議端末装置ごとのバッファメモリに区分けして蓄積するバッファ手段と、
前記バッファ手段に蓄積された受信データの復号化処理を行う復号化手段と、
前記ネットワークを通じて予め送られてくる前記優先条件情報を、前記他の会議端末装置の端末識別子とともに、予め、蓄積する優先条件蓄積手段と、
前記データ受信手段で受信した前記送信信号に含まれる前記優先条件情報と、前記優先条件蓄積手段に蓄積されている優先条件情報のうちの、前記送信信号に含まれる前記端末識別子で識別される前記他の会議端末装置に関する前記優先条件情報とを比較参照して、前記データ受信手段で受信した前記会議関連情報が前記優先条件に合致しているかどうかを判別して、前記優先条件に合致していると判別したときに、当該優先条件に合致していると判別された受信データを蓄積している前記他の会議端末装置用バッファメモリからの情報を、前記復号化手段で優先的に復号化を実行するように制御する優先制御手段と、
を備えることを特徴とする。
【００３２】
【作用】
請求項１の発明は、送信側の会議端末装置であって、予め送信側端末と受信側端末との間で取り決められた特定の情報が、送信する会議関連情報に含まれる場合に、優先度情報が送信信号中に付加される。受信側端末では、この送信信号に含まれる優先度情報により、当該優先すべき送信信号は、他の会議端末装置からの送信信号に優先して処理され、高品質で復号化される。
【００３４】
前述もしたように、会議においては、話者（発言者）の映像か、もしくは、話者の提供する映像に注目するので、少なくとも、話者の映像か、もしくは、話者の提供する映像だけは高品質で表示されることが望ましいが、この請求項１の発明によれば、受信側端末では、例えば、話者となっているユーザーが使用している会議端末装置からの送信信号は、常に、優先して処理され、高品質で復号化されるようにすることができる。
【００３５】
また、この発明の会議端末装置においては、ユーザーによる設定操作に基づく優先条件が参照されて、送信信号に優先条件情報を含ませるか否かが決定されて、当該送信信号が受信側端末に送られる。したがって、必要な場合に送信側でのユーザー指定に応じて優先条件情報が送信信号中に付加され、受信側端末で優先して処理される。
【００３６】
そして、受信側端末では、優先条件情報が付加されている送信信号を、他の送信信号に優先して処理するようになるので、ユーザーが特別に意識して操作することなく、常に優先するべき情報を優先的に処理することができるという効果がある。
【００３７】
また、この発明の会議端末装置においては、予め、ユーザーにより受信側端末で処理を優先させるようにするための条件（優先条件）が設定入力され、優先条件設定手段で設定される。そして、優先条件確認手段で、前記設定された優先条件に入力部から入力された会議関連情報が合致するか否かを判定確認する。情報処理手段は、その確認結果が優先条件に合致していることを示しているときは、送信信号に優先度情報と自端末の識別子とが付加情報として含めるようにする。
【００３８】
受信側端末は、ネットワークを通じてこれを受けると、優先条件情報に基づく判別をすることにより、受信した前記送信信号を優先して処理するか否かを自動的に判定して、復号化処理を実行する。
【００３９】
したがって、ユーザーにより優先条件を設定することができるため、例えばユーザーが高品質で再生する必要のあるとする情報は、ユーザーの意図の通りに再現することができるようになる。
【００４０】
また、この発明においては、優先条件として、どのような情報が送信信号に含まれるときに、受信側端末で優先処理を行わせることを設定することができる。例えば、話者の音声が送信信号に含まれるときのみ、特定の圧縮が施された映像情報が送信信号に含まれるときのみ、のように、ユーザーは設定することができる。例えば、会議映像資料は、ＭＰＥＧ圧縮されたものを使用すると定めた場合に、ＭＰＥＧ圧縮された映像データが送信信号に含まれるときに、自動的に送信信号に優先条件情報が付加挿入され、受信側端末で確実に優先処理させるようにすることができる。
【００４１】
また、優先条件送信手段により、優先条件情報を、自端末の識別子とともに、予め、受信側の会議端末装置に送るようにする。この優先条件情報は、例えば映像、音声などのマルチメディア情報のうちのどのような情報を含むときに、その処理を受信側で優先させるかの情報とすることができる。
【００４２】
したがって、受信側端末では、予め、この優先条件を各送信側の会議情報端末ごとに保存しておくことにより、送信信号を受信したときに、それに含まれる識別子により、いずれの会議端末装置からの送信信号であるかを認識し、そして、その送信信号を構成するマルチメディア情報としてどのような情報を含むかを判別して、予め保存してある当該送信信号を送信してきた会議端末装置についての優先情報を参照することにより、それを優先処理するか否かを自動的に決定することができる。
【００４８】
また、この発明においては、受信側の会議端末装置においては、優先条件蓄積手段に、ネットワークに接続されている他の会議端末装置ごとの優先条件が蓄積されている。この優先条件情報は、会議関連情報のうちの、いずれの情報を含む場合に復号化処理を優先させかという内容の情報である。
【００４９】
優先制御手段では、送信信号を受信したときに、その送信信号を送信してきた会議端末装置について優先条件情報を参照して、その送信信号が当該優先条件情報に合致するか否かを認識する。そして、合致している受信データについては、復号化手段で優先的に復号化を実行するように制御する。
【００５０】
したがって、この発明の場合には、予め受信側の会議端末装置に各会議端末装置ごとの優先条件情報を蓄積しておくことにより、各会議端末装置ごとに異なる優先条件を設定しても、それに対応した優先処理を行うことができる。
【００５２】
【発明の実施の形態】
以下、この発明による会議端末装置のいくつかの実施の形態を、図を参照しながら説明する。以下に説明する実施の形態の会議端末装置は、前述したような多地点マルチメディア会議システムに適用されるものである。そして、この場合の多地点マルチメディア会議システムは、図２１に示したように、ネットワークを通じて多地点に設置された複数個の会議端末装置が互いに接続され、マルチキャストの形式で相互の情報の送受を行うようにする場合である。
【００５３】
［第１の実施の形態］
この第１の実施の形態は、この発明の参考となる会議端末装置を示すもので、多地点マルチメディア会議中に、ユーザーが特に意識して操作することなく、かつ、常に注目するべき画像を優先的に高品質で表示できるようにするために、優先して処理してもらいたい情報を含むデータを送信するときに、優先度情報を付加してマルチメディアデータをパケット化するパケット化手段を備えた送信側端末と、受信情報中に含まれる上記優先度情報を検出して、どの送信側端末からのデータを優先して処理するべきかを選択する優先端末選択手段を備えた受信側端末とによって多地点マルチメディア会議システムを構築する。
【００５４】
そして、この第１の実施の形態では、予め定めた優先データが送信信号に含まれるときに、送信側端末からの送信信号に優先度情報を付加挿入するようにするが、以下に説明する例では、話者（発言者）が使用する会議端末装置からの送信情報を優先して処理するようにするために、優先データは音声情報とされる。
【００５５】
そして、ネットワークに接続される各会議端末装置が、前記の受信側端末の構成および送信側端末の構成を備えるものである。
【００５６】
＜会議端末装置の送信側の構成＞（請求項１、２、７に対応）
図１は、この第１の実施の形態の会議端末装置の送信側の構成例を示すもので、１１ｖは映像情報の入力端子、１１ａは音声情報の入力端子である。また、点線で囲んで示す部分は、情報処理手段を構成する部分である。
【００５７】
映像情報の入力端子１１ｖには、この例の場合には、ビデオカメラ２１の映像信号出力端子が接続される。ビデオカメラ２１は、この会議端末装置のユーザーである会議参加者および説明資料などを含む周辺状況を撮像し、その撮像出力信号を、映像情報の入力端子１１ｖに供給するようにする。
【００５８】
また、音声情報の入力端子１１ａには、会議参加者である当該会議端末装置のユーザーの発言を主として収音するためのマイクロホンの音声信号が供給される。
【００５９】
入力端子１１ｖを通じて入力された映像信号と、入力端子１１ａを通じて入力された音声信号とは、符号化部１２に供給されて、デジタル信号に変換されてそれぞれ符号化される。なお、説明の簡単のため、図１の例では、符号化部１２は、映像信号の符号化部と音声信号の符号化部とをまとめて示している。
【００６０】
この実施の形態における映像情報および音声情報のコーデック方式に関しては、一般にこのようなマルチメディア会議システムで用いられている、ＩＴＵ−Ｔ（International Telecommunication Union-Telecommunication ）で規格化されているコーデック方式が用いられる。すなわち、映像信号については、Ｈ．２６１やＨ．２６３が用いられ、また、音声信号についてはＧ．７１１、Ｇ．７２２やＧ．７２８などが利用される。
【００６１】
これら複数のコーデック方式のうちのどれを選択するべきかということは、会議端末装置を接続するネットワークに依存し、例えばイーサネットに接続するのであれば、映像および音声のコーデックに、それぞれＨ．２６３、Ｇ．７１１を利用する。
【００６２】
もちろん、ＭＰＥＧやまったく別のコーデックを利用しても構わないし、複数のコーデックを用意しておいて選択して利用する形態にしてもよい。なお、このように複数のコーデックを選択して利用する場合において、例えば映像のコーデックでは多くの場合においてＤＣＴ（Discrete Cosine Transform ）を使うので、ＤＣＴを実行するモジュールだけは、コーデックの形式によらず、共通に利用できるような形態にしておくことが望ましい。
【００６３】
符号化部１２で符号化された映像データおよび音声データは、パケット化部１３に供給される。
【００６４】
また、マイクロホン２２から入力される音声信号は、レベル検出部１５にも供給されて、音声信号レベルが検出される。このレベル検出部１５では、例えば、図２に示すような入力アナログ音声信号を適当な時間間隔でサンプリングし、図３に示すように８ビットのディジタル信号にＡ／Ｄ変換して、音声信号レベルを時系列的に検出する。
【００６５】
このレベル検出部１５からの時系列的に検出された音声信号レベルは、逐次、レベル比較部１６に送られ、あらかじめ設定してある基準レベルと比較されて、ユーザーの発言の有無、すなわち、発言音声の有無が検出される。この基準レベルは、ノイズと、ユーザーが発言した音声とを識別して検出することができるような値に設定される。この基準レベルは、使用するマイクロホンや音源ボードによって変わってくる可能性があるので、各会議端末装置で最初に設定を行い、経験的に求められるノイズのレベルから基準レベルを決定するようにする。したがって、各会議端末装置ごとに基準レベルは異なる値になる場合もある。
【００６６】
レベル比較部１６では、レベル検出部１５で検出された音声信号のレベルが、基準レベルよりも高いときは、この送信側端末から発信されるマルチメディアデータとして音声情報が含まれていると判断する。すなわち、この送信側端末のユーザーが発言中であると判断する。
【００６７】
また、レベル比較部１６は、レベル検出部１５で検出された音声信号のレベルが、基準レベルよりも低いときは、この送信側端末から発信されるマルチメディアデータとして音声が含まれていない、すなわち、送信側端末のユーザーは発言をしていないと判断する。
【００６８】
そして、レベル比較部１６は、その判断結果の情報をパケット化部１３に供給する。
【００６９】
パケット化部１３は、符号化部１２で符号化されたマルチメディアデータをパケット化する。また、このようなマルチメディア会議システムでは、例えばアプリケーションソフトウェアの端末間共有などの機能を備えている場合が多いので、パケット化部１３では、メインバスを通ってＣＰＵ１４から送られてくる、このような機能に関わる映像や音声以外のデータも同様にパケット化する。
【００７０】
そして、パケット化部１３は、前記マルチメディアデータについてのパケット化を行う際に、前記レベル比較部１６からの前記音声信号の有無の判断結果を参照して、送信すべきデータに音声信号が含まれると認識したときには、認識した音声情報と同期して送信するデータのすべてについて、優先度情報を付加する。この優先度情報は、この第１の実施の形態では、受信側端末において、送信側端末から送信されてきたデータに音声が含まれていて、それが優先的に処理されるべきデータであるということを通知するためのものである。
【００７１】
そこで、この第１の実施の形態では、パケット化部１３では、各パケットのヘッダ部に、その優先度情報を含ませるようにする。図４は、この実施の形態の場合のパケットの構造を模式的に示すもので、各パケットは、ヘッダ部とデータ部とからなる。
【００７２】
ヘッダ部には、当該パケットが映像、音声などの、いずれのマルチメディアデータのパケットであるかを示すパケット識別子ＰＩＤ（パケットＩＤ）や、当該データが発生した時間を示すタイムスタンプＴＳや、自己の端末の識別子ＴＩＤ（端末ＩＤ）に加えて、前記優先度情報ＰＲが含まれる。タイムスタンプＴＳを参照することで、同期する情報、すなわち、同じフレーム内の情報であることを検知することができる。また、端末の識別子ＩＤとしては、例えばネットワーク１０上の当該端末のアドレスが利用される。これらの情報の、例えば、ＩＰ（インターネットプロトコル）では、そのデータのヘッダなどに含まれているので、それを使用することができる。
【００７３】
優先度情報ＰＲは、例えば１ビットの情報とされ、例えば、送信信号に音声情報が含まれるときには、その優先度情報ＰＲのビットが「１」とされ、送信信号に音声情報が含まれないときには、その優先度情報ＰＲのビットは「０」とされる。したがって、送信信号に音声情報が含まれるときには、前述したように、音声情報のパケットおよび、その音声情報パケットと同期して送信されるすべてのパケットのヘッダ部の優先度情報ＰＲのビットは「１」となる。この情報は、例えば前述したＩＰのヘッダに用意されているユーザー用のビットなどを割り当てて組み込むようにすることができる。
【００７４】
こうしてパケット化された各データは、多重化部１７に供給される。この多重化部１７では、受信側端末で分離した時に複数のマルチメディアデータ、例えば映像と音声が同期できるように、図５に示すような多重化を行う。図５で、一つのフレーム内にある映像パケットおよび音声パケットが同時刻に発生したデータである。それぞれが１つのパケットに納まりきれるとは限らず、複数のパケットになる場合もある。なお、図５の各パケットの先頭の部分に斜線を付して示したのは、各パケットのヘッダ部である。
【００７５】
以上のようにして、多重化部１７で多重化されたマルチメディアデータのパケットデータは、データ送信部１８に渡され、ネットワーク１０に送出され、受信側の会議端末装置に送信される。
【００７６】
図６および図７は、以上説明した会議端末装置の送信側の動作のフローチャートを示すものである。すなわち、会議端末装置は、映像、音声などのマルチメディアデータの入力を受ける（ステップＳ１）と、これらマルチメディアデータの符号化を行う（ステップＳ２）とともに、入力音声有無の検出チェックを行う（ステップＳ３）。
【００７７】
図７のフローチャートは、入力音声有無の検出チェックの流れを示すものである。すなわち、入力端子１１ａからのアナログ音声信号をサンプリングし（ステップＳ１１）、そのサンプリング値をＤ／Ａ変換して音声レベルを検出する（ステップＳ１２）。そして、各Ｄ／Ａ変換値を基準レベルと比較し（ステップＳ１３）、その比較の結果、Ｄ／Ａ変換値が基準レベルを超えているか否か判別し（ステップＳ１４）、基準レベルを超えていれば音声ありを示す情報を検出チェック結果として出力し（ステップＳ１５）、基準レベルを超えていなければ音声なしを示す情報を検出チェック結果として出力する（ステップＳ１６）。
【００７８】
以上のようにしてステップＳ３で入力音声有無の検出チェック結果が得られると、入力音声があるか否かの判断を行う（ステップＳ４）。そして、入力音声がある、つまり、当該会議端末装置のユーザーが発言をしていると判断したときには、ステップＳ５に進んで、マルチメディアデータの各パケットのヘッダ部に付加する優先度情報を“優先”の状態（優先度情報ＰＲのビットを「１」）にし、また、入力音声がないと判断したときには、ステップＳ６に進んで、各パケットのヘッダ部に付加する優先度情報を“非優先”の状態（優先度情報ＰＲのビットを「０」）にする。
【００７９】
次に、マルチメディアデータの各パケットを多重化し（ステップＳ７）、その多重化したデータをネットワーク１０に送出する（ステップＳ８）。
【００８０】
＜会議端末装置の受信側の構成＞（請求項１０、１２に対応）
次に、会議端末装置の受信側について説明する。図８は、この発明における多地点マルチメディア会議端末装置のデータ受信および復号化処理部分の構成図の一例である。この図８において、点線で囲んだ部分は、情報処理手段を構成する部分である。
【００８１】
データ受信部３１は、ネットワーク１０を通って送られてきた多重化されたマルチメディアデータのパケットを受信する。これらのデータは分離部３２へ送られ、多重化されているパケットを、映像パケット、音声パケット、アプリケーションパケットなどの各メディアごとに分離する。
【００８２】
分離部３２で分離された送信側端末から送信されてきた各メディアごとのパケットは、パケット分解部３３において分解される。前述したように、各パケットには、送信側端末の識別子ＩＤ（送信側端末のアドレス）が付加されているので、ここで、どの送信側端末から送信されてきたマルチメディアデータであるかが判断される。
【００８３】
パケットを分解して取り出された映像および音声のデータは、パケット分解部３３からバッファメモリ３４ａ〜３４ｄのうちの送信側端末に対応するバッファメモリに格納される。バッファメモリ３４ａ〜３４ｄは、ネットワーク１０に接続されている会議端末装置の数分、用意されているものである。図８の例は、図２１におけるＥ地点の会議端末装置の受信側の構成例であって、他のＡ地点〜Ｄ地点の会議端末装置に対応して４つのバッファメモリ３４ａ〜３４ｄが設けられており、送信側端末ごとにマルチメディアデータが仕分けされて、一時蓄積される。さらに、バッファメモリ３４ａ〜３４ｄのそれぞれには、映像および音声などのメディアごとに区別されて、情報が蓄積されている。
【００８４】
バッファメモリ３４ａ〜３４ｄからの映像および音声データは、１フレーム分のデータ単位で、復号化部３５に送られて復号化処理される。復号化部３５は、この実施の形態の場合、バッファメモリ３４ａ〜３４ｄからのデータのすべてを同時に並列処理する構成ではなく、バッファメモリ３４ａ〜３４ｄのうちのいずれか一つからの１フレーム分のデータづつを処理するものである。
【００８５】
バッファメモリ３４ａ〜３４ｄのいずれかに１フレーム分のデータが蓄積されると、そのバッファメモリから、そのことが復号化部３５に伝えられる。復号化部３５では、バッファメモリ３４ａ〜３４ｄから１フレーム分のデータが蓄積されたことの通知が到来すると、その通知が到来したバッファメモリの１フレーム分のデータの復号化処理が可能な状態になったと認識する。そして、そのバッファメモリの１フレーム分のデータの復号を行うようにする。
【００８６】
この場合に、後述するような優先処理の状況でないときには、復号化の順番は、４個のバッファメモリで均等となるように、１フレーム分のデータが復号化される。したがって、このときには、４個の会議端末装置１ａ〜１ｄからの映像の画質に差（この例の場合には、フレーム間引きがあるか否か）は生じない。
【００８７】
この図８では、説明の簡単のために、復号化部３５は映像および音声の復号化部を一体として、まとめて示しているが、実際には、映像情報用の復号化部と、音声情報用の復号化部がある。この復号化部３５は、送信側端末の符号化部１２に採用した符号化方式に対応したものである。もちろん、符号化方式として複数のコーデックを選択して利用する形態の場合には、それに対応して複数のデコーダの機能を復号化部３５が有するように構成する。その場合には、送信側と同様に、コーデックの形式によらず大抵の場合、逆ＤＣＴを使うので、逆ＤＣＴのモジュールだけは、コーデックによらず利用できるような構成にしておくことが望ましい。
【００８８】
また、実際には音声の復号化に比べて映像の復号化は処理に時間がかかるので、例えば遅延回路を挿入して映像と音声の処理遅延の遅延差を無くし、２つのメディア間の同期を取るというようなことが行われるが、この点についてもこの図８では省略してある。
【００８９】
冒頭の従来の技術の欄でも述べたように、復号化部３５の処理能力が非常に高く、バッファメモリ３４ａ〜３４ｄに格納されたデータを滞りなく処理できれば問題ないが、マルチメディア会議に参加している端末の数が多いと復号化部３５が処理しなければならないデータも増大し、現実的には処理しきれなくなる。
【００９０】
そこで、この実施の形態では、送信信号の各パケットごとに含まれる前記優先度情報に基づいて、送信側端末から送られてきた情報が、復号化部３５で優先処理すべきデータがあるときには、復号化部３５で、そのデータを優先的に処理するように制御する。
【００９１】
すなわち、パケット分解部３３は、受信した送信信号の各パケットのヘッダ部に挿入付加されている優先度情報ＰＲを取り出し、端末識別子ＩＤとともに、優先端末選択部３６に、その取り出した優先度情報ＰＲを送る。優先端末選択部３６は、この優先度情報ＰＲを解析し、受信した送信側端末からの送信信号が優先して処理すべきものであるか否か判断する。すなわち、優先度情報ＰＲのビットが「１」であるときには、優先して処理すべきと判断し、「０」であれば、優先処理の必要なしと判断する。そして、その判断結果を情報は、復号化部３５に送る。
【００９２】
この実施の形態の場合、優先端末選択部３６からの判断結果の情報は、復号化部３５での４個のバッファメモリ３４ａ〜３４ｄに関する優先処理指示に関するもので、４ビットの情報とされる。この４ビットの優先処理指示情報の各ビットは、４地点Ａ〜Ｄの各会議端末装置から送られてきた情報を優先処理するか否かの情報を示すもので、この例では、ビットが「１」となっている端末からの情報の優先処理、ビットが「０」となっている端末からの情報は非優先とされる。
【００９３】
図９は、この４ビットの優先処理指示情報の例を説明するための図である。優先端末選択部３６は、パケット分解部３３からの優先度情報を解析することで、図９の表のような形式で各バッファメモリからの情報の優先、非優先の管理を行う。図９において、○はその送信側端末を優先させることを意味し、×は優先させなくてもよいことを意味する。そして、４ビットの優先処理指示情報は、前者（○）に「１」に、後者（×）に「０」を対応させることにより生成する。
【００９４】
図９の例の場合、時点ｔ１，ｔ２，ｔ３では、地点Ａの端末からの情報を優先して処理する状況になっており、時点ｔ３以降、時点ｔｎまでは、いずれの端末からの情報も非優先の状況となっていることを示している。そして、時点ｔｎでは、Ｂ地点の会議端末装置からの送信情報と、Ｃ地点の会議端末装置からの送信情報とが優先して処理されるべき状況となっている。
【００９５】
復号化部３５では、優先端末選択部３６からの４ビットの優先処理指示情報が、いずれかの端末からの情報を優先して処理することを指示している場合には、もし他の端末用のバッファメモリから１フレーム分のデータが蓄積されたことの通知が到来したとしても、優先端末選択部３６からの優先処理指示情報の指示通りに、優先すべき端末からの情報の復号化処理を続けて行うようにする。
【００９６】
図９の時点ｔ１，ｔ２，ｔ３では、バッファメモリ３４ａからの情報が優先されて、復号化部３５において優先復号化処理されることになる。
【００９７】
なお、図９の時点ｔｎのように、優先処理すべき端末が複数個になった場合には、それらの端末の間で交代に復号化処理するようにする。４ビットの優先処理指示情報が「００００」であるときには、優先的に処理する必要がないので、復号化部３５では、４個のバッファメモリ３４ａ〜３４ｂのデータについて、予め定めた順序で、均等に復号化処理を行うようにする。
【００９８】
以上のようにして復号化部３５で復号化された映像および音声のデータは、それぞれ出力端子３８ｖおよび３８ａを通じて、ディスプレイ４１およびスピーカ４２へと出力されて、再生される。
【００９９】
なお、パケット分解部３３において、パケット分解されて取り出された、例えばアプリケーションソフトウェアの端末間共有のような機能に関わる、計算を必要とするデータは、メインバスを通り、ＣＰＵ３７へと送られる。
【０１００】
図１０は、以上説明した第１の実施の形態の会議端末装置の受信側の動作のフローチャートを示すものである。
【０１０１】
すなわち、会議端末装置は、ネットワーク１０から、いずれかの端末からの送信信号である多重化データを取り込み（ステップＳ２１）、その取り込んだ多重化データをパケットごとに分離する（ステップＳ２２）。ついで、各パケットを分解し（ステップＳ２３）、ヘッダ部の付加情報のパケットＩＤや端末ＩＤなどのチェックを行い（ステップＳ２４）、送信側端末に対応したバッファメモリに、音声データや映像データを分離して格納する（ステップＳ２５）。
【０１０２】
このバッファメモリへの格納に伴って、ヘッダ部の優先度情報ＰＲのチェックを行い（ステップＳ２６）、前述したような自己以外の他の会議端末装置の数に対応したビット数、この例では４ビットの信号を生成し、復号化部３５に供給する（ステップＳ２７）。
【０１０３】
復号化に当たっては、４ビットの信号の各ビットの状態を確認して、優先すべき送信側端末からの送信データがあるか否か判断する（ステップＳ２８）。優先すべき送信側端末からのデータがあると判断したときには、その優先すべき情報の復号化を、他の端末からの情報に優先して実行し（ステップＳ２９）、その出力データを出力し、映像および音声を再生する（ステップＳ３３）。
【０１０４】
また、優先される送信側端末からの送信データがないと判断したときには、復号化中か否か判断し、復号化中であれば、復号化部３５での処理が終了するのを待ち（ステップＳ３１）、復号化部３５での処理が終了したら、４個のバッファメモリ３４ａ〜３４ｄからのデータを機会均等に復号化処理するようにする（ステップＳ３２）。そして、その復号結果を出力し（ステップＳ３３）、映像および音声を再生する。
【０１０５】
以上のような構成の多地点マルチメディア会議端末を用いれば、会議端末装置の計算機能力が低くて、多量の映像などのデータを処理しきれない場合でも、会議中にユーザが特に意識して操作することなく、常に注目するべき画像を優先的に高品質で表示でき、会議がスムーズに進行できるようにすることができる。すなわち、注目する画像や音声は、送信されてきたものが、ほぼすべて復号化されて再生されるようになるためである。
【０１０６】
これに対して、優先指定されていない端末からの情報は、他の端末からの情報が優先処理されているために、送信されてきても、対応するバッファメモリに蓄積しきれなくなり、その情報を持ったデータは、廃棄されることになる場合が生じる。そして、優先指定されている端末がなくなると、当該非優先の端末についての映像情報の復号化が実行されるようになる。そのため、当該非優先の端末の映像出力画像は、いわゆる駒落としのような状態になるが、前述したように、もともと、非優先の端末からの画像情報は、ユーザーがその出力画像に注目する度合いが少ないので、会議に支障はほとんど生じない。
【０１０７】
特に、この第１の実施の形態の上述の例では、音声情報の有無を判別して、音声情報が送信信号に含まれる場合、つまり、会議において、発言しているユーザーからの情報を優先処理するようにしたので、受信側端末での再生において、発言者の発言内容がとぎれたり、発言者の動作や、提示する資料の映像が低品質になるのを防止することができる。
【０１０８】
なお、上述の図１の送信側端末の構成において、レベル検出部１５およびレベル比較部１６では、ノイズの影響を除去して、音声信号の有無を確認することができればよいので、これらレベル検出部１５およびレベル比較部１６以外の別の手段によって、音声信号の有無を検出するように構成することももちろんできる。
【０１０９】
また、優先度情報ＰＲは、ヘッダ部ではなく、各パケットのデータ部の先頭部分などの映像情報や音声情報などの情報とは区別できる部位に付加するようにすることもできる。
【０１１０】
また、優先度情報ＰＲは、１ビットである必要はなく、複数ビットで構成されていてももちろんよい。また、優先度情報ＰＲは、常にヘッダ部やデータ部に挿入付加するのではなく、音声情報パケットおよび、その音声情報パケットと同期して送信されるパケットにのみ、挿入付加するようにしてもよい。その場合には、受信側端末では、パケットのヘッダ部やパケットのデータ部に優先度情報が存在するか否かを判別するだけで、優先すべき情報であるか否かを判別することができる。
【０１１１】
さらに、上述の説明では、音声の有無により、優先とするか否かを決めるようにしたが、例えば、特定の画像情報、例えば会議に資料として提出したい情報は、予めＭＰＥＧ圧縮して保存するように規定する場合に、当該ＭＰＥＧ圧縮画像情報が送信信号に含まれる場合に、上述したような優先度情報を送信信号に含ませて送信するように構成することもできる。つまり、優先とするか否かは、音声に限らず、予め定めた情報が送信信号に含まれるか否かにより決定することもできるものである。
【０１１２】
［第２の実施の形態］
上述した第１の実施の形態では、送信側端末から送信されるマルチメディアデータの中に音声などの特定の情報が含まれていた場合に、優先度情報をパケットに付加し、受信側端末がそれを認識して処理する優先度を決定するという形態について説明した。
【０１１３】
しかし、必ずしも処理を優先させる規準が、予めすべての会議端末装置間で共通の特定の情報によるとは限らず、臨機応変に各会議端末装置のユーザが変更したい場合もある。具体的には、例えば、あるユーザーが展示会等で撮影した映像を各受信側端末に提示しながら、その映像に対して説明をしたいとするような場合、少なくともその撮影映像はフレーム落ちなどのない高品質で表示させるようにしたい要望がある。
【０１１４】
この点にかんがみ、以下に説明するこの発明による実施形態としての第２の実施の形態では、ユーザーにより優先指定の条件を設定できるようにする。この優先条件の例として、以下の説明においては、ユーザーが指定した特定の情報が送信信号に含まれるときに、受信側での処理の優先を要求するものとする。優先条件として、例えば、特定ソースの映像が含まれるときや、発言音声が含まれるときなどが、ユーザーにより指定される。
【０１１５】
そして、この第２の実施の形態では、優先条件を送信側において記憶しておき、送信すべき信号がその優先条件に合致しているときに、その優先条件の情報を送信信号に付加して受信側端末に送信するようにする。
【０１１６】
また、送信側端末は、設定した優先条件の情報を、例えば会議開始前などの適当な時点において、予め受信側端末に送信しておく。受信側端末では、この優先条件情報を受信して送信側端末ごとに保存格納しておく。そして、受信側端末で、送信側端末からの送信信号を受信したときに、その受信した送信信号中に含まれる優先条件情報を、予め受信して記憶した優先条件情報と比較して、その一致を確認することにより、優先して処理すべきものであるかどうかを確定し、優先処理するようにする。
【０１１７】
＜会議端末装置の送信側の構成＞（請求項３、４、５、７に対応）
図１１は、この第２の実施の形態における多地点マルチメディア会議端末装置の送信側端末部分、すなわち、符号化処理およびデータ送信部分における構成図の一例である。点線で囲んだ部分は、情報処理手段を構成する部分である。
【０１１８】
この第２の実施の形態の送信側の構成においては、前述の第１の実施の形態のレベル検出部１５とレベル比較部１６は設けられず、その代わりに、優先データ設定操作部５１と、優先条件設定部５２と、優先条件確認部５３と、外部メモリ５４とを設けた構成となっている。その他の構成は、第１の実施の形態の図１の場合の構成と同様である。
【０１１９】
外部メモリ５４は、会議資料として提供したい画像情報を格納しておくもので、この例では、当該画像情報は、ＭＰＥＧ圧縮データとして格納しておくものである。
【０１２０】
設定操作部５１は、受信側端末で優先して処理させたい条件を設定入力するためのものである。この例では、どのようなデータを自端末から送信した場合に受信側端末で特に優先して処理してほしいかという情報を設定入力するようにする。
【０１２１】
この実施の形態の場合には、送信する情報としては、カメラ２１からの会議参加者の撮像映像データと、マイクロホン２２からの音声データ（発言）と、ＣＰＵ１４からのデータと、外部メモリ５４からのＭＰＥＧ圧縮データ形式の資料映像データとの４種のデータが想定されている。優先条件の設定は、この４種のデータのうちのどれが含まれているときに、受信側端末で優先して処理してほしいかを設定することができるようにされる。
【０１２２】
例えば、音声情報が含まれている場合に優先してほしいときは、「音声情報」と設定入力し、前述のＭＰＥＧ圧縮された映像情報が含まれている場合に優先してほしい時には、「ＭＰＥＧ情報」と設定入力するという具合に設定する。
【０１２３】
この設定操作部５１は、キーボードやマウス、またはペンタブレットのような入力デバイスで構成され、これを用いて優先条件である前記の情報の選択設定がなされる。例えば、最も簡単で使いやすい形態として、画面上に、図１２に示すようなプルダウンメニューＭＮを映出し、このプルダウンメニューＭＮから選択させる方法が採用される。
【０１２４】
設定操作部５１により選択設定された、受信側で優先処理してもらいたいデータに関する情報（以下、優先条件情報という）は、優先条件設定部５２に設定される。この優先条件設定部５２はメモリを備え、優先条件情報がメモリに格納される。この優先条件の設定は、会議が始まる前に、この会議端末装置のユーザーにより行われる。
【０１２５】
そして、ユーザーが設定した優先条件情報は、ネットワーク１０を介して複数の受信側端末へ、例えば電子メールのような形態で送信され、後述するように各受信側端末の優先条件情報記憶部に、端末ＩＤとともに、記憶される。優先条件設定部５２のメモリに保存された優先条件情報は、優先条件確認部５３にも供給される。
【０１２６】
優先条件確認部５３には、送信される可能性のある情報のすべてが入力される。すなわち、入力端子１１ｖおよび１１ａからの映像データおよび音声データと、外部メモリ５４からのＭＰＥＧデータと、ＣＰＵ１４からのデータとが入力される。
【０１２７】
この優先条件確認部５３は、会議中に自端末から送信信号をネットワーク１０を通じて他の端末に送信するときに、前記４種の入力信号の有無をそれぞれ検出することにより、当該送信信号がどのようなマルチメディア情報を含んでいるかを認識し、認識した送信信号が、以上のようにして設定された優先条件を参照した結果、優先条件と一致しているマルチメディアデータタイプのときには、その優先条件情報をパケット化部１３に送り、それを送信信号に付加して、ネットワークに送出するように、パケット化部１３に依頼する。
【０１２８】
また、この例では、優先条件確認部５３は、認識した送信信号が、設定された優先条件と一致していないときには、優先指定なしの優先条件情報をパケット化部１３に送り、それを送信信号に付加して、ネットワークに送出するように、パケット化部１３に依頼する。
【０１２９】
パケット部１３は、この第２の実施の形態では、符号化部１２からの映像データおよび音声データのパケット化と、ＣＰＵ１４からのデータ、例えば、アプリケーションソフトウェアの端末間共有などの機能に関わるデータのパケット化、外部メモリ５４からのＭＰＥＧデータのパケット化とを行う。
【０１３０】
そして、そのパケット化の際に、各パケットには、優先度情報を、前述の第１の実施の形態の場合と同様にして付加挿入する。この第２の実施の形態の場合の優先度情報は、受信側端末で当該データを優先して処理すべきか否かを判定する際に使用される情報であり、この第２の実施の形態では、前述した優先条件確認部５３から送られてくる優先条件情報がそのまま使用される。
【０１３１】
すなわち、パケット化部１３は、送信信号が設定されている優先条件に適合する場合には、優先条件確認部５３からの設定されている優先条件情報と等しい情報を、前記優先度情報として、各パケットのヘッダ部に、前述の第１の実施の形態の場合と同様にして付加挿入することになる。また、送信信号が設定されている優先条件に適合していない場合には、優先条件確認部５３からの優先指定なしの情報が、付加する優先度情報として、各パケットのヘッダ部に、同様にして付加挿入されることになる。
【０１３２】
この実施の形態では、優先条件情報は、設定された情報を含む送信マルチメディアデータのタイプとして表される。すなわち、図１３は、マルチメディアデータタイプと、優先条件情報との対応関係を示すものである。この例では、マルチメディアデータタイプとして４種のタイプを想定したので、優先条件情報は、２ビットで表される場合として示している。優先条件が、４種以上を設定可能であれば、優先条件情報は、３ビット以上の情報として構成するようにするのはもちろんである。
【０１３３】
図１３の表に示すように、この例では、設定操作部５１で、優先条件の指定をしなかった場合には、
図１３の表に示すように、この例で想定されるマルチメディアデータタイプは、
▲１▼優先条件の指定無し
▲２▼ＭＰＥＧ映像を含む場合を優先
▲３▼発言音声を含む場合に優先
▲４▼ＭＰＥＧ映像と発言音声を含む場合に優先
の４種とされる。
【０１３４】
そして、▲１▼優先条件の指定無しのマルチメディアデータタイプのときは、２ビットの優先条件情報は「００」、▲２▼ＭＰＥＧ映像を含むマルチメディアデータタイプのときは、２ビットの優先条件情報は「０１」、▲３▼発言音声を含むマルチメディアデータタイプのときは、２ビットの優先条件情報は「１０」、▲４▼ＭＰＥＧ映像と発言音声を含むマルチメディアデータタイプのときは、２ビットの優先条件情報は「１１」、とされる。
【０１３５】
優先条件設定部５２のメモリには、設定操作部５１での設定に応じた２ビットの優先条件情報が書き込まれ、また、同じ情報がネットワーク１０を通じて受信側端末に送信され、その優先条件情報記憶部に記憶される。
【０１３６】
図１４は、上述した各会議端末装置の送信側における優先条件設定部５２の動作のフローチャートである。
【０１３７】
すなわち、まず、設定操作部５１を通じてのユーザーの優先条件の設定選択入力を受け付ける（ステップＳ４１）。そして、設定された優先条件を判定し（ステップＳ４２）、２ビットの優先条件情報をそのメモリに保存する（ステップＳ４３）。次いで、ネットワークを通じて他のすべての受信側端末に、前記２ビットの優先条件情報を、例えば電子メール形式で送信する。以上で、優先条件の設定の終了である。
【０１３８】
例えば、ユーザーによりＭＰＥＧデータが選択設定された場合には、優先条件情報として、優先条件設定部５２のメモリに、優先条件として「０１」が記憶され、この２ビットの情報が他の受信側端末のすべてにネットワーク１０を通じて送られ、各受信側端末に記憶保持されるようにされる。
【０１３９】
その後、会議が始まると、前述したように、優先条件確認部５３は、会議中に自端末から送信信号をネットワークを通じて他の端末に送信するときに、当該送信信号がどのようなマルチメディア情報を含んでいるかを認識し、この優先条件確認部５３での認識結果に応じて、パケット化部に、前述した優先度情報が付加されて受信側端末に向けて送出される。
【０１４０】
この第２の実施の形態の会議端末装置の送信側の会議開始後の動作を、図１５のフローチャートを参照しながら説明する。
【０１４１】
すなわち、会議が始まると、前述した第１の実施の形態と同様に、送信側端末に付属しているカメラ２１およびマイクロホン２２から映像データおよび音声データの入力を受け（ステップＳ５１）と、これらマルチメディアデータの符号化を行う（ステップＳ５２）。
【０１４２】
この符号化と並行して、優先条件確認部５３において、４種の入力信号の有無のチェックにより、送信信号のチェックを行い（ステップ５３）、優先条件設定部５２に予め設定されている優先条件に合致しているか否かの判断を行う（ステップＳ５４）。
【０１４３】
そして、設定されている優先条件に合致していると判断したときには、優先条件確認部５３から、優先条件設定部５２のメモリに格納されている優先条件情報をパケット化部１３に送って、パケット化部１３でその優先条件情報を各パケットのヘッダ部に付加して、各マルチメディアデータのパケットを生成する（ステップＳ５５）。
【０１４４】
例えば、ＭＰＥＧデータが送信信号に含まれるときに優先と設定されていたときには、外部メモリ５４からの情報、つまり、ＭＰＥＧデータの入力を確認すると、送信信号が優先条件と一致しているとして、その２ビットの情報「０１」が、優先度情報として各パケットのヘッダ部に付加されて、各データパケットが生成される。
【０１４５】
一方、ステップＳ５４での判断において、設定されている優先条件に合致していないと判断したときには、この例では、優先条件確認部５３は「指定無し」を意味する「００」をパケット化部１３に送るので、パケット化部１３では、その２ビットの情報「００」が、優先度情報として各パケットのヘッダ部に付加されて、各データパケットが生成される（ステップＳ５６）。
【０１４６】
次に、マルチメディアデータの各パケットを多重化し（ステップＳ５７）、その多重化したデータをネットワーク１０に送出する（ステップＳ５８）。なお、この例の場合には、受信側端末で分離した時に複数のマルチメディアデータ、例えば、この例の場合には、映像と音声に加えてアニメーションが同期できるような多重化を行うことができる。
【０１４７】
＜会議端末装置の受信側の構成＞（請求項１１、１２に対応）
次に、会議端末装置の受信側について説明する。図１６は、この発明における多地点マルチメディア会議端末装置のデータ受信および復号化処理部分の構成図の一例である。この図１６において、点線で囲んだ部分は、情報処理手段を構成する部分である。
【０１４８】
この図１６の構成で、図８に示した第１の実施の形態の場合の会議端末装置のデータ受信および復号化処理部分の構成と異なるのは、この第２の実施の形態では、優先条件情報記憶部６１が設けられる点と、優先端末選択部３６の動作が異なる点である。その他の構成は、第１の実施の形態の図８の場合とほぼ同様であるので、その詳細な説明は省略する。
【０１４９】
すなわち、この第２の実施の形態においては、優先条件情報記憶部６１には、会議の開始に先立ち、ネットワーク１０およびデータ受信部３１を通じて、例えば電子メール形式で送られてくる、各送信側端末で設定された優先条件情報が各送信側端末ごとに記憶される。なお、前述したように、パケットヘッダには、端末ＩＤとしてネットワーク上のアドレスが使用されるが、電子メールアドレスは、当該ネットワーク上のアドレスそのものであるので、優先条件情報記憶部６１には、端末ＩＤをインデックスとして、各送信側端末の優先条件情報が記憶されていることなる。
【０１５０】
この優先条件情報記憶部６１に記憶された優先条件情報は、優先端末選択部３６に供給される。すなわち、優先端末選択部３６は、送信信号から取り出したパケットをパケット分解部３３でパケット分解して得られる端末ＩＤおよび優先度情報を、パケット分解部３３から取得し、当該端末から到来した信号は優先処理すべきかどうかを、優先条件情報記憶部６１に記憶されている当該端末の優先条件情報を参照することにより決定する。そして、その決定結果により、前述の第１の実施の形態の場合と同様に、優先端末選択部３６は、復号化部３５に供給する４ビットの優先処理指示情報を生成する。
【０１５１】
図１７は、この第２の実施の形態において、優先端末選択部３６で４ビットの優先処理指示情報が生成される例を説明するための図である。優先端末選択部３６は、パケット分解部３３からの優先度情報を、優先条件情報記憶部６１からの優先条件情報を参照して解析することで、図１７の表のような形式で各バッファメモリからの情報の優先、非優先の管理を行う。この場合も第１の実施の形態の場合と同様に、４ビットの優先処理指示情報のビットが「１」である端末は優先すべきもの、「０」である端末は優先する必要のないものをそれぞれ意味するものである。
【０１５２】
図１７の例は、地点Ｅの会議端末装置の場合で、地点Ａ，ＢおよびＤの会議端末装置では優先条件の指定をしなかったので、優先条件情報記憶部６１のそれらの会議端末装置のそれぞれの優先条件情報の記憶値は、「００」となっており、また、地点Ｃの会議端末装置では、ＭＰＥＧ映像データが送信信号に含まれるときに、優先処理をしてもらいたいとの設定がなされているので、その会議端末装置Ｃの優先条件情報の記憶値のみが、「０１」となっている場合である。
【０１５３】
この場合、時点ｔ１，ｔ２，では、いずれの地点の端末からも優先指定無しで送信信号が到来している状態で、このときには、優先端末選択部３６からの４ビットの優先処理指示情報は、「００００」となっており、復号化部３５では、４個のバッファメモリからのデータを順番に均等に復号化するようになる。
【０１５４】
そして、時点ｔｉでは、地点Ｃの会議端末装置からの送信信号には、優先度情報として「０１」が付加されているため、これが優先端末選択部３６で検出されて、復号化部３５に供給される４ビットの優先処理指示情報は「００１０」とされる。すなわち、優先条件情報の記憶値が「００」となっている場合は、優先されることがないので、その会議端末の対応するビットは、常に「０」であり、「００」以外になっている場合は、付加されてきた優先度情報と合致した場合にだけ「１」となる。これにより、復号化部３５では、バッファメモリ３５ｃの会議端末装置からの情報を優先して復号化処理されるようになる。
【０１５５】
この第２の実施の形態でも、復号化部３５では、優先端末選択部３６からの４ビットの優先処理指示情報が、いずれかの端末からの情報を優先して処理することを指示している場合には、もし他の端末用のバッファメモリから１フレーム分のデータが蓄積されたことの通知が到来したとしても、優先端末選択部３６からの優先処理指示情報の指示通りに、優先すべき端末からの情報の復号化処理を続けて行うようにする。
【０１５６】
また、優先処理すべき端末が複数個になった場合には、それらの端末の間で交代に復号化処理するようにする。４ビットの優先処理指示情報が「００００」であるときには、優先的に処理する必要がないので、復号化部３５では、４個のバッファメモリ３４ａ〜３４ｂのデータについて、予め定めた順序で、均等に復号化処理を行うようにするのは、第１の実施の形態の場合と同様である。
【０１５７】
図１８は、以上説明した第２の実施の形態の会議端末装置の受信側の動作のフローチャートを示すものである。このフローチャートは、第１の実施の形態の会議端末装置の受信側の動作のフローチャートと、優先度情報のチェックの方法がが異なるだけで、ほぼ同様である。
【０１５８】
すなわち、ステップＳ６１〜Ｓ６５およびステップＳ６８〜Ｓ７３は、第１の実施の形態の図１０のフローチャートのステップステップＳ２１〜Ｓ２５およびステップＳ２８〜Ｓ３３に、それぞれ対応している。この第２の実施の形態では、ステップＳ６６と、ステップＳ６７の優先度情報のチェックから４ビットの優先処理指示情報の形成までの処理部分が、第１の実施の形態と異なる。
【０１５９】
すなわち、この第２の実施の形態では、前述もしたように、送信側端末から送信信号を受信すると、ステップＳ６５までの処理により、送信側端末に対応したバッファメモリに、音声データや映像データが分離されて格納されるとともに、パケット分解部３３から得られる端末ＩＤおよび優先度情報を優先端末選択部３６が受け取る。
【０１６０】
そして、優先端末選択部３６は、優先条件情報記憶部６１に記憶されている当該端末ＩＤで示される送信側端末の優先条件情報を読み出し、読み出した優先条件情報が「００」以外のとき、パケット分解部３３から取得した優先度情報と、その優先条件情報とを比較し、両者が一致したら、４ビットの優先処理指示情報の当該端末に対応するビットを「１」とする。また、比較結果が不一致であれば、４ビットの優先処理指示情報の当該端末に対応するビットは「０」のままとする。また、読み出した優先条件情報が「００」であれば、優先されることはないので、対応するビットは常に「０」とする。
【０１６１】
この結果、優先度情報が優先条件情報に一致していれば、ステップＳ６９で当該端末からの情報が優先して復号化が実行され、そうでなければ、４個のバッファメモリ３４ａ〜３４ｄからのデータが機会均等に復号化処理される。
【０１６２】
以上説明した第２の実施の形態の会議端末装置を用いれば、第１の実施の形態と同様に、端末の計算機能力が低く、多量の映像データを処理しきれない場合でも、会議中にユーザが特に意識して操作することなく、常に注目するべき画像を優先的に高品質で表示でき、会議がスムーズに進行できるようにすることができる。
【０１６３】
そして、この第２の実施の形態の場合には、ユーザーが予め受信側で優先して処理してもらいたい情報を定めておくようにすることができるので、会議の重要な情報は、受信側において優先処理されて、品質が低下するのが防止されるので、会議がスムースに進行するものである。
【０１６４】
なお、会議に先立ち、予め複数の受信側端末に優先条件情報を送る方法は、電子メールによる方法に限るものではなく、パケット伝送方式であってもよいし、その他種々の伝送方式を利用できることは言うまでもない。
【０１６５】
また、会議中に送信する会議関連情報に付加される優先度情報は、ヘッダ部ではなく、各パケットのデータ部の先頭部分などの映像情報や音声情報などの情報とは区別できる部位に付加するようにすることもできる。
【０１６６】
また、前述もしたように、優先度情報つまり優先条件情報は、２ビットである必要はなく、３ビット以上で構成されていてももちろんよい。また、優先度情報は、常にヘッダ部やデータ部に挿入付加するのではなく、送信側端末において優先条件に合致する送信信号のパケットにのみ、挿入付加するようにしてもよい。その場合には、受信側端末では、パケットヘッダやパケットのデータ部に優先度情報が存在するか否かを判別するだけでも、優先すべき情報であるか否かを判別することができるが、受信した優先度情報と、優先条件情報記憶部の優先条件情報との比較検討を行うことにより、誤りなく、優先すべき情報の優先処理を確実に行うことができる。
【０１６７】
また、上述の第２の実施の形態の説明では、会議の最初に優先条件を設定しただけの場合を説明したが、会議の途中で、設定操作部５１により優先条件設定部５２を操作することで、優先条件情報を臨機応変に変更および更新するように構成することも可能である。
【０１６８】
［他の実施の形態］
第２の実施の形態においては、優先条件確認手段では、送信信号が優先条件に合致しているか否かを確認して、合致しているときに、その優先条件情報に等しい優先度情報を付加して送信するようにしたが、送信信号のマルチメディアデータタイプを予め送信側と受信側とで定めておき、必ず、送信信号のパケットには、そのマルチメディアデータタイプを付加するようにすることで、送信側での優先条件の確認処理を不要にすることができる。
【０１６９】
すなわち、図１１の優先条件確認部５３では、単に、４種の入力信号のうちのどれとどれが送信信号に含まれるかを確認し、その含まれる情報に応じたマルチメディアデータタイプを判定確認する。そして、パケット化部１３にそのマルチメディアデータタイプの情報を送るようにする。
【０１７０】
受信側においては、常時、受信した送信信号のマルチメディアデータタイプを判定し、それが予め記憶されている優先条件情報に合致しているか否か確認することで、それが優先処理すべきデータであるか否かを判断することができる。
【０１７１】
このようにすれば、優先条件確認部５３へ優先条件設定部５２から優先条件情報を供給する必要がないとともに、優先条件確認部５３では、優先条件に送信信号が合致しているかどうかを判定する必要がなくなるものである。
【０１７２】
また、第２の実施の形態では、予め、ユーザーが各会議端末装置で設定した優先条件を受信側端末に知らせておくようにするとともに、各受信側端末では、複数の送信側端末で設定されたそれぞれの優先条件情報を集めて記憶しておき、送信信号中に含まれる優先度情報が、記憶している送信側端末の優先条件情報と一致しているか否かにより優先処理するか否かを設定するようにした。
【０１７３】
しかし、送信側端末において、予め設定した優先条件に合致する送信信号を他の受信側端末に送信するときにのみ、第１の実施の形態で説明したような優先度情報ＰＲを挿入することようにすることもできる。この場合には、受信側端末の構成は、第１の実施の形態の場合の図８の構成とするだけでよく、予め、ユーザーが各会議端末装置で設定した優先条件を受信側端末に知らせておくようにしたり、また、受信側端末で各送信側端末ごとの優先条件情報を記憶しておく必要はない。
【０１７４】
また、第１の実施の形態では、送信側端末が音声の有無により優先度情報を受信側端末に知らせる形態を示したが、優先度情報が音声の有無だけによると決めておくのであれば、音声の有無を調べる処理を受信側端末が行うことで、送信側端末に頼ることなく同じ効果を得ることができる。この場合には、送信信号に優先度情報を付加する必要はない。
【０１７５】
［他の変形例］
第１の実施の形態および第２の実施の形態では、共に、外部から入力された映像、音声等の複数のマルチメディアデータを処理する処理手段および送信側端末より送信されてきたマルチメディアデータを処理する処理手段の処理内容に、それぞれ符号化、復号化が含まれている場合について説明したが、この発明ではこれに限るものではない。例えば、受信側の処理においては、ディスプレイへの表示処理のみに適用しても、上述したこの発明の効果が得られる。
【０１７６】
また、第１の実施の形態および第２の実施の形態では、共に、処理する優先度情報を受信側端末に送り、その情報によって受信側端末が優先的に処理する端末を選択する形態である。しかし、もし、明らかに全ての受信側端末での処理能力が足りないということが、予めわかっているのであれば、受信側での優先選択処理に加えて、優先しなくてもよい場合には、送信するデータ量を削減して送るということもできる。
【０１７７】
例えば、第１の実施の形態の場合は音声が、第２の実施の形態の場合は優先条件設定部５１で設定したデータが、それぞれレベル比較部および優先条件確認部５３で認識されなかった場合、フレームレート変換部または解像度変換部などのようなデータ量低減手段によりデータ量を低減したのちに符号化し、パケット化部においてパケット化して送信するようにすることができる。または、データ量を低減するのではなく、新しい映像データを送らないようにしてもよい。
【０１７８】
このようにすれば、この発明の効果に加え、ネットワーク上に流れるデータの量を低減することができるという効果も得られる。
【０１７９】
さらに、第１の実施の形態および第２の実施の形態では、共に、送信側端末および受信側端末とに分けて説明しているが、前述もしたように、マルチメディア会議では、各会議端末装置が送信も受信も行うので、それぞれの会議端末装置が、上述の送信側および受信側の両方の機能を持ち合わせていることは言うまでもない。
【０１８０】
【発明の効果】
以上説明したように、この発明によれば、多地点マルチメディア会議において、会議端末装置の計算機能力が低くて、多量の映像データを処理しきれない場合でも、会議中にユーザが特に意識して操作することなく、常に注目するべき画像を優先的に高品質で表示でき、会議がスムーズに進行できるようにすることができる。
【図面の簡単な説明】
【図１】この発明の参考例としての第１の実施の形態の送信側の構成例を示すブロック図である。
【図２】マイクロホンから入力されるアナログ音声信号の例を示す図である。
【図３】第１の実施の形態における音声の有無の検出方法の例を説明するための図である。
【図４】第１の実施の形態における送信信号の形態の例を説明するための図である。
【図５】第１の実施の形態における送信信号の形態の例を説明するための図である。
【図６】第１の実施の形態の送信側の動作を説明するためのフローチャートである。
【図７】第１の実施の形態の送信側における音声の有無の検出動作を説明するためのフローチャートである。
【図８】第１の実施の形態の受信側の構成例を示すブロック図である。
【図９】第１の実施の形態の受信側での優先端末選択部の動作を説明するための図である。
【図１０】第１の実施の形態の受信側の動作を説明するためのフローチャートである。
【図１１】この発明の実施の形態としての第２の実施の形態の送信側の構成例を示すブロック図である。
【図１２】第２の実施の形態における優先条件の設定選択方法の例を示す図である。
【図１３】第２の実施の形態における優先条件情報の例を説明するための図である。
【図１４】第２の実施の形態における優先条件の設定動作の例を説明するためのフローチャートである。
【図１５】第２の実施の形態の送信側の動作を説明するためのフローチャートである。
【図１６】第２の実施の形態の受信側の構成例を示すブロック図である。
【図１７】第２の実施の形態の受信側での優先端末選択部の動作を説明するための図である。
【図１８】第２の実施の形態の受信側の動作を説明するためのフローチャートである。
【図１９】多地点マルチメディア会議システムの一例を説明するための図である。
【図２０】図１９の会議システムにおける各端末のディスプレイ表示画面の例を示す図である。
【図２１】多地点マルチメディア会議システムの他の例を説明するための図である。
【図２２】図２１の会議システムにおける各端末のディスプレイ表示画面の例を示す図である。
【符号の説明】
１ａ〜１ｅ 多地点マルチメディア会議に参加している会議端末装置
２，１０ ネットワーク
３ ＭＣＵ
４ 会議端末装置のディスプレイ
５ａ〜５ｄ ディスプレイに表示される映像ウィンド
６ａ〜６ｄ ディスプレイに表示される映像ウィンド
１１ｖ 映像情報の入力端子
１１ａ 音声情報の入力端子
１２ 符号化部
１３ パケット化部
１４，３７ ＣＰＵ
１５ レベル検出部
１６ レベル比較部
１７ 多重化部
１８ データ送信部
３１ データ受信部
３２ 分離部
３３ パケット分解部
３４ａ〜３４ｄ バッファメモリ
３５ 復号化部
３６ 優先端末選択部
５１ 設定操作部
５２ 優先条件設定部
５３ 優先条件確認部
５４ 外部メモリ
６１ 優先条件情報記憶部
Claims (2)
- ネットワークに接続され、このネットワークを通じて、音声、映像等の会議関連情報を送信するとともに、他の複数個の会議端末装置からの送信信号を前記ネットワークを通じて受信する会議端末装置であって、
会議関連情報の入力を受ける入力部と、
前記会議関連情報に関して、受信側端末で処理を優先させるようにするための優先条件を、ユーザーによる指示を受けて予め設定する優先条件設定手段と、
前記優先条件設定手段で設定された前記優先条件に対応する優先条件情報を、自端末の端末識別子を付加して予め前記ネットワークを通じて他の全ての会議端末装置に送信する手段と、
前記入力部からの会議関連情報について、前記優先条件設定手段で設定された前記優先条件に合致しているか否かを確認する優先条件確認手段と、
前記入力部からの会議関連情報を前記ネットワークに送出する信号に変換する処理を行うとともに、前記優先条件確認手段での確認結果が前記会議関連情報が前記優先条件に合致しているときに、前記ネットワークに送出する信号に、前記優先条件情報と、前記自端末の端末識別子とを付加して、送信信号を生成する情報処理手段と、
前記情報処理手段からの送信信号を前記ネットワークを通じて受信側端末に対して送信するデータ送信手段と、
前記ネットワークを通じて送信されてきた他の会議端末装置からの送信信号を受信するデータ受信手段と、
前記データ受信手段で受信した前記送信信号中に含まれる前記端末識別子を認識して、前記受信したデータを、前記端末識別子に対応した前記他の会議端末装置ごとのバッファメモリに区分けして蓄積するバッファ手段と、
前記バッファ手段に蓄積された受信データの復号化処理を行う復号化手段と、
前記ネットワークを通じて予め送られてくる前記優先条件情報を、前記他の会議端末装置の端末識別子とともに、予め、蓄積する優先条件蓄積手段と、
前記データ受信手段で受信した前記送信信号に含まれる前記優先条件情報と、前記優先条件蓄積手段に蓄積されている優先条件情報のうちの、前記送信信号に含まれる前記端末識別子で識別される前記他の会議端末装置に関する前記優先条件情報とを比較参照して、前記データ受信手段で受信した前記会議関連情報が前記優先条件に合致しているかどうかを判別して、前記優先条件に合致していると判別したときに、当該優先条件に合致していると判別された受信データを蓄積している前記他の会議端末装置用バッファメモリからの情報を、前記復号化手段で優先的に復号化を実行するように制御する優先制御手段と、
を備えることを特徴とする会議端末装置。 - 請求項１に記載の会議端末装置において、
前記会議関連情報は、複数種類の情報を含むマルチメディア情報であり、
前記優先条件情報は、前記マルチメディア情報がどのような情報であるかを示すマルチメディアタイプに対応するものである
ことを特徴とする会議端末装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34256697A JP3775455B2 (ja) | 1997-12-12 | 1997-12-12 | 会議端末装置および会議関連情報の送信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP34256697A JP3775455B2 (ja) | 1997-12-12 | 1997-12-12 | 会議端末装置および会議関連情報の送信方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11177953A JPH11177953A (ja) | 1999-07-02 |
| JP3775455B2 true JP3775455B2 (ja) | 2006-05-17 |
Family
ID=18354760
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP34256697A Expired - Fee Related JP3775455B2 (ja) | 1997-12-12 | 1997-12-12 | 会議端末装置および会議関連情報の送信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3775455B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001005144A1 (fr) * | 1999-07-08 | 2001-01-18 | Matsushita Electric Industrial Co., Ltd. | Procede de commande d'affichage video, systeme de traitement d'affichage video, dispositif de traitement d'affichage video, et dispositif d'affichage sur ecran |
| JP4496755B2 (ja) * | 2003-10-23 | 2010-07-07 | ソニー株式会社 | 通信処理装置、および通信処理方法、並びにコンピュータ・プログラム |
| JP4882288B2 (ja) * | 2005-06-20 | 2012-02-22 | 富士ゼロックス株式会社 | 表示制御装置、システム及び表示制御方法 |
| JP4604877B2 (ja) * | 2005-06-24 | 2011-01-05 | 富士ゼロックス株式会社 | 表示画像制御プログラム、画像配信装置、表示画像制御装置、表示画像制御方法 |
| JP2007158410A (ja) | 2005-11-30 | 2007-06-21 | Sony Computer Entertainment Inc | 画像符号化装置、画像復号装置、および画像処理システム |
| JP2007274593A (ja) * | 2006-03-31 | 2007-10-18 | Matsushita Electric Ind Co Ltd | 映像受信装置及び映像配信システム並びに映像受信方法 |
| US7822811B2 (en) | 2006-06-16 | 2010-10-26 | Microsoft Corporation | Performance enhancements for video conferencing |
| CN101471861B (zh) * | 2007-12-27 | 2012-11-07 | 华为技术有限公司 | 提高对等叠加网络服务质量的方法、装置以及对等节点 |
| JP5187890B2 (ja) * | 2008-05-23 | 2013-04-24 | Ｋｄｄｉ株式会社 | メディアデータの送受信を優先制御する端末、プログラム及び方法 |
| JP5184229B2 (ja) * | 2008-07-01 | 2013-04-17 | Ｋｄｄｉ株式会社 | 同期制御装置、及び同期制御プログラム |
| JP6269609B2 (ja) * | 2015-07-28 | 2018-01-31 | 株式会社リコー | 情報処理装置、画像表示方法、通信システム、プログラム |
| US11184415B2 (en) | 2018-05-07 | 2021-11-23 | Apple Inc. | Media feed prioritization for multi-party conferencing |
-
1997
- 1997-12-12 JP JP34256697A patent/JP3775455B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11177953A (ja) | 1999-07-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6466248B1 (en) | Videoconference recording | |
| KR100405052B1 (ko) | 전화선을 통한 고속 영상 전송 | |
| US5818514A (en) | Video conferencing system and method for providing enhanced interactive communication | |
| US6603501B1 (en) | Videoconferencing using distributed processing | |
| JP3775455B2 (ja) | 会議端末装置および会議関連情報の送信方法 | |
| US20060256188A1 (en) | Status and control icons on a continuous presence display in a videoconferencing system | |
| JP6172610B2 (ja) | テレビ会議用システム | |
| JP2005318534A (ja) | ストリーム選択を行う会議開催方法及び装置 | |
| JP2005318535A (ja) | 帯域幅制御をして会議を開催する方法及び装置 | |
| US20050021620A1 (en) | Web data conferencing system and method with full motion interactive video | |
| US7453829B2 (en) | Method for conducting a video conference | |
| JP2010157906A (ja) | 映像表示装置 | |
| WO2016147538A1 (ja) | テレビ会議用通信装置 | |
| JP2007020095A (ja) | 情報合成装置、情報合成システム、情報同期方法およびプログラム | |
| JP2001145103A (ja) | 送信装置及び通信システム | |
| JP2013126103A (ja) | 通信装置および通信制御方法 | |
| JP2002290940A (ja) | テレビ会議システム | |
| JP6481937B2 (ja) | テレビ会議用通信装置 | |
| WO2022037424A1 (zh) | 转码方法、装置、介质和电子设备 | |
| JP2648095B2 (ja) | 画像符号化および復号化装置 | |
| JPH10126757A (ja) | ビデオ会議システム | |
| US20240177740A1 (en) | System and method for producing a video stream | |
| JPH05137135A (ja) | 通信会議方式 | |
| JPH05260463A (ja) | 会議相手映像切替方式 | |
| JP4348238B2 (ja) | 遠隔通信方法及び装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050815 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051109 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20051227 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060201 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060214 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100303 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110303 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120303 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |