JP3799070B2 - 送信装置及び方法 - Google Patents
送信装置及び方法 Download PDFInfo
- Publication number
- JP3799070B2 JP3799070B2 JP31558393A JP31558393A JP3799070B2 JP 3799070 B2 JP3799070 B2 JP 3799070B2 JP 31558393 A JP31558393 A JP 31558393A JP 31558393 A JP31558393 A JP 31558393A JP 3799070 B2 JP3799070 B2 JP 3799070B2
- Authority
- JP
- Japan
- Prior art keywords
- buffer memory
- time
- data
- signal
- internal capacity
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Communication Control (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、例えば、コンピュータネットワークのような通信の技術分野で用いられる送信装置及び方法に関し、特に、オーディオやビデオデータのようなマルチメディアデータに対応できる送信装置及び方法に関するものである。
【０００２】
【従来の技術】
近年、パーソナルコンピュータやワークステーションなどの性能は格段に向上し、また、身近に普及しつつある。また、最近は、それらをテレビジョンや電話と同じように日常的なコミュニケーションに利用したいという要求や、これら情報処理システムをより広範囲の用途に活用したいという要求が出てきている。したがって、上記パーソナルコンピュータやワークステーションなどにおいては、これらの要求を実現するために、音声や動画などのマルチメディアデータを分散環境上でインタラクティブに扱えるようにする事が必要となっている。
【０００３】
ここで、従来のマルチメディアの通信で用いられる情報処理通信システムとしては、図１１に示す構成のものが知られている。
【０００４】
この図１１において、入力装置１００や１０１からは例えば音声データ、動画データ等が供給される。この入力装置１００，１０１としては、例えばマイクロホンからのアナログの音声信号やビデオカメラからのアナログの映像信号をディジタル信号に変換するＡ／Ｄコンバータを挙げることができる。この入力装置１００，１０１からのデータは、それぞれ入力データ処理装置１０２，１０３に送られ、それぞれ所定のデータ処理が施される。この入力データ処理装置１０２，１０３でのデータ処理としては、例えばデータ圧縮処理を挙げることができる。上記入力データ処理装置１０２，１０３からの圧縮データは、マルチプレクサ１０４によってマルチプレクス処理され、送信バッファメモリ１０５に蓄えられた後に読み出されて、ネットワーク送信部１０６から例えばイーサーネットなどのネットワークを介して受信側のネットワーク受信部１１１に送られる。
【０００５】
上記ネットワーク受信部１１１で受信されたデータは、受信バッファメモリ１１２に一旦蓄えられた後に読み出され、さらに分離装置１１３によって上記送信側のマルチプレクス処理に対応する分離処理がなされて、出力データ処理装置１１４，１１５に送られる。当該出力データ処理装置１１４，１１５は上記入力データ処理装置１０２，１０３に対応するデータ伸張処理を施し、その後再生装置１１６，１１７に送る。なお、当該再生装置１１６，１１７としては、Ｄ／Ａコンバータを例に挙げることができる。
【０００６】
【発明が解決しようとする課題】
ところで、上述した従来の情報処理通信システムにおいては、以下のような問題点がある。
【０００７】
先ず、上記従来の情報処理通信システムにおいては、例えば通信路などの負荷の変動によって処理が遅れ、送信バッファメモリ１０５において内容が増えすぎるようになる場合がある。このように、送信バッファメモリ１０５の内容が増えすぎるようになると、当該送信バッファメモリ１０５におけるデータの入力から出力までの時間遅れが大きくなる。
【０００８】
また、図１１の例では、送信バッファメモリは単数となっているが、送信バッファメモリが複数ある様な場合において、例えばこの複数の送信バッファメモリの間で内容量の差が大きくなりすぎるようになると、これら複数の送信バッファメモリは本来同期していなければならないものであるにもかかわらず、出力の際のバッファメモリ間の時間のずれ（すなわちメディア間の時間のずれ）が大きくなる。
【０００９】
この従来の欠点についてより具体的に説明する。例えば、動画や音声などのマルチメディアデータは、コンピュータがこれまで処理してきた数値データやテキストデータとは本質的に異なる性質を持っている。すなわち、マルチメディアデータは、
第一に、マルチメディアデータは単なるバイト列ではなく、明示的あるいは暗示的に時間の属性を持っていること、
第二に、本質的にデータ量が莫大かつ冗長で、ハードウェアの処理能力が向上したとしても、効率良く扱うためにはデータ圧縮をする必要があること、
第三に、インタラクティブな処理を必要とされ、スループットだけでなくレスポンスや遅れなどの性能が重視されること、
などの性質を持っている。
【００１０】
このため、これらを分散環境で扱うためには、メディア間同期、通信、処理、リーソス管理などに新たな手法を導入する必要がある。
【００１１】
そこで、本発明は、上述のような実情に鑑みてなされたものであり、特に上記メディア間同期をとるために、動画像信号についての外部から送信装置への取り込み時間と送信装置から外部へ送信する時間との差を所定時間以内に制御可能とする送信装置及び送信方法を提供することを目的とするものである。
【００１２】
【課題を解決するための手段】
本発明の送信装置は、上述した目的を達成するために提案されたものであり、信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号をパケット化して送信する実時間の送信装置であって、動画信号を外部から取り込む取り込み手段と、上記取り込み手段により取り込まれた動画信号を圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段からの出力信号をバッファリングするバッファ手段と、上記バッファ手段のバッファメモリ内容量Ｄを測定する内容量測定手段と、上記バッファ手段によりバッファリングされた動画信号を送信する送信手段と、上記動画信号の上記取り込み手段による取り込み時間と上記送信手段により送信する時間との差が上記内容量測定手段により測定されたバッファメモリ内容量Ｄに予め対応付けられ、上記時間の差の上限としての第１の時間がバッファメモリ内容量の上限値Ｄmaxに、上記時間の差の下限としての第２の時間がバッファメモリ内容量の下限値Ｄminにそれぞれ予め対応付けられ、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmax内であることを検出する第１の検出手段、及び上記バッファメモリ内容量Ｄが上記下限値Ｄmin内であることを検出する第２の検出手段と、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、上記バッファメモリ内容量を上記上限値と上記下限値との間となすために、上記取り込み手段から出力する単位時間内のコマ数を制御する制御手段とを有することを特徴とするものである。
また、本発明の送信方法は、信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号をパケット化して送信する実時間の送信方法であって、動画信号を外部から取り込む取り込み工程と、上記取り込み工程により取り込まれた動画信号を圧縮符号化する圧縮符号化工程と、上記圧縮符号化工程により圧縮符号化された出力信号をバッファ手段にバッファリングする工程と、上記バッファ手段のバッファメモリ内容量Ｄを測定する内容量測定工程と、上記バッファ手段によりバッファリングされた動画信号を送信する送信工程と、上記動画信号の上記取り込み手段による取り込み時間と上記送信手段により送信する時間との差が上記内容量測定手段により測定されたバッファメモリ内容量Ｄに予め対応付けられ、上記時間の差の上限としての第１の時間がバッファメモリ内容量の上限値Ｄmaxに、上記時間の差の下限としての第２の時間がバッファメモリ内容量の下限値Ｄminにそれぞれ予め対応付けられ、上記内容量測定工程により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmax内であることを検出する第１の検出工程、及び上記バッファメモリ内容量Ｄが上記下限値Ｄmin内であることを検出する第２の検出工程と、上記内容量測定工程により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、上記バッファメモリ内容量を上記上限値と上記下限値との間となすために、上記取り込み工程から上記圧縮符号化工程に出力する単位時間内のコマ数を制御する制御工程とを有することを特徴とするものである。
【００１３】
また、本発明の送信装置は、送信信号が動画信号を除く信号であることを検出する第３の検出手段をも設け、動画信号を除く信号をも送信すると共に、上記第３の検出手段によって送信信号が動画信号を除く信号であることを検出したときには、当該動画信号を除く信号に対してはそのまま処理する。
【００１４】
さらに、本発明の送信装置は、送信信号の所定の部分を検出する第４の検出手段をも設け、当該第４の検出手段によって上記所定の部分を検出したときには、当該所定の部分についてはそのまま処理し、他の部分については送信を中止するようにしている。
【００１５】
【作用】
本発明によれば、制御手段は、信号の取り込み時間と送信する時間との差が上限である第１の時間内を越えたことを検出したときに、信号の取り込み時間と送信する時間との差を第１の時間と第２の時間との間と成すために、画質又は単位時間内の送信コマ数を制御する。
【００１６】
すなわち、本発明の送信装置によれば、送信時に信号の取り込み時間と送信する時間との差が第１の時間を越えると、バッファ手段での入力から出力までの時間遅れが大きくなるので、送信時に信号の取り込み時間と送信する時間との差が第１の時間を越えるようになったときには、送信する動画の画質を落とすか又はコマ落としを行うことで、バッファ手段の入力から出力までの時間遅れを適正値に回復させるようにしている。
【００１７】
さらに、本発明の送信装置によれば、送信時に信号の信号の取り込み時間と送信する時間との差が下限である第２の時間内を下回ると、映像が途切れるおそれが出てくるので、送信時の信号の取り込み時間と送信する時間との差が第２の時間内を下回るようになったときには、送信する動画の画質を上げるか又はコマ落とし数を無くす（若しくは少なくする）ことで、映像の途切れを防ぐようにしている。
【００１８】
また、本発明の送信装置によれば、さらに第３の検出手段を設け、この第３の検出手段によって送信信号が動画の信号を除く信号であることを検出したときには、そのまま処理することで、送信信号が例えばテキストデータなどである場合に、データの内容が変化することを防いでいる。
【００１９】
さらに、本発明の送信装置によれば、さらに第４の検出手段を設け、この第４の検出手段によって送信信号の所定の部分を検出したときには、その所定の部分を除く他の部分の送信を中止することで、バッファ手段の入力から出力までの時間遅れを適正値に回復させるようにし、その所定の部分についてはそのまま処理することで、この所定の部分の信号については送信するようにする。
【００２０】
【実施例】
以下、図面を参照し、本発明の実施例について詳述する。
【００２１】
図１には、本発明に係る送信装置及び方法の実施例となる送信装置の構成を示す。
本実施例の送信装置は、図１に示すように、少なくとも動画の信号を、取り込む取り込み時間と送信す時間との差が所定時間以内であるように送信する実時間の送信装置であり、動画信号を取り込む取り込み手段としてのＡ／Ｄ変換回路６６及びフレームバッファ６８と、動画データをバッファリングするバッファ手段としての映像データバッファメモリ８３と、動画データを送信する送信手段であるネットワーク送信部７とを有してなる。
【００２２】
さらに、本実施例の送信装置には、動画データについての取り込み時間と送信する時間との差（後述する測定値Ｄ）が上限（後述する上限値Ｄｍａｘ）の第１の時間内であることを検出する第１の検出手段、及び動画データについての取り込み時間と送信する時間との差が下限（後述する下限値Ｄｍｉｎ）の第２の時間内であることを検出する第２の検出手段としてのバッファメモリ内容量測定回路８６と、上記バッファメモリ内容量測定回路８６によって上記取り込み時間と送信時間との差（測定値Ｄ）が上記第１の時間内（上限値Ｄｍａｘ）を越えたことを検出したときに、上記取り込み時間と送信する時間との差を上記第１の時間内（上限値Ｄｍａｘ内）と第２の時間内（下限値Ｄｍｉｎ内）との間と成すために、画質又は単位時間内の送信コマ数を制御する制御手段としての演算判断回路８４，取り込み周期指定回路７１，フレーム取り込みクロック発生回路７０とを有している。
【００２３】
すなわち、本実施例の送信装置は、上記バッファメモリ内容量測定回路８６において上記取り込み時間と送信時間との差（測定値Ｄ）が上記第２の時間内（下限値Ｄｍｉｎ）を下回ったことを検出すると、上記演算判断回路８４が取り込み周期指定回路７１及びフレーム取り込みクロック発生回路７０を制御することで、フレームバッファ６８において動画の画質又はコマ落とし数を可変する。これによって、本実施例の送信装置は、映像データバッファメモリ８３に送る動画データの量を制御するようにしている。
【００２４】
なお、本実施例の送信装置では、動画データと共に、音声データをも扱うようにしている。
【００２５】
また、本実施例の送信装置には、音声及び動画の信号を除く信号をも送信可能であり、したがって、送信信号が音声及び動画の信号を除く信号であることを検出する第３の検出手段としての検出回路９３をさらに設けている。この検出回路９３において、送信信号が音声及び動画を除く信号であることを検出したときには、当該信号をデータ処理回路２６によってそのまま処理するようにもしている。なお、上記音声及び動画の信号を除く信号としては、例えばテキストデータやプログラムデータや数値データ，他のバイナリデータ等を挙げることができる。
【００２６】
さらに、本発明の送信装置の上記検出回路９３は、送信信号から所定の部分として例えば映像の重要な部分を検出する第４の検出手段としても動作し、当該第４の検出手段としての検出回路９３からの検出出力を、上記演算判断回路８４に送るようにもしている。当該演算判断回路８４においては、上記検出出力に基づいて、上記取り込み周期指定回路７１とフレーム取り込みクロック発生回路７０を制御することで、上記フレームバッファ６８に対して上記所定の部分のみはそのまま出力し、他の部分を伝送しないような読み出し制御を行う。
【００２７】
ここで、先ず、図１と図９〜図１０に示す本発明実施例の送信装置の具体的に説明に先立ち、本発明の送信装置が適用される情報処理通信システムのマルチメディアデータ対応の情報処理装置の基本機能と、該情報処理装置のモデルといわゆるアプリケーション・プログラミング・インタフェース（ＡＰＩ:application programming interface) と、情報処理通信システムにおける当該マルチメディア対応の情報処理装置の位置付け、当該情報処理の評価について、以下に項目に分けて説明する。
【００２８】
１．情報処理通信システムにおけるマルチメディア対応の情報処理装置の機能
この情報処理装置が実現する目標は、
(1) いろいろな制約はあるが、標準のパーソナルコンピュータやワークステーションにおいて構築し、既存のシステムとの親和性を保つこと、
(2) 音声や動画の通信や特有の処理は、当該情報処理装置にまかせ、クライアントプログラムはそのコントロールだけを行うこと、
(3) メディアデータの属性と、クライアントプログラムの目的に応じて柔軟に対処できること、
(4) プロセッサやネットワークなどのリソースの負荷の変動に対して、対応できること、
(5) モデルが単純なこと、
などである。
【００２９】
これらの要求から、情報処理装置は以下に述べるような機能を持つことが必要となる。
【００３０】
１．１ メディアタイプ
情報処理装置で扱うメディアデータとして、基本的には音声と動画がある。これらには、単位時間あたりのデータ量や生成時刻などの時間的な属性をつけ、これを情報処理装置での処理に利用する。例えば、データ幅８ビット、サンプリング周波数８ｋＨｚの音声データの場合には、単位時間は１／８０００（ｓｅｃ）、単位時間あたりのデータ量は１バイトという属性がつけられる。
【００３１】
１．２ 情報処理装置とメディアデバイス
情報処理装置は、複数の入力デバイスからのデータを、時間的な同期を取りながら、出力デバイスに出力する。
【００３２】
入力デバイスとしては、
(1) オーディオインタフェースやビデオ入力インタフェースなどのハードウェアデバイス、
(2) サウンドファイルや動画ファイルやムービーファイルのようなマルチメディアデータファイル、
(3) マルチキャストアドレス、
(4) クライアントプロセス
などをサポートする。
【００３３】
出力デバイスとしては、
(1) オーディオインタフェースやウィンドウなどのデバイス、
(2) マルチメディアファイル、
(3) マルチキャストアドレス、
(4) クライアントプロセス、
などをサポートする。
【００３４】
あるホストには情報処理装置はただ一つだけ存在し、それが直接に取り扱うデバイスは、そのホスト上にあることが必要である。入力デバイスと出力デバイスが別々のホストにあることを必要とする場合には、クライアントがそれぞれのホスト上のそれぞれの情報処理装置にアクセスして情報処理装置同志を接続させる。
【００３５】
１．３ メディアデータの転送と同期
マルチメディアシステムとしてユーザに提供する物の品質の評価規準として以下のものが考えられる。
例えば、
(1) 転送の遅れの許容限度、
(2) メディア間同期の許容限度、
(3) スループット、
(4) データの欠損が許される場合と許されない場合
である。
【００３６】
与えられた転送路で満足できる品質を得るために、データ量、圧縮方式、プロトコルやパケットサイズなどの転送の際の種々のパラメータをコントロールする。情報処理装置は、品質の評価基準に従って、メディア間同期を行う。
【００３７】
１．４ ネットワークプロトコール
上記情報処理装置が利用するマルチメディアデータのネットワークプロトコールは、品質の評価基準を考慮しながらフローなどを動的にコントロールできる必要がある。現状のネットワーク環境のＩＥＥＥ ８０２．３規格に準拠したいわゆるイーサ・ネット(Ethernet)や、国際標準化機構（ＩＳＯ）のＳＣ１３において提案されている光ファイバを用いた１００Ｍビット／秒トークンパッシング方式のファイバ・ディストリィビューテッド・データ・インタフェース（ＦＤＤＩ:fiber-distributed data interface)などネットワークデバイスは、分散環境上で個々に資源を取り合って共有しているため、あらかじめネットワーク資源を確保するようなサービスが難しい。しかし、現状のネットワーク環境との親和性を考えるとインターネット・プロトコール（ＩＰ:internet protocol) を利用する必要があり、今回はネットワークプロトコールとしていわゆるトランスミッション・コントロール・プロトコール（ＴＣＰ:transmission control protocol) と、コネクションレス形式のプロトコールであるいわゆるユーザ・データグラム・プロトコール（ＵＤＰ:user datdgram protocol)を利用した。
【００３８】
１．５ データの圧縮伸張
情報処理装置は、ソフトウェアまたはハードウェアによる、音声データや動画データの圧縮伸張機能を持つ。音声の圧縮方式としては、国際電信電話通信諮問委員会（ＣＣＩＴＴ）の音声符号化標準の勧告Ｇ．７１１，Ｇ．７２１，Ｇ．７２２，Ｇ．７２８などの規格をサポートする。また、画像の圧縮方式としては、国際電信電話通信諮問委員会（ＣＣＩＴＴ）のカラー静止画像符号化方式の国際標準化作業グループのいわゆるＪＰＥＧ(Joint Picture Expert Group)や、テレビ会議システム用映像符号化勧告Ｈ．２６１、カラー動画像符号化方式の国際標準化作業グループのＭＰＥＧ（Moving Picture Expert Group)などの方式がある。圧縮方式ごとに特徴があるので、用途によって使い分ける必要がある。
【００３９】
１．６ リソースのコントロール
情報処理装置は、複数のクライアントプログラムからの入出力要求を処理する機能をもつ。例えば、音声入力デバイスは一つしかないのに複数のクライアントから音声入力要求があった場合には、以下のような処理方法が考えられる。
(1) すべての要求元にコピーして配る。
(2) 先着の要求を優先し、後着の要求を拒絶する。
(3) クライアントを順次切り替える。この機能は、ウィンドウシステムでのウィンドウマネージャに相当するマルチメディアマネージャなどのプログラムが利用する。
【００４０】
１．７ 物理デバイスのコントロール
音声や動画などのマルチメディアデータを扱う場合には、ビデオカメラやビデオデッキのようないわゆるオーディオ・ビジュアル機器（ＡＶ機器）を接続することが必要になる。情報処理装置は、これらのコントロールのために、ＡＶ機器制御用の所定のプロトコールをサポートする。
【００４１】
２. 情報処理装置のモデルとＡＰＩ
２．１ ＡＶ機器が接続される情報処理装置のモデル
情報処理装置は、図２に示すように、クライアントそれぞれに対し１つの実行制御単位(AVobj）を生成する。クライアントがマルチメディアデータの入出力を行いたい場合には、次のような手順で情報処理装置に要求をだす。まず、実行制御単位（AVobj)において仮想的なメディアデバイス(AVdev) をオープンする。当該仮想的なメディアデバイス(AVdev) は物理的なデバイスではないため、排他制御や複数からのオープンなどが実現出来る。
【００４２】
また、図３に示すように、入力用に上記仮想的なメディアデバイス(AVdev) をオープンした実行制御単位(AVobj) と出力用にメディアデバイス(AVdev) をオープンした実行制御単位(AVobj) とを接続することによりマルチメディアデータの転送路が確保される。同一の実行制御単位(AVobj) でオープンされているデバイス間のメディアの同期は保証される。
【００４３】
さらに、図４のようにネットワークでつながれた異なるホスト上の情報処理装置において実行制御単位(AVobj) を生成し、接続することにより分散環境上のワークステーションにおいてマルチメディアデータの転送が行われる。
【００４４】
送信、受信側の実行制御単位(AVobj) がオープンするデバイス(AVdev) としてサウンドデバイスを用いると電話が実現できる。さらに、ビデオデバイスをオープンするとテレビ電話が実現できる。また、入力デバイスとして映画(Movie) ファイルを指定し、出力デバイスにサウンドデバイスとビデオデバイスをオープンすると映画(Movie) プレーヤとなる。このように入出力のデバイスを組み替えることにより各種マルチメディアアプリケーションを容易に作成することが可能となる。
【００４５】
２．２ 情報処理装置のＡＰＩ
情報処理装置のライブラリには、例えば次のものが用意されている。
【００４６】
int avs ＿new(char *hostname);
これは、ホスト名(hostname)上で起動されている情報処理装置において実行制御単位(AVobj) を生成する。エラーが発生した場合にはヌル(null)が返される。正常終了した場合には実行制御単位(AVobj) のＩＤ（識別情報）が返される。実行制御単位(AVobj) に対する命令はすべてこの実行制御単位(AVobj) のＩＤを用いて行なわれる。
【００４７】
int avs ＿open(int net, char *devname, int mode);
これは、デバイス(AVdev) をオープンする。引数は実行制御単位(AVobj) のＩＤ、デバイス名、モードである。
【００４８】
int avs ＿connect(int net1, int net2);
これは、２つの実行制御単位(AVobj) をポイント・ツウ・ポイント(point-to-point)接続する。これによって接続した実行制御単位(AVobj) の一方が以下に述べる関数（avs ＿transfer) によって転送状態になると、もう一方の実行制御単位(AVobj) がそのデータを受けとれるようになり自動的に受けとったデータを処理する。ひとつの送信実行制御単位(AVobj) に対して複数の受信実行制御単位(AVobj) を接続することが可能なため、１対多のデータ転送を処理できる。
【００４９】
int avs ＿transfer(int net, int dev, int length);
これは、実行制御単位(AVobj) の送信を制御する。デバイスＩＤとして０を指定すると、実行制御単位(AVobj) がオープンしたすべてのデバイスに対して有効となる。長さ(length)に正の数を指定するとその長さだけデータ転送が行なわれる（単位はｍｓｅｃ）。ここでゼロを指定すると、次の関数(av ＿transfer) が与えられるまで転送します。負の数を指定すると即座に停止する。
【００５０】
int avs ＿destroy(int net);
これは、関数(av ＿new)によって生成した実行制御単位(AVobj) を解放する。
【００５１】
int avs ＿interval(int net, int dev, int interval);
これは、転送インターバルの設定を行なう。単位はｍｓｅｃである。デバイスＩＤとしてゼロを設定すると、その実行制御単位(AVobj) でオープンされたすべてのデバイスに対して適応される。
【００５２】
int avs ＿resize(int net, int dev, int width, int height);
これは、ビデオデバイスに対してサイズ変更を要求する。サイズの単位はピクセルである。デバイスＩＤとしてゼロを設定すると、その実行制御単位(AVobj) でオープンされたすべてのビデオデバイスに対して適応される。
【００５３】
int avs ＿nettype(int net, char *type);
これは、実行制御単位(AVobj) 同志を接続するネットワークのタイプを設定する。現在のところ前記ＴＣＰとＵＤＰがサポートされている。これは関数(avs＿connect)を実行する以前に行なわなければならない。
【００５４】
int avs ＿fd(int net);
これは、クライアントと実行制御単位(AVobj) とのコントロール接続コネクションのファイル記述子を返す。
【００５５】
int avs ＿codec(int net, char *type, int quality);
これは、メディアデータの圧縮方式を指定する。ここでは、画像データに対して前記ＪＰＥＧの圧縮伸張のみがサポートされている。
【００５６】
その他、デバイス(AVdev) に対し直接メディアデータにアクセスするためのライブラリとして次のものがある。
例えば、
int avs ＿read(int net, int dev, int shmid, int size);
int avs ＿write(int net, int dev, int shmid, int size);
int avs ＿ioctl(int net, int dev, int request, int shmi);
である。
【００５７】
３．情報処理装置の実装
システム全体における情報処理装置の位置付けは次の図５のようになる。
３．１ スレッド(Thread)の利用
スレッドを用いると、複数プロセスを用いて実現するよりもコンテキスト・スイッチの時間が短く、各スレッド間でメモリなどの環境を共有でき、プログラミングが容易になる。情報処理装置を実現するにあたってスレッドのモデルへの割り当て方法として次の２通りが考えられる。
【００５８】
例えば、
機能毎にスレッドに割り当てる、
データストリーム毎にスレッドを割り当てる、
がある。
前者では画面入出力・音声入出力・ネットワークなどの機能毎にスレッドを割り当て、パイプラインを形成する方法であり、後者はメディアデータ毎の入力から出力までを行う処理にスレッドに割り当てる方法である。
【００５９】
機能毎にパイプラインを形成してもマルチプロセッサ環境下でないと利点はなく、複数のストリームにおいてストリーム単位のスケジュール・プライオリティ制御を行うには、後者が適しているため、今回の実装ではデータストリーム毎にスレッドを割り当てる方法も用いた。
【００６０】
３．２ ＴＣＰ／ＩＰの送信受信バッファと遅延
前記ＴＣＰ／ＩＰでは高信頼性を実現するため、パケットの順序付け、チェックサム、タイムアウトそして再転送を行い、オーバヘッドが大きくデータの転送遅延が問題となる。
【００６１】
したがって、ここでは送信および受信のためにバッファが用意されている。例えばワークステーションでは、デフォルトで８Ｋ（バイト）となっている。このバッファにデータがたまることによって遅延が生じる。例えば、解像度が１６０×１２０、深さ１６ビットの画面ならば、一画面でおよそ３８Ｋバイトとなり、送信側と受信側両方のバッファを合わせても１フレームもバッファリングされない。この場合にはバッファサイズを大きくすると転送効率は向上する。ところが、画像圧縮をかけて１／１０程の４Ｋバイト程度の大きさにすると両方のバッファ合わせておよそ４フレームが溜まることとなる。１秒間に５フレームのスピードで転送を行うならばこれだけで約１秒間の遅延となる。
【００６２】
しかし、逆にあまりバッファを小さくすると、転送効率が悪くなるため、ここにトレードオフがある。この送信、受信バッファのサイズは関数(setsockopt)で変更可能である。
【００６３】
４． 情報処理装置の評価
情報処理装置をワークステーション上に実装した場合の評価は以下のようになる。
【００６４】
４．１ 送受信バッファと転送遅延、効率
実際に送受信バッファのサイズと転送遅延、効率の測定をした例として、同一ネットワークに接続された２台のワークステーションの間で動画像データの転送を行なった。ここで、ワークステーションをイーサネットで接続し、解像度は１６０×１２０、１６ビットの深さの無圧縮とＪＰＥＧ圧縮画像で転送して測定し、１フレームのサイズは無圧縮でおよそ３８Ｋバイト、ＪＰＥＧ圧縮でおよそ５Ｋバイトとしている。
【００６５】
また、転送遅延は関数(timed(8))を用いて時計を合わせ、画像取り込みから転送を行いリモート側で表示を行うまでの時間を測定した。さらに、転送効率としては最大転送フレームレートを測定している。図６には無圧縮、図７にはＪＰＥＧ圧縮の画像の送受信バッファサイズと転送遅延、効率の関係を示す。
【００６６】
図６に示すように、無圧縮で１フレームの大きさが大きい場合には、送受信バッファに１フレームが入り切らないためバッファのサイズに対する転送遅延の差はほとんど変わらない。バッファサイズが８Ｋバイトの時には、転送遅延、効率ともに良い結果が現れる。この図６によれば、デフォルトの送受信バッファサイズが８ＫバイトということからもＴＣＰ／ＩＰでの転送がその場合に一番効率が良くなるようになっていることがわかる。
【００６７】
それに比べ、図７に示すＪＰＥＧ圧縮を行なった画像を転送する場合には、ソフトウェアでＪＰＥＧの圧縮伸張を行うため最大フレームレートは少ない。また、送受信バッファに数フレームが溜まってしまうため、バッファのサイズが大きいほど遅延は増大する。そこでＪＰＥＧなどの圧縮を行い画像データがネットワークのバンド幅より充分小さい場合には、送受信のバッファサイズを転送効率が下がらない程度に小さくすることにより、メディアデータの転送遅延を短縮できる。
【００６８】
４．２ 画面転送スピード
同様の環境で、画面サイズとフレームレートおよび転送遅延を測定している。まず、ネットワークとしてイーサネットを用いた場合は、次の表の結果が得られた。表１には１６ビットの深さの無圧縮画像、表２にはＪＰＥＧ圧縮した画像の転送最大フレームレートと遅延の性能を示す。
【００６９】
【表１】
【００７０】
【表２】
【００７１】
次に、ネットワークとしてサービス総合ディジタル網（ＩＳＤＮ:integrated service digitial network) の１Ｂ（６４Ｋ）を用いた場合の性能は表３のようになる。なお、ＩＳＤＭを用いた場合には、画像データを圧縮しないと最小の画面サイズ（８０×６０）においてもフレームレートが０．２（fps)となり、実用的でないため、深さ１６ビットの無圧縮画像の転送性能の評価は省いた。
【００７２】
【表３】
【００７３】
このような情報処理装置を用いることにより、画像と音声の取り込みや圧縮伸張、またネットワークプログラミングを意識することなく容易にマルチメディアアプリケーションが作成可能となった。
【００７４】
４．４ メディア間同期の実現
この情報処理装置では同期をとりメディアデータは、単一のストリームにインターリーブして転送している。また、ネットワークプロトコルとしてＴＣＰ／ＩＰを用いているため、パケットの順序は保証される。さらに、複数のメディアデータの取り込みを同時に行い、インターリーブしてデータ送信時に同期を保証できれば、データ受取側でも複数のメディアデータの同期はとれているものと仮定できる。実際この方法で単一ネットワーク上にて転送した音声と動画のメディアデータの同期は満足のいく結果となった。
【００７５】
４．５ 遅延との関係
上述の実装では、ネットワークプロトコルとしてオペレーティングシステムのＵＮＩＸで標準的なＴＣＰ／ＩＰを用いている。ここで、図８に示すように、メディアデータを直接送ることの出来る環境では、送信側と受信側のバッファの制御を情報処理装置が行うことができ、細かな流量制御が行える。
【００７６】
以下、図１に戻って、上述したようなことを具体的に実現する本発明実施例の送信装置について説明する。
【００７７】
図１において、マイクロホン１やビデオカメラ２からの音声信号や映像信号（動画信号）は、それぞれ対応するＡ／Ｄ変換回路６５，６６に送られて、Ａ／Ｄ変換される。Ａ／Ｄ変換回路６５からの音声データは、音声データ圧縮回路６７に送られ、ここで前述したように音声の圧縮方式として例えばＧ．７１１，Ｇ．７２１，Ｇ．７２２，Ｇ．７２８などのうちのいずれかを用いた圧縮が施される。また、上記Ａ／Ｄ変換回路６６からの映像データは、フレームバッファ６８を介して映像データ圧縮回路６９に送られ、ここで前述したように動画の圧縮方式として例えばＪＰＥＧ，Ｈ．２６１，ＭＰＥＧなどのうちのいずれかを用いた圧縮が施される。
【００７８】
これら圧縮回路６７，６９からの圧縮された音声データと映像データは、それぞれ対応して設けられた音声データバッファメモリ８２と映像データバッファメモリ８３に送られる。
【００７９】
また、バッファメモリ内容量測定回路８６は、音声データバッファメモリ８２と映像データバッファメモリ８３のそれぞれの書き込みアドレス及び読み出しアドレスから、当該メモリ８２と８３の内容量の測定を行い、その測定結果を演算判断回路８４に送る。
【００８０】
当該演算判断回路８４では、上記測定回路８６からの映像データバッファメモリ８３の内容量測定結果（後述する測定値Ｄ）に基づいて、映像データバッファメモリ８３の内容量が上記上限（後述するＤｍａｘ）を越えたことを検出したときに、その旨の信号を制御信号として上記取り込み周期指定回路９１に送る。
【００８１】
さらに、上記演算判断回路８４では、上記測定回路８６からのメモリ８３の内容量測定結果（後述する測定値Ｄ）が、映像データバッファメモリ８３の内容量が上記下限（後述するＤｍｉｎ）を下回るような場合には、映像が途切れるおそれがあるので、その旨（下限を下回った旨）の信号を制御信号として上記取り込み周期指定回路９１に送る。
【００８２】
当該取り込み周期指定回路７１は、上記制御信号に基づいて、フレーム取り込みクロック発生回路７０を制御する。当該フレーム取り込みクロック発生回路７０は、上記取り込み周期指定回路７１からの信号を受けると、例えばフレームバッファ６８において出力するコマ数を可変させるようなフレーム取り込みクロックを発生させる。このフレームバッファ６８において、例えばコマ落としを行う（若しくはコマ落とし数を増やす）ことで、送信する映像データの量を減らすことができ、コマ落としを行わないか若しくはコマ落とし数を減らすことで送信する映像データの量を増やすことができる。
【００８３】
すなわち、本実施例の送信装置ではでは、以下の図９に示すようなフローチャートの処理を行うことで、単位時間内に送信するコマ数を制御するようにしている。
【００８４】
この図９において、ステップＳ６１では、上記映像データのバッファメモリ８３の内容量の測定値Ｄを求める。なお、上記測定値Ｄは以下の式で求める。
Ｄ＝（バッファ読み出しアドレス）−（バッファ書き込みアドレス）
【００８５】
次のステップＳ６２では、当該測定値Ｄと映像データのバッファメモリ８３の内容量の上限値Ｄｍａｘとから、Ｄ＞Ｄｍａｘを判定し、ノーと判定した場合にはステップＳ６３に進み、逆にイエスと判定した場合にはステップＳ６４に進む。
【００８６】
ステップＳ６４では、上記取り込み周期指定回路７１が、フレーム取り込みクロック発生回路７０に対して、フレームバッファ６８におけるフレームの取り込みクロックの周期をＰだけ長くさせるように制御する。このステップＳ６４の後はステップＳ６１に戻る。なお、このＰの値は、例えば１％とする。
【００８７】
一方、上記ステップＳ６２においてノーと判断された場合のステップＳ６３では、上記測定値Ｄと映像データのバッファメモリ８３の内容量の下限値Ｄｍｉｎとから、Ｄ＜Ｄｍｉｎを判定する。当該ステップＳ６３において、ノーと判定した場合にはステップＳ６１に戻り、イエスと判断した場合にはステップＳ６５に進む。
【００８８】
ステップＳ６５では、上記取り込み周期指定回路７１が、フレーム取り込みクロック発生回路７０に対して、フレームバッファ６８におけるフレームの取り込みクロックの周期をＰだけ短くさせるように制御する。このステップＳ６５の後はステップＳ６１に戻る。なお、このＰの値は、例えば１％とする。
【００８９】
これにより、本実施例の送信装置では、映像データバッファメモリ８３の内容量が多くなって当該映像データバッファメモリ８３における入力から出力までの時間遅れ及び時間のずれが適正な値を越える、すなわち映像データバッファメモリ８３の内容量の測定値Ｄが上限値Ｄmaxを越えるようになっても、当該時間遅れ及び時間のずれを適正な値に回復する、すなわち上記測定値Ｄを上限値Ｄmaxまでの範囲内に戻すことができ、また、映像データバッファメモリ８３の内容量が少なくなって上記測定値Ｄが下限値Ｄminを下回ることにより映像が途切れるおそれがでてきても、当該映像の途切れを防ぐことができるようになる。
【００９０】
上述のようにして映像データバッファメモリ８３から読み出された圧縮された映像データと、音声データバッファメモリ８２から読み出された圧縮された音声データとは、マルチプレクサ５によってマルチプレクスされ、その後ネットワーク送信部７に送られ、当該ネットワーク送信部７から例えばイーサネットなどのネットワーク８を経て、受信側のネットワーク受信部１１に送られる。
【００９１】
また、本実施例の送信装置の入力端子８９には、送信信号として音声及び動画の信号を除く信号である例えばテキストデータやプログラムデータ，数値データ，他のバイナリデータのような信号が入力される。このデータは、検出回路９３に送られる。当該検出回路９３においては、上記音声及び動画を除くデータを検出するとそのまま当該データを出力して、データ処理回路９４に送る。
【００９２】
当該データ処理回路９４では、供給されたデータに対する所定の処理としては、例えば誤り訂正符号の付加等の処理を行い、その後、データバッファメモリ９５に送る。当該データバッファメモリ９５では、データを一旦蓄えた後に、上記マルチプレクサ５に送る。
【００９３】
このように、本実施例の送信装置においては、上記検出回路９３を有し、送信信号として前記音声や動画を除く他のデータも送信できるようになっている。
【００９４】
さらに、本実施例の送信側では、上記Ａ／Ｄ変換回路６６からの映像データも、上記検出回路９３に送られる。
【００９５】
このときの上記検出回路９３では、映像データに対しては例えば人間の視覚特性を考慮して当該映像データから特に視覚的に重要な映像部分を検出したり、映像内容で特に重要な部分を検出したりする。この検出回路９３からは、上記映像データに対応する検出信号が出力され、この検出信号が上記演算判断回路８４に送られる。
【００９６】
上記演算判断回路８４では、上記検出回路９３から上記映像データ用の制御信号を受けると、前述したフレームバッファ６８における伝送コマ数の可変制御を行う際に、上記検出回路９３での検出信号に対応した映像部分については伝送されるような制御、すなわち、上記検出信号に対応する映像の重要な部分については上記フレームバッファ６８からそのままデータを読み出して映像データ圧縮回路６９に送るように制御する。逆に、映像の重要でない部分に対しては、映像データバッファメモリ８３の内容量に応じて、前記伝送コマ数の制御が行われる。
【００９７】
これにより、本実施例の送信装置では、映像の重要な部分を除く部分についてはフレームバッファ６８での伝送コマ数の制御操作が行われることで、映像データバッファメモリ８３の入力から出力までの時間遅れを適正値に回復させることができ、また、上記映像の重要部分についてはコマ落としがなされないために、送信される映像は、高品質を保つことができるようになる。
【００９８】
次に、本実施例の受信側において、上述したような送信データを受信するネットワーク受信部１１によって受信されたデータは、分離回路１２によって上記圧縮された音声データと映像データとに分離され、それぞれ対応する音声データバッファメモリ（ＦＩＦＯメモリ）１３と映像データバッファメモリ（ＦＩＦＯメモリ）１４に送られる。
【００９９】
上記音声データバッファメモリ１３や映像データバッファメモリ１４から読み出された音声データと映像データは、それぞれ対応する伸張処理及びＤ／Ａ変換を施す伸張Ｄ／Ａ変換回路１８，１９に送られる。これら伸張Ｄ／Ａ変換回路１８，１９では、前記Ａ／Ｄ変換圧縮回路３，４での各圧縮処理に対応する伸張処理がそれぞれ施され、その後Ｄ／Ａ変換して出力する。
【０１００】
上記伸張Ｄ／Ａ変換回路１８からの音声信号はスピーカ１９に送られ、上記伸張Ｄ／Ａ変換回路１９からの映像信号はモニタディスプレイ２４に送られる。
【０１０１】
また、上記分離回路１２に供給された受信信号は、当該分離回路１２を介して検出回路２５にも送られる。検出回路２５では、上記受信信号から音声及び動画の信号を除く信号である例えば上記テキストデータやプログラムデータ，数値データ，他のバイナリデータのようなの信号を検出する。
【０１０２】
この検出回路２５において上記音声や動画の信号を除くデータを検出すると、当該検出回路２５からは、上記分離回路１２に対して検出信号が出力される。上記分離回路１２は、上記検出回路２５からの検出信号が供給されると、上記受信信号から当該検出信号に応じたデータのみを分離して、データ処理回路２６に送る。
【０１０３】
当該データ処理回路２６では、供給されたデータに対して所定の処理を施した後、出力端子から出力する。なお、上記所定の処理としては、例えば誤り訂正処理等を挙げることができる。
【０１０４】
このように、本実施例の受信側においては、上記検出回路２５を有し、上記分離回路１２が当該検出回路２５からの検出信号に応じて、受信信号から音声や動画以外のデータを分離することによって、上記音声や動画を除くデータについての処理を可能となっている。
【０１０５】
また、上記図１の構成では、映像のコマ落とし数を可変することで、上記映像データバッファメモリ８３における入力から出力までの時間遅れ及び時間のずれを適正な値に回復したり、映像の途切れを防ぐようにしているが、例えば、画像の画質を選択することでも同様のことを行うことができる。
【０１０６】
すなわち、この画質を選択する場合には、例えば、フレームバッファ６８において取り込む各画素データを間引くことで送信するデータ量を減らしたり、逆に間引きを行わないようにすることで画質を確保する。この場合、受信側では、画素データを間引いたときには、例えば補間等の処理を行って画像を復元する。
【０１０７】
次に、本発明の他の実施例の構成を図１０に示す。
【０１０８】
この図１０において、送信側ホストコンピュータには、モニタディスプレイ４０とマイクロホン４１とビデオカメラ４２が接続され、またネットワーク４３を介して受信側ホストコンピュータと接続される。
【０１０９】
当該送信側ホストコンピュータにおいて、ＣＰＵ３０は、メインメモリ３１に保持されているプログラムデータを用いて各部を制御すると共に、上述した図１の各バッファメモリ内容量測定回路８６，演算判断回路８４，取り込み周期指定回路７１，フレーム取り込みクロック発生回路７０，検出回路９３，データ処理回路９４等の機能を備えているものである。
【０１１０】
ビデオカメラ４２からの映像信号は、Ａ／Ｄ変換圧縮処理部３８によってＡ／Ｄ変換されると共に前述したような圧縮処理が施され、バッファメモリ３４に一時蓄えられる。このバッファメモリ３４は、前述の各実施例の映像データバッファメモリ８３として機能する部分と共に、前記フレームバッファ６８としても機能する部分をも有するしている。ただし、前述のフレームバッファ６８には圧縮前の映像データが取り込まれる例を挙げているが、この図１０に示すバッファメモリ３４の例では圧縮後の映像データを取り込むようにしている。
【０１１１】
一方、マイクロホン４１からの音声信号は、Ａ／Ｄ変換圧縮処理部３７によってＡ／Ｄ変換されると共に前述したような圧縮処理が施され、バッファメモリ３３に一時蓄えられる。このバッファメモリ３３は、前述の図１の音声データバッファメモリ８２としての機能を有する。
【０１１２】
また、フレームメモリ３２には、例えばＣＰＵ３０によって形成された映像フレームデータや、ビデオカメラ４２によって撮影された映像に基づく映像フレームデータが記憶される。当該フレームメモリ３２からの映像フレームデータは、ディスプレイインタフェース３６を介してモニタディスプレイ４０に送られて表示される。
【０１１３】
さらに、上記バッファメモリ３３，３４に蓄えられた圧縮された音声データと映像データは、例えばＣＰＵ３０によってマルチプレクスされた後にバッファメモリ３５に一旦蓄えられてから読み出される。なお、このバッファメモリ３５は図１のデータバッファメモリ９５としての機能も有している。当該バッファメモリ３５から読み出されたデータは、ネットワークインタフェース３９に接続されたネットワーク４３を介して、受信側ホストコンピュータに送られる。
【０１１４】
次に、受信側ホストコンピュータには、モニタディスプレイ６１とスピーカ６２が接続され、さらにネットワーク４３を介して送信側ホストコンピュータと接続される。
【０１１５】
当該受信側ホストコンピュータにおいて、ＣＰＵ５２は、メインメモリ５３に保持されているプログラムデータを用いて各部を制御したり、また、各種の演算を行う。
【０１１６】
上記ネットワーク４３を介して上記送信側ホストコンピュータから送られてきたデータは、ネットワークインタフェース５０を介してバッファメモリ５１に一旦蓄えられた後、読み出される。
【０１１７】
当該バッファメモリ５１から読み出された受信データからは、例えばＣＰＵ５２によって上記圧縮された音声データと映像データとが分離され、それぞれ対応するバッファメモリ５４，５５に送られる。
【０１１８】
バッファメモリ５４に送られた圧縮された映像データは、当該バッファメモリ５４から読み出されてデータ伸張処理部５６に送られて上記送信側ホストコンピュータでの圧縮に対応する伸張処理がなされる。当該伸張された映像データは、フレームメモリに蓄えられてフレームとなされ、ディスプレイインタフェース５８を介してモニタディスプレイ６１に送られて表示される。
【０１１９】
また、バッファメモリ５５に送られた圧縮された音声データは、当該メモリ５５から読み出されてデータ伸張処理部５９に送られて上記送信側ホストコンピュータでの圧縮に対応する伸張処理がなされる。当該伸張された音声データは、Ｄ／Ａ変換処理部６０によってアナログの音声信号に変換された後、スピーカ６２に送られる。
【０１２０】
上述したように、本発明の各実施例装置によれば映像データバッファ８３の内容量の測定値Ｄが、当該バッファ８３の内容量の上限値Ｄｍａｘを越えたことを検出すると、当該映像データバッファメモリ８３における映像データの取り込み時間と送信時間との差を上限値Ｄｍａｘと下限値Ｄｍｉｎとの間とするために、画質又は単位時間内の送信コマ数を制御するようにしているため、上記映像データバッファメモリ８３での入力から出力までの時間遅れ及び時間のずれを適正な値に回復し、また映像の途切れを防ぐことを可能としている。
【０１２１】
また、本実施例の送信装置においては、検出回路９３を設け、この検出回路９３によって受信信号が動画及び音声を除くデータであることを検出したときには、データ処理回路９４においてそのまま処理するようにしたことで、送信信号が例えばテキストデータ，プログラムデータ，数値データ，他のバイナリデータなどである場合に、これらデータの内容が変化することを防いでいる。
【０１２２】
さらに、本実施例の送信装置においては、検出回路９３によって送信信号から映像において特に重要な部分を検出したときには演算判断回路８４によって取り込み周期指定回路７１及びフレーム取り込みクロック発生回路７０を制御し、これら重要な部分を除く他の部分についてはコマ落としを行うように上記フレームバッファ６８を制御することで、映像データバッファメモリ８３の入力から出力までの時間遅れを適正値に回復させるようにし、上記特に重要な部分についてはそのまま処理することで、この部分の信号については破棄されることを防いでいる。
【０１２３】
【発明の効果】
上述のように本発明の送信装置においては、信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号を送信する実時間の送信を行う際に、動画信号を外部から取り込み、この取り込まれた動画信号をバッファ手段にバッファリングし、バッファ手段のバッファメモリ内容量Ｄを測定し、バッファ手段によりバッファリングされた動画信号を送信し、測定されたバッファメモリ内容量Ｄが、上記取り込み時間と上記送信する時間との差の上限としての第１の時間をバッファメモリ内容量に換算して得られる上限値Ｄmax内であることを検出し、測定されたバッファメモリ内容量Ｄが、上記取り込み時間と上記送信する時間との差の下限としての第２の時間をバッファメモリ内容量に換算して得られる下限値Ｄmin内であることを検出し、測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、画質又は単位時間内の送信コマ数を制御することにより、バッファメモリ内容量を上記上限値と上記下限値との間となすことができ、これによってバッファ手段の入力から出力までの時間遅れを適正値に回復させることを可能としている。
【０１２４】
さらに、本発明の送信装置においては、送信時に信号の信号の取り込み時間と送信する時間との差が第２の時間内を下回ったことを検出したときには、送信する動画の画質を上げるか又はコマ落とし数を無くす（若しくは少なくする）ことで、映像の途切れを防ぐことが可能となる。
【０１２５】
また、本発明の送信装置においては、第３の検出手段によって送信信号が動画の信号を除く信号であることを検出したときには、そのまま処理することで、送信信号が例えばテキストデータなどである場合に、データの内容が変化することを防止できる。
【０１２６】
さらに、本発明の送信装置によれば、第４の検出手段を設け、この第４の検出手段によって送信信号の所定の部分を検出したときには、その所定の部分を除く他の部分の送信を中止することで、バッファ手段の入力から出力までの時間遅れを適正値に回復させることができ、その所定の部分についてはそのまま処理することで、この所定の部分の信号については送信可能とする。
【図面の簡単な説明】
【図１】本発明実施例の送信装置及びこれに対応する受信側の装置の概略構成を示すブロック回路図である。
【図２】本発明装置が適用される情報処理通信システムの情報処理装置のモデルを示す図である。
【図３】マルチメディアデータの転送について説明するための図である。
【図４】ネットワークでつながれたホスト間のマルチメディアデータの転送について説明するための図である。
【図５】システム全体における情報処理装置の位置付けについて説明するための図である。
【図６】無圧縮の場合の送受信バッファサイズと転送遅延、効率の関係を示す特性図である。
【図７】ＪＰＥＧ圧縮の画像の送受信バッファサイズと転送遅延、効率の関係を示す特性図である。
【図８】情報処理装置と遅延との関係を説明するための図である。
【図９】本実施例装置における映像データバッファメモリの内容量測定と伝送コマ数制御についての処理を説明するためのフローチャートである。
【図１０】本発明の他の実施例の送信側ホストコンピュータと受信側ホストコンピュータの概略構成を示すブロック回路図である。
【図１１】従来の送信装置と送信装置の概略構成を示すブロック回路図である。
【符号の説明】
１，４１・・・マイクロホン
２，４２・・・ビデオカメラ
５・・・マルチプレクサ
６・・・データバッファメモリ
７・・・ネットワーク送信部
８・・・ネットワーク
９・・・ネットワーク受信部
１２・・・分離回路
１３，８２・・・音声データバッファメモリ
１４，８３・・・映像データバッファメモリ
１８・・・音声データの伸張Ｄ／Ａ変換回路
１９・・・ビデオデータの伸張Ｄ／Ａ変換回路
２４，４０，６１・・・モニタディスプレイ
２５，９３・・・検出回路
２６，９４・・・データ処理回路
２７，６２・・・スピーカ
３０，５２・・・ＣＰＵ
３１，５３・・・メインメモリ
３２，５７・・・フレームメモリ
３３，３４，３５，５１，５４，５５・・・バッファメモリ
３６，５８・・・ディスプレイインタフェース
３７・・・音声データＡ／Ｄ変換圧縮部
３８・・・動画データＡ／Ｄ変換圧縮部
５６・・・音声データ用データ伸張部
５９・・・映像データ用データ伸張部
６０・・・音声データＤ／Ａ変換部
６５，６６・・・Ａ／Ｄ変換回路
６７・・・音声データ圧縮回路
６８・・・フレームバッファ
６９・・・映像データ圧縮回路
７０・・・フレーム取り込みクロック発生回路
７１・・・取り込み周期指定回路
８４・・・演算判断回路
８６・・・バッファメモリ内容量測定回路
９５・・・データバッファメモリ
【産業上の利用分野】
本発明は、例えば、コンピュータネットワークのような通信の技術分野で用いられる送信装置及び方法に関し、特に、オーディオやビデオデータのようなマルチメディアデータに対応できる送信装置及び方法に関するものである。
【０００２】
【従来の技術】
近年、パーソナルコンピュータやワークステーションなどの性能は格段に向上し、また、身近に普及しつつある。また、最近は、それらをテレビジョンや電話と同じように日常的なコミュニケーションに利用したいという要求や、これら情報処理システムをより広範囲の用途に活用したいという要求が出てきている。したがって、上記パーソナルコンピュータやワークステーションなどにおいては、これらの要求を実現するために、音声や動画などのマルチメディアデータを分散環境上でインタラクティブに扱えるようにする事が必要となっている。
【０００３】
ここで、従来のマルチメディアの通信で用いられる情報処理通信システムとしては、図１１に示す構成のものが知られている。
【０００４】
この図１１において、入力装置１００や１０１からは例えば音声データ、動画データ等が供給される。この入力装置１００，１０１としては、例えばマイクロホンからのアナログの音声信号やビデオカメラからのアナログの映像信号をディジタル信号に変換するＡ／Ｄコンバータを挙げることができる。この入力装置１００，１０１からのデータは、それぞれ入力データ処理装置１０２，１０３に送られ、それぞれ所定のデータ処理が施される。この入力データ処理装置１０２，１０３でのデータ処理としては、例えばデータ圧縮処理を挙げることができる。上記入力データ処理装置１０２，１０３からの圧縮データは、マルチプレクサ１０４によってマルチプレクス処理され、送信バッファメモリ１０５に蓄えられた後に読み出されて、ネットワーク送信部１０６から例えばイーサーネットなどのネットワークを介して受信側のネットワーク受信部１１１に送られる。
【０００５】
上記ネットワーク受信部１１１で受信されたデータは、受信バッファメモリ１１２に一旦蓄えられた後に読み出され、さらに分離装置１１３によって上記送信側のマルチプレクス処理に対応する分離処理がなされて、出力データ処理装置１１４，１１５に送られる。当該出力データ処理装置１１４，１１５は上記入力データ処理装置１０２，１０３に対応するデータ伸張処理を施し、その後再生装置１１６，１１７に送る。なお、当該再生装置１１６，１１７としては、Ｄ／Ａコンバータを例に挙げることができる。
【０００６】
【発明が解決しようとする課題】
ところで、上述した従来の情報処理通信システムにおいては、以下のような問題点がある。
【０００７】
先ず、上記従来の情報処理通信システムにおいては、例えば通信路などの負荷の変動によって処理が遅れ、送信バッファメモリ１０５において内容が増えすぎるようになる場合がある。このように、送信バッファメモリ１０５の内容が増えすぎるようになると、当該送信バッファメモリ１０５におけるデータの入力から出力までの時間遅れが大きくなる。
【０００８】
また、図１１の例では、送信バッファメモリは単数となっているが、送信バッファメモリが複数ある様な場合において、例えばこの複数の送信バッファメモリの間で内容量の差が大きくなりすぎるようになると、これら複数の送信バッファメモリは本来同期していなければならないものであるにもかかわらず、出力の際のバッファメモリ間の時間のずれ（すなわちメディア間の時間のずれ）が大きくなる。
【０００９】
この従来の欠点についてより具体的に説明する。例えば、動画や音声などのマルチメディアデータは、コンピュータがこれまで処理してきた数値データやテキストデータとは本質的に異なる性質を持っている。すなわち、マルチメディアデータは、
第一に、マルチメディアデータは単なるバイト列ではなく、明示的あるいは暗示的に時間の属性を持っていること、
第二に、本質的にデータ量が莫大かつ冗長で、ハードウェアの処理能力が向上したとしても、効率良く扱うためにはデータ圧縮をする必要があること、
第三に、インタラクティブな処理を必要とされ、スループットだけでなくレスポンスや遅れなどの性能が重視されること、
などの性質を持っている。
【００１０】
このため、これらを分散環境で扱うためには、メディア間同期、通信、処理、リーソス管理などに新たな手法を導入する必要がある。
【００１１】
そこで、本発明は、上述のような実情に鑑みてなされたものであり、特に上記メディア間同期をとるために、動画像信号についての外部から送信装置への取り込み時間と送信装置から外部へ送信する時間との差を所定時間以内に制御可能とする送信装置及び送信方法を提供することを目的とするものである。
【００１２】
【課題を解決するための手段】
本発明の送信装置は、上述した目的を達成するために提案されたものであり、信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号をパケット化して送信する実時間の送信装置であって、動画信号を外部から取り込む取り込み手段と、上記取り込み手段により取り込まれた動画信号を圧縮符号化する圧縮符号化手段と、上記圧縮符号化手段からの出力信号をバッファリングするバッファ手段と、上記バッファ手段のバッファメモリ内容量Ｄを測定する内容量測定手段と、上記バッファ手段によりバッファリングされた動画信号を送信する送信手段と、上記動画信号の上記取り込み手段による取り込み時間と上記送信手段により送信する時間との差が上記内容量測定手段により測定されたバッファメモリ内容量Ｄに予め対応付けられ、上記時間の差の上限としての第１の時間がバッファメモリ内容量の上限値Ｄmaxに、上記時間の差の下限としての第２の時間がバッファメモリ内容量の下限値Ｄminにそれぞれ予め対応付けられ、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmax内であることを検出する第１の検出手段、及び上記バッファメモリ内容量Ｄが上記下限値Ｄmin内であることを検出する第２の検出手段と、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、上記バッファメモリ内容量を上記上限値と上記下限値との間となすために、上記取り込み手段から出力する単位時間内のコマ数を制御する制御手段とを有することを特徴とするものである。
また、本発明の送信方法は、信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号をパケット化して送信する実時間の送信方法であって、動画信号を外部から取り込む取り込み工程と、上記取り込み工程により取り込まれた動画信号を圧縮符号化する圧縮符号化工程と、上記圧縮符号化工程により圧縮符号化された出力信号をバッファ手段にバッファリングする工程と、上記バッファ手段のバッファメモリ内容量Ｄを測定する内容量測定工程と、上記バッファ手段によりバッファリングされた動画信号を送信する送信工程と、上記動画信号の上記取り込み手段による取り込み時間と上記送信手段により送信する時間との差が上記内容量測定手段により測定されたバッファメモリ内容量Ｄに予め対応付けられ、上記時間の差の上限としての第１の時間がバッファメモリ内容量の上限値Ｄmaxに、上記時間の差の下限としての第２の時間がバッファメモリ内容量の下限値Ｄminにそれぞれ予め対応付けられ、上記内容量測定工程により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmax内であることを検出する第１の検出工程、及び上記バッファメモリ内容量Ｄが上記下限値Ｄmin内であることを検出する第２の検出工程と、上記内容量測定工程により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、上記バッファメモリ内容量を上記上限値と上記下限値との間となすために、上記取り込み工程から上記圧縮符号化工程に出力する単位時間内のコマ数を制御する制御工程とを有することを特徴とするものである。
【００１３】
また、本発明の送信装置は、送信信号が動画信号を除く信号であることを検出する第３の検出手段をも設け、動画信号を除く信号をも送信すると共に、上記第３の検出手段によって送信信号が動画信号を除く信号であることを検出したときには、当該動画信号を除く信号に対してはそのまま処理する。
【００１４】
さらに、本発明の送信装置は、送信信号の所定の部分を検出する第４の検出手段をも設け、当該第４の検出手段によって上記所定の部分を検出したときには、当該所定の部分についてはそのまま処理し、他の部分については送信を中止するようにしている。
【００１５】
【作用】
本発明によれば、制御手段は、信号の取り込み時間と送信する時間との差が上限である第１の時間内を越えたことを検出したときに、信号の取り込み時間と送信する時間との差を第１の時間と第２の時間との間と成すために、画質又は単位時間内の送信コマ数を制御する。
【００１６】
すなわち、本発明の送信装置によれば、送信時に信号の取り込み時間と送信する時間との差が第１の時間を越えると、バッファ手段での入力から出力までの時間遅れが大きくなるので、送信時に信号の取り込み時間と送信する時間との差が第１の時間を越えるようになったときには、送信する動画の画質を落とすか又はコマ落としを行うことで、バッファ手段の入力から出力までの時間遅れを適正値に回復させるようにしている。
【００１７】
さらに、本発明の送信装置によれば、送信時に信号の信号の取り込み時間と送信する時間との差が下限である第２の時間内を下回ると、映像が途切れるおそれが出てくるので、送信時の信号の取り込み時間と送信する時間との差が第２の時間内を下回るようになったときには、送信する動画の画質を上げるか又はコマ落とし数を無くす（若しくは少なくする）ことで、映像の途切れを防ぐようにしている。
【００１８】
また、本発明の送信装置によれば、さらに第３の検出手段を設け、この第３の検出手段によって送信信号が動画の信号を除く信号であることを検出したときには、そのまま処理することで、送信信号が例えばテキストデータなどである場合に、データの内容が変化することを防いでいる。
【００１９】
さらに、本発明の送信装置によれば、さらに第４の検出手段を設け、この第４の検出手段によって送信信号の所定の部分を検出したときには、その所定の部分を除く他の部分の送信を中止することで、バッファ手段の入力から出力までの時間遅れを適正値に回復させるようにし、その所定の部分についてはそのまま処理することで、この所定の部分の信号については送信するようにする。
【００２０】
【実施例】
以下、図面を参照し、本発明の実施例について詳述する。
【００２１】
図１には、本発明に係る送信装置及び方法の実施例となる送信装置の構成を示す。
本実施例の送信装置は、図１に示すように、少なくとも動画の信号を、取り込む取り込み時間と送信す時間との差が所定時間以内であるように送信する実時間の送信装置であり、動画信号を取り込む取り込み手段としてのＡ／Ｄ変換回路６６及びフレームバッファ６８と、動画データをバッファリングするバッファ手段としての映像データバッファメモリ８３と、動画データを送信する送信手段であるネットワーク送信部７とを有してなる。
【００２２】
さらに、本実施例の送信装置には、動画データについての取り込み時間と送信する時間との差（後述する測定値Ｄ）が上限（後述する上限値Ｄｍａｘ）の第１の時間内であることを検出する第１の検出手段、及び動画データについての取り込み時間と送信する時間との差が下限（後述する下限値Ｄｍｉｎ）の第２の時間内であることを検出する第２の検出手段としてのバッファメモリ内容量測定回路８６と、上記バッファメモリ内容量測定回路８６によって上記取り込み時間と送信時間との差（測定値Ｄ）が上記第１の時間内（上限値Ｄｍａｘ）を越えたことを検出したときに、上記取り込み時間と送信する時間との差を上記第１の時間内（上限値Ｄｍａｘ内）と第２の時間内（下限値Ｄｍｉｎ内）との間と成すために、画質又は単位時間内の送信コマ数を制御する制御手段としての演算判断回路８４，取り込み周期指定回路７１，フレーム取り込みクロック発生回路７０とを有している。
【００２３】
すなわち、本実施例の送信装置は、上記バッファメモリ内容量測定回路８６において上記取り込み時間と送信時間との差（測定値Ｄ）が上記第２の時間内（下限値Ｄｍｉｎ）を下回ったことを検出すると、上記演算判断回路８４が取り込み周期指定回路７１及びフレーム取り込みクロック発生回路７０を制御することで、フレームバッファ６８において動画の画質又はコマ落とし数を可変する。これによって、本実施例の送信装置は、映像データバッファメモリ８３に送る動画データの量を制御するようにしている。
【００２４】
なお、本実施例の送信装置では、動画データと共に、音声データをも扱うようにしている。
【００２５】
また、本実施例の送信装置には、音声及び動画の信号を除く信号をも送信可能であり、したがって、送信信号が音声及び動画の信号を除く信号であることを検出する第３の検出手段としての検出回路９３をさらに設けている。この検出回路９３において、送信信号が音声及び動画を除く信号であることを検出したときには、当該信号をデータ処理回路２６によってそのまま処理するようにもしている。なお、上記音声及び動画の信号を除く信号としては、例えばテキストデータやプログラムデータや数値データ，他のバイナリデータ等を挙げることができる。
【００２６】
さらに、本発明の送信装置の上記検出回路９３は、送信信号から所定の部分として例えば映像の重要な部分を検出する第４の検出手段としても動作し、当該第４の検出手段としての検出回路９３からの検出出力を、上記演算判断回路８４に送るようにもしている。当該演算判断回路８４においては、上記検出出力に基づいて、上記取り込み周期指定回路７１とフレーム取り込みクロック発生回路７０を制御することで、上記フレームバッファ６８に対して上記所定の部分のみはそのまま出力し、他の部分を伝送しないような読み出し制御を行う。
【００２７】
ここで、先ず、図１と図９〜図１０に示す本発明実施例の送信装置の具体的に説明に先立ち、本発明の送信装置が適用される情報処理通信システムのマルチメディアデータ対応の情報処理装置の基本機能と、該情報処理装置のモデルといわゆるアプリケーション・プログラミング・インタフェース（ＡＰＩ:application programming interface) と、情報処理通信システムにおける当該マルチメディア対応の情報処理装置の位置付け、当該情報処理の評価について、以下に項目に分けて説明する。
【００２８】
１．情報処理通信システムにおけるマルチメディア対応の情報処理装置の機能
この情報処理装置が実現する目標は、
(1) いろいろな制約はあるが、標準のパーソナルコンピュータやワークステーションにおいて構築し、既存のシステムとの親和性を保つこと、
(2) 音声や動画の通信や特有の処理は、当該情報処理装置にまかせ、クライアントプログラムはそのコントロールだけを行うこと、
(3) メディアデータの属性と、クライアントプログラムの目的に応じて柔軟に対処できること、
(4) プロセッサやネットワークなどのリソースの負荷の変動に対して、対応できること、
(5) モデルが単純なこと、
などである。
【００２９】
これらの要求から、情報処理装置は以下に述べるような機能を持つことが必要となる。
【００３０】
１．１ メディアタイプ
情報処理装置で扱うメディアデータとして、基本的には音声と動画がある。これらには、単位時間あたりのデータ量や生成時刻などの時間的な属性をつけ、これを情報処理装置での処理に利用する。例えば、データ幅８ビット、サンプリング周波数８ｋＨｚの音声データの場合には、単位時間は１／８０００（ｓｅｃ）、単位時間あたりのデータ量は１バイトという属性がつけられる。
【００３１】
１．２ 情報処理装置とメディアデバイス
情報処理装置は、複数の入力デバイスからのデータを、時間的な同期を取りながら、出力デバイスに出力する。
【００３２】
入力デバイスとしては、
(1) オーディオインタフェースやビデオ入力インタフェースなどのハードウェアデバイス、
(2) サウンドファイルや動画ファイルやムービーファイルのようなマルチメディアデータファイル、
(3) マルチキャストアドレス、
(4) クライアントプロセス
などをサポートする。
【００３３】
出力デバイスとしては、
(1) オーディオインタフェースやウィンドウなどのデバイス、
(2) マルチメディアファイル、
(3) マルチキャストアドレス、
(4) クライアントプロセス、
などをサポートする。
【００３４】
あるホストには情報処理装置はただ一つだけ存在し、それが直接に取り扱うデバイスは、そのホスト上にあることが必要である。入力デバイスと出力デバイスが別々のホストにあることを必要とする場合には、クライアントがそれぞれのホスト上のそれぞれの情報処理装置にアクセスして情報処理装置同志を接続させる。
【００３５】
１．３ メディアデータの転送と同期
マルチメディアシステムとしてユーザに提供する物の品質の評価規準として以下のものが考えられる。
例えば、
(1) 転送の遅れの許容限度、
(2) メディア間同期の許容限度、
(3) スループット、
(4) データの欠損が許される場合と許されない場合
である。
【００３６】
与えられた転送路で満足できる品質を得るために、データ量、圧縮方式、プロトコルやパケットサイズなどの転送の際の種々のパラメータをコントロールする。情報処理装置は、品質の評価基準に従って、メディア間同期を行う。
【００３７】
１．４ ネットワークプロトコール
上記情報処理装置が利用するマルチメディアデータのネットワークプロトコールは、品質の評価基準を考慮しながらフローなどを動的にコントロールできる必要がある。現状のネットワーク環境のＩＥＥＥ ８０２．３規格に準拠したいわゆるイーサ・ネット(Ethernet)や、国際標準化機構（ＩＳＯ）のＳＣ１３において提案されている光ファイバを用いた１００Ｍビット／秒トークンパッシング方式のファイバ・ディストリィビューテッド・データ・インタフェース（ＦＤＤＩ:fiber-distributed data interface)などネットワークデバイスは、分散環境上で個々に資源を取り合って共有しているため、あらかじめネットワーク資源を確保するようなサービスが難しい。しかし、現状のネットワーク環境との親和性を考えるとインターネット・プロトコール（ＩＰ:internet protocol) を利用する必要があり、今回はネットワークプロトコールとしていわゆるトランスミッション・コントロール・プロトコール（ＴＣＰ:transmission control protocol) と、コネクションレス形式のプロトコールであるいわゆるユーザ・データグラム・プロトコール（ＵＤＰ:user datdgram protocol)を利用した。
【００３８】
１．５ データの圧縮伸張
情報処理装置は、ソフトウェアまたはハードウェアによる、音声データや動画データの圧縮伸張機能を持つ。音声の圧縮方式としては、国際電信電話通信諮問委員会（ＣＣＩＴＴ）の音声符号化標準の勧告Ｇ．７１１，Ｇ．７２１，Ｇ．７２２，Ｇ．７２８などの規格をサポートする。また、画像の圧縮方式としては、国際電信電話通信諮問委員会（ＣＣＩＴＴ）のカラー静止画像符号化方式の国際標準化作業グループのいわゆるＪＰＥＧ(Joint Picture Expert Group)や、テレビ会議システム用映像符号化勧告Ｈ．２６１、カラー動画像符号化方式の国際標準化作業グループのＭＰＥＧ（Moving Picture Expert Group)などの方式がある。圧縮方式ごとに特徴があるので、用途によって使い分ける必要がある。
【００３９】
１．６ リソースのコントロール
情報処理装置は、複数のクライアントプログラムからの入出力要求を処理する機能をもつ。例えば、音声入力デバイスは一つしかないのに複数のクライアントから音声入力要求があった場合には、以下のような処理方法が考えられる。
(1) すべての要求元にコピーして配る。
(2) 先着の要求を優先し、後着の要求を拒絶する。
(3) クライアントを順次切り替える。この機能は、ウィンドウシステムでのウィンドウマネージャに相当するマルチメディアマネージャなどのプログラムが利用する。
【００４０】
１．７ 物理デバイスのコントロール
音声や動画などのマルチメディアデータを扱う場合には、ビデオカメラやビデオデッキのようないわゆるオーディオ・ビジュアル機器（ＡＶ機器）を接続することが必要になる。情報処理装置は、これらのコントロールのために、ＡＶ機器制御用の所定のプロトコールをサポートする。
【００４１】
２. 情報処理装置のモデルとＡＰＩ
２．１ ＡＶ機器が接続される情報処理装置のモデル
情報処理装置は、図２に示すように、クライアントそれぞれに対し１つの実行制御単位(AVobj）を生成する。クライアントがマルチメディアデータの入出力を行いたい場合には、次のような手順で情報処理装置に要求をだす。まず、実行制御単位（AVobj)において仮想的なメディアデバイス(AVdev) をオープンする。当該仮想的なメディアデバイス(AVdev) は物理的なデバイスではないため、排他制御や複数からのオープンなどが実現出来る。
【００４２】
また、図３に示すように、入力用に上記仮想的なメディアデバイス(AVdev) をオープンした実行制御単位(AVobj) と出力用にメディアデバイス(AVdev) をオープンした実行制御単位(AVobj) とを接続することによりマルチメディアデータの転送路が確保される。同一の実行制御単位(AVobj) でオープンされているデバイス間のメディアの同期は保証される。
【００４３】
さらに、図４のようにネットワークでつながれた異なるホスト上の情報処理装置において実行制御単位(AVobj) を生成し、接続することにより分散環境上のワークステーションにおいてマルチメディアデータの転送が行われる。
【００４４】
送信、受信側の実行制御単位(AVobj) がオープンするデバイス(AVdev) としてサウンドデバイスを用いると電話が実現できる。さらに、ビデオデバイスをオープンするとテレビ電話が実現できる。また、入力デバイスとして映画(Movie) ファイルを指定し、出力デバイスにサウンドデバイスとビデオデバイスをオープンすると映画(Movie) プレーヤとなる。このように入出力のデバイスを組み替えることにより各種マルチメディアアプリケーションを容易に作成することが可能となる。
【００４５】
２．２ 情報処理装置のＡＰＩ
情報処理装置のライブラリには、例えば次のものが用意されている。
【００４６】
int avs ＿new(char *hostname);
これは、ホスト名(hostname)上で起動されている情報処理装置において実行制御単位(AVobj) を生成する。エラーが発生した場合にはヌル(null)が返される。正常終了した場合には実行制御単位(AVobj) のＩＤ（識別情報）が返される。実行制御単位(AVobj) に対する命令はすべてこの実行制御単位(AVobj) のＩＤを用いて行なわれる。
【００４７】
int avs ＿open(int net, char *devname, int mode);
これは、デバイス(AVdev) をオープンする。引数は実行制御単位(AVobj) のＩＤ、デバイス名、モードである。
【００４８】
int avs ＿connect(int net1, int net2);
これは、２つの実行制御単位(AVobj) をポイント・ツウ・ポイント(point-to-point)接続する。これによって接続した実行制御単位(AVobj) の一方が以下に述べる関数（avs ＿transfer) によって転送状態になると、もう一方の実行制御単位(AVobj) がそのデータを受けとれるようになり自動的に受けとったデータを処理する。ひとつの送信実行制御単位(AVobj) に対して複数の受信実行制御単位(AVobj) を接続することが可能なため、１対多のデータ転送を処理できる。
【００４９】
int avs ＿transfer(int net, int dev, int length);
これは、実行制御単位(AVobj) の送信を制御する。デバイスＩＤとして０を指定すると、実行制御単位(AVobj) がオープンしたすべてのデバイスに対して有効となる。長さ(length)に正の数を指定するとその長さだけデータ転送が行なわれる（単位はｍｓｅｃ）。ここでゼロを指定すると、次の関数(av ＿transfer) が与えられるまで転送します。負の数を指定すると即座に停止する。
【００５０】
int avs ＿destroy(int net);
これは、関数(av ＿new)によって生成した実行制御単位(AVobj) を解放する。
【００５１】
int avs ＿interval(int net, int dev, int interval);
これは、転送インターバルの設定を行なう。単位はｍｓｅｃである。デバイスＩＤとしてゼロを設定すると、その実行制御単位(AVobj) でオープンされたすべてのデバイスに対して適応される。
【００５２】
int avs ＿resize(int net, int dev, int width, int height);
これは、ビデオデバイスに対してサイズ変更を要求する。サイズの単位はピクセルである。デバイスＩＤとしてゼロを設定すると、その実行制御単位(AVobj) でオープンされたすべてのビデオデバイスに対して適応される。
【００５３】
int avs ＿nettype(int net, char *type);
これは、実行制御単位(AVobj) 同志を接続するネットワークのタイプを設定する。現在のところ前記ＴＣＰとＵＤＰがサポートされている。これは関数(avs＿connect)を実行する以前に行なわなければならない。
【００５４】
int avs ＿fd(int net);
これは、クライアントと実行制御単位(AVobj) とのコントロール接続コネクションのファイル記述子を返す。
【００５５】
int avs ＿codec(int net, char *type, int quality);
これは、メディアデータの圧縮方式を指定する。ここでは、画像データに対して前記ＪＰＥＧの圧縮伸張のみがサポートされている。
【００５６】
その他、デバイス(AVdev) に対し直接メディアデータにアクセスするためのライブラリとして次のものがある。
例えば、
int avs ＿read(int net, int dev, int shmid, int size);
int avs ＿write(int net, int dev, int shmid, int size);
int avs ＿ioctl(int net, int dev, int request, int shmi);
である。
【００５７】
３．情報処理装置の実装
システム全体における情報処理装置の位置付けは次の図５のようになる。
３．１ スレッド(Thread)の利用
スレッドを用いると、複数プロセスを用いて実現するよりもコンテキスト・スイッチの時間が短く、各スレッド間でメモリなどの環境を共有でき、プログラミングが容易になる。情報処理装置を実現するにあたってスレッドのモデルへの割り当て方法として次の２通りが考えられる。
【００５８】
例えば、
機能毎にスレッドに割り当てる、
データストリーム毎にスレッドを割り当てる、
がある。
前者では画面入出力・音声入出力・ネットワークなどの機能毎にスレッドを割り当て、パイプラインを形成する方法であり、後者はメディアデータ毎の入力から出力までを行う処理にスレッドに割り当てる方法である。
【００５９】
機能毎にパイプラインを形成してもマルチプロセッサ環境下でないと利点はなく、複数のストリームにおいてストリーム単位のスケジュール・プライオリティ制御を行うには、後者が適しているため、今回の実装ではデータストリーム毎にスレッドを割り当てる方法も用いた。
【００６０】
３．２ ＴＣＰ／ＩＰの送信受信バッファと遅延
前記ＴＣＰ／ＩＰでは高信頼性を実現するため、パケットの順序付け、チェックサム、タイムアウトそして再転送を行い、オーバヘッドが大きくデータの転送遅延が問題となる。
【００６１】
したがって、ここでは送信および受信のためにバッファが用意されている。例えばワークステーションでは、デフォルトで８Ｋ（バイト）となっている。このバッファにデータがたまることによって遅延が生じる。例えば、解像度が１６０×１２０、深さ１６ビットの画面ならば、一画面でおよそ３８Ｋバイトとなり、送信側と受信側両方のバッファを合わせても１フレームもバッファリングされない。この場合にはバッファサイズを大きくすると転送効率は向上する。ところが、画像圧縮をかけて１／１０程の４Ｋバイト程度の大きさにすると両方のバッファ合わせておよそ４フレームが溜まることとなる。１秒間に５フレームのスピードで転送を行うならばこれだけで約１秒間の遅延となる。
【００６２】
しかし、逆にあまりバッファを小さくすると、転送効率が悪くなるため、ここにトレードオフがある。この送信、受信バッファのサイズは関数(setsockopt)で変更可能である。
【００６３】
４． 情報処理装置の評価
情報処理装置をワークステーション上に実装した場合の評価は以下のようになる。
【００６４】
４．１ 送受信バッファと転送遅延、効率
実際に送受信バッファのサイズと転送遅延、効率の測定をした例として、同一ネットワークに接続された２台のワークステーションの間で動画像データの転送を行なった。ここで、ワークステーションをイーサネットで接続し、解像度は１６０×１２０、１６ビットの深さの無圧縮とＪＰＥＧ圧縮画像で転送して測定し、１フレームのサイズは無圧縮でおよそ３８Ｋバイト、ＪＰＥＧ圧縮でおよそ５Ｋバイトとしている。
【００６５】
また、転送遅延は関数(timed(8))を用いて時計を合わせ、画像取り込みから転送を行いリモート側で表示を行うまでの時間を測定した。さらに、転送効率としては最大転送フレームレートを測定している。図６には無圧縮、図７にはＪＰＥＧ圧縮の画像の送受信バッファサイズと転送遅延、効率の関係を示す。
【００６６】
図６に示すように、無圧縮で１フレームの大きさが大きい場合には、送受信バッファに１フレームが入り切らないためバッファのサイズに対する転送遅延の差はほとんど変わらない。バッファサイズが８Ｋバイトの時には、転送遅延、効率ともに良い結果が現れる。この図６によれば、デフォルトの送受信バッファサイズが８ＫバイトということからもＴＣＰ／ＩＰでの転送がその場合に一番効率が良くなるようになっていることがわかる。
【００６７】
それに比べ、図７に示すＪＰＥＧ圧縮を行なった画像を転送する場合には、ソフトウェアでＪＰＥＧの圧縮伸張を行うため最大フレームレートは少ない。また、送受信バッファに数フレームが溜まってしまうため、バッファのサイズが大きいほど遅延は増大する。そこでＪＰＥＧなどの圧縮を行い画像データがネットワークのバンド幅より充分小さい場合には、送受信のバッファサイズを転送効率が下がらない程度に小さくすることにより、メディアデータの転送遅延を短縮できる。
【００６８】
４．２ 画面転送スピード
同様の環境で、画面サイズとフレームレートおよび転送遅延を測定している。まず、ネットワークとしてイーサネットを用いた場合は、次の表の結果が得られた。表１には１６ビットの深さの無圧縮画像、表２にはＪＰＥＧ圧縮した画像の転送最大フレームレートと遅延の性能を示す。
【００６９】
【表１】
【表２】
次に、ネットワークとしてサービス総合ディジタル網（ＩＳＤＮ:integrated service digitial network) の１Ｂ（６４Ｋ）を用いた場合の性能は表３のようになる。なお、ＩＳＤＭを用いた場合には、画像データを圧縮しないと最小の画面サイズ（８０×６０）においてもフレームレートが０．２（fps)となり、実用的でないため、深さ１６ビットの無圧縮画像の転送性能の評価は省いた。
【００７２】
【表３】
このような情報処理装置を用いることにより、画像と音声の取り込みや圧縮伸張、またネットワークプログラミングを意識することなく容易にマルチメディアアプリケーションが作成可能となった。
【００７４】
４．４ メディア間同期の実現
この情報処理装置では同期をとりメディアデータは、単一のストリームにインターリーブして転送している。また、ネットワークプロトコルとしてＴＣＰ／ＩＰを用いているため、パケットの順序は保証される。さらに、複数のメディアデータの取り込みを同時に行い、インターリーブしてデータ送信時に同期を保証できれば、データ受取側でも複数のメディアデータの同期はとれているものと仮定できる。実際この方法で単一ネットワーク上にて転送した音声と動画のメディアデータの同期は満足のいく結果となった。
【００７５】
４．５ 遅延との関係
上述の実装では、ネットワークプロトコルとしてオペレーティングシステムのＵＮＩＸで標準的なＴＣＰ／ＩＰを用いている。ここで、図８に示すように、メディアデータを直接送ることの出来る環境では、送信側と受信側のバッファの制御を情報処理装置が行うことができ、細かな流量制御が行える。
【００７６】
以下、図１に戻って、上述したようなことを具体的に実現する本発明実施例の送信装置について説明する。
【００７７】
図１において、マイクロホン１やビデオカメラ２からの音声信号や映像信号（動画信号）は、それぞれ対応するＡ／Ｄ変換回路６５，６６に送られて、Ａ／Ｄ変換される。Ａ／Ｄ変換回路６５からの音声データは、音声データ圧縮回路６７に送られ、ここで前述したように音声の圧縮方式として例えばＧ．７１１，Ｇ．７２１，Ｇ．７２２，Ｇ．７２８などのうちのいずれかを用いた圧縮が施される。また、上記Ａ／Ｄ変換回路６６からの映像データは、フレームバッファ６８を介して映像データ圧縮回路６９に送られ、ここで前述したように動画の圧縮方式として例えばＪＰＥＧ，Ｈ．２６１，ＭＰＥＧなどのうちのいずれかを用いた圧縮が施される。
【００７８】
これら圧縮回路６７，６９からの圧縮された音声データと映像データは、それぞれ対応して設けられた音声データバッファメモリ８２と映像データバッファメモリ８３に送られる。
【００７９】
また、バッファメモリ内容量測定回路８６は、音声データバッファメモリ８２と映像データバッファメモリ８３のそれぞれの書き込みアドレス及び読み出しアドレスから、当該メモリ８２と８３の内容量の測定を行い、その測定結果を演算判断回路８４に送る。
【００８０】
当該演算判断回路８４では、上記測定回路８６からの映像データバッファメモリ８３の内容量測定結果（後述する測定値Ｄ）に基づいて、映像データバッファメモリ８３の内容量が上記上限（後述するＤｍａｘ）を越えたことを検出したときに、その旨の信号を制御信号として上記取り込み周期指定回路９１に送る。
【００８１】
さらに、上記演算判断回路８４では、上記測定回路８６からのメモリ８３の内容量測定結果（後述する測定値Ｄ）が、映像データバッファメモリ８３の内容量が上記下限（後述するＤｍｉｎ）を下回るような場合には、映像が途切れるおそれがあるので、その旨（下限を下回った旨）の信号を制御信号として上記取り込み周期指定回路９１に送る。
【００８２】
当該取り込み周期指定回路７１は、上記制御信号に基づいて、フレーム取り込みクロック発生回路７０を制御する。当該フレーム取り込みクロック発生回路７０は、上記取り込み周期指定回路７１からの信号を受けると、例えばフレームバッファ６８において出力するコマ数を可変させるようなフレーム取り込みクロックを発生させる。このフレームバッファ６８において、例えばコマ落としを行う（若しくはコマ落とし数を増やす）ことで、送信する映像データの量を減らすことができ、コマ落としを行わないか若しくはコマ落とし数を減らすことで送信する映像データの量を増やすことができる。
【００８３】
すなわち、本実施例の送信装置ではでは、以下の図９に示すようなフローチャートの処理を行うことで、単位時間内に送信するコマ数を制御するようにしている。
【００８４】
この図９において、ステップＳ６１では、上記映像データのバッファメモリ８３の内容量の測定値Ｄを求める。なお、上記測定値Ｄは以下の式で求める。
Ｄ＝（バッファ読み出しアドレス）−（バッファ書き込みアドレス）
【００８５】
次のステップＳ６２では、当該測定値Ｄと映像データのバッファメモリ８３の内容量の上限値Ｄｍａｘとから、Ｄ＞Ｄｍａｘを判定し、ノーと判定した場合にはステップＳ６３に進み、逆にイエスと判定した場合にはステップＳ６４に進む。
【００８６】
ステップＳ６４では、上記取り込み周期指定回路７１が、フレーム取り込みクロック発生回路７０に対して、フレームバッファ６８におけるフレームの取り込みクロックの周期をＰだけ長くさせるように制御する。このステップＳ６４の後はステップＳ６１に戻る。なお、このＰの値は、例えば１％とする。
【００８７】
一方、上記ステップＳ６２においてノーと判断された場合のステップＳ６３では、上記測定値Ｄと映像データのバッファメモリ８３の内容量の下限値Ｄｍｉｎとから、Ｄ＜Ｄｍｉｎを判定する。当該ステップＳ６３において、ノーと判定した場合にはステップＳ６１に戻り、イエスと判断した場合にはステップＳ６５に進む。
【００８８】
ステップＳ６５では、上記取り込み周期指定回路７１が、フレーム取り込みクロック発生回路７０に対して、フレームバッファ６８におけるフレームの取り込みクロックの周期をＰだけ短くさせるように制御する。このステップＳ６５の後はステップＳ６１に戻る。なお、このＰの値は、例えば１％とする。
【００８９】
これにより、本実施例の送信装置では、映像データバッファメモリ８３の内容量が多くなって当該映像データバッファメモリ８３における入力から出力までの時間遅れ及び時間のずれが適正な値を越える、すなわち映像データバッファメモリ８３の内容量の測定値Ｄが上限値Ｄmaxを越えるようになっても、当該時間遅れ及び時間のずれを適正な値に回復する、すなわち上記測定値Ｄを上限値Ｄmaxまでの範囲内に戻すことができ、また、映像データバッファメモリ８３の内容量が少なくなって上記測定値Ｄが下限値Ｄminを下回ることにより映像が途切れるおそれがでてきても、当該映像の途切れを防ぐことができるようになる。
【００９０】
上述のようにして映像データバッファメモリ８３から読み出された圧縮された映像データと、音声データバッファメモリ８２から読み出された圧縮された音声データとは、マルチプレクサ５によってマルチプレクスされ、その後ネットワーク送信部７に送られ、当該ネットワーク送信部７から例えばイーサネットなどのネットワーク８を経て、受信側のネットワーク受信部１１に送られる。
【００９１】
また、本実施例の送信装置の入力端子８９には、送信信号として音声及び動画の信号を除く信号である例えばテキストデータやプログラムデータ，数値データ，他のバイナリデータのような信号が入力される。このデータは、検出回路９３に送られる。当該検出回路９３においては、上記音声及び動画を除くデータを検出するとそのまま当該データを出力して、データ処理回路９４に送る。
【００９２】
当該データ処理回路９４では、供給されたデータに対する所定の処理としては、例えば誤り訂正符号の付加等の処理を行い、その後、データバッファメモリ９５に送る。当該データバッファメモリ９５では、データを一旦蓄えた後に、上記マルチプレクサ５に送る。
【００９３】
このように、本実施例の送信装置においては、上記検出回路９３を有し、送信信号として前記音声や動画を除く他のデータも送信できるようになっている。
【００９４】
さらに、本実施例の送信側では、上記Ａ／Ｄ変換回路６６からの映像データも、上記検出回路９３に送られる。
【００９５】
このときの上記検出回路９３では、映像データに対しては例えば人間の視覚特性を考慮して当該映像データから特に視覚的に重要な映像部分を検出したり、映像内容で特に重要な部分を検出したりする。この検出回路９３からは、上記映像データに対応する検出信号が出力され、この検出信号が上記演算判断回路８４に送られる。
【００９６】
上記演算判断回路８４では、上記検出回路９３から上記映像データ用の制御信号を受けると、前述したフレームバッファ６８における伝送コマ数の可変制御を行う際に、上記検出回路９３での検出信号に対応した映像部分については伝送されるような制御、すなわち、上記検出信号に対応する映像の重要な部分については上記フレームバッファ６８からそのままデータを読み出して映像データ圧縮回路６９に送るように制御する。逆に、映像の重要でない部分に対しては、映像データバッファメモリ８３の内容量に応じて、前記伝送コマ数の制御が行われる。
【００９７】
これにより、本実施例の送信装置では、映像の重要な部分を除く部分についてはフレームバッファ６８での伝送コマ数の制御操作が行われることで、映像データバッファメモリ８３の入力から出力までの時間遅れを適正値に回復させることができ、また、上記映像の重要部分についてはコマ落としがなされないために、送信される映像は、高品質を保つことができるようになる。
【００９８】
次に、本実施例の受信側において、上述したような送信データを受信するネットワーク受信部１１によって受信されたデータは、分離回路１２によって上記圧縮された音声データと映像データとに分離され、それぞれ対応する音声データバッファメモリ（ＦＩＦＯメモリ）１３と映像データバッファメモリ（ＦＩＦＯメモリ）１４に送られる。
【００９９】
上記音声データバッファメモリ１３や映像データバッファメモリ１４から読み出された音声データと映像データは、それぞれ対応する伸張処理及びＤ／Ａ変換を施す伸張Ｄ／Ａ変換回路１８，１９に送られる。これら伸張Ｄ／Ａ変換回路１８，１９では、前記Ａ／Ｄ変換圧縮回路３，４での各圧縮処理に対応する伸張処理がそれぞれ施され、その後Ｄ／Ａ変換して出力する。
【０１００】
上記伸張Ｄ／Ａ変換回路１８からの音声信号はスピーカ１９に送られ、上記伸張Ｄ／Ａ変換回路１９からの映像信号はモニタディスプレイ２４に送られる。
【０１０１】
また、上記分離回路１２に供給された受信信号は、当該分離回路１２を介して検出回路２５にも送られる。検出回路２５では、上記受信信号から音声及び動画の信号を除く信号である例えば上記テキストデータやプログラムデータ，数値データ，他のバイナリデータのようなの信号を検出する。
【０１０２】
この検出回路２５において上記音声や動画の信号を除くデータを検出すると、当該検出回路２５からは、上記分離回路１２に対して検出信号が出力される。上記分離回路１２は、上記検出回路２５からの検出信号が供給されると、上記受信信号から当該検出信号に応じたデータのみを分離して、データ処理回路２６に送る。
【０１０３】
当該データ処理回路２６では、供給されたデータに対して所定の処理を施した後、出力端子から出力する。なお、上記所定の処理としては、例えば誤り訂正処理等を挙げることができる。
【０１０４】
このように、本実施例の受信側においては、上記検出回路２５を有し、上記分離回路１２が当該検出回路２５からの検出信号に応じて、受信信号から音声や動画以外のデータを分離することによって、上記音声や動画を除くデータについての処理を可能となっている。
【０１０５】
また、上記図１の構成では、映像のコマ落とし数を可変することで、上記映像データバッファメモリ８３における入力から出力までの時間遅れ及び時間のずれを適正な値に回復したり、映像の途切れを防ぐようにしているが、例えば、画像の画質を選択することでも同様のことを行うことができる。
【０１０６】
すなわち、この画質を選択する場合には、例えば、フレームバッファ６８において取り込む各画素データを間引くことで送信するデータ量を減らしたり、逆に間引きを行わないようにすることで画質を確保する。この場合、受信側では、画素データを間引いたときには、例えば補間等の処理を行って画像を復元する。
【０１０７】
次に、本発明の他の実施例の構成を図１０に示す。
【０１０８】
この図１０において、送信側ホストコンピュータには、モニタディスプレイ４０とマイクロホン４１とビデオカメラ４２が接続され、またネットワーク４３を介して受信側ホストコンピュータと接続される。
【０１０９】
当該送信側ホストコンピュータにおいて、ＣＰＵ３０は、メインメモリ３１に保持されているプログラムデータを用いて各部を制御すると共に、上述した図１の各バッファメモリ内容量測定回路８６，演算判断回路８４，取り込み周期指定回路７１，フレーム取り込みクロック発生回路７０，検出回路９３，データ処理回路９４等の機能を備えているものである。
【０１１０】
ビデオカメラ４２からの映像信号は、Ａ／Ｄ変換圧縮処理部３８によってＡ／Ｄ変換されると共に前述したような圧縮処理が施され、バッファメモリ３４に一時蓄えられる。このバッファメモリ３４は、前述の各実施例の映像データバッファメモリ８３として機能する部分と共に、前記フレームバッファ６８としても機能する部分をも有するしている。ただし、前述のフレームバッファ６８には圧縮前の映像データが取り込まれる例を挙げているが、この図１０に示すバッファメモリ３４の例では圧縮後の映像データを取り込むようにしている。
【０１１１】
一方、マイクロホン４１からの音声信号は、Ａ／Ｄ変換圧縮処理部３７によってＡ／Ｄ変換されると共に前述したような圧縮処理が施され、バッファメモリ３３に一時蓄えられる。このバッファメモリ３３は、前述の図１の音声データバッファメモリ８２としての機能を有する。
【０１１２】
また、フレームメモリ３２には、例えばＣＰＵ３０によって形成された映像フレームデータや、ビデオカメラ４２によって撮影された映像に基づく映像フレームデータが記憶される。当該フレームメモリ３２からの映像フレームデータは、ディスプレイインタフェース３６を介してモニタディスプレイ４０に送られて表示される。
【０１１３】
さらに、上記バッファメモリ３３，３４に蓄えられた圧縮された音声データと映像データは、例えばＣＰＵ３０によってマルチプレクスされた後にバッファメモリ３５に一旦蓄えられてから読み出される。なお、このバッファメモリ３５は図１のデータバッファメモリ９５としての機能も有している。当該バッファメモリ３５から読み出されたデータは、ネットワークインタフェース３９に接続されたネットワーク４３を介して、受信側ホストコンピュータに送られる。
【０１１４】
次に、受信側ホストコンピュータには、モニタディスプレイ６１とスピーカ６２が接続され、さらにネットワーク４３を介して送信側ホストコンピュータと接続される。
【０１１５】
当該受信側ホストコンピュータにおいて、ＣＰＵ５２は、メインメモリ５３に保持されているプログラムデータを用いて各部を制御したり、また、各種の演算を行う。
【０１１６】
上記ネットワーク４３を介して上記送信側ホストコンピュータから送られてきたデータは、ネットワークインタフェース５０を介してバッファメモリ５１に一旦蓄えられた後、読み出される。
【０１１７】
当該バッファメモリ５１から読み出された受信データからは、例えばＣＰＵ５２によって上記圧縮された音声データと映像データとが分離され、それぞれ対応するバッファメモリ５４，５５に送られる。
【０１１８】
バッファメモリ５４に送られた圧縮された映像データは、当該バッファメモリ５４から読み出されてデータ伸張処理部５６に送られて上記送信側ホストコンピュータでの圧縮に対応する伸張処理がなされる。当該伸張された映像データは、フレームメモリに蓄えられてフレームとなされ、ディスプレイインタフェース５８を介してモニタディスプレイ６１に送られて表示される。
【０１１９】
また、バッファメモリ５５に送られた圧縮された音声データは、当該メモリ５５から読み出されてデータ伸張処理部５９に送られて上記送信側ホストコンピュータでの圧縮に対応する伸張処理がなされる。当該伸張された音声データは、Ｄ／Ａ変換処理部６０によってアナログの音声信号に変換された後、スピーカ６２に送られる。
【０１２０】
上述したように、本発明の各実施例装置によれば映像データバッファ８３の内容量の測定値Ｄが、当該バッファ８３の内容量の上限値Ｄｍａｘを越えたことを検出すると、当該映像データバッファメモリ８３における映像データの取り込み時間と送信時間との差を上限値Ｄｍａｘと下限値Ｄｍｉｎとの間とするために、画質又は単位時間内の送信コマ数を制御するようにしているため、上記映像データバッファメモリ８３での入力から出力までの時間遅れ及び時間のずれを適正な値に回復し、また映像の途切れを防ぐことを可能としている。
【０１２１】
また、本実施例の送信装置においては、検出回路９３を設け、この検出回路９３によって受信信号が動画及び音声を除くデータであることを検出したときには、データ処理回路９４においてそのまま処理するようにしたことで、送信信号が例えばテキストデータ，プログラムデータ，数値データ，他のバイナリデータなどである場合に、これらデータの内容が変化することを防いでいる。
【０１２２】
さらに、本実施例の送信装置においては、検出回路９３によって送信信号から映像において特に重要な部分を検出したときには演算判断回路８４によって取り込み周期指定回路７１及びフレーム取り込みクロック発生回路７０を制御し、これら重要な部分を除く他の部分についてはコマ落としを行うように上記フレームバッファ６８を制御することで、映像データバッファメモリ８３の入力から出力までの時間遅れを適正値に回復させるようにし、上記特に重要な部分についてはそのまま処理することで、この部分の信号については破棄されることを防いでいる。
【０１２３】
【発明の効果】
上述のように本発明の送信装置においては、信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号を送信する実時間の送信を行う際に、動画信号を外部から取り込み、この取り込まれた動画信号をバッファ手段にバッファリングし、バッファ手段のバッファメモリ内容量Ｄを測定し、バッファ手段によりバッファリングされた動画信号を送信し、測定されたバッファメモリ内容量Ｄが、上記取り込み時間と上記送信する時間との差の上限としての第１の時間をバッファメモリ内容量に換算して得られる上限値Ｄmax内であることを検出し、測定されたバッファメモリ内容量Ｄが、上記取り込み時間と上記送信する時間との差の下限としての第２の時間をバッファメモリ内容量に換算して得られる下限値Ｄmin内であることを検出し、測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、画質又は単位時間内の送信コマ数を制御することにより、バッファメモリ内容量を上記上限値と上記下限値との間となすことができ、これによってバッファ手段の入力から出力までの時間遅れを適正値に回復させることを可能としている。
【０１２４】
さらに、本発明の送信装置においては、送信時に信号の信号の取り込み時間と送信する時間との差が第２の時間内を下回ったことを検出したときには、送信する動画の画質を上げるか又はコマ落とし数を無くす（若しくは少なくする）ことで、映像の途切れを防ぐことが可能となる。
【０１２５】
また、本発明の送信装置においては、第３の検出手段によって送信信号が動画の信号を除く信号であることを検出したときには、そのまま処理することで、送信信号が例えばテキストデータなどである場合に、データの内容が変化することを防止できる。
【０１２６】
さらに、本発明の送信装置によれば、第４の検出手段を設け、この第４の検出手段によって送信信号の所定の部分を検出したときには、その所定の部分を除く他の部分の送信を中止することで、バッファ手段の入力から出力までの時間遅れを適正値に回復させることができ、その所定の部分についてはそのまま処理することで、この所定の部分の信号については送信可能とする。
【図面の簡単な説明】
【図１】本発明実施例の送信装置及びこれに対応する受信側の装置の概略構成を示すブロック回路図である。
【図２】本発明装置が適用される情報処理通信システムの情報処理装置のモデルを示す図である。
【図３】マルチメディアデータの転送について説明するための図である。
【図４】ネットワークでつながれたホスト間のマルチメディアデータの転送について説明するための図である。
【図５】システム全体における情報処理装置の位置付けについて説明するための図である。
【図６】無圧縮の場合の送受信バッファサイズと転送遅延、効率の関係を示す特性図である。
【図７】ＪＰＥＧ圧縮の画像の送受信バッファサイズと転送遅延、効率の関係を示す特性図である。
【図８】情報処理装置と遅延との関係を説明するための図である。
【図９】本実施例装置における映像データバッファメモリの内容量測定と伝送コマ数制御についての処理を説明するためのフローチャートである。
【図１０】本発明の他の実施例の送信側ホストコンピュータと受信側ホストコンピュータの概略構成を示すブロック回路図である。
【図１１】従来の送信装置と送信装置の概略構成を示すブロック回路図である。
【符号の説明】
１，４１・・・マイクロホン
２，４２・・・ビデオカメラ
５・・・マルチプレクサ
６・・・データバッファメモリ
７・・・ネットワーク送信部
８・・・ネットワーク
９・・・ネットワーク受信部
１２・・・分離回路
１３，８２・・・音声データバッファメモリ
１４，８３・・・映像データバッファメモリ
１８・・・音声データの伸張Ｄ／Ａ変換回路
１９・・・ビデオデータの伸張Ｄ／Ａ変換回路
２４，４０，６１・・・モニタディスプレイ
２５，９３・・・検出回路
２６，９４・・・データ処理回路
２７，６２・・・スピーカ
３０，５２・・・ＣＰＵ
３１，５３・・・メインメモリ
３２，５７・・・フレームメモリ
３３，３４，３５，５１，５４，５５・・・バッファメモリ
３６，５８・・・ディスプレイインタフェース
３７・・・音声データＡ／Ｄ変換圧縮部
３８・・・動画データＡ／Ｄ変換圧縮部
５６・・・音声データ用データ伸張部
５９・・・映像データ用データ伸張部
６０・・・音声データＤ／Ａ変換部
６５，６６・・・Ａ／Ｄ変換回路
６７・・・音声データ圧縮回路
６８・・・フレームバッファ
６９・・・映像データ圧縮回路
７０・・・フレーム取り込みクロック発生回路
７１・・・取り込み周期指定回路
８４・・・演算判断回路
８６・・・バッファメモリ内容量測定回路
９５・・・データバッファメモリ
Claims (4)
- 信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号をパケット化して送信する実時間の送信装置であって、
動画信号を外部から取り込む取り込み手段と、
上記取り込み手段により取り込まれた動画信号を圧縮符号化する圧縮符号化手段と、
上記圧縮符号化手段からの出力信号をバッファリングするバッファ手段と、
上記バッファ手段のバッファメモリ内容量Ｄを測定する内容量測定手段と、
上記バッファ手段によりバッファリングされた動画信号を送信する送信手段と、
上記動画信号の上記取り込み手段による取り込み時間と上記送信手段により送信する時間との差が上記内容量測定手段により測定されたバッファメモリ内容量Ｄに予め対応付けられ、上記時間の差の上限としての第１の時間がバッファメモリ内容量の上限値Ｄ max に、上記時間の差の下限としての第２の時間がバッファメモリ内容量の下限値Ｄ min にそれぞれ予め対応付けられ、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmax内であることを検出する第１の検出手段、及び上記バッファメモリ内容量Ｄが上記下限値Ｄmin内であることを検出する第２の検出手段と、
上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、上記バッファメモリ内容量を上記上限値と上記下限値との間となすために、上記取り込み手段から出力する単位時間内のコマ数を制御する制御手段と
を有することを特徴とする送信装置。 - 上記信号の外部から送信装置への取り込み周期を指定する取り込み周期指定手段を設け、
上記制御手段は、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えた（Ｄ＞Ｄmax）とき、上記取り込み周期指定手段の取り込み周期を長くさせるように制御し、上記内容量測定手段により測定されたバッファメモリ内容量Ｄが上記下限値Ｄminを下回った（Ｄ＜Ｄmin）とき、上記取り込み周期指定手段の取り込み周期を短くさせるように制御することを特徴とする請求項１記載の送信装置。 - 上記外部から送信装置への信号の取り込みの際に取り込む各画素データを間引いたり間引きを行わないことで画質を選択する画質選択手段を設け、
上記制御手段は、上記内容量測定手段により測定されたバッファメモリ内容量Ｄに応じて上記画質選択手段による画質の選択を制御することを特徴とする請求項１記載の送信装置。 - 信号の外部から送信装置への取り込み時間と取り込まれて処理された信号を送信する時間との差を所定時間以内となして動画信号を含むマルチメディアデータの信号をパケット化して送信する実時間の送信方法であって、
動画信号を外部から取り込む取り込み工程と、
上記取り込み工程により取り込まれた動画信号を圧縮符号化する圧縮符号化工程と、
上記圧縮符号化工程により圧縮符号化された出力信号をバッファ手段にバッファリングする工程と、
上記バッファ手段のバッファメモリ内容量Ｄを測定する内容量測定工程と、
上記バッファ手段によりバッファリングされた動画信号を送信する送信工程と、
上記動画信号の上記取り込み手段による取り込み時間と上記送信手段により送信する時間との差が上記内容量測定手段により測定されたバッファメモリ内容量Ｄに予め対応付けられ、上記時間の差の上限としての第１の時間がバッファメモリ内容量の上限値Ｄ max に、上記時間の差の下限としての第２の時間がバッファメモリ内容量の下限値Ｄ min にそれぞれ予め対応付けられ、上記内容量測定工程により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmax内であることを検出する第１の検出工程、及び上記バッファメモリ内容量Ｄが上記下限値Ｄmin内であることを検出する第２の検出工程と、
上記内容量測定工程により測定されたバッファメモリ内容量Ｄが上記上限値Ｄmaxを越えたことを検出したときに、上記バッファメモリ内容量を上記上限値と上記下限値との間となすために、上記取り込み工程から上記圧縮符号化工程に出力する単位時間内のコマ数を制御する制御工程と
を有することを特徴とする送信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31558393A JP3799070B2 (ja) | 1993-12-15 | 1993-12-15 | 送信装置及び方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31558393A JP3799070B2 (ja) | 1993-12-15 | 1993-12-15 | 送信装置及び方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07170504A JPH07170504A (ja) | 1995-07-04 |
| JP3799070B2 true JP3799070B2 (ja) | 2006-07-19 |
Family
ID=18067103
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP31558393A Expired - Fee Related JP3799070B2 (ja) | 1993-12-15 | 1993-12-15 | 送信装置及び方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3799070B2 (ja) |
Families Citing this family (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10229420A (ja) | 1997-02-17 | 1998-08-25 | Matsushita Electric Ind Co Ltd | 通信システム |
| JP3460625B2 (ja) | 1999-06-02 | 2003-10-27 | 日本電気株式会社 | テレビ電話装置およびテレビ電話装置における情報処理方法 |
| US6721280B1 (en) * | 2000-04-19 | 2004-04-13 | Qualcomm Incorporated | Method and apparatus for voice latency reduction in a voice-over-data wireless communication system |
| JP2005012729A (ja) * | 2003-06-23 | 2005-01-13 | Nanao Corp | 情報提供装置 |
| JP5295120B2 (ja) * | 2006-12-06 | 2013-09-18 | テレフオンアクチーボラゲット エル エム エリクソン（パブル） | ジッタバッファ制御 |
-
1993
- 1993-12-15 JP JP31558393A patent/JP3799070B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH07170504A (ja) | 1995-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6278478B1 (en) | End-to-end network encoding architecture | |
| JP3715332B2 (ja) | 通信システム、受信装置及び方法 | |
| US8160129B2 (en) | Image pickup apparatus and image distributing method | |
| US6195680B1 (en) | Client-based dynamic switching of streaming servers for fault-tolerance and load balancing | |
| JP4965059B2 (ja) | ビデオストリームの切り替え | |
| JP2003524909A (ja) | マルチメディアネットワーク・インタフェースを達成する方法及び装置 | |
| JP4822866B2 (ja) | インターネットプロトコルを用いたシリアルバスを介したデータ電送を実行するための方法及び当該方法を利用するための装置 | |
| JP2003504897A (ja) | 電話回線による高速映像伝送 | |
| US20040073953A1 (en) | Audio/video apparatus for use with a cable television network | |
| US7502417B2 (en) | Data transmission device and method | |
| JPH07170292A (ja) | 送信装置 | |
| Lehman et al. | Experiments with delivery of HDTV over IP networks | |
| JP3799070B2 (ja) | 送信装置及び方法 | |
| CA2344595A1 (en) | System and method for simultaneous viewing and/or listening to a plurality of transmitted multimedia streams through a centralized processing space | |
| JPH07170503A (ja) | 受信装置 | |
| JPH07170502A (ja) | 受信装置 | |
| JPH07170291A (ja) | 送信装置 | |
| JP2000295597A (ja) | メディアデータ受信および送信装置 | |
| JPH10164553A (ja) | 映像サーバ及びクライアント及び制御方法及び記憶媒体 | |
| US6947447B1 (en) | Image communication apparatus, image communication method and recording medium which stores the sound and image | |
| JP2002344937A (ja) | 品質制御保証方法及び品質制御保証装置並びにネットワーク接続装置 | |
| Engman | High Performance Video Streaming on Low End Systems | |
| KR100639872B1 (ko) | Ｎａｔｉｖｅ ＡＴＭ ＡＰＩ를 이용한 음성데이터 전송 방법 | |
| JP2003536326A (ja) | 対話型処理システム | |
| KR100327226B1 (ko) | Ieee1394버스를이용한화상전화데이터전송방법및그단말장치 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040203 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040405 |
|
| A911 | Transfer of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040409 |
|
| A912 | Removal of reconsideration by examiner before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20050930 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060116 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060424 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090428 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100428 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |