JP2002084339A - ストリーミング方法およびそれを実行するシステム - Google Patents

Abstract

(57)【要約】 【課題】 端末のバッファ容量が機種によって異なって
いても、ネットワークの伝送能力が変動しても、ストリ
ーミング再生の破綻を回避することが可能であり、しか
も、ストリーミング再生の破綻回避と、頭出し時の待ち
時間短縮とを互いに両立させることができるようなスト
リーミング方法を提供する。 【解決手段】 端末は、自身のバッファ容量とネットワ
ークの伝送能力とに関連して、自身のバッファに蓄積す
べきストリームの目標量（Ｓ＿ｔａｒｇｅｔ）を決定
し、また、バッファ容量を伝送能力で除して得られる値
を超えない範囲内で任意に、自身のバッファにストリー
ムの先頭データを書き込んでからそのデータを読み出し
て再生開始するまでの遅延時間（Ｔ＿ｄｅｌａｙ）を決
定して、それら目標量および遅延時間をサーバに通知す
る。サーバは、通知に基づき、端末のバッファ占有量
（Ｓｕｍ）が目標量の近傍で目標量を超えずに遷移する
ように、送信速度を制御する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ストリーミング方
法に関し、より特定的には、サーバが端末へインターネ
ットを通じてマルチメディアデータを送信し、かつ端末
がそのデータを受信しつつ再生するためのストリーミン
グ方法に関する。

【０００２】

【従来の技術】（マルチメディアデータの符号化圧縮方
式およびバッファモデルの説明）インターネットでの伝
送に使用されるマルチメディアデータには、動画、静止
画、音声、テキスト、およびそれらが多重化されたデー
タ等、さまざまな種類がある。動画では、Ｈ．２６３や
ＭＰＥＧ１、２、４といった符号化圧縮方式が著名であ
るし、静止画としてはＪＰＥＧ、音声では、ＭＰＥＧオ
ーディオ、Ｇ．７２９など枚挙にいとまがない。

【０００３】本発明では、ストリーミング再生に的を絞
っているので、動画および音声が伝伝送の対象となる。
ここでは、動画圧縮方式の代表であるＭＰＥＧビデオ、
中でも比較的仕組みが単純なＭＰＥＧ１（ＩＳＯ／ＩＥ
Ｃ １１１７２）ビデオや、ＭＰＥＧ２（ＩＳＯ／ＩＥ
Ｃ １３８１８）ビデオについて説明する。

【０００４】ＭＰＥＧビデオは、高効率なデータ圧縮を
実現するために、主に次の２つの特徴を有している。一
つ目は、動画像データの圧縮において、従来から行われ
ていた空間周波数特性を用いた圧縮方式の他に、フレー
ム間での時間相関特性を用いた圧縮方式を取り入れたこ
とである。ＭＰＥＧでは、ストリームを構成している各
フレーム（ピクチャとも呼ぶ）を、Ｉフレーム（フレー
ム内符号化ピクチャ）、Ｐフレーム（フレーム内符号化
と過去からの参照関係を使用したピクチャ）、Ｂフレー
ム（フレーム内符号化と過去および未来からの参照関係
を使用したピクチャ）の３種類に分類してデータ圧縮を
行う。これらの３種では、Ｉフレームが最も大きく（つ
まり情報量が最も多く）、次いでＰ、Ｂの順である。圧
縮アルゴリズムにも大きく依存するが、情報量の比は、
おおよそＩ：Ｐ：Ｂ＝４：２：１程度となる。また一般
的に、ＭＰＥＧビデオストリームは、１５フレーム（＝
１ＧＯＰ）を単位として、１ＧＯＰについてＩフレーム
が１枚、Ｐフレームが４枚、Ｂフレームが１０枚の割合
で含まれている。

【０００５】ＭＰＥＧビデオの二つ目の特徴は、画像の
複雑さに応じた動的な符号量割り当てをピクチャ単位で
行える点である。ＭＰＥＧのデコーダは、デコーダバッ
ファを備え、このデコーダバッファにデータを蓄積して
からデコードを行うことで、圧縮の難しい複雑な画像に
対して大量の符号量を割り当てることが可能になってい
る。ＭＰＥＧに限らず動画圧縮では、標準的なデコーダ
バッファの容量を規格で定義する場合が殆どである。Ｍ
ＰＥＧ１やＭＰＥＧ２の場合、標準デコーダバッファ
は、規格で容量が２２４ＫＢｙｔｅと定義されており、
ＭＰＥＧエンコーダは、この容量の範囲内でデコーダバ
ッファ占有量が遷移するようにピクチャデータを生成し
なければならない。

【０００６】図１９（Ａ）〜（Ｃ）は、従来のストリー
ミング方法を説明するための図である。図１９（Ａ）
は、ビデオフレームを示す図、図１９（Ｂ）は、バッフ
ァ占有量の遷移を模式的に示した図、図１９（Ｃ）は、
従来端末の構成例を示す図である。図１９（Ｃ）におい
て、端末は、ビデオバッファと、ビデオデコーダと、
Ｉ，Ｐ並べ替えバッファと、スイッチとを備えている。
ビデオバッファが、前述のデコーダバッファに相当し、
転送されてくるデータは、ビデオバッファに蓄積された
後、ビデオデコーダによってデコードされる。デコード
されたデータは、Ｉ，Ｐ並べ替えバッファおよびスイッ
チを通じて再生時刻順に並べ替えられる。

【０００７】図１９（Ｂ）において、縦軸はバッファ占
有量（ビデオバッファのデータ蓄積量）を、横軸は時間
を示し、図中の太線がバッファ占有量の時間的遷移を示
している。また、太線の傾きは、ビデオのビットレート
に相当し、一定のレートでデータがバッファに入力され
ていることを示している。また、一定間隔（３３．３６
６７ｍｓｅｃ）でバッファ占有量の削減が起こっている
が、これは、一定周期で各フレームのデータがデコード
されていくことによる。また、斜め点線と時間軸との交
点は、各ビデオフレーム内のデータがビデオバッファへ
向けて転送開始される時刻を示している。従って、図１
９（Ａ）に示されたフレームＸの転送開始時刻はｔ１、
フレームＹの転送開始時刻はｔ２となる。

【０００８】図１９（Ａ），（Ｂ）において、ビデオの
先頭フレームＸがビデオバッファに入力開始される時刻
ｔ１から、最初にデコードが実行される時刻（図中、太
線の第１の立ち下がり位置）までの時間を一般に、ｖｂ
ｖ＿ｄｅｌａｙ時間と呼ぶ。最初のデコードは、ビデオ
バッファが満杯になった瞬間に実行されるので、ｖｂｖ
＿ｄｅｌａｙ時間は、通常、データ入力開始から容量２
２４ＫＢｙｔｅのビデオバッファが満杯になるまでの時
間であり、従って、ビデオの入力が開始されてから、デ
コーダを通じてビデオ再生が開始されるまでの初期遅延
時間（頭出し時の待ち時間）ということになる。

【０００９】図１９（Ａ）のフレームＹが複雑な画像で
ある場合、図１９（Ｂ）に示されているように、その符
号量が大量なので、フレームＹのデコード時刻（図中の
ｔ３）よりも早い時刻（図中のｔ２）から、ビデオバッ
ファへのデータ転送を開始しなければならない。ただ
し、どんなに複雑な画像でも、バッファを占有するピク
チャ量は、２２４ＫＢｙｔｅの許容範囲内である。

【００１０】図１９（Ｂ）に示したバッファ遷移がきち
んと保たれるようにビデオバッファにデータが転送され
るならば、ビデオバッファのアンダーフローやオーバー
フローによるストリーミング破綻が起こらないことは、
ＭＰＥＧの規格で保証されている。

【００１１】（ネットワーク転送ジッタ吸収用の受信バ
ッファの説明）ところが、図２０に示すように、サーバ
２０１と端末２０２とをネットワーク２０３で接続し、
ストレージ２１０中のＭＰＥＧデータを配信する場合、
生成モジュール２１１でパケットを生成する時間や、ネ
ットワーク機器２０４，２０５における転送手続き時
間、ネットワーク２０３の混雑などに伴なう伝送遅延時
間などのために、データの転送レートに揺れが生じる。
従って、実際には、図１９（Ｂ）に示したバッファ遷移
が保たれないのが実情である。このような転送レートの
揺れ（ジッタ）を緩和吸収する方法としては、まず、ネ
ットワークの帯域に比べ十分小さい符号化レートのコン
テンツを流すことが考えられる。しかし、ネットワーク
資源をできる限り有効に使って高品位な映像や音声を提
供する必要があるので、この方法は適切ではない。そこ
で、一般には、ネットワーク機器２０４，２０５に、そ
れぞれ適当な容量の送受信バッファ２０６，２０７を設
け、普段からデータを多少先送り気味に転送しておい
て、データ転送に遅延が発生した時の不足を補う方法が
採用される。

【００１２】ここで、端末２０２側に受信バッファ２０
７を設けるということは、結局、図１９（Ｂ）のバッフ
ァ遷移において、バッファ占有量の上限を、デコーダバ
ッファ２０８の規格である２２４ＫＢｙｔｅから受信バ
ッファ２０７による蓄積量の分だけかさ上げするのとお
おむね等価である。図２１（Ａ），（Ｂ）に、受信バッ
ファ２９７を追加する前後のバッファ占有量を並べて示
す。なお、図２１（Ａ）に示されているのは、図１９
（Ｂ）と同一のバッファ遷移である。

【００１３】受信バッファ２０７の追加によって、バッ
ファ遷移の許容範囲が拡がり、その結果、図１９（Ｂ）
のバッファ遷移、すなわち図２１（Ａ）のバッファ遷移
は、図２１（Ｂ）のようになって、ネットワークの転送
レートが低下しても、アンダーフローを回避することが
可能となる。反面、ｖｂｖ＿ｄｅｌａｙ時間が、受信バ
ッファ２０７による蓄積量に相当する時間だけ長くな
り、デコーダ２０９でのデコード開始および再生装置２
１２での再生開始が遅れる。つまり、頭出し時間が、受
信バッファ２０７へのデータ蓄積にかかる時間の分だけ
長くなる。

【００１４】

【発明が解決しようとする課題】以上から明らかなよう
に、小規模ＬＡＮなどの信頼性や伝送速度の保証された
ネットワーク環境において、ＭＰＥＧ等のマルチメディ
アデータをストリーミング再生する場合には、基本的
に、コーデックの規格で定められた再生初期遅延時間
（ｖｂｖ＿ｄｅｌａｙ）やデコーダバッファ遷移をきち
んと遵守するようなシステム設計になってさえいれば、
デコーダバッファのアンダーフローやオーバーフローが
起こってストリーミング再生が破綻をきたすことはな
い。

【００１５】しかしながら、インターネットなどの広域
ネットワーク環境においては、通信経路の伝送特性変動
に伴なう転送ジッタが無視できないほど大きいため、従
来の端末２０２は、コーデックの規格で定められたデコ
ーダバッファ（ｖｂｖバッファ）に加えて、図２０の受
信バッファ２０７のような、転送ジッタ吸収のためのバ
ッファを持つ場合が多い。このとき、次のような課題が
存在する。

【００１６】端末に搭載されるジッタ吸収用のバッファ
の容量は、一般に、機種によって様々である。そのた
め、同じデータを同じ条件下で配信しても、バッファ容
量の多い機種ではストリーミング再生を破綻なく行える
が、少ない機種では、ジッタを吸収しきれずに破綻する
場合があった。

【００１７】この課題を解決するには、例えば、端末の
搭載メモリ量を増やして、ジッタ吸収用のバッファ容量
を十分確保すればよい。しかしながら、搭載メモリ量
は、端末の価格を決める主な要因の一つであり、可能な
限り少なく抑えたい要求がある。加えて、ジッタ吸収用
のバッファ容量が多すぎると、再生開始までの頭出し時
間が長くなって、ユーザにいらだちを感じさせてしまう
という新たな問題が発生する。

【００１８】それゆえに、本発明の目的は、端末のバッ
ファ容量が機種によって異なっていても、ネットワーク
の伝送能力が変動しても、バッファのアンダーフローや
オーバーフローによるストリーミング再生の破綻を回避
することが可能であり、しかも、ストリーミング再生の
破綻回避と、頭出し時の待ち時間短縮とを互いに両立さ
せることができるようなストリーミング方法を提供する
ことである。

【００１９】

【課題を解決するための手段および発明の効果】第１の
発明は、サーバが端末へネットワークを通じてストリー
ムデータを送信し、かつ端末が当該ストリームデータを
受信しつつ再生するストリーミング方法であって、端末
が、自身のバッファ容量とネットワークの伝送能力とに
関連して、自身のバッファに蓄積すべきストリームデー
タの目標量を決定する目標量決定ステップ、当該バッフ
ァ容量を当該伝送能力で除して得られる値を超えない範
囲内で任意に、端末が、自身のバッファにストリームの
先頭データを書き込んでから当該データを読み出して再
生開始するまでの遅延時間を決定する遅延時間決定ステ
ップ、決定した目標時間および遅延時間を、端末がサー
バに通知するステップ、サーバが端末へネットワークを
通じてストリームデータを送信する際に、通知された目
標量および遅延時間に基づいて送信速度を制御する制御
ステップを備える。

