JP2000295597A - メディアデータ受信および送信装置 - Google Patents

Abstract

(57)【要約】 【課題】 受信装置での復号が間に合う程度に符号化す
る映像情報量を調整する。 【解決手段】 撮影した映像を圧縮符号化してパケット
化してＩＰ通信網１０１へ実時間で送信する送信装置２
０１と、送信装置２０１からのパケットをＩＰ通信網１
０１を介して受信して符号化方法に対応する復号方法で
直ちに復号する受信装置３０１とを備え、送信装置２０
１は受信装置３０１からの報告パケットを元に情報量を
変更して受信装置３０１に送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ＩＰ通信網を介
した、マルチメディア符号の実時間伝送系に関する。

【０００２】

【従来の技術】近年、インターネットプロトコル（以
下、IPと略す）通信網に接続されて、マルチメディアデ
ータ圧縮符号化とパケット伝送をリアルタイムで行い、
遠隔地間でライブ映像を送受信する装置が実用化されて
いる。IPの上位プロトコルとしては、双方向通信に必要
な低遅延の伝送を達成するためにしばしばユーザデータ
グラムプロトコル（以下、UDPと略す）が使用される。
この場合は送信データの確実な受信が保証されないが、
先進的な送受信装置では、過剰なデータ量や通信帯域の
変動に起因する伝送遅延の情報や通信損失の情報などを
受信側から送信側へフィードバックすることで、適応的
に定常状態を回復する手段がとられる。このようなフィ
ードバック通信のための規格を内包するのが業界の規格
の「RTP:A Transport Protocol for Real-Time Applica
tion (RFC1889), IETF,1996」である。例えば、文献１
では伝送遅延の増減のフィードバック情報を元に、送出
データ量を調整している。（文献1：低速回線でのイン
ターネット接続に適したリアルタイムデータの送信レー
ト制御法、信学技報、IN97-101、1997） 文献2は、通信損失を補償するプロトコル上での技術で
あるが、通信帯域に関する情報のフィードバックだけで
なく、実時間再生に必要な受信装置の資源の変動に関す
る情報も用いて、送出データを調整する方法が開示され
ている。（文献２：特表平８−５０９８４７） ところで、マルチタスクOSを搭載してＩＰ通信網に接続
されたコンピュータ上に構築され、UDPを使用してパケ
ット化されたマルチメディアデータの受信と再生を実時
間で行う受信装置は、パケットデータの受信にSocketAP
Iというドライバを使用する事が多い。その方法は例え
ば「WinSock2.0 プログラミング, ソフトバンク, 1998,
p.49-55」に開示されているが、概ね以下のような方法
である。

【０００３】ドライバはUDPパケットを受信する毎に受
信用のFIFOバッファにパケットデータを書き込む事と、
受信データの利用アプリケーションからの要求の毎に、
指定されるメモリへ受信データのコピーを行う事を行
う。FIFOバッファが溢れても送信側へ通知して送信を抑
止するしくみが無いので、過剰な受信データのいずれか
を破棄する。FIFOバッファの溢れを回避するためには復
号/再生処理性能を超えないパケットデータの送出を送
信側が行う。

【０００４】

【発明が解決しようとする課題】しかし、以上述べた方
法では以下のような問題点があった。

【０００５】受信装置からの周期的なフィードバック情
報を元に送信側でマルチメディア符号化の制御を行う既
存方式の目的はいずれも通信路の状態の変動を監視する
ためのものであり、映像受信装置の復号/表示処理能力
やシステムバスの使用率などの資源で復号/再生に使用
できる部分の変動を監視し、フィードバックする方式は
無かった。これは従来の映像受信装置が復号をハードウ
ェアによって行う場合が多く、資源の変動が小さいため
に無視できたからである。しかし、例えば遠隔監視/遠
隔支援システムのセンタ装置でソフトウェアによる多チ
ャンネル復号を行う時に、複数の監視ポイント/利用者
端末からチャンネルが中途に接続されて同時に復号する
映像データのチャネル数が刻々と変動する場合に、資源
の変動を逐次に各監視ポイントへ伝える手段が既存の方
式では提供されない。

【０００６】文献２には、受信側で再生に使用できる資
源の変動に応じた送信側の送信レート調整の方法が記載
されているが、その伝送手段にデータの確実な到着を保
証する通信プロトコルを用いることで、再生の間に合わ
ないデータの一部を送信の前段で選択的に破棄できる点
と、予め符号化され、蓄積されたデータを間引くことで
再生に利用できる資源に応じたデータを作成する点にお
いて、上記の問題点を解決するものではない。

【０００７】また既存の受信装置は、復号/再生の性能
を超えるデータが送信装置から断続的に送られない事を
仮定しているが、性能を超えるデータが受信用FIFOバッ
ファの容量を越えるほど断続的に送信装置から送られた
時、受信済みデータのバッファからの破棄を受信装置が
検知する手段がSocketAPIから提供されないため、デー
タ欠落が通信損失によるものかバッファからの溢れによ
るものかを区別できないという問題がある。また上記の
破棄データの取捨選択には受信装置が関与出来ず、デー
タの内容に応じて優先順位を付けた破棄が出来ないとい
う問題がある。

【０００８】

【課題を解決するための手段】本発明のメディアデータ
受信装置は、符号化したメディアデータを受信して復号
するメディアデータ受信装置であって、メディアデータ
受信装置で受信するメディアデータを送信するメディア
データ送信装置に対して、符号化したメディアデータの
復号状況情報を送信することを特徴とする。

【０００９】

【発明の実施の形態】《具体例１》 ＜構成＞図１はこの発明の具体例１を示すブロック図を
示している。送信装置２０１は、撮影した映像を圧縮符
号化してパケット化してＩＰ通信網１０１へ実時間で送
信する送信装置全体を示す。

【００１０】ＩＰ通信網１０１は、例えばＬＡＮ回線や
高速専用線やISDN回線などで構築され、インターネット
プロトコルをサポートする。

【００１１】受信装置３０１は送信装置２０１からのパ
ケットをＩＰ通信網１０１を介して受信して符号化方法
に対応する復号方法で直ちに復号する受信装置全体を示
す。

【００１２】映像取得部２１１は、映像情報量決定部２
１５から指示されるスペックで、映像信号をビデオカメ
ラなどから取得し、映像符号化部２１２へ送る。

【００１３】映像符号化部２１２は、映像取得部２１１
からの映像信号を予め決められた符号化方式で圧縮符号
化して符号データとイントラフラグにし、パケット送信
部２１３へ送る。

【００１４】パケット送信部２１３は、映像符号化部２
１２からの符号データとイントラフラグをパケット化
し、網インターフェイス送信部２１４へ送る。

【００１５】網インターフェイス送信部２１４は、パケ
ット送信部２１３からのパケットをＩＰ通信網１０１を
介して、網インターフェイス受信部３１１へ送信し、ま
た、網インターフェイス受信部３１１からの報告パケッ
トを受信して、映像情報量決定部２１５へ送る。

【００１６】映像情報量決定部２１５は、網インターフ
ェイス送信部２１４からの報告パケットを元に、情報量
の変更を映像取得部２１１へ要求する。

【００１７】網インターフェイス受信部３１１は、網イ
ンターフェイス送信部２１４からのパケットを受信し、
パケット受信部３１２からの要求に答えてパケットをパ
ケット受信部３１２へ送る。また、報告パケット送信部
３１６からの報告パケットをＩＰ通信網１０１を介し
て、網インターフェイス送信部２１４へ送信する。

【００１８】パケット受信部３１２は、網インターフェ
イス受信部３１１へパケットを要求し、符号バッファ３
１３へパケットを送る。符号バッファ３１３は、映像映
像復号部３１４へ符号データを送り、逐次取得する受信
情報を報告パケット送信部３１６へ知らせる。

【００１９】映像映像復号部３１４は、符号データを復
号し、映像信号に変換して映像再生部３１５へ送る。

【００２０】映像再生部３１５は、映像映像復号部３１
４からの映像信号を再生する。

【００２１】報告パケット送信部３１６は、パケット受
信部３１２からの受信情報をパケット化し、一定の周期
で網インターフェイス受信部３１１へ送る。

【００２２】＜動作＞映像取得部２１１は、指示通りの
映像サイズとフレームレートでデジタル映像を取得する
機能を有し、指示に従って動作中途でフレームレートを
変更する機能も有する。

【００２３】映像取得部２１１は、映像情報量 W のデ
ジタル映像信号を映像符号化部２１２へ１フレームずつ
映像サイズ情報と共に送る。但し、映像情報量W=X×Y×
Z で、縦映像サイズＸ画素、横映像サイズＹ画素、Ｚフ
レーム/秒 である。X,Y,Z は映像符号化部２１２が符号
化可能な初期値X0、Y0, Z0 を持っており、従って映像
情報量W の初期値W0 は X0×Y0×Z0 で決まる。

【００２４】映像取得部２１１は、映像情報量決定部２
１５から別の要求映像情報量Ｖ〓に変更するように指示
される毎に映像情報量Wを変更し、X,Y,ZをW=X×Y×Zを
満たしながら更新する。

【００２５】X,Y,Zの更新方法としては、例えば、X=X0,
Y=Y0,Z=W/X/Y. とする計算式が挙げられ、この場合は映
像サイズは不変で、フレームレートだけが更新される。

【００２６】別のX,Y,Zの更新方法としては、Z=Z0,X^2=
W×X0/Z/Y0, Y^2=W×Y0/Z/X0を満たす計算式が挙げら
れ、この場合はフレームレートは不変で、映像サイズだ
けがアスペクト比を保ったまま更新されるが、映像取得
部２１１が指示に従って動作中途で映像サイズを変更す
る機能を有し、映像符号化部２１２が動作中途での映像
サイズの変更に対応出来る場合に限った更新方法であ
る。

【００２７】映像符号化部２１２は映像取得部２１１か
らの１フレームづつの映像信号を予め決められた符号化
方法で符号化し、符号データを作成し、パケット送信部
２１３の要求する単位でパケット送信部２１３へ送る。
但し、動作中途での映像サイズの変更に対応して、一旦
符号化を停止し、新たな映像符号の映像サイズ情報を含
む開始コード作成から符号化を再開できる機能を映像符
号化部２１２が持つ場合は、映像符号化部２１２は動作
途中の映像サイズ変更を監視し、変更に対応する。

【００２８】パケット送信部２１３は映像符号化部２１
２からの１パケット分の符号データの先頭にパケットヘ
ッダを付加し、パケット化する。パケットヘッダは、例
えば、「RFC1889, IETF」にあるRTP基本仕様と「RFC189
0, IETF」や「RFC2190, IETF」を一例とする、符号デー
タの符号化方法に応じて決まる関連ペイロード仕様、と
に準拠するパケットのヘッダである。１パケット分の符
号データは１フレーム相当や数スライス相当や数グルー
プオブブロック相当などであるが、先頭に、復号の同期
信号が多重される。同期符号の多重により、パケット損
失した際にパケット再送手段が無くても、後続パケット
データの受信及び復号を継続できる。パケットに含まれ
る符号データが映像データ符号である場合には、パケッ
トヘッダ中には少なくともパケットの通し番号と符号デ
ータ長の他に、符号データがフレーム間差分を利用しな
い符号化方式だけで符号化されたものか否かを示すイン
トラフラグを記述する。このような符号データの例とし
ては、イントラのフレームを構成する符号やイントラの
スライスを構成する符号やイントラのグループオブブロ
ックを構成する符号が挙げられ、例えば、映像符号H.26
3 (ITU-T) のRTPペイロード規格である「RFC2190, IET
F」で規定されるパケットヘッダには、5.1節に 「I Bit
s」として定義されるフラグがあり、この要件を満たす
フラグとして流用できる。イントラフラグは符号データ
に添付して映像符号化部２１２から送られるイントラフ
ラグ情報から作成する。

【００２９】パケットを作成次第、網インターフェイス
送信部２１４へ送信要求を出す。

【００３０】網インターフェイス送信部２１４はパケッ
ト送信部２１３から要求されると、網インターフェイス
受信部３１１を送信先として、パケット送信部２１３か
らのパケットをＩＰ通信網１０１へ発信する。

【００３１】網インターフェイス送信部２１４はまた、
網インターフェイス受信部３１１からの報告パケットを
受信し、映像情報量決定部２１５からの要求に応じて、
受信した報告パケットを映像情報量決定部２１５内の指
定メモリへコピーする。

【００３２】映像情報量決定部２１５には網インターフ
ェイス送信部２１４から送られる報告パケットが受信さ
れる毎にその内容を映像情報量決定部２１５内のメモリ
へ取り込まれる。報告パケットには受信装置３０１内に
おける、映像復号部３１４へ送られる送信パケット数 A
とパケット破棄数 Bと通信損失している損失パケット数
Cの各々毎秒平均でのデータが含まれる。

【００３３】映像復号部３１４での映像符号の復号に必
要な単位時間当たりの演算量は先に定義した映像情報量
Wに対して単調増加、もしくは、ほぼ比例するという経
験則を利用して、送信パケット数A と パケット破棄数B
と損失パケット数Cと現在映像取得部で設定されている
映像情報量Wとを元に、 新規の要求映像情報量Ｖを以
下の手順で決定する。

【００３４】まず、パケット破棄数Bが０であれば、現
在は受信装置の復号能力に余裕があるので、Ｖ＝W＋Kと
する。 Kは予め決めた定数でW0の数％とする。

【００３５】パケット破棄数Bが０でない場合は、現在
は受信装置の復号能力に余裕が無いので、映像情報量Ｗ
を減らす事でこれ以降の映像復号部３１４での映像符号
の復号に必要な単位時間当たりの演算量を減らし、復号
溢れを低減させる。全ての送信された映像情報量のう
ち、少なくとも B/A+B+C で表される割合の情報量が復
号できなかったので、Ｖ= W - W × (B/(A+B+C))×D)
とする。ここで、D は急峻な映像情報量の低下を抑える
ための定数で、0 < D <= 1 で、例えば 0.5 である。

【００３６】いずれの場合も、要求映像情報量Ｖには上
限をW0とし、下限はW0の数％である予め決められた定数
とするような制限をかる。映像取得部２１１に要求映像
情報量Ｖを伝えて映像情報量Ｗを更新させる。

【００３７】起動時に送信装置２０１にとって映像復号
部３１４の映像復号能力が未知であっても、何回かの報
告パケットの受信により映像情報量Wの設定が最適化さ
れて、映像復号部３１４の映像復号能力に応じた量の符
号データが送信されるようになり、復号溢れが解消され
る。また、映像復号部３１４の映像復号能力が、中途で
変化したときにも、適応的に映像情報量Wの設定が最適
化される。

【００３８】網インターフェイス受信部３１１は、通信
網１０１からのパケットを待ち受け、内部に存在する図
示しないFIFOバッファにパケットを書き込む。また、パ
ケット受信部３１２から受信パケットを要求される度
に、FIFOバッファに受信パケットを保持している場合は
1パケット分の受信データを符号バッファ３１３の指定
メモリへコピーし、保持していない場合は、高々パケッ
ト受信部３１２から指定されたタイムアウトの時間ま
で、次のパケットの受信を待ち受ける。タイムアウト指
定が無ければ、次のパケットの受信まで待ち受ける。受
信出来たときは1パケット分の受信データを符号バッフ
ァ３１３の指定メモリへコピーし、受信出来なかったと
きは失敗応答をパケット受信部３１２へ返信する。

【００３９】映像復号部３１４は、符号バッファ３１３
からパケットを読み出し、復号する。

【００４０】映像再生部３１５は、映像復号部３１４で
復号された１フレーム分の映像信号の再生を繰り返して
行う。報告パケット送信部３１６は、報告パケットのデ
ータを作成して、網インターフェイス送信部２１４を送
信先として網インターフェイス受信部３１１を通じてＩ
Ｐ通信網１０１へ送信する。報告パケットのデータ作成
については、具体例３で具体例を示す。

【００４１】本具体例では、映像取得部２１１でフレー
ムレートを変更して映像を取得することとしているが、
映像取得部２１１に動的なフレームレート変更の機能が
無い場合は、映像取得部２１１では固定レートとし、映
像符号化部２１２において、映像を符号化するフレーム
レートを変更して符号化を回避するフレームの信号を破
棄するという構成にしてもよい。

【００４２】＜効果＞以上のように、具体例１によれ
ば、復号溢れの程度の情報を映像送信装置へ通知するこ
とができる。映像送信装置はこの情報を繰り返し用いる
ことで受信装置での復号が間に合う程度に符号化する映
像情報量を調整でき、再生映像の乱れを適応的に回避す
る事が出来るという効果がある。従って、事前の能力交
換不要で、映像再生性能が未知である映像受信装置へ符
号の送信を開始できる。また、動作するコンピュータの
他のプロセスや他の映像再生装置の状態により、映像受
信装置の持つ映像再生性能が接続中途で変わる場合も、
同様に映像情報量を調整できる。これにより、ソフトウ
ェアによる複数の映像再生装置やオーディオ再生装置を
同時に使用した多チャネル再生を行う際に映像チャネル
の数が刻々と変化しても、動作するコンピュータの性能
で再生できる映像情報量の限界での再生が行える効果が
ある。

【００４３】《具体例２》 ＜構成＞図２はこの発明の具体例２を示すブロック図を
示している。

【００４４】受信装置３０２は１つまたは２つ以上の送
信装置からの映像符号パケット及びオーディオ符号パケ
ットを受信して各々の符号化方法に対応する復号方法で
直ちに復号する受信装置全体を示す。具体例１と同じ構
成には同じ符号を付して説明を省略する。

【００４５】網インターフェイス受信部３２１は、１つ
または２つ以上のメデイア符号送信装置からの映像符号
パケット及びオーディオ符号パケットを受信し、宛先チ
ャンネルを識別して、パケット受信部３２２−ｎからの
要求に答えて受信したオーディオ符号パケットをパケッ
ト受信部３２２−ｎへ送り、パケット受信部３３２−ｎ
からの要求に答えて受信した映像符号パケットをパケッ
ト受信部３３２−ｎへ送る。また、報告パケット送信部
３１６からの報告パケットをＩＰ通信網１０１を介し
て、図示しないメディア符号送信装置へ送信する。ここ
でチャンネルとは、別のメディア又は別の送信装置から
の符号パケットがそれぞれ予め決まった異なるパケット
受信部で処理される経路のことを言う。

【００４６】パケット受信部３２２−ｎは、網インター
フェイス受信部３２１へ受信パケットを要求し、オーデ
ィオ復号部３２４−ｎへ符号データを送り、逐次取得す
る受信情報を報告パケット送信部３１６へ知らせる。

【００４７】オーディオ復号部３２４−ｎは、符号デー
タを復号し、オーディオ信号に変換してオーディオ再生
部３２５−ｎへ送る。オーディオ再生部３２５−ｎはオ
ーディオ再生部で、オーディオ復号部３２４−ｎからの
オーディオ信号を再生する。

【００４８】パケット受信部３３２−ｎは、網インター
フェイス受信部３２１へ受信パケットを要求し、映像復
号部３１４−ｎへ符号データを送り、逐次取得する受信
情報を報告パケット送信部３１６へ知らせる。

【００４９】映像復号部３１４−ｎは、符号データを復
号し、映像信号に変換して映像再生部３１５−ｎへ送
る。映像再生部３１５−ｎは、映像復号部３１４−ｎか
らの映像信号を再生する。報告パケット送信部３１６
は、パケット受信部３２２−ｎ及びパケット受信部３３
２−ｎからの受信情報を元に、パケット受信部３３２−
ｎに対応する報告パケットを作成し、一定の周期で対応
する送信装置へ送る。

【００５０】＜動作＞網インターフェイス受信部３２１
は、複数のチャンネルのそれぞれの宛先に応じたパケッ
ト受信部３２２−ｎ、パケット受信部３３２−ｎを識別
してパケットを処理する。

【００５１】パケット受信部３２２−ｎおよびパケット
受信部３３２−ｎは具体例１に記載のパケット受信部３
１２と同様に、受信したオーディオおよび映像データの
パケットをオーディオ復号部３２４−ｎおよび映像復号
部３１４−ｎに送る。ここで、符号バッファに関する説
明は具体例２と同じため、省略する。また、受信した情
報を報告パケット送信部３１６へ送る。

【００５２】オーディオ復号部３２４−ｎはオーデイオ
の復号を行い、復号したオーディオ信号をオーディオ再
生部３２５−ｎへ送る。

【００５３】オーディオ再生部３２５−ｎはオーデイオ
信号の再生を繰り返して行う。

【００５４】映像復号部３１４−ｎおよび映像再生部３
１５−ｎは第３の具体例の映像復号部３１４および映像
再生部３１５と同じ動作をするため、説明を省略する。

【００５５】報告パケット送信部３１６は具体例１同様
にパケット受信部３２２−ｎおよびパケット受信部３３
２−ｎからの受信情報を蓄積する。そして、予め決めら
れた周期で，単位時間当たりの復号部へ送った送信パケ
ット数Ａと単位時間当たりの復号できなかった破棄パケ
ット数Ｂと単位時間当たりの通信損失された損失パケッ
ト数Ｃを記載した報告パケットを映像符号のチャンネル
に対してだけ作成し、それぞれに対応する映像送信装置
へ送る。この際、その周期のうちに、復号できなかった
オーディオパケットが少なくとも１チャンネルで存在し
たか否かを判定し、存在した場合は、上記の全報告パケ
ット中の、単位時間当たりの復号できなかった映像パケ
ットの数をある定数だけ故意に増加させる。

【００５６】同様に、１映像チャンネルだけが他の映像
チャンネルよりも優先度が高いと予め指定された場合に
は、その周期のうちに、指定チャンネルの映像パケット
で復号できなかったパケットが存在したかを判定し、存
在した場合は、指定チャンネルを除く上記の全報告パケ
ット中の、単位時間当たりの復号できなかった映像パケ
ットの数をある定数だけ故意に増加させる。

【００５７】＜効果＞以上のように具体例２によれば、
ソフトウェアによる複数の映像受信装置やオーディオ受
信装置を同時に使用して、復号のための資源を共有しな
がら多チャネル再生を行う際に、送信装置におけるメデ
ィア信号の情報量の変更が困難なオーデイオ符号の再生
に必要十分な資源をオーディオ受信装置に優先的に提供
し、残りの資源で再生できる映像情報量の映像符号を映
像送信装置へ要求することで、オーディオ再生品質の維
持と良好な映像の再生を両立できるという効果がある。

【００５８】《具体例３》 ＜構成＞図８はこの発明の具体例３を示すブロック図で
ある。マルチタスクOS上で動作し、音声や映像の圧縮符
号化され、パケット化された、符号データをＩＰ通信網
から受信し、符号化方法に対応する復号方法で直ちに復
号する復号装置の一部を示している。具体例１および２
と同様の構成には同じ符号を付して説明を省略する。

