JP6588882B2 - 動画再生装置、動画再生方法及びプログラム - Google Patents

Description

本発明は、動画再生装置、動画再生方法及びプログラムに関する。

近年のモバイルネットワークの普及に伴い、モバイルネットワークを介したアプリケーションやサービスが多数提供されている。その中でも代表的なサービスが動画配信サービスである。

近年の動画配信サービスは、再生開始待ち時間低減のため、動画データを全てダウンロードしてから再生するという形式ではなく、動画データをダウンロードしながら同時に再生するという形態をとっていることが多い。この形態はプログレッシブダウンロード（ＰＤＬ）型と呼ばれており、Ｙｏｕｔｕｂｅ（登録商標）をはじめとした多くの動画配信サービスで利用されている方式である。また、ＰＤＬ型動画配信では、Adaptive Bitrate（ＡＢＲ）方式で配信がされることが多い。ＡＢＲ方式において、サーバは動画データを一定時間ごとのデータ（チャンク）に分割してそれぞれ何パターンかの条件で再エンコードして保存しておき、クライアントはネットワーク品質やバッファ量に応じてどの品質（ビットレート）で配信するかを動的に決定する。ＡＢＲ型動画配信においては、クライアントで動くビットレート選択アルゴリズムとペーシングアルゴリズムという２つのアルゴリズムを組み合わせて体感品質の高い配信を実現している。

ビットレート選択アルゴリズムとは、各チャンクを受信するときにどのようなポリシーでビットレートを選択するか、を決定するアルゴリズムである。ネットワーク品質に対して高すぎるビットレートの動画データを選択してしまうと、途中で再生が停止してしまう。一方で、低すぎるビットレートの動画データを選択してしまうと、ネットワーク帯域が余っているにも関わらず低画質の動画しか視聴できないというトレードオフが存在する。そのため、適切なビットレート選択を行うためには、その時のネットワーク品質を高精度に把握することが重要となる。ＡＢＲ方式の動画配信の多くは、動画配信中のネットワーク品質を把握するため、チャンクをダウンロードした時に得られるスループットの値を用いている（例えば、非特許文献１参照）。

しかし、ＰＤＬ型動画配信サービスにおいて、リアルタイムにネットワーク品質を把握することは難しい。その理由は、クライアントで動作しているペーシングアルゴリズムによるものである。ペーシングアルゴリズムとは、動画の受信タイミングを調整することで、バッファ量をコントロールするアルゴリズムである。再生停止を防ぐという観点では、バッファを常に貯め続ける方式が望ましいが、バッファ量が大きすぎると、ユーザが視聴をやめた時に無駄になるトラヒック量が増えてしまう。一方で、バッファ量が小さすぎると、再生停止が発生しやすくなるというトレードオフがある。

一般的には、上限の閾値に達するまではバッファを貯め、上限の閾値に達した後は下限の閾値に達するまでバッファを貯めないｓａｗｔｏｏｔｈ方式や、できる限りバッファを貯め続けるｚｉｐｐｙ方式が利用されている（例えば、非特許文献１参照）。

Michael Seufert, Sebastian Egger, Martin Slanina, Thomas Zinner, Tobias Hosfeld, Phuoc Tran-Gia A Survey on Quality of Experience of HTTP Adaptive Streaming. IEEE Communications Surveys & Tutorials, 17, 2015.

しかしながら、ｓａｗｔｏｏｔｈペーシングにおいては、チャンクのダウンロードが行われない時間帯が発生する。そのため、例えばペーシング中（動画データを受信していない間）にスループットの上昇又は下降が発生したとしても、その変化を即座に把握することができない。こうした急激なスループットの変化は、モバイルネットワークにおいては頻繁に発生するため、再度チャンクを要求するときに、実際のスループットに適さないビットレートを選択してしまう可能性がある。

一方、ｚｉｐｐｙペーシングにおいては、断続的にチャンクの要求が行われるため、スループットを把握することは比較的容易である。しかし、１チャンク分のデータ量をダウンロードできるだけバッファの空きがないとチャンクのダウンロードを開始しないため、チャンクのダウンロード間に数秒間の待機時間が発生してしまう。こうした待機時間は、ｓａｗｔｏｏｔｈペーシングと同様、実際のスループットには適さないビットレートを選択してしまう可能性がある。

本発明は、上記の点に鑑みてなされたものであって、ネットワークのスループットの推定精度を向上させることを目的とする。

