JP4936542B2 - 通信制御装置、通信制御方法、及びコンピュータプログラム - Google Patents

Description

本発明は、通信制御装置、通信制御方法、及びコンピュータプログラムに関し、特に、パケット通信を行うために用いて好適なものである。

近年、通信システムの発達により、比較的大きなデータ通信帯域が必要となる動画像データを、インターネット等の通信回線を通して受信して視聴者に視聴させることが一般に行われるようになってきている。
このような動画像データの送信、特にライブ映像等のリアルタイム性を必要とする動画像データの長時間にわたる送信のために、ＲＴＰと呼ばれるプロトコルを用いるのが一般的となっている。ＲＴＰは、ＩＥＴＦによりＲＦＣ1889及びＲＦＣ1890として定義された、音声や動画像等をリアルタイムでデータ転送するためのプロトコルである。尚、ＲＴＰは、A Transport Protocol for Real-Time Applicationsの略である。
本明細書では、例えばＲＴＰのようなプロトコルを用いて送信する音声や動画像等のデータを、必要に応じて、ストリーム或いはストリームデータと呼ぶことにする。

一般的に、ＲＴＰによる通信に代表されるリアルタイム通信においては、必ずしもデータの信頼性が高いとは言えないが、比較的単純に通信速度の改善が期待できるＵＤＰ／ＩＰ等の低層プロトコルが利用されている。ＲＴＰにおいては、これを強く想定したものとなっている。
このようなＵＤＰ／ＩＰ等のプロトコルを用いた通信は、リアルタイム性には優れているものの、その性質上、パケットロス等のエラーが発生しやすいという問題がある。もし、エラーが発生すれば、動画像の一部が欠落するといった現象が発生する可能性が高い。このため、様々な工夫がなされている。例えば、圧縮符号化された動画像データに対し、符号化時点でエラーの波及する範囲を限定する仕組みを組み込んだり、一度発生したエラーに対して再生表示する際の動画像の欠落を目立たなくしたりするといったことが実際に行われている。
また、通信の側面からは、より信頼性の高い通信回線が提案され、特定条件下では、エラー率はかなり低いものとなってきている。

一方、エラーが発生する状況においては、そのエラーを抑制させる事も重要な課題となっている。
従来、パケットロス等のエラーの発生を抑制させる技術として、次のような技術が提案されている（特許文献１を参照）。すなわち、パケットの送信タイミングを遅延させることで、非常に短い送信間隔でパケットが送出されることを抑制し、ネットワーク経路のルーター等におけるバッファのデータが溢れることによるデータ損失を少なくする技術が提案されている。

特開２００２−７７２６０号公報

しかしながら、所定の時間空けて（所定の送信間隔で）パケットを送信する場合、一定時間の送信レート、或いは一定時間に送信するパケットの数によっては、ストリームを構成する動画像データのフレームレート内での送信が行えない場合がある。前述した従来の技術では、このような場合等に対する考慮がなされておらず、伝送エラーが生じ得るという問題点があった。
本発明は、このような問題点に鑑みてなされたものであり、動画像データの伝送エラーを低減することを目的とする。

本発明の通信制御装置は、受信装置へ動画データのパケットを送信する通信制御装置であって、前記受信装置へ送信する動画データを取得する取得手段と、前記動画データを再生中の前記受信装置における前記動画データのパケットの到着時間を遅延させられる遅延時間情報を算出する算出手段と、前記算出された遅延時間情報に応じて、所定の圧縮形式のフレームのパケットの送信間隔が、当該フレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなるように、前記動画データのパケットの送信間隔を決定する決定手段と、前記決定手段により決定された送信間隔に応じたタイミングで、前記動画データのパケットを送信する送信手段とを備えることを特徴とする。

本発明の通信制御方法は、受信装置へ動画データのパケットを送信する通信制御装置が行う通信制御方法であって、前記受信装置へ送信する動画データを取得する取得ステップと、前記動画データを再生中の前記受信装置における前記動画データのパケットの到着時間を遅延させられる遅延時間情報を算出する算出ステップと、前記算出された遅延時間情報に応じて、所定の圧縮形式のフレームのパケットの送信間隔が、当該フレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなるように、前記動画データのパケットの送信間隔を決定する決定ステップと、前記決定ステップにより決定された送信間隔に応じたタイミングで、前記動画データのパケットを送信する送信ステップとを備えることを特徴とする。

本発明のコンピュータプログラムは、受信装置へ動画データのパケットを送信するコンピュータに、前記受信装置へ送信する動画データを取得する取得ステップと、前記動画データを再生中の前記受信装置における前記動画データのパケットの到着時間を遅延させられる遅延時間情報を算出する算出ステップと、前記算出された遅延時間情報に応じて、所定の圧縮形式のフレームのパケットの送信間隔が、当該フレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなるように、前記動画データのパケットの送信間隔を決定する決定ステップと、前記決定ステップにより決定された送信間隔に応じたタイミングで、前記動画データのパケット送信する送信ステップとを実行させることを特徴とする。

本発明によれば、送信するデータの特性や、通信の特性に適したタイミングでパケットを送信することができ、パケットロス等の伝送エラーを低減することができる。

＜第１の実施形態＞
以下に、図面を参照しながら、本発明の第１の実施形態について説明する。尚、以下の実施形態では、通信制御装置の一例である送信装置が、通信機能を備えたネットワークカメラとしての機能を有する場合を例に挙げて説明を行う。
図１は、送信装置のシステム構成の一例を示すブロック図である。
図１において、ストリーム取得部１０１は、撮像部を備え、動画像データ及び音声データを含むストリームデータを送信用のデータとして取得する。尚、ストリームデータは、必ずしもこのようなものでなくてもよい。映像データ、音声データ、及びグラフィックデータの少なくとも何れか１つを含むマルチメディアデータであれば、どのようなストリームデータであってもよい。

ストリーム取得部１０１で取得されたストリームデータは、ストリーム符号化部１０２において符号化される。符号化されたストリームデータは、パケット化部１０３において、通信に適したサイズにパケット化される。パケット化されたストリームデータは、一旦、バッファメモリ１０８に保管される。尚、以下の説明では、パケット化されたストリームデータを、必要に応じてパケットデータ又はパケットと称する。

ストリーム特性情報取得部１０６と通信特性情報取得部１０７は、夫々ストリーム特性情報と通信特性情報を取得する。本実施形態では、ストリーム特性情報取得部１０６は、ストリーム符号化部１０２で符号化されたストリームデータの特性を示すストリーム特性情報として、ビットレートと、フレームレートと、ストリームデータを構成する各フレームのサイズ等を取得する。

ストリーム特性情報は、ストリームデータの特性を表すものであれば、どのような情報であっても、ストリーム特性情報として採用することができる。例えば、ストリーム特性情報として、ストリームデータ全体のサイズ、ストリームデータ全体の復号化時間又は再生時間、及び所定の処理時間毎のストリームデータのサイズ等を採用することもできる。ここで、所定の処理時間としては、例えば、フレームレートに基づく時間が挙げられ、より具体的には、ストリームデータにおける１フレーム当たりの復号化時間又は再生時間（フレームレートの逆数）が挙げられる。
また、ストリーム特性情報として、所定の処理単位での復号化時間又は再生時間、及び所定の処理単位毎のストリームデータのサイズを採用することができる。更に、所定の処理単位内で最も大きなフレームのサイズ、及び所定の処理単位に含まれるフレームにおける１フレーム当たりの復号化時間又は再生時間をストリーム特性情報として採用することもできる。所定の処理単位には、ストリームデータを構成する１つ以上のフレームが含まれており、例えば、後述するＧＯＰやＧＯＶを所定の処理単位として採用することができる。
以上のように本実施形態では、ストリーム特性情報によりデータ特性情報が実現される。

また、通信特性情報取得部１０７は、ストリームデータ以外の特性であって、ストリームデータを送信する際の通信の特性を示す通信特性情報として、次のような情報を取得する。即ち、通信経路の有効帯域や、送信装置のシステムを制御するクロックの精度（パケットの送信処理を行うにあたって参照されるクロックの精度）等を取得する。通信特性情報は、ストリームデータを送受信する際の通信の特性を表すものであれば、どのような情報であっても、通信特性情報として採用することができる。例えば、通信特性情報として、パケットのサイズ、通信に供することの出来る通信速度、ストリームデータを復号化又は再生する処理を行うにあたって許容される遅延時間を採用することができる。更に、ストリームデータを復号化又は再生する処理を行うためのバッファのサイズ、及び通信経路で発生するエラーの発生率を通信特性情報として採用することができる。尚、パケットのサイズは、ストリーム特性情報として扱うこともできる。

次に、スケジューリング部１０４は、ストリーム特性情報と通信特性情報とに基づいて、バッファメモリ１０８に一旦保管されたパケットデータの送信タイミングを制御する。送信部１０５は、スケジューリング部１０４で制御された送信タイミングの情報に従って、バッファメモリ１０８からパケットデータを読み出し、ネットワークへ送信する。

システムコントローラ１１０は、ストリームデータの取得からパケットを送信するまでの一連の処理において、図１に示したシステムの統括的な制御を行う。メインメモリ１０９は、システムコントローラ１１０が制御を行う上で必要に応じて記憶領域を提供する。

図２は、ストリームデータを取得してからパケットデータを送信するまでの送信装置の構成の一例を、データの流れと共に示すブロック図である。
前述したように、ストリーム符号化部１０２は、ストリーム取得部１０１から入力されたストリームデータ２１０を符号化する。パケット化部１０３は、符号化されたストリームデータを、通信に適したサイズに分割し、分割したストリームデータの各々に適切なヘッダ情報を付加してパケット２１１を生成する。
パケット２１１は、バッファメモリ１０８へ格納され、格納されたパケット２１１の格納情報２１２は、システムコントローラ１１０へ伝えられる。尚、図２において、バッファメモリ１０８は、送信バッファとして機能し、システムコントローラ１１０は、バッファ管理部として機能する。

スケジューリング部１０４は、ストリーム特性情報取得部１０６からストリーム特性情報２１５を入力し、通信特性情報取得部１０７から通信特性情報２１３を入力する。尚、スケジューリング部１０４は、ストリーム特性情報２１５の一部を、システムコントローラ１１０で保持されている「パケット２１１の格納情報２１２」に基づいて取得する。
スケジューリング部１０４は、入力されたストリーム特性情報２１５及び通信特性情報２１３に基づいてパケット２１１の送信タイミングが計算される。そして、その送信タイミングの計算結果が、送信タイミング情報として送信部１０５に送られる。

送信部１０５は、送信タイミング情報に基づいて、バッファメモリ１０８から、システムコントローラ１１０を介して、パケット（パケット化されたストリームデータ）２１１を読み出す。そして、送信部１０５は、有線又は無線のネットワークへ繋がる経路２１４へパケット２１１を送信する。

次に、スケジューリング部１０４により、パケット２１１の送信タイミングを調整する場合の動作の一例について説明する。
図３は、スケジューリング部１０４において計算された送信タイミング情報に基づいて送信タイミングの制御を行った場合のパケット送信間隔の変化の概要の一例を示す図である。
図３において、Ｉ、Ｐ１、Ｐ２、・・・は、符号化された動画像データのフレームのタイプを示している。ここで、動画像データをパケット化して送受信を行う場合に一般的な、動画像データの圧縮符号化処理の内容について説明する。
圧縮符号化処理の代表的な方式として、ＭＰＥＧ−２（ISO/IEC 13818）やＭＰＥＧ−４（ISO/IEC 14496）が挙げられる。これらの符号化方式に共通する圧縮形式（動画像データを構成する各フレームを圧縮する圧縮形式）として、主要な３種類の圧縮形式について説明する。

１つ目の圧縮形式は、１つのフレーム内の情報のみでマクロブロック処理等を行って圧縮符号化処理を行うものであり、この圧縮形式で圧縮されたフレームはＩフレーム（Intra-coded Frame）と呼ばれる。
２つ目の圧縮形式は、時間軸上で前方のフレームを参照しながら、動き補償予測、マクロブロック処理等を行うものであり、前方のフレームに依存した圧縮形式である。この方式で圧縮されたフレームはＰフレーム（Predicted Frame）と呼ばれる。
３つ目の圧縮形式は、Ｐフレームと同様に、時間軸上で隣り合ったフレームを参照しながら圧縮符号化を行うものである。ただし、Ｐフレームは、前方のフレームのみを参照して圧縮されたものであるのに対し、この圧縮形式では、時間軸上で前後に隣り合うフレームを参照しながら動き補償予測、マクロブロック処理等を行う。この方式で圧縮されたフレームは、Ｂフレーム(Bi-directional Predicted Frame)と呼ばれる。

また、いくつかの符号化済みのフレームの集合は、符号化形式がＭＰＥＧ−２の場合はＧＯＰ（Group Of Picture）と呼ばれる。また、ＭＰＥＧ−４の場合はＧＯＶ（Group Of Video Object Plane）と呼ばれる。通常、符号化済みの動画データはＧＯＰ或いはＧＯＶの組み合わせのフレームが連続して連なったものとなっている。以下の説明では、符号化済みのフレームの集合をＧＯＰと総称する。また、以上のような画像のフレーム（Frame）はピクチャ（Picture）とも呼ばれるが、ここではフレーム(Frame)と呼ぶことにする。

図３に示すＩ、Ｐは各々Ｉフレーム、Ｐフレームを表しており、Ｐの添え字の数字は同じ符号化形式のフレームを識別するためのものである。図３の『送信制御なし』のところに示しているパケット送信間隔は、パケット送信間隔の制御を行っていない場合のパケット２１１の送信間隔である。一方、『送信制御あり』のところに示している送信間隔は、パケット送信間隔の制御を行っている場合のパケット２１１の送信間隔である。ここでは、Ｉフレーム及びＰフレームの各々のフレームをパケット化したデータの送信間隔を広げることで、パケット送信間隔の狭い部分と広い部分との差を少なくしている様子を示している。尚、Ｂフレームについては、本実施形態の構成の説明を簡単にするために、詳細な説明を省略する。

次に、スケジューリング部１０４における送信タイミングの計算方法の一例について説明する。
前述したように、スケジューリング部１０４は、ストリーム特性情報２１５をストリーム特性情報取得部１０６及びシステムコントローラ１１０から取得し、通信特性情報２１３を通信特性情報取得部１０７から取得する。
スケジューリング部１０４における送信タイミングの計算処理で必要となるストリーム特性情報２１５は、パケット２１１の送信間隔の制御の方法によって異なり、前述したもの中から、制御の方法に応じたものが選択される。本実施形態では、より一般的な２つの方法について説明する。即ち、フレームレートを守った上で、パケット２１１の送信間隔をフレーム単位で制御する方法と、ＧＯＰに含まれるフレームの送信間隔をＧＯＰ単位で制御する方法との２つの方法について、図４を用いて説明する。図４は、スケジューリング部１０４において計算された送信タイミング情報に基づいて送信タイミングの制御を行った場合のパケットの送信間隔の変化の概要の一例を示す図である。

図４（ａ）の『制御なし』は、送信間隔の制御を行っていない場合のパケットの送信間隔の一例を示している。図４（ｂ）の『制御１』は、フレームレートを守ってフレーム単位で送信間隔を制御している場合のパケットの送信間隔の一例を示している。図４（ｃ）の『制御２』は、ＧＯＰ単位で送信間隔を制御している場合のパケットの送信間隔の一例を示している。図４（ａ）〜図４（ｃ）は、夫々の場合におけるパケットの送信時刻の違いを示している。

図４（ａ）に示す例では、特にパケットの送信間隔の制御を行っていない。このため、１つのフレームをパケット化したパケット毎の送信間隔は処理クロックの精度等に依存する。よって、一般に、図４（ａ）のように、パケットの送信間隔が狭くなる。

図４（ｂ）に示す例では、フレームレートを守った上で、個々のフレームを構成するパケット２１１の送信間隔を広げることで、その送信間隔の局所的な変動を軽減している。このような制御を行う上で最低限必要となるストリーム特性情報２１５には、フレームのサイズとフレームレートとが含まれる。個々のフレームをパケット化するには、更にパケット２１１のサイズの情報（パケットサイズ情報）が必要となるが、これは予め決められた固定値であっても、パケットを生成するタイミングで与えられる可変値であっても良い。

図２を用いて説明すると、スケジューリング部１０４は、送信するフレームがパケット化部１０３でパケット化された際にシステムコントローラ１１０へ送られるパケットサイズ情報とフレームサイズの情報とをシステムコントローラ１１０から取得する。また、スケジューリング部１０４は、フレームレートの情報を、ストリーム特性情報取得部１０６からストリーム特性情報２１５として取得する。
ここで、パケットサイズをPac＿Size、フレームサイズをFrame＿Size、フレームレートをFrame＿Rate、とすると、図４（ｂ）に示す「パケット２１１の送信間隔ΔＴ（Ｂ）は、以下の（１）式で表される。
ΔＴ（Ｂ）＝１／Frame＿Rate／（Frame＿Size／Pac＿Size） ・・・（１）
尚、ここでのパケットサイズPac＿Sizeとは、パケットのヘッダ部分を除いたペイロード部分のサイズを意図している。

