ブラウザおよびシュミレ―トさせる方法

トップ :: G 物理学 :: G06 計算;計数

【発明の名称】	ブラウザおよびシュミレ―トさせる方法
【発明者】	【氏名】エフライム・フェイグ【氏名】ジーン・シュー＝チュン・チェン【氏名】イー＝ミン・カン【氏名】トン・シエ
【要約】	【課題】ＵＲＬのシーケンスを含むＵＲＬリストと呼ばれるデータ・タイプを受け入れるブラウザを提供する。【解決手段】このブラウザは、リストに従ってＵＲＬ要求を行なう。ブラウザは、ＵＲＬ要求に対する応答時間の統計を獲得し、それによりシーケンス中の次のＵＲＬを呼び出すタイミングを決め、それにより、リンクされたデータの到着が実際のストリーミングをほぼシュミレートするようになる。

【特許請求の範囲】
【請求項１】一連のＵＲＬと、前記ＵＲＬの内容のサイズと、その表示の予定持続時間に関するデータと、前記ＵＲＬの内容の一般的な性質を有するヘッダとを含む、ＵＲＬＳまたはＵＲＬシーケンスと呼ばれるデータ・タイプを受け入れるブラウザであって、ＵＲＬＳを含む様々なＵＲＬにＵＲＬ要求を出し、その要求のタイミングを、前記ＵＲＬＳの前記タイミング・データに従って決めることを特徴とするブラウザ。
【請求項２】ＵＲＬＳを含む様々なＵＲＬに要求を出す段階が、提供されたレシピに従いＵＲＬＳの持続時間データに応じて自動的にタイミングが決められることを特徴とする請求項１に記載のブラウザ。
【請求項３】ユーザが、ＵＲＬＳを含む様々なＵＲＬに対する要求を手動で出すことを特徴とする請求項１に記載のブラウザ。
【請求項４】請求項１のＵＲＬＳに関連するＵＲＬにおける連続する時間セグメントに区分されることを特徴とするビデオ・データ。
【請求項５】時間セグメントの持続時間がすべてほぼ等しいことを特徴とする請求項４に記載のビデオ・データ。
【請求項６】一連のＵＲＬを有するＵＲＬリストと呼ばれるデータ・タイプを受け入れるブラウザであって、リストに従ってＵＲＬ要求を行なう手段と、ＵＲＬ要求に対する応答時間の統計を獲得する手段と、シーケンス中の後続のＵＲＬを呼び出すタイミングを決定する手段とを含み、リンクされたデータの到着が、実際のストリーミングをほぼシュミレートすることを特徴とするブラウザ。
【請求項７】非ストリーミング・サーバにストリーミング・サーバをシュミレートさせる方法であって、ＵＲＬリストに従ってＵＲＬ要求を行う段階と、ＵＲＬ要求に対する応答時間の統計を獲得する段階と、それに従って、シーケンス中の後続のＵＲＬを呼び出すタイミングを決定する段階とを含み、それにより、リンクされたデータの到着が実際のストリーミングをほぼシュミレートすることを特徴とする方法。

