JP2009100411A - 映像配信システム、映像中継装置、及び映像中継方法 - Google Patents

Abstract

【課題】連続的に映像を再生可能な映像ストリームを配信する。
【解決手段】映像ストリームを送信する映像配信装置と、前記映像配信装置から送信された映像ストリームをバッファに蓄積し、選択された前記映像ストリームを映像受信端末に転送する映像中継装置と、を備える映像配信システムにおいて、前記映像配信装置は、前記映像ストリームの再生可能な単位を示す区切情報を付加して前記映像ストリームを送信し、前記映像中継装置は、前記転送される映像ストリームを前記区切情報の箇所のみで切り換える。
【選択図】図１

Description

本発明は、映像ストリームを配信する映像配信システムに関し、特に、複数の映像ストリームを途切れることなく切り換える方法に関する。

ネットワーク技術の普及に伴って、インターネットプロトコルを用いて映像ストリームを送信する技術が開発されている。このような映像ストリームの送信技術には、ＩＰマルチキャストを用いて、リアルタイムに映像ストリームを配信する方式、ダウンロードし蓄積された映像データを再生する方式、等がある。また、映像符号化方式としてＭＰＥＧ２、配信方式としてＵＤＰ／ＲＴＰを用いたＩＰマルチキャストを用いてリアルタイムにストリームを配信する方式が検討されている。

さらに、通信回線の広帯域化に伴って、複数の視点からの映像を配信し、ユーザの希望に応じて映像を選択可能な映像配信システムが提案されている（例えば、特許文献１参照）。特許文献１に開示された映像配信装置は、映像の内容を示す付加情報を生成し、生成された付加情報を映像に多重して送信する。映像受信装置は、付加情報に基づいて希望する映像を選択する。
特開２００３−１７９９０８号公報

複数の視点映像を切り換えて映像受信端末に送信する場合、ＭＰＥＧ２のようにフレーム間の予測を用いる映像符号化方式では、映像の再生に前後のフレームの情報を利用するため、適切な点で映像ストリームの切り換えないと、切り換えたストリームを受信した端末が正しく映像を再生することができない。ＭＰＥＧ２では、複数のフレームを一つのまとまりとして管理しており、このまとまりはＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）と呼ばれる。ＧＯＰは、一つ以上のＩフレーム、複数のＰフレーム、及び複数のＢフレームを含み、映像の再生単位となる。

Ｉフレームは、フレーム間の予測を使わずに生成されるフレームで、単独で再生することが可能である。Ｐフレームは、他のＩフレームやＰフレームからの順方向の予測（前方予測）によって再生されるフレームである。Ｂフレームは他のＩフレームやＰフレームから双方向の予測によって再生されるフレームである。

そのため、映像受信端末がストリームを正しく再生できるように映像を切り換えるめには、映像ストリームの再生単位を考慮して映像ストリームを切り換える必要がある。

また、複数の映像配信サーバからＩＰネットワークを用いて映像を配信する場合、各映像ストリームは同期して配信されていないため、転送を終了するストリーム（終了ストリーム）の終了点の直後に新しく転送を開始するストリーム（開始ストリーム）の開始点が到着するとは限らない。また、ＩＰネットワークでは、ＩＰパケットの到着順序を保障していないため、ストリームの切換点の通知が切り換えるべきストリームパケットと前後して映像中継サーバに到着することがある。通知が到着した時点でストリームを切り換えると、開始ストリームを開始点から送信し、終了ストリームの送信を終了点で終了することができない。

本発明は、このような課題を解決するために、ストリーム配信された複数の映像の中から、ユーザが希望する映像に切り換えて映像受信端末に配信する際に、映像受信端末が映像再生に支障なく、連続的に映像を再生可能な映像ストリームを、映像中継サーバから配信することを目的とする。

本発明の代表的な一例を示せば以下の通りである。すなわち、映像ストリームを送信する映像配信装置と、前記映像配信装置から送信された映像ストリームをバッファに蓄積し、選択された前記映像ストリームを映像受信端末に転送する映像中継装置と、を備える映像配信システムにおいて、前記映像配信装置は、前記映像ストリームの再生可能な単位を示す区切情報を付加して前記映像ストリームを送信し、前記映像中継装置は、前記転送される映像ストリームを前記区切情報の箇所のみで切り換えることを特徴とする。

本発明の一実施形態によると、映像ストリームの再生単位を考慮して、途切れなく再生可能に、映像を切り換えることができる。

本発明の実施の形態では、映像配信サーバから配信される映像ストリームパケットが、映像の再生開始点や終了点となるデータを含む場合は、ストリームパケットのヘッダ部に目印を付し、ストリームパケットを配信する。ストリームパケットで配信される映像のキーワード、及び、このキーワードが示すストリームパケットの情報をメタデータとして映像中継サーバに通知する。映像中継サーバは、ストリームパケットのヘッダに付与された映像再生の区切情報、及び、メタデータサーバから通知されたキーワードに基づいて、映像受信装置が連続的に映像を再生できる映像の区切りからストリームを切り換えて配信する。

すなわち、映像中継サーバは、新しく受信するストリーム（開始ストリーム）を、映像の再生単位となるＧＯＰの先頭（Ｉフレーム）から転送する。また、映像中継サーバは、送信を終了するストリーム（終了ストリーム）の転送を、後方予測を行わないＩフレーム又はＰフレームの直前で終了する。Ｉフレームの直前は、次のＧＯＰの始まる直前なので、前のＧＯＰの終端となる。

このようにして、映像中継サーバは、映像受信端末がストリームを正しく再生できるように映像を切り換える。

＜実施形態１＞
図１は、本発明の第１の実施の形態の映像配信システムの構成を示すシステム構成図である。

第１の実施の形態の映像配信システムは、映像中継サーバ１、映像配信サーバＡ〜Ｃ（２、３、４）、メタデータ配信サーバ５、ネットワークＡ７、及び、ネットワークＢ８を備え、ネットワークＢ８には、映像受信端末６が接続されている。

ネットワークＡ７は、映像中継サーバ１と、映像配信サーバＡ〜Ｃ（２〜４）と、メタデータ配信サーバ５とを接続する。ネットワークＢ８は、映像中継サーバ１と、映像受信端末６とを接続する。

＜映像中継サーバ＞
まず、映像中継サーバ１について説明する。

図２は、本発明の第１の実施の形態の映像中継サーバ１の構成を示すブロック図である。

映像中継サーバ１は、ＣＰＵ（Central Processing Unit）１１、メモリ１２、インタフェース部１４、１５を備える。

ＣＰＵ１１は、ＯＳ（Operating System）及び各種アプリケーションプログラムを実行する。メモリ１２は、ＣＰＵ１１によって実行される各種アプリケーションプログラムを格納する。ＣＰＵ１１とメモリ１２とは、バス１３によって接続される。

インタフェース部１４、１５は、ＣＰＵ１１及びメモリ１２からのデータを、ネットワークを経由して外部の装置に送信し、外部の装置からのデータを受信する。インタフェース部１４、１５は、それぞれ、ネットワークＡ７に接続される回線１６、ネットワークＢ８に接続される回線１７に接続される。

図３は、本発明の第１の実施の形態の映像中継サーバ１のメモリ１２内の構成を示す説明図である。

映像中継サーバ１のメモリ１２は、パーソナライズストリーム制御プログラム１２１、パーソナライズストリーム配信プログラム１２２、メタデータ解析プログラム１２３、マルチキャスト制御プログラム１２４、バッファ１２５、端末管理テーブル１２６、及び、ストリーム管理テーブル１２７を格納する。

パーソナライズストリーム制御プログラム１２１は、映像受信端末６から送信された通知を受信し、受信した通知に基づいて端末管理テーブル１２６を更新する。

パーソナライズストリーム配信プログラム１２２は、映像配信サーバＡ〜Ｃ（２〜４）から送信される複数の映像ストリームから映像受信端末６に送信すべきパーソナライズストリームを生成し、生成されたパーソナライズストリームを映像受信端末６に送信する。

メタデータ解析プログラム１２３は、メタデータサーバ５から送信されたメタデータ通知を受信し、受信したメタデータ通知に基づいて、映像受信端末６に送信すべきパーソナライズストリームを選択する。