【００２０】上記第１の発明では、端末が、自身のバッ
ファ容量とネットワークの伝送能力とに応じた目標量を
決定し、さらに、バッファ容量を伝送能力で除して得ら
れる値を超えない範囲内で、遅延時間を決定する。サー
バは、こうして端末が決定した目標量および遅延時間に
基づいて送信速度を制御するので、端末のバッファ容量
が機種によって異なっていても、ネットワークの伝送能
力が変動しても、バッファ量および伝送能力に応じた送
信速度制御が行え、その結果、バッファのアンダーフロ
ーやオーバーフローによるストリーミング再生の破綻を
回避することが可能となる。しかも、目標量とは独立に
遅延時間が決定されるので、ストリーミング再生の破綻
回避と、頭出し時の待ち時間短縮とを互いに両立させる
ことができる。

【００２１】ここで、遅延時間が、バッファ容量を伝送
能力で除して得られる値以下に制限されるのは、遅延時
間がこの値を超えると、ストリーミング再生の破綻が起
こる恐れがあるためである。この値を超えない範囲であ
れば、遅延時間をどのような値に決めてもよい。ただ
し、値を決める際には、伝送能力の変動に対する耐性
と、頭出し時の待ち時間との間のバランスが考慮され
る。

【００２２】第２の発明は、第１の発明において、制御
ステップにおいて、サーバは、端末のバッファに蓄積さ
れているストリームデータの量が、当該目標量の近傍に
おいて当該目標量を超えることなく遷移するように、当
該送信速度を制御することを特徴とする。

【００２３】上記第２の発明では、蓄積量が目標量の近
傍において目標量を超えることなく遷移するので、バッ
ファのアンダーフローやオーバーフローが起こりにく
い。

【００２４】第３の発明は、第２の発明において、制御
ステップにおいて、サーバは、当該送信速度と、当該遅
延時間と、端末がストリームデータをデコードする速度
とに基づいて、端末のバッファに蓄積されるストリーム
データの量を予測算出することを特徴とする。

【００２５】上記第３の発明では、サーバが蓄積量を予
測算出して、その量に基づいて送信速度制御を行うの
で、蓄積量を目標量の近傍で目標量を超えないように遷
移させることができる。

【００２６】ここで、端末が現在の蓄積量をサーバに通
知し、サーバは、通知に基づいて送信速度制御を行って
もよい。しかし、この場合、端末からサーバへの情報伝
達に時間がかかるので、サーバは、過去の蓄積量に基づ
いて送信速度制御を行うことになる。そのため、蓄積量
を目標量の近傍で目標量を超えないように遷移させるこ
とができるとは限らない。

【００２７】第４の発明は、第１の発明において、端末
が、ネットワークの伝送能力が所定の閾値を跨いで変化
したことを検出する検出ステップ、検出ステップでの検
出結果に応じて、端末が当該目標量を変更する目標量変
更ステップ、および変更後の目標量を、端末がサーバに
通知するステップをさらに備え、制御ステップにおい
て、サーバは、変更後の目標量の通知を受けると、端末
のバッファに蓄積されるストリームデータの量が、当該
変更後の目標量の近傍において当該変更後の目標量を超
えることなく遷移するように、当該送信速度を制御する
ことを特徴とする。

【００２８】上記第４の発明では、伝送能力が閾値を跨
いで変化すると、端末によって目標量が変更される。サ
ーバは、変更後の目標量の近傍において変更後の目標量
を超えることなく遷移するように送信速度を制御して、
目標量の変更に追従する。

【００２９】第５の発明は、第４の発明において、検出
ステップでネットワークの伝送能力が第１の閾値を跨い
で低下したことを検出すると、端末は、目標量変更ステ
ップにおいて、当該目標量を増加させる向きに変更し、
制御ステップにおいて、サーバは、当該目標量が増加さ
れたのに応じて、当該送信速度を上昇させる向きに制御
することを特徴とする。

【００３０】上記第５の発明では、伝送能力が第１の閾
値を跨いで変化すると、端末によって目標量が増加され
る。サーバは、送信速度を上昇させることにより、目標
量の増加に追従する。

【００３１】第６の発明は、第５の発明において、当該
第１の閾値は、実現可能な最大の伝送能力と、ストリー
ムデータの転送ロスが発生し始めるような伝送能力との
略中間の値であることを特徴とする。

【００３２】上記第６の発明では、伝送能力が低下しつ
つあるとき、ストリームデータの転送ロスが発生し始め
る前に、送信速度を上昇させて蓄積量を増やしておく。
これにより、伝送能力の低下が進行したときに、ストリ
ーミング再生が破綻するのを防ぐことができる。

【００３３】第７の発明は、第４の発明において、検出
ステップでネットワークの伝送能力が当該第１の閾値よ
り小さい第２の閾値を跨いで低下したことを検出する
と、端末は、目標量変更ステップにおいて、当該目標量
を減少させる向きに変更し、制御ステップにおいて、サ
ーバは、当該目標量が減少方向に変更されたのに応じ
て、当該送信速度を低下させる向きに制御することを特
徴とする。

【００３４】上記第７の発明では、伝送能力が第２の閾
値を跨いで変化すると、端末によって目標量が減少され
る。サーバは、送信速度を低下させることにより、目標
量の減少に追従する。

【００３５】第８の発明は、第７の発明において、当該
第２の閾値は、ストリームデータの転送ロスが発生し始
めるような伝送能力と対応する値であることを特徴とす
る。

【００３６】上記第８の発明では、伝送能力の低下が進
行して、ストリームデータの転送ロスが発生し始める
と、一転、送信速度を低下させる。失われたデータの再
送処理を妨害しないためである。

【００３７】ここで、送信速度を低下させる場合、サー
バは、低下幅に応じた頻度でフレームの送信をスキップ
しなければならない。フレームがスキップされると、端
末が再生して得られる映像や音声の品位劣化が起こる。
この品位劣化を抑えるために、下記第９の発明では、ス
キップされるフレームとして、再生時刻に間に合わない
フレームが選択される。下記第１０の発明では、スキッ
プされるフレームとして、重要度の低いフレームと、重
要度は高いが再生時刻に間に合わないようなフレームと
が選択される。

【００３８】第９の発明は、第８の発明において、目標
量変更ステップにおいて、端末が当該目標量を減少させ
る向きに変更すると、制御ステップにおいて、サーバ
は、送信しようとするストリームを構成する各フレーム
の再生時刻を現在時刻と逐次比較して、再生時刻が現在
時刻よりも古いフレームの送信をスキップし、それよっ
て当該送信速度を低下方向に制御することを特徴とす
る。

【００３９】上記第１１の発明では、再生時刻に間に合
わないフレームが選択的にスキップされるので、無作為
的にスキップするのと比べて、送信速度の低下による品
位劣化を少なく抑えることができる。

【００４０】第１０の発明は、第８の発明において、目
標量変更ステップにおいて、端末が当該目標量を減少さ
せる向きに変更すると、制御ステップにおいて、サーバ
は、送信しようとするストリームを構成する各フレーム
の重要度を基準値と逐次比較して、重要度が基準値未満
であるフレームについては、全て送信をスキップし、重
要度が基準値以上であるフレームについては、それぞれ
の再生時刻を現在時刻と逐次比較して、再生時刻が現在
時刻よりも古いものだけ送信をスキップし、それによっ
て当該送信速度を低下方向に制御することを特徴とす
る。

【００４１】上記第１０の発明では、重要度の低いフレ
ームと、重要度は高いが再生時刻に間に合わないような
フレームとが選択的にスキップされるので、無作為的に
スキップするのと比べて、送信速度の低下による品位劣
化を少なく抑えることができる。

【００４２】ここで、第１０の発明のような、スキップ
すべきフレームを選択する際に再生時刻に間に合うか否
かに加えて重要度をも考慮する方法は、典型的には、Ｍ
ＰＥＧによる映像フレームに対して用いられる。この場
合、送信速度を低下させるとき、ＰやＢのフレームが重
要度の低いフレームとしてスキップされる一方、Ｉフレ
ームは、重要度の高いフレームとして、再生時刻に間に
合わない場合を除いてスキップされることがないので、
送信速度低下による再生画像の品位劣化が最小限に抑え
られる。なお、ＭＰＥＧによる音声フレームの場合、フ
レーム間に重要度の違いがないので、再生時刻に間に合
うか否かだけを考慮すればよい。

【００４３】第１１の発明は、ネットワークを通じてス
トリームデータを送信するサーバと、当該ストリームデ
ータを受信しつつ再生する端末とからなるシステムであ
って、端末は、自身のバッファ容量とネットワークの伝
送能力とに関連して、自身のバッファに蓄積すべきスト
リームデータの目標量を決定する目標量決定手段、当該
バッファ容量を当該伝送能力で除して得られる値を超え
ない範囲内で任意に、自身のバッファにストリームの先
頭データを書き込んでから当該データを読み出して再生
開始するまでの遅延時間を決定する遅延時間決定手段、
および決定した目標時間および遅延時間をサーバに通知
する手段を備え、サーバは、端末へネットワークを通じ
てストリームデータを送信する際に、通知された目標量
および遅延時間に基づいて送信速度を制御する制御手段
を備える。

【００４４】第１２の発明は、ネットワークを通じてス
トリームデータを送信するサーバと共に用いられ、当該
ストリームデータを受信しつつ再生する端末であって、
サーバには、端末へネットワークを通じてストリームデ
ータを送信する際に、通知された目標量および遅延時間
に基づいて送信速度を制御する制御手段が備わり、自身
のバッファ容量とネットワークの伝送能力とに関連し
て、自身のバッファに蓄積すべきストリームデータの目
標量を決定する目標量決定手段、当該バッファ容量を当
該伝送能力で除して得られる値を超えない範囲内で任意
に、自身のバッファにストリームの先頭データを書き込
んでから当該データを読み出して再生開始するまでの遅
延時間を決定する遅延時間決定手段、および決定した目
標時間および遅延時間をサーバに通知する手段を備え
る。

【００４５】第１３の発明は、ストリームデータを受信
しつつ再生する端末と共に用いられ、ネットワークを通
じて当該ストリームデータを送信するサーバであって、
端末には、自身のバッファ容量とネットワークの伝送能
力とに関連して、自身のバッファに蓄積すべきストリー
ムデータの目標量を決定する目標量決定手段、当該バッ
ファ容量を当該伝送能力で除して得られる値を超えない
範囲内で任意に、自身のバッファにストリームの先頭デ
ータを書き込んでから当該データを読み出して再生開始
するまでの遅延時間を決定する遅延時間決定手段、およ
び決定した目標時間および遅延時間をサーバに通知する
手段が備わり、端末へネットワークを通じてストリーム
データを送信する際に、通知された目標量および遅延時
間に基づいて送信速度を制御する制御手段を備え、制御
手段は、端末のバッファに蓄積されているストリームデ
ータの量が、当該目標量の近傍において当該目標量を超
えることなく遷移するように、当該送信速度を制御する
ことを特徴とする。

【００４６】第１４の発明は、上記第１の発明のような
ストリーミング方法を記述したプログラムである。

【００４７】第１５の発明は、上記第１４の発明のよう
なプログラムを記録した記録媒体である。

【００４８】

【発明の実施の形態】以下、本発明の実施形態につい
て、図面を参照しながら説明する。図１は、本発明の一
実施形態に係るストリーミング方法を実行するサーバ・
クライアント・システムの構成例を示すブロック図であ
る。図１において、本システムは、サーバ１０１と、そ
のクライアントとして動作する端末１０２とを備えてい
る。サーバ１０１側には、映像や音声のデータが蓄積さ
れている。このデータは、ＭＰＥＧによって符号化圧縮
されたデータである。サーバ１０１は、端末１０２から
の要求に応じ、蓄積しているデータをパケット化してス
トリームを生成する。そして、ネットワーク１０３を通
じ、生成したストリームを端末１０２に送信する。端末
１０２は、サーバ１０１から送信されるストリームを受
信してデコードし、得られた映像や音声を表示出力す
る。

【００４９】図２は、図１のサーバ１０１の構成を示す
ブロック図である。図２において、サーバ１０１は、蓄
積デバイス４１１と、送受信モジュール４０２と、生成
モジュール４０５と、ＲＡＭ４０４と、ＣＰＵ４１２
と、ＲＯＭ４１３とを備えている。蓄積デバイス４１１
には、映像や音声のデータが蓄積されている。この蓄積
デバイス４１１内のデータが生成モジュール４０５に与
えられる。生成モジュール４０５は、読み出しバッファ
４０７と、パケット生成回路４０６と、パケット生成バ
ッファ４０８とを含み、与えられるデータをパケット化
してストリームを生成する。

【００５０】送受信モジュール４０２は、ネットワーク
コントローラ４１０と、送信バッファ４０９とを含み、
生成モジュール４０５によって生成されたストリームを
端末１０２へ、ネットワーク１０３経由で送信する。ま
た、端末１０２からネットワーク１０３経由で送信され
てくる情報を受信する。

