特許 6553166 マルチメディアシステムにおけるメディアパケットを受信する方法及び装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6553166

(24)【登録日】2019年7月12日

(45)【発行日】2019年7月31日

(54)【発明の名称】マルチメディアシステムにおけるメディアパケットを受信する方法及び装置

(51)【国際特許分類】

   H04N 21/434 20110101AFI20190722BHJP

【ＦＩ】

   H04N21/434

【請求項の数】14

【全頁数】17

(21)【出願番号】特願2017-500077(P2017-500077)

(86)(22)【出願日】2015年7月3日

(65)【公表番号】特表2017-525270(P2017-525270A)

(43)【公表日】2017年8月31日

(86)【国際出願番号】KR2015006898

(87)【国際公開番号】WO2016003244

(87)【国際公開日】20160107

【審査請求日】2018年5月7日

(31)【優先権主張番号】10-2014-0083996

(32)【優先日】2014年7月4日

(33)【優先権主張国】KR

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100121382

【弁理士】

【氏名又は名称】山下 託嗣

(72)【発明者】

【氏名】パク，キョン−モ

(72)【発明者】

【氏名】プ，ヒョン−チョル

【審査官】 冨田 高史

(56)【参考文献】

【文献】 Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 1: MPEG media transport(MMT)，ISO/IEC23008-1，ISO，２０１４年 ６月 １日，第１版，第１８頁−第３５頁

【文献】 ＭＰＥＧ−４・ＢＩＦＳパケットの欠落と補償方式，映像情報メディア学会技術報告，社団法人映像情報メディア学会，２００１年 ２月２２日，Ｖｏｌ．２５ Ｎｏ．１７，第９頁−第１６頁

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００ − ２１／８５８

(57)【特許請求の範囲】

【請求項1】

マルチメディアシステムにおけるメディアパケットの受信方法であって、
パケットヘッダ及びペイロードを含むメディアパケットを受信するステップと、ここで、前記パケットヘッダは、ランダムアクセスポイント（ＲＡＰ）フラグを含み、前記ペイロードは、ペイロードヘッダ及びペイロードデータを含み、
前記ＲＡＰフラグが、前記ペイロードがＲＡＰ情報を含むことを示す第１の値を有するか否かを識別するステップと、
前記ＲＡＰフラグが前記第１の値を有する場合、前記メディアパケット内に含まれた前記ペイロードをデコーディングするステップと、
前記ＲＡＰフラグが、前記メディアパケットがＲＡＰ情報を含まないことを示す第２の値を有する場合、前記メディアパケットを廃棄するステップと、を含み、
前記ＲＡＰ情報は、メディアデータの伝送及び消費(delivery and consumption)のための少なくとも一つのシグナリングメッセージを含むことを特徴とする方法。

【請求項2】

前記ＲＡＰ情報は、メディアデータアクセスの開始位置情報をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項3】

前記ＲＡＰ情報は、関連するフレームなしに復号化される少なくとも一つのＩフレーム(Intra-coded frame)をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項4】

前記ＲＡＰ情報は、ＩＳＯ基本メディアファイルフォーマット（ＩＳＯＢＭＦＦ）を用いるＭＰＵ（Media Processing Unit）のメタデータをさらに含むことを特徴とする、請求項１に記載の方法。

【請求項5】

前記ＲＡＰフラグが前記第１の値を有する場合、前記ペイロード内の前記ペイロードヘッダ内に含まれるフラグメントタイプフィールドを識別するステップと、
前記ＲＡＰフラグが前記第１の値を有し、前記フラグメントタイプフィールドがＭＰＵのメタデータを示す場合、前記ＲＡＰ情報がＩＳＯＢＭＦＦを用いるＭＰＵのメタデータを含むことを確認するステップと、をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項6】

前記ＲＡＰフラグが前記第１の値を有する場合、前記パケットヘッダ内に含まれるタイプフィールドを識別するステップと、
前記ＲＡＰフラグが前記第１の値を有し、前記タイプフィールドが一つ又はそれ以上のシグナリングメッセージを示す場合、前記ＲＡＰ情報がメディアデータの伝送及び消費のための少なくとも一つのシグナリングメッセージを含むことを確認するステップと、を含むことを特徴とする、請求項１に記載の方法。

【請求項7】

前記ＲＡＰフラグが前記第１の値を有する場合、前記パケットヘッダ内に含まれるタイプフィールドを識別するステップと、
前記ＲＡＰフラグが前記第１の値を有し、前記タイプフィールドがＭＰＵのフラグメント又は一つの完全なＭＰＵを示す場合、前記ＲＡＰ情報が関連するフレームなしに復号化される少なくとも一つのＩフレーム(Intra-coded frame)を含むことを確認するステップと、をさらに含むことを特徴とする、請求項１に記載の方法。

【請求項8】

マルチメディアシステムにおけるメディアパケットを受信する受信エンティティ内の装置であって、
パケットヘッダ及びペイロードを含むメディアパケットを受信する送受信部と、ここで、前記パケットヘッダは、ランダムアクセスポイント（ＲＡＰ）フラグを含み、前記ペイロードは、ペイロードヘッダ及びペイロードデータを含み、
前記ＲＡＰフラグが、前記ペイロードがＲＡＰ情報を含むことを示す第１の値を有するか否かを識別し、前記ＲＡＰフラグが前記第１の値を有する場合、前記メディアパケット内に含まれた前記ペイロードをデコーディングし、前記ＲＡＰフラグが、前記メディアパケットがＲＡＰ情報を含まないことを示す第２の値を有する場合、前記メディアパケットを廃棄する制御部と、
を含み、
前記ＲＡＰ情報は、メディアデータの伝送及び消費(delivery and consumption)のための少なくとも一つのシグナリングメッセージを含むことを特徴とする装置。

【請求項9】

前記ＲＡＰ情報は、メディアデータアクセスの開始位置情報をさらに含むことを特徴とする、請求項８に記載の装置。