【００５９】符号バッファ３１３は、パケット受信部３
１２が受信するパケットを格納するためのメモリであ
り、０番からN-1番のNバンクのメモリで構成される。N
個の各メモリバンクは十分に大きなパケット長 Mバイト
を収容できる大きさの連続メモリであれば良く、単純に
は、Mバイトの連続メモリを固定的にN枚用意する。この
場合、M バイトを超える受信パケットは破棄する。 Nお
よびＭは、２以上の自然数である。

【００６０】メディア復号部３３４は、符号バッファ３
１３に存在する任意の符号データを読み取り、符号に対
応する復号方法で復号し、オーディオ信号や映像信号な
どのマルチメディア信号を出力する。メディア再生部３
３５は、メディア復号部３３４の出力するマルチメディ
ア信号を再生する。

【００６１】＜動作＞図４はパケット受信部３１２の動
作するフロチャートを示した図である。ステップＳ１０
３１で、パラメータi を 0 にセットする。パラメータi
は０からＮ−１へ増分し、Ｎ−１の次は０に戻るパラ
メータで、符号バッファ３１３の書き込みバンク値を意
味する。

【００６２】ステップＳ１０３２で、メディア復号部３
３４からのACK信号104-i をタイムアウト時間まで待
つ。到着した場合は符号バッファ３１３[i]への書き込
みが許可されているので、ステップＳ１０３３へ移る。
タイムアウト時間まで信号を待機しても到着しない場合
は、メディア復号部３３４による符号バッファ３１３
[i]からの読み出しが未だ終了していないとして、ステ
ップＳ１０３６へ移る。

【００６３】ステップＳ１０３３で、網インターフェイ
ス受信部３１１へパケットをタイムアウト指定無しで要
求し、符号バッファ３１３[i]へパケットデータを格納
する。このパケットヘッダに刻印されたパケット通し番
号を毎回参照することで、符号バッファ３１３[i-1]に
格納された前パケットと現パケットの間に通信損失によ
る損失パケットがあるか否かを判定できる。損失パケッ
トがある場合、その数を損失パケット数Ｃとして発生毎
に報告パケット送信部３１６へ報告する。その後、ステ
ップＳ１０３４へ移る。

【００６４】ステップＳ１０３４で、READY信号102-i
をメディア復号部３３４へ発信し、正常なパケット受信
の回数を送信パケット数Ａとして報告パケット送信部３
１６へ報告する。その後、ステップＳ１０３１へ移る。

【００６５】一方ステップＳ１０３５とステップＳ１０
３６では、網インターフェイス受信部３１１へパケット
のコピーを、予め決められた比較的短いタイムアウト時
間を指定して要求する。失敗応答ならば、そのままステ
ップＳ１０３２へ戻る。受信したパケットが既にFIFOバ
ッファにあるか、又は、タイムアウト時間以内にパケッ
トが到着した場合は、パケットデータは符号バッファ３
１３へは格納せずに直ちに破棄し、復号溢れの回数をパ
ケット破棄数Ｃとして報告パケット送信部３１６へ報告
する。その後、ステップＳ１０３２へ戻る。

【００６６】図５は、メディア復号部３３４の動作する
フロチャートを示した図である。まずステップＳ１０５
１で、初期化動作として、メデイア復号部３３４はACK
信号104-i (i=0,1,..,N-1)を計Ｎ回発信する。これは符
号バッファ３１３が起動時には空であることを知らせる
ためのものである。ステップＳ１０５２ではパラメータ
i を 0 にセットする。

【００６７】ステップＳ１０５３で、パケット受信部３
１２からのREADY信号102-i をタイムアウト無しで待機
する。到着したら、ステップＳ１０５４へ移る。READY
信号102-i及びACK信号104-iは、マルチタスクOSが標準
的に備えるスレッド間同期手段を用いて実現できる。例
えば、マイクロソフト社製のWindows 系の各OSであれば
イベントハンドリング機構によりイベントオブジェクト
を生成し、パケット受信部３１２とメデイア復号部３３
４の間でハンドル値を共有することで、 ＲＥＡＤＹ信
号１０２−ｉ及びACK信号104-iが実現できる。

【００６８】READY信号102-i(i=0,1,..,N-1) はパケッ
ト受信部３１２からメデイア復号部３３４へ発信され、
符号バッファ３１３のメモリバンク数N と同数の、それ
ぞれが識別可能な信号で構成される。 READY信号102-i
は符号バッファ３１３ [i] への書き込み完了を意味す
る。ACK信号104-i(i=0,1,..,N-1) はメデイア復号部３
３４からパケット受信部３１２へ発信され、符号バッフ
ァ３１３のメモリバンク数N と同数の、それぞれが識別
可能な信号で構成される。 ACK信号104-i は符号バッフ
ァ３１３[i] からの読み込み完了を意味する。

【００６９】ステップＳ１０５４で、メデイア復号部３
３４は、符号バッファ３１３[i]の符号を読み出して復
号し、オーディオ信号や映像信号などのメデイア信号を
生成する。読み終わったらステップＳ１０５５へ移る。

【００７０】ステップＳ１０５５で、ACK信号104-i 信
号をパケット受信部３１２へ発信し、ステップＳ１０５
２へ移る。図６は具体例３を動作させた時の網インター
フェイス受信部３１１とパケット受信部３１２とメディ
ア復号部３３４との間の同期制御信号とデータの流れの
一例を示すタイムチャートの図で、起動時からの動作を
示す。左端の垂直線は網インターフェイス受信部３１１
の動作を表し、中央の垂直線はパケット受信部３１２の
動作を表し、右端の垂直線はメディア復号部３３４の動
作を表し、右端の太い垂直線の部分は実際の復号がメデ
ィア復号部３３４により実行されている時間を表し、括
弧内の数字は図４と図５のフロチャート中での実行担当
個所を表している。

