JP2016012930A - データ提供方法及びその装置、並びにデータ受信方法及びその装置 - Google Patents

Abstract

【課題】ライブストリーミングを提供するのに必要な付加情報を提供する方法及びその装置、並びにそれを利用してライブストリーミングを提供される方法及びその装置を提供する。
【解決手段】データ受信方法及びその装置、並びにデータ提供方法及びその装置は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を受信し、第１付加情報を利用し、第１ファイルが更新される時点を示す更新時点情報を獲得した後、更新時点情報に基づいて、複数個のメディアデータの第２区間に係わる情報を含む第２付加情報を受信する。
【選択図】図３０

Description

本発明は、データを提供する方法及びその装置、並びにデータを受信する方法及びその装置に係り、特に、ライブストリーミングを提供するのに必要な付加情報を提供する方法及びその装置、並びにそれを利用してライブストリーミングを提供される方法及びその装置に関する。

ネットワークを介してメディアデータを伝送する方式には、ダウンロード方式とストリーミング方式とがある。ストリーミング方式は、サーバがリアルタイムでメディアデータを伝送し、クライアントは、受信されたメディアデータをリアルタイムで再生し、次に受信されるデータに係わる付加情報をあらかじめ獲得する方式である。

ダウンロード方式では、あらゆるデータに係わる付加情報をあらかじめ受信し、それを利用してデータを受信することができるが、ストリーミング方式の場合には、帯域幅の効率的な使用が重要であるので、かような方式を使用し難い。

国際公開第２００８／０６２９７９号 国際公開第２００８／１３０１９１号 特開２００９−１３４７００号公報

R. Pantos Ed.，HTTP Live Streaming draft-pantos-http-live-streaming-02，［online］，Internet-Drafts，IETF，２００９年１０月 ５日，［平成26年7月25日検索］，インターネット＜URL: ftp://tsubaki.st.ryukoku.ac.jp/pub/internet/internet-drafts/draft-pantos-http-live-streaming-02.txt＞

本発明の目的は、ライブストリーミングデータを効率的に提供して受信するための方法と、そのための装置を提供することである。

前記の目的を達成するための本発明の１つの特徴は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を受信する段階と、前記第１付加情報を利用し、前記第１ファイルが更新される時点を示す更新時点情報を獲得する段階と、前記更新時点情報に基づいて、前記複数個のメディアデータの第２区間に係わる情報を含む第２付加情報を受信する段階と、を含むことである。

前記第１付加情報に基づいて、前記複数個のメディアデータのうち少なくとも１つのメディアデータの第１区間に該当するデータを、ストリーミング方式で受信する段階と、前記第２付加情報に基づいて、前記少なくとも１つのメディアデータの第２区間に該当するデータを、ストリーミング方式で受信する段階と、をさらに含んでもよい。

前記第２付加情報は、前記第１付加情報と同一の属性構造を有することができる。

前記第１付加情報は、前記第２付加情報に係わる位置情報をさらに含んでもよい。

第２付加情報は、前記第１付加情報と異なる属性構造を有することができる。

前記第１区間及び前記第２区間は、前記第１区間及び前記第２区間で提供されるプログラムによって区分される。

前記第１区間及び前記第２区間は、前記複数個のメディアデータを所定の時間単位に分割して生成される。

前記第１付加情報は、前記第１区間が始まる時点を示す情報をさらに含んでもよい。

前記第１付加情報は、前記第１区間が終わる時点を示す情報をさらに含んでもよい。

前記第１付加情報は、前記第１区間で提供されるプログラムの識別情報をさらに含んでもよい。

本発明の他の実施形態が有する１つの特徴は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報が含まれた第１前記第１付加情報と、前記複数個のメディアデータの第２区間に係わる情報が含まれた第２付加情報とを生成する段階と、前記第１付加情報をクライアントに伝送する段階と、前記クライアントから前記第１付加情報に係わる更新要請が受信されれば、前記第２付加情報を前記クライアントに伝送する段階と、を含み、前記第１付加情報は、前記第１付加情報の更新時点を示す更新時点情報を含むことである。

前記方法は、前記第１区間に外部データを付加する段階と、外部データの追加によって、前記第１区間で除外されたデータに係わる情報が含まれた第３付加情報を生成する段階と、第１付加情報から前記除外されたデータに係わる情報を削除し、前記外部データに係わる情報を含んで第１付加情報を変更する段階と、をさらに含んでもよい。

前記変更する段階は、第３付加情報の位置を、次回付加情報の位置として、前記第１付加情報に登録する段階を含んでもよい。

本発明の他の実施形態が有する１つの特徴は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を受信する受信部と、前記第１付加情報を利用し、前記第１ファイルが更新される時点を示す更新時点情報を獲得する獲得部と、を含み、前記受信部は、前記更新時点情報に基づいて、前記複数個のメディアデータの第２区間に係わる情報を含む第２付加情報をさらに受信することを特徴とするデータ受信装置を提供することである。

本発明の他の実施形態が有する１つの特徴は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報が含まれた第１付加情報、及び前記複数個のメディアデータの第２区間に係わる情報が含まれた第２付加情報を生成する生成部と、前記第１付加情報をクライアントに伝送する伝送部と、前記クライアントから、前記第１付加情報に係わる更新要請を受信する要請受信部と、を含み、前記伝送部は、前記要請が受信されれば、前記第２付加情報を前記クライアントにさらに伝送し、前記第１付加情報は、第１付加情報の更新時点を示す更新時点情報を含むことを特徴とするデータ提供装置を提供することである。

本発明の一実施形態によるストリーミング・システムを図示する図面である。 本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。 本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。 本発明の一実施形態によるコンテンツについての情報を含むファイルのスキーマ（schema）を図示する図面である。 本発明の一実施形態による複数のメディアデータを定義するための情報を図示する図面である。 本発明の一実施形態によるメディアデータのヘッダについての情報を図示する図面である。 図４Ｃは本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも１つの部分についての情報を図示する図面である。 本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。 本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。 本発明の他の実施形態によるコンテンツについての情報を含むファイルのスキーマを図示する図面である。 本発明の他の実施形態によるコンテンツについての情報を図示する図面である。 本発明の一実施形態によるメディア表現記述のスキーマを図示する図面である。 本発明の一実施形態によるメディア表現記述のスキーマを図示する図面である。 本発明の一実施形態によるメディア表現記述（ＭＰＤ）を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態によるメディア表現記述を図示する図面である。 本発明の一実施形態による複数のメディアデータを図示する図面である。 本発明の一実施形態による複数のメディアデータを図示する図面である。 本発明の一実施形態による複数のメディアデータを図示する図面である。 本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。 本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。 本発明の他の実施形態による複数のメディアデータを図示する図面である。 本発明の他の実施形態による複数のメディアデータを図示する図面である。 本発明の他の実施形態による複数のメディアデータを図示する図面である。 本発明の一実施形態によるデータ提供装置に係わるブロック図である。 本発明の一実施形態による更新時点情報を含むメディア表現記述の構造に係わる一例を示す図面である。 本発明の一実施形態によるデータ受信装置に係わるブロック図である。 本発明の一実施形態によるメディアデータの構成に係わる一例を示す図面である。 図１６に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 図１６に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 本発明の一実施形態によるメディアデータの構成に係わる他の例を示す図面である。 図１８に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 図１８に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 本発明の一実施形態によるメディアデータの構成に係わるさらに他の例を示す図面である。 図２０に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 図２０に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 図２０に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 本発明の一実施形態によるメディアデータの構成に係わるさらに他の例を示す図面である。 図２２に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 図２２に図示されたメディアデータに係わる情報を含むメディア表現記述に係わる一例を示す図面である。 本発明の一実施形態によるデータ提供装置で、メディア表現記述を変更する過程に係わるフローチャートである。 本発明の一実施形態によるデータ提供装置で、追加セグメントが挿入される前のメディア表現記述に係わる一例を示す図面である。 本発明の一実施形態によるデータ提供装置で、追加セグメントが挿入された後のメディア表現記述に係わる一例を示す図面である。 発明の一実施形態によるデータ提供装置で、追加セグメントが挿入された後のメディア表現記述に係わる他の例を示す図面である。 本発明の一実施形態によるデータ提供装置で、追加セグメントの挿入によるメディア表現記述の変化を示す図面である。 本発明の一実施形態によるメディア表現記述とプログラムとの関係に係わる一例を示す図面である。 本発明の一実施形態によるメディア表現記述とプログラムとの関係に係わる一例を示す図面である。 本発明の一実施形態によるメディア表現記述とプログラムとの関係に係わる一例を示す図面である。 本発明の一実施形態によるデータ提供装置及びデータ受信装置間のデータフローを示すフローチャートである。

以下、添付された図面を参考にして、本発明の望ましい実施形態について詳細に説明する。

まず、説明の便宜のために、本明細書で使われる用語を簡単に定義する。

コンテンツの一例は、オーディオ情報、ビデオ情報、オーディオ・ビデオ情報及びデータを含む。コンテンツ・アイテム（content item）は、後述する複数個のコンポーネント（component）から構成される。

コンポーネントは、オーディオ情報、ビデオ情報、サブタイトル情報のように、コンテンツ・アイテムの成分である。一例として、コンポーネントは、特定言語で作成されたサブタイトル・ストリームや、特定カメラ・アングルで獲得したビデオ・ストリームであってもよい。コンポーネントは、コンテナによって、トラックや基本ストリーム（ＥＳ：elementary stream、ＥＳ）と命名することができる。

コンテンツ・リソース（例えば、多様な品質、ビットレート、角度など）は、コンテンツ・アイテムに係わる適応的なストリーミングを可能にするために、複数個のリプリゼンテーション（representation）で提供されるコンテンツ・アイテムである。サービス検索過程は、コンテンツ・リソースと称することができる。コンテンツ・リソースは、一つ以上の連続的なタイムのピリオド（period）から構成される。

ピリオドは、コンテンツ・リソースの時間的なセクションである。

リプリゼンテーションは、ピリオド内のコンテンツ・リソースのバージョン（あらゆるコンポーネントまたは一部のコンポーネント）である。リプリゼンテーションは、コンポーネントのサブセットが異なっているか、あるいはコンポーネントのエンコーディング・パラメータ（例えば、ビットレート）が異なっている。本明細書では、リプリゼンテーションをメディアデータと呼ぶが、一つ以上のコンポーネントを含むデータを指すいかなる用語にも使われもする。

セグメント（segment）は、特定システムレイヤ形式（ＴＳまたはＭＰ４）で、唯一のＵＲＬ（uniform resource locator）を介して称されるリプリゼンテーションの時間的なセクションを意味する。

以下、図面を参照しつつ本発明の実施形態について詳細に説明する。

図１は、本発明の一実施形態によるストリーミング・システムを図示している。

図１を参照すれば、本発明の一実施形態によるストリーミング・システム１００は、エンコーディング装置１１０、サーバ１２０及びクライアント１３０を含む。

エンコーディング装置１１０は、入力されたコンテンツを複数の異なる品質にエンコーディングし、１つのコンテンツに係わる複数のメディアデータを生成する。サーバ１２０がクライアント１３０にメディアデータをストリーミングするとき、ストリーミング環境が変更される。例えば、ストリーミングのためのネットワーク１４０の帯域幅が変更されることもあり、メディアデータを伝送するために、サーバ１２０が使用可能なハードウェア資源またはメディアデータを受信するために、クライアント１３０が使用可能なハードウェア資源が変更されることもある。

従って、エンコーディング装置１１０は、流動的なストリーミング環境による適応的なストリーミングのために、１つのコンテンツを複数の異なる品質にエンコーディングする。ビット率、サンプリング周波数（sampling frequency）または解像度のような因子を調節することによって、１つのコンテンツを複数の異なる品質にエンコーディングすることができる。例えば、１つの動映像コンテンツを、互いに異なる解像度でエンコーディングし、５００Ｋｂｐｓ、１０００Ｋｂｐｓ及び２０００Ｋｂｐｓの複数のメディアデータを生成することができる。

