JP2007174170A - パケット送信装置、受信装置、システム、およびプログラム - Google Patents

Abstract

【課題】汎用ＰＣ等を用いた非リアルタイムシステムベースのストリーミングシステムにおいて、端末側のバッファ量をできるだけ小さくするための技術を提供する。
【解決手段】映像パケット送信装置１００はパケット網１２０を介して映像パケット受信装置１５０にストリームデータを送信する。映像パケット送信装置１００は、映像パケット受信装置１５０の受信バッファ１５１の状態に関する通知を映像パケット受信装置１５０から受信するバッファ状態受信処理部１０３と、周期的に端末通信処理部１０２を起動する疑似リアルタイムスケジューラ部１０１と、疑似リアルタイムスケジューラ部１０１によって起動される各周期において、バッファ状態受信処理部１０３が受信した通知に基づいて調整されたパケット数のパケットを映像パケット受信装置１５０に送信する端末通信処理部１０２と、を備える。
【選択図】図１

Description

本発明は、パケット網を介してパケット受信装置にストリームデータを送信するパケット送信装置、そのパケット受信装置、それらの装置を有するシステム、およびそれらの装置ためのプログラムに関する。

映像パケット送信装置（映像データ流供給装置）とは、パケット交換網において映像データをパケットに分割し、適切な宛先に送信するための装置である。パケットは、ネットワークインターフェイスを介して端末装置（映像パケット受信装置）に送られ、端末装置では、送られて来たパケットから映像データ流（映像ストリーム）を再構成し、ビデオ信号に変換して表示装置に送り、映像を再生する。

放送業界等においては、従来から、高画質な映像パケット送信装置が求められていたが、一般に、映像パケット送信装置においては、映像データの圧縮および伸長を行なうために遅延が大きく、放送のリアルタイム性の要求を満たせないため、放送用編集システムとしては用いられてこなかった。リアルタイム性を実現するためには、高画質映像データを非圧縮で送信する必要があるが、広帯域ネットワークを必要とするため、ネットワークコストの面から、従来は積極的に開発が行なわれていなかった。

しかし、近年、安価なネットワーク機器の開発が進み、回線コストも下がりつつあることから、伝送路上を非圧縮で伝送する高画質映像伝送システムの開発が行なわれるようになってきた。これらの技術については、非特許文献１〜４に記載されている。

君山、清水、川野、小倉、丸山、"ＩＰネットワークを使った非圧縮ＨＤＴＶ対応映像サーバの構成法に関する検討"、情報処理学会研究報告、ＤＰＳ−１１１、ｐｐ．４５−５２、２００３ H. Kimiyama、K. Shimizu、T. Kawano、T. 0gura、M. Maruyama、"Real-time Processing Method for an Ultra High-Speed Streaming Server Running PCLinux"、Proceeding of AINA 2004、ｖｏｌ．２、ｐｐ．４４１−４４６、２００４ 川野、清水、小倉、丸山、"インターネット非圧縮ＨＤＴＶ転送システムにおける高速プロトコル処理技術"、ＮＴＴ Ｒ＆Ｄ、Ｖｏｌ．５１、Ｎｏ．７、ｐｐ．５９６−６０２、２００２ 川野、小倉、清水、丸山、小柳、"非圧縮ＨＤＴＶ ｏｖｅｒ ＩＰシステムにおける高速プロトコル処理技術"、信学技報、ＮＳ２００２−５１、ｐｐ．４７−５０、２００２

上記で述べたように、放送業界では、高画質とリアルタイム性を両立した伝送システムヘの要求がある。高画質であればあるほど、伝送されるデータ量は大きいものになるため、映像パケット受信装置側では、再生待ちの映像を格納するためのバッファ量を大きくする必要がある。また、ネットワークやシステムの負荷変動を吸収するために、ある程度の余裕をもたせるために必要量以上にバッファの大きさを取ることが一般的である。しかし、バッファ量が大きくなるほど、遅延が大きくなるため、許容遅延が数フレーム以内とされる放送業界の厳しい要求に応えるためには、できるだけバッファ量を小さくする必要がある。

一方、専用装置の開発は高コストとなるため、ストリーミングシステムにおいては、低価格化を目的として市販ＰＣやワークステーションを用いることが一般的である。しかし、これらはクロック同期機構を持たないため、サーバ側（映像パケット送信装置側）と端末側（映像パケット受信装置側）の再生レートを精密に合わせることができず、受信バッファを小さくした場合、バッファのオーバーランやアンダーランを容易に引き起こす。さらに、リアルタイムシステムではないため、負荷変動によってパケットの処理速度にも変動が生じるため、受信バッファのオーバーランやアンダーランを一層ひきおこし易くなる。バッファオーバーランやバッファアンダーランを回避するために、端末側のバッファ量を増やす手法が一般的に取られるが、既に述べたように、遅延が大きくなってしまうため、リアルタイム性を要求される分野には適さない。汎用ＰＣ等を用いるためには、端末側のバッファ量をできるだけ小さく抑えつつ、安定な伝送を行なうことが求められる。

