JP3571902B2 - 配送システム、クライアント、方法および媒体 - Google Patents
配送システム、クライアント、方法および媒体 Download PDFInfo
- Publication number
- JP3571902B2 JP3571902B2 JP35730297A JP35730297A JP3571902B2 JP 3571902 B2 JP3571902 B2 JP 3571902B2 JP 35730297 A JP35730297 A JP 35730297A JP 35730297 A JP35730297 A JP 35730297A JP 3571902 B2 JP3571902 B2 JP 3571902B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- requests
- server
- predicted
- video data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/12—Avoiding congestion; Recovering from congestion
- H04L47/127—Avoiding congestion; Recovering from congestion by using congestion prediction
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/18—End to end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/25—Flow control; Congestion control with rate being modified by the source upon detecting a change of network conditions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/28—Flow control; Congestion control in relation to timing considerations
- H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
- H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/60—Network streaming of media packets
- H04L65/70—Media network packetisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/80—Responding to QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Computer Security & Cryptography (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Information Transfer Between Computers (AREA)
Description
【発明の属する技術分野】
本発明は、例えばストリーム系データをネットワークに配送する配送システム、クライアントとその方法に関するものである。
【0002】
【従来の技術】
近年、インターネットやイントラネットなどのコンピュータネットワーク環境の普及および高性能化に伴い映像や音声などのストリーム系のマルチメディアデータをコンピュータ・ネットワークを介して複数のクライアントに配送サービスする映像配送システムが開発され実用に供されるようになってきている。
【0003】
従来、このような映像配送システムにおける映像データ配送方式として、図2に示す様な方式が提案されている。図2において、映像クライアント(201)は利用者が映像を視聴するために起動するプログラムである。映像クライアント(201)は利用者の要求に従って適当な映像サーバ(202)に接続する。
【0004】
この方式では、まず映像クライアント(201)がリクエスト(映像取得要求、 203)を映像サーバ(202)に送信する。映像サーバ(202)はリクエスト(203)に対するリプライとして1〜数フレーム分の映像データ(204)を返送する。映像クライアントは(201)は映像データ(204)をディスプレイ等に表示し、表示処理がおわると再びリクエスト(203)を映像サーバ(202)に送信する。このようにクライアントとサーバ間でリクエストとリプライを繰り返すことで映像配送を行う(以降、この方式のことを「リクエスト&リプライ方式」と呼ぶことにする)。
【0005】
リクエスト&リプライ方式の特徴は映像データ量やフレームレートが映像クライアントの表示速度やネットワークの状況に応じて自動的に調節されるという点である。
【0006】
映像クライアントのCPU負荷の増大やネットワークの状況が悪化するとリクエストの到達に時間がかかる。すると、リクエストが映像サーバに到達する間隔が長くなるので、時間あたりにネットワークに流れる映像データの量が減少することになる。その結果、ネットワークやクライアントの負荷が軽減される。逆に、クライアントやネットワークに余裕がある場合は、リクエストの間隔が短くなるのでより高フレームレートで映像データを送ることになる。
【0007】
さらにリクエストがなければリプライも行われないので、映像クライアントやネットワーク側のトラブルで映像データを受信できない状況にもかかわらず、映像サーバが映像データを送ってしまう心配もない。リクエスト&リプライ方式以外の方式では、映像サーバが一方的にクライアントに映像データを送り続ける方式(たれ流し方式)などが提案されている。しかし、リクエスト&リプライ方式はたれ流し方式等の他の方式に比べ、フレームレートやデータ量の制御が簡単かつネットワークやクライアントに余り負担をかけずにすむので、ネットワーク状況の変動が大きくかつ複数のサービスが共存するインターネット環境での利用に適している。
【0008】
【発明が解決しようとする課題】
しかしながらリクエスト&リプライ方式ではクライアントが1つのリクエストを送信してからサーバからのリプライが届くまでの待ち時間(以降この時間を「ネットワーク遅延時間」と呼ぶ)が無駄になる。図3aに示される様に、リクエスト2はリクエスト1のネットワーク遅延時間と表示時間が終了してから送信されるので、(ネットワーク遅延時間+表示時間)=T秒とするとフレームレートは 1/T fpsになってしまう。
【0009】
この無駄な時間の解消方法として、図3bに示す様にネットワーク遅延時間を見越して前もってリクエストを映像サーバに送っておくことで、見かけ上無駄時間を解消することが考えられる。(この方式を「ずらし送り方式」と呼ぶ。)図3bにおいてずらし送り方式では、リクエスト1の表示が終了した時にちょうどリクエスト2のリプライが到着する様にリクエストを送信しておく。このようにすることで、フレームレートを 1/(表示時間) fpsに改善することが可能になる。
【0010】
しかしながら、実際のネットワーク環境では、ネットワーク遅延時間は回線状況やデータ量などにより激しく変動する。場合によってはリプライがクライアントに届く順番が逆転する可能性もある。このような環境でずらし送り方式を実現するためには、前のリクエストの終了時間を予測して次のリクエストの送信のタイミングを決定しなければならない。しかし、不意のネットワーク遅延時間の変動を予測することは非常に困難である。
【0011】
そこで本発明は配送効果を従来よりも向上させた配送システム、その方法および媒体を提供することを目的とする。
【0012】
【課題を解決するための手段】
本発明は上記の課題を鑑みて提案されたものであり、その一形態は、クライアントにおいてサーバに対して映像データを取得するためのリクエストを発生する配送システムであって、ネットワークの遅延時間Nを予測する予測手段と、データ配送の最初において、前記サーバから映像データを取得するために、前記サーバの送信フレームレートF×前記予測手段によって予測された遅延時間Nで示される予測先送り数のリクエストを前記クライアント側において発生する第1のリクエスト手段と、前記第1のリクエスト手段によるリクエストが配送された後、前記サーバから映像データのリプライに応じて、前記サーバからの映像データを取得するためにリクエストを前記クライアント側において発生する第2のリクエスト手段と、前記第1,第2のリクエスト手段によって発生したリクエストのうち、映像データのリプライがない未処理リクエストの数を前記クライアント側において判別する判別手段と、前記判別手段によって判別された未処理リクエスト数が、第1の所定値(前記所定値は前記予測先送り数以上の整数値)より多い場合、前記クライアント側における前記第2のリクエスト手段によるリクエストの発生を行わないように制御し、前記判別手段によって判別された未処理リクエスト数が、第2の所定値(前記所定値は前記予測先送り数以下の整数値)より少ない場合、前記予測先送り数−未処理リクエスト数で求められるリクエスト数を前記第2のリクエスト手段によってリクエストを発生させ、前記判別手段によって判別された未処理リクエスト数が、前記第1の所定値より少なく、かつ前記第2の所定値より多い場合、1つのリクエストを前記第2のリクエスト手段によって発生させる制御手段と、
を有することを特徴とする配送システム。
【0013】
【発明の実施の形態】
ここでは、第1の実施例として本発明の一実施例の映像配送システムについて説明する。この映像配送システムは、ビデオ映像を送信する映像サーバと、利用者が映像を鑑賞するための映像クライアントで構成されている。各映像サーバと映像クライアントは適当なコンピュータ上で動作するプログラムである。1つの映像サーバで複数の映像クライアントに映像データを送信することができる。この映像配送システムは、リクエスト&リプライ方式を拡張することにより、映像データの制御をおこなっている。本実施例ではリクエストのことをAcknowledgeメッセージと呼ぶ(以降、AckないしAckメッセージと略す)。Ackメッセージの内容は映像クライアントと映像サーバ間のコネクションを識別するためのセッションIDのみである。セッションIDには0以上の整数として表現される。セッションIDは映像サーバと映像クライアント間のコネクションが形成された時にサーバによって割り当てられ、クライアントに通知される。また、本実施例でのリプライはJPEG形式で圧縮された1フレーム分の映像データである。映像サーバがAckメッセージを受信するとJPEG映像データを送り元の映像クライアントに送信される。もちろん、リプライの内容がJPEG形式以外のMPEG等の圧縮形式や、1フレームではなく複数フレーム分の映像データであっても本発明の適用に差し支えはない。また、映像データ以外の音声データや文字データを扱う場合にも適用可能である。
【0014】
本映像配送システムにおける映像データの制御方式では、ずらし送り方式の様に1つずつリクエストをリプライに先行させて送るのではなく、最初に一定数のリクエストを映像サーバに送信してしまう。この方式を先送り方式と呼ぶ。
【0015】
この方式は、サーバの送信フレームレートの最大値をFsフレーム/秒(fps)としたとき、リクエストを複数同時に送信しても1/Fs秒ごとに1つずつしか処理できないことを利用している。リクエストを同時に送信しても、1/Fs秒ずつずらし送りしたのと同じことになる。
【0016】
本実施例では、最初に送信されるべきリクエストの数(リクエストの先送り数)を以下の様にして制御する。まず、ネットワーク遅延時間の平均値の予測を行う。この値を N 秒とする。この場合には、1つのリクエストのネットワーク遅延時間N の間に、最大フレームレート Fs fpsの映像サーバは、N×Fs個のリプライを映像クライアントに送信することができる。したがって、N×Fs個のリクエストを先送りしておけばよい。実際には、フレームレート Fs も映像サーバの環境に依存するので予測値 F を決め、N×Fをリクエストの「予測先送り数」として使用する。
【0017】
実際には、ネットワークの遅延時間が予想値Nからはずれていたりネットワークやクライアントの動作環境などの影響によりネットワーク遅延時間が変動することがある。本実施例では、ネットワークの遅延時間の変動に対処するために以下の制御を行う。まず、ある時点(たとえばリプライを一定個受け取ったとき)までに映像クライアントから送信されたリクエストの個数と、その時点で映像クライアントが受信したリプライの個数を調べ、(リクエスト数−リプライ数)の値を計算する。この値を「未処理リクエスト数」と呼ぶ。ネットワーク遅延時間が予測値Nと一致しているときは、リプライがくるごとにリクエストが1つ送信されるので「未処理リクエスト」は「予測先送り数」とほぼ等しくなる。
【0018】
ネットワーク状況が悪化し伝送速度等の性能が低下すると、未処理リクエスト数が予測先送り数より多くなる。そこで、
未処理リクエスト数 > 予測先送り数*a
(aは1以上の整数)
となったとき、過剰分のリクエスト(= 未処理リクエスト数 − 予測先送り数)が映像サーバによって消費されるまで、映像クライアントはリプライを受け取ってもリクエストの送信を行わない様にする。また、この時点でネットワーク遅延時間を以下の式で計算し、
計測ネットワーク遅延時間 = 未処理リクエスト数/フレームレート
予想ネットワーク遅延時間と以下の関係が成り立つ時は、
計測ネットワーク遅延時間 > a*予想ネットワーク遅延時間
フレームレートや予想遅延時間を修正する(本実施例ではaの値を2として制御する。)。
【0019】
一方、ネットワークの状況が改善され性能が上昇した場合は未処理リクエスト数が予測先送り数より少なくなる。
【0020】
未処理リクエスト数 < 予測先送り数/b
(bは1以上の整数)
となった場合は、不足分のリクエスト(= 予測先送り数 − 未処理リクエスト数)個をまとめて映像サーバに送信する。また、この時点で、
計測ネットワーク遅延時間 < 予想ネットワーク遅延時間/bであれば
フレームレートや予想遅延時間を修正する(本実施例ではbの値を2として制御する。)。
【0021】
具体的にはフレームレートを上げる又は予熱遅延時間を短くする。では、次に図1を用いて本実施例の構成要素について説明する。図において(101)は映像クライアントである。映像クライアントは、実際にはPC等のコンピュータの主メモリ上におかれCPUによって実行されるプログラムである。映像クライアントはコンピュータネットワーク(102)を介して映像サーバ(103)と通信をおこなう。
【0022】
映像クライアント(101)の内部モジュールはAck処理モジュール群(104)とその他のモジュール群(105)に分類できる。Ack処理モジュール群(104)は、映像サーバ(103)にAckメッセージを送って映像データを取得する機能を提供する。その他のモジュール群(105)には、ユーザインタフェースや動画表示などをおこなうソフトウェアモジュールが含まれており、表示する映像データを取得するためにAck処理モジュール群(104)を利用する。
【0023】
Ack処理モジュール(104)には以下のソフトウェア・モジュールが属している。・Ack処理制御部(106)
映像サーバ(103)へのAckメッセージ送信を制御するモジュールである。また、他のモジュール群(105)がAck処理モジュール群(104)の機能を利用するためのインタフェースを提供する。他のモジュール群(105)が映像を取得するためには、このAck処理制御部(106)に映像取得指示を発行すればよい。
(以下、モジュールやサブ・モジュール間のコミュニケーションは、”指示”をやり取りするものとして説明する。”指示”の具体的な実現形態としてはオブジェクト志向言語の”メッセージ”や通常のプログラム言語の手続き呼び出しなどが可能である。)
【0024】
・Ack処理関連パラメータ設定部(107)
Ackの送信制御に必要なフレームレートとネットワーク遅延時間の予測値を管理するモジュールである。図4に示す様なパネル(401)を表示する機能をもち、ユーザはこのパネルを利用してに適当なフレームレートとネットワーク遅延時間の予測値を設定するための入力フィールド(402、 403)が提供される。また、その時点での推奨値(404、 405)が表示される。(推奨値の計算方法については後述する。)
【0025】
・Ack処理状況監視部(108)
映像サーバに送信されたAckメッセージの個数と、映像サーバから得られた映像データの個数を監視するモジュールである。Ackメッセージの個数から映像データの個数 を引けば、未処理のAckメッセージの個数が計算できる。また、受信した映像データの個数と経過時間から実測フレームレートを計算するためにも使用される。
【0026】
・Ack送信部(109)
Ackメッセージを映像サーバに送信するモジュールである。socket等のプロセス間通信の機構を用いて実現される。
【0027】
・映像データ受信部(110)
映像サーバから送られてきた映像データを受信するモジュールである。Ack送信部(109)と同じく、プロセス間通信の機構を用いて実現される。また、他のモジュール群(105)がAck処理モジュール群(104)の機能を利用するためのインタフェースを提供する。映像データ受信部(110)を呼び出すことで最新の映像データを取得することができる。
【0028】
では、図5とフローチャート図6を用いて本実施例の処理の流れを説明する。映像クライアント(501)が利用者によって起動され、映像サーバ(503)との通信が可能になると、Ack処理制御モジュール(506)はAck処理関連パラメータ設定部(508)を呼び出し、あらかじめ設定されているフレームレートとネットワーク遅延時間の予測値を取り出す(S6a01)。かかる設定はデフォルトとして設定されているフレームレートネットワーク遅延時間であってもよいし、又映像サーバーの種類又は映像サーバに至る通信路の種類に従って決められた値であってもよい。次にAck処理制御モジュール(506)は取り出したパラメータの値から予測先送り数=予測フレームレート×予測ネットワーク遅延時間 を計算する。Ack処理制御モジュール(506)はAck送信部(509)に予測先送り数を通知して予測先送り数のAckメッセージを映像サーバ(503)に送信させる(S6a03)。
【0029】
以上の様にしてAckの先送りが行われると、以降は以下の手順でAck送信制御処理が行われる。まず、他のモジュール(505)から映像取得指示を受け取ると(S6b01)、Ack処理制御部(506)はAck処理状況監視部(508)から、映像サーバに送信されたAckメッセージの総数と映像サーバから得られた映像データの総数を取り出して未処理Ackメッセージ数を計算する(S6b02)。
【0030】
ここで、Ack送信部(509)がAckメッセージを送信すると、送信した個数をAck送信通知(515)に付加してAck処理状況監視部(508)に通知する。また、映像データ受信部(510)が映像データを受信したときは、映像受信通知(516)をAck処理状況監視部(508)に通知する。Ack処理状況監視部(508)は上記の通知(515、 516)によって送信されたAckメッセージの総数と得られた映像データの総数を監視する。
【0031】
未処理Ackメッセージ数が予測先送り数/2以下の場合は(S6b03)、Ack処理制御部(506)はAck送信部(509)を使用して(予測先送り数 − 未処理Ackメッセージ数)個分のAckメッセージを映像サーバ(503)に送信する(S6b04)。
【0032】
さらに、
実測フレームレート = 受信映像データ総数/受信開始からの経過時間
計測ネットワーク遅延時間 = 未処理Ackメッセージ数/実測フレームレート
も従って計測ネットワーク遅延時間を計算し、その値が予測ネットワーク遅延時間の半分以下ならば(S6b05)、Ack処理状況監視部(508)に指示をおくって図4bの警告パネル(406)を表示させ、ユーザにフレームレートとネットワーク遅延時間の予測値の変更を示唆する(S6b06)。このとき、警告パネルには、上記の過程で計算した 実測フレームレートと実測ネットワーク遅延時間を推奨値(407、 408)として表示させる。また、未処理Ackメッセージ数が予測先送り数×2以上であった場合は(S6b07)、Ackメッセージの送信はおこなわない。かわりに、実測フレームレートと計測ネットワーク遅延時間を計算し、計測ネットワーク遅延時間が予測ネットワーク遅延時間の2倍以上ならば(S6b08)、Ack処理状況監視部(508)に指示をおくって警告パネル(406)を表示させ、ユーザにフレームレートとネットワーク遅延時間の変更を示唆する(S6b09)。
【0033】
未処理Ackメッセージ数が、予測先送り数/2より大きくかつ予測先送り数×2より小さい場合即ちネットワークの遅延が所定範囲内の場合は、単に1個のAckメッセージを送信させる(S6b10)。
【0034】
以上説明した構成および処理により、ネットワーク状況の変動に適応可能かつネットワーク遅延時間を無駄にすることなく動画像を処理することが可能になる。また、本実施例ではパラメータの設定をユーザに行わせることによりより複雑な事態にも対応することが可能となっている。
【0050】
以上述べた様に、本実施例では
・リクエストの送信手段と、
・ネットワーク遅延時間およびフレームレートの予測値の獲得手段と、
・サーバによって未だ処理されていない未処理リクエスト数の獲得手段
・上記ネットワーク遅延時間およびフレームレートの予測値と未処理リクエスト数に基づいてリクエストの送信を制御するリクエスト送信制御手段
を提供することにより、
不意のネットワーク遅延時間の変動に対応可能でかつ、ネットワーク遅延時間の無駄を解消することが可能な動画像配送システムを実現するものである。
【0051】
なお、本発明は、複数の機器から構成されるシステムに適用しても、一つの機器からなる装置に適用してもよい。
【0052】
特に本発明はクライアントのみに実施してもよい。例えばサーバー側の機能拡張が必要ない場合にはクライアント側の制御及びそのための方法を格納した媒体は本発明を実施したものに相当する。
【0053】
また、本実施形態で説明したカメラサーバ装置及びクライアント装置は、多少のハードウェアの違いはあっても、パーソナルコンピュータやワークステーションで実現できる。従って、本発明は、実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ(またはCPUやMPU)が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【0054】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【0055】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピディスク,ハードディスク,光ディスク,光磁気ディスク,CD−ROM,CD−R,磁気テープ,不揮発性のメモリカード,ROMなどを用いることができる。
【0056】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているOS(オペレーティングシステム)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0057】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【0058】
本実施例においては動画像データを用いて説明したが本発明はオーディオデータ等のストリーム系のデータであれば同様に実施することができる。
【0059】
【発明の効果】
以上の様に本発明によれば、従来の様な単に複数のリクエストをサーバに要求するデータ配送システムに比べて、ネットワークの状況や、クライアントのネットワーク環境に柔軟に適応したリクエストの先送りシステムを提供することが可能になる。
【図面の簡単な説明】
【図1】本発明の第1の実施例である映像配送システムの構成図、
【図2】映像配送システムにおけるリクエスト&リプライ方式の概念図、
【図3】リクエスト&リプライ方式の特性を表す図、
【図4】映像配送システムのパラメータ設定用ユーザインタフェースを示す図、
【図5】映像配送システムの動作の流れを説明するための図、
【図6】図5で示した処理のフローチャートである。
Claims (3)
- クライアントにおいてサーバに対して映像データを取得するためのリクエストを発生する配送システムであって、
ネットワークの遅延時間Nを予測する予測手段と、
データ配送の最初において、前記サーバから映像データを取得するために、前記サーバの送信フレームレートF×前記予測手段によって予測された遅延時間Nで示される予測先送り数のリクエストを前記クライアント側において発生する第1のリクエスト手段と、
前記第1のリクエスト手段によるリクエストが配送された後、前記サーバから映像データのリプライに応じて、前記サーバからの映像データを取得するためにリクエストを前記クライアント側において発生する第2のリクエスト手段と、
前記第1,第2のリクエスト手段によって発生したリクエストのうち、映像データのリプライがない未処理リクエストの数を前記クライアント側において判別する判別手段と、
前記判別手段によって判別された未処理リクエスト数が、第1の所定値(前記所定値は前記予測先送り数以上の整数値)より多い場合、前記クライアント側における前記第2のリクエスト手段によるリクエストの発生を行わないように制御し、
前記判別手段によって判別された未処理リクエスト数が、第2の所定値(前記所定値は前記予測先送り数以下の整数値)より少ない場合、前記予測先送り数−未処理リクエスト数で求められるリクエスト数を前記第2のリクエスト手段によってリクエストを発生させ、
前記判別手段によって判別された未処理リクエスト数が、前記第1の所定値より少なく、かつ前記第2の所定値より多い場合、1つのリクエストを前記第2のリクエスト手段によって発生させる制御手段と、
を有することを特徴とする配送システム。 - クライアントにおいてサーバに対して映像データを取得するためのリクエストを発生する配送方法であって、
ネットワークの遅延時間Nを予測する予測ステップと、
データ配送の最初において、前記サーバから映像データを取得するために、前記サーバの送信フレームレートF×前記予測された遅延時間Nで示される予測先送り数のリクエストを前記クライアント側において発生する第1のリクエストステップと、
前記第1のリクエストステップにおいてリクエストが配送された後、前記サーバからの映像データのリプライに応じて、前記サーバからの映像データを取得するためにリクエストを前記クライアント側において発生する第2のリクエストステップと、
前記第1,第2のリクエストステップにおいて発生したリクエストのうち、映像データのリプライがない未処理リクエストの数を前記クライアント側において判別する判別ステップと、
前記判別ステップにおいて判別された未処理リクエスト数が、第1の所定値(前記所定値は前記予測先送り数以上の整数値)より多い場合、前記クライアント側における前記第2のリクエストステップにおけるリクエストの発生を行わないように制御し、
前記判別ステップにおいて判別された未処理リクエスト数が、第2の所定値(前記所定値は前記予測先送り数以下の整数値)より少ない場合、前記予測先送り数−未処理リクエスト数で求められるリクエスト数を前記第2のリクエストおいてリクエストを発生させ、
前記判別ステップ判別された未処理リクエスト数が、前記第1の所定値より少なく、かつ前記第2の所定値より多い場合、1つのリクエストを前記第2のリクエストステップにおいて発生させる制御手段と、
を有することを特徴とする配送方法。 - 請求項2に記載の配送方法を実現するプログラムをコンピュータにより実行可能に格納した記憶媒体。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP35730297A JP3571902B2 (ja) | 1997-12-25 | 1997-12-25 | 配送システム、クライアント、方法および媒体 |
US09/218,865 US6377989B1 (en) | 1997-12-25 | 1998-12-22 | Distributing system, client, method and medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP35730297A JP3571902B2 (ja) | 1997-12-25 | 1997-12-25 | 配送システム、クライアント、方法および媒体 |
Publications (2)
Publication Number | Publication Date |
---|---|
JPH11191883A JPH11191883A (ja) | 1999-07-13 |
JP3571902B2 true JP3571902B2 (ja) | 2004-09-29 |
Family
ID=18453432
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP35730297A Expired - Fee Related JP3571902B2 (ja) | 1997-12-25 | 1997-12-25 | 配送システム、クライアント、方法および媒体 |
Country Status (2)
Country | Link |
---|---|
US (1) | US6377989B1 (ja) |
JP (1) | JP3571902B2 (ja) |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6848004B1 (en) * | 1999-11-23 | 2005-01-25 | International Business Machines Corporation | System and method for adaptive delivery of rich media content to a user in a network based on real time bandwidth measurement & prediction according to available user bandwidth |
JP2002354329A (ja) * | 2001-05-30 | 2002-12-06 | Minolta Co Ltd | 撮影装置および撮影システム |
KR20030010938A (ko) * | 2001-07-27 | 2003-02-06 | 나이스굿엔터테인먼트 주식회사 | 인터랙티브 멀티미디어 서비스 제어 방법 |
US7130472B2 (en) * | 2002-01-21 | 2006-10-31 | Canon Kabushiki Kaisha | Image distribution apparatus, communication terminal apparatus, and control method thereof |
EP2469716B1 (en) * | 2002-06-26 | 2013-12-04 | Yahoo! Inc. | System and method for communicating images between intercommunicating users |
US20100274893A1 (en) * | 2009-04-27 | 2010-10-28 | Sonus Networks, Inc. | Methods and apparatus for detecting and limiting focused server overload in a network |
US8699343B2 (en) * | 2009-04-27 | 2014-04-15 | Sonus Networks, Inc. | Adaptive rate control based on overload signals |
JP6107228B2 (ja) * | 2012-05-30 | 2017-04-05 | 株式会社リコー | 情報処理装置、会議システム及びプログラム |
CN105075276B (zh) * | 2013-01-11 | 2019-04-16 | 瑞典爱立信有限公司 | 在广播通信网络中操作客户端设备和服务器设备的技术 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3434074B2 (ja) * | 1994-06-23 | 2003-08-04 | 富士通株式会社 | マルチメディア通信装置 |
US5636211A (en) * | 1995-08-15 | 1997-06-03 | Motorola, Inc. | Universal multimedia access device |
JPH10173674A (ja) * | 1996-12-13 | 1998-06-26 | Hitachi Ltd | ディジタルデータ伝送システム |
JP3615905B2 (ja) * | 1997-05-12 | 2005-02-02 | 株式会社東京放送 | デジタル映像分配装置 |
US6072809A (en) * | 1997-08-14 | 2000-06-06 | Lucent Technologies, Inc. | Statistical method for dynamically controlling the playback delay of network multimedia streams |
US5941951A (en) * | 1997-10-31 | 1999-08-24 | International Business Machines Corporation | Methods for real-time deterministic delivery of multimedia data in a client/server system |
-
1997
- 1997-12-25 JP JP35730297A patent/JP3571902B2/ja not_active Expired - Fee Related
-
1998
- 1998-12-22 US US09/218,865 patent/US6377989B1/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JPH11191883A (ja) | 1999-07-13 |
US6377989B1 (en) | 2002-04-23 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9608921B2 (en) | Dynamic bit rate scaling | |
US9112938B2 (en) | Adaptive playback with look-ahead | |
US7983300B2 (en) | Method and apparatus for measuring bandwidth | |
US7548948B2 (en) | Client-side caching of streaming media content | |
EP1313285A2 (en) | Data communication apparatus and data communication method | |
JP2006050560A (ja) | ネットワーク条件に応じてネットワーク通信を最適化するためのシステムおよび方法 | |
JP3571902B2 (ja) | 配送システム、クライアント、方法および媒体 | |
JP5269918B2 (ja) | 配信ネットワークへのマルチメディアコンテンツフローの生成およびトランスポートのための方法および装置 | |
KR100982630B1 (ko) | 콘텐츠의 스트림 비트율을 조정하기 위한 디바이스 및프로세스 그리고 관련 제품 | |
JP4430596B2 (ja) | 画像データ送受信システムの受信側装置及びそのプログラムを記憶した記憶媒体 | |
JP3967443B2 (ja) | 画像データ送受信システムおよびその送信側装置およびその受信側装置並びにそのプログラムを記憶した記憶媒体 | |
EP1067753A2 (en) | Electronic mail terminal device and method of controlling the same | |
US8780708B2 (en) | Transmission control system | |
US8467313B1 (en) | PHY bandwidth estimation from backpressure patterns | |
JP2013012833A (ja) | 送信装置及び送信装置の制御方法 | |
JP2004080566A (ja) | コンテンツ配信方法およびこれを用いるコンテンツ配信システム | |
US20060280173A1 (en) | Method and system for uneven distribution of data | |
KR20090101348A (ko) | 비실시간 미디어 배포 시스템에서의 비실시간 미디어 배포 방법, 비실시간 미디어 배포 시스템, 비실시간 미디어 서버 및 비실시간 미디어 클라이언트 | |
JP2004096746A (ja) | ネットワーク提起情報伝達 | |
JP2002135307A (ja) | ストリーム状態通知方法および装置、ならびにプログラム記録媒体 | |
CN115460427A (zh) | 直播调度方法、装置、计算设备和存储介质 | |
CN116684652A (zh) | 音视频拉取方法、装置、存储介质及计算机设备 | |
JP2003204533A (ja) | 映像データ配信システムおよび映像データ配信サーバ装置、映像データ監視装置、ネットワーク中継装置ならびに映像データ配信方法 | |
JP2006135793A (ja) | データ配信装置及びその制御方法、プログラム | |
JP2005094187A (ja) | リモートモニタリングシステムのデータ送受信方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040106 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040308 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040615 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040625 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20070702 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080702 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090702 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090702 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100702 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100702 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110702 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |