(57)【要約】【課題】中断することなく快適にストリーム放送を視聴可能とする。【解決手段】本発明によれば、第一の配信用サーバより配信されたストリーム放送データに連続するストリームデータの格納されている第二の配信用サーバのロケーション情報を検出し、第一の配信用サーバからのストリーム放送データの受信中に、検出されたロケーション情報に基づき第二の配信用サーバからのストリーム放送データの受信を開始すると共にこの第二の配信用サーバからのストリーム放送データを一時記憶要のメモリに記憶し、第一の配信用サーバによるストリーム放送データの再生処理が完了した後に、メモリに記憶された第二の配信用サーバからのストリーム放送データの再生処理を行う構成とした。【選択図】　　　図１３
2004134868.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してストリーム放送データを受信する装置であって、
第一の配信用サーバより配信されたストリーム放送データに連続するストリームデータの格納されている第二の配信用サーバのロケーション情報を検出し、前記第一の配信用サーバからのストリーム放送データの受信中に、前記検出されたロケーション情報に基づき前記第二の配信用サーバからのストリーム放送データの受信を開始すると共にこの第二の配信用サーバからのストリーム放送データを一時記憶要のメモリに記憶し、前記第一の配信用サーバによるストリーム放送データの再生処理が完了した後に、前記メモリに記憶された前記第二の配信用サーバからのストリーム放送データの再生処理を行うことを特徴とする受信装置。
【請求項２】
前記第一の配信用サーバより配信されたストリーム放送データより前記第二の配信用サーバのロケーション情報を複数検出することを特徴とする請求項１記載の受信装置。
【請求項３】
前記複数のロケーション情報のうち、乱数発生手段により前記第二の配信用サーバとして接続すべきサーバのロケーションを選択することを特徴とする請求項２記載の受信装置。
【請求項４】
前記複数のロケーション情報に対応した複数のサーバに対して並列に接続を開始して前記メモリに各サーバからのストリーム放送データを記憶し、前記複数のサーバのうち最も早く所定量のストリーム放送データの記憶が完了したサーバを前記第二の配信用サーバとして選択することを特徴とする請求項２記載の受信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は受信装置に関し、特にはネットワークよりストリーミング放送を受信する装置に関する。
【０００２】
【従来の技術】
従来、デジタルテレビ放送を受信する装置（以下ＤＴＶ装置）が知られている。そして、近年、この様なＤＴＶ装置において、放送チャンネルに加えて、接続されたネットワークよりストリーミング放送を受信、視聴することが考えられている。
【０００３】
ストリーミング放送を受信する場合、ネットワークにより受信したネットワークのパケット情報より、目的の各種フォーマットからなる図１に示す様なストリーミング放送のパケット情報を分離し、それぞれのストリーミング放送フォーマットに対応したプレーヤで再生し、視聴を行う。この時、ストリーミング放送のパケット情報は、不正利用を防ぐコンテンツ保護の目的から受信装置内の記憶装置には一括的に、あるいは継続的に記録はしないものの、ストリーミング放送のパケット情報に含まれる、独立した画像データ、音声データ、あるいは、同期の為のヘッダ情報を逐次処理する為に、受信したストリーミングデータを一時的にバッファリングしてから、各データのデコード処理及び同期処理を行った上で再生していた。また、この時、再生に必要な情報については、当該ストリーミング放送のパケット情報部分の再生が完了した時点で直ちに消去する事により、コンテンツ保護の目的も果たしていた。
【０００４】
この様にストリーミング放送の視聴の際は、ネットワークやストリーミング放送の送り手側サーバ負荷の影響や、再生の為の処理手続きなどの影響を受けて連続的なパケット情報の受信が出来ない場合においても、ある程度のバッファリングで吸収し、図２に示す様に、バッファリングの量が時間的に多少変動しつつも視聴が途切れる事無く、安定したストリーミング放送の視聴再生を実現していた。
【０００５】
【発明が解決しようとする課題】
しかしながら、実際のストリーミング放送による番組においては、図３に示す様に、リアルタイム視聴による６０分強の長さの番組を例にとっても、番組の冒頭部分から終盤にいたるまで、均等の数の視聴者が存在するとは限らないのが通常である。
【０００６】
例えば、番組の冒頭部分３０２では、番組の導入部分である為に比較的視聴者の興味を引く内容となっている場合が多く、その結果、多くの視聴者が暫くの間はこのストリーミング放送の番組を視聴する事となる。しかし、導入部分を過ぎると、当該番組に興味を持たない視聴者の多くは視聴を止め、他のストリーミング放送や、放送チャンネルの番組へと流れていく。
【０００７】
ところが、ストリーミング放送において中盤の見せ場が幾つか用意されている場合、他のストリーミングや、放送チャンネルにおいて、チャンネルザッピングを行っていた視聴者が、前述の番組の見せ場付近、３０３や３０４においては、暫くの間、ストリーミング放送を視聴する場合も多い。
【０００８】
その後、先程と同様に、見せ場を過ぎた時点で、興味が薄れた視聴者は再び、他のストリーミング放送や放送チャンネルの番組へと移っていく。さらに、当該ストリーミング放送が終盤にさしかかり、ストーリーとしてのクライマックス等を迎える事で、三度、ストリーミング放送の視聴者となる事も稀ではない。
【０００９】
さらに、実際のストリーミング放送による番組においては、正味６０分の番組であっても、当該ストリーミング放送のストリームデータに視聴者がアクセス可能である時間帯は先の番組の長さよりも長い時間である事が多く、その結果、視聴者はサーバにアクセス可能である時間内において、好きな時間に当該番組の視聴を開始する事が可能となっている。
【００１０】
図４は、ストリーミング放送が開始されてから視聴者がストリーミング放送に接続を開始し視聴を開始する割合の一例を示した図である。図４で、ストリーミング放送が開始され、視聴者がアクセス可能となると、このストリーミング放送の存在を告知されていた視聴者の多くは放送の開始から直ちに接続を開始し視聴を開始する。図４では放送開始後１５分頃に多くのユーザが接続を開始している。その後、徐々に接続を開始する視聴者は減りつづけ、放送開始後６０分過ぎ頃、即ち、視聴を開始しても最後まで視聴する事が出来ない可能性のある時間帯から急激に接続開始をする視聴者は減少している。
【００１１】
以上説明してきた実際のストリーミング放送に対するアクセス状況について、放送開始後の特定の時間について、サーバへのアクセス状況を概略示した図で説明を行う。図５から図７は、それぞれ、放送開始後、１０数分後、３０分後、６０分弱後の視聴者の接続状況を概略示した図である。
【００１２】
図５では、番組の放送開始後直後であり、特に図４で接続開始をする視聴者の数がピークを迎える時間でもあり、５０１のサーバ１の、特に５０２のシーン１〜１２の部分にアクセスが集中している状況である。また、放送開始後３０分の図６では、相変わらず接続を開始する視聴者が多いにも関わらず、番組の見せ場３０３に差し掛かっており、サーバ１にかかる負荷は引き続き増大している。図７の放送開始後６０分弱後においては、初期に視聴を開始した視聴者が終盤のクライマックスの部分に差し掛かっており、同時に、番組の見せ場１および見せ場２の視聴者も多く、さらに、接続を開始する視聴者も未だ存在する状況である。
【００１３】
この様に、ストリーミング放送の番組に接続する視聴者の数は、番組の構成内容によって、ばらつきがあり、ストリーミング放送を提供するサーバの負荷の想定は、平均視聴者数などでは扱えず、常に最高数の視聴者を前提とする必要があった。また、視聴開始時間をずらして視聴する事が可能なストリーミング放送においては、視聴者の接続数のピークが持続する事もあり、よりサーバに対してアクセス負荷に対する余裕が求められるものであった。
【００１４】
また、もし、サーバに対して、想定した以上の視聴者がアクセスした場合は、接続するポート数の制限から、後から接続しようとする視聴者に対して、接続を拒否するか、あるいは、サーバが負荷に耐えられなくなり、図８の８０３に示す様に、突然ストリーミング放送の配信が停止する事で、接続中の全ての視聴者が突然視聴を中断させられる可能性も存在した。
【００１５】
本発明はこの様な問題を解決することを目的とする。
【００１６】
本発明の他の目的は、ストリーム放送を配信する際、サーバに対する付加を軽減すると共に、中断することなく快適にストリーム放送を視聴可能とする処にある。
【００１７】
【課題を解決するための手段】
前述の如き問題点を解決するため、本発明においては、ネットワークを介してストリーム放送データを受信する装置であって、第一の配信用サーバより配信されたストリーム放送データに連続するストリームデータの格納されている第二の配信用サーバのロケーション情報を検出し、前記第一の配信用サーバからのストリーム放送データの受信中に、前記検出されたロケーション情報に基づき前記第二の配信用サーバからのストリーム放送データの受信を開始すると共にこの第二の配信用サーバからのストリーム放送データを一時記憶要のメモリに記憶し、前記第一の配信用サーバによるストリーム放送データの再生処理が完了した後に、前記メモリに記憶された前記第二の配信用サーバからのストリーム放送データの再生処理を行う構成とした。
【００１８】
【発明の実施の形態】
（第１の実施形態）
図１７は本発明が適用される放送システムの構成を示す図である。
【００１９】
図１７では、ストリーミング放送を受信、再生する機能を持つ受信機１７００と、ストリーミング放送を提供する複数のサーバＳ１〜Ｓ１７がネットワークＮを介して接続されており、受信機１７００はネットワークＮを介して各サーバよりストリーミング放送データを受信、再生する。
【００２０】
図９〜図１１は図１７のシステムに夜動作を説明するための図であり、ここで、図９〜図１１は、図１７における複数のストリーミング放送配信サーバと、それぞれ当該サーバに収容される、分割されたストリーミング放送のストリームデータの対応を示した図である。
【００２１】
また、図９〜図１１はそれぞれ、番組の放送開始後、１０数分後、３０分後、６０分強後のそれぞれのサーバに対する視聴者の接続状況を、従来例における図５〜図７と対応させて示した図である。
【００２２】
図１２は、本形態で扱うストリーミング放送のストリームデータの一部分を示した図であり、１２０１から１２１２はストリームデータを構成する各種のデータからなるパケットデータとそのヘッダ部である。
【００２３】
図１３は、本形態によるストリームデータの処理を示す流れ図であり、１３０１は視聴者がストリーミング放送番組を選択し、このストリームの格納されているネットワーク上のサーバの、ロケーション情報を取得し、実際に当該ストリームデータを取得しようとする際のエントリポイントを示している。
【００２４】
また、ステップ１３０２は目的のサーバにアクセスするステップ、１３０３はストリームデータを受信開始し、一時蓄積の為のバッファリングを行うステップ、１３０４は現在バッファリング中のストリームデータの、前段のストリームデータの再生処理が完了しているか否かを判定するステップであり、前段の再生処理の完了通知が来るか、あるいは最初のストリームデータである場合にはステップ１３０５へと進む。１３０５は、１３０３でバッファリングされたストリームデータを読み込むステップ、１３０６は読み込まれたストリームデータのヘッダ解析を行うステップ、１３０７は解析されたヘッダ情報より、次に再生されるべきストリームデータが格納されているサーバのロケーション情報を取得するステップであり、１３０８は、前記ロケーション情報が存在するか否かを判定するステップ、１３０９は前記次に再生されるべきストリームデータが格納されているサーバに接続し、ストリームの処理を開始するルーチンであり、図１３の１３０１からなる処理が再起的に呼ばれる。
【００２５】
次にステップ１３１０では現在処理中の音声や映像などの個別のデータから成るストリームデータのパケットデータを分離し、ステップ１３１１において分離した夫々のパケットデータのデコード処理を行い、ステップ１３１２において、デコードした映像や音声などの個別データの同期処理を行い、ステップ１３１３において出力を行う。ステップ１３１４においては現在処理中のストリームデータの処理が完了したか否かを判定し、完了していない場合にはステップ１３０５へと進みループする。また、現在処理中のストリームデータの処理が完了した場合にはステップ１３１５において次に待機中の次段のストリーム処理ルーチンに対して、再生完了通知を行い、１３１６において現在処理中のストリームデータに関する処理を終了する。
【００２６】
以下、図９〜図１３を用いて、本形態について詳細に説明する。
【００２７】
ストリーミング放送のストリームデータは、現在様々な種類が存在し、その多くはストリームデータの構成について非公開である場合も多いが、ここでは、一般的なパケットデータから構成されるストリームデータを例にとって説明を行う。
【００２８】
図１２は、１２０１から１２１２のパケットデータからなるストリームデータの例を示しており、各パケットデータにはそれぞれ先頭にパケットデータの属性や同期の為のデータ及びコントロールの為のヘッダ情報が付随している。特に１２０１から１２１２からなるパケットデータは、ストリーミング放送の番組におけるシーン４及びシーン５の映像パケットデータ、音声パケットデータ、字幕パケットデータから構成されており、図９から図１１に示したサーバＳ２に格納されている分割されたストリームデータを示している。
【００２９】
図１２において、実際にはシーン４とシーン５の番組データを構成するには多くのパケットデータが必要ではあるが、ここでは簡単に説明する為に省略している。また、図１２のストリームデータでは、先頭のパケットデータである１２０１のヘッダ情報の一部に、１２１３に示す、次に再生されるべきストリームデータの格納されているサーバのロケーション情報が格納されている。さらに、１２１２に示す最後のパケットデータの最後部には１２１４に示すストリームデータの最後である旨を記述したデータも格納されている。
【００３０】
今、視聴者が、図９から図１１に示す分割されたストリーミング放送の番組について、視聴を開始する為に、先頭のパケットデータが格納されているサーバであるサーバＳ１のロケーション情報を入手し、このストリームデータによる処理が指示されると、図１３のエントリポイント１３０１からの処理が開始される事になる。
【００３１】
ステップ１３０２では前述のサーバロケーション情報を基にサーバに格納されているストリームデータとの接続が行われ、ステップ１３０３でサーバＳ１に格納されていたストリームデータのバッファリングが開始される。次にステップ１３０４では前段のサーバに格納されていたパケットデータの再生処理が完了したか否かが判定され、ここでは前段のデータは存在しない為にステップ１３０５へと進む。
【００３２】
１３０５ではバッファよりストリームデータのパケットデータが読み込まれ、ステップ１３０６において各パケットデータに付随するヘッダ情報の解析が行われる。次にステップ１３０７において、解析されたパケットデータより、次に再生されるべきストリームデータが格納されているサーバのロケーション情報の取得が行われ、ステップ１３０８において前記サーバのロケーション情報の有無が判定される。ここでは現在処理中のパケットデータの先頭で次のサーバであるＳ２についてのロケーション情報が検出される為に、ステップ１３０９において、サーバＳ２についてのロケーション情報を持って、別のスレッドとなる、１３０１からの処理が開始される。
【００３３】
サーバＳ２についてのストリームデータに対する処理も先の説明と同様にステップ１３０２から１３０４へと進み、ここで前段のサーバによるストリーム再生処理が完了しているか否かが判定され、ここではサーバＳ１についてのストリームデータの処理が完了していない為に、ステップ１３１７に進み、当該スレッドからなる処理は、特定の量のパケットデータのバッファリングが完了した時点で一時停止し、先のスレッドによるサーバＳ１によるストリームデータの再生処理の完了通知を待つ事になる（ステップＳ１３１７）。
【００３４】
次に、サーバＳ１によるストリームデータの処理は、ステップ１３１０に移り、図１２の如き構成のパケットデータは音声データ、映像データ、そして字幕データなどに分離され、ステップ１３１１においてそれぞれ専用のデコーダによりデコード処理される。ステップ１３１２では、各々別にデコードされた情報が、夫々のパケットデータのヘッダ情報に記載の同時情報を基に同期処理がなされ、１３１３において映像と音声の情報、あるいは必要によっては字幕情報も併せて出力される。
【００３５】
次に１３１４ではサーバＳ１によるストリームデータの処理が終了であるか否かが判定され、ストリームデータのパケットデータが残っている場合にはステップ１３０５へと進み、逐次パケットデータが処理される事となる。図１２の如き構成のパケットデータにおいて、最後のパケットデータの処理が完了すると、ステップ１３１４において、次段のサーバであるＳ２によるストリーム処理のスレッドに対して再生完了通知が行われ、ステップ１３１６において、サーバＳ１におけるストリーム処理を終了する。
【００３６】
この時サーバＳ２におけるストリーム処理のスレッドは、当該別スレッド上のステップ１３１７からステップ１３０４へのループ状態から復帰し、ステップ１３０５へと進み、以後、先程の、サーバ１のストリームデータの処理と同様の処理を行う事となる。
【００３７】
以上、説明した様に、本形態によれば、ストリーミング放送のストリームデータを分割し、それぞれの先頭のパケットデータヘッダ部に次に接続するべきサーバのロケーション情報を記録し、先のストリームの処理と同時に、直ちに次のストリームデータのバッファリングをしておく事で、視聴者のサーバへの接続を滞りなく次々とリレー状態でサーバを移行する事となり、時間差を持って接続開始する事が可能なストリーミング放送においては、サーバを短時間で移行して行く事で、時間的な負荷分散が計られ、接続を希望する視聴者に対して快適なストリーミング放送の視聴環境を提供出来る。
【００３８】
特に、ストリーミング放送の番組において、視聴を開始する時間差も小さく、しかも数多くの視聴者による接続が予想されるストリームデータ部分については、特別に、ストリームデータを短く分割し、予めサーバ負荷の分散を計画的に行う事も可能となる。
【００３９】
また、個々のサーバにおいても、１台の高性能なサーバで数多くの視聴者の接続を賄うものに比べると、古いか、あるいは能力の低いサーバで対応する事が可能であり、性能が上がると級数的にコストが上がるサーバ装置の状況においては、番組コンテンツを提供する提供者にとってもメリットがある。
【００４０】
さらには、サーバに何らかのトラブルが発生した際にも、１台のサーバで多くの視聴者に対応している状況においては、接続している視聴者全員が被害を被るのに対して、サーバを分割する事により、被害を一部の視聴者のみに留める事が可能である。
【００４１】
もちろん、サーバのトラブルに対応する為には、バックアップサーバを配置するのが常であるが、この場合も、１台のサーバで対応している場合には、高価で高機能なバックアップ用サーバを用意する必要があるが、サーバを分散する事により、ある程度の数のバックアップサーバを用意しておき、トラブルの発生したサーバのみバックアップさせる事が可能であり、バックアップサーバの数を最小限にする事が可能である。
【００４２】
（第２の実施形態）
前述の実施形態においては、ストリーミング放送のストリームデータを分割し複数のサーバで配信させる事で配信するサーバの負荷を時間的に分散させたが、本形態においては、図１４に示す様に、最初にストリーミング放送のロケーション情報を入手して最初の配信用サーバＳ１に接続した後に、接続可能な配信用サーバを複数用意する事で、時間的な負荷分散に加えて、場所的な分散を可能とした。
【００４３】
本形態においては、図１５に示す様に、最初のパケットデータのヘッダ部に次に接続するべき配信用サーバとして、Ｓ２ａ及びＳ２ｂの、二つのサーバのロケーション情報１５１３及び１５１４を記録し、始めの配信用サーバＳ１に接続した際に、入手した次段の二つのサーバのロケーション情報について、受信機１７００内で乱数などを用いてランダムに選択を行い、次段の接続するべきサーバを決定する構成とする。
【００４４】
また、この時、サーバＳ２ｂが選択され、サーバＳ１のストリームデータの再生処理が完了した後に、サーバＳ２ｂに格納されたストリームデータの処理を開始すると、当該ストリームデータの最初のパケットデータのヘッダ部には、Ｓ３ａ、Ｓ３ｂ、Ｓ３ｃの三つのサーバのロケーション情報が記録されている。この時も、先程と同様に、受信機１７００内で乱数などを用いてランダムに選択を行い、次段の複数のサーバの中から一つを常に選択していく構成とする。
【００４５】
図１６は、本形態においてストリーミング放送の視聴を行った際の、接続したサーバの遷移を図示した例である。ここではある視聴者が複数存在する配信サーバの選択をランダムに行った結果、選択された配信サーバを太枠で示しているが、より多くの視聴者が配信サーバをランダムに選択する事で、複数ある配信サーバに対して均等な負荷の配分が期待出来る。
【００４６】
この様に、本形態によれば、ストリーミング放送の番組について、多くの視聴者のアクセスが予想されるストリームの位置や時間帯に応じて、ストリームの分割により、単位時間辺りのサーバ負荷を減少させるだけでは無く、さらに、当該時間辺りのサーバの数を複数持つ事で、さらにサーバ負荷を分散させ、視聴者に、より快適なストリーミング放送の視聴環境を提供する事が可能となる。
【００４７】
（第３の実施形態）
第２の実施形態においては、複数のサーバを選択する際に、視聴者側の受信機１７００において、夫々、ランダムに選択する手段を用いていた。
【００４８】
本形態においては、次段の配信用サーバのロケーション情報として複数の情報が得られた場合には、当該複数の配信用サーバに対して、同時に接続を開始し、バッファリングを行う。そして、最も早くバッファリングが完了した配信用サーバを次段の接続先として決定する構成とする事で、乱数を用いた統計的な負荷分散に頼る事無く、確実に負荷の少ない配信用サーバを選択する事が可能となり、視聴者により快適なストリーミング放送の視聴環境を提供出来るものである。
【００４９】
さらに、本形態によれば、配信用サーバに特別な問題が存在しない場合でも、それぞれの配信サーバが接続されている、異なるネットワーク環境上に何らかのトラブルが発生した場合には、実際のバッファリング作業を通してこれを検知する事が可能であり、より有効な配信サーバの選択が可能となる。
【００５０】
【発明の効果】
以上説明した様に、本発明によれば、サーバの接続ポートの制限や、サーバ負荷の増大により接続を拒否される事が少なく、また、接続中においても、サーバの負荷の影響を受けにくく、安定した接続が行え、その結果、視聴者に対して、快適なストリーミング放送の視聴環境を提供出来る。
【図面の簡単な説明】
【図１】ストリーム放送データの様子を示す図である。
【図２】ストリーム放送の受信状態を示す図である。
【図３】ストリーム放送の配信状態を示す図である。
【図４】ストリーム放送の配信状態を示す図である。
【図５】ストリーム放送の配信状態を示す図である。
【図６】ストリーム放送の配信状態を示す図である。
【図７】ストリーム放送の配信状態を示す図である。
【図８】ストリーム放送の配信状態を示す図である。
【図９】複数のサーバによるストリーム放送の配信状態を示す図である。
【図１０】複数のサーバによるストリーム放送の配信状態を示す図である。
【図１１】複数のサーバによるストリーム放送の配信状態を示す図である。
【図１２】複数のサーバによるストリーム放送の配信状態を示す図である。
【図１３】ストリーム放送の受信動作を示すフローチャートである。
【図１４】複数のサーバによるストリーム放送の配信状態を示す図である。
【図１５】ストリーム放送データの様子を示す図である
【図１６】複数のサーバによるストリーム放送の配信状態を示す図である。
【図１７】本発明が適用される放送システムの構成を示す図である。
【図１】
2004134868.tif 000003
【図２】
2004134868.tif 000004
【図３】
2004134868.tif 000005
【図４】
2004134868.tif 000006
【図５】
2004134868.tif 000007
【図６】
2004134868.tif 000008
【図７】
2004134868.tif 000009
【図８】
2004134868.tif 000010
【図９】
2004134868.tif 000011
【図１０】
2004134868.tif 000012
【図１１】
2004134868.tif 000013
【図１２】
2004134868.tif 000014
【図１３】
2004134868.tif 000015
【図１４】
2004134868.tif 000016
【図１５】
2004134868.tif 000017
【図１６】
2004134868.tif 000018
【図１７】
2004134868.tif 000019