JP5428734B2 - ネットワーク機器、情報処理装置、ストリーム切替方法、情報処理方法、プログラムおよびコンテンツ配信システム - Google Patents

Description

本発明は、ネットワーク機器、情報処理装置、ストリーム切替方法、情報処理方法、プログラムおよびコンテンツ配信システムに関する。

ＩＰネットワークを利用した映像配信システムであるＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）は、ＭＰＥＧ２やＨ．２６４／ＡＶＣ等の高能率映像符号化技術を利用して圧縮した映像を、ＩＰマルチキャストにて複数に端末に配信することで、従来の電波を利用したＴＶシステムと同等のサービスを実現できる。

しかしながら、ＩＰＴＶシステムは、そのシステムの特性上、チャンネル切り替えに要する時間が１〜３秒程度必要であり、通常のデジタルテレビ放送などと比較しても、チャンネル切り替えに要する時間が遅いという問題があった。

この問題は、以下で説明するような２つの問題点に起因する。第１の問題点は、アクセスネットワークに配信するデータの切り替え制御に時間を要するという問題点である。これは、ＩＰＴＶシステムは、サービス加入者宅までのアクセスネットワークが限られた帯域のネットワーク（例えば、ＡＤＳＬ２の場合では１０Ｍｂｐｓ程度）であって、アクセスネットワークには端末が受信しているチャンネルのデータのみ伝送する方式を採用しているために、生じる問題である。

第２の問題点は、限られたデータ帯域のアクセスネットワークでチャンネルのデータを配信するために、圧縮映像、例えばＭＰＥＧ２のＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）長をデジタル放送に比べても長めにせざる得ないため、切り替えたチャンネルのＭＰＥＧ２ストリームＧＯＰ先頭のＩピクチャ（ＡＶＣの場合はＩＤＲピクチャー）を受信するまで待たされるという問題である。

これらの問題に対して、ＩＰＴＶでチャンネル切り替えを高速化するための手段として、以下に示すような２つの方法が提案されている。第１の方式は、チャンネルの映像信号を低解像度でエンコードして低ビットレートにした圧縮データをチャンネル切り替え用のストリームとして同時に端末に配信する方法である（例えば、特許文献１および特許文献２を参照。）。この方法では、チャンネル切り替え時に低ビットレートの圧縮データを表示させた後、本来の解像度のビットレートの圧縮データ方式の表示に切り替えを行う。第２の方法は、アクセスネットワーク近傍にＩピクチャ（ＩＤＲピクチャ）をキャッシュ、バッファリングするサーバを配置し、チャンネル切り替え時には、一時的に端末にユニキャストでそのサーバからＩピクチャを高速伝送して表示させる方式（例えば、特許文献３を参照。）である。

国際公開第０４／１１４６６７号パンフレット 国際公開第０４／１１４６６８号パンフレット 米国特許出願公開第２００５／００８１２４４号明細書

しかしながら、特許文献１および特許文献２に記載の方式では、チャンネル切り替え用の映像は低解像度のために品質が悪いという問題がある。また、特許文献３に記載の方式では、特殊なサーバをアクセスネットワークの近傍に配置する必要があり、システム全体が大きくなるに比例して機材コストが掛かり、システムも複雑なため運用コストが増大するという問題がある。

また、双方の方式とも、チャンネル切り替え時のプロトコルやデータストリーム切り替えのための仕組みが複雑であり、端末の再生システム実装が難しいという問題があった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、既存のネットワーク機器や端末の再生システムを大幅に変更することなく、簡易な方法でＩＰＴＶシステムにおけるチャンネル切り替えの高速化を実現することが可能な、ネットワーク機器、情報処理装置、ストリーム切替方法、情報処理方法、プログラムおよびコンテンツ配信システムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームをそれぞれ解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するストリーム解析部と、前記映像音声コンテンツを再生する情報処理装置から送信された映像音声コンテンツの配信要求を受信するとともに、前記ストリーム解析部により検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択する配信要求処理部と、前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記配信要求処理部により選択された前記圧縮データストリームへと切り替える配信切替部と、を備えるネットワーク機器が提供される。

前記配信要求処理部は、前記基準圧縮映像データが配信されてから次の前記基準圧縮映像データが配信されるまでの時間間隔に関する情報を保持しており、前記ストリーム解析部により検出された最も新しい基準圧縮映像データの配信時刻と、前記時間間隔に関する情報とに基づいて、前記複数の圧縮データストリームそれぞれについて次に前記基準圧縮映像データが配信される時刻を算出し、算出した時刻までの時間が最も短い前記圧縮データストリームを、前記情報処理装置へ配信する圧縮データストリームとして選択してもよい。

前記配信切替部は、前記配信要求処理部によって算出された時刻までに前記配信要求処理部によって選択された前記圧縮データストリームへの切替が完了するように、当該圧縮データストリームへの切替処理を行ってもよい。

前記ネットワーク機器は、前記配信切替部による前記圧縮データストリームの切替処理に要する遅延時間分の圧縮データストリームを一時的に記憶するバッファを更に備え、前記配信切替部は、前記バッファに格納されている前記圧縮データストリームを前記情報処理装置へと配信しつつ、前記圧縮データストリームの切替処理を行ってもよい。

また、上記課題を解決するために、本発明の別の観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時間が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームの配信切替を行うネットワーク機器に対して、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を要求し、前記ネットワーク機器から前記映像音声コンテンツを取得するコンテンツ取得部を備える情報処理装置が提供される。

前記複数の圧縮データストリームには、互いに異なる固有のネットワークアドレスが割り当てられており、前記コンテンツ取得部は、取得すべき前記映像音声コンテンツに対応する全ての前記圧縮データストリームに割り当てられたネットワークアドレスを前記ネットワーク機器に対して通知し、前記ネットワーク機器に通知したネットワークアドレスのうち、当該ネットワーク機器から配信された前記圧縮データストリームに割り当てられた前記ネットワークアドレスを、前記取得すべき前記映像音声コンテンツに対応するネットワークアドレスとして設定することが好ましい。

上記課題を解決するために、本発明の更に別の観点によれば、ネットワーク機器のストリーム解析部が、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームをそれぞれ解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するステップと、ネットワーク機器の配信要求処理部が、前記映像音声コンテンツを再生する情報処理装置から送信された映像音声コンテンツの配信要求を受信するステップと、ネットワーク機器の配信要求処理部が、前記基準圧縮映像データが配信された時刻を検出するステップにて検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択するステップと、ネットワーク機器の配信切替部が、前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記圧縮データストリームを選択するステップにより選択された前記圧縮データストリームへと切り替えるステップと、を含むストリーム切替方法が提供される。

上記課題を解決するために、本発明の更に別の観点によれば、情報処理装置のコンテンツ取得部が、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームの配信切替を行うネットワーク機器に対して、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を要求するステップと、情報処理装置のコンテンツ取得部が、前記ネットワーク機器から配信された前記映像音声コンテンツに対応する前記圧縮データストリームを取得するステップと、を含む情報処理方法が提供される。

上記課題を解決するために、本発明の更に別の観点によれば、コンピュータに、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームをそれぞれ解析して、最も新しい前記基準圧縮映像データが配信された時刻を検出するストリーム解析機能と、前記映像音声コンテンツを再生する情報処理装置から送信された映像音声コンテンツの配信要求を受信するとともに、前記ストリーム解析機能により検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択する配信要求処理機能と、前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記配信要求処理機能により選択された前記圧縮データストリームへと切り替える配信切替機能と、を実現させるためのプログラムが提供される。

上記課題を解決するために、本発明の更に別の観点によれば、コンピュータに、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームの配信切替を行うネットワーク機器に対して、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を要求し、前記ネットワーク機器から前記映像音声コンテンツを取得するコンテンツ取得機能を実現させるためのプログラムが提供される。

上記課題を解決するために、本発明の更に別の観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部を有するコンテンツサーバと、前記コンテンツサーバが配信する複数の配信された前記映像音声コンテンツに対応する前記圧縮データストリームを再生する情報処理装置と、１または複数の前記コンテンツサーバから配信された前記複数の圧縮データストリームを、当該圧縮データストリームの配信を希望する前記情報処理装置へと配信するネットワーク機器と、を含み、前記ネットワーク機器は、１または複数の前記コンテンツサーバから配信された前記複数の圧縮データストリームを解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するストリーム解析部と、前記情報処理装置から送信された映像音声コンテンツの配信要求を受信するとともに、前記ストリーム解析部により検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択する配信要求処理部と、前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記配信要求処理部により選択された前記圧縮データストリームへと切り替える配信切替部と、を有し、前記情報処理装置は、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を前記ネットワーク機器に要求し、前記ネットワーク機器から前記映像音声コンテンツを取得するコンテンツ取得部を有する、コンテンツ配信システムが提供される。

以上説明したように本発明によれば、既存のネットワーク機器や端末の再生システムを大幅に変更することなく、簡易な方法でＩＰＴＶシステムにおけるチャンネル切り替えの高速化を実現することが可能である。

本発明の第１の実施形態に係るコンテンツ配信システムを説明するための説明図である。 同実施形態に係るコンテンツサーバの構成を説明するためのブロック図である。 同実施形態に係る情報処理装置の構成を説明するためのブロック図である。 同実施形態に係るスイッチの構成を説明するためのブロック図である。 同実施形態に係るコンテンツサーバから出力されるＭＰＥＧ２−ＴＳストリーム中のＩＤＲピクチャの位置関係を説明するための説明図である。 同実施形態に係るコンテンツサーバが送出するＵＤＰパケットのフォーマットを説明するための説明図である。 ＤＶＢ−ＩＰのブロードキャストディスカバリーレコードのデータ形式を説明するための説明図である。 ブロードキャストディスカバリーレコードをＸＭＬ表記した場合の例を説明するための説明図である。 同実施形態に係る情報処理方法を説明するための流れ図である。 ＩＧＭＰメッセージのフォーマットを説明するための説明図である。 ＩＧＭＰメッセージのフォーマットを説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るチャンネル選局処理を説明するための流れ図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。 同実施形態に係るチャンネル受信終了処理を説明するための流れ図である。 同実施形態に係るストリームの切替処理について説明するための流れ図である。 同実施形態に係るストリームの切替処理について説明するための説明図である。 同実施形態に係るストリームの切替処理について説明するための説明図である。 本発明の実施形態に係るコンテンツサーバ、情報処理装置およびスイッチのハードウェア構成について説明するためのブロック図である。 一般的なＩＰＴＶシステムについて説明するための説明図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