本発明は、上記の問題を解決するためになされたものである。本発明の目的は、汎用ＰＣ等を用いた非リアルタイムシステムベースのストリーミングシステムにおいて、端末側のバッファ量をできるだけ小さくするための技術を提供することである。

本発明は、フィードバックレート制御を行うパケット送信装置、受信装置、システム、およびプログラムに関し、安価な汎用ＰＣ等の非リアルタイムシステムを用いたストリーミングシステムにおいて、低遅延に対応するために、通信用バッファ量の低減をはかりつつ、安定な通信を実現するものである。

一般に、非リアルタイムシステムを用いたストリーミングシステムにおいて、クロック同期機構を持たずして、負荷変動に強い、安定した通信を行なうには、バッファ量を大きく取ることが一般的である。しかし、バッファ量の増大は遅延の増大につながるため、遅延について数フレーム以内を要求される放送用設備には適さない。

そこで本発明では、端末側にバッファ量の瞬時値と変化率を測定し、その情報をパケット送信装置側に通知する装置を配置し、また、パケット送信装置側には送信レート制御装置を配置して、通知された情報を元に、パケット送信装置からのパケット送信レートを適応的に精密に制御することにより、バッファ量の低減をはかる。

本発明では、このような方法で、クロック同期機構を持たずに、非リアルタイムシステムを用いたストリーミングシステムのバッファ量の低減をはかり、遅延の低減をはかる。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

（１）パケット網を介してパケット受信装置にストリームデータを送信するパケット送信装置であって、前記パケット受信装置の受信バッファの状態に関する通知を前記パケット受信装置から受信するバッファ状態受信処理部と、周期的に端末通信処理部を起動するスケジューラ部と、前記スケジューラ部によって起動される各周期において、前記バッファ状態受信処理部が受信した前記通知に基づいて調整されたパケット数のパケットを前記パケット受信装置に送信する端末通信処理部と、を備えることを特徴とする。

（２）前記（１）のパケット送信装置であって、前記通知は前記パケット受信装置の受信バッファの使用量の変化率を含み、前記端末通信処理部は、前記変化率に基づいて調整されたパケット数のパケットを前記パケット受信装置に送信することを特徴とする。

（３）前記（２）のパケット送信装置であって、前記バッファ状態受信処理部は、前記変化率が予め決められた基準を外れた場合に、前記変化率に基づいて送信レートを変更することを特徴とする。

（４）前記（１）〜（３）のパケット送信装置であって、前記端末通信処理部は、予め定められた周期ごとに、送信すべきデータ量の端数を調整するパケット数でパケットを送信することを特徴とする。

（５）前記（１）〜（３）のパケット送信装置であって、前記端末通信処理部は、送信すべきデータ量の端数を分散して調整するパケット数でパケットを送信することを特徴とする。

（６）前記（１）〜（５）のパケット送信装置であって、前記通知は前記パケット受信装置の受信バッファの使用量とその変化率を含み、前記バッファ状態受信処理部は、前記パケット受信装置の受信バッファの使用量の変化率が予め決められた基準内に収まり、受信バッファの使用量が目標値から外れている場合に、リカバリーモードをセットし、前記端末通信処理部は、リカバリーモードがセットされている時には、受信バッファの使用量の目標値と現在の受信バッファの使用量の差分に基づいて、毎周期ごとにパケット数を増減することを特徴とする。

（７）前記（１）〜（６）のパケット送信装置からパケット網を介してストリームデータを受信するパケット受信装置であって、前記パケット送信装置から受信したデータを一時的に蓄える受信バッファと、前記受信バッファの状態に関する通知を前記パケット送信装置に送信するバッファ状態通知処理部と、を備えることを特徴とする。

本発明によれば、パケット送信装置が、パケット受信装置側から通知された受信バッファの状態に関する通知に基づいて（具体的には受信バッファ使用量の瞬時値およびその単位時間の変化率を元に）制御を行なうことにより、非リアルタイムシステムにおいて、ハードウェアによるクロック同期機構等によらずに、パケット受信装置において受信バッファのアンダーランおよびオーバーランを防ぎ、安定したストリームデータの再生が可能となる。

以下、本発明の実施例を図面に基づいて説明する。以下に説明する本発明の実施例は、パケット交換網において用いられる映像伝送用の映像パケット送信装置等に関するものであり、特にその映像データの送信レートの制御を行なうものである。しかし、本発明は、一般には、パケット網を介してパケット受信装置にストリームデータを送信するパケット送信装置等において有効な技術である。本実施例で扱うレート制御装置を含む、非リアルタイムシステムをべースとしたストリーミングシステムの実施形態を図１に示し、全体の動作を簡単に説明する。

