(57)【要約】【課題】  マルチキャストストリームの視聴チャンネルの切り替え時間を短縮する。【解決手段】  ユーザにより選択された視聴チャンネルのストリームを受信し、バッファリングし、デコード等の処理を通して再生する一方で、ユーザの嗜好に合わせて自動的に選択された他の１以上のチャンネルのメディアストリームを視聴候補ストリームとして受信し、バッファリングする。視聴候補ストリームとして受信中のいずれかのチャンネルを視聴対象のチャンネルに切り替える指示がユーザより入力されたとき、バッファリングされた当該チャンネルのストリームをデコードして再生を開始するとともに、当該チャンネルのストリームを視聴対象ストリームとして受信することを開始する。これにより、ユーザから見た視聴チャンネルの切り替え時間を大幅に短縮することができる。【選択図】図５
2010093576.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを通じてマルチキャスト配信されるストリームを受信する受信装置であって、
第１のチャンネルのストリームを視聴ストリームとして受信するとともに、他の１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信するストリーム受信部と、
前記ストリーム受信部により受信された各チャンネルのストリームを保持するバッファ部と、
前記バッファ部に前記視聴ストリームとして保持されたストリームを視聴するための処理を行う再生処理部と、
前記第１のチャンネルに代えて、前記視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、前記バッファ部に保持された当該第２のチャンネルに対応するストリームを前記視聴ストリームとして前記再生処理部に処理させるとともに前記ストリーム受信部にて前記視聴ストリームとして受信させるチャンネル処理部と
を具備する受信装置。
【請求項２】
請求項１に記載の受信装置であって、
前記チャンネル処理部は、前記指示が入力されたとき、さらに、前記第１のチャンネルのストリームを前記視聴候補ストリームとして前記ストリーム受信部に受信させる、または、当該第１のチャンネルのストリームの受信を停止させる
受信装置。
【請求項３】
請求項２に記載の受信装置であって、
前記チャンネル処理部は、前記受信装置が前記ストリームを受信してバッファリングするために利用できる資源の範囲で前記第２のチャンネルの数を最大に設定する
受信装置。
【請求項４】
請求項３に記載の受信装置であって、
前記バッファ部は、ストリームを受信するチャンネル毎に容量が割り当てられ、個々の前記第２のチャンネルに割り当てられる容量は、視聴チャンネルの切り替え直後の映像と音声の再生が保証される値に設定されている
受信装置。
【請求項５】
請求項４に記載の受信装置であって、
前記チャンネル処理部は、ストリームを受信可能な全チャンネルの優先度をユーザの嗜好を基準に算出し、優先度の高いチャンネルから優先的に前記第２のチャンネルとして選択する
受信装置。
【請求項６】
請求項５に記載の受信装置であって、
前記チャンネル処理部は、メディアストリームとこれに対する誤り訂正用のストリームを前記視聴ストリームとして前記ストリーム受信部に受信させ、前記視聴候補ストリームとしてメディアストリームのみを前記ストリーム受信部に受信させる
受信装置。
【請求項７】
請求項６に記載の受信装置であって、
前記チャンネル処理部は、前記ネットワークの伝送特性を評価するための情報を取得し、この情報をもとに前記第２のチャンネルの最大数を動的に変更する
受信装置。
【請求項８】
ネットワークを通じてマルチキャスト配信されるストリームを受信する方法であって、
第１のチャンネルのストリームを視聴ストリームとして受信するとともに、他の１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信し、
前記受信された各チャンネルのストリームをバッファ部に保持し、
前記第１のチャンネルに代えて、前記視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、前記バッファ部に保持された当該第２のチャンネルに対応するストリームを前記視聴ストリームとして再生処理を行うとともに、前記視聴ストリームとして受信する
受信方法。
【請求項９】
ネットワークを通じてマルチキャスト配信されるストリームを受信する受信装置としてコンピュータを動作させるコンピュータプログラムであって、
第１のチャンネルのストリームを視聴ストリームとして受信するとともに、他の１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信するストリーム受信部と、
前記ストリーム受信部により受信された各チャンネルのストリームを保持するバッファ部と、
前記バッファ部に前記視聴ストリームとして保持されたストリームを視聴するための処理を行う再生処理部と、
前記第１のチャンネルに代えて、前記視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、前記バッファ部に保持された当該第２のチャンネルに対応するストリームを前記視聴ストリームとして前記再生処理部に処理させるとともに前記ストリーム受信部にて前記視聴ストリームとして受信させるチャンネル処理部として、
前記コンピュータを動作させるコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信装置、受信方法およびコンピュータプログラムに関し、より詳細には、マルチキャスト配信によってデータを受信する受信装置、受信方法およびコンピュータプログラムに関する。
【背景技術】
【０００２】
近年、ネットワーク技術の発達に伴い、ネットワークを介した番組（コンテンツ）の配信が行われるようになった。番組を配信する事業者は、番組をＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）のパケットに変換し、複数の受信者に向けて同じ信号を配信するマルチキャスト配信によってサーバから番組を配信する。マルチキャスト配信による番組の受信には、ＩＰｖ４ネットワーク環境では、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＩＰｖ６ネットワーク環境では、ＭＬＤ（Ｍｕｌｔｉｃａｓｔ Ｌｉｓｔｅｎｅｒ Ｄｉｓｃｏｖｅｒｙ）と呼ばれるプロトコルを用いるのが一般的である。
【０００３】
マルチキャスト配信による番組を、ＩＧＭＰ（またはＭＬＤ）によって受信する場合には、受信装置は、コンテンツのストリームを受信する際に参加（Ｊｏｉｎ）メッセージと呼ばれる信号を送出する。参加メッセージの送出によって、受信装置はマルチキャストグループに参加して、そのマルチキャストグループに対応するコンテンツを視聴することができる。そして、コンテンツの視聴を止める場合には離脱（Ｌｅａｖｅ）メッセージと呼ばれる信号を送出する。Ｌｅａｖｅメッセージの送出によって、受信装置はマルチキャストグループから離脱してコンテンツの視聴を止めることができる。
【０００４】
ネットワークを介したコンテンツのマルチキャスト配信では、受信装置で視聴するコンテンツの切り替え、言い換えればチャンネルの切り替えに関して、上記のＪｏｉｎメッセージとＬｅａｖｅメッセージの送出処理が必要となるため、放送電波による配信に比べ、チャンネルの切り替えに要する待ち時間が長いという問題がある。従って、ネットワークを介したコンテンツのマルチキャスト配信において、高速なチャンネルの切り替えを実現する必要がある。
【０００５】
特許文献１には、複数のコンテンツのデータが多重化されたストリームをホームゲートウェイ装置にて受信し、受信端末から所望のコンテンツに対応するチャンネルの情報を受信したとき、多重化ストリームから該当するチャンネルに対応するコンテンツのデータを分離して受信端末に供給する方式が記載されている。
【特許文献１】特開２００８−０２２３９３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１の方式では、ホームゲートウェイ装置から受信端末へ切り替え後のチャンネルのコンテンツのデータが伝送されるまでにタイムラグが発生するので、チャンネルの切り換えの高速化には限界がある。
【０００７】
そこで、視聴中のチャンネルに対応するマルチキャストグループから離脱するよりも前に、切り替え先のチャンネルに対応するマルチキャストグループに参加するようにＬｅａｖｅメッセージとＪｏｉｎメッセージのそれぞれの送信タイミングを制御する方法が提案されている。しかし、この方式では、ネットワークなどの問題によりＬｅａｖｅメッセージやＪｏｉｎメッセージの伝送遅延や消失が発生した場合には、視聴チャンネルの切り替えをスムースに行えない。
【０００８】
本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、マルチキャストストリームの視聴チャンネルの切り替え時間を短縮することが可能な受信装置、受信方法およびコンピュータプログラムを提供することにある。
【課題を解決するための手段】
【０００９】
上記課題を解決するために、本発明の受信装置は、ネットワークを通じてマルチキャスト配信されるストリームを受信する受信装置であって、第１のチャンネルのストリームを視聴ストリームとして受信するとともに、他の１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信するストリーム受信部と、前記ストリーム受信部により受信された各チャンネルのストリームを保持するバッファ部と、前記バッファ部に前記視聴ストリームとして保持されたストリームを視聴するための処理を行う再生処理部と、前記第１のチャンネルに代えて、前記視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、前記バッファ部に保持された当該第２のチャンネルに対応するストリームを前記視聴ストリームとして前記再生処理部に処理させるとともに前記ストリーム受信部にて前記視聴ストリームとして受信させるチャンネル処理部とを具備する。
【００１０】
この発明の受信装置では、ストリーム受信部により、第１のチャンネルの視聴ストリームとは別に、１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信してバッファ部にバッファリングする。チャンネル処理部は、第１のチャンネルに代えて、視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、バッファ部に保持された当該第２のチャンネルに対応するストリームを視聴ストリームとして再生処理部に処理させるとともにストリーム受信部にて前記視聴ストリームとして受信させる。これにより、ユーザから見た視聴チャンネルの切り替え時間を短縮することができる。
【００１１】
本発明の受信装置において、前記チャンネル処理部は、前記チャンネル処理部は、前記指示が入力されたとき、さらに、前記第１のチャンネルのストリームを前記視聴候補ストリームとして前記ストリーム受信部に受信させる、または、当該第１のチャンネルのストリームの受信を停止させる。これにより、視聴対象のチャンネルの切り替えが良好に行われる。
【００１２】
本発明の受信装置において、前記チャンネル処理部は、前記受信装置が前記ストリームを受信してバッファリングするために利用できる資源の範囲で前記第２のチャンネルの数を最大に設定するようにしてもよい。これにより、マルチキャストストリームの多チャンネル化に対応しつつ、視聴チャンネルの切り替え時間を短縮できる。
【００１３】
本発明の受信装置において、前記バッファ部は、ストリームを受信するチャンネル毎に容量が割り当てられ、個々の前記第２のチャンネルに割り当てられる容量は、視聴チャンネルの切り替え直後の映像と音声の再生が保証される値に設定されている。これにより、視聴チャンネルの切り替えの指示が発生してから、デコード等の再生処理に要する短い時間を待つだけで、ユーザから見た視聴チャンネルの切り替えが行われるとともに、バッファ容量の利用効率を高めることができる。
【００１４】
本発明の受信装置において、前記チャンネル処理部は、ストリームを受信可能な全チャンネルの優先度をユーザの嗜好を基準に算出し、優先度の高いチャンネルから優先的に前記第２のチャンネルとして選択するようにしてもよい。これにより、ユーザが切り替え先の所望のチャンネルを選択する際に、その所望のチャンネルが第２のチャンネルの中から選択される確率を大きくすることができる。
【００１５】
本発明の受信装置において、前記チャンネル処理部は、メディアストリームとこれに対する誤り訂正用のストリームを前記視聴ストリームとして前記ストリーム受信部に受信させ、前記視聴候補ストリームとしてメディアストリームのみを前記ストリーム受信部に受信させる。このように視聴候補ストリームとしてはメディアストリームのみをストリーム受信部に受信させることで、受信装置がストリームを受信してバッファリングするために利用可能なネットワーク帯域やバッファ容量などの資源を効率的に利用できる。
【００１６】
本発明の受信装置において、前記チャンネル処理部は、前記ネットワークの伝送特性を評価するための情報を取得し、この情報をもとに前記第２のチャンネルの最大数を動的に変更するようにしてもよい。これにより、ネットワークの伝送特性の変動に追従して、第２のチャンネルの最大数を最適化することができ、ネットワーク帯域やバッファ容量の不足により各チャンネルのストリーム受信およびバッファリングの動作、ひいてはメディアストリームの再生が不安定になることを防止できる。
【００１７】
また、上記課題を解決するために、本発明の別の観点に基づく受信方法は、ネットワークを通じてマルチキャスト配信されるストリームを受信する方法であって、第１のチャンネルのストリームを視聴ストリームとして受信するとともに、他の１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信し、前記受信された各チャンネルのストリームをバッファ部に保持し、前記第１のチャンネルに代えて、前記視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、前記バッファ部に保持された当該第２のチャンネルに対応するストリームを前記視聴ストリームとして再生処理を行うとともに、前記視聴ストリームとして受信する。
【００１８】
また、上記課題を解決するために、本発明の別の観点に基づくコンピュータプログラムは、ネットワークを通じてマルチキャスト配信されるストリームを受信する受信装置としてコンピュータを動作させるコンピュータプログラムであって、第１のチャンネルのストリームを視聴ストリームとして受信するとともに、他の１以上の第２のチャンネルのストリームを視聴候補ストリームとして受信するストリーム受信部と、前記ストリーム受信部により受信された各チャンネルのストリームを保持するバッファ部と、前記バッファ部に前記視聴ストリームとして保持されたストリームを視聴するための処理を行う再生処理部と、前記第１のチャンネルに代えて、前記視聴候補ストリームとして受信中のいずれかの第２のチャンネルに視聴対象を切り替える指示が入力されたとき、前記バッファ部に保持された当該第２のチャンネルに対応するストリームを前記視聴ストリームとして前記再生処理部に処理させるとともに前記ストリーム受信部にて前記視聴ストリームとして受信させるチャンネル処理部として、前記コンピュータを動作させるものである。
【発明の効果】
【００１９】
以上説明したように本発明によれば、マルチキャストストリームの視聴チャンネルの切り替え時間を短縮することができる。
【発明を実施するための最良の形態】
【００２０】
以下、本発明を実施した形態を図面に基づき詳細に説明する。
【００２１】
＜第１の実施形態＞
［マルチキャスト配信システムの構成］
図１は、本発明の第１の実施形態に係る受信装置１００を用いるマルチキャスト配信システム１０の構成を示す図である。
【００２２】
同図に示すように、このマルチキャスト配信システム１０は、放送コンテンツ事業者１１がコンテンツのストリームをマルチキャスト方式で配信するための配信サーバ１３と、配信サーバ１３より配信されたコンテンツのストリームをあて先の受信装置１００に配信するルータ１４とを有する。配信サーバ１３とルータ１４とは、ＣＤＮ（Ｃｏｎｔｅｎｔｓ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）網１２で接続されている。ＣＤＮ網１２は、ファイルサイズの大きいデジタルコンテンツをネットワーク経由で配信するために最適化されたネットワークのことである。
【００２３】
ここで、配信サーバ１３より配信されるコンテンツのストリームは、コンテンツの映像／音声／字幕などのデータを含むメディアストリームと、このメディアストリームの誤り訂正用のＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ：順方向誤り訂正）ストリームとからなる。これらのストリームはそれぞれ別々のチャンネルで伝送される。
【００２４】
ルータ１４は、同じチャンネルのコンテンツのストリームを受信する１以上の受信装置１００をグループ化して、このグループ（マルチキャストグループ）に対してマルチキャストＩＰアドレスを割り当てる。これにより、受信装置１００は、自らが属しているグループのマルチキャストＩＰアドレス宛てのパケットを自分に宛てたパケットとみなして受信することができる。ルータ１４は、受信装置１００から、参加したいグループを識別する情報を含むＪｏｉｎメッセージを受信すると、その受信装置１００をグループに参加させる処理を行い、グループからの離脱を希望するＬｅａｖｅメッセージを受信すると、その受信装置１００をグループから離脱させる処理を行う。
【００２５】
ルータ１４には、ローカルのネットワークを通じて１以上の受信装置１００の接続が可能とされている。
【００２６】
図１では、説明を簡単にするために配信サーバ１３とルータ１４をそれぞれ１つずつ図示したが、マルチキャスト配信システム１０には複数の配信サーバやルータがＣＤＮ網１２上に接続可能とされている。
【００２７】
受信装置１００は、コンテンツのストリームを受信して再生などの利用ができる機器であればよい。具体的には、パーソナルコンピュータ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ：ＰＣ）等のコンピュータ機器、テレビジョン受像器、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）、録画機器などである。
【００２８】
［受信装置１００の構成］
次に、受信装置１００の構成について説明する。
図２は受信装置１００の構成を示すブロック図である。
【００２９】
図２に示すように、受信装置１００は、通信インタフェース部１０１、通信処理部１１０、ストリーミング処理部１２０、ディクリプタ１０２、デマルチプレクサ１０３、ＡＶプレーヤ１３０、映像・音声出力処理部１０４、映像・音声出力インタフェース１０５、リモコンインタフェース１０６、ＣＡＳ／ＤＲＭクライアント１０７、ＢＭＬブラウザ１０８を有する。
【００３０】
通信インタフェース部１０１は、ネットワークに受信装置１００を接続するインタフェースである。この実施形態では、受信装置１００は通信インタフェース部１０１を通じてローカルのネッワークに接続されている。
【００３１】
通信処理部１１０（ストリーム受信部）は、通信処理部１１０は、物理・データリンク層、ＩＰ層、ＩＧＭＰ／ＭＬＤ層、ＵＤＰ層、ＴＣＰ層、ＲＴＰ層、ＨＴＴＰ／ＴＬＳ層の通信処理を行う。通信処理部１１０は、例えば、配信サーバ１３からＣＤＮ網１２に配信されたコンテンツのストリームをルータ１４を介して受信したり、受信装置１００からルータ１４へ向けて各種のメッセージを送信する処理などを行う。
【００３２】
ストリーミング処理部１２０は、受信したコンテンツのメディアストリームおよびＦＥＣストリームをバッファリングのため保持するバッファ部１２１と、バッファ部１２１に保持されたメディアストリームに対してＦＥＣストリームを用いて誤り訂正処理を行うＦＥＣ処理部１２２とを有する。ストリーミング処理部１２０からは誤り訂正後のメディアストリームが出力される。
【００３３】
ディクリプタ１０２は、ストリーミング処理部１２０より出力された誤り訂正後のメディアストリームの復号を行うものである。ディクリプタ１０２は、コンテンツのメディアストリームの復号を行う前に、ＣＡＳ／ＤＲＭクライアント１０７から当該コンテンツのメディアストリームの復号が可能であるかどうかを判断する情報を取得する。ディクリプタ１０２は、復号が可能であることを判断したならメディアストリームの復号を行う。
【００３４】
デマルチプレクサ１０３は、ディクリプタ１０２で復号されたメディアストリームを、映像、音声、字幕などのそれぞれの種類のデータに分離する。メディアストリームは、配信サーバ１３において映像、音声、字幕などのデータをマルチプレクサで多重化して配信されてくるため、受信装置１００では、その多重化されたデータを分離するためにデマルチプレクサ１０３が必要となる。
【００３５】
ＡＶプレーヤ１３０は、映像デコーダ１３１、音声デコーダ１３２、字幕デコーダ１３３、再生制御部１３４、選局処理部１３５などを備える。映像デコーダ１３１は、デマルチプレクサ１０３で分離された映像データを復号する。音声デコーダ１３２はデマルチプレクサ１０３で分離された音声データを復号する。字幕デコーダ１３３はデマルチプレクサ１０３で分離された字幕データを復号する。再生制御部１３４は、リモートコントローラ１５１などを用いてユーザより入力された再生／停止／一時停止などの各種操作のための処理を実行する。選局処理部１３５（チャンネル処理部）は、リモートコントローラ１５１などを用いてユーザより入力された視聴対象のチャンネル（以下、「視聴チャンネル」と呼ぶ。）の選択や視聴チャンネルの切り替えのための処理を行う。また、選局処理部１３５は、ユーザの嗜好に合ったコンテンツを配信しているチャンネルを自動的に選択し、そのチャンネルのメディアストリームを視聴候補ストリームとして受信するための処理を行う。
【００３６】
映像・音声出力処理部１０４は、映像デコーダ１３１の出力、字幕デコーダ１３３の出力、およびＢＭＬブラウザ１０８による生成画像を合成して映像・音声出力インタフェース１０５を通じて外部のテレビジョンなどの映像・音声出力機器に出力する。また、映像・音声出力処理部１０４は、音声デコーダ１３２の出力を映像・音声出力インタフェース１０５を通じて外部のテレビジョンなどの映像・音声出力機器に出力する。
【００３７】
なお、受信装置１００に映像表示部と音声出力部を設け、これらに映像データおよび音声データを出力するようにしてもよい。
【００３８】
リモコンインタフェース１０６は、リモートコントローラ１５１との間で赤外線信号などの無線信号の送受信を行うインタフェースである。リモコンインタフェース１０６は、リモートコントローラ１５１を通じてユーザより入力された各種の指示をＡＶプレーヤ１３０内の再生制御部１３４および選局処理部１３５や、ＢＭＬブラウザ１０８、その他のブロックに通知する。
【００３９】
ＢＭＬブラウザ１０８は、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述されたデータを閲覧するための処理を行う。ＢＭＬとは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ベースのデータ放送向けのページ記述言語である。ＢＭＬブラウザ１０８はＢＭＬ形式で記述されたデータを解釈して表示情報を生成し、映像・音声出力処理部１０４に出力する。
【００４０】
ＣＡＳ／ＤＲＭクライアント１０７は、ＣＡＳ（Ｃｏｎｄｉｔｉｏｎａｌ Ａｃｃｅｓｓ Ｓｙｓｔｅｍ）およびＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）の管理を行うものである。
以上、本発明の第１の実施形態にかかる受信装置１００の構成の説明である。
【００４１】
［視聴チャンネルの選択と受信］
次に、受信装置１００での視聴チャンネルの選択から受信までの動作を説明する。
【００４２】
受信装置１００は、通信処理部１１０にて、自身に割り当てられるＩＰアドレスを取得してＣＤＮ網１２とのＩＰ接続を確立する。次に、受信装置１００は、一意に決められたＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）に従って、各種の配信サーバにアクセスするために必要な構成情報を取得する。受信装置１００は、この構成情報をもとにＣＤＮ網１２を通じてマルチキャスト放送を受信可能であるかどうかを判断する。受信装置１００は、マルチキャスト放送が受信可能であることを判断すると、ＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）情報を取得するためのマルチキャストアドレスを構成情報から抽出する。ＳＩ情報は、マルチキャスト放送されるコンテンツのチャンネル名、放送時間、タイトル、出演者などのコンテンツに関する管理情報、さらには、チャンネルとマルチキャストアドレスとを関連付ける情報であるＮＩＴ（Ｎｅｔｗｏｒｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ）を含む。１つのチャンネルのコンテンツは映像、音声、字幕などのデータを含むメディアストリームと、誤り訂正用のデータであるＦＥＣ（Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）ストリームとで構成される。これらのメディアストリームとＦＥＣストリームはそれぞれ異なるマルチキャストグループを利用して配信される。
【００４３】
次に、受信装置１００は、ＳＩ情報を取得するために、ＳＩ情報をマルチキャスト配信するチャンネルに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージをルータ１４へ送信する。このＪｏｉｎメッセージは、ＳＩ情報をマルチキャスト配信するチャンネルに対応するマルチキャストアドレスを、マルチキャストグループを指すアドレスとして含む。ルータ１４は、受信装置１００からのＪｏｉｎメッセージを受信すると、ＩＧＭＰテーブルに、ＳＩ情報の送信元である配信サーバ（図示せず）のＩＰアドレスと対応付けて受信装置１００のＩＰアドレスを登録する。これにより、以後、ルータ１４はＩＧＭＰテーブルに登録された情報に従って、ＳＩ情報の送信元である配信サーバから配信された、所定のプラットフォームのＳＩ情報のストリームを受信装置１００にルーティングする。
【００４４】
受信装置１００は、配信サーバから配信されたＳＩ情報のストリームを受信し、保存する。受信装置１００のユーザは視聴チャンネルを選択したい場合、受信装置１００に接続された映像・音声出力機器の画面にチャンネル選局リストを表示させるように指示を受信装置１００へ入力する。この指示を受けて、受信装置１００は、保存されているＳＩ情報をもとにチャンネル選局リストを作成し、映像・音声出力機器に表示させる。表示されたチャンネル選局リスト上でユーザは希望するチャンネルを選択して視聴要求を入力する。
【００４５】
受信装置１００は、ユーザからチャンネルの視聴要求を受けると、ＳＩ情報から、その選択されたチャンネルを使って配信中のメディアストリームのマルチキャストアドレスとＦＥＣストリームのマルチキャストアドレスをそれぞれ抽出する。受信装置１００は、各々のチャンネル毎に、対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージをルータ１４へそれぞれ送信する。ルータ１４は、受信装置１００からのＪｏｉｎメッセージを受信すると、ＩＧＭＰテーブルに、そのマルチキャストグループのアドレスと対応付けて受信装置１００のＩＰアドレスを登録する。以後、ルータ１４はＩＧＭＰテーブルに登録された情報に従って、配信サーバ１３から配信されたメディアストリームとＦＥＣストリームを受信装置１００にそれぞれルーティングする。受信装置１００は、配信サーバから配信されたメディアストリームとＦＥＣストリームを受信する。
【００４６】
［視聴チャンネルの典型的な切り替え動作］
図３は、典型的な受信装置での視聴チャンネルの切り替え例を示す図である。同図は２つのチャンネルＡ，Ｂ間での切り替えの例であり、Ｔ１時点でユーザによりチャンネルＡの視聴が選択され、その後、暫くの時間を置いてＴ２時点で、チャンネルＢの視聴に切り替えられた例を示している。
【００４７】
図４は、図３の視聴チャンネルの切り替え発生時点Ｔ２の時間軸を拡大して示す図である。まず、Ｔ２の時点で、ユーザから、チャンネルＡからチャンネルＢへの視聴チャンネルの切り替え指示が与えられる。視聴チャンネルの切り替える指示を受けた典型的な受信装置は、Ｔ２−１の時点で、チャンネルＡに対応するマルチキャストグループからの離脱を要求するマルチキャストレポートであるＬｅａｖｅメッセージをルータに送信する。
【００４８】
ルータは、受信装置からチャンネルＡからの離脱を要求するＬｅａｖｅメッセージを受信すると、ＩＧＭＰテーブルにチャンネルＡに対応するマルチキャストグループのアドレスと対応付けて登録されている当該受信装置のＩＰアドレスを削除する。これによりルータによるチャンネルＡのストリームの受信装置へのルーティングは、Ｔ２−２の時点から以降止められる。
【００４９】
次に、受信装置は、Ｔ２−３の時点で、チャンネルＢに対応するマルチキャストグループへの参加を要求するマルチキャストレポートであるＪｏｉｎメッセージをルータに送信する。ルータ１４は、Ｊｏｉｎメッセージを受け取ると、ＩＧＭＰテーブルに、そのマルチキャストグループのアドレスと対応付けて受信装置のＩＰアドレスを登録する。以後、ルータ１４はＩＧＭＰテーブルに登録された情報に従って、チャンネルＢのマルチキャストストリームを受信装置にルーティングするように動作する。これにより、受信装置は、Ｔ２−４の時点からチャンネルＢのストリームの受信を開始し、バッファリング、誤り訂正、復号などの処理を経て、Ｔ２−５の時点から、チャンネルＢのコンテンツの映像および音声の出力が開始される。
【００５０】
このように、典型的な受信装置では、視聴チャンネルを切り替えるために、Ｌｅａｖｅメッセージを送信して、切り替え前のチャンネルのマルチキャストグループから離脱した後、Ｊｏｉｎメッセージを送信して、切り替え先のチャンネルのマルチキャストグループに参加する手順が必要である。このため、結果的に、視聴チャンネルの切り替えに要する時間つまりユーザより視聴チャンネルの切り替え指示が入力されてから、実際に出力される視聴チャンネルが切り替われるまでに長い時間（約３．５秒）がかかっていた。
【００５１】
本発明に係る第１の実施形態の受信装置１００では、視聴チャンネルの切り替えに要する時間を短縮するために、次のような動作が行われる。
【００５２】
［本発明に係る視聴チャンネルの切り替え動作の概念］
図５は、本発明の第１の実施形態に係る受信装置１００での視聴チャンネルの切り替え動作の概念を説明する図である。
【００５３】
受信装置１００は、ユーザにより選択された視聴チャンネルのコンテンツのメディアストリームとＦＥＣストリームをそれぞれ受信し、ストリーミング処理部１２０のバッファ部１２１にバッファリングする。バッファリングされたメディアストリームとＦＥＣストリームはＦＥＣ処理部１２２（図２参照）にて処理され、ここで誤り訂正されたメディアストリームとなる。次いで、ディクリプタ１０２にて、誤り訂正後のメディアストリームの復号が行われ、デマルチプレクサ１０３にて映像、音声、字幕などのそれぞれの種類のデータに分離される。分離された各データはＡＶプレーヤ１３０内の映像デコーダ１３１、音声デコーダ１３２、字幕デコーダ１３３によってそれぞれ復号される。映像デコーダ１３１、音声デコーダ１３２、字幕デコーダ１３３それぞれの出力は映像・音声出力処理部１０４（図２参照）によって映像・音声出力インタフェース１０５を通じて外部のテレビジョンなどの映像・音声出力機器に出力される。これによりユーザにより選択されたチャンネルのコンテンツの視聴が可能となる。
【００５４】
一方で、受信装置１００は、自動的に選択された他のチャンネルのメディアストリームを視聴候補ストリームとして受信し、バッファリングする。この際、ＦＥＣストリームは受信されない。すなわち、受信装置１００は、視聴チャンネルに対応するマルチキャストグループと同時に他の１以上のマルチキャストグループに参加して、それぞれのマルチキャストグループに対応するチャンネルのストリームを視聴候補ストリームとして受信してバッファリングする。バッファリングされた視聴候補ストリームは、そのサイズがチャンネル毎に設定されたバッファ容量を超えないように、時間の経過に伴って古いパケットから順に破棄される。視聴候補ストリームとして受信中のいずれかのチャンネルを視聴対象のチャンネルに切り替える指示がユーザより入力されたとき、受信装置１００は、バッファリングされた当該チャンネルのストリームをデコードして再生を開始する。同時に、受信装置１００は、当該チャンネルのストリームを視聴対象ストリームとして受信することを開始する。これにより、ユーザから見た視聴チャンネルの切り替え時間が大幅に短縮される。
【００５５】
ここで、ストリームを視聴候補ストリームとして受信するチャンネルの選択方法の説明に入る。この視聴候補ストリームとして受信するチャンネルの選択は選局処理部１３５によって自動的に行われる。
【００５６】
図６は、選局処理部１３５による視聴候補ストリームのチャンネル選択に係るブロック図である。ＳＩ情報格納部７３は、ＣＤＮ網１２を通じて取得されたＳＩ（Ｓｅｒｖｉｃｅ Ｉｎｆｏｒｍａｔｉｏｎ）情報が格納される部分である。
【００５７】
視聴履歴記録部７４は、コンテンツが視聴される都度、そのコンテンツに関する情報、例えば、チャンネル、タイトル、ジャンル、出演者、放送時間などの情報を、ＳＩ情報格納部７３に格納されたＳＩ情報より抽出して視聴履歴として視聴履歴格納部７１に蓄積する。
【００５８】
選局処理部１３５は、視聴履歴格納部７１に格納されたユーザの視聴履歴をもとに、統計的な手法によりユーザの嗜好に合ったチャンネル、タイトル、ジャンル、出演者などの情報を判定し、この判定結果をもとにユーザの嗜好情報を生成して、嗜好情報格納部７２に格納する。このユーザの嗜好情報の生成は、例えば、視聴履歴格納部７１の視聴履歴が更新される都度行われて、嗜好情報格納部７２の内容がその都度更新される。選局処理部１３５は、コンテンツを配信中のすべてのチャンネルについて、嗜好情報格納部７２に格納されたユーザの嗜好情報をもとに優先度を判定する。
【００５９】
また、選局処理部１３５は、新たなチャンネルのストリームを受信するために必要なネットワーク帯域の空きとバッファ容量の空きが存在するかどうかを判定し、いずれも空きがあるならば、ルータ１４に対して、優先度の高いチャンネルから優先して、これに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージを発行するように通信処理部１１０に指示を出す。
以上が、選局処理部１３５による視聴候補ストリームのチャンネル選択に係る構成の説明である。
【００６０】
［本発明に係る視聴チャンネルの切り替え動作の詳細］
次に、本発明の第１の実施形態に係る受信装置１００での視聴チャンネルの切り替え動作を詳しく説明する。
【００６１】
はじめに、図７を用いて、視聴チャンネルの切り替え処理のための前処理について説明する。ユーザがリモートコントローラ１５１を操作してチャンネル選局リストの表示を指示する。このリモートコントローラ１５１からの指示は、リモコンインタフェース１０６にて受信され、ＡＶプレーヤ１３０内の選局処理部１３５に通知される。選局処理部１３５はチャンネル選局リストの表示の指示を受けると、ＳＩ情報格納部７３に格納されたＳＩ情報をもとにチャンネル選局リストを生成して、映像・音声出力処理部１０４に出力する。映像・音声出力処理部１０４は、チャンネル選局リストの表示情報を生成し、映像・音声出力インタフェース１０５を通じて外部のテレビジョンなどの映像・音声出力機器に出力する。これにより、チャンネル選局リストがユーザに提示される。
【００６２】
ユーザは、リモートコントローラ１５１を操作して、チャンネル選局リストの中から視聴したいチャンネルを選択して視聴要求を入力する。これにより、選択されたチャンネルの情報を含む視聴要求がＡＶプレーヤ１３０内の選局処理部１３５に与えられる。選局処理部１３５は、視聴要求を受けると、この視聴要求に含まれるチャンネルの情報をもとに、ＳＩ情報格納部７３に格納されたＳＩ情報から、当該チャンネルで配信されるコンテンツに対応するメディアストリームのマルチキャストアドレスおよびＦＥＣストリームのマルチキャストアドレスを抽出する。
【００６３】
次に、選局処理部１３５は、抽出したメディアストリームのマルチキャストアドレスに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージと、ＦＥＣストリームのマルチキャストアドレスに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージのそれぞれの送信を通信処理部１１０に依頼する。通信処理部１１０は、これらの依頼に従って、各Ｊｏｉｎメッセージをルータ１４へ送信する（ステップＳ２０１）。ルータ１４は、受信装置１００からの各Ｊｏｉｎメッセージを受信すると、ＩＧＭＰテーブルに、それらのマルチキャストグループのアドレスと対応付けて受信装置１００のＩＰアドレスを登録する。以後、ルータ１４は、ＩＧＭＰテーブルに登録された情報に従って、配信サーバから配信された当該メディアストリームおよびＦＥＣストリームを受信装置１００にルーティングするように動作する。受信装置１００は、配信サーバから配信されたメディアストリームおよびＦＥＣストリームをそれぞれ受信し、バッファリング、誤り訂正、復号などの処理を通してコンテンツの再生を行う。
【００６４】
次に、選局処理部１３５は、配信中のすべてのチャンネルのコンテンツについて、嗜好情報格納部７２に格納されたユーザの嗜好情報をもとに優先度を判定する（ステップＳ２０２）。優先度を判定する方法については後述する。
【００６５】
次に、選局処理部１３５は、視聴中のチャンネル以外の各チャンネルのうち優先度が最も高いチャンネルを、そのチャンネルのメディアストリームを視聴候補ストリームとして受信すべきかどうかを判定する対象のチャンネル（以降、「判定対象チャンネル」と呼ぶ。）として選択する（ステップＳ２０３）。
【００６６】
次に、選局処理部１３５は、受信装置１００で現在利用可能なネットワーク帯域とバッファ容量を算出する（ステップＳ２０５）。ここで、「現在利用可能なネットワーク帯域」とは、受信装置１００に割り当てられた全体の帯域から現在消費されている帯域を差し引いたものである。「現在利用可能なバッファ容量」とは、受信装置１００にストリーム受信用として用意されている全体のバッファ容量から現在消費されているバッファ容量を差し引いたものである。
【００６７】
次に、選局処理部１３５は、判定対象チャンネルのメディアストリームの受信によるネットワークの消費帯域とバッファ消費容量を算出する（ステップＳ２０６）。ここで、判定対象チャンネルのメディアストリームの受信によるバッファ消費容量は、判定対象チャンネルのメディアストリームの伝送レートをａ［Ｍｂｐｓ］とすると、例えば、ａ×ｔ［Ｍｂｉｔ］のように計算される。ここで、ｔはバッファリング時間であり、単位は秒［ｓｅｃ］である。このｔの値は固定値であっても、ユーザによる設定値であってもよい。あるいは、ネットワーク伝送特性や、バッファ空き容量に応じて動的に変更される値であってもよい。
【００６８】
次に、選局処理部１３５は、判定対象チャンネルのメディアストリームを受信するために必要なネットワーク帯域とバッファ容量が残っているかどうかを判定する（ステップＳ２０７）。この判定は、ステップＳ２０５で求めた現在利用可能なネットワーク帯域およびバッファ容量とステップＳ２０６で求めたネットワークの消費帯域およびバッファ消費容量とを比較することにより行われる。すなわち、現在利用可能なネットワーク帯域がネットワークの消費帯域よりも小さい場合、または、現在利用可能なバッファ容量がバッファ消費容量よりも小さい場合には、必要なネットワーク帯域とバッファ容量が残っていないと判定される。逆に、現在利用可能なネットワーク帯域がネットワークの消費帯域より大きく、かつ、現在利用可能なバッファ容量がバッファ消費容量よりも大きい場合には、必要なネットワーク帯域とバッファ容量が残っていると判定される。
【００６９】
選局処理部１３５は、必要なネットワーク帯域とバッファ容量が残っていることを判定した場合、その判定対象チャンネルのメディアストリームが、自受信装置１００が接続されているローカルのネットワークに流れているかどうかを判定する（ステップＳ２０８）。この判定は、例えば、通信処理部１１０にて、メディアストリームのマルチキャストパケットに含まれるマルチキャストアドレスを確認することなどによって行われる。すなわち、通信処理部１１０は、到着したマルチキャストパケットのマルチキャストアドレスを、判定対象チャンネルのメディアストリームのマルチキャストアドレスと比較する。通信処理部１１０は、両方が一致することを判定した場合、判定対象チャンネルのメディアストリームが受信装置１００が接続されたローカルのネットワークに流れていることを判定する。ここで、ローカルのネットワークに接続された他の受信装置が、その判定対象チャンネルのコンテンツを視聴しているか、または、視聴候補ストリームとして受信中であれば、判定対象チャンネルのメディアストリームがローカルのネットワークに流れていることになる。
【００７０】
選局処理部１３５は、判定対象チャンネルのメディアストリームのマルチキャストパケットがローカルのネットワークに流れている場合、そのメディアストリームを視聴候補ストリームとして受信してバッファリングするように、通信処理部１１０とストリーミング処理部１２０に指示を出す。これにより、受信装置１００にて、その視聴候補ストリームの受信とバッファリングが開始される（ステップＳ２０９）。
【００７１】
ステップ２０８の判定で判定対象チャンネルのストリームのマルチキャストパケットがローカルのネットワークに流れていない場合の動作は次の通りである。選局処理部１３５は、ＳＩ情報格納部７３に格納されたＳＩ情報から、その判定対象チャンネルに対応するメディアストリームのマルチキャストアドレスを抽出する。次に、選局処理部１３５は、抽出したメディアストリームのマルチキャストアドレスに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージの送信を通信処理部１１０に依頼する。
【００７２】
通信処理部１１０は、この依頼に従って、Ｊｏｉｎメッセージをルータ１４へ送信する（ステップＳ２１０）。ルータ１４は、受信装置１００からのＪｏｉｎメッセージを受信すると、ＩＧＭＰテーブルに、このマルチキャストグループのアドレスと対応付けて受信装置１００のＩＰアドレスを登録する。以後、ルータ１４は、ＩＧＭＰテーブルに登録された情報に従って、配信サーバから配信された当該チャンネルのメディアストリームを受信装置１００にルーティングする。これにより、受信装置１００にて、当該チャンネルのストリームを視聴候補ストリームとして受信してバッファリングすることが開始される（ステップＳ２０９）。
【００７３】
次に、選局処理部１３５は、判定対象チャンネルを次に優先度が高いチャンネルに更新する（ステップＳ２１１）。この後、ステップＳ２０５に戻って、次に優先度が高い判定対象チャンネルに対する判定処理が同様に繰り返される。なお、ステップＳ２０５に戻って、受信装置１００で現在利用可能なネットワーク帯域とバッファ容量の算定が再度行われるのは、その時点で受信チャンネル数が１つ増えたことによる、ネットワークの消費帯域とバッファ消費容量の変更が発生するためである。
【００７４】
以上の処理が繰り返される中で、いずれステップＳ２０６の判定で、判定対象チャンネルのストリームを受信するために必要なネットワーク帯域およびバッファ容量の少なくともいずれかが残っていないという結果が発生する。この場合、選局処理部１３５は、今回の判定対象チャンネルのストリームの受信とバッファリングを開始させずに、ステップＳ２１１へ移行して、判定対象チャンネルを次に優先度が高いチャンネルに更新する（ステップＳ２１１）。この後、更新された判定対象チャンネルに対する判定処理が同様に繰り返される。
【００７５】
ネットワークの消費帯域とバッファ消費容量がともに比較的低いチャンネルを対象に上記の判定が行われた場合、その判定対象チャンネルのストリームを受信するために必要なネットワーク帯域およびバッファ容量が残っていると判定されることがある。この場合にも、選局処理部１３５は、その判定対象チャンネルに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージをルータ１４に送信するように通信処理部１１０に依頼する。通信処理部１１０は、この依頼に従ってＪｏｉｎメッセージをルータ１４へ送信する（ステップＳ２１０）。これにより、受信装置１００にて、その判定対象チャンネルのメディアストリームを視聴候補ストリームとして受信してバッファリングすることが開始される。
【００７６】
ステップ２０４で、全てのチャンネルについて判定処理が終了し、判定対象とすべきチャンネルが無くなれば（ステップＳ２０４のＮＯ）、視聴チャンネルの切り替えのための前処理は終了となる。
【００７７】
このように、本実施形態の受信装置１００では、受信装置１００で利用可能なネットワーク帯域とバッファ容量の範囲内で、できるだけ多くのチャンネル数の視聴候補ストリームを受信してバッファリングをする。
以上が、視聴チャンネルの切り替え処理のための事前の準備に関する説明である。
【００７８】
次に、ステップＳ２０５の、受信装置１００で利用可能なネットワーク帯域とバッファ容量を算出する方法を説明する。図８は受信装置１００で利用可能なネットワーク帯域とバッファ容量を算出する処理のフローチャートである。
【００７９】
選局処理部１３５は、まず、現在消費されているネットワーク帯域を算出する（ステップＳ３０１）。この処理は単位時間当たりの送受信パケット数の平均値などに基づいて算出することが可能である。次に、選局処理部１３５は、受信装置１００に割り当てられた全体のネットワーク帯域から、現在消費されているネットワーク帯域を減算して、その結果をステップＳ２０５でいう「現在利用可能なネットワーク帯域」として得る（ステップＳ３０２）。続いて、選局処理部１３５は、全体のバッファ容量から現在消費されているバッファ容量を減算して「現在利用可能なバッファ容量」を求める（ステップＳ３０３）。
【００８０】
次に、ステップＳ２０６で選局処理部１３５が、判定対象チャンネルのストリームを受信可能なネットワーク帯域とバッファ容量が残っているかどうかを判定するために、判定対象チャンネルのメディアストリームの受信による消費帯域とバッファ消費容量を求める方法を説明する。
【００８１】
図９は、判定対象チャンネルのメディアストリームの受信による消費帯域とバッファ消費容量を求める手順のフローチャートである。
【００８２】
まず、選局処理部１３５は、判定対象チャンネルのメディアストリームが、自受信装置１００が接続されたローカルのネットワークに流れているかどうかを判定する（ステップＳ４０１）。判定対象チャンネルのメディアストリームがローカルのネットワークに流れている状況は、そのローカルのネットワークに自受信装置１００とともに接続されている別の受信装置が、そのメディアストリームを視聴または視聴候補ストリームとして受信している場合などに発生する。選局処理部１３５は、判定対象チャンネルのメディアストリームがローカルのネットワークに流れていることを判定した場合、そのメディアストリームを受信し、その際の送受信パケット数などからネットワークの消費帯域を算出する（ステップＳ４０２）。この後、選局処理部１３５は、判定対象チャンネルのメディアストリームの受信によるバッファ消費容量を算出する（ステップＳ４０７）。
【００８３】
ここで、判定対象チャンネルのメディアストリームの受信によるバッファ消費容量は、視聴するチャンネルを切り替えた直後に、バッファリングされているストリームだけで動画及び音声を出力できるような値に設定される。より具体的には、動画データの画質及び音声データの音質を決定するエンコード方式や、エンコードのビットレートなどの、ストリームの属性情報をもとに選局処理部１３５で決められる。したがって、この判定対象チャンネルのメディアストリームの受信によるバッファ消費容量は、視聴チャンネルのメディアストリーム受信用のバッファ容量に対して十分小さい値でよい。
【００８４】
また、判定対象チャンネルのメディアストリームがローカルのネットワークに流れていない場合、選局処理部１３５は、配信サーバ１３より、当該メディアストリームの伝送レートの情報を取得可能かどうかを判定する（ステップＳ４０３）。選局処理部１３５は、当該伝送レートの情報を配信サーバ１３より取得可能ならば、配信サーバ１３より当該ストリームの伝送レートの情報を取得し、この伝送レートの情報をもとに消費帯域を推定する（ステップＳ４０４）。この後、選局処理部１３５は、判定対象チャンネルのメディアストリームの受信によるバッファ消費容量を算出する（ステップＳ４０７）。
【００８５】
また、伝送レートの情報を配信サーバ１３より取得できない場合、選局処理部１３５は、視聴履歴格納部７１に格納された視聴履歴をもとに当該メディアストリームの消費帯域の情報の取得を試みる（ステップＳ４０５）。例えば、選局処理部１３５は、判定対象チャンネルのコンテンツと同じチャンネル、同じ時間帯、同じタイトル名のコンテンツを過去に視聴したことがあるかどうかを視聴履歴から判定する。視聴したことがある場合、選局処理部１３５は、その視聴済みのコンテンツの消費帯域の情報を視聴履歴から取り出し、当該メディアストリームの消費帯域の情報として採用する（ステップＳ４０６）。この処理に備えるため、視聴履歴記録部７４は、コンテンツの視聴中に、このコンテンツのメディアストリームの受信時の消費帯域を算出し、視聴履歴格納部７１の当該コンテンツの視聴履歴に関連付けて記録することとしている。
【００８６】
なお、判定対象チャンネルのコンテンツと同じチャンネル、同じ時間帯、同じタイトル名のコンテンツを視聴したいことがない場合、次のようにしてもよい。選局処理部１３５は、判定対象チャンネルのコンテンツと同じチャンネルで同じ時間帯のコンテンツを視聴履歴から検索する。すなわち、タイトル名が違っていてもチャンネルと時間帯が同じであれば、そのコンテンツを判定対象チャンネルのコンテンツに関連のあるものと判断する。選局処理部１３５は、視聴履歴格納部７１に記録されている、当該コンテンツの視聴履歴から消費帯域の情報を取り出し、判定対象チャンネルのメディアストリームの消費帯域の情報として採用する。複数のコンテンツが検索された場合には、これらのコンテンツの消費帯域の平均値を判定対象チャンネルのメディアストリームの消費帯域の情報として採用する。この後、選局処理部１３５は、判定対象チャンネルのストリーム受信によるバッファ消費容量を算出する（ステップＳ４０７）。
【００８７】
コンテンツの視聴履歴から判定対象チャンネルのメディアストリームの消費帯域の情報が得られなかった場合には、選局処理部１３５は、図７のステップＳ２１１へ移行して、判定対象チャンネルを次に優先度が高いチャンネルに更新する（ステップＳ２１１）。この後、更新された判定対象チャンネルに対する判定処理が同様に繰り返される。
【００８８】
次に、受信装置１００において、ユーザからの指示による視聴チャンネルの切り替え指示が発生した場合の動作を説明する。
【００８９】
図１０は、ユーザからの指示による視聴チャンネルの切り替え動作に関するフローチャートである。
【００９０】
まず、ユーザがリモートコントローラ１５１を操作して、切り替え先のチャンネルの情報を含む視聴チャンネルの切り替え指示を入力する。このリモートコントローラ１５１からの指示は、リモコンインタフェース１０６にて受信され、ＡＶプレーヤ１３０内の選局処理部１３５に通知される。
【００９１】
選局処理部１３５は、その視聴チャンネルの切り替え指示を受けると、映像デコーダ１３１、音声デコーダ１３２、字幕デコーダ１３３へのデータ転送元のバッファを、それまで視聴中のチャンネルのメディアストリーム用のバッファから切り替え先のチャンネルのメディアストリーム用のバッファへと切り替える（ステップＳ５０１）。以後、切り替え先のチャンネルを「新たな視聴チャンネル」と呼ぶ。視聴候補ストリーム用のバッファの容量は、視聴チャンネルの切り替え直後の映像と音声の再生が保証される値に設定されている。したがって、メディアストリームのデコード等の再生処理に要する短い時間を待つだけで、ユーザから見た視聴チャンネルの切り替えが行われるとともに、バッファ容量の利用効率を高めることができる。
【００９２】
この後、新たな視聴チャンネルのメディアストリーム用のバッファ容量を視聴用のサイズまで増大させるとともに、そのメディアストリームに対応するＦＥＣストリーム用のバッファを確保する（ステップＳ５０２）。ここで、視聴用のサイズとは、ネットワークでのデータ伝送レートの変動に起因したバッファアンダーフローの発生が防止されるように決められたサイズである。
【００９３】
次に、選局処理部１３５は、ＳＩ情報格納部７３に格納されたＳＩ情報から、新たな視聴チャンネルに対応するＦＥＣストリームのマルチキャストアドレスを抽出する。次に、選局処理部１３５は、ＦＥＣストリームのマルチキャストアドレスに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージの送信を通信処理部１１０に依頼する（ステップＳ５０３）。
【００９４】
通信処理部１１０は、この依頼に従って、Ｊｏｉｎメッセージをルータ１４へ送信する。ルータ１４は、受信装置１００からのＪｏｉｎメッセージを受信すると、ＩＧＭＰテーブルに、このマルチキャストグループのアドレスと対応付けて受信装置１００のＩＰアドレスを登録する。以後、ルータ１４は、ＩＧＭＰテーブルに登録された情報に従って、配信サーバから配信された当該ＦＥＣストリームを受信装置１００にルーティングする。これにより、受信装置１００にて、当該ＦＥＣストリームの受信とバッファリングが開始される。
【００９５】
次に、視聴履歴記録部７４は、新たな視聴チャンネルのコンテンツに関する、例えば、チャンネル、タイトル、ジャンル、出演者、放送時間などの情報をＳＩ情報格納部７３に格納されたＳＩ情報より抽出して視聴履歴として視聴履歴格納部７１に追加する。選局処理部１３５は、視聴履歴格納部７１に格納された視聴履歴をもとにユーザの嗜好情報を生成して、嗜好情報格納部７２の内容を、新たに生成された嗜好情報で置き換える。続いて、選局処理部１３５は、コンテンツを配信中のすべてのチャンネルについて、嗜好情報格納部７２に格納されたユーザの嗜好情報をもとに優先度を再計算する（ステップＳ５０４）。
【００９６】
現時点で、直前まで視聴していた切り替え前のチャンネルのメディアストリームとＦＥＣストリームは、まだ受信装置１００にて受信され、バッファリングされている。そこで、次に、選局処理部１３５は、その切り替え前のチャンネルのメディアストリームを今後は視聴候補ストリームとしてバッファリングするかどうかを、再計算されたチャンネル間の優先度をもとに判定する（ステップＳ５０５）。ここで、切り替え前のチャンネルの優先度が低いならば、近い将来に再びユーザによって視聴のために選択される可能性は低いと考えられる。そこで選局処理部１３５は、切り替え前のチャンネルの優先度が上位からｎ番目以内である場合には、そのチャンネルのメディアストリームを今後は視聴候補ストリームとしてバッファリングすることを決定する。また、選局処理部１３５は、切り替え前のチャンネルの優先度が上位からｎ番目より低い場合には、そのチャンネルのメディアストリームを受信しないことを決定する。ここで、ｎは固定値あるいはユーザによる設定値でもよい。
【００９７】
選局処理部１３５は、直前まで視聴していたチャンネルのストリームを視聴候補ストリームとしてバッファリングすることを決定した場合、ＳＩ情報から、そのチャンネルに対応するＦＥＣストリームのマルチキャストアドレスを抽出する。選局処理部１３５は、抽出したＦＥＣストリームのマルチキャストアドレスに対応するマルチキャストグループからの離脱を要求するＬｅａｖｅメッセージの送信を通信処理部１１０に依頼する。通信処理部１１０は、これらの依頼に従って、Ｌｅａｖｅメッセージをルータ１４へ送信する（ステップＳ５０６）。ルータ１４は、受信装置１００からのＬｅａｖｅメッセージを受信すると、ＩＧＭＰテーブルから、そのＦＥＣストリームのマルチキャストアドレスに対応付けて登録されている受信装置１００のＩＰアドレスを抹消する。
【００９８】
この後、選局処理部１３５は、切り替え前のチャンネルのＦＥＣストリーム受信用のバッファを消去するとともに、切り替え前のチャンネルのメディアストリーム受信用のバッファ容量を、視聴候補ストリームとして必要な容量まで低減する（ステップＳ５０７）。
【００９９】
これにより、以後は、切り替え前のチャンネルのＦＥＣストリームは受信装置１００にて受信されず、メディアストリームだけが受信装置１００にて受信されるようになる。すなわち、以後は、切り替え前のチャンネルのメディアストリームが視聴候補ストリームとして受信装置１００にて受信され、バッファリングされる。
【０１００】
この結果、受信装置１００が利用可能なネットワーク帯域とバッファ容量の空きが増加するので、選局処理部１３５は、図７のステップＳ２０３に移行する。これにより、新たな視聴チャンネルのストリームと視聴候補ストリーム以外の各ストリームについて、優先度の高いものから順に、視聴候補ストリームとして受信すべきかどうかを判定する処理が行われる。
【０１０１】
また、ステップＳ５０５で、選局処理部１３５は、切り替え前のチャンネルのストリームを視聴候補ストリームとしてバッファリングしないことを決定した場合には以下の動作を行う。選局処理部１３５は、ＳＩ情報から、その切り替え前のチャンネルに対応するメディアストリームのマルチキャストアドレスとＦＥＣストリームのマルチキャストアドレスとを抽出する。受信装置１００は、各々のストリーム毎に、対応するマルチキャストグループからの離脱を要求する２つのＬｅａｖｅメッセージをルータ１４へそれぞれ送信する（ステップＳ５０８）。ルータ１４は、受信装置１００からの上記の２つのＬｅａｖｅメッセージを受信すると、ＩＧＭＰテーブルから、それぞれのマルチキャストグループのアドレスと対応付けて登録されている受信装置１００のＩＰアドレスを抹消する。これにより、受信装置１００にて、切り替え前のチャンネルのメディアストリームとＦＥＣストリームは受信されなくなる。
【０１０２】
この場合においても、受信装置１００が利用可能なネットワーク帯域とバッファ容量の空きが増加するので、選局処理部１３５は、新たな視聴候補ストリームの設定を試みるために図７のステップＳ２０３に移行する。これにより、新たな視聴チャンネルのストリームと視聴候補ストリーム以外の各ストリームについて、優先度の高いものから順に、視聴候補ストリームとして受信すべきかどうかを判定する処理が行われる。
【０１０３】
以上説明したように、本実施形態の受信装置１００では、視聴中のチャンネルのストリームとは別に、１以上のチャンネルのストリームを視聴候補ストリームとして受信してバッファリングする。受信装置１００では、視聴候補ストリームとして受信中のいずれかのチャンネルを視聴対象のチャンネルに切り替える指示がユーザより入力されたとき、バッファリングされた当該チャンネルのストリームをデコードして再生を開始するとともに、当該チャンネルのストリームを視聴対象ストリームとして受信することを開始する。これにより、ユーザから見た視聴チャンネルの切り替え時間を大幅に短縮することができる。
【０１０４】
また、本実施形態の受信装置１００では、受信装置１００がストリームを受信してバッファリングするために利用できる資源の範囲で、できるだけ多くのチャンネルの視聴候補ストリームを受信してバッファリングをする。これにより、マルチキャストストリームの多チャンネル化に対応しつつ、視聴チャンネルの切り替え時間を短縮できる。
【０１０５】
さらに、本実施形態の受信装置１００では、各チャンネルの優先度をユーザの嗜好を基準に算出し、優先度の高いチャンネルから優先的に視聴候補ストリームとして受信するチャネルとして選択する。これにより、ユーザが切り替え先の所望のチャンネルを選択する際に、その所望のチャンネルが視聴候補ストリームを受信中のチャンネルの中から選択される確率を大きくすることができる。
【０１０６】
さらに、本実施形態の受信装置１００において、視聴候補ストリームをバッファリングするバッファ容量は、視聴チャンネルの切り替え直後の映像と音声の再生が保証される値に設定されている。これにより、メディアストリームのデコード等の再生処理に要する短い時間を待つだけで、ユーザから見た視聴チャンネルの切り替えが行われるとともに、バッファ容量の利用効率を高めることができる。
【０１０７】
＜第２の実施形態＞
次に、本発明の第２の実施形態を説明する。
この実施形態は、ネットワーク環境の伝送特性の劣化などに応じて、受信装置１００にて視聴候補ストリームとして受信するチャンネル数を動的に変更する方式に関するものである。
【０１０８】
図１１は、ネットワーク伝送特性に応じて受信チャンネル数を動的に変更する処理に関するフローチャートである。この処理は、例えば、ユーザにより指定された任意のタイミングで行われてもよいし、定期的に行われてもよい。定期的に行われる場合には、配信されるコンテンツの切り替わりが発生する時刻の数分前（ｘ時２５分、ｘ時５５分など）に開始されるようにすることが効率的である。
【０１０９】
まず、選局処理部１３５は、受信装置１００で現在利用可能なネットワーク帯域とバッファ容量を算出する（ステップＳ６０１）。次に、選局処理部１３５は、ネットワーク伝送特性を評価する情報、例えば、ＦＥＣ復元前のデータのエラーレートや、ＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）による例えばパケット損失率など、ネットワーク伝送特性を評価する情報を取得する（ステップＳ６０２）。ここで、現在利用可能なネットワーク帯域とバッファ容量の各実効値は、ネットワーク伝送特性の劣化の度合が大きくなるほど低下する。
【０１１０】
そこで、選局処理部１３５は、ネットワーク伝送特性の劣化の度合を見込んだとしても、現在利用可能なネットワーク帯域およびバッファ容量が視聴チャンネルのストリームと視聴候補ストリームを受信するのに十分であるかどうかを判定する（ステップＳ６０３）。より具体的には、選局処理部１３５は、例えば、現在使用中のネットワーク帯域に、ネットワーク伝送特性の評価情報である例えばＦＥＣ復元前のデータのエラーレートを乗じて得た値を、現在利用可能なネットワーク帯域から減算する。その結果得た値がマイナスであれば、現在利用可能なネットワーク帯域が視聴チャンネルのストリームと視聴候補ストリームを受信するのには不十分であると判定する。逆に、プラスであれば、現在利用可能なネットワーク帯域が視聴チャンネルのストリームと視聴候補ストリームを受信するのには十分であると判定する。現在利用可能なバッファ容量についても同様に判定が行われる。
【０１１１】
現在利用可能なネットワーク帯域またはバッファ容量のいずれかがネットワーク伝送特性を見込んだ場合に不十分であると判定された場合（ステップＳ６０２のＮＯ）、選局処理部１３５は、次のように処理を行う。選局処理部１３５は、現在受信中の１以上の視聴候補ストリームのうち優先度が最も低い視聴候補ストリームの受信を停止するように処理を行う。すなわち、選局処理部１３５は、現在受信中の１以上の視聴候補ストリームのうち優先度が最も低い視聴候補ストリームを判断し、その視聴候補ストリームに対応するマルチキャストグループからの離脱を要求するＬｅａｖｅメッセージの送信を通信処理部１１０に依頼する。通信処理部１１０は、この依頼に従って、優先度が最も低い視聴候補ストリームに対応するマルチキャストグループからの離脱を要求するＬｅａｖｅメッセージをルータ１４へ送信する（ステップＳ６０４）。これにより、優先度が最も低い視聴候補ストリームの受信とバッファリングが停止される。
【０１１２】
ネットワーク伝送特性を見込んだ場合の、現在利用可能なネットワーク帯域およびバッファ容量が十分であると判定された場合、選局処理部１３５は次のように処理を行う。選局処理部１３５は、受信していないチャンネルの各コンテンツについて、嗜好情報格納部７２に格納されたユーザの嗜好情報をもとに優先度を判定する。次に、選局処理部１３５は、この判定結果をもとに、受信していないチャンネルのコンテンツにおいて最高優先度のコンテンツを判定する。選局処理部１３５は、そのコンテンツを配信しているチャンネルのメディアストリームの受信によるネットワークの消費帯域とバッファ消費容量を算出する。選局処理部１３５は、そのチャンネルのメディアストリームを視聴候補ストリームとして受信するために必要なネットワーク帯域とバッファ容量が残っているかどうかを判定する（ステップＳ６０５）。
【０１１３】
この判定で、選局処理部１３５は、必要なネットワーク帯域とバッファ容量の少なくとも一方が残っていないことを判定すると、何もせずに終了する。選局処理部１３５、必要なネットワーク帯域とバッファ容量が残っていることを判定した場合には、そのチャンネルのメディアストリームに対応するマルチキャストグループへの参加を要求するＪｏｉｎメッセージの送信を通信処理部１１０に依頼する。通信処理部１１０は、この依頼に従って、Ｊｏｉｎメッセージをルータ１４へ送信する（ステップＳ６０６）。これにより、受信装置１００にて、その優先度が最高のチャンネルのメディアストリームの受信とバッファリングが開始される。
【０１１４】
以上説明したように、第２の実施形態によれば、ネットワークの伝送特性の変動に追従して、ストリームを視聴候補ストリームとして受信するチャンネルの最大数を最適化する。これにより、ネットワーク帯域やバッファ容量の不足により各チャンネルのストリーム受信およびバッファリングの動作、ひいてはメディアストリームの再生が不安定になることを防止できる。
【０１１５】
なお、本発明は、上述の図示例にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【図面の簡単な説明】
【０１１６】
【図１】本発明の第１の実施形態に係る受信装置を用いるマルチキャスト配信システムの構成を示すブロック図である。
【図２】本発明の第１の実施形態に係る受信装置の構成を示すブロック図である。
【図３】典型的な受信装置での視聴チャンネルの切り替え例を説明する図である。
【図４】図３の視聴チャンネルの切り替え発生時点Ｔ２の時間軸を拡大して示す図である。
【図５】本発明の第１の実施形態に係る受信装置での視聴チャンネルの切り替え動作を説明する図である。
【図６】選局処理部による視聴候補ストリームのチャンネル選択に係るブロック図である。
【図７】視聴チャンネルの切り替え処理のための前処理を説明するためのフローチャートである。
【図８】受信装置で利用可能なネットワーク帯域とバッファ容量を算出する処理のフローチャートである。
【図９】判定対象チャンネルのメディアストリームの受信による消費帯域とバッファ消費容量を求める手順のフローチャートである。
【図１０】ユーザからの指示による視聴チャンネルの切り替え動作に関するフローチャートである。
【図１１】ネットワーク伝送特性に応じて受信チャンネル数を動的に変更する処理に関するフローチャートである。
【符号の説明】
【０１１７】
１０…マルチキャスト配信システム
１１…放送コンテンツ事業者
１２…ＣＤＮ網
１３…配信サーバ
１４…ルータ
７１…視聴履歴格納部
７２…嗜好情報格納部
７３…ＳＩ情報格納部
７４…視聴履歴記録部
１００…受信装置
１０１…通信インタフェース部
１０２…ディクリプタ
１０３…デマルチプレクサ
１０４…映像・音声出力処理部
１０５…映像・音声出力インタフェース
１０６…リモコンインタフェース
１０７…ＤＲＭクライアント
１０８…ＢＭＬブラウザ
１１０…通信処理部
１２０…ストリーミング処理部
１２１…バッファ部
１２２…ＦＥＣ処理部
１３０…ＡＶプレーヤ
１３１…映像デコーダ
１３２…音声デコーダ
１３３…字幕デコーダ
１３４…再生制御部
１３５…選局処理部
１５１…リモートコントローラ
【図１】
2010093576.tif 000003
【図２】
2010093576.tif 000004
【図３】
2010093576.tif 000005
【図４】
2010093576.tif 000006
【図５】
2010093576.tif 000007
【図６】
2010093576.tif 000008
【図７】
2010093576.tif 000009
【図８】
2010093576.tif 000010
【図９】
2010093576.tif 000011
【図１０】
2010093576.tif 000012
【図１１】
2010093576.tif 000013