(58)【調査した分野】(Int.Cl.,DB名)
前記複数のメディアデータは、それぞれのPTS(presentation time stamp)及びそれぞれのDTS(decoding time stamp)を含むPES(packetized elementary stream)から構成され、
前記それぞれのPTSと前記それぞれのDTSは、メディアデータの再生時間によって整列されることをさらに含むことを特徴とする請求項1に記載のメディアデータ受信方法。
【発明を実施するための形態】
【0029】
以下、図面を参照しつつ、本発明の実施形態について詳細に説明する。
【0030】
図1は、本発明の一実施形態によるストリーミング・システムを図示している。
【0031】
図1を参照すれば、本発明の一実施形態によるストリーミング・システム100は、エンコーディング装置110、サーバ120及びクライアント130を含む。
【0032】
エンコーディング装置110は、入力されたコンテンツを複数の異なる品質にエンコーディングし、1つのコンテンツに係わる複数のメディアデータを生成する。サーバ120がクライアント130にメディアデータをストリーミングするとき、ストリーミング環境は、変更されてもよい。例えば、ストリーミングのためのネットワーク140帯域幅が変更されもし、メディアデータを伝送するために、サーバ120が使用可能なハードウェア資源またはメディアデータを受信するために、クライアント130が使用可能なハードウェア資源が変更されもする。
【0033】
従って、エンコーディング装置110は、流動的なストリーミング環境による適応的なストリーミングのために、1つのコンテンツを複数の異なる品質にエンコーディングする。ビット率(bit rate)、サンプリング周波数(sampling frequency)、解像度またはフレーム率(frame rate)のような因子を調節することによって、1つのコンテンツを複数の異なる品質にエンコーディングすることができる。例えば、1つの動映像コンテンツを互いに異なる解像度でエンコーディングし、500Kbps、1000Kbps及び2000Kbpsの複数のメディアデータを生成することができる。
【0034】
異なる品質にエンコーディングされた複数のメディアデータは、サーバ120に伝送され、このとき、コンテンツについての情報及び複数のメディアデータそれぞれについての情報も、共にサーバ120に伝送される。コンテンツについての情報は、コンテンツのメタデータであり、コンテンツの題目(title)、シノプシス(synopsis)、コンテンツ識別子(content ID)、コンテンツURL(uniform resource locator)のような情報を含んでもよい。複数のメディアデータについての情報は、それぞれのメディアデータの品質、類型及び識別子などを含むことができるが、これについては、
図4A、
図4B及び
図4Cを参照して詳細に説明する。
【0035】
クライアント140は、コンテンツについての情報及び複数のメディアデータについての情報のうち少なくとも一つを受信し、これに基づいて、サーバ120に複数のメディアデータのうち少なくとも1つのメディアデータを要請する。クライアント130は、ストリーミング環境を推定(estimation)し、推定されたストリーミング環境に基づいて、複数のメディアデータのうち少なくとも1つのメディアデータを選択する。推定されたストリーミング環境で、適切なQoS(quality of service)を維持することができる少なくとも1つのメディアデータを選択することができる。その後、クライアント130は、選択された少なくとも1つのメディアデータの伝送を要請するHTTP要請(hypertext transfer protocol request)をサーバ120に伝送することができる。
【0036】
ストリーミング環境が劣化され、高品質のメディアデータを受信すれば、続けてメディアデータを再生することができない場合には、複数のメディアデータのうち、低品質のメディアデータを要請し、ストリーミング環境が改善されて高品質のメディアデータを受信しても、続けてメディアデータを再生することができる場合には、複数のメディアデータのうち高品質のメディアデータを要請することができる。
【0037】
所定のメディアデータを受信している途中に、他のメディアデータを伝送することをサーバ120に要請することもできる。例えば、ストリーミング環境が劣化された状態で、低品質の第1メディアデータを要請して受信していたクライアント130は、ストリーミング環境が改善されることにより、さらに高品質の第2メディアデータを伝送することをサーバ120に要請することができる。従来技術によるストリーミング方法によれば、サーバ120とクライアント130とがストリーミング・チャネルを最初に設定するとき、品質を一度設定すれば、続けて同じ品質でメディアデータを送受信せねばならなかった。しかし、本発明によれば、クライアント130が低品質の第1メディアデータを受信していても、同じコンテンツに係わるさらに高品質の第2メディアデータをさらに要請することができ、ストリーミング環境による適応的なストリーミングが可能になる。
【0038】
ネットワーク140の帯域幅、及びサーバ120またはクライアント130の使用可能なハードウェア資源に基づいて、ストリーミング環境を推定する多様な方法が、クライアント130がストリーミング環境を推定するのに利用される。例えば、クライアント130は、受信されるメディアデータのタイムスタンプ及びBER(bit error rate)に基づいて、ストリーミング環境を推定することができる。受信されるメディアデータのタイムスタンプを確認し、メディアデータが再生速度より遅い速度で受信されていれば、ストリーミング環境が劣化していると判断することができる。また、受信されるメディアデータのBERが高まっても、ストリーミング環境が劣化していると判断することができる。
【0039】
クライアント130が、ストリーミング環境によって複数のメディアデータのうち、少なくとも1つのメディアデータを伝送することを要請すれば、サーバ120は、要請されたメディアデータをクライアント130に伝送する。HTTP要請に対するHTTP応答として要請されたメディアデータをクライアント130に伝送することができる。
【0040】
複数のメディアデータそれぞれは、コンテンツを異なる品質にエンコーディングし、分割して生成された複数の部分(segment)のうち、少なくとも一つを含んでもよい。言い換えれば、エンコーディング装置110のエンコーディングの結果として生成された複数のメディアデータそれぞれは、時間に基づいて分割された少なくとも1つの部分をそれぞれ含んでもよい。サーバ120は、コンテンツを1つのストリームにエンコーディングして連続して伝送するのではなく、複数の部分に分割してそれぞれ伝送する。コンテンツを10秒または20秒のように、所定の時間単位で分割し、複数の部分を生成することができる。分割の基礎になる時間は、GOP(group of picture)に基づいて設定される。一つまたは二つ以上のGOPのピクチャに対応するメディアデータを、1つの部分として設定することができる。
【0041】
例えば、2種の品質でコンテンツがストリーミングされる場合、第1メディアデータは、コンテンツを第1品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を含むことができ、第2メディアデータは、コンテンツを第2品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を含んでもよい。
【0042】
複数のメディアデータを時間に基づいてそれぞれ分割することによって、前述の適応的なストリーミングが可能になる。例えば、ストリーミングが始まれば、サーバ120は、低品質の第1メディアデータの0秒から20秒に該当する部分を伝送する。その後、20秒後に、ストリーミング環境が改善されたと判断され、クライアント130がさらに高品質のメディアデータを要請すれば、サーバ120は、さらに高品質の第2メディアデータの20秒から40秒に該当する部分を伝送することができる。メディアデータが、時間に基づいて複数の部分に分割されているために、ストリーミング最中にも、ストリーミング環境によって異なるメディアデータの部分を伝送することができる。
【0043】
図2Aは、本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。
【0044】
図2Aを参照すれば、段階210でクライアント130は、所定のコンテンツについての情報を伝送することをサーバ120に要請する。クライアント130のユーザが、クライアント130の画面に表示されたユーザ・インターフェースで、所定のコンテンツを選択すれば、選択されたコンテンツについての情報を伝送することをサーバ120に要請する。クライアント130は、コンテンツについての情報を伝送することを要請するHTTP要請を、サーバ120に伝送することができる。
【0045】
クライアント130から要請を受信したサーバ120は、クライアント130にコンテンツについての情報を伝送する。HTTP要請に対するHTTP応答として、コンテンツについての情報をクライアント130に伝送することができる。コンテンツについての情報は、OIPF(open IPTV forum)標準によるCAD(content access descriptor)であってもよい。
図3を参照して詳細に説明する。
【0046】
図3は、本発明の一実施形態によるコンテンツについての情報を含むファイルのスキーマ(schema)を図示している。コンテンツについての情報を含むファイルは、CADであり、XML(eXtensible Markup Language)ファイルであってもよい。以下、本発明の詳細な説明では、タグ(tag)及び属性(attribute)を区分して説明するが、本発明の詳細な説明で、タグによって定義される項目を、タグではない属性によって定義したり、本発明の詳細な説明で、属性によって定義される項目を、属性ではないタグによって定義することができることは、本発明が属する技術分野で当業者であるならば、容易に分かるであろう。
【0047】
図3を参照すれば、コンテンツについての情報は、「Title」、「Synopsis」、「OriginSite」、「ContentURL」タグなどを含んでもよい。
【0048】
従来技術によるメディアデータのストリーミングは、1つのコンテンツを所定の品質にエンコーディングして1つのメディアデータを生成するので、従来技術によるコンテンツについての情報(特に、OIPFによるCAD)は、コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含まない。
【0049】
しかし、本発明の一実施形態によるコンテンツについての情報は、1つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むが、
図3に図示された実施形態の「Tracks」タグ、「RefData」タグ及び「Fragments」タグがこれに該当する。
【0050】
図4Aは、本発明の一実施形態による複数のメディアデータを定義するための情報を図示している。
【0051】
図4Aを参照すれば、「Tracks」タグは、コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータを区分するための情報である。「Tracks」タグは、複数のメディアデータそれぞれに割り当てられた「ID」属性(attribute)、「Type」属性及び「BitRate」属性を含む。
【0052】
「ID」属性は、メディアデータに対して順番に付与される識別子を定義し、「Type」属性は、メディアデータのオーディオデータ、ビデオデータ、ビデオ/オーディオデータ、字幕データのうちいずれのデータに該当するかを定義する。「Type」属性が「Packed」であるならば、メディアデータがビデオ/オーディオデータであることを示し、「Type」属性が「Video」であるならば、メディアデータがビデオデータであることを示す。「BitRate」属性は、ビデオデータのエンコーディングに利用されたビット率を定義する。
【0053】
図4Bは、本発明の一実施形態によるメディアデータのヘッダについての情報を図示している。
【0054】
図4Bを参照すれば、「RefData」タグは、「Type」属性及び「ID」属性を含む。「Type」属性は、ヘッダがいかなるメディア・フォーマットのヘッダであるかを定義する。例えば、「Type」属性が「HEAD−TS」であるならば、ヘッダが伝送ストリーム(transport stream)フォーマットのヘッダであることを示す。「ID」属性は、ヘッダが複数のメディアデータのうち、いずれのメディアデータのヘッダであるか定義する。「ID」属性が「1」であるならば、メディアデータ識別子が「1」であるメディアデータに係わるヘッダであることを示す。また、「RefData」タグは、ヘッダを指示(pointing)する情報を含むが、「URL」タグは、ヘッダの位置、すなわち、URLを定義する。
【0055】
「RefData」タグは、選択的な要素である。ヘッダがメディアデータと分離され、別のファイルとして存在する場合にのみ、コンテンツについての情報に「RefData」タグが含まれ、メディアデータと結合されて存在する場合には、コンテンツについての情報に「RefData」タグが含まれない。
【0056】
図4Cは、本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも1つの部分についての情報を図示している。
【0057】
図4Cを参照すれば、「Fragments」タグの下位タグである「Fragment」タグに、複数のメディアデータそれぞれに含まれた少なくとも1つの部分についての情報が含まれる。
【0058】
「Fragments」タグは、「NextFragmentsXMLURL」属性を含む。ライブ・ストリーミングのように、1つのコンテンツ・ストリーミングが完了すれば、次のコンテンツが続いてストリーミングされる場合には、次にストリーミングされるコンテンツについての情報をクライアント130があらかじめ知っていてこそ、途切れなしにコンテンツをストリーミングすることができる。従って、「Fragments」タグは、次にストリーミングされるコンテンツについての情報を、「NextFragmentsXMLURL」属性と定義する。次に、ストリーミングされるコンテンツに係わる複数のメディアデータのURLが「NextFragmentsXMLURL」属性と定義される。
【0059】
「Fragment」タグは、現在ストリーミングされるコンテンツの少なくとも1つの部分についての情報を含む。
図4Cに図示された実施形態を例に挙げて説明すれば、第1メディアデータとして、コンテンツを第1品質にエンコーディングして生成された最初の部分である「slice1−1.as」のURL情報が「URL」タグによって定義され、対応するヘッダの識別子が「RefPointer」タグによって定義される。また、最初の部分の開始時間が「StartTime」属性によって定義され、それぞれの部分の持続時間が「Duration」属性によって定義される。第1メディアデータの品質は、「BitRate」属性によって定義される。
【0060】
図4Cに図示された実施形態では、「Fragments」タグは、それぞれのメディアデータが1つの部分だけを含む場合を図示した。しかし、本発明が属する技術分野で当業者であるならば、
図1と関連して述べたように、それぞれのメディアデータが複数の部分に分割される場合、1つの「Fragments」タグが2以上の部分についての情報を含むことができることを容易に理解することが可能であろう。
【0061】
再び
図2Aを参照すれば、段階220でクライアント130は、複数のメディアデータのうち、少なくとも1つのメディアデータを伝送することをサーバ120に要請する。複数のメディアデータは、1つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータである。クライアント130は、複数のメディアデータのうちから、ストリーミング環境に適した品質に符号化された少なくとも1つのメディアデータを選択し、サーバ120に要請する。クライアント130は、コンテンツについての情報に含まれた複数のメディアデータについての情報に基づいて、HTTP要請をサーバ120に伝送することができる。
【0062】
コンテンツについての情報は、
図4Cと関連して述べたように、「Fragments」タグを含んでいる。従って、クライアント130は、「Fragments」タグに含まれたURL情報に基づいて選択されたメディアデータの伝送をサーバ120に要請する。
【0063】
クライアント120の要請によってサーバ120は、メディアデータを伝送する。要請されたメディアデータの少なくとも1つの部分をクライアント120に伝送することができる。HTTP要請に対するHTTP応答として要請されたメディアデータをクライアント120に伝送することができる。
【0064】
図2Bは、本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。
図2Bは、ヘッダがメディアデータと分離され、別途のファイルとして存在する場合のストリーミング方法を図示している。
【0065】
図2Bを参照すれば、段階212でクライアント130は、所定のコンテンツについての情報を伝送することをサーバ120に要請し、サーバ120からコンテンツについての情報を伝送する。
図2Aの段階210に図示される。
図4Bと関連して述べた「RefData」タグを含むコンテンツについての情報を受信する。
【0066】
段階222でクライアント130は、段階210で受信されたコンテンツについての情報に基づいて、複数のメディアデータのうち選択されたメディアデータのヘッダを要請する。段階212で受信されたコンテンツについての情報に基づいて、複数のメディアデータのうちストリーミング環境に適した少なくとも1つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階212で受信されたコンテンツについての情報に含まれた「RefData」タグを参照して選択されたメディアデータのヘッダを要請する。
【0067】
サーバ120は、要請されたメディアデータのヘッダをクライアント130に伝送する。ヘッダファイルをクライアント130に伝送することができ、ヘッダファイルは、XMLファイルであってもよい。
【0068】
段階232でクライアント130は、段階212で受信されたコンテンツについての情報及び段階222で受信されたヘッダに基づいて選択されたメディアデータの伝送を、サーバ120に要請する。メディアデータを時間に基づいて分割して生成された少なくとも1つの部分を伝送することをサーバ120に要請し、サーバ120は、要請された少なくとも1つの部分をクライアント130に伝送する。
【0069】
図5Aは、本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。
【0070】
図5Aを参照すれば、段階510でクライアント130は、所定のコンテンツについての情報を伝送することをサーバ120に要請し、サーバ120からコンテンツについての情報を伝送する。所定のコンテンツについての情報を伝送することを要請するHTTP要請をサーバ120に伝送し、これに対するHTTP応答として、コンテンツについての情報を受信する。コンテンツについての情報を含むXMLファイルを受信することができる。段階510で、クライアント130が受信するコンテンツについての情報は、
図2の段階210で、クライアント130が受信するコンテンツについての情報と異なるが、
図6及び
図7を参照して詳細に説明する。
【0071】
図6は、本発明の他の実施形態によるコンテンツについての情報を含むファイルのスキーマを図示している。
【0072】
図6を参照すれば、本発明の一実施形態によるコンテンツについての情報は、
図3と同一に、「Title」、「Synopsis」、「OriginSite」、「ContentURL」タグなどを含んでもよい。
【0073】
しかし、
図3に図示された実施形態では、コンテンツについての情報が、「Tracks」、「RefData」及び「Fragments」タグを含むことによって、複数のメディアデータについての情報も共に含むのに対し、
図6に図示された実施形態では、コンテンツについての情報が複数のメディアデータについての情報を含むのではなく、複数のメディアデータについての情報を含むファイル(以下、media presentation description:「メディア表現記述」とする)のURLのみ定義することが異なる。「ContentURL」タグによって、メディア表現記述のURLが定義される。
【0074】
図6に図示されたように、従来技術による多様なコンテンツについての情報ファイルのスキーマを大きく変更せずに、メディア表現記述のURLだけコンテンツについての情報ファイルに挿入することによって、多様なメディアデータ・フォーマットとの互換性を維持しつつ、ストリーミング環境に適応的なストリーミングが可能になる。
【0075】
図6に図示されたところによれば、コンテンツについての情報は、複数のメディアデータについての情報は含まず、ストリーミング方法と関連した情報だけ含んでもよい。言い換えれば、「ContentURL」タグは、ストリーミングに利用されるメディアデータのフォーマットを定義する「MediaFormat」属性、メディアデータの種類を定義する「MIMEType」属性などを含んでもよい。
【0076】
特に、「ContentURL」タグは、コンテンツのストリーミングがいなかるサービスと関連しているか定義する「TransferType」属性を含んでもよい。「TransferType」属性は、コンテンツのストリーミングがCoD(content on delivery)サービス、生中継(live)、適応ストリーミング生中継(adaptive streaming live)及び適応ストリーミングCoD(adaptive streaming CoD)のうち、いかなるサービスと関連しているのかを定義することができる。
【0077】
図7は、本発明の他の実施形態によるコンテンツについての情報を図示している。
図7は、OIPF標準によるCADであってもよい。
【0078】
図7を参照すれば、
図6に図示されたスキーマによって生成されたコンテンツについての情報は、「ContentURL」タグに、メディア表現記述のURLが定義される。「http://asexample.com/vod/movies/18888/Meta/MainMeta.xml」がメディア表現記述のURLである。また、
図6と関連して述べたように、「MediaFormat」属性、「MIMEType」属性及び「TransferType」属性などが「ContentURL」タグに定義される。
【0079】
再び
図5Aを参照すれば、段階520でクライアント130は、段階510で受信されたコンテンツについての情報に基づいて、複数のメディアデータについての情報をサーバ120に要請する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。
【0080】
段階510で、クライアント130がサーバ120から受信したコンテンツについての情報は、
図6及び
図7と関連して述べたように、メディア表現記述のURL情報を含むことができるが、クライアント130は、コンテンツについての情報の「ContentURL」タグを参照し、メディア表現記述をサーバ120に要請して受信する。メディア表現記述について、
図8A、
図8B、
図9Aないし
図9Hを参照して詳細に説明する。
【0081】
図8A及び
図8Bは、本発明の一実施形態によるメディア表現記述のスキーマを図示している。メディア表現記述は、OIPF標準によるメディア表現記述であってもよい。
【0082】
図8Aを参照すれば、本発明の一実施形態によるメディア表現記述は、複数のメディアデータのURLに係わるテンプレート(template)タグ、ヘッダの位置を定義するためのタグ、ストリーミングがいかなるサービスと関連しているかを定義するためのタグ、メディアデータコンテナ(container)・フォーマットを定義するためのタグ、及び複数のメディアデータを定義するためのタグを含む。
【0083】
「urlTemplate」タグは、複数のメディアデータに係わるURL情報の共通部分を定義する。例えば、「http://example.com/vod/movie/18888/Track/{TrackID}/Segments/{SegmentID}」がURLテンプレートであるならば、「TrackID」及び「SegmentID」に、複数のメディアデータそれぞれの識別子、及びそれぞれのメディアデータに含まれた少なくとも1つの部分の識別子を代入することにより、メディアデータに係わるURLを定義することができる。
【0084】
「headerUrl」タグは、
図4Bと関連して述べた「RefData」タグに対応する。言い換えれば、複数のメディアデータのヘッダURLを定義する。
【0085】
「islive」タグは、ストリーミングがいかなるサービスと関連しているかを定義するタグである。例えば、「islive」タグが「live」と定義されれば、ストリーミングが生放送サービスと関連していることを示し、「islive」タグが「CoD」と定義されれば、ストリーミングがCoDサービスと関連していることを示す。
【0086】
「contentType」タグは、ストリーミングに利用されるメディアデータのコンテナ・フォーマットを定義する。メディアデータのコンテナ・フォーマットがMP4フォーマットであるか、あるいはMPEG2−TSフォーマットであるか示すための情報であってもよい。本発明の詳細な説明では、メディアデータのコンテナ・フォーマットが、MP4フォーマットまたはMPEG2−TSフォーマットである場合を例に挙げて説明する。しかし、コンテナ・フォーマットは、これに限定されるものではなく、メディアデータの伝送のためのあらゆるコンテナ・フォーマットが本発明に適用されることは、本発明が属する技術分野で当業者であるならば、容易に分かるであろう。例えば、前記「contentType」タグは、メディアデータのコンテナ・フォーマットが、MMT(MPEG media transport)標準によるフォーマットであることを定義することもできる。
【0087】
「Stream」タグは、複数のメディアデータそれぞれについて生成され、複数のメディアデータそれぞれを定義する。1つのコンテンツを異なる品質にエンコーディングして生成された複数のメディアデータそれぞれを定義するために、「streamName」属性、「type」属性、「bitrate」属性、「startTime」属性、「firstIntervalNum」属性、「duration」属性及び「intervalCount」属性を含む。
【0088】
「streamName」属性は、メディアデータの名称を定義する。メディアデータの識別子であってもよい。「type」属性は、メディアデータの類型を定義する。メディアデータがオーディオデータ、ビデオデータ及びオーディオ/ビデオデータのうち、いかなるメディアのデータであるかを定義する。メディアデータが変速再生(trick play)のために、Iフレームについてのデータのみ含む場合には、これについての情報が「type」属性と定義される。
【0089】
「BitRate」属性は、メディアデータのビット率を定義し、「startTime」属性は、メディアデータの開始時間を特定するタイムスタンプを定義し、「firstIntervalNum」属性は、最初に始まる部分の番号を定義する。
【0090】
「duration」属性は、メディアデータに含まれた部分の持続時間を定義し、「intervalCount」属性は、メディアデータに含まれた少なくとも1つの部分の全体個数を定義する。
【0091】
「Segment」タグは、「Stream」タグの下位タグであり、メディアデータが述べたように、コンテンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分であるならば、このような少なくとも1つの部分それぞれを定義する。
【0092】
「IntNum」属性は、部分の番号を定義し、「StartTime」は、当該部分の開始時間を定義する。「Duration」は、当該部分の持続時間を定義し、「url」は、当該部分のURL情報を定義する。
【0093】
「Segment」タグは、選択的なタグであり、メディアデータに含まれた少なくとも1つの部分についての情報が、「Stream」タグの他の属性から類推できる場合には、メディア表現記述に含まれない。言い換えれば、「Stream」タグに定義された「startTime」、「firstIntervalNum」、「duration」及び「intervalCount」の属性によって「Segment」タグの内容が類推される場合には、メディア表現記述に含まれない。また、「urlTemplate」タグに所定のテンプレートが定義されており、このように定義されたテンプレートに、複数のメディアデータそれぞれの識別子及びそれぞれのメディアデータに含まれた少なくとも1つの部分の識別子を代入することにより、部分のURL情報を類推することができれば、「Segment」タグの「url」属性は、不要となる。
【0094】
しかし反対に、「Stream」タグの他の属性から「Segment」の属性が類推されない場合には、「Segment」の属性がそれぞれの部分について別途に定義される。部分の持続時間が異なる場合がこのようなケースに該当するが、持続時間が異なるならば、「Stream」タグの属性から、メディアデータに含まれた部分の持続時間を類推することができないので、「Segment」タグの「duration」属性を利用し、メディアデータの持続時間をそれぞれ設定することができる。部分の持続時間が異なることによって、連続した部分の開始も異なることになる。例えば、第1メディアデータの最初部分の持続時間と、2番目の部分の持続時間とが異なるならば、2番目の部分の開始時刻と、3番目の部分の開始時刻は、「Stream」タグから類推することができない。従って、それぞれの部分に係わる開始時刻も、「startTime」属性と定義することができる。
【0095】
「Segment」タグの「duration」属性及び「startTime」属性ではない、「Segment」タグの下位タグを利用し、持続時間及び/または開始時刻を定義することもできる。例えば、「Segment」タグの下位タグである「Url」タグを設定し、「Url」タグの属性として持続時間を定義できるが、「<Url=www.example.com/〜/segment.ts,duration=10/>のように、Urlタグの属性として持続時間を定義することができる。
【0096】
また、本発明の他の実施形態によれば、連続した部分の持続時間の差に基づいて、持続時間を定義することもできる。上位タグでデフォルト持続時間を定義し、下位タグである「Url」タグでは、デフォルト持続時間と、部分の実際持続時間との差だけそれぞれの部分について定義することができる。前述のように、「Segment」タグの下位タグである「Url」タグを、「<Url=www.example.com/〜/segment.ts,duration=difference/>」のように定義することができる。「difference」は、デフォルト持続時間と実際持続時間との差を意味する。
【0097】
「Stream」タグまたは「Segment」タグを利用し、当該部分のデフォルト持続時間を10分と定義し、下位タグである「Url」タグが、「<Url=www.example.com/〜/segment.ts,duration=2/>」と定義されたとすれば、当該部分の持続時間は、10+2=12分と定義することができる。
【0098】
図8Bを参照すれば、本発明の他の実施形態によるメディア表現記述は、「nextManifestURL」タグをさらに含んでもよい。前述のように、ライブ・ストリーミングまたは広告の挿入のように、1つのコンテンツ・ストリーミングが完了すれば、次のコンテンツが続いてストリーミングされる場合には、次にストリーミングされるコンテンツについての情報をクライアント130があらかじめ知っていてこそ、切れ目なくコンテンツをストリーミングすることができるので、現在ストリーミング中であるコンテンツの次にストリーミングされるコンテンツのメディア表現記述のURL情報が、「nextManifestURL」タグによって定義される。
【0099】
図9Aないし
図9Hは、本発明の一実施形態によるメディア表現記述を図示している。
【0100】
図9Aを参照すれば、本発明の一実施形態によるメディア表現記述は、「URLTemplate」タグ、「RefDataURL」タグ及び複数のメディアデータそれぞれを定義する複数のタグを含む。
【0101】
「URLTemplate」タグ及び「RefDataURL」タグは、それぞれ
図8A及び
図8Bの「urlTemplate」タグ及び「RefDataURL」タグに対応する。
【0102】
「ID」属性、「Type」属性、「BitRate」属性、「StartTime」属性、「SegmentDuration」属性、「SegmentStartID」属性及び「SegmentCount」属性は、それぞれ
図8A及び
図8Bの「streamName」属性、「type」属性、「bitrate」属性、「startTime」属性、「Stream」タグの「duration」属性、「Stream」タグの「firstIntervalNum」属性及び「intervalCount」属性に対応する。
【0103】
図9Aに図示されたメディア表現記述は、コンテンツを、異なる品質に生成された3種のビデオデータ、1つのオーディオデータ、及び変速再生のためにIフレームだけエンコーディングして生成されたメディアデータについての情報を含む。
【0104】
図9Bを参照すれば、本発明の一実施形態によるメディア表現記述は、「NextAdaptiveControlURL」タグをさらに含む。「NextAdaptiveControlURL」タグは、
図8Bの「nextManifestURL」タグに対応する。従って、現在再生中であるコンテンツの次に続いて再生するコンテンツのメディア表現記述のURLが「NextAdaptiveControlURL」タグによって定義される。
【0105】
図9Cは、現在再生中であるコンテンツに続いて再生するコンテンツのメディア表現記述のURLが、
図9Bの「NextAdaptiveControlURL」タグによって定義されたとき、次に続いて再生するコンテンツのメディア表現記述を図示する。
図9Bのメディア表現記述と比較すれば、
図9Cは、次に続いて再生されるコンテンツのメディア表現記述であるから、「StartTime」属性の現在再生中であるコンテンツのメディア表現記述と異なる。
【0106】
図9D及び
図9Eは、ユーザの高画質ビデオ再生を選択的に制御するためのメディア表現記述を図示している。1つのコンテンツを5種の異なる品質にエンコーディングして複数のメディアデータが生成され、
図9Dは、その場合のメディア表現記述を図示する。しかし、
図9Eに図示されたメディア表現記述で、高品質にエンコーディングされたビデオについての情報を含んでいるタグ、すなわち、「ID」属性が「5」であるメディアデータの「StartTime」属性及び「SegmentCount」属性が、
図9Dのメディア表現記述と異なる。
【0107】
サーバ120は、クライアント130のユーザ等級によって、
図9Dのメディア表現記述または
図9Eのメディア表現記述を選択的に伝送することができる。クライアント130のユーザ等級が高い場合(例えば、クライアント130が有料ユーザである場合)には、
図9Dのメディア表現記述を伝送することによって、高品質のビデオも自由に再生するようにし、クライアント130のユーザ等級が低い場合(例えば、クライアント130が無料ユーザである場合)には、
図9Eのメディア表現記述を伝送することによって、高品質のビデオは、「StartTime」属性によって定義された時間から、「SegmentCount」属性によって定義された部分だけ再生することができる。
【0108】
図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に伝送される。
【0109】
図9Gは、本発明の一実施形態による広告コンテンツについての情報を含むメディア表現記述を図示している。メインコンテンツを提供するサーバと、広告コンテンツを提供するサーバが異なることもある。言い換えれば、クライアント130が、メインコンテンツは、
図5Aのサーバ120から提供され、広告コンテンツは、
図5Aのサーバ120ではない他のサーバから受信する場合、広告コンテンツについての情報を含むメディア表現記述は、広告コンテンツのURL情報を含んでもよい。
図9Gに図示されたように、1つの品質に符号化された広告コンテンツのURL情報が、メディア表現記述に含まれてもよい。
【0110】
図9Hは、本発明の一実施形態による言語情報及び字幕情報を含むメディア表現記述を図示している。
図9Hを参照すれば、オーディオデータは、多重言語についての情報を含んでもよい。「ID」属性が「4」及び「5」である多重言語のオーディオデータについての情報が、メディア表現記述に含まれることができ、「ID」属性が「6」及び「7」である多重言語の字幕についての情報が、メディア表現記述に含まれてもよい。
【0111】
オーディオデータはもとより、字幕も、経時的に複数の部分に分割されるので、ストリーミング最中に、オーディオデータ及び字幕を異なる言語のオーディオデータ及び字幕に変更することができる。
【0112】
再び
図5Aを参照すれば、段階530でクライアント130は、複数のメディアデータのうち、少なくとも1つのメディアデータを伝送することをサーバ120に要請する。クライアント130は、複数のメディアデータについての情報を参照し、ストリーミング環境に適した品質に符号化された少なくとも1つのメディアデータを選択してサーバ120に要請する。クライアント130は、所定のメディアデータを伝送することを要請するHTTP要請を、サーバ120に伝送することができる。クライアント120の要請によってサーバ120は、メディアデータを伝送する。コンテンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を、クライアント120に伝送することができる。HTTP要請に対するHTTP応答として要請されたメディアデータを、クライアント120に伝送することができる。
【0113】
図5Bは、本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。
【0114】
図5Bを参照すれば、段階512でクライアント130は、所定のコンテンツについての情報を伝送することをサーバ120に要請し、サーバ120からコンテンツについての情報を伝送する。所定のコンテンツについての情報を伝送することを要請するHTTP要請をサーバ120に伝送し、これに対するHTTP応答として、コンテンツについての情報を受信する。コンテンツについての情報を含むXMLファイルを受信することができる。
【0115】
段階522でクライアント130は、段階512で受信されたコンテンツについての情報に基づいて、複数のメディアデータについての情報をサーバ120に要請する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。
【0116】
段階532でクライアント130は、段階522で受信された複数のメディアデータについての情報に基づいて選択されたメディアデータのヘッダを要請する。段階522で受信された情報に基づいて、複数のメディアデータのうちストリーミング環境に適した少なくとも1つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階522で、受信された複数のメディアデータについての情報を参照して選択されたメディアデータのヘッダを要請する。サーバ120は、要請に対する応答として、選択されたメディアデータのヘッダファイルをクライアント130に伝送する。
【0117】
段階542でクライアント130は、段階522で受信された複数のメディアデータについての情報、及び段階222で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ120に要請する。コンテンツを所定の比率でエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を伝送することをサーバ120に要請し、サーバ120は、要請された少なくとも1つの部分をクライアント130に伝送する。
【0118】
図10Aないし
図10Cは、本発明の一実施形態による複数のメディアデータを図示している。
図10Aないし
図10Cは、
図5A及び
図5Bによるストリーミング方法を遂行するために、サーバ120が保有する複数のメディアデータを図示する。
【0119】
図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つの部分である。
【0120】
またサーバ120は、クライアント130が複数のメディアデータにアクセスするために必要な情報1040を保有することができる。コンテンツについての情報として、「CadMeta.xml」ファイル、複数のメディアデータについての情報として、「MainMeta.xml」ファイルを保有することができ、複数のメディアデータのヘッダとして、「Head1.ref」、「Head2.ref」ファイルなどを保有することができる。「Head1.ref」は、「Track1」のヘッダファイルであって、「Head2.ref」は、「Track2」のヘッダファイルである。
【0121】
「CadMeta.xml」は、OIPF標準によるCADファイルであって、「MainMeta.xml」は、前述のメディア表現記述であってもよい。また、「Head1.ref」、「Head2.ref」ファイルは、選択的な要素であり、ヘッダが複数のメディアデータ1010ないし1030に含まれている場合には、存在しなくともよい。
【0122】
図10Bを参照すれば、クライアント130が、複数のメディアデータにアクセスするために必要な情報1042は、「NextMeta.xml」をさらに含んでもよい。前述のように、「NextMeta.xml」は、現在再生中であるコンテンツに続いて再生される次のコンテンツのメディア表現記述であってもよい。前述のように、現在再生中であるメディア表現記述、すなわち、「MainMeta.xml」ファイルは、続いて再生するコンテンツのメディア表現記述のURL情報を含んでいるが、これに基づいてクライアント130は、「NextMeta.xml」ファイルにアクセスすることができる。
【0123】
図10Cを参照すれば、複数のメディアデータのヘッダは、1つのファイル1050として存在しうる。ヘッダファイルが、複数のメディアデータそれぞれについて複数で存在するのではなく、1つのヘッダファイル1050として、複数のメディアデータにアクセスするために必要な情報1044に含まれる。
【0124】
例えば、複数のメディアデータそれぞれがエレメンタリーストリーム(例えば、MPEG−2によるエレメンタリーストリーム)に対応するとき、複数のメディアデータのヘッダは、PAT(program association table)及びPMT(program map table)のうち、少なくとも一つを含む1つのヘッダファイル1050であってもよい。PAT及びPMTのうち、少なくとも一つを複数のメディアデータ1010ないし1030と分離し、1つのヘッダファイル1050を作り、メディア表現記述は、このヘッダファイル1050を指示(pointing)する情報を含んでもよい。指示情報は、ヘッダファイル1050のURL情報でもあり、MPEG−2伝送ストリーム(transport stream)で、ヘッダファイル1050を含んでいるパケットを特定するための情報でもある。PAT及びPMTのうち、少なくとも一つを含むヘッダファイル1050は、初期化部分(initialization segment)であり、メディアデータの再生を開始するために、ペイロードデータを含んでいる部分より先にクライアント130に伝送することができる。
【0125】
前述の段階532でクライアント130は、メディア表現記述を参照し、ヘッダファイル1050に係わる指示情報を獲得し、指示情報に基づいて、ヘッダファイル1050を要請することができる。指示情報に基づいて、ヘッダファイル1050を要請して受信した後、ヘッダファイル1050に含まれているPAT及びPMTのうち、少なくとも一つに基づいて、複数のメディアデータのうち、少なくとも一つを選択し、選択されたメディアデータをサーバ120に要請する。PAT及びPMTは、ヘッダファイル1050に分離されてもおり、複数のメディアデータ1010ないし1030に含まれてもいるが、含まれた位置と関係なく、複数のメディアデータ1010ないし1030に含まれたエレメンタリーストリームの全体リストを含む。
【0126】
MPEG−2によれば、PAT及びPMTで定義されるPID(packet ID)は、エレメンタリーストリームによって異なる。従って、複数のメディアデータそれぞれに割り当てられるPIDは、異なっている。しかし、他の実施形態によれば、1つのココンテンツを異なる品質にエンコーディングして生成された複数のメディアデータは、同じコンテンツに係わるエレメンタリーストリームであるから、PIDが同一に設定されもする。
【0127】
複数のメディアデータ1010ないし1030が、MPEG−2による複数のエレメンタリーストリームに対応する場合、複数のメディアデータ1010ないし1030に含まれた部分それぞれは、少なくとも1つの連続したPES(packetized elementary stream)を含んでもよい。しかし、1つのPESは、1つの部分にのみ含まれる。言い換えれば、1つのPESが異なる部分に含まれない。
【0128】
複数のメディアデータは、1つのコンテンツを異なる品質にエンコーディングして生成されたものであるので、複数のメディアデータに含まれたPESのPTS(presentation time stamp)及び/またはDTS(decoding time stamp)は、メディアデータの再生時間によって整列される。言い換えれば、第1メディアデータの最初のPESと、第2メディアデータの最初のPESとが同じ時間に再生されるコンテンツであるならば、PTS及び/またはDTSが同一に設定される。
【0129】
また、第1メディアデータを再生している最中、再生されるメディアデータを変更し、第2メディアデータを再生する場合にも、連続して再生されるように、PTS及び/またはDTSも、連続して整列される。言い換えれば、第1メディアデータを再生していて、メディアデータを変更して第2メディアデータを再生する場合には、第1メディアデータの最後のPESのPTS及び/またはDTSと、第2メディアデータの最初のPESのPTS及び/またはDTSとが連続して設定される。
【0130】
前述のPTS及び/またはDTSは、ビデオデータのタイムスタンプを定義する。従って、ビデオデータに係わる複数のメディアデータのタイムスタンプは、前述のように、メディアデータの再生時間によって整列される。しかし、このような再生時間に基づいたタイムスタンプの整列は、オーディオデータについても同一に適用される。言い換えれば、オーディオデータに係わる複数のメディアデータのタイムスタンプも、ビデオデータに係わる複数のメディアデータと同様に、再生時間に基づいて適応的なストリーミングが可能なように再生時間によって整列されてもよい。
【0131】
図11Aは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。
【0132】
図11Aを参照すれば、段階1110でクライアント130は、複数のメディアデータについての情報をサーバ120に要請する。メディア表現記述をHTTP要請を介してサーバ120に要請し、HTTP応答としてメディア表現記述を受信することができる。クライアント130は、ストリーミング環境に適応的なストリーミングを遂行するために、1つのコンテンツを複数の異なる品質にエンコーディングして生成された複数のメディアデータについての情報をサーバ120に要請し、受信する。コンテンツについての情報の要請及び受信なしに、複数のメディアデータについての情報の要請及び受信が行われるという点が、
図5Aに図示された実施形態と異なる。
【0133】
段階1120でクライアント130は、複数のメディアデータのうち、少なくとも1つのメディアデータを伝送することをサーバ120に要請する。クライアント130は、複数のメディアデータについての情報を参照し、ストリーミング環境に適した品質に符号化された少なくとも1つのメディアデータを選択してサーバ120に要請し、要請されたメディアデータをサーバ120から受信する。
【0134】
図11Bは、本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。
【0135】
図11Bを参照すれば、段階1112でクライアント130は、複数のメディアデータについての情報をサーバ120に要請し、要請に対する応答として、複数のメディアデータについての情報をサーバ120から受信する。メディア表現記述を、HTTP要請を介してサーバ120に要請し、HTTP応答として、メディア表現記述を受信することができる。
【0136】
段階1122でクライアント130は、段階1112で受信された複数のメディアデータについての情報に基づいて選択されたメディアデータのヘッダを要請する。段階1112で受信された複数のメディアデータについての情報を参照し、ストリーミング環境によって選択されたメディアデータのヘッダを要請する。サーバ120は、要請に対する応答として、選択されたメディアデータのヘッダを含むファイルをクライアント130に伝送する。
【0137】
段階1132でクライアント130は、段階1112で受信された複数のメディアデータについての情報、及び段階1122で受信されたヘッダに基づいて選択されたメディアデータの伝送を、サーバ120に要請する。コンテンツを所定の比率でエンコーディングし、時間に基づいて分割して生成された少なくとも1つの部分を伝送することをサーバ120に要請し、サーバ120は、要請された少なくとも1つの部分をクライアント130に伝送する。
【0138】
図12Aないし
図12Cは、本発明の他の実施形態による複数のメディアデータを図示している。
図12A及び
図12Bは、
図11A及び
図11Bによるストリーミング方法を遂行するために、サーバ120が保有する複数のメディアデータを図示している。
【0139】
図12Aを参照すれば、
図10Aに図示された実施形態と同様に、ストリーミング環境に適応的なストリーミングのために、サーバ120は、1つのコンテンツを複数の異なる品質にエンコーディングして生成された複数のメディアデータ1010ないし1030を保有することができる。
【0140】
クライアント130が複数のメディアデータにアクセスするために必要な情報1240だけ異なるが、
図10Aに図示された実施形態とは異なってサーバ120は、コンテンツについての情報を除外した複数のメディアデータについての情報だけ含んでもよい。この場合、クライアント130は、コンテンツについての情報を、サーバ120ではない他のエンティテイから受信し、コンテンツについての情報に基づいて、サーバ120が保有している複数のメディアデータにアクセスすることもできる。
【0141】
図12Bを参照すれば、クライアント130が複数のメディアデータにアクセスするために必要な情報1242は、
図12Aの情報1240に「NextMeta.xml」をさらに含んでもよい。
【0142】
図12Cを参照すれば、複数のメディアデータのヘッダは、1つのファイル1250として存在しうる。ヘッダファイルが複数のメディアデータそれぞれについて複数で存在するのではなく、1つのヘッダファイル1250として、複数のメディアデータにアクセスするために必要な情報1244に含まれもする。ヘッダファイル1250は、
図10Cのヘッダファイル1050に対応する。
【0143】
図13は、本発明の一実施形態によるサーバのメディアデータ伝送装置を図示している。
【0144】
図13を参照すれば、本発明の一実施形態によるサーバ120のメディアデータ伝送装置1300は、情報伝送部1310及びメディアデータ伝送部1320を含む。
【0145】
情報伝送部1310は、クライアント130から所定情報の伝送要請を受信し、これに対する応答として、要請された情報を伝送する。コンテンツについての情報及び複数のメディアデータについての情報のうち、少なくとも1つの伝送要請をクライアント130から受信し、要請された情報をクライアント130に伝送する。
図2A、
図2B、
図5A、
図5B、
図11A及び
図11Bに図示された実施形態によって、コンテンツについての情報及び複数のメディアデータについての情報のうち、少なくとも1つの伝送を要請するHTTP要請をクライアント130から受信し、HTTP応答として、要請された情報を伝送する。
【0146】
メディアデータ伝送部1320は、複数のメディアデータのうち、ストリーミング環境によって選択された少なくとも1つのメディアデータの伝送要請を、クライアント130から受信し、要請されたメディアデータを、クライアント1320に伝送する。情報伝送部1310がクライアント130に伝送した複数のメディアデータについての情報に基づいて選択されたメディアデータの伝送要請を受信する。サーバ120は、エンコーディング装置110から、異なる品質にエンコーディングされた複数のメディアデータを受信して保有していて、要請されたメディアデータをクライアント130に伝送することもできる。また、クライアント130の伝送要請によって、リアルタイムで、エンコーディング装置110からメディアデータを受信し、クライアント130に伝達することもできる。
【0147】
図14は、本発明の一実施形態によるクライアントのメディアデータ受信装置を図示している。
【0148】
図14を参照すれば、本発明の一実施形態によるクライアント130のメディアデータ受信装置1400は、情報受信部1410及びメディアデータ受信部1420を含む。
【0149】
情報受信部1410は、所定情報の伝送要請をサーバ120に伝送し、これに対する応答として、要請された情報をサーバ120から受信する。コンテンツについての情報及び複数のメディアデータについての情報のうち、少なくとも1つの伝送要請をサーバ120に伝送し、要請された情報を受信する。
図2A、
図2B、
図5A、
図5B、
図11A及び
図11Bに図示された実施形態によって、コンテンツについての情報及び複数のメディアデータについての情報のうち、少なくとも1つの伝送を要請するHTTP要請をサーバ120に伝送し、HTTP応答として、要請された情報を受信する。
【0150】
メディアデータ受信部1420は、複数のメディアデータのうち、ストリーミング環境によって選択された少なくとも1つのメディアデータの伝送要請をサーバ120に伝送し、要請されたメディアデータをクライアント1320から受信する。情報受信部1410がサーバ120から受信した複数のメディアデータについての情報に基づいて、ストリーミング環境によって選択されたメディアデータの伝送要請を伝送する。
【0151】
以上のように、本発明は、たとえ限定された実施形態及び図面によって説明したにしても、本発明が、前記の実施形態に限定されるものではなく、本発明が属する分野で当業者であるならば、かような記載から多様な修正及び変形が可能であろう。従って、本発明の思想は、特許請求の範囲によってのみ把握されるものであり、それと均等であるか、あるいは等価的な変形は、いずれも本発明思想の範疇に属するものである。また、本発明によるシステムは、コンピュータで読み取り可能な記録媒体に、コンピュータで読み取り可能なコードとして具現することが可能である。
【0152】
例えば、本発明の例示的な実施形態によるサーバのストリーミング装置及びクライアントのストリーミング装置は、
図13及び
図14に図示されたような装置のそれぞれのユニットにカップリングされたバス、前記バスに結合された少なくとも1つのプロセッサを含んでもよい。また、命令、受信されたメッセージまたは生成されたメッセージを保存するために、前記バスに結合され、前述のような命令を遂行するための少なくとも1つのプロセッサにカップリングされたメモリを含んでもよい。
【0153】
また、コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータが保存されるあらゆる種類の記録装置を含む。記録媒体の例としては、ROM(read-only memory)、RAM(random-access memory)、CD−ROM、磁気テープ、フロッピーディスク(登録商標)、光データ保存装置などを含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードが保存されて実行される。