なお、説明は、以下の順序で行うものとする。
（１）基盤技術に関する説明
（２）第１の実施形態
（２−１）コンテンツ配信システムについて
（２−２）コンテンツサーバについて
（２−３）情報処理装置について
（２−４）スイッチについて
（２−５）コンテンツ配信方法について
（２−６）情報処理方法について
（２−７）ストリーム切替方法について
（３）本発明の実施形態に係るコンテンツサーバ、情報処理装置およびスイッチのハードウェア構成について
（４）まとめ

（基盤技術に関する説明）
まず、本発明に係る好適な実施形態について詳細な説明をするに先立ち、本実施形態を実現する上で基盤を成す技術的事項について述べる。なお、本実施形態は、以下に記載する基盤技術の上に改良を加えることにより、より顕著な効果を得ることができるように構成されたものである。従って、その改良に係る技術こそが本実施形態の特徴を成す部分である。つまり、本実施形態は、ここで述べる技術的事項の基礎概念を踏襲するが、その本質はむしろ改良部分に集約されており、その構成が明確に相違すると共に、その効果において基盤技術とは一線を画するものであることに注意されたい。

図１９は、一般的なＩＰＴＶシステム９００におけるマルチキャスト映像配信に関するネットワーク構成図である。図１９に示したように、一般的なＩＰＴＶシステム９００は、例えば、それぞれのチャンネルに対応した複数のコンテンツサーバ９０１と、エッジスイッチ９０３，９０９と、ルータ９０５，９０７と、視聴者が使用する複数の端末９１１と、を主に備える。

コンテンツサーバ９０１は、映像音声信号（映像音声コンテンツ）を符号化するエンコーダと、配信サーバとから構成される。各ＴＶチャンネル（例えば、総数３００チャンネルとする。）の映像信号は、例えばＨ．２６４／ＡＶＣを利用してリアルタイムでエンコードされる。また、各ＴＶチャンネルのオーディオ信号は、ＨＥ−ＡＡＣ（Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｃｏｄｉｎｇ）などの高能率音声符号化技術を利用してリアルタイムでエンコードされる。その後、エンコーダは、エンコードした各信号をＭＰＥＧ２−ＴＳ（ＭＰＥＧ２−Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）の形式に多重化した後、ストリームデータとして配信サーバに伝送する。配信サーバは、それら複数のＭＰＥＧ２−ＴＳのパケットをＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）のパケットフォーマットにする。その後、配信サーバは、ＭＰＥＧ２−ＴＳパケットを入れた上でさらにＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）の伝送プロトコルによりＩＰネットワークにマルチキャスト配信する。

各チャンネルのストリームのＩＰパケットは、個別のマルチキャストアドレスが指定され、コアネットワーク、アクセスネットワークを経由して端末９１１に配信される。コアネットワークは、光ファイバーを利用し、ＷＤＭ（Ｗａｖｅｌｅｎｇｔｈ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅｘｉｎｇ）などの技術を用いて、毎秒数ギガ〜数十ギガビットのデータ伝送が可能な広帯域ネットワークが用いられる。他方、ＩＰＴＶサービス加入者宅（すなわち、エッジスイッチ９０９から端末９１１）までのアクセスネットワークは、例えば、既存のアナログ電話回線の銅線配線を利用したＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）などの技術が利用される。ＡＤＳＬにもさまざまな規格があり、データ帯域は回線の長さにも依存する。例えば、ＡＤＳＬ２という規格を用いる場合、基地局から４キロメートル以下であれば毎秒１０メガビット以上の帯域を実現でき、ハイビジョンテレビの解像度の映像信号を一本は配信することが可能である。

このように、コアネットワークは十分な帯域があり、ＩＰＴＶサービスが提供するすべてのチャンネルのストリームを配信できる。他方、アクセスネットワークのデータ帯域は限られているため、アクセスネットワークには、端末が受信しているチャンネルのデータのみを配信する必要がある。このマルチキャストデータの配信制御に、一般にはＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）が利用される。

端末９１１は、受信したいチャンネルのデータのマルチキャストグループに加入するためにＩＧＭＰメッセージをネットワークに送信すると、エッジルータ９０７は要求があったネットワークのみにマルチキャストデータを配信する。ただし、エッジルータ９０７の配下に複数の端末が接続されている場合、エッジルータ９０７は、該当するマルチキャストデータを受信していない端末９１１が接続されたアクセスネットワークに対しても、データを配信してしまう。そこで、ＩＧＭＰによるマルチキャストグループへの加入要求をしていない端末９１１が接続されたアクセスワークへの配信を防ぐ必要がある。そのため、エッジスイッチ９０９であるＤＳＬＡＭ（Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ Ａｃｃｅｓｓ Ｍｕｌｔｉｐｌｅｘｅｒ）などは、ＩＧＭＰ ＳＮＯＯＰＩＮＧが実装されている。ＤＳＬＡＭは、端末９１１から送信されたＩＧＭＰパケットを盗みみて、要求を受けた端末９１１が接続されるアクセスネットワークのみにマルチキャストグループのデータを配信するように、フィルタリング制御をなっている。

本発明の各実施形態に係るＩＰＴＶシステムは、上述のような一般的なアーキテクチャーのＩＰＴＶシステムを踏襲した上で、なされたものである。以下に、本発明の各実施形態について、詳細に説明する。

（第１の実施形態）
＜コンテンツ配信システムについて＞
まず、図１を参照しながら、本発明の第１の実施形態に係るコンテンツ配信システムについて、詳細に説明する。図１は、本実施形態に係るコンテンツ配信システムを説明するための説明図である。なお、以下の説明では、コンテンツ配信システムの一例として、ＩＰＴＶシステムを例に挙げながら、詳細に説明する。

本実施形態に係るコンテンツ配信システム１は、例えば図１に示したように、それぞれのチャンネルに対応した複数のコンテンツサーバ１０Ａ，１０Ｂ，１０Ｃと、スイッチ１２，３０と、ルータ１４，１６と、視聴者が使用する複数の情報処理装置２０Ａ，２０Ｂ，２０Ｃ，２０Ｄと、を主に備える。

コンテンツサーバ１０は、ＩＰＴＶシステムにおける各チャンネルの放送局に対応しており、映像音声コンテンツ（映像音声信号）を所定の方式で符号化して圧縮データストリームとし、所定の伝送プロトコルを用いて、ＩＰネットワークにマルチキャスト配信する。図１では、コンテンツサーバ１０は、３つしか図示されていないが、コンテンツサーバ１０は、例えばＩＰＴＶシステム上のチャンネル数と同じ数だけ存在し、チャンネル総数が３００である場合には、コンテンツ配信システム１上には、３００台のコンテンツサーバ１０が存在することとなる。

スイッチ１２は、コアネットワーク上を流れるパケットの交換機能（スイッチング機能）を有する通信装置である。スイッチ３０は、アクセスネットワーク上を流れるパケットの交換機能を有する通信装置であり、コアネットワークの周辺にあるため特にエッジスイッチと呼ばれる。これらのスイッチ１２，３０は、パケットの宛先を判断して、特定の相手にのみ通信を取り次ぐように設定されている。

ルータ１４，１６は、ネットワーク上を流れるパケット等のデータを中継する装置である。これらのルータは、いわゆるＯＳＩ参照モデルでいうネットワーク層やトランスポート層の一部のプロトコルを解析して、データの転送を行う。また、ネットワーク層に記載されているアドレスを解析して、どの経路を通じてデータを転送すべきかを判断する経路選択機能を有する。

情報処理装置２０は、コンテンツ配信システム１の視聴者が使用する端末であって、各コンテンツサーバ１０が配信している複数の映像音声コンテンツの中から、視聴したいコンテンツを取得し、取得したコンテンツを再生する。

なお、上述のコンテンツサーバ１０、情報処理装置２０およびスイッチ３０については、以下で改めて詳細に説明する。

以上、本実施形態に係るコンテンツ配信システム１について、説明を行った。続いて、図２〜図４を参照しながら、本実施形態に係るコンテンツサーバ１０、情報処理装置２０およびスイッチ３０について、詳細に説明する。

＜コンテンツサーバの構成について＞
次に、図２を参照しながら、本実施形態に係るコンテンツサーバ１０の構成について、詳細に説明する。図２は、本実施形態に係るコンテンツサーバ１０の構成について説明するためのブロック図である。

本実施形態に係るコンテンツサーバ１０は、例えば図２に示したように、第１処理部１１Ａと、第２処理部１１Ｂと、を備える。第１処理部１１Ａおよび第２処理部１１Ｂには、同一のチャンネルの映像音声信号がそれぞれ入力される。

第１処理部１１Ａは、図２に示したように、例えば、第１符号化部１０１と、第１配信部１０５と、記憶部１０９と、を主に備える。また、第２処理部１１Ｂは、図２に示したように、例えば、第２符号化部１０３と、第２配信部１０７と、記憶部１１１と、を主に備える。

図２に示したように、第１処理部１１Ａおよび第２処理部１１Ｂは、一つの符号化部および一つの配信部からなる組を少なくとも１つ備える処理部であり、各符号化部および各配信部は、それぞれ互いに独立して機能する。

第１符号化部１０１および第２符号化部１０３は、例えば、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）により実現される。第１符号化部１０１および第２符号化部１０３は、入力された映像音声信号のうち、映像信号を、例えばＨ．２６４／ＡＶＣを利用してリアルタイムで符号化（以下、エンコードとも称する。）するとともに、音声信号を、例えばＨＥ−ＡＡＣ等の高能率音声符号化技術を利用してリアルタイムでエンコードする。続いて、第１符号化部１０１および第２符号化部１０３は、エンコードした各信号をＭＰＥＧ２−ＴＳの形式に多重化した後、圧縮データストリームとして第１配信部１０５および第２配信部１０７に伝送する。

ここで、第１符号化部１０１および第２符号化部１０３は、それぞれ互いに、基準圧縮データが対応する元映像信号の映像フレーム（通常、３０フレーム毎秒）またはフィールド（６０フィールド毎秒）の位置が互いに異なるように、映像音声信号のうちの映像信号を符号化する。ここで、基準圧縮映像データは、この圧縮映像データよりも時間的に前の圧縮映像データを参照することなく、復号可能な圧縮映像データを意味している。第１符号化部１０１および第２符号化部１０３は、圧縮データストリームの途中から符号化が可能なように、基準圧縮映像データが定期的に出現するようエンコードを行う。このような基準圧縮映像データの例として、例えば、Ｈ．２６４／ＡＶＣでのＩＤＲ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ：デコーダ復号動作の瞬時リフレッシュ）ピクチャや、ＭＰＥＧ２ビデオでのＩピクチャ（Ｉｎｔｒａ ｐｉｃｔｕｒｅ：ピクチャ内符号化ピクチャ）を挙げることができる。