図１において、１００は映像パケット送信装置（ストリームサーバ）であり、疑似リアルタイムスケジューラ部１０１、端末通信処理部（送信部）１０２、バッファ状態受信処理部１０３、ディスク装置１０４、ネットワークインタフェース１０５、およびＬｉｎｕｘカーネル１０６を備えている。バッファ状態受信処理部１０３は映像パケット受信装置１５０の受信バッファ１５１の状態に関する通知を映像パケット受信装置１５０から受信する手段を有しており、疑似リアルタイムスケジューラ部１０１は周期的に端末通信処理部１０２を起動する手段を有しており、端末通信処理部１０２は疑似リアルタイムスケジューラ部１０１によって起動される各周期において、バッファ状態受信処理部１０３が受信した通知に基づいて調整されたパケット数のパケットを映像パケット受信装置１５０に送信する手段を有している。ディスク装置１０４、ネットワークインタフェース１０５、Ｌｉｎｕｘカーネル１０６は周知のものと同様である。

１５０は映像パケット受信装置（動画再生装置）であり、受信バッファ１５１、バッファ状態通知処理部１５２、および映像信号変換部１５３を備えている。受信バッファ１５１は映像パケット送信装置１００から受信したデータを一時的に蓄え、バッファ状態通知処理部１５２は受信バッファ１５１の状態に関する通知を映像パケット送信装置１００に送信する手段を有している。映像信号変換部１５３は周知のものと同様である。

１２０はパケット網であり、１２１は映像パケット送信装置１００から映像パケット受信装置１５０へ送信される動画ストリームであり、１２２は映像パケット受信装置から映像パケット送信装置１００へ送信される状態通知パケットである。なお、図中の点線の矢印は制御の流れを表しており、実線の矢印は映像データの流れを表している。

まず映像パケット送信装置１００側について説明する。疑似リアルタイムスケジューラ部１０１では、他のプロセスのスケジューリングを行なう働きを担っており、一定の周期で端末通信処理部１０２を起動する。非リアルタイムシステムにおいては、毎周期の動作を精密な間隔で行なうことは保証できないが、数十周期以上の長期にわたってみれば、平均的には正確な制御が可能であり、一般的なタイマ割り込みによっても、送信レート制御を可能とする程度には、疑似的なリアルタイムスケジューリングを行なうことができる。

端末通信処理部１０２は、映像データをパケット網１２０を通して送り出す働きを持ち、目標の送信レートとなるように、周期ごとにパケット数を調整して、パケットを送り出す。

バッファ状態受信処理部１０３は、映像パケット受信装置１５０側から通知された情報（受信バッファ１５１の使用量の瞬時値およびその変化率）に基づき、映像パケット受信装置１５０側のバッファのオーバーラン・アンダーランが発生しないように、１周期に送信すべき映像データ量を周期毎に調整して、目標とする映像パケット受信装置１５０の受信バッファ１５１の使用量が常に一定の範囲内に収まるようにする。

次に映像パケット受信装置１５０側について説明する。バッファ状態通知処理部１５２が、受信バッファ１５１からたとえば一定の周期（１〜１０映像フレームに一度の頻度）で、映像データの受信バッファ使用量を読みだし、その変化率とともにその瞬時値を数秒周期で映像パケット送信装置１００側に通知する。なお、受信バッファの使用量の変化率は、たとえば、単位時間あたりの変化量であり、変化量は直前の使用バッファ量測定値と現在の使用バッファ量の測定値の差分である。

以下、映像パケット送信装置１００の疑似リアルタイムスケジューラ１０１、端末通信処理部１０２、およびバッファ状態受信処理部１０３の動作を詳細に説明する。図２、図３、図４、図５および図６に、各部の動作アルゴリズムを示す。

図２は、疑似リアルタイムスケジューラ部１０１の動作を示した図である。初期状態では、疑似リアルタイムスケジューラ部１０１は、図示しないインターバルタイマからの割込信号を待っている（２０１）。インターバルタイマからの信号を受け取ると、端末通信処理部１０２に割込信号を送って起動した後、１０ｍｓ後に動作するようにインターバルタイマを設定した後（２０２）、端末通信処理部１０２へ割込信号を発行してパケットの送信を促し（２０３）、再び割込待ち状態に入る（２０１）。このようにして１０ｍｓ粒度のスケジューリング処理を実現する。

図３および図４は、端末通信処理部１０２の動作を示した図である。それぞれ後述の方式１および方式２に対応している。

