JP2006033026A - マルチメディア情報の受信方法及びこれを実現するプログラム、マルチメディア情報の受信装置 - Google Patents

Abstract

【課題】ユーザーからの再生指示に即応したストリーミング再生を実現する。
【解決手段】データ受信再生装置２０３は、映像及び／或いは音声データへのリンク情報があれば、当該データに対してＲＴＳＰのセットアップを行う（Ｓ１２）。ＲＴＳＰのセットアップが完了するまでに取得した情報で、再生に必要なセッション情報はここで記憶しておく（Ｓ１３）。ユーザーが入力デバイスを用いて映像／音声データの再生を指示した場合、ＰＬＡＹメソッドを送信し、再生開始を要求する（Ｓ１６）。
【選択図】図１

Description

本発明は、インターネット或いはホームネットワークによるＩＰ網を利用したビデオ・オン・デマンドサービス等におけるマルチメディア情報の受信方法及びマルチメディア情報の受信装置に関する。

ブロードバンドインターネットやホームネットワークの普及により、映像や音声データを、他のコンピュータやサーバからダウンロード或いはストリーミング再生する利用方法が増えている。ダウンロード方式では、サーバから送信された映像や音声データはクライアント側で一旦蓄積されてから再生される。このため、データの転送が終了するまではデータの再生を行うことができず、長時間再生には向かない。一方、ストリーム方式では、サーバからクライアントへデータが伝送されている間にも、クライアント側で受信したデータの再生が行われる。ストリーム方式では、信頼性よりもリアルタイム性が要求されることから、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）で勧告されているＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）といったプロトコルが使用される。

以下、ストリーム方式のネットワーク構成と利用方法について説明する。図２に示すビデオ・オン・デマンドシステムは、映像や音声データを伝送するストリーミングサーバ２０１と、ハイパーテキストや画像などを伝送するＷｅｂサーバ２０２と、それらのデータを受信するデータ受信再生装置２０３からなり、それらは互いにＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワークを介して、相互に通信することができる。データ受信再生装置２０３は、ＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルをＷｅｂサーバ２０２から受信して、それを表示する。ユーザーは、その中に含まれるリンクを選択（一般的にはマウスをクリック）することで、別のＨＴＭＬファイルの閲覧や、映像／音声データの視聴を行うことができる。このとき、映像／音声データの制御は、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）やＭＭＳ（Ｍｉｃｒｏｓｏｆｔ Ｍｅｄｉａ Ｓｅｒｖｉｃｅｓ）が利用される。

ここでは、ＲＴＳＰを用いた場合の一般的なシーケンスを図３に示す（非特許文献１を参照）。

まず、データ受信再生装置２０３とストリーミングサーバ２０１の間で通信経路の確立を行なう。例えば、ＴＣＰ／ＩＰの通信手順に従った通信の確立が行なわれる（図示せず）。

次いで、データ受信再生装置２０３は、ストリーミングサーバ２０１が対応しているメソッドをＯＰＴＩＯＮＳメソッドにより問い合わせる（ステップＳ３１）。次に、ＤＥＳＣＲＩＢＥメソッドにより再生する映像／音声データのヘッダ情報やプロパティを取得し（ステップＳ３２）、ＳＥＴＵＰメソッドにより伝送方法やポートのネゴシエーションを行う（ステップＳ３３）。ＰＬＡＹメソッドで再生開始を要求すると（ステップＳ３４）、ストリーミングサーバ２０１はＩＴＵ−ＴＳ（国際電気通信連合）とＩＳＯ（国際標準化機構）で制定されたＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）などの映像／音声データをペイロードとし、ＳＥＴＵＰメソッドでネゴシエーションしたプロトコルに準じた形式で、ＵＤＰパケット或いはＲＴＰパケットを構築し、データ受信再生装置２０３に送信する。データ受信再生装置２０３は、受信したパケットのペイロードから映像／音声データを抽出し再生する（ステップＳ３５）。

この間、データ受信再生装置２０３は、ストリーミングサーバ２０１とのセッションを維持するために、キープアライブを送信することもある。

映像／音声データの再生を終了するには、ＴＥＡＲＤＯＷＮメソッドを送信して、ストリーミングサーバ２０１が割り当てた資源を解放するよう要求する（ステップＳ３６）。

また、ストリーミングサーバ２０１は、全ての映像／音声データの伝送を終了した場合にデータの終了を示す制御情報や、ストリーミングサーバ２０１で発生したエラーに関する情報を、ＡＮＮＯＵＮＣＥメソッドによりデータ受信再生装置２０３に通知する機能も有する。

