JP6466870B2 - クライアント装置および方法 - Google Patents

Description

本発明は、クライアント装置および方法に関する。

近年、オンライン動画配信サービスにおいてＤＡＳＨ（dynamic adaptive streaming over hyper transfer protocol）型配信に代表される配信ビットレートを動的に変更する配信形態が広く採用されている。本方式によれば、予めあるコンテンツについて、異なる品質（ビットレート）のデータを用意し、かつ、セグメント単位に分割しておくことで、ネットワーク状況に応じて最適かつ最高の品質のコンテンツを要求できるようになる。具体的には、コンテンツビットレートと直近で計測したスループットの指標とが比較され、スループットを超えない範囲のビットレートのセグメントファイルが要求される。例えば、非特許文献１には、セグメントの再生時間を実際に同セグメントの受信に要した時間で除して、その値が予め設定されたしきい値以上であれば、要求するビットレートを一段階上げ、逆の場合は下げる技術が開示されている。

MMSys'11 - Proceedings of the 2011 ACM Multimedia Systems Conference, 2011, p. 169-174

しかしながら、非特許文献１に記載されるような方法では、コンテンツビットレートとスループットとを比較するロジックは固定されているので、受信装置がおかれた実環境を考慮することができない。つまり、実際にはスループットの急激な変動が発生する状況であっても、スループットの変動が安定的である状況であっても、用いられるロジックは同一となる。前者の状況の例は、端末が移動して頻繁にハンドオーバが行われる状況である。ハンドオーバにおいては、基地局のインタフェースの変化および端末登録期間のデータ通信停止が瞬間的に発生するので、スループットが急激に変動しうる。

このため、例えばスループットが変動しやすい状況において要求するビットレートが早く上がってしまうと、予期せぬバッファアンダーフローが起こる蓋然性が高くなる。また、逆に、スループットが変動しづらい状況であっても要求するビットレートが早く上がるということはなく、ユーザが体感する品質の低下につながりうる。このように、非特許文献１に記載されるような従来の方法では、パフォーマンス面で不十分となる虞がある。

本発明はこうした課題に鑑みてなされたものであり、その目的は、クライアント装置の状況やコンテンツの属性に応じて、要求するセグメントのビットレートを最適化することができる技術の提供にある。

本発明のある態様はクライアント装置に関する。このクライアント装置は、複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、クライアント装置の状況およびコンテンツの属性のうちの少なくともひとつに基づいて更新する更新部と、更新部によって更新された基準にしたがいビットレートを決定する決定部と、を備える。

なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、コンピュータプログラム、コンピュータプログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。

本発明によれば、クライアント装置の状況やコンテンツの属性に応じて、要求するセグメントのビットレートを最適化することができる。

実施の形態に係るクライアント装置を備える配信システムの機能および構成を示すブロック図である。 図１のＤＡＳＨサーバに保持されるコンテンツの説明図である。 図１のハンドオーバ情報保持部の一例を示すデータ構造図である。 図１のスループット保持部の一例を示すデータ構造図である。 図１の配信システムにおける一連の処理を示すタイムチャートである。 図５の第３ビットレート決定処理の流れを示すフローチャートである。

以下、各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。また、各図面において説明上重要ではない部材の一部は省略して表示する。

図１は、実施の形態に係るクライアント装置１０６を備える配信システム１００の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（Central Processing Unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。

配信システム１００は、ＤＡＳＨサーバ１０２と、インターネットなどのネットワーク１０４を介してＤＡＳＨサーバ１０２と接続されたクライアント装置１０６と、を備える。ＤＡＳＨサーバ１０２は、映画やアニメーションや他の動画像などのコンテンツを保持し、クライアント装置１０６からの要求に応じてストリーミング形式で配信する。クライアント装置１０６は携帯電話やタブレット端末、スマートフォン、デスクトップＰＣ（Personal Computer）、ノートＰＣ等であってもよいが、本実施の形態ではクライアント装置１０６は基地局や無線アクセスポイントを介してネットワーク１０４に無線で接続される携帯端末であるとする。

図２は、ＤＡＳＨサーバ１０２に保持されるコンテンツの説明図である。ＤＡＳＨサーバ１０２はひとつのコンテンツを複数のビットレート（符号化速度）で保持する。複数のビットレートは３００ｋｂｐｓ、１．２Ｍｂｐｓ、５Ｍｂｐｓを含むがこれらに限定されない。ＤＡＳＨサーバ１０２では、ひとつのコンテンツはＮ個（Ｎは２以上の自然数）のセグメントに分割される。各セグメントは所定の再生長またはデータ量に対応する。本実施の形態ではセグメントは３秒、５秒、１０秒のいずれかの再生長に対応するものとする。ただしこれらに限定されない。各セグメントには複数のビットレートのそれぞれに対応するセグメントファイルが存在する。

