JP2009017064A - 映像受信装置及びマルチキャスト配信コンテンツ受信制御方法 - Google Patents

Abstract

【課題】
IPマルチキャスト通信によるコンテンツ配信が普及し、不特定多数の映像配信チャンネルから所望の番組を探す環境となった時、以前の視聴番組を時系列的に行き来できる番組切替をスムーズに行なう。
【解決手段】
マルチキャストアドレスを取得する選局手段と、選局手段により取得したマルチキャストアドレス宛のデータパケットを取得するために、自ノードが受信者であることをネットワークの他ノードに宣言し当データを転送してもらう手続きを行なうマルチキャスト受信手段と、データパケットを取得して再生表示する番組再生手段と、自ノードが受信者ではないことをネットワークの他ノードに宣言する手続きを行なうマルチキャスト停止手段と、ネットワークの許容通信帯域に応じ、マルチキャスト受信手段とマルチキャスト停止手段を使い、自ノードへの転送番組数を調節するマルチキャスト受信管理手段を設ける。
【選択図】 図１

Description

本発明は、視聴者の要求に応じて、インターネット等の通信ネットワークを介してコンテンツ配信サーバの配信する映像コンテンツを受信し、再生するネットワーク対応テレビなどの映像コンテンツ受信装置および方法に関する。

近年、見たい時に見たいタイトルを楽しむことが可能なビデオオンデマンド（ＶＯＤ）や、放送局が放送電波の代わりにインターネットを通じて放送番組を配信するＩＰ(インターネットプロトコル)放送など、放送電波ではなくネットワークを通じて映像コンテンツを配信するサービス形態が本格化し、対応してテレビやレコーダなどの受信機もネットワーク機能を搭載し、映像コンテンツをデータパケットとして受信し再生する機能を搭載することが普通になって来ている。

IPネットワークを使ったVODサービスやIP放送は、サービス事業者の配信サーバが音楽や動画映像などのＡＶメディアコンテンツファイルを先頭から順次１パケットづつデータ送信し、それを視聴者の受信機（クライアント）が受信することにより実現されるが、特にIP放送の場合には、マルチキャストを使ってコンテンツ配信が行なわれる。

インターネットプロトコルの通信方式には、ネットワーク機器が1対1でIPパケットを送受信するユニキャストと、1台の機器から複数の機器に同じIPパケットを同時に送り届けるマルチキャストがあり、通常の通信では殆どがユニキャスト方式で行なわれている。

しかし、ユニキャストは複数の相手にパケットを送る場合、送る相手機器の台数分のパケットを用意して同時送信しなくてはならない。IP放送は、各家庭のTVで同時に同じ映像番組を視聴するため、送る相手の数が該当番組を視聴する各家庭のTV総数という膨大な数になり、ユニキャストでのコンテンツ配信はサーバの負担が無限に増えて不可能であるため、マルチキャスト通信が使用される。

マルチキャスト通信方式ではサーバはマルチキャストアドレスを宛先とする一つのパケットを配信の拠点となるルータに送信し、あとは、ルーティングを行なうためにネットワークに配されているルータが、必要に応じてパケットをコピーして転送を繰り返すことにより、多数の受信機にデータパケットが届けられることになる。このように、マルチキャスト通信の場合、サーバの負担は小さいが、通信経路の決定やパケットの転送先の登録などのルーティングの手順が複雑になり、ルータやスイッチなどの中継機器の負担が増えることになる。

また、受信機も、ユニキャスト通信の時のように、相手先のサーバに直接コンテンツデータの送信を要求するのではなく、ネットワーク上でデータパケットを中継しているルータ群に、所望のデータパケットをコピーし転送してくれるよう要求しなくてはならない。
この受信機がルータにマルチキャスト受信要求を行なうために使用されるプロトコルに、IGMP(Internet Group Management Protocol)やMLD(Multicast Listener Discovery)等があり、その仕組みは以下のようになる。

まず、受信機は、視聴したい番組コンテンツを示すIPマルチキャストアドレスを別途番組配信情報などからから得る。そして、自身が接続しているコンテンツ配信ＩＰネットワーク網内のルータに対し、所望のコンテンツを示すＩＰマルチキャストアドレスを通知し、該マルチキャストアドレス宛てのコンテンツのデータパケットを受信することを宣言する（Listener Report）。