初期状態では、カウンタＣおよび変数ＡＤＪ、ＡＤＤを０にした後（３０１、４０１）、疑似リアルタイムスケジューラ部１０１からの割込み信号待ちをしている（３０２、４０２）。割込信号を受けると動作を開始する。まず、リカバリーモードにあるかどうかを調べる（３０３、４０３）。リカバリーモードについては後述する。リカバリーモードに入っていなければ（３０３、４０３でＮｏ）、この周期において送信すべきデータ量Ｍを送信する。このスケジューラからの割り込み周期をＴ（ｓ）とすると、この周期で送信すべきデータ量Ｍｃ（理論値）は、以下の式１のようになる。なお、式１の「２９．９７」は動画１秒あたりのフレーム数である。一般には、テレビの動画は１秒間に３０フレームの絵からなるとされているが、正確な値は２９．９７フレーム／ｓｅｃである。
Ｍｃ＝Ｆ＿ｓｉｚｅ×２９．９７×Ｔ （式１）
Ｔ：起動周期（ｓ）
Ｆ＿ｓｉｚｅ：フレームサイズ
しかし、映像パケット送信装置１００と映像パケット受信装置１５０は独立した動作クロックで動いているため、Ｍの値が理論値Ｍｃに一致するとは限らない。バッファ状態受信処理部１０３から通知された変化率Ｒを元に値の補正を行なう、この周期で実際に送信すべきデータ量Ｍは、式２のようになる。なお、式１の送信すべきデータ量Ｍｃはフレームサイズから計算された理論値であり、式２の実際に送信すべきデータ量Ｍは映像パケット受信装置１５０側から通知されたバッファ量の変化率Ｒの実測値を加味して計算した補正値である。
Ｍ＝（Ｆ＿ｓｉｚｅ−Ｒ）×２９．９７×Ｔ （式２）
したがって、周期あたりの平均パケット送信数Ｎ＿ａｖｇは、パケットのペイロードサイズをｐｋｔ＿ｐｌｄとすると、式Ｃのようになる。
Ｎ＿ａｖｇ＝Ｍ／ｐｋｔ＿ｐｌｄ （式３）
計算の結果、Ｎ＿ａｖｇが整数であれば、周期あたりＮ＿ａｖｇのパケットを送信すればよいため、Ｎ＿ａｖｇができるだけ整数に近くなるようにｐｋｔ＿ｐｌｄを調整するだけで、所望のレートで送信することができることになる。しかし、受信側の実装その他の理由により、ペイロードサイズｐｋｔ＿ｐｌｄを固定とせざるを得ない場合には、ほとんどの場合Ｎ＿ａｖｇは整数とはならず、端数が発生するため、端末通信処理部１０２の送信パケット数Ｎを周期ごとに変更して、数周期の間に端数を調整し、微妙な送信レート調整を行なう。

この端数の調整の方法として、（１）数周期ごとに端数を調整する方法（方式１）と、（２）送信周期の整数倍で端数を分散させる方法（方式２）が考えられる。具体的には、端数の調整は、以下のように行なう。

（１）方式１（図３の３０５〜３０７参照）
周期Ｆごとに一度、端数を調整する。すなわち、端末通信処理部１０２は、予め定められた周期Ｆごとに、送信すべきデータ量の端数を調整するパケット数でパケットを送信する。たとえば、図３に示すように、カウンタＣが予め定めた周期Ｆに一致するかどうか調べ（３０５）、Ｎｏであれば基準パケット数Ｎ＿ｂａｓｅのパケットを送信し（３０６）、Ｙｅｓであれば端数を調整するパケット数Ｎ＿ｂａｓｅ＋Ｆ＿ｒａｃのパケットを送信する（３０７）。周期ごとに必ず送信すべき基準パケット数Ｎ＿ｂａｓｅは、以下の式によって予め求められる。通常は、送信パケット数Ｎ＝Ｎ＿ｂａｓｅである（３０６）。
Ｎ＿ｂａｓｅ＝（ｉｎｔ）（Ｍ ／ｐｋｔ＿ｐｌｄ） （式４）
また、端数Ｆ＿ｒａｃを以下の式によって計算し、毎Ｆ周期ごとに送信パケット数Ｎ＝Ｎ＿ｂａｓｅ＋Ｆ＿ｒａｃとする（３０７）。
Ｆ＿ｒａｃ＝（Ｍ％ｐｋｔ＿ｐｌｄ）＊Ｆ／ｐｋｔ＿ｐｌｄ （式５）
ここで、（ｉｎｔ）は整数を取ることを意味しており、％およびｍｏｄは剰余を得ることを意味している。なお、Ｎ＿ｂａｓｅとＦ＿ｒａｃの計算は図５に関連して説明するようにバッファ状態受信処理部１０３において行われる。

この方式では、ある特定の周期で多くのパケットを送ってしまうため、周期Ｆを長くとると、端数が大きくなりすぎて送信レートが大きく変動してしまう。本システムでは、受信側において送信レートの測定を行なっているため、周期Ｆの取りかたを調整して、送信レートが大きく変動しないようにする必要がある。具体的には、Ｆ＿ｒａｃがｐｋｔ＿ｐｌｄに比べて大きくなりすぎないように、周期Ｆを取ればよい。

この他、端数の調整法としては、次のように周期の整数倍で、端数を分散させる方法もある。

