"コンテンツを異なる品質にエンコーディングすることで生成されるそれぞれ少なくとも1つのセグメントを含む複数個のメディアデータのうち少なくとも一つを受信するステップと、前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を獲得するステップと、前記位置情報を利用し、前記受信されたメディアデータに係わるランダムアクセスを提供するステップと、を有することを特徴とするデータ受信方法。前記獲得するステップは、前記少なくとも1つのセグメントそれぞれに含まれた少なくとも1つのパケットから、前記少なくとも1つのセグメントそれぞれに対応する位置情報を獲得するステップを有することを特徴とする請求項1に記載のデータ受信方法。前記位置情報は、前記位置情報に対応するセグメント内に含まれるランダムアクセスが可能な次のパケットの位置を示す第1オフセット情報を含むことを特徴とする請求項2に記載のデータ受信方法。前記位置情報は、前記位置情報に対応するセグメント内に含まれるランダムアクセスが可能なあらゆるパケットの位置を示す第2オフセット情報を含むことを特徴とする請求項2に記載のデータ受信方法。前記位置情報は、前記位置情報に対応するセグメント内のあらゆるアクセスユニットについての位置情報を示す第3オフセット情報を含むことを特徴とする請求項2に記載のデータ受信方法。前記位置情報は、前記アクセスユニットが示す映像フレームのタイプを示す映像タイプ情報をさらに含むことを特徴とする請求項5に記載のデータ受信方法。前記位置情報は、前記位置情報が、ランダムアクセスが可能なポイントを示す方式によって分類された、前記位置情報に係わるタイプ情報をさらに含むことを特徴とする請求項2に記載のデータ受信方法。前記位置情報は、前記位置情報に対応するセグメント内のランダムアクセスが可能なパケットが、他のパケットと共に再生されるか否かを示す依存情報をさらに含むことを特徴とする請求項2に記載のデータ受信方法。前記位置情報は、前記共に再生されるパケットの個数を示す依存度情報をさらに含むことを特徴とする請求項8に記載のデータ受信方法。前記ランダムアクセスを提供するステップは、前記位置情報に基づいて、前記共に再生されるパケットを獲得するステップを有することを特徴とする請求項9に記載のデータ受信方法。前記位置情報は、前記位置情報に対応するセグメント内のランダムアクセスが可能なパケットが、三次元映像を提供するのに使われるか否かを示す三次元映像情報をさらに含むことを特徴とする請求項2に記載のデータ受信方法。前記位置情報は、前記ランダムアクセスが可能なパケットが提供する映像フレームの視点を示す視点情報をさらに含むことを特徴とする請求項10に記載のデータ受信方法。前記位置情報は、前記位置情報が複数個のパケットにまたがって存在する場合、現在パケットが、前記位置情報を含む最後のパケットであるか否かを示す終了情報をさらに含むことを特徴とする請求項4に記載のデータ受信方法。データを受信する装置において、コンテンツを異なる品質にエンコーディングすることで生成されるそれぞれ少なくとも1つのセグメントを含む複数個のメディアデータのうち少なくとも一つを受信する受信部と、前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を獲得する獲得部と、前記位置情報に基づいて、前記受信されたメディアデータに係わるランダムアクセスを提供する提供部と、を備えることを特徴とするデータ受信装置。方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、前記方法は、コンテンツを異なる品質にエンコーディングすることで生成されるそれぞれ少なくとも1つのセグメントを含む複数個のメディアデータのうち少なくとも一つを受信するステップと、前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を獲得するステップと、前記位置情報を利用し、前記受信されたメディアデータに係わるランダムアクセスを提供するステップと、を有するデータ受信方法を備えることを特徴とする記録媒体。前記の問題点を解決するための本発明の目的は、メディアデータ内に含まれるセグメント内のランダムアクセスが可能なポイントを示す位置情報を伝送または受信することによって、ランダムアクセス機能を効率的に提供するデータ伝送/受信の方法及びその装置を提供することである。例示的な実施形態の一態様によれば、データ受信の方法が提供される。前記方法は、異なる品質を有するようにコンテンツをエンコードすることによって生成されるそれぞれ少なくとも1つのセグメントを有する複数のメディアデータのうち少なくとも1つを受信するステップと、ステップ前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能な地点を示す位置情報を獲得するステップと、前記位置情報を利用し、前記受信したメディアデータに対するランダムアクセスを提供するステップと、を有する。前記獲得するステップは、前記少なくとも1つのセグメントそれぞれに含まれた少なくとも1つのパケットから、前記少なくとも1つのセグメントそれぞれに対応する位置情報を獲得するステップを含んでもよい。前記位置情報は、前記位置情報に対応するセグメント内に含まれるランダムアクセスが可能な次のパケットの位置を示す第1オフセット情報を含んでもよい。前記位置情報は、前記位置情報に対応するセグメント内に含まれるランダムアクセスが可能なあらゆるパケットの位置を示す第2オフセット情報を含んでもよい。前記位置情報は、前記位置情報に対応するセグメント内のあらゆるアクセスユニットaccessunitについての位置情報を示す第3オフセット情報を含んでもよい。前記位置情報は、前記アクセスユニットが示す映像フレームのタイプを示す映像タイプ情報をさらに含んでもよい。前記位置情報は、前記位置情報がランダムアクセスが可能なポイントを示す方式によって分類された、前記位置情報に係わるタイプ情報をさらに含んでもよい。前記位置情報は、前記位置情報に対応するセグメント内のランダムアクセスが可能なパケットが、他のパケットと共に再生されなければならないか否かを示す依存dependency情報をさらに含んでもよい。前記位置情報は、前記共に再生されなければならないパケットの個数を示す依存度情報をさらに含んでもよい。前記ランダムアクセスを提供するステップは、前記位置情報に基づいて、前記共に再生されなければならないパケットを獲得するステップを含んでもよい。前記位置情報は、前記位置情報に対応するセグメント内のランダムアクセスが可能なパケットが、三次元映像を提供するのに使われるか否かを示す三次元映像情報をさらに含んでもよい。前記位置情報は、前記ランダムアクセスが可能なパケットが提供する映像フレームの視点を示す視点情報をさらに含んでもよい。前記位置情報は、前記位置情報が複数個のパケットにまたがって存在する場合、現在パケットが、前記位置情報を含む最後のパケットであるか否かを示す終了情報をさらに含んでもよい。前記少なくとも1つのパケットは、MPEG2標準によって符号化され、前記位置情報は、前記少なくとも1つのパケットのprivate_data_bytesフィールドのうち少なくとも1つの位置情報から獲得される。前記少なくとも1つのパケットは、MPEG4標準によって符号化され、前記位置情報は、moovボックス及びmoofボックスのうち少なくとも一つから獲得される。例示的な実施形態の一態様によれば、データ送信の方法が提供される。前記方法は、異なる品質を有するようにコンテンツをエンコーディングすることで生成されるそれぞれ少なくとも1つのセグメントを有する複数のメディアデータを獲得するステップと、前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成するステップと、前記位置情報を伝送するステップと、を含む。例示的な実施形態の他の態様によれば、データ受信装置が提供される。前記装置は、異なる品質を有するようにコンテンツをエンコードすることによって生成されるそれぞれ少なくとも1つのセグメントを有する複数のメディアデータのうち少なくとも1つを受信する受信部と、前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を、前記受信されたメディアデータから獲得する獲得部と、前記位置情報を利用し、前記受信されたメディアデータに対するランダムアクセスを提供する提供部とを備える。例示的な実施形態の他の態様によれば、データ伝送装置が提供される。前記装置は、異なる品質を持つようにコンテンツをエンコーディングすることで生成されるそれぞれ少なくとも1つのセグメントを有する複数のメディアデータを獲得する獲得部と、前記少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成する生成部と、前記位置情報を伝送する伝送部とを備える。以下、添付された図面を参考にしつつ、本発明の望ましい実施形態について詳細に説明する。まず、説明の便宜のために、本明細書で使われる用語を簡単に定義する。コンテンツの一例は、オーディオ情報、ビデオ情報、オーディオビデオ情報及びデータを含む。コンテンツアイテムcontentitemは、後述する複数個のコンポーネントcomponentから構成される。コンポーネントは、オーディオ情報、ビデオ情報、サブタイトル情報のように、コンテンツアイテムの成分である。一例として、コンポーネントは、特定言語で作成されたサブタイトルストリームや、特定カメラアングルで獲得したビデオストリームであってもよい。コンポーネントは、コンテナによって、トラックや基本ストリームES:elementarystreamと命名可能である。コンテンツリソースは、コンテンツアイテムに係わる適切なストリーミングを可能にするために、複数個のリプリゼンテーションrepresentationから提供されるコンテンツアイテムである例えば、多様な品質、ビットレート、角度。サービス検索過程は、コンテンツリソースと言うことができる。コンテンツリソースは、一つ以上の連続的なタイムのペイロードから構成される。ピリオドは、コンテンツリソースの時間的なセクションである。リプリゼンテーションは、ピリオド内のコンテンツリソースのバージョンあらゆるコンポーネントまたは一部コンポーネントである。リプリゼンテーションは、コンポーネントのサブセットが異なるか、あるいはコンポーネントのエンコーディングパラメータ例えば、ビットレートが異なる。本明細書では、リプリゼンテーションをメディアデータとするが、一つ以上のコンポーネントを含むデータを指すいかなる用語にも使われる。セグメント部分は、特定システムレイヤ形式TSまたはMP4で、唯一のURLを介して呼ばれるリプリゼンテーションの時間的なセクションを意味する。以下、図面を参照しつつ、本発明の実施形態について詳細に説明する。図1は、本発明の一実施形態によるストリーミングシステムを図示している。図1を参照すれば、本発明の一実施形態によるストリーミングシステム100は、エンコーディング装置110、サーバ120及びクライアント130を有する。エンコーディング装置110は、入力されたコンテンツを複数の異なる品質にエンコーディングし、1つのコンテンツに係わる複数のメディアデータを生成する。サーバ120が、クライアント130にメディアデータをストリーミングするとき、ストリーミング環境は変更される。例えば、ストリーミングのためのネットワーク140の帯域幅が変更され得るし、メディアデータを伝送するために、サーバ120が使用可能なハードウェア資源、またはメディアデータを受信するために、クライアント130が使用可能なハードウェア資源が変更され得る。従って、エンコーディング装置110は、流動的なストリーミング環境による適切なストリーミングのために、1つのコンテンツを複数の異なる品質にエンコーディングする。ビット率、サンプリング周波数samplingfrequencyまたは解像度のような因子を調節することによって、1つのコンテンツを複数の異なる品質にエンコーディングすることができる。例えば、1つの動映像コンテンツを互いに異なる解像度でエンコーディングし、500Kbps、1,000Kbps及び2,000Kbpsの複数のメディアデータを生成することができる。異なる品質にエンコーディングされた複数のメディアデータは、サーバ120に伝送され、このとき、コンテンツに係わる情報及び複数のメディアデータそれぞれに係わる情報も、共にサーバ120に伝送される。コンテンツに係わる情報は、コンテンツのメタデータであって、コンテンツの題目title、シノプシスsynopsis、コンテンツ識別子contentID、コンテンツURLのような情報を含んでもよい。複数のメディアデータに係わる情報は、それぞれのメディアデータの品質、類型及び識別子などを含むことができるが、これについては、図4A、図4B及び図4Cを参照して詳細に説明する。クライアント130は、コンテンツに係わる情報及び複数のメディアデータに係わる情報のうち少なくとも一つを受信し、これに基づいて、サーバ120に複数のメディアデータのうち少なくとも1つのメディアデータを要請する。クライアント130は、ストリーミング環境を推定estimationし、推定されたストリーミング環境に基づいて、複数のメディアデータのうち少なくとも1つのメディアデータを選択する。推定されたストリーミング環境で、適切なQoSqualityofserviceを維持することができる少なくとも1つのメディアデータを選択することができる。その後、クライアント130は、選択された少なくとも1つのメディアデータの伝送を要請するHTTPhypertexttransferprotocol要請requestをサーバ120に伝送することができる。高品質のメディアデータを受信しているが、ストリーミング環境が劣化して続けてメディアデータを再生することができない場合には、複数のメディアデータのうち、低い品質のメディアデータを要請し、ストリーミング環境が改善されて高い品質のメディアデータを受信しても続けてメディアデータを再生することができる場合には、複数のメディアデータのうち、高い品質のメディアデータを要請することができる。所定のメディアデータを受信している最中に、他のメディアデータの伝送をサーバ120に要請することもできる。例えば、ストリーミング環境が劣化した状態で、低品質の第1メディアデータを要請して受信していたクライアント130は、ストリーミング環境が改善されることによって、さらに高品質の第2メディアデータの伝送をサーバ120に要請することができる。従来技術によるストリーミング方法によれば、サーバ120とクライアント130とが、ストリーミングチャネルを最初に設定するとき、品質を一度設定すれば、続けて同じ品質でメディアデータを送受信せねばならなかった。しかし、本願発明によれば、クライアント130が低品質の第1メディアデータを受信していても、同じコンテンツに係わるさらに高品質の第2メディアデータをさらに要請することができ、ストリーミング環境による適切なストリーミングが可能になる。ネットワーク140の帯域幅、及びサーバ120またはクライアント130の使用可能なハードウェア資源に基づいて、ストリーミング環境を推定する多様な方法が、クライアント130がストリーミング環境を推定するのに利用される。例えば、クライアント130は、受信されるメディアデータのタイムスタンプ及びBERbiterrorrateに基づいて、ストリーミング環境を推定することができる。受信されるメディアデータのタイムスタンプを確認し、メディアデータが再生速度より遅い速度で受信されていれば、ストリーミング環境が劣化していると判断することができる。また、受信されるメディアデータのBERが高くなっても、ストリーミング環境が劣化していると判断することができる。クライアント130が、ストリーミング環境によって複数のメディアデータのうち、少なくとも1つのメディアデータの伝送を要請すれば、サーバ120は、要請されたメディアデータをクライアント130に伝送する。HTTP要請に対するHTTP応答として、要請されたメディアデータをクライアント130に伝送することができる。複数のメディアデータそれぞれは、コンテンツを異なる品質にエンコーディングし、分割して生成された複数の部分segmentのうち、少なくとも一つを含んでもよい。言い換えれば、エンコーディング装置110のエンコーディング結果として生成された複数のメディアデータそれぞれは、時間に基づいて分割された少なくとも1つの部分をそれぞれ含んでもよい。サーバ120は、コンテンツを1つのストリームにエンコーディングして連続して伝送するのではなく、複数の部分に分割してそれぞれ伝送する。コンテンツを10秒または20秒のように、所定の時間単位でコンテンツを分割し、複数の部分を生成することができる。分割の基礎になる時間は、GOPgroupofpictureに基づいて設定される。一つまたは二つ以上のGOPのピクチャに対応するメディアデータを、1つの部分として設定することができる。例えば、2種の品質にコンテンツがストリーミングされる場合、第1メディアデータは、コンテンツを第1品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を含み、第2メディアデータは、コンテンツを第2品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を含んでもよい。複数のメディアデータを時間に基づいてそれぞれ分割することによって、前述の適切なストリーミングが可能になる。例えば、ストリーミングが始まれば、サーバ120は、低品質の第1メディアデータの0秒から20秒に該当する部分を伝送する。その後、20秒後に、ストリーミング環境が改善されたと判断され、クライアント130がさらに高品質のメディアデータを要請すれば、サーバ120は、さらに高品質の第2メディアデータの、20秒から40秒に該当する部分を伝送することができる。メディアデータが、時間に基づいて複数の部分に分割されているために、ストリーミング最中にも、ストリーミング環境によって異なるメディアデータの部分を伝送することができる。図2Aは、本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。図2Aを参照すれば、ステップ210でクライアント130は、所定のコンテンツに係わる情報の伝送をサーバ120に要請する。クライアント130のユーザが、クライアント130の画面に表示されたユーザインターフェースで、所定のコンテンツを選択すれば、選択されたコンテンツに係わる情報の伝送をサーバ120に要請する。クライアント130は、コンテンツに係わる情報の伝送を要請するHTTP要請を、サーバ120に伝送することができる。クライアント130からの要請を受信したサーバ120は、クライアント130にコンテンツに係わる情報を伝送する。HTTP要請に対するHTTP応答として、コンテンツに係わる情報をクライアント130に伝送することができる。コンテンツに係わる情報は、OIPFopenIPTVforum標準によるCADcontentaccessdescriptorであってもよい。図3を参照して詳細に説明する。図3は、本発明の一実施形態によるコンテンツに係わる情報を含むファイルのスキーマschemaを図示している。コンテンツに係わる情報を含むファイルは、CADであって、XMLextensiblemarkuplanguageファイルであってもよい。以下、本発明の詳細な説明では、タグtag及び属性attributeを区分して説明するが、本発明の詳細な説明で、タグによって定義される項目を、タグではない属性によって定義する、又は本発明の詳細な説明で、属性によって定義される項目を、属性ではないタグによって定義することができることは、本発明が属する技術分野で当業者であるならば、容易に理解できる。図3を参照すれば、コンテンツcontentに係わる情報は、Title、Synopsis、OriginSite、ContentURLのタグなどを含んでもよい。従来技術によるメディアデータのストリーミングは、1つのコンテンツを所定の品質にエンコーディングし、1つのメディアデータを生成するので、従来技術によるコンテンツに係わる情報特に、OIPFによるCADは、コンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータに係わる情報を含まない。しかし、本発明の一実施形態によるコンテンツに係わる情報は、1つのコンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータに係わる情報を含むが、図3に図示された実施形態のTracks、RefData及びFragmentsのタグがこれに該当する。図4Aは、本発明の一実施形態による複数のメディアデータを定義するための情報を図示している。図4Aを参照すれば、Tracksタグは、コンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータを区分するための情報である。Tracksタグは、複数のメディアデータそれぞれに割り当てられたID属性attribute、Type属性及びBitRate属性を含む。ID属性は、メディアデータに対して順に付与される識別子を定義し、Type属性は、メディアデータのオーディオデータ、ビデオデータ、ビデオ/オーディオデータ、字幕データのうち、どのデータに該当するかを定義する。Type属性がPackedであるならば、メディアデータがビデオ/オーディオデータであることを示し、Type属性がVideoであるならば、メディアデータがビデオデータであることを示す。BitRate属性は、ビデオデータのエンコーディングに利用されたビット率を定義する。図4Bは、本発明の一実施形態によるメディアデータのヘッダに係わる情報を図示している。図4Bを参照すれば、RefDataタグは、Type属性及びID属性を含む。Type属性は、ヘッダがいかなるメディアフォーマットのヘッダであるかを定義する。例えば、Type属性がHEAD-TSであるならば、ヘッダが、伝送ストリームtransportstreamフォーマットのヘッダであることを示す。ID属性は、ヘッダが複数のメディアデータのうち、どのメディアデータのヘッダであるかを定義する。ID属性が1であるならば、メディアデータ識別子が、1であるメディアデータに係わるヘッダであることを示す。また、RefDataタグは、ヘッダを指示pointingする情報を含むが、URLタグは、ヘッダの位置、すなわち、URLを定義する。RefDataタグは、選択的な要素である。ヘッダがメディアデータと分離され、別途のファイルとして存在する場合にのみ、コンテンツに係わる情報にRefDataタグが含まれ、メディアデータと結合されて存在する場合には、コンテンツに係わる情報に、RefDataタグが含まれない。図4Cは、本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも1つの部分に係わる情報を含む。図4Cを参照すれば、Fragmentsタグの下位タグであるFragmentタグに、複数のメディアデータそれぞれに含まれた少なくとも1つの部分に係わる情報が含まれる。Fragmentsタグは、NextFragmentsXMLURL属性を含む。ライブストリーミングのように、1つのコンテンツストリーミングが完了すれば、次のコンテンツが続いてストリーミングされる場合には、次にストリーミングされるコンテンツに係わる情報をクライアント130があらかじめ知っていてこそ、続けてコンテンツをストリーミングすることができる。従って、Fragmentsタグは、次にストリーミングされるコンテンツに係わる情報をNextFragmentsXMLURL属性と定義する。次にストリーミングされるコンテンツに係わる複数のメディアデータのURLがNextFragmentsXMLURL属性と定義される。Fragmentタグは、現在ストリーミングされるコンテンツの少なくとも1つの部分に係わる情報を含む。図4Cに図示された実施形態を例に挙げて説明すれば、第1メディアデータとしてコンテンツを第1品質にエンコーディングすることで生成された最初の部分であるslice1-1.asのURL情報が、URLタグによって定義され、対応するヘッダの識別子がRefPointerタグによって定義される。また、最初の部分の開始時間がStartTime属性によって定義され、それぞれの部分の持続時間がDuration属性によって定義される。第1メディアデータの品質は、BitRate属性によって定義される。図4Cに図示された実施形態ではFragmentsタグは、それぞれのメディアデータが1つの部分だけを含む場合を図示した。しかし、本発明が属する技術分野で当業者であるならば、図1と関連して説明したように、それぞれのメディアデータが複数の部分に分割される場合、1つのFragmentsタグが二以上の部分に係わる情報を含んでもよいということが容易に分かるであろう。再び図2Aを参照すれば、ステップ220でクライアント130は、複数のメディアデータのうち少なくとも1つのメディアデータの伝送をサーバ120に要請する。複数のメディアデータは、1つのコンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータである。クライアント130は、複数のメディアデータのうちから、ストリーミング環境に適した品質に符号化された少なくとも1つのメディアデータを選択し、サーバ120に要請する。クライアント130は、コンテンツに係わる情報に含まれた複数のメディアデータに係わる情報に基づいて、HTTP要請をサーバ120に伝送することができる。コンテンツに係わる情報は、図4Cと関連して説明したように、Fragmentsタグを含んでいる。従って、クライアント130は、Fragmentsタグに含まれたURL情報に基づいて、選択されたメディアデータの伝送をサーバ120に要請する。クライアント120の要請によって、サーバ120は、メディアデータを伝送する。要請されたメディアデータの少なくとも1つの部分をクライアント120に伝送することができる。HTTP要請に対するHTTP応答として、要請されたメディアデータをクライアント120に伝送することができる。図2Bは、本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。図2Bは、ヘッダがメディアデータと分離され、別途のファイルとして存在する場合のストリーミング方法を図示している。図2Bを参照すれば、ステップ212でクライアント130は、所定のコンテンツに係わる情報の伝送をサーバ120に要請し、サーバ120からコンテンツに係わる情報を伝送する。図2Aのステップ210に図示されている。図4Bと関連して説明したRefDataタグを含むコンテンツに係わる情報を受信する。ステップ222でクライアント130は、ステップ210で受信されたコンテンツに係わる情報に基づいて、複数のメディアデータのうち選択されたメディアデータのヘッダを要請する。ステップ212で受信されたコンテンツに係わる情報に基づいて、複数のメディアデータのうちストリーミング環境に適した少なくとも1つのメディアデータを選択し、選択したメディアデータのヘッダを要請する。ステップ212で受信されたコンテンツに係わる情報に含まれたRefDataタグを参照し、選択されたメディアデータのヘッダを要請する。サーバ120は、要請されたメディアデータのヘッダをクライアント130に伝送する。ヘッダファイルをクライアント130に伝送することができ、ヘッダファイルは、XMLファイルであってもよい。ステップ232でクライアント130は、ステップ212で受信されたコンテンツに係わる情報及びステップ222で受信されたヘッダに基づいて、選択されたメディアデータの伝送をサーバ120に要請する。メディアデータを時間に基づいて分割し、生成された少なくとも1つの部分の伝送をサーバ130に要請し、サーバ120は、要請された少なくとも1つの部分をクライアント130に伝送する。図5Aは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。図5Aを参照すれば、ステップ510でクライアント130は、所定のコンテンツに係わる情報の伝送をサーバ120に要請し、サーバ120からコンテンツに係わる情報を伝送する。所定のコンテンツに係わる情報の伝送を要請するHTTP要請をサーバ120に伝送し、これに対するHTTP応答として、コンテンツに係わる情報を受信する。コンテンツに係わる情報を含むXMLファイルを受信することができる。ステップ510でクライアント130が受信するコンテンツに係わる情報は、図2のステップ210でクライアント130が受信するコンテンツに係わる情報と異なるが、図6及び図7を参照して詳細に説明する。図6は、本発明の他の実施形態によるコンテンツに係わる情報を含むファイルのスキーマを図示している。図6を参照すれば、本発明の一実施形態によるコンテンツに係わる情報は、図3と同一に、Title、Synopsis、OriginSite、ContentURLのタグなどを含んでいる。しかし、図3に図示された実施形態では、コンテンツに係わる情報がTracks、RefData及びFragmentsのタグを含むことによって、複数のメディアデータに係わる情報も共に含むのに対し、図6に図示された実施形態では、コンテンツに係わる情報が、複数のメディアデータに係わる情報を含むのではなく、複数のメディアデータに係わる情報を含むファイル以下、メディア表現記述mediapresentationdescriptionのURLのみ定義するところが異なる。ContentURLタグによって、メディア表現記述のURLが定義される。図6に図示されているように、従来技術による多様なコンテンツに係わる情報ファイルのスキーマを大きく変更せずに、メディア表現記述のURLだけコンテンツに係わる情報ファイルに挿入することによって、多様なメディアデータフォーマットとの互換性を維持しつつ、ストリーミング環境に適切なストリーミングが可能になる。図6に図示されたところによれば、コンテンツに係わる情報は、複数のメディアデータに係わる情報は含まず、ストリーミング方法と関連した情報だけ含んでもよい。言い換えれば、ContentURLタグは、ストリーミングに利用されるメディアデータのフォーマットを定義するMediaFormat属性、メディアデータの種類を定義するMIMEType属性などを含んでもよい。特に、ContentURLタグは、コンテンツのストリーミングがいかなるサービスと関連しているかを定義するTransferType属性を含んでもよい。TransferType属性は、コンテンツのストリーミングが、CoDcontentondeliveryサービス、生中継live、適応ストリーミング生中継adaptivestreaminglive及び適応ストリーミングCoDadaptivestreamingCoDのうち、いかなるサービスと関連しているかを定義することができる。図7は、本発明のさらに他の実施形態によるコンテンツに係わる情報を図示している。図7は、OIPF標準によるCADであってもよい。図7を参照すれば、図6に図示されたスキーマによって生成されたコンテンツに係わる情報は、ContentURLタグに、メディア表現記述のURLが定義される。http://asexample.com/vod/movies/18888/Meta/MainMeta.xmlがメディア表現記述のURLである。また、図6と関連して説明したように、MediaFormat属性、MIMEType属性及びTransferType属性などがContentURLタグに定義される。再び図5Aを参照すれば、ステップ520でクライアント130は、ステップ510で受信されたコンテンツに係わる情報に基づいて、複数のメディアデータに係わる情報をサーバ120に要請する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。ステップ510でクライアント130がサーバ120から受信したコンテンツに係わる情報は、図6及び図7と関連して説明したように、メディア表現記述のURL情報を含んでもよいが、クライアント130は、コンテンツに係わる情報のContentURLタグを参照し、メディア表現記述をサーバ120に要請して受信する。メディア表現記述について、図8A、図8B、図9Aないし図9Gを参照しつつ詳細に説明する。図8A及び図8Bは、本発明の一実施形態によるメディア表現記述のスキーマを図示している。メディア表現記述は、OIPF標準によるメディア表現記述であってもよい。図8Aを参照すれば、本発明の一実施形態によるメディア表現記述は、複数のメディアデータのURLに対するテンプレートtemplateタグ、ヘッダの位置を定義するためのタグ、ストリーミングがいかなるサービスと関連しているかを定義するためのタグ、メディアデータコンテナcontainerフォーマットを定義するためのタグ、及び複数のメディアデータを定義するためのタグを含む。urlTemplateタグは、複数のメディアデータに係わるURL情報の共通部分を定義する。例えば、http://example.com/vod/movie/18888/Track/{TrackID}/Segments/{SegmentID}がURLテンプレートであるならば、TrackID及びSegmentIDに複数のメディアデータそれぞれの識別子、及びそれぞれのメディアデータに含まれた少なくとも1つの部分の識別子を代入することにより、メディアデータに係わるURLを定義することができる。headerUrlタグは、図4Bと関連して説明したRefDataタグに対応する。言い換えれば、複数のメディアデータのヘッダURLを定義する。isLiveタグは、ストリーミングがいかなるサービスと関連しているかを定義するタグである。例えば、isLiveタグがLiveと定義されれば、ストリーミングが生放送サービスと関連していることを示し、isLiveタグがCoDと定義されれば、ストリーミングがCoDサービスと関連していることを示す。contentTypeタグは、ストリーミングに利用されるメディアデータのコンテナフォーマットを定義する。例えば、メディアデータのコンテナフォーマットがMP4フォーマットであるか、あるいはMPEG2-TSフォーマットであるかを示すための情報であってもよい。Streamタグは、複数のメディアデータそれぞれについて生成され、複数のメディアデータそれぞれを定義する。1つのコンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータそれぞれを定義するために、streamName属性、Type属性、bitrate属性、startTime属性、firstIntervalNum属性、duration属性、及びintervalCount属性を含む。streamName属性は、メディアデータの名称を定義する。メディアデータの識別子であってもよい。Type属性は、メディアデータの類型を定義する。メディアデータがオーディオデータ、ビデオデータ及びオーディオ/ビデオデータのうち、いかなるメディアのデータであるかを定義する。メディアデータが変速再生トリックプレイのために、Iフレームに係わるデータだけを含む場合には、これに係わる情報をType属性と定義することができる。BitRate属性は、メディアデータのビット率を定義し、startTime属性は、メディアデータの開始時間を特定するタイムスタンプを定義し、firstIntervalNum属性は、最初に始まる部分の番号を定義する。duration属性は、メディアデータに含まれた部分の持続時間を定義し、intervalCount属性は、メディアデータに含まれた少なくとも1つの部分の全体個数を定義する。Segmentタグは、Streamタグの下位タグであり、メディアデータが、前述のように、コンテンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分であるならば、このような少なくとも1つの部分それぞれを定義する。IntNum属性は、部分の番号を定義し、StartTimeは、当該部分の開始時間を定義する。Durationは、当該部分の持続時間を定義し、urlは、当該部分のURL情報を定義する。Segmentタグは、選択的なタグであり、メディアデータに含まれた少なくとも1つの部分に係わる情報が、Streamタグの他の属性から類推される場合には、メディア表現記述に含まれない。言い換えれば、Streamタグに定義されたstartTime、firstIntervalNum、duration及びintervalCountの属性によってStreamタグから類推される場合には、メディア表現記述に含まれない。また、urlTemplateタグに所定のテンプレートが定義されており、このように定義されたテンプレートに、複数のメディアデータそれぞれの識別子、及びそれぞれのメディアデータに含まれた少なくとも1つの部分の識別子を代入することにより、部分のURL情報を類推することができれば、Segmentタグのurl属性は不要となる。図8Bを参照すれば、本発明の他の実施形態によるメディア表現記述は、nextManifestURLタグをさらに含んでもよい。前述のように、ライブストリーミングまたは広告の挿入のように、1つのコンテンツストリーミングが完了すれば、次のコンテンツが続いてストリーミングされる場合には、次にストリーミングされるコンテンツに係わる情報をクライアント130があらかじめ知っていてこそ、続けてコンテンツをストリーミングすることができるので、現在ストリーミング中であるコンテンツ次にストリーミングされるコンテンツのメディア表現記述のURL情報がnextManifestURLタグによって定義される。図9Aないし図9Hは、本願発明の一実施形態によるメディア表現記述を図示している。図9Aを参照すれば、本発明の一実施形態によるメディア表現記述は、URLTemplateタグ、RefDataURLタグ及び複数のメディアデータそれぞれを定義する複数のタグを含む。URLTemplateタグ及びRefDataURLタグは、それぞれ図8A及び図8BのurlTemplateタグ及びRefDataURLタグに対応する。ID属性、Type属性、BitRate属性、StartTime属性、SegmentDuration属性、SegmentStartID属性及びSegmentCount属性は、それぞれ図8A及び図8BのstreamName属性、Type属性、bitrate属性、startTime属性、Streamタグのduration属性、StreamタグのfirstIntervalNum属性及びintervalCount属性に対応する。図9Aに図示されたメディア表現記述は、コンテンツを異なる品質にエンコーディングすることで生成された3種のビデオデータ、1つのオーディオデータ及び変速再生のために、Iフレームだけエンコーディングすることで生成されたメディアデータに係わる情報を含む。図9Bを参照すれば、本発明の一実施形態によるメディア表現記述は、NextAdaptiveControlURLタグをさらに含む。NextAdaptiveControlURLタグは、図8BのnextManifestURLタグに対応する。従って、現在再生中であるコンテンツ後に続いて再生するコンテンツのメディア表現記述のURLが、NextAdaptiveControlURLタグによって定義される。図9Cは、現在再生中であるコンテンツに続いて再生するコンテンツのメディア表現記述のURLが、図9BのNextAdaptiveControlURLタグによって定義されたとき、次に続いて再生するコンテンツのメディア表現記述を図示する。図9Bのメディア表現記述と比較すれば、図9Cは、次に続いて再生されるコンテンツのメディア表現記述であるから、StartTime属性の現在再生中であるコンテンツのメディア表現記述と異なる。図9D及び図9Eは、ユーザの高画質ビデオ再生を選択的に制御するためのメディア表現記述を図示している。1つのコンテンツを5種の異なる品質にエンコーディングし、複数のメディアデータが生成され、図9Dは、その場合のメディア表現記述を図示する。しかし、図9Eに図示されたメディア表現記述で、高品質にエンコーディングされたビデオに係わる情報を含んでいるタグ、すなわち、ID属性が5であるメディアデータのStartTime属性及びSegmentCount属性が、図9Dのメディア表現記述と異なる。サーバ120は、クライアント130のユーザ等級ratingによって、図9Dのメディア表現記述、または図9Eのメディア表現記述を選択的に伝送することができる。クライアント130のユーザ等級が高い場合例えば、クライアント130が有料ユーザである場合には、図9Dのメディア表現記述を伝送することによって、高品質のビデオも自由に再生可能であり、クライアント130のユーザ等級が低い場合例えば、クライアント130が無料ユーザである場合には、図9Eのメディア表現記述を伝送することによって、高品質のビデオは、StartTime属性によって定義された時間から、SegmentCount属性によって定義された部分だけ再生可能とする。図9Fは、コンテンツに広告が挿入される場合のメディア表現記述を図示している。図9Fを参照すれば、メディア表現記述は、StartTime属性が異なる広告コンテンツ及びメインコンテンツに係わる情報を含んでもよい。メディア表現記述は、00:00:00から00:02:00まで再生されるビット率が500000である広告コンテンツに係わる情報、及び00:02:00から再生されるビット率が、1000000、2000000、3000000及び4000000のメインコンテンツに係わる情報を含んでもよい。サーバ120が広告コンテンツを1つのビット率によってエンコーディングしてクライアント130に提供し、広告コンテンツとStartTime属性を異にするメインコンテンツは、4種の異なるビット率によってエンコーディングしてクライアント130に提供する場合、図9Fのメディア表現記述が、サーバ120からクライアント130に伝送される。図9Gは、本発明の一実施形態による広告コンテンツに係わる情報を含むメディア表現記述を図示している。メインコンテンツを提供するサーバと、広告コンテンツを提供するサーバとが異なってもよい。言い換えれば、クライアント130が、メインコンテンツは、図5Aのサーバ120から提供され、広告コンテンツは、図5Aのサーバ120ではない他のサーバから受信する場合、広告コンテンツに係わる情報を含むメディア表現記述は、広告コンテンツのURL情報を含んでもよい。図9Gに図示されているように、1つの品質に符号化された広告コンテンツのURL情報が、メディア表現記述に含まれてもよい。図9Hは、本発明の一実施形態による言語情報及び字幕情報を含むメディア表現記述を図示している。図9Hを参照すれば、オーディオデータは、多重言語に係わる情報を含んでもよい。ID属性が4及び5である多重言語のオーディオデータに係わる情報が、メディア表現記述に含まれ、ID属性が6及び7である多重言語の字幕に係わる情報がメディア表現記述に含まれてもよい。オーディオデータは、もちろん字幕も、時間によって複数の部分に分割されるので、ストリーミング最中に、オーディオデータ及び字幕を異なる言語のオーディオデータ及び字幕に変更することができる。再び図5Aを参照すれば、ステップ530でクライアント130は、複数のメディアデータのうち少なくとも1つのメディアデータの伝送をサーバ120に要請する。クライアント130は、複数のメディアデータに係わる情報を参照し、ストリーミング環境に適した品質にエンコーディングされた少なくとも1つのメディアデータを選択してサーバ120に要請する。クライアント130は、所定のメディアデータの伝送を要請するHTTP要請をサーバ120に伝送することができる。クライアント120の要請によってサーバ120は、メディアデータを伝送する。コンテンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を、クライアント120に伝送することができる。HTTP要請に対するHTTP応答として、要請されたメディアデータをクライアント120に伝送することができる。図5Bは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。図5Bを参照すれば、ステップ512でクライアント130は、所定のコンテンツに係わる情報の伝送をサーバ120に要請し、サーバ120からコンテンツに係わる情報が伝送される。所定のコンテンツに係わる情報の伝送を要請するHTTP要請をサーバ120に伝送し、これに対するHTTP応答として、コンテンツに係わる情報を受信する。コンテンツに係わる情報を含むXMLファイルを受信することができる。ステップ522でクライアント130は、ステップ512で受信されたコンテンツに係わる情報に基づいて、複数のメディアデータに係わる情報をサーバ120に要請する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。ステップ532でクライアント130は、ステップ522で受信した複数のメディアデータに係わる情報に基づいて、選択されたメディアデータのヘッダを要請する。ステップ522で受信した情報に基づいて、複数のメディアデータのうち、ストリーミング環境に適した少なくとも1つのメディアデータを選択し、選択したメディアデータのヘッダを要請する。ステップ522で受信した複数のメディアデータに係わる情報を参照し、選択したメディアデータのヘッダを要請する。サーバ120は、要請に対する応答として、選択されたメディアデータのヘッダファイルをクライアント130に伝送する。ステップ542でクライアント130は、ステップ522で受信した複数のメディアデータに係わる情報、及びステップ532で受信したヘッダに基づいて、選択したメディアデータの伝送をサーバ120に要請する。コンテンツを所定の比率でエンコーディング、及び時間分割して生成された少なくとも1つの部分の伝送をサーバ130に要請し、サーバ120は、要請された少なくとも1つの部分をクライアント130に伝送する。図10Aないし図10Cは、本発明の一実施形態による複数のメディアデータを図示している。図10Aないし図10Cは、図5A及び図5Bによるストリーミング方法を遂行するために、サーバ120が保有する複数のメディアデータを図示している。図10Aを参照すれば、ストリーミング環境に適切なストリーミングのために、サーバ120は、1つのコンテンツを複数の異なる品質にエンコーディングすることで生成された複数のメディアデータ1010ないし1030を保有することができる。Track1、Track2、...、TrackNが複数のメディアデータである。また、それぞれのメディアデータは、それぞれのメディアデータを時間に基づいて分割して生成された少なくとも1つの部分を含んでもよい。Slice1-1.as、Slice1-2.as、Slice1-3.as、Slice2-1.as、Slice2-2.as、Slice2-3.as、SliceN-1.as、SliceN-2.as、SliceN-3.asなどが少なくとも1つの部分である。またサーバ120は、クライアント130が複数のメディアデータにアクセスするために必要な情報1040を保有することができる。コンテンツに係わる情報として、CadMeta.xmlファイル、複数のメディアデータに係わる情報として、MainMeta.xmlファイルを保有することができ、複数のメディアデータのヘッダとして、Head1.ref、Head2.refのファイルなどを保有することができる。Head1.refは、Track1のヘッダファイルであって、Head2.refは、Track2のヘッダファイルである。CadMeta.xmlは、OIPF標準によるCADファイルであって、MainMeta.xmlは、前述のメディア表現記述であってもよい。また、Head1.ref、Head2.refのファイルは、選択的な要素であり、ヘッダが複数のメディアデータ1010ないし1030に含まれている場合には、存在しないこともある。図10Bを参照すれば、クライアント130が複数のメディアデータにアクセスするために必要な情報1042は、NextMeta.xmlをさらに含んでもよい。前述のように、NextMeta.xmlは、現在再生中であるコンテンツに続いて再生される次のコンテンツのメディア表現記述であってもよい。前述のように、現在再生中のメディア表現記述、すなわち、MainMeta.xmlファイルは、続いて再生するコンテンツのメディア表現記述のURL情報を含んでいるが、これに基づいてクライアント130は、NextMeta.xmlファイルにアクセスすることができる。図10Cを参照すれば、複数のメディアデータのヘッダは、1つのファイル1050として存在しうる。ヘッダファイルが複数のメディアデータそれぞれについて、複数で存在するのではなく、1つのヘッダファイル1050として、複数のメディアデータにアクセスするために必要な情報1044に含まれてもよい。例えば、複数のメディアデータそれぞれが、MPEG-2によるエレメンタリーストリームelementarystreamに対応するとき、複数のメディアデータのヘッダは、PATprogramassociationtable及びPMTprogrammaptableのうち、少なくとも一つを含む1つのヘッダファイル1050であってもよい。PAT及びPMTのうち、少なくとも一つを複数のメディアデータ1010ないし1030と分離し、1つのヘッダファイル1050を作り、メディア表現記述は、このヘッダファイル1050を指示pointingする情報を含んでもよい。ヘッダファイル1050の指示情報は、ヘッダファイル1050のURL情報でもあり、MPEG-2伝送ストリームtransportstreamで、ヘッダファイル1050を含んでいるパケットを特定するための情報でもある。前述のステップ532でクライアント130は、メディア表現記述を参照し、ヘッダファイル1050に指示情報を獲得し、指示情報に基づいて、ヘッダファイル1050を要請することができる。指示情報にヘッダファイル1050を要請して受信した後、ヘッダファイル1050に含まれているPAT及びPMTのうち少なくとも一つに基づいて、複数のメディアデータのうち少なくとも一つを選択し、選択したメディアデータをサーバ120に要請する。PAT及びPMTは、複数のメディアデータ1010ないし1030の全体リストを含む。MPEG-2によれば、PAT及びPMTで定義されるPIDpacketIDは、エレメンタリーストリームによって異なる。従って、複数のメディアデータそれぞれに割り当てられるPIDは、異なる。しかし、他の実施形態によれば、1つのコンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータは、同じコンテンツに係わるエレメンタリーストリームであるから、PIDが同一に設定されもする。複数のメディアデータ1010ないし1030が、MPEG-2による複数のエレメンタリーストリームに対応する場合、複数のメディアデータ1010ないし1030それぞれは、複数の連続したPESpacketizedelementarystreamを含んでもよい。複数のメディアデータは、1つのコンテンツを異なる品質にエンコーディングすることで生成されたものであるので、複数のメディアデータそれぞれに含まれたPESのPTSpresentationtimestamp及び/またはDTSdecodingtimestampは、メディアデータの再生時間によって整列されるaligned。言い換えれば、第1メディアデータの最初のPESと、第2メディアデータの最初のPESとが同じ時間に再生されるコンテンツであるならば、PTS及び/またはDTSが同一に設定される。図11Aは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。図11Aを参照すれば、ステップ1110でクライアント130は、複数のメディアデータに係わる情報をサーバ120に要請する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。クライアント130は、ストリーミング環境に適切なストリーミングを遂行するために、1つのコンテンツを複数の異なる品質にエンコーディングすることで生成された複数のメディアデータに係わる情報を、サーバ120に要請して受信する。コンテンツに係わる情報の要請及び受信なしに、複数のメディアデータに係わる情報の要請及び受信が遂行されるという点が、図5Aに図示された実施形態と異なる。ステップ1120でクライアント130は、複数のメディアデータのうち、少なくとも1つのメディアデータの伝送をサーバ120に要請する。クライアント130は、複数のメディアデータに係わる情報を参照し、ストリーミング環境に適した品質にエンコーディングされた少なくとも1つのメディアデータを選択してサーバ120に要請し、要請されたメディアデータをサーバ120から受信する。図11Bは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。図11Bを参照すれば、ステップ1112でクライアント130は、複数のメディアデータに係わる情報をサーバ120に要請し、要請に対する応答として、複数のメディアデータに係わる情報をサーバ120から受信する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。ステップ1122でクライアント130は、ステップ1112で受信した複数のメディアデータに係わる情報に基づいて、選択したメディアデータのヘッダを要請する。ステップ522で受信された複数のメディアデータに係わる情報を参照し、ストリーミング環境によって選択したメディアデータのヘッダを要請する。サーバ120は、要請に対する応答として、選択されたメディアデータのヘッダを含むファイルをクライアント130に伝送する。ステップ1132でクライアント130は、ステップ1112で受信した複数のメディアデータに係わる情報、及びステップ1122で受信したヘッダに基づいて選択したメディアデータの伝送をサーバ120に要請する。コンテンツを所定の比率でエンコーディング、及び時間分割して生成された少なくとも1つの部分の伝送をサーバ130に要請し、サーバ120は、要請された少なくとも1つの部分をクライアント130に伝送する。図12A及び図12Bは、本発明の他の実施形態による複数のメディアデータを図示している。図12A及び図12Bは、図11A及び図11Bによるストリーミング方法を遂行するために、サーバ120が保有する複数のメディアデータを図示している。図12Aを参照すれば、図10Aに図示された実施形態と同様に、ストリーミング環境に適切なストリーミングのためにサーバ120は、1つのコンテンツを複数の異なる品質にエンコーディングすることで生成された複数のメディアデータ1010ないし1030を保有することができる。クライアント130が複数のメディアデータにアクセスするために必要な情報1240だけ異なるが、図10Aに図示された実施形態とは異なり、サーバ120は、コンテンツに係わる情報を除外した複数のメディアデータに係わる情報だけ含んでもよい。この場合、クライアント130は、コンテンツに係わる情報を、サーバ120ではない他のエンティテイから受信し、コンテンツに係わる情報に基づいて、サーバ120が保有している複数のメディアデータにアクセスすることが可能である。図12Bを参照すれば、クライアント130が複数のメディアデータにアクセスするために必要な情報1242は、図12Aの情報1240に、NextMeta.xmlをさらに含んでもよい。図13は、本発明の一実施形態によるデータ伝送装置1300に係わるブロック図である。本発明の一実施形態によるデータ伝送装置1300は、獲得部1310、生成部1320及び伝送部1330を備える。獲得部1310は、同じコンテンツを異なる品質にエンコーディングすることで生成された複数個のメディアデータを獲得する。複数個のメディアデータは、所定のコンテンツを異なる方式でエンコーディングするか、あるいは同じ方式でエンコーディングするが、エンコーディングパラメータを異にして生成されたものであってもよい。その場合、複数個のメディアデータは、異なる特徴を有する。一例として、複数個のメディアデータは、ビット率bitrate、解像度resolution、コーデックcodecが異なる。複数個のメディアデータは、同じコンテンツから生成されたものであるので、相互間にスイッチングが可能である。ユーザは、高解像度のメディアデータを使用時に通信環境が悪化すれば、同じコンテンツから生成された低解像度のメディアデータにスイッチングすることができる。メディアデータ間のスイッチングは、セグメント単位で遂行されてもよい。セグメントは、エンコーディングされたコンテンツを、時間分割して生成される。従って、1つのメディアデータは、一つ以上のセグメントを含み得る。ユーザが、第1メディアデータ内のA番目のセグメントを使用していて、他の品質を有する第2メディアデータを再生しようとすれば、第1メディアデータ内のA番目のセグメントに対応する第2メディアデータ内のセグメントを受信して使用するのである。生成部1320は、少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成する。生成部1320は、1つの位置情報だけを生成し、1つの位置情報にあらゆるセグメントでのランダムアクセスポイント情報を含めることができるが、それぞれのセグメントに対応する複数個の位置情報を生成することができる。後者の場合、1つの位置情報には、ただ対応するセグメント内のランダムアクセスポイントの位置だけを含むのである。他の実施形態において、図32Cに図示されているように、生成部1320は、少なくとも1つの他のセグメントの位置情報を含む少なくとも1つのセグメントを生成する。セグメントは、一つ以上のデータユニットから構成され、生成部1320は、位置情報をデータユニット内の所定位置に挿入することができる。位置情報を伝送する方法は、実施形態によって多様である。以下、位置情報を伝送する方法に係わる例として、4種を提示するが、本願発明は、それらに限定されるものではない。iMPEG2標準によってエンコーディングされたメディアデータの場合、伝送パケットtransportpacketのadaptationfield内に位置したprivate_data_bytesフィールドに位置情報を挿入して伝送することができる。private_data_bytesフィールドは、TSレベルで、付加的なフレーム情報を提供するためのフィールドである。これについての詳細な説明は、図26Aを利用して後述する。ii伝送パケットtransportpacketのadaptationfield内に位置したadaptation_field_extensionフィールドに位置情報を挿入して伝送することができる。adaptation_field_extensionフィールドには、ユーザが新たに定義して使用できるreserved領域が存在し、reserved領域を介して位置情報を伝送する。これについての詳細な説明は、図26Bを利用して後述する。iii既存に存在するセクション内の所定のフィールドを介して、本願発明による位置情報を伝送する。一例として、MPEG-2では、TS_description_sectionを定義しており、TS_description_sectionは、descriptorフィールドを介して、多様な記述を提供する。本願発明による位置情報は、記述を介して伝送することができる。これについての詳細な説明は、図26C及び図26Dを参考にして後述する。iv新たなセクションを定義し、新たに定義されたセクションを介して、本願発明による位置情報を伝送する。セクションは、伝送ストリームを介して伝送されるデータ形式の一つであり、主にサービス情報及びプログラム案内情報のようなサービス関連情報を含むデータである。これについての詳細な説明は、図26E及び図26Fを利用して後述する。vMPEG4標準によってエンコーディングされたメディアデータの場合、Moofボックスまたは、Moovボックスに位置情報を挿入する。以下、説明の便宜のために、パケットを基準にして説明する。しかし、本発明は、MPEG4標準によるボックスのように、他の標準によるエンコーディングでも同一に適用されることは、当業者に自明である。位置情報は、対応するセグメント内でのランダムアクセスが可能なポイントを指示する方式によって、異なる構造を有することができる。本明細書では、3種タイプの位置情報について説明する。しかし、位置情報は、これに限定されるものではない。第1タイプの位置情報は、対応するセグメント内のランダムアクセスが可能な次のパケットの位置を示す第1オフセット情報を含む。第1タイプの位置情報は、ランダムアクセスが可能なそれぞれのパケット内の所定位置に配置されるのである。第1タイプの位置情報に係わる詳細な説明は、図15及び図20で後述する。第2タイプの位置情報は、対応するセグメント内のランダムアクセスが可能なあらゆるパケットの位置を示す第2オフセット情報を含む。第2タイプの位置情報は、1つのパケットにいずれも含まれるか、あるいは連続する複数個のパケットにまたがって含まれてもよい。一例として、セグメントの開始から連続する複数個のパケットに第2タイプの位置情報が含まれてもよい。第2タイプの位置情報に係わる詳細な説明は、図17及び図24で後述する。第3タイプの位置情報は、対応するセグメント内のあらゆるアクセスユニットについての位置情報を示す第3オプション情報を含む。第3タイプの位置情報は、アクセスユニットのタイプ別位置を含むので、ランダムアクセスが可能ではないアクセスユニットではなくとも、位置が容易に分かる。第3タイプの位置情報に係わる詳細な説明は、図19及び図25で後述する。このように、異なるタイプの位置情報が使われる場合には、位置情報のタイプをシグナリングする必要がある。このために、生成部1320は、位置情報に係わるタイプ情報を位置情報に含めることができる。伝送部1330は、位置情報を伝送する。前述のように位置情報は、対応するセグメント内の所定パケットに挿入され、伝送部1330は、位置情報が挿入されたセグメントを含むメディアデータを伝送することができる。図14は、本発明の一実施形態によるデータ受信装置1400に係わるブロック図を示している。本発明の一実施形態によるデータ受信装置1400は、受信部1410、獲得部1420及び提供部1430を備える。受信部1410は、同じコンテンツを異なる品質にエンコーディングすることで生成された複数個のメディアデータのうち、少なくとも一つを受信する。複数個のメディアデータは、エンコーディングされたコンテンツを時間分割した部分である一つ以上のセグメントを含む。受信部1410は、コンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータに係わる情報を含むファイルをまず受信した後、ユーザの選択または外部環境に基づいて、複数個のメディアデータのうち一つ以上のメディアデータを選択的に受信することができる。獲得部1420は、少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を獲得する。位置情報は、自体が搭載されたセグメント内のランダムアクセスポイントについての情報だけを含むか、あるいは自体が搭載されていないセグメントのランダムアクセスポイントについての情報までいずれも含んでもよい。以下では、説明の便宜のために、位置情報自体が搭載されたセグメント内のランダムアクセスポイントについての情報だけを含むと仮定する。セグメントは、一つ以上のパケット例えば、MPEG2TSパケットまたはMPEG4ボックスから構成され、獲得部1420は、セグメント内の所定パケットにアクセスして位置情報を獲得する。獲得部1420が位置情報を獲得する方法は、位置情報のタイプによって異なることが可能であるので、獲得部1420は、まず位置情報に係わるタイプ情報を獲得する。第1タイプの位置情報の場合、獲得部1420は、セグメント内の特定パケット例えば、最初のパケットにアクセスする。獲得部1420は、アクセスしたパケット内の所定位置から例えば、private_data_bytesフィールド、ランダムアクセスが可能な次のパケットの位置を獲得する。獲得部1420は、アクセスしたパケット内の所定の位置から、ランダムアクセスが可能なその次のパケットの位置を獲得する。獲得部1420は、かような方式で、ランダムアクセスが可能なパケットに順次にアクセスし、次のランダムアクセスポイントの位置を獲得する。第2タイプの位置情報の場合、獲得部1420は、セグメント内の一つ以上の所定パケットの位置情報を獲得する。実施形態によっては、第2タイプの位置情報が、複数個の連続するパケットにまたがって含まれもする。その場合、獲得部1420は、複数個のパケットから位置情報を獲得して組み合わせる。第2タイプの位置情報が獲得されれば、当該セグメント内では、位置情報をさらに獲得する必要がない。しかし、位置情報がアップデートされたり、あるいはエラーが発生した場合に備え、アップデートされた後の特定パケットに位置情報を挿入したり、あるいは所定周期のパケットごとに位置情報を挿入したりもする。第3タイプの位置情報の場合、獲得部1420は、セグメント内の一つ以上の所定パケットの位置情報を獲得する。実施形態によっては、第3タイプの位置情報が、複数個の連続するパケットにまたがって含まれもする。その場合、獲得部1420は、複数個のパケットから位置情報を獲得して組み合わせる。第3タイプの位置情報は、位置情報がセグメント内のあらゆるアクセスユニットaccessunit例えば、Pフレーム、Bフレーム、Iフレームについての位置情報を示す第3オフセット情報を含むので、必要によっては、ランダムアクセスが不可能なアクセスユニットに選択的にアクセスすることもある。提供部1430は、位置情報を利用して受信されたメディアデータに係わるランダムアクセスを提供する。従来には、random_access_indicatorフィールドを利用してランダムアクセス機能を支援した。従って、クライアントでは、所望のランダムアクセスポイントを検出するまで、パケットを一つ一つ検索せねばならない。しかし、本願発明では、ランダムアクセス情報を特定フィールド例えば、MPEG2TSパケットのヘッダ内のprivate_data_bytesフィールドを使用して提供することによって、ランダムアクセス機能を効果的に提供することができる。図15Aは、本発明の一実施形態による第1タイプの位置情報1510に係わる一例を示している。data_field_tagフィールド1511は、位置情報1510のタイプを示す。本明細書での位置情報は、次のランダムアクセスポイントを指示する第1オフセット情報、あらゆるランダムアクセスポイントを指示する第2オフセット情報、あらゆるアクセスユニットの位置を指示する第3オフセット情報のうち1つのタイプであると仮定する。data_field_lengthフィールド1512は、フィールド長を示す。offsetフィールド1513は、16ビットから構成され、現在パケットからランダムアクセスが可能な次のパケットまでのパケット個数を示す。図15Aでは、offsetフィールド1513にパケット個数が含まれたが、次のランダムアクセスポイントを示すことができるいかなる値例えば、次のランダムアクセスポイントまでのバイト数、次のランダムアクセスポイントのPTS、DTS、メディアのglobaltime、フレーム番号が含まれてもよい。図15Bは、本発明の実施形態による第1タイプの位置情報1520についての他の例を示している。data_field_tagフィールド1521は、位置情報1520のタイプを示す。data_field_lengthフィールド1522は、フィールド長を示す。PTSフィールド1523は、TS_indexフィールド1524が示すパケットが提供するフレームのPTSを示す。一実施形態では、PTSフィールド1523が、メディアのglobaltimeを示すこともできる。TS_indexフィールド1524は、現在パケットからランダムアクセスが可能な次のパケットまでのパケット個数を示す。図16は、本発明の一実施形態による位置情報1510,1520を利用し、ランダムアクセスを提供する一例を示している。図16は、1つのセグメント内のパケットを示し、位置情報1510,1520は、第1タイプである。図16では、位置情報1510,1520がランダムアクセスが可能なパケットにのみ含まれると仮定する。また、セグメント内の最初のパケットは、ランダムアクセスが可能なパケットであると仮定する。獲得部1420は、最初のパケット内のPrivate_data_bytesフィールドにアクセスして位置情報を獲得する。最初のパケットから獲得した位置情報には、次のランダムアクセスポイントに係わるオフセット情報が含まれている。最初のパケットから順次にパケットを処理し、ユーザにコンテンツを提供していて、ユーザが特定位置へのジャンプを要請したと仮定する。ジャンプ後の再生は、必ずランダムアクセスポイントから開始されなければならないなので、獲得された位置情報から次のランダムアクセスポイントの位置を確認し、当該パケットにアクセスする。この後、アクセスしたパケットから順次にパケットを処理してデータを再生する。図17Aは、本発明の一実施形態による第2タイプの位置情報1710に係わる一例を示している。第2タイプの位置情報1710は、1つのセグメント内のあらゆるランダムアクセスポイントを指示する。位置情報1710は、1つのパケットに搭載されるが、場合によっては、連続する複数個のパケット内の特定フィールドに搭載されもする。位置情報1710が、パケット内のデータを搭載できる空間をいずれも占める場合には、当該パケットにペイロードデータがないこともある。パケットは、PIDを介してペイロードに含まれたデータを識別する。従って、PIDを利用し、当該パケットが位置情報を含むか否かを確認することができる。data_field_tagフィールド1711は、位置情報1710のタイプを示す。data_field_lengthフィールド1712は、フィールド長を示す。RAP_index_finish_flagフィールド1713は、現在のパケットで、RAP_indexデータが終わっているか否かを示す。前述のように位置情報1710は、複数個のパケットにまたがって存在し、RAP_index_finish_flagフィールド1713が、0であるならば、次のパケットに位置情報1710が含まれ、RAP_index_finish_flagフィールド1713が、1であるならば、次のパケットに位置情報1710が含まれないということを示す。PTSフィールド1714は、後述するTS_indexフィールド1715が示すパケットから始まるフレームのPTSまたはメディアのglobaltimeを示す。TS_indexフィールド1715は、それぞれのランダムアクセスポイントに係わるインデックスを示す。TS_indexフィールド1715は、ランダムアクセスポイントの位置を、パケットの個数、バイト数などを利用して示すことができる。図17Aでnは、セグメント内のランダムアクセスポイントの個数-1である。従って、位置情報1710には、PTSフィールド1714と、TS_indexフィールド1715とがn1回反復して存在する。図17Bは、本発明の一実施形態による第2タイプの位置情報1720に係わる一例を示している。第2タイプの位置情報1720は、1つのセグメント内のあらゆるランダムアクセスポイントを指示する。data_field_tagフィールド1721は、位置情報1720のタイプを示す。data_field_lengthフィールド1722は、フィールド長を示す。RAP_countフィールド1723は、セグメント内の全体ランダムアクセスポイントの個数を示す。PTSフィールド1724は、後述するTS_indexフィールド1725が示すパケットから始まるフレームのPTSまたはメディアのglobaltimeを示す。TS_indexフィールド1725は、現在パケットからランダムアクセスが可能な次のパケットの開始までのパケットの個数を示す。図17Cは、本発明の一実施形態による位置情報に係わる他の例を示している。図17Cは、メディアデータを構成するセグメントについてのインデックスである。図17Cでは、本願発明による位置情報をセグメントインデックスに挿入し、セグメントインデックスを、private_data_fieldを介して伝送する。図17Cでは、本願発明の位置情報と関連していないフィールドについての説明は省略する。segment_contains_rapフィールド1731は、セグメント内に少なくとも1つのランダムアクセスポイントが存在するか否かを示す。segment_starts_with_rapフィールド1732は、セグメントの最も近いアクセスポイントが、ランダムアクセスポイントであるか否かを示す。すなわち、セグメントの開始が、ランダムアクセスポイントであるか否かを示す。number_entriesフィールド1733は、ランダムアクセスポイントの個数を示す。directionフィールド1734は、現在位置からランダムアクセスポイントが存在する方向を示す例えば、以前のランダムアクセスポイント、またはそれ以後のランダムアクセスポイント。referencetypeフィールド1735は、ランダムアクセスポイントをインデクシングするときに基準になるパケットのタイプを決定する。次の表1は、referencetypeフィールド1735による基準パケットのタイプに係わる一例である。offsetflagsフィールド1736は、オフセット値のタイプを示す。次の表2は、offsetflagsフィールド1736値によるオフセット値のタイプに係わる一例である。offsetflagsフィールド1736の値が00であり、オフセットを示すフィールドの値が3であるならば、オフセット値は、83=24ビットになる。rap_size_present_flagフィールド1737は、セグメントエントリー内にランダムアクセスの位置を示す情報が含まれているか否かを示す。rap_sizeフィールド1738は、ランダムアクセスユニットを完全に出コーディングするために読み取らねばならない連続的な伝送ストリームパケットの個数を示す。すなわち、現在パケットから次のランダムアクセスポイントまでに存在するパケットの個数を示す。このとき、rap_sizeフィールド1738が示すパケットの個数は、アクセスユニットの最初のパケットと最後のパケットとの間に存在するPIDが異なるあらゆるパケットを含む。図18は、本発明の一実施形態による位置情報1710,1720を利用してランダムアクセスを提供する一例を示している。獲得部1420は、最初のパケットまたは、連続する一つ以上のパケット内のPrivate_data_bytesフィールドにアクセスし、位置情報1510,1520を獲得する。最初のパケットから獲得した位置情報には、セグメント内のあらゆるランダムアクセスポイントに係わるオフセット情報が含まれている。最初のパケットから順次にパケットを処理し、ユーザにデータを再生していて、ユーザが特定位置へのジャンプを要請したと仮定する。獲得した位置情報1510,1520には、セグメント内のあらゆるアクセスポイントの位置が含まれているので、ユーザが要請した位置後に存在するランダムアクセスポイントにアクセスし、アクセスしたパケットから順次にパケットを処理してデータを再生する。図19は、本発明の一実施形態による第3タイプの位置情報1910に係わる一例を示している。data_field_tagフィールド1911は、位置情報1910のタイプを示す。data_field_lengthフィールド1912は、フィールド長を示す。AU_index_finish_flagフィールド1913は、AU_indexデータが、現在パケットで終わっているか否かを示す。前述のように位置情報1910は、複数個のパケットにまたがって存在し、AU_index_finish_flagフィールド1913が0であるならば、次のパケットに位置情報1910が含まれ、AU_index_finish_flagフィールド1913が1であるならば、次のパケットに位置情報1910が含まれないということを示す。TS_indexフィールド1914は、アクセスユニットそれぞれに係わるパケットの位置を示す。実施形態によっては、TS_indexフィールド1914は、アクセスユニットそれぞれに係わるAU_informationフィールドの位置を示すこともある。AU_coding_type_informationフィールド1915は、アクセスユニットのタイプを示す。一例として、AU_coding_type_informationフィールド1915は、アクセスユニットが、Bフレーム、Pフレーム、Iフレーム、IDRフレームのうち一つであることを示すことができる。図20は、本発明の一実施形態による第1タイプの位置情報2010についての他の例を示している。図20の位置情報2010は、一部フィールドを除外すれば、図15Aの位置情報1510と同一であるので、異なる一部フィールドについてのみ説明する。dependency_flagまたはweighting_flagフィールド2011は、dependencyフィールド2013が存在するか否かを示す。dependency_flagまたはweighting_flagフィールド2011が1に設定されれば、対応するランダムアクセスポイントが示すパケットは、依存性を有する。すなわち、当該パケットは、一つ以上の他のパケットのデータと共に処理されて再生される。viewing_flagフィールド2012は、viewingフィールド2014フィールドが存在するか否かを示す。viewing_flagフィールド2012が1に設定されれば、対応するランダムアクセスポイントは、三次元映像を提供する。dependencyフィールド2013は、ランダムアクセスポイントに該当するパケットの依存度を示す。例えば、基本階層basislayerと強化階層enhancementlayerとから構成されるスケーラブル映像成分を仮定する。基本階層は、強化階層なしにもデコーディングされるために、依存度は、0に設定される。しかし、強化階層をデコーディングするためには、基本階層及び下位階層のデコーディングが必須である。これは、スケーラブル階層が増大することにより、依存度が上昇するということを意味する。従って、強化階層の依存度は、1以上に設定される。依存度と同じ概念として、加重値weightingは、依存度と反対に作用する。viewingフィールド2014は、多視点コーディングmultiviewcodingによってエンコーディングされた映像例えば、自由視点TV、多視点三次元TVまたはステレオスコーピック2種の視点の映像の視点レベルを示す。ステレオスコーピックの場合、左視点映像を提供するパケットに対応するviewingフィールド2014は、0に設定され、右視点映像を提供するパケットに対応するviewingフィールド2014は、1に設定される。図21は、本発明の一実施形態によるスケーラブル映像データを示している。図21では、n1個の映像データを提供する。baselayer階層に該当する映像データは、単独再生が可能な低画質の映像データである。ユーザが一ステップ高い画質または音質の映像データを所望する場合、enhancementlayer1階層とbaselayer階層とに該当する映像データを処理して再生する。ただし、enhancementlayer1階層に該当する映像データは、単独再生が不可能である。同様に、ユーザが最も高画質の映像データを所望する場合、baselayer階層からenhancementlayern階層に該当する映像データをいずれも処理して再生する。上位階層に位置した映像データであるほど、共に再生せねばならない映像データの個数が多くなるので、依存度が上昇する。一方、重要度は低下するので、加重値は減少する。図22は、本発明の一実施形態による位置情報2210,2220を利用し、ランダムアクセスを提供する一例を示している。図22は、複数個の階層から構成されたスケーラブル映像データに係わるものである。獲得部1420は、基本階層に該当するランダムアクセスが可能なパケット2201にアクセスし、パケット2201内のPrivate_data_bytesフィールドから、位置情報2210を獲得する。位置情報2210内のdependency_flagまたはweighting_flagフィールドを介して、当該パケット2201がスケーラブル映像データを提供するものであることを確認することができる。また、位置情報2210内のdependencyフィールドを介して、当該パケット2201の階層を確認することができる。パケット2201のdependencyフィールドは、0の値を有するので、パケット2201は、基本階層に該当する。獲得部1420は、offsetフィールドを参考にして、上位階層に該当するパケット2202にアクセスし、パケット2202内のPrivate_data_bytesフィールドから、位置情報2220を獲得する。図22で、パケット2202のdependencyフィールドは、1の値を有するので、パケット2202は、強化階層に該当する。図23は、本発明の一実施形態による位置情報2310,2320を利用し、ランダムアクセスを提供する一例を示す。図23では、左視点映像データと右視点映像データとから構成されたステレオスコーピック映像データに係わるものである。獲得部1420は、左視点映像データに該当するランダムアクセスが可能なパケット2301にアクセスし、パケット2301内のPrivate_data_bytesフィールドから、位置情報2310を獲得する。位置情報2310内のviewing_flagフィールドを介して、当該パケット2301が三次元映像を提供するものであることを確認することができる。また、位置情報2310内のviewingフィールドを介して、当該パケット2301が提供する映像データの視点を確認することができる。パケット2301のdependencyフィールドは、0の値を有するので、パケット2301は、左視点映像データである。獲得部1420は、offsetフィールドを介して、ランダムアクセスが可能な右視点映像データに該当するパケット2302にアクセスし、パケット2302内のPrivate_data_bytesフィールドから、位置情報2320を獲得する。図23で、パケット2302のviewingフィールドは、1の値を有するので、パケット2302は、右視点映像データである。図24は、本発明の一実施形態による第2タイプの位置情報2410についての他の例を示している。図24の位置情報2410は、一部フィールドを除外すれば、図17Aの位置情報1710と同一であるので、以下、説明を省略する。図25は、本発明の一実施形態による第3タイプの位置情報2510についての他の例を示している。図25の位置情報2510は、一部フィールドを除外すれば、図19の位置情報1910と同一であるので、以下、説明を省略する。図26Aは、本発明の一実施形態による位置情報を含むMPEGTStransportstreamの構造に係わる一例である。Adaptationfield内に、privatedataを入力するフィールドがprivate-data-byteとして存在する。データ伝送装置1300は、private-data-byteの長さを定義した後、transport-private-data-lengthに入力する。データ伝送装置1300は、transport-private-data-lengthほどprivate-data-byteに記録する。private-data-byteは、unsignedinteger形態の数値である。private-data-byteの値は、現在あるTSパケットで、次のIフレームを有するTSパケットの開始位置に係わるオフセット値を意味する。TSにいくつかのIフレームが存在する場合、それぞれのIフレームが始まるところに、Adaptationfieldが存在する。図26Bは、本発明の一実施形態による位置情報を含むMPEGTStransportstreamの構造についての他の例である。MPEG-2TSパケットのヘッダには、adaptation_fieldが存在する。adaptation_fieldには、adaptation_field_extensionフィールドが存在し、adaptation_field_extensionフィールドには、ユーザが任意に定義して使用することができるreserved領域が存在する。図26Cでは、adaptation_field_extensionフィールドに、本願発明による位置情報が含まれるか否かを示すフラグと、次のランダムアクセスポイントの位置を示すバイト値が含まれたフィールドとを挿入する。図26Bでは、説明の便宜のために、位置情報と関連したフィールドについてのみ説明する。adaptation_field_extension_flagフィールド2611は、adaptation_field内に、adaptation_field_extensionフィールドが存在するか否かを示す。random_access_point_flagフィールド2612は、adaptation_field_extensionフィールド内に、ランダムアクセスポイントの位置を示す情報が含まれているか否かを示す。random_access_point_countフィールド2613は、TSパケットで提供するランダムアクセスポイントの個数を示す。random_access_point_countフィールド2613が1の値を有せば、TSパケット内には、1つのランダムアクセスポイントの位置だけ含まれるということを意味する。random_access_point_countフィールド2613が1の値を有する場合のパケットの構造に係わる一例は、図32Aに図示されている。図32Aを参考にすれば、TSパケットには、次のランダムアクセスポイントの位置だけ含まれ、次のランダムアクセスポイントが始まるTSパケットで、その次のランダムアクセスポイントの位置をさらに獲得せねばならない。random_access_point_countフィールド2613が、2以上の値を有せば、TSパケット内には、複数のランダムアクセスポイントの位置が含まれるということを意味する。random_access_point_countフィールド2613が、2以上の値を有する場合のパケットの構造に係わる一例は、図32Bに図示されている。図32Bを参考にすれば、TSパケットには、複数個のランダムアクセスポイントの位置が含まれている。従って、1つのTSパケットを処理し、所定区間内に存在するランダムアクセスポイントの位置がいずれも分かる。random_access_point_lengthフィールド2614は、現在TSパケットから次のランダムアクセスポイントが始まるTSパケットまでのバイト数を示す。データ受信装置は、TSパケットのヘッダをパージングし、adaptation_field_extensionフィールドに含まれた情報を獲得し、random_access_indicatorフィールドが存在するか否かを判断する。random_access_indicatorフィールドが存在するならば、random_access_point_countフィールド2613と、random_access_point_lengthフィールド2614とを利用することによって、ランダムアクセスポイントの位置を容易に把握することができる。図26Bでは、adaptation_field_extensionフィールドに、本願発明による位置情報を挿入することによって、TSの構造を大きく変化させずとも、ランダムアクセスポイントの位置を効率的に提供する。図26Cは、本発明の一実施形態による位置情報を含むTS_description_sectionに係わる一例である。MPEG2では、プログラム情報のようなシグナリング情報を伝達するために、多様なセクションを定義している。次の表3は、MPEG2で定義するセクションに係わる一例である。MPEGでは、PAT、PMTのような多様な形態のセクションを定義しており、それぞれのセクションには、固有のPID値が割り当てられる。また、それぞれのセクションは、table_id値が指定される。次の表4は、table_id値によるセッションの種類である。表3及び表4を参考にすれば、table_idの値が0x00であるセクションは、PATであり、PIDは、0x00である。また、table_idの値が0x03であるセクションは、TS_description_sectionであり、PIDが0x02である。TS_description_sectionは、多様な記述子デスクリプタを提供する。図26Cは、TS_description_sectionであるから、table_idフィールド2631の値が0x03がなる。descriptorフィールド2632は、本願発明による位置情報が含まれる。descriptorフィールド2632に含まれる位置情報に係わる一例は、図26Dで述べる。図26Dは、本発明の一実施形態によるTS_description_sectionに挿入された位置情報を含むTSパケット2640に係わる一例である。TSパケット2640は、ヘッダ2641とペイロード領域2642とから構成される。ヘッダ2641には、ペイロード領域2642に含まれたデータを識別するためのPIDフィールドが存在する。TSパケット2640のペイロード領域2642には、ランダムアクセスポイントの位置情報を含むTS_description_sectionが搭載される。従って、TSパケット2640のPIDは、0x02になり、table_idは、0x03になるのである。ランダムアクセスポイントの位置情報は、descriptor_tagフィールド2643、descriptor_lengthフィールド2644、random_access_point_countフィールド2645及びrandom_access_point_offsetフィールド2646を含んでもよい。descriptor_tagフィールド2643は、8ビットのフィールドであり、記述子を区分する識別子である。descriptor_lengthフィールド2644は、8ビットのフィールドであり、記述子のバイト個数を示す。random_access_point_countフィールド2645は、TSパケットで提供するランダムアクセスポイントの個数を示す。random_access_point_lengthフィールド2646フィールドは、ランダムアクセスポイントの位置を示す。図26Eは、MPEG-2標準によるTS_program_map_section以下、PMT構造に係わる一例である。PMTは、stream_typeフィールド2651とelementary_PIDフィールド2652とのマッピング情報を含む。すなわち、PMTは、特定データタイプに係わる識別情報を提供する。MPEG2標準では、stream_typeフィールド2651の値が0x80~0xFFである場合をユーザが任意に使用することができるreserved領域として提供している。従って、0x80~0xFFのうち一つが、本願発明の位置情報を示すものであると設定できる。例えば、stream_typeフィールド2651値が0x80であるならば、当該ストリームが、本願発明の位置情報を含むと仮定することができる。同時に、本願発明の位置情報を含むストリームのelementary_PIDをreservedされた値のうち一つ例えば、1000に設定する。もし受信機で、ランダムアクセスポイントについての位置情報が含まれたストリームを獲得しようとすれば、elementary_PID2652が1000であるパケットを獲得する。図26Fは、本発明の一実施形態によるprivate_sectionに挿入された位置情報を含むTSパケット2660に係わる一例である。TSパケット2660は、ヘッダ2661とペイロード領域2662とから構成される。ヘッダ2661は、ペイロード領域2662に含まれたデータを識別するためのPIDフィールドが存在する。TSパケット2660のPIDが1000であるから、ペイロード2662には、ランダムアクセスポイントについての位置情報が含まれるということが分かる。本発明の一実施形態では、private_sectionを利用し、ランダムアクセスポイントについての情報を伝達すると仮定したが、実施形態によっては、既存のprivate_sectionではない新たなsectionを設定したり、あるいはTSパケットのペイロードなどに割り当てられたPIDを利用し、ランダムアクセスポイントについての情報を伝送することができるということは、本発明が属する技術分野で当業者には自明である。図26Fで、TSパケット2660のペイロード領域2662には、private_sectionが含まれる。MPEG-2TSでは、ユーザがセクションを新たに定義して使用することができるように、table_idが0x40~0xFEである場合をreserved領域として提供しており、table_idが0x40であるセクションを、private_sectionと定義し、本願発明による位置情報を搭載する。private_sectionは、table_idフィールド2663及びprivate_data_typeフィールド2664を含む。table_idフィールド2663は、セクションのタイプを示す。private_data_typeフィールド2664は、本願発明による位置情報が含まれる。本願発明による位置情報は、random_access_point_countフィールド2665及びrandom_access_point_offsetフィールド2666を含むことができ、これについての説明は、図26Dと同一であるので省略する。図27は、本発明の一実施形態によるデータ受信装置で、ユーザがトリックプレイを要請した場合のサービス提供方法に係わるフローチャートを示している。図27では、Iフレームを順次に再生することによって、トリックプレイを提供すると仮定する。ステップ2710で、ユーザからトリックプレイの要請を受信する。ステップ2720で、パケット内にadaptationfieldが存在するか否かを判断する。パケット内にadaptationfieldが存在すれば、ステップ2730に進み、そうではなければ、次のパケットにadaptationfieldが存在するか否かを判断する。もしクライアントが、位置情報を含むパケットの位置を知っている場合例えば、セグメント内の最初のパケットとして約束した場合には、ステップ2720を遂行しない。ステップ2730で、adaptationfield内のprivate-data-byteから、位置情報を獲得することによって、Iフレームの位置を確認する。第1タイプの位置情報が獲得された場合には、次のIフレームの位置だけを獲得できるのであり、第2タイプまたは第3タイプの位置情報が獲得された場合には、セグメント内のあらゆるIフレームの位置を確認することができる。以下、第1タイプの位置情報が獲得されたと仮定し、次のIフレームオフセットを抽出する過程について簡略に説明する。例えば、オフセット値が2462である場合、2462の値を16ビット値に変更した0x99Eを計算する。unsignedintegerのサイズが4バイトであるから、transport-private-data-length値を4として登録する。0x99Eを4バイト整数である0x000x000x090x9Eに変換する。private-data-byteに変換された値を入力する。反対に、private-data-byteからオフセット値を抽出する方法で、private-data-byteがpdb[4]と宣言された場合、オフセットは、intpdb[3]<<24|pdb[2]<<16|pdb[1]<<8|pdb[0]と計算される。ステップ2740で、次のIフレームオフセットほどTSファイルを分離する。ステップ2750で、セグメント内のファイルの最後であるか否かを判断する。セグメントファイルの最後ではない場合、ステップ2730に移動し、再び次のIフレームを抽出する。セグメントファイルの最後である場合、ステップ2720に移動し、次のセグメントについて同じ過程を遂行する。図28は、本発明の他の実施形態によるMPEGTStransportstreamで、Iフレームを見い出すためのTSパケットの構造を図示している。Adaptationfieldは、TSヘッダの一部分であり、TS関連追加情報を入力する選択的なフィールドである。Adaptationfieldは、さまざまなパラメータを有し、そのうち、ユーザが任意に使用することができるprivatedatafieldが存在する。transport_private_data_lengthは、Adaptationfield内に存在するprivatedatafieldのサイズ知らせるパラメータである。private_data_byteは、ユーザが任意に定義したデータを保存する空間である。クライアントは、transport_private_data_lengthとprivate_data_byteとを利用し、MPEGTSで、次のIフレームの開始位置を計算することができる。図29は、本発明の一実施形態による、MPEGTSで、Iフレームを探すためのMP4ファイル構造を図示している。MP4ファイル構造では、エンコーディングされたデータを、時間に基づいて分割して生成されたセグメントが、一つ以上のmoofボックス及びmdatボックスを含む。moofボックスは、セグメントに係わるメタデータが含まれ、mdatボックスは、コンテンツを提供するペイロードデータが含まれる。Iフレームの位置情報は、MP4ファイルのTrakボックスやTrafボックス内のmoofボックスを介して獲得することができる。図30は、本発明の一実施形態によるデータ伝送方法に係わるフローチャートを示している。ステップ3010では、同じコンテンツを異なる品質にエンコーディングすることで生成される少なくとも1つのセグメントを含む複数個のメディアデータを獲得する。ステップ3020では、少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成する。ステップ3030では、位置情報を伝送する。図31は、本発明の一実施形態によるデータ受信方法に係わるフローチャートを示している。ステップ3110では、コンテンツを異なる品質にエンコーディングすることで生成されるそれぞれ少なくとも1つのセグメントを含む複数個のメディアデータのうち少なくとも一つを受信する。ステップ3120では、少なくとも1つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を、受信されたメディアデータから獲得する。ステップ3130では、位置情報を利用して受信されたメディアデータに係わるランダムアクセスを提供する。一方、前述の本発明の実施形態は、コンピュータで実行することができるプログラムで作成可能であり、コンピュータで読み取り可能な記録媒体を利用し、前記プログラムを動作させる汎用デジタルコンピュータで具現される。前記コンピュータで読み取り可能な記録媒体は、磁気記録媒体例えば、ROMreadonlymemory、フロッピー登録商標ディスク、ハードディスクなど、光学記録媒体例えば、CD-ROM、DVDなど及びキャリアウェーブ例えば、インターネットを介した伝送のような記録媒体を含む。以上、本発明についてその望ましい実施形態を中心に説明した。本発明が属する技術分野で当業者であるならば、本発明が本発明の本質的な特性から外れない範囲で変更された形態で具現されるということを理解することができる。従って、開示された実施形態は、限定的な観点ではなく、説明的な観点から考慮されなければならないのである。本発明の範囲は、前述の説明ではなく、特許請求の範囲に示されており、それと同等な範囲内にあるあらゆる差異点は、本発明に含まれたものであると解釈されなければならない。100ストリーミングシステム110エンコーディング装置120サーバ130クライアント140ネットワーク"