JP2003169329A - 画像音声符号化復号化装置 - Google Patents

Abstract

(57)【要約】 【課題】 同時に複数の映像や音声の復号、合成を行う
場合に、端末の処理状況に応じて符号化量を制御するこ
とを目的とする。 【解決手段】 本復号化装置は、情報を受信する受信管
理部１１と、その受信情報を解析し、分離する分離部１
２と、その分離部１２で分離された画像の処理の優先度
を決定する優先度決定部１４と、その決定された優先度
に従って画像を伸長する画像伸長部１８と、その伸長さ
れた画像をもとに画像合成を行う画像合成部１９と、そ
の合成された画像を蓄積する合成結果蓄積部２２と、再
生を開始すべき時刻を管理する再生時刻管理部２３と、
その再生時刻管理部２３の情報に従って合成結果を山力
する出力部２４とを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、画像音声符号化復
号化装置に関するものである。

【０００２】

【従来の技術】従来より、自分側空間の風景の画像中か
ら、例えば人物画像を抽出し、その画像と、相手側から
送られてきた人物画像と、予め記憶されている相手側と
共通的に表示するための仮想的な空間の画像とを重畳し
て表示することにより、相手が自分の前にいるという実
在感を充足し、臨場感のある映像通信を目指したものが
ある（特公平４−２４９１４号公報、「ハイパーメディ
アシステム パーソナルコミュニケーション システム」
（Fukuda, K., Tahara, T., Miyoshi, T. :"Hypermedia
Personal Computer Communication System: Fujitsu H
abitat", FUJITSU Sci. Tech. J., 26, 3, pp.197-206
(October 1990).）、中村：「ネットワーク対応仮想現
実感による分散協同作業支援」、情報処理学会オーディ
オビジュアル複合情報処理研究会（１９９３））。特
に、従来の技術では画像合成を行うための高速化、メモ
リーを低減する方法に関する発明が行われている（例え
ば、特公平５−４６５９２：画像合成装置、特開平６−
１０５２２６：画像合成装置）。

【０００３】

【発明が解決しようとする課題】しかしながら、従来の
技術では、２次元の静止画や３次元のＣＧデータを合成
する画像合成システムが提案されていたが、複数の動画
や音声を同時に復号化（伸長）して、合成し表示させる
システムの実現方法については述べられていなかった。
特に、複数の映像、音声を同時に復号、合成、表示でき
る端末装置において、端末の能力の不足や処理能力の変
動に対して破綻を来さない映像や音声の再生方法につい
ては述べられていなかった。加えて、課金状況に応じて
複数の映像を復号、合成、表示する方法については述べ
られていなかった。

【０００４】具体的には、 （１）複数の画像、音声の情報、複数の画像と音声との
関係を記述した情報、及び処理結果の情報を管理する方
法。 （２）端末の処理状態が過負荷である場合の複数の画像
や音声の復号、合成、表示の優先度の決定方法、再生お
よび課金に関する方法。

【０００５】更に、複数の映像、音声を同時に復号、合
成、表示できる環境下で、受信端末側の状態や受信端末
での復号、合成、表示の優先度に応じて画像の圧縮方法
を変更して、符号化量を制御する方法に関しては考慮さ
れていない。

【０００６】

【課題を解決するための手段】本発明は、従来のこのよ
うな課題を考慮し、同時に複数の映像や音声の復号、合
成を行う場合に、端末の処理状況に応じて符号化量を制
御でき、また、課金状況に応じて複数の映像や音声の復
号、合成、表示の制御ができる画像音声復号化装置と画
像音声符号化装置及び情報伝送システムを提供すること
を目的とするものである。

【０００７】本発明は、２次元の画像合成だけに限定さ
れない。２次元の画像と３次元の画像を組み合わせた表
現形式でもよいし、広視野画像（パノラマ画像）のよう
に複数の画像を隣接させて画像合成するような画像合成
方法も含めてもよい。

【０００８】本発明で対象としている通信形態は、有線
の双方向ＣＡＴＶやＢ−ＩＳＤＮだけではない。例え
ば、センター側端末から家庭側端末への映像や音声の伝
送は電波（例えば、ＶＨＦ帯、ＵＨＦ帯）、衛星放送
で、家庭側端末からセンター側端末への情報発信はアナ
ログの電話回線やＮ−ＩＳＤＮであってもよい（映像、
音声、データも必ずしも多重化されている必要はな
い）。また、ＩｒＤＡ、ＰＨＳ（パーソナル・ハンディ
ー・ホン）や無線ＬＡＮのような無線を利用した通信形
態であってもよい。

【０００９】また、対象とする端末は、携帯情報端末の
ように携帯型の端末であっても、セットトップＢＯＸ、
パーソナルコンピュータのように卓上型の端末であって
もよい。

【００１０】具体的に説明すると、請求項１記載の本発
明は、少なくとも再生許可情報に基づいて、復号、合
成、表示すべき画像や音声の順番、有無、再生方法を決
定することを特徴とする画像音声符号化復号化装置であ
る。

【００１１】請求項２記載の本発明では、前記再生許可
情報は、課金に関する情報、サービスの内容を示す情
報、パスワード、利用者コード、国別コード、合成、表
示の順位を示す情報、復号の順位を示す情報、利用者の
指示、端末の処理能力、再生時刻のうち１つ以上の情報
である。

【００１２】

【発明の実施の形態】以下に、本発明をその実施の形態
を示す図面に基づいて説明する。本発明で使用する「画
像」の意味は静止画と動画の両方を含む。また、対象と
する画像は、コンピュータ・グラフィックス（ＣＧ）の
ような２次元画像とワイヤーフレーム・モデルから構成
されるような３次元の画像データが混合したものであっ
てもよい。この場合、画像間の関係はワイヤーフレーム
モデルに相当する。記述するためのスクリプト言語とし
てはＪＡＶＡやＶＲＭＬなどが挙げられる。

【００１３】図１及び図２は、本発明の一実施の形態に
おける画像復号化符号化装置の概略構成図である。図１
は、音声の再生機能をもたない場合の構成であり、図２
は、画像と音声の再生機能をもつ場合の構成である。当
然のことながら音声だけの場合も、同様に構成できる。

【００１４】図１あるいは図２の本装置は、符号化装置
及び復号化装置から構成され、図１の場合の符号化装置
は、符号化された画像の過負荷時の処理の優先度を予め
決められた基準で決定し、その符号化画像と優先度とを
対応づける優先度付加部１０１、画像を符号化する画像
符号化部１０２、優先度が付加された符号化情報を送信
あるいは記録する送信管理部１０３、及び符号化された
情報を受信する受信管理部１０４から構成されている。
また、図２の場合の符号化装置は、更に、音声を符号化
する音声符号化部１０５が設けられている。

【００１５】一方、復号化装置において、情報を受信す
る受信管理部１１と情報を送信する送信管理部１３は、
同軸ケーブル、ＣＡＴＶ、ＬＡＮ、モデム等の情報を伝
送する手段である。端末の接続形態としては、ＴＶ電話
やＴＶ会議システムのように端末間で双方向で映像情報
を送受信する形態や、衛星放送やＣＡＴＶ、インターネ
ット上での放送型（片方向）の映像放送の形態が挙げら
れる。本発明では、このような端末の接続形態について
考慮している。