次に、図４（ｃ）に示す例について説明する。図４（ｃ）では、『Ｉ，Ｐ₁，Ｐ₂，Ｐ₃，・・・，Ｐ₁₄』というように、先頭がＩフレームで残りの１４個がＰフレームで構成されているＧＯＰ単位でパケット２１１の送信間隔を制御した場合の一例を示している。ＧＯＰを構成する全てのフレームのパケット２１１を、１ＧＯＰ分の時間内に均等な間隔で送信するような制御を意図している。つまり、ＧＯＰ内における個々のフレームレベルでのフレームレートは必ずしも守られない。即ち、図４（ｃ）に示す例の場合、先頭のＩフレームのパケット２１１を、次のＰフレームＰ₁やその次のＰフレームＰ₂の本来の送信時間まで使用して送信している。このため、ＰフレームＰ₁の送信開始時刻は時刻ｔ１から時刻ｔ１´へとずれ込み、その差分ΔＴ１の遅延が発生する。

ところで、図４（ｃ）に示す前記ＧＯＰの構成例では、通常、先頭のＩフレームのサイズが最も大きい。このことから、パケット２１１のサイズが略一定だとすると、同じＧＯＰを構成する他のＰフレームに比較して、送信するパケット数はＩフレームが最も多くなる。よって、先頭のＩフレームのパケット２１１の送信が完了した時点のフレームレートに対する遅延時間を、続くＰフレームＰ₂、Ｐ₃・・・の送信時間内で徐々に少なくするようにパケット２１１の送信間隔を制御する。本実施形態では、このようにすることで、最後のＰフレームＰ₁₂の送信完了時点ではフレームレートに対する遅延が無くなっているようにパケット２１１の送信間隔を制御する。例えば、図４（ｃ）におけるフレームＰ₃でのフレームレートに対する遅延時間ΔＴ３は、フレームＰ₁における遅延時間ΔＴ１よりも小さくなっている。

即ち、図４（ｃ）に示すようにＧＯＰ単位でパケット２１１の送信間隔を制御する場合の最も簡単な方法１つは、１つのＧＯＰにおいて、各フレームをパケット化したものを均等な送信間隔で送信する方法である。このような方法でパケット２１１の送信間隔を制御する場合、スケジューリング部１０４は、ストリーム特性情報２１５として、１ＧＯＰの再生時間Ｔgopと、ＧＯＰ全体の発生符合量Ｓgopと、ペイロードサイズＰgopとを取得する。そして、スケジューリング部１０４は、パケット２１１の送信間隔ΔＴ（Ｃ）を、次の（２）式を用いて求めることができる。
ΔＴ（Ｃ）＝Ｔgop／（Ｓgop／Ｐgop） ・・・（２）
このパケット送信間隔ΔＴ（Ｃ）は、前述したパケット２１１の送信制御の内容からも明らかなように、送信対象のＧＯＰを１ＧＯＰ分の時間内に送信できる時間の上限値となる。
以上のように、図４（ｃ）に示すパケットの送信間隔の少なくとも一部が、フレームレートを守ってパケットを送信する場合のパケットの送信間隔（図４（ｂ）に示す送信間隔）よりも長くなるように、図４（ｃ）に示すパケットの送信間隔は設定される。

次に、ＧＯＰ単位でパケット２１１の送信間隔の制御を行う前述した２つの方法のうち、より実際の処理形態に近い方法の一例について、図５を用いて説明する。
図５は、ライブ映像の動画像データを送信する際に、ＧＯＰ単位でパケット２１１の送信間隔を制御（計算）する方法の一例を説明するフローチャートである。
まず、ステップＳ５０１において、スケジューリング部１０４は、以下の情報を通信特性情報２１３、ストリーム特性情報２１５として、ストリーム特性情報取得部１０６、通信特性情報取得部１０７から取得する。即ち、スケジューリング部１０４は、ライブ映像が受信装置で表示されるまでの許容遅延時間と、送信装置と受信装置と間のＲＴＴ（Round Trip Time）と、送信装置及び受信装置の内部処理時間（符号化・復号化処理時間）とを取得する。ここでの内部処理時間には、符号化及び復号化に関する処理全般において使用する処理バッファに依存する遅延時間を含むものとする。

次に、ステップＳ５０２において、スケジューリング部１０４は、次の（３）式を用いて、最大遅延時間を算出する。
最大遅延時間＝許容遅延時間−内部処理時間−ＲＴＴ／２ ・・・（３）
ここで算出する最大遅延時間とは、次のような時間を意図している。即ち、パケット２１１の送信開始時刻を起点とする動画像データのフレームレートに対し、実際に各フレームをパケット化したデータを許容遅延時間内に送信装置から受信装置に到着させる上で、データの到着時間を遅延させられる最大の時間を意図している。

ステップＳ５０１、Ｓ５０２と並行して、ステップＳ５０３において、スケジューリング部１０４は、１ＧＯＰ分の再生時間とパケット化する際のペイロードサイズとをストリーム特性情報２１５として、ストリーム特性情報取得部１０６から取得する。そして、続くステップＳ５０４において、スケジューリング部１０４は、ＧＯＰの発生符合量を予測する。
尚、ＧＯＰ単位でパケット２１１の送信間隔を制御するにあたって、１ＧＯＰ分の時間の遅延が許されない、又は１ＧＯＰ分の符号化データを保持するバッファを持てないこと等がある。このような理由により、当該ＧＯＰを構成する全てのフレームが符号化される前にＧＯＰの先頭のフレームをパケット化し、送信し始めなければならない場合を想定し、ステップＳ５０４においてＧＯＰの発生符合量を予測している。