このように、ストリーミング再生を行う場合、実際の映像／音声データがデータ受信再生装置２０３において再生されるまでに、ＴＣＰ／ＩＰの通信手順に従った通信経路の確立やＲＴＳＰにおけるＯＰＴＩＯＮＳやＤＥＳＣＲＩＢＥ、ＳＥＴＵＰメソッドといった要求及びこれに対するストリーミングサーバ２０１からの返答といったセットアップを待機する必要があり、テレビを見るような感覚でストリーミング再生を行うことができない。

この点について、ハイパーテキストを表示している最中に、その中に存在するリンク先の文書データを事前に読み込み、キャッシュに登録しておくことでユーザーからのリンク指示に高レスポンスで対応する技術が提案されている（例えば、特許文献１を参照）。

しかし、ハイパーテキストにリンクしたストリーミングデータを受信する場合、この技術をそのまま利用することは困難である。映像／音声データで構成されるストリーミングデータは、ＭＰＥＧ等により圧縮処理したものであってもそのデータ量は大きく、事前にデータ受信再生装置２０３がこれをキャッシュしておくには膨大な量のキャッシュ・メモリが必要となり、データ受信再生装置２０３の高額化を招く。１つのハイパーテキストに複数のストリーミングデータがリンクされている場合にこの問題は顕著となる。

さらに、ユーザーが選択したコンテンツを直ちに出力し得る使い勝手の優れたコンテンツ配信システムを実現すべく、ユーザーがコンテンツを選択するまでの期間を利用して、コンテンツにリンクされたストリーミングデータを先取り的に所定データ量単位で順次ダウンロードする技術が開示されている（例えば、特許文献２を参照）。この技術によれば、ユーザーが番組選択を思案している間に、動画再生に必要な所定データ量単位に区切られた分のストリーミングデータを、過去の履歴情報に基づいて決定した優先順位に従って順次ダウンロードし、データ蓄積部にバッファリングしておくことで、ユーザーの番組選択に即応したストリーミングデータの再生表示が可能になる。

しかし、コンテンツからリンクされるストリーミングデータが多い、すなわち、ユーザーが選択可能な番組が多く用意されている場合、全ての番組について所定データ量単位に区切られた分のストリーミングデータを受信・蓄積しておく必要があり、メモリの増大・受信再生装置の高額化は避けられない。また、受信・蓄積するストリーミングデータに優先順位をつけて一定限度のストリーミングデータのみを受信・蓄積することも可能であるが、この場合、優先順位の低いストリーミングデータについては先取り的な受信が後回しになってしまい、ユーザーの再生指示までにストリーミングデータの受信を完了できない事態を生じ得る。特に、ユーザーは、過去に見たことのないストリーミングデータを希望し、受信・記憶していないストリーミングデータに対して再生指示を行う可能性がある。そのような場合、新たにストリーミングデータを受信するためにストリーミングサーバとの間で通信を開始、セットアップを行なう必要があり、ユーザーの待ち時間を解消できない。さらに、先取り的に受信・記憶したストリーミングデータをユーザーが選択決定したとしても、受信・蓄積している分のストリーミングデータの再生を完了するまでに再度ストリーミングサーバとの間で通信を開始し、セットアップを行ったうえ、残りのストリーミングデータを受信する必要がある。ストリーミングサーバの回線の込み具合等の事情により、再度の通信開始ができなかったり、時間がかかった場合、既蓄積分の再生が完了した時点でストリーミングの再生は停止する。かかる弊害を回避するために、記憶しておくストリーミングデータの所定データ量単位を増やせば、メモリ容量の増加、蓄積完了までの時間の長期化に直結する。
特開平１１−４５２５９号公報 特開２００３−２８４０２９号公報 ＩＥＴＦ／ＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）２３２６ １９９８年４月勧告

本発明は、上記問題点に鑑み、データ受信再生装置のメモリ容量を極端に増やすことなく、ユーザーからのストリーミング再生指示に即応するストリーミングデータの受信再生方法を実現することを課題としている。

本発明にかかるマルチメディア情報の受信方法は、上記課題を解決するために、ＷＥＢサーバからネットワークを介してハイパーテキストで記述されたファイルを受信するステップと、受信したハイパーテキストに含まれる１または複数のマルチメディアサーバへのリンク情報を解析するステップと、解析された前記リンク情報により指定されるマルチメディアサーバとの間で通信を開始し、マルチメディア情報の送信要求を前記マルチメディアサーバに対して送信するまでのセットアップを行なうステップと、前記セットアップにより取得した前記マルチメディアサーバとの通信を特定するセッション情報を記憶するステップと、ユーザーによる前記リンク情報の選択に従って、前記マルチメディアサーバに対して前記送信要求を送信するステップを具備することを特徴としている。