図２には、３秒の再生長でＮ個のセグメントに分割されたコンテンツが示される。すなわちこのコンテンツの総再生長は３・Ｎ秒となる。各セグメントについて、ビットレートが高いほどセグメントファイルのデータ量は多くなる。図２に示されるように、ＤＡＳＨサーバ１０２にはセグメントごとに異なるビットレートのデータが用意されており、セグメントごとに異なるビットレートを指定可能となっている。例えば、セグメント１については３００ｋｂｐｓのセグメントファイル２０２、セグメント２については１．２Ｍｂｐｓのセグメントファイル２０４、セグメント３については５Ｍｂｐｓのセグメントファイル２０６、がそれぞれ指定され、クライアント装置１０６に配信されてもよい。ビットレートの指定はクライアント装置１０６からのセグメントの要求に含まれる。

図１に戻り、クライアント装置１０６はコンテンツをネットワーク１０４を介して取得する。クライアント装置１０６は受信したデータをバッファしつつ既にバッファされているデータを順次再生する。ここで、データの再生にデータの蓄積が追いつかず、データの「残量」すなわちクライアント装置１０６にダウンロードされバッファに格納されたデータであってまだ再生の用に供されていないデータの量が無くなってしまうことをバッファアンダーフローという。バッファアンダーフローが生じると再生が途切れ途切れになるなどユーザ体験が劣化しうる。

バッファアンダーフローを抑制または除去するために、クライアント装置１０６はコンテンツの受信速度すなわちスループットの指標（スループットそのものやスループットを示す他のパラメータ）を、セグメントを受信するたびに算出する。クライアント装置１０６は、算出された指標が基準を満たせば次に要求するセグメントについて指定するビットレートを変更する。本実施の形態では、クライアント装置１０６はこの基準を通信環境やバッファの状況、コンテンツの属性に応じて動的に更新する。これにより、固定的な基準を使用する場合と比較して、スループットの急な変動に起因するバッファアンダーフローが起こりにくい配信システムを実現できる。特に、セグメントの再生長と同程度の周期のスループットの変動に起因するバッファアンダーフローを抑制することができる。または、スループットの変動があまりない場合はより早い段階でより高品質なコンテンツの再生が可能となり、ユーザ体験が向上する。

クライアント装置１０６は、ＨＴＴＰアクセスクライアント１０８と、メディアエンジン１１０と、制御エンジン１１２と、ディスプレイ１１４と、ハンドオーバ検知部１１６と、ユーザ操作受付部１１８と、ハンドオーバ情報保持部１２０と、ＭＰＤ保持部１２２と、スループット保持部１２４と、を備える。

ＨＴＴＰアクセスクライアント１０８はＨＴＴＰアクセス用のクライアントであり、ネットワーク１０４とのインタフェースとして機能する。ＨＴＴＰアクセスクライアント１０８はネットワーク１０４を介してクライアント装置１０６宛に送られてきたデータを受信して他の部材に提供すると共に、他の部材から送信対象のデータを取得してネットワーク１０４に送信する。

メディアエンジン１１０はクライアント装置１０６が受信したコンテンツを再生するための復号等の処理を行い、ディスプレイ１１４にコンテンツを表示させる。メディアエンジン１１０は受信したコンテンツのセグメントファイルを保持するためのバッファ１３６を含む。ＤＡＳＨサーバ１０２から送信されたセグメントファイルはネットワーク１０４を介してＨＴＴＰアクセスクライアント１０８で受信され、ＨＴＴＰアクセスクライアント１０８からメディアエンジン１１０に送信され、メディアエンジン１１０においてバッファ１３６に格納される。また、メディアエンジン１１０は再生対象のセグメントファイルをバッファ１３６から読み出して処理し、ディスプレイ１１４に表示させる。

ハンドオーバ検知部１１６はクライアント装置１０６とネットワーク１０４との間の無線接続におけるハンドオーバを検知し、検知結果をハンドオーバ情報保持部１２０に登録する。ハンドオーバ検知部１１６は、周期的に、例えば所定の間隔ΔＴごとに、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を呼び出して現在接続している基地局の基地局ＩＤを取得する。ハンドオーバ検知部１１６は、取得された基地局ＩＤと、該基地局ＩＤを取得した時刻と、を対応付けてハンドオーバ情報保持部１２０に登録する。さらにハンドオーバ検知部１１６は、ハンドオーバ情報保持部１２０を参照し、今回登録した基地局ＩＤとその直前の基地局ＩＤとを比較し、それらが異なっていればハンドオーバが発生したと判定する。ハンドオーバが発生したと判定された場合、ハンドオーバ検知部１１６はハンドオーバが有った旨をハンドオーバ情報保持部１２０に登録する。