【００７１】ここでは、符号バッファ３１３のＮの個数
を３としている。細実線の水平線は符号バッファ３１３
[i=0]に係る動作を示し、破線の水平線は符号バッファ
３１３[i=1]に係る動作を示し、二重線の水平線は符号
バッファ３１３[i=2]に係る動作を示す。

【００７２】図６は、１パケット当たりの復号処理の所
用時間がパケット到着間隔よりおおむね小さいような定
常的な状態の例を示している。符号バッファ３１３にパ
ケットが１つ以上蓄積せず、あるパケットを受信してか
らそのパケットに含まれる符号データを復号開始するま
での時間経過が小さい事を示している。

【００７３】図７は具体例３を動作させた時の網インタ
ーフェイス受信部３１１とパケット受信部３１２とメデ
ィア復号部３３４の間の同期制御信号とデータの流れの
一例を示すタイムチャートの図で、中途からの動作を示
す。図中の用語の説明は図６と同じなので省略する。

【００７４】図７は、復号に通常より時間を要するパケ
ットがあったり（復号ジッタ）、想定以上の通信ジッタ
が発生したために、符号バッファ３１３に未復号のパケ
ットデータが溜まっている非定常な状態の一例を示して
いる。符号バッファ３１３に書き込み可能なバッファが
無い場合でも、パケット受信部３１２は網インターフェ
イス受信部３１１へパケットを要求するため、網インタ
ーフェイス受信部３１１内のFIFOバッファが溢れる事は
ない。受信したが、復号できずに破棄するパケットの数
を正確に把握し、報告する。そして、網インターフェイ
ス受信部３１１へ報告パケットの送信要求を出す。

【００７５】なお復号ジッタは、メディア復号部３３４
のステップＳ１０５４をソフトウエアで実行する場合
に、並行して受信するチャンネルや他のプロセスなどの
非同期的な実行のために演算資源が一時的に競合して発
生するケースが一例として挙げられる。

【００７６】符号バッファ３１３のＮをより大きく設定
すれば、復号ジッタや通信ジッタが大きい場合の復号溢
れを回避しやすくなる反面、ジッタ発生時や１パケット
当たりの復号処理の所用時間がパケット到着間隔とほぼ
同じような状態の時には、受信から再生までの遅延時間
が増大してしまうので、許容される遅延時間や使用可能
なメモリ量を元に決定する。

【００７７】報告パケットのフォーマットとしては、TC
Pパケットとして送受間で認識できるフォーマットを決
めても良い。例えば、映像送信装置の制御を行うための
コマンド用チャンネルが使用される場合は、このチャン
ネル使って報告パケットを送信端末側へ送信することが
考えられる。

【００７８】また、このような報告パケットのフォーマ
ットはUDPパケットとして送受間で認識できるフォーマ
ットを決めて使用しても良いし、さらには、「RFC1889,
IETF」で規定されているRTPコントロールプロトコル
(以下 RTCP と略す) に準拠したフォーマットを使用し
ても良い。

【００７９】RTCPは本来、RTP利用のマルチメディア通
信で、通信帯域の状況を系全体へ報告する使途で利用さ
れる。しかし、「RFC1889, IETF」6.6節 に記載される
APP型のRTCPパケットは、利用者が定義する情報を伝送
できるので、ここに本具体例のような報告の情報を多重
してもRTCPの動作上影響はない。

【００８０】本具体例では、符号バッファ３１３をMバ
イトの連続メモリをN枚用意する例を示したが、符号デ
ータ長にばらつきがある場合にMを大きく取らざるを得
ない。P×Nバイト(P<M)の連続メモリを１枚用意し、リ
ングバッファとして、動的にN枚に分割して使用するこ
とで、メモリ効率を高めることができる。この場合、符
号バッファ[i]の番地は毎回変更されるが、番地リスト
をパケット受信部３１２とメディア復号部３３４とで共
有して更新する。READY信号102-i及びACK信号104-iは、
マルチタスクOSが標準的に備えるスレッド間同期手段を
用いることとしたが、実装プラットフォームとなるOS
が、好適なスレッド間の同期手段を提供しない場合に
は、パケット受信部３１２とメディア復号部３３４との
間で共有するN+N個のメモリの値をトグルスイッチとし
て用いて実現しても良い。同様にレジスタや変数の値に
よって実現することも可能である。

【００８１】＜効果＞以上のように具体例３では、網イ
ンターフェイス受信部内の受信用FIFOバッファからの読
み出しをメディア符号の復号の進捗と非同期に行えるた
め、FIFOバッファの溢れを回避できる。復号処理に余裕
がある場合は受信から復号開始までに経過する時間は最
小に抑えられる。

【００８２】FIFOバッファの溢れ回避により、このFIFO
バッファが他のチャンネルと共有して実装される場合
で、音声と映像のように複数チャンネルのメディア受信
を並列に行う場合には、別のメディアの復号溢れによる
FIFOバッファの溢れに起因したパケット損失を回避でき
るという効果がある。

【００８３】また、メディア符号の復号が間に合わない
ときに実行する、受信パケットの破棄を受信装置自体が
明示的に行うため、単位時間当たりの受信パケットの破
棄数と通信損失したパケット数を切り分けて検知するこ
とが出来るという効果がある。

【００８４】《具体例４》 ＜構成＞図８はこの発明の具体例４を示すブロック図で
ある。具体例３と同じ構成には同じ符号を付して説明を
省略する。具体例３における網インターフェイス受信部
３１１とパケット受信部３１２の代わりに、網インター
フェイス受信部３４１とパケット受信部３４２を用い
る。

【００８５】＜動作＞以下、メデイア符号のうち、映像
符号に対する動作に関して説明する。

