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

ユーザ端末及びプログラム Download PDF

Info

Publication number
JP2021153270A
JP2021153270A JP2020053275A JP2020053275A JP2021153270A JP 2021153270 A JP2021153270 A JP 2021153270A JP 2020053275 A JP2020053275 A JP 2020053275A JP 2020053275 A JP2020053275 A JP 2020053275A JP 2021153270 A JP2021153270 A JP 2021153270A
Authority
JP
Japan
Prior art keywords
segment
moving image
switching
reception buffer
stored
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2020053275A
Other languages
English (en)
Other versions
JP7458848B2 (ja
Inventor
正顕 黒住
Masaaki Kurozumi
正顕 黒住
正男 山本
Masao Yamamoto
正男 山本
敏 西村
Satoshi Nishimura
敏 西村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Japan Broadcasting Corp
Original Assignee
Nippon Hoso Kyokai NHK
Japan Broadcasting Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Hoso Kyokai NHK, Japan Broadcasting Corp filed Critical Nippon Hoso Kyokai NHK
Priority to JP2020053275A priority Critical patent/JP7458848B2/ja
Publication of JP2021153270A publication Critical patent/JP2021153270A/ja
Application granted granted Critical
Publication of JP7458848B2 publication Critical patent/JP7458848B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

【課題】ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮すると共に、不体裁の発生を防止する。【解決手段】ユーザ端末1のセグメント要求部21は、動画Aから動画Bへの切替操作時に、受信バッファ20に空きがある場合、受信バッファ20に格納されたセグメントのうち最後部の次のSG番号を特定し、SG要求を出力する。格納処理部22は、サーバ2から取得した動画Bのセグメントを受信バッファ20に追加する。セグメント要求部21は、受信バッファ20に空きがなく、動画Aのセグメントが格納されている場合、受信バッファ20に格納された動画Aのセグメントのうち最後部のSG番号を特定し、SG要求を出力する。格納処理部22は、サーバ2から取得した動画Bのセグメントを、受信バッファ20に格納された動画Aの当該セグメントの箇所に上書きする。【選択図】図3

Description

本発明は、サーバからユーザ端末へ動画を配信するアダプティブストリーミングを行うシステムにおいて、ユーザ操作に従い動画を切り替えるユーザ端末及びプログラムに関する。
従来、テレビ放送を視聴するユーザは、別のチャンネルに切り替えるために、ザッピングを行うことがある。同様に、インターネットにより配信された動画(ネット動画)を視聴しているときも、ユーザは、別の動画に切り替えるために、ザッピングを行うことがある。
このようなザッピングにおいては、別の動画を再生するまでの時間が長ければ長いほど、ユーザの体感品質が低下し、当該動画の視聴を止めてしまう可能性がある。
一般に、ネット動画は、アダプティブストリーミングと呼ばれる方式により、インターネット経由でサーバからユーザ端末へ転送される。このときの動画データは、時間軸上で細切れにしたセグメントと呼ばれる単位で転送される。セグメントは、エンコードされた動画データを数秒単位に分割した動画ファイルである。例えば動画データの時間長は、1分、10分、1時間等のように様々であり、セグメントの時間長も、1秒、5秒、10秒等のように様々である。
アダプティブストリーミングには、例えばMPEG−DASH方式、HLS方式がある。これらの方式は、基本的な動作フローが同じであり、インターネットが輻輳した場合においても、できる限り動画の再生を継続し、途切れが発生しないという特長がある。
この特長を実現するために、ユーザ端末は、バッファメモリを利用して所定数のセグメントをバッファリングした後、当該セグメントを動画デコーダへ受け渡す。
また、動画の切り替え前のセグメントと切り替え後のセグメントとを、それぞれ別のバッファメモリに格納する技術も開示されている(例えば、特許文献1を参照)。この技術により、バッファメモリに格納されたセグメントを再使用できる場合には、動画を速やかに再生することができる。
バッファリングされるセグメントの数は、例えば、3セグメント、5セグメント等のように様々であり、セグメント数が多ければ多いほど、インターネットが輻輳した場合に、動画の再生は途切れ難くなる。
しかしながら、バッファリングされるセグメントの数が多いほど、バッファリングに時間がかかってしまう。このため、ユーザ端末がセグメントの配信をサーバへ要求してから、動画の再生が開始されるまでの間の時間が長くなり、ユーザにとっては、視聴開始までの待ち時間が長くなる。
特開2017−108217号公報
前述のとおり、ユーザがネット動画をザッピングすると、直ちに別の動画に切り替わることはなく、切り替わるのに時間がかかってしまう。ザッピングは、視聴中の動画から別の動画への切替操作をいう。
これは、動画の切替操作が行われると、ユーザ端末が既にバッファリングした視聴中の動画の全セグメントを動画デコーダへ受け渡す必要があり、その後に、次に視聴する別の動画のセグメントを動画デコーダへ受け渡すからである。つまり、切替操作が行われたときに、既にバッファリングされた視聴中の動画のセグメントの数に応じて、切替時間、すなわち別の動画の視聴開始までの待ち時間が決定されることとなる。既にバッファリングされた視聴中の動画のセグメントの数が多いほど、待ち時間が長くなり、セグメントの数が少ないほど、待ち時間が短くなる。
例えば、バッファリングされた視聴中の動画のセグメントの数が4セグメント、セグメント長が4秒の場合、次に視聴する別の動画のセグメントを動画デコーダへ受け渡すまでの時間は、少なくとも4セグメント×4秒=16秒である。この16秒が、そのままユーザの視聴開始までの待ち時間となる。
以下、視聴中の動画を切替操作前の動画といい、これから視聴する別の動画を切替操作後の動画という。この場合、受信バッファに格納されている切替操作前の動画の全てのセグメントの再生が完了した後に、切替操作後の動画の再生が行われる。
(従来技術の切替操作)
図5は、従来技術において、ケース1の場合の動画Aから動画Bへの切替操作に伴う受信バッファに格納されたセグメントの変化、及び動画Bが切替再生されるタイミングを説明する図である。切替操作前の動画が動画Aであり、切替操作後の動画が動画Bである。
横軸は再生時刻(秒)を示し、縦軸は受信バッファ時間(受信バッファに格納されたセグメントの動画時間)(秒)を示す。sxxにおけるxxは、セグメント番号を示す。細い実線で囲まれたセグメントは、動画Aのセグメントの動画データを示し、太い実線で囲まれたセグメントは、動画Bのセグメントの動画データを示す。この例は、常にタイムスタンプが最新のセグメントがサーバから取得され、受信バッファに格納されるものとする。セグメント番号は、動画のセグメントを再生する順番を表す番号を示し、タイムスタンプは、動画のセグメントの先頭を再生する時刻を示す。
図5に示すように、例えば再生時刻t1のタイミングにおいて、受信バッファには、動画Aのs01,s02のセグメント(の動画データ)が格納されており、動画Aのs03のセグメントの格納処理が開始されており、その一部が格納されていることを示している。また、このタイミングの受信バッファには、動画Aのs04のセグメントは格納されていない。
そして、再生時刻t2のタイミングにおいて、動画Aのs03のセグメントの格納処理が完了し、受信バッファには、動画Aのs01,s02,s03のセグメントが格納されていることを示している。また、このタイミングの受信バッファには、動画Aのs04のセグメントは格納されておらず、動画Aのs04のセグメントの格納処理がまさに開始されることを示している。
また、例えば再生時刻t3のタイミングにおいて、受信バッファには、動画Aのs06のセグメント及び動画Bのs07,s08,s09のセグメントが格納されていることを示している。
ケース1は、1セグメント分の動画時間を4秒、受信バッファ時間を16秒、動画ビットレートを1Mビット/秒、回線スループットを4Mビット/秒の条件を示している。後述する図6〜図8についても同様である。
再生時刻0秒からセグメントの取得が開始され、セグメントが受信バッファ時間16秒分取得されたときに、動画デコーダによる再生が開始される。動画デコーダが動画を再生する際には、1セグメント分の動画データが受信バッファから瞬時に読み出される。
ユーザ端末がサーバから動画を取得する際には、セグメントが受信バッファに受信バッファ時間16秒分満たされるまで連続して取得される。そして、動画再生のために受信バッファから1つのセグメントが読み出されたときに、受信バッファに1つの空きが生じたとして、サーバからセグメントが取得される。
ケース1の条件から、サーバから1セグメント分の動画取得時間は、4秒×(1Mビット/秒)/(4Mビット/秒)=1秒となる。動画再生のシナリオは、再生時刻12秒のタイミングで、動画Aから動画Bへの切替操作が行われるものとする。
図5を参照して、再生時刻4秒のタイミングにおいて、受信バッファには、動画Aのs01〜s04のセグメントが受信バッファ時間16秒分満たされるため、受信バッファから動画Aのs01のセグメントが読み出され再生される。そして、動画Aのs02〜s04のセグメントがシフトして、受信バッファには1セグメント分の空きが生じる。そうすると、動画Aのs05のセグメントがサーバから取得されて受信バッファに追加される。
再生時刻8秒のタイミングにおいて、動画Aのs01のセグメントの再生が完了すると、受信バッファから動画Aのs02のセグメントが読み出され再生される。そして、動画Aのs03〜s05のセグメントがシフトして、受信バッファには1セグメント分の空きが生じる。そうすると、動画Aのs06のセグメントがサーバから取得されて受信バッファに追加される。
再生時刻12秒のタイミングにおいて、ユーザにより動画Aから動画Bへの切替操作が行われる。このタイミングと同時に、動画Aのs02のセグメントの再生が完了し、受信バッファから動画Aのs03のセグメントが読み出され再生され、動画Aのs04〜s06のセグメントがシフトして、受信バッファには1セグメント分の空きが生じるものとする。そうすると、切替操作後の動画Bにおけるs07のセグメントがサーバから取得されて受信バッファに追加される。これにより、受信バッファは、切替操作前の動画Aにおけるs04〜s06のセグメント及び切替操作後の動画Bにおけるs07のセグメントが格納された状態となる。
再生時刻16秒のタイミングにおいて、動画Aのs04のセグメントの読み出し及び再生が行われ、動画Bのs08のセグメントの取得が行われる。これにより、動画Aの再生が継続し、受信バッファは、動画Aのs05,s06のセグメント及び動画Bのs07,s08のセグメントが格納された状態となる。
再生時刻20秒のタイミングにおいて、動画Aのs05のセグメントの読み出し及び再生が行われ、動画Bのs09のセグメントの取得が行われる。これにより、動画Aの再生が継続し、受信バッファは、前述した再生時刻t3のタイミングのように、動画Aのs06のセグメント及び動画Bのs07〜s09のセグメントが格納された状態となる。
再生時刻24秒のタイミングにおいて、動画Aのs06のセグメントの読み出し及び再生が行われ、動画Bのs10のセグメントの取得が行われる。これにより、動画Aの再生が継続し、受信バッファは、動画Bのs07〜s10のセグメントが格納された状態となる。
再生時刻28秒のタイミングにおいて、動画Bのs07のセグメントの読み出し及び再生が行われ(枠で囲まれたs07)、動画Bのs11のセグメントの取得が行われる。これにより、動画Aの再生が終了し、動画Bの再生に切り替わる。受信バッファは、動画Bのs08〜s11のセグメントが格納された状態となる。そして、動画Bの再生が継続する。
このように、ユーザにより動画Aから動画Bへの切替操作が行われると、受信バッファに格納されている切替操作前の動画Aの全てのセグメントの再生が完了した後に、切替操作後の動画Bの再生が行われる。
図5に示したように、切替操作が行われると、動画Aから動画Bに直ちに切り替わることはなく、16秒(28−12=16)の切替時間がかかってしまう。ユーザは、バッファリングされた動画Aのs03〜s06のセグメントが受け渡されるまで、16秒の間待つ必要があり、切り替わるのに時間がかかるという問題があった。
このため、ユーザによる動画Aから動画Bへの切替操作に伴い、動画の切替時間を短縮することが所望されていた。
そこで、本件特許出願の同一の出願人により、本件特許出願時に未公開の特願2019−12836号公報記載の発明が提案されている。この特願2019−12836号公報記載の発明は、切替操作が行われると、ダウンロード予測時間に基づいて新たな動画Bの上書領域(上書きするセグメント番号)を決定し、動画Bをその上書領域から上書きするものである。
(特願2019−12836号公報記載の発明の切替操作)
図6は、特願2019−12836号公報記載の発明において、ケース1の場合の動画Aから動画Bへの切替操作に伴う受信バッファに格納されたセグメントの変化、及び動画Bが切替再生されるタイミングを説明する図である。
横軸は再生時刻(秒)を示し、縦軸は受信バッファ時間(受信バッファに格納されたセグメントの動画時間)(秒)を示す。ケース1の条件、受信バッファからのセグメントの読み出し動作、受信バッファへの格納動作、サーバからの取得動作等は、図5にて説明したとおりである。この例では、サーバから取得されるセグメントのタイムスタンプは、当該セグメントが受信バッファに追加または上書される位置、及び受信バッファに格納されているセグメントのタイムスタンプに応じて、選択されるものとする。
図6を参照して、再生時刻4秒及び8秒のタイミングにおける動作は、図5と同様である。
再生時刻12秒のタイミングにおいて、ユーザにより動画Aから動画Bへの切替操作が行われる。このタイミングと同時に、動画Aのs02のセグメントの再生が完了し、受信バッファから動画Aのs03のセグメントが読み出され再生され、動画Aのs04〜s06のセグメントがシフトして、受信バッファには1セグメント分の空きが生じるものとする。このタイミングにおいて、ダウンロード予測時間に基づいて、上書領域として例えば動画Aのs05のセグメントが決定される。
そうすると、切替操作後の動画Bにおけるs05のセグメントがサーバから取得され、動画Bのs05のセグメントが、受信バッファに格納された動画Aのs05のセグメントの領域に上書きされる。これにより、受信バッファは、動画Aのs04のセグメント、動画Bのs05及び動画Aのs06のセグメントが格納された状態となる。
そして、動画Bのs06,s07のセグメントがサーバから取得され、動画Bのs06のセグメントが、受信バッファに格納された動画Aにおけるs06のセグメントの領域に上書きされ、動画Bのs07のセグメントが追加される。これにより、受信バッファは、切替操作前の動画Aのs04のセグメント及び切替操作後の動画Bのs05〜s07のセグメントが格納された状態となる。
再生時刻16秒のタイミングにおいて、動画Aのs04のセグメントの読み出し及び再生が行われ、動画Bのs08のセグメントの取得が行われる。これにより、動画Aの再生が継続し、受信バッファは、動画Bのs05〜s08のセグメントが格納された状態となる。
再生時刻20秒のタイミングにおいて、動画Bのs05のセグメントの読み出し及び再生が行われ(枠で囲まれたs05)、動画Bのs09のセグメントの取得が行われる。これにより、動画Aの再生が終了し、動画Bの再生に切り替わり、これ以降は、動画Bの再生が継続する。つまり、再生時刻20秒のタイミングで切替再生が行われることとなる。
このように、特願2019−12836号公報記載の発明の場合には、切替操作が行われると、ダウンロード予測時間に基づいて新たな動画Bの上書領域(上書きするセグメント番号)が決定され、新たな動画Bがその上書領域から上書きされる。
図6に示したように、動画Aから動画Bへの切替時間は、8秒(20−12=8)であり、図5に示した切替時間16秒よりも短い。これにより、切替操作が行われると、受信バッファに格納されている動画Aの全てのセグメントの再生の完了を待つことなく、上書きされた動画Bの再生が行われる。このため、切替操作に伴う動画の切替時間を短縮することができる。
しかしながら、特願2019−12836号公報記載の発明では、インターネットの回線の遅延または帯域の変動により、ダウンロードの回線スループットが低下した場合、切替操作の際に切り替え前後の動画が交互に再生されて動画が乱れる可能性がある。また、受信バッファに格納されたセグメントの数が低下し、再生が停止する可能性もある。
例えば図6において、再生時刻12秒のタイミングで切替操作が行われた後に、新たな動画Bのs05のセグメントがサーバから取得された場合を想定する。この場合、受信バッファは、動画Aのs04のセグメント、動画Bのs05のセグメント及び動画Aのs06のセグメントが格納されている状態となる。
ここで、引き続き新たな動画Bのs06のセグメントがサーバから取得されるが、ダウンロードの回線スループットが低下すると、動画Bのs06のセグメントは、受信バッファに格納された動画Aのs06の領域への上書きが遅れてしまう。そうすると、動画Aのs03,s04のセグメントの再生が完了した後、動画Bのs05のセグメントの再生が行われ、そして、動画Aのs06のセグメントの再生が行われることとなり得る。
つまり、動画A,Bの1セグメントをそれぞれA,Bとすると、再生は、A→A→B→B→B→B・・・となるべきところ、A→A→B→A→B→B・・・となってしまう。このように、切替操作時には、切り替え前後の動画が交互に再生されて乱れるという不体裁が発生する可能性があり、一層安定した再生を実現できることが望まれていた。
そこで、本発明は前記課題を解決するためになされたものであり、その目的は、ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮すると共に、不体裁の発生を防止するユーザ端末及びプログラムを提供することにある。
前記課題を解決するために、請求項1のユーザ端末は、サーバからインターネットを介して配信された動画のセグメントを受信し、前記セグメントをバッファリングして読み出し、前記セグメントをデコードして再生するユーザ端末において、前記インターネットを介して受信したそれぞれの前記セグメントを、受信バッファの最前領域から最後領域まで格納する受信バッファ管理部と、前記受信バッファの前記最前領域に格納された前記セグメントを読み出し、当該セグメントをデコードする動画デコーダと、を備え、前記受信バッファ管理部が、ユーザにより新たな動画を再生するための切替操作が行われると、前記受信バッファに前記セグメントを格納するための空き領域がある場合、前記新たな動画の切替後セグメントを取得し、当該切替後セグメントを前記受信バッファの前記空き領域に追加し、前記空き領域がなく、かつ前記受信バッファに再生中の前記動画の切替前セグメントが格納されている場合、前記受信バッファに格納された全ての前記切替前セグメントのうち最後に読み出される前記切替前セグメントを最後部の前記切替前セグメントとして特定し、新たな前記動画の切替後セグメントを取得し、当該切替後セグメントを、前記受信バッファにおける前記最後部の前記切替前セグメントが格納された領域に上書きする、ことを特徴とする。
また、請求項2のユーザ端末は、請求項1に記載のユーザ端末において、前記受信バッファ管理部は、セグメント要求部及び格納処理部を備え、前記ユーザにより前記切替操作が行われると、前記セグメント要求部が、前記受信バッファに前記セグメントを格納するための前記空き領域があるかないかを判定し、前記空き領域があると判定した場合、前記受信バッファに格納された全ての前記セグメントのうち前記最後部を特定し、当該最後部の次のセグメントにおけるセグメント番号またはタイムスタンプを特定し、当該セグメント番号または当該タイムスタンプに対応する前記切替後セグメントを取得するためのセグメント要求として、第1セグメント要求を生成し、前記格納処理部が、前記セグメント要求部により生成された前記第1セグメント要求に対応する前記切替後セグメントを取得し、当該切替後セグメントを前記受信バッファの前記空き領域に追加し、前記セグメント要求部が、前記空き領域が無いと判定した場合、前記受信バッファに前記切替前セグメントが格納されているか否かを判定し、前記切替前セグメントが格納されていると判定した場合、前記受信バッファに格納された全ての前記切替前セグメントのうち前記最後部を特定し、当該最後部のセグメントにおけるセグメント番号またはタイムスタンプを特定し、当該セグメント番号または当該タイムスタンプに対応する前記切替後セグメントを取得するためのセグメント要求として、第2セグメント要求を生成し、前記格納処理部が、前記セグメント要求部により生成された前記第2セグメント要求に対応する前記切替後セグメントを取得し、当該切替後セグメントを、前記受信バッファの前記最後部の領域に上書きする、ことを特徴とする。
さらに、請求項3のプログラムは、コンピュータを、請求項1または2に記載のユーザ端末として機能させることを特徴とする。
以上のように、本発明によれば、ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮すると共に、不体裁の発生を防止して一層安定した再生を実現することができる。
本発明の実施形態によるユーザ端末を含む全体システムの構成例を示す概略図である。 受信バッファ管理部の処理を示すフローチャートである。 受信バッファ管理部の構成を示すブロック図である。 動画切替時のセグメント取得処理(S202)を示すフローチャートである。 従来技術において、ケース1の場合の動画Aから動画Bへの切替操作に伴う受信バッファに格納されたセグメントの変化、及び動画Bが切替再生されるタイミングを説明する図である。 特願2019−12836号公報記載の発明において、ケース1の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。 本発明の実施形態において、ケース1の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。 図7において、動画Bのs04のセグメントの取得が遅れた場合を説明する図である。 従来技術において、ケース2の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。 特願2019−12836号公報記載の発明において、ケース2の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。 本発明の実施形態において、ケース2の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。
以下、本発明を実施するための形態について図面を用いて詳細に説明する。本発明は、ユーザによる動画の切替操作時に、受信バッファに空きがある場合、切替操作後の新たな動画を受信バッファの空き領域に追加する。また、本発明は、受信バッファに空きがなく、切替操作前の動画が格納されている場合、新たな動画を、受信バッファに格納された全ての切替操作前の動画(再生中の動画)のセグメントのうち最後部のセグメント(最後に読み出されるセグメント)の領域に上書きする。
これにより、切替操作時の受信バッファには、新たな動画のセグメントが追加または上書きされるため、受信バッファに格納されたセグメントの数の低下を抑えることができる。また、新たな動画のセグメントは、受信バッファの連続した領域に順次格納されることとなる。
したがって、ネット動画を視聴しているユーザが切替操作を行ったときに、新たな動画の視聴開始までの待ち時間を短縮することができ、動画が交互に再生されて乱れるという不体裁の発生を防止し、一層安定な再生を実現することができる。
〔全体システム〕
まず、本発明の実施形態によるユーザ端末を含む全体システムについて説明する。図1は、本発明の実施形態によるユーザ端末を含む全体システムの構成例を示す概略図である。
このシステムは、ユーザ端末1及びサーバ2を備えて構成され、サーバ2のストレージ4に格納された動画を、サーバ2からインターネット3を介してユーザ端末1へ配信するアダプティブストリーミングを行う。ユーザ端末1及びサーバ2は、インターネット3を介して接続される。インターネット3は、例えばオープンインターネットである。
ユーザ端末1は、通信インターフェース10、OS(オペレーティングシステム)11、WEBブラウザ12、受信バッファ管理部13、動画デコーダ14及び表示部15を備えている。ユーザ端末1は、パーソナルコンピュータであってもよいし、スマートフォン等の携帯型の端末装置であってもよい。要するに、ユーザ端末1は、サーバ2から動画をセグメント毎にダウンロードし、これをバッファリングして再生する機能を有していれば何でもよい。
通信インターフェース10は、当該ユーザ端末1とサーバ2との間で、インターネット3を介して所定のプロトコルに従いデータの送受信を行う。通信インターフェース10は、例えばEthernet(イーサネット(登録商標))の規格に従って動作する。
OS11は、各種のプログラムの実行を制御するためのソフトウェアであり、基本的な機能として、通信インターフェース10、WEBブラウザ12、受信バッファ管理部13、動画デコーダ14及び表示部15を管理する。OS11は、例えばWindows(登録商標)であってもよいし、iOSであってもよい。
WEBブラウザ12は、WEBページを閲覧するためのソフトウェアであり、例えばInternet Explorer(インターネットエクスプローラー、登録商標)であってもよいし、Chrome(クローム、登録商標)であってもよい。
受信バッファ管理部13は、サーバ2から配信された動画のセグメントを、受信バッファの最前領域から最後領域まで順番にバッファリングし、当該セグメントを最前領域から動画デコーダ14へ受け渡す。最前領域は、動画デコーダ14により読み出されるセグメントの領域であり、最後領域は、セグメントが格納されることで受信バッファが満杯となる当該セグメントの領域である。
受信バッファ管理部13は、ユーザによる動画の切替操作を検知すると、図5に示した従来技術及び図6に示した特願2019−12836号公報記載の発明に代わる新方式にて、動画の切替処理を行う。
具体的には、受信バッファ管理部13は、受信バッファに空きがある場合、サーバ2から送信された切替操作後の動画のセグメントを、受信バッファの空き領域に追加する。一方、受信バッファ管理部13は、受信バッファに空きがなく、かつ受信バッファに切替操作前の動画が格納されている場合、サーバ2から送信された切替操作後の動画のセグメントを、受信バッファに格納されている全ての切替操作前の動画のセグメントのうち最後部のセグメントの領域に上書きする。
また、受信バッファ管理部13は、受信バッファに空きがなく、かつ受信バッファに切替操作前の動画が格納されていない場合、通常の処理を行う。つまり、受信バッファ管理部13は、受信バッファが空きとなるのを待って、サーバ2から送信された切替操作後の動画のセグメントを、受信バッファの空き領域に追加する。尚、サーバ2から送信されるセグメントのタイムスタンプは、前述の図6と同様に、当該セグメントが受信バッファに追加または上書される位置、及び受信バッファに格納されているセグメントのタイムスタンプに応じて、選択されるものとする。
図1に戻って、動画デコーダ14は、受信バッファ管理部13からセグメントを読み出し、H264、H265等の各種符号化方式で符号化されたセグメントの動画データをデコードし、表示部15に表示する。これにより、動画の再生が行われる。表示部15は、テレビ画面であってもよいし、パソコン用モニタの画面であってもよい。
サーバ2は、ユーザ端末1からインターネット3を介してセグメント要求を受信し、当該セグメント要求に対応する動画のセグメントをストレージ4から読み出し、読み出したセグメントを、インターネット3を介してユーザ端末1へ送信する。サーバ2は、動画を配信可能なコンピュータ装置であれば何でもよい。
〔受信バッファ管理部13〕
次に、図1に示したユーザ端末1の受信バッファ管理部13について詳細に説明する。図2は、受信バッファ管理部13の処理を示すフローチャートである。
ユーザ端末1を操作するユーザがある動画を視聴しているものとする。ユーザにより、視聴中の動画を新たな動画に切り替える操作が行われると、当該切替操作に伴う動画切替要求が受信バッファ管理部13に入力される。
受信バッファ管理部13は、動画切替要求を入力したか否かを判定する(ステップS201)。受信バッファ管理部13は、ステップS201において、動画切替要求を入力したと判定した場合(ステップS201:Y)、動画切替時のセグメント取得処理を行い(ステップS202)、ステップS203へ移行する。ステップS202の動画切替時のセグメント取得処理については後述する。
一方、受信バッファ管理部13は、ステップS201において、動画切替要求を入力していないと判定した場合(ステップS201:N)、ステップS203へ移行する。
受信バッファ管理部13は、ステップS202またはステップS201(N)から移行して、通常時のセグメント取得処理を行う(ステップS203)。
具体的には、受信バッファ管理部13は、受信バッファに空きがある場合、視聴中の動画のセグメントをサーバ2から順次取得し、受信バッファの空き領域に追加する。受信バッファが所定の受信バッファ時間満たされるまで、連続した取得及び追加処理が行われる。受信バッファに格納されたセグメントは、動画デコーダ14により読み出され再生される。
受信バッファ管理部13は、ステップS203から移行して、処理が終了しない限り、ステップS201〜S203の処理を継続する(ステップS204)。
図3は、受信バッファ管理部13の構成を示すブロック図である。この受信バッファ管理部13は、受信バッファ20、セグメント要求部21及び格納処理部22を備えている。受信バッファ20には、動画のセグメントが格納される。
セグメント要求部21は、図2のステップS203における通常時のセグメント取得処理において、受信バッファ20に空きがある場合、受信バッファ20に格納されている全てのセグメントのうち最後部の次のセグメント番号(SG番号)を特定する。そして、セグメント要求部21は、当該SG番号のセグメントを取得するためのセグメント要求(SG要求)を生成して通信インターフェース10に出力する。SG要求は、通信インターフェース10からサーバ2へ送信される。
セグメント要求部21は、ユーザによる動画の切替操作に伴う動画切替要求を入力すると、図2のステップS202における動画切替時のセグメント取得処理において、受信バッファ20に格納されたセグメントの格納状況を確認する。
セグメント要求部21は、当該格納状況に応じて、サーバ2から取得する切替操作後の動画のセグメントのSG番号を決定し、SG番号を格納処理部22に出力する。セグメント要求部21は、切替操作後の動画の当該SG番号のセグメントを取得するためのSG要求を生成して通信インターフェース10に出力する。SG要求は、通信インターフェース10からサーバ2へ送信される。
セグメント要求部21は、受信バッファ20に格納された全てのセグメントが新たな動画のセグメントである場合、動画切替時のセグメント取得処理が完了したとして、通常時のセグメント取得処理へ移行する。
格納処理部22は、セグメント要求部21からSG番号を入力し、サーバ2から取得した当該SG番号のセグメントを、受信バッファ20における当該SG番号の領域に格納する。
ここで、取得した当該SG番号のセグメントは、受信バッファ20の空き領域に追加されるか、または、同じSG番号のセグメントが格納されている領域に上書きされることとなる。
具体的には、格納処理部22は、図2のステップS203における通常時のセグメント取得処理において、サーバ2から取得した切替操作後の当該SG番号のセグメントを受信バッファ20の空き領域に追加する。
受信バッファ20には、動画デコーダ14により読み出されるセグメントが格納された最前領域から、セグメントが格納されることで当該受信バッファ20が満杯となる最後領域までの間のそれぞれの領域に、セグメントが格納される。セグメントは、空き領域のうち最前領域に最も近い領域(最前部)から順番に追加される。
また、格納処理部22は、図2のステップS202における動画切替時のセグメント取得処理において、サーバ2から取得した切替操作後の動画の当該SG番号のセグメントを、受信バッファ20における当該SG番号の領域に上書きする。
(動画切替時のセグメント取得処理(S202))
図4は、図2に示した動画切替時のセグメント取得処理(S202)を示すフローチャートである。
セグメント要求部21は、図2のステップS201において、動画切替要求を入力した場合、ユーザによる動画の切替操作があったことを認識する。そして、セグメント要求部21は、受信バッファ20に空きがあるかないかを判定する(ステップS401)。
セグメント要求部21は、ステップS401において、受信バッファ20に空きがあると判定した場合(ステップS401:Y)、受信バッファ20に格納された最後部のセグメントを特定する。そして、セグメント要求部21は、当該最後部の次のセグメントのSG番号を特定し、当該SG番号を取得SG番号saに決定する(ステップS402)。
セグメント要求部21は、ステップS402にて決定した切替操作後の動画における取得SG番号saのセグメント(新たな動画の切替後セグメント)を取得するためのSG要求(sa)を生成する。そして、セグメント要求部21は、当該SG要求(sa)を通信インターフェース10に出力する(ステップS403)。これにより、SG要求(sa)はサーバ2へ送信され、サーバ2から切替操作後の動画における取得SG番号saのセグメントが送信される。セグメント要求部21は、取得SG番号saを格納処理部22に出力する。
格納処理部22は、通信インターフェース10から切替操作後の動画における取得SG番号saのセグメントを入力し、当該セグメントを受信バッファ20の空き領域に追加する(ステップS404)。これにより、受信バッファ20には、切替操作後の新たな動画が格納される。
一方、セグメント要求部21は、ステップS401において、受信バッファ20に空きがないと判定した場合(ステップS401:N)、受信バッファ20に切替操作前の動画のセグメント(再生中の動画の切替前セグメント)が格納されているか否かを判定する(ステップS405)。
セグメント要求部21は、ステップS405において、受信バッファ20に切替操作前の動画のセグメントが格納されていると判定した場合(ステップS405:Y)、受信バッファ20に格納された切替操作前の動画のセグメントのうち最後部のセグメントを特定する。そして、セグメント要求部21は、当該セグメントのSG番号を特定し、当該SG番号を取得SG番号sbに決定する(ステップS406)。
セグメント要求部21は、ステップS406にて決定した切替操作後の動画における取得SG番号sbのセグメントを取得するためのSG要求(sb)を生成し、当該SG要求(sb)を通信インターフェース10に出力する(ステップS407)。これにより、SG要求(sb)はサーバ2へ送信され、サーバ2から切替操作後の動画における取得SG番号sbのセグメントが送信される。セグメント要求部21は、取得SG番号sbを格納処理部22に出力する。
格納処理部22は、通信インターフェース10から切替操作後の動画における取得SG番号sbのセグメントを入力し、当該セグメントを、受信バッファ20に格納された切替操作前の動画における取得SG番号sbのセグメントの領域に上書きする(ステップS408)。これにより、受信バッファ20には、切替操作後の新たな動画が切替操作前の動画の領域に格納される。
一方、セグメント要求部21は、ステップS405において、受信バッファ20に切替操作前の動画のセグメントが格納されていないと判定した場合(ステップS405:N)、当該動画切替時のセグメント取得処理を終了する。これにより、図2のステップS203における通常時のセグメント取得処理へ移行する。
このように、ユーザによる動画の切替操作が行われると、動画切替時のセグメント取得処理が行われる。サーバ2から取得された切替操作後の動画のセグメントは、受信バッファ20に空きがある場合、最前領域(動画デコーダ14により読み出されるセグメントの領域)から最後領域(セグメントが格納されることで受信バッファ20が満杯となる当該セグメントの領域)へ向けて、その空きが埋まるように追加される。また、切替操作後の動画のセグメントは、受信バッファ20に空きがなく、切替操作前の動画が格納されている場合、最後領域から最前領域へ向けて、切替操作前の動画が格納された最後部(最後領域側の部分)から最前部(最前領域側の部分)まで順番に上書きされる。
〔切替操作時の動作例〕
次に、切替操作時の動作例について説明する。図7は、本発明の実施形態において、ケース1の場合の動画Aから動画Bへの切替操作に伴う受信バッファ20に格納されたセグメントの変化、及び動画Bが切替再生されるタイミングを説明する図である。
横軸は再生時刻(秒)を示し、縦軸は受信バッファ時間(受信バッファ20に格納されたセグメントの動画時間)(秒)を示す。ケース1の条件、受信バッファ20からのセグメントの読み出し動作、受信バッファ20への格納動作、サーバ2からの取得動作等は、図5にて説明したとおりである。
図7を参照して、再生時刻4秒及び8秒のタイミングにおける動作は、図5と同様である。
再生時刻12秒のタイミングにおいて、ユーザにより動画Aから動画Bへの切替操作が行われる。このタイミングと同時に、動画デコーダ14により受信バッファ20から動画Aのs03のセグメントが読み出され再生され、s04〜s06のセグメントがシフトして、受信バッファ20には1セグメント分の空きが生じるものとする。切替操作に伴い、動画切替要求がセグメント要求部21に入力され、動画切替時のセグメント取得処理が開始する。
セグメント要求部21は、受信バッファ20に空きがあると判定し、最後部のセグメントのSG番号が06であるため、その次のSG番号07を取得SG番号sa=07に決定する。そして、セグメント要求部21は、切替操作後の動画Bにおける取得SG番号sa=07のセグメントを取得するためのSG要求(sa=07)を出力する。このSG要求(sa=07)は、サーバ2へ送信される。
そうすると、切替操作後の動画Bにおけるs07のセグメントがサーバ2から送信され、ユーザ端末1はこれを取得する。格納処理部22は、切替操作後の動画Bにおけるs07のセグメントを受信バッファ20に追加する。
これにより、受信バッファ20は、切替操作前の動画Aにおけるs04〜s06のセグメント、及び切替操作後の動画Bにおけるs07のセグメントが格納された状態となる(再生時刻t1のタイミングを参照)。
そして、セグメント要求部21は、受信バッファ20に空きがなく、切替操作前の動画Aのセグメントが格納されていると判定する。セグメント要求部21は、切替操作前の動画Aのセグメントのうち最後部のセグメントのSG番号06を取得SG番号sb=06に決定する。そして、セグメント要求部21は、切替後の動画Bにおける取得SG番号sb=06のセグメントを取得するためのSG要求(sb=06)を出力する。このSG要求(sb=06)は、サーバ2へ送信される。
そうすると、切替操作後の動画Bにおけるs06のセグメントがサーバ2から送信され、ユーザ端末1はこれを取得する。格納処理部22は、切替操作後の動画Bにおけるs06のセグメントを、受信バッファ20に格納された切替操作前の動画Aにおける取得SG番号sb=06のセグメントの領域に上書きする。
これにより、受信バッファ20は、切替操作前の動画Aにおけるs04,s05のセグメント、及び切替操作後の動画Bにおけるs06,s07のセグメントが格納された状態となる(再生時刻t2のタイミングを参照)。
同様にして、セグメント要求部21は、切替操作後の動画Bにおける取得SG番号sb=05のセグメントを取得するためのSG要求(sb=05)を出力する。そして、格納処理部22は、切替操作後の動画Bにおけるs05のセグメントを、受信バッファ20に格納された切替操作前の動画Aにおけるs05のセグメントの領域に上書きする。
セグメント要求部21は、切替操作後の動画Bにおける取得SG番号sb=04のセグメントを取得するためのSG要求(sb=04)を出力する。そして、格納処理部22は、切替操作後の動画Bにおけるs04のセグメントを、受信バッファ20に格納された切替操作前の動画Aにおけるs04のセグメントの領域に上書きする。
これにより、受信バッファ20は、切替操作後の動画Bにおけるs04〜s07のセグメントが格納された状態となる(再生時刻t3のタイミングを参照)。
再生時刻16秒のタイミングにおいて、動画Bのs04のセグメントの読み出し及び再生が行われ(枠で囲まれたs04)、動画Bのs08のセグメントの取得が行われる。これにより、動画Aの再生が終了し、動画Bの再生に切り替わり、これ以降は動画Bの再生が継続する。つまり、再生時刻16秒のタイミングで切替再生が行われることとなる。
このように、本発明の実施形態では、切替操作が行われると、受信バッファ20に空きがある場合、切替操作後の動画Bのセグメントは受信バッファ20に追加される。一方、受信バッファ20に空きがなく、かつ切替操作前の動画Aが格納されている場合、新たな動画Bのセグメントは、切替操作前の動画Aの最後部の領域に上書きされる。そして、受信バッファ20に空きがなく、かつ切替操作前の動画Aが格納されていない場合、通常時のセグメント取得処理が行われる。
図7に示したように、動画Aから動画Bへの切替時間は、4秒(16−12=4)であり、図5に示した切替時間16秒及び図6に示した切替時間8秒よりも短い。これにより、切替操作に伴う動画の切替時間を短縮することができる。
(動画Bのs04の取得が遅れた場合)
図7に示した例は、ケース1の条件である回線スループットが4Mビット/秒に維持された場合を示している。回線スループットが4Mビット/秒に維持されることにより、動画Bのs04のセグメントが受信バッファ20に上書きされた直後に、動画デコーダ14により、受信バッファ20から動画Bのs04のセグメントが読み出され再生される。このため、切替再生のタイミングは再生時刻16秒となる。
ここで、サーバ2から動画Bのs04のセグメントが送信されているときに、回線スループットが4Mビット/秒未満となった場合を想定する。この場合、動画Bのs04のセグメントの上書き完了時刻は、再生時刻16秒よりも遅れてしまい、再生時刻16秒のタイミングにおいて、動画Bのs04のセグメントを再生することができない。動画Aから動画Bへの切替再生のタイミングは、再生時刻16秒よりも遅れることとなる。
図8は、図7において、動画Bのs04のセグメントの取得が遅れた場合を説明する図である。回線スループットが4Mビット/秒未満となったため(点線αを参照)、動画Aのs03のセグメントの再生が完了する再生時刻16秒のタイミングにおいて、動画Bのs04のセグメントの上書きが完了していない。動画デコーダ14は、受信バッファ20から動画Bのs04のセグメントを読み出して再生することができない。
このため、再生時刻16秒のタイミングにおいて、動画Aのs04のセグメントの読み出し及び再生が行われ、動画Bのs08のセグメントの取得が行われる。これにより、受信バッファ20は、動画Bのs05〜s08のセグメントが格納された状態となる。
そして、再生時刻20秒のタイミングにおいて、動画Bのs05のセグメントの読み出し及び再生が行われる(枠で囲まれたs05)。これにより、動画Aの再生が終了し、動画Bの再生に切り替わり、これ以降は動画Bの再生が継続する。つまり、図7に示した再生時刻16秒よりも遅れた再生時刻20秒のタイミングで、切替再生が行われることとなる。
前述のとおり、図6に示した特願2019−12836号公報記載の発明の例では、切替操作時に回線スループットが低下すると、受信バッファ20に格納されたセグメントの数が低下する。また、切り替え前後の動画A,Bが交互に再生されて乱れるという不体裁が発生する可能性がある。
これに対し、本発明の実施形態では、受信バッファ20に空きがある場合に、動画Bのセグメントは、受信バッファ20の最前領域から最後領域へ向けてその空きが埋まるように追加される。また、受信バッファ20に空きがなく、動画Aが格納されている場合に、動画Bのセグメントは、動画Aの最後部から最前部へ向けて順番に上書きされる。このため、切替操作時に回線スループットが低下した場合であっても、受信バッファ20は、動画Bのセグメントが連続した領域に格納された状態となる。
したがって、本発明の実施形態では、受信バッファ20に格納されたセグメントの数の低下を抑えることができ、動画A,Bが交互に再生されて乱れるという不体裁の発生を防止することができる。
〔切替操作時の他の動作例〕
次に、切替操作時の他の動作例について説明する。図9は、従来技術において、ケース2の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。図10は、特願2019−12836号公報記載の発明において、ケース2の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。図11は、本発明の実施形態において、ケース2の場合のセグメントの変化及び動画Bの切替再生タイミングを説明する図である。
図9、図10及び図11において、横軸は再生時刻(秒)を示し、縦軸は受信バッファ時間(秒)を示す。細い実線で囲まれたセグメントは、動画Aのセグメントの動画データを示し、太い実線で囲まれたセグメントは、動画Bのセグメントの動画データを示す。
ケース2は、1セグメント分の動画時間を4秒、受信バッファ時間を32秒、動画ビットレートを1Mビット/秒、回線スループットを4Mビット/秒の条件を示している。図5〜図8に示したケース1とこのケース2とを比較すると、受信バッファ時間が異なり、その他の条件は同じである。ケース1の受信バッファ時間は16秒であるのに対し、ケース2の受信バッファ時間は32秒である。
再生時刻0秒からセグメントの取得が開始され、セグメントが受信バッファ時間32秒分取得されたときに、動画デコーダ14による再生が開始される。動画デコーダ14が動画を再生する際には、1セグメント分の動画データが受信バッファから瞬時に読み出される。
ケース2の条件から、ケース1の場合と同様に、サーバ2から1セグメント分の動画取得時間は、4秒×(1Mビット/秒)/(4Mビット/秒)=1秒となる。動画再生のシナリオは、再生時刻16秒のタイミングで、動画Aから動画Bへの切替操作が行われるものとする。
図9を参照して、従来技術では、切替操作が行われると、受信バッファ20に格納されている動画Aの全てのセグメントの再生が完了した後に、動画Bの再生が行われる。
このため、従来技術の場合、動画Aから動画Bへの切替再生のタイミングは、再生時刻48秒となり、動画Aから動画Bへの切替時間は、32秒(48−16=32)となる。
また、図10を参照して、特願2019−12836号公報記載の発明では、切替操作が行われると、ダウンロード予測時間に基づいて動画Bの上書領域(上書きするセグメント番号)が決定され、動画Bがその上書領域から上書きされる。
このため、特願2019−12836号公報記載の発明の場合、動画Aから動画Bへの切替再生のタイミングは、再生時刻24秒となる。そして、動画Aから動画Bへの切替時間は8秒(24−16=8)となり、図9に示した従来技術の場合の切替時間32秒よりも短い。
また、図11を参照して、本発明の実施形態では、切替操作が行われると、受信バッファ20に空きがある場合、動画Bのセグメントは受信バッファ20に追加される。一方、受信バッファ20に空きがなく、かつ動画Aが格納されている場合、動画Bのセグメントは、動画Aの最後部の領域に上書きされる。
このため、本発明の実施形態の場合、動画Aから動画Bへの切替再生のタイミングは、再生時刻24秒となり、動画Aから動画Bへの切替時間は8秒(24−16=8)となる。これは、図10に示した特願2019−12836号公報記載の発明の場合と同じである。
しかしながら、前述のとおり、切替操作時に回線スループットが低下した場合、本発明の実施形態は、特願2019−12836号公報記載の発明よりも有効に機能する。すなわち、特願2019−12836号公報記載の発明では、受信バッファ20に格納されたセグメントの数が低下し、動画A,Bが交互に再生されて乱れるという不体裁が発生する。しかし、本発明の実施形態では、受信バッファ20に格納されたセグメントの数の低下を抑えることができ、不体裁の発生を防止することができる。
以上のように、本発明の実施形態のユーザ端末1によれば、受信バッファ管理部13のセグメント要求部21は、ユーザにより切替操作に伴う動画切替要求を入力し、受信バッファ20に空きがあると判定した場合、受信バッファ20に格納された最後部の次のSG番号を取得SG番号saに決定し、SG要求(sa)を出力する。SG要求(sa)はサーバ2へ送信され、サーバ2から切替操作後の動画Bにおける取得SG番号saのセグメントが送信される。
受信バッファ管理部13の格納処理部22は、切替操作後の動画Bにおける取得SG番号saのセグメントを受信バッファ20に追加する。
セグメント要求部21は、受信バッファ20に空きがなく、切替操作前の動画Aのセグメントが格納されていると判定した場合、受信バッファ20に格納された切替操作前の動画Aのセグメントのうち最後部のセグメントのSG番号を取得SG番号sbに決定し、SG要求(sb)を出力する。SG要求(sb)はサーバ2へ送信され、サーバ2から切替操作後の動画Bにおける取得SG番号sbのセグメントが送信される。
格納処理部22は、切替操作後の動画Bにおける取得SG番号sbのセグメントを、受信バッファ20に格納された切替操作前の動画Aにおける取得SG番号sbのセグメントの領域に上書きする。
セグメント要求部21は、受信バッファ20に切替操作前の動画Aのセグメントが格納されていないと判定した場合、通常時のセグメント取得処理へ移行する。
これにより、切替操作時の受信バッファ20には、動画Bのセグメントが追加または上書きされるため、受信バッファ20に格納されたセグメントの数の低下を抑えることができると共に、動画Bが連続して格納されることとなる。
したがって、動画Aを視聴しているユーザが切替操作を行ったときに、新たな動画Bの視聴開始までの待ち時間を短縮することができると共に、動画A,Bが交互に再生されて乱れるという不体裁の発生を防止し、一層安定した再生を実現することができる。
以上、実施形態を挙げて本発明を説明したが、本発明は前記実施形態に限定されるものではなく、その技術思想を逸脱しない範囲で種々変形可能である。例えば、前記実施形態では、セグメントを再生する順番を示すSG番号を用いてセグメントの位置を決定し、セグメントを取得する等の処理を行うようにしたが、SG番号の代わりに、セグメントの先頭を再生する時刻を示すタイムスタンプを用いるようにしてもよい。
尚、タイプスタンプはセグメント番号から以下の式にて求められる。タイムスタンプをTS、タイムスタンプの初期値をTS0、セグメント番号をSG、セグメント番号の初期値をSG0、セグメント長(セグメントの時間長)をSGTとする。
[式1]
TS=(SG−SG0)×SGT+TS0 ・・・(1)
具体的には、端末装置1に備えた受信バッファ管理部13のセグメント要求部21は、動画切替要求を入力し、受信バッファ20に空きがあると判定した場合、受信バッファ20に格納された最後部のセグメントのタイムスタンプを特定する。そして、セグメント要求部21は、特定したタイムスタンプにセグメント長SGTを加算することで、その次のセグメント(空き領域に格納されるべきセグメント)のタイムスタンプを求める。
セグメント要求部21は、切替操作後の動画Bにおける加算結果のタイムスタンプのセグメントを取得するためのSG要求をサーバ2へ出力する。これにより、サーバ2から端末装置1へ、当該SG要求に対応するセグメントが送信される。
格納処理部22は、受信した当該SG要求に対応するセグメント、すなわち切替操作後の動画Bにおける前記タイムスタンプのセグメントを受信バッファ20に追加する。
セグメント要求部21は、受信バッファ20に空きがなく、切替操作前の動画Aのセグメントが格納されていると判定した場合、受信バッファ20に格納された切替操作前の動画Aのセグメントのうち最後部のセグメントのタイムスタンプを特定する。そして、セグメント要求部21は、切替操作後の動画Bにおける特定したタイムスタンプのセグメントを取得するためのSG要求をサーバ2へ出力する。これにより、サーバ2から端末装置1へ、当該SG要求に対応するセグメントが送信される。
格納処理部22は、受信した当該SG要求に対応するセグメント、すなわち切替操作後の動画Bにおける前記タイムスタンプのセグメントを、受信バッファ20に格納された切替操作前の動画Aにおける前記タイムスタンプのセグメントの領域に上書きする。
尚、本発明の実施形態によるユーザ端末1のハードウェア構成としては、通常のコンピュータを使用することができる。ユーザ端末1は、CPU、RAM等の揮発性の記憶媒体、ROM等の不揮発性の記憶媒体、及びインターフェース等を備えたコンピュータによって構成される。
ユーザ端末1に備えた通信インターフェース10、OS11、WEBブラウザ12、受信バッファ管理部13、動画デコーダ14及び表示部15の各機能は、これらの機能を記述したプログラムをCPUに実行させることによりそれぞれ実現される。また、受信バッファ管理部13について、受信バッファ20、セグメント要求部21及び格納処理部22の各機能は、これらの機能を記述したプログラムをCPUに実行させることによりそれぞれ実現される。
これらのプログラムは、前記記憶媒体に格納されており、CPUに読み出されて実行される。また、これらのプログラムは、磁気ディスク(フロッピー(登録商標)ディスク、ハードディスク等)、光ディスク(CD−ROM、DVD等)、半導体メモリ等の記憶媒体に格納して頒布することもでき、ネットワークを介して送受信することもできる。
1 ユーザ端末
2 サーバ
3 インターネット
4 ストレージ
10 通信インターフェース
11 OS(オペレーティングシステム)
12 WEBブラウザ
13 受信バッファ管理部
14 動画デコーダ
15 表示部
20 受信バッファ
21 セグメント要求部
22 格納処理部
A,B 動画
sa,sb 取得SG番号

Claims (3)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2020053275A JP7458848B2 (ja) 2020-03-24 2020-03-24 ユーザ端末及びプログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2020053275A JP7458848B2 (ja) 2020-03-24 2020-03-24 ユーザ端末及びプログラム

Publications (2)

Publication Number Publication Date
JP2021153270A true JP2021153270A (ja) 2021-09-30
JP7458848B2 JP7458848B2 (ja) 2024-04-01

Family

ID=77886764

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020053275A Active JP7458848B2 (ja) 2020-03-24 2020-03-24 ユーザ端末及びプログラム

Country Status (1)

Country Link
JP (1) JP7458848B2 (ja)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6397341B2 (ja) 2015-01-23 2018-09-26 日本放送協会 受信装置、バッファ管理方法、及びプログラム
JP5973616B1 (ja) 2015-04-15 2016-08-23 西日本電信電話株式会社 受信端末及びその映像取得方法
JP6609468B2 (ja) 2015-12-07 2019-11-20 日本放送協会 受信装置、再生時刻制御方法、及びプログラム
WO2018139284A1 (ja) 2017-01-30 2018-08-02 ソニー株式会社 画像処理装置および方法、並びにプログラム
JP7195163B2 (ja) 2019-01-29 2022-12-23 日本放送協会 ユーザ端末及びプロブラム

Also Published As

Publication number Publication date
JP7458848B2 (ja) 2024-04-01

Similar Documents

Publication Publication Date Title
CN111586479B (zh) 一种由客户端设备执行的机器实现的方法以及可读介质
CN109714634B (zh) 一种直播数据流的解码同步方法、装置及设备
US9558282B2 (en) Playlists for real-time or near real-time streaming
JP4273165B2 (ja) コンテンツのストリーミングに使用するための改善された起動方法および装置
JP5201512B2 (ja) 家庭内で「ストリーミング」メディアを配信するハイブリッド方法
US7817551B2 (en) Data reception apparatus and data distribution system
US20070112973A1 (en) Pre-cached streaming content method and apparatus
KR20210135338A (ko) 피어 투 피어(Peer to peer, P2P) 네트워크에서 스트리밍 콘텐츠를 방송하는 방법
US8886765B2 (en) System and method for predicitive trick play using adaptive video streaming
US9680904B2 (en) Adaptive buffers for media players
US11997323B2 (en) Content delivery
TWI666928B (zh) 適應性位元率分發方式的內容分發之分發控制裝置及分發控制方法
US20120066338A1 (en) Recording variable-quality content stream
KR20220158275A (ko) 네트워크에서 스트리밍되는 콘텐츠를 클라이언트 디바이스의 플레이어에서 재생하기 위한 방법
WO2013185547A1 (zh) 一种缓存服务器的服务方法、缓存服务器及系统
EP3833034A1 (en) Contiguous streaming of media stream
KR102521753B1 (ko) 네트워크에서 스트리밍되는 콘텐츠를 클라이언트 디바이스의 플레이어에서 재생하기 위한 방법
CN114268830A (zh) 云导播同步方法、装置、设备及存储介质
JP7458848B2 (ja) ユーザ端末及びプログラム
JP5973616B1 (ja) 受信端末及びその映像取得方法
JP7162019B2 (ja) データストリーミング方法、データストリーミング装置、及びコンピュータプログラム
JP6397341B2 (ja) 受信装置、バッファ管理方法、及びプログラム
JP7195163B2 (ja) ユーザ端末及びプロブラム
JP2023161219A (ja) 送信装置、受信装置及びそれらのプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230201

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20240209

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240222

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240319

R150 Certificate of patent or registration of utility model

Ref document number: 7458848

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150