異なる品質にエンコーディングされた複数のメディアデータは、サーバ１２０に伝送され、このとき、コンテンツについての情報及び複数のメディアデータそれぞれについての情報も、共にサーバ１２０に伝送される。コンテンツについての情報は、コンテンツのメタデータであり、コンテンツの題目（title）、シノプシス（synopsis）、コンテンツ識別子（content ＩＤ）、コンテンツＵＲＬ（uniform resource locator）のような情報を含んでもよい。複数のメディアデータに係わる情報は、それぞれのメディアデータの品質、類型及び識別子などを含んでもよいが、これについては、図４Ａ、図４Ｂ及び図４Ｃを参照して詳細に説明する。

クライアント１３０は、コンテンツについての情報及び複数のメディアデータに係わる情報のうち少なくとも一つを受信し、これに基づいて、サーバ１２０に複数のメディアデータのうち、少なくとも１つのメディアデータを要請する。クライアント１３０は、ストリーミング環境を推定（estimation）し、推定されたストリーミング環境に基づいて、複数のメディアデータのうち、少なくとも１つのメディアデータを選択する。推定されたストリーミング環境で、適切なＱｏＳ（quality of service）を維持することができる少なくとも１つのメディアデータを選択することができる。その後、クライアント１３０は、選択された少なくとも１つのメディアデータの伝送を要請するＨＴＴＰ（hypertext transfer protocol）要請（request）をサーバ１２０に伝送することができる。

ストリーミング環境が劣化して高品質のメディアデータを受信すれば、続けてメディアデータを再生することができない場合には、複数のメディアデータのうち、低品質のメディアデータを要請し、ストリーミング環境が改善されて高品質のメディアデータを受信しても、続けてメディアデータを再生することができる場合には、複数のメディアデータのうち、高品質のメディアデータを要請することができる。

所定のメディアデータを受信している最中に、他のメディアデータを伝送することをサーバ１２０に要請することもできる。例えば、ストリーミング環境が劣化した状態で、低品質の第１メディアデータを要請して受信していたクライアント１３０は、ストリーミング環境が改善されることによって、さらに高品質の第２メディアデータを伝送することをサーバ１２０に要請することができる。従来技術によるストリーミング方法によれば、サーバ１２０とクライアント１３０とが、ストリーミング・チャネルを最初に設定するとき、品質を一度設定すれば、続けて同じ品質にメディアデータを送受信せねばならなかった。しかし、本発明によれば、クライアント１３０が低品質の第１メディアデータを受信していても、同じコンテンツに係わるさらに高品質の第２メディアデータをさらに要請することができ、ストリーミング環境による適応的なストリーミングが可能になる。

ネットワーク１４０の帯域幅、及びサーバ１２０またはクライアント１３０の使用可能なハードウェア資源に基づいて、ストリーミング環境を推定する多様な方法がクライアント１３０がストリーミング環境を推定するのに利用される。例えば、クライアント１３０は、受信されるメディアデータのタイムスタンプ及びＢＥＲ（bit error rate）に基づいて、ストリーミング環境を推定することができる。受信されるメディアデータのタイムスタンプを確認し、メディアデータが再生速度より遅い速度で受信されていれば、ストリーミング環境が劣化していると判断することができる。また、受信されるメディアデータのＢＥＲが高まっても、ストリーミング環境が劣化していると判断することができる。

クライアント１３０が、ストリーミング環境によって、複数のメディアデータのうち、少なくとも１つのメディアデータを伝送することを要請すれば、サーバ１２０は、要請されたメディアデータをクライアント１３０に伝送する。ＨＴＴＰ要請に対するＨＴＴＰ応答として、要請されたメディアデータをクライアント１３０に伝送することができる。

複数のメディアデータそれぞれは、コンテンツを異なる品質にエンコーディングし、分割して生成された複数の部分（segment）のうち、少なくとも一つを含んでもよい。言い換えれば、エンコーディング装置１１０のエンコーディングの結果として生成された複数のメディアデータそれぞれは、時間に基づいて分割された少なくとも１つの部分をそれぞれ含んでもよい。サーバ１２０は、コンテンツを１つのストリームにエンコーディングして連続して伝送するのではなく、複数の部分に分割してそれぞれ伝送する。コンテンツを１０秒または２０秒のように、所定の時間単位にコンテンツを分割して複数の部分を生成することができる。分割の基礎になる時間は、ＧＯＰ（group of picture）に基づいて設定することができる。一つまたは二つ以上のＧＯＰのピクチャに対応するメディアデータを１つの部分として設定することができる。

例えば、２種の品質にコンテンツがストリーミングされる場合、第１メディアデータは、コンテンツを第１品質にエンコーディングし、時間に基づいて分割して生成された少なくとも１つの部分を含み、第２メディアデータは、コンテンツを第２品質にエンコーディングし、時間に基づいて分割して生成された少なくとも１つの部分を含んでもよい。

複数のメディアデータを、時間に基づいてそれぞれ分割することによって、前述の適応的なストリーミングが可能になる。例えば、ストリーミングが始まれば、サーバ１２０は、低品質の第１メディアデータの０秒から２０秒に該当する部分を伝送する。その後、２０秒後に、ストリーミング環境が改善されたと判断され、クライアント１３０がさらに高品質のメディアデータを要請すれば、サーバ１２０は、さらに高品質の第２メディアデータの２０秒から４０秒に該当する部分を伝送することができる。メディアデータが、時間に基づいて複数の部分に分割されているために、ストリーミング最中にも、ストリーミング環境によって異なるメディアデータの部分を伝送することができる。

図２Ａは、本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。

図２Ａを参照すれば、段階２１０でクライアント１３０は、所定のコンテンツについての情報を伝送することをサーバ１２０に要請する。クライアント１３０のユーザが、クライアント１３０の画面に表示されたユーザ・インターフェースで所定のコンテンツを選択すれば、選択されたコンテンツについての情報を伝送することをサーバ１２０に要請する。クライアント１３０は、コンテンツについての情報を伝送することを要請するＨＴＴＰ要請をサーバ１２０に伝送することができる。

クライアント１３０から要請を受信したサーバ１２０は、クライアント１３０にコンテンツについての情報を伝送する。ＨＴＴＰ要請に対するＨＴＴＰ応答として、コンテンツについての情報をクライアント１３０に伝送することができる。コンテンツについての情報は、ＯＩＰＦ（open ＩＰＴＶ forum）標準によるＣＡＤ（content access descriptor）であってもよい。図３を参照して詳細に説明する。

図３は、本発明の一実施形態によるコンテンツについての情報を含むファイルのスキーマ（schema）を図示している。コンテンツについての情報を含むファイルは、ＣＡＤであり、ＸＭＬ（eXtensible Markup Language）ファイルであってもよい。以下、本発明の詳細な説明では、タグ（tag）及び属性（attribute）を区分して説明するが、本発明の詳細な説明で、タグによって定義される項目を、タグではない属性によって定義したり、本発明の詳細な説明で、属性によって定義される項目を、属性ではないタグによって定義することができることは、本発明が属する技術分野で当業者であるならば、容易に分かるであろう。

図３を参照すれば、コンテンツについての情報は、「Title」、「Synopsis」、「OriginSite」、「ContentＵＲＬ」タグなどを含んでもよい。

従来技術によるメディアデータのストリーミングは、１つのコンテンツを所定の品質にエンコーディングして１つのメディアデータを生成するので、従来技術によるコンテンツについての情報（特に、ＯＩＰＦによるＣＡＤ）は、コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータに係わる情報を含まない。

しかし、本発明の一実施形態によるコンテンツについての情報は、１つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータに係わる情報を含むが、図３に図示された実施形態の「Tracks」、「ＲｅｆData」及び「Fragments」タグがこれに該当する。

図４Ａは、本発明の一実施形態による複数のメディアデータを定義するための情報を図示している。

図４Ａを参照すれば、「Tracks」タグは、コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータを区分するための情報である。「Tracks」タグは、複数のメディアデータそれぞれに割り当てられた「ＩＤ」属性、「Type」属性及び「BitRate」属性を含む。

「ＩＤ」属性は、メディアデータに対して順に付与される識別子を定義し、「Type」属性は、メディアデータのオーディオデータ、ビデオデータ、ビデオ／オーディオデータ、字幕データのうち、いかなるデータに該当するかを定義する。「Type」属性が「Packed」であるならば、メディアデータがビデオ／オーディオデータであることを示し、「Type」属性が「Video」であるならば、メディアデータがビデオデータであることを示す。「BitRate」属性は、ビデオデータのエンコーディングに利用されたビット率を定義する。

図４Ｂは、本発明の一実施形態によるメディアデータのヘッダについての情報を図示している。

図４Ｂを参照すれば、「ＲｅｆData」タグは、「Type」属性及び「ＩＤ」属性を含む。「Type」属性は、ヘッダがいかなるメディアフォーマットのヘッダであるかを定義する。例えば、「Type」属性が「HEAD−ＴＳ」であるならば、ヘッダが伝送ストリーム（transport stream）フォーマットのヘッダであることを示す。「ＩＤ」属性は、ヘッダが複数のメディアデータのうち、いかなるメディアデータのヘッダであるかを定義する。「ＩＤ」属性が「１」であるならば、メディアデータ識別子が「１」であるメディアデータに係わるヘッダであることを示す。また、「ＲｅｆData」タグは、ヘッダを指示（pointing）する情報を含むが、「ＵＲＬ」タグは、ヘッダの位置、すなわち、ＵＲＬを定義する。

「ＲｅｆData」タグは、選択的な要素である。ヘッダがメディアデータと分離されて別途のファイルとして存在する場合にのみ、コンテンツについての情報に、「ＲｅｆData」タグが含まれ、メディアデータと結合されて存在する場合には、コンテンツについての情報に、「ＲｅｆData」タグが含まれない。

図４Ｃは、本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも１つの部分についての情報を含む。

図４Ｃを参照すれば、「Fragments」タグの下位タグである「Fragment」タグに、複数のメディアデータそれぞれに含まれた少なくとも１つの部分についての情報が含まれる。

「Fragments」タグは、「NextFragmentsＸＭＬＵＲＬ」属性を含む。ライブストリーミングのように、１つのコンテンツ・ストリーミングが完了すれば、次のコンテンツが続けてストリーミングされる場合には、次にストリーミングされるコンテンツについての情報を、クライアント１３０があらかじめ知っていてこそ、切れ目なくコンテンツをストリーミングすることができる。従って、「Fragments」タグは、次にストリーミングされるコンテンツについての情報を、「NextFragmentsＸＭＬＵＲＬ」属性と定義する。次に、ストリーミングされるコンテンツに係わる複数のメディアデータのＵＲＬが「NextFragmentsＸＭＬＵＲＬ」属性と定義される。

「Fragment」タグは、現在ストリーミングされるコンテンツの少なくとも１つの部分についての情報を含む。図４Ｃに図示された実施形態を例に挙げて説明すれば、第１メディアデータとして、コンテンツを第１品質にエンコーディングして生成された最初の部分である「slice１−１．as」のＵＲＬ情報が、「ＵＲＬ」タグによって定義され、対応するヘッダの識別子が「ＲｅｆPointer」タグによって定義される。また、最初の部分の開始時間が「StartTime」属性によって定義され、それぞれの部分の持続時間が「Duration」属性によって定義される。第１メディアデータの品質は、「BitRate」属性によって定義される。

図４Ｃに図示された実施形態では、「Fragments」タグは、それぞれのメディアデータが１つの部分だけを含む場合を図示した。しかし、本発明が属する技術分野で当業者であるならば、図１と関連して述べたように、それぞれのメディアデータが複数の部分に分割される場合、１つの「Fragments」タグが、２以上の部分についての情報を含んでもよいことが容易に分かる。

再び図２Ａを参照すれば、段階２２０でクライアント１３０は、複数のメディアデータのうち、少なくとも１つのメディアデータを伝送することをサーバ１２０に要請する。複数のメディアデータは、１つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータである。クライアント１３０は、複数のメディアデータのうち、ストリーミング環境に適した品質に符号化された少なくとも１つのメディアデータを選択してサーバ１２０に要請する。クライアント１３０は、コンテンツについての情報に含まれた複数のメディアデータに係わる情報に基づいて、ＨＴＴＰ要請をサーバ１２０に伝送することができる。