【００８６】網インターフェイス受信部３４１とパケッ
ト受信部３４２の動作以外は、具体例３と同様に動作す
るため、説明を省略する。

【００８７】具体例３と同様に、網インターフェイス受
信部３４１網インターフェイス受信部３４１は通信網１
０１からのパケットを待ち受け、受信パケットが到着す
る毎に内部に存在する図示しないFIFOバッファにパケッ
トデータを書き込む。但し、具体例３の網インターフェ
イス受信部３１１と異なり、パケット受信部３４２から
指定があった場合には、1パケットの固定長のパケット
ヘッダ部分のデータと後続の符号データ部分のデータを
分けてコピーする。このような指定がパケット受信部３
４２からあった時は、まず1回目の要求に対してヘッダ
だけを符号バッファ３１３の指定されたメモリへコピー
し、続いて対となる2回目の要求に対して、符号データ
を符号バッファ３１３の指定メモリへコピーする。

【００８８】図９はパケット受信部３４２の動作を示す
フロチャートの図である。

【００８９】ステップＳ２０３１で、メディア復号部３
３４からのACK信号104-0が到着するまでタイムアウト無
しで待機する。ステップＳ２０３２で、パラメータi を
1にセットする。 なお、パラメータ i は起動時の開始
値だけ１であるが、以降の循環増分の開始値は０であ
る。

【００９０】ステップＳ２０３３で、メディア復号部３
３４からのACK信号104-i 信号をタイムアウト時間まで
待つ。セットされているなら符号バッファ[i]への書き
込みが許可されており、 ACK信号104-i 信号をリセット
して、Ｓ２０３４へ移る。予め決められたタイムアウト
時間までにACK信号104-i 信号が到着しないなら符号バ
ッファ３１３[i]からの読み出しが未だ終了していない
として、ステップＳ２０３８へ移る。

【００９１】ステップＳ２０３８では、網インターフェ
イス部３５１へパケットのコピーを、予め決められた比
較的短いタイムアウト指定付きで、要求する。この際、
ローカルメモリをコピー先に指定して、パケットヘッダ
だけを要求する。受信データが既にFIFOバッファにある
か、又は、タイムアウト時間以内にパケットが到着すれ
ば、ステップＳ２０３９へ移り、失敗応答ならば、その
ままステップＳ２０３３へ戻る。

【００９２】ステップＳ２０３９では、ローカルメモリ
に取得したパケットヘッダを読み、このパケットのパケ
ット通し番号Ｘ及び イントラフラグＺを取り出す。Ｚ
は符号データの復号にフレーム内符号化方式だけを用い
ている場合は真、さもなくば偽である。この２つの情報
で、このパケットの符号データの復号がメデイア復号部
３３５にて正常に行えるかを判定する。

【００９３】まず、現在の i に対して、j= i-1 とし、
前ループで最後に符号バッファ３１３[j-1]へ書き込ん
だ符号データのパケット通し番号をＬとする。Ｌは前ル
ープでＫとして保存されている。Ｘ＝Ｌ＋１ならば、パ
ケット損失は発生していないので、正判定を行う。さも
なくば、このパケットの符号データと直前にメディア復
号部３３４へ渡した符号データの間に損失した符号デー
タが存在するので、その数を損失パケット数Ｃとして報
告パケット送信部３１６へ発生毎に報告する。その後、
Ｚが真であれば正判定を行い、さもなくば偽判定を行
う。判定が正と出れば、ステップＳ２０４０に移る。

【００９４】判定が偽と出ればこのパケットの符号デー
タは破棄するものとして、網インターフェイス受信部３
４１へこのパケットの符号データをローカルメモリをコ
ピー先に指定して要求し、取得後に破棄し、復号溢れの
回数を破棄パケット数Ｂとして報告パケット送信部３１
６へ報告する。その後、ステップＳ２０３３へ戻る。

【００９５】ステップＳ２０４０で、網インターフェイ
ス受信部３４１へこのパケットの符号データを符号バッ
ファ３１３[i-1]をコピー先に指定して要求し、取得す
る。このとき既に現在のループ中に、ステップＳ２０４
０が実行されて符号バッファ３１３[i-1]に符号データ
が入れられていた場合は、そのデータを上書きしたこと
になるので、復号溢れの回数を破棄パケット数Ｂとして
報告パケット送信部３１６へ報告する。

【００９６】なお、ステップＳ２０３９で新規に取得し
たパケット通し番号 Ｘ を Ｋ として保存しておく。そ
の後、ステップＳ２０３３へ戻る。

【００９７】ステップＳ２０３４では、符号バッファ３
１３[i-1]に対して既に現在のループ中に、ステップＳ
２０４０において符号が読み出されていれば、ステップ
Ｓ２０３７へ移り、されていなければステップＳ２０３
５へ移る。

【００９８】ステップＳ２０３５では、網インターフェ
イス受信部３４１へ受信パケットのコピーを、タイムア
ウト指定無しで要求する。この際、ローカルメモリをコ
ピー先に指定して、パケットヘッダだけを要求する。ロ
ーカルメモリに取得したパケットヘッダを読み、このパ
ケットのパケット通し番号Ｘ及び イントラフラグ Ｚを
取り出す。Ｚは符号データの復号にフレーム内符号化方
式だけを用いている場合は真、さもなくば偽である。

【００９９】この２つの情報で、このパケットの符号デ
ータの復号がメデイア復号部３３４にて正常に行えるか
を以下のように判定する。

【０１００】まず、現在の i に対して、j= i-1 とし、
前ループで最後に符号バッファ[j-1]へ書き込んだ符号
データのパケット通し番号を Ｌ とする。Ｌ は前ルー
プでＫとして保存されている。Ｘ＝Ｌ＋１ならば、パケ
ット損失は発生していないので、正判定を行う。さもな
くば、このパケットの符号データと直前にメディア復号
部３３４へ渡した符号データの間に欠落した符号データ
が存在するので、その数を損失パケット数Ｃとして報告
パケット送信部３１６へ発生毎に報告する。その後、Ｚ
が真であれば正判定を行い、さもなくば偽判定を行う。
判定が正と出れば、ステップＳ２０３６に移る。