例えば、ハイビジョンの映像を、Ｈ．２６４／ＡＶＣにてエンコードする場合を考える。この際、第１符号化部１０１および第２符号化部１０３は、毎秒３０枚のＭＰＥＧピクチャから構成され、ＩＤＲピクチャが１秒に一回出現するように映像信号をエンコードする。このような符号化処理を行うことで、ビデオのビットレートが最大毎秒７メガビットであっても、ＩＤＲピクチャを１秒に２回出現するようにエンコードするより、再生映像をより高画質なものとすることができる。なお、ＭＰＥＧ２ビデオのＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）の表記に従い、本明細書では、ＩＤＲピクチャを先頭に含む複数のピクチャのまとまりを、ＧＯＰと示すこととする。

第１符号化部１０１および第２符号化部１０３それぞれは、基準圧縮映像データが出現するタイミング以外の条件が同一となるように、映像音声信号を符号化する。例えば、第１符号化部１０１および第２符号化部１０３は、互いに同じＭＰＥＧピクチャの数、解像度により同一の映像信号をエンコードする。また、各符号化部１０１，１０３から出力されるＭＰＥＧストリームは、ＭＰＥＧ２−ＴＳにマルチプレックされた時点で、最大毎秒８メガビットになるように出力される。この場合、２つのＭＰＥＧ２−ＴＳのＩＤＲピクチャは、１秒ごと（すなわち、ＧＯＰ長３０フレーム）に出現するようになるが、ＩＤＲピクチャは０．５秒間（つまり１５ピクチャー）分ずらして生成されるように、第１符号化部１０１および第２符号化部１０３はそれぞれ設定される。

なお、第１符号化部１０１および第２符号化部１０３は、映像音声信号の符号化に際して、それぞれ後述する記憶部１０９および記憶部１１１に記録されている各種のデータベース等を参照することが可能である。また、第１符号化部１０１および第２符号化部１０３は、生成した圧縮データストリームを、それぞれ記憶部１０９および記憶部１１１に記録してもよい。

第１配信部１０５および第２配信部１０７は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等により実現されるものであり、いわゆるＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）サーバの機能を有している。第１配信部１０５および第２配信部１０７は、それぞれ第１符号化部１０１および第２符号化部１０３が生成したＭＰＥＧ２−ＴＳのパケットを、ＲＴＰパケットおよびＵＤＰパケットに格納した上で、ＩＰマルチキャストパケットに格納して、送信する。これらのＩＰパケットは、例えば、スイッチ１２等を経由して、ＩＰネットワークにより配信される。

記憶部１０９は、本実施形態に係る第１処理部１１Ａが、何らかの処理を行う際に保存する必要が生じた様々なパラメータや処理の途中経過等、または、各種のデータベース等が、適宜記録される。記憶部１０９は、第１符号化部１０１および第１配信部１０５等が、自由に読み書きを行うことが可能である。

同様に、記憶部１１１には、本実施形態に係る第２処理部１１Ｂが、何らかの処理を行う際に保存する必要が生じた様々なパラメータや処理の途中経過等、または、各種のデータベース等が、適宜記録される。記憶部１１１は、第２符号化部１０３および第２配信部１０７等が、自由に読み書きを行うことが可能である。

なお、図２に示した例では、本実施形態に係るコンテンツサーバ１０が第１処理部１１Ａと第２処理部１１Ｂの２つの処理部から構成される場合について説明したが、コンテンツサーバ１０は、３つ以上の処理部から構成されていてもよい。一つのチャンネル（換言すれば、一つの映像音声信号）に割り当てる処理部の数が多いほど、高速なチャンネル切り替えを実現することが可能となる。

また、第１処理部１１Ａおよび第２処理部１１Ｂは、１台のコンテンツサーバの筐体内に設けられていてもよい。また、一つの符号化部と一つの配信部とを備える処理部が一つの装置として独立しており、この装置が並列に複数台接続されていてもよい。

以上、本実施形態に係るコンテンツサーバ１０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。

なお、上述のような本実施形態に係るコンテンツサーバの各機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

＜情報処理装置の構成について＞
続いて、図３を参照しながら、本実施形態に係る情報処理装置２０の構成について、詳細に説明する。図３は、本実施形態に係る情報処理装置２０の構成を説明するためのブロック図である。

本実施形態に係る情報処理装置２０は、例えば図３に示したように、チャンネル選択部２０１と、コンテンツ取得部２０３と、コンテンツ再生部２０５と、記憶部２０７と、を主に備える。

チャンネル選択部２０１は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等により実現される。ユーザが、情報処理装置２０に設けられたチャンネル選択スイッチ、チャンネル選択ボタン等の操作部や、リモートコントローラ等を操作して、配信されている複数のチャンネルの中から特定のチャンネルを選択した場合に、チャンネル選択部２０１は、チャンネル選択スイッチやチャンネル選択ボタン等による入力を所定の信号に変換する。また、チャンネル選択部２０１は、ユーザ入力を変換した所定の信号を、後述するコンテンツ取得部２０３に出力する。

コンテンツ取得部２０３は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等により実現されるものであり、配信されている複数のチャンネルの中から、チャンネル選択部２０１から伝送された信号に対応したチャンネルが配信しているコンテンツを取得する。本実施形態に係るコンテンツ配信システムでは、１つのチャンネルに属するコンテンツに対して、複数の圧縮データストリームが配信されている。そのため、コンテンツ取得部２０３は、ユーザにより選択されたチャンネルに対応する全ての圧縮データストリームの配信を、後述するスイッチ３０に要求する。

スイッチ３０では、コンテンツ取得部２０３から伝送されたストリームの配信要求に基づいて、対応するチャンネルに該当する複数の圧縮データストリームの中から、配信要求のあった情報処理装置２０に配信するストリームを選択し、この情報処理装置２０へ配信する。スイッチ３０は、複数の圧縮データストリームの中から配信するストリームを選択する際に、チャンネル切り替え時間が短くなるように最適な圧縮データストリームを選択するが、かかるストリームの選択については、以下で改めて詳細に説明する。

コンテンツ取得部２０３は、スイッチ３０から配信された圧縮データストリームを取得することで、コンテンツの取得を行うことができる。コンテンツ取得部２０３は、取得したコンテンツ（より詳細には、コンテンツに対応する圧縮データストリーム）を、後述するコンテンツ再生部２０５に伝送する。

なお、コンテンツの取得に際して、コンテンツ取得部２０３は、後述する記憶部２０７に記録されている各種のデータベース等を参照しながら、コンテンツの取得処理を実行することが可能である。

コンテンツ再生部２０５は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等により実現されるものであり、コンテンツ取得部２０３が取得したコンテンツを再生して、情報処理装置２０が備える表示部（図示せず。）に表示する。ここで、コンテンツの再生とは、コンテンツ取得部２０３から伝送された圧縮データストリームの復号を行った上で、復号されたコンテンツを再生すること、および、圧縮データストリームの復号を行いながら、コンテンツを再生することを含む。コンテンツ再生部２０５は、コンテンツの復号やコンテンツの再生を行う際に、後述する記憶部２０７に記録されているデータベース等を参照することが可能である。

記憶部２０７は、本実施形態に係る情報処理装置２０が、何らかの処理を行う際に保存する必要が生じた様々なパラメータや処理の途中経過等、または、各種のデータベース等が、適宜記録される。記憶部２０７は、チャンネル選択部２０１、コンテンツ取得部２０３、コンテンツ再生部２０５等が、自由に読み書きを行うことが可能である。

以上、本実施形態に係る情報処理装置２０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。

なお、上述のような本実施形態に係る情報処理装置の各機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

＜スイッチの構成について＞
続いて、図４を参照しながら、本実施形態に係るネットワーク機器の一例であるスイッチ３０の構成について、詳細に説明する。図４は、本実施形態に係るスイッチ３０の構成を説明するためのブロック図である。

上述のように、スイッチ３０には、コンテンツ配信システム１内で配信されている全てのチャンネルの複数の圧縮データストリーム全てが配信されている。スイッチ３０は、これら複数の圧縮データストリームを解析することにより、現在スイッチ３０が受信しているＵＤＰからＩＤＲピクチャが開始されるか否かを判断し、最適なストリームを情報処理装置２０に配信することができる。この圧縮データストリームの解析は、ＭＰＥＧ−ＴＳパケットを解析することで行う。ＤＶＢ−ＩＰなどの規定では、ＩＤＲピクチャの出現の前にＭＰＥＧ−ＴＳのＳｙｓｔｅｍ ｈｅａｄｅｒが置かれるため、スイッチ３０は、Ｓｙｓｔｅｍ ｈｅａｄｅｒを検出することで、より簡易にストリームの解析処理を行うことが可能である

本実施形態に係るスイッチ３０は、例えば図４に示したように、バッファ３０１と、ストリーム解析部３０３と、配信要求処理部３０５と、配信切替部３０７とを主に備える。

バッファ３０１は、コンテンツ配信システム１内で配信されている全てのチャンネルの全ての圧縮データストリーム（より具体的にはＩＰパケット）の一部が、一時的に保存される。バッファ３０１にて一時的に保存された圧縮データストリームは、その後、後述する配信切替部３０７に送出される。また、このバッファ３０１に一時的に保存される圧縮データストリームの一部は、後述するストリーム解析部３０３におけるストリームの解析処理に利用される。

例えば、ＩＤＲピクチャが３０フレーム分ずれている場合を考える。
一般的には、ＩＤＲピクチャが存在するＩＰパケットから次のＩＤＲピクチャの直前のＩＰパケットまでデータをバッファリングすれば、その間にＩＧＭＰによる配信要求があった場合は、そのＩＤＲピクチャの配信を行うことができる。本実施形態では、チャンネルの２つのストリームのＧＯＰはＧＯＰの半分（すなわち１５フレーム分）だけずれている。また、スイッチは、端末に対していずれかのストリームのデータを配信すればよいため、バッファは１５フレーム分の容量があれば十分であると考えることもできる。ストリームが例えば８Ｍｂｐｓであるとすると、一つのストリームあたり０．５Ｍバイトのバッファ、すなわち、チャンネル当たり１Ｍバイトのバッファが必要となる。そのため、コンテンツ配信システム内の全てのチャンネルについて、上述のようなバッファ容量を確保すると、全体のバッファ容量が非常に大きな量となるため、好ましくない。また、かかるバッファリングを行った場合には、バッファリングに起因する配信遅延が生じる可能性もある。