コンテンツについての情報は、図４Ｃと関連して述べたように、「Fragments」タグを含んでいる。従って、クライアント１３０は、「Fragments」タグに含まれたＵＲＬ情報に基づいて、選択されたメディアデータの伝送をサーバ１２０に要請する。
クライアント１２０の要請によってサーバ１２０は、メディアデータを伝送する。要請されたメディアデータの少なくとも１つの部分をクライアント１２０に伝送することができる。ＨＴＴＰ要請に対するＨＴＴＰ応答として、要請されたメディアデータをクライアント１２０に伝送することができる。

図２Ｂは、本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。図２Ｂは、ヘッダがメディアデータと分離され、別途のファイルとして存在する場合のストリーミング方法を図示している。

図２Ｂを参照すれば、段階２１２でクライアント１３０は、所定のコンテンツについての情報を伝送することをサーバ１２０に要請し、サーバ１２０からコンテンツについての情報を伝送される。図２Ａの段階２１０に図示される。図４Ｂと関連して述べた「ＲｅｆData」タグを含むコンテンツについての情報を受信する。

段階２２２でクライアント１３０は、段階２１０で受信されたコンテンツについての情報に基づいて、複数のメディアデータのうち選択されたメディアデータのヘッダを要請する。段階２１２で受信されたコンテンツについての情報に基づいて、複数のメディアデータのうち、ストリーミング環境に適した少なくとも１つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階２１２で受信されたコンテンツについての情報に含まれた「ＲｅｆData」タグを参照し、選択されたメディアデータのヘッダを要請する。

サーバ１２０は、要請されたメディアデータのヘッダをクライアント１３０に伝送する。ヘッダファイルをクライアント１３０に伝送することができ、ヘッダファイルは、ＸＭＬファイルであってもよい。

段階２３２でクライアント１３０は、段階２１２で受信されたコンテンツについての情報及び段階２２２で受信されたヘッダに基づいて、選択されたメディアデータの伝送をサーバ１２０に要請する。メディアデータを時間に基づいて分割して生成された少なくとも１つの部分を伝送することをサーバ１３０に要請し、サーバ１２０は、要請された少なくとも１つの部分をクライアント１３０に伝送する。

図５Ａは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。

図５Ａを参照すれば、段階５１０でクライアント１３０は、所定のコンテンツについての情報を伝送することをサーバ１２０に要請し、サーバ１２０から、コンテンツについての情報を伝送する。所定のコンテンツについての情報を伝送することを要請するＨＴＴＰ要請をサーバ１２０に伝送し、これに対するＨＴＴＰ応答として、コンテンツについての情報を受信する。コンテンツについての情報を含むＸＭＬファイルを受信することができる。段階５１０でクライアント１３０が受信するコンテンツについての情報は、図２の段階２１０でクライアント１３０が受信するコンテンツについての情報と異なるが、図６及び図７を参照して詳細に説明する。

図６は、本発明の他の実施形態によるコンテンツについての情報を含むファイルのスキーマを図示している。

図６を参照すれば、本発明の一実施形態によるコンテンツについての情報は、図３と同一に、「Title」タグ、「Synopsis」タグ、「OriginSite」タグ、「ContentＵＲＬ」タグなどを含んでもよい。

しかし、図３に図示された実施形態では、コンテンツについての情報が「Tracks」タグ、「ＲｅｆData」タグ及び「Fragments」タグを含むことによって、複数のメディアデータに係わる情報も共に含むのに対し、図６に図示された実施形態では、コンテンツについての情報が、複数のメディアデータに係わる情報を含むのではなく、複数のメディアデータに係わる情報を含むファイル（以下、メディア表現記述（ＭＰＤ：media presentation description）とする）のＵＲＬだけ定義することが異なる。「ContentＵＲＬ」タグによって、ＭＰＤのＵＲＬが定義される。

図６に図示されているように、従来技術による多様なコンテンツについての情報ファイルのスキーマを大きく変更せず、ＭＰＤのＵＲＬだけコンテンツについての情報ファイルに挿入することによって、多様なメディアデータ・フォーマットとの互換性を維持しつつ、ストリーミング環境に適応的なストリーミングが可能になる。

図６に図示されたところによれば、コンテンツについての情報は、複数のメディアデータに係わる情報は含まず、ストリーミング方法と関連した情報だけ含んでもよい。言い換えれば、「ContentＵＲＬ」タグは、ストリーミングに利用されるメディアデータのフォーマットを定義する「MediaFormat」属性、メディアデータの種類を定義する「ＭＩＭＥType」属性などを含んでもよい。

特に、「ContentＵＲＬ」タグは、コンテンツのストリーミングが、いかなるサービスと関連しているかを定義する「TransferType」属性を含んでもよい。「TransferType」属性は、コンテンツのストリーミングがＣｏＤ（content on delivery）サービス、生中継（live）、適応ストリーミング生中継（adaptive streaming live）及び適応ストリーミングＣｏＤ（adaptive streaming ＣｏＤ）のうち、いかなるサービスと関連しているかを定義することができる。

図７は、本発明の他の実施形態によるコンテンツについての情報を図示している。図７は、ＯＩＰＦ標準によるＣＡＤであってもよい。

図７を参照すれば、図６に図示されたスキーマによって生成されたコンテンツについての情報は、「ContentＵＲＬ」タグに、ＭＰＤのＵＲＬが定義される。「ｈｔｔｐ：／／asexample．com／ｖｏｄ／movies／１８８８８／Meta／MainMeta．ｘｍｌ」がＭＰＤのＵＲＬである。また、図６と関連して述べたように、「MediaFormat」属性、「ＭＩＭＥType」属性及び「TransferType」属性などが、「ContentＵＲＬ」タグに定義される。

再び図５Ａを参照すれば、段階５２０でクライアント１３０は、段階５１０で受信されたコンテンツについての情報に基づいて、複数のメディアデータに係わる情報をサーバ１２０に要請する。ＭＰＤを、ＨＴＴＰ要請を介してサーバ１２０に要請し、ＨＴＴＰ応答として、ＭＰＤを受信することができる。

段階５１０でクライアント１３０がサーバ１２０から受信したコンテンツについての情報は、図６及び図７と関連して述べたように、ＭＰＤのＵＲＬ情報を含んでもよいが、クライアント１３０は、コンテンツについての情報の「ContentＵＲＬ」タグを参照し、ＭＰＤをサーバ１２０に要請して受信する。ＭＰＤについては、図８Ａ、図８Ｂ、図９Ａないし図９Ｈを参照して詳細に説明する。

図８Ａ及び図８Ｂは、本発明の一実施形態によるＭＰＤのスキーマを図示している。ＭＰＤは、ＯＩＰＦ標準によるＭＰＤであってもよい。

図８Ａを参照すれば、本発明の一実施形態によるＭＰＤは、複数のメディアデータのＵＲＬに係わるテンプレート（template）タグ、ヘッダの位置を定義するためのタグ、ストリーミングがいかなるサービスと関連しているかを定義するためのタグ、メディアデータコンテナ（container）・フォーマットを定義するためのタグ、及び複数のメディアデータを定義するためのタグを含む。

「ｕｒｌTemplate」タグは、複数のメディアデータに係わるＵＲＬ情報の共通部分を定義する。例えば、「ｈｔｔｐ：／／example．com／ｖｏｄ／movie／１８８８８／Track／｛TrackＩＤ｝／Segments／｛SegmentＩＤ｝」がＵＲＬテンプレートであるならば、「TrackＩＤ」及び「SegmentＩＤ」に複数のメディアデータそれぞれの識別子、及びそれぞれのメディアデータに含まれた少なくとも１つの部分の識別子を代入することにより、メディアデータに係わるＵＲＬを定義することができる。

「headerＵｒｌ」タグは、図４Ｂと関連して述べた「ＲｅｆData」タグに対応する。言い換えれば、複数のメディアデータのヘッダＵＲＬを定義する。

「isLive」タグは、ストリーミングがいかなるサービスと関連しているかを定義するタグである。例えば、「isLive」タグが「Live」と定義されれば、ストリーミングが生放送サービスと関連していることを示し、「isLive」タグが「ＣｏＤ」と定義されれば、ストリーミングがＣｏＤサービスと関連していることを示す。

「contentType」タグは、ストリーミングに利用されるメディアデータのコンテナ・フォーマットを定義する。例えば、メディアデータのコンテナ・フォーマットがＭＰ４フォーマットであるか、あるいはＭＰＥＧ２−ＴＳフォーマットであるかを示すための情報である。

「Stream」タグは、複数のメディアデータそれぞれについて生成され、複数のメディアデータそれぞれを定義する。１つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータそれぞれを定義するために、「streamName」属性、「type」属性、「bitrate」属性、「startTime」属性、「firstIntervalＮｕｍ」属性、「duration」属性及び「intervalCount」属性を含む。

「streamName」属性は、メディアデータの名称を定義する。メディアデータの識別子であってもよい。「type」属性は、メディアデータの類型を定義する。メディアデータがオーディオデータ、ビデオデータ及びオーディオ／ビデオデータのうち、いかなるメディアのデータであるかを定義する。メディアデータが、変速再生（trick play）のために、Ｉフレームに係わるデータだけ含む場合には、これについての情報が「type」属性と定義される。

「BitRate」属性は、メディアデータのビット率を定義し、「startTime」属性は、メディアデータの開始時間を特定するタイムスタンプを定義し、「firstIntervalＮｕｍ」属性は、最初に始まる部分の番号を定義する。

「duration」属性は、メディアデータに含まれた部分の持続時間を定義し、「intervalCount」属性は、メディアデータに含まれた少なくとも１つの部分の全体個数を定義する。

「Segment」タグは、「Stream」タグの下位タグであり、メディアデータが前述のように、コンテンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも１つの部分であるならば、このような少なくとも１つの部分それぞれを定義する。

「ＩｎｔＮｕｍ」属性は、部分の番号を定義し、「StartTime」は、当該部分の開始時間を定義する。「Duration」は、当該部分の持続時間を定義し、「ｕｒｌ」は、当該部分のＵＲＬ情報を定義する。

「Segment」タグは、選択的なタグであり、メディアデータに含まれた少なくとも１つの部分についての情報が、「Stream」タグの他の属性から類推される場合には、ＭＰＤに含まれない。言い換えれば、「Stream」タグに定義された「startTime」属性、「firstIntervalＮｕｍ」属性、「duration」属性及び「intervalCount」属性によって「Stream」タグから類推される場合には、ＭＰＤに含まれない。また、「ｕｒｌTemplate」タグに所定のテンプレートが定義されており、このように定義されたテンプレートに、複数のメディアデータそれぞれの識別子、及びそれぞれのメディアデータに含まれた少なくとも１つの部分の識別子を代入することにより、部分のＵＲＬ情報を類推することができれば、「Segment」タグの「ｕｒｌ」属性は、不要でもある。

図８Ｂを参照すれば、本発明の他の実施形態によるＭＰＤは、「nextManifestＵＲＬ」タグをさらに含んでもよい。前述のように、ライブストリーミングまたは広告の挿入のように、１つのコンテンツ・ストリーミングが完了すれば、次のコンテンツが続けてストリーミングされる場合には、次にストリーミングされるコンテンツについての情報をクライアント１３０があらかじめ知っていてこそ、切れ目なくコンテンツをストリーミングすることができるので、現在ストリーミング中であるコンテンツの次にストリーミングされるコンテンツのＭＰＤのＵＲＬ情報が、「nextManifestＵＲＬ」タグによって定義される。

図９Ａないし図９Ｈは、本発明の一実施形態によるＭＰＤを図示している。

図９Ａを参照すれば、本発明の一実施形態によるＭＰＤは、「ＵＲＬTemplate」タグ、「ＲｅｆDataＵＲＬ」タグ、及び複数のメディアデータそれぞれを定義する複数のタグを含む。

「ＵＲＬTemplate」タグ及び「ＲｅｆDataＵＲＬ」タグは、それぞれ図８Ａ及び図８Ｂの「ｕｒｌTemplate」タグ及び「ＲｅｆDataＵＲＬ」タグに対応する。

