JP6352931B2 - ハイブリッドネットワークにおけるマルチメディアデータを送受信するための装置及びその方法 - Google Patents

Description

本開示は、ハイブリッドネットワークにおいて、マルチメディアデータを送受信するための装置及びその方法に関し、より詳しくは、ＭＭＴ（ＭＰＥＧ Media Transport）がサポートされないデータタイプである場合に、ＭＭＴを再生する装置及び方法に関する。

最近のマルチメディアサービスでは、放送網及び通信網が同時に接続されるハイブリッド（Hybrid）ネットワークと、マルチメディアデータ、アプリケーション、及びファイルが共に提供されるハイブリッドコンテンツの提供のためのＭＭＴ（ＭＰＥＧ Media Transport）技術が考慮されている。
ＭＭＴストリームは、ＭＰＵ（Media Processing Unit）と称される単位で分割されて送信され、メディア再生装置でもＭＰＵ単位で受信し再生する。ＭＭＴストリームをＭＰＵに分割する場合は、ただ一定の時間又は一定のサイズに分割するのではなく、該当ＭＰＵ内に含まれるメディアの構造を記述し、該当ＭＭＴストリームから要請される動作が実行できる単位で分割される。

一方、現在のＭＰＵ構造において、ＭＭＴをサポートしない再生装置は、ＭＰＵに含まれたメディアデータを受信できない。また、現在のＭＰＵ構造は、特定時間に再生されるデータである時間メディアデータの送信には効率的であるが、非時間データの送信には非効率的である。
上述した情報は、本開示の理解を助けるために背景情報としてだけ提示される。本開示に対する先行技術で適用されることができるか否かに関してはいかなる決定及びいかなる主張もない。

本開示の目的は、上述した課題又は不都合な点を解決し、少なくとも以下に示す優位性を提供する。すなわち、本開示の目的は、ＭＭＴをサポートしないメディア再生装置でＭＭＴメディアデータを受信及び再生できるようにするＭＰＵの構造を提供することにある。
本開示の一実施形態は、非時間メディアデータを送信できるマルチメディアデータを送信するための装置及びその方法を提供する。
本開示の一実施形態は、ネットワークノードでＭＦＵを削除又は変更しても受信側で再度ＭＰＵのアップデートを受け取らなくてもよく、相異なるＡＵにかかるＭＦＵ関係を考慮して、ＭＦＵ単位で削除できるマルチメディアデータを送信するための装置及びその方法を提供する。

本開示の一実施形態による方法は、放送及びインターネット通信を同時に提供するハイブリッドネットワークにおけるメディアデータを送信する方法であって、メディアデータ処理のためのメディア処理ユニット（ＭＰＵ）を生成する過程と、生成された上記ＭＰＵを送信する過程と、を含み、上記ＭＰＵは、上記ＭＰＵに対する情報を含むＭＭＰＵボックスと、上記メディアデータから生成された少なくとも一つのメディアデータフラグメントを含むＭＤＡＴボックスと、上記少なくとも一つのメディアデータフラグメント別に、上記メディアデータフラグメントに対する情報を含むＭＭＦＵボックスと、を含む。

本開示の一実施形態によると、上記ＭＭＰＵボックスは、上記メディアデータが時間データであるか非時間データであるかを示す第１のフラグと、上記ＭＰＵがＭＦＵを含むか否かを示す第２のフラグと、上記ＭＰＵが原本ＭＰＵであるか変更されたＭＰＵであるかを示す第３のフラグとのうち少なくとも一つを含む。
本開示の一実施形態によると、上記ＭＭＰＵボックスは、上記ＭＰＵが複数個のメディアデータフラグメントを含む少なくとも一つのアクセスユニット（ＡＵ）を含む場合、上記ＡＵに対する情報を含むＡＵ構造ボックスを含む。

本開示の一実施形態によると、上記ＭＭＰＵボックスは、上記少なくとも一つのメディアデータフラグメントとそれに対応するＭＭＦＵボックスに対する情報とを含むＭＦＵ構造ボックスを含む。
本開示の一実施形態によると、上記ＭＦＵ構造ボックスは、上記ＭＰＵが複数個のメディアデータフラグメントを含む少なくとも一つのアクセスユニット（ＡＵ）を含む場合、上記メディアデータフラグメントと上記ＡＵとの間の関係情報を含む。
本開示の一実施形態によると、上記ＭＦＵ構造ボックスは、上記メディアデータフラグメントの相互間の参照情報、優先順位情報、時間及び空間的ハイブリッド階層情報のうち少なくとも一つを含み、上記情報は、相異なるＡＵに属するメディアデータフラグメントを考慮して決定される。

本開示の一実施形態によると、上記メディアデータフラグメントに対する情報は、上記メディアデータフラグメントのシーケンス番号、サイズ、位置情報のうち少なくとも一つを含む。
本開示の一実施形態によると、上記第３のフラグは、上記ＭＰＵに含まれたメディアデータフラグメントのうち少なくとも一つが削除された場合、上記メディアデータフラグメントが削除されたエンティティによって変更されたＭＰＵであることを示すように修正される。

本開示の一実施形態による装置は、放送及びインターネット通信を同時に提供するハイブリッドネットワークでメディアデータを送信する装置であって、メディアデータ処理のためのメディア処理ユニット（ＭＰＵ）を生成するＭＰＵ生成部と、生成された上記ＭＰＵを送信する送信部と、を含み、上記ＭＰＵは、上記ＭＰＵに対する情報を含むＭＭＰＵボックスと、上記メディアデータから生成された少なくとも一つのメディアデータフラグメントを含むＭＤＡＴボックスと、上記少なくとも一つのメディアデータフラグメント別に、上記メディアデータフラグメントに対する情報を含むＭＭＦＵボックスと、を含む。

