JPH09284343A - 蓄積型マルチメディア情報の転送再生方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 パケット紛失を可能な限り減らせるようにし
た蓄積型マルチメディア情報の転送再生装置を提供する
ことにある。 【解決手段】 クライアント２１の動画転送制御部２４
は動画バッファ２２の状態に基づいて動画パケットの転
送の制御を行う。該動画バッファ２２中のパケット数が
予め定められた個数（Ｔｈｒskip）以下になると、動画
転送制御部２４はデータ転送部２３にスキップ要求をす
る。そうすると、該データ転送部２３は再生に遅れたパ
ケットを無視し、自身のバッファ内に受信されている該
パケットに続く順序番号を持つパケットを動画転送制御
部２４に送出する。また、該データ転送部２３は、前記
無視されたパケットを受信済とみなして、サーバ側に送
達確認を返す。このようにすることにより、ファイルな
どの形で蓄積されているマルチメディア情報を転送しつ
つリアルタイムで再生することができると共に、パケッ
ト紛失を低減することができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は蓄積型マルチメデ
ィア情報の転送再生方法および装置に関し、特にパケッ
ト紛失を可能な限り減らせるようにした蓄積型マルチメ
ディア情報の転送再生方法および装置に関する。

【０００２】

【従来の技術】蓄積型マルチメディア情報の転送再生方
法は、ファイル等に蓄積された動画等のマルチメディア
情報を、ネットワークを介して転送しつつ再生するもの
である。従来から該転送再生方法について種々の提案が
なされており、以下に示す(1)〜(4) の方法がよく知ら
れている。

【０００３】(1) 誤り制御を持たない通信プロトコルを
採用し、送信側で、受信側の再生速度に合わせてマルチ
メディア情報を転送する方法、 (2) 誤り制御を持たない通信プロトコルを使用し、受信
側からの要求毎に、送信側から一定量のマルチメディア
情報を転送する方法、 (3) 誤り訂正機能を持つ確認型のプロトコルをそのまま
用いる方法。この方法は、受信側にバッファを設けてデ
ータを先読みし、確認型プロトコルを用いて伝送誤りか
ら回復する。 (4) 再送を1 回に限定した確認型のプロトコルを用いる
方法。この方法では、受信側は、往復伝送遅延に基づい
て設定した時間分マルチメディア情報を蓄積し、その後
に再生を開始する。一方、送信側は、再生レートに応じ
た速度で転送し、再送が要求された場合は、再送パケッ
トが紛失しないように再送を行う。受信側では、1 回の
み再送要求を行い、再送が間に合わないパケットは無視
する。

【０００４】

【発明が解決しようとする課題】しかしながら、前記し
た従来方法には、次のような問題があった。すなわち、
前記した(1) と(2) の方法では紛失したパケットが回復
されないという問題があった。また、前記した(3) の方
法では既存の確認型プロトコルがパケットの到着時間を
保証しないため、リアルタイムな再生が保証されないと
いう問題があった。さらに、前記(4) の方法は、再送を
行うために、回線の状態を見て再送を行ったり、時間的
に間に合わないパケットは送出を禁止する等の複雑な処
理が送信側に要求され、また蓄積されたマルチメディア
情報を先読みするための機能を持たないという問題があ
った。

【０００５】本発明の目的は、前記した従来技術の問題
点を除去し、ファイルなどの形で蓄積されているマルチ
メディア情報を転送しつつリアルタイムに再生する装置
を対象に、クライアント側で情報を先読みし、再生が遅
れない範囲で、確認型プロトコルを用いた誤り回復機能
を提供することで、パケット紛失を可能な限り減らせる
ようにした蓄積型マルチメディア情報の転送再生方法お
よび装置を提供することにある。本発明の他の目的は、
送信側に複雑な処理を要求することなくパケット紛失を
可能な限り減らせるようにした蓄積型マルチメディア情
報の転送再生方法および装置を提供することにある。

【０００６】