「ＩＤ」属性、「Type」属性、「BitRate」属性、「StartTime」属性、「SegmentDuration」属性、「SegmentStartＩＤ」属性及び「SegmentCount」属性は、それぞれ図８Ａ及び図８Ｂの「streamName」属性、「type」属性、「bitrate」属性、「startTime」属性、「Stream」タグの「duration」属性、「Stream」タグの「firstIntervalＮｕｍ」属性及び「intervalCount」属性に対応する。

図９Ａに図示されたＭＰＤは、コンテンツが異なる品質に生成された３種のビデオデータ、１つのオーディオデータ、及び変速再生のためにＩフレームのみエンコーディングして生成されたメディアデータに係わる情報を含む。

図９Ｂを参照すれば、本発明の一実施形態によるＭＰＤは、「NextAdaptiveControlＵＲＬ」タグをさらに含む。「NextAdaptiveControlＵＲＬ」タグは、図８Ｂの「nextManifestＵＲＬ」タグに対応する。従って、現在再生中であるコンテンツの次に続けて再生するコンテンツのＭＰＤのＵＲＬが「NextAdaptiveControlＵＲＬ」タグによって定義される。

図９Ｃは、現在再生中であるコンテンツに続けて再生するコンテンツのＭＰＤのＵＲＬが、図９Ｂの「NextAdaptiveControlＵＲＬ」タグによって定義されたとき、次に続けて再生するコンテンツのＭＰＤを図示している。図９ＢのＭＰＤと比較すれば、図９Ｃは、次に続けて再生されるコンテンツのＭＰＤであるから、「StartTime」属性の現在再生中であるコンテンツのＭＰＤと異なる。

図９Ｄ及び図９Ｅは、ユーザの高画質ビデオ再生を選択的に制御するためのＭＰＤを図示している。１つのコンテンツを５種の異なる品質にエンコーディングして複数のメディアデータが生成され、図９Ｄは、この場合、ＭＰＤを図示する。しかし、図９Ｅに図示されたＭＰＤで、高品質にエンコーディングされたビデオについての情報を含んでいるタグ、すなわち、「ＩＤ」属性が「５」であるメディアデータの「StartTime」属性及び「SegmentCount」属性が図９ＤのＭＰＤと異なる。

サーバ１２０は、クライアント１３０のユーザ等級によって、図９ＤのＭＰＤまたは図９ＥのＭＰＤを選択的に伝送することができる。クライアント１３０のユーザ等級が高い場合（例えば、クライアント１３０が有料ユーザである場合）には、図９ＤのＭＰＤを伝送することによって、高品質のビデオも自由に再生させ、クライアント１３０のユーザ等級が低い場合（例えば、クライアント１３０が無料ユーザである場合）には、図９ＥのＭＰＤを伝送することによって、高品質のビデオは、「StartTime」属性によって定義された時間から、「SegmentCount」属性によって定義された部分だけ再生させる。

図９Ｆは、コンテンツに広告が挿入される場合のＭＰＤを図示している。図９Ｆを参照すれば、ＭＰＤは、「StartTime」属性が異なる広告コンテンツ及びメインコンテンツについての情報を含んでもよい。ＭＰＤは、「００：００：００」から「００：０２：００」まで再生されるビット率が、「５０００００」である広告コンテンツについての情報、及び「００：０２：００」から再生されるビット率が、「１００００００」、「２００００００」、「３００００００」及び「４００００００」であるメインコンテンツについての情報を含んでもよい。サーバ１２０が、広告コンテンツを１つのビット率によってエンコーディングしてクライアント１３０に提供し、広告コンテンツと「StartTime」属性を異にするメインコンテンツは、４種の異なるビット率によってエンコーディングし、クライアント１３０に提供する場合、図９ＦのＭＰＤが、サーバ１２０からクライアント１３０に伝送される。

図９Ｇは、本発明の一実施形態による広告コンテンツについての情報を含むＭＰＤを図示している。メインコンテンツを提供するサーバと、広告コンテンツを提供するサーバとが異なっていてもよい。言い換えれば、クライアント１３０が、メインコンテンツは、図５Ａのサーバ１２０から提供され、広告コンテンツは、図５Ａのサーバ１２０ではない他のサーバから受信する場合、広告コンテンツについての情報を含むＭＰＤは、広告コンテンツのＵＲＬ情報を含んでもよい。図９Ｇに図示されているように、１つの品質に符号化された広告コンテンツのＵＲＬ情報がＭＰＤに含まれもする。

図９Ｈは、本発明の一実施形態による言語情報及び字幕情報を含むＭＰＤを図示している。図９Ｈを参照すれば、オーディオデータは、多重言語についての情報を含んでもよい。「ＩＤ」属性が「４」及び「５」である多重言語のオーディオデータに係わる情報がＭＰＤに含まれ、「ＩＤ」属性が「６」及び「７」である多重言語の字幕についての情報がＭＰＤに含まれもする。

オーディオデータはもとより、字幕も経時的に複数の部分に分割されもするので、ストリーミング最中に、オーディオデータ及び字幕を異なる言語のオーディオデータ及び字幕に変更することができる。

再び図５Ａを参照すれば、段階５３０でクライアント１３０は、複数のメディアデータのうち、少なくとも１つのメディアデータを伝送することをサーバ１２０に要請する。クライアント１３０は、複数のメディアデータに係わる情報を参照し、ストリーミング環境に適した品質に符号化された少なくとも１つのメディアデータを選択してサーバ１２０に要請する。クライアント１３０は、所定のメディアデータを伝送することを要請するＨＴＴＰ要請をサーバ１２０に伝送することができる。クライアント１２０の要請によってサーバ１２０は、メディアデータを伝送する。コンテンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも１つの部分をクライアント１２０に伝送することができる。ＨＴＴＰ要請に対するＨＴＴＰ応答として、要請されたメディアデータをクライアント１２０に伝送することができる。

図５Ｂは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。

図５Ｂを参照すれば、段階５１２でクライアント１３０は、所定のコンテンツについての情報を伝送することをサーバ１２０に要請し、サーバ１２０からコンテンツについての情報を伝送する。所定のコンテンツについての情報を伝送することを要請するＨＴＴＰ要請をサーバ１２０に伝送し、これに対するＨＴＴＰ応答として、コンテンツについての情報を受信する。コンテンツについての情報を含むＸＭＬファイルを受信することができる。

段階５２２でクライアント１３０は、段階５１２で受信されたコンテンツについての情報に基づいて、複数のメディアデータに係わる情報をサーバ１２０に要請する。ＭＰＤをＨＴＴＰ要請を介してサーバ１２０に要請し、ＨＴＴＰ応答としてＭＰＤを受信することができる。

段階５３２でクライアント１３０は、段階５２２で受信された複数のメディアデータに係わる情報に基づいて、選択されたメディアデータのヘッダを要請する。段階５２２で受信された情報に基づいて、複数のメディアデータのうちストリーミング環境に適した少なくとも１つのメディアデータを選択して選択されたメディアデータのヘッダを要請する。段階５２２で受信された複数のメディアデータに係わる情報を参照し、選択されたメディアデータのヘッダを要請する。サーバ１２０は、要請に対する応答として、選択されたメディアデータのヘッダファイルをクライアント１３０に伝送する。

段階５４２でクライアント１３０は、段階５２２で受信された複数のメディアデータに係わる情報、及び段階２２２で受信されたヘッダに基づいて、選択されたメディアデータの伝送をサーバ１２０に要請する。コンテンツを所定の比率でエンコーディングし、時間に基づいて分割して生成された少なくとも１つの部分を伝送することをサーバ１３０に要請し、サーバ１２０は、要請された少なくとも１つの部分をクライアント１３０に伝送する。

図１０Ａないし図１０Ｃは、本発明の一実施形態による複数のメディアデータを図示している。図１０Ａないし図１０Ｃは、図５Ａ及び図５Ｂによるストリーミング方法を遂行するために、サーバ１２０が保有する複数のメディアデータを図示している。

図１０Ａを参照すれば、ストリーミング環境に適応的なストリーミングのためにサーバ１２０は、１つのコンテンツを複数の異なる品質にエンコーディングして生成された複数のメディアデータ１０１０ないし１０３０を保有することができる。「Track１」、「Track２」、…、「TrackＮ」が複数のメディアデータである。また、それぞれのメディアデータは、それぞれのメディアデータを時間に基づいて分割して生成された少なくとも１つの部分を含んでもよい。「Slice１−１．as」、「Slice１−２．as」、「Slice１−３．as」、「Slice２−１．as」、「Slice２−２．as」、「Slice２−３．as」、「SliceＮ−１．as」、「SliceＮ−２．as」、「SliceＮ−３．as」などが少なくとも１つの部分である。

またサーバ１２０は、クライアント１３０が複数のメディアデータにアクセスするために必要な情報１０４０を保有することができる。コンテンツについての情報として、「CadMeta．ｘｍｌ」ファイル、複数のメディアデータに係わる情報として、「MainMeta．ｘｍｌ」ファイルを保有することができ、複数のメディアデータのヘッダとして、「Head１．ｒｅｆ」ファイル、「Head２．ｒｅｆ」ファイルなどを保有することができる。「Head１．ｒｅｆ」は、「Track１」のヘッダファイルであって、「Head２．ｒｅｆ」は、「Track２」のヘッダファイルである。

「CadMeta．ｘｍｌ」は、ＯＩＰＦ標準によるＣＡＤファイルであって、「MainMeta．ｘｍｌ」は、前述のＭＰＤであってもよい。また、「Head１．ｒｅｆ」ファイル、「Head２．ｒｅｆ」ファイルは、選択的な要素であり、ヘッダが、複数のメディアデータ１０１０ないし１０３０に含まれている場合には、存在しないこともある。

図１０Ｂを参照すれば、クライアント１３０が、複数のメディアデータにアクセスするために必要な情報１０４２は、「NextMeta．ｘｍｌ」をさらに含んでもよい。前述のように、「NextMeta．ｘｍｌ」は、現在再生中であるコンテンツに続けて再生される次のコンテンツのＭＰＤであってもよい。前述のように、現在再生中であるＭＰＤ、すなわち、「MainMeta．ｘｍｌ」ファイルは、続けて再生するコンテンツのＭＰＤのＵＲＬ情報を含んでいるが、これに基づいてクライアント１３０は、「NextMeta．ｘｍｌ」ファイルにアクセスしてもよい。

図１０Ｃを参照すれば、複数のメディアデータのヘッダは、１つのファイル１０５０として存在しうる。ヘッダファイルが複数のメディアデータそれぞれについて、複数で存在するのではなく、１つのヘッダファイル１０５０として、複数のメディアデータにアクセスするために必要な情報１０４４に含まれもする。

例えば、複数のメディアデータそれぞれが、ＭＰＥＧ−２によるエレメンタリーストリーム（elementary stream）に対応するとき、複数のメディアデータのヘッダは、ＰＡＴ（program association table）及びＰＭＴ（program map table）のうち、少なくとも一つを含む１つのヘッダファイル１０５０であってもよい。ＰＡＴ及びＰＭＴのうち少なくとも一つを、複数のメディアデータ１０１０ないし１０３０と分離して１つのヘッダファイル１０５０を作り、ＭＰＤは、このヘッダファイル１０５０を指示（pointing）する情報を含んでもよい。ヘッダファイル１０５０の指示情報は、ヘッダファイル１０５０のＵＲＬ情報でもあり、ＭＰＥＧ−２伝送ストリーム（transport stream）で、ヘッダファイル１０５０を含んでいるパケットを特定するための情報でもある。

前述の段階５３２でクライアント１３０は、ＭＰＤを参照し、ヘッダファイル１０５０の指示情報を獲得し、指示情報に基づいて、ヘッダファイル１０５０を要請することができる。ヘッダファイル１０５０への指示情報に基づいて、ヘッダファイル１０５０を要請して受信した後、ヘッダファイル１０５０に含まれているＰＡＴ及びＰＭＴのうち、少なくとも一つに基づいて、複数のメディアデータのうち少なくとも一つを選択し、選択されたメディアデータをサーバ１２０に要請する。ＰＡＴ及びＰＭＴは、複数のメディアデータ１０１０ないし１０３０の全体リストを含む。

