特許第6626696号(P6626696)IP Force 特許公報掲載プロジェクト 2015.5.11 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 日本放送協会の特許一覧
特許6626696受信装置、マニフェスト更新方法、及びプログラム
<>
  • 特許6626696-受信装置、マニフェスト更新方法、及びプログラム 図000002
  • 特許6626696-受信装置、マニフェスト更新方法、及びプログラム 図000003
  • 特許6626696-受信装置、マニフェスト更新方法、及びプログラム 図000004
  • 特許6626696-受信装置、マニフェスト更新方法、及びプログラム 図000005
  • 特許6626696-受信装置、マニフェスト更新方法、及びプログラム 図000006
  • 特許6626696-受信装置、マニフェスト更新方法、及びプログラム 図000007
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6626696
(24)【登録日】2019年12月6日
(45)【発行日】2019年12月25日
(54)【発明の名称】受信装置、マニフェスト更新方法、及びプログラム
(51)【国際特許分類】
   H04N 21/438 20110101AFI20191216BHJP
   G06F 13/00 20060101ALI20191216BHJP
【FI】
   H04N21/438
   G06F13/00 540A
【請求項の数】4
【全頁数】12
(21)【出願番号】特願2015-227890(P2015-227890)
(22)【出願日】2015年11月20日
(65)【公開番号】特開2017-98703(P2017-98703A)
(43)【公開日】2017年6月1日
【審査請求日】2018年10月1日
【権利譲渡・実施許諾】特許権者において、実施許諾の用意がある。
(73)【特許権者】
【識別番号】000004352
【氏名又は名称】日本放送協会
(74)【代理人】
【識別番号】100147485
【弁理士】
【氏名又は名称】杉村 憲司
(74)【代理人】
【識別番号】100161148
【弁理士】
【氏名又は名称】福尾 誠
(72)【発明者】
【氏名】西村 敏
(72)【発明者】
【氏名】松村 欣司
(72)【発明者】
【氏名】藤沢 寛
(72)【発明者】
【氏名】山本 正男
(72)【発明者】
【氏名】遠藤 洋介
【審査官】 板垣 有紀
(56)【参考文献】
【文献】 特表2013−505685(JP,A)
【文献】 特表2013−524618(JP,A)
【文献】 特表2013−535054(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04N 21/00 − 21/858
G06F 13/00
(57)【特許請求の範囲】
【請求項1】
ライブストリーミングを受信する受信装置であって、
マニフェストファイルを取得して更新するマニフェスト取得部と、
現在の再生時刻又は新たに指定された再生時刻を出力する再生制御部と、
前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するマニフェスト更新制御部と、
を備えることを特徴とする受信装置。
【請求項2】
前記マニフェスト取得部は、シーク動作時に前記更新周期が長期に設定されている場合には、最新のマニフェストファイルを取得し、
前記マニフェスト更新制御部は、前記最新のマニフェストファイルに基づき前記ライブ再生基準時刻を決定することを特徴とする、請求項1に記載の受信装置。
【請求項3】
ライブストリーミングを受信する受信装置におけるマニフェスト更新方法であって、
マニフェストファイルを取得して更新するステップと、
現在の再生時刻又は新たに指定された再生時刻を出力するステップと、
前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するステップと、
を含むことを特徴とするマニフェスト更新方法。
【請求項4】
コンピュータを、請求項1又は2に記載の受信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ライブストリーミングを受信する受信装置、マニフェスト更新方法、及びプログラムに関する。
【背景技術】
【0002】
近年インターネットにおいては、ストリーミングによる動画配信サービスが普及している。例えば、ユーザが要求したタイミングで、配信サーバより選択したコンテンツを受信するVOD(Video On Demand)型のサービスや、スポーツやイベントのライブストリーミングが行われている。これらに加え、編成に従って番組を次々と配信する放送型のライブストリーミングも今後普及していくものと考えられる。
【0003】
昨今のインターネットにおけるストリーミング動画配信では、専用のサーバと専用のプロトコルによるストリーミング配信方式から、汎用的なWebサーバによりHTTPプロトコルを用いてストリーミング配信する方式への移行が進んでおり、多くのデバイス向けの配信において主流となっている。このようなHTTPプロトコルによるストリーミング配信方式(アダプティブストリーミング)としては、ITベンダによる独自技術が普及している他、これらストリーミング方式の統一を意図した国際標準規格であるMPEG−DASH(ISO/IEC23009−1)が策定された。
【0004】
いずれの技術も基本的なコンセプトは同様であり、Webサーバには動画コンテンツを一つ又は複数の品質(画面サイズやビットレート)でエンコードしたストリームをそれぞれ数秒から数十秒程度のファイルに分割したもの(セグメント)と、それらの動画コンテンツの属性やURLを記述したマニフェストファイルを用意する。受信端末はマニフェストファイルに記述されたURLに従って次々とセグメントを受信し、1本の動画コンテンツにつなぎ合わせて再生する(例えば、非特許文献1参照)。
【0005】
図6にHTTPプロトコルによるストリーミング配信方式の概念を示す。図6では、ライブエンコーダでエンコードされたコンテンツが時間の進行に合わせて分割され、1〜6のセグメントが順次生成されている(例えば、非特許文献2参照)。マニフェストファイルも同様に、セグメントが生成されるのに合わせて内容が更新されている。一番左のマニフェストファイルには1〜3のセグメントのURLが登録されており、次のマニフェストファイルには2〜4のセグメントのURLが登録されているように、マニフェストファイルに登録されているセグメントのURLは、順次一定個数ずつスライドする。
【0006】
セグメント及びマニフェストファイルは、順次Webサーバに供給される。受信端末は、Webサーバからマニフェストファイルを受信し、マニフェストファイルに登録されているセグメントを順次HTTPプロトコルにより受信する。受信端末は、更新されたマニフェストファイルを受信し、新規に登録されたセグメントを受信する処理を繰り返すことにより、ライブストリーミングを受信することができる。
【0007】
さらに、マニフェストファイル更新の際に、時間的に過去のセグメントをマニフェストファイルから消去せずに、順次生成されたセグメントを追加していくことにより、ライブストリーミングでありながら、番組の冒頭に遡って再生したり、過去の任意の再生位置にシークして視聴したりすることを可能とするサービスも普及している。
【0008】
ライブストリーミングを継続的に視聴するためには、更新されたマニフェストファイルを適宜取得する必要がある。このようなマニフェストファイルの更新については、後続要求をサーバに送信し、応答として受信したプレイリストファイル(マニフェストファイル)が前回受信したプレイリストファイルと異なる場合には、第1の期間の後にプレイリストファイルに対する後続要求をサーバに送信し、異ならない場合は、第2の期間の後に後続要求をサーバに送信する方法が知られている(例えば、特許文献1参照)。この方法は常に最新のセグメントが記載されたマニフェストファイルを取得することを意図したものである。
【先行技術文献】
【特許文献】
【0009】
【特許文献1】特表2012−514276号公報
【非特許文献】
【0010】
【非特許文献1】“次世代動画配信技術「MPEG−DASH」技術概要と標準化・関連技術動向”、映像情報メディア学会誌、Vol.67,No.2、2013、p.109−115
【非特許文献2】RGB Networks,"Comparing Adaptive HTTP Streaming Technologies"2011年11月<URL: http://www.bogotobogo.com/VideoStreaming/Files/iis8/RGB#Adaptive#HTTP#Streaming#Comparison#1211-01.pdf>
【発明の概要】
【発明が解決しようとする課題】
【0011】
ユーザの視聴方法によっては、必ずしも最新のセグメントの情報を必要としない場合がある。例えば、番組冒頭に遡って視聴する場合や、最新のセグメントからある一定の遅延(例えば1時間)をもって視聴する場合などである。しかしながら、従来の手法ではそのような場合であっても高頻度でマニフェストファイルを更新していたため、マニフェストファイルの更新に伴うネットワークや配信サーバの負荷が大きかった。
【0012】
かかる事情に鑑みてなされた本発明の目的は、ライブストリーミングにおいて、マニフェストファイルの更新負荷を軽減することを可能とするストリーミング受信装置、及びマニフェスト更新方法を提供することにある。
【課題を解決するための手段】
【0013】
上記課題を解決するため、本発明に係る受信装置は、ライブストリーミングを受信する受信装置であって、マニフェストファイルを取得して更新するマニフェスト取得部と、現在の再生時刻又は新たに指定された再生時刻を出力する再生制御部と、前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するマニフェスト更新制御部と、を備えることを特徴とする。
【0014】
さらに、本発明に係る受信装置において、前記マニフェスト取得部は、シーク動作時に前記更新周期が長期に設定されている場合には、最新のマニフェストファイルを取得し、前記マニフェスト更新制御部は、前記最新のマニフェストファイルに基づき前記ライブ再生基準時刻を決定することを特徴とする。
【0015】
また、上記課題を解決するため、本発明に係るマニフェスト更新方法は、ライブストリーミングを受信する受信装置におけるマニフェスト更新方法であって、マニフェストファイルを取得して更新するステップと、現在の再生時刻又は新たに指定された再生時刻を出力するステップと、前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するステップと、を含むことを特徴とする。
【0016】
また、上記課題を解決するため、本発明に係るプログラムは、コンピュータを、上記受信装置として機能させることを特徴とする。
【発明の効果】
【0017】
本発明によれば、必ずしも最新のセグメントの情報を必要としない視聴方法である場合には、マニフェストファイルの更新周期を長期に設定することにより、マニフェストファイルの更新に伴うネットワークや配信サーバの負荷を軽減することが可能となる。
【図面の簡単な説明】
【0018】
図1】本発明の一実施形態に係る受信装置の構成例を示す図である。
図2】マニフェストファイルの一例(抜粋)を示す図である。
図3】本発明の一実施形態に係る受信装置のアプリケーション起動から再生開始までの動作を示すフローチャートである。
図4】本発明の一実施形態に係る受信装置の再生中の動作を示すフローチャートである。
図5】本発明の一実施形態に係る受信装置のシーク動作について示すフローチャートである。
図6】HTTPプロトコルによるストリーミング配信方式の概念を示す図である。
【発明を実施するための形態】
【0019】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【0020】
まず、配信サーバに用意されるマニフェストファイルについて説明する。本実施形態では一例としてマニフェストファイルをMPEG−DASH(ISO/IEC23009−1)のMPD(Media Presentation Description)形式とする。
【0021】
図2にマニフェストファイルの一例(抜粋)を示す。MPD形式ではPeriod,AdaptationSet,Representationの順に階層構造となっている。
【0022】
Periodは、番組を時間方向に(一つ又は複数に)区切った一区画を示している。Periodは一つ以上のAdaptationSetから構成される。図2の例ではAdaptationSetは一つである。
【0023】
AdaptationSetは、メディアのコンポーネント(映像、音声、テキスト等)の情報を示しており、同じメディアでパラメータ(ビットレートや画面サイズ、音声のチャンネル数など)の異なる複数のコンポーネントを含むことができる。図2の例ではコンポーネントは一つである。
【0024】
Representationは、AdaptationSetに含まれるそれぞれのメディアのコンポーネントの情報を示しており、一つ以上のセグメントで構成される。
【0025】
また、AdaptationSetに含まれるSegmentTemplateは、セグメントのURLのテンプレートの情報を示している。また、SegmentTimelineは、このMPDファイルに含まれるセグメント毎の開始時刻と継続時間を対応付けたリストを示している。具体的には、図2の6〜12行目の<S>タグがセグメントの時刻情報を示しており、tの値がセグメントの再生開始時刻、dの値がセグメントの継続時間を示している。AdaptationSetのtimescale(90000)をもとに、開始時刻及び継続時間は以下のように算出される。これより、このMPDファイルには0秒から60.06秒までのセグメントが存在しており、各セグメントの継続時間が2.002秒であることがわかる。
6行目:開始時刻=t/timescale=0、継続時間=d/timescale=2.002、
7行目:開始時刻=t/timescale=2.002、継続時間=d/timescale=2.002、
8行目:開始時刻=t/timescale=4.004、継続時間=d/timescale=2.002、
12行目:開始時刻=t/timescale=58.058、継続時間=d/timescale=2.002
【0026】
以上より、ある再生時刻のセグメントのURLは、当該再生時刻を含む<S>タグを抽出し、該抽出した<S>タグのtで、4行目のmediaの値から抽出したテンプレート”live#v1#$Time$.mp4”の$Time$を差し替えることにより取得することができる。
【0027】
minimumUpdatePeriodは、マニフェストファイルを取得してから次のマニフェストファイルを要求するまでの最小遅延時間を示しており、受信装置のマニフェスト更新に対する指標を与えるものである。図2の例では、minimumUpdatePeriodは2秒である。
【0028】
suggestedPresentationDelayは、現在時刻からの固定遅延時間の推奨値を表している。つまりは、MPDファイルに存在する最新のセグメントからsuggestedPresentationDelay秒だけ遡った再生時刻のセグメントから再生することが推奨されていることを示すものである。図2の例では、suggestedPresentationDelayは20秒である。
【0029】
このマニフェストファイルは、順次生成されるデータストリームを分割した複数のセグメントと、該分割されたセグメントのうち新たに生成されたセグメントの所在を示す情報を追加すると共に、有効期限切れとなったセグメントの所在を示す情報を削除することで更新される。
【0030】
(受信装置の構成)
次に、本発明の一実施形態に係る受信装置の構成例について、図1を参照して説明する。受信装置1と配信サーバ2はインターネットを介して接続される。受信装置1は、配信サーバ2から複数のセグメントにより構成されるコンテンツをセグメントごとに受信し、ストリーミング再生を行う。
【0031】
配信サーバ2は、受信装置1によって指定されたURLのマニフェストファイルやセグメントを配信するサーバであり、例えば一般的なWebサーバとすることができる。
【0032】
受信装置1は、マニフェスト取得部11と、マニフェスト更新制御部12と、セグメント取得部13と、バッファ14と、再生・表示部15と、再生制御部16と、再生制御ユーザI/F17と、通信I/F18とを備え、ライブストリーミングを受信する。
【0033】
マニフェスト取得部11は、マニフェスト更新制御部12の指示により、配信サーバ2から所望のコンテンツのマニフェストファイルを取得して更新し、マニフェスト更新制御部12に出力する。
【0034】
マニフェスト更新制御部12は、マニフェスト取得部11から入力されたマニフェストファイルをもとに、再生時刻とセグメントのURLを対応付けたセグメントURLリストを生成し、セグメント取得部13及び再生制御部16に出力する。
【0035】
また、マニフェスト更新制御部12は、マニフェストファイルに記載されたセグメントの時刻情報に基づきライブ再生基準時刻を決定する。ここで、ライブ再生基準時刻とは、ライブ再生を安定に行うための基準時刻であり、セグメントURLリスト内の最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻のことをいう。ライブ再生基準時刻は、再生終了時刻から図2に示すsuggestedPresentationDelayに規定される時間だけ遡った再生時刻としてもよいし、別途設定した遅延時間分だけ遡った再生時刻としてもよい。
【0036】
また、マニフェスト更新制御部12は、ライブ再生基準時刻と、再生制御部16から入力された再生時刻(現在再生時刻又は再生要求時刻)とを比較し、再生時刻がライブ再生基準時刻よりも前である場合には、マニフェストファイルの更新周期を長期に設定し、再生時刻がライブ再生基準時刻以降である場合には、マニフェストファイルの更新周期を短期に設定する。以下の説明では、マニフェストファイルの更新周期を長期に設定するモードを長期モードと称し、マニフェストファイルの更新周期を短期に設定するモードを短期モードと称する。
【0037】
このようにすることで、マニフェストファイルを高頻度に更新する必要がある場合には短期モードが設定される。短期モードの更新周期は、図2に示すminimumUpdatePeriodに規定される基準値をそのまま用いてもよいし、当該基準値をもとに別途設定してもよい。一方、高頻度でマニフェストファイルを更新する必要がない場合には長期モードが設定されることになる。長期モードの更新周期は、短期モードの更新間隔の倍数(例えば10倍)としてもよいし、別途短期モードよりも長い値を設定してもよい。
【0038】
さらに、マニフェスト更新制御部12は、設定したマニフェスト更新周期をもとにマニフェストファイルを更新するか否かを判定し、更新すると決定した場合はマニフェスト更新指示をマニフェスト取得部11に指示する。
【0039】
セグメント取得部13は、マニフェスト更新制御部12から入力されたセグメントURLリスト、再生制御部16から入力された再生開始時刻情報、及びバッファ14に溜まっているセグメントの状態に基づき、取得すべきセグメントのURLを抽出し、該URLを含むリクエストを配信サーバ2に送信する。そして、該リクエストに対するレスポンスとしてセグメントを取得し、バッファ14に挿入する。
【0040】
再生・表示部15は、再生制御部16の再生指示をもとにバッファ14からセグメントを順次入力し、該入力したセグメントを再生・表示するとともに、現在の再生時刻である現在再生時刻を再生制御部16に出力する。
【0041】
再生制御部16は、現在の再生状態(再生中、停止中)、及び再生・表示部15から入力された現在再生時刻をマニフェスト更新制御部12及び再生制御ユーザI/F17に出力する。また、再生制御ユーザI/F17から再生開始、停止の命令を入力したら、再生・表示部15に再生開始・停止を指示する。
【0042】
さらに、再生制御部16は、再生制御ユーザI/F17からシーク(再生時刻変更)命令を入力すると、新たに指定された再生時刻である再生要求時刻を求め、マニフェスト更新制御部12に出力する。また、マニフェスト更新制御部12から入力されたライブ再生基準時刻及びセグメントURLリストに基づいて再生開始時刻を決定し、再生開始時刻を示す再生開始時刻情報をセグメント取得部13に出力する。
【0043】
再生制御ユーザI/F17は、ユーザの操作によって再生を制御する機能を有する。再生開始・停止ボタンを用意するとともに、コンテンツの開始時刻及び終了時刻を表示し、さらに再生制御部16から入力された現在再生時刻情報をもとに、現在の再生時刻をグラフィカルに表示してもよい。
【0044】
例えば、再生画面の下部にコンテンツの開始時刻を左端、終了時刻を右端とする横長の棒状で表示し、それと重なるようにつまみ状の操作部分を配置し、つまみ上の操作部分を再生が進むにつれて左端から右端に移動させることによって、ユーザは再生時間全体のうち今どの部分を再生しているのかを一目で把握することができる。また、このつまみをマウス等のユーザ操作によって動かすことにより、任意の再生位置を指定できるようにしてもよい。ユーザ操作によって、再生開始命令、停止命令、及びシーク命令による再生要求時刻を再生制御部16に出力する。
【0045】
(アプリケーション起動動作)
次に、受信装置1におけるアプリケーション起動から再生開始までの動作について、図3のフローチャートを参照して説明する。
【0046】
まず、ユーザ操作により視聴アプリケーションが起動されたら(ステップS001)、マニフェスト更新制御部12によりマニフェスト更新周期を短期モードに設定する(ステップS002)。続いて、マニフェスト取得部11により配信サーバ2から所望のコンテンツのマニフェストファイルを取得する(ステップS003)。
【0047】
続いて、マニフェスト更新制御部12により、取得したマニフェストファイルを解析し、セグメントURLリストを生成するとともにライブ再生基準時刻を設定する(ステップS004)。
【0048】
続いて、再生制御部16により、再生開始時刻をライブ再生基準時刻に設定する(ステップS005)。
【0049】
続いて、セグメント取得部13により、ステップS005で設定された再生開始時刻を含むセグメントのURLをセグメントURLリストから抽出し、該URLを含むリクエストを配信サーバ2に送信する(ステップS006)。そして、該リクエストに対するレスポンスとして受信したセグメントをバッファ14に挿入する(ステップS007)。
【0050】
続いて、再生・表示部15により、取得したセグメントの再生を開始する(ステップS008)。
【0051】
(再生動作)
次に、受信装置1における再生中の動作について、図4のフローチャートを参照して説明する。
【0052】
まず、マニフェスト更新制御部12により、マニフェスト更新周期が長期モードであり、かつ現在再生時刻がライブ再生基準時刻以降であるか否かを確認する(ステップS101)。現在再生時刻がライブ再生基準時刻以降である場合には(ステップS101−YES)、新しいセグメントを早期に取得する必要があるため、マニフェスト更新周期を短期モードに設定する(ステップS102)。現在再生時刻がライブ再生基準時刻より前である場合には(ステップS101−NO)、ステップS102を迂回する。
【0053】
続いて、マニフェスト更新制御部12により、前回マニフェストファイルを取得してからマニフェスト更新周期以上の時間が経過しているか否かを確認する(ステップS103)。ステップS103がNOの場合には、ステップS104,S015は迂回する。
【0054】
一方、ステップS103がYESの場合には、マニフェスト取得部11により、配信サーバ2から更新されたマニフェストファイルを取得する(ステップS104)。続いて、マニフェスト更新制御部12により、取得したマニフェストファイルを解析してセグメントURLリストを更新するとともにライブ再生基準時刻を更新する(ステップS105)。
【0055】
次に、バッファ14にバッファ規定値(例えば5秒)以上のセグメントが存在するか否かを確認する(ステップS106)。最初にマニフェストファイルを取得した段階ではまだバッファ14にセグメントが挿入されていないためである。ここで、バッファ規定値とは、安定した視聴を継続するために現在再生時刻よりも先んじて受信しておくバッファ14内のセグメントの再生時間尺である。ステップS106がYESの場合には、ステップS107,S018の処理は迂回する。
【0056】
一方、ステップS106がNOの場合には、セグメント取得部13により、バッファ14に溜まっている最後のセグメントに続くセグメントのURLをセグメントURLリストから抽出し、該URLを含むリクエストを配信サーバ2に送信する(ステップS107)。そして、該リクエストに対するレスポンスとして受信したセグメントをバッファ14に挿入する(ステップS108)。
【0057】
続いて、再生終了の指示がない場合には(ステップS109−NO)、ステップS101に戻り、再生終了の指示があった場合には(ステップS109−YES)、再生処理を終了する。
【0058】
(シーク動作)
次に、本発明における受信装置1のシーク動作について、図5のフローチャートを参照して説明する。
【0059】
まず、再生制御ユーザI/F17おいてユーザによりシーク操作が実行されたら、再生制御部16により再生要求時刻を取得する(ステップS201)。続いて、マニフェスト更新制御部12により、マニフェスト更新周期が長期モードであるか否かを確認する(ステップS202)。マニフェスト更新周期が短期モードである場合には(ステップS202−NO)、ステップS204,S205の処理を迂回する。
【0060】
一方、マニフェスト更新周期が長期モードである場合には(ステップS202−YES)、取得しているマニフェストファイルが最新でない可能性があるため、マニフェスト取得部11により、配信サーバ2から更新された最新のマニフェストファイルを取得する(ステップS204)。そして、マニフェスト更新制御部12により、取得したマニフェストファイルを解析し、セグメントの時刻情報に基づき、セグメントURLリスト及びライブ再生基準時刻を決定(更新)する(ステップS205)。
【0061】
続いて、マニフェスト更新制御部12により、再生要求時刻がライブ再生基準時刻よりも前であるか否かを確認する(ステップS203)。再生要求時刻がライブ再生基準時刻より前である場合には(ステップS203−YES)、マニフェスト更新周期を長期モードに設定する(ステップS206)。一方、再生要求時刻がライブ再生基準時刻以降である場合には(ステップS203−NO)、マニフェスト更新モードを短期モードに設定するとともに(ステップS207)、再生要求時刻をライブ再生基準時刻に設定する(ステップS208)。
【0062】
続いて、再生制御部16により、再生要求時刻を含むセグメントのURLがセグメントURLリストに存在するか否かを確認する(ステップS209)。ステップS209がYESである場合には、再生開始時刻を再生要求時刻に設定する(ステップS210)。一方、ステップS209がNOである場合には、再生開始時刻をセグメントURLリスト内で最も古いセグメントの再生時刻に設定する(ステップS211)。
【0063】
続いて、セグメント取得部13により、再生開始時刻を含むセグメントのURLをセグメントURLリストから抽出し、該URLを含むリクエストを配信サーバ2に送信する(ステップS212)。そして、該リクエストに対するレスポンスとして配信サーバ2からセグメントを受信し、バッファ14に挿入する(ステップS213)。
【0064】
続いて、再生・表示部15により、取得したセグメントの再生を開始する(ステップS214)。
【0065】
以上により、必ずしも最新のセグメントの情報を必要としない視聴方法である場合、すなわち現在再生時刻、又はシークによる再生要求時刻が、ライブ再生基準時刻よりも前である場合には、マニフェストファイルの更新周期を長くすることにより、マニフェストファイルの更新に伴うネットワークや配信サーバ2の負荷を軽減することが可能となる。
【0066】
なお、上述した受信装置1として機能させるためにコンピュータを好適に用いることができ、そのようなコンピュータは、受信装置1の各機能を実現する処理内容を記述したプログラムを該コンピュータの記憶部に格納しておき、該コンピュータのCPUによってこのプログラムを読み出して実行させることで実現することができる。なお、このプログラムは、コンピュータ読取り可能な記録媒体に記録可能である。
【0067】
上述の実施形態は代表的な例として説明したが、本発明の趣旨及び範囲内で、多くの変更及び置換ができることは当業者に明らかである。したがって、本発明は、上述の実施形態によって制限するものと解するべきではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。例えば、実施形態に記載の構成ブロック又は処理ステップについて、複数を1つに組み合わせたり、1つを複数に分割したりすることが可能である。
【符号の説明】
【0068】
1 受信装置
2 配信サーバ
11 マニフェスト取得部
12 マニフェスト更新制御部
13 セグメント取得部
14 バッファ
15 再生・表示部
16 再生制御部
17 再生制御ユーザI/F
18 通信I/F
図1
図2
図3
図4
図5
図6