JP7222748B2 - 受信装置及び配信サーバ - Google Patents

Description

本発明は、動画の配信システムに関する。

従来、インターネット動画配信に利用されている配信方式としてＨＡＳ（ＨＴＴＰ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ）がある。この配信方式は、予め用意してある複数のビットレートの動画を、それぞれ数秒程度のセグメントに分割し、視聴端末の特性又は回線の混雑状況に応じて適切なセグメントを配信することで、リバッファリングを防ぎユーザ体験を向上させるものである。なお、適切なセグメントとは、視聴端末のバッファが枯渇する前にダウンロード可能で、かつ、最もビットレートの高い、すなわち高画質なセグメントのことである。

ＨＡＳについては、ＭＰＥＧ－ＤＡＳＨ及びＨＬＳ（ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）などの規格が制定されているが、適切なセグメントを取得するロジックは、視聴端末毎に独自実装される。また、複数のビットレートでコンテンツを用意し適切なビットレートで配信する技術は、ＡＢＲ（Ａｄａｐｔｉｖｅ ｂｉｔ Ｒａｔｅ）と呼ばれ、例えば、特許文献１に示されている。

米国特許第７８１８４４４号明細書

ＡＢＲでは、動画の再生が途切れない範囲内で、より高画質なセグメントを視聴端末が取得することによってユーザ体験を向上させることができる。しかしながら、回線の混雑状況によりスループットが一時的に低下した際に、視聴端末は、バッファを枯渇させないために低画質なセグメントを選択し、スループットが回復すると高画質なセグメントを取得するので、この画質の変化がユーザ体験を著しく低下させていた。

本発明は、スループットの低下を抑制し、動画視聴におけるユーザ体験を向上できる受信装置及び配信サーバを提供することを目的とする。

本発明に係る受信装置は、動画を構成するセグメントを順次受信して再生する受信装置であって、前記セグメントを受信した際のスループットから後続のセグメントのスループットの予測値を算出するスループット管理部と、受信した前記セグメントのバッファ量を計測するバッファ量計測部と、前記バッファ量が第１の閾値より多いか、又は前記スループットの予測値が前記セグメントのビットレートより高い場合、標準スライスを介した第１の配信サーバからの受信経路を選択し、前記バッファ量が前記第１の閾値以下で、かつ、前記スループットの予測値が前記セグメントのビットレート以下の場合、前記標準スライスよりも高速な高速スライスを介した第２の配信サーバからの受信経路を選択する経路決定部と、前記経路決定部により決定された受信経路で、前記セグメントを要求する要求部と、を備える。

前記要求部は、前記高速スライスを介した受信経路で前記セグメントを要求する場合、前記セグメントの受信状態を示すパラメータを前記第２の配信サーバへ通知し、当該パラメータに基づく優先度に応じて前記第２の配信サーバから要求拒否の応答を受信すると、前記標準スライスを介した受信経路で前記セグメントを要求してもよい。

前記パラメータは、所定時間内に前記高速スライスから前記セグメントを受信した回数、現在のビットレート、前記スループットの予測値、又は前記バッファ量の少なくともいずれかを含んでもよい。

前記セグメントはそれぞれ、複数のビットレートにより選択的に配信され、前記要求部は、前記第２の配信サーバから要求拒否の応答を受信すると、前記標準スライスを介した受信経路で、前記スループットよりも低いビットレートのうち最も高いビットレートの前記セグメントを要求してもよい。

前記要求部は、前記バッファ量が第１の閾値よりも多く、かつ、前記スループットが現在より高いビットレートよりもさらに高い場合、当該現在よりも高いビットレートの前記セグメントを要求してもよい。

前記要求部は、前記セグメントのビットレートを下げた場合、後続のセグメントの受信を所定回以上行うまで、ビットレートの上昇を抑制してもよい。

前記経路決定部は、前記バッファ量が前記第１の閾値より小さい第２の閾値以下の場合、前記スループットの予測値を現在より小さく補正し、前記高速スライスを介した第２の配信サーバからの受信経路を選択してもよい。

本発明に係る配信装置は、動画を構成するセグメントを受信装置へ配信する配信装置であって、標準スライスを介して前記受信装置へ配信するサーバと共通の前記セグメントを記憶する記憶部と、複数の前記受信装置からの要求を待ち行列で管理し、当該待ち行列の最大長を超える要求を拒否する要求管理部と、前記要求管理部により受け入れられた要求に応じて、前記標準スライスよりも高速な高速スライスを介して前記セグメントを送出する送出部と、を備え、前記要求管理部は、前記受信装置において、前記セグメントのバッファ量が第１の閾値以下で、かつ、前記セグメントを受信した際のスループットに基づく後続のセグメントのスループットの予測値が前記セグメントのビットレート以下の場合に、前記標準スライスを介した受信経路に代えて、前記高速スライスを介した受信経路が選択されると、当該受信装置から、前記セグメントの受信状態を示すパラメータと共に前記要求を受信し、前記パラメータに基づく優先度に応じて、前記待ち行列に格納される前記要求を並べ替える。

前記パラメータは、所定時間内に前記高速スライスから前記セグメントを受信した回数、現在のビットレート、前記スループットの予測値、又は前記バッファ量の少なくともいずれかを含み、前記要求管理部は、前記パラメータの重み付けにより前記優先度を算出してもよい。

前記要求管理部は、前記待ち行列として、先入れ先出しの第１のキューと、前記第１のキューに続く、前記優先度に応じて前記要求が並べ替えられる第２のキューと、を管理してもよい。

前記要求管理部は、前記要求のそれぞれに対応して、前記第２のキューに格納されてからの経過時間を計測し、所定の時間が経過すると、当該要求を前記第１のキューの末尾に追加してもよい。

本発明に係る受信プログラムは、前記受信装置としてコンピュータを機能させるためのものである。

本発明に係る配信プログラムは、前記配信装置としてコンピュータを機能させるためのものである。

本発明によれば、スループットの低下を抑制し、動画視聴におけるユーザ体験を向上できる。

実施形態に係る配信システムの全体構成を示す図である。 実施形態に係る受信装置の機能構成を示す図である。 実施形態に係る配信サーバの機能構成を示す図である。 実施形態に係る受信装置の処理手順を示すフローチャートである。 実施形態に係る配信サーバへ通知するアクセス回数のカウント処理を示すフローチャートである。 実施形態に係る配信サーバにおける要求の受け入れ判定の処理手順を示す図である。 実施形態に係るセグメントの要求発生時における、要求管理部の処理を示すフローチャートである。 実施形態に係るセグメントの要求に対するタイムアウト発生時における、要求管理部の処理を示すフローチャートである。 実施形態に係るセグメントの送出完了時における、要求管理部の処理を示すフローチャートである。

以下、本発明の実施形態の一例について説明する。
オープンインターネット上でのＨＡＳによる動画配信のシステムでは、前述のように、スループットの低下が課題となっていた。ＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）を利用することにより、スループットを向上させることはできるものの、ＵＨＤ（Ｕｌｔｒａ Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）などのリッチなコンテンツが増加傾向にある現状では十分な対策とはならない。そこで、例えば、ＣＤＮよりさらにユーザ（視聴端末）の近くに配信サーバを設置し、低遅延かつ広帯域なネットワークを利用することでスループットを向上させることが考えられるが、このようなネットワークを常時利用すると、配信コストが増加してしまう。

本実施形態では、オープンインターネット上に構築された標準のネットワーク（標準スライス）と、より高速なネットワーク（高速スライス）とを切り替え可能とし、視聴端末は、スループットの低下が検出された際に、一時的に高速スライスを利用してビットレートを維持させる。

図１は、本実施形態に係る配信システム１の全体構成を示す図である。
動画配信用の配信サーバ１０（第１の配信サーバ）は、Ｗｅｂサーバであり、オープンインターネット上に設置される。このとき、ＣＤＮが利用されてもよい。本実施形態では、ＡＢＲによる動画配信を想定し、ビットレートの異なる複数種類のセグメントファイルが配信サーバ１０に配置され、選択的に配信される。なお、ユーザの視聴端末である受信装置３０で実行されるプレーヤを構成するスクリプト類は、別のサーバに配置されてもよい。
配信サーバ１０が設置されるネットワークを標準スライスと呼ぶ。

配信サーバ２０（第２の配信サーバ、配信装置）は、配信サーバ１０よりも受信装置３０とネットワーク的に近い位置に設置され、低遅延かつ広帯域なネットワーク上に設置される。本実施形態では、モバイルキャリア網に配信サーバ２０が設置される構成を例示しているが、これには限られず、例えばモバイル基地局内のネットワークに設置されてもよい。
配信サーバ２０が設置されるネットワークを高速スライスと呼ぶ。

配信サーバ２０には、配信サーバ１０と共通の動画のセグメントファイルが格納され、高速スライスと標準スライスとは、スイッチで結ばれている。受信装置３０から配信サーバ１０又は配信サーバ２０へのアクセスは、例えばＩＰアドレスなどを指定することにより、スイッチを経由して高速スライス又は標準スライスのいずれかのネットワークに振り分けられる。

受信装置３０は、標準的なＨＴＭＬ５プラットフォームを搭載したＷｅｂブラウザを備え、配信サーバ１０又は他のサーバからスクリプト類をダウンロードすることでプレーヤとして機能する。