ＭＰＥＧ−２によれば、ＰＡＴ及びＰＭＴで定義されるＰＩＤ（packet ＩＤ）は、エレメンタリーストリームによって異なる。従って、複数のメディアデータそれぞれに割り当てられるＰＩＤは異なっていてもよい。しかし、他の実施形態によれば、１つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータは、同じコンテンツに係わるエレメンタリーストリームであるから、ＰＩＤが同一に設定されもする。

複数のメディアデータ１０１０ないし１０３０が、ＭＰＥＧ−２による複数のエレメンタリーストリームに対応する場合、複数のメディアデータ１０１０ないし１０３０それぞれは、複数の連続したＰＥＳ（packetized elementary stream）を含んでもよい。

複数のメディアデータは、１つのコンテンツを異なる品質にエンコーディングして生成されたものであるので、複数のメディアデータそれぞれに含まれたＰＥＳのＰＴＳ（presentation time stamp）及び／またはＤＴＳ（decoding time stamp）は、メディアデータの再生時間によって整列（aligned）される。言い換えれば、第１メディアデータの最初のＰＥＳと、第２メディアデータの最初のＰＥＳとが同じ時間に再生されるコンテンツであるならば、ＰＴＳ及び／またはＤＴＳが同一に設定される。

図１１Ａは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。

図１１Ａを参照すれば、段階１１１０でクライアント１３０は、複数のメディアデータに係わる情報をサーバ１２０に要請する。ＭＰＤをＨＴＴＰ要請を介してサーバ１２０に要請し、ＨＴＴＰ応答としてＭＰＤを受信することができる。クライアント１３０は、ストリーミング環境に適応的なストリーミングを遂行するために、１つのコンテンツを複数の異なる品質にエンコーディングして生成された複数のメディアデータに係わる情報を、サーバ１２０に要請して受信する。コンテンツについての情報の要請及び受信なしに、複数のメディアデータに係わる情報の要請及び受信が行われるという点が図５Ａに図示された実施形態と異なる。

段階１１２０でクライアント１３０は、複数のメディアデータのうち、少なくとも１つのメディアデータを伝送することをサーバ１２０に要請する。クライアント１３０は、複数のメディアデータに係わる情報を参照し、ストリーミング環境に適した品質に符号化された少なくとも１つのメディアデータを選択してサーバ１２０に要請し、要請されたメディアデータをサーバ１２０から受信する。

図１１Ｂは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。

図１１Ｂを参照すれば、段階１１１２でクライアント１３０は、複数のメディアデータに係わる情報をサーバ１２０に要請し、要請に対する応答として、複数のメディアデータに係わる情報をサーバ１２０から受信する。ＭＰＤをＨＴＴＰ要請を介してサーバ１２０に要請し、ＨＴＴＰ応答としてＭＰＤを受信することができる。

段階１１２２でクライアント１３０は、段階１１１２で受信された複数のメディアデータに係わる情報に基づいて、選択されたメディアデータのヘッダを要請する。段階５２２で、受信された複数のメディアデータに係わる情報を参照し、ストリーミング環境によって選択されたメディアデータのヘッダを要請する。サーバ１２０は、要請に対する応答として、選択されたメディアデータのヘッダを含むファイルをクライアント１３０に伝送する。

段階１１３２でクライアント１３０は、段階１１１２で受信された複数のメディアデータに係わる情報及び段階１１２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。コンテンツを所定の比率でエンコーディングし、時間に基づいて分割して生成された少なくとも１つの部分を伝送することをサーバ１３０に要請し、サーバ１２０は、要請された少なくとも１つの部分をクライアント１３０に伝送する。

図１２Ａ及び図１２Ｂは、本発明の他の実施形態による複数のメディアデータを図示している。図１２Ａ及び図１２Ｂは、図１１Ａ及び図１１Ｂによるストリーミング方法を遂行するために、サーバ１２０が保有する複数のメディアデータを図示している。

図１２Ａを参照すれば、図１０Ａに図示された実施形態と同様に、ストリーミング環境に適応的なストリーミングのためにサーバ１２０は、１つのコンテンツを複数の異なる品質にエンコーディングして生成された複数のメディアデータ１０１０ないし１０３０を保有することができる。

クライアント１３０が複数のメディアデータにアクセスするために必要な情報１２４０だけ異なるが、図１０Ａに図示された実施形態とは異なり、サーバ１２０は、コンテンツについての情報を除外した複数のメディアデータに係わる情報だけ含んでもよい。この場合、クライアント１３０は、コンテンツについての情報をサーバ１２０ではない他のエンティティから受信し、コンテンツについての情報に基づいて、サーバ１２０が保有している複数のメディアデータにアクセスすることも可能である。

図１２Ｂを参照すれば、クライアント１３０が複数のメディアデータにアクセスするために必要な情報１２４２は、図１２Ａの情報１２４０に「NextMeta．ｘｍｌ」をさらに含んでもよい。

図１３は、本発明の一実施形態によるデータ提供装置１３００に係わるブロック図を示している。

本発明の一実施形態によるデータ提供装置１３００は、生成部１３１０、伝送部１３２０及び要請受信部１３３０を含んでもよい。

生成部１３１０は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータに係わる情報が含まれた付加情報を生成する。付加情報は、メディアデータに係わる情報を含むいかなる形態のデータも可能であり、一例として、図１ないし図１２で説明したＭＰＤであってもよい。以下、説明の便宜のために付加情報がＭＰＤであると仮定する。

ＭＰＤは、メディアデータに係わる接近情報を含む。メディアデータは、一つ以上のセグメントから構成され、ＭＰＤは、セグメントそれぞれに対されるアクセス情報を含む。１つのＭＰＤが１つのメディアデータ全体についての情報を含んでもよいが、一部区間についての情報だけを含んでもよい。一例として、メディアデータを所定の基準によって、複数個の区間に区分し、それぞれの区間に対応する複数個のＭＰＤを生成することができる。メディアデータを利用して、ライブストリーミング・サービスを提供する場合、ＭＰＤがメディアデータ全体についての情報を含むことになれば、データの容量が大きくなり、ユーザが所望の情報を検索するのが困難であるために、それぞれの区間に対応する複数個のＭＰＤを生成することが望ましい。

以下、説明の便宜のために、メディアデータ内の連続する２つの区間を、第１区間及び第２区間と命名し、第１区間についての情報を含むＭＰＤを第１ＭＰＤ、第２区間についての情報を含むＭＰＤを第２ＭＰＤと命名する。

ＭＰＤに対応する区間を決定する方法は、実施形態によって多様である。

第一に、実施形態によって連続する区間のオーバーラッピングいかんを異にすることがある。

一実施形態では、連続する区間がオーバーラッピングされる。例えば、第１区間の終端部分に含まれた一つ以上のセグメントが、第２区間の開始部分に含まれもする。この場合、第１区間と第２区間とがオーバーラッピングされる領域に位置するセグメントに係わる情報は、第１ ＭＰＤ及び第２ ＭＰＤにいずれも含まれる。連続する区間がオーバーラッピングされる場合には、第１区間がいずれも処理される前に第２ ＭＰＤが受信されるので、データ受信装置１５００は、第２区間を処理することができる余裕時間を確保することができる。この方法は、第１ ＭＰＤ及び第２ ＭＰＤの属性構造が異なり、第１ ＭＰＤ及び第２ ＭＰＤの同期化が必要な場合に特に有用である。

他の実施形態では、連続する区間がオーバーラッピングされない。この場合、第１区間がいずれも処理される時点で第２ ＭＰＤが受信される。このような方法は、第１ ＭＰＤ及び第２ ＭＰＤの属性構造が同一であり、第１ ＭＰＤ及び第２ ＭＰＤの同期化が必要ない場合に特に有用である。

第二に、実施形態によって区間が分割される基準を異にすることができる。

一実施形態では、メディアデータに含まれたプログラムによって区間を分割することができる。一例として、第１プログラムが提供される区間を第１区間として、第２プログラムが提供される区間を第２区間として設定することができる。この場合、それぞれの区間は異なる長さを有することができる。

他の実施形態では、メディアデータを同じ時間間隔を有する区間に分割することができる。一例として、メディアデータ内の開始位置から「０：１０：００」までを第１区間と、「００：１０：０１」から「００：２０：００」までを第２区間として設定することができる。この場合、ＭＰＤとプログラとの１：１マッピング関係が成立しないこともある。

実施形態によっては、第１ ＭＰＤ及び第２ ＭＰＤが相互間に互換が可能でもあり、あるいはそうではないことも可能である。

一実施形態では第１ ＭＰＤ及び第２ ＭＰＤの互換が可能である。

第１ ＭＰＤ及び第２ ＭＰＤの互換が可能であるという意味は、第１ ＭＰＤの属性構造と第２ ＭＰＤの属性構造とが同一であるということを意味する。具体的には、第１ ＭＰＤ内及び第２ ＭＰＤ内の同じＩＤを有するリプリゼンテーションが同じ属性構造を有するので、第１ ＭＰＤに含まれたセグメント・リストと、第２ ＭＰＤに含まれたセグメント・リストとの構造が同一である。従って、データ受信装置１５００は、第２ ＭＰＤに含まれた属性が、第１ ＭＰＤ内のいかなる属性に対応するかを判断する同期化過程なしに、第２ ＭＰＤを直ちに使用することができる。

第１ ＭＰＤ及び第２ ＭＰＤが互換が可能である場合は、第１ ＭＰＤ及び第２ ＭＰＤが同じ名称のファイルを介して獲得される場合を含んでもよい。この場合、第１ ＭＰＤ及び第２ ＭＰＤは、同じＵＲＬを介して獲得される。

他の実施形態では、第１ ＭＰＤ及び第２ ＭＰＤが互換が不可能である。

第１ ＭＰＤ及び第２ ＭＰＤが互換が不可能であるという意味は、第１ ＭＰＤの属性構造と、第２ ＭＰＤの属性構造とが異なるということを意味する。従って、データ受信装置１５００は、第２ ＭＰＤに含まれた属性が、第１ ＭＰＤ内のいかなる属性に対応するかを判断する同期化過程が必要である。

第１ ＭＰＤ及び第２ ＭＰＤが互換が不可能である場合は、第１ ＭＰＤ及び第２ ＭＰＤが異なった名称のファイルを介して獲得される場合を含む。この場合、第１ ＭＰＤ及び第２ ＭＰＤは、他のＵＲＬを介して獲得される。

第１ ＭＰＤには、第１ ＭＰＤがアップデートされる時点（または、第１ ＭＰＤが有効性が保証される時間の長さ）を示す更新時点情報、第２ ＭＰＤに係わる位置情報、第１区間を介して提供されるプログラムのＩＤ、第１区間の開始位置、第１区間の終了位置のうち、少なくとも一つを含んでもよい。

第２ ＭＰＤに係わる位置情報は、データ受信装置１５００が第２ ＭＰＤに係わる位置情報を知らない場合にのみ、第１ ＭＰＤに含まれもする。一例として、第１ ＭＰＤ及び第２ ＭＰＤが互換される場合には、第１ ＭＰＤに位置情報が含まれず、第１ ＭＰＤ及び第２ ＭＰＤが互換されない場合には、第１ ＭＰＤに位置情報が含まれもする。

伝送部１３２０は、第１伝送部（図示せず）及び第２伝送部（図示せず）を含んでもよい。

第１伝送部（図示せず）は、ＭＰＤを伝送する。

第２伝送部（図示せず）は、複数個のメディアデータのうち、ユーザが要請する少なくとも１つのメディアデータをライブストリーミング方式で伝送する。

要請受信部１３３０は、ユーザの要請を受信し、ユーザの要請によって、第１伝送部（図示せず）がＭＰＤを伝送するように制御したり、あるいは第２伝送部（図示せず）が、少なくとも１つのメディアデータを伝送するように制御する。

以下、時間の順序によって、伝送部１３２０及び要請受信部１３３０の動作について説明する。