次に、ステップＳ５０５において、スケジューリング部１０４は、先頭のＩフレームの発生符合量（サイズ）を取得する。
次に、ステップＳ５０６において、スケジューリング部１０４は、ステップＳ５０２で算出した最大遅延時間、及びステップＳ５０３〜Ｓ５０５で得られた情報等を用いて、パケット２１１の送信間隔を算出する。
ここで、ステップＳ５０６におけるパケット２１１の送信間隔の算出方法の一例について説明する。

まず、スケジューリング部１０４は、１ＧＯＰの再生時間と、ＧＯＰの発生符合量とペイロードサイズとから、以下の（４）式を用いて数値Ａを計算する。
Ａ＝１ＧＯＰの再生時間／（ＧＯＰの発生符合量／ペイロードサイズ） ・・・（４）
数値Ａは、遅延時間を考慮せずに単純に１ＧＯＰの再生時間とパケット数とから算出した１ＧＯＰの平均パケット送信間隔である。

次に、スケジューリング部１０４は、以下の（５）式のように、Ｉフレームの符号量をペイロードサイズで除算し、数値Ｂを算出する。
Ｂ＝Ｉフレームの符合量／ペイロードサイズ ・・・（５）
数値Ｂは、ＧＯＰの先頭のＩフレームのパケット数を示す。ただし、処理方法によっては、ステップＳ５０６の段階で、既にＧＯＰの先頭のＩフレームのパケット化が完了している場合、又はペイロードサイズが一定ではない場合等がある。このような場合、算出式を一概に指定することは難しいが、ここでは、単純な計算方法の１つとして、（４）式及び（５）式を用いた算出方法を示している。

続いて、スケジューリング部１０４は、算出した数値Ａ、ＢとステップＳ５０２で算出した最大遅延時間とを、以下の条件式を用いてパケット２１１の送信間隔を算出する。
ｉｆ（（Ａ×Ｂ）≦最大遅延時間）
パケット送信間隔＝Ａ；
else
パケット送信間隔＝最大遅延時間／Ｂ

具体的にスケジューリング部１０４は、数値Ａと数値Ｂとを乗算した値（＝Ａ×Ｂ）が、ステップＳ５０２で算出した最大遅延時間以下であるか否かを判定する。すなわち、フレームレートに対するパケット送信時刻の遅延が最も大きくなる「Ｉフレームの送信直後の遅延時間」が、前記最大遅延時間以下であるか否かを判定する。

この判定の結果、数値Ａと数値Ｂとを乗算した値が、前記最大遅延時間以下である場合、スケジューリング部１０４は、数値Ａを、送信対象のＧＯＰにおけるパケット２１１の送信間隔として決定する。一方、数値Ａと数値Ｂとを乗算した値が、前記最大遅延時間より大きい場合、スケジューリング部１０４は、前記最大遅延時間を数値Ｂで除算した値（＝最大遅延時間／Ｂ）を、送信対象のＧＯＰにおけるパケット２１１の送信間隔として決定する。このようにすることで、遅延時間の最大値が前記最大遅延時間を越えないように制御される。
以上のように、上記条件式によって算出されるパケット送信間隔は、最大遅延時間内にパケット２１１を送信するための上限値となる。そして、スケジューリング部１０４は、決定した送信間隔でパケット２１１を送信させるための送信指示を送信部１０５に対して行う。これにより、スケジューリング部１０４により決定された送信間隔でパケット２１１が受信装置に送信される。

以上のように本実施形態では、ストリーム特性情報２１５と通信特性情報２１３とに基づいて、パケットの送信間隔の局所的な変動を抑制するように、パケットの送信間隔を制御して、パケットの送信間隔の平準化を行うようにした。これにより、動画像データのフレームレートの制限を超えて、パケット２１１の送信間隔の制御を行うことが可能になり、よりネットワークの障害に強く、パケットロス等の伝送エラーの少ないデータ送信を可能にする。

尚、本実施形態においては、主にＧＯＰ（ＭＰＥＧ-２）又はＧＯＶ（ＭＰＥＧ−４）単位で、パケット２１１の送信間隔を制御する場合を例に挙げて説明したが、制御を行う単位は、これらのものに限定されない。例えば、複数のＧＯＰやＧＯＶ単位でも良いし、ＧＯＰやＧＯＶを分割したものであっても良い。また、例えば、ＭＰＥＧ−４ ＡＶＣ（Ｈ.２６４）やＭｏｔｉｏｎＪＰＥＧ等、同様の符号化形式やフレーム構成を持つものについても、本実施形態の方法を実行する事によって、本発明の目的が達成される。尚、ＭＰＥＧ−４ ＡＶＣ（Ｈ.２６４）を適用した場合、例えば、ＩＤＲ（Instantaneous Decoder Refresh）フレームから次のＩＤＲフレームの直前のフレームまでの複数のフレーム単位で処理することができる。
また、図５のステップＳ５０３〜Ｓ５０５を、ステップＳ５０１、Ｓ５０２の前又は後に行うようにしてもよい。

＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。例えば監視カメラ等の、ライブ映像の配信を行う場合に、再生画像の遅延を少なくするため、出来るだけ送信時間の遅延を少なくする方が望ましい場合がある。本実施形態では、この様な場合でも、通信経路の帯域幅、或いは通信経路上のルーター等のバッファを溢れさせないように、パケットの送信間隔を制御する方法の一例について説明する。このように本実施形態と前述した第１の実施とは、パケットの送信間隔を制御する際の処理の一部が主として異なる。したがって、本実施形態の説明において、前述した第１の実施形態と同一の部分については、図１〜図５に付した符号と同一の符合を付すこと等によって、詳細な説明を省略する。