そして、該宣言によってＩＰ網内のマルチキャストに対応した各ルータが、Listener Reportを発信した受信機に、該当のマルチキャストアドレス宛てデータパケットが転送されるように配送路を構築し、そして配信元のサーバから受信機までデータパケットが転送され到達することで、受信機が番組コンテンツを受信することが可能となる（図１参照）。
つまり、IP放送でのマルチキャストアドレスは、TV放送の場合の番組チャンネルに相当し、視聴したい映像コンテンツのマルチキャストアドレスを得ることは、電子番組ガイドなどから、何時に何チャンネルで見たい番組が放映されるかを調べる行為に相当する。

ところで、IPネットワークを介しての映像コンテンツ配信は、放送局の電波送信システムとは異なり、配信サーバさえあれば誰でも映像コンテンツを任意の受信機に送信できることから、IP放送の時代が本格化するにつれ、配信される映像番組のチャネルも飛躍的に増加すると予想される。

そのような不特定多数の映像配信チャンネルから所望の番組を探す環境となった時、ブラウザであちらこちらのWebサイトをリンクを辿って見て回るネットサーフィンのように、あちこちのサーバの配信するコンテンツのマルチキャストアドレスをリンクを辿って取得しては視聴するような、番組サーフィンを視聴者が行なうことが予想され、今までの所謂ザッピング（リモコンの数字ボタンやチャンネルＵＰ／ＤＯＷＮボタンで放送チャンネルを次々と切替える処理）とは異なった番組映像切り替えのユーザインタフェース手段が求められると考えられる。

IPアドレス特にIPv6アドレスは桁数が多く、放送チャンネルのようにユーザがリモコンの数字ボタンで選択あるいは入力できるような数字の並びではないため、マルチキャストアドレスをサーフィンして回る際には、ブラウザが備える、戻る／進むボタンのような、以前視聴していた番組を時系列的に（「戻る」ボタンを押す毎に）遡って見てみたり、以前の視聴番組をさかのぼって視聴した後、逆に（「進む」ボタンを押して）最近見ていた番組コンテンツ視聴に繰り上がってきたりというユーザインタフェースが望ましい。

さらにIP放送の番組チャンネル切替えが放送と異なる点に、切替え時間が、ネットワークの状態よって左右されてしまうことがある。

つまり、上述したように、映像番組であるコンテンツの受信は、配信元のサーバから最終の配信先となる受信機までの間にあるルータやレイヤ3スイッチなど、全てのネットワーク中継機器が、受信機のListener Report要求を受け取り、該当のパケットを転送する処理を終えて後、やっと受信機までコンテンツが到達し、受信機がデータを取り込んで再生することが可能となる。

サーバと受信機の間のネットワーク経路に多くのルータが存在すればするほど、受信機がコンテンツのデータパケットを受信可能になるまでの時間が遅くなる。また、例えば経路中に一つでも前記転送処理の動作の遅いルータがあれば、他の機器がどれほど高速に処理しても、最も遅い機器の転送処理時間がボトルネックになってしまう。

特に、今まで見ていた番組コンテンツを別の番組コンテンツに切替えるときは、今まで受信していたマルチキャストアドレスのデータパケット転送処理を止め、さらに別のマルチキャストアドレスのパケット転送を行なう手順となり、いよいよ処理の負荷が大きくなる。つまり、マルチキャスト方式のIP放送では、ネットワークの状態よっては番組コンテンツの切替え、つまり番組サーフィンがスムーズに行なえない危険がある。

上記の番組コンテンツサーフィンの問題に対し、特許文献１では、連続チャネル切替えにより順次受信した系列データ組みをマルチ画面表示する受信機が開示され、また、マルチキャスト方式で配信されるコンテンツ切替えの問題に対し、特許文献２では、受信機が複数のコンテンツに対応した複数のマルチキャストチャンネル情報を予め取得して、マルチキャストチャンネル情報に従って受信手続きを行ない、既に受信している複数のコンテンツから対応するコンテンツを選択して出力する仕組みを設け、出力コンテンツを切替える要求をした際、既に受信している複数のコンテンツから対応するコンテンツを選択し出力することにより複数のコンテンツをクライアント上で視聴するシステムが開示されている。

特開２００６−１８６７３７号公報 特開２００５−８６２２２号公報

しかし、元々放送を大画面一杯に再生表示するのが通常であったTV等の受信機にとって、マルチ画面で映像を表示することは、かなりの処理の負担と製品コストの増大を招く。
また、数多くあるIP放送コンテンツから、今まで何となくリンクをたどって見てきた番組を行きつ戻りつ、気ままに見て回る映像番組サーフィンを行ないたい場合、予め複数の番組のIPアドレスに対して転送処理を行なっておくのは不可能である。