【００５１】送受信モジュール４０２によって受信され
た端末１０２からの情報は、ＲＡＭ４０４に書き込まれ
る。ＲＯＭ４１３には、サーバ制御プログラムが格納さ
れており、ＣＰＵ４１２は、ＲＡＭ４０４に記憶されて
いる端末からの情報を参照しつつＲＯＭ４１３内のプロ
グラムを実行し、それによって、送受信モジュール４０
２および生成モジュール４０５の制御を行う。なお、こ
こではプログラムがＲＯＭ４１３に格納されているとし
たが、ＲＯＭ以外の記憶媒体、例えばハードディスクや
ＣＤ−ＲＯＭ等に格納されていてもよい。

【００５２】図３は、図１の端末１０２の構成を示すブ
ロック図である。図３において、端末１０２は、送受信
モジュール５０７と、再生モジュール５１０と、表示デ
バイス５１１と、ＲＯＭ５０２と、ＣＰＵ５０３とを備
えている。送受信モジュール５０７は、ネットワークコ
ントローラ５０６と、受信バッファ５０５とを含み、サ
ーバ１０１からネットワーク１０３経由で送信されてく
るストリームを受信する。また、ＣＰＵ５０３からの情
報をサーバ１０１へ、ネットワーク１０３経由で送信す
る。

【００５３】送受信モジュール５０７によって受信され
たストリームが、再生モジュール５１０に入力される。
再生モジュール５１０は、デコーダバッファ５０８と、
デコーダ５０９とを含み、入力されるストリームをデコ
ードして再生する。再生モジュール５１０により再生さ
れたデータが表示デバイス５１１に与えられ、表示デバ
イス５１１は、そのデータを映像に変換して表示する。

【００５４】ＲＯＭ５０２には、端末制御プログラムが
格納されており、ＣＰＵ５０３は、ＲＯＭ５０２内のプ
ログラムを実行し、それによって、送受信モジュール５
０７、再生モジュール５１０および表示デバイス５１１
の制御を行う。

【００５５】以上のように構成されたシステムの動作
を、以下に説明する。図４は、図１のシステムの全体動
作を説明するためのシーケンス図である。図４には、サ
ーバ１０１側の送受信層および制御層と、端末１０２側
の送受信層および制御層とが示されており、これら各層
の間でやりとりされるコマンドやストリームが時系列的
に並べられている。

【００５６】最初、本システムの全体的な動作につい
て、図４を用いて説明する。図４において、最初、端末
１０２からサーバ１０１へ、コマンド”ＳＥＴＵＰ”が
送信される。サーバ１０１では、”ＳＥＴＵＰ”に応じ
て初期設定が行われ、設定が完了すると、サーバ１０１
から端末１０２へ、”ＯＫ”が応答される。

【００５７】サーバ１０１から”ＯＫ”が返ってくる
と、端末１０２からサーバ１０１へ、コマンド”ＰＬＡ
Ｙ”が送信される。サーバ１０１では、送信準備が行わ
れ、準備が完了すると、サーバ１０１から端末１０２
へ、”ＯＫ”が応答される。

【００５８】サーバ１０１から”ＯＫ”が返ってくる
と、端末１０２は、ストリームを待ち受ける態勢へと移
行する。この”ＯＫ”の応答に引き続いて、サーバ１０
１は、ストリームの送信を開始する。

【００５９】その後、端末１０２からサーバ１０１へ、
コマンド”ＴＥＡＲＤＯＷＮ”が送信され、サーバ１０
１は、”ＴＥＡＲＤＯＷＮ”に応じてストリーム送信を
終了する。送信が終了されると、サーバ１０１から端末
１０２へ、”ＯＫ”が応答される。サーバ１０１から”
ＯＫ”が返ってくると、端末１０２は、ストリーム待ち
受け態勢から脱する。

【００６０】以上が本システムの全体的な動作の概要で
あり、上で説明した限りでは、本システムの動作は、従
来と同様である。本システムの動作が従来と異なるの
は、次の（１）および（２）の２点である。 （１）端末１０２からサーバ１０１へのコマンド”ＳＥ
ＴＵＰ”にパラメータ”Ｓ＿ｔａｒｇｅｔ”および”Ｔ
＿ｄｅｌａｙ”が添付されており、サーバ１０１は、ス
トリームを送信する際、これらのパラメータに基づいて
送信速度を制御する。

【００６１】上記（１）において、”Ｓ＿ｔａｒｇｅ
ｔ”は、端末１０２がバッファに蓄積するデータ量の目
標値であり、その端末１０２に備わるバッファ（図３の
例では、受信バッファ５０５およびデコーダバッファ５
０８）の総容量（”Ｓ＿ｍａｘ”）と、ネットワーク１
０３の伝送能力とに基づいて決定される。従って、”Ｓ
＿ｔａｒｇｅｔ”は、一般に、端末１０２の機種によっ
て値が異なる。

【００６２】また、”Ｔ＿ｄｅｌａｙ”は、端末１０２
が先頭データをバッファに書き込んでから、そのデータ
を読み出してデコードを開始するまでの時間（つまり頭
出し遅延時間）であり、”Ｓ＿ｔａｒｇｅｔ”を送信速
度（後述）で除して得られる値を最大値として、その最
大値を超えない範囲内で任意の値に決定される。すなわ
ち、「”Ｓ＿ｔａｒｇｅｔ”を送信速度で除して得られ
る値を超えない範囲内で」という条件が付くものの、端
末１０２は、”Ｓ＿ｔａｒｇｅｔ”とは独立に”Ｔ＿ｄ
ｅｌａｙ”を決めることができる。

【００６３】また、「送信速度」は、単位時間に送信す
る情報の量をいい、例えば、単位時間に送信するパケッ
トの個数が決められている場合、各パケットに詰め込む
データの量を増減させることによって、送信速度を制御
することができる。また、各パケットに詰め込むデータ
の量が決められている場合、パケットと次のパケットと
の時間的な間隔を伸縮させることによって、送信速度を
制御することができる。あるいは、両方を同時に行う
（すなわち、各パケットに詰め込むデータの量を増減さ
せ、かつパケットと次のパケットとの時間的な間隔を伸
縮させる）ことによっても、送信速度を制御することが
できる。本実施形態では、各パケットに詰め込むデータ
の量を増減させることにより速度制御を行うものとす
る。

【００６４】（２）端末１０２は、ストリームの配信
中、必要に応じて”Ｓ＿ｔａｒｇｅｔ”を変更すること
ができる。この場合、変更後の”Ｓ＿ｔａｒｇｅｔ”が
端末１０２からサーバ１０１に通知され、以降、サーバ
１０１は、変更後の”Ｓ＿ｔａｒｇｅｔ”に基づいて送
信速度を制御する。

【００６５】上記（２）において、”Ｓ＿ｔａｒｇｅ
ｔ”の変更は、ネットワーク１０３の伝送能力の変動に
応じて行われる。具体的には、端末１０２が携帯電話の
場合、電界強度（例えば「強・中・弱・圏外」の４段階
の強度）を検知することができるので、この電界強度の
変化を「ネットワーク１０３の伝送能力の変動」と見な
して、”Ｓ＿ｔａｒｇｅｔ”を変化させる。例えば、電
界強度が「強」から「中」に変化すると、端末１０２
は、”Ｓ＿ｔａｒｇｅｔ”の値をより大きな値に変更
し、「中」から「弱」に変化すると、”Ｓ＿ｔａｒｇｅ
ｔ”の値をより小さな値に変更する。本システムの動作
が従来と異なるのは、主として上の２点である。

【００６６】次に、本システムの全体動作の具体例を詳
細に説明する。図４において、端末１０２は、ストリー
ム再生を開始するのに先立ち、端末制御プログラムに従
ってＣＰＵ５０３がＲＯＭ５０２より端末に固有のパラ
メータ群を抽出する。このパラメータ群中には、受信バ
ッファ５０５とデコーダバッファ５０８とを合わせた総
容量（端末１０２が実際に蓄積できる最大データ量）Ｓ
＿ｍａｘが含まれる。一方、ＣＰＵ５０３は、ストリー
ム再生補助データなどの事前入手の手続きによって、受
信したいストリームデータの符号化圧縮レートＶｒや、
ビデオないしオーディオのフレーム発生周期Ｔｆｒｍを
知っているものとする。また、ＣＰＵ５０３は、ネット
ワークインターフェースを通じ、ネットワーク１０３の
伝送能力、たとえば携帯電話における受信電波強度や、
通信速度（ＰＨＳの場合では６４Ｋｂｐｓ接続ないし３
２Ｋｂｐｓ接続などの情報）も検出しているものとす
る。

【００６７】ＣＰＵ５０３は、これらＳ＿ｍａｘ、Ｖ
ｒ、Ｔｆｒｍ、ネットワーク１０３の伝送能力（例えば
有効転送速度＝ｎｅｔｗｏｒｋＲａｔｅ）などをもと
に、端末１０２内のバッファにどれだけのデータを蓄積
するかを示す目標量Ｓ＿ｔａｒｇｅｔ、およびストリー
ム再生を始めるまでのプレバッファリング時間（すなわ
ち頭出し遅延時間）Ｔ＿ｄｅｌａｙを決定する。

【００６８】ここで、Ｓ＿ｔａｒｇｅｔの本質的な意味
は、今から開始するストリーミング再生において、Ｓ＿
ｔａｒｇｅｔ近傍かつそれを越えないように端末の蓄積
バッファ量が遷移すれば、途切れなく正常にストリーミ
ング再生が持続できるような基準値のことである。前述
のように、Ｔ＿ｄｅｌａｙが大きいと頭出し遅延時間が
長くなるが、ネットワーク１０３の転送ジッタに対して
は強くなる。しかし、遅延時間があまり長いとサービス
仕様として不適切なので、Ｔ＿ｄｅｌａｙを決める際に
は、転送ジッタに対する耐性と、頭出し時の待ち時間と
の間のバランスをとる配慮が必要である。

【００６９】なお、Ｔ＿ｄｅｌａｙの代わり、もしくは
Ｔ＿ｄｅｌａｙと併せて、端末１０２内のバッファにデ
ータを何バイトまで充填したらデコードを開始するかと
いう充填量Ｓ＿ｄｅｌａｙを決定してもよい。端末１０
２がＳ＿ｄｅｌａｙのみを決定してサーバ１０１に通知
する場合は、サーバ１０１側でＴ＿ｄｅｌａｙ＝Ｓ＿ｄ
ｅｌａｙ／ｎｅｔｗｏｒｋＲａｔｅなる式を用いて、Ｓ
＿ｄｅｌａｙをＴ＿ｄｅｌａｙに換算することが可能で
ある。また、Ｓ＿ｄｅｌａｙの値は、バッファ総量Ｓ＿
ｍａｘに対する充填率ｒＳ（％）であってもよい（この
場合、換算式は、Ｓ＿ｄｅｌａｙ＝Ｓ＿ｍａｘ＊ｒＳ／
１００となる）。

【００７０】端末１０２は、Ｓ＿ｔａｒｇｅｔと、Ｔ＿
ｄｅｌａｙ（および／またはＳ＿ｄｅｌａｙ）とを準備
すると、図４に示されているように、サーバ１０１に対
し、ストリーム配信の準備を促すＳＥＴＵＰコマンドを
発行する。ＳＥＴＵＰコマンド中には、引数としてＳ＿
ｔａｒｇｅｔと、Ｔ＿ｄｅｌａｙ（および／またはＳ＿
ｄｅｌａｙ）とが含まれている。サーバ１０１は、ＳＥ
ＴＵＰを受信すると、引数をＲＡＭ４０４に記憶して、
ストリーム配信のための初期設定を行う。具体的には、
サーバ１０１のＣＰＵ４１２が、最初メモリ４０４から
引数を取り出し、次いで、たとえばストリームのソース
ファイルを蓄積デバイス４１１から読み出してバッファ
４０７に書き込む操作と、読み出したデータをパケット
化するパケット生成回路４０６のパラメータ設定とを行
う。なお、パケット生成回路４０６は、必ずしも専用の
ハードウエアである必要はなく、サーバ１０１（例えば
ワークステーションなどで実現される）のＣＰＵ４１２
に同様のパケット化処理を実行させるプログラム（ソフ
トウエアアルゴリズム）であってもよい。

【００７１】前述のＳ＿ｔａｒｇｅｔと、Ｔ＿ｄｅｌａ
ｙ（および／またはＳ＿ｄｅｌａｙ）との２つの値も、
パケット生成回路４０６に引き渡される。パケット生成
回路４０６では、これらの値を用いて最適なレート制御
パラメータの算出が行われ、その結果、端末１０２への
ストリーム配信に適したレートでパケットが生成、送出
されるようになる。ネットワーク１０３中にパケットを
送出する準備が正常に完了すると、図４のように、送受
信層から制御層にＯＫが返り、次いで、端末１０２へ向
けてＳＥＴＵＰコマンドに対するＯＫが返る。こうし
て、本システムにおいて、ストリーム配信準備が完了す
る。

【００７２】次いで、端末１０２がサーバ１０１に対
し、ストリーム配信の開始を促すＰＬＡＹコマンドを発
行する。サーバ１０１は、ＰＬＡＹを受信すると、スト
リームデータの配信を開始する。端末１０２は、サーバ
１０１からのストリームデータを受信して蓄積する。そ
して、蓄積開始から前述のプレバッファリング時間（Ｔ
＿ｄｅｌａｙ）が経過したのちに、ストリームデータの
デコード、再生を開始する。このときストリーム配信
は、ＳＥＴＵＰ時に設定された適切なレート制御パラメ
ータに基づいてなされていることはいうまでもない。

