JP7458848B2 - ユーザ端末及びプログラム - Google Patents

Description

本発明は、サーバからユーザ端末へ動画を配信するアダプティブストリーミングを行うシステムにおいて、ユーザ操作に従い動画を切り替えるユーザ端末及びプログラムに関する。

従来、テレビ放送を視聴するユーザは、別のチャンネルに切り替えるために、ザッピングを行うことがある。同様に、インターネットにより配信された動画（ネット動画）を視聴しているときも、ユーザは、別の動画に切り替えるために、ザッピングを行うことがある。

このようなザッピングにおいては、別の動画を再生するまでの時間が長ければ長いほど、ユーザの体感品質が低下し、当該動画の視聴を止めてしまう可能性がある。

一般に、ネット動画は、アダプティブストリーミングと呼ばれる方式により、インターネット経由でサーバからユーザ端末へ転送される。このときの動画データは、時間軸上で細切れにしたセグメントと呼ばれる単位で転送される。セグメントは、エンコードされた動画データを数秒単位に分割した動画ファイルである。例えば動画データの時間長は、１分、１０分、１時間等のように様々であり、セグメントの時間長も、１秒、５秒、１０秒等のように様々である。

アダプティブストリーミングには、例えばＭＰＥＧ－ＤＡＳＨ方式、ＨＬＳ方式がある。これらの方式は、基本的な動作フローが同じであり、インターネットが輻輳した場合においても、できる限り動画の再生を継続し、途切れが発生しないという特長がある。

この特長を実現するために、ユーザ端末は、バッファメモリを利用して所定数のセグメントをバッファリングした後、当該セグメントを動画デコーダへ受け渡す。

また、動画の切り替え前のセグメントと切り替え後のセグメントとを、それぞれ別のバッファメモリに格納する技術も開示されている（例えば、特許文献１を参照）。この技術により、バッファメモリに格納されたセグメントを再使用できる場合には、動画を速やかに再生することができる。

バッファリングされるセグメントの数は、例えば、３セグメント、５セグメント等のように様々であり、セグメント数が多ければ多いほど、インターネットが輻輳した場合に、動画の再生は途切れ難くなる。

しかしながら、バッファリングされるセグメントの数が多いほど、バッファリングに時間がかかってしまう。このため、ユーザ端末がセグメントの配信をサーバへ要求してから、動画の再生が開始されるまでの間の時間が長くなり、ユーザにとっては、視聴開始までの待ち時間が長くなる。

特開２０１７－１０８２１７号公報

前述のとおり、ユーザがネット動画をザッピングすると、直ちに別の動画に切り替わることはなく、切り替わるのに時間がかかってしまう。ザッピングは、視聴中の動画から別の動画への切替操作をいう。

これは、動画の切替操作が行われると、ユーザ端末が既にバッファリングした視聴中の動画の全セグメントを動画デコーダへ受け渡す必要があり、その後に、次に視聴する別の動画のセグメントを動画デコーダへ受け渡すからである。つまり、切替操作が行われたときに、既にバッファリングされた視聴中の動画のセグメントの数に応じて、切替時間、すなわち別の動画の視聴開始までの待ち時間が決定されることとなる。既にバッファリングされた視聴中の動画のセグメントの数が多いほど、待ち時間が長くなり、セグメントの数が少ないほど、待ち時間が短くなる。

例えば、バッファリングされた視聴中の動画のセグメントの数が４セグメント、セグメント長が４秒の場合、次に視聴する別の動画のセグメントを動画デコーダへ受け渡すまでの時間は、少なくとも４セグメント×４秒＝１６秒である。この１６秒が、そのままユーザの視聴開始までの待ち時間となる。

以下、視聴中の動画を切替操作前の動画といい、これから視聴する別の動画を切替操作後の動画という。この場合、受信バッファに格納されている切替操作前の動画の全てのセグメントの再生が完了した後に、切替操作後の動画の再生が行われる。

（従来技術の切替操作）
図５は、従来技術において、ケース１の場合の動画Ａから動画Ｂへの切替操作に伴う受信バッファに格納されたセグメントの変化、及び動画Ｂが切替再生されるタイミングを説明する図である。切替操作前の動画が動画Ａであり、切替操作後の動画が動画Ｂである。

横軸は再生時刻（秒）を示し、縦軸は受信バッファ時間（受信バッファに格納されたセグメントの動画時間）（秒）を示す。ｓｘｘにおけるｘｘは、セグメント番号を示す。細い実線で囲まれたセグメントは、動画Ａのセグメントの動画データを示し、太い実線で囲まれたセグメントは、動画Ｂのセグメントの動画データを示す。この例は、常にタイムスタンプが最新のセグメントがサーバから取得され、受信バッファに格納されるものとする。セグメント番号は、動画のセグメントを再生する順番を表す番号を示し、タイムスタンプは、動画のセグメントの先頭を再生する時刻を示す。

図５に示すように、例えば再生時刻ｔ１のタイミングにおいて、受信バッファには、動画Ａのｓ０１，ｓ０２のセグメント（の動画データ）が格納されており、動画Ａのｓ０３のセグメントの格納処理が開始されており、その一部が格納されていることを示している。また、このタイミングの受信バッファには、動画Ａのｓ０４のセグメントは格納されていない。

そして、再生時刻ｔ２のタイミングにおいて、動画Ａのｓ０３のセグメントの格納処理が完了し、受信バッファには、動画Ａのｓ０１，ｓ０２，ｓ０３のセグメントが格納されていることを示している。また、このタイミングの受信バッファには、動画Ａのｓ０４のセグメントは格納されておらず、動画Ａのｓ０４のセグメントの格納処理がまさに開始されることを示している。

また、例えば再生時刻ｔ３のタイミングにおいて、受信バッファには、動画Ａのｓ０６のセグメント及び動画Ｂのｓ０７，ｓ０８，ｓ０９のセグメントが格納されていることを示している。

ケース１は、１セグメント分の動画時間を４秒、受信バッファ時間を１６秒、動画ビットレートを１Ｍビット／秒、回線スループットを４Ｍビット／秒の条件を示している。後述する図６～図８についても同様である。

再生時刻０秒からセグメントの取得が開始され、セグメントが受信バッファ時間１６秒分取得されたときに、動画デコーダによる再生が開始される。動画デコーダが動画を再生する際には、１セグメント分の動画データが受信バッファから瞬時に読み出される。

ユーザ端末がサーバから動画を取得する際には、セグメントが受信バッファに受信バッファ時間１６秒分満たされるまで連続して取得される。そして、動画再生のために受信バッファから１つのセグメントが読み出されたときに、受信バッファに１つの空きが生じたとして、サーバからセグメントが取得される。

ケース１の条件から、サーバから１セグメント分の動画取得時間は、４秒×（１Ｍビット／秒）／（４Ｍビット／秒）＝１秒となる。動画再生のシナリオは、再生時刻１２秒のタイミングで、動画Ａから動画Ｂへの切替操作が行われるものとする。

