特許 6131050 データ伝送方法及び装置、並びにデータ受信方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6131050

(24)【登録日】2017年4月21日

(45)【発行日】2017年5月17日

(54)【発明の名称】データ伝送方法及び装置、並びにデータ受信方法及び装置

(51)【国際特許分類】

   H04N 7/173 20110101AFI20170508BHJP

【ＦＩ】

   H04N7/173 630

   H04N7/173 610B

【請求項の数】13

【全頁数】49

(21)【出願番号】特願2012-553824(P2012-553824)

(86)(22)【出願日】2011年2月23日

(65)【公表番号】特表2013-520861(P2013-520861A)

(43)【公表日】2013年6月6日

(86)【国際出願番号】KR2011001268

(87)【国際公開番号】WO2011105811

(87)【国際公開日】20110901

【審査請求日】2013年11月20日

【審判番号】不服2015-13911(P2015-13911/J1)

【審判請求日】2015年7月23日

(31)【優先権主張番号】10-2010-0103727

(32)【優先日】2010年10月22日

(33)【優先権主張国】KR

(31)【優先権主張番号】61/392,645

(32)【優先日】2010年10月13日

(33)【優先権主張国】US

(31)【優先権主張番号】61/390,170

(32)【優先日】2010年10月5日

(33)【優先権主張国】US

(31)【優先権主張番号】61/380,461

(32)【優先日】2010年9月7日

(33)【優先権主張国】US

(31)【優先権主張番号】61/370,970

(32)【優先日】2010年8月5日

(33)【優先権主張国】US

(31)【優先権主張番号】61/323,536

(32)【優先日】2010年4月13日

(33)【優先権主張国】US

(31)【優先権主張番号】61/314,233

(32)【優先日】2010年3月16日

(33)【優先権主張国】US

(31)【優先権主張番号】61/310,104

(32)【優先日】2010年3月3日

(33)【優先権主張国】US

(31)【優先権主張番号】61/307,093

(32)【優先日】2010年2月23日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100154922

【弁理士】

【氏名又は名称】崔 允辰

(74)【代理人】

【識別番号】100140534

【弁理士】

【氏名又は名称】木内 敬二

(72)【発明者】

【氏名】オ−ホーン・クウォン

(72)【発明者】

【氏名】スン−バル・キム

(72)【発明者】

【氏名】ホ−ジン・ハ

(72)【発明者】

【氏名】グアンファ・チャン

(72)【発明者】

【氏名】ヒュン−タク・チェ

(72)【発明者】

【氏名】ジ−エウン・クム

【合議体】

【審判長】 渡邊 聡

【審判官】 冨田 高史

【審判官】 小池 正彦

(56)【参考文献】

【文献】 国際公開第２００９／１５３８４４（ＷＯ，Ａ２）

【文献】 特開２００９−１５９６２５（ＪＰ，Ａ）

【文献】 特開平６−２５２８７６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

H04N7/10

H04N7/14-7/173,640@Z

H04N7/20-7/56

H04N21/00-21/858

(57)【特許請求の範囲】

【請求項1】

コンテンツを異なる品質にエンコーディングすることで生成される複数のセグメントを含む複数個のメディアデータのうち少なくとも一つを受信するステップであって、前記セグメントは、前記メディアデータを時間に基づき分割した各部分を示す、ステップと、
前記複数のセグメントそれぞれのランダムアクセスが可能なポイントを示す情報を獲得するステップであって、
前記情報は、前記複数のセグメントのうちの第１のセグメントに含まれ、前記情報は、前記複数のセグメントのうちの前記第１のセグメント以後のセグメントについてのランダムアクセスが可能なポイントを示す位置情報を含む、ステップと、
前記情報に基づき前記受信されたメディアデータ内の少なくとも１つのセグメントにランダムアクセスするステップとを
含み、
前記情報は、前記複数のセグメントに含まれたアクセスユニットに対応する少なくとも一つのフレームをインデクシングする情報を含み、
前記情報は、前記第１のセグメント以後のセグメントでランダムアクセスが可能なあらゆるパケットの位置を示す第２オフセット情報を含むことを特徴とするデータ受信方法。

【請求項2】

前記情報は、
前記第１のセグメント以後のセグメントでランダムアクセスが可能な次のパケットの位置を示す第１オフセット情報を含むことを特徴とする請求項１に記載のデータ受信方法。

【請求項3】

コンテンツを異なる品質にエンコーディングすることで生成される複数のセグメントを含む複数個のメディアデータのうち少なくとも一つを受信するステップであって、前記セグメントは、前記メディアデータを時間に基づき分割した各部分を示す、ステップと、
前記複数のセグメントそれぞれのランダムアクセスが可能なポイントを示す情報を獲得するステップであって、
前記情報は、前記複数のセグメントのうちの第１のセグメントに含まれ、前記情報は、前記複数のセグメントのうちの前記第１のセグメント以後のセグメントについてのランダムアクセスが可能なポイントを示す位置情報を含む、ステップと、
前記情報に基づき前記受信されたメディアデータ内の少なくとも１つのセグメントにランダムアクセスするステップとを
含み、
前記情報は、前記複数のセグメントに含まれたアクセスユニットに対応する少なくとも一つのフレームをインデクシングする情報を含み、
前記情報は、前記第１のセグメント以後のセグメントのあらゆるアクセスユニットについての情報を示す第３オフセット情報を含むことを特徴とするデータ受信方法。

【請求項4】

前記情報は、
前記アクセスユニットが示す映像フレームのタイプを示す映像タイプ情報をさらに含むことを特徴とする請求項３に記載のデータ受信方法。

【請求項5】

前記情報は、前記情報に対応するタイプ情報をさらに含み、
前記タイプ情報は、前記情報が前記受信されたメディアデータ内でランダムアクセスが可能なポイントを示す方式によって分類されることを特徴とする請求項１または３に記載のデータ受信方法。

【請求項6】

コンテンツを異なる品質にエンコーディングすることで生成される複数のセグメントを含む複数個のメディアデータのうち少なくとも一つを受信するステップであって、前記セグメントは、前記メディアデータを時間に基づき分割した各部分を示す、ステップと、
前記複数のセグメントそれぞれのランダムアクセスが可能なポイントを示す情報を獲得するステップであって、
前記情報は、前記複数のセグメントのうちの第１のセグメントに含まれ、前記情報は、前記複数のセグメントのうちの前記第１のセグメント以後のセグメントについてのランダムアクセスが可能なポイントを示す位置情報を含む、ステップと、
前記情報に基づき前記受信されたメディアデータ内の少なくとも１つのセグメントにランダムアクセスするステップとを
含み、
前記情報は、前記複数のセグメントに含まれたアクセスユニットに対応する少なくとも一つのフレームをインデクシングする情報を含み、
前記情報は、前記第１のセグメント以後のセグメントでランダムアクセスが可能なパケットが、他のパケットと共に再生されるか否かを示す依存情報をさらに含むことを特徴とするデータ受信方法。

【請求項7】

前記情報は、
前記共に再生されるパケットの個数を示す依存度情報をさらに含むことを特徴とする請求項６に記載のデータ受信方法。

【請求項8】

前記ランダムアクセスするステップは、
前記情報に基づいて、前記共に再生されるパケットを獲得するステップを有することを特徴とする請求項７に記載のデータ受信方法。

【請求項9】

前記情報は、
前記第１のセグメント以後のセグメントでランダムアクセスが可能なパケットが、三次元映像を提供するのに使われるか否かを示す三次元映像情報をさらに含むことを特徴とする請求項１、３、および６のいずれか一項に記載のデータ受信方法。

【請求項10】

前記情報は、
前記ランダムアクセスが可能なパケットが提供する映像フレームの視点を示す視点情報をさらに含むことを特徴とする請求項８に記載のデータ受信方法。

【請求項11】

前記情報は、
前記情報が複数個のパケットにまたがって存在する場合、現在パケットが、前記情報を含む最後のパケットであるか否かを示す終了情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。

【請求項12】

データを受信する装置において、
コンテンツを異なる品質にエンコーディングすることで生成される複数のセグメントを含む複数個のメディアデータのうち少なくとも一つを受信する受信部であって、前記セグメントは、前記メディアデータを時間に基づき分割した各部分を示す、受信部と、
前記複数のセグメントそれぞれのランダムアクセスが可能なポイントを示す情報を獲得する獲得部と、
前記情報に基づいて、前記受信されたメディアデータ内の少なくとも１つのセグメントにランダムアクセスする提供部とを備え、
前記情報は、前記複数のセグメントのうちの第１のセグメントに含まれ、前記情報は、前記複数のセグメントのうちの前記第１のセグメント以後のセグメントについてのランダムアクセスが可能なポイントを示す位置情報を含み、
前記情報は、前記複数のセグメントに含まれたアクセスユニットに対応する少なくとも一つのフレームをインデクシングする情報を含み、
前記情報は、前記第１のセグメント以後のセグメントでランダムアクセスが可能なあらゆるパケットの位置を示す第２オフセット情報を含むことを特徴とするデータ受信装置。