【００１６】分離部１２は、符号化（圧縮）された受信
情報を解析し、分離する手段である（圧縮装置の場合
は、逆操作で多重化部になる）。たとえば、ＭＰＥＧ１
やＭＰＥＧ２、Ｈ．３２０端末（Ｎ−ＩＳＤＮを利用し
たＴＶ電話／会議装置の規約）ではＨ．２２１が、Ｈ．
３２４端末（アナログ電話回線を利用したＴＶ電話／会
議装置の規約）ではＨ．２２３がビデオ／音声／データ
を多重化、分離する規約である。本発明は、規約に準じ
た構成で実現してもよいし、規約に準じない構成で実現
してもよい。また、Ｈ．３２３やインターネットで行わ
れているように、映像と音声はそれぞれ別ストリームで
独立して伝送してもよい。

【００１７】優先度決定部１４は、分離部１２から得ら
れた情報（例えば映像、音声、管理情報）を、以下の方
法で、端末が過負荷である場合の復号（以後、「伸長」
を用いる）の優先度を決定して画像の伸長や音声の伸長
を行う（処理の優先度の決定方法は、予め受信端末装置
で取り決めしておいてもよいし、送信側端末（符号化装
置）で記録メディアや送信パケットなどに、下記の方法
で決定された優先度に関する情報を付加して伝送、記録
フォーマットとして付加しておいてもよい。優先度に関
する表現方法としては、優先度「大」、「中」、「小」
といった数値化していない表現や１、２、３といった数
値化した表現でもよい）。

【００１８】複数の画像もしくは音声フレームから構成
されるストリーム単位でのデータの扱いをするための識
別子を用いて、送信側と受信側とでデータの送受信の処
理を行うことで、受信側のバッファの管理や送信側のデ
ータの送信のスケジューリングが可能となる。つまり、
必要に応じて送信側から送付するストリームの識別子を
通知して受信側の受け入れ状況を調べたり、必要としな
いストリームの識別子の受信端末への通知、受信側から
必要なストリームを要求したりすることが可能となる。

【００１９】符号化された情報の過負荷時の処理の優先
度を前述した基準で決定し、符号化された情報と決定さ
れた優先度とを対応づける優先度付加手段を画像符号化
装置や音声符号化装置に備え、受信された種々の情報の
過負荷時の優先度に従って、処理の方法を決定する優先
度決定手段で、処理すべき優先度の画像フレームや音声
を決定し、復号、合成処理を行う。尚、画像フレームに
関しては、フレームスキップが行えるようにフレーム内
符号化（Ｉフレーム）を行ったフレームを定期的に挿入
する必要がある。

【００２０】優先度を付加する単位としては、映像や音
声の各フレーム単位（フレーム間同士の優先度の比
較）、複数のフレームから構成されるストリーム単位で
あってよい（ストリーム間同士の優先度の比較）。

【００２１】画像の特徴に着目した方法としては、画像
の圧縮形式（例えば、Ｈ．２６３とランレングスならラ
ンレングスを優先させる）、画像のサイズ（例えば、Ｃ
ＩＦとＱＣＩＦならばＱＣＩＦを優先させる）、コント
ラスト（例えば、コントラストの明るいものを優先させ
る〉、画像の合成比率（例えば、合成比率の高いものを
優先させる）、量子化ステップ（例えば、量子化ステッ
プの小さな値のものを優先させる）、フレーム間符号化
とフレーム内符号化の違い（例えば、フレーム内符号化
を優先させる）、表示位置（例えば、表示位置が中央の
ものを優先させる。また、３次元画像であれば、画像が
奥に配置される場合は、優先度を低く、手前に表示され
る場合には優先度を高く設定する）、フレーム番号（第
１フレームと最終フレームは優先度を高くする、シーン
チェンジのフレームの優先度を高める等）やフレーム数
（例えば、再生すべきフレーム数が少ない画像は優先度
を高くする。フレーム番号はＨ．２６３の場合、テンポ
ラリー・リファレンス（ＴＲ）に該当し、ＴＲの値の変
化に基づいて判断すればよい）、有音区間と無音区間、
表示時刻（ＰＴＳ）、復号時刻（ＤＴＳ）に基づく方法
が挙げられる。

【００２２】加えて、フレーム間符号化されたＰフレー
ムやＢフレームは同一の優先度を割り当てる。また、フ
レーム内符号化された画像に複数段階の優先度を割り当
てることにより、スキップする頻度を制御できる。

【００２３】また、メディアの違いに着目した例として
は、音声の伸長を画像の伸長よりも優先的に行う方法が
挙げられる。これにより、音声を途切らすことなく音声
の再生を行うことができる。

【００２４】さらに、受信側端末で管理している再生の
許可情報をもとに、伸長すべき情報（画像、音声）の決
定を行ってもよいし、送信側より制御情報として送る再
生許可の情報をもとに、伸長すべき情報の選択を行って
もよい。再生許可の情報は、具体的には、課金に関する
情報（例えば、課金が行われていなければ、伸長、合
成、表示の処理を行わない。受信端末側で、課金に関す
る情報を管理してもよいし、送信側で課金情報を管理し
てもよい）、サービスの内容を示す情報（例えば、成人
向きの放送で端末側で再生の許可が出ていなければ、伸
長、合成、表示の処理を行わない。再生の許可は受信側
端末で管理してもよいし、送信側端末で管理してもよ
い）、パスワード（例えば、特定の番組にはパスワード
を入力しなければ、伸長、合成、表示を行わない。パス
ワードは受信側端末で管理してもよいし、送信側端末で
管理してもよい）、利用者コード（例えば、許可が与え
られている利用者でなければ、伸長、合成、表示は行わ
ない。利用者コードは受信側端末で管理してもよいし、
送信側端末で管理してもよい）、国別コード（例えば、
国によって、伸長、合成、表示すべき画像や音声、再生
方法を変更する。国別コードは、送信側で管理してもよ
いし、受信側で管理してもよい。国別コードで再生方法
を変えることによってスクランブルが実現できる）。

【００２５】課金に関する情報、サービスの内容を示す
情報、パスワード、利用者コードといった画像や音声の
再生許可の制限をかけた再生方法としては、画像の合
成、表示を行う際に故意に位置や画素をずらしたり、画
像の拡大・縮小、画像のサンプリング（たとえばローパ
スをかけるとか）を変更、画素反転、コントラストの変
更、カラーパレットの変更、フレームのスキップを行う
方法などが挙げられる。これら画像の再生方法（画像の
伸張、合成、表示）は、１フレーム毎に制約をかけても
よい。あるいは、画像圧縮の１つであるＨ．２６３で定
義されるような１フレームよりも小さく、独立して処理
できる単位であるＧＯＢ（Ｇｒｏｕｐ Ｏｆ Ｂｌｏｃ
ｋ）単位で、画像の伸張、合成、表示方法に制約をかけ
てもよく、これにより、従来から行われている画面全体
を乱す手法よりも柔軟な制御が可能になる。つまり、Ｇ
ＯＢ単位で処理することにより、画面の一部分だけにス
クランブルをかけることができるため、画像合成を使っ
たソフトのようにインタラクティブなソフトに対する評
価が可能となる。