図５を参照して、再生時刻４秒のタイミングにおいて、受信バッファには、動画Ａのｓ０１～ｓ０４のセグメントが受信バッファ時間１６秒分満たされるため、受信バッファから動画Ａのｓ０１のセグメントが読み出され再生される。そして、動画Ａのｓ０２～ｓ０４のセグメントがシフトして、受信バッファには１セグメント分の空きが生じる。そうすると、動画Ａのｓ０５のセグメントがサーバから取得されて受信バッファに追加される。

再生時刻８秒のタイミングにおいて、動画Ａのｓ０１のセグメントの再生が完了すると、受信バッファから動画Ａのｓ０２のセグメントが読み出され再生される。そして、動画Ａのｓ０３～ｓ０５のセグメントがシフトして、受信バッファには１セグメント分の空きが生じる。そうすると、動画Ａのｓ０６のセグメントがサーバから取得されて受信バッファに追加される。

再生時刻１２秒のタイミングにおいて、ユーザにより動画Ａから動画Ｂへの切替操作が行われる。このタイミングと同時に、動画Ａのｓ０２のセグメントの再生が完了し、受信バッファから動画Ａのｓ０３のセグメントが読み出され再生され、動画Ａのｓ０４～ｓ０６のセグメントがシフトして、受信バッファには１セグメント分の空きが生じるものとする。そうすると、切替操作後の動画Ｂにおけるｓ０７のセグメントがサーバから取得されて受信バッファに追加される。これにより、受信バッファは、切替操作前の動画Ａにおけるｓ０４～ｓ０６のセグメント及び切替操作後の動画Ｂにおけるｓ０７のセグメントが格納された状態となる。

再生時刻１６秒のタイミングにおいて、動画Ａのｓ０４のセグメントの読み出し及び再生が行われ、動画Ｂのｓ０８のセグメントの取得が行われる。これにより、動画Ａの再生が継続し、受信バッファは、動画Ａのｓ０５，ｓ０６のセグメント及び動画Ｂのｓ０７，ｓ０８のセグメントが格納された状態となる。

再生時刻２０秒のタイミングにおいて、動画Ａのｓ０５のセグメントの読み出し及び再生が行われ、動画Ｂのｓ０９のセグメントの取得が行われる。これにより、動画Ａの再生が継続し、受信バッファは、前述した再生時刻ｔ３のタイミングのように、動画Ａのｓ０６のセグメント及び動画Ｂのｓ０７～ｓ０９のセグメントが格納された状態となる。

再生時刻２４秒のタイミングにおいて、動画Ａのｓ０６のセグメントの読み出し及び再生が行われ、動画Ｂのｓ１０のセグメントの取得が行われる。これにより、動画Ａの再生が継続し、受信バッファは、動画Ｂのｓ０７～ｓ１０のセグメントが格納された状態となる。

再生時刻２８秒のタイミングにおいて、動画Ｂのｓ０７のセグメントの読み出し及び再生が行われ（枠で囲まれたｓ０７）、動画Ｂのｓ１１のセグメントの取得が行われる。これにより、動画Ａの再生が終了し、動画Ｂの再生に切り替わる。受信バッファは、動画Ｂのｓ０８～ｓ１１のセグメントが格納された状態となる。そして、動画Ｂの再生が継続する。

このように、ユーザにより動画Ａから動画Ｂへの切替操作が行われると、受信バッファに格納されている切替操作前の動画Ａの全てのセグメントの再生が完了した後に、切替操作後の動画Ｂの再生が行われる。

図５に示したように、切替操作が行われると、動画Ａから動画Ｂに直ちに切り替わることはなく、１６秒（２８－１２＝１６）の切替時間がかかってしまう。ユーザは、バッファリングされた動画Ａのｓ０３～ｓ０６のセグメントが受け渡されるまで、１６秒の間待つ必要があり、切り替わるのに時間がかかるという問題があった。

このため、ユーザによる動画Ａから動画Ｂへの切替操作に伴い、動画の切替時間を短縮することが所望されていた。

そこで、本件特許出願の同一の出願人により、本件特許出願時に未公開の特願２０１９－１２８３６号公報記載の発明が提案されている。この特願２０１９－１２８３６号公報記載の発明は、切替操作が行われると、ダウンロード予測時間に基づいて新たな動画Ｂの上書領域（上書きするセグメント番号）を決定し、動画Ｂをその上書領域から上書きするものである。

（特願２０１９－１２８３６号公報記載の発明の切替操作）
図６は、特願２０１９－１２８３６号公報記載の発明において、ケース１の場合の動画Ａから動画Ｂへの切替操作に伴う受信バッファに格納されたセグメントの変化、及び動画Ｂが切替再生されるタイミングを説明する図である。

横軸は再生時刻（秒）を示し、縦軸は受信バッファ時間（受信バッファに格納されたセグメントの動画時間）（秒）を示す。ケース１の条件、受信バッファからのセグメントの読み出し動作、受信バッファへの格納動作、サーバからの取得動作等は、図５にて説明したとおりである。この例では、サーバから取得されるセグメントのタイムスタンプは、当該セグメントが受信バッファに追加または上書される位置、及び受信バッファに格納されているセグメントのタイムスタンプに応じて、選択されるものとする。

図６を参照して、再生時刻４秒及び８秒のタイミングにおける動作は、図５と同様である。

再生時刻１２秒のタイミングにおいて、ユーザにより動画Ａから動画Ｂへの切替操作が行われる。このタイミングと同時に、動画Ａのｓ０２のセグメントの再生が完了し、受信バッファから動画Ａのｓ０３のセグメントが読み出され再生され、動画Ａのｓ０４～ｓ０６のセグメントがシフトして、受信バッファには１セグメント分の空きが生じるものとする。このタイミングにおいて、ダウンロード予測時間に基づいて、上書領域として例えば動画Ａのｓ０５のセグメントが決定される。

そうすると、切替操作後の動画Ｂにおけるｓ０５のセグメントがサーバから取得され、動画Ｂのｓ０５のセグメントが、受信バッファに格納された動画Ａのｓ０５のセグメントの領域に上書きされる。これにより、受信バッファは、動画Ａのｓ０４のセグメント、動画Ｂのｓ０５及び動画Ａのｓ０６のセグメントが格納された状態となる。

そして、動画Ｂのｓ０６，ｓ０７のセグメントがサーバから取得され、動画Ｂのｓ０６のセグメントが、受信バッファに格納された動画Ａにおけるｓ０６のセグメントの領域に上書きされ、動画Ｂのｓ０７のセグメントが追加される。これにより、受信バッファは、切替操作前の動画Ａのｓ０４のセグメント及び切替操作後の動画Ｂのｓ０５～ｓ０７のセグメントが格納された状態となる。

再生時刻１６秒のタイミングにおいて、動画Ａのｓ０４のセグメントの読み出し及び再生が行われ、動画Ｂのｓ０８のセグメントの取得が行われる。これにより、動画Ａの再生が継続し、受信バッファは、動画Ｂのｓ０５～ｓ０８のセグメントが格納された状態となる。

再生時刻２０秒のタイミングにおいて、動画Ｂのｓ０５のセグメントの読み出し及び再生が行われ（枠で囲まれたｓ０５）、動画Ｂのｓ０９のセグメントの取得が行われる。これにより、動画Ａの再生が終了し、動画Ｂの再生に切り替わり、これ以降は、動画Ｂの再生が継続する。つまり、再生時刻２０秒のタイミングで切替再生が行われることとなる。