さらに、複数の番組の転送処理を行なう場合、ネットワークの帯域制限の問題がある。
一般にネットワークによるコンテンツ配信において、視聴者が同時受信できるコンテンツ番組の本数は利用する通信回線や受信機の性能により制限される。映像コンテンツは配信サーバによりネットワーク上にデータパケットとして送出され、ルータやスイッチ等の機器を経由して受信機まで届き、受信機内に取り込まれるが、その１秒当たりのデータ転送容量はビットレートと呼ばれ、各々のコンテンツファイルに固有の値である。

この値が大きいほど動画映像の解像度や滑らかさ等の品質が高くなるが、視聴のためのデータ受信に必要な利用帯域は大きくなる。視聴者の利用しているネットワーク環境や受信機の利用可能な帯域が、受信しているコンテンツのビットレートの合計よりも大きければ問題なく全てのコンテンツの受信再生が可能だが、利用可能な帯域の方が小さい場合、データが受信機まで届かなかったり、受信機内部での再生処理が間に合わなかったりして映像が乱れ飛んで視聴不可能になったりする。

つまり、膨大な数の番組が用意されるであろうIP放送において、視聴する可能性のある番組を全て転送状態にしておくことは、ネットワークの帯域制限上、実質的に不可能である。

本発明の一実施の態様は、例えば、特許請求の範囲のように記載する。

本発明では、ネットワーク上のルータやスイッチ等の中継機器の事情によって、受信機であるテレビの番組の切替え時間が決まってしまうIPマルチキャスト通信による映像コンテンツ番組の受信再生について、ユーザが複数の番組コンテンツを行きつ戻りつして視聴する番組サーフィンの場合に、番組切替え時間を出来るだけ短くスムーズに行なえるようにする効果がある。

今まで見てきた番組コンテンツを出来るだけ多く受信可能状態にしておき、同時に今まで見てきたコンテンツを選択的に切替えできるリモコンボタンなどのユーザインタフェースを設け、過去見た番組を選択視聴する際の映像受信再生装置の使い勝手を向上する。

図１はIPマルチキャスト通信方式で番組コンテンツを配信するコンテンツ配信サーバと本発明のマルチキャスト配信コンテンツ受信装置であるネットワーク対応テレビが、ルータやスイッチなどのネットワーク中継機器を経由してマルチキャストデータパケットを送受信している様子を示した例である。

コンテンツ配信ネットワーク１は、様々な従来のネットワーク物理層（光、有線、または無線ネットワークを含む）のいずれかを使用して実現されるインターネットプロトコル通信ネットワークであり、ルータやスイッチ、ハブなど、データパケットを送信元から送信先へ正確に送り届けるための通信制御機器41〜44も含まれる。

コンテンツ配信サーバ２は、映像番組のコンテンツをマルチキャスト方式で複数の受信機に番組コンテンツを配信するIP放送サービスを行なうためのサーバシステムである。
受信機３は本発明の一実施例であるネットワーク対応のデジタルテレビである。ネットワークを経由してマルチキャスト配信コンテンツを受信し、視聴者のために番組再生する機能を持つ。

図1では、コンテンツ配信ネットワーク１を介してコンテンツ配信サーバ２から映像コンテンツＡ、Ｂ、Ｃが配信されている。ネットワーク対応テレビ３は、IPマルチキャストプロトコルを用いて映像コンテンツＡの受信要求を出しており、スイッチ４２やルータ４３、４４が該受信要求に応じてデータパケットＡをネットワーク対応テレビ３に転送することによってコンテンツ配信が行なわれている様子を示す。

図2は、本発明のネットワーク対応テレビ３のハードウェア構成図である。

ネットワーク対応テレビ３は、放送電波を受信するアンテナやデジタルチューナ以外に、ＩＰ（Internet Protocol）データパケットを送受信するためのＩＰ通信ポートを備え、ＴＣＰ（Transmission Control Protocol）、ＵＤＰ（User Datagram Protocol）、ＤＨＣＰ（Dynamic Host Configuration Protocol）、ＤＮＳ（domain name server）、ＨＴＴＰ(HyperText Transfer Protocol)、ＲＴＰ(Real-time Transport Protocol)、ＲＴＳＰ(Real Time Streaming Protocol)、MLD(Multicast Listener Discovery)、IGMP(Internet Group Management Protocol)等の各種通信プロトコルとブラウザなどのアプリケーションを搭載しており、該ＩＰ通信ポートでルータ等を介して宅外のコンテンツ配信ネットワーク１に接続し、コンテンツ配信サーバ２の配信する様々なコンテンツのストリーミングやダウンロードのサービスを利用することができる。