そこで、本実施形態に係るスイッチ３０では、このバッファリングによる遅延を解決するために、後述するストリーム解析部３０３において、以下のようなストリームの解析処理を行う。これにより、１ストリーム当たりのバッファ容量を、後述する配信切替部３０７による切替処理に要する遅延時間分の圧縮データストリームを一時的に記憶可能な量（例えば、数十ミリ秒程度）に抑制することが可能となる。また、ストリームの解析処理の種類によっては、後述するように、バッファ３０１を設けることなく、配信遅延のないストリームの切り換えを実現することも可能である。

ストリーム解析部３０３は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ等により実現される。ストリーム解析部３０３は、スイッチ３０に配信される複数の圧縮データストリームをそれぞれ解析して、基準圧縮映像データ（例えば、ＩＤＲピクチャ）が配信された最も新しい時刻を検出し、検出した最新の基準圧縮映像データの配信時刻を記憶する。また、ストリーム解析部３０３は、後述する配信要求処理部３０５から、あるチャンネルに関する最新の配信時刻の問い合わせがあった場合に、その時点で記憶している該当チャンネルの配信時刻を、配信要求処理部３０５に出力する。このストリームの解析処理は、先述のように、ＭＰＥＧ−ＴＳパケットを解析することによって行う。

配信要求処理部３０５は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等により実現される。配信要求処理部３０５は、情報処理装置２０から送信された映像音声コンテンツの配信要求を受信する。また、配信要求処理部３０５は、ストリーム解析部３０３により検出された最新の配信時刻を利用して、配信要求に関する映像音声コンテンツに対応する複数の圧縮データストリームの中から、情報処理装置２０へ配信する圧縮データストリームを選択する。すなわち、配信要求処理部３０５は、ＩＧＭＰスヌーピング機能を有しており、情報処理装置２０から配信されたＩＧＭＰパケットを受信して、ＩＧＭＰパケットを送信した情報処理装置２０のみへ、選択した圧縮データストリームが配信されるように制御する。

スイッチ３０に到着したＩＰパケットがストリーム解析部３０３によりＳｙｓｔｅｍ Ｈｅａｄｅｒを含んでいると判定された場合を考える。システムヘッダを含むと判定されたストリームを直ちに情報処理装置２０に配信したとしても、切り換え処理の間に時間が経過してしまい、切り換えが完了した時点では、切り換え後のストリームにはＩＤＲピクチャを含まない。そのため、このような切り換え処理は、チャンネルスイッチには不適応な処理であるといえる。

そこで、配信要求処理部３０５は、情報処理装置２０から配信要求を受信すると、ストリーム解析部３０３に、配信要求に記載されたチャンネルに対応する各圧縮データストリームについて、記憶している最新の配信時刻を問い合わせる。その後、配信要求処理部３０５は、問い合わせの結果得られた複数の配信時刻の中から、最も古い配信時刻に対応する圧縮データストリームを、情報処理装置２０に配信する圧縮データストリームとして優先的に選択する。これにより、配信要求処理部３０５は、次に最も早く基準圧縮映像データが配信される圧縮データストリームを選択することができる。スイッチ３０は、配信要求処理部３０５が選択した圧縮データストリームのＩＰパケットを直ちに送出することで、最短時間でＩＤＲピクチャが伝送されてくるストリームを、情報処理装置２０に配信することができる。

なお、配信要求処理部３０５は、配信時刻の古さ（すなわち、配信時刻の相対的な位置）だけでなく、基準圧縮映像データから次の基準圧縮映像データまでの間隔（すなわちＧＯＰ）を更に考慮することで、ストリームの選択を行っても良い。かかる処理を行う場合には、配信要求処理部３０５は、基準圧縮映像データが配信されてから次の基準圧縮映像データが配信されるまでの時間間隔に関する情報を予め保持しているものとする。配信要求処理部３０５は、ストリーム解析部３０３から最新の配信時刻に関する情報を取得すると、かかる時間間隔に関する情報を利用して、配信要求のあった時刻が各ストリームにおける上記時間間隔のどのあたりに位置するかを判断する。その結果、配信要求処理部３０５は、各ストリームについて、次に基準圧縮映像データが配信されてくる時刻を予測することができる。配信要求処理部３０５は、予測した配信時刻のうち、最も早く到達する配信時刻に対応するストリームを、情報処理装置２０に配信する圧縮データストリームとして選択する。配信要求処理部３０５は、選択したストリームと、そのストリームにおける基準圧縮映像データの配信予定時刻を、後述する配信切替部３０７に出力する。後述する配信切替部３０７では、伝送された配信予定時刻にストリームの切替を行うことで、遅延無くストリームの切替を行うことができる。配信要求処理部３０５が、かかる予測処理を伴うストリームの選択処理を実行する場合には、バッファ３０１の実装を省略することも可能である。

なお、ストリーム解析部３０３が最新の配信時刻だけでなく、最新の配信時刻に先立ついくつかの配信時刻を更に記憶しておき、配信要求処理部３０５が、このいくつかの配信時刻を利用して、次の配信時刻を予測してもよい。

配信切替部３０７は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等により実現される。配信切替部３０７は、配信要求を送信した情報処理装置２０に配信される圧縮データストリームを、配信要求処理部３０５により選択された圧縮データストリームへと切り替える処理を行う。配信切替部３０７は、スイッチ３０にバッファ３０１が設けられている場合には、バッファ３０１に格納されている切替先の圧縮データストリームを情報処理装置２０へと配信しつつ、圧縮データストリームの切替処理を行う。また、配信要求処理部３０５から、基準圧縮映像データの配信予定時刻が入力された場合には、かかる時刻までに切替が完了するように、ストリームの切替処理を行う。

配信切替部３０７によりかかる圧縮データストリームの切替処理が行われることで、情報処理装置２０には、配信要求に記載された映像音声コンテンツの最適な圧縮データストリームが配信されることとなる。

以上、本実施形態に係るスイッチ（ネットワーク機器）３０の機能の一例を示した。上記の各構成要素は、汎用的な部材や回路を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。また、各構成要素の機能を、ＣＰＵ等が全て行ってもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用する構成を変更することが可能である。

なお、上述のような本実施形態に係るネットワーク機器の各機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

＜コンテンツ配信方法について＞
続いて、図５〜図８を参照しながら、本実施形態に係るコンテンツサーバ１０が実行するコンテンツ配信方法について、詳細に説明する。

［基準圧縮映像データの位置関係について］
図５は、本実施形態に係るコンテンツサーバ１０から出力されるＭＰＥＧ２−ＴＳストリーム中のＩＤＲピクチャの位置関係を説明するための説明図である。図５では、１秒間に１回の割合で、基準圧縮映像データであるＩＤＲピクチャが出現するように設定してエンコードする例を示したが、動的にＩＤＲピクチャの生成タイミングを変えるエンコード方式を採用してもよい。その場合には、互いの符号化部はそれぞれ連携して、ＩＤＲピクチャの出現タイミングがずれるように動作するように設定する。

図５では、上述のように１秒間に１回、基準圧縮映像データであるＩＤＲピクチャが出現するように符号化が実行される。また、ＧＯＰは３０フレームから構成されており、ＩＤＲピクチャ以外にも、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ ｐｉｃｔｕｒｅ：予測符号化ピクチャ）およびＢピクチャ（Ｂｉ−ｐｒｅｄｉｃｔｉｖｅ Ｐｉｃｔｕｒｅ：双予測ピクチャ）がＧＯＰ内に存在する。第１符号化部１０１から出力されるストリームと、第２符号化部１０３から出力されるストリームとを比較すると、図５から明らかなように、ＩＤＲピクチャの出現タイミングが１５フレーム分（約０．５秒分）ずれていることがわかる。

このように符号化を行うとともに、端末である情報処理装置２０がチャンネル切り替えの際に、その時点にて最適なＭＰＥＧ２−ＴＳストリームを受信することで、切り替え後にＩＤＲピクチャを受信するまでの待ち時間を最小にすることができ、切り替えたチャンネルの映像を早く表示することが可能になる。

例えば、図５に示す「時刻Ａ」の時点で、端末である情報処理装置２０において、このチャンネルに対する切り替えが起こった場合を考える。この場合、情報処理装置２０は、第１符号化部１０１から出力されるストリーム（換言すれば、第１処理部１１Ａから出力されるストリーム）を受信することで、チャンネル切り替え後に、選局したチャンネルの映像表示までの待ち時間を短くすることができる。同様に、「時刻Ｂ」の時点で、情報処理装置２０において、このチャンネルに対する切り替えが起こった場合を考える。この場合、情報処理装置２０は、第２符号化部１０３から出力されるストリーム（換言すれば、第２処理部１１Ｂから出力されるストリーム）を受信することで、チャンネル切り替え後に、選局したチャンネルの映像表示までの待ち時間を短くすることができる。

各符号化部１０１，１０３から出力されるＭＰＥＧストリームは、同一の映像信号から生成されたものである。また、これらのＭＰＥＧストリームは、チャンネル切り替え等で映像表示を開始できるＩＤＲピクチャの時間的位置がずれているだけであって、その他、解像度や最大ビットレートなどは同一条件にて符号化されている。そのため、視聴者からみて、どちらの符号化部から送出されたストリームを再生中であるかは、ほとんど意識されることはない。

また、各符号化部１０１，１０３は、Ｈ．２６４．ＡＶＣのエンコーダやＭＰＥＧ２の多重化のシステムクロックが互いに同期している必要はない。各符号化部１０１，１０３は、ＩＤＲピクチャの相対位置関係をずらすのに必要な情報を事前に取り決めておけば、処理部１１Ａ，１１Ｂ間における通信を行うことなく実現可能である。ここで、ＩＤＲピクチャの相対位置関係をずらすために必要な情報の例として、例えば、固定ＧＯＰ長の大きさに関する情報や、元映像信号の映像フレームのどのフレームをＩＤＲピクチャにエンコードするか等の情報を挙げることができる。また、可変ＧＯＰ長を採用する場合であれば、各処理部１１Ａ，１１Ｂは互いに通信しあい、ＩＤＲピクチャの出現フレームがチャンネル切り替えに最適なるように、出現位置を相対的にずらすことも実現可能である。

［ＵＤＰパケットのフォーマットについて］
図６は、本実施形態に係る配信部１０５，１０７が送出するＵＤＰパケットのフォーマットを説明するための説明図である。コンテンツサーバ１０が備える各符号化部１０１，１０３で生成されたＭＰＥＧ２−ＴＳパケットは、それぞれの符号化部が属する処理部に設けられた配信部に出力され、ＩＰパケットとして伝送される。このＩＰパケットは、例えば図６に示したようなフォーマットを有する。