マルチキャスト制御プログラム１２４は、映像受信端末６からのマルチキャスト制御要求（ＩＧＭＰレポート等）を受信し、受信したマルチキャスト制御要求をネットワークＡ７内に存在するマルチキャストルータに転送する。また、マルチキャスト制御プログラム１２４は、マルチキャストルータから送信されたマルチキャスト制御要求（ＩＧＭＰクエリー等）を受信し、受信したマルチキャスト制御要求を映像受信端末６に転送する。

バッファ１２５は、映像配信サーバＡ〜Ｃ（２〜４）から送信された映像ストリームを一時的に保存する。

端末管理テーブル１２６は、映像受信端末６の情報を保持する。端末が複数存在する場合は、端末ごとに端末管理テーブルが保持される。

図４は、本発明の第１の実施の形態の端末管理テーブル１２６の構成例を示す説明図である。

端末管理テーブル１２６は、ＩＰアドレス５０１、ポート番号５０２、キーワード５０３、パーソナライズストリーム５０４、切換フラグ５０５、変更先ストリーム５０６、及び、変更シーケンス番号５０７を含む。

ＩＰアドレス５０１は、映像受信端末６のＩＰアドレスである。ポート番号５０２は、パーソナライズストリームを待ち受けるポート番号である。キーワード５０３は、パーソナライズストリームを選択する際に用いられるキーワードである。なお、キーワードの代わりに、選択されるパーソナライズストリームの識別子を登録してもよい。

ＩＰアドレス５０４は、映像配信サーバから配信されたストリームのうち、現在パーソナライズストリームとして選択されている映像ストリームの識別子（選択されている映像ストリームが配信されているマルチキャストグループの宛先アドレス）である。

切換フラグ５０５は、選択するストリームの切り換えを予約するフラグである。変更先ストリーム５０６は、切り換えを予約した変更先ストリームのＩＰアドレスである。変更シーケンス番号５０７は、変更点のシーケンス番号である。

ストリーム管理テーブル１２７は、映像配信サーバＡ〜Ｃ（２〜４）から送信される映像ストリームの情報を管理する。

図５は、本発明の第１の実施の形態のストリーム管理テーブル１２７の構成例を示す説明図である。

ストリーム管理テーブル１２７は、ＩＰアドレス５０８、キーワード５０９、変更シーケンス番号５１０、及び、最終転送シーケンス番号５１１を含む。

ＩＰアドレス５０８は、映像配信サーバから送信された映像ストリームの宛先のＩＰアドレス５０８である。キーワード５０９は、映像のキーワードであって、映像に付加情報として付与されるキーワードである。変更シーケンス番号５１０は、キーワードで示される映像が始まるシーケンス番号である。最終転送シーケンス番号５１１は、最後に処理したストリームのシーケンス番号である。

＜映像配信サーバ＞
次に、映像配信サーバＡ〜Ｃ（２〜４）について説明する。

映像配信サーバＡ２は、図２に示す映像中継サーバ１と同様のハードウェア構成を有する。すなわち、映像配信サーバＡ２は、ＣＰＵ１１、メモリ１２、バス１３、及び、インタフェース部１４を備える。インタフェース部１４は、ネットワークＡ７に接続される回線１６に接続される。なお、映像配信サーバＡ２はインタフェース部１５を備えない。

図６は、本発明の第１の実施の形態の映像配信サーバＡ〜Ｃ（２〜４）のメモリ１２内の構成を示す説明図である。

映像配信サーバのメモリ１２は、映像取得プログラム４０１、及び、ストリームパケット生成プログラム４０２を格納する。

映像取得プログラム４０１は、映像配信サーバに接続されたカメラ等の撮影機器（図示省略）及び映像データが格納されたメディア（図示省略）等から、映像データを取得する。

ストリームパケット生成プログラム４０２は、映像取得プログラム４０１が取得した映像の構成を解析し、ネットワークＡ７に送信するストリームパケットを生成する。

以上、映像配信サーバＡ２の構成について説明したが、映像配信サーバＢ、Ｃ（３、４）も、映像配信サーバＡ２と同じ構成を備える。

図７は、本発明の第１の実施の形態のストリームパケット生成プログラム４０２によって実行されるストリームパケット生成処理のフローチャートである。

ストリームパケット生成処理は、映像取得処理プログラム４０１からＭＰＥＧ２のＴＳパケットを取得すると（ステップ６０１）、取得したＴＳパケットにＧＯＰスタートコードが含まれるか否かを解析する（ステップ６０２）。

その結果、取得したＴＳパケットにＧＯＰスタートコードが含まれる場合には（ステップ６０３で”ＹＥＳ”）、既に生成されているＲＴＰパケットを回線１６に出力する（ステップ６０４）。そして、新たにＲＴＰヘッダを生成し、所定の領域に”１”を設定する（ステップ６０５）。所定の領域には、ＲＴＰヘッダ中にパディング領域として準備されているＰビット７０１を用いるとよい。

図８は、本発明の第１の実施の形態のＲＴＰヘッダの構成を示す説明図である。ＲＴＰヘッダのＰビット７０１は未使用のパディング領域である。第１の実施の形態では、ＧＯＰの先頭を含むＲＴＰパケットであることを映像中継サーバ１に通知するために、このパディング領域を使用する。

一方、ステップ６０３で、取得したＴＳパケットでＧＯＰスタートコードが検出されなかった場合は、ステップ６０６へ進む。

ステップ６０６では、ＲＴＰヘッダが生成済か否かを判定して、ＲＴＰヘッダが生成済でない場合はＲＴＰヘッダを生成する（ステップ６０７）。一方、ＲＴＰヘッダが生成済である場合はステップ６０８に進む。

その後、ステップ６０８では、ＴＳパケットをＲＴＰパケットのペイロードにパッキングする。既にＲＴＰヘッダが生成済の場合は、生成済のＲＴＰパケットの最後尾にＴＳパケットをパッキングする（ステップ６０８）。

その後、ＲＴＰパケットのペイロードにパッキングされたＴＳパケット数が、回線１６のＭＴＵを超えずに送信できる最大数となったか否かを判定する（ステップ６０９）。その結果、パッキングされたＴＳパケット数が最大数となった場合は、生成したＲＴＰパケットにＩＰヘッダ及びＵＤＰヘッダを付与し、ＲＴＰパケットを回線に出力する（ステップ６１０）。その後、ＴＳパケット取得処理（ステップ６０１）へ戻る。

一方、パッキングされたＴＳパケット数が最大数を超えない場合は、さらにＴＳパケットをＲＴＰパケットにパッキングするために、ステップ６０１のＴＳパケット取得処理へ戻る。

なお、回線１６がイーサネット（登録商標、以下同じ）のＭＴＵは１５００バイトであるため、１つのＲＴＰペイロードにパッキングできるＴＳパケットの最大数は７個となる。ステップ６０９での判定は、ＲＴＰパケットが途中でフラグメントされないようにするための処理であり、ＲＴＰパケットがフラグメントされない値であれば、回線のＭＴＵを超えない最大数のＴＳパケットをパッキングしなくてもよい。リアルタイムに映像を取得するとき、エンコードの遅延等によって、ＴＳパケットが定期的に取得できない場合もある。この場合には、最大数のＴＳパケットがパッキングできるまで送信を遅らせる必要はない。

図９は、本発明の第１の実施の形態のステップ６０１から６１０の処理によって生成され回線に出力されたＩＰパケットの構成例を示す説明図である。

図示するように、複数のＴＳパケットがＲＴＰパケットのペイロードにパッキングされている。ＧＯＰスタートコードを含むＴＳパケットは、ＲＴＰペイロードの先頭にパッキングされる。ＧＯＰスタートコードを含むＴＳパケットがＲＴＰパケットに含まれている場合は、ＲＴＰヘッダのＰビット（７０１）に”１”が設定される。ＲＴＰパケットにＧＯＰスタートコードを含まないＴＳパケットのみが含まれる場合は、ＲＴＰヘッダのＰビット（７０１）に”０”が設定される。

＜メタデータサーバ＞
次に、メタデータサーバ５について説明する。