まず、第１伝送部（図示せず）は、第１ ＭＰＤをデータ受信装置１５００に伝送する。

データ受信装置１５００は、第１ ＭＰＤに基づいて、複数個のメディアデータのうち、少なくとも一つを要請する。

要請受信部１３３０は、データ受信装置１５００から、メディアデータの伝送要請が受信されれば、ユーザが所望のメディアデータがライブストリーミング方式で伝送されるように、第２伝送部（図示せず）を制御する。

データ受信装置１５００は、第１ ＭＰＤに基づいて、第１ ＭＰＤの更新時点を確認した後、第１ ＭＰＤの更新を要請する。

要請受信部１３３０は、データ受信装置１５００から第１ ＭＰＤの更新要請が受信されれば、第１ ＭＰＤに連続する第２ ＭＰＤが伝送されるように、第１伝送部（図示せず）を制御する。

データ受信装置１５００は、第２ ＭＰＤに基づいて、所望のメディアデータを続けて要請する。

要請受信部１３３０は、ユーザが所望のメディアデータが続けて伝送されるように、第２伝送部（図示せず）を制御する。

図１４は、本発明の一実施形態による更新時点情報を含むＭＰＤの構造に係わる一例を示している。

「nextmanifest」フィールドは、次のＭＰＤに係わる情報を含む。

「avalabilityTime」フィールド１４１０は、ＭＰＤを更新する時点（すなわち、次のＭＰＤを受信する時点）を示す。

「avalabilityTime」フィールド１４１０を更新する基準時間（例えば、ＭＰＤに対応する最初のセグメントの再生時間）からのオフセット値で示すことができる。また、「avalabilityTime」フィールド１４１０は、ＭＰＤが更新される時点を分、秒のような絶対時間で示したり、あるいはクロックまたはセグメントの個数で示すこともできる。

図１９では「avalabilityTime」フィールドが、各区間が始まる時点を基準に、ＭＰＤが更新される時点を示す場合について説明し、図２１では、「avalabilityTime」フィールドが、メディアデータ内の最初の区間が始まる時点を基準に、ＭＰＤが更新される時点を示す場合について説明し、図２３では、「avalabilityTime」フィールドが各区間が始まった後、ＭＰＤが更新されるまでダウンロードされるセグメントの数を示す場合について説明する。

「ＵＲＬ」フィールド１４２０は、次のＭＰＤの位置を示す。

「Program」フィールドは、ＭＰＤに対応する区間で提供されるプログラムに係わる情報を含む。プログラムは、少なくとも１つのメディアデータを、提供されるサービスによって区分したり、あるいは時間によって区分したセクションである。メディアデータは、一つ以上のプログラムから構成される。実施形態によっては、プログラムを前記で定義したピリオド（period）と命名することができる。すなわち、プログラムは、時間単位で構成されるエレメントであり、時間によってストリームの内容及び種類を多様に表現することができるフィールドである。

「ＩＤ」フィールド１４３０は、プログラムの識別情報を示す。それぞれのプログラムには、１つのメディア・プレゼンテーション内で唯一のＩＤが割り当てられる。ＭＰＤは、プログラムＩＤを利用し、それぞれのプログラムを区分し、定義するのに使われもする。

「StartTime」フィールド１４４０は、当該プログラムの開始時間、またはＭＰＤに対応する区間の開始時間を示す。例えば、メディアデータ内の最初のプログラムに係わる「StartTime」フィールド１４４０は、「０」の値を有し、残りのプログラムに係わる「StartTime」フィールド１４４０は、最初のプログラムの開始時間から、残りのプログラムが始まる時間までのオフセット値を示すことができる。このように、「StartTime」フィールド１４４０は、所定時点を基準にした相対的な時間値（relative time）を有することができるが、絶対的な時間値（absolute time）を有することもできる。

「EndTime」フィールド１４５０は、当該プログラムの終了時間、またはＭＰＤに対応する区間の終了時間を示す。ライブストリーミング・サービスでは、「EndTime」フィールド１４５０が示す時間が経過した後には、プログラムにそれ以上アクセスできない。

プログラムは、少なくとも１つのストリームから構成され、ストリームは、少なくとも１つのセグメントから構成される。実施形態によっては、ストリームが、図９に図示された「ｔｒａｃｋ」で代替される。

図１５は、本発明の一実施形態によるデータ受信装置１５００に係わるブロック図を示している。

本発明の一実施形態によるデータ受信装置１５００は、受信部１５１０及び獲得部１５２０を含む。

受信部１５１０は、第１受信部１５１２及び第２受信部１５１４を含んでもよい。

第１受信部１５１２は、複数個のメディアデータに係わる情報を含む付加情報を受信する。複数個のメディアデータは、同じコンテンツを異なる品質にエンコーディングして生成されたものである。付加情報は、複数個のメディアデータに係わるアクセス情報と、付加情報の更新時点を示す更新時点情報とが含まれもする。以下、付加情報がＭＰＤであると仮定する。

第１受信部１５１２は、複数個のメディアデータに係わる情報を含むＭＰＤを受信する。

第２受信部１５１４は、ＭＰＤに基づいて、複数個のメディアデータのうち、少なくとも１つのメディアデータを受信する。

獲得部１５２０は、ＭＰＤから現在ＭＰＤが更新される時点を示す更新時点情報、及び次回ＭＰＤの位置情報のうち、少なくとも一つを獲得する。

以下、時間順序による受信部１５１０及び獲得部１５２０の動作について説明する。

第１受信部（図示せず）は、複数個のメディアデータの第１区間に係わる情報を含む第１ ＭＰＤを受信する。

ユーザが複数個のメディアデータのうち、所望のメディアデータを選択すれば、第２受信部１５１４は、第１ ＭＰＤに基づいて選択された少なくとも１つのメディアデータをデータ提供装置１３００に要請し、ライブストリーミング方式で、メディアデータを受信することができる。

獲得部１５２０は、第１ ＭＰＤから更新時点情報を獲得する。一実施形態で、獲得部１５２０は、次のＭＰＤの位置情報をさらに獲得することができる。

第１受信部１５１２は、更新時点情報に基づいて、第２ ＭＰＤをデータ提供装置１３００に要請し、第２ ＭＰＤを受信する。

データ受信装置１５００で受信された第２ ＭＰＤを利用してＭＰＤを更新する方法は多様である。

例えば、データ受信装置１５００は、第１ ＭＰＤに含まれた情報に、第２ ＭＰＤに含まれた情報を蓄積して１つのＭＰＤを生成し、内部データベースに保存することができるが、第１ ＭＰＤと第２ ＭＰＤとを別個の情報として保存することもある。場合によっては、第１ ＭＰＤを保存しないこともある。

他の例として、データ受信装置１５００は、第２ ＭＰＤから属性値を抽出し、抽出された値を利用し、第１ ＭＰＤの属性値を代替することができる。このような方式は、第１ ＭＰＤ及び第２ ＭＰＤが互換される場合に有用である。

第２受信部１５１４は、第２ ＭＰＤに基づいて、少なくとも１つのメディアデータを受信する。

コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータを受信するためには、それぞれのメディアデータに係わる情報が含まれたＭＰＤが必要である。ＭＰＤが複数個のメディアデータを構成するあらゆるセグメントに係わる情報を含むことになれば、データサイズが大きくなる。特に、ユーザがメディアデータの一部区間だけを所望する場合、ユーザが所望しない区間についての情報は、ダミーデータになるので、資源が無意味に浪費されて所望の情報を検索することも容易ではなくなる。このような問題点は、ライブストリーミングを提供するときに、さらに深刻になる。本発明では、ＭＰＤがメディアデータ内の一部区間についての情報のみを含み、次のＭＰＤに更新時点情報を挿入し、データ受信装置１５００が効率的に必要なＭＰＤを獲得できるようにした。

以下、図１６ないし図２７を利用し、多様な形態のＭＰＤと、ＭＰＤを利用してメディアデータを処理する過程とについて説明する。図１６ないし図２７で、メディアデータは、ライブストリーミング方式で提供され、複数個のプログラムから構成される。

図１６は、本発明の一実施形態によるメディアデータの構成に係わる一例を示している。

図１６を参考にすれば、メディアデータは、２つのプログラムから構成され、最初のプログラムは、「００：００：００」から「００：２０：００」までであり、２番目のプログラムは「００：２０：００」から「１：２０：００」までである。メディアデータは、第１区間１６０１と第２区間１６０２とに区分される。第１区間１６０１と第２区間１６０２は、物理的に区分されるものではなく、ＭＰＤがカバーする範囲によって、仮想的に区分された区間である。第１区間１６０１についての情報は、図１７Ａに図示された第１ ＭＰＤ１７０１に含まれ、第２区間１６０２についての情報は、図１７Ｂに図示された第２ ＭＰＤ１７０２に含まれる。図１６でＭＰＤは、プログラム単位で生成される。また、各区間の終端と、次の区間の開始とが一定部分オーバーラッピングされている。従って、オーバーラッピングされた部分に属するセグメントに係わる情報は、以前ＭＰＤと次のＭＰＤとにいずれも含まれる。

図１７及び図１７Ｂは、図１６に図示されたメディアデータに係わる情報を含むＭＰＤに係わる一例を示している。

図１７Ａは、第１区間１６０１に係わる情報を含む第１ ＭＰＤ１７０１に係わる一例を示している。

「Program ｉｄ」フィールドは、第１ ＭＰＤ１７０１が、ＩＤが「００１」であるプログラムに係わる情報を含むことを示す。

「StartTime」フィールド及び「EndTime」フィールドは、ＩＤが「００１」であるプログラムは、「００：００：００」時点に始まり、「００：２０：００」に終了するということを示す。

「nextManifest availabilityTime」フィールドは、ＭＰＤが更新される時点（すなわち、第２ ＭＰＤ１７０２を受信する時点）が「００：１５：００」であることを示す。「nextManifest availabilityTime」フィールドの値が「００：１５：００」であるから、第１区間１６０１内のデータがいずれも処理される前に、第２ ＭＰＤ１７０２が受信される。

「ＵＲＬ」フィールドは、第２ ＭＰＤ１７０２の位置情報を示す。「ＵＲＬ」フィールドが空いているので、第１ ＭＰＤ１７０１と第２ ＭＰＤ１７０２は、同じ属性構造を有し、同じＵＲＬを介して獲得できることを示す。

図１７Ｂは、第２区間１６０２に係わる情報を含む第２ ＭＰＤ１７０２に係わる一例を示している。

「Program ｉｄ」フィールドは、第１ ＭＰＤ１７０２には、ＩＤが「００２」であるプログラムに係わる情報を含むことを示す。

「StartTime」フィールド及び「EndTime」フィールドは、ＩＤが「００２」であるプログラムは、「００：２０：００」時点に始まり、「０１：２０：００」に終了するということを示す。

「nextManifest availabilityTime」フィールドは、ＭＰＤが更新される時点を示す。図１７Ｂでは、「nextManifest availabilityTime」フィールドが存在しないために、次のＭＰＤが存在しない。

図１７Ａ及び図１７Ｂに図示されたＭＰＤ１７０１，１７０２を利用し、データ受信装置１５００にメディアデータを提供する過程は、次の通りである。

ｉ）データ受信装置１５００は、データ提供装置１３００に、第１ ＭＰＤ１７０１を要請する。

ｉｉ）データ提供装置１３００は、第１ ＭＰＤ１７０１を、データ受信装置１５００に伝送する。

ｉｉｉ）データ受信装置１５００が第１ ＭＰＤ１７０１に基づいて、最初のプログラムを構成するセグメントを要請する。

ｉｖ）データ提供装置１３００は、最初のプログラムを構成するセグメントを、データ受信装置１５００に伝送する。

ｖ）データ受信装置１５００は、最初のプログラムが再生された後、「００：１５：００」が経過した後に、データ提供装置１３００に第２ ＭＰＤ１７０２を要請する。

ｖｉ）データ提供装置１３００は、第２ ＭＰＤ１７０２をデータ受信装置１５００に伝送する。