ハンドオーバの検知間隔ΔＴとセグメントの再生長とは対応してもしなくてもよい。また、ハンドオーバ検知部１１６は、間隔ΔＴを使用する代わりに、セグメントが受信されるごとにハンドオーバを検知してもよい。

図３は、ハンドオーバ情報保持部１２０の一例を示すデータ構造図である。ハンドオーバ情報保持部１２０は、基地局ＩＤが取得された時刻と、基地局ＩＤと、ハンドオーバの有無を示す情報と、を対応付けて保持する。時刻「１３：０２：２６」のエントリについて、基地局ＩＤは「ｘｘｘ」であり、直前（時刻「１３：０２：２５」）の基地局ＩＤも「ｘｘｘ」であるから、ハンドオーバ検知部１１６はハンドオーバが発生しなかったと判定し、該エントリのハンドオーバの有無に「Ｎ」を登録する。時刻「１３：０２：２７」のエントリについて、基地局ＩＤは「ｙｙｙ」であり、直前（時刻「１３：０２：２６」）の基地局ＩＤは「ｘｘｘ」であり異なっているから、ハンドオーバ検知部１１６はハンドオーバが発生したと判定し、該エントリのハンドオーバの有無に「Ｙ」を登録する。

図１に戻り、ユーザ操作受付部１１８は不図示のタッチパネル等の入力装置と接続され、ユーザから再生対象のコンテンツの指定を受け付ける。ユーザ操作受付部１１８は、コンテンツの再生に関するユーザ操作、例えばコンテンツの再生開始や再生停止の指示、を受け付ける。

制御エンジン１１２はＤＡＳＨサーバ１０２からのコンテンツの受信を制御する。制御エンジン１１２は再生対象のコンテンツのメタファイルであるＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルをＤＡＳＨサーバ１０２に要求し、ＤＡＳＨサーバ１０２から取得し、ＭＰＤ保持部１２２に登録する。ＭＰＤファイルはコンテンツについての情報を含み、例えばセグメントの再生長や各セグメントについて指定可能なビットレートやＤＲＭ（Ｄｉｇｉｔａｌ Ｒｉｇｈｔｓ Ｍａｎａｇｅｍｅｎｔ）についての情報や符号化方式についての情報を含む。ＭＰＤファイルは例えばＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）に準拠してもよい。

制御エンジン１１２は、ＭＰＤ保持部１２２に保持されるＭＰＤファイルを解析し、解析結果に基づいて次に要求するセグメントについて指定するビットレートを決定する。クライアント装置１０６におけるスループットの指標から次に要求するセグメントのビットレートを決定するための基準を決定基準と称す。制御エンジン１１２は、セグメントが受信されるごとに決定基準を更新する。制御エンジン１１２は、セグメント要求部１２６と、指標算出部１２８と、変動係数算出部１３０と、しきい値更新部１３２と、ビットレート決定部１３４と、を含む。

セグメント要求部１２６は、ビットレート決定部１３４によって決定されたビットレートを指定して次のセグメントを、ネットワーク１０４を介してＤＡＳＨサーバ１０２に要求する。セグメント要求部１２６は、要求する次のセグメントのＩＤと該セグメントについて指定するビットレートとを含むセグメント要求信号を生成し、ＨＴＴＰアクセスクライアント１０８およびネットワーク１０４を介してＤＡＳＨサーバ１０２に送信する。ＤＡＳＨサーバ１０２は、受信したセグメント要求信号で指定されるビットレートのセグメントファイルをクライアント装置１０６に送信する。バッファ１３６はＤＡＳＨサーバ１０２から送信されたセグメントファイルを保持する。

指標算出部１２８は現在のスループットを定量化した指標を算出する。このスループットの指標はスループットの大きさを数値で表したものであれば何でもよく、例えばスループットそのものやスループットに関連する値であってもよい。本実施の形態では、指標算出部１２８は、直前に取得されたセグメントの受信に要した時間である受信時間と当該セグメントの再生長との比をスループットの指標として算出する。セグメントの再生長はセグメントファイルのデータ量を反映するので、この指標はスループットの大きさを示す良い指標である。より具体的には、指標算出部１２８は、セグメントファイルが受信されるごとに、そのセグメントファイルの受信時間と再生長とから指標を算出する。セグメントの数をＮ個（Ｎは２以上の自然数）とし、ｍ番目（ｍはＮより小さい自然数）のセグメントが受信された後に（ｍ＋１）番目のセグメントを要求するとき、指標算出部１２８は、ｍ番目のセグメントについての指標μ_ｍを
μ_ｍ＝（ｍ番目のセグメントの再生長）／（ｍ番目のセグメントの受信時間） …（式１）
にしたがい算出する。