メタデータサーバ５は、図２に示す映像中継サーバ１と同様のハードウェア構成を備える。すなわち、メタデータサーバ５は、ＣＰＵ１１、メモリ１２、バス１３、及び、インタフェース部１４を備える。インタフェース部１４は、ネットワークＡ７に接続される回線１６に接続される。なお、映像配信サーバＡ２はインタフェース部１５を備えない。

図１０は、本発明の第１の実施の形態のメタデータサーバ５のメモリ１２内の構成を示す説明図である。

メタデータサーバ５のメモリ１２は、ストリーム取得プログラム４０３、及び、メタデータ生成プログラム４０４を格納する。

ストリーム取得プログラム４０３は、映像配信サーバＡ〜Ｃ（２〜４）が送信したストリームパケットを取得する。ストリームパケットは、ネットワークＡ７を通して取得してもよい。また、映像配信サーバＡ〜Ｃ（２〜４）と直接接続された専用線を用いてもよい。また、映像配信サーバＡ〜Ｃ（２〜４）とメタデータサーバ５を同一のハードウェアに実装し、メモリ１２を通してストリームパケット取得してもよい。

メタデータ生成プログラム４０４は、ストリーム取得プログラム４０３が取得した映像ストリームに対応するメタデータを生成する。メタデータは、映像内容を示すキーワード、ＲＴＰのシーケンス番号、及び、配信サーバのＩＤを関連づけたデータである。メタデータに含まれるキーワードは、カメラに付されたセンサーからの情報や、映像ストリームに含まれる画像を解析した結果等によって定められる。

図１１は、本発明の第１の実施の形態のメタデータ通知の構成例を示す。

メタデータには、少なくとも、映像内容を示すキーワード、キーワードと関連付けられた映像のＲＴＰヘッダのシーケンス番号、及び、映像配信サーバを特定するためのＩＤが含まれる。キーワードと映像とはＧＯＰ単位として関連付けられる。通知されるメタデータに対応する映像を含むＲＴＰパケットは、必ずＧＯＰの先頭を含んでいる。本実施の形態では、映像配信サーバＡ〜Ｃ（２〜４）のＩＤとして、映像配信サーバが映像ストリームを配信するマルチキャストグループの宛先アドレスを使用する。

＜映像受信端末＞
次に、映像受信端末６について説明する。

映像受信端末６は、図２に示す映像中継サーバ１と同様のハードウェア構成を有する。すなわち、映像受信端末６は、ＣＰＵ１１、メモリ１２、バス１３、及び、インタフェース部１５を備える。インタフェース部１５は、ネットワークＢ８に接続される回線１７に接続される。なお、映像受信端末６はインタフェース部１４を備えない。

図１２は、本発明の第１の実施の形態の映像受信端末６のメモリ１２内の構成を示す説明図である。

映像受信端末６のメモリ１２は、ストリーム取得プログラム４０５、及び、ストリーム表示プログラム４０６を格納する。

ストリーム取得プログラム４０５は、インタフェース１５及び回線１７を通して、映像ストリームパケットを取得する。ストリーム表示プログラム４０６は、ストリーム取得プログラム４０５が取得した映像ストリームを表示画面に表示する（又は表示画面に出力可能な形式の信号で出力する）。

＜第１の実施の形態の処理＞
なお、本発明の各実施形態の処理は、各装置のＣＰＵ１１がメモリ１２に格納されたプログラムを実行することによって行われる。なお、各処理の一部又は全部を、プログラムの実行によらず、ハードウェアロジックによって行ってもよい。

図１３は、本発明の第１の実施の形態の映像ストリームの切り換え処理のシーケンス図である。

映像受信端末６は、映像配信サーバＡ〜Ｃ（２〜４）から配信される映像ストリームを取得するために、ネットワークＢ８にＩＧＭＰのｒｅｐｏｒｔを送信する。映像中継サーバ１は、映像受信端末６によって送信されたＩＧＭＰのｒｅｐｏｒｔを受信する。受信したＩＧＭＰのｒｅｐｏｒｔは、マルチキャスト制御処理１２４によって、ネットワークＡ７のマルチキャストルータ（図示省略）に転送される。以上の処理によって、映像受信端末６は、各映像配信サーバＡ〜Ｃ（２〜４）によって映像が配信されるマルチキャストグループに参加する。

映像受信端末６は、パーソナライズストリームの受信が可能であることを通知する受信開始通知を、映像中継サーバ１に送信する。受信開始通知には、パーソナライズストリームの受信を待ち受けるポート番号が含まれる。

映像中継サーバ１は、映像受信端末６からの受信開始通知を受信すると、パーソナライズストリーム制御処理を実行する。

図１４は、本発明の第１の実施の形態のパーソナライズストリーム制御プログラム１２１によって実行されるパーソナライズストリーム制御処理のフローチャートである。

まず、映像中継サーバ１は、制御メッセージを受信すると（ステップ９０１）、受信した制御メッセージから送信元ＩＰアドレス（映像受信端末６のＩＰアドレス）を抽出し、抽出された送信元ＩＰアドレスを用いて端末管理テーブル１２６を検索する（ステップ９０２）。

該当する映像受信端末６の端末管理テーブル１２６が存在しない場合は（ステップ９０３で”ＹＥＳ”）、処理を終了する。一方、該当する映像受信端末６の端末管理テーブル１２６が存在する場合は（ステップ９０３で”ＮＯ”）、制御メッセージの種別を特定する（ステップ９０４）。

制御メッセージが受信開始通知である場合は（ステップ９０４で”ＹＥＳ”）、通知された待ち受けポート番号を、該当する映像受信端末６の端末管理テーブル１２６のポート番号５０２に登録し、パーソナライズストリームの配信を開始する（ステップ９０５）。

該当する映像受信端末６の端末管理テーブル１２６にキーワード５０３が登録されていない場合は、ストリーム管理テーブル１２７から任意のストリームを選択し、選択されたストリームのマルチキャストアドレスをパーソナライズストリーム５０４に登録する。本実施の形態では、２３９．２５５．２５５．１（映像配信サーバＡによって配信されるマルチキャストグループの宛先アドレス）を登録する。

なお、端末管理テーブル１２６のパーソナライズストリーム５０４は、初回のみ任意のストリームのＩＰアドレスが登録される。その後は、後述するパーソナライズストリーム配信処理のストリーム切換実行時（図１５のステップ１０１３）に登録される。

図１３に戻り、映像受信端末６は端末のユーザが所望する映像のキーワードを含むキー通知を映像中継サーバ１に送信する。映像中継サーバ１は、キー通知を受信すると、パーソナライズストリーム制御処理（図１４）を実行する。キー通知を受信した映像中継サーバ１は、ステップ９０１から９０３を実行し、ステップ９０４で”ＮＯ”、ステップ９０８で”ＹＥＳ”となるため、ステップ９０９に進む。

その後、映像受信端末６から送信されたキー通知からキーワードを抽出し、抽出されたキーワードを端末管理テーブル１２６のキーワード５０３に登録する（ステップ９０９）。

さらに、通知されたキーワードを用いて、ストリーム管理テーブル１２７を検索する（ステップ９１０）。映像受信端末６から通知されたキーワードと、ストリーム管理テーブル１２７に登録されているキーワード５０９とが一致する場合は、端末管理テーブル１２６の切換フラグ５０５を”ＯＮ”に設定し、ストリーム管理テーブル１２７のＩＰアドレス５０８を端末管理テーブル１２６の変更先ストリーム５０６に登録し、ストリーム管理テーブル１２７の変更シーケンス番号５１０を端末管理テーブル１２６の変更シーケンス番号５０７を登録する。その後、処理を終了する。

一方、映像受信端末６から通知されたキーワードと、ストリーム管理テーブル１２７に登録されているキーワード５０９とが一致しない場合は、端末管理テーブル１２６を更新することなく、処理を終了する。

ここで、再び図１３に戻る。映像中継サーバ１は映像配信サーバＡ２が送信したストリームパケットを受信すると、パーソナライズストリーム配信処理を実行する。

図１５は、本発明の第１の実施の形態のパーソナライズストリーム配信プログラム１２２によって実行されるパーソナライズストリーム配信処理のフローチャートである。

まず、映像中継サーバ１は、ストリームパケットを受信すると（ステップ１００１）、受信したストリームパケットから宛先アドレスを抽出し、抽出された宛先アドレスを用いてストリーム管理テーブル１２７を検索する（ステップ１００２）。

