(57)【要約】【課題】動画データの視聴品質の低下を抑制しつつ再生停止の頻度を低下させること。【解決手段】動画再生装置は、動画データの各分割単位について、第１の方法で選択されるビットレートに対応するデータを取得する第１の取得部と、前記動画データの各分割単位について、前記第１の方法とは異なる第２の方法で選択されるビットレートに対応するデータを取得する第２の取得部と、前記第１の取得部によって取得されたデータを再生する再生部とを有し、前記再生部は、再生位置に対応する分割単位に係るデータが前記第１の取得部によって取得されていない場合には、当該分割単位に関して前記第２の取得部によって取得されたデータを再生する。【選択図】図５
2018082241.tif 000002
【特許請求の範囲】
【請求項１】
動画データの各分割単位について、第１の方法で選択されるビットレートに対応するデータを取得する第１の取得部と、
前記動画データの各分割単位について、前記第１の方法とは異なる第２の方法で選択されるビットレートに対応するデータを取得する第２の取得部と、
前記第１の取得部によって取得されたデータを再生する再生部とを有し、
前記再生部は、再生位置に対応する分割単位に係るデータが前記第１の取得部によって取得されていない場合には、当該分割単位に関して前記第２の取得部によって取得されたデータを再生する、
ことを特徴とする動画再生装置。
【請求項２】
前記第１の取得部は、前記第２の取得部によって取得されたデータが再生された場合には、一部の分割単位に対応するデータの取得を行わない、
ことを特徴とする請求項１記載の動画再生装置。
【請求項３】
前記第１の取得部は、或る分割単位について、前記第２の方法で選択されたビットレートよりも前記第１の方法で選択されたビットレートの方が小さい場合には、一部の分割単位に対応するデータの取得を行わない、
ことを特徴とする請求項１又は２記載の動画再生装置。
【請求項４】
動画データの各分割単位について、第１の方法で選択されるビットレートに対応するデータを取得する第１の取得手順と、
前記動画データの各分割単位について、前記第１の方法とは異なる第２の方法で選択されるビットレートに対応するデータを取得する第２の取得手順と、
前記第１の取得手順において取得されたデータを再生する再生手順とをコンピュータが実行し、
前記再生手順は、再生位置に対応する分割単位に係るデータが前記第１の取得手順において取得されていない場合には、当該分割単位に関して前記第２の取得手順において取得されたデータを再生する、
ことを特徴とする動画再生方法。
【請求項５】
前記第１の取得手順は、前記第２の取得手順において取得されたデータが再生された場合には、一部の分割単位に対応するデータの取得を行わない、
ことを特徴とする請求項４記載の動画再生方法。
【請求項６】
前記第１の取得手順は、或る分割単位について、前記第２の方法で選択されたビットレートよりも前記第１の方法で選択されたビットレートの方が小さい場合には、一部の分割単位に対応するデータの取得を行わない、
ことを特徴とする請求項４又は５記載の動画再生方法。
【請求項７】
請求項１乃至３いずれか一項記載の各部としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画再生装置、動画再生方法及びプログラムに関する。
【背景技術】
【０００２】
近年のモバイルネットワークの普及に伴い、モバイルネットワークを介したアプリケーションやサービスが多数提供されている。その中でも、動画配信サービスの利用が広まっている。
【０００３】
近年の動画配信サービスでは、再生開始待ち時間低減のため、動画データを全てダウンロードしてから再生するという形態ではなく、動画データをダウンロードしながら同時に再生するという形態が採用されていることが多い。この形態はプログレッシブダウンロード（ＰＤＬ）型と呼ばれており、Ｙｏｕｔｕｂｅ（登録商標）をはじめとした多くの動画配信サービスで利用されている方式である。
【０００４】
また、ＰＤＬ型動画配信の中でも、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.
【非特許文献２】D. Rossi, C. Testa, S. Valenti, L. Muscariello, LEDBAT: the new BitTorrent congestion control protocol, in: 19th IEEE International Conference on Computer Communications and Networks (ICCCN 2010) Zurich, Switzerland, 2010.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、ＡＢＲ方式についても、再生停止回数の低減には改善の余地が有ると考えられる。
【０００７】
図１は、従来のＡＢＲ方式による動画再生の例を示す図である。図１において、クライアントの動画データ取得部は、ビットレートが高い動画のチャンクを予め配信サーバから取得しておく。動画再生部は、チャンク１〜２の再生が終わり、チャンク３のデータを動画データ取得部に要求する。この時、動画データ取得部は、まだ配信サーバからチャンク３のデータを取得できていないため、チャンク３データなしの応答を返す。その結果、動画再生部で再生停止が発生してしまう。
【０００８】
これは、クライアントがビットレートを選択する際に高過ぎるビットレートを選んでしまうことや、チャンクを受信中にクライアントが通信環境の悪い場所に移動してしまい、低いビットレートに切り替える前にチャンクを受信しきれないこと等が主な原因である。
【０００９】
図１のような問題に対する対策としては、低ビットレートのチャンクを選択し続けるという方式が考えられる。
【００１０】
図２は、低ビットレートのチャンクを選択し続ける方式を説明するための図である。図２において、動画データ取得部は、動画の各チャンクについて、ビットレートが低いデータを予め配信サーバから取得しておく。動画再生部は、チャンク１〜２の再生が終わりと、チャンク３のデータを動画データ取得部に要求する。この時、動画データ取得部は、チャンク３を配信サーバから既に取得できているため、チャンク３のデータの応答を返す。このため、動画再生部は再生を継続できる。
【００１１】
しかしながら、低すぎるビットレートを選んでしまうと、エンゲージメント指標にも悪影響を及ぼしてしまう可能性が有る（例えば、非特許文献２参照）。したがって、単に低いビットレートを選び続けるだけでは、視聴品質の高い動画品質制御ができているとはいい難い。
【００１２】
本発明は、上記の点に鑑みてなされたものであって、動画データの視聴品質の低下を抑制しつつ再生停止の頻度を低下させることを目的とする。
【課題を解決するための手段】
【００１３】
そこで上記課題を解決するため、動画再生装置は、動画データの各分割単位について、第１の方法で選択されるビットレートに対応するデータを取得する第１の取得部と、前記動画データの各分割単位について、前記第１の方法とは異なる第２の方法で選択されるビットレートに対応するデータを取得する第２の取得部と、前記第１の取得部によって取得されたデータを再生する再生部とを有し、前記再生部は、再生位置に対応する分割単位に係るデータが前記第１の取得部によって取得されていない場合には、当該分割単位に関して前記第２の取得部によって取得されたデータを再生する。
【発明の効果】
【００１４】
動画データの視聴品質の低下を抑制しつつ再生停止の頻度を低下させることができる。
【図面の簡単な説明】
【００１５】
【図１】従来のＡＢＲ方式による動画再生の例を示す図である。
【図２】低ビットレートのチャンクを選択し続ける方式を説明するための図である。
【図３】本発明の実施の形態におけるネットワーク構成例を示す図である。
【図４】本発明の実施の形態における動画再生装置１０のハードウェア構成例を示す図である。
【図５】本発明の実施の形態における動画再生装置１０の機能構成例を示す図である。
【図６】チャンク選択部１３３が実行する処理手順の一例を説明するためのフローチャートである。
【図７】本発明の実施の形態における動画再生の例を示す図である。
【発明を実施するための形態】
【００１６】
以下、図面に基づいて本発明の実施の形態を説明する。図３は、本発明の実施の形態におけるネットワーク構成例を示す図である。図３において、配信サーバ２０及び動画再生装置１０は、インターネット等のネットワークを介して接続される。当該ネットワークは、モバイルネットワーク（移動体通信網）を含んでもよい。
【００１７】
配信サーバ２０は、動画再生装置１０から要求された動画データの配信を行う１以上のコンピュータである。動画データの配信は、ＡＢＲ（Adaptive Bitrate Streaming）に従う。すなわち、各動画データについては、一定時間ごとの分割単位の一例であるチャンクごとに、何パターンかの条件で再エンコードされたデータが保存されている。
【００１８】
動画再生装置１０は、動画データの視聴に利用される端末である。動画再生装置１０は、ユーザによって指定された動画データを配信サーバ２０からダウンロードし、当該動画データの再生を行う。例えば、スマートフォン、タブレット端末、又はＰＣ（Personal Computer）等が動画再生装置１０として利用されてもよい。
【００１９】
本実施の形態において、動画再生装置１０は、通常の又は正規の動画データの取得に影響を与えない範囲で、低いビットレートでの先読みを行う。
【００２０】
具体的には、動画再生装置１０は、取得対象の動画データの各チャンクについて、通常の又は正規のデータを受信するセッションとは別に、低画質のデータを先読みするためのセッションを張る。前者のセッションを、以下「表セッション」という。後者のセッションを、以下「裏セッション」という。
【００２１】
表セッションでは、通常のＴＣＰ（Transmission Control Protocol）輻輳制御アルゴリズムを用いて通信が行われるが、裏セッションでは、ＬＥＤＢＡＴ（Low Extra Delay Background Transport）（非特許文献２参照）を用いて通信が行われる。ＬＥＤＢＡＴは、輻輳制御アルゴリズムの一種である。ＬＥＤＢＡＴは、通常の又は正規の通信にはほぼ影響を与えずに通信を行うことができるというのが大きな特徴であり、例えば、ＯＳ（Operating System）更新データのバックグラウンドダウンロードや、Ｐ２Ｐ型ファイル共有ソフトでも利用されている。したがって、裏セッションでは、表セッションの通信には影響を与えずに、裏セッションに並行して、データをダウンロードすることが可能である。
【００２２】
動画再生装置１０は、このようにして張られた裏セッションを利用して、動画データの各チャンクについて低ビットレートのデータの取得を積極的に行い、蓄積しておく。裏セッションでは、配信サーバ２０側で用意された中で最も低いビットレートが静的に選び続けてられてもよいし、将来を予測したスループットの下側信頼区間を超えない最大のビットレートが選択される等の方法により、ビットレートが動的に選択されてもよい。すなわち、裏セッションでは、表セッションとは異なる方法でビットレートが選択されることで、表セッションよりも低いビットレートが選択される可能性が高くされる。
【００２３】
一方、表セッションでは、チャンクを要求するタイミングの決定や、ビットレートの決定にどのようなアルゴリズム（方法）が用いられてもよい。
【００２４】
動画再生装置１０は、再生位置のチャンクが変わるたびに、次にチャンクについて再生するデータを表セッションからのデータとするか、裏セッションからのデータとするのかを判断する。具体的には、動画再生装置１０は、表セッションにおいて次のチャンクのデータが受信されていれば、当該データを再生対象とし、裏セッションで受信されている、動画時間が同タイミングのチャンクのデータを破棄する。一方、表セッションにおいて次のチャンクが受信できていない場合、動画再生装置１０は、裏セッションにおいて当該チャンクについて受信されているデータを再生対象とする。
【００２５】
動画再生装置１０が上記のような処理を実行することで、再生停止が少なく、ビットレートが高い動画配信を実現することができる。
【００２６】
図４は、本発明の実施の形態における動画再生装置１０のハードウェア構成例を示す図である。図４の動画再生装置１０は、それぞれバスＢで相互に接続されている補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、インタフェース装置１０５、表示装置１０６及び入力装置１０７等を有する。
【００２７】
動画再生装置１０での処理を実現するプログラムは、補助記憶装置１０２にインストールされる。当該プログラムは、ネットワークを介して他のコンピュータからダウンロードされてもよい。補助記憶装置１０２は、インストールされたプログラムを記憶すると共に、必要なファイルやデータ等を記憶する。
【００２８】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して記憶する。ＣＰＵ１０４は、メモリ装置１０３に記憶されたプログラムに従って動画再生装置１０に係る機能を実現する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。表示装置１０６はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置１０７はキーボード、マウス、ボタン、又はタッチパネル等であり、様々な操作指示の入力に用いられる。
【００２９】
図５は、本発明の実施の形態における動画再生装置１０の機能構成例を示す図である。図５において、動画再生装置１０は、ＵＩ部１１、動画再生部１２及び動画データ取得部１３等を含む。これら各部は、動画再生装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。
【００３０】
ＵＩ部１１は、ユーザによって指定された動画データの再生を動画再生部１２に要求する。
【００３１】
動画再生部１２は、再生対象の動画データについて、再生位置のチャンクごとにチャンク番号を指定して、動画データ取得部１３に対してデータを要求し、動画データ取得部１３から応答されたデータの再生を行う。なお、動画再生部１２による動画データの再生は、動画データ取得部１３による動画データの取得と並行して行われる。すなわち、動画データの全部が取得される前に、動画再生部１２による再生が開始される。
【００３２】
動画データ取得部１３は、再生対象の動画データの各チャンクについて、配信サーバ２０からデータを取得（ダウンロード）する。動画データ取得部１３は、取得済みチャンクのデータのうち、動画再生部１２から要求されたチャンク番号に係るチャンクのデータを動画再生部１２に応答する。
【００３３】
図５において、動画データ取得部１３は、表セッション管理部１３１、裏セッション管理部１３２、チャンク選択部１３３、表セッションバッファ１３４及び裏セッションバッファ１３５等を含む。表セッションバッファ１３４及び裏セッションバッファ１３５は、メモリ装置１０３等を利用して実現可能である。
【００３４】
表セッション管理部１３１は、配信サーバ２０との間で表セッションを張り、再生対象の動画データの各チャンクについて表セッションを介してデータを取得する。取得されたデータは表セッションバッファ１３４に記憶（蓄積）される。表セッションでは、通常の（一般的な）ＴＣＰ輻輳制御が行われる。動画データ取得制御については、例えばｓａｗｔｏｏｔｈ法を用いたペーシング、直前のスループットを超えない最大のビットレートを選択するビットレート選択方式が適用される。表セッション管理部１３１は、当該選択方式に基づいて選択されたビットレートに対応するデータを取得する。但し、ビットレートの選択方式は、任意のものが用いられてもよい。
【００３５】
なお、表セッション管理部１３１は、ビットレートの選択に際し、裏セッションで受信が完了しているビットレート未満ビットレートが選択される場合や、動画データの受信が再生に間に合わなかった場合（すなわち、或るチャンクについて裏セッションで取得されたデータが再生された場合）には、動画時間上少し先のチャンクから受信を再開するようなアルゴリズムを採用してもよい。すなわち、これらの場合、表セッション管理部１３１は、一部のチャンクについて、データの取得を行わないようにしてもよい。そうすることで、よりビットレートの高い動画の再生を可能とすることができる。
【００３６】
例えば、表セッション管理部１３１が、或るチャンクのデータを表セッションで受信する際に、裏セッションよりも小さいビットレートを選択していることが分かったという状況を考える。また、将来ｎＴ［ｓｅｃ］に渡って、スループットが９０％以上の確率でｔ以上になることが推測できたとする。ここで、Ｔは、チャンクサイズ（チャンクの時間長）、ｎは、正の整数である。この時、表セッション管理部１３１は、以下の式にしたがってビットレートｂｒを選択することで、ｎチャンク後に再生するチャンクのビットレートをより高くすることが可能となる。
【００３７】
【数１】
2018082241.tif 000003
ここで、Ｂは、選択可能なビットレートの集合である。
【００３８】
裏セッション管理部１３２は、配信サーバ２０との間で裏セッションを張り、再生対象の動画データの各チャンクについて裏セッションを介してデータを取得する。取得されたデータは裏セッションバッファ１３５に記憶（蓄積）される。裏セッションにおいて、輻輳制御としてはＬＥＤＢＡＴが用いられる。動画データ取得制御については、例えば、ｚｉｐｐｙ法を用いたペーシング、静的又は動的にビットレートを選択する方式が適用される。ビットレート選択法については、例えば、再生対象の動画データについて用意されているビットレートの中で最も低いビットレートが選択されてもよいし、過去のスループットの代表値（例えば、平均値、中央値、パーセンタイル等）を超えない最大のビットレートが選択されてもよい。また、現在蓄積されているバッファ量に応じて、ビットレートが選択されてもよい。裏セッション管理部１３２は、選択されたビットレートに対応するデータを取得する。
【００３９】
なお、裏セッション管理部１３２は、各チャンクについて選択したビットレートの履歴を、例えば、メモリ装置１０３に記憶してもよい。表セッション管理部１３１は、当該履歴を参照することで、各チャンクについて表セッション管理部１３１が選択したビットレートが、裏セッション管理部１３２によって選択されたビットレートよりも小さいか否かを判定してもよい。
【００４０】
チャンク選択部１３３は、各チャンクについて、表セッション及び裏セッションのいずれのセッションを介して取得されたデータを動画再生部１２への応答対象とするのかを判定する。基本的に、チャンク選択部１３３は、表セッションによって取得されたデータを応答対象とする。但し、再生位置の対応するチャンクに係るデータが、表セッションから取得されていない場合、チャンク選択部１３３は、当該チャンクに関して裏セッションによって取得されているデータを応答対象とする。
【００４１】
図６は、チャンク選択部１３３が実行する処理手順の一例を説明するためのフローチャートである。図６の処理手順の契機（トリガー）は、動画再生部１２からのチャンク番号が指定された動画データの要求である。以下、指定されたチャンク番号を「対象チャンク番号」という。
【００４２】
ステップＳ１０１において、チャンク選択部１３３は、対象チャンク番号に係るチャンクのデータが、表セッションから取得されているか否かを判定する。当該判定は、表セッションバッファ１３４を参照することで可能である。当該データが表セッションバッファ１３４に記憶されている場合（Ｓ１０１でＹｅｓ）、チャンク選択部１３３は、当該データを表セッションバッファ１３４から取得して、取得されたデータを動画再生部１２に応答する（Ｓ１０２）。
【００４３】
当該チャンクのデータが表セッションから取得されていない場合（Ｓ１０１でＮｏ）、チャンク選択部１３３は、対象チャンク番号に係るチャンクのデータが、裏セッションから取得されているか否かを判定する（Ｓ１０３）。当該判定は、裏セッションバッファ１３５を参照することで可能である。当該データが裏セッションバッファ１３５に記憶されている場合（Ｓ１０３でＹｅｓ）、チャンク選択部１３３は、当該データを裏セッションバッファ１３５から取得して、取得されたデータを動画再生部１２に応答する（Ｓ１０４）。
【００４４】
当該データが裏セッションからも取得されていない場合（Ｓ１０３でＮｏ）、チャンク選択部１３３は、対象チャンク番号のデータが無いことを示す情報を、動画再生部１２に応答する（Ｓ１０５）。この場合、動画再生部１２による動画データの再生は停止する。
【００４５】
なお、チャンク選択部１３３は、図６のフローチャートにしたがってデータを応答した後、応答したデータ以前のチャンクのデータを、表セッションバッファ１３４及び裏セッションバッファ１３５のそれぞれから削除する。
【００４６】
また、チャンク選択部１３３は、ステップＳ１０１でＮｏの場合に、表セッションによるデータの取得が再生に間に合わなかったことを表セッション管理部１３１に通知してもよい。この場合、表セッション管理部１３１は、再生位置から一部のチャンクを除いて、データの取得を行ってもよい。すなわち、表セッション管理部１３１は、当該一部のチャンクのデータを取得しないようにしてもよい。そうすることで、表セッションによるデータの取得が、早期に再生に追いつくことができる。
【００４７】
図６の処理手順が実行されることにより、図７に示されるような動画再生が可能となる。図７は、本発明の実施の形態における動画再生の例を示す図である。
【００４８】
図７において、動画データ取得部１３は、動画データの各チャンクについて、表セッションを介してビットレートが相対的に高いデータを配信サーバ２０から取得しておき、裏セッションでビットレートが相対的に低いデータを配信サーバ２０から取得しておく。一般的に、或る１つのチャンクに着目すると、ビットレートの低いデータの方が、ビットレートが高いデータよりもデータ量が小さいため、先に取得することができる。したがって、或るチャンクについて、裏セッションの方がデータを早く取得することができる。なお、図７では、表セッションがチャンク２まで取得している時点で、裏セッションではチャンク５まで取得できている。
【００４９】
動画再生部１２は、チャンク１〜２のデータの再生が終わると、チャンク３のデータを動画データ取得部１３に要求する。この時、動画データ取得部１３のチャンク選択部１３３が表セッション及び裏セッションのそれぞれのデータの取得状況を確認する。チャンク３のデータは裏セッションでのみ取得できているため、チャンク選択部１３３は、裏セッションのチャンク３のデータを応答する。この場合、一時的に低ビットレートのデータが動画再生部１２によって再生されることになるが、再生は継続される。
【００５０】
上述したように、本実施の形態によれば、相対的に低いビットレートを先まで取得しておくことで、再生が停止するリスクを減らしながら、相対的に高いビットレートのデータが取得できたチャンクについては、当該高いビットレートのデータが再生される。
【００５１】
したがって、動画データの視聴品質の低下を抑制しつつ再生停止の頻度を低下させることができる。その結果、例えば、体感品質の向上や、ユーザエンゲージメントの向上等を期待することができる。
【００５２】
なお、本実施の形態において、表セッション管理部１３１は、第１の取得部の一例である。裏セッション管理部１３２は、第２の取得部の一例である。動画再生部１２は、再生部の一例である。
【００５３】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００５４】
１０          動画再生装置
１１          ＵＩ部
１２          動画再生部
１３          動画データ取得部
２０          配信サーバ
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
１０６        表示装置
１０７        入力装置
１３１        表セッション管理部
１３２        裏セッション管理部
１３３        チャンク選択部
１３４        表セッションバッファ
１３５        裏セッションバッファ
Ｂ            バス
【図１】
2018082241.tif 000004
【図２】
2018082241.tif 000005
【図３】
2018082241.tif 000006
【図４】
2018082241.tif 000007
【図５】
2018082241.tif 000008
【図６】
2018082241.tif 000009
【図７】
2018082241.tif 000010