JP2009284282A - コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システム - Google Patents

Abstract

【課題】既存のネットワーク機器や端末の再生システムを大幅に変更することなく、簡易な方法でＩＰＴＶシステムにおけるチャンネル切り替えの高速化を実現することが可能な、コンテンツサーバ、情報処理装置、ネットワーク機器、コンテンツ配信方法、情報処理方法およびコンテンツ配信システムを提供する。
【解決手段】本発明に係るコンテンツサーバは、基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の符号化部から、当該一の符号化部が生成した一の圧縮データストリームを取得して配信する、複数の配信部と、を設けた。
【選択図】図１

Description

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

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

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

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

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

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

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

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

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

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

上記課題を解決するために、本発明のある観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、を備える、コンテンツサーバが提供される。

ここで、基準圧縮映像データとは、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータであり、圧縮された時系列データには、複数の基準圧縮映像データが存在することができる。

かかる構成によれば、複数の符号化部は、基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの映像音声コンテンツから複数の圧縮データストリームを生成し、複数の配信部は、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の符号化部から、当該一の符号化部が生成した一の圧縮データストリームを取得して配信する。

前記複数の符号化部それぞれは、圧縮および符号化条件が同一となるように、前記映像音声コンテンツを符号化してもよい。

前記複数の配信部それぞれは、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を出力することが好ましい。

前記コンテンツサーバ内のクロックは、当該コンテンツサーバの外部に位置する基準クロックサーバから提供される基準クロックに同期しており、前記複数の符号化部は、同期している前記クロックに基づいて前記基準圧縮映像データ配信予定時刻の計測を行ってもよい。

前記コンテンツサーバは、一の前記符号化部と一の前記配信部とを含む装置が並列に複数台接続されていてもよい。また、前記複数の符号化部および前記複数の配信部は、同一の装置内に設けられていてもよい。

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

前記取得ストリーム選択部は、前記コンテンツサーバが出力した、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を取得し、取得した前記基準圧縮映像データ配信予定時刻情報に基づいて、取得する前記圧縮データストリームを選択してもよい。

前記取得ストリーム選択部は、取得した圧縮データストリームに表示を切り替えるために要する切替所要時間と、取得するストリームの選択処理を開始した時刻とを用いて、取得した圧縮データストリームの切り替えを完了する切替完了予想時刻を算出し、算出した前記切替完了予想時刻以降の直近の基準圧縮映像データ配信予定時刻を有する前記圧縮データストリームを選択してもよい。

前記取得ストリーム選択部は、各圧縮データストリームに対応した前記基準圧縮映像データ配信予定時刻が全て前記切替完了予想時刻よりも前である場合には、いずれのデータストリームも選択しなくてもよい。

前記取得ストリーム選択部は、前記配信予定時刻と、選択した前記圧縮データストリームの前記切替完了予想時刻との間の時間間隔が所定の閾値以下である場合に、前記圧縮データストリームの選択結果を前記コンテンツ取得部に通知するようにしてもよい。

前記コンテンツ取得部は、ＩＧＭＰにより前記取得ストリーム選択部が選択した前記圧縮データストリームの切り替え制御を行ってもよい。

上記課題を解決するために、本発明の更に別の観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、を備えるコンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、取得した前記圧縮データストリームを、ネットワークを介して接続された情報処理装置に対して配信する配信制御部と、を備える、ネットワーク機器が提供される。

上記課題を解決するために、本発明の更に別の観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように入力された一つの映像音声コンテンツを符号化し、前記一つの映像音声コンテンツから複数の圧縮データストリームを生成する符号化ステップと、生成された前記複数の圧縮データストリームそれぞれを、同時に配信するステップと、を含むコンテンツ配信方法が提供される。

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

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

上記課題を解決するために、本発明の更に別の観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声信号から複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、を備えるコンテンツサーバと、前記コンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、を備える情報処理装置と、を含む、コンテンツ配信システムが提供される。

上記課題を解決するために、本発明の更に別の観点によれば、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、を備えるコンテンツサーバと、前記コンテンツサーバが配信する前記複数の圧縮データストリームの中から、再生を希望する前記圧縮データストリームを通知し、取得した前記圧縮データストリームを再生する情報処理装置と、前記情報処理装置から受信した通知に基づいて、前記コンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、取得した前記圧縮データストリームを、ネットワークを介して前記情報処理装置に対して配信する配信制御部と、を備えるネットワーク機器と、を含む、コンテンツ配信システムが提供される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

配信予定時刻情報送信サーバ３０は、個々のコンテンツサーバ１０から出力される基準圧縮映像データ配信予定時刻情報をそれぞれ受信して、コンテンツ配信システム１上に存在するコンテンツサーバ１０全ての圧縮映像データ配信予定時刻情報を取りまとめる。また、配信予定時刻情報送信サーバ３０は、取りまとめた圧縮映像データ配信予定時刻情報を、システムに接続されている情報処理装置２０に対して、所定の時間間隔（例えば、１０ミリ秒〜２０ミリ秒周期）で送信する。なお、上述の圧縮映像データ配信予定時刻情報については、以下で詳細に説明する。

基準クロックサーバ４０は、例えば１万分の１秒精度の時刻情報源を有するサーバであり、例えばＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用して、コンテンツ配信システム１に接続されているコンテンツサーバ１０や情報処理装置２０等のコンピュータの内部クロックを、基準クロックサーバ４０が有する時刻情報源に同期させる。

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

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