このように、特願２０１９－１２８３６号公報記載の発明の場合には、切替操作が行われると、ダウンロード予測時間に基づいて新たな動画Ｂの上書領域（上書きするセグメント番号）が決定され、新たな動画Ｂがその上書領域から上書きされる。

図６に示したように、動画Ａから動画Ｂへの切替時間は、８秒（２０－１２＝８）であり、図５に示した切替時間１６秒よりも短い。これにより、切替操作が行われると、受信バッファに格納されている動画Ａの全てのセグメントの再生の完了を待つことなく、上書きされた動画Ｂの再生が行われる。このため、切替操作に伴う動画の切替時間を短縮することができる。

しかしながら、特願２０１９－１２８３６号公報記載の発明では、インターネットの回線の遅延または帯域の変動により、ダウンロードの回線スループットが低下した場合、切替操作の際に切り替え前後の動画が交互に再生されて動画が乱れる可能性がある。また、受信バッファに格納されたセグメントの数が低下し、再生が停止する可能性もある。

例えば図６において、再生時刻１２秒のタイミングで切替操作が行われた後に、新たな動画Ｂのｓ０５のセグメントがサーバから取得された場合を想定する。この場合、受信バッファは、動画Ａのｓ０４のセグメント、動画Ｂのｓ０５のセグメント及び動画Ａのｓ０６のセグメントが格納されている状態となる。

ここで、引き続き新たな動画Ｂのｓ０６のセグメントがサーバから取得されるが、ダウンロードの回線スループットが低下すると、動画Ｂのｓ０６のセグメントは、受信バッファに格納された動画Ａのｓ０６の領域への上書きが遅れてしまう。そうすると、動画Ａのｓ０３，ｓ０４のセグメントの再生が完了した後、動画Ｂのｓ０５のセグメントの再生が行われ、そして、動画Ａのｓ０６のセグメントの再生が行われることとなり得る。

つまり、動画Ａ，Ｂの１セグメントをそれぞれＡ，Ｂとすると、再生は、Ａ→Ａ→Ｂ→Ｂ→Ｂ→Ｂ・・・となるべきところ、Ａ→Ａ→Ｂ→Ａ→Ｂ→Ｂ・・・となってしまう。このように、切替操作時には、切り替え前後の動画が交互に再生されて乱れるという不体裁が発生する可能性があり、一層安定した再生を実現できることが望まれていた。

そこで、本発明は前記課題を解決するためになされたものであり、その目的は、ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮すると共に、不体裁の発生を防止するユーザ端末及びプログラムを提供することにある。

前記課題を解決するために、請求項１のユーザ端末は、サーバからインターネットを介して配信された動画のセグメントを受信し、前記セグメントをバッファリングして読み出し、前記セグメントをデコードして再生するユーザ端末において、前記インターネットを介して受信したそれぞれの前記セグメントを、受信バッファの最前領域から最後領域まで格納する受信バッファ管理部と、前記受信バッファの前記最前領域に格納された前記セグメントを読み出し、当該セグメントをデコードする動画デコーダと、を備え、前記受信バッファ管理部が、ユーザにより新たな動画を再生するための切替操作が行われると、前記受信バッファに前記セグメントを格納するための空き領域がある場合、前記新たな動画の切替後セグメントを取得し、当該切替後セグメントを前記受信バッファの前記空き領域に追加し、前記空き領域がなく、かつ前記受信バッファに再生中の前記動画の切替前セグメントが格納されている場合、前記受信バッファに格納された全ての前記切替前セグメントのうち最後に読み出される前記切替前セグメントを最後部の前記切替前セグメントとして特定し、新たな前記動画の切替後セグメントを取得し、当該切替後セグメントを、前記受信バッファにおける前記最後部の前記切替前セグメントが格納された領域に上書きする、ことを特徴とする。

また、請求項２のユーザ端末は、請求項１に記載のユーザ端末において、前記受信バッファ管理部は、セグメント要求部及び格納処理部を備え、前記ユーザにより前記切替操作が行われると、前記セグメント要求部が、前記受信バッファに前記セグメントを格納するための前記空き領域があるかないかを判定し、前記空き領域があると判定した場合、前記受信バッファに格納された全ての前記セグメントのうち前記最後部を特定し、当該最後部の次のセグメントにおけるセグメント番号またはタイムスタンプを特定し、当該セグメント番号または当該タイムスタンプに対応する前記切替後セグメントを取得するためのセグメント要求として、第１セグメント要求を生成し、前記格納処理部が、前記セグメント要求部により生成された前記第１セグメント要求に対応する前記切替後セグメントを取得し、当該切替後セグメントを前記受信バッファの前記空き領域に追加し、前記セグメント要求部が、前記空き領域が無いと判定した場合、前記受信バッファに前記切替前セグメントが格納されているか否かを判定し、前記切替前セグメントが格納されていると判定した場合、前記受信バッファに格納された全ての前記切替前セグメントのうち前記最後部を特定し、当該最後部のセグメントにおけるセグメント番号またはタイムスタンプを特定し、当該セグメント番号または当該タイムスタンプに対応する前記切替後セグメントを取得するためのセグメント要求として、第２セグメント要求を生成し、前記格納処理部が、前記セグメント要求部により生成された前記第２セグメント要求に対応する前記切替後セグメントを取得し、当該切替後セグメントを、前記受信バッファの前記最後部の領域に上書きする、ことを特徴とする。

さらに、請求項３のプログラムは、コンピュータを、請求項１または２に記載のユーザ端末として機能させることを特徴とする。

以上のように、本発明によれば、ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮すると共に、不体裁の発生を防止して一層安定した再生を実現することができる。

本発明の実施形態によるユーザ端末を含む全体システムの構成例を示す概略図である。 受信バッファ管理部の処理を示すフローチャートである。 受信バッファ管理部の構成を示すブロック図である。 動画切替時のセグメント取得処理（Ｓ２０２）を示すフローチャートである。 従来技術において、ケース１の場合の動画Ａから動画Ｂへの切替操作に伴う受信バッファに格納されたセグメントの変化、及び動画Ｂが切替再生されるタイミングを説明する図である。 特願２０１９－１２８３６号公報記載の発明において、ケース１の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。 本発明の実施形態において、ケース１の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。 図７において、動画Ｂのｓ０４のセグメントの取得が遅れた場合を説明する図である。 従来技術において、ケース２の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。 特願２０１９－１２８３６号公報記載の発明において、ケース２の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。 本発明の実施形態において、ケース２の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。

以下、本発明を実施するための形態について図面を用いて詳細に説明する。本発明は、ユーザによる動画の切替操作時に、受信バッファに空きがある場合、切替操作後の新たな動画を受信バッファの空き領域に追加する。また、本発明は、受信バッファに空きがなく、切替操作前の動画が格納されている場合、新たな動画を、受信バッファに格納された全ての切替操作前の動画（再生中の動画）のセグメントのうち最後部のセグメント（最後に読み出されるセグメント）の領域に上書きする。