図２は、本実施形態に係る受信装置３０の機能構成を示す図である。
受信装置３０は、スマートフォン、タブレット端末、パーソナルコンピュータ、テレビなどの情報処理装置であり、制御部が記憶部に格納されたソフトウェア（受信プログラム）を実行することにより、次の各機能部を実現する。
受信装置３０は、データ受信部３０１と、スループット測定部３０２と、スループット管理部３０３と、バッファ管理部３０４と、映像再生部３０５と、バッファ量計測部３０６と、セグメントパス決定部３０７（経路決定部）と、セグメント要求部３０８（要求部）と、セグメント再要求部３０９（要求部）と、アクセス回数管理部３１０とを備える。

データ受信部３０１は、標準スライス又は高速スライスを介して、動画を構成するセグメントデータを順次受信する。

スループット測定部３０２は、データ受信部３０１でセグメントデータを受信した時刻情報を元に、配信サーバ１０からのセグメントデータの受信に掛かった時間を求め、スループットを測定する。

スループット管理部３０３は、スループット測定部３０２により測定された過去のスループットの値から次のセグメントのスループットの予測値を算出し管理する。予測の方法は限定されないが、例えば、直前のスループット値又は過去のスループット値の平均などが予測値として利用されてもよい。

バッファ管理部３０４は、データ受信部３０１で受信されたセグメントデータをバッファに格納し、現在バッファが保持するセグメントデータを管理する。

映像再生部３０５は、バッファ管理部３０４よりセグメントデータを順にロードし、動画をデコードした上で再生する。

バッファ量計測部３０６は、現在バッファが保持している未再生セグメントデータのバッファ量を計測する。

セグメントパス決定部３０７は、バッファ量計測部３０６及びスループット管理部３０３の情報に基づいて、次に要求するセグメントの受信経路を決定する。
具体的には、セグメントパス決定部３０７は、バッファ量が第１の閾値より多いか、又はスループットがセグメントのビットレートより高い場合、標準スライスを介した配信サーバ１０からの受信経路を選択する。一方、バッファ量が第１の閾値以下で、かつ、スループットがセグメントのビットレート以下の場合、セグメントパス決定部３０７は、標準スライスよりも高速な高速スライスを介した配信サーバ２０からの受信経路を選択する。
さらに、セグメントパス決定部３０７は、バッファ量が第１の閾値より小さい第２の閾値以下の場合、スループットの値を現在より小さく補正し、高速スライスを介した配信サーバ２０からの受信経路を選択する。

セグメント要求部３０８は、セグメントパス決定部３０７により決定された標準スライス又は高速スライスを介したセグメントの受信経路に対して次のセグメントを要求する。
高速スライスを介した受信経路でセグメントを要求する場合、セグメントの要求部３０８は、セグメントデータの受信状態を示すパラメータを配信サーバ２０へ通知する。受信状態を示すパラメータは、例えば、所定時間内に高速スライスからセグメントデータを受信した回数であるアクセス回数、現在のビットレート、スループットの予測値、又はバッファ量の少なくともいずれかを含む。
これらのパラメータに基づく優先度に応じて、配信サーバ２０は、後述の処理によりセグメントの要求を受け入れるか拒否するかを判定する。

また、セグメント要求部３０８は、バッファ量が第１の閾値よりも多く、かつ、スループットの予測値が現在要求しているビットレートより高いビットレートと比べても、さらに高い場合、この現在よりも高いビットレートでセグメントを要求する。
ただし、セグメント要求部３０８は、セグメント再要求部３０９により要求するセグメントのビットレートが一旦下げられると、後続のセグメントの受信を所定回以上行うまで、ビットレートの上昇を抑制する。

セグメント再要求部３０９は、配信サーバ２０に通知されたパラメータに基づく優先度に応じてセグメントの要求が拒否され、応答を受信すると、セグメントパス決定部３０７で決定された高速スライスに代えて標準スライスを介して配信サーバ１０にセグメントを再要求する。
この後、セグメント再要求部３０９は、配信サーバ２０から要求拒否の応答を受信すると、標準スライスを介した受信経路で、スループットの予測値よりも低いビットレートのうち最も高いビットレートのセグメントを要求する。

アクセス回数管理部３１０は、配信サーバ２０に対してセグメントを要求し、受信できた回数をカウントし、所定時間当たりの配信サーバ２０に対するアクセス回数を管理する。このアクセス回数は、セグメント要求部３０８に提供され、高速スライスを介したセグメントの要求時に、他のパラメータと共に配信サーバ２０へ通知される。

図３は、本実施形態に係る配信サーバ２０の機能構成を示す図である。
配信サーバ２０は、配信サーバ１０と同様のサーバ装置であり、制御部が記憶部２１に格納されたソフトウェア（配信プログラム）を実行することにより、次の各機能部を実現する。これにより、配信サーバ２０は、受信装置３０からの要求に応じて、動画を構成するセグメントを、高速スライスを介して受信装置３０へ配信する。