本実施形態に係るコンテンツサーバ１０は、当該コンテンツサーバ１０内のクロックがコンテンツ配信システム１上に存在する基準クロックサーバ４０と同期している。コンテンツサーバ１０は、サーバの起動時や、コンテンツサーバ１０の管理者が内部クロックの更新命令を入力した時などの任意のタイミングで、例えばＮＴＰを用いて内部クロックを基準クロックサーバ４０の時刻と同期させることが可能である。

本実施形態に係るコンテンツサーバ１０の各処理部は、基準クロックサーバ４０に同期している内部クロックの現在時刻を参照しながら、所定の処理を実施する。

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

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

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

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

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

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

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

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

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

また、第１配信部１０５および第２配信部１０７は、第１符号化部１０１および第２符号化部１０３によって生成された基準圧縮映像データが配信される配信予定時刻を算出し、この配信予定時刻が記載された基準圧縮映像データ配信予定時刻情報（以下、配信予定時刻情報と略記する。）を定期的に生成する。配信予定時刻の算出方法については、以下で改めて詳細に説明する。

第１配信部１０５および第２配信部１０７は、それぞれが生成した配信予定時刻情報を、配信予定時刻情報送信サーバ３０へと定期的に出力する。また、第１配信部１０５および第２配信部１０７は、生成した配信予定時刻情報を、それぞれ記憶部１０９および記憶部１１１に記録してもよい。

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

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

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

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

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

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

本実施形態に係る情報処理装置２０は、当該情報処理装置２０内のクロックがコンテンツ配信システム１上に存在する基準クロックサーバ４０と同期している。情報処理装置２０は、装置の起動時や、情報処理装置２０の使用者が内部クロックの更新命令を入力した時などの任意のタイミングで、例えばＮＴＰを用いて内部クロックを基準クロックサーバ４０の時刻と同期させることが可能である。

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

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

コンテンツ取得部２０３は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等から構成されており、配信されている複数のチャンネルの中から、チャンネル選択部２０１から伝送された信号に対応したチャンネルが配信しているコンテンツを取得する。本実施形態に係るコンテンツ配信システムでは、１つのチャンネルに属するコンテンツに対して、複数の圧縮データストリームが配信されているため、コンテンツ取得部２０３は、後述する取得ストリーム選択部２０５から通知された選択結果に基づいて、コンテンツの取得を行う。

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

取得ストリーム選択部２０５は、例えば、ＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等から構成されており、基準クロックサーバ４０に同期している内部クロックの現在時刻を参照しながら、以下で説明するような処理を実施する。

取得ストリーム選択部２０５は、個々のコンテンツサーバ１０から出力され、配信予定時刻情報送信サーバ３０によって取りまとめられた配信予定時刻情報を、配信予定時刻情報送信サーバ３０から定期的に受信する。取得ストリーム選択部２０５は、受信した配信予定時刻情報を参照して、コンテンツ取得部２０３から通知されたチャンネルが配信している複数の圧縮データストリームの中から、取得すべき圧縮データストリームを選択する。

より詳細には、取得ストリーム選択部２０５は、コンテンツ取得部２０３から通知されたチャンネルの圧縮データストリームを取得して表示させるために要する切替所要時間と、取得する圧縮データストリームの選択処理を開始した時刻とを用いて、取得した圧縮データストリームの表示を完了する切替完了予想時刻を算出する。ここで、上述の切替所要時間は、現在表示しているチャンネルから異なるチャンネルにチャンネル切り替えを行った際に、新たなチャンネルで配信されているコンテンツが表示されるまでに要する時間を意味するものである。取得ストリーム選択部２０５は、算出した切替完了予想時刻と、配信予定時刻情報送信サーバ３０から取得した配信予定時刻情報とを比較して、切替完了予想時刻以降の直近の配信予定時刻を有する圧縮データストリームを選択する。

また、コンテンツ取得部２０３から通知されたチャンネルが配信している複数の圧縮データストリームに対応した配信予定時刻が、全て切替完了予想時刻よりも前である場合には、取得ストリーム選択部２０５は、いずれの圧縮データストリームの選択を行わない。その代わりに、新たに配信予定時刻情報送信サーバ３０から通知される配信予定時刻情報に基づいて、再度圧縮データストリームの選択処理を実行する。

配信予定時刻情報は、例えば数十ミリ秒周期のような非常に短い周期で配信予定時刻情報送信サーバ３０から送信されるものであるため、取得ストリーム選択部２０５が上述のような「選択を行わない」という判断をしたとしても、次の適切なタイミングにて選択されるので、視聴者の使用感が損なわれるような問題は生じない。

取得ストリーム選択部２０５は、取得すべき圧縮データストリームの選択が終了すると、選択結果を、コンテンツ取得部２０３に通知する。

なお、これらの選択処理を行うにあたって、取得ストリーム選択部２０５は、後述する記憶部２０９に記録されている各種のデータベース等を参照しながら処理を行うことが可能である。

また、取得ストリーム選択部２０５は、配信予定時刻と、選択した圧縮データストリームの切替完了予想時刻との間に、所定の閾値超過の時間間隔が存在する場合には、取得すべき圧縮データストリームの選択結果をコンテンツ取得部２０３に通知しなくてもよい。その代わりに、新たに配信予定時刻情報送信サーバ３０から通知される配信予定時刻情報に基づいて、再度圧縮データストリームの選択処理を実行する。換言すれば、取得ストリーム選択部２０５は、配信予定時刻と、選択した圧縮データストリームの切替完了予想時刻との間の時間間隔が、所定の閾値以下の場合に、取得すべき圧縮データストリームの選択結果をコンテンツ取得部２０３に通知する。