【００７３】ストリーム再生の終了時には、端末１０２
よりサーバ１０１に対し、ＴＥＡＲＤＯＷＮコマンドが
発行される。サーバ１０１は、ＴＥＡＲＤＯＷＮを受信
すると、ストリーム配信の終了処理を行い、全手続きを
完了させる。以上が、本システムの具体的な動作例であ
る。

【００７４】以下には、端末１０２の動作について詳細
に説明する。端末１０２は、インターネットに接続可能
な携帯電話であり、電界強度（受信電波強度）を検知す
る機能を持っているとする。図５は、図１の端末１０２
の動作を示すフローチャートである。図５において、最
初、端末１０２は、２つのパラメータＳ＿ｔａｒｇｅｔ
およびＴ＿ｄｅｌａｙの値を決定する（ステップＳ１０
１）。

【００７５】ここで、上記ステップＳ１０１の処理内容
を具体的に説明する。図６は、図３のＲＯＭ５０２の記
憶内容を示す図である。図６に示すように、ＲＯＭ５０
２内には、端末制御プログラムと、電界強度およびＳ＿
ｔａｒｇｅｔが互いに対応付けて記載されたテーブル６
０１と、パラメータＴ＿ｄｅｌａｙの値とが記憶され
る。パラメータＳ＿ｔａｒｇｅｔの値としては、電界強
度「強」と対応するＳ＿ｔａｒｇｅｔ１、「中」と対応
するＳ＿ｔａｒｇｅｔ２、「弱／圏外」と対応するＳ＿
ｔａｒｇｅｔ３の３つの値が記憶されている。一方、パ
ラメータＴ＿ｄｅｌａｙの値は、１つだけが記憶されて
いる。

【００７６】上記３つの値Ｓ＿ｔａｒｇｅｔ１〜３は、
次の関係を満たすように決められる。 Ｓ＿ｔａｒｇｅｔ３＜Ｓ＿ｔａｒｇｅｔ１＜Ｓ＿ｔａｒ
ｇｅｔ２≦Ｓ＿ｍａｘ 一方、値Ｔ＿ｄｅｌａｙは、値Ｓ＿ｍａｘをネットワー
ク１０３の実効的な伝送能力で除して得られる値を超え
ないように決められる。

【００７７】一例として、Ｓ＿ｍａｘが５１２（ＫＢ）
であれば、Ｓ＿ｔａｒｇｅｔ１＝２５６（ＫＢ），Ｓ＿
ｔａｒｇｅｔ２＝３８４（ＫＢ），Ｓ＿ｔａｒｇｅｔ３
＝１２８（ＫＢ）などのように決められる。また、ネッ
トワーク１０３の実効的な伝送能力を３８４（Ｋｂｐ
ｓ）すなわち４８（ＫＢ／ｓｅｃ）とすると、Ｔ＿ｄｅ
ｌａｙは、５１２÷４８≒１０．７（秒）を超えない範
囲で、任意の値（例えば４秒や３秒など）に決定され
る。

【００７８】上記ステップＳ１０１では、ＲＯＭ５０２
から、初期値としてのＳ＿ｔａｒｇｅｔ１と、値Ｔ＿ｄ
ｅｌａｙとが読み出される。

【００７９】なお、ここでは、Ｓ＿ｔａｒｇｅｔ１〜３
と、Ｔ＿ｄｅｌａｙの値とが予め計算されてＲＯＭ５０
２に記憶されており、ＣＰＵ５０３は、必要な値をＲＯ
Ｍ５０２から読み出すようにしているが、代わりに、バ
ッファの総容量と、ネットワーク１０３の実効的な伝送
能力と、Ｓ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値を
計算するためのプログラムとをＲＯＭ５０２に記憶して
おいてもよい。この場合、ＣＰＵ５０３は、必要があれ
ば、その都度、ＲＯＭ５０２から容量、速度およびプロ
グラムを読み出して、Ｓ＿ｔａｒｇｅｔおよびＴ＿ｄｅ
ｌａｙの値を計算する。また、ここでは、Ｔ＿ｄｅｌａ
ｙの値が１つだけであるが、複数の値を準備しておい
て、その中から選択してもよい。以上がステップＳ１０
１の処理内容である。

【００８０】再び図５において、端末１０２は、ステッ
プＳ１０１で決定されたＳ＿ｔａｒｇｅｔおよびＴ＿ｄ
ｅｌａｙをＳＥＴＵＰコマンドに添付して、サーバ１０
１へ向けて送信する（ステップＳ１０２）。応じて、サ
ーバ１０１からストリームが送られてくる。ストリーム
送信の際、サーバ１０１は、端末から通知されたＳ＿ｔ
ａｒｇｅｔおよびＴ＿ｄｅｌａｙに基づく送信速度制御
を実行する（サーバ側の動作ついては後述）。

【００８１】次に、端末１０２は、サーバ１０１から送
られてくるストリームを受信して、バッファに書き込む
動作を開始する（ステップＳ１０３）。具体的には、図
３に示されているように、ネットワーク１０３を通じて
送られてくるストリームは、まずネットワークコントロ
ーラ５０６を経由して受信バッファ５０５に書き込まれ
る。時間が経過して受信バッファ５０５が満杯になる
と、受信バッファ５０５内のストリームが先頭データか
ら順番に読み出されて、デコーダバッファ５０８へと書
き込まれていく。

【００８２】次に、端末１０２は、バッファリング開始
から時間がＴ＿ｄｅｌａｙだけ経過したか否かを判定し
（ステップＳ１０４）、その判定結果が否定であれば、
肯定となるまで待機する。ステップＳ１０４の判定結果
が肯定となると、端末１０２は、バッファからストリー
ムを読み出してデコード・再生する動作を開始する（ス
テップＳ１０５）。具体的には、図３において、ＣＰＵ
５０３がバッファリング開始からの経過時間を計測して
おり、その計測結果がＲＯＭ５０２内のＴ＿ｄｅｌａｙ
と一致した瞬間、再生モジュール５１０に命じて、デコ
ーダバッファ５０８内のストリームを先頭データから順
番に読み出してデコーダ５０９に入力する処理を開始さ
せる。

【００８３】次に、端末１０２は、ネットワーク１０３
の伝送能力が閾値を跨いで変化したか否かを判定する
（ステップＳ１０６）。この判定は、具体的には、次の
ようにして行われる。例えば、ネットワーク１０３を管
理するホストコンピュータ（図示せず）が、ネットワー
ク１０３の伝送能力に関する情報をネットワーク１０３
経由で端末１０２に随時配信するようにし、端末１０２
は、ホストコンピュータからの情報をもとに変化の有無
を判定する。

【００８４】この場合、具体的には、図３に示すよう
に、伝送能力に関する情報が送受信モジュール５０７を
通じてＣＰＵ５０３へと送られる。ＲＯＭ５０２には、
予め閾値が格納されており、ＣＰＵ５０３は、送られて
きた情報と、保持している前回の情報と、ＲＯＭ５０２
内の閾値とを互いに比較することにより、伝送能力が閾
値を跨いで変化したか否かを判定することができる。

【００８５】または、ネットワーク１０３を管理するホ
ストコンピュータがその伝送能力に関する情報を端末１
０２に配信する機能を持たない場合、端末１０２は、例
えば、次のようにして自ら判定を行うことができる。す
なわち、端末１０２が携帯電話の場合、図７（後述）に
示すように、周囲の電界強度を検知して、検知結果を
「強・中・弱・圏外」のように表示する機能を持ってい
る。この電界強度の変化をネットワーク１０３の伝送能
力の変化と見なせば、端末１０２は、検出を簡単に行え
ることになる。

【００８６】ステップＳ１０６の判定結果が肯定の場
合、端末１０２は、新たなＳ＿ｔａｒｇｅｔを決定し
（ステップＳ１０７）、それをサーバ１０１へ向けて送
信する（ステップＳ１０８）。一方、ステップＳ１０６
の判定結果が否定の場合、ステップＳ１０７，Ｓ１０８
をスキップして、ステップＳ１０９（後述）を実行す
る。

【００８７】ここで、上記ステップＳ１０６およびステ
ップＳ１０７の処理内容について、詳しく説明する。以
下では、端末１０２が携帯電話であり、電界強度の変化
に応じてＳ＿ｔａｒｇｅｔを変更する場合を説明する。
図７は、あるエリアにおける電界強度の分布と、端末の
移動に伴う伝送能力の変化とを示す模式図である。図７
（Ａ）には、３つの中継局Ｂ１〜Ｂ３を含むエリアにお
ける電界強度分布が示されている。図７（Ａ）におい
て、各中継局Ｂ１〜Ｂ３を中心とする同心円が、互いに
等しい電界強度の点を繋いでできる等電界曲線である。

【００８８】例えば、中継局に最も近い同心円７０３内
では、電界強度が「強」であり、この同心円７０３から
次の同心円７０４までの間の領域では「中」となる。さ
らに、同心円７０４から同心円７０５までの間では
「弱」、同心円７０５の外側の領域では「圏外」とな
る。ただし、各中継局を中心とする同心円は、一部が互
いに交差しており、電界強度が「圏外」となる領域は、
わずかしかない。

【００８９】いま、端末１０２は、矢印７０２で示され
る経路に沿って、中継局Ｂ１の近傍から中継Ｂ２の近傍
へ移動しようとしている。図７（Ｂ）には、図７（Ａ）
の矢印７０２に沿った電界強度（これをネットワーク１
０３の伝送能力と見なすことができる）が示されてい
る。図７（Ｂ）に示されているように、電界強度は、端
末１０２が中継局の近傍にあるとき「強」であり、中継
局Ｂ１から離れるにつれて「中」、「弱」、「圏外」の
ようにだんだん弱くなっていく。そして、中継局Ｂ１の
「圏外」となった直後、端末１０２は、中継局Ｂ２の
「圏内」に入り、電波強度が「弱」、「中」、「強」の
ようにだんだん強くなっていく。

【００９０】上記のように移動する端末１０２は、電界
強度が「強」から「中」へと変化した瞬間、ネットワー
ク１０３の伝送能力が閾値Ａを跨いで変化したと判定し
て、新たなＳ＿ｔａｒｇｅｔを決定し、「中」から
「弱」へと変化した瞬間、伝送能力が閾値Ｂを跨いで変
化したと判定して、新たなＳ＿ｔａｒｇｅｔを決定す
る。逆に、「弱」から「中」へと変化した瞬間、伝送能
力が閾値Ｂを跨いで変化したと判定して、新たなＳ＿ｔ
ａｒｇｅｔを決定し、「中」から「強」へと変化した瞬
間、伝送能力が閾値Ａを跨いで変化したと判定して、新
たなＳ＿ｔａｒｇｅｔを決定する。

【００９１】なお、一般的には、閾値Ａは、ネットワー
ク１０３において実現可能な最大の伝送能力と、ストリ
ームの転送ロスが発生し始めるような伝送能力との略中
間の値である。閾値Ｂは、ストリームの転送ロスが発生
し始めるような伝送能力と対応する値である。

【００９２】新たなＳ＿ｔａｒｇｅｔは、ＲＯＭ５０２
内のテーブル６０１（図６）を参照することにより、次
のように決定される。図８は、図５のステップＳ１０７
の詳細を示すフローチャートである。図８において、端
末１０２は、最初、変化後の電界強度が「強」か否かを
判定し（ステップＳ２０１）、判定結果が肯定であれ
ば、新たなＳ＿ｔａｒｇｅｔをＳ＿ｔａｒｇｅｔ１に決
定する（ステップＳ２０２）。ステップＳ２０１の判定
結果が否定あれば、ステップＳ２０２をジャンプして、
ステップＳ２０３に進む。

【００９３】次に、端末１０２は、変化後の電界強度が
「中」か否かを判定し（ステップＳ２０３）、判定結果
が肯定であれば、新たなＳ＿ｔａｒｇｅｔをＳ＿ｔａｒ
ｇｅｔ２に決定する（ステップＳ２０４）。ステップＳ
２０３の判定結果が否定であれば、ステップＳ２０４を
ジャンプして、ステップＳ２０５に進む。

【００９４】次に、端末１０２は、変化後の電界強度が
「弱／圏外」か否かを判定し（ステップＳ２０５）、判
定結果が肯定であれば、新たなＳ＿ｔａｒｇｅｔをＳ＿
ｔａｒｇｅｔ３に決定し（ステップＳ２０６）、その
後、図５のフローに戻る。ステップＳ２０５の判定結果
が否定であれば、ステップＳ２０６をジャンプして、図
５のフローに戻る。

【００９５】従って、図７（Ａ）の矢印７０２に沿って
端末１０２が移動して行く場合、電界強度の変化に伴っ
て、端末１０２は、パラメータＳ＿ｔａｒｇｅｔの値
を、Ｓ＿ｔａｒｇｅｔ１→Ｓ＿ｔａｒｇｅｔ２→Ｓ＿ｔ
ａｒｇｅｔ３→Ｓ＿ｔａｒｇｅｔ２→Ｓ＿ｔａｒｇｅｔ
１のように変化させる。具体例を挙げれば、２５６（Ｋ
Ｂ）→３８４（ＫＢ）→１２８（ＫＢ）→３８４（Ｋ
Ｂ）→１２８（ＫＢ）のように変化させる。以上が、ス
テップＳ１０６およびステップＳ１０７の具体的な処理
例である。