【０１０１】判定が偽と出ればこのパケットの符号デー
タは破棄するものとして、網インターフェイス受信部３
４１へこのパケットの符号データをローカルメモリをコ
ピー先に指定して要求し、取得後に破棄し、復号溢れの
回数を破棄パケット数Ｂとして報告パケット送信部３１
６へ報告する。その後、再びステップＳ２０３５の最初
へ戻る。

【０１０２】ステップＳ２０３６で、網インターフェイ
ス受信部３４１へこのパケットの符号データを符号バッ
ファ３１３[i-1]をコピー先に指定して要求し、取得す
る。

【０１０３】なお、ここで取得したＸをＫとして保存し
ておく。その後、ステップＳ２０３７へ移る。

【０１０４】ステップＳ２０３７で、 READY信号102-i
をメディア復号部３３４へ発信し、正常な受信回数を送
信パケット数Ａとして報告パケット送信部３１６へ報告
する。その後、ステップＳ２０３２へ移る。

【０１０５】本具体例では、網インターフェイス受信部
３４１が１つのパケットを２回に分けて、FIFOバッファ
から指定メモリへコピーする機能を有することとした
が、この機能を有しないドライバ上で実装された場合
は、一旦全部ローカルメモリへコピーしてから２回に分
けてコピーする動作を間に挿入することで代用してもよ
い。

【０１０６】＜効果＞以上のように、具体例４によれ
ば、具体例３の効果に加えて、符号バッファに１パケッ
ト分のマージンを持たせる事で、映像メディアの復号処
理に係る演算資源が不足して全ての受信符号を復号でき
ない時に、受信パケットの中から現在正常に復号できる
パケットだけを選択して、符号バッファへコピーする事
が出来て、メディア符号の復号処理に必要な演算資源の
有効化を図りながら、同時に、動き補償演算の誤りに起
因する復号映像の乱れを回避する事が出来るという効果
がある。上記マージンは復号が間に合わない状況でのみ
活用されるので、定常状態では受信から復号開始までの
遅延時間は第１の実勢例での程度に抑えられる。

【図面の簡単な説明】

【図１】本発明による具体例１を示すブロック図であ
る。

【図２】本発明による具体例２を示すブロック図であ
る。

【図３】本発明による具体例３を示すブロック図であ
る。

【図４】具体例３のパケット受信部の動作するフローチ
ャート図である。

【図５】具体例３のメディア復号部の動作するフローチ
ャート図である。

【図６】具体例３の動作するタイムチャート図である。

【図７】具体例３の動作するタイムチャート図である。

【図８】本発明による具体例３を示すブロック図であ
る。

【図９】具体例４のパケット受信部の動作するフローチ
ャート図である。

【符号の説明】

１０１：ＩＰ通信網 ２０１：送信装置 ３０１：受信装置 ２１１：映像取得部 ２１２：映像符号化部 ２１３：パケット送信部 ２１４：網インターフェイス送信部 ２１５：映像情報量決定部 ３１１：網インターフェイス受信部 ３１２：パケット受信部 ３１３： 符号バッファ ３１４：映像映像復号部 ３１５：映像再生部 ３１６：報告パケット送信部

フロントページの続き Ｆターム(参考） 5C059 KK31 KK34 RA01 RE16 SS08 TA17 TA57 TB07 TC45 TD11 UA02 UA05 UA32 5C064 BA01 BA07 BB05 BC10 BC16 BC18 BC20 BC27 BD03 BD05 BD07 BD08 BD09 5K034 AA02 AA06 CC01 CC02 CC05 FF01 HH11 HH12 HH16 HH17 HH27 MM03 MM08 MM11 MM14 MM21 MM24 MM39 NN22 NN31 TT01

Claims (7)

【特許請求の範囲】
1. 【請求項１】 符号化したメディアデータを受信して復
   号するメディアデータ受信装置であって、 前記メディアデータ受信装置で受信するメディアデータ
   を送信するメディアデータ送信装置に対して、符号化し
   たメディアデータの復号状況情報を送信することを特徴
   とするメディアデータ受信装置。
2. 【請求項２】 前記メディアデータ受信装置は、 受信したメディアデータを格納する多バンク構成のバッ
   ファを備えることを特徴とする請求項１に記載のメディ
   アデータ受信装置。
3. 【請求項３】 前記メディアデータ受信装置は、 受信したメディアデータを破棄する際に参照すべき映像
   フレームが欠落している場合には、フレーム間差分符号
   化方式の映像フレームを優先的に破棄することを特徴と
   する請求項１または２に記載のメディアデータ受信装
   置。
4. 【請求項４】 符号化したメディアデータを送信する送
   信装置であって、 前記メディアデータ送信装置から送信するメディアデー
   タを受信して復号するメディアデータ受信装置から送信
   される復号状況情報に基づき、送信するメディアデータ
   の送信量を変更することを特徴とするメディアデータ送
   信装置。
5. 【請求項５】 前記メディアデータの復号状況情報は、 復号処理のできなかった受信パケット数情報を含むこと
   を特徴とする請求項１から４に記載のメディアデータ受
   信またはメディアデータ送信装置。
6. 【請求項６】 前記メディアデータの復号状況情報は、 復号処理のできなかった受信パケット数情報を故意に増
   やして送信することを特徴とする請求項５に記載のメデ
   ィアデータ受信装置。
7. 【請求項７】 前記メディアデータの復号状況情報は、 前記受信装置のＣＰＵの負荷状況情報を含むことを特徴
   とする請求項１から５に記載のメディアデータ受信また
   はメディアデータ送信装置。