【請求項13】

データ受信方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体であって、
前記方法は、コンテンツを異なる品質にエンコーディングすることで生成される複数のセグメントを含む複数個のメディアデータのうち少なくとも一つを受信するステップであって、前記セグメントは、前記メディアデータを時間に基づき分割した各部分を示す、ステップと、
前記複数のセグメントそれぞれのランダムアクセスが可能なポイントを示す情報を獲得するステップであって、
前記情報は、前記複数のセグメントのうちの第１のセグメントに含まれ、前記情報は、前記複数のセグメントのうちの前記第１のセグメント以後のセグメントについてのランダムアクセスが可能なポイントを示す位置情報を含む、ステップと、
前記情報に基づき前記受信されたメディアデータ内の少なくとも１つのセグメントにランダムアクセスするステップとを
含み、
前記情報は、前記複数のセグメントに含まれたアクセスユニットに対応する少なくとも一つのフレームをインデクシングする情報を含み、
前記情報は、前記第１のセグメント以後のセグメントでランダムアクセスが可能なあらゆるパケットの位置を示す第２オフセット情報を含むことを特徴とする記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、データの伝送／受信の方法及びその装置に係り、特に、メディアデータに含まれたセグメント内のランダムアクセスが可能なポイントを示す位置情報を利用し、ランダムアクセス機能を提供するデータ伝送／受信の方法及びその装置に関する。

【背景技術】

【0002】

ネットワークを介してメディアデータを伝送する方式には、ダウンロード方式と、ストリーミング方式とがある。ストリーミング方式は、サーバがリアルタイムでメディアデータを伝送し、クライアントは、受信されたメディアデータをリアルタイムで再生する方式である。

【0003】

クライアントは、メディアデータを順次に再生することが一般的であるが、ユーザがトリックプレイを要請する、あるいは特定区間へのジャンプを要請すれば、メディアデータを順次に再生することができない。メディアデータが順次に提供されない場合には、Ｉフレームのように、他のデータを参照しない基準データからデータを再生せねばならない。従来では、パケットを一つずつ順次に検索し、Ｉフレームの開始に該当するパケットを検索した。

【発明の概要】

【発明が解決しようとする課題】

【0004】

前記の問題点を解決するための本発明の目的は、メディアデータ内に含まれるセグメント内のランダムアクセスが可能なポイントを示す位置情報を伝送または受信することによって、ランダムアクセス機能を効率的に提供するデータ伝送／受信の方法及びその装置を提供することである。

【課題を解決するための手段】

【0005】

例示的な実施形態の一態様によれば、データ受信の方法が提供される。前記方法は、異なる品質を有するようにコンテンツをエンコードすることによって生成されるそれぞれ少なくとも１つのセグメントを有する複数のメディアデータのうち少なくとも１つを受信するステップと、ステップ前記少なくとも１つのセグメントそれぞれのランダムアクセスが可能な地点を示す位置情報を獲得するステップと、前記位置情報を利用し、前記受信したメディアデータに対するランダムアクセスを提供するステップと、を有する。

【0006】

前記獲得するステップは、前記少なくとも１つのセグメントそれぞれに含まれた少なくとも１つのパケットから、前記少なくとも１つのセグメントそれぞれに対応する位置情報を獲得するステップを含んでもよい。

【0007】

前記位置情報は、前記位置情報に対応するセグメント内に含まれるランダムアクセスが可能な次のパケットの位置を示す第１オフセット情報を含んでもよい。

【0008】

前記位置情報は、前記位置情報に対応するセグメント内に含まれるランダムアクセスが可能なあらゆるパケットの位置を示す第２オフセット情報を含んでもよい。

【0009】

前記位置情報は、前記位置情報に対応するセグメント内のあらゆるアクセスユニット（access unit）についての位置情報を示す第３オフセット情報を含んでもよい。

【0010】

前記位置情報は、前記アクセスユニットが示す映像フレームのタイプを示す映像タイプ情報をさらに含んでもよい。

【0011】

前記位置情報は、前記位置情報がランダムアクセスが可能なポイントを示す方式によって分類された、前記位置情報に係わるタイプ情報をさらに含んでもよい。

【0012】

前記位置情報は、前記位置情報に対応するセグメント内のランダムアクセスが可能なパケットが、他のパケットと共に再生されなければならないか否かを示す依存（dependency）情報をさらに含んでもよい。

【0013】

前記位置情報は、前記共に再生されなければならないパケットの個数を示す依存度情報をさらに含んでもよい。

【0014】

前記ランダムアクセスを提供するステップは、前記位置情報に基づいて、前記共に再生されなければならないパケットを獲得するステップを含んでもよい。

【0015】

前記位置情報は、前記位置情報に対応するセグメント内のランダムアクセスが可能なパケットが、三次元映像を提供するのに使われるか否かを示す三次元映像情報をさらに含んでもよい。

【0016】

前記位置情報は、前記ランダムアクセスが可能なパケットが提供する映像フレームの視点を示す視点情報をさらに含んでもよい。

【0017】

前記位置情報は、前記位置情報が複数個のパケットにまたがって存在する場合、現在パケットが、前記位置情報を含む最後のパケットであるか否かを示す終了情報をさらに含んでもよい。

【0018】

前記少なくとも１つのパケットは、ＭＰＥＧ ２標準によって符号化され、前記位置情報は、前記少なくとも１つのパケットの「private＿data＿bytes」フィールドのうち少なくとも１つの位置情報から獲得される。

【0019】

前記少なくとも１つのパケットは、ＭＰＥＧ ４標準によって符号化され、前記位置情報は、ｍｏｏｖボックス及びｍｏｏｆボックスのうち少なくとも一つから獲得される。

【0020】

例示的な実施形態の一態様によれば、データ送信の方法が提供される。前記方法は、異なる品質を有するようにコンテンツをエンコーディングすることで生成されるそれぞれ少なくとも１つのセグメントを有する複数のメディアデータを獲得するステップと、前記少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成するステップと、前記位置情報を伝送するステップと、を含む。

【0021】

例示的な実施形態の他の態様によれば、データ受信装置が提供される。前記装置は、異なる品質を有するようにコンテンツをエンコードすることによって生成されるそれぞれ少なくとも１つのセグメントを有する複数のメディアデータのうち少なくとも１つを受信する受信部と、前記少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を、前記受信されたメディアデータから獲得する獲得部と、前記位置情報を利用し、前記受信されたメディアデータに対するランダムアクセスを提供する提供部とを備える。

【0022】

例示的な実施形態の他の態様によれば、データ伝送装置が提供される。前記装置は、異なる品質を持つようにコンテンツをエンコーディングすることで生成されるそれぞれ少なくとも１つのセグメントを有する複数のメディアデータを獲得する獲得部と、前記少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成する生成部と、前記位置情報を伝送する伝送部とを備える。

【図面の簡単な説明】

【0023】

【図1】本発明の一実施形態によるストリーミング・システムを図示する図面である。

【図2A】本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。

【図2B】本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。

【図3】本発明の一実施形態によるコンテンツに係わる情報を含むファイルのスキーマ（schema）を図示する図面である。

【図4A】本発明の一実施形態による複数のメディアデータを定義するための情報を図示する図面である。

【図4B】本発明の一実施形態によるメディアデータのヘッダに係わる情報を図示する図面である。

【図4C】本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも１つの部分に係わる情報を含む図面である。

【図5A】本発明の他の実施形態によるストリーミング方法を説明するためのフローチャートである。

【図5B】本発明の他の実施形態によるストリーミング方法を説明するためのフローチャートである。

【図6】本発明の他の実施形態によるコンテンツに係わる情報を含むファイルのスキーマを図示する図面である。

【図7】本発明の他の実施形態によるコンテンツに係わる情報を図示する図面である。

【図8A】本発明の一実施形態によるメディア表現技術のスキーマを図示する図面である。

【図8B】本発明の一実施形態によるメディア表現技術のスキーマを図示する図面である。

【図9A】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9B】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9C】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9D】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9E】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9F】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9G】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図9H】本願発明の一実施形態によるメディア表現技術を図示する図面である。

【図10A】本発明の一実施形態による複数のメディアデータを図示する図面である。