【００２６】同様に、音の再生方法としては、音の大き
さを変更させる、音の方向を変更させる、音の周波数を
変更させる、音のサンプリングを変更させる、異なる画
像や音声を挿入する方法が挙げられる（いずれの方法
も、あらかじめ送信側で処理する方法と、受信側で処理
する方法が挙げられる）。

【００２７】画像と音声の再生方法としては、画像と音
の同期をはずす方法が挙げられる。合成、表示の順位を
示す情報（予め表示する順序を受信側の端末で決めてお
く、例えばＣＩＦや静止画を優先するなど、また、送信
側で、送信情報に表示する順序を優先度に関する情報と
して付加しておく方法も挙げられる）、伸長の順位を示
す情報（予め伸長する順序を受信側の端末で決めてお
く、たとえばＱＣＩＦや、フレーム内符号化の画像デー
タを優先させるなど、ＢＧＭよりも会話音を優先して伸
長するなどが挙げられる。同様に、送信側で、送信情報
に表示する順序を付加しておく方法も挙げられる）、利
用者の指示（たとえば、利用者の指示により、伸長、合
成、表示すべき画像や音声情報を選択させるか、要望に
応じて選択した情報をもとに、伸長、合成、表示すべき
画像や音声情報を決定する）、端末の処理能力（たとえ
ば、現在もしくは過去の一定期間のＣＰＵの処理の占有
時間を計測することにより、処理時間がかかりそうな画
像や音声の伸長、合成、表示を抑制する。処理時間の推
定方法としては、圧縮を行う際にローカル・デコードに
かかった時間や、圧縮にかかった時間を圧縮した画像情
報とともに対応づけて管理することにより、伸長、合
成、表示の有無、優先度の決定を行うことができる）、
再生時刻（たとえば、再生時刻を過ぎた画像、音声情報
の伸長、合成、表示は中止する）や復号時刻により、伸
長すべき画像や音声の優先度、有無を決定してもよい。

【００２８】加えて、特定の画像や音声だけが優先的に
伸長、表示されるのを防ぐための方法として、画像や音
声の伸長、合成、表示の処理を行う実施率に関する情報
に基づいて、伸長、合成、表示すべき画像の順番や有無
を決定することができる。例えば、伸長を行う１０回の
うち１回はＣＩＦサイズの画像の伸長を行うと受信端末
側で設定しておくか、送信側で画像や音声の伸長、合
成、表示の実施率を規定してそれに基づいて画像情報や
音声情報を送信する方法が考えられる。実施率は具体的
には、Ｉフレーム（フレーム内符号化したフレーム）の
挿入間隔で定義できる。これにより、特定の画像や音声
オブジェクトのみが伸長、合成、表示されることはなく
なる。

【００２９】これら伸長、合成、表示を制御する優先度
に関する情報の付加は送信側の装置だけではなく、中継
を行う装置で付加、制御してもよい。また、受信端末の
復号装置の優先度決定部１４で決定した優先度に関する
情報を、送信管理部１３を通じて送信先に送信すること
で、優先度決定部１４の決定状況に応じた画像、音声伝
送を行うことが可能となる（選択されにくい画像オブジ
ェクトのＩＤを送信側へ送ることにより、無駄に送信さ
れることがなくなる）。尚、受信端末が過負荷である場
合の処理の優先度を示す情報は、受信端末装置で取り決
めてもよいし、伝送フォーマットとして伝送してもよい
し、ＣＤ−ＲＯＭやハードディスクのような記録メディ
アに記録するためのフォーマットとしてＭＰＥＧ２のト
ランスポートストリームを拡張してもよいし、標準化を
考慮しない伝送、記録フォーマット形式であってもよ
い。また、メディア毎（映像、音声、映像と音声の関係
を記述した情報）に別々のストリームとして、多重化を
行わずに伝送、記録してもよい。

【００３０】画像復号手段としての画像伸長部１８は画
像の伸長処理を行う手段であり（以降、符号化装置の場
合は符号化手段）、画像伸長部１８で扱う画像フォーマ
ットとしてはＭＰＥＧ１やＭＰＥＧ２、Ｈ．２６１、
Ｈ．２６３等が挙げられる。画像の伸長は１フレーム単
位で行っても、Ｈ．２６３で規定されているＧＯＢ単位
の処理であってもよい。１フレーム単位で処理する場
合、フレーム間符号化を行う場合、前フレームの伸長状
態を画像伸長部１８に記憶しておく必要がある。ＧＯＢ
単位での画像伸長を行った場合、画像の伸長の順序関係
は問題ではなくなる。従って、ＧＯＢ単位で伸長処理を
行う場合、複数の画像伸長部１８を受信装置に持つ必要
はなく、１つの画像伸長部１８で複数の映像の伸長を行
うことが可能となる。反面、伸長結果を蓄えておく必要
がある。

【００３１】図２の音声復号手段としての音声伸長部２
０は音声の伸長を行う手段であり、音声伸長部２０で扱
う音声フォーマットとしてはＧ．７２１やＧ．７２３等
が挙げられる。処理のための方法としては、ＤＳＰや汎
用ＣＰＵによるソフトウェア処理や専用のハードウェア
による処理が挙げられる。

【００３２】ソフトウェアで実現する場合は、画像およ
び音声の伸長処理をそれぞれ１つのプロセスあるいはス
レッドの単位で管理し、伸長すべき画像や音声が同時に
複数ある場合、処理できる範囲の数のプロセスあるいは
スレッドで時分割して処理する。

【００３３】画像伸長管理部１５は画像の伸長の状態を
管理する手段である。また音声伸長管理部１６は音声の
伸長の状態を管理する手段である。例えば、これら管理
部を、ソフトウェアで実現する場合は、分離部１２から
得た圧縮された情報を決められた手順（例えば、最初に
音声伸長部２０から実行し、次に画像伸長部１８で実行
する）で、画像伸長部１８、音声伸長部２０に引き渡
し、伸長の状態を監視する。すべての伸長が完了すれ
ば、画像合成部１９もしくは音声合成部２１に、伸長さ
れた情報を引き渡す。ソフトウェアでは共有メモリーと
セマフォを用いることで、引き渡す情報を制限したり、
伸長処理が終了したことを知る（詳細については後述す
る）。

【００３４】時間情報管理部１７は時間に関する情報を
管理する手段である。例えば、システムをパーソナルコ
ンピュータで実現する場合には、時間情報はパーソナル
コンピュータのタイマーを利用して実現すればよい。

【００３５】画像合成部１９は、伸長された画像データ
をもとに画像合成を行う。複数の画像の合成を行う場
合、それぞれの画像の合成比率（α値）をもとに画像合
成を行う。例えば、２つの画像を合成する場合で、前景
画像の合成比率がαの場合、背景画像のＲＧＢ値を１−
α、前景画像をαの割合で混合する。尚、伸長すべき画
像は１フレーム単位で処理の管理を行うことにより、表
示時刻を用いて複数の画像を合成する場合にシステムの
構成と実装が簡単化できる。また、画像合成部１９もし
くは音声合成部２１で、送信側から伸長結果を破棄する
指示が来るまで、伸長結果を保持して管理、利用するこ
とで、送信側から同一パターンの情報を繰り返し送信す
る必要をなくすことができる。