図６に示したように、ＩＰマルチキャストのＵＤＰパケットは、ＩＰヘッダと、ＵＤＰヘッダと、ＲＴＰヘッダと、ＲＴＰペイロードと、から構成される。コンテンツサーバ１０の各符号化部１０１，１０３で生成されたＭＰＥＧ２−ＴＳパケットは、ＲＴＰペイロードに格納される。通常、ＲＴＰペイロードには、図６に示したように、７個のＭＰＥＧ２−ＴＳパケットが格納される。

コンテンツサーバ１０の各配信部１０５，１０７は、図６のようなＵＤＰパケットを生成し、マルチキャスト配信する。

［ＩＰパケットの伝送について］
次に、図７および図８を参照しながら、本実施形態に係るＩＰパケットが情報処理装置へ伝送される仕組みについて、詳細に説明する。なお、以下では、ＩＰＴＶシステムの規格であるＤＶＢ−ＩＰ（ＥＴＳＩ ＴＳ１０２ ０３４）に基づき、詳細に説明を行う。

端末である情報処理装置２０は、各チャンネルに対するＭＰＥＧストリームを受信するために、チャンネルのデータが配信されるＩＰマルチキャストアドレスを知る必要がある。ＤＶＢ−ＩＰでは、チャンネルの情報は、ＳＤ＆Ｓのブロードキャストディスカバリーレコードに記述される。このブロードキャストディスカバリーレコードは、ＥＰＧサーバ等のＩＰＴＶアプリケーションサーバ（図示せず。）から情報処理装置２０へと、ＤＶＢ−ＩＰ規定のＤＶＢ ＳＤ＆Ｓ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＤＶＢ ＳＴＰ）によりマルチキャストで伝送される。なお、このブロードキャストディスカバリーレコードは、ＭＰＥＧ２−ＴＳストリームとは別のＩＰマルチキャストアドレスにて転送される。

そのため、本実施形態に係るコンテンツ配信システム１内に存在するコンテンツサーバ１０は、事前に、コンテンツサーバ１０の各処理部１１に割り当てられているＩＰマルチキャストアドレスや、各種のチャンネル情報を、ＩＰＴＶアプリケーションサーバに通知しておく必要がある。

図７は、ＤＶＢ−ＩＰのブロードキャストディスカバリーレコードのデータ形式を説明するための説明図である。ブロードキャストディスカバリーレコードには、ＩＰＴＶサービスが提供するすべてのチャンネルの情報が記述されている。例えば、３００チャンネル放送するＩＰＴＶサービスであれば、端末である情報処理装置２０は、３００個のチャンネルの情報が記述されたブロードキャストディスカバリーレコードを受信する。

チャンネル情報としては、例えば図７に示したように、ＴｅｘｔｕａｌＩｄｅｎｔｉｆｉｅｒ＠ＳｅｒｖｉｃｅＮａｍｅにはチャンネル名が文字列で記述され、チャンネル名を表示するのに使用される。また、ＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＠ＡｄｄｒｅｓｓとＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＠Ｐｏｒｔには、このチャンネルのＩＰマルチキャストパケットが配信されているＩＰマルチキャストアドレスとポート番号が記述さ
れている。

端末である情報処理装置２０は、ＩＧＭＰにて、ブロードキャストディスカバリーレコードに記載されているＩＰマルチキャストアドレスグループに加入することで、希望のチャンネルのＩＰマルチキャストパケットの配信が開始され、ＩＰマルチキャストパケットを受信可能となる。

通常、チャンネルごとに一つのＩＰマルチキャスト配信が割り当てられているが、本実施形態に係るコンテンツ配信システムでは、各チャンネルでは複数のＩＰマルチキャスト配信が提供される。このために、ブロードキャストディスカバリーレコードには、複数のＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓが記述される。

図８は、ブロードキャストディスカバリーレコードをＸＭＬ表記した場合の例を説明するための説明図である。このブロードキャストディスカバリーレコードの例では、３００チャンネル分のサービス情報が記述されており、各「＜ＳｉｎｇｌｅＳｅｒｖｉｃｅ＞」のＸＭＬエレメントが、チャンネルひとつ分の情報に相当する。

例えば、先頭のチャンネル情報には、チャンネル名（ＳｅｒｖｉｃｅＮａｍｅ）である「Ｃｈａｎｎｅｌ １」と、２つのマルチキャストアドレス（アドレス２２４．０．１．１、ポート番号１６００のものと、アドレス２２４．０．１．１、ポート番号１６００のもの）とが記述されている。これら２つのアドレスは、図２で示した第１処理部１１Ａから配信されるＩＰパケットのマルチキャストアドレスと、第２処理部１１Ｂから配信されるＩＰパケットのマルチキャストアドレスに相当する。次に列挙されているチャンネル情報では、チャンネル名である「Ｃｈａｎｎｅｌ ２」と、２つのマルチキャストアドレスが記述されている。以下、チャンネル情報の記述は省略されているが、合計３００チャンネル分の情報が列挙されて記述されることになる。以上のブロードキャストディスカバリーレコードにより、情報処理装置２０は、各チャンネルの２つのチャンネルアドレスを知ることが可能となる。

本実施形態では、ＤＶＢ−ＩＰ規定のブロードキャストディスカバリーレコードを拡張し、「＜ＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏ＞」というＸＭＬエレメントを記述する。「＜ＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏ＞」のＸＭＬエレメントでは、ひとつのチャンネルあたり最大幾つのＭＰＥＧストリームがマルチキャスト配信されているかを示すデータが、「＠ＮｕｍｂｅｒＯｆＳｔｒｅａｍｓＰｅｒＣｈａｎｎｅｌ」に指定されている。図８に示した例では、チャンネルあたり最大２つのＭＰＥＧストリームが配信されている。

以上説明したように、本実施形態に係るコンテンツ配信方法では、一つのチャンネルに対して、基準圧縮映像データの出現タイミングが異なる複数の圧縮データストリームが配信されることとなる。これらの圧縮データストリームは、基準圧縮映像データの出現タイミングのみが異なっており、この出現タイミング以外の符号化条件は同一である。そのため、端末である情報処理装置２０に複数の圧縮データストリームの中から、適したストリームをスイッチ３０が選択し配信することで、基準圧縮映像データを受信するまでの待ち時間を最小にすることができ、チャンネルの映像を早く表示することが可能となる。

＜情報処理方法について＞
続いて、図９〜図１３を参照しながら、本実施形態に係る情報処理装置２０が実行する情報処理方法について、詳細に説明する。図９は、本実施形態に係る情報処理装置２０が実施する情報処理方法を説明するための流れ図である。

視聴者（ユーザ）により、本実施形態に係る情報処理装置２０の電源が投入された場合や、ＩＰＴＶのサービスメニュー等からＴＶサービスが選択された場合には、本実施形態に係る情報処理装置２０は、ＴＶ視聴処理を開始する。

まず、情報処理装置２０は、装置に備えられているＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等を利用して、ＥＰＧサーバ等のＩＰＴＶアプリケーションサーバ（図示せず。）からブロードキャストディスカバリーレコードを取得する（ステップＳ１０１）。このブロードキャストディスカバリーレコードは、図７に示したようなＤＶＢ−ＩＰ規定のプロトコルに基づいて記載されており、情報処理装置２０は各チャンネルに対応したチャンネル情報を取得することができる。チャンネル情報が頻繁には変わらない場合には、既にＩＰＴＶサービスから取得済みのチャンネル情報を利用するようにしてもよい。

図１０Ａおよび図１０Ｂは、ＲＦＣ３３７６で規定されるＩＧＭＰバージョン３における、情報処理装置２０からマルチキャストデータ配信制御を行うためのＩＧＭＰメッセージのフォーマットである。また、図１１Ａおよび図１１Ｂは、本実施形態に係るＩＧＭＰメッセージの一例を説明するための説明図である。

情報処理装置２０がマルチキャストグループに参加および離脱する場合は、図１０Ａに示したレポートフォーマットのＩＧＭＰメッセージを利用する。そのほか、マルチキャストルータがマルチキャストグループに加入していることを確認するクエリーフォーマットのＩＧＭＰメッセージもあるが、これらＩＧＭＰの仕様についての詳細説明は省略する。

図１０Ａに示したように、レポートフォーマットのＩＧＭＰメッセージには、「Ｎｕｍｂｅｒ ｏｆ Ｇｒｏｕｐ Ｒｅｃｏｒｄｓ」という欄に、当該レポートに含まれるレコードの数が明記されており、続いて、明記されたレコードの数の分だけ、「Ｇｒｏｕｐ Ｒｅｃｏｒｄ」が記載される。図１０Ｂは、各グループレコードのフォーマットである。図１０Ｂに示したように、グループレコードのフォーマットには、「Ｒｅｃｏｒｄ Ｔｙｐｅ」という欄が存在し、この欄に所定の値を入力することで、マルチキャストグループへの参加や離脱を指定することが可能である。

例えば図１１Ａに示したように、「Ｒｅｃｏｒｄ Ｔｙｐｅ」の欄に「１」という値を設定することで、マルチキャストグループに参加することが可能である。この「１」という値は、「ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ」を示す値である。図１１Ａに示した例は、２２４．０．１．０で表されるマルチキャストグループに参加することを示すものである。

また、例えば図１１Ｂに示したように、「Ｒｅｃｏｒｄ Ｔｙｐｅ」の欄に「２」という値を設定することで、マルチキャストグループから離脱することが可能である。この「２」という値は、「ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ」を示す値である。図１１Ｂに示した例は、２２４．０．１．０で表されるマルチキャストグループから離脱することを示すものである。

続いて、情報処理装置２０のチャンネル選択部２０１は、チャンネル選択情報の初期設定を実施する（ステップＳ１０３）。初期設定されるチャンネル選択情報は、「ＣｕｒｒｅｎｔＣｈａｎ」、「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」、「ＳｅｌｅｃｔＣｈａｎ」、「ＳｅｌｅｃｔＡｄｄｒ」という４つのパラメータである。

パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」は、情報処理装置２０が現在選局中のチャンネルのポジションを示すパラメータであり、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」は、現在選局されているチャンネルが配信されているマルチキャストアドレスを示すパラメータである。初期設定では、これら２つのパラメータともに−１を設定する。これは、現在、チャンネル選局がおこなわれていないことを示す値である。また、パラメータ「ＳｅｌｅｃｔＣｈａｎ」は、これから選局するチャンネルのチャンネルポジションを示すパラメータであり、パラメータ「ＳｅｌｅｃｔＡｄｄｒ」は、選局されたチャンネルのＭＰＥＧ２−ＴＳストリームが配信されるマルチキャストアドレスを示すパラメータである。初期設定では、「ＳｅｌｅｃｔＣｈａｎ」には１を設定する。もし、以前に選曲したチャンネル情報を端末が保持している場合は、そのチャンネルポジションを指定する。「ＳｅｌｅｃｔＡｄｄｒｅｓｓ」には、−１を設定して初期化を行う。