【図10B】本発明の一実施形態による複数のメディアデータを図示する図面である。

【図10C】本発明の一実施形態による複数のメディアデータを図示する図面である。

【図11A】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。

【図11B】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。

【図12A】本発明の他の実施形態による複数のメディアデータを図示する図面である。

【図12B】本発明の他の実施形態による複数のメディアデータを図示する図面である。

【図13】本発明の一実施形態によるデータ伝送装置に係わるブロック図である。

【図14】本発明の一実施形態によるデータ受信装置に係わるブロック図である。

【図15A】本発明の一実施形態による第１タイプの位置情報に係わる一例を示す図面である。

【図15B】本発明の一実施形態による第１タイプの位置情報に係わる一例を示す図面である。

【図16】本発明の一実施形態による位置情報を利用してランダムアクセスを提供する一例を示す図面である。

【図17A】本発明の一実施形態による第２タイプの位置情報に係わる一例を示す図面である。

【図17B】本発明の一実施形態による第２タイプの位置情報に係わる一例を示す図面である。

【図17C】本発明の一実施形態による位置情報を示す図面である。

【図18】本発明の一実施形態による位置情報を利用し、ランダムアクセスを提供する一例を示す図面である。

【図19】本発明の一実施形態による第３タイプの位置情報に係わる一例を示す図面である。

【図20】本発明の一実施形態による第１タイプの位置情報に係わる他の例を示す図面である。

【図21】本発明の一実施形態によるスケーラブル映像データを示す図面である。

【図22】本発明の一実施形態による位置情報を利用し、ランダムアクセスを提供する一例を示す図面である。

【図23】本発明の一実施形態による位置情報を利用し、ランダムアクセスを提供する一例を示す図面である。

【図24】本発明の一実施形態による第２タイプの位置情報についての他の例を示す図面である。

【図25】本発明の一実施形態による第３タイプの位置情報についての他の例を示す図面である。

【図26A】本発明の一実施形態による位置情報に係わる一例の図面である。

【図26B】本発明の一実施形態による位置情報に係わる一例の図面である。

【図26C】本発明の一実施形態による位置情報に係わる一例の図面である。

【図26D】本発明の一実施形態による「ＴＳ＿program＿map＿section」に係わる一例を示す図面である。

【図26E】本発明の一実施形態による「ＴＳ＿program＿map＿section」に係わる一例を示す図面である。

【図26F】本発明の一実施形態による「ＴＳ＿program＿map＿section」に係わる一例を示す図面である。

【図27】本発明の一実施形態によるデータ受信装置で、ユーザがトリックプレイを要請した場合のサービス提供方法に係わるフローチャートである。

【図28】本発明の他の実施形態によるＭＰＥＧ ＴＳ（transport stream）で、Ｉフレームを探すためのＴＳパケットの構造を図示する図面である。

【図29】本発明の一実施形態によるＭＰＥＧ ＴＳで、Ｉフレームを探すためのＭＰ４ファイル構造を図示する図面である。

【図30】本発明の一実施形態によるデータ伝送方法に係わるフローチャートである。

【図31】本発明の一実施形態によるデータ受信方法に係わるフローチャートである。

【図32A】「random＿access＿point＿count」フィールド値によって、ランダムアクセスを提供する方法に係わる一例を示す図面である。

【図32B】「random＿access＿point＿count」フィールド値によって、ランダムアクセスを提供する方法に係わる一例を示す図面である。

【図32C】本発明の一実施形態によって、少なくとも１つの他のセグメントの位置情報を含む少なくとも１つのセグメントを利用するランダムアクセスを提供する方法を示す図面である。

【発明を実施するための形態】

【0024】

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

【0025】

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

【0026】

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

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

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

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

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

【0062】

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

【0063】

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

【0064】

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

【0065】

コンテンツに係わる情報は、図４Ｃと関連して説明したように、「Fragments」タグを含んでいる。従って、クライアント１３０は、「Fragments」タグに含まれたＵＲＬ情報に基づいて、選択されたメディアデータの伝送をサーバ１２０に要請する。

【0066】

クライアント１２０の要請によって、サーバ１２０は、メディアデータを伝送する。要請されたメディアデータの少なくとも１つの部分をクライアント１２０に伝送することができる。ＨＴＴＰ要請に対するＨＴＴＰ応答として、要請されたメディアデータをクライアント１２０に伝送することができる。

【0067】

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

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

図６を参照すれば、本発明の一実施形態によるコンテンツに係わる情報は、図３と同一に、「Title」、「Synopsis」、「OriginSite」、「ContentＵＲＬ」のタグなどを含んでいる。しかし、図３に図示された実施形態では、コンテンツに係わる情報が「Tracks」、「ＲｅｆData」及び「Fragments」のタグを含むことによって、複数のメディアデータに係わる情報も共に含むのに対し、図６に図示された実施形態では、コンテンツに係わる情報が、複数のメディアデータに係わる情報を含むのではなく、複数のメディアデータに係わる情報を含むファイル（以下、「メディア表現記述（media presentation description）」）のＵＲＬのみ定義するところが異なる。「ContentＵＲＬ」タグによって、メディア表現記述のＵＲＬが定義される。

【0076】

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

【0077】

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

【0078】

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

【0079】

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

【0080】

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

【0081】

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

【0082】

ステップ５１０でクライアント１３０がサーバ１２０から受信したコンテンツに係わる情報は、図６及び図７と関連して説明したように、メディア表現記述のＵＲＬ情報を含んでもよいが、クライアント１３０は、コンテンツに係わる情報の「ContentＵＲＬ」タグを参照し、メディア表現記述をサーバ１２０に要請して受信する。メディア表現記述について、図８Ａ、図８Ｂ、図９Ａないし図９Ｇを参照しつつ詳細に説明する。

【0083】

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

【0084】

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

【0085】

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

【0086】

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

【0087】

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

【0088】

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

【0089】

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

【0090】

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

【0091】

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

【0092】

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

【0093】

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

【0094】

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

【0095】

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

【0096】

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

【0097】

図９Ａないし図９Ｈは、本願発明の一実施形態によるメディア表現記述を図示している。

【0098】

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

【0099】

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

【0100】

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

【0101】

図９Ａに図示されたメディア表現記述は、コンテンツを異なる品質にエンコーディングすることで生成された３種のビデオデータ、１つのオーディオデータ及び変速再生のために、Ｉフレームだけエンコーディングすることで生成されたメディアデータに係わる情報を含む。

【0102】

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

【0103】

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

【0104】

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

【0105】

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

【0106】

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

【0107】

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

【0108】

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

【0109】

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

【0110】

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

【0111】

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

【0112】

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

【0113】

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

【0114】

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

【0115】

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

【0116】

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

【0117】

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

【0118】

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

【0119】

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

【0120】

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

【0121】

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

【0122】

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

【0123】

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

【0124】

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

【0125】

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

【0126】

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

【0127】

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

【0128】

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

【0129】

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

【0130】

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

【0131】

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

【0132】

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

【0133】

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

【0134】

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

【0135】

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

【0136】

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

【0137】

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

【0138】

図１３は、本発明の一実施形態によるデータ伝送装置１３００に係わるブロック図である。

【0139】

本発明の一実施形態によるデータ伝送装置１３００は、獲得部１３１０、生成部１３２０及び伝送部１３３０を備える。

【0140】

獲得部１３１０は、同じコンテンツを異なる品質にエンコーディングすることで生成された複数個のメディアデータを獲得する。複数個のメディアデータは、所定のコンテンツを異なる方式でエンコーディングするか、あるいは同じ方式でエンコーディングするが、エンコーディング・パラメータを異にして生成されたものであってもよい。その場合、複数個のメディアデータは、異なる特徴を有する。一例として、複数個のメディアデータは、ビット率（bit rate）、解像度（resolution）、コーデック（codec）が異なる。

【0141】

複数個のメディアデータは、同じコンテンツから生成されたものであるので、相互間にスイッチングが可能である。ユーザは、高解像度のメディアデータを使用時に通信環境が悪化すれば、同じコンテンツから生成された低解像度のメディアデータにスイッチングすることができる。メディアデータ間のスイッチングは、セグメント単位で遂行されてもよい。

【0142】

セグメントは、エンコーディングされたコンテンツを、時間分割して生成される。従って、１つのメディアデータは、一つ以上のセグメントを含み得る。ユーザが、第１メディアデータ内の「Ａ」番目のセグメントを使用していて、他の品質を有する第２メディアデータを再生しようとすれば、第１メディアデータ内の「Ａ」番目のセグメントに対応する第２メディアデータ内のセグメントを受信して使用するのである。

【0143】

