情報処理装置および方法、並びにプログラム
【課題】コンテンツの品質の劣化を抑制することができるようにする。
【解決手段】受信バッファ時間設定部１３８は、画像品質要求および伝送品質要求を受け付ける。受信バッファ時間設定部１３８は、受信バッファ時間決定処理を行い、ARQ部１３６や受信バッファ１３２の設定を行ったり、RTCP部１３７を介して、決定した情報等を送信装置１０１に通知したりする。受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７を介してこの通知を受け取ると、その通知に基づいて受信バッファ時間・処理パラメータ設定処理を行い、符号化部１１１やFEC部１１２の設定を行う。本発明は、例えば、情報処理装置に適用することができる。
【解決手段】受信バッファ時間設定部１３８は、画像品質要求および伝送品質要求を受け付ける。受信バッファ時間設定部１３８は、受信バッファ時間決定処理を行い、ARQ部１３６や受信バッファ１３２の設定を行ったり、RTCP部１３７を介して、決定した情報等を送信装置１０１に通知したりする。受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７を介してこの通知を受け取ると、その通知に基づいて受信バッファ時間・処理パラメータ設定処理を行い、符号化部１１１やFEC部１１２の設定を行う。本発明は、例えば、情報処理装置に適用することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置および方法、並びにプログラムに関し、特に、コンテンツの品質の劣化を抑制することができるようにした情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、インターネット、LAN（Local Area Network）、若しくは、その他の伝送路を経由して、メディア基準信号同期（所謂GENLOCK同期）を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
【０００３】
例えば、放送局においてカメラとそのコントロールユニット（所謂CCU（Camera Control Unit）とを、HD-SDI（High Definition Serial Digital Interface）ケーブルにより接続し、非圧縮同期伝送を行うシステムが存在する。近年、このシステムのHD-SDIケーブルをEthernet（登録商標）ケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
【０００４】
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手が要求されるため、例えば、高精度のGENLOCK同期とビデオフレーム間隔以下の低遅延伝送が要求される。
【０００５】
このような要求から動画像の各ピクチャの数ライン毎を１つの符号化ブロック（ラインブロック）としてウェーブレット変換による符号化を行う方式が提案されている（例えば特許文献１参照）。
【０００６】
この方式では、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。そのため、生成した符号化データをネットワーク伝送し、受信側で復号する場合においても、ピクチャ内の全てのデータを受信する前に復号処理を開始することができる。つまり、ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム（即時的な）動画像伝送が可能となる。
【０００７】
このようなデータ伝送においては、システムが破たんしないように、安定的にデータ伝送を行うために、エラー訂正やパケット再送などのための時間が遅延時間として設定される。このように、処理の待ち時間やデータのバッファリング等のような、遅延時間の確保が必要な要素を遅延要素と称する。
【０００８】
一般的に、データ伝送においては、複数の遅延要素が存在する場合が多い。このような遅延要素に対して、受信側の装置においては遅延時間が確保されるが、このように複数の遅延要素が存在する場合、受信側の装置における遅延時間は、各遅延要素についての遅延時間のうち、最も長いもの（若しくはそれ以上）に設定される。
【０００９】
つまり、受信側の装置における遅延時間設定よりも短い遅延時間の遅延要素については、その遅延時間設定と同じ時間まで遅延時間を延ばしても、受信側の遅延時間設定は変化しない。つまり、データ伝送全体の遅延時間は増大しない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許４３７１１２０号
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、従来の方式においては、上述した各遅延要素についての遅延時間は、互いに独立して設定されていたので、遅延時間が短く設定された遅延要素に関係する処理は、その遅延時間が不要に短く設定されたまま実行されることになり、その処理後、何も処理が行われない不要な待機時間が生じてしまう恐れがあった。すなわち、データ伝送によりコンテンツの品質を不要に劣化させる恐れがあった。
【００１２】
本発明は、このような状況に鑑みてなされたものであり、各処理の時間的余裕を画質や伝送品質の向上に利用することができるようにし、遅延時間上の無駄を低減させることができるようにすることを目的とする。
【課題を解決するための手段】
【００１３】
本発明の一側面は、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段と、前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段とを備える情報処理装置である。
【００１４】
前記遅延時間は、前記データ伝送のQoS制御処理時間であり、前記調整手段は、前記QoS制御処理時間として要求されるQoS制御処理要求時間のうち、最長のQoS制御処理要求時間、若しくはそれ以上の所定の時間に合わせるように、各遅延時間の長さを調整することができる。
【００１５】
前記QoS制御処理時間は、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を含むことができる。
【００１６】
前記設定手段は、前記再送パケット待ち時間を、前記パケットの再送処理を行う再送処理部に設定し、前記ネットワークジッタ対応バッファ時間を、伝送された前記データを一時的に保持する保持部に設定することができる。
【００１７】
前記データ伝送における伝送品質に関する要求である伝送品質要求、および、前記冗長符号化ブロック受信待ち時間を用いて、前記データ送信側のQoS制御処理のパラメータ設定を行うパラメータ設定手段をさらに備えることができる。
【００１８】
前記データは伝送元において符号化され、得られた符号化データが伝送され、伝送先において前記符号化データが復号され、前記遅延時間は、前記符号化においてレート制御されて生成された前記符号化データを平滑化伝送する際に必要な可変圧縮符号化遅延要求時間を含み、前記データの画質に関する要求である画像品質要求、および、前記可変圧縮符号化遅延要求時間を用いて、前記符号化のバッファサイズを含む符号化パラメータの設定を行うパラメータ設定手段をさらに備えることができる。
【００１９】
前記データの画質に関する要求である画像品質要求、および、前記データ伝送における伝送品質に関する要求である伝送品質要求を受け付ける受付手段をさらに備え、前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、各遅延時間として要求される遅延要求時間を設定することができる。
【００２０】
前記受付手段により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力手段をさらに備えることができる。
【００２１】
複数の送信装置から１つの受信装置に向けて行われる前記データ伝送において、前記調整手段は、前記送信装置毎に前記遅延時間の調整を行い、さらに、各送信装置間で、それぞれの前記データ伝送全体の遅延時間が揃うように、前記遅延時間の調整を行うことができる。
【００２２】
本発明の一側面は、また、情報処理装置の情報処理方法であって、前記情報処理装置の調整手段が、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整し、前記情報処理装置の設定手段が、長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する情報処理方法である。
【００２３】
本発明の一側面は、さらに、データ伝送を行うコンピュータを、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段、前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段として機能させるためのプログラムである。
【００２４】
本発明の一側面においては、データ伝送を遅延させる遅延時間であって、データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さが、複数の遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整され、長さが調整された複数の遅延時間のそれぞれが、データ伝送に関する処理を行う処理部に設定される。
【発明の効果】
【００２５】
本発明によれば、データを伝送することができる。特に、コンテンツの品質の劣化を抑制することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明を適用した伝送システムの主な構成例を示すブロック図である。
【図２】符号化部の主な構成例を示すブロック図である。
【図３】分析フィルタリングの概要を説明する図である。
【図４】分析フィルタリングの概要を説明する図３に続く図である。
【図５】ラインブロックを説明する図である。
【図６】復号部の主な構成例を示すブロック図である。
【図７】データ伝送処理の流れの例を説明するフローチャートである。
【図８】要求受付画面の表示例を示す図である。
【図９】受信バッファ時間決定処理の流れの例を説明するフローチャートである。
【図１０】遅延時間設定の様子の例を説明する図である。
【図１１】受信バッファ時間・処理パラメータ設定処理の流れの例を説明するフローチャートである。
【図１２】データ伝送処理の流れの他の例を説明するフローチャートである。
【図１３】受信バッファ動的変更伝送処理の流れの例を説明するフローチャートである。
【図１４】本発明を適用した伝送システムの主な構成例を示すブロック図である。
【図１５】受信部の主な構成例を示すブロック図である。
【図１６】データ伝送処理の流れの、さらに他の例を説明するフローチャートである。
【図１７】仮受信バッファ時間決定処理の流れの例を説明するフローチャートである。
【図１８】統合受信バッファ時間決定処理の流れの例を説明するフローチャートである。
【図１９】受信バッファ時間設定の様子の例を説明する図である。
【図２０】受信バッファ動的変更伝送処理の流れの、他の例を説明するフローチャートである。
【図２１】本発明を適用したパーソナルコンピュータの主な構成例を示すブロック図である。
【発明を実施するための形態】
【００２７】
以下、発明を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（伝送システム）
２．第２の実施の形態（伝送システム）
３．第３の実施の形態（伝送システム）
４．第４の実施の形態（パーソナルコンピュータ）
【００２８】
＜１．第１の実施の形態＞
［伝送システムの概要］
図１は、本発明を適用した伝送システムの主な構成例を示すブロック図である。伝送システム１００は、送信装置１０１に入力された画像データ（ビデオデータ（ビデオIN））を、リアルタイムに（即時的に）、インターネットやLAN等の汎用の伝送路であるネットワーク１０２を介して受信装置１０３伝送し、その受信装置１０３より出力する（ビデオOUT）システムである。
【００２９】
送信装置１０１は、外部入力端子「ビデオIN」より入力された動画像の画像データを、全てのデータが入力されるまで待たずに、順次、符号化し、生成した符号化データのパケットを、ネットワーク１０２を介して受信装置１０３に送信する。
【００３０】
ネットワーク１０２は、例えば、インターネットやLAN等のような汎用のIPパケット網である。ネットワーク１０２においては、送信装置１０１および受信装置１０３の間のデータ伝送以外の、他のデータ伝送も行われる。
【００３１】
受信装置１０３は、送信装置１０１から伝送されるパケットを受信し、順次、得られた符号化データを復号し、復号画像の画像データを外部出力端子「ビデオOUT」より出力する。なお、受信装置１０３は、送信装置１０１に入力される画像データのサンプリング周波数に同期したタイミングで画像データの出力を行う。つまり、画像データは、送信装置１０１に入力されるときと同じフレームレートで受信装置１０３より出力される。伝送システム１００は、この出力タイミングに間に合うようにデータ伝送を行う。
【００３２】
近年においては、インターネットやLAN（Local Area Network）の汎用の伝送路を経由してメディア基準信号同期（所謂GENLOCK同期）を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
【００３３】
例えば、放送局においては、従来、カメラとそのコントロールユニット（所謂CCU）がHD-SDIケーブルにより接続され、それらの間で非圧縮同期伝送が行われていた。近年においては、このHD-SDIケーブルをEthernetケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
【００３４】
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手を要求される。そのため、高精度のGENLOCK同期や、ビデオフレーム間隔以下の低遅延伝送等が要求される。
【００３５】
このような要求から特許文献１においては、動画像の各ピクチャの数ライン毎を１つの符号化ブロック（ラインブロック）とし、符号化を行う方式が提案されている。この方式の場合、送信装置１０１は、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。また、送信装置１０１は、その符号化により得られた符号化データを、順次、ネットワーク１０２を介して受信装置１０３に伝送することができる。
【００３６】
さらに、受信装置１０３は、ピクチャ内の全てのデータを受信する前に復号を開始することができる。ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム動画像伝送（送信装置１０１入力時のフレームレートで、受信装置１０３から出力することができるようなデータ伝送）が可能となる。
【００３７】
動画像の符号化処理では、フレームやラインブロック等、短い時間単位において一定データレートにて符号化を行うCBR（Constant Bit Rate）方式と、長い時間間隔における平均データレートは一定だが短い時間間隔ではデータレートが変動するVBR（Variable Bit Rate）方式がある。
【００３８】
VBR方式で圧縮されたストリームデータを伝送する場合、ITU-T Y.1221記載のトークンバケット等を用い平滑化処理を行い、符号化処理においてはトークンバケットの最大バケツサイズを超えないように制御する。このとき最大バケツサイズにより符号化処理における最大バースト（瞬時）データサイズは制限される。
【００３９】
VBR方式の場合、一般に、画像の複雑度の高い部分、動きの激しいシーン等の圧縮効率の低い部分に多くのデータを割り当てることができる。そのため、一般的に、VBR方式の方がCBR方式よりも圧縮効率が高い。つまり、一般的に、同一の平均データレートの場合、VBR方式の方がCBR方式よりも高画質である。
【００４０】
トークンバケットにおける最大バケツサイズを大きくとればとるほど画質は向上するが、ストリーム伝送後の同期再生を考えた場合、同期再生までの遅延時間は大きくなる。以下において、VBR方式で符号化処理を行った場合の平滑化処理により生じる遅延時間を可変圧縮符号化遅延時間と称する。
【００４１】
上述したようなリアルタイム伝送に適したインターネット技術にIETF RFC3550で規定されているRTP（Realtime Transport Protocol）がある。RTPによるデータ転送では、時間情報としてパケットにタイムスタンプを付加しておき、これによって送信側と受信側の時間的関係を把握することでパケット転送の遅延ゆらぎ（ジッタ）などの影響を受けずに同期をとって再生することができる。
【００４２】
ここでRTPは、実時間のデータ転送を保証しているものではない。例えばパケット配送の優先度の設定や管理などはRTPが提供するトランスポートサービスの範疇ではない。そのため、RTPパケットは、他のパケットと同様に、配送遅延やパケット損失がおきる可能性がある。このような事態が起こる場合であっても、受信装置１０３は、期待する時間内に到着したパケットだけを利用してデータを再生することができる。映像や音声データは、多少のデータ損失があったとしても、ある程度再生することができる。
【００４３】
なお、遅延配送されたパケットやエラーの発生したパケットは、受信装置１０３により、破棄される。つまり、パケット損失やエラーにより高品質なデータを配信するようにしても、受信装置１０３において、その高品質なデータが十分に再生されない恐れがある。有線区間で１０−５以上、無線区間で１０−３以上のエラーがあるといわれており、このような現状の中でRTPをそのまま利用するのでは、配信するメディアの品質を保持する点について信頼性が低い。
【００４４】
これに対して、データ転送に信頼性が高いTCP（Transmission Control Protocol）で再送要求および再送パケット送信を行わせる方法がある。しかしながら、TCPは、エラーには強いものの、スループットが低く遅延が大きい。そのため、再送しても再生時間に間に合わない恐れがある。
【００４５】
RTPを用いてデータ転送の信頼性を向上させる手法として、データの冗長符号化を行い信頼性の向上を図る、前方誤り訂正符号化方式（所謂FEC(Forward Error Correction)方式）という手法がある。
【００４６】
FEC方式では、パケット複数個を１つのFECブロックとし、Reed-Solomon（RS）符号等の誤り訂正符号を用いて冗長符号化を行う。例えば（n,k）RS符号を用いる場合、元パケットをk個とするとn-k個冗長パケットを生成することができる（n > k）。この場合、送信装置１０１から合計n個のパケットを送信することにより、受信装置１０３ではn個のパケット中k個のパケットを受信すれば、RS復号処理によりk個の元パケットを復元することができる。
【００４７】
FEC方式を用いて冗長符号化した場合、パケット損失に対する回復性能はFECブロック元データ単位と冗長パケット数n-kとに依存する。特に、ネットワーク伝送中に起こるデータ系列上連続するパケットの損失（所謂バーストパケット損失）に対する回復性能は、FECブロック元データ単位と関係が深い。一般に、FECブロック元データ単位を大きくとればとるほど、バーストパケット損失に対する回復性能は向上する。
【００４８】
しかしながら、FECブロック元データ単位を大きく取るとFEC符号化処理・復号処理を行うために必要なブロックサイズ（データ量）が増大する。その分、処理に必要なデータ蓄積量、すなわち、待機時間が増大するので、遅延時間が増大する恐れがあった。このようなFEC符号化処理やFEC復号処理に必要な遅延時間を、冗長符号化ブロック受信待ち時間と称する。
【００４９】
データ転送の信頼性を向上させる他の手法として、自動再送方式、いわゆるARQ（Auto Repeat Request）方式がある。ARQ方式は、受信装置１０３が、RTPパケットのシーケンス番号を利用して損失したパケットを検知し、送信装置１０１へ損失パケットの再送を要求するようにする方式である。このARQ方式の拡張方法として、受信装置１０３が、パケット損失に対して一定時間再送パケットを受信しなかった場合、再度再送要求を行う手法もある。
【００５０】
この手法を用いる場合、受信装置１０３における再送パケット待ち時間を大きく設定すればするほど回復性能は向上するが、その分、同期再生時の遅延を増大させてしまう。
【００５１】
また他の伝送品質の回復手法として、受信装置１０３が、ネットワーク伝送時間の変動（所謂ネットワークジッタ）を吸収するためのバッファ（ネットワークジッタ対応バッファ）を設ける方法もある。このネットワークジッタ対応バッファでバッファリングを行う時間、（所謂ネットワークジッタ対応バッファ時間）を大きくとればとるほど、受信装置１０３において行われる各種処理における、ネットワークジッタによる影響を抑制することができる。ただし、その分、同期再生時の遅延を増大させてしまう。
【００５２】
以上のように、データ伝送に関して、一般的に、多様な遅延要素が存在し、受信側の装置においては、各遅延要素についての遅延時間の確保が必要であった。
【００５３】
しかしながら、従来においては、復号画像の画質（画質要求）や、データ伝送時のパケット損失率（伝送品質）等に対する要求に応じて、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、および、ネットワークジッタ対応バッファ時間等の各種遅延時間が互いに独立に設定されていた。
【００５４】
受信装置１０３は、これらの遅延によりシステムが破たんしないように、受信したデータを、これらの遅延時間の最大値以上の時間、一時的に保持する。つまり、各遅延要素の遅延時間を受信装置１０３において確保する必要があった。このデータを保持する時間を受信バッファ時間と称する。
【００５５】
この場合、例えば可変圧縮符号化遅延時間が上記遅延時間中最大値であり、この値を受信バッファ時間として設定したとする。その場合、冗長符号化処理において、さらに冗長符号化ブロックを大きく取ることによりバースト損失耐性を向上させ、冗長符号化ブロック受信待ち時間を受信バッファ時間と同等まで大きくしても全体の遅延時間は増加しない。
【００５６】
しかしながら、仮に、冗長符号化ブロック受信待ち時間が、従来の方法のように、他と独立して設定されるとする。その場合、冗長符号化処理は、冗長符号化ブロック受信待ち時間が小さいまま行われることになる。つまり、冗長符号化処理において、処理が行われない不要な待機時間が発生し、遅延時間上の無駄が生じる恐れがあった。
【００５７】
また、冗長符号化ブロック受信待ち時間が最大である場合、可変圧縮符号化遅延時間を大きく設定することにより、全体の遅延時間を増大させずに画質を向上させることができる。しかしながら、上述した従来の方法のように各遅延時間が互いに独立して設定されるものとすると、符号化処理は、可変圧縮符号化遅延時間が小さい設定のまま行われることになる。つまり、遅延時間上の無駄が生じる恐れがあった。
【００５８】
受信装置１０３は、データ伝送を遅延させる遅延時間であって、そのデータ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、その複数の遅延時間の内、最長の遅延時間に合わせるように調整する。
【００５９】
送信装置１０１も、受信装置１０３から供給される情報に基づいて、受信装置１０３において確保された遅延時間（受信バッファ時間）より遅延時間が増大しないように、かつ、より遅延時間を長くし、画像や伝送の品質を向上させるように、各処理のパラメータを設定する。
【００６０】
したがって、伝送システム１００（送信装置１０１および受信装置１０３）は、このような遅延時間上の無駄を抑制するようにし、データ伝送全体の遅延時間を増大させずに画質や伝送品質（コンテンツの品質）を向上させることができる。
【００６１】
［送信装置の構成］
図１に示されるように、送信装置１０１は、符号化部１１１、FEC部１１２、RTP部１１３、平滑化部１１４、基準信号同期部１１５、メディア同期部１１６、RTCP（RTP Control Protocol）部１１７、ARQ部１１８、および受信バッファ時間・処理パラメータ設定部１１９を有する。
【００６２】
ビデオカメラ等を経由しビデオ入力IF「ビデオIN」より入力したビデオデータ（動画像データ）は、符号化部１１１に供給される。符号化部１１１は、所定の符号化方式で動画像データの符号化処理を行う。この符号化方式は任意であるが、より低遅延なものが望ましい。符号化方式の例については後述する。
【００６３】
符号化部１１１は、レート制御部１２１を有する。レート制御部１２１は、符号化部１１１において生成される符号化データのビットレートを制御する。符号化部１１１は、生成した符号化データをRTPパケット化し、それをFEC部１１２に供給する。
【００６４】
FEC部１１２は、符号化部１１１から供給されるRTPパケットの冗長パケットを生成する。RTP部１１３は、FEC部１１２から供給される符号化データの冗長パケットをRTPパケット化する。
【００６５】
平滑化部１１４は、RTP部１１３から供給されるRTPパケットを、一時的に保持し、所定のデータレートに平滑化して送信する。
【００６６】
基準信号同期部１１５は、ネットワーク１０２を介して、伝送先である受信装置１０３の基準信号同期部１３９と通信を行い、基準信号クロックの同期をとる。基準信号同期部１１５は、受信装置１０３との間で同期がとれた基準信号をメディア同期部１１６に供給する。
【００６７】
メディア同期部１１６は、基準信号同期部１１５から供給される時刻を基準として、ビデオINに入力されたデータのサンプリング時刻と同期した時刻を、符号化部１１１（内のRTP部）とRTP部１１３に供給する。この時刻は、RTPタイムスタンプとしてRTPパケットに付加される。
【００６８】
RTCP部１１７は、伝送先の受信装置１０３のRTCP部１３７とRTCPメッセージの授受を行い、QoS（Quality of Service）制御処理のための制御メッセージ（QoS制御メッセージ）の送受信を行う。RTCP部１１７は、取得した制御メッセージをARQ部１１８や受信バッファ時間・処理パラメータ設定部１１９に供給する。
【００６９】
ARQ部１１８は、RTCP部１１７から供給される再送要求メッセージに従って、要求されたRTPパケットの再送を行う。
【００７０】
受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７から供給される各種遅延時間等の設定に従って、符号化部１１１やFEC部１１２のパラメータ設定を行う。
【００７１】
［受信装置の構成］
図１に示されるように、受信装置１０３は、受信部１３１、受信バッファ１３２、RTP部１３３、FEC部１３４、復号部１３５、ARQ部１３６、RTCP部１３７、受信バッファ時間設定部１３８、基準信号同期部１３９、メディア同期部１４０、入力部１４１、および出力部１４２を有する。
【００７２】
受信部１３１は、ネットワーク１０２を介して送信装置１０１から伝送されるRTPパケットを受信し、それを受信バッファ１３２に供給する。受信バッファ１３２は、ネットワーク１０２におけるパケット伝送の遅延時間の変動を吸収する等のために、受信部１３１から供給されるRTPパケットを、一時的に保持した後、受信バッファ時間設定部１３８やメディア同期部１４０からの情報に基づいて決定される時刻に、RTP部１３３に供給する。
【００７３】
RTP部１３３は、RTPパケットを再構成して、冗長パケットを含む符号化データであるFEC冗長符号化データを生成し、それをFEC１３４に供給する。FEC部１３４は、パケットの損失の検出を行い、必要に応じて冗長符号化復号処理によって損失パケットデータを回復する。FEC部１３４は、処理後の符号化データを復号部１３５に供給する。
【００７４】
復号部１３５は、符号化データを、符号化部１１１による符号化処理の方式に対応する復号方式により復号する。復号されたビデオデータ（動画像データ）は、受信装置１０３のビデオ出力IF（ビデオOUT）から、例えば、ディスプレイ等の映像表示装置（図示せず）に出力される。
【００７５】
ARQ部１３６は、受信部１３１における損失パケット（受信できなかったパケット）の検出を行い、損失パケットを検出した場合、RTCP部１３７を制御し、送信装置１０１のARQ部１１８に対する再送要求メッセージを送信させる。RTCP部１３７は、ARQ部１３６から要求された再送要求メッセージや、受信バッファ時間設定部１３８から供給される各種設定情報をRTCPメッセージとして、送信装置１０１のRTCP部１１７に供給する。
【００７６】
受信バッファ時間設定部１３８は、例えば入力部１４１を介して入力される画像品質要求や、伝送品質要求等に基づいて、受信バッファ時間等を設定する。画像品質要求は、復号画像（受信装置１０３から出力されるビデオデータの画像）の画質に対する要求である。伝送品質要求は、ネットワーク１０２のパケットロス率等に対する要求である。受信バッファ時間は、システムを破たんさせないように、データ伝送を安定的に伝送させるために受信装置１０３において設定される遅延時間である。
【００７７】
基準信号同期部１３９は、基準信号同期部１１５と通信し、送信装置１０１との間で基準信号の同期をとる。メディア同期部１４０は、基準信号同期部１３９により同期がとられた基準信号に基づいて、受信バッファ１３２のRTPパケット出力タイミングや、復号部１３５の復号処理開始タイミング等を制御する。
【００７８】
入力部１４１は、例えば、キーボード、マウス、タッチパネル、若しくはスイッチ等の任意の入力デバイス、または外部入力端子等よりなり、例えばユーザ等の、受信装置１０３外部からの画像品質要求や伝送品質要求を受け付け、それを受信バッファ時間設定部１３８に供給する。
【００７９】
出力部１４２は、例えば、モニタやスピーカ等の任意の出力デバイス、または、外部出力端子等よりなり、受信バッファ時間設定部１３８から供給されるGUI画像を表示したり、音声を出力したりして、画像品質要求や伝送品質要求の入力案内や、入力結果を出力する。
【００８０】
［符号化部の構成例］
次に、送信装置１０１の符号化部１１１の例について説明する。図２は、送信装置１０１の符号化部１１１の構成例を示すブロック図である。符号化部１１１は、画像データを解像度に関して重要度の高いデータから順に階層化し、その階層毎に符号化する階層符号化を行う。例えば、符号化部１１１は、空間解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。また、例えば、符号化部１１１は、時間方向の解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。さらに、例えば、符号化部１１１は、SNR（Signal to Noise Ratio）に関して重要度の高いデータから順に階層化された階層化データを生成する。符号化部１１１は、このように生成した階層化データを、その階層毎に符号化する。
【００８１】
このような階層符号化として、例えば、動画像データの各ピクチャをウェーブレット変換し、エントロピ符号化するJPEG(Joint Photographic Experts Group)2000方式がある。階層符号化方法は任意であるが、以下においては、符号化部１１１が、動画像データを複数ライン毎にウェーブレット変換し、エントロピ符号化する場合について説明する。
【００８２】
図２に示されるように、符号化部１１１は、ウェーブレット変換部１６１、量子化部１６２、エントロピ符号化部１６３、レート制御部１２１、およびRTP部１６４を有する。ウェーブレット変換部１６１は、動画像の各ピクチャを、複数ライン毎にウェーブレット変換する。
【００８３】
ウェーブレット変換は、入力データを低域成分と高域成分に分割する分析フィルタ処理を画面水平方向および画面垂直方向の両方に対して行う処理である。つまり、ウェーブレット変換処理により入力データは、水平方向および垂直方向に低域な成分（ＬＬ成分）、水平方向に高域で垂直方向に低域な成分（ＨＬ成分）、水平方向に低域で垂直方向に高域な成分（ＬＨ成分）、および、水平方向および垂直方向に高域な成分（ＨＨ成分）の４つの成分（サブバンド）に分割される。
【００８４】
ウェーブレット変換部１６１は、このようなウェーブレット変換処理を、所定回数、分析フィルタ処理により得られる水平方向および垂直方向に低域な成分（ＬＬ成分）に対して再帰的に繰り返す。つまり、ウェーブレット変換処理により、動画像データの各ピクチャは、階層化された複数のサブバンド（周波数成分）に分割される（階層化データが生成される）。エントロピ符号化部１６３は、このサブバンド毎に符号化を行う。
【００８５】
動画像の各ピクチャの画像データは、画像の上から下に向かう順に１ラインずつウェーブレット変換部１６１に入力される。また各ラインの画像データは、画像左から右に向かう順に１サンプル（１コラム）ずつ入力される。
【００８６】
ウェーブレット変換部１６１は、そのように入力される画像データに対して、分析フィルタリングを実行可能なサンプル数のデータを入手する毎に（入手次第）、画像水平方向の分析フィルタリング（水平分析フィルタリング）を実行する。例えば、ウェーブレット変換部１６１は、図３の左に示されるベースバンドの画像データ１７１に対して、Ｍコラム入力される毎に水平分析フィルタリングを行い、１ラインずつ水平方向に低域な成分（Ｌ）と高域な成分（Ｈ）に分割する。図３の右に示される水平分析フィルタ処理結果１７２は、ウェーブレット変換部１６１により分割されたＮライン分の水平方向に低域な成分（Ｌ）と高域な成分（Ｈ）を示す。
【００８７】
次に、ウェーブレット変換部１６１は、その水平分析フィルタ処理結果１７２の各成分に対して、垂直方向に分析フィルタリング（垂直分析フィルタリング）を行う。ウェーブレット変換部１６１は、水平分析フィルタリングにより、垂直分析フィルタリングに必要な垂直ライン分の係数が生成されると、その垂直分析フィルタリングに必要な垂直ライン分の係数に対して、コラム毎に垂直分析フィルタリングを行う。
【００８８】
その結果、水平分析フィルタ処理結果１７２は、図４の左に示されるように、水平方向および垂直方向の両方に低域な成分（ＬＬ成分）、水平方向に高域で垂直方向に低域な成分（ＨＬ成分）、水平方向に低域で垂直方向に高域な成分（ＬＨ成分）、および、水平方向および垂直方向の両方に高域な成分（ＨＨ成分）の４つの成分のウェーブレット変換係数（以下、係数と称する）に分割される（階層化データ１７３）。
【００８９】
所定の階層（分割レベル）の係数が得られるまで、得られた分析フィルタリングの結果のうち、ＨＬ成分、ＬＨ成分、ＨＨ成分は外部に出力される。残りのＬＬ成分は、ウェーブレット変換部１６１により、再度分析フィルタリングが行われる。つまり、例えば、図４の左に示される階層化データ１７３は、図４の右に示される階層化データ１７４に変換される。階層化データ１７４では、ＬＬ成分から、ＬＬＬＬ成分、ＬＬＨＬ成分、ＬＬＬＨ成分、およびＬＬＨＨ成分の４つの成分が生成されている。
【００９０】
ウェーブレット変換部１６１は、このような分析フィルタリングを所定回数再帰的に行い、動画像データを所望の分割レベルまで階層化された階層化データを生成する。図５は、分割レベル３（３階層）まで階層化された階層化データの例を示す図である。図５において、分割レベル３まで分割された階層化データ１７５は、分割レベル１（階層番号３）の３ＨＬ成分、３ＬＨ成分、および３ＨＨ成分、分割レベル２（階層番号２）の２ＨＬ成分、２ＬＨ成分、および２ＨＨ成分、並びに、分割レベル３（階層番号１）の１ＬＬ成分、１ＨＬ成分、１ＬＨ成分、および１ＨＨ成分の各サブバンドにより構成される。
【００９１】
ウェーブレット変換処理では、フィルタリング処理を繰り返す毎に（階層が１つ下位になる毎に）、生成されるライン数は２のべき乗分の１の大きさで小さくなっていく。最終分割レベル（階層番号１）の係数を１ライン生成するために必要なベースバンドのライン数は、そのフィルタリング処理を何回繰り返すか（最終分割レベルの階層数）によって決められる。通常、この階層数は予め定められる。
【００９２】
この、最終分割レベルの係数を１ライン生成するために必要なベースバンドの画像データ（複数ライン分の画像データ）、または、各階層の係数をまとめてラインブロック（またはプレシンクト）と称する。
【００９３】
図５において斜線で示される部分が１ラインブロックを構成する係数である。図５に示されるように、ラインブロックは、階層番号１の各成分の１ライン分の係数、階層番号２の各成分の２ライン分の係数、並びに、階層番号３の各成分の４ライン分の係数により構成される。なお、これらに相当する分析フィルタリング前の画像データ、すなわち、この例では８ライン分の画像データのこともラインブロック（またはプレシンクト）と称する。
【００９４】
図２に戻り、量子化部１６２は、ウェーブレット変換部１６１により生成される各成分の係数を、例えば量子化ステップサイズで除算することにより量子化し、量子化係数を生成する。この際、量子化部１６２は、ラインブロック（プレシンクト）毎に量子化ステップサイズを設定することができる。このラインブロックは、ある画像領域のすべての周波数成分（図５の場合、１ＬＬ乃至３ＨＨまでの１０個の周波数成分）の係数を包含しているため、ラインブロック毎に量子化を行えば、ウェーブレット変換の特徴である多重解像度分析の利点を活かすことができる。また、全画面でラインブロック数だけを決めればよいため、量子化の負荷も小さくて済む。
【００９５】
さらに、画像信号のエネルギは一般的に低域成分に集中しており、また、人間の視覚上、低域成分の劣化が目立ちやすいという特性があるため、量子化に際しては、低域成分のサブバンドでの量子化ステップサイズが結果的に小さな値になるように、重み付けを行うことが有効である。この重み付けにより、低域成分には相対的に多くの情報量が割り当てられるようになり、全体の主観的な画質が向上する。
【００９６】
エントロピ符号化部１６３は、量子化部１６２で生成された量子化係数を情報源符号化し、圧縮された符号化データを生成し、それをレート制御部１２１に供給する。情報源符号化としては、例えばJPEG方式やMPEG（Moving Picture Experts Group）方式で用いられているハフマン符号化や、JPEG2000方式で用いられているさらに高精度な算術符号化を用いることができる。
【００９７】
ここで、エントロピ符号化をどの範囲の係数に対して行うかは、圧縮効率に直接関係する非常に重要な要素になる。例えば、JPEG方式やMPEG方式では、８×８のブロックに対してDCT（Discrete Cosine Transform）変換を施し、生成された６４個のDCT変換係数に対してハフマン符号化を行うことで、情報を圧縮している。すなわち、６４個のDCT変換係数がエントロピ符号化の範囲になる。
【００９８】
ウェーブレット変換部１６１では、８×８ブロックに対するDCT変換とは異なり、ライン単位でウェーブレット変換を施しているため、エントロピ符号化部１６３では、周波数帯域（サブバンド）毎に独立に、且つ各周波数帯域内をＰライン毎に情報源符号化する。
【００９９】
Ｐは１ラインが最低であるが、ライン数が少ない場合には参照情報が少なくて済み、メモリ容量を減らすことができる。逆に、ライン数が多い場合には情報量がその分増えるため、符号化効率が向上させることができる。しかしながら、Ｐが各周波数帯域内のラインブロックのライン数を超えた値になると、次のラインブロックのラインまで必要になる。このため、このラインブロックの量子化係数データがウェーブレット変換及び量子化によって生成されるまで待たなければならず、この時間が遅延時間となってしまう。
【０１００】
したがって、低遅延のためには、Ｐはラインブロックのライン数以下である必要がある。例えば、図５の例では、１ＬＬ，１ＨＬ，１ＬＨ，１ＨＨの周波数帯域については、ラインブロックのライン数＝１ラインであるためＰ＝１となる。また、２ＨＬ，２ＬＨ，２ＨＨのサブバンドについては、ラインブロックのライン数＝２ラインであるためＰ＝１または２となる。
【０１０１】
レート制御部１２１は、最終的に目標のビットレート又は圧縮率に合わせるための制御を行い、レート制御後の符号化データをRTP部１６４に供給する。例えば、このレート制御部１２１は、ビットレートを上げる場合には量子化ステップサイズを小さくし、ビットレートを下げる場合には量子化ステップサイズを大きくするように、量子化部１６２に対して制御信号を送信する。
【０１０２】
RTP部１６４は、レート制御部１２１から供給される符号化データをRTPパケット化し、FEC部１１２に供給する。
【０１０３】
［復号部の構成例］
次に、上述した符号化部１１１の例に対応する復号部１３５の例について説明する。図６は、受信装置１０３の復号部１３５の構成例を示すブロック図である。図６において、復号部１３５は、RTP部１９０、エントロピ復号部１９１、逆量子化部１９２、およびウェーブレット逆変換部１９３を有する。
【０１０４】
RTP部１９０は、FEC部１３４から供給されるRTPパケットを符号化データに変換し、それをエントロピ復号部１９１に供給する。エントロピ復号部１９１は、エントロピ符号化部１６３の符号化方法に対応する方法で符号化データを復号し、量子化係数データを生成する。例えば、ハフマン復号や、高効率な算術復号などを用いることができる。なお、エントロピ符号化部１６３においてＰラインごとに符号化されている場合、エントロピ復号部１９１は、各サブバンドを独立に復号し、かつ、各サブバンド内をＰライン毎に復号する。
【０１０５】
逆量子化部１９２は、量子化係数データに量子化ステップサイズを乗算することにより逆量子化し、係数データを生成する。この量子化ステップサイズは、通常、送信装置１０１から供給される符号化データのヘッダなどに記述されている。なお、量子化部１６２において、ラインブロック毎に量子化ステップサイズが設定されている場合には、逆量子化部１９２においても同様に、ラインブロック毎に逆量子化ステップサイズが設定されて、逆量子化される。
【０１０６】
ウェーブレット逆変換部１９３は、ウェーブレット変換部１６１の逆処理を行う。つまり、ウェーブレット逆変換部１９３は、ウェーブレット変換部１６１により複数の周波数帯域に分割された係数データに対して、低域成分と高域成分を合成するフィルタ処理（合成フィルタ処理）を水平方向と垂直方向の両方に対して行う。ウェーブレット逆変換部１９３は、このようはウェーブレット逆変換処理により、ベースバンドのビデオデータを復元し、ビデオOUTから受信装置１０３の外部に出力する。
【０１０７】
もちろん、上述した符号化部１１１および復号部１３５は、一例であり、これ以外の符号化・復号方式を用いるようにしてもよい。
【０１０８】
［伝送処理］
次に、伝送システム１００において行われる各処理について説明する。最初に、ビデオデータを送信装置１０１からネットワーク１０２を介して受信装置１０３に伝送する伝送処理について説明する。
【０１０９】
送信装置１０１は、ビデオカメラ等を経由し、ビデオ入力IF「ビデオIN」より入力したビデオデータを、動画像データの符号化処理を行う符号化部１１１に入力し、符号化される。符号化データは、符号化部１１１内部のRTP部１６４によりRTPパケット化処理を施され出力される。出力されたRTPパケットは、FEC部１１２によりFEC冗長符号化処理を施され、RTP部１１３によりFEC冗長符号化データ用のRTPパケット化処理を施され、平滑化部１１４からRTPパケットとしてネットワーク１０２へ送信される。
【０１１０】
各RTPパケットには、メディア同期部１１６にて指定された同期用RTPタイムスタンプがセットされる。
【０１１１】
受信装置１０３は、送信装置１０１より送信されたRTPパケットを受信部１３１で受信し、受信バッファ１３２に保存する。このとき損失パケットが検出された場合、ARQ部１３６に通知され、ARQ部１３６により再送要求処理が行われる。
【０１１２】
受信バッファ１３２は、受信バッファ時間決定部１３８により決定された受信バッファ時間と、メディア同期部１４０より通知される時刻情報と、各RTPパケットにセットされたRTPタイムスタンプ値とから、受信バッファ出力時刻を決定し、所定時刻に各RTPパケットをRTP部１３３に出力する。
【０１１３】
RTP部１３３は、RTPパケットをFEC冗長符号化データへ変換する再構成処理を行い、変換したFEC冗長符号化データを、FEC部１３４へ出力する。FEC部１３４は、損失パケットの検出を行う。損失パケットが検出された場合、FEC部１３４は、冗長符号化復号処理により損失パケットデータの回復を行う。
【０１１４】
このように処理された符号化データ（RTPパケット）は、復号部１３５に供給される。復号部１３５は、供給された符号化データのRTPパケットを変換して符号化データを生成し、その符号化データに対して復号処理を行う。復号されたビデオデータは、ビデオ出力IF「ビデオOUT」より、例えば、ディスプレイ等の映像表示装置に供給され、出力される。
【０１１５】
［基準信号同期処理］
次に、送信装置１０１と受信装置１０３との間で基準信号の同期をとる基準信号同期処理について説明する。基準信号同期部１１５および基準信号同期部１３９は、互いに通信を行い、IEEE 1588 PTP（Precision Time Protocol）を用い、送信装置１０１と受信装置１０３との間の基準信号クロックの同期を行う。
【０１１６】
基準信号クロックの周波数としては、例えば、入力ビデオ画像のピクセルサンプリング周波数が用いられる。また、ビデオ出力装置から出力されるビデオデータが「ビデオIN」から入力される場合、送信装置１０１とそのビデオ出力装置との間でも、基準信号の同期がとられるようにしてもよい。
【０１１７】
なお、基準信号同期部１１５および基準信号同期部１３９による、送信装置１０１と受信装置１０３との間の基準信号の同期とりは、任意であり、装置間で基準信号の同期をとらないようにしてもよい。
【０１１８】
［メディア同期処理］
次に、基準信号に基づいてビデオデータの同期をとるメディア同期処理について説明する。送信装置１０１におけるメディア同期部１１６は、基準信号同期部１１５より通知された時刻を基に、「ビデオIN」より入力されたデータのサンプリング時刻と同期した時刻を、RTPタイムスタンプの周波数に変換し、符号化部１１１内のRTP部１６４、およびRTP部１１３にて各RTPパケットにRTPタイムスタンプとして付加する。
【０１１９】
受信装置１０３におけるメディア同期部１４０は、基準信号同期部１３９より通知された基準クロック時刻情報をRTPタイムスタンプ周波数に変換したシステム時刻として保持する。
【０１２０】
受信装置１０３における受信バッファ１３２にRTPパケットが記録されると、受信バッファ１３２は、RTPパケットのRTPタイムスタンプ値と、受信バッファ時間設定部１３８より通知された受信バッファ時間と、メディア同期部１４０から供給されるRTPタイムスタンプ周波数時刻とから、各RTPパケットの受信バッファ出力時刻を決定する。
【０１２１】
RTPパケットの受信バッファ出力時刻は、例えば、以下のように決定される。ストリームデータの先頭パケットは、受信した時刻から受信バッファ時間TSTIME_BUFが経過した時刻後に受信バッファから出力されるものとする。これに対して、後続パケットは、先頭パケットのRTPタイムスタンプ値と当該パケットのRTPタイムスタンプ値との差分値から算出される時刻に同期出力される。
【０１２２】
RTPパケットnの受信バッファ出力時刻TSSYS_BO_nは、例えば、以下の式（１）により算出される。ストリーム先頭パケットのRTPタイムスタンプ値をTSPKT_initとし、受信時刻（システム時刻換算：周波数はRTPタイムスタンプ周波数）をTSSYS_initとし、RTPパケットnのRTPタイムスタンプ値をTSPKT_nとする。
【０１２３】
TSSYS_BO_n＝（TSPKT_n−TSPKT_init）＋TSSYS_init＋TSTIME_BUF ・・・（１）
【０１２４】
［符号化処理・復号処理］
次に、送信装置１０１および受信装置１０３が行うビデオデータのコーデック処理（符号化処理および復号処理）について説明する。符号化部１１１は、例えば特許文献１において提案されている動画像の各ピクチャの数ライン毎を１つの符号化ブロックとしてウェーブレット変換を行う階層符号化方式であり、かつ、階層毎に関連する入力データ範囲の異なる符号化方式を用いる。
【０１２５】
符号化部１１１が符号化処理を行って符号化データを生成し、復号部１３５がその符号化データを復号する復号処理を行う。
【０１２６】
符号化部１１１は、上述したようにレート制御部１２１を有する。レート制御部１２１は、例えば、ITU-T Y.1221記載のトークンバケットビヘビアにおける、バケツサイズをエンコーダ想定バッファサイズＢ（byte）、バケットレートＲ（bps）をエンコードレートとして、バケットがあふれないようにエンコードレートを制御するレート制御を行う。これを平滑化伝送したときに受信装置１０３において必要となるバッファ時間を「可変圧縮符号化遅延要求時間」と称する。
【０１２７】
可変圧縮符号化遅延要求時間Bt_codec_req(sec)は、例えば、以下の式（２）のように算出される。
【０１２８】
Bt_codec_req＝Ｂ×８／Ｒ ・・・（２）
【０１２９】
エンコーダ想定バッファサイズＢは、ユーザ等により指定される画像品質要求に応じて決定される。VBR方式による圧縮符号化の場合、エンコーダ想定バッファサイズＢを大きくとることにより、複雑度の高い画像部分により多くのデータ量を使用することができ、画質を向上させることができる。つまり、画像品質要求が高い場合、このエンコーダ想定バッファサイズＢを大きくとることでその高い要求に応じることができる。
【０１３０】
ただし、エンコーダ想定バッファサイズＢを大きくとると、可変圧縮符号化遅延要求時間Bt_codec_req(sec)が大きくなるので、遅延が増加する恐れがある。
【０１３１】
［RTCP処理］
次に、送信装置１０１と受信装置１０３との間で行われるQoS制御処理のRTCP処理について説明する。RTCP部１１７およびRTCP部１３７は、IETF RFC 3550記載のRTCPを用いて、送信装置１０１と受信装置１０３との間でRTCPメッセージの送受信を行い、パケット損失率、往復伝搬遅延（RTT）、およびネットワークジッタ等の情報収集や、QoS制御処理のための制御メッセージの送受信を行う。QoS制御メッセージとしては、例えば、ARQ処理における再送要求メッセージ等がある。
【０１３２】
［FEC処理］
次に、QoS制御処理のFEC処理について説明する。FEC部１１２は、符号化部１１１から供給される符号化データのRTPパケットを単位として、FEC冗長符号化を行う。例えば、FEC部１１２は、Reed-Solomon符号等の消失誤り訂正符号を用い冗長符号化を行う。
【０１３３】
FEC冗長符号化における冗長度は、例えば、ユーザ等により指定される伝送品質要求により決定される。冗長度は、（元データパケット数，冗長パケット数）という形で指定される。ユーザは、また、ネットワークの想定パケット損失率pも指定する。
【０１３４】
以下においては、（元データパケット数，冗長パケット数）の組を１つの冗長符号単位（所謂FECブロック）とする。例えば、（元データパケット数，冗長パケット数）＝（10,5）と指定された場合、送信装置１０１のFEC部１１２は、元データパケット数10個に対して、冗長パケットを５個生成する。つまり、このFECブロックにおいては合計15個のパケットが送信される。
【０１３５】
この場合、受信装置１０３のFEC部１３４は、このFECブロックパケット中任意の10個のパケットを受信すれば、FEC復号処理により元データを復号することができる。例えば、ユーザにより指定されたパケット損失率をpとし、FECブロック内のパケット数をnとし、元データパケット数をｋとし、冗長パケット数をn-kとし、ユーザにより伝送品質要求として指定される目標FECブロック損失率をPtとすると、目標FECブロック損失率Ptは、以下の式（３）のように表される。
【０１３６】
【数１】
・・・（３）
【０１３７】
この式（３）を満たすように元データパケット数kおよび冗長パケット数n-kが決定される。
【０１３８】
受信装置１０３（FEC部１３４）では、FEC冗長復号化処理により損失パケット回復を行うために、FECブロックの先頭パケットが受信装置１０３に到着してから末尾のパケットが到着するまでの時間（所謂、冗長符号化ブロック受信待ち時間）以上に受信バッファ時間を設定する必要がある。
【０１３９】
ユーザ等により指定される伝送品質要求に応じて設定されたFECブロックに対応する冗長符号化ブロック受信待ち時間を「冗長符号化ブロック受信待ち要求時間」と称する。
【０１４０】
［ARQ処理］
受信装置１０３におけるARQ処理では、受信部１３１がRTPパケットのシーケンス番号を利用して損失したパケットを検知し、ARQ部１３６がその損失パケットの再送要求メッセージを生成し、RTCP部１３７が、送信装置１０１に対してその再送要求メッセージを送信し、再送要求を行う。
【０１４１】
なお、受信装置１０３のARQ部１３６が、パケット損失に対して再送要求を行い、往復伝搬時間（ARQ再送パケット待ち時間）経過しても受信部１３１が再送パケットを受信しなかった場合、再度、再送要求を行うようにしてもよい。さらに、ARQ部１３６が、当該パケットの受信バッファ出力時刻に再送パケット到着が間に合わないと決定されるまで、このような再送要求を繰り返すようにしてもよい。
【０１４２】
送信装置１０１におけるARQ処理では、RTCP部１１７が再送要求メッセージを受け取ると、ARQ部１１８が再送すべきRTPパケット（再送パケット）を生成し、その再送パケットを平滑化部１１４に供給し、再送させる。
【０１４３】
ARQ処理における回復性能は、受信装置１０３における、ARQ部１３６の要求により再送される再送パケットを待つ時間であるARQ再送パケット待ち時間に依存する。ARQ再送パケット待ち時間が大きいほど回復性能は向上するが、ARQ再送パケット待ち要求時間以上の受信バッファ時間が必要となるので、遅延が増大する恐れがある。
【０１４４】
この「ARQ再送パケット待ち要求時間」は、ユーザ等により指定される伝送品質要求により決定される。
【０１４５】
［ネットワークジッタ対応処理］
受信装置１０３の受信バッファ１３２は、ネットワークジッタ対応処理機構も兼ね備える。受信バッファ１３２は、ユーザ等により指定される伝送品質要求により決定された「ネットワークジッタ対応バッファ要求時間」以上の時間を受信バッファ時間としてセットする。これにより「ネットワークジッタ対応バッファ要求時間」以下のジッタを受けたパケットの同期処理が可能となる。
【０１４６】
［データ伝送全体処理］
次に、伝送システム１００において実行されるデータ伝送処理の全体の流れの例を、図７のフローチャートを参照して説明する。
【０１４７】
受信装置１０３の受信バッファ時間設定部１３８は、入力部１４１および出力部１４２を制御して、ステップＳ１２１において、画像品質要求および伝送品質要求を受け付ける。
【０１４８】
受信バッファ時間設定部１３８は、例えば、出力部１４２のモニタに、図８に示されるようなGUIを表示し、入力部１４１を制御し、そのGUIに基づいて行われるユーザ操作を受け付ける。
【０１４９】
図８は、画像品質要求および伝送品質要求等を受け付けるGUIである要求受付画面の表示例を示す図である。図８に示されるように、要求受付画面２０１には、表示部２０２と要求部２０３とが設けられている。要求部２０３は、ユーザにより入力可能な項目が示される。表示部２０２には、ユーザにより情報が入力された結果が表示される。
【０１５０】
要求部２０３には、例えば、「使用者要求」として、「画質要求」（画像品質要求）や「伝送品質要求」を入力することができることが示されている。例えば、画像品質を指定する場合、ユーザは、「画質要求」を選択し、要求する品質（例えばPSR値等）を入力する。また、例えば、伝送品質を指定する場合、ユーザは、「伝送品質要求」を選択し、要求する品質（例えばQoS制御後パケット損失率等）を入力する。
【０１５１】
なお、要求部２０３においては、ユーザは、受信バッファ時間を指定することもできる。例えば、ユーザが、「受信バッファ時間」を選択し、要求する時間を入力することにより、「受信バッファ時間」として許容される最長の時間が設定される。
【０１５２】
表示部２０２には、このように要求部２０３において入力された情報が反映された各種情報が表示される。
【０１５３】
例えば、表示部２０２には、「ネットワーク状況」として「伝送遅延」、「パケット損失率」、および「ネットワークジッタ」等が表示される。
【０１５４】
また、例えば、表示部２０２には、「処理要求時間」として「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等が表示される。
【０１５５】
さらに、例えば、表示部２０２には、受信バッファ時間として推奨される「推奨受信バッファ時間」が表示される。
【０１５６】
このようなGUIに基づいて要求を入力することにより、ユーザは、画像品質要求、伝送品質要求、および受信バッファ時間等をより容易に設定することができる。
【０１５７】
図７に戻り、画像品質要求や伝送品質要求が受け付けられると、受信バッファ時間設定部１３８は、ステップＳ１２２において受信バッファ時間決定処理を行い、ARQ部１３６や受信バッファ１３２の設定を行ったり、RTCP部１３７を介して、決定した情報等を送信装置１０１に通知したりする。
【０１５８】
送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７を介してこの通知を受け取ると、ステップＳ１０１において、その通知に基づいて受信バッファ時間・処理パラメータ設定処理を行い、符号化部１１１やFEC部１１２の設定を行う。
【０１５９】
設定が終了すると、送信装置１０１の各部は、ステップＳ１０２において、受信装置１０３と連携してデータ伝送（データ送信）を行う。この処理に対応して、受信装置１０３の各部は、ステップＳ１２３において、送信装置１０１と連携してデータ伝送（データ受信）を行う。
【０１６０】
これらのデータ伝送においては、上述した各種処理が適宜行われる。
【０１６１】
以上のように、送信装置１０１および受信装置１０３は、互いに連携し、ユーザ等により指定される画像品質要求や伝送品質要求に応じて、各部の設定を行う。これにより、送信装置１０１および受信装置１０３は、各処理の遅延時間を最適化し、各処理の時間的余裕を画質や伝送品質の向上に利用し、遅延時間上の無駄を低減させることができる。つまり、コンテンツの品質の劣化を抑制することができる。
【０１６２】
［受信バッファ時間決定処理］
次に、図７のステップＳ１２２において実行される受信バッファ時間決定処理の流れの例を図９のフローチャートを参照して説明する。
【０１６３】
受信バッファ時間決定処理が開始されると、受信バッファ時間設定部１３８は、ステップＳ１４１において、ユーザ等からの画像品質要求や伝送品質要求に基づいて、各種遅延時間や待ち時間等を設定する。
【０１６４】
例えば、受信バッファ時間設定部１３８は、画像品質要求や伝送品質要求の設定値から、「可変圧縮符号化遅延時間」として要求される時間である「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち時間」として要求される時間である「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち時間」として要求される時間である「ARQ再送パケット待ち要求時間」、および、「ネットワークジッタ対応バッファ時間」として要求される時間である「ネットワークジッタ対応バッファ要求時間」を計算する。
【０１６５】
従来の方法の場合、これらの値がそのまま設定値として使用されていたが、受信バッファ時間設定部１３８は、これらの値を、その最大値に揃えるように再設定する。受信バッファ時間設定部１３８は、ステップＳ１４２において、以下の式（４）に示されるように、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を「受信バッファ時間」として設定する。
【０１６６】
「受信バッファ時間」＝MAX（「可変圧縮符号化遅延要求時間」，「冗長符号化ブロック受信待ち要求時間」，「ARQ再送パケット待ち要求時間」，「ネットワークジッタ対応バッファ要求時間」）
・・・（４）
【０１６７】
式（４）において、MAX（）は、最大値を計算する関数である。
【０１６８】
「受信バッファ時間」を算出すると、受信バッファ時間設定部１３８は、ステップＳ１４３において、以下の式（５）に示されるように、その「受信バッファ時間」を、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」として設定する。
【０１６９】
「可変圧縮符号化遅延時間」＝「冗長符号化ブロック受信待ち時間」＝「ARQ再送パケット待ち時間」＝「ネットワークジッタ対応バッファ時間」＝「受信バッファ時間」
・・・（５）
【０１７０】
例えば、可変圧縮符号化遅延要求時間２２１、冗長符号化ブロック受信待ち要求時間２２２、ARQ再送パケット待ち要求時間２２３、および、ネットワークジッタ対応バッファ要求時間２２４が、図１０の左に示されるような長さであるとする。
【０１７１】
この場合、可変圧縮符号化遅延要求時間２２１が最も長いので、図１０右に示されるように、受信バッファ時間２４１は、この可変圧縮符号化遅延要求時間２２１と同じ長さに設定される。可変圧縮符号化遅延時間２３１、冗長符号化ブロック受信待ち時間２３２、ARQ再送パケット待ち時間２３３、および、ネットワークジッタ対応バッファ時間２３４は、それぞれ、この受信バッファ時間２４１に揃えられる。
【０１７２】
つまり、この場合、冗長符号化ブロック受信待ち時間２３２、ARQ再送パケット待ち時間２３３、および、ネットワークジッタ対応バッファ時間２３４は、それぞれ、要求された時間よりも長くなるように設定される。
【０１７３】
図９に戻り、以上のように、各時間が設定されると、受信バッファ時間設定部１３８は、ステップＳ１４４において、「ARQ再送パケット待ち時間」を、ARQ部１３６に設定し、再送要求を行うかどうかの判定に使用させる。
【０１７４】
また、ステップＳ１４５において、受信バッファ時間設定部１３８は、「ネットワークジッタ対応バッファ時間」を受信バッファ１３２に設定する。
【０１７５】
さらに、ステップＳ１４６において、受信バッファ時間設定部１３８は、「画像品質要求」、「伝送品質要求」、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック待ち時間」を、例えば、RTCP部１３７を介して、RTCPメッセージとして送信装置１０１へ通知する。
【０１７６】
通知が終了すると、受信バッファ時間設定部１３８は、受信バッファ時間決定処理を終了し、処理を図７のステップＳ１０２に戻し、ステップＳ１０３に処理を進める。
【０１７７】
［受信バッファ時間・処理パラメータ設定処理］
次に、図１１のフローチャートを参照して、図７のステップＳ１０１において実行される受信バッファ時間・処理パラメータ設定処理を説明する。
【０１７８】
受信バッファ時間・処理パラメータ設定処理が開始されると、受信バッファ時間・処理パラメータ設定部１１９は、ステップＳ１６１において、RTCP部１１７を介して、受信装置１０３から供給されるRTCPメッセージに含まれる「画像品質要求」、「伝送品質要求」、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック待ち時間」を取得する。
【０１７９】
ステップＳ１６２において、受信バッファ時間・処理パラメータ設定部１１９は、「可変圧縮符号化遅延時間」を符号化部１１１に設定する。ステップＳ１６３において、受信バッファ時間・処理パラメータ設定部１１９は、「冗長符号化ブロック待ち時間」をFEC部１１２に設定する。
【０１８０】
レート制御部１２１は、ステップＳ１６４において、供給された「画像品質要求」や「可変圧縮符号化遅延時間」を用いて、レート制御パラメータを設定する。例えば、レート制御部１２１は、以下の式（６）を満たすように、エンコーダ想定バッファサイズＢ(byte)を設定する。なお、式（６）において、Bt_codec(sec)は可変圧縮符号化遅延時間を示す。また、Ｒ（bps）はパケットレートを示す。
【０１８１】
Bt_codec＝Ｂ×８／Ｒ ・・・（６）
【０１８２】
FEC部１１２は、ステップＳ１６５において、「伝送品質要求」および「冗長符号化ブロック受信待ち時間」を用いてFECブロックパラメータを設定する。「冗長符号化ブロック待ち時間」は、FECブロックに含まれるパケット全ての平滑化伝送にかかる時間の最大値である。FEC部１１２は、この時間が「冗長符号化ブロック待ち時間」以下となるように、FECブロック毎の元データパケット数を調整する。さらに、FEC部１１２は、例えば、上述した式（３）を満たすように、冗長パケット数ｎ−ｋを設定する。
【０１８３】
ステップＳ１６５の処理が終了すると、受信バッファ時間・処理パラメータ設定部１１９は、受信バッファ時間・処理パラメータ設定処理を終了し、処理を図７のステップＳ１０１に戻し、ステップＳ１０２の処理を行う。
【０１８４】
以上のように各種設定を行うことにより、送信装置１０１および受信装置１０３は、遅延を増大させない程度に、各遅延時間や待ち時間をできるだけ長く確保することができ、その時間的余裕を、画像品質や伝送品質の向上に利用することができる。
【０１８５】
より具体的には、送信装置１０１は、遅延を増大させない程度に、符号化部１１１の「可変圧縮符号化遅延時間」をより長く設定し、エンコーダ想定バッファサイズＢ(byte)をより大きく設定することができる。また、送信装置１０１は、遅延を増大させない程度に、FEC部１１２の「冗長符号化ブロック待ち時間」をより長く設定し、FECブロックや冗長度をより大きく設定することができる。
【０１８６】
受信装置１０３は、遅延を増大させない程度に、ARQ部１３６の「ARQ再送パケット待ち時間」をより長く設定することができる。また、受信装置１０３は、遅延を増大させない程度に、受信バッファ１３２の「ネットワークジッタ対応バッファ時間」をより長く設定することができる。
【０１８７】
以上のように、送信装置１０１および受信装置１０３は、各処理の時間的余裕を活用し、画質や伝送品質の向上に利用することにより、遅延時間上の無駄を低減させることができる。つまり、送信装置１０１および受信装置１０３は、上述したようなデータ伝送に関する各種処理によるコンテンツの品質の劣化を抑制することができる。
【０１８８】
＜２．第２の実施の形態＞
［データ伝送全体処理の他の例］
以上においては、ユーザ等の要求のみにより受信バッファ時間や処理パラメータが決定されるように説明したが、これに限らず、ネットワーク１０２の通信に関する状況に応じて受信バッファ時間や処理パラメータの設定が行われるようにしてもよい。
【０１８９】
その場合、ネットワーク１０２の通信に関する状況（ネットワーク状況情報）は、RTCP部１１７とRTCP部１３７との間で行われるパケットの授受によって観測される。したがって、送信装置１０１と受信装置１０３の構成は、上述した第１の実施の形態（図１）の場合と同様である。
【０１９０】
さらに、このようなネットワーク状況情報の測定を、データ伝送中に繰り返し行い、その最新のネットワーク状況に応じて、受信バッファ時間や処理パラメータの設定が更新されるようにしてもよい。
【０１９１】
この場合も、RTCP部１１７およびRTCP部１３７は、上述した第１の実施の形態において説明した場合と基本的に同様の処理を行う。ただし、この場合、RTCP部１１７は、符号化データの伝送を開始する前に、ネットワーク状況事前計測用のダミーデータを送信する。そのダミーデータは、ネットワーク１０２を介してRTCP部１３７に伝送される。RTCP部１３７は、そのダミーデータを受信し、パケットに記述される送信時の情報と、受信時の状況からネットワーク状況の計測（事前計測）を行う。
【０１９２】
符号化データの伝送開始後においては、RTCP部１３７は、伝送される符号化データのRTPパケットによりネットワーク状況情報の計測を行う。
【０１９３】
この場合のデータ伝送処理の流れの例を図１２のフローチャートを参照して説明する。受信装置１０３の受信バッファ時間設定部１３８が、ステップＳ２２１において、図７のステップＳ１２１の場合と同様に、画像品質要求および伝送品質要求を受け付けると、RTCP部１３７は、ステップＳ２２２において、RTCP部１１７とダミーデータ等の各種データの授受を行い、ネットワーク状況を測定し、そのネットワーク状況情報をRTCP部１１７と共有する。送信装置１０１のRTCP部１１７は、ステップＳ２０１において、このステップＳ２２２の処理に対応する処理を行う。
【０１９４】
ネットワーク状況を測定すると受信装置１０３の受信バッファ時間設定部１３８は、受信バッファ時間決定処理を行う。この処理は、基本的に図９のフローチャートを参照して説明した場合と同様に行われる。
【０１９５】
ただし、受信バッファ時間設定部１３８は、ステップＳ１４１において、画像品質要求と伝送品質要求だけでなく、ステップＳ２２２においてRTCP部１３７より取得したネットワーク状況情報にも基づいて、各種要求時間を算出する。
【０１９６】
例えば、パケット損失率が高い場合、「ARQ再送パケット待ち要求時間」は、回復性能を向上させるような値に設定される。また、例えば、パケット損失率が高い場合、「冗長符号化ブロック受信待ち要求時間」は、式（３）を満たし、指定された冗長度以下に保つ元データパケット数および冗長パケット数に合わせた値に設定される。
【０１９７】
また、「ネットワークジッタ対応バッファ要求時間」は、実際に測定されたネットワークジッタ以上の値に設定される。
【０１９８】
このように設定された要求時間に応じて、各種遅延時間や待機時間等が設定される。送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、ステップＳ２０２において、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、基本的に図１１のフローチャートを参照して説明した場合と同様に行われる。
【０１９９】
つまり、受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７により取得されたネットワーク状況情報も利用して冗長度やFECブロックサイズを決定する。符号化データの伝送開始前において、受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７により計測されたネットワーク状況事前計測情報に含まれるパケット損失率pを用い、式（３）を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
【０２００】
各種パラメータの設定が終了すると、受信装置１０３の各部は、ステップＳ２２４において、受信バッファ時間等各種設定を動的に更新しながらデータ伝送を行う受信バッファ動的変更伝送処理を行う。この処理に対応して、送信装置１０１の各部は、ステップＳ２０３において、受信バッファ動的変更伝送処理を行う。
【０２０１】
［受信バッファ動的変更伝送処理］
図１３のフローチャートを参照して、送信装置１０１および受信装置１０３により行われる受信バッファ動的変更伝送処理の流れの例を説明する。
【０２０２】
ステップＳ２４１において、送信装置１０１の各部は、一定時間データ転送を行う。この処理に対応して、受信装置１０３の各部は、ステップＳ２６１において、一定時間データ転送を行う。
【０２０３】
受信装置１０３のRTCP部１３７は、ステップＳ２６２において、RTCP部１１７とデータの送受信を行い、ネットワーク状況を測定し、ネットワーク状況情報を更新する。この処理に対応して、送信装置１０１のRTCP部１１７は、ステップＳ２４２において、ネットワーク状況を測定し、ネットワーク状況情報を更新する。
【０２０４】
ステップＳ２６３において、受信装置１０３の受信バッファ時間設定部１３８は、更新されたネットワーク状況情報に基づいて、受信バッファ時間決定処理を行い、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等を更新し、その更新された各種要求時間に応じて、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」等の設定を、例えば式（４）や式（５）を用いて更新する。
【０２０５】
この受信バッファ時間決定処理は、図１２のステップＳ２２３の場合と同様に行われる。
【０２０６】
この処理に対応し、ステップＳ２４３において、送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、図１２のステップＳ２０２の場合と同様に行われる。
【０２０７】
符号化データの伝送開始後の場合、受信バッファ時間・処理パラメータ設定部１１９は、符号化データ伝送を利用してRTCP部１１７により計測されたネットワーク状況情報に含まれるパケット損失率pを用い、式（３）を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
【０２０８】
ステップＳ２４４において、送信装置１０１は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップＳ２４１に戻し、それ以降の処理を実行させる。また、ステップＳ２４４において、伝送を終了すると判定された場合、送信装置１０１による受信バッファ動的変更伝送処理が終了される。
【０２０９】
また、ステップＳ２６４において、受信装置１０３は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップＳ２６１に戻し、それ以降の処理を実行させる。また、ステップＳ２６４において、伝送を終了すると判定された場合、受信装置１０３による受信バッファ動的変更伝送処理が終了される。
【０２１０】
以上のように、ユーザ等からの要求だけでなく、ネットワーク状況にも応じて、パラメータ等の設定を行うようにすることにより、送信装置１０１および受信装置１０３は、より実際の状況に応じてより効率よく画質や伝送品質の設定を行うことができ、遅延時間上の無駄をより低減させることができる。つまり、送信装置１０１および受信装置１０３は、コンテンツの品質の劣化を抑制することができる。
【０２１１】
＜３．第３の実施の形態＞
［伝送システムの構成］
以上においては、送信装置と受信装置が１対１に構成されるシステムについて説明したが、これに限らず、伝送システムを構成する送信装置と受信装置の数は任意である。例えば、複数の送信装置から送信される符号化データを１つの受信装置が受信するようにしてもよい。
【０２１２】
図１４は、その場合の伝送システムの構成例を示す図である。図１４に示される伝送システム３００は、基本的に伝送システム１００と同様のシステムであるが、伝送システム１００の場合と異なり、送信装置を複数有する（送信装置１０１−１乃至送信装置１０１−Ｎ（Ｎは２以上の整数））。
【０２１３】
送信装置１０１−１乃至送信装置１０１−Ｎは、それぞれ、上述した送信装置１０１と同様の構成を有し、同様の処理を行う。送信装置１０１−１乃至送信装置１０１−Ｎを互いに区別して説明する必要が無い場合、単に送信装置１０１と称する。
【０２１４】
伝送システム３００は、受信装置１０３の代わりに、各送信装置１０１から送信されるRTPパケットを受信する１つの受信装置３０３を有する。
【０２１５】
図１４に示されるように、受信装置３０３は、伝送部３１１、基準信号同期部３１２、受信部３１３−１乃至受信部３１３−Ｎ、統合受信バッファ時間調整部３１４、および合成部３１５を有する。
【０２１６】
伝送部３１１は、各送信装置１０１と通信を行い、基準信号同期部３１２や受信部３１３−１乃至受信部３１３−Ｎから供給される情報を送信したり、各送信装置１０１から供給される情報を受信し、基準信号同期部３１２や受信部３１３−１乃至受信部３１３−Ｎに供給したりする。
【０２１７】
基準信号同期部３１２は、送信装置１０１の基準信号同期部１１５と通信を行い、基準信号の同期をとる。同期がとられた基準信号は、受信部３１３−１乃至受信部３１３−Ｎに供給される。
【０２１８】
このように、送信装置１０１が複数存在する場合、例えば、受信装置３０３の基準信号同期部３１２がマスタとなり、全ての送信装置１０１が受信装置３０３と同期を取ることにより結果的に全ての送信装置１０１および受信装置３０３の同期を取ることができる。
【０２１９】
受信部３１３−１乃至受信部３１３−Ｎは、それぞれ、送信装置１０１−１乃至送信装置１０１−Ｎに対応し、対応する送信装置１０１から供給されたRTPパケットを受信し、復号してビデオデータを出力する。以下において、受信部３１３−１乃至受信部３１３−Ｎを互いに区別して説明する必要が無い場合、単に、受信部３１３と称する。つまり、受信部３１３は、送信装置１０１以上の数が予め用意される。換言するに、受信装置３０３は、内蔵する受信部３１３の数以下の送信装置１０１から送信されるパケットを受信することができる。
【０２２０】
統合受信バッファ時間調整部３１４は、各受信部３１３の受信バッファ時間を揃える。合成部３１５は、各受信部３１３から出力されるビデオデータを合成し、合成されたビデオデータを、受信装置３０３のビデオ出力端子「ビデオOUT」から出力する。
【０２２１】
［受信部］
図１５は、受信部３１３の主な構成例を示すブロック図である。図１５に示されるように、受信部３１３は、上述した受信装置１０３と基本的に同様の構成を有する。ただし、受信部３１３は、受信装置１０３が有する基準信号同期部１３９を有さない。また、受信部３１３は、受信装置１０３が有する受信バッファ時間設定部１３８の代わりに、受信バッファ時間設定部３３８を有する。
【０２２２】
メディア同期部１４０は、受信部３１３の外部の基準信号同期部３１２より供給される基準信号、すなわち、各送信装置１０１と各受信部３１３において同期がとれた基準信号を用いて、受信バッファ１３２や復号部１３５におけるRTPパケットの処理タイミングを制御する。
【０２２３】
受信バッファ時間設定部３３８は、受信バッファ時間設定部１３８と同様に、ユーザ等により設定された画像品質要求や伝送品質要求、並びに、RTCP部１３７により収集されたネットワーク状況情報等に基づいて、各種時間やパラメータ等の設定を行う。
【０２２４】
なお、受信バッファ時間設定部３３８が設定した各種時間は、後述するように、統合受信バッファ時間調整部３１４により、受信部３１３間で調整される。
【０２２５】
また、入力部１４１および出力部１４２は、各受信部３１３で共有するようにしてもよい。例えば、ユーザが、どの受信部３１３に対して画像品質要求や伝送品質要求を入力する場合であっても、同じ入力部１４１および出力部１４２を用いるようにするようにしてもよい。画像品質要求や伝送品質要求の設定対象とする受信部３１３の切り替え制御方法は任意である。例えばGUIにそのような切り替えボタンを設けるようにしてもよい。また、ユーザが、複数の受信部３１３に対して、画像品質要求や伝送品質要求の設定を一度に行うことができるようにしてもよい。
【０２２６】
［データ伝送全体処理］
図１６のフローチャートを参照して、この場合のデータ伝送処理の流れの例を説明する。
【０２２７】
ステップＳ３２１において、受信装置３０３の各受信部３１３の受信バッファ時間設定部３３８は、画像品質要求や伝送品質要求を受け付ける。ステップＳ３２２において、受信装置３０３の各受信部３１３のRTCP部１３７は、それぞれ、自分自身が対応する送信装置１０１のRTCP部１１７と通信を行い、ネットワーク状況を測定し、ネットワーク状況情報を生成する。
【０２２８】
この処理に対応して、各送信装置１０１のRTCP部１１７は、ネットワーク状況の測定を行い、ネットワーク状況情報を取得する。
【０２２９】
これらの情報を基に、ステップＳ３２３において、受信装置３０３の各受信部３１３の受信バッファ時間設定部３３８は、受信バッファ時間の仮設定を行う仮受信バッファ時間決定処理を行う。
【０２３０】
各受信部３１３において仮受信バッファ時間が決定されると、ステップＳ３２４において、統合受信バッファ時間調整部３１４と各受信部３１３の受信バッファ時間設定部３３８は、連携して、統合受信バッファ時間決定処理を行い、各仮受信バッファ時間を調整した受信バッファ時間を設定する。
【０２３１】
ステップＳ３２５において、伝送部３１１は、以上の処理により得られた各種情報（例えば、画像品質要求、伝送品質要求、可変圧縮符号化遅延時間、および冗長符号化ブロック受信待ち時間等）を、各送信装置１０１に通知する。各送信装置１０１は、ステップＳ３０２において、この通知を取得し、受信バッファ時間・処理パラメータ設定処理を行う。
【０２３２】
各送信装置１０１および受信装置３０３は、ステップＳ３０３およびステップＳ３２６において、受信バッファ動的変更処理を行い、最新のネットワーク状況を測定し、その状況に基づいて各種設定を更新しながらデータ伝送を行う。
【０２３３】
なお、以上においては、受信バッファ時間を、画像品質要求、伝送品質要求、およびネットワーク状況に基づいて設定するように説明したが、これに限らず、第１の実施の形態のように、画像品質要求と伝送品質要求のみに基づいて受信バッファ時間を設定するようにしてもよい。その場合、ステップＳ３２２やステップＳ３０１の処理が省略される。
【０２３４】
［仮受信バッファ時間決定処理］
次に、図１７のフローチャートを参照して、仮受信バッファ時間決定処理の流れの例を説明する。
【０２３５】
ステップＳ３４１において、受信装置３０３は、送信装置１０１と対応し、データ伝送に使用する受信部３１３の内、未処理のものの中から、処理対象とする受信部３１３を選択する。その処理対象の受信部３１３の受信バッファ時間設定部３３８は、ステップＳ３４２において、画像品質要求、伝送品質要求、およびネットワーク状況情報等に基づいて、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」を算出する。
【０２３６】
また、受信バッファ時間設定部３３８は、ステップＳ３４３において、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を仮受信バッファ時間として設定する。
【０２３７】
ステップＳ３４４において、受信装置３０３は、全ての受信部３１３に対して処理を行ったか否かを判定し、未処理の受信部３１３が存在すると判定した場合、処理をステップＳ３４１に戻し、新たな受信部３１３を処理対象として選択し、それ以降の処理を繰り返す。
【０２３８】
また、ステップＳ３４４において、データ伝送に用いる全ての受信部３１３を処理したと判定された場合、受信装置３０３は、仮受信バッファ時間決定処理を終了し、処理を図１６のステップＳ３２３に戻し、ステップＳ３２４の処理を行う。
【０２３９】
［統合受信バッファ時間決定処理］
次に、図１６のステップＳ３２４において実行される統合受信バッファ時間決定処理の流れの例を、図１８のフローチャートを参照して説明する。
【０２４０】
ステップＳ３６１において、統合受信バッファ時間調整部３１４は、各受信部３１３において設定された仮受信バッファ時間を取得し、以下の式（７）に示されるように、各受信部３１３について、仮受信バッファ時間と伝送遅延の和を求め、その和の最大値を統合受信バッファ時間に設定する。
【０２４１】
統合受信バッファ時間＝MAX（仮受信バッファ時間１＋伝送遅延時間１，仮受信バッファ時間２＋伝送遅延時間２，・・・，仮受信バッファ時間N＋伝送遅延時間N）
・・・（７）
【０２４２】
例えば、図１９の上部に示されるように、送信装置１０１において行われる処理による遅延時間を送信装置処理遅延３５１とし、ネットワーク１０２を介したデータ伝送による遅延時間を伝送遅延３５２とし、受信装置３０３に設定される仮の受信バッファ時間を仮受信バッファ時間３５３とする。
【０２４３】
図１９の上部に示されるように、送信装置１０１−１の送信装置処理遅延３５１を送信装置処理遅延３５１−１とし、送信装置１０１−１の伝送遅延３５２を伝送遅延３５２−１とし、送信装置１０１−１の仮受信バッファ時間３５３を仮受信バッファ時間３５３−１とする。
【０２４４】
また、送信装置１０１−２の送信装置処理遅延３５１を送信装置処理遅延３５１−２とし、送信装置１０１−２の伝送遅延３５２を伝送遅延３５２−２とし、送信装置１０１−２の仮受信バッファ時間３５３を仮受信バッファ時間３５３−２とする。
【０２４５】
以下、各送信装置１０１に対して同様にして、送信装置１０１−Ｎの送信装置処理遅延３５１を送信装置処理遅延３５１−Ｎとし、送信装置１０１−Ｎの伝送遅延３５２を伝送遅延３５２−Ｎとし、送信装置１０１−Ｎの仮受信バッファ時間３５３を仮受信バッファ時間３５３−Ｎとする。
【０２４６】
なお、説明の便宜上、送信装置処理遅延３５１−１乃至送信装置処理遅延３５１−Ｎは、互いに同じ長さとする。
【０２４７】
この場合、仮受信バッファ時間と伝送遅延の和は、送信装置１０１−１のものが最大であるので、その和が統合受信バッファ時間に設定される。
【０２４８】
図１８に戻り、ステップＳ３６２において、統合受信バッファ時間調整部３１４は、いずれかの送信装置１０１に対応し、データ伝送に用いる受信部３１３の内、未処理のものの中から、処理対象とする受信部３１３を選択する。
【０２４９】
ステップＳ３６３において、その処理対象に選択された受信部３１３の受信バッファ時間設定部３３８は、以下の式（８）に示されるように、ステップＳ３６１において設定された統合受信バッファ時間と伝送遅延との差を受信バッファ時間に設定する。
【０２５０】
受信バッファ時間Ｋ＝統合受信バッファ時間−伝送遅延Ｋ ・・・（８）
【０２５１】
図１９の例の場合、送信装置１０１−１の伝送遅延３５２−１と仮受信バッファ時間３５３−１の和が最大であるので、式（７）および式（８）により、送信装置１０１−１の受信バッファ時間３５４−１は、図１９の下段に示されるように、仮受信バッファ時間３５３−１と同一に設定される。
【０２５２】
送信装置１０１−２の受信バッファ時間３５４−２、・・・、送信装置１０１−Ｎの受信バッファ時間３５４−Ｎも、それぞれ、同様に算出される。その結果、図１９の下段に示されるように、各送信装置１０１の送信装置処理遅延３５１、伝送遅延３５２、および受信バッファ時間３５４の和は、互いに同一となる。
【０２５３】
つまり、各送信装置１０１の受信バッファ時間３５４は、遅延が増大しない程度に、より長くなるように設定される。
【０２５４】
図１８に戻り、ステップＳ３６４において、処理対象の受信部３１３の受信バッファ時間設定部３３８は、式（５）のように、ステップＳ３６３において設定した受信バッファ時間を、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、およびネットワークジッタ対応バッファ時間として設定する。
【０２５５】
これにより、各遅延時間や待ち時間が、遅延が増大しない程度に、より長くなるように設定される。
【０２５６】
ステップＳ３６５において、受信バッファ時間設定部３３８は、ARQ部１３６に、ARQ再送パケット待ち時間を設定する。ステップＳ３６６において、受信バッファ時間設定部３３８は、受信バッファ１３２にネットワークジッタ対応バッファ時間を設定する。
【０２５７】
ステップＳ３６７において、受信装置３０３は、データ伝送に用いられる全ての受信部３１３に対して処理を行ったか否かを判定し、未処理の受信部３１３が存在すると判定された場合、処理をステップＳ３６２に戻し、新たな未処理の受信部３１３を選択し、その受信部３１３について、それ以降の処理を繰り返す。
【０２５８】
また、ステップＳ３６７において、全ての受信部３１３に対して処理を行ったと判定された場合、受信装置３０３は、統合受信バッファ時間決定処理を終了し、処理を図１６のステップＳ３２４に戻し、ステップＳ３２５以降の処理を実行する。
【０２５９】
なお、図１６のステップＳ３０２において実行される各送信装置１０１による受信バッファ時間・処理パラメータ設定処理は、図１１のフローチャートを参照して説明した場合と同様に行われる。
【０２６０】
［受信バッファ動的変更伝送処理］
次に、図１６のステップＳ３０３およびステップＳ３２６において実行される受信バッファ動的変更伝送処理の流れの例を図２０のフローチャートを参照して説明する。
【０２６１】
なお、この受信バッファ動的変更伝送処理は、各送信装置１０１と、それに対応する受信部３１３との間で行われる。
【０２６２】
この場合も基本的に図１３を参照して説明した場合と同様に行われるが、図１３の例の場合、受信装置１０３がステップＳ２６３において受信バッファ時間決定処理を行うのに対し、図２０の例の場合、受信装置３０３（受信部３１３）は、ステップＳ４０３において仮受信バッファ時間決定処理を行い、ステップＳ４０４において統合受信バッファ時間決定処理を行い、ステップＳ４０５において、以上の処理により得られた各種情報（例えば、画像品質要求、伝送品質要求、可変圧縮符号化遅延時間、および冗長符号化ブロック受信待ち時間等）を、対応する送信装置１０１に通知する。
【０２６３】
つまり、図１６のステップＳ３２３乃至ステップＳ３２５の処理、すなわち、データ伝送を開始する前と同様の処理が行われる。
【０２６４】
このようにして、送信装置１０１および受信装置３０３は、第２の実施の形態の場合と同様に、最新のネットワーク状況に基づいて各種設定を更新することにより、各処理の時間的余裕を画質や伝送品質の向上により有効に利用することができるようにし、遅延時間上の無駄をより低減させることができる。つまり、コンテンツの品質の劣化をより抑制することができる。
【０２６５】
なお、ユーザ等からの要求のみに基づいて各種設定を行う場合、この受信バッファ動的変更伝送処理は省略される。
【０２６６】
以上のように、伝送システム１００および伝送システム３００は、データ伝送に関する各処理に対して、受信装置において設定される遅延時間や待機時間を、その最大値に揃えることにより、遅延時間を増大させない程度に各処理に時間的余裕を設け、その時間的余裕を使って画質や伝送品質を向上させるように、各処理のパラメータの設定を行う。
【０２６７】
このようにすることにより、伝送システム１００および伝送システム３００は、コンテンツの品質の劣化を抑制することができる。
【０２６８】
例えば、ユーザ等による画質要求、伝送品質要求、およびネットワーク状況等により決定される受信バッファ時間を有効に活用し、遅延時間を増加させることなく、映像画質や伝送品質を最大限向上させることができる。
【０２６９】
また、可変圧縮符号化遅延時間が処理遅延時間中最大値であり、この値を受信バッファ時間として設定した場合、冗長符号化処理において冗長符号化ブロックを大きく取り、冗長符号化ブロック受信待ち時間を受信バッファ時間と同等まで大きくすることにより、遅延時間を増加させずにバースト損失耐性を向上させることが可能となる。
【０２７０】
さらに、ARQ再送パケット待ち要求時間、ネットワークジッタ対応バッファ要求時間も同様に大きくすることにより、それぞれ、損失回復性能の向上やネットワークジッタ許容値の向上を行うことができる。
【０２７１】
また、冗長符号化ブロック受信待ち時間が処理遅延時間中最大であった場合、可変圧縮符号化遅延時間を受信バッファ時間と同等大きく設定することにより、遅延時間を増加させずに画質を向上させる事ができる。
【０２７２】
複数の送信装置からの伝送を受信装置において同期処理する場合、複数の符号化データの同期処理が可能となるように、受信バッファ時間の調整を行い、調整後の受信バッファ時間に合わせて実際の圧縮符号化・復号処理時間やQoS制御処理時間を受信バッファ時間と同一値以下となるように処理パラメータを調整することにより、複数符号化データの同期処理のために設定した使用者の画質要求、伝送品質要求、およびネットワーク状況等から指定される以上に設定された受信バッファ時間を有効に活用し、遅延時間を増加させることなく、映像画質や伝送品質を最大限向上させることができる。
【０２７３】
なお、以上においては、伝送するビデオデータを符号化するように説明したが、これに限らず、非圧縮のまま伝送するようにしてもよい。
【０２７４】
＜４．第４の実施の形態＞
［パーソナルコンピュータ］
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、図２１に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
【０２７５】
図２１において、パーソナルコンピュータ４００のCPU（Central Processing Unit）４０１は、ROM（Read Only Memory）４０２に記憶されているプログラム、または記憶部４１３からRAM（Random Access Memory）４０３にロードされたプログラムに従って各種の処理を実行する。RAM４０３にはまた、CPU４０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２７６】
CPU４０１、ROM４０２、およびRAM４０３は、バス４０４を介して相互に接続されている。このバス４０４にはまた、入出力インタフェース４１０も接続されている。
【０２７７】
入出力インタフェース４１０には、キーボード、マウスなどよりなる入力部４１１、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部４１２、ハードディスクなどより構成される記憶部４１３、モデムなどより構成される通信部４１４が接続されている。通信部４１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０２７８】
入出力インタフェース４１０にはまた、必要に応じてドライブ４１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア４２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部４１３にインストールされる。
【０２７９】
上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０２８０】
この記録媒体は、例えば、図２１に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、若しくは半導体メモリなどよりなるリムーバブルメディア４２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM４０２や、記憶部４１３に含まれるハードディスクなどで構成される。
【０２８１】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０２８２】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２８３】
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。
【０２８４】
また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０２８５】
１００ 伝送システム， １０１ 送信装置， １０２ ネットワーク， １０３ 受信装置， １１１ 符号化部， １１２ FEC部， １１３ RTP部， １１４ 平滑化部， １１５ 基準信号同期部， １１６ メディア同期部， １１７ RTCP部， １１８ ARQ部， １１９ 受信バッファ時間・処理パラメータ設定部， １２１ レート制御部， １３１ 受信部， １３２ 受信バッファ， １３３ RTP部， １３４ FEC部， １３５ 復号部， １３６ ARQ部， １３７ RTCP部， １３８ 受信バッファ時間設定部， １３９ 基準信号同期部， １４０ メディア同期部， １４１ 入力部， １４２ 出力部， ３００ 伝送システム， ３０３ 受信装置， ３１１ 伝送路， ３１２ 基準信号同期部， ３１３ 受信部， ３１４ 統合受信バッファ時間調整部， ３１５ 合成部， ３３８ 受信バッファ時間設定部
【技術分野】
【０００１】
本発明は、情報処理装置および方法、並びにプログラムに関し、特に、コンテンツの品質の劣化を抑制することができるようにした情報処理装置および方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、インターネット、LAN（Local Area Network）、若しくは、その他の伝送路を経由して、メディア基準信号同期（所謂GENLOCK同期）を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
【０００３】
例えば、放送局においてカメラとそのコントロールユニット（所謂CCU（Camera Control Unit）とを、HD-SDI（High Definition Serial Digital Interface）ケーブルにより接続し、非圧縮同期伝送を行うシステムが存在する。近年、このシステムのHD-SDIケーブルをEthernet（登録商標）ケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
【０００４】
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手が要求されるため、例えば、高精度のGENLOCK同期とビデオフレーム間隔以下の低遅延伝送が要求される。
【０００５】
このような要求から動画像の各ピクチャの数ライン毎を１つの符号化ブロック（ラインブロック）としてウェーブレット変換による符号化を行う方式が提案されている（例えば特許文献１参照）。
【０００６】
この方式では、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。そのため、生成した符号化データをネットワーク伝送し、受信側で復号する場合においても、ピクチャ内の全てのデータを受信する前に復号処理を開始することができる。つまり、ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム（即時的な）動画像伝送が可能となる。
【０００７】
このようなデータ伝送においては、システムが破たんしないように、安定的にデータ伝送を行うために、エラー訂正やパケット再送などのための時間が遅延時間として設定される。このように、処理の待ち時間やデータのバッファリング等のような、遅延時間の確保が必要な要素を遅延要素と称する。
【０００８】
一般的に、データ伝送においては、複数の遅延要素が存在する場合が多い。このような遅延要素に対して、受信側の装置においては遅延時間が確保されるが、このように複数の遅延要素が存在する場合、受信側の装置における遅延時間は、各遅延要素についての遅延時間のうち、最も長いもの（若しくはそれ以上）に設定される。
【０００９】
つまり、受信側の装置における遅延時間設定よりも短い遅延時間の遅延要素については、その遅延時間設定と同じ時間まで遅延時間を延ばしても、受信側の遅延時間設定は変化しない。つまり、データ伝送全体の遅延時間は増大しない。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特許４３７１１２０号
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、従来の方式においては、上述した各遅延要素についての遅延時間は、互いに独立して設定されていたので、遅延時間が短く設定された遅延要素に関係する処理は、その遅延時間が不要に短く設定されたまま実行されることになり、その処理後、何も処理が行われない不要な待機時間が生じてしまう恐れがあった。すなわち、データ伝送によりコンテンツの品質を不要に劣化させる恐れがあった。
【００１２】
本発明は、このような状況に鑑みてなされたものであり、各処理の時間的余裕を画質や伝送品質の向上に利用することができるようにし、遅延時間上の無駄を低減させることができるようにすることを目的とする。
【課題を解決するための手段】
【００１３】
本発明の一側面は、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段と、前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段とを備える情報処理装置である。
【００１４】
前記遅延時間は、前記データ伝送のQoS制御処理時間であり、前記調整手段は、前記QoS制御処理時間として要求されるQoS制御処理要求時間のうち、最長のQoS制御処理要求時間、若しくはそれ以上の所定の時間に合わせるように、各遅延時間の長さを調整することができる。
【００１５】
前記QoS制御処理時間は、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を含むことができる。
【００１６】
前記設定手段は、前記再送パケット待ち時間を、前記パケットの再送処理を行う再送処理部に設定し、前記ネットワークジッタ対応バッファ時間を、伝送された前記データを一時的に保持する保持部に設定することができる。
【００１７】
前記データ伝送における伝送品質に関する要求である伝送品質要求、および、前記冗長符号化ブロック受信待ち時間を用いて、前記データ送信側のQoS制御処理のパラメータ設定を行うパラメータ設定手段をさらに備えることができる。
【００１８】
前記データは伝送元において符号化され、得られた符号化データが伝送され、伝送先において前記符号化データが復号され、前記遅延時間は、前記符号化においてレート制御されて生成された前記符号化データを平滑化伝送する際に必要な可変圧縮符号化遅延要求時間を含み、前記データの画質に関する要求である画像品質要求、および、前記可変圧縮符号化遅延要求時間を用いて、前記符号化のバッファサイズを含む符号化パラメータの設定を行うパラメータ設定手段をさらに備えることができる。
【００１９】
前記データの画質に関する要求である画像品質要求、および、前記データ伝送における伝送品質に関する要求である伝送品質要求を受け付ける受付手段をさらに備え、前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、各遅延時間として要求される遅延要求時間を設定することができる。
【００２０】
前記受付手段により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力手段をさらに備えることができる。
【００２１】
複数の送信装置から１つの受信装置に向けて行われる前記データ伝送において、前記調整手段は、前記送信装置毎に前記遅延時間の調整を行い、さらに、各送信装置間で、それぞれの前記データ伝送全体の遅延時間が揃うように、前記遅延時間の調整を行うことができる。
【００２２】
本発明の一側面は、また、情報処理装置の情報処理方法であって、前記情報処理装置の調整手段が、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整し、前記情報処理装置の設定手段が、長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する情報処理方法である。
【００２３】
本発明の一側面は、さらに、データ伝送を行うコンピュータを、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段、前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段として機能させるためのプログラムである。
【００２４】
本発明の一側面においては、データ伝送を遅延させる遅延時間であって、データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さが、複数の遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整され、長さが調整された複数の遅延時間のそれぞれが、データ伝送に関する処理を行う処理部に設定される。
【発明の効果】
【００２５】
本発明によれば、データを伝送することができる。特に、コンテンツの品質の劣化を抑制することができる。
【図面の簡単な説明】
【００２６】
【図１】本発明を適用した伝送システムの主な構成例を示すブロック図である。
【図２】符号化部の主な構成例を示すブロック図である。
【図３】分析フィルタリングの概要を説明する図である。
【図４】分析フィルタリングの概要を説明する図３に続く図である。
【図５】ラインブロックを説明する図である。
【図６】復号部の主な構成例を示すブロック図である。
【図７】データ伝送処理の流れの例を説明するフローチャートである。
【図８】要求受付画面の表示例を示す図である。
【図９】受信バッファ時間決定処理の流れの例を説明するフローチャートである。
【図１０】遅延時間設定の様子の例を説明する図である。
【図１１】受信バッファ時間・処理パラメータ設定処理の流れの例を説明するフローチャートである。
【図１２】データ伝送処理の流れの他の例を説明するフローチャートである。
【図１３】受信バッファ動的変更伝送処理の流れの例を説明するフローチャートである。
【図１４】本発明を適用した伝送システムの主な構成例を示すブロック図である。
【図１５】受信部の主な構成例を示すブロック図である。
【図１６】データ伝送処理の流れの、さらに他の例を説明するフローチャートである。
【図１７】仮受信バッファ時間決定処理の流れの例を説明するフローチャートである。
【図１８】統合受信バッファ時間決定処理の流れの例を説明するフローチャートである。
【図１９】受信バッファ時間設定の様子の例を説明する図である。
【図２０】受信バッファ動的変更伝送処理の流れの、他の例を説明するフローチャートである。
【図２１】本発明を適用したパーソナルコンピュータの主な構成例を示すブロック図である。
【発明を実施するための形態】
【００２７】
以下、発明を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．第１の実施の形態（伝送システム）
２．第２の実施の形態（伝送システム）
３．第３の実施の形態（伝送システム）
４．第４の実施の形態（パーソナルコンピュータ）
【００２８】
＜１．第１の実施の形態＞
［伝送システムの概要］
図１は、本発明を適用した伝送システムの主な構成例を示すブロック図である。伝送システム１００は、送信装置１０１に入力された画像データ（ビデオデータ（ビデオIN））を、リアルタイムに（即時的に）、インターネットやLAN等の汎用の伝送路であるネットワーク１０２を介して受信装置１０３伝送し、その受信装置１０３より出力する（ビデオOUT）システムである。
【００２９】
送信装置１０１は、外部入力端子「ビデオIN」より入力された動画像の画像データを、全てのデータが入力されるまで待たずに、順次、符号化し、生成した符号化データのパケットを、ネットワーク１０２を介して受信装置１０３に送信する。
【００３０】
ネットワーク１０２は、例えば、インターネットやLAN等のような汎用のIPパケット網である。ネットワーク１０２においては、送信装置１０１および受信装置１０３の間のデータ伝送以外の、他のデータ伝送も行われる。
【００３１】
受信装置１０３は、送信装置１０１から伝送されるパケットを受信し、順次、得られた符号化データを復号し、復号画像の画像データを外部出力端子「ビデオOUT」より出力する。なお、受信装置１０３は、送信装置１０１に入力される画像データのサンプリング周波数に同期したタイミングで画像データの出力を行う。つまり、画像データは、送信装置１０１に入力されるときと同じフレームレートで受信装置１０３より出力される。伝送システム１００は、この出力タイミングに間に合うようにデータ伝送を行う。
【００３２】
近年においては、インターネットやLAN（Local Area Network）の汎用の伝送路を経由してメディア基準信号同期（所謂GENLOCK同期）を行いながらマルチメディアデータを低遅延に伝送するという需要が高まっている。
【００３３】
例えば、放送局においては、従来、カメラとそのコントロールユニット（所謂CCU）がHD-SDIケーブルにより接続され、それらの間で非圧縮同期伝送が行われていた。近年においては、このHD-SDIケーブルをEthernetケーブルに置き換え、Ethernet上でIPパケットによるGENLOCK同期を行いながら伝送するといったことが行われている。
【００３４】
このような目的においてマルチメディアデータのIP伝送を行う場合、HD-SDIケーブル経由での伝送と同等の使い勝手を要求される。そのため、高精度のGENLOCK同期や、ビデオフレーム間隔以下の低遅延伝送等が要求される。
【００３５】
このような要求から特許文献１においては、動画像の各ピクチャの数ライン毎を１つの符号化ブロック（ラインブロック）とし、符号化を行う方式が提案されている。この方式の場合、送信装置１０１は、ピクチャ内のデータ全てを入力するまで待つことなく符号化を開始することができる。また、送信装置１０１は、その符号化により得られた符号化データを、順次、ネットワーク１０２を介して受信装置１０３に伝送することができる。
【００３６】
さらに、受信装置１０３は、ピクチャ内の全てのデータを受信する前に復号を開始することができる。ネットワーク伝播遅延が十分小さければ、フレーム間隔以下の遅延でのリアルタイム動画像伝送（送信装置１０１入力時のフレームレートで、受信装置１０３から出力することができるようなデータ伝送）が可能となる。
【００３７】
動画像の符号化処理では、フレームやラインブロック等、短い時間単位において一定データレートにて符号化を行うCBR（Constant Bit Rate）方式と、長い時間間隔における平均データレートは一定だが短い時間間隔ではデータレートが変動するVBR（Variable Bit Rate）方式がある。
【００３８】
VBR方式で圧縮されたストリームデータを伝送する場合、ITU-T Y.1221記載のトークンバケット等を用い平滑化処理を行い、符号化処理においてはトークンバケットの最大バケツサイズを超えないように制御する。このとき最大バケツサイズにより符号化処理における最大バースト（瞬時）データサイズは制限される。
【００３９】
VBR方式の場合、一般に、画像の複雑度の高い部分、動きの激しいシーン等の圧縮効率の低い部分に多くのデータを割り当てることができる。そのため、一般的に、VBR方式の方がCBR方式よりも圧縮効率が高い。つまり、一般的に、同一の平均データレートの場合、VBR方式の方がCBR方式よりも高画質である。
【００４０】
トークンバケットにおける最大バケツサイズを大きくとればとるほど画質は向上するが、ストリーム伝送後の同期再生を考えた場合、同期再生までの遅延時間は大きくなる。以下において、VBR方式で符号化処理を行った場合の平滑化処理により生じる遅延時間を可変圧縮符号化遅延時間と称する。
【００４１】
上述したようなリアルタイム伝送に適したインターネット技術にIETF RFC3550で規定されているRTP（Realtime Transport Protocol）がある。RTPによるデータ転送では、時間情報としてパケットにタイムスタンプを付加しておき、これによって送信側と受信側の時間的関係を把握することでパケット転送の遅延ゆらぎ（ジッタ）などの影響を受けずに同期をとって再生することができる。
【００４２】
ここでRTPは、実時間のデータ転送を保証しているものではない。例えばパケット配送の優先度の設定や管理などはRTPが提供するトランスポートサービスの範疇ではない。そのため、RTPパケットは、他のパケットと同様に、配送遅延やパケット損失がおきる可能性がある。このような事態が起こる場合であっても、受信装置１０３は、期待する時間内に到着したパケットだけを利用してデータを再生することができる。映像や音声データは、多少のデータ損失があったとしても、ある程度再生することができる。
【００４３】
なお、遅延配送されたパケットやエラーの発生したパケットは、受信装置１０３により、破棄される。つまり、パケット損失やエラーにより高品質なデータを配信するようにしても、受信装置１０３において、その高品質なデータが十分に再生されない恐れがある。有線区間で１０−５以上、無線区間で１０−３以上のエラーがあるといわれており、このような現状の中でRTPをそのまま利用するのでは、配信するメディアの品質を保持する点について信頼性が低い。
【００４４】
これに対して、データ転送に信頼性が高いTCP（Transmission Control Protocol）で再送要求および再送パケット送信を行わせる方法がある。しかしながら、TCPは、エラーには強いものの、スループットが低く遅延が大きい。そのため、再送しても再生時間に間に合わない恐れがある。
【００４５】
RTPを用いてデータ転送の信頼性を向上させる手法として、データの冗長符号化を行い信頼性の向上を図る、前方誤り訂正符号化方式（所謂FEC(Forward Error Correction)方式）という手法がある。
【００４６】
FEC方式では、パケット複数個を１つのFECブロックとし、Reed-Solomon（RS）符号等の誤り訂正符号を用いて冗長符号化を行う。例えば（n,k）RS符号を用いる場合、元パケットをk個とするとn-k個冗長パケットを生成することができる（n > k）。この場合、送信装置１０１から合計n個のパケットを送信することにより、受信装置１０３ではn個のパケット中k個のパケットを受信すれば、RS復号処理によりk個の元パケットを復元することができる。
【００４７】
FEC方式を用いて冗長符号化した場合、パケット損失に対する回復性能はFECブロック元データ単位と冗長パケット数n-kとに依存する。特に、ネットワーク伝送中に起こるデータ系列上連続するパケットの損失（所謂バーストパケット損失）に対する回復性能は、FECブロック元データ単位と関係が深い。一般に、FECブロック元データ単位を大きくとればとるほど、バーストパケット損失に対する回復性能は向上する。
【００４８】
しかしながら、FECブロック元データ単位を大きく取るとFEC符号化処理・復号処理を行うために必要なブロックサイズ（データ量）が増大する。その分、処理に必要なデータ蓄積量、すなわち、待機時間が増大するので、遅延時間が増大する恐れがあった。このようなFEC符号化処理やFEC復号処理に必要な遅延時間を、冗長符号化ブロック受信待ち時間と称する。
【００４９】
データ転送の信頼性を向上させる他の手法として、自動再送方式、いわゆるARQ（Auto Repeat Request）方式がある。ARQ方式は、受信装置１０３が、RTPパケットのシーケンス番号を利用して損失したパケットを検知し、送信装置１０１へ損失パケットの再送を要求するようにする方式である。このARQ方式の拡張方法として、受信装置１０３が、パケット損失に対して一定時間再送パケットを受信しなかった場合、再度再送要求を行う手法もある。
【００５０】
この手法を用いる場合、受信装置１０３における再送パケット待ち時間を大きく設定すればするほど回復性能は向上するが、その分、同期再生時の遅延を増大させてしまう。
【００５１】
また他の伝送品質の回復手法として、受信装置１０３が、ネットワーク伝送時間の変動（所謂ネットワークジッタ）を吸収するためのバッファ（ネットワークジッタ対応バッファ）を設ける方法もある。このネットワークジッタ対応バッファでバッファリングを行う時間、（所謂ネットワークジッタ対応バッファ時間）を大きくとればとるほど、受信装置１０３において行われる各種処理における、ネットワークジッタによる影響を抑制することができる。ただし、その分、同期再生時の遅延を増大させてしまう。
【００５２】
以上のように、データ伝送に関して、一般的に、多様な遅延要素が存在し、受信側の装置においては、各遅延要素についての遅延時間の確保が必要であった。
【００５３】
しかしながら、従来においては、復号画像の画質（画質要求）や、データ伝送時のパケット損失率（伝送品質）等に対する要求に応じて、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、および、ネットワークジッタ対応バッファ時間等の各種遅延時間が互いに独立に設定されていた。
【００５４】
受信装置１０３は、これらの遅延によりシステムが破たんしないように、受信したデータを、これらの遅延時間の最大値以上の時間、一時的に保持する。つまり、各遅延要素の遅延時間を受信装置１０３において確保する必要があった。このデータを保持する時間を受信バッファ時間と称する。
【００５５】
この場合、例えば可変圧縮符号化遅延時間が上記遅延時間中最大値であり、この値を受信バッファ時間として設定したとする。その場合、冗長符号化処理において、さらに冗長符号化ブロックを大きく取ることによりバースト損失耐性を向上させ、冗長符号化ブロック受信待ち時間を受信バッファ時間と同等まで大きくしても全体の遅延時間は増加しない。
【００５６】
しかしながら、仮に、冗長符号化ブロック受信待ち時間が、従来の方法のように、他と独立して設定されるとする。その場合、冗長符号化処理は、冗長符号化ブロック受信待ち時間が小さいまま行われることになる。つまり、冗長符号化処理において、処理が行われない不要な待機時間が発生し、遅延時間上の無駄が生じる恐れがあった。
【００５７】
また、冗長符号化ブロック受信待ち時間が最大である場合、可変圧縮符号化遅延時間を大きく設定することにより、全体の遅延時間を増大させずに画質を向上させることができる。しかしながら、上述した従来の方法のように各遅延時間が互いに独立して設定されるものとすると、符号化処理は、可変圧縮符号化遅延時間が小さい設定のまま行われることになる。つまり、遅延時間上の無駄が生じる恐れがあった。
【００５８】
受信装置１０３は、データ伝送を遅延させる遅延時間であって、そのデータ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、その複数の遅延時間の内、最長の遅延時間に合わせるように調整する。
【００５９】
送信装置１０１も、受信装置１０３から供給される情報に基づいて、受信装置１０３において確保された遅延時間（受信バッファ時間）より遅延時間が増大しないように、かつ、より遅延時間を長くし、画像や伝送の品質を向上させるように、各処理のパラメータを設定する。
【００６０】
したがって、伝送システム１００（送信装置１０１および受信装置１０３）は、このような遅延時間上の無駄を抑制するようにし、データ伝送全体の遅延時間を増大させずに画質や伝送品質（コンテンツの品質）を向上させることができる。
【００６１】
［送信装置の構成］
図１に示されるように、送信装置１０１は、符号化部１１１、FEC部１１２、RTP部１１３、平滑化部１１４、基準信号同期部１１５、メディア同期部１１６、RTCP（RTP Control Protocol）部１１７、ARQ部１１８、および受信バッファ時間・処理パラメータ設定部１１９を有する。
【００６２】
ビデオカメラ等を経由しビデオ入力IF「ビデオIN」より入力したビデオデータ（動画像データ）は、符号化部１１１に供給される。符号化部１１１は、所定の符号化方式で動画像データの符号化処理を行う。この符号化方式は任意であるが、より低遅延なものが望ましい。符号化方式の例については後述する。
【００６３】
符号化部１１１は、レート制御部１２１を有する。レート制御部１２１は、符号化部１１１において生成される符号化データのビットレートを制御する。符号化部１１１は、生成した符号化データをRTPパケット化し、それをFEC部１１２に供給する。
【００６４】
FEC部１１２は、符号化部１１１から供給されるRTPパケットの冗長パケットを生成する。RTP部１１３は、FEC部１１２から供給される符号化データの冗長パケットをRTPパケット化する。
【００６５】
平滑化部１１４は、RTP部１１３から供給されるRTPパケットを、一時的に保持し、所定のデータレートに平滑化して送信する。
【００６６】
基準信号同期部１１５は、ネットワーク１０２を介して、伝送先である受信装置１０３の基準信号同期部１３９と通信を行い、基準信号クロックの同期をとる。基準信号同期部１１５は、受信装置１０３との間で同期がとれた基準信号をメディア同期部１１６に供給する。
【００６７】
メディア同期部１１６は、基準信号同期部１１５から供給される時刻を基準として、ビデオINに入力されたデータのサンプリング時刻と同期した時刻を、符号化部１１１（内のRTP部）とRTP部１１３に供給する。この時刻は、RTPタイムスタンプとしてRTPパケットに付加される。
【００６８】
RTCP部１１７は、伝送先の受信装置１０３のRTCP部１３７とRTCPメッセージの授受を行い、QoS（Quality of Service）制御処理のための制御メッセージ（QoS制御メッセージ）の送受信を行う。RTCP部１１７は、取得した制御メッセージをARQ部１１８や受信バッファ時間・処理パラメータ設定部１１９に供給する。
【００６９】
ARQ部１１８は、RTCP部１１７から供給される再送要求メッセージに従って、要求されたRTPパケットの再送を行う。
【００７０】
受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７から供給される各種遅延時間等の設定に従って、符号化部１１１やFEC部１１２のパラメータ設定を行う。
【００７１】
［受信装置の構成］
図１に示されるように、受信装置１０３は、受信部１３１、受信バッファ１３２、RTP部１３３、FEC部１３４、復号部１３５、ARQ部１３６、RTCP部１３７、受信バッファ時間設定部１３８、基準信号同期部１３９、メディア同期部１４０、入力部１４１、および出力部１４２を有する。
【００７２】
受信部１３１は、ネットワーク１０２を介して送信装置１０１から伝送されるRTPパケットを受信し、それを受信バッファ１３２に供給する。受信バッファ１３２は、ネットワーク１０２におけるパケット伝送の遅延時間の変動を吸収する等のために、受信部１３１から供給されるRTPパケットを、一時的に保持した後、受信バッファ時間設定部１３８やメディア同期部１４０からの情報に基づいて決定される時刻に、RTP部１３３に供給する。
【００７３】
RTP部１３３は、RTPパケットを再構成して、冗長パケットを含む符号化データであるFEC冗長符号化データを生成し、それをFEC１３４に供給する。FEC部１３４は、パケットの損失の検出を行い、必要に応じて冗長符号化復号処理によって損失パケットデータを回復する。FEC部１３４は、処理後の符号化データを復号部１３５に供給する。
【００７４】
復号部１３５は、符号化データを、符号化部１１１による符号化処理の方式に対応する復号方式により復号する。復号されたビデオデータ（動画像データ）は、受信装置１０３のビデオ出力IF（ビデオOUT）から、例えば、ディスプレイ等の映像表示装置（図示せず）に出力される。
【００７５】
ARQ部１３６は、受信部１３１における損失パケット（受信できなかったパケット）の検出を行い、損失パケットを検出した場合、RTCP部１３７を制御し、送信装置１０１のARQ部１１８に対する再送要求メッセージを送信させる。RTCP部１３７は、ARQ部１３６から要求された再送要求メッセージや、受信バッファ時間設定部１３８から供給される各種設定情報をRTCPメッセージとして、送信装置１０１のRTCP部１１７に供給する。
【００７６】
受信バッファ時間設定部１３８は、例えば入力部１４１を介して入力される画像品質要求や、伝送品質要求等に基づいて、受信バッファ時間等を設定する。画像品質要求は、復号画像（受信装置１０３から出力されるビデオデータの画像）の画質に対する要求である。伝送品質要求は、ネットワーク１０２のパケットロス率等に対する要求である。受信バッファ時間は、システムを破たんさせないように、データ伝送を安定的に伝送させるために受信装置１０３において設定される遅延時間である。
【００７７】
基準信号同期部１３９は、基準信号同期部１１５と通信し、送信装置１０１との間で基準信号の同期をとる。メディア同期部１４０は、基準信号同期部１３９により同期がとられた基準信号に基づいて、受信バッファ１３２のRTPパケット出力タイミングや、復号部１３５の復号処理開始タイミング等を制御する。
【００７８】
入力部１４１は、例えば、キーボード、マウス、タッチパネル、若しくはスイッチ等の任意の入力デバイス、または外部入力端子等よりなり、例えばユーザ等の、受信装置１０３外部からの画像品質要求や伝送品質要求を受け付け、それを受信バッファ時間設定部１３８に供給する。
【００７９】
出力部１４２は、例えば、モニタやスピーカ等の任意の出力デバイス、または、外部出力端子等よりなり、受信バッファ時間設定部１３８から供給されるGUI画像を表示したり、音声を出力したりして、画像品質要求や伝送品質要求の入力案内や、入力結果を出力する。
【００８０】
［符号化部の構成例］
次に、送信装置１０１の符号化部１１１の例について説明する。図２は、送信装置１０１の符号化部１１１の構成例を示すブロック図である。符号化部１１１は、画像データを解像度に関して重要度の高いデータから順に階層化し、その階層毎に符号化する階層符号化を行う。例えば、符号化部１１１は、空間解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。また、例えば、符号化部１１１は、時間方向の解像度に関して重要度の高いデータから順に階層化された階層化データを生成する。さらに、例えば、符号化部１１１は、SNR（Signal to Noise Ratio）に関して重要度の高いデータから順に階層化された階層化データを生成する。符号化部１１１は、このように生成した階層化データを、その階層毎に符号化する。
【００８１】
このような階層符号化として、例えば、動画像データの各ピクチャをウェーブレット変換し、エントロピ符号化するJPEG(Joint Photographic Experts Group)2000方式がある。階層符号化方法は任意であるが、以下においては、符号化部１１１が、動画像データを複数ライン毎にウェーブレット変換し、エントロピ符号化する場合について説明する。
【００８２】
図２に示されるように、符号化部１１１は、ウェーブレット変換部１６１、量子化部１６２、エントロピ符号化部１６３、レート制御部１２１、およびRTP部１６４を有する。ウェーブレット変換部１６１は、動画像の各ピクチャを、複数ライン毎にウェーブレット変換する。
【００８３】
ウェーブレット変換は、入力データを低域成分と高域成分に分割する分析フィルタ処理を画面水平方向および画面垂直方向の両方に対して行う処理である。つまり、ウェーブレット変換処理により入力データは、水平方向および垂直方向に低域な成分（ＬＬ成分）、水平方向に高域で垂直方向に低域な成分（ＨＬ成分）、水平方向に低域で垂直方向に高域な成分（ＬＨ成分）、および、水平方向および垂直方向に高域な成分（ＨＨ成分）の４つの成分（サブバンド）に分割される。
【００８４】
ウェーブレット変換部１６１は、このようなウェーブレット変換処理を、所定回数、分析フィルタ処理により得られる水平方向および垂直方向に低域な成分（ＬＬ成分）に対して再帰的に繰り返す。つまり、ウェーブレット変換処理により、動画像データの各ピクチャは、階層化された複数のサブバンド（周波数成分）に分割される（階層化データが生成される）。エントロピ符号化部１６３は、このサブバンド毎に符号化を行う。
【００８５】
動画像の各ピクチャの画像データは、画像の上から下に向かう順に１ラインずつウェーブレット変換部１６１に入力される。また各ラインの画像データは、画像左から右に向かう順に１サンプル（１コラム）ずつ入力される。
【００８６】
ウェーブレット変換部１６１は、そのように入力される画像データに対して、分析フィルタリングを実行可能なサンプル数のデータを入手する毎に（入手次第）、画像水平方向の分析フィルタリング（水平分析フィルタリング）を実行する。例えば、ウェーブレット変換部１６１は、図３の左に示されるベースバンドの画像データ１７１に対して、Ｍコラム入力される毎に水平分析フィルタリングを行い、１ラインずつ水平方向に低域な成分（Ｌ）と高域な成分（Ｈ）に分割する。図３の右に示される水平分析フィルタ処理結果１７２は、ウェーブレット変換部１６１により分割されたＮライン分の水平方向に低域な成分（Ｌ）と高域な成分（Ｈ）を示す。
【００８７】
次に、ウェーブレット変換部１６１は、その水平分析フィルタ処理結果１７２の各成分に対して、垂直方向に分析フィルタリング（垂直分析フィルタリング）を行う。ウェーブレット変換部１６１は、水平分析フィルタリングにより、垂直分析フィルタリングに必要な垂直ライン分の係数が生成されると、その垂直分析フィルタリングに必要な垂直ライン分の係数に対して、コラム毎に垂直分析フィルタリングを行う。
【００８８】
その結果、水平分析フィルタ処理結果１７２は、図４の左に示されるように、水平方向および垂直方向の両方に低域な成分（ＬＬ成分）、水平方向に高域で垂直方向に低域な成分（ＨＬ成分）、水平方向に低域で垂直方向に高域な成分（ＬＨ成分）、および、水平方向および垂直方向の両方に高域な成分（ＨＨ成分）の４つの成分のウェーブレット変換係数（以下、係数と称する）に分割される（階層化データ１７３）。
【００８９】
所定の階層（分割レベル）の係数が得られるまで、得られた分析フィルタリングの結果のうち、ＨＬ成分、ＬＨ成分、ＨＨ成分は外部に出力される。残りのＬＬ成分は、ウェーブレット変換部１６１により、再度分析フィルタリングが行われる。つまり、例えば、図４の左に示される階層化データ１７３は、図４の右に示される階層化データ１７４に変換される。階層化データ１７４では、ＬＬ成分から、ＬＬＬＬ成分、ＬＬＨＬ成分、ＬＬＬＨ成分、およびＬＬＨＨ成分の４つの成分が生成されている。
【００９０】
ウェーブレット変換部１６１は、このような分析フィルタリングを所定回数再帰的に行い、動画像データを所望の分割レベルまで階層化された階層化データを生成する。図５は、分割レベル３（３階層）まで階層化された階層化データの例を示す図である。図５において、分割レベル３まで分割された階層化データ１７５は、分割レベル１（階層番号３）の３ＨＬ成分、３ＬＨ成分、および３ＨＨ成分、分割レベル２（階層番号２）の２ＨＬ成分、２ＬＨ成分、および２ＨＨ成分、並びに、分割レベル３（階層番号１）の１ＬＬ成分、１ＨＬ成分、１ＬＨ成分、および１ＨＨ成分の各サブバンドにより構成される。
【００９１】
ウェーブレット変換処理では、フィルタリング処理を繰り返す毎に（階層が１つ下位になる毎に）、生成されるライン数は２のべき乗分の１の大きさで小さくなっていく。最終分割レベル（階層番号１）の係数を１ライン生成するために必要なベースバンドのライン数は、そのフィルタリング処理を何回繰り返すか（最終分割レベルの階層数）によって決められる。通常、この階層数は予め定められる。
【００９２】
この、最終分割レベルの係数を１ライン生成するために必要なベースバンドの画像データ（複数ライン分の画像データ）、または、各階層の係数をまとめてラインブロック（またはプレシンクト）と称する。
【００９３】
図５において斜線で示される部分が１ラインブロックを構成する係数である。図５に示されるように、ラインブロックは、階層番号１の各成分の１ライン分の係数、階層番号２の各成分の２ライン分の係数、並びに、階層番号３の各成分の４ライン分の係数により構成される。なお、これらに相当する分析フィルタリング前の画像データ、すなわち、この例では８ライン分の画像データのこともラインブロック（またはプレシンクト）と称する。
【００９４】
図２に戻り、量子化部１６２は、ウェーブレット変換部１６１により生成される各成分の係数を、例えば量子化ステップサイズで除算することにより量子化し、量子化係数を生成する。この際、量子化部１６２は、ラインブロック（プレシンクト）毎に量子化ステップサイズを設定することができる。このラインブロックは、ある画像領域のすべての周波数成分（図５の場合、１ＬＬ乃至３ＨＨまでの１０個の周波数成分）の係数を包含しているため、ラインブロック毎に量子化を行えば、ウェーブレット変換の特徴である多重解像度分析の利点を活かすことができる。また、全画面でラインブロック数だけを決めればよいため、量子化の負荷も小さくて済む。
【００９５】
さらに、画像信号のエネルギは一般的に低域成分に集中しており、また、人間の視覚上、低域成分の劣化が目立ちやすいという特性があるため、量子化に際しては、低域成分のサブバンドでの量子化ステップサイズが結果的に小さな値になるように、重み付けを行うことが有効である。この重み付けにより、低域成分には相対的に多くの情報量が割り当てられるようになり、全体の主観的な画質が向上する。
【００９６】
エントロピ符号化部１６３は、量子化部１６２で生成された量子化係数を情報源符号化し、圧縮された符号化データを生成し、それをレート制御部１２１に供給する。情報源符号化としては、例えばJPEG方式やMPEG（Moving Picture Experts Group）方式で用いられているハフマン符号化や、JPEG2000方式で用いられているさらに高精度な算術符号化を用いることができる。
【００９７】
ここで、エントロピ符号化をどの範囲の係数に対して行うかは、圧縮効率に直接関係する非常に重要な要素になる。例えば、JPEG方式やMPEG方式では、８×８のブロックに対してDCT（Discrete Cosine Transform）変換を施し、生成された６４個のDCT変換係数に対してハフマン符号化を行うことで、情報を圧縮している。すなわち、６４個のDCT変換係数がエントロピ符号化の範囲になる。
【００９８】
ウェーブレット変換部１６１では、８×８ブロックに対するDCT変換とは異なり、ライン単位でウェーブレット変換を施しているため、エントロピ符号化部１６３では、周波数帯域（サブバンド）毎に独立に、且つ各周波数帯域内をＰライン毎に情報源符号化する。
【００９９】
Ｐは１ラインが最低であるが、ライン数が少ない場合には参照情報が少なくて済み、メモリ容量を減らすことができる。逆に、ライン数が多い場合には情報量がその分増えるため、符号化効率が向上させることができる。しかしながら、Ｐが各周波数帯域内のラインブロックのライン数を超えた値になると、次のラインブロックのラインまで必要になる。このため、このラインブロックの量子化係数データがウェーブレット変換及び量子化によって生成されるまで待たなければならず、この時間が遅延時間となってしまう。
【０１００】
したがって、低遅延のためには、Ｐはラインブロックのライン数以下である必要がある。例えば、図５の例では、１ＬＬ，１ＨＬ，１ＬＨ，１ＨＨの周波数帯域については、ラインブロックのライン数＝１ラインであるためＰ＝１となる。また、２ＨＬ，２ＬＨ，２ＨＨのサブバンドについては、ラインブロックのライン数＝２ラインであるためＰ＝１または２となる。
【０１０１】
レート制御部１２１は、最終的に目標のビットレート又は圧縮率に合わせるための制御を行い、レート制御後の符号化データをRTP部１６４に供給する。例えば、このレート制御部１２１は、ビットレートを上げる場合には量子化ステップサイズを小さくし、ビットレートを下げる場合には量子化ステップサイズを大きくするように、量子化部１６２に対して制御信号を送信する。
【０１０２】
RTP部１６４は、レート制御部１２１から供給される符号化データをRTPパケット化し、FEC部１１２に供給する。
【０１０３】
［復号部の構成例］
次に、上述した符号化部１１１の例に対応する復号部１３５の例について説明する。図６は、受信装置１０３の復号部１３５の構成例を示すブロック図である。図６において、復号部１３５は、RTP部１９０、エントロピ復号部１９１、逆量子化部１９２、およびウェーブレット逆変換部１９３を有する。
【０１０４】
RTP部１９０は、FEC部１３４から供給されるRTPパケットを符号化データに変換し、それをエントロピ復号部１９１に供給する。エントロピ復号部１９１は、エントロピ符号化部１６３の符号化方法に対応する方法で符号化データを復号し、量子化係数データを生成する。例えば、ハフマン復号や、高効率な算術復号などを用いることができる。なお、エントロピ符号化部１６３においてＰラインごとに符号化されている場合、エントロピ復号部１９１は、各サブバンドを独立に復号し、かつ、各サブバンド内をＰライン毎に復号する。
【０１０５】
逆量子化部１９２は、量子化係数データに量子化ステップサイズを乗算することにより逆量子化し、係数データを生成する。この量子化ステップサイズは、通常、送信装置１０１から供給される符号化データのヘッダなどに記述されている。なお、量子化部１６２において、ラインブロック毎に量子化ステップサイズが設定されている場合には、逆量子化部１９２においても同様に、ラインブロック毎に逆量子化ステップサイズが設定されて、逆量子化される。
【０１０６】
ウェーブレット逆変換部１９３は、ウェーブレット変換部１６１の逆処理を行う。つまり、ウェーブレット逆変換部１９３は、ウェーブレット変換部１６１により複数の周波数帯域に分割された係数データに対して、低域成分と高域成分を合成するフィルタ処理（合成フィルタ処理）を水平方向と垂直方向の両方に対して行う。ウェーブレット逆変換部１９３は、このようはウェーブレット逆変換処理により、ベースバンドのビデオデータを復元し、ビデオOUTから受信装置１０３の外部に出力する。
【０１０７】
もちろん、上述した符号化部１１１および復号部１３５は、一例であり、これ以外の符号化・復号方式を用いるようにしてもよい。
【０１０８】
［伝送処理］
次に、伝送システム１００において行われる各処理について説明する。最初に、ビデオデータを送信装置１０１からネットワーク１０２を介して受信装置１０３に伝送する伝送処理について説明する。
【０１０９】
送信装置１０１は、ビデオカメラ等を経由し、ビデオ入力IF「ビデオIN」より入力したビデオデータを、動画像データの符号化処理を行う符号化部１１１に入力し、符号化される。符号化データは、符号化部１１１内部のRTP部１６４によりRTPパケット化処理を施され出力される。出力されたRTPパケットは、FEC部１１２によりFEC冗長符号化処理を施され、RTP部１１３によりFEC冗長符号化データ用のRTPパケット化処理を施され、平滑化部１１４からRTPパケットとしてネットワーク１０２へ送信される。
【０１１０】
各RTPパケットには、メディア同期部１１６にて指定された同期用RTPタイムスタンプがセットされる。
【０１１１】
受信装置１０３は、送信装置１０１より送信されたRTPパケットを受信部１３１で受信し、受信バッファ１３２に保存する。このとき損失パケットが検出された場合、ARQ部１３６に通知され、ARQ部１３６により再送要求処理が行われる。
【０１１２】
受信バッファ１３２は、受信バッファ時間決定部１３８により決定された受信バッファ時間と、メディア同期部１４０より通知される時刻情報と、各RTPパケットにセットされたRTPタイムスタンプ値とから、受信バッファ出力時刻を決定し、所定時刻に各RTPパケットをRTP部１３３に出力する。
【０１１３】
RTP部１３３は、RTPパケットをFEC冗長符号化データへ変換する再構成処理を行い、変換したFEC冗長符号化データを、FEC部１３４へ出力する。FEC部１３４は、損失パケットの検出を行う。損失パケットが検出された場合、FEC部１３４は、冗長符号化復号処理により損失パケットデータの回復を行う。
【０１１４】
このように処理された符号化データ（RTPパケット）は、復号部１３５に供給される。復号部１３５は、供給された符号化データのRTPパケットを変換して符号化データを生成し、その符号化データに対して復号処理を行う。復号されたビデオデータは、ビデオ出力IF「ビデオOUT」より、例えば、ディスプレイ等の映像表示装置に供給され、出力される。
【０１１５】
［基準信号同期処理］
次に、送信装置１０１と受信装置１０３との間で基準信号の同期をとる基準信号同期処理について説明する。基準信号同期部１１５および基準信号同期部１３９は、互いに通信を行い、IEEE 1588 PTP（Precision Time Protocol）を用い、送信装置１０１と受信装置１０３との間の基準信号クロックの同期を行う。
【０１１６】
基準信号クロックの周波数としては、例えば、入力ビデオ画像のピクセルサンプリング周波数が用いられる。また、ビデオ出力装置から出力されるビデオデータが「ビデオIN」から入力される場合、送信装置１０１とそのビデオ出力装置との間でも、基準信号の同期がとられるようにしてもよい。
【０１１７】
なお、基準信号同期部１１５および基準信号同期部１３９による、送信装置１０１と受信装置１０３との間の基準信号の同期とりは、任意であり、装置間で基準信号の同期をとらないようにしてもよい。
【０１１８】
［メディア同期処理］
次に、基準信号に基づいてビデオデータの同期をとるメディア同期処理について説明する。送信装置１０１におけるメディア同期部１１６は、基準信号同期部１１５より通知された時刻を基に、「ビデオIN」より入力されたデータのサンプリング時刻と同期した時刻を、RTPタイムスタンプの周波数に変換し、符号化部１１１内のRTP部１６４、およびRTP部１１３にて各RTPパケットにRTPタイムスタンプとして付加する。
【０１１９】
受信装置１０３におけるメディア同期部１４０は、基準信号同期部１３９より通知された基準クロック時刻情報をRTPタイムスタンプ周波数に変換したシステム時刻として保持する。
【０１２０】
受信装置１０３における受信バッファ１３２にRTPパケットが記録されると、受信バッファ１３２は、RTPパケットのRTPタイムスタンプ値と、受信バッファ時間設定部１３８より通知された受信バッファ時間と、メディア同期部１４０から供給されるRTPタイムスタンプ周波数時刻とから、各RTPパケットの受信バッファ出力時刻を決定する。
【０１２１】
RTPパケットの受信バッファ出力時刻は、例えば、以下のように決定される。ストリームデータの先頭パケットは、受信した時刻から受信バッファ時間TSTIME_BUFが経過した時刻後に受信バッファから出力されるものとする。これに対して、後続パケットは、先頭パケットのRTPタイムスタンプ値と当該パケットのRTPタイムスタンプ値との差分値から算出される時刻に同期出力される。
【０１２２】
RTPパケットnの受信バッファ出力時刻TSSYS_BO_nは、例えば、以下の式（１）により算出される。ストリーム先頭パケットのRTPタイムスタンプ値をTSPKT_initとし、受信時刻（システム時刻換算：周波数はRTPタイムスタンプ周波数）をTSSYS_initとし、RTPパケットnのRTPタイムスタンプ値をTSPKT_nとする。
【０１２３】
TSSYS_BO_n＝（TSPKT_n−TSPKT_init）＋TSSYS_init＋TSTIME_BUF ・・・（１）
【０１２４】
［符号化処理・復号処理］
次に、送信装置１０１および受信装置１０３が行うビデオデータのコーデック処理（符号化処理および復号処理）について説明する。符号化部１１１は、例えば特許文献１において提案されている動画像の各ピクチャの数ライン毎を１つの符号化ブロックとしてウェーブレット変換を行う階層符号化方式であり、かつ、階層毎に関連する入力データ範囲の異なる符号化方式を用いる。
【０１２５】
符号化部１１１が符号化処理を行って符号化データを生成し、復号部１３５がその符号化データを復号する復号処理を行う。
【０１２６】
符号化部１１１は、上述したようにレート制御部１２１を有する。レート制御部１２１は、例えば、ITU-T Y.1221記載のトークンバケットビヘビアにおける、バケツサイズをエンコーダ想定バッファサイズＢ（byte）、バケットレートＲ（bps）をエンコードレートとして、バケットがあふれないようにエンコードレートを制御するレート制御を行う。これを平滑化伝送したときに受信装置１０３において必要となるバッファ時間を「可変圧縮符号化遅延要求時間」と称する。
【０１２７】
可変圧縮符号化遅延要求時間Bt_codec_req(sec)は、例えば、以下の式（２）のように算出される。
【０１２８】
Bt_codec_req＝Ｂ×８／Ｒ ・・・（２）
【０１２９】
エンコーダ想定バッファサイズＢは、ユーザ等により指定される画像品質要求に応じて決定される。VBR方式による圧縮符号化の場合、エンコーダ想定バッファサイズＢを大きくとることにより、複雑度の高い画像部分により多くのデータ量を使用することができ、画質を向上させることができる。つまり、画像品質要求が高い場合、このエンコーダ想定バッファサイズＢを大きくとることでその高い要求に応じることができる。
【０１３０】
ただし、エンコーダ想定バッファサイズＢを大きくとると、可変圧縮符号化遅延要求時間Bt_codec_req(sec)が大きくなるので、遅延が増加する恐れがある。
【０１３１】
［RTCP処理］
次に、送信装置１０１と受信装置１０３との間で行われるQoS制御処理のRTCP処理について説明する。RTCP部１１７およびRTCP部１３７は、IETF RFC 3550記載のRTCPを用いて、送信装置１０１と受信装置１０３との間でRTCPメッセージの送受信を行い、パケット損失率、往復伝搬遅延（RTT）、およびネットワークジッタ等の情報収集や、QoS制御処理のための制御メッセージの送受信を行う。QoS制御メッセージとしては、例えば、ARQ処理における再送要求メッセージ等がある。
【０１３２】
［FEC処理］
次に、QoS制御処理のFEC処理について説明する。FEC部１１２は、符号化部１１１から供給される符号化データのRTPパケットを単位として、FEC冗長符号化を行う。例えば、FEC部１１２は、Reed-Solomon符号等の消失誤り訂正符号を用い冗長符号化を行う。
【０１３３】
FEC冗長符号化における冗長度は、例えば、ユーザ等により指定される伝送品質要求により決定される。冗長度は、（元データパケット数，冗長パケット数）という形で指定される。ユーザは、また、ネットワークの想定パケット損失率pも指定する。
【０１３４】
以下においては、（元データパケット数，冗長パケット数）の組を１つの冗長符号単位（所謂FECブロック）とする。例えば、（元データパケット数，冗長パケット数）＝（10,5）と指定された場合、送信装置１０１のFEC部１１２は、元データパケット数10個に対して、冗長パケットを５個生成する。つまり、このFECブロックにおいては合計15個のパケットが送信される。
【０１３５】
この場合、受信装置１０３のFEC部１３４は、このFECブロックパケット中任意の10個のパケットを受信すれば、FEC復号処理により元データを復号することができる。例えば、ユーザにより指定されたパケット損失率をpとし、FECブロック内のパケット数をnとし、元データパケット数をｋとし、冗長パケット数をn-kとし、ユーザにより伝送品質要求として指定される目標FECブロック損失率をPtとすると、目標FECブロック損失率Ptは、以下の式（３）のように表される。
【０１３６】
【数１】
・・・（３）
【０１３７】
この式（３）を満たすように元データパケット数kおよび冗長パケット数n-kが決定される。
【０１３８】
受信装置１０３（FEC部１３４）では、FEC冗長復号化処理により損失パケット回復を行うために、FECブロックの先頭パケットが受信装置１０３に到着してから末尾のパケットが到着するまでの時間（所謂、冗長符号化ブロック受信待ち時間）以上に受信バッファ時間を設定する必要がある。
【０１３９】
ユーザ等により指定される伝送品質要求に応じて設定されたFECブロックに対応する冗長符号化ブロック受信待ち時間を「冗長符号化ブロック受信待ち要求時間」と称する。
【０１４０】
［ARQ処理］
受信装置１０３におけるARQ処理では、受信部１３１がRTPパケットのシーケンス番号を利用して損失したパケットを検知し、ARQ部１３６がその損失パケットの再送要求メッセージを生成し、RTCP部１３７が、送信装置１０１に対してその再送要求メッセージを送信し、再送要求を行う。
【０１４１】
なお、受信装置１０３のARQ部１３６が、パケット損失に対して再送要求を行い、往復伝搬時間（ARQ再送パケット待ち時間）経過しても受信部１３１が再送パケットを受信しなかった場合、再度、再送要求を行うようにしてもよい。さらに、ARQ部１３６が、当該パケットの受信バッファ出力時刻に再送パケット到着が間に合わないと決定されるまで、このような再送要求を繰り返すようにしてもよい。
【０１４２】
送信装置１０１におけるARQ処理では、RTCP部１１７が再送要求メッセージを受け取ると、ARQ部１１８が再送すべきRTPパケット（再送パケット）を生成し、その再送パケットを平滑化部１１４に供給し、再送させる。
【０１４３】
ARQ処理における回復性能は、受信装置１０３における、ARQ部１３６の要求により再送される再送パケットを待つ時間であるARQ再送パケット待ち時間に依存する。ARQ再送パケット待ち時間が大きいほど回復性能は向上するが、ARQ再送パケット待ち要求時間以上の受信バッファ時間が必要となるので、遅延が増大する恐れがある。
【０１４４】
この「ARQ再送パケット待ち要求時間」は、ユーザ等により指定される伝送品質要求により決定される。
【０１４５】
［ネットワークジッタ対応処理］
受信装置１０３の受信バッファ１３２は、ネットワークジッタ対応処理機構も兼ね備える。受信バッファ１３２は、ユーザ等により指定される伝送品質要求により決定された「ネットワークジッタ対応バッファ要求時間」以上の時間を受信バッファ時間としてセットする。これにより「ネットワークジッタ対応バッファ要求時間」以下のジッタを受けたパケットの同期処理が可能となる。
【０１４６】
［データ伝送全体処理］
次に、伝送システム１００において実行されるデータ伝送処理の全体の流れの例を、図７のフローチャートを参照して説明する。
【０１４７】
受信装置１０３の受信バッファ時間設定部１３８は、入力部１４１および出力部１４２を制御して、ステップＳ１２１において、画像品質要求および伝送品質要求を受け付ける。
【０１４８】
受信バッファ時間設定部１３８は、例えば、出力部１４２のモニタに、図８に示されるようなGUIを表示し、入力部１４１を制御し、そのGUIに基づいて行われるユーザ操作を受け付ける。
【０１４９】
図８は、画像品質要求および伝送品質要求等を受け付けるGUIである要求受付画面の表示例を示す図である。図８に示されるように、要求受付画面２０１には、表示部２０２と要求部２０３とが設けられている。要求部２０３は、ユーザにより入力可能な項目が示される。表示部２０２には、ユーザにより情報が入力された結果が表示される。
【０１５０】
要求部２０３には、例えば、「使用者要求」として、「画質要求」（画像品質要求）や「伝送品質要求」を入力することができることが示されている。例えば、画像品質を指定する場合、ユーザは、「画質要求」を選択し、要求する品質（例えばPSR値等）を入力する。また、例えば、伝送品質を指定する場合、ユーザは、「伝送品質要求」を選択し、要求する品質（例えばQoS制御後パケット損失率等）を入力する。
【０１５１】
なお、要求部２０３においては、ユーザは、受信バッファ時間を指定することもできる。例えば、ユーザが、「受信バッファ時間」を選択し、要求する時間を入力することにより、「受信バッファ時間」として許容される最長の時間が設定される。
【０１５２】
表示部２０２には、このように要求部２０３において入力された情報が反映された各種情報が表示される。
【０１５３】
例えば、表示部２０２には、「ネットワーク状況」として「伝送遅延」、「パケット損失率」、および「ネットワークジッタ」等が表示される。
【０１５４】
また、例えば、表示部２０２には、「処理要求時間」として「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等が表示される。
【０１５５】
さらに、例えば、表示部２０２には、受信バッファ時間として推奨される「推奨受信バッファ時間」が表示される。
【０１５６】
このようなGUIに基づいて要求を入力することにより、ユーザは、画像品質要求、伝送品質要求、および受信バッファ時間等をより容易に設定することができる。
【０１５７】
図７に戻り、画像品質要求や伝送品質要求が受け付けられると、受信バッファ時間設定部１３８は、ステップＳ１２２において受信バッファ時間決定処理を行い、ARQ部１３６や受信バッファ１３２の設定を行ったり、RTCP部１３７を介して、決定した情報等を送信装置１０１に通知したりする。
【０１５８】
送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７を介してこの通知を受け取ると、ステップＳ１０１において、その通知に基づいて受信バッファ時間・処理パラメータ設定処理を行い、符号化部１１１やFEC部１１２の設定を行う。
【０１５９】
設定が終了すると、送信装置１０１の各部は、ステップＳ１０２において、受信装置１０３と連携してデータ伝送（データ送信）を行う。この処理に対応して、受信装置１０３の各部は、ステップＳ１２３において、送信装置１０１と連携してデータ伝送（データ受信）を行う。
【０１６０】
これらのデータ伝送においては、上述した各種処理が適宜行われる。
【０１６１】
以上のように、送信装置１０１および受信装置１０３は、互いに連携し、ユーザ等により指定される画像品質要求や伝送品質要求に応じて、各部の設定を行う。これにより、送信装置１０１および受信装置１０３は、各処理の遅延時間を最適化し、各処理の時間的余裕を画質や伝送品質の向上に利用し、遅延時間上の無駄を低減させることができる。つまり、コンテンツの品質の劣化を抑制することができる。
【０１６２】
［受信バッファ時間決定処理］
次に、図７のステップＳ１２２において実行される受信バッファ時間決定処理の流れの例を図９のフローチャートを参照して説明する。
【０１６３】
受信バッファ時間決定処理が開始されると、受信バッファ時間設定部１３８は、ステップＳ１４１において、ユーザ等からの画像品質要求や伝送品質要求に基づいて、各種遅延時間や待ち時間等を設定する。
【０１６４】
例えば、受信バッファ時間設定部１３８は、画像品質要求や伝送品質要求の設定値から、「可変圧縮符号化遅延時間」として要求される時間である「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち時間」として要求される時間である「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち時間」として要求される時間である「ARQ再送パケット待ち要求時間」、および、「ネットワークジッタ対応バッファ時間」として要求される時間である「ネットワークジッタ対応バッファ要求時間」を計算する。
【０１６５】
従来の方法の場合、これらの値がそのまま設定値として使用されていたが、受信バッファ時間設定部１３８は、これらの値を、その最大値に揃えるように再設定する。受信バッファ時間設定部１３８は、ステップＳ１４２において、以下の式（４）に示されるように、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を「受信バッファ時間」として設定する。
【０１６６】
「受信バッファ時間」＝MAX（「可変圧縮符号化遅延要求時間」，「冗長符号化ブロック受信待ち要求時間」，「ARQ再送パケット待ち要求時間」，「ネットワークジッタ対応バッファ要求時間」）
・・・（４）
【０１６７】
式（４）において、MAX（）は、最大値を計算する関数である。
【０１６８】
「受信バッファ時間」を算出すると、受信バッファ時間設定部１３８は、ステップＳ１４３において、以下の式（５）に示されるように、その「受信バッファ時間」を、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」として設定する。
【０１６９】
「可変圧縮符号化遅延時間」＝「冗長符号化ブロック受信待ち時間」＝「ARQ再送パケット待ち時間」＝「ネットワークジッタ対応バッファ時間」＝「受信バッファ時間」
・・・（５）
【０１７０】
例えば、可変圧縮符号化遅延要求時間２２１、冗長符号化ブロック受信待ち要求時間２２２、ARQ再送パケット待ち要求時間２２３、および、ネットワークジッタ対応バッファ要求時間２２４が、図１０の左に示されるような長さであるとする。
【０１７１】
この場合、可変圧縮符号化遅延要求時間２２１が最も長いので、図１０右に示されるように、受信バッファ時間２４１は、この可変圧縮符号化遅延要求時間２２１と同じ長さに設定される。可変圧縮符号化遅延時間２３１、冗長符号化ブロック受信待ち時間２３２、ARQ再送パケット待ち時間２３３、および、ネットワークジッタ対応バッファ時間２３４は、それぞれ、この受信バッファ時間２４１に揃えられる。
【０１７２】
つまり、この場合、冗長符号化ブロック受信待ち時間２３２、ARQ再送パケット待ち時間２３３、および、ネットワークジッタ対応バッファ時間２３４は、それぞれ、要求された時間よりも長くなるように設定される。
【０１７３】
図９に戻り、以上のように、各時間が設定されると、受信バッファ時間設定部１３８は、ステップＳ１４４において、「ARQ再送パケット待ち時間」を、ARQ部１３６に設定し、再送要求を行うかどうかの判定に使用させる。
【０１７４】
また、ステップＳ１４５において、受信バッファ時間設定部１３８は、「ネットワークジッタ対応バッファ時間」を受信バッファ１３２に設定する。
【０１７５】
さらに、ステップＳ１４６において、受信バッファ時間設定部１３８は、「画像品質要求」、「伝送品質要求」、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック待ち時間」を、例えば、RTCP部１３７を介して、RTCPメッセージとして送信装置１０１へ通知する。
【０１７６】
通知が終了すると、受信バッファ時間設定部１３８は、受信バッファ時間決定処理を終了し、処理を図７のステップＳ１０２に戻し、ステップＳ１０３に処理を進める。
【０１７７】
［受信バッファ時間・処理パラメータ設定処理］
次に、図１１のフローチャートを参照して、図７のステップＳ１０１において実行される受信バッファ時間・処理パラメータ設定処理を説明する。
【０１７８】
受信バッファ時間・処理パラメータ設定処理が開始されると、受信バッファ時間・処理パラメータ設定部１１９は、ステップＳ１６１において、RTCP部１１７を介して、受信装置１０３から供給されるRTCPメッセージに含まれる「画像品質要求」、「伝送品質要求」、「可変圧縮符号化遅延時間」、および「冗長符号化ブロック待ち時間」を取得する。
【０１７９】
ステップＳ１６２において、受信バッファ時間・処理パラメータ設定部１１９は、「可変圧縮符号化遅延時間」を符号化部１１１に設定する。ステップＳ１６３において、受信バッファ時間・処理パラメータ設定部１１９は、「冗長符号化ブロック待ち時間」をFEC部１１２に設定する。
【０１８０】
レート制御部１２１は、ステップＳ１６４において、供給された「画像品質要求」や「可変圧縮符号化遅延時間」を用いて、レート制御パラメータを設定する。例えば、レート制御部１２１は、以下の式（６）を満たすように、エンコーダ想定バッファサイズＢ(byte)を設定する。なお、式（６）において、Bt_codec(sec)は可変圧縮符号化遅延時間を示す。また、Ｒ（bps）はパケットレートを示す。
【０１８１】
Bt_codec＝Ｂ×８／Ｒ ・・・（６）
【０１８２】
FEC部１１２は、ステップＳ１６５において、「伝送品質要求」および「冗長符号化ブロック受信待ち時間」を用いてFECブロックパラメータを設定する。「冗長符号化ブロック待ち時間」は、FECブロックに含まれるパケット全ての平滑化伝送にかかる時間の最大値である。FEC部１１２は、この時間が「冗長符号化ブロック待ち時間」以下となるように、FECブロック毎の元データパケット数を調整する。さらに、FEC部１１２は、例えば、上述した式（３）を満たすように、冗長パケット数ｎ−ｋを設定する。
【０１８３】
ステップＳ１６５の処理が終了すると、受信バッファ時間・処理パラメータ設定部１１９は、受信バッファ時間・処理パラメータ設定処理を終了し、処理を図７のステップＳ１０１に戻し、ステップＳ１０２の処理を行う。
【０１８４】
以上のように各種設定を行うことにより、送信装置１０１および受信装置１０３は、遅延を増大させない程度に、各遅延時間や待ち時間をできるだけ長く確保することができ、その時間的余裕を、画像品質や伝送品質の向上に利用することができる。
【０１８５】
より具体的には、送信装置１０１は、遅延を増大させない程度に、符号化部１１１の「可変圧縮符号化遅延時間」をより長く設定し、エンコーダ想定バッファサイズＢ(byte)をより大きく設定することができる。また、送信装置１０１は、遅延を増大させない程度に、FEC部１１２の「冗長符号化ブロック待ち時間」をより長く設定し、FECブロックや冗長度をより大きく設定することができる。
【０１８６】
受信装置１０３は、遅延を増大させない程度に、ARQ部１３６の「ARQ再送パケット待ち時間」をより長く設定することができる。また、受信装置１０３は、遅延を増大させない程度に、受信バッファ１３２の「ネットワークジッタ対応バッファ時間」をより長く設定することができる。
【０１８７】
以上のように、送信装置１０１および受信装置１０３は、各処理の時間的余裕を活用し、画質や伝送品質の向上に利用することにより、遅延時間上の無駄を低減させることができる。つまり、送信装置１０１および受信装置１０３は、上述したようなデータ伝送に関する各種処理によるコンテンツの品質の劣化を抑制することができる。
【０１８８】
＜２．第２の実施の形態＞
［データ伝送全体処理の他の例］
以上においては、ユーザ等の要求のみにより受信バッファ時間や処理パラメータが決定されるように説明したが、これに限らず、ネットワーク１０２の通信に関する状況に応じて受信バッファ時間や処理パラメータの設定が行われるようにしてもよい。
【０１８９】
その場合、ネットワーク１０２の通信に関する状況（ネットワーク状況情報）は、RTCP部１１７とRTCP部１３７との間で行われるパケットの授受によって観測される。したがって、送信装置１０１と受信装置１０３の構成は、上述した第１の実施の形態（図１）の場合と同様である。
【０１９０】
さらに、このようなネットワーク状況情報の測定を、データ伝送中に繰り返し行い、その最新のネットワーク状況に応じて、受信バッファ時間や処理パラメータの設定が更新されるようにしてもよい。
【０１９１】
この場合も、RTCP部１１７およびRTCP部１３７は、上述した第１の実施の形態において説明した場合と基本的に同様の処理を行う。ただし、この場合、RTCP部１１７は、符号化データの伝送を開始する前に、ネットワーク状況事前計測用のダミーデータを送信する。そのダミーデータは、ネットワーク１０２を介してRTCP部１３７に伝送される。RTCP部１３７は、そのダミーデータを受信し、パケットに記述される送信時の情報と、受信時の状況からネットワーク状況の計測（事前計測）を行う。
【０１９２】
符号化データの伝送開始後においては、RTCP部１３７は、伝送される符号化データのRTPパケットによりネットワーク状況情報の計測を行う。
【０１９３】
この場合のデータ伝送処理の流れの例を図１２のフローチャートを参照して説明する。受信装置１０３の受信バッファ時間設定部１３８が、ステップＳ２２１において、図７のステップＳ１２１の場合と同様に、画像品質要求および伝送品質要求を受け付けると、RTCP部１３７は、ステップＳ２２２において、RTCP部１１７とダミーデータ等の各種データの授受を行い、ネットワーク状況を測定し、そのネットワーク状況情報をRTCP部１１７と共有する。送信装置１０１のRTCP部１１７は、ステップＳ２０１において、このステップＳ２２２の処理に対応する処理を行う。
【０１９４】
ネットワーク状況を測定すると受信装置１０３の受信バッファ時間設定部１３８は、受信バッファ時間決定処理を行う。この処理は、基本的に図９のフローチャートを参照して説明した場合と同様に行われる。
【０１９５】
ただし、受信バッファ時間設定部１３８は、ステップＳ１４１において、画像品質要求と伝送品質要求だけでなく、ステップＳ２２２においてRTCP部１３７より取得したネットワーク状況情報にも基づいて、各種要求時間を算出する。
【０１９６】
例えば、パケット損失率が高い場合、「ARQ再送パケット待ち要求時間」は、回復性能を向上させるような値に設定される。また、例えば、パケット損失率が高い場合、「冗長符号化ブロック受信待ち要求時間」は、式（３）を満たし、指定された冗長度以下に保つ元データパケット数および冗長パケット数に合わせた値に設定される。
【０１９７】
また、「ネットワークジッタ対応バッファ要求時間」は、実際に測定されたネットワークジッタ以上の値に設定される。
【０１９８】
このように設定された要求時間に応じて、各種遅延時間や待機時間等が設定される。送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、ステップＳ２０２において、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、基本的に図１１のフローチャートを参照して説明した場合と同様に行われる。
【０１９９】
つまり、受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７により取得されたネットワーク状況情報も利用して冗長度やFECブロックサイズを決定する。符号化データの伝送開始前において、受信バッファ時間・処理パラメータ設定部１１９は、RTCP部１１７により計測されたネットワーク状況事前計測情報に含まれるパケット損失率pを用い、式（３）を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
【０２００】
各種パラメータの設定が終了すると、受信装置１０３の各部は、ステップＳ２２４において、受信バッファ時間等各種設定を動的に更新しながらデータ伝送を行う受信バッファ動的変更伝送処理を行う。この処理に対応して、送信装置１０１の各部は、ステップＳ２０３において、受信バッファ動的変更伝送処理を行う。
【０２０１】
［受信バッファ動的変更伝送処理］
図１３のフローチャートを参照して、送信装置１０１および受信装置１０３により行われる受信バッファ動的変更伝送処理の流れの例を説明する。
【０２０２】
ステップＳ２４１において、送信装置１０１の各部は、一定時間データ転送を行う。この処理に対応して、受信装置１０３の各部は、ステップＳ２６１において、一定時間データ転送を行う。
【０２０３】
受信装置１０３のRTCP部１３７は、ステップＳ２６２において、RTCP部１１７とデータの送受信を行い、ネットワーク状況を測定し、ネットワーク状況情報を更新する。この処理に対応して、送信装置１０１のRTCP部１１７は、ステップＳ２４２において、ネットワーク状況を測定し、ネットワーク状況情報を更新する。
【０２０４】
ステップＳ２６３において、受信装置１０３の受信バッファ時間設定部１３８は、更新されたネットワーク状況情報に基づいて、受信バッファ時間決定処理を行い、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」等を更新し、その更新された各種要求時間に応じて、「可変圧縮符号化遅延時間」、「冗長符号化ブロック受信待ち時間」、「ARQ再送パケット待ち時間」、および「ネットワークジッタ対応バッファ時間」等の設定を、例えば式（４）や式（５）を用いて更新する。
【０２０５】
この受信バッファ時間決定処理は、図１２のステップＳ２２３の場合と同様に行われる。
【０２０６】
この処理に対応し、ステップＳ２４３において、送信装置１０１の受信バッファ時間・処理パラメータ設定部１１９は、受信バッファ時間・処理パラメータ設定処理を行う。この処理は、図１２のステップＳ２０２の場合と同様に行われる。
【０２０７】
符号化データの伝送開始後の場合、受信バッファ時間・処理パラメータ設定部１１９は、符号化データ伝送を利用してRTCP部１１７により計測されたネットワーク状況情報に含まれるパケット損失率pを用い、式（３）を満たすように、元データパケット数kや冗長パケット数n-kを決定する。
【０２０８】
ステップＳ２４４において、送信装置１０１は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップＳ２４１に戻し、それ以降の処理を実行させる。また、ステップＳ２４４において、伝送を終了すると判定された場合、送信装置１０１による受信バッファ動的変更伝送処理が終了される。
【０２０９】
また、ステップＳ２６４において、受信装置１０３は、伝送を終了するか否かを判定し、伝送を終了すると判定された場合、処理をステップＳ２６１に戻し、それ以降の処理を実行させる。また、ステップＳ２６４において、伝送を終了すると判定された場合、受信装置１０３による受信バッファ動的変更伝送処理が終了される。
【０２１０】
以上のように、ユーザ等からの要求だけでなく、ネットワーク状況にも応じて、パラメータ等の設定を行うようにすることにより、送信装置１０１および受信装置１０３は、より実際の状況に応じてより効率よく画質や伝送品質の設定を行うことができ、遅延時間上の無駄をより低減させることができる。つまり、送信装置１０１および受信装置１０３は、コンテンツの品質の劣化を抑制することができる。
【０２１１】
＜３．第３の実施の形態＞
［伝送システムの構成］
以上においては、送信装置と受信装置が１対１に構成されるシステムについて説明したが、これに限らず、伝送システムを構成する送信装置と受信装置の数は任意である。例えば、複数の送信装置から送信される符号化データを１つの受信装置が受信するようにしてもよい。
【０２１２】
図１４は、その場合の伝送システムの構成例を示す図である。図１４に示される伝送システム３００は、基本的に伝送システム１００と同様のシステムであるが、伝送システム１００の場合と異なり、送信装置を複数有する（送信装置１０１−１乃至送信装置１０１−Ｎ（Ｎは２以上の整数））。
【０２１３】
送信装置１０１−１乃至送信装置１０１−Ｎは、それぞれ、上述した送信装置１０１と同様の構成を有し、同様の処理を行う。送信装置１０１−１乃至送信装置１０１−Ｎを互いに区別して説明する必要が無い場合、単に送信装置１０１と称する。
【０２１４】
伝送システム３００は、受信装置１０３の代わりに、各送信装置１０１から送信されるRTPパケットを受信する１つの受信装置３０３を有する。
【０２１５】
図１４に示されるように、受信装置３０３は、伝送部３１１、基準信号同期部３１２、受信部３１３−１乃至受信部３１３−Ｎ、統合受信バッファ時間調整部３１４、および合成部３１５を有する。
【０２１６】
伝送部３１１は、各送信装置１０１と通信を行い、基準信号同期部３１２や受信部３１３−１乃至受信部３１３−Ｎから供給される情報を送信したり、各送信装置１０１から供給される情報を受信し、基準信号同期部３１２や受信部３１３−１乃至受信部３１３−Ｎに供給したりする。
【０２１７】
基準信号同期部３１２は、送信装置１０１の基準信号同期部１１５と通信を行い、基準信号の同期をとる。同期がとられた基準信号は、受信部３１３−１乃至受信部３１３−Ｎに供給される。
【０２１８】
このように、送信装置１０１が複数存在する場合、例えば、受信装置３０３の基準信号同期部３１２がマスタとなり、全ての送信装置１０１が受信装置３０３と同期を取ることにより結果的に全ての送信装置１０１および受信装置３０３の同期を取ることができる。
【０２１９】
受信部３１３−１乃至受信部３１３−Ｎは、それぞれ、送信装置１０１−１乃至送信装置１０１−Ｎに対応し、対応する送信装置１０１から供給されたRTPパケットを受信し、復号してビデオデータを出力する。以下において、受信部３１３−１乃至受信部３１３−Ｎを互いに区別して説明する必要が無い場合、単に、受信部３１３と称する。つまり、受信部３１３は、送信装置１０１以上の数が予め用意される。換言するに、受信装置３０３は、内蔵する受信部３１３の数以下の送信装置１０１から送信されるパケットを受信することができる。
【０２２０】
統合受信バッファ時間調整部３１４は、各受信部３１３の受信バッファ時間を揃える。合成部３１５は、各受信部３１３から出力されるビデオデータを合成し、合成されたビデオデータを、受信装置３０３のビデオ出力端子「ビデオOUT」から出力する。
【０２２１】
［受信部］
図１５は、受信部３１３の主な構成例を示すブロック図である。図１５に示されるように、受信部３１３は、上述した受信装置１０３と基本的に同様の構成を有する。ただし、受信部３１３は、受信装置１０３が有する基準信号同期部１３９を有さない。また、受信部３１３は、受信装置１０３が有する受信バッファ時間設定部１３８の代わりに、受信バッファ時間設定部３３８を有する。
【０２２２】
メディア同期部１４０は、受信部３１３の外部の基準信号同期部３１２より供給される基準信号、すなわち、各送信装置１０１と各受信部３１３において同期がとれた基準信号を用いて、受信バッファ１３２や復号部１３５におけるRTPパケットの処理タイミングを制御する。
【０２２３】
受信バッファ時間設定部３３８は、受信バッファ時間設定部１３８と同様に、ユーザ等により設定された画像品質要求や伝送品質要求、並びに、RTCP部１３７により収集されたネットワーク状況情報等に基づいて、各種時間やパラメータ等の設定を行う。
【０２２４】
なお、受信バッファ時間設定部３３８が設定した各種時間は、後述するように、統合受信バッファ時間調整部３１４により、受信部３１３間で調整される。
【０２２５】
また、入力部１４１および出力部１４２は、各受信部３１３で共有するようにしてもよい。例えば、ユーザが、どの受信部３１３に対して画像品質要求や伝送品質要求を入力する場合であっても、同じ入力部１４１および出力部１４２を用いるようにするようにしてもよい。画像品質要求や伝送品質要求の設定対象とする受信部３１３の切り替え制御方法は任意である。例えばGUIにそのような切り替えボタンを設けるようにしてもよい。また、ユーザが、複数の受信部３１３に対して、画像品質要求や伝送品質要求の設定を一度に行うことができるようにしてもよい。
【０２２６】
［データ伝送全体処理］
図１６のフローチャートを参照して、この場合のデータ伝送処理の流れの例を説明する。
【０２２７】
ステップＳ３２１において、受信装置３０３の各受信部３１３の受信バッファ時間設定部３３８は、画像品質要求や伝送品質要求を受け付ける。ステップＳ３２２において、受信装置３０３の各受信部３１３のRTCP部１３７は、それぞれ、自分自身が対応する送信装置１０１のRTCP部１１７と通信を行い、ネットワーク状況を測定し、ネットワーク状況情報を生成する。
【０２２８】
この処理に対応して、各送信装置１０１のRTCP部１１７は、ネットワーク状況の測定を行い、ネットワーク状況情報を取得する。
【０２２９】
これらの情報を基に、ステップＳ３２３において、受信装置３０３の各受信部３１３の受信バッファ時間設定部３３８は、受信バッファ時間の仮設定を行う仮受信バッファ時間決定処理を行う。
【０２３０】
各受信部３１３において仮受信バッファ時間が決定されると、ステップＳ３２４において、統合受信バッファ時間調整部３１４と各受信部３１３の受信バッファ時間設定部３３８は、連携して、統合受信バッファ時間決定処理を行い、各仮受信バッファ時間を調整した受信バッファ時間を設定する。
【０２３１】
ステップＳ３２５において、伝送部３１１は、以上の処理により得られた各種情報（例えば、画像品質要求、伝送品質要求、可変圧縮符号化遅延時間、および冗長符号化ブロック受信待ち時間等）を、各送信装置１０１に通知する。各送信装置１０１は、ステップＳ３０２において、この通知を取得し、受信バッファ時間・処理パラメータ設定処理を行う。
【０２３２】
各送信装置１０１および受信装置３０３は、ステップＳ３０３およびステップＳ３２６において、受信バッファ動的変更処理を行い、最新のネットワーク状況を測定し、その状況に基づいて各種設定を更新しながらデータ伝送を行う。
【０２３３】
なお、以上においては、受信バッファ時間を、画像品質要求、伝送品質要求、およびネットワーク状況に基づいて設定するように説明したが、これに限らず、第１の実施の形態のように、画像品質要求と伝送品質要求のみに基づいて受信バッファ時間を設定するようにしてもよい。その場合、ステップＳ３２２やステップＳ３０１の処理が省略される。
【０２３４】
［仮受信バッファ時間決定処理］
次に、図１７のフローチャートを参照して、仮受信バッファ時間決定処理の流れの例を説明する。
【０２３５】
ステップＳ３４１において、受信装置３０３は、送信装置１０１と対応し、データ伝送に使用する受信部３１３の内、未処理のものの中から、処理対象とする受信部３１３を選択する。その処理対象の受信部３１３の受信バッファ時間設定部３３８は、ステップＳ３４２において、画像品質要求、伝送品質要求、およびネットワーク状況情報等に基づいて、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」を算出する。
【０２３６】
また、受信バッファ時間設定部３３８は、ステップＳ３４３において、「可変圧縮符号化遅延要求時間」、「冗長符号化ブロック受信待ち要求時間」、「ARQ再送パケット待ち要求時間」、および「ネットワークジッタ対応バッファ要求時間」の最大値を仮受信バッファ時間として設定する。
【０２３７】
ステップＳ３４４において、受信装置３０３は、全ての受信部３１３に対して処理を行ったか否かを判定し、未処理の受信部３１３が存在すると判定した場合、処理をステップＳ３４１に戻し、新たな受信部３１３を処理対象として選択し、それ以降の処理を繰り返す。
【０２３８】
また、ステップＳ３４４において、データ伝送に用いる全ての受信部３１３を処理したと判定された場合、受信装置３０３は、仮受信バッファ時間決定処理を終了し、処理を図１６のステップＳ３２３に戻し、ステップＳ３２４の処理を行う。
【０２３９】
［統合受信バッファ時間決定処理］
次に、図１６のステップＳ３２４において実行される統合受信バッファ時間決定処理の流れの例を、図１８のフローチャートを参照して説明する。
【０２４０】
ステップＳ３６１において、統合受信バッファ時間調整部３１４は、各受信部３１３において設定された仮受信バッファ時間を取得し、以下の式（７）に示されるように、各受信部３１３について、仮受信バッファ時間と伝送遅延の和を求め、その和の最大値を統合受信バッファ時間に設定する。
【０２４１】
統合受信バッファ時間＝MAX（仮受信バッファ時間１＋伝送遅延時間１，仮受信バッファ時間２＋伝送遅延時間２，・・・，仮受信バッファ時間N＋伝送遅延時間N）
・・・（７）
【０２４２】
例えば、図１９の上部に示されるように、送信装置１０１において行われる処理による遅延時間を送信装置処理遅延３５１とし、ネットワーク１０２を介したデータ伝送による遅延時間を伝送遅延３５２とし、受信装置３０３に設定される仮の受信バッファ時間を仮受信バッファ時間３５３とする。
【０２４３】
図１９の上部に示されるように、送信装置１０１−１の送信装置処理遅延３５１を送信装置処理遅延３５１−１とし、送信装置１０１−１の伝送遅延３５２を伝送遅延３５２−１とし、送信装置１０１−１の仮受信バッファ時間３５３を仮受信バッファ時間３５３−１とする。
【０２４４】
また、送信装置１０１−２の送信装置処理遅延３５１を送信装置処理遅延３５１−２とし、送信装置１０１−２の伝送遅延３５２を伝送遅延３５２−２とし、送信装置１０１−２の仮受信バッファ時間３５３を仮受信バッファ時間３５３−２とする。
【０２４５】
以下、各送信装置１０１に対して同様にして、送信装置１０１−Ｎの送信装置処理遅延３５１を送信装置処理遅延３５１−Ｎとし、送信装置１０１−Ｎの伝送遅延３５２を伝送遅延３５２−Ｎとし、送信装置１０１−Ｎの仮受信バッファ時間３５３を仮受信バッファ時間３５３−Ｎとする。
【０２４６】
なお、説明の便宜上、送信装置処理遅延３５１−１乃至送信装置処理遅延３５１−Ｎは、互いに同じ長さとする。
【０２４７】
この場合、仮受信バッファ時間と伝送遅延の和は、送信装置１０１−１のものが最大であるので、その和が統合受信バッファ時間に設定される。
【０２４８】
図１８に戻り、ステップＳ３６２において、統合受信バッファ時間調整部３１４は、いずれかの送信装置１０１に対応し、データ伝送に用いる受信部３１３の内、未処理のものの中から、処理対象とする受信部３１３を選択する。
【０２４９】
ステップＳ３６３において、その処理対象に選択された受信部３１３の受信バッファ時間設定部３３８は、以下の式（８）に示されるように、ステップＳ３６１において設定された統合受信バッファ時間と伝送遅延との差を受信バッファ時間に設定する。
【０２５０】
受信バッファ時間Ｋ＝統合受信バッファ時間−伝送遅延Ｋ ・・・（８）
【０２５１】
図１９の例の場合、送信装置１０１−１の伝送遅延３５２−１と仮受信バッファ時間３５３−１の和が最大であるので、式（７）および式（８）により、送信装置１０１−１の受信バッファ時間３５４−１は、図１９の下段に示されるように、仮受信バッファ時間３５３−１と同一に設定される。
【０２５２】
送信装置１０１−２の受信バッファ時間３５４−２、・・・、送信装置１０１−Ｎの受信バッファ時間３５４−Ｎも、それぞれ、同様に算出される。その結果、図１９の下段に示されるように、各送信装置１０１の送信装置処理遅延３５１、伝送遅延３５２、および受信バッファ時間３５４の和は、互いに同一となる。
【０２５３】
つまり、各送信装置１０１の受信バッファ時間３５４は、遅延が増大しない程度に、より長くなるように設定される。
【０２５４】
図１８に戻り、ステップＳ３６４において、処理対象の受信部３１３の受信バッファ時間設定部３３８は、式（５）のように、ステップＳ３６３において設定した受信バッファ時間を、可変圧縮符号化遅延時間、冗長符号化ブロック受信待ち時間、ARQ再送パケット待ち時間、およびネットワークジッタ対応バッファ時間として設定する。
【０２５５】
これにより、各遅延時間や待ち時間が、遅延が増大しない程度に、より長くなるように設定される。
【０２５６】
ステップＳ３６５において、受信バッファ時間設定部３３８は、ARQ部１３６に、ARQ再送パケット待ち時間を設定する。ステップＳ３６６において、受信バッファ時間設定部３３８は、受信バッファ１３２にネットワークジッタ対応バッファ時間を設定する。
【０２５７】
ステップＳ３６７において、受信装置３０３は、データ伝送に用いられる全ての受信部３１３に対して処理を行ったか否かを判定し、未処理の受信部３１３が存在すると判定された場合、処理をステップＳ３６２に戻し、新たな未処理の受信部３１３を選択し、その受信部３１３について、それ以降の処理を繰り返す。
【０２５８】
また、ステップＳ３６７において、全ての受信部３１３に対して処理を行ったと判定された場合、受信装置３０３は、統合受信バッファ時間決定処理を終了し、処理を図１６のステップＳ３２４に戻し、ステップＳ３２５以降の処理を実行する。
【０２５９】
なお、図１６のステップＳ３０２において実行される各送信装置１０１による受信バッファ時間・処理パラメータ設定処理は、図１１のフローチャートを参照して説明した場合と同様に行われる。
【０２６０】
［受信バッファ動的変更伝送処理］
次に、図１６のステップＳ３０３およびステップＳ３２６において実行される受信バッファ動的変更伝送処理の流れの例を図２０のフローチャートを参照して説明する。
【０２６１】
なお、この受信バッファ動的変更伝送処理は、各送信装置１０１と、それに対応する受信部３１３との間で行われる。
【０２６２】
この場合も基本的に図１３を参照して説明した場合と同様に行われるが、図１３の例の場合、受信装置１０３がステップＳ２６３において受信バッファ時間決定処理を行うのに対し、図２０の例の場合、受信装置３０３（受信部３１３）は、ステップＳ４０３において仮受信バッファ時間決定処理を行い、ステップＳ４０４において統合受信バッファ時間決定処理を行い、ステップＳ４０５において、以上の処理により得られた各種情報（例えば、画像品質要求、伝送品質要求、可変圧縮符号化遅延時間、および冗長符号化ブロック受信待ち時間等）を、対応する送信装置１０１に通知する。
【０２６３】
つまり、図１６のステップＳ３２３乃至ステップＳ３２５の処理、すなわち、データ伝送を開始する前と同様の処理が行われる。
【０２６４】
このようにして、送信装置１０１および受信装置３０３は、第２の実施の形態の場合と同様に、最新のネットワーク状況に基づいて各種設定を更新することにより、各処理の時間的余裕を画質や伝送品質の向上により有効に利用することができるようにし、遅延時間上の無駄をより低減させることができる。つまり、コンテンツの品質の劣化をより抑制することができる。
【０２６５】
なお、ユーザ等からの要求のみに基づいて各種設定を行う場合、この受信バッファ動的変更伝送処理は省略される。
【０２６６】
以上のように、伝送システム１００および伝送システム３００は、データ伝送に関する各処理に対して、受信装置において設定される遅延時間や待機時間を、その最大値に揃えることにより、遅延時間を増大させない程度に各処理に時間的余裕を設け、その時間的余裕を使って画質や伝送品質を向上させるように、各処理のパラメータの設定を行う。
【０２６７】
このようにすることにより、伝送システム１００および伝送システム３００は、コンテンツの品質の劣化を抑制することができる。
【０２６８】
例えば、ユーザ等による画質要求、伝送品質要求、およびネットワーク状況等により決定される受信バッファ時間を有効に活用し、遅延時間を増加させることなく、映像画質や伝送品質を最大限向上させることができる。
【０２６９】
また、可変圧縮符号化遅延時間が処理遅延時間中最大値であり、この値を受信バッファ時間として設定した場合、冗長符号化処理において冗長符号化ブロックを大きく取り、冗長符号化ブロック受信待ち時間を受信バッファ時間と同等まで大きくすることにより、遅延時間を増加させずにバースト損失耐性を向上させることが可能となる。
【０２７０】
さらに、ARQ再送パケット待ち要求時間、ネットワークジッタ対応バッファ要求時間も同様に大きくすることにより、それぞれ、損失回復性能の向上やネットワークジッタ許容値の向上を行うことができる。
【０２７１】
また、冗長符号化ブロック受信待ち時間が処理遅延時間中最大であった場合、可変圧縮符号化遅延時間を受信バッファ時間と同等大きく設定することにより、遅延時間を増加させずに画質を向上させる事ができる。
【０２７２】
複数の送信装置からの伝送を受信装置において同期処理する場合、複数の符号化データの同期処理が可能となるように、受信バッファ時間の調整を行い、調整後の受信バッファ時間に合わせて実際の圧縮符号化・復号処理時間やQoS制御処理時間を受信バッファ時間と同一値以下となるように処理パラメータを調整することにより、複数符号化データの同期処理のために設定した使用者の画質要求、伝送品質要求、およびネットワーク状況等から指定される以上に設定された受信バッファ時間を有効に活用し、遅延時間を増加させることなく、映像画質や伝送品質を最大限向上させることができる。
【０２７３】
なお、以上においては、伝送するビデオデータを符号化するように説明したが、これに限らず、非圧縮のまま伝送するようにしてもよい。
【０２７４】
＜４．第４の実施の形態＞
［パーソナルコンピュータ］
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。この場合、例えば、図２１に示されるようなパーソナルコンピュータとして構成されるようにしてもよい。
【０２７５】
図２１において、パーソナルコンピュータ４００のCPU（Central Processing Unit）４０１は、ROM（Read Only Memory）４０２に記憶されているプログラム、または記憶部４１３からRAM（Random Access Memory）４０３にロードされたプログラムに従って各種の処理を実行する。RAM４０３にはまた、CPU４０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２７６】
CPU４０１、ROM４０２、およびRAM４０３は、バス４０４を介して相互に接続されている。このバス４０４にはまた、入出力インタフェース４１０も接続されている。
【０２７７】
入出力インタフェース４１０には、キーボード、マウスなどよりなる入力部４１１、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイ、並びにスピーカなどよりなる出力部４１２、ハードディスクなどより構成される記憶部４１３、モデムなどより構成される通信部４１４が接続されている。通信部４１４は、インターネットを含むネットワークを介しての通信処理を行う。
【０２７８】
入出力インタフェース４１０にはまた、必要に応じてドライブ４１５が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア４２１が適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部４１３にインストールされる。
【０２７９】
上述した一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、ネットワークや記録媒体からインストールされる。
【０２８０】
この記録媒体は、例えば、図２１に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM（Compact Disc - Read Only Memory）,DVD（Digital Versatile Disc）を含む）、光磁気ディスク（MD（Mini Disc）を含む）、若しくは半導体メモリなどよりなるリムーバブルメディア４２１により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM４０２や、記憶部４１３に含まれるハードディスクなどで構成される。
【０２８１】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０２８２】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２８３】
また、本明細書において、システムとは、複数のデバイス（装置）により構成される装置全体を表すものである。
【０２８４】
また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０２８５】
１００ 伝送システム， １０１ 送信装置， １０２ ネットワーク， １０３ 受信装置， １１１ 符号化部， １１２ FEC部， １１３ RTP部， １１４ 平滑化部， １１５ 基準信号同期部， １１６ メディア同期部， １１７ RTCP部， １１８ ARQ部， １１９ 受信バッファ時間・処理パラメータ設定部， １２１ レート制御部， １３１ 受信部， １３２ 受信バッファ， １３３ RTP部， １３４ FEC部， １３５ 復号部， １３６ ARQ部， １３７ RTCP部， １３８ 受信バッファ時間設定部， １３９ 基準信号同期部， １４０ メディア同期部， １４１ 入力部， １４２ 出力部， ３００ 伝送システム， ３０３ 受信装置， ３１１ 伝送路， ３１２ 基準信号同期部， ３１３ 受信部， ３１４ 統合受信バッファ時間調整部， ３１５ 合成部， ３３８ 受信バッファ時間設定部
【特許請求の範囲】
【請求項１】
データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段と、
前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段と
を備える情報処理装置。
【請求項２】
前記遅延時間は、前記データ伝送のQoS制御処理時間であり、
前記調整手段は、前記QoS制御処理時間として要求されるQoS制御処理要求時間のうち、最長のQoS制御処理要求時間、若しくはそれ以上の所定の時間に合わせるように、各遅延時間の長さを調整する
請求項１に記載の情報処理装置。
【請求項３】
前記QoS制御処理時間は、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を含む
請求項２に記載の情報処理装置。
【請求項４】
前記設定手段は、
前記再送パケット待ち時間を、前記パケットの再送処理を行う再送処理部に設定し、
前記ネットワークジッタ対応バッファ時間を、伝送された前記データを一時的に保持する保持部に設定する
請求項３に記載の情報処理装置。
【請求項５】
前記データ伝送における伝送品質に関する要求である伝送品質要求、および、前記冗長符号化ブロック受信待ち時間を用いて、前記データ送信側のQoS制御処理のパラメータ設定を行うパラメータ設定手段をさらに備える
請求項３に記載の情報処理装置。
【請求項６】
前記データは伝送元において符号化され、得られた符号化データが伝送され、伝送先において前記符号化データが復号され、
前記遅延時間は、前記符号化においてレート制御されて生成された前記符号化データを平滑化伝送する際に必要な可変圧縮符号化遅延要求時間を含み、
前記データの画質に関する要求である画像品質要求、および、前記可変圧縮符号化遅延要求時間を用いて、前記符号化のバッファサイズを含む符号化パラメータの設定を行うパラメータ設定手段をさらに備える
請求項３に記載の情報処理装置。
【請求項７】
前記データの画質に関する要求である画像品質要求、および、前記データ伝送における伝送品質に関する要求である伝送品質要求を受け付ける受付手段をさらに備え、
前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、各遅延時間として要求される遅延要求時間を設定する
請求項１に記載の情報処理装置。
【請求項８】
前記受付手段により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力手段をさらに備える
請求項７に記載の情報処理装置。
【請求項９】
複数の送信装置から１つの受信装置に向けて行われる前記データ伝送において、
前記調整手段は、前記送信装置毎に前記遅延時間の調整を行い、さらに、各送信装置間で、それぞれの前記データ伝送全体の遅延時間が揃うように、前記遅延時間の調整を行う
請求項１に記載の情報処理装置。
【請求項１０】
情報処理装置の情報処理方法であって、
前記情報処理装置の調整手段が、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整し、
前記情報処理装置の設定手段が、長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する
情報処理方法。
【請求項１１】
データ伝送を行うコンピュータを、
データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段、
前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段
として機能させるためのプログラム。
【請求項１】
データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段と、
前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段と
を備える情報処理装置。
【請求項２】
前記遅延時間は、前記データ伝送のQoS制御処理時間であり、
前記調整手段は、前記QoS制御処理時間として要求されるQoS制御処理要求時間のうち、最長のQoS制御処理要求時間、若しくはそれ以上の所定の時間に合わせるように、各遅延時間の長さを調整する
請求項１に記載の情報処理装置。
【請求項３】
前記QoS制御処理時間は、冗長符号化ブロックの先頭パケットから末尾のパケットを受信するまでの時間である冗長符号化ブロック受信待ち時間、再送パケットを待つ時間である再送パケット待ち時間、およびネットワークジッタを吸収するためのネットワークジッタ対応バッファ時間を含む
請求項２に記載の情報処理装置。
【請求項４】
前記設定手段は、
前記再送パケット待ち時間を、前記パケットの再送処理を行う再送処理部に設定し、
前記ネットワークジッタ対応バッファ時間を、伝送された前記データを一時的に保持する保持部に設定する
請求項３に記載の情報処理装置。
【請求項５】
前記データ伝送における伝送品質に関する要求である伝送品質要求、および、前記冗長符号化ブロック受信待ち時間を用いて、前記データ送信側のQoS制御処理のパラメータ設定を行うパラメータ設定手段をさらに備える
請求項３に記載の情報処理装置。
【請求項６】
前記データは伝送元において符号化され、得られた符号化データが伝送され、伝送先において前記符号化データが復号され、
前記遅延時間は、前記符号化においてレート制御されて生成された前記符号化データを平滑化伝送する際に必要な可変圧縮符号化遅延要求時間を含み、
前記データの画質に関する要求である画像品質要求、および、前記可変圧縮符号化遅延要求時間を用いて、前記符号化のバッファサイズを含む符号化パラメータの設定を行うパラメータ設定手段をさらに備える
請求項３に記載の情報処理装置。
【請求項７】
前記データの画質に関する要求である画像品質要求、および、前記データ伝送における伝送品質に関する要求である伝送品質要求を受け付ける受付手段をさらに備え、
前記調整手段は、前記受付手段により受け付けられた前記画像品質要求および前記伝送品質要求に基づいて、各遅延時間として要求される遅延要求時間を設定する
請求項１に記載の情報処理装置。
【請求項８】
前記受付手段により受け付けられる前記画像品質要求および前記伝送品質要求の入力を補助するGUIを表示する出力手段をさらに備える
請求項７に記載の情報処理装置。
【請求項９】
複数の送信装置から１つの受信装置に向けて行われる前記データ伝送において、
前記調整手段は、前記送信装置毎に前記遅延時間の調整を行い、さらに、各送信装置間で、それぞれの前記データ伝送全体の遅延時間が揃うように、前記遅延時間の調整を行う
請求項１に記載の情報処理装置。
【請求項１０】
情報処理装置の情報処理方法であって、
前記情報処理装置の調整手段が、データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整し、
前記情報処理装置の設定手段が、長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する
情報処理方法。
【請求項１１】
データ伝送を行うコンピュータを、
データ伝送を遅延させる遅延時間であって、前記データ伝送に関する互いに異なる複数の遅延要素についての遅延時間のそれぞれの長さを、複数の前記遅延時間の内、最長の遅延時間、若しくはそれ以上の所定の時間に合わせるように調整する調整手段、
前記調整手段により長さが調整された複数の前記遅延時間のそれぞれを、前記データ伝送に関する処理を行う処理部に設定する設定手段
として機能させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１２−４４２５２（Ｐ２０１２−４４２５２Ａ）
【公開日】平成２４年３月１日（２０１２．３．１）
【国際特許分類】
【出願番号】特願２０１０−１８０９４５（Ｐ２０１０−１８０９４５）
【出願日】平成２２年８月１２日（２０１０．８．１２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成２４年３月１日（２０１２．３．１）
【国際特許分類】
【出願日】平成２２年８月１２日（２０１０．８．１２）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]