特許第5794998号(P5794998)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ サムスン エレクトロニクス カンパニー リミテッドの特許一覧

特許5794998適応的なストリーミング方法及びその装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5794998
(24)【登録日】2015年8月21日
(45)【発行日】2015年10月14日
(54)【発明の名称】適応的なストリーミング方法及びその装置
(51)【国際特許分類】
   H04N 7/173 20110101AFI20150928BHJP
   H04N 21/239 20110101ALI20150928BHJP
   H04N 21/442 20110101ALI20150928BHJP
   H04N 21/858 20110101ALI20150928BHJP
   G06F 13/00 20060101ALI20150928BHJP
【FI】
   H04N7/173 630
   H04N7/173 610Z
   H04N21/239
   H04N21/442
   H04N21/858
   G06F13/00 520B
【請求項の数】11
【全頁数】31
(21)【出願番号】特願2012-538765(P2012-538765)
(86)(22)【出願日】2010年11月12日
(65)【公表番号】特表2013-511197(P2013-511197A)
(43)【公表日】2013年3月28日
(86)【国際出願番号】KR2010008017
(87)【国際公開番号】WO2011059274
(87)【国際公開日】20110519
【審査請求日】2013年10月25日
(31)【優先権主張番号】61/260,906
(32)【優先日】2009年11月13日
(33)【優先権主張国】US
(31)【優先権主張番号】61/262,708
(32)【優先日】2009年11月19日
(33)【優先権主張国】US
(31)【優先権主張番号】61/267,131
(32)【優先日】2009年12月7日
(33)【優先権主張国】US
(31)【優先権主張番号】61/294,211
(32)【優先日】2010年1月12日
(33)【優先権主張国】US
(31)【優先権主張番号】61/303,778
(32)【優先日】2010年2月12日
(33)【優先権主張国】US
(31)【優先権主張番号】61/380,461
(32)【優先日】2010年9月7日
(33)【優先権主張国】US
(31)【優先権主張番号】61/380,489
(32)【優先日】2010年9月7日
(33)【優先権主張国】US
(31)【優先権主張番号】10-2010-0103722
(32)【優先日】2010年10月22日
(33)【優先権主張国】KR
【前置審査】
(73)【特許権者】
【識別番号】503447036
【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド
(74)【代理人】
【識別番号】100133400
【弁理士】
【氏名又は名称】阿部 達彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100154922
【弁理士】
【氏名又は名称】崔 允辰
(74)【代理人】
【識別番号】100140534
【弁理士】
【氏名又は名称】木内 敬二
(72)【発明者】
【氏名】ホ−ジン・ハ
(72)【発明者】
【氏名】オ−ホーン・クウォン
(72)【発明者】
【氏名】スン−ビン・イム
(72)【発明者】
【氏名】グアンファ・チャン
(72)【発明者】
【氏名】ジ−エウン・クム
【審査官】 松元 伸次
(56)【参考文献】
【文献】 特開2009−017345(JP,A)
【文献】 国際公開第2009/119394(WO,A1)
【文献】 特開2004−140654(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F13/00
H04N5/765
5/91
5/915
5/92
5/922
5/928−5/93
5/937−5/94
5/95−5/956
7/10
7/14−7/173
7/20−7/56
21/00−21/858
(57)【特許請求の範囲】
【請求項1】
複数のメディアデータを受信する方法において、
コンテンツをそれぞれ複数の互いに異なる品質を有するようにエンコーディングすることによって、発生する複数のメディアデータに関する情報を含むファイルをサーバから受信する段階と、
前記ファイルを用いて、前記複数のメディアデータのうち、少なくとも1つを受信する段階と、を含み、
前記複数のメディアデータそれぞれは、前記コンテンツ既定の品質を有するようにエンコーディングされ、時間に基づいて分割された結果、生成される複数のデータ部分のうち、少なくとも1つを含み、
前記ファイルは、前記複数のメディアデータのURL(uniform resource locator)情報に関するテンプレート情報を含み、
前記複数のメディアデータそれぞれのURL情報は、前記テンプレートの識別子を取り替ることで獲得され、前記ファイルは、前記複数のメディアデータのヘッダを指示する情報をさらに含み、前記複数のメディアデータは、複数のエレメンタリーストリームにそれぞれ対応し、記複数のメディアデータのヘッダは、前記複数のエレメンタリーストリームと関連したPAT(program association table)またはPMT(program map table)のうち、少なくとも一つを含むことを特徴とするメディアデータ受信方法。
【請求項2】
前記ファイルを受信する段階は、
前記ファイルの伝送を要請するHTTP(hypertext transfer protocol)要請メッセージを前記サーバに伝送し、前記伝送は、前記ファイルのURL情報を利用して遂行される段階と、
前記要請メッセージに対する応答として、前記ファイルを含むHTTP応答メッセージを、前記サーバから受信する段階と、を含むことを特徴とする請求項1に記載のメディアデータ受信方法。
【請求項3】
前記ファイルは、
前記複数のメディアデータのURLと関連したメディアデータのフォーマットに係わる情報を含むことを特徴とする請求項1に記載のメディアデータ受信方法。
【請求項4】
前記PAT及びPMTのうち少なくとも一つは、
前記複数のメディアデータ全体のリストを含むことを特徴とする請求項に記載のメディアデータ受信方法。
【請求項5】
前記複数のメディアデータは、それぞれ異なるPID(packetID)に割り当てられることを特徴とする請求項に記載のメディアデータ受信方法。
【請求項6】
前記複数のデータ部分のうち、前記少なくとも1つのデータ部分は、
少なくとも1つのPES(packetized elementary stream)を含むことを特徴とする請求項に記載のメディアデータ受信方法。
【請求項7】
前記複数のメディアデータは、それぞれのPTS(presentation time stamp)及びそれぞれのDTS(decoding time stamp)を含むPES(packetized elementary stream)から構成され、
前記それぞれのPTSと前記それぞれのDTSは、メディアデータの再生時間によって整列されることをさらに含むことを特徴とする請求項に記載のメディアデータ受信方法。
【請求項8】
メディアデータを伝送する方法において、
コンテンツをそれぞれ複数の互いに異なる品質を有するようにエンコーディングするによって、発生する複数のメディアデータについての情報を含むファイルをクライアント装置に伝送する段階と、
前記複数のメディアデータそれぞれは、前記コンテンツ既定の品質を有するようにエンコーディングされ、時間に基づいて分割された結果、生成される複数のデータ部分のうち、少なくとも1つを含み、
前記ファイルは、前記メディアデータのURL情報に関するテンプレート情報を含み、
前記メディアデータそれぞれのURL情報は、前記テンプレートの識別子を取り替えることで獲得され、前記ファイルは、前記複数のメディアデータのヘッダを指示する情報をさらに含み、前記複数のメディアデータは、複数のエレメンタリーストリームにそれぞれ対応し、記複数のメディアデータのヘッダは、前記複数のエレメンタリーストリームと関連したPAT(program association table)またはPMT(program map table)のうち、少なくとも一つを含むことを特徴とするメディアデータ伝送方法。
【請求項9】
メディアデータを受信する装置において、
コンテンツをそれぞれ複数の互いに異なる品質を有するようにエンコーディングするによって、発生する複数のメディアデータに関する情報を含むファイルをサーから受信する情報受信部と、
前記複数のメディアデータそれぞれは、前記コンテンツ既定の品質を有するようにエンコーディングされ、時間に基づいて分割された結果、生成される複数のデータ部分のうち、少なくとも1つを含み、
前記ファイルは、前記複数のメディアデータのURL情報に関するテンプレート情報を含み、
前記メディアデータそれぞれのURL情報は、前記テンプレートの識別子を取り替ることで獲得され、前記ファイルは、前記複数のメディアデータのヘッダを指示する情報をさらに含み、前記複数のメディアデータは、複数のエレメンタリーストリームにそれぞれ対応し、記複数のメディアデータのヘッダは、前記複数のエレメンタリーストリームと関連したPAT(program association table)またはPMT(program map table)のうち、少なくとも一つを含むことを特徴とするメディアデータ受信装置。
【請求項10】
メディアデータを伝送する装置において、
コンテンツをそれぞれ複数の互いに異なる品質を有するようにエンコーディングするによって、発生する複数のメディアデータについての情報を含むファイルをクライアントに伝送する情報伝送部と、
前記クライアントの要請によって、前記複数のメディアデータのうち、少なくとも1つのメディアデータを、前記クライアントに伝送するように構成されるメディアデータ伝送部と、を含み、
前記複数のメディアデータそれぞれは、前記コンテンツ既定の品質を有するようにエンコーディングされ、時間に基づいて分割された結果、生成される複数のデータ部分のうち、少なくとも1つを含み、
前記ファイルは、前記メディアデータのURL情報に関するテンプレート情報を含み、
前記複数のメディアデータそれぞれのURL情報は、前記テンプレートの識別子を取り替ることで獲得され、前記ファイルは、前記複数のメディアデータのヘッダを指示する情報をさらに含み、前記複数のメディアデータは、複数のエレメンタリーストリームにそれぞれ対応し、記複数のメディアデータのヘッダは、前記複数のエレメンタリーストリームと関連したPAT(program association table)またはPMT(program map table)のうち、少なくとも一つを含むことを特徴とするメディアデータ伝送装置。
【請求項11】
請求項1ないし請求項のうち、いずれか1項に記載の方法を実行するためのプログラムを記録したコンピュータで読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ストリーミング方法及びその装置に係り、さらに詳細には、ストリーミング環境の変動(fluctuation)によって、適応的にメディアデータをストリーミングする方法及びその装置に関する。
【背景技術】
【0002】
ネットワークを介してメディアデータを伝送する方式には、ダウンロード方式とストリーミング方式とがある。ストリーミング方式は、サーバがリアルタイムでメディアデータを伝送し、クライアントは、受信されたメディアデータをリアルタイムで再生する方式である。
【0003】
ストリーミング方式は、メディアデータをいずれも送受信した後、メディアデータの再生が始まるダウンロード方式とは異なり、ストリーミング方式によれば、サーバとクライアントとの間に設定された論理的なチャネルを介して、リアルタイムでメディアデータが送受信され、再生されるためにストリーミング環境の変動を反映し、メディアデータ再生のQoS(quality of service)を維持することができる方法及びその装置が必要である。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明が解決しようとする技術的課題は、ストリーミング、すなわち、メディアデータの伝送及び受信を、ストリーミング環境によって適応的に調節して遂行する方法及びその装置を提供するところにあり、前記方法を実行するためのプログラムを記録したコンピュータで読み取り可能な記録媒体を提供するところにある。
【課題を解決するための手段】
【0005】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを受信する方法は、所定のコンテンツについての情報を含む第1ファイルをサーバから受信する段階と、前記コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含む第2ファイルを、前記第1ファイルに基づいてサーバから受信する段階と、前記第2ファイルに基づいて、前記複数のメディアデータのうち少なくとも1つのメディアデータを受信する段階と、を含み、前記第1ファイルは、前記第2ファイルの位置についての情報を含む。
【0006】
本発明の他の実施形態によれば、前記第2ファイルの位置についての情報は、前記第2ファイルのURL(uniform resource locator)情報であることを特徴とする。
【0007】
本発明のさらに他の実施形態によれば、前記第2ファイルを、前記第1ファイルに基づいてサーバから受信する段階は、前記第2ファイルのURL情報に基づいて、前記第2ファイルの伝送を要請するHTTP(hypertext transfer protocol)要請メッセージを、前記サーバに伝送する段階と、前記要請メッセージに対する応答として、前記第2ファイルを含むHTTP応答メッセージを、前記サーバから受信する段階を含む。
【0008】
本発明のさらに他の実施形態によれば、前記複数のメディアデータは、前記コンテンツを所定品質にエンコーディングし、時間に基づいて分割して生成された複数のデータ部分のうち少なくとも一つをそれぞれ含む。
【0009】
本発明のさらに他の実施形態によれば、前記第2ファイルは、前記複数のデータ部分のURLに係わるテンプレート(template)及びメディアデータのフォーマットのうち少なくとも一つに係わる情報を含む。
【0010】
本発明のさらに他の実施形態によれば、前記第2ファイルは、前記複数のメディアデータのヘッダを指示する情報をさらに含む。
【0011】
本発明のさらに他の実施形態によれば、前記複数のメディアデータは、複数のエレメンタリーストリームにそれぞれ対応し、前記複数のメディアデータのヘッダは、前記複数のエレメンタリーストリームに係わるPAT(program association table)及びPMT(program map table)のうち少なくとも一つを含む。
【0012】
本発明のさらに他の実施形態によれば、前記PAT及びPMTのうち少なくとも一つは、前記複数のメディアデータの全体リストを含む。
【0013】
本発明のさらに他の実施形態によれば、前記複数のメディアデータは、PID(packet ID)が異なることを特徴とする。
【0014】
本発明のさらに他の実施形態によれば、前記少なくとも1つのデータ部分は、少なくとも1つのPES(packetized elementary stream)を含むことを特徴とする。
【0015】
本発明のさらに他の実施形態によれば、前記複数のメディアデータのうち互いに異なるメディアデータに含まれたPESのPTS(presentation time stamp)及びDTS(decoding time stamp)は、メディアデータの再生時間によって整列(aligned)されることを特徴とする。
【0016】
本発明のさらに他の実施形態によれば、前記第2ファイルは、前記コンテンツ後に受信するコンテンツを異なる品質にエンコーディングして生成されたさらに他の複数のメディアデータについての情報を含む第3ファイルについての情報をさらに含む。
【0017】
本発明のさらに他の実施形態によれば、前記第2ファイルは、前記複数のメディアデータそれぞれに係わるメディアデータの名称、類型、品質及びタイムスタンプのうち、少なくとも一つに係わる情報を含む。
【0018】
本発明のさらに他の実施形態によれば、前記第2ファイルは、前記複数のメディアデータのうち、少なくとも一つを受信するユーザの等級によって異なることを特徴とする。
【0019】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを伝送する方法は、所定コンテンツについての情報を含む第1ファイルをクライアントに伝送する段階と、前記第1ファイルに基づいた前記クライアントの要請によって伝送する前記コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含む第2ファイルを、前記クライアントに伝送する段階と、前記第2ファイルに基づいたクライアントの要請によって、前記複数のメディアデータのうち少なくとも1つのメディアデータを、前記クライアントに伝送する段階と、を含み、前記第1ファイルは、前記第2ファイルの位置についての情報を含む。
【0020】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを受信する装置は、所定コンテンツについての情報を含む第1ファイルをサーバから受信し、前記コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含む第2ファイルを、前記第1ファイルに基づいてサーバから受信する情報受信部と、前記第2ファイルに基づいて、前記複数のメディアデータのうち少なくとも1つのメディアデータを受信するメディアデータ受信部と、を含み、前記第1ファイルは、前記第2ファイルの位置についての情報を含む。
【0021】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを伝送する装置は、所定コンテンツについての情報を含む第1ファイルをクライアントに伝送し、前記第1ファイルに基づいた前記クライアントの要請によって伝送する前記コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含む第2ファイルを、前記クライアントに伝送する情報伝送部と、前記第2ファイルに基づいたクライアントの要請によって、前記複数のメディアデータのうち少なくとも1つのメディアデータを、前記クライアントに伝送するメディアデータ伝送部と、を含み、前記第1ファイルは、前記第2ファイルの位置についての情報を含む。
【0022】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを受信する方法は、所定コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルをサーバから受信する段階と、前記受信されたファイルに基づいて、前記複数のメディアデータのうち少なくとも少なくとも1つのメディアデータを受信する段階と、を含み、前記ファイルは、前記複数のメディアデータそれぞれに係わるメディアデータの名称、類型、品質及びタイムスタンプのうち、少なくとも一つを含む。
【0023】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを伝送する方法は、所定コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルを、前記クライアントに伝送する段階と、前記伝送されたファイルに基づいたクライアントの要請によって、前記複数のメディアデータのうち少なくとも1つのメディアデータを、前記クライアントに伝送する段階と、を含み、前記ファイルは、前記複数のメディアデータそれぞれに係わるメディアデータの名称、類型、品質及びタイムスタンプのうち、少なくとも一つを含む。
【0024】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを受信する装置は、所定コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルを、サーバから受信する情報受信部と、前記受信されたファイルに基づいて、前記複数のメディアデータのうち少なくとも少なくとも1つのメディアデータを受信するメディアデータ受信部と、を含み、前記ファイルは、前記複数のメディアデータそれぞれに係わるメディアデータの名称、類型、品質及びタイムスタンプのうち、少なくとも一つを含む。
【0025】
前記技術的課題を解決するための本発明の一実施形態によるメディアデータを伝送する装置は、所定コンテンツを異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むファイルを、前記クライアントに伝送する情報伝送部と、前記伝送されたファイルに基づいたクライアントの要請によって、前記複数のメディアデータのうち少なくとも1つのメディアデータを、前記クライアントに伝送するメディアデータ伝送部と、を含み、前記ファイルは、前記複数のメディアデータそれぞれに係わるメディアデータの名称、類型、品質及びタイムスタンプのうち、少なくとも一つを含む。
【0026】
本発明による一実施形態は、前記のメディアデータ受信方法及びメディアデータ伝送方法を実行するためのプログラムを記録したコンピュータで読み取り可能な記録媒体を提供する。
【発明の効果】
【0027】
本発明によれば、サーバ及び/またはクライアントの構成を変更せずに、既存のプロトコルを利用したストリーミング環境による適応的なストリーミングが可能になり、低コストで多様なメディアデータ・フォーマットに互換される適応的なストリーミング・システム構築が可能になる。
【図面の簡単な説明】
【0028】
図1】本発明の一実施形態によるストリーミング・システムを図示する図面である。
図2A】本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。
図2B】本発明の一実施形態によるストリーミング方法について説明するためのフローチャートである。
図3】本発明の一実施形態によるコンテンツについての情報を含むファイルのスキーマ(schema)を図示する図面である。
図4A】本発明の一実施形態による複数のメディアデータを定義するための情報を図示する図面である。
図4B】本発明の一実施形態によるメディアデータのヘッダについての情報を図示する図面である。
図4C】本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも1つの部分についての情報を図示する図面である。
図5A】本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。
図5B】本発明の他の実施形態によるストリーミング方法について説明するためのフローチャートである。
図6】本発明の他の実施形態によるコンテンツについての情報を含むファイルのスキーマを図示する図面である。
図7】本発明の他の実施形態によるコンテンツについての情報を図示する図面である。
図8A】本発明の一実施形態によるメディア表現記述のスキーマを図示する図面である。
図8B】本発明の一実施形態によるメディア表現記述のスキーマを図示する図面である。
図9A】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9B】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9C】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9D】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9E】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9F】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9G】本発明の一実施形態によるメディア表現記述を図示する図面である。
図9H】本発明の一実施形態によるメディア表現記述を図示する図面である。
図10A】本発明の一実施形態による複数のメディアデータを図示する図面である。
図10B】本発明の一実施形態による複数のメディアデータを図示する図面である。
図10C】本発明の一実施形態による複数のメディアデータを図示する図面である。
図11A】本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。
図11B】本発明のさらに他の実施形態によるストリーミング方法について説明するためのフローチャートである。
図12A】本発明の他の実施形態による複数のメディアデータを図示する図面である。
図12B】本発明の他の実施形態による複数のメディアデータを図示する図面である。
図12C】本発明の他の実施形態による複数のメディアデータを図示する図面である。
図13】本発明の一実施形態によるサーバのメディアデータ伝送装置を図示する図面である。
図14】本発明の一実施形態によるクライアントのメディアデータ受信装置を図示する図面である。
【発明を実施するための形態】
【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、磁気テープ、フロッピーディスク(登録商標)、光データ保存装置などを含む。また、コンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードが保存されて実行される。
【符号の説明】
【0154】
100 ストリーミング・システム
110 エンコーディング装置
120 サーバ
130、140 クライアント
1010、1030 メディアデー
1050、1250 ヘッダファイル
1240、1242、1040、1044 情報
1300 メディアデータ伝送装置
1310 情報伝送部
1320 メディアデータ伝送部
1400 メディアデータ受信装置
1410 情報受信部
1420 メディアデータ
図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
図1