生成部１３２０は、少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成する。生成部１３２０は、１つの位置情報だけを生成し、１つの位置情報にあらゆるセグメントでのランダムアクセス・ポイント情報を含めることができるが、それぞれのセグメントに対応する複数個の位置情報を生成することができる。後者の場合、１つの位置情報には、ただ対応するセグメント内のランダムアクセス・ポイントの位置だけを含むのである。

【0144】

他の実施形態において、図３２Ｃに図示されているように、生成部１３２０は、少なくとも１つの他のセグメントの位置情報を含む少なくとも１つのセグメントを生成する。

【0145】

セグメントは、一つ以上のデータユニットから構成され、生成部１３２０は、位置情報をデータユニット内の所定位置に挿入することができる。

【0146】

位置情報を伝送する方法は、実施形態によって多様である。以下、位置情報を伝送する方法に係わる例として、４種を提示するが、本願発明は、それらに限定されるものではない。

【0147】

ｉ）ＭＰＥＧ ２標準によってエンコーディングされたメディアデータの場合、伝送パケット（transport packet）の「adaptation field」内に位置した「private＿data＿bytes」フィールドに位置情報を挿入して伝送することができる。「private＿data＿bytes」フィールドは、ＴＳレベルで、付加的なフレーム情報を提供するためのフィールドである。これについての詳細な説明は、図２６Ａを利用して後述する。

【0148】

ｉｉ）伝送パケット（transport packet）の「adaptation field」内に位置した「adaptation＿field＿extension」フィールドに位置情報を挿入して伝送することができる。「adaptation＿field＿extension」フィールドには、ユーザが新たに定義して使用できる「reserved」領域が存在し、「reserved」領域を介して位置情報を伝送する。これについての詳細な説明は、図２６Ｂを利用して後述する。

【0149】

ｉｉｉ）既存に存在するセクション内の所定のフィールドを介して、本願発明による位置情報を伝送する。一例として、ＭＰＥＧ−２では、ＴＳ＿description＿sectionを定義しており、ＴＳ＿description＿sectionは、「descriptor」フィールドを介して、多様な記述を提供する。本願発明による位置情報は、記述を介して伝送することができる。これについての詳細な説明は、図２６Ｃ及び図２６Ｄを参考にして後述する。

【0150】

ｉｖ）新たなセクションを定義し、新たに定義されたセクションを介して、本願発明による位置情報を伝送する。セクションは、伝送ストリームを介して伝送されるデータ形式の一つであり、主にサービス情報及びプログラム案内情報のようなサービス関連情報を含むデータである。これについての詳細な説明は、図２６Ｅ及び図２６Ｆを利用して後述する。

【0151】

ｖ）ＭＰＥＧ ４標準によってエンコーディングされたメディアデータの場合、「Ｍｏｏｆ」ボックスまたは、「Ｍｏｏｖ」ボックスに位置情報を挿入する。以下、説明の便宜のために、パケットを基準にして説明する。しかし、本発明は、ＭＰＥＧ ４標準によるボックスのように、他の標準によるエンコーディングでも同一に適用されることは、当業者に自明である。

【0152】

位置情報は、対応するセグメント内でのランダムアクセスが可能なポイントを指示する方式によって、異なる構造を有することができる。本明細書では、３種タイプの位置情報について説明する。しかし、位置情報は、これに限定されるものではない。

【0153】

第１タイプの位置情報は、対応するセグメント内のランダムアクセスが可能な次のパケットの位置を示す第１オフセット情報を含む。第１タイプの位置情報は、ランダムアクセスが可能なそれぞれのパケット内の所定位置に配置されるのである。第１タイプの位置情報に係わる詳細な説明は、図１５及び図２０で後述する。

【0154】

第２タイプの位置情報は、対応するセグメント内のランダムアクセスが可能なあらゆるパケットの位置を示す第２オフセット情報を含む。第２タイプの位置情報は、１つのパケットにいずれも含まれるか、あるいは連続する複数個のパケットにまたがって含まれてもよい。一例として、セグメントの開始から連続する複数個のパケットに第２タイプの位置情報が含まれてもよい。第２タイプの位置情報に係わる詳細な説明は、図１７及び図２４で後述する。

【0155】

第３タイプの位置情報は、対応するセグメント内のあらゆるアクセスユニットについての位置情報を示す第３オプション情報を含む。第３タイプの位置情報は、アクセスユニットのタイプ別位置を含むので、ランダムアクセスが可能ではないアクセスユニットではなくとも、位置が容易に分かる。第３タイプの位置情報に係わる詳細な説明は、図１９及び図２５で後述する。

【0156】

このように、異なるタイプの位置情報が使われる場合には、位置情報のタイプをシグナリングする必要がある。このために、生成部１３２０は、位置情報に係わるタイプ情報を位置情報に含めることができる。

【0157】

伝送部１３３０は、位置情報を伝送する。前述のように位置情報は、対応するセグメント内の所定パケットに挿入され、伝送部１３３０は、位置情報が挿入されたセグメントを含むメディアデータを伝送することができる。

【0158】

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

【0159】

本発明の一実施形態によるデータ受信装置１４００は、受信部１４１０、獲得部１４２０及び提供部１４３０を備える。

【0160】

受信部１４１０は、同じコンテンツを異なる品質にエンコーディングすることで生成された複数個のメディアデータのうち、少なくとも一つを受信する。複数個のメディアデータは、エンコーディングされたコンテンツを時間分割した部分である一つ以上のセグメントを含む。

【0161】

受信部１４１０は、コンテンツを異なる品質にエンコーディングすることで生成された複数のメディアデータに係わる情報を含むファイルをまず受信した後、ユーザの選択または外部環境に基づいて、複数個のメディアデータのうち一つ以上のメディアデータを選択的に受信することができる。

【0162】

獲得部１４２０は、少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を獲得する。位置情報は、自体が搭載されたセグメント内のランダムアクセス・ポイントについての情報だけを含むか、あるいは自体が搭載されていないセグメントのランダムアクセス・ポイントについての情報までいずれも含んでもよい。以下では、説明の便宜のために、位置情報自体が搭載されたセグメント内のランダムアクセス・ポイントについての情報だけを含むと仮定する。

【0163】

セグメントは、一つ以上のパケット（例えば、ＭＰＥＧ ２ＴＳパケットまたはＭＰＥＧ ４ボックス）から構成され、獲得部１４２０は、セグメント内の所定パケットにアクセスして位置情報を獲得する。

【0164】

獲得部１４２０が位置情報を獲得する方法は、位置情報のタイプによって異なることが可能であるので、獲得部１４２０は、まず位置情報に係わるタイプ情報を獲得する。

【0165】

第１タイプの位置情報の場合、獲得部１４２０は、セグメント内の特定パケット（例えば、最初のパケット）にアクセスする。獲得部１４２０は、アクセスしたパケット内の所定位置から（例えば、「private＿data＿bytes」フィールド）、ランダムアクセスが可能な次のパケットの位置を獲得する。獲得部１４２０は、アクセスしたパケット内の所定の位置から、ランダムアクセスが可能なその次のパケットの位置を獲得する。獲得部１４２０は、かような方式で、ランダムアクセスが可能なパケットに順次にアクセスし、次のランダムアクセス・ポイントの位置を獲得する。

【0166】

第２タイプの位置情報の場合、獲得部１４２０は、セグメント内の一つ以上の所定パケットの位置情報を獲得する。実施形態によっては、第２タイプの位置情報が、複数個の連続するパケットにまたがって含まれもする。その場合、獲得部１４２０は、複数個のパケットから位置情報を獲得して組み合わせる。第２タイプの位置情報が獲得されれば、当該セグメント内では、位置情報をさらに獲得する必要がない。しかし、位置情報がアップデートされたり、あるいはエラーが発生した場合に備え、アップデートされた後の特定パケットに位置情報を挿入したり、あるいは所定周期のパケットごとに位置情報を挿入したりもする。

【0167】

第３タイプの位置情報の場合、獲得部１４２０は、セグメント内の一つ以上の所定パケットの位置情報を獲得する。実施形態によっては、第３タイプの位置情報が、複数個の連続するパケットにまたがって含まれもする。その場合、獲得部１４２０は、複数個のパケットから位置情報を獲得して組み合わせる。第３タイプの位置情報は、位置情報がセグメント内のあらゆるアクセスユニット（access unit）（例えば、Ｐフレーム、Ｂフレーム、Ｉフレーム）についての位置情報を示す第３オフセット情報を含むので、必要によっては、ランダムアクセスが不可能なアクセスユニットに選択的にアクセスすることもある。

【0168】