【００３６】画像同士や音声同士の関係を記述した情報
に基づき、画像や音声を合成する際に、必要とする復号
された画像や音声が用意されていなくて、合成できない
画像や音声が存在することを提示することで、利用者は
合成の状態を知ることができる。そこで、利用者が必要
な画質を選択したり、合成したい画像を予め選択するな
どの指示を行うことで、必要な情報を取りこぼさずに合
成することが可能となる。尚、復号化された画像や音声
のデータをバッファに蓄積、管理する方法としては、到
着順に古いものから順に消去してゆくか、画像同士、音
声同士の関係を記述したスクリプトをみて、全体として
の復号化された画像や音声のデータの使用状況をみて消
去する方法が考えられる。

【００３７】音声伸長管理部１６は、少なくとも１っ以
上の音声の伸長を行う音声伸長部２０の伸長状態を管理
する。

【００３８】音声合成部２１は、伸長された情報をもと
に音声合成を行う手段であり、合成結果蓄積部２２は、
画像合成部１９が合成した画像と、音声合成部２１が合
成した音声を蓄積する手段である。

【００３９】再生時刻管理部２３は、再生を開始すべき
時刻に、合成した画像や音声を再生する手段である。

【００４０】出力部２４は合成結果を出力する手段（例
えば、ディスプレイ、プリンタなどである）、入力部２
５は情報を入力する手段（例えば、キーボード、マウ
ス、カメラ、ビデオなどである）である。端末制御部２
６は、これら各部を管理する手段である。

【００４１】図３は、通信、記録フォーマットで優先度
に関する情報を付加する場合の例を説明する図である。

【００４２】図３（ａ）の例は、完全にすべてのメディ
ア（映像、音声、制御情報）を多重化している例であ
る。制御情報として、過負荷時の処理を決定するための
優先度（本発明で指している優先度）や表示の順序を示
す優先度が示されている。また、制御情報としては、画
像同士、音声同士、画像と音声との関係（時間的、位置
的なもの）に関する情報を記述しておいてもよい。図３
（ａ）の例では、たとえば、ＭＰＥＧ１／２の多重化、
Ｈ．２２３のような制御情報とデータ（映像、音声）を
混在させるパケット多重の適用に向いている。尚、過負
荷時の処理の優先度はフレーム単位もしくはストリーム
単位で付加する。

【００４３】図３（ｂ）の例は、メディア毎に情報を多
重化している例である。この例では、制御情報、画像情
報、音声情報は別々の通信ポートから送信される。画像
同士、音声同士、画像と音声との関係に関する情報は制
御情報として、画像や音声とは別の通信ポートから送信
すればよい。Ｈ．３２３やインターネットのように複数
の通信ポートを同時に確立できる場合の適用に向いてお
り、図３（ａ）と比べて多重化の処理が簡略化できるの
で、端末の負荷が軽減できる。

【００４４】画像同士と音声同士の記述方法として、Ｊ
ＡＶＡ（登録商標）、ＶＲＭＬといった記述言語などで
対応が可能であると思われるが、スクリプトの記述言語
の仕様が一意に定まらない状況も考えられる。そこで画
像同士、音声同士の関係（例えば、位置的な情報、時間
的な情報（表示期間など））を記述した情報の記述方法
を識別するための識別子を設けることで、複数種類の記
述方法に対応することができる。情報の記述方法を識別
するための識別子の付加方法としては、例えば、ＭＰＥ
Ｇ２においては、ＭＰＥＧ２−ＴＳのストリームを管理
するプログラム・マップテーブルに設けるか、スクリプ
トを記述したストリームに設けることで対応できる。過
負荷時の処理の優先度は画像と音声との対応関係を記述
した情報とともに付加する（制御情報）。尚、ＭＰＥＧ
２においては、ＭＰＥＧ２−ＴＳ（トランスポート・ス
トリーム）のビデオ・ストリーム、オーディオ・ストリ
ームを関係づけるプログラム・マップテーブルで管理で
きるように、画像と音声との対応関係づけを行う構造情
報・ストリームを定義して管理すれば、ＭＰＥＧ２でも
データと独立して伝送することができる。

【００４５】図４は、ソフトウェアで木発明を構成した
場合の例を説明する図である。マルチタスク・オペレー
ションが可能なオペレーティング・システム上で本発明
を実現した場合、図１や図２で説明した各処理は、プロ
セス、スレッドといったソフトウェアの実行モジュール
単位に分けられ、各プロセス、スレッド間は共有メモリ
ーにより情報の交換を行い、セマフォ（図４の例では、
実線で示された部分がセマフォに対応する）によって共
有する情報の排他制御を行う。以下に、各プロセス、ス
レッドの機能について述べる。

【００４６】ＤＥＭＵＸスレッド３１はネットワークや
ディスクから多重化された情報（映像、音声、制御情
報）を読み取り、音声、映像及び、音声と映像との対応
関係と再生時間に関する情報とを記述した監視用テーブ
ル（詳細は後述する）に分離する。ＤＥＭＵＸスレッド
３１は前述の分離部１２に対応する。ＤＥＭＵＸスレッ
ド３１で分離された情報は、音声用のリングバッファ３
２、映像用のリングバッファ３３、監視用のリングバッ
ファ３４にそれぞれ送出される。音声情報である場合、
リングバッファ３２に送出された情報は、音声デコード
スレッド３５（前述の音声伸長部２０に対応する）で伸
長される。映像情報である場合、リングバッファ３３に
送出された情報は、デコードプロセス３６で伸長され
る。

【００４７】監視用テーブルに関しては、リングバッフ
ァ３４に送出され、映像を伸長するための順序を決定す
るために監視スレッド３７（前述の端末制御部２６、画
像伸長管理部１５、音声伸長管理部１６に対応する）で
利用される。また、同じ監視用テーブルが画像合成のた
めに画像合成スレッド３９で利用される。監視スレッド
３７で利用された監視用テーブルは、すべての音声、画
像の伸長が終わった時点で、次のテーブルをリングバッ
ファ３４から読み出す。デコード・プロセス３６（前述
の画像伸長部１８に対応する）で伸長された画像情報は
映像用シングルバッファ３８に送出される。送出された
画像情報が揃った時点で、画像合成スレッド３９（前述
の画像合成部１９に対応する）にて、監視用テーブルで
管理される画像合成の比率を用いて画像合成を行う。合
成結果は、合成用バッファ４１（前述の合成結果蓄積部
２２に対応する）に蓄積され、表示監視スレッド４２で
表示時間になるまで表示待ちの状態で待機する（前述の
再生時刻管理部２３に対応する）。