そこで上記課題を解決するため、動画再生装置は、動画データを部分データごとにネットワークを介して受信し、前記動画データのバッファ量に応じて前記動画データの受信を停止する受信部と、前記受信部によって受信された部分データを再生する再生部と、前記受信部が受信を停止している間に、前記動画データの一部を受信することでスループットを測定する測定部と、前記動画データのうちまだ受信されていない部分データに対して用意されている複数のビットレートの中から前記受信部に受信させるビットレートを、前記測定部によって測定されたスループットに基づいて選択する選択部と、を有し、前記受信部は、前記選択部によって選択されたビットレートの部分データを受信する。

ネットワークのスループットの推定精度を向上させることができる。

第１の実施の形態におけるネットワーク構成例を示す図である。 第１の実施の形態における動画再生装置１０のハードウェア構成例を示す図である。 第１の実施の形態における動画再生装置１０の機能構成例を示す図である。 第１の実施の形態においてペーシング処理部１３１が実行する処理手順の一例を説明するためのフローチャートである。 ｂｙｔｅ−ｒａｎｇｅ決定処理の処理手順の一例を説明するためのフローチャートである。 スループットの測定処理の処理手順の一例を説明するためのフローチャートである。 ペーシング中においてダウンロードが実行されることによる効果を説明するための図である。 ダウンロードが一部ずつ実行されることによる効果を説明するための図である。 第２の実施の形態においてペーシング処理部１３１が実行する処理手順の一例を説明するためのフローチャートである。

本実施の形態では、新たなペーシング方式が開示される。当該ペーシング方式は、既存のあらゆるペーシング方式に修正を加えることで実現することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、第１の実施の形態におけるネットワーク構成例を示す図である。図１において、配信サーバ２０及び動画再生装置１０は、インターネット等のネットワークを介して接続される。当該ネットワークは、モバイルネットワーク（移動体通信網）を含んでもよい。

配信サーバ２０は、動画再生装置１０から要求された動画データの配信を行う１以上のコンピュータである。動画データの配信は、ＡＢＲ（Adaptive Bitrate Streaming）に従う。すなわち、各動画データについては、一定時間ごとの分割単位の一例であるチャンクごとに、何パターンかの条件で再エンコードされたデータが保存されている。

動画再生装置１０は、動画データの視聴に利用される端末（コンピュータ）である。動画再生装置１０は、ユーザによって指定された動画データを配信サーバ２０からダウンロードし、当該動画データの再生を行う。例えば、スマートフォン、タブレット端末、又はＰＣ（Personal Computer）等が動画再生装置１０として利用されてもよい。

図２は、第１の実施の形態における動画再生装置１０のハードウェア構成例を示す図である。図２の動画再生装置１０は、それぞれバスＢで相互に接続されている補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６及び入力装置１０７等を有する。

動画再生装置１０での処理を実現するプログラムは、補助記憶装置１０２にインストールされる。当該プログラムは、ネットワークを介して他のコンピュータからダウンロードされてもよい。補助記憶装置１０２は、インストールされたプログラムを記憶すると共に、必要なファイルやデータ等を記憶する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して記憶する。ＣＰＵ１０４は、メモリ装置１０３に記憶されたプログラムに従って動画再生装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード、マウス、ボタン、又はタッチパネル等であり、様々な操作指示の入力に用いられる。

図３は、第１の実施の形態における動画再生装置１０の機能構成例を示す図である。図３において、動画再生装置１０は、ＵＩ部１１、動画再生部１２、動画データ受信部１３及びスループット測定部１４等を有する。これら各部は、動画再生装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

ＵＩ部１１は、ユーザによって指定された動画データの再生を動画再生部１２に要求する。

動画再生部１２は、再生対象の動画データについて、再生位置のチャンクごとにチャンク番号を指定して、動画データ受信部１３に対してデータを要求し、動画データ受信部１３から応答されたデータの再生を行う。なお、動画再生部１２による動画データの再生は、動画データ受信部１３による動画データの取得と並行して行われる。すなわち、動画データの全部が取得される前に、動画再生部１２による再生が開始される。

動画データ受信部１３は、動画再生部１２から要求されたチャンクのデータを、ペーシングが行われていない期間において配信サーバ２０から受信（取得）する。ペーシングとは、動画データの受信が停止されることをいう。図３において、動画データ受信部１３は、ペーシング処理部１３１、ビットレート選択部１３２及びチャンク要求部１３３等を含む。