【請求項10】

前記ＲＡＰ情報は、関連するフレームなしに復号化される少なくとも一つのＩフレーム(Intra-coded frame)をさらに含むことを特徴とする、請求項８に記載の装置。

【請求項11】

前記ＲＡＰ情報は、ＩＳＯ基本メディアファイルフォーマット（ＩＳＯＢＭＦＦ）を用いるＭＰＵ（Media Processing Unit）のメタデータをさらに含むことを特徴とする、請求項８に記載の装置。

【請求項12】

前記制御部は、
前記ＲＡＰフラグが前記第１の値を有する場合、前記ペイロード内の前記ペイロードヘッダ内に含まれるフラグメントタイプフィールドを識別し、
前記ＲＡＰフラグが前記第１の値を有し、前記フラグメントタイプフィールドがＭＰＵのメタデータを示す場合、前記ＲＡＰ情報がＩＳＯＢＭＦＦを用いるＭＰＵのメタデータを含むことを確認するように構成されることを特徴とする、請求項８に記載の装置。

【請求項13】

前記制御部は、
前記ＲＡＰフラグが前記第１の値を有する場合、前記パケットヘッダ内に含まれるタイプフィールドを識別し、
前記ＲＡＰフラグが前記第１の値を有し、前記タイプフィールドが一つ又はそれ以上のシグナリングメッセージを示す場合、前記ＲＡＰ情報がメディアデータの伝送及び消費のための少なくとも一つのシグナリングメッセージを含むことを確認するように構成されることを特徴とする、請求項８に記載の装置。

【請求項14】

前記制御部は、
前記ＲＡＰフラグが前記第１の値を有する場合、前記パケットヘッダ内に含まれるタイプフィールドを識別し、
前記ＲＡＰフラグが前記第１の値を有し、前記タイプフィールドがＭＰＵのフラグメント又は一つの完全なＭＰＵを示す場合、前記ＲＡＰ情報が関連するフレームなしに復号化される少なくとも一つのＩフレーム(Intra-coded frame)を含むことを確認するように構成されることを特徴とする、請求項８に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、メディアデータを複数のメディアパケットにパケット化して伝送するマルチメディアシステムにおけるメディアパケットを受信する方法及び装置に関する。

【背景技術】

【0002】

現在のマルチメディアサービスでは、放送網と通信網を同時に接続する複合(Hybrid)ネットワークと、マルチメディアデータとアプリケーション、ファイルが共に提供される複合コンテンツの提供のためのＭＭＴ(MPEG Media Transport)技術が考えられている。

【0003】

図１は、マルチメディア通信システムにおけるＭＭＴデータモデルを説明するための図である。

【0004】