受信したストリームパケットの宛先アドレスがストリーム管理テーブル１２７に登録されていない場合は（ステップ１００３で”ＹＥＳ”）、処理を終了する。一方、受信したストリームパケットの宛先アドレスがストリーム管理テーブル１２７に登録されている場合は（ステップ１００３で”ＮＯ”）、受信したストリームパケットのＲＴＰヘッダのＰビットの有無を判定する（ステップ１００４）。

Ｐビットに”１”が設定されている場合は、受信しているストリームのデータで、既にバッファされているデータを破棄し（ステップ１００５）、受信したストリームパケットをバッファの先頭（バッファＩＤ＝”１”）に格納する（ステップ１００６）。一方、Ｐビットが”１”に設定されていない場合は、最後にストリームパケットが蓄積されたバッファの次のバッファに、受信したストリームパケットを格納する（ステップ１００６）。

ここで、図１６に、本発明の第１の実施の形態のＲＴＰパケットが格納されたバッファ１２５の構成を示す。バッファ１２５は、１ＧＯＰ分よりも多い容量であり、ＲＴＰパケット毎に異なるバッファＩＤが付与されて格納される。ストリーム管理テーブルに登録されているストリーム（ＩＰアドレス５０１）ごとに異なるバッファを保持し、ストリームごとに管理する。

次に、ストリームパケットの宛先ＩＰアドレスを用いて、全ての端末管理テーブル１２６のパーソナライズストリーム５０４を検索する（ステップ１００７）。ストリームパケットの宛先ＩＰアドレスと、端末管理テーブル１２６のパーソナライズストリーム５０４とが一致しない場合は（ステップ１００７で”ＮＯ”）、処理を終了する。一方、ストリームパケットの宛先ＩＰアドレスと、端末管理テーブル１２６のパーソナライズストリーム５０４とが一致する場合は（ステップ１００７で”ＹＥＳ”）、ストリームパケットのＰビットが設定されているか否かを判定する（ステップ１００８）。

ストリームパケットのＰビットに”１”が設定されていない場合は（ステップ１００８で”ＮＯ”）、ステップ１０１２に進み、受信したストリームパケットのＩＰヘッダの宛先アドレス及びＵＤＰヘッダの宛先ポート番号を端末管理テーブル１２６から取得した情報に書き換える。なお、ＲＴＰのシーケンス番号、ＴＳパケットのＰＩＤ、コンティニュティカウンタ、ＰＣＲ及びＰＡＴ等、ＰＥＳヘッダのＰＴＳ、ＤＴＳ等を書き換えてもよい。そして、ヘッダが書き換えられたストリームパケットをパーソナライズストリームとして映像受信端末６へ送信する（ステップ１０１２）。

一方、Ｐビットに”１”が設定されている場合は（ステップ１００８で”ＹＥＳ”）、端末管理テーブル１２６の切換フラグ５０５が設定されているか否かを判定する（ステップ１００９）。

切換フラグ５０５に”ＯＮ”が設定されていない場合は（ステップ１００９で”ＮＯ”）、受信したストリームパケットのＩＰヘッダを書き換えて、ヘッダが書き換えられたストリームパケットを送信し（ステップ１０１２）、処理を終了する。

一方、切換フラグ５０５が”ＯＮ”に設定されている場合は（ステップ１００９で”ＹＥＳ”）、端末管理テーブル１２６の変更先ストリーム５０６に登録されたＩＰアドレスのエントリをストリーム管理テーブル１２７から取得する（ステップ１０１０）。そして、変更先ストリームのＩＰアドレスに対応する、ストリーム管理テーブル１２７中の最終転送シーケンス番号５１１と、端末管理テーブル１２６の変更シーケンス番号５１０とを比較する（ステップ１０１１）。

その結果、最終転送シーケンス番号５１１が変更シーケンス番号５１０より小さい場合は（ステップ１０１１で”ＹＥＳ”）、変更点のストリームパケットが、映像中継サーバ１にまだ到着していないので、ストリームの切り換えは行わない。そして、受信したストリームパケットのＩＰヘッダを書き換えて、ヘッダが書き換えられたストリームパケットを送信し（ステップ１０１２）、処理を終了する。

一方、最終転送シーケンス番号５１１が変更シーケンス番号５１０より以上である場合は（ステップ１０１１で”ＮＯ”）、ストリームの切替タイミングに到達していると判定し、ストリームを切り換える。具体的には、変更先ストリームのバッファ１２５に蓄積されたストリームパケットについて、ステップ１０１２と同様に、ＩＰヘッダ等を書き換えて、ヘッダが書き換えられたストリームパケットを送信する。また、端末管理テーブル１２６の変更先ストリーム５０６に登録されているＩＰアドレスをパーソナライズストリーム５０４に登録し、その後、切換フラグ５０５をＯＦＦに更新し、変更先ストリーム５０６及び変更シーケンス５０７に登録されている情報をクリアする（ステップ１０１３）。その後、処理を終了する。

ここで、再び図１３に戻る。映像配信サーバＡ２から送信されたストリームパケット１０１及び１０３は、パーソナライズストリームとして選択され、Ｐビットが設定されていないため、パーソナライズストリーム配信処理（図１５）のステップ１００１から１００４、ステップ１００６から１００８、及び、ステップ１０１２の処理が行われる。これによって、映像中継サーバ１は、ストリームパケット１０１及び１０３をバッファ１２５に蓄積しつつ、パーソナライズストリームとして映像受信端末６へ転送する。

一方、映像配信サーバＢ３から送信されたストリームパケット１０２は、ビットは設定されず、パーソナライズストリームとして端末管理テーブルに登録されていないため、パーソナライズストリーム配信処理（図１５）のステップ１００１から１００４、ステップ１００６から１００７の処理が行われる。これによって、映像中継サーバ１は、ストリームパケット１０２をバッファ１２５に蓄積し、処理を終了する。

映像中継サーバ１は、メタデータ１０４を受信すると、メタデータ解析プログラム１２３を実行することによって、メタデータ解析処理を行う。

図１７は、本発明の第１の実施の形態のメタデータ解析プログラム１２３によって実行されるメタデータ解析処理のフローチャートである。

まず、映像中継サーバ１は、メタデータを受信すると（ステップ１１０１）、受信したメタデータからＩＰアドレスを抽出し、抽出されたＩＰアドレスを用いてストリーム管理テーブル１２７を検索する（ステップ１１０２）。

受信したメタデータに含まれるＩＰアドレスがストリーム管理テーブル１２７に登録されていない場合は（ステップ１１０３で”ＹＥＳ”）、処理を終了する。一方、受信したメタデータに含まれるＩＰアドレスがストリーム管理テーブル１２７に登録されている場合は（ステップ１１０３で”ＮＯ”）、受信したメタデータに含まれるキーワード及びシーケンス番号をストリーム管理テーブル１２７のキーワード５０９及び変更シーケンス番号５１０にそれぞれ登録する（ステップ１１０４）。

次に、全ての端末管理テーブル１２６のキーワード５０３と、メタデータにて通知されたキーワードとを比較する（ステップ１１０５）。メタデータにて通知されたキーワードが端末管理テーブル１２６のいずれのキーワード５０３とも一致しない場合は、切り換えるべき映像ストリームがないので、処理を終了する。

一方、メタデータにて通知されたキーワードが端末管理テーブル１２６のいずかのキーワード５０３と一致する場合は、該当する端末管理テーブル１２６を更新する（ステップ１１０５）。具体的には、該当する端末管理テーブル１２６の切換フラグ５０５を”ＯＮ”に設定し、メタデータにて通知されたＩＰアドレス及びシーケンス番号を端末管理テーブル１２６の変更先ストリーム５０６及び変更シーケンス番号５０７に登録する。

以上説明した処理によって、受信したメタデータ１０４に基づいて、端末管理テーブル１２６及びストリーム管理テーブル１２７が更新される。

ここで、再び図１３に戻る。図１３に示す場合、映像受信端末６から送信されたキーワードとメタデータ１０４に含まれるキーワードとが一致しているので、端末管理テーブルの切換フラグ５０５はＯＮに設定されている。しかし、その後に映像配信サーバＡ２から送信されたストリームパケット１０５及び１０７はＰビットが設定されていないため、映像中継サーバ１は、ストリームパケット１０１と同様に、ストリームパケット１０５及び１０７を処理する。