続いて、チャンネル選択部２０１は、パラメータ「ＳｅｌｃｔＣｈａｎ」に示されたチャンネルをコンテンツ取得部２０３へ通知して、コンテンツ取得部２０３は、チャンネルの選局処理を行う（ステップＳ１０５）。このチャンネルの選局処理については、以下で改めて詳細に説明する。この処理により取得したコンテンツがコンテンツ再生部２０５により再生されることで、情報処理装置２０の表示部（図示せず。）の画面には、チャンネルの映像が表示され、スピーカからは音声が再生される。

選局の処理が終了すると、チャンネル選択部２０１は、現在選局中のチャンネルに関するチャンネル情報を更新する（ステップＳ１０７）。すなわち、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」にはパラメータ「ＳｅｌｅｃｔＣｈａｎ」の値が設定され、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒ」にはパラメータ「ＳｅｌｅｃｔＡｄｄｒ」の値が設定される。

続いて、情報処理装置２０のチャンネル選択部２０１は、ユーザ操作の入力を待ち受ける（ステップＳ１０９）。

ここで、ユーザにより、例えば、リモコンの電源オフボタンを押すなど終了操作が入力された場合には（ステップＳ１１１）、チャンネル選択部２０１は、入力された操作に応じた信号を生成し、ステップＳ１２１のチャンネル受信終了処理に進む。また、ユーザにより、チャンネルを切り替える旨の操作が入力された場合には（ステップＳ１１３）、後述するステップＳ１１５に進む。そうでなかった場合は、ステップＳ１０９に戻り、ユーザ操作の待ちうけを行う。実際には、これらの制御以外にも、ボリューム制御等の他のユーザ操作の処理もあるが、図９での記述は省略する。

ユーザにより、チャンネル切り替え操作、例えば、リモートコントローラのチャンネルアップボタンが操作された場合には、チャンネル選択部２０１は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」を１加算し、チャンネルダウンボタンが操作された場合には、チャンネル選択部２０１は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」を１減算する（ステップＳ１１５）。ここで、チャンネル選択部２０１は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」の値がマイナス値や総チャンネル値以上にならないように、制御を行う。また、リモートコントローラ等にチャンネル番号等を直接選択できるボタン等がある場合には、チャンネル選択部２０１は、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に、選択されたチャンネル番号に相当するチャンネルポジションを設定する。その後、チャンネル選択部２０１は、新たに設定されたパラメータに関する情報をコンテンツ取得部２０３に通知する。

コンテンツ取得部２０３は、チャンネル選択部２０１から通知されたパラメータ「ＳｅｌｅｃｔＣｈａｎ」の値に基づいて、このパラメータに指定されたチャンネルの選局を実施する（ステップＳ１１７）。その結果、新たに選局されたチャンネルが、情報処理装置２０の画面およびスピーカから再生される。ステップＳ１０５にて説明したとおり、チャンネル選局処理の詳細については、以下で改めて説明する。

その後、チャンネル選択部２０１は、ステップＳ１０７と同様に、現在選局中のチャンネルに関するチャンネル情報を更新する（ステップＳ１１９）。

続いて、情報処理装置２０のチャンネル選択部２０１は、ユーザ操作の入力を待ち受け、ＴＶ視聴が続く。

他方、ユーザ操作が終了操作であった場合には、コンテンツ取得部２０３は、チャンネル受信終了処理を実施する（ステップＳ１２１）。チャンネル受信終了処理については、以下で改めて詳細に説明する。

これにより、情報処理装置２０は、ＴＶ視聴を終了し、他のＩＰＴＶサービスメニューに戻るか、端末の他の機能に移行する。

［チャンネル選局処理について］
続いて、図１２を参照しながら、本実施形態に係る情報処理装置２０が実施するチャンネル選局処理について、詳細に説明する。図１２は、本実施形態に係る情報処理方法におけるチャンネル選局処理を説明するための流れ図である。

コンテンツ取得部２０３は、まず、ブロードキャストディスカバリーレコードからチャンネルのマルチキャストアドレスを取得する。図８に示した例では、パラメータ「ＳｅｌｅｃｔＣｈａｎ」が１に設定されている場合、先頭位置の「＜ＳｉｎｇｌｅＳｅｒｖｉｃｅ＞」が該当するチャンネル情報である。このチャンネル情報の「＜ＳｅｒｖｉｃｅＬｏｃａｔｉｏｎ＞」には、図８に示したように、２つのマルチキャストアドレスが記述されている。図８の例では、パラメータ「Ａｄｄｒｅｓｓ１」に２２４．０．１．１が設定され、パラメータ「Ａｄｄｒｅｓｓ２」には２２４．０．１．２が設定される。

コンテンツ取得部２０３は、ブロードキャストディスカバリーレコードから選局チャンネルに対応する複数のチャンネルのマルチキャストアドレスを含むＩＧＭＰメッセージを発行する（ステップＳ２０１）。これにより、情報処理装置２０は、マルチキャストパケットの配信切り替えを開始する。このＩＧＭＰメッセージの発行は、図１０Ａおよび図１０Ｂに示したＲＦＣ−３３７６規定のＩＧＭＰバージョン３のレポートフォーマットにて行われる。

図１３Ａ〜図１３ＣにＩＧＭＰパケットの例を示す。
図１３Ａは、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」が−１の場合、つまり、既に配信しているマルチキャストがない場合のものである。図１３Ａでは、パラメータ「ＳｅｌｅｃｔＣｈａｎ」（例では１）の複数のマルチキャストアドレス（例では２２４．０．１．１と２２４．０．１．２）の２つのマルチキャストグループに対して、ＲｅｃｏｄｅＴｙｐｅ＝１（ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ）を指定している。これは、マルチキャストデータ配信を開始するために、あるチャンネルに対応する２つのマルチキャストアドレスに加入することを意味している。

図１３Ｂは、パラメータ「ＣｕｒｒｅｎｔＣｈａｎ」が−１以外の場合、つまり、既に配信しているマルチキャストアドレスがある場合のＩＧＭＰパケットの例である。ここでは、「ＣｕｒｒｅｎｔＣｈａｎ」（例では１）の「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」（例２２４．０．１．１）のマルチキャストグループに、ＲｅｃｏｒｄＴｙｐｅ＝２（ＭＯＤＥ＿ＩＳ＿ＥＸＣＬＵＤＥ）を指定して配信の停止を指示している。また、このＩＧＭＰパケットでは、「ＳｅｌｅｃｔＣｈａｎｎｅｌ」（例では２）の複数のマルチキャストアドレス「（例では２２４．０．１．３と２２４．０．１．４）のマルチキャストグループに、ＲｅｃｏｒｄＴｙｐｅ＝１（ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥ）を指定して配信の開始を指示している。

ＩＭＧＰバージョン３では、図１３Ｂに示したように、ひとつのＩＧＭＰパケットによって一括して指示がおこなえるので、切り替え時にアクセスネットワークに重複してマルチキャストアドレスが配信されないような実装が可能であるという利点がある。

かかるＩＧＭＰパケットを発行し、発行したＩＧＭＰパケットをスイッチ３０に送信することで、スイッチ３０は後述するストリームの切替処理を行い、情報処理装置２０にＩＧＭＰパケットに記載されたチャンネルのマルチキャストパケットを配信する。コンテンツ取得部２０３は、ＩＧＭＰパケットにおいて要求したＡｄｄｒｅｓｓ１およびＡｄｄｒｅｓｓ２のＩＰパケットの受信を開始する（ステップＳ２０３）。

スイッチ３０は、後述するように、情報処理装置２０から要求された複数のマルチキャストアドレスに対するストリームのうち、チャンネル切り替えに最適なものを選択し、選択したストリームのマルチキャストアドレスの配信のみを行う。また、スイッチ３０は、選択しなかったストリームに関する情報処理装置２０からの配信要求は、無視する。

コンテンツ取得部２０３は、スイッチ３０により選択されたストリームの配信の切り替えが完了するまでは最大切替所要時間の間待機を行うため、マルチキャストパケットを受信していない場合は、待機する（ステップＳ２０５）。なお、ネットワークにてＩＧＭＰパケットの喪失の恐れがある場合、コンテンツ取得部２０３は、複数のパケットをステップＳ２０１にて送信してもよく、ステップＳ２０３にてタイムアウト等を設け、ＩＧＭＰパケットの再送信処理を行うようにしてもよい。

ステップＳ２０５で待機した結果、待機後にはマルチキャストの配信切り替えが終了しているため、以前選局していたチャンネルが存在する場合には、コンテンツ取得部２０３は、該当する「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」のマルチキャストパケットの受信を終了する（ステップＳ２０７）。

コンテンツ取得部２０３は、受信したマルチキャストパケットを参照して、受信したマルチキャストパケットに対応するマルチキャストアドレスを調べ、このマルチキャストアドレスをＳｅｌｅｃｔＡｄｄｒｅｓｓに設定する（ステップＳ２０５）。また、コンテンツ取得部２０３は、受信していないマルチキャストアドレス（すなわち、スイッチ３０にて選択されなかったマルチキャストアドレス）の受信は終了する（ステップＳ２０５）。

その後、コンテンツ取得部２０３は、受信したマルチキャストパケットをコンテンツ再生部２０５に伝送する。コンテンツ再生部２０５は、新たに受信を開始したチャンネルのマルチキャストパケットに格納されているＭＰＥＧ２−ＴＳの再生を開始する（ステップＳ２１１）。より詳細には、ＩＤＲピクチャを含むＭＰＥＧ２−ＴＳパケットを受信してから、映像が情報処理装置２０の表示部（図示せず。）に表示されることになる。このようにして、チャンネル選局処理は終了し、そのままＩＰＴＶテレビ視聴は継続することとなる。

［チャンネル受信終了処理について］
続いて、図１４を参照しながら、情報処理装置２０が実施するチャンネル受信終了の処理について詳細に説明する。

まず、コンテンツ取得部２０３は、現在、受信中のマルチキャストパケットを停止する。マルチキャストパケットの受信は、図１３Ｃに示したＩＧＭＰレポートメッセージを送信することで停止可能である（ステップＳ３０１）。図１３Ｃに示したように、コンテンツ取得部２０３は、パラメータ「ＣｕｒｒｅｎｔＡｄｄｒｅｓｓ」（例では２２４．０．１．４）のマルチキャストグループに対して、ＲｅｃｏｒｄＴｙｐｅ＝２を指定して、ＩＧＭＰメッセージを送信する。これにより、マルチキャストパケット配信の停止が行われる。