本発明によれば、ネットワークのアイドル時間に、データの受信再生に必要なセットアップを前倒しで行うことが可能となるので、ユーザーからの再生指示が行われた場合、速やかに再生を開始することができる。

以下本発明の実施の形態について、図面を参照しながら説明する。

（実施の形態１）
図１は、本発明の実施の形態１におけるデータ受信再生装置、すなわちクライアントマシンの処理シーケンス図である。また、本発明の実施の形態１におけるネットワーク構成図は、背景技術で用いた図２と同じとする。

データ受信再生装置２０３は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を利用して少なくとも１台のＷｅｂサーバ２０２からＨＴＭＬファイルを取得する（ステップＳ１０）。そして、取得したＨＴＭＬファイルを解析し（ステップＳ１１）、画像や他のＨＴＭＬファイルを取得する必要があれば、Ｗｅｂサーバ２０２にそれらのファイルを要求し、最終的に得られたページをブラウザにより表示する。

このとき解析したＨＴＭＬファイルに、ストリーミング方式の映像及び／或いは音声データへのリンク情報があれば、当該リンク情報に記述されたストリーミングサーバ２０１のアドレスを元にストリーミングサーバ２０１との通信を開始し、その映像／音声データに対してＴＣＰ／ＩＰやＲＴＳＰ等のセットアップを行う（ステップＳ１２）。ここで、セットアップとは、データ受信再生装置２０３がストリーミングサーバ２０１に対してＲＴＳＰのＰＬＡＹメソッドを送信する直前までのＴＣＰ／ＩＰやＲＴＳＰ等のメソッドの送受信処理を意味し、ＲＴＳＰのメソッドでは図３におけるステップＳ３１〜Ｓ３３がこれに相当する。

この場合、送信するＲＴＳＰメソッドは、データ受信再生装置２０３が一定の制限を守れば任意の順序で任意のメソッドを送信することができるため、ＯＰＴＩＯＮＳメソッド、ＤＥＳＣＲＩＢＥメソッド、ＳＥＴＵＰメソッドに限るものではない。

ＲＴＳＰのセットアップが完了するまでに取得した情報で、その後、映像／音声データの受信・再生に必要となるセッション情報はここで記憶しておく（ステップＳ１３）。例えば、映像／音声データのファイル名、ストリーミングサーバ２０１のアドレス、伝送プロトコル、ポート番号、レート等である。

ＨＴＭＬファイルに複数の映像／音声データへのリンク情報が含まれれば、それら全数に対して、或いはある閾値を上限として、ステップＳ１２とＳ１３を繰り返す。この場合は、複数のストリーミングサーバ２０１が存在しうる。閾値は、予めデータ受信再生装置２０３に設定されているか、或いはユーザーが任意に設定可能である。

一定の閾値を設ける場合、ＨＴＭＬファイルに含まれる複数の映像／音声データへのリンク情報から一定の閾値に該当する数のリンク情報を選択するステップを追加する。この場合の選択は、ユーザーの過去の再生指示情報をデータ受信再生装置２０３の記憶装置に記憶させておき、この過去の再生指示情報をもとに行なうことができる。例えば、ユーザーが過去に見ていないストリーミングデータに対するセットアップのみを行ったり、同じストリーミングデータを度々選択するユーザーに対してはユーザーが過去に選択したことのあるストリーミングデータのみを選択してセットアップすることも可能である。

これにより、ＨＴＭＬに含まれるリンク情報に記述された全てのストリーミングサーバとの間でセットアップを行なうのではなく、一定数のストリーミングサーバとの間でのみセットアップを行なえばよいことになるので、ストリーミングサーバとの間で多数のセッションを設けることに起因するデータ受信再生装置２０３の負荷を軽減することが可能になる。

また、リンク情報からストリーミングデータの種類を判定するステップを追加し、このステップで判定されたストリーミングデータの種類に従って選択を行なうことも可能である。例えば、ストリーミングデータの圧縮方式が一定のもののみを選択したり、映像／音声データ等、ストリーミングデータの種類によって選別することも可能である。ストリーミングデータの種類の判定は、例えばリンク情報に含まれる拡張子（「．ｍｐｇ」や「．ａｖｉ」等）に基づいて行なうことができる。これにより、ユーザーが選択する可能性の高いストリーミングサーバとの間でのみセットアップを行なうことが可能になる。