提供部１４３０は、位置情報を利用して受信されたメディアデータに係わるランダムアクセスを提供する。

【0169】

従来には、「random＿access＿indicator」フィールドを利用してランダムアクセス機能を支援した。従って、クライアントでは、所望のランダムアクセス・ポイントを検出するまで、パケットを一つ一つ検索せねばならない。しかし、本願発明では、ランダムアクセス情報を特定フィールド（例えば、ＭＰＥＧ ２ＴＳパケットのヘッダ内の「private＿data＿bytes」フィールド）を使用して提供することによって、ランダムアクセス機能を効果的に提供することができる。

【0170】

図１５Ａは、本発明の一実施形態による第１タイプの位置情報１５１０に係わる一例を示している。

【0171】

「data＿field＿tag」フィールド１５１１は、位置情報１５１０のタイプを示す。本明細書での位置情報は、次のランダムアクセス・ポイントを指示する第１オフセット情報、あらゆるランダムアクセス・ポイントを指示する第２オフセット情報、あらゆるアクセスユニットの位置を指示する第３オフセット情報のうち１つのタイプであると仮定する。

【0172】

「data＿field＿length」フィールド１５１２は、フィールド長を示す。

【0173】

「offset」フィールド１５１３は、１６ビットから構成され、現在パケットからランダムアクセスが可能な次のパケットまでのパケット個数を示す。図１５Ａでは、「offset」フィールド１５１３にパケット個数が含まれたが、次のランダムアクセス・ポイントを示すことができるいかなる値（例えば、次のランダムアクセス・ポイントまでのバイト数、次のランダムアクセス・ポイントのＰＴＳ、ＤＴＳ、メディアのglobal time、フレーム番号）が含まれてもよい。

【0174】

図１５Ｂは、本発明の実施形態による第１タイプの位置情報１５２０についての他の例を示している。

【0175】

「data＿field＿tag」フィールド１５２１は、位置情報１５２０のタイプを示す。

【0176】

「data＿field＿length」フィールド１５２２は、フィールド長を示す。

【0177】

「ＰＴＳ」フィールド１５２３は、「ＴＳ＿index」フィールド１５２４が示すパケットが提供するフレームのＰＴＳを示す。一実施形態では、「ＰＴＳ」フィールド１５２３が、メディアのglobal timeを示すこともできる。

【0178】

「ＴＳ＿index」フィールド１５２４は、現在パケットからランダムアクセスが可能な次のパケットまでのパケット個数を示す。

【0179】

図１６は、本発明の一実施形態による位置情報１５１０，１５２０を利用し、ランダムアクセスを提供する一例を示している。

【0180】

図１６は、１つのセグメント内のパケットを示し、位置情報１５１０，１５２０は、第１タイプである。

【0181】

図１６では、位置情報１５１０，１５２０がランダムアクセスが可能なパケットにのみ含まれると仮定する。また、セグメント内の最初のパケットは、ランダムアクセスが可能なパケットであると仮定する。

【0182】

獲得部１４２０は、最初のパケット内の「Private＿data＿bytes」フィールドにアクセスして位置情報を獲得する。最初のパケットから獲得した位置情報には、次のランダムアクセス・ポイントに係わるオフセット情報が含まれている。

【0183】

最初のパケットから順次にパケットを処理し、ユーザにコンテンツを提供していて、ユーザが特定位置へのジャンプを要請したと仮定する。ジャンプ後の再生は、必ずランダムアクセス・ポイントから開始されなければならないなので、獲得された位置情報から次のランダムアクセス・ポイントの位置を確認し、当該パケットにアクセスする。この後、アクセスしたパケットから順次にパケットを処理してデータを再生する。

【0184】

図１７Ａは、本発明の一実施形態による第２タイプの位置情報１７１０に係わる一例を示している。第２タイプの位置情報１７１０は、１つのセグメント内のあらゆるランダムアクセス・ポイントを指示する。

【0185】

位置情報１７１０は、１つのパケットに搭載されるが、場合によっては、連続する複数個のパケット内の特定フィールドに搭載されもする。位置情報１７１０が、パケット内のデータを搭載できる空間をいずれも占める場合には、当該パケットにペイロードデータがないこともある。パケットは、ＰＩＤを介してペイロードに含まれたデータを識別する。従って、ＰＩＤを利用し、当該パケットが位置情報を含むか否かを確認することができる。

【0186】

「data＿field＿tag」フィールド１７１１は、位置情報１７１０のタイプを示す。

【0187】

「data＿field＿length」フィールド１７１２は、フィールド長を示す。

【0188】

「ＲＡＰ＿index＿finish＿flag」フィールド１７１３は、現在のパケットで、「ＲＡＰ＿index」データが終わっているか否かを示す。前述のように位置情報１７１０は、複数個のパケットにまたがって存在し、「ＲＡＰ＿index＿finish＿flag」フィールド１７１３が、「０」であるならば、次のパケットに位置情報１７１０が含まれ、「ＲＡＰ＿index＿finish＿flag」フィールド１７１３が、「１」であるならば、次のパケットに位置情報１７１０が含まれないということを示す。

【0189】

「ＰＴＳ」フィールド１７１４は、後述する「ＴＳ＿index」フィールド１７１５が示すパケットから始まるフレームのＰＴＳ（またはメディアのglobal time）を示す。「ＴＳ＿index」フィールド１７１５は、それぞれのランダムアクセス・ポイントに係わるインデックスを示す。「ＴＳ＿index」フィールド１７１５は、ランダムアクセス・ポイントの位置を、パケットの個数、バイト数などを利用して示すことができる。図１７Ａでｎは、セグメント内の「ランダムアクセス・ポイントの個数−１」である。従って、位置情報１７１０には、「ＰＴＳ」フィールド１７１４と、「ＴＳ＿index」フィールド１７１５とが「ｎ＋１」回反復して存在する。

【0190】

図１７Ｂは、本発明の一実施形態による第２タイプの位置情報１７２０に係わる一例を示している。第２タイプの位置情報１７２０は、１つのセグメント内のあらゆるランダムアクセス・ポイントを指示する。

【0191】

「data＿field＿tag」フィールド１７２１は、位置情報１７２０のタイプを示す。

【0192】

「data＿field＿length」フィールド１７２２は、フィールド長を示す。

【0193】

「ＲＡＰ＿count」フィールド１７２３は、セグメント内の全体ランダムアクセス・ポイントの個数を示す。

【0194】

「ＰＴＳ」フィールド１７２４は、後述する「ＴＳ＿index」フィールド１７２５が示すパケットから始まるフレームのＰＴＳ（またはメディアのglobal time）を示す。「ＴＳ＿index」フィールド１７２５は、現在パケットからランダムアクセスが可能な次のパケットの開始までのパケットの個数を示す。

【0195】

図１７Ｃは、本発明の一実施形態による位置情報に係わる他の例を示している。

【0196】

図１７Ｃは、メディアデータを構成するセグメントについてのインデックスである。図１７Ｃでは、本願発明による位置情報をセグメント・インデックスに挿入し、セグメント・インデックスを、「private＿data＿field」を介して伝送する。図１７Ｃでは、本願発明の位置情報と関連していないフィールドについての説明は省略する。

【0197】

「segment＿contains＿ｒａｐ」フィールド１７３１は、セグメント内に少なくとも１つのランダムアクセス・ポイントが存在するか否かを示す。

【0198】

「segment＿starts＿with＿ｒａｐ」フィールド１７３２は、セグメントの最も近いアクセスポイントが、ランダムアクセス・ポイントであるか否かを示す。すなわち、セグメントの開始が、ランダムアクセス・ポイントであるか否かを示す。

【0199】

「number＿entries」フィールド１７３３は、ランダムアクセス・ポイントの個数を示す。

【0200】

「direction」フィールド１７３４は、現在位置からランダムアクセス・ポイントが存在する方向を示す（例えば、以前のランダムアクセス・ポイント、またはそれ以後のランダムアクセス・ポイント）。

【0201】

「reference type」フィールド１７３５は、ランダムアクセス・ポイントをインデクシングするときに基準になるパケットのタイプを決定する。次の表１は、「reference type」フィールド１７３５による基準パケットのタイプに係わる一例である。

【0202】

【表1】

【0203】

「offset flags」フィールド１７３６は、オフセット値のタイプを示す。次の表２は、「offset flags」フィールド１７３６値によるオフセット値のタイプに係わる一例である。

【0204】

【表2】

【0205】

「offset flags」フィールド１７３６の値が「００」であり、オフセットを示すフィールドの値が「３」であるならば、オフセット値は、８＊３＝２４ビットになる。

【0206】