映像配信サーバＢ３によって送信されたストリームパケット１０６のシーケンス番号は、メタデータ通知１０４で通知されたシーケンス番号と同じであり、Ｐビットが設定されているため、ストリームの切換点である。しかし、ストリームパケット１０６の到達時にはストリームＡが切換点に到達していないため、ストリームが切り換えられない。そこで、パーソナライズストリーム配信処理（図１５）のステップ１００１から１００７及びステップ１０１２の処理が行われ、ストリームパケット１０６がバッファ１２５に格納される。ストリームパケット１０６に続いて到達するストリームパケット１０８も、同様にバッファ１２５に格納される。

映像配信サーバＡ２によって送信されたストリームパケット１０９は、Ｐビットが設定されている。端末管理テーブル１２６の切換フラグが”ＯＮ”であるので、ストリームが切り換えられる。すなわち、パーソナライズストリーム配信処理（図１５）のステップ１００１から１０１１及び１０１３の処理が行われ、ストリームパケット１０９は転送されず、バッファに蓄積される。さらに、映像配信サーバＢ３によって送信されたストリームパケット１０６及び１０８はバッファから読み出され、ＩＰヘッダの宛先アドレス及びＵＤＰヘッダの宛先ポート番号を端末管理テーブル１２６から取得した情報に書き換える。なお、ＲＴＰのシーケンス番号、ＴＳパケットのＰＩＤ、コンティニュティカウンタ、ＰＣＲ及びＰＡＴ等、ＰＥＳヘッダのＰＴＳ、ＤＴＳ等を書き換えてもよい。そして、ヘッダが書き換えられたストリームパケットは、パーソナライズストリームとして映像受信端末６に送信される。

ストリーム切換後に映像中継サーバ１に到着した、映像配信サーバＢ３によって送信されたストリームパケット１１０は、ステップ１００１から１００４、１００６から１００８及び１０１２の処理が行われることによって、バッファに蓄積されつつ、パーソナライズストリームとして、映像受信端末６に送信される。

図１８は、本発明の第１の実施の形態の映像配信サーバから配信されるストリームが切り換えられたパーソナライズストリームの説明図である。具体的には、図１８は、映像中継サーバ１が、図１３に示すシーケンスによって、映像配信サーバＡ２から配信されるストリームＡが、映像配信サーバＢ３から配信されるストリームＢに切り換えることによって、映像中継サーバ１が送信したパーソナライズストリームを示す。なお、図１８においては、右から左に時間が流れている。

メタデータ１０４によって通知されたキーワードに対応して映像ストリームを切り換える場合、切り換えによって転送が中止されるストリームＡ（終了ストリーム）は、ＧＯＰの終端となるストリームパケット１０７まで転送された後、ストリームが切り換えられる。

切り換えによって転送が開始されるストリーム（開始ストリーム）は、バッファに格納されていたＧＯＰの始まりとなるストリームパケット１０６から転送が開始される。バッファに格納されたストリームパケットの転送終了後は、ストリームパケット１１０のように、ストリームパケットが到着次第転送される。これによって、映像受信端末６は、終了ストリームをＧＯＰの終端まで受信し、開始ストリームはＧＯＰの始まりから受信することが可能となる。

なお、第１の実施の形態の映像中継方法によると、メタデータの通知が、切換点より後に到着した場合（１１１）でも、同様の処理によって、ストリームＢはＧＯＰの先頭から送信することができる。また、バッファ１２５の更新単位である１ＧＯＰ分よりも遅れてメタデータが到着した場合は、最寄りのＧＯＰの先頭からストリームを切り換えることができる。さらに、１ＧＯＰ分よりも多い容量のバッファ１２５を備えることによって、メタデータが１ＧＯＰ分より遅く到着した場合でも、ＧＯＰの先頭から新しいストリームを送信することが可能となる。

なお、第１の実施の形態では、映像符号化方式にＭＰＥＧ２を用いたが、本実施の形態は、１つのフレームを複数のパケットに分割して送信する映像配信システムであれば、他の映像符号化方式を用いるもの全てに適用することができる。

以上説明したように、本発明の一実施形態によると、映像の付加情報であるメタデータに対応して、映像ストリームの再生単位を考慮して、途切れなく再生可能に、映像を切り換えることができる。また、開始ストリームの映像データをバッファ１２５に格納しているので、メタデータが切換点のストリームデータより遅れて通知された場合でも、映像受信端末が再生に支障なく、連続的に映像を再生可能な点から映像ストリームを切り換えることができる。さらに、ストリームデータのヘッダ部を参照して映像を切り換えるので、切換点を特定する処理を削減することができる。

＜実施形態２＞
次に、本発明の第２の実施の形態について説明する。

第２の実施の形態では、映像配信サーバＡ〜Ｃ（２〜４）が、ＧＯＰの先頭だけでなく、ＧＯＰの終端や、Ｉ及びＰフレーム直前、開始を通知する目印を付与することによって、前述した第１の実施の形態より迅速にストリームを切り換えることができる。

第２の実施の形態の映像配信システム及び各装置の構成は、前述した第１の実施の形態と同じである。

図１９は、本発明の第２の実施の形態のストリームパケット生成プログラム４０２によって実行されるストリームパケット生成処理のフローチャートである。なお、前述した第１の実施の形態のストリームパケット生成処理（図７）と同じ処理は同じ符号を付し、それらの説明は省略する。

ステップ６０３で、取得したＴＳパケットにＧＯＰスタートコード及びピクチャースタートコードが含まれるか否かを解析する。

ＴＳパケットにＧＯＰスタートコードが含まれる場合には（ステップ６０３で”ＹＥＳ”）、既に生成されているＲＴＰパケットにＧＯＰの終端を示す拡張ヘッダを付与し、生成されたＲＴＰパケットを回線１６に出力する（ステップ１３０２）。そして、新たにＲＴＰヘッダを生成し、ＧＯＰの先頭を示す拡張ヘッダを設定する（ステップ１３０３）。

ステップ６０３で、ＴＳパケットにＧＯＰスタートコードが含まれていない場合には（ステップ６０３で”ＮＯ”）、さらに、取得したＴＳパケットにピクチャースタートコードが含まれるか否かを判定する。ピクチャースタートコードが含まれる場合は、ピクチャタイプを検査しＰピクチャか否かを判定する。ＴＳパケットにピクチャースタートコードが含まれる場合には（ステップ１３０１で”ＹＥＳ”）、既に生成されているＲＴＰパケットにＰピクチャの直前であることを示す拡張ヘッダを付与し、生成されたＲＴＰパケットを回線１６に出力する（ステップ１３０４）。そして、新たにＲＴＰヘッダを生成し、Ｐピクチャの開始を示す拡張ヘッダを設定する（ステップ１３０５）。

図２０は、本発明の第２の実施の形態のＲＴＰの拡張ヘッダの構成を示す説明図である。

ＲＴＰの拡張ヘッダは、拡張ヘッダの種別、データ長、及び、ＲＴＰペイロードにパッキングされたデータの種別を含む。データの種別は、ＧＯＰの先頭、ＧＯＰの終端、Ｐピクチャー（フレーム）の直前、及び、Ｐピクチャ（フレーム）の開始のいずれかを含む。

図２１は、本発明の第２の実施の形態のパーソナライズストリーム配信プログラム１２２によって実行されるパーソナライズストリーム配信処理のフローチャートである。なお、前述した第１の実施の形態のパーソナライズストリーム配信処理（図１５）と同じ処理は同じ符号を付し、それらの説明は省略する。

第２の実施の形態のパーソナライズ配信処理では、ＲＴＰの拡張ヘッダを利用して映像ストリームの切り換えタイミングを判定する。