また、リモコン３０には、テレビチャネルの入力のための数字ボタンの他に、ＩＰ放送番組サーフィンのための「戻る」ボタンと「進む」ボタンが備えられている。「戻る」ボタンは、押すたびに今まで視聴してきたチャネルを一つずつ順次前に戻るように番組切替えを行ない、「戻る」ボタンで過去に順次遡って再視聴した後、「進む」ボタンを押すことによって再度番組を現在に向かって辿って順次切替えることをユーザが指示する為の手段である。

なお、本例のIPマルチキャストコンテンツ配信のサービスでは、コンテンツ配信サーバが送出するIP放送番組の番組表データを受信機が受信して表示画面に表示し、ユーザが表示された番組を指定するチャネル番号をリモコンの数字ボタンを使って入力し視聴番組を指定、受信機は入力されたチャネル番号を番組表データに含まれるマルチキャストアドレスとチャネル番号換算表に基づいて、番組映像コンテンツの宛先マルチキャストアドレスを得るものとする。

該手続きで得られたマルチキャストアドレスを基に、受信機はMLDまたはIGMPプロトコルを用いて再生表示する番組の映像コンテンツ受信のための手続きを行ない、RTPプロトコルを用いてコンテンツのデータパケットを受信する。

本ネットワーク対応テレビは、RTPプロトコルを使って受信したコンテンツのデータパケットを、放送波と同じデコード処理が可能なようにデータ変換を行った後デコーダ１４に送る。これにより放送もIPネットワーク配信されたコンテンツも区別なく再生視聴が出来る。

なお、勿論、視聴する番組の選択方法やマルチキャストアドレスの取得方法、サービスで使用するＩＰプロトコルは上述に限るものではない
図3はネットワーク対応テレビ３がマルチキャスト配信されたコンテンツパケットを受信し再生する際のマルチキャスト受信状態管理の制御プログラムのフローチャートで、該プログラムはＲＯＭ２４に格納されＣＰＵ２０により実行される。図4から図9はCPUが図3のフローで使用する受信マルチキャストアドレスの管理テーブルで、ＲＡＭ２３上に作成される。以下、図3から図9を使って、IPマルチキャスト配信コンテンツ受信時の受信状態管理処理と、戻るまたは進むボタンが押されたときの番組チャンネル切替え動作を説明する。

まず、ネットワーク対応テレビは電源が入ると、通常、電源ＯＦＦ直前に見ていた状態及びチャンネルで番組再生を開始し、その後の様々な処理で使用されるデータやテーブルの初期化処理を済ませた後、ユーザのリモコン操作待ちとなる（ステップ１０００〜１００１）。

なお、一般にテレビのリモコンには放送チャンネル選択のボタンや音量調整ボタン等、テレビを動かすための様々な機能があり、該リモコンボタンの操作に応じて該当する各種処理が行われることになるが（ステップ１００１、ステップ２０００）、ここでは、本発明の特徴であるＩＰマルチキャスト配信番組の選択再生と、リモコンの「戻る」および「進む」ボタンによる番組チャンネル切替えの際の、マルチキャスト受信状態管理についてのみ説明する。

まず、リモコンでマルチキャスト配信される番組の視聴を指定したとする(ステップ１００２、ステップ１００３)。この視聴番組の直接指定の場合はステップ１００４に進み、ユーザが視聴する番組を選択的に入力できるよう番組ガイドサービス画面を表示するモードに移る。本例の場合、この番組選択用の画面はコンテンツ配信サーバがWebサイトとして提供することを想定しており、ネットワーク対応テレビ３の動作は、HTTPブラウザを起動しコンテンツ配信サーバの番組ガイドサイトにアクセスするだけである。

ユーザは、リモコンのカーソルボタンや決定ボタンを使って番組ガイドのページをめくったり予告ダイジェストを見たりしながら所望の番組を選択し、ブラウザの決定機能を使って指定入力する（ステップ１００５）。ユーザが所望の番組を選択指定すると、コンテンツ配信サーバ2は、ネットワーク対応テレビ３に、ユーザが所望した番組コンテンツを受信するに必要なマルチキャストアドレスや転送ビットレート等の情報を通知するので、ネットワーク対応テレビ３は該受け取った情報をマルチキャスト受信管理テーブルに記録し、自身の受信可能な帯域に応じて、IPマルチキャスト通信の受信参加状況を調整しコンテンツ再生処理を行う。