配信サーバ２０は、要求管理部２０１と、セグメント送出部２０２とを備える。
また、記憶部２１は、標準スライスを介して受信装置３０へ動画配信する配信サーバ１０と共通のセグメントを記憶する。

要求管理部２０１は、複数の受信装置３０からのセグメントの要求を待ち行列で管理し、この待ち行列の最大長を超える要求を拒否する。
具体的には、要求管理部２０１は、受信装置３０において、バッファ量が第１の閾値以下で、かつ、セグメントを受信する際のスループットの予測値がセグメントのビットレート以下の場合に、標準スライスを介した受信経路に代えて、高速スライスを介した受信経路が選択されると、この受信装置３０からセグメントの要求を受信する。このとき、要求管理部２０１は、受信装置３０におけるセグメントの受信状態を示すパラメータと共に要求を受信し、これらのパラメータに基づいて、待ち行列に格納される要求を並べ替える。

待ち行列は、先入れ先出しの第１のキューと、第１のキューに続く、パラメータに基づく優先度に応じて要求が並べ替えられる第２のキューとを含む。
要求管理部２０１は、要求のそれぞれに対応して、第２のキューに格納されてからの経過時間を計測し、所定の時間が経過すると、この要求を第１のキューの末尾に追加する。

セグメント送出部２０２は、要求管理部２０１により受け入れられた要求に応じて、標準スライスよりも高速な高速スライスを介して受信装置３０へセグメントを送出する。

図４は、本実施形態に係る受信装置３０の処理手順を示すフローチャートである。
受信装置３０は、この処理により、セグメントの受信経路及び要求するビットレートを決定する。

ステップＳ１において、受信装置３０は、ｍ３ｕ８又はｍｐｄなどのマニフェストファイル、及び初期化セグメントなどの初期化ファイルを取得し、プレーヤの初期化を行う。次に、セグメント要求部３０８は、動画のセグメントをバッファリングが完了するまで順次要求する。
このとき取得するセグメントのビットレートは限定されず、既定の初期値又は最高値などであってよい。また、初めにセグメントを要求する先は、標準スライスを介した配信サーバ１０、又は高速スライスを介した配信サーバ２０のいずれでもよい。例えば、配信サーバ２０から高速に取得することで、受信装置３０は、動画の再生が開始されるまでの待ち時間を短縮できる。

ステップＳ２において、バッファリングが完了すると、映像再生部３０５は、動画の再生を開始する。

ステップＳ３において、データ受信部３０１は、標準スライスの配信サーバ１０からビットレートがＳ［ｉ］のセグメントを取得する。
ここで、配信サーバ１０及び２０に用意されるセグメントのビットレートは、高い順にＳ［Ｈ］，・・・，Ｓ［ｉ］，・・・，Ｓ［０］とする。

ステップＳ４において、スループット測定部３０２は、ステップＳ３でセグメントの取得にかかった時間、及びセグメントサイズからスループットを測定し、スループット管理部３０３は、後続のセグメントのスループットの予測値ＴＰを更新する。

ステップＳ５において、バッファ量計測部３０６は、動画再生によりバッファから消費したセグメント及び取得したセグメントから現在のバッファ量を更新する。

ステップＳ６において、受信装置３０は、ビットレートが低下して以降のセグメントの受信回数を示すパラメータＳＨをインクリメントする。ＳＨの初期値は定数ＳＨ＿０であり、画質が低下した際にＳＨ＝０となる。ＳＨ≦ＳＨ＿０（例えば８）の場合に画質（ビットレート）を向上させないようにすることで、画質が頻繁に切り替わることが抑制される。

ステップＳ７において、セグメントパス決定部３０７は、バッファ量がＮセグメント（第１の閾値）より多いか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ８に移り、判定がＮＯの場合、処理はステップＳ１０に移る。
ここで、Ｎと後述のＭとは、Ｎ＞Ｍ＞０の関係にあり、バッファ量がＮ（例えば８）より多ければバッファが十分にあることを示し、Ｍ（例えば２）以下であればバッファが枯渇し動画の再生が停止する可能性がある状態を示す。

ステップＳ８において、セグメント要求部３０８は、スループットＴＰとビットレートＳ［ｉ＋１］とを比較し、ＴＰ＞Ｓ［ｉ＋１］かつＳＨ＞ＳＨ＿０の条件を満たすか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ９に移り、判定がＮＯの場合、処理はステップＳ３に移る。

ステップＳ９において、セグメント要求部３０８は、バッファ量とスループットは十分に余裕があると判断し、ｉをインクリメントして、よりビットレートの高いセグメントを、標準スライスを介して要求する。その後、処理はステップＳ３に移る。

ステップＳ１０において、セグメントパス決定部３０７は、バッファ量がＭセグメント（第２の閾値）以下か否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１１に移り、判定がＮＯの場合、処理はステップＳ１２に移る。