これにより、切替操作時の受信バッファには、新たな動画のセグメントが追加または上書きされるため、受信バッファに格納されたセグメントの数の低下を抑えることができる。また、新たな動画のセグメントは、受信バッファの連続した領域に順次格納されることとなる。

したがって、ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮することができ、動画が交互に再生されて乱れるという不体裁の発生を防止し、一層安定な再生を実現することができる。

〔全体システム〕
まず、本発明の実施形態によるユーザ端末を含む全体システムについて説明する。図１は、本発明の実施形態によるユーザ端末を含む全体システムの構成例を示す概略図である。

このシステムは、ユーザ端末１及びサーバ２を備えて構成され、サーバ２のストレージ４に格納された動画を、サーバ２からインターネット３を介してユーザ端末１へ配信するアダプティブストリーミングを行う。ユーザ端末１及びサーバ２は、インターネット３を介して接続される。インターネット３は、例えばオープンインターネットである。

ユーザ端末１は、通信インターフェース１０、ＯＳ（オペレーティングシステム）１１、ＷＥＢブラウザ１２、受信バッファ管理部１３、動画デコーダ１４及び表示部１５を備えている。ユーザ端末１は、パーソナルコンピュータであってもよいし、スマートフォン等の携帯型の端末装置であってもよい。要するに、ユーザ端末１は、サーバ２から動画をセグメント毎にダウンロードし、これをバッファリングして再生する機能を有していれば何でもよい。

通信インターフェース１０は、当該ユーザ端末１とサーバ２との間で、インターネット３を介して所定のプロトコルに従いデータの送受信を行う。通信インターフェース１０は、例えばEthernet（イーサネット（登録商標））の規格に従って動作する。

ＯＳ１１は、各種のプログラムの実行を制御するためのソフトウェアであり、基本的な機能として、通信インターフェース１０、ＷＥＢブラウザ１２、受信バッファ管理部１３、動画デコーダ１４及び表示部１５を管理する。ＯＳ１１は、例えばWindows（登録商標）であってもよいし、iOSであってもよい。

ＷＥＢブラウザ１２は、ＷＥＢページを閲覧するためのソフトウェアであり、例えばInternet Explorer（インターネットエクスプローラー、登録商標）であってもよいし、Chrome（クローム、登録商標）であってもよい。

受信バッファ管理部１３は、サーバ２から配信された動画のセグメントを、受信バッファの最前領域から最後領域まで順番にバッファリングし、当該セグメントを最前領域から動画デコーダ１４へ受け渡す。最前領域は、動画デコーダ１４により読み出されるセグメントの領域であり、最後領域は、セグメントが格納されることで受信バッファが満杯となる当該セグメントの領域である。

受信バッファ管理部１３は、ユーザによる動画の切替操作を検知すると、図５に示した従来技術及び図６に示した特願２０１９－１２８３６号公報記載の発明に代わる新方式にて、動画の切替処理を行う。

具体的には、受信バッファ管理部１３は、受信バッファに空きがある場合、サーバ２から送信された切替操作後の動画のセグメントを、受信バッファの空き領域に追加する。一方、受信バッファ管理部１３は、受信バッファに空きがなく、かつ受信バッファに切替操作前の動画が格納されている場合、サーバ２から送信された切替操作後の動画のセグメントを、受信バッファに格納されている全ての切替操作前の動画のセグメントのうち最後部のセグメントの領域に上書きする。

また、受信バッファ管理部１３は、受信バッファに空きがなく、かつ受信バッファに切替操作前の動画が格納されていない場合、通常の処理を行う。つまり、受信バッファ管理部１３は、受信バッファが空きとなるのを待って、サーバ２から送信された切替操作後の動画のセグメントを、受信バッファの空き領域に追加する。尚、サーバ２から送信されるセグメントのタイムスタンプは、前述の図６と同様に、当該セグメントが受信バッファに追加または上書される位置、及び受信バッファに格納されているセグメントのタイムスタンプに応じて、選択されるものとする。

図１に戻って、動画デコーダ１４は、受信バッファ管理部１３からセグメントを読み出し、Ｈ２６４、Ｈ２６５等の各種符号化方式で符号化されたセグメントの動画データをデコードし、表示部１５に表示する。これにより、動画の再生が行われる。表示部１５は、テレビ画面であってもよいし、パソコン用モニタの画面であってもよい。

サーバ２は、ユーザ端末１からインターネット３を介してセグメント要求を受信し、当該セグメント要求に対応する動画のセグメントをストレージ４から読み出し、読み出したセグメントを、インターネット３を介してユーザ端末１へ送信する。サーバ２は、動画を配信可能なコンピュータ装置であれば何でもよい。

〔受信バッファ管理部１３〕
次に、図１に示したユーザ端末１の受信バッファ管理部１３について詳細に説明する。図２は、受信バッファ管理部１３の処理を示すフローチャートである。

ユーザ端末１を操作するユーザがある動画を視聴しているものとする。ユーザにより、視聴中の動画を新たな動画に切り替える操作が行われると、当該切替操作に伴う動画切替要求が受信バッファ管理部１３に入力される。

受信バッファ管理部１３は、動画切替要求を入力したか否かを判定する（ステップＳ２０１）。受信バッファ管理部１３は、ステップＳ２０１において、動画切替要求を入力したと判定した場合（ステップＳ２０１：Ｙ）、動画切替時のセグメント取得処理を行い（ステップＳ２０２）、ステップＳ２０３へ移行する。ステップＳ２０２の動画切替時のセグメント取得処理については後述する。

一方、受信バッファ管理部１３は、ステップＳ２０１において、動画切替要求を入力していないと判定した場合（ステップＳ２０１：Ｎ）、ステップＳ２０３へ移行する。

受信バッファ管理部１３は、ステップＳ２０２またはステップＳ２０１（Ｎ）から移行して、通常時のセグメント取得処理を行う（ステップＳ２０３）。

具体的には、受信バッファ管理部１３は、受信バッファに空きがある場合、視聴中の動画のセグメントをサーバ２から順次取得し、受信バッファの空き領域に追加する。受信バッファが所定の受信バッファ時間満たされるまで、連続した取得及び追加処理が行われる。受信バッファに格納されたセグメントは、動画デコーダ１４により読み出され再生される。

受信バッファ管理部１３は、ステップＳ２０３から移行して、処理が終了しない限り、ステップＳ２０１～Ｓ２０３の処理を継続する（ステップＳ２０４）。

図３は、受信バッファ管理部１３の構成を示すブロック図である。この受信バッファ管理部１３は、受信バッファ２０、セグメント要求部２１及び格納処理部２２を備えている。受信バッファ２０には、動画のセグメントが格納される。

セグメント要求部２１は、図２のステップＳ２０３における通常時のセグメント取得処理において、受信バッファ２０に空きがある場合、受信バッファ２０に格納されている全てのセグメントのうち最後部の次のセグメント番号（ＳＧ番号）を特定する。そして、セグメント要求部２１は、当該ＳＧ番号のセグメントを取得するためのセグメント要求（ＳＧ要求）を生成して通信インターフェース１０に出力する。ＳＧ要求は、通信インターフェース１０からサーバ２へ送信される。

セグメント要求部２１は、ユーザによる動画の切替操作に伴う動画切替要求を入力すると、図２のステップＳ２０２における動画切替時のセグメント取得処理において、受信バッファ２０に格納されたセグメントの格納状況を確認する。

