JP4432257B2 - 画像音声情報通信システム - Google Patents
画像音声情報通信システム Download PDFInfo
- Publication number
- JP4432257B2 JP4432257B2 JP2000376840A JP2000376840A JP4432257B2 JP 4432257 B2 JP4432257 B2 JP 4432257B2 JP 2000376840 A JP2000376840 A JP 2000376840A JP 2000376840 A JP2000376840 A JP 2000376840A JP 4432257 B2 JP4432257 B2 JP 4432257B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- information
- transmission
- audio
- voice
- 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
- Transmission Systems Not Characterized By The Medium Used For Transmission (AREA)
- Telephonic Communication Services (AREA)
Description
【発明の属する技術分野】
本発明は、ディジタル化された画像や音声の情報を、遠隔地にある携帯型情報伝送端末装置と管理局通信装置との間で伝送するための画像音声情報通信システムに関わるものである。
【0002】
【従来の技術】
現在、携帯電話(PDC:Portable Digital Cellular)や、PHS(Personal Handy-Phone System:登録商標)の普及によって、モバイル通信が華やかである。その様な中に於いて、これらの通信媒体を利用し、画像データや音声データを圧縮して遠隔地にある情報処理装置(パソコンなど)に伝送し、現場の状況を報告するための携帯型情報伝送端末装置が知られている。
【0003】
この携帯型情報伝送端末装置の主たる伝送情報は画像データと音声データであり、現場の映像を画像処理して伝送する機能および現場と音声による情報交換を行うのが一般的である。この携帯型遠隔画像情報伝送端末装置の使用形態を図16に示す。
【0004】
同図に於いて、100が入力された画像情報と音声情報を圧縮処理して伝送するための携帯型情報伝送端末装置の本体、200が伝送された画像情報を受信して処理するための管理局側の情報処理装置(パソコンなど)の本体である。
【0005】
また、同図に於いて、301は、画像情報を入力するためのカメラ装置(ビデオ・カメラや、ディジタル・スチル・カメラなど)、302は音声情報を入力するためのマイクロフォン、303は管理局側から送られてきた音声情報を音声として出力するためのスピーカである。ここでは、302のマイクロフォンと303のスピーカは、一体になって頭部に装着できるヘッドセットを例に採っている。また、100aは、100の情報伝送端末装置に付属されている、プレス・トーク用のスイッチであり、このスイッチを押下している間、端末側の音声を伝送することが可能とするものである。
【0006】
また、同図に於いて、400は情報の伝送媒体である通信網(PDC、PHS、アナログ電話、LANなど)を示す。また、501は受信した画像情報を表示するための画像出力装置(CRT、LCD、ビデオ・モニタなど)、502は管理局側の音声を入力するためのマイクロフォン、503は端末側から送られてきた音声を再生するためのスピーカである。こちらも、502のマイクロフォンと503のスピーカは、一体になって頭部に装着できるヘッドセットを例に採っている。504は受信データを格納したり出力したりする情報のストレージ(ハード・ディスクなど)である。
【0007】
図16に於いて、遠隔地に赴いた操作員は、図に示すような体勢で、301のカメラから画像情報を入力し、これを100の携帯型遠隔情報伝送端末に於いて、圧縮処理して伝送する。この情報は、400の伝送媒体(通信網)によって遠隔地に送られるので、管理局側では、これを通信網を介して受信し、200の情報処理装置にて伸長処理して元の画像情報に再生する。さらに管理局側では、この情報を501の表示装置に表示したり、データ・ベース・ソフトウェアなどを利用して504のデータ・ストレージに情報を格納して管理する。
【0008】
この様な基本操作の補助的機能として、この装置では、現場と管理局との間で、音声情報の交換ができる。
【0009】
まず、現場の操作員は、100aのプレス・トーク・スイッチを押しながら、302のマイクロフォンに向かって声を発すると、この間(スイッチを押下している間)の音声情報が、携帯型遠隔情報伝送端末に於いて、圧縮処理されて伝送される。200の管理局側では、この音声データを受け取ると、伸長処理を施して、元の音声データを再生し、503のスピーカに出力する。これによって、現場の操作員の音声が、管理局側の操作員に伝えられる。
【0010】
次に、管理局側の操作員は、200の情報処理装置の操作を行い、502のマイクロフォンに向かって声を発すると、この操作の間の音声情報が情報処理装置内で圧縮処理されて端末装置に向けて送信される。100の情報伝送端末装置側では、通信網からこの音声データを受け取ると、伸長処理を施して、元の音声データを再生し、303スピーカに出力する。これによって、管理局側の操作員の音声が、現場側の操作員に伝えられる。
【0011】
この相互の通話により、現場の状況の詳細な報告や、採りたい画像の指示などが的確に行える。
【0012】
次に、図17に、上記の携帯型情報伝送端末装置の機能的構成例を示す。
【0013】
同図に於いて、100は、破線で囲まれた全体を指し、携帯型遠隔情報伝送端末の全体である。以下、携帯型遠隔情報伝送端末は、単に情報伝送端末と略す。
【0014】
また、301は画像情報を入力するための入力装置(CCDカメラなど)であり、110は、CCDカメラなどから与えられるビデオ信号をディジタル化して入力する画像入力ディジタル化処理機能(ビデオ・デコード機能)、111は入力された生の画像データを一時的に貯えるための画像データ入力バッファ機能、112は、画像データのデータ量を縮小するために圧縮処理を行うための画像データ圧縮処理機能、113は圧縮された画像データを送信するために、一時的に格納しておくための画像データ送信バッファ機能である。
【0015】
一方、同図に於いて、302は、操作者の発する声を電気信号として入力するためのマイクロフォン、120は取り込まれた音声信号をディジタル化して取り込むための音声入力ディジタル化処理機能、121は入力された音声データを一時的に貯えるための音声データ入力バッファ機能、122は音声データのデータ量を縮小するために圧縮処理を行うための音声データ圧縮処理機能、123は圧縮された音声データを送信するために、一時的に格納しておくための音声データ送信バッファ機能である。
【0016】
また、130は、113に貯えられた送信すべき画像データや、123に貯えられた音声データを通信網に向けて送信するための通信手段送信処理機能である。 更に、400は情報の伝送媒体である通信網を示す。
【0017】
次に、同図に於いて、100aは、情報伝送端末に於ける音声伝送(入力、圧縮、送信)処理を行うべき期間を示すために、操作員が押下するための、プレス・トーク・スイッチ、160はそのキー入力の処理機能、160aは、キーの押下時と開放時を、170の装置統括制御機能に知らせるための割り込み信号である。170は装置全体の統括管理を行うための装置統括制御機能であり、マイクロプロセッサがこの任に当たる。
【0018】
更に、同図に於いて、140は、管理局側から通信網を介して送られてきた情報を通信網から受信し、情報装置側に取り込むための通信手段受信機能である。また、150は通信網より受信した音声情報データ(圧縮加工されたデータ)を一時的に蓄積するための音声データ受信バッファ、151は蓄積された音声データを伸長処理し、元の画像データのサイズに復元するための音声データ伸長処理機能、152は復元された音声を再生出力するためにそのデータを一時的に格納しておくための音声データ出力バッファ機能、153は、音声を実際のスピーカなどから出力するための音声出力アナログ変換処理機能である。303は、音声出力用のスピーカである。
【0019】
ここで、図17に示した機能構成例を実際に実現するためのハードウェア回路の構成例を図18に示す。この例は、図17に於ける、112「画像データ圧縮処理機能」、122「音声データ圧縮処理機能」、151「音声データ伸長処理機能」の各機能を、全て、性能の高いマイクロプロセッサ(CPU)でソフトウェア的に実現する場合を示している。
【0020】
図18に於いて、301の入力装置は、CCDを利用したビデオ・カメラや、ディジタル・カメラなどが挙げられる。302は、一般的な音声入力用マイクロフォン、303は音声出力用スピーカである。
【0021】
400は情報の伝送媒体である通信網であって、携帯電話(PDC:Portable Digital Cellular)網や、PHS(Personal Handy-Phone System)網、アナログ一般電話回線網、LAN(Local Area Network)網などがこれに当たる。
【0022】
同図に於いて、100は、破線で囲まれた全体を指し、情報伝送端末の全体である。
【0023】
110は、画像入力ディジタル化回路であり、ビデオ・デコーダLSIなどのハードウェアによって実現される。111は、画像データ入力バッファ・メモリである。
【0024】
120は、音声入力ディジタル化回路であり、音声A/D(Analog/Digital)変換器とコード化用のハードウェア(LSIなど)によって実現される。121は、音声データ入力バッファ・メモリである。
【0025】
130は、情報の伝送媒体である通信網との通信インターフェース回路であり、送受信の双方向の物理階層処理を行う。
【0026】
152は、音声データ出力バッファ・メモリであり、153は、音声出力アナログ変換処理回路であって、音声コードをデコードするための専用ハードウェア(LSIなど)と音声D/A(Digital/Analog)変換器とによって実現される。
【0027】
更に、この装置の統括制御を行うのが、170の制御CPU(マイクロプロセッサなど)である。このCPUの実行環境として、171のプログラム・メモリ(ROM)および172のワーク・メモリ(RAM)などが必要である。これら装置全体のデータを授受するための経路が、170aのCPUバスである。
【0028】
また、同図に於いて、100aが、情報伝送端末に於ける音声伝送(入力、圧縮、送信)処理を行うべき期間を示すために、操作員が押下するための、プレス・トーク・スイッチ、160はそのキー入力の処理回路、160aは、キーの押下時と開放時を、170のCPUに知らせるための割り込み信号である。
【0029】
次に、図19に、この情報伝送システムに於ける管理局側の情報通信装置(サーバ機)の仕組みについて説明する。図19に於いて、200は、管理局側の情報通信装置(パソコンシステムなど)の全体を示す。また、同図に於いて、210は、携帯端末側から通信網を介して送られてきた情報を通信網から受信し、情報装置側に取り込むための通信手段受信機能である。また、220は通信網より受信した画像情報データ(圧縮加工されたデータ)を一時的に蓄積するための画像データ受信バッファ、221は蓄積された画像データを伸長処理し、元の画像データのサイズに復元するための画像データ伸長処理機能、222は復元された画像を映像出力するためにそのデータを一時的に格納しておくための画像データ出力バッファ機能、223は、画像を実際のビデオ・モニタやCRTに表示するための画像出力アナログ変換処理機能である。
【0030】
一方、230は通信網より受信した音声情報データ(圧縮加工されたデータ)を一時的に蓄積するための音声データ受信バッファ、231は蓄積された音声データを伸長処理し、元の画像データのサイズに復元するための音声データ伸長処理機能、232は復元された音声を再生出力するためにそのデータを一時的に格納しておくための音声データ出力バッファ機能、233は、音声を実際のスピーカなどから出力するための音声出力アナログ変換処理機能である。
【0031】
また、260は受信した画像データや音声情報データを、蓄積管理するためのデータ・ベース機能の内、情報をストレージに格納する部分である情報格納処理機能であり、261は同じデータ・ベース機能の内、情報をストレージから取り出す部分である格納情報出力処理機能である。
【0032】
同図に於いて、400は情報の伝送媒体である通信網、501は画像の出力機器であるCRTや、LCDなど、504はハード・ディスクのような情報のストレージ機器、503は音声再生出力用のスピーカを示す。
【0033】
一方、同図に於いて、502は、操作者の発する声を電気信号として入力するためのマイクロフォン、240は取り込まれた音声信号をディジタル化して取り込むための音声入力ディジタル化処理機能、241は入力された音声データを一時的に貯えるための音声データ入力バッファ機能、242は音声データのデータ量を縮小するために圧縮処理を行うための音声データ圧縮処理機能、243は圧縮された音声データを送信するために、一時的に格納しておくための音声データ送信バッファ機能である。
【0034】
また、250は、243に貯えられた音声データを通信網400に向けて送信するための通信手段送信処理機能である。
【0035】
210の通信手段受信処理機能は、ハードウェアによる通信インターフェースと、その処理ソフトウェアによって実現される。220の画像データ受信バッファと、230の音声データ受信バッファは、情報処理装置(パソコン等)内のメモリである。222の画像データ出力バッファ機能は、画像出力専用のメモリであったり汎用のメモリが利用される場合もある。232の音声データ出力バッファ機能は、音声出力専用のメモリであったり汎用のメモリが利用される場合もある。
【0036】
221の画像データ伸長処理機能、231の音声データ伸長処理機能、242の音声データ圧縮処理、260の情報格納処理機能、261の格納情報出力処理機能については、概ね、情報処理装置のプロセッサによるソフトウェアの実行によって実現される。
【0037】
223の画像出力アナログ変換処理機能は、専用のLSIやアナログ的インターフェース(ハードウェア)をソフトウェアで制御することによって実現される。233の音声出力アナログ変換処理機能は、音声コードをデコードするための専用ハードウェア(LSIなど)と音声D/A(Digital/Analog)変換器とによって実現される。
【0038】
240は、音声入力ディジタル化処理機能であり、音声A/D(Analog/Digital)変換器とコード化用のハードウェア(LSIなど)によって実現される。241は、音声データ入力バッファ・メモリである。
【0039】
243は音声データの送信バッファメモリであって、汎用のメモリなどが利用される。
【0040】
250の通信手段送信処理機能部は、情報の伝送媒体である通信網との通信インターフェース回路であり、専用のハードウェアとマイクロ・プロセッサによるソフトウェア実行との組み合わせにて実現される。
【0041】
【発明が解決しようとする課題】
図17、図19に示すような、端末装置と、管理局の情報通信装置との間で、画像データや音声データを伝送するシステムに於いて、音声情報の伝達に使用される音声データの圧縮処理および音声データの伸張処理は、共通したアルゴリズムに従って行われる。
【0042】
この音声の圧縮伸張アルゴリズムには、様々なものが実用化されているが、14.4kbpsと言った低速の回線網での使用を前提とした高い圧縮率のアルゴリズムとしては、ITU−TのG.723規格が知られている。
【0043】
この規格に準拠し、リアルタイムに音声を圧縮伸張するための音声圧縮伸張ソフトウェア・エンジンとして市販されている商品としては、現在1秒間の音声情報を8,500ビット(8.5kbit)まで圧縮するものが存在する。
【0044】
この圧縮率から単純に考えると、実際に1秒間分の音声情報として送るべきデータ数は、8,500ビットであるから、公称の回線スピード(伝送レイト)が9600bpsである携帯電話網でもこの情報は、伝えられると判断される。しかし、実際にコンピュータ間(端末と情報通信装置間も同じ)でこのような情報を伝送する場合には、通信のためのプロトコルを利用することが常套な手段であり、そのためには、音声データは、ある程度の大きさで分割され、前後にヘッダやフラグと呼ばれる、通信のための情報を付加されてパケット化されるのが普通である。
【0045】
この情報のパケット化に際し、そのシステムで実現する通信機能が、音声のみである場合、また、通信プロトコルが垂れ流しに近くFCS(フレーム・チェック・シーケンス)などのデータのチェック機能を必要としない場合には、そのヘッダ部分は比較的情報量を小さくすることができるので、1秒間に実際に伝送すべき情報量を9,600ビット以下に押さえていくことも不可能ではないと考えられる。
【0046】
しかし、先に図17〜図19を持って説明した、画像情報と音声情報を同じ装置で伝送可能としたシステムや、更に、監視や制御のための情報の授受機能まで備えるシステムでは、ヘッダ部分に、そのパケットの種別(例えば、画像、音声、監視、制御と言ったどのデータが含まれるのかを示すコード)情報を付加して、受信側での判別に用いる必要があるし、監視・制御情報を含む場合には、情報(データ)により高い信頼性を要求されるため、FCSなどのデータ・チェック機構をパケットに付加することが必要となる。
【0047】
すると、コンピュータ間(端末と情報通信装置間)でやりとりされる情報パケットには、本来のデータそのもののに加えて、比較的大きなヘッダ部分を付加することが必要となってくる。
【0048】
すると、先に述べた音声圧縮伸張エンジン(1秒当たりの音声情報を8.5kビットに圧縮)を用いて音声情報を伝送しようとした場合、そこに1秒当たり1.1kビット以上のヘッダが付加されることも考えられる。すると、1秒当たり、実際に物理回線で送る必要のあるデータ量は、9.6kビットを越えてしまうので、9,600bpsの伝送レイトを持つ回線での伝送が論理的に不可能となってしまう。
【0049】
ここで、実際の例を用いて、問題点を説明する。ここに、図17および図19で示すような画像および音声情報の伝送システムがある。このシステムに於いて、音声の圧縮伸張のアルゴリズムとして、ITU−TのG.723に準じた方式を採り、圧縮伸張処理のエンジンとしては、1秒当たりの音声情報を8.5kビットに圧縮する方式を用いるものとする。
【0050】
送信側の音声圧縮エンジンでは、30ミリ秒の情報を1データ単位としてこれを32バイト(256ビット)に圧縮し、受信側の音声伸張エンジンでは、これを元に戻して再生するものとする。
【0051】
すると、圧縮された音声情報は、1秒当たり、256ビット×1000/30=8,533ビット(≒8.5kビット)の情報量である。
【0052】
更に、これらの情報の通信のためのプロトコルとしては、PPP/IPでリンクし、UDP方式を用いるものとする。この通信プロトコルによって必要とされる1パケット当たりのヘッダと、データ種別識別など必要情報を含んだアプリケーション・ヘッダを加えた形での情報パケットのフレーム構成例を、図20に示す。この例では、1パケット当たりPPPに関する情報が8バイト(スタート・フラグ1バイト、PPPヘッダ4バイト、FCS(FrameCheckSequence)2バイト、エンド・フラグ1バイト)、IPに関するヘッダ情報が20バイト、UDPに関するヘッダ情報が8バイト、アプリケーション・ヘッダ情報が16バイトで、計52バイトのヘッダが形成されている。
【0053】
一方、1パケット当たりのデータ部分の情報量を大きくすると、受信/再生側では、1パケット分の音声情報を全て受信してからの、再生処理となるために、音声が再生開始されるまでの遅延が大きくなってしまうことから、1パケット当たりのデータ量をあまり大きく採ることは適切でない。ここでは、約210ミリ秒の音声遅延を許すとして、30ミリ秒分のデータ(256ビット)を1データ単位として、7データ(224バイト=1,792ビット)を1パケットに挿入するものとする。
【0054】
すると、この音声情報パケットのフレーム全体の容量は、276バイト(2,208ビット)となる。このパケットが、間断なく通信できたとして、9,600bpsの回線では、1秒間に、9,600/2,208=4.35フレームを送ることができるが、この4.35フレームに含まれる、音声情報の量は、1,792×4.35=7,795ビットとなり、毎秒8,533ビットの伝送を要求される圧縮後の音声データを送りきることができないことが分かる。
【0055】
このように、送るべき情報量が、最大の伝送容量を越えてしまうと、連続した音声情報を伝送した場合、次第に情報の到達時間の遅れが大きくなり、送信側では送信バッファのオーバフローを生じ、受信側では、音声再生に必要なデータが到達しないことによって、再生される音声が途切れ途切れになってしまう。
【0056】
このような理由により、ソフトウェアによって通信プロトコルを実現するための、ヘッダ容量が大きくなってしまう情報伝送システムでは、低い転送レイトの回線を用いた音声情報の伝送を行うことは困難であった。
【0057】
本発明の目的は、携帯電話等の低速転送レイト回線を使用した画像・音声および監視制御情報のリアルタイムな情報伝送ができる画像音声情報通信システムを提供することにある。
【0058】
【課題を解決するための手段】
(第1の発明)
先述の通り、従来のシステムでは、通信プロトコルを実現するための、ヘッダ容量が大きくなってしまう場合には、低い転送レイトの回線を用いた音声情報の伝送を行うことは困難であったが、逆に、このような場合でも、低い転送レイトの通信回線(例えば9,600bpsの携帯電話回線など)を用いることが期待されている。本発明は、これを実現するするものである。
【0059】
先述の課題で説明するシステムにおいて、低い伝送レイトの通信回線でもこの情報を伝送できるようにするためには、パケット当たりの情報量(データ量)を減らすしかない。図20に示すようなフレーム構成のパケットの場合、大きく分けてヘッダ部分の情報(データ量)を減らすか、音声情報そのもののデータ量を減らすかのいずれかである。しかし、通信プロトコルを実現するためのヘッダ類の情報削減が困難であり、また、音声情報の圧縮伸長アルゴリズムに於ける圧縮率をこれ以上高めることが困難であった場合、パケットの情報量を減らすことができない。
【0060】
そこで、本発明では、通信プロトコルを実現するためのヘッダ類の情報削減および、音声情報の圧縮伸長アルゴリズムに於ける圧縮率の変更を伴うことなく、簡単にパケット当たりの情報量を削減して、音声情報を低転送レイトの通信回線を通して伝送するようにしたものである。
【0061】
本発明による音声情報パケットのデータ量削減方法は、基本的には、音声データ部分の情報量を一義的に間引いて転送し、受信側でこの部分を前後のデータから補間して情報量を元に戻してから再生するものであり、以下の構成を特徴とする。
【0066】
(第2の発明)
前記の第1の発明になるシステムでは、1つのシステムに伝送レイトの早い回線と遅い回線とが混在し、その伝送レイトの差によって、圧縮音声データの間引き/補間処理を行うかどうかが決定される場合に、各端末とサーバとの1対1の通信の場合は、それぞれの伝送回線スピードに応じて、回線毎に間引き/補間処理の実施/不実施を設定すればよいが、そのシステムで一斉同報を行う必要のある場合には、伝送レイトの遅い回線に合わせて、常時、圧縮音声データの間引き/補間アルゴリズムを使う必要があった。これは、端末装置の伝送アルゴリズムが、通常一義的に定められているためである。
【0067】
本発明は、端末装置の伝送アルゴリズムを運用時もダイナミックに切り替える。つまり、サーバと端末間が、早い伝送レイトの回線を用いて、1対1の通信を行う場合には、間引き/補間処理を行なわない通常の伝送を行い、一斉同報通信時で、かつそのシステム内に遅い伝送レイトの回線が存在するために、間引き/補間処理を施さなければならない場合に限って、この補間処理を伴った伝送処理を行うものであり、以下の構成を特徴とする。
【0068】
(1)ディジタル化された画像・音声および制御情報などの複数種類のデータを遠隔した複数台の携帯型情報伝送端末装置と管理局通信装置との間で低速伝送レイトと高速伝送レイトの回線とが混在する回線を通して伝送し、前記各端末装置は送信する音声データを圧縮して間引きする手段を有し、前記管理局通信装置は送信する音声データを圧縮して間引きまたは間引きすることなく送信できる手段を有し、前記各端末装置は受信した音声データを補間して伸長または補間することなく伸長する手段を有し、前記管理局通信装置は受信した音声データを補間して伸長する手段を有する画像音声情報通信システムであって、
前記管理局通信装置と各端末装置との1対1通信の場合で、
それぞれの端末装置が接続された回線が低速伝送レイトの状態にあるときには、送信側になる前記管理局通信装置は前記圧縮した音声データを前記間引きして送信し、受信側になる前記各端末装置は受信した音声データを前記補間して前記伸長を行う送受信処理と、それぞれの端末装置が接続された回線が高速伝送レイトの状態にあるときには、送信側になる前記管理局通信装置は前記圧縮した音声データを前記間引きすることなく送信し、受信側になる前記各端末装置は受信した音声データを前記補間することなく前記伸長を行う送受信処理と、を切り替える手段を備えたことを特徴とする。
【0070】
(2)前記切り替え手段による切り替えは、前記管理局通信装置がデータの送信処理における送信エラーが発生するか否かによって回線の伝送レイトを判定することを特徴とする。
【0071】
(3)前記データの間引きと補間は、送信側になる前記管理局通信装置が伝送データパケットのヘッダ部で設定した間引きフラグで明示し、受信側になる前記各端末装置が前記フラグの状態から当該パケットが間引きされたデータか否かを判定することを特徴とする。
【0072】
【発明の実施の形態】
(実施形態1)
図1と、図2に、本発明の実施形態を示す端末と情報処理装置側の機能構成例を示す。
【0073】
図1は、端末側であるが、124部に圧縮音声データ間引き機能、154に圧縮音声データ補間機能が追加されており、その他の部分については、図17と全く同じである。
【0074】
一方、図2は、管理局側の情報処理装置側であるが、これも、244の圧縮音声データ間引き機能と、234の圧縮音声データ補間機能が追加されており、その他の部分については、図19と全く同じである。
【0075】
図1および図2で、細かい破線で囲まれた部分、101および201は、それぞれの装置内部の制御CPU(図18の170に相当)によって画像や音声の圧縮伸長処理を実現している部分であるが、圧縮音声データ間引き機能、および圧縮音声データ補間機能についても、この制御CPU(高性能なマイクロプロセッサ等)のソフトウェア処理によって実現する。
【0076】
この、圧縮音声データ間引き機能、および圧縮音声データ補間機能を用いて、圧縮後の音声データを間引き、データ転送し、これを受信して、データを補間して、音声伸長プロセスに入力されるまでの処理の様子を、図3に示す。ここでは、1パケット当たり7データ分の音声情報を5データまで縮小して伝送する例を示す。
【0077】
図3の(1)は、音声圧縮直後のデータで、1パケット当たり7データ(1データは30ミリ秒分の音声情報とし、256ビット)で構成されている。このデータを圧縮音声間引き機能を用いて5データに縮小したものが、(2)である。ここでは、第3番目のデータ(D3)と第6番目のデータ(D6)を強制的に削除した例を示している。この間引きにより、伝送される1パケット当たりの情報量は5/7となり、512ビット分縮小される。この縮小化されたパケットを受け取った受信側は、これを伸長処理する前に、圧縮音声データ補間処理を行う。この様子が同図の(3)である。ここでは、データD2の後に、D3’、データD5の後に、D6’のデータを強制的に挿入して、全体の情報量を間引き前の7データ分に戻している。これによって、情報量の戻った圧縮音声データに伸長処理を施して、音声再生(出力)を行う。
【0078】
実際の音声の波形について、この音声データの間引き処理と補間処理の方法を説明する。
【0079】
図4は人間の発声する音声の1音節分の波形例である。人間の音声は、子音部と母音部に分かれ、1音節の長さは、概ね200ミリ秒程度である。この長さは、本システムで用いられる音声情報1パケット分(30ミリ秒分×7データ=210ミリ秒分)とほぼ同じである。そこで、この1音節分の音声を圧縮する単位に分割してD1〜D7のデータ番号を付けている。
【0080】
例えば、図3で示したように、7データの内2データを間引いてまた補間する場合を考える。間引きは一義的に、間引くパターン(例えば第3、第6データを間引くというように)を定めて置けば処理が可能であるが、補間の方法は、一義的ではない。
【0081】
この場合、D3とD6のデータが欠落したパケットが、受信側で受け取られるので、受信側では、D3の代わりにD3’、D6の代わりにD6’を生成して補間するが、その場合の方式には以下のような例が考えられる。
【0082】
(補間方法例1)
図5に補間方法を示す。この例は、D3’およびD6’データを作る場合に、その直前のデータ(30ミリ秒分)D2およびD5をそのままコピーして埋め込む方法である。これにより、圧縮音声伸長機能に入力されるデータ列は、「D1,D2,D2,D4,D5,D5,D7」となる。
【0083】
この方法のメリットは、間引きされた欠落部を直前のデータのコピーで補うため、非常に簡単に補間処理が行える点である。その分、再生後の音声波形には、図5の様に不連続点が存在するため、若干の音質劣化が見られる。しかし、実証により内容を聞き取り判断するための音質としては十分であることが確かめられている。
【0084】
(補間方法2)
図6に補間方法を示す。この例も、D3とD6のデータが欠落して受信されるが、補間データD3’およびD6’を作る場合に、直前のデータの最終値、例えばD3’データを作る場合にはD2データの最終値(同図のA部分)をそのまま維持するような圧縮データを生成して埋め込む方法である。この場合、補間するデータは圧縮されたデータとして数値を生成しなければならないが、この方法は使用する圧縮伸長アルゴリズムによって異なる。
【0085】
この方法も、一つ前のデータの最終値を割り出して、それをオフセットとする無変化のパターンの生成なので比較的簡単に行うことができる。また、D2データからD3’、D5データからD6’データへは連続させることができるため、補間方法1よりは音質劣化が少ない。
【0086】
(補間方法3)
図7に補間方法を示す。この例も、D3とD5のデータが欠落して受信されるが、補間データD3’およびD6’を作る場合に、直前のデータの最終値と直後のデータの初期値、例えばD3’データを作る場合にはD2データの最終値(同図のA部分)と、次のデータD4の初期値(同図のB部分)の値を算出し、その平均値を計算してそのレベルをそのまま維持するような圧縮データを生成して埋め込む方法である。この場合も、補間するデータは圧縮されたデータとして数値を生成しなければならないが、この方法は使用する圧縮伸長アルゴリズムによって異なる。
【0087】
この方法も、一つ前のデータの最終値と次のデータの初期値から、平均値を割り出して、それをオフセットとする無変化のパターンの生成なので比較的簡単に行うことができる。
【0088】
この場合、D2データからD3’、D3’からD4、D5データからD6’、D6’からD7という部分でデータの連続性は失われているが、その不連続点での変化量は各点で平均化させることができるため、補間方法2よりは音質劣化が少ない。
【0089】
(補間方法4)
図8に補間方法を示す。この例も、D3とD6のデータが欠落して受信されるが、補間データD3’およびD6’を作る場合に、直前のデータの最終値と直後のデータの初期値、例えばD3’データを作る場合にはD2データの最終値(同図のA部分)と、次のデータD4の初期値(同図のB部分)の値を算出し、その間を直線で結ぶリニアな数値列を計算してその斜線データを圧縮データとして埋め込む方法である。この場合も、補間するデータは圧縮されたデータとして数値を生成しなければならないが、この方法は使用する圧縮伸長アルゴリズムによって異なる。
【0090】
この方法は、一つ前のデータの最終値と次のデータの初期値から、その差を割り出しこの2値を結ぶ傾いた直線(斜線)のデータを算出して、前データの最終値をオフセットとする斜線パターンを生成して埋め込むことになる。この方式の場合データの不連続点がなくなり、音質劣化は殆どない。
【0091】
この計算処理は前例に比べて複雑になるが、予め種々の傾斜角度を持った直線のデータ列のテーブルを作っておき、前データと次データの差からそれに対応する傾きのテーブルを参照してオフセットを加えるだけで埋め込むべき数値列を生成することができる。
【0092】
以上までの補間方法例では、7データを5データに縮小して伝送させることを説明したが、この場合1パケットの総容量は、1,696ビットとなり、9,600bpsの回線で1秒間に送ることのできるフレーム数は5.7となる。本来7データ分の情報を含んでいたフレームを毎秒5.7フレーム送れる訳であるから、音声の情報量としては、7データ(1,792ビット)×5.7=10,214ビット分であり、1秒間に必要とされる圧縮音声のデータ量、8,533ビットを上回る。
【0093】
従って、この手法により、通信プロトコルを実現するための、ヘッダ容量が大きくなってしまうようなシステムであっても、低い転送レイトの回線を用いた音声情報の伝送を行うことを可能にすることができる。
【0094】
(実施形態2)
前記の実施形態1では、圧縮後の音声データを間引いて伝送し、受信側で、一定の方法で欠落したデータを補間した上で音声再生を行うという方式で、伝送レイトの低い回線を用いても、リアルタイムに音声情報を伝送する。
【0095】
これによって、9,600bpsの伝送レイトを持った携帯電話回線を使用して、画像情報と共にリアルタイムの音声情報を伝送できるシステムが構築することは可能となった。
【0096】
しかし、この方式の場合、基本的には、本来送るべき圧縮後の音声データを間引いて転送するため、受信側でできるだけ元の波形に近くなるように音声データを補間したとしても、波形の完全な復元を行うことは不可能であるから、再生された音声がある程度の音質劣化を伴うことは、やむを得ないことであった。
【0097】
ここで、この方式を適用する、画像音声情報伝送システム全体を考える。このシステムは、図16で示した通り、画像情報を収集するための、端末装置と、この端末から送られる画像情報を収集して蓄積したり、表示したりする情報処理装置(サーバ装置)との組み合わせで構築されるが、1台の情報処理装置に対して、複数台の端末装置を従属させることも可能である。つまり、複数台の端末装置から、1台の管理局側のサーバ装置に対して画像情報を送信し、管理局側のサーバ装置は、複数台の端末から送られる情報を収集してこれを表示できる。この様に複数の端末を1台のサーバ装置で管理するシステムの例を図9に示す。
【0098】
さて、図9の例では、4台の端末まで、1台のサーバ装置で扱えるようなシステムを示しているが、従属している4台の端末装置の内、3台まで(端末1〜端末3)は、伝送レイトが32kbpsまたはそれ以上であるPHS(Personal Handy phone System)の回線を利用しており、残りの1台(端末4)だけが、伝送レイト9,600bpsの携帯電話回線を使用しているとする。
【0099】
このシステムの場合、PHS回線を使用した端末とサーバ間には充分な伝送レイトが得られるから、音声のリアルタイム伝送について、圧縮音声データの間引きを行う必要はないが、携帯電話回線を使用した端末とサーバ間では、実施形態1で説明した通り、リアルタイムに音声情報を伝送するための伝送レイトが得られないため、送信側で圧縮音声データの間引きを行い、受信側で間引いて欠落した圧縮音声データ部の補間を行ってやる必要がある。
【0100】
通常の画像データの収集と、音声通話が行われている場合、各端末とサーバ装置間は、1対1で情報を授受すればよく、それぞれ使用している回線の種類に応じて、圧縮音声データの間引きを行うか否かを決定した上で、通信を行うようにすればよい。
【0101】
ところが、この様なシステムに於いて、緊急事態が発生した場合などに、管理局側のサーバ装置から、それに従属する全ての端末装置に対して、一斉に同報連絡を掛けたい場合がある。この場合、端末の中に伝送レイトの遅い回線と早い回線とが混在している場合、同じアルゴリズムで伝送することができないため、同報通信のを諦め、端末毎に、何回かに分けて連絡する必要があった。
【0102】
また、別な手段としては、同報通信が極めて重要と判断されるシステムに於いては、遅い伝送レイトの回線を利用する端末が、1台でも存在する場合には、全端末に対して、常時、圧縮音声データの間引きを行う方式で通信を行うようにする必要があった。この方法の場合には、早い伝送レイトの回線を持った端末に対しても、常に間引きを行う伝送が行われるため、せっかくの伝送レイトが活かされず、通常の伝送時についても、ある程度音質劣化を起こした音声で会話をすることが余儀なくされていた。
【0103】
本実施形態は、以上の不都合を解消するもので、端末装置の伝送アルゴリズムを運用時もダイナミックに切り替える。つまり、サーバと端末間が、早い伝送レイトの回線を用いて、1対1の通信を行う場合には、間引き/補間処理を行なわない通常の伝送を行い、一斉同報通信時で、かつそのシステム内に遅い伝送レイトの回線が存在するために、間引き/補間処理を施さなければならない場合に限って、この補間処理を伴った伝送処理を行うものである。
【0104】
本実施形態による、音声情報伝送機能を実現するための、端末装置およびサーバ装置の機能構成を、図10と図11に示す。
【0105】
図10の端末装置は、図17の従来の端末装置の機能構成に対して、124の圧縮音声データ間引き機能と154の圧縮音声データ補間機能、155の受信パケット間引きフラグ判定機能を加えたものである。これは実施形態1に対しては、155が追加されている。
【0106】
一方、図11のサーバ装置は、図19の従来のサーバ装置の機能構成に対して、244の圧縮音声データ間引き機能と、245の間引き実施判定機能、234の圧縮音声データ補間機能を加えたものである。これは実施形態1に対しては、245が追加されている。
【0107】
また、図12に、この画像音声情報伝送システムで用いられる音声情報の基本パケット(間引きなし)のフレーム構成を示す。
【0108】
今、図12に示す、フレーム構成で単純に音声情報を伝送する場合、これを受け取る装置は、これが間引きを受けた情報なのか、間引きを受けていない情報なのかの判断がつかない。そこで、本実施形態では、このフレームのヘッダ部分にある、アプリケーション・ヘッダの内の一部分(最低1ビット)に専用のフラグ(間引きフラグと呼ぶ)を設けて、ここに、このフレームが間引き処理を受けたフレームか、そうでないかを明示するような仕組みとする。
【0109】
今回の例では、サーバから複数の端末装置に向けて一斉同報を行う場合に、早い伝送レイトを持つ回線についても間引き処理を行わなければならない訳だから、その音声フレームを間引くか否かは、サーバ装置側で判断し、間引き処理を行った場合についてのみ、そのフラグに「1」をセットするようにする。
【0110】
専用の間引きフラグをアプリケーション・ヘッダの中に設け、間引きの行われたフレームと間引きの行われていない通常のフレームとの差を示したものが図13である。
【0111】
図に示す通り、間引かれて短くなったフレームには、この間引きフラグに「1」がセットされ、間引きを受ない通常のフレームはこのフラグが「0」となっている。
【0112】
次に、画像音声情報伝送システムで、本実施形態による機構(仕組み)を利用する例を2つ説明する。
【0113】
(適用例A)
図11に示す管理局側のサーバ装置は、音声情報を送るべき端末装置との間の回線種別を予め認知しており、目的の端末への回線が低い伝送レイトである場合には、同図の245の間引き実施判定機能によってこれを判断し、244の圧縮音声データ間引き機能を動作させると共に、音声情報フレーム内の間引きフラグに「1」をセットして、そのパケットを送信処理機能を用いて回線に送り出す。
【0114】
一方、目的の端末への回線が早い伝送レイトを持つ場合には、245の間引き実施判定機能は、間引きなしと判断し、244の間引き機能は動作させず、音声情報フレーム内の間引きフラグを「0」にセットして、そのパケットを送信処理する。
【0115】
一斉同報通信の場合には、サーバはシステム内に、遅い伝送レイトの回線があるかどうかが予め分かっているから、これがある場合には、圧縮音声データの間引きを行って音声情報パケットを送信し、そうでない場合には、間引きを行わずに通常の音声情報パケットを送信する。
【0116】
一方、端末側は、自らが早い伝送レイトの回線に接続されているのか、あるいは、遅い伝送レイトの回線に接続されているのかについて、予め認識しておく必要はない。端末装置は、サーバ側から送られて来た音声情報パケットを受信すると、アプリケーション・ヘッダ部分にある「間引きフラグ」を抽出し、これが「1」にセットされている場合には、このパケットは間引きされているから、予め定められた間引きパターンにおけるデータの欠落部を、先提案で述べたような適当な補間方法によって、補間してから、伸張処理を施して音声再生を行う。
【0117】
受け取った「間引きフラグ」が、「0」であった場合には、このパケットは間引き処理を受けていないものであるから、そのまま通常の伸張処理を施して、音声再生を行えばよい。
【0118】
このような手法により、同一システム内に、早い回線と遅い回線が同居するような場合でも、一斉同報機能を実現することができるし、また、一斉同報ではない1対1の情報伝送を行う場合には、それぞれの回線毎に伝送レイトに応じて、間引き処理を行ったり、行わなかったりすることによって最適の伝送アルゴリズムを使用することができる。
【0119】
(適用例B)
管理局側のサーバと端末とを結ぶ回線が、一般の電話回線であって、モデム装置によってインターフェースが取られている場合、回線の品質状態によって、通信速度(伝送レイト)が変更される場合がある。
【0120】
例えば、通常では、33.6kbpsとか、14.4kbpsという比較的早い伝送レイトで通信できる回線であっても、回線上に品質劣化があった場合相互のモデム間のネゴシエーションによって、通信スピードを9,600bps以下に下げてしまうことが有りうる。
【0121】
この様な場合には、先の例と異なり、管理局のサーバや端末装置は、それらを結ぶ回線の伝送レイトを予め認識できていないため、端末に対する音声情報伝送の方式を決定することができない。
【0122】
そこで、このように、伝送レイトが変動するような回線に対しては、取りあえず、通常の音声情報の伝送方式(間引きなし)で送信を開始し、送信エラーが頻発しない限りは、そのままの方式で伝送を続けるものとする。もし、この伝送処理中に、送信エラー(例えば、送信アンダーラン)などが多発するようになった場合には、回線品質の劣化などによって、伝送レイトが下げられたことが推定されるため、その先の音声情報伝送については、間引き処理を加えるように切り替える。間引きされる音声情報パケットには、ヘッダ部の「間引きフラグ」に「1」をセットして送信する。
【0123】
音声情報パケットの受信側は、ヘッダ部の間引きフラグを必ず判定して、間引きフラグに「1」がセットされたパケットについては、補間処理を行い、フラグが「0」のパケットについては、これを行わないで音声再生する。
【0124】
この例の場合には、サーバ装置、端末装置共に、音声情報を送信処理する際に間引き音声伝送を行うかどうかの判断を行うことになる。(共に回線の伝送レイトを知らないため)この音声情報伝送機能を実現するための、端末装置およびサーバ装置の機能構成を、図14と図15に示す。
【0125】
図14の端末装置は、図10の例1による端末装置の機能構成に対して、125の間引き実施判定回路をを加えたものである。一方、図15のサーバ装置は、図11の例1によるサーバ装置の機能構成に対して、235の受信パケット間引きフラグ判定機能を加えたものである。
【0126】
以上のことから、適用例Bの場合の機能構成は、適用例Aの場合のものを拡張したものであるが、当然適用例Aの機能を実現することもできる。また、適用例Bの方法で、間引き伝送を行うと判断された回線については、そのままであると、継続的に遅い回線と認識されるが、その後、回線品質状態の復帰などによって回線速度(伝送レイト)が復旧するような場合には、一定期間毎に、通常の伝送方式(間引きしない方式)での音声情報伝送を試みることも効果的である。
【0127】
【発明の効果】
以上のとおり、本発明によれば、以下の効果がある。
【0128】
(1)従来のシステムでは、通信プロトコルを実現するための、ヘッダ容量が大きくなってしまう場合には、低い転送レイトの回線を用いた音声情報の伝送を行うことは困難であったが、このような場合でも、低い伝送レイトの通信回線を用いた通信ができる。
【0129】
(2)現在、携帯電話の普及率は非常に高くなっており、このインフラを利用した、画像や音声情報の無線伝送が求められている、画像と音声、さらに制御や監視情報を同じ伝送システムで授受しようとすると、情報量が大きくなりすぎて、この携帯電話回線(9,600bps)を利用することができなかった。少なくとも、画像やその他の監視制御情報、またはボイス・メイルのように遅延が許される情報の場合には、携帯電話のような遅い回線でも伝送可能であるが、本システムのように、現場との会話をしながら、画像情報を収集するようなシステムでは、リニアに音声情報を伝送しなければならないため、9,600bpsクラスの携帯電話回線は利用できなかった。本発明によれば、9,600bpsの携帯電話回線を利用して、リアルタイムの音声通話と画像情報伝送、監視・制御情報伝送を同じ1装置で行うことができる。
【0130】
(3)同じシステム内に伝送レイトの早い回線と遅い回線とが混在し、その伝送レイトの差によって、圧縮音声データの間引き/補間処理を行うかどうかが決定される場合に、各端末とサーバとの1対1の通信の場合は、それぞれの回線スピードに応じて、回線毎に間引き/補間処理の実施/不実施を設定すればよいが、そのシステムで一斉同報を行う必要のある場合には、伝送レイトの遅い回線に合わせて、伝送レイトの早い回線についても、常時圧縮音声データの間引き/補間アルゴリズムを使う必要があった。このため、従来の方式の場合には、早い伝送レイトの回線を持った端末に対しても、常に間引きを行う伝送が行われるため、せっかくの伝送レイトが活かされず、常にある程度の音質劣化を起こした音声で会話をすることが余儀なくされていた。
【0131】
これに対し、本発明によれば、サーバ側は各端末との1対1通信の場合には、それぞれの端末が接続された回線のスピードに応じて、間引き/補間処理を使うか使わないかを切り替えることができるため、伝送レイトの早い回線については、必要のない間引き/補間処理を行うことはなく、従って、音質劣化の少ない音声情報伝送を行うことができる。一方伝送レイトの低い回線については、この処理を加えることによって、従来不可能であった音声情報伝送そのものが可能になる。
【0132】
(4)サーバ装置から、従属された全ての端末装置に対して、一斉同報を掛ける場合には、そのシステム内に遅い伝送レイトの回線があれば、それにあわせて、間引き/補間アルゴリズムを用いた音声情報伝送を行うことが可能になる。すなわち、システム内の早い伝送レイトの回線に従属する端末は、受けとった音声情報パケット内のヘッダ情報から、間引きされたパケットであることを認識すると、補間アルゴリズムを働かせて、音声を再生するため、この一斉同報処理にも対応できる。
【0133】
これにより、システム内に遅い伝送レイトの回線が混在しても、早い伝送レイトの回線では、通常は音質劣化のない通常のアルゴリズムで音声情報伝送を行い、一斉同報時のみについては、遅い回線に合わせて間引き処理を施されたパケットを受け取ってもこれを音声再生処理できる。
【0134】
また、回線の伝送レイトに変動があって、圧縮音声の間引き/補間処理が必要になったり、そうでなくなったりという変化が生じる場合についても、音声情報を圧縮して送信しようとする装置側で、送信処理の実施応答から、送信エラーが頻発するようになった場合に、通常伝送から間引き伝送に切り替える判断をすれば、伝送レイトが下がった場合に自動的に間引き運転に移行できる。
【0135】
端末側は、絶えず受信された音声情報パケットに対して、間引きフラグの監視を行っていて、この状態に応じて、そのまま再生するか、欠落データを補間して再生すればよい。
【0136】
このような仕組みであれば、予め伝送レイトが固定できない回線を含むシステムであっても、伝送レイトが落ちた場合に自動的に対応できる。あるいは、各回線の伝送レイトを意識しないシステムの構築も可能になる。
【図面の簡単な説明】
【図1】本発明の実施形態1を示す携帯型情報伝送端末装置の機能構成例。
【図2】実施形態1における管理局情報通信装置の機能構成例。
【図3】音声データ間引きおよび補間処理の例。
【図4】人間の発生する音節の状態。
【図5】図4における第3データと第6データの間引きを補間する例(1)。
【図6】図4における第3データと第6データの間引きを補間する例(2)。
【図7】図4における第3データと第6データの間引きを補間する例(3)。
【図8】図4における第3データと第6データの間引きを補間する例(4)。
【図9】複数の端末を1台のサーバ装置で管理するシステム例。
【図10】本発明の実施形態2を示す端末装置の機能構成例。
【図11】実施形態2における管理局側サーバ装置の機能構成例。
【図12】一般のシステムで使用される音声情報パケットのフレーム構成。
【図13】音声情報パケットのフレーム構成例。
【図14】実施形態2における端末装置の機能構成例。
【図15】実施形態2における管理局側サーバ装置の機能構成例。
【図16】遠隔情報伝送システムの使用形態。
【図17】従来の携帯型情報伝送端末装置の機能構成例。
【図18】従来の端末装置の回路構成例。
【図19】従来の管理局情報通信装置の機能構成例。
【図20】音声情報パケットのフレーム構成例。
【符号の説明】
124、244…圧縮音声データ間引き機能
154、233、234…圧縮音声データ補間機能
155…受信パケット間引きフラグ判定回路
245…間引き実施判定機能
Claims (3)
- ディジタル化された画像・音声および制御情報などの複数種類のデータを遠隔した複数台の携帯型情報伝送端末装置と管理局通信装置との間で低速伝送レイトと高速伝送レイトの回線とが混在する回線を通して伝送し、前記各端末装置は送信する音声データを圧縮して間引きする手段を有し、前記管理局通信装置は送信する音声データを圧縮して間引きまたは間引きすることなく送信できる手段を有し、前記各端末装置は受信した音声データを補間して伸長または補間することなく伸長する手段を有し、前記管理局通信装置は受信した音声データを補間して伸長する手段を有する画像音声情報通信システムであって、
前記管理局通信装置と各端末装置との1対1通信の場合で、
それぞれの端末装置が接続された回線が低速伝送レイトの状態にあるときには、送信側になる前記管理局通信装置は前記圧縮した音声データを前記間引きして送信し、受信側になる前記各端末装置は受信した音声データを前記補間して前記伸長を行う送受信処理と、それぞれの端末装置が接続された回線が高速伝送レイトの状態にあるときには、送信側になる前記管理局通信装置は前記圧縮した音声データを前記間引きすることなく送信し、受信側になる前記各端末装置は受信した音声データを前記補間することなく前記伸長を行う送受信処理と、を切り替える手段を備えたことを特徴とする画像音声情報通信システム。 - 前記切り替え手段による切り替えは、前記管理局通信装置がデータの送信処理における送信エラーが発生するか否かによって回線の伝送レイトを判定することを特徴とする請求項1に記載の画像音声情報通信システム。
- 前記データの間引きと補間は、送信側になる前記管理局通信装置が伝送データパケットのヘッダ部で設定した間引きフラグで明示し、受信側になる前記各端末装置が前記フラグの状態から当該パケットが間引きされたデータか否かを判定することを特徴とする請求項1または請求項2に記載の画像音声情報通信システム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000376840A JP4432257B2 (ja) | 2000-12-12 | 2000-12-12 | 画像音声情報通信システム |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000376840A JP4432257B2 (ja) | 2000-12-12 | 2000-12-12 | 画像音声情報通信システム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2002185409A JP2002185409A (ja) | 2002-06-28 |
JP4432257B2 true JP4432257B2 (ja) | 2010-03-17 |
Family
ID=18845649
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2000376840A Expired - Fee Related JP4432257B2 (ja) | 2000-12-12 | 2000-12-12 | 画像音声情報通信システム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4432257B2 (ja) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2006171353A (ja) * | 2004-12-15 | 2006-06-29 | Nec Engineering Ltd | 音声復号システム |
JP5038951B2 (ja) * | 2008-03-19 | 2012-10-03 | 株式会社エヌ・ティ・ティ・ドコモ | 音声パケット通信方法および音声パケット通信装置 |
-
2000
- 2000-12-12 JP JP2000376840A patent/JP4432257B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2002185409A (ja) | 2002-06-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101003413B1 (ko) | 이동통신 단말기의 전송데이터 압축/해제 방법 | |
JP4949591B2 (ja) | ビデオ誤り回復方法 | |
US7822050B2 (en) | Buffering, pausing and condensing a live phone call | |
US6978242B2 (en) | Radio transmission device and method, radio receiving device and method, radio transmitting/receiving system, and storage medium | |
EP1768406A2 (en) | Video call apparatus for mobile communication terminal and method thereof | |
JP2000078202A (ja) | パケットベ―スネットワ―クを介しての遅延センシティブデ―タの保証方法、パケットベ―スデ―タネットワ―クを介して音声会話を可能にするための装置及びデ―タ伝送の品質改善方法 | |
JP2007174708A (ja) | パケット電話システムにおける帯域幅動的利用割り当てのための方法及び装置 | |
US7389093B2 (en) | Call method, call apparatus and call system | |
JP2003101662A (ja) | 通信方法、通信装置および通信端末 | |
JP5028784B2 (ja) | 無線lan電話システム、無線lan電話システム親機、無線lan電話システム子機、無線lan電話通信方法、無線lan電話通信プログラム、および、記録媒体 | |
CN115174538A (zh) | 数据传输方法、装置、电子设备及计算机可读介质 | |
JP2000270024A (ja) | インターネット電話におけるフレームパケット化サイズ能力交換方法,インターネット電話利用端末装置,およびインターネット電話のプログラムを記録した記録媒体 | |
JP2000332829A (ja) | 電話システムでの受信データ量制御方法、装置、及び、その方法を記録した記憶媒体 | |
JP3014366B2 (ja) | インターネット電話通信方法及び装置、及びそのプログラムを記録した記録媒体 | |
JP4432257B2 (ja) | 画像音声情報通信システム | |
US20060002686A1 (en) | Reproducing method, apparatus, and computer-readable recording medium | |
JP3362695B2 (ja) | 遅延揺らぎ吸収装置及び吸収方法 | |
JP3061039B2 (ja) | 無音圧縮符号復号化方法及びその装置 | |
JPH11308373A (ja) | 情報通信装置 | |
US6785234B1 (en) | Method and apparatus for providing user control of audio quality | |
US20050169245A1 (en) | Arrangement and a method for handling an audio signal | |
JP2002186032A (ja) | 携帯型情報伝送端末装置および管理局通信装置並びに画像音声情報通信システム | |
JP3172774B2 (ja) | 音声の無音抑圧可変制御装置 | |
JP2000253150A (ja) | 通話システムの通話補助装置 | |
JP3947871B2 (ja) | 音声データ送受信方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051209 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080415 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080613 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090630 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090824 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20091201 |
|
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091214 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4432257 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130108 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140108 Year of fee payment: 4 |
|
LAPS | Cancellation because of no payment of annual fees |