（２）方式２（図４の４０５参照）
方式２では、端末通信処理部１０２は、送信すべきデータ量の端数を分散して調整するパケット数Ｎでパケットを送信する。パケット数Ｎは以下の式に基づいて決定する（図４の４０５）。
Ｎ＝Ｎ＿ｂａｓｅ＋
（（ＮＯＴ（Ｃ ｍｏｄ ２）） ＆＆ ｃｙｃｌｅ［２］）＋
（（ＮＯＴ（Ｃ ｍｏｄ ４）） ＆＆ ｃｙｃｌｅ［４］）＋
（（ＮＯＴ（Ｃ ｍｏｄ ６）） ＆＆ ｃｙｃｌｅ［６］）＋
（（ＮＯＴ（Ｃ ｍｏｄ ８）） ＆＆ ｃｙｃ１ｅ［８］） （式６）
ここで、Ｎ＿ｂａｓｅは基準パケット数であり、前述のように、Ｎ＿ｂａｓｅ＝（ｉｎｔ）Ｍ／ｐｋｔ＿ｐｌｄである。ＮＯＴは否定を意味し、たとえば、（ＮＯＴ（Ｃ ｍｏｄ ２））は、Ｃを２で割った剰余が０であれば１であり、そうでなければ０である。すなわち、Ｃが２の倍数かどうかがチェックされる。＆＆は論理和を意味し、たとえば、（Ａ ＆＆ Ｂ）は、Ａが１であり、かつＢが１である場合に１になる。ｃｙｃｌｅ［］はどの周期でパケットを１つ増加させるかを決める配列変数である。本実施例では、１０ｍｓに一度、規定数のパケットを送信するが、１０ｍｓのｎ倍の周期にパケットを増やしたい場合にｃｙｃｌｅ［ｎ］＝１とする。たとえば、２倍の周期で１パケット増やすのであればｃｙｃｌｅ［２］＝１とし、４倍の周期で１パケット増やすのであればｃｙｃｌｅ［４］＝１とし、６倍の周期ではパケットを増やさないのであればｃｙｃｌｅ［６］＝０とする。なお、Ｎ＿ｂａｓｅの計算およびｃｙｃｌｅ［］のセットは図６に関連して説明するようにバッファ状態受信処理部１０３において行われる。

式６において、基準パケット数以下の項は、送信レートを細かく調整するための工夫で、たとえば、基準パケット数を２４１としたとき、１周期平均２４１．５パケットを送信したければ、第２項のｃｙｃｌｅ［２］を１に設定すればよい。カウンタＣが偶数の時に第２項の値は１となり、パケットが基準パケット数よりも１つ余に送信され、奇数のときは基準パケット数だけ送信される。これが交互に繰り返されるため、平均２４１．５パケット／周期が実現できる。同様に第３項は、カウンタＣが４の倍数のときだけパケットを送信するための工夫で、１周期あたり０．２５パケットだけ送信レートが上乗せになる。以下同様にして、送信レートを細かく調整する。

次に端末通信処理部１０２のリカバリーモードについて説明する。リカバリーモードとは、送信レートと受信側の映像再生レートが一致しているとき、受信側バッファ量が目標値よりも大きく外れている場合に、その補正を行なうモードである。受信側の映像処理速度と送信側のデータ送信速度がほぼ一致しており、バッファ使用量の変化がない（あらかじめ決めた基準内に収まっている）ときバッファ使用量を目標量に近づけるためのモードである。このモードに入っている間は、バッファ使用量の目標量に対する不足分（あるいは超過分）に対応するデータ量だけ、パケットを増やす（あるいは減らす）ことによって、バッファ量が目標値に一致するようにする。この調整により、システムの負荷増大等によりバッファ量が大きく変動してもパケットが消失しないようにできる。なお、このモードの間はバッファ量は当然に大きく変化するので、変化率の測定結果は無視する。なお、リカバリーモードに入るかどうかはバッファ状態受信処理部１０３が決定するが、この点については後述する。端末通信処理部１０２は、リカバリーモードがセットされている時には、受信バッファの使用量の目標値と現在の受信バッファの使用量の差分に基づいて、毎周期ごとにパケット数を増減する。

以下、リカバリーモードがセットされている時の端末通信処理部１０２の動作を図３、図４を用いて説明するが、その前に、ここで用いられる変数について説明する。ＡＤＤは、使用バッファの目標量と現在の使用バッファ量との差分のデータ量を示す変数で、パケットを単位とする。ＡＤＪは、パケットの増減に関する変数で、その周期（１０ｍｓ）において、パケットを減らすのであれば−１、増やすのであれば１を代入し、送信パケット数Ｎを調整する。

図３、図４に示すように、もしもリカバリーモードにはいっていれば（３０３、４０３でＹｅｓ）、以下の処理を行なう。変数ＡＤＤ＞０であれば（３１１、４１１でＹｅｓ）、ＡＤＤから１を減算し、ＡＤＪ＝１と設定する（３１２、４１２）。変数ＡＤＤ＜０であれば（３１３、４１３でＹｅｓ）、ＡＤＤに１を加算し、ＡＤＪ＝−１と設定する（３１４、４１４）。次に、送信パケット数ＮにＡＤＪを加える（３１５〜３１６、４１５）。もし、ＡＤＤがゼロになっていれば（３１８、４１８でＹｅｓ）、リカバリーモードを解除する（３１９、４１９）。

すなわち、リカバリーモードに入ると、使用バッファ量の目標値と現在のバッファ量との差分のデータ量をパケットを単位とする変数ＡＤＤに格納し、使用バッファ量の目標値＞現在のバッファ量であれば（ＡＤＤ＞０）、ＡＤＪ＝１とし、使用バッファ量の目標値＜現在のバッファ量（ＡＤＤ＜０）であれば、ＡＤＪ＝−１として、毎周期にパケットを±１することによって、使用バッファ量の目標値に近づける。ＡＤＪは±２等であってもよく、システムへの負荷、ネットワークへの負荷等を考慮して決めればよい。