セグメント要求部２１は、当該格納状況に応じて、サーバ２から取得する切替操作後の動画のセグメントのＳＧ番号を決定し、ＳＧ番号を格納処理部２２に出力する。セグメント要求部２１は、切替操作後の動画の当該ＳＧ番号のセグメントを取得するためのＳＧ要求を生成して通信インターフェース１０に出力する。ＳＧ要求は、通信インターフェース１０からサーバ２へ送信される。

セグメント要求部２１は、受信バッファ２０に格納された全てのセグメントが新たな動画のセグメントである場合、動画切替時のセグメント取得処理が完了したとして、通常時のセグメント取得処理へ移行する。

格納処理部２２は、セグメント要求部２１からＳＧ番号を入力し、サーバ２から取得した当該ＳＧ番号のセグメントを、受信バッファ２０における当該ＳＧ番号の領域に格納する。

ここで、取得した当該ＳＧ番号のセグメントは、受信バッファ２０の空き領域に追加されるか、または、同じＳＧ番号のセグメントが格納されている領域に上書きされることとなる。

具体的には、格納処理部２２は、図２のステップＳ２０３における通常時のセグメント取得処理において、サーバ２から取得した切替操作後の当該ＳＧ番号のセグメントを受信バッファ２０の空き領域に追加する。

受信バッファ２０には、動画デコーダ１４により読み出されるセグメントが格納された最前領域から、セグメントが格納されることで当該受信バッファ２０が満杯となる最後領域までの間のそれぞれの領域に、セグメントが格納される。セグメントは、空き領域のうち最前領域に最も近い領域（最前部）から順番に追加される。

また、格納処理部２２は、図２のステップＳ２０２における動画切替時のセグメント取得処理において、サーバ２から取得した切替操作後の動画の当該ＳＧ番号のセグメントを、受信バッファ２０における当該ＳＧ番号の領域に上書きする。

（動画切替時のセグメント取得処理（Ｓ２０２））
図４は、図２に示した動画切替時のセグメント取得処理（Ｓ２０２）を示すフローチャートである。

セグメント要求部２１は、図２のステップＳ２０１において、動画切替要求を入力した場合、ユーザによる動画の切替操作があったことを認識する。そして、セグメント要求部２１は、受信バッファ２０に空きがあるかないかを判定する（ステップＳ４０１）。

セグメント要求部２１は、ステップＳ４０１において、受信バッファ２０に空きがあると判定した場合（ステップＳ４０１：Ｙ）、受信バッファ２０に格納された最後部のセグメントを特定する。そして、セグメント要求部２１は、当該最後部の次のセグメントのＳＧ番号を特定し、当該ＳＧ番号を取得ＳＧ番号ｓａに決定する（ステップＳ４０２）。

セグメント要求部２１は、ステップＳ４０２にて決定した切替操作後の動画における取得ＳＧ番号ｓａのセグメント（新たな動画の切替後セグメント）を取得するためのＳＧ要求（ｓａ）を生成する。そして、セグメント要求部２１は、当該ＳＧ要求（ｓａ）を通信インターフェース１０に出力する（ステップＳ４０３）。これにより、ＳＧ要求（ｓａ）はサーバ２へ送信され、サーバ２から切替操作後の動画における取得ＳＧ番号ｓａのセグメントが送信される。セグメント要求部２１は、取得ＳＧ番号ｓａを格納処理部２２に出力する。

格納処理部２２は、通信インターフェース１０から切替操作後の動画における取得ＳＧ番号ｓａのセグメントを入力し、当該セグメントを受信バッファ２０の空き領域に追加する（ステップＳ４０４）。これにより、受信バッファ２０には、切替操作後の新たな動画が格納される。

一方、セグメント要求部２１は、ステップＳ４０１において、受信バッファ２０に空きがないと判定した場合（ステップＳ４０１：Ｎ）、受信バッファ２０に切替操作前の動画のセグメント（再生中の動画の切替前セグメント）が格納されているか否かを判定する（ステップＳ４０５）。

セグメント要求部２１は、ステップＳ４０５において、受信バッファ２０に切替操作前の動画のセグメントが格納されていると判定した場合（ステップＳ４０５：Ｙ）、受信バッファ２０に格納された切替操作前の動画のセグメントのうち最後部のセグメントを特定する。そして、セグメント要求部２１は、当該セグメントのＳＧ番号を特定し、当該ＳＧ番号を取得ＳＧ番号ｓｂに決定する（ステップＳ４０６）。

セグメント要求部２１は、ステップＳ４０６にて決定した切替操作後の動画における取得ＳＧ番号ｓｂのセグメントを取得するためのＳＧ要求（ｓｂ）を生成し、当該ＳＧ要求（ｓｂ）を通信インターフェース１０に出力する（ステップＳ４０７）。これにより、ＳＧ要求（ｓｂ）はサーバ２へ送信され、サーバ２から切替操作後の動画における取得ＳＧ番号ｓｂのセグメントが送信される。セグメント要求部２１は、取得ＳＧ番号ｓｂを格納処理部２２に出力する。

格納処理部２２は、通信インターフェース１０から切替操作後の動画における取得ＳＧ番号ｓｂのセグメントを入力し、当該セグメントを、受信バッファ２０に格納された切替操作前の動画における取得ＳＧ番号ｓｂのセグメントの領域に上書きする（ステップＳ４０８）。これにより、受信バッファ２０には、切替操作後の新たな動画が切替操作前の動画の領域に格納される。

一方、セグメント要求部２１は、ステップＳ４０５において、受信バッファ２０に切替操作前の動画のセグメントが格納されていないと判定した場合（ステップＳ４０５：Ｎ）、当該動画切替時のセグメント取得処理を終了する。これにより、図２のステップＳ２０３における通常時のセグメント取得処理へ移行する。

このように、ユーザによる動画の切替操作が行われると、動画切替時のセグメント取得処理が行われる。サーバ２から取得された切替操作後の動画のセグメントは、受信バッファ２０に空きがある場合、最前領域（動画デコーダ１４により読み出されるセグメントの領域）から最後領域（セグメントが格納されることで受信バッファ２０が満杯となる当該セグメントの領域）へ向けて、その空きが埋まるように追加される。また、切替操作後の動画のセグメントは、受信バッファ２０に空きがなく、切替操作前の動画が格納されている場合、最後領域から最前領域へ向けて、切替操作前の動画が格納された最後部（最後領域側の部分）から最前部（最前領域側の部分）まで順番に上書きされる。

〔切替操作時の動作例〕
次に、切替操作時の動作例について説明する。図７は、本発明の実施形態において、ケース１の場合の動画Ａから動画Ｂへの切替操作に伴う受信バッファ２０に格納されたセグメントの変化、及び動画Ｂが切替再生されるタイミングを説明する図である。

横軸は再生時刻（秒）を示し、縦軸は受信バッファ時間（受信バッファ２０に格納されたセグメントの動画時間）（秒）を示す。ケース１の条件、受信バッファ２０からのセグメントの読み出し動作、受信バッファ２０への格納動作、サーバ２からの取得動作等は、図５にて説明したとおりである。