「ｒａｐ＿size＿present＿flag」フィールド１７３７は、セグメントエントリー内にランダムアクセスの位置を示す情報が含まれているか否かを示す。

【0207】

「ｒａｐ＿size」フィールド１７３８は、ランダムアクセス・ユニットを完全に出コーディングするために読み取らねばならない連続的な伝送ストリームパケットの個数を示す。すなわち、現在パケットから次のランダムアクセス・ポイントまでに存在するパケットの個数を示す。このとき、「ｒａｐ＿size」フィールド１７３８が示すパケットの個数は、アクセスユニットの最初のパケットと最後のパケットとの間に存在するＰＩＤが異なるあらゆるパケットを含む。図１８は、本発明の一実施形態による位置情報１７１０，１７２０を利用してランダムアクセスを提供する一例を示している。

【0208】

獲得部１４２０は、最初のパケット（または、連続する一つ以上のパケット）内の「Private＿data＿bytes」フィールドにアクセスし、位置情報１５１０，１５２０を獲得する。最初のパケットから獲得した位置情報には、セグメント内のあらゆるランダムアクセス・ポイントに係わるオフセット情報が含まれている。

【0209】

最初のパケットから順次にパケットを処理し、ユーザにデータを再生していて、ユーザが特定位置へのジャンプを要請したと仮定する。獲得した位置情報１５１０，１５２０には、セグメント内のあらゆるアクセスポイントの位置が含まれているので、ユーザが要請した位置後に存在するランダムアクセス・ポイントにアクセスし、アクセスしたパケットから順次にパケットを処理してデータを再生する。

【0210】

図１９は、本発明の一実施形態による第３タイプの位置情報１９１０に係わる一例を示している。

【0211】

「data＿field＿tag」フィールド１９１１は、位置情報１９１０のタイプを示す。

【0212】

「data＿field＿length」フィールド１９１２は、フィールド長を示す。

【0213】

「ＡＵ＿index＿finish＿flag」フィールド１９１３は、ＡＵ＿indexデータが、現在パケットで終わっているか否かを示す。前述のように位置情報１９１０は、複数個のパケットにまたがって存在し、「ＡＵ＿index＿finish＿flag」フィールド１９１３が「０」であるならば、次のパケットに位置情報１９１０が含まれ、「ＡＵ＿index＿finish＿flag」フィールド１９１３が「１」であるならば、次のパケットに位置情報１９１０が含まれないということを示す。

【0214】

「ＴＳ＿index」フィールド１９１４は、アクセスユニットそれぞれに係わるパケットの位置を示す。実施形態によっては、「ＴＳ＿index」フィールド１９１４は、アクセスユニットそれぞれに係わる「ＡＵ＿information」フィールドの位置を示すこともある。

【0215】

「ＡＵ＿coding＿type＿information」フィールド１９１５は、アクセスユニットのタイプを示す。一例として、「ＡＵ＿coding＿type＿information」フィールド１９１５は、アクセスユニットが、Ｂフレーム、Ｐフレーム、Ｉフレーム、ＩＤＲフレームのうち一つであることを示すことができる。

【0216】

図２０は、本発明の一実施形態による第１タイプの位置情報２０１０についての他の例を示している。図２０の位置情報２０１０は、一部フィールドを除外すれば、図１５Ａの位置情報１５１０と同一であるので、異なる一部フィールドについてのみ説明する。

【0217】

「dependency＿flag」（またはweighting＿flag）フィールド２０１１は、「dependency」フィールド２０１３が存在するか否かを示す。「dependency＿flag」（またはweighting＿flag）フィールド２０１１が「１」に設定されれば、対応するランダムアクセス・ポイントが示すパケットは、依存性を有する。すなわち、当該パケットは、一つ以上の他のパケットのデータと共に処理されて再生される。

【0218】

「viewing＿flag」フィールド２０１２は、「viewing」フィールド２０１４フィールドが存在するか否かを示す。「viewing＿flag」フィールド２０１２が「１」に設定されれば、対応するランダムアクセス・ポイントは、三次元映像を提供する。

【0219】

「dependency」フィールド２０１３は、ランダムアクセス・ポイントに該当するパケットの依存度を示す。例えば、基本階層（basis layer）と強化階層（enhancement layer）とから構成されるスケーラブル映像成分を仮定する。基本階層は、強化階層なしにもデコーディングされるために、依存度は、「０」に設定される。しかし、強化階層をデコーディングするためには、基本階層及び下位階層のデコーディングが必須である。これは、スケーラブル階層が増大することにより、依存度が上昇するということを意味する。従って、強化階層の依存度は、「１」以上に設定される。依存度と同じ概念として、加重値（weighting）は、依存度と反対に作用する。

【0220】

「viewing」フィールド２０１４は、多視点コーディング（multi view coding）によってエンコーディングされた映像（例えば、自由視点ＴＶ、多視点三次元ＴＶまたはステレオスコーピック（２種の視点）の映像）の視点レベルを示す。ステレオスコーピックの場合、左視点映像を提供するパケットに対応する「viewing」フィールド２０１４は、「０」に設定され、右視点映像を提供するパケットに対応する「viewing」フィールド２０１４は、「１」に設定される。

【0221】

図２１は、本発明の一実施形態によるスケーラブル映像データを示している。

【0222】

図２１では、ｎ＋１個の映像データを提供する。「base layer」階層に該当する映像データは、単独再生が可能な低画質の映像データである。ユーザが一ステップ高い画質（または音質）の映像データを所望する場合、「enhancement layer １」階層と「base layer」階層とに該当する映像データを処理して再生する。ただし、「enhancement layer １」階層に該当する映像データは、単独再生が不可能である。同様に、ユーザが最も高画質の映像データを所望する場合、「base layer」階層から「enhancement layer ｎ」階層に該当する映像データをいずれも処理して再生する。

【0223】

上位階層に位置した映像データであるほど、共に再生せねばならない映像データの個数が多くなるので、依存度が上昇する。一方、重要度は低下するので、加重値は減少する。

【0224】

図２２は、本発明の一実施形態による位置情報２２１０，２２２０を利用し、ランダムアクセスを提供する一例を示している。図２２は、複数個の階層から構成されたスケーラブル映像データに係わるものである。

【0225】

獲得部１４２０は、基本階層に該当するランダムアクセスが可能なパケット２２０１にアクセスし、パケット２２０１内の「Private＿data＿bytes」フィールドから、位置情報２２１０を獲得する。

【0226】

位置情報２２１０内の「dependency＿flag」（またはweighting＿flag）フィールドを介して、当該パケット２２０１がスケーラブル映像データを提供するものであることを確認することができる。また、位置情報２２１０内の「dependency」フィールドを介して、当該パケット２２０１の階層を確認することができる。パケット２２０１の「dependency」フィールドは、「０」の値を有するので、パケット２２０１は、基本階層に該当する。

【0227】

獲得部１４２０は、「offset」フィールドを参考にして、上位階層に該当するパケット２２０２にアクセスし、パケット２２０２内の「Private＿data＿bytes」フィールドから、位置情報２２２０を獲得する。図２２で、パケット２２０２の「dependency」フィールドは、「１」の値を有するので、パケット２２０２は、強化階層に該当する。

【0228】

図２３は、本発明の一実施形態による位置情報２３１０，２３２０を利用し、ランダムアクセスを提供する一例を示す。図２３では、左視点映像データと右視点映像データとから構成されたステレオスコーピック映像データに係わるものである。

【0229】

獲得部１４２０は、左視点映像データに該当するランダムアクセスが可能なパケット２３０１にアクセスし、パケット２３０１内の「Private＿data＿bytes」フィールドから、位置情報２３１０を獲得する。

【0230】

位置情報２３１０内の「viewing＿flag」フィールドを介して、当該パケット２３０１が三次元映像を提供するものであることを確認することができる。また、位置情報２３１０内の「viewing」フィールドを介して、当該パケット２３０１が提供する映像データの視点を確認することができる。パケット２３０１の「dependency」フィールドは、「０」の値を有するので、パケット２３０１は、左視点映像データである。

【0231】

獲得部１４２０は、「offset」フィールドを介して、ランダムアクセスが可能な右視点映像データに該当するパケット２３０２にアクセスし、パケット２３０２内の「Private＿data＿bytes」フィールドから、位置情報２３２０を獲得する。図２３で、パケット２３０２の「viewing」フィールドは、「１」の値を有するので、パケット２３０２は、右視点映像データである。

【0232】

図２４は、本発明の一実施形態による第２タイプの位置情報２４１０についての他の例を示している。図２４の位置情報２４１０は、一部フィールドを除外すれば、図１７Ａの位置情報１７１０と同一であるので、以下、説明を省略する。