さらに、ＨＴＭＬファイルに含まれる複数の映像／音声データへのリンク情報にセットアップの順番付けを行なうステップを追加してもよい。これにより、ユーザーが次に選択する可能性が高いと予想されるストリーミングサーバに対するセットアップを優先的に行なうとが可能となる。さらに、リンク情報からストリーミングデータの種類を判定するステップを設け、ここで判定したストリーミングデータの種類に基づいてセットアップの優先順位を決定することも可能である。また、過去にユーザーが選択したストリーミングデータの情報を記憶するステップを設け、ここで記憶したストリーミングデータに基づいてセットアップの優先順位を決定してもよい。これにより、ユーザーによる早いタイミングでのストリーミングデータの選択にも対応できるように、ユーザーから選択される可能性の高いストリーミングサーバとの間で優先的にセットアップを完了しておくことが可能となる。

次に、ユーザーがキーボード、マウス、リモートコントローラなどの入力デバイスを用いて映像／音声データの再生を指示すると、既に当該映像／音声データのセットアップが完了（ステップＳ１２）しており、セッション情報が既知（ステップＳ１３）であれば、ＰＬＡＹメソッドを送信し、再生開始を要求する（ステップＳ１６）。もし、当該映像／音声データのセットアップが完了しておらず、セッション情報が記憶されていなければ、ストリーミングサーバ２０１にセットアップで必要なＲＴＳＰメソッドを送信、そこで得られた情報を記憶し（ステップＳ１４、Ｓ１５）、ＰＬＡＹメソッドを送信することで再生開始を要求する（ステップＳ１６）。すなわち、ユーザーからの指示は、ステップＳ１２、Ｓ１３を行っている最中であっても受け付けることができ、ステップＳ１４、Ｓ１５は、ステップＳ１２、Ｓ１３より優先して処理される。

再生開始の要求を受け取ったストリーミングサーバ２０１は、ＭＰＥＧなどの映像／音声データをペイロードとし、ＳＥＴＵＰメソッドでネゴシエーションしたプロトコルに準じた形式でＵＤＰパケット或いはＲＴＰパケットを構築し、データ受信再生装置２０３に送信する。データ受信再生装置２０３は、受信したパケットのペイロードから映像／音声データを抽出し再生する。

かかる方法によれば、ユーザーが映像／音声データを選択する毎に実行されるストリーミングサーバ２０１のセットアップ、再生開始要求のうち、ネットワークのアイドル時間にセットアップ処理を前倒しで行っておくことで、ユーザーからの再生指示が行われた場合、再生開始要求を行うのみで速やかに再生を開始することができる。

なお、本実施の形態において、データ受信再生装置２０３はＷｅｂサーバ２０２からＨＴＭＬファイルを取得したが、Ｗ３Ｃ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ Ｃｏｎｓｏｒｔｉｕｍ）により標準化勧告されているＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）やＳＭＩＬ（Ｓｙｎｃｈｒｏｎｉｚｅｄ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｇｒａｔｉｏｎ Ｌａｎｇｕａｇｅ）などその他のマークアップ言語で記述されたファイルであってもかまわない。また、ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）などにより動的に生成されたファイルであってもかまわない。伝送プロトコルについても本実施の形態１で説明したＲＴＳＰに限定されるものではなく、ストリーミング再生に適したプロトコルであればＭＭＳ等、どのようなものであってもよい。また、映像／音声データの符号化方式に関しても、ＭＰＥＧに限るものではない。

本実施の形態１および以下に説明する実施の形態においては、ストリーミングデータを受信再生する場合を例示して説明しているが、映像／音声情報のストリーミングデータのほか、静止画像情報、ハイパーテキストを含む文書データ、ゲームやソフトウェアプログラムなどのマルチメディア情報をマルチメディアサーバからダウンロードする場面にも本技術を応用することが可能である。この場合、これらマルチメディア情報の送信要求をマルチメディアサーバに送信する以前のセットアップを行なっておくことで、ユーザーからのマルチメディア情報のダウンロード指示に備えることが可能になる。例えば、ＨＴＭＬファイルにダウンロード用プログラムを保有するサーバへのリンク情報が含まれる場合、事前にそれらリンク先サーバとのセットアップを行ない、プログラム送信要求以前のＴＣＰ／ＩＰの通信確立などを含むセットアップを行なっておくことで、ユーザーがこれらリンク先を実際に選択してからプログラムのダウンロードが開始されるまでの期間を短縮することが可能となる。

（実施の形態２）
図４は、本発明の実施の形態２におけるデータ受信再生装置の処理シーケンス図である。また、本発明の実施の形態２におけるネットワーク構成図は、背景技術で用いた図２と同じとする。

データ受信再生装置２０３は、ＨＴＴＰプロトコルを利用して少なくとも１台のＷｅｂサーバ２０２からＨＴＭＬファイルを取得する（ステップＳ４０）。そして、取得したＨＴＭＬファイルを解析し（ステップＳ４１）、画像や他のＨＴＭＬファイルを取得する必要があれば、Ｗｅｂサーバ２０２にそれらのファイルを要求し、最終的に得られたページをブラウザにより表示する。

このとき解析したＨＴＭＬファイルに、ストリーミング方式の映像及び／或いは音声データへのリンク情報があれば、その映像／音声データに対してＴＣＰ／ＩＰやＲＴＳＰ等のセットアップを行う（ステップＳ４４）。

ＲＴＳＰのセットアップが完了するまでに取得した情報で、その後、映像／音声データの再生に必要となるセッション情報はここで記憶しておく（ステップＳ４５）。

ＨＴＭＬファイルに複数の映像／音声データへのリンク情報が含まれれば、ある閾値を上限として、ステップＳ４４とＳ４５を繰り返す。

この閾値は、データ受信再生装置２０３が接続されるネットワークの帯域によって決定する。データ受信再生装置２０３は、ネットワークの帯域を取得し（ステップＳ４２）、取得した帯域から最大セッション数を算出する（ステップＳ４３）。最大セッション数の算出は、取得したネットワークの帯域と１セッションに必要なデータレートを比較することにより行う。この場合、セッション情報は未だ取得していないため、１セッションに必要なデータレートとして事前に設定された値を用いることになる。なお、ステップＳ４３による最大セッション数の算出は、ステップＳ４４の後、またはステップＳ４５の後に行ってもよい。この場合、取得したセッション情報（ステップＳ４４、Ｓ４５）に含まれるデータレートと比較することができるので、より現実的な最大セッション数の算出が可能になる。

なお、ネットワークの帯域を取得するには、あるサイズのファイルをダウンロードするのにどれだけの時間を要したかにより求めることができるが、ユーザーが予め設定しておいてそれを利用する方法でもよい。

以降のシーケンスは、本発明の実施の形態１と同様であるため、説明を省略する。

かかる方法によれば、ＨＴＭＬファイルなどのハイパーテキストに、複数の映像／音声データが含まれる場合に、ストリーミングサーバとの間でデータ受信再生装置２０３が接続されるネットワーク環境の帯域を超える多数のセッションが設けられることに起因する、データ受信再生装置、およびネットワークの負荷を軽減することができる。

なお、本実施の形態において、ステップＳ４２、Ｓ４３はハイパーテキストを入力する毎に行われるようになっているが、データ受信再生装置２０１が起動してから少なくとも一度だけ実行するものであってもよい。接続されるネットワーク環境は同じであり、ハイパーテキストを解析する間に帯域が大きく変化することがない場合はステップＳ４２、Ｓ４３を繰り返す必要がなく、迅速なセットアップが実現できるためである。

（実施の形態３）
図５は、本発明の実施の形態３におけるデータ受信再生装置の処理シーケンス図であり、図６は、本発明の実施の形態３におけるＲＴＳＰメソッドの送受信シーケンス図である。また、本発明の実施の形態３におけるネットワーク構成図は、背景技術で用いた図２と同じとする。

データ受信再生装置２０３は、ＨＴＴＰプロトコルを利用して少なくとも１台のＷｅｂサーバ２０２からＨＴＭＬファイルを取得する（ステップＳ５０）。そして、取得したＨＴＭＬファイルを解析し（ステップＳ５１）、画像や他のＨＴＭＬファイルを取得する必要があれば、Ｗｅｂサーバ２０２にそれらのファイルを要求し、最終的に得られたページをブラウザにより表示する。

このとき解析したＨＴＭＬファイルに、ストリーミング方式の映像及び／或いは音声データへのリンク情報があれば、その映像／音声データに対してＲＴＳＰのセットアップを行う（ステップＳ５２）。

ＴＣＰ／ＩＰやＲＴＳＰ等のセットアップが完了するまでに取得した情報で、その後、映像／音声データの再生に必要となるセッション情報はここで記憶しておく（ステップＳ５３）。

ＨＴＭＬファイルに複数の映像／音声データへのリンク情報が含まれれば、それら全数に対して、或いはある閾値を上限として、ステップＳ５２とＳ５３を繰り返す。

以後、データ受信再生装置２０３は、ストリーミングサーバ２０１との通信を維持するために必要なキープアライブを、ある時間間隔で送信する（ステップＳ５４）。

複数の映像／音声データに対してセットアップを行っていれば、各々の映像／音声データに対するキープアライブを送信する。キープアライブに使用するＲＴＳＰメソッドは、ＯＰＴＩＯＮＳメソッドのように再生に影響を与えないメソッドであれば任意であるが、ＣＲ（Ｃａｒｒｉａｇｅ Ｒｅｔｕｒｎ）＋ＬＦ（Ｌｉｎｅ Ｆｅｅｄ）を用いることも可能であり、この場合は、ストリーミングサーバ２０１からデータ受信再生装置２０３にＲＴＳＰメソッドの応答は返らない。

