JP2016036103A - 映像配信サーバ及び映像配信方法 - Google Patents
映像配信サーバ及び映像配信方法 Download PDFInfo
- Publication number
- JP2016036103A JP2016036103A JP2014158834A JP2014158834A JP2016036103A JP 2016036103 A JP2016036103 A JP 2016036103A JP 2014158834 A JP2014158834 A JP 2014158834A JP 2014158834 A JP2014158834 A JP 2014158834A JP 2016036103 A JP2016036103 A JP 2016036103A
- Authority
- JP
- Japan
- Prior art keywords
- distribution
- file
- request
- video
- client terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Abstract
【課題】映像を連続的に再生できるようにする。【解決手段】 コンピュータによる映像配信方法であって、該コンピュータが、要求元からの配信要求に対する処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換えて、前記要求元に対して、映像ファイルを配信する制御を行うことを特徴とする。【選択図】図１
Description
本発明は、映像配信サーバ及び映像配信方法に関する。
従来より、ＨＴＴＰ（HyperText Transfer Protocol）を用いた映像配信技術が知られており、例えば、ＭＰＥＧ−ＤＡＳＨが適用された映像配信システム等が提案されている。なお、ＭＰＥＧとはMoving Picture Experts Groupの略であり、ＤＡＳＨとはDynamic Adaptive Streaming over HTTPの略である。
ＭＰＥＧ−ＤＡＳＨが適用された映像配信システムでは、コンテンツごとに予め複数の品質のファイルが用意されており、クライアント端末より映像の品質が指定された配信要求が送信されると、対応するファイルがクライアント端末に対して送信される。
上記のような映像配信システムでは、例えば、クライアント端末が、配信要求を行ってからファイルを受信するまでの受信時間に応じて、次の配信要求の際に指定する品質を変更し、次の配信要求に対するファイルの受信タイミングを調整する技術等が知られている。
しかしながら、複数のクライアント端末からの配信要求が集中し、映像配信サーバ側での処理等の負荷が高くなった場合、映像配信サーバの処理の遅れによりクライアント端末へのファイル送信が遅延する。この結果、クライアント端末では、連続再生できるタイミングでファイルを受信することができず、連続再生が滞るなどの影響が生じることになる。
一つの側面では、映像を連続的に再生できるようにすることを目的としている。
一態様によれば、要求元からの配信要求に対する処理負荷を算出する算出部と、前記処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換える変更部と、前記差し換えた映像ファイルを、前記要求元に対して配信する配信部とを有することを特徴とする映像配信サーバが提供される。
映像を連続的に再生することができるようになる。
以下、実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
［第１の実施形態］
はじめに、一実施形態に係る映像配信システムについて説明する。図１は、映像配信システムの一例を示す図である。
はじめに、一実施形態に係る映像配信システムについて説明する。図１は、映像配信システムの一例を示す図である。
映像配信システム１００は、第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎと、映像配信サーバ１２０とを有する（なお、ｎは２以上の任意の整数）。第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎと、映像配信サーバ１２０とは、ネットワーク１６０を介して接続されており、両装置間ではネットワーク１６０を介してデータの送受信が行われる。映像配信システム１００は、ＨＴＴＰを用いた映像配信技術の国際標準規格であるＭＰＥＧ−ＤＡＳＨが適用されたシステムである。映像配信サーバ１２０では第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎからの配信要求に応じて映像配信を行う。なお、ＭＰＥＧとはMoving Picture Experts Groupの略であり、ＤＡＳＨとは、Dynamic Adaptive Streaming over HTTPの略である。
第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎは、それぞれ、映像配信サーバ１２０に格納されているコンテンツをダウンロードしながら再生する、いわゆる"ストリーミング"を実行する。ＭＰＥＧ−ＤＡＳＨが適用された映像配信システム１００において、ストリーミングが実行されるコンテンツのデータ（以下、ストリーミングデータと称す）は、複数のセグメントを含む。映像配信サーバ１２０では、それぞれのセグメントごとに画質の異なる複数のファイルを格納している。このため、第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎでは、ストリーミングデータに含まれるそれぞれのセグメントについて、所定の画質のファイルを指定しながら配信要求を行う。
映像配信サーバ１２０は、映像配信プログラム１３０と、ストリーミングデータ用データベース（以下、ＤＢと略す）１４０とを有する。映像配信プログラム１３０が実行されることで、映像配信サーバ１２０では、第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎからの配信要求において指定されたファイルを、配信要求を行ったクライアント端末（要求元）に対して送信する。なお、映像配信サーバ１２０では、配信要求を受信したタイミングでのＣＰＵの処理負荷に応じて、配信要求において指定されたファイルよりも画質の低いファイルを代替ファイルとして要求元に送信する。
ストリーミングデータ用ＤＢ１４０には、複数のストリーミングデータが格納されている。各ストリーミングデータには複数のセグメントが含まれており、複数のセグメントそれぞれには、更に、画質の異なる複数のファイルが含まれている。つまり、ストリーミングデータ用ＤＢ１４０には、セグメントごとに画質の異なる複数のファイルが対応付けられているストリーミングデータが複数格納されている。
ここで、セグメントごとに対応付けられた、画質の異なる複数のファイルについて簡単に説明する。図２は、画質の異なる複数のファイルについて説明するための図であり、図２の例では、所定のストリーミングデータに含まれる所定のセグメントに対応付けられた、画質の異なる複数のファイルを模式的に示している。
図２（ａ）に示すように、１つのセグメントに対応付けられた第１のファイル２００には複数のフレーム画像２０１〜２０７が所定のフレーム周期Ｔで再生されるように格納されている。ここでフレーム画像２０１〜２０７はそれぞれＩａ［Ｍｂｉｔ（メガビット）］のデータであったとすると、第１のファイル２００は、Ｉａ／Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであるということができる。
一方、図２（ｂ）は、同じセグメントに対応付けられた第２のファイル２１０に複数のフレーム画像２１１〜２１７が所定のフレーム周期Ｔで再生されるように格納されていることを示している。ここで、複数のフレーム画像２１１〜２１７は、それぞれ、複数のフレーム画像２０１〜２０７よりも画像サイズが小さく、それぞれがＩｂ［Ｍｂｉｔ（メガビット）］のデータであるとする（Ｉｂ＜Ｉａ）。つまり、第２のファイル２１０は、Ｉｂ／Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであるということができる。
以下、同様に、図２（ｃ）の第３のファイル２２０は、Ｉｃ／Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであり、図２（ｄ）の第４のファイル２３０は、Ｉｄ／Ｔ［Ｍｂｐｓ］のレートで再生されるファイルである（ただし、Ｉａ＞Ｉｂ＞Ｉｃ＞Ｉｄ）。このように、１つのセグメントには、各フレーム画像のビット数（データ量）が異なることで、単位時間あたりに処理されるビット数（データ量）が互いに異なる複数のファイルが対応付けられている（図２の例では、第１乃至第４のファイル２００〜２３０）。
ここで、図２の例によれば"単位時間あたりに処理されるビット数（データ量）"を示すレートの高低は、画質の高低と等価であることから、互いにレートが異なる複数のファイルとは、画質の異なる複数のファイルと言い換えることができる。したがって、以下では、"レート"を変更する、あるいは、"レート"を落とすことを"画質"を変更する、あるいは、"画質"を落とすと表現する。
次に、映像配信サーバ１２０のハードウェア構成について説明する。図３は、映像配信サーバのハードウェア構成を示す図である。図３に示すように、映像配信サーバ１２０は、ＣＰＵ３０１、ＲＯＭ（Read Only Memory）３０２、ＲＡＭ（Random Access Memory）３０３を備える。また、映像配信サーバ１２０は、記憶部３０４、通信部３０５、ユーザインタフェース部３０６を備える。なお、映像配信サーバ１２０の各部は、バス３０７を介して相互に接続されている。
ＣＰＵ３０１は、記憶部３０４に格納された各種プログラムを実行するコンピュータである。
ＲＯＭ３０２は不揮発性メモリである。ＲＯＭ３０２は、記憶部３０４に格納された各種プログラムをＣＰＵ３０１が実行するために必要な各種プログラム、データ等を格納する。具体的には、ＢＩＯＳ（Basic Input/Output System）やＥＦＩ（Extensible Firmware Interface）等のブートプログラムなどを格納する。
ＲＡＭ３０３は、ＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）等の主記憶装置である。ＲＡＭ３０３は、記憶部３０４に格納された各種プログラムがＣＰＵ３０１によって実行される際に展開される、作業領域として機能する。
記憶部３０４は、映像配信サーバ１２０にインストールされた各種プログラムや、プログラムを実行することで生成されるデータ等を格納する。通信部３０５は、ネットワーク１６０を介して第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎと接続され、各端末との間でデータの送受信を行う。ユーザインタフェース部３０６は、映像配信サーバ１２０を操作する操作者の各種操作を受け付ける。
次に、映像配信サーバ１２０のストリーミングデータ用ＤＢ１４０について説明する。図４は、ストリーミングデータ用ＤＢの一例を示す図である。
図４に示すように、ストリーミングデータ用ＤＢ１４０は、ストリーミングデータごとに区分して格納され、各ストリーミングデータには、情報の項目として、"セグメント"と"画質"とが含まれる。"画質"には、更に、情報の項目として、"４Ｍｂｐｓ"、"１Ｍｂｐｓ"、"５００Ｋｂｐｓ"、"２００Ｋｂｐｓ"が含まれる。
"セグメント"には、ストリーミングデータに含まれる複数のセグメントのセグメント名が格納される。図４の例では、ストリーミングデータ１がＮ個のセグメントを含むため、"セグメント０"から"セグメントＮ"が格納される。
"画質"の"４Ｍｂｐｓ"には、セグメント０〜セグメントＮそれぞれに対応するファイルであって、画質が４［Ｍｂｐｓ］のファイルが格納される。例えば、ファイル名＝"Ｓｅｇ４Ｍ＿０．ｔｓ"は、ストリーミングデータ１のセグメント０に対応付けられた４［Ｍｂｐｓ］の画質を有するファイルであることを示している。
"画質"の"１Ｍｂｐｓ"には、セグメント０〜セグメントＮそれぞれに対応するファイルであって、画質が１［Ｍｂｐｓ］のファイルが格納される。例えば、ファイル名＝"Ｓｅｇ１Ｍ＿０．ｔｓ"は、ストリーミングデータ１のセグメント０に対応付けられた１［Ｍｂｐｓ］の画質を有するファイルであることを示している。
以下、同様に、"画質"の"５００Ｋｂｐｓ"、"２００Ｋｂｐｓ"には、セグメント０〜セグメントＮそれぞれに対応するファイルであって、画質が５００［Ｋｂｐｓ］、２００［Ｋｂｐｓ］のファイルが格納される。
次に、映像配信プログラム１３０がＣＰＵ３０１により実行されることで、映像配信サーバ１２０において実現される機能について説明する。図５は、映像配信サーバにおける機能構成を示す図である。
図５に示すように、映像配信サーバ１２０は、配信要求受信部５０１、配信負荷算出部５０２、ＣＰＵ使用率監視部５０３、配信レート算出部５０４、配信ファイル変更部５０５、配信部５０６を有する。
配信要求受信部５０１は、第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎから送信される配信要求を受信する。また、受信した配信要求において指定されたファイルを識別する。
配信負荷算出部５０２は、所定の周期ごとに、受信中の配信要求において指定されたファイルを送信する場合の配信負荷量を算出する。配信負荷量は、受信中の配信要求において指定されたファイルの画質を和算することで算出する。
ＣＰＵ使用率監視部５０３は、所定の周期ごとに、ＣＰＵ３０１の使用率を監視する。配信レート算出部５０４は、ＣＰＵ使用率監視部５０３により監視されたＣＰＵ３０１の現在の使用率において、単位時間あたりに処理可能なビット数（データ量）を算出する。なお、ＣＰＵ３０１が単位時間あたりに処理可能なビット数（データ量）を、以下では、「配信レート」と称す。
配信ファイル変更部５０５は、配信負荷算出部５０２により算出された配信負荷量と、ＣＰＵ使用率監視部５０３により算出された配信レートとを比較する。そして、配信ファイル変更部５０５は、映像配信サーバ１２０が、現在受信中の配信要求において指定されたファイルを遅延なく送信できるか否かを判定する。また、配信ファイル変更部５０５は、現在受信中の配信要求において指定されたファイルを遅延なく送信することができないと判定した場合に、現在受信中の配信要求において指定されたファイルとは異なる他のファイルの有無を確認する。そして、他のファイルが存在する場合には、他のファイルを代替のファイルとして選択する。具体的には、配信ファイル変更部５０５では、現在受信中の配信要求において指定されたファイルにより特定される画質よりも低い画質のファイルの有無を確認し、低い画質のファイルがある場合には、代替のファイルとして選択する。
配信部５０６は、配信要求受信部５０１により識別されたファイル（配信ファイル変更部５０５により他のファイルが選択された場合にあっては、他のファイル）を、ストリーミングデータ用ＤＢ１４０より呼び出し、要求元のクライアント端末に送信する。
次に、映像配信サーバ１２０における映像配信処理の流れについて説明する。図６は、映像配信サーバによる映像配信処理のフローチャートである。図６に示すフローチャートは、映像配信プログラム１３０がＣＰＵ３０１により実行されることで処理が開始される。
ステップＳ６０１において、配信要求受信部５０１は、所定の周期ごとに第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎのいずれかから配信要求を受信したか否かを判定する。ステップＳ６０１において、配信要求を受信していないと判定した場合には、配信要求を受信するまで待機する。
一方、ステップＳ６０１において、配信要求を受信したと判定した場合には、ステップＳ６０２に進む。ステップＳ６０２において、配信要求受信部５０１は、受信した配信要求それぞれの要求内容を識別する。具体的には、ステップＳ６０１において受信した各配信要求において指定されたファイルを識別する。
ステップＳ６０３において、ＣＰＵ使用率監視部５０３は、現在のＣＰＵ３０１の使用率を取得する。また、配信レート算出部５０４は、取得したＣＰＵ使用率のもとでのＣＰＵ３０１の配信レートを算出する。
ステップＳ６０４において、ＣＰＵ使用率監視部５０３は、ステップＳ６０３において取得したＣＰＵ使用率が、所定の閾値を上回っているか否か（第１の条件を満たしているか否か）を判定する。
ステップＳ６０４において、所定の閾値を上回っていない（第１の条件を満たしていない）と判定した場合には、ステップＳ６０９に進む。この場合、配信部５０６では、ステップＳ６０１において受信した各配信要求において指定されたファイルを、それぞれの要求元に送信する。
一方、ステップＳ６０４において、所定の閾値を上回っている（第１の条件を満たしている）と判定した場合には、ステップＳ６０５に進む。ステップＳ６０５において、配信負荷算出部５０２は、ステップＳ６０２において識別した要求内容に基づいて、配信負荷量を算出する。具体的には、各配信要求において指定されたファイルにより特定される各画質の和と配信係数とを乗算することで算出する。なお、配信負荷量は、クライアント端末における連続再生を実現するために、ファイルを遅延なく送信できるか否かを判定する際に用いられる値である。また、配信係数は、判定に用いられる配信負荷量を、実際の配信負荷量よりも高い値に設定するための係数（１以上の値）である。配信係数を乗算して算出した配信負荷量に基づいて、ファイルを遅延なく送信できるか否かを判定することで、クライアント端末における連続再生の実現をより確実なものにすることができる。
ステップＳ６０６において、配信負荷算出部５０２は、ステップＳ６０５において算出した配信負荷量が、ステップＳ６０３において算出した配信レートを上回っているか否か（第２の条件を満たしているか否か）を判定する。ステップＳ６０６において、配信負荷量が配信レート以下であった（第２の条件を満たしていない）と判定された場合には、ステップＳ６０９に進む。この場合も、配信部５０６では、ステップＳ６０１において受信した各配信要求において指定されたファイルを、それぞれの要求元に送信する。
一方、ステップＳ６０６において、配信負荷量のほうが配信レートを上回っている（第２の条件を満たしている）と判定された場合には、ステップＳ６０７に進む。ステップＳ６０７において、配信負荷算出部５０２は、映像配信サーバ１２０の配信負荷が高いと判定し、ステップＳ６０８に進む。
ステップＳ６０８において、配信ファイル変更部５０５は、ステップＳ６０１において受信した各配信要求において指定されたファイルそれぞれについて、画質が１段階低いファイルの有無を確認する。そして、画質が１段階低いファイルが存在する場合には、画質が１段階低いファイルに変更する。その後、ステップＳ６０５に戻る。なお、画質が１段階低いファイルがない場合には、ファイルを変更することなくステップＳ６０５に戻る。
ステップＳ６０５において、配信負荷算出部５０２は、ステップＳ６０８において変更されたファイルにより特定される各画質の和と配信係数とを乗算することで配信負荷量を算出する。更に、ステップＳ６０６において、算出した配信負荷量と配信レートとを比較する。
ステップＳ６０６において再度、配信負荷量のほうが配信レートを上回っていると判定された場合には、ステップＳ６０７において、配信負荷算出部５０２は映像配信サーバ１２０の配信負荷が高いと判定する。そして、ステップＳ６０８において、配信ファイル変更部５０５は、更に画質が１段階低いファイルの有無を確認し、存在する場合には、更に画質が１段階低いファイルに変更する（なお、存在しない場合には、更なるファイルの変更は行われない）。
このように、配信ファイル変更部５０５では、ステップＳ６０６において、配信負荷量が配信レート以下になったと判定されるまで画質を落としていく。一方、ステップＳ６０６において、配信負荷量が配信レート以下になったと判定した場合には、ステップＳ６０９に進む。
ステップＳ６０９において、配信部５０６は、配信負荷量が配信レート以下になったと判定された際の各画質のファイルを、それぞれの要求元に送信する。
ステップＳ６１０において、配信要求受信部５０１は、映像配信プログラム１３０に対する実行停止指示が入力されたか否かを判定し、入力されていないと判定した場合には、ステップＳ６０１に戻る。一方、入力されたと判定した場合には、映像配信処理を終了する。
次に、映像配信処理の具体例について説明する。図７は、映像配信処理の具体例を示す図である。図７（ａ）は、ＣＰＵ使用率監視部５０３により取得されるＣＰＵ使用率の時間変化を示す図である。ここでは、時間ｔにおける映像配信処理について説明する。
図７（ａ）の例では、ＣＰＵ使用率監視部５０３により取得される、時間ｔにおけるＣＰＵ使用率は８０％であり、所定の閾値を上回っていることから、ＣＰＵ使用率監視部５０３では、第１の条件を満たすと判定する。
また、配信レート算出部５０４では、ＣＰＵ使用率＝８０％における配信レートを算出する（図７（ａ）の例では、４８［Ｍｂｐｓ］であったとする）。また、配信要求受信部５０１では、時間ｔにおいて受信した配信要求の要求内容について識別する。
図７（ｂ）に示すように、時間ｔにおいて、配信要求受信部５０１では、第１のクライアント端末１１０−１〜第８のクライアント端末１１０−８からの配信要求を受信している。このうち、第１のクライアント端末１１０−１〜第４のクライアント端末１１０−４からは、時間ｔ以前に、他のセグメントのファイルについての配信要求を受信している。
具体的には、第１のクライアント端末１１０−１からは、ストリーミングデータ１について、セグメント０からセグメント３に対応するファイルについて、時間ｔ以前に、配信要求を受信している。そして、時間ｔにおいてはセグメント４に対応するファイル（Ｓｅｇ４Ｍ＿４．ｔｓ）についての配信要求を受信している。
同様に、第２のクライアント端末１１０−２からは、ストリーミングデータ１について、セグメント０からセグメント１に対応するファイルについて、時間ｔ以前に、配信要求を受信している。そして、時間ｔにおいてはセグメント２に対応するファイル（Ｓｅｇ４Ｍ＿２．ｔｓ）についての配信要求を受信している。
また、第３のクライアント端末１１０−３からは、ストリーミングデータ２について、セグメント０からセグメント２に対応するファイルについて、時間ｔ以前に、配信要求を受信している。そして、時間ｔにおいてはセグメント３に対応するファイル（Ｓｅｇ４Ｍ＿３．ｔｓ）についての配信要求を受信している。
また、第４のクライアント端末１１０−４からは、ストリーミングデータ２について、セグメント０からセグメント４に対応するファイルについて、時間ｔ以前に、配信要求を受信している。そして、時間ｔにおいてはセグメント５に対応するファイル（Ｓｅｇ４Ｍ＿５．ｔｓ）についての配信要求を受信している。
一方、第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８からは、時間ｔ以前に配信要求を受信しておらず、時間ｔにおいて、新たに配信要求を受信したとする。具体的には、ストリーミングデータ１またはストリーミングデータ２のセグメント０に対応するファイル（Ｓｅｇ４Ｍ＿０．ｔｓまたはＳｅｇ１Ｍ＿０．ｔｓ）についての配信要求を新たに受信したとする。
ここで、配信負荷算出部５０２では、時間ｔにおける配信負荷量を以下のように算出する。
・第１のクライアント端末１１０−１〜第４のクライアント端末１１０−４の配信負荷量
（４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋１［Ｍｂｐｓ］）×２（配信係数）＝２６［Ｍｂｐｓ］
・第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８の配信負荷量
（４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋１［Ｍｂｐｓ］）×２（配信係数）＝２６［Ｍｂｐｓ］
つまり、時間ｔにおいて、新たに第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８からの配信要求が開始したことで、配信負荷量は、２６［Ｍｂｐｓ］から５２［Ｍｂｐｓ］に増加した。このため、配信負荷算出部５０２では、時間ｔにおいて、第２の条件を満たしたと判定し、映像配信サーバ１２０の配信負荷が高いと判定する。
・第１のクライアント端末１１０−１〜第４のクライアント端末１１０−４の配信負荷量
（４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋１［Ｍｂｐｓ］）×２（配信係数）＝２６［Ｍｂｐｓ］
・第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８の配信負荷量
（４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋４［Ｍｂｐｓ］＋１［Ｍｂｐｓ］）×２（配信係数）＝２６［Ｍｂｐｓ］
つまり、時間ｔにおいて、新たに第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８からの配信要求が開始したことで、配信負荷量は、２６［Ｍｂｐｓ］から５２［Ｍｂｐｓ］に増加した。このため、配信負荷算出部５０２では、時間ｔにおいて、第２の条件を満たしたと判定し、映像配信サーバ１２０の配信負荷が高いと判定する。
そこで、配信ファイル変更部５０５では、時間ｔにおいて受信した配信要求において指定されたすべてのファイルについて、１段階画質の低いファイルの有無を確認し、存在する場合に、１段階画質の低いファイルに変更する。具体的には、第１のクライアント端末１１０−１からの配信要求については、ストリーミングデータ１のセグメント４に対応するファイルを、４［Ｍｂｐｓ］のファイル（ＳＥＧ４Ｍ＿４．ｔｓ）から１［Ｍｂｐｓ］のファイル（ＳＥＧ１Ｍ＿４．ｔｓ）に変更する。また、第２のクライアント端末１１０−２からの配信要求については、ストリーミングデータ１のセグメント２に対応するファイルを、４［Ｍｂｐｓ］のファイル（ＳＥＧ４Ｍ＿２．ｔｓ）から１［Ｍｂｐｓ］のファイル（ＳＥＧ１Ｍ＿２．ｔｓ）に変更する。
以下、同様に、各クライアント端末からの配信要求において指定されたストリーミングデータのセグメントに対応するファイルについて、画質が１段階低いファイルの有無を確認し、存在する場合には、画質が１段階低いファイルに変更する。この結果、配信負荷算出部５０２により算出される、時間ｔにおける配信負荷量は以下のようになる。
・第１のクライアント端末１１０−１〜第４のクライアント端末１１０−４の配信負荷量
（１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋５００［Ｋｂｐｓ］）×２（配信係数）＝７［Ｍｂｐｓ］
・第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８の配信負荷量
（１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋５００［Ｋｂｐｓ］）×２（配信係数）＝７［Ｍｂｐｓ］
つまり、時間ｔにおける配信負荷量は１４［Ｍｂｐｓ］となり、配信レート（４８［Ｍｂｐｓ］以下となったことで、配信部５０６では、変更後のファイルをそれぞれの要求元に送信する。
・第１のクライアント端末１１０−１〜第４のクライアント端末１１０−４の配信負荷量
（１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋５００［Ｋｂｐｓ］）×２（配信係数）＝７［Ｍｂｐｓ］
・第５のクライアント端末１１０−５〜第８のクライアント端末１１０−８の配信負荷量
（１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋１［Ｍｂｐｓ］＋５００［Ｋｂｐｓ］）×２（配信係数）＝７［Ｍｂｐｓ］
つまり、時間ｔにおける配信負荷量は１４［Ｍｂｐｓ］となり、配信レート（４８［Ｍｂｐｓ］以下となったことで、配信部５０６では、変更後のファイルをそれぞれの要求元に送信する。
以上の説明から明らかなように、ＭＰＥＧ−ＤＡＳＨが適用された映像配信システムにおいて、第１の実施形態に係る映像配信サーバでは、
・ＣＰＵ使用率を監視し、配信要求を受信した際にＣＰＵ使用率が所定の閾値を上回っているか否かを判定し、
・ＣＰＵ使用率に基づいて算出される映像配信サーバの配信レートと、配信要求において指定されたファイルを配信する場合の配信負荷量とを対比し、
・ＣＰＵ使用率が所定の閾値を上回っており、配信負荷量が配信レートを上回っていた場合に、それぞれの配信要求において指定されたファイルについて、画質の低いファイルの有無を確認する。そして、存在する場合には、配信負荷量が配信レート以下となるようにファイルを変更し、変更後のファイルを、配信要求において指定されたファイルに代えてそれぞれの要求元に送信する。
・ＣＰＵ使用率を監視し、配信要求を受信した際にＣＰＵ使用率が所定の閾値を上回っているか否かを判定し、
・ＣＰＵ使用率に基づいて算出される映像配信サーバの配信レートと、配信要求において指定されたファイルを配信する場合の配信負荷量とを対比し、
・ＣＰＵ使用率が所定の閾値を上回っており、配信負荷量が配信レートを上回っていた場合に、それぞれの配信要求において指定されたファイルについて、画質の低いファイルの有無を確認する。そして、存在する場合には、配信負荷量が配信レート以下となるようにファイルを変更し、変更後のファイルを、配信要求において指定されたファイルに代えてそれぞれの要求元に送信する。
これにより、複数のクライアント端末からの配信要求が集中して映像配信サーバの配信負荷が増加した場合であっても、映像配信サーバによるファイル送信の遅延を回避することができる。
このように、通常は可能な限り高画質な映像配信をすることが品質のよい配信であるところ、第１の実施形態に係る映像配信サーバでは、クライアント端末から見て画質とともに重視される連続性（滞りなく再生できること）を保証することを優先した。つまり、映像配信における品質（画質、連続性）のうち、連続性を優先した処理を行うようにした。この結果、第１の実施形態に係る映像配信サーバによれば、クライアント端末での連続的な再生を維持することが可能となる。
［第２の実施形態］
上記第１の実施形態では、配信負荷量を算出するにあたり、配信要求の要求内容に関わらず、配信係数を一律に設定（２倍）したのに対して、第２の実施形態では、配信係数を配信要求の要求内容に応じて変更する。以下、第２の実施形態について説明する。
上記第１の実施形態では、配信負荷量を算出するにあたり、配信要求の要求内容に関わらず、配信係数を一律に設定（２倍）したのに対して、第２の実施形態では、配信係数を配信要求の要求内容に応じて変更する。以下、第２の実施形態について説明する。
はじめに、第２の実施形態に係る映像配信サーバ１２０の機能構成について説明する。図８は、第２の実施形態に係る映像配信サーバの機能構成を示す図である。なお、図５で説明した機能構成と同じ要素については同じ参照番号を付すこととし、ここでは説明を省略する。図５との相違点は、配信リスト８１０を有する点である。
配信リスト８１０は、所定の周期ごとに、受信中の配信要求の内容を格納したリストであり、各配信要求に応じて、ファイルの送信期限時刻を定義することで、配信係数を設定するリストである。
図９は、配信リスト８１０の一例を示す図である。図９に示すように、配信リスト８１０には、情報の項目として、"配信要求の番号"、"要求元"、"要求内容"、"再生時間"、"要求受信時刻"、"送信期限時刻"が含まれる。
"配信要求の番号"には、現在受信中の配信要求を特定するための番号が格納される。"要求元"には、各配信要求を行った要求元のクライアント端末の名称が格納される。"要求内容"には、各配信要求において指定されたファイル名が格納される。"再生時間"には、各配信要求において指定されたファイルの再生に要する時間（再生時間）が格納される。"要求受信時刻"には、配信要求を受信した時刻である受信時刻が格納される。"送信期限時刻"には、各配信要求において指定されたファイルの送信を完了させる期限となる時刻が格納される。
図９の例では、"配信要求の番号"＝１により特定される配信要求は、"要求元"＝第１のクライアント端末１１０−１から送信され、"要求受信時刻"＝１３：００：００．０００に映像配信サーバ１２０において受信された配信要求である。そして、配信要求において指定された"要求内容"＝ストリーミングデータ１、ＳＥＧ４Ｍ＿４．ｔｓのファイルは、"再生時間"＝１０秒のファイルである。
ここで、配信負荷算出部５０２では、"要求内容"＝ストリーミングデータ１、ＳＥＧ４Ｍ＿４．ｔｓのファイルを第１のクライアント端末１１０−１に送信するにあたり、送信完了までの時間を５秒に設定したとする。この場合、"送信期限時刻"＝１３：００：００５．００となり、再生時間の１／２の時間で送信を完了させることが必要となる。再生時間の１／２の時間で送信を完了させるためには、配信要求において指定されたファイルの送信を２倍の配信レートで送信することと等価である。そこで、配信負荷算出部５０２では、"配信要求の番号"＝１の配信要求について、配信負荷量を算出するにあたり、配信係数を"２"に設定する。
以下、同様に、配信負荷算出部５０２では、各配信要求について"送信期限時刻"を設定することで、各送信要求において指定されるファイルを、再生時間の何倍の配信レートで送信するのかを設定する。そして、配信負荷算出部５０２では、各配信要求の配信負荷量を算出するにあたり、送信時間と再生時間との比に基づいて算出される配信係数を用いる。これにより、第２の実施形態に係る映像配信サーバ１２０では、配信要求ごとに異なる配信係数に基づいて配信負荷量を算出することができる。
次に、第２の実施形態に係る映像配信サーバ１２０による映像配信処理の流れについて説明する。図１０は、第２の実施形態に係る映像配信サーバによる映像配信処理のフローチャートである。なお、図１０に示すフローチャートのうち、図６と同様の処理については同じ参照番号を付すこととし、ここでは説明を省略する。図６との相違点は、ステップＳ１００１とステップＳ１００２である。
ステップＳ１００１において、配信負荷算出部５０２は、ステップＳ６０２において識別した各配信要求の要求内容に基づいて配信リスト８１０を生成するとともに、配信リスト８１０に送信期限時刻を設定する。
ステップＳ１００２において、配信負荷算出部５０２は、ステップＳ１００１において設定した各送信期限時刻により算出される各送信時間と、各配信要求において指定された各ファイルの再生時間との比に基づいて、配信係数を算出する。
これにより、ステップＳ６０５において、配信負荷算出部５０２は、ステップＳ１００２において算出した配信係数を用いて配信負荷量を算出することができる。
このように、第２の実施形態によれば、上記第１の実施形態における効果を享受できるとともに、更に、配信係数を配信要求の要求内容に応じて変更することが可能となる。
［第３の実施形態］
上記第１の実施形態では、第２の条件が成立すると判定した場合に、受信中の配信要求において指定されたファイルすべてを、画質の低いファイルに変更した。これに対して、第３の実施形態では、受信中の配信要求のうち、"配信要求の番号"が１番目の配信要求から、順次、算出した配信負荷量を加算していく。そして、加算した配信負荷量が第２の条件を満たした場合に、以降の配信要求において指定されたファイルの画質を落とすことで、映像配信サーバ１２０の配信負荷を低減させる。以下、第３の実施形態について説明する。
上記第１の実施形態では、第２の条件が成立すると判定した場合に、受信中の配信要求において指定されたファイルすべてを、画質の低いファイルに変更した。これに対して、第３の実施形態では、受信中の配信要求のうち、"配信要求の番号"が１番目の配信要求から、順次、算出した配信負荷量を加算していく。そして、加算した配信負荷量が第２の条件を満たした場合に、以降の配信要求において指定されたファイルの画質を落とすことで、映像配信サーバ１２０の配信負荷を低減させる。以下、第３の実施形態について説明する。
はじめに、第３の実施形態に係る映像配信サーバ１２０による映像配信処理の流れについて説明する。図１１は、第３の実施形態に係る映像配信サーバによる映像配信処理のフローチャートである。
ステップＳ６０１において、配信要求受信部５０１は、所定の周期ごとに第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎのいずれかから配信要求を受信したか否かを判定する。ステップＳ６０１において、配信要求を受信していないと判定した場合には、配信要求を受信するまで待機する。
一方、ステップＳ６０１において、配信要求を受信したと判定した場合には、ステップＳ６０２に進む。ステップＳ６０２において、配信要求受信部５０１は、受信した配信要求それぞれの要求内容を識別する。具体的には、ステップＳ６０１において受信した各配信要求において指定されたファイルを識別する。
ステップＳ１１０１において、配信負荷算出部５０２は、配信要求カウントｉに"１"を代入する。
ステップＳ６０３において、ＣＰＵ使用率監視部５０３は、現在のＣＰＵ３０１の使用率を取得する。また、配信レート算出部５０４は、取得したＣＰＵ使用率のもとでのＣＰＵ３０１の配信レートを算出する。
ステップＳ６０４において、ＣＰＵ使用率監視部５０３は、ステップＳ６０３において取得したＣＰＵ使用率が、所定の閾値を上回っているか否か（第１の条件を満たしているか否か）を判定する。
ステップＳ６０４において、所定の閾値を上回っていない（第１の条件を満たしていない）と判定した場合には、ステップＳ６０９に進む。この場合、配信部５０６では、ステップＳ６０１において受信した各配信要求において指定されたファイルを、それぞれの要求元に送信する。
一方、ステップＳ６０４において、所定の閾値を上回っている（第１の条件を満たしている）と判定した場合には、ステップＳ１１０２に進む。
ステップＳ１１０２において、配信負荷算出部５０２は、ｉ番目の配信要求について、画質と配信係数とに基づいて配信負荷量を算出する。ここでは、配信要求カウントｉに"１"が代入されているため、１番目の配信要求について、画質と配信係数に基づいて配信負荷量を算出する。
ステップＳ６０６において、配信負荷算出部５０２は、ステップＳ１１０２において算出した配信負荷量が、ステップＳ６０３において算出した配信レートを上回っているか否か（第２の条件を満たしているか否か）を判定する。ステップＳ６０６において、配信負荷量が配信レート以下であった（第２の条件を満たしていない）と判定された場合には、ステップＳ１１０４に進む。
ステップＳ１１０４において、配信レート算出部５０４は、ステップＳ６０１において受信した全ての配信要求に基づいて配信負荷量を算出したか否かを判定する。ステップＳ１１０４において、配信要求のうち、配信負荷量の算出に用いられていない配信要求があると判定した場合には、ステップＳ１１０５に進む。
ステップＳ１１０５において、配信負荷算出部５０２は、配信要求カウントｉをインクリメントし、ステップＳ１１０２に戻る。ここでは、配信要求カウントｉ＝２としたうえで、ステップＳ１１０２に戻る。
ステップＳ１１０２において、配信負荷算出部５０２は、２番目の配信要求について画質と配信係数とに基づいて配信負荷量を算出する。また、ステップＳ６０６において、第２の条件を満たしているか否かを判定する。判定の結果、まだ、第２の条件を満たしていない場合には、ステップＳ１１０４に進む。
ステップＳ１１０４では、配信負荷算出部５０２が、再び、配信負荷量の算出に用いられていない配信要求があるか否かを判定し、あると判定した場合には、配信要求カウントｉをインクリメントする。
このように、ステップＳ６０１において受信した配信要求において指定されたファイルに基づいて算出される配信負荷量を、配信要求の番号の小さい方から順次、加算していく。そして、ステップＳ６０６において、配信負荷量が配信レートを上回った（第２の条件を満たした）と判定した場合には、ステップＳ６０７に進む。ステップＳ６０７において、配信負荷算出部５０２は、映像配信サーバ１２０の配信負荷が高いと判定し、ステップＳ１１０３に進む。
ステップＳ１１０３において、配信ファイル変更部５０５は、ｉ番目の配信要求において指定されたファイルについて、画質が１段階低いファイルの有無を確認し、存在する場合には、画質が１段階低いファイルに変更する。そして、ステップＳ６０６に戻り、変更後のファイルを含むｉ番目までの配信要求それぞれにおいて指定されたファイルに基づいて算出された配信負荷量の合計が、配信レートを上回っているか否かを判定する。なお、画質が１段階低いファイルが存在しない場合には、ファイルの変更は行われない。
ステップＳ６０６において、依然として配信負荷量が配信レートを上回っていると判定された場合には、ステップＳ６０７に進み、配信負荷算出部５０２が、映像配信サーバ１２０の配信負荷が高いと判定する。更に、ステップＳ１１０３において、配信ファイル変更部５０５は、ｉ番目の配信要求において指定されたファイルについて、更に、１段階低い画質のファイルの有無を確認し、存在する場合には、更に１段階低い画質のファイルに変更する。その後、再びステップＳ１１０２に戻る。なお、存在しない場合には、更なるファイルの変更は行われない。
このように、変更後のファイルを含むｉ番目までの配信要求それぞれにおいて指定されたファイルに基づいて算出される配信負荷量の合計が、配信レート以下となるまで、ｉ番目の配信要求において指定されたファイルを、順次画質の低いファイルへと変更していく。ステップＳ６０６において、配信負荷算出部５０２が、変更後のファイルを含むｉ番目までの配信要求それぞれにおいて指定されたファイルに基づいて算出される配信負荷量の合計が、配信レート以下となったと判定した場合には、ステップＳ１１０４に進む。
ステップＳ１１０４において、配信レート算出部５０４は、ステップＳ６０１において受信した全ての配信要求に基づいて配信負荷量を算出したか否かを判定する。ステップＳ１１０４において、全ての配信要求に基づいて配信負荷量を算出したと判定した場合には、ステップＳ６０９に進む。
ステップＳ６０９において、配信部５０６は、全ての配信要求に基づいて算出された配信負荷量の合計が配信レート以下になったと判定された際の各画質のファイルを、要求元に送信する。
ステップＳ６１０において、配信要求受信部５０１は、映像配信プログラム１３０に対する実行停止指示が入力されたか否かを判定し、入力されていないと判定した場合には、ステップＳ６０１に戻る。一方、入力されたと判定した場合には、映像配信処理を終了する。
次に、第３の実施形態に係る映像配信サーバ１２０による映像配信処理の具体例について説明する。図１２は、映像配信処理の具体例を示す図である。図１２（ａ）は、ＣＰＵ使用率監視部５０３により取得されるＣＰＵ使用率の時間変化を示す図であり、図７（ａ）と同じである。
したがって、図７（ａ）と同様に、ＣＰＵ使用率監視部５０３では、第１の条件を満たすと判定する。また、配信レート算出部５０４では、ＣＰＵ使用率＝８０％における配信レートを算出し、図７（ａ）と同様に、配信レート＝４８［Ｍｂｐｓ］を導出する。更に、配信要求受信部５０１では、時間ｔにおいて受信した配信要求の要求内容について識別し、図７（ｂ）と同様の識別結果を得たとする。
ここで、本実施形態において配信負荷算出部５０２では、まず配信要求カウントｉ＝１に対応する"配信要求の番号"＝１（第１のクライアント端末１１０−１）の配信要求について配信負荷量を算出する。第１のクライアント端末１１０−１の配信要求において指定されたファイル（ＳＥＧ４Ｍ＿４．ｔｓ）は、画質＝４［Ｍｂｐｓ］のファイルであることから、配信負荷量＝４［Ｍｂｐｓ］×２（配信係数）＝８［Ｍｂｐｓ］となる。算出した配信負荷量（８［Ｍｂｐｓ］）は配信レート（４８［Ｍｂｐｓ］）以下であるため、配信負荷算出部５０２では、配信要求において指定されたファイルを変更する必要がないと判定する。そして、配信要求カウントｉをインクリメントし（ｉ＝２）、次の配信要求について、配信負荷量を算出する。
具体的には、配信要求カウントｉ＝２に対応する"配信要求の番号"＝２（第２のクライアント端末１１０−２）の配信要求について配信負荷量を算出する。図１２（ｂ）の例では、第２のクライアント端末１１０−２の配信要求において指定されたファイル（ＳＥＧ４Ｍ＿２．ｔｓ）は、画質＝４［Ｍｂｐｓ］のファイルである。したがって、配信負荷量＝４［Ｍｂｐｓ］×２（配信係数）＝８［Ｍｂｐｓ］となる。
そして、"配信要求の番号"＝１（第１のクライアント端末１１０−１）の配信要求において指定されたファイルに基づく配信負荷量に加算すると、配信負荷量の合計は１６［Ｍｂｐｓ］となる。算出した配信負荷量の合計（１６［Ｍｂｐｓ］）は依然として配信レート（４８［Ｍｂｐｓ］）以下であるため、配信負荷算出部５０２では、配信要求において指定されたファイルを変更する必要がないと判定する。そして、配信要求カウントｉをインクリメントしたうえで（ｉ＝３）、次の配信要求について、配信負荷量を算出する。
以下、図１２（ｂ）に示すように、配信要求カウントｉ＝６に対応する"配信要求の番号"＝６（第６のクライアント端末１１０−６）の配信要求について算出された配信負荷量を加算するまでの、配信負荷量の合計は４２［Ｍｂｐｓ］である。
ここで、配信要求カウントｉ＝７に対応する"配信要求の番号"＝７（第７のクライアント端末１１０−７）の配信要求について算出された配信負荷量（８［Ｍｂｐｓ］）を加算すると、配信負荷量の合計は５０［Ｍｂｐｓ］となる。つまり、配信負荷量が配信レート（４８［Ｍｂｐｓ］）を上回ることとなる。
そこで、配信ファイル変更部５０５では、配信要求カウントｉ＝７に対応する"配信要求の番号"＝７（第７のクライアント端末１１０−７）については、配信要求において指定されたファイルよりも画質が１段階低いファイルの有無を確認する。そして、存在する場合には、画質が１段階低いファイルに変更する。この場合、"配信要求の番号"＝７（第７のクライアント端末１１０−７）の配信要求について算出される配信負荷量は、２［Ｍｂｐｓ］となる。この結果、第６のクライアント端末１１０−６の配信要求について算出された配信負荷量を加算するまでの、合計の配信負荷量に加算した場合、合計の配信負荷量は４４［Ｍｂｐｓ］となる。つまり、合計の配信負荷量（４４［Ｍｂｐｓ］）が配信レート（４８［Ｍｂｐｓ］）以下となる。したがって、配信ファイル変更部５０５では、"配信要求の番号"＝７（第７のクライアント端末１１０−７）の配信要求に対して送信するファイルを、ＳＥＧ１Ｍ＿０．ｔｓに変更することを決定する。
更に、配信負荷算出部５０２では、更に、配信要求カウントｉをインクリメントしたうえで（ｉ＝８）、次の配信要求について、配信負荷量を算出する。具体的には、配信要求カウントｉ＝８に対応する"配信要求の番号"＝８（第８のクライアント端末１１０−８）の配信要求について配信負荷量を算出する。図１２（ｂ）の例では、第８のクライアント端末１１０−８の配信要求において指定されたファイル（ＳＥＧ１Ｍ＿０．ｔｓ）は、画質＝１［Ｍｂｐｓ］のファイルである。したがって、配信負荷量＝１［Ｍｂｐｓ］×２（配信係数）＝２［Ｍｂｐｓ］となる。
そして、"配信要求の番号"＝７（第７のクライアント端末１１０−７）の配信要求について算出された配信負荷量を加算するまでの、合計の配信負荷量（４４［Ｍｂｐｓ］）に加算すると、合計の配信負荷量は４６［Ｍｂｐｓ］となる。つまり、算出した合計の配信負荷量（４６［Ｍｂｐｓ］）は配信レート（４８［Ｍｂｐｓ］）以下であるため、配信負荷算出部５０２では、第８のクライアント端末１１０−８の配信要求において指定されたファイルを変更する必要がないと判定する。
図１２（ｂ）の例では、時間ｔにおいて"配信要求の番号"＝８までの配信要求を受信しているため、配信要求カウントｉ＝８のときに算出された配信負荷量が加算されると、全ての配信要求に基づいて算出した配信負荷量の合計が算出されたこととなる。この結果、図１２（ｂ）の下段に示すファイルが、配信部５０６によりそれぞれの要求元に送信される。
このように、第３の実施形態によれば、受信した配信要求のうち、一部の配信要求において指定されたファイルを変更するだけで、映像配信サーバによるファイル送信の遅延を回避することができる。この結果、クライアント端末での連続的な再生を維持することが可能となる。
［第４の実施形態］
上記第１の実施形態では、第２の条件が成立したと判定した場合に、受信中の配信要求において指定されたファイルすべてを、画質の低いファイルに変更した。
上記第１の実施形態では、第２の条件が成立したと判定した場合に、受信中の配信要求において指定されたファイルすべてを、画質の低いファイルに変更した。
また、上記第３の実施形態では、配信要求の番号の小さい方から順に配信負荷量を加算していき、配信負荷量の合計が配信レートを上回った場合に、第２の条件が成立したと判定し、最後に加算したファイルを、画質の低いファイルに変更した。
これに対して、第４の実施形態では、第２の条件が成立したと判定した場合に、受信中の配信要求のうち、画質の高いファイルについて、優先的に画質の低いファイルに変更する。以下、第４の実施形態について説明する。
はじめに、第４の実施形態に係る映像配信サーバ１２０による映像配信処理の流れについて説明する。図１３は、第４の実施形態に係る映像配信サーバによる映像配信処理のフローチャートである。なお、図１３に示すフローチャートのうち、図６と同様の処理については同じ参照番号を付すこととし、ここでは説明を省略する。図６との相違点は、ステップＳ１３０１である。
ステップＳ１３０１において、配信ファイル変更部５０５は、ステップＳ６０１において受信した配信要求において指定されたファイルのうち、特定される画質が最も高いファイルを選択する。そして、配信ファイル変更部５０５では、選択したファイルについて１段階画質の低いファイルの有無を確認し、存在する場合には、１段階画質の低いファイルに変更した後、ステップＳ６０５に戻る。なお、存在しない場合には、ファイルを変更することなくステップＳ６０５に戻る。
ステップＳ６０５において、配信負荷算出部５０２は、ステップＳ６０１において受信した配信要求により指定されたファイル（ステップＳ１３０１において変更された場合にあっては変更後のファイル）により特定される画質に基づいて、配信負荷量を算出する。
更に、ステップＳ６０６において、配信負荷算出部５０２は、ステップＳ６０５において算出された配信負荷量が配信レートを上回っているか否かを判定し、依然として、配信負荷量が配信レートを上回っている場合には、ステップＳ６０７に進む。ステップＳ６０７において、配信負荷算出部５０２は、映像配信サーバ１２０の配信負荷が高いと判定する。また、ステップＳ１３０１において、配信ファイル変更部５０５は、受信した配信要求において指定されたファイル（ステップＳ１３０１において変更された場合にあっては変更後のファイル）のうち、特定される画質が最も高いファイルを選択する。そして、配信ファイル変更部５０５は、選択したファイルについて１段階画質の低いファイルの有無を確認し、存在する場合には１段階画質の低いファイルに変更した後、ステップＳ６０４に戻る。なお、存在しない場合には、ファイルを変更することなくステップＳ６０４に戻る。
このように、第４の実施形態では、受信中の配信要求において指定されたファイルのうち、画質の高いファイルから順次画質の低いファイルに変更していき、配信負荷量が配信レート以下となるまで、これらの処理を繰り返す。
次に、第４の実施形態に係る映像配信サーバ１２０による映像配信処理の具体例について説明する。図１４は、第４の実施形態に係る映像配信サーバによる映像配信処理の具体例を示す図である。なお、図１４（ａ）は、図７（ａ）と同じであるため、ここでは説明を省略する。また、図１４（ｂ）の上段に示す、時間ｔにおける各クライアント端末からの要求内容も、図７（ｂ）の上段に示す図と同じであるため、ここでは説明を省略する。
第４の実施形態において、配信負荷算出部５０２は、受信中の配信要求のうち、画質が最も高いファイルを選択する。図１４（ｂ）の上段に示す図の例では、画質が最も高いファイルは、下記のとおりである。
・第１のクライアント端末１１０−１より要求されたＳＥＧ４Ｍ＿４．ｔｓ、
・第２のクライアント端末１１０−２より要求されたＳＥＧ４Ｍ＿２．ｔｓ、
・第３のクライアント端末１１０−３より要求されたＳＥＧ４Ｍ＿３．ｔｓ、
・第５のクライアント端末１１０−５より要求されたＳＥＧ４Ｍ＿０．ｔｓ、
・第６のクライアント端末１１０−６より要求されたＳＥＧ４Ｍ＿０．ｔｓ、
・第７のクライアント端末１１０−７より要求されたＳＥＧ４Ｍ＿０．ｔｓ、
である（いずれも、画質＝４［Ｍｂｐｓ］）。したがって、上記ファイルについて１段階画質の低いファイルの有無を確認し、存在する場合には、１段階画質の低いファイル（すなわち、１［Ｍｂｐｓ］のファイル）に変更する。図１４（ｂ）の下段に示す図は、図１４（ｂ）の上段に示すファイルのうち、画質が最も高いファイルを１段階画質の低いファイルに変更した様子を示している。
・第１のクライアント端末１１０−１より要求されたＳＥＧ４Ｍ＿４．ｔｓ、
・第２のクライアント端末１１０−２より要求されたＳＥＧ４Ｍ＿２．ｔｓ、
・第３のクライアント端末１１０−３より要求されたＳＥＧ４Ｍ＿３．ｔｓ、
・第５のクライアント端末１１０−５より要求されたＳＥＧ４Ｍ＿０．ｔｓ、
・第６のクライアント端末１１０−６より要求されたＳＥＧ４Ｍ＿０．ｔｓ、
・第７のクライアント端末１１０−７より要求されたＳＥＧ４Ｍ＿０．ｔｓ、
である（いずれも、画質＝４［Ｍｂｐｓ］）。したがって、上記ファイルについて１段階画質の低いファイルの有無を確認し、存在する場合には、１段階画質の低いファイル（すなわち、１［Ｍｂｐｓ］のファイル）に変更する。図１４（ｂ）の下段に示す図は、図１４（ｂ）の上段に示すファイルのうち、画質が最も高いファイルを１段階画質の低いファイルに変更した様子を示している。
図１４（ｂ）の下段に示すように、画質が最も高いファイルを１段階画質の低いファイルに変更することで、変更後のファイルの配信負荷量は、１６［Ｍｂｐｓ］になる。つまり、配信負荷量が配信レート（４８［Ｍｂｐｓ］）以下となったため、配信部５０６では、変更後のファイルを要求元に送信する。
このように、本実施形態に係る映像配信サーバ１２０では、画質が最も高いファイル（最も高いファイルが複数ある場合には、複数のファイルすべて）について、１段階画質の低いファイルの有無を確認し、存在する場合には１段階画質の低いファイルに変更する。そして、変更後の配信負荷量を算出し、配信レート以下でなければ、再度、その時点で画質が最も高いファイルについて、１段階画質の低いファイルの有無を確認したうえで変更する。ファイルを変更することにより配信負荷量が配信レート以下になった場合には、変更後のファイルを配信する。これにより、複数のクライアント端末からの配信要求が集中して映像配信サーバの配信負荷が増加した場合であっても、映像配信サーバによるファイル送信の遅延を回避することができる。この結果、クライアント端末での連続的な再生を維持することが可能となる。
［第５の実施形態］
上記第４の実施形態では、受信中の配信要求のうち、画質の高いファイルについて、優先的に１段階画質の低いファイルに変更した。これに対して、第５の実施形態では、受信中の配信要求のうち、要求元のクライアント端末について予め設定している優先順位が低いクライアント端末からの配信要求において指定されたファイルについて、１段階画質の低いファイルに変更する。以下、第５の実施形態について説明する。
上記第４の実施形態では、受信中の配信要求のうち、画質の高いファイルについて、優先的に１段階画質の低いファイルに変更した。これに対して、第５の実施形態では、受信中の配信要求のうち、要求元のクライアント端末について予め設定している優先順位が低いクライアント端末からの配信要求において指定されたファイルについて、１段階画質の低いファイルに変更する。以下、第５の実施形態について説明する。
はじめに、第５の実施形態に係る映像配信サーバ１２０の機能構成について説明する。図１５は、第５の実施形態に係る映像配信サーバの機能構成を示す図である。なお、図５で説明した機能構成と同じ要素については同じ参照番号を付すこととし、ここでは説明を省略する。図５との相違点は、優先順位リストＤＢ１５００を有する点である。
優先順位リストＤＢ１５００は、映像配信サーバ１２０にネットワーク１６０を介して接続された第１のクライアント端末１１０−１〜第ｎのクライアント端末１１０−ｎについて設定された優先順位が格納されたＤＢである。なお、ここでいう優先順位とは、クライアント端末からの配信要求に従ってファイル送信を行うための優先度を示したものであり、優先順位が高いクライアント端末に対しては、配信要求において指定されたファイルが送信される可能性が高くなる。一方、優先順位が低いクライアント端末に対しては、配信要求が集中した場合に、配信要求において指定されたファイルが送信される可能性が低くなる。
図１６は、優先順位リストＤＢの具体例を示す図である。図１６に示すように、優先順位リストＤＢ１５００は、情報の項目として、"要求元"と"優先順位"とが含まれ、"要求元"には、映像配信サーバ１２０に接続されるクライアント端末の名称が全て格納される。また、"優先順位"には、各クライアント端末について設定された優先順位が格納される。
図１６の例では、映像配信サーバ１２０に接続されるクライアント端末が３つのグループに区分されている。このため、優先順位リストＤＢ１５００には、優先順位＝１のクライアント端末と、優先順位＝２のクライアント端末と、優先順位＝３のクライアント端末とが含まれる。なお、優先順位の区分方法は図１６の例に限定されるものではなく、２つのグループに区分してもよいし、４つ以上のグループに区分してもよい。
また、上記説明では優先順位の設定方法について特に言及していないが、優先順位の設定方法には、様々なバリエーションが考えられる。例えば、配信要求の要求元のクライアント端末において、ストリーミングデータを再生する表示画面のサイズに応じて、優先順位を設定するようにしてもよい。具体的には、画質の低下が顕在化しやすい大サイズを有するクライアント端末の優先順位を高く設定し、画質の低下が顕在化しにくい小サイズの画面を有するクライアント端末の優先順位を低く設定するようにしてもよい。
あるいは、配信要求の要求元のクライアント端末により再生されるストリーミングデータを視聴する視聴者の数に応じて、優先順位を設定するようにしてもよい。具体的には、多数の視聴者が視聴することを前提としたクライアント端末の優先順位を高く設定し、個人が視聴することを前提としたクライアント端末の優先順位を低く設定するようにしてもよい。
あるいは、配信要求の要求頻度に応じて、優先順位を設定するようにしてもよい。具体的には、要求頻度の高いクライアント端末の優先順位を高く設定し、要求頻度の低いクライアント端末の優先順位を低く設定するようにしてもよい。
次に、第５の実施形態に係る映像配信サーバ１２０による映像配信処理の流れについて説明する。図１７は、第５の実施形態に係る映像配信サーバによる映像配信処理のフローチャートである。なお、図１７に示すフローチャートのうち、図６と同様の処理については同じ参照番号を付すこととし、ここでは説明を省略する。図６との相違点は、ステップＳ１７０１、Ｓ１７０２、Ｓ１７０３である。
ステップＳ１７０１において、配信負荷算出部５０２は、優先順位カウントｊに、優先順位の最も低い値である"３"を代入する。なお、図１６に示す優先順位リストＤＢ１５００において、クライアント端末が２つのグループに区分されている場合には、ステップＳ１７０１において優先順位カウントｊには"２"が代入される。また、４つ以上のグループに区分されている場合には、ステップＳ１７０１において優先順位カウントｊには４以上の値が代入される。
ステップＳ１７０２において、配信ファイル変更部５０５は、優先順位がｊ番目のクライアント端末からの配信要求において指定されたファイルについて、１段階画質の低いファイルの有無を確認し、存在する場合には１段階画質の低いファイルに変更する。ここでは、優先順位が３番目のクライアント端末からの配信要求において指定されたファイルが、１段階画質の低いファイルの有無を確認したうえで変更される。なお、存在しない場合には、ファイルの変更は行われない。
ステップＳ１７０３において、配信ファイル変更部５０５は、優先順位カウントｊをデクリメントし、ステップＳ６０５に戻る。ここでは、優先順位カウントｊ＝２としたうえで、ステップＳ６０５に戻る。
ステップＳ６０５において、配信レート算出部５０４は、ステップＳ６０１において受信した配信要求において指定されたファイル（ステップＳ１７０２において変更された場合にあっては変更後のファイル）に基づいて、配信負荷量を算出する。
ステップＳ６０６において、配信負荷算出部５０２は、ステップＳ６０５において算出された配信負荷量が配信レートを上回っているか否かを判定する。ステップＳ６０６において、配信負荷量が配信レートを上回っていると判定された場合には、再び、ステップＳ６０７に進み、配信負荷算出部５０２は、映像配信サーバ１２０の配信負荷が高いと判定する。更に、ステップＳ１７０２において、優先順位がｊ番目（ここでは２番目）のクライアント端末からの配信要求により指定されたファイルについて、１段階画質の低いファイルの有無を確認し、存在する場合には１段階画質の低いファイルに変更する。なお、存在しない場合には、ファイルの変更は行われない。
このように、第５の実施形態では、優先順位の低いクライアント端末からの配信要求において指定されたファイルから、順次、画質を１段階ずつ落としていき、配信負荷量が配信レート以下となるようにする。
次に、第５の実施形態に係る映像配信サーバ１２０による映像配信処理の具体例について説明する。図１８は、第５の実施形態に係る映像配信サーバによる映像配信処理の具体例を示す図である。なお、図１８（ａ）は、図７（ａ）と同じであるため、ここでは説明を省略する。また、図１８（ｂ）の上段に示す、時間ｔにおける各クライアント端末からの要求内容も、図７（ｂ）の上段に示す図と同じであるため、ここでは説明を省略する。
第５の実施形態において、配信ファイル変更部５０５は、受信中の配信要求のうち、優先順位の低いクライアント端末からの配信要求において指定されたファイルを選択する。優先順位リストＤＢ１５００によれば、図１８（ｂ）の上段に示す図の例では、優先順位の低いクライアント端末は、第３のクライアント端末１１０−３、第６のクライアント端末１１０−６、第７のクライアント端末１１０−７である（いずれも優先順位＝３）。したがって、配信ファイル変更部５０５は、第３のクライアント端末１１０−３、第６のクライアント端末１１０−６、第７のクライアント端末１１０−７を選択する。
また、配信ファイル変更部５０５では、選択したクライアント端末からの配信要求において指定されたファイルについて、１段階画質の低いファイルの有無を確認し、存在する場合には１段階画質の低いファイルに変更する。図１８（ｂ）の例では、選択されたクライアント端末からの配信要求において指定されたファイルは、いずれも４［Ｍｂｐｓ］のファイルであることから、１段階画質の低いファイル（１［Ｍｂｐｓ］のファイル）に変更する。
図１８（ｂ）の下段に示すように、優先順位の低いクライアント端末からの配信要求において指定されたファイルを、１段階画質の低いファイルに変更することで、変更後のファイルの配信負荷量は、３４［Ｍｂｐｓ］になる。つまり、配信負荷量が配信レート（４８［Ｍｂｐｓ］）以下となったため、配信部５０６では、変更後のファイルを要求元に送信する。
なお、優先順位の最も低いクライアント端末（優先順位＝３の第３、第６、第７のクライアント端末１１０−３、１１０−６、１１０−７）からの配信要求において指定されたファイルを変更しても、配信負荷量が配信レートを上回っていたとする。この場合には、優先順位が次に低いクライアント端末（優先順位＝２の第４、第８のクライアント端末１１０−４、１１０−８）からの配信要求において指定されたファイルを変更する。
このように、本実施形態に係る映像配信サーバ１２０では、配信負荷量が配信レートを上回っていた場合、優先順位の低いクライアント端末からの配信要求において指定されたファイルを、優先的に１段階画質の低いファイルに変更する。また、優先順位の低いクライアント端末からの配信要求において指定されたファイルを変更してもなお、配信負荷量が配信レートを上回っている場合には、優先順位が次に低いクライアント端末からの配信要求において指定されたファイルを変更する。つまり、対象とする優先順位を低い方から高い方へと変えながら、対象とする優先順位のクライアント端末からの配信要求において指定されたファイルを１段階画質の低いファイルへと変更していく。
これにより、複数のクライアント端末からの配信要求が集中して映像配信サーバの配信負荷が増加した場合であっても、映像配信サーバによるファイル送信の遅延を回避することができる。この結果、クライアント端末での連続的な再生を維持することが可能となる。
［第６の実施形態］
上記第１の実施形態では、セグメントごとに対応付けられた、画質の異なるファイルとして、フレーム画像２０１〜２０７とは画像サイズの異なるフレーム画像を例示した。しかしながら、画質の異なるファイルは、フレーム画像ごとの画像サイズの異なるファイルに限定されない。そこで、第６の実施形態では、セグメントごとに対応付けられた、画質の異なるファイルの例について、図１９及び図２０を用いて更に説明する。
上記第１の実施形態では、セグメントごとに対応付けられた、画質の異なるファイルとして、フレーム画像２０１〜２０７とは画像サイズの異なるフレーム画像を例示した。しかしながら、画質の異なるファイルは、フレーム画像ごとの画像サイズの異なるファイルに限定されない。そこで、第６の実施形態では、セグメントごとに対応付けられた、画質の異なるファイルの例について、図１９及び図２０を用いて更に説明する。
図１９（ａ）は、図２（ａ）と同じであり、フレーム画像２０１〜２０７は、それぞれがＩａ［Ｍｂｉｔ（メガビット）］のデータであり、第１のファイル２００は、Ｉａ／Ｔ［Ｍｂｐｓ］のレートで再生される。
一方、図１９（ｂ）は、同じセグメントに対応付けられたファイル１９００に複数のフレーム画像１９０１〜１９０７が所定のフレーム周期Ｔで再生されるように格納されていることを示している。ここで、複数のフレーム画像１９０１〜１９０７は、それぞれ、複数のフレーム画像２０１〜２０７よりも圧縮率が高く、それぞれがＩａ／２［Ｍｂｉｔ］のデータであるとする。つまり、ファイル１９００は、Ｉａ／２Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであるということができる。
また、図１９（ｃ）は、同じセグメントに対応付けられたファイル１９１０に複数のフレーム画像１９１１〜１９１４が所定のフレーム周期２Ｔで再生されるように格納されていることを示している。ここで、複数のフレーム画像１９１１〜１９１４は、それぞれ複数のフレーム画像２０１、２０３、２０５、２０７と同じフレーム画像であり、それぞれがＩａ［Ｍｂｉｔ］のデータであるとする。つまり、ファイル１９１０は、Ｉａ／２Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであるということができる。
このように、図１９（ａ）に示すフレーム画像２０１〜２０７を含む第１のファイル２００に対して、画質が１／２のファイルを、様々な方法で生成することができる。なお、図２及び図１９の例では、１つのセグメントに対応付けられた第１のファイル２００には、複数のフレーム画像２０１〜２０７が含まれるものとして説明した。しかしながら、１つのセグメントに対応付けられた第１のファイル２００に含まれる画像は、フレーム画像に限定されない。例えば、フレーム画像と差分画像とが混在していてもよい。
図２０は、所定のストリーミングデータに含まれる所定のセグメントに対応付けられた画質の異なるファイルを模式的に示した他の例である。図２０（ａ）の例は、１つのセグメントに対応付けられたファイル２０００に、複数のフレーム画像２００１、２００３、２００５、２００７と、複数の差分画像２００２、２００４、２００６とが所定のフレーム周期Ｔで再生されるように格納されている。ここでフレーム画像２００１、２００３、２００５、２００７それぞれがＩａ［Ｍｂｉｔ］のデータであり、差分画像２００２、２００４、２００６それぞれがＩｂ［Ｍｂｉｔ］のデータであり、Ｉａ＞＞Ｉｂであったとする。この場合、ファイル２０００は、概ねＩａ／２Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであるということができる。
図２０（ｂ）は、同じセグメントに対応付けられたファイル２０１０に複数のフレーム画像２０１１、２０１５と、複数の差分画像２０１２〜２０１４、２０１６、２０１７とが所定のフレーム周期Ｔで再生されるように格納されていることを示している。ここでフレーム画像２０１１、２０１５それぞれがＩａ［Ｍｂｉｔ］のデータであり、差分画像２０１２〜２０１４、２０１６、２０１７それぞれがＩｂ［Ｍｂｉｔ］のデータであり、Ｉａ＞＞Ｉｂであったとする。この場合、ファイル２０１０は、概ねＩａ／４Ｔ［Ｍｂｐｓ］のレートで再生されるファイルであるということができる。
このように、図２０（ａ）に示すフレーム画像２００１、２００３、２００５、２００７と差分画像２００２、２００４、２００６とを含むファイル２０００に対して、画質が概ね１／２のファイル２０１０を生成することができる。
［第７の実施形態］
上記第１の実施形態及び上記第６の実施形態では、図２、図１９、図２０を用いて、画質の異なるファイルの生成方法について説明した。ここで、同一の生成方法によりファイルを生成した場合においては、レートの小さいファイルほど画質が低いため、レートと画質とは等価であることは既に述べたとおりである。
上記第１の実施形態及び上記第６の実施形態では、図２、図１９、図２０を用いて、画質の異なるファイルの生成方法について説明した。ここで、同一の生成方法によりファイルを生成した場合においては、レートの小さいファイルほど画質が低いため、レートと画質とは等価であることは既に述べたとおりである。
しかしながら、同一レートのファイルを異なる生成方法により生成した場合には、同一の画質になるとは限らず、同一レートであっても画質には差異が生じる。例えば、図２に示したように、画像サイズを小さくすることで低レートのファイルを生成した場合、図１９または図２０に示したように、他の方法で低レートのファイルを生成した場合と比較して、画質の低下が大きい。
このため、配信ファイル変更部５０５が、ストリーミングデータ用ＤＢ１４０に基づいて低レートのファイルを選択するにあたっては、画質の影響を受けにくい生成方法により生成されたファイルを優先的に選択することもできる。これにより、配信要求において指定されたファイルよりも低レートのファイルが送信されたクライアント端末において、画質の低下を認識しにくくさせることができる。
［第８の実施形態］
上記第１乃至第７の実施形態では、配信要求を受信するごとに、第１及び第２の条件が成立しているか否かを判定し、第１及び第２の条件が成立している場合にファイルを変更するようにした。このため、例えば、今回の配信要求において第１及び第２の条件が成立した場合であっても、次回の配信要求において第１及び第２の条件が成立しなくなった場合には、ファイルの変更は行われず、配信要求において指定されたファイルが送信されることとなる。
上記第１乃至第７の実施形態では、配信要求を受信するごとに、第１及び第２の条件が成立しているか否かを判定し、第１及び第２の条件が成立している場合にファイルを変更するようにした。このため、例えば、今回の配信要求において第１及び第２の条件が成立した場合であっても、次回の配信要求において第１及び第２の条件が成立しなくなった場合には、ファイルの変更は行われず、配信要求において指定されたファイルが送信されることとなる。
しかしながら、ファイルの変更は、配信要求を受信するごとに判定された判定結果に基づいて行われなくてもよい。例えば、今回の配信要求において第１及び第２の条件が成立した場合には、所定期間、ファイルの変更を継続して行い、所定期間が経過した後に元に戻す（すなわち、配信要求において指定されたファイルを送信する）ようにしてもよい。
また、元に戻す際に、第１及び第２の条件が成立しているか否かを判定し、第１及び第２の条件が成立している場合には、元に戻すことなく、所定期間、ファイルの変更を継続して行うようにしてもよい。
なお、開示の技術では、以下に記載する付記のような形態が考えられる。
（付記１）
要求元からの配信要求に対する処理負荷を算出する算出部と、
前記処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換える変更部と、
前記差し換えた映像ファイルを、前記要求元に対して配信する配信部と
を有することを特徴とする映像配信サーバ。
（付記２）
前記変更部は、予め設定された要求元の優先順位のうち、優先順位の低い要求元から要求された映像ファイルを、優先して差し換えることを特徴とする付記１に記載の映像配信サーバ。
（付記３）
前記変更部は、前記要求元のうち、品質の高い映像ファイルを要求する要求元から要求された映像ファイルを、優先して差し換えることを特徴とする付記１に記載の映像配信サーバ。
（付記４）
前記算出部は、前記要求元からの配信要求において指定された映像ファイルを再生するために処理すべき単位時間あたりのデータ量を示す第１のレートと、前記要求元からの配信要求を受信した時点において前記映像配信サーバが処理可能な単位時間あたりのデータ量を示す第２のレートとに基づいて、前記処理負荷が基準以上と高くなったか否かを判定することを特徴とする付記１乃至３のいずれかの付記に記載の映像配信サーバ。
（付記５）
前記算出部は、前記要求元からの配信要求において指定された映像ファイルを再生するために処理すべき単位時間あたりのデータ量を示すレートに所定の係数を乗算することで算出した第１のレートと、前記要求元からの配信要求を受信した時点において前記映像配信サーバが処理可能な単位時間あたりのデータ量を示す第２のレートとに基づいて、前記処理負荷が基準以上と高くなったか否かを判定することを特徴とする付記１乃至３のいずれかの付記に記載の映像配信サーバ。
（付記６）
前記所定の係数は、配信要求ごとに決定されることを特徴とする付記５に記載の映像配信サーバ。
（付記７）
前記要求元からの配信要求を受信するごとに、前記映像配信サーバのＣＰＵ使用率が所定の閾値を上回っているか否かを判定する監視部を更に有し、
前記算出部は、前記所定の閾値を上回っていると判定された場合に、前記第１のレートが前記第２のレートを上回っているか否かを判定することを特徴とする付記４乃至６のいずれかの付記に記載の映像配信サーバ。
（付記８）
前記算出部は、前記第１のレートが前記第２のレートを上回っていると判定した場合に、前記処理負荷が基準以上と高くなったと判定することを特徴とする付記７に記載の映像配信サーバ。
（付記９）
要求元からの配信要求に対する処理負荷を算出する算出部と、
前記処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルを、処理負荷が低くなるデータ量の少ない映像ファイルに差し換える変更部と、
前記差し換えた映像ファイルを、前記要求元に対して配信する配信部と
を有することを特徴とする映像配信サーバ。
（付記１０）
コンピュータによる映像配信方法であって、該コンピュータが、
要求元からの配信要求に対する処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換えて、前記要求元に対して、映像ファイルを配信する制御を行うことを特徴とする映像配信方法。
（付記１１）
要求元からの配信要求に対する処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換えて、前記要求元に対して、映像ファイルを配信する制御を行う、
処理を、コンピュータに実行させることを特徴とするプログラム。
（付記１）
要求元からの配信要求に対する処理負荷を算出する算出部と、
前記処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換える変更部と、
前記差し換えた映像ファイルを、前記要求元に対して配信する配信部と
を有することを特徴とする映像配信サーバ。
（付記２）
前記変更部は、予め設定された要求元の優先順位のうち、優先順位の低い要求元から要求された映像ファイルを、優先して差し換えることを特徴とする付記１に記載の映像配信サーバ。
（付記３）
前記変更部は、前記要求元のうち、品質の高い映像ファイルを要求する要求元から要求された映像ファイルを、優先して差し換えることを特徴とする付記１に記載の映像配信サーバ。
（付記４）
前記算出部は、前記要求元からの配信要求において指定された映像ファイルを再生するために処理すべき単位時間あたりのデータ量を示す第１のレートと、前記要求元からの配信要求を受信した時点において前記映像配信サーバが処理可能な単位時間あたりのデータ量を示す第２のレートとに基づいて、前記処理負荷が基準以上と高くなったか否かを判定することを特徴とする付記１乃至３のいずれかの付記に記載の映像配信サーバ。
（付記５）
前記算出部は、前記要求元からの配信要求において指定された映像ファイルを再生するために処理すべき単位時間あたりのデータ量を示すレートに所定の係数を乗算することで算出した第１のレートと、前記要求元からの配信要求を受信した時点において前記映像配信サーバが処理可能な単位時間あたりのデータ量を示す第２のレートとに基づいて、前記処理負荷が基準以上と高くなったか否かを判定することを特徴とする付記１乃至３のいずれかの付記に記載の映像配信サーバ。
（付記６）
前記所定の係数は、配信要求ごとに決定されることを特徴とする付記５に記載の映像配信サーバ。
（付記７）
前記要求元からの配信要求を受信するごとに、前記映像配信サーバのＣＰＵ使用率が所定の閾値を上回っているか否かを判定する監視部を更に有し、
前記算出部は、前記所定の閾値を上回っていると判定された場合に、前記第１のレートが前記第２のレートを上回っているか否かを判定することを特徴とする付記４乃至６のいずれかの付記に記載の映像配信サーバ。
（付記８）
前記算出部は、前記第１のレートが前記第２のレートを上回っていると判定した場合に、前記処理負荷が基準以上と高くなったと判定することを特徴とする付記７に記載の映像配信サーバ。
（付記９）
要求元からの配信要求に対する処理負荷を算出する算出部と、
前記処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルを、処理負荷が低くなるデータ量の少ない映像ファイルに差し換える変更部と、
前記差し換えた映像ファイルを、前記要求元に対して配信する配信部と
を有することを特徴とする映像配信サーバ。
（付記１０）
コンピュータによる映像配信方法であって、該コンピュータが、
要求元からの配信要求に対する処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換えて、前記要求元に対して、映像ファイルを配信する制御を行うことを特徴とする映像配信方法。
（付記１１）
要求元からの配信要求に対する処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換えて、前記要求元に対して、映像ファイルを配信する制御を行う、
処理を、コンピュータに実行させることを特徴とするプログラム。
なお、上記実施形態に挙げた構成等に、その他の要素との組み合わせなど、ここで示した構成に本発明が限定されるものではない。これらの点に関しては、本発明の趣旨を逸脱しない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。
１００ ：映像配信システム
１１０ ：クライアント端末
１２０ ：映像配信サーバ
１３０ ：映像配信プログラム
１４０ ：ストリーミングデータ用ＤＢ
１６０ ：ネットワーク
５０１ ：配信要求受信部
５０２ ：配信負荷算出部
５０３ ：ＣＰＵ使用率監視部
５０４ ：配信レート算出部
５０５ ：配信ファイル変更部
５０６ ：配信部
８１０ ：配信リスト
１５００ ：優先順位リストＤＢ
１１０ ：クライアント端末
１２０ ：映像配信サーバ
１３０ ：映像配信プログラム
１４０ ：ストリーミングデータ用ＤＢ
１６０ ：ネットワーク
５０１ ：配信要求受信部
５０２ ：配信負荷算出部
５０３ ：ＣＰＵ使用率監視部
５０４ ：配信レート算出部
５０５ ：配信ファイル変更部
５０６ ：配信部
８１０ ：配信リスト
１５００ ：優先順位リストＤＢ
Claims (5)
- 要求元からの配信要求に対する処理負荷を算出する算出部と、
前記処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換える変更部と、
前記差し換えた映像ファイルを、前記要求元に対して配信する配信部と
を有することを特徴とする映像配信サーバ。 - 前記変更部は、予め設定された要求元の優先順位のうち、優先順位の低い要求元から要求された映像ファイルを、優先して差し換えることを特徴とする請求項１に記載の映像配信サーバ。
- 前記変更部は、前記要求元のうち、品質の高い映像ファイルを要求する要求元から要求された映像ファイルを、優先して差し換えることを特徴とする請求項１に記載の映像配信サーバ。
- 前記算出部は、前記要求元からの配信要求において指定された映像ファイルを再生するために処理すべき単位時間あたりのデータ量を示す第１のレートと、前記要求元からの配信要求を受信した時点において前記映像配信サーバが処理可能な単位時間あたりのデータ量を示す第２のレートとに基づいて、前記処理負荷が基準以上と高くなったか否かを判定することを特徴とする請求項１乃至３のいずれか１項に記載の映像配信サーバ。
- コンピュータによる映像配信方法であって、該コンピュータが、
要求元からの配信要求に対する処理負荷が基準以上と高くなった場合、前記要求元から要求された品質の映像ファイルに対して、データ量の少ない代替可能な映像ファイルが存在するか確認し、代替可能な映像ファイルが存在する場合に、処理負荷が低くなるデータ量の少ない映像ファイルに差し換えて、前記要求元に対して、映像ファイルを配信する制御を行うことを特徴とする映像配信方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014158834A JP2016036103A (ja) | 2014-08-04 | 2014-08-04 | 映像配信サーバ及び映像配信方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014158834A JP2016036103A (ja) | 2014-08-04 | 2014-08-04 | 映像配信サーバ及び映像配信方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2016036103A true JP2016036103A (ja) | 2016-03-17 |
Family
ID=55523733
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2014158834A Withdrawn JP2016036103A (ja) | 2014-08-04 | 2014-08-04 | 映像配信サーバ及び映像配信方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2016036103A (ja) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2023547287A (ja) * | 2021-09-30 | 2023-11-10 | １７Ｌｉｖｅ株式会社 | ストリーミングをレンダリングするためのシステム、方法、及びコンピュータ可読媒体 |
| JP7421628B1 (ja) | 2022-12-26 | 2024-01-24 | ソフトバンク株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
-
2014
- 2014-08-04 JP JP2014158834A patent/JP2016036103A/ja not_active Withdrawn
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2023547287A (ja) * | 2021-09-30 | 2023-11-10 | １７Ｌｉｖｅ株式会社 | ストリーミングをレンダリングするためのシステム、方法、及びコンピュータ可読媒体 |
| JP7406713B2 (ja) | 2021-09-30 | 2023-12-28 | １７Ｌｉｖｅ株式会社 | ストリーミングをレンダリングするためのシステム、方法、及びコンピュータ可読媒体 |
| JP7421628B1 (ja) | 2022-12-26 | 2024-01-24 | ソフトバンク株式会社 | 情報処理装置、情報処理方法、および情報処理プログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10069885B2 (en) | Bandwidth management for over-the-top adaptive streaming | |
| CN104918072B (zh) | 低延时实况视频流传输 | |
| US9060207B2 (en) | Adaptive video streaming over a content delivery network | |
| US9680889B2 (en) | System and method of managing multiple video players | |
| US9473548B1 (en) | Latency reduction in streamed content consumption | |
| EP2300928B1 (en) | Client side stream switching | |
| JP6442507B2 (ja) | ネットワークのデバイスにより実行される進行中のトラフィックセッションの中でネットワークの利用可能な帯域幅を割り当てる方法、対応するデバイス | |
| US9843825B1 (en) | Distributed and synchronized media switching | |
| CN108965884B (zh) | 一种转码任务的分配方法及调度设备、转码设备 | |
| US20140280760A1 (en) | Playback stall avoidance in adaptive media streaming | |
| JP6419848B2 (ja) | 帯域幅最適化のための適応的データセグメント配信調停 | |
| US8725947B2 (en) | Cache control for adaptive stream player | |
| CN110087141A (zh) | 视频数据传输方法、装置、客户端及服务器 | |
| JP2011172021A (ja) | キャッシュサーバ制御装置、コンテンツ配信システム、コンテンツ配信方法、及びプログラム | |
| EP2583435A1 (en) | Improved peer-to-peer system | |
| CN107920108A (zh) | 一种媒体资源的推送方法、客户端及服务器 | |
| CN109587068B (zh) | 流量切换方法、装置、设备及计算机可读存储介质 | |
| US10609111B2 (en) | Client-driven, ABR flow rate shaping | |
| JP2016036103A (ja) | 映像配信サーバ及び映像配信方法 | |
| JP2009237918A (ja) | 分散型コンテンツ配信システム、センタサーバ、分散型コンテンツ配信方法及び分散型コンテンツ配信プログラム | |
| EP3895352B1 (en) | Method and system for reducing drop-outs during video stream playback | |
| JP2023515003A (ja) | ネットワークでストリーミングされたコンテンツをクライアントデバイスのプレーヤで再生する方法 | |
| US20190190843A1 (en) | Arbitration of competing flows | |
| CN108307206A (zh) | 一种直播编码任务的分配方法及装置 | |
| JP2017225044A (ja) | コンテンツ配信システムのクライアント装置、コンテンツの取得方法及びプログラム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20170511 |
|
| A761 | Written withdrawal of application |
Free format text: JAPANESE INTERMEDIATE CODE: A761 Effective date: 20171225 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20180104 |