切替完了予想時刻と、配信予定時刻との間に、所定の閾値以上の時間間隔が存在する場合には、取得ストリーム選択部２０５の選択結果に基づいて表示切り替えを行ったとしても、表示画面は、画面に黒などの色を表示するブラックアウト状態のままとなる。そのため、新たに配信予定時刻情報送信サーバ３０から通知される配信予定時刻情報を待っている間は、切り替え前のチャンネルのストリームが継続して取得されているので、その映像を画面表示続けることで、視聴者の使用感を損なうことなく、圧縮データストリームの選択処理を再度実行することができる。

上述のような取得ストリームの選択方法については、以下で改めて詳細に説明する。

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

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

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

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

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

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

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

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

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

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

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

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

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

［配信予定時刻の算出について］
次に、図６を参照しながら、本実施形態に係るコンテンツサーバ１０が備える各配信部が実施する配信予定時刻の算出方法について、詳細に説明する。図６は、本実施形態に係るコンテンツサーバが実施する配信予定時刻の算出方法について説明するための説明図である。

本実施形態に係るコンテンツサーバ１０が備える各配信部１０５，１０７は、ＩＤＲピクチャの配信予定時刻の算出を行うが、この算出処理は、以下の式を用いて行われる。

算出時刻ＣでのＩＤＲピクチャ配信予定時刻：時刻Ｆ＝時刻Ｃ＋時間Ｄ＋時間Ｅ
・・・（式１）

ここで、上記式１において、時間Ｄは、図６に示したように、時間Ｄ＝（時刻Ｂ−時刻Ａ）を用いて算出することができる。この時間Ｄは、各符号化部から生成されたＩＤＲピクチャのデータを含むＭＰＥＧ２−ＴＳパケットが生成されてから、ＩＰマルチパケットにて送出されるまでの遅延時間として考えることができる。

図６における時刻Ｂは、ＩＤＲピクチャのデータが含まれる最初のＭＰＥＧ２−ＴＳパケットの生成時間であり、時刻Ａは、そのＭＰＥＧ２−ＴＳパケットが各配信部から送信される時刻である。この遅延時間Ｄは、通常は、ほぼ一定であるので、一回の計測で得られた値を使用してもよいし、固定値をつかってもよいし、ＩＤＲピクチャの送出ごとに計算してもよい。

図６における時間Ｅは、時刻Ｃの時点における次のＩＤＲピクチャの最初のデータが含まれるＭＰＥＧ２−ＴＳパケットの生成までにかかる時間である。時間Ｅは、時刻Ｃの経過とともに更新されるので、ＩＤＲピクチャ配信予定時刻の計測のたびに、それぞれの符号化部に問い合わせる必要がある。通常、リアルタイムエンコードでは、エンコードによる遅延を小さくするために、ＩＤＲピクチャ配信予定時刻は符号化部が予測した時間となる。例えば、各符号化部が、毎秒１秒ごとに固定間隔でＩＤＲピクチャを生成するように設定されている場合は、時間Ｅは容易に求めることができる。そうではない場合も、符号化部によって生成され記憶部等に記録されているエンコーダバッファ管理情報を元に、時間Ｅの予測は十分可能である。既に時刻Ｃの時点で未送出のＩＤＲパケットが存在する場合は、時間Ｅはマイナスの値をとる。

本実施形態に係るコンテンツサーバが備える各配信部は、上述のような方法を用いて、基準圧縮映像データ配信予定時刻を算出する。配信部は、このようにして算出された配信予定時刻を、配信部自身に割り当てられている所在情報（例えば、ＩＰアドレス番号）に関連付けて、配信予定時刻情報として配信予定時刻情報送出サーバ４０に出力する。

［配信予定時刻情報の例について］
続いて、図７を参照しながら、上述のような方法で算出された配信予定時刻情報の具体的な記述例について、詳細に説明する。図７は、本実施形態に係る基準圧縮映像データ配信予定時刻情報の具体例を説明するための説明図である。

基準圧縮映像データ配信予定時刻情報の一例であるＩＤＲピクチャ配信予定時刻情報は、例えば図７に示したように、ＩＰヘッダと、ＵＤＰヘッダと、ＲＴＰヘッダと、ＲＴＰペイロードと、から構成されている。ＩＤＲピクチャ配信予定時刻情報は、図７に示したように、ＵＤＰパケットのＲＴＰペイロードに格納され、１２バイトのヘッダとともにＭ個のＩＤＲピクチャ送出予定時刻レコードが記述される。

ＩＤＲピクチャ配信予定時刻情報のヘッダには、このＵＤＰパケットがＩＤＲピクチャ配信予定時刻情報のパケット形式であることを示す識別子や、バージョン番号等が指定される。ひとつのＭＰＥＧストリームのＩＤＲピクチャ配信予定時刻情報は、ＩＰマルチキャストアドレス（４バイト）と、配信予定時刻（４バイト）とからなる８バイトで表記され、ひとつのＵＤＰパケットは、Ｍ＝１５０個ほどのＭＰＥＧストリームに対する配信予定時刻が記述可能である。