次いで、ユーザーがキーボード、マウス、リモートコントローラなどの入力デバイスを用いて映像／音声データの再生を指示すると、既に当該映像／音声データのセットアップが完了しており、セッション情報が既知であれば、ＰＬＡＹメソッドを送信し、再生開始を要求する（ステップＳ５７）。もし、当該映像／音声データのセットアップが完了しておらず、セッション情報がわかっていなければ、ストリーミングサーバ２０１にセットアップで必要なＲＴＳＰメソッドを送信、そこで得られた情報を記憶し（ステップＳ５５、Ｓ５６）、ＰＬＡＹメソッドを送信することで再生開始を要求する（ステップＳ５７）。

再生開始の要求を受け取ったストリーミングサーバ２０１は、ＭＰＥＧなどの映像／音声データをペイロードとし、ＳＥＴＵＰメソッドでネゴシエーションしたプロトコルに準じた形式でＵＤＰパケット或いはＲＴＰパケットを構築し、データ受信再生装置２０３に送信する。データ受信再生装置２０３は、受信したパケットのペイロードから映像／音声データを抽出し再生する（ステップＳ６０）。この間もデータ受信再生装置２０３は、キープアライブをある時間間隔で送信しつづけている。

ここで、ユーザーがストリーミングサーバ２０１に対し、受信中の映像／音声データの再生停止を指示すると、データ受信再生装置２０３は、ＰＡＵＳＥメソッドを送信する（ステップＳ６１）。この場合も、データ受信再生装置２０３は、キープアライブをある時間間隔で送信しつづける。

かかる方法によれば、データ受信再生装置２０３からの要求がないためにストリーミングサーバ２０１がタイムアウトして、当該映像／音声データを受信再生するために割り当てた資源を解放するのを防ぐことができる。また、ユーザーが一旦は停止した映像／音声データに対して、再度そのデータを再生指示した場合にも速やかな再生開始を実現できる。

なお、キープアライブの送信間隔はストリーミングサーバ２０１に依存することになるため、想定されるタイムアウト時間よりも短い送信間隔を使用する必要があるが、これは予めデータ受信再生装置２０３に設定されていることが多く、別の方法としては、セットアップの処理過程で、ストリーミングサーバ２０１とデータ受信再生装置２０３のネゴシエーションで決定することもできる。

また、本発明の実施の形態３では、ユーザーが再生停止を指示するものとしたが、映像／音声データの送信が完了し、ストリーミングサーバ２０１からＡＮＮＯＵＮＣＥメソッドによるＥＯＳ（Ｅｎｄ Ｏｆ Ｓｔｒｅａｍ）が通知された場合であっても、同様に通信を維持する。

（実施の形態４）
図７は、本発明の実施の形態４におけるデータ受信再生装置の処理シーケンス図である。また、本発明の実施の形態４におけるネットワーク構成図は、背景技術で用いた図２と同じとする。

データ受信再生装置２０３は、ＨＴＴＰプロトコルを利用して少なくとも１台のＷｅｂサーバ２０２からＨＴＭＬファイルを取得する（ステップＳ７０）。そして、取得したＨＴＭＬファイルを解析し（ステップＳ７１）、画像や他のＨＴＭＬファイルを取得する必要があれば、Ｗｅｂサーバ２０２にそれらのファイルを要求し、最終的に得られたページをブラウザにより表示する。

このとき解析したＨＴＭＬファイルに、ストリーミング方式の映像及び／或いは音声データへのリンク情報があれば、その映像／音声データに対してＴＣＰ／ＩＰやＲＴＳＰ等のセットアップを行う（ステップＳ７２）。

ＲＴＳＰのセットアップが完了するまでに取得した情報で、その後、映像／音声データの再生に必要となるセッション情報はここで記憶しておく（ステップＳ７３）。

このとき、通信開始からの経過時間を管理するために、一定の時間でタイムアウトするタイマを起動する（ステップＳ７４）。なお、タイマは通信を終了した場合に削除されるものとする。以後、タイムアウトが発生した場合は、当該映像／音声データに対し、ＴＥＡＲＤＯＷＮメソッドを送信して、ストリーミングサーバ２０１が割り当てた資源を解放するよう要求する（ステップＳ７５）。この場合、タイムアウト後はキープアライブメソッドをストリーミングサーバ２０１に送信しないことで通信を終了させることも可能である。

ＨＴＭＬファイルに複数の映像／音声データへのリンク情報が含まれれば、それら全数に対して、或いはある閾値を上限として、ステップＳ７２〜Ｓ７５を繰り返す。

