(57)【特許請求の範囲】
【請求項１】
コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する段階と、
前記更新時点情報に基づいて、前記コンテンツの第２区間についての第２付加情報を受信する段階と、を含み、
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新されることを特徴とするデータ受信方法。
【請求項２】
前記方法は、
前記第１付加情報に基づいて、前記複数個の第１メディアデータのうち、前記少なくとも１つの第１メディアデータを、ストリーミング方式で受信する段階と、
前記第２付加情報に基づいて、前記コンテンツの前記第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータのうち少なくとも１つの第２メディアデータを、ストリーミング方式で受信する段階と、をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項３】
前記第２付加情報は、
前記第１付加情報と同じ属性構造を有することを特徴とする請求項１に記載のデータ受信方法。
【請求項４】
前記第１付加情報は、
前記第２付加情報に係わる位置情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項５】
前記第２付加情報は、
前記第１付加情報と異なる属性構造を有することを特徴とする請求項４に記載のデータ受信方法。
【請求項６】
前記第１区間及び前記第２区間は、
前記第１区間及び前記第２区間で提供されるプログラムによって区分されることを特徴とする請求項１に記載のデータ受信方法。
【請求項７】
前記第１区間及び前記第２区間は、
前記コンテンツを所定の時間単位に分割して生成されたことを特徴とする請求項１に記載のデータ受信方法。
【請求項８】
前記第１付加情報は、
前記第１区間が始まる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項９】
前記第１付加情報は、
前記第１区間が終わる時点を示す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項１０】
前記第１付加情報は、
前記第１区間で提供されるプログラムの識別情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項１１】
コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報が含まれた第１付加情報と、前記コンテンツの第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータに係わる情報が含まれた第２付加情報と、を生成する段階と、
前記第１付加情報をクライアントに伝送する段階と、
前記第１付加情報に含まれた該第１付加情報が更新可能な時点を示す更新時点情報に基づいて、前記第２付加情報を前記クライアントに伝送する段階と、を含み、
前記第１付加情報は、該第１付加情報に基づいて伝送される少なくとも１つの第１メディアデータが前記クライアントで処理される間に更新されることを特徴とするデータ提供方法。
【請求項１２】
前記複数個の第１メディアデータのうち、前記クライアントが要請する前記少なくとも１つの第１メディアデータをストリーミング方式で伝送する段階と、
前記複数個の第２メディアデータのうち、前記クライアントが要請する少なくとも１つの第２メディアデータをストリーミング方式で伝送する段階と、をさらに含むことを特徴とする請求項１１に記載のデータ提供方法。
【請求項１３】
コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する受信部と、
前記第１付加情報を利用し、前記第１付加情報が更新可能な時点を示す更新時点情報を獲得する獲得部と、を含み、
前記受信部は、前記更新時点情報に基づいて、前記更新可能な時点によって前記コンテンツの第２区間に係わる情報を含む第２付加情報をさらに受信し、
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新されることを特徴とするデータ受信装置。
【請求項１４】
コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報が含まれた第１付加情報と、前記コンテンツの第２区間を異なる品質にエンコーディングして生成された複数個の第２メディアデータに係わる情報が含まれた第２付加情報と、を生成する生成部と、
前記第１付加情報をクライアントに伝送する伝送部と、
前記クライアントから、前記第１付加情報に係わる更新要請を受信する要請受信部と、を含み、
前記伝送部は、前記更新要請が受信されれば、前記第１付加情報に含まれた前記第１付加情報が更新可能な時点を示す更新時点情報に基づいて、前記第２付加情報を前記クライアントにさらに伝送し、
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新されることを特徴とするデータ提供装置。
【請求項１５】
データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、
前記方法は、コンテンツの第１区間を異なる品質にエンコーディングして生成された複数個の第１メディアデータに係わる情報を含む第１付加情報を受信する段階と、
前記第１付加情報を利用し、前記第１付加情報が更新される時点を示す更新時点情報を獲得する段階と、
前記更新時点情報に基づいて、前記コンテンツの第２区間に関する第２付加情報を受信する段階と、を含み、
前記第１付加情報は、該第１付加情報に基づいて受信される少なくとも１つの第１メディアデータが処理される間に更新されることを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データを提供する方法及びその装置、並びにデータを受信する方法及びその装置に係り、特に、ライブストリーミングを提供するのに必要な付加情報を提供する方法及びその装置、並びにそれを利用してライブストリーミングを提供される方法及びその装置に関する。
【背景技術】
【０００２】
ネットワークを介してメディアデータを伝送する方式には、ダウンロード方式とストリーミング方式とがある。ストリーミング方式は、サーバがリアルタイムでメディアデータを伝送し、クライアントは、受信されたメディアデータをリアルタイムで再生し、次に受信されるデータに係わる付加情報をあらかじめ獲得する方式である。
【０００３】
ダウンロード方式では、あらゆるデータに係わる付加情報をあらかじめ受信し、それを利用してデータを受信することができるが、ストリーミング方式の場合には、帯域幅の効率的な使用が重要であるので、かような方式を使用し難い。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】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」属性及び「BitR
ate」属性を含む。
【００５３】
「ＩＤ」属性は、メディアデータに対して順に付与される識別子を定義し、「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 presentationdescription）とする）のＵＲＬだけ定義することが異なる。「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）、フロッピーディスク（登録商標）、ハードディスクなど）、光学的判読媒体（例えば、ＣＤ−ＲＯＭ、ＤＶＤなど）及びキャリアウェーブ（例えば、インターネットを介した伝送）のような記録媒体を含む。
【０２９６】
以上、本発明についてその望ましい実施形態を中心に説明した。本発明が属する技術分野で当業者であるならば、本発明が本発明の本質的な特性から外れない範囲で変形された形態で具現されるということを理解することができるであろう。従って、開示された実施形態は、限定的な観点ではなく、説明的な観点から考慮されねばならない。本発明の範囲は、前述の説明ではなく、特許請求の範囲に示されており、それと同等な範囲内にあるあらゆる差異点は、本発明に含まれたものであると解釈されねばならない。
【符号の説明】
【０２９７】
１００  ストリーミング・システム
１１０  エンコーディング装置
１２０  サーバ
１３０  クライアント
１４０  ネットワーク
１０１０、１０３０  メディアデータ
１０４０、１０４２、１０４４  情報
１０５０  ファイル
１３００  データ提供装置
１３２０  伝送部
１３３０  要請受信部
１４１０、１４２０、１４３０、１４４０、１４５０  フィールド
１５００  データ受信装置
１５１０、１５１２、１５１４  受信部
１５２０  獲得部
【図３】
0005988378.tif 000002
【図４ａ】
0005988378.tif 000003
【図４ｂ】
0005988378.tif 000004
【図４ｃ】
0005988378.tif 000005
【図６】
0005988378.tif 000006
【図７】
0005988378.tif 000007
【図８ａ】
0005988378.tif 000008
【図８ｂ】
0005988378.tif 000009
【図９ａ】
0005988378.tif 000010
【図９ｂ】
0005988378.tif 000011
【図９ｃ】
0005988378.tif 000012
【図９ｄ】
0005988378.tif 000013
【図９ｅ】
0005988378.tif 000014
【図９ｆ】
0005988378.tif 000015
【図９ｇ】
0005988378.tif 000016
【図９ｈ】
0005988378.tif 000017
【図１４】
0005988378.tif 000018
【図１７ａ】
0005988378.tif 000019
【図１７ｂ】
0005988378.tif 000020
【図１９ａ】
0005988378.tif 000021
【図１９ｂ】
0005988378.tif 000022
【図２１ａ】
0005988378.tif 000023
【図２１ｂ】
0005988378.tif 000024
【図２１ｃ】
0005988378.tif 000025
【図２３ａ】
0005988378.tif 000026
【図２３ｂ】
0005988378.tif 000027
【図１】
0005988378.tif 000028
【図２Ａ】
0005988378.tif 000029
【図２Ｂ】
0005988378.tif 000030
【図５Ａ】
0005988378.tif 000031
【図５Ｂ】
0005988378.tif 000032
【図１０Ａ】
0005988378.tif 000033
【図１０Ｂ】
0005988378.tif 000034
【図１０Ｃ】
0005988378.tif 000035
【図１１Ａ】
0005988378.tif 000036
【図１１Ｂ】
0005988378.tif 000037
【図１２Ａ】
0005988378.tif 000038
【図１２Ｂ】
0005988378.tif 000039
【図１２Ｃ】
0005988378.tif 000040
【図１３】
0005988378.tif 000041
【図１５】
0005988378.tif 000042
【図１６】
0005988378.tif 000043
【図１８】
0005988378.tif 000044
【図２０】
0005988378.tif 000045
【図２２】
0005988378.tif 000046
【図２４】
0005988378.tif 000047
【図２５】
0005988378.tif 000048
【図２６】
0005988378.tif 000049
【図２７】
0005988378.tif 000050
【図２８】
0005988378.tif 000051
【図２９Ａ】
0005988378.tif 000052
【図２９Ｂ】
0005988378.tif 000053
【図２９Ｃ】
0005988378.tif 000054
【図３０】
0005988378.tif 000055