(57)【要約】【課題】本発明は逆転ストリームパケットの補正方法及び装置に関し、受信したパケットのデコードを行なった場合でも画像の乱れ等の品質の低下を防止することができる逆転ストリームパケットの補正方法及び装置を提供することを目的としている。【解決手段】ＩＰネットワーク上にＭＰＥＧストリームパケットを流し、リアルタイムに画像配信を行なうシステムにおいて、ＭＰＥＧストリームパケットを受信するパケット受信部１０と、受信したパケットからＲＴＰヘッダを抽出するＲＴＰヘッダ情報抽出部１１と、抽出したＲＴＰヘッダから更にパケットのシーケンス番号を抽出するシーケンス番号抽出部１２と、該シーケンス番号抽出部１２から抽出されたシーケンス番号を元にパケットの順序を補正するパケット順序補正部１３と、を含んで構成される。【選択図】      図２
2004328353.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークを介して受信したＭＰＥＧストリームパケットを流し、リアルタイムに画像配信を行なうシステムにおいて、ＩＰネットワークを介して受信したＭＰＥＧストリームパケットからＲＴＰヘッダ情報を取り出し（ステップ１）、
次に、ＲＴＰヘッダ内のパケット送信順序を示すシーケンス番号情報を取り出し（ステップ２）、
取り出したシーケンス番号を元にパケットの受信順序の誤りを識別し、パケット送信順序に従って処理を行なう（ステップ３）
ようにしたことを特徴とする逆転ストリームパケットの補正方法。
【請求項２】
ＩＰネットワーク上にＭＰＥＧストリームパケットを流し、リアルタイムに画像配信を行なうシステムにおいて、
ＭＰＥＧストリームパケットを受信するパケット受信部と、
受信したパケットからＲＴＰヘッダを抽出するＲＴＰヘッダ情報抽出部と、
抽出したＲＴＰヘッダから更にパケットのシーケンス番号を抽出するシーケンス番号抽出部と、
該シーケンス番号抽出部から抽出されたシーケンス番号を元にパケットの順序を補正するパケット順序補正部と、
を含んで構成される逆転ストリームパケットの補正装置。
【請求項３】
前記パケット順序補正部は、パケット逆転が発生した場合には、それをどの程度まで保証するかの閾値として保証数範囲を設け、最後にデコード要求を行なったストリームのシーケンス番号から閾値までを範囲とすることを特徴とする請求項２記載の逆転ストリームパケットの補正装置。
【請求項４】
前記パケット順序補正部は、逆転しているパケットをどの程度まで保持させるの閾値として最大保持数を設け、その値は請求項３記載の保証数範囲と同じとすることを特徴とする請求項２記載の逆転ストリームパケットの補正装置。
【請求項５】
保持したストリームや、最後にデコード要求を行なったストリーム情報を管理するため、ストリーム管理テーブルを設け、ストリームの一括管理を行なうようにしたことを特徴とする請求項２記載の逆転ストリームパケットの補正装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は逆転ストリームパケットの補正方法及び装置に関する。マルチメディア時代を迎え、通信回線網等のインフラの拡充が進んでいる。しかしながら、画像データの情報量は大きいため、そのままのデータを転送しようとすると、依然として通信時間が長くなったり、通信回線の負荷が増大するといったことが問題となる。このような問題を解決する技術として、ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）やＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｃｏｄｉｎｇ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）方式の画像圧縮技術が用いられる。このうち、ＭＰＥＧ方式は、主として動画像（ビデオデータ）の圧縮に用いられる他、音声データを圧縮し、ビデオデータに多重化することもできる。
【０００２】
【従来の技術】
前述した画像圧縮技術として用いられるＭＰＥＧ方式には、ＭＰＥＧ１，ＭＰＥＧ２，ＭＰＥＧ４といったものがある。従来のこの種の技術としては、ＭＰＥＧパケットのＰＥＳプライベートデータ領域に、当初のＭＰＥＧデータストリームにおけるパケットグループの並びと、生成したＭＰＥＧデータパケット列におけるパケットグループの並びとの対応関係を記述した順序テーブルを設け、これにより、当初のパケットグループの順序を把握し、パケットグループの順序を任意に変更することができるようにしたシステムが知られている（例えば特許文献１参照）。
【０００３】
図７は従来のデータ転送システムの概念図である。図において、１はカメラ、２は該カメラ１で撮影したＮＴＳＣ信号を受けて変調を行なうエンコーダである。この例では、カメラ１としてカメラ１〜カメラ３までの３台、エンコーダ２としてエンコーダ１〜エンコーダ３までの３台を示している。３はエンコーダ２の出力信号が転送されるネットワークである。これらエンコーダ２の出力は、ＭＰＥＧデータとなり、ＭＰＥＧストリームパケット配信となる。
【０００４】
４はネットワーク３と接続され、エンコーダ２の出力信号であるＭＰＥＧデータを受信して元のＮＴＳＣ信号に戻すデコーダである。５はデコーダ４と接続され、ＮＴＳＣ画像を表示するモニタである。図に示す例では、デコーダがデコーダ１，デコーダ２の２台、モニタ５がモニタ１，モニタ２の２台設けられた例を示している。６はネットワーク３と接続される管理サーバ、７は同じくネットワーク３と接続されるパソコン（ＰＣ）である。このように構成されたシステムの概要を説明すれば、以下の通りである。
【０００５】
この図に示すシステムは、ＩＰネットワーク上にＭＰＥＧストリームパケットを流し、リアルタイムに画像配信を行なうシステムを示している。図中のエンコーダ１〜３は、それぞれＮＴＳＣ映像／音声入力及びＩＰインタフェースを持ち、カメラ１から入力されたＮＴＳＣ映像／音声データをＭＰＥＧストリームにエンコードし、ＭＰＥＧストリームパケットをＩＰネットワーク上に配信する機能を持つ。
【０００６】
また、図中のデコーダ１，デコーダ２は、それぞれＮＴＳＣ映像／音声出力及びＩＰネットワークインタフェースを持ち、ライブ受信したＭＰＥＧストリームパケットをＮＴＳＣ映像／音声データにデコードし、モニタ５に出力する機能を持つ。
【０００７】
このようなシステムにより、マルチキャスト或いはユニキャストにてＩＰネットワーク上の多数のモニタに同時に配信できる。更に、これらの装置は、管理サーバ６及びパソコン（ＰＣ）７により一括設定することができる。例えば、エンコーダ１からの映像／音声をデコーダ１で受信してモニタ１に表示していたものを管理サーバ６又はパソコン７によりデコーダ２で受信してモニタ２に表示するように切替設定することができる。
【０００８】
エンコーダ、デコーダの装置構成を以下に示す。図８はエンコーダ２の内部構成例を示す図である。図において、２ａは例えばカメラからのＮＴＳＣデータを受けてエンコードするエンコーダ部であり、ＮＴＳＣデータをＭＰＥＧデータに変換する。２ｂはエンコーダ部２ａの出力であるＭＰＥＧデータを送信する送信部である。該送信部２ｂからＭＰＥＧストリームパケット配信が行なわれる。
【０００９】
図９はデコーダ４の内部構成例を示す図である。図において、４ａは例えばエンコーダ２からのＭＰＥＧストリームパケットを受信する受信部である。４ｂは該受信部４ａの出力であるＭＰＥＧデータを、デコードしてＮＴＳＣデータに変換するデコーダ部である。該デコーダ部４ｂの出力は、例えばモニタに接続され、画像表示が行なわれる。
【００１０】
図１０はＭＰＥＧストリームパケットの構成例を示す図である。ＭＰＥＧストリームパケットの構成例を示す図である。ＭＰＥＧストリームパケットは、大きく分けてＲＴＰヘッダとペイロード部の２つから構成されている。ＲＴＰヘッダは、エンコーダがＭＰＥＧストリームパケットをＩＰネットワークに配信する際に送信部で付加され、そのヘッダ内には、パケットの配信順序を示すシーケンス番号が格納されている。
【００１１】
パケットは１行あたり０ビットから３１ビットまでの３２ビットで構成され、０〜６５５３５の範囲でサイクリックに採番されている。この番号により、デコーダ側は受信パケットやストリーム切り替えの発生を認識している。
【００１２】
ＲＴＰヘッダにおいて、Ｖはバージョン、Ｐはパディング、Ｘはエクステンション、ＣＣはＣＳＲＣカウント、ＭはＲＡＰのフラグを示すマーカ、ＰＴはペイロードタイプ、シーケンス番号はパケットの連続番号を示す。タイムスタンプは時刻情報である。
【００１３】
ペイロード部において、ＭＰＥＧ圧縮モードは、圧縮のモード（例えばＭＰＥＧ１かＭＰＥＧ２か等）を示し、時刻はＲＡＰフラグが立った時に表示される。その後にはＭＰＥＧ実データが入る。
【００１４】
エンコーダからネットワークに配信されたＭＰＥＧストリームパケットをデコーダの受信部にて受信した時の受信フローチャートを図１１に示す。ストリームパケットを受信すると（Ｓ１）、パケット受信数をカウントする（Ｓ２）。次に、ＲＴＰヘッダ情報をチェックする（Ｓ３）。そして、ストリームサイズをチェックする（Ｓ４）。
【００１５】
次に、受信パケットがおかしくないかどうかチェックする（Ｓ５）。ここで、受信パケットがおかしいとは、例えば受信パケットデータが壊れていることをいう。受信パケットがおかしい場合には、その受信ストリームを破棄し（Ｓ６）、ステップＳ１に戻り、パケット受信ステップからやりなおす。受信パケットがおかしくない場合には、パケット抜けをチェックし（Ｓ７）、受信ストリームをデコード要求する（Ｓ８）。そして、次のパケット受信処理に入る。
【００１６】
以上の説明より明らかなように、受信部にて受信されたＭＰＥＧストリームパケットは、受信部内において初めにＲＴＰヘッダ内の情報のチェックが行なわれ、その後にシーケンス番号のチェックが行なわれる。従来の技術では、パケット逆転が発生していたとしても、パケットの受信順に従って、デコーダ部にデコード要求を行なっている。
【００１７】
【特許文献１】
特開平１０−３１２６４８号公報（第６頁、図１）
【００１８】
【発明が解決しようとする課題】
前述したように、ＭＰＥＧストリームを逆転して受信した場合、従来のパケット受信処理では、エンコーダが送信した順序とは異なった順序でデコード要求がなされる。そのため、データが抜けていないにもかかわらず画像が乱れてしまい、品質の低下が課題とされている。特に、ＭＰＥＧ４に関しては、データサイズが小さく、パケットが逆転する頻度が高くなるため、ＭＰＥＧ１やＭＰＥＧ２に比べると更に画像が乱れてしまうという問題があった。
【００１９】
本発明はこのような課題に鑑みてなされたものであって、受信したパケットのデコードを行なった場合でも画像の乱れ等の品質の低下を防止することができる逆転ストリームパケットの補正方法及び装置を提供することを目的としている。
【００２０】
【課題を解決するための手段】
（１）請求項１記載の発明は、以下の通りである。図１は本発明方法の原理を示すフローチャートである。本発明は、ＩＰネットワークを介して受信したＭＰＥＧストリームパケットを流し、リアルタイムに画像配信を行なうシステムにおいて、ＩＰネットワークを介して受信したＭＰＥＧストリームパケットからＲＴＰヘッダ情報を取り出し（ステップ１）、次に、ＲＴＰヘッダ内のパケット送信順序を示すシーケンス番号情報を取り出し（ステップ２）、取り出したシーケンス番号を元にパケットの受信順序の誤りを識別し、パケット送信順序に従って処理を行なう（ステップ３）ようにしたことを特徴とする。
【００２１】
このように構成すれば、シーケンス番号を元に、受信したパケットデータをデコードする時に、パケット着信順ではなく、シーケンス番号順にデコードするようにしているため、デコードされた画像に乱れがなく、品質の低下を防止することができる。
（２）請求項２記載の発明は、以下の通りである。図２は本発明の原理ブロック図である。図に示す装置は、ＩＰネットワーク上にＭＰＥＧストリームパケットを流し、リアルタイムに画像配信を行なうシステムのデコード部分を示している。図において、１０はＭＰＥＧストリームパケットを受信するパケット受信部、１１は受信したパケットからＲＴＰヘッダを抽出するＲＴＰヘッダ情報抽出部、１２は抽出したＲＴＰヘッダから更にパケットのシーケンス番号を抽出するシーケンス番号抽出部、１３は該シーケンス番号抽出部１２から抽出されたシーケンス番号を元にパケットの順序を補正するパケット順序補正部である。
【００２２】
このように構成すれば、パケット受信時のパケット着信順序がパケット送信時と比較して狂っていても、パケット順序補正部１３がパケット送信順に従ってデコード処理を行なうようにすることで、デコードされた画像に乱れがなく、品質の低下を防止することができる。
（３）請求項３記載の発明は、前記パケット順序補正部１３は、パケット逆転が発生した場合には、それをどの程度まで保証するかの閾値として保証数範囲を設け、最後にデコード要求を行なったストリームのシーケンス番号から閾値までを範囲とすることを特徴とする。
【００２３】
このように構成すれば、パケット逆転を補正するための保証数範囲を予め設定しておき、保証数範囲内に到着したパケットについては、パケット順序を補正するようにしているので、デコードされた画像に乱れがなく、好ましい画像が得られる。
（４）請求項４記載の発明は、前記パケット順序補正部は、逆転しているパケットをどの程度まで保持させるかの閾値として最大保持数を設け、その値は請求項３記載の保証数範囲と同じとすることを特徴とする。
【００２４】
このように構成すれば、最大保持数以内のパケットであれば、逆転を補正してデコードされた画像の品質の低下を防止することができる。
（５）請求項５記載の発明は、保持したストリームや、最後にデコード要求を行なったストリーム情報を管理するため、ストリーム管理テーブルを設け、ストリームの一括管理を行なうようにしたことを特徴とする。
【００２５】
このように構成すれば、ストリームの一括管理を行なうことでパケット順序の補正処理を行ない、画像品質を維持することができる。
【００２６】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
【００２７】
図３は本発明方法の動作の一例を示すフローチャートである。図に示すフローチャートは、図１１の従来方法と対応している。図１１の方法と比較すると、図１１のステップＳ７，Ｓ８が、本発明ではＳ７’となっている。Ｓ７’は、本発明に係るパケット逆転補正処理である。
【００２８】
先ず、全体の動作について説明する。ストリームパケットを受信すると（Ｓ１）、パケット受信数をカウントする（Ｓ２）。次に、ＲＴＰヘッダ情報をチェックする（Ｓ３）。そして、ストリームサイズをチェックする（Ｓ４）。次に、受信パケットがおかしくないかどうかチェックする（Ｓ５）。ここで、受信パケットがおかしいとは、例えば受信パケットデータが壊れていることをいう。受信パケットがおかしい場合には、その受信ストリームを破棄し（Ｓ６）、ステップＳ１に戻り、パケット受信ステップからやりなおす。受信パケットがおかしくない場合には、パケットに逆転が発生していた場合には、パケット逆転補正処理を行ない（Ｓ７’）、次のパケット受信処理に入る。
【００２９】
パケット逆転が発生した場合には、それをどの程度まで保証するかの閾値として保証数範囲を設け、最後にデコード要求を行なったストリームのシーケンス番号から閾値までを保証する範囲とする。また、本来の順序とは違って受信したパケットは、期待するパケットを受信するまで保持していなければならない。そのため、パケットをどの程度まで保持させるかの閾値として最大保持数を設け、その値は保証数範囲と同じ値とする。
【００３０】
更に、保持したストリームや最後にデコード要求を行なったストリーム情報を管理するため、ストリーム管理テーブルを設け、ストリームの一括管理を行なうようにする。
【００３１】
図４はストリーム管理テーブルの一例を示す図である。ストリーム管理テーブルは、パケットの逆転を補正するために、必要な情報を全て格納しておくテーブルである。このストリーム管理テーブルは、図２のパケット順序補正部１３内に設けられる。ストリーム管理テーブルには、図に示すように、大きく分けて３つの情報が格納されている。１つ目は、最後にデコード要求を行なったストリームの情報で、シーケンス番号とＭＰＥＧ実データが格納されているバッファ上の先頭アドレス情報が管理されている。シーケンス番号は、受信したパケットと最後にデコード要求を行なったストリームとのシーケンス飛びをチェックするために必要とされる情報である。ＭＰＥＧ実データの先頭アドレスは、受信したストリームが格納されているバッファの管理のためのものである。
【００３２】
２つ目は、現在受信したストリームの情報で、シーケンス番号、ＲＴＰヘッダ先頭アドレス、ＭＰＥＧ実データ先頭アドレスとそのサイズ、ＭＰＥＧ形式、ＭＰＥＧモード番号、装置種別である。ＲＡＰフラグは、受信したＭＰＥＧストリームパケットがＲＡＰであるかどうかを示すフラグである。ここで、ＲＡＰとは基準画像のことである。
【００３３】
シーケンス番号は、前述したように、最後にデコード要求を行なったストリームとのシーケンス番号チェックに用いられる。その他の情報については、デコード要求時に必要とされる情報であり、これらの情報をデコーダ部に渡すことで、デコード要求を行なう。
【００３４】
３つ目は、パケット逆転が発生した際に保持するストリームの情報で、最大保持数分の領域が用意されている。保持ストリームフラグ以外は、２つ目で示した内容と同一の内容である。保持ストリームフラグは、格納されている保持ストリーム情報の有効、無効を識別するためのフラグである。例えば、このフラグが立ている場合には、その情報は、現在発生しているパケット逆転の保証数範囲内のストリーム情報が格納されていることを示している。
【００３５】
また、そのストリームがデコード要求、破棄及び初期化された場合は、フラグは下げられる。このフラグにより、その情報が正しいかどうかを明確に確認することができ、保持ストリームを検索する際の無駄がなくなる。
【００３６】
このストリーム管理テーブルは、デコード要求開始時、停止時及びネットワーク断発生時には、パケットの連続性が失われる可能性があるため、初期化が行なわれる。このようなストリーム管理テーブルを用いれば、ストリームの一括管理を行なうことでパケット順序の補正処理を行ない、画像品質を維持することができる。
【００３７】
このように、本発明によれば、パケット逆転を補正するための保証数範囲を予め設定しておき、保証数範囲内に到着したパケットについては、パケット順序を補正するようにしているので、デコードされた画像に乱れがなく、好ましい画像が得られる。また、逆転しているパケットをどの程度まで保持させるかの閾値として最大保持数を設け、その値は前記保証数範囲と同じとすることにより、逆転を補正してデコードされた画像の品質の低下を防止することができる。
【００３８】
図５はパケット逆転補正処理の一例を示すフローチャートである。動作の主体は、図２のパケット順序補正部１３である。補正には、既存のシーケンス番号を利用してエンコーダがＩＰネットワーク上に送信したパケットの順序を識別し、パケットのデコード順序の補正を行なうものである。
【００３９】
先ず、初めに受信ストリームのシーケンス番号のチェックが行なわれる（Ｓ１）。このチェックでは、図４に示したストリーム管理テーブルの情報から最後にデコーダ要求を行なったストリームのシーケンス番号と比較し、シーケンス飛びが発生したかどうかを識別し、発生していればシーケンス飛びフラグを立てる。
【００４０】
次に、受信したストリームが受信開始から初めてのストリームパケットであるかチェックを行なう（Ｓ２）。初めてのストリームパケットである場合には、パケット逆転発生はあり得ないため、即デコーダ部に対してデコード要求を行なう（Ｓ９）。初めてではない場合（受信開始から２番目以降のストリーム）には、次の処理に入る。
【００４１】
次に、受信ストリームがデコード要求を行なったストリームより番号が小さいかどうかチェックする（Ｓ３）。最後にデコード要求を行なったストリームより番号が小さい場合には、不要なパケットであるので、ストリーム管理テーブルより最後にデコード要求を行なったストリームのシーケンス番号を取得し、それ以前の受信ストリームパケットを破棄する（Ｓ１０）。
【００４２】
次に、受信ストリームが保証数範囲の場合について説明する。受信ストリームがシーケンス飛びの保証数範囲内であるかどうかチェックする（Ｓ４）。保証数範囲内の場合には、はじめにシーケンス飛びが発生しているか否かで処理が変わる。シーケンス飛びは、初めに行なったシーケンス飛びチェックで行なっており、フラグの内容により判断する（Ｓ５）。
【００４３】
シーケンス飛びが発生しておれば、受信ストリームをデコード保持する（Ｓ１１）。この場合において、ストリーム管理テーブルの保持ストリームフラグにて格納場所の空きを検索し、その情報を保持しておく。この処理により、後で保持ストリームをデコード要求する場合に、ストリーム管理テーブルより情報を取り出すことが可能となる。
【００４４】
シーケンス飛びが発生していない場合には、受信したストリームが連続していることになるので、受信ストリームをデコード要求する（Ｓ６）。この時、ストリーム管理テーブルの保持しているストリームの中に次のストリームがあるかどうかチェックし（Ｓ７）、受信したストリームの次のストリームがあれば、保持ストリームをデコード要求を行なう（Ｓ８）。その後、受信待ち状態となる。
【００４５】
次に、受信ストリームが保証数範囲外の場合の処理について説明する。保証数範囲外の場合には、初めに受信したストリームの一つ前のシーケンス番号のストリームがあるか否かをストリーム管理テーブル内を検索し（Ｓ１３）、あればフラグを立て（Ｓ１２）、更にもう一つ前のストリームがあるか検索する。この処理を繰り返すことにより、ストリーム管理テーブル内の連続している保持ストリーム全てに対してデコード要求を行ない、その後に現在受信したストリームのデコード要求を行なう。最後に、受信したストリームが保証数範囲を超えてしまったので、一度ストリーム管理テーブルの初期化を行なう。その後、受信待ち状態となる。
【００４６】
具体的には、保持ストリーム中に前のストリームがない場合、ループを通ったかどうかチェックし（Ｓ１４）、通った場合には、シーケンス番号が連続しているストリームのみ保持ストリームをデコード要求する（Ｓ１５）。次に、受信ストリームをデコード要求し（Ｓ１６）、残っているストリームを破棄し（Ｓ１７）、ステップＳ１に戻る。
【００４７】
ステップＳ１４において、ループを通っていない場合には、受信ストリームをデコード要求し（Ｓ１８）、保持ストリームを全て破棄し（Ｓ１９）、ステップＳ１に戻る。
【００４８】
このように構成すれば、パケット受信時のパケット着信順序がパケット送信時と比較して狂っていても、パケット順序補正部１３がパケット送信順序に従ってデコード処理を行なうようにすることで、デコードされた画像に乱れがなく、品質の低下を防止することができる。
【００４９】
次に、図５，図６を用いて、いくつかのパケット逆転補正処理の例を示す。図６はパケット受信例を示す図である。図６のパケットの受信順序は、左から右の順に受信するものとし、図中の矢印は、パケットが逆転したことを示し、番号はシーケンス番号を示す。また、網掛けしたパケットは、抜けたパケットを受信したことを示す。ここでは、保証数範囲及び最大保持数は１０の場合を例にとる。
（デコード要求を行なったストリームよりも以前のパケットを受信した場合）
図６の（ａ）に示すように、デコード要求を行なったストリームよりも以前のパケットを受信した場合（パケット番号５がパケット番号３３の後に来た場合）、図５の逆転補正処理フローチャートに従って処理を行なうと、シーケンス番号１（以下番号のみとする）のストリームは、Ｓ１のシーケンスチェックを受け、受信開始から初めてのストリームなので、Ｓ２の分岐でＳ９の処理に移り、デコード要求される。この処理を初期動作とする。
【００５０】
デコード要求を行なう際は、ストリーム管理テーブルのデコード要求情報が更新され、以下、更新処理はデコード要求時毎に行なわれる。２のパケットは、Ｓ１，Ｓ２，Ｓ３，Ｓ４，Ｓ５，Ｓ６，Ｓ７の処理の順に行なわれる。この処理順序を通常動作とする。その後、３３までのパケットは、２のパケットと同様に通常処理を行なう。
【００５１】
次に、５のパケットが来た場合、Ｓ１，Ｓ２の処理を受け、Ｓ３の分岐により最後にデコード要求を行なったストリーム３３よりも番号が小さいため、Ｓ１０の処理が行なわれ、当該パケットは破棄される。３４以降の処理は２と同様の処理順となる。
（保証数範囲を超えたストリームを受信した場合）
図６の（ｂ）に示すような保証数範囲を超えたパケットを受信した場合、図５のパケット逆転補正処理フローチャートに従って処理を行なうと、１のパケットは受信開始から初めてのストリームなので初期動作を行なう。２から１３までのパケットについては通常動作が行なわれる。
【００５２】
２２のパケットは、Ｓ１，Ｓ２，Ｓ３の順に処理が行なわれる。この場合、Ｓ４の分岐により保証数範囲内であるかどうかのチェックが行なわれる。ストリーム１３と２２間の差異は“９”であり、保証数範囲内なのでＳ５の処理に移る。Ｓ５の処理において、最後にデコード要求を行なったストリーム１３からシーケンス飛びが発生しているので、Ｓ１１の処理により、ストリーム管理テーブル上に保持ストリームとして情報が格納され、２３，２４のパケットについても２２と同様の処理順でストリーム管理テーブルにその情報が格納される。
【００５３】
その後、ストリーム２５を受信すると、Ｓ１，Ｓ２，Ｓ３の処理が行なわれ、Ｓ４の処理において保証数範囲外なので、Ｓ１３の処理に移る。Ｓ１３の処理では、ストリーム管理テーブル内を受信ストリーム２５より一つ前のストリーム、即ち２４のストリームを検索する。ここで、先に保持した２４のストリームが存在するので、Ｓ１２の処理によりループチェックフラグが立てられ、更にＳ１３の処理が繰り返され、次は２４の一つ前のストリームである２３を検索する。
【００５４】
同様に、この処理を繰り返し、２２を見つけるまで検索を続けるが、２２の一つ前のストリームは保持されていないため、Ｓ１４の処理に移る。Ｓ１４の処理において、ループチェックフラグにより、ループを通ったかが識別されるので、Ｓ１５の処理に移り、２２，２３，２４のストリームをデコード要求する。
【００５５】
その後、Ｓ１６の処理により現在受信したストリーム２５のデコード要求を行ない、最後にＳ１７の処理により、残っている保持ストリームを、保持ストリームフラグを下げることにより、無効とする。その後、２６のパケット以降は通常動作を行なう。
（パケット逆転が１回発生した場合）
図６の（ｃ）に示すように、逆転が１回発生した場合（ストリーム１１）、図５のパケット逆転補正処理フローチャートに従って処理を行なうと、１のパケットは受信開始から初めてのストリームなので、初期動作を行なう。２から１０までのパケットは通常動作が行なわれ、１２，１３のパケットは、Ｓ１，Ｓ２，Ｓ３の順に処理が行なわれる。
【００５６】
そして、Ｓ４の処理において保証数範囲内なので、Ｓ５の処理に移る。Ｓ５の処理において、最後にデコード要求を行なったストリーム１０からシーケンス飛びが発生しているので、Ｓ１１の処理により、ストリーム管理テーブル上に保持ストリームとして情報が格納される。
【００５７】
期待している１１のパケットを受信すると、Ｓ１〜Ｓ４の順に処理が行なわれる。Ｓ５の処理において、最後にデコード要求を行なったストリーム１０と現在受信した１１とはシーケンス飛びが発生していないので、Ｓ６の処理が行なわれ、１１がデコード要求される。
【００５８】
次に、Ｓ７の処理に移り、Ｓ７の処理において現在受信した１１の次のパケット、即ち１２がないかストリーム管理テーブル内の検索を行なう。ここで、先に保持しておいたストリーム１２が存在するので、Ｓ８の処理により１２のストリームがデコード要求され、更にＳ７の処理が繰り返される。
【００５９】
そして、１２の次の番号である１３を探す。１３も１２と同様にストリーム管理テーブル内に情報が保持されているので、Ｓ８の処理に移り、デコード要求される。更に、Ｓ７の処理が繰り返されるが、１３の次の番号１４は存在しないので、終了となる。その後、１４以降の処理は通常動作をする。
（パケット逆転が３回発生し、その受信順が複雑な場合）
図６の（ｄ）に示すようにシーケンス飛びが発生し、更に期待するパケットを受信する前に２回のシーケンス飛びが発生している。その後、期待するパケットの受信順序が複雑な場合、図５のパケット逆転補正処理フローチャートに従って処理を行なう。
【００６０】
１のパケットは、受信開始から初めてのストリームなので、初期動作を行なう。２〜１０までのパケットは通常動作が行なわれ、１２，１３，１５，１７の順にパケットを受信する。これらのパケットは、Ｓ１，Ｓ２，Ｓ３，Ｓ４，Ｓ５，Ｓ１１の順で処理され、ストリーム管理テーブルにてその情報を管理される。
【００６１】
次に、逆転したパケット１４を受信するが、Ｓ１〜Ｓ５の順に処理され、最後にデコード要求を行なったストリーム１０とは、シーケンス飛びが発生しているので、１２，１３，１５，１７と同様にストリーム管理テーブルにてその情報を保持される。更に１８，１６，１９も１４と同様に処理される。
【００６２】
次に、１１を受信すると、Ｓ１〜Ｓ４の順序で処理され、Ｓ５の処理において、最後にデコード要求を行なった１０とはシーケンス飛びが発生していないため、Ｓ６の処理に移りデコード要求される。そして、Ｓ７の処理に移る。
【００６３】
Ｓ７の処理では、１１の次のストリーム１２を検索する。１２のストリームは、ストリーム管理テーブルでその情報を保持しているため、Ｓ８の処理に移り、１２のストリームがデコード要求される。その後、Ｓ７，Ｓ８の処理が繰り返され、残っている保持しているストリーム１３から１９がデコード要求される。その後、２０以降のパケットは通常動作を行なう。
【００６４】
以上、説明したように、本発明によれば、ＩＰネットワークより受信したパケットに逆転が発生しても、その補正が可能になる。この補正効果により、パケット逆転が発生した際の画像の乱れを軽減でき、特にＭＰＥＧ４のようなパケット逆転発生頻度が高いストリームの場合に対して効果的であり、課題となっている品質の低下も避けられる。
【００６５】
【発明の効果】
本発明によれば、以下のような効果が得られる。
（１）請求項１記載の発明によれば、シーケンス番号を元に、受信したパケットデータをデコードする時に、パケット着信順ではなく、シーケンス番号順にデコードするようにしているため、デコードされた画像に乱れがなく、品質の低下を防止することができる。
（２）請求項２記載の発明によれば、パケット受信時のパケット着信順序がパケット送信時と比較して狂っていても、パケット順序補正部１３がパケット送信順に従ってデコード処理を行なうようにすることで、デコードされた画像に乱れがなく、品質の低下を防止することができる。
（３）請求項３記載の発明によれば、パケット逆転を補正するための保証数範囲を予め設定しておき、保証数範囲内に到着したパケットについては、パケット順序を補正するようにしているので、デコードされた画像に乱れがなく、好ましい画像が得られる。
（４）請求項４記載の発明によれば、最大保持数以内のパケットであれば、逆転を補正してデコードされた画像の品質の低下を防止することができる。
（５）請求項５記載の発明によれば、ストリームの一括管理を行なうことでパケット順序の補正処理を行ない、画像品質を維持することができる。
【００６６】
このように、本発明によれば、受信したパケットのデコードを行なった場合でも画像の乱れ等の品質の低下を防止することができる逆転ストリームパケットの補正方法及び装置を提供することができる。
【図面の簡単な説明】
【図１】本発明方法の原理を示すフローチャートである。
【図２】本発明の原理ブロック図である。
【図３】本発明方法の動作の一例を示すフローチャートである。
【図４】ストリーム管理テーブルの一例を示す図である。
【図５】パケット逆転補正処理の一例を示すフローチャートである。
【図６】パケット受信例を示す図である。
【図７】従来のデータ転送システムの概念図である。
【図８】エンコーダの内部構成例を示す図である。
【図９】デコーダの内部構成例を示す図である。
【図１０】ＭＰＥＧストリームパケットの構成例を示す図である。
【図１１】受信部のパケット受信時の既存処理を示すフローチャートである。
【符号の説明】
１０  パケット受信部
１１  ＲＴＰヘッダ情報抽出部
１２  シーケンス番号抽出部
１３  パケット順序補正部
【図１】
2004328353.tif 000003
【図２】
2004328353.tif 000004
【図３】
2004328353.tif 000005
【図４】
2004328353.tif 000006
【図５】
2004328353.tif 000007
【図６】
2004328353.tif 000008
【図７】
2004328353.tif 000009
【図８】
2004328353.tif 000010
【図９】
2004328353.tif 000011
【図１０】
2004328353.tif 000012
【図１１】
2004328353.tif 000013