上述したように、同時受信できるコンテンツ番組の本数は、使用しているネットワークの利用可能な通信帯域により決まる。例えば、ネットワーク環境の通信可能な帯域が５０Mbpsであったとする。すると、各々１６Mbpsのコンテンツ番組なら3本同時に受信状態にしていても通信帯域は合計４８Mbpsなので、どの映像コンテンツデータも問題なく受信し再生視聴できる。しかし、各々２０Mbpsのコンテンツであれば、３本を受信しようとするとネットワークの通信能力を越えるデータが押し寄せ、パケット落ちなどが生じてコンテンツを正常に再生できなくなるため、同時受信は2本までになる。

ステップ１００６から１０１０では、マルチキャスト受信管理テーブルを使って、上記通信可能帯域の制限に収まるように、IPマルチキャスト通信の受信グループ参加状況を管理する。本例のネットワーク対応テレビ３が接続している宅内ネットワークの環境では、ネットワークの通信帯域は９０Mbpsが限界であるとする。

そして、切替え時の余裕を考慮し、受信参加状態のコンテンツの合計ビットレートが６０Mbpsを超えないように調整する。この制限値は、テレビが接続する周辺ネットワークの仕様から得られる値をあらかじめリモコンから入力して設定しておくこととするが、もし、サーバから順次ビットレートの上がって行く帯域テスト用データパケットを送信するサービスがある場合は、テレビに何bpsのデータパケットまで正常受信したかを判定する仕組みを設けることにより自動測定が可能である。

ステップ１００５で視聴番組を指定した後、ステップ１００６で「戻る」番組切替えを行なっているか否かを判定しているが、この処理の説明は後述する。ここでは「戻る」切替え操作は行なっていないものとしてステップ１００７に進む。

まず、ステップ１００７では、ステップ１００５で取得した番組コンテンツの情報をRAM
２３に電源ON時に作成されたマルチキャスト受信管理テーブルに記載する。

図4から図9はマルチキャスト受信管理テーブルの例である。本装置例のマルチキャスト受信管理テーブルは、ユーザが視聴した番組コンテンツのマルチキャストアドレスやビットレート等の番組情報を時系列的に格納していくためのリングバッファであり、受信処理の制御のため、一番最近に番組のマルチキャストアドレスが入力されたことを示す先頭フラグ、マルチキャスト受信中つまり周辺ルータに転送要求を出していことを示す受信フラグ、現在デコーダ１４に送って再生しているコンテンツであることを示す再生フラグを書き込む欄を設けている。

ステップ１００７では、現在先頭フラグが付いている番組情報の記録欄の次の欄に、新規に視聴を所望する番組情報を書込み、同時に先頭フラグが該新しく書き込んだ欄がON(１)になるように管理テーブルを更新する。

ところで、本例の図では、記載の都合上、本発明で使用するIPマルチキャストアドレスとビットレートのみを番組コンテンツ情報としているが、一般に番組コンテンツ情報は、送出サーバアドレスや著作権、視聴開始時間など他にも様々な情報を含んでおり、それら全ての情報を格納することが多い。また、本例の図では、フラグはONが１、OFFが０としている。受信中である番組コンテンツを表す受信フラグは複数の番組でONになるが、先頭フラグと現在再生中であることを示す再生フラグは、該当する一つの番組一つだけがONになる。

また、やはり記載の都合上、図のテーブルは8欄しかなく、従って過去受信した８番組しか記録に残らないことになるが、勿論格納できるコンテンツの数、即ち管理テーブルの大きさは任意である。

ステップ１００８では、該新規に視聴所望の番組コンテンツパケット受信のため手続きを行なう。新規データパケットをIP通信ポート２２から装置内の取り込むためのソケットを準備し、IGMPプロトコルやMLDプロトコルに従って、IPマルチキャスト通信パケット受信開始の通知（Listener Report）を送信し、マルチキャスト受信管理テーブルの受信フラグをOFFからONにする。

そして、受信開始を通知したIPマルチキャストパケットがIPポート２２まで届き始めたら、ステップ１００９で、今まで再生していた番組コンテンツパケットの取り込みとデコードを中止し、新たに届き始めた番組コンテンツのパケットを取り込んでデコーダに送る再生処理を開始する。同時に受信管理テーブルの再生フラグの位置を更新する。

具体的には今まで視聴していた番組の再生フラグをONからOFFに、新たに視聴する番組の再生フラグをOFFからONにする。ユーザから見れば、このステップ１００９の処理で番組が切替わったことになる。

ステップ１０１０と１０１１では、マルチキャスト受信参加の調整を行なう。ステップ１０１０で、受信フラグが１になっている番組、すなわち番組のデータパケットがネットワーク対応テレビ3まで転送されてIPポート２２からいつでも受信可能な状態となっている番組のビットレートを合計し、通信可能帯域の制限値と比較する。