本開示の一実施形態による方法は、放送及びインターネット通信を同時に提供するハイブリッドネットワークでメディアデータを受信する方法であって、メディアデータ処理のためのメディア処理ユニット（ＭＰＵ）を受信する過程と、受信された上記ＭＰＵを用いてメディアデータを復元する過程と、を含み、上記ＭＰＵは、上記ＭＰＵに対する情報を含むＭＭＰＵボックスと、上記メディアデータから生成された少なくとも一つのメディアデータフラグメントを含むＭＤＡＴボックスと、上記少なくとも一つのメディアデータフラグメント別に、上記メディアデータフラグメントに対する情報を含むＭＭＦＵボックスとを含む。

本開示の一実施形態による装置は、放送及びインターネット通信を同時に提供するハイブリッドネットワークでメディアデータを受信する装置であって、メディアデータ処理のためのメディア処理ユニット（ＭＰＵ）を受信するＭＰＵ受信部と、受信された上記ＭＰＵを利用して上記メディアデータを復元するデータ復元部と、を含み、上記ＭＰＵは、上記ＭＰＵに対する情報を含むＭＭＰＵボックスと、上記メディアデータから生成された少なくとも一つのメディアデータフラグメントを含むＭＤＡＴボックスと、上記少なくとも一つのメディアデータフラグメント別に、上記メディアデータフラグメントに対する情報を含むＭＭＦＵボックスとを含む。

本開示の他の実施形態による装置は、マルチメディアデータを送信する装置であって、ＭＰＵを利用して従来のメディアフォーマットのデータを送信することができ、従来の再生装置と互換性のあるＭＰＵ構造を有し、非時間メディアデータを送信できる。また、ＭＦＵを削除してもＭＰＵをアップデートしなくてもよく、相異なるＡＵにかかるＭＦＵ関係を考慮してＭＦＵ単位で削除することができる。
本開示の他の目的、利点、及び顕著な特徴は、添付の図面及び本開示の実施形態からなされた以下の詳細な説明から、この分野の当業者に明確になるはずである。

既存のＭＰＵ構造を説明するための図である。 本開示の一実施形態によるネットワークノードにおける相異なるＡＵ内のＭＦＵを考慮してＭＦＵを除去する方式を説明する図である。 本開示の一実施形態によるネットワークノードにおける相異なるＡＵ内のＭＦＵを考慮してＭＦＵを除去する方式を説明する図である。 本開示の一実施形態によるＭＰＵの構造を説明する図である。 本開示の一実施形態によるネットワークノード又は受信端末などがＭＰＵを受信した以後、ＭＰＵを修正するか又はＭＰＵを復元する過程を説明する図である。 本開示の一実施形態によるネットワークノード又は受信端末などがＭＰＵを受信した以後、ＭＰＵを修正するか又はＭＰＵを復元する過程を説明する図である。 本開示の一実施形態によるマルチメディアデータを送信する方法を示すフローチャートである。

本開示の実施形態の上述した及び他の様相、特徴、及び利点は、添付の図面が併用された後述の詳細な説明から、より一層明らかになるはずである。
添付の図面を参照した下記の説明は、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるような本開示の実施形態の包括的な理解を助けるために提供され、この理解を助けるための様々な特定の詳細を含むが、それらは単なる実施形態にすぎない。したがって、本開示の範囲及び趣旨を逸脱することなく、ここに説明した実施形態の様々な変更及び修正が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明を省略する。

以下の説明及び特許請求の範囲で使用する用語及び単語は、辞典的意味に限定されるものではなく、本開示の理解を明確且つ一貫性があるようにするために使用される。したがって、本開示の実施形態の説明が単に実例を提供するためのものであって、特許請求の範囲及びこれと均等なものに基づいて定義される開示をさらに限定する目的で提供されるものでないことは、本開示の技術分野における通常の知識を持つ者には明らかである。
本願明細書に記載の各要素は、文脈中に特に明示しない限り、複数形を含むことを、当業者は理解すべきである。したがって、例えば、“コンポーネント表面（a component surface）”との記載は、１つ又は複数の表面を含む。

まず、本開示の実施形態で使用される用語に対して、ＭＭＴ標準に基づいて説明する。
メディアフラグメントユニット（Media Fragment Unit:ＭＦＵ）は、メディア復号器により独立的に消費され得る符号化されたメディアデータを含む、特定メディアコーデックから独立的な、一般的なコンテナである。それは、アクセスユニット（access unit:ＡＵ）よりも小さいか同一であり、伝達階層により利用され得る情報を含む。
アクセスユニット（ＡＵ）は、時間情報が示され得る最小のデータエンティティである。復号及び関連するプレゼンテーションのために指定された時間情報がない符号化されたメディアデータに対しては、アクセスユニットは定義されない。

メディア処理ユニット（Media Processing Unit:ＭＰＵ）は、特定のメディアコーデックから独立的な、少なくとも一つ以上のアクセスユニット（ＡＵ）と関連情報の追加的な伝達及び消費を含む一般的なコンテナである。非時間（non-timed）データに対して、ＭＰＵは、ＡＵ境界のないデータ部分を含む。ＭＰＵは、完全で独立的に処理できる符号化されたメディアデータユニットである。ここで、処理とは、ＭＭＴパッケージ又は伝達のためのパッケージへのカプセル化を意味する。

非時間データ（non-timed data）は、特定されない時間に消費されるデータエレメントである。非時間データはデータが実行され得る使用可能な時間範囲を有することができる。
時間データ（timed data）は、復号及びプレゼンテーションのために、特定の時間と関連するデータ要素として定義される。