ユーザーがキーボード、マウス、リモートコントローラなどの入力デバイスを用いて映像／音声データの再生を指示すると、既に当該映像／音声データのセットアップが完了しており、セッション情報が既知であれば、ＰＬＡＹメソッドを送信し、再生開始を要求する（ステップＳ７９）。このとき、当該映像／音声データのセッション経過時間を管理しているタイマをリセットしておく（ステップＳ７８）。もし、当該映像／音声データのセットアップが完了しておらず、セッション情報がわかっていなければ、ストリーミングサーバ２０１にセットアップで必要なＲＴＳＰメソッドを送信、そこで得られた情報を記憶し（ステップＳ７６、Ｓ７７）、ＰＬＡＹメソッドを送信することで再生開始を要求する（ステップＳ７９）。この場合は、ステップ７６、７７がステップ７２、７３に優先するため、タイマは起動しない。

かかる方法によれば、ユーザーからの操作が一定時間得られない場合に、それ以降に通信されるＲＴＳＰメソッドを停止し、無駄な通信やデータ受信再生装置２０３の負荷を軽減することができる。また、ストリーミングサーバ２０１の資源を他のクライアントに解放することで、ネットワークを有効に活用することが可能となる。

なお、本実施の形態において、タイマをリセットさせているのは再生を要求するタイミングだけであるが、一時停止、停止、早送り、巻き戻しなど、映像・音声データの再生を制御するＲＴＳＰメソッドを送信する場合にも同様にタイマをリセットするようにしてもよい。また、ユーザーがあるＨＴＭＬファイルを見ている最中に、別のＨＴＭＬファイルを取得する指示を与えた場合、既に接続しているセッションがあれば、それをステップＳ７０の前後処理で解放してもよい。これにより、累積的に増えていくセッションを軽減することができる。また、ＨＴＭＬファイルの切り換えが複数回行われ、切り換え数が一定回数を超えた場合にのみ通信の終了を要求するようにしてもよい。これにより、先に見ていたＨＴＭＬファイルに戻ってストリーミングサーバへの再生を指示するといったユーザーの要求に対応することが可能となる。

（実施の形態５）
以上、実施の形態１〜４において、本発明にかかるマルチメディア情報の受信方法を説明したが、パーソナルコンピュータ（ＰＣ）やテレビ、ビデオ、その他ＳＴＢ（Ｓｅｔ−ｔｏｐ Ｂｏｘ）等の受信機にこれらの受信方法をソフトウェアとして組み込み、これをＰＣ等に備わるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に処理・実行させることで、ユーザーからの再生指示に即応するストリーミングデータの受信装置を実現することが可能となる。

また、実施の形態１〜４の受信方法を上記ＰＣ等に備わるＣＰＵで処理・実行させるために、これらの方法をＣＰＵで処理可能な手順としてプログラムまたはプログラムに準ずるデータとしてＣＤ−ＲＯＭ等の記録媒体に格納することも可能である。これにより、読取装置を備えたＰＣ等で上述の方法を実現することが可能となる。

本発明のデータ受信再生方法及びデータ受信再生装置は、ネットワークのアイドル時間に、データの受信再生に必要なセットアップを予め行い、またそのストリーミングサーバとのセッションを維持しておくことで、ユーザーからの再生指示が行われた場合、速やかに再生を開始することができるようになるので、インターネット或いはホームネットワークによるＩＰ網を利用したビデオ・オン・デマンドサービスにおけるストリーミングデータ受信方法及びストリーミングデータ受信再生装置として有用である。

本発明の実施の形態１におけるデータ受信再生装置の処理シーケンス図 従来例におけるビデオ・オン・デマンドシステムのネットワーク構成図 従来例におけるＲＴＳＰメソッドの送受信シーケンス図 本発明の実施の形態２におけるデータ受信再生装置の処理シーケンス図 本発明の実施の形態３におけるデータ受信再生装置の処理シーケンス図 本発明の実施の形態３におけるＲＴＳＰメソッドの送受信シーケンス図 本発明の実施の形態４におけるデータ受信再生装置の処理シーケンス図

符号の説明

２０１ ストリーミングサーバ
２０２ Ｗｅｂサーバ
２０３ データ受信再生装置

Claims (17)

1. ネットワークに接続されたクライアントマシンによるマルチメディア情報の受信方法であって、
   ＷＥＢサーバからネットワークを介してハイパーテキストで記述されたファイルを受信するステップと、受信したハイパーテキストに含まれる１または複数のマルチメディアサーバへのリンク情報を解析するステップと、解析された前記リンク情報により指定されるマルチメディアサーバとの間で通信を開始し、マルチメディア情報の送信要求を前記マルチメディアサーバに対して送信するまでのセットアップを行なうステップと、前記セットアップにより取得した前記マルチメディアサーバとの通信を特定するセッション情報を記憶するステップと、ユーザーによる前記リンク情報の選択に従って、前記マルチメディアサーバに対して前記送信要求を送信するステップを具備することを特徴とするマルチメディア情報の受信方法。