図７を参照して、再生時刻４秒及び８秒のタイミングにおける動作は、図５と同様である。

再生時刻１２秒のタイミングにおいて、ユーザにより動画Ａから動画Ｂへの切替操作が行われる。このタイミングと同時に、動画デコーダ１４により受信バッファ２０から動画Ａのｓ０３のセグメントが読み出され再生され、ｓ０４～ｓ０６のセグメントがシフトして、受信バッファ２０には１セグメント分の空きが生じるものとする。切替操作に伴い、動画切替要求がセグメント要求部２１に入力され、動画切替時のセグメント取得処理が開始する。

セグメント要求部２１は、受信バッファ２０に空きがあると判定し、最後部のセグメントのＳＧ番号が０６であるため、その次のＳＧ番号０７を取得ＳＧ番号ｓａ＝０７に決定する。そして、セグメント要求部２１は、切替操作後の動画Ｂにおける取得ＳＧ番号ｓａ＝０７のセグメントを取得するためのＳＧ要求（ｓａ＝０７）を出力する。このＳＧ要求（ｓａ＝０７）は、サーバ２へ送信される。

そうすると、切替操作後の動画Ｂにおけるｓ０７のセグメントがサーバ２から送信され、ユーザ端末１はこれを取得する。格納処理部２２は、切替操作後の動画Ｂにおけるｓ０７のセグメントを受信バッファ２０に追加する。

これにより、受信バッファ２０は、切替操作前の動画Ａにおけるｓ０４～ｓ０６のセグメント、及び切替操作後の動画Ｂにおけるｓ０７のセグメントが格納された状態となる（再生時刻ｔ１のタイミングを参照）。

そして、セグメント要求部２１は、受信バッファ２０に空きがなく、切替操作前の動画Ａのセグメントが格納されていると判定する。セグメント要求部２１は、切替操作前の動画Ａのセグメントのうち最後部のセグメントのＳＧ番号０６を取得ＳＧ番号ｓｂ＝０６に決定する。そして、セグメント要求部２１は、切替後の動画Ｂにおける取得ＳＧ番号ｓｂ＝０６のセグメントを取得するためのＳＧ要求（ｓｂ＝０６）を出力する。このＳＧ要求（ｓｂ＝０６）は、サーバ２へ送信される。

そうすると、切替操作後の動画Ｂにおけるｓ０６のセグメントがサーバ２から送信され、ユーザ端末１はこれを取得する。格納処理部２２は、切替操作後の動画Ｂにおけるｓ０６のセグメントを、受信バッファ２０に格納された切替操作前の動画Ａにおける取得ＳＧ番号ｓｂ＝０６のセグメントの領域に上書きする。

これにより、受信バッファ２０は、切替操作前の動画Ａにおけるｓ０４，ｓ０５のセグメント、及び切替操作後の動画Ｂにおけるｓ０６，ｓ０７のセグメントが格納された状態となる（再生時刻ｔ２のタイミングを参照）。

同様にして、セグメント要求部２１は、切替操作後の動画Ｂにおける取得ＳＧ番号ｓｂ＝０５のセグメントを取得するためのＳＧ要求（ｓｂ＝０５）を出力する。そして、格納処理部２２は、切替操作後の動画Ｂにおけるｓ０５のセグメントを、受信バッファ２０に格納された切替操作前の動画Ａにおけるｓ０５のセグメントの領域に上書きする。

セグメント要求部２１は、切替操作後の動画Ｂにおける取得ＳＧ番号ｓｂ＝０４のセグメントを取得するためのＳＧ要求（ｓｂ＝０４）を出力する。そして、格納処理部２２は、切替操作後の動画Ｂにおけるｓ０４のセグメントを、受信バッファ２０に格納された切替操作前の動画Ａにおけるｓ０４のセグメントの領域に上書きする。

これにより、受信バッファ２０は、切替操作後の動画Ｂにおけるｓ０４～ｓ０７のセグメントが格納された状態となる（再生時刻ｔ３のタイミングを参照）。

再生時刻１６秒のタイミングにおいて、動画Ｂのｓ０４のセグメントの読み出し及び再生が行われ（枠で囲まれたｓ０４）、動画Ｂのｓ０８のセグメントの取得が行われる。これにより、動画Ａの再生が終了し、動画Ｂの再生に切り替わり、これ以降は動画Ｂの再生が継続する。つまり、再生時刻１６秒のタイミングで切替再生が行われることとなる。

このように、本発明の実施形態では、切替操作が行われると、受信バッファ２０に空きがある場合、切替操作後の動画Ｂのセグメントは受信バッファ２０に追加される。一方、受信バッファ２０に空きがなく、かつ切替操作前の動画Ａが格納されている場合、新たな動画Ｂのセグメントは、切替操作前の動画Ａの最後部の領域に上書きされる。そして、受信バッファ２０に空きがなく、かつ切替操作前の動画Ａが格納されていない場合、通常時のセグメント取得処理が行われる。

図７に示したように、動画Ａから動画Ｂへの切替時間は、４秒（１６－１２＝４）であり、図５に示した切替時間１６秒及び図６に示した切替時間８秒よりも短い。これにより、切替操作に伴う動画の切替時間を短縮することができる。

（動画Ｂのｓ０４の取得が遅れた場合）
図７に示した例は、ケース１の条件である回線スループットが４Ｍビット／秒に維持された場合を示している。回線スループットが４Ｍビット／秒に維持されることにより、動画Ｂのｓ０４のセグメントが受信バッファ２０に上書きされた直後に、動画デコーダ１４により、受信バッファ２０から動画Ｂのｓ０４のセグメントが読み出され再生される。このため、切替再生のタイミングは再生時刻１６秒となる。

ここで、サーバ２から動画Ｂのｓ０４のセグメントが送信されているときに、回線スループットが４Ｍビット／秒未満となった場合を想定する。この場合、動画Ｂのｓ０４のセグメントの上書き完了時刻は、再生時刻１６秒よりも遅れてしまい、再生時刻１６秒のタイミングにおいて、動画Ｂのｓ０４のセグメントを再生することができない。動画Ａから動画Ｂへの切替再生のタイミングは、再生時刻１６秒よりも遅れることとなる。

図８は、図７において、動画Ｂのｓ０４のセグメントの取得が遅れた場合を説明する図である。回線スループットが４Ｍビット／秒未満となったため（点線αを参照）、動画Ａのｓ０３のセグメントの再生が完了する再生時刻１６秒のタイミングにおいて、動画Ｂのｓ０４のセグメントの上書きが完了していない。動画デコーダ１４は、受信バッファ２０から動画Ｂのｓ０４のセグメントを読み出して再生することができない。

このため、再生時刻１６秒のタイミングにおいて、動画Ａのｓ０４のセグメントの読み出し及び再生が行われ、動画Ｂのｓ０８のセグメントの取得が行われる。これにより、受信バッファ２０は、動画Ｂのｓ０５～ｓ０８のセグメントが格納された状態となる。