ビットレート決定部１３４は、しきい値更新部１３２によって更新される決定基準にしたがい、次に要求するセグメントについて指定するビットレートを決定する。ビットレート決定部１３４は、指標算出部１２８によって算出された指標μ_ｍとしきい値更新部１３２によって更新されるしきい値との大小関係に基づいてビットレートを決定する。

具体的には、ビットレート決定部１３４は、レートアップ基準が満たされる場合、すなわち
μ_ｍ＞μｕ_ｍ＋１
の場合、（ｍ＋１）番目のセグメントについて要求するビットレートをｍ番目のセグメントのビットレートよりも高くなるよう決定する。μｕ_ｍ＋１は（ｍ＋１）番目のセグメントに対するレートアップしきい値であり、しきい値更新部１３２により算出される。ビットレート決定部１３４は、レートダウン基準が満たされる場合、すなわち
μ_ｍ＜μｄ_ｍ＋１
の場合、（ｍ＋１）番目のセグメントについて要求するビットレートをｍ番目のセグメントのビットレートよりも低くなるよう決定する。μｄ_ｍ＋１は（ｍ＋１）番目のセグメントに対するレートダウンしきい値であり、しきい値更新部１３２により算出される。

μｕ_ｍ＋１およびμｄ_ｍ＋１のそれぞれの初期値（μｕ_２、μｄ_２）は以下のように決定される。
μｕ_２：ＭＰＤファイルに記載されている、コンテンツについて利用可能なビットレートをＢＲ１、ＢＲ２、ＢＲ３、…とするとき、隣接レート間比率（ＢＲ２／ＢＲ１、ＢＲ３／ＢＲ２、…）の最大値。利用可能なビットレートが３００ｋｂｐｓ、１．２Ｍｂｐｓ、５Ｍｂｐｓである例では、１．２／０．３＝４、５／１．２＝４．２なのでμｕ_２は４．２となる。
μｄ_２：予め設定された定数であり、例えば０．８程度。

しきい値更新部１３２は、セグメントファイルが受信されるごとに、決定基準をクライアント装置１０６の状況およびコンテンツの属性のうちの少なくともひとつに基づいて更新する。しきい値更新部１３２は、（１）スループットの変動が大きいほど、または（２）ハンドオーバの頻度が高いほど、ビットレートが上がりにくくなるよう決定基準を更新する。

より具体的には、しきい値更新部１３２は、ビットレート決定部１３４におけるレートアップしきい値およびレートダウンしきい値を以下のように更新する。しきい値更新部１３２は、１より大きいｍについて（ｍ＋１）番目のセグメントに対するレートアップしきい値μｕ_ｍ＋１およびレートダウンしきい値μｄ_ｍ＋１を
μｕ_ｍ＋１＝（１−α）・μｕ_ｍ＋α・μｕ_２・ｋ …（式２）
μｄ_ｍ＋１＝（１−β）・μｄ_ｍ＋β・μｄ_２・ｋ …（式３）
にしたがい算出する。μｕ_ｍ、μｄ_ｍはそれぞれｍ番目のセグメントに対するレートアップしきい値、レートダウンしきい値である。α、βは重み付け係数であり、特に直近の値の反映割合を示す学習率である。ｋはスループットの変動の程度を表す指標σ_ｔｈとハンドオーバの頻度の程度を表す指標σ_ｈｏとに基づいてセグメントごとに更新される変動係数である。

変動係数算出部１３０は、セグメントファイルが受信されるごとに、変動係数ｋを算出し、しきい値更新部１３２に供給する。変動係数ｋは指標σ_ｔｈおよび指標σ_ｈｏの２変数に関して単調増加となる２次元関数
ｋ＝ｆ（σ_ｔｈ、σ_ｈｏ） （０．５≦ｋ≦２）
である。変動係数算出部１３０は以下のように指標σ_ｔｈおよび指標σ_ｈｏを算出し、それらを上記の式に代入することでｋを算出する。ｋの値域はしきい値が発散しないために例として設定したものである。

変動係数算出部１３０は、直前に受信されたセグメントファイルのサイズと、セグメントを要求してからそのセグメントファイル全てを受信し終わるのに要した時間と、からスループットを算出する。変動係数算出部１３０は、算出されたスループットと、該スループットを算出した時刻と、を対応付けてスループット保持部１２４に登録する。