以下で本開示の実施形態に対して詳細に説明する。
図１は既存のＭＰＵの構造を説明する図である。
図１で、ＭＰＵ１００は、ＭＭＴ処理ユニット（ＭＭＴ Processing Unit:ＭＭＰＵ）１０５と、少なくとも一つのＭＦＵ１３０，１４０，１５０とで構成される。上記ＭＭＰＵは、ＭＰＵ自体の構造に対する情報を含み、図１における、トラックフラグメントヘッダ（Track Fragment Header:ＴＦＨＤ）１０７、トラックフラグメントラン（Track Fragment Run:ＴＲＵＮ）１１０、サブ−サンプル情報（Sub-Sample information:ＳＵＢＳ）１２０のようなボックスを含む。該当ボックスの具体的な内容に対する説明は省略する。ＭＦＵ１３０，１４０，１５０は各々ＭＭＦＵとメディアデータボックス（Media Data Box:ＭＤＡＴ）とを含む。それぞれのＭＭＦＵは、該当ＭＦＵ自体の構造に対する情報を含み、ＭＤＡＴは実際メディアデータを含む。一方、ここでＭＦＵに含まれるメディアデータは時間メディアデータである。非時間メディアデータの場合は分割されて送信される必要がないため、ＭＰＵ内で送信されてもＭＦＵの形態で分割されて送信されない。

また、図示されないが、複数のＭＦＵは、一つのＡＵに含まれることもできる。例えば、ＭＰＵ内に５個のＭＦＵがあるとすれば、５個のＭＦＵのうち最先の２個のＭＦＵはＡＵ１に含まれ、残りの３個のＭＦＵはＡＵ２に属することができる。この場合、ＭＭＰＵは、ＡＵの構造に対する情報を含むＡＵ構造（structure）を含む。具体的にＡＵ構造はＭＭＰＵ内のＴＲＵＮ１１０ボックスに含まれる。
＜表１＞は、図１における時間メディアデータに対するアクセスユニット（access unit:ＡＵ）の構造を説明する。

＜表１＞のようなＡＵに対する情報はＴＲＵＮボックス１１０に含まれる。ＴＲＵＮボックス１１０は、該当時間メディアデータサンプルの基本長とサンプルの個数、サンプル長が相異なる場合におけるサンプル長、サンプルの再生時間、復号順序、該当サンプルがＲＡＰ（Random Access Point）であるか否か、該当するＭＦＵの開始及び終了番号情報などを含む。
しかし、非時間データの場合、ＭＰＵ１００はＭＦＵを含めないことがあるので、ＭＰＵにＭＦＵの開始インデックスとＭＦＵの終了インデックスに対する情報が含まれることは不要である。すなわち、非時間メディアデータがＭＦＵに含まれる場合、ＭＰＵ１００は、ＡＵ構造及び時間情報が必要ではない。したがって、不必要な情報はオーバーヘッドになる。したがって、本開示の実施形態では、このような情報をＡＵではなくＭＦＵに含める。したがって、本開示の実施形態では、ＭＰＵ内にＭＦＵが含まれているか否かを示すことができる。

一方、ＭＭＴフォーマットをサポートしない既存の時間メディアデータは、ＭＭＴフォーマットのＭＦＵによってカプセル化（encapsulated）されない。したがって、上記ＭＰＵ１００が既存のメディアデータを含む場合、ＭＰＵはＭＦＵに対する情報を含む必要がない。また、既存のメディア再生装置は、ＭＭＴフォーマットをサポートしないため、受信したメディアデータ内にＭＭＴで規定されたＭＰＵ内のボックスが認識できないので、ＭＭＰＵボックスやＭＭＦＵボックスをスキップ（skip）するようになる。したがって、ＭＰＵ内には既存のメディア再生装置がアクセスできるボックスがない。結局、既存のメディア再生装置は、ＭＭＦＵ内に含まれているメディアデータを認識できず、したがって現在のＭＰＵ構造はＭＭＴをサポートしない既存のメディア再生装置と互換性がない。このような点を考慮して本開示の実施形態によるＭＰＵ構造は、ＭＭＴをサポートしないメディア再生装置との互換を可能にする。このために、ＭＭＦＵがＭＦＵのシーケンス番号（sequence number）、メディアデータのサイズ情報、メディアデータの位置情報（offset）を含むようにする。

一方、上述したようにＭＭＴ時間メディアデータはＭＦＵ単位で送受信される。しかし、複数個のＭＦＵを送信する間に自体的にＭＦＵが失われることもあるが、任意のネットワークノードでチャネル状況を考慮してＭＦＵを送信しないこともある。例えば、チャネル状況が急激に悪くなって、データ送信率を半分程度下げたい場合は、送信する全体のＭＦＵのうち半分のＭＦＵを送信しない。この場合、受信側では、いずれか一つのＭＦＵが失われる場合、全体ＭＰＵに対する情報をまた受信すべきである。すなわち、失われたＭＦＵによって、その状況を反映したＭＰＵのアップデートを受け取らないと、全体メディアデータを復元できない。本開示の実施形態によるＭＰＵ構造は、ＭＦＵが失われても全体ＭＰＵを再受信することなく、全体メディアデータを復元できる。このために本開示の実施形態では、該当ＭＰＵが原本ＭＰＵから変更された部分を有するか否かを示す情報を含むようにして、受信側にとって該当情報からどの部分が変更、又は削除されたか認識できるようにする。