2. 請求項１に記載のマルチメディア情報の受信方法であって、
   ユーザーによる前記リンク情報の選択が前記セッション情報の記憶より先に行なわれた場合、ユーザーが選択したリンク情報により指定されるマルチメディアサーバとの間の前記セットアップおよび前記セッション情報の記憶、前記送信要求の送信を、他のリンク情報により指定されるマルチメディアサーバとの間の前記セットアップおよび前記セッション情報の記憶に優先して行なうことを特徴とするマルチメディア情報の受信方法。
3. さらに、前記リンク情報のうち１または複数のリンク情報を選択するステップを備えた請求項１または２に記載の受信方法であって、
   前記セットアップは、前記選択されたリンク情報において指定されるマルチメディアサーバとの間でのみ行われることを特徴とするマルチメディア情報の受信方法。
4. さらに、前記リンク情報から前記マルチメディア情報の種類を判定するステップを備えた請求項３に記載の受信方法であって、
   前記リンク情報の選択は、前記マルチメディア情報の種類に基づいて行なうことを特徴とするマルチメディア情報の受信方法。
5. さらに、過去にユーザーが選択したリンク情報を記憶するステップを備えた請求項３に記載の受信方法であって、
   前記リンク情報の選択は、ユーザーが過去に選択したリンク情報に基づいて行なうことを特徴とするマルチメディア情報の受信方法。
6. さらに、前記リンク情報にセットアップの順番付けを行なうステップを備えた請求項１から５に記載の受信方法であって、
   前記セットアップは、前記リンク情報に付された順番に従って行われることを特徴とするマルチメディア情報の受信方法。
7. さらに、前記リンク情報から前記マルチメディア情報の種類を判定するステップを備えた請求項６に記載の受信方法であって、
   前記リンク情報の順番付けは、前記マルチメディア情報の種類に基づいて行なうことを特徴とするマルチメディア情報の受信方法。
8. さらに、過去にユーザーが選択したリンク情報を記憶するステップを備えた請求項６に記載の受信方法であって、
   前記リンク情報の順番付けは、ユーザーが過去に選択したリンク情報に基づいて行なうことを特徴とするマルチメディア情報の受信方法。
9. さらに、クライアントマシンが接続されるネットワークの帯域を取得するステップと、前記ネットワーク帯域において取得可能なマルチメディア情報の最大数を算出するステップを備えた請求項１から８に記載のマルチメディア情報の受信方法であって、
   前記セットアップは、前記最大数を上限として行なうことを特徴とするマルチメディア情報の受信方法。
10. さらに、前記マルチメディアサーバとの通信を維持するための制御情報を前記マルチメディアサーバに対して送信するステップを備えた請求項１から９に記載のマルチメディア情報の受信方法。
11. さらに、第１のマルチメディアサーバから受信中の第１のマルチメディアデータに対してユーザーが停止指示を与えた後も、前記第１のマルチメディアサーバとの通信を維持するための制御情報を前記第１のマルチメディアサーバに対して送信することを特徴とする請求項１から１０に記載のマルチメディア情報の受信方法。
12. さらに、前記マルチメディアサーバに対して、通信の終了を要求するステップを備えた請求項１から１１に記載のマルチメディア情報の受信方法であって、
    前記通信終了の要求は、クライアントマシンが受信する前記ハイパーテキストファイルを別のハイパーテキストファイルに切り換えるタイミングで行なうことを特徴とするマルチメディア情報の受信方法。
13. さらに、前記マルチメディアサーバとの通信の開始からの時間を測定するステップと、
    クライアントマシンが受信中の前記マルチメディア情報を送信している前記マルチメディアサーバ以外のマルチメディアサーバに対して、通信の終了を要求するステップを備えた請求項１から１２に記載のマルチメディア情報の受信方法であって、前記通信終了の要求は、前記通信の開始からの時間が一定時間を超えたタイミングで行なうことを特徴とするマルチメディア情報の受信方法。
14. 前記マルチメディア情報が、映像または音声のストリーミングデータであることを特徴とする請求項１から１３に記載のマルチメディア情報の受信方法。
15. 請求項１から１４に記載の方法を実現するマルチメディア情報の受信装置。
16. 請求項１から１４に記載の方法を電子計算機により実行させるためのプログラム。
17. 請求項１から１４に記載の方法を電子計算機により実行させるためのプログラムまたはプログラムに準ずる情報を記録した記録媒体。

Images