ひとつのレコードのＩＰマルチキャストアドレスは、以下で説明するようなブロードキャストディスカバリーレコードの各チャンネルのＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓに対応するものであり、該当するＩＰマルチキャストのストリームのＩＤＲピクチャを含むＩＰパケットが、次に配信される予定時刻が記録されている。

配信予定時刻は、例えば１００分の１秒程度の精度で十分であるが、１０００分の１秒つまり１ミリ秒の精度とすることが好ましい。この配信予定時刻は、少なくとも同じチャンネルのＩＰマルチキャストストリームを送出する各処理部１１間において、同じクロックで計測されていれば十分であるが、すべての処理部にて同じクロックにて配信予定時刻の計測をおこなってもよい。

次に、図７を参照しながら、コンテンツ配信システム１の各コンテンツサーバ１０で計測されたＩＤＲピクチャの配信予定時刻情報を集計して、端末である情報処理装置２０に伝送する仕組みを説明する。

前述のように、すべてのコンテンツサーバ１０および情報処理装置２０のクロックは、ＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）によってネットワークに接続された基準クロックサーバ４０のクロックと同期するように設定されており、各コンテンツサーバ１０は、この基準クロックにＮＰＴにて自身のクロックを同期させ、同期したクロックにて次のＩＤＲピクチャが配信される予定時刻を算出する。コンテンツサーバ１０の処理部１１内に設けられた配信部は、前述のように、算出した時刻を、ＩＤＲピクチャ配信予定時刻情報送信サーバ４０に送信する。

この場合、各処理部１１の配信部は、図７で示したＵＤＰパケットを、ＩＰユニキャストにて送信する。このＵＤＰパケットには、その処理部１１が送出するＩＰパケットストリームについての配信予定時刻レコードのみ記録される。換言すれば、図７のＵＤＰパケットは、Ｍ＝１となる。ＩＤＲピクチャ配信予定時刻情報送信サーバ４０は、各コンテンツサーバ１０（より詳細には、各処理部１１）から送信されたＩＤＲピクチャ配信予定時刻を集計して、図７に示したようなＵＤＰパケットを生成する。

図１および図２に示したように、コンテンツ配信システム１上に３００チャンネル（すなわち、３００台のコンテンツサーバ１０）が存在し、各チャンネルあたり２つの処理部１１がある場合は、図７に示したＵＤＰパケットは、６００個のＩＰマルチキャストストリームの情報となる。そのため、各ＵＤＰパケットでは、Ｍ＝１５０となり、４つのＵＤＰパケットに分割されて送信される。ＵＤＰパケットの喪失の恐れがネットワーク環境においては、重複して同一のパケットを送信する。

配信予定時刻情報送信サーバ４０から送信されるＵＤＰパケットのＩＰマルチキャストアドレスは、後述するようなブロードキャストディスカバリーレコードのＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏに指定したＩＰマルチキャストアドレスである。各情報処理装置２０は、ピクチャ配信予定時刻情報を受信するためには、このＩＰマルチキャストアドレスを指定してＩＧＭＰにてマルチキャストグループへの加入をおこなう。ＩＤＲピクチャの配信時刻情報の送出は、例えば、１秒間に１００回ほどの頻度、つまり１０ミリ秒周期にておこなわれ、情報処理装置２０は、１０ミリ秒ごとに最新のＩＤＲピクチャ配信時刻情報を受信できる。

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

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

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

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

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

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

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

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

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

次に、各マルチキャストアドレスで配信されるＭＰＥＧ２−ＴＳストリームでのＩＤＲピクチャ配信予定情報の取得方法について、説明する。本実施形態では、ＤＶＢ−ＩＰ規定のブロードキャストディスカバリーレコードを拡張し、「＜ＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏ＞」というＸＭＬエレメントを記述する。「＜ＣｈａｎｎｅｌＣｈａｎｇｅＩｎｆｏ＞」のＸＭＬエレメントでは、ひとつのチャンネルあたり最大幾つのＭＰＥＧストリームがマルチキャスト配信されているかを示すデータが、「＠ＮｕｍｂｅｒＯｆＳｔｒｅａｍｓＰｅｒＣｈａｎｎｅｌ」に指定されている。また、ＩＰＴＶサービスから配信されるすべてのＭＰＥＧストリームのＩＤＲピクチャ配信予定時刻情報を取得可能な、配信予定時刻情報送信サーバ３０のマルチキャストアドレスが、「＜ＩＰＭｕｌｔｉｃａｓｔＡｄｄｒｅｓｓ＞」に指定されている。図９に示した例では、チャンネルあたり最大２つのＭＰＥＧストリームが配信されており、ＩＤＲピクチャ配信予定時刻情報は、アドレス２２４．０．１．０のポート番号１５００から取得できることが示されている。

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

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

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

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

次に、情報処理装置２０は、装置に備えられているＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等を利用して、ＩＤＲピクチャ配信予定時刻情報の配信開始要請のためのＩＧＭＰメッセージの発行と、この配信予定時刻情報に関するマルチキャストパケットの受信を開始する（ステップＳ１０３）。

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

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

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