上述したような本開示の実施形態によるＭＰＵの構造をより詳細に説明する。
本開示の実施形態によるＭＭＰＵは、“フラグ（flag）”フィールド、“メディア情報テーブル（media info table）”フィールド、“ＡＵ構造（structure）”フィールド、“ＭＰＵ構造（structure）”フィールドのうち少なくとも一つを含む。

まず、フラグフィールドを説明する。本開示の実施形態によるフラグフィールドは３個のフラグを含む。“フラグ１”は、該当ＭＰＵに含まれたデータが時間データであるか非時間データであるかを示すフラグである。“フラグ２”は、該当ＭＰＵがＭＦＵを含むか否かを示すフラグである。“フラグ３”は、該当ＭＰＵが原本（original）ＭＰＵであるか変更されたＭＰＵであるかを示すフラグである。

フラグ１を具体的に説明する。フラグ１が“１（true）”であると、ＭＰＵ１００は時間メディアデータを有し、フラグ１が“０（false）”であると、ＭＰＵ１００は非時間メディアデータを有することを示す。もちろん、その逆も可能である。また、フラグ１が“１（true）”であると、時間メディアデータに対する時間情報が提供されることを示し、フラグ１が“０（false）”であると、時間に対する情報は提供されないことを示す。上記時間メディアデータに対する時間情報とは、時間メディアデータが再生される時間を意味する。

“フラグ（flag）２”を具体的に説明する。フラグ２が“１（true）”であると、ＭＰＵはＭＦＵでカプセル化されたメディアデータを有し、フラグ２が“０（false）”であると、ＭＰＵはＭＦＵでカプセル化されていないメディアデータを含んでいることを示す。もちろん、その逆も可能である。参考までに、ＭＦＵでカプセル化されないメディアフォーマットを有するメディアデータは、例えば、ＭＰＥＧ−２ＴＳ（Transport Stream）やＩＳＯＦＦで示したメディアデータであり得る。また、追加的にフラグ２が“true”であると、ＭＦＵの構造情報が提供されることを示し、フラグ２が“false”であると、ＭＦＵの構造情報が提供されないことを示す。上述したフラグ２は、ＭＰＵがＭＦＵでカプセル化したメディアデータを含むか否かを示すものであるため、これは、結局ＭＰＵがＭＭＴをサポートするメディアデータを含むか否かを示すことになる。
一方、“フラグ３”に対しては後述する。

以下でＭＦＵ構造に対して説明する。
ＭＦＵ構造は、ＡＵが存在するか否かに関わらず、独立的に存在できると仮定される。ＡＵが存在してＭＦＵがＡＵに含まれた場合、ＭＦＵ構造はＡＵとＭＦＵとの間の関係に関する情報を含む。一方、ＡＵが存在しなくてＭＦＵがＡＵに含まれない場合、ＭＦＵ構造はＡＵとＭＦＵとの間の関係に関する情報を含まない。この場合、ＡＵとＭＦＵとの間の関係に関する情報とは、それぞれのＡＵに属するＭＦＵの個数情報を含む。したがって、ＡＵのテーブルとＭＦＵのテーブルとをマッピングするためのマッピング情報を利用することが可能である。

また、ＭＦＵが時間メディアデータを含む場合、ＭＦＵは“時間メディア”データタイプを含むものであるため、ＭＦＵが有するメディアデータのタイプを所定の基本値として指示してＭＦＵが有するメディアタイプを記述できる。一方、上記メディアタイプは、メディア情報テーブルで設定されたメディアタイプのうち一つから選択されることができる。一方、ＭＦＵが非時間メディアを含む場合、ＭＦＵは、相異なる複数のメディアタイプを有することができる。したがって、該当ＭＦＵがメディア情報テーブルのうちいずれかのメディアタイプにマッピングされるかをＭＦＵ別に各々示すことができる。

また、ＭＦＵ構造は、ＭＰＵ内の多様なＭＦＵ間の関連関係に対する情報を提供する。図１で説明された既存のＭＰＵ構造内に含まれたＭＦＵには、相異なるＭＦＵ間で相互参照する回数を示す“dependency_counter”フィールド、ＭＦＵ間の優先順位を示す“priority”フィールド、時間的空間的ハイブリッド階層情報を示す“multilayer information”フィールドを有する。しかし、上記情報の参照範囲は、一つのＡＵに属する相異なるＭＦＵに制限される。例えば、ＡＵ１はＭＦＵ１、ＭＦＵ２、ＭＦＵ３を含み、ＡＵ２は、ＭＦＵ３、ＭＦＵ４を含むと仮定すれば、既存のＭＦＵで“dependency_counter”、“priority”、“multilayer information”の各々は、ＡＵ１に属するＭＦＵ１、ＭＦＵ２、ＭＦＵ３間の参照関係だけを示した。同様に、ＡＵ２に属するＭＦＵ３、ＭＦＵ４間の参照関係だけを示した。しかし、相異なるＡＵであるＡＵ１とＡＵ２に属するＭＦＵ間の参照関係が存在することも有り、上記情報が一つのＡＵ内に存在するＭＦＵ間の関係だけを考慮して示される場合、ネットワークノードが効率的にＭＦＵを削除又は変更できない問題がある。

本開示の実施形態では、このような点を考慮して、ＭＦＵ内の“dependency_counter”、“priority”、“multilayer information”を相異なるＡＵ内に存在するＭＦＵ間の関係を考慮して示す。したがって、ネットワークノードは、チャネル状態が混雑して任意のＭＦＵを除去したい場合、効率性よくＭＦＵを除去できる。これに対しては図２ａ及び図２ｂを参照して説明する。

