[1.第1実施形態]
以下、本発明の第1実施形態について説明する。
[1-1.動画配信システムの構成]
図1は、本実施形態に係る動画配信システム1の概略構成図である。動画配信システム1は、通信回線2、複数の携帯端末3、及びサーバ4を含んで構成される。
通信回線2は、コンピュータネットワークを形成するものであり、例えば、電気事業者によって提供される広域通信回線である。
携帯端末3は、例えば、スマートフォンやタブレット端末、ノートパソコン等の情報処理端末である。携帯端末3は、画像を表示するタッチパネルディスプレイ3a、音を出力するスピーカー3b、音が入力されるマイク3c、及び被写体を撮像するカメラ3d等を備える。携帯端末3は、サーバ4から配信される動画データを再生するために、一例として、専用のアプリケーションソフトウエアがインストールされる。
サーバ4は、通信回線2を介して、複数の携帯端末3へ動画データを配信する情報処理装置である。動画データは、例えばアニメやドラマ等のようにストーリーが存在し、ストーリーに沿って物語が進行する動画を示すものである。サーバ4は、動画データを、例えばライブ配信ではなく非ライブ配信によって携帯端末3に配信する。動画データを受信した携帯端末3は、動画データを再生してタッチパネルディスプレイ3aに表示したり、音をスピーカー3bから出力する。
動画データが配信される複数の携帯端末3は、至近距離に位置し、グループ5としてサーバ4に登録(以下「グループ登録」という。)される。すなわち、グループ登録された複数の携帯端末3は、サーバ4から配信された動画データに基づく動画を同じタイミングで、換言すると同期してタッチパネルディスプレイ3aに表示する。そして、グループ登録された携帯端末3の各ユーザは、同時に動画を視聴することとなる。
図1では、グループ5を構成する携帯端末3を四つ(携帯端末3A,3B,3C,3D)としているが、これは一例であり、グループ5は複数の携帯端末3で構成されていればその台数は限定されない。また、グループ5を構成する携帯端末3の種類も限定されず、スマートフォンやタブレット端末、ノートパソコン等が混在してもよい。
[1-2.サーバの構成]
図2は、本実施形態に係るサーバ4の電気的構成を示すブロック図である。
本実施形態に係るサーバ4は、サーバ4全体の動作を司る主制御部であるCPU(Central Processing Unit)20、各種プログラム及び各種データ等が予め記憶されたROM(Read Only Memory)22、CPU20による各種プログラムの実行時のワークエリア等として用いられるRAM(Random Access Memory)24、各種プログラム及び各種データを記憶する記憶手段としてのHDD(Hard Disk Drive)26を備えている。
HDD26は、登録されたグループ5に関する情報や、携帯端末3に配信する動画データを記憶する。なお、記憶手段は、HDD26に限らず、例えば、フラッシュメモリ等の半導体メモリ等の他の記憶媒体であってもよい。
さらに、サーバ4は、キーボード及びマウス等で構成されて各種操作の入力を受け付ける操作入力部28、各種画像を表示する例えば液晶ディスプレイ装置等のモニタ30、通信回線2を介して携帯端末3等の他の情報処理装置等と接続され、他の情報処理装置等との間で各種データの送受信を行う外部インタフェース32を備えている。
これらCPU20、ROM22、RAM24、HDD26、操作入力部28、モニタ30、及び外部インタフェース32は、システムバス34を介して相互に電気的に接続されている。従って、CPU20は、ROM22、RAM24、及びHDD26へのアクセス、操作入力部28に対する操作状態の把握、モニタ30に対する画像の表示、並びに外部インタフェース32を介した他の情報処理装置等との各種データの送受信等を各々行なうことができる。
[1-3.携帯端末の電気的構成]
図3は、携帯端末3の電気的構成を示す機能ブロック図である。
携帯端末3は、図1に示される構成に加え、主制御部40、主記憶部42、補助記憶部44、通信部46、及び操作ボタン48を備える。
主制御部40は、例えば、CPU、マイクロプロセッサ、DSP(Digital Signal Processor)等であり、携帯端末3の全体の動作を制御する。
主記憶部42は、例えば、RAMやDRAM(Dynamic Random Access Memory)等で構成されており、主制御部40による各種プログラムに基づく処理の実行時のワークエリア等として用いられる。
補助記憶部44は、例えば、フラッシュメモリ等の不揮発性メモリであり、画像等の各種データ及び主制御部40の処理に利用されるプログラム等を保存する。補助記憶部44に記憶されるプログラムは、例えば、携帯端末3の基本的な機能を実現するためのOS(Operating System)、各種ハードウェアを制御するためのドライバ、電子メールやウェブブラウジング、その他各種機能を実現するためのプログラム等である。また、補助記憶部44には、サーバ4から配信された動画データを再生してタッチパネルディスプレイ3aに表示させるためのアプリケーションソフトが予め記憶されている。
通信部46は、例えばNIC(Network Interface Controller)であり、通信回線2に接続する機能を有する。なお、通信部46は、NICに代えて又はNICと共に、無線LAN(Local Area Network)に接続する機能、無線WAN(Wide Area Network)に接続する機能、例えばBluetooth(登録商標)等の近距離の無線通信、及び赤外線通信等を可能とする機能を有してもよい。
操作ボタン48は、携帯端末3の側面に設けられ、携帯端末3を起動又は停止させるための電源ボタンやスピーカー3bが出力する音のボリューム調整ボタン等である。
これら主制御部40、主記憶部42、補助記憶部44、通信部46、タッチパネルディスプレイ3a、スピーカー3b、マイクロフォン3c、カメラ3d、及び操作ボタン48は、システムバス49を介して相互に電気的に接続されている。従って、主制御部40は、主記憶部42及び補助記憶部44へのアクセス、タッチパネルディスプレイ3aに対する画像の表示、ユーザによるタッチパネルディスプレイ3aや操作ボタン48に対する操作状態の把握、マイクロフォン3cへの音の入力、スピーカー3bからの音の出力、カメラ3dに対する制御、及び通信部46を介した各種通信網や他の情報処理装置へのアクセス等を行える。
[1-4.動画の進行変化]
本実施形態に係るサーバ4は、グループとして登録された複数の携帯端末3へ動画データを配信し、携帯端末3からの入力に応じて、携帯端末3に表示させる動画の進行を変化させる動画配信処理を行う。
図4は、動画の進行変化の態様例を示す模式図である。
図4の例では、動画の進行が変化する分岐(分岐フェーズα,β1,β2,β3,γ)が複数存在する。図4の例では、分岐フェーズαを介して進行Aから進行B、分岐フェーズβ1,β2,β3を介して進行Bから進行C、分岐フェーズγを介して進行Cから進行Dへ分岐する。
なお、一回の分岐による進行変化の数(種類)は限定されない。例えば、進行Aから進行Bに分岐する場合は、4種類(進行B1~B4)に分岐し、進行B1から進行Cに変化する場合は3種類(進行C1~C3)に分岐している。また、他の進行では分岐フェーズが存在する一方で、進行B3から進行C5等のように分岐フェーズが存在しない進行を設けてもよい。さらに、進行B1と進行B2が進行C3となる場合や、進行C1と進行C2が進行D1となる場合のように、途中の進行が異なっても、その後の進行が同じになってもよい。
なお、本実施形態に係る動画配信処理は、グループ登録された携帯端末3の全てで、動画の進行を同様に変化させる。
[1-5.本実施形態に係る動作再生ファイルの詳細]
サーバ4が有する動画配信機能は、複数の携帯端末3へ動画データの記憶場所及び再生順序を示す再生順序情報を配信するものである。再生順序情報は、一例として、HLS(HTTP Live Streaming)によって表されるものであり、以下、動画再生ファイル50(図5参照)という。
HLSは、“.m3u”又は“.m3u8”という拡張子で表現され、HLSの実体は“.ts”の拡張子を有する複数のファイル(以下「tsファイル」という。)である。tsファイルは、動画データのパスをテキストで示したものである。すなわち、tsファイルが動画データの記憶場所を示す。なお、tsファイルで示される動画データの記憶場所(パス)は、一例として、URL(Uniform Resource Locator)で表される。そして、tsファイルの並び順(図5の例では上から下方向)が動画データの再生順序を示す。
携帯端末3は、サーバ4から動画再生ファイル50が配信されると、tsファイルの並び順に沿ってtsファイルで表されるパスにアクセスし、動画データを再生する。
図5(A)で示される動画再生ファイル50であるstory_01.m3uは、一例として、chapter1.ts、chapter2.ts、chapter3.ts、chapter4.tsのように、4つのtsファイルで構成される。携帯端末3は、story_01.m3uが配信されると、このtsファイルを順番に読み込んで各tsファイルに割り振られたURLへアクセスして動画データを一つずつ再生する。
このように動画配信においてHLSを用いることによって、本来動画のストリーミング配信に向かないHTTP(Hypertext Transfer Protocol)においてもストリーミング配信(疑似ストリーミング配信)が可能となる。
そして、本実施形態に係るサーバ4は、携帯端末3に表示される動画の進行分岐に応じて、他の携帯端末3に配信される動画再生ファイル50に含まれる記憶場所とは異なる記憶場所を含む動画再生ファイル50を携帯端末3に配信する。
なお、動画の進行分岐に応じた動画再生ファイル50は、サーバ4のHDD26に予め記憶されていてもよいし、後述するように、サーバ4が携帯端末3から送信される情報に基づいて生成してもよい。
動画の進行分岐に応じて異なる記憶場所を含む動画再生ファイル50について、図5,6を参照して説明する。
図5(A),(B)に示される動画再生ファイル50は、3番目のtsファイルのみが異なる。すなわち、3番目のtsファイルが動画の進行分岐に対応するものである。このように、本実施形態に係る動画再生ファイル50により示される動画の記憶場所は、動画の進行分岐に応じて異なるURLとされる。
なお、本実施形態に係る動画再生ファイル50は、動画の進行分岐に応じて異なるtsファイルであってもその動画の再生時間(長さ)は同じとされている。すなわち、図5(A),(B)の例では、chapter 3.tsとchapter3_dash.tsとで示される動画の再生時間は同じである。これにより、携帯端末3に応じて動画の進行が途中で異なっても、動画の最終的な終了時間は全ての携帯端末3で同じとなる。
図6は、複数の携帯端末3のうち一部の携帯端末3で異なる動画再生ファイル50を再生する場合を示す模式図である。図6の例では、携帯端末3A,3B,3Dに同じ動画再生ファイル50が配信され、携帯端末3Cのみに異なる動画再生ファイル50が配信される。そして、携帯端末3A,3B,3Dに配信される動画再生ファイル50を図5(A)に示されるものとし、携帯端末3Cに配信される動画再生ファイル50を図5(B)に示されるものとする。そして、図6に示されるように、「chapter 2」が終了すると、動画の進行が分岐し、携帯端末3A,3B,3Dは「chapter 3」を再生するものの、携帯端末3Cのみが「chapter3_dash」を再生する。
なお、本実施形態では、一つの動画は、複数の動画再生ファイル50によって構成されており、サーバ4は、予め定められた順序で動画再生ファイル50を携帯端末3に配信する。携帯端末3は、サーバ4から配信された動画再生ファイル50を記憶し、サーバ4から配信された順序で動画再生ファイル50により示されるURLへアクセスして、動画データを再生し、タッチパネルディスプレイ3aに動画を表示する。
[1-6.サーバの動画配信機能]
図7は、本実施形態に係るサーバ4の動画配信機能に関する機能ブロック図である。
サーバ4が備えるCPU20は、グループ登録部60、HLS配信部62、及びHLS選択部64を備える。CPU20が備える各機能は、HDD26に記憶されているプログラムによって実現される。
グループ登録部60は、至近距離に位置する複数の携帯端末3で構成されるグループ5の登録を受け付ける。
グループ登録部60は、例えば、携帯端末3を介して携帯端末3の位置情報を取得し、至近距離として予め定められた範囲内(例えば10m内、以下「至近距離範囲」という。)にある複数の携帯端末3をグループ5として登録する。なお、携帯端末3の位置情報と共に、ユーザID(identification)も取得される。ユーザIDは、ユーザが動画配信サービスを受ける場合に、ログイン画面に入力するIDとして用いられる。
至近距離範囲に携帯端末3があるか否かは、例えば、ホストとされた一つの携帯端末3(以下「親端末3M」という。)を中心として直径10m以内に位置する携帯端末3が至近距離範囲にあるか否かによって判定される。より具体的には、まず、親端末3Mとなる携帯端末3が動画配信サービスに最初にログインすることによって、グループ5の登録が開始され、登録されたグループ5に入る許可申請を他の携帯端末3が行う。他の携帯端末3による許可申請は、親端末3Mによって可否が決定されると共に、親端末3Mと他の携帯端末3との距離が至近距離範囲内であるか否かがグループ登録部60によって判定される。なお、親端末3Mに対して、他の携帯端末3を子端末3Sともいう。
グループ登録部60は、他の携帯端末3が至近距離範囲内であると判定した場合にのみ、親端末3Mの許可に追従して他の携帯端末3がグループ5へ登録されることを許可する。一方、他の携帯端末3が至近距離範囲内でないと判定した場合、グループ登録部60は、親端末3Mが許可しても、他の携帯端末3がグループ5へ登録されることを許可しない。
なお、グループ登録部60は、携帯端末3の位置情報を取得することなく、ユーザIDの登録のみによってグループ5の登録を行ってもよい。この場合、他の携帯端末3による許可申請は、親端末3Mによってのみ可否が決定される。
HLS配信部62は、グループ登録された複数の携帯端末3へ動画再生ファイル50を配信する。なお、一つの動画は、複数の動画再生ファイル50によって構成されているため、HLS配信部62は、予め定められた順序で動画再生ファイル50を携帯端末3に配信する。本実施形態に係るHLS配信部62は、携帯端末3に表示される動画の進行分岐に応じて、異なる動画データの記憶場所を含む動画再生ファイル50を携帯端末3に配信する。
HLS選択部64は、携帯端末3に配信する動画再生ファイル50を選択する。そして、HLS選択部64は、選択した動画再生ファイル50を携帯端末3に配信させる配信指示をHLS配信部62へ出力する。なお、本実施形態に係るHLS選択部64は、携帯端末3から送信される動画の進行分岐を示す進行分岐情報をサーバ4が受信した場合に、進行分岐情報に応じた動画再生ファイル50をHDD26から選択し、配信指示をHLS配信部62へ出力する。
すなわち、HLS配信部62は、携帯端末3から送信される進行分岐情報に応じて、動画再生ファイル50を携帯端末3に配信する。なお、進行分岐情報は、一例として、各携帯端末3が各々でサーバ4へ送信してもよいし、グループ登録された各携帯端末3(子端末3S)が親端末3Mを介してサーバ4へ送信してもよい。
また、携帯端末3から送信された進行分岐情報に対応する動画再生ファイル50がサーバ4のHDD26に記憶されていない場合、HLS選択部64は、HLS生成手段として機能し、進行分岐情報に対応する動画再生ファイル50を生成してもよい。
[1-7.携帯端末の動画再生機能]
図8は、本実施形態に係る携帯端末3の動画再生機能に関する機能ブロック図である。
携帯端末3が備える主制御部40は、動画再生ファイル処理部70、画像表示制御部72、進行分岐決定部74、進行分岐情報送信処理部76、及び動画再生強制シーク部78を備える。主制御部40が備える各機能は、補助記憶部44に記憶されているプログラムによって実現される。
動画再生ファイル処理部70は、通信部46を介してサーバ4から受信した動画再生ファイル50を主記憶部42に記憶させる。そして、動画再生ファイル処理部70は、動画の進行に応じて主記憶部42に記憶されている動画再生ファイル50の再生順序毎にtsファイルを読み出し、tsファイルが示すURLにアクセスし、動画データをダウンロード(キャッシュ)する。
なお、動画再生ファイル処理部70は、重複するtsファイルがあり、そのtsファイルにより示される動画データを既にダウンロードしている場合、同じ動画データをダウンロードしない。これにより、動画データのダウンロードコストが削減される。
画像表示制御部72は、画像データに基づいた画像を表示するようにタッチパネルディスプレイ3aを制御する。本実施形態に係る画像表示制御部72は、動画再生ファイル処理部70によってダウンロードされた動画データを再生して、タッチパネルディスプレイ3aに表示させる。
進行分岐決定部74は、動画の進行が分岐フェーズに至った場合、進行の分岐先を決定する。なお、本実施形態に係る進行分岐決定部74は、動画の進行が分岐フェーズに至った場合にユーザによる動画の進行分岐の選択を受け付けるが、これに限られず、携帯端末3に入力される各種情報等に基づいて、自動的に動画の進行分岐を選択してもよい。
進行分岐情報送信処理部76は、進行分岐決定部74で決定(選択)された進行の分岐先を示す情報である進行分岐情報を、通信部46を介してサーバ4へ送信する。
動画再生強制シーク部78は、動画再生ファイル50により示される動画データの再生開始タイミングを、グループ登録された複数の携帯端末3で同じとなるように制御(強制シーク)する。より具体的には、動画再生ファイル50で示される各動画データは再生開始から終了までの時間(以下「予定進行時間」という。)が予め定められており、動画再生強制シーク部78は、各携帯端末3において動画が再生されてから予定進行時間に達した場合にはその動画データの再生が最後に至っていなくても、次の動画データの再生を強制的に開始する。なお、予定進行時間は、データの通信状態等が正常である場合に、その動画データの再生から終了に至るまでの時間である。
図6を参照して説明すると、携帯端末3A,3B,3Cでは予定進行時間でchapter 1の動画データの再生が完了する一方、携帯端末3Dでは何らかの理由で通信状態が悪く、chapter 1の再生が終了していない場合、携帯端末3Dの動画再生強制シーク部78が強制的にchapter 1の再生を終了し、携帯端末3A,3B,3Cと再生開始タイミングが同じとなるようにchapter 2の再生を開始する。なお、予定進行時間を示す情報は、一例として、動画再生ファイル50と共に、サーバ4から各携帯端末3に配信される。
これにより、グループ登録された複数の携帯端末3において、動画データの再生タイミングを同期させることができる。なお、強制シークを行うために、動画再生ファイル処理部70は、tsファイルにより示される動画データのダウンロードを先行して行う。例えば、動画再生ファイル処理部70は、タッチパネルディスプレイ3aにchapter 1の動画が表示されている状態で、既に少なくともchapter 2を示す動画データのダウンロードを終了する。
なお、強制シークは、サーバ4から送信される指示(以下「強制シーク指示」という。)に応じて行われてもよい。このため、各携帯端末3は、動画の進行に応じて、例えば、各tsファイルで示される動画の再生が終了する毎に当該動画の終了時刻を示す動画終了情報をサーバ4へ送信する。サーバ4は、各携帯端末3からの動画終了情報を比較して、動画の進行に遅れが生じている携帯端末3へ強制シーク指示を送信する。強制シーク指示は、送信対象の携帯端末3における動画の進行が遅れている時間(遅れ時間)を含んでいる。このため、強制シーク指示を受信した携帯端末3は、遅れ時間を解消するように、再生中の動画を強制的に終了し、次の動画データの再生を開始する。
[1-8.本実施形態に係る動画配信処理のフロー]
図9は、サーバ4が備えるCPU20によって実行される本実施形態に係る動画配信処理の流れを示すフローチャートである。動画配信処理を実行するためのプログラムはHDD26の所定領域に予め記憶されている。動画配信処理は、一例として、サーバ4が動画の再生指示を携帯端末3から受信した場合に実行が開始される。
まず、ステップ100では、動画は複数の動画再生ファイル50で構成されるため、次の動画再生ファイル50の配信タイミングに至ったか否かをHLS配信部62が判定し、肯定判定の場合はステップ102へ移行する一方、否定判定の場合はステップ104へ移行する。
ステップ102では、携帯端末3で再生されている動画の進行に応じた所定の動画再生ファイル50をHLS選択部64が選択し、ステップ110へ移行する。
ステップ104では、進行分岐情報を携帯端末3から受信したか否かをHLS選択部64が判定し、肯定判定の場合はステップ106へ移行する一方、否定判定の場合はステップ100へ戻る。
ステップ106では、進行分岐情報に応じた動画再生ファイル50をHLS選択部64が選択する。
次のステップ108では、携帯端末3への動画再生ファイル50の配信タイミングに至ったか否かをHLS配信部62が判定し、肯定判定の場合はステップ110へ移行する。
ステップ110では、選択された動画再生ファイル50をHLS配信部62が携帯端末3に配信し、ステップ100へ戻る。なお、ステップ110では、動画の進行分岐に応じた動画再生ファイル50を配信するタイミングの場合には、ステップ106で選択した動画再生ファイル50を携帯端末3に配信し、そうでない場合には、ステップ102で選択した動画再生ファイル50を携帯端末3に配信する。
以上説明したように、本実施形態に係る動画配信処理は、携帯端末3に表示される動画の進行分岐に応じて、異なる動画データの記憶場所(URL)を含むHLSで示される動画再生ファイル50をサーバ4が携帯端末3に配信する。このように、サーバ4は、動画の進行分岐が生じても、動画の進行分岐に応じて記憶場所を異ならせた動画再生ファイル50を携帯端末3に配信するだけであるので、本実施形態に係る動画配信処理は、携帯端末3に応じて進行が異なる動画をHTTP通信によって簡易に配信できる。
[1-9.変形例1]
本変形例に係る動画再生ファイル50は、記憶場所がプロキシ(プロキシサーバ、HTTPプロキシ)で表される。このプロキシは、携帯端末3に表示される動画の進行分岐に応じて、異なる動画データの記憶場所(転送先)を示す。
例えば、携帯端末3Aに配信される動画再生ファイル50の記憶場所は“プロキシA”で表され、携帯端末3Bに配信される動画再生ファイル50の記憶場所は“プロキシB”で表され、携帯端末3Cに配信される動画再生ファイル50の記憶場所は“プロキシC”で表され、携帯端末3Dに配信される動画再生ファイル50の記憶場所は“プロキシD”で表される。
動画の進行が分岐しない場合は、プロキシA~Dは転送先である動画の記憶場所として同じ記憶場所を示す。一方、動画の進行が分岐する場合、例えば、携帯端末3Cで再生される動画の進行が他の携帯端末3と異なる場合、プロキシCは他のプロキシA,B,Dとは異なる転送先を示す。すなわち、サーバ4は、動画の進行分岐に応じて、プロキシにより示される転送先を変更する。
すなわち、本変形例に係るサーバ4は、動画の進行分岐が生じても、携帯端末3に配信する動画再生ファイル50の内容を変更しない。その一方で、サーバ4は、動画の進行分岐が生じた場合に、プロキシの転送先を変更する。これにより、動画の進行分岐が生じても携帯端末3へ同じ動画再生ファイル50を配信し続ければいいので、サーバ4から携帯端末3に配信するための動画再生ファイル50の選択等に関する処理が簡略化される。
[1-10.変形例2]
本変形例に係るHLS配信部62は、複数の進行分岐に対応可能なように、複数の異なる動画データの記憶場所(tsファイル)を含んだ同じ動画再生ファイル50を複数の携帯端末3に配信する。そして、携帯端末3は、複数の異なるtsファイルのうち、一つを選択して動画データをダウンロードして再生する。
図10を参照して本変形例を説明する。本変形例に係る動画再生ファイル50は、chapter 3が進行分岐に対応するものであり、chapter3-1.ts、chapter3-2.ts、及びchapter3-3.tsのように3つのうち何れかに分岐可能とされている。そして、各携帯端末3は、動画の進行分岐に応じて、上記3つのtsファイルのうち一つを選択する。これにより、サーバ4は、複数の携帯端末3に対して同じ動画再生ファイル50を送信すればよく、サーバ4から携帯端末3に配信するための動画再生ファイル50の選択等に関する処理が簡略化される。
なお、携帯端末3は、進行分岐に対応した複数のtsファイルのうち、一つのtsファイルにより示される動画データのみをダウンロードするのではなく、複数のtsファイルにより示される複数の動画データを予めダウンロードし、ダウンロードした複数の動画データのうち、一つのみを再生してもよい。このように、携帯端末3が、進行分岐に対応して予め複数の動画データをダウンロードすることによって、進行分岐に至る際に通信速度が低下したとしても、途切れることなく動画の再生が可能となる。
[1-11.変形例3]
本変形例に係るHLS配信部62は、同じ動画再生ファイル50を複数の携帯端末3に配信し、かつ動画の進行分岐に応じた記憶場所を示す情報(以下「分岐動画情報」という。)52(図11参照)を対応する携帯端末3に配信する。そして、携帯端末3は、受信した動画再生ファイル50の進行分岐に対応する記憶場所(tsファイル)を、受信した分岐動画情報52に応じた記憶場所に置き換える。
より具体的には、HLS配信部62は、複数の携帯端末3に対して同じ動画再生ファイル50を配信する。さらに、HLS配信部62は、動画の進行分岐に対応した動画の記憶場所を示した分岐動画情報52を、別途、携帯端末3へ送信する。そして、動画の進行が分岐する携帯端末3、すなわち分岐動画情報52が配信された携帯端末3は、動画再生ファイル50において進行分岐に対応するtsファイルを、分岐動画情報52により示されるtsファイルに置き換える。
例えば、図6に示すように携帯端末3Cで再生される動画の進行が他の携帯端末3と異なる場合、図11に示すように携帯端末3Cにのみ分岐動画情報52が配信され、携帯端末3Cにおいて動画再生ファイル50のchapter3.tsがchapter3_dash.tsに置き換えられる。これにより、サーバ4は、複数の携帯端末3に対して同じ動画再生ファイル50を送信すればよく、サーバ4から携帯端末3に配信するための動画再生ファイル50の選択等に関する処理が簡略化される。
[2.第2実施形態]
以下、本発明の第2実施形態について説明する。
本実施形態に係る動画配信システム1、サーバ4、及び携帯端末3の構成は、図1~図3に係る第1実施形態に係る動画配信システム1、サーバ4、及び携帯端末3の構成と同様であるので説明を省略する。
本実施形態に係る動画配信システム1は、グループ登録された複数の携帯端末3のうち、一つを親端末3M(携帯端末3A)とし他を子端末3S(携帯端末3B~3D)とする。そして、本実施形態に係る親端末3Mは、自身と子端末3Sとで再生される動画の進行を同期させる進行同期処理を行う。すなわち、本実施形態に係る進行同期処理は、第1実施形態において説明した強制シークの一例でもある。
[2-1.本実施形態に係る進行同期処理の概要]
本実施形態に係る動画配信システム1は、進行同期処理を行うために、子端末3Sが、自身で再生されている動画の進行状態を示す進行状態情報を親端末3Mへ送信する。親端末3Mは、進行状態情報に基づいて、自身と子端末3Sとで再生される動画の進行を同期させる。
より具体的には、親端末3Mは、自身の進行状態情報及び子端末3Sの進行状態情報により示される動画の進行状態を比較して、同期がずれている子端末3Sが存在しているか否かを判定する。同期がずれている子端末3Sが存在している場合には、親端末3Mは、その同期のずれを導出する。同期のずれとは、他の携帯端末3に比べて子端末3Sの動画の進行が遅れている場合には、その遅れ時間であり、他の携帯端末3に比べて子端末3Sの動画の進行が進んでいる場合には、その進み時間である。なお、動画の進行が同期している場合とは、動画の進行が完全に一致している場合だけでなく、予め定められた時間(例えば1秒程度)以下のずれが生じている場合が含まれてもよい。
そして、親端末3Mは、同期がずれている子端末と同期するように、自身と他の子端末3Sにおける動画データの再生を制御する。
なお、本実施形態に係る親端末3M及び子端末3Sは、第1実施形態と同様に、一例として、HLSによって表される動画再生ファイル50がサーバ4から携帯端末3に配信され、動画再生ファイル50に基づいて携帯端末3が動画データをダウンロードして再生する。このため、本実施形態に係る親端末3Mは、自身と子端末3Sとで再生される動画の進行が同期するように、動画再生ファイル50により示される所定の動画データであるバッファ動画データの再生を制御する。
図12は、本実施形態に係る動画再生ファイル50の一例を示す模式図である。図12においてchapter3_buffer.tsで示されるtsファイルが示す動画データは、親端末3Mと子端末3Sとで動画の進行を同期させるために再生が制御されるものであり、バッファ動画データである。バッファ動画データは、詳細を後述するように、再生が繰り返されたり、再生が行われなくても、物語の理解に影響のない動画を示すデータである。この動画は、例えば、人物や物(例えば自動車)が移動する場面や風景のみの場面の動画である。図12の例では、動画再生ファイル50にバッファ動画データが一つのみ含まれているが、これは一例であり、バッファ動画データは一つの動画再生ファイル50に複数含まれてもよい。
[2-1-1.子端末の再生が遅れている場合]
親端末3Mは、一部の子端末3Sにおける動画の進行が遅れている場合、自身と他の子端末3Sで再生される動画の進行を遅延させる。
本実施形態に係るバッファ動画データは、繰り返し再生(以下「ループ再生」という。)されるものであり、本実施形態に係る進行同期処理では、一例として、バッファ動画データの繰り返し数を増加させることで、動画の進行を遅延させる。すなわち、本実施形態に係る進行同期処理は、子端末3Sにおける動画の進行の遅れに応じて、親端末3Mや他の子端末3Sのバッファ動画データを再生の制御対象とし、バッファ動画データのループ再生させる回数を増加させる。なお、バッファ動画データは、例えば、1秒の動画を10回ループ再生するように予め設定されており、動画の進行を遅延させる場合には、このループ再生回数を増加させることになる。
これにより、動画配信システム1は、親端末3Mや他の子端末3Sにおける動画の進行を強制的に遅延させ、グループ登録された携帯端末3で再生される動画の進行を同期させることになる。
本実施形態に係る進行同期処理について、図13を参照して説明する。図13(A)は、動画の進行に遅れがない場合である。図13(B)は、一部の子端末3Sに動画の進行に遅れがある場合であり、一例として、chapter 2に遅れが生じている。
図13(C)は、動画の進行を強制的に遅延させる場合であり、親端末3Mは、動画の進行に遅れが生じていない自身と子端末3Sにおけるchapter 4の再生開始タイミングが、動画の進行に遅れがある子端末3Sのchapter 4の再生開始タイミングと同期するように、chapter 2の後に再生されるバッファ動画データのループ再生回数を増加させる。これにより、図13(B),(C)に表されるように、遅れがある子端末3Sと親端末3M及び他の子端末3Sとで、バッファ動画データの後に再生される動画(chapter 4)の再生開始のタイミングが一致、すなわち同期することになる。
すなわち、親端末3Mは、バッファ動画データの後に再生される動画データの再生開始タイミングがグループ登録された複数の携帯端末3で同期するように、バッファ動画データの再生を制御する。これにより、動画配信システム1は、複数の携帯端末3に動画を配信して複数のユーザが同時に動画視聴を行う場合に、各携帯端末3における動画の再生を簡易に同期できる。
なお、ループ再生回数の増加数は、親端末3M及び子端末3Sの進行状態情報に基づいて、親端末3Mが判定する。すなわち、親端末3Mが、動画の進行が遅れている子端末3Sと、親端末3M及び他の子端末3Sの動画の進行状態(遅れ時間)の差に基づいてループ再生回数の増加数を決定する。例えば、バッファ動画データによる動画の再生時間が1秒であって、遅れ時間が5秒の場合には、この遅れ時間を解消するためにバッファ動画データのループ再生回数が5回増加される。
そして、親端末3Mは、動画の進行を遅延させる子端末3Sに対して、バッファ動画データのループ再生回数を示した動画再生指示情報を送信する。親端末3Mは、自身に対応するように生成した動画再生指示情報に応じて、動画の進行を遅延させる。
ループ再生回数の決定は、バッファ動画データの再生が開始した後に行われてもよいし、バッファ動画データの再生開始前に、バッファ動画データの再生時における動画の進行の遅れを推測して行われてもよい。また、動画の進行に遅れが生じている子端末3Sが複数存在する場合、動画再生指示情報により示されるループ再生回数は、親端末3Mや子端末3Sに応じて異なる。
また、親端末3Mは、バッファ動画データをループ再生させず、バッファ動画データの再生速度を予め設定された再生速度よりも遅くすることで、動画の進行を遅延させてもよい。予め設定された再生速度は、通常の動画視聴が行われる場合の再生速度(×1倍)である。この場合、親端末3Mは、バッファ動画データの後に再生される動画データの再生開始タイミングが、グループ登録されている携帯端末3で同期するように、バッファ動画データの再生速度を低下させることになる。
[2-1-2.子端末の再生が進行している場合]
親端末3Mは、一部の子端末3Sにおける動画の進行が進んでいる場合、自身と他の子端末3Sで再生される動画の進行を促進させる。
この場合、親端末3Mは、バッファ動画データのループ再生回数を減少させる、又はバッファ動画データの再生速度を予め設定された再生速度よりも速くすることで、自身と他の子端末3Sで再生される動画の進行を促進させる。この場合、親端末3Mは、バッファ動画データの後に再生される動画データの再生開始タイミングがグループ登録された携帯端末3で同期するように、バッファ動画データの再生を制御することになる。また、親端末3Mは、バッファ動画データの再生を行わなかったり、途中で停止して次の動画データを再生させることで、自身と他の子端末3Sで再生される動画の進行を促進させてもよい。
[2-1-3.動画の進行が同期している場合]
親端末3Mは、自身と子端末3Sとで動画の進行が同期している場合、バッファ動画データの再生を行わない。
そもそも、バッファ動画データは、動画の進行に影響を与えない動画を示したものである。このため、グループ登録された複数の携帯端末3における動画の進行が同期している場合、親端末3Mは、バッファ動画データの再生を行わずに次の動画データの再生を行うことを示す動画再生指示情報を子端末3Sへ送信する。これにより、グループ登録された携帯端末3で再生される動画の進行が冗長とならずに、よりスムーズに行われる。
[2-2.携帯端末の動画再生同期機能]
図14は、本実施形態に係る携帯端末3の動画再生同期機能に関する機能ブロック図である。携帯端末3が備える主制御部40は、進行状態情報送信処理部80、進行状態情報受信処理部82、動画進行状態判定部84、動画再生指示生成部86、動画再生指示送信処理部88、動画再生指示受信処理部90、及び動画再生制御部92を備える。主制御部40が備える各機能は、補助記憶部44に記憶されているプログラムによって実現される。
なお、子端末3Sは、進行状態情報送信処理部80、動画再生指示受信処理部90、及び動画再生制御部92が機能する一方、進行状態情報受信処理部82、動画進行状態判定部84、動画再生指示生成部86、及び動画再生指示送信処理部88は機能しない。また、親端末3Mでは、動画再生指示受信処理部90は機能しない。
進行状態情報送信処理部80は、自身で再生されている動画の進行状態を示す進行状態情報を生成する。進行状態情報は、一例として、各tsファイルで示される動画データの再生が終了すると共に生成され、その内容は例えば最初のtsファイルの再生からの経過時間である。そして、子端末3Sは、生成した進行状態情報を通信部46を介して親端末3Mへ送信する。親端末3Mは、生成した進行状態情報を主記憶部42に記憶する。
進行状態情報受信処理部82は、親端末3Mで機能するものであり、子端末3Sから送信された進行状態情報を通信部46を介して受信し、主記憶部42に記憶する。
動画進行状態判定部84は、親端末3Mで機能するものであり、主記憶部42に記憶されている携帯端末3(親端末3Mと子端末3S)の進行状態情報に基づいて、子端末3Sにおける動画の進行のずれ(遅れ又は進み)を判定する。
動画再生指示生成部86は、親端末3Mで機能するものであり、動画進行状態判定部84による判定結果に基づいて、グループ登録された携帯端末3(親端末3Mと子端末3S)で動画の進行が同期するように動画再生指示を生成する。具体的には、動画再生指示生成部86は、自身及び各子端末3S毎に、グループ登録された携帯端末3で動画の進行が同期するように、バッファ動画データの再生を制御するための動画再生指示を生成する。
動画再生指示送信処理部88は、親端末3Mで機能するものであり、動画再生指示生成部86によって生成された動画再生指示を各子端末3Sへ通信部46を介して送信する。
動画再生指示受信処理部90は、子端末3Sで機能するものであり、親端末3Mから送信された動画再生指示を通信部46を介して受信し、主記憶部42に記憶する。
動画再生制御部92は、動画再生指示に基づいて、動画再生ファイル50により示される動画データを再生する。
[2-3.動画再生同期処理のフロー]
図15は、親端末3Mが備える主制御部40によって実行される本実施形態に係る動画再生同期処理の流れを示すフローチャートである。動画再生同期処理を実行するためのプログラムは補助記憶部44の所定領域に予め記憶されている。図15に示される動画再生同期処理は、一例として、動画再生ファイル50により示される動画データの再生開始と共に実行が開始される。
まず、ステップ200では、グループ登録された全ての子端末3Sから進行状態情報を受信したか否かを動画進行状態判定部84が判定し、肯定判定の場合はステップ202へ移行する。
ステップ202では、全ての子端末3Sと自身の進行状態情報に基づいて、動画の進行のずれを動画進行状態判定部84が判定する。
次のステップ204では、子端末3Sにおける動画の進行同期にずれがあるか否かを動画進行状態判定部84が判定し、肯定判定の場合はステップ206へ移行する一方、否定判定の場合はステップ212へ移行する。
ステップ206では、子端末3Sにおける動画の進行が遅れているか否かを判定し、肯定判定の場合はステップ208へ移行する一方、否定判定の場合はステップ210へ移行する。なお、ステップ210に移行する場合とは、子端末3Sにおける動画の進行が進んでいる場合である。
ステップ208では、動画の進行を遅延させることを示した動画再生指示を子端末3S及び親端末3M毎に動画再生指示生成部86が生成し、生成した動画再生指示を動画再生指示送信処理部88が子端末3Sへ送信し、ステップ200へ戻る。なお、各携帯端末3は、動画再生指示に基づいて、バッファ動画データの再生を制御する。
ステップ210では、動画の進行を促進させることを示した動画再生指示を子端末3S及び親端末3M毎に動画再生指示生成部86が生成し、生成した動画再生指示を動画再生指示送信処理部88が子端末3Sへ送信し、ステップ200へ戻る。なお、各携帯端末3は、動画再生指示に基づいて、バッファ動画データの再生を制御する。
ステップ204で否定判定となった場合に移行するステップ212では、グループ登録された携帯端末3で動画の進行にずれがないため、バッファ動画データを再生させないことを示した動画再生指示を動画再生指示生成部86が生成する。そして、生成した動画再生指示を動画再生指示送信処理部88が子端末3Sへ送信し、ステップ200へ戻る。なお、各携帯端末3は、動画再生指示に基づいて、バッファ動画データを再生することなく、バッファ動画データの次の動画データを再生する。
以上説明したように、本実施形態に係る動画配信システム1は、グループ登録された複数の携帯端末3のうち、一つの携帯端末3を親端末3Mとし、他の携帯端末3を子端末3Sとし、親端末3Mが、自身と子端末3Sとで再生される動画の進行を同期させる。これにより、動画配信システム1は、複数の携帯端末3に動画を配信して複数のユーザが同時に動画視聴を行う場合に、各携帯端末3における動画の再生を簡易に同期できる。
[2-4.変形例]
本変形例に係る親端末3Mは、一部の子端末3Sにおける動画の進行が遅れている場合、この一部の子端末3Sで再生される動画の進行を促進させるように動画再生指示を一部の子端末3Sに送信する。この形態の場合、一部の子端末3Sでは、親端末3Mにおける動画の進行状態と同期するように、バッファ動画データのループ再生回数が減少される、又はバッファ動画データの再生速度が予め設定された再生速度よりも速くされる。
また、親端末3Mは、一部の子端末3Sにおける動画の進行が進んでいる場合、この一部の子端末3Sで再生される動画の進行を遅延させるように動画再生指示を一部の子端末3Sに送信する。この形態の場合、一部の子端末3Sでは、親端末3Mにおける動画の進行状態と同期するように、バッファ動画データのループ再生の繰り返し数が増加される、又はバッファ動画データの再生速度が予め設定された再生速度よりも遅くされる。
また、バッファ動画データとされる動画データは、複数設けられ、その再生が制御される優先順位が予め定められてもよい。例えば、一つのバッファ動画データに対する再生制御だけでは、グループ登録されている携帯端末3における動画の進行を同期できない場合には、動画の進行が同期するように優先順位の高い順から再生制御が行われる。
さらに、バッファ動画データは、携帯端末3に記憶され、動画の進行同期のために適宜再生制御されてもよい。例えば、バッファ動画データとされる動画データのURLが、最初に配信される動画再生ファイル50で示され、それを携帯端末3がダウンロード(キャッシュ)する。携帯端末3は、その後に配信される動画再生ファイル50にバッファ動画データを示す記憶場所(URL)が含まれていなくても、ダウンロードしたバッファ動画データを動画の進行同期のために適宜、再生制御する。
[3.第3実施形態]
以下、本発明の第3実施形態について説明する。
本実施形態に係る動画配信システム1、サーバ4、及び携帯端末3の構成は、図1~図3に係る第1実施形態に係る動画配信システム1、サーバ4、及び携帯端末3の構成と同様であるので説明を省略する。
本実施形態に係る動画配信システム1は、グループ登録された携帯端末3毎に、動画の再生開始からの継時時間を計測する。そして、各携帯端末3は、再生された動画の実際の進行時間である実進行時間が予定された進行時間である予定進行時間と異なる場合に、実進行時間が予定進行時間に一致するように動画データの再生を制御する進行同期処理を行う。すなわち、本実施形態に係る進行同期処理は、第1実施形態において説明した強制シークの一例でもある。
[3-1.本実施形態に係る進行同期処理の概要]
本実施形態に係る携帯端末3は、第2実施形態と同様に、一例としてHLSによって表される動画再生ファイル50がサーバ4から携帯端末3に配信され、動画再生ファイル50に基づいて携帯端末3が動画データをダウンロードして再生する。そして、動画再生ファイル50には、第2実施形態と同様に、バッファ動画データを示すtsファイルが含まれる。なお、バッファ動画データは、予め定められた回数繰り返し再生(ループ再生)されるように設定されており、バッファ動画データは、例えば、1秒の動画を10回ループ再生するように予め設定されている。
各携帯端末3は、実進行時間が予定進行時間に一致するように、動画再生ファイル50により示されるバッファ動画データの再生を制御する。
ここで、予定進行時間と実進行時間とについて具体的に説明する。予定進行時間は、動画データ(動画再生ファイル50)に予め設定されており、動画の再生に遅れがない場合における動画の再生開始からの継時時間である。すなわち、予定進行時間は、動画を再生する携帯端末3にかかわらず同じである。一方、実進行時間は、実際の再生開始からの継時時間であり、動画の再生が遅れている場合にはその遅れが反映される。すなわち、実進行時間は、動画を再生する携帯端末3毎に異なる可能性がある。
そして、実進行時間と予定進行時間との差異が、各携帯端末3における動画の進行の遅れ時間となる。携帯端末3は、この遅れ時間を解消するように、バッファ動画データの再生を制御する。なお、実進行時間と予定進行時間が一致する場合は、動画の進行に遅れがない場合である。
本実施形態に係る進行同期処理について、図16を参照して説明する。図16(A)は、動画再生開始からの予定進行時間を示した模式図であり、動画の進行に遅れがない場合は、予定進行時間と実進行時間とが一致する。なお、本実施形態に係る予定進行時間及び実進行時間は、一例として、図16に示されるように動画の再生開始から各tsファイルで示される動画データの再生終了までの時間とする。図16(B)は、動画の進行に遅れがある場合であり、一例として、chapter 2に遅れが生じており、予定進行時間2と実進行時間2との差異が動画の進行の遅れ時間となる。
携帯端末3は、この遅れ時間を解消するように、chapter 2の後に再生されるバッファ動画データの再生を制御する。より具体的には、実進行時間が予定進行時間に一致するように、バッファ動画データのループ再生回数を予め定められた回数よりも減少させる。例えば、遅れ時間が5秒の場合には、再生時間が1秒とされるバッファ動画データのループ再生回数を5回少なくする。
これにより、バッファ動画データの終了時における実進行時間3が予定進行時間3と一致する。さらに、その後のchapter 4に遅れが生じない場合には、実進行時間4と予定進行時間4とが一致する。
なお、本実施形態に係る携帯端末3は、グループ登録された複数の携帯端末3で動画の再生開始タイミングを合わせる。そして、グループ登録された各携帯端末3が、各々で再生する動画の実進行時間が予定進行時間に一致するようにバッファ動画データの再生を制御するので、結果的に、各携帯端末3で動画の進行が同期することになる。
なお、本実施形態に係る再生開始タイミングは、一例として、親端末3Mにおける動画の再生開始タイミングに合わせられる。すなわち、子端末3Sは、親端末3Mから動画の再生開始タイミングを示す進行状態情報を受信し、この再生開始タイミングに合わせて、動画の再生を開始する。
また、本実施形態に係る携帯端末3は、自身で再生されている動画の進行状態を示す進行状態情報を生成し、グループ登録された他の携帯端末3へ送信する。この進行状態情報には、自身で再生されている動画の遅れ時間が含まれている。
そして、本実施形態に係る携帯端末3は、グループ登録された複数の携帯端末3の全てで、実進行時間が予定進行時間に一致している場合、再生の制御対象とされるバッファ動画データの再生を行わない。これにより、グループ登録された携帯端末3で再生される動画の進行がよりスムーズに行われる。
[3-2.携帯端末の動画再生同期機能]
図17は、本実施形態に係る携帯端末3の動画再生同期機能に関する機能ブロック図である。携帯端末3が備える主制御部40は、実進行時間計測部100、進行遅れ判定部102、動画再生制御部104、及び進行状態情報処理部106を備える。主制御部40が備える各機能は、補助記憶部44に記憶されているプログラムによって実現される。
実進行時間計測部100は、動画の再生開始からの継時時間を計測する。
進行遅れ判定部102は、再生された動画の実進行時間が予定進行時間と一致しているか否かを判定し、一致していない場合はそのずれである遅れ時間を導出する。
動画再生制御部104は、進行遅れ判定部102により導出された遅れ時間を解消するように、すなわち実進行時間が予定進行時間に一致するようにバッファ動画データの再生を制御する。また、動画再生制御部104は、グループ登録された他の携帯端末3から送信される進行状態情報に基づいて、バッファ動画データの再生の有無を決定する。
進行状態情報処理部106は、自身で再生される動画の進行状態、すなわち遅れ時間を進行状態情報として通信部46を介して他の携帯端末3へ送信し、他の携帯端末3から受信した進行状態情報を主記憶部42へ記憶する。
[3-3.動画再生同期処理のフロー]
図18は、携帯端末3が備える主制御部40によって実行される本実施形態に係る動画再生同期処理の流れを示すフローチャートである。動画再生同期処理を実行するためのプログラムは補助記憶部44の所定領域に予め記憶されている。図18に示される動画再生同期処理は、一例として、動画再生ファイル50により示される動画データの再生開始と共に実行が開始される。
まず、ステップ300では、動画再生ファイル50により示される動画の再生を動画再生制御部104が行い、実進行時間の計測タイミングに至ったか否かを実進行時間計測部100が判定し、肯定判定の場合はステップ302へ移行する。
ステップ302では、実進行時間を実進行時間計測部100が計測する。なお、実進行時間が計測される毎に、進行状態情報処理部106は、実進行時間と予定進行時間との差異(遅れ時間)を進行状態情報として他の携帯端末3へ送信する。
ステップ304では、バッファ動画データの再生タイミングに至ったか否かを動画再生制御部104が判定し、肯定判定の場合はステップ306へ移行する一方、否定判定の場合はステップ300へ戻る。
次のステップ306では、実進行時間と予定進行時間とが一致するか否かを進行遅れ判定部102が判定し、否定判定の場合はステップ308へ移行する一方、肯定判定の場合はステップ310へ移行する。
ステップ308では、動画進行の遅れ時間を解消するように、動画再生制御部104がバッファ動画データの再生を制御する。
一方、ステップ306で肯定判定となった場合に移行するステップ310では、他の携帯端末3から送信された進行状態情報に基づいて、動画の進行に遅れがある他の携帯端末3が存在するか否かを動画再生制御部104が判定する。そして、肯定判定の場合はステップ312へ移行する一方、否定判定の場合はステップ314へ移行する。
ステップ312は、動画再生制御部104がバッファ動画データを所定回数でループ再生することで、自身における動画の進行を遅れがある他の携帯端末3と同じとし、ステップ300へ移行する。
ステップ314では、動画再生制御部104がバッファ動画データの再生を行わずに、ステップ300へ戻る。
以上説明したように、本実施形態に係るグループ登録された各携帯端末3は、動画の再生開始からの継時時間を計測し、再生された動画の実進行時間が予定進行時間と異なる場合に、実進行時間が予定進行時間に一致するように動画データの再生を制御する。これにより、複数のユーザが同時に動画視聴を行う場合に、各携帯端末3における動画の再生が簡易に同期される。
[3-4.変形例]
本変形例に係る携帯端末3は、実進行時間が予定進行時間に一致するように、バッファ動画データの再生速度を予め設定された再生速度よりも速くする。この変形例の場合、バッファ動画データは、ループ再生されることなく、1回の再生が終了後に次のtsファイルにより示される動画データの再生が開始される。このために、動画再生制御部104は、実進行時間と予定進行時間とが一致するように、バッファ動画データの再生速度を算出し、算出した再生速度でバッファ動画データを再生させる。
さらに、他の変形例として携帯端末3は、実進行時間が予定進行時間に一致するように、バッファ動画データの再生を途中で停止、又はバッファ動画データの再生を行わないとしてもよい。この変形例の場合、遅れ時間がバッファ動画データの再生時間よりも長い場合には、バッファ動画データの再生が行われない。また、遅れ時間に相当する時間を再生しないように、バッファ動画データの再生が途中で停止される。
[4.他の実施形態]
以上、本発明を、上記各実施形態を用いて説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。発明の要旨を逸脱しない範囲で上記各実施形態に多様な変更又は改良を加えることができ、該変更又は改良を加えた形態も本発明の技術的範囲に含まれる。また、上記各実施形態を適宜組み合わせてもよい。
また、上記各実施形態においてサーバ4が行っていた処理の一部を、動画が配信される携帯端末3で行う形態としてもよい。
また、上記各実施形態で説明した各フローで説明した各種処理の流れも一例であり、本発明の主旨を逸脱しない範囲内において不要なステップを削除したり、新たなステップを追加したり、処理順序を入れ替えたりしてもよい。