(57)【特許請求の範囲】
【請求項１】
画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、
各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、
前記優先度識別子を有した符号化画像情報を送信又は記憶する送信管理手段とを含む画像符号化装置と、
前記符号化画像情報の受信または読み出しを行う受信管理手段と、
前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを含む画像復号化装置とを備え、
前記優先度識別子は前記画像復号化装置の処理能力に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化符号化装置。
【請求項２】
画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、
各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、
前記優先度識別子を有した符号化画像情報を画像復号化装置に送信又は記憶する送信管理手段とを備え、
前記優先度識別子は前記画像復号化装置の処理能力に従って各画像が前記画像復号化装置によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像符号化装置。
【請求項３】
画像符号化装置から伝送された優先度識別子を有した符号化画像情報および各画像に対してＩ，Ｐ，Ｂピクチャを識別するピクチャ識別子を受信または読み出しを行う受信管理手段と、
前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを備えた画像復号化装置であって、
前記優先度識別子は、前記ピクチャ識別子から独立しており、かつ前記画像復号化装置の処理能力に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化装置。
【請求項４】
画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、
各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、
前記優先度識別子を有した符号化画像情報を送信又は記憶する送信管理手段とを含む画像符号化装置と、
前記符号化画像情報の受信または読み出しを行う受信管理手段と、
前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを含む画像復号化装置とを備え、
前記優先度識別子は前記画像復号化装置の処理負荷に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化符号化装置。
【請求項５】
画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、
各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、
前記優先度識別子を有した符号化画像情報を画像復号化装置に送信又は記憶する送信管理手段とを備え、
前記優先度識別子は前記画像復号化装置の処理負荷に従って各画像が前記画像復号化装置によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像符号化装置。
【請求項６】
画像符号化装置から伝送された優先度識別子を有した符号化画像情報および各画像に対してＩ，Ｐ，Ｂピクチャを識別するピクチャ識別子を受信または読み出しを行う受信管理手段と、
前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを備えた画像復号化装置であって、
前記優先度識別子は、前記ピクチャ識別子から独立しており、かつ前記画像復号化装置の処理負荷に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化装置。
【請求項７】
画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、
各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、
前記優先度識別子を有した符号化画像情報を送信又は記憶する送信管理手段とを含む画像符号化装置と、
前記符号化画像情報の受信または読み出しを行う受信管理手段と、
前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを含む画像復号化装置とを備え、
前記優先度識別子は前記画像復号化装置の過負荷時に各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化符号化装置。
【請求項８】
画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、
各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、
前記優先度識別子を有した符号化画像情報を画像復号化装置に送信又は記憶する送信管理手段とを備え、
前記優先度識別子は前記画像復号化装置の過負荷時に各画像が前記画像復号化装置によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像符号化装置。
【請求項９】
画像符号化装置から伝送された優先度識別子を有した符号化画像情報および各画像に対してＩ，Ｐ，Ｂピクチャを識別するピクチャ識別子を受信または読み出しを行う受信管理手段と、
前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを備えた画像復号化装置であって、
前記優先度識別子は、前記ピクチャ識別子から独立しており、かつ前記画像復号化装置の過負荷時に各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化装置。
【発明の詳細な説明】
【０００１】
［技術分野］
本発明は、画像復号化符号化装置、画像符号化装置及び画像復号化装置に関するものである。
【０００２】
［背景技術］
従来より、自分側空間の風景の画像中から、例えば人物画像を抽出し、その画像と、相手側から送られてきた人物画像と、予め記憶されている相手側と共通的に表示するための仮想的な空間の画像とを重畳して表示することにより、相手が自分の前にいるという実在感を充足し、臨場感のある映像通信を目指したものがある（特公平４−２４９１４号公報、「ハイパーメディアシステム パーソナル コミュニケーション システム」（Fukuda, K., Tahara, T., Miyoshi, T.:″Hypermedia Personal Computer Communication System: Fujitsu Habitat″, FUJITSU Sci. Tech. J., 26, 3, pp.197-206(October 1990).）、中村：「ネットワーク対応仮想現実感による分散協同作業支援」、情報処理学会オーディオビジュアル複合情報処理研究会（１９９３））。特に、従来の技術では画像合成を行うための高速化、メモリーを低減する方法に関する発明が行われている（例えば、特公平５−４６５９２：画像合成装置、特開平６−１０５２２６：画像合成装置）。
【０００３】
しかしながら、従来の技術では、２次元の静止画や３次元のＣＧデータを合成する画像合成システムが提案されていたが、複数の動画や音声を同時に復号化（伸長）して、合成し表示させるシステムの実現方法については述べられていなかった。特に、複数の映像、音声を同時に復号、合成、表示できる端末装置において、端末の能力の不足や処理能力の変動に対して破綻を来さない映像や音声の再生方法については述べられていなかった。加えて、課金状況に応じて複数の映像を復号、合成、表示する方法については述べられていなかった。
【０００４】
具体的には、
（１）複数の画像、音声の情報、複数の画像と音声との関係を記述した情報、及び処理結果の情報を管理する方法。
（２）端末の処理状態が過負荷である場合の複数の画像や音声の復号、合成、表示の優先度の決定方法、再生および課金に関する方法。
【０００５】
更に、複数の映像、音声を同時に復号、合成、表示できる環境下で、受信端末側の状態や受信端末での復号、合成、表示の優先度に応じて画像の圧縮方法を変更して、符号化量を制御する方法に関しては考慮されていない。
【０００６】
［発明の開示］
本発明は、従来のこのような課題を考慮し、同時に複数の映像や音声の復号、合成を行う場合に、端末の処理状況に応じて符号化量を制御でき、また、課金状況に応じて複数の映像や音声の復号、合成、表示の制御ができる画像音声復号化装置と画像音声符号化装置及び情報伝送システムを提供することを目的とするものである。
【０００７】
本発明は、２次元の画像合成だけに限定されない。２次元の画像と３次元の画像を組み合わせた表現形式でもよいし、広視野画像（パノラマ画像）のように複数の画像を隣接させて画像合成するような画像合成方法も含めてもよい。
【０００８】
本発明で対象としている通信形態は、有線の双方向ＣＡＴＶやＢ−ＩＳＤＮだけではない。例えば、センター側端末から家庭側端末への映像や音声の伝送は電波（例えば、ＶＨＦ帯、ＵＨＦ帯）、衛星放送で、家庭側端末からセンター側端末への情報発信はアナログの電話回線やＮ−ＩＳＤＮであってもよい（映像、音声、データも必ずしも多重化されている必要はない）。また、ＩｒＤＡ、ＰＨＳ（パーソナル・ハンディー・ホン）や無線ＬＡＮのような無線を利用した通信形態であってもよい。
【０００９】
また、対象とする端末は、携帯情報端末のように携帯型の端末であっても、セットトップＢＯＸ、パーソナルコンピュータのように卓上型の端末であってもよい。
【００１０】
請求項１の本発明は、画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、各符号化された画像情報と前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、前記優先度識別子を有した符号化画像情報を送信又は記憶する送信管理手段とを含む画像符号化装置と、前記符号化画像情報の受信または読み出しを行う受信管理手段と、前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを含む画像復号化装置とを備え、前記優先度識別子は前記画像復号化装置の処理能力に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化符号化装置である。
【００１１】
請求項２の本発明は、画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、各符号化された画像情報と前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、前記優先度識別子を有した符号化画像情報を画像復号化装置に送信又は記憶する送信管理手段とを備え、前記優先度識別子は前記画像復号化装置の処理能力に従って各画像が前記画像復号化装置によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像符号化装置である。
【００１２】
請求項３の本発明は、画像符号化装置から伝送された優先度識別子を有した符号化画像情報および各画像に対してＩ，Ｐ，Ｂピクチャを識別するピクチャ識別子を受信または読み出しを行う受信管理手段と、前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを備えた画像復号化装置であって、前記優先度識別子は、前記ピクチャ識別子から独立しており、かつ前記画像復号化装置の処理能力に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化装置である。
【００１３】
請求項４の本発明は、画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、各符号化された画像情報と前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、前記優先度識別子を有した符号化画像情報を送信又は記憶する送信管理手段とを含む画像符号化装置と、前記符号化画像情報の受信または読み出しを行う受信管理手段と、前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを含む画像復号化装置とを備え、前記優先度識別子は前記画像復号化装置の処理負荷に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化符号化装置である。
【００１４】
請求項５の本発明は、画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、各符号化された画像情報と前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、前記優先度識別子を有した符号化画像情報を画像復号化装置に送信又は記憶する送信管理手段とを備え、前記優先度識別子は前記画像復号化装置の処理負荷に従って各画像が前記画像復号化装置によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像符号化装置である。
【００１５】
請求項６の本発明は、画像符号化装置から伝送された優先度識別子を有した符号化画像情報および各画像に対してＩ，Ｐ，Ｂピクチャを識別するピクチャ識別子を受信または読み出しを行う受信管理手段と、前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを備えた画像復号化装置であって、前記優先度識別子は、前記ピクチャ識別子から独立しており、かつ前記画像復号化装置の処理負荷に従って各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化装置である。
【００１６】
請求項７の本発明は、画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と、各符号化された画像情報と前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、前記優先度識別子を有した符号化画像情報を送信又は記憶する送信管理手段とを含む画像符号化装置と、前記符号化画像情報の受信または読み出しを行う受信管理手段と、前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを含む画像復号化装置とを備え、前記優先度識別子は前記画像復号化装置の過負荷時に各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化符号化装置である。
【００１７】
請求項８の本発明は、画像情報を符号化し、各画像に対してＩ，Ｐ，Ｂピクチャとしてピクチャ識別子を付与する画像符号化手段と各符号化された画像情報と、前記ピクチャ識別子から独立した優先度識別子とを対応付ける優先度付加手段と、前記優先度識別子を有した符号化画像情報を画像復号化装置に送信又は記憶する送信管理手段とを備え、前記優先度識別子は前記画像復号化装置の過負荷時に各画像が前記画像復号化装置によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像符号化装置である。
【００１８】
請求項９の本発明は、画像符号化装置から伝送された優先度識別子を有した符号化画像情報および各画像に対してＩ，Ｐ，Ｂピクチャを識別するピクチャ識別子を受信または読み出しを行う受信管理手段と、前記優先度識別子を有した符号化画像情報を復号化する画像復号化手段とを備えた画像復号化装置であって、前記優先度識別子は、前記ピクチャ識別子から独立しており、かつ前記画像復号化装置の過負荷時に各画像が前記画像復号化手段によって処理されるか否かを決定するために用いられ、更にＩピクチャの画像に複数段階の優先度を付与するものである画像復号化装置である。
【００１９】
［発明の実施の形態］
以下に、本発明をその実施の形態を示す図面に基づいて説明する。本発明で使用する「画像」の意味は静止画と動画の両方を含む。また、対象とする画像は、コンピュータ・グラフィックス（ＣＧ）のような２次元画像とワイヤーフレーム・モデルから構成されるような３次元の画像データが混合したものであってもよい。この場合、画像間の関係はワイヤーフレームモデルに相当する。記述するためのスクリプト言語としてはＪＡＶＡやＶＲＭＬなどが挙げられる。
【００２０】
図１及び図２は、本発明の一実施の形態における画像復号化符号化装置の概略構成図である。図１は、音声の再生機能をもたない場合の構成であり、図２は、画像と音声の再生機能をもつ場合の構成である。当然のことながら音声だけの場合も、同様に構成できる。
【００２１】
図１あるいは図２の本装置は、符号化装置及び復号化装置から構成され、図１の場合の符号化装置は、符号化された画像の過負荷時の処理の優先度を予め決められた基準で決定し、その符号化画像と優先度とを対応づける優先度付加部１０１、画像を符号化する画像符号化部１０２、優先度が付加された符号化情報を送信あるいは記録する送信管理部１０３、及び符号化された情報を受信する受信管理部１０４から構成されている。また、図２の場合の符号化装置は、更に、音声を符号化する音声符号化部１０５が設けられている。
【００２２】
一方、復号化装置において、情報を受信する受信管理部１１と情報を送信する送信管理部１３は、同軸ケーブル、ＣＡＴＶ、ＬＡＮ、モデム等の情報を伝送する手段である。端末の接続形態としては、ＴＶ電話やＴＶ会議システムのように端末間で双方向で映像情報を送受信する形態や、衛星放送やＣＡＴＶ、インターネット上での放送型（片方向）の映像放送の形態が挙げられる。本発明では、このような端末の接続形態について考慮している。
【００２３】
分離部１２は、符号化（圧縮）された受信情報を解析し、分離する手段である（圧縮装置の場合は、逆操作で多重化部になる）。たとえば、ＭＰＥＧ１やＭＰＥＧ２、Ｈ．３２０端末（Ｎ−ＩＳＤＮを利用したＴＶ電話／会議装置の規約）ではＨ．２２１が、Ｈ．３２４端末（アナログ電話回線を利用したＴＶ電話／会議装置の規約）ではＨ．２２３がビデオ／音声／データを多重化、分離する規約である。本発明は、規約に準じた構成で実現してもよいし、規約に準じない構成で実現してもよい。また、Ｈ．３２３やインターネットで行われているように、映像と音声はそれぞれ別ストリームで独立して伝送してもよい。
【００２４】
優先度決定部１４は、分離部１２から得られた情報（例えば映像、音声、管理情報）を、以下の方法で、端末が過負荷である場合の復号（以後、「伸長」を用いる）の優先度を決定して画像の伸長や音声の伸長を行う（処理の優先度の決定方法は、予め受信端末装置で取り決めしておいてもよいし、送信側端末（符号化装置）で記録メディアや送信パケットなどに、下記の方法で決定された優先度に関する情報を付加して伝送、記録フォーマットとして付加しておいてもよい。優先度に関する表現方法としては、優先度「大」、「中」、「小」といった数値化していない表現や１、２、３といった数値化した表現でもよい）。
【００２５】
複数の画像もしくは音声フレームから構成されるストリーム単位でのデータの扱いをするための識別子を用いて、送信側と受信側とでデータの送受信の処理を行うことで、受信側のバッファの管理や送信側のデータの送信のスケジューリングが可能となる。つまり、必要に応じて送信側から送付するストリームの識別子を通知して受信側の受け入れ状況を調べたり、必要としないストリームの識別子の受信端末への通知、受信側から必要なストリームを要求したりすることが可能となる。
【００２６】
符号化された情報の過負荷時の処理の優先度を前述した基準で決定し、符号化された情報と決定された優先度とを対応づける優先度付加手段を画像符号化装置や音声符号化装置に備え、受信された種々の情報の過負荷時の優先度に従って、処理の方法を決定する優先度決定手段で、処理すべき優先度の画像フレームや音声を決定し、復号、合成処理を行う。尚、画像フレームに関しては、フレームスキップが行えるようにフレーム内符号化（Ｉフレーム）を行ったフレームを定期的に挿入する必要がある。
【００２７】
優先度を付加する単位としては、映像や音声の各フレーム単位（フレーム間同士の優先度の比較）、複数のフレームから構成されるストリーム単位であってよい（ストリーム間同士の優先度の比較）。
【００２８】
画像の特徴に着目した方法としては、画像の圧縮形式（例えば、Ｈ．２６３とランレングスならランレングスを優先させる）、画像のサイズ（例えば、ＣＩＦとＱＣＩＦならばＱＣＩＦを優先させる）、コントラスト（例えば、コントラストの明るいものを優先させる〉、画像の合成比率（例えば、合成比率の高いものを優先させる）、量子化ステップ（例えば、量子化ステップの小さな値のものを優先させる）、フレーム間符号化とフレーム内符号化の違い（例えば、フレーム内符号化を優先させる）、表示位置（例えば、表示位置が中央のものを優先させる。また、３次元画像であれば、画像が奥に配置される場合は、優先度を低く、手前に表示される場合には優先度を高く設定する）、フレーム番号（第１フレームと最終フレームは優先度を高くする、シーンチェンジのフレームの優先度を高める等）やフレーム数（例えば、再生すべきフレーム数が少ない画像は優先度を高くする。フレーム番号はＨ．２６３の場合、テンポラリー・リファレンス（ＴＲ）に該当し、ＴＲの値の変化に基づいて判断すればよい）、有音区間と無音区間、表示時刻（ＰＴＳ）、復号時刻（ＤＴＳ）に基づく方法が挙げられる。
【００２９】
加えて、フレーム間符号化されたＰフレームやＢフレームは同一の優先度を割り当てる。また、フレーム内符号化された画像に複数段階の優先度を割り当てることにより、スキップする頻度を制御できる。
【００３０】
また、メディアの違いに着目した例としては、音声の伸長を画像の伸長よりも優先的に行う方法が挙げられる。これにより、音声を途切らすことなく音声の再生を行うことができる。
【００３１】
さらに、受信側端末で管理している再生の許可情報をもとに、伸長すべき情報（画像、音声）の決定を行ってもよいし、送信側より制御情報として送る再生許可の情報をもとに、伸長すべき情報の選択を行ってもよい。再生許可の情報は、具体的には、課金に関する情報（例えば、課金が行われていなければ、伸長、合成、表示の処理を行わない。受信端末側で、課金に関する情報を管理してもよいし、送信側で課金情報を管理してもよい）、サービスの内容を示す情報（例えば、成人向きの放送で端末側で再生の許可が出ていなければ、伸長、合成、表示の処理を行わない。再生の許可は受信側端末で管理してもよいし、送信側端末で管理してもよい）、パスワード（例えば、特定の番組にはパスワードを入力しなければ、伸長、合成、表示を行わない。パスワードは受信側端末で管理してもよいし、送信側端末で管理してもよい）、利用者コード（例えば、許可が与えられている利用者でなければ、伸長、合成、表示は行わない。利用者コードは受信側端末で管理してもよいし、送信側端末で管理してもよい）、国別コード（例えば、国によって、伸長、合成、表示すべき画像や音声、再生方法を変更する。国別コードは、送信側で管理してもよいし、受信側で管理してもよい。国別コードで再生方法を変えることによってスクランブルが実現できる）。
【００３２】
課金に関する情報、サービスの内容を示す情報、パスワード、利用者コードといった画像や音声の再生許可の制限をかけた再生方法としては、画像の合成、表示を行う際に故意に位置や画素をずらしたり、画像の拡大・縮小、画像のサンプリング（たとえばローパスをかけるとか）を変更、画素反転、コントラストの変更、カラーパレットの変更、フレームのスキップを行う方法などが挙げられる。これら画像の再生方法（画像の伸長、合成、表示）は、１フレーム毎に制約をかけてもよい。あるいは、画像圧縮の１つであるＨ．２６３で定義されるような１フレームよりも小さく、独立して処理できる単位であるＧＯＢ（Ｇｒｏｕｐ  Ｏｆ  Ｂｌｏｃｋ）単位で、画像の伸長、合成、表示方法に制約をかけてもよく、これにより、従来から行われている画面全体を乱す手法よりも柔軟な制御が可能になる。つまり、ＧＯＢ単位で処理することにより、画面の一部分だけにスクランブルをかけることができるため、画像合成を使ったソフトのようにインタラクティブなソフトに対する評価が可能となる。
【００３３】
同様に、音の再生方法としては、音の大きさを変更させる、音の方向を変更させる、音の周波数を変更させる、音のサンプリングを変更させる、異なる画像や音声を挿入する方法が挙げられる（いずれの方法も、あらかじめ送信側で処理する方法と、受信側で処理する方法が挙げられる）。
【００３４】
画像と音声の再生方法としては、画像と音の同期をはずす方法が挙げられる。合成、表示の順位を示す情報（予め表示する順序を受信側の端末で決めておく、例えばＣＩＦや静止画を優先するなど、また、送信側で、送信情報に表示する順序を優先度に関する情報として付加しておく方法も挙げられる）、伸長の順位を示す情報（予め伸長する順序を受信側の端末で決めておく、たとえばＱＣＩＦや、フレーム内符号化の画像データを優先させるなど、ＢＧＭよりも会話音を優先して伸長するなどが挙げられる。同様に、送信側で、送信情報に表示する順序を付加しておく方法も挙げられる）、利用者の指示（たとえば、利用者の指示により、伸長、合成、表示すべき画像や音声情報を選択させるか、要望に応じて選択した情報をもとに、伸長、合成、表示すべき画像や音声情報を決定する）、端末の処理能力（たとえば、現在もしくは過去の一定期間のＣＰＵの処理の占有時間を計測することにより、処理時間がかかりそうな画像や音声の伸長、合成、表示を抑制する。処理時間の推定方法としては、圧縮を行う際にローカル・デコードにかかった時間や、圧縮にかかった時間を圧縮した画像情報とともに対応づけて管理することにより、伸長、合成、表示の有無、優先度の決定を行うことができる）、再生時刻（たとえば、再生時刻を過ぎた画像、音声情報の伸長、合成、表示は中止する）や復号時刻により、伸長すべき画像や音声の優先度、有無を決定してもよい。
【００３５】
加えて、特定の画像や音声だけが優先的に伸長、表示されるのを防ぐための方法として、画像や音声の伸長、合成、表示の処理を行う実施率に関する情報に基づいて、伸長、合成、表示すべき画像の順番や有無を決定することができる。例えば、伸長を行う１０回のうち１回はＣＩＦサイズの画像の伸長を行うと受信端末側で設定しておくか、送信側で画像や音声の伸長、合成、表示の実施率を規定してそれに基づいて画像情報や音声情報を送信する方法が考えられる。実施率は具体的には、Ｉフレーム（フレーム内符号化したフレーム）の挿入間隔で定義できる。これにより、特定の画像や音声オブジェクトのみが伸長、合成、表示されることはなくなる。
【００３６】
これら伸長、合成、表示を制御する優先度に関する情報の付加は送信側の装置だけではなく、中継を行う装置で付加、制御してもよい。また、受信端末の復号装置の優先度決定部１４で決定した優先度に関する情報を、送信管理部１３を通じて送信先に送信することで、優先度決定部１４の決定状況に応じた画像、音声伝送を行うことが可能となる（選択されにくい画像オブジェクトのＩＤを送信側へ送ることにより、無駄に送信されることがなくなる）。尚、受信端末が過負荷である場合の処理の優先度を示す情報は、受信端末装置で取り決めてもよいし、伝送フォーマットとして伝送してもよいし、ＣＤ−ＲＯＭやハードディスクのような記録メディアに記録するためのフォーマットとしてＭＰＥＧ２のトランスポートストリームを拡張してもよいし、標準化を考慮しない伝送、記録フォーマット形式であってもよい。また、メディア毎（映像、音声、映像と音声の関係を記述した情報）に別々のストリームとして、多重化を行わずに伝送、記録してもよい。
【００３７】
画像復号手段としての画像伸長部１８は画像の伸長処理を行う手段であり（以降、符号化装置の場合は符号化手段）、画像伸長部１８で扱う画像フォーマットとしてはＭＰＥＧ１やＭＰＥＧ２、Ｈ．２６１、Ｈ．２６３等が挙げられる。画像の伸長は１フレーム単位で行っても、Ｈ．２６３で規定されているＧＯＢ単位の処理であってもよい。１フレーム単位で処理する場合、フレーム間符号化を行う場合、前フレームの伸長状態を画像伸長部１８に記憶しておく必要がある。ＧＯＢ単位での画像伸長を行った場合、画像の伸長の順序関係は問題ではなくなる。従って、ＧＯＢ単位で伸長処理を行う場合、複数の画像伸長部１８を受信装置に持つ必要はなく、１つの画像伸長部１８で複数の映像の伸長を行うことが可能となる。反面、伸長結果を蓄えておく必要がある。
【００３８】
図２の音声復号手段としての音声伸長部２０は音声の伸長を行う手段であり、音声伸長部２０で扱う音声フォーマットとしてはＧ．７２１やＧ．７２３等が挙げられる。処理のための方法としては、ＤＳＰや汎用ＣＰＵによるソフトウェア処理や専用のハードウェアによる処理が挙げられる。
【００３９】
ソフトウェアで実現する場合は、画像および音声の伸長処理をそれぞれ１つのプロセスあるいはスレッドの単位で管理し、伸長すべき画像や音声が同時に複数ある場合、処理できる範囲の数のプロセスあるいはスレッドで時分割して処理する。
【００４０】
画像伸長管理部１５は画像の伸長の状態を管理する手段である。また音声伸長管理部１６は音声の伸長の状態を管理する手段である。例えば、これら管理部を、ソフトウェアで実現する場合は、分離部１２から得た圧縮された情報を決められた手順（例えば、最初に音声伸長部２０から実行し、次に画像伸長部１８で実行する）で、画像伸長部１８、音声伸長部２０に引き渡し、伸長の状態を監視する。すべての伸長が完了すれば、画像合成部１９もしくは音声合成部２１に、伸長された情報を引き渡す。ソフトウェアでは共有メモリーとセマフォを用いることで、引き渡す情報を制限したり、伸長処理が終了したことを知る（詳細については後述する）。
【００４１】
時間情報管理部１７は時間に関する情報を管理する手段である。例えば、システムをパーソナルコンピュータで実現する場合には、時間情報はパーソナルコンピュータのタイマーを利用して実現すればよい。
【００４２】
画像合成部１９は、伸長された画像データをもとに画像合成を行う。複数の画像の合成を行う場合、それぞれの画像の合成比率（α値）をもとに画像合成を行う。例えば、２つの画像を合成する場合で、前景画像の合成比率がαの場合、背景画像のＲＧＢ値を１−α、前景画像をαの割合で混合する。尚、伸長すべき画像は１フレーム単位で処理の管理を行うことにより、表示時刻を用いて複数の画像を合成する場合にシステムの構成と実装が簡単化できる。また、画像合成部１９もしくは音声合成部２１で、送信側から伸長結果を破棄する指示が来るまで、伸長結果を保持して管理、利用することで、送信側から同一パターンの情報を繰り返し送信する必要をなくすことができる。
【００４３】
画像同士や音声同士の関係を記述した情報に基づき、画像や音声を合成する際に、必要とする復号された画像や音声が用意されていなくて、合成できない画像や音声が存在することを提示することで、利用者は合成の状態を知ることができる。そこで、利用者が必要な画質を選択したり、合成したい画像を予め選択するなどの指示を行うことで、必要な情報を取りこぼさずに合成することが可能となる。尚、復号化された画像や音声のデータをバッファに蓄積、管理する方法としては、到着順に古いものから順に消去してゆくか、画像同士、音声同士の関係を記述したスクリプトをみて、全体としての復号化された画像や音声のデータの使用状況をみて消去する方法が考えられる。
【００４４】
音声伸長管理部１６は、少なくとも１っ以上の音声の伸長を行う音声伸長部２０の伸長状態を管理する。
【００４５】
音声合成部２１は、伸長された情報をもとに音声合成を行う手段であり、合成結果蓄積部２２は、画像合成部１９が合成した画像と、音声合成部２１が合成した音声を蓄積する手段である。
【００４６】
再生時刻管理部２３は、再生を開始すべき時刻に、合成した画像や音声を再生する手段である。
【００４７】
出力部２４は合成結果を出力する手段（例えば、ディスプレイ、プリンタなどである）、入力部２５は情報を入力する手段（例えば、キーボード、マウス、カメラ、ビデオなどである）である。端末制御部２６は、これら各部を管理する手段である。
【００４８】
図３は、通信、記録フォーマットで優先度に関する情報を付加する場合の例を説明する図である。
【００４９】
図３（ａ）の例は、完全にすべてのメディア（映像、音声、制御情報）を多重化している例である。制御情報として、過負荷時の処理を決定するための優先度（本発明で指している優先度）や表示の順序を示す優先度が示されている。また、制御情報としては、画像同士、音声同士、画像と音声との関係（時間的、位置的なもの）に関する情報を記述しておいてもよい。図３（ａ）の例では、たとえば、ＭＰＥＧ１／２の多重化、Ｈ．２２３のような制御情報とデータ（映像、音声）を混在させるパケット多重の適用に向いている。尚、過負荷時の処理の優先度はフレーム単位もしくはストリーム単位で付加する。
【００５０】
図３（ｂ）の例は、メディア毎に情報を多重化している例である。この例では、制御情報、画像情報、音声情報は別々の通信ポートから送信される。画像同士、音声同士、画像と音声との関係に関する情報は制御情報として、画像や音声とは別の通信ポートから送信すればよい。Ｈ．３２３やインターネットのように複数の通信ポートを同時に確立できる場合の適用に向いており、図３（ａ）と比べて多重化の処理が簡略化できるので、端末の負荷が軽減できる。
【００５１】
画像同士と音声同士の記述方法として、ＪＡＶＡ、ＶＲＭＬといった記述言語などで対応が可能であると思われるが、スクリプトの記述言語の仕様が一意に定まらない状況も考えられる。そこで画像同士、音声同士の関係（例えば、位置的な情報、時間的な情報（表示期間など））を記述した情報の記述方法を識別するための識別子を設けることで、複数種類の記述方法に対応することができる。情報の記述方法を識別するための識別子の付加方法としては、例えば、ＭＰＥＧ２においては、ＭＰＥＧ２−ＴＳのストリームを管理するプログラム・マップテーブルに設けるか、スクリプトを記述したストリームに設けることで対応できる。過負荷時の処理の優先度は画像と音声との対応関係を記述した情報とともに付加する（制御情報）。尚、ＭＰＥＧ２においては、ＭＰＥＧ２−ＴＳ（トランスポート・ストリーム）のビデオ・ストリーム、オーディオ・ストリームを関係づけるプログラム・マップテーブルで管理できるように、画像と音声との対応関係づけを行う構造情報・ストリームを定義して管理すれば、ＭＰＥＧ２でもデータと独立して伝送することができる。
【００５２】
図４は、ソフトウェアで木発明を構成した場合の例を説明する図である。マルチタスク・オペレーションが可能なオペレーティング・システム上で本発明を実現した場合、図１や図２で説明した各処理は、プロセス、スレッドといったソフトウェアの実行モジュール単位に分けられ、各プロセス、スレッド間は共有メモリーにより情報の交換を行い、セマフォ（図４の例では、実線で示された部分がセマフォに対応する）によって共有する情報の排他制御を行う。以下に、各プロセス、スレッドの機能について述べる。
【００５３】
ＤＥＭＵＸスレッド３１はネットワークやディスクから多重化された情報（映像、音声、制御情報）を読み取り、音声、映像及び、音声と映像との対応関係と再生時間に関する情報とを記述した監視用テーブル（詳細は後述する）に分離する。ＤＥＭＵＸスレッド３１は前述の分離部１２に対応する。ＤＥＭＵＸスレッド３１で分離された情報は、音声用のリングバッファ３２、映像用のリングバッファ３３、監視用のリングバッファ３４にそれぞれ送出される。音声情報である場合、リングバッファ３２に送出された情報は、音声デコードスレッド３５（前述の音声伸長部２０に対応する）で伸長される。映像情報である場合、リングバッファ３３に送出された情報は、デコードプロセス３６で伸長される。
【００５４】
監視用テーブルに関しては、リングバッファ３４に送出され、映像を伸長するための順序を決定するために監視スレッド３７（前述の端末制御部２６、画像伸長管理部１５、音声伸長管理部１６に対応する）で利用される。また、同じ監視用テーブルが画像合成のために画像合成スレッド３９で利用される。監視スレッド３７で利用された監視用テーブルは、すべての音声、画像の伸長が終わった時点で、次のテーブルをリングバッファ３４から読み出す。デコード・プロセス３６（前述の画像伸長部１８に対応する）で伸長された画像情報は映像用シングルバッファ３８に送出される。送出された画像情報が揃った時点で、画像合成スレッド３９（前述の画像合成部１９に対応する）にて、監視用テーブルで管理される画像合成の比率を用いて画像合成を行う。合成結果は、合成用バッファ４１（前述の合成結果蓄積部２２に対応する）に蓄積され、表示監視スレッド４２で表示時間になるまで表示待ちの状態で待機する（前述の再生時刻管理部２３に対応する）。
【００５５】
図５は、図４の構成で用いられる情報の構造について説明する図である。図５の例では、ディスクもしくはネットワークから受信した情報は１８８ｂｙｔｅの固定長である（Ｂ）。ＤＥＭＵＸスレッド３１で分離された音声情報の構造は、パケット同期用のコード、再生時刻、再生すべき音声の長さを示すフレーム長、音声データからなる（Ｃ）。映像情報の構造は、パケット同期用のコード、画像を識別するためのフレーム番号、画像情報の大きさを示すフレーム長、画像データからなる（Ｄ）。本発明は１フレーム単位での処理である必要はなく、マクロブロック単位のような小さなブロック単位での処理を行っても構わない。
【００５６】
監視用テーブルの構造は、画像の表示時間、１フレームで表示（合成）すべき画像の数、各画像のＩＤ、フレーム番号、伸長や表示を行う優先度、フレームのタイプを示す識別子（Ｉピクチャ、Ｐピクチャ、Ｂピクチャ）、表示の水平位置、表示の垂直位置、合成の比率を示す階層の各情報から構成される（Ｅ）。なお、画像の合成比率と音声の合成比率を対応づけて変化させてもよい。例えば、画像、２種類が、それぞれ音声２種類に対応する場合、画像の合成比率がα：１−αである場合、対応する音声の合成比率もα：１−αで対応づけてもよい。画像情報同士の関係だけではなく、音声同士の関係も記述してもよい（例えば、方向、種類（ＢＧＭ、会話音））。
【００５７】
図６は、ＤＥＭＵＸスレッド３１の動作について説明する図である。ファイルもしくは、ネットワークから１８８バイトの固定長のデータを読み込む（５−１）。読み込んだデータを分析し、前述の音声、映像、監視用テーブルの構造の型にセットする（５−２）。リングバッファへの書き込みが可能であれば、音声、映像、監視用テーブルをそれぞれのリングバッファに書き込みを行う。画像オブジェクトＩＤと複数ある画像伸長手段との対応関係をとる。例では、若い番号のオブジェクトＩＤから若いリングバッファ番号の共有メモリーへ順に書き出す（５−３）。書き込んだバッファのライトポインタを更新する（５−４）。監視用テーブル１つ分の映像、音声の情報を書き込んだら監視スレッド制御用セマフォのカウンターを進める（５−５）。このようにＤＥＭＵＸにより監視スレッドの制御を行う。
【００５８】
図７は、監視スレッド３７の動作について説明する図である。監視用のテーブルを読み込みリードポインタを進める（６−１）。過負荷時のオブジェクトの優先度をチェックして、優先度の高い画像フレームを調べる。（６−２）。監視用テーブルの内容を合成側のスレッドへ渡す（６−３）。ＤＥＭＵＸからの監視用テーブル１個分のデータの作成を待つ（６−４）。処理の優先度の高い順に、表示を行う画像のフレーム番号をデコードプロセスに書き（６−５）、現在の時刻と表示すべき時刻を比べて、間に合っていなかったらＩフレームをスキップせずに、ＰＢのフレームだけをスキップする（６−６）。対応するデコード・プロセスの実行を許可し（６−７）、処理が完了するまで待つ（６−８）。
【００５９】
図８は、デコード・プロセス３６の動作について説明する図である。監視スレッド３７から実行の許可が出るまで待機する（７−１）。入力画像の状態をチェックし、画像のシリアル番号、入力されるフレームはスキップすべき画像かどうかを調べる（７−２）。デコードすべき画像データがリングバッファに溜まるまで待つ（７−３）。監視スレッドから指示された画像のシリアル番号に対応する画像データがなければ、デコードをスキップし、リードポインタを進める（７−４）。入力画像のスキップでなければ、デコードの処理を実行し、リードポインタを進める（７−５）。デコードの結果を出力し（７−６）、監視スレッド３７に処理が終了したことを通知する（７−７）。
【００６０】
同じプロセス（スレッドであってもよい。ハードウェアである場合はプロセッサ）を利用して異なる種類のオブジェクトを伸長する場合、デコード・プロセス３６内で過去に伸長した画像のフレーム番号と伸長される前の画像とを対応づけて管理することにより、同時にたくさんのプロセスを生成して利用する必要がなくなる（最低、直前のフレームに関する情報だけでもよい。また、Ｉ、Ｐ、Ｂというように異なるタイプのフレーム画像が存在する場合は、管理される順序と出力すべき順序とが異なるのでデコード・プロセス３６におけるこのような管理は必要となる）。
【００６１】
図９は、画像合成スレッド３９の動作について説明する図である。監視スレッド３７から監視用テーブルを待つ（８−１）。処理する画像の優先度をチェックする（８−２）。優先度の高い順にデコード結果の画像を待つ（８−３）。表示位置にあわせた画像の合成を行う（８−４）。合成結果を合成用バッファ４１に書き込む（８−５）。表示を行うべき画像情報の選択は画像伸長手段もしくは画像合成手段で行うことができる。表示すべきではない画像オブジェクトＩＤをスキップする場合、画像合成手段へは伸長結果が出力されないことを通知する必要がある。音声に関しても再生すべき音声情報の選択を音声伸長手段もしくは音声合成手段で行うことができる。
【００６２】
図１０は、表示監視スレッド４２の動作について説明する図である。合成画像が書き込まれるのを待つ（９−１）。初めての表示である場合、表示を開始した時刻を取得し（９−２）、表示を行うべき時刻との対応関係を管理する。表示時刻に達していなければ、達していない時間だけ待機し、合成画像の表示を遅らせる（９−３）。
【００６３】
図１１を用いて本発明の画像合成装置のユーザインターフェースについて説明する。
【００６４】
図１１の例では、背景画像に、前景画像が合成され、遠くに位置する建物が合成比率０．５で半透明に画像合成されている。図１１に示したように、使用する画像は２次元画像でなくてもよい。前景に３次元画像としてヘリコプターと気球が、２次元の画像である背景と合成されている。なお、前景のヘリコプターと気球は必ずしも常に３次元の画像である必要はない。遠くに位置する場合（画面上に２次元として表示される大きさで定義しておけばよい。たとえば２０ドット×２０ドットの大きさよりも小さければ対象物は遠くに存在すると定義しておけばよい）には、２次元で表現しておき、近くに位置する場合には３次元で表現してもよい。また、３次元画像のワイヤーフレーム・モデルにマッピングする画像も静止画だけではなく、動画像であってもよい。画質に関しては中心部分の画質は高く、周辺部分へいくほど荒くすることで、ユーザの望む必要な情報を優先的に、選択して伝送することができる（このように、画像が合成される位置に応じて、画質を変更することで応答性の向上が期待できる）。また、３次元画像である場合、遠方に表示される画像の優先度は低く、近くに表示される画像の優先度は高く設定すればよい。なお、画質の制御に関しては量子化ステップを変更することにより実現できる。
【００６５】
図１２は、受信側端末の能力の変動に応じた画像伝送を行う方法について説明した図である。次に、伝送される画像が多くなることにより、受信端末の処理が過負荷になるのを防ぐために、圧縮装置を含めて、管理、制御する方法について述べる。例えば、ハードウェアで実現されているＭＰＥＧ２ベースのビデオ・オン・デマンドシステムでは、送信側の端末は受信側の端末の性能（たとえば、画像圧縮できる方式やサイズ、通信プロトコル）を、映像情報を送信、受信する前にお互いに確認する。このため、送信側端末では、受信側端末の処理能力がほぼ確定しているため、受信側端末の受信状況や再生の状況を逐次、モニターする必要はない。
【００６６】
一方、ハードウェアで画像の圧縮と伸長を実現する場合は、端末で画像の圧縮と伸長を行える個数は固定である。しかし、ソフトウェアで画像の圧縮と伸長を実現する場合は、端末で画像の圧縮と伸長が行える個数を動的に可変にできる。又、ソフトウェアでマルチタスク環境下で画像の圧縮と伸長を行う場合、画像サイズや、画像圧縮を行うための量子化パラメータ、対象とする画像（フレーム内符号化かフレーム間符号化、撮影された画像の内容）等によって大きく影響し、端末で処理（圧縮、伸長）できる画像サイズ、同時に処理できる画像の数は時間的に変化する。また、これに伴って送信側端末では、逐次、受信側端末の受信状況（たとえば、受信バッファの容量や映像の再生の優先度、受信確認の応答時間）に応じた画像の圧縮方法（画像圧縮の方式、画像圧縮の有無、量子化ステップ、圧縮の優先度、圧縮すべき画像サイズなど）、受信端末が過負荷時の優先度の決定を検討していかなければ受信側の能力を上回ってしまい破綻を来す。
【００６７】
例えば、図１２（ｂ）に示すように、受信側端末の受信バッファの容量が８０％を超えた場合、送信側へ受信バッファがあふれそうになっていることを通知し、画像圧縮の方式（たとえばＭＰＥＧ１からランレングスへ変化させて、圧縮画像の送出量を減らす）、画像圧縮の有無（画像圧縮して、送信するのを一時中断させる）、圧縮の優先度の変更（圧縮すべきプロセスが複数ある場合、圧縮するための優先度を下げて、圧縮される圧縮画像の送出量を減らす）、画像サイズの変更（ＣＩＦからＱＣＩＦへと圧縮すべきサイズを小さく変更して圧縮画像の送出量を減らす）、量子化ステップの変更（画質の変更によって圧縮画像の送出量を減らす）による送出量を制限させる方法、フレーム数を調整する方法（処理を行うフレーム数を減らす）、受信端末が過負荷時の優先度を決定する方法を適宜、選択、組み合わせて実施する。これにより受信側端末の受信バッファのオーバーフローを回避させる。
【００６８】
同様に、受信側の受信バッファの容量が２０％を下回った場合、送信側の端末へ受信側端末の受信バッファがアンダーフローになりかけている旨を通知して、前述とは逆の方法で、送信側の端末で、画像圧縮の方式、画像圧縮の有無、画像圧縮の優先度、画像のサイズ、量子化ステップ、フレーム数を適宜、選択、組み合わせて実施する。このように送出量を増大させる方法を実施することにより、受信側端末の受信バッファのアンダーフローを回避させることができる。
【００６９】
受信バッファの状態の監視以外にも、受信側端末での再生能力が限られていて、再生すべき画像が複数ある場合、受信側端末で、優先して再生すべき画像を利用者が明示的に決定するか、端末側で、優先して再生すべき画像を自動的に決定する必要がある（予め、利用者により優先して再生すべき画像はどれであるかを、ルールとして受信端末に登録しておく必要がある。例えば、画像サイズの小さいものは優先であるとか、背景の画像として表示させているものは再生の間隔はゆっくりであってもよいとか）。例えば、受信側端末の負荷（たとえば、再生に必要なＣＰＵの占有時間）を送信側の端末へ通知してやることにより、簡単に実現可能である。
【００７０】
受信側の端末の再生の負荷が端末の処理能力の８０％を超えれば、その受信側端末が過負荷になっていることを送信側へ通知し、送信側ではそのことをうけて、上述と同様の方法で、受信側端末の処理すべき負荷が下がるように、画像圧縮の方式（たとえば、ＭＰＥＧ１からランレングスへ変更させて処理量を減らす）、画像圧縮の有無（画像圧縮して、送信するのを一時中断させる）、圧縮の優先度の変更（重要度の低い画像に対しては、圧縮するための優先度を下げて、重要度の高い画像を優先して圧縮して送出する）、画像サイズの変更（ＣＩＦからＱＣＩＦへと圧縮すべきサイズを変更して、再生側の負荷を減らす）、量子化ステップの変更（画質の変更によって圧縮画像の送出量を減らす）の方法、フレーム数を調整する方法、過負荷時の処理の優先度に基づいて処理する方法を適宜、選択もしくは組み合わせて実施することによって受信側の端末での処理量を軽減させる。
【００７１】
逆に、負荷が受信側端末の処理能力の２０％を下回った場合は、受信側の端末の処理能力に余裕があるものとして、前述とは逆の方法で、送信側の端末で、画像圧縮の方式、画像圧縮の有無、画像圧縮の優先度、画像のサイズ、量子化ステップ、フレーム数を適宜、選択、組み合わせて実施することにより、高画質で、フレーム間隔の短い画像を受信側端末へ送出する。これにより、受信側端末の能力を活かした画像伝送が可能になる。
【００７２】
最後に、受信側端末の処理状況を知る方法としては、受信側の画像合成装置からの受信確認の応答時間によって知ることができる。例えば、送信側の端末から受信側端末へ画像データを送出した場合に、受信側端末が画像データを受信したことや復号処理、合成や表示処理が完了したことを送信側端末へ応答する場合、その応答時間が、例えば、通常値として１秒以内である場合、受信側端末の負荷の増大により、その応答時間は、５秒といったように長くなる（通常値は、端末接続時に一度、測定してもよいし、通信時に定期的に測定してもよいし、利用者が指示してもよい。また、応答時間の測定は周期的に行ってもよいし、端末の負荷や前回の応答時間の結果に関連させて測定間隔を変化させてもよい）。この応答時間の変化により、前述した画像圧縮の方式、画像圧縮の有無、画像圧縮の優先度、画像のサイズ、量子化ステップを適宜、選択、組み合わせて実施することにより、受信端末での負荷を低減させることができるので、応答時間を短縮させることができる（図１６のケース１参照）。受信端末での再生時刻もしくは復号時刻を受信して上記と同様の処理を行ってもよい。
【００７３】
尚、受信側の端末の状態を考慮した方法として、前述した受信側の端末の受信バッファの容量、受信側端末の負荷、受信側の端末の応答時間を測定する方法をそれぞれ単独に用いるのではなく、適宜、選択して、組み合わせて用いてもよい（音声に関しても同様の方法が適用できる）。また、受信側の端末で優先度情報に基づいて処理した画像や音声に関する情報（複数の、画像ストリーム、音声ストリームが存在するとき、受信側端末で実際に処理された画像、音声ストリームは、どのストリームであり、再生された画像ストリームは毎秒何フレームであったかという情報）を、通信路を通じて送信先に送信することで、送信側から受信側の端末への画像データ送信が、受信端末の処理量をこえるような量になることを未然に防ぐことができる（図１６のケース２参照、実際に処理された画像データについて知ることで、送信側の量子化パラメータ、画像サイズなどの情報量を調整することが可能となる。なお、この例では、フレーム単位で処理のフィードバックを返しているが、前述したように、例えば、Ｈ．２６３ならばＧＯＢのように独立して扱えるような画像単位であってもよい）。以上の方法は、同様に音声に対しても適用できる。
【００７４】
図１３は、本発明の一実施の形態の画像圧縮装置について説明する図である。尚、本実施の形態は、画像に対しての例を説明しているが、音声の圧縮に対しても適用できる。図１３の例では、画像入力手段１２０７毎に量子化ステップを変化させたり、画像入力手段１２０７に対する制御によって受信側端末での受信状況が変化した場合に、量子化ステップを追随させて変化させることにより、圧縮画像の発生量の増大を低減させようとするものである。図１３の画像圧縮装置は、量子化ステップに関する情報を管理する量子化ステップ管理部１２０１、画像入力手段１２０７の制御状態を管理する画像入力管理部１２０２、受信側端末装置の受信バッファの状況を監視する他端末制御要求管理部１２０３、制御の時間的な推移を記録、管理する操作管理部１２０４、画像圧縮を行う手段である画像圧縮部１２０５、圧縮結果を通信路や記憶装置に出力する出力部１２０６、画像入力を行う画像入力手段１２０７及び、これら各部を管理し、また管理する制御を行う画像処理決定制御手段１２０８から構成される。
【００７５】
尚、画像圧縮の方法としては、ＪＰＥＧ、ＭＰＥＧ１／２、Ｈ．２６１、Ｈ．２６３のような標準化されている方式でもよいし、ウェーブレットやフラクタルのような標準化されていない方式であってもよい。画像入力手段１２０７はカメラであっても、ビデオ、オプティカル・ディスクのような記録装置であってもよい。
【００７６】
この画像圧縮装置の利用方法としては、画像入力手段１２０７がカメラである場合、受信側端末により送信側の端末のカメラが操作されたときや送信側でカメラ操作が行われたとき、画質が大きく変化するために、送出される符号化量は変動する。例えば、カメラのコントラストを上げた場合、画像は見やすくなるが、送出すべき符号化量は増える。そこで、コントラストの向上とともに前述したように符号化量を低減させるために、画像圧縮の方式、画像圧縮の有無、画像圧縮の優先度、画像のサイズ、量子化ステップ、フレーム数を適宜、選択、組み合わせて実施することにより、符号化量を抑えることができる。
【００７７】
ここで述べているカメラ操作とは、カメラを移動させる方向（パン、チルト、ズーム）、コントラスト、フォーカス、カメラ位置（たとえば、図面を撮影する場合はカメラを下向きに向け、人物を撮影するときは水平にする）が挙げられる。画像圧縮の方式を変更する方法としては、カメラを下向きに向けた場合は、文書画像を撮影しているものと判断して、ランレングスで画像を伝送し、カメラが水平方向にむいている場合は、人物の顔の様子を撮影しているものとして、Ｈ．２６１で撮影して画像伝送を行う方法が挙げられる。これにより、不必要な情報の伝送を低減させることが可能となる。
【００７８】
また、複数のカメラが存在し、複数のカメラから得られる映像を伝送する必要がある場合に、通信容量が限られている場合は、利用者が着目しているカメラの映像の画質やフレーム数を多くして見やすくし、着目していないカメラの画質やフレーム数は低減してやる方法が考えられる。着目しているカメラから得られる映像の画質やフレーム数を操作することにより、情報量が増大するため、それに応じて着目していないカメラから得られる映像を制限して発生情報量を調整する必要がある。発生する情報量を調整する方法としては、画像サイズ、量子化ステップの値、フレーム数などを調整する方法が挙げられる。尚、複数のカメラを用いて広視野画像を作成する場合の例については、図１５を用いて後述する。
【００７９】
図１４は、操作管理部１２０４が管理する情報の例である。図１４の例では、画像サイズ、カメラ制御、他端末の制御要求、量子化ステップ、図示しないフレーム数について管理されている。これらの管理情報に基づいて、受信側端末の受信バッファがオーバーフローしないように、量子化ステップとカメラ操作の関係を履歴情報として記録、管理することで、カメラ操作に対する制限を利用者に加えることができる。また、量子化ステップや画像サイズ、フレーム数などを自動的に変更させることで、カメラ操作に伴う受信側端末の受信バッファのオーバーフローやアンダーフローを未然に防ぐことができる。
【００８０】
図１５に、上記画像圧縮装置を広視野画像を作成する用途に応用した例を示す。図１５の例では、複数のカメラから入力された画像を入力部１４０７で取得する。その得られた複数の画像を受信端末１４０８側でつなぎ目なく接合（合成）するとき、受信端末１４０８が過負荷になると端末が破綻を来すので、それを防ぐために、受信端末１４０８における過負荷時の処理を行うべき画像の順序を定義した優先度を画像に付加する。これにより、受信端末１４０８側が過負荷になることを防ぐことができる。
【００８１】
図１５に示す画像圧縮装置は、複数のカメラ（Ｎ台）を備えた入力部１４０７と、その入力部１４０７で得られたそれぞれの画像に対して優先度の付加を行う優先度決定制御部１４０１と、利用者が（特に、着目して見たいと思って）カメラを指示、操作した操作履歴を管理する操作履歴管理部１４０２と、画像の画質を制御する画質制御部１４０３と、カメラから得られた画像を優先度に基づいて合成する画像合成部１４０４（優先度の低い画像は合成しなくてもよい）と、合成結果を出力する出力部１４０５と、それら各部を制御する圧縮制御部１４０６とから構成される。出力部１４０５は通信路を介して受信端末１４０８に接続されている。
【００８２】
出力部１４０５の出力先は、記録装置であっても通信路であってもよい。また、画像の合成は必ずしも送信側の端末で行う必要はない。優先度が付加された画像を通信路を通して、受信側端末へ送信し、受信端末側で合成してもよい。なお、得られた複数の画像を送信側端末で合成して、受信側端末で再生を行う場合、得られた画像を送信側で受信端末で必要となる（表示の）優先度の高い順に合成して、伝送路を使って合成画像を受信端末装置に伝送する。
【００８３】
優先度の付加方法としては、利用者が指示したカメラで得られた画像、過去に指示の多かったカメラで得られた画像から順に高い優先度、高い画質（たとえば、フレーム数を多く、解像度を高く）なるようにすればよい（必ずしも、高い優先度の画像を高画質にする必要はない）。これにより利用者の着目度合いの大きい画像が高画質で、優先的に表示される。画像に付加された優先度に応じて送信側端末からの画像伝送を制御したり、受信側端末での画像の伸張や表示を制御することにより、利用者における端末の応答性を確保することができる。
【００８４】
また、優先度、画質の高い画像、フレーム枚数の多い画像から順に、隣接する接合された画像に対して段階的に、優先度や画質を下げてゆく（優先度の管理は、送信側端末で管理しておいてもよいし、受信側端末で管理しておいてもよい）。優先度の決定方法としては、必ずしもカメラの操作履歴に基づくものでなくてもよい。前述したように、圧縮する際にかかったローカル・デコードの時間に基づいて優先度の決定を行ってもよいし、優先度、画質の高い画像、フレーム枚数の多い画像から順に、周辺の画像に対して、処理の実施回数を規定する実施率を定義してもよい。さらに、音声に関しても、複数あるカメラ毎にマイクを設け、音声の圧縮の有無を制御することで、利用者の着目している方向の画像に対応する音声のみを合成することが可能となる。
【００８５】
また、前述したように、送信側端末と受信側端末との間での応答時間を参照して、量子化ステップやフレーム数を決定してもよい。また、受信側端末で過負荷時に優先度情報に基づいて処理された画像に関する情報を、通信路を通じて送信先に送信することで、送信側から受信側端末への画像データ送信を受信端末の処理量をこえるような量になることを未然に防ぐことができる。また、受信端末でのフレームスキップの状態を送信側へ伝送することにより、その状態に応じてデータ量を調節することができる。
【００８６】
更に、画像は再送を行う伝送方法で伝送し、音声は再送を行わない伝送方法で伝送して、受信側端末が、画像の再送回数、受信された音声の誤り率、廃棄率に関する情報のいずれかの情報を送信側端末に伝送する構成とする。そうして送信側端末で画像の圧縮方式、量子化ステップの値、フレーム数、圧縮すべき画像の大きさ、画像圧縮の有無のいずれかを決定することで、画像が乱れることなく、音声の伝送の遅延を小さくするような制御が可能となる。例えば、ＴＣＰ／ＩＰを用いた通信では、画像の伝送はＴＣＰで、音声の伝送はＵＤＰで行うことで実現できる（映像と音声は物理的に同じ伝送路にあってもよいし、なくてもよい）。尚、通信の方式はＴＣＰ／ＩＰだけに限定されない。この方式は、複数の映像や音声を同時に伝送する場合、それぞれの音声毎に廃棄率や誤り率を定義して、複数の映像の圧縮方法や伝送方法を制御してもよい。
【００８７】
最後に、通常、アナログ電話回線を用いた低ビットレートの画像伝送や、画像の内容が大きく変動する場合、画像に大きなブロックノイズ、もあれが発生する。このような場合に圧縮処理だけで画像の品質を保つのは難しい。そこで、画像の出力側のモニターに低域の信号のみを透過させるフィルター（例えば、画像処理によるローパス・フィルター、あるいは物理的な偏光フィルター）を用いれば、画像はぼやけた感じにはなるものの、ノイズや、もあれが気にならない画像が得られる。
【００８８】
以上述べたところから明らかなように本発明は、同時に複数の映像や音声の復号、合成を行う場合に、端末の負荷状況に応じて優先度に基づいて処理量を制御できるという長所を有する。
【００８９】
また、本発明は、課金状況に応じて複数の映像や音声を合成できるという利点がある。
【図面の簡単な説明】
【図１】本発明の一実施の形態における画像復号化符号化装置の概略構成図である。
【図２】同実施の形態における別の例を示す画像音声復号化符号化装置の概略構成図である。
【図３】通信、記録フォーマットで優先度に関する情報を付加する場合の例を説明する図である。
【図４】ソフトウェアで本発明の構成をした場合の例を説明する図である。
【図５】情報の構造について説明する図である。
【図６】ＤＥＭＵＸスレッドの動作について説明する図である。
【図７】監視スレッドの動作について説明する図である。
【図８】デコード・プロセスの動作について説明する図である。
【図９】画像合成スレッドの動作について説明する図である。
【図１０】表示監視スレッドの動作について説明する図である。
【図１１】画像合成装置のユーザインターフェースについて説明する図である。
【図１２】受信側端末の能力の変動に応じた画像伝送を行う方法について説明した図である。
【図１３】本発明の一実施の形態の画像圧縮装置について説明する図である。
【図１４】操作管理部が管理する情報について説明する図である。
【図１５】広視野画像を作成する場合の画像圧縮装置を説明する図である。
【図１６】送信端末と受信端末との応答状況を説明する図である。
【符号の説明】
１１      受信管理部
１２      分離部
１３      送信管理部
１４      優先度決定部
１７      時間情報管理部
１８      画像伸長部
１９      画像合成部
２０      音声伸長部
２１      音声合成部
３１      ＤＥＭＵＸスレッド
３６      デコード・プロセス
３７      監視スレッド
３９      画像合成スレッド
４２      表示監視スレッド
１２０４  操作管理部
１２０５  画像圧縮部
１２０８  画像処理決定制御手段
１４０１  優先度決定制御部
１４０２  操作履歴管理部
１４０４  画像合成部
１４０７  入力部
【図１】
0004153995.tif 000002
【図２】
0004153995.tif 000003
【図３】
0004153995.tif 000004
【図４】
0004153995.tif 000005
【図５】
0004153995.tif 000006
【図６】
0004153995.tif 000007
【図７】
0004153995.tif 000008
【図８】
0004153995.tif 000009
【図９】
0004153995.tif 000010
【図１０】
0004153995.tif 000011
【図１１】
0004153995.tif 000012
【図１２】
0004153995.tif 000013
【図１３】
0004153995.tif 000014
【図１４】
0004153995.tif 000015
【図１５】
0004153995.tif 000016
【図１６】
0004153995.tif 000017