図２Ａ及び図２Ｂは、本開示の実施形態による、ネットワークノードにおける相異なるＡＵ内のＭＦＵを考慮してＭＦＵを除去する方式を説明する図である。
図２Ａは、相異なるＡＵ内部に位置するＭＦＵ間の相互参照が維持されることを実線で図示しており、図２Ｂは、相異なるＡＵ内部に位置するＭＦＵ間の相互参照が維持されないことを点線で図示する。

図２Ａにおいて、相異なるＡＵ２０１，２０３，２０５間で相異なるＭＦＵ２１１，２１３，２１５を相互参照している。しかし、ネットワークノードでＡＵ２ ２０３のＭＦＵ２ ２１３を削除したと仮定すれば、上記削除されたＭＵＦ２ ２１３が参照しているＡＵ１ ２０１とＡＵ３ ２０５内のＭＦＵ１ ２１１とＭＦＵ３ ２１５も削除される。一方、図２ｂでは、ＡＵ２ ２２３内のＭＦＵ２ ２３５がＭＦＵ１ ２３１とＭＦＵ３ ２３５を参照しないために、ＭＦＵ２ ２３５が削除されてもＭＦＵ１ ２３１とＭＦＵ３ ２３５は削除されない。

しかし、図２Ａのように、相異なるＡＵ内部のＭＦＵ間の相互参照が維持された状態で、ＭＦＵ内の“dependency_counter”、“priority”、“multilayer information”が一つのＡＵ内のＭＦＵ間の関係に対する情報だけを考慮して示されていると、ネットワークノードは、該当ＭＦＵが相異なるＡＵ内のＭＦＵを参照していることを考慮しない状態で削除したいＭＦＵを選択するようになる。したがって、ネットワークノードがＭＦＵを削除する場合、一つのＡＵ内に含まれたＭＦＵだけの優先順位などを考慮するために、効率的にＭＦＵを削除することが難しい。

例えば、一つのＡＵ内に５個のＭＦＵがある場合、ネットワークノードが５個のＭＦＵ間の関係だけを考慮して削除するＭＦＵを決定すると、５個のＭＦＵのうち最も重要度（priority）が低いＭＦＵを削除するはずである。しかし、削除されたＭＦＵが相異なるＡＵに含まれたＭＦＵを参照していれば、該当ＭＦＵの重要度は変わる。したがって、ＭＦＵの重要度を示すために該当ＭＦＵが属しているＡＵだけではなく、相異なるＡＵ関係を考慮する。他の情報も同一に、相異なるＡＵを考慮して該当情報を示すと、ネットワークノードでＭＦＵを削除する場合に、このような情報を利用して効率的にＭＦＵを削除できる。
上述した点を考慮して、本開示は＜表２＞のＡＵ構造（structure）と＜表３＞のＭＦＵ構造を提案する。

上記＜表２＞のＡＵ構造は本開示の実施形態によるＭＰＵに含まれる。ＭＰＵに含まれたＡＵ構造は後述する図３に符号３１０で図示される。
図３は本開示の実施形態によるＭＰＵの構造を説明する図である。

上記＜表３＞のＭＦＵ構造は、本開示の実施形態によるＭＰＵに含まれる。ＭＰＵに含まれたＭＦＵ構造は、後述する図３に符号３２０で図示されている。特に、上記＜表３＞では“Dependency counter”、“priority”、“multilayer information”が参照するＭＦＵの範囲は、該当ＭＦＵが現在属しているＡＵだけではなく、相異なるＡＵ内に属しているＭＦＵまで拡張される。また、＜表３＞のＭＦＵ構造は、ＭＦＵのＡＵ内におけるシーケンス番号（number_of_mfu_in_au）、データボックス（ＭＤＡＴ）内に位置している実際メディアデータのサイズ（size）情報を含む。また、＜表３＞に示されないが、必要な場合、メディアデータがデータボックス（ＭＤＡＴ）内の位置を通知するために位置情報（offset）を含むことができる。一方、本開示の実施形態によると、実際メディアデータは既存のＭＰＵ構造とは違ってメディアデータボックス（ＭＤＡＴ）内に配置される。

以下では、ＭＭＴをサポートしない既存のメディアフォーマット再生装置互換性を維持するための方案を説明する。
既存のＭＰＵ構造におけるＭＭＦＵは、時間メディアデータをＭＭＦＵ内に含んでいるが、上述したようにＭＭＴをサポートしない既存のメディアフォーマット再生装置は、ＭＭＦＵを認識できないためにＭＰＵ内にアクセスできるボックスがない。一方、チャンク（Chunk）及びサンプルに基づくアドレシング（addressing）を使用している既存のメディアフォーマットでは不連続的な空間上に時間メディアデータが配置されるなどの問題がある。したがって既存のメディアフォーマット再生装置はＭＭＴとの互換性がない。

したがって、本開示の実施形態では、ＭＦＵのシーケンス番号（sequence number）とメディアデータボックス（ＭＤＡＴ）内のサイズ、また必要であれば、オフセット（offset）を付加的に記述し、実際のメディアデータフラグメントをＭＤＡＴ内に順次に配置する。このようにすれば、ネットワーク装置や保存装置は、ＭＰＵを読み取った以後ＭＰＵに含まれたメディアデータをＭＦＵ単位で削除するため、効率的にＭＰＵを送信又は保存することができる。例えば、サービスプロバイダが最初に生成したＭＰＵを受信したネットワークノードが、ネットワーク状態が悪くなって、任意のメディアデータフラグメントを削除してＭＰＵを送信しようとする場合を仮定する。この場合、ネットワークノードは、ＭＰＵに含まれた複数のＭＭＦＵボックスのうち任意のＭＭＦＵボックスを削除し、該当ＭＭＦＵが示す位置情報及びサイズ情報を利用してＭＤＡＴ内の該当メディアデータを削除することで全体ＭＰＵのサイズを減らすことができる。