ペーシング処理部１３１は、動画再生部１２からの要求に応じ、動画データの受信を行うか、スループット測定部１４を呼び出すかを決定する。動画データの受信を行う場合、ペーシング処理部１３１は、ビットレート選択部１３２に対してビットレートの選択等を要求する。当該要求には、動画再生部１２から要求されたチャンク番号が指定される。スループット測定部１４を呼び出す場合、ペーシング処理部１３１は、スループット測定部１４に対してスループットの測定を要求する。当該要求には、動画再生部１２から要求されたチャンク番号が指定される。

ビットレート選択部１３２は、ペーシング処理部１３１からの要求に応じ、当該要求において指定されているチャンク番号に係るチャンクについて、受信対象とするデータのビットレートを選択する。ビットレートの選択は、チャンク要求部１３３又は測定実行部１４２によって測定されたスループットに基づいて行われる。

チャンク要求部１３３は、動画再生部１２から要求されたチャンクについて、決定されたタイミングで決定されたビットレートのデータを配信サーバ２０に要求する。チャンク要求部１３３は、当該要求に応じて配信サーバ２０から返信されるデータを受信する。チャンク要求部１３３は、更に、データの受信に際し、スループットを測定する。

スループット測定部１４は、配信サーバ２０と動画再生装置１０との間の通信のスループットを測定する。図３において、スループット測定部１４は、測定条件決定部１４１及び測定実行部１４２を含む。

測定条件決定部１４１は、ペーシング処理部１３１からの要求に応じ、スループットの測定条件を決定する。測定条件の詳細については後述される。

測定実行部１４２は、測定条件決定部１４１によって決定された測定条件に従って、スループットの測定を実行する。測定実行部１４２は、スループットの測定値をペーシング処理部１３１へ通知する。スループットの測定は、ペーシング処理部１３１からの要求に指定されているチャンク番号に係るチャンクのデータの全部又は一部を配信サーバ２０から受信することによって行われる。すなわち、スループットの測定用のパケットは使用されない。スループットの測定のために受信されたデータは、動画再生部１２に送られ、チャンク単位でデータが揃い次第、動画再生部１２によって再生される。

以下、動画再生装置１０が実行する処理手順について説明する。図４は、第１の実施の形態においてペーシング処理部１３１が実行する処理手順の一例を説明するためのフローチャートである。図４の処理手順は、動画再生部１２からの要求に応じて、ペーシング処理部１３１によって実行される。

ステップＳ１０１において、ペーシング処理部１３１は、動画再生装置１０に蓄積されているバッファ量ｂｕｆが、バッファ量の下限値Ｔｈ_ｂ以上であるか否かを判定する。バッファ量ｂｕｆは、配信サーバ２０からダウンロード済みであるが、まだ再生されていない動画データの時間長［ｓｅｃ］である。バッファ量ｂｕｆが、下限値Ｔｈ_ｂ［ｓｅｃ］未満である場合（Ｓ１０１でＮｏ）、ペーシング処理部１３１は、データの受信を行うことを決定する（Ｓ１０４）。

一方、バッファ量ｂｕｆが、下限値Ｔｈ_ｂ［ｓｅｃ］以上である場合（Ｓ１０１でＹｅｓ）、ペーシング処理部１３１は、バッファ量ｂｕｆが、上限値Ｔｈ_ａ以下であるか否かを判定する（Ｓ１０２）。なお、上限値Ｔｈ_ａ及び下限値Ｔｈ_ｂは、予め設定される。

バッファ量ｂｕｆが、上限値Ｔｈ_ａ以下である場合（Ｓ１０２でＹｅｓ）、ペーシング処理部１３１は、スループットが、予め設定された閾値以上であるか否かを判定する（Ｓ１０３）。スループットが閾値以上である場合（Ｓ１０３でＹｅｓ）、ペーシング処理部１３１は、動画データの受信を行うことを判定する（Ｓ１０４）。なお、当該スループットは、チャンク要求部１３３又は測定実行部１４２によって測定されたスループットの履歴の中で最後に測定されたスループットである。

一方、バッファ量の上限値Ｔｈ_ａを越える場合（Ｓ１０２でＮｏ）、又はスループットが閾値未満である場合（Ｓ１０３でＮｏ）、ペーシング処理部１３１は、スループット測定部１４を呼び出すことを判定する（Ｓ１０５）。この場合、ペーシングが行われ、チャンク要求部１３３による動画データの受信は停止する。