次に、コンテンツ取得部２０３は、マルチキャストの受信を終了する（ステップＳ３０３）。その後、コンテンツ再生部２０５は、ＭＰＥＧ２−ＴＳストリームの再生を終了する（ステップＳ３０５）。このような処理を行うことで、チャンネル受信終了の処理は完了する。

以上説明したように、本実施形態に係る情報処理方法では、チャンネル選局処理に際して、視聴を希望するチャンネルに対応する複数のマルチキャストアドレス全てに対して、参加の要請を行う。これにより、本実施形態に係る情報処理方法では、視聴を希望するチャンネルに対応する複数のマルチキャストアドレスのうち、どのアドレスへ参加するかを判断しなくとも良くなる。その結果、本実施形態に係る情報処理方法を実施する情報処理装置では、より簡便にチャンネル選局処理を実行することが可能となる。

＜ストリーム切替方法について＞
続いて、図１５〜図１７を参照しながら、本実施形態に係るネットワーク機器の一例であるスイッチ３０が実施するストリーム切替方法について、詳細に説明する。図１５は、本実施形態に係るストリーム切替方法を説明するための流れ図であり、図１６および図１７は、本実施形態に係るストリーム切替方法を説明するための説明図である。

本実施形態に係るストリーム切替方法を説明するに先立ち、ネットワーク機器の一例であるスイッチ３０は、コンテンツ配信システム１内で配信されている映像音声コンテンツに対応する圧縮データストリームを全て解析しているものとする。これにより、スイッチ３０は、全ての圧縮データストリームについて、基準圧縮映像データの最新の配信時刻を検出しているものとする。

端末である情報処理装置２０は、チャンネルの切替操作等によって、情報処理装置２０に配信されるコンテンツを切り替える必要が生じた場合には、情報処理装置２０のコンテンツ取得部２０３は、スイッチ３０に対してコンテンツの配信要求を送信する。

スイッチ３０の配信要求処理部３０５は、情報処理装置２０から送信されたチャンネルの切替等に起因するコンテンツの配信要求を取得する（ステップＳ３０１）。続いて、配信要求処理部３０５は、取得したコンテンツの配信要求に記載されている、配信を希望するチャンネルのマルチキャストアドレスを特定する。

続いて、配信要求処理部３０５は、配信要求に記載されているマルチキャストアドレスについて、基準圧縮映像データの最新の配信時刻をストリーム解析部３０３に問い合わせる。

ストリーム解析部３０３は、配信要求処理部３０５からの問い合わせに応じて、該当するマルチキャストアドレスの最新の基準圧縮映像データの配信時刻を配信要求処理部３０５に送信する。

次に、配信要求処理部３０５は、各ストリームの最新の基準圧縮映像データ（例えばＩＤＲピクチャ）の配信時刻に基づいて、適切な圧縮データストリームを選択する（ステップＳ３０３）。より詳細には、例えば図１６に示したように、配信時刻の相対的な古さに応じてストリームを選択したり、例えば図１７に示したように、配信時刻の相対的な古さとＧＯＰの大きさとに基づいてストリームを選択したりする。

図１６に示した選択方法は、配信要求に記載されていたチャンネル（チャンネルＡ）に対応する各圧縮データストリームの最新の配信時刻の相対的な古さに応じて、情報処理装置２０に配信するストリームを選択する方法である。図１６に示した場合では、ストリーム１の配信時刻の方がストリーム２の配信時刻よりも古いため、配信要求処理部３０５は、基準圧縮映像データ（ＩＤＲピクチャ）の次の配信時刻は、ストリーム１の方が先になると判断する。そのため、配信要求処理部３０５は、配信切替部３０７に対して、チャンネルＡのストリーム１に対応するマルチキャストアドレスを通知する。

図１７に示した選択方法は、配信時刻の相対的な古さとＧＯＰの大きさとに基づいて、情報処理装置２０に配信するストリームを選択する方法である。図１７に示した場合では、配信要求処理部３０５は、ストリーム１における最新の配信時刻である時刻１と、ストリーム２における最新の配信時刻である時刻２と、ＧＯＰの大きさとに基づいて、各ストリームにおける次の基準圧縮映像データの配信時刻を予測する。図１７の場合、配信要求を受信した時刻と各ストリームにおけるＧＯＰの大きさとの相対的な位置関係を考慮すると、基準圧縮映像データ（ＩＤＲピクチャ）の次の配信時刻（配信予定時刻）は、ストリーム１の方がストリーム２よりも早くなる。そのため、配信要求処理部３０５は、配信切替部３０７に対して、チャンネルＡのストリーム１に対応するマルチキャストアドレスと、算出した配信予定時刻とを通知する。

次に、スイッチ３０の配信切替部３０７は、配信要求処理部３０５によって選択されたストリームを、配信要求を送信した情報処理装置２０へと配信する（ステップＳ３０５）。これにより、情報処理装置２０には、当該情報処理装置２０が配信要求に記載したマルチキャストアドレスの何れかのアドレスに対応する圧縮データストリームが配信されることとなる。

以上、本実施形態に係るＩＰＴＶシステムの高速チャンネル切り替えについて説明した。上記実施形態のみならず、本発明によれば、別の実施形態を考案することは容易であり、例えば、以下のような別の実施形態が考えられる。

本発明に係る実施形態では、チャンネル切り替え処理を行っている間のユーザ操作による割り込みにより、チャンネル切り替えの中止や選局するチャンネルの変更を行うために、図１２に示した選局処理の途中中断処理を実装することは容易である。

また、本発明に係る実施形態では、Ｈ．２６４／ＡＶＣの場合について説明したが、ＭＰＥＧ２の映像圧縮を利用した場合でもＩＤＲピクチャをＩピクチャと考えることで、ＭＰＥＧ２の映像圧縮を利用したＩＰＴＶシステムにも、本発明を容易に適用可能である。

また、本発明に係る実施形態では、圧縮映像データと音声データとをＭＰＥＧ２−ＴＳにて多重化して送信する場合について説明した。しかしながら、圧縮映像、音声データを個別にＩＰパケットにて配信する場合であっても、本発明を適用することで、それらＩＰパケット配信を切り替えて高速チャンネル切り替えを実現するＩＰＴＶシステムを容易に実現可能である。

また、本発明に係る実施形態では、ひとつの映像音声信号のみを、圧縮映像データおよび音声データとしてＭＰＥＧ２−ＴＳにて多重化し、ＩＰパケットに格納した上で配信の切り替えを行う。しかしながら、ＭＰＥＧ２−ＴＳに複数の映像音声信号の圧縮映像データおよび音声データを多重化して配信し、情報処理装置２０へのネットワーク経路にて、選択された映像音声信号に該当する圧縮映像・音声パケットのみをフィルターして送信してもよい。これにより、本実施形態と同様の高速チャンネル切り替えを実現したＩＰＴＶシステムを容易に実現することが可能である。

また、本発明に係る実施形態では、ＩＧＭＰバージョン３の機能を利用し、一つのＩＧＭＰパケットにてマルチキャストグループの配信切り替えを行う。これにより、切り替え中にパケットが重複してアクセスネットワークに配信されないようにし、アクセスネットワークでＩＰＴＶシステムが使用するデータ帯域を制限するようにした。しかしながら、ＩＧＭＰバージョン２を利用の場合でも、マルチキャストグループへの離脱を行い、配信が停止された後、切り替えるマルチキャストグループに加入する処理をすることで、同様にＩＰＴＶシステムで使用するデータ帯域を制限することは可能である。

また、本発明に係る実施形態では、コンテンツサーバ１０が各チャンネルの複数ＭＰＥＧ２−ＴＳストリームをエンコードし、コアネットワーク経由にて配信した。ここで、コアネットワークの帯域に制限のある環境では、以下のようなことを実施することも可能である。すなわち、コンテンツサーバ１０では各チャンネルあたり一つの符号化されたパケットをコアネットワークにて配信を行い、アクセスネットワーク等の配信ネットワークの途中に、エッジサーバまたはエッジルータなどの別のコンテンツサーバを配置する。これらの別のコンテンツサーバにて、受信したＭＰＥＧ２−ＴＳストリームに対して、映像音声信号を元にＩＤＲピクチャの配信タイミングが異なるＭＰＥＧ２−ＴＳストリームを生成して、配信する。このようにすることで、コアネットワークの帯域を制限しながら、本実施形態で説明したＩＴＰＶシステムと同様の高速チャンネルスイッチを実現することができる。

（ハードウェア構成について）
次に、図１８を参照しながら、本発明の実施形態に係るコンテンツサーバ１０のハードウェア構成について、詳細に説明する。図１８は、本発明の実施形態に係るコンテンツサーバ１０のハードウェア構成を説明するためのブロック図である。

コンテンツサーバ１０は、主に、ＣＰＵ７０１と、ＲＯＭ７０３と、ＲＡＭ７０５と、を備える。また、コンテンツサーバ１０は、更に、ホストバス７０７と、ブリッジ７０９と、外部バス７１１と、インターフェース７１３と、入力装置７１５と、出力装置７１７と、ストレージ装置７１９と、ドライブ７２１と、接続ポート７２３と、通信装置７２５とを備える。

ＣＰＵ７０１は、演算処理装置および制御装置として機能し、ＲＯＭ７０３、ＲＡＭ７０５、ストレージ装置７１９、またはリムーバブル記録媒体７２７に記録された各種プログラムに従って、コンテンツサーバ１０内の動作全般またはその一部を制御する。ＲＯＭ７０３は、ＣＰＵ７０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ７０５は、ＣＰＵ７０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一次記憶する。これらはＣＰＵバス等の内部バスにより構成されるホストバス７０７により相互に接続されている。

ホストバス７０７は、ブリッジ７０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス９１１に接続されている。

入力装置７１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチおよびレバーなどユーザが操作する操作手段である。また、入力装置７１５は、例えば、赤外線やその他の電波を利用したリモートコントロール手段（いわゆる、リモコン）であってもよいし、コンテンツサーバ１０の操作に対応した携帯電話やＰＤＡ等の外部接続機器７２９であってもよい。さらに、入力装置７１５は、例えば、上記の操作手段を用いてユーザにより入力された情報に基づいて入力信号を生成し、ＣＰＵ７０１に出力する入力制御回路などから構成されている。コンテンツサーバ１０のユーザは、この入力装置７１５を操作することにより、コンテンツサーバ１０に対して各種のデータを入力したり処理動作を指示したりすることができる。