【課題を解決するための手段】前記した目的を達成する
ために、この発明は、ファイル等の形で蓄積されている
マルチメディア情報をパケットで転送しつつリアルタイ
ムに再生する蓄積型マルチメディア情報の転送再生方法
において、受信側において、前記マルチメディア情報を
先読みする機能と、転送中に伝送誤り等により紛失した
パケットを再送する機能と、再生に遅れたパケットを無
視し次のパケットを再生処理するスキップ機能とを具備
した点に第１の特徴がある。また、前記無視されたパケ
ットを受信済とみなして、送信側に送達確認を返すよう
にした点に第２の特徴がある。さらに、スキップを要求
した後、前記パケットを再生する表示部が要求する順序
番号が受信したパケットの順序番号より大きい場合に、
再同期を行うようにした点に第３の特徴がある。

【０００７】この発明によれば、再生処理に間に合わな
い紛失パケットのみが捨てられ、該紛失パケットに続く
パケットは有効なパケットとして再生処理されるので、
パケット紛失を可能な限り低減することができる。ま
た、前記スキップ処理は受信側においてなされるので、
送信側に複雑な処理を要求することがなくなる。

【０００８】

【発明の実施の形態】以下に、図面を参照して、本発明
を詳細に説明する。図１は、ファイルに蓄積された動画
情報の検索を対象とした動画検索装置の一実施形態の概
略の構成を示すブロック図である。

【０００９】図示されているように、該動画検索装置
は、動画情報をＡＴＭネットワーク１へ送出するサーバ
１１と、これを受信し再生するクライアント２１から構
成されている。該サーバ１１は、動画情報をファイル形
式で記憶するファイル装置１２と、該ファイル装置１２
のファイルの入出力を制御するためのファイル制御部１
３と、クライアント側の動画バッファ２２の状態に基づ
いて、動画パケットの転送の制御を行う動画転送制御部
１４と、確認型プロトコルを用いてデータを転送するデ
ータ転送部１５とから構成されている。

【００１０】また、クライアント２１は、受信した動画
情報を一時蓄積する動画バッファ２２と、確認型プロト
コルを用いてデータを転送するデータ転送部２３と、動
画バッファ２２の状態に基づいて動画パケットの転送の
制御を行うと共に受信した動画パケットを動画バッファ
２２に書込む動画転送制御部２４と、受信した動画パケ
ットを表示するための表示部２５とから構成されてい
る。

【００１１】本実施形態では、データ転送部１５，２３
と、動画転送制御部１４，２４に対して、以下の要領で
プロトコルを規定する。データ転送部１５，２３のため
のプロトコルは、ＡＴＭ上の確認型データ転送プロトコ
ルＳＳＣＯＰ(Service Specific Connection Oriented
Protcol)をベースに規定する。ＳＳＣＯＰにスキップ機
能を実装するために、動画転送制御部１４，２４からの
要求により、到着していないデータ送信用ＰＤＵ(Proto
col DataUnit) を受信したものとみなし、その受信応答
を行い、以降のパケットを上位に通知可能とする。

【００１２】一方、動画転送制御部１４，２４では、ク
ライアント側に設けた動画バッファ２２に基づいて、動
画情報のフロー制御、再生に間に合わない場合のスキッ
プの要求、再同期の機能を提供する。

【００１３】次に、前記データ転送部１５，２３のプロ
トコルの一例を図２に示す。該データ転送部１５，２３
のプロトコルはＳＳＣＯＰをベースとして作成されてい
るので、まず該ＳＳＣＯＰの機能について説明すること
にする。ＳＳＣＯＰは、下記の(1) 〜(5) の機能を提供
するものである。

【００１４】(1) ユーザデータの順序保存 送信側は、上位から渡されたユーザデータに順序番号を
含むトレイラを付加し、ＳＤ(Sequenced Data)ＰＤＵを
作成して送出する。受信側は、順序番号に従ってユーザ
データを上位に通知する。

【００１５】(2) ＳＤの送達確認 以下の２つのＰＤＵによりＳＤの送達確認を行う。・送
信側から送られたＰＯＬＬ ＰＤＵに対して、受信側が
送出するＳＴＡＴ(Solicited Status) ＰＤＵ。・誤っ
た順序でＳＤが受信された場合に、受信側が送出するＵ
ＳＴＡＴ(Unsolicited Status) ＰＤＵ。 (3) 選択再送による誤り回復 受信側は、受信したＳＤの順序番号を検査することで、
ＳＤの紛失を検出する。紛失したＳＤの順序番号は、Ｓ
ＴＡＴまたはＵＳＴＡＴによって送信側へ通知する。こ
の際、連続して紛失したＳＤのグループ( 紛失ＳＤグル
ープ) とそれに続く受信したＳＤのグループ( 受信ＳＤ
グループ) を順に書き込む。送信側は、紛失を通知され
たＳＤのみを選択的に再送する。なお、ＳＴＡＴとＵＳ
ＴＡＴによる再送が重複しないように、ＰＯＬＬに対し
てＳＤとは独立な順序番号を設けている。