なお、ステップＳ１０４の判定が行われた場合、ビットレート選択部１３２によって、ビットレートが選択され、受信対象のチャンクについて、当該ビットレートのデータがチャンク要求部１３３によって配信サーバ２０から受信される。ここで、チャンク要求部１３３が、当該チャンクのデータの受信を行う際、後述する処理手順（図６）において、測定実行部１４２によって部分的に当該チャンクのダウンロードが行われていれば、チャンク要求部１３３は、ダウンロード済みの部分に続くデータを受信してもよい。又は、チャンク要求部１３３は、当該チャンクについて測定実行部１４２によってダウンロードされている部分的なデータを破棄し、改めて当該チャンクのデータを先頭から受信してもよい。

一方、ステップＳ１０５の判定が行われた場合、ペーシング処理部１３１は、スループット測定部１４の測定条件決定部１４１に対してスループットの測定を要求する。測定条件決定部１４１は、当該要求に応じ、スループットの測定条件を決定する。測定条件とは、どのような条件でスループットの測定を行うのかを示す情報をいう。測定条件は、測定間の待機時間（すなわち、測定時の間隔）、測定時にダウンロード対象とするビットレート、測定時にダウンロードするデータ量の３つ要素で表される。それぞれの要素については、後述するようにいくつか設定しうる方式があるが、これらの方式の任意のものが組み合わせてひとつの条件としされてもよい。

測定間の待機時間は、静的に値が設定されてもよいし、動的に決定されてもよい。静的に設定される場合には、１秒間隔などが設定されてもよいし、小さな値βが設定されて、ｂｕｆ−Ｔｈ_ｂ―βが設定されてもよい。動的に決定される場合には、例えば、現在のユーザの通信環境（時間帯、セルＩＤ、ＧＰＳのいずれか、又はこれらの２以上の組み合わせ）が一致する過去の通信におけるスループットの標準偏差の逆数に係数を乗じた値が採用されてもよい。動的に待機時間が設定されることで、その通信環境におけるスループットの標準偏差が大きいときには、なるべく短い間隔でスループットを測定することで精度を確保し、スループットの標準偏差が小さいときには、なるべく長い間隔でスループットを測定することができる。その結果、実スループットと乖離したビットレートが選択されるチャンクを少なくすることができる。

測定時にダウンロード対象とするビットレートとしては、直前までのスループットの履歴に基づいて算出した推定スループットに１以下の係数αを乗じた値を超えない最大のビットレートが選択されてもよいし、配信サーバ２０において用意されたビットレートの中で最も低いビットレートが選択されてもよいし、その通信環境における過去のスループットの代表値（平均値、中央値等）を超えない最大のビットレートが選択されてもよい。なお、直前までのスループットの履歴とは、チャンク要求部１３３又は測定実行部１４２によって測定されたスループットの履歴をいう。

測定時にダウンロードするビット量は、１チャンク分であってのよいし、チャンクの一部であってもよい。チャンクの一部のダウンロードは、例えば、ＲＦＣ７２３３に規定されているHTTP range requestsの機能を利用することで実現可能である。近年の動画配信の多くはＨＴＴＰベースで行われているため、この機能は多くの動画配信に対して適用することが可能である。但し、他の方法によって部分的なデータの取得が可能であれば、必ずしもこの機能が用いられなくてもよい。

チャンクの一部のダウンロードする場合の、ｂｙｔｅ−ｒａｎｇｅの決定方法について説明する。

図５は、ｂｙｔｅ−ｒａｎｇｅ決定処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ２０１において、測定条件決定部１４１は、ｂ_ｓ＋ｍとｂｒ×ｓとのうちの小さい方をｂ_ｅに代入する。ここで、ｂ_ｓは、ダウンロード対象のチャンク（ペーシング処理部１３１からの要求に指定されたチャンク番号に係るチャンク）において、既にダウンロードが完了している部分の末尾の位置を示すバイト数である。ｂ_ｓは、例えば、動画再生部１２からペーシング処理部１３１に対して動画データ（チャンク）が要求されるごとに０に初期化される。ｂ_ｅは、ダウンロード対象の末尾の位置を示すバイト数である。なお、ｂ_ｓ及びｂ_ｅは、ダウンロード対象のチャンクの先頭を起点とする値である。ｍは、静的もしくは動的に決定されたｂｙｔｅ−ｒａｎｇｅの幅［ｂｙｔｅ］を表す変数である。ｓは、配信サーバ２０で用意している、各チャンクの長さ［ｓｅｃ］である。ｂｒは、測定時にダウンロード対象とするビットレートとして決定された値である。

