本発明の詳細な説明に先立って、本明細書の全般にわたって使用される特定の単語及び語句の定義を説明することが好ましい。「接続(結合)する(couple)」という語句とその派生語は、2個以上の構成要素の間で、相互に物理的な接触状態にあるか否か、それら間の任意の直接的又は間接的通信を意味する。「送信する(transmit)」、「受信する(receive)」、及び「通信する(communicate)」という用語だけでなく、その派生語は、直接及び間接的な通信の両方ともを含む。「含む(include)」及び「備える(comprise)」という語句だけではなく、その派生語(derivatives thereof)は、限定ではなく、含みを意味する。「又は(or)」という用語は、「及び/又は(and/or)」の意味を包括する。「関連した(associated with)」及び「それと関連した(associated therewith)」という語句だけではなく、その派生語句は、「含む(include)」、「含まれる(be included within)」、「相互接続する(interconnect with)」、「包含する(contain)」、「包含される(be contained within)」、「接続する(connect to or with)」、「結合する(couple to or with)」、「疎通する(be communicable with)」、「協力する(cooperate with)」、「相互配置する(interleave)」、「並置する(juxtapose)」、「近接する(be proximate to)」、「接する(be bound to or with)」、「有する(have)」、及び「特性を有する(have a property of)」などを意味する。「制御部(controller)」は、少なくとも1つの動作を制御する装置、システム又はその部分を意味するもので、ハードウェア、ファームウェア、ソフトウェア、又は、それらのうちの2つ以上の組合せで実現できる。ある特定の制御器に関連した機能性は、ローカルでも遠隔でも、集中するか又は分散できることに留意しなければならない。「少なくとも一つの(at least one of)」という語句は、項目のリストとともに使用される時に、リストされた項目のうち一つ以上の異なる組み合せが使用され、そのリスト内の一つの項目のみが必要とされることができることを意味する。例えば、A、B、及びCのうち少なくとも一つは、A、B、C、A及びB、A及びC、B及びC、そしてAとBとCのような組み合せのうちいずれか一つを含む。
さらに、以下に記述される様々な機能は、1つ以上のコンピュータプログラムにより実現されるか又はサポートされ、そのプログラムの各々は、コンピュータ読み取り可能なプログラムコードで構成され、コンピュータ読み取り可能な媒体で実施される。「アプリケーション」及び「プログラム」という用語は、一つ以上のコンピュータプログラム、ソフトウェアコンポーネント、命令語セット、手順、関数、オブジェクト、クラス、インスタンス、関連データ、又は適したコンピュータ読み取り可能なプログラムコードの実現に適合したそれらの一部を称する。「コンピュータ読み取り可能なプログラムコード」という語句は、ソースコード、オブジェクトコード、及び実行コードを含むすべてのタイプのコンピュータコードを含む。「コンピュータ読み取り可能な媒体」という語句は、ROM(Read Only Memory)、RAM(Random Access Memory)、ハードディスクドライブ、CD(Compact Disc)、DVD(Digital Video Disc)、又は任意の他のタイプのメモリのように、コンピュータによりアクセス可能なすべてのタイプの媒体を含む。「非一時的(non-transitory)」なコンピュータ読み取り可能な媒体は、一時的な電気又は他の信号を伝送する有線、無線、光学、又は他の通信リンクを除外する。非一時的なコンピュータ読み取り可能な媒体は、データを永久的に格納できる媒体、及び再記録可能な光学ディスクや削除可能なメモリ装置のようにデータが格納され、後でオーバーライティングされ得る媒体を含む。
他の所定の単語及びフレーズに対する定義は、本特許文書全体に基づいて決定される。ほとんどでなくとも多くの場合に、このような定義が、定義された用語及びフレーズの将来の使用と同様に過去における使用に対しても適用可能であることは、当業者であれば理解できる。
後述する図1〜図7、及び、本願で本発明の原理を説明するために使用される多様な実施形態は、単に例示に過ぎず、どのような方法であっても本発明の範囲を限定するものとして捉えてはならない。本発明の原理が適切に配列された装置又はシステムで実現できることは、当該技術分野における通常の知識を有する者には明らかである。
MMT符号化及びメディア伝達が、「ISO/IECJTC1/SC29/WG11、異種環境における高効率符号化及び媒体伝達−パート1:MPEGメディア伝送(MMT)(High efficiency coding and media delivery in heterogeneous environments−Part1:MPEG Media Transport(MMT))、2012年7月」とのドキュメント及び標準化内容(standards description)において議論されている。上記のドキュメントは、ここに完全に記述されているように本開示中に引用される。異種IPネットワーク環境上における符号化されたメディアデータの効率的かつ効果的な伝達のために、MMTはマッシュアップ(mash-up)アプリケーションのための多様な構成要素からなるコンテンツを構成するための論理的モデルと、パケット化及び適応化のような伝達階層処理のために符号化されたメディアデータに対する情報を伝達するデータの構造と、ハイブリッド伝達を含んだ、TCP又はUDPを通して使用される特定メディア類型や符号化方法と無関係なメディアコンテンツを伝達するためのパケット化方法及びパケット構造と、メディアコンテンツの提供及び伝達を管理するためのシグナリングメッセージのフォーマットと、交差階層通信を容易にするために階層間で交換されるべき情報のフォーマットと、を提供する。
MMTは、カプセル化、伝達、及びシグナリングを含む三個の機能領域を規定する。カプセル化機能領域は、メディアコンテンツの論理的構造、MMTパッケージ、及びMMT準拠エンティティにより処理されるデータユニットのフォーマットを規定する。MMTパッケージは、メディアコンテンツ及び適応的伝達に必要な情報を提供するためのメディアコンテンツ間の関係を含む構成要素を特定する。データユニットのフォーマットは、伝達プロトコルのペイロードとして格納されるか運搬され、また、格納と運搬との間を容易に変換できるように符号化されたメディアをカプセル化するように定義される。伝達機能領域は、ペイロードのフォーマット及び応用階層プロトコルを定義する。応用階層プロトコルは、マルチメディア伝達のための従来の応用階層プロトコルと比較して、MMTパッケージの伝達のために多重化を含む拡張された特性を提供する。ペイロードフォーマットは、特定メディア類型や符号化方法と無関係な符号化されたメディアデータを運搬するために定義される。シグナリング機能領域は、MMTパッケージの伝達及び消費を管理するためのメッセージのフォーマットを定義する。消費管理のためのメッセージがMMTパッケージの構造をシグナリングするために使用され、伝達管理のためのメッセージがペイロードフォーマットの構造及びプロトコルの構成をシグナリングするために使用される。
MMTは、オーディオ、ビデオ、及びウィジェット、ファイルのような他の固定コンテンツといった時間連続的なマルチメディア伝達のための新たなフレームワークを定義する。MMTは、受信エンティティへのMMTパッケージの伝達のためのプロトコル(すなわち、MMTP)を特定する。MMTPは、プロトコルヘッダの一部としてMMTPパッケージの伝送時間をシグナリングする。その時間は、受信エンティティが各々の流入MMTパケットの伝送時間及び受信時間を検査することでデジッタリング(de-jittering)を実行できる。
本開示の実施形態は、MMT仕様がISOBMFFファイルの低遅延伝送を許容するが、低遅延消費に適合した情報を提供できないことを認識及び参酌する。
図1は、本開示の多様な実施形態が実現される例示的通信システム100を示す。図1に示す通信システム100の実施形態は、例示のためのものである。本開示の範囲から逸脱しない通信システム100の他の実施形態が使用されてもよい。
図1に示されるように、システム100は、システム100内の多様な構成要素間の通信を容易にするネットワーク102を含む。例えば、ネットワーク102は、ネットワークアドレス間インターネットプロトコル(IP)パケット、フレーム中継フレーム、非同期式伝送モード(ATM)セル、又は、他の情報を伝送できる。ネットワーク102は、また、ケーブル及び衛星通信リンクのようなブロードキャスティングネットワークを含む異種ネットワークであってもよい。ネットワーク102には、一つ以上のLAN(local area networks)、MAN(metropolitan area networks)、WAN(wide area networks)、インターネットのようなグローバルネットワーク全体又は一部、又は、一つ以上の位置にある他の通信システムやシステムを含めることができる。
ネットワーク102は、少なくとも一つのサーバ104及び多様なクライアント装置106〜115との間の通信を容易にする。各々のサーバ104は、一つ以上のクライアント装置にコンピュータサービスを提供できるある適合したコンピュータ又は処理装置を含む。各々のサーバ104には、例えば、一つ以上の処理装置、命令及びデータを格納する一つ以上のメモリ、及びネットワーク102を通じて通信を容易にする一つ以上のネットワークインターフェースを含めることができる。
各々のクライアント装置106〜115は、ネットワーク102を介して少なくとも一つのサーバ又は他のコンピュータ装置と相互動作するある適合したコンピュータ又は処理装置を示す。この実施形態で、クライアント装置106〜115には、デスクトップコンピュータ106、モバイル電話やスマートフォン108、PDA(personal digital assistant)110、ラップトップコンピュータ112、タブレットコンピュータ114、及びセットアップボックス及び/又はテレビ115を含めることができる。しかし、このほかに、追加的なクライアント装置を通信システム100内で使用できる。
この実施形態で、一部クライアント装置108〜114は、ネットワーク102と間接的に通信する。例えば、クライアント装置108、110は、携帯電話基地局やeNodeBのような一つ以上の基地局116を通じて通信する。また、クライアント装置112、114は、IEEE802.11無線アクセスポイントのような一つ以上の無線アクセスポイント118を通じて通信する。これらは、単に例示のためのもので、各々のクライアント装置がネットワーク102と直接通信するか、または、ある適合した媒介装置やネットワークを通してネットワーク102と間接的にも通信できることに留意しなければならない。
以下で、より詳細に記述されるように、ネットワーク102は、MMTPを利用したサーバ104からクライアント装置106〜115への例えば、イメージ、ビデオ、及び/又はオーディオのようなメディアデータの通信を容易にする。MMTも多様な伝達環境特性を考慮して設計される点を勘案すると、サーバ104は、MMTPを利用してネットワークを通じてクライアント装置106〜115にメディアデータをブロードキャスティング又はストリーミングできる。また、サーバ104は、メディアデータと共に、又は別途にMMTPデカプセル化バッファ動作及び管理MMTPデカプセル化バッファを通知するためにメッセージを通してバッファ除去モードシグナリングを提供できる。
図1は、通信システム100の一例を図示しているが、多様な変形が図1に対してなされてもよい。例えば、システム100は、任意個数の各構成要素を任意の適合した構成で含むこともできる。一般的に、コンピュータ及び通信システムは、広範囲な構成で示され、図1は、本開示の範囲をある特定構成に限定しない。図1は、本特許文書で開示される多様な特性が使用される一つの動作環境を示しているが、このような特性は、他の適合したシステムでも使用できる。
図2及び3は、本開示によるコンピュータシステム内の装置の例を示す。特に図2は、例示的なサーバ200を示し、図3は、例示的なクライアント装置300を示す。サーバ200は、図1のサーバ104を示し、クライアント装置300は図1のクライアント装置106〜115のうちの一つ以上を示す。
図2に示されるように、サーバ200は、少なくとも一つの制御器210、少なくとも一つの格納装置215、少なくとも一つの通信部220、及び少なくとも一つの入出力(I/O)ユニット225間の通信をサポートするバスシステム205を含む。
制御器210は、メモリ230にロードされる命令語を実行する。制御器210には、ある適合した構成で任意の適合した個数及び類型のプロセッサ又は他の装置を含めることができる。制御器210の類型の例では、マイクロプロセッサ、マイクロ制御器、デジタルシグナリングプロセッサ、フィールドプログラマブルゲートアレイ、ASIC(application specific integrated circuits)、及び分離(discreet)回路を含む。
メモリ230及び永続格納装置(persistent storage)235が格納装置215の例として、(データ、プログラムコード、及び/又は一時的又は持続的な他の適合した情報といった)情報を格納し、その検索を容易にする任意の構造を示す。メモリ230は、RAM(random access memory)又は他の適合した揮発性又は非揮発性格納装置である。永続格納装置235には、ROM(read-only memory)、ハードドライブ、フラッシュメモリ、又は光ディスクのようにデータの長期格納をサポートする一つ以上の構成要素や素子を含めることができる。
通信部220は、他のシステム又は装置との通信をサポートする。例えば、通信部220には、ネットワーク102を通じた通信を容易にするネットワークインターフェースカード又は無線送受信器を含めることができる。通信部220は、適合した物理的及び/又は無線通信リンクを通じて通信をサポートできる。
I/Oユニット225は、データの入力及び出力を可能とする。例えば、I/Oユニット225は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適合した入力装置を通じてユーザ入力のためのインターフェースを提供できる。I/Oユニット225は、また、ディスプレイ、プリンタ、又は他の適合した出力装置に出力を送信できる。
なお、図2は、図1のサーバ104を示すものとして記述されているが、同一又は類似の構造をクライアント装置106〜115のうちの一つ以上にて使用できる。例えば、ラップトップ又はデスクトップコンピュータは、図2に示す構造と同一であるか、類似の構造を有していてもよい。
以下で、より詳細に記述されるように、サーバ200は、メディアデータ及び/又はメディアデータと共に、又は別途に、MMTPデカプセル化バッファ動作及び管理MMTPデカプセル化バッファを通知するためにメッセージを通してバッファ除去モードシグナリングを提供できる。一例で、サーバ200は、IPネットワークを通じてメディアデータをブロードキャスティングするブロードキャストエンティティであってもよい。
図3に示されるように、クライアント装置300は、アンテナ305、送受信器310、送信(TX)処理回路315、マイクロフォン320、及び受信(RX)処理回路325を含む。クライアント装置300は、また、スピーカ330、制御器340、入出力(I/O)インターフェース(IF)345、キーパッド350、ディスプレイ355、及びメモリ360を含む。メモリ360は、オぺレーティングシステム(OS)361と一つ以上のアプリケーション363を含む。
送受信器310は、アンテナ305から、システム内の他の構成要素が伝送した流入RF信号を受信する。送受信器310は、流入RF信号をダウンコンバーティングして中間周波数(IF)やベースバンド信号を生成する。IF又はベースバンド信号は、RX処理回路325に送られ、RX処理回路325はベースバンド又はIF信号をフィルタリング、復号化及び/又は二進化することによって、処理されたベースバンド信号を生成する。RX処理回路325は、処理されたベースバンド信号をスピーカ330(音声データなどの場合)又は制御器340(ウェブブラウジングデータの場合)に伝送する。
TX処理回路315は、マイクロフォン320からアナログやデジタル音声データを受信したり、制御器340から他の流出(outgoing)ベースバンドデータ(ウェブデータ、Eメール又はインタラクティブビデオゲームデータ)を受信する。TX処理回路315は、流出ベースバンドデータを符号化、多重化及び/又は二進化して、処理されたベースバンド又はIF信号を生成する。送受信器310は、処理された流出ベースバンド又はIF信号をTX処理回路315から受信し、アンテナ305を通じて伝送されるベースバンド又はIF信号をRF信号にアップコンバートする。
制御器340には一つ以上のプロセッサ又は他の処理装置を含めることができ、クライアント装置300の全般的な動作を制御するために、メモリ360に格納されたオぺレーティングシステム361を実行する。例えば、制御器340は、よく知らされている原理により送受信器310、RX処理回路325、及びTX処理回路315により順方向チャネル信号の受信及び逆方向チャネル信号の送信を制御できる。一部の実施形態において、制御器340は、少なくとも一つのマイクロプロセッサ又はマイクロ制御器を含む。
制御器340は、メモリ360に存在している他のプロセス及びプログラムを実行できる。制御器340は、実行プロセスにより要求される場合、メモリ360内に又は外にデータを移動できる。一部の実施形態において、制御器340は、オぺレーティングシステム361に基づいて、又は、外部装置やオペレータから受信された信号に応じてアプリケーション363を実行するように構成される。また、制御器340はI/Oインターフェース345と接続され、クライアント装置300にラップトップコンピュータ及びハンドヘルドコンピュータのような他の装置への接続機能を提供する。I/Oインターフェース345は、このようなアクセサリと制御器340との間の通信経路である。
制御器340は、また、キーパッド350及びディスプレイ355と接続される。クライアント装置300のオペレータは、キーパッド350を使用してクライアント装置300にデータを入力できる。ディスプレイ355は、液晶ディスプレイ、又はウェブサイトからテキスト及び/又は少なくとも制限されたグラフィックをレンダリングできる他のディスプレイであってもよい。
メモリ360は、制御器340と接続される。メモリ360の一部は、RAM(random access memory)を含み、メモリ360の他の一部には、フラッシュメモリや他のROM(read-only memory)を含めることができる。
以下でより詳細に記述されるように、クライアント装置300は、低遅延消費(low delay consumption:LDC)メッセージを受信する。例えば、クライアント装置300は、LDCに従ってメディアデータを受信及び処理できる。一例で、クライアント装置300は、IPネットワークを通してメディアデータをブロードキャスティングするモバイル装置であってもよい。
図2及び3は、コンピュータシステム内の装置の例を示すが、多様な変更が図2及び3に対して可能である。例えば、特定のニーズに従って、図2及び3内の多様な構成要素を組み合わせるか、より細部化するか、又は、省略でき、追加構成要素を追加できる。特定実施形態では、制御器340は、一つ以上の中央処理ユニット(CPU)及び一つ以上のグラフィック処理ユニット(GPU)のような多様なプロセッサに分割できる。また、図3は、モバイル電話やスマートフォンで構成されるクライアント装置300を示すが、クライアント装置は、例えば、非限定的にセットアップボックス、テレビ、及びメディアストリーミング装置を含む他の類型のモバイル又は固定装置として動作するように構成できる。また、コンピュータ及び通信ネットワークと同様に、クライアント装置及びサーバを広範囲な様々な構成とでき、図2及び3は、本開示を特定のクライアント装置やサーバに限定しない。
図4は、本開示によるMMTPデータ伝送環境400におけるMMTP入出力に対する例示的なブロック図を示す。この実施形態で、送信エンティティ405、例えば、図2のサーバ200のようなサーバがMMTPに従って、伝送メディアを通して受信エンティティ410、例えば、図3のクライアント装置300のようなクライアント装置にメディアデータを伝送する。メディアデータ415は、送信エンティティ405でMMTPに従って処理される。例えば、送信エンティティ405は、MMTプロセッシングユニット(MPUs)及びMMTフラグメントユニット(MFUs)(例えば、MPUのフラグメント)であるメディアデータに対してMMTパッケージカプセル化、符号化、伝達、及びシグナリングを実行できる。その次に、処理されたメディアデータがMMTPによる処理(例えば、カプセル化解除、復号化等)のために受信エンティティ410に(例えば、パケットとして)伝送される。受信エンティティ410で処理されたメディアデータは、その後、視覚的及び/又は聴覚的ディスプレイ装置によるユーザへの提供のためにMPU及び/又はMFUとして上位階層プログラム(例えば、メディアプレーヤのような応用階層プログラム)に送られ、メディアデータの伝達を完了する。
図5は、受信側での受信器の動作をシミュレーションしバッファ遅延及びサイズ要件を推定するための本開示に係る例示的な受信器バッファモデル500のブロック図を示す。本開示の多様な実施形態で、メディア伝達サーバ(又は、他のMMT認知ノード)のような送信エンティティ405が、一対多伝送システムにおけるメディアデータ伝達のための固定されたエンドツーエンド遅延を算出、判定及び/又は識別する。例えば、送信エンティティ405は、モデル500を活用して、受信エンティティ410の受信器における受信制約上でパケットストリームに対して実行されるメディアデータ処理の影響を判定できる。例えば、送信エンティティ405は、上記モデルを活用して、要求されたバッファリング遅延及び要求されたバッファサイズを判定し、その情報をメディアデータを受信するエンティティに伝送できる。
この図示した例で、FEC復号化バッファ505は、FEC復号化と関連する遅延及び/又はバッファサイズ要件を推定するためのモデルである。FEC復号化は、下位階層伝送がチャネルエラーから復元するためには十分でないか、又は、ネットワーク混雑によりパケット欠落や過度な遅延が発生する場合に、多くのアプリケーションで一般的なものである。FEC復号化を実行するために、受信エンティティ410は、充分なソース(“S”)及びリペアデータ(“P”パリティデータ)がFEC復号化を実行するために使用可能となるまで、流入パケットが格納されるバッファを利用する。
この図示した例で、送信エンティティ405は、FEC復号化と関連する遅延を推定するためにFEC復号化に関して受信エンティティ410が取るアクションを決定するためにFEC復号化バッファ505のモデルを利用する。すなわち、送信エンティティ405は、FEC復号化バッファ505のモデルを利用して、FEC復号化遅延を推定するために受信エンティティ410が取るアクションを予測する。このような送信エンティティ405によるFEC復号化バッファ505のモデリングは、FEC復号化バッファ505が初期段階では空であるという仮定から開始する。続いて、伝送タイムスタンプtsを有する各々の流入パケットiに対して、受信エンティティ410は、buffer_occupancy(バッファ占有)+packet_size(パケットサイズ)<max_buffer_size(最大バッファサイズ)である場合に、FEC復号化バッファ505を使用してパケットiをバッファする。そうでない場合、受信エンティティ410は、パケットiをバッファモデルに符合しないとして破棄する。受信エンティティ410は、次に、FECがパケットiに適用されるかを判定する。FECがパケットiに適用される場合、受信エンティティ410は、パケットiが属するソースブロックjを決定し、ソースブロックjの最初のパケットの挿入時間tを決定し、挿入時間t+FEC_buffer_timeでソースブロックjの全てのパケットを(必要であれば、FEC訂正後)デジッタバッファに移動し、復元パケットを破棄する。送信エンティティ405は、FEC_buffer_timeを、ソースブロックの最初のパケットの受信からFEC復号化が試みられる時までのFEC復号化に必要なバッファ時間として利用する。この時間は、典型的には、FECブロックサイズに基づいて算出される。
デジッタバッファ510は、パケットのデジッタリング、すなわち、パケットの遅延ジッタの除去と関連する遅延及び/又はバッファサイズ要件を推定するために送信エンティティにより使用されるモデルである。デジッタバッファは、究極的には、最大伝送遅延を前提にして、MMTPパケットがソースからMMTPプロトコルスタックの出力まで固定された伝送遅延を経験することを保証する。受信エンティティ410は、最大伝送遅延より大きな伝送遅延を経験するデータユニットを非常に遅いとして破棄できる。
このような送信エンティティ405によるデジッタバッファ510のモデリングは、デジッタバッファ305が初期段階では空であるという仮定から開始する。次に、受信エンティティ410は、MMTPパケットが到着する時にそのパケットをデジッタバッファ510内に挿入する。受信エンティティ410は、その次に、時間ts+ΔでMMTPパケットを除去する。この場合、tsはMMTPパケットの伝送タイムスタンプであり、Δはメディアデータに対してシグナリングされる固定されたエンドツーエンド(end-to-end)遅延である。デジッタリングが適用された後、正確に到着された(又はFEC/再伝送を通して復元された)全てのMMTPパケットは同一のエンドツーエンド遅延を経験したことになる。
MMTPデカプセル化バッファ515は、MMTP処理と関連して、その出力を上位階層に送る前に遅延及び/又はバッファサイズ要件を推定するために送信エンティティにより使用されるモデルである。MMTPプロセッサの出力は、MFUペイロード(低い遅延動作時)、完全な映画フラグメント、又は完全なMPUである。MPUは、それらのサイズによって、より小さなパケットに分割されるか、又は、より大きなパケットに集合される。その後、デカプセル化(MMTPパケット及びペイロードヘッダの除去)及び必要とされた分割解除(de-fragmentation)/集合解除(de-aggregation)が、MMTPプロセシングの一部として実行される。MPUが幾つかのMMTPパケットに分割された場合に組立を実行するために、このプロシージャはデカプセル化遅延と呼ばれるあるバッファリング遅延を必要としてもよい。しかし、このような例示的実施形態で、デカプセル化遅延は、固定されたエンドツーエンド遅延の一環として見なされず、符号化されたメディア階層により消費されるMPUの使用可能性は、エンティティがデカプセル化遅延と関係なく、そのMPUを幾つかのMMTPパケットに分割することによって保障できる。送信エンティティ405によるモデルとして使用される時、バッファ(505、510、及び515)の各々は、例えば、クライアント装置300のメモリ360のような受信エンティティのメモリで実現されることができる。
本開示の多様な実施形態で、MMTPデカプセル化バッファ515は、次のように動作できる。MMTPデカプセル化バッファ515は、初期段階で空であるとき、デジッタバッファ510によりデジッタリングが実行された後、MMTPを受信する。集合したペイロードを運搬するMMTPパケットに対して、受信エンティティ410は、パケット及びペイロードヘッダを除去し、各々の単一データユニットを抽出する。分割されたペイロードを運搬するMMTPパケットに対して、全ての該当フラグメントが正確に受信されるまで、又は、同一分割されたデータユニットに属しないパケットが受信されるまで、パケットがバッファ内に保存される。以下でより詳細に記述するように、クライアントの動作モードによって、完全なMPU、映画フラグメント、又は単一MFUが復元されると、送信エンティティ405は、再構成されたデータをユーザにディスプレイするためにプレゼンテーション階層と同一の上位階層に伝達する。
上述した通り、LDCは、映画フラグメントヘッダのようなメタデータを受信する前に複数のサンプルに対する提供順序を規定する。本開示の実施形態は、MMTPデカプセル化バッファ515からのデータ除去を始める前に、各々のサンプルの提供時間を算出するために使用及び/又は要求される情報をシグナリングするためのメッセージをさらに提供する。
したがって、本開示の実施形態は、映画フラグメントヘッダのようなメタデータを受信する前にクライアントによりメディアデータを復号化及び提供するのに必要な情報を提供する低遅延消費(LDC)メッセージを提供する。このメッセージは、各々のサンプルのデューレーションがトラック拡張ボックス(Track Extends Box)内のデフォルトサンプルデューレーション(default_sample_duration)によりシグナリングされるように固定され、符号化依存構造がアセットを通して固定されていることを示す。このメッセージが使用される時、MPUの第1のサンプルの復号化時間値は、MPUの第1サンプルの提供時間よりfixed_presentation_time_offsetの合計だけサイズが少なく、sample_compositiontime_offset_value対のsample_composition_time_offset_signの最大値は‘1’である。
以下の<表1>はLDCメッセージの例示的なシンタックスを提供する。
この図示した例で、「message_id」は、LDCメッセージの識別子を示し、「version」はLDCメッセージのバージョンを示す。例えば、MMT受信エンティティ(例えば、クライアント装置300)は、このフィールドを使用して受信されたLDCメッセージのバージョンを確認することができる。また、「length」は、LDCメッセージの長さをバイト単位にて示し、次のフィールドの最初バイトからLDCメッセージの最後のバイトまでをカウントしたものである。値「0」は、このフィールドにおいて有効でなくてもよい。続いて、「base_presentation_time_offset」は、復号化時間と提供時間との間の時差に対するマイクロ秒単位の情報を提供する。各々のサンプルの提供時間は、この値だけ、復号化時間より大きくなり得る。これは、復号化されたメディアデータの再整列によってもたらされたサンプルの復号化時間と提供時間との間の差は含まない可能性もある。
また、「coding_dependency_structure_flag」は、サンプルの復号化順序及び提供順序が相異なるという指示を提供する。このフラグが「0」に設定されると、復号化順序がサンプルの提供順序と同一でなければならない。このフラグが「1」に設定されると、復号化順序はサンプルの提供順序と相異する必要があり、クライアントがサンプルの適合した復号化時間及び提供時間を算出できるように、このメッセージを通して詳細構成(composition)時間オフセットが提供されなければならない。また、「period_of_intra_coded_sample」は、独立的に符号化された二つのサンプル間にあるサンプルの個数を提供する。
図6は、本開示によるクライアント装置により受信データを管理するためのプロセス600を示す。例えば、図6に示されたプロセスは、図4の受信エンティティ410により実行される。このプロセスは、図3のクライアント装置300により実現できる。
このプロセスは、クライアント装置がバッファから複数のデータサンプルの各々のサンプルの提供時間に対する情報を含むメッセージを受信することによって始まる(動作610)。例えば、動作610で、クライアント装置は、クライアント装置にあるバッファから複数のデータサンプルの各々のサンプルの提供時間に対する情報を含むメッセージを受信する。このメッセージは、LDCメッセージであってもよく、他のMMTシグナリングメッセージと共に含まれるか、又はクライアント装置におけるメディアコンテンツストリーミング開始時に含めることができる。一例で、このバッファは、図5のMMTPデカプセル化バッファ515である。メッセージ受信時間の前後に、例えばメッセージ受信後に、クライアント装置はメッセージと関連するメディアデータ伝送の受信を開始できる。上記メッセージは、メディアデータ伝送がクライアント装置により受信され始めてから受信できる。
クライアント装置は、複数のサンプル各々のサンプルに対する提供時間を算出する(動作620)。例えば、動作620で、LDCメッセージは、提供時間オフセット値、提供時間オフセットの符号、基本提供時間オフセット、独自符号化されたサンプル間のサンプルの個数、符号化依存構造フラグなどを含むことができる。
例示的な実施形態で、符号化依存構造フラグは、サンプルの符号化が提供順序と同一の順序になっているか否かを示す。提供順序は、サンプルがディスプレイされるように提供される順序である。符号化順序が提供順序と同一であると、サンプルを、それらが復号化されたのと同じ順序で除去できる。データのサンプルはフレームを示す。
他の例示的な実施形態で、提供時間は、基本提供時間オフセットを正又は負の提供時間オフセットに加算することによって算出される。符号は、提供時間オフセットが正であるか負であるかを示し、その値は、提供時間オフセットの値を示す。上記値は、マイクロ秒、ミリ秒、又は他の類型の時間で表現できる。例えば、基本提供時間オフセットがt+40であり、サンプルの提供時間オフセットがt+10であると、そのサンプルの提供時間はt+50である。
以後、クライアント装置は、提供時間に基づいてバッファからデータを除去し、再構成されたデータを上位階層に送る(動作630)。例えば、動作630で、クライアント装置は、提供時間(例えば、提供時間オフセット+基本提供時間オフセット)に基づいてデータを除去できる。クライアント装置は、再構成されたデータをディスプレイ上でユーザに提供するためにプレゼンテーション階層と同一の上位階層に送る。
図7は、本開示によるサーバの提供順序を示すためのプロセス(700)を示す。例えば、図7に示されたプロセスは図4の送信エンティティ405により実行される。このプロセスは、図2のサーバ200により実現されることができる。
このプロセスは、サーバが受信データの提供順序に対する情報を含むメッセージを生成することで始まる(動作710)。例えば、動作710で、上記メッセージは各々のサンプルの提供時間を含むことができる。サーバは、例えば、データの各々のサンプルと関連する値及び符号を含むことができる。サーバは、また、基本提供時間オフセットを示す情報を上記メッセージ内に含むことができる。
以後、サーバは、そのメッセージをクライアント装置に送る(動作720)。例えば、動作720で、サーバは、そのメッセージをクライアントに送り、クライアント装置のMMTPデカプセル化バッファからのデータ除去動作及び管理をシグナリングする。この実施形態で、サーバは、メディアデータをクライアント装置に送るサーバと同一であるか又は相異なるサーバであってもよい。
図6及び7は、クライアントにより受信されたデータを管理してサーバにより提供順序を示す例示的なプロセスを各々図示しているが、多様な変更が図6及び7でなされてもよい。例えば、一連のステップが図示されたが、各々の図面で多様なステップが重複したり並べて発生したり、相異なる順序又は幾つか発生してもよい。
本開示は、例示的な実施形態と共に記述されたが、多様な変更及び修正案が当業者に提案され得る。本開示は、そのような変更及び修正が添付された請求範囲内に属する範囲内で包括する。
本出願の内容は、ある特定要素、ステップ、又は機能が請求範囲に含まれなければならない必須構成要素を意味することとして把握されてはならない。本発明の特許範囲は請求範囲だけにより限定される。