【発明の詳細な説明】【０００１】
【発明の属する技術分野】本発明は、ブラウザに関し、より詳細には、一連のＵＲＬ要求を自動的に処理する機能を備えたブラウザに関する。この機能により、プロセスが非ストリーミング・サーバにストリーミング・サーバをシュミレートさせることが可能になる。
【０００２】
【従来の技術】ハイパーテキスト文書は、ハイパーリンクを介して他の文書にリンクされる。ハイパーリンクはしばしば、強調表示された１つのテキストとしてハイパーテキスト文書に現われる。テキストは、通常、ユーザがさらに詳しい情報を望むものを記述する単語または語句である。ユーザが、そのハイパーリンクを、通常はマウスを使ってクリックすることにより活動化すると、画面表示が変化し、通常は当該の強調表示された単語または語句に関するさらに詳しい情報を含むリンクされた文書が表示される。ハイパーリンクにより、文書間の相互参照がたどりやすくなる。ハイパーメディア文書は、マルチメディア機能を備えたハイパーテキスト文書である。画面上のアクティブなハイパーリンクの領域は、ホット・リンクと呼ばれる。
【０００３】最近では、ほとんどの人々が、インターネット上のワールド・ワイド・ウェブ（ウェブ）からホーム・ページのコンピュータ表示上のホット・リンクをマウスを使ってクリックすることによるハイパーテキストの利用に精通している。ウェブ上のデータは、ＵＲＬを介して見つけ出される。ＵＲＬは、「ユニフォーム・リソース・ロケータ（Uniform Resource Locator）」を表す。これは、インターネット上のオブジェクトを指定するための規格であり、アクセス方法とファイルの位置を指定する（参照：http://www/w3/org/pub/WWW/Addressing）。ウェブ上の文書は、ハイパーテキスト・マークアップ言語を表すＨＴＭＬと呼ばれる簡単な「マークアップ言語」で記述される。ウェブ上のデータのファイル形式は、ＭＩＭＥ形式として指定される。ＭＩＭＥは、「マルチパーパス・インターネット・メール・エクステンション」を表す。（参照：http://www.oac.uci.edu/indiv/ehood/MIME/MIME.html）。ウェブ上のファイル形式の例には、.au（おそらく最も一般的な音声形式）、.html（ＨＴＭＬファイル）、.jpg（ＪＰＥＧ符号化イメージ）、.mid（Ｍｉｄｉ音楽形式）、.mpg（ＭＰＥＧ符号化ビデオ）、および.ps（ポストスクリプト・ファイル）がある。ブラウザは、ウェブ上のＨＴＭＬ文書の閲覧および操作を便利にするコンピュータ・プログラムである。最も人気のある２つのブラウザは、Netscape社のNavigator（参照：http://www.netscape.com）とMicrosoft社のInternet Explorer（参照：http://www.microsoft.com/ie/default.esp）である。これらは、グラフィカル・ユーザ・インタフェースに、標準のポイント・アンド・クリック・ナビゲーション方法を提供し、ＨＴＭＬファイルをサポートする。
【０００４】ＨＴＭＬファイル内のホット・オブジェクトは、それぞれ固有のＵＲＬにリンクされている。一連のＵＲＬにリンクされたホット・オブジェクトがあることがしばしば望ましい。たとえば、あるプレゼンテーションが、それぞれＵＲＬによってリンクされた一連のＨＴＭＬファイルからなることがある。プレゼンタが、この一連のＨＴＭＬを、それぞれある所定の時間だけ継続して次々に表示させたいことがある。もう１つの例は、一連のビデオ・セグメントが様々なＵＲＬに配置され、そのような一連のビデオ・セグメントが、連結されると連続した１つのビデオを含むときに生じる。その場合、閲覧者が、一連のビデオ・セグメントを連続的に表示させ、サーバから流れてくるビデオ全体を表示するようにシュミレートすることが望ましい。
【０００５】したがって、多数のＵＲＬに対する要求を自動的に順に送り出し、そのような要求のタイミングが自動的にまたは閲覧者によって手動で決定される、ホット・オブジェクトをユーザに提供することが望ましい。
【０００６】ビデオは、娯楽のなかでも主流の媒体であり、また急速にコンピューティングの重要な部分になりつつある。ビデオは、きわめて大きな情報伝達能力を有し、ニュース・イベント、ライブ・インタビュー、科学実験、旅行記録、その他多くの複雑な状況を収集し伝達するためによく使用される。ビデオ・データは、通常きわめて大きい。一方、ビデオ・ファイルは、コンピュータ上の大きな記憶空間を占有する。たとえば、ＭＰＥＧ－１、Ｉｎｄｅｏ、ＱｕｉｃｋＴｉｍｅ－ＭＯＶ、Ｃｉｎｅｐａｋを含めてほとんどの圧縮ビデオ形式で、１分間のビデオを記憶するのに約１０ＭＢを必要とする。
【０００７】従来の非ストリーミング・サーバは、等時要件を満たさない。一般に、このサーバは、等時性を保証するための明示的な機構なしに転送待ち時間を最少にするように設計されており、ブラウザへの配布速度が不規則であり、その結果、クライアント・マシンでの再生品質が不安定になる。ビデオ・ファイルの不安定な再生を回避する通常の方法は、ビデオ再生を始める前にファイル全体をダウンロードすることである。この手法は、大きなほとんどのビデオにとって許容不可能な遅延をもたらす。たとえば、転送速度が、１．５Ｍｂ／秒もの速さの場合でも、初期のスタートアップ遅延は、１分のビデオ・クリップで６０秒である。チャネルの帯域幅が低すぎて特定のビデオのビット伝送速度をサポートできないときは、この手法またはその何らかの修正が不可避である。そのような１つの修正は、ビデオのビット伝送速度と共にダウンロード速度の統計を取り、妥当な再生の開始時間を計算して、それによって、ビデオ全体をグリッチなしに再生できるようにするものである。この方式により、ビデオを要求してから再生を開始するまでの待ち時間がある程度短縮される。チャネルの帯域幅が、実時間再生に必要な帯域幅より高いときは、非ストリーミング・サーバの能力が受信側再生装置の記憶容量を超えることがある。ストリーミング・ビデオは、主に、この状況に対処するものである。
【０００８】それとは対照的に、ストリーミング・サーバは、ビデオ・ストリームを等時に配布し、それにより、チャネル帯域幅が十分に高ければ、ビデオ再生のモーションと音声が滑らかになることが保証される。ストリーミング・サーバは、符号化ビデオのビット伝送速度と一致する制御されたビット伝送速度でビデオ・データを送る。しかし、ビデオ・データの転送を調整するために、クライアント・マシンのブラウザは、あらかじめデータ・バッファを割り振らなければならず、バッファのオーバーフローを回避するためにサーバと絶えず対話しなければならない。その上、ストリーミング・サーバは、ビデオ・データをシーケンス・モードで送り、したがって、ストリーミング・ビデオ・ファイルの１つの欠点は、受信再生システムがランダム・シークをサポートできないことである。ストリーミング・ビデオを見るユーザは、必ず、ファイルの最初から、またはせいぜいファイルのキャッシュされた部分から閲覧を始めなければならない。たとえば、ビデオの将来の箇所を探すときは、閲覧者は、サーバが所望のシーク位置よりも前のすべてのビデオ・データを流すのを待たなければならない。これは、長いビデオにアクセスするために多量のネットワーク帯域幅を浪費しすぎる。
【０００９】
【発明が解決しようとする課題】以上に鑑みて、本発明の一目的は、非ストリーミング・サーバにストリーミング・サーバをシュミレートさせることができるブラウザを提供することである。
【００１０】本発明のもう１つの目的は、非ストリーミング・サーバにストリーミング・サーバをシュミレートさせる方法を提供することである。
【００１１】本発明のもう１つの目的は、新しいデータ・タイプであるＵＲＬをサポートするように標準のＨＴＭＬブラウザを拡張することである。
【００１２】
【課題を解決するための手段】以上その他の目的は、次のようにして達成される。本発明においては、流れてくるデータが、順次セグメントに区分される。順次リストされたＵＲＬを含むＵＲＬリストが作成される。ＵＲＬリストのデータから一連のＵＲＬ要求を自動的に生成することができるブラウザが構築される。
【００１３】本発明によれば、ブラウザは、ＵＲＬＳを含む様々なＵＲＬに順にアクセスして、チャネルの帯域幅とＵＲＬ内のデータによって提供される様々なパラメータによって決まるタイミングに要求を出す。様々なＵＲＬがビデオ・シーケンスからの連続したセグメントを含み、要求のタイミングが適切なとき、ストリーミング・ビデオのシュミレートが達成される。
【００１４】ブラウザは、サーバからのデータの到着の統計を獲得する。次いで、後続のＵＲＬ要求を出すタイミングを決定する。
【００１５】たとえば、ビデオ・ストリームは、１分間のセグメントに区分される。符号化ビデオのデータ伝送速度は１００Ｋｂｐｓであり、サーバからブラウザへの帯域幅は１Ｍｂｐｓである。ブラウザは、再生されるビデオが次のデータ・セグメントを必要とするより２００ミリ秒前にＵＲＬ要求を出す。したがって、１００ミリ秒分のデータ（１０ｋｂ）だけをバッファすればよい。再生装置は、各ファイル・セグメントを再生した後で、後続のセグメントを引き続き再生するために再び呼び出せるようにプログラムされる。したがって、ブラウザは、入ってくるすべてのセグメント用に新しい再生装置を生成する必要はない。
【００１６】再生装置は、すべてのセグメントの開始に対するランダム・シークをサポートすることができる。また、任意のセグメントから開始するために再生装置を最初に開くことができるが、必要なヘッダ情報を含む最初のセグメントをまず獲得しなければならないこともある。
【００１７】
【発明の実施の形態】本発明は、新しいデータ・タイプであるＵＲＬＳ（ユニフォーム・リソース・ロケータ・シーケンス）をサポートするように標準のＨＴＭＬブラウザを拡張する。図１に、ＵＲＬＳデータ・タイプの構造を示す。この構造は、１からｎまでのインデックスｊを有するＵＲＬＳと添付側面情報の順序リストＵＲＬＳ（ｊ）と、ヘッダ・ファイルを含む最初のヘッダとを有する。ヘッダ・ファイルは、後続の様々なＵＲＬに含まれるデータのタイプに関する情報を含み、そのようなデータは、テキスト、画像、音声、ビデオ、その他のタイプでもよい。ヘッダはまた、後続のＵＲＬのデータを処理するためにどのようなプラグインまたはエクストラが必要か、ストリーミングをシュミレートする必要があるかどうかに関する情報を含む。ストリーミングをシュミレートするブラウザは、ストリーミング・モードであるといい、そうでない場合は、通常モードであると言われる。各ＵＲＬＳ（ｊ）は、ＵＲＬ、ＵＲＬ（ｊ）、持続時間パラメータＴ（ｊ）、および対応するデータのサイズを表わす値Ｂ（ｊ）を含む。通常、持続時間パラメータＴ（ｊ）は、ブラウザが、その期間Ｔ（ｊ）の間ＵＲＬ（ｊ）にＵＲＬの内容を表示することを意味する。図２に、ＵＲＬＳ（ｊ）の構造を示す。
【００１８】本発明は、たとえばパーソナル・コンピュータやワークステーションを含めて、どんなコンピュータ処理システムでも実施することができる。図３に示すように、本発明で利用できるコンピュータ処理システムは、メモリ１０１、少なくとも１つの中央演算処理装置（ＣＰＵ）１０３（１つを示す）、および少なくとも１つのユーザ入力装置１０７（キーボード、マウス、ジョイスティック、音声認識システム、手書き文字認識システムなど）を含む。さらに、コンピュータ処理システムは、（ＲＯＭ）などの不揮発性メモリ、またはメモリ１０１にロードされＣＰＵ１０３によって実行されるオペレーティング・システム、および１つまたは複数のアプリケーション・プログラムを記憶する固定ディスク・ドライブなどその他の不揮発性記憶装置１０８あるいはその両方を含む。オペレーティング・システムおよびアプリケーション・プログラムを実行する際に、ＣＰＵは、不揮発性記憶装置１０８またはメモリ１０１あるいはその両方に記憶されたデータを使用する。さらに、コンピュータ処理システムは、ＣＰＵ１０３と、ＣＲＴ表示装置やＬＣＤ表示装置などの表示装置１０５との間に結合されたグラフィックス・アダプタ１０４を含む。ＣＰＵ１０３によって実行されるアプリケーション・プログラムまたはオペレーティング・システムあるいはその両方は、たとえば枠（またはウィンドウ）を描く命令、ビット・マップ・イメージを表示させる命令、三次元モデルをレンダリングする命令、ビデオ・ファイルを表示する命令などの図形命令を生成する。そのような命令は、ＣＰＵ１０３によって実行されるアプリケーション・プログラム／オペレーティング・システムによって、あるいはＣＰＵ１０３によって実行されるアプリケーション・プログラム／オペレーティング・システムと一緒に動作するハードウェアによって処理され、適切な画素データが生成され、それに応じて表示装置１０５が更新される。
【００１９】さらに、コンピュータ処理システムは、ＣＰＵ１０３に結合され、ＣＰＵ１０３が、通信リンクたとえばインターネットを介して他のコンピュータ処理システムと通信できるようにする通信リンク１０９（ネットワーク・アダプタやモデム）を含む。ＣＰＵ１０３は、通信リンク１０９を介してオペレーティング・システムおよびアプリケーション・プログラムを実行する際に、オペレーティング・システムの一部、アプリケーション・プログラムの一部、またはＣＰＵ１０３によって使用されるデータの一部を受け取ることができる。
【００２０】ＣＰＵ１０３によって実行されるアプリケーション・プログラム／オペレーティング・システムは、後述する本発明の方法を実行できることに留意されたい。あるいは、後述の方法の一部またはすべてを、ＣＰＵ１０３によって実行されるアプリケーション・プログラム／オペレーティング・システムと共に動作するハードウェアで実施することができる。さらに、後述の方法は、分散処理システムで実施することもでき、その場合は、そのような方法の諸部分が、通信リンク１０９を介してリンクされた複数の処理システム間に分散される。
【００２１】図４に、本発明の好ましい実施形態のフローチャートを示す。ユーザが、ブラウザに表示された、ＵＲＬＳへのリンクを有するＨＴＭＬページのホット・オブジェクトをクリックすると、ブラウザは、「読取りヘッダ」を呼び出して、ＵＲＬＳのヘッダ部から必要な情報を取り出す。この情報は、「初期化」モジュールに渡され、同モジュールは、ヘッダ・ファイル内の情報に基づいて、所望のアプリケーションを実行するのに必要な適切な機能をブラウザに開始させる。たとえば、ＵＲＬＳ内のデータがビデオ・ストリームからのセグメントを含む場合、ブラウザは、適切なビデオ・デコーダと再生装置を立ち上げる。ヘッダ情報の一部分は、データがストリーミング・モード再生用のものか、それともマニュアル・モードとストリーミング・モードの選択がユーザによって行われるかを示す。たとえば、Lotus Freelanceのプレゼンテーションは、両方のモードで実行することができるが、ビデオ・プレゼンテーションの作成者は、ストリーミング・モードだけで実行することを望むことがある。このモジュールにおいて、ヘッダがストリーミング・モードを示す場合、再生モードは、自動的にストリーミング・モードに設定され、そうでない場合は、ブラウザは、コンピュータ画面に質問を出力して、ユーザが再生モードとして２つのモードのどちらを実行したいかを入力するようユーザにプロンプトを出す。ユーザは、通常通り、マウスによって活動化したカーソルで適切な選択肢をポイントし、マウスでクリックすることにより応答する。
【００２２】ブラウザがストリーミング・モードのときは、異なるＵＲＬＳの様々なデータ間で移行のタイミングが重要である。たとえば、ＵＲＬＳがビデオ・シーケンスからの連続するセグメントを含む場合がそうである。ストリーミングは、ＴＤ（ｊ＋１）＋Ａ（ｊ＋１）＜Ｔ（ｊ）の場合だけ続く。ここで、・ＴＤ（ｊ）は、ブラウザがＵＲＬ（ｊ）に要求を出してからＵＲＬ（ｊ）からの最初のデータ・パケットがブラウザに到着するまでの時間遅延である。・Ａ（ｊ）は、ＵＲＬ（ｊ）からのすべてのデータがパケットに到着するための接続時間である。すなわち、最初のデータ・パケットが到着してから最後のパケットが到着するまでの接続時間である。
【００２３】「パラメータ」モジュールでは、ブラウザは、ユーザが、ストリーミング・データの連続表示の最小持続時間を選択できるようにする。ユーザは、プログラム全体のストリーミングが不可能な場合に、少なくとも持続時間Ｔのセグメントが連続的に再生されるように、持続時間Ｔを選択するよう要求される。Ｔ（１）＋．．．＋Ｔ（Ａ１－１）＜ＴおよびＴ（１）＋．．．＋Ｔ（Ａ１）＞Ｔ、（Ａ１＋１）＋．．．＋Ｔ（Ａ２－１）＜ＴおよびＴ（Ａ１＋１）＋．．．＋Ｔ（Ａ２）＞Ｔとなるように、ＵＲＬは、セグメント（ＵＲＬ（１），．．．，ＵＲＬ（Ａ１）），（ＵＲＬ（Ａ１＋１），．．．，ＵＲＬ（Ａ２）），（ＵＲＬ（Ａ２＋１），．．．，ＵＲＬ（Ａ３））に区分されるＵＲＬＳを含む。最後のセグメントの表示が要件を満たすことは保証できない。ブラウザは、また、ＵＲＬＳ内のデータＢ（ｊ）を利用して、最大量のデータを有するセグメントを記憶するのに必要なバッファ・サイズＢＵＦＦを決定する。すなわち、ＢＵＦＦ＝最大Ｂ（ＡＫ＋１）＋Ｂ（ＡＫ＋２）＋．．．＋Ｂ（Ａ（Ｋ＋１））である。次に、それぞれサイズＢＵＦＦのＢＵＦＦ１とＢＵＦＦの２つのバッファを割り振る。
【００２４】次に、ブラウザは、第１のセグメントを取り込んでそれをＢＵＦＦに記憶する。それには、ＵＲＬ（１）、次にＵＲＬ（２）、以下同様にＵＲＬ（Ａ１）まで、順に要求を出す必要がある。ブラウザは、第１のセグメントのデータがすべて到着し次第、第２のセグメントを取り込んでそれをＢＵＦＦに記憶し始め、同時に、ＢＵＦＦに記憶された第１のセグメントからの復号された出力を表示し始める。「自動待機」モジュールは、システムのセグメント取込みの終了およびセグメント表示の終了を連続的に監視する。ストリーミングの制約が満たされる場合、すなわちＴＤ（ｊ＋１）＋Ａ（ｊ＋１）＜Ｔ（ｊ）の場合は、取込みが表示の前に行われ、そうでない場合は、それは必要ない。取込みと表示が両方とも行われるとき、取込むべきセグメントがまだ残っている場合は、ブラウザは、第３のセグメントの取込みを開始し、それをＢＵＦＦ１に記憶し、ＢＵＦＦ２に既に記憶されている第２のセグメントからの復号された出力を表示し始める。このプロセスは、ピンポン式のバッファ操作（一方に記憶し、他方から再生する）によって、取り込むべきセグメントがなくなるまで続行される。次に、最後のセグメントが表示される。
【００２５】ストリーミング基準を満たす場合は、ＵＲＬＳを含むすべてのＵＲＬの内容全体が、内容作成者によって規定された適切なタイミング順序で表示されることが分かる。たとえば、ＵＲＬの内容がビデオ・シーケンスの場合、ビデオは、ストリーミング・サーバとストリーム処理可能な再生装置を利用する際に、最初から最後まで連続的に表示される。再生装置は、各ビデオ・セグメントを再生した後、再度呼び出して後続のセグメントを引き続き再生できるようにプログラムされる。このように、ブラウザは、入ってくるすべてのセグメントに対して新しい再生装置を立ち上げなくてもよい。
【００２６】ブラウザが手動モードの場合、「パラメータ」モジュールは、それぞれのサイズが最大Ｂ（ｊ）に等しい２つのバッファＢＵＦＦ１とＢＵＦＦを割り振る。次に、ブラウザは、ＵＲＬ（１）のデータを取り込みそれをバッファＢＵＦＦに記憶する。ＵＲＬ（１）からのデータがすべて到着し次第、ブラウザは、ＵＲＬ（２）からデータを取り込んでそれをバッファＢＵＦＦに記憶し始め、同時にＵＲＬ（１）からのデータから復号された出力を表示し始める。「手動待機」モジュールは、ユーザからの信号についてシステムを連続的に監視してＵＲＬ（３）からデータを取り込み始め、ＵＲＬ（２）からのデータからの復号された出力を表示し始める。このような信号は、通常、カーソルがコンピュータ画面上のどこか適切な位置にあるときにマウスでクリックすることによって入力される。ＵＲＬ（２）の内容がすべて到着し終わっている場合に、そのような信号が検出されたとき、ブラウザは、実際にＵＲＬ（３）からデータを取り込んでそれをＢＵＦＦ１に入力し始め、同時にＵＲＬ（２）からのデータから復号された出力を表示し始める。そうでない場合は、ＵＲＬ（２）の内容がすべて到着するまで待機し、それから、ＵＲＬ（３）からデータを取り込んでそれをＢＵＦＦ１に入力し始め、同時にＵＲＬ（２）からのデータから復号された出力を表示し始める。このプロセスは、ピンポン式のバッファ操作により、取り込むＵＲＬがなくなるまで続行される。次に、最後のＵＲＬからの復号された出力が表示される。
【００２７】本発明は、ローカル・サイトにすべてのデータをあらかじめ記憶したり、サーバがストリーミング機能を備えたりする必要なしに、サーバからその圧縮データが送られたビデオを表示するのに適している。流れてくるビデオ・データは、順番のあるセグメントに区分される。ＵＲＬがそれぞれ１つのセグメントを含むＵＲＬＳが作成される。たとえば、６０分間のＭＰＥＧ符号化ビデオ・ストリームは、１分間のセグメントに区分される。符号化ビデオのデータ伝送速度は、１．５Ｍｂｐｓであり、したがって、１分間の各セグメントは、９０メガビットで符号化され、ビデオ全体は、５．４ギガビット（すなわち６７５メガバイト）のデータで符号化される。サーバからブラウザへの帯域幅は３Ｍｂｐｓである。ブラウザは、データを要求してからデータが到着し始めるまでの時間遅延が、２０秒未満であるかどうか判定する。チャネルを介して１分間のビデオ・セグメントを配布する時間は３０秒である。したがって、１分間のセグメントの要求を出してからそのセグメントのデータ全体が到着するまでの合計時間は５０秒未満であり、１つのセグメントの再生時間である１分よりも確かに短い。したがって、ストリーミング基準が満たされる。ブラウザは、入ってくるビデオ・データを一時的に記憶するために、それぞれ１２メガバイトの２つのメモリ・バッファを割り振り、それををピンポン式に利用する。
【００２８】本発明の一実施形態は、Netscapeなどの従来のブラウザのプラグ・インとして実施することができる。これは、ビデオのサイズ、持続時間、１秒当たりのフレーム数などを含めてビデオの詳細な情報を記述したＵＲＬリストと呼ばれるデータ・タイプを受け入れる。ランダムな位置でビデオにアクセスするためには、ビデオを一連の小さなビデオ・ファイルに区分する必要があり、これは、多くのビデオ編集ツールで行うことができる。したがって、ＵＲＬリストは、すべてのビデオ・セグメントの名前リストと、各セグメントのサイズおよび継続時間を含む。以下に、代表的なＵＲＬリストの形式を示す。
【００２９】
ビデオ原本名：ｔｅｓｔ．ｍｐｇファイル・サイズ：２０ＭＢ動画持続時間：１０５秒１秒当たりのフレーム数：３０．．．．．．
ビデオ・セグメント１ファイル名：ｔｅｓｔ１．ｍｐｇファイル・サイズ：１ＭＢ動画持続時間：５秒ビデオ・セグメント２ファイル名：ｔｅｓｔ２．ｍｐｇファイル・サイズ：１ＭＢ動画持続時間：５秒．．．．．．
【００３０】図５は、ビデオ・ブラウザのモジュール構造を表し、これは主に、制御モジュール、ＵＲＬリスト解決モジュール、統計モジュール、およびビデオ・デコーダ・モジュールの４つのモジュールを含む。ＵＲＬリスト解決モジュールは、ＵＲＬリスト・ファイルを読み取り、ビデオ情報を獲得するために使用され、統計モジュールは、ビデオ・セグメントの平均の到着時間を計算するために使用され、ビデオ・デコーダ・モジュールは、ビデオのレンダリングに使用される。
【００３１】制御モジュールは、ＵＲＬリストを獲得し、ウェブ・サーバからビデオをダウンロードする順序を制御する役割を持つ最も複雑な部分である。
【００３２】図６に、制御モジュールのフローチャートを示す。図に示したように、制御モジュールは、ＵＲＬリストを獲得した後、ＵＲＬリスト解決モジュールを呼び出して、ＵＲＬリストを分析し、各ビデオ・セグメントのサイズに従ってデータ・バッファを割り振り、通常これは、ビデオ・セグメントと同じサイズでもよい。次に、制御モジュールは、最初のビデオ・セグメントをダウンロードし始め、統計モジュールを呼び出して到着時間を計算する。最初のビデオ・セグメントが完全にダウンロードされると、制御モジュールは、ビデオ・デコーダ・モジュールを呼び出してビデオ・セグメントを再生し、ＵＲＬリストに従って次のビデオ・セグメントをダウンロードする準備をする。ユーザが、ランダムな位置でビデオを再生したい場合、制御モジュールは、ビデオ・シークを行い、相対的ビデオ・セグメントを獲得する。そうでない場合は、次のビデオ・セグメントを獲得する。
【００３３】あらゆるビデオ・セグメントの到着時間が予測できないので、制御モジュールは、ビデオ・デコーダの速度を制御する。１つのビデオ・セグメントを再生する時間が１つのビデオ・セグメントをダウンロードする時間よりも短い場合は、ビデオ・デコーダ・モジュールは、ビデオをゆっくり再生する。これにより、ビデオ再生中の不規則な休止が回避されることは明らかである。
【００３４】まとめとして、本発明の構成に関して以下の事項を開示する。
【００３５】（１）一連のＵＲＬと、前記ＵＲＬの内容のサイズと、その表示の予定持続時間に関するデータと、前記ＵＲＬの内容の一般的な性質を有するヘッダとを含む、ＵＲＬＳまたはＵＲＬシーケンスと呼ばれるデータ・タイプを受け入れるブラウザであって、ＵＲＬＳを含む様々なＵＲＬにＵＲＬ要求を出し、その要求のタイミングを、前記ＵＲＬＳの前記タイミング・データに従って決めることを特徴とするブラウザ。
（２）ＵＲＬＳを含む様々なＵＲＬに要求を出す段階が、提供されたレシピに従いＵＲＬＳの持続時間データに応じて自動的にタイミングが決められることを特徴とする上記（１）に記載のブラウザ。
（３）ユーザが、ＵＲＬＳを含む様々なＵＲＬに対する要求を手動で出すことを特徴とする上記（１）に記載のブラウザ。
（４）上記（１）のＵＲＬＳに関連するＵＲＬにおける連続する時間セグメントに区分されることを特徴とするビデオ・データ。
（５）時間セグメントの持続時間がすべてほぼ等しいことを特徴とする上記（４）に記載のビデオ・データ。
（６）一連のＵＲＬを有するＵＲＬリストと呼ばれるデータ・タイプを受け入れるブラウザであって、リストに従ってＵＲＬ要求を行なう手段と、ＵＲＬ要求に対する応答時間の統計を獲得する手段と、シーケンス中の後続のＵＲＬを呼び出すタイミングを決定する手段とを含み、リンクされたデータの到着が、実際のストリーミングをほぼシュミレートすることを特徴とするブラウザ。
（７）非ストリーミング・サーバにストリーミング・サーバをシュミレートさせる方法であって、ＵＲＬリストに従ってＵＲＬ要求を行う段階と、ＵＲＬ要求に対する応答時間の統計を獲得する段階と、それに従って、シーケンス中の後続のＵＲＬを呼び出すタイミングを決定する段階とを含み、それにより、リンクされたデータの到着が実際のストリーミングをほぼシュミレートすることを特徴とする方法。

【出願人】	【識別番号】３９０００９５３１【氏名又は名称】インターナショナル・ビジネス・マシーンズ・コーポレイション【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬＢＵＳＩＮＥＳＳＭＡＳＣＨＩＮＥＳＣＯＲＰＯＲＡＴＩＯＮ
【出願日】	平成１１年（１９９９）２月１０日
【代理人】	【弁理士】【氏名又は名称】坂口博（外１名）
【公開番号】	特開平１１－３２８０７３
【公開日】	平成１１年（１９９９）１１月３０日
【出願番号】	特願平１１－３２５６８