情報処理装置２０がＩＤＲピクチャ配信予定時刻情報を配信しているマルチキャストグループの配信開始を指示するには、図１２Ａに示したようなＩＧＭＰメッセージを発行する。「Ｒｅｃｏｒｄ Ｔｙｐｅ」の欄に指定されている「１」という値は、ＭＯＤＥ＿ＩＳ＿ＩＮＣＬＵＤＥを示し、上述のステップＳ１０１にて取得したマルチキャストアドレス（例では２２４．０．１．０）に対して、マルチキャストグループに参加することを示すものである。このＩＧＭＰによるマルチキャストグループへの参加により、配信予定時刻情報送信サーバ３０から、ＩＤＲピクチャ配信予定時刻情報が定期的（例えば、１０ミリ秒周期）に情報処理装置２０へ配信されることとなる。情報処理装置２０は、ＩＤＲピクチャ配信予定時刻情報を受信し、記憶部２０９に常に最新の情報を保持しておく。

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

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

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

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

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

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

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

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

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

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

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

その後、情報処理装置２０は、装置に備えられているＣＰＵ、ＲＯＭ、ＲＡＭ、通信装置等を利用して、ステップＳ１０３にて開始したＩＤＲピクチャ配信予定時刻情報の配信を停止させ、配信予定時刻情報のマルチキャストパケットの受信も終了する（ステップＳ１２５）。情報処理装置２０は、図１２Ｂに示したようなＩＧＭＰメッセージを送信することで、配信を停止可能である。ここで、図１２Ｂにおける「ＲｅｃｏｒｄＴｙｐｅ＝２」は、ＭＯＤＥ＿ＩＳ＿ＥＸＬＣＵＤＥであることを示し、２２４．０．１．０のマルチキャストグループからの離脱を意味する。

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

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

コンテンツ取得部２０３から依頼を受けた取得ストリーム選択部２０５は、記憶部２０９等に記録されている最新のＩＤＲピクチャ配信予定時刻情報から、パラメータ「ＳｅｌｅｃｔＣｈａｎ」に該当するチャンネル情報を取得する（ステップＳ２０１）。

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

次に、取得ストリーム選択部２０５は、最新のＩＤＲピクチャ配信予定時刻情報から、各マルチキャストアドレスの配信予定時刻情報レコードを検索し、ＩＤＲピクチャ配信予定時刻をそれぞれ「ＮｅｘｔＴｉｍｅ１」と「ＮｅｘｔＴｉｍｅ２」に設定する。ただし、ＩＤＲピクチャの配信時刻はコンテンツサーバ１０の各配信部から送出された時刻であり、本来、ＩＤＲピクチャを含む先頭のＭＰＥＧ２−ＴＳパケットが情報処理装置２０に届くまでには遅延がある。そのため、遅延時間が大きく無視できない場合は、コンテンツサーバ１０から情報処理装置２０までのネットワークの条件に合わせて、「ＮｅｘｔＴｉｍｅ１」と「ＮｅｘｔＴｉｍｅ２」に適宜遅延時間を加算する必要がある。

次に、取得ストリーム選択部２０５は、マルチキャスト配信の切替完了予想時刻を算出する（ステップＳ２０３）。この切替完了予想時刻は、直ちにＩＧＭＰメッセージを発行して配信の開始や切り替えを行った場合に、新規に加入したマルチキャストグループの最初のパケットが到着するまでの予想時間である。この切替完了予想時刻「ＳｗｉｔｃｈＴｉｍｅ」は、現在時刻に切替所要時間を加算することで得ることができる。ここで、切替所要時間は、以下に示した時間の総和となる。

（１） 情報処理装置２０がＩＧＭＰメッセージを発行するまでに要する時間
（２） ＩＧＭＰメッセージがＩＧＭＰプロクシーをおこなっているエッジスイッチ、（例えば、ＤＳＬＡＭ）に到達するまでの所要時間
（３） エッジスイッチが、現在、端末の接続されているアクセスネットワークに配信しているマルチキャストグループのパケットの配信を停止し、新たに加入したマルチキャストグループのパケットの配信を開始するまでの所要時間
（４） エッジスイッチが配信を開始した最初のパケットが情報処理装置２０に到達するまでの所要時間
（５） 情報処理装置２０が最初のパケットを受信して保存するのに要する時間

上記（１）〜（５）の値は、ＩＰＴＶサービスのネットワークおよび情報処理装置２０の性能に依存し、情報処理装置２０やネットワークの条件に対応する切替所要時間の最大値が、予め情報処理装置２０に設定されているものとする。例えば、切替所要時間の最大値を、２０ミリ秒程度に設定することが可能である。

また、上記（３）において、加入者宅に複数台の情報処理装置２０が接続されている場合は、パケット配信の停止に際して、他の情報処理装置２０が同じマルチキャストグループへ加入していないかを確認するために要する時間も含む。通常、この確認は、ＲＦＣ−３３７６に規定されているように、定期的なＩＧＭＰクエリーメッセージによって行われる。また、複数の情報処理装置２０が、個別のマルチキャストグループへの加入、つまり、複数の情報処理装置２０にて異なるチャンネルを視聴する場合には、アクセスネットワークには、複数のチャンネル分のマルチキャストを流すのに十分なデータ帯域が必要となる。このためのネットワークの帯域保障には、例えば、ＩＭＳ（ＩＰ Ｍｕｌｔｉｍｅｄｉａ Ｓｕｂｓｙｓｔｅｍ）などのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御が利用可能である。

以下、ステップＳ２０５〜ステップＳ２２１にかけては、選局しようとしているチャンネルのマルチキャストアドレスのいずれを選択するかの判断、および、配信の開始または切り替えのために、ＩＧＭＰの発行をすべきタイミングについての決定を実施している。本実施形態に係る取得ストリーム選択部２０５は、以下の４つの条件に基づいて、アドレス選択およびタイミング決定を判断している。

