(57)【要約】【課題】表示のために１ピクチャ分の全てのデータを要する動画像を、通信リソースの消費を抑制しつつ低遅延で伝送するための、動画像伝送装置、システム、方法およびプログラムを提供する。【解決手段】１ピクチャ分のデータをラインブロックのブロックデータとしてキャプチャし、伝送路ＮＷの状況および各ブロックデータのキャプチャ時点に応じて、各ブロックデータの誤り訂正方式としてＦＥＣ符号方式を利用するかを動的に決定し、ＦＥＣ符号方式を利用するパケットについて、各パケットをＦＥＣ冗長符号化し、ＦＥＣ符号方式を利用しないパケットについて、各パケットをＦＥＣ冗長符号化せずに、伝送路を通じて受信装置２０に送信し、かつ、パケットロスが発生すると、消失パケットをＡＲＱ方式で受信装置に再送し、複数のラインブロックについて、各ブロックデータのキャプチャおよび送信を含む一連の処理を、キャプチャ所要時間だけずらして並列処理する。【選択図】図４
2011211616.tif 000002
【特許請求の範囲】
【請求項１】
表示のために１ピクチャ分の全てのデータを要する動画像について、前記１ピクチャ分のデータを所定数の画素ラインからなるラインブロックに区分してブロックデータとしてキャプチャするキャプチャ部と、
伝送路の状況および各ブロックデータのキャプチャ時点に応じて、前記各ブロックデータのパケットの誤り訂正方式として、前方誤り訂正（ＦＥＣ）符号方式を利用するか否かを動的に決定するＦＥＣ利用決定部と、
前記ＦＥＣ符号方式を利用するパケットについて、ＦＥＣ冗長符号化された各パケットを、前記ＦＥＣ符号方式を利用しないパケットについて、ＦＥＣ冗長符号化されていない各パケットを、前記伝送路を通じて受信装置に送信し、かつ、前記ＦＥＣ符号方式を利用しないパケットについて、パケットロスが発生すると、消失パケットを自動再送（ＡＲＱ）方式で前記受信装置に再送する送信部と、を備え、
前記キャプチャ部および前記送信部は、複数のブロックデータについて、前記各ブロックデータのキャプチャおよび送信を含む一連の処理を、キャプチャ所要時間だけずらして並列処理する、動画像伝送装置。
【請求項２】
前記ＦＥＣ利用決定部は、前記各ブロックデータを表示するために必要な処理の完了が見込まれる完了予定時点から前記動画像の表示時点までの余裕時間内で、前記消失パケットの再送により誤り訂正後の所定の目標ロス率を達成しつつ前記消失パケットを回復できない場合に、前記ＦＥＣ符号方式の利用を決定する、請求項１に記載の動画像伝送装置。
【請求項３】
前記ＦＥＣ利用決定部は、前記伝送路の往復伝送時間およびパケットロス率を考慮して、前記ＦＥＣ符号方式の利用を決定する、請求項１または２に記載の動画像伝送装置。
【請求項４】
前記ＦＥＣ利用決定部は、前記ＦＥＣ符号方式を利用する場合、所定の目標ロス率を達成できるように、前記ＦＥＣ符号化の冗長度を決定する、請求項１〜３のいずれか１項に記載の動画像伝送装置。
【請求項５】
前記ＦＥＣ利用決定部は、キャプチャ開始順序の遅いブロックデータを表示するために必要な処理の完了時点から、前記動画像の表示時点までの余裕時間が短いため、前記キャプチャ開始順序の遅いブロックデータについて、前記ＦＥＣ符号方式の利用を決定する、請求項１〜４のいずれか１項に記載の動画像伝送装置。
【請求項６】
伝送路を通じて送信装置から受信装置に動画像を伝送する動画像伝送システムであって、
前記送信装置は、
表示のために１ピクチャ分の全てのデータを要する動画像について、前記１ピクチャのデータを所定数の画素ラインからなるラインブロックに区分してブロックデータとしてキャプチャするキャプチャ部と、
前記伝送路の状況および各ブロックデータのキャプチャ時点に応じて、前記各ブロックデータのパケットの誤り訂正方式として、前方誤り訂正（ＦＥＣ）符号方式を利用するか否かを動的に決定するＦＥＣ利用決定部と、
前記ＦＥＣ符号方式を利用するパケットについて、ＦＥＣ冗長符号化された各パケットを、前記ＦＥＣ符号方式を利用しないパケットについて、ＦＥＣ冗長符号化されていない各パケットを、前記伝送路を通じて受信装置に送信し、前記ＦＥＣ符号方式を利用しないパケットについて、パケットロスが発生すると、消失パケットを自動再送（ＡＲＱ）方式で前記受信装置に再送する送信部と、を備え、
前記キャプチャ部および前記送信部は、複数のブロックデータについて、前記各ブロックデータのキャプチャおよび送信を含む一連の処理を、キャプチャ所要時間だけずらして並列処理し、
前記受信装置は、
前記ＦＥＣ符号方式を利用するパケットについて、前記ＦＥＣ冗長符号化された各パケットを、前記ＦＥＣ符号方式を利用しないパケットについて、前記ＦＥＣ冗長符号化されていない各パケットを、前記伝送路を通じて前記送信装置から受信し、かつ、前記ＦＥＣ符号方式を利用しないパケットについて、前記パケットロスが発生すると、前記消失パケットを自動再送（ＡＲＱ）方式で前記送信装置から再受信する受信部と
前記１ピクチャ分の全てのブロックデータについて、前記受信および前記表示するために必要な処理を完了すると、前記１ピクチャ分のデータとして前記表示装置に出力する出力インターフェイスと
を備える、動画像伝送システム。
【請求項７】
表示のために１ピクチャ分の全てのデータを要する動画像について、前記１ピクチャ分のデータを所定数の画素ラインからなるラインブロックに区分してブロックデータとしてキャプチャするステップと、
伝送路の状況および各ブロックデータのキャプチャ時点に応じて、前記各ブロックデータのパケットの誤り訂正方式として、前方誤り訂正（ＦＥＣ）符号方式を利用するか否かを動的に決定するステップと、
前記ＦＥＣ符号方式を利用するパケットについて、各パケットをＦＥＣ冗長符号化し、前記ＦＥＣ符号方式を利用しないパケットについて、各パケットをＦＥＣ冗長符号化せずに、前記伝送路を通じて受信装置に送信するステップと、
前記ＦＥＣ符号方式を利用しないパケットについて、パケットロスが発生すると、消失パケットを自動再送（ＡＲＱ）方式で前記受信装置に再送するステップと、
複数のブロックデータについて、前記各ブロックデータのキャプチャステップおよび送信ステップを含む一連の処理を、キャプチャ所要時間だけずらして並列処理するステップと
を含む動画像伝送方法。
【請求項８】
請求項７に記載の動画像伝送方法をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画像伝送装置、動画像伝送システム、動画像伝送方法およびプログラムに関する。
【背景技術】
【０００２】
近年、インターネット等の伝送路を通じて、動画像等のデータを低遅延で伝送することが求められている。例えばリアルタイムで動画像を伝送する場合、動画像のフレーム間隔以下の遅延で動画像データを伝送することが求められる。
【０００３】
このため、下記特許文献１には、１ピクチャ分のデータを所定数の画素ラインからなるラインブロックに区分し、ブロックデータとして圧縮する技術（ラインブロック単位方式）が開示されている。
【０００４】
この技術によれば、送信側では、１ピクチャ分の全てのデータのキャプチャを完了しなくても、ブロックデータ毎に前方誤り訂正（ＦＥＣ：Ｆｏｒｗａｒｄ  Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｏｎ）符号化等の後続処理を開始することができる。同様に、受信側でも、１ピクチャ分の全てのデータの受信を完了しなくても、ブロックデータ毎にＦＥＣ復号等の後続処理を開始することができる。よって、伝送路の伝播遅延が十分に小さければ、フレーム間隔以下の遅延で、動画像の伝送が可能となる。
【０００５】
しかし、動画像を表示する表示装置によっては、表示のために１ピクチャ分の全てのデータを必要とする場合がある。この場合、ブロックデータ毎に後続処理を開始できても、１ピクチャ分の全てのブロックデータの後続処理を完了するまでは、動画像を表示することができない。このため、動画像の表示時点は、１ピクチャ分のブロックデータのうち、最後にキャプチャされるブロックデータの後続処理を完了する時点に依存することになる。
【０００６】
ところで、動画像の伝送では、伝送時における誤り訂正方式として、ＦＥＣ符号方式が頻繁に利用される。ＦＥＣ符号方式において、送信側では、元データを冗長符号化し、冗長パケットを含む複数のパケットが伝送路を通じて送信される。そして、受信側では、複数のパケットのうち所定数のパケットを受信することで、元データの復号が可能となる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００７−３１１９２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかし、ＦＥＣ符号方式を利用する動画像伝送では、冗長パケットを伝送するために、伝送路の帯域およびＦＥＣ処理（符号化・復号）に要する処理時間等、多くの通信リソースが消費されてしまうことなる。
【０００９】
そこで、本発明は、表示のために１ピクチャ分の全てのデータを要する動画像を、通信リソースの消費を抑制しつつ低遅延で伝送可能な、動画像伝送装置、動画像伝送システム、動画像伝送方法およびプログラムを提供しようとするものである。
【課題を解決するための手段】
【００１０】
本発明のある観点によれば、表示のために１ピクチャ分の全てのデータを要する動画像について、１ピクチャ分のデータを所定数の画素ラインからなるラインブロックに区分してブロックデータとしてキャプチャするキャプチャ部と、伝送路の状況および各ブロックデータのキャプチャ時点に応じて、各ブロックデータのパケットの誤り訂正方式として、前方誤り訂正（ＦＥＣ）符号方式を利用するか否かを動的に決定するＦＥＣ利用決定部と、ＦＥＣ符号方式を利用するパケットについて、ＦＥＣ冗長符号化された各パケットを、ＦＥＣ符号方式を利用しないパケットについて、ＦＥＣ冗長符号化されていない各パケットを、伝送路を通じて受信装置に送信し、かつ、ＦＥＣ符号方式を利用しないパケットについて、パケットロスが発生すると、消失パケットを自動再送（ＡＲＱ）方式で受信装置に再送する送信部と、を備え、キャプチャ部および送信部は、複数のブロックデータについて、各ブロックデータのキャプチャおよび送信を含む一連の処理を、キャプチャ所要時間だけずらして並列処理する動画像伝送装置が提供される。
【００１１】
上記ＦＥＣ利用決定部は、各ブロックデータを表示するために必要な処理の完了が見込まれる完了予定時点から動画像の表示時点までの余裕時間内で、消失パケットの再送により誤り訂正後の所定の目標ロス率を達成しつつ消失パケットを回復できない場合に、ＦＥＣ符号方式の利用を決定してもよい。
【００１２】
上記ＦＥＣ利用決定部は、伝送路の往復伝送時間およびパケットロス率を考慮して、ＦＥＣ符号方式の利用を決定してもよい。
【００１３】
上記ＦＥＣ利用決定部は、ＦＥＣ符号方式を利用する場合、所定の目標ロス率を達成できるように、ＦＥＣ符号化の冗長度を決定してもよい。
【００１４】
上記ＦＥＣ利用決定部は、キャプチャ開始順序の遅いブロックデータを表示するために必要な処理の完了時点から、動画像の表示時点までの余裕時間が短いため、キャプチャ開始順序の遅いブロックデータについて、ＦＥＣ符号方式の利用を決定してもよい。
【００１５】
また、本発明の別の観点によれば、伝送路を通じて上記動画像伝送装置から受信装置に動画像を伝送する動画像伝送システムが提供される。
【００１６】
また、本発明の別の観点によれば、表示のために１ピクチャ分の全てのデータを要する動画像について、１ピクチャ分のデータを所定数の画素ラインからなるラインブロックに区分してブロックデータとしてキャプチャするステップと、伝送路の状況および各ブロックデータのキャプチャ時点に応じて、各ブロックデータのパケットの誤り訂正方式として、前方誤り訂正（ＦＥＣ）符号方式を利用するか否かを動的に決定するステップと、ＦＥＣ符号方式を利用するパケットについて、各パケットをＦＥＣ冗長符号化し、ＦＥＣ符号方式を利用しないパケットについて、各パケットをＦＥＣ冗長符号化せずに、伝送路を通じて受信装置に送信するステップと、ＦＥＣ符号方式を利用しないパケットについて、パケットロスが発生すると、消失パケットを自動再送（ＡＲＱ）方式で受信装置に再送するステップと、複数のブロックデータについて、各ブロックデータのキャプチャステップおよび送信ステップを含む一連の処理を、キャプチャ所要時間だけずらして並列処理するステップとを含む動画像伝送方法が提供される。
【００１７】
また、本発明の別の観点によれば、上記動画像伝送方法をコンピュータに実行させるためのプログラムが提供される。ここで、プログラムは、コンピュータ読取り可能な記録媒体を用いて提供されてもよく、通信手段を介して提供されてもよい。
【発明の効果】
【００１８】
以上説明したように本発明によれば、表示のために１ピクチャ分の全てのデータを要する動画像を、通信リソースの消費を抑制しつつ低遅延で伝送可能な、動画像伝送装置、動画像伝送システム、動画像伝送方法およびプログラムを提供することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態に係る伝送システムの全体構成を示す図である。
【図２】ピクチャ単位方式とラインブロック単位方式の動画像伝送処理を対比して示す図である。
【図３Ａ】ラインブロック単位方式での動画像伝送の処理状況を示す図（１／２）である。
【図３Ｂ】ラインブロック単位方式での動画像伝送の処理状況を示す図（２／２）である。
【図４】送信装置および受信装置の主要な機能構成を示すブロック図である。
【図５】ＦＥＣ符号方式の利用を決定するための判定条件を説明するための図である。
【図６Ａ】動画像伝送システムの動作手順を示すフロー図（１／２）である。
【図６Ｂ】動画像伝送システムの動作手順を示すフロー図（２／２）である。
【発明を実施するための形態】
【００２０】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００２１】
本明細書では、本発明の好適な実施の形態について、以下の項目に沿って説明する。
１．動画像伝送システムの全体構成
２．ラインブロック単位方式の動画像伝送処理
３．送信装置および受信装置の構成
４．ＦＥＣ符号方式の利用判定
５．動画像伝送システムの動作
６．まとめ
【００２２】
［１．動画像伝送システムの全体構成］
まず、図１を参照して、本発明の実施形態に係る動画像伝送システムの全体構成について説明する。図１には、動画像伝送システムの全体構成が示されている。
【００２３】
図１に示すように、動画像伝送システムは、インターネット等の伝送路ＮＷを通じて動画像のデータを伝送可能な、送信装置１０および受信装置２０を含んで構成される。動画像データは、ＩＥＴＦ  ＲＦＣ３５５０に規定されるＲＴＰ（Ｒｅａｌｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）等のストリーム伝送方式で伝送される。
【００２４】
送信装置１０は、ビデオカメラＶ等の動画像入力装置に接続され、受信装置２０は、ディスプレイＤ等の動画像出力装置に接続されている。なお、送信装置１０は、ビデオカメラＶと一体に構成されてもよく、受信装置２０は、ディスプレイＤと一体に構成されてもよい。
【００２５】
送信装置１０は、ビデオカメラＶから入力される動画像信号をデータとして取込み（キャプチャし）（ａ）、圧縮符号化し（ｂ）、パケタイズし（ｃ）、必要に応じて前方誤り訂正（ＦＥＣ）符号化し（ｆ）、伝送路ＮＷを通じて受信装置２０に送信する（ｅ）。
【００２６】
一方、受信装置２０は、伝送路ＮＷを通じて送信装置１０からデータを受信し（ｅ´）、必要に応じてＦＥＣ復号し（ｆ）、デパケタイズし（ｇ）、圧縮復号する（ｈ）。受信装置２０は、１ピクチャ分の全てのデータについて処理（ｅ´）〜（ｈ）を完了すると、表示処理を施し、１ピクチャ分のデータとしてディスプレイＤに出力し、ディスプレイＤは、動画像として表示する。
【００２７】
［２．ラインブロック単位方式の動画像伝送処理］
つぎに、図２および図３を参照して、ラインブロック単位方式の動画像伝送処理について説明する。
【００２８】
図２には、ピクチャ単位方式とラインブロック単位方式の動画像伝送処理が対比して示されている。なお、以下では、１ピクチャ分のデータがラインブロック番号ｋ＝１〜Ｎのラインブロックに区分される場合を想定して説明する。
【００２９】
図２に示すように、ピクチャ単位方式においては、キャプチャ（Ａ）、圧縮符号化（Ｂ）、パケタイズ（Ｃ）、ＦＥＣ符号化（Ｄ）、伝送（Ｅ）、ＦＥＣ復号（Ｆ）、デパケタイズ（Ｇ）および圧縮復号（Ｈ）の各処理（Ａ）〜（Ｈ）がピクチャ単位で実行される。このため、送信側では、１ピクチャ分のデータのキャプチャ（Ａ）を完了するまで、後続処理（Ｂ）〜（Ｅ）を開始することができず、受信側でも、１ピクチャ分のデータの伝送（Ｅ）を完了するまで、後続処理（Ｆ）〜（Ｈ）を開始することができない。
【００３０】
一方、ラインブロック単位方式においては、キャプチャ（ａ）、圧縮符号化（ｂ）、パケタイズ（ｃ）、ＦＥＣ符号化（ｄ）、伝送（ｅ）、ＦＥＣ復号（ｆ）、デパケタイズ（ｇ）および圧縮復号（ｈ）の各処理（ａ）〜（ｈ）がラインブロック単位で実行される。つまり、送信側では、１ピクチャ分のデータのキャプチャ（Ａ）を完了しなくても、ラインブロック単位のデータのキャプチャ（ａ）を完了すれば、後続処理（ｂ）〜（ｅ）を順次に開始することができ、受信側でも、ラインブロック単位のデータの伝送（ｅ）を完了すれば、後続処理（ｆ）〜（ｈ）を順次に開始することができる。
【００３１】
また、送信側では、例えばラインブロック番号ｋ＝１のブロックデータのキャプチャ（ａ）を完了すると、後続処理（ｂ）〜（ｅ）を順次に開始するとともに、ｋ＝２のブロックデータのキャプチャ（ａ）を開始する、というように、ラインブロック単位で各処理（ａ）〜（ｅ）が並列処理される。なお、受信側でも、送信側と同様に、ラインブロック単位で各処理（ｆ）〜（ｈ）が並列処理される。
【００３２】
このため、ピクチャ単位方式では、各処理（Ａ）〜（Ｈ）の少なくとも１つで生じた遅延は、１ピクチャ分の処理の遅延としてそのまま蓄積されてしまい、キャプチャ（Ａ）から表示に至る処理全体の遅延が大きくなる。一方、ラインブロック単位方式では、各処理（ａ）〜（ｈ）の少なくとも１つで生じた遅延は、ラインブロック同士の処理の間で吸収され、１ピクチャ分の処理の遅延としてそのまま蓄積されることがないので、最初のキャプチャ開始（ａ）から表示に至る処理全体の遅延が抑制される。
【００３３】
図３Ａ、３Ｂには、ラインブロック単位方式での動画像伝送の処理状況が示されている。図３Ａ、３Ｂには、ラインブロック単位で実行される各処理（ａ）〜（ｈ）が示されている。
【００３４】
図３Ａには、１ピクチャ分の動画像について、キャプチャの開始時点と動画像の表示時点が横軸に示されている。また、ラインブロック単位の処理ブロックが処理の開始順序に従って縦軸方向に並列して示されている。
【００３５】
図３Ａに示すように、各処理ブロックは、キャプチャ（ａ）に要する処理時間に相当するオフセットＴｃａｐｔｕｒｅを伴って並列処理される。伝送（ｅ）を除く各処理（ａ）〜（ｄ）、（ｆ）〜（ｈ）に要する時間は、処理ブロックの間で殆ど同一であるが、伝送（ｅ）に要する処理時間は、伝送路ＮＷの状況に応じて変動する。
【００３６】
各処理ブロックは、オフセットＴｃａｐｔｕｒｅを伴って開始されるので、キャプチャ開始順序の早い処理ブロックでは、処理（ａ）〜（ｈ）の完了から表示時点までに十分な余裕時間Ｔｒｅｍａｉｎがあるが、キャプチャ開始順序の遅い処理ブロックでは、余裕時間Ｔｒｅｍａｉｎが殆どなくなる。
【００３７】
このため、図３Ｂに示すように、キャプチャ開始順序の早い処理ブロックでは、伝送時にブロックデータのパケットロスが発生しても、パケットの自動再送により表示時点までに消失パケットを回復することが比較的容易である。一方、キャプチャ開始順序の遅い処理ブロックでは、パケットの自動再送により表示時点までに消失パケットを回復することが困難となる。よって、ラインブロック単位方式の動画像伝送処理では、キャプチャ開始順序の遅い処理ブロック、特に最後の処理ブロックが伝送遅延に関してクリティカルとなる。
【００３８】
一方、ＦＥＣ処理（符号化・復号）では、ブロックデータのパケットが冗長符号化され、冗長パケットが伝送されるので、伝送路ＮＷの帯域およびＦＥＣ処理（符号化・復号）に要する処理時間等、多くの通信リソースが消費されてしまう。
【００３９】
このため、本実施形態では、キャプチャ時点および伝送路ＮＷの状況に応じて、伝送時の誤り訂正方式として、ＦＥＣ符号方式または自動再送（ＡＲＱ：Ａｕｔｏ  Ｒｅｐｅａｔ  ｒｅＱｕｅｓｔ）方式のいずれかが利用される。ここで、詳細は後述するが、再送により回復可能なブロックデータには、ＡＲＱ方式が利用され、再送により回復不能なブロックデータには、ＦＥＣ符号方式が利用される。なお、ＡＲＱ方式は、伝送路ＮＷの状況に応じて、目標とされる誤り訂正後のロス率Ｐａｒｑを達成できる場合に利用される。
【００４０】
これにより、キャプチャ開始順序の早いブロックデータは、消失パケットの再送により回復され、キャプチャ開始順序の遅いブロックデータは、冗長符号化されて送信されたパケットのうち所定数のパケットを受信することで回復される。よって、伝送遅延に関してクリティカルとなるブロックデータにのみＦＥＣ符号方式を利用することで、表示のために１ピクチャ分の全てのデータを要する動画像を、通信リソースの消費を抑制しつつ低遅延で伝送することができる。
【００４１】
［３．送信装置および受信装置の構成］
つぎに、図４を参照して、動画像伝送システムを構成する送信装置１０および受信装置２０の構成について説明する。なお、図４では、ブロックデータの伝達経路が実線の矢印で示され、制御指令等の伝達経路が破線の矢印で示されている。
【００４２】
図４には、送信装置１０および受信装置２０の主要な機能構成が示されている。図４に示すように、送信装置１０は、入力インターフェイス（ＩＦ）１１、キャプチャ部１２、圧縮符号化部１３、パケタイズ部１４、ＦＥＣ符号化部１５、ＲＴＰ送信部１６、ＲＴＣＰ（ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）部１７、ＡＲＱ制御部１８、ＦＥＣ利用決定部１９を含んで構成される。
【００４３】
入力ＩＦ１１は、ビデオカメラＶから供給される動画像信号をデータとして入力する。キャプチャ部１２は、入力ＩＦ１１から供給されるデータをラインブロック単位のブロックデータとして取込む。また、キャプチャ部１２は、キャプチャされたラインブロックのラインブロック番号ｋをＦＥＣ利用決定部１９に通知する。ラインブロック番号ｋは、１ピクチャ分のデータについて、キャプチャ時点が１番目〜Ｎ番目のラインブロックに、ｋ＝１、…、Ｎとして付与される。
【００４４】
圧縮符号化部１３は、キャプチャ部１２から供給されるブロックデータを圧縮符号化する。パケタイズ部１４は、圧縮符号化部１３から供給される圧縮データをＲＴＰパケットにパケタイズする。
【００４５】
ＦＥＣ符号化部１５は、パケタイズ部１４からパケットを供給され、ＦＥＣ利用決定部１９からのＦＥＣ指示に応じてＦＥＣ符号化する。ＦＥＣ符号化では、パケット（元データ）がリードソロモン符号等の消失誤り訂正符号により冗長符号化される。
【００４６】
ＲＴＰ送信部１６は、ＦＥＣ符号化されていないパケット、またはＦＥＣ符号化されたパケットを、伝送路ＮＷを通じて受信装置２０に送信する。また、ＲＴＰ送信部１６は、ＡＲＱ制御部１８からのＡＲＱ指示に応じて、ＦＥＣ符号化されていないパケットのうち、送信時のパケットロスによリ消失したパケットを受信装置２０に再送する。なお、ＦＥＣ符号化されていないパケットは、受信が確認されるまでバッファ（不図示）に記憶される。
【００４７】
ＲＴＣＰ部１７は、ＲＴＰにより受信装置２０との間でデータを送受信するためのセッションを制御する。ＲＴＣＰ部１７は、受信装置２０のＲＴＣＰ部２９との間で、例えばＩＥＴＦ  ＲＦＣ３５５０に規定されるＲＴＣＰ送信レポート（ＳＲ）パケット、ＲＴＣＰ受信レポート（ＲＲ）パケットを送受信することで、伝送路ＮＷの状況を表す伝送路情報を得てＦＥＣ利用決定部１９に通知する。伝送路情報としては、往復伝送時間（ＲＴＴ：Ｒｏｕｎｄ−Ｔｒｉｐ  Ｔｉｍｅ）、平均パケットロス率Ｐｌ等、様々なパラメータが利用される。
【００４８】
また、ＲＴＣＰ部１７は、受信装置２０のＲＴＣＰ部２９から再送要求（ＮＡＣＫ）パケットを受信すると、ＡＲＱ指示としてＡＲＱ制御部１８に通知する。ＡＲＱ制御部１８は、ＲＴＣＰ部１７からのＡＲＱ指示に応じて、ＲＴＰ送信部１６による消失パケットの再送を制御する。
【００４９】
ＦＥＣ利用決定部１９は、伝送路情報およびラインブロック番号ｋに基づき、伝送時の誤り訂正方式として、ＦＥＣ符号方式を利用するか否かを動的に決定する。ＦＥＣ利用決定部１９は、ＦＥＣ符号方式を利用する場合に、ＦＥＣ符号化部１５にＦＥＣ指示を通知する。なお、ＦＥＣ符号方式の利用を決定するための判定条件については、後述する。
【００５０】
また、ＦＥＣ利用決定部１９は、伝送路情報、ＡＲＱ再送パケット量、ブロックデータの伝送レート等に基づき、ＦＥＣ符号化の冗長度を変更してもよい。この場合、例えばＲＴＴの変動が小さい場合に冗長度を低くし、ＲＴＴの変動が大きい場合に冗長度を高くすることで、誤り訂正後の目標ロス率を達成することができる。
【００５１】
これにより、動画像伝送システムでは、ＦＥＣ符号方式の利用の対象となるブロックデータは、ＦＥＣ符号方式により消失パケットが回復され、利用の対象とならないブロックデータは、ＡＲＱ方式により消失パケットが回復される。
【００５２】
なお、図３Ａ、３Ｂにより説明したように、送信装置１０では、キャプチャ（ａ）、圧縮符号化（ｂ）、パケタイズ（ｃ）、ＦＥＣ符号化（ｄ）およびＲＴＰ送信（ｅ）の各処理が複数のブロックデータについて並列処理される。
【００５３】
また、送信装置１０の機能構成は、ハードウェアとして実現されてもよく、少なくとも部分的にソフトウェアとして実現されてもよい。後者の場合、送信装置１０に設けられる制御部（不図示）では、動画像伝送方法を実行するためのプログラムが実行される。
【００５４】
受信装置２０は、ＲＴＰ受信部２１、ＦＥＣ復号部２２、デパケタイズ部２３、圧縮復号部２４、表示処理部２５、出力ＩＦ２６、ロス検知部２７、ＡＲＱ制御部２８、ＲＴＣＰ部２９を含んで構成される。
【００５５】
ＲＴＰ受信部２１は、伝送路ＮＷを通じて送信装置１０からパケットを受信する。ＲＴＰ受信部２１は、ＦＥＣ符号化されていないパケット、またはＦＥＣ符号化されたパケットを受信する。ＦＥＣ復号部２２は、ＦＥＣ符号化されたパケットをＲＴＰ受信部２１から供給され、ＦＥＣ復号する。
【００５６】
デパケタイズ部２３は、ＲＴＰ受信部２１から供給されるパケットを圧縮データにデパケタイズする。なお、デパケタイズ部２３には、ＦＥＣ符号化されたパケットがＦＥＣ復号されて供給され、ＦＥＣ符号化されていないパケットがＦＥＣ復号されずに供給される。
【００５７】
圧縮復号部２４は、デパケタイズ部２３から圧縮データを供給され、圧縮データをブロックデータに復号し、バッファ（不図示）に記憶される。表示処理部２５は、圧縮復号部２４から１ピクチャ分のブロックデータを供給され、表示処理を施して動画像信号を生成する。出力ＩＦ２６は、表示処理部２５から動画像信号を供給され、ディスプレイＤに出力する。
【００５８】
ロス検知部２７は、ＲＴＰ受信部２１から供給される受信情報に基づきパケットロスを検知し、検知結果をＡＲＱ制御部２８に通知する。パケットロスは、例えば、パケットヘッダに記述されたシーケンス番号を検査し、受信したパケットのシーケンス番号が不連続性を有している場合に検知される。
【００５９】
ここで、パケットロスの検知は、ＦＥＣ符号化されていないパケットについてのみ行われ、ＦＥＣ符号化されたパケットについては行われない。これは、ＦＥＣ符号化されたパケットは、ＡＲＱ方式ではなく、ＦＥＣ符号方式により消失パケットが回復されるためである。
【００６０】
ＡＲＱ制御部２８は、ロス検知部２７から供給される検知結果に基づき、消失パケットを特定するための再送要求（ＮＡＣＫ）パケット情報をＮＡＣＫリストに追加する。ＡＲＱ制御部２８は、所定時間にＮＡＣＫリストからＮＡＣＫパケット情報を読出し、ＲＴＣＰ部２９を通じて送信装置１０にＮＡＣＫパケットを送信する。
【００６１】
ＮＡＣＫパケットは、例えば、ＩＥＴＦ  Ｉｎｔｅｒｎｅｔ  Ｄｒａｆｔ「Ｅｘｔｅｎｄｅｄ  ＲＴＰ  Ｐｒｏｆｉｌｅ  ｆｏｒ  ＲＴＣＰ−ｂａｓｅｄ  Ｆｅｅｄｂａｃｋ」に記載のフォーマットに準拠している。
【００６２】
ＮＡＣＫリストには、ＮＡＣＫパケット毎に「ＮＡＣＫｔｉｍｅｏｕｔ」、「ＮＡＣＫｄｅａｄｌｉｎｅ」の時点情報が設定されている。「ＮＡＣＫｔｉｍｅｏｕｔ」は、例えば、ＮＡＣＫパケットの送信からＲＴＴが経過する時点として設定される。「ＮＡＣＫｄｅａｄｌｉｎｅ」は、パケットの到達予定時点等よりもＲＴＴ以前の時点として設定される。
【００６３】
ＡＲＱ制御部２８では、パケットロスを検知すると、ＲＴＣＰ部２９を通じて送信装置１０にＮＡＣＫパケットが送信される。そして、「ＮＡＣＫｔｉｍｅｏｕｔ」の時点が到来しても再送パケットが受信されていない場合、ＮＡＣＫパケットが再送される。ＮＡＣＫパケットは、「ＮＡＣＫｄｅａｄｌｉｎｅ」の時点が経過するまで繰返し再送される。
【００６４】
なお、図３Ａ、３Ｂにより説明したように、受信装置２０では、ＲＴＰ受信（ｅ´）、ＦＥＣ復号（ｆ）、デパケタイズ（ｇ）および圧縮復号（ｈ）の各処理が複数のブロックデータについて並列処理される。
【００６５】
また、受信装置２０の機能構成は、ハードウェアとして実現されてもよく、少なくとも部分的にソフトウェアとして実現されてもよい。後者の場合、受信装置２０に設けられる制御部（不図示）では、動画像伝送方法を実行するためのプログラムが実行される。
【００６６】
［４．ＦＥＣ符号方式の利用判定］
図５には、誤り訂正方式としてＦＥＣ符号方式の利用を決定するための判定条件が模式的に説明されている。
【００６７】
まず、誤り訂正後の目標ロス率Ｐａｒｑが設定される。目標ロス率Ｐａｒｑは、例えば、ＩＰＴＶのための動画像伝送ではＰａｒｑ＝１０-６等の値として設定される。次に、ＡＲＱ方式により誤り訂正を行うことを想定して、目標ロス率Ｐａｒｑを達成するために要するパケットの再送回数Ｎｎｅｔが推定される。再送回数Ｎｎｅｔは、伝送路情報として得られる平均パケットロス率Ｐｌを考慮して、式１により推定される。そして、再送回数Ｎｎｅｔに亘ってパケットを再送するために要する再送時間ｔａｒｑが算出される。再送時間ｔａｒｑは、伝送路情報として得られるＲＴＴに基づいて、式２により算出される。
【００６８】
なお、式１は、久礼等による「リアルタイム・コミュニケーションシステムのための"Ｉｎｔｅｌｌｉｇｅｎｔ  ＱｏＳ"制御方式の検討」、電子情報通信学会技術研究報告、ｖｏｌ．１０７、Ｎｏ．１９、ＣＱ２００７−１、ｐｐ．１−６、２００７年４月」の記載に基づくものである。
【００６９】
【数１】
2011211616.tif 000003
【００７０】
ここで、Ｐｌ：平均パケットロス率（ランダムパケットロス率）
Ｐａｒｑ：誤り訂正後の目標ロス率（設定値）
Ｎｎｅｔ：目標ロス率を達成するために要するパケットの再送回数
ｔａｒｑ：再送回数に亘ってパケットを再送するために要する再送時間
ＲＴＴ：往復伝送時間
【００７１】
一方、ブロックデータの処理全体に要する全処理時間Ｔｔｏｔａｌが式３により算出される。全処理時間Ｔｔｏｔａｌは、送信側および受信側で行われるキャプチャ（ａ）、圧縮処理（ｂ）、（ｈ）、パケット処理（ｃ）、（ｇ）に要する処理時間Ｔｐｒｏｃｅｓｓと伝送（ｅ）に要する伝送時間Ｔｔｒａｎｓの合計として算出される。なお、ＦＥＣ処理（符号化・復号）の処理（ｄ）、（ｆ）に要する処理時間は、ＡＲＱ方式により誤り訂正を行うことを想定しているので、処理時間Ｔｐｒｏｃｅｓｓに含まれていない。
【００７２】
ここで、処理時間Ｔｐｒｏｃｅｓｓは、伝送対象となる動画像に応じて予め設定され、伝送時間Ｔｔｒａｎｓは、ＲＴＴの１／２として設定される。よって、全体処理時間Ｔｔｏｔａｌは、伝送路ＮＷの状況に応じて変動することになる。
【００７３】
次に、ブロックデータの全処理（処理（ａ）〜（ｃ）、（ｅ）、（ｇ）、（ｈ））の完了時点から表示時点までの余裕時間Ｔｒｅｍａｉｎが式４により算出される。余裕時間Ｔｒｅｍａｉｎは、１ピクチャ分のデータのキャプチャ開始から表示時点までの利用可能時間Ｔｄｅｌａｙと、各ブロックデータの全処理の終了時点との差分として算出される。よって、余裕時間Ｔｒｅｍａｉｎは、キャプチャ開始順序の早いブロックデータほど長く、遅いブロックデータほど短くなる。
【００７４】
【数２】
2011211616.tif 000004
【００７５】
ここで、Ｔｐｒｏｃｅｓｓ：ブロックデータの処理時間（処理（ａ）〜（ｃ）、（ｇ）、（ｈ））
Ｔｔｒａｎｓ：ブロックデータの伝送時間（処理（ｅ）（＝ＲＴＴ／２））
Ｔｔｏｔａｌ：ブロックデータの全処理時間
Ｔｒｅｍａｉｎ：ブロックデータの全処理の完了時点から表示時点までの余裕時間
Ｔｄｅｌａｙ：１ピクチャ分のデータのキャプチャ開始から表示時点までの利用可能時間
Ｔｃａｐｔｕｒｅ：ブロックデータのキャプチャ時間
ｋ：ラインブロック番号ｋ（ｋ＝１、２、…、Ｎ）
【００７６】
そして、式２および式４を用いて、各ブロックデータが式５による判定条件を満たすかが判定される。
【００７７】
【数３】
2011211616.tif 000005
【００７８】
ここで、判定条件を満たす場合、ＡＲＱ方式により目標ロス率Ｐａｒｑを達成しつつ消失パケットを回復することができないので、ＦＥＣ符号方式の利用が決定される。一方、判定条件を満たさない場合、ＡＲＱ方式により目標ロス率Ｐａｒｑを達成しつつ消失パケットを回復することができるので、ＦＥＣ符号方式が利用されずに、ＡＲＱ方式が利用されることになる。
【００７９】
［５．動画像伝送システムの動作］
つぎに、図６Ａ、６Ｂを参照して、動画像伝送システムの動作について説明する。図６Ａ、６Ｂには、１ピクチャ分のデータについて、キャプチャの開始から動画像の表示に至るまでの送信装置１０および受信装置２０の動作手順が各々に示されている。
【００８０】
なお、図６Ａ、６Ｂでは、ラインブロック単位で処理が完了するように示されている。しかし、実際には、前述したように、ラインブロックのキャプチャ（ａ）を完了すると、当該ラインブロックの圧縮符号化（ｂ）を開始するとともに、他のラインブロックのキャプチャ（ａ）を開始するというように、複数のラインブロックの処理が並列して実行される。
【００８１】
まず、送信装置１０の動作について説明する。図６Ａに示すように、送信装置１０において、キャプチャ部１２は、ラインブロック単位のデータをブロックデータとしてキャプチャする（ステップＳ１０１）。ステップＳ１０１の処理では、処理を実行するたびに、ラインブロック番号ｋ＝１〜Ｎのブロックデータが順次にキャプチャされる。
【００８２】
圧縮符号化部１３は、ブロックデータを圧縮符号化し、パケタイズ部１４は、圧縮データをＲＴＰパケットにパケタイズする（Ｓ１０３）。
【００８３】
ＦＥＣ利用決定部１９は、キャプチャ部１２からのラインブロック番号ｋに基づき、前述した判定条件に従って、伝送時の誤り訂正方式としてＦＥＣ符号方式を利用するか否かを決定する（Ｓ１０５）。具体的に、ＦＥＣ利用決定部１９は、伝送路情報およびラインブロック番号ｋに基づいて、再送時間ｔａｒｑおよび余裕時間Ｔｒｅｍａｉｎを算出し、式５の判定条件を満たすかを判定する。そして、判定条件を満たす場合、誤り訂正方式としてＦＥＣ符号方式の利用が決定され、ＦＥＣ符号化部１５にＦＥＣ指示が行われ、判定条件を満たさない場合、ＡＲＱ方式が利用されることになる。
【００８４】
ＦＥＣ符号化部１５は、ＦＥＣ指示が行われたかを判定する（Ｓ１０７）。ＦＥＣ指示が行われた場合、パケットは、ＦＥＣ符号化され（Ｓ１０９）、ＦＥＣ符号化されたパケットとして受信装置２０に送信される（Ｓ１１１）。一方、ＦＥＣ指示が行われなかった場合、パケットは、ＦＥＣ符号化されず、ＦＥＣ符号化されていないパケットとして受信装置２０に送信される（Ｓ１１１）。
【００８５】
一方、ＲＴＣＰ部１７は、受信装置２０のＲＴＣＰ部２９からＮＡＣＫパケットを受信すると、ＡＲＱ指示をＡＲＱ制御部１８に通知する。ＡＲＱ制御部１８は、ＡＲＱ指示が行われたかを判定する（Ｓ１１３）。そして、ＡＲＱ指示が行われた場合、ＡＲＱ制御部１８は、消失パケットの再送を制御し、消失パケットが受信装置２０に再送される（Ｓ１１５）。なお、ステップＳ１１３、Ｓ１１５の処理は、ステップＳ１１１の処理の後続処理として行われる代わりに、ステップＳ１０１〜Ｓ１０９の処理と並行して行われてもよい。
【００８６】
また、キャプチャ部１２は、ラインブロック番号ｋに基づき１ピクチャ分のデータのキャプチャを完了したか、つまりラインブロック番号ｋ＝Ｎのブロックデータをキャプチャしたかを判定する（Ｓ１１７）。そして、キャプチャを完了した場合、１ピクチャ分のパケットの送信を完了するまで、ＡＲＱ指示の判定およびパケットの再送が繰返される（Ｓ１１９〜Ｓ１２３）。
【００８７】
一方、キャプチャを完了していない場合、キャプチャ部１２は、ラインブロック番号ｋを１インクリメントし、次のラインブロックのデータをブロックデータとしてキャプチャする（Ｓ１０１）。
【００８８】
つぎに、受信装置２０の動作について説明する。図６Ｂに示すように、受信装置２０において、ＲＴＰ受信部２１は、伝送路ＮＷを通じて送信装置１０からパケットを受信する（Ｓ１５１）。パケットは、ＦＥＣ符号化されたパケット、またはＦＥＣ符号化されていないパケットとして受信される。
【００８９】
ＲＴＰ受信部２１は、パケットがＦＥＣ符号化されているかを判定する（Ｓ１５３）。そして、ＦＥＣ符号化されている場合、ＦＥＣ復号部２２は、パケットをＦＥＣ復号する（Ｓ１５５）。ここで、パケットロスが発生した場合には、冗長パケットによりロスが回復される。また、デパケタイズ部２３は、パケットをデパケタイズし、圧縮復号部２４は、圧縮データを圧縮復号する（Ｓ１５７）。
【００９０】
一方、ＦＥＣ符号化されていない場合、ロス検知部２７は、受信したパケットについて、パケットロスが発生しているかを検知する（Ｓ１５９）。ロス検知部２７は、検知結果をＡＲＱ制御部２８に通知する。ＡＲＱ制御部２８は、ロスが発生している場合、ＮＡＣＫパケットをＲＴＣＰ部２９を通じて送信装置１０に送信する（Ｓ１６１）。一方、ロスが発生していない場合、パケットのデパケタイズおよび圧縮データの圧縮復号が行われる（Ｓ１５７）。
【００９１】
ステップＳ１５７またはＳ１６１の処理を終了すると、１ピクチャ分の処理が完了したかが判定される（Ｓ１６３）。そして、処理を完了した場合には表示処理（Ｓ１６５）が行われ、完了していない場合には、次のラインブロックのパケットが受信される（Ｓ１５１）。
【００９２】
［６．まとめ］
以上説明したように、本発明の実施形態に係る動画像伝送システムによれば、表示のために１ピクチャ分の全てのデータを要する動画像が伝送される。システムでは、１ピクチャ分のデータがラインブロック単位のブロックデータとしてキャプチャされる。また、伝送路ＮＷの状況および各ブロックデータのキャプチャ時点に応じて、各ブロックデータのパケットを送信する際の誤り訂正方式として、ＦＥＣ符号方式またはＡＲＱ方式のいずれかが利用される。ここで、再送により回復可能なブロックデータには、ＡＲＱ方式が利用され、再送により回復不能なブロックデータには、ＦＥＣ符号方式が利用される。
【００９３】
これにより、キャプチャ開始順序の早いブロックデータは、消失パケットの再送により回復され、キャプチャ開始順序の遅いブロックデータは、冗長符号化されて送信されたパケットのうち所定数のパケットを受信することで回復される。よって、伝送遅延に関してクリティカルとなるブロックデータにのみＦＥＣ符号方式を利用することで、表示のために１ピクチャ分の全てのデータを要する動画像を、通信リソースの消費を抑制しつつ低遅延で伝送することができる。
【００９４】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【００９５】
例えば、上記説明では、ラインブロック単位で並列処理を行う場合について説明した。しかし、所定数のブロックデータからなる処理単位をパイプライン化して並列処理してもよい。この場合、ＦＥＣ符号方式の利用は、所定数のブロックデータのパケットについて、再送回数Ｎｎｅｔ、再送時間ｔａｒｑ、全処理時間Ｔｔｏｔａｌ、キャプチャ時間Ｔｃａｐｔｕｒｅおよび余裕時間Ｔｒｅｍａｉｎを算出し、前述した判定条件に基づき決定されることになる。
【符号の説明】
【００９６】
１０    送信装置
１１    入力ＩＦ
１２    キャプチャ部
１３    圧縮符号化部
１４    パケタイズ部
１５    ＦＥＣ符号化部
１６    ＲＴＰ送信部
１７    ＲＴＣＰ部
１８    ＡＲＱ制御部
１９    ＦＥＣ利用決定部
２０    受信装置
２１    ＲＴＰ受信部
２２    ＦＥＣ復号部
２３    デパケタイズ部
２４    圧縮復号部
２５    表示処理部
２６    出力ＩＦ
２７    ロス検知部
２８    ＡＲＱ制御部
２９    ＲＴＣＰ部
ＮＷ    伝送路
Ｖ    ビデオカメラ
Ｄ    ディスプレイ
【図１】
2011211616.tif 000006
【図２】
2011211616.tif 000007
【図３Ａ】
2011211616.tif 000008
【図３Ｂ】
2011211616.tif 000009
【図４】
2011211616.tif 000010
【図５】
2011211616.tif 000011
【図６Ａ】
2011211616.tif 000012
【図６Ｂ】
2011211616.tif 000013