図４は、スループット保持部１２４の一例を示すデータ構造図である。スループット保持部１２４は、スループットが算出された時刻と、算出されたスループットの値と、を対応付けて保持する。

図１に戻り、変動係数算出部１３０は、直前に受信されたセグメントファイルについて算出されたスループットを含む一定時間Ｔ内でのスループットの変動の程度を表す指標σ_ｔｈを以下のように算出する。一定時間Ｔ内に観測されたｎ個（ｎは２より大きくＮより小さい自然数）のスループットをＴｈ_１、Ｔｈ_２、…、Ｔｈ_ｎ、平均をＴｈとすると、σ_ｔｈはｎ個のスループットの標準偏差

として算出される。変動係数算出部１３０は、各セグメントの受信を完了した時点で指標σ_ｔｈを算出する。

変動係数算出部１３０は、一定時間Ｔ内でのハンドオーバの発生頻度の程度を表す指標σ_ｈｏを、一定時間Ｔ内でのハンドオーバ発生の累積回数として算出する。変動係数算出部１３０は、ハンドオーバ情報保持部１２０を参照し、現在時刻からＴだけ前の時刻から現在時刻までの間に何回ハンドオーバが発生したかを算出する。変動係数算出部１３０は算出された値（回数）を指標σ_ｈｏとする。

以上の構成による配信システム１００の動作を説明する。
図５は、配信システム１００における一連の処理を示すタイムチャートである。クライアント装置１０６は、再生対象のコンテンツのＭＰＤファイルをＤＡＳＨサーバ１０２に要求する（Ｓ５０２）。ＤＡＳＨサーバ１０２は、予め生成したＭＰＤファイルをクライアント装置１０６に送信する（Ｓ５０４）。クライアント装置１０６は取得されたＭＰＤファイルの内容に基づいて第１ビットレート決定処理を行う（Ｓ５０６）。第１ビットレート決定処理はコンテンツの最初のセグメントを要求する際にその最初のセグメントについて指定するビットレートを決定するための処理である。本実施の形態では、最初のセグメントについて指定するビットレートの決定基準は予め定められている（例えば、利用可能なビットレートのうち最も低いレート）ので、クライアント装置１０６はその決定基準にしたがって最初のセグメントについて指定するビットレートを決定する。第１ビットレート決定処理における決定基準はスループットの指標にも、スループットの変動の程度にも依存しない。

クライアント装置１０６は、ステップＳ５０６で決定されたビットレートを指定して最初のセグメント（セグメント１）をＤＡＳＨサーバ１０２に要求する（Ｓ５０８）。ＤＡＳＨサーバ１０２は、ステップＳ５０８の要求に応答して、指定されたビットレートに対応するセグメント１のセグメントファイルをクライアント装置１０６に送信する（Ｓ５１０）。

クライアント装置１０６は、セグメント１についてのスループットの指標μ_１に基づいて第２ビットレート決定処理を行う（Ｓ５１２）。第２ビットレート決定処理は、コンテンツの２番目のセグメントを要求する際に、最初のセグメントの指標μ_１に基づいて２番目のセグメントについて指定するビットレートを決定するための処理である。クライアント装置１０６は、受信されたセグメント１のセグメントファイルのサイズと、セグメント１を要求してからそのセグメントファイル全てを受信し終わるのに要した時間と、からセグメント１のスループットを算出し、スループット保持部１２４に登録する。また、クライアント装置１０６は指標μ_１を上記の式１にしたがい算出し、レートアップ基準が満たされるか、すなわちμ_１＞μｕ_２が満たされるかを判定し、レートダウン基準が満たされるか、すなわちμ_１＜μｄ_２が満たされるかを判定する。クライアント装置１０６は、レートアップ基準が満たされている場合、最初のセグメントについて指定したビットレートよりも高いビットレートを２番目のセグメントについて指定するビットレートとして決定する。クライアント装置１０６は、レートダウン基準が満たされている場合、最初のセグメントについて指定したビットレートよりも低いビットレートを２番目のセグメントについて指定するビットレートとして決定する。第２ビットレート決定処理における決定基準はスループットの指標に依存するが、スループットの変動の程度には依存しない。

クライアント装置１０６は、ステップＳ５１２で決定されたビットレートを指定して２番目のセグメント（セグメント２）をＤＡＳＨサーバ１０２に要求する（Ｓ５１４）。ＤＡＳＨサーバ１０２は、ステップＳ５１４の要求に応答して、指定されたビットレートに対応するセグメント２のセグメントファイルをクライアント装置１０６に送信する（Ｓ５１６）。