すなわち、第２の実施の形態のパーソナライズ配信処理では、ステップ１００１〜１００３の処理が行われる。その後、受信したストリームパケットの宛先アドレスがストリーム管理テーブル１２７に登録されている場合は（ステップ１００３で”ＮＯ”）、受信したストリームパケットのＲＴＰの拡張ヘッダのデータ種別が、”ＧＯＰの先頭”を示すか否かを判定する（ステップ１９０１）。ＲＴＰの拡張ヘッダのデータ種別が”ＧＯＰの先頭”を示す場合は、受信しているストリームのデータで、既にバッファされているデータを破棄し（ステップ１００５）、受信したストリームパケットをバッファ１２５の先頭の領域（バッファＩＤ＝”１”）に格納する（ステップ１００６）。一方、ＲＴＰの拡張ヘッダのデータ種別に”ＧＯＰの先頭”が設定されていない場合は、最後にストリームパケットが蓄積されたバッファの次の領域（バッファＩＤ＝”２”）に、受信したストリームパケットを格納する（ステップ１００６）。

さらに、ステップ１００７の処理が行われた後、ストリームパケットの宛先ＩＰアドレスと、端末管理テーブル１２６のパーソナライズストリーム５０４とが一致する場合は（ステップ１００７で”ＹＥＳ”）、ＲＴＰパケットに拡張ヘッダが付されているか否かを判定する（ステップ１９０２）。その結果、ＲＴＰパケットに拡張ヘッダが付されている場合は、ステップ１００９の処理が行われる。一方、ＲＴＰパケットに拡張ヘッダが付されていない場合は、ステップ１０１２に進む。

さらに、ステップ１０１１において、最終転送シーケンス番号５１１が変更シーケンス番号５１０より以上であると判定された場合は（ステップ１０１１で”ＮＯ”）、ＲＴＰの拡張ヘッダのデータ種別が”ＧＯＰの終端”又は”Ｐフレームの直前”を示すか否かを判定する（ステップ１９０３）。ＲＴＰの拡張ヘッダのデータ種別が”ＧＯＰの終端”又は”Ｐフレームの直前”を示す場合に、ステップ１００１で受信したストリームパケットのＩＰヘッダの宛先アドレス及びＵＤＰヘッダの宛先ポート番号を端末管理テーブル１２６から取得した情報に書き換える。なお、ＲＴＰのシーケンス番号、ＴＳパケットのＰＩＤ、コンティニュティカウンタ、ＰＣＲ及びＰＡＴ等、ＰＥＳのＰＴＳ、ＤＴＳ等を書き換えてもよい。そして、ヘッダが書き換えられたストリームパケットをパーソナライズストリームとして映像受信端末６へ送信する（ステップ１９０４）。その後、ステップ１０１３に進む。

その他の処理は、前述した第１の実施の形態のパーソナライズストリーム配信処理（図１５）と同じである。

図２２は、本発明の第２の実施の形態の映像ストリームの切り換え処理のシーケンス図である。

映像受信端末６は、映像配信サーバＡ〜Ｃ（２〜４）から配信されるオリジナルの映像ストリームを取得するために、ネットワークＢ８にＩＧＭＰのｒｅｐｏｒｔを送信する。映像中継サーバ１は、映像受信端末６によって送信されたＩＧＭＰのｒｅｐｏｒｔを受信する。受信したＩＧＭＰのｒｅｐｏｒｔは、マルチキャスト制御処理１２４によって、ネットワークＡ７のマルチキャストルータ（図示省略）に転送される。以上の処理によって、映像受信端末６は、各映像配信サーバＡ〜Ｃ（２〜４）によって映像が配信されるマルチキャストグループに参加する。

映像受信端末６は、パーソナライズストリームの受信が可能であることを通知する受信開始通知を、映像中継サーバ１に送信する。受信開始通知には、パーソナライズストリームの受信を待ち受けるポート番号が含まれる。

映像中継サーバ１は、映像受信端末６からの受信開始通知を受信すると、パーソナライズストリーム制御処理（図１４）を実行する。パーソナライズストリームは、初回のみ任意のストリームを選択して登録するが、本実施例では、パーソナライズストリームとして、映像配信サーバＡ２が送信しているストリーム（宛先アドレス２３９．２５５．２５５．１）が登録されることとする。その後、映像受信端末６は端末のユーザが所望する映像のキーワードを含むキー通知を映像中継サーバ１に送信する。映像中継サーバ１は、キー通知を受信すると、パーソナライズストリーム制御処理（図１４）を実行する。

その後、映像中継サーバ１は映像配信サーバＡ２が送信したストリームパケットを受信すると、パーソナライズストリーム配信処理（図２１）を実行する。

映像配信サーバＡ２から送信されたストリームパケット１７０９及び１７１０は、パーソナライズストリームとして選択され、ＲＴＰ拡張ヘッダは持っていないため、パーソナライズストリーム配信処理（図２１）のステップ１００１から１９０１、ステップ１００６から１９０２、及び、ステップ１０１２の処理が行われる。これによって、映像中継サーバ１は、ストリームパケット１７０９及び１７１０をバッファ１２５に蓄積しつつ、パーソナライズストリームとして映像受信端末６へ転送する。

一方、映像配信サーバＢ３から送信されたストリームパケット１７０１は、パーソナライズストリームとして選択されていない。また、映像配信サーバＢ３によって送信されたストリームパケット１０２の拡張ヘッダは”ＧＯＰの先頭”であることを示していないため、パーソナライズストリーム配信処理（図２１）のステップ１００１から１９０１、ステップ１００６から１００７の処理が行われる。これによって、映像中継サーバ１は、ストリームパケット１７０１をバッファ１２５に蓄積する。

映像中継サーバ１は、メタデータ１７０２を受信すると、メタデータ解析プログラム１２３を実行することによって、メタデータ解析処理（図１７）を行う。

映像受信端末６から送信されたキーワードとメタデータ１７０２に含まれるキーワードとが一致しているので、端末管理テーブルの切換フラグ５０５はＯＮに設定される。しかし、その後に映像配信サーバＡ２から送信されたストリームパケット１７１１は、ＲＴＰ拡張ヘッダを持っていないため、映像中継サーバ１は、ストリームパケット１７０９と同様に、ストリームパケット１７１１を処理する。

映像配信サーバＢ３によって送信されたストリームパケット１７０４のシーケンス番号は、メタデータ通知１７０２で通知されたシーケンス番号と同じであり、”ＧＯＰの先頭”であることを示す拡張ヘッダを含んでいるため、ストリームの切換点である。しかし、ストリームパケット１７０４の到達時にはストリームＡが切換点に到達していないため、ストリームが切り換えられない。そこで、パーソナライズストリーム配信処理（図２１）のステップ１００１から１００７の処理が行われ、ストリームパケット１０７４がバッファ１２５に格納される。

映像配信サーバＡ２によって送信されたストリームパケット１７０３は、”Ｐピクチャーの直前”であることを示す拡張ヘッダを含んでいる。端末管理テーブル１２６の切換フラグ５０５が”ＯＮ”であり、ストリームの切換点のパケットも到達しているので、本ストリームパケットを転送後、ストリームが切り換えられる。すなわち、パーソナライズストリーム配信処理（図２１）のステップ１００１から１９０１、１００５から１０１１及び１９０３から１０１３の処理が行われ、ストリームパケット１７０３は、パーソナライズストリームとして端末６に転送され、さらにバッファ１２５にも蓄積される。さらに、映像配信サーバＢ３によって送信されたストリームパケット１７０４はバッファ１２５から読み出され、パーソナライズストリームとして映像受信端末６に送信される。

ストリーム切換後に映像中継サーバ１に到着した、映像配信サーバＢ３によって送信されたストリームパケット１７０６及び１７０８は、ステップ１００１から１９０１、１００６から１９０２及び１０１２の処理が行われることによって、パーソナライズストリームとして、映像受信端末６に送信される。

一方、ストリーム切換後に映像中継サーバ１に到着した、映像配信サーバＡ２によって送信されたストリームパケット１７０５及び１７０７は、ステップ１００１から１９０１、ステップ１００６から１００７の処理が行われることによあって、バッファ１２５に蓄積される。

図２３は、本発明の第２の実施の形態の映像配信サーバから配信されるストリームが切り換えられたパーソナライズストリームの説明図である。具体的には、図２３は、映像中継サーバ１が、図２２に示すシーケンスによって、映像配信サーバＡ２から配信されるストリームＡが、映像配信サーバＢ３から配信されるストリームＢに切り換えることによって、映像中継サーバ１が送信したパーソナライズストリームを示す。なお、図２３においては、右から左に時間が流れている。