もし合計のビットレートが通信可能帯域を越えていたら、受信状態中の番組の中で最も過去に視聴した番組を受信停止対象とし、再度残りの受信状態の番組のビットレート合計を算出、制限値と比較する。この過程を繰り返して、受信状態の番組のビットレート合計を帯域制限内の収めるために停止しなくてはならない番組を調べる。

ステップ１０１１で、IGMPプロトコルやMLDプロトコルに従って、該受信を停止しなくてはならない番組のIPマルチキャスト通信パケット受信停止の通知（（Leave GroupまたはListener Report）を送信し、マルチキャスト受信管理テーブルの受信フラグをONからOFFにする。また、受信用のソケットも削除する。
以上が、ユーザが番組のマルチキャストアドレスを指定することにより視聴する番組を切替える際に、本ネットワーク対応テレビ3が行なうマルチキャスト受信管理処理である。
図４の受信管理テーブル情報は、今までに3つの番組を視聴し、現在はNo2欄に記載されたアドレス「224.0.200.121」のコンテンツを視聴している場合の例である。

No2欄の先頭フラグおよび再生フラグに１が書かれていることで、No2欄の番組が一番最近に指定され、現在再生視聴中であることが読み取れる。また、No0,No1,No2の3つの番組コンテンツのビットレート合計が60Mbps以下であるため、No0とNo1番組とも再生はしていないがデータの受信状態を維持しており、受信フラグが１になっている。

この図4の状態で、ステップ１００７からステップ１０１１の処理によって、新たにアドレス「237.12.0.111」、ビットレート１８の番組に再生視聴を切替えた結果が図5のマルチキャスト受信管理テーブルになる。先頭フラグおよび再生フラグがNo3欄に移り、またマルチキャスト受信参加の調整により、No0欄の番組の受信は停止されている。

なお、図4は分かりやすいよう、マルチキャスト受信管理テーブルに何もデータが入っていない初期状態で3つの番組が切替えられ視聴された場合を示しているが、本例の受信管理テーブルはリングバッファ構造になっており、No7欄まで情報が書き込まれるとNo0欄に戻って上書きしていく。従って、通常図4のような書込み状態は稀で、通常図6のような上書き状態となっている。

次に、リモコンの「戻る」「進む」ボタンを操作して番組サーフィンした場合の番組切替えとマルチキャスト受信管理処理を説明する。なお、本例のネットワーク対応テレビはリモコンが付いていて「戻る」「進む」の操作はリモコンで行なうようになっているが、ユーザの番組切替え指示の入力はリモコンに限るものではなく、例えばテレビ本体のボタンでもよく、またパソコンのアプリケーションに見られるように、画面の一部に仮想のボタンや操作卓が表示されていて、それをタッチパネルやポインティングデバイスで指定するようなユーザ指示入力の手段であっても勿論かまわない。

ステップ１０１２でリモコン操作が「戻る」又は「進む」であったと判定されると、ステップ１０１３で該当する番組が受信管理テーブルに存在するか否かを判定する。
つまり、マルチキャスト受信管理テーブルが初期状態で何も番組データが記録されていない場合や最初の一つ目の番組を視聴している場合は「戻る」に該当するひとつ前にアドレス指定して視聴した番組は存在しない。

または「戻る」操作を何度も行なってマルチキャスト受信管理テーブルに記録されている過去視聴した番組を全て遡って見てしまった場合には、それ以前に視聴した番組の記録が残っていないので「戻る」に該当する番組は無いことになる。

「進む」の場合は「戻る」操作を一度も行なっていない場合は該当番組は無い。また「戻る」で過去に遡って視聴した数だけ「進む」処理を行って、先頭フラグが１になっている番組まで来てしまった場合も、それ以上先の番組が存在しないので該当番組は無い。

該当する番組の記録があった場合はステップ１０１４に進む。ステップ１０１４では該番組の受信フラグの状態を調べ、ONであった場合はステップ１０１９に進んで、ステップ１００９で行った処理と同様に、現在ネットワーク対応テレビ３のIP通信ポート２２から取り込んでデコーダに送っているデータパケットを、該当の番組パケットに変更する。同時にマルチキャスト受信管理テーブルの再生フラグを切替えた該当番組がONになるよう更新する。これで戻る又は進むに該当する番組に再生が切替わる。