【0233】

図２５は、本発明の一実施形態による第３タイプの位置情報２５１０についての他の例を示している。図２５の位置情報２５１０は、一部フィールドを除外すれば、図１９の位置情報１９１０と同一であるので、以下、説明を省略する。

【0234】

図２６Ａは、本発明の一実施形態による位置情報を含むＭＰＥＧ ＴＳ（transport stream）の構造に係わる一例である。

【0235】

「Adaptation field」内に、「private data」を入力するフィールドが「private−data−byte」として存在する。データ伝送装置１３００は、「private−data−byte」の長さを定義した後、「transport−private−data−length」に入力する。データ伝送装置１３００は、「transport−private−data−length」ほど「private−data−byte」に記録する。「private−data−byte」は、「unsigned integer」形態の数値である。「private−data−byte」の値は、現在あるＴＳパケットで、次のＩフレームを有するＴＳパケットの開始位置に係わるオフセット値を意味する。ＴＳにいくつかのＩフレームが存在する場合、それぞれのＩフレームが始まるところに、「Adaptation field」が存在する。

【0236】

図２６Ｂは、本発明の一実施形態による位置情報を含むＭＰＥＧ ＴＳ（transport stream）の構造についての他の例である。

【0237】

ＭＰＥＧ−２ ＴＳパケットのヘッダには、「adaptation＿field」が存在する。「adaptation＿field」には、「adaptation＿field＿extension」フィールドが存在し、「adaptation＿field＿extension」フィールドには、ユーザが任意に定義して使用することができる「reserved」領域が存在する。図２６Ｃでは、「adaptation＿field＿extension」フィールドに、本願発明による位置情報が含まれるか否かを示すフラグと、次のランダムアクセス・ポイントの位置を示すバイト値が含まれたフィールドとを挿入する。

【0238】

図２６Ｂでは、説明の便宜のために、位置情報と関連したフィールドについてのみ説明する。

【0239】

「adaptation＿field＿extension＿flag」フィールド２６１１は、「adaptation＿field」内に、「adaptation＿field＿extension」フィールドが存在するか否かを示す。

【0240】

「random＿access＿point＿flag」フィールド２６１２は、「adaptation＿field＿extension」フィールド内に、ランダムアクセス・ポイントの位置を示す情報が含まれているか否かを示す。

【0241】

「random＿access＿point＿count」フィールド２６１３は、ＴＳパケットで提供するランダムアクセス・ポイントの個数を示す。

【0242】

「random＿access＿point＿count」フィールド２６１３が「１」の値を有せば、ＴＳパケット内には、１つのランダムアクセス・ポイントの位置だけ含まれるということを意味する。「random＿access＿point＿count」フィールド２６１３が「１」の値を有する場合のパケットの構造に係わる一例は、図３２Ａに図示されている。図３２Ａを参考にすれば、ＴＳパケットには、次のランダムアクセス・ポイントの位置だけ含まれ、次のランダムアクセス・ポイントが始まるＴＳパケットで、その次のランダムアクセス・ポイントの位置をさらに獲得せねばならない。

【0243】

「random＿access＿point＿count」フィールド２６１３が、「２」以上の値を有せば、ＴＳパケット内には、複数のランダムアクセス・ポイントの位置が含まれるということを意味する。「random＿access＿point＿count」フィールド２６１３が、「２」以上の値を有する場合のパケットの構造に係わる一例は、図３２Ｂに図示されている。図３２Ｂを参考にすれば、ＴＳパケットには、複数個のランダムアクセス・ポイントの位置が含まれている。従って、１つのＴＳパケットを処理し、所定区間内に存在するランダムアクセス・ポイントの位置がいずれも分かる。

【0244】

「random＿access＿point＿length」フィールド２６１４は、現在ＴＳパケットから次のランダムアクセス・ポイントが始まるＴＳパケットまでのバイト数を示す。

【0245】

データ受信装置は、ＴＳパケットのヘッダをパージングし、「adaptation＿field＿extension」フィールドに含まれた情報を獲得し、「random＿access＿indicator」フィールドが存在するか否かを判断する。

【0246】

「random＿access＿indicator」フィールドが存在するならば、「random＿access＿point＿count」フィールド２６１３と、「random＿access＿point＿length」フィールド２６１４とを利用することによって、ランダムアクセス・ポイントの位置を容易に把握することができる。

【0247】

図２６Ｂでは、「adaptation＿field＿extension」フィールドに、本願発明による位置情報を挿入することによって、ＴＳの構造を大きく変化させずとも、ランダムアクセス・ポイントの位置を効率的に提供する。

【0248】

図２６Ｃは、本発明の一実施形態による位置情報を含む「ＴＳ＿description＿section」に係わる一例である。

【0249】

ＭＰＥＧ ２では、プログラム情報のようなシグナリング情報を伝達するために、多様なセクションを定義している。次の表３は、ＭＰＥＧ ２で定義するセクションに係わる一例である。

【0250】

【表3】

【0251】

ＭＰＥＧでは、ＰＡＴ、ＰＭＴのような多様な形態のセクションを定義しており、それぞれのセクションには、固有の「ＰＩＤ」値が割り当てられる。

【0252】

また、それぞれのセクションは、「table＿ｉｄ」値が指定される。次の表４は、「table＿ｉｄ」値によるセッションの種類である。

【0253】

【表4】

【0254】

表３及び表４を参考にすれば、「table＿ｉｄ」の値が「０ｘ００」であるセクションは、ＰＡＴであり、ＰＩＤは、「０ｘ００」である。また、「table＿ｉｄ」の値が「０ｘ０３」であるセクションは、「ＴＳ＿description＿section」であり、ＰＩＤが「０ｘ０２」である。「ＴＳ＿description＿section」は、多様な記述子（デスクリプタ）を提供する。

【0255】

図２６Ｃは、「ＴＳ＿description＿section」であるから、「table＿ｉｄ」フィールド２６３１の値が「０ｘ０３」がなる。

【0256】

「descriptor」フィールド２６３２は、本願発明による位置情報が含まれる。「descriptor」フィールド２６３２に含まれる位置情報に係わる一例は、図２６Ｄで述べる。

【0257】

図２６Ｄは、本発明の一実施形態による「ＴＳ＿description＿section（）」に挿入された位置情報を含むＴＳパケット２６４０に係わる一例である。

【0258】

ＴＳパケット２６４０は、ヘッダ２６４１とペイロード領域２６４２とから構成される。ヘッダ２６４１には、ペイロード領域２６４２に含まれたデータを識別するためのＰＩＤフィールドが存在する。

【0259】

ＴＳパケット２６４０のペイロード領域２６４２には、ランダムアクセス・ポイントの位置情報を含む「ＴＳ＿description＿section（）」が搭載される。従って、ＴＳパケット２６４０のＰＩＤは、「０ｘ０２」になり、「table＿ｉｄ」は、「０ｘ０３」になるのである。

【0260】

ランダムアクセス・ポイントの位置情報は、「descriptor＿tag」フィールド２６４３、「descriptor＿length」フィールド２６４４、「random＿access＿point＿count」フィールド２６４５及び「random＿access＿point＿offset」フィールド２６４６を含んでもよい。

【0261】

「descriptor＿tag」フィールド２６４３は、８ビットのフィールドであり、記述子を区分する識別子である。

【0262】

「descriptor＿length」フィールド２６４４は、８ビットのフィールドであり、記述子のバイト個数を示す。

【0263】

「random＿access＿point＿count」フィールド２６４５は、ＴＳパケットで提供するランダムアクセス・ポイントの個数を示す。

【0264】

「random＿access＿point＿length」フィールド２６４６フィールドは、ランダムアクセス・ポイントの位置を示す。

【0265】

図２６Ｅは、ＭＰＥＧ−２標準による「ＴＳ＿program＿map＿section」（以下、ＰＭＴ）構造に係わる一例である。

【0266】

ＰＭＴは、「stream＿type」フィールド２６５１と「elementary＿ＰＩＤ」フィールド２６５２とのマッピング情報を含む。すなわち、ＰＭＴは、特定データタイプに係わる識別情報を提供する。

【0267】

ＭＰＥＧ ２標準では、「stream＿type」フィールド２６５１の値が「０ｘ８０〜０ｘＦＦ」である場合をユーザが任意に使用することができる「reserved」領域として提供している。従って、「０ｘ８０〜０ｘＦＦ」のうち一つが、本願発明の位置情報を示すものであると設定できる。例えば、「stream＿type」フィールド２６５１値が「０ｘ８０」であるならば、当該ストリームが、本願発明の位置情報を含むと仮定することができる。

