(57)【要約】      （修正有）【課題】複数地点の画像データが含まれていて、１つのビデオ符号化データとして復号することが可能なビデオ符号化データを受信側端末に送信可能なビデオ符号化データ合成装置を提供する。【解決手段】ビデオ符号化データ合成装置１０は、ビデオ符号化データを入力して復号する２以上のＮ個の復号器１１1〜１１Nからなる復号部１１と、復号部１１からの画像データを符号化するＮ個の符号化器１２1〜１２Nからなる符号化部１２と、前記符号化されたビデオ符号化データをフレーム単位で所定フレーム数分、記憶可能なＮ個のバッファ１３1〜１３Nからなるバッファ部１３と、バッファ部１３におけるビデオ符号化データの格納状況を示すバッファ管理テーブルを管理するバッファ管理部１５と、前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部１４と、を備える。【選択図】図１
2005244898.tif 000002
【特許請求の範囲】
【請求項１】
ビデオ符号化データを入力して復号する２以上のＮ個の復号器からなる復号部と、
前記復号部からの画像データを符号化するＮ個の符号化器からなる符号化部と、
前記符号化されたビデオ符号化データをフレーム単位で所定フレーム数分、記憶可能なＮ個のバッファからなるバッファ部と、
前記バッファ部におけるビデオ符号化データの格納状況を示すバッファ管理テーブルを管理するバッファ管理部と、
前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部と、
前記バッファ管理テーブルに基づいて、１フレーム分の合成処理を実行するように、前記ストリーム合成部に指示を出す制御部と、
を備えることを特徴とするビデオ符号化データ合成装置。
【請求項２】
前回のデータからの誤差がゼロであることを示すリピートデータを保持するリピートデータ部をさらに有し、
前記バッファ部内の少なくとも１つのバッファにおいて、ビデオ符号化データが存在しない場合、前記制御部は、そのビデオ符号化データが存在しないバッファ用のデータとして、前記リピートデータ部のリピートデータを用いることを特徴とする請求項１記載のビデオ符号化データ合成装置。
【請求項３】
ビデオ符号化データを入力して復号する２以上のＮ個の復号器からなる復号部と、
前記復号部からの画像データをフレーム単位で所定フレーム数分、記憶可能なＮ個のフレームメモリからなるフレームメモリ部と、
前記フレームメモリ部における画像データの格納状況を示すフレームメモリ管理テーブルを管理するメモリ管理部と、
前記フレームメモリ部からの画像データを符号化するＮ個の符号化器からなる符号化部と、
前記符号化されたビデオ符号化データをフレーム単位で少なくとも１フレーム分、記憶可能なＮ個のバッファからなるバッファ部と、
前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部と、
前記フレームメモリ管理テーブルに基づいて、前記符号化部、バッファ部を制御すると共に、前記１フレーム分の合成処理を実行するように、前記ストリーム合成部に指示を出す制御部と、
を備えることを特徴とするビデオ符号化データ合成装置。
【請求項４】
前記制御部は、フレーム内符号化のみで１フレーム分の符号化を行うかフレーム内符号化に加えて過去のフレームとのフレーム間差分データも利用して１フレーム分の符号化を行うかを決定する符号化形式決定部を有すると共に、決定された符号化の形式に基づいて、前記フレームメモリ部からの各画像データを符号化するように前記各符号化器に指示を出すことを特徴とする請求項３記載のビデオ符号化データ合成装置。
【請求項５】
前回のデータからの誤差がゼロであることを示すリピートデータを保持するリピートデータ部をさらに有し、
前記差分データも利用して１フレーム分の符号化を行う場合に、前記フレームメモリ部内の少なくとも１つのフレームメモリにおいて、新たな画像データが存在しない場合、前記制御部は、その画像データが存在しないフレームメモリ用のデータとして、前記リピートデータ部のリピートデータを用いることを特徴とする請求項３記載のビデオ符号化データ合成装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ符号化合成装置に関する。
【背景技術】
【０００２】
多地点制御装置（Multipoint Control Unit：以下、ＭＣＵという）は、複数地点に設置されたＴＶ会議端末から送信されてくるビデオ符号化データを受信して、その各ＴＶ会議端末に対して、例えば、その端末が送信したビデオ符号化データを除く他端末のビデオ符号化データを送信する装置である。
【０００３】
複数のＴＶ会議端末と、それら端末に接続されたＭＣＵとを備える上述のＴＶ会議システムにおいて、従来、様々な方式が実現されている。なお、以下の図１７〜図２２を参照して行われる説明では、５地点に設置されたＴＶ会議端末により会議を行う場合に、各地点には、他の４地点からの合成画像が送信される。
【０００４】
まず、図１７は、ストリーム多重化方式に基づいて画像合成処理を行うＭＣＵの構成を示す図である。
このストリーム多重化方式においては、ＭＣＵ内のヘッダ検出部１０１1、・・・、１０１4は、複数地点（４地点）に設置されるＴＶ会議端末から送信されてくるビデオ符号化データを受信する。そして、それらヘッダ検出部は、そのビデオ符号化データにおいて、１フレームごとに挿入されているフレームヘッダを検出して、その検出したフレームヘッダに各地点を識別するための地点番号を挿入し、バッファ１０２1、・・・、１０２4に一時蓄積する。バッファ監視部１０４は、それらバッファへのデータの格納状況を監視する。そして、例えば、すべてのバッファについて、データが揃ったときに、制御部１０５に多重化処理部１０３に起動をかけるように指示を出す。多重化処理部１０３は、制御部１０５からの指示に基づいて起動し、このようなヘッダ部に地点番号が挿入されたビデオ符号化データを１フレームごとにバッファ１０２1、・・・、１０２4から読み出し、多重化して各ＴＶ会議端末あてに送信する。なお、上記ストリーム多重化方式は、例えば下記特許文献１などに開示されている。
【０００５】
図１８は、５地点に対応可能なストリーム多重化方式のＭＣＵの構成を示す図である。図に示すように、このストリーム多重化方式では、地点数の増設に対して、多重化処理部を増設するだけで対応可能であるという特徴を有する。
【０００６】
図１９は、ストリーム合成方式に基づいて画像合成処理を行うＭＣＵの構成を示す図である。
このストリーム合成方式においては、ＭＣＵ内のバッファ１１１1、・・・、１１１4は複数地点（４地点）に設置されるＴＶ会議端末から送信されてくるビデオ符号化データを受信して一時蓄積する。バッファ監視部１１３は、それらバッファへのデータの格納状況を監視する。そして、例えば、すべてのバッファについて、データが揃ったときに、制御部１１４にストリーム合成処理部１１２に起動をかけるように指示を出す。ストリーム合成処理部１１２は、制御部１１４からの指示に基づき起動し、ビデオ符号化データのままで合成処理を行う。この際、各ビデオ符号化データを合成したものを１つのビデオ符号化データとして受信側のＴＶ会議端末が認識できるように、それらビデオ符号化データの境界において、番号が連続するように、番号の付け替えを行う。なお、上記ストリーム合成方式は、例えば下記特許文献２などに開示される。
【０００７】
なお、特許文献２には、ＭＣＵからのビデオ符号化データの送信遅延を回避する工夫も開示されている。すなわち、すべての地点において、ビデオ符号化データが１フレーム分揃ってから送信するのではなく、例えば、ビデオ符号化データが１フレーム分揃わない地点が存在したとしても、そのような揃わない地点が存在する段階において、ＭＣＵからのデータ送信を可能としている。このため、その揃わない地点に対して、前回の画像データから変化が無いことを示す情報（ＧＯＢ０）を挿入する。
【０００８】
図２０は、５地点に対応可能なストリーム合成方式のＭＣＵの構成を示す図である。図に示すように、このストリーム合成方式では、地点数の増設に対して、ストリーム合成部を増設するだけで対応可能であるという特徴を有する。
【０００９】
図２１は、完全合成方式に基づいて画像合成処理を行うＭＣＵの構成を示す図である。
この完全合成方式においては、ＭＣＵ内の復号器１２１1、・・・、１２１4は複数地点（４地点）に設置されるＴＶ会議端末から送信されてくるビデオ符号化データを受信して、それら各地点からのデータに対し復号処理を行い、画像をフレームメモリ１２２1、・・・、１２２4に蓄積する。そして、画像サイズ変更処理１２３1、・・・、１２３4を介することで、それらフレームメモリに蓄積した画像に対して、拡大縮小などの画像サイズ変更処理を施す。メモリ管理部１２７は、それらフレームメモリへのデータの格納状況を管理する。そして、例えば、すべてのフレームメモリについて、データが揃ったときに、制御部１２８に、フレームメモリからのデータ読み出し、画像サイズ変更、画面合成、符号化、の一連の処理について起動をかけるように指示を出す。画面合成処理部１２５は、画像サイズ変更処理によってサイズ変更された画像データを入力して、所定の地点に送信する画像、例えば、上述したように、その地点の端末が送信した画像を除く他端末の画像、を１画面として合成する処理を行う。符号化器１２６は、合成された１画面に対して符号化処理を行う。符号化されたデータは、所定の地点の端末に送信される。なお、上記完全合成方式は、例えば下記特許文献３などに開示される。
【００１０】
図２２は、５地点に対応可能な完全合成方式のＭＣＵの構成を示す図である。図に示すように、この完全合成方式では、地点数の増設に対して、画面合成処理部と符号化部とをその都度、増設しなければならない。
【特許文献１】特開平５−３７９２９号公報  「ビデオ信号合成方式」
【特許文献２】特開平７−２２２１３１号公報  「多地点会議用画面合成システムおよび方法」
【特許文献３】特開平８−２０５１１５号公報  「画像合成符号化装置」
【発明の開示】
【発明が解決しようとする課題】
【００１１】
上述のストリーム多重化方式においては、ＭＣＵの主な処理は、フレームヘッダの検出、地点番号のヘッダ部への挿入、多重化処理であり、受信したビデオ符号化データに対して、復号／符号化処理を行っていない。したがって、一般に、ＭＣＵの装置負荷を増大させる第一の原因となる符号化処理を行わなくて済むことから、装置の処理負荷が非常に軽いという特徴を有する。
【００１２】
しかし、この方式では、ＭＣＵからのビデオ符号化データを受信する側であるＴＶ会議端末において、ＭＣＵにおいて、どのような規則に従って地点番号を挿入するのかを知っている必要がある。つまり、送信側と受信側とにおいて、上位のレイヤ間で標準化で定められている以外の事項に関する取り決めが必要となる。このことを、「１つのビデオ符号化データとして復号できない」ということもある。なお、上記の記載から明らかなように、この方式においては、受信側において、標準化された手順によらずに復号処理が行なわれる、すなわち、受信したビデオ符号化データを地点別に復号処理している。
【００１３】
また、上述のストリーム合成方式においても、他地点に送信するビデオ符号化データの境界において、番号が連続するように、番号の付け替えを行う関係から、復号／符号化処理を行っていないため、上記ストリーム多重化方式同様に、ＭＣＵ側の装置負荷が軽減できる。
【００１４】
例えば、TV電話・TV会議用標準符号化方式であるH.261の動き補償フレーム間符号化方式を適用した場合は、予測に利用できる参照画面は、同じ画面の内部に制約されるので、動きベクトルは画面の外部を指すことがなく、このストリーム合成方式を問題なく適用可能である。しかし、ＭＰＥＧ方式などには、画面の外部を指すような動きベクトルが存在しており、画面の内部を指すベクトルとは異なる処理を行うことが規定されている。例えば、合成前は画面の縁であった部分にそのような外部を指すベクトルが存在し、その部分が合成後に他の地点の画面と接する画面位置に合成される場合を考える。本来は画面の外部を指すベクトルとして、画面の内部を指すベクトルとは異なる処理を行わなければならないが、合成後は画面の内部を指すベクトルとして処理されてしまう場合が存在することになる。この場合、符号化時と同じ参照画面を生成することができずに、復号処理した画面が崩れてしまう。
【００１５】
そこで、このような復号時の不都合を回避するには、MPEG方式の場合においても、符号化時に画面の外部を指す動きベクトルを生成しないように、符号化方式に制約を設ける必要が生じる。つまり標準化に準拠した符号化方式のＴＶ会議端末であれば、全て接続できるＭＣＵではなくなる。
【００１６】
また、上述の完全合成方式においては、ＭＣＵ内において、受信した複数地点からのビデオ符号化データに対して復号処理を行うと共に、送信先のＴＶ会議端末に応じて、復号された画像データを合成する画面合成処理を行う。そして、そのＴＶ会議端末にその合成された画面データを送信するに先立って、その合成された画像データを符号化する処理を、送信先の地点数だけ行なう。このため、ストリーム合成方式のように動きベクトルについて、例えば、常に画面内部を指すように制約をつける必要がなくなる。しかし、ＭＣＵ内において、復号／符号化処理を行わない上記特許文献１および２の技術と比較して、ＭＣＵ側の装置負荷が非常に大きくなってしまうという問題がある。しかも、図２２に見られるように、この方式では、地点数の増設に対して、処理負荷が高い符号化部をその都度、増設する。これは、地点数が増えるにつれて、処理負荷も急激に増すことを意味している。
【００１７】
本発明の課題は、複数地点の画像データが含まれていて、１つのビデオ符号化データとして復号することが可能なビデオ符号化データを受信側端末に送信可能なビデオ符号化データ合成装置を、高い装置負荷を要することなく、提供することである。
【課題を解決するための手段】
【００１８】
図１は、本発明の第１態様のビデオ符号化データ合成装置の構成を示すブロック図である。
図１において、ビデオ符号化データ合成装置１０は、ビデオ符号化データを入力して復号する２以上のＮ個の復号器１１1、１１2、・・・、１１Nからなる復号部１１と、復号部１１からの画像データを符号化するＮ個の符号化器１２1、１２2、・・・、１２Nからなる符号化部１２と、符号化されたビデオ符号化データをフレーム単位で所定フレーム数分、記憶可能なＮ個のバッファ１３1、１３2、・・・、１３Nからなるバッファ部１３と、バッファ部１３におけるビデオ符号化データの格納状況を示すバッファ管理テーブルを管理するバッファ管理部１５と、前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部１４と、前記バッファ管理テーブルに基づいて、１フレーム分の合成処理を実行するように、前記ストリーム合成部１４に指示を出す制御部１６と、を備える。
【００１９】
第１態様のビデオ符号化データ合成装置では、Ｎ個のビデオ符号化データを入力して復号した後に、都合よく、例えば、後段のストリーム合成部１４にてビデオ符号化データのまま合成可能なように符号化を行い、それらのビデオ符号化データは各バッファに格納される。そして、全てのバッファについて１フレーム分のビデオ符号化データが揃う等のデータ読み出しタイミングによって、各バッファからビデオ符号化データが読み出され、それらビデオ符号化データについてストリーム合成を行っている。
【００２０】
このため、復号した画像データを各地点のＴＶ会議端末ごとに合成して、その合成された画面データに対して符号化を行う従来の方式と比較すると、符号化する画像データの量を大幅に減らすことができる。また、各地点のＴＶ会議端末に送信されるビデオ符号化データは、地点番号等をヘッダ部に挿入するなどの特殊な操作が行なわれておらず、標準化で定められている以外の事項に関する取り決めを必要としないので、１つのビデオ符号化データとして復号することができる。
【００２１】
図２は、本発明の第２態様のビデオ符号化データ合成装置の構成を示すブロック図である。
図２において、ビデオ符号化データ合成装置２０は、ビデオ符号化データを入力して復号する２以上のＮ個の復号器２１1、２１2、・・・、２１Nからなる復号部２１と、復号部２１からの画像データを符号化するＮ個の符号化器２２1、２２2、・・・、２２Nからなる符号化部２２と、符号化されたビデオ符号化データをフレーム単位で所定フレーム数分、記憶可能なＮ個のバッファ２３1、２３2、・・・、２３Nからなるバッファ部２３と、バッファ部２３におけるビデオ符号化データの格納状況を示すバッファ管理テーブルを管理するバッファ管理部２５と、前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部２４と、前記バッファ管理テーブルに基づいて、１フレーム分の合成処理を実行するように、前記ストリーム合成部２４に指示を出す制御部２６と、前回のデータからの誤差がゼロであることを示すリピートデータを保持するリピートデータ部２７と、を備える。
【００２２】
上記第２態様では、上記第１態様に対して、リピートデータ部２７がさらに追加されている。そして、前記バッファ部２３内の少なくとも１つのバッファにおいて、ビデオ符号化データが存在しない場合に、前記制御部２６は、そのビデオ符号化データが存在しないバッファ用のビデオ符号化データとして、前記リピートデータ部２７のリピートデータを用いている。
【００２３】
このようにすれば、すべてのバッファについて１フレーム分のビデオ符号化データが揃うまで待つことなくストリーム合成を行うことが可能となるので、ビデオ符号化データ合成装置からのビデオ符号化データの送信遅延を回避することができる。
【００２４】
図３は、本発明の第３態様のビデオ符号化データ合成装置の構成を示すブロック図である。
図３において、ビデオ符号化データ合成装置３０は、ビデオ符号化データを入力して復号する２以上のＮ個の復号器３１1、３１2、・・・、３１Nからなる復号部３１と、復号部３１からの画像データをフレーム単位で所定フレーム数分、記憶可能なＮ個のフレームメモリ３２1、３２2、・・・、３２Nからなるフレームメモリ部３２と、フレームメモリ部３２における画像データの格納状況を示すフレームメモリ管理テーブルを管理するメモリ管理部３６と、フレームメモリ部３２からの画像データを符号化するＮ個の符号化器３３1、３３2、・・・、３３Nからなる符号化部３３と、符号化されたビデオ符号化データをフレーム単位で少なくとも１フレーム分、記憶可能なＮ個のバッファ３４1、３４2、・・・、３４Nからなるバッファ部３４と、前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部３５と、前記フレームメモリ管理テーブルに基づいて、前記符号化部３３、バッファ部３４を制御すると共に、前記１フレーム分の合成処理を実行するように、前記ストリーム合成部３５に指示を出す制御部３７と、を備える。
【００２５】
ここで、第３態様のビデオ符号化データ合成装置では、Ｎ個のビデオ符号化データを入力して復号した後に、一旦、フレームメモリ部３２に格納することから、符号化部３３による画像データの符号化を同期して行うことが可能となる。よって、フレーム内符号化のみで１フレーム分の符号化を行う“Ｉピクチャ”やフレーム内符号化に加えて過去のフレームとのフレーム間差分データも利用して１フレーム分の符号化を行う“Ｐピクチャ”などの異なる形式の画像データも扱うことが可能となる。そして、全てのフレームメモリについて１フレーム分の画像データが揃う等のデータ読み出しタイミングによって、各フレームメモリから画像データが読み出され、それら画像データについて符号化部３３によって、都合よく、例えば、後段のストリーム合成部１４にてビデオ符号化データのまま合成可能なように符号化が行われた後に、バッファ部３４を介してストリーム合成を行っている。
【００２６】
このため、復号した画像データを各地点のＴＶ会議端末ごとに合成して、その合成された画面データに対して符号化を行う従来の方式と比較すると、符号化する画像データの量を大幅に減らすことができる。また、各地点のＴＶ会議端末に送信されるビデオ符号化データは、地点番号等をヘッダ部に挿入するなどの特殊な操作が行なわれておらず、標準化で定められている以外の事項に関する取り決めを必要としないので、１つのビデオ符号化データとして復号することができる。
【００２７】
図４は、本発明の第４態様のビデオ符号化データ合成装置の構成を示すブロック図である。
図４において、ビデオ符号化データ合成装置は、ビデオ符号化データを入力して復号する２以上のＮ個の復号器４１1、４１2、・・・、４１Nからなる復号部４１と、復号部４１からの画像データをフレーム単位で所定フレーム数分、記憶可能なＮ個のフレームメモリ４２1、４２2、・・・、４２Nからなるフレームメモリ部４２と、フレームメモリ部４２における画像データの格納状況を示すフレームメモリ管理テーブルを管理するメモリ管理部４６と、フレームメモリ部４２からの画像データを符号化するＮ個の符号化器４３1、４３2、・・・、４３Nからなる符号化部４３と、符号化されたビデオ符号化データをフレーム単位で少なくとも１フレーム分、記憶可能なＮ個のバッファ４４1、４４2、・・・、４４Nからなるバッファ部４４と、前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部４５と、前記フレームメモリ管理テーブルに基づいて、前記符号化部４３、バッファ部４４を制御すると共に、前記１フレーム分の合成処理を実行するように、前記ストリーム合成部４５に指示を出す制御部４７と、前回のデータからの誤差がゼロであることを示すリピートデータを保持するリピートデータ部４８と、を備える。
【００２８】
上記第４態様では、前記制御部４７は、前記各符号化器による符号化をフレーム内符号化のみで１フレーム分の符号化を行う“Ｉピクチャ”として行うかフレーム内符号化に加えて過去のフレームとのフレーム間差分データも利用して１フレーム分の符号化を行う“Ｐピクチャ”として行うかを決定する符号化形式決定部を有すると共に、決定された符号化の形式に基づいて、前記フレームメモリ部４２からの各画像データを符号化するように前記各符号化器に指示を出している。
【００２９】
そして、Ｐピクチャとして符号化を行う場合に、前記フレームメモリ部４２内の少なくとも１つのフレームメモリにおいて、新しい画像データが存在しない場合、前記制御部４７は、その画像データが存在しないフレームメモリに対しては、対応する符号化器は処理を実行させることができず、対応するバッファにはビデオ符号化データは存在しないため、そのビデオ符号化データが存在しないバッファ用のデータとして、前記リピートデータ部４８のリピートデータを用いている。
【００３０】
このようにすれば、すべてのフレームメモリについて１フレーム分の画像データが揃うまで待つことなく、制御部は、フレームメモリ部からのデータ読み出しからストリーム合成に至るまでの一連の処理を起動することが可能となるので、ビデオ符号化データ合成装置からのビデオ符号化データの送信遅延を回避することができる。
【発明の効果】
【００３１】
本発明のビデオ符号化データ合成装置では、Ｎ個のビデオ符号化データを入力して復号した後に、都合よく、例えば、後段のストリーム合成部にてビデオ符号化データのまま合成可能なように符号化を行い、それらのビデオ符号化データは各バッファに格納される。そして、全てのバッファについて１フレーム分のビデオ符号化データが揃う等のデータ読み出しタイミングによって、各バッファからビデオ符号化データが読み出され、それらビデオ符号化データについてストリーム合成を行っている。
【００３２】
このため、復号した画像データを各地点のＴＶ会議端末ごとに合成して、その合成された画面データに対して符号化を行う従来の方式と比較すると、符号化する画像データの量を大幅に減らすことができる。また、各地点のＴＶ会議端末に送信されるビデオ符号化データは、地点番号等をヘッダ部に挿入するなどの特殊な操作が行なわれておらず、標準化で定められている以外の事項に関する取り決めを必要としないので、１つのビデオ符号化データとして復号することができる。
【００３３】
また、本発明のビデオ符号化データ合成装置では、Ｎ個のビデオ符号化データを入力して復号した後に、一旦、フレームメモリ部に格納することから、符号化部による画像データの符号化を同期して行うことが可能となる。よって、ＩピクチャやＰピクチャなどの異なる形式の画像データも扱うことが可能となる。そして、全てのフレームメモリについて１フレーム分の画像データが揃う等のデータ読み出しタイミングによって、各フレームメモリから画像データが読み出され、それら画像データについて符号化部によって、都合よく、例えば、後段のストリーム合成部にてビデオ符号化データのまま合成可能なように符号化が行われた後に、バッファ部を介してストリーム合成を行っている。
【００３４】
このため、復号した画像データを各地点のＴＶ会議端末ごとに合成して、その合成された画面データに対して符号化を行う従来の方式と比較すると、符号化する画像データの量を大幅に減らすことができる。また、各地点のＴＶ会議端末に送信されるビデオ符号化データは、地点番号等をヘッダ部に挿入するなどの特殊な操作が行なわれておらず、標準化で定められている以外の事項に関する取り決めを必要としないので、１つのビデオ符号化データとして復号することができる。
【発明を実施するための最良の形態】
【００３５】
以下、本発明の実施の形態を、図面を参照しながら詳細に説明する。なお、以下の説明では、５つのＴＶ会議端末がビデオ符号化データ合成装置に接続されることで、ＴＶ会議システムを構成するものとしている。この場合、各端末には、好ましくは自端末を除く他の４端末からのビデオ符号化データが合成されて表示される。Ｍ個のＴＶ会議端末と、それらＭ個のＴＶ会議端末に接続されたＭＣＵとからなるＴＶ会議システムに対して、以下の各実施形態の説明を拡張することは容易である。
【００３６】
図５は、本発明の各実施形態に共通するＴＶ会議システムの構成図である。
図５において、ＴＶ会議システム５０は、ＴＶ会議端末５１、５２、５３、５４、５５が、ビデオ符号化データ合成装置５６に接続されることで構成されている。
【００３７】
図６は、本発明の第１実施形態のビデオ符号化データ合成装置の構成を示すブロック図である。
図６のビデオ符号化データ合成装置は、例えば図１のＴＶ会議端末５１、５２、５３、５４からの画像データを合成して、ＴＶ会議端末５５に送信する。
【００３８】
図６において、ビデオ符号化データ合成装置６０は、復号部６１、画像サイズ変更部６２、符号化部６３、バッファ部６４、ストリーム合成部６５、バッファ管理部６６、制御部６７、リピートデータ部６８、からなる。
【００３９】
復号部６１は、復号器６１1、６１2、６１3、６１4からなる。画像サイズ変更部６２は、サイズ変更処理６２1、６２2、６２3、６２4からなる。符号化部６３は、符号化器６３1、６３2、６３3、６３4からなる。バッファ部６４は、バッファ６４1、６４2、６４3、６４4からなる。
【００４０】
図６において、復号部６１の各復号器６１1、６１2、６１3、６１4には、例えばＴＶ会議端末１１〜１４からのビデオ符号化データが入力される。そして、そこで、そのビデオ符号化データに対して復号処理が行われた後、必要に応じて伸長される。
【００４１】
画像サイズ変更部６２は、拡大や縮小などの画像サイズの変更処理を行なう。本実施形態においては、画像サイズ変更部６２は、受信した画像データの画像サイズを１／４に縮小する処理を行う。受信した画像サイズに対し、サイズ変更を行なわない場合は、画像サイズ変更部６２をビデオ符号化データ合成装置の構成から除くことができる。すなわち、各サイズ変更処理６２1、６２2、６２3、６２4は、各復号器６１1、６１2、６１3、６１4にて復号された画像データの画像サイズをそれぞれ１／４に縮小する。
【００４２】
例えば、各ＴＶ会議端末で、ＣＩＦ（Common Intermediate Format;横３５２ピクセル、縦２８８ピクセル）サイズの画像を符号化し送信した場合、そのビデオ符号化データは各復号器を介することによって、再びそのＣＩＦサイズの画像に復号され、それら復号された画像データは、各サイズ変更処理を介することで、それぞれ、１／４にサイズが縮小されて、ＱＣＩＦ（横１７６ピクセル、縦１４４ピクセル）サイズとなる。
【００４３】
その後、この１／４にサイズが縮小された各画像データは、符号化部６３に入力される。そして、そこで、その画像データを必要に応じて圧縮した後に、都合よく、例えば、後段のストリーム合成部６５にてビデオ符号化データのまま合成可能なように符号化処理が行われる。
【００４４】
すなわち、各サイズ変更処理６２1、６２2、６２3、６２4を介することで、１／４に縮小された画像データは、符号化器６３1、６３2、６３3、６３4にそれぞれ入力され、そこで、後段においてストリーム合成が行いやすいような符号化処理、例えば、ＭＰＥＧ４方式では、画面の外をベクトルが指さないようにする等、が行われる。
【００４５】
バッファ６４1、６４2、６４3、６４4には、それぞれ、符号化器６３1、６３2、６３3、６３4を介して符号化された、ビデオ符号化データが格納される。
バッファ管理部は、バッファ６４1、６４2、６４3、６４4内のそれぞれのビデオ符号化データの格納状況を示すバッファ管理テーブルを管理する。このバッファ管理テーブルは、例えば、前段の符号化器６３1、６３2、６３3、６３4からの画像データの入力や、制御部からの読み出し指示に対応して、書き換えられる。
【００４６】
なお、図６の示す構成から、第１実施形態においては、符号化部６３による符号化処理は非同期で行なわれる。よって、この第１実施形態のビデオ符号化データ合成装置は、１つの種別の画像データのみ、例えば、Ｉピクチャのみ、または、Ｐピクチャのみ、を扱う。Ｉピクチャでは、１フレーム内をフレーム内符号化のみで構成する。また、Ｐピクチャでは、フレーム内符号化に加えて、送信済みの他のフレームを参照フレームとして、その参照フレームからの差分データに基づいて１フレームを構成する。このため、Ｐピクチャの符号データのみでは、画像を正常に再生できない。
【００４７】
図７は、バッファ部６４内のあるバッファに対応するバッファ管理テーブルの時系列的な更新の状況、すなわち、動作遷移の一例を示す図である。
図７では、このバッファに対応するバッファ管理テーブルは、最大格納フレーム数が３であるリングバッファとして構成される。よって、データの書き込み領域の先頭を示す書き込みポインタや、データの読み出し領域の先頭を示す読み出しポインタは、「０」「１」「２」のいずれかの値をとる。
【００４８】
図７の例では、まず、遷移Ｎｏ．１において、初期化が行なわれ、書き込みポインタ、読み出しポインタ共に、「０」に設定される。そして、遷移Ｎｏ．２において、前段の符号化器からの符号化されたビデオ符号化データがこのバッファに入力されたことに伴って、「０」番の領域にそのビデオ符号化データが書き込まれ、その書き込み動作後には、次にデータの書き込みを行なう領域の先頭を示すポインタとして書き込みポインタが「１」にインクリメントされる。このバッファに現在、格納されているデータ数を示す格納フレーム数についても「０」から「１」にインクリメントされる。
【００４９】
続いて、遷移Ｎｏ．３において、制御部からの読み出し指示によって、バッファに格納されているビデオ符号化データが、読み出される。ここでは、最も古いデータから読み出される。この読み出し処理に伴って、読み出しポインタは「０」から「１」にインクリメントされる。また、格納フレーム数は、「１」から「０」にデクリメントされる。
【００５０】
続く、遷移Ｎｏ．４〜６では、前段の符号化器からこのバッファへのデータ書き込みが行なわれる。
この一連の書き込み処理において、動作後の書き込みポインタが「１」→「２」→「０」→「１」の順にインクリメントされ（最大格納数が「３」のリングバッファであることから「２」の次は「０」となる）、格納フレーム数も連動して「０」→「１」→「２」→「３」とインクリメントされる。
【００５１】
遷移Ｎｏ．６の動作後の状態では、リングバッファは、最大格納数「３」に対応する分のデータをすでに格納していて、満杯の状態になっている。この状態において、例えば遷移Ｎｏ．７に示すように、続いて書き込みが行なわれると、遷移Ｎｏ．４において、書き込みを行なった「１」の領域のデータは、読み出されることなく上書きされる。このため、この遷移Ｎｏ．７の書き込み動作の前後で、格納フレーム数は変化しないが、読み出しポインタは「１」→「２」にインクリメントされる。
【００５２】
続いて、遷移Ｎｏ．８〜１０において、制御部からの読み出し指示によって、このバッファからデータの読み出しが行なわれる。
この一連の読み出し処理において、動作後の読み出しポインタが「２」→「０」→「１」→「２」の順にインクリメントされ、格納フレーム数も連動して「３」→「２」→「１」→「０」とデクリメントされる。
【００５３】
遷移Ｎｏ．１１では、格納フレーム数「０」の状態において、制御部からの読み出し指示が行なわれている。このような格納フレーム数が「０」の場合に行われる読み出し指示に対しては、その格納フレーム数が「０」であり、したがって、ビデオ符号化データが存在しないバッファ用のデータとして、リピートデータ部のリピートデータが用いられる。
【００５４】
遷移Ｎｏ．１２では、前段の符号化器からの符号化されたビデオ符号化データがこのバッファに入力される。そして、この書き込み動作後には、書き込みポインタが「２」→「０」にインクリメントされ、かつ、格納フレーム数が「０」→「１」にインクリメントされる。
【００５５】
図８は、上記の制御部が行なう処理を示すフローチャートである。この制御部は、一定間隔のタイマーによって起動され、その都度、下記フローチャートに示す処理を行う。
図８において、ステップＳ１０１において、タイマーが起動され制御部による一連の処理が開始される。
【００５６】
続く、ステップＳ１０２では、図に示すような各バッファに対応するデータを管理するバッファ管理テーブルを参照して、その各バッファの読み出しポインタ値および格納フレーム数を取得する。
【００５７】
そして、取得されたデータを用いて、以下のステップＳ１０３〜Ｓ１０９において、合成リストの生成処理が行われる。
まず、ステップＳ１０３において、バッファの番号を示すカウンタＮが１に初期化される。このカウンタＮは、バッファの番号を示しており、そのバッファには、いずれかの地点に対応するビデオ符号化データが格納される。本フローチャートにおいては、地点番号Ｎのビデオ符号化データは、バッファＮに格納されるものとする。
【００５８】
続く、ステップＳ１０４の処理では、地点（バッファ）Ｎの格納フレーム数が０であるか否かが判定される。格納フレーム数が０でない場合は、そのバッファには、１フレーム分以上のビデオ符号化データが格納されている。この場合、バッファに格納されているビデオ符号化データが、ストリーム合成に用いられるので、ステップＳ１０６に示すように、合成リスト中の地点（バッファ）Ｎに対応する読み出しポインタとして、バッファ管理テーブル中のバッファＮに対応する読み出しポインタを指定する。また、ステップＳ１０６においては、リピートデータを使用しないことから、リピートデータ使用フラグがＯＦＦに設定される。そして、ステップＳ１０７に進む。
【００５９】
一方、地点（バッファ）Ｎの格納フレーム数が０である場合は、そのバッファには、ビデオ符号化データが格納されていない。この場合、リピートデータ部のリピートデータが、ストリーム合成に用いられるので、ステップＳ１０５に示すように、合成リスト中の地点（バッファ）Ｎに対応する読み出しポインタとして、リピートデータ部中の読み出しポインタを指定する。また、ステップＳ１０５においては、リピートデータが使用されることから、リピートデータ使用フラグがＯＮに設定される。そして、ステップＳ１０７に進む。
【００６０】
ステップＳ１０７では、カウンタ変数Ｎがインクリメントされる。そして、Ｓ１０８において、インクリメント後のＮが処理対象となるバッファの総数を示す４より大きいかが判定される。すべてのバッファにつき、ステップＳ１０４、Ｓ１０５、Ｓ１０６の処理が繰り返されることで、合成リストが生成される。
【００６１】
続く、ステップＳ１０９では、図８に示す合成リストおよび合成画面組み合わせリストに基づいてストリーム合成処理が行なわれる。その一例は、例えば、後述の図９、図１０に示される。
【００６２】
そして、ステップＳ１１０において、合成リストのリピートデータ使用フラグがＯＦＦである地点（バッファ）に関して、バッファ管理テーブル中の対応するバッファの読み出しポインタをインクリメントすると共に、格納フレーム数をデクリメントすることで、バッファ管理テーブルの情報が更新される。
【００６３】
図９は、図８のステップＳ１０９のストリーム合成処理を、ビデオ符号化データの特定の形式を例にとってより詳しく説明する図であり、図１０は、図９に対応する処理のフローチャートである。
【００６４】
なお、図９、１０では、水平画面サイズ×４８ラインを１ブロックラインとするラスタスキャンをビデオ符号化データの形式として説明するが、この他の各種符号化形式を採用可能であることはいうまでもない。
【００６５】
図９において、左下部分には、各バッファ内にある合成前のビデオ符号化データが示される。これら合成前の画面データは、それぞれが、画面サイズがＱＣＩＦ（１７６画素×１４４ライン）であり、１７６画素×４８ラインを１ブロックラインとして、３ブロックラインにより構成される。１つの画面データは、図に矢印で示されるように、第１ブロックラインの末尾が第２ブロックラインの先頭に、また、第２ブロックラインの末尾が第３ブロックラインの先頭に、それぞれつながって構成されている。
【００６６】
図９の右下部分には、左下部分のＱＣＩＦサイズの各画面を合成して得られる画面が示されている。この画面の画面サイズはＣＩＦ（３５２画素×２８８ライン）で与えられる。左下部分に示される４つのＱＣＩＦサイズの画面を、１つのＣＩＦサイズの画面として合成するには、図に示すように、３５２画素×４８ラインを１ブロックラインとして、そのブロックラインを６つ分、つなげる。
【００６７】
図１０は、ストリーム合成部が行なう合成処理のフローチャートである。制御部により起動されるストリーム合成部は、合成画面組み合わせリストと合成リストとに基づいてストリーム合成処理を実行する。
【００６８】
図１０において、まず、ステップＳ２０１において、フレームヘッダの生成・出力処理を行う。１フレーム分の画像データには、このようなフレームヘッダが一般的に設けられている。
【００６９】
そして、ステップＳ２０２において、カウンタｎを１に設定する。合成画面組み合わせリストを参照すると、合成されるＣＩＦサイズの画面の上半分のデータは、地点１のＱＣＩＦサイズの画面と、地点２のＱＣＩＦサイズの画面とが左右方向に並んで構成されることが分かる。これより、ステップＳ２０３において、地点１の第ｎブロックラインのビデオ符号化データを読み出して出力し、また、ステップＳ２０４において、地点２の第ｎブロックラインのビデオ符号化データを読み出して出力する。
【００７０】
なお、上記各ブロックラインの読み出しは、合成リストから、各バッファ内あるいはリピートデータ部内の１画面分のビデオ符号化データを読み出す領域の先頭を示す読み出しポインタを取得することにより行なわれる。
【００７１】
ステップＳ２０５では、カウンタｎをインクリメントし、ステップＳ２０６において、ｎが各ＱＣＩＦ画面中のブロックライン数を示す３より大きいかが判定される。ブロックライン数より大きくない場合、上記ステップＳ２０３およびＳ２０４が繰り返される。上記ステップＳ２０３およびＳ２０４の処理をＱＣＩＦ画面のブロックライン数分（＝３）だけ繰り返すことによって、これら地点１と地点２の各バッファあるいはリピートデータ部に含まれるビデオ符号化データをブロックラインごとに交互に合成する。
【００７２】
次に、ステップＳ２０７において、カウンタｎを再度１に設定する。合成画面組み合わせリストを参照すると、合成されるＣＩＦサイズの画面の下半分のデータは、地点３のＱＣＩＦサイズの画面と、地点４のＱＣＩＦサイズの画面とが左右方向に並んで構成されることが分かる。これより、ステップＳ２０８において、地点３の第ｎブロックラインのビデオ符号化データを読み出して出力し、また、ステップＳ２０９において、地点４の第ｎブロックラインのビデオ符号化データを読み出して出力する。
【００７３】
なお、上記各ブロックラインの読み出しは、合成リストから、各バッファ内あるいはリピートデータ部内の１画面分のビデオ符号化データを読み出す領域の先頭を示す読み出しポインタを取得することにより行なわれる。
【００７４】
ステップＳ２１０では、カウンタｎをインクリメントし、ステップＳ２１１において、ｎが各ＱＣＩＦ画面中のブロックライン数を示す３より大きいかが判定される。ブロックライン数より大きくない場合、上記ステップＳ２０８およびＳ２０９が繰り返される。上記ステップＳ２０８およびＳ２０９の処理をＱＣＩＦ画面のブロックライン数分（＝３）だけ繰り返すことによって、これら地点３と地点４の各バッファあるいはリピートデータ部に含まれるビデオ符号化データをブロックラインごとに交互に合成する。
【００７５】
なお、符号化部から出力されるビデオ符号化データは、必ずストリーム合成部を経由するので、上記１ブロックラインの読み出しが容易になるように、ビデオ符号化データをバッファ部に予め格納しておくことが最適化のためには好ましい。
【００７６】
図１１は、５地点に対応可能な第１実施形態のビデオ符号化データ合成装置の構成を示す図である。図６のビデオ符号化データ合成装置と比較すると、出力する地点が１地点から５地点に増加したために、ストリーム合成部が差の４地点分追加されている。
【００７７】
図１１では、地点１〜５のそれぞれから、ＣＩＦサイズのビデオ符号化データが送られてくる。これらのデータは、復号器１〜５に入力され、そこで、復号処理が行われる。復号処理されたデータは、画像サイズ変更処理１〜５を介することで、ＣＩＦサイズからＱＣＩＦサイズに１／４に縮小される。そして、後段のストリーム合成部１〜５では、１／４に縮小されたＱＣＩＦサイズの４画面を合成してＣＩＦサイズの１画面を得ている。合成されたＣＩＦサイズのデータは各地点に送信される。
【００７８】
従来例に示した完全合成方式において、図２２に示すように、同様の５地点分の出力を行う場合、各符号化器は、ＣＩＦサイズの画像を５地点分、符号化処理しなければならず、処理負荷が重くなる。これに対し、本実施形態では、符号化器１〜５は、ＱＣＩＦサイズの画像を５地点分、符号化処理すればよく、各符号化器の処理負荷が約１／４で済む。このように、第１実施形態では、処理負荷を減らした上で、従来の完全合成方式と同等の機能を実現できる。
【００７９】
なお、図１１は、各地点において、自らが送信した画像が合成画像としてビデオ符号化データ合成装置から戻ってこない構成になっているが、その他の構成も採用可能である。例えば、ストリーム合成部１〜５にバッファ１〜５のデータをすべて選択できるようにし、制御部の指示によって、自らが送信した画像を含むように合成画像を生成して送信してもよい。
【００８０】
以上に説明した第１実施形態においては、リピートデータ部を設けることで、ビデオ符号化データ合成装置からのデータの送信遅延を回避していた。このような構成においては、制御部は、全てのバッファにデータが１フレーム分以上、格納されているかを知る必要がないことから、例えば上記のタイマーによる起動が可能であった。
【００８１】
第１実施形態の変形例として、リピートデータ部を設けないことも可能である。この場合、全てのバッファについて１フレーム分のデータが揃う等のデータ読み出しタイミングがバッファ管理部から制御部に通知されることで、制御部が起動し、各バッファからビデオ符号化データが読み出され、それらビデオ符号化データについてストリーム合成を行う。
【００８２】
図１２は、本発明の第２実施形態のビデオ符号化データ合成装置の構成を示すブロック図である。第２実施形態の説明において、上記第１実施形態の説明との重複部分は原則として省略される。
【００８３】
図１２のビデオ符号化データ合成装置は、例えば図１のＴＶ会議端末５１、５２、５３、５４からの画像データを合成して、ＴＶ会議端末５５に送信する。
図１２において、ビデオ符号化データ合成装置７０は、復号部７１、画像サイズ変更部７２、フレームメモリ部７３、符号化部７４、バッファ部７５、ストリーム合成部７６、メモリ管理部７７、制御部７８、リピートデータ部７９、からなる。
【００８４】
復号部７１は、復号器７１1、７１2、７１3、７１4からなる。画像サイズ変更部７２は、サイズ変更処理７２1、７２2、７２3、７２4からなる。フレームメモリ部７３は、フレームメモリ７３1、７３2、７３3、７３4からなる。符号化部７４は、符号化器７４1、７４2、７４3、７４4からなる。バッファ部７５は、バッファ７５1、７５2、７５3、７５4からなる。
【００８５】
図１２において、復号部７１の各復号器７１1、７１2、７１3、７１4には、例えば図５のＴＶ会議端末１１〜１４からのビデオ符号化データが入力される。そのビデオ符号化データに対して復号処理が行われた後、必要に応じて伸長される。
【００８６】
画像サイズ変更部７２は、拡大や縮小などの画像サイズの変更処理を行なう。本実施形態においては、画像サイズ変更部７２は、受信した画像データの画像サイズを１／４に縮小する処理を行う。受信した画像サイズに対し、サイズ変更を行なわない場合は、画像サイズ変更部７２をビデオ符号化データ合成装置の構成から除くことができる。
【００８７】
すなわち、各サイズ変更処理７２1、７２2、７２3、７２4は、各復号器７１1、７１2、７１3、７１4にて復号された画像データの画像サイズをそれぞれ１／４に縮小する。例えば、ビデオ符号化データが各ＴＶ会議端末側で、ＣＩＦ（Common Intermediate Format;横３５２ピクセル、縦２８８ピクセル）サイズにて圧縮された場合、各復号器を介することによって、再びそのＣＩＦサイズに復号され、それら復号された画像データは、各サイズ変更処理を介することで、それぞれ、１／４にサイズが縮小されて、ＱＣＩＦ（横１７６ピクセル、縦１４４ピクセル）サイズとなる。
【００８８】
その後、この１／４にサイズが縮小された各画像データは、フレームメモリ部７３に一旦、入力され、所定のタイミングによって次段の符号化部７４に出力される。符号化部７４では、フレームメモリ部７３からの画像データを必要に応じて圧縮した後に、都合よく、例えば、後段のストリーム合成部７６にてビデオ符号化データのまま合成可能なように符号化処理が行われる。
【００８９】
ここで、本第２実施形態においては、符号化処理を行う符号化部７４の直前にフレームメモリ部７３を設け、そのフレームメモリ部７３に画像データを一旦、格納するようにしている。よって、符号化処理を同期させることができる。このため、符号化処理が非同期であるために、処理対象とする画像種別を１種類（ＩピクチャまたはＰピクチャ）に決めなければならなかった第１実施形態とは異なり、第２実施形態においては、画像種別を混在させることができる。例えば、ＩピクチャとＰピクチャとを混在して用いることができる。
【００９０】
制御部７８は、圧縮処理からストリーム合成までの一連の処理の制御を行う。この制御部７８は、不図示のタイマーによって一定間隔ごとに起動される。例えば、１５フレーム／秒のビデオ符号化データを生成する場合は、一定間隔を示す周期は１５Ｈｚとなる。
【００９１】
メモリ管理部７７は、フレームメモリ７３1、７３2、７３3、７３4内のそれぞれの画像データの格納状況を示すフレームメモリ管理テーブルを管理する。このフレームメモリ管理テーブルは、例えば、前段のサイズ変更処理７２1、７２2、７２3、７２4からの画像データの入力や、制御部７８からの読み出し指示に対応して、書き換えられる。
【００９２】
各フレームメモリ７３1、７３2、７３3、７３4に格納された画像データは、上記制御部７８からの指示によって、次段の符号化器７４1、７４2、７４3、７４4にそれぞれ入力され、そこで、後段においてストリーム合成が行いやすいような符号化処理、例えば、ＭＰＥＧ４方式では、画面の外をベクトルが指さないようにする等、が行われる。
【００９３】
バッファ７５1、７５2、７５3、７５4には、それぞれ、符号化器７４1、７４2、７４3、７４4を介して符号化されたビデオ符号化データが格納される。上記したように、本実施形態においては、符号化処理が同期している関係から、これらバッファ７５1、７５2、７５3、７５4は、ビデオ符号化データを少なくとも１フレーム分だけ保持するバッファとして用いられる。
【００９４】
このように、本第２実施形態のバッファ部は、上記第１実施形態のように、複数フレーム分を格納することがないので、バッファ管理は行なわない。
なお、上記したように、符号化処理が同期している関係から、本第２実施形態においては、処理対象となる画像データにはＩピクチャとＰピクチャが混在することとなる。
【００９５】
リピートデータ部７９は、前回のデータからの誤差がゼロであることを示すリピートデータを保持している。このリピートデータは、処理対象となる画像データがＰピクチャの場合に用いることが可能である。
【００９６】
すなわち、制御部７８からの読み出し指示に対応して、フレームメモリ部７３内の各画像データを取得するに際して、フレームメモリ部７３内の少なくとも１つのフレームメモリにおいて、画像データが存在しない場合、制御部７８は、その画像データが存在しないフレームメモリに対しては、対応する符号化器は処理を実行させることができず、対応するバッファにはビデオ符号化データは存在しないため、そのビデオ符号化データが存在しないバッファ用のデータとして、リピートデータ部７９のリピートデータを用いる。
【００９７】
図１３は、フレームメモリ部７３内のあるフレームメモリに対応するフレームメモリ管理テーブルの時系列的な更新の状況、すなわち、動作遷移の一例を示す図である。図１３は、図７のバッファ管理テーブルの動作遷移例と同様のデータを用いており、バッファとメモリとの違いを別にすれば、その動作内容もほぼ同じである。以下では、原則として相違点につき説明する。
【００９８】
図１３では、このフレームメモリに対応するフレームメモリ管理テーブルは、最大格納フレーム数が３であるリングメモリとして構成される。よって、データの書き込み領域の先頭を示す書き込みポインタや、データの読み出し領域の先頭を示す読み出しポインタは、「０」「１」「２」のいずれかの値をとる。
【００９９】
図１３の遷移Ｎｏ．１１では、格納フレーム数「０」の状態において、制御部からの読み出し指示が行なわれている。このような格納フレーム数が「０」の場合に行われる読み出し指示に対しては、処理対象の画像データがＰピクチャである場合には、その格納フレーム数が「０」であり、したがって、フレームメモリ内に画像データが存在せず、対応する符号化器は処理を実行させることができず、対応するバッファにはビデオ符号化データは存在しないため、そのビデオ符号化データが存在しないバッファ用のデータとして、リピートデータ部のリピートデータが用いられる。一方、格納フレーム数が「０」の場合に行われる読み出し指示に対して、処理対象の画像データがＩピクチャである場合には、読み出しポインタをデクリメントすることで、このフレームメモリで直前に符号化処理をした画像データを後段の符号器に再度読み出す。
【０１００】
図１４および図１５は、上記の制御部が行なう処理を示すフローチャートである。この制御部は、一定間隔のタイマーによって起動され、その都度、下記フローチャートに示す処理を行う。なお、図１４は前半部分のフローチャートであり、図１５は、後半部分のフローチャートである。
【０１０１】
図１４において、ステップＳ３０１において、タイマーが起動され制御部による一連の処理が開始される。
続く、ステップＳ３０２では、図に示す各地点に対応するフレームメモリ管理テーブルを参照して、その各地点の読み出しポインタ値および格納フレーム数を取得する。
【０１０２】
本第２実施形態においては、ＩピクチャとＰピクチャとが処理対象のデータとして混在する場合を扱う。各フレームメモリに格納された画像データは既に復号済みであるので、符号化時にＩピクチャとして符号化することも、また、Ｐピクチャとして符号化することもできる。本実施形態では、Ｉピクチャと次のＩピクチャとの間に、Ｐピクチャを何フレーム挿入するかを指定している。以下の表１で定義される変数ｉｎｔｅｒｖａｌは、フレーム内符号化のみで符号化するIピクチャを何回に１回行なうのかを定める閾値（Ｉピクチャ間に挿入するＰピクチャのフレーム数を定める閾値）である。
【０１０３】
【表１】
2005244898.tif 000003
本フローにおいては、この変数ｉｎｔｅｒｖａｌと、カウンタ変数ｆｒａｍｅとを用いる、ステップＳ３０３、Ｓ３０４、Ｓ３０５に示す判定アルゴリズムによって、Ｉピクチャ間に挿入するＰピクチャのフレーム数を決めている。
【０１０４】
すなわち、カウンタ変数ｆｒａｍｅは、符号無し８ビットの変数であり、初期値が“０”に設定される。よって、このｆｒａｍｅは０〜２５５の範囲の値をとり得る。なお、ｆｒａｍｅ＝２５５からインクリメントすると、ｆｒａｍｅ＝０となるものとする。また、カウンタ変数ｆｒａｍｅは、タイマーによる制御部の周期的な起動の前後でも、その値を保持するスタティックな変数（グローバルな変数）である。
【０１０５】
以下では例えば、変数ｉｎｔｅｒｖａｌ＝１４の場合を例に説明する。まず、最初に起動される制御部の処理において取得されるフレームでは、カウンタ変数ｆｒａｍｅは“０”である。よって、ステップＳ３０３の判定において、条件：ｆｒａｍｅ＜ｉｎｔｅｒｖａｌを満たすことから、ステップＳ３０５に進む、カウンタ変数ｆｒａｍｅは、そのステップで、“０”から“１”にインクリメントされる。このステップＳ３０５では、符号化をＩピクチャで行なうかＰピクチャで行なうかを示す変数ｐｔｙｐｅをＰピクチャに設定している。これにより、対応する画像データはＰピクチャとして符号化される。
【０１０６】
このような処理は、制御部が起動されるごとに行なわれ、カウンタ変数ｆｒａｍｅはその都度インクリメントされる。Ｐピクチャとして符号化される画像データが１４回連続して挿入された後には、カウンタ変数ｆｒａｍｅ＝１４となり、ステップＳ３０３の判定において、条件：ｆｒａｍｅ＜ｉｎｔｅｒｖａｌが満たされず、ステップＳ３０４に進む。そして、そのステップで、上記変数ｐｔｙｐｅをＩピクチャに設定すると共に、カウンタ変数ｆｒａｍｅを“０”に初期化する。つまり、カウンタ変数ｆｒａｍｅに設定される値が変数ｉｎｔｅｒｖａｌに定められた閾値に一致するたびに符号化データがＩピクチャとなる符号化が行なわれるように、符号化の形式を定める変数ｐｔｙｐｅをＩピクチャに設定する。
【０１０７】
制御部が起動されるごとに上記のステップＳ３０３、Ｓ３０４、Ｓ３０５の処理が繰り返されることによって、変数ｉｎｔｅｒｖａｌ＝１４においては、Ｉピクチャ間に１４個のＰピクチャを挿入するような符号化が周期的に行なわれる。変数ｉｎｔｅｒｖａｌの値を１４以外に設定することも当然可能であり、その場合の処理も同様に考えられる。
【０１０８】
上記ステップＳ３０３〜Ｓ３０５の判定フローによって、Ｉピクチャ、Ｐピクチャのいずれとして符号化するかを決定した後は、後続のステップＳ３０６〜Ｓ３１１において、符号化処理リスト生成処理が行われる。
【０１０９】
このリスト生成処理において、まず、ステップＳ３０６でカウンタＮが１に初期化される。このカウンタＮは、フレームメモリの番号、または、そのフレームメモリに対応する少なくとも１フレーム分のバッファの番号を示しており、そのフレームメモリまたは少なくとも１フレーム分のバッファには、いずれかの地点に対応する画像データおよびビデオ符号化データが格納される。本フローチャートにおいては、地点番号Ｎの画像データおよびビデオ符号化データは、各々フレームメモリＮ、バッファＮに格納されるものとする。
【０１１０】
ステップＳ３０７において、地点（フレームメモリ）Ｎの格納フレーム数がゼロ（０）であるかが判定される。ステップＳ３０７で、地点Ｎの格納フレーム数が０と判定された場合は、ステップＳ３０８に進み、そのステップにおいて、リピートデータ使用フラグをＯＮに設定すると共に、フレームメモリ管理テーブルから取得したフレームメモリＮの読み出しポインタをデクリメントした値を、符号化処理リスト中のフレームメモリＮに対応する読み出しポインタとして格納する。これにより、フレームメモリＮ内に残っている符号化処理済みの画像データ中で最も時間的に新しい画像データを再使用することが可能となる。なお、上記リピートデータ使用フラグは、Ｐピクチャによって符号化が行なわれる場合に、リピートデータ部のリピートデータが用いられることを示すフラグである。
【０１１１】
ステップＳ３０７で、地点（フレームメモリ）Ｎの格納フレーム数が０でないと判定された場合には、ステップＳ３０９に進み、そのステップにおいて、上記リピートデータ使用フラグをＯＦＦに設定すると共に、フレームメモリ管理テーブルから取得したフレームメモリＮの読み出しポインタを、符号化処理リスト中の地点（フレームメモリ）Ｎに対応する読み出しポインタとしてそのまま格納する。
【０１１２】
ステップＳ３１０で、この場合はフレームメモリの番号を示すカウンタＮがインクリメントされ、ステップＳ３１１において、カウンタＮが、処理対象となるフレームメモリ数（この場合、４）より大きいかが判定される。カウンタＮが処理対象となるフレームメモリ数を超えない場合は、処理対象となる全てのフレームメモリについてリスト生成処理が完了していないので、ステップＳ３０７の処理に戻り、次のフレームメモリについて、同様の判定処理を行う。
【０１１３】
これら一連のリスト生成処理の結果として、図に示すように、フレームメモリの番号と、その番号に対応する読み出しポインタとからなる符号化処理リストが生成される。
続いて、図１５に移り、ステップＳ３１２〜Ｓ３２０において、符号化処理および合成リスト生成処理が行なわれる。
【０１１４】
まず、ステップＳ３１２において、フレームメモリまたはバッファの番号を示すカウンタＮに１を設定する。そして、ステップＳ３１３において、ステップＳ３０４およびＳ３０５において設定された、上記変数ｐｔｙｐｅを参照して、その変数ｐｔｙｐｅの値がＩピクチャに一致するか判定している。
【０１１５】
ステップＳ３１３において、変数ｐｔｙｐｅがＩピクチャに一致する場合は、ステップＳ３１６に進み、そこで、符号化処理リストの地点（フレームメモリ）Ｎに対応する読み出しポインタを、今回符号化される画像データが格納される領域の先頭を指すポインタとして指定する。そして、指定された読み出しポインタと、変数ｐｔｙｐｅに指定される形式、この場合はＩピクチャに基づいて地点Ｎに対する符号化処理が行なわれる。
【０１１６】
ステップＳ３１３において、変数ｐｔｙｐｅがＩピクチャに一致しない場合は、ステップＳ３１４に進み、そこで、リピートデータ使用フラグの値を判定する。ステップＳ３１４で、リピートデータ使用フラグがＯＦＦである場合は、ステップＳ３１５に進み、そこで、符号化処理リストの地点（フレームメモリ）Ｎに対応する読み出しポインタを、今回符号化される画像データが格納される領域の先頭を指すポインタとして指定する。そして、指定された読み出しポインタと、変数ｐｔｙｐｅに指定される形式、この場合はＰピクチャに基づいて地点Ｎに対する符号化処理が行なわれる。
【０１１７】
符号化部の各符号化器において、ステップＳ３１５またはＳ３１６の符号化が施されたデータは、後段のバッファ部内の対応する各バッファに格納される。例えば、符号化器Ｎにおいて符号化されたビデオ符号化データは、バッファＮに格納される。
【０１１８】
ステップＳ３１７では、ストリーム合成の際に参照される合成リストの一部が作成される。すなわち、符号化器Ｎにおいて符号化され、バッファＮに格納されたビデオ符号化データの読み出しポインタを、合成リスト中の地点（バッファ）Ｎに対応する読み出しポインタとして格納する。
【０１１９】
一方、ステップＳ３１４で、リピートデータ使用フラグがＯＮである場合は、処理対象のフレームメモリＮに対してリピートデータを使用することになるので、後段の対応する符号化器を起動させることなく、ステップＳ３１８に進む。ステップＳ３１８においては、リピートデータの読み出しポインタを、上記合成リスト中の地点（バッファ）Ｎに対応する読み出しポインタとして格納する。
【０１２０】
ステップＳ３１７およびＳ３１８に続くステップＳ３１９では、カウンタＮがインクリメントされ、ステップＳ３２０では、インクリメントされたカウンタＮが処理対象となる地点の数（この場合、４で与えられる）を超えたかが判定される。カウンタＮが処理対象となる地点の数を超えない場合は、処理対象となる全ての地点（フレームメモリ、バッファ）について合成リスト生成処理が完了していないので、ステップＳ３１３の処理に戻り、次の地点（フレームメモリ、バッファ）について、同様の判定処理を行う。
【０１２１】
合成リスト生成処理の結果として、例えば図１５に示すような合成リスト（Ｐピクチャの場合、Ｉピクチャの場合）が作成される。
上述した記載との関連では、フレームメモリ３に対して、格納フレーム数が０の状態で読み出し指示が行なわれている。よって、合成リスト（Ｐピクチャの場合）中のバッファ３に対応する読み出しポインタとしては、リピートデータの読み出しポインタが格納されている。
【０１２２】
続く、ステップＳ３２１では、図１５に示す合成リストおよび合成画面組み合わせリストとに基づいてストリーム合成処理が行なわれる。その一例については、例えば、前述の図９、図１０に示した通りである。
【０１２３】
そして、ステップＳ３２２において、符号化処理リストのリピートデータ使用フラグがＯＦＦである地点（バッファ）に関して、フレームメモリ管理テーブル中の対応するフレームメモリの読み出しポインタをインクリメントすると共に、格納フレーム数をデクリメントすることで、フレームメモリ管理テーブルの情報が更新される。
【０１２４】
図１６は、５地点に対応可能な第２実施形態のビデオ符号化データ合成装置の構成を示す図である。図１２のビデオ符号化データ合成装置と比較すると、出力する地点が１地点から５地点に増加したために、ストリーム合成部が差の４地点分追加されている。
【０１２５】
図１６は、地点１〜５のそれぞれから、ＣＩＦサイズのビデオ符号化データが送られてくる。これらのデータは、復号器１〜５に入力され、そこで、復号処理が行われる。復号処理されたデータは、画像サイズ変更処理１〜５を介することで、ＣＩＦサイズからＱＣＩＦサイズに１／４に縮小される。そして、後段のストリーム合成部１〜５では、１／４に縮小されたＱＣＩＦサイズの４画面を合成してＣＩＦサイズの１画面を得ている。合成されたＣＩＦサイズのデータは各地点に送信される。
【０１２６】
従来例に示した完全合成方式において、図２２に示すように、同様の５地点分の出力を行う場合、各符号化器は、ＣＩＦサイズの画像を５地点分、符号化処理しなければならず、処理負荷が重くなる。これに対し、本実施形態では、符号化器１〜５は、ＱＣＩＦサイズの画像を５地点分、符号化処理すればよく、各符号化器の処理負荷が約１／４で済む。このように、第２実施形態では、処理負荷を減らした上で、従来の完全合成方式と同等の機能を実現できる。
【０１２７】
なお、図１６は、各地点において、自らが送信した画像が合成画像としてビデオ符号化データ合成装置から戻ってこない構成になっているが、その他の構成も採用可能である。例えば、ストリーム合成部１〜５にバッファ１〜５のデータをすべて選択できるようにし、制御部の指示によって、自らが送信した画像を含むように合成画像を生成して送信してもよい。
【０１２８】
以上に説明した第２実施形態においては、リピートデータ部を設けることで、ビデオ符号化データ合成装置からのデータの送信遅延を回避していた。このような構成においては、制御部は、全てのフレームメモリにデータが１フレーム分以上、格納されているかを知る必要がないことから、例えば上記のタイマーによる起動が可能であった。
【０１２９】
第２実施形態の変形例として、リピートデータ部を設けないことも可能である。この場合、全てのフレームメモリについて１フレーム分のデータが揃う等のデータ読み出しタイミングがメモリ管理部から制御部に通知されることで制御部が起動して、各フレームメモリから画像データが読み出され、それら画像データについて符号化部によって符号化が行われた後に、バッファ部を介してストリーム合成を行う。
【０１３０】
本発明は、下記構成でもよい。
（付記１）  ビデオ符号化データを入力して復号する２以上のＮ個の復号器からなる復号部と、
前記復号部からの画像データを符号化するＮ個の符号化器からなる符号化部と、
前記符号化されたビデオ符号化データをフレーム単位で所定フレーム数分、記憶可能なＮ個のバッファからなるバッファ部と、
前記バッファ部におけるビデオ符号化データの格納状況を示すバッファ管理テーブルを管理するバッファ管理部と、
前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部と、
前記バッファ管理テーブルに基づいて、１フレーム分の合成処理を実行するように、前記ストリーム合成部に指示を出す制御部と、
を備えることを特徴とするビデオ符号化データ合成装置。
【０１３１】
（付記２）  前回のデータからの誤差がゼロであることを示すリピートデータを保持するリピートデータ部をさらに有し、
前記バッファ部内の少なくとも１つのバッファにおいて、ビデオ符号化データが存在しない場合、前記制御部は、そのビデオ符号化データが存在しないバッファ用のビデオ符号化データとして、前記リピートデータ部のリピートデータを用いることを特徴とする付記１記載のビデオ符号化データ合成装置。
【０１３２】
（付記３）  前記復号部からの復号されたＮ個の画像データに対して画像サイズを変更する処理を行なう画像サイズ変更処理部をさらに備え、
前記符号化部は、該サイズ変更されたＮ個の画像データを符号化することを特徴とする付記１記載のビデオ符号化データ合成装置。
【０１３３】
（付記４）  ビデオ符号化データを入力して復号する２以上のＮ個の復号器からなる復号部と、
前記復号部からの画像データを所定フレーム数分、記憶可能なＮ個のフレームメモリからなるフレームメモリ部と、
前記フレームメモリ部における画像データの格納状況を示すフレームメモリ管理テーブルを管理するメモリ管理部と、
前記フレームメモリ部からの画像データを符号化するＮ個の符号化器からなる符号化部と、
前記符号化されたビデオ符号化データをフレーム単位で少なくとも１フレーム分、記憶可能なＮ個のバッファからなるバッファ部と、
前記各バッファからの１フレーム分のビデオ符号化データに対して合成処理を行うストリーム合成部と、
前記フレームメモリ管理テーブルに基づいて、前記符号化部、バッファ部を制御すると共に、前記１フレーム分の合成処理を実行するように、前記ストリーム合成部に指示を出す制御部と、
を備えることを特徴とするビデオ符号化データ合成装置。
【０１３４】
（付記５）  前記制御部は、フレーム内符号化のみで１フレーム分の符号化を行うか、フレーム内符号化に加え参照フレームからの差分データも利用して１フレーム分の符号化を行うかを決定する符号化形式決定部を有すると共に、決定された符号化の形式に基づいて、前記フレームメモリ部からの各画像データを符号化するように前記各符号化器に指示を出すことを特徴とする付記４記載のビデオ符号化データ合成装置。
【０１３５】
（付記６）  前記制御部は所定の時間間隔ごとに起動されると共に、
前記制御部の起動のたびにインクリメントされるカウンタ変数の値を保持する起動回数記憶部を備え、
前記符号化形式決定部は、フレーム内符号化のみで行う符号化を何回に１回行なうのかを定める閾値と前記カウンタ値との比較結果に基づいて、各符号化器による符号化をフレーム内符号化のみで行うかフレーム内符号化に加えて参照フレームからの差分データも利用して行うかを決定することを特徴とする付記５記載のビデオ符号化データ合成装置。
【０１３６】
（付記７）  前回のデータからの誤差がゼロであることを示すリピートデータを保持するリピートデータ部をさらに有し、
前記フレーム内符号化に加えて差分データも利用して１フレーム分の符号化を行う場合に、前記フレームメモリ部内の少なくとも１つのフレームメモリにおいて、格納されている画像データが存在しない場合、前記制御部は、その画像データが存在しないフレームメモリに対しては、対応する符号化器は処理を実行させることができず、対応するバッファにはビデオ符号化データは存在しないため、そのビデオ符号化データが存在しないバッファ用のデータとして、前記リピートデータ部のデータを用いることを特徴とする付記５記載のビデオ符号化データ合成装置。
【０１３７】
（付記８）  前記復号部からの復号されたＮ個の画像データに対して画像サイズを変更する処理を行なう画像サイズ変更処理部をさらに備え、
前記フレームメモリ部は、該サイズ変更されたＮ個の画像データを格納することを特徴とする付記４記載のビデオ符号化データ合成装置。
【０１３８】
（付記９）  前記制御部は、タイマーによって周期的に起動されることを特徴とする付記２、または、５記載のビデオ符号化データ合成装置。
（付記１０）  前記画像サイズ変更処理部は、画像サイズを縮小する処理を行うことを特徴とする付記３、または、８記載のビデオ符号化データ合成装置。
【産業上の利用可能性】
【０１３９】
本発明は、複数のＴＶ会議端末からビデオ符号化データを入力して、それらの入力データに基づいて、送信用のビデオ符号化データを合成するビデオ符号化合成装置に適用可能である。
【図面の簡単な説明】
【０１４０】
【図１】本発明の第１態様のビデオ符号化データ合成装置の構成を示すブロック図である。
【図２】本発明の第２態様のビデオ符号化データ合成装置の構成を示すブロック図である。
【図３】本発明の第３態様のビデオ符号化データ合成装置の構成を示すブロック図である。
【図４】本発明の第４態様のビデオ符号化データ合成装置の構成を示すブロック図である。
【図５】本発明の各実施形態に共通するＴＶ会議システムの構成図である。
【図６】本発明の第１実施形態のビデオ符号化データ合成装置の構成を示すブロック図である。
【図７】バッファ部内のあるバッファに対応するバッファ管理テーブルの動作遷移例を示す図である。
【図８】制御部が行なう処理を示すフローチャートである。
【図９】図８のステップＳ１０９のストリーム合成処理を、特定の形式を例にとってより詳しく説明する図である。
【図１０】図９に対応する処理のフローチャートである。
【図１１】５地点に対応可能な第１実施形態のビデオ符号化データ合成装置の構成を示す図である。
【図１２】本発明の第２実施形態のビデオ符号化データ合成装置の構成を示すブロック図である。
【図１３】フレームメモリ部内のあるフレームメモリに対応するフレームメモリ管理テーブルの動作遷移例を示す図である。
【図１４】制御部が行なう処理を示すフローチャート（前半）である。
【図１５】制御部が行なう処理を示すフローチャート（後半）である。
【図１６】５地点に対応可能な第２実施形態のビデオ符号化データ合成装置の構成を示す図である。
【図１７】ストリーム多重化方式に基づいて画像合成処理を行うＭＣＵの構成を示す図である。
【図１８】５地点に対応可能なストリーム多重化方式のＭＣＵの構成を示す図である。
【図１９】ストリーム合成方式に基づいて画像合成処理を行うＭＣＵの構成を示す図である。
【図２０】５地点に対応可能なストリーム合成方式のＭＣＵの構成を示す図である。
【図２１】完全合成方式に基づいて画像合成処理を行うＭＣＵの構成を示す図である。
【図２２】５地点に対応可能な完全合成方式のＭＣＵの構成を示す図である。
【符号の説明】
【０１４１】
１０，２０，３０，４０，５６，６０，７０  ビデオ符号化データ合成装置
１１，２１，３１，４１，６１，７１  復号部
１２，２２，３３，４３，６３，７４  符号化部
１３，２３，３４，４４，６４，７５  バッファ部
１４，２４，３５，４５，６５，７６  ストリーム合成部
１５，２５，６６  バッファ管理部
３６，４６，７７  メモリ管理部
１６，２６，３７，４７，６７，７８  制御部
２７，４８，６８，７９  リピートデータ部
６２，７２  画像サイズ変更部
【図１】
2005244898.tif 000004
【図２】
2005244898.tif 000005
【図３】
2005244898.tif 000006
【図４】
2005244898.tif 000007
【図５】
2005244898.tif 000008
【図６】
2005244898.tif 000009
【図７】
2005244898.tif 000010
【図８】
2005244898.tif 000011
【図９】
2005244898.tif 000012
【図１０】
2005244898.tif 000013
【図１１】
2005244898.tif 000014
【図１２】
2005244898.tif 000015
【図１３】
2005244898.tif 000016
【図１４】
2005244898.tif 000017
【図１５】
2005244898.tif 000018
【図１６】
2005244898.tif 000019
【図１７】
2005244898.tif 000020
【図１８】
2005244898.tif 000021
【図１９】
2005244898.tif 000022
【図２０】
2005244898.tif 000023
【図２１】
2005244898.tif 000024
【図２２】
2005244898.tif 000025