図６は、パケットの送信間隔の変化の概要の一例を示す図である。図６（ａ）の『制御なし』は、送信間隔の制御を行っていない場合のパケットの送信時刻の一例を示している。図６（ｂ）の『制御３』は、本実施形態のようにして送信間隔の制御を行った場合のパケットの送信時刻の一例を示している。図６（ｂ）に示す例では、パケットの送信間隔を広げることによって、ストリームデータのフレームレートに対して先頭の３フレームに遅延が発生したが、４フレーム目からフレームレート通りのパケット送信が行なわれていることを示している。
尚、本実施形態においても、『Ｉ，Ｐ₁，Ｐ₂，Ｐ₃，・・・，Ｐ₁₄』というように、先頭がＩフレームで残りの１４個がＰフレームで構成されているＧＯＰの構造を持つストリームデータを例に挙げて説明を行う。

本実施形態では、パケット送信間隔を、通信特性情報を用いて算出する。この通信特性情報の主なものとして、ストリームデータの通信に使用可能な通信経路の有効帯域がある。
この有効帯域は、実際に通信経路の計測を行って得た統計情報等から推測しても良いし、ストリームデータを受信する受信装置側から予め設定しても良い。更にその他の方法として、ストリームデータの送受信を行う中で、パケットロスやビットエラー等の伝送エラー率（エラーの発生率）等を算出し、その伝送エラー率から有効帯域を推測しても良い。このようにして通信特性情報を取得する処理は、通信特性情報取得部１０７で行うことができる。

図７は、図６に示すような送信間隔でパケットを送信した場合の送信レートの変化の一例を示す図である。図７（ａ）の『制御なし』は、図６（ａ）のようにパケットの送信間隔を制御しなかった場合の送信レートの変化の一例を示す図である。また、図７（ｂ）は、図６（ｂ）に示すようにしてパケットの送信間隔を制御した場合の送信レートの変化の一例を示す図である。

図７（ａ）に示すように、パケットの送信間隔の制御を行っていない場合、送信レートが有効帯域を越えてしまう場合がある。このような場合、実際の通信経路では、経路上のルーターやＮＩＣ（Network Interface Card）等において、バッファ溢れ等によりパケットロスが発生する。
本実施形態では、このパケットロスを回避するために必要な「最低限のパケットの送信間隔」を与えることで、送信レートの変動を有効帯域以下に抑え、且つ、出来るだけ遅延の少ないストリームデータの送信を実現する。

スケジューリング部１０４は、通信特性情報２１３として有効帯域Ｂを、通信特性情報取得部１０７から取得する。また、スケジューリング部１０４は、ストリーム特性情報２１５としてパケットの平均サイズＳpacを、ストリーム特性情報取得部１０６からフレーム毎に取得する。そして、スケジューリング部１０４は、次の（６）式を満たすように、パケットの送信間隔ΔＴ（Ｄ）を設定する。
ΔＴ（Ｄ）＞Ｓpac／Ｂ ・・・（６）
この計算式（（６）式））の不等号（＞）を等号（＝）にした条件を満たす送信間隔ΔＴ（Ｄ）でパケットを送信すると、送信レートが有効帯域に接してしまう。このため、６）式）の不等号（＞）を等号（＝）にした条件を満たす送信間隔ΔＴ（Ｄ）に対し、状況に応じたマージンを加算した値を、パケットの送信間隔ΔＴ（Ｄ）の下限値として設定するのが好ましい。即ち、この（６）式の条件式によって算出される最低限のパケット送信間隔ΔＴ（Ｄ）は、バッファ溢れ等によるパケットロスを回避するための下限値となる。

以上のように本実施形態では、通信特性情報２１３の一例である有効帯域Ｂと、ストリーム特性情報２１５の一例であるパケットの平均サイズＳpacとを用いて、パケットの送信間隔の下限値を設定するようにした。したがって、送信レートが有効帯域を越えてしまうことを可及的に防止することができる。
尚、本実施形態と前述した第１の実施形態とを組み合わせて、パケットの送信間隔の上限値と下限値とを設定し、設定した範囲内の送信間隔でパケットを送信するようにしてもよい。

＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。本実施形態では、既に符号化・蓄積済みの動画像コンテンツを送信する場合を例に挙げて説明する。本実施形態と前述した各実施形態とは、パケットを送信する際の処理の一部が主として異なるので、本実施形態の説明において、前述した各実施形態と同一の部分については、図１〜図６に付した符号と同一の符合を付すこと等により、詳細な説明を省略する。

図８は、蓄積済みの動画像コンテンツのビットレートと、その動画像コンテンツを送信する場合の送信レートとの関係の一例について示す図である。図８（ａ）、図８（ｂ）は、夫々コンテンツＡ、Ｂにおけるビットレートと送信レートとの関係の一例を示す図である。以下に示すように、本実施形態では、コンテンツの平均レートを算出又は取得し、平均レートと同等の送信レートでコンテンツを送信する方法を用いる。

例えば、図８（ａ）に示すコンテンツＡのようなビットレートの変動を持つコンテンツの場合には、次のようにして配信を行う。即ち、前述した実施形態のように、送信開始時点を起点としたフレームレートに対し遅延させてパケットを送信するのではなく、フレームレートよりも早いタイミングで前倒ししてパケットを送信することで、平均レートと同等のレートでのコンテンツ配信を行う。
尚、動画像ストリームの配信には、ＲＴＰを使用することが多い。ＲＴＰで送信されるパケットにはヘッダ部分にタイムスタンプ情報が付加されている。このため、本実施形態のようにフレームレートに合わせた送信を行わなくても、受信装置側でタイムスタンプを確認することによって、正しい再生画像を表示することができる。ただし、受信装置では、表示する時間よりも早くパケットが送信装置から送られてくるので、復号化等の表示処理を開始するまで、受信したデータを保管しておくバッファが必要になる。