以上の処理の後、Ｎパケット分の映像データを映像パケット受信装置１５０側に送信し（３２０、４２０）、カウンタＣに１加算する（３２１、４２１）。

図５、図６は、バッファ状態受信処理部１０３の動作を示した図である。図５は図３の方式１に対応しており、図６は図４の方式２に対応している。初期状態では、映像パケット受信装置１５０側からの状態通知パケット１２２を待っている（５０１、６０１）。状態通知パケットを受信すると、リカバリーモードに入っているかどうかをチェックし（５０２、６０２）、リカバリーモードであれば（５０２、６０２でＹｅｓ）、直ちに、再び状態通知パケットの受信状態に入る（５０１、６０１）。このようにする理由は、リカバリーモード時の使用バッファ量の変化率を送信パケット数の決定に反映させないためである。

リカバリーモードに入っていなければ（５０２、６０２でＮｏ）、状態通知パケットで通知された、バッファ量の変化率Ｒのチェックを行なう（５０３、６０３）。変化率Ｒが１フレーム分のデータ量の０．１％以上であれば（５０３、６０３でＮｏ）、送信レートを変更する。方式１の場合は変化率を元に基準パケット数Ｎ＿ｂａｓｅおよび端数Ｆ＿ｒａｃを計算し（５０４）、方式２の場合は変化率を元に基準パケット数Ｎ＿ｂａｓｅを計算すると共に変化率を元に送出パケット数を決定する配列ｃｙｃｌｅ［］を更新して（６０４）、映像の送信レートを変更し、状態通知パケットの受信状態に入る（５０１、６０１）。なお、本実施例では、５０３、６０３で１フレーム分のデータ量の０．１パーセントに収まっているかどうかを判断しているが、この数字は固定ではなく、１秒間に変化するライン数（１フレームは１１２５ライン）とすることもでき、バッファ量の変化について、どの程度の安定性を求めているかによって変わる値である。すなわち、バッファ状態受信処理部１０３は、変化率が予め決められた基準を外れた場合に、変化率に基づいて送信レートを変更すればよい。

５０４における基準パケット数Ｎ＿ｂａｓｅおよび端数Ｆ＿ｒａｃの計算は、本実施例においては、前述の式２により変化率Ｒを元に送信すべきデータ量Ｍを計算し、このＭを用いて前述の式４でＮ＿ｂａｓｅを、前述の式５でＦ＿ｒａｃを計算することにより行う。６０４における基準パケット数Ｎ＿ｂａｓｅの計算も同様である。６０４におけるｃｙｃｌｅ［］の決定については式６に関連して述べたことをアルゴリズムあるいはテーブルとして保持しておき、それを用いて決定すればよい。

バッファ状態受信処理部１０３がこのようにして設定した値を用いて、端末通信処理部１０２は、映像パケット受信装置１５０の受信バッファ１５１の変化率に基づいて調整されたパケット数のパケットを映像パケット受信装置１５０に送信する（図３、図４参照）。

変化率が１フレーム分のデータ量の０．１％未満であれば（５０３、６０３でＹｅｓ）、変化率が既定の範囲（最大許容値と最小許容値の間）に収まっているかどうかを確認する（５０５、６０５）。もしも収まっていなければ（５０５、６０５でＮｏ）、使用受信バッファ量の目標量と現在の瞬時値との値の差ＡＤＤを計算し（５０７、６０６）、リカバリーモードに入る（５０７、６０７）。再び、状態通知パケットの受信待ちに入る（５０１、６０１）。変化率が既定の範囲（最大許容値と最小許容値の間）に収まっていれば（５０５、６０５でＹｅｓ）、直ちに状態通知パケットの受信待ちに入る（５０１、６０１）。

このようにして、バッファ状態受信処理部１０３は、映像パケット受信装置１５０の受信バッファ１５１の使用量の変化率が予め決められた基準内に収まり、受信バッファの使用量が目標値から外れている場合に、リカバリーモードをセットする。

次に、映像パケット受信装置１５０側のバッファ状態通知処理部１５２の動作について説明する。受信バッファ１５１の使用量の測定周期が高精度であれば、一回の測定でもある程度は正確な変化率を求めることが可能であるが、本システムでは、非リアルタイムオペレーティングシステムをベースとしたスケジューラを使っているため、この受信バッファ量の読み出し周期に変動が起こり、１周期の測定だけでは、変化率が正確には求められない。

そこで、瞬時値のデータをメモリに格納しておき、数周期から数十周期分のデータから、可能な限り正確な変化率を算出する。具体的には、（１）数秒毎に最小二乗法を用いて受信バッファ使用量の変化率を求める方法（方式３）、（２）数秒ごとに各周期の変化率の平均を求める方法（方式４）、（３）数秒ごとに、この期間の受信データ総量と描画された映像フレームの総量との差分を取り、変化率を求める方法（方式５）などの方法を用いる。