図7は図６の状態で「戻る」ボタンを1回押したときに、上述したステップ１０１３からステップ１０１９の処理が行なわれた結果のマルチキャスト受信管理テーブルである。
図6ではNo2欄の番組を視聴中（No2欄の再生フラグがON）で、また、先頭フラグもNo2欄がONなので、これが一番最近に視聴指定し再生した番組であり、従って「進む」ボタンは無効（該当番組が存在しない)である。「戻る」ボタンを1回押すと、一つ前のNo１欄の番組データが該当番組になり、受信フラグがONなので、取り込みデコーダに送るデータをアドレス「237.12.0.111」を持つパケットからアドレス「224.0.200.121」を持つパケットに変更するだけで番組切替えが出来る。

なお、図7の状態で「進む」ボタンを一回押すと図6の状態に戻るのは当然である。
もしステップ１０１４で、該当番組の受信フラグがOFFであった場合は、ステップ１０１５に進み、ステップ１００８で行なったように、まず、IPマルチキャスト受信開始処理を行なってからステップ１０１６で再生データパケットを変更する。そして、ステップ１０１７で帯域調整のために、どの番組の受信停止が必要か否か、そして停止すべき番組コンテンツはどれかを調べる。

ステップ１０１７の処理は、現在受信状態つまり受信フラグが１になっている一連の番組のビットレートを合計し、通信可能帯域の制限値と比較して受信停止すべきコンテンツがあるかを調べるところまではステップ１０１０と同じである。その後、受信停止する番組コンテンツを特定する際、「戻る」処理の最中であれば、受信停止する番組を先頭フラグがONの番組に近い側から特定し、「進む」処理の最中であれば、先頭フラグがONの番組から遠い側から特定する。つまり、受信状態の番組が連続するように受信停止を行なうことになる。

図８は、図７の状態からさらに４回「戻る」ボタンを押して、No0欄の番組→No７欄の番組→No.6欄の番組→No5欄の番組と過去に遡って番組を視聴した時のマルチキャスト受信管理テーブルの状態であるビットレート合計60Mbps以下になるよう、図７の時は受信状態だったNo2欄とNo1欄の番組コンテンツの受信が停止されている。

なお、「戻る」処理により過去に視聴した番組を選択視聴している時に、新たに番組を指定(ステップ１００３)するなど、先頭フラグの付いていない欄の番組を視聴している際に新たにマルチキャストアドレアス新規指定による番組切替えを行なう場合がある。この場合は、現在視聴している番組の次の欄に新規直接指定した番組を置く仕組みでも、または先頭フラグのある欄の次の欄に記載する仕組みでも、どちらでもよい。ただし、どちらの場合でも、戻る進むの番組切替えをスムーズに行なえるよう、受信状態の番組が一連に続くようにマルチキャスト受信管理テーブルを更新する必要がある。

本システムでは、上記、戻る状態で新規番組指定があった場合は、現在視聴中の番組を基準に受信管理テーブルを更新する。すなわち、ステップ１００６で、「戻る」の最中である場合、すなわち先頭フラグと再生フラグが異なった番組欄にある場合は、ステップ１０２０に進み、受信管理テーブル上の現在視聴番組欄以降から先頭フラグの付いた番組を全て無効として受信停止を行ない、現「戻る」視聴中の番組欄を先頭として先頭フラグを立てる。そしてステップ１００７で、「戻り」再生中だった番組の次の欄に該新たに指定した番組情報を書込み、その欄が先頭となる。

図９は図８（図６の状態から５回「戻る」ボタンを押してNo5欄の番組を見ている場合）の状態で、新たに「233.111.111.111」アドレスの番組コンテンツを視聴指定した際の受信管理テーブルの状態である。No6欄から先頭フラグのあったNo2までの番組受信を停止した後、一旦No5が先頭となる。そしてステップ１００７に進んでNo6欄に新たに指定した番組の情報が上書きされ、先頭フラグがONになっている。

以上のように、IPマルチキャスト通信方式による番組コンテンツの受信状態を、ネットワークの通信能力に応じて管理し、特に過去視聴した幾つかの番組チャンネルへの切替えをスムーズに行なうようにすることが出来る。

受信装置の接続するネットワークの利用可能帯域を考慮して、今まで見てきた番組コンテンツを出来るだけ多く受信可能状態にしておく仕組みのため、様々な帯域制限のネットワーク環境に繋がる受信機に幅広く適用できる。

