(57)【特許請求の範囲】
【請求項１】
ライブストリーミングを受信する受信装置であって、
マニフェストファイルを取得して更新するマニフェスト取得部と、
現在の再生時刻又は新たに指定された再生時刻を出力する再生制御部と、
前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するマニフェスト更新制御部と、
を備えることを特徴とする受信装置。
【請求項２】
前記マニフェスト取得部は、シーク動作時に前記更新周期が長期に設定されている場合には、最新のマニフェストファイルを取得し、
前記マニフェスト更新制御部は、前記最新のマニフェストファイルに基づき前記ライブ再生基準時刻を決定することを特徴とする、請求項１に記載の受信装置。
【請求項３】
ライブストリーミングを受信する受信装置におけるマニフェスト更新方法であって、
マニフェストファイルを取得して更新するステップと、
現在の再生時刻又は新たに指定された再生時刻を出力するステップと、
前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するステップと、
を含むことを特徴とするマニフェスト更新方法。
【請求項４】
コンピュータを、請求項１又は２に記載の受信装置として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ライブストリーミングを受信する受信装置、マニフェスト更新方法、及びプログラムに関する。
【背景技術】
【０００２】
近年インターネットにおいては、ストリーミングによる動画配信サービスが普及している。例えば、ユーザが要求したタイミングで、配信サーバより選択したコンテンツを受信するＶＯＤ（Video On Demand）型のサービスや、スポーツやイベントのライブストリーミングが行われている。これらに加え、編成に従って番組を次々と配信する放送型のライブストリーミングも今後普及していくものと考えられる。
【０００３】
昨今のインターネットにおけるストリーミング動画配信では、専用のサーバと専用のプロトコルによるストリーミング配信方式から、汎用的なＷｅｂサーバによりＨＴＴＰプロトコルを用いてストリーミング配信する方式への移行が進んでおり、多くのデバイス向けの配信において主流となっている。このようなＨＴＴＰプロトコルによるストリーミング配信方式（アダプティブストリーミング）としては、ＩＴベンダによる独自技術が普及している他、これらストリーミング方式の統一を意図した国際標準規格であるＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）が策定された。
【０００４】
いずれの技術も基本的なコンセプトは同様であり、Ｗｅｂサーバには動画コンテンツを一つ又は複数の品質（画面サイズやビットレート）でエンコードしたストリームをそれぞれ数秒から数十秒程度のファイルに分割したもの（セグメント）と、それらの動画コンテンツの属性やＵＲＬを記述したマニフェストファイルを用意する。受信端末はマニフェストファイルに記述されたＵＲＬに従って次々とセグメントを受信し、１本の動画コンテンツにつなぎ合わせて再生する（例えば、非特許文献１参照）。
【０００５】
図６にＨＴＴＰプロトコルによるストリーミング配信方式の概念を示す。図６では、ライブエンコーダでエンコードされたコンテンツが時間の進行に合わせて分割され、１〜６のセグメントが順次生成されている（例えば、非特許文献２参照）。マニフェストファイルも同様に、セグメントが生成されるのに合わせて内容が更新されている。一番左のマニフェストファイルには１〜３のセグメントのＵＲＬが登録されており、次のマニフェストファイルには２〜４のセグメントのＵＲＬが登録されているように、マニフェストファイルに登録されているセグメントのＵＲＬは、順次一定個数ずつスライドする。
【０００６】
セグメント及びマニフェストファイルは、順次Ｗｅｂサーバに供給される。受信端末は、Ｗｅｂサーバからマニフェストファイルを受信し、マニフェストファイルに登録されているセグメントを順次ＨＴＴＰプロトコルにより受信する。受信端末は、更新されたマニフェストファイルを受信し、新規に登録されたセグメントを受信する処理を繰り返すことにより、ライブストリーミングを受信することができる。
【０００７】
さらに、マニフェストファイル更新の際に、時間的に過去のセグメントをマニフェストファイルから消去せずに、順次生成されたセグメントを追加していくことにより、ライブストリーミングでありながら、番組の冒頭に遡って再生したり、過去の任意の再生位置にシークして視聴したりすることを可能とするサービスも普及している。
【０００８】
ライブストリーミングを継続的に視聴するためには、更新されたマニフェストファイルを適宜取得する必要がある。このようなマニフェストファイルの更新については、後続要求をサーバに送信し、応答として受信したプレイリストファイル（マニフェストファイル）が前回受信したプレイリストファイルと異なる場合には、第１の期間の後にプレイリストファイルに対する後続要求をサーバに送信し、異ならない場合は、第２の期間の後に後続要求をサーバに送信する方法が知られている（例えば、特許文献１参照）。この方法は常に最新のセグメントが記載されたマニフェストファイルを取得することを意図したものである。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特表２０１２−５１４２７６号公報
【非特許文献】
【００１０】
【非特許文献１】“次世代動画配信技術「ＭＰＥＧ−ＤＡＳＨ」技術概要と標準化・関連技術動向”、映像情報メディア学会誌、Ｖｏｌ．６７，Ｎｏ．２、２０１３、ｐ．１０９−１１５
【非特許文献２】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>
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ユーザの視聴方法によっては、必ずしも最新のセグメントの情報を必要としない場合がある。例えば、番組冒頭に遡って視聴する場合や、最新のセグメントからある一定の遅延（例えば１時間）をもって視聴する場合などである。しかしながら、従来の手法ではそのような場合であっても高頻度でマニフェストファイルを更新していたため、マニフェストファイルの更新に伴うネットワークや配信サーバの負荷が大きかった。
【００１２】
かかる事情に鑑みてなされた本発明の目的は、ライブストリーミングにおいて、マニフェストファイルの更新負荷を軽減することを可能とするストリーミング受信装置、及びマニフェスト更新方法を提供することにある。
【課題を解決するための手段】
【００１３】
上記課題を解決するため、本発明に係る受信装置は、ライブストリーミングを受信する受信装置であって、マニフェストファイルを取得して更新するマニフェスト取得部と、現在の再生時刻又は新たに指定された再生時刻を出力する再生制御部と、前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するマニフェスト更新制御部と、を備えることを特徴とする。
【００１４】
さらに、本発明に係る受信装置において、前記マニフェスト取得部は、シーク動作時に前記更新周期が長期に設定されている場合には、最新のマニフェストファイルを取得し、前記マニフェスト更新制御部は、前記最新のマニフェストファイルに基づき前記ライブ再生基準時刻を決定することを特徴とする。
【００１５】
また、上記課題を解決するため、本発明に係るマニフェスト更新方法は、ライブストリーミングを受信する受信装置におけるマニフェスト更新方法であって、マニフェストファイルを取得して更新するステップと、現在の再生時刻又は新たに指定された再生時刻を出力するステップと、前記マニフェストファイルに記載された最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻であるライブ再生基準時刻を決定し、前記再生時刻が前記ライブ再生基準時刻よりも前である場合には、前記マニフェストファイルの更新周期を長期に設定し、前記再生時刻が前記ライブ再生基準時刻以降である場合には、前記マニフェストファイルの更新周期を短期に設定するステップと、を含むことを特徴とする。
【００１６】
また、上記課題を解決するため、本発明に係るプログラムは、コンピュータを、上記受信装置として機能させることを特徴とする。
【発明の効果】
【００１７】
本発明によれば、必ずしも最新のセグメントの情報を必要としない視聴方法である場合には、マニフェストファイルの更新周期を長期に設定することにより、マニフェストファイルの更新に伴うネットワークや配信サーバの負荷を軽減することが可能となる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施形態に係る受信装置の構成例を示す図である。
【図２】マニフェストファイルの一例（抜粋）を示す図である。
【図３】本発明の一実施形態に係る受信装置のアプリケーション起動から再生開始までの動作を示すフローチャートである。
【図４】本発明の一実施形態に係る受信装置の再生中の動作を示すフローチャートである。
【図５】本発明の一実施形態に係る受信装置のシーク動作について示すフローチャートである。
【図６】ＨＴＴＰプロトコルによるストリーミング配信方式の概念を示す図である。
【発明を実施するための形態】
【００１９】
以下、本発明の一実施形態について、図面を参照して詳細に説明する。
【００２０】
まず、配信サーバに用意されるマニフェストファイルについて説明する。本実施形態では一例としてマニフェストファイルをＭＰＥＧ−ＤＡＳＨ（ＩＳＯ／ＩＥＣ２３００９−１）のＭＰＤ（Media Presentation Description）形式とする。
【００２１】
図２にマニフェストファイルの一例（抜粋）を示す。ＭＰＤ形式ではPeriod，AdaptationSet，Representationの順に階層構造となっている。
【００２２】
Periodは、番組を時間方向に（一つ又は複数に）区切った一区画を示している。Periodは一つ以上のAdaptationSetから構成される。図２の例ではAdaptationSetは一つである。
【００２３】
AdaptationSetは、メディアのコンポーネント（映像、音声、テキスト等）の情報を示しており、同じメディアでパラメータ（ビットレートや画面サイズ、音声のチャンネル数など）の異なる複数のコンポーネントを含むことができる。図２の例ではコンポーネントは一つである。
【００２４】
Representationは、AdaptationSetに含まれるそれぞれのメディアのコンポーネントの情報を示しており、一つ以上のセグメントで構成される。
【００２５】
また、AdaptationSetに含まれるSegmentTemplateは、セグメントのＵＲＬのテンプレートの情報を示している。また、SegmentTimelineは、このＭＰＤファイルに含まれるセグメント毎の開始時刻と継続時間を対応付けたリストを示している。具体的には、図２の６〜１２行目の＜Ｓ＞タグがセグメントの時刻情報を示しており、ｔの値がセグメントの再生開始時刻、ｄの値がセグメントの継続時間を示している。AdaptationSetのtimescale（90000）をもとに、開始時刻及び継続時間は以下のように算出される。これより、このＭＰＤファイルには0秒から60.06秒までのセグメントが存在しており、各セグメントの継続時間が2.002秒であることがわかる。
６行目：開始時刻＝ｔ/timescale＝0、継続時間＝d/timescale＝2.002、
７行目：開始時刻＝ｔ/timescale＝2.002、継続時間＝d/timescale＝2.002、
８行目：開始時刻＝ｔ/timescale＝4.004、継続時間＝d/timescale＝2.002、
１２行目：開始時刻＝ｔ/timescale＝58.058、継続時間＝d/timescale＝2.002
【００２６】
以上より、ある再生時刻のセグメントのＵＲＬは、当該再生時刻を含む＜Ｓ＞タグを抽出し、該抽出した＜Ｓ＞タグのｔで、４行目のmediaの値から抽出したテンプレート”live#v1#$Time$.mp4”の$Time$を差し替えることにより取得することができる。
【００２７】
minimumUpdatePeriodは、マニフェストファイルを取得してから次のマニフェストファイルを要求するまでの最小遅延時間を示しており、受信装置のマニフェスト更新に対する指標を与えるものである。図２の例では、minimumUpdatePeriodは２秒である。
【００２８】
suggestedPresentationDelayは、現在時刻からの固定遅延時間の推奨値を表している。つまりは、ＭＰＤファイルに存在する最新のセグメントからsuggestedPresentationDelay秒だけ遡った再生時刻のセグメントから再生することが推奨されていることを示すものである。図２の例では、suggestedPresentationDelayは２０秒である。
【００２９】
このマニフェストファイルは、順次生成されるデータストリームを分割した複数のセグメントと、該分割されたセグメントのうち新たに生成されたセグメントの所在を示す情報を追加すると共に、有効期限切れとなったセグメントの所在を示す情報を削除することで更新される。
【００３０】
（受信装置の構成）
次に、本発明の一実施形態に係る受信装置の構成例について、図１を参照して説明する。受信装置１と配信サーバ２はインターネットを介して接続される。受信装置１は、配信サーバ２から複数のセグメントにより構成されるコンテンツをセグメントごとに受信し、ストリーミング再生を行う。
【００３１】
配信サーバ２は、受信装置１によって指定されたＵＲＬのマニフェストファイルやセグメントを配信するサーバであり、例えば一般的なＷｅｂサーバとすることができる。
【００３２】
受信装置１は、マニフェスト取得部１１と、マニフェスト更新制御部１２と、セグメント取得部１３と、バッファ１４と、再生・表示部１５と、再生制御部１６と、再生制御ユーザＩ／Ｆ１７と、通信Ｉ／Ｆ１８とを備え、ライブストリーミングを受信する。
【００３３】
マニフェスト取得部１１は、マニフェスト更新制御部１２の指示により、配信サーバ２から所望のコンテンツのマニフェストファイルを取得して更新し、マニフェスト更新制御部１２に出力する。
【００３４】
マニフェスト更新制御部１２は、マニフェスト取得部１１から入力されたマニフェストファイルをもとに、再生時刻とセグメントのＵＲＬを対応付けたセグメントＵＲＬリストを生成し、セグメント取得部１３及び再生制御部１６に出力する。
【００３５】
また、マニフェスト更新制御部１２は、マニフェストファイルに記載されたセグメントの時刻情報に基づきライブ再生基準時刻を決定する。ここで、ライブ再生基準時刻とは、ライブ再生を安定に行うための基準時刻であり、セグメントＵＲＬリスト内の最新のセグメントの再生終了時刻から一定の遅延時間分遡った再生時刻のことをいう。ライブ再生基準時刻は、再生終了時刻から図２に示すsuggestedPresentationDelayに規定される時間だけ遡った再生時刻としてもよいし、別途設定した遅延時間分だけ遡った再生時刻としてもよい。
【００３６】
また、マニフェスト更新制御部１２は、ライブ再生基準時刻と、再生制御部１６から入力された再生時刻（現在再生時刻又は再生要求時刻）とを比較し、再生時刻がライブ再生基準時刻よりも前である場合には、マニフェストファイルの更新周期を長期に設定し、再生時刻がライブ再生基準時刻以降である場合には、マニフェストファイルの更新周期を短期に設定する。以下の説明では、マニフェストファイルの更新周期を長期に設定するモードを長期モードと称し、マニフェストファイルの更新周期を短期に設定するモードを短期モードと称する。
【００３７】
このようにすることで、マニフェストファイルを高頻度に更新する必要がある場合には短期モードが設定される。短期モードの更新周期は、図２に示すminimumUpdatePeriodに規定される基準値をそのまま用いてもよいし、当該基準値をもとに別途設定してもよい。一方、高頻度でマニフェストファイルを更新する必要がない場合には長期モードが設定されることになる。長期モードの更新周期は、短期モードの更新間隔の倍数（例えば１０倍）としてもよいし、別途短期モードよりも長い値を設定してもよい。
【００３８】
さらに、マニフェスト更新制御部１２は、設定したマニフェスト更新周期をもとにマニフェストファイルを更新するか否かを判定し、更新すると決定した場合はマニフェスト更新指示をマニフェスト取得部１１に指示する。
【００３９】
セグメント取得部１３は、マニフェスト更新制御部１２から入力されたセグメントＵＲＬリスト、再生制御部１６から入力された再生開始時刻情報、及びバッファ１４に溜まっているセグメントの状態に基づき、取得すべきセグメントのＵＲＬを抽出し、該ＵＲＬを含むリクエストを配信サーバ２に送信する。そして、該リクエストに対するレスポンスとしてセグメントを取得し、バッファ１４に挿入する。
【００４０】
再生・表示部１５は、再生制御部１６の再生指示をもとにバッファ１４からセグメントを順次入力し、該入力したセグメントを再生・表示するとともに、現在の再生時刻である現在再生時刻を再生制御部１６に出力する。
【００４１】
再生制御部１６は、現在の再生状態（再生中、停止中）、及び再生・表示部１５から入力された現在再生時刻をマニフェスト更新制御部１２及び再生制御ユーザＩ／Ｆ１７に出力する。また、再生制御ユーザＩ／Ｆ１７から再生開始、停止の命令を入力したら、再生・表示部１５に再生開始・停止を指示する。
【００４２】
さらに、再生制御部１６は、再生制御ユーザＩ／Ｆ１７からシーク（再生時刻変更）命令を入力すると、新たに指定された再生時刻である再生要求時刻を求め、マニフェスト更新制御部１２に出力する。また、マニフェスト更新制御部１２から入力されたライブ再生基準時刻及びセグメントＵＲＬリストに基づいて再生開始時刻を決定し、再生開始時刻を示す再生開始時刻情報をセグメント取得部１３に出力する。
【００４３】
再生制御ユーザＩ／Ｆ１７は、ユーザの操作によって再生を制御する機能を有する。再生開始・停止ボタンを用意するとともに、コンテンツの開始時刻及び終了時刻を表示し、さらに再生制御部１６から入力された現在再生時刻情報をもとに、現在の再生時刻をグラフィカルに表示してもよい。
【００４４】
例えば、再生画面の下部にコンテンツの開始時刻を左端、終了時刻を右端とする横長の棒状で表示し、それと重なるようにつまみ状の操作部分を配置し、つまみ上の操作部分を再生が進むにつれて左端から右端に移動させることによって、ユーザは再生時間全体のうち今どの部分を再生しているのかを一目で把握することができる。また、このつまみをマウス等のユーザ操作によって動かすことにより、任意の再生位置を指定できるようにしてもよい。ユーザ操作によって、再生開始命令、停止命令、及びシーク命令による再生要求時刻を再生制御部１６に出力する。
【００４５】
（アプリケーション起動動作）
次に、受信装置１におけるアプリケーション起動から再生開始までの動作について、図３のフローチャートを参照して説明する。
【００４６】
まず、ユーザ操作により視聴アプリケーションが起動されたら（ステップＳ００１）、マニフェスト更新制御部１２によりマニフェスト更新周期を短期モードに設定する（ステップＳ００２）。続いて、マニフェスト取得部１１により配信サーバ２から所望のコンテンツのマニフェストファイルを取得する（ステップＳ００３）。
【００４７】
続いて、マニフェスト更新制御部１２により、取得したマニフェストファイルを解析し、セグメントＵＲＬリストを生成するとともにライブ再生基準時刻を設定する（ステップＳ００４）。
【００４８】
続いて、再生制御部１６により、再生開始時刻をライブ再生基準時刻に設定する（ステップＳ００５）。
【００４９】
続いて、セグメント取得部１３により、ステップＳ００５で設定された再生開始時刻を含むセグメントのＵＲＬをセグメントＵＲＬリストから抽出し、該ＵＲＬを含むリクエストを配信サーバ２に送信する（ステップＳ００６）。そして、該リクエストに対するレスポンスとして受信したセグメントをバッファ１４に挿入する（ステップＳ００７）。
【００５０】
続いて、再生・表示部１５により、取得したセグメントの再生を開始する（ステップＳ００８）。
【００５１】
（再生動作）
次に、受信装置１における再生中の動作について、図４のフローチャートを参照して説明する。
【００５２】
まず、マニフェスト更新制御部１２により、マニフェスト更新周期が長期モードであり、かつ現在再生時刻がライブ再生基準時刻以降であるか否かを確認する（ステップＳ１０１）。現在再生時刻がライブ再生基準時刻以降である場合には（ステップＳ１０１−ＹＥＳ）、新しいセグメントを早期に取得する必要があるため、マニフェスト更新周期を短期モードに設定する（ステップＳ１０２）。現在再生時刻がライブ再生基準時刻より前である場合には（ステップＳ１０１−ＮＯ）、ステップＳ１０２を迂回する。
【００５３】
続いて、マニフェスト更新制御部１２により、前回マニフェストファイルを取得してからマニフェスト更新周期以上の時間が経過しているか否かを確認する（ステップＳ１０３）。ステップＳ１０３がＮＯの場合には、ステップＳ１０４，Ｓ０１５は迂回する。
【００５４】
一方、ステップＳ１０３がＹＥＳの場合には、マニフェスト取得部１１により、配信サーバ２から更新されたマニフェストファイルを取得する（ステップＳ１０４）。続いて、マニフェスト更新制御部１２により、取得したマニフェストファイルを解析してセグメントＵＲＬリストを更新するとともにライブ再生基準時刻を更新する（ステップＳ１０５）。
【００５５】
次に、バッファ１４にバッファ規定値（例えば５秒）以上のセグメントが存在するか否かを確認する（ステップＳ１０６）。最初にマニフェストファイルを取得した段階ではまだバッファ１４にセグメントが挿入されていないためである。ここで、バッファ規定値とは、安定した視聴を継続するために現在再生時刻よりも先んじて受信しておくバッファ１４内のセグメントの再生時間尺である。ステップＳ１０６がＹＥＳの場合には、ステップＳ１０７，Ｓ０１８の処理は迂回する。
【００５６】
一方、ステップＳ１０６がＮＯの場合には、セグメント取得部１３により、バッファ１４に溜まっている最後のセグメントに続くセグメントのＵＲＬをセグメントＵＲＬリストから抽出し、該ＵＲＬを含むリクエストを配信サーバ２に送信する（ステップＳ１０７）。そして、該リクエストに対するレスポンスとして受信したセグメントをバッファ１４に挿入する（ステップＳ１０８）。
【００５７】
続いて、再生終了の指示がない場合には（ステップＳ１０９−ＮＯ）、ステップＳ１０１に戻り、再生終了の指示があった場合には（ステップＳ１０９−ＹＥＳ）、再生処理を終了する。
【００５８】
（シーク動作）
次に、本発明における受信装置１のシーク動作について、図５のフローチャートを参照して説明する。
【００５９】
まず、再生制御ユーザＩ／Ｆ１７おいてユーザによりシーク操作が実行されたら、再生制御部１６により再生要求時刻を取得する（ステップＳ２０１）。続いて、マニフェスト更新制御部１２により、マニフェスト更新周期が長期モードであるか否かを確認する（ステップＳ２０２）。マニフェスト更新周期が短期モードである場合には（ステップＳ２０２−ＮＯ）、ステップＳ２０４，Ｓ２０５の処理を迂回する。
【００６０】
一方、マニフェスト更新周期が長期モードである場合には（ステップＳ２０２−ＹＥＳ）、取得しているマニフェストファイルが最新でない可能性があるため、マニフェスト取得部１１により、配信サーバ２から更新された最新のマニフェストファイルを取得する（ステップＳ２０４）。そして、マニフェスト更新制御部１２により、取得したマニフェストファイルを解析し、セグメントの時刻情報に基づき、セグメントＵＲＬリスト及びライブ再生基準時刻を決定（更新）する（ステップＳ２０５）。
【００６１】
続いて、マニフェスト更新制御部１２により、再生要求時刻がライブ再生基準時刻よりも前であるか否かを確認する（ステップＳ２０３）。再生要求時刻がライブ再生基準時刻より前である場合には（ステップＳ２０３−ＹＥＳ）、マニフェスト更新周期を長期モードに設定する（ステップＳ２０６）。一方、再生要求時刻がライブ再生基準時刻以降である場合には（ステップＳ２０３−ＮＯ）、マニフェスト更新モードを短期モードに設定するとともに（ステップＳ２０７）、再生要求時刻をライブ再生基準時刻に設定する（ステップＳ２０８）。
【００６２】
続いて、再生制御部１６により、再生要求時刻を含むセグメントのＵＲＬがセグメントＵＲＬリストに存在するか否かを確認する（ステップＳ２０９）。ステップＳ２０９がＹＥＳである場合には、再生開始時刻を再生要求時刻に設定する（ステップＳ２１０）。一方、ステップＳ２０９がＮＯである場合には、再生開始時刻をセグメントＵＲＬリスト内で最も古いセグメントの再生時刻に設定する（ステップＳ２１１）。
【００６３】
続いて、セグメント取得部１３により、再生開始時刻を含むセグメントのＵＲＬをセグメントＵＲＬリストから抽出し、該ＵＲＬを含むリクエストを配信サーバ２に送信する（ステップＳ２１２）。そして、該リクエストに対するレスポンスとして配信サーバ２からセグメントを受信し、バッファ１４に挿入する（ステップＳ２１３）。
【００６４】
続いて、再生・表示部１５により、取得したセグメントの再生を開始する（ステップＳ２１４）。
【００６５】
以上により、必ずしも最新のセグメントの情報を必要としない視聴方法である場合、すなわち現在再生時刻、又はシークによる再生要求時刻が、ライブ再生基準時刻よりも前である場合には、マニフェストファイルの更新周期を長くすることにより、マニフェストファイルの更新に伴うネットワークや配信サーバ２の負荷を軽減することが可能となる。
【００６６】
なお、上述した受信装置１として機能させるためにコンピュータを好適に用いることができ、そのようなコンピュータは、受信装置１の各機能を実現する処理内容を記述したプログラムを該コンピュータの記憶部に格納しておき、該コンピュータのＣＰＵによってこのプログラムを読み出して実行させることで実現することができる。なお、このプログラムは、コンピュータ読取り可能な記録媒体に記録可能である。
【００６７】
上述の実施形態は代表的な例として説明したが、本発明の趣旨及び範囲内で、多くの変更及び置換ができることは当業者に明らかである。したがって、本発明は、上述の実施形態によって制限するものと解するべきではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。例えば、実施形態に記載の構成ブロック又は処理ステップについて、複数を１つに組み合わせたり、１つを複数に分割したりすることが可能である。
【符号の説明】
【００６８】
１    受信装置
２    配信サーバ
１１  マニフェスト取得部
１２  マニフェスト更新制御部
１３  セグメント取得部
１４  バッファ
１５  再生・表示部
１６  再生制御部
１７  再生制御ユーザＩ／Ｆ
１８  通信Ｉ／Ｆ
【図１】
0006626696.tif 000002
【図２】
0006626696.tif 000003
【図３】
0006626696.tif 000004
【図４】
0006626696.tif 000005
【図５】
0006626696.tif 000006
【図６】
0006626696.tif 000007