(57)【要約】【課題】映像を通信する際に、当該映像を規格化することなく、自端末および相手端末のより高度な能力を用いて通信する。【解決手段】自端末の映像入出力通信能力を取得する自端末能力取得手段１２と、相手端末の映像入出力通信能力を取得する相手端末能力取得手段１３と、自端末の映像入出力通信能力と相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定手段１４と、方式決定手段が決定した映像入出力方式に従って映像の入出力処理を行う入出力処理手段１５と、相手端末と映像を送受信する通信手段１６と、を有する映像通信端末１。【選択図】図２
2009017033.tif 000002
【特許請求の範囲】
【請求項１】
映像通信端末であって、
自端末の映像入出力通信能力を取得する自端末能力取得手段と、
相手端末の映像入出力通信能力を取得する相手端末能力取得手段と、
前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定手段と、
前記方式決定手段が決定した映像入出力方式に従って、映像の入出力処理を行う入出力処理手段と、
前記相手端末と映像を送受信する通信手段と、を有すること
を特徴とする映像通信端末。
【請求項２】
請求項１記載の映像通信端末であって、
前記方式決定手段が決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックを外部からダウンロードするソフト／ハードダウンロード手段と、
前記ダウンロードしたソフトウェアおよび／またはハードロジックを用いて相手端末と通信が可能か否かを検証する検証手段と、をさらに有すること
を特徴とする映像通信端末。
【請求項３】
請求項２記載の映像通信端末であって、
前記方式決定手段が決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックの実行に必要な情報を外部からダウンロードするソフト／ハード情報ダウンロード手段を、さらに有すること
を特徴とする映像通信端末。
【請求項４】
映像通信端末が行う映像通信方法であって、
自端末の映像入出力通信能力を取得するとともに、相手端末の映像入出力通信能力を取得する端末能力取得ステップと、
前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定ステップと、
前記方式決定ステップで決定した映像入出力方式に従って映像の入出力処理を行うとともに、前記相手端末と映像を送受信する通信ステップと、を行うこと
を特徴とする映像通信方法。
【請求項５】
請求項４記載の映像通信方法であって、
前記方式決定ステップで決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックを外部からダウンロードするソフト／ハードダウンロードステップと、
前記ダウンロードしたソフトウェアおよび／またはハードロジックを用いて相手端末と通信が可能か否かを検証する検証ステップと、をさらに行うこと
を特徴とする映像通信方法。
【請求項６】
請求項５記載の映像通信方法であって、
前記方式決定ステップで決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックの実行に必要な情報を外部からダウンロードするソフト／ハード情報ダウンロードステップを、さらに行うこと
を特徴とする映像通信方法。
【請求項７】
映像通信端末が実行する映像通信プログラムであって、
前記映像通信端末に、
自端末の映像入出力通信能力を取得するとともに、相手端末の映像入出力通信能力を取得する端末能力取得ステップと、
前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定ステップと、
前記方式決定ステップで決定した映像入出力方式に従って映像の入出力処理を行うとともに、前記相手端末と映像を送受信する通信ステップと、を実行させること
を特徴とする映像通信プログラム。
【請求項８】
請求項７記載の映像通信プログラムであって、
前記映像通信端末に、
前記方式決定ステップで決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックを外部からダウンロードするソフト／ハードダウンロードステップと、
前記ダウンロードしたソフトウェアおよび／またはハードロジックを用いて相手端末と通信が可能か否かを検証する検証ステップと、をさらに実行させること
を特徴とする映像通信プログラム。
【請求項９】
請求項８記載の映像通信プログラムであって、
前記映像通信端末に、
前記方式決定ステップで決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックの実行に必要な情報を外部からダウンロードするソフト／ハード情報ダウンロードステップを、さらに実行させること
を特徴とする映像通信プログラム。
【請求項１０】
映像通信端末が実行する映像通信プログラムを記憶した記録媒体であって、
前記映像通信端末に、
自端末の映像入出力通信能力を取得するとともに、相手端末の映像入出力通信能力を取得する端末能力取得ステップと、
前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定ステップと、
前記方式決定ステップで決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックを外部からダウンロードするソフト／ハードダウンロードステップと、
前記ダウンロードしたソフトウェアおよび／またはハードロジックを用いて相手端末と通信が可能か否かを検証する検証ステップと、
前記検証ステップで検証したソフトウェアおよび／またはハードロジックの映像入出力方式に従って映像の入出力処理を行うとともに、前記相手端末と映像を送受信する通信ステップと、を実行させること
を特徴とする映像通信プログラムを記憶した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像を通信する映像通信端末、映像通信方法、映像通信プログラムおよび映像通信プログラムを記録した記録媒体に関する。
【背景技術】
【０００２】
一般的な映像通信端末においては、映像の評価尺度に応じて映像を規格化し、規格化した映像を送受信することが行われている。映像の規格化としては、例えばVGA（Video Graphics Array規格）の縦640ピクセル×横480ピクセルのような規定があり、各ピクセルは、光源としてRGB（赤、緑、青）の３原色を有する。
【０００３】
また、映像を通信する際に、SIP（Session Initiation Protocol）を用いて相手端末とセッションを確立することが行われ、セッションの詳細情報はSDP（Session Description Protocol）を用いて記述されている。SIPについては非特許文献１に記載されて、SDPについては非特許文献２に記載されている。
【非特許文献１】“RFC 2543 - SIP: Session Initiation Protocol”、[online]、［平成１９年６月１日検索］、インターネット＜ＵＲＬ： http://www.faqs.org/rfcs/rfc2543.html＞
【非特許文献２】“RFC 2327 - SDP: Session Description Protocol”、[online]、［平成１９年６月１日検索］、インターネット＜ＵＲＬ： http://www.faqs.org/rfcs/rfc2327.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００４】
規格化した映像を通信する場合、送信側の映像通信端末の入力装置（入力デバイス）から入力された映像は、当該端末で規格化され、相手端末に送信される。映像が規格化されることにより映像の一部の情報が欠落してしまい、受信側の映像通信端末では、出力装置（出力デバイス）が高度な能力（性能）を有する場合であっても、規格化前の映像を出力することができない。
【０００５】
本発明は上記事情に鑑みてなされたものであり、本発明の目的は、映像を通信する際に、当該映像を規格化することなく、自端末および相手端末のより高度な能力を用いて通信することにある。
【課題を解決するための手段】
【０００６】
本発明は、映像通信端末であって、自端末の映像入出力通信能力を取得する自端末能力取得手段と、相手端末の映像入出力通信能力を取得する相手端末能力取得手段と、前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定手段と、前記方式決定手段が決定した映像入出力方式に従って、映像の入出力処理を行う入出力処理手段と、前記相手端末と映像を送受信する通信手段と、を有する。
【０００７】
また、本発明は、映像通信端末が行う映像通信方法であって、自端末の映像入出力通信能力を取得するとともに、相手端末の映像入出力通信能力を取得する端末能力取得ステップと、前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定ステップと、前記方式決定ステップで決定した映像入出力方式に従って映像の入出力処理を行うとともに、前記相手端末と映像を送受信する通信ステップと、を行う。
【０００８】
また、本発明は、映像通信端末が実行する映像通信プログラムであって、前記映像通信端末に、自端末の映像入出力通信能力を取得するとともに、相手端末の映像入出力通信能力を取得する端末能力取得ステップと、前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定ステップと、前記方式決定ステップで決定した映像入出力方式に従って映像の入出力処理を行うとともに、前記相手端末と映像を送受信する通信ステップと、を実行させる。
【０００９】
また、本発明は、映像通信端末が実行する映像通信プログラムを記憶した記録媒体であって、前記映像通信端末に、自端末の映像入出力通信能力を取得するとともに、相手端末の映像入出力通信能力を取得する端末能力取得ステップと、前記自端末の映像入出力通信能力と、前記相手端末の映像入出力通信能力とに基づいて、映像入出力方式を決定する方式決定ステップと、前記方式決定ステップで決定した映像入出力方式に対応するソフトウェアおよび／またはハードロジックを外部からダウンロードするソフト／ハードダウンロードステップと、前記ダウンロードしたソフトウェアおよび／またはハードロジックを用いて相手端末と通信が可能か否かを検証する検証ステップと、前記検証ステップで検証したソフトウェアおよび／またはハードロジックの映像入出力方式に従って映像の入出力処理を行うとともに、前記相手端末と映像を送受信する通信ステップと、を実行させる。
【発明の効果】
【００１０】
本発明によれば、映像を通信する際に、当該映像を規格化することなく、自端末および相手端末のより高度な能力を用いて通信することができる。
【発明を実施するための最良の形態】
【００１１】
＜第１の実施の形態＞
以下、本発明の第１の実施の形態について、図面を参照して説明する。
【００１２】
図１は、本実施形態の映像通信処理の概要を説明するための説明図である。
【００１３】
本実施形態では、通信プロトコルとしてRFC2543等に記述されるSIPを例に以下説明するが、これに限定されず、他の通信プロトコルを用いてもよい。
【００１４】
発信側の映像通信端末M（以下、「端末M」）は、通信相手（受信側）の映像通信端末N（以下、「端末N」）にINVITEメッセージを送信する（Ｓ１１）。端末Nは、「180  Ringing」を端末Nに返答する（Ｓ１２）。端末Mおよび端末Nがテレビ電話の場合、呼び出し音が鳴っていることを端末Mに通知する。そして、端末Nがオフフックされることにより、端末Nは、「200  OK」を端末Mに送信する（Ｓ１３）。端末Mは、「200  OK」を受信すると、ACKメッセージを端末Nに送信する（Ｓ１４）。
【００１５】
このような、SIPのプロトコルにより、端末Mと端末Nとの間で呼が接続され、メディア（映像、音声等）のチャネル（ポート）をオープンし、各端末の入力装置から入力されたメディアを、相手端末にRTPなどで送信する（Ｓ１５）。各端末は、相手端末から送信されたメディアを、自端末の出力装置に出力する。そして、通信の終了時には、何れかの端末からBYEメッセージを送信し（Ｓ１６）、BYEメッセージを受信した端末は「200  OK」を返信する。
【００１６】
本実施形態では、INVITEメッセージのSDP（Session Description Protocol）に、自端末Mの映像入出力通信能力を記述し、相手端末Nに送信することとする。すなわち、本実施形態では、規格化したメディア情報ではなく、自端末Mの入出力装置が有する映像入出力通信能力をSDPに記述して相手端末Nに送信する。受信側の端末Nは、受信した端末Mの映像入出力通信能力と、自端末Nの映像入出力通信能力とに基づいて最適な映像入出力方式を決定し、当該方式に基づいてメディアを通信し、当該メディアの入出力処理を行う。
【００１７】
図２は、本発明の第１の実施形態に係る映像通信端末のブロック図である。
【００１８】
図示する映像通信端末１は、呼処理待ち受け部１１と、自端末能力取得部１２と、相手端末能力取得部１３と、映像入出力方式決定部１４と、映像入出力処理部１５と、映像通信部１６とを備える。
【００１９】
呼処理待ち受け部１１は、通信が行われていない間、相手端末からの通信が行われるか、または自ら通信を行うまで、呼処理を待ち受ける。
【００２０】
自端末能力取得部１２は、自端末における映像入出力通信能力を取得する。また、自端末が発信側（図１の端末M）の場合は、取得した自端末の映像入出力通信能力を、相手端末に送信する。
【００２１】
相手端末能力取得部１３は、自端末が受信側（図１の端末N）の場合、相手端末から送信された相手端末の映像入出力通信能力を受信する。
【００２２】
映像入出力方式決定部１４は、自端末が受信側の場合、自端末および相手端末の映像入出力通信能力を用いて、最適な映像入出力方式を決定する。
【００２３】
映像入出力処理部１５は、映像入出力方式決定部１４が決定した映像入出力方式に基づいて、映像入出力処理を実行する。映像入出力処理としては、例えば、映像・音声のCODEC（符号化、復号化）、映像入出力表現、音声入出力表現などである。
【００２４】
映像通信部１６は、映像入出力処理部１５の処理と並行して、相手端末とメディア（映像、音声等）の通信を行う。
【００２５】
上記説明した、映像通信装置１は、例えば、ＣＰＵと、メモリと、ＨＤＤ等の外部記憶装置と、キーボードやマウスなどの入力装置と、ディスプレイやプリンタなどの出力装置と、ネットワークと接続するための通信制御装置と、を備えた汎用的なコンピュータシステムを用いることができる。このコンピュータシステムにおいて、ＣＰＵがメモリ上にロードされた映像通信装置１用のプログラムを実行することにより、映像通信装置１の各機能が実現される。なお、映像通信装置１用のプログラムは、記録媒体に記録されているものであってもよい。
【００２６】
次に、本実施形態の映像通信端末１の処理について説明する。
【００２７】
図３は、映像通信端末１の処理を示すフローチャートである。
【００２８】
なお、映像通信端末１は、処理を開始する前に初期化処理を行うものとする。初期化処理としては、例えば、ＩＰソケット（Socket）通信に必要な所定のポートのオープンや、ログファイルのオープンなどが考えられる。
【００２９】
呼処理待ち受け部１１は、呼処理で用いる所定のポート番号をリッスン（Listen）し（Ｓ１０１）、呼処理キューに呼が入っているか否かを判別する（Ｓ１０２）。なお、呼処理待ち受け部１１は、相手端末からの呼があるかどうかをリッスンし、当該呼のポートが相手端末からオープンされた場合、呼処理キューに呼を入れる。呼処理キューに呼が入っている場合（Ｓ１０２：ＹＥＳ）、当該映像通信端末１は受信側の端末であって、後述するＳ１１１の処理に進む。
【００３０】
呼処理キューが空の場合（Ｓ１０２：ＮＯ）、呼処理待ち受け部１１は、自端末からの発信要求があるか否かを判別する（Ｓ１０３）。発信要求がない場合（Ｓ１０３：ＮＯ）、呼処理待ち受け部１１は、Ｓ１０１に戻り以降の処理を繰り返し行う。一方、発信要求を受け付けた場合（Ｓ１０３：ＹＥＳ）、当該映像通信端末１は受信側の端末であって、以降の発信処理（Ｓ１０４〜Ｓ１０５）を行う。
【００３１】
映像通信端末１がテレビ電話の場合、発信要求は、ユーザがハンドセットを持ち、電話をかける操作に相当する。すなわち、ハンドセットを持ち上げオフフックした後、トーン音がネットワーク側から送出され、ダイヤル可能な状態であることをユーザに通知する。ユーザは、トーン音を聞いた後、相手端末の識別ＩＤ（例えば、電話番号）を、映像通信端末１の入力装置（不図示）を用いて入力する。映像通信端末１は、相手端末の識別ＩＤの入力後に発信を指示する発信ボタンの押下を受け付けた場合、または、一意に相手端末を識別可能な識別ＩＤが入力された場合、発信処理を行う。本実施形態では、前述の通りSIPを用いた発信処理を行うものとする。
【００３２】
まず、自端末能力取得部１２は、自端末における映像入出力通信能力（性能）を取得する（Ｓ１０４）。
【００３３】
具体的には、自端末能力取得部１２は、自端末の映像入力装置の通信時の能力を取得する。映像入力装置としては、例えば、CCD（Charge Coupled Devices）、CMOS（Complementary Metal Oxide Semiconductor）などのカメラが考えられる。
【００３４】
また、自端末能力取得部１２は、自端末の映像出力装置の通信時の能力を取得する。映像出力装置としては、例えば、LCD（液晶ディスプレイ）、PDP（プラズマディスプレイ）などが考えられる。
【００３５】
また、自端末能力取得部１２は、映像通信時の処理能力（リソース）を取得する。処理能力は、CPUのMIPS値、メモリ容量のMbyte値などである。なお、映像通信時の処理能力は、映像入出力時に利用可能な最大能力であって、映像通信端末のハード的処理能力／ソフトウェア的処理能力等により決定されるものである。これにより、最大能力を生かした処理が可能となる。
【００３６】
また、自端末能力取得部１２は、処理能力として、CPUタイプ、映像通信時に処理可能なCPU INSTRUCTION set（命令セット）を取得する。CPUタイプは、例えば、CISC、RISC、Dynamic reconfigurable Processor、DSP、FPGAなどである。CPU INSTRUCTION setは、CPUが使用できる命令の集合であって、例えば、Z80  instruction、MMX、Dynamic reconfigurable Processor用のINSTRUCTION set、さらに高級言語の場合はJava(登録商標) CDEなどである。
【００３７】
本実施形態の自端末能力取得部１２は、Ｓ１０４で取得した自端末の映像入出力通信能力を、SDP（RFC2327：Session Description Protocol）で記述し、INVITEメッセージとともに識別ＩＤで指定された相手端末に送信する（Ｓ１０５）。
【００３８】
SDPの記述形式は、下記のとおりである。なお、記述の表記は、BNF（ハ゛ッカス・ノイヤス・フォーム）記法とする。
【００３９】
｛［ａ−ｚ］＝［・・・］｝＊ｎ
すなわち、最初のキャラクタ（文字）は、ａからｚの文字で記述され、それぞれの文字に意味が持たせられている。例えば、ｖは、バージョンを表す。また、ｍは、メディアタイプを示す。ａは、属性や拡張属性を記述する行である。SDPでは、このような行が、少なくとも１つ記述される。
【００４０】
V=0
o=inagaki ・・・
m=audio 3999 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 52000 RTP/AVP 31
a=rtpmap:31 H261/9000
・・・．
メディアタイプを示すmライン（mから始まる行）には、以下の内容が記述される。
【００４１】
M=<media type> <port number> <transport protocol> <media format>
属性や拡張属性を記述するaライン(aから始まる行)には、自端末で対応した拡張部分を記述することができる。aの記述を受け取った相手端末では、拡張部分の処理が理解できない場合、無視することとする。
【００４２】
例えば、ビデオの属性としてVGAで処理したい場合に、以下のように記述してもよい。
【００４３】
m=video 52000 RTP/AVP 31
a=x_video_size:VGA
すなわち、ビデオの属性として“x_video_size”を記述し、さらに“x_video_size”の示す値として“VGA”を記述している。
【００４４】
また、本実施形態では、映像通信端末１の最大性能をDSPに記述するため、aラインに拡張属性として、最大能力、入出力装置固有の特徴および能力などを記述することができる。入出力装置の能力の記述としては、例えば、入力装置としてCMOSを例に説明する。
【００４５】
CMOSは、CCDと異なり、一般的に全素子からの読み出しを機構上できない。そのため、通常、画面上で上の方から画素（Pixel）の情報を読み出すため、一番下の画素まで情報を読み出す間に動いている物を撮像する場合に、下の画素からm行上の画素は、（t-n*m）秒のときの映像のデータを示していることになる。ｔは、一番下（最後）の画素を読み出した時間である。nは、１行分の画素を読み出すのに要する時間である。このような、CMOSの特性も下記のようにaラインに記述することができる。
【００４６】
m=video 52000 RTP/AVP 31
a=x_video_size:VGA x_cmos_read_time_per_line:n
ここで、“x_cmos_read_time_per_line”は、CMOSの各行の読み出し時間（値）が“n”であることを示している。
【００４７】
また、CMOSおよびCCDにおいては、各画素は光を読み取る画素として機能し、その光がどのような特性を持った光であるかは認識できず、光子数しかカウントできない。そのため、映像のRGB（赤、緑、青）の色の光子をカウントする際には、各画素の前に適切なフィルタを設置する。例えば、赤の光子をカウントするためには、赤だけを透過する赤外線フィルタを画素の前に配置する。このように、入力装置は、各RGBの光子をカウントする仕組みを備えている。
【００４８】
また、フィルタのつくりにより、RGB以上の色区分をすることも可能である。○ｎｍ〜△ｎｍまでの光を透過するフィルタを用意しておけば、当該フィルタ毎に適切な光子を測定することが可能となる。上記の場合、ａラインを下記のよう記述することとしてもよい。
【００４９】
a=x_cmos_filter_no.1_start:○ x_coms_filter_no.1_end:△
x_cmos_filter_no.2_start:■ x_coms_filter_no.2_end:◇
x_cmos_filter_no.3_start:● x_coms_filter_no.3_end:◎
・・・．
例えば“no.1”CMOSフィルタは、○ｎｍ〜△ｎｍまでの光を透過するフィルタを搭載していることを示している。
【００５０】
このようにCMOSはフィルタがされているため、１画素でRGB全ての色を表すことが難しい。そのため、各画素のそれぞれのR、G、Bの色だけを読み取らせ適当な配列とし、配置の規則性に基づき仮想画素のRGB値を求めるという方式が利用されることが多い。Bayerが開発したBayer配列の方式がRGBの配列では一般的である。
【００５１】
図４は、Bayer配列の一例を示す図である。
【００５２】
CMOSやCCDがBayer配列であることを示す場合、以下の記述形式とすることができる。
【００５３】
a=x_cmos_filter_no.1_start:○ x_coms_filter_no.1_end:△ x_filter_no.1:R
x_cmos_filter_no.2_start:■ x_coms_filter_no.2_end:◇ x_filter_no.2:G
x_cmos_filter_no.3_start:● x_coms_filter_no.3_end:◎ x_filter_no.3:B
x_cmos_array_grid_no.1:RGRG x_cmos_array_grid_no.2:GBGB
“x_cmos_filter_no.1”は略称ではＲのフィルタ（赤の光子を測定するためのフィルタ）、“x_cmos_filter_no.2”はＧ（緑）のフィルタ、“x_cmos_filter_no.3”はＢ（青）のフィルタである。そして、これらのフィルタが、最初の配列のグリッドでは、どのように配列されているかが“x_cmos_array_grid_no.1:RGRG”で記述されている。すなわち、Ｒの次にＧ、次にＲ、次にＧが配列されている。これは、図４のようなカラーフィルタ形のセンサ配列を、相手端末に伝える際に必要となる。
【００５４】
同様に、例えばLCD（出力装置）では、光を入射して、ある特定の光のみを反射し、あるいは、バックライト（背面側）のライトにより、ある特定の光のみを透過させることにより、色情報を伝えている。LCDでは、CMOSと同様に、特定のRGBの配列とすることにより、色を組み合わせて色情報として伝えている。
【００５５】
図５は、LCD の一般的なRGBの配列を示すものである。図示するRGBの配列は、１画素を３等分して、それぞれにR、G、Bを配置している。この配列を、ａラインで記述すると以下のようになる。
【００５６】
a=x_LCD_filter_no.1_start:○ x_LCD_filter_no.1_end:△ x_filter_no.1:R
x_LDC_filter_no.2_start:■ x_LCD_filter_no.2_end:◇ x_filter_no.2:G
x_LCD_filter_no.3_start:● x_LCD_filter_no.3_end:◎ x_filter_no.3:B
x_LCD_array_grid_no.1_per_pixel:RGB x_LCD_array_grid_no.2_per_pixel:RGB
x_LCD_array_grid_no.3_per_pixel:RGB
この記述では、前述したCMOSと同様に、RGBフィルタが定義されている。また、１画素あたりのフィルタの配列を示す属性名は“x_LCD_array_grid_no.1_per_pixel”であり、その配列属性は“RGB”であることが記述されている。これは、非常に単純なサブ画素の集まりとして、１画素を表現する手法である。サブ画素が特別な形の場合、その特別な形をサブ画素の集合として表現する方法、または、サブ画素の構成を関数として与える方法を用いることが考えられる。
【００５７】
関数として与える場合には、下記の記述となる。
【００５８】
a=x_LCD_filter_no.1_start:○ x_LCD_filter_no.1_end:△ x_filter_no.1:R
x_LDC_filter_no.2_start:■ x_LCD_filter_no.2_end:◇ x_filter_no.2:G
x_LCD_filter_no.3_start:● x_LCD_filter_no.3_end:◎ x_filter_no.3:B
x_LCD_array_grid_func_per_pixel:hogehoge(X,Y)
x_LCD_array_grid_max_X_per_pixel:10
x_LCD_array_grid_max_Y_per_pixel:10
x_LCD_array_grid_func@URL:http://www.sooooo.ok.jp/hogehoge?x=X%y=Y%max
_x=10%max_y=10”
この記述では、“x_LCD_array_grid_func_per_pixel”により１画素あたりのRGBの計算値は“hogehoge(X,Y)”で表される。そして、“hogehoge”の式の値は、“x_LCD_array_grid_func@URL”で記述されるＵＲＬ（“http://www.sooooo.ok.jp/hogehoge?x=X%y=Y%max_x=10%max_y=10”）に記載されていることが示されている。
【００５９】
当該ＵＲＬでは、XとYおよび最大のXと最大のYを与えることにより、RGB値が返されるCGIであることが期待される。X、Y座標は、１画素単位とし、左上がX=0、Y=0である。
【００６０】
この例では、１画素をXとYとが10×10のマトリックで１画素を分割し、各画素の値はURLをキックすることにより、返り値（Return Value）としてR=○、G=△、B=◇の計算結果が設定される。具体的には、下記のようなHTML形式で返り値が設定される。
【００６１】
<HTML>
<BODY>
<a>R=○</>
<a>G=△</>
<a>B=◇</>
</BODY></HTML>
また、自端末の処理能力（リソース）等についても、以下のようにａラインに記述する。
【００６２】
a=x_cpu_MIPS:300 x_MM:32 X_CPU_type=DSP x_CPU_INSTRUCTION_SET:aaaCDE
上記記述では、CPU MIPSは300MIPS、メインメモリは32Mbyte、CPUタイプはCISC、CPU  INSTRUCTION  SETはaaaCDEが、映像通信時の処理能力であることを示している。なお、複数のCPU  INSTRUCTION  SETがある場合は、以下のように複数記述してもよい。
【００６３】
a=x_CPU_INSTRUCTION_SET:aaaCDE x_CPU_INSTRUCTION_SET:bbbCDE  
また、aラインの各属性情報に関して記述されているURLが存在する場合には、以下のようにURLを記述することとしてもよい。
【００６４】
a=x_CPU_INSTRUCTION_SET@URL:http://hogehoge/aaaCDE
URLを記述することにより、当該URLをキックしてCPU  INSTRUCTION  SETを取得することとしてもよい。 
次に、呼処理キューに呼が入っている場合（Ｓ１０２：ＹＥＳ）、すなわち、映像通信端末１が受信端末の場合、相手端末能力取得部１３は、発信端末がＳ１０５で送信した映像入出力通信能力を受信する（Ｓ１１１）。本実施形態では、前述のSDPにより記述された相手端末の映像通信能力（映像入力通信能力、映像出力通信能力、処理能力）を受信する。
【００６５】
そして、受信端末の自端末能力取得部１２は、Ｓ１０４と同様に、自端末の映像入出力通信能力を取得する（Ｓ１１２）。
【００６６】
そして、受信端末の映像入出力方式決定部１４は、Ｓ１１１で受信した相手端末の映像入出力通信能力と、Ｓ１１２で取得した自端末の映像入出力通信能力とに基づいて、映像の入出力方式を決定する（Ｓ１１３）。
【００６７】
例えば、映像サイズとして、自端末と相手端末とで以下のように記述されているものとする。
【００６８】
自端末SDP（ビデオサイズは、QCIFおよびCIFが可能）
a=x_video_size:QCIF x_video_size:CIF
相手端末SDP（ビデオサイズは、QCIF、CIFおよびVGAが可能）
a=x_video_size:QCIF x_video_size:CIF x_video_size:VGA
映像入出力方式決定部１４は、自端末のSDPと相手端末のSDPとで、共通する能力を抽出し（ＡＮＤをとり）、以下のSDPを生成する。 
a=x_video_size:QCIF x_video_size:CIF
そして、映像入出力方式決定部１４は、抽出した能力のうち、最大の能力を選択する。上記の例では、CIFがQCIFの４倍のビデオサイズであるため、映像入出力方式決定部１４は、CIFを選択する。これにより、自端末と相手端末とは、ビデオサイズをCIFで通信する。
【００６９】
また、映像入出力方式決定部１４は、aラインが関数で示されている場合に、自端末の能力記述群をN、相手端末の能力記述群をMとし、左上の座標を原点とする。そして、原点から右方向を横軸Xとし、下方向を縦軸Yとする画素（X，Y）とした場合、映像入出力方式決定部１４は、関数ｆ（N,M,X,Y）で映像入出力方式を決定する。なお、XとYをパラメータとして含まない関数の場合は、関数ｆ（N,M）で入出力方式が決定される。
【００７０】
映像入出力方式決定部１４は、決定した映像入出力方式を、発信側の相手端末に送信する（Ｓ１１３）。なお、本実施形態では、「200 OK」（図１参照）とともに決定した映像入出力方式を送信する。そして、発信端末の映像入出力方式決定部１４は、Ｓ１２３で送信された映像入出力方式を受信し、「ACK」（図１参照）を受信端末に送信する（Ｓ１０６）。
【００７１】
これにより、発信端末と受信端末との間でメディア（映像、音声等）が送受信され、受信端末の映像入出力方式決定部１４が決定した映像入出力方式に基づいて、映像の入出力が行われる（Ｓ１２１）。すなわち、発信側および受信側の各映像通信端末の映像通信部１６は、RTPなどによりメディアを相手端末と通信する。また、各映像通信端末の映像入出力処理部１５は、通信されたメディアのCODEC(符号化、復号化)、映像入出力表現、音声入出力表現などの映像処理を行う。
【００７２】
例えば、ビデオサイズをCIFに決定した場合、ビデオの入出力方式としては、CIFで映像を入力し、CIFで映像を出力する。同様に、各種映像・音声のCODEC(符号化、復号化)、映像入出力表現、音声入出力表現などが、Ｓ１１３で決定された映像入出力方式で処理される。
【００７３】
なお、決定された映像入出力方式が関数型の場合、各映像入出力処理部１５は、当該関数を実行して、必要な値を取得し、他の処理実行する。例えば、関数がｆ（N,M,X,Y）の場合、当該関数ｆ（N,M,X,Y）を適宜N,M,X,Yを与えた結果を得て実行する必要がある。
【００７４】
そして、映像通信部１６は、メディアの通信が終了したか否かを判別する（Ｓ１２２）。メディアの通信を終了させる場合、いずれかの映像通信端末の映像通信部１６は、「BYEメッセージ」を相手端末に送信する。映像通信端末がテレビ電話の場合、オンフックしたときに「BYEメッセージ」を送信する。「BYEメッセージ」を受信した相手端末の通信処理部１６は、「200 OK」を返信する。
【００７５】
「BYEメッセージ」および「200 OK」を送信し、通信が終了した場合（Ｓ１２２：ＹＥＳ）、Ｓ１０１に戻り、呼処理キューを確認する。一方、通信が終了しない場合（Ｓ１２２：ＮＯ）、Ｓ１２１の処理を実行し続ける。
【００７６】
次に、本実施形態の具体的な処理を、さらに説明する。
【００７７】
ここでは、映像通信端末の入力装置をCMOSとし、出力装置をLCDとする。CMOSは、その性質上、光の量の読み出しが一定の時間となっていないため、読み出し時間にずれが生じてしまう。そのため、ずれたままの映像が相手端末に伝送されることを防止するために、発信側の映像通信端末は、CMOSのメディア処理能力に焦点をあてた下記のようなDSPを記述し、受信側の映像通信端末に送信する(図３：Ｓ１０５)。
【００７８】
m=video 52000 RTP/AVP 31
a=x_video_size:VGA x_coms_read_time_per_line:n
当該SDPを受信した映像通信端末のLCDが、読み出しの時間ずれを表示時に対応可能な場合、１行あたりの表示時間をずらすことにより、CMOSでの読み込み時に発生した映像のずれを補正することができる。
【００７９】
また、CMOSは、Bayer配列により仮想画素のRGB値を計算する。例えば、図４のBayer配列に仮想画素を図６に示すように配置したときのRGB値は、下記の式により算出される。
【００８０】
R=(9*R11+3*R03+3*R09+R01)/16
G=(G07+G19)/2
B=(9*B06+3*B08+3*B14+R16)/16
この式では、仮想画素は、映像の規格化に適した形式であるが、映像出力装置としてLCD（または、ブラウン管、PDP）を考えた場合、 LCDは図５に示すRGBの配列になっており、最適なRGB値とはいえない。
【００８１】
そこで、本実施形態では、CMOSにより映像を入力する側の映像通信端末のSDPを以下のようにする。
【００８２】
a=x_cmos_filter_no.1_start:○ x_coms_filter_no.1_end:△ x_filter_no.1:R
x_cmos_filter_no.2_start:■ x_coms_filter_no.2_end:◇ x_filter_no.2:G
x_cmos_filter_no.3_start:● x_coms_filter_no.3_end:◎ x_filter_no.3:B
x_cmos_array_grid_no.1:RGRG x_cmos_array_grid_no.2:GBGB
また、LCDにより映像を表示する側の映像通信端末のSDPを以下のようにする。
【００８３】
a=x_LCD_filter_no.1_start:○ x_LCD_filter_no.1_end:△ x_filter_no.1:R
x_LDC_filter_no.2_start:■ x_LCD_filter_no.2_end:◇ x_filter_no.2:G
x_LCD_filter_no.3_start:● x_LCD_filter_no.3_end:◎ x_filter_no.3:B
x_LCD_array_grid_no.1_per_pixel:RGB x_LCD_array_grid_no.2_per_pixel:RGB
x_LCD_array_grid_no.3_per_pixel:RGB
この２つのSDPに基づいて、映像入出力方式決定部１４は、映像を規格化することなく、端末間で映像を最適に送受信できる入出力方式を決定する(図３：Ｓ１１３)。
【００８４】
図７は、映像入出力方式決定部１４が、上記SDPに基づいて映像入力装置および映像出力装置の特性を考慮した映像表示例である。図７の場合、出力側の画素のRGB値は、以下の式により表すこともできる。
【００８５】
R=(16*R11/3+16/3/2*R11+R03)/16
G=(G10+G07)/2
B=(16*B06/3+16/3/2*B14)/16
これにより、本実施形態では映像を規格化することなく、映像入力装置および映像出力装置の特性を考慮した最適な映像表示を行うことができる。なお、上記式は、CMOSが図４のBayer配列で、LCDが図５のRGB配列の場合の計算式であるが、これ以外の入出力装置であっても、また、これ以外のRGM配列であっても適用することができる。
【００８６】
次に、本実施形態の比較例について説明する。
【００８７】
図８は、放送局が放送した映像をテレビ受像機が受信する処理を説明するため説明図である。放送局では、一般的に、カメラで撮像した映像を、放送規格などの所定の規格に基づいて規格化し、規格化した映像８１を電波で各家庭に流す。各家庭のテレビ受像機は、規格化された映像８２を受信し、当該規格に基づいて再構成した映像を映し出す。これにより、遠隔地の放送局が放送した映像を、各家庭のテレビ受像機が映し出すことができる。
【００８８】
このように映像を規格化して送受信する場合、映像出力端末（テレビ受像機など）が規格化された映像を処理する機能を実装していれば、入力装置（カメラなど）の個別の仕様・性能に左右されることはない。しかしながら、映像入力装置が高性能な場合、映像入力装置が撮像した映像は高精細であっても、規格化された時点で映像情報が欠落し、映像出力装置では高精細な映像を出力することができない。
【００８９】
テレビ放送においては、放送局側で最適な照度、カメラ等を映像入力装置として用いることにより、映像規格に十分足る映像入力能力を有するため、規格化された映像を送信することによる問題はない。しかしながら、端末間で映像を送受信する場合、放送局のような最適な照度、カメラ等を映像入力装置として用いることができないため、映像を規格化することによるデメリットが発生する場合がある。
【００９０】
図９は、映像通信端末同士で、規格化された映像を送受信する処理を説明するための説明図である。
【００９１】
端末Mの入力装置（カメラ）９１が撮像した映像は、受信側の端末Nに送信される前に、規格化され、規格化された映像９２が端末Nに送信される。そして、端末Nでは、規格化された映像９３を受信し、規格化された状態で当該映像をメモリ上に展開し、出力装置９４に出力する。端末Mと端末Nとの間で映像が規格化されることが、端末M、N各々が備える最大能力を発揮できない原因となる。すなわち、近年の映像入力装置および映像出力装置は、それぞれ高度な能力・性能を実装しているが、映像を一旦規格化して通信することにより、装置各々有する最大限の性能が発揮できなくなってしまう。
【００９２】
これに対し、本実施形態では、映像入出力装置が最大・最適な映像入出力能力を発揮できるようにするために、図１に示すように映像を規格化せず、互いの端末の能力を送受信して、映像入出力方式を決定する。これにより、本実施形態では、規格化した映像を送受信する場合と比べて、自端末および相手端末の能力をより最大限に生かした、より最適な映像通信を行うことができる。
【００９３】
すなわち、本実施形態では、映像をVGA、各画素RGB8bitの合計24bitなどの規格化することなく、映像入力装置の映像情報をそのまま出力装置に出力することにより、規格化による映像情報の欠落を最小限に防ぐことができる。
【００９４】
また、本実施形態では、INVAITEメッセージのSDPに、自端末の入出力装置が有する映像入出力通信能力を記述し、相手端末に送信する（図１参照）。すなわち、本実施形態は、図９に示す規格化した映像を送受信する場合と同じシーケンスであるため、シーケンスの変更を行うことなく容易に実装することができる。
【００９５】
＜第２の実施形態＞
以下、本発明の第２の実施の形態について、図面を参照して説明する。
【００９６】
本実施形態では、映像通信端末が最初から搭載している能力だけでなく、通信に必要な能力を外部からダウンロードして動作させる。通信に必要な能力は、例えば映像・音声などのメディアのCODECなどである。
【００９７】
図１０は、本発明の第２の実施の形態に係る映像通信端末のブロック図である。
【００９８】
本実施形態の映像通信端末は、ソフト／ハードダウンロード部１７、実行可能フラグ送信部１８、実行可能フラグ受信部１９およびソフト／ハード検証部２０を、さらに有する点において、第１の実施形態の映像通信端末（図２参照）と異なる。
【００９９】
ソフト／ハードダウンロード部１７は、自端末または相手端末が初期状態で保持していない映像入出力処理ソフトウェアまたはハードロジックをダウンロードする。なお、ハードロジックのダウンロードは、映像入出力処理をハード的にダイナミックに変更できるようなDynamic Reconfigurable Processorにおいて、映像入出力処理のハードロジックを外部のネットワークからダウンロードし、当該ハードロジックをDynamic Reconfigurable Processor上に搭載することにより、ソフトウェアをダウンロードしたのと同様に、当該ハードロジックがハードウェア的に実行可能となる。なお、ハードロジックのダウンロードは、ハードウェア自体をダウンロードすることではない。
【０１００】
実行可能フラグ送信部１８は、ソフト／ハードダウンロード部１７がダウンロードしたソフト／ハードを自端末で実行可能とするためにマイグレーション（migration）し、実行可能となった時点で、相手端末に実行可能フラグを送信する。
【０１０１】
実行可能フラグ受信部１９は、相手端末から送信された実行可能フラグを受信する。
【０１０２】
ソフト／ハード検証部２０は、第１の処理として、ダウンロードしたソフト／ハードを自端末で実行した場合、エラーが発生しないかを各種リソース（CPU、メモリ等）から検証する。すなわち、ソフト／ハード検証部２０は、自端末において実行可能フラグが送信された際に、最大計算量、最大メモリ使用量となる複雑な処理や全ての検証パターンを含んだメディアを相手端末と通信し、自端末の映像入出力処理が可能であるか否かを検証する。
【０１０３】
また、ソフト／ハード検証部２０は、第２の処理として、ダウンロードしたソフト／ハードが処理したメディアを、相手端末が処理可能かどうかを検証する。すなわち、ソフト／ハード検証部２０は、自端末および相手端末からそれぞれ実行可能フラグが送信された後に、最大計算量、最大メモリ使用量となる複雑な処理や全ての検証パターンを含んだメディアを相手端末と通信し、相手端末の映像入出力処理が可能であるか否かを検証する。なお、通常は、第１の処理の後に第２の処理を行う。
【０１０４】
ソフト／ハードの検証により、自端末内での処理が不可能な場合や、相手端末との通信が不可能な場合が判明したときは、映像入出力方式決定部１４の処理に戻り、再度、別のハード／ソフトを決定し、同様の処理を行う。
【０１０５】
次に、本実施形態の処理について説明する。
【０１０６】
図１１は、本実施形態の映像通信端末１の処理を示すフローチャートである。
【０１０７】
本実施形態の処理は、映像入出力方式決定部１４が映像入出力方式を決定し相手端末に送信した後（図３：Ｓ１１３）に、発信側および受信側の映像通信端末１がそれぞれ行う処理である。
【０１０８】
ソフト／ハードダウンロード部１７は、映像入出力方式決定部１４が決定した映像入出力方式のDSPを読み込む。そして、ソフト／ハードダウンロード部１７は、DSPのａラインにURLが記載されているか否かを判別する（Ｓ３０１）。すなわち、ａラインに“x_soft_hard_downLoad@URL”の属性が記述されている場合、当該aラインの上のライン（例えば、mライン）は、当該URLからダウンロードしたソフト／ハードを使用して映像入出力処理を行うこととなる。
【０１０９】
SDPでは複数の能力を記述できるため、下記では２つのmラインを記述した例を示す。
【０１１０】
m=video 52000 RTP/AVP 31
a=x_video_size:VGA
m=video 52000 RTP/AVP 500
a=x_video_size:VGAx_soft_hard_downLoad@URL:http//hoge.jp/soft500.bin
上記SDPの場合、一番上のmラインのaラインにはURLが記述されていないので、当該mラインの能力は、最初から映像入出力端末に搭載されている能力であることがわかる。一方、２番目のmラインの aラインには”VGAx_soft_hard_downLoad@URL“が記述されており、その後ろにダウンロードするためのURLが記載されている。すなわち、当該mラインを実行するためには、ソフト／ハードのダウンロードが必要となる。
【０１１１】
URLが記載されていない場合（Ｓ３０１：ＮＯ）は、当該映像入出力端末に搭載されている能力であるため、第１の実施形態のＳ１２１に進み、映像の通信および映像入出力処理を行う。
【０１１２】
URLが記載されている場合（Ｓ３０１：ＹＥＳ）、ソフト／ハードダウンロード部１７は、当該URLにアクセスし、ソフト／ハードをダウンロードして検証蓄積メモリ４１に記憶する（Ｓ３０２）。すなわち、ソフト／ハードダウンロード部１７は、SDPに記述されたURL（“http//hoge.jp/soft500.bin”）を読み込み、当該URLからソフト／ハードをダウンロードし、記憶する。なお、上記の例では、httpプロトコルを用いてダウンロードするが、FTPの場合であってもよい。
【０１１３】
そして、実行可能フラグ送信部１８は、検証蓄積メモリ４１に記憶されたソフト／ハードを、自端末で実行可能な状態にするためにマイグレーションする（Ｓ３０３）。すなわち、実行可能フラグ送信部１８は、検証蓄積メモリ４１に記憶されたソフト／ハードの番地を読み出し、ＣＰＵの実行番地にセットする。なお、検証蓄積メモリ４１は、映像入出力方式の検証用であるため、メモリの不正アクセス（利用されていないメモリへのアクセス等）を防止するために、当該メモリ上にある実行データ（ソフト／ハード）を実行する際には、１ステップづつエミュレートしながら実行する。すなわち、メモリの不正アクセスがあるかどうかを確認しながら実行する。そのため、ダウンロードしたソフト／ハードが不完全であっても、当該マイグレーションが他の処理に影響を与えないようにする。
【０１１４】
そして、ダウンロードしたソフト／ハードが実行可能な状態となった後、実行可能フラグ送信部１８は、相手端末に実行可能フラグを送信する（Ｓ３０４）。
【０１１５】
そして、実行可能フラグ受信部１９は、相手端末から送信された実行可能フラグを受信する（Ｓ３０５）。
【０１１６】
そして、ソフト／ハード検証部２０は、検証蓄積メモリ４１のソフト／ハードを実行し、エラーが発生しないかを検証する。具体的には、ソフト／ハード検証部２０は、メモリ、スタック等のリソースが不正に利用されていないかをメモリ管理ツール、スタック管理ツール等を利用して検証する（Ｓ３０６）。
【０１１７】
なお、ソフト／ハード検証部２０は、メモリの不正アクセス（利用されていないメモリへのアクセス等）を防止するために、当該メモリ上にある実行データ（ソフト／ハード）を実行する際には、１ステップづつエミュレートしながら実行する。すなわち、メモリの不正アクセスがあるかどうかを確認しながら実行する。そのため、ダウンロードしたソフト／ハードが不完全であっても、当該検証処理が他の処理に影響を与えないようにする。
【０１１８】
不正利用がある場合、すなわち、実際の動作として不適切な場合（Ｓ３０６：ＹＥＳ）、ソフト／ハード検証部２０は、ダウンロードしたURLとダウンロードしたソフト／ハードのMD5(Message Digest 5)値とを不正利用型のソフト／ハードとして、実行不可チェックリスト４２に登録する（Ｓ３０７）。ソフト／ハード検証部２０は、実行不可チェックリスト４２に登録されたソフト／ハードを、これ以降、実行しないこととする。なお、URLが異なるが同じソフト／ハードの場合には、MD5値を比較して不正利用型のソフト／ハードであるかを判別する。そして、Ｓ１１３に戻り、映像入出力方式決定部１４は、当該ダウンロードしたソフト／ハードの能力を削除し、次に最大・最適となる映像入出力方式を決定する。
【０１１９】
不正利用がない場合（Ｓ３０６：ＮＯ）、ソフト／ハード検証部２０は、CPUリソースの実行時の検証を行う（Ｓ３０８）。すなわち、ソフト／ハード検証部２０は、ダウンロードしたソフト／ハードを実際に動作させる環境と同じ環境で実行・動作させ、CPUリソースが、所定の値以上消費されていないかどうかをチェックする。
【０１２０】
所定の値以上、CPUリソースが消費されている場合（Ｓ３０８：ＹＥＳ）、実行不可チェックリスト４２に登録する（Ｓ３０７）。そして、Ｓ１１３に戻り、映像入出力方式決定部１４は、次に最大・最適となる映像入出力方式を決定する。
【０１２１】
なお、CPUリソースが所定の値以上消費される場合としては、例えば、無限ループなどが考えられ、他のプロセスがCPUリソースを利用することができなくなり、無応答状態となってしまうおそれがある。
【０１２２】
CPUリソースが所定の値以上、消費されない場合（Ｓ３０８：ＮＯ）、すなわち、当該ソフト／ハードが自端末で問題なく動作する場合、ソフト／ハード検証部２０は、当該ソフト／ハードを用いて、検証用のメディアを相手端末と通信し、相手端末の映像入出力処理が可能であるか否か（相互接続性）を検証する（Ｓ３０９）。すなわち、ソフト／ハード検証部２０は、Ｓ３０８と同様に、当該ソフト／ハードを実行し、そして、検証用のメディアを生成して相手端末と通信する。なお、検証用のメディアとしては、最大計算量、最大メモリ使用量となる複雑な処理や全ての検証パターンを含んだものとする。
【０１２３】
検証用のメディアを送信された相手端末のソフト／ハード検証部２０は、当該メディアの映像入出力処理が可能か否かを実行し、実行可否を送信元の端末に送信する。
【０１２４】
相手端末の映像入出力処理が可能な場合（Ｓ３０９：ＹＥＳ）、第１の実施形態で説明した、映像入出力処理部１５および映像通信部１６の処理（図３：Ｓ１２１）に進み、以降の処理を行う。一方、相手端末の映像入出力処理が不可能な場合（Ｓ３０９：ＮＯ）、ソフト／ハード検証部２０は、通信不可リスト４３に登録（Ｓ３１０）する。そして、Ｓ１１３に戻り、映像入出力方式決定部１４は、次に最大・最適となる映像入出力方式を決定する。
【０１２５】
なお、ソフト／ハード検証部２０は、通信不可となった相手端末のIPアドレスおよび端末情報を通信不可リスト４３に登録し、これ以降、通信不可リスト４３に登録された相手端末に対して当該ソフト／ハードを使用しないこととする。これは、オンザフライ方式で、能力の搭載検証を実施していることを意味する。例えば、利用する能力としてCODECを考えた場合、端末A−端末Cでは利用不可能なCODECであっても、端末A−端末Bでは利用可能な場合は当該CODECを利用することができる。
【０１２６】
本実施形態では、映像通信端末がソフト／ハードを外部からダウンロードする。これにより、本実施形態の映像通信端末では、当該端末が最初から搭載している能力だけでなく、外部からダウンロードしたソフト／ハードを用いて、相手端末と最適な映像入出力方式で映像等を通信することができる。すなわち、本実施形態では、upToDateな映像通信端末とすることができる。
【０１２７】
具体的には、新しい映像のCODECが開発された場合に、初期搭載の映像CODECしか搭載していない映像通信端末では、最大の表示能力を発揮できない。しかしながら、本実施形態では、新しい映像のCODECをダウンロードできるため、最大の表示能力を発揮することができる。
【０１２８】
また、本実施形態では、ダウンロードしたソフト／ハードが自端末で動作可能か、また、相手端末と通信可能（例えば、相手端末でCODECできるか）かの検証を行う。これにより、本実施形態では、前述のオンザフライ方式で能力の搭載検証を実施するため、端末A−端末Cでは利用不可能なCODECであっても、端末A−端末Bでは利用可能な場合は当該CODECを利用することができる。すなわち、ダウンロードしたソフト／ハードを実行する際に、相手端末毎に相手端末の実行可能性を検証するオンザフライ方式を用いることにより、相手端末毎に最大の能力を用いて通信することができる。
【０１２９】
＜第３の実施形態＞
以下、本発明の第３の実施の形態について、図面を参照して説明する。
【０１３０】
図１２は、本発明の第３の実施の形態に係る映像通信端末のブロック図である。
【０１３１】
本実施形態の映像通信端末は、ソフト／ハード情報ダウンロード部２１を、さらに有する点において、第２の実施形態の映像通信端末と異なる。
【０１３２】
ソフト／ハード情報ダウンロード部２１は、ソフト／ハードダウンロード部１７がソフト／ハードをダウンロードする前に、当該ソフト／ハードの仕様等、当該ソフト／ハードの実行に必要なソフト／ハード情報をあらかじめダウンロードする。例えば、IANA(Internet Assigned Number Authority;http://www.iana.org/)に登録されているような表記法に基づいて記述されたハード／ソフト情報を外部からダウンロードする。映像CODECの場合は例えばMPEG2MP@ML,H.261(番号であれば、31)を、音声CODECの場合は例えばG.711などのハード／ソフト情報をダウンロードする。
【０１３３】
そして、ソフト／ハード情報ダウンロード部２１は、ダウンロードしたソフト／ハード情報に基づいて、対応するソフト／ハードが自端末で実行可能か否かを判別する。実行可能な場合は、ソフト／ハードダウンロード部１７がソフト／ハードをダウンロードし、第２の実施形態の処理を行う（図１１参照）。一方、実行不可能な場合は、第１の実施形態のＳ１１３（図３参照）に戻り、映像入出力方式決定部１４は、当該ダウンロードしたソフト／ハードの能力を削除し、次に最大・最適となる映像入出力方式を決定する。
【０１３４】
本実施形態では、最初に、ソフト／ハード情報のみをダウンロードする。これにより、無駄なソフト／ハードをダウンロードせず、より効率的な処理を行うことができる。
【０１３５】
なお、本発明は上記各実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。
【図面の簡単な説明】
【０１３６】
【図１】映像通信処理の概要を説明するための説明図である。
【図２】本発明の第１の実施形態に係る映像通信端末の構成を示すブロック図である。
【図３】第１の実施形態の処理を示すフローチャートである。
【図４】Bayer配列の一例を示す図である。
【図５】LCDのRGB配列の一例を示す図である。
【図６】Bayer配列における仮想画素の配置例である。
【図７】映像入力装置および映像出力装置を考慮した映像表示例である。
【図８】比較例であるテレビの映像通信を説明するための説明図である。
【図９】比較例である規格化された映像の映像通信を説明するための説明図である。
【図１０】第２の実施形態に係る映像通信端末の構成を示すブロック図である。
【図１１】第２の実施形態の処理を示すフローチャートである。
【図１２】第３の実施形態に係る映像通信端末の構成を示すブロック図である。
【符号の説明】
【０１３７】
１  映像通信端末
１１  呼処理待ち受け部
１２  自端末能力取得部
１３  相手端末能力取得部
１４  映像入出力方式決定部
１５  映像入出力処理部
１６  映像通信部
１７  ソフト／ハードダウンロード部
１８  実行可能フラグ送信部
１９  実行可能フラグ受信部
２０  ソフト／ハード検証部
２１  ソフト／ハードダウンロード部
【図１】
2009017033.tif 000003
【図２】
2009017033.tif 000004
【図３】
2009017033.tif 000005
【図４】
2009017033.tif 000006
【図５】
2009017033.tif 000007
【図６】
2009017033.tif 000008
【図７】
2009017033.tif 000009
【図８】
2009017033.tif 000010
【図９】
2009017033.tif 000011
【図１０】
2009017033.tif 000012
【図１１】
2009017033.tif 000013
【図１２】
2009017033.tif 000014