（Ａ） ＩＤＲピクチャを含むＩＰパケットの受信が、切替完了予測時刻ＳｗｉｔｃｈＴｉｍｅの時点で間に合わない場合は、そのマルチキャストアドレスは選択しない。
（Ｂ） ＩＤＲピクチャを含むＩＰパケットが最も早く受信できるマルチキャストアドレスを選択する。この条件により高速チャンネル切り替えが実現可能である。
（Ｃ） （Ａ）および（Ｂ）の結果選択が行われなかった場合、次のＩＤＲピクチャ配信予定時刻情報のパケットが受信するのを待って、ステップＳ２０１から処理を実施する。
（Ｄ） （Ａ）および（Ｂ）の結果選択が行われたが、ＩＤＲピクチャを含むＩＰパケット到着時刻と切替完了予定時刻ＳｗｉｔｃｈＴｉｍｅとの差が大きい場合は、配信の開始または切り替えは行わず、次のＩＤＲピクチャ配信予定時刻情報のパケットまで待って、ステップＳ２０１からの処理を実施する。

上記（Ｄ）の条件は、以下のような理由のために設定される。すなわち、直ちに表示の開始や切り替えを実施したとしても、パケットの受信を開始してＩＤＲピクチャが到着するまでは、情報処理装置２０のコンテンツ再生部２０７は映像を伸張できない。そのため、画面表示が出ない期間（以下、ブラックアウト期間と称する。）が生じてしまう。（Ｄ）の条件により、ブラックアウト期間を短縮することが可能である。シームレスな映像の開始または切り替えには、ブラックアウト期間をできるだけ短くするのが望ましいが、ＩＤＲピクチャの配信予定時刻のパケットの送出周期よりも長くする必要がある。そのため、ブラックアウト期間の最大値（以下、ブラックアウト許容時間と称する。）は、例えば、４０ミリ秒に設定することが好ましい。

以下に、上記（Ａ）〜（Ｄ）の条件について、具体的な例を示しながら説明する。図１４Ａおよび図１４Ｂは、マルチキャストアドレスの選択についての場合分けを説明するための説明図であり、図１５は、開始または切り替えタイミングの場合分けを説明するための説明図である。

まず、図１４Ａおよび図１４Ｂを参照しながら、これらの図に示した６つの具体的な場合について、上記（Ａ）〜（Ｃ）の条件がどのように適用されるかを説明する。

条件（Ａ）より、図１４Ａに示した（ケース２）の場合は、「Ａｄｄｒｅｓｓ１」が選択され、（ケース４）の場合は、「Ａｄｄｒｅｓｓ２」が選択される。また、条件（Ａ）により、図１４Ｂに示した（ケース５）および（ケース６）では、マルチキャストアドレスの切り替えは行われない。そのため、条件（Ｃ）に基づいて、次のＩＤＲピクチャ配信予定時刻情報のパケットが受信するのを待って、ステップＳ２０１から処理を実施する。

また、条件（Ｂ）により、図１４Ａに示した（ケース１）では「Ａｄｄｒｅｓｓ１」が選択され、（ケース３）では「Ａｄｄｒｅｓｓ２」が選択されることとなる。

上述のような条件（Ａ）〜条件（Ｃ）に基づく判断が、図１３におけるステップＳ２０５〜ステップＳ２１７に該当する。

ここで、条件（Ａ）および条件（Ｂ）により、「Ａｄｄｒｅｓｓ１」が選択された場合には、チャンネル選択情報として、以下の値が設定されることとなる。すなわち、選択されたマルチキャストアドレスを示すパラメータ「ＳｅｌｅｃｔＡｄｄｒ」には、「Ａｄｄｒｅｓｓ１」が設定され、ＩＤＲピクチャの配信予定時刻を示すパラメータ「ＮｅｘｔＴｉｍｅ」には、「ＮｅｘｔＴｉｍｅ１」が設定される（ステップＳ２１１）。

同様に、条件（Ａ）および条件（Ｂ）により、「Ａｄｄｒｅｓｓ２」が選択された場合には、チャンネル選択情報として、以下の値が設定されることとなる。すなわち、選択されたマルチキャストアドレスを示すパラメータ「ＳｅｌｅｃｔＡｄｄｒ」には、「Ａｄｄｒｅｓｓ２」が設定され、ＩＤＲピクチャの配信予定時刻を示すパラメータ「ＮｅｘｔＴｉｍｅ」には、「ＮｅｘｔＴｉｍｅ２」が設定される（ステップＳ２１５）。

続いて、図１５を参照しながら、上記（Ｄ）の条件について、具体的な例を示しながら説明する。この条件判定は、図１３に示したステップＳ２１９に該当する。

条件（Ａ）および（Ｂ）により、図１５に示した（ケース１）では双方のマルチキャストアドレスは選択されないため、条件（Ｃ）により、マルチキャストアドレスの切り替えは行われない。また、図１５に示した（ケース２）の場合は、切り替え後のブラックアウト時間が許容値（例えば、４０ミリ秒）より大きい場合であり、条件（Ｄ）により、マルチキャストアドレスの切り替えは行われない。また、図１５に示した（ケース３）の場合は、条件（Ｄ）を満たさないため、選択したマルチキャストアドレスの切り替えが行われる。