【００１６】(4) フロー制御 送信側は、ＳＴＡＴ・ＵＳＴＡＴ等で受信側から通知さ
れるウインドウの上限値に基づいて、フロー制御に用い
るウインドウを決定し、その範囲内でＳＤを送出する。

【００１７】(5) 非確認型のデータ転送 送信側は、確認型のＳＤ ＰＤＵの他に、送達確認・誤
り回復・フロー制御機能の無いＵＤ(Unit Data) ＰＤＵ
を用いて非確認型のデータ転送を行うことも可能であ
る。

【００１８】本実施形態は、このＳＳＣＯＰに対して、
再生に間に合わないＳＤを受信済として扱うスキップ機
能を、以下の(6) 〜(8) の方法で実現した点を特徴とし
ている。

【００１９】(6) ＳＳＣＯＰにスキップを要求するプリ
ミティブ(AA-SKIP.request) を用意する。 (7) ＳＳＣＯＰでは、上位よりＡＡ−ＳＫＩＰ．reques
t （要求）を受け取った場合、未受信ＳＤ中で最も順序
番号の小さいＳＤを含む紛失ＳＤグループ全体を受信済
とみなす。そして、紛失ＳＤグループに連続する順序番
号を持つＳＤがプロトコルバッファに存在している場合
は、上位へ通知する。 (8) 受信済とみなしたＳＤについては、後に受信した場
合は無視し、ＰＯＬＬに対するＳＴＡＴで送達確認を返
す。

【００２０】次に、本実施形態の特徴であるスキップ機
能を含むＳＳＣＯＰの通信シーケンス例を、図２を参照
して説明する。

【００２１】サーバ（送信）側のデータ転送部１５か
ら順序番号Ｎ(S) を持つＳＤ（図中のSD(0) ）が転送さ
れると、クライアント（受信）側のデータ転送部２３は
これを受信し、受信したことを上位の動画像転送制御部
２４に通知する。動画像転送制御部２４は通知を受ける
と、動画バッファ２２に格納する。

【００２２】次に転送されたＳＤ(1) が送信途中で紛
失すると、受信側のデータ転送部２３は該ＳＤ(1) が紛
失したことを次のＳＤ(2) の受信により検知する。そし
て、該データ転送部２３はＵＳＴＡＴを用いて送信側へ
ＳＤ(1) の再送を要求する。ＵＳＴＡＴには、次に受信
すべきＳＤの順序番号Ｎ(R)(＝１) 、受信ウインドウＮ
(MR)（＝９）( ウインドウサイズ８を仮定している) 、
紛失ＳＤグループを示すリストエレメント(={1,2})が書
き込まれている。送信側はこのＵＳＴＡＴ受信により、
送達確認されたＳＤ(0) の解放、ウインドウの更新、紛
失を通知されたＳＤ(1) の再送を行う。ここに、前記
{1,2} は、１以上２未満の整数、すなわち１であること
を示している。以下においても同様である。

【００２３】送信側は、一定時間毎あるいは一定のＳ
Ｄ送出回数毎に、ＰＯＬＬを送出する。ＰＯＬＬは次に
送出されるＳＤのＮ(S) と、自身の順序番号Ｎ(PS)を持
つ。ＰＯＬＬ(4,1) を受信した受信側は、次に受信すべ
きＳＤの順序番号Ｎ(R) （＝１）、対応するＰＯＬＬ順
序番号Ｎ(PS)（＝１）、受信ウインドウＮ(MR)（＝
９）、紛失ＳＤグループ(=[1,2):SD(1) を表す) と受信
ＳＤグループ(=[2,4))を示すリストエレメント＝{1,2,
4} を含むＳＴＡＴを送出する。ここに、{1,2,4} は、
紛失ＳＤが１以上２未満のものであり、受信済みのＳＤ
が２以上４未満のものであることを示している。