【００４８】図５は、図４の構成で用いられる情報の構
造について説明する図である。図５の例では、ディスク
もしくはネットワークから受信した情報は１８８ｂｙｔ
ｅの固定長である（Ｂ）。ＤＥＭＵＸスレッド３１で分
離された音声情報の構造は、パケット同期用のコード、
再生時刻、再生すべき音声の長さを示すフレーム長、音
声データからなる（Ｃ）。映像情報の構造は、パケット
同期用のコード、画像を識別するためのフレーム番号、
画像情報の大きさを示すフレーム長、画像データからな
る（Ｄ）。本発明は１フレーム単位での処理である必要
はなく、マクロブロック単位のような小さなブロック単
位での処理を行っても構わない。

【００４９】監視用テーブルの構造は、画像の表示時
間、１フレームで表示（合成）すべき画像の数、各画像
のＩＤ、フレーム番号、伸長や表示を行う優先度、フレ
ームのタイプを示す識別子（Ｉピクチャ、Ｐピクチャ、
Ｂピクチャ）、表示の水平位置、表示の垂直位置、合成
の比率を示す階層の各情報から構成される（Ｅ）。な
お、画像の合成比率と音声の合成比率を対応づけて変化
させてもよい。例えば、画像、２種類が、それぞれ音声
２種類に対応する場合、画像の合成比率がα：１−αで
ある場合、対応する音声の合成比率もα：１−αで対応
づけてもよい。画像情報同士の関係だけではなく、音声
同士の関係も記述してもよい（例えば、方向、種類（Ｂ
ＧＭ、会話音））。

【００５０】図６は、ＤＥＭＵＸスレッド３１の動作に
ついて説明する図である。ファイルもしくは、ネットワ
ークから１８８バイトの固定長のデータを読み込む（５
−１）。読み込んだデータを分析し、前述の音声、映
像、監視用テーブルの構造の型にセットする（５−
２）。リングバッファヘの書き込みが可能であれば、音
声、映像、監視用テーブルをそれぞれのリングバッファ
に書き込みを行う。画像オブジェクトＩＤと複数ある画
像伸長手段との対応関係をとる。例では、若い番号のオ
ブジェクトＩＤから若いリングバッファ番号の共有メモ
リーへ順に書き出す（５−３）。書き込んだバッファの
ライトポインタを更新する（５−４）。監視用テーブル
１つ分の映像、音声の情報を書き込んだら監視スレッド
制御用セマフォのカウンターを進める（５−５）。この
ようにＤＥＭＵＸにより監視スレッドの制御を行う。

【００５１】図７は、監視スレッド３７の動作について
説明する図である。監視用のテーブルを読み込みリード
ポインタを進める（６−１）。過負荷時のオブジェクト
の優先度をチェックして、優先度の高い画像フレームを
調べる（６−２）。監視用テーブルの内容を合成側のス
レッドへ渡す（６−３）。ＤＥＭＵＸからの監視用テー
ブル１個分のデータの作成を待つ（６−４）。処理の優
先度の高い順に、表示を行う画像のフレーム番号をデコ
ードプロセスに書き（６−５）、現在の時刻と表示すべ
き時刻を比べて、間に合っていなかったらＩフレームを
スキップせずに、ＰＢのフレームだけをスキップする
（６−６）。対応するデコード・プロセスの実行を許可
し（６−７）、処理が完了するまで待つ（６−８）。

【００５２】図８は、デコード・プロセス３６の動作に
ついて説明する図である。監視スレッド３７から実行の
許可が出るまで待機する（７−１）。入力画像の状態を
チェックし、画像のシリアル番号、入力されるフレーム
はスキップすべき画像かどうかを調べる（７−２）。デ
コードすべき画像データがリングバッファに溜まるまで
待つ（７−３）。監視スレッドから指示された画像のシ
リアル番号に対応する画像データがなければ、デコード
をスキップし、リードポインタを進める（７−４）。入
力画像のスキップでなければ、デコードの処理を実行
し、リードポインタを進める（７−５）。デコードの結
果を出力し（７−６）、監視スレッド３７に処理が終了
したことを通知する（７−７）。

【００５３】同じプロセス（スレッドであってもよい。
ハードウェアである場合はプロセッサ）を利用して異な
る種類の画像オブジェクトを伸長する場合、デコード・
プロセス３６内で過去に伸長した画像のフレーム番号と
伸長される前の画像とを対応づけて管理することによ
り、同時にたくさんのプロセスを生成して利用する必要
がなくなる（最低、直前のフレームに関する情報だけで
もよい。また、Ｉ、Ｐ、Ｂというように異なるタイプの
フレーム画像が存在する場合は、管理される順序と出力
すべき順序とが異なるのでデコード・プロセス３６にお
けるこのような管理は必要となる）。

【００５４】図９は、画像合成スレッド３９の動作につ
いて説明する図である。監視スレッド３７から監視用テ
ーブルを待つ（８−１）。処理する画像の優先度をチェ
ックする（８−２）。優先度の高い順にデコード結果の
画像を待つ（８−３）。表示位置にあわせた画像の合成
を行う（８−４）。合成結果を合成用バッファ４１に書
き込む（８−５）。表示を行うべき画像情報の選択は画
像伸長手段もしくは画像合成手段で行うことができる。
表示すべきではない画像オブジェクトＩＤをスキップす
る場合、画像合成手段へは伸長結果が出力されないこと
を通知する必要がある。音声に関しても再生すべき音声
情報の選択を音声伸長手段もしくは音声合成手段で行う
ことができる。

【００５５】図１０は、表示監視スレッド４２の動作に
ついて説明する図である。合成画像が書き込まれるのを
待つ（９−１）。初めての表示である場合、表示を開始
した時刻を取得し（９−２）、表示を行うべき時刻との
対応関係を管理する。表示時刻に達していなければ、達
していない時間だけ待機し、合成画像の表示を遅らせる
（９−３）。

【００５６】図１１を用いて本発明の画像合成装置のユ
ーザインターフェースについて説明する。

【００５７】図１１の例では、背景画像に、前景画像が
合成され、遠くに位置する建物が合成比率０．５で半透
明に画像合成されている。図１１に示したように、使用
する画像は２次元画像でなくてもよい。前景に３次元画
像としてヘリコプターと気球が、２次元の画像である背
景と合成されている。なお、前景のヘリコプターと気球
は必ずしも常に３次元の画像である必要はない。遠くに
位置する場合（画面上に２次元として表示される大きさ
で定義しておけばよい。たとえば２０ドット×２０ドッ
トの大きさよりも小さければ対象物は遠くに存在すると
定義しておけばよい）には、２次元で表現しておき、近
くに位置する場合には３次元で表現してもよい。また、
３次元画像のワイヤーフレーム・モデルにマッピングす
る画像も静止画だけではなく、動画像であってもよい。
画質に関しては中心部分の画質は高く、周辺部分へいく
ほど荒くすることで、ユーザの望む必要な情報を優先的
に、選択して伝送することができる（このように、画像
が合成される位置に応じて、画質を変更することで応答
性の向上が期待できる）。また、３次元画像である場
合、遠方に表示される画像の優先度は低く、近くに表示
される画像の優先度は高く設定すればよい。なお、画質
の制御に関しては量子化ステップを変更することにより
実現できる。