上述のような条件判定に基づき、取得ストリーム選択部２０５によって選局チャンネルのマルチキャストアドレスの選局およびタイミングの決定がなされると、選局結果が、取得ストリーム選択部２０５からコンテンツ取得部２０３へと伝送される。コンテンツ取得部２０３は、選局結果に基づいてＩＧＭＰメッセージを発行して、情報処理装置２０が接続しているアクセスネットワークへ配信されるマルチキャストパケットの配信切り替えを行う（ステップＳ２２１）。このＩＧＭＰメッセージの発行は、図１１Ａおよび図１１Ｂに示したＲＦＣ−３３７６規定のＩＧＭＰバージョン３のレポートフォーマットにて行われる。

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

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

これにより、コンテンツ取得部２０３は、「ＳｅｌｅｃｔＡｄｄｒｅｓｓ」のマルチキャストパケットの受信を開始することとなる（ステップＳ２２３）。

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

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

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

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

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

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

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

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

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

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

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

また、本発明に係る実施形態では、ＩＤＲピクチャの配信予定時刻情報は、次に送出される一つのＩＤＲピクチャのみ端末である情報処理装置２０に送信した。ここで、ＩＤＲピクチャの配信予定時刻レコードに複数のＩＤＲピクチャについての配信予定時刻を指定して送信するようにすれば、情報処理装置２０は、より厳密にチャンネル選択時におけるマルチキャストアドレスの選択を行うことができるのは自明である。

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

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

また、本発明に係る実施形態では、端末である情報処理装置２０にＩＤＲピクチャの配信予定時刻情報を送信し、情報処理装置２０が、チャンネルのマルチキャストアドレスの選択およびアクセスネットワークに送信するマルチキャストパケットの切り替のタイミングの判断を行った。ここで、ＩＤＲピクチャの配信予定時刻を、実際に配信切り替えを実行するＩＧＭＰスヌーピングをおこなうエッジスイッチ、または、エッジルータに配信し、情報処理装置２０は、チャンネル選局処理が開始した時点で、直ちにマルチキャスト配信切り替え指示を行うようにする。指示を受信したエッジスイッチ、エッジルータは、ＩＤＲピクチャの配信予定情報を用いて、図１３に示した情報処理装置の選局処理と同等の判断にて、マルチキャストアドレスの選択および配信切り替えタイミングを制御してもよい。

この場合には、エッジスイッチ、エッジルータ等のネットワーク機器は、図３に示した情報処理装置２０が備える各処理部と同様の機能を有する処理部（例えば、コンテンツ取得部および取得ストリーム選択部）を有し、さらに、取得した圧縮データストリームを、所定のネットワークを介して情報処理装置２０へと配信する配信制御部を備えることが好ましい。かかる処理部を有するネットワーク機器は、エッジサーバとして機能することが可能となる。

＜ハードウェア構成について＞
次に、図１８を参照しながら、本発明の各実施形態に係るコンテンツサーバ１０および情報処理装置２０のハードウェア構成について、詳細に説明する。図１８は、本実施形態に係るコンテンツサーバ１０および情報処理装置２０のハードウェア構成を説明するためのブロック図である。

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

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

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

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

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

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

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

接続ポート７２３は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ｉ．Ｌｉｎｋ等のＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）ポート、ＲＳ−２３２Ｃポート、光オーディオ端子、ＨＤＭＩ（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ Ｍｕｌｔｉｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）ポート等の、機器をコンテンツサーバ１０および情報処理装置２０に直接接続するためのポートである。この接続ポート７２３に外部接続機器７２９を接続することで、コンテンツサーバ１０および情報処理装置２０は、外部接続機器７２９から直接音響信号データや画像信号データを取得したり、外部接続機器７２９に音響信号データや画像信号データを提供したりする。

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

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

なお、本発明の各実施形態に係るコンテンツサーバ１０は、以下に示すような機能を有するプログラムとして提供されることも可能である。このプログラムは、コンピュータに、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように、入力された一つの映像音声コンテンツを符号化し、一つの映像音声コンテンツから複数の圧縮データストリームを生成する符号化ステップと、生成された複数の圧縮データストリームそれぞれを、同時に配信するステップと、を実行させるためのプログラムである。

このコンピュータプログラムは、コンピュータが備える記憶部に格納され、コンピュータが備えるＣＰＵに読み込まれて実行されることにより、コンピュータを上記のコンテンツサーバ１０として機能させる。また、コンピュータプログラムが記録された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

また、本発明の各実施形態に係る情報処理装置２０は、以下に示すような機能を有するプログラムとして提供されることも可能である。このプログラムは、コンピュータに、映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように一つの映像音声コンテンツが符号化された複数の圧縮データストリームについて、配信されている複数の圧縮データストリームの中から、取得する圧縮データストリームを選択する取得ストリーム選択ステップと、選択した圧縮データストリームを取得するコンテンツ取得ステップと、を実行させるためのプログラムである。

このコンピュータプログラムは、コンピュータが備える記憶部に格納され、コンピュータが備えるＣＰＵに読み込まれて実行されることにより、コンピュータを上記の情報処理装置２０として機能させる。また、コンピュータプログラムが記録された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。

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

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

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

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

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

符号の説明

１ コンテンツ配信システム
１０ コンテンツサーバ
１１Ａ 第１処理部
１１Ｂ 第２処理部
２０ 情報処理装置
３０ 配信予定時刻情報送信サーバ
４０ 基準クロックサーバ
１０１ 第１符号化部
１０３ 第２符号化部
１０５ 第１配信部
１０７ 第２配信部
１０９，１１１ 記憶部
２０１ チャンネル選択部
２０３ コンテンツ取得部
２０５ 取得ストリーム選択部
２０７ コンテンツ再生部
２０９ 記憶部