メタデータ１０４によって通知されたキーワードに対応して映像ストリームを切り換える場合、切り換えによって転送が中止されるストリームＡ（終了ストリーム）は、ＧＯＰの終端を待たずに、Ｐピクチャの直前となるストリームパケット１７０３まで転送された後、ストリームが切り換えられる。

切り換えによって転送が開始されるストリーム（開始ストリーム）は、バッファ１２５に格納されていたＧＯＰの始まりとなるストリームパケット１７０４から転送が開始される。バッファ１２５に格納されたストリームパケットの転送終了後は、ストリームパケット１７０６のように、ストリームパケットが到着次第転送される。これによって、映像受信端末６は、終了ストリームをＰピクチャの直前まで受信し、開始ストリームはＧＯＰの始まりから受信することが可能となる。

以上説明したように、本発明の第２の実施の形態では、ＧＯＰの区切り以外に、Ｐフレームの開始直前においても、終了されるべきストリームの転送が中止される。よって、映像中継処置１は、第１の実施例よりストリームの終了点を早く検知することができ、より迅速に映像ストリームを切り換えることができる。

＜実施形態３＞
次に、本発明の第３の実施の形態について説明する。

第３の実施の形態では、映像中継サーバ１に備わる機能を映像受信端末６に配置し、映像中継サーバが設けられていない映像配信システムにおいても、映像ストリームを切り換えることができる構成について説明する。

図２４は、本発明の第３の実施の形態の映像配信システムの構成を示すシステム構成図である。

第１の実施の形態の映像配信システムは、映像配信サーバＡ〜Ｃ（２、３、４）、メタデータサーバ５、及び、ネットワークＡ７を備え、ネットワークＡ７には、映像受信端末６が接続されている。

本発明の第３の実施の形態の映像受信端末６は、映像選択部６１及び映像表示部６２を備える。映像表示部６２は、ストリーム取得プログラム４０５及びストリーム表示プログラム４０６（図１２）を備える。映像選択部６１は、パーソナライズストリーム制御プログラム１２１、パーソナライズストリーム配信プログラム１２２、メタデータ解析プログラム１２３、マルチキャスト制御プログラム１２４、バッファ１２５、端末管理テーブル１２６、及び、ストリーム管理テーブル１２７（図３）を備える。各プログラムによって実行される処理は、前述した第１の実施の形態と同じである。

図２５は、本発明の第３の実施の形態の映像ストリームの切り換え処理のシーケンス図である。

第３の実施の形態では、映像受信端末６は、上流のマルチキャストルータ（図示省略）に、直接マルチキャスト制御要求（ＩＧＭＰのレポートなど）を送信する。

受信開始要求、キー通知及び受信終了通知は、映像受信端末６の内部処理として、メモリ１２を介して、パーソナライズストリーム制御プログラム１２１に通知される。制御メッセージ受信時のパーソナライズストリーム制御処理は、前述した第１の実施の形態と同じである。端末管理テーブル１２６は、自映像受信端末６の情報のみを管理する。

ストリーム取得プログラム４０５は、映像配信サーバＡ〜Ｃ（２、３、４）から送信される全てのストリームパケットを受信する、受信したストリームパケットは、映像受信端末６の内部処理として、パーソナライズストリーム配信プログラム１２２に渡される。

パーソナライズストリーム配信プログラム１２２は、ストリームパケットを受信すると、前述した第１の実施の形態と同様に、ステップ１０１２及び１０１３（図１５）でストリームパケットを選択する。選択されたストリームパケットは、回線へ出力されず、映像受信端末６の内部処理として（例えば、メモリを介して）、ストリーム取得プログラム４０５に渡される。ストリーム取得プログラム４０５は、パーソナライズストリーム配信プログラム１２２から渡されたストリームパケットから映像データを取得し、取得したストリームパケットをストリーム表示プログラム４０６へ渡す。ストリーム表示プログラム４０６は、ストリームパケットを表示画面に表示する。

以上説明したように、本発明の第３の実施の形態では、映像中継サーバ１に備わる機能を映像受信端末６に配置したので、映像中継サーバが設けられていない映像配信システムにおいても、映像ストリームを切り換えることができる。

＜実施形態４＞
次に、本発明の第４の実施の形態について説明する。

第４の実施の形態では、映像中継サーバ１が、メタデータの通知ごとにストリームを切り換えて、ダイジェストストリームを配信する例について説明する。

第４の実施の形態の映像配信システム及び各装置の構成は、前述した第１の実施の形態と同じである。

図２６は、本発明の第４の実施の形態の映像ストリームの切り換え処理のシーケンス図である。

第４の実施の形態において、映像受信端末６から制御メッセージを受信した場合の映像中継サーバ１による処理、及び、ストリームパケットを受信した場合の映像中継サーバ１による処理は、前述した第１の実施の形態と同じである。

映像中継サーバ１は、メタデータ通知を受信すると、メタデータ解析プログラム１２３を実行することによって、メタデータ解析処理１２３を行う。第４の実施の形態例では、メタデータ解析処理（図１７）のステップ１１０５においてキーワードを比較せず、メタデータ通知を受信する毎に、端末管理テーブル１２６の切換フラグ５０５を”ＯＮ”に設定し、変更先ストリーム５０６及び変更シーケンス番号５０７を登録する。

その結果、映像中継サーバ１は、メタデータが通知されるごとにパーソナライズストリームを切り換えることができる。

その他の処理は、前述した第１の実施の形態と同じである。

以上説明したように、本発明の第４の実施の形態では、映像中継サーバ１は、メタデータが通知されるごとにパーソナライズストリームを切り換えることによって、各映像配信サーバＡ〜Ｃ（２〜４）から配信される映像ストリームのダイジェストストリームを映像受信端末に配信することができる。

本発明の第１の実施の形態の映像配信システムの構成を示すシステム構成図である。 本発明の第１の実施の形態の映像中継サーバの構成を示すブロック図である。 本発明の第１の実施の形態の映像中継サーバのメモリ内の構成を示す説明図である。 本発明の第１の実施の形態の端末管理テーブルの構成例を示す説明図である。 本発明の第１の実施の形態のストリーム管理テーブルの構成例を示す説明図である。 本発明の第１の実施の形態の映像配信サーバＡ〜Ｃのメモリ内の構成を示す説明図である。 本発明の第１の実施の形態のストリームパケット生成処理のフローチャートである。 本発明の第１の実施の形態のＲＴＰヘッダの構成を示す説明図である。 本発明の第１の実施の形態によって生成され回線に出力されたＩＰパケットの構成例を示す説明図である。 本発明の第１の実施の形態のメタデータサーバのメモリ内の構成を示す説明図である。 本発明の第１の実施の形態のメタデータ通知の構成例を示す。 本発明の第１の実施の形態の映像受信端末のメモリ内の構成を示す説明図である。 本発明の第１の実施の形態の映像ストリームの切り換え処理のシーケンス図である。 本発明の第１の実施の形態のパーソナライズストリーム制御処理のフローチャートである。 本発明の第１の実施の形態のパーソナライズストリーム処理のフローチャートである。 本発明の第１の実施の形態のＲＴＰパケットが格納されたバッファの構成を示す説明図である。 本発明の第１の実施の形態のメタデータ解析処理のフローチャートである 本発明の第１の実施の形態のパーソナライズストリームの説明図である。 本発明の第２の実施の形態のストリームパケット生成処理のフローチャートである。 本発明の第２の実施の形態のＲＴＰの拡張ヘッダの構成を示す説明図である。 本発明の第２の実施の形態のパーソナライズストリーム配信処理のフローチャートである。 本発明の第２の実施の形態の映像ストリームの切り換え処理のシーケンス図である。 本発明の第２の実施の形態のパーソナライズストリームの説明図である。 本発明の第３の実施の形態の映像配信システムの構成を示すシステム構成図である。 本発明の第３の実施の形態の映像ストリームの切り換え処理のシーケンス図である。 本発明の第４の実施の形態の映像ストリームの切り換え処理のシーケンス図である。

符号の説明