出力装置７１７は、取得した情報をユーザに対して視覚的または聴覚的に通知することが可能な装置で構成される。このような装置として、ＣＲＴディスプレイ装置、液晶ディスプレイ装置、プラズマディスプレイ装置、ＥＬディスプレイ装置およびランプなどの表示装置や、スピーカおよびヘッドホンなどの音声出力装置や、プリンタ装置、携帯電話、ファクシミリなどがある。出力装置７１７は、例えば、コンテンツサーバ１０が行った各種処理により得られた結果を出力する。具体的には、表示装置は、コンテンツサーバ１０が行った各種処理により得られた結果を、テキストまたはイメージで表示する。他方、音声出力装置は、再生された音声データや音響データ等からなるオーディオ信号をアナログ信号に変換して出力する。

ストレージ装置７１９は、コンテンツサーバ１０の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置７１９は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス、または光磁気記憶デバイス等により構成される。このストレージ装置７１９は、ＣＰＵ７０１が実行するプログラムや各種データ、および外部から取得した各種のデータなどを格納する。

ドライブ７２１は、記録媒体用リーダライタであり、コンテンツサーバ１０に内蔵、あるいは外付けされる。ドライブ７２１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体７２７に記録されている情報を読み出して、ＲＡＭ７０５に出力する。また、ドライブ７２１は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記録媒体７２７に記録を書き込むことも可能である。リムーバブル記録媒体７２７は、例えば、ＤＶＤメディア、ＨＤ−ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア等である。また、リムーバブル記録媒体７２７は、コンパクトフラッシュ（登録商標）（ＣｏｍｐａｃｔＦｌａｓｈ：ＣＦ）、フラッシュメモリ、または、ＳＤメモリカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ ｍｅｍｏｒｙ ｃａｒｄ）等であってもよい。また、リムーバブル記録媒体７２７は、例えば、非接触型ＩＣチップを搭載したＩＣカード（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ ｃａｒｄ）または電子機器等であってもよい。

接続ポート７２３は、機器をコンテンツサーバ１０に直接接続するためのポートである。接続ポート７２３の一例として、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）ポート等がある。接続ポート７２３の別の例として、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ポート等がある。この接続ポート７２３に外部接続機器７２９を接続することで、コンテンツサーバ１０は、外部接続機器７２９から直接各種のデータを取得したり、外部接続機器７２９に各種のデータを提供したりする。

通信装置７２５は、例えば、通信網７３１に接続するための通信デバイス等で構成された通信インターフェースである。通信装置７２５は、例えば、有線または無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、またはＷＵＳＢ（Ｗｉｒｅｌｅｓｓ ＵＳＢ）用の通信カード等である。また、通信装置７２５は、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）用のルータ、または、各種通信用のモデム等であってもよい。この通信装置７２５は、例えば、インターネットや他の通信機器との間で、例えばＴＣＰ／ＩＰ等の所定のプロトコルに則して信号等を送受信することができる。また、通信装置７２５に接続される通信網７３１は、有線または無線によって接続されたネットワーク等により構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信または衛星通信等であってもよい。

以上、本発明の実施形態に係るコンテンツサーバ１０の機能を実現可能なハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用するハードウェア構成を変更することが可能である。

また、本発明の実施形態に係る情報処理装置２０およびスイッチ３０のハードウェア構成は、本発明の実施形態に係るコンテンツサーバ１０のハードウェア構成と同様であって、同様の効果を奏するものであるため、詳細な説明は省略する。

（まとめ）
以上説明したように、本発明の実施形態によれば、ＩＰＴＶの加入者宅へのアクセスネットワークのデータ帯域が限定される環境でも、高品位な映像にて高速チャンネルスイッチを利用者に提供できるＩＰＴＶシステムを、高価なネットワーク機器や特殊コンテンツサーバをアクセスネットワーク近傍に設置せずに実現することが可能である。

また、本発明の実施形態によれば、チャンネル切り替え時に映像が表示されないブラックアウト期間、または、切り替え前のチャンネルの映像を停止状態で表示しておく時間を最小にすることが可能であり、視聴者にはシームレスなチャンネル切り替えを提供することができる。

また、本発明の実施形態によれば、各チャンネルに割り当てられた何れのマルチキャストストリームを受信してもチャンネル視聴ができるため、マルチキャストアドレスの選択を行わない端末（既存の端末）も共存したＩＰＴＶシステムを構築可能である。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

１ コンテンツ配信システム
１０ コンテンツサーバ
１１Ａ 第１処理部
１１Ｂ 第２処理部
２０ 情報処理装置
３０ スイッチ
１０１ 第１符号化部
１０３ 第２符号化部
１０５ 第１配信部
１０７ 第２配信部
１０９，１１１ 記憶部
２０１ チャンネル選択部
２０３ コンテンツ取得部
２０５ コンテンツ再生部
２０７ 記憶部
３０１ バッファ
３０３ ストリーム解析部
３０５ 配信要求処理部
３０７ 配信切替部

Claims (11)

1. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームをそれぞれ解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するストリーム解析部と、
   前記映像音声コンテンツを再生する情報処理装置から送信された映像音声コンテンツの配信要求を受信するとともに、前記ストリーム解析部により検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択する配信要求処理部と、
   前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記配信要求処理部により選択された前記圧縮データストリームへと切り替える配信切替部と、
   を備えるネットワーク機器。
2. 前記配信要求処理部は、
   前記基準圧縮映像データが配信されてから次の前記基準圧縮映像データが配信されるまでの時間間隔に関する情報を保持しており、
   前記ストリーム解析部により検出された最も新しい基準圧縮映像データの配信時刻と、前記時間間隔に関する情報とに基づいて、前記複数の圧縮データストリームそれぞれについて次に前記基準圧縮映像データが配信される時刻を算出し、
   算出した時刻までの時間が最も短い前記圧縮データストリームを、前記情報処理装置へ配信する圧縮データストリームとして選択する、請求項１に記載のネットワーク機器。
3. 前記配信切替部は、前記配信要求処理部によって算出された時刻までに前記配信要求処理部によって選択された前記圧縮データストリームへの切替が完了するように、当該圧縮データストリームへの切替処理を行う、請求項２に記載のネットワーク機器。
4. 前記ネットワーク機器は、前記配信切替部による前記圧縮データストリームの切替処理に要する遅延時間分の圧縮データストリームを一時的に記憶するバッファを更に備え、
   前記配信切替部は、前記バッファに格納されている前記圧縮データストリームを前記情報処理装置へと配信しつつ、前記圧縮データストリームの切替処理を行う、請求項１に記載のネットワーク機器。
5. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームの配信切替を行うネットワーク機器に対して、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を要求し、前記ネットワーク機器から前記映像音声コンテンツを取得するコンテンツ取得部を備える、情報処理装置。
6. 前記複数の圧縮データストリームには、互いに異なる固有のネットワークアドレスが割り当てられており、
   前記コンテンツ取得部は、
   取得すべき前記映像音声コンテンツに対応する全ての前記圧縮データストリームに割り当てられたネットワークアドレスを前記ネットワーク機器に対して通知し、
   前記ネットワーク機器に通知したネットワークアドレスのうち、当該ネットワーク機器から配信された前記圧縮データストリームに割り当てられた前記ネットワークアドレスを、前記取得すべき前記映像音声コンテンツに対応するネットワークアドレスとして設定する、請求項５に記載の情報処理装置。
7. ネットワーク機器のストリーム解析部が、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームをそれぞれ解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するステップと、
   ネットワーク機器の配信要求処理部が、前記映像音声コンテンツを再生する情報処理装置から送信された映像音声コンテンツの配信要求を受信するステップと、
   ネットワーク機器の配信要求処理部が、前記基準圧縮映像データが配信された時刻を検出するステップにて検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択するステップと、
   ネットワーク機器の配信切替部が、前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記圧縮データストリームを選択するステップにより選択された前記圧縮データストリームへと切り替えるステップと、
   を含む、ストリーム切替方法。
8. 情報処理装置のコンテンツ取得部が、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームの配信切替を行うネットワーク機器に対して、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を要求するステップと、
   情報処理装置のコンテンツ取得部が、前記ネットワーク機器から配信された前記映像音声コンテンツに対応する前記圧縮データストリームを取得するステップと、
   を含む、情報処理方法。
9. コンピュータに、
   映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームをそれぞれ解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するストリーム解析機能と、
   前記映像音声コンテンツを再生する情報処理装置から送信された映像音声コンテンツの配信要求を受信するとともに、前記ストリーム解析機能により検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択する配信要求処理機能と、
   前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記配信要求処理機能により選択された前記圧縮データストリームへと切り替える配信切替機能と、
   を実現させるためのプログラム。
10. コンピュータに、
    映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように一つの映像音声コンテンツから生成された複数の圧縮データストリームの配信切替を行うネットワーク機器に対して、取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を要求し、前記ネットワーク機器から前記映像音声コンテンツを取得するコンテンツ取得機能を実現させるためのプログラム。
11. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずにそれ以降の映像信号の復号を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮映像データの配信される時刻が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部を有するコンテンツサーバと、
    前記コンテンツサーバが配信する複数の配信された前記映像音声コンテンツに対応する前記圧縮データストリームを再生する情報処理装置と、
    １または複数の前記コンテンツサーバから配信された前記複数の圧縮データストリームを、当該圧縮データストリームの配信を希望する前記情報処理装置へと配信するネットワーク機器と、
    を含み、
    前記ネットワーク機器は、
    １または複数の前記コンテンツサーバから配信された前記複数の圧縮データストリームを解析して、前記基準圧縮映像データが配信された最も新しい時刻を検出するストリーム解析部と、
    前記情報処理装置から送信された映像音声コンテンツの配信要求を受信するとともに、前記ストリーム解析部により検出された前記基準圧縮映像データの配信時刻を利用して、前記配信要求に関する前記映像音声コンテンツに対応する前記複数の圧縮データストリームの中から、前記情報処理装置へ配信する圧縮データストリームを選択する配信要求処理部と、
    前記配信要求を送信した前記情報処理装置に配信される前記圧縮データストリームを、前記配信要求処理部により選択された前記圧縮データストリームへと切り替える配信切替部と、
    を有し、
    前記情報処理装置は、
    取得すべき前記映像音声コンテンツに対応する前記複数の圧縮データストリーム全ての配信を前記ネットワーク機器に要求し、前記ネットワーク機器から前記映像音声コンテンツを取得するコンテンツ取得部を有する、コンテンツ配信システム。
    

Images