ｖｉｉ）データ受信装置１５００は、最初のプログラムがいずれも再生されれば（すなわち、「００：２０：００」が経過すれば）、第２ ＭＰＤ１７０２に基づいて、２番目のプログラムを構成するセグメントを要請する。

ｖｉｉｉ）データ提供装置１３００は、２番目のプログラムを構成するセグメントを、データ受信装置１５００に伝送する。

図１８は、本発明の一実施形態によるメディアデータの構成に係わる他の例を示している。

図１８を参考にすれば、メディアデータは、複数個のプログラムから構成され、最初のプログラムは、「００：００：００」から「００：２０：００」までであり、２番目のプログラムは、「００：２０：００」から「１：２０：００」までである。メディアデータは、第１区間１８０１と第２区間１８０２とに区分される。第１区間１８０１と第２区間１８０２は、物理的に区分されるものではなく、ＭＰＤがカバーする範囲によって、仮想的に区分された区間である。第１区間１８０１についての情報は、図１９Ａに図示された第１ ＭＰＤ １９０１に含まれ、第２区間１８０２についての情報は、図１９Ｂに図示された第２ ＭＰＤ １９０２に含まれる。図１８でＭＰＤは、プログラム単位で生成され、データ受信装置１５００は、１つのプログラムが完了した後、次のプログラムについての情報を含む次のＭＰＤを受信する。

図１８では、第１区間１８０１の終端と第２区間１８０２の終端とがオーバーラッピングされていない。従って、第１ ＭＰＤ １９０１及び第２ ＭＰＤ １９０２には、重複するセグメントに係わる情報が含まれない。

図１９Ａ及び図１９Ｂは、図１８に図示されたメディアデータに係わる情報を含むＭＰＤに係わる一例を示している。図１９Ａ及び図１９Ｂでは、「avalabilityTime」フィールドが、各区間が始まる時点を基準に、ＭＰＤが更新される時間を示す。

図１９Ａは、第１区間１８０１に係わる情報を含む第１ ＭＰＤ １９０１に係わる一例を示している。

「nextManifest availabilityTime」フィールドは、ＭＰＤが更新される時点（すなわち、第２ ＭＰＤ１７０２を受信する時点）が、「００：２０：００」であることを示す。

「ＵＲＬ」フィールドは、第２ ＭＰＤ １９０２の位置情報を示している。第２ ＭＰＤ １９０２は、「ManifestＢ．ｘｍｌ」に該当するＵＲＬにアクセスして獲得する。

図１９Ｂは、第２区間１８０２に係わる情報を含む第２ ＭＰＤ １９０２に係わる一例を示している。

図１９Ｂで、「nextManifest availabilityTime」フィールドは、第２区間１８０２が始まった時点を基準に、第２ ＭＰＤ １９０２が更新される時点を示す。従って、第２ ＭＰＤ １９０２は、第２区間１８０２が始まった後から、「０１：００：００」が経過した時点に更新される。

実施形態によっては、「nextManifest availabilityTime」フィールド値が、最初のプログラムが始まった時点を基準に、第２ ＭＰＤ １９０２が更新される時点を示すこともある。この場合、「nextManifest availabilityTime」フィールド値は、「０１：２０：００」になるのである。

図１９Ａ及び図１９Ｂに図示されたＭＰＤ１９０１，１９０２を利用し、データ受信装置１５００にメディアデータを提供する過程は、ｖ）過程を除外すれば、図１７と同一であるので、ｉ）〜ｉｖ）及びｖｉ）〜ｖｉｉ）過程は、説明を省略する。

データ受信装置１５００は、最初のプログラムが完了すれば（すなわち、「００：２０：００」）、データ提供装置１３００に第２ ＭＰＤ １９０２を要請する。

図２０は、本発明の一実施形態によるメディアデータの構成に係わるさらに他の例を示している。

図２０を参考にすれば、メディアデータは、２つのプログラムから構成され、最初のプログラムは、「００：００：００」から「００：２０：００」までであり、２番目のプログラムは、「００：２０：００」から「１：２０：００」までである。

メディアデータは、第１区間２００１、第２区間２００２及び第３区間２００３に区分される。第１区間２００１についての情報は、第１ ＭＰＤ ２１０１に含まれ、第２区間２００２についての情報は、第２ ＭＰＤ ２１０２に含まれる。
図２０では、メディアデータは、プログラムとは関係がなく、時間によって複数個の区間に分けられ、区間別にＭＰＤが生成される。このとき、それぞれの区間の長さは、同一でもあり、あるいは異なってもいる。各区間の終端と次の区間の開始とが、一定部分オーバーラッピングされている。従って、オーバーラッピングされた部分に属するセグメントに係わる情報は、以前ＭＰＤと次のＭＰＤとにいずれも含まれる。

図２１Ａないし図２１Ｃは、図２０に図示されたメディアデータに係わる情報を含むＭＰＤに係わる一例を示している。図２１Ａないし図２１Ｃでは、「avalabilityTime」フィールドが、メディアデータ内の最初の区間が始まる時点を基準に、ＭＰＤが更新される時間を示している。

図２１Ａは、第１区間２００１に係わる情報を含む第１ ＭＰＤ ２１０１に係わる一例を示している。

図２１Ａないし図２１Ｃで、「nextManifest availabilityTime」フィールドが、「００：１５：００」の値を有するので、第１ ＭＰＤ ２１０１は、第１区間２００１が始まった後から、「００：１５：００」が経過した時点に更新される。

図２１Ｂは、第２区間２００２に係わる情報を含む第２ ＭＰＤ ２１０２に係わる一例を示している。「nextManifest availabilityTime」フィールドが、「００：３０：００」であるから、第２ ＭＰＤ ２１０２は、第１区間２００１が始まってから、「００：３０：００」が経過した時点に更新される。

図２１Ｃは、第３区間２００３に係わる情報を含む第３ ＭＰＤ ２１０３に係わる一例を示している。

図２１Ａないし図２１Ｃに図示されたＭＰＤ ２１０１，２１０２，２１０３を利用し、データ受信装置１５００にメディアデータを提供する過程は、ＭＰＤの更新回数を除外すれば、図１７と同一であるので、以下、説明を省略する。

図２２は、本発明の一実施形態によるメディアデータの構成に係わるさらに他の例を示している。

図２２を参考にすれば、メディアデータは、複数個のプログラムから構成され、最初のプログラムは、「００：００：００」から「００：２０：００」までであり、２番目のプログラムは、「００：２０：００」から「１：２０：００」までである。メディアデータは、所定の時間間隔を有する複数個の区間に区分される。それぞれの区間ごとに対応するＭＰＤが生成される。

図２２では、メディアデータは、プログラムとは関係なしに、時間によって複数個の区間に分けられ、区間別にＭＰＤが生成される。区間の間のオーバーラッピングが存在しないために、以前ＭＰＤに含まれたセグメントに係わる情報と、次のＭＰＤに含まれたセグメントに係わる情報とは重複しない。

ＭＰＤとプログラムは、整列されねばならない。例えば、２番目のプログラムの開始と、第４ ＭＰＤ ２３０４が受信される時点とが一致せねばならない。これは、最初のプログラムと２番目のプログラムとのエンコーディングが異なる場合に適切に対処するためである。

図２３Ａ及び図２３Ｂは、図２２に図示されたメディアデータに係わる情報を含むＭＰＤに係わる一例を示している。図２３Ａ及び図２３Ｂでは、「avalabilityTime」フィールドが、各区間が始まった後、ＭＰＤが更新されるまでダウンロードされるセグメントの数を示している。

図２３Ａ及び図２３Ｂは、対応する区間内のセグメントに係わる情報を含むＭＰＤに係わる一例を示している。

最初のプログラムは、第１ ＭＰＤ ２３０１ないし第３ ＭＰＤ ２３０３によって処理され、次のＭＰＤまでの間隔は、セグメントカウントを利用して計算される。

２番目のプログラムは、第４ ＭＰＤ ２３０４ないし第６ ＭＰＤ ２３０６によって処理され、次のＭＰＤまでの間隔は、セグメントカウントを利用して計算される。

図２３Ａ及び図２３Ｂで、「nextManifest availabilityTime」フィールドは、対応する区間が始まった時点を基準に、ＭＰＤが更新される時点を示す。「nextManifest availabilityTime」フィールドが「１０」であるならば、それぞれの区間が始まった時点から「１０」に該当するセグメント個数ほどセグメントがダウンロードされれば、次の区間のセグメントを処理するために、次のＭＰＤを受信する。

図２３Ａ及び図２３Ｂに図示されたＭＰＤ ２３０１〜２３０６を利用し、データ受信装置１５００にメディアデータを提供する過程は、ＭＰＤの更新回数を除外すれば、図１７と同一であるので、以下、説明を省略する。

図２４は、本発明の一実施形態によるデータ提供装置１３００で、ＭＰＤを変更する過程に係わるフローチャートを示している。

データ提供装置１３００では、セグメントが準備されれば、準備されたセグメントに係わる情報を含むＭＰＤを生成する。従って、データ提供装置１３００から提供されるプログラムの内容が変更されれば、ＭＰＤが変更される。一例として、プログラム間に広告を挿入すれば、ＭＰＤがカバーするセグメントの種類、順序及びシンクが変わるために、ＭＰＤも変更されねばならない。図２４では、プログラム間に広告を挿入することによって生成されたＭＰＤを変更する過程について説明する。メディアデータは、第１区間と第２区とから構成され、第１区間についての情報は、第１ ＭＰＤに含まれ、第２区間についての情報は、第２ ＭＰＤに含まれる。また、第１ ＭＰＤは、第２ ＭＰＤの位置情報を含むと仮定する。

段階Ｓ２４１０では、外部セグメントを所望の区間に挿入する。一例として、外部セグメントを第１区間内に挿入する。

段階Ｓ２４２０では、第１ ＭＰＤ内で、第１区間で除外されたセグメントに係わる情報を削除する。第１区間の長さが固定された状態で、第１区間に新たらに外部セグメントが挿入されれば、挿入された外部セグメントの個数ほど、既存セグメントが第１区間で除外される。従って、第１ ＭＰＤでは、除外されたセグメントに係わる情報が削除される。

段階Ｓ２４３０では、外部セグメントに係わる情報を第１ ＭＰＤに追加し、次のＭＰＤの位置情報を変更する。すなわち、第１ ＭＰＤ内の次のＭＰＤの「ＵＲＬ」を第２ ＭＰＤのＵＲＬで第３ ＭＰＤのＵＲＬに変更する。

段階Ｓ２４４０では、第１区間で除外されたセグメントに係わる情報を含む第３ ＭＰＤを生成する。

図２５は、本発明の一実施形態によるデータ提供装置１３００で、追加セグメント２５０３が挿入される前のＭＰＤに係わる一例を示している。

メディアデータは、第１区間２５０１と第２区間２５０２とに区分される。

第１ ＭＰＤ ２５１０は、第１区間２５０１内のセグメントに係わる情報を含み、第２ ＭＰＤ ２５２０を受信する時点を示す更新時点情報、及び第２ ＭＰＤ ２５２０に対する位置情報を含む。

また、第２ ＭＰＤ ２５２０は、第２区間２５０２内のセグメントに係わる情報を含み、次のＭＰＤに係わる位置情報を含む。

このように、第１ ＭＰＤ ２５１０と第２ ＭＰＤ ２５２０とが生成された状態で、広告の挿入などによって、追加セグメント２５０３が第１区間２５０１内に挿入され、これによるＭＰＤの変化は、図２６で続けて説明する。

図２６は、本発明の一実施形態によるデータ提供装置１３００で、追加セグメント２５０３が挿入された後のＭＰＤに係わる一例を示している。

第１区間２５０１に、追加セグメント２５０３が挿入されれば、第１区間２５０１に属した既存のセグメントの一部が、第１区間２５０１から除外される。

データ提供装置１３００は、第１ ＭＰＤ ２５１０に、追加セグメント２５０３に係わる情報を挿入し、除外されたセグメント２６０３に係わる情報を削除し、変更された第１ ＭＰＤ ２６１０を生成する。

次に、データ提供装置１３００は、除外されたセグメント２６０３についての情報を含む第３ ＭＰＤ ２６３０を生成する。