続いて、測定条件決定部１４１は、ｂ_ｓ＋１からｂ_ｅまでをｂｙｔｅ−ｒａｎｇｅに指定する（Ｓ２０２）。続いて、測定条件決定部１４１は、ｂ_ｅにｂ_ｓを代入する（Ｓ２０３）。

測定条件決定部１４１は、決定した測定条件と、ペーシング処理部１３１からの要求に指定されているチャンク番号とを指定して、測定実行部１４２に対してスループットの測定を要求する。測定実行部１４２は、当該要求に応じてスループットの測定処理を実行する。

図６は、スループットの測定処理の処理手順の一例を説明するためのフローチャートである。

ステップＳ３０１において、測定実行部１４２は、測定条件において指定された「測定間の待機時間」が示す秒数だけ待機する。

続いて、測定実行部１４２は、ダウンロード対象のチャンクについて、測定条件において指定された「測定時にダウンロード対象とするビットレート」のデータを、測定条件において指定されたｂｙｔｅ−ｒａｎｇｅが示す範囲分だけ配信サーバ２０から取得（ダウンロード）する（Ｓ３０２）。

続いて、測定実行部１４２は、ｂｒ×（ｂ_ｅ−ｂ_ｓ）÷ｔの演算結果を、スループットｔｈｐに代入する（Ｓ３０３）。ここで、ｂｒは、測定条件において指定された「測定時にダウンロード対象とするビットレート」である。ｂ_ｅ及びｂ_ｓは、測定条件において指定されたｂｙｔｅ−ｒａｎｇｅに係るｂ_ｅ及びｂ_ｓである。ｔは、ステップＳ３０２におけるダウンロードの所要時間［ｓｅｃ］である。

続いて、測定実行部１４２は、ｂｒ×ｓがｂ_ｅに等しいか否かを判定する（Ｓ３０４）。当該判定は、１チャンク分のデータが測定実行部１４２によってダウンロードされたか否かの判定である。ｂｒ×ｓがｂ_ｅに等しくない場合、すなわち、１チャンク分のデータがダウンロードされていない場合（Ｓ３０４でＮｏ）、測定実行部１４２は、スループットｔｈｐをペーシング処理部１３１に通知する（Ｓ３０５）。

一方、ｂｒ×ｓがｂ_ｅに等しい場合、すなわち、１チャンク分のデータがダウンロードされた場合（Ｓ３０４でＹｅｓ）、測定実行部１４２は、当該チャンクについてダウンロードされたデータを、動画再生部１２に転送する（Ｓ３０６）。動画再生部１２は、当該データを再生する。続いて、ステップＳ３０５が実行される。

なお、ステップＳ３０５が実行されると、図４の処理手順が開始される。すなわち、ペーシング処理部１３１は、動画再生部１２からの要求のみならず、測定実行部１４２からスループットの通知をも契機として、図４の処理手順を実行する。したがって、図６の処理は、図４のステップＳ１０１、Ｓ１０２、及びＳ１０３の条件が満たされるまで繰り返し実行される。当該繰り返しにおいて、図６の処理が実行される間隔は、ステップＳ３０１における待機時間となる。すなわち、定期的に１以上のタイミングにおいてスループットの測定が実行される。

上述したように、本実施の形態によれば、ｓａｗｔｏｏｔｈペーシングとは異なり、チャンクが受信されない期間が長期化することを回避することができる。すなわち、本実施の形態では、ペーシング中においてもダウンロードが実行されてスループットが測定される。その結果、スループットの変化をよりリアルタイムに把握することができる。

図７は、ペーシング中においてダウンロードが実行されることによる効果を説明するための図である。図７において、○は、ｓａｗｔｏｏｔｈペーシングによってチャンクが受信されるタイミングを示す。×は、本実施の形態によってチャンク又はチャンクの一部が受信されるタイミングを示す。また、時点ｔ１は、ｓａｗｔｏｏｔｈペーシングにおいてバッファ量が上限値に達したため、受信が停止した時点を示す。時点ｔ２は、バッファ量が下限値に達したため、受信が再開された時点を示す。

時点ｔ１〜ｔ２において、ｓａｗｔｏｏｔｈペーシングではチャンクが受信されないため、スループットの測定ができない。したがって、時点ｔ２におけるスループットの推定値は、時点ｔ１において測定された値となる。当該値は、図７において両矢印によって示されている分だけの誤差を含む。

一方、本実施の形態では、時点ｔ１〜ｔ２の間においても、測定実行部１４２によってチャンクが受信される。したがって、時点ｔ１よりも時点ｔ２に近い時点ｔ３における測定値を、時点ｔ２におけるスループットの推定値とすることができる。その結果、スループットの推定精度を向上させることができる。