クライアント装置１０６は、セグメント２についてのスループットの指標μ_２とスループットの変動の程度を表す指標σ_ｔｈとハンドオーバの頻度の程度を表す指標σ_ｈｏとに基づいて第３ビットレート決定処理を行う（Ｓ５１８）。第３ビットレート決定処理は、コンテンツの３番目以降のセグメントを要求する際に、直前のセグメント（ｍ番目のセグメント、ｍ≧２）の指標μ_ｍに基づいて（ｍ＋１）番目のセグメントについて指定するビットレートを決定するための処理である。

図６は、第３ビットレート決定処理の流れを示すフローチャートである。クライアント装置１０６は、受信されたセグメントｍのセグメントファイルのサイズと、セグメントｍを要求してからそのセグメントファイル全てを受信し終わるのに要した時間と、からセグメントｍのスループットを算出し、スループット保持部１２４に登録する。また、クライアント装置１０６はスループットの指標μ_ｍを上記の式１にしたがい算出する（Ｓ６０２）。クライアント装置１０６は、スループットの変動の指標σ_ｔｈを算出する（Ｓ６０４）。クライアント装置１０６は、ハンドオーバの頻度の指標σ_ｈｏを算出する（Ｓ６０６）。クライアント装置１０６は、ステップＳ６０４で算出された指標σ_ｔｈとステップＳ６０６で算出された指標σ_ｈｏとから変動係数ｋを算出し、上記の式２、式３にしたがいレートアップしきい値μｕ_ｍ＋１とレートダウンしきい値μｄ_ｍ＋１とを更新する（Ｓ６０８）。クライアント装置１０６は、更新されたレートアップ基準が満たされるか、すなわちμ_ｍ＞μｕ_ｍ＋１が満たされるかを判定し、更新されたレートダウン基準が満たされるか、すなわちμ_ｍ＜μｄ_ｍ＋１が満たされるかを判定する（Ｓ６１０）。クライアント装置１０６は、レートアップ基準が満たされている場合、ｍ番目のセグメントについて指定したビットレートよりも高いビットレートを（ｍ＋１）番目のセグメントについて指定するビットレートとして決定する（Ｓ６１２）。クライアント装置１０６は、レートダウン基準が満たされている場合、ｍ番目のセグメントについて指定したビットレートよりも低いビットレートを（ｍ＋１）番目のセグメントについて指定するビットレートとして決定する（Ｓ６１２）。第３ビットレート決定処理における決定基準はスループットの指標とスループットの変動の程度とに依存する。

図５に戻り、クライアント装置１０６は、ステップＳ５１８で決定されたビットレートを指定して３番目のセグメント（セグメント３）をＤＡＳＨサーバ１０２に要求する（Ｓ５２０）。ＤＡＳＨサーバ１０２は、ステップＳ５２０の要求に応答して、指定されたビットレートに対応するセグメント３のセグメントファイルをクライアント装置１０６に送信する（Ｓ５２２）。その後、クライアント装置１０６は次に要求する４番目のセグメントについて第３ビットレート決定処理を行う（Ｓ５２４）。以降、セグメントの配信と第３ビットレート決定処理とがセグメント全てが配信されるまで繰り返される。

上述の実施の形態において、保持部の例は、ハードディスクや半導体メモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶する半導体メモリなどにより実現できることは本明細書に触れた当業者には理解される。

本実施の形態に係るクライアント装置１０６によると、スループットが変動しやすい状況においてはビットレートが上がりにくくなるようにしきい値が更新されるので、予期せぬバッファアンダーフローの発生を抑制または除去できる。また、逆に、スループットが変動しづらい状況においてはビットレートが上がりやすくなるようにしきい値が更新されるので、高画質のコンテンツを迅速にユーザに提供することができ、ユーザが体感する品質を高めることができる。

以上、実施の形態に係るクライアント装置１０６の構成と動作について説明した。この実施の形態は例示であり、各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解される。

実施の形態では、クライアント側でビットレートを決定する場合について説明したが、これに限られず、サーバ側がクライアントからスループットの報告を受けてビットレートを決定するような構成に本実施の形態の技術的思想を適用してもよい。

実施の形態では、指標算出部１２８は、直前に取得されたセグメントの受信に要した時間である受信時間と当該セグメントの再生長との比をスループットの指標として算出する場合について説明したが、これに限られない。例えば、指標算出部は２つ前のセグメントおよび直前のセグメントの２つのセグメントの受信時間の合計とそれらの再生長の合計との比を指標として算出してもよい。このように、過去に取得されたセグメントについて算出された指標が使用されてもよい。