【００２４】送信側はこのＳＴＡＴ受信に対して、紛
失ＳＤグループ(=[1,2))に対する再送処理、受信ＳＤグ
ループに対応するＳＤ(2) とＳＤ(3) の解放、ウインド
ウの更新を行う。ただしこの例では、ＳＤ(1) がＰＯＬ
Ｌ(4,1) 送出後に再送されているため、新たな再送は行
わない。これは、ＳＤ送出時点で保持されたＰＯＬＬ順
序番号と、ＳＴＡＴ中のＮ(PS)を比較することで判断さ
れる。

【００２５】一方、ＰＯＬＬ(7,2) に対応するＳＴＡ
Ｔ受信では、ＳＴＡＴのＮ(PS)（＝２）がＳＤ(6) 送出
時のＰＯＬＬ順序番号（＝１）より大きいため、要求さ
れたＳＤ(6) を再送する。

【００２６】受信側の上位の動画転送制御部２３から
ＡＡ−ＳＫＩＰ．request によりスキップを要求される
と、ＳＳＣＯＰでは、ＳＤ(6) を受信済とみなし、ＳＤ
(7)を上位の動画転送制御部２３へ通知する。この結果
Ｎ(R) ＝８となり、以降のＳＴＡＴを用いて送信側にＳ
Ｄ(6) を送達確認させる。この処理を実行した後に受信
したＳＤ(6) は破棄される。なお、前記ＡＡ−ＳＫＩ
Ｐ．request は、後述されるように、ＳＤ(6) の表示時
間が来たことを条件に動画転送制御部２３から出力され
る。

【００２７】以上の説明から明らかなように、受信側は
最初は一定量のＳＤを受信すると順次所定の時間間隔で
表示を開始し、表示すべきＳＤの時間が来ても該ＳＤが
受信されていない時にはスキップ要求が出されて、該Ｓ
Ｄはスキップされることになる。

【００２８】次に、動画転送制御部１４，２４のプロト
コルについて説明する。動画転送制御部のプロトコル
は、前述のように、クライアント側の動画バッファ２２
を用いて、フロー制御、スキップ機能の起動、再同期の
処理を行う。本プロトコルが使用するＰＤＵを図３に示
す。サーバの動画転送制御部１４はＤＡＴＡ ＰＤＵを
用いて動画情報をクライアントへ転送する。この際、動
画情報はファイルから固定サイズで読み出され、Messag
e パラメータに格納される。また、SequenceNumberパラ
メータでは、ファイルごとのＤＡＴＡの順序番号が運ば
れる。

【００２９】一方、ＳＴＯＰならびにＧＯ ＰＤＵは、
クライアントが、サーバからのＤＡＴＡ送信の停止・再
開を要求するために用いられる。さらに、クライアント
は、再生すべき動画情報を含むＤＡＴＡのSequenceNumb
erを含むＲＥＳＹＮＣ ＰＤＵを送信することにより、
動画情報の再同期を要求することができる。これらの全
てのＰＤＵは、ＳＳＣＯＰでＳＤ ＰＤＵを用いて転送
される。

【００３０】次に、前記動画転送制御部１４，２４のプ
ロトコルを、図４、図５を参照して説明する。図４はサ
ーバ側の動画転送制御部１４のプロトコルを示し、図５
はクライアント側の動画転送制御部１５のプロトコルを
示す。

【００３１】サーバ側の動画転送制御部１４は、図４の
ステップＳ１において、ファイル制御部１３から渡され
た動画情報をＤＡＴＡとして送信する。ステップＳ２で
は、全ての動画情報が転送されたか否かの判断がなさ
れ、この判断が否定の時には、ステップＳ３に進む。ス
テップＳ３では、受信側からのＰＤＵを受信したか否か
の判断がなされる。この判断が否定の時にはステップＳ
１に戻り、次の動画情報をＤＡＴＡとして送信する。一
方、この判断が肯定の時には、ステップＳ４に進んで、
受信したＰＤＵが、ＳＴＯＰ ＰＤＵであるかＲＥＳＹ
ＮＣ ＰＤＵであるかの判断がなされる。ＳＴＯＰ Ｐ
ＤＵである場合には、ステップＳ５に進んで受信側から
ＧＯ ＰＤＵが到来するまで待機する。一方、ＲＥＳＹ
ＮＣ ＰＤＵである場合には、ステップＳ６に進んで、
次のＤＡＴＡの順序番号がＭＡＸ（ＲＥＳＹＮＣの順序
番号，送信済ＤＡＴＡ順序番号）から求められる。ステ
ップＳ５またはＳ６の処理が終わると、再度ステップＳ
１に戻り、前記と同様の動作が繰返される。上記した動
作が繰返し行われ、最後に前記したステップＳ２の判断
が肯定になると、ステップＳ７に進んで終了処理が行わ
れる。