IPマルチキャストによるコンテンツ配信システムの一例を示す図である。 本発明の一実施例を示すIPマルチキャスト配信コンテンツの受信機のハードウェアブロック図である。 本発明の一実施例を示すIPマルチキャスト配信コンテンツの受信状態管理処理の手順を示すフローチャートである。 図2の受信機のIPマルチキャスト配信コンテンツ受信状態を管理するためのデータテーブルの例である。 図2の受信機のIPマルチキャスト配信コンテンツ受信状態を管理するためのデータテーブルの例である。 図2の受信機のIPマルチキャスト配信コンテンツ受信状態を管理するためのデータテーブルの例である。 図2の受信機のIPマルチキャスト配信コンテンツ受信状態を管理するためのデータテーブルの例である。 図2の受信機のIPマルチキャスト配信コンテンツ受信状態を管理するためのデータテーブルの例である。 図2の受信機のIPマルチキャスト配信コンテンツ受信状態を管理するためのデータテーブルの例である。

符号の説明

１…ネットワーク、２ コンテンツ配信サーバ、３…受信機、１１…アンテナ・チューナ、１２…デスクランブラ、１３…デマルチプレクサ、１４…ビデオオーディオデコーダ、１５…メディア記録制御部、１６…ハードディスク、１７…デジタルビデオディスク、１８…表示画面、１９…スピーカ、２０…ＣＰＵ、２１…リモコンインタフェース部、２２…ＩＰ（インターネットプロトコル）通信ポート、２３…ランダムアクセスメモリ、２４…リードオンリメモリ、２５…グラフィックオーディオエンジン、２６…映像表示制御部、２７…オーディオ出力制御部、２８…メモリカード、３０…リモコン、３１…リモコン戻るボタン、３２…リモコン進むボタン、４１…エッジルータ、４２…レイヤ3スイッチ、４３…エッジルータ、４４…ホームゲートウェイルータ

Claims (4)

1台のサーバが複数のクライアントに向けて同じIPパケットを同時に届けるIPマルチキャスト通信方式により配信される映像番組コンテンツをネットワーク経由で受信し再生する映像受信装置において、
使用者がコンテンツ受信再生指示を入力するためのリモコン等のユーザインタフェース手段と、
前記ユーザインタフェース手段から入力された使用者の指示に従い、マルチキャスト配信された任意の映像コンテンツを受信するためのマルチキャストアドレスを取得する選局手段と、
前記選局手段により取得したマルチキャストアドレスを宛先とするデータパケットを取得するために、自ノードが前記マルチキャストアドレスに対応する受信者であることをネットワークの他ノードに宣言し、前記当データパケットを自ノードまで転送させる手続きを行なうマルチキャスト受信手段と、
前記マルチキャスト受信手段により取得可能な状態になった複数のデータパケットから、任意のデータパケットを取得してデコードし再生表示する番組再生手段と、
マルチキャスト受信手段により取得可能な状態とさせていたデータパケットの取得を停止するため、自ノードが受信者ではないことをネットワークの他ノードに宣言し前記当データパケットの転送を中止させる手続きを行なうマルチキャスト停止手段と、を備え、
ネットワークの許容通信帯域に応じ、前記マルチキャスト受信手段およびマルチキャスト停止手段を使って、自ノードへの転送データパケット量を調節するマルチキャスト受信管理手段を有することを特徴とする映像受信装置。

請求項１の映像受信装置において、
前記マルチキャスト受信管理手段が、使用者が受信指定した順にマルチキャストアドレスを時系列的に記録する受信管理テーブルを備え、前記時系列的に記録されたマルチキャストアドレス情報に従って自ノードへの転送データパケット量を調節することを特徴とする映像受信装置。

請求項２の映像受信装置において、
ユーザインタフェース手段は、再生番組の切替えを、今まで受信再生した番組から時系列順に間接指定する要求を入力する手段を備え、選局手段は時系列的に受信管理テーブルに記録されているマルチキャストアドレス情報から、前記間接的に指定された番組を再生番組として選択する手段を備えることを特徴とする映像受信装置。

1台のサーバが複数のクライアントに向けて同じIPパケットを同時に届けるIPマルチキャスト通信方式により配信される複数のコンテンツを、異なる複数の番組チャンネルとして受信し再生表示する映像受信機が、使用者の指示に従いコンテンツを受信する方法において、
映像受信機は複数のコンテンツに対応した複数のマルチキャストアドレス情報を、使用者が受信指定した順に時系列的に記録するステップと、前記時系列的に記録したマルチキャストアドレス情報に従ってコンテンツデータの受信手続きを行なうステップと、前記映像受信機の再生表示コンテンツを時系列的に切替える要求を受けるステップと、映像受信機は前記記録しているマルチキャストアドレス情報から前記切替え要求に対応するコンテンツデータを選択し再生表示するステップとを有するマルチキャスト配信コンテンツ受信制御方法。

Images