【0268】

同時に、本願発明の位置情報を含むストリームの「elementary＿ＰＩＤ」を「reserved」された値のうち一つ（例えば、「１０００」）に設定する。

【0269】

もし受信機で、ランダムアクセス・ポイントについての位置情報が含まれたストリームを獲得しようとすれば、「elementary＿ＰＩＤ」２６５２が「１０００」であるパケットを獲得する。

【0270】

図２６Ｆは、本発明の一実施形態による「private＿section（）」に挿入された位置情報を含むＴＳパケット２６６０に係わる一例である。

【0271】

ＴＳパケット２６６０は、ヘッダ２６６１とペイロード領域２６６２とから構成される。ヘッダ２６６１は、ペイロード領域２６６２に含まれたデータを識別するためのＰＩＤフィールドが存在する。ＴＳパケット２６６０のＰＩＤが「１０００」であるから、ペイロード２６６２には、ランダムアクセス・ポイントについての位置情報が含まれるということが分かる。

【0272】

本発明の一実施形態では、「private＿section（）」を利用し、ランダムアクセス・ポイントについての情報を伝達すると仮定したが、実施形態によっては、既存の「private＿section（）」ではない新たなsectionを設定したり、あるいはＴＳパケットのペイロードなどに割り当てられたＰＩＤを利用し、ランダムアクセス・ポイントについての情報を伝送することができるということは、本発明が属する技術分野で当業者には自明である。

【0273】

図２６Ｆで、ＴＳパケット２６６０のペイロード領域２６６２には、「private＿section（）」が含まれる。ＭＰＥＧ−２ＴＳでは、ユーザがセクションを新たに定義して使用することができるように、「table＿ｉｄ」が「０ｘ４０」〜「０ｘＦＥ」である場合を「reserved」領域として提供しており、「table＿ｉｄ」が「０ｘ４０」であるセクションを、「private＿section（）」と定義し、本願発明による位置情報を搭載する。

【0274】

「private＿section（）」は、「table＿ｉｄ」フィールド２６６３及び「private＿data＿type」フィールド２６６４を含む。

【0275】

「table＿ｉｄ」フィールド２６６３は、セクションのタイプを示す。

【0276】

「private＿data＿type」フィールド２６６４は、本願発明による位置情報が含まれる。本願発明による位置情報は、「random＿access＿point＿count」フィールド２６６５及び「random＿access＿point＿offset」フィールド２６６６を含むことができ、これについての説明は、図２６Ｄと同一であるので省略する。

【0277】

図２７は、本発明の一実施形態によるデータ受信装置で、ユーザがトリックプレイを要請した場合のサービス提供方法に係わるフローチャートを示している。図２７では、Ｉフレームを順次に再生することによって、トリックプレイを提供すると仮定する。

【0278】

ステップ２７１０で、ユーザからトリックプレイの要請を受信する。

【0279】

ステップ２７２０で、パケット内に「adaptation field」が存在するか否かを判断する。パケット内に「adaptation field」が存在すれば、ステップ２７３０に進み、そうではなければ、次のパケットに「adaptation field」が存在するか否かを判断する。もしクライアントが、位置情報を含むパケットの位置を知っている場合（例えば、セグメント内の最初のパケットとして約束した場合）には、ステップ２７２０を遂行しない。

【0280】

ステップ２７３０で、「adaptation field」内の「private−data−byte」から、位置情報を獲得することによって、Ｉフレームの位置を確認する。第１タイプの位置情報が獲得された場合には、次のＩフレームの位置だけを獲得できるのであり、第２タイプまたは第３タイプの位置情報が獲得された場合には、セグメント内のあらゆるＩフレームの位置を確認することができる。

【0281】

以下、第１タイプの位置情報が獲得されたと仮定し、次のＩフレームオフセットを抽出する過程について簡略に説明する。例えば、オフセット値が２４６２である場合、２４６２の値を１６ビット値に変更した０ｘ９９Ｅを計算する。「unsigned integer」のサイズが４バイトであるから、「transport−private−data−length」値を４として登録する。０ｘ９９Ｅを４バイト整数である「０ｘ００ ０ｘ００ ０ｘ０９ ０ｘ９Ｅ」に変換する。「private−data−byte」に変換された値を入力する。反対に、「private−data−byte」からオフセット値を抽出する方法で、「private−data−byte」がｐｄｂ［４］と宣言された場合、オフセットは、（ｉｎｔ）（ｐｄｂ［３］＜＜２４ ｜ ｐｄｂ［２］＜＜１６ ｜ ｐｄｂ［１］＜＜８｜ｐｄｂ［０］）と計算される。

【0282】

ステップ２７４０で、次のＩフレームオフセットほどＴＳファイルを分離する。

【0283】

ステップ２７５０で、セグメント内のファイルの最後であるか否かを判断する。セグメントファイルの最後ではない場合、ステップ２７３０に移動し、再び次のＩフレームを抽出する。セグメントファイルの最後である場合、ステップ２７２０に移動し、次のセグメントについて同じ過程を遂行する。

【0284】

図２８は、本発明の他の実施形態によるＭＰＥＧ ＴＳ（transport stream）で、Ｉフレームを見い出すためのＴＳパケットの構造を図示している。

【0285】

「Adaptation field」は、ＴＳヘッダの一部分であり、ＴＳ関連追加情報を入力する選択的なフィールドである。「Adaptation field」は、さまざまなパラメータを有し、そのうち、ユーザが任意に使用することができる「private data field」が存在する。「transport＿private＿data＿length」は、「Adaptation field」内に存在する「private data field」のサイズ知らせるパラメータである。「private＿data＿byte」は、ユーザが任意に定義したデータを保存する空間である。クライアントは、「transport＿private＿data＿length」と「private＿data＿byte」とを利用し、ＭＰＥＧ ＴＳで、次のＩフレームの開始位置を計算することができる。

【0286】

図２９は、本発明の一実施形態による、ＭＰＥＧ ＴＳで、Ｉフレームを探すためのＭＰ４ファイル構造を図示している。

【0287】

ＭＰ４ファイル構造では、エンコーディングされたデータを、時間に基づいて分割して生成されたセグメントが、一つ以上の「ｍｏｏｆ」ボックス及び「ｍｄａｔ」ボックスを含む。「ｍｏｏｆ」ボックスは、セグメントに係わるメタデータが含まれ、「ｍｄａｔ」ボックスは、コンテンツを提供するペイロードデータが含まれる。

【0288】

Ｉフレームの位置情報は、ＭＰ４ファイルの「Ｔｒａｋ」ボックスや「Ｔｒａｆ」ボックス内の「ｍｏｏｆ」ボックスを介して獲得することができる。

【0289】

図３０は、本発明の一実施形態によるデータ伝送方法に係わるフローチャートを示している。

【0290】

ステップ３０１０では、同じコンテンツを異なる品質にエンコーディングすることで生成される少なくとも１つのセグメントを含む複数個のメディアデータを獲得する。

【0291】

ステップ３０２０では、少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を生成する。

【0292】

ステップ３０３０では、位置情報を伝送する。

【0293】

図３１は、本発明の一実施形態によるデータ受信方法に係わるフローチャートを示している。

【0294】

ステップ３１１０では、コンテンツを異なる品質にエンコーディングすることで生成されるそれぞれ少なくとも１つのセグメントを含む複数個のメディアデータのうち少なくとも一つを受信する。

【0295】

ステップ３１２０では、少なくとも１つのセグメントそれぞれのランダムアクセスが可能なポイントを示す位置情報を、受信されたメディアデータから獲得する。

【0296】

ステップ３１３０では、位置情報を利用して受信されたメディアデータに係わるランダムアクセスを提供する。

【0297】

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

【0298】

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

【0299】

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

【0300】

１００ ストリーミング・システム
１１０ エンコーディング装置
１２０ サーバ
１３０ クライアント
１４０ ネットワーク

【図1】

【図2A】

【図2B】

【図3】

【図4a】

【図4b】

【図4c】

【図5A】

【図5B】

【図6】

【図7】

【図8a】

【図8b】

【図9a】

【図9b】

【図9c】

【図9d】

【図9e】

【図9f】

【図9g】

【図9h】

【図10A】

【図10B】

【図10C】

【図11A】

【図11B】

【図12A】

【図12B】

【図12C】

【図13】

【図14】

【図15a】

【図15b】

【図16】

【図17a】

【図17b】

【図17c】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】

【図26a】

【図26b】

【図26c】

【図26d】

【図26e】

【図26f】

【図27】

【図28】

【図29】

【図30】

【図31】

【図32a】

【図32b】

【図32c】