ステップＳ１１において、セグメントパス決定部３０７は、バッファが枯渇し、再生が停止する可能性があると判断し、スループットの予測値ＴＰを小さく、例えば半分に補正することで、要求するセグメントのビットレートを下げてでもバッファ量を増加させるよう動作する。その後、処理はステップＳ１３に移る。

ステップＳ１２において、セグメントパス決定部３０７は、スループットの予測値ＴＰよりも高い、すなわちＴＰ＞Ｓ［ｉ］であるか否かを判定する。この判定がＹＥＳの場合、受信経路及びビットレートは標準スライスのまま維持され、処理はステップＳ３に移る。一方、判定がＮＯ、すなわちＴＰ≦Ｓ［ｉ］の場合、処理はステップＳ１３に移る。

ステップＳ１３において、セグメント要求部３０８は、高速スライスを介して配信サーバ２０に対して、受信状態を示すパラメータを通知すると共にビットレートＳ［ｉ］のセグメントを要求する。そして、受信装置３０は、配信サーバ２０において要求が受け入れられたか否か、すなわち高速スライスからセグメントを取得できるか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ１４に移る。一方、判定がＮＯの場合、すなわち要求が拒否された場合、処理はステップＳ１５に移る。

ステップＳ１４において、データ受信部３０１は、配信サーバ２０から高速スライスを介してビットレートＳ［ｉ］のセグメントを取得する。これにより、バッファ量の減少が抑制され、ビットレートを下げずに映像再生部３０５が動画の再生を継続できる。その後、処理はステップＳ５に移る。

ステップＳ１５において、セグメント再要求部３０９は、スループットの予測値に基づいて、動画の再生を止めることなく次のセグメントを取得できるビットレートを決定する。具体的には、セグメント再要求部３０９は、例えば、ビットレートを１段階ずつ下げたとき、初めてスループットの予測値ＴＰを下回るビットレートＳ［ｉ－ｋ］を決定する。

ステップＳ１６において、受信装置３０は、ビットレートの順位ｉをｉ－ｋに更新すると共に、パラメータＳＨを０に更新し、ビットレートが下がったことを保持しておく。その後、処理はステップＳ３に移る。

図５は、本実施形態に係る配信サーバ２０へ通知するアクセス回数のカウント処理を示すフローチャートである。
ここで、配列Ｔ［］には、本処理の結果として、過去に配信サーバ２０からセグメントを取得した時刻が新しい順に格納されているものとする。

ステップＳ２１において、アクセス回数管理部３１０は、配信サーバ２０への要求が発生した時刻Ｔ＿ＮＯＷを計測する。

ステップＳ２２において、アクセス回数管理部３１０は、配列Ｔ［］の要素のうち、時刻Ｔ＿ＮＯＷとの時刻差が所定の時間Ｔ０（例えば１０秒）以内のものをカウントし、アクセス回数Ｃを決定する。具体的には、アクセス回数管理部３１０は、Ｔ＿ＮＯＷ－Ｔ［Ｃ］＞Ｔ０となるまでＣをカウントアップしていくことでＣを決定できる。

ステップＳ２３において、セグメント要求部３０８は、配信サーバ２０に対してセグメントの要求と共にアクセス回数Ｃを含むパラメータを送信し、配信サーバ２０において要求が受け入れられると、処理はステップＳ２４に移る。

ステップＳ２４において、データ受信部３０１は、配信サーバ２０からセグメントデータを受信する。

ステップＳ２５において、アクセス回数管理部３１０は、セグメントデータを取得した時刻を計測し、配列Ｔ［］の先頭Ｔ［０］に追加することでリスト化する。

図６は、本実施形態に係る配信サーバ２０における要求の受け入れ判定の処理手順を示す図である。
要求管理部２０１は、セグメント送出用の待ち行列ｑｕｅ＿Ａ（第１のキュー）と、ｑｕｅ＿Ａへ追加するための待ち行列ｑｕｅ＿Ｂ（第２のキュー）とを用意する。

ｑｕｅ＿Ａに追加された要求は受け入れられたものとみなされ、追加された順に先入れ先出しでセグメント送出部２０２により処理される。
ｑｕｅ＿Ｂは、要求を一時的に保持する待ち行列であり、ｑｕｅ＿Ａに空きができると先頭から順にｑｕｅ＿Ａへ追加される。ただし、ｑｕｅ＿Ｂの最大長まで要求が保持されている場合、新たに要求を受けると、優先度の低い要求が拒否されｑｕｅ＿Ｂから消去される。