【００９６】再び図５において、ステップＳ１０８で端
末１０２が新たなＳ＿ｔａｒｇｅｔをサーバ１０１へ向
けて送信すると、それに応じて、サーバ１０１は、パラ
メータＳ＿ｔａｒｇｅｔの値を、端末１０２から新たに
通知された値に変更して、送信速度制御を続行する。

【００９７】次に、端末１０２は、ストリーミング再生
を終了するか否かを判断し（ステップＳ１０９）、終了
する場合は、サーバ１０１へコマンドＴＥＡＲＤＯＷＮ
を送信すると共に、ストリームの受信およびバッファリ
ングを停止し（ステップＳ１１０）、次いで、再生処理
を停止する（ステップＳ１１１）。一方、ストリーミン
グ再生を継続する場合には、端末１０２は、ステップＳ
１０６に戻って、上記と同様の処理を繰り返す。以上
が、端末１０２の動作である。

【００９８】次に、サーバ１０１の動作について詳細に
説明する。なお、ここでは説明を簡単にするために、サ
ーバ１０１は、ＭＰＥＧ１ビデオ（ＩＳＯ／ＩＥＣ １
１１７２−２）、ＭＰＥＧ２ビデオ（ＩＳＯ／ＩＥＣ
１３８１８−２）、あるいはＭＰＥＧ２−ＡＡＣオーデ
ィオ（ＩＳＯ／ＩＥＣ １３８１８−７）のような、固
定周期Ｔｆｒｍでフレームを発生させる符号化圧縮アル
ゴリズムを用いて符号化を行い、かつ、固定周期Ｔｓで
符号化データのパケット化を行うものとする。このパケ
ット化は、フレーム単位で行われるものとする。

【００９９】最初、サーバ１０１が行うストリーム送信
速度制御の概要について、図９〜図１１を用いて説明す
る。図９〜図１１は、サーバ１０１が行うストリーム送
信速度制御によって、端末１０２のバッファに蓄積され
ているデータ量（バッファ占有量）がどのように遷移す
るかを示す図である。サーバ１０１は、送信先の端末１
０２において、バッファ占有量が図９〜図１１に示され
ているごとく遷移するように、ストリームの送信速度を
制御する。

【０１００】図９には、バッファ占有量がＳ＿ｔａｒｇ
ｅｔに近づいていく様子が示されている。図１０には、
バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で遷移してい
る状態で、Ｓ＿ｔａｒｇｅｔの値がより大きな値（Ｓ＿
ｔａｒｇｅｔ２）に変更された場合に、バッファ占有量
がＳ＿ｔａｒｇｅｔ２に近づいていく様子が示されてい
る。図１１には、バッファ占有量がＳ＿ｔａｒｇｅｔの
近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がよ
り小さな値（Ｓ＿ｔａｒｇｅｔ３）に変更された場合
に、バッファ占有量がＳ＿ｔａｒｇｅｔ３に近づいてい
く様子が示されている。

【０１０１】図９〜図１１に共通して、”Ｓ＿ｍａｘ”
は、端末１０２のバッファの総容量であり、”Ｓｕｍ”
が、バッファ占有量である。”ｄｅｌｔａ（０，１，
２，…）”は、サーバ１０１が単位時間Ｔｓあたりに送
信するデータの量（すなわち、１つのパケットに詰め込
まれているデータの量）を示す。ここで、単位時間Ｔｓ
は、サーバ１０１がパケットを送信する周期であり、固
定値である。”Ｌ（０，１，２，…）”は、１つのフレ
ームあたりのデータ量である。

【０１０２】サーバ１０１は、端末１０２からＴ＿ｄｅ
ｌａｙの値の通知を受けると、その値に基づいてストリ
ームの送信速度を制御する。この速度制御は、１つのパ
ケットに詰め込むデータの量を変化させることにより行
われる。

【０１０３】図９において、サーバ１０１が最初に送信
したパケット（ｉ＝０）には、量ｄｅｌｔａ０のデータ
が詰め込まれており、時刻ｔ＝０では、バッファ占有量
Ｓｕｍは、ｄｅｌｔａ０となる。単位時間Ｔｓが経過す
ると、次のパケット（ｉ＝１）が送られてくるが、そこ
には、量ｄｅｌｔａ１のデータが詰め込まれている。従
って、時刻ｔ＝Ｔｓでは、Ｓｕｍは、｛ｄｅｌｔａ０＋
ｄｅｌｔａ１｝となる。以降、単位時間Ｔｓが経過する
毎に、次々とパケット（ｉ＝２，３，…）が送られてき
て、Ｓｕｍにｄｅｌｔａ２，ｄｅｌｔａ３，…が加算さ
れていく。

【０１０４】一方、３つ目のパケット（ｉ＝２）が送ら
れてくる以前である時刻ｔ＝Ｔ＿ｄｅｌａｙに、バッフ
ァからデータを読み出してデコードする処理が開始され
る。デコードはフレーム単位で行われるので、ｔ＝Ｔ＿
ｄｅｌａｙ以降、固定周期Ｔｆｒｍ毎に、ＳｕｍからＬ
０，Ｌ１，Ｌ２…が減算されていく。

【０１０５】すなわち、バッファ占有量Ｓｕｍは、時刻
ｔ＝０以降、周期Ｔｓ毎に、ｄｅｌｔａ０，ｄｅｌｔａ
１，…が加算されて、だんだん増加していく。その一方
で、時刻ｔ＝Ｔ＿ｄｅｌａｙ以降、周期Ｔｆｒｍ毎にＬ
０，Ｌ１，Ｌ２…が減算されていく。従って、Ｓｕｍが
目標値Ｓ＿ｔａｒｇｅｔに達する直前までの期間は、１
つのパケットに詰め込むデータ量を標準よりも多くして
（より一般的には送信速度を速くして）、バッファへの
書き込み速度がバッファからの読み出し速度を上回るよ
うにし、それ以降は、１つのパケットに詰め込むデータ
量を標準に戻して、書き込み速度と読み出し速度とを均
衡させれば、Ｓｕｍを目標値Ｓ＿ｔａｒｇｅｔの近傍で
遷移させることが可能となる。

【０１０６】このような送信速度制御を行えば、図１
０，図１１のように、目標値Ｓ＿ｔａｒｇｅｔが途中で
新たな目標値（Ｓ＿ｔａｒｇｅｔ２，３）に変更された
場合にも、Ｓｕｍを新たな目標値（Ｓ＿ｔａｒｇｅｔ
２，３）の近傍で遷移させることが可能となる。

【０１０７】すなわち、図１０において、Ｓｕｍが目標
値Ｓ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿
ｔａｒｇｅｔがより大きな値（Ｓ＿ｔａｒｇｅｔ２）に
変更されると、サーバ１０１は、以降のパケット（ｉ＝
３，４）に詰めるデータの量を増やすことによって、バ
ッファへの書き込み速度がバッファからの読み出し速度
を上回るようにする。Ｓｕｍが新たな目標値Ｓ＿ｔａｒ
ｇｅｔ２に達して以降は、１つのパケットに詰め込むデ
ータ量を標準に戻して、書き込み速度と読み出し速度と
を均衡させればよい。

【０１０８】また、図１１において、Ｓｕｍが目標値Ｓ
＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａ
ｒｇｅｔがより小さな値（Ｓ＿ｔａｒｇｅｔ３）に変更
されると、サーバ１０１は、以降のパケット（ｉ＝３，
４）に詰めるデータの量を減らすことによって、バッフ
ァへの書き込み速度がバッファからの読み出し速度を下
回るようにする。Ｓｕｍが新たな目標値Ｓ＿ｔａｒｇｅ
ｔ３に達して以降は、１つのパケットに詰め込むデータ
量を標準に戻して、書き込み速度と読み出し速度とを均
衡させればよい。

【０１０９】次に、上で説明したようなサーバ１０１に
よる送信速度制御について詳細に説明する。図１２は、
サーバ１０１が行う送信速度制御アルゴリズムの一例を
示すフローチャートである。図１２において、最初、端
末１０２が自身のバッファ占有量（Ｓｕｍ）を検出し、
サーバ１０１は、端末１０２からバッファ占有量Ｓｕｍ
の通知を受ける（ステップＳ３０１）。次に、サーバ１
０１は、ステップＳ３０１で通知されたバッファ占有量
Ｓｕｍが、端末１０２から指定された目標値Ｓ＿ｔａｒ
ｇｅｔの近傍で遷移しているか否かを判定する（ステッ
プＳ３０２）。その判定結果が肯定であれば、現在の送
信速度が維持される。

【０１１０】ステップＳ３０２の判定結果が否定の場
合、サーバ１０１は、ステップＳ３０１で通知されたバ
ッファ占有量Ｓｕｍが目標値Ｓ＿ｔａｒｇｅｔよりも大
きいか否かを判定する（ステップＳ３０３）。そして、
判定結果が否定であれば、送信速度を現在よりも速い速
度に変更し（ステップＳ３０４）、その後、ステップＳ
３０６に進む。一方、ステップＳ３０３の判定結果が肯
定であれば、送信速度を現在よりも遅い速度に変更し
（ステップＳ３０５）、その後、ステップＳ３０６に進
む。

【０１１１】ステップＳ３０６では、速度制御動作を継
続するか否かが判断され、判断結果が肯定の場合、ステ
ップＳ３０１に戻って、上記と同様の動作が繰り返され
る。一方、判断結果が否定の場合、動作が終了される。
以上が、サーバ１０１が行う送信速度制御の一例であ
る。

【０１１２】ところで、図１２の例では、端末１０２が
自身のバッファ占有量を検出して、サーバ１０１に通知
している。しかしその場合、端末１０２が検出するの
は、現在時刻におけるバッファ占有量である。その上、
端末１０２からサーバ１０１への情報伝達に時間がかか
るので、サーバ１０１は、伝達遅延時間の分だけ過去の
バッファ占有量に基づいて送信速度制御を行うことにな
り、バッファ占有量をＳ＿ｔａｒｇｅｔの近傍で遷移さ
せるのは、現実には困難である。

【０１１３】これに対して、以下に説明する別の例（図
１３，１４参照）では、未来のある時点でのバッファ占
有量に基づいて送信速度制御を行うことによって、バッ
ファ占有量をＳ＿ｔａｒｇｅｔの近傍で遷移させること
が可能となる。この場合、サーバ１０１は、端末１０２
からＳｕｍの通知を受けるのでなく、未来のある時刻に
おける端末１０２側のバッファ占有量Ｓｕｍを予測算出
する。この予測算出は、次のようにして行われる。

【０１１４】すなわち、図２において、ＲＯＭ４１３に
は、パケット送信周期Ｔｓ（固定値）と、デコード周期
Ｔｆｒｍ（固定値）とが予め記憶されている。ＣＰＵ４
１２は、パケットが生成される際、そのパケットに詰め
込まれたデータの量（ｄｅｌｔａ０，ｄｅｌｔａ１，ｄ
ｅｌｔａ２，…）をＲＡＭ４０４に記憶させておく。さ
らに、ストリームが送信される際、各フレームのデータ
量（Ｌ０，Ｌ１，Ｌ２，…）をＲＡＭ４０４に記憶させ
ておく。

【０１１５】ＲＡＭ４０４にはまた、先に端末１０２か
ら通知されたＴ＿ｄｅｌａｙが記憶されており、ＣＰＵ
４１２は、ＲＯＭ４１３内のＴｓおよびＴｆｒｍと、Ｒ
ＡＭ４０４内のｄｅｌｔａ（０，１，２，…）、Ｌ
（０，１，２，…）およびＴ＿ｄｅｌａｙとを参照して
所定の演算を行うことにより、未来のある時刻における
バッファ占有量Ｓｕｍを算出することができる。このよ
うな算出処理を行うことによって、サーバ１０１は、端
末１０２側においてバッファ占有量Ｓｕｍがどのように
遷移してくか（図９〜図１１参照）を予測することがで
きる。

【０１１６】以下、サーバ１０１が端末１０２のバッフ
ァ占有量Ｓｕｍを予測算出して送信速度制御を行う具体
的な動作例について、図９のバッファ遷移図、図１３お
よび図１４のフローチャート、図１５のパケット構成図
を用いて説明する。

【０１１７】図９において、Ｓ＿ｍａｘは、端末１０２
内バッファの有効蓄積量の最大値（これを簡単に「バッ
ファの総容量」と呼んでいる）であり、Ｓ＿ｔａｒｇｅ
ｔは、今回のストリーミングにおいて端末１０２内バッ
ファに蓄積しようとする目標量であり、Ｔ＿ｄｅｌａｙ
は、頭出し遅延時間の設定値である。これら各パラメー
タの意味については、既に説明したとおりである。以下
では、端末１０２よりＳ＿ｔａｒｇｅｔとＴ＿ｄｅｌａ
ｙが通知されたものとして説明を行う。