そして、再生時刻２０秒のタイミングにおいて、動画Ｂのｓ０５のセグメントの読み出し及び再生が行われる（枠で囲まれたｓ０５）。これにより、動画Ａの再生が終了し、動画Ｂの再生に切り替わり、これ以降は動画Ｂの再生が継続する。つまり、図７に示した再生時刻１６秒よりも遅れた再生時刻２０秒のタイミングで、切替再生が行われることとなる。

前述のとおり、図６に示した特願２０１９－１２８３６号公報記載の発明の例では、切替操作時に回線スループットが低下すると、受信バッファ２０に格納されたセグメントの数が低下する。また、切り替え前後の動画Ａ，Ｂが交互に再生されて乱れるという不体裁が発生する可能性がある。

これに対し、本発明の実施形態では、受信バッファ２０に空きがある場合に、動画Ｂのセグメントは、受信バッファ２０の最前領域から最後領域へ向けてその空きが埋まるように追加される。また、受信バッファ２０に空きがなく、動画Ａが格納されている場合に、動画Ｂのセグメントは、動画Ａの最後部から最前部へ向けて順番に上書きされる。このため、切替操作時に回線スループットが低下した場合であっても、受信バッファ２０は、動画Ｂのセグメントが連続した領域に格納された状態となる。

したがって、本発明の実施形態では、受信バッファ２０に格納されたセグメントの数の低下を抑えることができ、動画Ａ，Ｂが交互に再生されて乱れるという不体裁の発生を防止することができる。

〔切替操作時の他の動作例〕
次に、切替操作時の他の動作例について説明する。図９は、従来技術において、ケース２の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。図１０は、特願２０１９－１２８３６号公報記載の発明において、ケース２の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。図１１は、本発明の実施形態において、ケース２の場合のセグメントの変化及び動画Ｂの切替再生タイミングを説明する図である。

図９、図１０及び図１１において、横軸は再生時刻（秒）を示し、縦軸は受信バッファ時間（秒）を示す。細い実線で囲まれたセグメントは、動画Ａのセグメントの動画データを示し、太い実線で囲まれたセグメントは、動画Ｂのセグメントの動画データを示す。

ケース２は、１セグメント分の動画時間を４秒、受信バッファ時間を３２秒、動画ビットレートを１Ｍビット／秒、回線スループットを４Ｍビット／秒の条件を示している。図５～図８に示したケース１とこのケース２とを比較すると、受信バッファ時間が異なり、その他の条件は同じである。ケース１の受信バッファ時間は１６秒であるのに対し、ケース２の受信バッファ時間は３２秒である。

再生時刻０秒からセグメントの取得が開始され、セグメントが受信バッファ時間３２秒分取得されたときに、動画デコーダ１４による再生が開始される。動画デコーダ１４が動画を再生する際には、１セグメント分の動画データが受信バッファから瞬時に読み出される。

ケース２の条件から、ケース１の場合と同様に、サーバ２から１セグメント分の動画取得時間は、４秒×（１Ｍビット／秒）／（４Ｍビット／秒）＝１秒となる。動画再生のシナリオは、再生時刻１６秒のタイミングで、動画Ａから動画Ｂへの切替操作が行われるものとする。

図９を参照して、従来技術では、切替操作が行われると、受信バッファ２０に格納されている動画Ａの全てのセグメントの再生が完了した後に、動画Ｂの再生が行われる。

このため、従来技術の場合、動画Ａから動画Ｂへの切替再生のタイミングは、再生時刻４８秒となり、動画Ａから動画Ｂへの切替時間は、３２秒（４８－１６＝３２）となる。

また、図１０を参照して、特願２０１９－１２８３６号公報記載の発明では、切替操作が行われると、ダウンロード予測時間に基づいて動画Ｂの上書領域（上書きするセグメント番号）が決定され、動画Ｂがその上書領域から上書きされる。

このため、特願２０１９－１２８３６号公報記載の発明の場合、動画Ａから動画Ｂへの切替再生のタイミングは、再生時刻２４秒となる。そして、動画Ａから動画Ｂへの切替時間は８秒（２４－１６＝８）となり、図９に示した従来技術の場合の切替時間３２秒よりも短い。

また、図１１を参照して、本発明の実施形態では、切替操作が行われると、受信バッファ２０に空きがある場合、動画Ｂのセグメントは受信バッファ２０に追加される。一方、受信バッファ２０に空きがなく、かつ動画Ａが格納されている場合、動画Ｂのセグメントは、動画Ａの最後部の領域に上書きされる。

このため、本発明の実施形態の場合、動画Ａから動画Ｂへの切替再生のタイミングは、再生時刻２４秒となり、動画Ａから動画Ｂへの切替時間は８秒（２４－１６＝８）となる。これは、図１０に示した特願２０１９－１２８３６号公報記載の発明の場合と同じである。

しかしながら、前述のとおり、切替操作時に回線スループットが低下した場合、本発明の実施形態は、特願２０１９－１２８３６号公報記載の発明よりも有効に機能する。すなわち、特願２０１９－１２８３６号公報記載の発明では、受信バッファ２０に格納されたセグメントの数が低下し、動画Ａ，Ｂが交互に再生されて乱れるという不体裁が発生する。しかし、本発明の実施形態では、受信バッファ２０に格納されたセグメントの数の低下を抑えることができ、不体裁の発生を防止することができる。

以上のように、本発明の実施形態のユーザ端末１によれば、受信バッファ管理部１３のセグメント要求部２１は、ユーザにより切替操作に伴う動画切替要求を入力し、受信バッファ２０に空きがあると判定した場合、受信バッファ２０に格納された最後部の次のＳＧ番号を取得ＳＧ番号ｓａに決定し、ＳＧ要求（ｓａ）を出力する。ＳＧ要求（ｓａ）はサーバ２へ送信され、サーバ２から切替操作後の動画Ｂにおける取得ＳＧ番号ｓａのセグメントが送信される。

受信バッファ管理部１３の格納処理部２２は、切替操作後の動画Ｂにおける取得ＳＧ番号ｓａのセグメントを受信バッファ２０に追加する。

セグメント要求部２１は、受信バッファ２０に空きがなく、切替操作前の動画Ａのセグメントが格納されていると判定した場合、受信バッファ２０に格納された切替操作前の動画Ａのセグメントのうち最後部のセグメントのＳＧ番号を取得ＳＧ番号ｓｂに決定し、ＳＧ要求（ｓｂ）を出力する。ＳＧ要求（ｓｂ）はサーバ２へ送信され、サーバ２から切替操作後の動画Ｂにおける取得ＳＧ番号ｓｂのセグメントが送信される。

格納処理部２２は、切替操作後の動画Ｂにおける取得ＳＧ番号ｓｂのセグメントを、受信バッファ２０に格納された切替操作前の動画Ａにおける取得ＳＧ番号ｓｂのセグメントの領域に上書きする。

セグメント要求部２１は、受信バッファ２０に切替操作前の動画Ａのセグメントが格納されていないと判定した場合、通常時のセグメント取得処理へ移行する。

これにより、切替操作時の受信バッファ２０には、動画Ｂのセグメントが追加または上書きされるため、受信バッファ２０に格納されたセグメントの数の低下を抑えることができると共に、動画Ｂが連続して格納されることとなる。