図７は、上記の（１）の方式（方式３）に基づいて、映像パケット受信装置１５０側のバッファ状態通知処理部１５２の動作を示したものである。初期状態では、映像フレームの受信を待っている（７０１）。フレームｘを受信すると、直ちに受信バッファ使用量ｙをメモリ上の配列ｄａｔａ［］に記録する（７０２、７０３）。これを既定の受信フレーム数ｎ（例えば１５０フレーム＝約５秒間）に到達するまで繰り返す（７０４）。次に、メモリ上の受信バッファ使用量を格納した配列ｄａｔａ［］を元に、式７のように最小二乗法を用いて受信バッファ使用量の１フレームあたりの変化率を計算する（７０５）。これにより、ジッタの影響を少なくすることができる。この変化率と受信バッファ使用量の瞬時値とともに、映像パケット送信装置（ストリームサーバ）１００側に通知し（７０６）、再びフレーム受信を待つ（７０１）。なお、式７において＾２は２乗を意味する。
変化率 Ｒ＝（ｎΣｘｙ−ΣｘΣｙ）／（ｎΣｘ＾２−（Σｘ）＾２） （式７）
ｎ＝１５０（サンプルしたデータ数）
ｘ：フレーム番号
ｙ：受信バッファ量の瞬時値
図８は、上記の（２）の方式（方式４）に基づいて、映像パケット受信装置１５０側のバッファ状態通知処理部１５２の動作を示したものである。初期状態では、映像フレームの受信を待っている（８０１）。フレームを受信すると、直ちに受信バッファの変化量ｚをメモリ上の配列ｄａｔａ［］に記録する（８０２、８０３）。これを既定の受信フレーム数ｎ（例えば１５０フレーム：約５秒間）に到達するまで繰り返した後（８０４でＹｅｓ）、式８のように１フレームあたりの平均の変化率を計算し（８０５）、その変化率をこの時点の受信バッファ使用量の瞬時値とともに、映像パケット送信装置側に通知し（８０６）、再びフレーム受信を待つ（８０１）。
変化率 Ｒ＝Σｚ／ｎ （式８）

図９は、上記の（３）の方式（方式５）に基づいて、映像パケット受信装置１５０側のバッファ状態通知処理部１５２の動作を示したものである。初期状態では、映像フレームの受信を待っている（９０１）。フレームを受信すると、直ちに映像フレームサイズを変数ｘに加え、前回フレーム受信から今回までの間に受信したパケットサイズの合計を変数ｙに加える（９０２、９０３）。これを既定の受信フレーム数ｎ（例えば１５０フレーム＝約５秒間）に到達するまで繰り返した後（９０４でＹｅｓ）、式９のように１フレームあたりの平均の変化率を計算し、ｘ＝ｙ＝０として（９０５）、その変化率をこの時点の受信バッファ使用量の瞬時値とともに、映像パケット送信装置側に通知し（９０６）、再びフレーム受信を待つ（９０１）。
変化率 Ｒ＝（ｙ−ｘ）／ｎ （式９）

以上説明した実施例においては、使用バッファ量の瞬時値だけでなく、その変化率も送ることで、正確に送信速度を調整することができるため、瞬時値だけを通知して送信パケット数を調整するアドホックな方法を取る場合に比べ、通知パケット数(通知メッセージ数)を減らすことができるので、ネットワークや送信装置にかける負担を減らすことができる。その効果は多重ストリーム環境で使う場合、特に顕著と考えられる。

すなわち、瞬時値だけを送信側に通知する場合、瞬時値が使用バッファ量の目標量より小さければ増速、大きければ減速といった、アドホックかつ単純な方法をとることで、使用バッファ量を目標値に近づけることも可能である。しかし、この大雑把な方法では、送信側に瞬時値を頻繁に通知しなければならないので、システムやネットワーク全体の負荷を増大させることになる。また、ネットワークには、伝送遅延という遅れ要素があるので、通知された瞬時値だけを元に送信速度を調整すると、どうしても発振してしまうことになる。

これに対して、本実施例では、送信速度と受信処理速度差をゼロにする、つまり使用バッファ量の変化率をゼロにすることで、送信速度を正確に補正する方法である。バッファ量の変化率は、データ転送の全期間にわたって、それほど大きな変動はないため、ゆらぎの大きい瞬時値よりも、変化率を元に補正したほうが、安定度の高い転送が望める。

この場合、正確な変化率を求める必要がある。使用バッファ量の変化率は、受信側で測定せず、通知された側(送信側)で、複数回の瞬時値の通知結果を元に計算することも可能であるが、これは要するに、受信側でやっている変化率計算処理を送信側にやらせることになるため、送信側処理の負荷があがり、瞬時値のデータ転送によりネットワークの負荷も(若干)上がる。

送信側は多重ストリームを扱わなければならないので、できるだけ１ストリームあたりの負荷を下げる必要があり、受信側にできることは全て受信側でやったほうが都合がいい。しかし、送信側の能力とネットワーク帯域に十分な余裕がある場合には、送信側で計算しても構わない。