【０１１８】本実施の形態では、理解を簡単にするため
に、固定時間周期Ｔｓ毎にパケットの生成・配信を行う
例（ｉ＝ｎに相当する時刻でパケット配信：ｎは整数）
を示している。また、ｉ＝ｎに相当する時刻（ｔ＝ｉ＊
Ｔｓ）でパケットの配信がなされた際に、端末１０２の
受信バッファ５０５およびデコーダバッファ５０８内の
蓄積量Ｓｕｍは、数フレームに相当するデータ量が瞬時
に増加しているが、これは、図１５（Ａ）に示されてい
るように、１パケットに複数フレームを挿入するパター
ンでパケットを生成して端末１０２に配信しているため
である。実際には、パケット配信には転送時間がかか
り、図のように瞬時にバッファ占有量が増加する訳では
ない（傾き＝ｎｅｔｗｏｒｋＲａｔｅの斜線になる）
が、あくまでモデルとして単純化して取り扱うものとす
る。また、時刻ｔ＝Ｔ＿ｄｅｌａｙ以降、階段状にバッ
ファ占有量が減じられていくのは、その時刻に端末１０
２でストリーム再生が始まったことを示している。すな
わち、フレームの再生周期Ｔｆｒｍ毎に、各々のフレー
ム長Ｌ＝Ｌ［ｋ］（ｋは整数）ずつデコーダ５０９でデ
ータが処理される。

【０１１９】図１３および図１４は、図９のバッファ遷
移を実現するためにサーバ１０１によって行われる送信
制御アルゴリズムの別の例を示したフローチャートであ
る。図１３がアルゴリズムの全体像であり、図１４は、
図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの
一例を示すフローチャートである。このようなアルゴリ
ズムを記述したプログラムがＲＯＭ４１３（図２参照）
に格納されており、ＣＰＵ４１２は、このプログラムに
従って各種の演算や制御を行い、その結果、図９のバッ
ファ遷移が実現される。なお、説明を簡単にするため
に、ストリーム途中での配信停止などは、今回考えない
ものとする。以下、各ステップについて順次説明を行
う。

【０１２０】図９において、サーバ１０１は、端末１０
２から送られてきたＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌ
ａｙを受信して記憶する（ステップＳ４０１）。具体的
には、図２において、端末１０２からネットワーク１０
３経由で送られてきたＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅ
ｌａｙの値が、ネットワークコントローラ４１０を通じ
てＲＡＭ４０４に書き込まれる。

【０１２１】なお、ここでは、端末１０２がパラメータ
Ｓ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値を決定し
て、結果をサーバ１０１に通知しているが、代わりに、
サーバ１０１がそれらの値を予め記憶しておいてもよ
く、あるいは、端末１０２の機種情報（バッファの総容
量等）を記憶しておいて、この機種情報をもとにサーバ
１０１がパラメータの値を計算してもよい。

【０１２２】次に、各変数の初期化が行われる（ステッ
プＳ４０２，Ｓ４０３）。各変数の意味は、図１４の説
明にて後述する。初期化が完了すると、ステップＳ４０
４以降の処理、すなわち関数ｍｋＰａｃｋｅｔにてパケ
ットを生成してネットワーク１０３中に送出する処理が
開始される。生成されたパケットは、この例では固定周
期Ｔｓで端末１０２に配信されるので、サーバ１０１
は、ステップＳ４０５にてタイミング調整を行ったの
ち、ステップＳ４０６にて送出を行う。この一連の処理
が完了すると、ＣＰＵ４１２は、関数ｍｋＰａｃｋｅｔ
の実行カウンタｉを更新し、ステップＳ４０４に戻って
ループする。ストリームデータの読み出しおよびパケッ
ト化が全て完了すると、ＣＰＵ４１２は、関数ｍｋＰａ
ｃｋｅｔを抜けて、ステップＳ４０４に判定結果ＦＡＬ
ＳＥでｒｅｔｕｒｎする。ＣＰＵ４１２は、このとき配
信が完了したと見なし、アルゴリズムを完了する。以上
が、本送信制御アルゴリズムの概要である。

【０１２３】次に、ステップＳ４０４に示された関数ｍ
ｋＰａｃｋｅｔの詳細なアルゴリズムであるが、まず各
変数について説明を行う。Ｓｕｍは、端末１０２内の受
信バッファ５０５およびデコーダバッファ５０８に蓄積
されているデータ量の総和であり、Ｌは、フレームのデ
ータ量であり、ｄｅｌｔａは、関数ｍｋＰａｃｋｅｔが
今回呼ばれてからパケット化したデータ量の総和（すな
わち１つのパケットに詰め込んだデータの量）であり、
ｉｎは、蓄積デバイス４１１から読み出したストリーム
ソースのフレーム数を示すカウンタであり、ｏｕｔは、
端末１０２内のデコーダ５０９でデコードされたフレー
ム数を示すカウンタであり、ｄｔｓは、デコーダ５０９
にてフレームがデコードされる時刻であり、ｇｒｉｄ
は、前回の関数ｍｋＰａｃｋｅｔの１ループを処理する
際に進んだｄｔｓの上限値である。

【０１２４】図１４において、関数ｍｋＰａｃｋｅｔ
は、大きくパケット生成アルゴリズムＡ１と、デコード
量算出アルゴリズムＡ２との２つのアルゴリズムに分け
られる。前者において、最初のステップ（Ｓ５０１）で
は、ＣＰＵ４１２は、ｄｅｌｔａをクリアする。続くス
テップＳ５０２では、ＣＰＵ４１２は、Ｌ＝Ｌ［ｉｎ］
のフレーム（既に読み出し済み）を今回のパケット生成
に用いて良いかどうかの判定を行う。判定の基準は、
（ａ）ＳｕｍにＬを加えてもＳ＿ｔａｒｇｅｔを越えな
いこと、および（ｂ）今回の関数呼び出しでパケット化
したデータの量（今回１つのパケットに詰め込んだデー
タの量）ｄｅｌｔａにＬを加えても、１つのパケットに
詰め込み可能なデータ量の上限値ｄｅｌｔａＭａｘを超
えないこと、の２つであるである。

【０１２５】ここでｄｅｌｔａＭａｘは、図１５（Ａ）
に示される不等式 （ｄｅｌｔａＭａｘ＋ｈｄｒ）／Ｔｓ＜Ｎｅｔｗｏｒｋ
Ｒａｔｅ を満たす値であって、周期Ｔｓ以内に端末に配信可能な
データ量の最大値であり、ネットワーク１０３の実効転
送レート（伝送能力）から算出が可能である。ステップ
Ｓ５０２にて真と判定されると、ＣＰＵ４１２は、ステ
ップＳ５０３に進み、Ｌ＝Ｌ［ｉｎ］のフレームをパケ
ット化する。続くステップＳ５０４では、ＣＰＵ４１２
は、パケット化の実行に伴い、Ｓｕｍおよびｄｅｌｔａ
を更新する。続くステップＳ５０５では、ＣＰＵ４１２
は、次のフレームのデータを読み出しバッファ４０７か
ら、フレーム長ＬをＲＡＭ４０４から、それぞれ読み出
す。そして、Ｌが０よりも大きいか否かを判定する。

【０１２６】ステップＳ５０５の判定結果が否定、すな
わちＬ＝０であれば、ＣＰＵ４１２は、全データの読み
出しが完了した（Ｅｎｄ ｏｆ Ｆｉｌｅ検出）とみな
し、関数を抜ける。そして、メインフロー（図１３）の
ステップＳ４０４に判定結果ＦＡＬＳＥでＲＥＴＵＲＮ
する。一方、判定結果が肯定、すなわちＬ＞０であれ
ば、ＣＰＵ４１２は、次のステップ（Ｓ５０６）に進
み、Ｌ［ｉｎ］を配列ｌｅｎｇ内に加える（ＲＡＭ４０
４に記憶させる）。これは後ほど説明するが、デコード
量算出アルゴリズムＡ２で用いるためである。次に、Ｃ
ＰＵ４１２は、ステップＳ５０７に進み、読み出したフ
レーム数カウンタｉｎを更新して、ステップＳ５０２に
ループする。

【０１２７】上記のループによるパケット生成を繰り返
すうち、Ｓｕｍおよびｄｅｌｔａの値がだんだん大きく
なっていく。そして、ステップＳ５０２にてＳｕｍまた
はｄｅｌｔａが十分大きくなったと判定されると、ＣＰ
Ｕ４１２は、このループを抜けて、デコード量算出アル
ゴリズムＡ２に入る。

【０１２８】デコード量算出アルゴリズムＡ２におい
て、最初のステップ（Ｓ５０８）では、ｉ＊Ｔｓがｇｒ
ｉｄ以上であるか否かが判定される。このステップＳ５
０８は、端末１０２においてデコードが開始される時刻
になったかどうかを判定することが目的である。具体的
には、ｇｒｉｄが最初Ｔ＿ｄｅｌａｙに設定されている
ため、関数呼び出しカウンタ数ｉが小さくてｔ＝ｉ＊Ｔ
ｓがｇｒｉｄ未満の間は、端末１０２でのデコードがま
だ始まっていないものと判定される。図９では、ｉ＝０
およびｉ＝１と対応する時刻がこれに相当する。

【０１２９】ステップＳ５０８の判定結果が否定の場
合、ＣＰＵ４１２は、デコードによるフレームデータの
減算を行わずに関数を抜ける。一方、ｉが十分大きくな
ってパケット生成時刻ｔ＝ｉ＊Ｔｓがｇｒｉｄ以上にな
ると、ＣＰＵ４１２は、端末１０２でのデコードが既に
始まっているとみなし、フレームデータの減算処理を行
う。図９では、ｉが２以上の時刻がこれに相当する。続
くステップＳ５０９からステップＳ５１２までのループ
において、現在のｇｒｉｄ時刻から次のｇｒｉｄ時刻
（＝ｇｒｉｄ＋Ｔｓ）に挟まれた時間内にデコード処理
されるフレームデータの量ｌｅｎｇ［ｏｕｔ］をＳｕｍ
から減算し、かつデコードしたフレーム数ｏｕｔをカウ
ントアップする。

【０１３０】上記ループ内のステップＳ５１１におい
て、ｄｔｓには、フレームを１つデコードするたびにＴ
ｆｒｍずつ加算されるが、これは、本実施形態が固定時
間間隔Ｔｆｒｍのフレーム発生を行う符号化方式を用い
ていることに由来する。ステップＳ５１２では、ＣＰＵ
４１２は、今回の時間間隔Ｔｓでデコードされるべきフ
レームの有無を判定している。ステップＳ５１２の判定
結果が否定、すなわち、もはや今回の時間間隔Ｔｓでデ
コードされるフレームは無いと判定されると、ＣＰＵ４
１２は、上記のループ（ステップＳ５０９〜Ｓ５１２）
から抜け、ステップＳ５１３に進む。ステップＳ５１３
では、ＣＰＵ４１２は、変数ｇｒｉｄを次のｇｒｉｄ時
刻に更新する。そして、関数を抜け、メインフロー（図
１３）のステップＳ４０４に判定結果ＴＲＵＥでＲＥＴ
ＵＲＮする。

【０１３１】以上のアルゴリズムにより、図９で示した
ように、端末１０２内において、バッファ占有量Ｓｕｍ
を常にＳ＿ｔａｒｇｅｔの近傍でかつＳ＿ｔａｒｇｅｔ
を超えないように遷移させることが可能となる。従っ
て、複数機種の端末１０２があって、バッファの総容量
Ｓｍａｘが機種によって異なっていても、それぞれの端
末１０２のＳｍａｘに応じてＳ＿ｔａｒｇｅｔを適切な
値に設定すれば、バッファのオーバーフローもアンダー
フローも生じないようにすることができる。

【０１３２】なお、今回の例では、図１５（Ａ）のよう
に１パケットに複数フレームを挿入するパターンでパケ
ットを生成したが、代わりに、図１５（Ｂ）のように、
１パケットに１フレームのフレームを挿入するパターン
でパケットを生成することも可能である。この場合は、
図１４のステップＳ５０２において、後半の不等式を ｄｅｌｔａ＋（Ｌ＋ｈｄｒ） ＜＝ ｄｅｌｔａＭａｘ とし、ステップＳ５０４の後半の等式を ｄｅｌｔａ ＋＝ （Ｌ＋ｈｄｒ） とするだけでよい。

【０１３３】また、本実施形態では、説明を簡単にする
ために、固定時間間隔Ｔｆｒｍでフレーム発生を行う符
号化方式を用いたが、使用する符号化方式―たとえばＭ
ＰＥＧ４ビデオ（ＩＳＯ／ＩＥＣ １４４９６−２）―
に合わせてデコード量算出アルゴリズムＡ２を設計すれ
ば、必ずしも固定時間間隔のフレーム発生を行わなくて
も構わないことはいうまでもない。また、必ずしもフレ
ーム単位でデータを扱うアルゴリズムでなくてもよく、
例えばスライス単位、あるいはＭＰＥＧ１やＭＰＥＧ２
システムストリームのパック単位でデータを扱うアルゴ
リズムであってもよい。