【００３２】次に、クライアント側の動画転送制御部２
４のプロトコルを、図５を参照して説明する。ステップ
Ｓ１１では、送信側から送られてくるＤＡＴＡの受信を
待ち、ステップＳ１２では該ＤＡＴＡを受信する。受信
されたＤＡＴＡは動画バッファ２２に格納される。ステ
ップＳ１３では、転送動作が終了したか否かの判断を
し、この判断が否定の時にはステップＳ１４に進む。ス
テップＳ１４では、動画バッファ２２内に予め定められ
た数のパケット、すなわちＴｈｒinitより多くのパケッ
トが蓄積されたか否かの判断がなされる。この判断が否
定の場合にはステップＳ１１に戻って、ＤＡＴＡの受信
を行う。

【００３３】以上のようにして、動画バッファ２２内に
Ｔｈｒinit以上のパケットが蓄積されると、ステップＳ
１４の判断は肯定になり、ステップＳ１５に進む。ステ
ップＳ１５では、ＤＡＴＡが表示可能になったことが表
示部２５に通知される。該通知があると表示部２５は予
め定められた時間間隔で動画バッファ２２からＤＡＴＡ
を読みだし、再生を開始する。

【００３４】次に、ステップＳ１６に進んで、イベント
の入力待ちとなる。入力してきたイベントがＤＡＴＡ受
信であった場合には、ステップＳ１７に進む。ステップ
Ｓ１７では送信されてきたＤＡＴＡを受信し、前記動画
バッファ２２に格納する。次に、ステップＳ１８に進
み、ＤＡＴＡの転送終了か否かの判断を行う。この判断
が否定の時には、再びステップＳ１６に戻って、イベン
トの入力を待機する。

【００３５】次に、入力してきたイベントが、動画バッ
ファ２２のパケット数がＴｈｒstop以上になったという
通知であった場合、すなわち動画バッファ２２満杯に近
くなり、ＤＡＴＡの蓄積が困難になった場合には、ステ
ップＳ２０、Ｓ２１に進む。ステップＳ２１では、ＳＴ
ＯＰ ＰＤＵを送信側に送出する。これは、図４のステ
ップＳ４に対応する。また、前記入力してきたイベント
が、動画バッファ２２のパケット数がＴｈｒgo以下にな
ったという通知であった場合、すなわち動画バッファ２
２に余裕ができ、ＤＡＴＡの蓄積が可能になった場合に
は、ステップＳ２２、Ｓ２３に進む。ステップＳ２３で
は、ＧＯ ＰＤＵを送信側に送出する。これは、図４の
ステップＳ５に対応する。

【００３６】次に、前記入力してきたイベントが、動画
バッファ２２のパケット数がＴｈｒskip以下になったと
いう通知であった場合、すなわち動画バッファ２２に蓄
積されているＤＡＴＡが０になった場合には、ステップ
Ｓ２４、Ｓ２５に進む。ステップＳ２５では、データ転
送部２３に対してスキップ要求を行う。このスキップ要
求は、図２のＡＡ−ＳＫＩＰ．request に相当する。そ
うすると、データ転送部２３は未受信のＤＡＴＡをスキ
ップし、既に受信し自身のバッファに記憶している後続
のＤＡＴＡを動画転送制御部２４に送る。この結果、動
画バッファ２２には、該ＤＡＴＡが格納され、該ＤＡＴ
Ａは表示部２５にて表示されることになる。