一方、図８（ｂ）に示すコンテンツＢのようなビットレートの変動を持つコンテンツの場合は、前半部分のビットレートの方が後半部分のビットレートよりも高い。よって、送信レートを平均レートに近づけるには、フレームレートよりも遅延させてパケットの送信を行う必要がある。
この場合、受信装置側での表示開始のタイミングや、受信したパケットのバッファ量によっては、パケットの到着時刻が受信装置での表示タイミングに間に合わなくなる恐れがある。よって、本実施形態では、例えば受信装置でパケットの受信を開始してから表示処理を開始するまでの時間を送信装置側から指定したり、受信装置のバッファサイズを送信装置側に通知したりする。このようにすることによって、受信装置のバッファをオーバーフロー又はアンダーフローさせないように、パケットの遅延時間を送信装置側で制御する等の方法をとる。従って、特に、コンテンツＢのようなビットレートの変動を持つコンテンツの場合には、図８（ｂ）に示すように平均レートに近い送信レートをベースにして、パケット到達時刻の遅延による再生処理の破綻を回避するように制御を行う。

以上のように本実施形態では、スケジューリング部１０４は、蓄積済みの動画像コンテンツのビットレートに基づいて、前述した各実施形態のようにしてパケットを送信するか、フレームレートよりも早いタイミングで前倒ししてパケットを送信するかを判定する。したがって、蓄積済みの動画像コンテンツを、平均レートに近い送信レートで送信することができ、伝送エラーを防止することができる。

＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。前述した各実施形態では、パケットの送信間隔を最終的にパケット単位で制御する方法を例に挙げて説明してきた。しかしながら、実際の処理を行う送信装置では、処理を行う基本的な単位となるクロックの精度が問題となる事がある。
つまり、クロック精度が良くない送信装置では、パケットの送信タイミングの細かな制御が出来ない場合がある。
このような送信装置においては、複数のパケットの送信をタイミング制御せずにまとめて連続送信する方法と、クロック精度に依存したタイミング制御を行って送信する方法とを組み合わせることによって、パケットの送信間隔の制御を実現できる。尚、以下の説明では、複数のパケットの送信をタイミング制御せずにまとめて連続送信することを、必要に応じてバースト送信と称する。

図９は、バースト送信と、クロック精度に依存したタイミング制御とを組み合わせて、パケットの送信間隔をＧＯＰ単位で制御した場合のパケットの送信間隔の変化の概要の一例を示す図である。図９（ａ）の『制御なし』は、送信間隔の制御を行っていない場合のパケットの送信時刻の一例を示している。図４（９）の『制御２』は、第１の実施形態で説明したように、ＧＯＰ単位で送信間隔を制御した場合のパケットの送信間隔の一例を示している。図９（ｃ）の『制御４』は、本実施形態のようにして送信間隔の制御を行った場合のパケットの送信時刻の一例を示している。

第１の実施形態で説明したように、パケットの理想的な送信タイミングは、図９（ｂ）に示すものとなる。しかしながら、送信装置のクロックの精度があまり良くなく、クロック・タイミングのポイントでのみパケットの送信を行える装置では、図９（ｃ）に示すようにしてパケットをバースト送信する。即ち、パケットの理想的な送信タイミングに最も近いクロック・タイミングでバースト送信を行なうことで、パケット送信間隔を平均化することができる。

以上のように本実施形態では、スケジューリング部１０４は、例えば図９（ｂ）のようなパケットの送信間隔と、クロックの精度に基づく送信タイミング（クロック・タイミング）とに基づいて、そのクロック・タイミングでバースト送信するパケットを設定する。したがって、送信装置のクロックの精度が高くなくても（低くても）、パケットの伝送エラーを低減することができる。

（本発明の他の実施形態）
前述した本発明の実施形態における通信制御装置を構成する各手段、並びに通信制御方法の各ステップは、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。

また、本発明は、例えば、システム、装置、方法、プログラム若しくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図５に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接、あるいは遠隔から供給する。そして、そのシステムあるいは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷなどがある。また、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などもある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、前記ホームページから本発明のコンピュータプログラムそのもの、若しくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。

また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、ダウンロードした鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。その他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。

さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。その後、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。

尚、前述した各実施形態は、何れも本発明を実施するにあたっての具体化の例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。

本発明の第１の実施形態を示し、送信装置のシステム構成の一例を示すブロック図である。 本発明の第１の実施形態を示し、ストリームデータを取得してからパケットデータを送信するまでの送信装置の構成の一例を、データの流れと共に示すブロック図である。 本発明の第１の実施形態を示し、スケジューリング部において計算された送信タイミング情報に基づいて送信タイミングの制御を行った場合のパケット送信間隔の変化の概要の一例を示す図である。 本発明の第１の実施形態を示し、スケジューリング部において計算された送信タイミング情報に基づいて送信タイミングの制御を行った場合のパケットの送信間隔の変化の概要の一例を示す図である。 本発明の第１の実施形態を示し、ライブ映像の動画像データを送信する際に、ＧＯＰ単位でパケット２１１の送信間隔を制御（計算）する方法の一例を説明するフローチャートである 本発明の第２の実施形態を示し、パケットの送信間隔の変化の概要の一例を示す図である。 本発明の第２の実施形態を示し、図６に示すような送信間隔でパケットを送信した場合の送信レートの変化の一例を示す図である。 本発明の第３の実施形態を示し、蓄積済みの動画像コンテンツのビットレートと、その動画像コンテンツを送信する場合の送信レートとの関係の一例について示す図である。 本発明の第４の実施形態を示し、バースト送信と、クロック精度に依存したタイミング制御とを組み合わせて、パケットの送信間隔をＧＯＰ単位で制御した場合のパケットの送信間隔の変化の概要の一例を示す図である。