【０１３４】一方、図１４のステップＳ５０２におい
て、Ｓ＿ｔａｒｇｅｔの値が途中で変更されると、本ア
ルゴリズムは瞬時に、変更された新しいＳ＿ｔａｒｇｅ
ｔをターゲットとしてパケットの生成を行うようにな
る。Ｓ＿ｔａｒｇｅｔの値が途中で変更された場合のバ
ッファ遷移の様子が、図１０および図１１に示されてい
る。図１０において、ｉ＝３の時刻にＳ＿ｔａｒｇｅｔ
がＳ＿ｔａｒｇｅｔ２に変更（Ｓ＿ｔａｒｇｅｔ＜Ｓ＿
ｔａｒｇｅｔ２≦Ｓ＿ｍａｘ）されると、変更後しばら
くは多量のフレームデータがパケット化され（図中、ｄ
ｅｌｔａ３やｄｅｌｔａ４）、その結果、Ｓｕｍが新し
い目標値Ｓ＿ｔａｒｇｅｔ２の近傍に到達するようにな
る。

【０１３５】また、図１１のように、ｉ＝２の時刻にＳ
＿ｔａｒｇｅｔがＳ＿ｔａｒｇｅｔ３に変更（Ｓ＿ｔａ
ｒｇｅｔ３＜Ｓ＿ｔａｒｇｅｔ）されると、少量（ｄｅ
ｌｔａ４）または０（ｄｅｌｔａ３）のフレームデータ
がパケット化される。その一方、デコードによりＳｕｍ
が消費されるので、やはりＳｕｍが新しい目標値Ｓ＿ｔ
ａｒｇｅｔ３の近傍に到達するようになる。このような
仕組みを利用すると、ネットワーク１０３の伝送能力
（あるいは端末１０２の電波受信状態）に応じて、動的
に端末１０２内のバッファ占有量Ｓｕｍを増減させるこ
とが可能となり、以下に説明するような応用が可能とな
る。

【０１３６】図７（Ａ）において、携帯電話７０１（図
１の端末１０２と対応）を持ったユーザが、図中の矢印
７０２ように、中継局Ｂ１の圏内から中継局Ｂ２の圏内
へと移動する場合を考える。移動に伴い、携帯電話７０
１からの呼を受け付ける業務が、中継局Ｂ１から中継局
Ｂ２へと引き渡される。このとき、携帯電話７０１の受
信電波強度は、おおむね図７（Ｂ）に示したグラフのよ
うに変化する。本モデルでは、説明を簡単にするため
に、電波強度が強から中（または中から強）に変わると
ころをネットワーク１０３の伝送能力に関する閾値Ａ、
中から弱（または弱から中）に変わるところを閾値Ｂ、
弱から圏外（または圏外から弱）に変わるところを閾値
Ｃとした。

【０１３７】図７（Ｂ）において、今、携帯電話７０１
を持ったユーザが距離ｄ１だけ移動し、伝送能力が閾値
Ａを下回ったとする。このとき携帯電話７０１は、図１
１に示されるように、Ｓ＿ｄｅｌａｙをより大きい値
（Ｓ＿ｔａｒｇｅｔ２）に変更して、その値をサーバ１
０１に通知する。これは、その後も進むと予想される伝
送能力低下に備えて、サーバ１０１による新たなパケッ
ト生成および送出を促進させ、それにより、できるだけ
長時間（これをΔｔとする）ぶんのデータを携帯電話７
０１内のバッファに蓄積しておくためである。伝送能力
が閾値Ａを下回っても、閾値Ｂ以上である間は、まだパ
ケットの転送ロスが発生することがないので、このよう
な伝送速度の高速化が可能である。

【０１３８】ユーザが移動して距離ｄ２に達すると、伝
送能力が閾値Ｂを下回って、パケットの転送ロスが発生
し始める。このとき、携帯電話７０１は、図１１に示さ
れるように、Ｓ＿ｔａｒｇｅｔを小さい値（Ｓ＿ｔａｒ
ｇｅｔ３）に変更して、その値をサーバ１０１に通知す
る。これは、その後もさらに進むと予想される伝送能力
低下に備えて、できるだけサーバ１０１による新たなパ
ケット生成および送出を抑制させるためである。パケッ
ト生成および送出を抑制するのは、次の理由による。

【０１３９】たとえば、携帯電話７０１が通信方式とし
てＰＨＳのＰＩＡＦＳ方式を採用している場合、パケッ
トの伝送ロスが発生すると、リンクレイヤであるＰＩＡ
ＦＳ層のプロトコルに基づくデータ再送処理が行われ
る。再送処理中に、新たなパケット生成および送出が行
われると、それが再送処理の邪魔をする結果となり、か
えって好ましくないからである。

【０１４０】ユーザが移動して距離ｄ３に達すると、伝
送能力が閾値Ｃを下回って、一瞬、パケット転送が困難
となる。しかし、ユーザがさらに移動して距離ｄ４に達
すると、伝送能力が閾値Ｂを上回り、かつ呼を受け付け
る業務の引き渡し（ハンドオーバー）も完了しているの
で、携帯電話７０１は、今度はＳ＿ｔａｒｇｅｔ３を元
の値Ｓ＿ｔａｒｇｅｔに戻して、その値をサーバ１０１
に通知し、それによって、データの蓄積量（すなわちバ
ッファ占有量Ｓｕｍ）を増加させる。なお、ＰＨＳ等の
ハンドオーバー時間は、普通に人が歩く速さでもおおよ
そ２〜３秒程度で完了するため、上記のΔｔをおおよそ
３〜４秒程度確保しておけば、ハンドオーバーが起こっ
ても携帯電話７０１でのストリーミング再生を滞りなく
継続することができる。

【０１４１】ところで、図１１のように、ストリーム配
信の途中でＳ＿ｔａｒｇｅｔの設定値がより小さな値に
変更されると、図１４のアルゴリズムにおいてステップ
Ｓ５０２の判定文がなかなか真にならず、次のフレーム
のデータを送出できないケースが起こりうる。このよう
なケースがたびたび発生すると、折角パケットを端末１
０２に届けても、もはやそのパケット内のフレームデー
タを再生するべき時刻（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔ
ｉｍｅ）を経過してしまっており、データが無駄になっ
てしまうことがある。このような場合は、再生時刻が経
過してしまったフレームデータをスキップした方が、無
駄なデータをネットワーク１０３に流さないで済む分だ
け効率的である。

【０１４２】図１６は、図１３のステップＳ４０４中の
関数ｍｋＰａｃｋｅｔの別の例を示すフローチャートで
ある。図１６の関数ｍｋＰａｃｋｅｔには、サーバ１０
１が送信速度を遅くする際に、再生時刻を過ぎたデータ
の送出をスキップするためのステップ（Ｓ６０１および
Ｓ６０２）が含まれている。すなわち、図１６のアルゴ
リズムは、図１４と比較して、ステップＳ６０１および
ステップＳ６０２が追加されただけである。他のステッ
プは、図１４と全く同じであり、同一の参照番号が付さ
れている。ステップＳ６０１では、ＣＰＵ４１２は、今
から送出しようとしているｉｎ番目のフレームデータ
が、０番目のフレームのデータでなく、かつ、端末１０
２にて既にデコードされたとみなされるｏｕｔ番目のフ
レームデータより再生時刻が後かどうかを判定してい
る。

【０１４３】この判定結果が真ならば、ＣＰＵ４１２
は、ｉｎ番目のフレームのデータが端末での再生時刻に
間に合うと見なして、ステップＳ５０３にてそのデータ
をパケット化し、端末１０２に送出する。偽の場合は、
ｉｎ番目のフレームデータを無かったものとみなし、ス
テップＳ６０２にてＬ＝０とする。これにより、ステッ
プＳ５０２では必ず真と判定され、かつステップＳ５０
３のパケット化において、不要なフレームデータのコピ
ーを行わずに、送出フレームを次に進めることができ
る。なお、このようなフレームスキップがあった場合
は、デコーダ５０９での再生が時間Ｔｆｒｍだけ飛ぶの
で、その旨を端末１０２に通知する情報が、図１５
（Ａ），（Ｂ）のパケット中に記述されるものとする。
例えば、ヘッダ内にそのような再生時刻情報を記述する
領域を設ければよい。

【０１４４】図１６に示したアルゴリズムは、ＭＰＥＧ
オーディオのように各フレームどうしの優先順位（重要
度）に差が無い場合には、十分有効な手法である。しか
し、ＭＰＥＧビデオにおいては、従来例の紹介において
既に説明したように、Ｉフレームであればそれ単独で意
味のある画像を再構成することができるが、ＰやＢのフ
レームでは、時間的に前後の参照フレームがなければ、
意味のある画像を再構成することができない。この場合
には、図１６のアルゴリズムにおいてフレームの間引き
を行う際に、再生時刻に間に合うＩフレームを優先的に
送出する一方、ＰやＢのフレームを全てスキップするこ
とで、ネットワーク１０３の転送速度が遅い状況におい
ても、端末１０２に対してより高品位の映像を提供する
ことが可能となる。

【０１４５】図１７は、図１３のステップＳ４０４中の
関数ｍｋＰａｃｋｅｔの、さらに別の例を示すフローチ
ャートである。図１７の関数ｍｋＰａｃｋｅｔには、サ
ーバ１０１が送信速度を遅くする際に、優先度の低いデ
ータと、優先度は高いが再生時刻を過ぎたデータとの送
出をスキップするためのステップ（Ｓ５０５’，Ｓ６０
１，Ｓ６０２，Ｓ７０１およびＳ７０２）が含まれてい
る。すなわち、図１７のアルゴリズムは、図１４と比較
して、ステップＳ６０１，Ｓ６０２，Ｓ７０１およびＳ
７０２が追加され、かつステップＳ５０５がステップＳ
５０５’に置き換えられている。ステップＳ５０５’
は、ステップＳ５０５に対し、関数ＮｅｘＴｆｒｍに優
先順位ｐｒｉの検出機能が加えられたものである。他の
ステップは、図１４，図１６と全く同じであり、同一の
参照番号が付されている。

【０１４６】従って、図１７のアルゴリズムは、図１６
と比較すると、ステップＳ７０１，Ｓ７０２が追加さ
れ、かつステップＳ５０５がＳ５０５’に置き換わって
いる。

【０１４７】図１７のアルゴリズムを実行するには、端
末１０２が検出した受信状態を示す情報（受信状態情
報）を、端末１０２からサーバ１０１に通知する機能が
必要となる。このような機能を持ったサーバ・クライア
ント・システムの構成例を、図１８に示す。図１８にお
いて、端末１０２は、受信状態を検出する検出部８０１
を備えている。端末１０２とサーバ１０１との間には、
検出された受信状態情報を端末１０２からサーバ１０１
に通知する通知部８０２が設けられる。サーバ１０１
は、保持部８０３を備えており、通知された受信状態情
報を保持する。

【０１４８】再び図１７において、ｍｋＰａｃｋｅｔ関
数が呼び出されると、ステップＳ５０１に先立って、ス
テップＳ７０１が実行される。ステップＳ７０１におい
て、サーバ１０１（のＣＰＵ４１２）は、保持部８０３
内の情報（端末１０２側の受信状態）を参照して、ネッ
トワーク１０３の伝送能力が閾値Ｂを下回るか否かを判
定する。この判定の結果、閾値Ｂを下回っていればｓｌ
ｏｗｆｌａｇを真とし、そうでなければ偽とする。

【０１４９】ステップＳ５０５’では、次のフレームの
優先度が検出され、続くステップＳ７０２では、そのフ
レームのデータの優先度が高く、かつｓｌｏｗｆｌａｇ
が真であるか否かが判定される。この判定結果が肯定、
すなわちネットワーク１０３の転送速度が遅いことを示
すｓｌｏｗｆｌａｇが真であり、かつ優先度の高いフレ
ームである場合、ステップＳ６０１に進んで、再生時刻
が経過してしまったフレームか否かが判定される。一
方、判定結果が否定である場合、ステップＳ６０２に進
んで、Ｌ＝０とされる（つまり、たとえ再生時刻に間に
合うようであっても、そのフレームはスキップされ
る）。後の処理は、図１４や図１６の処理と全く同様で
ある。

【０１５０】以上のように、本実施形態によれば、端末
１０２が、自身のバッファ容量とネットワーク１０３の
伝送能力とに応じた目標量を決定し、さらに、目標量を
伝送能力で除して得られる値を超えない範囲内で、遅延
時間を決定する。サーバ１０１は、こうして端末１０２
が決定した目標量および遅延時間に基づいて送信速度を
制御するので、端末１０２のバッファ容量が機種によっ
て異なっていても、ネットワーク１０３の伝送能力が変
動しても、バッファ量および伝送能力に応じた送信速度
制御が行え、その結果、バッファのアンダーフローやオ
ーバーフローによるストリーミング再生の破綻を回避す
ることが可能となる。しかも、目標量とは独立に遅延時
間が決定されるので、ストリーミング再生の破綻回避
と、頭出し時の待ち時間短縮とを互いに両立させること
ができる。

【図面の簡単な説明】

【図１】本発明の一実施形態に係るストリーミング方法
を実行するサーバ・クライアント・システムの構成例を
示すブロック図である。

【図２】図１のサーバ１０１の構成を示すブロック図で
ある。

【図３】図１の端末１０２の構成を示すブロック図であ
る。