また、本実施の形態において、測定実行部１４２によるチャンクのダウンロードは一部ずつ実行されてもよい。当該一部のダウンロード時間は、当該チャンクの全部のダウンロード時間に比べて短くなる。したがって、より高精度にスループットの把握が可能となる。

図８は、ダウンロードが一部ずつ実行されることによる効果を説明するための図である。図８において、○は、ｚｉｐｐｙペーシングによってチャンクが受信されるタイミングを示す。×は、本実施の形態の測定実行部１４２によってチャンクが受信されるタイミングを示す。

図８において明らかなように、本実施の形態は、スループットの測定間隔を短くすることができる。その結果、スループットの推定精度を向上させることができる。

上記のように、本実施の形態は、高精度なスループットの推定結果を用いてビットレート選択を行うことで、従来技術よりも適切なビットレート選択を可能とし、視聴品質の向上、エンゲージメント指標の向上に寄与することができる。

次に、第２の実施の形態について説明する。第２の実施の形態では第１の実施の形態と異なる点について説明する。第２の実施の形態において特に言及されない点については、第１の実施の形態と同様でもよい。第２の実施の形態では、図４の処理手順が、図９の処理手順によって置き換えられる。

図９は、第２の実施の形態においてペーシング処理部１３１が実行する処理手順の一例を説明するためのフローチャートである。図９中、図４と同一ステップには同一ステップ番号を付し、その説明は省略する。

図９では、ステップＳ１０３は実行されない。すなわち、スループットが閾値以上であるか否かの判定は行われない。したがって、バッファ量ｂｕｆが、上限値Ｔｈ_ａ以下であれば、チャンク要求部１３３によってチャンクの受信が実行される。

なお、上記各実施の形態において、チャンク要求部１３３は、受信部の一例である。動画再生部１２は、再生部の一例である。測定実行部１４２は、測定部の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 動画再生装置
１１ ＵＩ部
１２ 動画再生部
１３ 動画データ受信部
１４ スループット測定部
１３１ ペーシング処理部
１３２ ビットレート選択部
１３３ チャンク要求部
１４１ 測定条件決定部
１４２ 測定実行部
２０ 配信サーバ
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
１０６ 表示装置
１０７ 入力装置
Ｂ バス

Claims (7)

1. 動画データを部分データごとにネットワークを介して受信し、前記動画データのバッファ量に応じて前記動画データの受信を停止する受信部と、
   前記受信部によって受信された部分データを再生する再生部と、
   前記受信部が受信を停止している間に、前記動画データの一部を受信することでスループットを測定する測定部と、
   前記動画データのうちまだ受信されていない部分データに対して用意されている複数のビットレートの中から前記受信部に受信させるビットレートを、前記測定部によって測定されたスループットに基づいて選択する選択部と、
   を有し、
   前記受信部は、前記選択部によって選択されたビットレートの部分データを受信する、
   ことを特徴とする動画再生装置。
2. 前記再生部は、前記測定部によって受信される前記動画データの一部も再生する、
   ことを特徴とする請求項１記載の動画再生装置。
3. 前記測定部は、過去のスループットの標準偏差に基づいて算出される時間間隔ごとに、前記動画データを一部ずつ受信する、
   ことを特徴とする請求項１又は２記載の動画再生装置。
4. 前記測定部は、測定されたスループットに基づいて選択されるビットレートの前記動画データの一部を受信する、
   ことを特徴とする請求項１乃至３いずれか一項記載の動画再生装置。
5. 前記一部のデータ量は、前記ビットレートに基づいて決定される、
   ことを特徴とする請求項４記載の動画再生装置。
6. 動画データを部分データごとにネットワークを介して受信し、前記動画データのバッファ量に応じて前記動画データの受信を停止する受信手順と、
   前記受信手順において受信された部分データを再生する再生手順と、
   前記受信手順が受信を停止している間に、前記動画データの一部を受信することでスループットを測定する測定手順と、
   前記動画データのうちまだ受信されていない部分データに対して用意されている複数のビットレートの中から前記受信手順に受信させるビットレートを、前記測定手順において測定されたスループットに基づいて選択する選択手順と、
   をコンピュータが実行し、
   前記受信手順は、前記選択手順において選択されたビットレートの部分データを受信する、
   ことを特徴とする動画再生方法。
7. 請求項１乃至５いずれか一項記載の各部としてコンピュータを機能させることを特徴とするプログラム。

Images