実施の形態では、しきい値更新部１３２は、（１）スループットの変動が大きいほど、または（２）ハンドオーバの頻度が高いほど、ビットレートが上がりにくくなるよう決定基準を更新する場合について説明したが、これに限られない。例えば、しきい値更新部は、（３）バッファ１３６の残量が少ないほど、または（４）次以降に要求するセグメントのデータ量が多いほど、ビットレートが上がりにくくなるよう決定基準を更新してもよい。次以降に要求するセグメントのデータ量は、例えばセグメントの再生長や将来に配信されるセグメントのサイズ情報によって表される。

例えば、セグメントの再生長が長いほど急激なスループットの変動に弱いので、変動係数ｋ’をセグメントの再生長ｌに関して単調増加となる関数
ｋ’＝ｇ（ｌ）
としてもよい。

あるいはまた、しきい値更新部は、ユーザ操作受付部１１８によって受け付けられたユーザ操作の統計情報に基づいて決定基準を更新してもよい。統計情報は、例えば一定期間内の再生停止回数や一定期間内の再生停止時間である。あるいはまた、しきい値更新部１３２は、コンテンツの符号化情報（例えば、ＣＢＲ、ＶＢＲ、ＡＢＲ）やＤＲＭ情報に基づいて決定基準を更新してもよい。ユーザ操作の統計情報について、ユーザ操作によっても、どれくらいのビットレートを要求すればよいかは変わりうる。例えば、シークを大量に行うユーザであれば、毎回の再生までの初期遅延が長くなるので、ビットレートを低くするほうが都合が良い。ユーザ操作の統計情報に基づいて決定基準を更新する場合はこのような状況にも対応可能となる。

あるいはまた、バッファアンダーフローによっても再生停止が発生するので、しきい値更新部はそのような発生停止回数が多いほどまたはその期間が長いほど、ビットレートが上がりにくくなるよう決定基準を更新してもよい。

実施の形態では、スループットの変動の程度を表す指標σ_ｔｈとしてスループットの標準偏差を採用する場合について説明したが、これに限られず、スループットの変動の程度を表す指標であれば任意のものでよい。例えば、指標μ_ｍの標準偏差が採用されてもよいし、過去のセグメントの受信時間の標準偏差が採用されてもよい。

実施の形態では、しきい値更新部１３２はセグメントファイルを受信するごとに、次のセグメントの要求の際に使用されるしきい値を更新する場合について説明したが、これに限られない。例えば、ハンドオーバに着目すると、一般的な再生長よりも細かい時間粒度で変動しうる。したがって、しきい値更新部は、再生長よりも細かい時間粒度でしきい値を更新してもよい。例えば、しきい値更新部は、セグメントファイルの受信中に複数回しきい値の更新を行ってもよい。あるいはまた、しきい値更新部は、再生長が５秒のセグメントに対して１秒間隔や２秒間隔でしきい値の更新を行ってもよい。あるいはまた、しきい値更新部１３２は、ハンドオーバの検知が行われるごとにしきい値の更新を行ってもよい。

１００ 配信システム、 １０２ ＤＡＳＨサーバ、 １０４ ネットワーク、 １０６ クライアント装置。

Claims (13)

1. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、
   前記クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、前記クライアント装置の状況に基づいて更新する更新部と、
   前記更新部によって更新された基準にしたがいビットレートを決定する決定部と、を備え、
   前記更新部は、スループットの変動が大きいほどビットレートが上がりにくくなるよう基準を更新することを特徴とするクライアント装置。
2. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、
   前記クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、前記クライアント装置の状況に基づいて更新する更新部と、
   前記更新部によって更新された基準にしたがいビットレートを決定する決定部と、を備え、
   前記更新部は、ハンドオーバの頻度が高いほどビットレートが上がりにくくなるよう基準を更新することを特徴とするクライアント装置。
3. 前記更新部は、スループットの変動が大きいほどビットレートが上がりにくくなるよう基準を更新することを特徴とする請求項２に記載のクライアント装置。
4. 前記更新部は、セグメントが取得されるごとに基準を更新することを特徴とする請求項１から３のいずれか１項に記載のクライアント装置。
5. 前記決定部によって決定されたビットレートを指定して次のセグメントをネットワークを介して要求する要求部をさらに備えることを特徴とする請求項１から４のいずれか１項に記載のクライアント装置。
6. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、
   前記クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、前記クライアント装置の状況に基づいて更新する更新部と、
   前記更新部によって更新された基準にしたがいビットレートを決定する決定部と、
   取得されたセグメントファイルを保持するバッファと、を備え、
   前記更新部は、前記バッファの残量が少ないほどビットレートが上がりにくくなるよう基準を更新することを特徴とするクライアント装置。
7. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、
   前記クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、前記クライアント装置の状況に基づいて更新する更新部と、
   前記更新部によって更新された基準にしたがいビットレートを決定する決定部と、
   取得されたセグメントファイルを保持するバッファと、を備え、
   前記更新部は、前記バッファの残量に起因する再生停止の回数または期間に基づいて基準を更新することを特徴とするクライアント装置。
8. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、
   前記クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、前記クライアント装置の状況に基づいて更新する更新部と、
   前記更新部によって更新された基準にしたがいビットレートを決定する決定部と、
   取得されたコンテンツの再生に関するユーザ操作を受け付ける受付部と、を備え、
   前記更新部は、前記受付部によって受け付けられたユーザ操作の統計情報に基づいて基準を更新することを特徴とするクライアント装置。
9. 前記更新部は、要求するセグメントのデータ量が多いほどビットレートが上がりにくくなるよう基準を更新することを特徴とする請求項１から８のいずれか１項に記載のクライアント装置。
10. 過去に取得されたセグメントの受信に要した時間と当該セグメントの再生長またはデータ量との比をスループットの指標として算出する算出部をさらに備え、
    前記決定部は、前記算出部によって算出された指標としきい値との大小関係に基づいてビットレートを決定し、
    前記更新部は、前記決定部におけるしきい値を更新することを特徴とする請求項１から９のいずれか１項に記載のクライアント装置。
11. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得するクライアント装置であって、
    前記クライアント装置におけるスループットの指標から要求するセグメントのビットレートを決定するための基準を、前記クライアント装置の状況に基づいて更新する更新部と、
    前記更新部によって更新された基準にしたがいビットレートを決定する決定部と、
    過去に取得されたセグメントの受信に要した時間と当該セグメントの再生長またはデータ量との比をスループットの指標として算出する算出部と、を備え、
    前記決定部は、前記算出部によって算出された指標としきい値との大小関係に基づいてビットレートを決定し、
    前記更新部は、前記決定部におけるしきい値を更新し、
    セグメントの数をＮ個（Ｎは３以上の自然数）とし、ｍ番目（ｍは１より大きくＮより小さい自然数）のセグメントが受信された後に（ｍ＋１）番目のセグメントを要求するとき、
    前記算出部は、指標μ_ｍを
    μ_ｍ＝（ｍ番目のセグメントの再生長）／（ｍ番目のセグメントの受信に要した時間）
    にしたがい算出し、
    前記更新部は、第１しきい値μｕ_ｍ＋１および第２しきい値μｄ_ｍ＋１を
    μｕ_ｍ＋１＝（１−α）・μｕ_ｍ＋α・μｕ_２・ｋ
    μｄ_ｍ＋１＝（１−β）・μｄ_ｍ＋β・μｄ_２・ｋ
    にしたがい算出し、ここでα、βは重み付け係数であり、ｋは前記クライアント装置の状況およびコンテンツの属性のうちの少なくともひとつに基づいてセグメントごとに更新される値であり、
    前記決定部は、
    μ_ｍ＞μｕ_ｍ＋１
    の場合、（ｍ＋１）番目のセグメントについて要求するビットレートをｍ番目のセグメントのビットレートよりも高くなるよう決定し、
    μ_ｍ＜μｄ_ｍ＋１
    の場合、（ｍ＋１）番目のセグメントについて要求するビットレートをｍ番目のセグメントのビットレートよりも低くなるよう決定することを特徴とするクライアント装置。
12. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得する方法であって、
    受信装置におけるスループットの指標から要求されるセグメントのビットレートを決定するための基準を、前記受信装置の状況に基づいて更新することと、
    前記更新された基準にしたがいビットレートを決定することと、を含み、
    前記更新することは、スループットの変動が大きいほどビットレートが上がりにくくなるよう基準を更新することを含むことを特徴とする方法。
13. 複数のビットレートを有し、複数のセグメントに分割されるコンテンツに対し、セグメントごとにビットレートを指定して要求し、ネットワークを介して取得する機能と、
    受信装置におけるスループットの指標から要求されるセグメントのビットレートを決定するための基準を、前記受信装置の状況に基づいて更新する機能と、
    前記更新された基準にしたがいビットレートを決定する機能と、をコンピュータに実現させ、
    前記更新する機能は、スループットの変動が大きいほどビットレートが上がりにくくなるよう基準を更新する機能を含むコンピュータプログラム。

Images