データ伝送方法及び装置
コンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータについての情報に基づいて、ストリーミング環境に適応的なストリーミングを行う方法及び装置を開示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データの伝送／受信方法及び装置に係り、特に、メディアデータに含まれたコンポーネントについての情報を用いてデータを伝送／受信する方法及び装置に関する。
【背景技術】
【０００２】
ネットワークを通じてメディアデータを伝送する方式には、ダウンロード方式とストリーミング方式とがある。ストリーミング方式は、サーバがリアルタイムでメディアデータを伝送し、クライアントは、受信されたメディアデータをリアルタイムで再生する方式である。
【０００３】
メディアデータは、複数のコンポーネントを含むことが一般的である。サーバは、複数のコンポーネントの組み合わせに該当する複数のメディアデータを保存し、ユーザがこれらのうち一つを要請すれば、要請されたメディアデータを伝送する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前記の問題点を解決するための本発明の目的は、データを伝送及び受信する方法を提供することであり、特に、メディアデータに含まれたコンポーネントについての情報を共に伝送するデータ伝送方法及び装置を提供することである。
【課題を解決するための手段】
【０００５】
前記の目的を達成するための本発明の一実施形態が持つ一つの特徴は、少なくとも一つのコンポーネントを含む第１メディアデータについての情報を獲得する段階と、前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得する段階と、を含み、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことである。
【０００６】
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報を含み、前記コンポーネント情報は、前記第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含む。
【０００７】
前記コンポーネント情報は、前記少なくとも一つのコンポーネントの識別情報をさらに含む。
【０００８】
前記コンポーネント情報は、前記第１メディアデータに含まれたビデオコンポーネントについてのカメラ角度情報をさらに含む。
【０００９】
前記コンポーネント情報は、前記第１メディアデータに含まれたオーディオコンポーネントについてのチャネル情報及び言語コード情報のうち少なくとも一つをさらに含む。
【００１０】
前記コンポーネント情報は、前記第１メディアデータに含まれたサブタイトルコンポーネントについての言語情報をさらに含む。
【００１１】
前記第１メディアデータ情報は、前記第１メディアデータと前記第２メディアデータとが、同じコンデンツをエンコーディングして生成されたコンポーネントを含むかどうかを表す情報をさらに含む。
【００１２】
前記第１メディアデータについての情報を獲得する段階は、所定のコンデンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイルから、前記第１メディアデータについての情報を獲得する段階を含む。
【００１３】
本発明の他の実施形態が持つ一つの特徴は、サーバにより少なくとも一つのコンポーネントを含む第１メディアデータについての情報を生成する段階と、サーバにより前記第１メディアデータについての情報を伝送する段階と、前記伝送に対応する要請に基づいて、サーバにより前記少なくとも一つのコンポーネントを伝送する段階と、を含み、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含む。
【００１４】
本発明の他の実施形態が持つ一つの特徴は、マルチメディアデータを構成する少なくとも一つのコンポーネントが含まれた第１メディアデータについての情報を獲得する情報獲得部と、前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得するコンポーネント獲得部と、を備え、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことである。
【００１５】
本発明の他の実施形態が持つ一つの特徴は、少なくとも一つのコンポーネントが含まれた第１メディアデータについての情報を生成する情報生成部と、前記第１メディアデータについての情報を伝送する情報伝送部と、前記伝送に対応する要請に基づいて、前記少なくとも一つのコンポーネントを伝送するコンポーネント伝送部と、を備え、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことである。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態によるストリーミングシステムを示す図面である。
【図２Ａ】本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。
【図２Ｂ】本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。
【図３】本発明の一実施形態によるコンデンツ情報を含むファイルのスキーマ（ｓｃｈｅｍａ）を示す図面である。
【図４Ａ】本発明の一実施形態による複数のメディアデータを定義するための情報を示す図面である。
【図４Ｂ】本発明の一実施形態によるメディアデータのヘッダについての情報を示す図面である。
【図４Ｃ】本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも一つの部分についての情報を含む図面である。
【図５Ａ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図５Ｂ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図６】本発明のさらに他の実施形態によるコンデンツ情報を含むファイルのスキーマを示す図面である。
【図７】本発明のさらに他の実施形態によるコンデンツ情報を示す図面である。
【図８Ａ】本発明の一実施形態によるメディア表現技術のスキーマを示す図面である。
【図８Ｂ】本発明の一実施形態によるメディア表現技術のスキーマを示す図面である。
【図９Ａ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｂ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｃ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｄ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｅ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｆ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｇ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｈ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図１０Ａ】本発明の一実施形態による複数のメディアデータを示す図面である。
【図１０Ｂ】本発明の一実施形態による複数のメディアデータを示す図面である。
【図１０Ｃ】本発明の一実施形態による複数のメディアデータを示す図面である。
【図１１Ａ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図１１Ｂ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図１２Ａ】本発明のさらに他の実施形態による複数のメディアデータを示す図面である。
【図１２Ｂ】本発明のさらに他の実施形態による複数のメディアデータを示す図面である。
【図１２Ｃ】本発明のさらに他の実施形態による複数のメディアデータを示す図面である。
【図１３】本発明の一実施形態によるデータ伝送システムの動作方法についてのフローチャートである。
【図１４】本発明の一実施形態によるコンポーネント情報についての一例を示す図面である。
【図１５】本発明の一実施形態によるメディアデータについての情報についての一例を示す図面である。
【図１６】本発明の他の実施形態によるコンポーネント情報についての一例を示す図面である。
【図１７】本発明の他の実施形態によるメディアデータについての情報についての一例を示す図面である。
【図１８】本発明のさらに他の実施形態によるメディアデータについての情報についての一例を示す図面である。
【図１９】本発明の一実施形態によるデータ伝送装置１９００についてのブロック図である。
【図２０】本発明の一実施形態によるデータ受信装置２０００についてのブロック図である。
【図２１】本発明の他の実施形態によるデータ受信方法についてのフローチャートである。
【発明を実施するための形態】
【００１７】
まず、説明の便宜上、本明細書で使われる用語を簡単に定義する。
【００１８】
コンテンツの一例は、オーディオ情報、ビデオ情報、オーディオ−ビデオ情報及びデータを含む。コンテンツアイテム（Ｃｏｎｔｅｎｔ Ｉｔｅｍ）は、後述する複数のコンポーネントで構成される。
【００１９】
コンポーネント（Ｃｏｍｐｏｎｅｎｔ）は、オーディオ情報、ビデオ情報、サブタイトル情報などのコンテンツアイテムの成分である。一例として、コンポーネントは、特定言語で作成されたサブタイトルストリームや、特定カメラアングルで獲得したビデオストリームでありうる。コンポーネントは、コンテナによってトラックや基本ストリーム（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ、ＥＳ）とも称する。
【００２０】
コンテンツリソースは、コンテンツアイテムに対する適応的なストリーミングを可能にするために、複数のリフリゼンテーションから提供されるコンテンツアイテムである（例えば、多様な品質、ビットレート、角度）。サービス検索過程は、コンテンツリソースとも称する。コンテンツリソースは、一つ以上の連続的なタイムのピリオドで構成される。
【００２１】
ピリオドは、コンテンツリソースの時間的なセクションである。
【００２２】
リフリゼンテーションは、ピリオド内のコンテンツリソースのバージョン（あらゆるコンポーネントまたは一部コンポーネント）である。リフリゼンテーションは、コンポーネントのサブセットが異なるか、またはコンポーネントのエンコーディングパラメータ（例えば、ビットレート）が異なる。本明細書では、リフリゼンテーションをメディアデータと称するが、一つ以上のコンポーネントを含むデータを称するいかなる用語でも使われる。
【００２３】
セグメントは、特定システムレイヤー形式（ＴＳまたはＭＰ４）で唯一のＵＲＬを通じて称されるリフリゼンテーションの時間的なセクションを意味する。
【００２４】
以下では、図面を参照して本発明の実施形態を詳細に説明する。
【００２５】
図１は、本発明の一実施形態によるストリーミングシステムを図示する。
【００２６】
図１を参照すれば、本発明の一実施形態によるストリーミングシステム１００は、エンコーディング装置１１０、サーバ１２０及びクライアント１３０を備える。
【００２７】
エンコーディング装置１１０は、入力されたコンデンツを複数の相異なる品質にエンコーディングして、一つのコンデンツに対する複数のメディアデータを生成する。サーバ１２０がクライアント１３０にメディアデータをストリーミングする時、ストリーミング環境は変更される。例えば、ストリーミングのためのネットワーク１４０帯域幅が変更されてもよく、メディアデータを伝送するためにサーバ１２０の使用可能なハードウェア資源、またはメディアデータを受信するためにクライアント１３０の使用可能なハードウェア資源が変更されてもよい。
【００２８】
したがって、エンコーディング装置１１０は、流動的なストリーミング環境による適応的なストリーミングのために、一つのコンデンツを複数の相異なる品質にエンコーディングする。ビット率、サンプリング周波数または解像度などの因子を調節することで、一つのコンデンツを複数の相異なる品質にエンコーディングできる。例えば、一つの動映像コンデンツを相異なる解像度でエンコーディングして、５００Ｋｂｐｓ、１０００Ｋｂｐｓ及び２０００Ｋｂｐｓの複数のメディアデータを生成できる。
【００２９】
相異なる品質にエンコーディングされた複数のメディアデータはサーバ１２０に伝送され、この時、コンデンツ情報及び複数のメディアデータそれぞれについての情報も共にサーバ１２０に伝送される。コンデンツ情報は、コンデンツのメタデータであり、コンデンツのタイトル（ｔｉｔｌｅ）、シノプシス（ｓｙｎｏｐｓｉｓ）、コンデンツ識別子（Ｃｏｎｔｅｎｔ ＩＤ）、コンデンツＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などの情報を含む。複数のメディアデータについての情報は、それぞれのメディアデータの品質、類型及び識別子などを含むところ、これについては、図４Ａないし図４Ｃを参照して詳細に説明する。
【００３０】
クライアント１４０は、コンデンツ情報及び複数のメディアデータについての情報のうち少なくとも一つを受信し、これに基づいて、サーバ１２０に複数のメディアデータのうち少なくとも一つのメディアデータを要請する。クライアント１３０は、ストリーミング環境を推定（ｅｓｔｉｍａｔｉｏｎ）し、推定されたストリーミング環境に基づいて複数のメディアデータのうち少なくとも一つのメディアデータを選択する。推定されたストリーミング環境で適宜なＱｏＳを維持できる少なくとも一つのメディアデータを選択する。次いで、クライアント１３０は、選択された少なくとも一つのメディアデータの伝送を要請するＨＴＴＰ要請（ｒｅｑｕｅｓｔ）をサーバ１２０に伝送できる。
【００３１】
ストリーミング環境が劣化して高品質のメディアデータを受信すれば、メディアデータを再生し続けることができない場合には、複数のメディアデータのうち低い品質のメディアデータを要請し、ストリーミング環境が改善されて高品質のメディアデータを受信しても、メディアデータを再生し続けることができる場合には、複数のメディアデータのうち高品質のメディアデータを要請できる。
【００３２】
所定のメディアデータの受信中に他のメディアデータの伝送をサーバ１２０に要請してもよい。例えば、ストリーミング環境が劣化した状態で低い品質の第１メディアデータを要請して受信しているクライアント１３０は、ストリーミング環境が改善されるにつれてさらに高品質の第２メディアデータの伝送を、サーバ１２０に要請できる。従来技術によるストリーミング方法によれば、サーバ１２０とクライアント１３０とがストリーミングチャネルを最初に設定する時、品質を一度設定すれば、同じ品質でメディアデータを送受信し続けねばならない。しかし、本願発明によれば、クライアント１３０が低い品質の第１メディアデータの受信中にも同じコンデンツに対するさらに高品質の第２メディアデータを再び要請することができて、ストリーミング環境による適応的なストリーミングが可能になる。
【００３３】
ネットワーク１４０の帯域幅及びサーバ１２０またはクライアント１３０の使用可能なハードウェア資源に基づいてストリーミング環境を推定する多様な方法が、クライアント１３０のストリーミング環境の推定に利用できる。例えば、クライアント１３０は、受信されるメディアデータのタイムスタンプ及びＢＥＲ（Ｂｉｔ Ｅｒｒｏｒ Ｒａｔｅ）に基づいてストリーミング環境を推定できる。受信されるメディアデータのタイムスタンプを確認して、メディアデータが再生速度より遅い速度で受信されていれば、ストリーミング環境が劣化していると判断できる。また、受信されるメディアデータのＢＥＲが高くなってストリーミング環境が劣化していると判断できる。
【００３４】
クライアント１３０がストリーミング環境によって複数のメディアデータのうち少なくとも一つのメディアデータの伝送を要請すれば、サーバ１２０は、要請されたメディアデータをクライアント１３０に伝送する。ＨＴＴＰ要請に対するＨＴＴＰ応答として、要請されたメディアデータをクライアント１３０に伝送できる。
【００３５】
複数のメディアデータそれぞれは、コンデンツを相異なる品質にエンコーディングし、分割して生成された複数の部分のうち少なくとも一つを含む。言い換えれば、エンコーディング装置１１０のエンコーディング結果、生成された複数のメディアデータそれぞれは、時間に基づいて分割された少なくとも一つの部分をそれぞれ含む。サーバ１２０は、コンデンツを一つのストリームにエンコーディングして連続して伝送するものではなく、複数の部分に分割してそれぞれ伝送する。コンデンツを１０秒または２０秒などの所定の時間単位でコンデンツを分割して、複数の部分を生成できる。分割の基礎になる時間は、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）に基づいて設定される。一つまたは二つ以上のＧＯＰのピクチャーに対応するメディアデータを一つの部分に設定できる。
【００３６】
例えば、２種の品質でコンデンツがストリーミングされる場合、第１メディアデータは、コンデンツを第１品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分を含むことができ、第２メディアデータは、コンデンツを第２品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分を含む。
【００３７】
複数のメディアデータを時間に基づいてそれぞれ分割することで、前述した適応的なストリーミングが可能になる。例えば、ストリーミングが始まれば、サーバ１２０は、品質が低い第１メディアデータの０秒〜２０秒に該当する部分を伝送する。次いで、２０秒以後にストリーミング環境が改善されたと判断されて、クライアント１３０がさらに高品質のメディアデータを要請すれば、サーバ１２０は、さらに品質の高い第２メディアデータの２０秒〜４０秒に該当する部分を伝送できる。メディアデータが時間に基づいて複数の部分に分割されているため、ストリーミング途中でもストリーミング環境によって異なるメディアデータの部分を伝送できる。
【００３８】
図２Ａは、本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。
【００３９】
図２Ａを参照すれば、段階２１０で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請する。クライアント１３０のユーザが、クライアント１３０の画面に表示されたユーザインターフェースから所定のコンデンツを選択すれば、選択されたコンデンツ情報の伝送をサーバ１２０に要請する。クライアント１３０は、コンデンツ情報の伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送できる。
【００４０】
クライアント１３０から要請を受信したサーバ１２０は、クライアント１３０にコンデンツ情報を伝送する。ＨＴＴＰ要請に対するＨＴＴＰ応答として、コンデンツ情報をクライアント１３０に伝送できる。コンデンツ情報は、ＯＩＰＦ（Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ）標準によるＣＡＤ（Ｃｏｎｔｅｎｔ Ａｃｃｅｓｓ Ｄｅｓｃｒｉｐｔｏｒ）でありうる。図３を参照して詳細に説明する。
【００４１】
図３は、本発明の一実施形態によるコンデンツ情報を含むファイルのスキーマを図示する。コンデンツ情報を含むファイルは、ＣＡＤであり、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルでありうる。以下、本発明の詳細な説明ではタグ（ｔａｇ）及び属性（ａｔｔｒｉｂｕｔｅ）を区分して説明するが、本発明の詳細な説明でタグにより定義される項目を、タグではない属性により定義するか、本発明の詳細な説明で属性により定義される項目を、属性ではないタグにより定義するということは、当業者ならば容易に理解できる。
【００４２】
図３を参照すれば、コンデンツ情報は“Ｔｉｔｌｅ”、“Ｓｙｎｏｐｓｉｓ”、“ＯｒｉｇｉｎＳｉｔｅ”、“ＣｏｎｔｅｎｔＵＲＬ”タグなどを含む。
【００４３】
従来技術によるメディアデータのストリーミングは、一つのコンデンツを所定の品質にエンコーディングして一つのメディアデータを生成するので、従来技術によるコンデンツ情報（特に、ＯＩＰＦによるＣＡＤ）は、コンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含んでいない。
【００４４】
しかし、本発明の一実施形態によるコンデンツ情報は、一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むところ、図３に示した実施形態の“Ｔｒａｃｋｓ”、“ＲｅｆＤａｔａ”及び“Ｆｒａｇｍｅｎｔｓ”タグがこれに該当する。
【００４５】
図４Ａは、本発明の一実施形態による複数のメディアデータを定義するための情報を図示する。
【００４６】
図４Ａを参照すれば、“Ｔｒａｃｋｓ”タグは、コンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータを区切るための情報である。“Ｔｒａｃｋｓ”タグは、複数のメディアデータそれぞれに割り当てられた“ＩＤ”属性（ａｔｔｒｉｂｕｔｅ）、“Ｔｙｐｅ”属性及び“Ｂｉｔｒａｔｅ”属性を含む。
【００４７】
“ＩＤ”属性は、メディアデータに対して順次に付与される識別子を定義し、“Ｔｙｐｅ”属性は、メディアデータのオーディオデータ、ビデオデータ、ビデオ／オーディオデータ、字幕データのうちいかなるデータに該当するかを定義する。“Ｔｙｐｅ”属性が“Ｐａｃｋｅｄ”ならば、メディアデータがビデオ／オーディオデータであることを表し、“Ｔｙｐｅ”属性が“Ｖｉｄｅｏ”ならば、メディアデータがビデオデータであることを表す。“Ｂｉｔｒａｔｅ”属性は、ビデオデータのエンコーディングに用いられたビット率を定義する。
【００４８】
図４Ｂは、本発明の一実施形態によるメディアデータのヘッダについての情報を図示する。
【００４９】
図４Ｂを参照すれば、“ＲｅｆＤａｔａ”タグは、“Ｔｙｐｅ”属性及び“ＩＤ”属性を含む。“Ｔｙｐｅ”属性は、ヘッダがいかなるメディアフォーマットのヘッダであるかを定義する。例えば、“Ｔｙｐｅ”属性が“ＨＥＡＤ−ＴＳ”ならば、ヘッダが伝送ストリーム（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）フォーマットのヘッダであることを表す。“ＩＤ”属性は、ヘッダが複数のメディアデータのうちいかなるメディアデータのヘッダであるかを定義する。“ＩＤ”属性が“１”ならば、メディアデータ識別子が“１”であるメディアデータに対するヘッダであることを表す。また、“ＲｅｆＤａｔａ”タグは、ヘッダを指示（Ｐｏｉｎｔｉｎｇ）する情報を含むところ、“ＵＲＬ”タグは、ヘッダの位置、すなわち、ＵＲＬを定義する。
【００５０】
“ＲｅｆＤａｔａ”タグは、選択的な要素である。ヘッダがメディアデータと分離されて別途のファイルに存在する場合にのみ、コンデンツ情報に“ＲｅｆＤａｔａ”タグが含まれ、メディアデータと結合されて存在する場合には、コンデンツ情報に“ＲｅｆＤａｔａ”タグが含まれていない。
【００５１】
図４Ｃは、本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも一つの部分についての情報を含む。
【００５２】
図４Ｃを参照すれば、“Ｆｒａｇｍｅｎｔｓ”タグの下位タグである“Ｆｒａｇｍｅｎｔ”タグに、複数のメディアデータそれぞれに含まれた少なくとも一つの部分についての情報が含まれる。
【００５３】
“Ｆｒａｇｍｅｎｔｓ”タグは、“ＮｅｘｔＦｒａｇｍｅｎｔｓＸＭＬＵＲＬ”属性を含む。ライブストリーミングのように一つのコンデンツストリーミングが完了すれば、次のコンデンツが続いてストリーミングされる場合には、次にストリーミングされるコンデンツ情報をクライアント１３０が予め知っていて初めて、コンデンツをストリーミングし続けることができる。したがって、“Ｆｒａｇｍｅｎｔｓ”タグは、次にストリーミングされるコンデンツ情報を、“ＮｅｘｔＦｒａｇｍｅｎｔｓＸＭＬＵＲＬ”属性と定義する。次にストリーミングされるコンデンツに対する複数のメディアデータのＵＲＬが“ＮｅｘｔＦｒａｇｍｅｎｔｓＸＭＬＵＲＬ”属性と定義される。
【００５４】
“Ｆｒａｇｍｅｎｔ”タグは、現在ストリーミングされるコンデンツの少なくとも一つの部分についての情報を含む。図４Ｃに示した実施形態を例として説明すれば、第１メディアデータとして、コンデンツを第１品質にエンコーディングして生成された最初の部分である“ｓｌｉｃｅ１−１．ａｓ”のＵＲＬ情報が“ＵＲＬ”タグにより定義され、対応するヘッダの識別子が“ＲｅｆＰｏｉｎｔｅｒ”タグにより定義される。また、最初の部分の開始時間が“ＳｔａｒｔＴｉｍｅ”属性により定義され、それぞれの部分の持続時間が“Ｄｕｒａｔｉｏｎ”属性により定義される。第１メディアデータの品質は“ＢｉｔＲａｔｅ”属性により定義される。
【００５５】
図４Ｃに示した実施形態では、“Ｆｒａｇｍｅｎｔｓ”タグはそれぞれのメディアデータが一つの部分のみ含む場合を図示した。しかし、当業者あらば、図１と関連して前述したよに、それぞれのメディアデータが複数の部分に分割される場合、一つの“Ｆｒａｇｍｅｎｔｓ”タグが２つ以上の部分についての情報を含むことができるということがすぐ分かる。
【００５６】
再び図２Ａを参照すれば、段階２２０でクライアント１３０は、複数のメディアデータのうち少なくとも一つのメディアデータの伝送をサーバ１２０に要請する。複数のメディアデータは、一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータである。クライアント１３０は、複数のメディアデータのうち、ストリーミング環境に好適な品質に符号化された少なくとも一つのメディアデータを選択してサーバ１２０に要請する。クライアント１３０は、コンデンツ情報に含まれた複数のメディアデータについての情報に基づいて、ＨＴＴＰ要請をサーバ１２０に伝送できる。
【００５７】
コンデンツ情報は、図４Ｃと関連して前述したように、“Ｆｒａｇｍｅｎｔｓ”タグを含んでいる。したがって、クライアント１３０は、“Ｆｒａｇｍｅｎｔｓ”タグに含まれたＵＲＬ情報に基づいて、選択されたメディアデータの伝送をサーバ１２０に要請する。
【００５８】
クライアント１２０の要請によって、サーバ１２０はメディアデータを伝送する。要請されたメディアデータの少なくとも一つの部分をクライアント１２０に伝送できる。ＨＴＴＰ要請に対するＨＴＴＰ応答として要請されたメディアデータをクライアント１２０に伝送できる。
【００５９】
図２Ｂは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。図２Ｂは、ヘッダがメディアデータと分離されて別途のファイルに存在する場合のストリーミング方法を図示する。
【００６０】
図２Ｂを参照すれば、段階２１２で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請し、サーバ１２０からコンデンツ情報を伝送する。図２Ａの段階２１０に図示される。図４Ｂと関連して前述した“ＲｅｆＤａｔａ”タグを含むコンデンツ情報を受信する。
【００６１】
段階２２２で、クライアント１３０は、段階２１０で受信されたコンデンツ情報に基づいて、複数のメディアデータのうち選択されたメディアデータのヘッダを要請する。段階２１２で受信されたコンデンツ情報に基づいて、複数のメディアデータのうちストリーミング環境に好適な少なくとも一つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階２１２で受信されたコンデンツ情報に含まれた“ＲｅｆＤａｔａ”タグを参照して、選択されたメディアデータのヘッダを要請する。
【００６２】
サーバ１２０は、要請されたメディアデータのヘッダをクライアント１３０に伝送する。ヘッダファイルをクライアント１３０に伝送でき、ヘッダファイルはＸＭＬファイルでありうる。
【００６３】
段階２３２で、クライアント１３０は、段階２１２で受信されたコンデンツ情報、及び段階２２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。メディアデータを時間に基づいて分割して生成された少なくとも一つの部分の伝送をサーバ１３０に要請し、サーバ１２０は、要請された少なくとも一つの部分をクライアント１３０に伝送する。
【００６４】
図５Ａは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【００６５】
図５Ａを参照すれば、段階５１０で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請し、サーバ１２０からコンデンツ情報を伝送する。所定のコンデンツ情報の伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送し、これに対するＨＴＴＰ応答としてコンデンツ情報を受信する。コンデンツ情報を含むＸＭＬファイルが受信できる。段階５１０で、クライアント１３０が受信するコンデンツ情報は、図２の段階２１０で、クライアント１３０が受信するコンデンツ情報と異なるところ、図６及び７を参照して詳細に説明する。
【００６６】
図６は、本発明のさらに他の実施形態によるコンデンツ情報を含むファイルのスキーマを示す図面である。
【００６７】
図６を参照すれば、本発明の一実施形態によるコンデンツ情報は、図３と同様に“Ｔｉｔｌｅ”、“Ｓｙｎｏｐｓｉｓ”、“ＯｒｉｇｉｎＳｉｔｅ”、“ＣｏｎｔｅｎｔＵＲＬ”タグなどを含む。
【００６８】
しかし、図３に示した実施形態では、コンデンツ情報が“Ｔｒａｃｋｓ”、“ＲｅｆＤａｔａ”及び“Ｆｒａｇｍｅｎｔｓ”タグを含むことで、複数のメディアデータについての情報も共に含むのに対し、図６に示した実施形態では、コンデンツ情報が複数のメディアデータについての情報を含むものではなく、複数のメディアデータについての情報を含むファイル（以下、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ：‘メディア表現技術’という。）のＵＲＬのみ定義することが異なる。“ＣｏｎｔｅｎｔＵＲＬ”タグによりメディア表現技術のＵＲＬが定義される。
【００６９】
図６に示したように、従来技術による多様なコンデンツ情報ファイルのスキーマをあまり変更せずに、メディア表現技術のＵＲＬのみコンデンツ情報ファイルに挿入することで、多様なメディアデータフォーマットとの互換性を維持しつつ、ストリーミング環境に適応的なストリーミングが可能になる。
【００７０】
図６に示したところによれば、コンデンツ情報は、複数のメディアデータについての情報は含まず、ストリーミング方法と関連する情報のみ含む。言い換えれば、“ＣｏｎｔｅｎｔＵＲＬ”タグは、ストリーミングに用いられるメディアデータのフォーマットを定義する“ＭｅｄｉａＦｏｒｍａｔ”属性、メディアデータの種類を定義する“ＭＩＭＥＴｙｐｅ”属性などを含む。
【００７１】
特に、“ＣｏｎｔｅｎｔＵＲＬ”タグは、コンデンツのストリーミングがいかなるサービスと関連しているかを定義する“ＴｒａｎｓｆｅｒＴｙｐｅ”属性を含む。“ＴｒａｎｓｆｅｒＴｙｐｅ”属性は、コンデンツのストリーミングがＣｏＤ（Ｃｏｎｔｅｎｔ ｏｎ Ｄｅｌｉｖｅｒｙ）サービス、生中継（Ｌｉｖｅ）、適応ストリーミング生中継（Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ Ｌｉｖｅ）及び適応ストリーミングＣｏＤ（Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ＣｏＤ）のうちいかなるサービスと関連しているかを定義できる。
【００７２】
図７は、本発明のさらに他の実施形態によるコンデンツ情報を図示する。図７は、ＯＩＰＦ標準によるＣＡＤでありうる。
【００７３】
図７を参照すれば、図６に示したスキーマによって生成されたコンデンツ情報は、“ＣｏｎｔｅｎｔＵＲＬ”タグにメディア表現技術のＵＲＬが定義される。“ｈｔｔｐ：／／ａｓｅｘａｍｐｌｅ．ｃｏｍ／ｖｏｄ／ｍｏｖｉｅｓ／１８８８８／Ｍｅｔａ／ＭａｉｎＭｅｔａ．ｘｍｌ”が、メディア表現技術のＵＲＬである。また、図６と関連して前述したように、“ＭｅｄｉａＦｏｒｍａｔ”属性、“ＭＩＭＥＴｙｐｅ”属性及び“ＴｒａｎｓｆｅｒＴｙｐｅ”属性などが“ＣｏｎｔｅｎｔＵＲＬ”タグに定義される。
【００７４】
再び図５Ａを参照すれば、段階５２０で、クライアント１３０は、段階５１０で受信されたコンデンツ情報に基づいて、複数のメディアデータについての情報をサーバ１２０に要請する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。
【００７５】
段階５１０で、クライアント１３０がサーバ１２０から受信したコンデンツ情報は、図６及び７と関連して前述したように、メディア表現技術のＵＲＬ情報を含むことができるところ、クライアント１３０は、コンデンツ情報の“ＣｏｎｔｅｎｔＵＲＬ”タグを参照してメディア表現技術をサーバ１２０に要請し、受信する。メディア表現技術について、図８Ａ及び図８Ｂ、図９Ａないし図９Ｇを参照して詳細に説明する。
【００７６】
図８Ａ及び図８Ｂは、本発明の一実施形態によるメディア表現技術のスキーマを示す図面である。メディア表現技術は、ＯＩＰＦ標準によるメディア表現技術でありうる。
【００７７】
図８Ａを参照すれば、本発明の一実施形態によるメディア表現技術は、複数のメディアデータのＵＲＬに対するテンプレート（ｔｅｍｐｌａｔｅ）タグ、ヘッダの位置を定義するためのタグ、ストリーミングがいかなるサービスと関連しているかを定義するためのタグ、メディアデータコンテナ（ｃｏｎｔａｉｎｅｒ）フォーマットを定義するためのタグ及び複数のメディアデータを定義するためのタグを含む。
【００７８】
“ｕｒｌＴｅｍｐｌａｔｅ”タグは、複数のメディアデータについてのＵＲＬ情報の共通部分を定義する。例えば、“ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｖｏｄ／ｍｏｖｉｅ／１８８８８／Ｔｒａｃｋ／｛ＴｒａｃｋＩＤ｝／Ｓｅｇｍｅｎｔｓ／｛ＳｅｇｍｅｎｔＩＤ｝”がＵＲＬテンプレートならば、“ＴｒａｃｋＩＤ”及び“ＳｅｇｍｅｎｔＩＤ”に、複数のメディアデータそれぞれの識別子及びそれぞれのメディアデータに含まれた少なくとも一つの部分の識別子を代入することで、メディアデータに対するＵＲＬを定義できる。
【００７９】
“ｈｅａｄｅｒＵｒｌ”タグは、図４Ｂと関連して前述した“ＲｅｆＤａｔａ”タグに対応する。言い換えれば、複数のメディアデータのヘッダＵＲＬを定義する。
【００８０】
“ｉｓＬｉｖｅ”タグは、ストリーミングがいかなるサービスと関連しているかを定義するタグである。例えば、“ｉｓＬｉｖｅ”タグが“Ｌｉｖｅ”と定義されれば、ストリーミングが生放送サービスと関連していることを表し、“ｉｓＬｉｖｅ”タグが”ＣｏＤ”と定義されれば、ストリーミングがＣｏＤサービスと関連していることを表す。
【００８１】
”ｃｏｎｔｅｎｔＴｙｐｅ”タグは、ストリーミングに用いられるメディアデータのコンテナフォーマットを定義する。例えば、メディアデータのコンテナフォーマットがＭＰ４フォーマットであるか、あるいはＭＰＥＧ２−ＴＳフォーマットであるかを表すための情報でありうる。
【００８２】
”Ｓｔｒｅａｍ”タグは、複数のメディアデータそれぞれに対して生成され、複数のメディアデータそれぞれを定義する。一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータそれぞれを定義するために、”ｓｔｒｅａｍＮａｍｅ”属性、”ｔｙｐｅ”属性、”ｂｉｔｒａｔｅ”属性、”ｓｔａｒｔＴｉｍｅ”属性、”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”属性、”ｄｕｒａｔｉｏｎ”属性、及び”ｉｎｔｅｒｖａｌＣｏｕｎｔ”属性を含む。
【００８３】
”ｓｔｒｅａｍＮａｍｅ”属性は、メディアデータの名称を定義する。メディアデータの識別子でありうる。”ｔｙｐｅ”属性は、メディアデータの類型を定義する。メディアデータがオーディオデータ、ビデオデータ及びオーディオ／ビデオデータのうちいかなるメディアのデータであるかを定義する。メディアデータが変速再生（ｔｒｉｃｋ ｐｌａｙ）のためにＩフレームに対するデータのみ含む場合には、これについての情報が”ｔｙｐｅ”属性と定義される。
【００８４】
”Ｂｉｔｒａｔｅ”属性は、メディアデータのビット率を定義し、”ｓｔａｒｔＴｉｍｅ”属性は、メディアデータの開始時間を特定するタイムスタンプを定義し、”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”属性は、最初に始まる部分の番号を定義する。
【００８５】
”ｄｕｒａｔｉｏｎ”属性は、メディアデータに含まれた部分の持続時間を定義し、”ｉｎｔｅｒｖａｌＣｏｎｕｎｔ”属性は、メディアデータに含まれた少なくとも一つの部分の全体数を定義する。
【００８６】
”Ｓｅｇｍｅｎｔ”タグは、”Ｓｔｒｅａｍ”タグの下位タグであり、メディアデータが、前述したようにコンデンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分ならば、このような少なくとも一つの部分それぞれを定義する。
【００８７】
”ＩｎｔＮｕｍ”属性は、部分の番号を定義し、”ＳｔａｒｔＴｉｍｅ”は、該当部分の開始時間を定義する。”Ｄｕｒａｔｉｏｎ”は、該当部分の持続時間を定義し、”ｕｒｌ”は、該当部分のＵＲＬ情報を定義する。
【００８８】
”Ｓｅｇｍｅｎｔ”タグは、選択的なタグであり、メディアデータに含まれた少なくとも一つの部分についての情報が”Ｓｔｒｅａｍ”タグの他の属性から類推される場合には、メディア表現技術に含まれない。言い換えれば、”Ｓｔｒｅａｍ”タグに定義された”ｓｔａｒｔＴｉｍｅ”、”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”、”ｄｕｒａｔｉｏｎ”及び”ｉｎｔｅｒｖａｌＣｏｕｎｔ”属性によって”Ｓｔｒｅａｍ”タグから類推される場合には、メディア表現技術に含まれない。また、”ｕｒｌＴｅｍｐｌａｔｅ”タグに所定のテンプレートが定義されており、このように定義されたテンプレートに、複数のメディアデータそれぞれの識別子及びそれぞれのメディアデータに含まれた少なくとも一つの部分の識別子を代入することで部分のＵＲＬ情報が類推できれば、”Ｓｅｇｍｅｎｔ”タグの”ｕｒｌ”属性は不要である。
【００８９】
図８Ｂを参照すれば、本発明のさらに他の実施形態によるメディア表現技術は、”ｎｅｘｔＭａｎｉｆｅｓｔＵＲＬ”タグをさらに含む。前述したように、ライブストリーミングまたは広告の挿入などのように一つのコンデンツストリーミングが完了すれば、次のコンデンツが続いてストリーミングされる場合には、次にストリーミングされるコンデンツ情報を、クライアント１３０が予め知っていて初めて、コンデンツをストリーミングし続けることができるので、現在ストリーミング中のコンデンツの次にストリーミングされるコンデンツのメディア表現技術のＵＲＬ情報が、”ｎｅｘｔＭａｎｉｆｅｓｔＵＲＬ”タグにより定義される。
【００９０】
図９Ａないし図９Ｈは、本願発明の一実施形態によるメディア表現技術を図示する。
【００９１】
図９Ａを参照すれば、本発明の一実施形態によるメディア表現技術は、”ＵＲＬＴｅｍｐｌａｔｅ”タグ、”ＲｅｆＤａｔａＵＲＬ”タグ及び複数のメディアデータそれぞれを定義する複数のタグを含む。
【００９２】
”ＵＲＬＴｅｍｐｌａｔｅ”タグ及び”ＲｅｆＤａｔａＵＲＬ”タグは、それぞれ図８Ａ及び図８Ｂの”ｕｒｌＴｅｍｐｌａｔｅ”タグ及び”ＲｅｆＤａｔａＵＲＬ”タグに対応する。
【００９３】
”ＩＤ”属性、”Ｔｙｐｅ”属性、”ＢｉｔＲａｔｅ”属性、”ＳｔａｒｔＴｉｍｅ”属性、”ＳｅｇｍｅｎｔＤｕｒａｔｉｏｎ”属性、”ＳｅｇｍｅｎｔＳｔａｒｔＩＤ”属性及び”ＳｅｇｍｅｎｔＣｏｕｎｔ”属性は、それぞれ図８Ａ及び図８Ｂの”ｓｔｒｅａｍＮａｍｅ”属性、”ｔｙｐｅ”属性、”ｂｉｔｒａｔｅ”属性、”ｓｔａｒｔＴｉｍｅ”属性、”Ｓｔｒｅａｍ”タグの”ｄｕｒａｔｉｏｎ”属性、”Ｓｔｒｅａｍ”タグの”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”属性及び”ｉｎｔｅｒｖａｌＣｏｕｎｔ”属性に対応する。
【００９４】
図９Ａに示したメディア表現技術は、コンデンツが相異なる品質に生成された３つのビデオデータ、一つのオーディオデータ及び変速再生のためにＩフレームのみエンコーディングして生成されたメディアデータについての情報を含む。
【００９５】
図９Ｂを参照すれば、本発明の一実施形態によるメディア表現技術は、”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグをさらに含む。”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグは、図８Ｂの”ｎｅｘｔＭａｎｉｆｅｓｔＵＲＬ”タグに対応する。したがって、現在再生中のコンデンツの次に続いて再生するコンデンツのメディア表現技術のＵＲＬが、”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグにより定義される。
【００９６】
図９Ｃは、現在再生中のコンデンツに続いて再生するコンデンツのメディア表現技術のＵＲＬが、図９Ｂの”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグにより定義された時、次に続いて再生するコンデンツのメディア表現技術を図示する。図９Ｂのメディア表現技術に比べれば、図９Ｃは、次に続いて再生されるコンデンツのメディア表現技術であるため、”ＳｔａｒｔＴｉｍｅ”属性の現在再生中のコンデンツのメディア表現技術と異なる。
【００９７】
図９Ｄ及び図９Ｅは、ユーザの高画質ビデオ再生を選択的に制御するためのメディア表現技術を図示する。一つのコンデンツを５種の相異なる品質にエンコーディングして複数のメディアデータが生成され、図９Ｄは、この場合のメディア表現技術を図示する。しかし、図９Ｅに示したメディア表現技術で高い品質にエンコーディングされたビデオについての情報を含んでいるタグ、すなわち、”ＩＤ”属性が”５”であるメディアデータの”ＳｔａｒｔＴｉｍｅ”属性及び”ＳｅｇｍｅｎｔＣｏｕｎｔ”属性が、図９Ｄのメディア表現技術と異なる。
【００９８】
サーバ１２０は、クライアント１３０のユーザ等級によって、図９Ｄのメディア表現技術または図９Ｅのメディア表現技術を選択的に伝送できる。クライアント１３０のユーザ等級が高い場合（例えば、クライアント１３０が有料ユーザである場合）には、図９Ｄのメディア表現技術を伝送することで、高品質のビデオも自由に再生させ、クライアント１３０のユーザ等級が低い場合（例えば、クライアント１３０が無料ユーザである場合）には、図９Ｅのメディア表現技術を伝送することで、高品質のビデオは、”ＳｔａｒｔＴｉｍｅ”属性により定義された時間から”ＳｅｇｍｅｎｔＣｏｕｎｔ”属性により定義された部分のみ再生可能にする。
【００９９】
図９Ｆは、コンデンツに広告が挿入される場合のメディア表現技術を図示する。図９Ｆを参照すれば、メディア表現技術は、”ＳｔａｒｔＴｉｍｅ”属性の相異なる広告コンデンツ及びメインコンデンツ情報を含む。メディア表現技術は、”００：００：００”から”００：０２：００”まで再生されるビット率”５０００００”の広告コンデンツ情報、及び”００：０２：００”から再生されるビット率”１００００００”、”２００００００”、”３００００００”及び”４００００００”のメインコンデンツ情報を含む。サーバ１２０が広告コンデンツを、一つのビット率によりエンコーディングしてクライアント１３０に提供し、広告コンデンツと”ＳｔａｒｔＴｉｍｅ”属性を異ならせるメインコンデンツは、４つの相異なるビット率によりエンコーディングしてクライアント１３０に提供する場合、図９Ｆのメディア表現技術がサーバ１２０からクライアント１３０に伝送される。
【０１００】
図９Ｇは、本発明の一実施形態による広告コンデンツ情報を含むメディア表現技術を図示する。メインコンデンツを提供するサーバと、広告コンデンツを提供するサーバとが相異なる。言い換えれば、クライアント１３０が、メインコンデンツは図５Ａのサーバ１２０から提供され、広告コンデンツは図５Ａのサーバ１２０ではない他のサーバから受信する場合、広告コンデンツ情報を含むメディア表現技術は、広告コンデンツのＵＲＬ情報を含む。図９Ｇに示したように、一つの品質に符号化された広告コンデンツのＵＲＬ情報がメディア表現技術に含まれる。
【０１０１】
図９Ｈは、本発明の一実施形態による言語情報及び字幕情報を含むメディア表現技術を図示する。図９Ｈを参照すれば、オーディオデータは多重言語についての情報を含む。”ＩＤ”属性が”４”及び”５”である多重言語のオーディオデータについての情報がメディア表現技術に含まれ、”ＩＤ”属性が”６”及び”７”である多重言語の字幕についての情報がメディア表現技術に含まれる。
【０１０２】
オーディオデータはもとより字幕も時間によって複数の部分に分割できるので、ストリーミング中にオーディオデータ及び字幕を、異なる言語のオーディオデータ及び字幕に変更できる。
【０１０３】
再び図５Ａを参照すれば、段階５３０で、クライアント１３０は、複数のメディアデータのうち少なくとも一つのメディアデータの伝送をサーバ１２０に要請する。クライアント１３０は、複数のメディアデータについての情報を参照して、ストリーミング環境に好適な品質に符号化された少なくとも一つのメディアデータを選択して、サーバ１２０に要請する。クライアント１３０は、所定のメディアデータの伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送できる。クライアント１２０の要請によって、サーバ１２０はメディアデータを伝送する。コンデンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分をクライアント１２０に伝送できる。ＨＴＴＰ要請に対するＨＴＴＰ応答として要請されたメディアデータをクライアント１２０に伝送できる。
【０１０４】
図５Ｂは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【０１０５】
図５Ｂを参照すれば、段階５１２で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請し、サーバ１２０からコンデンツ情報を伝送する。所定のコンデンツ情報の伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送し、これに対するＨＴＴＰ応答として、コンデンツ情報を受信する。コンデンツ情報を含むＸＭＬファイルを受信できる。
【０１０６】
段階５２２で、クライアント１３０は、段階５１２で受信されたコンデンツ情報に基づいて、複数のメディアデータについての情報をサーバ１２０に要請する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。
【０１０７】
段階５３２で、クライアント１３０は、段階５２２で受信された複数のメディアデータについての情報に基づいて選択されたメディアデータのヘッダを要請する。段階５２２で受信された情報に基づいて、複数のメディアデータのうちストリーミング環境に好適な少なくとも一つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階５２２で受信された複数のメディアデータについての情報を参照して選択されたメディアデータのヘッダを要請する。サーバ１２０は、要請に対する応答として、選択されたメディアデータのヘッダファイルをクライアント１３０に伝送する。
【０１０８】
段階５４２でクライアント１３０は、段階５２２で受信された複数のメディアデータについての情報、及び段階２２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。コンデンツを所定の割合でエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分の伝送をサーバ１３０に要請し、サーバ１２０は、要請された少なくとも一つの部分をクライアント１３０に伝送する。
【０１０９】
図１０Ａないし図１０Ｃは、本発明の一実施形態による複数のメディアデータを図示する。図１０Ａないし図１０Ｃは、図５Ａ及び図５Ｂによるストリーミング方法を行うために、サーバ１２０が保有する複数のメディアデータを図示する。
【０１１０】
図１０Ａを参照すれば、ストリーミング環境に適応的なストリーミングのために、サーバ１２０は、一つのコンデンツを複数の相異なる品質にエンコーディングして生成された複数のメディアデータ１０１０ないし１０３０を保有できる。”Ｔｒａｃｋ１”、”Ｔｒａｃｋ２”、…、”ＴｒａｃｋＮ”が複数のメディアデータである。また、それぞれのメディアデータは、それぞれのメディアデータを時間に基づいて分割して生成された少なくとも一つの部分を含む。”Ｓｌｉｃｅ１−１．ａｓ”、”Ｓｌｉｃｅ１−２．ａｓ”、”Ｓｌｉｃｅ１−３．ａｓ”、”Ｓｌｉｃｅ２−１．ａｓ”、”Ｓｌｉｃｅ２−２．ａｓ”、”Ｓｌｉｃｅ２−３．ａｓ”、”ＳｌｉｃｅＮ−１．ａｓ”、”ＳｌｉｃｅＮ−２．ａｓ”、”ＳｌｉｃｅＮ−３．ａｓ”などが少なくとも一つの部分である。
【０１１１】
また、サーバ１２０は、クライアント１３０の複数のメディアデータへのアクセスに必要な情報１０４０を保有できる。コンデンツ情報として”ＣａｄＭｅｔａ．ｘｍｌ”ファイル、複数のメディアデータについての情報として”ＭａｉｎＭｅｔａ．ｘｍｌ”ファイルを保有でき、複数のメディアデータのヘッダとして”Ｈｅａｄ１．ｒｅｆ”、”Ｈｅａｄ２．ｒｅｆ”ファイルなどを保有できる。”Ｈｅａｄ１．ｒｅｆ”は”Ｔｒａｃｋ１”のヘッダファイルであり、”Ｈｅａｄ２．ｒｅｆ”は”Ｔｒａｃｋ２”のヘッダファイルでありうる。
【０１１２】
”ＣａｄＭｅｔａ．ｘｍｌ”はＯＩＰＦ標準によるＣＡＤファイルであり、”ＭａｉｎＭｅｔａ．ｘｍｌ”は前述したメディア表現技術でありうる。また、”Ｈｅａｄ１．ｒｅｆ”、”Ｈｅａｄ２．ｒｅｆ”ファイルは選択的な要素であり、ヘッダが複数のメディアデータ１０１０ないし１０３０に含まれている場合には存在しない。
【０１１３】
図１０Ｂを参照すれば、クライアント１３０の複数のメディアデータへのアクセスに必要な情報１０４２は、”ＮｅｘｔＭｅｔａ．ｘｍｌ”をさらに含む。前述したように、”ＮｅｘｔＭｅｔａ．ｘｍｌ”は、現在再生中のコンデンツに続いて再生される次のコンデンツのメディア表現技術でありうる。前述したように、現在再生中のメディア表現技術、すなわち、”ＭａｉｎＭｅｔａ．ｘｍｌ”ファイルは、続いて再生するコンデンツのメディア表現技術のＵＲＬ情報を含んでいるところ、これに基づいてクライアント１３０は、”ＮｅｘｔＭｅｔａ．ｘｍｌ”ファイルにアクセスできる。
【０１１４】
図１０Ｃを参照すれば、複数のメディアデータのヘッダは、一つのファイル１０５０に存在できる。ヘッダファイルが複数のメディアデータそれぞれに対して複数で存在するものではなく、一つのヘッダファイル１０５０として複数のメディアデータにアクセスするために必要な情報１０４４に含まれる。
【０１１５】
例えば、複数のメディアデータそれぞれがＭＰＥＧ−２によるエレメンタリーストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）に対応する時、複数のメディアデータのヘッダは、ＰＡＴ（Ｐｒｏｇｒａｍ）及びＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）のうち少なくとも一つを含む一つのヘッダファイル１０５０でありうる。ＰＡＴ及びＰＭＴのうち少なくとも一つを、複数のメディアデータ１０１０ないし１０３０と分離して一つのヘッダファイル１０５０を作り、メディア表現技術は、このヘッダファイル１０５０を指示（Ｐｏｉｎｔｉｎｇ）する情報を含む。ヘッダファイル１０５０の指示情報は、ヘッダファイル１０５０のＵＲＬ情報でもあり、ＭＰＥＧ−２伝送ストリーム（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）でヘッダファイル１０５０を含んでいるパケットを特定するための情報でもありうる。
【０１１６】
前述した段階５３２で、クライアント１３０は、メディア表現技術を参照してヘッダファイル１０５０の指示情報を獲得し、指示情報に基づいてヘッダファイル１０５０を要請できる。指示情報にヘッダファイル１０５０を要請して受信した後、ヘッダファイル１０５０に含まれているＰＡＴ及びＰＭＴのうち少なくとも一つに基づいて、複数のメディアデータのうち少なくとも一つを選択し、選択されたメディアデータをサーバ１２０に要請する。ＰＡＴ及びＰＭＴは、複数のメディアデータ１０１０ないし１０３０の全体リストを含む。
【０１１７】
ＭＰＥＧ−２によれば、ＰＡＴ及びＰＭＴで定義されるＰＩＤ（Ｐａｃｋｅｔ ＩＤ）は、エレメンタリーストリームによって異なる。したがって、複数のメディアデータそれぞれに割り当てられるＰＩＤは相異なる。しかし、さらに他の実施形態によれば、一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータは、同じコンデンツに対するエレメンタリーストリームであるため、ＰＩＤが同一に設定されてもよい。
【０１１８】
複数のメディアデータ１０１０ないし１０３０がＭＰＥＧ−２による複数のエレメンタリーストリームに対応する場合、複数のメディアデータ１０１０ないし１０３０それぞれは、複数の連続するＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）を含む。
【０１１９】
複数のメディアデータは、一つのコンデンツを相異なる品質にエンコーディングして生成されたものであるので、複数のメディアデータそれぞれに含まれたＰＥＳのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）及び／またはＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）は、メディアデータの再生時間によって整列（ａｌｉｇｎｅｄ）される。言い換えれば、第１メディアデータの最初のＰＥＳと第２メディアデータの最初のＰＥＳとが同じ時間に再生されるコンデンツならば、ＰＴＳ及び／またはＤＴＳが同一に設定される。
【０１２０】
図１１Ａは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【０１２１】
図１１Ａを参照すれば、段階１１１０で、クライアント１３０は、複数のメディアデータについての情報をサーバ１２０に要請する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。クライアント１３０は、ストリーミング環境に適応的なストリーミングを行うために、一つのコンデンツを複数の相異なる品質にエンコーディングして生成された複数のメディアデータについての情報をサーバ１２０に要請し、受信する。コンデンツ情報の要請及び受信なしに、複数のメディアデータについての情報の要請及び受信が行われるという点が、図５Ａに示した実施形態と異なる。
【０１２２】
段階１１２０で、クライアント１３０は、複数のメディアデータのうち少なくとも一つのメディアデータの伝送をサーバ１２０に要請する。クライアント１３０は、複数のメディアデータについての情報を参照して、ストリーミング環境に好適な品質に符号化された少なくとも一つのメディアデータを選択してサーバ１２０に要請し、要請されたメディアデータをサーバ１２０から受信する。
【０１２３】
図１１Ｂは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【０１２４】
図１１Ｂを参照すれば、段階１１１２で、クライアント１３０は、複数のメディアデータについての情報をサーバ１２０に要請し、要請に対する応答として、複数のメディアデータについての情報をサーバ１２０から受信する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。
【０１２５】
段階１１２２で、クライアント１３０は、段階１１１２で受信された複数のメディアデータについての情報に基づいて選択されたメディアデータのヘッダを要請する。段階５２２で受信された複数のメディアデータについての情報を参照して、ストリーミング環境によって選択されたメディアデータのヘッダを要請する。サーバ１２０は、要請に対する応答として、選択されたメディアデータのヘッダを含むファイルをクライアント１３０に伝送する。
【０１２６】
段階１１３２で、クライアント１３０は、段階１１１２で受信された複数のメディアデータについての情報、及び段階１１２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。コンデンツを所定の割合でエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分の伝送をサーバ１３０に要請し、サーバ１２０は、要請された少なくとも一つの部分をクライアント１３０に伝送する。
【０１２７】
図１２Ａ及び図１２Ｂは、本発明のさらに他の実施形態による複数のメディアデータを図示する。図１２Ａ及び図１２Ｂは、図１１Ａ及び図１１Ｂによるストリーミング方法を行うために、サーバ１２０が保有する複数のメディアデータを図示する。
【０１２８】
図１２Ａを参照すれば、図１０Ａに示した実施形態と同様に、ストリーミング環境に適応的なストリーミングのために、サーバ１２０は、一つのコンデンツを複数の相異なる品質にエンコーディングして生成された複数のメディアデータ１０１０ないし１０３０を保有できる。
【０１２９】
クライアント１３０の複数のメディアデータへのアクセスに必要な情報１２４０のみ相異なるところ、図１０Ａに示した実施形態とは異なって、サーバ１２０は、コンデンツ情報を除外した複数のメディアデータについての情報のみ含む。この場合、クライアント１３０は、コンデンツ情報を、サーバ１２０ではない他のエンティティから受信し、コンデンツ情報に基づいてサーバ１２０が保有している複数のメディアデータにアクセスしてもよい。
【０１３０】
図１２Ｂを参照すれば、クライアント１３０の複数のメディアデータへのアクセスに必要な情報１２４２は、図１２Ａの情報１２４０に”ＮｅｘｔＭｅｔａ．ｘｍｌ”をさらに含む。
【０１３１】
図１３は、本発明の一実施形態によるデータ伝送システムの動作方法についてのフローチャートである。
【０１３２】
本発明の一実施形態によるデータ伝送システムは、サーバ１３０１及びクライアント１３０２を備える。
【０１３３】
段階ｓ１３１０で、サーバ１３０１は、一つ以上のコンポーネントを含む一つ以上のメディアデータを生成し、メディアデータについての情報を生成する。以下では、説明の便宜のために、サーバ１３０１で生成されたメディアデータのうち一つを第１メディアデータと称し、第１メディアデータを中心として伝送システムの動作方法を説明する。
【０１３４】
サーバ１３０１は、提供しようとするマルチメディアデータに含まれた少なくとも一つのコンテンツをエンコーディングして複数のコンポーネントを生成する。サーバ１３０１は、関連する複数の相異なるコンテンツをエンコーディングして同じタイプの複数のコンポーネントを生成してもよい。一例として、サーバ１３０１は、英語のオーディオコンテンツを用いて第１オーディオコンポーネントを生成し、韓国語のオーディオコンテンツを用いて第２オーディオコンポーネントを生成する。第１オーディオコンポーネントと第２オーディオコンポーネントとは、同じタイプのコンポーネントであるが、相異なるコンテンツを用いて生成されたものである。
【０１３５】
また、サーバ１３０１は、同じコンテンツを相異な方式でエンコーディングして複数のコンポーネントを生成できる。一例として、図１ないし図１２で前述したように、同じコンテンツを相異なる品質にエンコーディングすることで、ビットレートの相異なる複数のコンポーネントを生成できる。
【０１３６】
サーバ１３０１は、生成されたコンポーネントのうち少なくとも一つを含む第１メディアデータを生成する。第１メディアデータは、可能なあらゆるタイプのコンポーネントを含んでもよいが、一部タイプのコンポーネントのみ含んでもよい。一例として、サーバ１３０１でビデオコンポーネント、オーディオコンポーネント及びサブタイトルコンポーネントを生成した場合、第１メディアデータは、ビデオコンポーネント、オーディオコンポーネント及びサブタイトルコンポーネントをいずれも含んでもよいが、ビデオコンポーネントのみ含んでもよい。本明細書では、可能なあらゆるタイプのコンポーネントが含まれたメディアデータを、フル・リフリゼンテーション（ｆｕｌｌ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎまたはｃｏｍｐｌｅｔｅ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と称し、一部タイプのコンポーネントのみ含まれたメディアデータを、パーシャル・リフリゼンテーション（ｐａｒｔｉａｌ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と称する。パーシャル・リフリゼンテーションに含まれたコンポーネントは、他のパーシャルリフリゼンテーションに含まれたコンポーネントと共に処理されて、デコーダに提供される。
【０１３７】
第１メディアデータについての情報は、第１メディアデータに含まれたコンポーネントが第２メディアデータに含まれたコンポーネントと共に提供されるかどうかを表す情報を含む。すなわち、第１メディアデータがパーシャル・リフリゼンテーションであるかどうかを表す情報を含む。
【０１３８】
また、第１メディアデータについての情報は、第１メディアデータに含まれた少なくとも一つのコンポーネントについての情報であるコンポーネント情報を含む。第１メディアデータについての情報の一例は、図１５、図１７及び図１８で後述し、コンポーネント情報についての一例は、図１４及び図１６で後述する。
【０１３９】
段階ｓ１３２０で、サーバ１３０１は、第１メディアデータについての情報をクライアント１３０２に伝送する。第１メディアデータについての情報は、コンデンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイル（例えば、メディア表現技術）に含まれて伝送される。
【０１４０】
段階ｓ１３３０で、クライアント１３０２は、第１メディアデータについての情報に基づいて、第１メディアデータに含まれた少なくとも一つのコンポーネントをサーバ１３０１に要請する。クライアント１３０２がコンポーネントを要請して処理する具体的な過程は、図２１で後述する。
【０１４１】
クライアント１３０２は、メディア表現技術に含まれた複数のメディアデータのうち少なくとも一つのメディアデータを選択する。クライアント１３０２は、ユーザがパーシャル・リフリゼンテーションを所望するか、あるいはフル・リフリゼンテーションを所望するかを判断する。ユーザから別途の入力がない場合にフル・リフリゼンテーションが薦められる。
【０１４２】
ユーザの要請または通信環境に基づいて、適切なビットレートを持つ第１メディアデータを選択する。次いで、クライアント１３０２は、第１メディアデータのヘッダ情報を獲得し、第１メディアデータに含まれた少なくとも一つのコンポーネントをサーバ１３０１に要請する。第１メディアデータに複数のコンポーネントが含まれた場合には、クライアント１３０２の所望するコンポーネントを選択的に要請できる。
【０１４３】
段階ｓ１３４０で、サーバ１３０１は、クライアント１３０２が要請した第１メディアデータに含まれたコンポーネントを伝送する。
【０１４４】
段階ｓ１３５０で、クライアント１３０２は、受信されたコンポーネントを処理する。第１メディアデータがパーシャル・リフリゼンテーションであり、ユーザが第２メディアデータを追加的に選択したならば、クライアント１３０２は、第２メディアデータに含まれたコンポーネントをさらに受信して処理する。クライアント１３０２は、第１メディアデータに含まれたコンポーネントと、第２メディアデータに含まれたコンポーネントとを結合して、ユーザの所望するデータを出力する。
【０１４５】
従来には、フル・リフリゼンテーションのみ定義され、パーシャル・リフリゼンテーションは定義されていない。すなわち、サーバ１３０１は、あらゆるタイプのコンポーネントを含むメディアデータ、すなわち、フル・リフリゼンテーションのみ生成した。
【０１４６】
したがって、クライアント１３０２は、一回に一つのメディアデータに対するセグメントをダウンロードして処理する。かかる方式は比較的簡単で明らかではあるが、柔軟性の面では多くの短所を持っている。同じタイプのコンポーネントに多様な代案が存在する場合、サーバ１３０１は、それぞれの代案に対応する複数のメディアデータを生成せねばならない。例えば、同じビデオコンテンツを相異なるビット率でエンコーディングある４つのビデオコンポーネントが存在し、相異なる言語の３つのサブタイトルが存在する場合、サーバ１３０１は、コンポーネントの組み合わせの数に該当する１２つのメディアデータを生成せねばならない。これは、サーバ１３０１の保存空間を大きく無駄遣いさせる結果を招く。サーバ１３０１は、一般的に相異なるＵＲＬによって指示されるコンテンツ間のプロトコルや類似性が分からないため、サーバ１３０１が最適化するとしても（例えば、ディスクに別途に保存されたＥＳから、リアルタイムでメディアデータのセグメントを生成できるとしても）、コンテンツ伝送ネットワーク（ｃｏｎｔｅｎｔ ｄｅｌｉｖｅｒｙ ｎｅｔｗｏｒｋ、ＣＤＮ）にかかる方式を適用するのが容易でなかった。
【０１４７】
しかし、本発明の一実施形態では、サーバ１３０１が一部タイプのコンポーネントのみを含むメディアデータ、すなわち、パーシャル・リフリゼンテーションを生成することで、クライアント１３０２は、所望のメディアデータを確認し、これらに対するセグメントを独立的にダウンロードした後、メディアデータに含まれたコンポーネントを組み合わせて所望のデータを出力する。この場合、サーバ１３０１は、ビットレートによるビデオコンポーネントを含む４つのメディアデータと、３つの相異なる言語によるサブタイトルを含む３つのメディアデータのみを生成してもよい。他の実施形態では、サーバ１３０１が、ビットレートによるビデオコンポーネントと、特定言語のサブタイトルコンポーネントとを含む４つのメディアデータと、残りの２つの言語によるサブタイトルを含む２つのメディアデータのみを生成すれば十分である。このような方式で、サーバ１３０１で要求される保存空間及び負荷を急減させることができる。
【０１４８】
図１４は、本発明の一実施形態によるコンポーネント情報についての一例を示す。
【０１４９】
図１４の表は、図１５の‘ＰａｒｔｉａｌＴｙｐｅ’の属性値１４０１によるコンポーネント情報１４０２を表す。説明の便宜のために、コンポーネントは第１メディアデータに含まれると仮定する。
【０１５０】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｖｉｄｅｏ’１４１０である場合、第１メディアデータはビデオＥＳを含むことを表す。
【０１５１】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ａｕｄｉｏ’１４２０である場合、第１メディアデータは、オーディオＥＳを含むことを表す。
【０１５２】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｍｕｌｔｉｐｌｅｘ−ＡＶ’１４３０である場合、第１メディアデータは、ビデオデータとオーディオデータとが多重化されたＥＳを含むことを表す。
【０１５３】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｍｕｌｔｉｐｌｅｘ−ＡＳ’１４４０である場合、第１メディアデータは、ビデオデータとサブタイトルデータとが多重化されたＥＳを含むことを表す。
【０１５４】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｓｕｂｔｉｔｌｅ’１４５０である場合、第１メディアデータは、サブタイトルＥＳを含むことを表す。
【０１５５】
図１５は、本発明の一実施形態によるメディアデータについての情報についての一例を示す。
【０１５６】
図１５は、ＸＭＬファイルで具現されたＭＰＤの一例である。それぞれのメディアデータについての情報は、対応する＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに含まれる。
【０１５７】
＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性は、”ｏｉｐｆ：ＲｅｐｒｅｓｅｎｔａｔｉｏｎＴｙｐｅ”に設定される。この場合、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグは、‘ｐａｒｔｉａｌＴｙｐｅ’属性及び‘ｓｗｉｔｃｈＧｒｏｕｐ’属性を含む。
【０１５８】
‘ｐａｒｔｉａｌＴｙｐｅ’属性は、対応するメディアデータがパーシャル−プレゼンテーションであることを表す。すなわち、＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグが表すメディアデータに含まれた個別的なコンポーネント（ビデオ、オーディオ、サブタイトルなど）がサーバからダウンロードされた後、他の＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞が表すメディアデータを通じて獲得されるデータと共にデコーダに提供されることを意味する。
【０１５９】
‘ｐａｒｔｉａｌＴｙｐｅ’属性は、図１４に示したテーブルの値１４０１のうち一つを持つ。
【０１６０】
‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の場合、同じコンデンツを相異なる品質にエンコーディングして生成されたコンポーネントを持つメディアデータは同じ値を持つ。しかし、タイプは同一であるものの相異なるコンテンツを用いて生成されたメディアデータは、相異なる属性値を持つ（例えば、２つの異なる言語のオーディオコンポーネント）。
【０１６１】
＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性は、‘ｏｉｐｆ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔＴｙｐｅ’に設定される。この場合、＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグは、‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性を含む。
【０１６２】
‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性は、メディアデータのヘッダ（ｉｎｉｔｉａｌｉｚａｔｉｏｎ ｓｅｇｍｅｎｔ）についての参考を提供する。＜ｐｓｓ：Ｐｅｒｉｏｄ＞タグ内の＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグに‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性が存在する場合、ヘッダは、あらゆるメディアデータ（パーシャル・リフリゼンテーション、フル・リフリゼンテーション）に対するサンプルを説明するメタデータを提供する（例えば、ＭＰ４のｍｏｏｖ、ＴＳのＰＡＴ／ＰＭＴ）。
【０１６３】
図１６は、本発明の他の実施形態によるコンポーネント情報についての一例を示す。
【０１６４】
図１６の表は、図１７の‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’の属性値１６０１によるコンポーネント情報１６０２を表す。‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’属性は、‘ｉｄ’属性１６１０、‘Ｔｙｐｅ’属性１６２０、‘Ｌａｎｇ’属性１６３０、‘Ａｎｇｌｅ’属性１６４０、‘Ｃｈａｎｎｌｅｓ’属性１６５０及び‘Ｉｍｐａｒｉｅｄ’属性１６６０を含む。
【０１６５】
‘ｉｄ’属性１６１０は、メディアデータに含まれたコンポーネントの識別子を表す。識別子の形態は、コンテナによって異なる。一例として、ＭＰＥＧ２−ＴＳではＰＩＤが使われ、ＭＰ４ではＴｒａｃｋＩＤが使われる。その他にも、ユーザが任意に識別子の形態を指定できる。
【０１６６】
‘Ｔｙｐｅ’属性１６２０は、コンポーネントのタイプを表す。一例として、コンポーネントは、ビデオコンポーネント、オーディオコンポーネント及びサブタイトルコンポーネントのうち少なくとも一つでありうる。
【０１６７】
‘Ｌａｎｇ’属性１６３０は、オーディオコンポーネントまたはサブタイトルコンポーネントに対する言語コードを表す。言語コードは、ＲＣＦ５６４６による言語コードでありうる。
【０１６８】
‘Ａｎｇｌｅ’属性１６４０は、ビデオコンポーネントに対するカメラアングルを表す。
【０１６９】
‘Ｃｈａｎｎｌｅｓ’属性１６５０は、オーディオコンポーネントに対するオーディオチャネル（例えば、５．１チャネル、２．１チャネルなど）を表す。
【０１７０】
‘Ｉｍｐａｒｉｅｄ’属性１６６０は、障害のあるユーザのためのデータが提供されるを表す情報である。一例として、聴覚障害者のためのデータが提供されることを表す。
【０１７１】
図１７は、本発明の他の実施形態によるメディアデータについての情報についての一例を示す。
【０１７２】
図１７は、ＸＭＬファイルで具現されたＭＰＤの一例である。
【０１７３】
＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性が”ｏｉｐｆ：ＲｅｐｒｅｓｅｎｔａｔｉｏｎＴｙｐｅ”に設定される場合、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグは、次の属性を含む。
【０１７４】
‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性は、メディアデータが‘フル・リフリゼンテーション’ではなく‘パーシャル・リフリゼンテーション’であることを表す。すなわち、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに対応するメディアデータに含まれた少なくとも一つのコンポーネントは（例えば、個別的なビデオ、オーディオまたはサブタイトルを提供するＴｒａｃｋ／ＥＳ）、他のメディアデータを通じてダウンロードされるデータと共にデコーダに提供される。
【０１７５】
‘ｐａｒｔｉａｌＣｏｍｐｏｎｅｎｔｓ２属性は、メディアデータに含まれるそれぞれのコンポーネントを説明する。‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性の値は、メディアデータに含まれたそれぞれのコンポーネントについての情報のリストをセミコロン（またはコロン）で区切ったストリングでありうる。コンポーネントについての情報には、図１６に示した属性が含まれる。ただし、所望のコンポーネントを選択し、これによりデコーダを設定するのはアプリケーションが担当する。
【０１７６】
‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性は、同じ機能を行う他のタイトルで代替できる。一例として、‘Ｐａｔｉａｌ’属性、‘ＰａｔｉａｌＴｙｐｅ’属性‘Ｃｏｍｐｏｎｅｎｔ’などで代替できる。
【０１７７】
図１７では、‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性を通じて対応するメディアデータがパーシャル・リフリゼンテーションであるかどうかを表すと仮定した。しかし、実施形態によっては、図１７に示した他の属性がメディアデータがパーシャル・リフリゼンテーションであるかどうかを表すか、図１７に図示されていない新たな属性が、メディアデータがパーシャル・リフリゼンテーションであるかどうかを表すこともある。
【０１７８】
‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の場合、同じコンテンツを異なる方式でエンコーディングしたコンポーネント（例えば、同じコンテンツを異なる品質にエンコーディングして生成されたコンポーネント）を含むメディアデータについては、同じ属性値を持つ。しかし、タイプは同一であるものの、異なるコンテンツを用いて生成されたコンポーネント（例えば、２つの相異なる言語に対するオーディオコンポーネント）を含むメディアデータに対しては、異なる属性値を持つ。したがって、‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の値が相異なる複数のメディアデータに含まれたコンポーネントは、組み合わせられて同時に再生されるが、‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の値の同じメディアデータは、同時に再生されない。
【０１７９】
＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性は、‘ｏｉｐｆ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔＴｙｐｅ’に設定され、この場合、＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグは、次のタグ及び属性を含む。
【０１８０】
‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性は、ヘッダ（Ｉｎｉｔｉａｌｉｓａｔｉｏｎ Ｓｅｇｍｅｎｔ）に対する参考を表す。本属性が＜ｐｓｓ：Ｐｅｒｉｏｄ＞タグ内の＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグに存在するならば、参考になったヘッダがあらゆるメディアデータ（パーシャル・リフリゼンテーション及びフル・リフリゼンテーション）に対するメタデータを提供する（例えば、ＭＰ４のｍｏｏｖ、ＴＳのＰＡＴ／ＰＭＴ）。
【０１８１】
図１８は、本発明のさらに他の実施形態によるメディアデータについての情報の一例を示す。
【０１８２】
図１８は、ＸＭＬファイルで具現されたＭＰＤの一例である。それぞれのメディアＸＭＬファイル内の＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに含まれ、コンポーネント情報は、‘ｏｐｉｆ：Ｃｏｍｐｏｎｅｎｔ’属性に含まれる。
【０１８３】
＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグは‘ｇｒｏｕｐ’属性を含む。‘ｇｒｏｕｐ’属性が‘０ ’でない値を持つならば、対応するメディアデータがフル・リフリゼンテーションである必要はなく、パーシャル・リフリゼンテーションでありうることを表す。すなわち、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに対応するメディアデータに含まれた少なくとも一つのコンポーネントは（例えば、個別的なビデオ、オーディオまたはサブタイトルを提供するＴｒａｃｋ／ＥＳ）、他のメディアデータを通じてダウンロードされるデータに追加されてデコーダに提供される。この場合、＜Ｃｏｍｐｏｎｅｎｔ＞タグは、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに含まれた一つ以上のコンポーネントについての情報を含む。＜Ｃｏｍｐｏｎｅｎｔ＞タグは、図１６で定義された属性を含む。
【０１８４】
‘ｇｒｏｕｐ’属性の場合、少なくとも一つの同じコンポーネントを含むメディアデータに対しては同じ値を持つ。しかし、同じタイプの完全に相異なるコンポーネント（例えば、相異なる言語からなるオーディオコンポーネント）を持つ複数のメディアデータに対しては相異なる値を持つ。
【０１８５】
図１９は、本発明の一実施形態によるデータ伝送装置１９００についてのブロック図である。
【０１８６】
本発明の一実施形態によるデータ伝送装置１９００は、情報生成部１９１０、情報伝送部１９２０及びコンポーネント伝送部１９３０を備える。
【０１８７】
情報生成部１９１０は、少なくとも一つのコンポーネントを含む第１メディアデータについての情報を生成する。情報生成部１９１０は、一つのコンテンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイルを生成でき、このファイルに第１メディアデータについての情報を挿入する。
【０１８８】
第１メディアデータについての情報は、少なくとも一つのコンポーネントが、第２メディアデータから獲得したコンポーネントと共にデータ受信装置２０００内のデコーダに提供されるかどうかを表す情報、及び少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報を含む。
【０１８９】
コンポーネント情報は、第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含む。コンポーネント情報は、少なくとも一つのコンポーネントの識別情報、オーディオコンポーネントについてのチャネル情報、言語コード情報及び損傷（ｉｍｐａｉｒｅｄ）情報、サブタイトルコンポーネントについての言語情報、及び損傷情報サブタイトルコンポーネントについての言語情報、及び損傷情報ビデオコンポーネントについてのカメラ角度情報のうち少なくとも一つをさらに含む。
【０１９０】
第１メディアについての情報は、複数のメディアデータそれぞれが、同じコンテンツをエンコーディングして生成されたコンポーネントを含んでいるかどうかを表す情報をさらに含む。一例として、第１メディアデータと第２メディアデータとが同じコンテンツをエンコーディングして生成されたコンポーネントをそれぞれ含めば、特定フィールドの値を同じ値に設定し、第１メディアデータと第２メディアデータとが、同じタイプの相異なるコンテンツ（例えば、言語の相異なるオーディオコンテンツ）をエンコーディングして生成されたコンポーネントをそれぞれ含めば、特定フィールドの値を異なる値に設定できる。
【０１９１】
図２０は、本発明の一実施形態によるデータ受信装置２０００についてのブロック図である。
【０１９２】
情報受信部２０１０は、第１メディアデータについての情報を受信する。第１メディアデータについての情報は、少なくとも一つのコンポーネントが第２メディアデータから獲得したコンポーネントと共に提供されるかどうかを表す情報を含む。
【０１９３】
コンポーネント受信部２０２０は、第１メディアデータについての情報に基づいて少なくとも一つのコンポーネントを獲得する。
【０１９４】
図２１は、本発明の他の実施形態によるデータ受信方法についてのフローチャートである。
【０１９５】
段階ｓ２１１０では、ＭＰＤを獲得する。
【０１９６】
段階ｓ２１２０では、ＭＰＤがパーシャル・リフリゼンテーション及びフル・リフリゼンテーションをいずれも含む場合、ユーザからの入力に基づいてこれらのうち一つを選択する。別の入力がない場合、パーシャル・リフリゼンテーションの選択が薦められる。
【０１９７】
パーシャル・リフリゼンテーションが選択されれば、段階ｓ２１４１を行い、それとも段階ｓ２１３１を行う。
【０１９８】
段階ｓ２１３１では、ＭＰＤ内のメタデータに基づいて初期メディアデータを選択する。一般的に、メディアデータのビットレートに基づいて初期メディアデータを選択する。
【０１９９】
段階ｓ２１３２で、メディアデータのヘッダが存在すれば、ヘッダを獲得する。
【０２００】
段階ｓ２１３３で、メディアデータからメディアセグメントを獲得する。
【０２０１】
段階ｓ２１３４で、獲得したヘッダ及びメディアセグメントからＥＳを獲得する。この時、一つのオーディオストリームと一つのビデオストリームとを選択することが一般的である。もし、他の代案があれば、これら代案からＥＳを選択してもよい。
【０２０２】
段階ｓ２１３５で、選択されたＥＳを再生するために再生器を設定し、ＥＳを再生する。
【０２０３】
段階ｓ２１３６で、再生途中でユーザがヘッダ／メディアセグメント内の他のＥＳへの交替を要請するか、他のＥＳの追加を要請するかどうかを判断する。別の要請がない場合、段階ｓ２１３５によって選択されたＥＳを処理し続け、要請がある場合（例えば、他のビットレートへの転換）、要請されたフル・リフリゼンテーションを選択して段階ｓ２１３２を進める。
【０２０４】
段階ｓ２１４１では、ＭＰＤ内のメタデータに基づいて（例えば、‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’属性または‘Ｂａｎｄｗｉｄｔｈ’属性）、所望のＥＳが含まれたメディアデータを選択する。
【０２０５】
段階ｓ２１４２で、該当ピリオド内でのヘッダを獲得する。
【０２０６】
段階ｓ２１４３で、メディアデータでメディアセグメントを獲得する。
【０２０７】
段階ｓ２１４４で、獲得したヘッダ及びメディアセグメントからＥＳを獲得する。
【０２０８】
段階ｓ２１４５で、ヘッダまたはコンポーネント情報から獲得された情報を用いて、選択されたＥＳを再生できるように再生器を構成する。‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’属性にＩＤフィールドが存在するならば、ＭＰＤ内のストリームと、ヘッダから抽出されたメタデータ内のストリームとの間の正確なマッピングが可能である。この場合、ヘッダをパージングせずに‘ＴｒａｃｋＩＤ’または‘ＰＩＤ’を再生器に伝送できる。
【０２０９】
段階ｓ２１４６で、選択されたＥＳを再生するために再生器を設定し、ＥＳを再生する。
【０２１０】
段階ｓ２１４７で、再生途中でヘッダまたはメディアセグメント内の他のＥＳの選択または他のＥＳの追加要請が受信されるかどうかを判断する。別の要請がない場合、段階ｓ２１４６によって選択されたＥＳを進め続け、他のＥＳが選択された場合（例えば、他のビットレートへの転換）、段階ｓ２１４８に進める。
【０２１１】
段階ｓ２１４８では、選択されたパーシャル・リフリゼンテーションの‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値と、以前パーシャル・リフリゼンテーションの‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値とが同一であるかどうかを判断する。属性値が同一ならば、段階ｓ２１４４を進め、それとも段階ｓ２１４２を進める。
【０２１２】
具体的に、ユーザが‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値の同じ他のパーシャル−プレゼンテーションを選択すれば（例えば、ビットレートの相異なるコンポーネントが含まれたメディアデータ）、段階ｓ２１４４を進める。一方、ユーザが‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値の相異なる他のパーシャル−プレゼンテーションを選択するか、または追加すれば、段階ｓ２１４１を進める。
【０２１３】
以上のように、本発明は、たとえ限定された実施形態及び図面により説明されたとしても、本発明が前記の実施形態に限定されるものではなく、これは、当業者ならば、これらの記載から多様な修正及び変形が可能である。したがって、本発明の思想は特許請求の範囲のみによって把握されねばならず、これと均等または等価的な変形はいずれも本発明の思想の範ちゅうに属するといえる。また、本発明によるシステムは、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現できる。
【０２１４】
例えば、本発明の例示的な実施形態によるサーバのストリーミング装置及びクライアントのストリーミング装置は、図１３及び図１４に示したような装置のそれぞれのユニットにカップリングされたバス、前記バスに結合された少なくとも一つのプロセッサーを備える。また、命令、受信されたメッセージまたは生成されたメッセージを保存するために前記バスに結合されて、前述したような命令を行うための少なくとも一つのプロセッサーにカップリングされたメモリを含む。
【０２１５】
また、コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み込まれるデータが保存されるあらゆる種類の記録装置を備える。記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピー(登録商標)ディスク、光データ保存装置などを含む。またコンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散されて、分散方式でコンピュータで読み取り可能なコードが保存されて行われる。
【符号の説明】
【０２１６】
１１０ エンコーディング装置
１２０ サーバ
１３０ クライアント
【技術分野】
【０００１】
本発明は、データの伝送／受信方法及び装置に係り、特に、メディアデータに含まれたコンポーネントについての情報を用いてデータを伝送／受信する方法及び装置に関する。
【背景技術】
【０００２】
ネットワークを通じてメディアデータを伝送する方式には、ダウンロード方式とストリーミング方式とがある。ストリーミング方式は、サーバがリアルタイムでメディアデータを伝送し、クライアントは、受信されたメディアデータをリアルタイムで再生する方式である。
【０００３】
メディアデータは、複数のコンポーネントを含むことが一般的である。サーバは、複数のコンポーネントの組み合わせに該当する複数のメディアデータを保存し、ユーザがこれらのうち一つを要請すれば、要請されたメディアデータを伝送する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
前記の問題点を解決するための本発明の目的は、データを伝送及び受信する方法を提供することであり、特に、メディアデータに含まれたコンポーネントについての情報を共に伝送するデータ伝送方法及び装置を提供することである。
【課題を解決するための手段】
【０００５】
前記の目的を達成するための本発明の一実施形態が持つ一つの特徴は、少なくとも一つのコンポーネントを含む第１メディアデータについての情報を獲得する段階と、前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得する段階と、を含み、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことである。
【０００６】
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報を含み、前記コンポーネント情報は、前記第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含む。
【０００７】
前記コンポーネント情報は、前記少なくとも一つのコンポーネントの識別情報をさらに含む。
【０００８】
前記コンポーネント情報は、前記第１メディアデータに含まれたビデオコンポーネントについてのカメラ角度情報をさらに含む。
【０００９】
前記コンポーネント情報は、前記第１メディアデータに含まれたオーディオコンポーネントについてのチャネル情報及び言語コード情報のうち少なくとも一つをさらに含む。
【００１０】
前記コンポーネント情報は、前記第１メディアデータに含まれたサブタイトルコンポーネントについての言語情報をさらに含む。
【００１１】
前記第１メディアデータ情報は、前記第１メディアデータと前記第２メディアデータとが、同じコンデンツをエンコーディングして生成されたコンポーネントを含むかどうかを表す情報をさらに含む。
【００１２】
前記第１メディアデータについての情報を獲得する段階は、所定のコンデンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイルから、前記第１メディアデータについての情報を獲得する段階を含む。
【００１３】
本発明の他の実施形態が持つ一つの特徴は、サーバにより少なくとも一つのコンポーネントを含む第１メディアデータについての情報を生成する段階と、サーバにより前記第１メディアデータについての情報を伝送する段階と、前記伝送に対応する要請に基づいて、サーバにより前記少なくとも一つのコンポーネントを伝送する段階と、を含み、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含む。
【００１４】
本発明の他の実施形態が持つ一つの特徴は、マルチメディアデータを構成する少なくとも一つのコンポーネントが含まれた第１メディアデータについての情報を獲得する情報獲得部と、前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得するコンポーネント獲得部と、を備え、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことである。
【００１５】
本発明の他の実施形態が持つ一つの特徴は、少なくとも一つのコンポーネントが含まれた第１メディアデータについての情報を生成する情報生成部と、前記第１メディアデータについての情報を伝送する情報伝送部と、前記伝送に対応する要請に基づいて、前記少なくとも一つのコンポーネントを伝送するコンポーネント伝送部と、を備え、前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことである。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態によるストリーミングシステムを示す図面である。
【図２Ａ】本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。
【図２Ｂ】本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。
【図３】本発明の一実施形態によるコンデンツ情報を含むファイルのスキーマ（ｓｃｈｅｍａ）を示す図面である。
【図４Ａ】本発明の一実施形態による複数のメディアデータを定義するための情報を示す図面である。
【図４Ｂ】本発明の一実施形態によるメディアデータのヘッダについての情報を示す図面である。
【図４Ｃ】本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも一つの部分についての情報を含む図面である。
【図５Ａ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図５Ｂ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図６】本発明のさらに他の実施形態によるコンデンツ情報を含むファイルのスキーマを示す図面である。
【図７】本発明のさらに他の実施形態によるコンデンツ情報を示す図面である。
【図８Ａ】本発明の一実施形態によるメディア表現技術のスキーマを示す図面である。
【図８Ｂ】本発明の一実施形態によるメディア表現技術のスキーマを示す図面である。
【図９Ａ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｂ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｃ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｄ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｅ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｆ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｇ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図９Ｈ】本願発明の一実施形態によるメディア表現技術を示す図面である。
【図１０Ａ】本発明の一実施形態による複数のメディアデータを示す図面である。
【図１０Ｂ】本発明の一実施形態による複数のメディアデータを示す図面である。
【図１０Ｃ】本発明の一実施形態による複数のメディアデータを示す図面である。
【図１１Ａ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図１１Ｂ】本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【図１２Ａ】本発明のさらに他の実施形態による複数のメディアデータを示す図面である。
【図１２Ｂ】本発明のさらに他の実施形態による複数のメディアデータを示す図面である。
【図１２Ｃ】本発明のさらに他の実施形態による複数のメディアデータを示す図面である。
【図１３】本発明の一実施形態によるデータ伝送システムの動作方法についてのフローチャートである。
【図１４】本発明の一実施形態によるコンポーネント情報についての一例を示す図面である。
【図１５】本発明の一実施形態によるメディアデータについての情報についての一例を示す図面である。
【図１６】本発明の他の実施形態によるコンポーネント情報についての一例を示す図面である。
【図１７】本発明の他の実施形態によるメディアデータについての情報についての一例を示す図面である。
【図１８】本発明のさらに他の実施形態によるメディアデータについての情報についての一例を示す図面である。
【図１９】本発明の一実施形態によるデータ伝送装置１９００についてのブロック図である。
【図２０】本発明の一実施形態によるデータ受信装置２０００についてのブロック図である。
【図２１】本発明の他の実施形態によるデータ受信方法についてのフローチャートである。
【発明を実施するための形態】
【００１７】
まず、説明の便宜上、本明細書で使われる用語を簡単に定義する。
【００１８】
コンテンツの一例は、オーディオ情報、ビデオ情報、オーディオ−ビデオ情報及びデータを含む。コンテンツアイテム（Ｃｏｎｔｅｎｔ Ｉｔｅｍ）は、後述する複数のコンポーネントで構成される。
【００１９】
コンポーネント（Ｃｏｍｐｏｎｅｎｔ）は、オーディオ情報、ビデオ情報、サブタイトル情報などのコンテンツアイテムの成分である。一例として、コンポーネントは、特定言語で作成されたサブタイトルストリームや、特定カメラアングルで獲得したビデオストリームでありうる。コンポーネントは、コンテナによってトラックや基本ストリーム（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ、ＥＳ）とも称する。
【００２０】
コンテンツリソースは、コンテンツアイテムに対する適応的なストリーミングを可能にするために、複数のリフリゼンテーションから提供されるコンテンツアイテムである（例えば、多様な品質、ビットレート、角度）。サービス検索過程は、コンテンツリソースとも称する。コンテンツリソースは、一つ以上の連続的なタイムのピリオドで構成される。
【００２１】
ピリオドは、コンテンツリソースの時間的なセクションである。
【００２２】
リフリゼンテーションは、ピリオド内のコンテンツリソースのバージョン（あらゆるコンポーネントまたは一部コンポーネント）である。リフリゼンテーションは、コンポーネントのサブセットが異なるか、またはコンポーネントのエンコーディングパラメータ（例えば、ビットレート）が異なる。本明細書では、リフリゼンテーションをメディアデータと称するが、一つ以上のコンポーネントを含むデータを称するいかなる用語でも使われる。
【００２３】
セグメントは、特定システムレイヤー形式（ＴＳまたはＭＰ４）で唯一のＵＲＬを通じて称されるリフリゼンテーションの時間的なセクションを意味する。
【００２４】
以下では、図面を参照して本発明の実施形態を詳細に説明する。
【００２５】
図１は、本発明の一実施形態によるストリーミングシステムを図示する。
【００２６】
図１を参照すれば、本発明の一実施形態によるストリーミングシステム１００は、エンコーディング装置１１０、サーバ１２０及びクライアント１３０を備える。
【００２７】
エンコーディング装置１１０は、入力されたコンデンツを複数の相異なる品質にエンコーディングして、一つのコンデンツに対する複数のメディアデータを生成する。サーバ１２０がクライアント１３０にメディアデータをストリーミングする時、ストリーミング環境は変更される。例えば、ストリーミングのためのネットワーク１４０帯域幅が変更されてもよく、メディアデータを伝送するためにサーバ１２０の使用可能なハードウェア資源、またはメディアデータを受信するためにクライアント１３０の使用可能なハードウェア資源が変更されてもよい。
【００２８】
したがって、エンコーディング装置１１０は、流動的なストリーミング環境による適応的なストリーミングのために、一つのコンデンツを複数の相異なる品質にエンコーディングする。ビット率、サンプリング周波数または解像度などの因子を調節することで、一つのコンデンツを複数の相異なる品質にエンコーディングできる。例えば、一つの動映像コンデンツを相異なる解像度でエンコーディングして、５００Ｋｂｐｓ、１０００Ｋｂｐｓ及び２０００Ｋｂｐｓの複数のメディアデータを生成できる。
【００２９】
相異なる品質にエンコーディングされた複数のメディアデータはサーバ１２０に伝送され、この時、コンデンツ情報及び複数のメディアデータそれぞれについての情報も共にサーバ１２０に伝送される。コンデンツ情報は、コンデンツのメタデータであり、コンデンツのタイトル（ｔｉｔｌｅ）、シノプシス（ｓｙｎｏｐｓｉｓ）、コンデンツ識別子（Ｃｏｎｔｅｎｔ ＩＤ）、コンデンツＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などの情報を含む。複数のメディアデータについての情報は、それぞれのメディアデータの品質、類型及び識別子などを含むところ、これについては、図４Ａないし図４Ｃを参照して詳細に説明する。
【００３０】
クライアント１４０は、コンデンツ情報及び複数のメディアデータについての情報のうち少なくとも一つを受信し、これに基づいて、サーバ１２０に複数のメディアデータのうち少なくとも一つのメディアデータを要請する。クライアント１３０は、ストリーミング環境を推定（ｅｓｔｉｍａｔｉｏｎ）し、推定されたストリーミング環境に基づいて複数のメディアデータのうち少なくとも一つのメディアデータを選択する。推定されたストリーミング環境で適宜なＱｏＳを維持できる少なくとも一つのメディアデータを選択する。次いで、クライアント１３０は、選択された少なくとも一つのメディアデータの伝送を要請するＨＴＴＰ要請（ｒｅｑｕｅｓｔ）をサーバ１２０に伝送できる。
【００３１】
ストリーミング環境が劣化して高品質のメディアデータを受信すれば、メディアデータを再生し続けることができない場合には、複数のメディアデータのうち低い品質のメディアデータを要請し、ストリーミング環境が改善されて高品質のメディアデータを受信しても、メディアデータを再生し続けることができる場合には、複数のメディアデータのうち高品質のメディアデータを要請できる。
【００３２】
所定のメディアデータの受信中に他のメディアデータの伝送をサーバ１２０に要請してもよい。例えば、ストリーミング環境が劣化した状態で低い品質の第１メディアデータを要請して受信しているクライアント１３０は、ストリーミング環境が改善されるにつれてさらに高品質の第２メディアデータの伝送を、サーバ１２０に要請できる。従来技術によるストリーミング方法によれば、サーバ１２０とクライアント１３０とがストリーミングチャネルを最初に設定する時、品質を一度設定すれば、同じ品質でメディアデータを送受信し続けねばならない。しかし、本願発明によれば、クライアント１３０が低い品質の第１メディアデータの受信中にも同じコンデンツに対するさらに高品質の第２メディアデータを再び要請することができて、ストリーミング環境による適応的なストリーミングが可能になる。
【００３３】
ネットワーク１４０の帯域幅及びサーバ１２０またはクライアント１３０の使用可能なハードウェア資源に基づいてストリーミング環境を推定する多様な方法が、クライアント１３０のストリーミング環境の推定に利用できる。例えば、クライアント１３０は、受信されるメディアデータのタイムスタンプ及びＢＥＲ（Ｂｉｔ Ｅｒｒｏｒ Ｒａｔｅ）に基づいてストリーミング環境を推定できる。受信されるメディアデータのタイムスタンプを確認して、メディアデータが再生速度より遅い速度で受信されていれば、ストリーミング環境が劣化していると判断できる。また、受信されるメディアデータのＢＥＲが高くなってストリーミング環境が劣化していると判断できる。
【００３４】
クライアント１３０がストリーミング環境によって複数のメディアデータのうち少なくとも一つのメディアデータの伝送を要請すれば、サーバ１２０は、要請されたメディアデータをクライアント１３０に伝送する。ＨＴＴＰ要請に対するＨＴＴＰ応答として、要請されたメディアデータをクライアント１３０に伝送できる。
【００３５】
複数のメディアデータそれぞれは、コンデンツを相異なる品質にエンコーディングし、分割して生成された複数の部分のうち少なくとも一つを含む。言い換えれば、エンコーディング装置１１０のエンコーディング結果、生成された複数のメディアデータそれぞれは、時間に基づいて分割された少なくとも一つの部分をそれぞれ含む。サーバ１２０は、コンデンツを一つのストリームにエンコーディングして連続して伝送するものではなく、複数の部分に分割してそれぞれ伝送する。コンデンツを１０秒または２０秒などの所定の時間単位でコンデンツを分割して、複数の部分を生成できる。分割の基礎になる時間は、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）に基づいて設定される。一つまたは二つ以上のＧＯＰのピクチャーに対応するメディアデータを一つの部分に設定できる。
【００３６】
例えば、２種の品質でコンデンツがストリーミングされる場合、第１メディアデータは、コンデンツを第１品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分を含むことができ、第２メディアデータは、コンデンツを第２品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分を含む。
【００３７】
複数のメディアデータを時間に基づいてそれぞれ分割することで、前述した適応的なストリーミングが可能になる。例えば、ストリーミングが始まれば、サーバ１２０は、品質が低い第１メディアデータの０秒〜２０秒に該当する部分を伝送する。次いで、２０秒以後にストリーミング環境が改善されたと判断されて、クライアント１３０がさらに高品質のメディアデータを要請すれば、サーバ１２０は、さらに品質の高い第２メディアデータの２０秒〜４０秒に該当する部分を伝送できる。メディアデータが時間に基づいて複数の部分に分割されているため、ストリーミング途中でもストリーミング環境によって異なるメディアデータの部分を伝送できる。
【００３８】
図２Ａは、本発明の一実施形態によるストリーミング方法を説明するためのフローチャートである。
【００３９】
図２Ａを参照すれば、段階２１０で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請する。クライアント１３０のユーザが、クライアント１３０の画面に表示されたユーザインターフェースから所定のコンデンツを選択すれば、選択されたコンデンツ情報の伝送をサーバ１２０に要請する。クライアント１３０は、コンデンツ情報の伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送できる。
【００４０】
クライアント１３０から要請を受信したサーバ１２０は、クライアント１３０にコンデンツ情報を伝送する。ＨＴＴＰ要請に対するＨＴＴＰ応答として、コンデンツ情報をクライアント１３０に伝送できる。コンデンツ情報は、ＯＩＰＦ（Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ）標準によるＣＡＤ（Ｃｏｎｔｅｎｔ Ａｃｃｅｓｓ Ｄｅｓｃｒｉｐｔｏｒ）でありうる。図３を参照して詳細に説明する。
【００４１】
図３は、本発明の一実施形態によるコンデンツ情報を含むファイルのスキーマを図示する。コンデンツ情報を含むファイルは、ＣＡＤであり、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ファイルでありうる。以下、本発明の詳細な説明ではタグ（ｔａｇ）及び属性（ａｔｔｒｉｂｕｔｅ）を区分して説明するが、本発明の詳細な説明でタグにより定義される項目を、タグではない属性により定義するか、本発明の詳細な説明で属性により定義される項目を、属性ではないタグにより定義するということは、当業者ならば容易に理解できる。
【００４２】
図３を参照すれば、コンデンツ情報は“Ｔｉｔｌｅ”、“Ｓｙｎｏｐｓｉｓ”、“ＯｒｉｇｉｎＳｉｔｅ”、“ＣｏｎｔｅｎｔＵＲＬ”タグなどを含む。
【００４３】
従来技術によるメディアデータのストリーミングは、一つのコンデンツを所定の品質にエンコーディングして一つのメディアデータを生成するので、従来技術によるコンデンツ情報（特に、ＯＩＰＦによるＣＡＤ）は、コンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含んでいない。
【００４４】
しかし、本発明の一実施形態によるコンデンツ情報は、一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータについての情報を含むところ、図３に示した実施形態の“Ｔｒａｃｋｓ”、“ＲｅｆＤａｔａ”及び“Ｆｒａｇｍｅｎｔｓ”タグがこれに該当する。
【００４５】
図４Ａは、本発明の一実施形態による複数のメディアデータを定義するための情報を図示する。
【００４６】
図４Ａを参照すれば、“Ｔｒａｃｋｓ”タグは、コンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータを区切るための情報である。“Ｔｒａｃｋｓ”タグは、複数のメディアデータそれぞれに割り当てられた“ＩＤ”属性（ａｔｔｒｉｂｕｔｅ）、“Ｔｙｐｅ”属性及び“Ｂｉｔｒａｔｅ”属性を含む。
【００４７】
“ＩＤ”属性は、メディアデータに対して順次に付与される識別子を定義し、“Ｔｙｐｅ”属性は、メディアデータのオーディオデータ、ビデオデータ、ビデオ／オーディオデータ、字幕データのうちいかなるデータに該当するかを定義する。“Ｔｙｐｅ”属性が“Ｐａｃｋｅｄ”ならば、メディアデータがビデオ／オーディオデータであることを表し、“Ｔｙｐｅ”属性が“Ｖｉｄｅｏ”ならば、メディアデータがビデオデータであることを表す。“Ｂｉｔｒａｔｅ”属性は、ビデオデータのエンコーディングに用いられたビット率を定義する。
【００４８】
図４Ｂは、本発明の一実施形態によるメディアデータのヘッダについての情報を図示する。
【００４９】
図４Ｂを参照すれば、“ＲｅｆＤａｔａ”タグは、“Ｔｙｐｅ”属性及び“ＩＤ”属性を含む。“Ｔｙｐｅ”属性は、ヘッダがいかなるメディアフォーマットのヘッダであるかを定義する。例えば、“Ｔｙｐｅ”属性が“ＨＥＡＤ−ＴＳ”ならば、ヘッダが伝送ストリーム（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）フォーマットのヘッダであることを表す。“ＩＤ”属性は、ヘッダが複数のメディアデータのうちいかなるメディアデータのヘッダであるかを定義する。“ＩＤ”属性が“１”ならば、メディアデータ識別子が“１”であるメディアデータに対するヘッダであることを表す。また、“ＲｅｆＤａｔａ”タグは、ヘッダを指示（Ｐｏｉｎｔｉｎｇ）する情報を含むところ、“ＵＲＬ”タグは、ヘッダの位置、すなわち、ＵＲＬを定義する。
【００５０】
“ＲｅｆＤａｔａ”タグは、選択的な要素である。ヘッダがメディアデータと分離されて別途のファイルに存在する場合にのみ、コンデンツ情報に“ＲｅｆＤａｔａ”タグが含まれ、メディアデータと結合されて存在する場合には、コンデンツ情報に“ＲｅｆＤａｔａ”タグが含まれていない。
【００５１】
図４Ｃは、本発明の一実施形態による複数のメディアデータそれぞれに含まれた少なくとも一つの部分についての情報を含む。
【００５２】
図４Ｃを参照すれば、“Ｆｒａｇｍｅｎｔｓ”タグの下位タグである“Ｆｒａｇｍｅｎｔ”タグに、複数のメディアデータそれぞれに含まれた少なくとも一つの部分についての情報が含まれる。
【００５３】
“Ｆｒａｇｍｅｎｔｓ”タグは、“ＮｅｘｔＦｒａｇｍｅｎｔｓＸＭＬＵＲＬ”属性を含む。ライブストリーミングのように一つのコンデンツストリーミングが完了すれば、次のコンデンツが続いてストリーミングされる場合には、次にストリーミングされるコンデンツ情報をクライアント１３０が予め知っていて初めて、コンデンツをストリーミングし続けることができる。したがって、“Ｆｒａｇｍｅｎｔｓ”タグは、次にストリーミングされるコンデンツ情報を、“ＮｅｘｔＦｒａｇｍｅｎｔｓＸＭＬＵＲＬ”属性と定義する。次にストリーミングされるコンデンツに対する複数のメディアデータのＵＲＬが“ＮｅｘｔＦｒａｇｍｅｎｔｓＸＭＬＵＲＬ”属性と定義される。
【００５４】
“Ｆｒａｇｍｅｎｔ”タグは、現在ストリーミングされるコンデンツの少なくとも一つの部分についての情報を含む。図４Ｃに示した実施形態を例として説明すれば、第１メディアデータとして、コンデンツを第１品質にエンコーディングして生成された最初の部分である“ｓｌｉｃｅ１−１．ａｓ”のＵＲＬ情報が“ＵＲＬ”タグにより定義され、対応するヘッダの識別子が“ＲｅｆＰｏｉｎｔｅｒ”タグにより定義される。また、最初の部分の開始時間が“ＳｔａｒｔＴｉｍｅ”属性により定義され、それぞれの部分の持続時間が“Ｄｕｒａｔｉｏｎ”属性により定義される。第１メディアデータの品質は“ＢｉｔＲａｔｅ”属性により定義される。
【００５５】
図４Ｃに示した実施形態では、“Ｆｒａｇｍｅｎｔｓ”タグはそれぞれのメディアデータが一つの部分のみ含む場合を図示した。しかし、当業者あらば、図１と関連して前述したよに、それぞれのメディアデータが複数の部分に分割される場合、一つの“Ｆｒａｇｍｅｎｔｓ”タグが２つ以上の部分についての情報を含むことができるということがすぐ分かる。
【００５６】
再び図２Ａを参照すれば、段階２２０でクライアント１３０は、複数のメディアデータのうち少なくとも一つのメディアデータの伝送をサーバ１２０に要請する。複数のメディアデータは、一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータである。クライアント１３０は、複数のメディアデータのうち、ストリーミング環境に好適な品質に符号化された少なくとも一つのメディアデータを選択してサーバ１２０に要請する。クライアント１３０は、コンデンツ情報に含まれた複数のメディアデータについての情報に基づいて、ＨＴＴＰ要請をサーバ１２０に伝送できる。
【００５７】
コンデンツ情報は、図４Ｃと関連して前述したように、“Ｆｒａｇｍｅｎｔｓ”タグを含んでいる。したがって、クライアント１３０は、“Ｆｒａｇｍｅｎｔｓ”タグに含まれたＵＲＬ情報に基づいて、選択されたメディアデータの伝送をサーバ１２０に要請する。
【００５８】
クライアント１２０の要請によって、サーバ１２０はメディアデータを伝送する。要請されたメディアデータの少なくとも一つの部分をクライアント１２０に伝送できる。ＨＴＴＰ要請に対するＨＴＴＰ応答として要請されたメディアデータをクライアント１２０に伝送できる。
【００５９】
図２Ｂは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。図２Ｂは、ヘッダがメディアデータと分離されて別途のファイルに存在する場合のストリーミング方法を図示する。
【００６０】
図２Ｂを参照すれば、段階２１２で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請し、サーバ１２０からコンデンツ情報を伝送する。図２Ａの段階２１０に図示される。図４Ｂと関連して前述した“ＲｅｆＤａｔａ”タグを含むコンデンツ情報を受信する。
【００６１】
段階２２２で、クライアント１３０は、段階２１０で受信されたコンデンツ情報に基づいて、複数のメディアデータのうち選択されたメディアデータのヘッダを要請する。段階２１２で受信されたコンデンツ情報に基づいて、複数のメディアデータのうちストリーミング環境に好適な少なくとも一つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階２１２で受信されたコンデンツ情報に含まれた“ＲｅｆＤａｔａ”タグを参照して、選択されたメディアデータのヘッダを要請する。
【００６２】
サーバ１２０は、要請されたメディアデータのヘッダをクライアント１３０に伝送する。ヘッダファイルをクライアント１３０に伝送でき、ヘッダファイルはＸＭＬファイルでありうる。
【００６３】
段階２３２で、クライアント１３０は、段階２１２で受信されたコンデンツ情報、及び段階２２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。メディアデータを時間に基づいて分割して生成された少なくとも一つの部分の伝送をサーバ１３０に要請し、サーバ１２０は、要請された少なくとも一つの部分をクライアント１３０に伝送する。
【００６４】
図５Ａは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【００６５】
図５Ａを参照すれば、段階５１０で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請し、サーバ１２０からコンデンツ情報を伝送する。所定のコンデンツ情報の伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送し、これに対するＨＴＴＰ応答としてコンデンツ情報を受信する。コンデンツ情報を含むＸＭＬファイルが受信できる。段階５１０で、クライアント１３０が受信するコンデンツ情報は、図２の段階２１０で、クライアント１３０が受信するコンデンツ情報と異なるところ、図６及び７を参照して詳細に説明する。
【００６６】
図６は、本発明のさらに他の実施形態によるコンデンツ情報を含むファイルのスキーマを示す図面である。
【００６７】
図６を参照すれば、本発明の一実施形態によるコンデンツ情報は、図３と同様に“Ｔｉｔｌｅ”、“Ｓｙｎｏｐｓｉｓ”、“ＯｒｉｇｉｎＳｉｔｅ”、“ＣｏｎｔｅｎｔＵＲＬ”タグなどを含む。
【００６８】
しかし、図３に示した実施形態では、コンデンツ情報が“Ｔｒａｃｋｓ”、“ＲｅｆＤａｔａ”及び“Ｆｒａｇｍｅｎｔｓ”タグを含むことで、複数のメディアデータについての情報も共に含むのに対し、図６に示した実施形態では、コンデンツ情報が複数のメディアデータについての情報を含むものではなく、複数のメディアデータについての情報を含むファイル（以下、Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ：‘メディア表現技術’という。）のＵＲＬのみ定義することが異なる。“ＣｏｎｔｅｎｔＵＲＬ”タグによりメディア表現技術のＵＲＬが定義される。
【００６９】
図６に示したように、従来技術による多様なコンデンツ情報ファイルのスキーマをあまり変更せずに、メディア表現技術のＵＲＬのみコンデンツ情報ファイルに挿入することで、多様なメディアデータフォーマットとの互換性を維持しつつ、ストリーミング環境に適応的なストリーミングが可能になる。
【００７０】
図６に示したところによれば、コンデンツ情報は、複数のメディアデータについての情報は含まず、ストリーミング方法と関連する情報のみ含む。言い換えれば、“ＣｏｎｔｅｎｔＵＲＬ”タグは、ストリーミングに用いられるメディアデータのフォーマットを定義する“ＭｅｄｉａＦｏｒｍａｔ”属性、メディアデータの種類を定義する“ＭＩＭＥＴｙｐｅ”属性などを含む。
【００７１】
特に、“ＣｏｎｔｅｎｔＵＲＬ”タグは、コンデンツのストリーミングがいかなるサービスと関連しているかを定義する“ＴｒａｎｓｆｅｒＴｙｐｅ”属性を含む。“ＴｒａｎｓｆｅｒＴｙｐｅ”属性は、コンデンツのストリーミングがＣｏＤ（Ｃｏｎｔｅｎｔ ｏｎ Ｄｅｌｉｖｅｒｙ）サービス、生中継（Ｌｉｖｅ）、適応ストリーミング生中継（Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ Ｌｉｖｅ）及び適応ストリーミングＣｏＤ（Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ＣｏＤ）のうちいかなるサービスと関連しているかを定義できる。
【００７２】
図７は、本発明のさらに他の実施形態によるコンデンツ情報を図示する。図７は、ＯＩＰＦ標準によるＣＡＤでありうる。
【００７３】
図７を参照すれば、図６に示したスキーマによって生成されたコンデンツ情報は、“ＣｏｎｔｅｎｔＵＲＬ”タグにメディア表現技術のＵＲＬが定義される。“ｈｔｔｐ：／／ａｓｅｘａｍｐｌｅ．ｃｏｍ／ｖｏｄ／ｍｏｖｉｅｓ／１８８８８／Ｍｅｔａ／ＭａｉｎＭｅｔａ．ｘｍｌ”が、メディア表現技術のＵＲＬである。また、図６と関連して前述したように、“ＭｅｄｉａＦｏｒｍａｔ”属性、“ＭＩＭＥＴｙｐｅ”属性及び“ＴｒａｎｓｆｅｒＴｙｐｅ”属性などが“ＣｏｎｔｅｎｔＵＲＬ”タグに定義される。
【００７４】
再び図５Ａを参照すれば、段階５２０で、クライアント１３０は、段階５１０で受信されたコンデンツ情報に基づいて、複数のメディアデータについての情報をサーバ１２０に要請する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。
【００７５】
段階５１０で、クライアント１３０がサーバ１２０から受信したコンデンツ情報は、図６及び７と関連して前述したように、メディア表現技術のＵＲＬ情報を含むことができるところ、クライアント１３０は、コンデンツ情報の“ＣｏｎｔｅｎｔＵＲＬ”タグを参照してメディア表現技術をサーバ１２０に要請し、受信する。メディア表現技術について、図８Ａ及び図８Ｂ、図９Ａないし図９Ｇを参照して詳細に説明する。
【００７６】
図８Ａ及び図８Ｂは、本発明の一実施形態によるメディア表現技術のスキーマを示す図面である。メディア表現技術は、ＯＩＰＦ標準によるメディア表現技術でありうる。
【００７７】
図８Ａを参照すれば、本発明の一実施形態によるメディア表現技術は、複数のメディアデータのＵＲＬに対するテンプレート（ｔｅｍｐｌａｔｅ）タグ、ヘッダの位置を定義するためのタグ、ストリーミングがいかなるサービスと関連しているかを定義するためのタグ、メディアデータコンテナ（ｃｏｎｔａｉｎｅｒ）フォーマットを定義するためのタグ及び複数のメディアデータを定義するためのタグを含む。
【００７８】
“ｕｒｌＴｅｍｐｌａｔｅ”タグは、複数のメディアデータについてのＵＲＬ情報の共通部分を定義する。例えば、“ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／ｖｏｄ／ｍｏｖｉｅ／１８８８８／Ｔｒａｃｋ／｛ＴｒａｃｋＩＤ｝／Ｓｅｇｍｅｎｔｓ／｛ＳｅｇｍｅｎｔＩＤ｝”がＵＲＬテンプレートならば、“ＴｒａｃｋＩＤ”及び“ＳｅｇｍｅｎｔＩＤ”に、複数のメディアデータそれぞれの識別子及びそれぞれのメディアデータに含まれた少なくとも一つの部分の識別子を代入することで、メディアデータに対するＵＲＬを定義できる。
【００７９】
“ｈｅａｄｅｒＵｒｌ”タグは、図４Ｂと関連して前述した“ＲｅｆＤａｔａ”タグに対応する。言い換えれば、複数のメディアデータのヘッダＵＲＬを定義する。
【００８０】
“ｉｓＬｉｖｅ”タグは、ストリーミングがいかなるサービスと関連しているかを定義するタグである。例えば、“ｉｓＬｉｖｅ”タグが“Ｌｉｖｅ”と定義されれば、ストリーミングが生放送サービスと関連していることを表し、“ｉｓＬｉｖｅ”タグが”ＣｏＤ”と定義されれば、ストリーミングがＣｏＤサービスと関連していることを表す。
【００８１】
”ｃｏｎｔｅｎｔＴｙｐｅ”タグは、ストリーミングに用いられるメディアデータのコンテナフォーマットを定義する。例えば、メディアデータのコンテナフォーマットがＭＰ４フォーマットであるか、あるいはＭＰＥＧ２−ＴＳフォーマットであるかを表すための情報でありうる。
【００８２】
”Ｓｔｒｅａｍ”タグは、複数のメディアデータそれぞれに対して生成され、複数のメディアデータそれぞれを定義する。一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータそれぞれを定義するために、”ｓｔｒｅａｍＮａｍｅ”属性、”ｔｙｐｅ”属性、”ｂｉｔｒａｔｅ”属性、”ｓｔａｒｔＴｉｍｅ”属性、”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”属性、”ｄｕｒａｔｉｏｎ”属性、及び”ｉｎｔｅｒｖａｌＣｏｕｎｔ”属性を含む。
【００８３】
”ｓｔｒｅａｍＮａｍｅ”属性は、メディアデータの名称を定義する。メディアデータの識別子でありうる。”ｔｙｐｅ”属性は、メディアデータの類型を定義する。メディアデータがオーディオデータ、ビデオデータ及びオーディオ／ビデオデータのうちいかなるメディアのデータであるかを定義する。メディアデータが変速再生（ｔｒｉｃｋ ｐｌａｙ）のためにＩフレームに対するデータのみ含む場合には、これについての情報が”ｔｙｐｅ”属性と定義される。
【００８４】
”Ｂｉｔｒａｔｅ”属性は、メディアデータのビット率を定義し、”ｓｔａｒｔＴｉｍｅ”属性は、メディアデータの開始時間を特定するタイムスタンプを定義し、”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”属性は、最初に始まる部分の番号を定義する。
【００８５】
”ｄｕｒａｔｉｏｎ”属性は、メディアデータに含まれた部分の持続時間を定義し、”ｉｎｔｅｒｖａｌＣｏｎｕｎｔ”属性は、メディアデータに含まれた少なくとも一つの部分の全体数を定義する。
【００８６】
”Ｓｅｇｍｅｎｔ”タグは、”Ｓｔｒｅａｍ”タグの下位タグであり、メディアデータが、前述したようにコンデンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分ならば、このような少なくとも一つの部分それぞれを定義する。
【００８７】
”ＩｎｔＮｕｍ”属性は、部分の番号を定義し、”ＳｔａｒｔＴｉｍｅ”は、該当部分の開始時間を定義する。”Ｄｕｒａｔｉｏｎ”は、該当部分の持続時間を定義し、”ｕｒｌ”は、該当部分のＵＲＬ情報を定義する。
【００８８】
”Ｓｅｇｍｅｎｔ”タグは、選択的なタグであり、メディアデータに含まれた少なくとも一つの部分についての情報が”Ｓｔｒｅａｍ”タグの他の属性から類推される場合には、メディア表現技術に含まれない。言い換えれば、”Ｓｔｒｅａｍ”タグに定義された”ｓｔａｒｔＴｉｍｅ”、”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”、”ｄｕｒａｔｉｏｎ”及び”ｉｎｔｅｒｖａｌＣｏｕｎｔ”属性によって”Ｓｔｒｅａｍ”タグから類推される場合には、メディア表現技術に含まれない。また、”ｕｒｌＴｅｍｐｌａｔｅ”タグに所定のテンプレートが定義されており、このように定義されたテンプレートに、複数のメディアデータそれぞれの識別子及びそれぞれのメディアデータに含まれた少なくとも一つの部分の識別子を代入することで部分のＵＲＬ情報が類推できれば、”Ｓｅｇｍｅｎｔ”タグの”ｕｒｌ”属性は不要である。
【００８９】
図８Ｂを参照すれば、本発明のさらに他の実施形態によるメディア表現技術は、”ｎｅｘｔＭａｎｉｆｅｓｔＵＲＬ”タグをさらに含む。前述したように、ライブストリーミングまたは広告の挿入などのように一つのコンデンツストリーミングが完了すれば、次のコンデンツが続いてストリーミングされる場合には、次にストリーミングされるコンデンツ情報を、クライアント１３０が予め知っていて初めて、コンデンツをストリーミングし続けることができるので、現在ストリーミング中のコンデンツの次にストリーミングされるコンデンツのメディア表現技術のＵＲＬ情報が、”ｎｅｘｔＭａｎｉｆｅｓｔＵＲＬ”タグにより定義される。
【００９０】
図９Ａないし図９Ｈは、本願発明の一実施形態によるメディア表現技術を図示する。
【００９１】
図９Ａを参照すれば、本発明の一実施形態によるメディア表現技術は、”ＵＲＬＴｅｍｐｌａｔｅ”タグ、”ＲｅｆＤａｔａＵＲＬ”タグ及び複数のメディアデータそれぞれを定義する複数のタグを含む。
【００９２】
”ＵＲＬＴｅｍｐｌａｔｅ”タグ及び”ＲｅｆＤａｔａＵＲＬ”タグは、それぞれ図８Ａ及び図８Ｂの”ｕｒｌＴｅｍｐｌａｔｅ”タグ及び”ＲｅｆＤａｔａＵＲＬ”タグに対応する。
【００９３】
”ＩＤ”属性、”Ｔｙｐｅ”属性、”ＢｉｔＲａｔｅ”属性、”ＳｔａｒｔＴｉｍｅ”属性、”ＳｅｇｍｅｎｔＤｕｒａｔｉｏｎ”属性、”ＳｅｇｍｅｎｔＳｔａｒｔＩＤ”属性及び”ＳｅｇｍｅｎｔＣｏｕｎｔ”属性は、それぞれ図８Ａ及び図８Ｂの”ｓｔｒｅａｍＮａｍｅ”属性、”ｔｙｐｅ”属性、”ｂｉｔｒａｔｅ”属性、”ｓｔａｒｔＴｉｍｅ”属性、”Ｓｔｒｅａｍ”タグの”ｄｕｒａｔｉｏｎ”属性、”Ｓｔｒｅａｍ”タグの”ｆｉｒｓｔＩｎｔｅｒｖａｌＮｕｍ”属性及び”ｉｎｔｅｒｖａｌＣｏｕｎｔ”属性に対応する。
【００９４】
図９Ａに示したメディア表現技術は、コンデンツが相異なる品質に生成された３つのビデオデータ、一つのオーディオデータ及び変速再生のためにＩフレームのみエンコーディングして生成されたメディアデータについての情報を含む。
【００９５】
図９Ｂを参照すれば、本発明の一実施形態によるメディア表現技術は、”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグをさらに含む。”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグは、図８Ｂの”ｎｅｘｔＭａｎｉｆｅｓｔＵＲＬ”タグに対応する。したがって、現在再生中のコンデンツの次に続いて再生するコンデンツのメディア表現技術のＵＲＬが、”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグにより定義される。
【００９６】
図９Ｃは、現在再生中のコンデンツに続いて再生するコンデンツのメディア表現技術のＵＲＬが、図９Ｂの”ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ”タグにより定義された時、次に続いて再生するコンデンツのメディア表現技術を図示する。図９Ｂのメディア表現技術に比べれば、図９Ｃは、次に続いて再生されるコンデンツのメディア表現技術であるため、”ＳｔａｒｔＴｉｍｅ”属性の現在再生中のコンデンツのメディア表現技術と異なる。
【００９７】
図９Ｄ及び図９Ｅは、ユーザの高画質ビデオ再生を選択的に制御するためのメディア表現技術を図示する。一つのコンデンツを５種の相異なる品質にエンコーディングして複数のメディアデータが生成され、図９Ｄは、この場合のメディア表現技術を図示する。しかし、図９Ｅに示したメディア表現技術で高い品質にエンコーディングされたビデオについての情報を含んでいるタグ、すなわち、”ＩＤ”属性が”５”であるメディアデータの”ＳｔａｒｔＴｉｍｅ”属性及び”ＳｅｇｍｅｎｔＣｏｕｎｔ”属性が、図９Ｄのメディア表現技術と異なる。
【００９８】
サーバ１２０は、クライアント１３０のユーザ等級によって、図９Ｄのメディア表現技術または図９Ｅのメディア表現技術を選択的に伝送できる。クライアント１３０のユーザ等級が高い場合（例えば、クライアント１３０が有料ユーザである場合）には、図９Ｄのメディア表現技術を伝送することで、高品質のビデオも自由に再生させ、クライアント１３０のユーザ等級が低い場合（例えば、クライアント１３０が無料ユーザである場合）には、図９Ｅのメディア表現技術を伝送することで、高品質のビデオは、”ＳｔａｒｔＴｉｍｅ”属性により定義された時間から”ＳｅｇｍｅｎｔＣｏｕｎｔ”属性により定義された部分のみ再生可能にする。
【００９９】
図９Ｆは、コンデンツに広告が挿入される場合のメディア表現技術を図示する。図９Ｆを参照すれば、メディア表現技術は、”ＳｔａｒｔＴｉｍｅ”属性の相異なる広告コンデンツ及びメインコンデンツ情報を含む。メディア表現技術は、”００：００：００”から”００：０２：００”まで再生されるビット率”５０００００”の広告コンデンツ情報、及び”００：０２：００”から再生されるビット率”１００００００”、”２００００００”、”３００００００”及び”４００００００”のメインコンデンツ情報を含む。サーバ１２０が広告コンデンツを、一つのビット率によりエンコーディングしてクライアント１３０に提供し、広告コンデンツと”ＳｔａｒｔＴｉｍｅ”属性を異ならせるメインコンデンツは、４つの相異なるビット率によりエンコーディングしてクライアント１３０に提供する場合、図９Ｆのメディア表現技術がサーバ１２０からクライアント１３０に伝送される。
【０１００】
図９Ｇは、本発明の一実施形態による広告コンデンツ情報を含むメディア表現技術を図示する。メインコンデンツを提供するサーバと、広告コンデンツを提供するサーバとが相異なる。言い換えれば、クライアント１３０が、メインコンデンツは図５Ａのサーバ１２０から提供され、広告コンデンツは図５Ａのサーバ１２０ではない他のサーバから受信する場合、広告コンデンツ情報を含むメディア表現技術は、広告コンデンツのＵＲＬ情報を含む。図９Ｇに示したように、一つの品質に符号化された広告コンデンツのＵＲＬ情報がメディア表現技術に含まれる。
【０１０１】
図９Ｈは、本発明の一実施形態による言語情報及び字幕情報を含むメディア表現技術を図示する。図９Ｈを参照すれば、オーディオデータは多重言語についての情報を含む。”ＩＤ”属性が”４”及び”５”である多重言語のオーディオデータについての情報がメディア表現技術に含まれ、”ＩＤ”属性が”６”及び”７”である多重言語の字幕についての情報がメディア表現技術に含まれる。
【０１０２】
オーディオデータはもとより字幕も時間によって複数の部分に分割できるので、ストリーミング中にオーディオデータ及び字幕を、異なる言語のオーディオデータ及び字幕に変更できる。
【０１０３】
再び図５Ａを参照すれば、段階５３０で、クライアント１３０は、複数のメディアデータのうち少なくとも一つのメディアデータの伝送をサーバ１２０に要請する。クライアント１３０は、複数のメディアデータについての情報を参照して、ストリーミング環境に好適な品質に符号化された少なくとも一つのメディアデータを選択して、サーバ１２０に要請する。クライアント１３０は、所定のメディアデータの伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送できる。クライアント１２０の要請によって、サーバ１２０はメディアデータを伝送する。コンデンツを所定の品質にエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分をクライアント１２０に伝送できる。ＨＴＴＰ要請に対するＨＴＴＰ応答として要請されたメディアデータをクライアント１２０に伝送できる。
【０１０４】
図５Ｂは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【０１０５】
図５Ｂを参照すれば、段階５１２で、クライアント１３０は、所定のコンデンツ情報の伝送をサーバ１２０に要請し、サーバ１２０からコンデンツ情報を伝送する。所定のコンデンツ情報の伝送を要請するＨＴＴＰ要請をサーバ１２０に伝送し、これに対するＨＴＴＰ応答として、コンデンツ情報を受信する。コンデンツ情報を含むＸＭＬファイルを受信できる。
【０１０６】
段階５２２で、クライアント１３０は、段階５１２で受信されたコンデンツ情報に基づいて、複数のメディアデータについての情報をサーバ１２０に要請する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。
【０１０７】
段階５３２で、クライアント１３０は、段階５２２で受信された複数のメディアデータについての情報に基づいて選択されたメディアデータのヘッダを要請する。段階５２２で受信された情報に基づいて、複数のメディアデータのうちストリーミング環境に好適な少なくとも一つのメディアデータを選択し、選択されたメディアデータのヘッダを要請する。段階５２２で受信された複数のメディアデータについての情報を参照して選択されたメディアデータのヘッダを要請する。サーバ１２０は、要請に対する応答として、選択されたメディアデータのヘッダファイルをクライアント１３０に伝送する。
【０１０８】
段階５４２でクライアント１３０は、段階５２２で受信された複数のメディアデータについての情報、及び段階２２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。コンデンツを所定の割合でエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分の伝送をサーバ１３０に要請し、サーバ１２０は、要請された少なくとも一つの部分をクライアント１３０に伝送する。
【０１０９】
図１０Ａないし図１０Ｃは、本発明の一実施形態による複数のメディアデータを図示する。図１０Ａないし図１０Ｃは、図５Ａ及び図５Ｂによるストリーミング方法を行うために、サーバ１２０が保有する複数のメディアデータを図示する。
【０１１０】
図１０Ａを参照すれば、ストリーミング環境に適応的なストリーミングのために、サーバ１２０は、一つのコンデンツを複数の相異なる品質にエンコーディングして生成された複数のメディアデータ１０１０ないし１０３０を保有できる。”Ｔｒａｃｋ１”、”Ｔｒａｃｋ２”、…、”ＴｒａｃｋＮ”が複数のメディアデータである。また、それぞれのメディアデータは、それぞれのメディアデータを時間に基づいて分割して生成された少なくとも一つの部分を含む。”Ｓｌｉｃｅ１−１．ａｓ”、”Ｓｌｉｃｅ１−２．ａｓ”、”Ｓｌｉｃｅ１−３．ａｓ”、”Ｓｌｉｃｅ２−１．ａｓ”、”Ｓｌｉｃｅ２−２．ａｓ”、”Ｓｌｉｃｅ２−３．ａｓ”、”ＳｌｉｃｅＮ−１．ａｓ”、”ＳｌｉｃｅＮ−２．ａｓ”、”ＳｌｉｃｅＮ−３．ａｓ”などが少なくとも一つの部分である。
【０１１１】
また、サーバ１２０は、クライアント１３０の複数のメディアデータへのアクセスに必要な情報１０４０を保有できる。コンデンツ情報として”ＣａｄＭｅｔａ．ｘｍｌ”ファイル、複数のメディアデータについての情報として”ＭａｉｎＭｅｔａ．ｘｍｌ”ファイルを保有でき、複数のメディアデータのヘッダとして”Ｈｅａｄ１．ｒｅｆ”、”Ｈｅａｄ２．ｒｅｆ”ファイルなどを保有できる。”Ｈｅａｄ１．ｒｅｆ”は”Ｔｒａｃｋ１”のヘッダファイルであり、”Ｈｅａｄ２．ｒｅｆ”は”Ｔｒａｃｋ２”のヘッダファイルでありうる。
【０１１２】
”ＣａｄＭｅｔａ．ｘｍｌ”はＯＩＰＦ標準によるＣＡＤファイルであり、”ＭａｉｎＭｅｔａ．ｘｍｌ”は前述したメディア表現技術でありうる。また、”Ｈｅａｄ１．ｒｅｆ”、”Ｈｅａｄ２．ｒｅｆ”ファイルは選択的な要素であり、ヘッダが複数のメディアデータ１０１０ないし１０３０に含まれている場合には存在しない。
【０１１３】
図１０Ｂを参照すれば、クライアント１３０の複数のメディアデータへのアクセスに必要な情報１０４２は、”ＮｅｘｔＭｅｔａ．ｘｍｌ”をさらに含む。前述したように、”ＮｅｘｔＭｅｔａ．ｘｍｌ”は、現在再生中のコンデンツに続いて再生される次のコンデンツのメディア表現技術でありうる。前述したように、現在再生中のメディア表現技術、すなわち、”ＭａｉｎＭｅｔａ．ｘｍｌ”ファイルは、続いて再生するコンデンツのメディア表現技術のＵＲＬ情報を含んでいるところ、これに基づいてクライアント１３０は、”ＮｅｘｔＭｅｔａ．ｘｍｌ”ファイルにアクセスできる。
【０１１４】
図１０Ｃを参照すれば、複数のメディアデータのヘッダは、一つのファイル１０５０に存在できる。ヘッダファイルが複数のメディアデータそれぞれに対して複数で存在するものではなく、一つのヘッダファイル１０５０として複数のメディアデータにアクセスするために必要な情報１０４４に含まれる。
【０１１５】
例えば、複数のメディアデータそれぞれがＭＰＥＧ−２によるエレメンタリーストリーム（ｅｌｅｍｅｎｔａｒｙ ｓｔｒｅａｍ）に対応する時、複数のメディアデータのヘッダは、ＰＡＴ（Ｐｒｏｇｒａｍ）及びＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）のうち少なくとも一つを含む一つのヘッダファイル１０５０でありうる。ＰＡＴ及びＰＭＴのうち少なくとも一つを、複数のメディアデータ１０１０ないし１０３０と分離して一つのヘッダファイル１０５０を作り、メディア表現技術は、このヘッダファイル１０５０を指示（Ｐｏｉｎｔｉｎｇ）する情報を含む。ヘッダファイル１０５０の指示情報は、ヘッダファイル１０５０のＵＲＬ情報でもあり、ＭＰＥＧ−２伝送ストリーム（ｔｒａｎｓｐｏｒｔ ｓｔｒｅａｍ）でヘッダファイル１０５０を含んでいるパケットを特定するための情報でもありうる。
【０１１６】
前述した段階５３２で、クライアント１３０は、メディア表現技術を参照してヘッダファイル１０５０の指示情報を獲得し、指示情報に基づいてヘッダファイル１０５０を要請できる。指示情報にヘッダファイル１０５０を要請して受信した後、ヘッダファイル１０５０に含まれているＰＡＴ及びＰＭＴのうち少なくとも一つに基づいて、複数のメディアデータのうち少なくとも一つを選択し、選択されたメディアデータをサーバ１２０に要請する。ＰＡＴ及びＰＭＴは、複数のメディアデータ１０１０ないし１０３０の全体リストを含む。
【０１１７】
ＭＰＥＧ−２によれば、ＰＡＴ及びＰＭＴで定義されるＰＩＤ（Ｐａｃｋｅｔ ＩＤ）は、エレメンタリーストリームによって異なる。したがって、複数のメディアデータそれぞれに割り当てられるＰＩＤは相異なる。しかし、さらに他の実施形態によれば、一つのコンデンツを相異なる品質にエンコーディングして生成された複数のメディアデータは、同じコンデンツに対するエレメンタリーストリームであるため、ＰＩＤが同一に設定されてもよい。
【０１１８】
複数のメディアデータ１０１０ないし１０３０がＭＰＥＧ−２による複数のエレメンタリーストリームに対応する場合、複数のメディアデータ１０１０ないし１０３０それぞれは、複数の連続するＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ）を含む。
【０１１９】
複数のメディアデータは、一つのコンデンツを相異なる品質にエンコーディングして生成されたものであるので、複数のメディアデータそれぞれに含まれたＰＥＳのＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）及び／またはＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）は、メディアデータの再生時間によって整列（ａｌｉｇｎｅｄ）される。言い換えれば、第１メディアデータの最初のＰＥＳと第２メディアデータの最初のＰＥＳとが同じ時間に再生されるコンデンツならば、ＰＴＳ及び／またはＤＴＳが同一に設定される。
【０１２０】
図１１Ａは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【０１２１】
図１１Ａを参照すれば、段階１１１０で、クライアント１３０は、複数のメディアデータについての情報をサーバ１２０に要請する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。クライアント１３０は、ストリーミング環境に適応的なストリーミングを行うために、一つのコンデンツを複数の相異なる品質にエンコーディングして生成された複数のメディアデータについての情報をサーバ１２０に要請し、受信する。コンデンツ情報の要請及び受信なしに、複数のメディアデータについての情報の要請及び受信が行われるという点が、図５Ａに示した実施形態と異なる。
【０１２２】
段階１１２０で、クライアント１３０は、複数のメディアデータのうち少なくとも一つのメディアデータの伝送をサーバ１２０に要請する。クライアント１３０は、複数のメディアデータについての情報を参照して、ストリーミング環境に好適な品質に符号化された少なくとも一つのメディアデータを選択してサーバ１２０に要請し、要請されたメディアデータをサーバ１２０から受信する。
【０１２３】
図１１Ｂは、本発明のさらに他の実施形態によるストリーミング方法を説明するためのフローチャートである。
【０１２４】
図１１Ｂを参照すれば、段階１１１２で、クライアント１３０は、複数のメディアデータについての情報をサーバ１２０に要請し、要請に対する応答として、複数のメディアデータについての情報をサーバ１２０から受信する。メディア表現技術を、ＨＴＴＰ要請を通じてサーバ１２０に要請し、ＨＴＴＰ応答としてメディア表現技術を受信できる。
【０１２５】
段階１１２２で、クライアント１３０は、段階１１１２で受信された複数のメディアデータについての情報に基づいて選択されたメディアデータのヘッダを要請する。段階５２２で受信された複数のメディアデータについての情報を参照して、ストリーミング環境によって選択されたメディアデータのヘッダを要請する。サーバ１２０は、要請に対する応答として、選択されたメディアデータのヘッダを含むファイルをクライアント１３０に伝送する。
【０１２６】
段階１１３２で、クライアント１３０は、段階１１１２で受信された複数のメディアデータについての情報、及び段階１１２２で受信されたヘッダに基づいて選択されたメディアデータの伝送をサーバ１２０に要請する。コンデンツを所定の割合でエンコーディングし、時間に基づいて分割して生成された少なくとも一つの部分の伝送をサーバ１３０に要請し、サーバ１２０は、要請された少なくとも一つの部分をクライアント１３０に伝送する。
【０１２７】
図１２Ａ及び図１２Ｂは、本発明のさらに他の実施形態による複数のメディアデータを図示する。図１２Ａ及び図１２Ｂは、図１１Ａ及び図１１Ｂによるストリーミング方法を行うために、サーバ１２０が保有する複数のメディアデータを図示する。
【０１２８】
図１２Ａを参照すれば、図１０Ａに示した実施形態と同様に、ストリーミング環境に適応的なストリーミングのために、サーバ１２０は、一つのコンデンツを複数の相異なる品質にエンコーディングして生成された複数のメディアデータ１０１０ないし１０３０を保有できる。
【０１２９】
クライアント１３０の複数のメディアデータへのアクセスに必要な情報１２４０のみ相異なるところ、図１０Ａに示した実施形態とは異なって、サーバ１２０は、コンデンツ情報を除外した複数のメディアデータについての情報のみ含む。この場合、クライアント１３０は、コンデンツ情報を、サーバ１２０ではない他のエンティティから受信し、コンデンツ情報に基づいてサーバ１２０が保有している複数のメディアデータにアクセスしてもよい。
【０１３０】
図１２Ｂを参照すれば、クライアント１３０の複数のメディアデータへのアクセスに必要な情報１２４２は、図１２Ａの情報１２４０に”ＮｅｘｔＭｅｔａ．ｘｍｌ”をさらに含む。
【０１３１】
図１３は、本発明の一実施形態によるデータ伝送システムの動作方法についてのフローチャートである。
【０１３２】
本発明の一実施形態によるデータ伝送システムは、サーバ１３０１及びクライアント１３０２を備える。
【０１３３】
段階ｓ１３１０で、サーバ１３０１は、一つ以上のコンポーネントを含む一つ以上のメディアデータを生成し、メディアデータについての情報を生成する。以下では、説明の便宜のために、サーバ１３０１で生成されたメディアデータのうち一つを第１メディアデータと称し、第１メディアデータを中心として伝送システムの動作方法を説明する。
【０１３４】
サーバ１３０１は、提供しようとするマルチメディアデータに含まれた少なくとも一つのコンテンツをエンコーディングして複数のコンポーネントを生成する。サーバ１３０１は、関連する複数の相異なるコンテンツをエンコーディングして同じタイプの複数のコンポーネントを生成してもよい。一例として、サーバ１３０１は、英語のオーディオコンテンツを用いて第１オーディオコンポーネントを生成し、韓国語のオーディオコンテンツを用いて第２オーディオコンポーネントを生成する。第１オーディオコンポーネントと第２オーディオコンポーネントとは、同じタイプのコンポーネントであるが、相異なるコンテンツを用いて生成されたものである。
【０１３５】
また、サーバ１３０１は、同じコンテンツを相異な方式でエンコーディングして複数のコンポーネントを生成できる。一例として、図１ないし図１２で前述したように、同じコンテンツを相異なる品質にエンコーディングすることで、ビットレートの相異なる複数のコンポーネントを生成できる。
【０１３６】
サーバ１３０１は、生成されたコンポーネントのうち少なくとも一つを含む第１メディアデータを生成する。第１メディアデータは、可能なあらゆるタイプのコンポーネントを含んでもよいが、一部タイプのコンポーネントのみ含んでもよい。一例として、サーバ１３０１でビデオコンポーネント、オーディオコンポーネント及びサブタイトルコンポーネントを生成した場合、第１メディアデータは、ビデオコンポーネント、オーディオコンポーネント及びサブタイトルコンポーネントをいずれも含んでもよいが、ビデオコンポーネントのみ含んでもよい。本明細書では、可能なあらゆるタイプのコンポーネントが含まれたメディアデータを、フル・リフリゼンテーション（ｆｕｌｌ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎまたはｃｏｍｐｌｅｔｅ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と称し、一部タイプのコンポーネントのみ含まれたメディアデータを、パーシャル・リフリゼンテーション（ｐａｒｔｉａｌ−ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）と称する。パーシャル・リフリゼンテーションに含まれたコンポーネントは、他のパーシャルリフリゼンテーションに含まれたコンポーネントと共に処理されて、デコーダに提供される。
【０１３７】
第１メディアデータについての情報は、第１メディアデータに含まれたコンポーネントが第２メディアデータに含まれたコンポーネントと共に提供されるかどうかを表す情報を含む。すなわち、第１メディアデータがパーシャル・リフリゼンテーションであるかどうかを表す情報を含む。
【０１３８】
また、第１メディアデータについての情報は、第１メディアデータに含まれた少なくとも一つのコンポーネントについての情報であるコンポーネント情報を含む。第１メディアデータについての情報の一例は、図１５、図１７及び図１８で後述し、コンポーネント情報についての一例は、図１４及び図１６で後述する。
【０１３９】
段階ｓ１３２０で、サーバ１３０１は、第１メディアデータについての情報をクライアント１３０２に伝送する。第１メディアデータについての情報は、コンデンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイル（例えば、メディア表現技術）に含まれて伝送される。
【０１４０】
段階ｓ１３３０で、クライアント１３０２は、第１メディアデータについての情報に基づいて、第１メディアデータに含まれた少なくとも一つのコンポーネントをサーバ１３０１に要請する。クライアント１３０２がコンポーネントを要請して処理する具体的な過程は、図２１で後述する。
【０１４１】
クライアント１３０２は、メディア表現技術に含まれた複数のメディアデータのうち少なくとも一つのメディアデータを選択する。クライアント１３０２は、ユーザがパーシャル・リフリゼンテーションを所望するか、あるいはフル・リフリゼンテーションを所望するかを判断する。ユーザから別途の入力がない場合にフル・リフリゼンテーションが薦められる。
【０１４２】
ユーザの要請または通信環境に基づいて、適切なビットレートを持つ第１メディアデータを選択する。次いで、クライアント１３０２は、第１メディアデータのヘッダ情報を獲得し、第１メディアデータに含まれた少なくとも一つのコンポーネントをサーバ１３０１に要請する。第１メディアデータに複数のコンポーネントが含まれた場合には、クライアント１３０２の所望するコンポーネントを選択的に要請できる。
【０１４３】
段階ｓ１３４０で、サーバ１３０１は、クライアント１３０２が要請した第１メディアデータに含まれたコンポーネントを伝送する。
【０１４４】
段階ｓ１３５０で、クライアント１３０２は、受信されたコンポーネントを処理する。第１メディアデータがパーシャル・リフリゼンテーションであり、ユーザが第２メディアデータを追加的に選択したならば、クライアント１３０２は、第２メディアデータに含まれたコンポーネントをさらに受信して処理する。クライアント１３０２は、第１メディアデータに含まれたコンポーネントと、第２メディアデータに含まれたコンポーネントとを結合して、ユーザの所望するデータを出力する。
【０１４５】
従来には、フル・リフリゼンテーションのみ定義され、パーシャル・リフリゼンテーションは定義されていない。すなわち、サーバ１３０１は、あらゆるタイプのコンポーネントを含むメディアデータ、すなわち、フル・リフリゼンテーションのみ生成した。
【０１４６】
したがって、クライアント１３０２は、一回に一つのメディアデータに対するセグメントをダウンロードして処理する。かかる方式は比較的簡単で明らかではあるが、柔軟性の面では多くの短所を持っている。同じタイプのコンポーネントに多様な代案が存在する場合、サーバ１３０１は、それぞれの代案に対応する複数のメディアデータを生成せねばならない。例えば、同じビデオコンテンツを相異なるビット率でエンコーディングある４つのビデオコンポーネントが存在し、相異なる言語の３つのサブタイトルが存在する場合、サーバ１３０１は、コンポーネントの組み合わせの数に該当する１２つのメディアデータを生成せねばならない。これは、サーバ１３０１の保存空間を大きく無駄遣いさせる結果を招く。サーバ１３０１は、一般的に相異なるＵＲＬによって指示されるコンテンツ間のプロトコルや類似性が分からないため、サーバ１３０１が最適化するとしても（例えば、ディスクに別途に保存されたＥＳから、リアルタイムでメディアデータのセグメントを生成できるとしても）、コンテンツ伝送ネットワーク（ｃｏｎｔｅｎｔ ｄｅｌｉｖｅｒｙ ｎｅｔｗｏｒｋ、ＣＤＮ）にかかる方式を適用するのが容易でなかった。
【０１４７】
しかし、本発明の一実施形態では、サーバ１３０１が一部タイプのコンポーネントのみを含むメディアデータ、すなわち、パーシャル・リフリゼンテーションを生成することで、クライアント１３０２は、所望のメディアデータを確認し、これらに対するセグメントを独立的にダウンロードした後、メディアデータに含まれたコンポーネントを組み合わせて所望のデータを出力する。この場合、サーバ１３０１は、ビットレートによるビデオコンポーネントを含む４つのメディアデータと、３つの相異なる言語によるサブタイトルを含む３つのメディアデータのみを生成してもよい。他の実施形態では、サーバ１３０１が、ビットレートによるビデオコンポーネントと、特定言語のサブタイトルコンポーネントとを含む４つのメディアデータと、残りの２つの言語によるサブタイトルを含む２つのメディアデータのみを生成すれば十分である。このような方式で、サーバ１３０１で要求される保存空間及び負荷を急減させることができる。
【０１４８】
図１４は、本発明の一実施形態によるコンポーネント情報についての一例を示す。
【０１４９】
図１４の表は、図１５の‘ＰａｒｔｉａｌＴｙｐｅ’の属性値１４０１によるコンポーネント情報１４０２を表す。説明の便宜のために、コンポーネントは第１メディアデータに含まれると仮定する。
【０１５０】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｖｉｄｅｏ’１４１０である場合、第１メディアデータはビデオＥＳを含むことを表す。
【０１５１】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ａｕｄｉｏ’１４２０である場合、第１メディアデータは、オーディオＥＳを含むことを表す。
【０１５２】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｍｕｌｔｉｐｌｅｘ−ＡＶ’１４３０である場合、第１メディアデータは、ビデオデータとオーディオデータとが多重化されたＥＳを含むことを表す。
【０１５３】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｍｕｌｔｉｐｌｅｘ−ＡＳ’１４４０である場合、第１メディアデータは、ビデオデータとサブタイトルデータとが多重化されたＥＳを含むことを表す。
【０１５４】
‘ＰａｒｔｉａｌＴｙｐｅ’の属性値が‘Ｓｕｂｔｉｔｌｅ’１４５０である場合、第１メディアデータは、サブタイトルＥＳを含むことを表す。
【０１５５】
図１５は、本発明の一実施形態によるメディアデータについての情報についての一例を示す。
【０１５６】
図１５は、ＸＭＬファイルで具現されたＭＰＤの一例である。それぞれのメディアデータについての情報は、対応する＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに含まれる。
【０１５７】
＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性は、”ｏｉｐｆ：ＲｅｐｒｅｓｅｎｔａｔｉｏｎＴｙｐｅ”に設定される。この場合、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグは、‘ｐａｒｔｉａｌＴｙｐｅ’属性及び‘ｓｗｉｔｃｈＧｒｏｕｐ’属性を含む。
【０１５８】
‘ｐａｒｔｉａｌＴｙｐｅ’属性は、対応するメディアデータがパーシャル−プレゼンテーションであることを表す。すなわち、＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグが表すメディアデータに含まれた個別的なコンポーネント（ビデオ、オーディオ、サブタイトルなど）がサーバからダウンロードされた後、他の＜Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞が表すメディアデータを通じて獲得されるデータと共にデコーダに提供されることを意味する。
【０１５９】
‘ｐａｒｔｉａｌＴｙｐｅ’属性は、図１４に示したテーブルの値１４０１のうち一つを持つ。
【０１６０】
‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の場合、同じコンデンツを相異なる品質にエンコーディングして生成されたコンポーネントを持つメディアデータは同じ値を持つ。しかし、タイプは同一であるものの相異なるコンテンツを用いて生成されたメディアデータは、相異なる属性値を持つ（例えば、２つの異なる言語のオーディオコンポーネント）。
【０１６１】
＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性は、‘ｏｉｐｆ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔＴｙｐｅ’に設定される。この場合、＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグは、‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性を含む。
【０１６２】
‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性は、メディアデータのヘッダ（ｉｎｉｔｉａｌｉｚａｔｉｏｎ ｓｅｇｍｅｎｔ）についての参考を提供する。＜ｐｓｓ：Ｐｅｒｉｏｄ＞タグ内の＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグに‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性が存在する場合、ヘッダは、あらゆるメディアデータ（パーシャル・リフリゼンテーション、フル・リフリゼンテーション）に対するサンプルを説明するメタデータを提供する（例えば、ＭＰ４のｍｏｏｖ、ＴＳのＰＡＴ／ＰＭＴ）。
【０１６３】
図１６は、本発明の他の実施形態によるコンポーネント情報についての一例を示す。
【０１６４】
図１６の表は、図１７の‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’の属性値１６０１によるコンポーネント情報１６０２を表す。‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’属性は、‘ｉｄ’属性１６１０、‘Ｔｙｐｅ’属性１６２０、‘Ｌａｎｇ’属性１６３０、‘Ａｎｇｌｅ’属性１６４０、‘Ｃｈａｎｎｌｅｓ’属性１６５０及び‘Ｉｍｐａｒｉｅｄ’属性１６６０を含む。
【０１６５】
‘ｉｄ’属性１６１０は、メディアデータに含まれたコンポーネントの識別子を表す。識別子の形態は、コンテナによって異なる。一例として、ＭＰＥＧ２−ＴＳではＰＩＤが使われ、ＭＰ４ではＴｒａｃｋＩＤが使われる。その他にも、ユーザが任意に識別子の形態を指定できる。
【０１６６】
‘Ｔｙｐｅ’属性１６２０は、コンポーネントのタイプを表す。一例として、コンポーネントは、ビデオコンポーネント、オーディオコンポーネント及びサブタイトルコンポーネントのうち少なくとも一つでありうる。
【０１６７】
‘Ｌａｎｇ’属性１６３０は、オーディオコンポーネントまたはサブタイトルコンポーネントに対する言語コードを表す。言語コードは、ＲＣＦ５６４６による言語コードでありうる。
【０１６８】
‘Ａｎｇｌｅ’属性１６４０は、ビデオコンポーネントに対するカメラアングルを表す。
【０１６９】
‘Ｃｈａｎｎｌｅｓ’属性１６５０は、オーディオコンポーネントに対するオーディオチャネル（例えば、５．１チャネル、２．１チャネルなど）を表す。
【０１７０】
‘Ｉｍｐａｒｉｅｄ’属性１６６０は、障害のあるユーザのためのデータが提供されるを表す情報である。一例として、聴覚障害者のためのデータが提供されることを表す。
【０１７１】
図１７は、本発明の他の実施形態によるメディアデータについての情報についての一例を示す。
【０１７２】
図１７は、ＸＭＬファイルで具現されたＭＰＤの一例である。
【０１７３】
＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性が”ｏｉｐｆ：ＲｅｐｒｅｓｅｎｔａｔｉｏｎＴｙｐｅ”に設定される場合、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグは、次の属性を含む。
【０１７４】
‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性は、メディアデータが‘フル・リフリゼンテーション’ではなく‘パーシャル・リフリゼンテーション’であることを表す。すなわち、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに対応するメディアデータに含まれた少なくとも一つのコンポーネントは（例えば、個別的なビデオ、オーディオまたはサブタイトルを提供するＴｒａｃｋ／ＥＳ）、他のメディアデータを通じてダウンロードされるデータと共にデコーダに提供される。
【０１７５】
‘ｐａｒｔｉａｌＣｏｍｐｏｎｅｎｔｓ２属性は、メディアデータに含まれるそれぞれのコンポーネントを説明する。‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性の値は、メディアデータに含まれたそれぞれのコンポーネントについての情報のリストをセミコロン（またはコロン）で区切ったストリングでありうる。コンポーネントについての情報には、図１６に示した属性が含まれる。ただし、所望のコンポーネントを選択し、これによりデコーダを設定するのはアプリケーションが担当する。
【０１７６】
‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性は、同じ機能を行う他のタイトルで代替できる。一例として、‘Ｐａｔｉａｌ’属性、‘ＰａｔｉａｌＴｙｐｅ’属性‘Ｃｏｍｐｏｎｅｎｔ’などで代替できる。
【０１７７】
図１７では、‘ｐａｒｔｉａｌＣｏｍｐｏｎｔｓ’属性を通じて対応するメディアデータがパーシャル・リフリゼンテーションであるかどうかを表すと仮定した。しかし、実施形態によっては、図１７に示した他の属性がメディアデータがパーシャル・リフリゼンテーションであるかどうかを表すか、図１７に図示されていない新たな属性が、メディアデータがパーシャル・リフリゼンテーションであるかどうかを表すこともある。
【０１７８】
‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の場合、同じコンテンツを異なる方式でエンコーディングしたコンポーネント（例えば、同じコンテンツを異なる品質にエンコーディングして生成されたコンポーネント）を含むメディアデータについては、同じ属性値を持つ。しかし、タイプは同一であるものの、異なるコンテンツを用いて生成されたコンポーネント（例えば、２つの相異なる言語に対するオーディオコンポーネント）を含むメディアデータに対しては、異なる属性値を持つ。したがって、‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の値が相異なる複数のメディアデータに含まれたコンポーネントは、組み合わせられて同時に再生されるが、‘ｓｗｉｔｃｈＧｒｏｕｐ’属性の値の同じメディアデータは、同時に再生されない。
【０１７９】
＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグ内の‘ｘｓｉ：ｔｙｐｅ’属性は、‘ｏｉｐｆ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔＴｙｐｅ’に設定され、この場合、＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグは、次のタグ及び属性を含む。
【０１８０】
‘ｐｓｓ：ＩｎｉｔｉａｌｉｓａｔｉｏｎＳｅｇｍｅｎｔＵＲＬ’属性は、ヘッダ（Ｉｎｉｔｉａｌｉｓａｔｉｏｎ Ｓｅｇｍｅｎｔ）に対する参考を表す。本属性が＜ｐｓｓ：Ｐｅｒｉｏｄ＞タグ内の＜ｐｓｓ：ＳｅｇｍｅｎｔＩｎｆｏＤｅｆａｕｌｔ＞タグに存在するならば、参考になったヘッダがあらゆるメディアデータ（パーシャル・リフリゼンテーション及びフル・リフリゼンテーション）に対するメタデータを提供する（例えば、ＭＰ４のｍｏｏｖ、ＴＳのＰＡＴ／ＰＭＴ）。
【０１８１】
図１８は、本発明のさらに他の実施形態によるメディアデータについての情報の一例を示す。
【０１８２】
図１８は、ＸＭＬファイルで具現されたＭＰＤの一例である。それぞれのメディアＸＭＬファイル内の＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに含まれ、コンポーネント情報は、‘ｏｐｉｆ：Ｃｏｍｐｏｎｅｎｔ’属性に含まれる。
【０１８３】
＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグは‘ｇｒｏｕｐ’属性を含む。‘ｇｒｏｕｐ’属性が‘０ ’でない値を持つならば、対応するメディアデータがフル・リフリゼンテーションである必要はなく、パーシャル・リフリゼンテーションでありうることを表す。すなわち、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに対応するメディアデータに含まれた少なくとも一つのコンポーネントは（例えば、個別的なビデオ、オーディオまたはサブタイトルを提供するＴｒａｃｋ／ＥＳ）、他のメディアデータを通じてダウンロードされるデータに追加されてデコーダに提供される。この場合、＜Ｃｏｍｐｏｎｅｎｔ＞タグは、＜ｐｓｓ：Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ＞タグに含まれた一つ以上のコンポーネントについての情報を含む。＜Ｃｏｍｐｏｎｅｎｔ＞タグは、図１６で定義された属性を含む。
【０１８４】
‘ｇｒｏｕｐ’属性の場合、少なくとも一つの同じコンポーネントを含むメディアデータに対しては同じ値を持つ。しかし、同じタイプの完全に相異なるコンポーネント（例えば、相異なる言語からなるオーディオコンポーネント）を持つ複数のメディアデータに対しては相異なる値を持つ。
【０１８５】
図１９は、本発明の一実施形態によるデータ伝送装置１９００についてのブロック図である。
【０１８６】
本発明の一実施形態によるデータ伝送装置１９００は、情報生成部１９１０、情報伝送部１９２０及びコンポーネント伝送部１９３０を備える。
【０１８７】
情報生成部１９１０は、少なくとも一つのコンポーネントを含む第１メディアデータについての情報を生成する。情報生成部１９１０は、一つのコンテンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイルを生成でき、このファイルに第１メディアデータについての情報を挿入する。
【０１８８】
第１メディアデータについての情報は、少なくとも一つのコンポーネントが、第２メディアデータから獲得したコンポーネントと共にデータ受信装置２０００内のデコーダに提供されるかどうかを表す情報、及び少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報を含む。
【０１８９】
コンポーネント情報は、第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含む。コンポーネント情報は、少なくとも一つのコンポーネントの識別情報、オーディオコンポーネントについてのチャネル情報、言語コード情報及び損傷（ｉｍｐａｉｒｅｄ）情報、サブタイトルコンポーネントについての言語情報、及び損傷情報サブタイトルコンポーネントについての言語情報、及び損傷情報ビデオコンポーネントについてのカメラ角度情報のうち少なくとも一つをさらに含む。
【０１９０】
第１メディアについての情報は、複数のメディアデータそれぞれが、同じコンテンツをエンコーディングして生成されたコンポーネントを含んでいるかどうかを表す情報をさらに含む。一例として、第１メディアデータと第２メディアデータとが同じコンテンツをエンコーディングして生成されたコンポーネントをそれぞれ含めば、特定フィールドの値を同じ値に設定し、第１メディアデータと第２メディアデータとが、同じタイプの相異なるコンテンツ（例えば、言語の相異なるオーディオコンテンツ）をエンコーディングして生成されたコンポーネントをそれぞれ含めば、特定フィールドの値を異なる値に設定できる。
【０１９１】
図２０は、本発明の一実施形態によるデータ受信装置２０００についてのブロック図である。
【０１９２】
情報受信部２０１０は、第１メディアデータについての情報を受信する。第１メディアデータについての情報は、少なくとも一つのコンポーネントが第２メディアデータから獲得したコンポーネントと共に提供されるかどうかを表す情報を含む。
【０１９３】
コンポーネント受信部２０２０は、第１メディアデータについての情報に基づいて少なくとも一つのコンポーネントを獲得する。
【０１９４】
図２１は、本発明の他の実施形態によるデータ受信方法についてのフローチャートである。
【０１９５】
段階ｓ２１１０では、ＭＰＤを獲得する。
【０１９６】
段階ｓ２１２０では、ＭＰＤがパーシャル・リフリゼンテーション及びフル・リフリゼンテーションをいずれも含む場合、ユーザからの入力に基づいてこれらのうち一つを選択する。別の入力がない場合、パーシャル・リフリゼンテーションの選択が薦められる。
【０１９７】
パーシャル・リフリゼンテーションが選択されれば、段階ｓ２１４１を行い、それとも段階ｓ２１３１を行う。
【０１９８】
段階ｓ２１３１では、ＭＰＤ内のメタデータに基づいて初期メディアデータを選択する。一般的に、メディアデータのビットレートに基づいて初期メディアデータを選択する。
【０１９９】
段階ｓ２１３２で、メディアデータのヘッダが存在すれば、ヘッダを獲得する。
【０２００】
段階ｓ２１３３で、メディアデータからメディアセグメントを獲得する。
【０２０１】
段階ｓ２１３４で、獲得したヘッダ及びメディアセグメントからＥＳを獲得する。この時、一つのオーディオストリームと一つのビデオストリームとを選択することが一般的である。もし、他の代案があれば、これら代案からＥＳを選択してもよい。
【０２０２】
段階ｓ２１３５で、選択されたＥＳを再生するために再生器を設定し、ＥＳを再生する。
【０２０３】
段階ｓ２１３６で、再生途中でユーザがヘッダ／メディアセグメント内の他のＥＳへの交替を要請するか、他のＥＳの追加を要請するかどうかを判断する。別の要請がない場合、段階ｓ２１３５によって選択されたＥＳを処理し続け、要請がある場合（例えば、他のビットレートへの転換）、要請されたフル・リフリゼンテーションを選択して段階ｓ２１３２を進める。
【０２０４】
段階ｓ２１４１では、ＭＰＤ内のメタデータに基づいて（例えば、‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’属性または‘Ｂａｎｄｗｉｄｔｈ’属性）、所望のＥＳが含まれたメディアデータを選択する。
【０２０５】
段階ｓ２１４２で、該当ピリオド内でのヘッダを獲得する。
【０２０６】
段階ｓ２１４３で、メディアデータでメディアセグメントを獲得する。
【０２０７】
段階ｓ２１４４で、獲得したヘッダ及びメディアセグメントからＥＳを獲得する。
【０２０８】
段階ｓ２１４５で、ヘッダまたはコンポーネント情報から獲得された情報を用いて、選択されたＥＳを再生できるように再生器を構成する。‘ＰａｒｔｉａｌＣｏｍｐｏｎｅｎｔ’属性にＩＤフィールドが存在するならば、ＭＰＤ内のストリームと、ヘッダから抽出されたメタデータ内のストリームとの間の正確なマッピングが可能である。この場合、ヘッダをパージングせずに‘ＴｒａｃｋＩＤ’または‘ＰＩＤ’を再生器に伝送できる。
【０２０９】
段階ｓ２１４６で、選択されたＥＳを再生するために再生器を設定し、ＥＳを再生する。
【０２１０】
段階ｓ２１４７で、再生途中でヘッダまたはメディアセグメント内の他のＥＳの選択または他のＥＳの追加要請が受信されるかどうかを判断する。別の要請がない場合、段階ｓ２１４６によって選択されたＥＳを進め続け、他のＥＳが選択された場合（例えば、他のビットレートへの転換）、段階ｓ２１４８に進める。
【０２１１】
段階ｓ２１４８では、選択されたパーシャル・リフリゼンテーションの‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値と、以前パーシャル・リフリゼンテーションの‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値とが同一であるかどうかを判断する。属性値が同一ならば、段階ｓ２１４４を進め、それとも段階ｓ２１４２を進める。
【０２１２】
具体的に、ユーザが‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値の同じ他のパーシャル−プレゼンテーションを選択すれば（例えば、ビットレートの相異なるコンポーネントが含まれたメディアデータ）、段階ｓ２１４４を進める。一方、ユーザが‘ＳｗｉｔｃｈＧｒｏｕｐ’属性値の相異なる他のパーシャル−プレゼンテーションを選択するか、または追加すれば、段階ｓ２１４１を進める。
【０２１３】
以上のように、本発明は、たとえ限定された実施形態及び図面により説明されたとしても、本発明が前記の実施形態に限定されるものではなく、これは、当業者ならば、これらの記載から多様な修正及び変形が可能である。したがって、本発明の思想は特許請求の範囲のみによって把握されねばならず、これと均等または等価的な変形はいずれも本発明の思想の範ちゅうに属するといえる。また、本発明によるシステムは、コンピュータで読み取り可能な記録媒体にコンピュータで読み取り可能なコードとして具現できる。
【０２１４】
例えば、本発明の例示的な実施形態によるサーバのストリーミング装置及びクライアントのストリーミング装置は、図１３及び図１４に示したような装置のそれぞれのユニットにカップリングされたバス、前記バスに結合された少なくとも一つのプロセッサーを備える。また、命令、受信されたメッセージまたは生成されたメッセージを保存するために前記バスに結合されて、前述したような命令を行うための少なくとも一つのプロセッサーにカップリングされたメモリを含む。
【０２１５】
また、コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み込まれるデータが保存されるあらゆる種類の記録装置を備える。記録媒体の例には、ＲＯＭ、ＲＡＭ、ＣＤ−ＲＯＭ、磁気テープ、フロッピー(登録商標)ディスク、光データ保存装置などを含む。またコンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散されて、分散方式でコンピュータで読み取り可能なコードが保存されて行われる。
【符号の説明】
【０２１６】
１１０ エンコーディング装置
１２０ サーバ
１３０ クライアント
【特許請求の範囲】
【請求項１】
データを受信する方法において、
第１メディアデータについての情報を獲得し、前記第１メディアデータは少なくとも一つのコンポーネントを含む段階と、
前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得する段階と、を含み、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが、第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報をさらに含むことを特徴とするデータ受信方法。
【請求項２】
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報をさらに含み、
前記コンポーネント情報は、前記第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項３】
前記コンポーネント情報は、
前記少なくとも一つのコンポーネントの識別情報をさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項４】
前記コンポーネント情報は、
前記第１メディアデータに含まれたビデオコンポーネントについてのカメラ角度情報をさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項５】
前記コンポーネント情報は、
前記第１メディアデータに含まれたオーディオコンポーネントについてのチャネル情報及び言語コード情報のうち少なくとも一つをさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項６】
前記コンポーネント情報は、
前記第１メディアデータに含まれたサブタイトルコンポーネントについての言語情報をさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項７】
前記第１メディアデータ情報は、
前記第１メディアデータと前記第２メディアデータとが、同じコンデンツをエンコーディングして生成されたコンポーネントを含むかどうかを表す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項８】
前記第１メディアデータについての情報を獲得する段階は、
所定のコンデンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイルから、前記第１メディアデータについての情報を獲得する段階を含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項９】
データを伝送する方法において、
サーバにより少なくとも一つのコンポーネントを含む第１メディアデータについての情報を生成する段階と、
サーバにより前記第１メディアデータについての情報を伝送する段階と、
サーバにより前記伝送に対応する要請に基づいて、前記少なくとも一つのコンポーネントを伝送する段階と、を含み、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことを特徴とするデータ伝送方法。
【請求項１０】
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報をさらに含み、
前記コンポーネント情報は、前記第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含むことを特徴とする請求項９に記載のデータ伝送方法。
【請求項１１】
前記コンポーネント情報は、
前記少なくとも一つのコンポーネントの識別情報をさらに含むことを特徴とする請求項１０に記載のデータ伝送方法。
【請求項１２】
前記コンポーネント情報は、
前記第１メディアデータに含まれたビデオコンポーネントについてのカメラ角度情報をさらに含むことを特徴とする請求項１０に記載のデータ伝送方法。
【請求項１３】
データを受信する装置において、
第１メディアデータについての情報を獲得し、前記第１メディアデータは、マルチメディアデータを構成する少なくとも一つのコンポーネントを含む情報獲得部と、
前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得するコンポーネント獲得部と、を備え、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことを特徴とするデータ受信装置。
【請求項１４】
データを伝送する装置において、
少なくとも一つのコンポーネントが含まれた第１メディアデータについての情報を生成する情報生成部と、
前記第１メディアデータについての情報を伝送する情報伝送部と、
前記伝送に対応する要請に基づいて、前記少なくとも一つのコンポーネントを伝送するコンポーネント伝送部と、を備え、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことを特徴とするデータ伝送装置。
【請求項１５】
データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、
前記方法は、第１メディアデータについての情報を獲得し、前記第１メディアデータは少なくとも一つのコンポーネントを含む段階と、
前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得する段階と、を含み、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報をさらに含むことを特徴とする記録媒体。
【請求項１】
データを受信する方法において、
第１メディアデータについての情報を獲得し、前記第１メディアデータは少なくとも一つのコンポーネントを含む段階と、
前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得する段階と、を含み、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが、第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報をさらに含むことを特徴とするデータ受信方法。
【請求項２】
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報をさらに含み、
前記コンポーネント情報は、前記第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項３】
前記コンポーネント情報は、
前記少なくとも一つのコンポーネントの識別情報をさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項４】
前記コンポーネント情報は、
前記第１メディアデータに含まれたビデオコンポーネントについてのカメラ角度情報をさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項５】
前記コンポーネント情報は、
前記第１メディアデータに含まれたオーディオコンポーネントについてのチャネル情報及び言語コード情報のうち少なくとも一つをさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項６】
前記コンポーネント情報は、
前記第１メディアデータに含まれたサブタイトルコンポーネントについての言語情報をさらに含むことを特徴とする請求項２に記載のデータ受信方法。
【請求項７】
前記第１メディアデータ情報は、
前記第１メディアデータと前記第２メディアデータとが、同じコンデンツをエンコーディングして生成されたコンポーネントを含むかどうかを表す情報をさらに含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項８】
前記第１メディアデータについての情報を獲得する段階は、
所定のコンデンツを相異なる品質にエンコーディングして生成された複数のコンポーネントについての情報を含むファイルから、前記第１メディアデータについての情報を獲得する段階を含むことを特徴とする請求項１に記載のデータ受信方法。
【請求項９】
データを伝送する方法において、
サーバにより少なくとも一つのコンポーネントを含む第１メディアデータについての情報を生成する段階と、
サーバにより前記第１メディアデータについての情報を伝送する段階と、
サーバにより前記伝送に対応する要請に基づいて、前記少なくとも一つのコンポーネントを伝送する段階と、を含み、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことを特徴とするデータ伝送方法。
【請求項１０】
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントそれぞれについての情報であるコンポーネント情報をさらに含み、
前記コンポーネント情報は、前記第１メディアデータに含まれた少なくとも一つのコンポーネントについてのタイプ情報を含むことを特徴とする請求項９に記載のデータ伝送方法。
【請求項１１】
前記コンポーネント情報は、
前記少なくとも一つのコンポーネントの識別情報をさらに含むことを特徴とする請求項１０に記載のデータ伝送方法。
【請求項１２】
前記コンポーネント情報は、
前記第１メディアデータに含まれたビデオコンポーネントについてのカメラ角度情報をさらに含むことを特徴とする請求項１０に記載のデータ伝送方法。
【請求項１３】
データを受信する装置において、
第１メディアデータについての情報を獲得し、前記第１メディアデータは、マルチメディアデータを構成する少なくとも一つのコンポーネントを含む情報獲得部と、
前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得するコンポーネント獲得部と、を備え、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことを特徴とするデータ受信装置。
【請求項１４】
データを伝送する装置において、
少なくとも一つのコンポーネントが含まれた第１メディアデータについての情報を生成する情報生成部と、
前記第１メディアデータについての情報を伝送する情報伝送部と、
前記伝送に対応する要請に基づいて、前記少なくとも一つのコンポーネントを伝送するコンポーネント伝送部と、を備え、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報を含むことを特徴とするデータ伝送装置。
【請求項１５】
データを受信する方法を具現するためのプログラムが記録されたコンピュータで読み取り可能な記録媒体において、
前記方法は、第１メディアデータについての情報を獲得し、前記第１メディアデータは少なくとも一つのコンポーネントを含む段階と、
前記第１メディアデータについての情報に基づいて、前記少なくとも一つのコンポーネントを獲得する段階と、を含み、
前記第１メディアデータについての情報は、前記少なくとも一つのコンポーネントが第２メディアデータから獲得されたコンポーネントと共に提供されるかどうかを表す情報をさらに含むことを特徴とする記録媒体。
【図２Ａ】
【図２Ｂ】
【図３】
【図４ａ】
【図４ｂ】
【図４ｃ】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８ａ】
【図８ｂ】
【図９ａ】
【図９ｂ】
【図９ｃ】
【図９ｄ】
【図９ｅ】
【図９ｆ】
【図９ｇ】
【図９ｈ】
【図１０Ａ】
【図１０Ｂ】
【図１０Ｃ】
【図１１Ａ】
【図１１Ｂ】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図１】
【図２Ｂ】
【図３】
【図４ａ】
【図４ｂ】
【図４ｃ】
【図５Ａ】
【図５Ｂ】
【図６】
【図７】
【図８ａ】
【図８ｂ】
【図９ａ】
【図９ｂ】
【図９ｃ】
【図９ｄ】
【図９ｅ】
【図９ｆ】
【図９ｇ】
【図９ｈ】
【図１０Ａ】
【図１０Ｂ】
【図１０Ｃ】
【図１１Ａ】
【図１１Ｂ】
【図１２Ａ】
【図１２Ｂ】
【図１２Ｃ】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図１】
【公表番号】特表２０１３−５１１２０１（Ｐ２０１３−５１１２０１Ａ）
【公表日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願番号】特願２０１２−５３８７７１（Ｐ２０１２−５３８７７１）
【出願日】平成２２年１１月１５日（２０１０．１１．１５）
【国際出願番号】ＰＣＴ／ＫＲ２０１０／００８０６８
【国際公開番号】ＷＯ２０１１／０５９２９１
【国際公開日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公表日】平成２５年３月２８日（２０１３．３．２８）
【国際特許分類】
【出願日】平成２２年１１月１５日（２０１０．１１．１５）
【国際出願番号】ＰＣＴ／ＫＲ２０１０／００８０６８
【国際公開番号】ＷＯ２０１１／０５９２９１
【国際公開日】平成２３年５月１９日（２０１１．５．１９）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]