【００３７】スキップを要求した後、クライアント側
は、ステップＳ２６にて、スキップの結果通知されたＤ
ＡＴＡ、または、スキップの結果ＤＡＴＡが通知されな
い場合は、スキップ直前に受信したＤＡＴＡの順序番号
（SequenceNumber）と、表示部２５の要求するＤＡＴＡ
の順序番号（SequenceNumber）とを比較する。受信した
ＤＡＴＡの順序番号が小さい場合（ステップＳ２６の判
断が肯定）は、転送中の動画情報と表示すべき動画情報
の同期がとれていないと判断し、要求する順序番号を含
むＲＥＳＹＮＣを送出する。ただし、ＲＥＳＹＮＣが無
駄に送出されるのを防ぐために、この処理は一定間隔ご
とに行われる。サーバ側は、図４のステップＳ４にて、
ＲＥＳＹＮＣを受信すると、ＲＥＳＹＮＣの順序番号と
送信済のＤＡＴＡの順序番号を比較し、前者が大きい場
合は、要求されたＤＡＴＡを送信する。このようにし
て、例えば、バースト誤り等で長期間、動画情報が配達
されない場合の再同期が可能になる。最後に、ステップ
Ｓ１３が肯定になると、ステップＳ２８に進んで、該転
送終了を表示部２５に通知した後、一連の処理を終了す
る。

【００３８】

【発明の効果】本発明による蓄積型マルチメディア情報
の転送再生装置の効果を評価するため、ワークステーシ
ョン上に、データ転送部と動画転送制御部を含む評価シ
ステムを実装し、再生を考慮した動画パケットの転送性
能を評価した。なお、本発明と従来方式との比較を行う
ために、次の２つの従来方式、すなわち単純再送方式お
よび非再送方式も実装した。

【００３９】ここに、単純再送方式はＳＳＣＯＰの再送
機能と動画バッファを用いた先読み機能により動画情報
を転送する方式である。データ転送部には、スキップ機
能のない通常のＳＳＣＯＰを使用し、動画転送制御部で
は、動画バッファに対するフロー制御機能のみを提供す
る。一方、非再送方式は、動画検索に通常使用されてい
る方式で、ＳＳＣＯＰのＵＤ ＰＤＵ( 再送により回復
されない) を用いて、再生速度に合わせて動画パケット
を転送する方式である。

【００４０】図６は、本発明装置と単純再送方式と非再
送方式が有する機能をまとめたものである。本発明装置
では、スキップと再同期の機能を有しているが、単純再
送方式と非再送方式はこれらの機能を具備していない。

【００４１】図７は、本発明と前記した従来方式との効
果を比較するために使用した実験構成を示すブロック図
である。サーバとクライアントはSUN Sparc Station20
(SS20: クロック周波数60MHz x 2 、Solaris2.4) に実
装し、ＡＴＭボード(FORE Systems SBA200) ならびにＡ
ＴＭスイッチ(FORE Systems ASX200) を介して通信を行
う。また、ＡＴＭスイッチには伝送遅延ならびに伝送誤
りを付加するためのデータチャネルシミュレータ(ADTEC
H SX14) を接続した。

【００４２】実験では、データチャネルシミュレータに
よりＢＥＲ＝１Ｅ−６のランダムビット誤りを付加した
ATM 回線上で、サーバから１００，０００Ｋbyteの動画
情報を１Ｋbyteごとに転送し、クライアントにおいて
１．５Ｍbps のレートで再生することを想定した。ま
た、往復伝送時間(Round Trip Time :ＲＴＴ) の値につ
いては、２０msec、２００msec、６００msecを用いた。
その際に、再生時間に間に合わないか、伝送誤りにより
紛失したかの理由により、再生できなかったＤＡＴＡ
ＰＤＵの数を測定した。なお、前記した３つの方式の
内、本発明装置と単純再送方式においては、ＲＴＴの値
に応じて、図８に示すパラメータ値を用いた。

【００４３】図９は、前記のようにして行った実験結果
を示す図である。本発明装置では、全てのＲＴＴにおい
て最も良い結果が得られており、非再送方式と比較し
て、再生できないＤＡＴＡ ＰＤＵ数を１／１００以下
に低減している。また、単純再送方式では、ＲＴＴの増
加に伴い、本発明装置と比較して、再生できないＤＡＴ
Ａ ＰＤＵの数が多くなっている。

【００４４】以上のように、本発明によれば、再生でき
ないＤＡＴＡ ＰＤＵ数、すなわち紛失パケット数を従
来の方式に比べて大きく低減することができるという効
果がある。

