(57)【要約】【課題】複数のクライアント端末に複数チャンネルの映像等のコンテンツを配信する際に、配信要求されたチャンネル数が増減した場合であっても、使用可能な受信帯域の上限まで活用して要求されたチャンネルの配信データを取得し、クライアント端末に配信する。【解決手段】複数のクライアント端末９に同時に複数のチャンネルの映像を配信する配信サーバー３は、複数のエンコードサーバー２との間の受信帯域の上限を、クライアント端末９から要求されたチャンネル数で除算して１チャンネル当たりに使用可能な受信帯域を算出し、この算出した受信帯域をエンコードレートとして配信データを生成するよう、配信が要求されているチャンネルの配信データを生成するエンコードサーバー２に指示する。配信サーバー３は、エンコードレートを指示したエンコードサーバー２から配信データを受信し、クライアント端末９へ要求されたチャンネルの配信データを配信する。【選択図】図１
2012004970.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアント端末に同時に複数のチャンネルのコンテンツを配信するコンテンツ配信装置において、
エンコード処理を行ない、それぞれ異なるチャンネルの配信データを生成する複数のエンコード処理部と、
前記複数のエンコード処理部から前記チャンネルの配信データを受信する配信データ受信部と、
ネットワークを介して接続されるクライアント端末から配信要求信号及び配信終了要求信号を受信する配信要求受信部と、
前記配信要求信号を受信してから前記配信終了要求信号を受信するまで前記配信要求信号の送信元のクライアント端末へ、前記配信要求信号により特定されるチャンネルの前記配信データを配信する伝送部と、
前記配信要求受信部において受信した前記配信要求信号及び前記配信終了要求信号に基づいて配信中のチャンネル数をカウントするチャンネル数カウント部と、
前記チャンネル数カウント部によってカウントされた前記チャンネル数に基づいて、前記複数のエンコード処理部が共有する帯域における前記配信データ受信部が受信可能な上限の受信帯域を超えないように、前記複数のエンコード処理部において生成する前記配信データのエンコードレートを算出するレート計算部と、
を備えることを特徴とするコンテンツ配信装置。
【請求項２】
複数のクライアント端末に同時に複数のチャンネルのコンテンツを配信する配信サーバー装置において、
複数のエンコード装置それぞれから異なるチャンネルの配信データを受信する配信データ受信部と、
ネットワークを介して接続されるクライアント端末から配信要求信号及び配信終了要求信号を受信する配信要求受信部と、
前記配信要求信号を受信してから前記配信終了要求信号を受信するまで前記配信要求信号の送信元のクライアント端末へ、前記配信要求信号により特定されるチャンネルの前記配信データを配信する伝送部と、
前記配信要求受信部において受信した前記配信要求信号及び前記配信終了要求信号に基づいて配信中のチャンネル数をカウントするチャンネル数カウント部と、
前記チャンネル数カウント部によってカウントされた前記チャンネル数に基づいて、前記複数のエンコード装置が共有する帯域における前記配信データ受信部が受信可能な上限の受信帯域を超えないように、前記複数のエンコード装置において生成する前記配信データのエンコードレートを算出するレート計算部と、
前記レート計算部が算出したエンコードレートを配信が要求されている前記チャンネルの配信データを生成する前記エンコード装置へ出力するレート指示送信部と、
を備えることを特徴とする配信サーバー装置。
【請求項３】
コンピュータを、
請求項２の配信サーバー装置として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツ配信装置、配信サーバー装置及びプログラムに関する。
【背景技術】
【０００２】
近年ＩＰ（Internet Protocol）ネットワークは広く普及しており、このＩＰネットワークを用いて、リアルタイムに映像を配信することが一般化している。映像データは容量が大きいため、ＭＰＥＧ（Moving Picture Experts Group）方式に代表される圧縮技術により映像データを圧縮して伝送する。圧縮率を高くしてエンコードレートを小さくすれば、伝送データ量は減るものの映像の高解像度成分が失われ、映像品質は劣化する。
【０００３】
一方、ＩＰネットワークは複数のコンピュータ装置が帯域を共有して伝送するベストエフォートネットワークであり、多くのコンピュータ装置が同時に伝送しているときにはネットワークが混雑し、各コンピュータ装置において所望のスループットを得られない場合もある。
【０００４】
例えば、特許文献１には、各チャンネルに対応した複数のユーザーがストリーミングサーバーに映像をリアルタイムでアップロードし、複数のクライアントは、ストリーミングサーバーに接続して所望のチャンネルを視聴する技術が記載されており、各ユーザー（チャンネル）は、アップロードを行なう前に、予約管理サーバーに対して、ストリーミングサーバーの持つ能力を超えない範囲でアップロードのための帯域を予約する。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−７７８６８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
１つのサーバーから複数のチャンネルの映像を複数のクライアントにリアルタイムに配信する場合、当該サーバーは、クライアントに要求された各チャンネルについて圧縮された配信用の映像を取得する必要がある。そこで、予めサーバー側の持つ受信処理能力や帯域と、想定されるチャンネル数を勘案して、安定して配信用の映像を受信可能なエンコードレートを事前に決定しておき、このエンコードレートによる配信用の映像を受信し、各チャンネルの要求元のクライアント端末へ配信することが一般的である。
【０００７】
しかしながら、配信するコンテンツの内容などから要求されるチャンネル数をあらかじめ正確に予測することは極めて困難であり、想定を超えて要求されるチャンネル数が増大するケースもある。このような場合、サーバー側の持つ帯域の上限やサーバーの処理能力を超えて配信用の映像を受信することはできないため、想定以上のチャンネルについてはクライアントからの配信要求を受け付けられないという問題があった。
【０００８】
上述した特許文献１の技術によれば、映像をアップロードするユーザーは、予めストリーミングサーバーへのアップロードのための帯域を予約しており、すでにストリーミングサーバーの上限の受信帯域まで使用されている場合は、この上限を超えての帯域予約を受けることはできない。従って、特許文献１の技術は、同時に映像をアップロードできるチャンネルの数を柔軟に増加させることはできず、上述した問題を解決するものではない。
【０００９】
本発明は、このような事情を考慮してなされたもので、その目的は、複数のクライアント端末に複数チャンネルの映像等のコンテンツを配信する際に、配信要求されたチャンネル数が増減した場合であっても、使用可能な受信帯域の上限まで活用して要求されたチャンネルの配信データを取得し、クライアント端末に配信することができるコンテンツ配信装置、配信サーバー装置及びプログラムを提供することにある。
【課題を解決するための手段】
【００１０】
［１］  本発明の一態様は、複数のクライアント端末に同時に複数のチャンネルのコンテンツを配信するコンテンツ配信装置において、エンコード処理を行ない、それぞれ異なるチャンネルの配信データを生成する複数のエンコード処理部と、前記複数のエンコード処理部から前記チャンネルの配信データを受信する配信データ受信部と、ネットワークを介して接続されるクライアント端末から配信要求信号及び配信終了要求信号を受信する配信要求受信部と、前記配信要求信号を受信してから前記配信終了要求信号を受信するまで前記配信要求信号の送信元のクライアント端末へ、前記配信要求信号により特定されるチャンネルの前記配信データを配信する伝送部と、前記配信要求受信部において受信した前記配信要求信号及び前記配信終了要求信号に基づいて配信中のチャンネル数をカウントするチャンネル数カウント部と、前記チャンネル数カウント部によってカウントされた前記チャンネル数に基づいて、前記複数のエンコード処理部が共有する帯域における前記配信データ受信部が受信可能な上限の受信帯域を超えないように、前記複数のエンコード処理部において生成する前記配信データのエンコードレートを算出するレート計算部と、を備えることを特徴とするコンテンツ配信装置である。
この構成によれば、複数のクライアント端末に同時に複数のチャンネルのコンテンツを配信するコンテンツ配信装置において、それぞれが異なるチャンネルに対応した複数のエンコード手段から各チャンネルの配信データを受信するための受信帯域の上限を超えないよう、クライアント端末から配信が要求されているチャンネル数に応じて１チャンネル当たりに使用可能な受信帯域を算出し、この算出結果をエンコードレートとして、配信が要求されているチャンネルの配信データを生成するエンコード手段へ指示する。各チャンネルの配信データを生成するエンコード手段は、指示されたエンコードレートにより配信データを生成する。
これにより、コンテンツ配信装置は、ネットワーク上で複数のクライアント端末に映像等のコンテンツを配信する際に、クライアント端末から要求されるチャンネルが増減した場合も、要求された各チャンネルに対応したエンコード手段から出力される配信データを、受信帯域の上限まで活用して受信することができる。従って、コンテンツ配信装置は、予めチャンネル数を予測しなくとも、クライアント端末から要求された全てのチャンネルのコンテンツを配信することが可能となる。
【００１１】
［２］  本発明の一態様は、複数のクライアント端末に同時に複数のチャンネルのコンテンツを配信する配信サーバー装置において、複数のエンコード装置それぞれから異なるチャンネルの配信データを受信する配信データ受信部と、ネットワークを介して接続されるクライアント端末から配信要求信号及び配信終了要求信号を受信する配信要求受信部と、前記配信要求信号を受信してから前記配信終了要求信号を受信するまで前記配信要求信号の送信元のクライアント端末へ、前記配信要求信号により特定されるチャンネルの前記配信データを配信する伝送部と、前記配信要求受信部において受信した前記配信要求信号及び前記配信終了要求信号に基づいて配信中のチャンネル数をカウントするチャンネル数カウント部と、前記チャンネル数カウント部によってカウントされた前記チャンネル数に基づいて、前記複数のエンコード装置が共有する帯域における前記配信データ受信部が受信可能な上限の受信帯域を超えないように、前記複数のエンコード装置において生成する前記配信データのエンコードレートを算出するレート計算部と、前記レート計算部が算出したエンコードレートを配信が要求されている前記チャンネルの配信データを生成する前記エンコード装置へ出力するレート指示送信部と、を備えることを特徴とする配信サーバー装置である。
この構成によれば、複数のクライアント端末に同時に複数のチャンネルのコンテンツを配信する配信サーバー装置は、それぞれが異なるチャンネルに対応した複数のエンコード装置との間で使用する受信帯域の上限を超えないよう、クライアント端末から配信が要求されているチャンネル数に応じて１チャンネル当たりに使用可能な受信帯域を算出し、この算出結果をエンコードレートとして、配信が要求されているチャンネルの配信データを生成するエンコード装置へ指示する。
これにより、配信サーバー装置は、ネットワーク上で複数のクライアント端末に映像等のコンテンツを配信する際に、クライアント端末から要求されるチャンネルが増減した場合も、要求された各チャンネルに対応したエンコード装置から出力される配信データを、受信帯域の上限まで活用して受信することができる。従って、配信サーバーは、予めチャンネル数を予測しなくとも、クライアント端末から要求された全てのチャンネルのコンテンツをクライアント端末に配信することが可能となる。
【００１２】
［３］  本発明の一態様は、コンピュータを、上述した配信サーバー装置として機能させることを特徴とするプログラムである。
【発明の効果】
【００１３】
上記の構成によれば、配信サーバーは、各エンコードサーバーによりエンコードされた複数のチャンネルのコンテンツをネットワーク上で複数のクライアント端末に配信する際に、クライアント端末から要求された全てのチャンネルの配信データを受信帯域の上限まで活用して受信できるよう、要求されているチャンネル数に応じて配信データのエンコードレートを決定する。よって、配信サーバーは、予めチャンネル数を予測する必要がなく、クライアント端末から要求されるチャンネルが増減した場合であっても、受信帯域の上限まで活用して、要求された全てのチャンネルについての配信データを受信し、配信することが可能となる。また、要求されているチャンネルが少ないときには高品質のコンテンツを配信することができ、また、コンテンツの品質を落とすことにより要求されているチャンネルが多いときにもコンテンツの配信を可能とする。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態によるコンテンツ配信装置の構成図である。
【図２】同実施形態によるエンコードサーバーの構成を示すブロック図である。
【図３】同実施形態による配信サーバーの構成を示すブロック図である。
【図４】同実施形態によるコンテンツ配信装置の配信処理フローを示す図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。
図１は、本発明の一実施形態によるコンテンツ配信装置１の構成を示すブロック図である。コンテンツ配信装置１は、複数のクライアント端末９に対して、同時に複数のコンテンツを配信する。コンテンツは映像や音声などであり、異なる内容のコンテンツをそれぞれチャンネルと呼ぶ。同図に示す配信システム１は、チャンネルの映像や音声を符号化した映像音声信号を配信用に圧縮して配信データを生成する複数のエンコードサーバー２（エンコード装置）と、エンコードサーバー２が生成した配信データを複数のクライアント端末９に配信する配信サーバー３（配信サーバー装置）とを備える。エンコードサーバー２と配信サーバー３はネットワークＮを介して接続され、配信サーバー３とクライアント端末９はネットワークＭを介して接続される。ネットワークＮ、ネットワークＭは、ＩＰ（Internet Protocol）網などの通信ネットワークである。各エンコードサーバー２は映像音声信号から配信データを生成するエンコード処理を行なうエンコード処理部を有しており、以下、ｎ台のエンコードサーバー２それぞれが、異なるチャンネル１〜ｎの映像音声信号の配信データを生成するものとして説明する。つまり、コンテンツ配信装置１は、エンコード処理を行ない、それぞれ異なるチャンネルの配信データを生成する複数のエンコード処理部を備える。
【００１６】
配信サーバー３は、複数のクライアント端末９に配信データを配信するが、各クライアント端末９がそれぞれ視聴したいチャンネルは異なる。そこで、配信サーバー３は、クライアント端末９から要求されたチャンネルの配信データを、該チャンネルの配信データを生成するエンコードサーバー２から取得し、配信する。配信サーバー３は、クライアント端末９に対してユニキャスト通信を用いて個別に配信データを配信しても良く、同じチャンネルの配信を希望する複数のクライアント端末９に対して、例えばマルチキャスト通信を利用して一斉に同じ配信データを配信しても良い。
【００１７】
配信サーバー３が複数のエンコードサーバー２から受信を行なう帯域には上限がある。この配信サーバー３の受信帯域の上限は、配信サーバー３が実装するインタフェース等のハードウェアの性能に依存する場合もあれば、エンコードサーバー２と配信サーバー３を接続するネットワークＮとの間のネットワークリンクの上限である場合もある。クライアント端末９から要求されるチャンネル数が増加し、各エンコードサーバー２から配信サーバー３に送らなければいけない配信データ量の合計が配信サーバー３の受信帯域を越えた場合、それ以上のチャンネルを配信サーバー３が受信することはできない。
【００１８】
例えば、配信サーバー３に実装されているネットワークインターフェースが、１０Ｂａｓｅ−Ｔ  イーサーネット（登録商標）であれば、１０［Ｍｂｐｓ（メガビット毎秒）］以上の配信データは受信できない。このとき、従来のコンテンツ配信装置の場合、エンコードサーバーにおいて配信データのエンコードレートを１［Ｍｂｐｓ］の固定レートに圧縮していれば、配信サーバー３は、プロトコルオーバヘッドや伝送量の時間的偏り等による伝送効率低下を無視できるとすると、１０チャンネル、すなわち、１０台のエンコードサーバーまでの配信データを受信ことができる。しかし、それ以上の数のチャンネルの配信要求をクライアント端末９から受けても、１０台の上限を超えたエンコードサーバーから配信データを受信することはできないため、配信要求された全てのチャンネルをクライアント端末９に配信することはできない。本実施形態のコンテンツ配信装置１は、配信サーバー３の受信帯域の上限と、クライアント端末９から要求されたチャンネル数とに応じてエンコードレートを変えることによって、１チャンネルあたりの配信データ量を調節し、チャンネル数の増加に対応することができる。
【００１９】
このように、本実施形態では、受信帯域の上限とチャンネル数に応じて配信データの圧縮率を変えることにより、配信サーバー３が受信するデータ量を調節し、クライアント端末９から要求されるチャンネル数が増加しても、全てのクライアント端末９に対して要求されたチャンネルの配信を継続することができる。
【００２０】
図２は、図１に示すエンコードサーバー２の内部構成を示すブロック図である。同図に示すように、エンコードサーバー２は、レート指示受信部２１、エンコード処理部２２、及び、エンコードデータ送信部２３を備えて構成される。
レート指示受信部２１は、配信サーバー３からエンコードレートを示すレート指示値を受信する。エンコード処理部２２は、外部装置等から入力された映像音声信号を記憶する記憶部２０を備えており、レート指示受信部２１が受信したレート指示値に従って映像音声信号を圧縮するエンコード処理を行い、エンコードデータを生成する。エンコードデータ送信部２３は、エンコード処理部２２が生成したエンコードデータを配信データとして配信サーバー３に出力する。
【００２１】
図３は、図１に示す配信サーバー３の内部構成を示すブロック図である。同図に示すように、配信サーバー３は、配信要求受信部３１、チャンネル数カウント部３２、レート計算部３３、レート指示送信部３４、配信データ受信部３５、及び、伝送部３６を備えて構成される。
配信要求受信部３１は、クライアント端末９から所望チャンネルの配信を要求する配信要求信号及び配信の終了を要求する配信終了要求信号を受信する。チャンネル数カウント部３２は、配信要求受信部３１が受信した配信要求信号及び配信終了要求信号に基づいて、配信中のチャンネル数をカウントする。レート計算部３３は、チャンネル数カウント部３２がカウントしたチャンネル数等に基づいて、エンコードレートを算出する。レート指示送信部３４は、レート計算部３３によって算出されたエンコードレートをレート指示値としてエンコードサーバー２に出力する。配信データ受信部３５は、複数のエンコードサーバー２から配信データを受信し、伝送部３６に出力する。伝送部３６は、配信要求信号を受信してから配信終了要求信号を受信するまでの間、配信要求送信元のクライアント端末９へ、配信データ受信部３５から入力された配信データを配信する。配信される配信データは、配信要求信号により特定されたチャンネルの配信データである。また、配信データは、ユニキャストで各クライアント端末９個別に配信してもよく、同一チャンネルを要求しているクライアント端末９に対してマルチキャストで一斉に配信しても良い。
【００２２】
次に、本実施形態のコンテンツ配信装置１の処理について説明する。
【００２３】
図４は、コンテンツ配信装置１の処理フローを示す。
各エンコードサーバー２のエンコード処理部２２は、外部装置等から映像音声信号の入力が開始されると、この入力された映像音声信号を記憶部２０に書き込んでいく（ステップＳ１０５）。
配信サーバー３の配信要求受信部３１が、チャンネルｘ（ｘは１〜ｎのいずれか）を示すチャンネル情報が設定された配信要求信号をクライアント端末９から受信すると（ステップＳ１１０：配信要求）、チャンネル数カウント部３２は、配信が要求されたチャンネルｘが現在他のクライアント端末９へ配信中のチャンネルに含まれているか否かにより、チャンネル数に変化があるかを判断する（ステップＳ１１５）。配信が要求されたチャンネルｘが現在配信中のチャンネルに含まれておらず、チャンネル数に変化があると判断した場合（ステップＳ１１５：ＹＥＳ）、チャンネル数カウント部３２は、チャンネル数に１を加算する（ステップＳ１２０）。チャンネル数カウント部３２は、更新されたチャンネル数をレート計算部３３に出力するとともに、現在配信が要求されているチャンネルをレート指示送信部３４に出力する。
【００２４】
レート計算部３３は、レート指示送信部３４から入力されたチャンネル数に基づいてエンコードレートを算出する（ステップＳ１２５）。この算出方法の詳細については後述する。レート指示送信部３４は、レート計算部３３が算出したエンコードレートを示すレート指示値を、チャンネル数カウント部３２から入力されたチャンネルの配信データを生成するエンコードサーバー２に出力する（ステップＳ１３０）。
【００２５】
配信が要求されているチャンネルの配信データを生成するエンコードサーバー２において、レート指示受信部２１は、配信サーバー３からレート指示値を受信し、エンコード処理部２２に出力する（ステップＳ１３５）。エンコード処理部２２は、記憶部２０から映像音声信号を読み出すと、この読み出した映像音声信号を配信用に圧縮し、受信したレート指示値により指示されたエンコードレートの配信データを生成する（ステップＳ１４０）。エンコードデータ送信部２３は、エンコード処理部２２が生成した配信データを配信サーバー３に出力する（ステップＳ１４５）。
【００２６】
配信サーバー３の配信データ受信部３５は、配信要求されたチャンネルのエンコードサーバー２から配信データを受信し、伝送部３６に出力する（ステップＳ１５０）。伝送部３６は、配信要求信号送信元の各クライアント端末９に、該クライアント端末９が配信を要求したチャンネルの配信データを配信する（ステップＳ１５５）。つまり、ステップＳ１１０において受信した配信要求信号の送信元のクライアント端末９、及び、この配信要求信号を受信したときにすでに配信中であったクライアント端末９のそれぞれに対して、当該クライアント端末９が配信を要求したチャンネルの配信データを配信する。そして、ステップＳ１１０からの処理を繰り返す。
【００２７】
なお、ステップＳ１１５において、配信が要求されたチャンネルｘが現在他のクライアント端末９へ配信中のチャンネルに含まれており、チャンネル数に変化がないと判断した場合（ステップＳ１１５：ＮＯ）、伝送部３６は、エンコードレートを変更することなく、ステップＳ１１０において受信した配信要求信号の送信元のクライアント端末９に要求されたチャンネルの配信データの配信を開始するとともに、この配信要求信号を受信したときにすでに配信中であったクライアント端末９に対して、各クライアント端末９が配信を要求したチャンネルの配信データの配信を継続する。
【００２８】
一方、ステップＳ１１０において、配信サーバー３の配信要求受信部３１がクライアント端末９から配信終了要求信号を受信すると（ステップＳ１１０：配信終了要求）、伝送部３６は、配信終了要求信号の送信元のクライアント端末９への配信データの配信を終了する（ステップＳ１６０）。チャンネル数カウント部３２は、配信終了要求信号送信元のクライアント端末９へ送信していたチャンネルｙ（ｙは１〜ｎのいずれか）が他のクライアント端末９に配信中であるか否かにより、チャンネル数に変化があるかを判断する（ステップＳ１１５）。チャンネルｙを配信している他のクライアント端末９がなく、チャンネル数に変化があると判断した場合（ステップＳ１１５：ＹＥＳ）、チャンネル数カウント部３２は、チャンネル数から１を減算する（ステップＳ１２０）。チャンネル数カウント部３２は、更新されたチャンネル数をレート計算部３３に出力するとともに、現在配信が要求されているチャンネルをレート指示送信部３４に出力する。以降のステップＳ１２５からの処理は、上述した配信要求信号受信時の処理と同様である。ただし、レート指示送信部３４は、ステップＳ１３０において、チャンネルｙの配信データを生成しているエンコードサーバー２に対して、配信データの出力停止を指示する。
【００２９】
なお、ステップＳ１１５において、チャンネルｙが他のクライアント端末９へ配信中のチャンネルであり、チャンネル数に変化がないと判断した場合（ステップＳ１１５：ＮＯ）、エンコードレートを変更することなく、ステップＳ１１０において受信した配信終了要求信号の送信元のクライアント端末９を除き、この配信終了要求信号を受信したときにすでに配信中であったクライアント端末９に対して、当該クライアント端末９が配信を要求したチャンネルの配信データの配信を継続する。
【００３０】
続いて、ステップＳ１２５におけるエンコードレートの算出方法について詳細に説明する。レート計算部３３は、配信データ受信部３５が受信可能な上限の受信帯域を超えないように、各エンコードサーバー２のエンコード処理部２２において生成する配信データのエンコードレートを算出する。例えば以下の式（１）により、エンコードレートを算出する。
【００３１】
（エンコードレート）＝（受信帯域の上限値）／（チャンネル数）    …（１）
【００３２】
このように算出することで、想定を超えたチャンネル数について配信要求があった場合でも、配信サーバー３は、チャンネル数に応じたエンコードレートにより配信データを受信し、全てのクライアント端末９からのチャンネル配信要求を継続して受け付けることができるようになる。
【００３３】
なお、配信帯域の上限は、物理的なインタフェース等のハードウェアの性能により定まる値であってもよく、物理的なインタフェース等のハードウェアの性能により定まる配信帯域内で配信者が意図的に設定した値であってもよい。この配信帯域の上限は、予め配信サーバー３に記憶させておく。
【００３４】
上記のようにエンコードレートを算出することにより、例えば、配信帯域の上限が１０［Ｍｂｐｓ］であり、１０チャンネルの配信が要求されている場合、１［Ｍｂｐｓ］のエンコードレートで圧縮された配信データが１０台のエンコードサーバー２から配信サーバー３へ出力される。ここで、急激にチャンネル数が増加し、２０チャンネルの配信が要求された場合でも、０．５［Ｍｂｐｓ］のエンコードレートで圧縮された配信データを各クライアント端末９に配信し、全てのクライアント端末９への配信を継続することができる。このように、想定を超えた数のチャンネルについて配信が要求された場合でも、チャンネル数に応じたエンコードレートで配信データを受信し、クライアントからの更なるチャンネルの配信要求を継続して受け付けることができるようになる。なお、エンコードレートに算出にあたっては、エンコードレートに上限を設け、チャンネル数が少ない場合でも必要以上にエンコードレートが高くならないようにしてもよい。つまり、（レート計算部３３が算出したエンコードレート）＞（エンコードレートの上限値）である場合、レート指示送信部３４は、レート指示値としてエンコードレートの上限値を設定し、エンコードサーバー２へ出力する。
【００３５】
なお、エンコードレートの算出結果が、映像や音声などが正常に再生できる最低のエンコードレートを下回った場合、クライアント端末９からの新たなチャンネルについての配信要求を拒否する。
なお、上記においては、受信帯域の上限を用いてエンコードレートを決定しているが、プロトコルオーバヘッドや伝送量の時間的偏り等による伝送効率の低下などを勘案し、現在クライアント端末９から要求されているチャンネルのエンコードサーバー２から送信される配信データの受信帯域の合計が、受信帯域の上限を超えないようにエンコードレートを決定することができる。
【００３６】
以上説明した本発明の実施形態によれば、配信サーバーは、各エンコードサーバーによりエンコードされた複数のチャンネルのコンテンツをネットワーク上で複数のクライアント端末に配信する際に、予めチャンネル数を予測する必要がなく、クライアント端末から要求されるチャンネルが増減した場合も、要求された各チャンネルの配信データを受信帯域の上限まで活用して受信し、クライアント端末に配信することが可能となる。またこのとき、上限の受信帯域内において、できる限りよい品質の配信データを配信することが可能となる。よって、クライアントから要求されているチャンネルが少ないときには高品質のコンテンツを配信することができ、また、コンテンツの品質を落とすことにより要求されているチャンネルが多いときにもコンテンツの配信を可能とする。
【００３７】
なお、上述のエンコードサーバー２、配信サーバー３は、内部にコンピュータシステムを有している。そして、エンコードサーバー２の各部、配信サーバー３の各部の動作の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータシステムが読み出して実行することによって、上記処理が行われる。ここでいうコンピュータシステムとは、ＣＰＵ及び各種メモリやＯＳ、周辺機器等のハードウェアを含むものである。
【００３８】
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバーやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。
【符号の説明】
【００３９】
１…コンテンツ配信装置
２…エンコードサーバー（エンコード装置）
３…配信サーバー（配信サーバー装置）
２０…記憶部
２１…レート指示受信部
２２…エンコード処理部
２３…エンコードデータ送信部
３１…配信要求受信部
３２…チャンネル数カウント部
３３…レート計算部
３４…レート指示送信部
３５…配信データ受信部
３６…伝送部
【図１】
2012004970.tif 000003
【図２】
2012004970.tif 000004
【図３】
2012004970.tif 000005
【図４】
2012004970.tif 000006