図１を参照すれば、ＭＭＴ技術では、符号化されたメディアデータと上記メディアデータに関連するメタデータ(metadata）の集合をパッケージ(package)１００として定義する。パッケージ１００は、少なくとも一つのＭＭＴアセット(asset)（１１０，１２０，１３０）、少なくとも一つのＡＤＣ(Asset Delivery Characteristics)(又は“送信特性(Transport Characteristic)”情報)（１１５，１２５）、少なくとも一つのプレゼンテーション情報(Presentation Information:ＰＩ)１４０を含む。パッケージ１００は、一編の映画のようなコンテンツとして理解される。

【0005】

上記ＭＭＴアセットは、ビデオ、オーディオ、テキスト、ファイルのようなマルチメディアプレゼンテーション(multimedia presentation）を生成するために用いられるマルチメディアデータを意味する。それぞれのＭＭＴアセット（１１０，１２０，１３０）は、少なくとも一つのＭＰＵ（Media Processing Unit）に分割される。図１に示すように、ＭＭＴアセット１ １１０は、複数のＭＰＵ（１１１，１１２，…，１１３）に分割されている。上記ＭＰＵは、ＭＭＴストリームが独立して処理される単位である。また、上記ＭＰＵは、独立して復号化されるメディアデータの単位である。一方、一つのＭＰＵは、複数のフラグメント(fragments）に分割され、この時、分割されたフラグメントは、ＭＰＵフラグメントユニット（ＭＦＵ）と呼ばれる。ＭＭＴ送信エンティティは、ＭＰＵ単位でメディアデータを分割して処理し、ＭＭＴ受信エンティティは、ＭＰＵ単位でメディアデータを受信して再生のための処理をする。上記ＡＤＣは、ＭＭＴアセット毎に該当ＭＭＴアセットの送信特性を提供可能な情報を含む。図１の例では、ＡＤＣ１１５はアセット１ １１０の送信特性を表し、ＡＤＣ１２５はアセット２ １２０及びアセット３ １３０の送信特性を表す。また、上記プレゼンテーション情報(Presentation Information:ＰＩ)１４０は、複数個のアセット（１１０，１２０，１３０）間の時間及び空間関係を説明する情報を含み、パッケージ内のＭＭＴアセットの伝送順序を規定する。

【0006】

上記したＭＭＴデータモデルが適用されたマルチメディアシステムにおける送信エンティティは、ＭＰＵ単位で構成されたメディアデータを複数のＭＭＴＰパケットにパケット化して伝送する。また、マルチメディアシステムにおける受信エンティティは、受信された複数のＭＭＴＰパケットをＭＰＵ単位でデパケット化して再構成されたメディアデータを再生できる。

【0007】

上記ＭＰＵは、複数のＭＭＴＰ(MMT Protocol)パケットにパケット化された後に伝送され、上記ＭＦＵは、少なくとも一つのＭＭＴＰパケットのＭＭＴＰペイロード(payload)を介して伝送される。また、上記ＭＭＴＰパケットは、ＭＭＴプロトコルを用いて伝送されるメディアデータのフォーマットされた単位を意味し、ＭＭＴＰペイロードを搬送する。上記ＭＭＴＰペイロードは、ＭＭＴプロトコル又はインターネットアプリケーション伝送階層プロトコル(例えば、ＲＴＰ(Real Time Protocol)）を用いてパッケージ及び/又はシグナリングメッセージを伝送するためのメディアデータのフォーマットされた単位を意味する。また、上記ＭＭＴＰペイロードは、ＭＰＵメタデータ(metadata)、フラグメントメタデータ(fragment metadata)、ＭＦＵ、又はシグナリング情報を含みうる。上記ＭＰＵメタデータは、そのＭＰＵを識別するための情報、メディアデータの復号化のための情報などを含む。また、上記シグナリング情報はパッケージの伝送及び消費(delivery and consumption)のための各種シグナリングメッセージを含む。上記シグナリングメッセージを通じて、パッケージの構造、プロトコル構成、ＭＭＴＰペイロードの構造などを受信エンティティに提供できる。

【0008】

上記の通り、ＭＭＴベースのマルチメディアシステムにおけるメディアデータは、複数のＭＭＴＰパケットに分割されて伝送され(すなわち、パケット化されたメディアストリームとして伝送されて)、上記複数のＭＭＴＰパケットを介して伝送される情報のうち、例えば、上記ＭＰＵメタデータと上記シグナリング情報は、受信エンティティでメディアデータの復号化又は再生のために必須情報として考慮される。したがって、上記メディアストリームの遅延のない再生のためには、該当メディアデータに関連する上記ＭＰＵメタデータと上記シグナリング情報などの迅速な受信が必要である。

【発明の概要】

【発明が解決しようとする課題】

【0009】

本発明は、マルチメディアシステムにおける特定メディアパケットを効率的に受信する方法及び装置を提供する。

【0010】

また、本発明は、マルチメディアシステムにおける特定メディアデータ又は特定情報を含むメディアパケットを優先的に検出して受信する方法及び装置を提供する。

【課題を解決するための手段】

【0011】

本発明の実施形態によると、マルチメディアシステムにおけるメディアパケットの受信方法は、受信したメディアパケットに特定メディアデータと特定情報のうち少なくとも一つを受信するためのアクセス情報が含まれているか判定するステップと、上記受信したメディアパケットに上記アクセス情報が含まれている場合、上記アクセス情報を用いて、上記特定メディアデータと上記特定情報のうち少なくとも一つを優先的に受信するステップと、を含む。

【0012】

また、本発明の実施形態によると、マルチメディアシステムでメディアパケットを受信する受信エンティティは、無線ネットワークを介してデータを送受信するための送受信部と、受信したデータを復号化する復号部と、上記送受信部を介して受信したメディアパケットに特定メディアデータと特定情報のうち少なくとも一つを受信するためのアクセス情報が含まれているかを判定し、上記受信したメディアパケットに上記アクセス情報が含まれている場合、上記アクセス情報を用いて、上記特定メディアデータと上記特定情報のうち少なくとも一つを優先的に受信する動作を制御する制御部とを含む。

【図面の簡単な説明】

【0013】

【図1】マルチメディア通信システムにおけるＭＭＴデータモデルを説明するための図である。

【図2】本発明の実施形態に係る送信エンティティと受信エンティティがＭＭＴＰパケットを送受信するマルチメディアシステムの構成を表す図である。

【図3】本発明の実施形態に係るマルチメディアシステムでＭＰＵメタデータを含むＩＳＯ基本メディアファイルフォーマットベースのＭＰＵ構造を表す図である。

【図4】本発明の実施形態に係るマルチメディアシステムでＭＰＵが複数のＭＭＴＰパケットに分割されて伝送される例を表す図である。

【図5】本発明の実施形態に係るマルチメディアシステムにおけるＲＡＰ情報を含むか否かを指示できるＭＭＴＰパケットの構造を表す図である。

【図6】本発明の実施形態に係るＭＰＵメタデータを含むＭＭＴＰパケットを受信する受信エンティティの動作を表すフローチャートである。

【図7】本発明の実施形態に係るＭＭＴシグナリング情報を含むＭＭＴＰパケットを受信する受信エンティティの動作を表すフローチャートである。

【図8】本発明の実施形態に係る特定メディアデータを含むＭＭＴＰパケットを受信する受信エンティティの動作を表すフローチャートである。

【図9】本発明の実施形態に係るマルチメディアシステムにおける受信エンティティの構成を表す図である。

【発明を実施するための形態】

【0014】

本発明の実施形態の以下の説明において、本発明と関連する周知の機能又は構成要素の詳細な説明が不必要に本発明の要旨を不明確にする場合には、その詳細な説明を省略する。以下に説明する本発明の実施形態は、説明の便宜のために分離されているが、相互衝突しない範囲内で少なくとも二以上の実施形態を結合して実行できる。

【0015】

また、本発明の実施形態は多様に変更可能であり、本発明は図を参照しながら詳細に説明される以下の多様な実施形態を含んでいてもよい。しかし、本発明の思想に係る実施形態は、特定の実施形態に限定されるものとして解釈されず、本発明の思想及び技術範囲に含まれる全ての変更、均等物乃至代替物を含む。また、ここで使用される用語は、特定の実施形態を説明するためのものであり、本発明を限定するものではない。 英文明細書に記載の「ａ」、「ａｎ」、及び「ｔｈｅ」、すなわち単数形は、以下の説明中において特記して明示されない限り、複数形を含む。例えば、「ａｎ ｏｂｊｅｃｔ」は、一つ以上のオブジェクトを含む。また、「含む」又は「有する」などの用語は、明細書上に記載された特徴、数字、段階、動作、要素、特性、及び/又は構成要素が存在することを指定しようとするものであって、一つ又はそれ以上の他の特徴、数字、段階、動作、要素、特性、及び/又は構成要素及び/又はこれらを組み合わせの存在又は付加可能性を予め排除しないと理解しなければならない。

【0016】

本発明の実施形態によると、マルチメディアシステムは、ＭＭＴプロトコルをベースとするマルチメディアシステムを例にして説明しているが、本発明の実施形態はＭＭＴベースのマルチメディアシステムだけでなく、同一又は類似のサービスを提供する各種マルチメディアシステムに適用可能である。

【0017】

上記ＭＭＴプロトコルは、ＭＭＴパッケージをパケット化して伝送するためのアプリケーション階層伝送プロトコルであり、パッケージを効率的、かつ、信頼性をもって伝送するために設計されたものである。ＭＭＴプロトコルは、メディア多重化とネットワークジッター(jitter)計算のような改善した特徴を有する。この特徴は、多様なタイプで符号化されたメディアデータで構成されるコンテンツを効率的に伝送できる。上記ＭＭＴプロトコルは、現存するネットワークプロトコル、例えば、ＵＤＰ又はＩＰの上位階層で動作可能であり、多様なアプリケーションをサポートできる。

【0018】

図２は、本発明の実施形態によって送信エンティティと受信エンティティがＭＭＴＰパケットを送受信するマルチメディアシステムの構成を示す図である。

【0019】

図２を参照すれば、ＭＭＴ送信エンティティ(以下「送信エンティティ」と呼ぶ。)２１０は、メディアデータを含むパッケージをＭＭＴＰパケットフロー(flow)としてＭＭＴ受信エンティティ(以下「受信エンティティ」と呼ぶ。)２２０に送信する。上記パッケージは、例えば、映画一編 、ドラマ一編などのコンテンツと理解される。送信エンティティ２１０は、メディアデータを送信する任意のエンティティであり、一例で、ＭＭＴ放送サーバであってもよい。受信エンティティ２２０は、メディアデータを受信する任意のエンティティであり、一例として、ＭＭＴクライアントである無線端末又は移動端末(以下「端末」と呼ぶ。)であってもよい。また、送信エンティティ２１０がＭＭＴ放送サーバである場合、ＭＭＴ放送サーバから伝送されるメディアデータは、端末が接続する無線通信システムの基地局又はＡＰ(Access Point）を経由して端末に伝送されてもよい。

【0020】

図２で、送信エンティティ２１０は、パッケージプロバイダ２０１によって提供されるパッケージのプレゼンテーション情報（ＰＩ）に基づいて、アセットプロバイダ２０３，２０５からコンテンツを収集できる。ここで、パッケージプロバイダ２０１及びアセットプロバイダ２０３，２０５は、個別のエンティティで構成されるか、又は結合されたエンティティとして構成される。送信エンティティ２１０は、アセット、制御情報、プレゼンテーション情報などを含むパッケージをＭＭＴプロトコル（ＭＭＴＰ）を用いて送信できる(２３０)。送信エンティティ２１０と受信エンティティ２２０は、背景技術で記述したシグナリング情報をＭＭＴＰを用いて送受信できる（２４０）。

【0021】

送信エンティティ２１０は、メディアデータを複数のＭＭＴＰパケットに分割して伝送し、上記複数のＭＭＴＰパケットのうち一部のＭＭＴＰパケットを介して上記ＭＰＵメタデータと上記シグナリング情報が伝送される。上記ＭＭＴＰパケットは、メディアデータを伝送するのでメディアパケットとも称される。

【0022】

図３は、本発明の実施形態に係るマルチメディアシステムにおけるＭＰＵメタデータを含むＩＳＯ基本メディアファイルフォーマット(International Standardization Organization Base Media File Format:ＩＳＯＢＭＦＦ)ベースのＭＰＵ構造を示す図である。

【0023】

ＭＭＴベースのマルチメディアシステム(以下、ＭＭＴシステム)では、ストリーミングサービスのように復号化のための時間情報を有するタイムドデータ（timed data）と、一般ファイル伝送サービスのように上記復号化のための時間情報を有しないノンタイムドデータ（non-timed data）の両方をサポートでき、図３は、便宜上タイムドデータのＭＰＵ構造を表す。ノンタイムドデータのＭＰＵ構造(図示せず)も上記ＭＰＵメタデータを含む。

【0024】

ＭＭＴシステムにおいて、ＭＰＵは、ＩＳＯＢＭＦＦに従ってカプセル化(encapsulation)される。図３を参照すれば、上記ＭＰＵがカプセル化されるＩＳＯベースのメディアファイル３００は、上記ＭＰＵメタデータを含むＭＰＵメタデータ３１０と、ＭＰＵメディアデータを少なくとも一つのＭＦＵ(例えば、３２１、３２２、…、３２Ｎ）に分割して含ませたmdatボックス３２０を含む。それぞれのＭＦＵ(３２1、３２２、…、３２Ｎ）は、ＭＦＵペイロード(payload)とＭＦＵヘッダ（ｈ）を含む。上記ＭＰＵメタデータは、ftypボックス３１１、sidxボックス３１２、mmpuボックス３１３、moovボックス３１４、moofボックス３１７のうち少なくとも一つを含む。ftypボックス３１１は、メディアデータのタイプ情報を含み、sidxボックス３１２は、ＭＰＵを構成するフラグメントのインデックス情報を含む。mmpuボックス３１３は、現在のＭＰＵが属するアセットの識別子及び現在のＭＰＵの他の情報を含む。mmpuボックス３１３は、現在のＭＰＵが全てのＭＦＵを含んでいるか否かを指示する情報(「is complete」)を含む。

【0025】

また、moovボックス３１４は、メディアデータの復号化及びプレゼンテーションのための全てのコーデック設定情報を含む。moovボックス３１４は、少なくとも一つのメディアトラック３１６を含み、またＭＦＵのためのＭＭＴヒントトラック３１５を含むことができる。ＭＭＴヒントトラック３１５は、ＭＰＵを含んでいるメディアファイル３００をＭＭＴプロトコルのような伝送プロトコルを用いてパケット化されたメディアストリームに変換するために必要な情報を含む。すなわち、ＭＭＴヒントトラック３１５は、一つのＭＰＵを構成する複数個のＭＦＵを生成するために必要な情報を含む。

【0026】

上記ＭＰＵメタデータは、ＭＰＵに含まれたメディアデータの復号化又は再生のために必須的な情報として考慮され、受信エンティティは、ＭＰＵが分割及びパケット化されて伝送された複数のＭＭＴＰパケットのうち上記ＭＰＵメタデータを含むＭＭＴＰパケットを優先的に検出して受信する必要がある。

【0027】

図４は、本発明の実施形態に係るマルチメディアシステムにおけるＭＰＵが複数のＭＭＴＰパケットに分割されて伝送される例を示す図である。

【0028】

図４の（ａ）は、ＭＰＵメタデータ４０１と複数のＭＦＵ(４０３、４０５、…）を含むＭＰＵであり、図４の（ｂ）は、ＭＰＵメタデータ４０１と複数のＭＦＵ(４０３、４０５、…)が複数のＭＭＴＰパケットにパケット化されて伝送される例を示す図である。ＭＰＵメタデータ４０１は、ＭＭＴＰパケット４１１を介して伝送され、一つのＭＦＵは、一つ又は複数のＭＭＴＰパケットを介して伝送できる。図４において、ＭＦＵ４０３は、３個のＭＭＴＰパケット(４１３ａ、４１３ｂ、４１３ｃ）に分割されて伝送され、ＭＦＵ４０５は、一つのＭＭＴＰパケット４１５により伝送される例を示す図である。ＭＰＵメタデータ４０１も一つ又は複数のＭＭＴＰパケットを介して伝送されてもよい。

【0029】

また、本発明の実施形態で、ＭＭＴＰパケット４１１が、そのペイロードに優先的に受信すべきのデータ(又は、情報)が含んでいるか、又は、そのペイロードに優先的に受信すべきのデータ(又は、情報）のアクセスのための位置情報が含まれる場合には、ＭＭＴＰパケット４１１はランダムアクセスポイント(Random Access Point:ＲＡＰ)情報を含んでいてもよい。すなわち、上記ＲＡＰ情報は、該当ＭＭＴＰパケットのペイロードにおいて、受信エンティティがメディアデータアクセスを開始すべき優先的なデータ(又は、情報）のメディアストリームにおける位置を指示する。上記優先的なデータ(又は、情報）は、上記したＭＰＵメタデータ、シグナリング情報、又はイメージフレームのＩフレーム(Intra-coded frame)であってもよい。本発明の実施形態において、受信エンティティは、ＭＭＴＰパケットのうちＲＡＰ情報が含まれたＭＭＴＰパケットを検出した場合、そのＭＭＴＰパケットを優先的にバッファし、ＭＰＵ単位でデータ受信を完了し、受信したデータに対して信号処理を実行する。

【0030】

図５は、本発明の実施形態によるマルチメディアシステムでＲＡＰ情報を含むか否かを指示できるＭＭＴＰパケットの構造を示す図である。

【0031】

図５を参照すれば、「Ｖ」フィールドは、ＭＭＴＰプロトコルのバージョンを表し、「Ｃ」フィールドはパケットカウンタ(packet＿counter)フィールドの存在可否を表す。「ＦＥＣ」フィールドはＭＭＴＰパケットのエラー防止のために使用されたＦＥＣ(Forward Error Correction)方式のタイプを表す。「ｒ」フィールドと「ＲＥＳ」フィールドは、今後の使用のために予約された(reserved)フィールドであり、「Ｘ」フィールドは、ヘッダ拡張(header＿extension)フィールドの存在可否を表す。

【0032】

また、参照番号５０１の「Ｒ」フィールドは、ＭＭＴＰパケットのペイロードデータ(payload data)(以下、ペイロード)が上記ＲＡＰ情報を含むか否かを指示するＲＡＰフラグ情報である。例えば、上記「Ｒ」フィールドが「１」であれば、ＭＭＴＰパケットのペイロードは、上記ＲＡＰ情報を含み、上記「Ｒ」フィールドが「０」であれば、ＭＭＴＰパケットのペイロードは上記ＲＡＰ情報を含まない。上記ＲＡＰ情報は、ＭＰＵメタデータ、シグナリング情報、又はイメージフレームのうちＩフレームのデータアクセスのための開始位置を指示する。これは、タイムメディアデータとノンタイムメディアデータの全てに適用されてもよい。

【0033】

上記イメージフレームの種類は、Ｉフレーム、Ｐフレーム、Ｂフレームを含む。上記Ｉフレームは、データストリームのどの位置にも存在でき、データのランダムアクセスのために使用され、他のイメージフレームを参照することなく符号化/復号化できる。Ｐフレームは、符号化/復号化される際に、以前のＩフレーム情報と以前のＰフレームの情報を使用する。上記Ｐフレームは、以前の画面と現在の画面間の差が少ないことを用いてその差を符号化したフレームである。Ｂフレーム(Bidirectional-coded frame）は、符号化/復号化される際に、以前及び以後のＩフレームとＰフレームの全てを使用する。上記Ｂフレームは、以前のＩフレーム又はＰフレームとそのＢフレーム以後のＩフレーム又はＰフレームとの差を有する。また上記Ｉフレームから開始される連続するイメージフレームの集合をＧＯＰ(Group Of Picture)と呼び、動画などを再生する際に上記Ｉフレームが受信された後にのみその再生のための復号化を開始できる。

【0034】

したがって、本実施形態において、受信エンティティがメディアストリームを受信して動画などを再生する場合、受信したＭＭＴＰパケットの「Ｒ」フィールドからＲＡＰ情報が含まれているか否かが判定され、ＭＭＴＰパケットのペイロードにＲＡＰ情報が含まれる場合、上記ＲＡＰ情報を用いて当該ＭＭＴＰパケットで上記Ｉフレームを優先的に受信できる。他の実施形態で、複数のＩフレームに対する位置情報をＭＭＴＰパケットに含めて搬送し、その位置情報を含むＭＭＴＰパケット中の上記ＲＡＰ情報を通してその位置情報を受信してもよい。この場合、受信エンティティは、上記の位置情報を用いて複数のＩフレームを予め受信することで、動画などの再生、探索又はチャネル切り替えなどを遅延無くより高速に実行できる。

【0035】

このように、ＲＡＰ情報を用いてＩフレームを優先的に受信する場合、例えば放送受信環境でチャネルの切り替えの際に、再生遅延を最小化できる。又は倍速再生、巻き戻し、探索などの動作を遅延なく高速に実行できる。

【0036】

上記のように、本実施形態において、ＲＡＰ情報は、メディアデータ又は情報の優先的な受信のための特定メディアデータ(例えば、Ｉフレーム)（又は、特定情報(例えば、ＭＰＵメタデータ又はシグナリング情報））へのアクセス位置を指示するために利用できる。また、上記特定メディアデータ(又は、特定情報）は、上記ＲＡＰ情報が含まれた少なくとも一つのＭＭＴＰパケットに含まれてもよいし、または、上記ＲＡＰ情報が指示する位置の少なくとも一つのＭＭＴＰパケットに含まれてもよい。

【0037】

また、図５の説明に戻り、「type」フィールド５０３は、ＭＭＴＰパケットのペイロードデータのタイプを指示するフィールドである。例えば「type」フィールドが「０ｘ００」又は「０ｘ０１」の値を有する場合、ペイロードデータのタイプがメディアデータであることを意味する。上記「０ｘ００」は、そのペイロードデータがＭＰＵのフラグメント(fragment）を含むことを表し、上記「０ｘ０１」は、そのペイロードデータが一つのＭＰＵの完全な(complete)データを含むことを表す。したがって、「Ｒ」フィールドが「１」の値を有し、かつ、上記「type」フィールドが「０ｘ００」又は「０ｘ０１」の値を有する場合、そのペイロードデータは、例えば、Ｉフレームを含むものと判定できる。また、上記「type」フィールドが「０ｘ０２」の値を有すると、そのペイロードデータが上記特定情報のうち上記シグナリング情報を含むことを表す。また、ＭＰＵメタデータは、上記「type」フィールドが「０ｘ００」であるＭＰＵモードである場合、ＭＰＵメタデータが、「０」値のＭＰＵフラグメントタイプを有することを意味する。

【0038】

ＭＭＴシステムにおいて、上記シグナリング情報について言えば、上記シグナリング情報は、メディアデータの伝送と消費を管理するための制御情報として、各種シグナリングメッセージと理解される。上記メディアデータの消費を管理するシグナリングメッセージは、パッケージの構造をシグナリングするのに利用され、上記メディアデータの伝送を管理するためのシグナリングメッセージは、ペイロードフォーマットとプロトコル構成をシグナリングするのに利用されてもよい。上記シグナリングメッセージは、シグナリング情報の効率的な送受信のために、複数のテーブルの形態にて構成されてもよい。

【0039】

メディアデータの消費を管理するシグナリングメッセージの一例は下記の＜表１＞のようになり、メディアデータの伝送を管理するためのシグナリングメッセージは、例えば、受信器バッファーモデル動作を構成するための受信器バッファーモデルメッセージとできる。

【0040】

【表1】

したがって、「Ｒ」フィールドが「１」の値を有し、かつ、「type」フィールドが「０ｘ０２」の値を有すると、そのペイロードデータが特定情報のうち上記シグナリング情報(又は、シグナリングメッセージ)を含むと判定できる。

【0041】

また、図５において、「packet＿id」フィールドは一つのアセット(asset）を他のアセットと区別するためのものであり、「timestamp」フィールドはＭＭＴＰパケットの送信時間を表す。「packet＿sequence＿number」フィールドは、同一の「packet＿id」を有するＭＭＴＰパケットを区別するためのものであり、「packet＿counter」フィールドは、ＭＭＴＰパケットが伝送された時、その個数をカウントするためのものである。また「header#extension」フィールドは、ユーザ定義情報を含み、「payload data」フィールドは、ＭＭＴＰパケットのペイロードを含む。上記ペイロードには、上述したように、メディアデータ、特定情報(例えば、ＭＰＵメタデータ又はシグナリング情報)などを含めることができる。「source＿FEC＿payload＿ID」は、アプリケーション階層順方向エラー訂正(Application Level＿Forward Error Correction)などのようなＦＥＣタイプを表す。

【0042】

また、受信エンティティは、ＭＭＴＰパケットのペイロードにＭＰＵメタデータが含まれているか否かを、上記「payload data」フィールドに含まれたペイロードヘッダを介して確認できる。すなわち、ＭＭＴＰパケットを介してメディアデータだけでなくＭＰＵメタデータを伝送できる。ＭＭＴＰパケットのペイロードは、上記ペイロードヘッダとペイロードデータを含み、上記ペイロードヘッダは、ファイルタイプ(File Type:ＦＴ)情報を含む。上記ペイロードに含まれるペイロードデータが上記ＭＰＵメタデータである場合、上記ＦＴ情報は、例えば、「０」の値を有する。

【0043】

したがって、図５で「Ｒ」フィールドが「１」の値を有し、かつ、上記「payload data」フィールドのペイロードヘッダに含まれたＦＴ情報が「０」の値を有すると、そのペイロードデータが上記特定情報のうち上記ＭＰＵメタデータを含むと判定できる。図５のＭＭＴＰパケット構造において、上記「payload data」フィールドを除外した残りのフィールドはＭＭＴＰパケットのヘッダ情報を構成する。

【0044】

以下、本発明の実施形態に係るＭＭＴベースのマルチメディアシステムにおいて、ＭＰＵを分割しパケット化した後伝送された複数のＭＭＴＰパケットのうち、特定メディアデータ(例えば、Ｉフレーム)又は特定情報(例えば、ＭＰＵメタデータ又はシグナリング情報)を含む少なくとも一つのＭＭＴＰパケットを優先的に検出して受信する受信エンティティの動作を説明する。

【0045】

図６は、本発明の実施形態によってＭＰＵメタデータを含むＭＭＴＰパケットを受信する受信エンティティの動作を表すフローチャートである。上記ＭＰＵメタデータは、図３で説明したftypボックス３１１、sidxボックス３１２、mmpuボックス３１３、moovボックス３１４、moofボックス３１７のうち少なくとも一つを含む。

【0046】

図６を参照すると、ステップ６０１でＭＭＴＰパケットを受信すると、ステップ６０３で、受信したＭＭＴＰパケットのヘッダ情報から図５の「Ｒ」フィールド(すなわち、ＲＡＰフラグ情報)を特定し、受信したＭＭＴＰパケットにＲＡＰ情報が含まれているか否かを判定する。上記ステップ６０３の判定の結果、ＭＭＴＰパケットにＲＡＰ情報が含まれない場合、ステップ６０５で、受信エンティティは、受信したＭＭＴＰパケットを廃棄(discard)する。一方、ステップ６０５で、ＲＡＰ情報を含まないＭＭＴＰパケットは廃棄されると述べたが、受信エンティティは、ＭＰＵメタデータなどの受信を完了した後に、ＲＡＰ情報が含まれないＭＭＴＰパケットを受信する一般的な動作を実行してもよい。また、他の実施形態において、受信エンティティが制限されたメモリーの使用又は低電力プロセスを実行しているときに、ステップ６０５でＲＡＰ情報を含まない全てのＭＭＴＰパケットを廃棄してもよい。

【0047】

一方、上記ステップ６０３の判定の結果、ＭＭＴＰパケットにＲＡＰ情報が含まれる場合、ステップ６０７で、受信エンティティは、ＭＭＴＰパケットのペイロードに含まれるデータタイプを特定する。すなわち、受信エンティティは、ＭＭＴＰパケットのペイロードヘッダに含まれるファイルタイプ（ＦＴ）情報を特定して、データタイプを特定する。ステップ６０９でＦＴ情報がＭＰＵメタデータを指示する場合(例えば、上記ＦＴ情報が「０」の値を有する場合)、受信エンティティは、ステップ６１１で受信したＭＭＴＰパケットからバッファリングを開始し、ステップ６１３でＭＰＵ単位データの受信を完了する。その後、ステップ６1５で、受信エンティティは、完全に受信したＭＰＵメタデータを用いて信号(又は、データ)処理を実行する。

【0048】

図７は、本発明の実施形態に係るＭＭＴシグナリング情報を含むＭＭＴＰパケットを受信する受信エンティティの動作を表すフローチャートである。ＭＭＴシグナリング情報は、ＭＭＴシステムにおいて、メディアデータの伝送、消費を管理するためのシグナリングメッセージのうち少なくとも一つを含む。

【0049】

図７を参照すれば、ステップ７０１でＭＭＴＰパケットを受信すると、受信エンティティは、ステップ７０３で、受信したＭＭＴＰパケットのヘッダ情報から図５の「Ｒ」フィールド(すなわち、ＲＡＰフラグ情報)を特定して、受信したＭＭＴＰパケットにＲＡＰ情報が含まれているかを判定する。ステップ７０３の判定の結果、ＭＭＴＰパケットにＲＡＰ情報が含まれない場合、受信エンティティは、ステップ７０５で受信したＭＭＴＰパケットを廃棄(discard)する。一方、ステップ７０５でＲＡＰ情報を含まないＭＭＴＰパケットは廃棄されると述べたが、受信エンティティは、シグナリング情報などの受信を完了した後に、ＲＡＰ情報が含まれないＭＭＴＰパケットの一般的な受信動作を実行してもよい。また、他の実施形態で、受信エンティティが制限されたメモリーの使用又は低電力プロセスを実行しているときに、ステップ７０５でＲＡＰ情報を含まない全てのＭＭＴＰパケットを廃棄してもよい。

【0050】

一方、上記ステップ７０３の判定の結果、ＭＭＴＰパケットにＲＡＰ情報が含まれる場合、ステップ７０７で、受信エンティティは、ＭＭＴＰパケットのヘッダ情報に含まれるペイロードデータのタイプ情報(図５の「type」フィールド５０３)を特定する。ステップ７０９で、受信エンティティは、上記ペイロードデータのタイプ情報が上記シグナリング情報を指示する場合(例えば、上記「type」フィールドが「０ｘ０２」の値を有する場合)、ステップ７１１で当該受信したＭＭＴＰパケットからバッファリングを開始し、ステップ７１３で、ＭＰＵ単位データの受信を完了する。その後、ステップ７１５で、受信エンティティは、完全に受信したシグナリング情報を用いて信号(又は、データ)処理を実行する。

【0051】

図８は、本発明の実施形態に係る特定メディアデータを含むＭＭＴＰパケットを受信する受信エンティティの動作を表すフローチャートである。上記特定メディアデータは他のイメージフレームを参照することなく符号化/復号化されるＩフレームを仮定する。

【0052】

図８を参照すれば、ステップ８０１でＭＭＴＰパケットを受信すると、受信エンティティは、ステップ８０３で、受信したＭＭＴＰパケットのヘッダ情報から図５の「Ｒ」フィールド(すなわちＲＡＰフラグ情報)を特定して、受信したＭＭＴＰパケットにＲＡＰ情報が含まれているかを判定する。上記ステップ８０３の判定の結果、ＭＭＴＰパケットにＲＡＰ情報が含まれない場合、受信エンティティは、受信したＭＭＴＰパケットを廃棄(discard)する。一方、上記ステップ８０５でＲＡＰ情報を含まないＭＭＴＰパケットは廃棄されると述べたが、受信エンティティは、Ｉフレームなどの受信を完了した後に、ＲＡＰ情報が含まれないＭＭＴＰパケットの一般的な受信動作を実行してもよい。また、他の実施形態で、受信エンティティが制限されたメモリーの使用又は低電力プロセスを実行しているときに、上記ステップ８０５でＲＡＰ情報を含まない全てのＭＭＴＰパケットを廃棄してもよい。

【0053】

一方、上記ステップ８０３の判定の結果、ＭＭＴＰパケットにＲＡＰ情報が含まれる場合、ステップ８０７で、受信エンティティは、ＭＭＴＰパケットのヘッダ情報に含まれるペイロードデータのタイプ情報(図５の「type」フィールド５０３)を特定する。ステップ８０９で、受信エンティティは、ペイロードデータのタイプ情報がシグナリング情報を指示する場合(例えば、「type」フィールドが「０ｘ００」又は「０ｘ０１」の値を有する場合)、ステップ８１１で当該受信したＭＭＴＰパケットからバッファリングを開始し、ステップ８１３でＭＰＵ単位データの受信を完了する。その後、ステップ８１５で、受信エンティティは、完全に受信したＩフレームを用いてイメージフレームのデコーディングを実行する。他の実施形態において、ＭＭＴＰパケットのペイロードに複数のＩフレームに対する位置情報を含めて搬送し、ＲＡＰ情報を介して位置情報を受信して複数のＩフレームを受信してもよい。

【0054】

上記のように、ＲＡＰ情報を用いてＩフレームを予め受信する場合、放送チャネル切り替えが頻繁に行われる放送サービスにおいて、チャネル切り替えによる再生遅延を大幅に減少できる。

【0055】

図９は、本発明の実施形態に係るマルチメディアシステムにおける受信エンティティの構成を示す図である。

【0056】

図９を参照すると、受信エンティティは、無線ネットワークを介してデータを送受信する送受信部９１０、受信されたデータを復号化する復号部９３０、また、図２乃至図８で説明した方式によって分割及びパケット化後に送信エンティティから伝送された複数のＭＭＴＰパケットのうち、特定メディアデータ(例えば、Ｉフレーム)又は特定情報(例えば、ＭＰＵメタデータ又はシグナリング情報)を含む少なくとも一つのＭＭＴＰパケットを優先的に検出して受信する動作を制御する制御部９５０を含む。本実施形態で、制御部９５０は、送受信部９１０を介して受信したメディアパケットに特定メディアデータと特定情報のうち少なくとも一つを受信するためのアクセス情報が含まれているかを判定し、受信したメディアパケットにアクセス情報が含まれている場合、アクセス情報を用いて、特定メディアデータと特定情報のうち少なくとも一つを優先的に受信する動作を制御するように実現されてもよい。

【0057】

上記した図６乃至図９の実施形態は、個別的な動作で記述したが、図６乃至図９の実施形態をのうち二以上が結合されて実施されてもよい。

【0058】

上記した本発明の実施形態は、また、コンピュータ読み取り可能な記録媒体(computer readable recording medium)でコンピュータ読み取り可能なコード(computer readable code)として実現できる。コンピュータで読まれる記録媒体は、コンピュータシステムにより読まれるデータを保存できる任意のデータ保存デバイスである。上記コンピュータで読まれる記録媒体は、例えばＲＯＭ(Read-Only Memory)と、ＲＡＭ(Random Access Memory)と、ＣＤ−ＲＯＭと、磁気テープ(magnetic tape)と、フロッピーディスク(floppy disk)（登録商標）と、光データ保存デバイス、及びキャリアウェーブ(carrier wave)(例えば、インターネットを介するデータ送信）を含むことができる。コンピュータで読み取れる記録媒体は、またネットワーク接続されたコンピュータシステムを介して配布され、したがってコンピュータで読み取れるコードは分散方式で保存及び実行される。また、本発明を達成するための機能的プログラム、コード、及びコードセグメント(segment)は、本発明が適用される分野で熟練されたプログラマーにより容易に解析できる。

【0059】

また、本発明の一実施形態による装置及び方法は、ハードウェア、ソフトウェア又はハードウェア及びソフトウェアの組合の形態で実現可能であると理解される。このような任意のソフトウェアは、例えば、削除可能又は再記録可能の可否にかかわらず、ＲＯＭなどの保存装置のような揮発性又は非揮発性保存装置、又は例えば、ＲＡＭ、メモリーチップ、装置又は集積回路のようなメモリー、又は例えばＣＤ、ＤＶＤ、磁気ディスク又は磁気テープのような光学又は磁気的に記録可能あると共に機械(例えば、コンピュータ）で読み取り可能な保存媒体に保存されてもよい。本発明の一実施形態による方法は、制御部及びメモリーを含むコンピュータ又は携帯端末により実現される上記メモリーは、本発明の実施形態を実現する命令を含むプログラム又はプログラムを保存するのに適合した機械で読み取り可能な保存媒体の一例であることを分かる。

【0060】

したがって、本発明は、本明細書の任意の請求項に記載された装置又は方法を実現するためのコードを含むプログラム及びこのようなプログラムを保存する機械(コンピュータなど）で読み取り可能な保存媒体を含む。また、このようなプログラムは、有線又は無線接続を介して伝えられる通信信号のような任意の媒体を介して電子的に移送され、本発明はこれの均等物を含む。

【0061】

また、本発明の一実施形態による装置は、有線又は無線で接続するプログラム提供装置から上記プログラムを受信して保存できる。上記プログラム提供装置は、上記プログラム処理装置が既設定されたコンテンツ保護方法を実行させる指示を含むプログラム、コンテンツ保護方法に必要な情報などを保存するためのメモリーと、上記グラフィック処理装置との有線又は無線通信を実行するための通信部と、上記グラフィック処理装置の要請又は自動で該当プログラムを上記送受信装置に伝送する制御部を含むことができる。

【0062】

一方、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】