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

Description

【０００１】
【発明の属する技術分野】
本発明は、ストリーミング方法に関し、より特定的には、サーバが端末へインターネットを通じてマルチメディアデータを送信し、かつ端末がそのデータを受信しつつ再生するためのストリーミング方法に関する。
【０００２】
【従来の技術】
（マルチメディアデータの符号化圧縮方式およびバッファモデルの説明）
インターネットでの伝送に使用されるマルチメディアデータには、動画、静止画、音声、テキスト、およびそれらが多重化されたデータ等、さまざまな種類がある。動画では、Ｈ．２６３やＭＰＥＧ１、２、４といった符号化圧縮方式が著名であるし、静止画としてはＪＰＥＧ、音声では、ＭＰＥＧオーディオ、Ｇ．７２９など枚挙にいとまがない。
【０００３】
本発明では、ストリーミング再生に的を絞っているので、動画および音声が伝伝送の対象となる。ここでは、動画圧縮方式の代表であるＭＰＥＧビデオ、中でも比較的仕組みが単純なＭＰＥＧ１（ＩＳＯ／ＩＥＣ １１１７２）ビデオや、ＭＰＥＧ２（ＩＳＯ／ＩＥＣ １３８１８）ビデオについて説明する。
【０００４】
ＭＰＥＧビデオは、高効率なデータ圧縮を実現するために、主に次の２つの特徴を有している。一つ目は、動画像データの圧縮において、従来から行われていた空間周波数特性を用いた圧縮方式の他に、フレーム間での時間相関特性を用いた圧縮方式を取り入れたことである。ＭＰＥＧでは、ストリームを構成している各フレーム（ピクチャとも呼ぶ）を、Ｉフレーム（フレーム内符号化ピクチャ）、Ｐフレーム（フレーム内符号化と過去からの参照関係を使用したピクチャ）、Ｂフレーム（フレーム内符号化と過去および未来からの参照関係を使用したピクチャ）の３種類に分類してデータ圧縮を行う。これらの３種では、Ｉフレームが最も大きく（つまり情報量が最も多く）、次いでＰ、Ｂの順である。圧縮アルゴリズムにも大きく依存するが、情報量の比は、おおよそＩ：Ｐ：Ｂ＝４：２：１程度となる。また一般的に、ＭＰＥＧビデオストリームは、１５フレーム（＝１ＧＯＰ）を単位として、１ＧＯＰについてＩフレームが１枚、Ｐフレームが４枚、Ｂフレームが１０枚の割合で含まれている。
【０００５】
ＭＰＥＧビデオの二つ目の特徴は、画像の複雑さに応じた動的な符号量割り当てをピクチャ単位で行える点である。ＭＰＥＧのデコーダは、デコーダバッファを備え、このデコーダバッファにデータを蓄積してからデコードを行うことで、圧縮の難しい複雑な画像に対して大量の符号量を割り当てることが可能になっている。ＭＰＥＧに限らず動画圧縮では、標準的なデコーダバッファの容量を規格で定義する場合が殆どである。ＭＰＥＧ１やＭＰＥＧ２の場合、標準デコーダバッファは、規格で容量が２２４ＫＢｙｔｅと定義されており、ＭＰＥＧエンコーダは、この容量の範囲内でデコーダバッファ占有量が遷移するようにピクチャデータを生成しなければならない。
【０００６】
図１９（Ａ）〜（Ｃ）は、従来のストリーミング方法を説明するための図である。図１９（Ａ）は、ビデオフレームを示す図、図１９（Ｂ）は、バッファ占有量の遷移を模式的に示した図、図１９（Ｃ）は、従来端末の構成例を示す図である。図１９（Ｃ）において、端末は、ビデオバッファと、ビデオデコーダと、Ｉ，Ｐ並べ替えバッファと、スイッチとを備えている。ビデオバッファが、前述のデコーダバッファに相当し、転送されてくるデータは、ビデオバッファに蓄積された後、ビデオデコーダによってデコードされる。デコードされたデータは、Ｉ，Ｐ並べ替えバッファおよびスイッチを通じて再生時刻順に並べ替えられる。
【０００７】
図１９（Ｂ）において、縦軸はバッファ占有量（ビデオバッファのデータ蓄積量）を、横軸は時間を示し、図中の太線がバッファ占有量の時間的遷移を示している。また、太線の傾きは、ビデオのビットレートに相当し、一定のレートでデータがバッファに入力されていることを示している。また、一定間隔（３３．３６６７ｍｓｅｃ）でバッファ占有量の削減が起こっているが、これは、一定周期で各フレームのデータがデコードされていくことによる。また、斜め点線と時間軸との交点は、各ビデオフレーム内のデータがビデオバッファへ向けて転送開始される時刻を示している。従って、図１９（Ａ）に示されたフレームＸの転送開始時刻はｔ１、フレームＹの転送開始時刻はｔ２となる。
【０００８】
図１９（Ａ），（Ｂ）において、ビデオの先頭フレームＸがビデオバッファに入力開始される時刻ｔ１から、最初にデコードが実行される時刻（図中、太線の第１の立ち下がり位置）までの時間を一般に、ｖｂｖ＿ｄｅｌａｙ時間と呼ぶ。最初のデコードは、ビデオバッファが満杯になった瞬間に実行されるので、ｖｂｖ＿ｄｅｌａｙ時間は、通常、データ入力開始から容量２２４ＫＢｙｔｅのビデオバッファが満杯になるまでの時間であり、従って、ビデオの入力が開始されてから、デコーダを通じてビデオ再生が開始されるまでの初期遅延時間（頭出し時の待ち時間）ということになる。
【０００９】
図１９（Ａ）のフレームＹが複雑な画像である場合、図１９（Ｂ）に示されているように、その符号量が大量なので、フレームＹのデコード時刻（図中のｔ３）よりも早い時刻（図中のｔ２）から、ビデオバッファへのデータ転送を開始しなければならない。ただし、どんなに複雑な画像でも、バッファを占有するピクチャ量は、２２４ＫＢｙｔｅの許容範囲内である。
【００１０】
図１９（Ｂ）に示したバッファ遷移がきちんと保たれるようにビデオバッファにデータが転送されるならば、ビデオバッファのアンダーフローやオーバーフローによるストリーミング破綻が起こらないことは、ＭＰＥＧの規格で保証されている。
【００１１】
（ネットワーク転送ジッタ吸収用の受信バッファの説明）
ところが、図２０に示すように、サーバ２０１と端末２０２とをネットワーク２０３で接続し、ストレージ２１０中のＭＰＥＧデータを配信する場合、生成モジュール２１１でパケットを生成する時間や、ネットワーク機器２０４，２０５における転送手続き時間、ネットワーク２０３の混雑などに伴なう伝送遅延時間などのために、データの転送レートに揺れが生じる。従って、実際には、図１９（Ｂ）に示したバッファ遷移が保たれないのが実情である。このような転送レートの揺れ（ジッタ）を緩和吸収する方法としては、まず、ネットワークの帯域に比べ十分小さい符号化レートのコンテンツを流すことが考えられる。しかし、ネットワーク資源をできる限り有効に使って高品位な映像や音声を提供する必要があるので、この方法は適切ではない。そこで、一般には、ネットワーク機器２０４，２０５に、それぞれ適当な容量の送受信バッファ２０６，２０７を設け、普段からデータを多少先送り気味に転送しておいて、データ転送に遅延が発生した時の不足を補う方法が採用される。
【００１２】
ここで、端末２０２側に受信バッファ２０７を設けるということは、結局、図１９（Ｂ）のバッファ遷移において、バッファ占有量の上限を、デコーダバッファ２０８の規格である２２４ＫＢｙｔｅから受信バッファ２０７による蓄積量の分だけかさ上げするのとおおむね等価である。図２１（Ａ），（Ｂ）に、受信バッファ２９７を追加する前後のバッファ占有量を並べて示す。なお、図２１（Ａ）に示されているのは、図１９（Ｂ）と同一のバッファ遷移である。
【００１３】
受信バッファ２０７の追加によって、バッファ遷移の許容範囲が拡がり、その結果、図１９（Ｂ）のバッファ遷移、すなわち図２１（Ａ）のバッファ遷移は、図２１（Ｂ）のようになって、ネットワークの転送レートが低下しても、アンダーフローを回避することが可能となる。反面、ｖｂｖ＿ｄｅｌａｙ時間が、受信バッファ２０７による蓄積量に相当する時間だけ長くなり、デコーダ２０９でのデコード開始および再生装置２１２での再生開始が遅れる。つまり、頭出し時間が、受信バッファ２０７へのデータ蓄積にかかる時間の分だけ長くなる。
【００１４】
【発明が解決しようとする課題】
以上から明らかなように、小規模ＬＡＮなどの信頼性や伝送速度の保証されたネットワーク環境において、ＭＰＥＧ等のマルチメディアデータをストリーミング再生する場合には、基本的に、コーデックの規格で定められた再生初期遅延時間（ｖｂｖ＿ｄｅｌａｙ）やデコーダバッファ遷移をきちんと遵守するようなシステム設計になってさえいれば、デコーダバッファのアンダーフローやオーバーフローが起こってストリーミング再生が破綻をきたすことはない。
【００１５】
しかしながら、インターネットなどの広域ネットワーク環境においては、通信経路の伝送特性変動に伴なう転送ジッタが無視できないほど大きいため、従来の端末２０２は、コーデックの規格で定められたデコーダバッファ（ｖｂｖバッファ）に加えて、図２０の受信バッファ２０７のような、転送ジッタ吸収のためのバッファを持つ場合が多い。このとき、次のような課題が存在する。
【００１６】
端末に搭載されるジッタ吸収用のバッファの容量は、一般に、機種によって様々である。そのため、同じデータを同じ条件下で配信しても、バッファ容量の多い機種ではストリーミング再生を破綻なく行えるが、少ない機種では、ジッタを吸収しきれずに破綻する場合があった。
【００１７】
この課題を解決するには、例えば、端末の搭載メモリ量を増やして、ジッタ吸収用のバッファ容量を十分確保すればよい。しかしながら、搭載メモリ量は、端末の価格を決める主な要因の一つであり、可能な限り少なく抑えたい要求がある。加えて、ジッタ吸収用のバッファ容量が多すぎると、再生開始までの頭出し時間が長くなって、ユーザにいらだちを感じさせてしまうという新たな問題が発生する。
【００１８】
それゆえに、本発明の目的は、端末のバッファ容量が機種によって異なっていても、ネットワークの伝送能力が変動しても、バッファのアンダーフローやオーバーフローによるストリーミング再生の破綻を回避することが可能であり、しかも、ストリーミング再生の破綻回避と、頭出し時の待ち時間短縮とを互いに両立させることができるようなストリーミング方法を提供することである。
【００１９】
【課題を解決するための手段および発明の効果】
第１の発明は、サーバが端末へネットワークを通じてストリームデータを送信し、かつ端末が当該ストリームデータを受信しつつ再生するストリーミング方法であって、
端末が、自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定ステップ、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、端末が、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定ステップ、
決定した目標時間および遅延時間を、端末がサーバに通知するステップ、
サーバが端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御ステップを備える。
【００２０】
上記第１の発明では、端末が、自身のバッファ容量とネットワークの伝送能力とに応じた目標量を決定し、さらに、バッファ容量を伝送能力で除して得られる値を超えない範囲内で、遅延時間を決定する。サーバは、こうして端末が決定した目標量および遅延時間に基づいて送信速度を制御するので、端末のバッファ容量が機種によって異なっていても、ネットワークの伝送能力が変動しても、バッファ量および伝送能力に応じた送信速度制御が行え、その結果、バッファのアンダーフローやオーバーフローによるストリーミング再生の破綻を回避することが可能となる。しかも、目標量とは独立に遅延時間が決定されるので、ストリーミング再生の破綻回避と、頭出し時の待ち時間短縮とを互いに両立させることができる。
【００２１】
ここで、遅延時間が、バッファ容量を伝送能力で除して得られる値以下に制限されるのは、遅延時間がこの値を超えると、ストリーミング再生の破綻が起こる恐れがあるためである。この値を超えない範囲であれば、遅延時間をどのような値に決めてもよい。ただし、値を決める際には、伝送能力の変動に対する耐性と、頭出し時の待ち時間との間のバランスが考慮される。
【００２２】
第２の発明は、第１の発明において、
制御ステップにおいて、サーバは、
端末のバッファに蓄積されているストリームデータの量が、当該目標量の近傍において当該目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする。
【００２３】
上記第２の発明では、蓄積量が目標量の近傍において目標量を超えることなく遷移するので、バッファのアンダーフローやオーバーフローが起こりにくい。
【００２４】
第３の発明は、第２の発明において、
制御ステップにおいて、サーバは、当該送信速度と、当該遅延時間と、端末がストリームデータをデコードする速度とに基づいて、端末のバッファに蓄積されるストリームデータの量を予測算出することを特徴とする。
【００２５】
上記第３の発明では、サーバが蓄積量を予測算出して、その量に基づいて送信速度制御を行うので、蓄積量を目標量の近傍で目標量を超えないように遷移させることができる。
【００２６】
ここで、端末が現在の蓄積量をサーバに通知し、サーバは、通知に基づいて送信速度制御を行ってもよい。しかし、この場合、端末からサーバへの情報伝達に時間がかかるので、サーバは、過去の蓄積量に基づいて送信速度制御を行うことになる。そのため、蓄積量を目標量の近傍で目標量を超えないように遷移させることができるとは限らない。
【００２７】
第４の発明は、第１の発明において、
端末が、ネットワークの伝送能力が所定の閾値を跨いで変化したことを検出する検出ステップ、
検出ステップでの検出結果に応じて、端末が当該目標量を変更する目標量変更ステップ、および
変更後の目標量を、端末がサーバに通知するステップをさらに備え、
制御ステップにおいて、サーバは、変更後の目標量の通知を受けると、端末のバッファに蓄積されるストリームデータの量が、当該変更後の目標量の近傍において当該変更後の目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする。
【００２８】
上記第４の発明では、伝送能力が閾値を跨いで変化すると、端末によって目標量が変更される。サーバは、変更後の目標量の近傍において変更後の目標量を超えることなく遷移するように送信速度を制御して、目標量の変更に追従する。
【００２９】
第５の発明は、第４の発明において、
検出ステップでネットワークの伝送能力が第１の閾値を跨いで低下したことを検出すると、端末は、目標量変更ステップにおいて、当該目標量を増加させる向きに変更し、
制御ステップにおいて、サーバは、当該目標量が増加されたのに応じて、当該送信速度を上昇させる向きに制御することを特徴とする。
【００３０】
上記第５の発明では、伝送能力が第１の閾値を跨いで変化すると、端末によって目標量が増加される。サーバは、送信速度を上昇させることにより、目標量の増加に追従する。
【００３１】
第６の発明は、第５の発明において、
当該第１の閾値は、実現可能な最大の伝送能力と、ストリームデータの転送ロスが発生し始めるような伝送能力との略中間の値であることを特徴とする。
【００３２】
上記第６の発明では、伝送能力が低下しつつあるとき、ストリームデータの転送ロスが発生し始める前に、送信速度を上昇させて蓄積量を増やしておく。これにより、伝送能力の低下が進行したときに、ストリーミング再生が破綻するのを防ぐことができる。
【００３３】
第７の発明は、第４の発明において、
検出ステップでネットワークの伝送能力が当該第１の閾値より小さい第２の閾値を跨いで低下したことを検出すると、端末は、目標量変更ステップにおいて、当該目標量を減少させる向きに変更し、
制御ステップにおいて、サーバは、当該目標量が減少方向に変更されたのに応じて、当該送信速度を低下させる向きに制御することを特徴とする。
【００３４】
上記第７の発明では、伝送能力が第２の閾値を跨いで変化すると、端末によって目標量が減少される。サーバは、送信速度を低下させることにより、目標量の減少に追従する。
【００３５】
第８の発明は、第７の発明において、
当該第２の閾値は、ストリームデータの転送ロスが発生し始めるような伝送能力と対応する値であることを特徴とする。
【００３６】
上記第８の発明では、伝送能力の低下が進行して、ストリームデータの転送ロスが発生し始めると、一転、送信速度を低下させる。失われたデータの再送処理を妨害しないためである。
【００３７】
ここで、送信速度を低下させる場合、サーバは、低下幅に応じた頻度でフレームの送信をスキップしなければならない。フレームがスキップされると、端末が再生して得られる映像や音声の品位劣化が起こる。この品位劣化を抑えるために、下記第９の発明では、スキップされるフレームとして、再生時刻に間に合わないフレームが選択される。下記第１０の発明では、スキップされるフレームとして、重要度の低いフレームと、重要度は高いが再生時刻に間に合わないようなフレームとが選択される。
【００３８】
第９の発明は、第８の発明において、
目標量変更ステップにおいて、端末が当該目標量を減少させる向きに変更すると、制御ステップにおいて、サーバは、送信しようとするストリームを構成する各フレームの再生時刻を現在時刻と逐次比較して、再生時刻が現在時刻よりも古いフレームの送信をスキップし、それよって当該送信速度を低下方向に制御することを特徴とする。
【００３９】
上記第１１の発明では、再生時刻に間に合わないフレームが選択的にスキップされるので、無作為的にスキップするのと比べて、送信速度の低下による品位劣化を少なく抑えることができる。
【００４０】
第１０の発明は、第８の発明において、
目標量変更ステップにおいて、端末が当該目標量を減少させる向きに変更すると、制御ステップにおいて、サーバは、送信しようとするストリームを構成する各フレームの重要度を基準値と逐次比較して、
重要度が基準値未満であるフレームについては、全て送信をスキップし、
重要度が基準値以上であるフレームについては、それぞれの再生時刻を現在時刻と逐次比較して、再生時刻が現在時刻よりも古いものだけ送信をスキップし、それによって当該送信速度を低下方向に制御することを特徴とする。
【００４１】
上記第１０の発明では、重要度の低いフレームと、重要度は高いが再生時刻に間に合わないようなフレームとが選択的にスキップされるので、無作為的にスキップするのと比べて、送信速度の低下による品位劣化を少なく抑えることができる。
【００４２】
ここで、第１０の発明のような、スキップすべきフレームを選択する際に再生時刻に間に合うか否かに加えて重要度をも考慮する方法は、典型的には、ＭＰＥＧによる映像フレームに対して用いられる。この場合、送信速度を低下させるとき、ＰやＢのフレームが重要度の低いフレームとしてスキップされる一方、Ｉフレームは、重要度の高いフレームとして、再生時刻に間に合わない場合を除いてスキップされることがないので、送信速度低下による再生画像の品位劣化が最小限に抑えられる。なお、ＭＰＥＧによる音声フレームの場合、フレーム間に重要度の違いがないので、再生時刻に間に合うか否かだけを考慮すればよい。
【００４３】
第１１の発明は、ネットワークを通じてストリームデータを送信するサーバと、当該ストリームデータを受信しつつ再生する端末とからなるシステムであって、
端末は、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段を備え、
サーバは、端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段を備える。
【００４４】
第１２の発明は、ネットワークを通じてストリームデータを送信するサーバと共に用いられ、当該ストリームデータを受信しつつ再生する端末であって、
サーバには、端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段が備わり、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段を備える。
【００４５】
第１３の発明は、ストリームデータを受信しつつ再生する端末と共に用いられ、ネットワークを通じて当該ストリームデータを送信するサーバであって、
端末には、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段が備わり、
端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段を備え、
制御手段は、端末のバッファに蓄積されているストリームデータの量が、当該目標量の近傍において当該目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする。
【００４６】
第１４の発明は、上記第１の発明のようなストリーミング方法を記述したプログラムである。
【００４７】
第１５の発明は、上記第１４の発明のようなプログラムを記録した記録媒体である。
【００４８】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照しながら説明する。図１は、本発明の一実施形態に係るストリーミング方法を実行するサーバ・クライアント・システムの構成例を示すブロック図である。図１において、本システムは、サーバ１０１と、そのクライアントとして動作する端末１０２とを備えている。サーバ１０１側には、映像や音声のデータが蓄積されている。このデータは、ＭＰＥＧによって符号化圧縮されたデータである。サーバ１０１は、端末１０２からの要求に応じ、蓄積しているデータをパケット化してストリームを生成する。そして、ネットワーク１０３を通じ、生成したストリームを端末１０２に送信する。端末１０２は、サーバ１０１から送信されるストリームを受信してデコードし、得られた映像や音声を表示出力する。
【００４９】
図２は、図１のサーバ１０１の構成を示すブロック図である。図２において、サーバ１０１は、蓄積デバイス４１１と、送受信モジュール４０２と、生成モジュール４０５と、ＲＡＭ４０４と、ＣＰＵ４１２と、ＲＯＭ４１３とを備えている。蓄積デバイス４１１には、映像や音声のデータが蓄積されている。この蓄積デバイス４１１内のデータが生成モジュール４０５に与えられる。生成モジュール４０５は、読み出しバッファ４０７と、パケット生成回路４０６と、パケット生成バッファ４０８とを含み、与えられるデータをパケット化してストリームを生成する。
【００５０】
送受信モジュール４０２は、ネットワークコントローラ４１０と、送信バッファ４０９とを含み、生成モジュール４０５によって生成されたストリームを端末１０２へ、ネットワーク１０３経由で送信する。また、端末１０２からネットワーク１０３経由で送信されてくる情報を受信する。
【００５１】
送受信モジュール４０２によって受信された端末１０２からの情報は、ＲＡＭ４０４に書き込まれる。ＲＯＭ４１３には、サーバ制御プログラムが格納されており、ＣＰＵ４１２は、ＲＡＭ４０４に記憶されている端末からの情報を参照しつつＲＯＭ４１３内のプログラムを実行し、それによって、送受信モジュール４０２および生成モジュール４０５の制御を行う。なお、ここではプログラムがＲＯＭ４１３に格納されているとしたが、ＲＯＭ以外の記憶媒体、例えばハードディスクやＣＤ−ＲＯＭ等に格納されていてもよい。
【００５２】
図３は、図１の端末１０２の構成を示すブロック図である。図３において、端末１０２は、送受信モジュール５０７と、再生モジュール５１０と、表示デバイス５１１と、ＲＯＭ５０２と、ＣＰＵ５０３とを備えている。送受信モジュール５０７は、ネットワークコントローラ５０６と、受信バッファ５０５とを含み、サーバ１０１からネットワーク１０３経由で送信されてくるストリームを受信する。また、ＣＰＵ５０３からの情報をサーバ１０１へ、ネットワーク１０３経由で送信する。
【００５３】
送受信モジュール５０７によって受信されたストリームが、再生モジュール５１０に入力される。再生モジュール５１０は、デコーダバッファ５０８と、デコーダ５０９とを含み、入力されるストリームをデコードして再生する。再生モジュール５１０により再生されたデータが表示デバイス５１１に与えられ、表示デバイス５１１は、そのデータを映像に変換して表示する。
【００５４】
ＲＯＭ５０２には、端末制御プログラムが格納されており、ＣＰＵ５０３は、ＲＯＭ５０２内のプログラムを実行し、それによって、送受信モジュール５０７、再生モジュール５１０および表示デバイス５１１の制御を行う。
【００５５】
以上のように構成されたシステムの動作を、以下に説明する。図４は、図１のシステムの全体動作を説明するためのシーケンス図である。図４には、サーバ１０１側の送受信層および制御層と、端末１０２側の送受信層および制御層とが示されており、これら各層の間でやりとりされるコマンドやストリームが時系列的に並べられている。
【００５６】
最初、本システムの全体的な動作について、図４を用いて説明する。図４において、最初、端末１０２からサーバ１０１へ、コマンド”ＳＥＴＵＰ”が送信される。サーバ１０１では、”ＳＥＴＵＰ”に応じて初期設定が行われ、設定が完了すると、サーバ１０１から端末１０２へ、”ＯＫ”が応答される。
【００５７】
サーバ１０１から”ＯＫ”が返ってくると、端末１０２からサーバ１０１へ、コマンド”ＰＬＡＹ”が送信される。サーバ１０１では、送信準備が行われ、準備が完了すると、サーバ１０１から端末１０２へ、”ＯＫ”が応答される。
【００５８】
サーバ１０１から”ＯＫ”が返ってくると、端末１０２は、ストリームを待ち受ける態勢へと移行する。この”ＯＫ”の応答に引き続いて、サーバ１０１は、ストリームの送信を開始する。
【００５９】
その後、端末１０２からサーバ１０１へ、コマンド”ＴＥＡＲＤＯＷＮ”が送信され、サーバ１０１は、”ＴＥＡＲＤＯＷＮ”に応じてストリーム送信を終了する。送信が終了されると、サーバ１０１から端末１０２へ、”ＯＫ”が応答される。
サーバ１０１から”ＯＫ”が返ってくると、端末１０２は、ストリーム待ち受け態勢から脱する。
【００６０】
以上が本システムの全体的な動作の概要であり、上で説明した限りでは、本システムの動作は、従来と同様である。本システムの動作が従来と異なるのは、次の（１）および（２）の２点である。
（１）端末１０２からサーバ１０１へのコマンド”ＳＥＴＵＰ”にパラメータ”Ｓ＿ｔａｒｇｅｔ”および”Ｔ＿ｄｅｌａｙ”が添付されており、サーバ１０１は、ストリームを送信する際、これらのパラメータに基づいて送信速度を制御する。
【００６１】
上記（１）において、”Ｓ＿ｔａｒｇｅｔ”は、端末１０２がバッファに蓄積するデータ量の目標値であり、その端末１０２に備わるバッファ（図３の例では、受信バッファ５０５およびデコーダバッファ５０８）の総容量（”Ｓ＿ｍａｘ”）と、ネットワーク１０３の伝送能力とに基づいて決定される。従って、”Ｓ＿ｔａｒｇｅｔ”は、一般に、端末１０２の機種によって値が異なる。
【００６２】
また、”Ｔ＿ｄｅｌａｙ”は、端末１０２が先頭データをバッファに書き込んでから、そのデータを読み出してデコードを開始するまでの時間（つまり頭出し遅延時間）であり、”Ｓ＿ｔａｒｇｅｔ”を送信速度（後述）で除して得られる値を最大値として、その最大値を超えない範囲内で任意の値に決定される。すなわち、「”Ｓ＿ｔａｒｇｅｔ”を送信速度で除して得られる値を超えない範囲内で」という条件が付くものの、端末１０２は、”Ｓ＿ｔａｒｇｅｔ”とは独立に”Ｔ＿ｄｅｌａｙ”を決めることができる。
【００６３】
また、「送信速度」は、単位時間に送信する情報の量をいい、例えば、単位時間に送信するパケットの個数が決められている場合、各パケットに詰め込むデータの量を増減させることによって、送信速度を制御することができる。また、各パケットに詰め込むデータの量が決められている場合、パケットと次のパケットとの時間的な間隔を伸縮させることによって、送信速度を制御することができる。あるいは、両方を同時に行う（すなわち、各パケットに詰め込むデータの量を増減させ、かつパケットと次のパケットとの時間的な間隔を伸縮させる）ことによっても、送信速度を制御することができる。本実施形態では、各パケットに詰め込むデータの量を増減させることにより速度制御を行うものとする。
【００６４】
（２）端末１０２は、ストリームの配信中、必要に応じて”Ｓ＿ｔａｒｇｅｔ”を変更することができる。この場合、変更後の”Ｓ＿ｔａｒｇｅｔ”が端末１０２からサーバ１０１に通知され、以降、サーバ１０１は、変更後の”Ｓ＿ｔａｒｇｅｔ”に基づいて送信速度を制御する。
【００６５】
上記（２）において、”Ｓ＿ｔａｒｇｅｔ”の変更は、ネットワーク１０３の伝送能力の変動に応じて行われる。具体的には、端末１０２が携帯電話の場合、電界強度（例えば「強・中・弱・圏外」の４段階の強度）を検知することができるので、この電界強度の変化を「ネットワーク１０３の伝送能力の変動」と見なして、”Ｓ＿ｔａｒｇｅｔ”を変化させる。例えば、電界強度が「強」から「中」に変化すると、端末１０２は、”Ｓ＿ｔａｒｇｅｔ”の値をより大きな値に変更し、「中」から「弱」に変化すると、”Ｓ＿ｔａｒｇｅｔ”の値をより小さな値に変更する。
本システムの動作が従来と異なるのは、主として上の２点である。
【００６６】
次に、本システムの全体動作の具体例を詳細に説明する。図４において、端末１０２は、ストリーム再生を開始するのに先立ち、端末制御プログラムに従ってＣＰＵ５０３がＲＯＭ５０２より端末に固有のパラメータ群を抽出する。このパラメータ群中には、受信バッファ５０５とデコーダバッファ５０８とを合わせた総容量（端末１０２が実際に蓄積できる最大データ量）Ｓ＿ｍａｘが含まれる。一方、ＣＰＵ５０３は、ストリーム再生補助データなどの事前入手の手続きによって、受信したいストリームデータの符号化圧縮レートＶｒや、ビデオないしオーディオのフレーム発生周期Ｔｆｒｍを知っているものとする。また、ＣＰＵ５０３は、ネットワークインターフェースを通じ、ネットワーク１０３の伝送能力、たとえば携帯電話における受信電波強度や、通信速度（ＰＨＳの場合では６４Ｋｂｐｓ接続ないし３２Ｋｂｐｓ接続などの情報）も検出しているものとする。
【００６７】
ＣＰＵ５０３は、これらＳ＿ｍａｘ、Ｖｒ、Ｔｆｒｍ、ネットワーク１０３の伝送能力（例えば有効転送速度＝ｎｅｔｗｏｒｋＲａｔｅ）などをもとに、端末１０２内のバッファにどれだけのデータを蓄積するかを示す目標量Ｓ＿ｔａｒｇｅｔ、およびストリーム再生を始めるまでのプレバッファリング時間（すなわち頭出し遅延時間）Ｔ＿ｄｅｌａｙを決定する。
【００６８】
ここで、Ｓ＿ｔａｒｇｅｔの本質的な意味は、今から開始するストリーミング再生において、Ｓ＿ｔａｒｇｅｔ近傍かつそれを越えないように端末の蓄積バッファ量が遷移すれば、途切れなく正常にストリーミング再生が持続できるような基準値のことである。前述のように、Ｔ＿ｄｅｌａｙが大きいと頭出し遅延時間が長くなるが、ネットワーク１０３の転送ジッタに対しては強くなる。しかし、遅延時間があまり長いとサービス仕様として不適切なので、Ｔ＿ｄｅｌａｙを決める際には、転送ジッタに対する耐性と、頭出し時の待ち時間との間のバランスをとる配慮が必要である。
【００６９】
なお、Ｔ＿ｄｅｌａｙの代わり、もしくはＴ＿ｄｅｌａｙと併せて、端末１０２内のバッファにデータを何バイトまで充填したらデコードを開始するかという充填量Ｓ＿ｄｅｌａｙを決定してもよい。端末１０２がＳ＿ｄｅｌａｙのみを決定してサーバ１０１に通知する場合は、サーバ１０１側でＴ＿ｄｅｌａｙ＝Ｓ＿ｄｅｌａｙ／ｎｅｔｗｏｒｋＲａｔｅなる式を用いて、Ｓ＿ｄｅｌａｙをＴ＿ｄｅｌａｙに換算することが可能である。また、Ｓ＿ｄｅｌａｙの値は、バッファ総量Ｓ＿ｍａｘに対する充填率ｒＳ（％）であってもよい（この場合、換算式は、Ｓ＿ｄｅｌａｙ＝Ｓ＿ｍａｘ＊ｒＳ／１００となる）。
【００７０】
端末１０２は、Ｓ＿ｔａｒｇｅｔと、Ｔ＿ｄｅｌａｙ（および／またはＳ＿ｄｅｌａｙ）とを準備すると、図４に示されているように、サーバ１０１に対し、ストリーム配信の準備を促すＳＥＴＵＰコマンドを発行する。ＳＥＴＵＰコマンド中には、引数としてＳ＿ｔａｒｇｅｔと、Ｔ＿ｄｅｌａｙ（および／またはＳ＿ｄｅｌａｙ）とが含まれている。サーバ１０１は、ＳＥＴＵＰを受信すると、引数をＲＡＭ４０４に記憶して、ストリーム配信のための初期設定を行う。具体的には、サーバ１０１のＣＰＵ４１２が、最初ＲＡＭ４０４から引数を取り出し、次いで、たとえばストリームのソースファイルを蓄積デバイス４１１から読み出してバッファ４０７に書き込む操作と、読み出したデータをパケット化するパケット生成回路４０６のパラメータ設定とを行う。なお、パケット生成回路４０６は、必ずしも専用のハードウエアである必要はなく、サーバ１０１（例えばワークステーションなどで実現される）のＣＰＵ４１２に同様のパケット化処理を実行させるプログラム（ソフトウエアアルゴリズム）であってもよい。
【００７１】
前述のＳ＿ｔａｒｇｅｔと、Ｔ＿ｄｅｌａｙ（および／またはＳ＿ｄｅｌａｙ）との２つの値も、パケット生成回路４０６に引き渡される。パケット生成回路４０６では、これらの値を用いて最適なレート制御パラメータの算出が行われ、その結果、端末１０２へのストリーム配信に適したレートでパケットが生成、送出されるようになる。ネットワーク１０３中にパケットを送出する準備が正常に完了すると、図４のように、送受信層から制御層にＯＫが返り、次いで、端末１０２へ向けてＳＥＴＵＰコマンドに対するＯＫが返る。こうして、本システムにおいて、ストリーム配信準備が完了する。
【００７２】
次いで、端末１０２がサーバ１０１に対し、ストリーム配信の開始を促すＰＬＡＹコマンドを発行する。サーバ１０１は、ＰＬＡＹを受信すると、ストリームデータの配信を開始する。端末１０２は、サーバ１０１からのストリームデータを受信して蓄積する。そして、蓄積開始から前述のプレバッファリング時間（Ｔ＿ｄｅｌａｙ）が経過したのちに、ストリームデータのデコード、再生を開始する。このときストリーム配信は、ＳＥＴＵＰ時に設定された適切なレート制御パラメータに基づいてなされていることはいうまでもない。
【００７３】
ストリーム再生の終了時には、端末１０２よりサーバ１０１に対し、ＴＥＡＲＤＯＷＮコマンドが発行される。サーバ１０１は、ＴＥＡＲＤＯＷＮを受信すると、ストリーム配信の終了処理を行い、全手続きを完了させる。以上が、本システムの具体的な動作例である。
【００７４】
以下には、端末１０２の動作について詳細に説明する。端末１０２は、インターネットに接続可能な携帯電話であり、電界強度（受信電波強度）を検知する機能を持っているとする。図５は、図１の端末１０２の動作を示すフローチャートである。図５において、最初、端末１０２は、２つのパラメータＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値を決定する（ステップＳ１０１）。
【００７５】
ここで、上記ステップＳ１０１の処理内容を具体的に説明する。図６は、図３のＲＯＭ５０２の記憶内容を示す図である。図６に示すように、ＲＯＭ５０２内には、端末制御プログラムと、電界強度およびＳ＿ｔａｒｇｅｔが互いに対応付けて記載されたテーブル６０１と、パラメータＴ＿ｄｅｌａｙの値とが記憶される。パラメータＳ＿ｔａｒｇｅｔの値としては、電界強度「強」と対応するＳ＿ｔａｒｇｅｔ１、「中」と対応するＳ＿ｔａｒｇｅｔ２、「弱／圏外」と対応するＳ＿ｔａｒｇｅｔ３の３つの値が記憶されている。一方、パラメータＴ＿ｄｅｌａｙの値は、１つだけが記憶されている。
【００７６】
上記３つの値Ｓ＿ｔａｒｇｅｔ１〜３は、次の関係を満たすように決められる。
Ｓ＿ｔａｒｇｅｔ３＜Ｓ＿ｔａｒｇｅｔ１＜Ｓ＿ｔａｒｇｅｔ２≦Ｓ＿ｍａｘ一方、値Ｔ＿ｄｅｌａｙは、値Ｓ＿ｍａｘをネットワーク１０３の実効的な伝送能力で除して得られる値を超えないように決められる。
【００７７】
一例として、Ｓ＿ｍａｘが５１２（ＫＢ）であれば、Ｓ＿ｔａｒｇｅｔ１＝２５６（ＫＢ），Ｓ＿ｔａｒｇｅｔ２＝３８４（ＫＢ），Ｓ＿ｔａｒｇｅｔ３＝１２８（ＫＢ）などのように決められる。また、ネットワーク１０３の実効的な伝送能力を３８４（Ｋｂｐｓ）すなわち４８（ＫＢ／ｓｅｃ）とすると、Ｔ＿ｄｅｌａｙは、５１２÷４８≒１０．７（秒）を超えない範囲で、任意の値（例えば４秒や３秒など）に決定される。
【００７８】
上記ステップＳ１０１では、ＲＯＭ５０２から、初期値としてのＳ＿ｔａｒｇｅｔ１と、値Ｔ＿ｄｅｌａｙとが読み出される。
【００７９】
なお、ここでは、Ｓ＿ｔａｒｇｅｔ１〜３と、Ｔ＿ｄｅｌａｙの値とが予め計算されてＲＯＭ５０２に記憶されており、ＣＰＵ５０３は、必要な値をＲＯＭ５０２から読み出すようにしているが、代わりに、バッファの総容量と、ネットワーク１０３の実効的な伝送能力と、Ｓ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値を計算するためのプログラムとをＲＯＭ５０２に記憶しておいてもよい。この場合、ＣＰＵ５０３は、必要があれば、その都度、ＲＯＭ５０２から容量、速度およびプログラムを読み出して、Ｓ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値を計算する。また、ここでは、Ｔ＿ｄｅｌａｙの値が１つだけであるが、複数の値を準備しておいて、その中から選択してもよい。以上がステップＳ１０１の処理内容である。
【００８０】
再び図５において、端末１０２は、ステップＳ１０１で決定されたＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙをＳＥＴＵＰコマンドに添付して、サーバ１０１へ向けて送信する（ステップＳ１０２）。応じて、サーバ１０１からストリームが送られてくる。ストリーム送信の際、サーバ１０１は、端末から通知されたＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙに基づく送信速度制御を実行する（サーバ側の動作ついては後述）。
【００８１】
次に、端末１０２は、サーバ１０１から送られてくるストリームを受信して、バッファに書き込む動作を開始する（ステップＳ１０３）。具体的には、図３に示されているように、ネットワーク１０３を通じて送られてくるストリームは、まずネットワークコントローラ５０６を経由して受信バッファ５０５に書き込まれる。時間が経過して受信バッファ５０５が満杯になると、受信バッファ５０５内のストリームが先頭データから順番に読み出されて、デコーダバッファ５０８へと書き込まれていく。
【００８２】
次に、端末１０２は、バッファリング開始から時間がＴ＿ｄｅｌａｙだけ経過したか否かを判定し（ステップＳ１０４）、その判定結果が否定であれば、肯定となるまで待機する。ステップＳ１０４の判定結果が肯定となると、端末１０２は、バッファからストリームを読み出してデコード・再生する動作を開始する（ステップＳ１０５）。具体的には、図３において、ＣＰＵ５０３がバッファリング開始からの経過時間を計測しており、その計測結果がＲＯＭ５０２内のＴ＿ｄｅｌａｙと一致した瞬間、再生モジュール５１０に命じて、デコーダバッファ５０８内のストリームを先頭データから順番に読み出してデコーダ５０９に入力する処理を開始させる。
【００８３】
次に、端末１０２は、ネットワーク１０３の伝送能力が閾値を跨いで変化したか否かを判定する（ステップＳ１０６）。この判定は、具体的には、次のようにして行われる。例えば、ネットワーク１０３を管理するホストコンピュータ（図示せず）が、ネットワーク１０３の伝送能力に関する情報をネットワーク１０３経由で端末１０２に随時配信するようにし、端末１０２は、ホストコンピュータからの情報をもとに変化の有無を判定する。
【００８４】
この場合、具体的には、図３に示すように、伝送能力に関する情報が送受信モジュール５０７を通じてＣＰＵ５０３へと送られる。ＲＯＭ５０２には、予め閾値が格納されており、ＣＰＵ５０３は、送られてきた情報と、保持している前回の情報と、ＲＯＭ５０２内の閾値とを互いに比較することにより、伝送能力が閾値を跨いで変化したか否かを判定することができる。
【００８５】
または、ネットワーク１０３を管理するホストコンピュータがその伝送能力に関する情報を端末１０２に配信する機能を持たない場合、端末１０２は、例えば、次のようにして自ら判定を行うことができる。すなわち、端末１０２が携帯電話の場合、図７（後述）に示すように、周囲の電界強度を検知して、検知結果を「強・中・弱・圏外」のように表示する機能を持っている。この電界強度の変化をネットワーク１０３の伝送能力の変化と見なせば、端末１０２は、検出を簡単に行えることになる。
【００８６】
ステップＳ１０６の判定結果が肯定の場合、端末１０２は、新たなＳ＿ｔａｒｇｅｔを決定し（ステップＳ１０７）、それをサーバ１０１へ向けて送信する（ステップＳ１０８）。一方、ステップＳ１０６の判定結果が否定の場合、ステップＳ１０７，Ｓ１０８をスキップして、ステップＳ１０９（後述）を実行する。
【００８７】
ここで、上記ステップＳ１０６およびステップＳ１０７の処理内容について、詳しく説明する。以下では、端末１０２が携帯電話であり、電界強度の変化に応じてＳ＿ｔａｒｇｅｔを変更する場合を説明する。図７は、あるエリアにおける電界強度の分布と、端末の移動に伴う伝送能力の変化とを示す模式図である。図７（Ａ）には、３つの中継局Ｂ１〜Ｂ３を含むエリアにおける電界強度分布が示されている。図７（Ａ）において、各中継局Ｂ１〜Ｂ３を中心とする同心円が、互いに等しい電界強度の点を繋いでできる等電界曲線である。
【００８８】
例えば、中継局に最も近い同心円７０３内では、電界強度が「強」であり、この同心円７０３から次の同心円７０４までの間の領域では「中」となる。さらに、同心円７０４から同心円７０５までの間では「弱」、同心円７０５の外側の領域では「圏外」となる。ただし、各中継局を中心とする同心円は、一部が互いに交差しており、電界強度が「圏外」となる領域は、わずかしかない。
【００８９】
いま、端末１０２は、矢印７０２で示される経路に沿って、中継局Ｂ１の近傍から中継Ｂ２の近傍へ移動しようとしている。図７（Ｂ）には、図７（Ａ）の矢印７０２に沿った電界強度（これをネットワーク１０３の伝送能力と見なすことができる）が示されている。図７（Ｂ）に示されているように、電界強度は、端末１０２が中継局の近傍にあるとき「強」であり、中継局Ｂ１から離れるにつれて「中」、「弱」、「圏外」のようにだんだん弱くなっていく。そして、中継局Ｂ１の「圏外」となった直後、端末１０２は、中継局Ｂ２の「圏内」に入り、電波強度が「弱」、「中」、「強」のようにだんだん強くなっていく。
【００９０】
上記のように移動する端末１０２は、電界強度が「強」から「中」へと変化した瞬間、ネットワーク１０３の伝送能力が閾値Ａを跨いで変化したと判定して、新たなＳ＿ｔａｒｇｅｔを決定し、「中」から「弱」へと変化した瞬間、伝送能力が閾値Ｂを跨いで変化したと判定して、新たなＳ＿ｔａｒｇｅｔを決定する。逆に、「弱」から「中」へと変化した瞬間、伝送能力が閾値Ｂを跨いで変化したと判定して、新たなＳ＿ｔａｒｇｅｔを決定し、「中」から「強」へと変化した瞬間、伝送能力が閾値Ａを跨いで変化したと判定して、新たなＳ＿ｔａｒｇｅｔを決定する。
【００９１】
なお、一般的には、閾値Ａは、ネットワーク１０３において実現可能な最大の伝送能力と、ストリームの転送ロスが発生し始めるような伝送能力との略中間の値である。閾値Ｂは、ストリームの転送ロスが発生し始めるような伝送能力と対応する値である。
【００９２】
新たなＳ＿ｔａｒｇｅｔは、ＲＯＭ５０２内のテーブル６０１（図６）を参照することにより、次のように決定される。図８は、図５のステップＳ１０７の詳細を示すフローチャートである。図８において、端末１０２は、最初、変化後の電界強度が「強」か否かを判定し（ステップＳ２０１）、判定結果が肯定であれば、新たなＳ＿ｔａｒｇｅｔをＳ＿ｔａｒｇｅｔ１に決定する（ステップＳ２０２）。ステップＳ２０１の判定結果が否定あれば、ステップＳ２０２をジャンプして、ステップＳ２０３に進む。
【００９３】
次に、端末１０２は、変化後の電界強度が「中」か否かを判定し（ステップＳ２０３）、判定結果が肯定であれば、新たなＳ＿ｔａｒｇｅｔをＳ＿ｔａｒｇｅｔ２に決定する（ステップＳ２０４）。ステップＳ２０３の判定結果が否定であれば、ステップＳ２０４をジャンプして、ステップＳ２０５に進む。
【００９４】
次に、端末１０２は、変化後の電界強度が「弱／圏外」か否かを判定し（ステップＳ２０５）、判定結果が肯定であれば、新たなＳ＿ｔａｒｇｅｔをＳ＿ｔａｒｇｅｔ３に決定し（ステップＳ２０６）、その後、図５のフローに戻る。ステップＳ２０５の判定結果が否定であれば、ステップＳ２０６をジャンプして、図５のフローに戻る。
【００９５】
従って、図７（Ａ）の矢印７０２に沿って端末１０２が移動して行く場合、電界強度の変化に伴って、端末１０２は、パラメータＳ＿ｔａｒｇｅｔの値を、Ｓ＿ｔａｒｇｅｔ１→Ｓ＿ｔａｒｇｅｔ２→Ｓ＿ｔａｒｇｅｔ３→Ｓ＿ｔａｒｇｅｔ２→Ｓ＿ｔａｒｇｅｔ１のように変化させる。具体例を挙げれば、２５６（ＫＢ）→３８４（ＫＢ）→１２８（ＫＢ）→３８４（ＫＢ）→１２８（ＫＢ）のように変化させる。以上が、ステップＳ１０６およびステップＳ１０７の具体的な処理例である。
【００９６】
再び図５において、ステップＳ１０８で端末１０２が新たなＳ＿ｔａｒｇｅｔをサーバ１０１へ向けて送信すると、それに応じて、サーバ１０１は、パラメータＳ＿ｔａｒｇｅｔの値を、端末１０２から新たに通知された値に変更して、送信速度制御を続行する。
【００９７】
次に、端末１０２は、ストリーミング再生を終了するか否かを判断し（ステップＳ１０９）、終了する場合は、サーバ１０１へコマンドＴＥＡＲＤＯＷＮを送信すると共に、ストリームの受信およびバッファリングを停止し（ステップＳ１１０）、次いで、再生処理を停止する（ステップＳ１１１）。一方、ストリーミング再生を継続する場合には、端末１０２は、ステップＳ１０６に戻って、上記と同様の処理を繰り返す。以上が、端末１０２の動作である。
【００９８】
次に、サーバ１０１の動作について詳細に説明する。なお、ここでは説明を簡単にするために、サーバ１０１は、ＭＰＥＧ１ビデオ（ＩＳＯ／ＩＥＣ １１１７２−２）、ＭＰＥＧ２ビデオ（ＩＳＯ／ＩＥＣ １３８１８−２）、あるいはＭＰＥＧ２−ＡＡＣオーディオ（ＩＳＯ／ＩＥＣ １３８１８−７）のような、固定周期Ｔｆｒｍでフレームを発生させる符号化圧縮アルゴリズムを用いて符号化を行い、かつ、固定周期Ｔｓで符号化データのパケット化を行うものとする。
このパケット化は、フレーム単位で行われるものとする。
【００９９】
最初、サーバ１０１が行うストリーム送信速度制御の概要について、図９〜図１１を用いて説明する。図９〜図１１は、サーバ１０１が行うストリーム送信速度制御によって、端末１０２のバッファに蓄積されているデータ量（バッファ占有量）がどのように遷移するかを示す図である。サーバ１０１は、送信先の端末１０２において、バッファ占有量が図９〜図１１に示されているごとく遷移するように、ストリームの送信速度を制御する。
【０１００】
図９には、バッファ占有量がＳ＿ｔａｒｇｅｔに近づいていく様子が示されている。図１０には、バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がより大きな値（Ｓ＿ｔａｒｇｅｔ２）に変更された場合に、バッファ占有量がＳ＿ｔａｒｇｅｔ２に近づいていく様子が示されている。図１１には、バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がより小さな値（Ｓ＿ｔａｒｇｅｔ３）に変更された場合に、バッファ占有量がＳ＿ｔａｒｇｅｔ３に近づいていく様子が示されている。
【０１０１】
図９〜図１１に共通して、”Ｓ＿ｍａｘ”は、端末１０２のバッファの総容量であり、”Ｓｕｍ”が、バッファ占有量である。”ｄｅｌｔａ（０，１，２，…）”は、サーバ１０１が単位時間Ｔｓあたりに送信するデータの量（すなわち、１つのパケットに詰め込まれているデータの量）を示す。ここで、単位時間Ｔｓは、サーバ１０１がパケットを送信する周期であり、固定値である。”Ｌ（０，１，２，…）”は、１つのフレームあたりのデータ量である。
【０１０２】
サーバ１０１は、端末１０２からＴ＿ｄｅｌａｙの値の通知を受けると、その値に基づいてストリームの送信速度を制御する。この速度制御は、１つのパケットに詰め込むデータの量を変化させることにより行われる。
【０１０３】
図９において、サーバ１０１が最初に送信したパケット（ｉ＝０）には、量ｄｅｌｔａ０のデータが詰め込まれており、時刻ｔ＝０では、バッファ占有量Ｓｕｍは、ｄｅｌｔａ０となる。単位時間Ｔｓが経過すると、次のパケット（ｉ＝１）が送られてくるが、そこには、量ｄｅｌｔａ１のデータが詰め込まれている。従って、時刻ｔ＝Ｔｓでは、Ｓｕｍは、｛ｄｅｌｔａ０＋ｄｅｌｔａ１｝となる。以降、単位時間Ｔｓが経過する毎に、次々とパケット（ｉ＝２，３，…）が送られてきて、Ｓｕｍにｄｅｌｔａ２，ｄｅｌｔａ３，…が加算されていく。
【０１０４】
一方、３つ目のパケット（ｉ＝２）が送られてくる以前である時刻ｔ＝Ｔ＿ｄｅｌａｙに、バッファからデータを読み出してデコードする処理が開始される。デコードはフレーム単位で行われるので、ｔ＝Ｔ＿ｄｅｌａｙ以降、固定周期Ｔｆｒｍ毎に、ＳｕｍからＬ０，Ｌ１，Ｌ２…が減算されていく。
【０１０５】
すなわち、バッファ占有量Ｓｕｍは、時刻ｔ＝０以降、周期Ｔｓ毎に、ｄｅｌｔａ０，ｄｅｌｔａ１，…が加算されて、だんだん増加していく。その一方で、時刻ｔ＝Ｔ＿ｄｅｌａｙ以降、周期Ｔｆｒｍ毎にＬ０，Ｌ１，Ｌ２…が減算されていく。従って、Ｓｕｍが目標値Ｓ＿ｔａｒｇｅｔに達する直前までの期間は、１つのパケットに詰め込むデータ量を標準よりも多くして（より一般的には送信速度を速くして）、バッファへの書き込み速度がバッファからの読み出し速度を上回るようにし、それ以降は、１つのパケットに詰め込むデータ量を標準に戻して、書き込み速度と読み出し速度とを均衡させれば、Ｓｕｍを目標値Ｓ＿ｔａｒｇｅｔの近傍で遷移させることが可能となる。
【０１０６】
このような送信速度制御を行えば、図１０，図１１のように、目標値Ｓ＿ｔａｒｇｅｔが途中で新たな目標値（Ｓ＿ｔａｒｇｅｔ２，３）に変更された場合にも、Ｓｕｍを新たな目標値（Ｓ＿ｔａｒｇｅｔ２，３）の近傍で遷移させることが可能となる。
【０１０７】
すなわち、図１０において、Ｓｕｍが目標値Ｓ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔがより大きな値（Ｓ＿ｔａｒｇｅｔ２）に変更されると、サーバ１０１は、以降のパケット（ｉ＝３，４）に詰めるデータの量を増やすことによって、バッファへの書き込み速度がバッファからの読み出し速度を上回るようにする。Ｓｕｍが新たな目標値Ｓ＿ｔａｒｇｅｔ２に達して以降は、１つのパケットに詰め込むデータ量を標準に戻して、書き込み速度と読み出し速度とを均衡させればよい。
【０１０８】
また、図１１において、Ｓｕｍが目標値Ｓ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔがより小さな値（Ｓ＿ｔａｒｇｅｔ３）に変更されると、サーバ１０１は、以降のパケット（ｉ＝３，４）に詰めるデータの量を減らすことによって、バッファへの書き込み速度がバッファからの読み出し速度を下回るようにする。Ｓｕｍが新たな目標値Ｓ＿ｔａｒｇｅｔ３に達して以降は、１つのパケットに詰め込むデータ量を標準に戻して、書き込み速度と読み出し速度とを均衡させればよい。
【０１０９】
次に、上で説明したようなサーバ１０１による送信速度制御について詳細に説明する。図１２は、サーバ１０１が行う送信速度制御アルゴリズムの一例を示すフローチャートである。図１２において、最初、端末１０２が自身のバッファ占有量（Ｓｕｍ）を検出し、サーバ１０１は、端末１０２からバッファ占有量Ｓｕｍの通知を受ける（ステップＳ３０１）。次に、サーバ１０１は、ステップＳ３０１で通知されたバッファ占有量Ｓｕｍが、端末１０２から指定された目標値Ｓ＿ｔａｒｇｅｔの近傍で遷移しているか否かを判定する（ステップＳ３０２）。その判定結果が肯定であれば、現在の送信速度が維持される。
【０１１０】
ステップＳ３０２の判定結果が否定の場合、サーバ１０１は、ステップＳ３０１で通知されたバッファ占有量Ｓｕｍが目標値Ｓ＿ｔａｒｇｅｔよりも大きいか否かを判定する（ステップＳ３０３）。そして、判定結果が否定であれば、送信速度を現在よりも速い速度に変更し（ステップＳ３０４）、その後、ステップＳ３０６に進む。一方、ステップＳ３０３の判定結果が肯定であれば、送信速度を現在よりも遅い速度に変更し（ステップＳ３０５）、その後、ステップＳ３０６に進む。
【０１１１】
ステップＳ３０６では、速度制御動作を継続するか否かが判断され、判断結果が肯定の場合、ステップＳ３０１に戻って、上記と同様の動作が繰り返される。一方、判断結果が否定の場合、動作が終了される。以上が、サーバ１０１が行う送信速度制御の一例である。
【０１１２】
ところで、図１２の例では、端末１０２が自身のバッファ占有量を検出して、サーバ１０１に通知している。しかしその場合、端末１０２が検出するのは、現在時刻におけるバッファ占有量である。その上、端末１０２からサーバ１０１への情報伝達に時間がかかるので、サーバ１０１は、伝達遅延時間の分だけ過去のバッファ占有量に基づいて送信速度制御を行うことになり、バッファ占有量をＳ＿ｔａｒｇｅｔの近傍で遷移させるのは、現実には困難である。
【０１１３】
これに対して、以下に説明する別の例（図１３，１４参照）では、未来のある時点でのバッファ占有量に基づいて送信速度制御を行うことによって、バッファ占有量をＳ＿ｔａｒｇｅｔの近傍で遷移させることが可能となる。この場合、サーバ１０１は、端末１０２からＳｕｍの通知を受けるのでなく、未来のある時刻における端末１０２側のバッファ占有量Ｓｕｍを予測算出する。この予測算出は、次のようにして行われる。
【０１１４】
すなわち、図２において、ＲＯＭ４１３には、パケット送信周期Ｔｓ（固定値）と、デコード周期Ｔｆｒｍ（固定値）とが予め記憶されている。ＣＰＵ４１２は、パケットが生成される際、そのパケットに詰め込まれたデータの量（ｄｅｌｔａ０，ｄｅｌｔａ１，ｄｅｌｔａ２，…）をＲＡＭ４０４に記憶させておく。さらに、ストリームが送信される際、各フレームのデータ量（Ｌ０，Ｌ１，Ｌ２，…）をＲＡＭ４０４に記憶させておく。
【０１１５】
ＲＡＭ４０４にはまた、先に端末１０２から通知されたＴ＿ｄｅｌａｙが記憶されており、ＣＰＵ４１２は、ＲＯＭ４１３内のＴｓおよびＴｆｒｍと、ＲＡＭ４０４内のｄｅｌｔａ（０，１，２，…）、Ｌ（０，１，２，…）およびＴ＿ｄｅｌａｙとを参照して所定の演算を行うことにより、未来のある時刻におけるバッファ占有量Ｓｕｍを算出することができる。このような算出処理を行うことによって、サーバ１０１は、端末１０２側においてバッファ占有量Ｓｕｍがどのように遷移してくか（図９〜図１１参照）を予測することができる。
【０１１６】
以下、サーバ１０１が端末１０２のバッファ占有量Ｓｕｍを予測算出して送信速度制御を行う具体的な動作例について、図９のバッファ遷移図、図１３および図１４のフローチャート、図１５のパケット構成図を用いて説明する。
【０１１７】
図９において、Ｓ＿ｍａｘは、端末１０２内バッファの有効蓄積量の最大値（これを簡単に「バッファの総容量」と呼んでいる）であり、Ｓ＿ｔａｒｇｅｔは、今回のストリーミングにおいて端末１０２内バッファに蓄積しようとする目標量であり、Ｔ＿ｄｅｌａｙは、頭出し遅延時間の設定値である。これら各パラメータの意味については、既に説明したとおりである。以下では、端末１０２よりＳ＿ｔａｒｇｅｔとＴ＿ｄｅｌａｙが通知されたものとして説明を行う。
【０１１８】
本実施の形態では、理解を簡単にするために、固定時間周期Ｔｓ毎にパケットの生成・配信を行う例（ｉ＝ｎに相当する時刻でパケット配信：ｎは整数）を示している。また、ｉ＝ｎに相当する時刻（ｔ＝ｉ＊Ｔｓ）でパケットの配信がなされた際に、端末１０２の受信バッファ５０５およびデコーダバッファ５０８内の蓄積量Ｓｕｍは、数フレームに相当するデータ量が瞬時に増加しているが、これは、図１５（Ａ）に示されているように、１パケットに複数フレームを挿入するパターンでパケットを生成して端末１０２に配信しているためである。実際には、パケット配信には転送時間がかかり、図のように瞬時にバッファ占有量が増加する訳ではない（傾き＝ｎｅｔｗｏｒｋＲａｔｅの斜線になる）が、あくまでモデルとして単純化して取り扱うものとする。また、時刻ｔ＝Ｔ＿ｄｅｌａｙ以降、階段状にバッファ占有量が減じられていくのは、その時刻に端末１０２でストリーム再生が始まったことを示している。すなわち、フレームの再生周期Ｔｆｒｍ毎に、各々のフレーム長Ｌ＝Ｌ［ｋ］（ｋは整数）ずつデコーダ５０９でデータが処理される。
【０１１９】
図１３および図１４は、図９のバッファ遷移を実現するためにサーバ１０１によって行われる送信制御アルゴリズムの別の例を示したフローチャートである。図１３がアルゴリズムの全体像であり、図１４は、図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの一例を示すフローチャートである。このようなアルゴリズムを記述したプログラムがＲＯＭ４１３（図２参照）に格納されており、ＣＰＵ４１２は、このプログラムに従って各種の演算や制御を行い、その結果、図９のバッファ遷移が実現される。なお、説明を簡単にするために、ストリーム途中での配信停止などは、今回考えないものとする。以下、各ステップについて順次説明を行う。
【０１２０】
図９において、サーバ１０１は、端末１０２から送られてきたＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙを受信して記憶する（ステップＳ４０１）。具体的には、図２において、端末１０２からネットワーク１０３経由で送られてきたＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値が、ネットワークコントローラ４１０を通じてＲＡＭ４０４に書き込まれる。
【０１２１】
なお、ここでは、端末１０２がパラメータＳ＿ｔａｒｇｅｔおよびＴ＿ｄｅｌａｙの値を決定して、結果をサーバ１０１に通知しているが、代わりに、サーバ１０１がそれらの値を予め記憶しておいてもよく、あるいは、端末１０２の機種情報（バッファの総容量等）を記憶しておいて、この機種情報をもとにサーバ１０１がパラメータの値を計算してもよい。
【０１２２】
次に、各変数の初期化が行われる（ステップＳ４０２，Ｓ４０３）。各変数の意味は、図１４の説明にて後述する。初期化が完了すると、ステップＳ４０４以降の処理、すなわち関数ｍｋＰａｃｋｅｔにてパケットを生成してネットワーク１０３中に送出する処理が開始される。生成されたパケットは、この例では固定周期Ｔｓで端末１０２に配信されるので、サーバ１０１は、ステップＳ４０５にてタイミング調整を行ったのち、ステップＳ４０６にて送出を行う。この一連の処理が完了すると、ＣＰＵ４１２は、関数ｍｋＰａｃｋｅｔの実行カウンタｉを更新し、ステップＳ４０４に戻ってループする。ストリームデータの読み出しおよびパケット化が全て完了すると、ＣＰＵ４１２は、関数ｍｋＰａｃｋｅｔを抜けて、ステップＳ４０４に判定結果ＦＡＬＳＥでｒｅｔｕｒｎする。ＣＰＵ４１２は、このとき配信が完了したと見なし、アルゴリズムを完了する。以上が、本送信制御アルゴリズムの概要である。
【０１２３】
次に、ステップＳ４０４に示された関数ｍｋＰａｃｋｅｔの詳細なアルゴリズムであるが、まず各変数について説明を行う。Ｓｕｍは、端末１０２内の受信バッファ５０５およびデコーダバッファ５０８に蓄積されているデータ量の総和であり、Ｌは、フレームのデータ量であり、ｄｅｌｔａは、関数ｍｋＰａｃｋｅｔが今回呼ばれてからパケット化したデータ量の総和（すなわち１つのパケットに詰め込んだデータの量）であり、ｉｎは、蓄積デバイス４１１から読み出したストリームソースのフレーム数を示すカウンタであり、ｏｕｔは、端末１０２内のデコーダ５０９でデコードされたフレーム数を示すカウンタであり、ｄｔｓは、デコーダ５０９にてフレームがデコードされる時刻であり、ｇｒｉｄは、前回の関数ｍｋＰａｃｋｅｔの１ループを処理する際に進んだｄｔｓの上限値である。
【０１２４】
図１４において、関数ｍｋＰａｃｋｅｔは、大きくパケット生成アルゴリズムＡ１と、デコード量算出アルゴリズムＡ２との２つのアルゴリズムに分けられる。前者において、最初のステップ（Ｓ５０１）では、ＣＰＵ４１２は、ｄｅｌｔａをクリアする。続くステップＳ５０２では、ＣＰＵ４１２は、Ｌ＝Ｌ［ｉｎ］のフレーム（既に読み出し済み）を今回のパケット生成に用いて良いかどうかの判定を行う。判定の基準は、（ａ）ＳｕｍにＬを加えてもＳ＿ｔａｒｇｅｔを越えないこと、および（ｂ）今回の関数呼び出しでパケット化したデータの量（今回１つのパケットに詰め込んだデータの量）ｄｅｌｔａにＬを加えても、１つのパケットに詰め込み可能なデータ量の上限値ｄｅｌｔａＭａｘを超えないこと、の２つであるである。
【０１２５】
ここでｄｅｌｔａＭａｘは、図１５（Ａ）に示される不等式
（ｄｅｌｔａＭａｘ＋ｈｄｒ）／Ｔｓ＜ＮｅｔｗｏｒｋＲａｔｅ
を満たす値であって、周期Ｔｓ以内に端末に配信可能なデータ量の最大値であり、ネットワーク１０３の実効転送レート（伝送能力）から算出が可能である。ステップＳ５０２にて真と判定されると、ＣＰＵ４１２は、ステップＳ５０３に進み、Ｌ＝Ｌ［ｉｎ］のフレームをパケット化する。続くステップＳ５０４では、ＣＰＵ４１２は、パケット化の実行に伴い、Ｓｕｍおよびｄｅｌｔａを更新する。続くステップＳ５０５では、ＣＰＵ４１２は、次のフレームのデータを読み出しバッファ４０７から、フレーム長ＬをＲＡＭ４０４から、それぞれ読み出す。
そして、Ｌが０よりも大きいか否かを判定する。
【０１２６】
ステップＳ５０５の判定結果が否定、すなわちＬ＝０であれば、ＣＰＵ４１２は、全データの読み出しが完了した（Ｅｎｄ ｏｆ Ｆｉｌｅ検出）とみなし、関数を抜ける。そして、メインフロー（図１３）のステップＳ４０４に判定結果ＦＡＬＳＥでＲＥＴＵＲＮする。一方、判定結果が肯定、すなわちＬ＞０であれば、ＣＰＵ４１２は、次のステップ（Ｓ５０６）に進み、Ｌ［ｉｎ］を配列ｌｅｎｇ内に加える（ＲＡＭ４０４に記憶させる）。これは後ほど説明するが、デコード量算出アルゴリズムＡ２で用いるためである。次に、ＣＰＵ４１２は、ステップＳ５０７に進み、読み出したフレーム数カウンタｉｎを更新して、ステップＳ５０２にループする。
【０１２７】
上記のループによるパケット生成を繰り返すうち、Ｓｕｍおよびｄｅｌｔａの値がだんだん大きくなっていく。そして、ステップＳ５０２にてＳｕｍまたはｄｅｌｔａが十分大きくなったと判定されると、ＣＰＵ４１２は、このループを抜けて、デコード量算出アルゴリズムＡ２に入る。
【０１２８】
デコード量算出アルゴリズムＡ２において、最初のステップ（Ｓ５０８）では、ｉ＊Ｔｓがｇｒｉｄ以上であるか否かが判定される。このステップＳ５０８は、端末１０２においてデコードが開始される時刻になったかどうかを判定することが目的である。具体的には、ｇｒｉｄが最初Ｔ＿ｄｅｌａｙに設定されているため、関数呼び出しカウンタ数ｉが小さくてｔ＝ｉ＊Ｔｓがｇｒｉｄ未満の間は、端末１０２でのデコードがまだ始まっていないものと判定される。図９では、ｉ＝０およびｉ＝１と対応する時刻がこれに相当する。
【０１２９】
ステップＳ５０８の判定結果が否定の場合、ＣＰＵ４１２は、デコードによるフレームデータの減算を行わずに関数を抜ける。一方、ｉが十分大きくなってパケット生成時刻ｔ＝ｉ＊Ｔｓがｇｒｉｄ以上になると、ＣＰＵ４１２は、端末１０２でのデコードが既に始まっているとみなし、フレームデータの減算処理を行う。図９では、ｉが２以上の時刻がこれに相当する。続くステップＳ５０９からステップＳ５１２までのループにおいて、現在のｇｒｉｄ時刻から次のｇｒｉｄ時刻（＝ｇｒｉｄ＋Ｔｓ）に挟まれた時間内にデコード処理されるフレームデータの量ｌｅｎｇ［ｏｕｔ］をＳｕｍから減算し、かつデコードしたフレーム数ｏｕｔをカウントアップする。
【０１３０】
上記ループ内のステップＳ５１１において、ｄｔｓには、フレームを１つデコードするたびにＴｆｒｍずつ加算されるが、これは、本実施形態が固定時間間隔Ｔｆｒｍのフレーム発生を行う符号化方式を用いていることに由来する。ステップＳ５１２では、ＣＰＵ４１２は、今回の時間間隔Ｔｓでデコードされるべきフレームの有無を判定している。ステップＳ５１２の判定結果が否定、すなわち、もはや今回の時間間隔Ｔｓでデコードされるフレームは無いと判定されると、ＣＰＵ４１２は、上記のループ（ステップＳ５０９〜Ｓ５１２）から抜け、ステップＳ５１３に進む。ステップＳ５１３では、ＣＰＵ４１２は、変数ｇｒｉｄを次のｇｒｉｄ時刻に更新する。そして、関数を抜け、メインフロー（図１３）のステップＳ４０４に判定結果ＴＲＵＥでＲＥＴＵＲＮする。
【０１３１】
以上のアルゴリズムにより、図９で示したように、端末１０２内において、バッファ占有量Ｓｕｍを常にＳ＿ｔａｒｇｅｔの近傍でかつＳ＿ｔａｒｇｅｔを超えないように遷移させることが可能となる。従って、複数機種の端末１０２があって、バッファの総容量Ｓｍａｘが機種によって異なっていても、それぞれの端末１０２のＳｍａｘに応じてＳ＿ｔａｒｇｅｔを適切な値に設定すれば、バッファのオーバーフローもアンダーフローも生じないようにすることができる。
【０１３２】
なお、今回の例では、図１５（Ａ）のように１パケットに複数フレームを挿入するパターンでパケットを生成したが、代わりに、図１５（Ｂ）のように、１パケットに１フレームのフレームを挿入するパターンでパケットを生成することも可能である。この場合は、図１４のステップＳ５０２において、後半の不等式を
ｄｅｌｔａ＋（Ｌ＋ｈｄｒ） ＜＝ ｄｅｌｔａＭａｘ
とし、ステップＳ５０４の後半の等式を
ｄｅｌｔａ ＋＝ （Ｌ＋ｈｄｒ）
とするだけでよい。
【０１３３】
また、本実施形態では、説明を簡単にするために、固定時間間隔Ｔｆｒｍでフレーム発生を行う符号化方式を用いたが、使用する符号化方式―たとえばＭＰＥＧ４ビデオ（ＩＳＯ／ＩＥＣ １４４９６−２）―に合わせてデコード量算出アルゴリズムＡ２を設計すれば、必ずしも固定時間間隔のフレーム発生を行わなくても構わないことはいうまでもない。また、必ずしもフレーム単位でデータを扱うアルゴリズムでなくてもよく、例えばスライス単位、あるいはＭＰＥＧ１やＭＰＥＧ２システムストリームのパック単位でデータを扱うアルゴリズムであってもよい。
【０１３４】
一方、図１４のステップＳ５０２において、Ｓ＿ｔａｒｇｅｔの値が途中で変更されると、本アルゴリズムは瞬時に、変更された新しいＳ＿ｔａｒｇｅｔをターゲットとしてパケットの生成を行うようになる。Ｓ＿ｔａｒｇｅｔの値が途中で変更された場合のバッファ遷移の様子が、図１０および図１１に示されている。図１０において、ｉ＝３の時刻にＳ＿ｔａｒｇｅｔがＳ＿ｔａｒｇｅｔ２に変更（Ｓ＿ｔａｒｇｅｔ＜Ｓ＿ｔａｒｇｅｔ２≦Ｓ＿ｍａｘ）されると、変更後しばらくは多量のフレームデータがパケット化され（図中、ｄｅｌｔａ３やｄｅｌｔａ４）、その結果、Ｓｕｍが新しい目標値Ｓ＿ｔａｒｇｅｔ２の近傍に到達するようになる。
【０１３５】
また、図１１のように、ｉ＝２の時刻にＳ＿ｔａｒｇｅｔがＳ＿ｔａｒｇｅｔ３に変更（Ｓ＿ｔａｒｇｅｔ３＜Ｓ＿ｔａｒｇｅｔ）されると、少量（ｄｅｌｔａ４）または０（ｄｅｌｔａ３）のフレームデータがパケット化される。その一方、デコードによりＳｕｍが消費されるので、やはりＳｕｍが新しい目標値Ｓ＿ｔａｒｇｅｔ３の近傍に到達するようになる。このような仕組みを利用すると、ネットワーク１０３の伝送能力（あるいは端末１０２の電波受信状態）に応じて、動的に端末１０２内のバッファ占有量Ｓｕｍを増減させることが可能となり、以下に説明するような応用が可能となる。
【０１３６】
図７（Ａ）において、携帯電話７０１（図１の端末１０２と対応）を持ったユーザが、図中の矢印７０２ように、中継局Ｂ１の圏内から中継局Ｂ２の圏内へと移動する場合を考える。移動に伴い、携帯電話７０１からの呼を受け付ける業務が、中継局Ｂ１から中継局Ｂ２へと引き渡される。このとき、携帯電話７０１の受信電波強度は、おおむね図７（Ｂ）に示したグラフのように変化する。本モデルでは、説明を簡単にするために、電波強度が強から中（または中から強）に変わるところをネットワーク１０３の伝送能力に関する閾値Ａ、中から弱（または弱から中）に変わるところを閾値Ｂ、弱から圏外（または圏外から弱）に変わるところを閾値Ｃとした。
【０１３７】
図７（Ｂ）において、今、携帯電話７０１を持ったユーザが距離ｄ１だけ移動し、伝送能力が閾値Ａを下回ったとする。このとき携帯電話７０１は、図１１に示されるように、Ｓ＿ｄｅｌａｙをより大きい値（Ｓ＿ｔａｒｇｅｔ２）に変更して、その値をサーバ１０１に通知する。これは、その後も進むと予想される伝送能力低下に備えて、サーバ１０１による新たなパケット生成および送出を促進させ、それにより、できるだけ長時間（これをΔｔとする）ぶんのデータを携帯電話７０１内のバッファに蓄積しておくためである。伝送能力が閾値Ａを下回っても、閾値Ｂ以上である間は、まだパケットの転送ロスが発生することがないので、このような伝送速度の高速化が可能である。
【０１３８】
ユーザが移動して距離ｄ２に達すると、伝送能力が閾値Ｂを下回って、パケットの転送ロスが発生し始める。このとき、携帯電話７０１は、図１１に示されるように、Ｓ＿ｔａｒｇｅｔを小さい値（Ｓ＿ｔａｒｇｅｔ３）に変更して、その値をサーバ１０１に通知する。これは、その後もさらに進むと予想される伝送能力低下に備えて、できるだけサーバ１０１による新たなパケット生成および送出を抑制させるためである。パケット生成および送出を抑制するのは、次の理由による。
【０１３９】
たとえば、携帯電話７０１が通信方式としてＰＨＳのＰＩＡＦＳ方式を採用している場合、パケットの伝送ロスが発生すると、リンクレイヤであるＰＩＡＦＳ層のプロトコルに基づくデータ再送処理が行われる。再送処理中に、新たなパケット生成および送出が行われると、それが再送処理の邪魔をする結果となり、かえって好ましくないからである。
【０１４０】
ユーザが移動して距離ｄ３に達すると、伝送能力が閾値Ｃを下回って、一瞬、パケット転送が困難となる。しかし、ユーザがさらに移動して距離ｄ４に達すると、伝送能力が閾値Ｂを上回り、かつ呼を受け付ける業務の引き渡し（ハンドオーバー）も完了しているので、携帯電話７０１は、今度はＳ＿ｔａｒｇｅｔ３を元の値Ｓ＿ｔａｒｇｅｔに戻して、その値をサーバ１０１に通知し、それによって、データの蓄積量（すなわちバッファ占有量Ｓｕｍ）を増加させる。なお、ＰＨＳ等のハンドオーバー時間は、普通に人が歩く速さでもおおよそ２〜３秒程度で完了するため、上記のΔｔをおおよそ３〜４秒程度確保しておけば、ハンドオーバーが起こっても携帯電話７０１でのストリーミング再生を滞りなく継続することができる。
【０１４１】
ところで、図１１のように、ストリーム配信の途中でＳ＿ｔａｒｇｅｔの設定値がより小さな値に変更されると、図１４のアルゴリズムにおいてステップＳ５０２の判定文がなかなか真にならず、次のフレームのデータを送出できないケースが起こりうる。このようなケースがたびたび発生すると、折角パケットを端末１０２に届けても、もはやそのパケット内のフレームデータを再生するべき時刻（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ）を経過してしまっており、データが無駄になってしまうことがある。このような場合は、再生時刻が経過してしまったフレームデータをスキップした方が、無駄なデータをネットワーク１０３に流さないで済む分だけ効率的である。
【０１４２】
図１６は、図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの別の例を示すフローチャートである。図１６の関数ｍｋＰａｃｋｅｔには、サーバ１０１が送信速度を遅くする際に、再生時刻を過ぎたデータの送出をスキップするためのステップ（Ｓ６０１およびＳ６０２）が含まれている。すなわち、図１６のアルゴリズムは、図１４と比較して、ステップＳ６０１およびステップＳ６０２が追加されただけである。他のステップは、図１４と全く同じであり、同一の参照番号が付されている。ステップＳ６０１では、ＣＰＵ４１２は、今から送出しようとしているｉｎ番目のフレームデータが、０番目のフレームのデータでなく、かつ、端末１０２にて既にデコードされたとみなされるｏｕｔ番目のフレームデータより再生時刻が後かどうかを判定している。
【０１４３】
この判定結果が真ならば、ＣＰＵ４１２は、ｉｎ番目のフレームのデータが端末での再生時刻に間に合うと見なして、ステップＳ５０３にてそのデータをパケット化し、端末１０２に送出する。偽の場合は、ｉｎ番目のフレームデータを無かったものとみなし、ステップＳ６０２にてＬ＝０とする。これにより、ステップＳ５０２では必ず真と判定され、かつステップＳ５０３のパケット化において、不要なフレームデータのコピーを行わずに、送出フレームを次に進めることができる。なお、このようなフレームスキップがあった場合は、デコーダ５０９での再生が時間Ｔｆｒｍだけ飛ぶので、その旨を端末１０２に通知する情報が、図１５（Ａ），（Ｂ）のパケット中に記述されるものとする。例えば、ヘッダ内にそのような再生時刻情報を記述する領域を設ければよい。
【０１４４】
図１６に示したアルゴリズムは、ＭＰＥＧオーディオのように各フレームどうしの優先順位（重要度）に差が無い場合には、十分有効な手法である。しかし、ＭＰＥＧビデオにおいては、従来例の紹介において既に説明したように、Ｉフレームであればそれ単独で意味のある画像を再構成することができるが、ＰやＢのフレームでは、時間的に前後の参照フレームがなければ、意味のある画像を再構成することができない。この場合には、図１６のアルゴリズムにおいてフレームの間引きを行う際に、再生時刻に間に合うＩフレームを優先的に送出する一方、ＰやＢのフレームを全てスキップすることで、ネットワーク１０３の転送速度が遅い状況においても、端末１０２に対してより高品位の映像を提供することが可能となる。
【０１４５】
図１７は、図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの、さらに別の例を示すフローチャートである。図１７の関数ｍｋＰａｃｋｅｔには、サーバ１０１が送信速度を遅くする際に、優先度の低いデータと、優先度は高いが再生時刻を過ぎたデータとの送出をスキップするためのステップ（Ｓ５０５’，Ｓ６０１，Ｓ６０２，Ｓ７０１およびＳ７０２）が含まれている。すなわち、図１７のアルゴリズムは、図１４と比較して、ステップＳ６０１，Ｓ６０２，Ｓ７０１およびＳ７０２が追加され、かつステップＳ５０５がステップＳ５０５’に置き換えられている。ステップＳ５０５’は、ステップＳ５０５に対し、関数ＮｅｘＴｆｒｍに優先順位ｐｒｉの検出機能が加えられたものである。他のステップは、図１４，図１６と全く同じであり、同一の参照番号が付されている。
【０１４６】
従って、図１７のアルゴリズムは、図１６と比較すると、ステップＳ７０１，Ｓ７０２が追加され、かつステップＳ５０５がＳ５０５’に置き換わっている。
【０１４７】
図１７のアルゴリズムを実行するには、端末１０２が検出した受信状態を示す情報（受信状態情報）を、端末１０２からサーバ１０１に通知する機能が必要となる。このような機能を持ったサーバ・クライアント・システムの構成例を、図１８に示す。図１８において、端末１０２は、受信状態を検出する検出部８０１を備えている。端末１０２とサーバ１０１との間には、検出された受信状態情報を端末１０２からサーバ１０１に通知する通知部８０２が設けられる。サーバ１０１は、保持部８０３を備えており、通知された受信状態情報を保持する。
【０１４８】
再び図１７において、ｍｋＰａｃｋｅｔ関数が呼び出されると、ステップＳ５０１に先立って、ステップＳ７０１が実行される。ステップＳ７０１において、サーバ１０１（のＣＰＵ４１２）は、保持部８０３内の情報（端末１０２側の受信状態）を参照して、ネットワーク１０３の伝送能力が閾値Ｂを下回るか否かを判定する。この判定の結果、閾値Ｂを下回っていればｓｌｏｗｆｌａｇを真とし、そうでなければ偽とする。
【０１４９】
ステップＳ５０５’では、次のフレームの優先度が検出され、続くステップＳ７０２では、そのフレームのデータの優先度が高く、かつｓｌｏｗｆｌａｇが真であるか否かが判定される。この判定結果が肯定、すなわちネットワーク１０３の転送速度が遅いことを示すｓｌｏｗｆｌａｇが真であり、かつ優先度の高いフレームである場合、ステップＳ６０１に進んで、再生時刻が経過してしまったフレームか否かが判定される。一方、判定結果が否定である場合、ステップＳ６０２に進んで、Ｌ＝０とされる（つまり、たとえ再生時刻に間に合うようであっても、そのフレームはスキップされる）。後の処理は、図１４や図１６の処理と全く同様である。
【０１５０】
以上のように、本実施形態によれば、端末１０２が、自身のバッファ容量とネットワーク１０３の伝送能力とに応じた目標量を決定し、さらに、目標量を伝送能力で除して得られる値を超えない範囲内で、遅延時間を決定する。サーバ１０１は、こうして端末１０２が決定した目標量および遅延時間に基づいて送信速度を制御するので、端末１０２のバッファ容量が機種によって異なっていても、ネットワーク１０３の伝送能力が変動しても、バッファ量および伝送能力に応じた送信速度制御が行え、その結果、バッファのアンダーフローやオーバーフローによるストリーミング再生の破綻を回避することが可能となる。しかも、目標量とは独立に遅延時間が決定されるので、ストリーミング再生の破綻回避と、頭出し時の待ち時間短縮とを互いに両立させることができる。
【図面の簡単な説明】
【図１】本発明の一実施形態に係るストリーミング方法を実行するサーバ・クライアント・システムの構成例を示すブロック図である。
【図２】図１のサーバ１０１の構成を示すブロック図である。
【図３】図１の端末１０２の構成を示すブロック図である。
【図４】図１のシステムの全体動作を説明するためのシーケンス図である。
【図５】図１の端末１０２の動作を示すフローチャートである。
【図６】図３のＲＯＭ５０２の記憶内容を示す図である。
【図７】あるエリアにおける電界強度の分布（Ａ）と、端末の移動に伴う伝送能力の変化（Ｂ）とを示す模式図である。
【図８】図５のステップＳ１０７の詳細を示すフローチャートである。
【図９】図１のサーバ１０１が行う送信速度制御によって、端末１０２のバッファ占有量がどのように遷移するか（Ｓ＿ｔａｒｇｅｔに近づいていく様子）を示す図である。
【図１０】バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がより大きな値（Ｓ＿ｔａｒｇｅｔ２）に変更された場合に、図１のサーバ１０１が行う送信速度制御によって、端末１０２のバッファ占有量がどのように遷移するかを示す図である。
【図１１】バッファ占有量がＳ＿ｔａｒｇｅｔの近傍で遷移している状態で、Ｓ＿ｔａｒｇｅｔの値がより小さな値（Ｓ＿ｔａｒｇｅｔ３）に変更された場合に、図１のサーバ１０１が行う送信速度制御によって、端末１０２のバッファ占有量がどのように遷移するかを示す図である。
【図１２】図１のサーバ１０１が行う送信速度制御アルゴリズムの一例を示すフローチャートである。
【図１３】図９〜図１１のバッファ遷移を実現するためにサーバ１０１によって行われる送信速度制御アルゴリズムの別の例を示したフローチャートである。
【図１４】図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの一例を示すフローチャートである。
【図１５】図１のサーバ１０１が生成するパケットの構成例（Ａは１パケットに複数フレームを挿入する場合、Ｂは１パケットに１フレームを挿入する場合）を示す図である。
【図１６】図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの別の例を示すフローチャートである。
【図１７】図１３のステップＳ４０４中の関数ｍｋＰａｃｋｅｔの、さらに別の例を示すフローチャートである。
【図１８】本発明の一実施形態に係るストリーミング方法を実行するサーバ・クライアント・システムの別の構成例を示すブロック図である。
【図１９】従来のストリーミング方法を説明するための図である（Ａはビデオフレーム、Ｂはバッファ占有量の遷移、Ｃは従来端末の構成例）。
【図２０】従来のストリーミング方法を実行するサーバ・クライアント・システムの構成例を示すブロック図である。
【図２１】受信バッファを追加することによってバッファ占有量の遷移がどのように変化するかを説明するための図である（Ａが追加前、Ｂが追加後）。
【符号の説明】
１０１ サーバ
１０２ 端末
１０３ ネットワーク
４０２，５０７ 送受信モジュール
４０４ ＲＡＭ
４０５ 生成モジュール
４０６ パケット生成回路
４０７ 読み出しバッファ
４０８ パケット生成バッファ
４０９ 送信バッファ
４１０，５０６ ネットワークコントローラ
４１１ 蓄積デバイス
４１２，５０３ ＣＰＵ
４１３，５０２ ＲＯＭ
５０５ 受信バッファ
５０８ デコーダバッファ
５０９ デコーダ
５１０ 再生モジュール
５１１ 表示デバイス

Claims (15)

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

Images