ファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置とその記録媒体
本発明は、ファイルフォーマットベースの適応的ストリームの生成及び再生方法及び装置を提供する。その方法は、サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するステップと、マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化及び再生を遂行するステップとを有し、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれることを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はコンテンツ伝送システムに関するもので、特にファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置に関する。
【背景技術】
【０００２】
国際標準化機構(International Organization for Standardization：ＩＳＯ)/国際電気標準会議(International Electrotechnical Commission：ＩＥＣ)１４４９６-１２は、マルチメディアサービスに使用される標準ファイルフォーマットとしてＩＳＯ基本ファイルフォーマットを定義する。ＩＳＯ基本ファイルフォーマットは、フレキシブルかつ拡張可能なファイル構成を有し、それによって多様なメディアファイルフォーマットの基本になる。このＩＳＯ基本ファイルフォーマットは、メディアリソースとメタデータをパッケージングするための標準化したファイル構成であって、多様なタイプのメディアリソースとメタデータを含むようにオブジェクト指向設計を有する。例えば、ＪＰＥＧ(Joint Photographic Experts Group)２０００及び３ＧＰＰ(3rd Generation Partnership Project)ファイルフォーマットはＩＳＯ基本ファイルフォーマットに基づき、ＭＰＥＧ(Moving Picture Experts Group)-４ファイルフォーマットはＩＳＯ基本ファイルフォーマットを拡張したものである。
【０００３】
一方、ＨＴＴＰ(Hyper Text Transfer Protocol)を用いるＡ/Ｖ(Audio/Video)ストリーミングは、サーバの負担を最小化してクライアントの知能的処理に全体的に依存するストリーミング方式である。クライアントは、ＨＴＴＰのファイル伝送要求又は一部ファイル伝送要求のみを用いてストリーミングを達成する。したがって、ネットワークの伝送率変化に適応するために、ファイルは、同一のコンテンツに対して色々な伝送率で圧縮され、サーバに予めアップロードしなければならない。また、このようなネットワークの変化に適応するために、全体コンテンツファイルは、適当なサイズのフラグメントに分けられ、分けられたフラグメントはファイルとして格納されなければならない。さらに、このように断片化したファイルを順次に持ってきてＡＶコンテンツを再生する方法に関する情報を含む別途のメタデータファイルは、サーバにアップロードしなければならない。このようなメタデータファイルの一例としては、マニフェスト(Manifest)がある。このマニフェストは、一般的にファイルリストに関連した情報を提供するファイルを意味する。コンテンツ情報を伝送する場合、コンテンツを構成するデータの時間及び帯域幅のように、ファイルに関する構成情報及び付加情報を伝送するのに使用されるファイルは、“マニフェストファイル”と呼ばれる。また、ファイルリストに関連した情報を予めクライアントに伝送することによって、クライアントは、ファイルを選択できる。
【０００４】
さらに、マニフェストは、適応ストリームに関する情報を提供する。例えば、このマニフェストは、各セグメントに使用されるビットレートに関する情報を提供する。したがって、端末は、適応ストリームに関する情報に基づいて適当なセグメントを選択することができる。
【０００５】
しかしながら、可変するブロードキャスト環境に適応するために、コンテンツが小さな単位に分けられてから伝送される場合、マニフェストファイルを効率的に伝送するための方式が要求される。また、クライアントがサーバから伝送されたファイルフォーマットを通じて再生するための適切なファイルを探すことができる方案が要求される。加えて、サーバのスケジューリング時に、ファイルは、相互に異なるＵＲＬ(Uniform Resource Locator）を参照して該当セグメントにマッピングされなければならないため、スケジューリング負荷が増加するという問題点を有する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、マニフェスト情報を効率的に伝送、受信、及び再生するためのファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置を提供することにある。
【０００７】
本発明の他の目的は、サーバによって効率的にスケジューリングするためのファイルフォーマットベースの適応的ストリーム生成方法及び装置を提供することにある。
【課題を解決するための手段】
【０００８】
上記のような目的を達成するために、本発明の一態様によれば、サーバにおけるファイル伝送方法が提供される。その方法は、マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含む一つ以上のセグメントを一つのファイルに生成するステップと、生成された一つのファイルを端末に伝送するステップとを有する。
【０００９】
本発明の他の態様によれば、サーバにおけるファイル生成装置が提供される。その装置は、マニフェスト情報を伝送するためのマニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含むセグメントを生成する生成部と、マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを端末に伝送する伝送部とを含み、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに伝送される。
【００１０】
また、本発明の他の態様によれば、端末におけるファイル再生方法が提供される。その方法は、サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するステップと、マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化及び再生を遂行するステップとを有し、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれる。
【００１１】
さらに、本発明の他の態様によれば、端末におけるファイル再生装置が提供される。その装置は、サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するパーサと、マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化するデコーダとを含み、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれる。
【００１２】
本発明の他の態様によれば、データ構成を格納可能な記録媒体が提供される。その記録媒体は、マニフェスト情報を伝送するマニフェストボックスと、ｍｏｏｖボックスと、メディアデータボックスを含む一つ以上のセグメントとを含み、マニフェストボックス、ｍｏｏｖボックス、及び一つ以上のセグメントが一つのファイルに含まれる。
【発明の効果】
【００１３】
本発明は、マニフェスト情報を効率的に伝送、受信、及び再生することができる。また、本発明は、効率的にスケジューリングを遂行するサーバを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】現在メカニズムのマニフェストのスキーマを示す図である。
【図２】図１に示したマニフェストに関連したファイルフォーマットの構成を示す図である。
【図３】本発明の第１の実施形態によるマニフェスト構成を示す図である。
【図４】本発明の第２の実施形態によるマニフェスト構成を示す図である。
【図５】本発明の第３の実施形態によるマニフェスト構成を示す図である。
【図６】本発明の第４の実施形態によるｍｏｏｖレベル又はｍｏｏｖボックスに位置したｍａｎｉボックスを示す図である。
【図７】本発明の第５の実施形態によるｍｅｔａレベル又はｍｅｔａボックスに位置したｍａｎｉボックスを示す図である
【図８】本発明のセグメント構成の一例を示す図である。
【図９】本発明のセグメント構成の他の例を示す図である。
【図１０】本発明により、他の新たなフィールドがファイルフォーマットのマニフェストに追加できる一例を示す図である。
【図１１】本発明の実施形態による端末によってファイルを再生する方法を示すフローチャートである。
【図１２】本発明の実施形態によるサーバの動作を示すフローチャートである。
【図１３】本発明の実施形態による端末を示すブロック構成図である。
【図１４】本発明の実施形態によるサーバを示すブロック構成図である。
【発明を実施するための形態】
【００１５】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【００１６】
次の説明において、公知の機能または構成に関する具体的な説明は、明瞭性と簡潔性のために省略する。また、本発明の説明において、具体的な構成及び構成要素のような特定詳細は、ただ本発明の実施形態の全般的な理解を助けるために提供されるだけである。したがって、本発明の範囲及び趣旨を逸脱することなく、以下に説明される本発明の様々な変形及び変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【００１７】
後述するサーバ及び端末の動作において、具体的に説明されないファイルフォーマットの生成及び分析プロセスは、ＩＳＯ/ＩＥＣ１４４９６-１２に従い、本発明は、これに限定されない。
【００１８】
マニフェストパラメータは、図１に示すようなスキーマ(schema)及び属性値(attributes）を含む。図２は、図１に示したマニフェストに関連したファイルフォーマットの構成を示す。
Ｉ．ＵＲＬＴｅｍｐｌａｔｅ：これは、セグメントＩＤ及びトラックＩＤを含む固定した部分を組み合わせて生成される固有のＵＲＬを示す。ＵＲＬＴｅｍｐｌａｔｅは、トラックＩＤ及びセグメントＩＤと一緒に各セグメントのＵＲＬを含む。ＵＲＬＴｅｍｐｌａｔｅは、各セグメントにアクセスするためのテンプレートを示す。ＵＲＬＴｅｍｐｌａｔｅは、必要時にはセグメントのＵＲＬにより再定義(override)できる。ＵＲＬＴｅｍｐｌａｔｅの一例は、次のようである。
http://example.com/vod/movie/18888/Track/{TrackID}/Segments/{segmentID}
ＩＩ．ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ：これは、連続的表示のために必要な次のＸＭＬ ＵＲＬを示すのに使われる。ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬは、選択的であり、ライブ適応的ストリーミングの場合に、あるいは広告のために使用され得る。
ＩＩＩ．ＲｅｆＤａｔａＵＲＬ：これは、部分的又は完全なヘッドデータ(.ｒｅｆ)を示すために使われる。セグメントがそれら自身を復号化できる場合、ＲｅｆＤａｔａＵＲＬは選択的である。
ＩＶ．Ｔｒａｃｋ：これは、異なるビットレートを有する特定タイプの隣接したセグメントの集合である。
ｉ．ＩＤ：これは、トラックＩＤを示す。
ｉｉ．Ｔｙｐｅｓ：これは、トラックのタイプを示す。Ｔｙｐｅｓは、ビデオ、オーディオ、パッケージング又は結合されたビデオとオーディオ、及びＩ-フレームとなり得る。
ｉｉｉ．ＢｉｔＲａｔｅ：これは、トラックでセグメントのビットレートを示す。
ｉｖ．ＳｔａｒｔＴｉｍｅ：これは、トラックの開始時間を指定するタイムスタンプを表し、選択的である。
ｖ．ＳｅｇｍｅｎｔＳｔａｒｔＩＤ：これは、トラックに属するセグメントの初期ＩＤを表し、選択的である。
ｖｉ．ＳｅｇｍｅｎｔＤｕｒａｔｉｏｎ：これは、各セグメントの区間を表し、選択的である。
ｖｉｉ．ＳｅｇｍｅｎｔＣｏｕｎｔ：これは、トラックに属するセグメントの総個数を表し、選択的である。
ｖｉｉｉ．Ｓｅｇｍｅｎｔ：これは、連結された基本単位であり、各単位はオーディオ又はビデオデータのみからなされた、あるいは特定時間区間に基づいて分けられたオーディオとビデオデータとの両方からなされるフラグメントを含む。セグメントは、サーバとクライアントとの間の基本伝送単位である。セグメントは、時間的及び空間的位置指定又はＡ/Ｖ(Audio/Video)同期のためのタイムスタンプが割り当てられる。(エレメントセグメントは選択的である。トラックエレメントの選択的属性が指定される場合、各セグメントのすべての情報は推定され、エレメントセグメントは不必要になる可能性がある。)
◆ＩＤ-セグメントＩＤ
◆ＳｔａｒｔＴｉｍｅ-これは、セグメントの開始時間を示す。
◆Ｄｕｒａｔｉｏｎ-これは、セグメントの区間を示す。
◆ＵＲＬ-これは、ＵＲＬＴｅｍｐｌａｔｅが使用される場合に選択的である。ＵＲＬは特定用途(例えば、他のサーバからのコンテンツまたは広告ビデオ)のために指定され、ＵＲＬＴｅｍｐｌａｔｅはこのセグメントに対して無視される。
【００１９】
本発明は、ファイル内のマニフェスト情報を効率的に伝送するために、いくつかのファイルフォーマットに変更要素を追加することを含む。
【００２０】
図２に示すような現在のメカニズムにおいて、マニフェストとデータ(例えば、オーディオ、ビデオ）は分離される。端末は、マニフェストをサーバから要求して獲得する。すると、端末は、ヘッド及び各セグメントに関する情報を認識する。復号化及び構成に関する情報に該当するヘッド情報は、ファイルフォーマットのｍｏｏｖボックスに格納される。セグメント情報は、サービスデータの一部であり、ｍｏｏｆボックスとメディアデータ(ｍｄａｔ)ボックスを含む。
【００２１】
ｍｏｏｆボックスはこの部分サービスに関する情報を格納し、ｍｄａｔボックスは実際のデータ、例えばビデオとオーディオのようなメディアデータ又はメディアストリームを格納する。現在メカニズムで説明される例は、現在のファイルフォーマットに基づく。ファイルフォーマットが今後変更される場合、ヘッドとセグメントは、新たなフォーマットにマッピングすることができる。
【００２２】
現在、マニフェストはファイルフォーマットの内部に格納されず、このファイルフォーマットとマニフェストは、別々に端末に要求及び送信される。
【００２３】
ヘッド情報及びセグメントは、相互に異なるＵＲＬを有する異なるファイルに分けられる。すなわち、異なるファイルは、異なるＵＲＬを有する。したがって、サーバは、スケジューリング時に、各ファイルを各セグメントにマッピングするために異なるＵＲＬを参照しなければならないので、スケジューリングの負荷が増加する。
【００２４】
ＩＳＯベースのメディアファイルフォーマットは、オーディオ/ビデオデータ及びオーディオ/ビデオに関する詳細情報を包含する複数のボックスで構成される。ここで説明されるボックスは、データブロック又はコンテナと呼ばれる。
【００２５】
本発明の第１〜第３の実施形態では、マニフェストは、一つのファイルフォーマット内のｍａｎｉボックスで構成される。
【００２６】
図３は、本発明の第１の実施形態によるマニフェスト構成を示す。
【００２７】
マニフェスト、ヘッド情報、セグメント、及び次のマニフェストは、一つのファイルにすべて含まれる。マニフェストはｍａｎｉボックスに格納され、ヘッド情報はｍｏｏｖボックスに格納される。
【００２８】
ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性は、ファイル内の各セグメントのオフセットとサイズを示すためにマニフェストで定義される。したがって、端末は、ｈｔｔｐレンジ(range)に基づいて期待されるセグメントを提供するようにサーバに要求できる。また、ＵＲＬＴｅｍｐｌａｔｅ属性は、固定部分及びレンジ情報を用いて生成される。すなわち、マニフェストのＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性の情報に基づいて同一のＵＲＬの各セグメントを獲得することができる。
【００２９】
さらに、ファイルフォーマット内部にマニフェストボックスを定義する場合、ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ属性は使用されない。次のマニフェストはこのファイル、すなわち一つのファイル内に格納されるので、次のマニフェストのオフセットは、現在マニフェストボックスに定義される。
【００３０】
他のパラメータは、現在のマニフェストのパラメータと同一である。
【００３１】
図４は、本発明の第２の実施形態によるマニフェスト構成を示す。
【００３２】
本発明の第２の実施形態において、ヘッド情報とすべてのセグメントは、まだ一つのファイル内にあるが、マニフェストは、図４に示すように一つのファイルとは別途に伝送される。マニフェストは、他の一つのファイルにより格納されたり、あるいはファイル構成以外の別途のメッセージを通じて転送されたり、又は別途のＵＲＬを通じて獲得することが可能である。すなわち、ヘッド情報と、すべてのセグメントを含む一つのファイルとマニフェストは、端末によって別に獲得される。本実施形態による新たなメカニズムは、一つのファイルがマニフェスト情報なしにヘッド情報とすべてのセグメントを含むという面で、図２について上記した現在のメカニズムと類似した構成を有する。しかしながら、ヘッド情報及び各セグメントは、上記した現在のメカニズムでは異なるＵＲＬを通じてアクセス及び獲得されなければならないが、本発明の第２の実施形態では、一つのＵＲＬを通じて獲得されなければならない。すなわち、上記したように、一つのＵＲＬを通じてすべてのセグメントを獲得するために、マニフェスト内にヘッド情報の位置を獲得するために新たな属性“Ｈｅａｄｉｎｆｏ”が定義されるべきである。
【００３３】
したがって、ヘッド情報がｍｏｏｖボックスに格納されるため、Ｈｅａｄｉｎｆｏ属性は、ファイルのｍｏｏｖボックスの位置を含む。このために、Ｈｅａｄｉｎｆｏは、ＨｅａｄＯｆｆｓｅｔとＨｅａｄＳｉｚｅを含むパラメータで定義される。
【００３４】
ヘッド情報と残りのセグメントが異なるＵＲＬを有する２つのファイルに分けられる場合、ＲｅｆＤａｔａＵＲＬは、ここでヘッド情報を表すために使われることができる。
【００３５】
ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性は、上記ファイルの各セグメントのオフセット及びサイズを表すためにマニフェストファイルで定義できる。したがって、端末は、ｈｔｔｐレンジに基づいて期待されるセグメントを要求できる。また、ＵＲＬＴｅｍｐｌａｔｅ属性は、固定部分及びレンジ情報を用いて生成される。
【００３６】
本発明の第２の実施形態では、マニフェストは別途に受信される。したがって、ｍａｎｉボックスは使用されず、次のマニフェストはＮｅｘｔＡａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ属性で表される。すなわち、次のマニフェスト情報はＮｅｘｔＡａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬを通じてわかる。
【００３７】
図５は、本発明の第３の実施形態によるマニフェスト構成を示す。
【００３８】
このメカニズムにおいて、一部のセグメントは一つのファイル(メインファイル)にあり、他のセグメントは他のファイル(補助ファイル）にある。図５に示すように、セグメント１，２は一つのファイルにあり、ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性は、一つのファイル内にセグメント１，２の位置を示す。しかしながら、セグメント３は他のファイルにあり、セグメント３の位置はＳｅｇｍｅｎｔＵＲＬ属性で表示される。例えば、ハイブリッドネットワークにおいて、一部のセグメントは、有線ネットワークを介してファイルから取られ、一部のセグメントは無線ネットワークを介してファイルから取られる。したがって、セグメントがメインファイルに格納される場合、ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅは、ファイルのセグメント位置を表すために使われる。セグメントが他のファイル(補助ファイル)に格納される場合、ＳｅｇｍｅｎｔＵＲＬは、セグメント位置を示すために使われる。
【００３９】
マニフェストは、図５に示す例のようにメインファイルに格納され、独立的に格納されることもできる。
【００４０】
ファイルフォーマットのマニフェストの位置は、多様に実施できる。ｍａｎｉボックスは、ファイルレベル内で定義されるだけでなく、他のレベルで位置することもできる。例えば、ｍａｎｉボックスは、ｍｏｏｖレベルに位置できる。
【００４１】
図６は、本発明の第４の実施形態によるｍｏｏｖレベル又はｍｏｏｖボックス内に位置したｍａｎｉボックスを示す。
【００４２】
ｍｏｏｖレベルでマニフェストボックスに関する説明は、ファイルレベル又はファイルボックス内でマニフェストボックスに関する説明、すなわち、本発明の第１の実施形態の説明と同様である。
【００４３】
一般的に、ｍｏｏｖボックスはアップデートされない。しかしながら、例えば、ライブストリームの場合に、マニフェストアップデートは要求されることもある。マニフェストアップデートが要求される場合、ｍｏｏｖボックスは、アップデートメカニズムをサポートし、次の構成で示すようにマニフェストボックスを実行する。第１のｍｏｏｖボックスでは、ノーマル(normal)なトラックボックスを除いたｍａｎｉボックスが追加される。新たなｍａｎｉボックスが要求される場合、ｍｏｏｖボックスは、新たなｍａｎｉボックスを実行するためにアップデートされる。図６は、セグメント構成を示す。図６に示す構成は、以後に説明する場合に基づく。しかしながら、空き領域(free space)が使用される場合、図６に示す構成は、後述するケース２に基づく。
【００４４】
ファイルフォーマットでのマニフェストの位置は、多様に実施できる。ｍａｎｉボックスは、ファイルレベル内で定義されるだけでなく、他のレベルで位置することもできる。例えば、ｍａｎｉボックスは、ｍｅｔａレベルに位置できる。
【００４５】
図７は、本発明の第５の実施形態によるｍｅｔａレベル又はｍｅｔａボックス内に位置したｍａｎｉボックスを示す。
【００４６】
ｍｅｔａレベルでマニフェストボックスに関する説明は、ファイルレベル又はファイルボックス内でマニフェストボックスに関する説明、すなわち、本発明の第１の実施形態の説明と同様である。
【００４７】
一般的に、ｍｅｔａボックスはアップデートされない。しかしながら、例えば、ライブストリームの場合に、マニフェストアップデートは要求されることもある。マニフェストアップデートが要求される場合、ｍｅｔａボックスは、アップデートメカニズムをサポートし、マニフェストボックスを実行する。第１のｍｅｔａボックスでは、ノーマルなメタデータ情報ボックスを除いたｍａｎｉボックスが追加される。新たなｍａｎｉボックスが要求される場合、ｍｅｔａボックスは、新たなｍａｎｉボックスを実行するためにアップデートされる。図７は、セグメント構成を示す。図７に示す構成は、以後に説明するケース１に基づく。しかしながら、空き領域が使用される場合、図７に示す構成は、後述するケース２に基づく。
【００４８】
新たなマニフェスト構成において、新たなｍａｎｉボックスは、上記した多様な実施形態をサポートするために提供される。多様なボックスは、提案されたｍａｎｉボックス内に含むことができる。新たに定義されたボックスは、下記の＜表１＞に示すようである。
【００４９】
【表１】
【００５０】
以後、＜表１＞で新たに定義されたボックスについて詳細に説明する。
【００５１】
２.１ ｍａｎｉボックス
ボックスタイプ：“ｍａｎｉ”
コンテナ(Container)：ファイル
数量(Quantity)：０以上
【００５２】
このｍａｎｉボックスは、マニフェストがファイル内で転送される場合に使用される。ＣｏＤ(Content on Delivery）の場合、一つのファイルが一つのｍａｎｉボックスを有する。ライブ適応的ストリーミングの場合、一つ以上のｍａｎｉボックスがあり得る。
【００５３】
そのシンタックス(syntax)の一例は、次のようである。
aligned(8)class ManifestBox extends Box('mani'){
}
【００５４】
２.２ ｍａｈｄ
ボックスタイプ：“ｍａｈｄ”
コンテナ：ｍａｎｉボックス
数量：正確に１
【００５５】
このボックスは、マニフェストに関する情報を含み、そのシンタックスの一例は次のようである。
aligned(8)class ManifestHeaderBox extends FullBox('mahd'、version,0){
if(version==1){
unsignedint(64)creation_time;
unsignedint(64)modification_time;
unsignedint(32)timescale;
unsignedint(64)duration;
unsignedint(64)size;
}else{//version==0
unsignedint(32)creation_time;
unsignedint(32)modification_time;
unsignedint(32)timescale;
unsignedint(32)duration;
unsignedint(32)size;
}
}
【００５６】
上記シンタックスにおいて、“ｖｅｒｓｉｏｎ”は、現在の明細書に基づいて０又は１として表現できるマニフェストボックスのバージョンを指定する整数である。
【００５７】
“ｃｒｅａｔｉｏｎ_ｔｉｍｅ”は、ＵＴＣ(Coordinated Universal Time)、１９０４年１月１日、深夜１２時以後に秒単位で、プレゼンテーションの生成時間をして公表する(declare)整数である。
【００５８】
“ｍｏｄｉｆｉｃａｔｉｏｎ_ｔｉｍｅ”は、ＵＴＣ時間では１９０４年１月１日深夜１２時以後に秒単位でプレゼンテーションが変更される最近の時間を公表する整数である。
【００５９】
“ｔｉｍｅｓｃａｌｅ”は、全体プレゼンテーションのための時間スケールを指定する整数であり、１秒内で通過する時間単位の数に該当する。例えば、１秒の１/６０で時間を測定する時間座標系は６０の時間スケールを有する。
【００６０】
“ｄｕｒａｔｉｏｎ”は、表示された時間スケールでプレゼンテーションの長さを公表する整数である。この特性は、プレゼンテーションのトラックから得られる(すなわち、このフィールドの値は、プレゼンテーションで最も長いトラックの区間に対応する)。
【００６１】
“ｓｉｚｅ”は、このボックスのバイトの個数を明示する整数である。
【００６２】
２.３ ｍｘｍｌ
ボックスタイプ：“ｍｘｍｌ”
コンテナ：ｍａｎｉボックス
数量：正確に１
【００６３】
このボックス(マニフェストＭＸＭＬボックス)は、マニフェストＸＭＬのためのコンテナであり、そのシンタックスの例は、次のようである。
aligned(8)class MXMLBox extends FullBox('mxml'、version=0,0){
string xml;
}
【００６４】
２.４ ｎｍｏｆ
ボックスタイプ：“ｎｍｏｆ”
コンテナ：ｍａｎｉボックス
数量：０又は１
【００６５】
このボックス(次のマニフェストオフセットボックス)は、次のマニフェストボックスがファイル内で生成される場合に使用され、オフセット値を表し、そのシンタックスの例は、次のようである。
aligned(8)class NextManifestoffsetBox
extends FullBox('nmof'、version=0,0){
unsigned int(32)size;
}
【００６６】
２.５ ｎｍｓｚ
ボックスタイプ：“ｎｍｓｚ”
コンテナ：ｍａｎｉボックス
数量：０又は１
【００６７】
このボックス(次のマニフェストサイズボックス)は、次のｍａｎｉボックスがファイル内で生成される場合に使用され、次のｍａｎｉボックスのサイズを表し、そのシンタックスの例は、次のようである。
aligned(8)class NextManifestSizeBox extends FullBox('nmof'、version=0,0){
unsigned int(32)next_manifest_offset;
}
【００６８】
セグメント構成のケース１は、図８に示す。
ライブストリームのケースで、マニフェストが生成される場合、各セグメントの長さは既に知られていることがある。すなわち、次のマニフェスト実際オフセット(next manifest actual offset：ｎｍａｏ）が予め決定される。したがって、各セグメントの正確なオフセットとサイズは固定され、次のマニフェストのオフセットは予測可能である。
【００６９】
セグメント構成のケース２は、図９に示す。セグメント構成のケース２は、空き領域を追加的に含む。
【００７０】
一部条件の下で、マニフェストが生成される場合、各セグメントの実際サイズは、知られていない。このとき、各セグメントに対する固定サイズを仮定して割り当てることができ、この固定サイズは、各セグメントに対して十分に大きくなければならない。したがって、余分のデータを搬送する空き領域は、メディアデータボックスに含まれる。セグメントが予備(reserved)領域すべてを使用しないと、空き領域は残りのサイズに対して使用される。固定サイズがすべてのセグメントに対して予備にされるため、次のマニフェストのオフセットは、以前のマニフェストボックスでわかり、表示することができる。
【００７１】
図１０は、本発明により、他の新たなフィールドがファイルフォーマットのマニフェストに追加できる一例を示す。
【００７２】
上記した新たなフィールドに加えて、他のフィールドもマニフェストで使用され得る。
【００７３】
フィールドＬａｎｇｕａｇｅ１００１，１００２：異なるトラック/セグメントは、同一のサービスのために相互に異なる言語を提供できる。この場合、各トラック/セグメントの言語は、マニフェストに表示することができる。
【００７４】
ＳｕｂｔｉｔｌｅＬａｎｇｕａｇｅ１００３，１００４：異なるトラック/セグメントは、同一のサービスのために異なるサブタイトル言語を提供できる。この場合、各トラック/セグメントのサブタイトル言語は、マニフェストに表示することができる。
【００７５】
ＡｃｃｅｓｓＮｅｔｗｏｒｋ１００５，１００６：本発明の第３の実施形態で、 ＡｃｃｅｓｓＮｅｔｗｏｒｋが説明される。ハイブリッドネットワークで、トラック/セグメントは相互に異なるネットワークから来ることができる。したがって、この情報は、アクセスする適当なネットワークを選択するように端末を助けるためにマニフェストに表示することができる。
【００７６】
ＣａｍｅｒａＡｎｇｌｅ１００７，１００８：異なるカメラ角度が同一のサービスのために提供され得る。端末は、マニフェストから特定カメラ角度を有する一つのトラック/セグメントを選択できる。
【００７７】
図１１は、端末によりファイル再生方法を示すフローチャートである。
【００７８】
端末は、ステップ１１００で、マニフェストがデータファイルから独立されるか否かを判定する。マニフェストがデータファイルから独立した場合、端末は、ステップ１１１０でそのマニフェストを要求して獲得する。しかしながら、マニフェストが同一のファイルにある場合には、端末は、ステップ１１１２で、マニフェストボックスにアクセスしてマニフェストの情報を獲得する。
【００７９】
端末は、ステップ１１１４で、マニフェストを分析して各トラックの異なるビットレートを獲得する。端末は、ステップ１１１６で、現在の状態に基づいて適当なトラックセグメントを選択する。
【００８０】
端末は、ステップ１１１８で、ｍｏｏｖボックスを分析してヘッダー情報を得ることができる。本発明の第２の実施形態によると、端末は、ヘッドオフセットに関する情報とヘッドサイズに関する情報を用いてｍｏｏｖボックスにアクセスできる。
【００８１】
以後、端末は、ステップ１１２０で、セグメントが同一のファイル又は異なるファイルにあるか否かを判定する。
【００８２】
セグメントが同一のファイルにある場合、端末は、ステップ１１２２で、ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性に基づいてセグメントを要求し、セグメントを復号化して再生する。
【００８３】
セグメントが異なるファイルにある場合に、端末は、ステップ１１２４で、ＳｅｇｍｅｎｔＵＲＬ、ＳｅｇｍｅｎｔＯｆｆｓｅｔ、及びＳｅｇｍｅｎｔＳｉｚｅ属性に基づいてセグメントを要求し、セグメントを復号化して再生する。
【００８４】
ステップ１１２２及び１１２４以後、端末は、ステップ１１２６で、端末がサービスを継続して所望するか否かを判定する。
【００８５】
端末がサービスの継続を望まない場合、端末は、上記プロセスを終了する。端末がサービスの継続を望む場合には、端末は、ステップ１１２８に進行する。
【００８６】
端末は、ステップ１１２８で、新たなマニフェストが必要であるか否かを判定する。新たなマニフェストが必要である場合、例えば、ライブストリームの場合、端末は、新たなマニフェストを獲得しなければならない。
【００８７】
端末は、ステップ１１３０で、新たなマニフェストが同一のファイルにあるか否かを判定する。新たなマニフェストが同一のファイルにある場合、端末は、ステップ１１１２に進行して次のマニフェストオフセットボックス及び次のマニフェストサイズボックスに基づいてマニフェストを獲得する。しかしながら、ステップ１１３０での判定の結果、新たなマニフェストが異なるファイルにある場合には、端末は、ステップ１１１０に進行して、ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ属性に基づいてサーバからマニフェストを獲得する。新たなマニフェストボックスを獲得した後、端末は、これを分析して上記したステップを反復する。
【００８８】
ステップ１１２８の結果、新たなマニフェストが必要でない場合、端末は、ステップ１１３２で、その現在状態に基づいて次のセグメントを継続して要求し、ステップ１１３４で、上記セグメントを受信して復号化及び再生する。すると、端末は、サービスを継続して所望するか否かを判定し、上記ステップを反復する。
【００８９】
上記した端末動作は、本発明のすべての実施形態に適用できることはもちろんである。
【００９０】
図１２は、サーバの動作を示すフローチャートである。
【００９１】
サーバは、ステップ１２００で、マニフェストを生成するためにサービス情報を収集する。
【００９２】
ステップ１２１０で、サーバは、マニフェストが他のサービスデータと同一のファイルにあるか否かを判定する。
【００９３】
マニフェストが独立的である場合、すなわち、マニフェストが他のサービスデータと異なるファイルにある場合、サーバは、ステップ１２１２で、一つのＵＲＬを有し、独立的なマニフェストを生成する。ステップ１２１４で、サーバが端末からマニフェスト要求を受信する場合、サーバは、一つのＵＲＬに基づいて生成されたマニフェストを端末に伝送する。
【００９４】
端末は、このマニフェストを分析した後、期待したセグメントの提供をサーバに要求する。
【００９５】
サーバがセグメントに対する要求を受信する場合、サーバは、ステップ１２１９で、ヘッド情報を用いてｍｏｏｖボックスを生成し、ステップ１２２０で、端末により要求されたセグメント及びｍｏｏｖボックスを端末に伝送する。したがって、セグメント要求を端末から受信すると、サーバは、期待したセグメントを端末に伝送する。
【００９６】
ステップ１２１０での判定の結果、マニフェストが他のサービスデータと同一のファイルに存在する場合、サーバは、ステップ１２１８で、ファイル内にマニフェストボックスを生成する。その後、生成されたマニフェストが端末によってダウンロードされる。サーバがセグメントに対する要求を受信する場合、サーバは、ステップ１２１９で、ヘッド情報を用いてｍｏｏｖボックスを生成し、ステップ１２２０で、端末により要求されたセグメント及びｍｏｏｖボックスを端末に伝送する。すなわち、セグメント要求を端末から受信すると、サーバは、期待したセグメントを端末に伝送する。あるいは、ステップ１２１８で生成されたマニフェストボックスは、ステップ１２１９で生成されたｍｏｏｖボックスとユーザーに転送されるセグメントと一緒に、一つのファイルに組合されて端末に伝送される。上記したサーバ動作は、本発明のすべての実施形態に適用することができる。
【００９７】
図１３は、端末のブロック構成図である。
【００９８】
端末１３００は、マニフェストパーサ(parser)１３１０、ファイルパーサ１３２０、及びデコーダ１３３０を含む。
【００９９】
マニフェストパーサ１３１０は、ｍｏｏｖボックス及びメディアデータボックスと独立的である場合、マニフェストを獲得して分析する。さらに、ファイルパーサ１３２０は、マニフェストボックス以外に、ｍｏｏｖボックス及び多様な他のボックスを含む他のボックスを要求して分析する。マニフェストパーサ１３１０は、マニフェストがファイル内にある場合、ファイル内にマニフェストボックスを検出して分析する。
【０１００】
ファイルパーサ１３２０は、ファイル内に他のボックス及びｍｄａｔを分析する。すると、端末は、期待したセグメントを要求して、復号化及び再生する。
【０１０１】
図１４は、サーバのブロック構成図である。
【０１０２】
サーバ１４００は、サービスデータ提供部１４１０、マニフェスト生成器１４１２、及びファイル生成器１４１４を含む。
【０１０３】
サーバ１４００のサービスデータ提供部１４１０は、すべてのサービスソースを有する。
【０１０４】
図に示されていない制御部は、端末からマニフェスト要求を受信し、マニフェストが独立的であるか否かを判定する。
【０１０５】
マニフェスト生成器１４１２は、マニフェストがデータファイルから独立的である場合、ファイルからサービスデータと一部情報(例えば、セグメントの位置)に基づいてマニフェスト情報を生成する。
【０１０６】
ファイル生成器１４１４は、マニフェストがファイル内部にある場合、マニフェストボックスがファイル内に含まれるようにファイルを生成する。マニフェストがデータファイルから独立的である場合、マニフェストファイルを除いた他のファイルは、ｍｏｏｖボックス及びセグメントを含むように生成される。
【０１０７】
さらに、図示されていないが、本発明の実施形態により生成されたファイルフォーマットに従ってデータを記録、格納、及び再生することができる。すなわち、一つのファイル内にマニフェストが含まれた場合、格納媒体(例えば、ＣＤ、ＤＶＤ、ＢＤ、又はＵＳＢ)に、一つのファイル内に複数のセグメント及びｍｏｏｖボックス及びｍａｎｉボックスを含むように格納し、まずｍａｎｉボックスを読み取って解析することによってセグメントを再生できる。また、他のセグメントとｍｏｏｖボックスのファイルと異なる別途のファイルにマニフェストを格納し、別途のファイルに格納されたｍａｎｉボックスをまず読み取って解析することで、所望のデータを含むセグメントを再生することができる。格納媒体が格納及び再生に採用される場合、本発明の実施形態で上記したＵＲＬ情報は、格納位置情報(例えば、メモリアドレス)により代替されて容易に格納及び再生することができる。
【０１０８】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【符号の説明】
【０１０９】
１３１０ マニフェストパーサ
１３２０ ファイルパーサ
１３３０ デコーダ
【技術分野】
【０００１】
本発明はコンテンツ伝送システムに関するもので、特にファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置に関する。
【背景技術】
【０００２】
国際標準化機構(International Organization for Standardization：ＩＳＯ)/国際電気標準会議(International Electrotechnical Commission：ＩＥＣ)１４４９６-１２は、マルチメディアサービスに使用される標準ファイルフォーマットとしてＩＳＯ基本ファイルフォーマットを定義する。ＩＳＯ基本ファイルフォーマットは、フレキシブルかつ拡張可能なファイル構成を有し、それによって多様なメディアファイルフォーマットの基本になる。このＩＳＯ基本ファイルフォーマットは、メディアリソースとメタデータをパッケージングするための標準化したファイル構成であって、多様なタイプのメディアリソースとメタデータを含むようにオブジェクト指向設計を有する。例えば、ＪＰＥＧ(Joint Photographic Experts Group)２０００及び３ＧＰＰ(3rd Generation Partnership Project)ファイルフォーマットはＩＳＯ基本ファイルフォーマットに基づき、ＭＰＥＧ(Moving Picture Experts Group)-４ファイルフォーマットはＩＳＯ基本ファイルフォーマットを拡張したものである。
【０００３】
一方、ＨＴＴＰ(Hyper Text Transfer Protocol)を用いるＡ/Ｖ(Audio/Video)ストリーミングは、サーバの負担を最小化してクライアントの知能的処理に全体的に依存するストリーミング方式である。クライアントは、ＨＴＴＰのファイル伝送要求又は一部ファイル伝送要求のみを用いてストリーミングを達成する。したがって、ネットワークの伝送率変化に適応するために、ファイルは、同一のコンテンツに対して色々な伝送率で圧縮され、サーバに予めアップロードしなければならない。また、このようなネットワークの変化に適応するために、全体コンテンツファイルは、適当なサイズのフラグメントに分けられ、分けられたフラグメントはファイルとして格納されなければならない。さらに、このように断片化したファイルを順次に持ってきてＡＶコンテンツを再生する方法に関する情報を含む別途のメタデータファイルは、サーバにアップロードしなければならない。このようなメタデータファイルの一例としては、マニフェスト(Manifest)がある。このマニフェストは、一般的にファイルリストに関連した情報を提供するファイルを意味する。コンテンツ情報を伝送する場合、コンテンツを構成するデータの時間及び帯域幅のように、ファイルに関する構成情報及び付加情報を伝送するのに使用されるファイルは、“マニフェストファイル”と呼ばれる。また、ファイルリストに関連した情報を予めクライアントに伝送することによって、クライアントは、ファイルを選択できる。
【０００４】
さらに、マニフェストは、適応ストリームに関する情報を提供する。例えば、このマニフェストは、各セグメントに使用されるビットレートに関する情報を提供する。したがって、端末は、適応ストリームに関する情報に基づいて適当なセグメントを選択することができる。
【０００５】
しかしながら、可変するブロードキャスト環境に適応するために、コンテンツが小さな単位に分けられてから伝送される場合、マニフェストファイルを効率的に伝送するための方式が要求される。また、クライアントがサーバから伝送されたファイルフォーマットを通じて再生するための適切なファイルを探すことができる方案が要求される。加えて、サーバのスケジューリング時に、ファイルは、相互に異なるＵＲＬ(Uniform Resource Locator）を参照して該当セグメントにマッピングされなければならないため、スケジューリング負荷が増加するという問題点を有する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
したがって、本発明は上記した従来技術の問題点に鑑みてなされたものであって、その目的は、マニフェスト情報を効率的に伝送、受信、及び再生するためのファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置を提供することにある。
【０００７】
本発明の他の目的は、サーバによって効率的にスケジューリングするためのファイルフォーマットベースの適応的ストリーム生成方法及び装置を提供することにある。
【課題を解決するための手段】
【０００８】
上記のような目的を達成するために、本発明の一態様によれば、サーバにおけるファイル伝送方法が提供される。その方法は、マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含む一つ以上のセグメントを一つのファイルに生成するステップと、生成された一つのファイルを端末に伝送するステップとを有する。
【０００９】
本発明の他の態様によれば、サーバにおけるファイル生成装置が提供される。その装置は、マニフェスト情報を伝送するためのマニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含むセグメントを生成する生成部と、マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを端末に伝送する伝送部とを含み、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに伝送される。
【００１０】
また、本発明の他の態様によれば、端末におけるファイル再生方法が提供される。その方法は、サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するステップと、マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化及び再生を遂行するステップとを有し、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれる。
【００１１】
さらに、本発明の他の態様によれば、端末におけるファイル再生装置が提供される。その装置は、サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するパーサと、マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化するデコーダとを含み、マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれる。
【００１２】
本発明の他の態様によれば、データ構成を格納可能な記録媒体が提供される。その記録媒体は、マニフェスト情報を伝送するマニフェストボックスと、ｍｏｏｖボックスと、メディアデータボックスを含む一つ以上のセグメントとを含み、マニフェストボックス、ｍｏｏｖボックス、及び一つ以上のセグメントが一つのファイルに含まれる。
【発明の効果】
【００１３】
本発明は、マニフェスト情報を効率的に伝送、受信、及び再生することができる。また、本発明は、効率的にスケジューリングを遂行するサーバを提供することができる。
【図面の簡単な説明】
【００１４】
【図１】現在メカニズムのマニフェストのスキーマを示す図である。
【図２】図１に示したマニフェストに関連したファイルフォーマットの構成を示す図である。
【図３】本発明の第１の実施形態によるマニフェスト構成を示す図である。
【図４】本発明の第２の実施形態によるマニフェスト構成を示す図である。
【図５】本発明の第３の実施形態によるマニフェスト構成を示す図である。
【図６】本発明の第４の実施形態によるｍｏｏｖレベル又はｍｏｏｖボックスに位置したｍａｎｉボックスを示す図である。
【図７】本発明の第５の実施形態によるｍｅｔａレベル又はｍｅｔａボックスに位置したｍａｎｉボックスを示す図である
【図８】本発明のセグメント構成の一例を示す図である。
【図９】本発明のセグメント構成の他の例を示す図である。
【図１０】本発明により、他の新たなフィールドがファイルフォーマットのマニフェストに追加できる一例を示す図である。
【図１１】本発明の実施形態による端末によってファイルを再生する方法を示すフローチャートである。
【図１２】本発明の実施形態によるサーバの動作を示すフローチャートである。
【図１３】本発明の実施形態による端末を示すブロック構成図である。
【図１４】本発明の実施形態によるサーバを示すブロック構成図である。
【発明を実施するための形態】
【００１５】
以下、本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。
【００１６】
次の説明において、公知の機能または構成に関する具体的な説明は、明瞭性と簡潔性のために省略する。また、本発明の説明において、具体的な構成及び構成要素のような特定詳細は、ただ本発明の実施形態の全般的な理解を助けるために提供されるだけである。したがって、本発明の範囲及び趣旨を逸脱することなく、以下に説明される本発明の様々な変形及び変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【００１７】
後述するサーバ及び端末の動作において、具体的に説明されないファイルフォーマットの生成及び分析プロセスは、ＩＳＯ/ＩＥＣ１４４９６-１２に従い、本発明は、これに限定されない。
【００１８】
マニフェストパラメータは、図１に示すようなスキーマ(schema)及び属性値(attributes）を含む。図２は、図１に示したマニフェストに関連したファイルフォーマットの構成を示す。
Ｉ．ＵＲＬＴｅｍｐｌａｔｅ：これは、セグメントＩＤ及びトラックＩＤを含む固定した部分を組み合わせて生成される固有のＵＲＬを示す。ＵＲＬＴｅｍｐｌａｔｅは、トラックＩＤ及びセグメントＩＤと一緒に各セグメントのＵＲＬを含む。ＵＲＬＴｅｍｐｌａｔｅは、各セグメントにアクセスするためのテンプレートを示す。ＵＲＬＴｅｍｐｌａｔｅは、必要時にはセグメントのＵＲＬにより再定義(override)できる。ＵＲＬＴｅｍｐｌａｔｅの一例は、次のようである。
http://example.com/vod/movie/18888/Track/{TrackID}/Segments/{segmentID}
ＩＩ．ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ：これは、連続的表示のために必要な次のＸＭＬ ＵＲＬを示すのに使われる。ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬは、選択的であり、ライブ適応的ストリーミングの場合に、あるいは広告のために使用され得る。
ＩＩＩ．ＲｅｆＤａｔａＵＲＬ：これは、部分的又は完全なヘッドデータ(.ｒｅｆ)を示すために使われる。セグメントがそれら自身を復号化できる場合、ＲｅｆＤａｔａＵＲＬは選択的である。
ＩＶ．Ｔｒａｃｋ：これは、異なるビットレートを有する特定タイプの隣接したセグメントの集合である。
ｉ．ＩＤ：これは、トラックＩＤを示す。
ｉｉ．Ｔｙｐｅｓ：これは、トラックのタイプを示す。Ｔｙｐｅｓは、ビデオ、オーディオ、パッケージング又は結合されたビデオとオーディオ、及びＩ-フレームとなり得る。
ｉｉｉ．ＢｉｔＲａｔｅ：これは、トラックでセグメントのビットレートを示す。
ｉｖ．ＳｔａｒｔＴｉｍｅ：これは、トラックの開始時間を指定するタイムスタンプを表し、選択的である。
ｖ．ＳｅｇｍｅｎｔＳｔａｒｔＩＤ：これは、トラックに属するセグメントの初期ＩＤを表し、選択的である。
ｖｉ．ＳｅｇｍｅｎｔＤｕｒａｔｉｏｎ：これは、各セグメントの区間を表し、選択的である。
ｖｉｉ．ＳｅｇｍｅｎｔＣｏｕｎｔ：これは、トラックに属するセグメントの総個数を表し、選択的である。
ｖｉｉｉ．Ｓｅｇｍｅｎｔ：これは、連結された基本単位であり、各単位はオーディオ又はビデオデータのみからなされた、あるいは特定時間区間に基づいて分けられたオーディオとビデオデータとの両方からなされるフラグメントを含む。セグメントは、サーバとクライアントとの間の基本伝送単位である。セグメントは、時間的及び空間的位置指定又はＡ/Ｖ(Audio/Video)同期のためのタイムスタンプが割り当てられる。(エレメントセグメントは選択的である。トラックエレメントの選択的属性が指定される場合、各セグメントのすべての情報は推定され、エレメントセグメントは不必要になる可能性がある。)
◆ＩＤ-セグメントＩＤ
◆ＳｔａｒｔＴｉｍｅ-これは、セグメントの開始時間を示す。
◆Ｄｕｒａｔｉｏｎ-これは、セグメントの区間を示す。
◆ＵＲＬ-これは、ＵＲＬＴｅｍｐｌａｔｅが使用される場合に選択的である。ＵＲＬは特定用途(例えば、他のサーバからのコンテンツまたは広告ビデオ)のために指定され、ＵＲＬＴｅｍｐｌａｔｅはこのセグメントに対して無視される。
【００１９】
本発明は、ファイル内のマニフェスト情報を効率的に伝送するために、いくつかのファイルフォーマットに変更要素を追加することを含む。
【００２０】
図２に示すような現在のメカニズムにおいて、マニフェストとデータ(例えば、オーディオ、ビデオ）は分離される。端末は、マニフェストをサーバから要求して獲得する。すると、端末は、ヘッド及び各セグメントに関する情報を認識する。復号化及び構成に関する情報に該当するヘッド情報は、ファイルフォーマットのｍｏｏｖボックスに格納される。セグメント情報は、サービスデータの一部であり、ｍｏｏｆボックスとメディアデータ(ｍｄａｔ)ボックスを含む。
【００２１】
ｍｏｏｆボックスはこの部分サービスに関する情報を格納し、ｍｄａｔボックスは実際のデータ、例えばビデオとオーディオのようなメディアデータ又はメディアストリームを格納する。現在メカニズムで説明される例は、現在のファイルフォーマットに基づく。ファイルフォーマットが今後変更される場合、ヘッドとセグメントは、新たなフォーマットにマッピングすることができる。
【００２２】
現在、マニフェストはファイルフォーマットの内部に格納されず、このファイルフォーマットとマニフェストは、別々に端末に要求及び送信される。
【００２３】
ヘッド情報及びセグメントは、相互に異なるＵＲＬを有する異なるファイルに分けられる。すなわち、異なるファイルは、異なるＵＲＬを有する。したがって、サーバは、スケジューリング時に、各ファイルを各セグメントにマッピングするために異なるＵＲＬを参照しなければならないので、スケジューリングの負荷が増加する。
【００２４】
ＩＳＯベースのメディアファイルフォーマットは、オーディオ/ビデオデータ及びオーディオ/ビデオに関する詳細情報を包含する複数のボックスで構成される。ここで説明されるボックスは、データブロック又はコンテナと呼ばれる。
【００２５】
本発明の第１〜第３の実施形態では、マニフェストは、一つのファイルフォーマット内のｍａｎｉボックスで構成される。
【００２６】
図３は、本発明の第１の実施形態によるマニフェスト構成を示す。
【００２７】
マニフェスト、ヘッド情報、セグメント、及び次のマニフェストは、一つのファイルにすべて含まれる。マニフェストはｍａｎｉボックスに格納され、ヘッド情報はｍｏｏｖボックスに格納される。
【００２８】
ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性は、ファイル内の各セグメントのオフセットとサイズを示すためにマニフェストで定義される。したがって、端末は、ｈｔｔｐレンジ(range)に基づいて期待されるセグメントを提供するようにサーバに要求できる。また、ＵＲＬＴｅｍｐｌａｔｅ属性は、固定部分及びレンジ情報を用いて生成される。すなわち、マニフェストのＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性の情報に基づいて同一のＵＲＬの各セグメントを獲得することができる。
【００２９】
さらに、ファイルフォーマット内部にマニフェストボックスを定義する場合、ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ属性は使用されない。次のマニフェストはこのファイル、すなわち一つのファイル内に格納されるので、次のマニフェストのオフセットは、現在マニフェストボックスに定義される。
【００３０】
他のパラメータは、現在のマニフェストのパラメータと同一である。
【００３１】
図４は、本発明の第２の実施形態によるマニフェスト構成を示す。
【００３２】
本発明の第２の実施形態において、ヘッド情報とすべてのセグメントは、まだ一つのファイル内にあるが、マニフェストは、図４に示すように一つのファイルとは別途に伝送される。マニフェストは、他の一つのファイルにより格納されたり、あるいはファイル構成以外の別途のメッセージを通じて転送されたり、又は別途のＵＲＬを通じて獲得することが可能である。すなわち、ヘッド情報と、すべてのセグメントを含む一つのファイルとマニフェストは、端末によって別に獲得される。本実施形態による新たなメカニズムは、一つのファイルがマニフェスト情報なしにヘッド情報とすべてのセグメントを含むという面で、図２について上記した現在のメカニズムと類似した構成を有する。しかしながら、ヘッド情報及び各セグメントは、上記した現在のメカニズムでは異なるＵＲＬを通じてアクセス及び獲得されなければならないが、本発明の第２の実施形態では、一つのＵＲＬを通じて獲得されなければならない。すなわち、上記したように、一つのＵＲＬを通じてすべてのセグメントを獲得するために、マニフェスト内にヘッド情報の位置を獲得するために新たな属性“Ｈｅａｄｉｎｆｏ”が定義されるべきである。
【００３３】
したがって、ヘッド情報がｍｏｏｖボックスに格納されるため、Ｈｅａｄｉｎｆｏ属性は、ファイルのｍｏｏｖボックスの位置を含む。このために、Ｈｅａｄｉｎｆｏは、ＨｅａｄＯｆｆｓｅｔとＨｅａｄＳｉｚｅを含むパラメータで定義される。
【００３４】
ヘッド情報と残りのセグメントが異なるＵＲＬを有する２つのファイルに分けられる場合、ＲｅｆＤａｔａＵＲＬは、ここでヘッド情報を表すために使われることができる。
【００３５】
ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性は、上記ファイルの各セグメントのオフセット及びサイズを表すためにマニフェストファイルで定義できる。したがって、端末は、ｈｔｔｐレンジに基づいて期待されるセグメントを要求できる。また、ＵＲＬＴｅｍｐｌａｔｅ属性は、固定部分及びレンジ情報を用いて生成される。
【００３６】
本発明の第２の実施形態では、マニフェストは別途に受信される。したがって、ｍａｎｉボックスは使用されず、次のマニフェストはＮｅｘｔＡａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ属性で表される。すなわち、次のマニフェスト情報はＮｅｘｔＡａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬを通じてわかる。
【００３７】
図５は、本発明の第３の実施形態によるマニフェスト構成を示す。
【００３８】
このメカニズムにおいて、一部のセグメントは一つのファイル(メインファイル)にあり、他のセグメントは他のファイル(補助ファイル）にある。図５に示すように、セグメント１，２は一つのファイルにあり、ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性は、一つのファイル内にセグメント１，２の位置を示す。しかしながら、セグメント３は他のファイルにあり、セグメント３の位置はＳｅｇｍｅｎｔＵＲＬ属性で表示される。例えば、ハイブリッドネットワークにおいて、一部のセグメントは、有線ネットワークを介してファイルから取られ、一部のセグメントは無線ネットワークを介してファイルから取られる。したがって、セグメントがメインファイルに格納される場合、ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅは、ファイルのセグメント位置を表すために使われる。セグメントが他のファイル(補助ファイル)に格納される場合、ＳｅｇｍｅｎｔＵＲＬは、セグメント位置を示すために使われる。
【００３９】
マニフェストは、図５に示す例のようにメインファイルに格納され、独立的に格納されることもできる。
【００４０】
ファイルフォーマットのマニフェストの位置は、多様に実施できる。ｍａｎｉボックスは、ファイルレベル内で定義されるだけでなく、他のレベルで位置することもできる。例えば、ｍａｎｉボックスは、ｍｏｏｖレベルに位置できる。
【００４１】
図６は、本発明の第４の実施形態によるｍｏｏｖレベル又はｍｏｏｖボックス内に位置したｍａｎｉボックスを示す。
【００４２】
ｍｏｏｖレベルでマニフェストボックスに関する説明は、ファイルレベル又はファイルボックス内でマニフェストボックスに関する説明、すなわち、本発明の第１の実施形態の説明と同様である。
【００４３】
一般的に、ｍｏｏｖボックスはアップデートされない。しかしながら、例えば、ライブストリームの場合に、マニフェストアップデートは要求されることもある。マニフェストアップデートが要求される場合、ｍｏｏｖボックスは、アップデートメカニズムをサポートし、次の構成で示すようにマニフェストボックスを実行する。第１のｍｏｏｖボックスでは、ノーマル(normal)なトラックボックスを除いたｍａｎｉボックスが追加される。新たなｍａｎｉボックスが要求される場合、ｍｏｏｖボックスは、新たなｍａｎｉボックスを実行するためにアップデートされる。図６は、セグメント構成を示す。図６に示す構成は、以後に説明する場合に基づく。しかしながら、空き領域(free space)が使用される場合、図６に示す構成は、後述するケース２に基づく。
【００４４】
ファイルフォーマットでのマニフェストの位置は、多様に実施できる。ｍａｎｉボックスは、ファイルレベル内で定義されるだけでなく、他のレベルで位置することもできる。例えば、ｍａｎｉボックスは、ｍｅｔａレベルに位置できる。
【００４５】
図７は、本発明の第５の実施形態によるｍｅｔａレベル又はｍｅｔａボックス内に位置したｍａｎｉボックスを示す。
【００４６】
ｍｅｔａレベルでマニフェストボックスに関する説明は、ファイルレベル又はファイルボックス内でマニフェストボックスに関する説明、すなわち、本発明の第１の実施形態の説明と同様である。
【００４７】
一般的に、ｍｅｔａボックスはアップデートされない。しかしながら、例えば、ライブストリームの場合に、マニフェストアップデートは要求されることもある。マニフェストアップデートが要求される場合、ｍｅｔａボックスは、アップデートメカニズムをサポートし、マニフェストボックスを実行する。第１のｍｅｔａボックスでは、ノーマルなメタデータ情報ボックスを除いたｍａｎｉボックスが追加される。新たなｍａｎｉボックスが要求される場合、ｍｅｔａボックスは、新たなｍａｎｉボックスを実行するためにアップデートされる。図７は、セグメント構成を示す。図７に示す構成は、以後に説明するケース１に基づく。しかしながら、空き領域が使用される場合、図７に示す構成は、後述するケース２に基づく。
【００４８】
新たなマニフェスト構成において、新たなｍａｎｉボックスは、上記した多様な実施形態をサポートするために提供される。多様なボックスは、提案されたｍａｎｉボックス内に含むことができる。新たに定義されたボックスは、下記の＜表１＞に示すようである。
【００４９】
【表１】
【００５０】
以後、＜表１＞で新たに定義されたボックスについて詳細に説明する。
【００５１】
２.１ ｍａｎｉボックス
ボックスタイプ：“ｍａｎｉ”
コンテナ(Container)：ファイル
数量(Quantity)：０以上
【００５２】
このｍａｎｉボックスは、マニフェストがファイル内で転送される場合に使用される。ＣｏＤ(Content on Delivery）の場合、一つのファイルが一つのｍａｎｉボックスを有する。ライブ適応的ストリーミングの場合、一つ以上のｍａｎｉボックスがあり得る。
【００５３】
そのシンタックス(syntax)の一例は、次のようである。
aligned(8)class ManifestBox extends Box('mani'){
}
【００５４】
２.２ ｍａｈｄ
ボックスタイプ：“ｍａｈｄ”
コンテナ：ｍａｎｉボックス
数量：正確に１
【００５５】
このボックスは、マニフェストに関する情報を含み、そのシンタックスの一例は次のようである。
aligned(8)class ManifestHeaderBox extends FullBox('mahd'、version,0){
if(version==1){
unsignedint(64)creation_time;
unsignedint(64)modification_time;
unsignedint(32)timescale;
unsignedint(64)duration;
unsignedint(64)size;
}else{//version==0
unsignedint(32)creation_time;
unsignedint(32)modification_time;
unsignedint(32)timescale;
unsignedint(32)duration;
unsignedint(32)size;
}
}
【００５６】
上記シンタックスにおいて、“ｖｅｒｓｉｏｎ”は、現在の明細書に基づいて０又は１として表現できるマニフェストボックスのバージョンを指定する整数である。
【００５７】
“ｃｒｅａｔｉｏｎ_ｔｉｍｅ”は、ＵＴＣ(Coordinated Universal Time)、１９０４年１月１日、深夜１２時以後に秒単位で、プレゼンテーションの生成時間をして公表する(declare)整数である。
【００５８】
“ｍｏｄｉｆｉｃａｔｉｏｎ_ｔｉｍｅ”は、ＵＴＣ時間では１９０４年１月１日深夜１２時以後に秒単位でプレゼンテーションが変更される最近の時間を公表する整数である。
【００５９】
“ｔｉｍｅｓｃａｌｅ”は、全体プレゼンテーションのための時間スケールを指定する整数であり、１秒内で通過する時間単位の数に該当する。例えば、１秒の１/６０で時間を測定する時間座標系は６０の時間スケールを有する。
【００６０】
“ｄｕｒａｔｉｏｎ”は、表示された時間スケールでプレゼンテーションの長さを公表する整数である。この特性は、プレゼンテーションのトラックから得られる(すなわち、このフィールドの値は、プレゼンテーションで最も長いトラックの区間に対応する)。
【００６１】
“ｓｉｚｅ”は、このボックスのバイトの個数を明示する整数である。
【００６２】
２.３ ｍｘｍｌ
ボックスタイプ：“ｍｘｍｌ”
コンテナ：ｍａｎｉボックス
数量：正確に１
【００６３】
このボックス(マニフェストＭＸＭＬボックス)は、マニフェストＸＭＬのためのコンテナであり、そのシンタックスの例は、次のようである。
aligned(8)class MXMLBox extends FullBox('mxml'、version=0,0){
string xml;
}
【００６４】
２.４ ｎｍｏｆ
ボックスタイプ：“ｎｍｏｆ”
コンテナ：ｍａｎｉボックス
数量：０又は１
【００６５】
このボックス(次のマニフェストオフセットボックス)は、次のマニフェストボックスがファイル内で生成される場合に使用され、オフセット値を表し、そのシンタックスの例は、次のようである。
aligned(8)class NextManifestoffsetBox
extends FullBox('nmof'、version=0,0){
unsigned int(32)size;
}
【００６６】
２.５ ｎｍｓｚ
ボックスタイプ：“ｎｍｓｚ”
コンテナ：ｍａｎｉボックス
数量：０又は１
【００６７】
このボックス(次のマニフェストサイズボックス)は、次のｍａｎｉボックスがファイル内で生成される場合に使用され、次のｍａｎｉボックスのサイズを表し、そのシンタックスの例は、次のようである。
aligned(8)class NextManifestSizeBox extends FullBox('nmof'、version=0,0){
unsigned int(32)next_manifest_offset;
}
【００６８】
セグメント構成のケース１は、図８に示す。
ライブストリームのケースで、マニフェストが生成される場合、各セグメントの長さは既に知られていることがある。すなわち、次のマニフェスト実際オフセット(next manifest actual offset：ｎｍａｏ）が予め決定される。したがって、各セグメントの正確なオフセットとサイズは固定され、次のマニフェストのオフセットは予測可能である。
【００６９】
セグメント構成のケース２は、図９に示す。セグメント構成のケース２は、空き領域を追加的に含む。
【００７０】
一部条件の下で、マニフェストが生成される場合、各セグメントの実際サイズは、知られていない。このとき、各セグメントに対する固定サイズを仮定して割り当てることができ、この固定サイズは、各セグメントに対して十分に大きくなければならない。したがって、余分のデータを搬送する空き領域は、メディアデータボックスに含まれる。セグメントが予備(reserved)領域すべてを使用しないと、空き領域は残りのサイズに対して使用される。固定サイズがすべてのセグメントに対して予備にされるため、次のマニフェストのオフセットは、以前のマニフェストボックスでわかり、表示することができる。
【００７１】
図１０は、本発明により、他の新たなフィールドがファイルフォーマットのマニフェストに追加できる一例を示す。
【００７２】
上記した新たなフィールドに加えて、他のフィールドもマニフェストで使用され得る。
【００７３】
フィールドＬａｎｇｕａｇｅ１００１，１００２：異なるトラック/セグメントは、同一のサービスのために相互に異なる言語を提供できる。この場合、各トラック/セグメントの言語は、マニフェストに表示することができる。
【００７４】
ＳｕｂｔｉｔｌｅＬａｎｇｕａｇｅ１００３，１００４：異なるトラック/セグメントは、同一のサービスのために異なるサブタイトル言語を提供できる。この場合、各トラック/セグメントのサブタイトル言語は、マニフェストに表示することができる。
【００７５】
ＡｃｃｅｓｓＮｅｔｗｏｒｋ１００５，１００６：本発明の第３の実施形態で、 ＡｃｃｅｓｓＮｅｔｗｏｒｋが説明される。ハイブリッドネットワークで、トラック/セグメントは相互に異なるネットワークから来ることができる。したがって、この情報は、アクセスする適当なネットワークを選択するように端末を助けるためにマニフェストに表示することができる。
【００７６】
ＣａｍｅｒａＡｎｇｌｅ１００７，１００８：異なるカメラ角度が同一のサービスのために提供され得る。端末は、マニフェストから特定カメラ角度を有する一つのトラック/セグメントを選択できる。
【００７７】
図１１は、端末によりファイル再生方法を示すフローチャートである。
【００７８】
端末は、ステップ１１００で、マニフェストがデータファイルから独立されるか否かを判定する。マニフェストがデータファイルから独立した場合、端末は、ステップ１１１０でそのマニフェストを要求して獲得する。しかしながら、マニフェストが同一のファイルにある場合には、端末は、ステップ１１１２で、マニフェストボックスにアクセスしてマニフェストの情報を獲得する。
【００７９】
端末は、ステップ１１１４で、マニフェストを分析して各トラックの異なるビットレートを獲得する。端末は、ステップ１１１６で、現在の状態に基づいて適当なトラックセグメントを選択する。
【００８０】
端末は、ステップ１１１８で、ｍｏｏｖボックスを分析してヘッダー情報を得ることができる。本発明の第２の実施形態によると、端末は、ヘッドオフセットに関する情報とヘッドサイズに関する情報を用いてｍｏｏｖボックスにアクセスできる。
【００８１】
以後、端末は、ステップ１１２０で、セグメントが同一のファイル又は異なるファイルにあるか否かを判定する。
【００８２】
セグメントが同一のファイルにある場合、端末は、ステップ１１２２で、ＳｅｇｍｅｎｔＯｆｆｓｅｔ及びＳｅｇｍｅｎｔＳｉｚｅ属性に基づいてセグメントを要求し、セグメントを復号化して再生する。
【００８３】
セグメントが異なるファイルにある場合に、端末は、ステップ１１２４で、ＳｅｇｍｅｎｔＵＲＬ、ＳｅｇｍｅｎｔＯｆｆｓｅｔ、及びＳｅｇｍｅｎｔＳｉｚｅ属性に基づいてセグメントを要求し、セグメントを復号化して再生する。
【００８４】
ステップ１１２２及び１１２４以後、端末は、ステップ１１２６で、端末がサービスを継続して所望するか否かを判定する。
【００８５】
端末がサービスの継続を望まない場合、端末は、上記プロセスを終了する。端末がサービスの継続を望む場合には、端末は、ステップ１１２８に進行する。
【００８６】
端末は、ステップ１１２８で、新たなマニフェストが必要であるか否かを判定する。新たなマニフェストが必要である場合、例えば、ライブストリームの場合、端末は、新たなマニフェストを獲得しなければならない。
【００８７】
端末は、ステップ１１３０で、新たなマニフェストが同一のファイルにあるか否かを判定する。新たなマニフェストが同一のファイルにある場合、端末は、ステップ１１１２に進行して次のマニフェストオフセットボックス及び次のマニフェストサイズボックスに基づいてマニフェストを獲得する。しかしながら、ステップ１１３０での判定の結果、新たなマニフェストが異なるファイルにある場合には、端末は、ステップ１１１０に進行して、ＮｅｘｔＡｄａｐｔｉｖｅＣｏｎｔｒｏｌＵＲＬ属性に基づいてサーバからマニフェストを獲得する。新たなマニフェストボックスを獲得した後、端末は、これを分析して上記したステップを反復する。
【００８８】
ステップ１１２８の結果、新たなマニフェストが必要でない場合、端末は、ステップ１１３２で、その現在状態に基づいて次のセグメントを継続して要求し、ステップ１１３４で、上記セグメントを受信して復号化及び再生する。すると、端末は、サービスを継続して所望するか否かを判定し、上記ステップを反復する。
【００８９】
上記した端末動作は、本発明のすべての実施形態に適用できることはもちろんである。
【００９０】
図１２は、サーバの動作を示すフローチャートである。
【００９１】
サーバは、ステップ１２００で、マニフェストを生成するためにサービス情報を収集する。
【００９２】
ステップ１２１０で、サーバは、マニフェストが他のサービスデータと同一のファイルにあるか否かを判定する。
【００９３】
マニフェストが独立的である場合、すなわち、マニフェストが他のサービスデータと異なるファイルにある場合、サーバは、ステップ１２１２で、一つのＵＲＬを有し、独立的なマニフェストを生成する。ステップ１２１４で、サーバが端末からマニフェスト要求を受信する場合、サーバは、一つのＵＲＬに基づいて生成されたマニフェストを端末に伝送する。
【００９４】
端末は、このマニフェストを分析した後、期待したセグメントの提供をサーバに要求する。
【００９５】
サーバがセグメントに対する要求を受信する場合、サーバは、ステップ１２１９で、ヘッド情報を用いてｍｏｏｖボックスを生成し、ステップ１２２０で、端末により要求されたセグメント及びｍｏｏｖボックスを端末に伝送する。したがって、セグメント要求を端末から受信すると、サーバは、期待したセグメントを端末に伝送する。
【００９６】
ステップ１２１０での判定の結果、マニフェストが他のサービスデータと同一のファイルに存在する場合、サーバは、ステップ１２１８で、ファイル内にマニフェストボックスを生成する。その後、生成されたマニフェストが端末によってダウンロードされる。サーバがセグメントに対する要求を受信する場合、サーバは、ステップ１２１９で、ヘッド情報を用いてｍｏｏｖボックスを生成し、ステップ１２２０で、端末により要求されたセグメント及びｍｏｏｖボックスを端末に伝送する。すなわち、セグメント要求を端末から受信すると、サーバは、期待したセグメントを端末に伝送する。あるいは、ステップ１２１８で生成されたマニフェストボックスは、ステップ１２１９で生成されたｍｏｏｖボックスとユーザーに転送されるセグメントと一緒に、一つのファイルに組合されて端末に伝送される。上記したサーバ動作は、本発明のすべての実施形態に適用することができる。
【００９７】
図１３は、端末のブロック構成図である。
【００９８】
端末１３００は、マニフェストパーサ(parser)１３１０、ファイルパーサ１３２０、及びデコーダ１３３０を含む。
【００９９】
マニフェストパーサ１３１０は、ｍｏｏｖボックス及びメディアデータボックスと独立的である場合、マニフェストを獲得して分析する。さらに、ファイルパーサ１３２０は、マニフェストボックス以外に、ｍｏｏｖボックス及び多様な他のボックスを含む他のボックスを要求して分析する。マニフェストパーサ１３１０は、マニフェストがファイル内にある場合、ファイル内にマニフェストボックスを検出して分析する。
【０１００】
ファイルパーサ１３２０は、ファイル内に他のボックス及びｍｄａｔを分析する。すると、端末は、期待したセグメントを要求して、復号化及び再生する。
【０１０１】
図１４は、サーバのブロック構成図である。
【０１０２】
サーバ１４００は、サービスデータ提供部１４１０、マニフェスト生成器１４１２、及びファイル生成器１４１４を含む。
【０１０３】
サーバ１４００のサービスデータ提供部１４１０は、すべてのサービスソースを有する。
【０１０４】
図に示されていない制御部は、端末からマニフェスト要求を受信し、マニフェストが独立的であるか否かを判定する。
【０１０５】
マニフェスト生成器１４１２は、マニフェストがデータファイルから独立的である場合、ファイルからサービスデータと一部情報(例えば、セグメントの位置)に基づいてマニフェスト情報を生成する。
【０１０６】
ファイル生成器１４１４は、マニフェストがファイル内部にある場合、マニフェストボックスがファイル内に含まれるようにファイルを生成する。マニフェストがデータファイルから独立的である場合、マニフェストファイルを除いた他のファイルは、ｍｏｏｖボックス及びセグメントを含むように生成される。
【０１０７】
さらに、図示されていないが、本発明の実施形態により生成されたファイルフォーマットに従ってデータを記録、格納、及び再生することができる。すなわち、一つのファイル内にマニフェストが含まれた場合、格納媒体(例えば、ＣＤ、ＤＶＤ、ＢＤ、又はＵＳＢ)に、一つのファイル内に複数のセグメント及びｍｏｏｖボックス及びｍａｎｉボックスを含むように格納し、まずｍａｎｉボックスを読み取って解析することによってセグメントを再生できる。また、他のセグメントとｍｏｏｖボックスのファイルと異なる別途のファイルにマニフェストを格納し、別途のファイルに格納されたｍａｎｉボックスをまず読み取って解析することで、所望のデータを含むセグメントを再生することができる。格納媒体が格納及び再生に採用される場合、本発明の実施形態で上記したＵＲＬ情報は、格納位置情報(例えば、メモリアドレス)により代替されて容易に格納及び再生することができる。
【０１０８】
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲の記載及びこれと均等なものに基づいて定められる本発明の範囲及び趣旨を逸脱することなく、形式や細部の様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。
【符号の説明】
【０１０９】
１３１０ マニフェストパーサ
１３２０ ファイルパーサ
１３３０ デコーダ
【特許請求の範囲】
【請求項１】
サーバにおけるファイル伝送方法であって、
マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含む一つ以上のセグメントを一つのファイルに生成するステップと、
生成された一つのファイルを端末に伝送するステップと、
を有することを特徴とする方法。
【請求項２】
サーバにおけるファイル生成装置であって、
マニフェスト情報を伝送するためのマニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含むセグメントを生成する生成部と、
前記マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを端末に伝送する伝送部と、を含み、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに伝送されることを特徴とする生成装置。
【請求項３】
端末におけるファイル再生方法であって、
サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するステップと、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化及び再生を遂行するステップと、を有し、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれることを特徴とする再生方法。
【請求項４】
端末におけるファイル再生装置であって、
サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するパーサと、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化するデコーダと、を含み、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれることを特徴とする再生装置。
【請求項５】
データ構成を格納可能な記録媒体であって、
マニフェスト情報を伝送するマニフェストボックスと、
ｍｏｏｖボックスと、
メディアデータボックスを含む一つ以上のセグメントと、を含み、
前記マニフェストボックス、ｍｏｏｖボックス、及び一つ以上のセグメントが一つのファイルに含まれることを特徴とする記録媒体。
【請求項６】
前記マニフェスト情報は、前記一つ以上のセグメントのオフセット及びサイズ情報を含むことを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項７】
前記マニフェスト情報は、次のマニフェストオフセット及び次のマニフェストサイズに関する情報を含むことを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項８】
前記一つのファイルは伝送されるセグメントのうち一部セグメントを含み、前記一つのファイルから独立したファイルは伝送されるセグメントのうち残りのセグメントを含むことを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項９】
前記一部セグメントの位置は、前記一部のセグメントのオフセット情報及びサイズ情報で表され、前記残りのセグメントの位置はＳｅｇｍｅｎｔＵＲＬ属性で表されることを特徴とする請求項８に記載の方法、請求項８に記載の生成装置、請求項８に記載の再生方法、請求項８に記載の再生装置、及び請求項８に記載の記録媒体。
【請求項１０】
前記マニフェストボックスは前記ｍｏｏｖボックスに格納されることを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項１１】
前記一つのファイルはメタデータボックスをさらに含み、前記マニフェストボックスは前記メタデータボックスに格納されることを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項１】
サーバにおけるファイル伝送方法であって、
マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含む一つ以上のセグメントを一つのファイルに生成するステップと、
生成された一つのファイルを端末に伝送するステップと、
を有することを特徴とする方法。
【請求項２】
サーバにおけるファイル生成装置であって、
マニフェスト情報を伝送するためのマニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを含むセグメントを生成する生成部と、
前記マニフェストボックス、ｍｏｏｖボックス、及びメディアデータボックスを端末に伝送する伝送部と、を含み、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに伝送されることを特徴とする生成装置。
【請求項３】
端末におけるファイル再生方法であって、
サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するステップと、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化及び再生を遂行するステップと、を有し、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれることを特徴とする再生方法。
【請求項４】
端末におけるファイル再生装置であって、
サーバからマニフェストボックス、ｍｏｏｖボックス、及びセグメントを受信して分析するパーサと、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントの分析結果に基づいて復号化するデコーダと、を含み、
前記マニフェストボックス、ｍｏｏｖボックス、及びセグメントは一つのファイルに含まれることを特徴とする再生装置。
【請求項５】
データ構成を格納可能な記録媒体であって、
マニフェスト情報を伝送するマニフェストボックスと、
ｍｏｏｖボックスと、
メディアデータボックスを含む一つ以上のセグメントと、を含み、
前記マニフェストボックス、ｍｏｏｖボックス、及び一つ以上のセグメントが一つのファイルに含まれることを特徴とする記録媒体。
【請求項６】
前記マニフェスト情報は、前記一つ以上のセグメントのオフセット及びサイズ情報を含むことを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項７】
前記マニフェスト情報は、次のマニフェストオフセット及び次のマニフェストサイズに関する情報を含むことを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項８】
前記一つのファイルは伝送されるセグメントのうち一部セグメントを含み、前記一つのファイルから独立したファイルは伝送されるセグメントのうち残りのセグメントを含むことを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項９】
前記一部セグメントの位置は、前記一部のセグメントのオフセット情報及びサイズ情報で表され、前記残りのセグメントの位置はＳｅｇｍｅｎｔＵＲＬ属性で表されることを特徴とする請求項８に記載の方法、請求項８に記載の生成装置、請求項８に記載の再生方法、請求項８に記載の再生装置、及び請求項８に記載の記録媒体。
【請求項１０】
前記マニフェストボックスは前記ｍｏｏｖボックスに格納されることを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【請求項１１】
前記一つのファイルはメタデータボックスをさらに含み、前記マニフェストボックスは前記メタデータボックスに格納されることを特徴とする請求項１に記載の方法、請求項２に記載の生成装置、請求項３に記載の再生方法、請求項４に記載の再生装置、及び請求項５に記載の記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公表番号】特表２０１３−５１８５０７（Ｐ２０１３−５１８５０７Ａ）
【公表日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願番号】特願２０１２−５５１１０４（Ｐ２０１２−５５１１０４）
【出願日】平成２３年３月４日（２０１１．３．４）
【国際出願番号】ＰＣＴ／ＫＲ２０１１／００１５２６
【国際公開番号】ＷＯ２０１１／１０８８９３
【国際公開日】平成２３年９月９日（２０１１．９．９）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公表日】平成２５年５月２０日（２０１３．５．２０）
【国際特許分類】
【出願日】平成２３年３月４日（２０１１．３．４）
【国際出願番号】ＰＣＴ／ＫＲ２０１１／００１５２６
【国際公開番号】ＷＯ２０１１／１０８８９３
【国際公開日】平成２３年９月９日（２０１１．９．９）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]