変更された第１ ＭＰＤ ２６１０は、第３ ＭＰＤ ２６３０に係わる位置情報を含み、第３ ＭＰＤ ２６３０は、第２ ＭＰＤ ２６２０に係わる位置情報を含む。

図２７は、本発明の一実施形態によるデータ提供装置１３００で、追加セグメント２５０３が挿入された後のＭＰＤに係わる他の例を示している。図２７では、図２６と異なり、第２ ＭＰＤ ２５２０の名称を修正しない。

第１区間２５０１に追加セグメント２５０３が挿入されることにより、第１区間２５０１に属した既存のセグメントの一部が、第１区間２５０１から除外される。

データ提供装置１３００は、第１ ＭＰＤ ２５１０に、追加セグメント２５０３に係わる情報を挿入し、除外されたセグメント２６０３に係わる情報を削除し、変更された第１ ＭＰＤ ２６１０を生成する。

次に、データ提供装置１３００は、除外されたセグメント２７０３に係わる情報を含む第３ ＭＰＤ ２６３０を生成する。このとき、第１ ＭＰＤ ２６１０に含まれた次のＭＰＤの位置情報を変更しないようにするために、第３ ＭＰＤ ２６３０の名称を「manifestＢ．ｘｍｌ」と決定する。

最後に、第２ ＭＰＤ ２５２０の名称を「manifestＢ＿１．ｘｍｌ」に変更する。

図２８は、本発明の一実施形態によるデータ提供装置１３００で、追加セグメント２５０３の挿入によるＭＰＤの変化を示している。

第１区間２８０１に対応する第１ ＭＰＤ ２８１０と、第２区間２８０２に対応する第２ ＭＰＤ ２８２０とが生成された後、第１区間２８０１内に、追加セグメントが挿入された。

第１ ＭＰＤ ２８１０に追加セグメントについての情報が挿入され、除外されたセグメントについての情報を削除する。同時に、除外されたセグメントについての情報を含む第３ ＭＰＤ ２８３０を生成し、名称を「manifestＢ」に決定する。このとき、次のＭＰＤの名称を「manifestＢ＿１．ｘｍｌ」と指定する。

第２ ＭＰＤ ２８２０は、「manifestＢ．ｘｍｌ」から「manifestＢ＿１．ｘｍｌ」に変更する。

図２９Ａないし図２９Ｃは、本発明の一実施形態によるＭＰＤとプログラムとの関係に係わる一例を示している。

図２９Ａは、１つのＭＰＤ２９１０が、複数個のプログラム２０１１，２９１２，２９１３に係わる情報を含む場合を示している。ＭＰＤがカバーする区間には、第１プログラム２０１１、第２プログラム２９１２及び第３プログラム２９１３の一部または全部が含まれる。一例として、ライブストリーミングの場合に、リアルタイムでプログラム単位のメディアデータを生成し、プログラム単位でＭＰＤを生成することができる。このとき、ＭＰＤが、過去と現在とのプログラムに該当するメディアデータに係わる情報をいずれも含むようにすることによって、メディアデータの処理能力を向上させることができる。

図２９Ｂは、ＭＰＤ ２９２０が所定のプログラム２９２２に係わる位置情報を含む場合を示している。ＭＰＤ ２９２０は、ＵＲＬフィールドを含み、ＵＲＬフィールドを利用し、次のＭＰＤの位置を示すことができることは、説明した通りである。しかし、図２９Ｂでのように、ＭＰＤ ２９２０に含まれたＵＲＬフィールドを利用し、次のＭＰＤの位置ではない所定のプログラム２９２２の位置を示すこともできる。ＵＲＬフィールドが指示する所定のプログラム２９２２は、次のＭＰＤがカバーする最初のプログラム、現在ＭＰＤ ２９２０がカバーする最後のプログラム、または所定の定義された条件を満足するプログラムであってもよい。

図２９Ｃは、１つのＭＰＤが１つのプログラムに係わる情報と、次のＭＰＤに係わる情報とを含む場合を示している。

第１ ＭＰＤ ２９３０は、第１プログラム２９３１についての情報と、次のＭＰＤである第２ ＭＰＤ ２９４０に係わる位置情報とを含む。

第２ ＭＰＤ ２９４０は、第２プログラム２９４１に係わる情報と、次のＭＰＤである第３ ＭＰＤ ２９５０に係わる位置情報を含む。

同様に、第３ ＭＰＤ ２９５０は、第３プログラム２９５１に係わる情報を含む。

図３０は、本発明の一実施形態によるデータ提供装置１３００及びデータ受信装置１５００間のデータフローを示すフローチャートである。

段階Ｓ３０１０で、データ提供装置１３００は、複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を伝送する。複数個のメディアデータは、コンテンツを異なる品質にエンコーディングして生成される。

段階Ｓ３０２０で、データ受信装置１５００は、第１付加情報に基づいて、少なくとも１つのメディアデータの伝送を要請する。メディアデータは、他のメディアデータとスイッチングされて処理及び再生が可能である少なくとも１つのセグメントから構成される。第１付加情報には、第１区間に属するセグメントに係わるアクセス情報が含まれているので、データ受信装置１５００は、第１付加情報に基づいて、所望のメディアデータの伝送を要請することができる。

段階Ｓ３０３０で、データ提供装置１３００は、少なくとも１つのメディアデータを伝送する。

段階Ｓ３０４０で、データ受信装置１５００は、第１付加情報から、第１付加情報の更新時点を示す更新時点情報を獲得する。

段階Ｓ３０５０で、データ受信装置１５００は、更新時点情報に基づいて、複数個のメディアデータの第２区間に係わる情報を含む第２付加情報を要請する。

段階Ｓ３０６０で、データ提供装置１３００は、第２付加情報を伝送する。

段階Ｓ３０７０で、データ受信装置１５００は、第２付加情報を利用して付加情報を更新し、少なくとも１つのメディアデータの伝送を要請する。

データ受信装置１５００が付加情報を更新する方法は、実施形態によって多様である。

一例として、データ提供装置１３００が、属性構造は同一であり、属性値だけを異にするように、第１付加情報と第２付加情報とを生成することができる。その場合、第１付加情報と第２付加情報は、相互間に互換するので（例えば、セグメントの個数、セグメントのリスト、付加情報の位置情報などが同一）、第２付加情報と第１付加情報とを同期化させる必要なしに、第２付加情報を直ちに使用することができる。

他の例として、データ提供装置１３００が、異なる属性構造を有する第１付加情報と第２付加情報とを生成することができる。その場合、第１付加情報には、第２付加情報に係わる位置情報が含まれなければならない。

段階Ｓ３０８０で、データ提供装置１３００は、少なくとも１つのメディアデータを伝送する。

一方、前述の本発明の実施形態は、コンピュータで実行することができるプログラムで作成可能であり、コンピュータで読み取り可能な記録媒体を利用し、前記プログラムを動作させる汎用デジタル・コンピュータで具現される。

前記コンピュータで読み取り可能な記録媒体は、マグネチック保存媒体（例えば、ＲＯＭ（read-only memory）、フロッピー（登録商標）ディスク、ハードディスクなど）、光学的判読媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤなど）及びキャリアウェーブ（例えば、インターネットを介した伝送）のような記録媒体を含む。

以上、本発明についてその望ましい実施形態を中心に説明した。本発明が属する技術分野で当業者であるならば、本発明が本発明の本質的な特性から外れない範囲で変形された形態で具現されるということを理解することができるであろう。従って、開示された実施形態は、限定的な観点ではなく、説明的な観点から考慮されねばならない。本発明の範囲は、前述の説明ではなく、特許請求の範囲に示されており、それと同等な範囲内にあるあらゆる差異点は、本発明に含まれたものであると解釈されねばならない。

１００ ストリーミング・システム
１１０ エンコーディング装置
１２０ サーバ
１３０ クライアント
１４０ ネットワーク
１０１０，１０３０ メディアデータ
１０４０，１０４２，１０４４ 情報
１０５０ ファイル
１３００ データ提供装置
１３２０ 伝送部
１３３０ 要請受信部
１４１０，１４２０，１４３０，１４４０，１４５０ フィールド
１５００ データ受信装置
１５１０，１５１２，１５１４ 受信部
１５２０ 獲得部

Claims (15)

1. コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を受信する段階と、
   前記第１付加情報を利用し、前記第１ファイルが更新される時点を示す更新時点情報を獲得する段階と、
   前記更新時点情報に基づいて、前記複数個のメディアデータの第２区間に係わる情報を含む第２付加情報を受信する段階と、を含むことを特徴とするデータ受信方法。
2. 前記方法は、
   前記第１付加情報に基づいて、前記複数個のメディアデータのうち、少なくとも１つのメディアデータの第１区間に該当するデータを、ストリーミング方式で受信する段階と、
   前記第２付加情報に基づいて、前記少なくとも１つのメディアデータの第２区間に該当するデータを、ストリーミング方式で受信する段階と、をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
3. 前記第２付加情報は、
   前記第１付加情報と同じ属性構造を有することを特徴とする請求項１に記載のデータ受信方法。
4. 前記第１付加情報は、
   前記第２付加情報に係わる位置情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
5. 第２付加情報は、
   前記第１付加情報と異なる属性構造を有することを特徴とする請求項４に記載のデータ受信方法。
6. 前記第１区間及び前記第２区間は、
   前記第１区間及び前記第２区間で提供されるプログラムによって区分されることを特徴とする請求項１に記載のデータ受信方法。
7. 前記第１区間及び前記第２区間は、
   前記複数個のメディアデータを所定の時間単位に分割して生成されたことを特徴とする請求項１に記載のデータ受信方法。
8. 前記第１付加情報は、
   前記第１区間が始まる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
9. 前記第１付加情報は、
   前記第１区間が終わる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
10. 前記第１付加情報は、
    前記第１区間で提供されるプログラムの識別情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
11. コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報が含まれた第１前記第１付加情報と、前記複数個のメディアデータの第２区間に係わる情報が含まれた第２付加情報と、を生成する段階と、
    前記第１付加情報をクライアントに伝送する段階と、
    前記クライアントから、前記第１付加情報に係わる更新要請が受信されれば、前記第２付加情報を前記クライアントに伝送する段階と、を含み、
    前記第１付加情報は、前記第１付加情報の更新時点を示す更新時点情報を含むことを特徴とするデータ提供方法。
12. 前記複数個のメディアデータのうち、前記クライアントが要請する少なくとも１つのメディアデータの第１区間に該当するデータをストリーミング方式で伝送する段階と、
    前記複数個のメディアデータのうち、前記クライアントが要請する少なくとも１つのメディアデータの第２区間に該当するデータをストリーミング方式で伝送する段階と、をさらに含むことを特徴とする請求項１１に記載のデータ提供方法。
13. コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を受信する受信部と、
    前記第１付加情報を利用し、前記第１ファイルが更新される時点を示す更新時点情報を獲得する獲得部と、を含み、
    前記受信部は、前記更新時点情報に基づいて、前記複数個のメディアデータの第２区間に係わる情報を含む第２付加情報をさらに受信することを特徴とするデータ受信装置。
14. コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報が含まれた第１付加情報と、前記複数個のメディアデータの第２区間に係わる情報が含まれた第２付加情報と、を生成する生成部と、
    前記第１付加情報をクライアントに伝送する伝送部と、
    前記クライアントから、前記第１付加情報に係わる更新要請を受信する要請受信部と、を含み、
    前記伝送部は、前記更新要請が受信されれば、前記２付加情報を前記クライアントにさらに伝送し、
    前記第１付加情報は、前記第１付加情報の更新時点を示す更新時点情報を含むことを特徴とするデータ提供装置。
15. データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、
    前記方法は、コンテンツを異なる品質にエンコーディングして生成された複数個のメディアデータの第１区間に係わる情報を含む第１付加情報を受信する段階と、
    前記第１付加情報を利用し、前記第１ファイルが更新される時点を示す更新時点情報を獲得する段階と、
    前記更新時点情報に基づいて、前記複数個のメディアデータの第２区間に係わる情報を含む第２付加情報を受信する段階と、を含むことを特徴とする記録媒体。

Images