優先度Ｐは、セグメントの要求と共に受信した、アクセス回数Ｃ、ビットレートＳ［ｉ］、スループットの予測値ＴＰ、バッファ量ＢＦなどのパラメータと、予め定義される各パラメータに対する重み係数Ｗとによって、例えば次のように定義される。
Ｐ＝Ｗ１×Ｃ＋Ｗ２×ＢＦ＋Ｗ３×（Ｓ［ｉ］／ＴＰ）＋Ｗ［ｉ］×Ｓ［ｉ］
ここで、Ｗ１はアクセス回数Ｃ、Ｗ２はバッファ量ＢＦ、Ｗ３はスループットＴＰに対するビットレートＳ［ｉ］の割合、Ｗ［ｉ］は各ビットレートＳ［ｉ］に対する重み係数である。
これらの重み係数Ｗを調整することにより、各パラメータの効果の比率を調整することができる。例えば、Ｗ１＝１、Ｗ２＝０、Ｗ３＝０、Ｗ［ｉ］＝０に設定することで、アクセス回数Ｃが少ないものほど優先度Ｐを高くすることができる。

セグメントの要求、要求のタイムアウト、及びセグメントの送出完了の各イベント発生時における、要求管理部２０１の処理を以下に示す。

図７は、本実施形態に係るセグメントの要求発生時における、要求管理部２０１の処理を示すフローチャートである。

ステップＳ３１において、要求管理部２０１は、ｑｕｅ＿Ａの要素数が所定値ＱＡＬ未満か否かを判定する。この判定がＹＥＳの場合、処理はステップＳ３２に移り、判定がＮＯの場合、処理はステップＳ３３に移る。

ステップＳ３２において、要求管理部２０１は、ｑｕｅ＿Ａに空きがあるため、ｑｕｅ＿Ａの末尾に要求を追加する。

ステップＳ３３において、要求管理部２０１は、ｑｕｅ＿Ａに空きがないため、要求をｑｕｅ＿Ｂに追加する。

ステップＳ３４において、要求管理部２０１は、ｑｕｅ＿Ｂに新たに追加した要求に対してタイマ（例えば５０ｍｓｅｃ）を設定する。なお、このタイマによるタイムアウトイベント発生時の処理については後述する。

ステップＳ３５において、要求管理部２０１は、ｑｕｅ＿Ｂに格納された要求を、優先度Ｐによりソートする。これにより、最も優先度Ｐが高い要求がｑｕｅ＿Ａに続く先頭に格納される。なお、優先度Ｐが同じ場合、新しい要求が後ろに配置されてよい。

ステップＳ３６において、要求管理部２０１は、ｑｕｅ＿Ｂの要素数が所定値ＱＢＬを超えたか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ３７に移り、判定がＮＯの場合、処理は終了する。

ステップＳ３７において、要求管理部２０１は、ｑｕｅ＿Ｂの末尾の要求を消去し、この要求に対して設定されたタイマも解除する。

ステップＳ３８において、要求管理部２０１は、ｑｕｅ＿Ｂから消去した要求を拒否した旨の応答を受信装置３０へ返信する。

図８は、本実施形態に係るセグメントの要求に対するタイムアウト発生時における、要求管理部２０１の処理を示すフローチャートである。

ステップＳ４１において、要求管理部２０１は、ｑｕｅ＿Ｂにおいてタイムアウトが発生した要求を消去する。

ステップＳ４２において、要求管理部２０１は、ｑｕｅ＿Ｂでタイムアウトが発生し消去した要求をｑｕｅ＿Ａの末尾に追加する。これにより、長期間にわたってｑｕｅ＿Ａに追加されず、かつ、拒否もされなかった要求が受け入れられる。

図９は、本実施形態に係るセグメントの送出完了時における、要求管理部２０１の処理を示すフローチャートである。

ステップＳ５１において、要求管理部２０１は、セグメント送出部２０２によりｑｕｅ＿Ａの先頭の要求に対するセグメントの送出が完了すると、この要求をｑｕｅ＿Ａから消去する。

ステップＳ５２において、要求管理部２０１は、ｑｕｅ＿Ａの要素数がＱＡＬ未満になったか否かを判定する。この判定がＹＥＳの場合、処理はステップＳ５３に移り、判定がＮＯの場合、処理は終了する。

ステップＳ５３において、要求管理部２０１は、ｑｕｅ＿Ａの末尾に、ｑｕｅ＿Ｂの先頭にある要求を追加する。

ステップＳ５４において、要求管理部２０１は、ｑｕａ＿Ａに追加した要求を、ｑｕｅ＿Ｂから消去する。

本実施形態によれば、配信システム１において、受信装置３０は、バッファ量、及び標準スライスを介した配信サーバ１０に対するスループットの予測値に基づいて、次に要求するセグメントの受信経路を決定する。このとき、バッファ量が十分か、又はスループットの予測値が十分に高ければ、受信装置３０は、標準スライスを介して配信サーバ１０からセグメントを取得する。一方、バッファ量が第１の閾値を下回り、かつ、スループットの予測値が十分でない場合に、受信装置３０は、高速スライスを介して配信サーバ２０にセグメントを要求する。