【図４】図１のシステムの全体動作を説明するためのシ
ーケンス図である。

【図５】図１の端末１０２の動作を示すフローチャート
である。

【図６】図３のＲＯＭ５０２の記憶内容を示す図であ
る。

【図７】あるエリアにおける電界強度の分布（Ａ）と、
端末の移動に伴う伝送能力の変化（Ｂ）とを示す模式図
である。

【図８】図５のステップＳ１０７の詳細を示すフローチ
ャートである。

【図９】図１のサーバ１０１が行う送信速度制御によっ
て、端末１０２のバッファ占有量がどのように遷移する
か（Ｓ＿ｔａｒｇｅｔに近づいていく様子）を示す図で
ある。

【図１０】バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で
遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がより大き
な値（Ｓ＿ｔａｒｇｅｔ２）に変更された場合に、図１
のサーバ１０１が行う送信速度制御によって、端末１０
２のバッファ占有量がどのように遷移するかを示す図で
ある。

【図１１】バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で
遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がより小さ
な値（Ｓ＿ｔａｒｇｅｔ３）に変更された場合に、図１
のサーバ１０１が行う送信速度制御によって、端末１０
２のバッファ占有量がどのように遷移するかを示す図で
ある。

【図１２】図１のサーバ１０１が行う送信速度制御アル
ゴリズムの一例を示すフローチャートである。

【図１３】図９〜図１１のバッファ遷移を実現するため
にサーバ１０１によって行われる送信速度制御アルゴリ
ズムの別の例を示したフローチャートである。

【図１４】図１３のステップＳ４０４中の関数ｍｋＰａ
ｃｋｅｔの一例を示すフローチャートである。

【図１５】図１のサーバ１０１が生成するパケットの構
成例（Ａは１パケットに複数フレームを挿入する場合、
Ｂは１パケットに１フレームを挿入する場合）を示す図
である。

【図１６】図１３のステップＳ４０４中の関数ｍｋＰａ
ｃｋｅｔの別の例を示すフローチャートである。

【図１７】図１３のステップＳ４０４中の関数ｍｋＰａ
ｃｋｅｔの、さらに別の例を示すフローチャートであ
る。

【図１８】本発明の一実施形態に係るストリーミング方
法を実行するサーバ・クライアント・システムの別の構
成例を示すブロック図である。

【図１９】従来のストリーミング方法を説明するための
図である（Ａはビデオフレーム、Ｂはバッファ占有量の
遷移、Ｃは従来端末の構成例）。

【図２０】従来のストリーミング方法を実行するサーバ
・クライアント・システムの構成例を示すブロック図で
ある。

【図２１】受信バッファを追加することによってバッフ
ァ占有量の遷移がどのように変化するかを説明するため
の図である（Ａが追加前、Ｂが追加後）。

【符号の説明】

１０１ サーバ １０２ 端末 １０３ ネットワーク ４０２，５０７ 送受信モジュール ４０４ ＲＡＭ ４０５ 生成モジュール ４０６ パケット生成回路 ４０７ 読み出しバッファ ４０８ パケット生成バッファ ４０９ 送信バッファ ４１０，５０６ ネットワークコントローラ ４１１ 蓄積デバイス ４１２，５０３ ＣＰＵ ４１３，５０２ ＲＯＭ ５０５ 受信バッファ ５０８ デコーダバッファ ５０９ デコーダ ５１０ 再生モジュール ５１１ 表示デバイス

フロントページの続き (72)発明者 藤田 隆久 大阪府門真市大字門真1006番地 松下電器 産業株式会社内 Ｆターム(参考） 5C059 KK35 RB02 RB04 RE16 RE20 SS08 SS10 SS20 TA71 TC16 TC38 TD14 UA32 UA39 5K030 HA08 HB02 HB21 JT10 KA01 KA03 KA07 LC01 LE16 LE17 MB15 5K034 AA05 CC02 CC05 DD02 EE10 HH42 MM08

Claims (15)

【特許請求の範囲】
1. 【請求項１】 サーバが端末へネットワークを通じてス
   トリームデータを送信し、かつ端末が当該ストリームデ
   ータを受信しつつ再生するストリーミング方法であっ
   て、 端末が、自身のバッファ容量とネットワークの伝送能力
   とに関連して、自身のバッファに蓄積すべきストリーム
   データの目標量を決定する目標量決定ステップ、 当該バッファ容量を当該伝送能力で除して得られる値を
   超えない範囲内で任意に、端末が、自身のバッファにス
   トリームの先頭データを書き込んでから当該データを読
   み出して再生開始するまでの遅延時間を決定する遅延時
   間決定ステップ、 決定した目標時間および遅延時間を、端末がサーバに通
   知するステップ、 サーバが端末へネットワークを通じてストリームデータ
   を送信する際に、通知された目標量および遅延時間に基
   づいて送信速度を制御する制御ステップを備える、スト
   リーミング方法。
2. 【請求項２】 前記制御ステップにおいて、サーバは、 端末のバッファに蓄積されているストリームデータの量
   が、当該目標量の近傍において当該目標量を超えること
   なく遷移するように、当該送信速度を制御することを特
   徴とする、請求項１に記載のストリーミング方法。
3. 【請求項３】 前記制御ステップにおいて、サーバは、
   当該送信速度と、当該遅延時間と、端末がストリームデ
   ータをデコードする速度とに基づいて、端末のバッファ
   に蓄積されるストリームデータの量を予測算出すること
   を特徴とする、請求項２に記載のストリーミング方法。
4. 【請求項４】 端末が、ネットワークの伝送能力が所定
   の閾値を跨いで変化したことを検出する検出ステップ、 前記検出ステップでの検出結果に応じて、端末が当該目
   標量を変更する目標量変更ステップ、および変更後の目
   標量を、端末がサーバに通知するステップをさらに備
   え、 前記制御ステップにおいて、サーバは、変更後の目標量
   の通知を受けると、端末のバッファに蓄積されるストリ
   ームデータの量が、当該変更後の目標量の近傍において
   当該変更後の目標量を超えることなく遷移するように、
   当該送信速度を制御することを特徴とする、請求項１に
   記載のストリーミング方法。
5. 【請求項５】 前記検出ステップでネットワークの伝送
   能力が第１の閾値を跨いで低下したことを検出すると、
   端末は、前記目標量変更ステップにおいて、当該目標量
   を増加させる向きに変更し、 前記制御ステップにおいて、サーバは、当該目標量が増
   加されたのに応じて、当該送信速度を上昇させる向きに
   制御することを特徴とする、請求項４に記載のストリー
   ミング方法。
6. 【請求項６】 当該第１の閾値は、実現可能な最大の伝
   送能力と、ストリームデータの転送ロスが発生し始める
   ような伝送能力との略中間の値であることを特徴とす
   る、請求項５に記載のストリーミング方法。
7. 【請求項７】 前記検出ステップでネットワークの伝送
   能力が当該第１の閾値より小さい第２の閾値を跨いで低
   下したことを検出すると、端末は、前記目標量変更ステ
   ップにおいて、当該目標量を減少させる向きに変更し、 前記制御ステップにおいて、サーバは、当該目標量が減
   少方向に変更されたのに応じて、当該送信速度を低下さ
   せる向きに制御することを特徴とする、請求項４に記載
   のストリーミング方法。
8. 【請求項８】 当該第２の閾値は、ストリームデータの
   転送ロスが発生し始めるような伝送能力と対応する値で
   あることを特徴とする、請求項７に記載のストリーミン
   グ方法。
9. 【請求項９】 前記目標量変更ステップにおいて、端末
   が当該目標量を減少させる向きに変更すると、前記制御
   ステップにおいて、サーバは、送信しようとするストリ
   ームを構成する各フレームの再生時刻を現在時刻と逐次
   比較して、再生時刻が現在時刻よりも古いフレームの送
   信をスキップし、それよって当該送信速度を低下方向に
   制御することを特徴とする、請求項８に記載のストリー
   ミング方法。
10. 【請求項１０】 前記目標量変更ステップにおいて、端
    末が当該目標量を減少させる向きに変更すると、前記制
    御ステップにおいて、サーバは、送信しようとするスト
    リームを構成する各フレームの重要度を基準値と逐次比
    較して、 重要度が基準値未満であるフレームについては、全て送
    信をスキップし、 重要度が基準値以上であるフレームについては、それぞ
    れの再生時刻を現在時刻と逐次比較して、再生時刻が現
    在時刻よりも古いものだけ送信をスキップし、それによ
    って当該送信速度を低下方向に制御することを特徴とす
    る、請求項８に記載のストリーミング方法。
11. 【請求項１１】 ネットワークを通じてストリームデー
    タを送信するサーバと、当該ストリームデータを受信し
    つつ再生する端末とからなるシステムであって、 端末は、 自身のバッファ容量とネットワークの伝送能力とに関連
    して、自身のバッファに蓄積すべきストリームデータの
    目標量を決定する目標量決定手段、 当該バッファ容量を当該伝送能力で除して得られる値を
    超えない範囲内で任意に、自身のバッファにストリーム
    の先頭データを書き込んでから当該データを読み出して
    再生開始するまでの遅延時間を決定する遅延時間決定手
    段、および決定した目標時間および遅延時間をサーバに
    通知する手段を備え、 サーバは、端末へネットワークを通じてストリームデー
    タを送信する際に、通知された目標量および遅延時間に
    基づいて送信速度を制御する制御手段を備える、システ
    ム。
12. 【請求項１２】 ネットワークを通じてストリームデー
    タを送信するサーバと共に用いられ、当該ストリームデ
    ータを受信しつつ再生する端末であって、 サーバには、端末へネットワークを通じてストリームデ
    ータを送信する際に、通知された目標量および遅延時間
    に基づいて送信速度を制御する制御手段が備わり、 自身のバッファ容量とネットワークの伝送能力とに関連
    して、自身のバッファに蓄積すべきストリームデータの
    目標量を決定する目標量決定手段、 当該バッファ容量を当該伝送能力で除して得られる値を
    超えない範囲内で任意に、自身のバッファにストリーム
    の先頭データを書き込んでから当該データを読み出して
    再生開始するまでの遅延時間を決定する遅延時間決定手
    段、および決定した目標時間および遅延時間をサーバに
    通知する手段を備える、端末。
13. 【請求項１３】 ストリームデータを受信しつつ再生す
    る端末と共に用いられ、ネットワークを通じて当該スト
    リームデータを送信するサーバであって、 端末には、 自身のバッファ容量とネットワークの伝送能力とに関連
    して、自身のバッファに蓄積すべきストリームデータの
    目標量を決定する目標量決定手段、 当該バッファ容量を当該伝送能力で除して得られる値を
    超えない範囲内で任意に、自身のバッファにストリーム
    の先頭データを書き込んでから当該データを読み出して
    再生開始するまでの遅延時間を決定する遅延時間決定手
    段、および決定した目標時間および遅延時間をサーバに
    通知する手段が備わり、 端末へネットワークを通じてストリームデータを送信す
    る際に、通知された目標量および遅延時間に基づいて送
    信速度を制御する制御手段を備え、 前記制御手段は、端末のバッファに蓄積されているスト
    リームデータの量が、当該目標量の近傍において当該目
    標量を超えることなく遷移するように、当該送信速度を
    制御することを特徴とする、サーバ。
14. 【請求項１４】 サーバが端末へネットワークを通じて
    ストリームデータを送信し、かつ端末が当該ストリーム
    データを受信しつつ再生するストリーミング方法を記述
    したプログラムであって、 端末が、自身のバッファ容量とネットワークの伝送能力
    とに関連して、自身のバッファに蓄積すべきストリーム
    データの目標量を決定する目標量決定ステップ、 当該バッファ容量を当該伝送能力で除して得られる値を
    超えない範囲内で任意に、端末が、自身のバッファにス
    トリームの先頭データを書き込んでから当該データを読
    み出して再生開始するまでの遅延時間を決定する遅延時
    間決定ステップ、 決定した目標時間および遅延時間を、端末がサーバに通
    知するステップ、 サーバが端末へネットワークを通じてストリームデータ
    を送信する際に、通知された目標量および遅延時間に基
    づいて送信速度を制御する制御ステップを備えるストリ
    ーミング方法を記述した、プログラム。
15. 【請求項１５】 サーバが端末へネットワークを通じて
    ストリームデータを送信し、かつ端末が当該ストリーム
    データを受信しつつ再生するストリーミング方法が記述
    されたプログラムを記録した記録媒体であって、 端末が、自身のバッファ容量とネットワークの伝送能力
    とに関連して、自身のバッファに蓄積すべきストリーム
    データの目標量を決定する目標量決定ステップ、 当該バッファ容量を当該伝送能力で除して得られる値を
    超えない範囲内で任意に、端末が、自身のバッファにス
    トリームの先頭データを書き込んでから当該データを読
    み出して再生開始するまでの遅延時間を決定する遅延時
    間決定ステップ、 決定した目標時間および遅延時間を、端末がサーバに通
    知するステップ、 サーバが端末へネットワークを通じてストリームデータ
    を送信する際に、通知された目標量および遅延時間に基
    づいて送信速度を制御する制御ステップを備えるストリ
    ーミング方法が記述されたプログラムを記録した、記録
    媒体。