JP6516767B2 - Ｍｍｔｐデカプセル化バッファのシグナリング及び動作 - Google Patents

Ｍｍｔｐデカプセル化バッファのシグナリング及び動作 Download PDF

Info

Publication number
JP6516767B2
JP6516767B2 JP2016559580A JP2016559580A JP6516767B2 JP 6516767 B2 JP6516767 B2 JP 6516767B2 JP 2016559580 A JP2016559580 A JP 2016559580A JP 2016559580 A JP2016559580 A JP 2016559580A JP 6516767 B2 JP6516767 B2 JP 6516767B2
Authority
JP
Japan
Prior art keywords
buffer
data
client device
mode
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2016559580A
Other languages
English (en)
Other versions
JP2017518656A (ja
Inventor
リム，ヨン−クォン
イメド，ブアジジ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2017518656A publication Critical patent/JP2017518656A/ja
Application granted granted Critical
Publication of JP6516767B2 publication Critical patent/JP6516767B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4348—Demultiplexing of additional data and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Communication Control (AREA)
  • Computer And Data Communications (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

本発明は、一般に、送信システムにおけるメディアデータ伝送に関し、より詳しくは、ＭＭＴＰ（Moving Picture Experts Group（MPEG）media transport（MMT）protocol）デカプセル化バッファのシグナリング及び動作に関する。
ＭＭＴは、異種ＩＰネットワーク環境を通じてマルチメディアサービスについてのコード化されたメディアデータの伝送のための技術を規定するデジタルコンテナ標準又はフォーマットである。伝送されてコード化されたメディアデータは、指定された時間で、データの特定のユニットの同期されたデコーディング及び提示（presentation）を要求する視聴覚メディアデータ、即ち、同期型（timed）データと、ユーザによるサービスのコンテキスト又はインタラクションに基づいて、任意の時間でデコードし、提示されるデータの他のタイプ、即ち、非同期型（non-timed）データの両方を含む。
ＭＭＴは、コード化されたメディアデータが、リアルタイムトランスポートプロトコル（ＲＴＰ）、送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）などのインターネットプロトコル（ＩＰ）を用いてパケット基盤の伝送ネットワークを介して伝送されるという仮定の下で設計されたものである。ＭＭＴは、また異なる伝送環境の特徴を考慮して設計されている。
本発明は、ＭＭＴＰデカプセル化（de-capsulation）バッファのシグナリング及び動作を提供する。
一実施形態において、受信されたデータをクライアントデバイスにより管理するための方法が提供される。この方法は、クライアントデバイスにあるバッファからデータの除去のための多数のモードに関する情報を含むメッセージを受信するステップを含む。この方法は、また受信されたメッセージ内の前記モードに関する情報が示すモードの中で、最大要求バッファサイズを有するバッファからデータの除去のためのモードを選ぶステップを含む。さらに、この方法は、識別されたモードに基づいて、バッファからデータを除去するステップを含む。
また他の実施形態において、サーバによりデータ除去管理を指示するための方法が提供される。この方法は、クライアントデバイスにあるバッファから受信データの除去のための多数のモードに関する情報を含むメッセージを生成するステップを含む。前記情報は、前記モードの各々について、データの除去のためのモードのタイプを示す。また、前記方法は、前記メッセージを、クライアントデバイスに送信するステップを含む。
更なる他の実施形態において、受信データを管理するためのクライアントデバイス内の装置が提供される。前記装置は、データを少なくとも一時的に格納するように構成されたバッファを備えるメモリ、受信部、及び制御部を含む。前記受信部は、クライアントデバイスにあるバッファから、データの除去のための多数のモードに関する情報を含むメッセージを受信するよう構成される。前記制御部は、受信したメッセージ内の前記モードに関する情報が示すモードのうち、最大要求バッファサイズを有するバッファから、データの除去のためのモードのタイプを選択し、識別されたタイプのモードに基づいて、バッファからデータを除去するよう構成される。
また、他の実施形態において、データ除去管理を指示するための装置が提供される。この装置は、制御部と、送信部とを含む。前記制御部は、クライアントデバイスにあるバッファから、受信データの除去のための多数のモードに関する情報を含むメッセージを生成するよう構成され、前記情報は、前記モードの各々について、データの除去のためのモードのタイプを示す。前記送信部は、前記 メッセージを、クライアントデバイスに送信するよう構成される。
以下、本発明の開示及びその利点について、より完全な理解を与えるために、添付の図面を参照して説明する。
本発明の実施形態が実現できる通信システムの一例を示す図である。 本発明の実施形態による通信システム内の装置の例を示す図である。 本発明の実施形態による通信システム内の装置の例を示す図である。 本発明によるＭＭＴＰデータ伝送環境におけるＭＭＴＰ入出力の例示的ブロック図である。 本発明により、受信側での受信部動作をシミュレーションし、バッファ遅延及びサイズ要件を推定するための例示的受信部バッファモデルのブロック図である。 本発明により、図５に示したＭＭＴＰデカプセル化バッファ内のＭＭＴＰパケット処理の例示的タイミングチャートである。 本発明により、クライアントデバイスによる受信データの管理のための例示的プロセスのフローチャートである。 本発明により、サーバによるデータ除去管理を指示するための例示的プロセスのフローチャートである。
他の技術的特徴は、以下の図面、詳細な説明、及び特許請求の範囲から当業者には自明である。
本発明を詳細に説明するに先立って、本明細書の全般に渡って用いられる特定の単語及び語句の定義を開示することが望ましい。「接続する」との用語及びその派生語は、二つ以上のコンポーネントが、互いに物理的接触の状態にあるか否か、それらの間の直接的又は間接的通信をいう。用語「送信する」、「受信する」、及び「通信する」及びこれらの派生語は、直接及び間接的通信の両方を含む。「含む」及び「備える」との用語とその派生語は、限定されずに包含を意味する。「又は」との用語は、「及び／又は」の意味を含む。語句「〜と関連する」及びその派生語は、含む、〜内に含まれる、〜と相互接続する、包含する、〜内に包含される、〜に／と接続する、〜に／と連結する、〜と通信できる、〜と協力する、介在する、並置する、〜に近似する、〜に束縛される、有する、〜の特性を有する、〜と関係を有するなどの意味である。「制御部」との用語は、少なくとも一つの動作を制御するデバイス、システム、又はこれらの一部を意味する。かかる制御部は、ハードウェア又はハードウェアとソフトウェア及び／又はファームウェアとの組み合わせで実現できる。特定の制御部と関連した機能は、集中していてもよく、或いは局部的又は遠隔に分散されてもよい。「少なくとも一つ〜」との語句は、項目のリストと共に使われる際に、項目リストのうちの一つ以上の異なる組み合わせが使われてもよく、そのリスト内の一つの項目のみが必要であってもよいことを意味する。例えば、「Ａ、Ｂ、及びＣのうちの少なくとも一つ」は、Ａ、Ｂ、Ｃ、 ＡとＢ、ＡとＣ、ＢとＣ、及びＡとＢとＣとの組み合わせのうちのいずれかを含む。
また、後述の多様な機能は、一つ以上のコンピュータプログラムにより実現又は支援でき、このプログラムの各々は、コンピュータ読み取り可能なプログラムコードから構成され、コンピュータ読み取り可能媒体で実施される。「アプリケーション」及び「プログラム」との用語は、一つ以上のコンピュータプログラム、ソフトウェア成分、命令集合、手続き、関数、オブジェクト、クラス、インスタンス、関連データ、又は適切なコンピュータ読み取り可能なプログラムコードの実現に適合したそれらの一部をいう。「コンピュータ読み取り可能なプログラムコード」との語句は、ソースコード、オブジェクトコード、及び実行可能なコードを含んだコンピュータコードのタイプのいずれかを含む。「コンピュータ読み取り可能媒体」との語句は、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）、ハードディスクドライブ、コンパクトディスク（ＣＤ）、デジタルビデオディスク（ＤＶＤ）、又は他のタイプのメモリのような、コンピュータによりアクセス可能な媒体のタイプのいずれかを含む。「非一時的」コンピュータ読み取り可能媒体は、一時的な電気又は他の信号を伝送する有線、無線、光学、又はその他の通信リンクを排除する。非一時的コンピュータ読み取り可能媒体は、データが永久的に格納できる媒体、及び再記録可能な光学ディスク又は削除可能のメモリデバイスのように、データが格納され、後で上書き可能な媒体を含む。
他の特定の単語及び語句についての定義は、本明細書の全般に渡って提供される。当該技術分野における当業者は、大部分の場合でなくても、前記のような定義が、従来だけでなく、前記のように定義された単語及び語句の未来の使用にも適用されることを理解すべきである。
以下で説明する図１〜図８と、本明細書における本開示の基本原則を説明するために用いられる多様な実施形態は、単に例示するだけのものであり、本開示の範囲を制限することと理解してはならない。当該技術分野における当業者であれば、本開示の基本原則が、適切に配列された無線通信システムで実現できることを理解すべきである。
ＭＭＴコーディング及びメディア伝送は、文献及び標準記述[ISO/IEC JTC 1/SC29/WG11、異種環境における高効率コーディング及び媒体伝送−パート１： ＭＰＥＧメディア伝送（ＭＭＴ）、２０１２年７月]にて論議されており、その文献の全内容は本明細書中に参照として組み入れられている。異種ＩＰネットワーク環境を通じて、コード化されたメディアデータの効率かつ効果的な伝送のために、ＭＭＴは、マッシュアップ（mash-up）アプリケーションのための多様なコンポーネントからなるコンテンツを構成するための論理的モデル、パケット化及び適応化のような、伝送階層処理のためにコード化されたメディアデータに関する情報を運搬するデータ構造、ハイブリッド伝送を含んで、ＴＣＰ又はＵＤＰを通じて用いられる特定のメディアのタイプ又はコーディング方法に不可知（agnostic）のメディアコンテンツを伝送するためのパケット化方法及びパケット構造、メディアコンテンツの提示及び伝送を管理するためのシグナリングメッセージのフォーマット、メディアコンテンツの提示及び伝送を管理するためのシグナリングメッセージのフォーマット、及び交差階層通信を容易にするために、階層に渡って交換されるべき情報のフォーマットを提供する。
ＭＭＴは、カプセル化、伝送、及びシグナリングを含む三つの機能領域を定める。カプセル化機能領域は、メディアコンテンツの論理的構造、ＭＭＴパッケージ、及びＭＭＴコンプライアントエンティティ（MMT compliant entity）により処理されるデータユニットのフォーマットを規定する。ＭＭＴパッケージは、メディアコンテンツ及び適応的な伝送に必要な情報を提供するためのメディアコンテンツ間の関係を含むコンポーネントを指定する。データユニットのフォーマットは、伝送プロトコルのペイロードとして格納されるか，或いは運ばれて、格納と運搬との間で容易に変換されるように、コード化されたメディアをカプセル化するように定義される。伝送機能領域は、ペイロードのフォーマットと、アプリケーション階層プロトコルとを定める。アプリケーション階層プロトコルは、マルチメディアの伝送のための通常のアプリケーション階層プロトコルに比べて、ＭＭＴパッケージの伝送のために、多重化（multiplexing）を含む向上した特徴を提供する。ペイロードフォーマットは、特定のメディアタイプ又はエンコーディング方式に不可知（agnostic）のコード化されたメディアデータを運搬するために定められる。シグナリング機能領域は、ＭＭＴパッケージの伝送及び消費を管理するためのメッセージのフォーマットを定める。消費管理のためのメッセージは、ＭＭＴパッケージの構造をシグナルするために用いられ、伝送管理のためのメッセージは、ペイロードフォーマットの構造及びプロトコルの構成をシグナルするために用いられる。
ＭＭＴは、オーディオ、ビデオ、及びウィジェット、ファイルなどの他の静的コンテンツ（static content）のような時間連続のマルチメディアの伝送のための新しいフレームワークを定める。ＭＭＴは、ＭＭＴパッケージを受信エンティティへ伝送するためのプロトコル（即ち、ＭＭＴＰ）を規定する。ＭＭＴＰは、プロトコルヘッダの一部として、ＭＭＴＰパッケージの送信時間をシグナルする。このような時間は、受信エンティティが、各入力ＭＭＴパケットの送信時間及び受信時間を検査することにより、デジッタ（de-jittering）を行うことを可能とする。
本開示の実施形態は、ＭＭＴ仕様が仮想の受信部バッファモデル（ＨＲＢＭ）を規定するものの、ＭＭＴＰデカプセル化バッファからデータを除去する方法は規定していないことを認知及び参酌する。
これにより、本開示の一つ以上の実施形態は、ＭＭＴＰデカプセル化バッファの動作、及びＭＭＴＰデカプセル化バッファを運用するために用いられるか、又は必要な情報をシグナルするメッセージを提供する。本開示の実施形態は、またＭＭＴＰデカプセル化バッファからデータの除去を開始する前の初期遅延、及びＭＭＴＰデカプセル化バッファからデータを除去するレート（rate）の算出を提供する。さらに、本開示の実施形態は、オーバーフロー（overflow）又はアンダーフロー（underflow）のないＭＭＴＰデカプセル化バッファの動作を提供する。
図１は、本開示の実施形態が実現できる通信システム１００の例を示す。図１に示された通信システム１００の実施形態は、例示に過ぎない。本開示の範囲から外れることなく、通信システム１００の他の実施形態が使用されることができる。
図１に示すように、システム１００は、システム１００内の様々なコンポーネント間の通信を容易に行うネットワーク１０２を含む。例えば、ネットワーク１０２は、ネットワークアドレス間のインターネットプロトコル（ＩＰ）パケット、フレーム中継フレーム、非同期伝送モード（ＡＴＭ）セル、又は他の情報を伝送できる。ネットワーク１０２は、またケーブル及び衛星通信リンクのようなブロードキャスティングネットワークを含む異種ネットワークであってもよい。ネットワーク１０２は、一つ以上のＬＡＮ（local area networks）、ＭＡＮ（metropolitan area networks）、ＷＡＮ（wide area networks）、インターネットのようなグロバールネットワークの全体又は一部、又は一つ以上の位置にある他の通信システムを含んでもよい。
ネットワーク１０２は、少なくとも一つのサーバ１０４及び多様なクライアントデバイス１０６〜１１５間の通信を助ける。各々のサーバ１０４は、一つ以上のクライアントデバイスに、コンピューティングサービスを提供することができるいずれかの適切なコンピューティング又は処理デバイスを含む。各々のサーバ１０４は、例えば、一つ以上の処理デバイス、命令及びデータを格納する一つ以上のメモリ、及びネットワーク１０２を介した通信を助ける一つ以上のネットワークインターフェースを含むことができる。
各々のクライアントデバイス１０６〜１１５ は、ネットワーク１０２を介して少なくとも一つのサーバ又は他のコンピューティングデバイスと相互動作するいずれかの適切なコンピューティング又は処理デバイスを示す。この例において、クライアントデバイス１０６〜１１５には、デスクトップコンピュータ１０６、モバイル電話又はスマートフォン１０８、ＰＤＡ（personal digital assistant）１１０、ラップトップコンピュータ１１２、タブレットコンピュータ１１４、及びセットトップボックス及び／又はテレビジョン１１５が含まれる。しかし、他の、又は追加のクライアントデバイスが、通信システム１００内において用いられてもよい。
この例において、一部のクライアントデバイス１０８〜１１４は、ネットワーク１０２と間接的に通信する。例えば、クライアントデバイス１０８、１１０は、携帯電話基地局又はeNodeBのような一つ以上の基地局１１６を通じて通信する。また、クライアントデバイス１１２〜１１４は、ＩＥＥＥ８０２．１１無線アクセスポイントのような一つ以上の無線アクセスポイント１１８を通じて通信する。これらは例示に過ぎず、各々のクライアントデバイスが、ネットワーク１０２と直接通信するか、適切な媒介装置又はネットワークを通じて、ネットワーク１０２と間接的に通信できることを理解すべきである。
以下でより詳細に説明されるように、ネットワーク１０２は、ＭＭＴＰを用いたサーバ１０４からクライアントデバイス１０６〜１１５への、例えば、イメージ、ビデオ、及び／又はオーディオのようなメディアデータの通信を助ける。ＭＭＴが、また異なる伝送環境の特性を考慮して設計されていることを勘案すると、サーバ１０４は、ＭＭＴＰを用いて、ネットワークを通じてクライアントデバイス１０６〜１１５に、メディアデータをブロードキャスト又はストリームしてもよい。また、サーバ１０４は、メディアデータと共に、或いは、別途に、ＭＭＴＰデカプセル化バッファ動作及び管理ＭＭＴＰデカプセル化バッファを示すために、メッセージを通じてバッファ除去モードシグナリングを提供してもよい。
図１は、通信システム１００の一例を示しているが、図１について様々な変形が可能である。例えば、システム１００は、各コンポーネントの任意の個数を任意の適切な配列で含むことができる。一般に、コンピューティング及び通信システムは、広範囲の構成で示され、図１は、本開示の範囲を特定の構成に限定しない。図１は、本明細書に開示された様々な特性が用いられ得る一つの動作環境を示しているが、これらの特性は、他の適切なシステムにおいても用いることができる。
図２及び図３は、本開示によるコンピューティングシステム内の例示的デバイスを示す。特に、図２は、例示的なサーバ２００を示し、図３は、例示的なクライアントデバイス３００を示す。サーバ２００は、図１においてサーバ１０４を示してもよく、クライアントデバイス３００は、図１においてクライアントデバイス１０６〜１１５のうちの一つ以上を示してもよい。
図２に示すように、サーバ２００は、少なくとも一つの制御部２１０、少なくとも一つの格納装置２１５、少なくとも一つの通信部２２０、及び少なくとも一つの入出力（Ｉ／Ｏ）ユニット２２５間の通信を支援するバスシステム２０５を含む。
制御部２１０は、メモリ２３０内にロードされた命令語を実行する。制御部２１０は、適切な個数及びタイプのプロセッサ又は他のデバイスを適切な配列で含んでもよい。制御部２１０の例としては、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ、フィールドプログラマブルゲートアレイ、特定用途向け集積回路（application specific integrated circuits、ASIC）、及び分離回路を含む。
メモリ２３０及び永続性記憶部２３５が格納装置２１５の例であるが、格納装置２１５は、情報 (データ、プログラムコード、及び／又は一時的又は持続的な他の適切な情報)を格納し、その検索を支援可能な任意の構造を指す。メモリ２３０は、ＲＡＭ（random access memory）又は他の適切な揮発性又は非揮発性格納装置であってもよい。永続性記憶部２３５は、ＲＯＭ（read-only memory）、ハードドライブ、フラッシュメモリ、又は光ディスクのように、データの長期的格納を支援する一つ以上のコンポーネント又はデバイスを含んでもよい。
通信部２２０は、他のシステム又はデバイスとの通信を支援する。例えば、通信部２２０は、ネットワーク１０２を通じて通信を助けるネットワークインターフェースカード又は無線送受信部を含むことができる。通信部２２０は、適切な物理的又は無線通信リンクを通じて通信を支援できる。
Ｉ／Ｏユニット２２５は、データの入力及び出力を可能にする。例えば、Ｉ／Ｏユニット２２５は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適切な入力装置を通じてユーザ入力のための接続が提供できる。Ｉ／Ｏユニット２２５は、またディスプレイ、プリンター、又は他の適切な出力装置へ出力を送ることができる。
なお、図２は、図１のサーバ１０４を示しているが、同一、又は類似の構造を、クライアントデバイス１０６〜１１５のうちの一つ以上に用いることができる。例えば、ラップトップ又はデスクトップコンピュータは、図２に示したものと同一又は類似の構造を有することができる。
以下でより詳細に説明するように、サーバ２００は、メディアデータと共に、或いは別途に、ＭＭＴＰデカプセル化バッファ 動作及び管理ＭＭＴＰデカプセル化バッファを示すために、メッセージを通じてメディアデータ及び／又はバッファ除去モードシグナリングを送信する。一例において、サーバ２００は、ＩＰネットワークを通じてメディアデータをブロードキャストするためのブロードキャストエンティティであってもよい。
図３に示すように、クライアントデバイス３００は、アンテナ３０５、送受信部３１０、送信（ＴＸ)処理回路３１５、マイクロフォン３２０、及び受信（ＲＸ)処理回路３２５を含む。クライアントデバイス３００は、さらにスピーカー３３０、制御部３４０、入出力（Ｉ／Ｏ）インターフェース（ＩＦ）３４５、キーパッド３５０、ディスプレイ３５５、及びメモリ３６０を含む。メモリ３６０は、オペレーディングシステム（ＯＳ）３６１と、一つ以上のアプリケーション３６３とを含む。
送受信部３１０は、アンテナ３０５から、システム内の他のコンポーネントにより送信される流入（incoming）ＲＦ信号を受信する。送受信部３１０は、流入ＲＦ信号をダウンコンバートすることにより、中間周波数（ＩＦ）又は基底帯域信号を生成する。ＩＦ又は基底帯域信号は、ＲＸ処理回路３２５に送られ、ＲＸ処理回路３２５は、基底帯域又はＩＦ信号をフィルタリング、デコーディング、及び／又は二進化処理により、処理された基底帯域信号を生成する。ＲＸ処理回路３２５は、処理された基底帯域信号をスピーカー３３０(音声データの場合)に、又はさらなる処理のために制御部３４０(ウェブブラウジングデータの場合)に送信する。
ＴＸ処理回路３１５は、マイクロフォン３２０からアナログ又はデジタル音声データを、又は制御部３４０から他の流出（outgoing）基底帯域データ(ウェブデータ、E−メール又はインタラクティブビデオゲームデータ)を受信する。ＴＸ処理回路３１５は、流出基底帯域データを、エンコーディング、多重化、及び／又は二進化して、処理された基底帯域又はＩＦ信号を生成する。送受信部３１０は、処理された流出基底帯域又はＩＦ信号を、ＴＸ処理回路３１５から受信し、アンテナ３０５を介して送信される基底帯域又はＩＦ信号をＲＦ信号にアップコンバートする。
制御部３４０には、一つ以上のプロセッサ又は他の処理デバイスを含めることができ、クライアントデバイス３００の全般的動作を制御するために、メモリ３６０に格納された基本オペレーティングシステム３６１を実行する。例えば、制御部３４０は、よく知られている原理に従い、送受信部３１０、ＲＸ処理回路３２５、及びＴＸ処理回路３１５によりフォワードチャンネル信号の受信及びリバースチャンネル信号の送信を制御することもできる。一部の実施形態において、制御部３４０は、少なくとも一つのマイクロプロセッサ又はマイクロコントローラを含む。
制御部３４０は、メモリ３６０に常駐する他のプロセス及びプログラムを実行することもできる。制御部３４０は、実行プロセスにより要請されるとき、メモリ３６０の内外にデータを移動できる。一部の実施形態において、制御部３４０は、オペレーティングシステム３６１に基づくか、又は外部装置又はオペレータから受信した信号に応じて、アプリケーション３６３を実行するように構成されている。制御部３４０は、またクライアントデバイス３００に、ラップトップコンピュータ及びハンドヘルドコンピュータのような他の装置への接続機能を提供するＩ／Ｏインターフェース３４５に結合される。Ｉ／Ｏインターフェース３４５は、これらのアクセサリーと制御部３４０との間の通信経路である。
制御部３４０はまた、キーパッド３５０及びディスプレイ３５５に接続される。クライアントデバイス３００のオペレータは、キーパッド３５０を用いてクライアントデバイス３００にデータを入力できる。ディスプレイ３５５は、液晶ディスプレイ、又はウェブサイトなどからのテキスト及び／又は少なくとも制限されたグラフィックをレンダリングできる他のディスプレイであってもよい。
メモリ３６０は、制御部３４０に接続される。メモリ３６０の一部には、ＲＡＭ（random access memory）を含めることができ、メモリ３６０の他の一部には、フラッシュメモリ又は他のＲＯＭ（read-only memory）を含めることができる。
以下でより詳細に説明されるように、クライアントデバイス３００は、メディアデータバッファ除去モードシグナリングを受信する。例えば、クライアントデバイス３００は、ＨＲＢＭによりメディアデータを受信及び処理してもよい。クライアントデバイス３００はまた、サーバから受信したメッセージから、ＭＭＴＰデカプセル化バッファデータ除去動作及び管理が識別できる。一例において、クライアントデバイス３００は、ＩＰネットワークを通じてブロードキャストメディアデータを受信するモバイル装置であってもよい。
図２及び図３は、コンピューティングシステム内のデバイスの例を示しているが、図２及び図３について様々な変更が行われてもよい。例えば、図２及び図３において、多様なコンポーネントが接続されるか、さらに細分化されるか、省略されてもよく、特定のニーズに応じて追加のコンポーネントが加えられてもよい。特定の例として、制御部３４０は、一つ以上の中央処理ユニット（ＣＰＵ）及び一つ以上のグラフィック処理ユニット（ＧＰＵ）のような複数のプロセッサに分割できる。また、図３は、モバイル電話又はスマートフォンとして構成されたクライアントデバイス３００を示しているが、クライアントデバイス３００は、例えば、非限定的に、セットトップボックス、テレビジョン、及びメディアストリーミングデバイスを含む他のタイプのモバイル又は固定デバイスとして動作するように構成できる。また、コンピューティング及び通信ネットワークを用いることのように、クライアントデバイス及びサーバは、広範囲の構成で示すことができ、図２及び図３は、本開示を特定のクライアントデバイス又はサーバに限定していない。
図４は、本開示によるＭＭＴＰデータ送信環境４００におけるＭＭＴＰ入出力の例示的ブロック図である。この例において、送信エンティティ４０５、例えば、図２のサーバ２００のようなサーバが、ＭＭＴＰに従って、送信媒体を通じて受信エンティティ４１０、例えば、図３のクライアントデバイス３００のようなクライアントデバイスに、メディアデータを送る。メディアデータ４１５は、ＭＭＴＰに従って、送信エンティティ４０５で処理される。例えば、送信エンティティ４０５は、ＭＭＴ処理ユニット（ＭＰＵ）及び ＭＭＴフラグメントユニット（ＭＦＵ)(例えば、ＭＰＵのフラグメント)としてメディアデータに対して、ＭＭＴパッケージカプセル化、コーディング、伝送、及びシグナリングを行ってもよい。次に、その処理されたメディアデータは、ＭＭＴＰによる処理(例えば、デカプセル化, デコーディングなど)のために、受信エンティティ４１０に（例えば、パケットとして）送られる。受信エンティティ４１０で処理されたメディアデータは、次に、メディアデータの伝送を完了する視覚及び／又は聴覚的ディスプレイ装置の上に、ユーザに提示するためにＭＰＵ及び／又はＭＦＵとして上位階層プログラミング（例えば、メディアプレーヤーのようなアプリケーション階層プログラム）まで送られる。
図５は、本開示による受信側での受信部動作をシミュレーションし、バッファ遅延及びサイズ要件を推定するための例示的受信部バッファモデル５００のブロック図を示す。本開示の様々な実施形態において、メディア伝送サーバ（又は他のＭＭＴ認知ノード）のような送信エンティティ４０５が、一対多点の送信システムにおけるメディアデータ伝送のための固定のエンドツーエンド遅延を算出、判断及び／又は識別する。例えば、送信エンティティ４０５は、モデル５００を活用して、受信エンティティ４１０の受信部における受信制約上で、パケットストリームに対して実施されたメディアデータ処理の影響を判断してもよい。例えば、送信エンティティ４０５は、上記のモデルを活用して、求められたバッファリング遅延及び求められたバッファサイズを判断し、その情報を、メディアデータを受信するエンティティに伝送してもよい。
この例示において、ＦＥＣデコーディングバッファ５０５は、ＦＥＣデコーディングと関連した遅延及び／又はバッファサイズ要件を推定するためのモデルである。ＦＥＣデコーディングは、下位階層送信だけではチャンネルエラーから復旧するのに十分でない場合がある、又は、ネットワーク輻輳がパケットドロップ又は過度の遅延を発生させる場合の多くのアプリケーションに典型的に用いられる。ＦＥＣデコーディングを行うために、受信エンティティ４１０は、ＦＥＣデコーディングを行うのに十分な量のソース（「Ｓ」）及びリペアデータ（「Ｐ」パリティーデータ）が利用可能となるまで流入パケットを記憶させたバッファを用いる。
この例示において、送信エンティティ４０５は、ＦＥＣデコーディングと関連した遅延を推定するために、ＦＥＣデコーディングに関し、受信エンティティ４１０が取るアクションを決めるように、ＦＥＣデコーディングバッファ５０５のモデルを用いる。即ち、送信エンティティ４０５は、ＦＥＣデコーディングバッファ５０５のモデルを用いてＦＥＣデコーディング遅延を推定するために、受信エンティティ４１０により取られるアクションを予測する。このような送信エンティティ４０５によるＦＥＣデコーディングバッファ５０５のモデリングは、ＦＥＣデコーディングバッファ５０５が初期段階では空であると仮定して開始される。次に、送信タイムスタンプｔｓを有する各々の流入パケットｉに対して、受信エンティティ４１０は、buffer_occupancy＋packet_size＜max_buffer_sizeの場合、ＦＥＣデコーディングバッファ５０５を用いて、パケットｉをバッファする。そうでない場合、受信エンティティ４１０は、パケットｉを、バッファモデルに合わないものとして破棄する。受信エンティティ４１０は、その後、ＦＥＣをパケットｉに適用するか否かを判断する。ＦＥＣをパケットｉに適用する場合、受信エンティティ４１０は、パケットｉの属するソースブロックｊを決定し、ソースブロックｊの第１パケットの挿入時間ｔを決定し、time t+FEC_buffer_timeのタイミングにてソースブロックｊの全てのパケットを（必要な場合、ＦＥＣ訂正の後）デジッタバッファに移動し、リペアパケットを破棄する。送信エンティティ４０５は、ソースブロックの最初のパケットの受信からＦＥＣデコーディングが試みられるまでのＦＥＣデコーディングに必要なバッファ時間として、FEC_buffer_timeを用いる。この時間は、通常、ＦＥＣブロックサイズに基づいて算出される。
デジッタバッファ５１０は、パケットのデジッタリング、即ち、パケットの遅延ジッタの除去と関連した遅延及び／又はバッファサイズ要件を推定するために、送信エンティティにより用いられるモデルである。デジッタバッファは、究極的には、最大送信遅延を前提として、ＭＭＴＰパケットが、ソースからＭＭＴＰプロトコルスタックの出力まで固定された送信遅延を経験することを保証する。受信エンティティ４１０は、最大送信遅延より大きな送信遅延を経たデータユニットを、非常に遅いものとして破棄してもよい。
このような送信エンティティ４０５によるデジッタバッファ５１０のモデリングは、デジッタバッファ３０５が初期段階では空であるという仮定から開始する。その後、受信エンティティ４１０は、ＭＭＴＰパケットが到着するとき、そのパケットをデジッタバッファ５１０に挿入する。受信エンティティ４１０は、その後、時間ts+ΔでＭＭＴＰパケットを除去する。ここで、ｔｓは、ＭＭＴＰパケットの送信タイムスタンプであり、Δは、メディアデータについてシグナルされる固定されたエンドツーエンド遅延である。デジッタリングが適用された後、適切に到着した（又はＦＥＣ／再伝送を通じて復旧された）全てのＭＭＴＰパケットは、同じエンドツーエンド遅延を経験しているであろう。
ＭＭＴＰデカプセル化バッファ５１５は、ＭＭＴＰ処理と関連して、その出力を上位階層へ送る前に、遅延及び／又はバッファサイズ要件を推定するために、送信エンティティにより用いられるモデルである。ＭＭＴＰプロセッサの出力は、ＭＦＵペイロード（低い遅延動作の時）、完全なムービーフラグメント、又は完全なＭＰＵであり得る。ＭＰＵは、それらのサイズによって、より小さいパケットに分割されるか、又はより大きいパケットの集合とできる。デカプセル化（ＭＭＴＰパケット及びペイロードヘッダの除去）及びそのパケットの任意の求められた分割解除（de-fragmentation）／集合解除（de-aggregation）が、ＭＭＴＰプロセッシングの一部として行われる。この手続きは、ＭＰＵが、多くのＭＭＴＰパケットに分割される際、組立てを行うために、デカプセル化遅延と称されるバッファリング遅延を求めることができる。しかし、このような例示的実施形態において、デカプセル化遅延は，固定されたエンドツーエンド遅延の一部として看做されなく、コード化されたメディア階層により消費されるＭＰＵの可用性は、エンティティがデカプセル化遅延と関係なく、そのＭＰＵを多くのＭＭＴＰパケットに分割することにより保証できる。送信エンティティ４０５によりモデルとして用いられる際、バッファ５０５、５１０、及び５１５の各々は、例えば、クライアントデバイス３００のメモリ３６０のような受信エンティティのメモリで実現できる。
本開示の様々な実施形態において、ＭＭＴＰデカプセル化バッファ５１５は、以下のように動作してもよい。ＭＭＴＰデカプセル化バッファ５１５は、初期段階で空であるときに、デジッタバッファ５１０によりデジッタリングが行われた後、ＭＭＴＰパケットを受信する。ＭＭＴＰパケットが集合したペイロードを運搬する場合、受信エンティティ４１０は、パケット及びペイロードヘッダを除去し、各々の単一データユニットを抽出する。ＭＭＴＰパケットが分割されたペイロードを運搬する場合、全てのフラグメントが正しく受信されるまで、或いは同一の分割されたデータユニットに属さないパケットが受信されるまで、パケットがバッファ内に保持される。以下でより詳細に説明するように、クライアントの動作モードに応じて、完全なＭＰＵ、ムービーフラグメント、又は単一ＭＦＵが復旧されると、送信エンティティ４０５は、再構成されたデータを、ユーザに表示するために、提示階層のような上位階層に伝送する。
前述のように、受信部バッファモデル又はＭＭＴのＨＲＢＭは、ＭＭＴＰパケット伝送のエンドツーエンド遅延を保持するためのバッファモデルを定める。本開示の実施形態は、ＭＭＴＰデカプセル化バッファ５１５からデータの除去を始める前の初期遅延及びＭＭＴＰデカプセル化バッファ５１５からデータを除去するレートの両方を算出するのに使用及び／又は必要な情報をシグナルするためのメッセージをさらに提供する。
本開示の様々な実施形態において、サーバ２００は、クライアントデバイス３００に、クライアントデバイス３００の動作モードによるＭＭＴＰデカプセル化バッファの管理に関する情報を含むメッセージを提供する。一実施形態において、このメッセージは、ＨＲＢＭ除去メッセージであってもよい。他の実施形態において、上記の情報は、例えば、固定されたエンドツーエンド遅延をシグナルするのに用いられるメッセージのように、情報をシグナルするのに使用される他のＭＭＴシグナリングメッセージと共に含まれてもよい。このメッセージは、クライアントデバイス３００が、ＭＭＴＰデカプセル化バッファ５１５からデータの除去を始める前の初期遅延及びＭＭＴＰデカプセル化バッファ５１５からデータを除去するレートの両方を算出するのに使用及び／又は要求する情報を提供する。このメッセージがシグナルされると、クライアントデバイス３００は、データ送信のために、可能な、現在使用可能である、及び／又は、サポートされている動作モードのうちの一つを識別、及び／又は選択する。クライアントデバイス３００は、ＭＭＴＰデカプセル化バッファ５１５のオーバーフロー及び／又はアンダーフローを避ける及び／又は防ぐために、このメッセージによりシグナルされる最大要求バッファサイズを有する動作モードを選択できる。選択されたモードに応じて、クライアントデバイス３００は、完全なＭＰＵ、ムービーフラグメント、又は単一ＭＦＵを復旧し、再構成されたデータは、メディアエンジンのような上位階層に伝送される。
Figure 0006516767
この例示において、「message_id」は、HRBM_Data_Removalメッセージの識別子を示し、「version」は、HRBM_Data_Removalメッセージのバージョンを示す。例えば、ＭＭＴ受信エンティティ（例えば、クライアントデバイス３００）は、このフィールドを用いて、受信したHRBM_Data_Removalメッセージのバージョンを確認できる。また、「length」は、HRBM_Data_Removalメッセージのバイト単位の長さを示すものであって、次のフィールドの最初のバイトからHRBM_Data_Removalメッセージの最終のバイトまでカウントしたものである。値「０」は、このフィールドにおいて有効でないことがある。続いて、「number_of_operation_modes」は、（例えば、以下の表２に示されているように）クライアントデバイス３００が選択する、現在使用可能な及び／又はサポートされるデータ送信のための動作モードの個数を提供し、「data_removal_type」は、ＭＭＴＰデカプセル化バッファ５１５で再構成されたデータを除去するクライアントの動作モードのタイプについての情報を提供する。各々のモード毎に必要なバッファサイズが提供される。
さらに、「max_decapsulation_buffer_size」は、ＭＭＴアセットのバイト単位で、ＭＭＴＰデカプセル化バッファの必要な最大サイズについての情報を提供し、「buffer_management_valid」は、アセットについて定義されたバッファ管理メカニズムが、適用されるか否かに関する情報を提供する。例えば、このフラグが「０」に設定されると、ＭＭＴＰデカプセル化バッファ５１５からデータの除去を始める前の初期遅延及びＭＭＴＰデカプセル化バッファ５１５からデータを除去するレートの両方について何の制限も与えられない。再構成されたデータは、ＭＭＴＰデカプセル化バッファ５１５が満たされるまで、そのバッファ５１５で利用可能である。再構成されたデータは、バッファが満たされているとき、新たに受信及び復旧したデータを追加するために、クライアントにより選択された動作モードに応じて、最も古いもの（例えば、最古の完全なＭＰＵ、ムービーフラグメント、又はＭＦＵ）から除去される。このフラグが「１」に設定されると、ＭＭＴＰデカプセル化バッファ５１５からデータの除去を始める前の初期遅延及びＭＭＴＰデカプセル化バッファ５１５からデータを除去するレートの両方を算出するために、適合した情報が、外部仕様に基づいてメディアデータにおいて運搬される。
以下の表２は、クライアントデバイス３００が動作するに当って、選択できる多様なタイプのモード及び「data_removal_type」値についての例示的コーディングを提供する。
Figure 0006516767
このような例示的実施形態において、クライアントデバイス３００により選択可能なモードのタイプとしては、ＭＰＵモード、ムービーフラグメントモード、及びＭＦＵモードが含まれる。クライアントデバイス３００は、クライアントデバイス３００の使用可能なバッファサイズ、メディアデータのバッファサイズ要件、及び／又はクライアントデバイス３００のユーザと関連のメディア消費類型と関連した提示要件に基づいて、動作モードを選択できる。例えば、メディアコンテンツを後で鑑賞するために録画する場合のように、バッファが使用可能であるか否かが深刻な制約とならない非実時間的なシナリオにおいて、クライアントデバイス３００は，全ＭＰＵを待って、ＭＰＵモードで動作するように選択できる。より実時間的なメディア消費アプリケーションにおいて、クライアントデバイス３００は、ＭＦＵモード又はムービーフラグメントモードを用いて、メディアデータをより迅速に提示階層に伝送できる。ムービーフラグメントモードにおいて、多数の関連のＭＦＵ及び関連のメタデータは、上記の関連のＭＦＵを提示階層に送るために一緒に処理される。
図６は、本開示の様々な実施形態によるＭＭＴＰデカプセル化バッファ５１５内のＭＭＴＰパケット処理のタイミングチャート６００を示す。タイミングチャート６００は、ＭＭＴＰパケットが処理されて上位階層に出力される際の、ＭＭＴＰデカプセル化バッファ５１５のバッファレベルの経時変化例である。例えば、タイミングチャート６００は、ＭＭＴＰパケット処理と関連したバッファ要件を推定する例である。
送信エンティティ４０５によるＭＭＴＰデカプセル化バッファ５１５のモデリングは、ＭＭＴＰデカプセル化バッファ５１５が初期段階では空であるとの仮定から開始する。受信エンティティ４１０は、デジッタリングが行われた後、ＭＭＴＰパケットを、ＭＭＴＰデカプセル化バッファ５１５内に挿入する。集合したペイロードを運搬するＭＭＴＰパケットについて、受信エンティティ４１０は、パケット及びペイロードヘッダを除去し、その集合を個別のＭＰＵに分割する。分割されたペイロードを運搬するＭＭＴＰパケットについて、受信エンティティ４１０は、全ての当該フラグメントが正しく受信されるまで、或いは同一の分割されたＭＰＵに属さないパケットが受信されるまで、ＭＭＴＰデカプセル化バッファ５１５内にパケットを保持する。ＭＰＵの全てのフラグメントが受信されると（例えば、時間６０５又は時間６１０で）、受信エンティティ４１０は、ＭＭＴＰパケット及びペイロードヘッダを除去し、再組立て（reassemble）した後、再構成されたＭＰＵを上位階層に伝送する。それに対して、ＭＰＵの一部のフラグメントが受信されていない場合には、受信エンティティ４１０は、不完全なＭＰＵのフラグメントを破棄してもよい。
このような受信部バッファモデル５００に基づいて、送信エンティティ４０５は、送信スケジュール、バッファサイズ及びバッファリング遅延Δを判断し、ターゲット経路上の最大伝送遅延を仮定して、パケットがドロップしないことを保証できる。送信エンティティ４０５は、設定された閾値以下の送信遅延を経験するパケットが、一対多点の送信システムに渡って一定の遅延の後、クライアントバッファがアンダーフロー又はオーバーフローすることなく、上位階層に出力されることを可能とするか又は保証する。
メディアデータに求められたバッファサイズ及び固定のエンドツーエンド遅延を判断した後、送信エンティティ４０５は、受信エンティティ４１０に、その情報を伝送する。例えば、送信エンティティ４０５は、送信及び受信エンティティ間のシグナリングプロトコルを用いて、 受信エンティティ４１０にその情報を伝送してもよい。多様な実施形態において、送信エンティティ４０５は、選択されたエンドツーエンド遅延及びバッファサイズがアラインされ（aligned）、バッファアンダーラン（under-runs）又はオーバーラン（overruns）を起こさないことを確認するために、受信部バッファモデル５００を、連続的に実行できる。受信側において、固定遅延のシグナリングは、受信エンティティ４１０に対して、各々のデータユニットが上位階層に伝送される前に、シグナルされた固定のエンドツーエンド遅延Δを経験するように、バッファリングを実行するよう指示する。送信及び受信エンティティ間のクロックが同期されるという前提の下で、受信エンティティ４１０は、送信タイムスタンプ及びシグナルされた固定のエンドツーエンド遅延に基づいて、データの出力時間を算出できる。
一部の実施形態において、送信エンティティ４０５は、セッション記述プロトコル（ＳＤＰ）ファイルのようなセッション記述ファイルを用いて、シグナリングを行う。ＳＤＰにおいて、メディアセッションは、ＭＭＴＰプロトコルを用いて伝送されると記述される。メディアセッションは、固定のエンドツーエンド遅延及び／又は要求されたバッファサイズを含む。表３は、固定のエンドツーエンド遅延及びバッファサイズ要件をシグナルするＳＤＰファイルのメディアセッション記述の一例を示す。
Figure 0006516767
他の実施形態において、固定のエンドツーエンド遅延及びバッファサイズ要件のシグナリングは、ＭＭＴＰシグナリング関数を用いて行われる。そのような実施形態において、上記の情報を運搬するための新たなシグナリングメッセージが設計される。
この例において、バッファサイズは、バイト単位であり、固定のエンドツーエンド遅延は、ミリ秒単位である。他の実施形態において、送信エンティティ４０５は、特殊なシグナリングメッセージタイプが定義されるか、既存のシグナリングメッセージ内に情報が含まれるＭＭＴＰシグナリングメッセージを用いて、シグナリングを行うことができる。
固定遅延を判断する際、送信エンティティ４０５は、受信部への送信経路上で、最大期待及び許容可能な送信遅延を推定する。ＦＥＣが用いられる場合、送信エンティティ４０５は、損失したＭＭＴＰパケットを復旧するためにＦＥＣデコーディングが要求される状況で、ソースブロックを組み立てるのに必要な時間（例えば、前記の論議されたFEC_buffer_time）をカバーするＦＥＣバッファリング遅延を追加する。また、送信エンティティ４０５は、パケットの分割により誘発される可能性がある遅延を追加する。送信エンティティ４０５は、その結果によるＭＭＴＰ伝送遅延の推定を、固定のエンドツーエンド遅延としてシグナルする。固定のエンドツーエンド遅延を推定する一例が、以下の数式１により与えられる。
Figure 0006516767
多様な実施形態において、結果的なバッファ要件を推定するために、送信エンティティ４０５は、データが送信エンティティ４０５によりバッファされるべきであると推定された最大時間量として、固定のエンドツーエンド遅延を用い受信部への送信経路についての最小送信遅延を差し引いてもよい。次に、送信エンティティ４０５は、バッファサイズ要件を、算出したバッファデータデュレーション（duration）とＭＭＴＰストリームの最大ビットレートとを乗じた値として推定できる。固定のエンドツーエンド遅延を推定する一例が、以下の数式２により与えられる。
Figure 0006516767
本明細書に記述された多様な実施形態は、ＭＭＴＰデータ通信について述べているが、本開示の多様な実施形態は、ＭＭＴ通信のみに制限されないことに留意すべきである。例えば、あるモードシグナリング及び決定、固定の遅延及びバッファサイズの決定は、本開示の原理に従い、適切なタイプのデータ又はメディアコンテンツ伝送及び／又は適切なタイプの送信システムにも適用できる。
図７は、本開示により、クライアントデバイスによる受信データを管理するための例示的プロセスのフローチャートを示す。例えば、図７に示したプロセスは、図４の受信エンティティ４１０により実行されてもよい。このプロセスは、図３のクライアントデバイス３００により実現されてもよい。
このプロセスは、クライアントデバイスが、データ除去のための多くのモードに関する情報を含むメッセージを受信することから始まる（ステップ７０５）。例えば、ステップ７０５において、クライアントデバイスは、クライアントデバイスにあるバッファから、メディアデータの除去を管理するためのメッセージを受信する。このメッセージは、ＨＲＢＭ除去メッセージであってもよく、他のＭＭＴシグナリングメッセージと共に含まれてもよく、及び／又は、クライアントデバイスへのメディアコンテンツストリーミングの開始の際に含まれてもよい。一例において、このバッファは、図５のＭＭＴＰデカプセル化バッファ５１５である。メッセージの受信時間の付近で、例えば、メッセージの受信後、クライアントデバイスは、メッセージ及びデータ除去のモードと関連付けられたメディアデータ送信の受信を開始してもよい。また、メディアデータ送信がクライアントデバイスにより受信され始めた後、例えば、メディアデータのサポートされた及び／又は使用可能な除去モードが変更された場合に、メッセージが受信されてもよい。
その後、クライアントデバイスが、メッセージからモードのタイプを識別する（ステップ７１０）。例えば、ステップ７１０において、クライアントデバイスは、受信したメッセージに示されたモードに関する情報から、バッファからのデータ除去のために用いるモードを識別する。前記モードとしては、クライアントデバイスが完全なＭＰＵを除去可能なモード、クライアントデバイスが完全なムービーフラグメントを除去可能なモード、クライアントデバイスが完全なＭＦＵを除去可能なモードが含まれてもよい。クライアントデバイス（例えば、制御部３４０）は、バッファのオーバーフロー又はアンダーフローを防ぐために、メッセージ内に示されたモードのうち、最大要求バッファサイズを有するモードのタイプを選択できる。
クライアントデバイスは、初期遅延を算出する（ステップ７１５）。例えば、ステップ７１５において、クライアントデバイスは、選択されたモード及びデータの送信パラメータ（例えば、バッファからデータの除去を始めるために、完全なＭＰＵ、ＭＦＵ、ムービーフラグメントが十分に受信されるまでの時間）に基づいて、初期遅延を算出できる。また、クライアントデバイスは、除去レートを算出する（ステップ７２０）。例えば、ステップ７２０において、クライアントデバイスは、選択されたモード及びデータの送信パラメータ（例えば、完全なＭＰＵ、ＭＦＵ、又はムービーフラグメントが受信されて新たに構築されるレート、及び提示、例えば、リアルタイム表示、録画などの要件）に基づいて、除去レートを算出できる。クライアントデバイスは、バッファからデータを除去する前の初期遅延及び除去レートの両方を算出してもよい。
この後、クライアントデバイスは、バッファからデータを除去し、再構成されたデータを、上位階層に送信する（ステップ７２５）。例えば、ステップ７２５において、クライアントデバイスは、識別されたモードのタイプに基づいて、データを除去（例えば、完全なＭＰＵ、ＭＦＵ、又はムービーフラグメントを除去）できる。クライアントデバイスは、再構成されたデータを、ディスプレイ上でユーザに提示するために、提示階層のような上位階層に送信する。
図８は、本開示により、サーバによるデータ除去管理を指示するための例示的プロセスのフローチャートである。例えば、図８に示されたプロセスは、図４の送信エンティティ４０５により実行できる。このプロセスは、図２のサーバ２００によっても実現できる。
このプロセスは、サーバが受信データの除去のための多数のモードに関する情報を含むメッセージを生成することから始まる（ステップ８０５）。例えば、ステップ８０５において、上記のメッセージは、クライアントデバイスにあるバッファからメディアデータの除去に関する管理情報を含んでもよい。サーバは、例えば、多数の使用可能な及び／又はサポートされたモードの各々について、データの除去のためのモードのタイプを示す情報を含んでもよい。また、サーバは、バッファの最大要求サイズを示す情報を、メッセージ内に含める。
その後、サーバは、上記のメッセージをクライアントデバイスに送信する（ステップ８１０）。例えば、ステップ８１０において、サーバは、上記のメッセージをクライアントデバイスに送信して、クライアントデバイスのＭＭＴＰデカプセル化バッファからのデータ除去の動作及び管理をシグナルする。これらの例において、サーバは、メディアデータをクライアントデバイスに送信サーバと同一であってもよいし、異なっていてもよい。
図７及び図８は、クライアントデバイスにより受信されたデータを管理し、サーバによりデータ除去管理を指示するプロセスの例を各々示しているが、図７と図８に様々な変更が行われてもよい。例えば、一連のステップが示されているが、各々の図面において、様々なステップが重複されるか、並行に発生するか、異なる順に起きるか、複数回発生してもよい。
本開示は、例示的な実施形態により記述されたが、様々な変更及び修正が可能であることは、当業者には明らかである。本開示は、添付の特許請求の範囲内で、そのような変更及び修正を含むことができる。
本出願の内容は、特定の要素、ステップ、又は機能が、特許請求の範囲に含まれるべき必須の要素を意味すると取られるべきである。特許内容の範囲は、専ら請求項により限定されるだけである。また、請求項のうちのいずれも、正確な単語「〜の手段」の後に分詞が続かなければ、35 USC §112（ｆ）を行使するようになっていない。
１００ 通信システム
１０２ ネットワーク
１０４、２００ サーバ
１０６、１０８、１１０、１１２、１１４、１１５ クライアントデバイス
１１６ 基地局
２０５ バスシステム
２１０ 制御部
２１５ 格納装置
２２０ 通信部
２２５ 入出力ユニット
２３０ メモリ
２３５ 永続性記憶部
３００ クライアントデバイス
３０５ アンテナ
３１０ 送受信部
３１５ 送信（ＴＸ）処理回路
３２０ マイクロフォン
３２５ 受信（ＲＸ）処理回路
３３０ スピーカー
３４０ 制御部
３４５ 入出力（Ｉ／Ｏ）インターフェース（ＩＦ）
３５０ キーパッド
３５５ ディスプレイ
３６０ メモリ
３６１ オペレーティングシステム
３６３ アプリケーション
４０５ 送信エンティティ
４１０ 受信エンティティ
５００ 受信部バッファモデル
５０５ ＦＥＣデコーディングバッファ
５１０ デジッタバッファ
５１５ ＭＭＴＰデカプセル化バッファ