したがって、受信装置３０は、一時的にインターネットが混雑した場合に、高速スライスからセグメントを受信することでスループットの低下を抑制できる。これにより、受信装置３０は、ビットレート変動による画質の劣化、及びリバッファリングによる再生の停止を抑止できるので、高画質な動画再生を維持して動画視聴におけるユーザ体験を向上できる。
特に、ＵＨＤ又はＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）などのリッチなコンテンツ、あるいは、ライブ配信において低遅延化のためにバッファ量を少なく設定しているときに有効である。

高速スライスに配置された配信サーバ２０は、現在の処理待ちの要求数と、要求元の受信装置３０から通知されたパラメータに基づく優先度とに基づいて、要求を受け入れてセグメントを配信するか拒否するかを決定する。
したがって、配信サーバ２０は、高速スライスを介した配信サーバ２０の利用頻度が高いなど、パラメータに基づく優先度が低い受信装置３０からの要求を混雑状況に応じて拒否でき、これにより、複数の受信装置３０が公平に高速スライスを利用できる。この結果、配信システム１は、高速スライスのパフォーマンスを維持しつつ、複数の受信装置３０全体としてユーザ体験を向上させることができる。

このとき、配信サーバ２０は、パラメータとしてアクセス回数、現在のビットレート、スループットの予測値、バッファ量と、複数の重み係数とを用いた計算式により優先度Ｐを算出する。
これにより、配信サーバ２０は、重み係数を調整することで、アクセス回数の少ない受信装置３０、バッファ量が少ない受信装置３０、ビットレートに対してスループットが低い受信装置３０、特定のビットレートを要求する受信装置３０など、優先的に配信する受信装置３０を調整しつつ、全体のバッファの枯渇を抑制できる。
なお、重み係数は、受信装置３０の数、高速スライスの性能、予め用意する各セグメントのビットレートなどに応じて適宜に設定されてよく、これにより、配信事業者の希望に適した配信動作が実現される。

また、配信サーバ２０は、待ち行列として、受け入れ済みの要求が先入れ先出しで格納される第１のキューと、第１のキューに続く、優先度で並べ替えられる第２のキューとを用いる。
これにより、配信サーバ２０は、要求に対する応答の遅延を抑制しつつ、適切な優先順位によりセグメントを配信できる。

さらに、配信サーバ２０は、第２のキューに格納した要求に対しては、それぞれタイマを設定し、所定時間を経過した要求を第１のキューの末尾に追加する。
これにより、配信サーバ２０は、長時間にわたって処理されず、かつ、拒否もされない要求が待ち行列に残されて応答が遅延する事態を抑制できる。

また、配信サーバ２０から要求を拒否された受信装置３０は、標準スライスを介して配信サーバ１０からセグメントを取得することで、セグメントの取得を継続できる。
このとき、受信装置３０は、スループットに応じて前回よりも低いビットレートのセグメントを要求することで、バッファの枯渇を防ぎ、動画の再生が停止する事態を抑制できる。

受信装置３０は、バッファ量が十分にあり、かつ、現在より高いビットレートでもスループットに余裕がある場合、要求するビットレートを上げることで、より高画質な動画を再生できる。
また、受信装置３０は、ビットレートを下げた後は、後続のセグメントの受信を所定回以上行うまでビットレートを上げないことにより、ビットレートの頻繁な変動を抑制し、動画視聴におけるユーザ体験を向上できる。

さらに、受信装置３０は、バッファ量が第２閾値以下の場合、スループットの予測値を現在よりも小さく補正することで、受信するセグメントのビットレートを低く抑え、バッファの枯渇による動画再生の停止を抑制できる。

本実施形態では、主に配信システム１の構成と動作について説明したが、本発明はこれに限られず、各構成要素を備え、動画を配信するための方法、又はプログラムとして構成されてもよい。

さらに、配信システム１の機能を実現するためのプログラムをコンピュータで読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。

ここでいう「コンピュータシステム」とは、ＯＳや周辺機器などのハードウェアを含むものとする。また、「コンピュータで読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ－ＲＯＭなどの可搬媒体、コンピュータシステムに内蔵されるハードディスクなどの記憶装置のことをいう。

さらに、「コンピュータで読み取り可能な記録媒体」とは、インターネットなどのネットワークや電話回線などの通信回線を介してプログラムを送信する場合の通信線のように、短時刻の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時刻プログラムを保持しているものも含んでもよい。また、上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよい。

１ 配信システム
１０ 第１の配信サーバ
２０ 第２の配信サーバ（配信装置）
２１ 記憶部
３０ 受信装置
２０１ 要求管理部
２０２ セグメント送出部
３０１ データ受信部
３０２ スループット測定部
３０３ スループット管理部
３０４ バッファ管理部
３０５ 映像再生部
３０６ バッファ量計測部
３０７ セグメントパス決定部（経路決定部）
３０８ セグメント要求部（要求部）
３０９ セグメント再要求部（要求部）
３１０ アクセス回数管理部