【００４５】また、本発明によれば、受信側において、
再生に遅れたパケットを無視し次のパケットを再生処理
するようにされているので、送信側は通常の再送機能の
みを有しておれば良く、従来方式のように、複雑な処理
を要求されないという効果がある。また、受信側におい
ても、複雑な処理を要求されないという効果がある。

【図面の簡単な説明】

【図１】 本発明の一実施形態の概略の構成を示すブロ
ック図である。

【図２】 データ転送部のプロトコルを示す通信シーケ
ンス図である。

【図３】 動画転送制御プロトコルのＰＤＵおよびパラ
メータを示す図である。

【図４】 サーバ側の動画転送制御部の動作を示すフロ
ーチャートである。

【図５】 クライアント側の動画転送制御部の動作を示
すフローチャートである。

【図６】 本発明装置と従来の再送方式との機能の違い
を説明する図である。

【図７】 実験に使用する装置の構成を示すブロック図
である。

【図８】 本発明装置と単純再送方式のパラメータ値を
示す図である。

【図９】 実験結果（再生されないＤＡＴＡ ＰＤＵ
数）を示す図である。

【符号の説明】

１…ＡＴＭネットワーク、１１…サーバ、１２…ファイ
ル装置、１３…ファイル制御部、１４…動画転送制御
部、１５…データ転送部、２１…クライアント、２２…
動画バッファ、２３…データ転送部、２４…動画転送制
御部、２５…表示部。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 鈴木 健二 東京都新宿区西新宿２丁目３番２号 国際 電信電話株式会社内

Claims (6)

【特許請求の範囲】
1. 【請求項１】 ファイル等の形で蓄積されているマルチ
   メディア情報をパケットで転送しつつリアルタイムに再
   生する蓄積型マルチメディア情報の転送再生方法におい
   て、 受信側において、前記マルチメディア情報を先読みする
   機能と、 転送中に伝送誤り等により紛失したパケットを再送する
   機能と、 再生に遅れたパケットを無視し次のパケットを再生処理
   するスキップ機能とを具備したことを特徴とする蓄積型
   マルチメディア情報の転送再生方法。
2. 【請求項２】 請求項１の蓄積型マルチメディア情報の
   転送再生方法において、 パケットの転送プロトコルに対して前記無視されたパケ
   ットを受信済とみなして、送信側に送達確認を返す機能
   を追加したことを特徴とする蓄積型マルチメディア情報
   の転送再生方法。
3. 【請求項３】 請求項１の蓄積型マルチメディア情報の
   転送再生方法において、 スキップを要求した後、前記パケットを再生する表示部
   が要求する順序番号が受信したパケットの順序番号より
   大きい場合に、再同期を行うようにしたことを特徴とす
   る蓄積型マルチメディア情報の転送再生方法。
4. 【請求項４】 請求項３の蓄積型マルチメディア情報の
   転送再生方法において、 送信側は再同期の指示を受信すると、再同期の順序番号
   と送信済のパケットの順序番号とを比較し、前者が大き
   い場合には該再同期の順序番号のパケットを送出するよ
   うにしたことを特徴とする蓄積型マルチメディア情報の
   転送再生方法。
5. 【請求項５】 ファイル等の形で蓄積されているマルチ
   メディア情報をパケットで転送しつつリアルタイムに再
   生する蓄積型マルチメディア情報の転送再生装置におい
   て、 受信した動画情報を一時蓄積する動画バッファと、 選択機能をもつ確認型プロトコルを用いてデータを転送
   するデータ転送部と、 前記動画バッファの状態に基づいて動画パケットの転送
   の制御を行うと共に受信した動画パケットを動画バッフ
   ァに書込む動画転送制御部と、 受信した動画パケットを表示するための表示部とを具備
   し、 前記動画転送制御部は前記動画バッファ内のパケット数
   が所定数以下になった時に、前記データ転送部にスキッ
   プ要求を行うようにしたことを特徴とする蓄積型マルチ
   メディア情報の転送再生装置。
6. 【請求項６】 請求項５の蓄積型マルチメディア情報の
   転送再生装置において、 前記データ転送部は前記動画転送制御部からスキップ要
   求を受けると、紛失パケットに続く、自身のバッファ内
   に格納しているパケットを該動画転送制御部に送出する
   ことを特徴とする蓄積型マルチメディア情報の転送再生
   装置。