【００５８】図１２は、受信側端末の能力の変動に応じ
た画像伝送を行う方法について説明した図である。次
に、伝送される画像が多くなることにより、受信端末の
処理が過負荷になるのを防ぐために、圧縮装置を含め
て、管理、制御する方法について述べる。例えば、ハー
ドウェアで実現されているＭＰＥＧ２ベースのビデオ・
オン・デマンドシステムでは、送信側の端末は受信側の
端末の性能（たとえば、画像圧縮できる方式やサイズ、
通信プロトコル）を、映像情報を送信、受信する前にお
互いに確認する。このため、送信側端末では、受信側端
末の処理能力がほぼ確定しているため、受信側端末の受
信状況や再生の状況を逐次、モニターする必要はない。

【００５９】一方、ハードウェアで画像の圧縮と伸長を
実現する場合は、端末で画像の圧縮と伸長を行える個数
は固定である。しかし、ソフトウェアで画像の圧縮と伸
長を実現する場合は、端末で画像の圧縮と伸長が行える
個数を動的に可変にできる。又、ソフトウェアでマルチ
タスク環境下で画像の圧縮と伸長を行う場合、画像サイ
ズや、画像圧縮を行うための量子化パラメータ、対象と
する画像（フレーム内符号化かフレーム間符号化、撮影
された画像の内容）等によって大きく影響し、端末で処
理（圧縮、伸長）できる画像サイズ、同時に処理できる
画像の数は時間的に変化する。また、これに伴って送信
側端末では、逐次、受信側端末の受信状況（たとえば、
受信バッファの容量や映像の再生の優先度、受信確認の
応答時間）に応じた画像の圧縮方法（画像圧縮の方式、
画像圧縮の有無、量子化ステップ、圧縮の優先度、圧縮
すべき画像サイズなど）、受信端末が過負荷時の優先度
の決定を検討していかなければ受信側の能力を上回って
しまい破綻を来す。

【００６０】例えば、図１２（ｂ）に示すように、受信
側端末の受信バッファの容量が８０％を超えた場合、送
信側へ受信バッファがあふれそうになっていることを通
知し、画像圧縮の方式（たとえばＭＰＥＧ１からランレ
ングスへ変化させて、圧縮画像の送出量を減らす）、画
像圧縮の有無（画像圧縮して、送信するのを一時中断さ
せる）、圧縮の優先度の変更（圧縮すべきプロセスが複
数ある場合、圧縮するための優先度を下げて、圧縮され
る圧縮画像の送出量を減らす）、画像サイズの変更（Ｃ
ＩＦからＱＣＩＦへと圧縮すべきサイズを小さく変更し
て圧縮画像の送出量を減らす）、量子化ステップの変更
（画質の変更によって圧縮画像の送出量を減らす）によ
る送出量を制限させる方法、フレーム数を調整する方法
（処理を行うフレーム数を減らす）、受信端末が過負荷
時の優先度を決定する方法を適宜、選択、組み合わせて
実施する。これにより受信側端末の受信バッファのオー
バーフローを回避させる。

【００６１】同様に、受信側の受信バッファの容量が２
０％を下回った場合、送信側の端末へ受信側端末の受信
バッファがアンダーフローになりかけている旨を通知し
て、前述とは逆の方法で、送信側の端末で、画像圧縮の
方式、画像圧縮の有無、画像圧縮の優先度、画像のサイ
ズ、量子化ステップ、フレーム数を適宜、選択、組み合
わせて実施する。このように送出量を増大させる方法を
実施することにより、受信側端末の受信バッファのアン
ダーフローを回避させることができる。

【００６２】受信バッファの状態の監視以外にも、受信
側端末での再生能力が限られていて、再生すべき画像が
複数ある場合、受信側端末で、優先して再生すべき画像
を利用者が明示的に決定するか、端末側で、優先して再
生すべき画像を自動的に決定する必要がある（予め、利
用者により優先して再生すべき画像はどれであるかを、
ルールとして受信端末に登録しておく必要がある。例え
ば、画像サイズの小さいものは優先であるとか、背景の
画像として表示させているものは再生の間隔はゆっくり
であってもよいとか）。例えば、受信側端末の負荷（た
とえば、再生に必要なＣＰＵの占有時間）を送信側の端
末へ通知してやることにより、簡単に実現可能である。

【００６３】受信側の端末の再生の負荷が端末の処理能
力の８０％を超えれば、その受信側端末が過負荷になっ
ていることを送信側へ通知し、送信側ではそのことをう
けて、上述と同様の方法で、受信側端末の処理すべき負
荷が下がるように、画像圧縮の方式（たとえば、ＭＰＥ
Ｇ１からランレングスへ変更させて処理量を減らす）、
画像圧縮の有無（画像圧縮して、送信するのを一時中断
させる）、圧縮の優先度の変更（重要度の低い画像に対
しては、圧縮するための優先度を下げて、重要度の高い
画像を優先して圧縮して送出する）、画像サイズの変更
（ＣＩＦからＱＣＩＦへと圧縮すべきサイズを変更し
て、再生側の負荷を減らす）、量子化ステップの変更
（画質の変更によって圧縮画像の送出量を減らす）の方
法、フレーム数を調整する方法、過負荷時の処理の優先
度に基づいて処理する方法を適宜、選択もしくは組み合
わせて実施することによって受信側の端末での処理量を
軽減させる。

【００６４】逆に、負荷が受信側端末の処理能力の２０
％を下回った場合は、受信側の端末の処理能力に余裕が
あるものとして、前述とは逆の方法で、送信側の端末
で、画像圧縮の方式、画像圧縮の有無、画像圧縮の優先
度、画像のサイズ、量子化ステップ、フレーム数を適
宜、選択、組み合わせて実施することにより、高画質
で、フレーム間隔の短い画像を受信側端末へ送出する。
これにより、受信側端末の能力を活かした画像伝送が可
能になる。

【００６５】最後に、受信側端末の処理状況を知る方法
としては、受信側の画像合成装置からの受信確認の応答
時間によって知ることができる。例えば、送信側の端末
から受信側端末へ画像データを送出した場合に、受信側
端末が画像データを受信したことや復号処理、合成や表
示処理が完了したことを送信側端末へ応答する場合、そ
の応答時間が、例えば、通常値として１秒以内である場
合、受信側端末の負荷の増大により、その応答時間は、
５秒といったように長くなる（通常値は、端末接続時に
一度、測定してもよいし、通信時に定期的に測定しても
よいし、利用者が指示してもよい。また、応答時間の測
定は周期的に行ってもよいし、端末の負荷や前回の応答
時間の結果に関連させて測定間隔を変化させてもよ
い）。この応答時間の変化により、前述した画像圧縮の
方式、画像圧縮の有無、画像圧縮の優先度、画像のサイ
ズ、量子化ステップを適宜、選択、組み合わせて実施す
ることにより、受信端末での負荷を低減させることがで
きるので、応答時間を短縮させることができる（図１６
のケース１参照）。受信端末での再生時刻もしくは復号
時刻を受信して上記と同様の処理を行ってもよい。