符号の説明

１０１ ストリーム取得部
１０２ ストリーム符号化部
１０３ パケット化部
１０４ スケジューリング部
１０５ 送信部
１０６ ストリーム特性情報取得部
１０７ 通信特性情報取得部
１０８ バッファメモリ１０９
１０９ メインメモリ
１１０ システムコントローラ

Claims (11)

1. 受信装置へ動画データのパケットを送信する通信制御装置であって、
   前記受信装置へ送信する動画データを取得する取得手段と、
   前記動画データを再生中の前記受信装置における前記動画データのパケットの到着時間を遅延させられる遅延時間情報を算出する算出手段と、
   前記算出された遅延時間情報に応じて、所定の圧縮形式のフレームのパケットの送信間隔が、当該フレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなるように、前記動画データのパケットの送信間隔を決定する決定手段と、
   前記決定手段により決定された送信間隔に応じたタイミングで、前記動画データのパケットを送信する送信手段とを備えることを特徴とする通信制御装置。
2. 前記算出手段は、前記動画データの撮影時刻と当該動画データの前記受信装置での再生時刻との時間差に応じた許容遅延時間、及び、前記通信制御装置と前記受信装置との間のデータの伝達時間に基づいて、前記遅延時間情報を算出することを特徴とする請求項１に記載の通信制御装置。
3. 前記所定の圧縮形式のフレームは、１フレーム内で圧縮符号化されたイントラフレームであることを特徴とする請求項１又は２に記載の通信制御装置。
4. 前記決定手段は、１フレーム内で圧縮符号化されたイントラフレームのパケットの送信間隔が、当該イントラフレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなり、他のフレームを参照して圧縮符号化されたインターフレームのパケットの送信間隔が、当該インターフレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも短くなるように、前記算出手段により算出された遅延時間情報に応じて、前記動画データのパケットの送信間隔を決定することを特徴とする請求項１乃至３のいずれか１項に記載の通信制御装置。
5. 前記決定手段は、１フレーム内で圧縮符号化されたイントラフレームと、他のフレームを参照して圧縮符号化された複数のインターフレームとを含むフレームグループの各パケットの送信間隔が均等になるように、送信間隔を決定することを特徴とする請求項１乃至４のいずれか１項に記載の通信制御装置。
6. 前記決定手段は、１フレーム内で圧縮符号化されたイントラフレームと、他のフレームを参照して圧縮符号化された複数のインターフレームとを含むフレームグループのデータ量と当該フレームグループの再生時間とに基づいて算出される当該フレームグループのパケットの送信間隔で当該フレームグループのパケットを送信した場合に、前記イントラフレームのパケットの送信を前記通信制御装置で遅延させる時間が前記遅延時間情報に示される時間を超えない場合、当該送信間隔を前記フレームグループのパケットの送信間隔として決定することを特徴とする請求項１乃至５のいずれか１項に記載の通信制御装置。
7. 前記決定手段は、前記通信制御装置と前記受信装置との間の通信経路の有効帯域に関する情報に基づいて算出される、前記動画データのパケットの送信間隔の下限値以上の送信間隔で送信されるように、前記動画データのパケットの送信間隔を決定することを特徴とする請求項１に記載の通信制御装置。
8. 前記受信装置へ送信する動画データを予め記録する記録手段を有し、
   前記決定手段は、前記記録手段に記録された動画データのうち、第１の期間の動画データのビットレートが前記記録手段に記録された動画データの平均ビットレートよりも低く、前記第１の期間よりも後の第２の期間の動画データのビットレートが前記平均ビットレートよりも高い場合、前記第１の期間の動画データ及び第２の期間の動画データのビットレートが前記平均ビットレートの場合よりも、前記第２の期間の動画データを早いタイミングで送信するように、前記動画データのパケットの送信間隔を決定することを特徴とする請求項１に記載の通信制御装置。
9. 前記決定手段は、前記決定したパケットの送信間隔と、前記通信制御装置のクロックの精度とに基づいて、クロックタイミングで連続して送信するパケットを決定することを特徴とする請求項１乃至８のいずれか１項に記載の通信制御装置。
10. 受信装置へ動画データのパケットを送信する通信制御装置が行う通信制御方法であって、
    前記受信装置へ送信する動画データを取得する取得ステップと、
    前記動画データを再生中の前記受信装置における前記動画データのパケットの到着時間を遅延させられる遅延時間情報を算出する算出ステップと、
    前記算出された遅延時間情報に応じて、所定の圧縮形式のフレームのパケットの送信間隔が、当該フレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなるように、前記動画データのパケットの送信間隔を決定する決定ステップと、
    前記決定ステップにより決定された送信間隔に応じたタイミングで、前記動画データのパケットを送信する送信ステップとを備えることを特徴とする通信制御方法。
11. 受信装置へ動画データのパケットを送信するコンピュータに、
    前記受信装置へ送信する動画データを取得する取得ステップと、
    前記動画データを再生中の前記受信装置における前記動画データのパケットの到着時間を遅延させられる遅延時間情報を算出する算出ステップと、
    前記算出された遅延時間情報に応じて、所定の圧縮形式のフレームのパケットの送信間隔が、当該フレームのパケット数と前記動画データのフレームレートとに基づく送信間隔よりも長くなるように、前記動画データのパケットの送信間隔を決定する決定ステップと、
    前記決定ステップにより決定された送信間隔に応じたタイミングで、前記動画データのパケット送信する送信ステップとを実行させることを特徴とするコンピュータプログラム。

Images