Claims (13)

1. 動画を構成するセグメントを順次受信して再生する受信装置であって、
   前記セグメントを受信した際のスループットから後続のセグメントのスループットの予測値を算出するスループット管理部と、
   受信した前記セグメントのバッファ量を計測するバッファ量計測部と、
   前記バッファ量が第１の閾値より多いか、又は前記スループットの予測値が前記セグメントのビットレートより高い場合、標準スライスを介した第１の配信サーバからの受信経路を選択し、前記バッファ量が前記第１の閾値以下で、かつ、前記スループットの予測値が前記セグメントのビットレート以下の場合、前記標準スライスよりも高速な高速スライスを介した第２の配信サーバからの受信経路を選択する経路決定部と、
   前記経路決定部により決定された受信経路で、前記セグメントを要求する要求部と、を備える受信装置。
2. 前記要求部は、前記高速スライスを介した受信経路で前記セグメントを要求する場合、前記セグメントの受信状態を示すパラメータを前記第２の配信サーバへ通知し、当該パラメータに基づく優先度に応じて前記第２の配信サーバから要求拒否の応答を受信すると、前記標準スライスを介した受信経路で前記セグメントを要求する請求項１に記載の受信装置。
3. 前記パラメータは、所定時間内に前記高速スライスから前記セグメントを受信した回数、現在のビットレート、前記スループットの予測値、又は前記バッファ量の少なくともいずれかを含む請求項２に記載の受信装置。
4. 前記セグメントはそれぞれ、複数のビットレートにより選択的に配信され、
   前記要求部は、前記第２の配信サーバから要求拒否の応答を受信すると、前記標準スライスを介した受信経路で、前記スループットよりも低いビットレートのうち最も高いビットレートの前記セグメントを要求する請求項２又は請求項３に記載の受信装置。
5. 前記要求部は、前記バッファ量が第１の閾値よりも多く、かつ、前記スループットが現在より高いビットレートよりもさらに高い場合、当該現在よりも高いビットレートの前記セグメントを要求する請求項４に記載の受信装置。
6. 前記要求部は、前記セグメントのビットレートを下げた場合、後続のセグメントの受信を所定回以上行うまで、ビットレートの上昇を抑制する請求項５に記載の受信装置。
7. 前記経路決定部は、前記バッファ量が前記第１の閾値より小さい第２の閾値以下の場合、前記スループットの予測値を現在より小さく補正し、前記高速スライスを介した第２の配信サーバからの受信経路を選択する請求項４から請求項６のいずれかに記載の受信装置。
8. 動画を構成するセグメントを受信装置へ配信する配信装置であって、
   標準スライスを介して前記受信装置へ配信するサーバと共通の前記セグメントを記憶する記憶部と、
   複数の前記受信装置からの要求を待ち行列で管理し、当該待ち行列の最大長を超える要求を拒否する要求管理部と、
   前記要求管理部により受け入れられた要求に応じて、前記標準スライスよりも高速な高速スライスを介して前記セグメントを送出する送出部と、を備え、
   前記要求管理部は、
   前記受信装置において、前記セグメントのバッファ量が第１の閾値以下で、かつ、前記セグメントを受信した際のスループットに基づく後続のセグメントのスループットの予測値が前記セグメントのビットレート以下の場合に、前記標準スライスを介した受信経路に代えて、前記高速スライスを介した受信経路が選択されると、当該受信装置から、前記セグメントの受信状態を示すパラメータと共に前記要求を受信し、
   前記パラメータに基づく優先度に応じて、前記待ち行列に格納される前記要求を並べ替える配信装置。
9. 前記パラメータは、所定時間内に前記高速スライスから前記セグメントを受信した回数、現在のビットレート、前記スループットの予測値、又は前記バッファ量の少なくともいずれかを含み、
   前記要求管理部は、前記パラメータの重み付けにより前記優先度を算出する請求項８に記載の配信装置。
10. 前記要求管理部は、前記待ち行列として、先入れ先出しの第１のキューと、前記第１のキューに続く、前記優先度に応じて前記要求が並べ替えられる第２のキューと、を管理する請求項８又は請求項９に記載の配信装置。
11. 前記要求管理部は、前記要求のそれぞれに対応して、前記第２のキューに格納されてからの経過時間を計測し、所定の時間が経過すると、当該要求を前記第１のキューの末尾に追加する請求項１０に記載の配信装置。
12. 請求項１から請求項７のいずれかに記載の受信装置としてコンピュータを機能させるための受信プログラム。
13. 請求項８から請求項１１のいずれかに記載の配信装置としてコンピュータを機能させるための配信プログラム。

Images