【００６６】尚、受信側の端末の状態を考慮した方法と
して、前述した受信側の端末の受信バッファの容量、受
信側端末の負荷、受信側の端末の応答時間を測定する方
法をそれぞれ単独に用いるのではなく、適宜、選択し
て、組み合わせて用いてもよい（音声に関しても同様の
方法が適用できる）。また、受信側の端末で優先度情報
に基づいて処理した画像や音声に関する情報（複数の、
画像ストリーム、音声ストリームが存在するとき、受信
側端末で実際に処理された画像、音声ストリームは、ど
のストリームであり、再生された画像ストリームは毎秒
何フレームであったかという情報）を、通信路を通じて
送信先に送信することで、送信側から受信側の端末への
画像データ送信が、受信端末の処理量をこえるような量
になることを未然に防ぐことができる（図１６のケース
２参照、実際に処理された画像データについて知ること
で、送信側の量子化パラメータ、画像サイズなどの情報
量を調整することが可能となる。なお、この例では、フ
レーム単位で処理のフィードバックを返しているが、前
述したように、例えば、Ｈ．２６３ならばＧＯＢのよう
に独立して扱えるような画像単位であってもよい）。以
上の方法は、同様に音声に対しても適用できる。

【００６７】図１３は、本発明の一実施の形態の画像圧
縮装置について説明する図である。尚、本実施の形態
は、画像に対しての例を説明しているが、音声の圧縮に
対しても適用できる。図１３の例では、画像入力手段１
２０７毎に量子化ステップを変化させたり、画像入力手
段１２０７に対する制御によって受信側端末での受信状
況が変化した場合に、量子化ステップを追随させて変化
させることにより、圧縮画像の発生量の増大を低減させ
ようとするものである。図１３の画像圧縮装置は、量子
化ステップに関する情報を管理する量子化ステップ管理
部１２０１、画像入力手段１２０７の制御状態を管理す
る画像入力管理部１２０２、受信側端末装置の受信バッ
ファの状況を監視する他端末制御要求管理部１２０３、
制御の時間的な推移を記録、管理する操作管理部１２０
４、画像圧縮を行う手段である画像圧縮部１２０５、圧
縮結果を通信路や記憶装置に出力する出力部１２０６、
画像入力を行う画像入力手段１２０７及び、これら各部
を管理し、また管理する制御を行う画像処理決定制御手
段１２０８から構成される。

【００６８】尚、画像圧縮の方法としては、ＪＰＥＧ、
ＭＰＥＧ１／２、Ｈ．２６１、Ｈ．２６３のような標準
化されている方式でもよいし、ウェーブレットやフラク
タルのような標準化されていない方式であってもよい。
画像入力手段１２０７はカメラであっても、ビデオ、オ
プティカル・ディスクのような記録装置であってもよ
い。

【００６９】この画像圧縮装置の利用方法としては、画
像入力手段１２０７がカメラである場合、受信側端末に
より送信側の端末のカメラが操作されたときや送信側で
カメラ操作が行われたとき、画質が大きく変化するため
に、送出される符号化量は変動する。例えば、カメラの
コントラストを上げた場合、画像は見やすくなるが、送
出すべき符号化量は増える。そこで、コントラストの向
上とともに前述したように符号化量を低減させるため
に、画像圧縮の方式、画像圧縮の有無、画像圧縮の優先
度、画像のサイズ、量子化ステップ、フレーム数を適
宜、選択、組み合わせて実施することにより、符号化量
を抑えることができる。

【００７０】ここで述べているカメラ操作とは、カメラ
を移動させる方向（パン、チルト、ズーム）、コントラ
スト、フォーカス、カメラ位置（たとえば、図面を撮影
する場合はカメラを下向きに向け、人物を撮影するとき
は水平にする）が挙げられる。画像圧縮の方式を変更す
る方法としては、カメラを下向きに向けた場合は、文書
画像を撮影しているものと判断して、ランレングスで画
像を伝送し、カメラが水平方向にむいている場合は、人
物の顔の様子を撮影しているものとして、Ｈ．２６１で
撮影して画像伝送を行う方法が挙げられる。これによ
り、不必要な情報の伝送を低減させることが可能とな
る。

【００７１】また、複数のカメラが存在し、複数のカメ
ラから得られる映像を伝送する必要がある場合に、通信
容量が限られている場合は、利用者が着目しているカメ
ラの映像の画質やフレーム数を多くして見やすくし、着
目していないカメラの画質やフレーム数は低減してやる
方法が考えられる。着目しているカメラから得られる映
像の画質やフレーム数を操作することにより、情報量が
増大するため、それに応じて着目していないカメラから
得られる映像を制限して発生情報量を調整する必要があ
る。発生する情報量を調整する方法としては、画像サイ
ズ、量子化ステップの値、フレーム数などを調整する方
法が挙げられる。尚、複数のカメラを用いて広視野画像
を作成する場合の例については、図１５を用いて後述す
る。

【００７２】図１４は、操作管理部１２０４が管理する
情報の例である。図１４の例では、画像サイズ、カメラ
制御、他端末の制御要求、量子化ステップ、図示しない
フレーム数について管理されている。これらの管理情報
に基づいて、受信側端末の受信バッファがオーバーフロ
ーしないように、量子化ステップとカメラ操作の関係を
履歴情報として記録、管理することで、カメラ操作に対
する制限を利用者に加えることができる。また、量子化
ステップや画像サイズ、フレーム数などを自動的に変更
させることで、カメラ操作に伴う受信側端末の受信バッ
ファのオーバーフローやアンダーフローを未然に防ぐこ
とができる。

【００７３】図１５に、上記画像圧縮装置を広視野画像
を作成する用途に応用した例を示す。図１５の例では、
複数のカメラから入力された画像を入力部１４０７で取
得する。その得られた複数の画像を受信端末１４０８側
でつなぎ目なく接合（合成）するとき、受信端末１４０
８が過負荷になると端末が破綻を来すので、それを防ぐ
ために、受信端末１４０８における過負荷時の処理を行
うべき画像の順序を定義した優先度を画像に付加する。
これにより、受信端末１４０８側が過負荷になることを
防ぐことができる。

【００７４】図１５に示す画像圧縮装置は、複数のカメ
ラ（Ｎ台）を備えた入力部１４０７と、その入力部１４
０７で得られたそれぞれの画像に対して優先度の付加を
行う優先度決定制御部１４０１と、利用者が（特に、着
目して見たいと思って）カメラを指示、操作した操作履
歴を管理する操作履歴管理部１４０２と、画像の画質を
制御する画質制御部１４０３と、カメラから得られた画
像を優先度に基づいて合成する画像合成部１４０４（優
先度の低い画像は合成しなくてもよい）と、合成結果を
出力する出力部１４０５と、それら各部を制御する圧縮
制御部１４０６とから構成される。出力部１４０５は通
信路を介して受信端末１４０８に接続されている。

【００７５】出力部１４０５の出力先は、記録装置であ
っても通信路であってもよい。また、画像の合成は必ず
しも送信側の端末で行う必要はない。優先度が付加され
た画像を通信路を通して、受信側端末へ送信し、受信端
末側で合成してもよい。なお、得られた複数の画像を送
信側端末で合成して、受信側端末で再生を行う場合、得
られた画像を送信側で受信端末で必要となる（表示の）
優先度の高い順に合成して、伝送路を使って合成画像を
受信端末装置に伝送する。

