生成装置、配信サーバ、生成方法、再生装置、再生方法、再生システム、生成プログラム、再生プログラム、記録媒体およびデータ構造
【課題】再生装置が任意の再生位置でトリック再生することを可能にするＭＰＤであって従来よりも配信効率の良いＭＰＤを生成可能な生成装置を実現する。
【解決手段】
配信サーバ３００は、コンテンツのライブ配信中にそのコンテンツのＭＰＤをクライアント装置１００に定期的に配信する。配信サーバ３００は、過去の各ピリオドについてピリオドに属する各メディアセグメント（MS）のＵＲＬを含むＸＭＬファイルを生成するメタデータ作成部３２０を備える。メタデータ作成部３２０はＭＰＤも作成する。ＭＰＤには、コンテンツを構成する複数のMSのうち、過去の各ピリオドに属するMSについてはピリオドのidを含む、ＸＭＬファイルのファイル名が記載され、現在のピリオドについてはそのピリオドに属する各MSのURLが記載される。
【解決手段】
配信サーバ３００は、コンテンツのライブ配信中にそのコンテンツのＭＰＤをクライアント装置１００に定期的に配信する。配信サーバ３００は、過去の各ピリオドについてピリオドに属する各メディアセグメント（MS）のＵＲＬを含むＸＭＬファイルを生成するメタデータ作成部３２０を備える。メタデータ作成部３２０はＭＰＤも作成する。ＭＰＤには、コンテンツを構成する複数のMSのうち、過去の各ピリオドに属するMSについてはピリオドのidを含む、ＸＭＬファイルのファイル名が記載され、現在のピリオドについてはそのピリオドに属する各MSのURLが記載される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信サーバから取得したコンテンツデータを再生する再生装置および再生方法に関する。また、本発明は、コンテンツデータを再生するために再生装置が参照すべきメタデータを生成する生成装置および生成方法に関する。また、本発明は、そのような生成装置および再生装置を含む再生システムに関する。さらに、本発明は、そのような再生装置もしくは生成装置としてコンピュータを動作させる再生プログラムもしくは生成プログラム、並びに、そのような再生プログラムもしくは生成プログラムを記憶している記録媒体に関する。さらに、本発明は、再生装置がコンテンツデータを再生するために参照すべきメタデータのデータ構造に関する。
【背景技術】
【０００２】
近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等で構成されたＷＥＢページを見るだけでなく、動画コンテンツを鑑賞するユーザが増えてきている。
【０００３】
このような状況を踏まえ、例えば非特許文献１に記載の技術のような、動画コンテンツをストリーミング配信するための様々な技術が開発されているが、そのうちのひとつに、MPEG（Moving Picture Experts Group）にて現在標準化作業が進められているＤＡＳＨ(Dynamic Adaptive Streaming over HTTP)が挙げられる。
【０００４】
ＤＡＳＨでは、図１４に例示されているようなＭＰＤ（Media Presentation Description）データと、図１４のＭＰＤデータにおいてtsファイルとして例示されているメディアセグメントとの２つのフォーマットが規定されている。メディアセグメントは、動画コンテンツが時分割された、ＨＴＴＰ伝送の伝送単位である。また、ＭＰＤデータは、ストリーミング配信の制御メタデータであり、動画コンテンツがライブ配信されるコンテンツ（ライブコンテンツ）であるかＶＯＤコンテンツであるかを示す情報（図１４における属性「type」の属性値）を含んでいる。
【０００５】
また、ＭＰＤデータは、動画コンテンツの再生期間を区切った各ピリオドについて、動画コンテンツの配信開始時間を基準「０」とした場合のそのピリオドの開始時間を示す情報（図１４における属性「start」の属性値）とそのピリオドに属する各メディアセグメントのＵＲＬを示す情報（図１４における要素「BaseURL」の要素値および属性「sourceURL」の属性値）とを含んでいる。さらに、動画コンテンツがライブコンテンツである場合(属性「type」の属性値が“Live”である場合)には、ＭＰＤデータには配信サーバにおいて動画コンテンツのストリーミング配信が開始される時刻の情報（図１４における属性「availabilityStartTime」の属性値）が含まれるようになっている。
【０００６】
ＭＰＤデータは、クライアント装置が動画コンテンツの配信を受ける前に、クライアント装置が配信サーバから取得する。クライアント装置は、ＭＰＤデータに記載された各メディアセグメントのURLを基に、順次メディアセグメントを取得し、動画コンテンツの再生を行うことができる。また、非特許文献１の技術ではトリック再生を行うことができないが、ＤＡＳＨに準拠したクライアント装置は、ＭＰＤデータに取得可能な全てのメディアセグメントの情報が含まれているため、タイムシフト再生や早送り等のトリック再生を行うことができる。
【０００７】
ところで、ライブコンテンツには、配信が開始される前から配信終了時刻が確定している音楽番組のようなライブコンテンツと、プロ野球のナイター中継や災害発生時におけるニュース番組のように、配信が開始されてからも配信終了時刻が確定しないライブコンテンツとが存在する。
【０００８】
配信サーバは、前者のライブコンテンツを配信する場合には、配信終了時刻（すなわち、全ピリオド）が予め確定しているため、ライブコンテンツを構成する全メディアセグメントのＵＲＬを含むＭＰＤデータをクライアント装置に伝送することができる。したがって、クライアント装置は、ライブコンテンツの再生を開始する前に上記ＭＰＤデータを１回受信すれば、ライブコンテンツを最後まで再生することができる。
【０００９】
一方、配信サーバは、後者のライブコンテンツを配信する場合には、配信終了時刻が確定するまで、最終的に配信されることになる全メディアセグメントのＵＲＬを含むＭＰＤデータを生成し、クライアント装置に伝送することができない。したがって、クライアント装置は、配信終了時刻が確定していない時点で受信したＭＰＤデータのみでは、ライブコンテンツを最後まで再生することができない。
【００１０】
非特許文献２の技術では、後者のライブコンテンツを配信する場合において、クライアント装置がライブコンテンツを最後まで再生できるように、配信サーバが最新状態に更新されているＭＰＤデータをクライアント装置に定期的に伝送する「MPD Update」と呼ばれる処理が用いられる。なお、「MPD Update」では、タイムシフト再生や早送り等のトリック再生をサポートするか否によって、後述する２種類の処理方法（「更新処理１」、「更新処理２」）が存在する。
〔更新処理１〕
更新処理１では、配信サーバが、ＭＰＤデータを更新すべき各時点において前回のＭＰＤデータに対して後続するピリオドの情報を追加し、これにより最新状態に更新されているＭＰＤデータを、クライアント装置に定期的に伝送する。配信サーバのこのような更新処理の具体例について図１５を参照して以下に説明する。
【００１１】
図１５は、配信サーバがクライアント装置に伝送する一部のＭＰＤデータを概略的に例示した図である。図１５において、属性「minimumUpdatePeriodMPD」の属性値は、配信サーバがＭＰＤデータを更新する周期を示している。この属性値は、クライアント装置が配信サーバからＭＰＤデータを取得する周期でもあり、図１５の例では“１０分”である。図１５（ａ）は、配信開始時刻における初期のＭＰＤデータを示している。
【００１２】
この例では、配信サーバは、配信開始から１０分経過後に、ＭＰＤデータに対して開始時間が配信開始２０分後である後続のピリオドの情報を１つ追加する最初の更新を行い、その後１０分毎に、後続のピリオドの情報を１つ追加する。図１５（ｂ）は、配信開始から１０分経過後におけるＭＰＤデータを示しており、点線で囲まれた部分は、追加されたピリオドを示している。
【００１３】
これに対し、クライアント装置は、ライブコンテンツの再生中、属性「minimumUpdatePeriodMPD」の属性値が示す時間である１０分毎に、最新状態のＭＰＤデータを配信サーバから取得するとともに取得したＭＰＤデータに基づいてライブコンテンツの再生を継続する。
【００１４】
その後、配信サーバは、配信終了時刻が確定した時点で、残りのピリオドの情報を追加する。図１５（ｃ）は、配信終了時刻が確定した時点である配信開始から４０分経過後におけるＭＰＤデータを示しており、点線で囲まれた部分は、追加された残りのピリオドを示している。図１５（ｃ）に示すように、最終的に確定したＭＰＤデータでは、属性「minimumUpdatePeriodMPD」が削除されている。
【００１５】
クライアント装置は、取得したＭＰＤデータに属性「minimumUpdatePeriodMPD」が存在しないことをもって、定期的なＭＰＤデータの取得を終了すべきであると判断する。クライアント装置は、最終的に確定したＭＰＤデータに基づいてライブコンテンツを最後まで再生する。なお、図１５（ｃ）を見るとわかるように、最新状態のＭＰＤデータには、常に、最初のピリオドから現在時刻が属するピリオドまでの情報が含まれているため、クライアント装置は、常に、ライブコンテンツの先頭からトリック再生を行うことが可能である。
〔更新処理２〕
更新処理２は、配信サーバが、ＭＰＤデータを更新すべき各時点において前回のＭＰＤデータに対して後続するピリオドの情報を追加するとともに最も古いピリオドの情報を削除する処理であり、配信サーバは、これにより最新状態に更新されたＭＰＤデータを、クライアント装置に定期的に伝送する。
【００１６】
配信サーバのこのような更新処理２の具体例について図１６を参照して以下に説明する。
【００１７】
図１６は、この「ＭＰＤ Update」処理において、配信サーバがクライアント装置に伝送する一部のＭＰＤデータを概略的に例示した図である。図１６（ａ）は、配信開始時刻における初期のＭＰＤデータを示している。
【００１８】
この例では、配信サーバは、配信開始から１０分経過後に、ＭＰＤデータに対して開始時間が配信開始２０分後である後続のピリオドの情報を１つ追加するとともに開始時間が配信開始時点である最も古いピリオドの情報を削除する最初の更新を行う。図１６（ｂ）は、配信開始から１０分経過後におけるＭＰＤデータを示している。配信サーバは、その後１０分毎に、後続のピリオドの情報を１つ追加するとともにその時点で最も古いピリオドの情報を削除する。そして、配信サーバは、配信終了時刻が確定した時点である４０分経過後に、残りのピリオドの情報を追加する。図１６（ｃ）は、配信開始から４０分経過後におけるＭＰＤデータを示している。
【００１９】
クライアント装置は、更新処理２によって更新されたＭＰＤデータを受信する場合も、更新処理１によって更新されたＭＰＤデータを受信する場合と同様にライブコンテンツの再生を行う。なお、図１６（ｃ）からわかるように、更新処理２によって更新された最新状態のＭＰＤデータには、常に一定数のピリオドの情報しか含まれていないため、クライアント装置が受信するＭＰＤデータのデータ量は、常に、略一定となる。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】“HTTP Live Streaming”、[online]、２０１１年３月、［２０１１年６月３日検索］、Apple Inc.、インターネット<http://tools.ietf.org/html/draft-pantos-http-live-streaming-06>
【非特許文献２】“Information technology-MPEG systems technologies - Part6:Dynamic Adaptive streaming over HTTP(DASH)”、[online]、２０１１年１月２８日、[２０１１年６月３日検索]、ISO/IEC、インターネット<http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11873t.doc>
【発明の概要】
【発明が解決しようとする課題】
【００２１】
配信サーバが、定期的に、上記更新処理１によって更新した最新状態のＭＰＤをクライアント装置に伝送する場合には、クライアント装置は、すでに取得済のピリオドに関する情報を何度も受信することになる。また、配信サーバからストリーミング配信されているライブコンテンツを鑑賞しているユーザの多くは鑑賞中に一度もタイムシフト再生機能を使用しないと考えられる。タイムシフト再生を行わない多くのクライアント装置は、そのようなクライアント装置にとっては非常に冗長な情報量を持つＭＰＤデータを受信してしまうことになる。
【００２２】
したがって、上記更新処理１によって更新したＭＰＤデータを配信するのは、ＭＰＤデータの配信効率が良いとは言えない。
【００２３】
一方、配信サーバが、定期的に、上記更新処理２によって更新した最新の状態のＭＰＤデータをクライアント装置に伝送する場合、更新のたびにその時点で最も古いピリオドの情報がＭＰＤデータから削除されてしまうため、クライアント装置は、現在時刻から過去に遡った一定範囲内の再生位置でしかタイムシフト再生を行うことができないという問題がある。
【００２４】
本発明は、上記課題に鑑みて成されたものであり、その主な目的は、再生装置が任意の再生位置でライブコンテンツのトリック再生を行うことを可能にするＭＰＤデータ（より一般的にはライブ配信を制御するメタデータ）であって従来よりも配信効率の良い（データ量の小さい）ＭＰＤデータ（メタデータ）を生成可能な生成装置および生成方法を実現することにある。
【００２５】
また、そのような生成装置によって生成されたＭＰＤデータ（メタデータ）に基づいて、ライブ配信されたコンテンツを再生する再生装置および再生方法を実現すること、および、そのようなＭＰＤデータ（メタデータ）のデータ構造を提供することも本発明の目的の範疇に含まれる。
【課題を解決するための手段】
【００２６】
本発明に係る生成装置は、複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置において、過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成手段と、上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについて、その所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成手段と、を備えていることを特徴としている。ここで、上記第２の生成手段は、過去に生成した第２のメタデータを編集することによって第２のメタデータを生成してもよいし、過去に生成した第２のメタデータとは独立に第２のメタデータを生成してもよい。
【００２７】
上記の構成によれば、本発明に係る生成装置が生成する第２のメタデータには、現在配信されている時分割データの所在を示す第１の資源位置指定子が含まれている。また、上記第２のメタデータには、過去に配信された上記複数の時分割データの各々について、当該時分割データの所在を示す第１の資源位置指定子が含まれているか、あるいは、当該時分割データの所在を示す第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子が含まれている。そして、第２のメタデータを取得した上記再生装置は、現在配信され、あるいは、過去に配信された、任意の時分割データの所在を特定することができる。
【００２８】
したがって、本発明に係る生成装置は、ライブコンテンツをライブ再生している再生装置が任意の位置でトリック再生することができるような第２のメタデータを生成することになる。
【００２９】
また、一般的に、第２の資源位置指定子のデータサイズは、第２の資源位置指定子により所在が示される第１のメタデータに含まれる各第１の資源位置指定子のデータサイズの総和よりも小さいことは明らかであるので、現在配信され、または、過去に配信された上記複数の時分割データの各々について当該時分割データの第１の資源位置指定子を含むような、従来の装置が生成するメタデータよりも、上記第２のメタデータのデータサイズは小さくなる。さらに、トリック再生を行わない再生装置は、過去に配信された時分割データを取得しないので第１のメタデータを取得することはない。
【００３０】
したがって、トリック再生を行わない再生装置にとっては従来よりもメタデータの配信効率が良くなる。
【００３１】
以上のことから、本発明に係る生成装置は、再生装置が任意の再生位置でライブコンテンツのトリック再生を行うことを可能にする、ライブ配信されるコンテンツデータに関するメタデータであって従来よりも配信効率の良いメタデータを生成することができる。
【００３２】
本発明に係る生成方法は、複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置の生成方法において、過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成工程と、上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成工程と、からなる生成工程を繰り返すことを特徴としている。
【００３３】
上記の構成によれば、本発明に係る生成方法は、本発明に係る生成装置と同様の作用効果を奏する。
【００３４】
なお、上記ライブ配信で用いるメタデータのデータフォーマットおよびメディアセグメントのデータフォーマットは、ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）に準拠したデータフォーマットであり、上記時分割データはメディアセグメントであり、上記第１のメタデータはリモートオブジェクトであって上記第２のメタデータは上記コンテンツデータに関するＭＰＤデータであり、上記第１の資源位置指定子は上記メディアセグメントのＵＲＬであって上記第２の資源位置指定子は上記リモートオブジェクトのＵＲＬである、ことが望ましい。また、上記コンテンツデータと上記コンテンツデータに関するメタデータとを上記再生装置に配信する配信サーバであって上記生成装置としても機能する配信サーバとして本発明を実現することが望ましい。
【００３５】
本発明に係る生成装置は、上記コンテンツデータが、配信開始時刻には配信終了時刻が確定していないコンテンツデータであり、上記第２の生成手段が、上記配信終了時刻が確定した後に上記第２のメタデータを生成する場合には、上記第２のメタデータとして、上記配信開始時刻から上記配信終了時刻までに配信される全時分割データについて上記メタ情報を含むような第２のメタデータを生成することが望ましい。
【００３６】
上記の構成によれば、本発明に係る生成装置は、再生装置に配信開始時刻には配信終了時刻が確定していないコンテンツデータを最後まで再生させることができるようなメタデータを生成することができるというさらなる効果を奏する。
【００３７】
さらに、本発明に係る生成装置では、上記過去の所定の期間が、上記第２の生成手段が上記第２のメタデータを生成する時点を含む一定期間よりも過去の全期間であることが望ましい。
【００３８】
上記の構成によれば、本発明に係る生成装置が繰り返し生成する第２のメタデータには、生成された時点を含む上記一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す第１の資源位置指定子が含まれることになる。換言すれば、本発明に係る生成装置が生成する第２のメタデータのデータサイズは生成の度にそれほど大きく増えるわけではないと言える。
【００３９】
したがって、本発明に係る生成装置は、より配信効率の良いメタデータを生成することができるというさらなる効果を奏する。
【００４０】
本発明に係る再生装置は、上記課題を解決するために、配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含むような、第１のメタデータを取得する第１の取得手段と、上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を含んでいる第２のメタデータを取得する第２の取得手段と、上記第２のメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、上記再生手段が、取得すべき時分割データの第１の資源位置指定子が上記第２のメタデータに含まれていない場合には、第２の資源位置指定子を参照して当該第１の資源位置指定子を含む第１のメタデータを取得するとともに当該第１の資源位置指定子を参照して当該時分割データを取得する、ことを特徴としている。
【００４１】
上記の構成によれば、本発明に係る再生装置が取得する第１のメタデータおよび第２のメタデータは、それぞれ、本発明に係る生成装置が生成する第１のメタデータおよび第２のメタデータと同じものである。また、上記再生装置は、ライブ再生の指示を受け付けた時点で再生のために取得すべき時分割データを第２の資源位置指定子を参照することにより取得することができ、トリック再生の指示を受け付けた時点で再生のために取得すべき時分割データを、第１の資源位置指定子および第２の資源位置指定子のいずれかを参照することにより取得することができる。
【００４２】
したがって、本発明に係る再生装置は、本発明に係る生成装置によって生成されたメタデータに基づいて、ライブ配信されたコンテンツを再生することができる。
【００４３】
本発明に係る再生装置は、上記課題を解決するために、配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得手段と、上記取得手段がメタデータを取得する度に当該メタデータから新たなメタデータを生成する生成手段と、上記生成手段が直前に生成した新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、上記生成手段が、当該生成手段が直前に生成したメタデータおよび上記取得手段が新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する、ことを特徴としている。
【００４４】
上記の構成によれば、本発明に係る再生装置は、過去に取得したメタデータに含まれていたすべての資源位置指定子を含むようなメタデータを新たなメタデータとして生成する。
【００４５】
したがって、本発明に係る再生装置は、配信開始時点からコンテンツデータの再生を開始していれば、現在配信され、または、過去に配信されたすべてのメディアセグメントについてその所在を示す資源位置指定子を含むようなメタデータを生成するので、当該メタデータに基づいてライブコンテンツのライブ再生および任意の再生位置でのトリック再生を行うことができる。
【００４６】
また、本発明に係る再生装置が取得するメタデータは、ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含んでいる。
【００４７】
したがって、本発明に係る再生装置は、ライブコンテンツのライブ再生および任意の再生位置でのトリック再生を行うために取得すべきメタデータを従来よりも効率良く取得することができる。
【００４８】
本発明に係る再生装置は、上記課題を解決するために、配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置の再生方法において、ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得工程と、上記取得工程にてメタデータが取得される度に当該メタデータから新たなメタデータを生成する生成工程と、直前の上記生成工程にて生成された新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生工程と、を含み、上記生成工程は、当該生成工程の直前の生成工程にて生成されたメタデータおよび上記取得工程にて新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する工程であることを特徴としている。
【００４９】
上記の構成によれば、本発明に係る再生方法は、本発明に係る再生装置と同様の作用効果を奏する。
【００５０】
なお、上記ライブ配信で用いられる上記時分割データはＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）に準拠したメディアセグメントである、ことが望ましい。
【００５１】
本発明に係る生成装置と再生装置とを含む再生システムも本発明の範疇に含まれる。
【００５２】
また、本発明に係る生成装置または再生装置としてコンピュータを動作させるプログラムであって、コンピュータを上記生成装置または上記再生装置の各手段として機能させることを特徴とするプログラム、および、そのようなプログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。
【００５３】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータのデータ構造において、上記メタデータに含まれる、所定の期間における時分割データ群の所在を特定するためのメタ情報のデータ構造が、上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含むようなメタデータの所在を示す第２の資源位置指定子を上記メタ情報として含む第１のデータ構造、および、上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を上記メタ情報として含む第２のデータ構造のうち、上記コンテンツデータのライブ配信が開始されてからの経過時間に応じて選択されたデータ構造となっていることを特徴とするメタデータのデータ構造に係る発明も本発明の範疇に含まれる。
【発明の効果】
【００５４】
以上のように、本発明の生成装置および生成方法は、再生装置が任意の再生位置でトリック再生することを可能にする、ライブ配信されるコンテンツデータに関するメタデータであって従来よりも配信効率の良いメタデータを生成することができる。
【００５５】
また、本発明の再生装置および再生方法は、本発明の生成装置によって生成されたＭＰＤデータに基づいてライブコンテンツを再生することができる。
【図面の簡単な説明】
【００５６】
【図１】本発明の実施形態に係るクライアント装置および配信サーバの構成を示した図である。
【図２】本発明の実施形態に係る配信システムの全体構成を示した図である。
【図３】図１のクライアント装置が参照するＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）データの一例を概略的に示した図である。
【図４】図１の配信サーバが備えるメタデータ作成部が定期的にＭＰＤデータを更新する動作の一実施形態を示すフローチャートである。
【図５】図１のクライアント装置が参照するリモートオブジェクトの一例を概略的に示した図である。
【図６】図１のクライアント装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図７】本発明の別の一実施形態に係るクライアント装置および配信サーバの構成を示した図である。
【図８】本発明の別の一実施形態に係る配信システムの全体構成を示した図である。
【図９】図７の配信サーバが図７のクライアント装置に配信するＭＰＤデータおよび図７のクライアント装置が生成するＭＰＤデータの一例を概略的に示した図である。
【図１０】図７の配信サーバが備えるメタデータ作成部が定期的にＭＰＤデータを更新する動作の一実施形態を示すフローチャートである。
【図１１】図７のクライアント装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図１２】図１１のフローチャートにおける１ステップについてより詳細な処理の流れに示したフローチャートである。
【図１３】図７の配信サーバが映像コンテンツのＭＰＤデータを更新するタイミングと、その映像コンテンツの各ピリオドと、クライアント装置がＭＰＤデータを取得するタイミングと、クライアント装置が各ピリオドの映像を再生する期間と、の時間的関係を模式的に示した図である。
【図１４】ＭＰＤデータの一例を概略的に示した図である。
【図１５】従来技術を示すものであり、ＭＰＤ Ｕｐｄａｔｅにより更新されるＭＰＤデータの一例を概略的に示した図である。
【図１６】従来技術を示すものであり、ＭＰＤ Ｕｐｄａｔｅにより更新されるＭＰＤデータの別の一例を概略的に示した図である。
【図１７】ＭＰＤ初期データの一例を示した図である。
【図１８】図７のクライアント装置が参照するＭＰＤデータの一例を概略的に示した図である。
【発明を実施するための形態】
【００５７】
〔実施形態１〕
本発明の一実施形態に係る配信システムは、配信開始時点では配信終了時刻が確定しないスポーツ中継のような映像コンテンツをクライアント装置にライブストリーミング配信する配信システムである。なお、当該システムでは、メタデータおよびメディアセグメントに前述のＤＡＳＨ規定のデータフォーマットを用いる。
【００５８】
本実施形態に係る配信システムについて図１〜図６を参照しながら説明する。
【００５９】
図１は、本実施形態に係るクライアント装置および配信サーバの全体構成を示した図であり、図２は、本実施形態に係る配信システム１の全体構成を示した図である。
【００６０】
図２に示すように、配信システム１は、クライアント装置１００と配信サーバ３００とネットワークストレージサーバ（ＮＡＳ）４００とを含むシステムである。また、クライアント装置１００および配信サーバ３００は、インターネットＮＷに接続している。
【００６１】
以下、クライアント装置１００、配信サーバ３００、およびＮＡＳ４００について説明する。
（クライアント装置１００）
図１に示すように、クライアント装置１００は、ストリーミング制御部１１０、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および操作部１６０を備えている。
【００６２】
クライアント装置１００は、操作部１６０を介して映像コンテンツの再生指示をユーザから受け付けると、そのライブ再生すべき映像コンテンツ（以下では、再生指示を受け付けた映像コンテンツを「対象映像コンテンツ」とも称する）を、配信サーバ３００からメディアセグメント（映像コンテンツの符号化データを一定時間ごとに分割して得られる各単位、以下、「ＭＳ」とも称する）単位で受信して再生する。
【００６３】
具体的には、クライアント装置１００は、再生指示を受け付けた時点で対象映像コンテンツに関するＭＰＤデータ（第２のメタデータ）を配信サーバ３００から受信することにより、対象映像コンテンツを再生するために受信すべきＭＳのＵＲＬ（第１の資源位置指定子）を特定し、配信開始時刻になると、ＵＲＬで指定される配信サーバ３００からＭＳを受信して対象映像コンテンツの再生を開始する。また、クライアント装置１００は、対象映像コンテンツの再生中にも定期的に配信サーバ３００からＭＰＤデータを取得する。そして、クライアント装置１００は、対象映像コンテンツの再生中は常に、最後に取得したＭＰＤデータに基づいて、対象映像コンテンツの再生を継続するのに必要なＭＳを受信する。
（ストリーミング制御部１１０）
ストリーミング制御部１１０は、配信サーバ３００から定期的にその時点で最新状態のＭＰＤデータを取得する。
【００６４】
ストリーミング制御部１１０は、最新状態のＭＰＤデータおよび必要に応じて後述するリモートオブジェクトを参照することにより、対象映像コンテンツのうち再生対象となる部分を構成する各ＭＳの配信開始時刻を特定する。ＭＰＤデータにおける各ＭＳの配信開始時刻は、ライブ再生時における当該ＭＳの再生開始時刻も示していることから、ストリーミング制御部１１０は、現在時刻（ライブ再生の場合）またはユーザ操作による指定時刻（トリック再生の場合）と各ＭＳについて特定した配信開始時刻とから、再生すべきＭＳのＵＲＬを特定し、そのＭＳを受信するためのＨＴＴＰ要求を配信サーバ３００に送信する。
【００６５】
ストリーミング制御部１１０は、配信サーバ３００から受信したＭＳを記憶部１３０にバッファリングする。
（再生部１２０）
再生部１２０は、再生すべき時刻の早い順に、記憶部１３０にバッファリングされているＭＳを読み出してデコードおよび再生を行うことにより、対象映像コンテンツを表示部１５０に表示する。
（記憶部１３０）
記憶部１３０は、対象映像コンテンツを構成する各ＭＳをバッファリングし、対象映像コンテンツに関するＭＰＤデータを記憶するための記録媒体である。
（ネットワークＩ／Ｆ１４０）
ネットワークＩ／Ｆ１４０は、サーバ３００との間でデータの送受信を行う。
（表示部１５０）
表示部１５０は、対象映像コンテンツを表示するディスプレイである。
（操作部１６０）
操作部１６０は、クライアント装置１００に対する指示をユーザが行うための操作パネルである。
（配信サーバ３００）
配信サーバ３００は、配信部３１０と、メタデータ作成部３２０と、パラメータ制御部３３０と、を備えている。
【００６６】
映像コンテンツの配信開始時刻になると、対象映像コンテンツを構成する映像をＭＳ単位で順次、ライブエンコーダ（図示せず）がエンコードし、ＮＡＳ４００に記録する。これと並行して、メタデータ作成部３２０は、その映像コンテンツのＭＰＤデータを繰り返し（本実施形態では１０分毎に）生成し、最新状態に更新するとともに後述するリモートオブジェクト（第１のメタデータ）を生成する。
【００６７】
パラメータ制御部３３０は、配信サービス事業者の担当者の指示内容に基づいて、メタデータ作成部３２０がＭＰＤデータを生成するために参照する各種パラメータを制御する。
【００６８】
また、配信部３１０は、クライアント装置１００からＭＰＤデータの要求を受けると、ＮＡＳ４００に記録されているその時点で最新の状態のＭＰＤデータをクライアント装置１００に送信する。そして、配信サーバ３００は、クライアント装置１００からＭＳのＨＴＴＰ要求を受けると、ＮＡＳ４００に記録された該ＭＳをクライアント装置１００に配信する。
（ＮＡＳ４００）
ＮＡＳ４００は、映像コンテンツを構成する各ＭＳ、映像コンテンツに関するＭＰＤデータ、および後述するリモートオブジェクトを保持するネットワークストレージである。
（ＭＰＤデータについて）
次に、上述したＭＰＤデータについて図３を参照しながら以下に説明する。図３は、ＮＡＳ４００が保持しており、クライアント装置１００が受信すべきＭＳを特定するために参照するＭＰＤデータの一部を概略的に例示した図である。なお、図３におけるピリオドの開始タグと終了タグとの間に囲まれた範囲の「…」の表記は、当該部分に非特許文献２に記載されているようなグループ、リプレゼンテーション、ＭＳ等に関する情報が含まれていることを意味している。すなわち、「…」の部分には相当なバイトサイズのデータが含まれている。
【００６９】
図３（ａ）は、配信開始時刻における初期のＭＰＤデータを示している。また、図３（ｂ）は、配信終了時刻が確定する前である配信開始１０分経過後におけるＭＰＤデータを示しており、図３（ｃ）は、配信終了時刻が確定した時点である配信開始４０分経過後におけるＭＰＤデータを示している。
【００７０】
図３（ｂ）および図３（ｃ）を見るとわかるように、更新後のＭＰＤデータの要素「Period」には、属性値がリモートオブジェクトの所在を示すURL（第２の資源位置指定子）である属性「href」を含んでいるもの（図中において点線の枠で囲まれた部分。以下では、そのような要素「Period」を「外部参照ピリオド」とも称することにする）とそのような属性「href」を含んでおらず、要素値に当該ピリオドを構成するＭＳの所在を示すURL（第１の資源位置指定子）を含むもの（以下では、そのような要素「Period」を「通常ピリオド」とも称することにする）と、が存在することがわかる。また、外部参照ピリオド（第１のデータ構造）の要素値は空であり、通常ピリオド（第２のデータ構造）に比べ、当該ピリオドに関する情報のデータサイズは非常に小さくなっていることがわかる。
（ＭＰＤデータの生成動作について）
次に、メタデータ作成部３２０が、ＭＰＤデータの各更新時において、最新状態のＭＰＤデータを生成する動作について図３〜図５および図１７を参照しながら説明する。
【００７１】
図４は、メタデータ作成部３２０の上記動作を示すフローチャート図である。なお、図４の動作フロー開始にあたり、メタデータ作成部３２０には、パラメータ制御部３３０から以下のパラメータが入力されるものとする。
update：当該ＭＰＤデータの次回更新が必要であれば「true」であり、対象映像コンテンツの配信終了時刻が確定しており、次回更新の必要がなければ「false」である。なお当該パラメータは、例えば、図示しない操作部を介して配信サービス事業者の担当者から配信終了時刻が確定した旨を示す情報を受け取り済みの場合に、falseに設定される。
Ｄp:１つのピリオドに属する対象映像コンテンツの再生時間（１つのピリオドに含められるＭＳの総再生時間）。図３のＭＰＤデータを生成する場合、「１０分」である。
Ｔa:対象映像コンテンツの配信開始時刻（対象映像コンテンツのライブ再生開始時刻）。
Ｔc:当該ＭＰＤデータ生成時刻（現在時刻）。
Ｔe:当該ＭＰＤデータに含める必要のあるピリオドを決定するための閾値。
【００７２】
最初に、図１７に示すような、ＭＰＤ更新により変化しない共通要素のみからなるＭＰＤ初期ドキュメントを作成する（Ｓ１）。
【００７３】
次に、Ｓ２において、対象映像コンテンツの配信終了時刻が確定しているか否かを判定する。対象映像コンテンツの配信終了時刻が確定していないと判定した場合には（Ｓ２においてＹＥＳ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加する（Ｓ３）。例えば、メタデータ作成部３２０は、対象映像コンテンツの配信開始１０分経過後に図３（ｂ）のようなＭＰＤデータを作成する場合、その時点では配信終了時刻が確定してないため、属性「minimumUpdatePeriodMPD」を追加し、ＭＰＤデータの更新間隔Ｄpにあたる属性値「PT10M」を設定する。
【００７４】
一方、対象映像コンテンツの配信終了時刻が確定したと判定した場合には（Ｓ２においてＮＯ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加せずに、Ｓ４に進む。例えば、対象映像コンテンツの配信終了時刻が確定した配信開始４０分経過後にＭＰＤデータを更新する際には、図３（ｃ）に示すように更新後のＭＰＤデータにおいて要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」は含まれないことになる。
【００７５】
Ｓ４において、処理対象時刻変数ＴをＴaに初期化するとともに、処理対象ピリオドが対象映像コンテンツの先頭から何番目のピリオドであるかを示す変数Ｎを１に初期化する。
【００７６】
Ｓ５において、Ｎ番目のピリオドに関する情報を通常のピリオドとして生成し、Ｓ６に進む。Ｓ６において、メタデータ作成部３２０は、Ｔ＜Ｔcが成立するか否かを判定する。メタデータ作成部３２０がＴ＜Ｔcが成立しないと判定した場合（Ｓ６においてＮＯ）、Ｓ９に進む。
【００７７】
一方、Ｔ＜Ｔcが成立すると判定した場合（Ｓ６においてＹＥＳ）、Ｓ５で生成した通常ピリオドをリモートオブジェクトとしてＮＡＳ４００に出力し（Ｓ７）、Ｓ８に進む。なお、Ｎ番目のピリオドのリモートオブジェクトは、図５に示す例のように、ＭＰＤデータや他のリモートオブジェクトとは別にＮＡＳ４００に記録される。本動作例では、Ｎ番目のピリオドのリモートオブジェクトは、ファイル名が「pN.xml」（Nは数値であり、例えば、N=1の場合「p1.xml」である。以下「pN.xml」の記載を同様の意味で用いる）であるＸＭＬファイルとして記録される。
【００７８】
Ｓ８において、Ｓ７で生成したリモートオブジェクトを参照する外部参照ピリオドを生成し、Ｓ９に進む。
【００７９】
Ｓ９において、Ｎ番目のピリオドに関して直近で生成したピリオド情報（直前のステップがＳ８である場合にはＳ８において生成した外部参照ピリオドであり、直前のステップがＳ６である場合にはＳ５で生成した通常ピリオド）を、生成すべきＭＰＤデータの一部として追加する。
【００８０】
Ｓ１０において、次のピリオドの処理のため、変数ＴにＤpの値を加算するとともに、変数Ｎに１を加算し、Ｓ１１に進む。
【００８１】
Ｓ１１において、Ｔ＜Ｔeが成立するか否かを判定する。Ｔ＜Ｔeが成立すると判定した場合（Ｓ１１においてＹＥＳ）、未処理のピリオドについてピリオド情報を生成するため、Ｓ５に戻る。一方、Ｔ＜Ｔeが成立しないと判定した場合（Ｓ１１においてＮＯ）、当該ＭＰＤデータに記載する必要のあるピリオド情報の生成が完了し、Ｓ１２に進む。
【００８２】
Ｓ１２において、Ｓ１〜Ｓ１１までの処理によって作成したＭＰＤデータ（すなわち、更新により最新状態となったＭＰＤデータ）をＮＡＳ４００に記録し、処理を終了する。なお、クライアント装置１００から要求されたタイミングに応じて、最新の状態に更新されたＭＰＤデータがＮＡＳ４００から読み出され配信部３１０により配信される。
【００８３】
以上、メタデータ作成部３２０が行うＭＰＤデータの更新処理動作について説明したが、以上の更新処理動作により、対象映像コンテンツの配信終了時刻が確定した後に更新されたＭＰＤデータには、対象映像コンテンツを構成するすべてのピリオドについて、外部参照ピリオドまたは通常ピリオドが含まれることになる。したがって、配信サーバ３００は、クライアント装置１００から要求されたタイミングが配信終了時刻確定後におけるＭＰＤデータの更新後である場合には、対象映像コンテンツを構成するすべてのピリオドのピリオド情報を含むＭＰＤデータをＮＡＳ４００から読み出して配信することになる。
【００８４】
なお、ＭＰＤデータを生成する際、ＭＰＤの更新間隔をピリオドの再生時間Ｄpとすることで、ＴcをＮ番目のピリオドの再生開始時刻と一致させることができ、外部参照ピリオドとして生成される１〜Ｎ−１番目のピリオドだけでなく、通常ピリオドとして生成さるＮ番目のピリオド以降にもライブ再生に不要なＭＳのＵＲＬは一切含まれない。また、閾値Ｔeを、Updateがtrueの場合には、Ｔe＝Ｔc＋2Ｄpとし、,Updateがfalseの場合には、Ｔe＝「当該映像コンテンツの配信終了時刻」とすることで、当該ＭＰＤデータには、任意のクライアント装置１００が最新のＭＰＤデータを取得した時点から、次回MPDデータの取得までの期間（つまり属性「minimumUpdatePeriodMPD」で示される期間）にライブ配信およびライブ再生されるＭＳのＵＲＬのみを含めることができる。言い換えれば、ライブ再生を行うのに必要な最小限の通常ピリオドを含む配信効率の高いＭＰＤデータを生成することができる。
【００８５】
以下では、操作部１６０を介して再生指示を受け付けたクライアント装置１００が、配信サーバ３００が配信する対象映像コンテンツを再生するための動作について、図３、図５および図６を参照しながら説明する。
【００８６】
図６は、クライアント装置１００の上記動作を示すフローチャート図である。なお、図６において、Ｔsは、操作部１６０を介したユーザ操作による再生指示によって決定される再生開始位置を示す入力パラメータである。Ｔsは、再生指示がライブ再生の場合においては現在時刻を示しており、再生指示がトリック再生の場合においては、再生指示に基づく指定時刻を示している。
【００８７】
また、Ｄpは、ピリオドに属する対象映像コンテンツの再生時間（ＭＰＤデータの要素「Period」における属性「duration」の属性値として、あるいは、連続する２つの要素「Period」における各属性「start」の属性値の差として得られる）を示しており、Ｄsは１つのＭＳが継続して再生される期間（ＭＰＤデータの要素「SegmentInfo」における属性「duration」の属性値として得られる）を示している。
【００８８】
最初に、ストリーミング制御部１１０は、再生処理開始に先立ち、処理対象時刻を表す変数ＴをＴsで初期化し、処理対象を示す変数Ｎを１で初期化する（Ｓ２１）。
【００８９】
Ｓ２２において、ストリーミング制御部１１０は、配信サーバ３００にＭＰＤデータを要求し、配信サーバ３００からＭＰＤデータを受信し、記憶部１３０に記憶する。Ｓ２３において、ストリーミング制御部１１０は、Ｓ２２で受信され、記憶部１３０に記憶されたＭＰＤデータの内容を読み出し、Ｓ２４に進む。
【００９０】
Ｓ２４において、ストリーミング制御部１１０は、読み出したＭＰＤデータの中に属性「minimumUpdatePeriodMPD」が存在するか否かを判定する。
【００９１】
ストリーミング制御部１１０は、読み出したＭＰＤデータの中に属性「minimumUpdatePeriodMPD」が存在すると判定した場合（Ｓ２４においてＹＥＳ）、次回ＭＰＤデータを配信サーバ３００から取得する時刻を示す変数Ｔuに変数Ｔと属性「minimumUpdatePeriodMPD」の属性値との和を代入し（Ｓ２５）、Ｓ２７に進む。
【００９２】
一方、ストリーミング制御部１１０は、読み出したＭＰＤデータの中に属性「minimumUpdatePeriodMPD」が存在しないと判定した場合（Ｓ２４においてＹＥＳ）、以降ＭＰＤデータの更新は不要であるため、変数Ｔuに、対象映像コンテンツの配信終了時刻以降を示す十分に大きい値（例えば、変数Ｔが示す時刻の１ヶ月後を示すような値）を設定し（Ｓ２６）、Ｓ２７に進む。
【００９３】
Ｓ２７において、ストリーミング制御部１１０は、N番目のピリオドが再生対象であるか否かを判定する。具体的には、N番目のピリオドの配信開始時刻（およびライブ再生開始時刻）を示す属性「start」の属性値ＴNを用いて、ＴN≦Ｔ＜ＴN＋Ｄpが成立するか否かを判定する。成立しないと判定した場合、当該ピリオドは再生処理対象外であると判断し（Ｓ２７においてＮＯ）、ストリーミング制御部１１０はＮに１を加算することで再生処理対象ピリオドを次のピリオドへ切り替え（Ｓ２８）、Ｓ２７に戻る。
【００９４】
一方、ＴN≦Ｔ＜ＴN＋Ｄpが成立すると判定した場合、当該ピリオドを再生処理対象であると判断し（Ｓ２７においてＹＥＳ）、Ｎ番目のピリオドについて、属性「href」の有無で、外部参照ピリオドであるか、あるいは、通常ピリオドであるかを判定する（Ｓ２９）。
【００９５】
通常ピリオドと判定された場合（Ｓ２９においてＮＯ）、Ｓ３２に進む。一方、外部参照ピリオドと判定された場合（Ｓ２９においてＹＥＳ）、ストリーミング制御部１１０は、Ｎ番目のピリオドである外部参照ピリオドにおける属性「href」の属性値を参照することにより、リモートオブジェクトであるＸＭＬファイルpN.xmlを配信サーバ３００から受信する（Ｓ３０）
Ｓ３０の後、ストリーミング制御部１１０は、受信したリモートオブジェクトpN.xmlの内容を読み出し（Ｓ３１）、Ｓ３２に進む。なお、前述したように、pN.xmlの内容は、Ｎ番目のピリオドを示す通常ピリオドである。すなわち、Ｎ番目のピリオドに属する各ＭＳ（時分割データ群を構成する各時分割データ）の所在を示すＵＲＬ（第１の資源位置指定子）が含まれている。したがって、クライアント装置１００は、pN.xmlに基づいてＮ番目のピリオドの再生を行うことができる。
【００９６】
Ｓ３２において、ストリーミング制御部１１０は、当該ピリオドにおける処理対象ＭＳを示す変数Ｍを１に初期化し（Ｓ３２）、Ｓ３３に進む。
【００９７】
Ｓ３３において、ストリーミング制御部１１０は、ＴN＋（Ｍ−１）×Ｄs＜Ｔが成立するか否かを判定する。ストリーミング制御部１１０は、ＴN＋（Ｍ−１）×Ｄs＜Ｔが成立すると判定した場合（Ｓ３３においてＹＥＳ）、当該ＭＳは再生処理ではないと判断し、Ｍに１を加算し（Ｓ３４）、Ｓ３３に戻る。
【００９８】
一方、ストリーミング制御部１１０は、ＴN＋（Ｍ−１）×Ｄs＜Ｔが成立しないと判定した場合（Ｓ３３においてＮＯ）、クライアント装置１００は、当該ＭＳ（Ｎ番目のピリオドにおけるＭ番目のＭＳ）を再生処理対象と判断して再生する（Ｓ３５）。
【００９９】
具体的には、ストリーミング制御部１１０は、Ｓ２３で読み出したＭＰＤデータまたはＳ３１にて読み出したリモートオブジェクトに含まれているＮ番目のピリオドの通常ピリオドを参照したＭ番目のＭＳのＵＲＬを特定し、特定したＵＲＬにアクセスすることによりＭ番目のＭＳを受信して記憶部１３０にバッファリングする。そして、再生部１２０は、記憶部１３０にバッファリングされたＭ番目のＭＳを再生する。
【０１００】
Ｓ３５の後、ストリーミング制御部１１０は、処理対象時刻変数Ｔに、Ｓ３５で再生されたＭＳの再生時間に相当するＤsの値を加算すると共に、変数Ｍに１を加算することによって処理対象ＭＳを更新し（Ｓ３６）、Ｓ３７に進む。
【０１０１】
Ｓ３７において、ストリーミング制御部１１０は、Ｔ＜Ｔuが成立するか否かを判定する。ストリーミング制御部１１０は、Ｔ＜Ｔuが成立しない（すなわち、ＭＰＤデータを再度取得すべき時刻になった）と判定した場合（Ｓ３７においてＮＯ）、Ｓ２２に戻る。
【０１０２】
一方、ストリーミング制御部１１０は、Ｔ＜Ｔuが成立すると判定した場合（Ｓ３７においてＹＥＳ）、当該ピリオドに再生対象ＭＳが存在するかを判定するため、Ｔ＜ＴN＋Ｄpが成立するか否かを判定する（Ｓ３８）。
【０１０３】
ストリーミング制御部１１０は、Ｔ＜ＴN＋Ｄpが成立すると判定した場合（Ｓ３８においてＹＥＳ）、Ｓ３５の処理に戻る一方、Ｔ＜ＴN＋Ｄpが成立しない（すなわち、次のピリオドのＭＳを再生すべき時刻となった）と判定した場合（Ｓ３８においてＮＯ）、変数Ｎに１を加算する（Ｓ３９）。
【０１０４】
Ｓ３９の後、ストリーミング制御部１１０は、Ｓ２３にて読み出したＭＰＤデータの中に、Ｎ番目のピリオドが含まれているか否かを判定する（Ｓ４０）。ストリーミング制御部１１０は、含まれていると判定した場合（Ｓ４０においてＹＥＳ）にはＳ２９に戻る一方、含まれていないと判定した場合（Ｓ４０においてＮＯ）には処理を終了する。
【０１０５】
（配信システム１の利点）
以上のように、配信システム１の配信サーバ３００は、ライブ再生を行うクライアント装置１００が取得すべきＭＳの所在を特定するためのメタ情報を含んでいるＭＰＤデータを、対象映像コンテンツがライブ配信されている間に繰り返し生成する。
【０１０６】
配信サーバ３００のメタデータ作成部３２０は、過去のピリオド（過去の所定の期間中に配信され、ライブ再生が終了したピリオド）に属する各ＭＳについて当該ＭＳのＵＲＬ（時分割データの所在を示す第１の資源位置指定子）を含むリモートオブジェクト（第１のメタデータ）を生成する。
【０１０７】
また、メタデータ作成部３２０は、上記複数のＭＳのうち、過去のピリオドに属する各ＭＳについては当該ＭＳのＵＲＬを含むリモートオブジェクトの所在を示すＵＲＬ（第２の資源位置指定子）を上記メタ情報として含み、その他のピリオドに属する各ＭＳについては当該ＭＳのＵＲＬを上記メタ情報として含んでいるＭＰＤデータ（第２のメタデータ）を生成する。
【０１０８】
また、配信システム１のクライアント装置１００では、ストリーミング制御部１１０が、ＭＰＤデータを取得する。取得したＭＰＤデータには、ライブ再生に必要なピリオドに属する各ＭＳについては、当該ＭＳのＵＲＬが含まれており、過去のピリオドについては、取得すべきＭＳのＵＲＬが含まれるリモートオブジェクトのＵＲＬが含まれており、タイムシフト再生のように過去のピリオドに含まれるＭＳの再生が必要となる場合には、ストリーミング制御部１１０が当該リモートオブジェクトを取得する。
【０１０９】
そして、再生部１２０は、取得したＭＰＤデータに基づいて、配信サーバ３００からＭＳを順次取得するとともに再生する。取得すべきＭＳのＵＲＬがＭＰＤデータに含まれていない場合には、ストリーミング制御部１１０がＭＰＤデータに記載されているリモートオブジェクトの所在を示すＵＲＬを参照して当該リモートオブジェクトを取得した後、当該リモートオブジェクトに記載されているＵＲＬを参照して取得すべきＭＳを受信し、再生部１２０が再生する。
【０１１０】
上記の構成により、配信システム１の配信サーバ３００は、クライアント装置１００が任意の再生位置でライブコンテンツのトリック再生を行うことを可能にするようなＭＰＤデータであって従来よりも配信効率の良いＭＰＤデータを生成することができる。
【０１１１】
また、クライアント装置１００は、そのようなＭＰＤデータを参照することにより、対象映像コンテンツのライブ再生および任意の再生開始位置からのトリック再生を行うことができる。
【０１１２】
〔実施形態２〕
本発明の別の一実施形態に係る配信システムについて図７〜図１２を参照しながら説明する。
【０１１３】
本実施形態に係る配信システムでは、配信サーバが、定期的に、古いＭＰＤデータを、ライブ再生に不要なピリオドに関する情報を含まないようなＭＰＤデータ（ライブ再生に必要十分な最低限のピリオドに関する情報を持つＭＰＤデータ）に更新するとともに、更新後のＭＰＤデータをクライアント装置に送信する点で実施形態１の配信サーバ３００とは異なっている。また、本実施形態に係る配信システムでは、クライアント装置が、配信サーバから新たに取得したＭＰＤデータと既に配信サーバから取得済または合成済のＭＰＤデータとを合成することにより、対象映像コンテンツの再生を完了するために必要なＭＰＤデータを獲得する点で、実施形態１のクライアント装置１００とは異なっている。
【０１１４】
最初に、本実施形態に係る配信システム１’の構成について図７および図８を参照しながら説明する。
【０１１５】
図７は、本実施形態に係るクライアント装置および配信サーバの全体構成を示した図であり、図８は、本実施形態に係る配信システム１’の全体構成を示した図である。また、図９は、配信サーバの各更新時における更新処理後のＭＰＤデータと、クライアント装置によるＭＰＤデータの各取得後における合成処理により獲得されるＭＰＤデータと、を例示している。
【０１１６】
図８に示すように、配信システム１’は、クライアント装置１００’と配信サーバ３００’とネットワークストレージサーバ（ＮＡＳ）４００とを含むシステムである。また、クライアント装置１００’および配信サーバ３００’は、インターネットＮＷに接続している。
【０１１７】
以下、クライアント装置１００’および配信サーバ３００’について説明するが、ＮＡＳ４００については実施形態１に係るＮＡＳ４００と同一であるので、その説明を省略する。
（クライアント装置１００’）
図１に示すように、クライアント装置１００’は、ストリーミング制御部１１０’、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および操作部１６０を備えている。再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および操作部１６０については実施形態１と同一であるので、ストリーミング制御部１１０’について以下に説明する。
（ストリーミング制御部１１０’）
ストリーミング制御部１１０’は、配信サーバ３００’によって定期的に更新されるＭＰＤデータを定期的に配信サーバ３００’から取得し、既に配信サーバ３００から取得済または合成済のＭＰＤデータと合成することにより、対象映像コンテンツに関する最新状態のＭＰＤデータを生成する。
【０１１８】
ストリーミング制御部１１０’は、最新状態のＭＰＤデータを参照することにより、対象映像コンテンツのうち再生対象となる部分を構成する各ＭＳを配信サーバ３００’が配信する（または、配信した）配信時刻を特定する。ＭＰＤデータにおける各ＭＳの配信開始時刻は、ライブ再生時における当該ＭＳの再生開始時刻も示していることから、ストリーミング制御部１１０’は、現在時刻（ライブ再生の場合）またはユーザ操作による指定時刻（トリック再生の場合）と各ＭＳについて特定した配信時刻とから、再生すべきＭＳのＵＲＬを特定し、そのＭＳを受信するためのＨＴＴＰ要求を配信サーバ３００’に送信する。
【０１１９】
ストリーミング制御部１１０は、配信サーバから受信したそのＭＳを記憶部１３０にバッファリングする。
（配信サーバ３００’）
配信サーバ３００’は、配信部３１０と、メタデータ作成部３２０’と、パラメータ制御部３３０と、を備えている。配信部３１０およびパラメータ制御部３３０は、それぞれ、実施形態１の配信部３１０およびパラメータ制御部３３０と同一であるので、その説明を省略する。
【０１２０】
メタデータ作成部３２０’は、その映像コンテンツのＭＰＤデータを繰り返し（本実施形態では１０分毎に）更新する。具体的には、メタデータ作成部３２０’は、各更新時において、ピリオドに関する情報としてはクライアント装置１００’がライブ再生を行うのに必要な最小限のピリオド情報（通常ピリオド）のみを含むようにＭＰＤデータを更新する。
【０１２１】
以上、本実施形態に係る配信システム１’の構成について説明した。
【０１２２】
以下では、本実施形態に係るクライアント装置１００’および配信サーバ３００’の各動作について図９〜図１２を参照しながら説明する。
【０１２３】
最初に、配信サーバ３００’におけるメタデータ作成部３２０’が、ＭＰＤデータの各更新時において、古いＭＰＤデータを、新しいＭＰＤデータ（すなわち、クライアント装置１００’がライブ再生を行うのに必要な最小限のピリオド情報のみを含むＭＰＤデータ）に更新する動作について図９および図１０を参照しながら説明する。
【０１２４】
図９は、ＮＡＳ４００およびクライアント装置１００’の記憶部１３０が保持するＭＰＤデータの一部を概略的に例示した図である。なお、図９における「…」の表記は、図３における「…」の表記と同様に意味を持っている。
【０１２５】
また、図９の左上段のＭＰＤデータ５ａは、配信開始時刻にＮＡＳ４００に保持されている初期のＭＰＤデータを示している。また、図９の左中段のＭＰＤデータ５ｂは、配信終了時刻が確定する前である配信開始１０分経過後にＮＡＳ４００に保持されるＭＰＤデータを示しており、左下段のＭＰＤデータ５ｃは、配信終了時刻が確定した時点である配信開始４０分経過後にＮＡＳ４００に保持されるＭＰＤデータを示している。
【０１２６】
さらに、図９の右上段のＭＰＤデータ５ａ、右中段のＭＰＤデータ５ｄ、右下段のＭＰＤデータ５ｅは、それぞれ、クライアント装置１００’が対応する左段のＭＰＤデータを配信サーバ３００’から取得し、必要に応じて合成処理を行った結果として記憶部１３０に記録される、その時点で最新状態のＭＰＤデータを示している。
【０１２７】
図１０は、メタデータ作成部３２０’の上記動作を示すフローチャート図である。なお、図１０における「Period＃Ｎ」、Ｄp、Ｔc、ＴaおよびＴeは、図４のフローチャート図と同様の意味を持っている。
【０１２８】
最初に、図１７に示すような、ＭＰＤ更新により変化しない共通要素のみからなるＭＰＤ初期ドキュメントを作成する（Ｓ４１）。
【０１２９】
次に、Ｓ４２において、対象映像コンテンツの配信終了時刻が確定しているか否かを判定する。
【０１３０】
対象映像コンテンツの配信終了時刻が確定していないと判定した場合には（Ｓ４２においてＹＥＳ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加する（Ｓ４３）。例えば、メタデータ作成部３２０’は、対象映像コンテンツの配信開始１０分経過後に図９（ｂ）のようなＭＰＤデータを作成する場合、その時点では配信終了時刻が確定してないため、属性「minimumUpdatePeriodMPD」を追加し、ＭＰＤデータの更新間隔Ｄpにあたる属性値「PT10M」を設定する。
【０１３１】
一方、対象映像コンテンツの配信終了時刻が確定したと判定した場合には（Ｓ４２においてＮＯ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加せずに、Ｓ４４に進む。例えば、対象映像コンテンツの配信終了時刻が確定した配信開始４０分経過後にＭＰＤデータを更新する際には、図９（ｃ）に示すように更新後のＭＰＤデータにおいて要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」は含まれないことになる。
【０１３２】
Ｓ４４において、処理対象時刻変数ＴをＴaに初期化するとともに、処理対象ピリオドが対象映像コンテンツの先頭から何番目のピリオドであるかを示す変数Ｎを１に初期化し、Ｓ４５に進む。
【０１３３】
Ｓ４５において、Ｔ＜Ｔcが成立するか否かを判定する。Ｔ＜Ｔcが成立すると判定された場合（Ｓ４５においてＹＥＳ）、Ｓ４８に進む。
【０１３４】
一方、Ｔ＜Ｔcが成立しないと判定した場合（Ｓ４５においてＮＯ）、Ｎ番目のピリオドに関する情報を生成するとともに（Ｓ４６）、ＭＰＤデータの一部として追加し（Ｓ４７）、Ｓ４８に進む。
【０１３５】
Ｓ４８において、変数Ｔの値にＤpを加算するとともに、変数Ｎの値に１を加算し、Ｓ４９に進む。
【０１３６】
Ｓ４９において、Ｔ＜Ｔeが成立するか否かを判定する。Ｔ＜Ｔeが成立すると判定した場合（Ｓ４９においてＹＥＳ）、Ｓ４５の処理に戻る。
【０１３７】
一方、Ｔ＜Ｔeが成立しないと判定した場合（Ｓ４９においてＮＯ）、古いＭＰＤデータをＳ４１〜Ｓ４９までの処理の結果として得られたＭＰＤデータに更新し、ＮＡＳ４００に記録し、処理を終了する。なお、クライアント装置１００’から要求されたタイミングに応じて、最新の状態に更新されたＭＰＤデータがＮＡＳ４００から読み出され配信部３１０により配信される。
【０１３８】
以上、メタデータ作成部３２０’の動作について説明したが、配信サーバ３００’が配信開始時刻から１０分経過後にＭＰＤデータ５ａをＭＰＤデータ５ｂに更新する処理を例に挙げて、Ｓ４５〜Ｓ４７の処理についてより詳細に説明する。
【０１３９】
この例では、Ｔcが配信開始時刻Ｔaから１０分経過時点を示す値（Ｔa＋Ｄp）となる。配信サーバ３００’がＳ４５のステップを最初に処理する時には、Ｎ＝１且つＴ＝Ｔaであるので、Ｔ＜Ｔcが成立すると判定する。したがって、更新後のＭＰＤデータ５ｂには、クライアント装置１００’がライブ再生を行うのに不要な１番目のピリオドに関する情報は含まれないことになる。
【０１４０】
一方、配信サーバ３００’がＳ４５のステップを２度目に処理する時には、Ｎ＝２且つＴ＝Ｔa＋Ｄpであるので、Ｔ＜Ｔcが成立しないと判定する。したがって、その直後のＳ４６、Ｓ４７の処理の結果、更新後のＭＰＤデータ５ｂには、クライアント装置１００’がライブ再生を行うのに必要な２番目のピリオドに関する情報が含まれることになる。
【０１４１】
次に、本実施形態に係るクライアント装置１００’が、配信サーバ３００’が配信する対象映像コンテンツを再生するための動作について、図９、図１１および図１２を参照しながら以下に説明する。
【０１４２】
図１１は、配信サーバ３００’により配信される対象映像コンテンツを再生するためのクライアント装置１００’の動作を示すフローチャート図である。また、図１２は、図１１１のフローチャートの１ステップをより詳細に示したフローチャート図である。なお、図１１および図１２におけるＤp、Ｄs、Ｔs、ＴuおよびＴNは、図６のフローチャート図と同様の意味を持っている。
【０１４３】
最初に、ストリーミング制御部１１０’は、再生処理開始に先立ち、処理対象時刻を表す変数ＴをＴsで初期化し、処理対象ピリオドを表す変数Ｎを１で初期化する（Ｓ６１）。
【０１４４】
Ｓ６２において、ストリーミング制御部１１０’は、配信サーバ３００’に対象映像コンテンツに関するＭＰＤデータを要求し、配信サーバ３００’からＭＰＤデータを受信し、記憶部１３０に記憶する。Ｓ６３において、ストリーミング制御部１１０’は、Ｓ６２の処理の前からすでに記憶部１３０に記録されているような、対象映像コンテンツに関するＭＰＤデータ（以下では「既存ＭＰＤ」とも称する）が存在するか否かを判定する。
【０１４５】
Ｓ６３において存在しないと判定された場合、Ｓ６５に進む。一方、Ｓ６３において存在すると判定された場合、Ｓ６４に進む。すなわち、Ｓ６２にて初期のＭＰＤデータ（例えば、図９の左上段のＭＰＤデータ５ａ）を受信した場合には、Ｓ６５に進み、Ｓ６２にて２度目以降のＭＰＤデータ（例えば、図９の左中段のＭＰＤデータ５ｂや左下段のＭＰＤデータ５ｃ等）を受信した場合には、Ｓ６４に進む。
【０１４６】
ストリーミング制御部１１０’は、Ｓ６２で受信され、記憶部１３０に記憶されたＭＰＤデータ（以下では「新規ＭＰＤ」とも称する）と、既存ＭＰＤとを合成し（Ｓ６４）、Ｓ６５の処理に進む。後に述べるように、Ｓ６４の合成処理の結果として得られるＭＰＤデータには、ライブ再生に必要十分なピリオドに関する情報とそれ以前のすべてのピリオドに関する情報とが含まれることになる。
【０１４７】
クライアント装置１００’は、Ｓ６５〜Ｓ８１について、クライアント装置１００のＳ２４〜Ｓ４０と同様の処理を行う。
【０１４８】
以下では、参照する図面を図９および図１２に変えて、Ｓ６４の合成処理の詳細について説明する。
【０１４９】
最初に、ストリーミング制御部１１０’は、新規ＭＰＤを読み出し（Ｓ６４１）。新規ＭＰＤの先頭から何番目のピリオドであるかを示す変数Ｌを１で初期化する（Ｓ６４２）。
【０１５０】
その後、Ｓ６４３において、ストリーミング制御部１１０’は、新規ＭＰＤのＬ番目のピリオドの属性「ｉｄ」の属性値と同じ属性値を持つピリオドが既存ＭＰＤに含まれているか否かを判定する。例えば、既存ＭＰＤが図９のＭＰＤデータ５ａであって新規ＭＰＤが図９のＭＰＤデータ５ｂである場合、ストリーミング制御部１１０’は、Ｌが１のとき（id=”2”のピリオド）は既存ＭＰＤに含まれていると判定し、Ｌが２のとき（id=”3”のピリオド）は既存ＭＰＤに含まれていないと判定する。
【０１５１】
ストリーミング制御部１１０’は、そのような情報が既存ＭＰＤに含まれていないと判定した場合（Ｓ６４３においてＮＯ）には、新規ＭＰＤに含まれているＬ番目のピリオドに関する情報を既存ＭＰＤに追加し（Ｓ６４４）、Ｓ６４５の処理に進む。一方、ストリーミング制御部１１０’は、そのような情報が既存ＭＰＤに含まれていると判定した場合（Ｓ６４３においてＹＥＳ）には、そのまま、Ｓ６４５の処理に進む。
【０１５２】
Ｓ６４５において、ストリーミング制御部１１０’は、Ｌの値に１を加算し、Ｓ６４６において、新規ＭＰＤにＬ番目のピリオドに関する情報が含まれているか否かを判定する。例えば、既存ＭＰＤが図９のＭＰＤデータ５ａであって新規ＭＰＤが図９のＭＰＤデータ５ｂである場合、ストリーミング制御部１１０’は、Ｌが１あるいは２のときは、当該ピリオドの情報が含まれていると判定し、Ｌが３のときは当該ピリオドに関する情報が含まれていないと判定する。当該例においては、この時点で、既存ＭＰＤが図９のＭＰＤデータ５ｄのようになっている。
【０１５３】
ストリーミング制御部１１０’は、新規ＭＰＤにＬ番目のピリオドに関する情報が含まれていると判定した場合（Ｓ６４６においてＹＥＳ）、Ｓ６４３の処理に戻る一方、そのような情報が含まれていないと判定した場合（Ｓ６４６においてＮＯ）、Ｓ６４７の処理に進む。
【０１５４】
Ｓ６４７では、ストリーミング制御部１１０’は、Ｓ６４１〜Ｓ６４６の処理で得られた合成後のＭＰＤデータの先頭から何番目のピリオドであるかを示す変数Ｋを１で初期化する。
【０１５５】
Ｓ６４８において、ストリーミング制御部１１０’は、Ｋ番目のピリオドが有効であるか否かを、新規ＭＰＤの属性「timeShiftBufferDepth」の属性値に基づいて判定する。属性「timeShiftBufferDepth」は、ライブストリーミング配信のみで有効な属性であり、配信サーバが各ＭＳについてＭＳの配信を開始してから破棄するまでの時間を示している。
【０１５６】
ストリーミング制御部１１０’は、具体的には、Ｋ番目のピリオドの開始時間（属性「start」の属性値）と属性「availabilityStartTime」の属性値とからＬ番目のピリオドの配信開始時刻を算出する。そして、ストリーミング制御部１１０’は、現在時刻からＫ番目のピリオドの配信開始時刻を引いた値が属性「timeShiftBufferDepth」の属性値以下である場合にＫ番目のピリオドが有効であると判定し、そうでない場合にはＫ番目のピリオドが無効であると判定する。例えば、既存ＭＰＤがＭＰＤデータ５ｄである場合には、１番目のピリオドから３番目のピリオドまでの各配信開始時刻はいずれも現在時刻から過去７日以内にあるので、３つのピリオドはすべて有効であると判定される。
【０１５７】
以上のＳ６４８の処理によってＫ番目のピリオドが有効であると判定した場合、ストリーミング制御部１１０’は、Ｓ６５０の処理に進む。一方、Ｋ番目のピリオドが無効であると判定した場合、ストリーミング制御部１１０’は、Ｋ番目のピリオドに関するピリオド情報を削除した上で（Ｓ６４９）、Ｓ６５０の処理に進む。
【０１５８】
Ｓ６５０において、ストリーミング制御部１１０’は、Ｋの値に１を加算し、Ｓ６５１において、既存ＭＰＤにＫ番目のピリオドに関する情報が含まれているか否かを判定する。
【０１５９】
ストリーミング制御部１１０’は、上記情報が含まれていると判定した場合（Ｓ６５１においてＹＥＳ）にはＳ６４８の処理に戻り、上記情報が含まれていないと判定した場合（Ｓ６５１においてＮＯ）には、Ｓ６４の処理を終了し、Ｓ６５の処理に進む。なお、ストリーミング制御部１１０’は、Ｓ６４６において「新規ＭＰＤにＬ番目のピリオドに関する情報が含まれていない」と判定した時点以降に新規ＭＰＤを破棄しても良い。
【０１６０】
（配信システム１’の利点）
以上のように、配信システム１’の配信サーバ３００’は、対象映像コンテンツのＭＰＤデータをクライアント装置１００’に繰り返し配信するが、ＭＰＤデータには配信時点を含む一定期間内に配信される各ＭＳについてのみ当該ＭＳのＵＲＬが含まれている。
【０１６１】
また、配信システム１’のクライアント装置１００’では、ストリーミング制御部１１０’が、配信サーバ３００’から上記ＭＰＤデータを取得する度に、取得したＭＰＤデータから新たなＭＰＤデータを生成し、再生部１２０が直前に生成したＭＰＤデータに基づいて取得すべきＭＳを順次取得するとともに再生する。
【０１６２】
具体的には、ストリーミング制御部１１０’は、直前に生成したＭＰＤデータ（既存ＭＰＤ）と新たに取得したＭＰＤデータ（新規ＭＰＤ）とを合成することにより、新たなＭＰＤデータを生成するが、合成により新たに生成されるＭＰＤデータには、既存ＭＰＤおよび新規ＭＰＤの少なくとも一方のＭＰＤに含まれている上記ＵＲＬがすべて含まれることになる。
【０１６３】
したがって、クライアント装置１００’が対象映像コンテンツを配信開始時点からライブ再生する場合には、クライアント装置１００’が生成するＭＰＤには、常に、現在配信され、または、過去に配信されたすべてのＭＳのＵＲＬが含まれることになる。
【０１６４】
以上のことから、配信システム１’では、クライアント装置１００’が、対象映像コンテンツのライブ再生および任意の再生開始位置からのトリック再生を行うことができる。
【０１６５】
〔実施形態の変形例について〕
（変形例１）
実施形態２の配信システム１’では、クライアント装置１００’が対象映像コンテンツの先頭のピリオドから始まるすべてのピリオドについてピリオドに関する情報を受信した場合に限り、任意の再生位置から対象映像コンテンツのトリック再生を行うことができる。換言すれば、配信システム１’のクライアント装置１００’は、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けた場合、任意の再生位置からトリック再生を行うことができないことがある。具体例について図１３を参照しながら説明する。
【０１６６】
図１３は、配信サーバ３００’がＭＰＤデータを更新するタイミングと、対象映像コンテンツの各ピリオドと、クライアント装置１００’−１、１００’−２がＭＰＤデータを取得するタイミングと、クライアント装置１００’−１、１００’−２が各ピリオドにおける映像を再生する期間とを模式的に示した図である。
【０１６７】
図１３において、水平方向は時間方向を示しており、左端は対象映像コンテンツの配信開始時刻を示している。配信サーバ３００’がＭＰＤデータを更新するタイミングは、図中における「配信サーバ」という文字列の水平右方向に位置する下向き矢印により表されている。また、対象映像コンテンツの各ピリオドは、図中における「対象映像コンテンツ」という文字列の水平右方向に位置する双方向矢印により表されている。なお、この双方向矢印の上方および下方のブレースは、各ピリオドに関する情報が含まれているＭＰＤデータを示している。さらに、各クライアント装置がＭＰＤデータを取得するタイミングおよび各クライアント装置が各ピリオドにおける映像を再生する期間は、それぞれ、図中における対応する「クライアント装置」という文字列の水平右方向に位置する下向き矢印および双方向矢印により表されている。
【０１６８】
図１３に示すように、クライアント装置１００’−１および１００’−２は、両方とも、対象映像コンテンツの配信開始時刻を過ぎてから再生指示を受け、ＭＰＤデータを取得している。
【０１６９】
クライアント装置１００’−１は、配信サーバ３００’において最初の更新がされる前に再生指示を受けているので、初期のＭＰＤデータ（ＭＰＤ１）を取得することができている。一方、クライアント装置１００’−２は、配信サーバ３００’において最初の更新がされた直後に再生指示を受けているので、初期のＭＰＤデータ（ＭＰＤ１）を取得することができていない。したがって、クライアント装置１００’−２は、１番目のピリオドに関する情報を取得できず、１番目のピリオドに属するような再生位置からトリック再生を行うことができない。
【０１７０】
任意の再生位置でトリック再生を行うことができるように、本発明は、実施形態２のクライアント装置１００’と実施形態１の配信サーバ３００とを組み合わせた配信システムとして実現してもよい。
【０１７１】
このように実現された配信システムでは、図１２に示したフローチャートに従う実施形態２の方法と略同様の方法で、クライアント装置１００’は、配信サーバ３００から受信した新規ＭＰＤと既存ＭＰＤとを合成することになる。
【０１７２】
その結果、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けたクライアント装置１００’が最初に取得するＭＰＤデータには、現在時刻が属するピリオド（「Ｐ番目のピリオド」とする）よりも前のピリオドについては外部参照ピリオドが含まれ、それ以降のピリオドについては通常ピリオドが含まれることになる。そして、クライアント装置１００’が２度目以降に取得した新規ＭＰＤと既存ＭＰＤとを合成して得られるＭＰＤデータには、常に、１〜Ｐ−１番目のピリオドについては外部参照ピリオドが含まれ、Ｐ番目以降のピリオドについては通常ピリオドが含まれることになる。
【０１７３】
したがって、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けた場合であっても、クライアント装置１００’は、実施形態１と同様に、任意の再生位置から対象映像コンテンツのトリック再生を行うことができる。また、実施形態１とは異なり、クライアント装置１００’は、トリック再生を開始する再生位置が属するピリオドが先頭からＰ番目以降のピリオドであれば、常に、リモートオブジェクトを参照することなくトリック再生を開始することができる。
【０１７４】
（変形例２）
クライアント装置が、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けた場合であっても、任意の再生位置からトリック再生を行うことができるように、以下のような配信システムとして本発明を実施してもよい。
【０１７５】
すなわち、クライアント装置１００’と、対象映像コンテンツのＭＰＤデータに対して定期的に更新処理１を実行していく一方、対象映像コンテンツのＭＰＤデータに対して定期的に更新処理２を実行していくような配信サーバと、を含むような配信システムとして、本発明を実施してもよい。
【０１７６】
この配信サーバは、具体的には、更新処理１と更新処理２とを同時に行うようになっている。また、この配信サーバは、最初の更新時には、同一内容の２つのＭＰＤデータ（初期のＭＰＤデータ）に対して、それぞれ、更新処理１と更新処理２とを実行するようになっている。
【０１７７】
配信サーバは、クライアント装置１００’からの対象映像コンテンツのＭＰＤデータの要求が初回の要求である場合には、更新処理１によって更新されたＭＰＤデータをクライアント装置１００’に返却し、２度目以降の要求である場合には、更新処理２によって更新されたＭＰＤデータをクライアント装置１００’に返却する。
【０１７８】
配信サーバは、クライアント装置１００’からのＭＰＤデータの要求が初回の要求であるか２度目以降の要求であるかを以下のように識別することができる。
【０１７９】
例えば、配信サーバは、クライアント装置１００’を特定可能な情報（例えばクライアント装置１００’のＩＤ情報）を含むようなクッキー情報を、クライアント装置１００’に保存させてもよい。すなわち、配信サーバは、クライアント装置１００’から上記クッキー情報を受信したか否かを判定し、受信していないと判定した場合には、初回の要求であると判定するとともに、上記クッキー情報をクライアント装置１００‘に保存させる。一方、配信サーバは、受信したと判定した場合には、２度目の要求であると判定する。
【０１８０】
また、例えば、配信サーバは、更新処理１によって更新されるＭＰＤデータのＵＲＬ情報（ＵＲＬ１）と、更新処理２によって更新されるＭＰＤデータのＵＲＬ情報（ＵＲＬ２）と、それぞれ、クライアント装置１００’に通知してもよい。２つのＵＲＬ情報は互いに異なっていればよい。すなわち、各ＭＰＤデータのファイル名を含むようなＵＲＬ情報であってもよいし、各ＭＰＤデータの保存先を互いに異なるフォルダにすることにより、２つのＵＲＬ情報を異ならせてもよい。この場合、クライアント装置１００’は、対象映像コンテンツのＭＰＤデータを初めて取得する場合には、ＵＲＬ１にアクセスし、取得するのが２度目以降である場合には、ＵＲＬ２にアクセスすればよい。なお、ＵＲＬ１についてはクライアント装置１００’に予め通知しておき、ＵＲＬ２については、ＵＲＬ１にアクセスすることによって取得されるＭＰＤデータ内（例えば、図１８に例示されているＭＰＤデータ内の点線の枠で囲まれた部分）に要素「Location」の要素値として記述する構成であってもよい。
【０１８１】
以上のような配信システムによっても、クライアント装置１００’は、配信サーバからＭＰＤデータを取得するたびに、Ｓ６４の合成処理によって任意の再生位置からトリック再生を行うことができるような最新状態のＭＰＤデータを得ることができる。
【０１８２】
（付記事項１）
以上の各実施形態では、配信サーバが対象映像コンテンツのＭＰＤデータと対象映像コンテンツ自体との両方を配信するものとしたが、ＭＰＤデータを配信する配信サーバと、対象映像コンテンツを配信する配信サーバとは異なるサーバであってもよい。また、各実施形態では、ＭＰＤデータを配信する配信サーバがＭＰＤデータの更新も行うものとしたが、ＭＰＤデータの配信とＭＰＤデータの更新とを異なるサーバが行ってもよい。また、ＭＰＤデータの更新を行うサーバ（生成装置）は、通信機能を備えている必要はない。すなわち、配信サービス事業者の担当者が、サーバで更新されたＭＰＤデータを、着脱可能な記録メディアを介して、手作業で、配信サーバに移動してもよく、上記ＭＰＤデータを、通信機能を備えた他の装置に手作業で移動した上で、配信サーバにアップロードしてもよい。
【０１８３】
（その他の付記事項）
メタデータ作成部３２０は、対象映像コンテンツの配信終了時刻が確定した後に既存のＭＰＤデータを属性「minimumUpdatePeriodMPD」を含まないようなＭＰＤデータに更新した後、ＭＰＤデータの定期的な更新を終了してもよいし、そのまま更新を定期的に続けても良い。また、実施形態１では、メタデータ作成部３２０が、過去のピリオドについてピリオド毎に異なるXMLファイルを生成するものとしたが、過去のピリオドに属する全MSのURL（１つの時分割データ群を構成する各時分割データ）を含むような１つのXMLファイルを生成してもよい。
【０１８４】
（プログラム、記憶媒体）
クライアント装置１００（１００’）および配信サーバ３００（３００’）の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
【０１８５】
後者の場合、クライアント装置１００（１００’）および配信サーバ３００（３００’）は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるクライアント装置１００（１００’） および配信サーバ３００（３００’）の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、クライアント装置１００（１００’） および配信サーバ３００（３００’）に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０１８６】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
【０１８７】
また、上記プログラムコードは、通信ネットワークを介してクライアント装置１００（１００’）および配信サーバ３００（３００’）に供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
【０１８８】
なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明だけではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【産業上の利用可能性】
【０１８９】
本発明に係る再生装置および生成装置は、コンテンツ配信システムなどに広く適用することができる。
【符号の説明】
【０１９０】
５ａ〜５ｅ ＭＰＤデータ
１００、１００’ クライアント装置（再生装置）
１１０、１１０’ ストリーミング制御部（第１の取得手段、第２の取得
手段、取得手段、生成手段）
１２０ 再生部（再生手段）
１３０ 記憶部
１４０ ネットワーク・Ｉ／Ｆ
１５０ 表示部
１６０ 操作部
３００、３００’ 配信サーバ（生成装置）
３１０ 配信部
３２０、３２０’ メタデータ作成部（第１の生成手段、第２の生成手段）
３３０ パラメータ制御部
４００ ネットワークストレージサーバ（ＮＡＳ）
【技術分野】
【０００１】
本発明は、配信サーバから取得したコンテンツデータを再生する再生装置および再生方法に関する。また、本発明は、コンテンツデータを再生するために再生装置が参照すべきメタデータを生成する生成装置および生成方法に関する。また、本発明は、そのような生成装置および再生装置を含む再生システムに関する。さらに、本発明は、そのような再生装置もしくは生成装置としてコンピュータを動作させる再生プログラムもしくは生成プログラム、並びに、そのような再生プログラムもしくは生成プログラムを記憶している記録媒体に関する。さらに、本発明は、再生装置がコンテンツデータを再生するために参照すべきメタデータのデータ構造に関する。
【背景技術】
【０００２】
近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等で構成されたＷＥＢページを見るだけでなく、動画コンテンツを鑑賞するユーザが増えてきている。
【０００３】
このような状況を踏まえ、例えば非特許文献１に記載の技術のような、動画コンテンツをストリーミング配信するための様々な技術が開発されているが、そのうちのひとつに、MPEG（Moving Picture Experts Group）にて現在標準化作業が進められているＤＡＳＨ(Dynamic Adaptive Streaming over HTTP)が挙げられる。
【０００４】
ＤＡＳＨでは、図１４に例示されているようなＭＰＤ（Media Presentation Description）データと、図１４のＭＰＤデータにおいてtsファイルとして例示されているメディアセグメントとの２つのフォーマットが規定されている。メディアセグメントは、動画コンテンツが時分割された、ＨＴＴＰ伝送の伝送単位である。また、ＭＰＤデータは、ストリーミング配信の制御メタデータであり、動画コンテンツがライブ配信されるコンテンツ（ライブコンテンツ）であるかＶＯＤコンテンツであるかを示す情報（図１４における属性「type」の属性値）を含んでいる。
【０００５】
また、ＭＰＤデータは、動画コンテンツの再生期間を区切った各ピリオドについて、動画コンテンツの配信開始時間を基準「０」とした場合のそのピリオドの開始時間を示す情報（図１４における属性「start」の属性値）とそのピリオドに属する各メディアセグメントのＵＲＬを示す情報（図１４における要素「BaseURL」の要素値および属性「sourceURL」の属性値）とを含んでいる。さらに、動画コンテンツがライブコンテンツである場合(属性「type」の属性値が“Live”である場合)には、ＭＰＤデータには配信サーバにおいて動画コンテンツのストリーミング配信が開始される時刻の情報（図１４における属性「availabilityStartTime」の属性値）が含まれるようになっている。
【０００６】
ＭＰＤデータは、クライアント装置が動画コンテンツの配信を受ける前に、クライアント装置が配信サーバから取得する。クライアント装置は、ＭＰＤデータに記載された各メディアセグメントのURLを基に、順次メディアセグメントを取得し、動画コンテンツの再生を行うことができる。また、非特許文献１の技術ではトリック再生を行うことができないが、ＤＡＳＨに準拠したクライアント装置は、ＭＰＤデータに取得可能な全てのメディアセグメントの情報が含まれているため、タイムシフト再生や早送り等のトリック再生を行うことができる。
【０００７】
ところで、ライブコンテンツには、配信が開始される前から配信終了時刻が確定している音楽番組のようなライブコンテンツと、プロ野球のナイター中継や災害発生時におけるニュース番組のように、配信が開始されてからも配信終了時刻が確定しないライブコンテンツとが存在する。
【０００８】
配信サーバは、前者のライブコンテンツを配信する場合には、配信終了時刻（すなわち、全ピリオド）が予め確定しているため、ライブコンテンツを構成する全メディアセグメントのＵＲＬを含むＭＰＤデータをクライアント装置に伝送することができる。したがって、クライアント装置は、ライブコンテンツの再生を開始する前に上記ＭＰＤデータを１回受信すれば、ライブコンテンツを最後まで再生することができる。
【０００９】
一方、配信サーバは、後者のライブコンテンツを配信する場合には、配信終了時刻が確定するまで、最終的に配信されることになる全メディアセグメントのＵＲＬを含むＭＰＤデータを生成し、クライアント装置に伝送することができない。したがって、クライアント装置は、配信終了時刻が確定していない時点で受信したＭＰＤデータのみでは、ライブコンテンツを最後まで再生することができない。
【００１０】
非特許文献２の技術では、後者のライブコンテンツを配信する場合において、クライアント装置がライブコンテンツを最後まで再生できるように、配信サーバが最新状態に更新されているＭＰＤデータをクライアント装置に定期的に伝送する「MPD Update」と呼ばれる処理が用いられる。なお、「MPD Update」では、タイムシフト再生や早送り等のトリック再生をサポートするか否によって、後述する２種類の処理方法（「更新処理１」、「更新処理２」）が存在する。
〔更新処理１〕
更新処理１では、配信サーバが、ＭＰＤデータを更新すべき各時点において前回のＭＰＤデータに対して後続するピリオドの情報を追加し、これにより最新状態に更新されているＭＰＤデータを、クライアント装置に定期的に伝送する。配信サーバのこのような更新処理の具体例について図１５を参照して以下に説明する。
【００１１】
図１５は、配信サーバがクライアント装置に伝送する一部のＭＰＤデータを概略的に例示した図である。図１５において、属性「minimumUpdatePeriodMPD」の属性値は、配信サーバがＭＰＤデータを更新する周期を示している。この属性値は、クライアント装置が配信サーバからＭＰＤデータを取得する周期でもあり、図１５の例では“１０分”である。図１５（ａ）は、配信開始時刻における初期のＭＰＤデータを示している。
【００１２】
この例では、配信サーバは、配信開始から１０分経過後に、ＭＰＤデータに対して開始時間が配信開始２０分後である後続のピリオドの情報を１つ追加する最初の更新を行い、その後１０分毎に、後続のピリオドの情報を１つ追加する。図１５（ｂ）は、配信開始から１０分経過後におけるＭＰＤデータを示しており、点線で囲まれた部分は、追加されたピリオドを示している。
【００１３】
これに対し、クライアント装置は、ライブコンテンツの再生中、属性「minimumUpdatePeriodMPD」の属性値が示す時間である１０分毎に、最新状態のＭＰＤデータを配信サーバから取得するとともに取得したＭＰＤデータに基づいてライブコンテンツの再生を継続する。
【００１４】
その後、配信サーバは、配信終了時刻が確定した時点で、残りのピリオドの情報を追加する。図１５（ｃ）は、配信終了時刻が確定した時点である配信開始から４０分経過後におけるＭＰＤデータを示しており、点線で囲まれた部分は、追加された残りのピリオドを示している。図１５（ｃ）に示すように、最終的に確定したＭＰＤデータでは、属性「minimumUpdatePeriodMPD」が削除されている。
【００１５】
クライアント装置は、取得したＭＰＤデータに属性「minimumUpdatePeriodMPD」が存在しないことをもって、定期的なＭＰＤデータの取得を終了すべきであると判断する。クライアント装置は、最終的に確定したＭＰＤデータに基づいてライブコンテンツを最後まで再生する。なお、図１５（ｃ）を見るとわかるように、最新状態のＭＰＤデータには、常に、最初のピリオドから現在時刻が属するピリオドまでの情報が含まれているため、クライアント装置は、常に、ライブコンテンツの先頭からトリック再生を行うことが可能である。
〔更新処理２〕
更新処理２は、配信サーバが、ＭＰＤデータを更新すべき各時点において前回のＭＰＤデータに対して後続するピリオドの情報を追加するとともに最も古いピリオドの情報を削除する処理であり、配信サーバは、これにより最新状態に更新されたＭＰＤデータを、クライアント装置に定期的に伝送する。
【００１６】
配信サーバのこのような更新処理２の具体例について図１６を参照して以下に説明する。
【００１７】
図１６は、この「ＭＰＤ Update」処理において、配信サーバがクライアント装置に伝送する一部のＭＰＤデータを概略的に例示した図である。図１６（ａ）は、配信開始時刻における初期のＭＰＤデータを示している。
【００１８】
この例では、配信サーバは、配信開始から１０分経過後に、ＭＰＤデータに対して開始時間が配信開始２０分後である後続のピリオドの情報を１つ追加するとともに開始時間が配信開始時点である最も古いピリオドの情報を削除する最初の更新を行う。図１６（ｂ）は、配信開始から１０分経過後におけるＭＰＤデータを示している。配信サーバは、その後１０分毎に、後続のピリオドの情報を１つ追加するとともにその時点で最も古いピリオドの情報を削除する。そして、配信サーバは、配信終了時刻が確定した時点である４０分経過後に、残りのピリオドの情報を追加する。図１６（ｃ）は、配信開始から４０分経過後におけるＭＰＤデータを示している。
【００１９】
クライアント装置は、更新処理２によって更新されたＭＰＤデータを受信する場合も、更新処理１によって更新されたＭＰＤデータを受信する場合と同様にライブコンテンツの再生を行う。なお、図１６（ｃ）からわかるように、更新処理２によって更新された最新状態のＭＰＤデータには、常に一定数のピリオドの情報しか含まれていないため、クライアント装置が受信するＭＰＤデータのデータ量は、常に、略一定となる。
【先行技術文献】
【非特許文献】
【００２０】
【非特許文献１】“HTTP Live Streaming”、[online]、２０１１年３月、［２０１１年６月３日検索］、Apple Inc.、インターネット<http://tools.ietf.org/html/draft-pantos-http-live-streaming-06>
【非特許文献２】“Information technology-MPEG systems technologies - Part6:Dynamic Adaptive streaming over HTTP(DASH)”、[online]、２０１１年１月２８日、[２０１１年６月３日検索]、ISO/IEC、インターネット<http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11873t.doc>
【発明の概要】
【発明が解決しようとする課題】
【００２１】
配信サーバが、定期的に、上記更新処理１によって更新した最新状態のＭＰＤをクライアント装置に伝送する場合には、クライアント装置は、すでに取得済のピリオドに関する情報を何度も受信することになる。また、配信サーバからストリーミング配信されているライブコンテンツを鑑賞しているユーザの多くは鑑賞中に一度もタイムシフト再生機能を使用しないと考えられる。タイムシフト再生を行わない多くのクライアント装置は、そのようなクライアント装置にとっては非常に冗長な情報量を持つＭＰＤデータを受信してしまうことになる。
【００２２】
したがって、上記更新処理１によって更新したＭＰＤデータを配信するのは、ＭＰＤデータの配信効率が良いとは言えない。
【００２３】
一方、配信サーバが、定期的に、上記更新処理２によって更新した最新の状態のＭＰＤデータをクライアント装置に伝送する場合、更新のたびにその時点で最も古いピリオドの情報がＭＰＤデータから削除されてしまうため、クライアント装置は、現在時刻から過去に遡った一定範囲内の再生位置でしかタイムシフト再生を行うことができないという問題がある。
【００２４】
本発明は、上記課題に鑑みて成されたものであり、その主な目的は、再生装置が任意の再生位置でライブコンテンツのトリック再生を行うことを可能にするＭＰＤデータ（より一般的にはライブ配信を制御するメタデータ）であって従来よりも配信効率の良い（データ量の小さい）ＭＰＤデータ（メタデータ）を生成可能な生成装置および生成方法を実現することにある。
【００２５】
また、そのような生成装置によって生成されたＭＰＤデータ（メタデータ）に基づいて、ライブ配信されたコンテンツを再生する再生装置および再生方法を実現すること、および、そのようなＭＰＤデータ（メタデータ）のデータ構造を提供することも本発明の目的の範疇に含まれる。
【課題を解決するための手段】
【００２６】
本発明に係る生成装置は、複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置において、過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成手段と、上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについて、その所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成手段と、を備えていることを特徴としている。ここで、上記第２の生成手段は、過去に生成した第２のメタデータを編集することによって第２のメタデータを生成してもよいし、過去に生成した第２のメタデータとは独立に第２のメタデータを生成してもよい。
【００２７】
上記の構成によれば、本発明に係る生成装置が生成する第２のメタデータには、現在配信されている時分割データの所在を示す第１の資源位置指定子が含まれている。また、上記第２のメタデータには、過去に配信された上記複数の時分割データの各々について、当該時分割データの所在を示す第１の資源位置指定子が含まれているか、あるいは、当該時分割データの所在を示す第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子が含まれている。そして、第２のメタデータを取得した上記再生装置は、現在配信され、あるいは、過去に配信された、任意の時分割データの所在を特定することができる。
【００２８】
したがって、本発明に係る生成装置は、ライブコンテンツをライブ再生している再生装置が任意の位置でトリック再生することができるような第２のメタデータを生成することになる。
【００２９】
また、一般的に、第２の資源位置指定子のデータサイズは、第２の資源位置指定子により所在が示される第１のメタデータに含まれる各第１の資源位置指定子のデータサイズの総和よりも小さいことは明らかであるので、現在配信され、または、過去に配信された上記複数の時分割データの各々について当該時分割データの第１の資源位置指定子を含むような、従来の装置が生成するメタデータよりも、上記第２のメタデータのデータサイズは小さくなる。さらに、トリック再生を行わない再生装置は、過去に配信された時分割データを取得しないので第１のメタデータを取得することはない。
【００３０】
したがって、トリック再生を行わない再生装置にとっては従来よりもメタデータの配信効率が良くなる。
【００３１】
以上のことから、本発明に係る生成装置は、再生装置が任意の再生位置でライブコンテンツのトリック再生を行うことを可能にする、ライブ配信されるコンテンツデータに関するメタデータであって従来よりも配信効率の良いメタデータを生成することができる。
【００３２】
本発明に係る生成方法は、複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置の生成方法において、過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成工程と、上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成工程と、からなる生成工程を繰り返すことを特徴としている。
【００３３】
上記の構成によれば、本発明に係る生成方法は、本発明に係る生成装置と同様の作用効果を奏する。
【００３４】
なお、上記ライブ配信で用いるメタデータのデータフォーマットおよびメディアセグメントのデータフォーマットは、ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）に準拠したデータフォーマットであり、上記時分割データはメディアセグメントであり、上記第１のメタデータはリモートオブジェクトであって上記第２のメタデータは上記コンテンツデータに関するＭＰＤデータであり、上記第１の資源位置指定子は上記メディアセグメントのＵＲＬであって上記第２の資源位置指定子は上記リモートオブジェクトのＵＲＬである、ことが望ましい。また、上記コンテンツデータと上記コンテンツデータに関するメタデータとを上記再生装置に配信する配信サーバであって上記生成装置としても機能する配信サーバとして本発明を実現することが望ましい。
【００３５】
本発明に係る生成装置は、上記コンテンツデータが、配信開始時刻には配信終了時刻が確定していないコンテンツデータであり、上記第２の生成手段が、上記配信終了時刻が確定した後に上記第２のメタデータを生成する場合には、上記第２のメタデータとして、上記配信開始時刻から上記配信終了時刻までに配信される全時分割データについて上記メタ情報を含むような第２のメタデータを生成することが望ましい。
【００３６】
上記の構成によれば、本発明に係る生成装置は、再生装置に配信開始時刻には配信終了時刻が確定していないコンテンツデータを最後まで再生させることができるようなメタデータを生成することができるというさらなる効果を奏する。
【００３７】
さらに、本発明に係る生成装置では、上記過去の所定の期間が、上記第２の生成手段が上記第２のメタデータを生成する時点を含む一定期間よりも過去の全期間であることが望ましい。
【００３８】
上記の構成によれば、本発明に係る生成装置が繰り返し生成する第２のメタデータには、生成された時点を含む上記一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す第１の資源位置指定子が含まれることになる。換言すれば、本発明に係る生成装置が生成する第２のメタデータのデータサイズは生成の度にそれほど大きく増えるわけではないと言える。
【００３９】
したがって、本発明に係る生成装置は、より配信効率の良いメタデータを生成することができるというさらなる効果を奏する。
【００４０】
本発明に係る再生装置は、上記課題を解決するために、配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含むような、第１のメタデータを取得する第１の取得手段と、上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を含んでいる第２のメタデータを取得する第２の取得手段と、上記第２のメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、上記再生手段が、取得すべき時分割データの第１の資源位置指定子が上記第２のメタデータに含まれていない場合には、第２の資源位置指定子を参照して当該第１の資源位置指定子を含む第１のメタデータを取得するとともに当該第１の資源位置指定子を参照して当該時分割データを取得する、ことを特徴としている。
【００４１】
上記の構成によれば、本発明に係る再生装置が取得する第１のメタデータおよび第２のメタデータは、それぞれ、本発明に係る生成装置が生成する第１のメタデータおよび第２のメタデータと同じものである。また、上記再生装置は、ライブ再生の指示を受け付けた時点で再生のために取得すべき時分割データを第２の資源位置指定子を参照することにより取得することができ、トリック再生の指示を受け付けた時点で再生のために取得すべき時分割データを、第１の資源位置指定子および第２の資源位置指定子のいずれかを参照することにより取得することができる。
【００４２】
したがって、本発明に係る再生装置は、本発明に係る生成装置によって生成されたメタデータに基づいて、ライブ配信されたコンテンツを再生することができる。
【００４３】
本発明に係る再生装置は、上記課題を解決するために、配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得手段と、上記取得手段がメタデータを取得する度に当該メタデータから新たなメタデータを生成する生成手段と、上記生成手段が直前に生成した新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、上記生成手段が、当該生成手段が直前に生成したメタデータおよび上記取得手段が新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する、ことを特徴としている。
【００４４】
上記の構成によれば、本発明に係る再生装置は、過去に取得したメタデータに含まれていたすべての資源位置指定子を含むようなメタデータを新たなメタデータとして生成する。
【００４５】
したがって、本発明に係る再生装置は、配信開始時点からコンテンツデータの再生を開始していれば、現在配信され、または、過去に配信されたすべてのメディアセグメントについてその所在を示す資源位置指定子を含むようなメタデータを生成するので、当該メタデータに基づいてライブコンテンツのライブ再生および任意の再生位置でのトリック再生を行うことができる。
【００４６】
また、本発明に係る再生装置が取得するメタデータは、ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含んでいる。
【００４７】
したがって、本発明に係る再生装置は、ライブコンテンツのライブ再生および任意の再生位置でのトリック再生を行うために取得すべきメタデータを従来よりも効率良く取得することができる。
【００４８】
本発明に係る再生装置は、上記課題を解決するために、配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置の再生方法において、ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得工程と、上記取得工程にてメタデータが取得される度に当該メタデータから新たなメタデータを生成する生成工程と、直前の上記生成工程にて生成された新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生工程と、を含み、上記生成工程は、当該生成工程の直前の生成工程にて生成されたメタデータおよび上記取得工程にて新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する工程であることを特徴としている。
【００４９】
上記の構成によれば、本発明に係る再生方法は、本発明に係る再生装置と同様の作用効果を奏する。
【００５０】
なお、上記ライブ配信で用いられる上記時分割データはＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）に準拠したメディアセグメントである、ことが望ましい。
【００５１】
本発明に係る生成装置と再生装置とを含む再生システムも本発明の範疇に含まれる。
【００５２】
また、本発明に係る生成装置または再生装置としてコンピュータを動作させるプログラムであって、コンピュータを上記生成装置または上記再生装置の各手段として機能させることを特徴とするプログラム、および、そのようなプログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。
【００５３】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータのデータ構造において、上記メタデータに含まれる、所定の期間における時分割データ群の所在を特定するためのメタ情報のデータ構造が、上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含むようなメタデータの所在を示す第２の資源位置指定子を上記メタ情報として含む第１のデータ構造、および、上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を上記メタ情報として含む第２のデータ構造のうち、上記コンテンツデータのライブ配信が開始されてからの経過時間に応じて選択されたデータ構造となっていることを特徴とするメタデータのデータ構造に係る発明も本発明の範疇に含まれる。
【発明の効果】
【００５４】
以上のように、本発明の生成装置および生成方法は、再生装置が任意の再生位置でトリック再生することを可能にする、ライブ配信されるコンテンツデータに関するメタデータであって従来よりも配信効率の良いメタデータを生成することができる。
【００５５】
また、本発明の再生装置および再生方法は、本発明の生成装置によって生成されたＭＰＤデータに基づいてライブコンテンツを再生することができる。
【図面の簡単な説明】
【００５６】
【図１】本発明の実施形態に係るクライアント装置および配信サーバの構成を示した図である。
【図２】本発明の実施形態に係る配信システムの全体構成を示した図である。
【図３】図１のクライアント装置が参照するＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）データの一例を概略的に示した図である。
【図４】図１の配信サーバが備えるメタデータ作成部が定期的にＭＰＤデータを更新する動作の一実施形態を示すフローチャートである。
【図５】図１のクライアント装置が参照するリモートオブジェクトの一例を概略的に示した図である。
【図６】図１のクライアント装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図７】本発明の別の一実施形態に係るクライアント装置および配信サーバの構成を示した図である。
【図８】本発明の別の一実施形態に係る配信システムの全体構成を示した図である。
【図９】図７の配信サーバが図７のクライアント装置に配信するＭＰＤデータおよび図７のクライアント装置が生成するＭＰＤデータの一例を概略的に示した図である。
【図１０】図７の配信サーバが備えるメタデータ作成部が定期的にＭＰＤデータを更新する動作の一実施形態を示すフローチャートである。
【図１１】図７のクライアント装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図１２】図１１のフローチャートにおける１ステップについてより詳細な処理の流れに示したフローチャートである。
【図１３】図７の配信サーバが映像コンテンツのＭＰＤデータを更新するタイミングと、その映像コンテンツの各ピリオドと、クライアント装置がＭＰＤデータを取得するタイミングと、クライアント装置が各ピリオドの映像を再生する期間と、の時間的関係を模式的に示した図である。
【図１４】ＭＰＤデータの一例を概略的に示した図である。
【図１５】従来技術を示すものであり、ＭＰＤ Ｕｐｄａｔｅにより更新されるＭＰＤデータの一例を概略的に示した図である。
【図１６】従来技術を示すものであり、ＭＰＤ Ｕｐｄａｔｅにより更新されるＭＰＤデータの別の一例を概略的に示した図である。
【図１７】ＭＰＤ初期データの一例を示した図である。
【図１８】図７のクライアント装置が参照するＭＰＤデータの一例を概略的に示した図である。
【発明を実施するための形態】
【００５７】
〔実施形態１〕
本発明の一実施形態に係る配信システムは、配信開始時点では配信終了時刻が確定しないスポーツ中継のような映像コンテンツをクライアント装置にライブストリーミング配信する配信システムである。なお、当該システムでは、メタデータおよびメディアセグメントに前述のＤＡＳＨ規定のデータフォーマットを用いる。
【００５８】
本実施形態に係る配信システムについて図１〜図６を参照しながら説明する。
【００５９】
図１は、本実施形態に係るクライアント装置および配信サーバの全体構成を示した図であり、図２は、本実施形態に係る配信システム１の全体構成を示した図である。
【００６０】
図２に示すように、配信システム１は、クライアント装置１００と配信サーバ３００とネットワークストレージサーバ（ＮＡＳ）４００とを含むシステムである。また、クライアント装置１００および配信サーバ３００は、インターネットＮＷに接続している。
【００６１】
以下、クライアント装置１００、配信サーバ３００、およびＮＡＳ４００について説明する。
（クライアント装置１００）
図１に示すように、クライアント装置１００は、ストリーミング制御部１１０、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および操作部１６０を備えている。
【００６２】
クライアント装置１００は、操作部１６０を介して映像コンテンツの再生指示をユーザから受け付けると、そのライブ再生すべき映像コンテンツ（以下では、再生指示を受け付けた映像コンテンツを「対象映像コンテンツ」とも称する）を、配信サーバ３００からメディアセグメント（映像コンテンツの符号化データを一定時間ごとに分割して得られる各単位、以下、「ＭＳ」とも称する）単位で受信して再生する。
【００６３】
具体的には、クライアント装置１００は、再生指示を受け付けた時点で対象映像コンテンツに関するＭＰＤデータ（第２のメタデータ）を配信サーバ３００から受信することにより、対象映像コンテンツを再生するために受信すべきＭＳのＵＲＬ（第１の資源位置指定子）を特定し、配信開始時刻になると、ＵＲＬで指定される配信サーバ３００からＭＳを受信して対象映像コンテンツの再生を開始する。また、クライアント装置１００は、対象映像コンテンツの再生中にも定期的に配信サーバ３００からＭＰＤデータを取得する。そして、クライアント装置１００は、対象映像コンテンツの再生中は常に、最後に取得したＭＰＤデータに基づいて、対象映像コンテンツの再生を継続するのに必要なＭＳを受信する。
（ストリーミング制御部１１０）
ストリーミング制御部１１０は、配信サーバ３００から定期的にその時点で最新状態のＭＰＤデータを取得する。
【００６４】
ストリーミング制御部１１０は、最新状態のＭＰＤデータおよび必要に応じて後述するリモートオブジェクトを参照することにより、対象映像コンテンツのうち再生対象となる部分を構成する各ＭＳの配信開始時刻を特定する。ＭＰＤデータにおける各ＭＳの配信開始時刻は、ライブ再生時における当該ＭＳの再生開始時刻も示していることから、ストリーミング制御部１１０は、現在時刻（ライブ再生の場合）またはユーザ操作による指定時刻（トリック再生の場合）と各ＭＳについて特定した配信開始時刻とから、再生すべきＭＳのＵＲＬを特定し、そのＭＳを受信するためのＨＴＴＰ要求を配信サーバ３００に送信する。
【００６５】
ストリーミング制御部１１０は、配信サーバ３００から受信したＭＳを記憶部１３０にバッファリングする。
（再生部１２０）
再生部１２０は、再生すべき時刻の早い順に、記憶部１３０にバッファリングされているＭＳを読み出してデコードおよび再生を行うことにより、対象映像コンテンツを表示部１５０に表示する。
（記憶部１３０）
記憶部１３０は、対象映像コンテンツを構成する各ＭＳをバッファリングし、対象映像コンテンツに関するＭＰＤデータを記憶するための記録媒体である。
（ネットワークＩ／Ｆ１４０）
ネットワークＩ／Ｆ１４０は、サーバ３００との間でデータの送受信を行う。
（表示部１５０）
表示部１５０は、対象映像コンテンツを表示するディスプレイである。
（操作部１６０）
操作部１６０は、クライアント装置１００に対する指示をユーザが行うための操作パネルである。
（配信サーバ３００）
配信サーバ３００は、配信部３１０と、メタデータ作成部３２０と、パラメータ制御部３３０と、を備えている。
【００６６】
映像コンテンツの配信開始時刻になると、対象映像コンテンツを構成する映像をＭＳ単位で順次、ライブエンコーダ（図示せず）がエンコードし、ＮＡＳ４００に記録する。これと並行して、メタデータ作成部３２０は、その映像コンテンツのＭＰＤデータを繰り返し（本実施形態では１０分毎に）生成し、最新状態に更新するとともに後述するリモートオブジェクト（第１のメタデータ）を生成する。
【００６７】
パラメータ制御部３３０は、配信サービス事業者の担当者の指示内容に基づいて、メタデータ作成部３２０がＭＰＤデータを生成するために参照する各種パラメータを制御する。
【００６８】
また、配信部３１０は、クライアント装置１００からＭＰＤデータの要求を受けると、ＮＡＳ４００に記録されているその時点で最新の状態のＭＰＤデータをクライアント装置１００に送信する。そして、配信サーバ３００は、クライアント装置１００からＭＳのＨＴＴＰ要求を受けると、ＮＡＳ４００に記録された該ＭＳをクライアント装置１００に配信する。
（ＮＡＳ４００）
ＮＡＳ４００は、映像コンテンツを構成する各ＭＳ、映像コンテンツに関するＭＰＤデータ、および後述するリモートオブジェクトを保持するネットワークストレージである。
（ＭＰＤデータについて）
次に、上述したＭＰＤデータについて図３を参照しながら以下に説明する。図３は、ＮＡＳ４００が保持しており、クライアント装置１００が受信すべきＭＳを特定するために参照するＭＰＤデータの一部を概略的に例示した図である。なお、図３におけるピリオドの開始タグと終了タグとの間に囲まれた範囲の「…」の表記は、当該部分に非特許文献２に記載されているようなグループ、リプレゼンテーション、ＭＳ等に関する情報が含まれていることを意味している。すなわち、「…」の部分には相当なバイトサイズのデータが含まれている。
【００６９】
図３（ａ）は、配信開始時刻における初期のＭＰＤデータを示している。また、図３（ｂ）は、配信終了時刻が確定する前である配信開始１０分経過後におけるＭＰＤデータを示しており、図３（ｃ）は、配信終了時刻が確定した時点である配信開始４０分経過後におけるＭＰＤデータを示している。
【００７０】
図３（ｂ）および図３（ｃ）を見るとわかるように、更新後のＭＰＤデータの要素「Period」には、属性値がリモートオブジェクトの所在を示すURL（第２の資源位置指定子）である属性「href」を含んでいるもの（図中において点線の枠で囲まれた部分。以下では、そのような要素「Period」を「外部参照ピリオド」とも称することにする）とそのような属性「href」を含んでおらず、要素値に当該ピリオドを構成するＭＳの所在を示すURL（第１の資源位置指定子）を含むもの（以下では、そのような要素「Period」を「通常ピリオド」とも称することにする）と、が存在することがわかる。また、外部参照ピリオド（第１のデータ構造）の要素値は空であり、通常ピリオド（第２のデータ構造）に比べ、当該ピリオドに関する情報のデータサイズは非常に小さくなっていることがわかる。
（ＭＰＤデータの生成動作について）
次に、メタデータ作成部３２０が、ＭＰＤデータの各更新時において、最新状態のＭＰＤデータを生成する動作について図３〜図５および図１７を参照しながら説明する。
【００７１】
図４は、メタデータ作成部３２０の上記動作を示すフローチャート図である。なお、図４の動作フロー開始にあたり、メタデータ作成部３２０には、パラメータ制御部３３０から以下のパラメータが入力されるものとする。
update：当該ＭＰＤデータの次回更新が必要であれば「true」であり、対象映像コンテンツの配信終了時刻が確定しており、次回更新の必要がなければ「false」である。なお当該パラメータは、例えば、図示しない操作部を介して配信サービス事業者の担当者から配信終了時刻が確定した旨を示す情報を受け取り済みの場合に、falseに設定される。
Ｄp:１つのピリオドに属する対象映像コンテンツの再生時間（１つのピリオドに含められるＭＳの総再生時間）。図３のＭＰＤデータを生成する場合、「１０分」である。
Ｔa:対象映像コンテンツの配信開始時刻（対象映像コンテンツのライブ再生開始時刻）。
Ｔc:当該ＭＰＤデータ生成時刻（現在時刻）。
Ｔe:当該ＭＰＤデータに含める必要のあるピリオドを決定するための閾値。
【００７２】
最初に、図１７に示すような、ＭＰＤ更新により変化しない共通要素のみからなるＭＰＤ初期ドキュメントを作成する（Ｓ１）。
【００７３】
次に、Ｓ２において、対象映像コンテンツの配信終了時刻が確定しているか否かを判定する。対象映像コンテンツの配信終了時刻が確定していないと判定した場合には（Ｓ２においてＹＥＳ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加する（Ｓ３）。例えば、メタデータ作成部３２０は、対象映像コンテンツの配信開始１０分経過後に図３（ｂ）のようなＭＰＤデータを作成する場合、その時点では配信終了時刻が確定してないため、属性「minimumUpdatePeriodMPD」を追加し、ＭＰＤデータの更新間隔Ｄpにあたる属性値「PT10M」を設定する。
【００７４】
一方、対象映像コンテンツの配信終了時刻が確定したと判定した場合には（Ｓ２においてＮＯ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加せずに、Ｓ４に進む。例えば、対象映像コンテンツの配信終了時刻が確定した配信開始４０分経過後にＭＰＤデータを更新する際には、図３（ｃ）に示すように更新後のＭＰＤデータにおいて要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」は含まれないことになる。
【００７５】
Ｓ４において、処理対象時刻変数ＴをＴaに初期化するとともに、処理対象ピリオドが対象映像コンテンツの先頭から何番目のピリオドであるかを示す変数Ｎを１に初期化する。
【００７６】
Ｓ５において、Ｎ番目のピリオドに関する情報を通常のピリオドとして生成し、Ｓ６に進む。Ｓ６において、メタデータ作成部３２０は、Ｔ＜Ｔcが成立するか否かを判定する。メタデータ作成部３２０がＴ＜Ｔcが成立しないと判定した場合（Ｓ６においてＮＯ）、Ｓ９に進む。
【００７７】
一方、Ｔ＜Ｔcが成立すると判定した場合（Ｓ６においてＹＥＳ）、Ｓ５で生成した通常ピリオドをリモートオブジェクトとしてＮＡＳ４００に出力し（Ｓ７）、Ｓ８に進む。なお、Ｎ番目のピリオドのリモートオブジェクトは、図５に示す例のように、ＭＰＤデータや他のリモートオブジェクトとは別にＮＡＳ４００に記録される。本動作例では、Ｎ番目のピリオドのリモートオブジェクトは、ファイル名が「pN.xml」（Nは数値であり、例えば、N=1の場合「p1.xml」である。以下「pN.xml」の記載を同様の意味で用いる）であるＸＭＬファイルとして記録される。
【００７８】
Ｓ８において、Ｓ７で生成したリモートオブジェクトを参照する外部参照ピリオドを生成し、Ｓ９に進む。
【００７９】
Ｓ９において、Ｎ番目のピリオドに関して直近で生成したピリオド情報（直前のステップがＳ８である場合にはＳ８において生成した外部参照ピリオドであり、直前のステップがＳ６である場合にはＳ５で生成した通常ピリオド）を、生成すべきＭＰＤデータの一部として追加する。
【００８０】
Ｓ１０において、次のピリオドの処理のため、変数ＴにＤpの値を加算するとともに、変数Ｎに１を加算し、Ｓ１１に進む。
【００８１】
Ｓ１１において、Ｔ＜Ｔeが成立するか否かを判定する。Ｔ＜Ｔeが成立すると判定した場合（Ｓ１１においてＹＥＳ）、未処理のピリオドについてピリオド情報を生成するため、Ｓ５に戻る。一方、Ｔ＜Ｔeが成立しないと判定した場合（Ｓ１１においてＮＯ）、当該ＭＰＤデータに記載する必要のあるピリオド情報の生成が完了し、Ｓ１２に進む。
【００８２】
Ｓ１２において、Ｓ１〜Ｓ１１までの処理によって作成したＭＰＤデータ（すなわち、更新により最新状態となったＭＰＤデータ）をＮＡＳ４００に記録し、処理を終了する。なお、クライアント装置１００から要求されたタイミングに応じて、最新の状態に更新されたＭＰＤデータがＮＡＳ４００から読み出され配信部３１０により配信される。
【００８３】
以上、メタデータ作成部３２０が行うＭＰＤデータの更新処理動作について説明したが、以上の更新処理動作により、対象映像コンテンツの配信終了時刻が確定した後に更新されたＭＰＤデータには、対象映像コンテンツを構成するすべてのピリオドについて、外部参照ピリオドまたは通常ピリオドが含まれることになる。したがって、配信サーバ３００は、クライアント装置１００から要求されたタイミングが配信終了時刻確定後におけるＭＰＤデータの更新後である場合には、対象映像コンテンツを構成するすべてのピリオドのピリオド情報を含むＭＰＤデータをＮＡＳ４００から読み出して配信することになる。
【００８４】
なお、ＭＰＤデータを生成する際、ＭＰＤの更新間隔をピリオドの再生時間Ｄpとすることで、ＴcをＮ番目のピリオドの再生開始時刻と一致させることができ、外部参照ピリオドとして生成される１〜Ｎ−１番目のピリオドだけでなく、通常ピリオドとして生成さるＮ番目のピリオド以降にもライブ再生に不要なＭＳのＵＲＬは一切含まれない。また、閾値Ｔeを、Updateがtrueの場合には、Ｔe＝Ｔc＋2Ｄpとし、,Updateがfalseの場合には、Ｔe＝「当該映像コンテンツの配信終了時刻」とすることで、当該ＭＰＤデータには、任意のクライアント装置１００が最新のＭＰＤデータを取得した時点から、次回MPDデータの取得までの期間（つまり属性「minimumUpdatePeriodMPD」で示される期間）にライブ配信およびライブ再生されるＭＳのＵＲＬのみを含めることができる。言い換えれば、ライブ再生を行うのに必要な最小限の通常ピリオドを含む配信効率の高いＭＰＤデータを生成することができる。
【００８５】
以下では、操作部１６０を介して再生指示を受け付けたクライアント装置１００が、配信サーバ３００が配信する対象映像コンテンツを再生するための動作について、図３、図５および図６を参照しながら説明する。
【００８６】
図６は、クライアント装置１００の上記動作を示すフローチャート図である。なお、図６において、Ｔsは、操作部１６０を介したユーザ操作による再生指示によって決定される再生開始位置を示す入力パラメータである。Ｔsは、再生指示がライブ再生の場合においては現在時刻を示しており、再生指示がトリック再生の場合においては、再生指示に基づく指定時刻を示している。
【００８７】
また、Ｄpは、ピリオドに属する対象映像コンテンツの再生時間（ＭＰＤデータの要素「Period」における属性「duration」の属性値として、あるいは、連続する２つの要素「Period」における各属性「start」の属性値の差として得られる）を示しており、Ｄsは１つのＭＳが継続して再生される期間（ＭＰＤデータの要素「SegmentInfo」における属性「duration」の属性値として得られる）を示している。
【００８８】
最初に、ストリーミング制御部１１０は、再生処理開始に先立ち、処理対象時刻を表す変数ＴをＴsで初期化し、処理対象を示す変数Ｎを１で初期化する（Ｓ２１）。
【００８９】
Ｓ２２において、ストリーミング制御部１１０は、配信サーバ３００にＭＰＤデータを要求し、配信サーバ３００からＭＰＤデータを受信し、記憶部１３０に記憶する。Ｓ２３において、ストリーミング制御部１１０は、Ｓ２２で受信され、記憶部１３０に記憶されたＭＰＤデータの内容を読み出し、Ｓ２４に進む。
【００９０】
Ｓ２４において、ストリーミング制御部１１０は、読み出したＭＰＤデータの中に属性「minimumUpdatePeriodMPD」が存在するか否かを判定する。
【００９１】
ストリーミング制御部１１０は、読み出したＭＰＤデータの中に属性「minimumUpdatePeriodMPD」が存在すると判定した場合（Ｓ２４においてＹＥＳ）、次回ＭＰＤデータを配信サーバ３００から取得する時刻を示す変数Ｔuに変数Ｔと属性「minimumUpdatePeriodMPD」の属性値との和を代入し（Ｓ２５）、Ｓ２７に進む。
【００９２】
一方、ストリーミング制御部１１０は、読み出したＭＰＤデータの中に属性「minimumUpdatePeriodMPD」が存在しないと判定した場合（Ｓ２４においてＹＥＳ）、以降ＭＰＤデータの更新は不要であるため、変数Ｔuに、対象映像コンテンツの配信終了時刻以降を示す十分に大きい値（例えば、変数Ｔが示す時刻の１ヶ月後を示すような値）を設定し（Ｓ２６）、Ｓ２７に進む。
【００９３】
Ｓ２７において、ストリーミング制御部１１０は、N番目のピリオドが再生対象であるか否かを判定する。具体的には、N番目のピリオドの配信開始時刻（およびライブ再生開始時刻）を示す属性「start」の属性値ＴNを用いて、ＴN≦Ｔ＜ＴN＋Ｄpが成立するか否かを判定する。成立しないと判定した場合、当該ピリオドは再生処理対象外であると判断し（Ｓ２７においてＮＯ）、ストリーミング制御部１１０はＮに１を加算することで再生処理対象ピリオドを次のピリオドへ切り替え（Ｓ２８）、Ｓ２７に戻る。
【００９４】
一方、ＴN≦Ｔ＜ＴN＋Ｄpが成立すると判定した場合、当該ピリオドを再生処理対象であると判断し（Ｓ２７においてＹＥＳ）、Ｎ番目のピリオドについて、属性「href」の有無で、外部参照ピリオドであるか、あるいは、通常ピリオドであるかを判定する（Ｓ２９）。
【００９５】
通常ピリオドと判定された場合（Ｓ２９においてＮＯ）、Ｓ３２に進む。一方、外部参照ピリオドと判定された場合（Ｓ２９においてＹＥＳ）、ストリーミング制御部１１０は、Ｎ番目のピリオドである外部参照ピリオドにおける属性「href」の属性値を参照することにより、リモートオブジェクトであるＸＭＬファイルpN.xmlを配信サーバ３００から受信する（Ｓ３０）
Ｓ３０の後、ストリーミング制御部１１０は、受信したリモートオブジェクトpN.xmlの内容を読み出し（Ｓ３１）、Ｓ３２に進む。なお、前述したように、pN.xmlの内容は、Ｎ番目のピリオドを示す通常ピリオドである。すなわち、Ｎ番目のピリオドに属する各ＭＳ（時分割データ群を構成する各時分割データ）の所在を示すＵＲＬ（第１の資源位置指定子）が含まれている。したがって、クライアント装置１００は、pN.xmlに基づいてＮ番目のピリオドの再生を行うことができる。
【００９６】
Ｓ３２において、ストリーミング制御部１１０は、当該ピリオドにおける処理対象ＭＳを示す変数Ｍを１に初期化し（Ｓ３２）、Ｓ３３に進む。
【００９７】
Ｓ３３において、ストリーミング制御部１１０は、ＴN＋（Ｍ−１）×Ｄs＜Ｔが成立するか否かを判定する。ストリーミング制御部１１０は、ＴN＋（Ｍ−１）×Ｄs＜Ｔが成立すると判定した場合（Ｓ３３においてＹＥＳ）、当該ＭＳは再生処理ではないと判断し、Ｍに１を加算し（Ｓ３４）、Ｓ３３に戻る。
【００９８】
一方、ストリーミング制御部１１０は、ＴN＋（Ｍ−１）×Ｄs＜Ｔが成立しないと判定した場合（Ｓ３３においてＮＯ）、クライアント装置１００は、当該ＭＳ（Ｎ番目のピリオドにおけるＭ番目のＭＳ）を再生処理対象と判断して再生する（Ｓ３５）。
【００９９】
具体的には、ストリーミング制御部１１０は、Ｓ２３で読み出したＭＰＤデータまたはＳ３１にて読み出したリモートオブジェクトに含まれているＮ番目のピリオドの通常ピリオドを参照したＭ番目のＭＳのＵＲＬを特定し、特定したＵＲＬにアクセスすることによりＭ番目のＭＳを受信して記憶部１３０にバッファリングする。そして、再生部１２０は、記憶部１３０にバッファリングされたＭ番目のＭＳを再生する。
【０１００】
Ｓ３５の後、ストリーミング制御部１１０は、処理対象時刻変数Ｔに、Ｓ３５で再生されたＭＳの再生時間に相当するＤsの値を加算すると共に、変数Ｍに１を加算することによって処理対象ＭＳを更新し（Ｓ３６）、Ｓ３７に進む。
【０１０１】
Ｓ３７において、ストリーミング制御部１１０は、Ｔ＜Ｔuが成立するか否かを判定する。ストリーミング制御部１１０は、Ｔ＜Ｔuが成立しない（すなわち、ＭＰＤデータを再度取得すべき時刻になった）と判定した場合（Ｓ３７においてＮＯ）、Ｓ２２に戻る。
【０１０２】
一方、ストリーミング制御部１１０は、Ｔ＜Ｔuが成立すると判定した場合（Ｓ３７においてＹＥＳ）、当該ピリオドに再生対象ＭＳが存在するかを判定するため、Ｔ＜ＴN＋Ｄpが成立するか否かを判定する（Ｓ３８）。
【０１０３】
ストリーミング制御部１１０は、Ｔ＜ＴN＋Ｄpが成立すると判定した場合（Ｓ３８においてＹＥＳ）、Ｓ３５の処理に戻る一方、Ｔ＜ＴN＋Ｄpが成立しない（すなわち、次のピリオドのＭＳを再生すべき時刻となった）と判定した場合（Ｓ３８においてＮＯ）、変数Ｎに１を加算する（Ｓ３９）。
【０１０４】
Ｓ３９の後、ストリーミング制御部１１０は、Ｓ２３にて読み出したＭＰＤデータの中に、Ｎ番目のピリオドが含まれているか否かを判定する（Ｓ４０）。ストリーミング制御部１１０は、含まれていると判定した場合（Ｓ４０においてＹＥＳ）にはＳ２９に戻る一方、含まれていないと判定した場合（Ｓ４０においてＮＯ）には処理を終了する。
【０１０５】
（配信システム１の利点）
以上のように、配信システム１の配信サーバ３００は、ライブ再生を行うクライアント装置１００が取得すべきＭＳの所在を特定するためのメタ情報を含んでいるＭＰＤデータを、対象映像コンテンツがライブ配信されている間に繰り返し生成する。
【０１０６】
配信サーバ３００のメタデータ作成部３２０は、過去のピリオド（過去の所定の期間中に配信され、ライブ再生が終了したピリオド）に属する各ＭＳについて当該ＭＳのＵＲＬ（時分割データの所在を示す第１の資源位置指定子）を含むリモートオブジェクト（第１のメタデータ）を生成する。
【０１０７】
また、メタデータ作成部３２０は、上記複数のＭＳのうち、過去のピリオドに属する各ＭＳについては当該ＭＳのＵＲＬを含むリモートオブジェクトの所在を示すＵＲＬ（第２の資源位置指定子）を上記メタ情報として含み、その他のピリオドに属する各ＭＳについては当該ＭＳのＵＲＬを上記メタ情報として含んでいるＭＰＤデータ（第２のメタデータ）を生成する。
【０１０８】
また、配信システム１のクライアント装置１００では、ストリーミング制御部１１０が、ＭＰＤデータを取得する。取得したＭＰＤデータには、ライブ再生に必要なピリオドに属する各ＭＳについては、当該ＭＳのＵＲＬが含まれており、過去のピリオドについては、取得すべきＭＳのＵＲＬが含まれるリモートオブジェクトのＵＲＬが含まれており、タイムシフト再生のように過去のピリオドに含まれるＭＳの再生が必要となる場合には、ストリーミング制御部１１０が当該リモートオブジェクトを取得する。
【０１０９】
そして、再生部１２０は、取得したＭＰＤデータに基づいて、配信サーバ３００からＭＳを順次取得するとともに再生する。取得すべきＭＳのＵＲＬがＭＰＤデータに含まれていない場合には、ストリーミング制御部１１０がＭＰＤデータに記載されているリモートオブジェクトの所在を示すＵＲＬを参照して当該リモートオブジェクトを取得した後、当該リモートオブジェクトに記載されているＵＲＬを参照して取得すべきＭＳを受信し、再生部１２０が再生する。
【０１１０】
上記の構成により、配信システム１の配信サーバ３００は、クライアント装置１００が任意の再生位置でライブコンテンツのトリック再生を行うことを可能にするようなＭＰＤデータであって従来よりも配信効率の良いＭＰＤデータを生成することができる。
【０１１１】
また、クライアント装置１００は、そのようなＭＰＤデータを参照することにより、対象映像コンテンツのライブ再生および任意の再生開始位置からのトリック再生を行うことができる。
【０１１２】
〔実施形態２〕
本発明の別の一実施形態に係る配信システムについて図７〜図１２を参照しながら説明する。
【０１１３】
本実施形態に係る配信システムでは、配信サーバが、定期的に、古いＭＰＤデータを、ライブ再生に不要なピリオドに関する情報を含まないようなＭＰＤデータ（ライブ再生に必要十分な最低限のピリオドに関する情報を持つＭＰＤデータ）に更新するとともに、更新後のＭＰＤデータをクライアント装置に送信する点で実施形態１の配信サーバ３００とは異なっている。また、本実施形態に係る配信システムでは、クライアント装置が、配信サーバから新たに取得したＭＰＤデータと既に配信サーバから取得済または合成済のＭＰＤデータとを合成することにより、対象映像コンテンツの再生を完了するために必要なＭＰＤデータを獲得する点で、実施形態１のクライアント装置１００とは異なっている。
【０１１４】
最初に、本実施形態に係る配信システム１’の構成について図７および図８を参照しながら説明する。
【０１１５】
図７は、本実施形態に係るクライアント装置および配信サーバの全体構成を示した図であり、図８は、本実施形態に係る配信システム１’の全体構成を示した図である。また、図９は、配信サーバの各更新時における更新処理後のＭＰＤデータと、クライアント装置によるＭＰＤデータの各取得後における合成処理により獲得されるＭＰＤデータと、を例示している。
【０１１６】
図８に示すように、配信システム１’は、クライアント装置１００’と配信サーバ３００’とネットワークストレージサーバ（ＮＡＳ）４００とを含むシステムである。また、クライアント装置１００’および配信サーバ３００’は、インターネットＮＷに接続している。
【０１１７】
以下、クライアント装置１００’および配信サーバ３００’について説明するが、ＮＡＳ４００については実施形態１に係るＮＡＳ４００と同一であるので、その説明を省略する。
（クライアント装置１００’）
図１に示すように、クライアント装置１００’は、ストリーミング制御部１１０’、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および操作部１６０を備えている。再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および操作部１６０については実施形態１と同一であるので、ストリーミング制御部１１０’について以下に説明する。
（ストリーミング制御部１１０’）
ストリーミング制御部１１０’は、配信サーバ３００’によって定期的に更新されるＭＰＤデータを定期的に配信サーバ３００’から取得し、既に配信サーバ３００から取得済または合成済のＭＰＤデータと合成することにより、対象映像コンテンツに関する最新状態のＭＰＤデータを生成する。
【０１１８】
ストリーミング制御部１１０’は、最新状態のＭＰＤデータを参照することにより、対象映像コンテンツのうち再生対象となる部分を構成する各ＭＳを配信サーバ３００’が配信する（または、配信した）配信時刻を特定する。ＭＰＤデータにおける各ＭＳの配信開始時刻は、ライブ再生時における当該ＭＳの再生開始時刻も示していることから、ストリーミング制御部１１０’は、現在時刻（ライブ再生の場合）またはユーザ操作による指定時刻（トリック再生の場合）と各ＭＳについて特定した配信時刻とから、再生すべきＭＳのＵＲＬを特定し、そのＭＳを受信するためのＨＴＴＰ要求を配信サーバ３００’に送信する。
【０１１９】
ストリーミング制御部１１０は、配信サーバから受信したそのＭＳを記憶部１３０にバッファリングする。
（配信サーバ３００’）
配信サーバ３００’は、配信部３１０と、メタデータ作成部３２０’と、パラメータ制御部３３０と、を備えている。配信部３１０およびパラメータ制御部３３０は、それぞれ、実施形態１の配信部３１０およびパラメータ制御部３３０と同一であるので、その説明を省略する。
【０１２０】
メタデータ作成部３２０’は、その映像コンテンツのＭＰＤデータを繰り返し（本実施形態では１０分毎に）更新する。具体的には、メタデータ作成部３２０’は、各更新時において、ピリオドに関する情報としてはクライアント装置１００’がライブ再生を行うのに必要な最小限のピリオド情報（通常ピリオド）のみを含むようにＭＰＤデータを更新する。
【０１２１】
以上、本実施形態に係る配信システム１’の構成について説明した。
【０１２２】
以下では、本実施形態に係るクライアント装置１００’および配信サーバ３００’の各動作について図９〜図１２を参照しながら説明する。
【０１２３】
最初に、配信サーバ３００’におけるメタデータ作成部３２０’が、ＭＰＤデータの各更新時において、古いＭＰＤデータを、新しいＭＰＤデータ（すなわち、クライアント装置１００’がライブ再生を行うのに必要な最小限のピリオド情報のみを含むＭＰＤデータ）に更新する動作について図９および図１０を参照しながら説明する。
【０１２４】
図９は、ＮＡＳ４００およびクライアント装置１００’の記憶部１３０が保持するＭＰＤデータの一部を概略的に例示した図である。なお、図９における「…」の表記は、図３における「…」の表記と同様に意味を持っている。
【０１２５】
また、図９の左上段のＭＰＤデータ５ａは、配信開始時刻にＮＡＳ４００に保持されている初期のＭＰＤデータを示している。また、図９の左中段のＭＰＤデータ５ｂは、配信終了時刻が確定する前である配信開始１０分経過後にＮＡＳ４００に保持されるＭＰＤデータを示しており、左下段のＭＰＤデータ５ｃは、配信終了時刻が確定した時点である配信開始４０分経過後にＮＡＳ４００に保持されるＭＰＤデータを示している。
【０１２６】
さらに、図９の右上段のＭＰＤデータ５ａ、右中段のＭＰＤデータ５ｄ、右下段のＭＰＤデータ５ｅは、それぞれ、クライアント装置１００’が対応する左段のＭＰＤデータを配信サーバ３００’から取得し、必要に応じて合成処理を行った結果として記憶部１３０に記録される、その時点で最新状態のＭＰＤデータを示している。
【０１２７】
図１０は、メタデータ作成部３２０’の上記動作を示すフローチャート図である。なお、図１０における「Period＃Ｎ」、Ｄp、Ｔc、ＴaおよびＴeは、図４のフローチャート図と同様の意味を持っている。
【０１２８】
最初に、図１７に示すような、ＭＰＤ更新により変化しない共通要素のみからなるＭＰＤ初期ドキュメントを作成する（Ｓ４１）。
【０１２９】
次に、Ｓ４２において、対象映像コンテンツの配信終了時刻が確定しているか否かを判定する。
【０１３０】
対象映像コンテンツの配信終了時刻が確定していないと判定した場合には（Ｓ４２においてＹＥＳ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加する（Ｓ４３）。例えば、メタデータ作成部３２０’は、対象映像コンテンツの配信開始１０分経過後に図９（ｂ）のようなＭＰＤデータを作成する場合、その時点では配信終了時刻が確定してないため、属性「minimumUpdatePeriodMPD」を追加し、ＭＰＤデータの更新間隔Ｄpにあたる属性値「PT10M」を設定する。
【０１３１】
一方、対象映像コンテンツの配信終了時刻が確定したと判定した場合には（Ｓ４２においてＮＯ）、要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」を追加せずに、Ｓ４４に進む。例えば、対象映像コンテンツの配信終了時刻が確定した配信開始４０分経過後にＭＰＤデータを更新する際には、図９（ｃ）に示すように更新後のＭＰＤデータにおいて要素「ＭＰＤ」に属性「minimumUpdatePeriodMPD」は含まれないことになる。
【０１３２】
Ｓ４４において、処理対象時刻変数ＴをＴaに初期化するとともに、処理対象ピリオドが対象映像コンテンツの先頭から何番目のピリオドであるかを示す変数Ｎを１に初期化し、Ｓ４５に進む。
【０１３３】
Ｓ４５において、Ｔ＜Ｔcが成立するか否かを判定する。Ｔ＜Ｔcが成立すると判定された場合（Ｓ４５においてＹＥＳ）、Ｓ４８に進む。
【０１３４】
一方、Ｔ＜Ｔcが成立しないと判定した場合（Ｓ４５においてＮＯ）、Ｎ番目のピリオドに関する情報を生成するとともに（Ｓ４６）、ＭＰＤデータの一部として追加し（Ｓ４７）、Ｓ４８に進む。
【０１３５】
Ｓ４８において、変数Ｔの値にＤpを加算するとともに、変数Ｎの値に１を加算し、Ｓ４９に進む。
【０１３６】
Ｓ４９において、Ｔ＜Ｔeが成立するか否かを判定する。Ｔ＜Ｔeが成立すると判定した場合（Ｓ４９においてＹＥＳ）、Ｓ４５の処理に戻る。
【０１３７】
一方、Ｔ＜Ｔeが成立しないと判定した場合（Ｓ４９においてＮＯ）、古いＭＰＤデータをＳ４１〜Ｓ４９までの処理の結果として得られたＭＰＤデータに更新し、ＮＡＳ４００に記録し、処理を終了する。なお、クライアント装置１００’から要求されたタイミングに応じて、最新の状態に更新されたＭＰＤデータがＮＡＳ４００から読み出され配信部３１０により配信される。
【０１３８】
以上、メタデータ作成部３２０’の動作について説明したが、配信サーバ３００’が配信開始時刻から１０分経過後にＭＰＤデータ５ａをＭＰＤデータ５ｂに更新する処理を例に挙げて、Ｓ４５〜Ｓ４７の処理についてより詳細に説明する。
【０１３９】
この例では、Ｔcが配信開始時刻Ｔaから１０分経過時点を示す値（Ｔa＋Ｄp）となる。配信サーバ３００’がＳ４５のステップを最初に処理する時には、Ｎ＝１且つＴ＝Ｔaであるので、Ｔ＜Ｔcが成立すると判定する。したがって、更新後のＭＰＤデータ５ｂには、クライアント装置１００’がライブ再生を行うのに不要な１番目のピリオドに関する情報は含まれないことになる。
【０１４０】
一方、配信サーバ３００’がＳ４５のステップを２度目に処理する時には、Ｎ＝２且つＴ＝Ｔa＋Ｄpであるので、Ｔ＜Ｔcが成立しないと判定する。したがって、その直後のＳ４６、Ｓ４７の処理の結果、更新後のＭＰＤデータ５ｂには、クライアント装置１００’がライブ再生を行うのに必要な２番目のピリオドに関する情報が含まれることになる。
【０１４１】
次に、本実施形態に係るクライアント装置１００’が、配信サーバ３００’が配信する対象映像コンテンツを再生するための動作について、図９、図１１および図１２を参照しながら以下に説明する。
【０１４２】
図１１は、配信サーバ３００’により配信される対象映像コンテンツを再生するためのクライアント装置１００’の動作を示すフローチャート図である。また、図１２は、図１１１のフローチャートの１ステップをより詳細に示したフローチャート図である。なお、図１１および図１２におけるＤp、Ｄs、Ｔs、ＴuおよびＴNは、図６のフローチャート図と同様の意味を持っている。
【０１４３】
最初に、ストリーミング制御部１１０’は、再生処理開始に先立ち、処理対象時刻を表す変数ＴをＴsで初期化し、処理対象ピリオドを表す変数Ｎを１で初期化する（Ｓ６１）。
【０１４４】
Ｓ６２において、ストリーミング制御部１１０’は、配信サーバ３００’に対象映像コンテンツに関するＭＰＤデータを要求し、配信サーバ３００’からＭＰＤデータを受信し、記憶部１３０に記憶する。Ｓ６３において、ストリーミング制御部１１０’は、Ｓ６２の処理の前からすでに記憶部１３０に記録されているような、対象映像コンテンツに関するＭＰＤデータ（以下では「既存ＭＰＤ」とも称する）が存在するか否かを判定する。
【０１４５】
Ｓ６３において存在しないと判定された場合、Ｓ６５に進む。一方、Ｓ６３において存在すると判定された場合、Ｓ６４に進む。すなわち、Ｓ６２にて初期のＭＰＤデータ（例えば、図９の左上段のＭＰＤデータ５ａ）を受信した場合には、Ｓ６５に進み、Ｓ６２にて２度目以降のＭＰＤデータ（例えば、図９の左中段のＭＰＤデータ５ｂや左下段のＭＰＤデータ５ｃ等）を受信した場合には、Ｓ６４に進む。
【０１４６】
ストリーミング制御部１１０’は、Ｓ６２で受信され、記憶部１３０に記憶されたＭＰＤデータ（以下では「新規ＭＰＤ」とも称する）と、既存ＭＰＤとを合成し（Ｓ６４）、Ｓ６５の処理に進む。後に述べるように、Ｓ６４の合成処理の結果として得られるＭＰＤデータには、ライブ再生に必要十分なピリオドに関する情報とそれ以前のすべてのピリオドに関する情報とが含まれることになる。
【０１４７】
クライアント装置１００’は、Ｓ６５〜Ｓ８１について、クライアント装置１００のＳ２４〜Ｓ４０と同様の処理を行う。
【０１４８】
以下では、参照する図面を図９および図１２に変えて、Ｓ６４の合成処理の詳細について説明する。
【０１４９】
最初に、ストリーミング制御部１１０’は、新規ＭＰＤを読み出し（Ｓ６４１）。新規ＭＰＤの先頭から何番目のピリオドであるかを示す変数Ｌを１で初期化する（Ｓ６４２）。
【０１５０】
その後、Ｓ６４３において、ストリーミング制御部１１０’は、新規ＭＰＤのＬ番目のピリオドの属性「ｉｄ」の属性値と同じ属性値を持つピリオドが既存ＭＰＤに含まれているか否かを判定する。例えば、既存ＭＰＤが図９のＭＰＤデータ５ａであって新規ＭＰＤが図９のＭＰＤデータ５ｂである場合、ストリーミング制御部１１０’は、Ｌが１のとき（id=”2”のピリオド）は既存ＭＰＤに含まれていると判定し、Ｌが２のとき（id=”3”のピリオド）は既存ＭＰＤに含まれていないと判定する。
【０１５１】
ストリーミング制御部１１０’は、そのような情報が既存ＭＰＤに含まれていないと判定した場合（Ｓ６４３においてＮＯ）には、新規ＭＰＤに含まれているＬ番目のピリオドに関する情報を既存ＭＰＤに追加し（Ｓ６４４）、Ｓ６４５の処理に進む。一方、ストリーミング制御部１１０’は、そのような情報が既存ＭＰＤに含まれていると判定した場合（Ｓ６４３においてＹＥＳ）には、そのまま、Ｓ６４５の処理に進む。
【０１５２】
Ｓ６４５において、ストリーミング制御部１１０’は、Ｌの値に１を加算し、Ｓ６４６において、新規ＭＰＤにＬ番目のピリオドに関する情報が含まれているか否かを判定する。例えば、既存ＭＰＤが図９のＭＰＤデータ５ａであって新規ＭＰＤが図９のＭＰＤデータ５ｂである場合、ストリーミング制御部１１０’は、Ｌが１あるいは２のときは、当該ピリオドの情報が含まれていると判定し、Ｌが３のときは当該ピリオドに関する情報が含まれていないと判定する。当該例においては、この時点で、既存ＭＰＤが図９のＭＰＤデータ５ｄのようになっている。
【０１５３】
ストリーミング制御部１１０’は、新規ＭＰＤにＬ番目のピリオドに関する情報が含まれていると判定した場合（Ｓ６４６においてＹＥＳ）、Ｓ６４３の処理に戻る一方、そのような情報が含まれていないと判定した場合（Ｓ６４６においてＮＯ）、Ｓ６４７の処理に進む。
【０１５４】
Ｓ６４７では、ストリーミング制御部１１０’は、Ｓ６４１〜Ｓ６４６の処理で得られた合成後のＭＰＤデータの先頭から何番目のピリオドであるかを示す変数Ｋを１で初期化する。
【０１５５】
Ｓ６４８において、ストリーミング制御部１１０’は、Ｋ番目のピリオドが有効であるか否かを、新規ＭＰＤの属性「timeShiftBufferDepth」の属性値に基づいて判定する。属性「timeShiftBufferDepth」は、ライブストリーミング配信のみで有効な属性であり、配信サーバが各ＭＳについてＭＳの配信を開始してから破棄するまでの時間を示している。
【０１５６】
ストリーミング制御部１１０’は、具体的には、Ｋ番目のピリオドの開始時間（属性「start」の属性値）と属性「availabilityStartTime」の属性値とからＬ番目のピリオドの配信開始時刻を算出する。そして、ストリーミング制御部１１０’は、現在時刻からＫ番目のピリオドの配信開始時刻を引いた値が属性「timeShiftBufferDepth」の属性値以下である場合にＫ番目のピリオドが有効であると判定し、そうでない場合にはＫ番目のピリオドが無効であると判定する。例えば、既存ＭＰＤがＭＰＤデータ５ｄである場合には、１番目のピリオドから３番目のピリオドまでの各配信開始時刻はいずれも現在時刻から過去７日以内にあるので、３つのピリオドはすべて有効であると判定される。
【０１５７】
以上のＳ６４８の処理によってＫ番目のピリオドが有効であると判定した場合、ストリーミング制御部１１０’は、Ｓ６５０の処理に進む。一方、Ｋ番目のピリオドが無効であると判定した場合、ストリーミング制御部１１０’は、Ｋ番目のピリオドに関するピリオド情報を削除した上で（Ｓ６４９）、Ｓ６５０の処理に進む。
【０１５８】
Ｓ６５０において、ストリーミング制御部１１０’は、Ｋの値に１を加算し、Ｓ６５１において、既存ＭＰＤにＫ番目のピリオドに関する情報が含まれているか否かを判定する。
【０１５９】
ストリーミング制御部１１０’は、上記情報が含まれていると判定した場合（Ｓ６５１においてＹＥＳ）にはＳ６４８の処理に戻り、上記情報が含まれていないと判定した場合（Ｓ６５１においてＮＯ）には、Ｓ６４の処理を終了し、Ｓ６５の処理に進む。なお、ストリーミング制御部１１０’は、Ｓ６４６において「新規ＭＰＤにＬ番目のピリオドに関する情報が含まれていない」と判定した時点以降に新規ＭＰＤを破棄しても良い。
【０１６０】
（配信システム１’の利点）
以上のように、配信システム１’の配信サーバ３００’は、対象映像コンテンツのＭＰＤデータをクライアント装置１００’に繰り返し配信するが、ＭＰＤデータには配信時点を含む一定期間内に配信される各ＭＳについてのみ当該ＭＳのＵＲＬが含まれている。
【０１６１】
また、配信システム１’のクライアント装置１００’では、ストリーミング制御部１１０’が、配信サーバ３００’から上記ＭＰＤデータを取得する度に、取得したＭＰＤデータから新たなＭＰＤデータを生成し、再生部１２０が直前に生成したＭＰＤデータに基づいて取得すべきＭＳを順次取得するとともに再生する。
【０１６２】
具体的には、ストリーミング制御部１１０’は、直前に生成したＭＰＤデータ（既存ＭＰＤ）と新たに取得したＭＰＤデータ（新規ＭＰＤ）とを合成することにより、新たなＭＰＤデータを生成するが、合成により新たに生成されるＭＰＤデータには、既存ＭＰＤおよび新規ＭＰＤの少なくとも一方のＭＰＤに含まれている上記ＵＲＬがすべて含まれることになる。
【０１６３】
したがって、クライアント装置１００’が対象映像コンテンツを配信開始時点からライブ再生する場合には、クライアント装置１００’が生成するＭＰＤには、常に、現在配信され、または、過去に配信されたすべてのＭＳのＵＲＬが含まれることになる。
【０１６４】
以上のことから、配信システム１’では、クライアント装置１００’が、対象映像コンテンツのライブ再生および任意の再生開始位置からのトリック再生を行うことができる。
【０１６５】
〔実施形態の変形例について〕
（変形例１）
実施形態２の配信システム１’では、クライアント装置１００’が対象映像コンテンツの先頭のピリオドから始まるすべてのピリオドについてピリオドに関する情報を受信した場合に限り、任意の再生位置から対象映像コンテンツのトリック再生を行うことができる。換言すれば、配信システム１’のクライアント装置１００’は、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けた場合、任意の再生位置からトリック再生を行うことができないことがある。具体例について図１３を参照しながら説明する。
【０１６６】
図１３は、配信サーバ３００’がＭＰＤデータを更新するタイミングと、対象映像コンテンツの各ピリオドと、クライアント装置１００’−１、１００’−２がＭＰＤデータを取得するタイミングと、クライアント装置１００’−１、１００’−２が各ピリオドにおける映像を再生する期間とを模式的に示した図である。
【０１６７】
図１３において、水平方向は時間方向を示しており、左端は対象映像コンテンツの配信開始時刻を示している。配信サーバ３００’がＭＰＤデータを更新するタイミングは、図中における「配信サーバ」という文字列の水平右方向に位置する下向き矢印により表されている。また、対象映像コンテンツの各ピリオドは、図中における「対象映像コンテンツ」という文字列の水平右方向に位置する双方向矢印により表されている。なお、この双方向矢印の上方および下方のブレースは、各ピリオドに関する情報が含まれているＭＰＤデータを示している。さらに、各クライアント装置がＭＰＤデータを取得するタイミングおよび各クライアント装置が各ピリオドにおける映像を再生する期間は、それぞれ、図中における対応する「クライアント装置」という文字列の水平右方向に位置する下向き矢印および双方向矢印により表されている。
【０１６８】
図１３に示すように、クライアント装置１００’−１および１００’−２は、両方とも、対象映像コンテンツの配信開始時刻を過ぎてから再生指示を受け、ＭＰＤデータを取得している。
【０１６９】
クライアント装置１００’−１は、配信サーバ３００’において最初の更新がされる前に再生指示を受けているので、初期のＭＰＤデータ（ＭＰＤ１）を取得することができている。一方、クライアント装置１００’−２は、配信サーバ３００’において最初の更新がされた直後に再生指示を受けているので、初期のＭＰＤデータ（ＭＰＤ１）を取得することができていない。したがって、クライアント装置１００’−２は、１番目のピリオドに関する情報を取得できず、１番目のピリオドに属するような再生位置からトリック再生を行うことができない。
【０１７０】
任意の再生位置でトリック再生を行うことができるように、本発明は、実施形態２のクライアント装置１００’と実施形態１の配信サーバ３００とを組み合わせた配信システムとして実現してもよい。
【０１７１】
このように実現された配信システムでは、図１２に示したフローチャートに従う実施形態２の方法と略同様の方法で、クライアント装置１００’は、配信サーバ３００から受信した新規ＭＰＤと既存ＭＰＤとを合成することになる。
【０１７２】
その結果、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けたクライアント装置１００’が最初に取得するＭＰＤデータには、現在時刻が属するピリオド（「Ｐ番目のピリオド」とする）よりも前のピリオドについては外部参照ピリオドが含まれ、それ以降のピリオドについては通常ピリオドが含まれることになる。そして、クライアント装置１００’が２度目以降に取得した新規ＭＰＤと既存ＭＰＤとを合成して得られるＭＰＤデータには、常に、１〜Ｐ−１番目のピリオドについては外部参照ピリオドが含まれ、Ｐ番目以降のピリオドについては通常ピリオドが含まれることになる。
【０１７３】
したがって、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けた場合であっても、クライアント装置１００’は、実施形態１と同様に、任意の再生位置から対象映像コンテンツのトリック再生を行うことができる。また、実施形態１とは異なり、クライアント装置１００’は、トリック再生を開始する再生位置が属するピリオドが先頭からＰ番目以降のピリオドであれば、常に、リモートオブジェクトを参照することなくトリック再生を開始することができる。
【０１７４】
（変形例２）
クライアント装置が、配信開始時刻を過ぎてから対象映像コンテンツの再生指示を受け付けた場合であっても、任意の再生位置からトリック再生を行うことができるように、以下のような配信システムとして本発明を実施してもよい。
【０１７５】
すなわち、クライアント装置１００’と、対象映像コンテンツのＭＰＤデータに対して定期的に更新処理１を実行していく一方、対象映像コンテンツのＭＰＤデータに対して定期的に更新処理２を実行していくような配信サーバと、を含むような配信システムとして、本発明を実施してもよい。
【０１７６】
この配信サーバは、具体的には、更新処理１と更新処理２とを同時に行うようになっている。また、この配信サーバは、最初の更新時には、同一内容の２つのＭＰＤデータ（初期のＭＰＤデータ）に対して、それぞれ、更新処理１と更新処理２とを実行するようになっている。
【０１７７】
配信サーバは、クライアント装置１００’からの対象映像コンテンツのＭＰＤデータの要求が初回の要求である場合には、更新処理１によって更新されたＭＰＤデータをクライアント装置１００’に返却し、２度目以降の要求である場合には、更新処理２によって更新されたＭＰＤデータをクライアント装置１００’に返却する。
【０１７８】
配信サーバは、クライアント装置１００’からのＭＰＤデータの要求が初回の要求であるか２度目以降の要求であるかを以下のように識別することができる。
【０１７９】
例えば、配信サーバは、クライアント装置１００’を特定可能な情報（例えばクライアント装置１００’のＩＤ情報）を含むようなクッキー情報を、クライアント装置１００’に保存させてもよい。すなわち、配信サーバは、クライアント装置１００’から上記クッキー情報を受信したか否かを判定し、受信していないと判定した場合には、初回の要求であると判定するとともに、上記クッキー情報をクライアント装置１００‘に保存させる。一方、配信サーバは、受信したと判定した場合には、２度目の要求であると判定する。
【０１８０】
また、例えば、配信サーバは、更新処理１によって更新されるＭＰＤデータのＵＲＬ情報（ＵＲＬ１）と、更新処理２によって更新されるＭＰＤデータのＵＲＬ情報（ＵＲＬ２）と、それぞれ、クライアント装置１００’に通知してもよい。２つのＵＲＬ情報は互いに異なっていればよい。すなわち、各ＭＰＤデータのファイル名を含むようなＵＲＬ情報であってもよいし、各ＭＰＤデータの保存先を互いに異なるフォルダにすることにより、２つのＵＲＬ情報を異ならせてもよい。この場合、クライアント装置１００’は、対象映像コンテンツのＭＰＤデータを初めて取得する場合には、ＵＲＬ１にアクセスし、取得するのが２度目以降である場合には、ＵＲＬ２にアクセスすればよい。なお、ＵＲＬ１についてはクライアント装置１００’に予め通知しておき、ＵＲＬ２については、ＵＲＬ１にアクセスすることによって取得されるＭＰＤデータ内（例えば、図１８に例示されているＭＰＤデータ内の点線の枠で囲まれた部分）に要素「Location」の要素値として記述する構成であってもよい。
【０１８１】
以上のような配信システムによっても、クライアント装置１００’は、配信サーバからＭＰＤデータを取得するたびに、Ｓ６４の合成処理によって任意の再生位置からトリック再生を行うことができるような最新状態のＭＰＤデータを得ることができる。
【０１８２】
（付記事項１）
以上の各実施形態では、配信サーバが対象映像コンテンツのＭＰＤデータと対象映像コンテンツ自体との両方を配信するものとしたが、ＭＰＤデータを配信する配信サーバと、対象映像コンテンツを配信する配信サーバとは異なるサーバであってもよい。また、各実施形態では、ＭＰＤデータを配信する配信サーバがＭＰＤデータの更新も行うものとしたが、ＭＰＤデータの配信とＭＰＤデータの更新とを異なるサーバが行ってもよい。また、ＭＰＤデータの更新を行うサーバ（生成装置）は、通信機能を備えている必要はない。すなわち、配信サービス事業者の担当者が、サーバで更新されたＭＰＤデータを、着脱可能な記録メディアを介して、手作業で、配信サーバに移動してもよく、上記ＭＰＤデータを、通信機能を備えた他の装置に手作業で移動した上で、配信サーバにアップロードしてもよい。
【０１８３】
（その他の付記事項）
メタデータ作成部３２０は、対象映像コンテンツの配信終了時刻が確定した後に既存のＭＰＤデータを属性「minimumUpdatePeriodMPD」を含まないようなＭＰＤデータに更新した後、ＭＰＤデータの定期的な更新を終了してもよいし、そのまま更新を定期的に続けても良い。また、実施形態１では、メタデータ作成部３２０が、過去のピリオドについてピリオド毎に異なるXMLファイルを生成するものとしたが、過去のピリオドに属する全MSのURL（１つの時分割データ群を構成する各時分割データ）を含むような１つのXMLファイルを生成してもよい。
【０１８４】
（プログラム、記憶媒体）
クライアント装置１００（１００’）および配信サーバ３００（３００’）の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
【０１８５】
後者の場合、クライアント装置１００（１００’）および配信サーバ３００（３００’）は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるクライアント装置１００（１００’） および配信サーバ３００（３００’）の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、クライアント装置１００（１００’） および配信サーバ３００（３００’）に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０１８６】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
【０１８７】
また、上記プログラムコードは、通信ネットワークを介してクライアント装置１００（１００’）および配信サーバ３００（３００’）に供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
【０１８８】
なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明だけではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【産業上の利用可能性】
【０１８９】
本発明に係る再生装置および生成装置は、コンテンツ配信システムなどに広く適用することができる。
【符号の説明】
【０１９０】
５ａ〜５ｅ ＭＰＤデータ
１００、１００’ クライアント装置（再生装置）
１１０、１１０’ ストリーミング制御部（第１の取得手段、第２の取得
手段、取得手段、生成手段）
１２０ 再生部（再生手段）
１３０ 記憶部
１４０ ネットワーク・Ｉ／Ｆ
１５０ 表示部
１６０ 操作部
３００、３００’ 配信サーバ（生成装置）
３１０ 配信部
３２０、３２０’ メタデータ作成部（第１の生成手段、第２の生成手段）
３３０ パラメータ制御部
４００ ネットワークストレージサーバ（ＮＡＳ）
【特許請求の範囲】
【請求項１】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置において、
過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成手段と、
上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成手段と、を備えていることを特徴とする生成装置。
【請求項２】
上記コンテンツデータは、配信開始時刻には配信終了時刻が確定していないコンテンツデータであり、
上記第２の生成手段は、上記配信終了時刻が確定した後に上記第２のメタデータを生成する場合には、上記第２のメタデータとして、上記配信開始時刻から上記配信終了時刻までに配信される全時分割データについて上記メタ情報を含むような第２のメタデータを生成することを特徴とする請求項１に記載の生成装置。
【請求項３】
上記過去の所定の期間は、上記第２の生成手段が上記第２のメタデータを生成する時点を含む一定期間よりも過去の全期間であることを特徴とする請求項２に記載の生成装置。
【請求項４】
上記時分割データはＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規定のメディアセグメントであり、上記第１のメタデータはＤＡＳＨ規定のリモートオブジェクトであって上記第２のメタデータは上記コンテンツデータに関するＤＡＳＨ規定のＭＰＤデータであり、
上記第１の資源位置指定子は上記メディアセグメントのＵＲＬであって上記第２の資源位置指定子は上記リモートオブジェクトのＵＲＬである、ことを特徴とする請求項１から３のいずれか１項に記載の生成装置。
【請求項５】
上記コンテンツデータと上記コンテンツデータに関するメタデータとを上記再生装置に配信する配信サーバであって請求項１から４のいずれか１項に記載の生成装置としても機能することを特徴とする配信サーバ。
【請求項６】
配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、
過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを取得する第１の取得手段と、
上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を含んでいる第２のメタデータを取得する第２の取得手段と、
上記第２のメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、
上記再生手段は、取得すべき時分割データの第１の資源位置指定子が上記第２のメタデータに含まれていない場合には、第２の資源位置指定子を参照して当該第１の資源位置指定子を含む第１のメタデータを取得するとともに当該第１の資源位置指定子を参照して当該時分割データを取得する、ことを特徴とする再生装置。
【請求項７】
配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、
ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得手段と、
上記取得手段がメタデータを取得する度に当該メタデータから新たなメタデータを生成する生成手段と、
上記生成手段が直前に生成した新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、
上記生成手段は、当該生成手段が直前に生成したメタデータおよび上記取得手段が新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する、ことを特徴とする再生装置。
【請求項８】
上記時分割データはＤＡＳＨ（Dynamic AdaptiveStreaming overHTTP）規定のメディアセグメントである、ことを特徴とする請求項６または７に記載の再生装置。
【請求項９】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置の生成方法において、
過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成工程と、
上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成工程と、からなる生成工程を繰り返すことを特徴とする生成方法。
【請求項１０】
配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置の再生方法において、
ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得工程と、
上記取得工程にてメタデータが取得される度に当該メタデータから新たなメタデータを生成する生成工程と、
直前の上記生成工程にて生成された新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生工程と、を含み、
上記生成工程は、当該生成工程の直前の生成工程にて生成されたメタデータおよび上記取得工程にて新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する工程であることを特徴とする再生方法。
【請求項１１】
請求項５に記載の配信サーバと、請求項６に記載の再生装置と、を含んでいる再生システム。
【請求項１２】
請求項１から４のいずれか１項に記載の生成装置としてコンピュータを動作させる生成プログラムであって、コンピュータを上記各手段として機能させるための生成プログラム。
【請求項１３】
請求項６から８のいずれか１項に記載の再生装置としてコンピュータを動作させる再生プログラムであって、コンピュータを上記各手段として機能させるための再生プログラム。
【請求項１４】
請求項１２に記載の生成プログラムおよび請求項１３に記載の再生プログラムのうちの少なくとも一方のプログラムが記録されているコンピュータ読み取り可能な記録媒体。
【請求項１５】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータのデータ構造において、
上記メタデータに含まれる、所定の期間における時分割データ群の所在を特定するためのメタ情報のデータ構造が、
上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含むようなメタデータの所在を示す第２の資源位置指定子を上記メタ情報として含む第１のデータ構造、および、上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を上記メタ情報として含む第２のデータ構造のうち、上記コンテンツデータのライブ配信が開始されてからの経過時間に応じて選択されたデータ構造となっていることを特徴とするメタデータのデータ構造。
【請求項１】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置において、
過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成手段と、
上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成手段と、を備えていることを特徴とする生成装置。
【請求項２】
上記コンテンツデータは、配信開始時刻には配信終了時刻が確定していないコンテンツデータであり、
上記第２の生成手段は、上記配信終了時刻が確定した後に上記第２のメタデータを生成する場合には、上記第２のメタデータとして、上記配信開始時刻から上記配信終了時刻までに配信される全時分割データについて上記メタ情報を含むような第２のメタデータを生成することを特徴とする請求項１に記載の生成装置。
【請求項３】
上記過去の所定の期間は、上記第２の生成手段が上記第２のメタデータを生成する時点を含む一定期間よりも過去の全期間であることを特徴とする請求項２に記載の生成装置。
【請求項４】
上記時分割データはＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規定のメディアセグメントであり、上記第１のメタデータはＤＡＳＨ規定のリモートオブジェクトであって上記第２のメタデータは上記コンテンツデータに関するＤＡＳＨ規定のＭＰＤデータであり、
上記第１の資源位置指定子は上記メディアセグメントのＵＲＬであって上記第２の資源位置指定子は上記リモートオブジェクトのＵＲＬである、ことを特徴とする請求項１から３のいずれか１項に記載の生成装置。
【請求項５】
上記コンテンツデータと上記コンテンツデータに関するメタデータとを上記再生装置に配信する配信サーバであって請求項１から４のいずれか１項に記載の生成装置としても機能することを特徴とする配信サーバ。
【請求項６】
配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、
過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを取得する第１の取得手段と、
上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を含んでいる第２のメタデータを取得する第２の取得手段と、
上記第２のメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、
上記再生手段は、取得すべき時分割データの第１の資源位置指定子が上記第２のメタデータに含まれていない場合には、第２の資源位置指定子を参照して当該第１の資源位置指定子を含む第１のメタデータを取得するとともに当該第１の資源位置指定子を参照して当該時分割データを取得する、ことを特徴とする再生装置。
【請求項７】
配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置において、
ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得手段と、
上記取得手段がメタデータを取得する度に当該メタデータから新たなメタデータを生成する生成手段と、
上記生成手段が直前に生成した新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生手段と、を備え、
上記生成手段は、当該生成手段が直前に生成したメタデータおよび上記取得手段が新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する、ことを特徴とする再生装置。
【請求項８】
上記時分割データはＤＡＳＨ（Dynamic AdaptiveStreaming overHTTP）規定のメディアセグメントである、ことを特徴とする請求項６または７に記載の再生装置。
【請求項９】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータを、上記コンテンツデータがライブ配信されている間に繰り返し生成する生成装置の生成方法において、
過去の所定の期間内に配信された１以上の時分割データ群の各時分割データ群について、該時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含む、第１のメタデータを生成する第１の生成工程と、
上記複数の時分割データのうち、上記期間内に配信された各時分割データについては当該時分割データの第１の資源位置指定子を含む第１のメタデータについてその所在を示す第２の資源位置指定子を上記メタ情報として含み、その他の各時分割データについては当該時分割データの第１の資源位置指定子を上記メタ情報として含んでいる第２のメタデータを生成する第２の生成工程と、からなる生成工程を繰り返すことを特徴とする生成方法。
【請求項１０】
配信サーバにより複数の時分割データに時分割されてライブ配信されるコンテンツデータを再生する再生装置の再生方法において、
ライブ再生するために取得すべき時分割データを少なくとも含む一定期間内に配信される各時分割データについてのみ、当該時分割データの所在を示す資源位置指定子を含むようなメタデータを繰り返し取得する取得工程と、
上記取得工程にてメタデータが取得される度に当該メタデータから新たなメタデータを生成する生成工程と、
直前の上記生成工程にて生成された新たなメタデータに基づいて上記配信サーバから上記時分割データを順次取得するとともに再生する再生工程と、を含み、
上記生成工程は、当該生成工程の直前の生成工程にて生成されたメタデータおよび上記取得工程にて新たに取得したメタデータのうちの少なくとも一方のメタデータに含まれている資源位置指定子をすべて含むようなメタデータを上記新たなメタデータとして生成する工程であることを特徴とする再生方法。
【請求項１１】
請求項５に記載の配信サーバと、請求項６に記載の再生装置と、を含んでいる再生システム。
【請求項１２】
請求項１から４のいずれか１項に記載の生成装置としてコンピュータを動作させる生成プログラムであって、コンピュータを上記各手段として機能させるための生成プログラム。
【請求項１３】
請求項６から８のいずれか１項に記載の再生装置としてコンピュータを動作させる再生プログラムであって、コンピュータを上記各手段として機能させるための再生プログラム。
【請求項１４】
請求項１２に記載の生成プログラムおよび請求項１３に記載の再生プログラムのうちの少なくとも一方のプログラムが記録されているコンピュータ読み取り可能な記録媒体。
【請求項１５】
複数の時分割データに時分割されてライブ配信されるコンテンツデータに関するメタデータであってライブ再生を行う再生装置が取得すべき時分割データの所在を特定するためのメタ情報を含んでいるメタデータのデータ構造において、
上記メタデータに含まれる、所定の期間における時分割データ群の所在を特定するためのメタ情報のデータ構造が、
上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を含むようなメタデータの所在を示す第２の資源位置指定子を上記メタ情報として含む第１のデータ構造、および、上記時分割データ群を構成する各時分割データの所在を示す第１の資源位置指定子を上記メタ情報として含む第２のデータ構造のうち、上記コンテンツデータのライブ配信が開始されてからの経過時間に応じて選択されたデータ構造となっていることを特徴とするメタデータのデータ構造。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１３−２１５７４（Ｐ２０１３−２１５７４Ａ）
【公開日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願番号】特願２０１１−１５４３４９（Ｐ２０１１−１５４３４９）
【出願日】平成２３年７月１２日（２０１１．７．１２）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２５年１月３１日（２０１３．１．３１）
【国際特許分類】
【出願日】平成２３年７月１２日（２０１１．７．１２）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]