Claims (20)

  1. クライアントデバイスにより受信データを管理する方法において、
    前記クライアントデバイスにあるバッファから、データを除去するための多数のモードに関する情報を含むメッセージを受信するステップと、
    前記多数のモードのうち、最大要求バッファサイズを有するモードを識別するステップと、
    前記識別されたモードに基づいて、前記バッファから前記データを除去するステップと、
    を含む方法。
  2. 前記識別されたモードに基づいて、前記バッファから前記データを除去するステップは、
    前記バッファからデータの除去を始める前に初期遅延を算出するステップと、
    前記バッファから前記データを除去するレートを算出するステップと、
    を含む、請求項１に記載の方法。
  3. 前記モードは、前記クライアントデバイスが完全なＭＰＵ（Moving Picture Experts Group（MPEG）media transport（MMT）processing units）を除去するモード、前記クライアントデバイスが完全なムービーフラグメントを除去するモード、及び前記クライアントデバイスがＭＦＵ（MMT fragmentation units）を除去するモードを含む、請求項１に記載の方法。
  4. 前記メッセージは、ＨＲＢＭ（hypothetical receiver buffer model）除去メッセージである、請求項１に記載の方法。
  5. 前記バッファは、ＭＭＴＰデカプセル化バッファである、請求項１に記載の方法。
  6. 前記バッファから前記データを除去するステップは、前記データを、ユーザに提示するために伝送するステップを含む、請求項１に記載の方法。
  7. サーバによりデータ除去管理を指示するための方法において、
    クライアントデバイスにあるバッファから受信データの除去のための多数のモードに関する情報であって、前記モードの各々についてデータの除去のためのモードのタイプを示す情報を含むメッセージを生成するステップと、
    前記メッセージを、前記クライアントデバイスに送信するステップと、
    を含む、方法。
  8. 前記モードは、前記クライアントデバイスが完全なＭＰＵ（Moving Picture Experts Group（MPEG）media transport（MMT）processing units）を除去するモード、前記クライアントデバイスが完全なムービーフラグメントを除去するモード、及び前記クライアントデバイスがＭＦＵ（MMT fragmentation units）を除去するモードを含む、請求項７に記載の方法。
  9. 前記メッセージ内の前記情報は、バッファの最大要求サイズをさらに示す、請求項７に記載の方法。
  10. 前記メッセージは、ＨＲＢＭ（hypothetical receiver buffer model）除去メッセージである、請求項７に記載の方法。
  11. 受信データを管理するためのクライアントデバイス内の装置において、
    データを少なくとも一時的に格納するように構成されたバッファを備えるメモリと、
    前記クライアントデバイスにあるバッファからデータを除去するための多数のモードに関する情報を含むメッセージを受信するように構成された受信部と、
    前記多数のモードのうち、最大要求バッファサイズを有するモードを識別し、前記識別されたモードに基づいて、前記バッファからデータを除去するように構成される制御部と、
    を含む、装置。
  12. 前記制御部は、前記バッファからデータの除去を始める前の初期遅延を算出し、前記バッファからデータを除去するレートを算出するようにさらに構成される、請求項１１に記載の装置。
  13. 前記モードは、前記クライアントデバイスが完全なＭＰＵ（Moving Picture Experts Group（MPEG）media transport（MMT）processing units）を除去するモード、前記クライアントデバイスが完全なムービーフラグメントを除去するモード、及び前記クライアントデバイスがＭＦＵ（MMT fragmentation units）を除去するモードを含む、請求項１１に記載の装置。
  14. 前記メッセージは、ＨＲＢＭ（hypothetical receiver buffer model）除去メッセージである、請求項１１に記載の装置。
  15. 前記バッファは、ＭＭＴＰデカプセル化バッファである、請求項１１に記載の装置。
  16. 前記制御部は、ユーザに提示するために、前記バッファからデータを伝送するようにさらに構成される、請求項１１に記載の装置。
  17. データ除去管理を指示するための装置において、
    クライアントデバイスにあるバッファから、受信データの除去のための多数のモードに関する情報を含むメッセージを生成するように構成され、前記情報は、前記モードの各々について、データの除去のためのモードのタイプを示す制御部と、
    前記メッセージを、前記クライアントデバイスに送信するように構成された送信部と、
    を含む、装置。
  18. 前記モードは、前記クライアントデバイスが完全なＭＰＵ（Moving Picture Experts Group（MPEG）media transport（MMT）processing units）を除去するモード、前記クライアントデバイスが完全なムービーフラグメントを除去するモード、及び前記クライアントデバイスがＭＦＵ（MMT fragmentation units）を除去するモードを含む、請求項１７に記載の装置。
  19. 前記メッセージ内の前記情報は、バッファの最大要求サイズをさらに示す、 請求項１７に記載の装置。
  20. 前記メッセージは、ＨＲＢＭ（hypothetical receiver buffer model）除去メッセージである、請求項１７に記載の装置。