【００７６】優先度の付加方法としては、利用者が指示
したカメラで得られた画像、過去に指示の多かったカメ
ラで得られた画像から順に高い優先度、高い画質（たと
えば、フレーム数を多く、解像度を高く）なるようにす
ればよい（必ずしも、高い優先度の画像を高画質にする
必要はない）。これにより利用者の着目度合いの大きい
画像が高画質で、優先的に表示される。画像に付加され
た優先度に応じて送信側端末からの画像伝送を制御した
り、受信側端末での画像の伸張や表示を制御することに
より、利用者における端末の応答性を確保することがで
きる。

【００７７】また、優先度、画質の高い画像、フレーム
枚数の多い画像から順に、隣接する接合された画像に対
して段階的に、優先度や画質を下げてゆく（優先度の管
理は、送信側端末で管理しておいてもよいし、受信側端
末で管理しておいてもよい）。優先度の決定方法として
は、必ずしもカメラの操作履歴に基づくものでなくても
よい。前述したように、圧縮する際にかかったローカル
・デコードの時間に基づいて優先度の決定を行ってもよ
いし、優先度、画質の高い画像、フレーム枚数の多い画
像から順に、周辺の画像に対して、処理の実施回数を規
定する実施率を定義してもよい。さらに、音声に関して
も、複数あるカメラ毎にマイクを設け、音声の圧縮の有
無を制御することで、利用者の着目している方向の画像
に対応する音声のみを合成することが可能となる。

【００７８】また、前述したように、送信側端末と受信
側端末との間での応答時間を参照して、量子化ステップ
やフレーム数を決定してもよい。また、受信側端末で過
負荷時に優先度情報に基づいて処理された画像に関する
情報を、通信路を通じて送信先に送信することで、送信
側から受信側端末への画像データ送信を受信端末の処理
量をこえるような量になることを未然に防ぐことができ
る。また、受信端末でのフレームスキップの状態を送信
側へ伝送することにより、その状態に応じてデータ量を
調節することができる。

【００７９】更に、画像は再送を行う伝送方法で伝送
し、音声は再送を行わない伝送方法で伝送して、受信側
端末が、画像の再送回数、受信された音声の誤り率、廃
棄率に関する情報のいずれかの情報を送信側端末に伝送
する構成とする。そうして送信側端末で画像の圧縮方
式、量子化ステップの値、フレーム数、圧縮すべき画像
の大きさ、画像圧縮の有無のいずれかを決定すること
で、画像が乱れることなく、音声の伝送の遅延を小さく
するような制御が可能となる。例えば、ＴＣＰ／ＩＰを
用いた通信では、画像の伝送はＴＣＰで、音声の伝送は
ＵＤＰで行うことで実現できる（映像と音声は物理的に
同じ伝送路にあってもよいし、なくてもよい）。尚、通
信の方式はＴＣＰ／ＩＰだけに限定されない。この方式
は、複数の映像や音声を同時に伝送する場合、それぞれ
の音声毎に廃棄率や誤り率を定義して、複数の映像の圧
縮方法や伝送方法を制御してもよい。

【００８０】最後に、通常、アナログ電話回線を用いた
低ビットレートの画像伝送や、画像の内容が大きく変動
する場合、画像に大きなブロックノイズ、もあれが発生
する。このような場合に圧縮処理だけで画像の品質を保
つのは難しい。そこで、画像の出力側のモニターに低域
の信号のみを透過させるフィルター（例えば、画像処理
によるローパス・フィルター、あるいは物理的な偏光フ
ィルター）を用いれば、画像はぼやけた感じにはなるも
のの、ノイズや、もあれが気にならない画像が得られ
る。

【００８１】

【発明の効果】以上述べたところから明らかなように本
発明は、同時に複数の映像や音声の復号、合成を行う場
合に、端末の負荷状況に応じて優先度に基づいて処理量
を制御できるという長所を有する。

【００８２】また、本発明は、課金状況に応じて複数の
映像や音声を合成できるという利点がある。

【図面の簡単な説明】

【図１】本発明の一実施の形態における画像復号化符号
化装置の概略構成図である。

【図２】同実施の形態における別の例を示す画像音声復
号化符号化装置の概略構成図である。

【図３】通信、記録フォーマットで優先度に関する情報
を付加する場合の例を説明する図である。

【図４】ソフトウェアで本発明の構成をした場合の例を
説明する図である。

【図５】情報の構造について説明する図である。

【図６】ＤＥＭＵＸスレッドの動作について説明する図
である。

【図７】監視スレッドの動作について説明する図であ
る。

【図８】デコード・プロセスの動作について説明する図
である。

【図９】画像合成スレッドの動作について説明する図で
ある。

【図１０】表示監視スレッドの動作について説明する図
である。

【図１１】画像合成装置のユーザインターフェースにつ
いて説明する図である。

【図１２】受信側端末の能力の変動に応じた画像伝送を
行う方法について説明した図である。

【図１３】本発明の一実施の形態の画像圧縮装置につい
て説明する図である。

【図１４】操作管理部が管理する情報について説明する
図である。

【図１５】広視野画像を作成する場合の画像圧縮装置を
説明する図である。

【図１６】送信端末と受信端末との応答状況を説明する
図である。

【符号の説明】

１１ 受信管理部 １２ 分離部 １３ 送信管理部 １４ 優先度決定部 １７ 時間情報管理部 １８ 画像伸長部 １９ 画像合成部 ２０ 音声伸長部 ２１ 音声合成部 ３１ ＤＥＭＵＸスレッド ３６ デコード・プロセス ３７ 監視スレッド ３９ 画像合成スレッド ４２ 表示監視スレッド １２０４ 操作管理部 １２０５ 画像圧縮部 １２０８ 画像処理決定制御手段 １４０１ 優先度決定制御部 １４０２ 操作履歴管理部 １４０４ 画像合成部 １４０７ 入力部

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） // Ｈ０４Ｊ 3/00 Ｆターム(参考） 5C059 KK37 PP04 PP13 RB02 RB09 RC04 RC11 RC32 SS06 SS30 UA05 UA38 5C063 AA01 AB03 AB07 AB11 AC01 AC05 AC10 CA23 CA36 DA01 DA05 DA07 DA13 DB10 5C064 AA01 AA02 AB04 AC01 AC11 AD01 AD14 BA01 BB10 BC01 BC18 BC23 BD01 BD08 BD09 5K028 AA12 EE02 EE03 EE05 EE07 EE09 EE12 KK32 MM12

Claims (2)

【特許請求の範囲】
1. 【請求項１】 少なくとも再生許可情報に基づいて、復
   号、合成、表示すべき画像や音声の順番、有無、再生方
   法を決定することを特徴とする画像音声符号化復号化装
   置。
2. 【請求項２】 前記再生許可情報は、課金に関する情
   報、サービスの内容を示す情報、パスワード、利用者コ
   ード、国別コード、合成、表示の順位を示す情報、復号
   の順位を示す情報、利用者の指示、端末の処理能力、再
   生時刻のうち１つ以上の情報である請求項１記載の画像
   音声符号化復号化装置。