一方、上述したようにネットワークノードで一部のメディアデータが削除された場合でも、受信側で、削除されたメディアデータが反映されたＭＰＵを再受信することなく、該当ＭＰＵで特定メディアデータが削除されたことを認識するべきである。以下で、メディアデータが削除された場合でも受信側で認識できるようにする方案に対して説明する。

受信側メディア再生装置を含む任意のネットワークノードがＭＰＵを受信し、ＭＰＵを読み取ってＭＰＵ内部でＭＭＦＵを検索した結果、一部のＭＭＦＵが欠落していると、メディアフォーマット再生装置は、受信したＭＰＵが送信側で最初に送信した原本（original）ＭＰＵではなく、修正されたＭＰＵであると認識できる。ただし、これはメディア再生装置が全てのＭＭＦＵを読み終わってから判定できるので、この判定のための時間が必要である。したがって、本開示の実施形態では、ネットワークエンティティ（entity）が受信したＭＰＵが原本ＭＰＵであるか否かを速く認識させるために、ＭＰＵに“フラグ（flag）３”フィールドが含まれる。

“フラグ３”が“１（true）”であると、該当ＭＰＵは完全な（complete）原本であることを示し、最初に生成されたＭＦＵの全部を含んでいることを示す。“フラグ３”が“０（false）”であると、該当ＭＰＵは一部のＭＦＵが削除又は変更された“変更された（modified）ＭＰＵ”であることを示す。もちろん、その逆も可能である。すなわち、該当ＭＰＵが変更されたＭＰＵであることを示すため、該当ＭＰＵが完全な再生及び保存のために、今後、原本ＭＰＵに切り替えられる。
一方、“フラグ３”は、ＭＰＵの前方に固定されたオフセットの位置に配置されることができる。また、ＭＦＵを削除したネットワークエンティティは、ＭＦＵを削除した以後、該当ＭＰＵが変更されたことを示すためにフラグ３の値を“１（true）”から“０（false）”へ変更できる。
上述した本開示の一実施形態によるＭＭＦＵ構造は下記＜表４＞で例示する。

上記＜表４＞のＭＭＦＵは、本開示の実施形態によるＭＰＵに含まれ、ＭＦＵシーケンス番号、サイズ、オフセットが含まれていることを示す。参考的にＭＰＵに含まれたＭＭＦＵは後述する図３に符号３３０で図示されている。

図３は本開示の実施形態によるＭＰＵ３００の構造を説明する図である。
ＭＭＰＵ３０１は、フラグ３０５、メディア情報テーブル３０７、ＡＵ構造３１０、ＭＦＵ構造３２０を含み、これらを利用してＭＰＵに関連した情報を含む。また、ＭＰＵは少なくとも一つ以上のＭＭＦＵ３３０を含み、それぞれのＭＭＦＵは、それぞれのメディアデータフラグメントに対する情報を含む。ＭＤＡＴ３４０は、少なくとも一つのメディアデータ、すなわち、メディアデータフラグメントを含み、それぞれのメディアデータフラグメントは、ＭＭＦＵに含まれた位置情報（offset）とサイズ情報（size）を有し、シーケンス番号によって順次に配列される。

上記フラグ３０５は、上述したように本開示で提案する“フラグ１”、“フラグ２”、“フラグ３”を含むことができる。上記フラグの内容は説明した通りである。
上記メディア情報テーブル３０７は、ＭＦＵが有するメディアタイプの種類を予め設定したテーブルであって、現在のＭＦＵがどのメディアタイプを有するかを上記テーブルを通して示すことができる。
ＡＵ構造３１０は、＜表２＞で説明した通りである。ＡＵ構造は、図１で説明したＡＵ構造からＡＵとＭＦＵに対する情報が除外されたものである。
ＭＦＵ構造３２０は、＜表３＞で説明した通りである。上述したように、本開示の実施形態では、ＭＦＵ構造３２０内の“Dependency counter”、“priority”、“multilayer information”が参照するＭＦＵの範囲は、該当ＭＦＵが現在属しているＡＵだけではなく、異なるＡＵ内に属しているＭＦＵまで拡張される。

一方、ＭＰＵ３００がＡＵ構造３１０を有すると、ＡＵ構造３１０は該当ＡＵが含むメディアデータに対する情報を含む。また、ＭＰＵ３００がＭＦＵ構造３２０を有すると、ＭＦＵ構造３２０はＡＵとＭＦＵとの間の関係に対する情報を提供する。
また、任意のＭＭＦＵが削除された場合、メディア再生装置を含むＭＰＵを受信したエンティティは、ＭＦＵ構造３２０を利用して、削除されたＭＭＦＵと、ＭＤＡＴ３４０内から削除されたメディアデータ位置とサイズを認識できる。すなわち、上記ＭＦＵ構造３２０は、ＭＭＦＵ別にＭＭＦＵ識別子とＭＭＦＵのサイズ、ＭＭＦＵ３３０のＭＤＡＴ３４０内の位置に関するオフセット（Offset）情報を含み、これら情報を利用して、削除されたＭＭＦＵとＭＤＡＴ内から削除されたメディアデータの位置及びサイズを認識する。

図４Ａ及び図４Ｂは、本開示の一実施形態によるネットワークノード又は受信端末などがＭＰＵを受信した以後に、ＭＰＵを修正するかまたはＭＰＵを復元する過程を説明する図である。
図４Ａにおける３個のＭＰＵは、図３で説明した本開示の実施形態によるＭＰＵ構造に基づく。したがって具体的な構成に対しては説明を省略する。