したがって、動画Ａを視聴しているユーザが切替操作を行ったときに、新たな動画Ｂの視聴開始までの待ち時間を短縮することができると共に、動画Ａ，Ｂが交互に再生されて乱れるという不体裁の発生を防止し、一層安定した再生を実現することができる。

以上、実施形態を挙げて本発明を説明したが、本発明は前記実施形態に限定されるものではなく、その技術思想を逸脱しない範囲で種々変形可能である。例えば、前記実施形態では、セグメントを再生する順番を示すＳＧ番号を用いてセグメントの位置を決定し、セグメントを取得する等の処理を行うようにしたが、ＳＧ番号の代わりに、セグメントの先頭を再生する時刻を示すタイムスタンプを用いるようにしてもよい。

尚、タイプスタンプはセグメント番号から以下の式にて求められる。タイムスタンプをＴＳ、タイムスタンプの初期値をＴＳ０、セグメント番号をＳＧ、セグメント番号の初期値をＳＧ０、セグメント長（セグメントの時間長）をＳＧＴとする。
［式１］
ＴＳ＝（ＳＧ－ＳＧ０）×ＳＧＴ＋ＴＳ０ ・・・（１）

具体的には、端末装置１に備えた受信バッファ管理部１３のセグメント要求部２１は、動画切替要求を入力し、受信バッファ２０に空きがあると判定した場合、受信バッファ２０に格納された最後部のセグメントのタイムスタンプを特定する。そして、セグメント要求部２１は、特定したタイムスタンプにセグメント長ＳＧＴを加算することで、その次のセグメント（空き領域に格納されるべきセグメント）のタイムスタンプを求める。

セグメント要求部２１は、切替操作後の動画Ｂにおける加算結果のタイムスタンプのセグメントを取得するためのＳＧ要求をサーバ２へ出力する。これにより、サーバ２から端末装置１へ、当該ＳＧ要求に対応するセグメントが送信される。

格納処理部２２は、受信した当該ＳＧ要求に対応するセグメント、すなわち切替操作後の動画Ｂにおける前記タイムスタンプのセグメントを受信バッファ２０に追加する。

セグメント要求部２１は、受信バッファ２０に空きがなく、切替操作前の動画Ａのセグメントが格納されていると判定した場合、受信バッファ２０に格納された切替操作前の動画Ａのセグメントのうち最後部のセグメントのタイムスタンプを特定する。そして、セグメント要求部２１は、切替操作後の動画Ｂにおける特定したタイムスタンプのセグメントを取得するためのＳＧ要求をサーバ２へ出力する。これにより、サーバ２から端末装置１へ、当該ＳＧ要求に対応するセグメントが送信される。

格納処理部２２は、受信した当該ＳＧ要求に対応するセグメント、すなわち切替操作後の動画Ｂにおける前記タイムスタンプのセグメントを、受信バッファ２０に格納された切替操作前の動画Ａにおける前記タイムスタンプのセグメントの領域に上書きする。

尚、本発明の実施形態によるユーザ端末１のハードウェア構成としては、通常のコンピュータを使用することができる。ユーザ端末１は、ＣＰＵ、ＲＡＭ等の揮発性の記憶媒体、ＲＯＭ等の不揮発性の記憶媒体、及びインターフェース等を備えたコンピュータによって構成される。

ユーザ端末１に備えた通信インターフェース１０、ＯＳ１１、ＷＥＢブラウザ１２、受信バッファ管理部１３、動画デコーダ１４及び表示部１５の各機能は、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。また、受信バッファ管理部１３について、受信バッファ２０、セグメント要求部２１及び格納処理部２２の各機能は、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現される。

これらのプログラムは、前記記憶媒体に格納されており、ＣＰＵに読み出されて実行される。また、これらのプログラムは、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記憶媒体に格納して頒布することもでき、ネットワークを介して送受信することもできる。

１ ユーザ端末
２ サーバ
３ インターネット
４ ストレージ
１０ 通信インターフェース
１１ ＯＳ（オペレーティングシステム）
１２ ＷＥＢブラウザ
１３ 受信バッファ管理部
１４ 動画デコーダ
１５ 表示部
２０ 受信バッファ
２１ セグメント要求部
２２ 格納処理部
Ａ，Ｂ 動画
ｓａ，ｓｂ 取得ＳＧ番号

Claims (3)

1. サーバからインターネットを介して配信された動画のセグメントを受信し、前記セグメントをバッファリングして読み出し、前記セグメントをデコードして再生するユーザ端末において、
   前記インターネットを介して受信したそれぞれの前記セグメントを、受信バッファの最前領域から最後領域まで格納する受信バッファ管理部と、
   前記受信バッファの前記最前領域に格納された前記セグメントを読み出し、当該セグメントをデコードする動画デコーダと、を備え、
   前記受信バッファ管理部は、
   ユーザにより新たな前記動画を再生するための切替操作が行われると、
   前記受信バッファに前記セグメントを格納するための空き領域がある場合、新たな前記動画の切替後セグメントを取得し、当該切替後セグメントを前記受信バッファの前記空き領域に追加し、
   前記空き領域がなく、かつ前記受信バッファに再生中の前記動画の切替前セグメントが格納されている場合、前記受信バッファに格納された全ての前記切替前セグメントのうち最後に読み出される前記切替前セグメントを最後部の前記切替前セグメントとして特定し、新たな前記動画の切替後セグメントを取得し、当該切替後セグメントを、前記受信バッファにおける前記最後部の前記切替前セグメントが格納された領域に上書きする、ことを特徴とするユーザ端末。
2. 請求項１に記載のユーザ端末において、
   前記受信バッファ管理部は、セグメント要求部及び格納処理部を備え、
   前記ユーザにより前記切替操作が行われると、
   前記セグメント要求部は、
   前記受信バッファに前記セグメントを格納するための前記空き領域があるかないかを判定し、前記空き領域があると判定した場合、前記受信バッファに格納された全ての前記セグメントのうち前記最後部を特定し、当該最後部の次のセグメントにおけるセグメント番号またはタイムスタンプを特定し、当該セグメント番号または当該タイムスタンプに対応する前記切替後セグメントを取得するためのセグメント要求として、第１セグメント要求を生成し、
   前記格納処理部は、
   前記セグメント要求部により生成された前記第１セグメント要求に対応する前記切替後セグメントを取得し、当該切替後セグメントを前記受信バッファの前記空き領域に追加し、
   前記セグメント要求部は、
   前記空き領域が無いと判定した場合、前記受信バッファに前記切替前セグメントが格納されているか否かを判定し、前記切替前セグメントが格納されていると判定した場合、前記受信バッファに格納された全ての前記切替前セグメントのうち前記最後部を特定し、当該最後部のセグメントにおけるセグメント番号またはタイムスタンプを特定し、当該セグメント番号または当該タイムスタンプに対応する前記切替後セグメントを取得するためのセグメント要求として、第２セグメント要求を生成し、
   前記格納処理部は、
   前記セグメント要求部により生成された前記第２セグメント要求に対応する前記切替後セグメントを取得し、当該切替後セグメントを、前記受信バッファの前記最後部の領域に上書きする、ことを特徴とするユーザ端末。
3. コンピュータを、請求項１または２に記載のユーザ端末として機能させるためのプログラム。

Images