１ 映像中継サーバ
２ 映像配信サーバＡ
３ 映像配信サーバＢ
４ 映像配信サーバＣ
５ メタデータ配信サーバ
６ 映像受信端末
１１ ＣＰＵ
１２ メモリ
１３ バス
１４、１５ インタフェース
１６、１７ 回線
１２１ パーソナライズストリーム制御プログラム
１２２ パーソナライズストリーム配信プログラム
１２３ メタデータ解析プログラム
１２４ マルチキャスト制御プログラム
１２５ バッファ
１２６ 端末管理テーブル
１２７ ストリーム管理テーブル
４０１ 映像取得プログラム
４０２ ストリームパケット生成プログラム
４０３ ストリーム取得プログラム
４０４ メタデータ生成プログラム
４０５ ストリーム取得プログラム
４０６ ストリーム表示プログラム

Claims (17)

1. 映像ストリームを送信する映像配信装置と、
   前記映像配信装置から送信された映像ストリームをバッファに蓄積し、選択された前記映像ストリームを映像受信端末に転送する映像中継装置と、を備える映像配信システムにおいて、
   前記映像配信装置は、前記映像ストリームの再生可能な単位を示す区切情報を付加して前記映像ストリームを送信し、
   前記映像中継装置は、前記転送される映像ストリームを前記区切情報の箇所のみで切り換えることを特徴とする映像配信システム。
2. 前記配信システムは、さらに、前記映像配信装置から送信された映像ストリームに関する情報を送信するメタデータ配信装置を備え、
   前記メタデータ配信装置は、前記映像ストリームに含まれる被写体の情報、及び、この被写体の情報に対応する映像ストリームの場所の情報を含むメタデータを送信し、
   前記映像中継装置は、
   前記メタデータ配信装置から送信されたメタデータ、及び、前記映像ストリームに含まれる被写体の情報を含み、前記映像受信装置から送信された映像送信要求を受信し、
   前記受信したメタデータを参照して、前記受信した映像送信要求に合致する映像ストリームが配信されているか否かを判定し、
   前記受信した映像送信要求に合致する映像ストリームが配信されている場合には、現在転送中の第１の映像ストリームを前記区切情報によって特定される映像まで転送し、前記切換先の第２の映像ストリームを前記区切情報によって特定される映像から転送することを特徴とする請求項１に記載の映像配信システム。
3. 前記映像中継装置は、
   前記第２の映像ストリームのデータを前記バッファに格納し、
   前記第２の映像ストリームの区切情報を受信した場合に、前記バッファに格納された第２の映像ストリームのデータを消去することを特徴とする請求項２に記載の映像配信システム。
4. 前記映像ストリームは、少なくとも、フレーム間の予測を使わずに単独で再生可能な第１のフレーム、及び、他のフレームからの順方向の予測のみによって再生可能な第２のフレームを含み、
   前記映像中継装置は、前記第１のフレームの直前又は前記第２のフレームの直前まで前記第１の映像ストリームを転送し、前記第１のフレームから前記第２の映像ストリームを転送することを特徴とする請求項２に記載の映像配信システム。
5. 前記被写体の情報に対応する映像ストリームの場所の情報は、前記被写体が写り始める映像のＲＴＰシーケンス番号を含むことを特徴とする請求項２に記載の映像配信システム。
6. 前記映像配信装置は、ＲＴＰパケットによって前記映像ストリームを送信し、
   前記区切情報は、前記ＲＴＰパケットのヘッダ部に含まれることを特徴とする請求項１に記載の映像配信システム。
7. 前記映像配信装置は、フレーム間の予測を使わずに単独で生成可能なフレームが、配信すべき映像ストリーム中に検出された場所に、前記区切情報を付加することを特徴とする請求項１に記載の映像配信システム。
8. 映像配信装置から送信された映像ストリームをバッファに蓄積し、選択された前記映像ストリームを映像受信端末に転送する映像中継装置であって、
   前記映像配信装置は、前記映像ストリームの再生可能な単位を示す区切情報を付加して前記映像ストリームを送信し、
   前記映像中継装置は、
   前記映像ストリームに含まれる被写体の情報、及び、この被写体の情報に対応する映像ストリームの場所の情報を含むメタデータを送信するメタデータ配信装置に接続され、
   前記メタデータ配信装置から送信されたメタデータ、及び、前記映像ストリームに含まれる被写体の情報を含み、前記映像受信装置から送信された映像送信要求を受信し、
   前記受信したメタデータを参照して、前記受信した映像送信要求に合致する映像ストリームが配信されているか否かを判定し、
   前記受信した映像送信要求に合致する映像ストリームが配信されている場合には、現在転送中の第１の映像ストリームを前記区切情報によって特定される映像まで転送し、前記切換先の第２の映像ストリームを前記区切情報によって特定される映像から転送することを特徴とする映像中継装置。
9. 前記第２の映像ストリームのデータを前記バッファに格納し、
   前記第２の映像ストリームの区切情報を受信した場合に、前記バッファに格納された第２の映像ストリームのデータを消去することを特徴とする請求項８に記載の映像中継装置。
10. 前記映像ストリームは、少なくとも、フレーム間の予測を使わずに単独で再生可能な第１のフレーム、及び、他のフレームからの順方向の予測のみによって再生可能な第２のフレームを含み、
    前記映像中継装置は、前記第１のフレームの直前又は前記第２のフレームの直前まで前記第１の映像ストリームを転送し、前記第１のフレームから前記第２の映像ストリームを転送することを特徴とする請求項８に記載の映像中継装置。
11. 前記被写体の情報に対応する映像ストリームの場所の情報は、前記被写体が写り始める映像のＲＴＰシーケンス番号を含むことを特徴とする請求項８に記載の映像中継装置。
12. 前記映像配信装置からＲＴＰパケットによって送信された前記映像ストリームを受信し、
    前記ＲＴＰパケットのヘッダ部から前記区切情報を抽出することを特徴とする請求項８に記載の映像中継装置。
13. 映像ストリームを送信する映像配信装置と、
    前記映像配信装置から送信された映像ストリームをバッファに蓄積し、選択された前記映像ストリームを映像受信端末に転送する映像中継装置と、
    前記映像配信装置から送信された映像ストリームに関する情報を送信するメタデータ配信装置と、を備える映像配信システムにおける映像中継方法であって、
    前記映像配信装置は、前記映像ストリームの再生可能な単位を示す区切情報を付加して前記映像ストリームを送信し、
    前記メタデータ配信装置は、前記映像ストリームに含まれる被写体の情報、及び、この被写体の情報に対応する映像ストリームの場所の情報を含むメタデータを送信し、
    前記映像中継装置は、
    前記メタデータ配信装置から送信されたメタデータ、及び、前記映像ストリームに含まれる被写体の情報を含み、前記映像受信装置から送信された映像送信要求を受信し、
    前記受信したメタデータを参照して、前記受信した映像送信要求に合致する映像ストリームが配信されているか否かを判定し、
    前記受信した映像送信要求に合致する映像ストリームが配信されている場合には、現在転送中の第１の映像ストリームを前記区切情報によって特定される映像まで転送し、前記切換先の第２の映像ストリームを前記区切情報によって特定される映像から転送することを特徴とする映像中継方法。
14. 前記映像中継装置は、
    前記第２の映像ストリームのデータを前記バッファに格納し、
    前記第２の映像ストリームの区切情報を受信した場合に、前記バッファに格納された第２の映像ストリームのデータを消去することを特徴とする請求項１３に記載の映像中継方法。
15. 前記映像ストリームは、少なくとも、フレーム間の予測を使わずに単独で再生可能な第１のフレーム、及び、他のフレームからの順方向の予測のみによって再生可能な第２のフレームを含み、
    前記映像中継装置は、前記第１のフレームの直前又は前記第２のフレームの直前まで前記第１の映像ストリームを転送し、前記第１のフレームから前記第２の映像ストリームを転送することを特徴とする請求項１３に記載の映像中継方法。
16. 前記被写体の情報に対応する映像ストリームの場所の情報は、前記被写体が写り始める映像のＲＴＰシーケンス番号を含むことを特徴とする請求項１３に記載の映像中継方法。
17. 前記映像配信装置は、ＲＴＰパケットによって前記映像ストリームを送信し、
    前記映像中継装置は、前記ＲＴＰパケットのヘッダ部から前記区切情報を抽出することを特徴とする請求項１３に記載の映像中継方法。

Images