原本ＭＰＵ４００はコンテンツプロバイダにより生成された最初のＭＰＵを示す。原本ＭＰＵ４００は、ＭＭＰＵ４１１と、４個のＭＭＦＵ４１２と、それぞれのＭＭＦＵに対応する４個のメディアデータ４１３とを含むと仮定した。上記原本ＭＰＵ４００は、最初に送信のために必要な全てのＭＭＦＵとそれぞれのＭＭＦＵに該当するメディアデータを含んでいるので、“原本（Original）ＭＰＵ”と称し、フラグフィールドで“is_complete”値が１になる。上記“is_complete”は、上述した“フラグ３”と同一フラグであって、名称を直観的に示すためのものである。

変更されたＭＰＵ４１０は、ネットワークノードのようにＭＰＵを変更できるネットワークエンティティがＭＰＵの送信又はＭＰＵを効率的に保存するために原本ＭＰＵ４００で一部のＭＦＵを削除又は変更したものである。上記削除又は変更されたＭＰＵ４１０は、一部のＭＭＦＵと該当メディアが削除又は変更されたため、“変更された（Modified）ＭＰＵ”と称し、“is_complete”値が０に設定される。上記“is_complete”は上述したフラグ３と同一フラグである。この場合、原本ＭＰＵ４００を必要によって修正して、ＭＭＦＵ及び該当メディアデータを削除したエンティティが“is_complete”値を“１”から０へ変更できる。すなわち、ネットワークエンティティが原本ＭＰＵ４００を受信した時は“is_complete”値が１であったが、該当エンティティがＭＰＵを修正したので、修正ＭＰＵであることを示すために“is_complete”値を０に設定するものである。

復元されたＭＰＵ４２０は、メディアフォーマット再生装置又は受信したＭＰＵを保存する端末で、受信したＭＰＵを復元して、“復元された（Restored）ＭＰＵ”を生成したことを示す。“is_complete”値が０であるＭＰＵを受信した端末は、ＭＭＦＵ内に含まれたメディアデータに対するサイズ（size）情報と位置情報（すなわち、offset）を利用して削除されたメディアデータのサイズと位置を判定できる。
以後、削除されたメディアデータのサイズの“ダミー（dummy）”データがＭＤＡＴ内で該当メディアデータが削除された位置に満たされる。上記ダミーデータは、特定の意味のないデータであって、復号器がダミーデータを復号する場合にも復号エラーが生じない特徴を有する。

このようにダミーデータを利用して削除されたＭＰＵを復元すれば、復元されたＭＰＵ４２０が生成される。このＭＰＵ４２０は原本ＭＰＵと完全に同一のものではないが、ＭＰＵ及びＭＭＴをサポートしない既存のメディアフォーマットを有する情報が示すデータの位置にデータを位置させたため、“復元されたＭＰＵ”という。上記既存のメディアフォーマットを有する情報は、一例でＩＳＯ１４４９６−１２のＭＯＯＶ、ＭＯＯＦボックスなどであり得る。

図４Ｂは、図４Ａで説明されたＭＰＵにおけるデータの位置を説明するための図である。
原本ＭＰＵ４３０は、ＭＭＰＵ４３１と、４個のＭＭＦＵ４３２と、それぞれのＭＭＦＵに対応する４個のメディアデータ４３３とを含む。原本ＭＰＵ４３０における実線矢印４３５は最初のメディアデータの位置を示す。

修正されたＭＰＵ４４０ではｉｄ＝３を有するＭＭＦＵ４４１が削除される。したがって、ＭＤＡＴ内でもＭＭＦＵ４４１ ｉｄ＝３に対応するメディアデータが削除される。ＭＭＦＵ ｉｄ＝１、２番に対応するメディアデータは原本ＭＰＵ４３０におけるメディアデータと同一位置にある。上側の二つの実線矢印４４３は該当位置にあるメディアデータのエラーが無いことを示す。上側から３番目の点線矢印４４５に位置したメディアデータは、実際ＭＭＦＵ ｉｄ＝４に対応するメディアデータであるため、原本ＭＰＵにおけるメディアデータの位置と異なる。下側の二つの点線矢印４４７は、このように該当位置のメディアデータが原本ＭＰＵ４３０におけるメディアデータ位置と異なる位置に存在してエラーがあることを示している。

一方、上述したように、ダミーデータを利用してメディア再生装置又は端末機が復元ＭＰＵ４５０を生成すれば、原本ＭＰＵにおけるデータ位置と同一位置にデータが存在するようになる。このようにして原本ＭＰＵとの互換性が保障され、既存メディアフォーマットと互換性が保障されることができる。

以下では、本開示の実施形態で使用されるメディアのタイプに対して説明する。
本開示の実施形態で使用されるメディアタイプは、時間メディアデータと非時間メディアデータの両方が適切なマイムタイプ（ＭＩＭＥ type）と、メディア初期化情報及び基本情報を提供する。
時間メディアデータと非時間メディアデータには、一つ又は複数個のメディアタイプテーブルが提供され、それぞれのマイムタイプによって該当メディアデータの初期化に必要な、適切な情報を提供する。
時間メディアデータの代表的な初期化情報には、シーケンスパラメータ集合（Sequence Parameter Set）とピクチャーパラメータ集合（Picture Parameter Set）のようなパラメータ集合（Parameter Set）がある。