JP2016559580A 2014-03-31 2015-03-31 Ｍｍｔｐデカプセル化バッファのシグナリング及び動作 Active JP6516767B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201461973092P 2014-03-31 2014-03-31
US61/973,092 2014-03-31
US14/596,796 US10887651B2 (en) 2014-03-31 2015-01-14 Signaling and operation of an MMTP de-capsulation buffer
US14/596,796 2015-01-14
PCT/KR2015/003151 WO2015152599A2 (en) 2014-03-31 2015-03-31 Signaling and operation of an mmtp de-capsulation buffer

Publications (2)

Publication Number Publication Date
JP2017518656A JP2017518656A (ja) 2017-07-06
JP6516767B2 true JP6516767B2 (ja) 2019-05-22

Family

ID=54192265

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016559580A Active JP6516767B2 (ja) 2014-03-31 2015-03-31 Ｍｍｔｐデカプセル化バッファのシグナリング及び動作

Country Status (6)

Country Link
US (1) US10887651B2 (ja)
EP (1) EP3127287B1 (ja)
JP (1) JP6516767B2 (ja)
KR (1) KR102306352B1 (ja)
CN (1) CN109076025B (ja)
WO (1) WO2015152599A2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111884955B (zh) * 2014-12-04 2023-07-18 索尼公司 数据处理设备、数据处理方法及程序
US10116576B2 (en) 2015-10-19 2018-10-30 Samsung Electronics Co., Ltd. Methods and apparatus for random access of HEVC bitstream for MMT
US10148582B2 (en) * 2016-05-24 2018-12-04 Samsung Electronics Co., Ltd. Managing buffers for rate pacing
KR102532645B1 (ko) * 2016-09-20 2023-05-15 삼성전자 주식회사 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치
KR102391799B1 (ko) 2017-10-19 2022-04-29 삼성전자주식회사 유니캐스트　기반 멀티미디어 서비스 방법 및 장치
TWI646794B (zh) * 2018-02-01 2019-01-01 晨星半導體股份有限公司 符合數位電視廣播標準之信號接收裝置及其信號處理方法
CN110267062B (zh) * 2019-07-26 2022-07-08 深圳Tcl新技术有限公司 拼装视频帧的优化方法、装置及可读存储介质
WO2023022578A1 (ko) * 2021-08-20 2023-02-23 엘지전자 주식회사 영상 신호 처리 방법 및 장치

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000316027A (ja) * 1999-04-28 2000-11-14 Sony Corp 情報処理装置および方法、並びに提供媒体
GB0013273D0 (en) * 2000-06-01 2000-07-26 Philips Electronics Nv Video signal encoding and buffer management
US7061942B2 (en) * 2002-05-31 2006-06-13 Skystream Networks Inc. Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
US20050201471A1 (en) * 2004-02-13 2005-09-15 Nokia Corporation Picture decoding method
US9380091B2 (en) * 2012-06-12 2016-06-28 Wi-Lan Labs, Inc. Systems and methods for using client-side video buffer occupancy for enhanced quality of experience in a communication network
JP4740356B2 (ja) 2009-06-30 2011-08-03 富士通株式会社 メディア配信切替え方法、受信装置、送信装置
US9319721B2 (en) * 2011-10-13 2016-04-19 Electronics And Telecommunications Research Institute Method of configuring and transmitting an MMT transport packet
US8695047B2 (en) * 2011-11-08 2014-04-08 Qualcomm Incorporated Video stream protection
KR101995221B1 (ko) 2011-11-24 2019-07-16 삼성전자주식회사 통신 시스템에서 패킷 송수신 장치 및 방법
KR20130058648A (ko) 2011-11-25 2013-06-04 (주)휴맥스 Mmt 미디어와 dash 미디어와의 연동 방법
KR20130078643A (ko) * 2011-12-30 2013-07-10 한국전자통신연구원 Ｍｍｔ 복합 전달 서비스에서 ｍｍｔ 패킷 스트림 동기화를 위한 ｍｍｔ 제어 계층 시그널링을 이용한 타이밍 정보 제공 방법 및 ｍｍｔ 패킷 스트림 동기화 방법
KR20130108198A (ko) * 2012-03-23 2013-10-02 (주)휴맥스 Ｍｍｔ 패키지화된 ｓｖｃ 비디오 콘텐츠의 하이브리드 전송 방법 및 수신 방법
EP2873243A1 (en) * 2012-06-29 2015-05-20 VID SCALE, Inc. Frame prioritization based on prediction information
CN104471913B (zh) 2012-07-13 2017-12-05 华为技术有限公司 指示和处理内容传输和传送中的内容加密和权限管理
JP6652320B2 (ja) * 2013-12-16 2020-02-19 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置及び受信装置

Also Published As

Publication number Publication date
EP3127287A2 (en) 2017-02-08
US10887651B2 (en) 2021-01-05
CN109076025A (zh) 2018-12-21
JP2017518656A (ja) 2017-07-06
CN109076025B (zh) 2022-06-28
EP3127287A4 (en) 2018-02-28
WO2015152599A3 (en) 2017-05-04
KR102306352B1 (ko) 2021-10-01
US20150281770A1 (en) 2015-10-01
WO2015152599A2 (en) 2015-10-08
EP3127287B1 (en) 2021-09-15
KR20160140873A (ko) 2016-12-07

Similar Documents

Publication Publication Date Title
JP6516767B2 (ja) Ｍｍｔｐデカプセル化バッファのシグナリング及び動作
US11381622B2 (en) Method and apparatus for media data delivery control
JP6744458B2 (ja) メディアデータに関する情報を送信する方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171121

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180730

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180828

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181105

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190409

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190416

R150 Certificate of patent or registration of utility model

Ref document number: 6516767

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250