以上のことから、本実施例では使用バッファ量の瞬時値およびその変化率を映像パケット受信装置１５０が映像パケット送信装置１００に送信するが、一般には、映像パケット受信装置１５０の受信バッファ１５１の状態に関する通知を、映像パケット受信装置１５０が映像パケット送信装置１００に送り、映像パケット送信装置１００のバッファ状態受信処理部１０３がその通知を受信し、擬似リアルタイムスケジューラ部１０１が周期的に端末通信処理部１０２を起動し、端末通信処理部１０２が擬似リアルタイムスケジューラ部１０１によって起動される各周期において、バッファ状態受信処理部１０３が受信したその通知に基づいて調整されたパケット数のパケットを映像パケット受信装置１５０に送信すればよい。

以上に説明した実施例の映像パケット送信装置および映像パケット受信装置はコンピュータと記憶装置に記憶されたプログラムによって実現することができる。また、そのプログラムの一部または全部をハードウェアで実現してもよい。

以上、本発明者によってなされた発明を、前記実施形態に基づき具体的に説明したが、本発明は、前記実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々変更可能であることは勿論である。

実施例の全体図 疑似リアルタイムスケジューラ部１０１の動作 端末通信処理部１０２の動作（方式１） 端末通信処理部１０２の動作（方式２） バッファ状態受信処理部１０３の動作（方式１） バッファ状態受信処理部１０３の動作（方式２） バッファ状態通知処理部１５２の動作（方式３） バッファ状態通知処理部１５２の動作（方式４） バッファ状態通知処理部１５２の動作（方式５）

符号の説明

１００…映像パケット送信装置、１０１…疑似リアルタイムスケジューラ部、１０２…端末通信処理部、１０３…バッファ状態受信処理部、１０４…ディスク装置、１０５…ネットワークインタフェース、１０６…Ｌｉｎｕｘカーネル、１５０…映像パケット受信装置、１５１…受信バッファ、１５２…バッファ状態通知処理装置、１２０…パケット網、１２１…動画ストリーム、１２２…状態通知パケット

Claims (10)

1. パケット網を介してパケット受信装置にストリームデータを送信するパケット送信装置であって、
   前記パケット受信装置の受信バッファの状態に関する通知を前記パケット受信装置から受信するバッファ状態受信処理部と、
   周期的に端末通信処理部を起動するスケジューラ部と、
   前記スケジューラ部によって起動される各周期において、前記バッファ状態受信処理部が受信した前記通知に基づいて調整されたパケット数のパケットを前記パケット受信装置に送信する端末通信処理部と、
   を備えるパケット送信装置。
2. 請求項１に記載のパケット送信装置であって、
   前記通知は前記パケット受信装置の受信バッファの使用量の変化率を含み、
   前記端末通信処理部は、前記変化率に基づいて調整されたパケット数のパケットを前記パケット受信装置に送信するパケット送信装置。
3. 請求項２に記載のパケット送信装置であって、
   前記バッファ状態受信処理部は、前記変化率が予め決められた基準を外れた場合に、前記変化率に基づいて送信レートを変更するパケット送信装置。
4. 請求項１ないし３のうちいずれか１項に記載のパケット送信装置であって、
   前記端末通信処理部は、予め定められた周期ごとに、送信すべきデータ量の端数を調整するパケット数でパケットを送信するパケット送信装置。
5. 請求項１ないし３のうちいずれか１項に記載のパケット送信装置であって、
   前記端末通信処理部は、送信すべきデータ量の端数を分散して調整するパケット数でパケットを送信するパケット送信装置。
6. 請求項１ないし５のうちいずれか１項に記載のパケット送信装置であって、
   前記通知は前記パケット受信装置の受信バッファの使用量とその変化率を含み、
   前記バッファ状態受信処理部は、前記パケット受信装置の受信バッファの使用量の変化率が予め決められた基準内に収まり、受信バッファの使用量が目標値から外れている場合に、リカバリーモードをセットし、
   前記端末通信処理部は、リカバリーモードがセットされている時には、受信バッファの使用量の目標値と現在の受信バッファの使用量の差分に基づいて、毎周期ごとにパケット数を増減するパケット送信装置。
7. 請求項１ないし６のうちのいずれか１項に記載のパケット送信装置からパケット網を介してストリームデータを受信するパケット受信装置であって、
   前記パケット送信装置から受信したデータを一時的に蓄える受信バッファと、
   前記受信バッファの状態に関する通知を前記パケット送信装置に送信するバッファ状態通知処理部と、
   を備えるパケット受信装置。
8. 請求項１ないし６のうちいずれか１項に記載のパケット送信装置と請求項７に記載のパケット受信装置を有するシステム。
9. 請求項１ないし６のうちのいずれか１項に記載のパケット送信装置のためのプログラムであって、
   前記バッファ状態受信処理部と前記スケジューラ部と前記端末通信処理部としてコンピュータを機能させるためのプログラム。
10. 請求項７に記載のパケット受信装置のためのプログラムであって、
    前記バッファ状態通知処理部としてコンピュータを機能させるためのプログラム。
    
    

Images