ＭＰＵを再生しようとする再生装置は、ＭＭＴアセット（Asset）内で連続する任意のＭＰＵのうち一つの再生を開始し、メディアのタイプによって、時間メディアデータの場合は、パラメータ集合（Parameter set）を読み取ってデコーダー装置を初期化し、以後、時間メディアデータをデコーダーに印加して正常に再生を実行することができる。参考までに上記ＭＭＴアセットは、少なくとも一つのＭＰＵの集合である。

一方、非時間メディアデータの代表的な例としてはファイルがあり得る。ファイルを初期化するための情報には、ファイル名、サイズ、ＣＲＣ（Cyclic Redundancy Check）のような情報があり得る。ファイルは、一つのＭＦＵにマッピングされて提供され、ＭＦＵ構造では、どのファイルがどこに位置しているかに対する情報が記述されているので、再生装置はＭＰＵ内に複数のファイルがある場合、ファイルの情報とファイルの位置をマッピングして希望のファイルを抽出できる。
上述したメディアタイプテーブルの一例は、＜表５＞に示され、この場合のＭＭＰＵは＜表６＞のようである。

上記＜表５＞のメディアタイプテーブルはＭＭＰＵ内に含まれ、これは上述した図３で符号３０７で図示される。該当メディアタイプテーブルは、ＭＰＵ内のメディアのタイプに対する情報を提供する。すなわち、該当メディアがどのコーデックを使用し、どの圧縮方式を使用しているかに対する情報を提供する。

上記＜表６＞は、アセット（asset）情報とasid情報と、本開示の実施形態によるＭＰＵボックスを説明する。
上述したように＜表６＞で“has_timed_media”は、フラグ１のようなフラグであり、ＭＰＵが時間又は非時間メディアデータであることを示す。また、“has_mfu”は、フラグ２に対応し、ＭＰＵがＭＦＵ構造を有するか否かを示す。“is_complete”はフラグ３に対応し、ＭＰＵが“原本フラグ”であるか削除されたＭＦＵを有する“変更されたフラグ”であるかを示す。

図５は、本開示の一実施形態によるマルチメディアデータを送信する方法を示すフローチャートである。
図５を参照すれば、メディアデータ送信装置は、ステップ５００でメディアデータに対するＭＦＵを生成し、ステップ５１０で上記メディアデータを再生する情報を含むＭＰＵを生成する。以後、生成されたＭＰＵを送信する。
この場合、上記ＭＰＵは、図３で説明したように、本開示で提案するＭＰＵ構造を有する。

一方、上述したメディアデータ送信装置及び方法に対応してメディアデータを受信する装置及び方法が具現可能であることが当業者に自明な事項であるため、これに対する詳細な説明は省略する。
本開示の詳細な説明では具体的な実施形態に関して説明したが、本開示の範囲から逸脱しない限度内で多様な変形が可能であることは明らかである。
したがって、本開示の範囲は、説明された実施形態に限定されず、添付の特許請求範囲だけではなく、この特許請求範囲と均等なものにより定められるべきである。

１００，３００ メディア処理ユニット（ＭＰＵ）
１０５ ＭＰＥＧメディアトランスポート（ＭＭＴ）処理ユニット（ＭＭＰＵ）
１０７ トラックフラグメントヘッダ（ＴＦＨＤ）
１１０ トラックフラグメントラン（ＴＲＵＮ）
１２０ サブ−サンプル情報（ＳＵＢＳ）
１３０，１４０，１５０，２１１，２１３，２１５，２３１，２３３，２３５ メディアフラグメントユニット（ＭＦＵ）
２０１，２０３，２０５，２２１，２２３，２２５ アクセスユニット（ＡＵ）
３０５ フラグ
３０７ メディア情報テーブル
３１０ ＡＵ構造
３２０ ＭＦＵ構造
３３０ ＭＭＴフラグメントユニット（ＭＭＦＵ）
３４０ メディアデータボックス（ＭＤＡＴ）

Claims (5)

1. 放送ネットワークにおけるメディアデータを送信する方法であって、
   メディアデータ部分及び情報部分を含むメディア処理ユニットを生成する過程と、
   前記メディア処理ユニットを送信する過程と、を含み、
   前記メディアデータ部分は前記メディアデータの少なくとも一つのフラグメントを含み、前記情報部分は前記メディア処理ユニットに対する情報及び前記少なくとも一つのフラグメントに対する情報を含み、
   前記情報部分は、前記メディア処理ユニットがフラグメント構造に対応する全てのフラグメントを含むか否かを示す第１の情報を含むことを特徴とするメディアデータを送信する方法。
2. 前記情報部分は、前記メディア処理ユニットが前記フラグメント構造を含むか否かを示す第２の情報を含むことを特徴とする請求項１に記載のメディアデータを送信する方法。
3. 前記情報部分は、前記メディア処理ユニット内の前記少なくとも一つのフラグメントが時間データであるか非時間データであるかを示す第３の情報を含むことを特徴とする請求項１に記載のメディアデータを送信する方法。
4. 前記情報部分は、シーケンス番号、オフセット情報及び長さ情報のうち少なくとも一つを含み、
   前記シーケンス番号は、前記メディア処理ユニット内の前記少なくとも一つのフラグメントのシーケンス順序を示し、
   前記オフセット情報は、前記メディア処理ユニット内の前記少なくとも一つのフラグメントの位置を示し、
   前記長さ情報は、前記少なくとも一つのフラグメントの長さを示すことを特徴とする請求項１に記載のメディアデータを送信する方法。
5. 前記少なくとも一つのフラグメントは、前記シーケンス番号、前記オフセット情報及び前記長さ情報のうち少なくとも一つに従って配置されることを特徴とする請求項４に記載のメディアデータを送信する方法。
   
   

Images