Claims (18)

1. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、
   互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、
   を備える、コンテンツサーバ。
2. 前記複数の符号化部それぞれは、圧縮および符号化条件が同一となるように、前記映像音声コンテンツを符号化する、請求項１に記載のコンテンツサーバ。
3. 前記複数の配信部それぞれは、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を出力する、請求項２に記載のコンテンツサーバ。
4. 前記コンテンツサーバ内のクロックは、当該コンテンツサーバの外部に位置する基準クロックサーバから提供される基準クロックに同期しており、
   前記複数の符号化部は、同期している前記クロックに基づいて前記基準圧縮映像データ配信予定時刻の計測を行う、請求項１に記載のコンテンツサーバ。
5. 前記コンテンツサーバは、一の前記符号化部と一の前記配信部とを含む装置が並列に複数台接続されている、請求項１に記載のコンテンツサーバ。
6. 前記複数の符号化部および前記複数の配信部は、同一の装置内に設けられる、請求項１に記載のコンテンツサーバ。
7. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、を備えるコンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、
   前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
   を備える、情報処理装置。
8. 前記取得ストリーム選択部は、前記コンテンツサーバが出力した、生成された前記基準圧縮映像データが配信される配信予定時刻に関する基準圧縮映像データ配信予定時刻情報を取得し、取得した前記基準圧縮映像データ配信予定時刻情報に基づいて、取得する前記圧縮データストリームを選択する、請求項７に記載の情報処理装置。
9. 前記取得ストリーム選択部は、取得した圧縮データストリームに表示を切り替えるために要する切替所要時間と、取得するストリームの選択処理を開始した時刻とを用いて、取得した圧縮データストリームの切り替えを完了する切替完了予想時刻を算出し、算出した前記切替完了予想時刻以降の直近の基準圧縮映像データ配信予定時刻を有する前記圧縮データストリームを選択する、請求項８に記載の情報処理装置。
10. 前記取得ストリーム選択部は、各圧縮データストリームに対応した前記基準圧縮映像データ配信予定時刻が全て前記切替完了予想時刻よりも前である場合には、いずれのデータストリームも選択しない、請求項９に記載の情報処理装置。
11. 前記取得ストリーム選択部は、前記配信予定時刻と、選択した前記圧縮データストリームの前記切替完了予想時刻との間の時間間隔が所定の閾値以下である場合に、前記圧縮データストリームの選択結果を前記コンテンツ取得部に通知する、請求項９に記載の情報処理装置。
12. 前記コンテンツ取得部は、ＩＧＭＰにより前記取得ストリーム選択部が選択した前記圧縮データストリームの切り替え制御を行う、請求項８に記載の情報処理装置。
13. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、を備えるコンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    取得した前記圧縮データストリームを、ネットワークを介して接続された情報処理装置に対して配信する配信制御部と、
    を備える、ネットワーク機器。
14. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように入力された一つの映像音声コンテンツを符号化し、前記一つの映像音声コンテンツから複数の圧縮データストリームを生成する符号化ステップと、
    生成された前記複数の圧縮データストリームそれぞれを、同時に配信するステップと、
    を含む、コンテンツ配信方法。
15. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように一つの映像音声コンテンツが符号化された複数の圧縮データストリームについて、配信されている前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択ステップと、
    選択した前記圧縮データストリームを取得するコンテンツ取得ステップと、
    を含む、情報処理方法。
16. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように一つの映像音声コンテンツが符号化された複数の圧縮データストリームについて、配信されている前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択ステップと、
    選択した前記圧縮データストリームを取得するコンテンツ取得ステップと、
    取得した前記圧縮データストリームを、ネットワークを介して接続された情報処理装置に対して配信する配信制御ステップと、
    を含む、コンテンツ配信方法。
17. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、
    互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、
    を備えるコンテンツサーバと、
    前記コンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    を備える情報処理装置と、
    を含む、コンテンツ配信システム。
18. 映像信号の圧縮によって生成された時系列データにおいて、以前のデータに依存せずに、それ以降の映像信号の復号化を開始できるデータである基準圧縮映像データが対応する映像フレームおよび当該基準圧縮データの配信される時間が互いに異なるように映像音声コンテンツを符号化し、一つの前記映像音声コンテンツから複数の圧縮データストリームを生成する複数の符号化部と、
    互いに異なるネットワークアドレスが割り当てられており、互いに異なる一の前記符号化部から、当該一の符号化部が生成した一の前記圧縮データストリームを取得して配信する、複数の配信部と、
    を備えるコンテンツサーバと、
    前記コンテンツサーバが配信する複数の圧縮データストリームの中から、再生を希望する前記圧縮データストリームを通知し、取得した前記圧縮データストリームを再生する情報処理装置と、
    前記情報処理装置から受信した通知に基づいて、前記コンテンツサーバが配信する前記複数の圧縮データストリームの中から、取得する前記圧縮データストリームを選択する取得ストリーム選択部と、
    前記取得ストリーム選択部による選択結果に基づいて、前記コンテンツサーバから配信された前記圧縮データストリームを取得するコンテンツ取得部と、
    取得した前記圧縮データストリームを、ネットワークを介して前記情報処理装置に対して配信する配信制御部と、
    を備えるネットワーク機器と、
    を含む、コンテンツ配信システム。
    

Images