JP2024502822A - ビジュアルボリュメトリックビデオベース（ｖ３ｃ）及びジオメトリベース点群（ｇ－ｐｃｃ）メディアのストリーミングのためのｍｍｔシグナリング - Google Patents

ビジュアルボリュメトリックビデオベース（ｖ３ｃ）及びジオメトリベース点群（ｇ－ｐｃｃ）メディアのストリーミングのためのｍｍｔシグナリング Download PDF

Info

Publication number
JP2024502822A
JP2024502822A JP2023540501A JP2023540501A JP2024502822A JP 2024502822 A JP2024502822 A JP 2024502822A JP 2023540501 A JP2023540501 A JP 2023540501A JP 2023540501 A JP2023540501 A JP 2023540501A JP 2024502822 A JP2024502822 A JP 2024502822A
Authority
JP
Japan
Prior art keywords
media
asset
message
receiving device
pcc
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.)
Pending
Application number
JP2023540501A
Other languages
English (en)
Inventor
ハムザ，アハメド
グドゥマス，シュリーニバス
Original Assignee
インターデイジタル パテント ホールディングス インコーポレイテッド
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 インターデイジタル パテント ホールディングス インコーポレイテッド filed Critical インターデイジタル パテント ホールディングス インコーポレイテッド
Publication of JP2024502822A publication Critical patent/JP2024502822A/ja
Pending legal-status Critical Current

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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614—Multiplexing 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136—Incoming video signal characteristics or properties
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation 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/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • A—HUMAN NECESSITIES
    • A63—SPORTS; GAMES; AMUSEMENTS
    • A63F—CARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/80—Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game specially adapted for executing a specific type of game
    • A63F2300/8082—Virtual reality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/001—Model-based coding, e.g. wire frame

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Graphics (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

ビジュアルボリュメトリックビデオベースコーディング（Ｖ３Ｃ）メディア及びジオメトリベース点群コーディング（Ｇ－ＰＣＣ）メディアのストリーミングのための方法、システム、及び装置が本明細書で説明される。受信デバイスにおいて実施される方法は、送信デバイスからストリーミングされるために利用可能なメディアアセットのリストを含む第１のメッセージ、又はメディアアセットをそれぞれ記述する１つ以上のメッセージのうちの１つ以上を受信することを含んでもよい。本方法は、送信デバイスからストリーミングされるべきメディアアセットのサブセットに対する要求を示す第２のメッセージを送信することを更に含んでもよい。メディアアセットの要求されたサブセットは、受信デバイスのビューポートに基づいて決定されてよい。本方法は、モーションピクチャエキスパートグループ（Motion Picture Experts Group）（ＭＰＥＧ）メディアトランスポートプロトコル（Media Transport Protocol）（ＭＭＴＰ）パケットを受信することと、メディアアセットの要求されたサブセットの少なくとも一部分を復元するためにパケットを処理することとを更に含んでよい。【選択図】図１７

Description

（関連出願の相互参照）
本出願は、２０２１年１月５日に出願された米国仮出願第６３／１３４，０３８号及び２０２１年１月５日に出願された米国仮出願第６３／１３４，１４３号の利益を主張し、これらの内容は参照により本明細書に組み込まれる。
現実又は仮想の３Ｄシーンが複数の現実又は仮想カメラによってキャプチャされる没入ビデオコンテンツなどの、高品質の３次元（３Ｄ）点群及び他の視覚的なボリュメトリックメディアが没入型メディアの高度な表現として最近登場した。
３Ｄ点をキャプチャしてレンダリングする技術の最近の進歩は、テレプレゼンス、仮想現実、及び大規模な動的３Ｄマップの分野における新規な用途を可能にし得る。ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１ Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）の３Ｄグラフィックスサブグループは現在、２つの３Ｄ点群圧縮（point cloud compression、ＰＣＣ）規格である、静的点群のためのジオメトリベースの圧縮規格及び動的点群のためのビデオベースの圧縮規格の開発に取り組んでいる。これらの規格の目標は、３Ｄ点群の、効率的で相互運用可能な記憶及び送信をサポートすることであり得る。これらの規格の要件の１つは、点群ジオメトリ座標及び属性の、非可逆コーディング及び／又は可逆コーディングをサポートすることであり得る。ＭＰＥＧ－Ｉ Ｖｉｓｕａｌは、境界付けられたボリューム内の正しい運動視差を有する６ＤｏＦ仮想ウォークスルーをサポートするための没入ビデオコンテンツの圧縮のための規格の開発に取り組んでいる別のＭＰＥＧサブグループである。制限された６自由度（６ＤｏＦ）を有するビデオベースの点群圧縮と没入ビデオの両方が、ビデオコード化されたコンポーネントに依存し得るので、これら２つのタイプの没入メディアのこれらのコーディングは、集合的に、視覚的なボリュメトリックビデオベースのコーディング（Ｖ３Ｃ）と称されてよく、それらのコード化された情報を表すために同じビットストリームフォーマットが使用されてよい。
ビジュアルボリュメトリックビデオベースコーディング（Ｖ３Ｃ）メディア及びジオメトリベース点群コーディング（Ｇ－ＰＣＣ）メディアのストリーミングのための方法、システム、及び装置が本明細書で説明される。受信デバイスにおいて実施される方法は、送信デバイスからストリーミングされるために利用可能なメディアアセットのリストを含む第１のメッセージ、又はメディアアセットをそれぞれ記述する１つ以上のメッセージのうちの１つ以上を受信することを含んでもよい。本方法は、送信デバイスからストリーミングされるべきメディアアセットのサブセットに対する要求を示す第２のメッセージを送信することを更に含んでもよい。メディアアセットの要求されたサブセットは、受信デバイスのビューポートに基づいて決定されてよい。本方法は、モーションピクチャエキスパートグループ（Motion Picture Experts Group）（ＭＰＥＧ）メディアトランスポートプロトコル（Media Transport Protocol）（ＭＭＴＰ）パケットを受信することと、メディアアセットの要求されたサブセットの少なくとも一部分を復元するためにパケットを処理することとを更に含んでよい。
より詳細な理解は、添付の図面と併せて例として与えられる以下の説明から得られ得、図中の同様の参照番号は、同様の要素を示す。
１つ以上の開示された実施形態が実装され得る、例示的な通信システムを示すシステム図である。 一実施形態による、図１Ａに示される通信システム内で使用され得る、例示的な無線送信／受信ユニット（ＷＴＲＵ）を示すシステム図である。 一実施形態による、図１Ａに示される通信システム内で使用され得る、例示的な無線アクセスネットワーク（radio access network、ＲＡＮ）及び例示的なコアネットワーク（core network、ＣＮ）を示すシステム図である。 一実施形態による、図１Ａに示される通信システム内で使用され得る、更なる例示的なＲＡＮ及び更なる例示的なＣＮを示すシステム図である。 ビデオエンコーダの一例を例示する図である。 ビデオエンコーダの一例を例示する図である。 本明細書に記載の様々な態様及び実施形態が実装され得る例示的なシステムの実施例を例示する図である。 サーバとクライアントとの間の例示的なシステムインターフェースを示す図である。 サーバとクライアントとの間の別の例示的なシステムインターフェースを示す図である。 例示的なＶ３Ｃビットストリームの構造を示す図である。 サポートされるＶ３Ｃ属性タイプの例を例示する表である。 ＩＳＯＢＭＦＦ規格に従って実装され得るＶ３Ｃコンテナの例示的な構造を示す図である。 ２つ以上のアトラス及び複数のアトラスタイルを有する例示的なマルチトラックコンテナを示す図である。 ビットストリームの構造の一例を例示する図である。 Ｇ－ＰＣＣ ＴＬＶカプセル化ユニットの例示的なシンタックス構造を提供する表である。 ＴＬＶタイプパラメータの可能な値及び対応する記述を提供する表である。 Ｇ－ＰＣＣ ＴＬＶユニットペイロードの例示的なシンタックス構造を提供する表である。 Ｇ－ＰＣＣジオメトリ情報及び属性情報を提供するビットストリームが単一のトラックに記憶される方式による例示的なサンプル構造を例示する図である。 マルチトラックＩＳＯＢＭＦＦ Ｇ－ＰＣＣコンテナの例示的な構造を示す図である。 ＭＭＴシグナリングが実行されるシステムの例示的なエンドツーエンドアーキテクチャを描く図である。 いくつかの実施形態によるパッケージ構造の例示の図である。 定義されたアプリケーションメッセージタイプのリストを提供する表である。 Ｖ３Ｃアセット記述子の例示的なシンタックス構造を提供する表である。 Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅの例示的なシンタックスを例示する表である。 Ｄａｔａ＿ｔｙｐｅフィールドにおいて使用され得るような例示的なＶ３Ｃデータタイプ値を例示する表である。 Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅの例示的なシンタックスを示す表である。 ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅフィールドの定義を提供する表である。 Ｖ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅの例示的なシンタックスを例示する表である。 Ｇ－ＰＣＣアセット記述子の例示的なシンタックス構造を提供する表である。 定義されたＧ－ＰＣＣアプリケーションメッセージタイプの例を例示する表である。 グループメッセージの例示的なシンタックスを例示する表である。 Ｄａｔａ＿ｔｙｐｅフィールドにおいて使用され得るような例示的なＧ－ＰＣＣデータタイプ値を例示する表である。 ＧＰＣＣ選択フィードバックメッセージの例示的なシンタックスを例示する表である。 ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅフィールドの定義を提供する表である。 Ｇ－ＰＣＣビュー変更フィードバックメッセージ（例えば、「ＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋ」）の例示的なシンタックスを例示する表である。
図１Ａは、１つ以上の開示された実施形態が実装され得る、例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージ伝達、ブロードキャストなどのコンテンツを、複数の無線ユーザに提供する、多重アクセスシステムであり得る。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、上記のようなコンテンツにアクセスすることを可能にし得る。例えば、通信システム１００は、符号分割多重アクセス（code division multiple access、ＣＤＭＡ）、時分割多重アクセス（time division multiple access、ＴＤＭＡ）、周波数分割多重アクセス（frequency division multiple、ＦＤＭＡ）、直交ＦＤＭＡ（orthogonal FDMA、ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（single-carrier FDMA、ＳＣ－ＦＤＭＡ）、ゼロテールユニークワード離散フーリエ変換拡散ＯＦＤＭ（zero-tail unique-word discrete Fourier transform Spread OFDM、ＺＴ－ＵＷ－ＤＦＴ－Ｓ－ＯＦＤＭ）、ユニークワードＯＦＤＭ（unique word OFDM、ＵＷ－ＯＦＤＭ）、リソースブロックフィルタ型ＯＦＤＭ、フィルタバンクマルチキャリア（filter bank multicarrier、ＦＢＭＣ）などの１つ以上のチャネルアクセス方法を用い得る。
図１Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク（ＣＮ）１０６、公衆交換電話ネットワーク（public switched telephone network、ＰＳＴＮ）１０８、インターネット１１０、及び他のネットワーク１１２を含み得るが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、及び／又はネットワーク要素を企図することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作し、かつ／又は通信するように構成された、任意のタイプのデバイスであり得る。例として、いずれもステーション（station、ＳＴＡ）と称され得るＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信及び／又は受信するように構成され得、ユーザ機器（user equipment、ＵＥ）、モバイルステーション、固定又はモバイル加入者ユニット、加入ベースのユニット、ポケットベル、携帯電話、携帯情報端末（personal digital assistant、ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポット又はＭｉ－Ｆｉデバイス、モノのインターネット（Internet of Things、ＩｏＴ）デバイス、時計又は他のウェアラブル、ヘッドマウントディスプレイ（head-mounted display、ＨＭＤ）、車両、ドローン、医療デバイス及び用途（例えば、遠隔手術）、産業デバイス及び用途（例えば、産業及び／又は自動処理チェーンコンテキストで動作するロボット及び／又は他の無線デバイス）、消費者電子デバイス、商業及び／又は産業無線ネットワークで動作するデバイスなどを含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、及び１０２ｄのいずれも、互換的にＵＥと称され得る。
通信システム１００はまた、基地局１１４ａ及び／又は基地局１１４ｂを含み得る。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６、インターネット１１０、及び／又は他のネットワーク１１２などの１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェース接続するように構成された任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、基地トランシーバ局（base transceiver station、ＢＴＳ）、ノードＢ、ｅノードＢ（eNode B、ｅＮＢ）、ホームノードＢ、ホームｅノードＢ、ｇノードＢ（ｇＮＢ）などの次世代ノードＢ、新無線（ＮＲ）ノードＢ、サイトコントローラ、アクセスポイント（access point、ＡＰ）、無線ルータなどであり得る。基地局１１４ａ、１１４ｂは各々単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局及び／又はネットワーク要素を含み得ることが理解されるであろう。
基地局１１４ａは、ＲＡＮ１０４の一部であり得、これはまた、基地局コントローラ（base station controller、ＢＳＣ）、無線ネットワークコントローラ（radio network controller、ＲＮＣ）、リレーノードなどの他の基地局、及び／又はネットワーク要素（図示せず）を含み得る。基地局１１４ａ及び／又は基地局１１４ｂは、セル（図示せず）と称され得る１つ以上のキャリア周波数で無線信号を送信及び／又は受信するように構成され得る。これらの周波数は、認可スペクトル、未認可スペクトル、又は認可及び未認可スペクトルの組み合わせであり得る。セルは、相対的に固定され得るか又は経時的に変化し得る特定の地理的エリアに、無線サービスのカバレッジを提供し得る。セルは、更にセルセクタに分けられ得る。例えば、基地局１１４ａと関連付けられたセルは、３つのセクタに分けられ得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバを、すなわち、セルのセクタごとに１つのトランシーバを含み得る。一実施形態では、基地局１１４ａは、多重入力多重出力（multiple-input multiple output、ＭＩＭＯ）技術を用い得、セルのセクタごとに複数のトランシーバを利用し得る。例えば、ビームフォーミングを使用して、所望の空間方向に信号を送信及び／又は受信し得る。
基地局１１４ａ、１１４ｂは、エアインターフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つ以上と通信し得るが、このエアインターフェース１１６は、任意の好適な無線通信リンク（例えば、無線周波数（radio frequency、ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（infrared、ＩＲ）、紫外線（ultraviolet、ＵＶ）、可視光など）であり得る。エアインターフェース１１６は、任意の好適な無線アクセス技術（radio access technology、ＲＡＴ）を使用して確立され得る。
より具体的には、上記のように、通信システム１００は、多重アクセスシステムであり得、例えば、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの、１つ以上のチャネルアクセススキームを用い得る。例えば、ＲＡＮ１０４及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの基地局１１４ａは、広帯域ＣＤＭＡ（wideband CDMA、ＷＣＤＭＡ）を使用してエアインターフェース１１６を確立し得る、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System、ＵＭＴＳ）地上無線アクセス（Terrestrial Radio Access、ＵＴＲＡ）などの無線技術を実装し得る。ＷＣＤＭＡは、高速パケットアクセス（High-Speed Packet Access、ＨＳＰＡ）及び／又は進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンク（Downlink、ＤＬ）パケットアクセス（High-Speed Downlink Packet Access、ＨＳＤＰＡ）及び／又は高速アップリンク（Uplink、ＵＬ）パケットアクセス（High-Speed Uplink Packet Access、ＨＳＵＰＡ）を含み得る。
一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＭＴＳ地上無線アクセス（Evolved UMTS Terrestrial Radio Access、Ｅ－ＵＴＲＡ）などの無線技術を実装し得、これは、ロングタームエボリューション（Long Term Evolution、ＬＴＥ）及び／又はＬＴＥ－Ａｄｖａｎｃｅｄ（LTE-Advanced、ＬＴＥ－Ａ）及び／又はＬＴＥ－Ａｄｖａｎｃｅｄ Ｐｒｏ（ＬＴＥ－Ａ Ｐｒｏ）を使用してエアインターフェース１１６を確立し得る。
一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＮＲ無線アクセスなどの無線技術を実装し得、これは、ＮＲを使用してエアインターフェース１１６を確立し得る。
一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装し得る。例えば、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、デュアルコネクティビティ（dual connectivity、ＤＣ）原理を使用して、ＬＴＥ無線アクセス及びＮＲ無線アクセスを一緒に実装し得る。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数のタイプの基地局（例えば、ｅＮＢ及びｇＮＢ）に／から送信される複数のタイプの無線アクセス技術及び／又は送信によって特徴付けられ得る。
他の実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、無線フィデリティ（Wireless Fidelity、ＷｉＦｉ）、ＩＥＥＥ８０２．１６（すなわち、ワイマックス（Worldwide Interoperability for Microwave Access、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定規格２０００（ＩＳ－２０００）、暫定規格９５（ＩＳ－９５）、暫定規格８５６（ＩＳ－８５６）、汎欧州デジタル移動電話方式（Global System for Mobile communications、ＧＳＭ）、ＧＳＭ進化型高速データレート（Enhanced Data rates for GSM Evolution、ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装し得る。
図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅノードＢ又はアクセスポイントであり得、事業所、家庭、車両、キャンパス、工業施設、（例えば、ドローンによる使用のための）空中回廊、道路などの場所などの局所的エリアにおける無線接続を容易にするために、任意の好適なＲＡＴを利用し得る。一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（wireless local area network、ＷＬＡＮ）を確立し得る。一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（wireless personal area network、ＷＰＡＮ）を確立し得る。更に別の一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、ＮＲなど）を利用して、ピコセル又はフェムトセルを確立し得る。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスする必要がない場合がある。
ＲＡＮ１０４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つ以上に、音声、データ、アプリケーション、及び／又はボイスオーバインターネットプロトコル（voice over internet protocol、ＶｏＩＰ）サービスを提供するように構成された任意のタイプのネットワークであり得る、ＣＮ１０６と通信し得る。データは、例えば、異なるスループット要件、待ち時間要件、エラー許容要件、信頼性要件、データスループット要件、モビリティ要件などの、様々なサービス品質（quality of service、ＱｏＳ）要件を有し得る。ＣＮ１０６は、通話制御、ビリングサービス、モバイルロケーションベースのサービス、プリペイド通話、インターネット接続性、映像配信などを提供し、かつ／又はユーザ認証などの高レベルセキュリティ機能を行い得る。図１Ａには示されていないが、ＲＡＮ１０４及び／又はＣＮ１０６は、ＲＡＮ１０４と同じＲＡＴ又は異なるＲＡＴを用いる他のＲＡＮと直接又は間接的に通信し得ることが理解されよう。例えば、ＮＲ無線技術を利用し得るＲＡＮ１０４に接続されることに加えて、ＣＮ１０６はまた、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ－ＵＴＲＡ又はＷｉＦｉ無線技術を用いて別のＲＡＮ（図示せず）と通信し得る。
ＣＮ１０６はまた、ＰＳＴＮ１０８、インターネット１１０、及び／又は他のネットワーク１１２にアクセスするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのゲートウェイとして機能し得る。ＰＳＴＮ１０８は、基本電話サービス（plain old telephone service、ＰＯＴＳ）を提供する公衆交換電話網を含み得る。インターネット１１０は、相互接続されたコンピュータネットワーク及びデバイスのグローバルシステムを含み得るが、これらのネットワーク及びデバイスは、送信制御プロトコル（transmission control protocol、ＴＣＰ）、ユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）、及び／又はＴＣＰ／ＩＰインターネットプロトコルスイートのインターネットプロトコル（internet protocol、ＩＰ）などの、共通通信プロトコルを使用する。ネットワーク１１２は、他のサービスプロバイダによって所有及び／又は運営される、有線及び／又は無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴ又は異なるＲＡＴを用い得る１つ以上のＲＡＮに接続された別のＣＮを含み得る。
通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつか又は全ては、マルチモード能力を含み得る（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含み得る）。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を用い得る基地局１１４ａ、及びＩＥＥＥ８０２無線技術を用い得る基地局１１４ｂと通信するように構成され得る。
図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、とりわけ、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（global positioning system、ＧＰＳ）チップセット１３６、及び／又は他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、一実施形態との一貫性を有したまま、前述の要素の任意の部分的組み合わせを含み得ることが理解されよう。
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array、ＦＰＧＡ）、任意の他のタイプの集積回路（integrated circuit、ＩＣ）、状態機械などであり得る。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、及び／又はＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能性を実行し得る。プロセッサ１１８は、送信／受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｂは、プロセッサ１１８及びトランシーバ１２０を別個のコンポーネントとして示すが、プロセッサ１１８及びトランシーバ１２０は、電子パッケージ又はチップにおいて一緒に統合され得るということが理解されよう。
送信／受信要素１２２は、エアインターフェース１１６を介して基地局（例えば、基地局１１４ａ）に信号を送信するか又は基地局（例えば、基地局１１４ａ）から信号を受信するように構成され得る。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信及び／又は受信するように構成されたアンテナであり得る。一実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ又は可視光信号を送信及び／又は受信するように構成されたエミッタ／検出器であり得る。更に別の実施形態では、送信／受信要素１２２は、ＲＦ信号及び光信号の両方を送信及び／又は受信するように構成され得る。送信／受信要素１２２は、無線信号の任意の組み合わせを送信及び／又は受信するように構成され得るということが理解されよう。
送信／受信要素１２２は、単一の要素として図１Ｂに示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含み得る。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を用い得る。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６を介して無線信号を送受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含み得る。
トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成され得る。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有し得る。したがって、トランシーバ１２０は、例えばＮＲ及びＩＥＥＥ８０２．１１などの複数のＲＡＴを介してＷＴＲＵ１０２が通信することを可能にするための複数のトランシーバを含み得る。
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（liquid crystal display、ＬＣＤ）表示ユニット若しくは有機発光ダイオード（organic light-emitting diode、ＯＬＥＤ）表示ユニット）に結合され得、これらからユーザが入力したデータを受信し得る。プロセッサ１１８はまた、ユーザデータをスピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド１２８に出力し得る。加えて、プロセッサ１１８は、非リムーバブルメモリ１３０及び／又はリムーバブルメモリ１３２などの任意のタイプの好適なメモリから情報にアクセスし、かつ当該メモリにデータを記憶し得る。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（random-access memory、ＲＡＭ）、読取り専用メモリ（read-only memory、ＲＯＭ）、ハードディスク又は任意の他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（subscriber identity module、ＳＩＭ）カード、メモリスティック、セキュアデジタル（secure digital、ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ１１８は、サーバ又はホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリから情報にアクセスし、かつ当該メモリにデータを記憶し得る。
プロセッサ１１８は、電源１３４から電力を受信し得るが、ＷＴＲＵ１０２における他のコンポーネントに電力を分配し、かつ／又は制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の好適なデバイスであり得る。例えば、電源１３４は、１つ以上の乾電池（例えば、ニッケルカドミウム（nickel-cadmium、ＮｉＣｄ）、ニッケル亜鉛（nickel-zinc、ＮｉＺｎ）、ニッケル金属水素化物（nickel metal hydride、ＮｉＭＨ）、リチウムイオン（lithium-ion、Ｌｉ－ｉｏｎ）など）、太陽セル、燃料セルなどを含み得る。
プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合され得、これは、ＷＴＲＵ１０２の現在の場所に関する場所情報（例えば、経度及び緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて又はその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６を介して場所情報を受信し、かつ／又は２つ以上の近くの基地局から受信されている信号のタイミングに基づいて、その場所を判定し得る。ＷＴＲＵ１０２は、一実施形態との一貫性を有したまま、任意の好適な位置判定方法によって位置情報を取得し得るということが理解されよう。
プロセッサ１１８は、他の周辺機器１３８に更に結合され得、他の周辺機器１３８には、追加の特徴、機能、及び／又は有線若しくは無線接続を提供する１つ以上のソフトウェア及び／又はハードウェアモジュールが含まれ得る。例えば、周辺機器１３８には、加速度計、電子コンパス、衛星トランシーバ、（写真及び／又はビデオのための）デジタルカメラ、ユニバーサルシリアルバス（universal serial bus、ＵＳＢ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（frequency modulated、ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実及び／又は拡張現実（Virtual Reality/Augmented Reality、ＶＲ／ＡＲ）デバイス、アクティビティトラッカなどが含まれ得る。周辺機器１３８は、１つ以上のセンサを含み得る。センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、配向センサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体認証センサ、湿度センサなどのうちの１つ以上であり得る。
ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬ及び（例えば、受信のための）ＤＬの両方の特定のサブフレームと関連付けられた）信号の一部又は全部の送受信が、同時及び／又は一緒であり得る、全二重無線機を含み得る。全二重無線機は、ハードウェア（例えば、チョーク）又はプロセッサを介した信号処理（例えば、別個のプロセッサ（図示せず）又はプロセッサ１１８を介して）を介して自己干渉を低減し、かつ又は実質的に排除するための干渉管理ユニットを含み得る。一実施形態では、ＷＴＲＵ１０２は、（例えば、（例えば、送信のための）ＵＬ又は（例えば、受信のための）ＤＬのいずれかの特定のサブフレームと関連付けられた）信号の一部又は全部の送受信の半二重無線機を含み得る。
図１Ｃは、一実施形態によるＲＡＮ１０４及びＣＮ１０６を図示するシステム図である。上記のように、ＲＡＮ１０４は、Ｅ－ＵＴＲＡ無線技術を用いて、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１０４はまた、ＣＮ１０６と通信し得る。
ＲＡＮ１０４は、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４は、一実施形態との一貫性を有しながら、任意の数のｅノードＢを含み得るということが理解されよう。ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ以上のトランシーバを含み得る。一実施形態では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装し得る。したがって、ｅノードＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつ／又はＷＴＲＵ１０２ａから無線信号を受信し得る。
ｅノードＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）と関連付けられ得、ＵＬ及び／又はＤＬにおいて、無線リソース管理意思決定、ハンドオーバ意思決定、ユーザのスケジューリングなどを処理するように構成され得る。図１Ｃに示すように、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信し得る。
図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（mobility management entity、ＭＭＥ）１６２、サービングゲートウェイ（serving gateway、ＳＧＷ）１６４、及びパケットデータネットワーク（packet data network、ＰＤＮ）ゲートウェイ（packet data gateway、ＰＧＷ）１６６を含み得る。前述の要素は、ＣＮ１０６の一部として示されているが、これらの要素のうちのいずれかも、ＣＮオペレータ以外のエンティティによって所有及び／又は運営され得ることが理解されよう。
ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４におけるｅノードＢ１６２ａ、１６２ｂ、１６２ｃの各々に接続され得、かつ制御ノードとして機能し得る。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービス中のゲートウェイを選択すること、などの役割を果たし得る。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭ及び／又はＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供し得る。
ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅノード－Ｂ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は、概して、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からルーティングし、転送し得る。ＳＧＷ１６４は、ｅノード－Ｂ間ハンドオーバ中にユーザプレーンをアンカする機能、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能であるときにページングをトリガする機能、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理及び記憶する機能などの、他の機能を実行し得る。
ＳＧＷ１６４は、ＰＧＷ１６６に接続され得、ＰＧＷ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。
ＣＮ１０６は、他のネットワークとの通信を容易にし得る。例えば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上回線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（IP multimedia subsystem、ＩＭＳ）サーバ）を含み得るか、又はそれと通信し得る。加えて、ＣＮ０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに他のネットワーク１１２へのアクセスを提供してもよく、他のネットワーク１１２は、他のサービスプロバイダによって所有される、及び／又は動作される他の有線及び／又は無線ネットワークを含み得る。
ＷＴＲＵは、無線端末として図１Ａ～図１Ｄに記載されているが、特定の代表的な実施形態では、そのような端末は、通信ネットワークとの（例えば、一時的又は永久的に）有線通信インターフェースを使用し得ることが企図される。
代表的な実施形態では、他のネットワーク１１２は、ＷＬＡＮであり得る。
インフラストラクチャ基本サービスセット（Basic Service Set、ＢＳＳ）モードのＷＬＡＮは、ＢＳＳのアクセスポイント（ＡＰ）及びＡＰと関連付けられた１つ以上のステーション（station、ＳＴＡ）を有し得る。ＡＰは、ＢＳＳ内に、かつ／又はＢＳＳ外にトラフィックを搬送する配信システム（Distribution System、ＤＳ）又は別のタイプの有線／無線ネットワークへのアクセス又はインターフェースを有し得る。ＢＳＳ外から生じる、ＳＴＡへのトラフィックは、ＡＰを通って到達し得、ＳＴＡに配信され得る。ＳＴＡからＢＳＳ外の宛先への生じるトラフィックは、ＡＰに送信されて、それぞれの宛先に送信され得る。ＢＳＳ内のＳＴＡどうしの間のトラフィックは、例えば、ＡＰを介して送信され得、ソースＳＴＡは、ＡＰにトラフィックを送信し得、ＡＰは、トラフィックを宛先ＳＴＡに配信し得。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックとして見なされ、かつ／又は称され得る。ピアツーピアトラフィックは、ソースＳＴＡと宛先ＳＴＡとの間で（例えば、それらの間で直接的に）、直接リンクセットアップ（direct link setup、ＤＬＳ）で送信され得る。特定の代表的な実施形態では、ＤＬＳは、８０２．１１ｅ ＤＬＳ又は８０２．１１ｚトンネル化ＤＬＳ（tunneled DLS、ＴＤＬＳ）を使用し得る。独立ＢＳＳ（Independent BSS、ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有しない場合があり、ＩＢＳＳ内又はそれを使用するＳＴＡ（例えば、ＳＴＡの全部）は、互いに直接通信し得る。通信のＩＢＳＳモードは、本明細書では、「アドホック」通信モードと称され得る。
８０２．１１ａｃインフラストラクチャ動作モード又は同様の動作モードを使用するときに、ＡＰは、プライマリチャネルなどの固定チャネル上にビーコンを送信し得る。一次チャネルは、固定幅（例えば、２０ＭＨｚ幅の帯域幅）又は動的に設定された幅であり得る。プライマリチャネルは、ＢＳＳの動作チャネルであり得、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。特定の代表的な実施形態では、衝突回避を用いるキャリア感知多重アクセス（Carrier Sense Multiple Access with Collision Avoidance、ＣＳＭＡ／ＣＡ）は、例えば、８０２．１１システムにおいて実装され得る。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、全てのＳＴＡ）は、プライマリチャネルを感知し得る。プライマリチャネルが特定のＳＴＡによってビジーであると感知され／検出され、かつ／又は判定される場合、特定のＳＴＡはバックオフされ得る。１つのＳＴＡ（例えば、１つのステーションのみ）は、所与のＢＳＳにおいて、任意の所与の時間に送信し得る。
高スループット（High Throughput、ＨＴ）ＳＴＡは、通信のための４０ＭＨｚ幅のチャネルを使用し得るが、この４０ＭＨｚ幅のチャネルは、例えば、プライマリ２０ＭＨｚチャネルと、隣接又は非隣接の２０ＭＨｚチャネルとの組み合わせを介して形成され得る。
非常に高いスループット（Very High Throughput、ＶＨＴ）のＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、及び／又は１６０ＭＨｚ幅のチャネルをサポートし得る。上記の４０ＭＨｚ及び／又は８０ＭＨｚ幅のチャネルは、連続する２０ＭＨｚチャネルどうしを組み合わせることによって形成され得る。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを組み合わせることによって、又は８０＋８０構成と称され得る２つの連続していない８０ＭＨｚチャネルを組み合わせることによって、形成され得る。８０＋８０構成の場合、チャネル符号化後、データは、データを２つのストリームに分割し得るセグメントパーサを通過し得る。逆高速フーリエ変換（Inverse Fast Fourier Transform、ＩＦＦＴ）処理及び時間ドメイン処理は、各ストリームで別々に行われ得る。ストリームは、２つの８０ＭＨｚチャネルにマッピングされ得、データは、送信ＳＴＡによって送信され得る。受信ＳＴＡの受信機では、８０＋８０構成に対する上記で説明される動作は逆にされ得、組み合わされたデータを媒体アクセス制御（Medium Access Control、ＭＡＣ）に送信し得る。
サブ１ＧＨｚの動作モードは、８０２．１１ａｆ及び８０２．１１ａｈによってサポートされる。チャネル動作帯域幅及びキャリアは、８０２．１１ｎ及び８０２．１１ａｃで使用されるものと比較して、８０２．１１ａｆ及び８０２．１１ａｈでは低減される。８０２．１１ａｆは、ＴＶホワイトスペース（TV White Space、ＴＶＷＳ）スペクトルで５ＭＨｚ、１０ＭＨｚ、及び２０ＭＨｚの帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、及び１６ＭＨｚの帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレッジエリアにおけるＭＴＣデバイスなどのメータタイプの制御／マシンタイプ通信（Machine-Type Communications、ＭＴＣ）をサポートし得る。ＭＴＣデバイスは、例えば、特定の、かつ／又は限定された帯域幅のためのサポート（例えば、そのためのみのサポート）を含む、特定の能力を有し得る。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を超えるバッテリ寿命を有するバッテリを含み得る。
複数のチャネル、並びに８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、及び８０２．１１ａｈなどのチャネル帯域幅をサポートし得るＷＬＡＮシステムは、プライマリチャネルとして指定され得るチャネルを含む。プライマリチャネルは、ＢＳＳにおける全てのＳＴＡによってサポートされる最大共通動作帯域幅に等しい帯域幅を有し得る。プライマリチャネルの帯域幅は、最小帯域幅動作モードをサポートするＢＳＳで動作する全てのＳＴＡの中から、ＳＴＡによって設定され、かつ／又は制限され得る。８０２．１１ａｈの例では、プライマリチャネルは、ＡＰ及びＢＳＳにおける他のＳＴＡが２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、及び／又は他のチャネル帯域幅動作モードをサポートする場合であっても、１ＭＨｚモードをサポートする（例えば、それのみをサポートする）ＳＴＡ（例えば、ＭＴＣタイプデバイス）に対して１ＭＨｚ幅であり得る。キャリア感知及び／又はネットワーク配分ベクトル（Network Allocation Vector、ＮＡＶ）設定は、プライマリチャネルの状態に依存し得る。例えば、一次チャネルがビジーである場合、ＡＰに送信する（１ＭＨｚ動作モードのみをサポートする）ＳＴＡにより、利用可能な周波数帯域の大部分がアイドル状態になったとしても、利用可能な周波数帯域の全てがビジーであると見なされ得る。
米国では、８０２．１１ａｈにより使用され得る利用可能な周波数帯域は、９０２ＭＨｚ～９２８ＭＨｚである。韓国では、利用可能な周波数帯域は９１７．５ＭＨｚ～９２３．５ＭＨｚである。日本では、利用可能な周波数帯域は９１６．５ＭＨｚ～９２７．５ＭＨｚである。８０２．１１ａｈに利用可能な総帯域幅は、国のコードに応じて６ＭＨｚ～２６ＭＨｚである。
図１Ｄは、一実施形態によるＲＡＮ１０４及びＣＮ１０６を例示するシステム図である。上記のように、ＲＡＮ１０４は、ＮＲ無線技術を用いて、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１０４はまた、ＣＮ１０６と通信し得る。
ＲＡＮ１０４は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１０４は、一実施形態との一貫性を維持しながら、任意の数のｇＮＢを含み得ることが理解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ以上のトランシーバを含み得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装し得る。例えば、ｇＮＢ１８０ａ、１０８ｂは、ビームフォーミングを利用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信及び／又は受信し得る。したがって、ｇＮＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつ／又はＷＴＲＵ１０２ａから無線信号を受信し得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装し得る。例えば、ｇＮＢ１８０ａは、複数のコンポーネントキャリアをＷＴＲＵ１０２ａ（図示せず）に送信し得る。これらのコンポーネントキャリアのサブセットは、未認可スペクトル上にあり得、残りのコンポーネントキャリアは、認可スペクトル上にあり得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、協調マルチポイント（Coordinated Multi-Point、ＣｏＭＰ）技術を実装し得る。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａ及びｇＮＢ１８０ｂ（及び／又はｇＮＢ１８０ｃ）からの協調送信を受信し得る。
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、拡張可能なヌメロロジと関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。例えば、ＯＦＤＭシンボル間隔及び／又はＯＦＤＭサブキャリア間隔は、無線送信スペクトルの異なる送信、異なるセル、及び／又は異なる部分に対して変化し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、様々な若しくは拡張可能な長さのサブフレーム又は送信時間間隔（transmission time interval、ＴＴＩ）を使用して（例えば、様々な数のＯＦＤＭシンボル及び／又は様々な長さの絶対時間の持続し変化する時間を含む）、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成及び／又は非スタンドアロン構成でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなど）にアクセスすることなく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、モビリティアンカポイントとしてｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つ以上を利用し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、未認可バンドにおける信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し、これらに接続する一方で、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信し、これらに接続し得る。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、１つ以上のｇＮＢ１８０ａ、１８０ｂ、１８０ｃ及び１つ以上のｅノードＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信するためのＤＣ原理を実装し得る。非スタンドアロン構成では、ｅノードＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティアンカとして機能し得るが、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃをサービス提供するための追加のカバレッジ及び／又はスループットを提供し得る。
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）に関連付けられ得、無線リソース管理決定、ハンドオーバ決定、ＵＬ及び／又はＤＬにおけるユーザのスケジューリング、ネットワークスライスのサポート、ＤＣ、ＮＲとＥ－ＵＴＲＡとの間の相互作用、ユーザプレーン機能（User Plane Function、ＵＰＦ）１８４ａ、１８４ｂに対するユーザプレーンデータのルーティング、アクセス及びモビリティ管理機能（Access and Mobility Management Function、ＡＭＦ）１８２ａ、１８２ｂに対する制御プレーン情報のルーティングなどを処理するように構成され得る。図１Ｄに示すように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いに通信し得る。
図１Ｄに示されるＣＮ１０６は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（Session Management Function、ＳＭＦ）１８３ａ、１８３ｂ、及び場合によってはデータネットワーク（Data Network、ＤＮ）１８５ａ、１８５ｂを含み得る。前述の要素は、ＣＮ１０６の一部として示されているが、これらの要素のうちのいずれかも、ＣＮオペレータ以外のエンティティによって所有及び／又は運営され得ることが理解されよう。
ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１０４におけるｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つ以上に接続されてよく、制御ノードとして機能し得る。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザ認証、ネットワークスライスのためのサポート（例えば、異なる要件を有する異なるプロトコルデータユニット（protocol data unit、ＰＤＵ）セッションの処理）、登録のＳＭＦ１８３ａ、１８３ｂの選択、登録エリアの管理、非アクセス層（non-access stratum、ＮＡＳ）信号伝達の終了、モビリティ管理などの役割を果たし得る。ネットワークスライスは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃを利用しているサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。例えば、異なるネットワークスライスは、超高信頼低レイテンシ（ultra-reliable low latency、ＵＲＬＬＣ）アクセスに依存するサービス、拡張大規模モバイルブロードバンド（enhanced massive mobile broadband、ｅＭＢＢ）アクセスに依存するサービス、ＭＴＣアクセスのためのサービスなどのような、異なる使用事例に対して確立され得る。ＡＭＦ１８２ａ、１８２ｂは、ＲＡＮ１０４と、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、及び／又はＷｉＦｉなどの非－３ＧＰＰアクセス技術などの他の無線技術を用いる他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供し得る。
ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介して、ＣＮ１０６内のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介して、ＣＮ１０６内のＵＰＦ１８４ａ、１８４ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択及び制御し、ＵＰＦ１８４ａ、１８４ｂを通るトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＥ ＩＰアドレスを管理及び配分する機能、ＰＤＵセッションを管理する機能、ポリシー実施及びＱｏＳを制御する機能、ＤＬデータ通知を提供する機能などのような、他の機能を実行し得る。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、イーサネットベースなどであり得る。
ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介して、ＲＡＮ１０４内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つ以上に接続されてよく、これにより、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。ＵＰＦ１８４、１８４ｂは、パケットのルーティング及び転送、ユーザプレーンポリシーの実施、マルチホームＰＤＵセッションのサポート、ユーザプレーンＱｏＳの処理、ＤＬパケットのバッファリング、モビリティアンカリングなどの他の機能を実行し得る。
ＣＮ１０６は、他のネットワークとの通信を容易にし得る。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（IP multimedia subsystem、ＩＭＳ）サーバ）を含み得るか、又はそれと通信し得る。加えて、ＣＮ０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに他のネットワーク１１２へのアクセスを提供してもよく、他のネットワーク１１２は、他のサービスプロバイダによって所有される、及び／又は動作される他の有線及び／又は無線ネットワークを含み得る。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェース及びＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通じて、ローカルＤＮ１８５ａ、１８５ｂに接続され得る。
図１Ａ～図１Ｄ及び図１Ａ～図１Ｄの対応する説明を考慮して、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、ｅノードＢ１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ、及び／又は本明細書に記載される任意の他のデバイスの１つ以上に関して本明細書に記載される機能のうちの１つ以上又は全部は、１つ以上のエミュレーションデバイス（図示せず）によって行われ得る（図示せず）。エミュレーションデバイスは、本明細書に説明される機能の１つ以上又は全てをエミュレートするように構成された１つ以上のデバイスであり得る。例えば、エミュレーションデバイスを使用して、他のデバイスを試験し、かつ／又はネットワーク及び／若しくはＷＴＲＵ機能をシミュレートし得る。
エミュレーションデバイスは、ラボ環境及び／又はオペレータネットワーク環境における他のデバイスの１つ以上の試験を実装するように設計され得る。例えば、１つ以上のエミュレーションデバイスは、通信ネットワーク内の他のデバイスを試験するために、有線及び／又は無線通信ネットワークの一部として完全に若しくは部分的に実装され、かつ／又は展開されている間、１つ以上若しくは全ての機能を実行し得る。１つ以上のエミュレーションデバイスは、有線及び／又は無線通信ネットワークの一部として一時的に実装／展開されている間、１つ以上若しくは全ての機能を実行し得る。エミュレーションデバイスは、オーバザエアの無線通信を使用して、試験する及び／又は試験を行う目的で、別のデバイスに直接結合され得る。
１つ以上のエミュレーションデバイスは、有線及び／又は無線通信ネットワークの一部として実装／展開されていない間、全てを含む１つ以上の機能を実行し得る。例えば、エミュレーションデバイスは、１つ以上のコンポーネントの試験を実装するために、試験実験室での試験シナリオ、並びに／又は展開されていない（例えば、試験用の）有線及び／若しくは無線通信ネットワークにおいて利用され得る。１つ以上のエミュレーションデバイスは、試験機器であり得る。ＲＦ回路（例えば、１つ以上のアンテナを含み得る）を介した直接ＲＦ結合及び／又は無線通信は、データを送信及び／又は受信するように、エミュレーションデバイスによって使用され得る。
本出願に記載の様々な方法及び他の態様は、図２及び図３に示すように、例えば、ビデオエンコーダ２００及びデコーダ３００のモジュールを修正するために使用され得る。更に、本明細書で開示される主題は、Ｖ３Ｃ、Ｇ－ＰＣＣに限定されない態様を提示し、例えば、規格又は勧告に記載されているかどうかにかかわらず、既存であるか又は将来開発されるかどうかにかかわらず、ビデオコーディングの任意のタイプ、形式、又はバージョン、並びに任意のかかる規格及び勧告（例えば、Ｖ３Ｃ及びＧ－ＰＣＣを含む）の拡張に適用され得る。別段の指示がない限り、又は技術的に除外されない限り、本出願に記載の態様は、個々に又は組み合わせて使用され得る。
本出願で説明する例では、Ｖ３Ｃアプリケーションメッセージ又はＧ－ＰＣＣアプリケーションメッセージのフィールドのために予約されたビット数など、様々な数値が使用される。これら及び他の特定の値は、例を説明する目的であり、説明される態様は、これらの特定の値に限定されない。
図２は、ビデオエンコーダの一例を示す図である。例示的なエンコーダ２００の変形形態が企図されるが、エンコーダ２００は、全ての予想される変形形態を説明することなく、明確にする目的で以下に記載される。
符号化される前に、ビデオシーケンスは、符号化前処理（２０１）、例えば、カラー変換を入力カラーピクチャに適用すること（例えば、ＲＧＢ４：４：４からＹＣｂＣｒ４：２：０への変換）、又は圧縮に対してより弾力的な信号分布を得るために入力ピクチャ成分の再マッピングを実行する（例えば、色成分のうちの１つのヒストグラム等化を使用して）ことを経得る。メタデータは前処理に関連付けられてもよく、そのようなメタデータはビットストリームに添付されてもよい。
エンコーダ２００では、以下に記載されるように、ピクチャは、エンコーダ要素によって符号化されてもよい。符号化されるべきピクチャは、分割され（２０２）、例えば、コーディングユニット（coding unit、ＣＵ）の単位で処理されてもよい。各ユニットは、例えば、イントラモード又はインターモードのいずれかを使用して符号化されてよい。ユニットがイントラモードで符号化されると、ユニットはイントラ予測を実行し（２６０）、インターモードでは、動き推定（２７５）及び動き補償（２７０）が実行される。エンコーダは、ユニットを符号化するためにイントラモード又はインターモードのうちのどちらを使用すべきかを決定してよく（２０５）、例えば、予測モードフラグによってイントラ／インターの決定を示す。予測残差は、例えば、元の画像ブロックから予測されたブロックを減算することによって（２１０）計算されてよい。
次いで、予測残差が変換され（２２５）、量子化されてよい（２３０）。量子化された変換係数、並びに動きベクトル及び他のシンタックス要素は、ビットストリームを出力するためにエントロピーコード化されてよい（２４５）。エンコーダは、変換をスキップし、量子化を非変換残差信号に直接適用し得る。エンコーダは、変換及び量子化の両方をバイパスすることができ、すなわち、残差は、変換プロセス又は量子化プロセスを適用することなく直接コード化される。
エンコーダは、符号化されたブロックを復号化して、更なる予測のための参照を提供する。量子化された変換係数は、予測残差を復号化するために逆量子化され（２４０）、逆変換される（２５０）。復号化された予測残差と予測ブロックとを組み合わせる（２５５）と、画像ブロックが再構成される。再構築されたピクチャには、符号化アーチファクトを低減するために、例えば、デブロッキング／ＳＡＯ（サンプル適応オフセット）フィルタリングを実行するために、ｌｎループフィルタ（２６５）が適用される。フィルタリングされた画像は、参照ピクチャバッファ（２８０）に記憶される。
図３は、ビデオデコーダの実施例を示す図である。例示的なデコーダ３００では、ビットストリームは、以下に記載されるようにデコーダ要素によって復号化され、ビデオデコーダ３００は、一般に、図２に記載されるように符号化パスと逆の復号化されたパスを実行する。エンコーダ２００はまた、一般に、ビデオデータの符号化の一部としてビデオ復号化を実行する。特に、デコーダの入力は、ビデオエンコーダ２００によって生成され得るビデオビットストリームを含んでよい。ビットストリームは、変換係数、動きベクトル、及びその他のコード化された情報を取得するために、まずエントロピー復号化されてよい（３３０）。ピクチャ分割情報は、ピクチャがどのように分割されるかを示し、したがって、デコーダは、復号化されたピクチャ分割情報に従ってピクチャを分けてよい（３３５）。変換係数は、予測残差を復号化するために、逆量子化され（３４０）、逆変換される（３５０）。復号化された予測残差と予測ブロックとを組み合わせ（３５５）、画像ブロックが再構成され、予測ブロックは、イントラ予測（３６０）又は動き補償予測（すなわち、インター予測）（３７５）から取得され得る（３７０）。ループ内フィルタ（３６５）は、再構成された画像に適用される。フィルタリングされた画像は、参照ピクチャバッファ（３８０）に記憶される。
復号化されたピクチャは、復号化後処理（３８５）、例えば、逆カラー変換（例えば、ＹＣｂＣｒ４：２：０からＲＧＢ４：４：４への変換）、又は符号化前処理（２０１）において実行された再マッピングプロセスの逆を実行する逆再マッピングを更に経ることができる。復号化後処理は、符号化前処理において導出され、ビットストリームにおいてシグナリングされたメタデータを使用し得る。
図４は、本明細書に記載の様々な態様及び実施形態が実装され得るシステムの実施例を示す図である。システム４００は、以下に説明する様々なコンポーネントを含むデバイスとして具現化されてよく、本明細書に記載される態様のうちの１つ以上を実行するように構成されてよい。そのようなデバイスの例には、パーソナルコンピュータ、ラップトップコンピュータ、スマートフォン、タブレットコンピュータ、デジタルマルチメディアセットトップボックス、デジタルテレビ受信機、パーソナルビデオ記録システム、接続された家電製品、及びサーバなどの様々な電子デバイスが含まれるが、これらに限定されない。システム４００の要素は、単独で又は組み合わせて、単一の集積回路（ＩＧ）、複数のＩＣ、及び／又は個別のコンポーネントで具体化されてもよい。例えば、少なくとも１つの例では、システム４００の処理及びエンコーダ／デコーダ要素は、複数のＩＣ及び／又は個別のコンポーネントに分散され、様々な実施形態では、システム４００は、例えば通信バスを介して、又は専用の入力及び／又は出力ポートを介して、１つ以上の他のシステム、又は他の電子デバイスに通信可能に結合される。様々な実施形態では、システム４００は、本明細書に記載される態様のうちの１つ以上を実装するように構成されている。
システム４００は、例えば、この文書に記載された様々な態様を実施するためにその中にロードされた命令を実行するように構成された少なくとも１つのプロセッサ４１０を含み、プロセッサ４１０は、埋め込みメモリ、入出力インターフェース、及び当技術分野で知られているような様々な他の回路を含んでよい。システム４００は、少なくとも１つのメモリ４２０（例えば、揮発性メモリデバイス及び／又は不揮発性メモリデバイス）を含む。システム４００は、記憶デバイス４４０を含み、これは、これに限定されないが、電気的消去可能プログラマブル読み出し専用メモリ（ＥＥＰＲＯＭ）．読取り専用メモリ（ＲＯＭ）、プログラマブル読取り専用メモリ（ＰＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、フラッシュ、磁気ディスクドライブ、及び／又は光ディスクドライブを含めた、不揮発性メモリ及び／又は揮発性メモリを含むことができる。記憶デバイス４４０は、非限定的な例として、内部記憶デバイス、取り付け型の記憶デバイス（取り外し可能及び取り外し不可能な記憶デバイスを含む）、及び／又はネットワークアクセス可能な記憶デバイスを含むことができる。
システム４００は、例えば、データを処理して、符号化されたビデオ又は復号化されたビデオを提供するように構成されたエンコーダ／デコーダモジュール４３０を含み、エンコーダ／デコーダモジュール４３０は、その独自のプロセッサ及びメモリを含み得る。エンコーダ／デコーダモジュール４３０は、符号化及び／又は復号化機能を実行するためにデバイスに含まれ得るモジュールを表す。既知のように、デバイスは、符号化モジュール及び復号化モジュールの一方又はその両方を含むことができる。加えて、エンコーダ／デコーダモジュール４３０は、システム４００の個別の要素として実装され得るか、又は当業者に知られているように、ハードウェアとソフトウェアの組み合わせとしてプロセッサ４１０内に組み込まれてもよい。
本明細書に記載される様々な態様を実行するためにプロセッサ４１０又はエンコーダ／デコーダ４３０にロードされるべきプログラムコードは、記憶デバイス４４０に記憶され、その後、プロセッサ４１０による実行のためにメモリ４２０にロードされてよく、様々な実施形態によれば、プロセッサ４１０、メモリ４２０、記憶デバイス４４０、及びエンコーダ／デコーダモジュール４３０のうちの１つ以上は、本明細書に記載されたプロセスの実行中、様々なアイテムのうちの１つ以上を記憶することができる。かかる記憶されたアイテムは、これらに限定されないが、入力ビデオ、復号化されたビデオ、又は復号化されたビデオの一部分、ビットストリーム、マトリクス、変数、並びに、方程式、式、動作、及び動作論理の処理からの中間結果又は最終結果を含むことができる。
いくつかの実施形態では、プロセッサ４１０及び／又はエンコーダ／デコーダモジュール４３０の内部のメモリは、命令を記憶し、かつ符号化中又は復号化中に必要とされる処理のための作業メモリを提供するために使用される。しかしながら、他の実施形態では、処理デバイス（例えば、処理デバイスは、プロセッサ４１０又はエンコーダ／デコーダモジュール４３０のいずれかであり得る）の外部のメモリが、これらの機能のうちの１つ以上のために使用されてもよい。外部メモリは、メモリ４２０及び／又は記憶デバイス４４０、例えば、ダイナミック揮発性メモリ及び／又は不揮発性フラッシュメモリであり得る。いくつかの実施形態では、外部不揮発性フラッシュメモリを使用して、例えば、テレビのオペレーティングシステムを記憶する。少なくとも一つの実施形態では、ＲＡＭなどの高速外部ダイナミック揮発性メモリが、ＭＰＥＧ－２などのビデオコーディング動作及びビデオ復号化動作のためのワーキングメモリとして使用される。ＭＰＥＧはＭｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐを指し、ＭＰＥＧ－２はＩＳＯ／ＩＥＣ １３８１８と呼ばれてもよい。ＩＳＯ／ＩＥＣ １３８１８－１はＨ．２２２としても知られており、１３８１８－２はＨ．２６２）、ＨＥＶＧ（ＨＥＶＣは、Ｈ．２６５及びＭＰＥＧ－Ｈ Ｐａｒｔ ２としても知られている高効率ビデオ符号化を指す）、又はＶＶＣ（多用途ビデオ符号化、ＪＶＥＴ、ジョイント・ビデオ・エキスパート・チームによって開発されている新しい規格）として知られている場合もある。
システム４００の要素への入力は、ブロック４４５に示されるように、様々な入力デバイスを通して提供され得る。このような入力デバイスには、（Ｉ）例えば、放送事業者による放送全体にわたり送信されるＲＦ信号を受信する無線周波数（Radio Frequency、ＲＦ）部分、（ｉｉ）コンポーネント（Component、ＣＯＭＰ）入力端子（又はＣＯＭＰ入力端子セット）、（ｉｉｉ）ユニバーサルシリアルバス（Universal Serial Bus、ＵＳＢ）入力端子、及び／又は（ｉｖ）高解像度マルチメディアインターフェース（High Definition Multimedia Interface、ＨＤＭＩ）入力端子が含まれるが、これらに限定されない。他の実施例には、図４には示されていないが、コンポジットビデオが含まれてもよい。
様々な実施形態では、ブロック４４５の入力デバイスは、当該技術分野で既知の、関連付けられたそれぞれの入力処理要素を有してもよい。例えば、ＲＦ部分は、（ｉ）所望の周波数を選択することと（また信号を選択する、又は信号を周波数帯域に帯域制限するとも称される）、（ｉｉ）選択された信号をダウンコンバートすることと、（ｉｉｉ）特定の実施形態で、（例えば）チャネルとして称され得る信号周波数帯域を選択するために、再度より狭い周波数帯域に帯域制限することと、（ｉｖ）ダウンコンバート及び帯域制限された信号を復調することと、（ｖ）誤り訂正を実行することと、（ｖｉ）データパケットの所望のストリームを選択するために多重分離することと、に対して好適な要素に関連付けられ得る。様々な実施形態のＲＦ部分は、これらの機能を実行するための１つ以上の要素、例えば、周波数セレクタ、信号セレクタ、帯域リミッタ、チャネルセレクタ、フィルタ、ダウンコンバータ、復調器、エラー訂正器、及びデマルチプレクサを含む。ＲＦ部分は、例えば、受信信号をより低い周波数（例えば、中間周波数又はベースバンドに近い周波数）又はベースバンドにダウンコンバートすることを含め、様々なこれらの機能を実行するチューナを含んでよい。１つのセットトップボックス実施形態では、ＲＦ部分及びその関連付けられた入力処理要素は、有線（例えば、ケーブル）媒体を介して送信されたＲＦ信号を受信し、フィルタリング、ダウンコンバート、及び所望の周波数帯域への再フィルタリングによって周波数選択を実行する。様々な実施形態では、上で説明される（及び他の）要素の順序を並べ替える、これらの要素の一部を削除する、並びに／又は、類似若しくは異なる機能を実行する他の要素を追加してもよい。要素を追加することは、例えば、既存の要素の間に要素を挿入すること、例えば増幅器及びアナログ－デジタル変換器を挿入することを含むことができ、様々な実施形態において、ＲＦ部分はアンテナを含む。
更に、ＵＳＢ及び／又はＨＤＭＩ端子は、システム４００をＵＳＢ及び／又はＨＤＭＩ接続を介して他の電子デバイスに接続するためのそれぞれのインターフェースプロセッサを含むことができ、入力処理、例えばリード・ソロモン誤り訂正の様々な態様は、例えば、別個の入力処理１Ｃ内又は必要に応じてプロセッサ４１０内で実施されてもよいことを理解されたい。同様に、ＵＳＢ又はＨＤＭＩインターフェース処理の態様は、必要に応じて、個別のインターフェースＩＣ内又はプロセッサ４１０内に実装され得る。復調され、エラー訂正され、多重分離されたストリームは、例えば、プロセッサ４１０、及び出力デバイス上に提示するために必要に応じてデータストリームを処理するためにメモリ及び記憶要素と組み合わせて動作するエンコーダ／デコーダ４３０を含む、様々な処理要素に提供される。
システム４００の様々な要素は、一体型ハウジング内に提供され得る。一体型ハウジング内では、様々な要素が相互接続され、適切な接続配列４２５、例えば、Ｉｎｔｅｒ－ＩＣ（Ｉ２Ｃ）バス、配線、及びプリント回路基板を含む当技術分野で知られている内部バスを使用して、それらの間でデータを送信し得る。
システム４００は、通信チャネル４６０を介して他のデバイスとの通信を可能にする通信インターフェース４５０を含む。通信インターフェース４５０は、これに限定されないが、通信チャネル４６０を介してデータを送信及び受信するように構成されたトランシーバを含むことができる。通信インターフェース４５０は、モデム又はネットワークカードを含むことができるが、これに限定されず、通信チャネル４６０は、例えば、有線及び／又は無線媒体内に実装され得る。
データは、様々な実施形態では、Ｗｉ－Ｆｉネットワーク、例えば、ＩＥＥＥ８０２．１１（ＩＥＥＥは、米国電気電子技術者協会（Institute of Electrical and Electronics Engineers）を指す）などの無線ネットワークを使用して、システム４００にストリーミングされるか、又は別様に提供されてもよい。これらの実施例のＷｉ－Ｆｉ信号は、Ｗｉ－Ｆｉ通信用に適合された通信チャネル４６０及び通信インターフェース４５０を介して受信される。これらの実施形態の通信チャネル４６０は、典型的に、ストリーミングアプリケーション及び他のオーバザトップ通信を可能にするために、インターネットを含む外部ネットワークへのアクセスを提供するアクセスポイント又はルータに接続される。他の実施形態では、入力ブロック４４５のＨＤＭＩ接続を介してデータを配信するセットトップボックスを使用して、システム４００にストリーミングデータを提供する。更に他の実施形態は、入力ブロック４４５のＲＦ接続を使用してシステム４００にストリーミングされたデータを提供する。上述したように、様々な実施形態は、非ストリーミング方式でデータを提供する。追加的に、様々な実施形態は、Ｗｉ－Ｆｉ以外の無線ネットワーク、例えば、セルラネットワーク又はＢｌｕｅｔｏｏｔｈネットワークを使用してもよい。
システム４００は、ディスプレイ４７５、スピーカ４８５、及び他の周辺デバイス４９５を含む様々な出力デバイスに出力信号を提供することができる。様々な実施形態のディスプレイ４７５は、例えば、タッチスクリーンディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、湾曲ディスプレイ、及び／又は折り畳み可能なディスプレイのうちの１つ以上を含む。ディスプレイ４７５は、テレビ、タブレット、ラップトップ、携帯電話（移動電話）、又は他のデバイス用であってもよい。ディスプレイ４７５はまた、他のコンポーネント（例えば、スマートフォンの場合のように、）と統合されてもよく、又は別個の（例えば、ラップトップ用の外部モニタ）であってもよい。他の周辺デバイス４９５は、実施形態の様々な例では、スタンドアロンのデジタルビデオディスク（又はデジタル多用途ディスク）（両用語のＤＶＲ）、ディスクプレーヤ、ステレオシステム、及び／又は照明システムのうちの１つ以上を含む。様々な実施形態は、システム４００の出力に基づいて機能を提供する１つ以上の周辺デバイス４９５を使用する。例えば、ディスクプレーヤは、システム４００の出力を再生する機能を実行する。
様々な実施形態において、制御信号が、ユーザの介入の有無に関わらず、デバイス間制御を可能にする、ＡＶＬｉｎｋ、Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ Ｃｏｎｔｒｏｌ（ＣＥＣ）、又は他の通信プロトコルなどのシグナリングを使用して、システム４００と、ディスプレイ４７５、スピーカ４８５、又は他の周辺デバイス４９５との間で通信されてよい。出力デバイスは、それぞれのインターフェース４７０、４８０及び４９０を通じた専用接続を介してシステム４００に通信可能に結合され得る。あるいは、出力デバイスは、通信インターフェース４５０を介して通信チャネル４６０を使用してシステム４００に接続されてもよい。ディスプレイ４７５及びスピーカ４８５は、例えばテレビなどの電子デバイス内のシステム４００の他のコンポーネントと単一のユニットに統合されてもよく、様々な実施形態では、ディスプレイインターフェース４７０は、例えばタイミングコントローラ（Ｔ Ｃｏｎ）チップなどのディスプレイドライバを含む。
ディスプレイ４７５及びスピーカ４８５は、代替的に、例えば、入力４４５のＲＦ部分が個別のセットトップボックスの一部分である場合、他のコンポーネントのうちの１つ以上から分離され得る。ディスプレイ４７５及びスピーカ４８５が外部コンポーネントである様々な実施形態では、出力信号は、例えば、ＨＤＭＩポート、ＵＳＢポート、又はＣＯＭＰ出力を含む、専用の出力接続を介して提供され得る。
実施形態は、プロセッサ４１０によって、又はハードウェアによって、又はハードウェア及びソフトウェアの組み合わせによって実装されたコンピュータソフトウェアによって実行され得る。非限定的な例として、実施形態は、１つ以上の集積回路によって実施されてもよい。メモリ４２０は、技術的環境に適した任意のタイプのものであってもよく、非限定的な例として、光メモリデバイス、磁気メモリデバイス、半導体ベースのメモリデバイス、固定メモリ、及びリムーバブルメモリなどの任意の適切なデータ記憶技術を使用して実施されてもよい。プロセッサ４１０は、技術的環境に適した任意のタイプのものであってもよく、非限定的な例として、マイクロプロセッサ、汎用コンピュータ、専用コンピュータ、及びマルチコアアーキテクチャに基づくプロセッサのうちの１つ又は複数を包含することができる。
様々な実装形態は、復号化を伴う。本出願で使用される「復号化」は、表示に適した最終出力を生成するために、例えば受信された符号化されたシーケンスに対して実行されるプロセスの全て又は一部を包含することができ、様々な実施形態では、そのようなプロセスは、デコーダによって通常実行されるプロセス、例えばエントロピー復号化、逆量子化、逆変換、及び差分復号化のうちの１つ又は複数を含む。様々な実施形態では、かかるプロセスはまた、又は代替的に、本出願に記載の様々な実装形態のデコーダによって実行されるプロセス、例えば、コード化点群シーケンス（例えば、ＩＳＯＢＭＦＦコンテナにカプセル化された）への部分的なアクセスを提供するために、コード化点群シーケンス（例えば、例えば、本明細書に開示するような、１つ以上のファイルフォーマット構造を使用してＩＳＯＢＭＦＦコンテナにカプセル化された）の一部分を復号化すること、などを含む。
更なる実施形態として、いくつかの例では、「復号化」はエントロピー復号化のみを指す場合があり、他の実施形態では、「復号化」は差分復号化のみを指す場合があり、他の実施形態では、「復号化」はエントロピー復号化と差分復号化との組み合わせを指す場合がある。「復号化プロセス」という語句が具体的に動作のサブセットを指すことを意図しているか、一般的により広い復号化プロセスを指すことを意図しているかは、特定の説明の文脈に基づいて明らかであり、当業者によって十分に理解されると考えられる。
様々な実装形態は、符号化を伴う。「復号化（decoding）」に関する上記の考察と同様に、本出願で使用される「符号化（encoding）」は、例えば、符号化されたビットストリームを作り出すために入力ビデオシーケンスに対して実行されるプロセスの全て又は一部を包含することができる。様々な実施形態において、このようなプロセスは、例えば、分割、差動符号化、変換、量子化、及びエントロピー符号化など、エンコーダによって典型的に実行されるプロセスのうちの１つ以上を含む。様々な実施形態では、かかるプロセスは同様に、又は代替的に、本出願に記載の様々な実施形態のエンコーダによって実行されるプロセス、例えば、コード化された点群シーケンス（例えば、ＩＳＯＢＭＦＦコンテナにカプセル化された）の異なる部分に部分的なアクセスサポートを提供するために、１つ以上のファイルフォーマット構造（例えば、本明細書に開示するような）を含むビデオベースの点群ビットストリームを符号化すること、などを含む。
更なる例として、一実施形態では、「符号化」とは、エントロピー符号化のみを指し、別の実施形態では、「符号化」とは、差動符号化のみを指し、別の実施形態では、「符号化」とは、差動符号化とエントロピー符号化との組み合わせを指す。符号化プロセスという句が、具体的に演算のサブセットを指すことを意図しているか、又は概してより広範な符号化プロセスを指すことを意図しているかは、特定の説明の文脈に基づいて明らかになり、当業者には十分に理解されると考えられる。
本明細書で使用されるシンタックス要素、例えばＶ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅ、Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ、及びＶ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅなどは、記述用語であることに留意されたい。したがって、これらは他のシンタックス要素名の使用を排除するものではない。
図がフローチャートとして提示されている場合、その図は対応する装置のブロック図も提供するものと理解されたい。同様に、図がブロック図として提示されている場合、その図は対応する方法／プロセスのフローチャートも提供するものと理解されたい。
本明細書に記載の実装形態及び態様は、例えば、方法又はプロセス、装置、ソフトウェアプログラム、データストリーム、又は信号において実装され得る。たとえ単一の形態の実装形態の文脈でのみ考察される場合でも（例えば、方法としてのみ考察される）、考察された特徴の実装形態は、他の形態（例えば、装置又はプログラム）でも実装することができる。装置は、例えば、適切なハードウェア、ソフトウェア、及びファームウェアで実装され得る。本方法は、例えば、一般に、例えば、コンピュータ、マイクロプロセッサ、集積回路、又はプログラマブルロジックデバイスを含む処理デバイスを指すプロセッサで実施されてよい。プロセッサはまた、例えば、コンピュータ、携帯電話、携帯情報端末「ＰＤＡ」、及びエンドユーザ間の情報の通信を容易にする他のデバイスなどの通信デバイスを含む。
「一実施形態」、「実施形態」、「例」、「一実装形態」、又は「実装形態」、並びにそれらの他の変形は、実施形態に関連して説明された特定の特徴、構造、特性などが少なくとも１つの実施形態に含まれることを意味する。したがって、本出願全体の様々な場所に現れる、「一実施形態において」、「例において」、「一実装形態において」、又は「実装形態において」という句、並びに他の任意の変形の出現は、必ずしも全てが同じ実施形態又は例を指すとは限らない。
更に、本出願は、様々な情報を「決定する」ことに言及する場合がある。情報を決定することは、例えば、情報を推定すること、情報を計算すること、情報を予測すること、又はメモリから情報を検索することのうちの１つ以上を含むことができる。取得することは、受信すること、取り出すこと、構築すること、生成すること、及び／又は判定することを含み得る。
更に、本出願は、情報の種々の部分にアクセスすることに言及する場合がある。情報にアクセスすることは、例えば、（例えば、メモリから）情報を取得すること、情報を記憶すること、情報を移動すること、情報をコピーすること、情報を計算すること、情報を判定すること、情報を予測すること、情報を推測すること、又は情報を推定することのうちの１つ以上を含むことができる。
加えて、本出願は、様々な情報を「受信すること」に言及する場合がある。受信することは、「アクセスすること」と同様に、広義の用語であることが意図されている。情報を受信することは、例えば、情報にアクセスすること、又は情報を（例えば、メモリから）検索することのうちの１つ以上を含むことができる。更に、「受信することは」は、典型的には、例えば、情報を記憶すること、情報を処理すること、情報を送信すること、情報を移動させること、情報をコピーすること、情報を消去すること、情報を計算すること、情報を判定すること、情報を予測すること、又は情報を推定することなどの動作中に、ある方法で又は別の方法で関与する。
以下の「及び／又は」並びに「例えば「Ａ／Ｂ」、「Ａ及び／又はＢ（A and/or B）」及び「Ａ及びＢの少なくとも一方（at least one of A and B）」の場合の少なくとも１つの使用は、最初に列挙された選択肢（Ａ）のみの選択、又は２番目に列挙された選択肢（Ｂ）のみの選択、又は両方の選択肢（Ａ及びＢ）の選択を包含することを意図していることを理解されたい。更なる例として、「Ａ、Ｂ、及び／又はＣ（A, B, and/or C）」及び「Ａ、Ｂ、及びＣのうちの少なくとも１つ（at least one of A, B, and C）」の場合、かかる表現は、第１のリストされた選択肢（Ａ）のみの選択、又は第２のリストされた選択肢（Ｂ）のみの選択、又は第３のリストされた選択肢（Ｃ）のみの選択、又は第１及び第２のリストされた選択肢（Ａ及びＢ）のみの選択、又は第１及び第３のリストされた選択肢（Ａ及びＣ）のみの選択、又は第２及び第３のリストされた選択肢のみの選択（Ｂ及びＣ）のみ、又は３つ全ての選択肢の選択（Ａ及びＢ及びＣ）を包含することが意図される。このことは、当該技術分野及び関連技術分野の当業者に明らかであるように、リストされたアイテムの数だけ拡張され得る。
また、本明細書で使用される場合、「シグナリングする」という単語は、とりわけ、対応するデコーダに対して何かを示すことを指す。いくつかの実施形態では、エンコーダは（例えば、符号化されたビットストリーム及び／又はＩＳＯＢＭＦＦコンテナなどのカプセル化ファイルにおいて）、例えば、パラメータセット、ＳＥＩメッセージ、メタデータ、編集リスト、ポストデコーダ要件、ＩＳＯＢＭＦＦコンテナにカプセル化されたコード化された点群シーケンスの異なる部分への柔軟な部分アクセスを可能にする信号、各シグナリングされたオブジェクトの依存関係リスト、空間領域へのマッピング、３Ｄ境界ボックス情報などをシグナリングしてよい。このようにして、一実施形態では、同じパラメータがエンコーダ側とデコーダ側の両方で使用される。したがって、例えば、エンコーダは、デコーダが同じ特定のパラメータを使用できるように、特定のパラメータをデコーダに送信する（明示的なシグナリング）ことができる。逆に、デコーダが既に特定のパラメータ並びに他のパラメータを有する場合、シグナリングを使用して、送信（暗黙的なシグナリング）することなく、単にデコーダが特定のパラメータを知り選択することを可能にし得る。任意の実際の機能の送信を回避することによって、様々な実施形態においてビット節約が実現され、シグナリングは様々な方法で達成され得ることを理解されたい。例えば、１つ以上のシンタックス要素、フラグなどが、様々な実施形態において、対応するデコーダに情報をシグナリングするために使用される。上記は、「シグナリングする」という語の動詞形に関連しているが、「ｓｉｇｎａｌ」という語は、本明細書では名詞としても使用されることがある。
当業者には明らかであるように、実装形態は、例えば、記憶又は送信され得る情報を搬送するようにフォーマットされた様々な信号を生成し得る。情報は、例えば、方法を実行するための命令、又は説明されている実装形態の１つによって生成されるデータを含むことができる。例えば、信号は、説明された実施形態のビットストリームを搬送するようにフォーマットされ得る。かかる信号は、例えば、（例えば、スペクトルの無線周波数部分を使用して）電磁波として、又はベースバンド信号としてフォーマットされ得る。フォーマットすることは、例えば、データストリームを符号化し、符号化されたデータストリームで搬送波を変調することを含み得る。信号が搬送する信号は、例えば、アナログ情報又はデジタル情報であり得る。信号は、知られているように、様々な異なる有線又は無線リンクによって送信され得る。信号は、プロセッサ可読メディアに記憶され得る。
三次元（３Ｄ）画像を（例えば、３Ｄ点群を使用して）キャプチャし、レンダリングすることは、テレプレゼンス、仮想現実、及び大規模動的３Ｄマップなどの多くの用途を有し得る。３Ｄ点群は、没入型メディアを表すために使用されてよい。３Ｄ点群は、３Ｄ空間に表される点のセットを含んでもよい。（例えば、各）点は、座標及び／又は１つ以上の属性を含み得る。座標は、（例えば、各）点の位置を示し得る。属性は、例えば、各点に関連付けられた色、透明度、取得時間、レーザ又は材料特性などのうちの１つ又は複数を含むことができる。点群は、いくつかの方法でキャプチャ又は展開されてよい。点群は、（例えば、３Ｄ空間をサンプリングするために、）例えば、複数のカメラ及び深度センサ、光検出及び測距（ＬＩＤＡＲ．）レーザスキャナなどを使用してキャプチャ又は展開され得る。点（例えば、座標及び／又は属性によって表される）は、例えば、３Ｄ空間内のオブジェクトのサンプリングによって生成され得る。点群は、複数の点を含むことができ、その各々は、３Ｄ空間にマッピングする座標のセット（例えば、ｘ、ｙ、ｚ座標）によって表されてよく、一例では、３Ｄオブジェクト又はシーンは、数百万又は数十億個のサンプリングされた点を含む点群で表される、又は再構成されてよい。３Ｄ点群は、静的及び／又は動的（移動する）３Ｄシーンを表し得る。
点群データは、例えば、点群データを（例えば、効率的に）記憶及び／又は送信するために、表現及び／又は圧縮（例えば、点群圧縮（ＰＣＣ））され得る。例えば、３Ｄ点群の効率的かつ相互運用可能な記憶及び送信をサポートするために、ジオメトリベース圧縮が、静的点群を符号化及び復号化するために利用され得、ビデオベース圧縮が、動的点群を符号化及び復号化するために利用され得る。点群サンプリング、表現、圧縮、及び／又はレンダリングは、点群のジオメトリック座標及び／又は属性の非可逆コーディング及び／又は可逆コーディング（例えば、符号化又は復号化）をサポートし得る。
図５は、サーバ５０２及びクライアント５１０のシステムインターフェース５００を示す図である。サーバ５０２は、インターネット５０４及び他のネットワーク５０６に接続された点群サーバとし得る。クライアント５１０はまた、インターネット５０４及び他のネットワーク５０６に接続され、ノード（例えば、サーバ５０２及びクライアント５１０）間の通信を可能にしてもよい。各ノードは、プロセッサと、非一時的コンピュータ可読メモリ記憶媒体と、本明細書に開示する方法又は方法の一部分を実施するようにプロセッサによって実行可能である、記憶媒体内に記憶された実行可能命令とを含んでよい。１つ以上のノードは、１つ以上のセンサを更に含み得る。クライアント５１０は、ヘッドマウントディスプレイ（head-mounted display、ＨＭＤ）５０８などのディスプレイの３Ｄビデオをレンダリングするためのグラフィックスプロセッサ５１２を含み得る（例えば、をも含み得る）。ノードのいずれか又は全ては、図１Ａ～図１Ｄに関して上記に記載したように、ＷＴＲＵを備え、ネットワークを介して通信し得る。
図６は、サーバ６０２及びクライアント６０４のためのシステムインターフェース６００を示す図である。サーバ６０２は、点群コンテンツサーバ６０２とし得、点群コンテンツのデータベース、詳細レベルを処理するためのロジック、及びサーバ管理機能を含み得る。いくつかの実施例では、詳細を処理することは、帯域幅制限に起因して、又は視認距離が低減を可能にするのに十分であるために可能にされるように、クライアント６０４（例えば、閲覧クライアント６０４）に送信するための解像度を低減し得る。点群コンテンツサーバ６０２は、クライアント６０４と通信してよく、点群データ及び／又は点群メタデータを交換することができる。いくつかの例では、閲覧者向けにレンダリングされた点群データは、点群データ及び／又は点群メタデータ（例えば、点群サーバ６０２から視聴クライアント６０４にストリーミングされた）などから、詳細のレベルを低減及び／又は増加させるためにデータ構築のプロセスを経てもよい。点群サーバ６０２は、空間取り込みが提供された解像度で点群データをストリーミングし得るか、又はいくつかの実施形態では、例えば、帯域幅制約又は視認距離公差に準拠するためにダウンサンプリングし得る。点群サーバ６０２は、詳細レベルを動的に低減してもよく、いくつかの例では、点群サーバ６０２は、点群データをセグメント化してよく（例えば同様にしてよく）、点群内のオブジェクトを識別してよい。いくつかの例では、選択されたオブジェクトに対応する点群データ内の点は、より低い解像度データで置き換えられ得る。
クライアント６０４（例えば、ＨＭＤを有するクライアント６０４）は、ビットストリーム、例えば、ビデオベース点群圧縮（Ｖ－ＰＣＣ）コード化されたビットストリームを介して点群コンテンツサーバ６０２から点群の一部分及び／又はタイルを要求し得る。例えば、点群の一部分及び／又はタイルは、ＨＭＤの場所及び／又は向きに基づいて取り出され得る。
点群は、各点に関連付けられた色、透明度、取得時間、レーザの反射率又は材料特性などの１つ以上の属性と共に各点の位置を示す座標を使用して３Ｄ空間内で表される点のセットから構成され得る。点群は、いくつかの方法でキャプチャされてよい。例えば、点群をキャプチャするための１つの技法は、複数のカメラ及び深度センサを使用してよい。光検出及び測距（ＬｉＤＡＲ）レーザスキャナも、点群をキャプチャするために使用されてよい。点群を使用してオブジェクト及びシーンを現実的に再構築するために必要とされる点の数は、数百万（又は更には数十億）ほどになり得る。したがって、効率的に表現及び圧縮することが、点群データを記憶及び送信するために不可欠であり得る。点群と同様に、いくつかの没入型ビデオタイプはまた、視覚的ボリュメトリックコンテンツを表すことが可能であってもよく、例えば、６自由度（６ＤｏＦ）で、限られた範囲の視聴位置及び配向内で３Ｄシーンの再生のためのサポートを提供することが可能であり得る。
上の段落で実質的に説明したように、少なくとも２つの３Ｄ点群圧縮（ＰＣＣ）規格、すなわち、静的点群のためのジオメトリベースの圧縮規格、及び動的点群のためのビデオベースの圧縮規格が提案される。動的点群のためのビデオベースの圧縮規格に関して、視覚的ボリュメトリックビデオベースコーディング（Ｖ３Ｃ）は一例であり、Ｖ３Ｃベースの実装形態の様々な態様は以下のように説明され得る。
図７は、例示的なＶ３Ｃビットストリームの構造の一例を示す。図７に示すように、ビットストリームは、Ｖ３Ｃサンプルストリーム７０１を含んでよく、これは、各々がＶ３Ｃユニットヘッダ及びＶ３Ｃユニットペイロードを有するＶ３Ｃユニットのセットを含み得る。Ｖ３Ｃユニットヘッダは、Ｖ３Ｃユニットタイプを記述してよい。例えば、Ｖ３Ｃユニットタイプは、Ｖ３Ｃ＿ＯＶＤ、Ｖ３Ｃ＿ＧＶＤ、及び／又はＶ３Ｃ＿ＡＶＤを含み得る。ユニットタイプＶ３Ｃ＿ＯＶＤ、Ｖ３Ｃ＿ＧＶＤ、及びＶ３Ｃ＿ＡＶＤを有するＶ３Ｃユニットは、それぞれ占有ビデオデータユニット、ジオメトリ属性ビデオデータユニット、及び属性ビデオデータユニットであってよい。これらのデータユニットは、視覚的ボリュメトリックメディアコンテンツを再構成するために必要とされる３つの主要なコンポーネントを表してよい。占有Ｖ３Ｃユニットペイロード、ジオメトリＶ３Ｃユニットペイロード、及び属性Ｖ３Ｃユニットペイロードは、適切なビデオデコーダによって復号化され得るビデオデータユニット（例えば、ＮＡＬユニット）に対応してよい。Ｖ３Ｃビットストリームはまた、１つ以上のＶ３Ｃ＿ＶＰＳユニットを含んでよく、これは、Ｖ３Ｃユニットヘッダで使用され得るシンタックス要素を定義するパラメータセットを提供してよい。Ｖ３Ｃビットストリームは、アトラスサブビットストリーム（例えば、Ｖ３ＣユニットヘッダＶ３Ｃ＿ＡＤによって示される）を更に含んでよく、これは、少なくともＮＡＬユニットヘッダを含むユニットと、符号化されたアトラスを定義する（又は部分的に定義する）データをカプセル化するユニットとを含む、ネットワーク抽象化層（ＮＡＬ）サンプルストリーム７０２を搬送し得る。例えば、図７に示すように、ＮＡＬユニットは、アトラスタイルグループに対応するアトラスタイルグループ層７０３（例えば、生バイトシーケンスペイロード（ＲＢＳＰ））のペイロードを含んでよく、これは、パッチ（すなわち、ボリュメトリック情報に関連付けられたアトラス内の領域）を記述するヘッダ及びデータを含み得る。
図８は、サポートされるＶ３Ｃ属性タイプの例を例示する表である。Ｖ３Ｃ属性ユニットヘッダは、Ｖ３Ｃユニットタイプに加えて、属性タイプを指定してもよい。Ｖ３Ｃ属性ユニットヘッダはまた、インデックスを指定してもよく、同じ属性タイプの複数のインスタンスがサポートされることを可能にする。例えば、サポートされる属性タイプは、テクスチャ、材料、透明度、反射率、又は表面法線を含み得る。
本明細書では、Ｖ３Ｃコンテナファイルフォーマットについて説明する。
図９は、ＩＳＯＢＭＦＦ規格に従って実装され得るようなＶ３Ｃコンテナの例示的な構造を示す。一般に、Ｖ３Ｃコンテナは、アトラスデータ、ジオメトリデータ、属性データ、及び占有データによって更に定義されるボリュメトリックビデオデータ９００を包含し得る。より具体的には、コンテナは、サンプルエントリ内のＶ３Ｃパラメータセット及びアトラスパラメータセットと、サンプル内のアトラスコンポーネントビットストリームＮＡＬユニットとを包含するＶ３Ｃアトラストラック９１０を含み得る。Ｖ３Ｃアトラストラックはまた、ビデオ圧縮Ｖ３Ｃユニット（すなわち、Ｖ３Ｃ＿ＯＶＤ、Ｖ３Ｃ＿ＧＶＤ、及びＶ３Ｃ＿ＡＶＤに等しいＶ３Ｃユニットタイプである）のペイロードを搬送する他のトラック９２０、９３０及び９４０、又はＶ３Ｃアトラスタイルトラックへのトラック参照を含み得る。
コンテナは、図９の９２０に例示されるように、サンプルがジオメトリデータ（すなわち、Ｖ３Ｃ＿ＧＶＤに等しいタイプのＶ３Ｃユニットのペイロード）用のビデオコード化されたエレメンタリストリームのアクセスユニットを包含する、１つ以上のＶ３Ｃビデオコンポーネントトラックを含み得る。コンテナは、図９の９３０に例示されるように、サンプルが属性データ（すなわち、Ｖ３Ｃ＿ＡＶＤに等しいタイプのＶ３Ｃユニットのペイロード）用のビデオコード化されたエレメンタリストリームのアクセスユニットを包含する、ゼロ以上のＶ３Ｃビデオコンポーネントトラックを含み得る。コンテナは、図９の９４０に例示されるように、サンプルが占有データ（すなわち、Ｖ３Ｃ＿ＯＶＤに等しいタイプのＶ３Ｃユニットのペイロード）用のビデオコード化されたエレメンタリストリームのアクセスユニットを包含する、ゼロ以上のＶ３Ｃビデオコンポーネントトラックを含み得る。
図１０は、２つ以上のアトラス及び複数のアトラスタイルを有する例示的なマルチトラックコンテナを例示する。複数のアトラスがＶ３Ｃメディアに存在する場合、これらのアトラスは、関連付けられたＶ３Ｃコンポーネントトラック（すなわち、関連付けられた占有マップ、ジオメトリ、及び属性情報を搬送するトラック）へのトラック参照を有する別個のアトラストラックで搬送されてもよい。アトラスデータが２つ以上のアトラスタイルを含む場合、これらのアトラスタイルは、アトラストラックによって参照される別個のアトラスタイルトラックに記憶されてもよく、追加のトラック参照は、アトラスタイルトラックから、アトラスタイルトラックによって搬送されるアトラスタイルの関連付けられたＶ３Ｃビデオコンポーネント情報を搬送するトラックに記憶される。これは、例えば、図１０に例証されてよい。１００１に例示されるように、Ｖ３Ｃトラック「ｖ３ｃｂ」は複数のアトラスを含み得る。アトラスは、例えば、「ｖ３ａ１」又は「ｖ３ａｇ」のサンプルエントリを有する別個のＶ３Ｃトラック１０１０及び１０２０に記憶されてもよい。Ｖ３Ｃトラック１０１０及び１０２０は各々、複数のアトラスタイルトラック１０１１及び１０１２を含んでよく、アトラスタイルトラック１０１１及び１０１２の各々は、Ｖ３Ｃコンポーネントトラック１０１３及び１０１４をそれぞれ含み得る。
上記の段落で実質的に説明したように、静的点群のためのジオメトリベースの圧縮（Ｇ－ＰＣＣ）規格はまた、３Ｄ点群の効率的で相互運用可能な記憶及び送信をサポートするために定義され得る。本明細書では、そのような幾何学ベースの圧縮規格に従って実行及び／又は実装され得る方法、装置、及びシステムが提案される。
図１１は、Ｇ－ＰＣＣ規格で符号化されたビットストリームの構造の一例を例示する図である。図１１に示すように、Ｇ－ＰＣＣビットストリーム１１００は、タイプ－長さ－値（ＴＬＶ）カプセル化構造としても知られるＧ－ＰＣＣユニットのセットを搬送し得る。１１１０に示すように、（すなわち、各）Ｇ－ＰＣＣ ＴＬＶユニットは、ＴＬＶタイプ１１１１及びＧ－ＰＣＣ ＴＬＶユニットペイロード１１１２を示す情報を含み得る。図１１には示されていないが、ＧＰＣＣ ＴＬＶユニットは、例えばバイト又はビットに関して表現され得るＧ－ＰＣＣ ＴＬＶユニットペイロード長を示す情報を更に含み得る。Ｇ－ＰＣＣ ＴＬＶユニットペイロード１１１２は、所与のタイプの情報を含み得る。例えば、Ｇ－ＰＣＣ ＴＬＶユニットペイロードは、例えば、シーケンスパラメータセット、ジオメトリパラメータセット、ジオメトリデータユニット、属性パラメータセット、属性データユニット、タイルインベントリ、フレーム境界マーカ、又はデフォルトの属性データユニットであり得る所与のタイプの情報を搬送し得る。
図１２は、例えばＭＰＥＧ規格に従って定義され得るＧ－ＰＣＣ ＴＬＶカプセル化ユニットの例示的なシンタックス構造を提供する表である。図１２に示すように、ＴＬＶカプセル化ユニットは、第１のビット数（又はバイト）、例えば８ビットを使用してペイロードタイプを示してよい。ＴＬＶカプセル化ユニットペイロード長は、第２のビット数（例えば、３２ビット）で表されてよい。Ｇ－ＰＣＣ ＴＬＶカプセル化ユニットは、示されたペイロードタイプ及びペイロード長を有するペイロードを含み得る。
図１３は、ＴＬＶタイプパラメータの可能な値と、この可能な値の各々の対応する記述とを提供する表である。図１３に示すように、ＴＬＶペイロードタイプは、シーケンスパラメータセット、ジオメトリパラメータセット、ジオメトリデータユニット、属性パラメータセット、属性データユニット、タイルインベントリ、フレーム境界マーカ、又はデフォルトの属性データユニットであってもよい。ユニットタイプ「２」及び「４」を有するＧ－ＰＣＣ ＴＬＶユニットは、それぞれジオメトリデータユニット及び属性データユニットであり得る。
図１４は、Ｇ－ＰＣＣ ＴＬＶユニットペイロードの例示的なシンタックス構造を提供する表である。図１４に示される例示的なシンタックスは、例えば、ＭＰＥＧ－Ｉ Ｐａｒｔ ９（ＩＳＯ／ＩＥＣ ２３０９０－９）で定義されたシンタックス構造と一致し得る。ジオメトリＧ－ＰＣＣユニット及び属性Ｇ－ＰＣＣユニットのペイロード情報は、Ｇ－ＰＣＣデコーダによって復号化されてよく、かつ対応するジオメトリＧ－ＰＣＣユニット及び属性パラメータセットＧ－ＰＣＣユニットにおいて指定されるメディアデータユニット（例えば、ＴＬＶユニット）に対応し得る。
Ｇ－ＰＣＣファイルの高レベル構文（high-level syntax、ＨＬＳ）は、ジオメトリデータ及び属性データにおけるスライス及びタイルグループの概念をサポートし得る。フレームは、複数のタイル及びスライスに分割され得る。スライスは、独立して符号化又は復号化することができる点のセットとして理解されてよい。スライスは、例えば、１つのジオメトリデータユニットと、０以上の属性データユニットとを含み得る。属性データユニットの情報は、同じスライス内のジオメトリデータユニットの対応する情報に依存し得る。スライス内で、ジオメトリデータユニットは、関連付けられた属性ユニットの前に必然的に現れてよい。スライスのデータユニットは、連続し得る。フレーム内のスライスの順序付けは、必ずしも指定されなくてもよい。
いくつかの方式では、スライスのグループは、共通タイル識別子によって識別されてもよい。いくつかの規格と一致して、各タイルのバウンディングボックスを記述するタイルインベントリが提供されてもよい。タイルは、バウンディングボックス内の別のタイルと重複し得る。各スライスは、スライスが属するタイルを識別するインデックスを包含し得る。
本明細書では、Ｇ－ＰＣＣコンテナファイルフォーマットについて説明する。Ｇ－ＰＣＣビットストリームが単一のトラックで搬送される場合、それは、Ｇ－ＰＣＣ符号化されたビットストリームが単一トラック宣言によって表されることを必要とし得る。Ｇ－ＰＣＣデータの単一トラックカプセル化は、一部のケースでは、更なる処理なしにＧ－ＰＣＣビットストリームが単一トラックに記憶される単純なＩＳＯＢＭＦＦカプセル化を利用し得る。そのようなトラック内の各サンプルは、１つ以上のＧ－ＰＣＣコンポーネントを包含し得る。換言すると、各サンプルは、１つ以上のＴＬＶカプセル化構造を含み得る。
図１５は、Ｇ－ＰＣＣジオメトリ情報及び属性情報を提供するビットストリームが単一のトラックに記憶される方式による例示的なサンプル構造を例示する。図１５に示すように、Ｇ－ＰＣＣビットストリームを搬送するトラックのサンプル１５００は、パラメータセットを提供する第１のＴＬＶ １５１０、ジオメトリデータを提供する第２のＴＬＶ １５２０、及び第２のＴＬＶ １５２０のジオメトリデータに対応する属性データを提供する第３のＴＬＶ １５３０のうちの少なくとも一つを含み得る。
１つ以上の符号化Ｇ－ＰＣＣジオメトリビットストリーム及び１つ以上の符号化Ｇ－ＰＣＣ属性ビットストリームが別々のトラックに記憶されるとき、トラック内の各サンプルは、単一のＧ－ＰＣＣコンポーネントデータを搬送する少なくとも１つのＴＬＶカプセル化構造を包含してよい。
図１６は、いくつかの規格（ＭＰＥＧ－Ｉ Ｐａｒｔ １８（ＩＳＯ／ＩＥＣ ２３０９０－１８）など）に従って実装され得るマルチトラックＩＳＯＢＭＦＦ Ｇ－ＰＣＣコンテナの例示的な構造を示す。マルチトラックＧ－ＰＣＣコンテナは、それぞれｆｔｙｐ、ｍｏｏｖ、及びｍｄａｔ構造１６１０、１６２０、及び１６３０によって図１６に示される「ボックス」として知られる情報ユニットを含んでよく、これらは、ＩＳＯ／ＩＥＣ １４４９６－１２で定義されたベースメディアファイルフォーマットと一致してよい。ｆｔｙｐボックス１６１０は、例えば、ファイルタイプ記述情報、及びメディアファイルで使用される共通データ構造を提供してよい。ｍｏｏｖボックス１６２０及びｍｄａｔボックス１６３０は、ジオメトリパラメータセット、シーケンスパラメータセット、及びジオメトリデータＴＬＶユニットを搬送するジオメトリビットストリームサンプルを併せて包含するＧ－ＰＣＣトラック１６２１及び１６３１を含んでよい。トラックはまた、Ｇ－ＰＣＣ属性コンポーネントのペイロードを搬送する他のトラックへのトラック参照を含んでよい。ｍｏｏｖボックス１６２０及びｍｄａｔボックス１６３０は、それぞれの属性の属性パラメータセットを包含し得るＧ－ＰＣＣトラック１６２２及び１６３２と、属性データＴＬＶユニットを搬送する属性ビットストリームサンプルとを集合的に含んでよい。
Ｇ－ＰＣＣビットストリームが複数のトラックで搬送される場合、いくつかの規格（ＩＳＯ／ＩＥＣ １４４９６－１２など）に従って実装され得るトラック参照ツールを使用して、Ｇ－ＰＣＣコンポーネントトラックをリンクしてもよい。場合によっては、１つ以上のＴｒａｃｋＲｅｆｅｒｅｎｃｅＴｙｐｅＢｏｘが、Ｇ－ＰＣＣトラックのＴｒａｃｋＢｏｘ内のＴｒａｃｋＲｅｆｅｒｅｎｃｅＢｏｘに追加されてもよい。ＴｒａｃｋＲｅｆｅｒｅｎｃｅＴｙｐｅＢｏｘは、Ｇ－ＰＣＣトラックが参照するトラックを指定するｔｒａｃｋ＿ＩＤの配列を包含してよい。Ｇ－ＰＣＣジオメトリトラックをＧ－ＰＣＣ属性トラックにリンクするために、Ｇ－ＰＣＣジオメトリトラックのＴｒａｃｋＲｅｆｅｒｅｎｃｅＴｙｐｅＢｏｘのｒｅｆｅｒｅｎｃｅ＿ｔｙｐｅが、関連付けられた属性トラックを識別してよい。これらのトラック参照タイプに関連付けられた４文字コード（４ＣＣ）は、参照されたトラックがＧ－ＰＣＣ属性データの符号化ビットストリームを包含することを示し得る「ｇｐｃａ」であってよい。
Ｇ－ＰＣＣビットストリームのジオメトリストリームが複数のタイルを包含する場合、各タイル又はタイルのグループは、ジオメトリタイルトラックと呼ばれ得る別個のトラックにカプセル化されてよい。ジオメトリタイルトラックは、１つ以上のジオメトリタイルのＴＬＶユニットを搬送してもよく、したがってこれらのタイルへの直接のアクセスを可能にする。同様に、複数のタイルを包含するＧ－ＰＣＣビットストリームの属性ストリームもまた、複数の属性タイルトラックで搬送されてもよい。
１つ以上のＧ－ＰＣＣタイルのデータは、コンテナの別々のジオメトリタイルトラック及び属性タイルトラックで搬送されてよい。Ｇ－ＰＣＣコード化されたストリーム用のＩＳＯＢＭＦＦコンテナにおける部分アクセスをサポートするために、点群シーン内の空間領域に対応するタイルは、いくつかのＭＰＥＧ規格と一致して定義され得るＤｙｎａｍｉｃ３ＤＳｐａｔｉａｌＲｅｇｉｏｎＳａｍｐｌｅＥｎｔｒｙを有するトラックなどの時限メタデータトラックのサンプルにおいて、又は同様にいくつかのＭＰＥＧ規格で定義され得るようなＧＰＣＣＳｐａｔｉａｌＲｅｇｉｏｎＩｎｆｏＢｏｘボックスにおいてシグナリングされ得る。これにより、プレーヤ及びストリーミングクライアントは、点群シーン内の特定の空間領域又はタイルをレンダリングするために必要とされる情報を搬送するタイルトラックのセットを取り出すことが可能になり得る。
Ｇ－ＰＣＣベーストラックは、ＩＳＯ／ＩＥＣ ２３０９０－９に記載されているように、例えば、ＳＰＳ、ＧＰＳ、ＡＰＳ、及びタイルインベントリ情報のみを包含するＴＬＶカプセル化構造を搬送してよい。Ｇ－ＰＣＣベーストラックをジオメトリタイルトラックにリンクするために、新しいトラック参照タイプを有するトラック参照が、４ＣＣ「ｇｐｂｔ」を使用して定義され得る。新しいタイプのトラック参照を使用して、Ｇ－ＰＣＣベーストラックを各ジオメトリタイルトラックにリンクしてよい。
各ジオメトリタイルトラックは、例えばＩＳＯ／ＩＥＣ １４４９６－１２と一致して実装され得るようなトラック参照ツールを使用して、それぞれのタイル又はタイルグループの属性情報を搬送するＧ－ＰＣＣタイルトラックの他の１つ以上の属性とリンクされ得る。これらのトラック参照タイプの４ＣＣは、例えば、ＭＰＥＧ規格と一致して定義され得るような「ｇｐｃａ」であってよい。
点群シーンは、代替形態でコード化されてもよい。そのような場合、コード化Ｇ－ＰＣＣデータの代替形態は、ＩＳＯ／ＩＥＣ １４４９６－１２と一致して実装され得るような、代替トラックメカニズムによって示されてよい。例えば、コード化されたＧ－ＰＣＣデータの代替を示すために、ＴｒａｃｋＨｅａｄｅｒＢｏｘのａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐフィールドが使用されてもよい。各代替Ｇ－ＰＣＣビットストリームが単一のトラックに記憶されるとき、互いの代替形態であり得るコード化されたＧ－ＰＣＣビットストリームを包含するＧ－ＰＣＣトラックは、それらのＴｒａｃｋＨｅａｄｅｒＢｏｘ内に同じａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ値を有してもよい。各代替のＧ－ＰＣＣビットストリームがマルチトラックコンテナに記憶されるとき、すなわち、各代替のＧ－ＰＣＣビットストリームの異なるコンポーネントビットストリームが別々のトラックで搬送されるとき、代替Ｇ－ＰＣＣビットストリームのＧ－ＰＣＣジオメトリトラックは、それらのＴｒａｃｋＨｅａｄｅｒＢｏｘ内で同じａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ値を有し得る。
ＭＰＥＧメディアトランスポート（ＭＭＴ）のための方法、手順、装置、及びシステムが本明細書で説明される。一般的に言えば、高度なメディアトランスポート及び配信サービスを可能にするために、ツールのセットを使用することができる。ツールは、メディア処理ユニット（ＭＰＵ）フォーマット、配信、及びシグナリングの３つの異なる機能領域に分散されてもよい。そのようなツールは、一緒に効率的に使用されるように設計され得るが、それらはまた、独立して使用されてもよい。
メディア処理ユニット（ＭＰＵ）機能領域は、メディアコンテンツの論理構造、ＭＭＴエンティティによって処理されるデータユニットのパッケージ及びフォーマット、並びに例えばＩＳＯベースメディアファイルフォーマットを用いたそれらのインスタンス化を定義してよい。パッケージは、高度な配信に必要な情報を提供するために、メディアコンテンツ及びそれらの関係性を含むコンポーネントを指定してよい。データのフォーマットは、記憶又は配信のいずれかのために符号化されたメディアデータをカプセル化し、記憶されるべきデータと配信されるべきデータとの間の容易な変換を可能にするように定義され得る。
配信機能領域は、ＭＭＴプロトコル（ＭＭＴＰ）と呼ばれるアプリケーション層トランスポートプロトコル及びペイロードフォーマットを定義してよい。アプリケーション層トランスポートプロトコルは、単一のパケットフローにおけるストリーミング配信とダウンロード配信との混合使用の多重化及びサポートなど、マルチメディアデータの配信のための拡張機能を提供し得る。ペイロードフォーマットは、メディアタイプ及び符号化方法に依存しない符号化されたメディアデータの搬送を可能にし得る。
シグナリング機能エリアは、メディアデータの配信及び消費を管理するためのシグナリングメッセージのフォーマットを定義してよい。消費管理のためのシグナリングメッセージは、パッケージの構造をシグナリングするために使用されてよく、配信管理のためのシグナリングメッセージは、ペイロードフォーマット及びプロトコル構成の構造をシグナリングするために使用されてよい。
ＭＭＴプロトコルは、単一のＭＭＴＰパケットフローを介した様々なアセットからのメディア処理ユニット（ＭＰＵ）のような異なるメディアデータの多重化をサポートし得る。それは、大きな遅延を導入することなく、又は大きなバッファを必要とすることなく、異なるタイプのメディアデータ間の同期を助けるために、消費の順序で複数のタイプのデータを受信エンティティに配信し得る。ＭＭＴＰはまた、単一のパケットフロー内のメディアデータ及びシグナリングメッセージの多重化をサポートしてよい。
いくつかの実施形態では、ＭＭＴＰペイロードは、１つのＭＭＴＰパケットのみで搬送され得る。フラグメンテーション及びアグリゲーションは、ペイロードフォーマットによって提供されてもよく、ＭＭＴＰ自体によって提供されなくてもよい。ＭＭＴＰは、汎用ファイル配信（ＧＦＤ）モード及びＭＰＵモードの２つのパケット化モードを定義してよい。ＧＦＤモードは、トランスポートオブジェクト内のそれらのバイト位置を使用してデータユニットを識別し得る。ＭＰＵモードは、ＭＰＵ内の役割及びメディア位置を使用してデータユニットを識別し得る。ＭＭＴプロトコルは、単一の配信セッションにおける２つの異なるモードを有するパケットの混合使用をサポートし得る。ＭＭＴパケットの単一のパケットフローは、任意に２種類のペイロードで構成されてもよい。
図１７は、ＭＭＴシグナリングが実行されるシステムの例示的なエンドツーエンドアーキテクチャを描く。アーキテクチャは、少なくとも、これらに限定されないが、パッケージプロバイダ１７１０と、一つ以上のアセットプロバイダ１７２１及び１７２２と、ＭＭＴ送信エンティティ１７３０と、ＭＭＴ受信エンティティ１７４０とを含んでもよい。図１７に示されるように、ＭＭＴ送信エンティティ１７３０は、パッケージ提供者１７１０からパッケージを受信してよい。ＭＭＴ送信エンティティ１７３０は、ＭＭＴＰパケットフローとしてＭＭＴ受信エンティティ１７４０へパッケージを送信する役割を担ってもよい。ＭＭＴ送信エンティティ１７３０は、パッケージプロバイダ１７１０によって提供されるパッケージのプレゼンテーション情報に基づいてコンテンツプロバイダからメディアコンテンツを収集するように要求されてもよい。メディアコンテンツは、ＭＭＴＰパケットフローを形成する一連のカプセル化されたＭＭＴ処理ユニットにセグメント化されるアセットとして提供されてもよい。したがって、ＭＭＴ送信エンティティ１７３０は、アセットプロバイダ１７２１及び／又は１７２２のうちの１つ以上からアセット情報を収集してもよい。
シグナリングメッセージは、パッケージの配信及び消費を管理するために使用されてよい。ＭＭＴ送信エンティティ１７３０とＭＭＴ受信エンティティ１７４０との間のインターフェース、並びにそれらの動作は、規格化され得る。ＭＭＴプロトコル（ＭＭＴＰ）は、ＭＭＴ受信エンティティ１７４０によって、ｐａｃｋｅｔ＿ｉｄ及びペイロードタイプに基づいて、ストリーミングされたメディアを受信して多重分離するために使用され得る。ＭＭＴ受信エンティティ１７４０によって実行されるカプセル化解除手順は、搬送されるペイロードのタイプに依存してもよく、例えば、図１７に示されたシナリオにおいて、別個に処理されてもよい。
本明細書では、ＭＭＴデータモデルの様々な態様が説明される。ＭＭＴプロトコルは、コード化されたメディアデータのストリーミング配信及びダウンロード配信の両方を提供し得る。ストリーミング配信の場合、ＭＭＴプロトコルは、ＭＰＵ、アセット、及びパッケージを含む固有のデータモデルを想定してよい。ＭＭＴプロトコルは、シグナリングメッセージを使用してＭＰＵ、アセット、及びパッケージの間の構造的関係を示すことによって、配信中にデータモデルを保存してよい。
符号化されたメディアデータ及びその関連メタデータの集合は、パッケージを構築してよい。パッケージは、１又は複数のＭＭＴ送信エンティティから１つ以上のＭＭＴ受信エンティティに配信されてよい。オーディオ又はビデオコンテンツの一部など、パッケージの符号化されたメディアデータの１つ以上の部分は、アセットを構成し得る。
アセットは、アセットがグローバルに一意に識別され得るように、アセットを提供している実際の物理的位置又はサービスプロバイダに依存する可能性がない識別子に関連付けられてよい。異なる識別子を有するアセットは交換可能ではない場合がある。例えば、２つの異なるアセットは、同じコンテンツの２つの異なる符号化を搬送し得るが、それらは交換可能でなくてもよい。ＭＭＴは、特定の識別メカニズムを指定することはできないが、この目的のためにＵＲＩ又はＵＵＩＤを使用することを可能にする場合がある。各アセットは、パッケージによって作成されたプレゼンテーション全体のタイムラインとは異なる持続時間であり得る独自のタイムラインを有する場合がある。
各ＭＰＵは、アセットの重複しない部分を構成することができ、すなわち、同じアセットの２つの連続するＭＰＵは同じメディアサンプルを包含しない場合がある。各ＭＰＵは、ＭＭＴ受信エンティティのプレゼンテーションエンジンによって独立的に消費され得る。
図１８は、いくつかの実施形態によるパッケージ構造の例示である。図１８に示すように、パッケージ１８００は、論理エンティティであってもよい。パッケージ１８００は、１つ以上のプレゼンテーション情報ドキュメント１８１０と、１つ以上のアセット１８２０と、各アセットに対して関連付けられたアセット配信特性（ＡＤＣ）とを包含し得る。アセット１８２０の各々は、１つ以上のＭＰＵ１８３０を包含し得る。パッケージの処理はＭＰＵ単位で行われてもよく、各ＭＰＵは同じアセットＩＤを共有してもよい。
ＭＭＴアセットは、いくつかの実施形態に従って本明細書で更に説明される。アセットは、マルチメディアプレゼンテーションを構築するために使用される任意のマルチメディアデータであり得る。アセットは、符号化されたメディアデータを搬送するための同じアセットＩＤを共有するＭＰＵの論理グルーピングであり得る。アセットの符号化されたメディアデータは、時限データ又は非時限データであり得る。時限データは、固有のタイムラインを有する符号化されたメディアデータを含んでよく、指定された時間にデータユニットの同期された復号化及びプレゼンテーションを必要とする場合がある。非時限データは、そのメディアコンテンツの復号化及びプレゼンテーションのための固有のタイムラインを持たない任意の他のタイプのデータを含み得る。非時限データの各項目の復号化時刻及びプレゼンテーション時刻は、必ずしも同一の非時限データの他の項目の復号化時刻及びプレゼンテーション時刻と関連しなくてもよい。例えば、これらは、ユーザ対話又はプレゼンテーション情報によって決定されてもよい。
時限メディアデータを搬送する同じアセットの２つのＭＰＵは、それらのプレゼンテーション時間において重複を持たない場合がある。プレゼンテーション情報によって参照される任意のタイプのデータがアセットと見なされてもよい。個々のアセットと見なされ得るメディアデータのタイプの例は、オーディオデータ、ビデオデータ、又はウェブページデータを含み得る。
メディア処理ユニット（ＭＰＵ）の特徴及び特性が、本明細書で説明される。メディア処理ユニット（ＭＰＵ）は、ＭＭＴエンティティによって処理され、他のＭＰＵから独立してプレゼンテーションエンジンによって消費され得るメディアデータ項目であり得る。
ＭＭＴエンティティによるＭＰＵの処理は、カプセル化／カプセル化解除及びパケット化／パケット化解除を含み得る。ＭＰＵは、メディアアウェアパケット化のためのＭＦＵの境界を示すＭＭＴヒントトラックを含んでよい。ＭＰＵの消費は、メディア処理（例えば、符号化／復号化）及びプレゼンテーションを含み得る。
パケット化の目的で、ＭＰＵは、アクセスユニット（ＡＵ）よりも小さくなり得るデータユニットにフラグメント化され得る。ＭＰＵのシンタックス及びセマンティクスは、ＭＰＵ中で搬送されるメディアデータのタイプに依存しないことがある。単一アセットのＭＰＵは、時限メディア又は非時限メディアのいずれかを有し得る。ＭＰＵは、ＭＰＥＧ－４ ＡＶＣ（ＩＳＯ／ＩＥＣ １４４９６－１０）又はＭＰＥＧ－２ ＴＳなどのいくつかの規格のうちの１つ以上に従ってフォーマットされたデータの一部を包含してよい。
単一のＭＰＵは、整数個のＡＵ又は非時限データを包含し得る。時限データの場合、単一のＡＵは、複数のＭＰＵにフラグメント化されない場合がある。非時限データの場合、単一のＭＰＵは、プレゼンテーションエンジンによって消費される１つ以上の非時限データ項目を包含し得る。ＭＰＵは、関連付けられたアセット識別（ａｓｓｅｔ＿ｉｄ）及び／又はシーケンス番号によって識別され得る。
ＭＭＴＰペイロードの態様が本明細書で説明される。ＭＭＴＰペイロードは、ＭＰＵ、汎用オブジェクト、及びＭＭＴプロトコルを介してパッケージを消費するための他の情報のようなメディアデータをパケット化して伝達するために使用される汎用ペイロードであってもよい。適切なＭＭＴＰペイロードフォーマットが、ＭＰＵ、汎用オブジェクト、及びシグナリングメッセージをパケット化するために使用されてよい。
ＭＭＴＰペイロードは、完全なＭＰＵ又はＭＰＵの断片、シグナリングメッセージ、汎用オブジェクト、ＡＬ－ＦＥＣ方式のリペアシンボル、又は他のデータユニット又は構造を搬送してもよい。ペイロードのタイプは、ＭＭＴプロトコルパケットヘッダ内のタイプフィールドによって示されてもよい。ペイロードタイプごとに、配信のための１つ以上のデータユニットと、追加又は代替として、タイプ固有ペイロードヘッダとが定義され得る。例えば、ＭＭＴＰペイロードがＭＰＵの断片を搬送するとき、ＭＰＵ（例えば、ＭＦＵ）の断片は、単一のデータユニットと見なされてもよい。ＭＭＴプロトコルは、同じデータタイプを有する複数のデータユニットを単一のＭＭＴＰペイロードに集約してもよい。また、単一のデータユニットを複数のＭＭＴＰパケットにフラグメント化してもよい。
ＭＦＵは、時限データのサンプル若しくはサブサンプル、又は非時限データのアイテムであってもよい。ＭＦＵは、時限データのためのＡＵよりも小さくてもよいメディアデータを含んでもよく、含まれるメディアデータは、メディアデコーダによって処理されてもよい。ＭＦＵは、搬送されるメディアデータの境界に関する情報を包含するＭＦＵヘッダを含んでよい。ＭＦＵは、ＭＰＵ内のＭＦＵを一意に区別するための識別子を包含してよい。また、同じＭＰＵ内の他のＭＦＵに対する依存性及び優先度情報を提供してもよい。
ＭＭＴＰペイロードは、ペイロードヘッダ及びペイロードデータを含んでもよい。いくつかのデータタイプは、フラグメント化及びアグリゲーションを可能にしてもよく、その場合、単一のデータユニットが複数の断片に分割され得るか、又はデータユニットのセットが単一のＭＭＴＰパケットで配信される場合もある。
近年、仮想現実（ＶＲ）及び没入型ビデオ及び３Ｄグラフィックスなどの新しく出現しつつあるメディアタイプにかなりの関心が集まっている。没入型メディアの高度な表現として近年、高品質の３Ｄ点群が出現し、仮想世界との対話及び通信の新たな形態を可能にした。そのような点群を表すために必要な大量の情報は、効率的なコーディングアルゴリズムを必要とし得る。ビデオベースの点群圧縮のための新しい規格が現在開発中であり、ビジュアルボリュメトリックビデオベースコーディング（Ｖ３Ｃ）のための基礎を形成するであろう。ジオメトリベースの点群圧縮のための規格もまた開発されており、圧縮された静的な点群のためのビットストリームを定義し得る。並行して、Ｖ３Ｃメディア及びジオメトリベースの点群データの搬送を定義する規格も開発中である。
Ｖ３Ｃキャリッジ及び点群規格を取り巻く議論は、Ｖ３Ｃデータ及び点群データの記憶及びシグナリング態様に対処し得るが、そのような議論は、例えば、ＭＰＥＧ－ＤＡＳＨ規格に基づくＨＴＴＰを介した動的適応ストリーミングのためのシグナリングのみに関係し得るという点において限定されてよい。異なるストリーミング及び配信アプリケーションを可能にするための別の重要な候補規格は、ＭＰＥＧメディアトランスポート（ＭＭＴ）である。しかしながら、ＭＭＴ規格は、現在、Ｖ３Ｃメディアのためのシグナリングメカニズムは提供しない場合がある。したがって、ストリーミングクライアントがＶ３Ｃストリーム及びそれらのコンポーネントサブストリームを識別することを可能にする新しいシグナリング要素が望まれる。加えて、Ｖ３Ｃコンポーネントに関連付けられた異なる種類のメタデータをシグナリングして、ストリーミングクライアントが、サポートすることが可能な、あるいは所与の特定のネットワーク制約又は任意の所与の時間におけるユーザのビューポートを配信することができる、Ｖ３Ｃコンテンツ又はそのコンポーネントの最適なバージョン（複数可）を選択することを可能にすることも必要であり得る。
更に、実際の点群アプリケーションは、ネットワーク上で点群データをストリーミングすることを必要とすることが想定される。そのようなアプリケーションは、コンテンツがどのように生成されたかに応じて、点群コンテンツのライブストリーミング又はオンデマンドストリーミングのいずれかを実行してよい。点群を表すために必要とされる大量の情報に起因して、そのようなアプリケーションは、ネットワークの過負荷を回避し、任意の所与の瞬間において、例えば、その瞬間におけるネットワーク容量に関して、最適な視聴体験を提供するために、適応型ストリーミング技法をサポートする必要がある場合がある。点群コンテンツのコンポーネントは、複数のタイルに分割され得る。１つ以上のストリーミングクライアントは、例えば、帯域幅利用可能性に基づいて、（例えば、点群データ全体の代わりに）ジオメトリコンポーネントの特定のタイル部分をストリーミングすることを（例えば単に）望む（例えば、決定又は選択する）場合がある。Ｇ－ＰＣＣコンポーネントタイルデータは、異なるＧ－ＰＣＣタイルトラックにカプセル化され得る。（例えば、各）タイルトラックは、Ｇ－ＰＣＣコンポーネントタイルのセット又は全てのＧ－ＰＣＣコンポーネントタイルのセットを表してよい。
現在、ＭＭＴは、ＭＰＥＧ Ｇ－ＰＣＣ規格に基づく点群ストリームを含む点群メディアのためのシグナリングメカニズムを提供していない。したがって、ストリーミングクライアントが点群ストリーム及びそれらのコンポーネントサブストリームを識別することを可能にする新しいシグナリング要素を定義することが重要である。ストリーミングクライアントが、サポートすることができる点群又はそのコンポーネントの最適なバージョンを選択することを可能にするために、点群コンポーネントに関連付けられた異なる種類のメタデータをシグナリングすることも必要である。
本明細書で説明される解決策は、ＭＭＴストリーミングクライアントが、Ｖ３Ｃ及びＧＰＣＣメディアコンテンツに関連付けられた異なるコンポーネント及びメタデータを識別し、クライアントがストリーミングセッション中の任意の時点でコンテンツサーバから取り出す必要があるメディアデータを選択することを可能にする新しいシグナリング要素を提供し得る。更に、本明細書で説明される解決策は、ＭＭＴストリーミングのためのＧ－ＰＣＣデータと、ＭＭＴを介したＧ－ＰＣＣデータの配信をサポートするために必要なＭＭＴシグナリングメッセージとのカプセル化のための様々な方法を提供してもよい。
Ｖ３ＣコンテンツのＭＭＴ配信が、本明細書で更に説明される。Ｖ３Ｃコンテンツは、ストリーミングプロセス中にＭＭＴ送信エンティティを支援し得る。例えば、プレゼンテーション情報は、アプリケーションによる適切な処理を可能にするために、Ｖ３Ｃに準拠するＭＰＵを記述する情報を包含し得る。
プレーヤは、現在の視聴方向、現在のビューポート、及びプレーヤが動作しているデバイスのディスプレイの特性に関する情報を受信してよい。この情報に基づいて、ビュー依存ストリーミングは、ストリーミングセッションにおいて必要とされる帯域幅を低減するために使用され得る。ＭＭＴの場合、ビュー依存ストリーミングは、１つ以上の手法によって達成されてよい。
いくつかのクライアントベースのストリーミング手法では、ＭＭＴ受信エンティティは、現在のビューポート内に含まれる（又は現在のビューポートと交差する）Ｖ３Ｃコンテンツの部分をレンダリングするために必要とされるＶ３Ｃ情報を搬送するアセットのサブセットを選択するようにプレーヤによって命令されてよい。ＭＭＴセッション制御手順は、ＭＭＴ送信エンティティから選択されたセットのアセットを要求するために使用されてよい。プレーヤは、サーバからのＶ３Ｃアプリケーション固有シグナリングメッセージを使用して、ビュー依存ストリーミングのために切り替えるべき適切なアセットを選択し得る。
いくつかのサーバベースの手法では、ＭＭＴ受信エンティティは、ＭＭＴ送信エンティティに依存して、現在のビューポートをカバーするＶ３Ｃコンテンツの部分をレンダリングするためのＶ３Ｃ情報を提供するアセットの正しいサブセットを選択し得る。受信エンティティは、Ｖ３Ｃアプリケーション固有のシグナリングを使用して、現在のビューポートに関する情報を送信エンティティに送信し得る。
Ｖ３ＣコンテナをＭＭＴアセットにマッピングするための方法及び手順が本明細書で説明される。ＭＭＴを使用してＶ３Ｃコンテンツの配信をサポートするために、マルチトラックＩＳＯＢＭＦＦ Ｖ３Ｃコンテナ内の各トラックは、別個のアセットとしてカプセル化されてよい。したがって、アセットの数は、コンテナ内のトラックの数に等しくてよい。同じＶ３Ｃコンポーネントに属するアセットは、アセットグループに論理的にグループ化され得る。これらのアセットグループは、ストリーミングクライアントがどのアセットグループを要求すべきかを決定することを可能にするために、受信エンティティにシグナリングされ得る。Ｖ３Ｃアプリケーション固有のＭＭＴシグナリングが本明細書で説明される。
ＭＭＴを使用してＶ３Ｃ符号化されたデータをストリーミングする目的で、いくつかのＶ３Ｃ固有のＭＭＴメッセージが定義される。例えば、Ｖ３Ｃアプリケーション固有シグナリングは、Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅなどのグループメッセージ、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅなどの選択メッセージ、又はＶ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅなどのビュー変更フィードバックメッセージの送信を含むことができる。いくつかの実施形態では、これらのメッセージは、例えば、送信エンティティがシグナリングをＶ３Ｃアプリケーションに関連付けることを可能にし得るユニフォームリソース名（ＵＲＮ）「ｕｒｎ：ｍｐｅｇ：ｍｍｔ：ａｐｐ：ｖ３ｃ：２０２０」を有するアプリケーション識別子を含んでよい。
図１９は、定義されたアプリケーションメッセージタイプのリストを提供する表である。提案されたＭＭＴ Ｖ３Ｃシグナリングでは、アプリケーションメッセージタイプのセットが定義されてよく、セットの各メッセージタイプは、図１９に示すように、アプリケーションメッセージ名に関連付けられてよい。Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅを介して、送信エンティティは、サーバにおいて利用可能なアセットのセットについてクライアントに通知し、受信エンティティにストリーミングされているアセットのリストを提供し得る。Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅでは、クライアントは、アセットのセットが送信エンティティによって受信エンティティにストリーミングされることを要求してよい。Ｖ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅでは、クライアントは、サーバベースのビュー依存ストリーミングセッションにおいて、ユーザの現在の視聴方向及びビューポートの指示をサーバに送信し得る。
ＭＭＴを介してＶ３Ｃコンテンツを送信する場合、いくつかの実施形態において、Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅは義務的であってもよく、Ｖ３Ｃコンテンツに関連付けられたサーバにおいて利用可能なアセットのリストを受信エンティティに提供してもよい。このメッセージはまた、これらのアセットのうちのどれが受信エンティティに現在ストリーミングされているかについて受信エンティティに通知するために使用され得る。このリストから、受信エンティティ上で動作するクライアントは、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅメッセージを使用して、これらのＶ３Ｃアセットの一意のサブセットを要求し得る。
ＭＭＴを介したＶ３Ｃコンテンツのビュー依存配信のために、クライアントは、Ｖ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅ ｍｅｓｓａｇｅを使用して、その現在のビューポート情報をサーバに送信してよく、その後、サーバは、そのビューポートに対応するアセットを選択してクライアントに配信し得る。Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅはまた、アセットの選択されたサブセットについてクライアントを更新するために使用され得る。図２０は、Ｖ３Ｃアセット記述子の例示的なシンタックス構造を提供する表である。アセット記述子は、受信エンティティ及び消費アプリケーションに、Ｖ３Ｃコンテンツを搬送するアセットのコンテンツについて通知するために使用され得る。Ｖ３Ｃアセット記述子のセマンティクスが、本明細書で提供される。記述子タグ、例えば、「Ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ」は、記述子のタイプを示し得る。記述子長、例えば「Ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ」は、このフィールドの後の次のバイトから記述子の最後のバイトまでカウントするバイト単位の長さを指定し得る。データタイプ、例えば、「Ｄａｔａ＿ｔｙｐｅ」は、このアセット中に存在するＶ３Ｃデータのタイプを示し得る。このフィールドの値は、図２２に更に示され、以下の段落で紹介され、実質的に説明され得る。依存フラグ、例えば、「Ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ」は、Ｖ３Ｃアセットが復号化のために別のＶ３Ｃアセット中のデータに依存するかどうかを示し得る。０の値は、このＶ３Ｃコンポーネントアセットグループデータが独立して復号化され得ることを示し得る。１の値は、このＶ３Ｃアセットが復号化のために他のＶ３Ｃアセットデータに依存することを示し得る。代替グループフラグ、例えば、「Ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ＿ｆｌａｇ」は、このＶ３Ｃアセットが代替バージョンを有するかどうかを示し得る。０の値は、このＶ３Ｃコンポーネントアセットがいかなる代替アセットも持たないことを示し得る。１の値は、このＶ３Ｃアセットが１つ以上の代替を有することを示し得る。代替グループＩＤ、例えば、「Ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ＿ｉｄ」は、代替アセットのグループを識別するＩＤを示し得る。同じＶ３Ｃアセットの異なる符号化されたバージョンは、このフィールドに対して同じ値を有し得る。依存アセットＩＤ、例えば、「Ｄｅｐ＿ａｓｓｅｔ＿ｉｄ」は、このアセットの復号化が依存するアセットＩＤの値を示し得る。場合によっては、この値は、ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇが１に設定されているときのみ存在し得る。例えば、Ｖ３Ｃビデオコンポーネントアセットは、このフィールドのための対応するＶ３ＣアトラスコンポーネントアセットＩＤを使用し得る。「Ｎｕｍ＿ｔｉｌｅｓ」は、このアセットで搬送されるタイルの数を示し得る。「ｔｉｌｅ＿ｉｄ」は、特定のアトラスタイルの一意の識別子を示し得る。
図２１は、Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅの例示的なシンタックスの例を示す表である。図２１の表と一致して、Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅのセマンティクスは、以下のように説明され得る。「Ｍｅｓｓａｇｅ＿ｉｄ」は、Ｖ３Ｃアプリケーションメッセージの識別子を示し得る。「Ｖｅｒｓｉｏｎ」は、Ｖ３Ｃアプリケーションメッセージのバージョンを示し得る。「長さ」は、次のフィールドの開始からメッセージの最後のバイトまでカウントする、Ｖ３Ｃアプリケーションメッセージの長さをバイト単位で示し得る。このフィールドの値は０に等しくなくてもよい。アプリケーション識別子、例えば、「Ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」は、このメッセージのコンテンツを消費するアプリケーションを一意に識別するＵＲＮとしてアプリケーション識別子を示し得る。「Ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ」は、図１９に関して実質的に上記で説明したように、アプリケーション固有のメッセージタイプを示し得る。「Ｎｕｍ＿Ｖ３Ｃ＿ａｓｓｅｔ＿ｇｒｏｕｐｓ」は、Ｖ３Ｃアセットグループの数を示してよく、各グループは、Ｖ３Ｃコンポーネントに関連付けられたアセットを包含する。「ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」は、Ｖ３Ｃコンポーネントと関連付けられたアセットグループの識別子を示し得る。「Ｎｕｍ＿ａｓｓｅｔｓ」は、Ｖ３Ｃコンポーネントに関連付けられたアセットグループ内のアセットの数を示す。「Ｓｔａｒｔ＿ｔｉｍｅ」は、このメッセージにリストされたアセットの状態が適用可能なＶ３Ｃコンポーネントのプレゼンテーション時間を示し得る。「Ｄａｔａ＿ｔｙｐｅ」は、このアセットグループに存在するＶ３Ｃデータのタイプを示し得る。このフィールドの値の例は、図２２の文脈で説明され、以下の段落で紹介され、実質的に説明され得る。「Ｐｅｎｄｉｎｇ＿ｆｌａｇ」は、全てのデータコンポーネントがアセットグループのレンダリングの準備ができているかどうかを示し得る。例えば、「１」に設定されると、データが準備完了であることを示してもよく、そうでない場合、フラグは「０」であってもよい。「ａｓｓｅｔ＿ｉｄ」は、アセットのアセット識別子を提供し得る。「ｓｔａｔｅ＿ｆｌａｇ」は、アセットの配信状態を示し得る。１（「１」）に設定されるとき、これは、送信エンティティが受信エンティティにアセットをアクティブに送信していることを示し得る。０（「０」）に設定されると、これは、送信エンティティがアセットを受信エンティティにアクティブに送信していないことを示し得る。「Ｓｅｎｄｉｎｇ＿ｔｉｍｅ＿ｆｌａｇ」は、アセットストリームの最初のＭＰＵを含む最初のＭＭＴＰパケットに対する「ｓｅｎｄｉｎｇ＿ｔｉｍｅ」の存在を示し得る。デフォルト値は「０」であってもよい。「ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ＿ｆｌａｇ」は、このＶ３Ｃコンポーネントアセットが代替バージョンを有するか否かを示し得る。０の値は、このＶ３Ｃアセットがいかなる代替アセットも持たないことを示し得る。１の値は、このＶ３Ｃアセットが代替アセットを有することを示し得る。依存フラグ、例えば、「Ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ」は、このＶ３Ｃコンポーネントアセットが復号化のために他のＶ３Ｃアセット中のデータに依存するかどうかを示し得る。０の値は、このＶ３Ｃコンポーネントアセットグループデータが独立して復号化され得ることを示し得る。１の値は、このＶ３Ｃアセットが復号化のために他のＶ３Ｃアセットデータに依存することを示し得る。送信時間、例えば「Ｓｅｎｄｉｎｇ＿ｔｉｍｅ」は、アセットストリームの最初のＭＰＵを包含する最初のＭＭＴＰパケットに対する送信時間を示し得る。この情報を使用して、クライアントは、新しいアセットストリームのための新しいパケット処理パイプラインを準備してよい。「ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ＿ｉｄ」は、代替Ｖ３Ｃコンポーネントアセットの識別子を示し得る。同じＶ３Ｃアセットの異なる符号化されたバージョンは、このフィールドに対して同じ値を有し得る。「Ｄｅｐ＿ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」は、このアセットの復号化が依存するアセットのためのＩＤを示し得る。場合によっては、この値は、例えばｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇが１に設定されているときのみ存在し得る。例えば、Ｖ３Ｃ属性コンポーネントアセットは、このフィールドに対応するＶ３ＣアトラスコンポーネントアセットＩＤを使用し得る。「ａｌｌ＿ｔｉｌｅｓ＿ｐｒｅｓｅｎｔ＿ｆｌａｇ」は、アトラスコンポーネントの全てのタイルがアセットの一部であるか否かを示し得る。１の値は、全てのアトラスタイルについてのデータがアセットにおいて利用可能であることを示し得る。０の値は、アトラスタイルのサブセットについてのデータがアセット内で利用可能であることを示し得る。「Ｎｕｍ＿ｔｉｌｅｓ」は、このアセットで搬送されるタイルの数を示し得る。「ｔｉｌｅ＿ｉｄ」は、特定のアトラスタイルの一意の識別子を提供してよい。
図２２は、Ｄａｔａ＿ｔｙｐｅフィールドにおいて使用され得るような例示的なＶ３Ｃデータタイプ値を例示する表である。図２２に示されているように、Ｄａｔａ＿ｔｙｐｅフィールドの値は、全てのＶ３Ｃコンポーネントデータ、アトラスコンポーネントデータ、占有コンポーネントデータ、ジオメトリコンポーネントデータ、属性コンポーネントデータ、コーデック初期化データ、動的ボリュメトリック時限メタデータ情報、又はビューポート時限メタデータ情報を示し得る。
図２３は、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅの例示的なシンタックスを示す表である。図２３の表と一致して、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅのセマンティクスは、以下のように説明され得る。「Ｍｅｓｓａｇｅ＿ｉｄ」は、Ｖ３Ｃアプリケーションメッセージの識別子を示し得る。「Ｖｅｒｓｉｏｎ」は、Ｖ３Ｃアプリケーションメッセージのバージョンを示し得る。「長さ」は、Ｖ３Ｃアプリケーションメッセージの長さをバイト単位で示すことができ、例えば、次のフィールドの先頭からメッセージの最後のバイトまでカウントする。このフィールドの値は０に等しくなくてもよい。「Ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」は、このメッセージのコンテンツを消費するアプリケーションを一意に識別するＵＲＮとしてアプリケーション識別子を示し得る。「Ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ」は、図１９に関して上記の段落で実質的に上記で説明したように、アプリケーション固有のメッセージタイプを示し得る。「Ｎｕｍ＿ｓｅｌｅｃｔｅｄ＿ａｓｓｅｔ＿ｇｒｏｕｐｓ」は、受信エンティティによる関連付けられた状態変更要求があるアセットグループの数を示し得る。「ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」は、Ｖ３Ｃコンテンツと関連付けられたアセットグループの識別子を示し得る。「ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅ」は、受信エンティティによって要求されるアセットの選択のために使用されるスイッチングモードを示し得る。「ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅ」の値のリストは、例えば、図２３を紹介し、説明する以下の段落と一致して定義され得る。「Ｎｕｍ＿ａｓｓｅｔｓ」は、指定されたスイッチングモードによる状態変更のためにシグナリングされるアセットの数を示し得る。「Ａｓｓｅｔ＿ｉｄ」は、指定されたスイッチングモードによる状態変更のためのアセットの識別子を示し得る。
図２４は、ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅフィールドの定義を提供する表である。図２４に示すように、「ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅ」フィールドは、アセットの選択のために使用されるスイッチングモードを示し得る。例えば、スイッチングモードがリフレッシュに設定される場合、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅにリストされた各アセットに対して、各アセットのＳｔａｔｅ＿ｆｌａｇは「１」に設定され、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅにリストされていない全てのアセットのＳｔａｔｅ＿ｆｌａｇは「０」に設定される。スイッチングモードがトグルするように設定される場合、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅにリストされた各アセットについて、各アセットのＳｔａｔｅ＿ｆｌａｇは、例えば、元々「０」であれば「１」に、元々「１」であれば「０」に変更されるが、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅにリストされていない全てのアセットのＳｔａｔｅ＿ｆｌａｇは変更されない。スイッチングモードが、Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅで指定されたアセットグループの全てのアセットに対して、全てを送信するように設定される場合、各アセットのＳｔａｔｅ＿ｆｌａｇは、「１」に設定される。
図２５は、Ｖ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅの例示的なシンタックスを示す表である。図２５の表と一致して、Ｖ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅのセマンティクスは、以下のように説明されてよい。「Ｍｅｓｓａｇｅ＿ｉｄ」は、Ｖ３Ｃアプリケーションメッセージの識別子を示し得る。「Ｖｅｒｓｉｏｎ」は、Ｖ３Ｃアプリケーションメッセージのバージョンを示し得る。「長さ」は、次のフィールドの開始からメッセージの最後のバイトまでカウントする、Ｖ３Ｃアプリケーションメッセージの長さをバイト単位で示し得る。このフィールドの値は０に等しくないものとする。「Ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」は、このメッセージのコンテンツを消費するアプリケーションを一意に識別するＵＲＮとしてアプリケーション識別子を示し得る。「Ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ」は、図１９に関して上記の段落で実質的に上記で説明したように、アプリケーション固有のメッセージタイプを示し得る。「Ｖｐ＿ｐｏｓ＿ｘ」、「ｖｐ＿ｐｏｓ＿ｙ」、及び「ｖｐ＿ｐｏｓ＿ｚ」は、それぞれ、グローバル基準座標系におけるビューポートの位置のｘ、ｙ及びｚ座標をメートル単位で示し得る。値は、例えば、２－１６メートルの単位で提供され得る。「Ｖｐ＿ｑｕａｔ＿ｘ」、「ｖｐ＿ｑｕａｔ＿ｙ」、及び「ｖｐ＿ｑｕａｔ＿ｚ」は、それぞれ、四元数表現を使用したビューポート領域の回転のｘ、ｙ、及びｚ成分を示し得る。座標の値は、両端値を含む－１から１の範囲内の浮動小数点値であり得る。これらの値は、四元数表現を使用して、グローバル座標軸をカメラのローカル座標軸に変換するために適用される回転のｘ、ｙ、及びｚ成分、すなわちｑＸ、ｑＹ、及びｑＺを指定し得る。四元数ｑＷの第４の成分は、式１に従って、生成されてよく、
Figure 2024502822000002
点（ｗ，ｘ，ｙ，ｚ）は、ベクトル（ｘ，ｙ，ｚ）によって方向付けられた軸の周りの角度による回転を表してよく、これは、式２に従って決定されてよい。
Figure 2024502822000003
「ｃｌｉｐｐｉｎｇ＿ｎｅａｒ＿ｐｌａｎｅ」及び「ｃｌｉｐｐｉｎｇ＿ｆａｒ＿ｐｌａｎｅ」は、ビューポートの近距離及び遠距離クリッピング平面に基づく近距離及び遠距離深度（又は距離）をメートル単位で示し得る。「Ｈｏｒｉｚｏｎｔａｌ＿ｆｏｖ」は、例えば、ラジアン単位で、ビューポート領域の水平サイズに対応する経度範囲を指定してよい。この値は、０～２πの範囲内であってもよい。「ｖｅｒｔｉｃａｌ＿ｆｏｖ」は、ビューポート領域の垂直サイズに対応する緯度範囲を、例えばラジアンの単位で指定してよい。この値は、０～πの範囲内であってもよい。
ストリーミングクライアント挙動に関する方法及び装置が、本明細書で説明される。ＭＭＴクライアントは、アプリケーション固有シグナリングメッセージで提供される情報によってガイドされてもよい。以下は、本明細書で提示されるＭＭＴシグナリングを使用してＶ３Ｃコンテンツをストリーミングするためのクライアント挙動の例である。
いくつかの方法では、ＭＭＴ送信エンティティは、関心のあるクライアントに「Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージを送信してよい。受信クライアントは、「Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージを構文解析し、ＭＭＴコンテンツ送信エンティティに存在するＶ３Ｃメディアアセットを識別し得る。利用可能なＶ３Ｃメディアコンテンツを識別するために、ストリーミングクライアントは、「ｕｒｎ：ｍｐｅｇ：ｍｍｔ：ａｐｐ：ｖ３ｃ：２０２０」」に設定された「Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージ内の「ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」フィールドをチェックし得る。Ｖ３Ｃコンテンツにおいて利用可能なＶ３Ｃアセットの全部又は一部は、「Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージにおいてシグナリングされたアセットＩＤをチェックすることによって識別され得る。クライアントは、ユーザの現在のビューポートに基づいてストリーミングされる必要なアセットを選んでよい。ＭＭＴクライアントは、「Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅ」アプリケーションメッセージを送信エンティティに送信し、利用可能なＶ３Ｃアセットのリストから関心のあるＶ３Ｃアセットを要求してよい。ＭＭＴ送信エンティティは、ＭＴＰでＭＭＴＰパケットを形成し、ＭＴＴＰパケットをクライアントに送信してよい。
いくつかの方法において、ＭＭＴクライアントは、ＭＭＴＰパケットを受信し、ＭＰＵ又はＭＦＵをデパケット化してよい。ＭＰＵ／ＭＦＵは、時限ディアコンテンツを又は非時限Ｖ３Ｃメディアコンテンツを包含してよい。ＭＭＴクライアントが、アセットグループ「ｄａｔａ＿ｔｙｐｅ」が「０ｘ０５」に設定されたＭＭＴＰパケットを受信する場合、このＶ３Ｃアセットデータは、ＶＰＳ、ＡＳＰＳ、ＡＡＰＳ、ＡＦＰＳ及びＳＥＩメッセージなどの初期化情報を表す。ＭＭＴクライアントが、アセットグループ「ｄａｔａ＿ｔｙｐｅ」が「０ｘ０６」に設定されたＭＭＴＰパケットを受信する場合、このＶ３Ｃアセットデータは、３Ｄ空間領域時限メタデータ情報を表してよい。このアセット内の情報は、Ｖ３Ｃコンテンツの部分的アクセスのために使用され得る。ＭＭＴクライアントが、アセットグループ「ｄａｔａ＿ｔｙｐｅ」が「０ｘ０７」に設定されたＭＭＴＰパケットを受信する場合、このＶ３Ｃアセットデータは、初期又は推奨されたビューポート情報を示し得る。この情報を使用して、異なる基準に基づく自動的なビューポートの変更を可能にすることができる。ＭＭＴクライアントは、例えば、ユーザのビューポート又は推奨されたビューポート及び対応する１つ以上の３Ｄ空間領域に基づいて、必要なＶ３Ｃアセットを選択してよい。ＭＭＴクライアントは、対象のＶ３Ｃアセットを要求する送信エンティティに「Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅ」アプリケーションメッセージを送信してよい。
いくつかの方法では、ユーザのビューポートがクライアントベースのストリーミング手法において変化するとき、ＭＭＴクライアントは、「Ｖ３ＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅ」アプリケーションメッセージを使用してＶ３Ｃアセットの異なるセットを要求してもよい。ユーザのビューポートがサーバベースのストリーミング手法において変化するとき、ＭＭＴクライアントは、「Ｖ３ＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋＭｅｓｓａｇｅ」メッセージを送信エンティティに送信して、ユーザの現在のビューポートをシグナリングしてよい。このメッセージを受信すると、ＭＭＴ送信エンティティは、ユーザの新しいビューポート情報に基づいてＶ３Ｃアセットの新しいセットを選択し、「Ｖ３ＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージを対応するＶ３Ｃアセットと共にＭＭＴクライアントに送信する。ＭＭＴ送信エンティティは、Ｖ３ＣアセットデータをＭＭＴＰパケットとしてストリーミングしてよい。ＭＭＴクライアントは、全ての要求されたＶ３Ｃアセットに対するＭＭＴＰパケットの受信を開始し、ＭＭＴＰペイロードからＭＰＵ及びＭＦＵを抽出してよい。ＭＰＵ及びＭＦＵは、メディアサンプルを直接包含してもよい、又はメディアセグメントを包含する場合もある。ＭＭＴクライアントは、メディアセグメントコンテナ（例えば、ＩＳＯＢＭＦＦ）の構文解析を開始して、エレメンタリストリーム情報を抽出し、Ｖ３Ｃ規格に従ってＶ３Ｃビットストリームを構造化してよい。ビットストリームは、Ｖ３Ｃデコーダに渡されてよい。ＭＭＴＰペイロードがＶ３Ｃメディアサンプルを包含する場合、エレメンタリストリームデータが抽出され、Ｖ３Ｃビットストリーム規格に従って構造化される。ビットストリームは、Ｖ３Ｃデコーダに渡されてよい。
ＭＭＴにおけるＧ－ＰＣＣデータのカプセル化及びシグナリングを対象とする実施形態が本明細書に記載される。従来のメディアコンテンツとは異なり、Ｇ－ＰＣＣメディアコンテンツは、ジオメトリ及び属性などの多数のコンポーネントを含み得る。各コンポーネントは、Ｇ－ＰＣＣビットストリームのサブストリームとして別々に符号化され得る。ジオメトリ及び属性などのコンポーネントは、例えば、Ｇ－ＧＰＣＣエンコーダを使用して符号化され得る。しかしながら、これらのサブストリームは、点群をレンダリングするために追加のメタデータと共にまとめて復号化される必要があり得る。
Ｇ－ＰＣＣ符号化されたコンテンツは、ＭＭＴを使用してネットワークを介して配信されてよい。ＩＳＯＢＭＦＦ内のＧ－ＰＣＣコンポーネントが複数のトラックを使用してシグナリングされるとき、各トラックは、別個のアセットにカプセル化されるように提案されてもよく、次いで、別個のアセットは、通常の方法でＭＭＴＰパケットにパケット化されてもよい。サーバ及びクライアントが特定のＧ－ＰＣＣコンポーネントに対して複数のアセットのグループを識別できるようにするために、Ｇ－ＰＣＣ定義のアプリケーションメッセージも提案される。
Ｇ－ＰＣＣメディアコンテンツは、ジオメトリ及び属性など、１つ以上の（例えば、複数の）コンポーネントを含み得る。（例えば各）コンポーネントは、Ｇ－ＰＣＣビットストリームのサブストリームとして別々に符号化され得る。ジオメトリ及び属性などのコンポーネントは、例えば、Ｇ－ＧＰＣＣエンコーダを使用して符号化され得る。サブストリームは、例えば点群をレンダリングするために、追加のメタデータと共にまとめて復号化されてもよい。
Ｇ－ＰＣＣデータは、ＭＭＴにおいてカプセル化及びシグナリングされ得る。Ｇ－ＰＣＣ符号化されたコンテンツは、ＭＭＴを使用してネットワークを介して配信されてよい。Ｇ－ＰＣＣデータは、（例えば、本明細書で説明するような）様々なカプセル化方法を使用して、ＭＭＴストリーミングのためにカプセル化され得る。ＭＭＴシグナリングメッセージは、ＭＭＴを介したＧ－ＰＣＣデータの配信をサポートしてよい（例えば、生成及び送信され得る）。
ＩＳＯＢＭＦＦ内のＧ－ＰＣＣコンポーネントは、複数のトラックを使用してシグナリングされ得る。（例えば、複数のトラックのうちの）（例えば、各）トラックは、別個のアセットにカプセル化されてもよく、別個のアセットは、（例えば、次いで）ＭＭＴＰパケットにパケット化されてもよい。Ｇ－ＰＣＣ定義されたアプリケーションメッセージは、例えば、サーバ及びクライアントが、特定のＧ－ＰＣＣコンポーネントへの、又は特定のＧ－ＰＣＣコンポーネントのための複数のアセットのグループを識別するために、（例えば、これもまた）構成／展開されてもよい。
いくつかの例では（例えば、ＭＭＴを使用してＧ－ＰＣＣコンテンツの配信をサポートするために）、マルチトラックＩＳＯＢＭＦＦ Ｇ－ＰＣＣコンテナ内の（例えば、各）トラックは、別個のアセットにカプセル化され得る。アセットの数は、マルチトラックＩＳＯＢＭＦＦ Ｇ－ＰＣＣコンテナ内のトラックの数に等しくなり得る。いくつかの例では、（例えば、単一の）Ｇ－ＰＣＣコンポーネントに対応する複数のアセットは、グループ化され、メッセージ（例えば、「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージ）中でアセットグループとしてシグナリングされ得る。代替コンポーネントトラックは、例えば、（例えば、ＭＭＴＰパケット内のＩＳＯＢＭＦＦファイルを最初に構文解析することなく）サーバ及びクライアント選択決定を（例えば、効率的に）可能にするために、（例えば、「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」メッセージを使用して）メッセージ内で公開されてもよい。
ＭＭＴは、アプリケーション固有シグナリングメッセージを定義してよく、これは、アプリケーション固有情報の配信をサポート（例えば、許容）してよい。Ｇ－ＰＣＣ固有のシグナリングメッセージは、ＭＭＴを使用してＧ－ＰＣＣ符号化されたデータをストリーミングするように定義（例えば、構成）されてよい。Ｇ－ＰＣＣ固有のシグナリングメッセージは、ユニフォームリソース名（ＵＲＮ）値（例えば、「ｕｒｎ：ｍｐｅｇ：ｍｍｔ：ａｐｐ：ｇｐｃｃ：２０２０」）」というＵＲＮ値）を有するアプリケーション識別子を有し得る。
図２６は、Ｇ－ＰＣＣアセット記述子の例示的なシンタックス構造を提供する表である。アセット記述子は、受信エンティティ及び消費アプリケーションに、Ｇ－ＰＣＣコンテンツを搬送するアセットのコンテンツについて通知するために使用され得る。Ｇ－ＰＣＣアセット記述子のセマンティクスが、本明細書で提供される。「ｄｅｓｃｒｉｐｔｏｒ＿ｔａｇ」は、記述子のタイプを示し得る。「Ｄｅｓｃｒｉｐｔｏｒ＿ｌｅｎｇｔｈ」は、このフィールドの後の次のバイトから記述子の最後のバイトまでカウントするバイト単位の長さを指定し得る。「Ｄａｔａ＿ｔｙｐｅ」は、このアセットグループに存在するＧ－ＰＣＣデータのタイプを示し得る。このフィールドの値は、図２９に更に示され、以下の段落で紹介され、実質的に説明され得る。「Ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ」は、Ｇ－ＰＣＣアセットが復号化のために別のＧ－ＰＣＣアセット内のデータに依存するかどうかを示し得る。０の値は、このＧ－ＰＣＣコンポーネントアセットグループデータが独立して復号化され得ることを示し得る。１の値は、このＧ－ＰＣＣアセットが復号化のために他のＧ－ＰＣＣアセットデータに依存することを示し得る。「ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ＿ｆｌａｇ」は、このＧ－ＰＣＣアセットが代替バージョンを有するか否かを示し得る。０の値は、このＧ－ＰＣＣコンポーネントアセットがいかなる代替アセットも持たないことを示し得る。１の値は、このＧ－ＰＣＣアセットが１つ以上の代替を有することを示し得る。「ａｌｔｅｒｎａｔｅ＿ｇｒｏｕｐ＿ｉｄ」は、代替アセットのグループを識別するＩＤを示し得る。同じＧ－ＰＣＣアセットの異なる符号化されたバージョンは、このフィールドに対して同じ値を有し得る。「Ｄｅｐ＿ａｓｓｅｔ＿ｉｄ」は、このアセットの復号化が依存するアセットＩＤの値を示し得る。場合によっては、この値は、ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇが１に設定されているときのみ存在し得る。例えば、Ｇ－ＰＣＣ属性コンポーネントアセットは、このフィールドのための対応するＧ－ＰＣＣジオメトリコンポーネントアセットＩＤを使用してもよい。「Ｎｕｍ＿ｔｉｌｅｓ」は、このアセットで搬送されるタイルの数を示し得る。ｔｉｌｅ＿ｉｄは、タイルインベントリ内の特定のタイルの一意の識別子を示す。ｄｙｎａｍｉｃ＿ｔｉｌｅ＿ｉｄ＿ｆｌａｇが値０に設定されているとき、ｔｉｌｅ＿ｉｄは、タイルインベントリ内に存在するタイルｉｄ値のうちの１つを表してよい。
ＭＭＴ Ｇ－ＰＣＣシグナリングは、例えば、ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅのようなグループメッセージ、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋのような選択フィードバックメッセージ、及び／又はＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋのような変更ビューフィードバックメッセージなどの（例えば、定義された）アプリケーションメッセージタイプのセットのうちの１つ以上を含んでよい。
図２７は、定義されたＧ－ＰＣＣアプリケーションメッセージタイプの例を例示する表である。図２７に示すように、アプリケーションメッセージタイプは、メッセージがＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋメッセージ、又はＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋメッセージであることを示し得る。ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅメッセージタイプの例では、送信エンティティは、サーバにおいて利用可能なアセットのセット、及び／又は受信エンティティにストリーミングされ得る（例えば、ストリーミングされている）アセットのリストについてクライアントに通知するために、グループメッセージ（例えば、ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅメッセージ）を送信し得る。選択フィードバックメッセージタイプ（例えば、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋメッセージタイプ）の一例では、クライアントは、選択フィードバックメッセージを使用して、アセットのセットが送信エンティティによって受信エンティティにストリーミングされることを要求してよい。変更ビューフィードバックメッセージ（例えば、ＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋメッセージ）の例では、クライアントは、ビュー変更フィードバックメッセージを使用して、ユーザの現在の視聴空間の指示をサーバに送信してよい。
グループメッセージ（例えば、ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅメッセージ）は、ＭＭＴを介してＧ－ＰＣＣ符号化されたコンテンツを送信するために使用され得る。グループメッセージ（例えば、ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅメッセージ）は、サーバにおいて利用可能なＧ－ＰＣＣデータタイプアセットのリストをクライアントに提供してもよい、及び／又はアセットのうちのどれが受信エンティティにストリーミングされ得るか（例えば、現在ストリーミングされているか）についてクライアントに通知してもよい。クライアントは、Ｇ－ＰＣＣデータタイプアセットの一意のサブセットを（例えば、リストから）要求してよい。要求は、例えば、ＧＰＣＣＳｅｌｅｃｔｉｏｎＦｅｅｄｂａｃｋメッセージを使用して行われてもよい。
クライアントは、（例えば、ＭＭＴを介したＧ－ＰＣＣコンテンツのビュー依存配信のために）ＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋメッセージを使用して、例えば、現在の視聴空間（例えば、錐台）情報をサーバに送信してもよい。サーバは、視聴空間に対応するアセットを選択し、クライアントに配信してよい。ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅは（例えば、また）更新され、クライアントに送信されてよい。表４は、定義されたＧ－ＰＣＣアプリケーションメッセージタイプの例を提供する。
図２８は、ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅなどのグループメッセージの例示的なシンタックスを例示する表である。図２８の表と一致して、ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅのセマンティクスは以下の通りであり得る。「Ｍｅｓｓａｇｅ＿ｉｄ」は、Ｇ－ＰＣＣアプリケーションメッセージの識別子を示し得る。「バージョン」は、Ｇ－ＰＣＣアプリケーションメッセージのバージョンを示し得る。「長さ」は、Ｇ－ＰＣＣアプリケーションメッセージの長さ（例えば、次のフィールドの先頭からメッセージの最後のバイトまでカウントするバイト単位）を示し得る。長さフィールドの値は、０（０）に等しくなくてもよい。アプリケーション識別子（例えば、「ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」）は、例えば、メッセージのコンテンツを消費する、アプリケーションのタイプを（例えば、一意に）識別するＵＲＮとして、アプリケーション識別子を示し得る。アプリケーションメッセージタイプ（例えば、「ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ」）は、（例えば、表４中の例によって与えられるような）アプリケーション固有メッセージタイプを定義し得る。アプリケーションメッセージタイプフィールドの長さは、例えば、８ビットであってもよい。Ｇ－ＰＣＣアセットグループの数（例えば、「ｎｕｍ＿ｇｐｃｃ＿ａｓｓｅｔ＿ｇｒｏｕｐｓ」）は、Ｇ－ＰＣＣアセットグループの数を示し得る。（例えば、各）アセットグループは、Ｇ－ＰＣＣコンポーネントに関連付けられたアセットを含んでよい。アセットグループ識別子（例えば、「ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」）は、Ｇ－ＰＣＣコンポーネントに関連付けられたアセットグループの識別子を示し得る。アセットの数（例えば、「ｎｕｍ＿ａｓｓｅｔｓ」）は、Ｇ－ＰＣＣコンポーネントに関連付けられたアセットグループ内のアセットの数を示し得る。開始時間（例えば、「ｓｔａｒｔ＿ｔｉｍｅ」）は、メッセージ中にリストされたアセットの状態が適用可能であり得るＧ－ＰＣＣコンポーネントの提示時間を示し得る。データタイプ（例えば、「ｄａｔａ＿ｔｙｐｅ」）は、図２９に関して以下の段落で更に説明される、アセットグループ内に存在するＧ－ＰＣＣ点群データのタイプを示し得る。保留フラグ（例えば、「ｐｅｎｄｉｎｇ＿ｆｌａｇ」）は、例えば、（例えば、全ての）データコンポーネントが、アセットグループのためにレンダリングする準備ができているかどうかを示し得る。「１」に設定された保留フラグは、データが準備完了であることを示し得る。０（「０」）に設定された保留フラグは、データの準備ができていないことを示し得る。依存フラグ（例えば、「ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ」）は、Ｇ－ＰＣＣコンポーネントアセットグループが復号化のために他のＧ－ＰＣＣコンポーネントアセットグループデータに依存するかどうかを示し得る。０（「０」）の値は、Ｇ－ＰＣＣコンポーネントアセットグループデータが独立して復号化され得ることを示し得る。１（「１」）の値は、Ｇ－ＰＣＣコンポーネントアセットグループが復号化のために他のＧ－ＰＣＣコンポーネントアセットグループデータに依存することを示し得る。依存アセットグループＩＤ（例えば、「ｄｅｐ＿ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」）は、アセットグループコンテンツ復号化が依存するアセットグループＩＤの値を示し得る。値は、例えば、ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇが１に設定される場合／ときに（例えば、そのような場合のみ）存在し得る。例えば、Ｇ－ＰＣＣ属性コンポーネントアセットグループは、依存アセットグループＩＤフィールドのために対応するＧ－ＰＣＣジオメトリコンポーネントアセットグループＩＤを使用してよい。アセットＩＤ（例えば、「ａｓｓｅｔ＿ｉｄ」）は、アセットのアセット識別子を提供し得る。代替アセットグループフラグ（例えば、「ａｌｔｅｒｎａｔｅ＿ａｓｓｅｔ＿ｇｒｏｕｐ＿ｆｌａｇ」）は、Ｇ－ＰＣＣコンポーネントアセットが代替バージョンを有するかどうかを示し得る。０（「０」）の値は、Ｇ－ＰＣＣコンポーネントアセットが代替バージョンを持たないことを示し得る。１（「１」）の値は、Ｇ－ＰＣＣコンポーネントアセットが代替バージョンを有することを示し得る。代替グループフラグフィールドの値は、例えば、同じＧ－ＰＣＣコンポーネント及び／又はアセットの異なる符号化バージョンがビットストリーム中で利用可能である場合／とき、１（「１」）に設定され得る。代替グループフラグフィールドの値は、例えば、同じＧ－ＰＣＣコンポーネント及び／又はアセットの異なる符号化されたバージョンがビットストリーム中で利用可能でない場合／とき、０（「０」）に設定され得る。代替アセットグループＩＤ（例えば、「ａｌｔｅｒｎａｔｅ＿ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」）は、代替Ｇ－ＰＣＣコンポーネントアセットの値（例えば、一意の値）を示し得る。Ｇ－ＰＣＣコンポーネント又はアセットの異なる符号化されたバージョンは、代替アセットグループＩＤフィールドについて同じ値を表してよい。状態フラグ（例えば、「ｓｔａｔｅ＿ｆｌａｇ」）は、アセットの配信状態を示し得る。１（「１」）に設定された状態フラグは、送信エンティティが受信エンティティにアセットをアクティブに送信していることを示し得る。０（「０」）に設定された状態フラグは、送信エンティティが受信エンティティにアセットをアクティブに送信していないことを示し得る。送信時間フラグ（例えば、「ｓｅｎｄｉｎｇ＿ｔｉｍｅ＿ｆｌａｇ」）は、アセットストリームの最初のＭＰＵを含む最初のＭＭＴＰパケットに対する送信時間（例えば、ｓｅｎｄｉｎｇ＿ｔｉｍｅ）の存在を示し得る。デフォルト値は、例えば、０（「０」）であってもよい。送信時間（例えば、「ｓｅｎｄｉｎｇ＿ｔｉｍｅ」）は、アセットストリームの最初のＭＰＵを含む最初のＭＭＴＰパケットの送信時間を示し得る。クライアントは、（例えば、送信時間情報を使用して）新しいアセットストリームのための新しいパケット処理パイプラインを準備してよい。動的タイルフラグ（例えば、「ｄｙｎａｍｉｃ＿ｔｉｌｅ＿ｆｌａｇ」）は、タイル及び／又はタイル識別子の数がアセット内で動的に変化し得るかどうかを示し得る。０（「０」）の値は、アセット中のタイルの数及びタイル識別子がビットストリーム全体にわたって変化しないこと、並びに／又はタイルの数（例えば、「ｎｕｍ＿ｔｉｌｅｓ」）及びタイルＩＤ（例えば、「ｔｉｌｅ＿ｉｄ」）がシグナリングされることを示し得る。１（「１」）の値は、タイルの数を示してよく、タイル識別子はアセット内で変化する場合がある。１（「１」）の値は、タイルトラック中に存在するタイルＩＤがビットストリーム中で時間と共に動的に変化していることを示し得る。タイルの数（例えば、「ｎｕｍ＿ｔｉｌｅｓ」）は、アセット内で搬送されるタイルの数を示し得る。タイルＩＤ（例えば、「ｔｉｌｅ＿ｉｄ」）は、タイルインベントリ内の特定のタイルに関する（例えば、一意の）識別子を示し得る。タイルＩＤ（例えば、「ｔｉｌｅ＿ｉｄ」）は、例えば、動的タイルフラグ（例えば、「ｄｙｎａｍｉｃ＿ｔｉｌｅ＿ｆｌａｇ」）が０（「０」）の値に設定される場合／ときに、タイルインベントリ内に存在するタイルｉｄ値（例えば、タイルｉｄ値のうちの１つ）を表してよい。
図２９は、Ｄａｔａ＿ｔｙｐｅフィールド中で使用され得る例示的なＧ－ＰＣＣデータタイプ値を示す表である。図２４に示されているように、Ｄａｔａ＿ｔｙｐｅフィールドの値は、全てのＧ－ＰＣＣコンポーネントデータ、ジオメトリデータ、属性データ、ＳＰＳ、ＧＰＳ、ＡＰＳ、及びタイルインベントリデータ、又は３Ｄ空間領域時限メタデータ情報を示してよい。
図３０は、ＧＰＣＣ選択フィードバックメッセージ（例えば、「ＧＰＣＣＳｅｌｅｃｔｉｏｎＦｅｅｄｂａｃｋ」）の例示的なシンタックスを示す表である。図３０の表と一致して、ＧＰＣＣＳｅｌｅｃｔｉｏｎＦｅｅｄｂａｃｋメッセージのセマンティクスは、以下の通りであり得る。メッセージＩＤ（例えば、「ｍｅｓｓａｇｅ＿ｉｄ」）は、Ｇ－ＰＣＣアプリケーションメッセージの識別子を示し得る。バージョン（例えば、「ｖｅｒｓｉｏｎ」）は、Ｇ－ＰＣＣアプリケーションメッセージのバージョンを示し得る。長さ（例えば、「ｌｅｎｇｔｈ」）は、Ｇ－ＰＣＣアプリケーションメッセージの長さ（例えば、次のフィールドの先頭からメッセージの最後のバイトまでカウントするバイト単位）を示し得る。長さフィールドの値は０に等しくなくてもよい。アプリケーション識別子（例えば、「ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」）は、例えば、メッセージのコンテンツを消費する、アプリケーションのタイプを（例えば、一意に）識別するＵＲＮとして、アプリケーション識別子を示し得る。アプリケーションメッセージタイプ（例えば、「ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ」）は、（例えば、図２７に関して上記の段落で実質的に説明された）アプリケーション固有のメッセージタイプを定義し得る。アプリケーションメッセージタイプフィールドの長さは、例えば、８ビットであってもよい。選択されたアセットグループの数（例えば、「ｎｕｍ＿ｓｅｌｅｃｔｅｄ＿ａｓｓｅｔ＿ｇｒｏｕｐｓ」）は、受信エンティティによる関連付けられた状態変更要求が存在するアセットグループの数を示し得る。アセットグループＩＤ（例えば、「ａｓｓｅｔ＿ｇｒｏｕｐ＿ｉｄ」）は、Ｇ－ＰＣＣコンテンツに関連付けられたアセットグループの識別子を示し得る。スイッチングモード（例えば、「ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅ」）は、（例えば、受信エンティティによって要求されるような）アセットの選択のために使用されるスイッチングモードを示し得る。アセットの数（例えば、「ｎｕｍ＿ａｓｓｅｔｓ」）は、（例えば、指定されたスイッチングモードに従って）状態変化のためにシグナリングされたアセットの数を示し得る。アセットＩＤ（例えば、「ａｓｓｅｔ＿ｉｄ」）は、（例えば、指定されたスイッチングモードに従って）状態変化のためのアセットの識別子を示し得る。
図３１は、ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅフィールドの定義を示す表である。図３１に示すように、「ｓｗｉｔｃｈｉｎｇ＿ｍｏｄｅ」フィールドは、アセットの選択のために使用されるスイッチングモードを示し得る。例えば、スイッチングモードがリフレッシュに設定されている場合、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋにリストされている各アセットについて、各アセットのＳｔａｔｅ＿ｆｌａｇは「１」に設定され、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋ ｗｉｌｌにリストされていない全てのアセットのＳｔａｔｅ＿ｆｌａｇは「０」に設定される。スイッチングモードがトグルするように設定される場合、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋにリストされた各アセットについて、各アセットのＳｔａｔｅ＿ｆｌａｇは、例えば、元々「０」であれば「１」に、元々「１」であれば「０」に変更されるが、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋにリストされていない全てのアセットのＳｔａｔｅ＿ｆｌａｇは変更されない。スイッチングモードが、ＧＰＣＣＳｅｌｅｃｔｉｏｎＭｅｓｓａｇｅＦｅｅｄｂａｃｋで指定されたアセットグループの全てのアセットに対して、全てを送信するように設定される場合、各アセットのＳｔａｔｅ＿ｆｌａｇは、「１」に設定される。
図３２は、Ｇ－ＰＣＣビュー変更フィードバックメッセージ（例えば、「ＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋ」）の例示的なシンタックスを示す表である。図３２の表と一致して、ＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋメッセージのセマンティクスは、以下の通りであり得る。メッセージＩＤ（例えば、「ｍｅｓｓａｇｅ＿ｉｄ」）は、Ｇ－ＰＣＣアプリケーションメッセージの識別子を示し得る。バージョンは、Ｇ－ＰＣＣアプリケーションメッセージのバージョンを示し得る。長さは、Ｇ－ＰＣＣアプリケーションメッセージの長さを（例えば、次のフィールドの先頭からメッセージの最後のバイトまでカウントするバイト単位で）示し得る。長さフィールドの値は０に等しくなくてもよい。アプリケーション識別子（例えば、「ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」）は、例えば、メッセージのコンテンツを消費する、アプリケーションのタイプを（例えば、一意に）識別するＵＲＮとして、アプリケーション識別子を示し得る。アプリケーションメッセージタイプ（例えば、「ａｐｐ＿ｍｅｓｓａｇｅ＿ｔｙｐｅ」）は、（例えば、表４中の例によって与えられるような）アプリケーション固有メッセージタイプを定義し得る。アプリケーションメッセージタイプフィールドの長さは、例えば、８ビットであってもよい。ビューポート位置座標（例えば、ｖｐ＿ｐｏｓ＿ｘ、ｖｐ＿ｐｏｓ＿ｙ、ｖｐ＿ｐｏｓ＿ｚ）は、グローバル基準座標系におけるビューポートの位置のｘ座標、ｙ座標、及びｚ座標をメートル単位で示し得る。値は、例えば、２－１６メートルの単位であってもよい。ビューポート回転（例えば、ｖｐ＿ｑｕａｔ＿ｘ、ｖｐ＿ｑｕａｔ＿ｙ、ｖｐ＿ｑｕａｔ＿ｚ）は、ビューポート領域の回転のｘ、ｙ、及びｚ成分を（例えば、四元数表現を使用して）示し得る。値は、例えば、両端値を含む－１から１の範囲内の浮動小数点値であり得る。値は、グローバル座標軸をカメラ（例えば、四元数表現を使用する）のローカル座標軸に変換するために適用される回転のｘ、ｙ、及びｚ成分（例えば、ｑＸ、ｑＹ及びｑＺ）を指定し得る。四元数ｑＷの第４の成分は、例えば、上記の段落に実質的に記載されている式１に従って計算されてよい。点（ｗ、ｘ、ｙ、ｚ）は、これもまた上記の段落に実質的に記載されている式２に従って決定された角度だけ、ベクトル（ｘ、ｙ、ｚ）によって方向付けられた軸の周りの回転を表してよい。
近平面（例えば、ｃｌｉｐｐｉｎｇ＿ｎｅａｒ＿ｐｌａｎｅ）でのクリッピング及び遠平面（例えば、ｃｌｉｐｐｉｎｇ＿ｆａｒ＿ｐｌａｎｅ）でのクリッピングは、例えば、ビューポートの近クリッピング平面及び遠クリッピング平面（例えば、メートル単位）に基づいて、近深度及び遠深度又は距離を示してよい。
水平視野（ＦＯＶ）（例えば、ｈｏｒｉｚｏｎｔａｌ＿ｆｏｖ）は、ビューポート領域の水平サイズに対応する経度範囲を（例えば、ラジアン単位で）指定してよい。この値は、０～２πの範囲内であってもよい。
垂直ＦＯＶ（例えば、ｖｅｒｔｉｃａｌ＿ｆｏｖ）は、ビューポート領域の垂直サイズに対応する緯度範囲を（例えば、ラジアン単位で）指定してよい。この値は、０～πの範囲内であってもよい。
ストリーミングクライアント挙動が提供され得る（例えば、定義又は構成され得る）。ＭＭＴクライアントは、例えば、アプリケーション固有シグナリングメッセージにおいて提供される情報によってガイドされてもよい。クライアント挙動の例は、（例えば、本明細書で開示されるＭＭＴシグナリングの例を使用して）ジオメトリベースの点群圧縮コンテンツをストリーミングするために提供される。
ＭＭＴ送信エンティティは、関心のあるクライアントに「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージを送信してよい。受信クライアントは、「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージを構文解析し、ＭＭＴコンテンツ送信エンティティに存在するＧ－ＰＣＣメディアアセットを識別してよい。ストリーミングクライアントは、「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージ内の「ａｐｐｌｉｃａｔｉｏｎ＿ｉｄｅｎｔｉｆｉｅｒ」フィールド（例えば、「ｕｒｎ：ｍｐｅｇ：ｍｍｔ：ａｐｐ：ｇｐｃｃ：２０２０”）」に設定される）をチェックして、例えば、利用可能なＧ－ＰＣＣメディアコンテンツを識別してもよい。Ｇ－ＰＣＣ点群コンテンツ内で利用可能なＧ－ＰＣＣアセット（例えば、全てのＧ－ＰＣＣアセット）は、例えば、「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージ内に存在するａｓｓｅｔ＿ｉｄをチェックすることによって識別されてもよい。クライアントは、例えば、ユーザの現在のビューポートに基づいて、ストリーミングされるべきａｓｓｅｔ＿ｉｄを選んでもよい（例えば、選択してもよい）。ＭＭＴクライアントは、利用可能なＧ－ＰＣＣアセットのリストから関心のあるＧ－ＰＣＣアセットを要求する「ＧＰＣＣＳｅｌｅｃｔｉｏｎＦｅｅｄｂａｃｋ」アプリケーションメッセージを送信エンティティに送信してよい。ＭＭＴ送信エンティティは、ＭＴＰでＭＭＴＰパケットを形成してよい。ＭＭＴ送信エンティティは、ＭＴＴＰパケットをクライアントに送信してよい。ＭＭＴクライアントは、ＭＭＴＰパケットを受信してよい。ＭＭＴクライアントは、ＭＰＵ又はＭＦＵをデパケット化してよい。ＭＰＵ／ＭＦＵは、時限又は非時限Ｇ－ＰＣＣメディアコンテンツを含んでもよい。
Ｇ－ＰＣＣアセットデータは、例えば、ＭＭＴクライアントがアセットグループ「ｄａｔａ＿ｔｙｐｅ」が「３」に設定されたＭＭＴＰパケットを受信する場合、初期化情報（例えば、ＳＰＳ、ＧＰＳ、ＡＰＳ、及び／又はタイルインベントリ）を表してよい。Ｇ－ＰＣＣアセットデータは、例えば、ＭＭＴクライアントがアセットグループ「ｄａｔａ＿ｔｙｐｅ」が「４」に設定されたＭＭＴＰパケットを受信する場合、３Ｄ空間領域時限メタデータ情報を表してよい。Ｇ－ＰＣＣアセット情報は、Ｇ－ＰＣＣデータの部分アクセスのために使用されてよい。
ＭＭＴクライアントは、ユーザビューポート及び対応する３Ｄ空間領域に基づいてＧ－ＰＣＣアセットを選択してよい。ＭＭＴクライアントは、対象のＧ－ＰＣＣアセットを要求する送信エンティティに「ＧＰＣＣＳｅｌｅｃｔｉｏｎＦｅｅｄｂａｃｋ」アプリケーションメッセージを送信してよい。ＭＭＴクライアントは、例えば、ユーザビューポートが変更される場合／ときに、（例えば、「ＧＰＣＣＳｅｌｅｃｔｉｏｎＦｅｅｄｂａｃｋ」アプリケーションメッセージを用いて）Ｇ－ＰＣＣアセットの異なるセットを要求してよい。
ＭＭＴクライアントは、例えば、ユーザビューポートが変更される場合／ときに、「ＧＰＣＣＶｉｅｗＣｈａｎｇｅＦｅｅｄｂａｃｋ」メッセージを送信エンティティに（例えば、ユーザの現在ビューポートをシグナリングするために）送信してよい。ＭＭＴ送信エンティティは、（例えば、ＭＭＴクライアントからメッセージを受信すると）、（例えば、ユーザの新しいビューポート情報に基づいて）Ｇ－ＰＣＣアセットを選択してよい。ＭＭＴ送信エンティティは、「ＧＰＣＣＡｓｓｅｔＧｒｏｕｐＭｅｓｓａｇｅ」アプリケーションメッセージを対応するＧ－ＰＣＣアセットと共にＭＭＴクライアントに送信してよい。ＭＭＴ送信エンティティは、Ｇ－ＰＣＣアセットデータをＭＭＴＰパケットとしてストリーミングしてよい。
ＭＭＴクライアントは、要求されたＧ－ＰＣＣアセット（例えば、全て）に対するＭＭＴＰパケットの受信を開始してよい。ＭＭＴクライアントは、ＭＭＴＰペイロードからＭＰＵ及びＭＦＵを抽出してよい。ＭＰＵ及びＭＦＵは、メディアサンプル（例えば、直接）又はメディアセグメントを含んでよい。
ＭＭＴクライアントは、メディアセグメントコンテナ（例えば、ＩＳＯＢＭＦＦ）の構文解析を開始して、エレメンタリストリーム情報を抽出し、Ｇ－ＰＣＣビットストリームを構造化し、ビットストリームをＧ－ＰＣＣデコーダに渡してよい。例えば、ＭＭＴＰペイロードがＧ－ＰＣＣメディアサンプルを含む場合／とき、エレメンタリストリームデータは抽出及び構造化されてもよく、ビットストリームはＧ－ＰＣＣデコーダに渡されてもよい。
ジオメトリベースの点群（Ｇ－ＰＣＣ）のＭＰＥＧメディアトランスポート（ＭＭＴ）ストリーミングのためのシステム、方法、及び装置が本明細書で説明されている。Ｇ－ＰＣＣ符号化されたコンテンツは、ＭＭＴを使用してネットワークを介して配信されてよい。Ｇ－ＰＣＣデータは、ＭＭＴストリーミングのためにカプセル化されてよい。ＭＭＴシグナリングメッセージは、ＭＭＴを介したＧ－ＰＣＣデータの配信をサポートし得る。（例えば、各）トラックは、例えば、国際規格化機構ベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）内のＧ－ＰＣＣコンポーネントが複数のトラックを使用してシグナリングされる場合／とき、ＭＭＴＰパケットにパケット化され得る別個のアセットにカプセル化されてもよい。Ｇ－ＰＣＣ定義アプリケーションメッセージは、サーバ及びクライアントが、Ｇ－ＰＣＣコンポーネントのための複数のアセットのグループを識別することを可能にし得る。
特徴及び要素は、特定の組み合わせにおいて上で説明されているが、当業者は、各特徴又は要素が単独で又は他の特徴及び要素との任意の組み合わせで使用され得ることを理解されよう。更に、本明細書に説明される方法は、コンピュータ又はプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア又はファームウェアに実装され得る。コンピュータ可読媒体の例には、電子信号（有線又は無線接続を介して送信される）及びコンピュータ可読記憶媒体が含まれる。コンピュータ可読記憶媒体の例としては、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスク及びリムーバブルディスクなどの磁気媒体、磁気光学媒体及びＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（digital versatile disk、ＤＶＤ）などの光学媒体が挙げられるが、これらに限定されない。ソフトウェアと関連付けられたプロセッサを使用して、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ又は任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装し得る。

Claims (18)

  1. 受信デバイスにおいて実施される方法であって、前記方法は、
    送信デバイスから、
    前記送信デバイスから前記受信デバイスにストリーミングされるのに利用可能なメディアアセットのリストを含む第１のメッセージ、又は
    前記送信デバイスから前記受信デバイスにストリーミングされるのに利用可能な前記メディアアセットをそれぞれ記述する１つ以上のメッセージのうちの少なくとも１つを受信することと、前記送信デバイスから前記受信デバイスにストリーミングされるべき前記メディアアセットのサブセットの要求であって、前記メディアアセットの前記要求されたサブセットが、前記受信デバイスのビューポートに基づいて決定される、前記メディアアセットの前記要求されたサブセットを示す情報を含む第２のメッセージを前記送信デバイスに送信することと、
    前記送信デバイスから、前記第２のメッセージに応答して、１つ以上のモーションピクチャエキスパートグループ（Motion Picture Experts Group）（ＭＰＥＧ）メディアトランスポートプロトコル（Media Transport Protocol）（ＭＭＴＰ）パケットを受信することと、
    前記１つ以上のＭＭＴＰパケットを処理して、前記メディアアセットの前記要求されたサブセットの少なくとも一部を復元することとを含む方法。
  2. 前記送信デバイスから前記受信デバイスにストリーミングされるべき前記メディアアセットの更新されたサブセットであって、前記メディアアセットの前記要求された更新されたサブセットが、前記受信デバイスの更新されたビューポートに基づいて決定される、前記メディアアセットの前記要求された更新されたサブセットについての要求を示す情報を含む第３のメッセージを前記送信デバイスに送信することを更に含む、請求項１に記載の方法。
  3. 前記送信デバイスから受信された前記第１のメッセージは、前記メディアアセットのリストに関連付けられたアプリケーションを識別する情報を更に含む、請求項１に記載の方法。
  4. 前記アプリケーションを識別する前記情報は、前記アプリケーションがビジュアルボリュメトリックビデオベースコーディング（Ｖ３Ｃ）データを消費することを示す、請求項３に記載の方法。
  5. 前記アプリケーションを識別する前記情報は、前記アプリケーションがジオメトリベースの点群圧縮（Ｇ－ＰＣＣ）データを消費することを示す、請求項３に記載の方法。
  6. 前記第１のメッセージは、復号化のためのメディアアセットの別のメディアアセットへの依存性と、前記メディアアセットが依存する前記別のメディアアセットの指示と、メディアアセットが代替バージョンを有するかどうかと、前記メディアアセットの前記代替バージョンの識別のうちの１つ以上を示す情報を含む、請求項１に記載の方法。
  7. 受信デバイスであって、
    プロセッサと、
    通信インターフェースとを備え、
    前記プロセッサ及び前記通信インターフェースは、送信デバイスから
    前記送信デバイスから前記受信デバイスにストリーミングされるのに利用可能なメディアアセットのリストを示す情報を含む第１のメッセージ、又は
    前記送信デバイスから前記受信デバイスにストリーミングされるのに利用可能な前記メディアアセットをそれぞれ記述する１つ以上のメッセージのうちの少なくとも１つを受信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記送信デバイスから前記受信デバイスにストリーミングされるべき前記メディアアセットのサブセットであって、前記メディアアセットの前記要求されたサブセットが、前記受信デバイスのビューポートに基づいて決定される、前記メディアアセットのサブセットについての要求を示す情報を含む第２のメッセージを前記送信デバイスに送信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記第２のメッセージに応答して、１つ以上のモーションピクチャエキスパートグループ（Motion Picture Experts Group）（ＭＰＥＧ）メディアトランスポートプロトコル（Media Transport Protocol）（ＭＭＴＰ）パケットを前記送信デバイスから受信するように構成され、
    前記プロセッサは、前記１つ以上のＭＭＴＰパケットを処理して、前記メディアアセットの前記要求されたサブセットの少なくとも一部を復元するように構成される、受信デバイス。
  8. 前記送信デバイスから前記受信デバイスにストリーミングされるべき前記メディアアセットの更新されたサブセットであって、前記メディアアセットの前記要求された更新されたサブセットが、前記受信デバイスの更新されたビューポートに基づいて決定される、前記メディアアセットの前記要求された更新されたサブセットについての要求を示す情報を含む第３のメッセージを前記送信デバイスに送信することを更に含む、請求項７に記載の受信デバイス。
  9. 前記送信デバイスから受信された前記第１のメッセージは、前記メディアアセットのリストに関連付けられたアプリケーションを識別する情報を更に含む、請求項７に記載の受信デバイス。
  10. 前記アプリケーションを識別する前記情報は、前記アプリケーションがビジュアルボリュメトリックビデオベースコーディング（Ｖ３Ｃ）データを消費することを示す、請求項９に記載の受信デバイス。
  11. 前記アプリケーションを識別する前記情報は、前記アプリケーションがジオメトリベースの点群圧縮（Ｇ－ＰＣＣ）データを消費することを示す、請求項９に記載の受信デバイス。
  12. 前記第１のメッセージは、復号化のためのメディアアセットの別のメディアアセットへの依存性と、前記メディアアセットが依存する前記別のメディアアセットの指示と、メディアアセットが代替バージョンを有するかどうか、及び前記メディアアセットの前記代替バージョンの識別のうちの１つ以上を示す情報を含む、請求項７に記載の受信デバイス。
  13. 受信デバイスであって、
    プロセッサと、
    通信インターフェースとを備え、
    前記プロセッサ及び前記通信インターフェースは、送信デバイスから
    前記送信デバイスから前記受信デバイスにストリーミングされるのに利用可能なメディアアセットのセットを示す情報を含む第１のメッセージ、又は
    前記送信デバイスから前記受信デバイスにストリーミングされるのに利用可能な前記メディアアセットをそれぞれ記述する１つ以上のメッセージのうちの少なくとも１つを受信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記受信デバイスのビューポートを示す情報を含む第２のメッセージを前記送信デバイスに送信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記送信デバイスから、前記送信デバイスから前記受信デバイスにストリーミングされるべき前記メディアアセットのサブセットであって、前記メディアアセットの前記示されたサブセットが、前記受信デバイスの前記示されたビューポートに基づいて決定される、前記メディアアセットの前記示されたサブセットを示す情報を含む第３のメッセージを受信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記送信デバイスから、前記第3のメッセージに応答して、１つ以上のモーションピクチャエキスパートグループ（Motion Picture Experts Group）（ＭＰＥＧ）メディアトランスポートプロトコル（Media Transport Protocol）（ＭＭＴＰ）パケットを受信するように構成され、
    前記プロセッサは、前記１つ以上のＭＭＴＰパケットを処理して、前記メディアアセットの前記示されたサブセットの少なくとも一部を復元するように構成される、受信デバイス。
  14. 前記プロセッサ及び前記通信インターフェースは、前記受信デバイスの更新されたビューポートを示す情報を含む第４のメッセージを前記送信デバイスに送信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記送信デバイスから、前記更新されたビューポートに関連付けられたメディアアセットの更新されたセットを示す情報を含む第４のメッセージを受信するように構成され、
    前記プロセッサ及び前記通信インターフェースは、前記送信デバイスから別の１つ以上のＭＭＴＰパケットを受信するように構成され、
    前記プロセッサは、前記別の１つ以上のＭＭＴＰパケットを処理して、前記受信デバイスの前記更新されたビューポートに関連付けられたメディアアセットの前記更新されたセットの前記少なくとも一部分を復元するように構成される、請求項１３に記載の受信デバイス。
  15. 前記送信デバイスから受信された前記第１のメッセージは、前記メディアアセットのリストに関連付けられたアプリケーションを識別する情報を更に含む、請求項１３に記載の受信デバイス。
  16. 前記アプリケーションを識別する前記情報は、前記アプリケーションがビジュアルボリュメトリックビデオベースコーディング（Ｖ３Ｃ）データを消費することを示す、請求項１５に記載の受信デバイス。
  17. 前記アプリケーションを識別する前記情報は、前記アプリケーションがジオメトリベースの点群圧縮（Ｇ－ＰＣＣ）データを消費することを示す、請求項１５に記載の受信デバイス。
  18. 前記第１のメッセージは、復号化のためのメディアアセットの別のメディアアセットへの依存性と、前記メディアアセットが依存する前記別のメディアアセットの指示と、メディアアセットが代替バージョンを有するかどうか、及び前記メディアアセットの前記代替バージョンの識別のうちの１つ以上を示す情報を含む、請求項１３に記載の受信デバイス。
JP2023540501A 2021-01-05 2022-01-05 ビジュアルボリュメトリックビデオベース（ｖ３ｃ）及びジオメトリベース点群（ｇ－ｐｃｃ）メディアのストリーミングのためのｍｍｔシグナリング Pending JP2024502822A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202163134038P 2021-01-05 2021-01-05
US202163134143P 2021-01-05 2021-01-05
US63/134,038 2021-01-05
US63/134,143 2021-01-05
PCT/US2022/011298 WO2022150376A1 (en) 2021-01-05 2022-01-05 Mmt signaling for streaming of visual volumetric video-based (v3c) and geometry-based point cloud (g-pcc) media

Publications (1)

Publication Number Publication Date
JP2024502822A true JP2024502822A (ja) 2024-01-23

Family

ID=80050976

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023540501A Pending JP2024502822A (ja) 2021-01-05 2022-01-05 ビジュアルボリュメトリックビデオベース（ｖ３ｃ）及びジオメトリベース点群（ｇ－ｐｃｃ）メディアのストリーミングのためのｍｍｔシグナリング

Country Status (6)

Country Link
US (1) US20240022773A1 (ja)
EP (1) EP4275358A1 (ja)
JP (1) JP2024502822A (ja)
KR (1) KR20230129259A (ja)
IL (1) IL304205A (ja)
WO (1) WO2022150376A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220329857A1 (en) * 2021-04-13 2022-10-13 Samsung Electronics Co., Ltd. Mpeg media transport (mmt) signaling of visual volumetric video-based coding (v3c) content

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3818716A4 (en) * 2018-07-02 2022-06-01 Nokia Technologies Oy DEVICE, METHOD AND COMPUTER PROGRAM FOR VIDEO ENCODING AND DECODING
US11823421B2 (en) * 2019-03-14 2023-11-21 Nokia Technologies Oy Signalling of metadata for volumetric video
KR20230153532A (ko) * 2019-03-21 2023-11-06 엘지전자 주식회사 포인트 클라우드 데이터 부호화 장치, 포인트 클라우드 데이터 부호화 방법, 포인트 클라우드 데이터 복호화 장치 및 포인트 클라우드 데이터 복호화 방법

Also Published As

Publication number Publication date
EP4275358A1 (en) 2023-11-15
WO2022150376A1 (en) 2022-07-14
US20240022773A1 (en) 2024-01-18
KR20230129259A (ko) 2023-09-07
IL304205A (en) 2023-09-01

Similar Documents

Publication Publication Date Title
US11568573B2 (en) Methods and apparatus for point cloud compression bitstream format
US20240195999A1 (en) Dynamic adaptation of volumetric content component sub-bitstreams in streaming services
US20230188751A1 (en) Partial access support in isobmff containers for video-based point cloud streams
JP2023536725A (ja) ジオメトリベースのポイントクラウドデータのためのタイルトラック
US20220329923A1 (en) Video-based point cloud streams
AU2020280072A1 (en) Video-based point cloud streams
US20240022773A1 (en) Mmt signaling for streaming of visual volumetric video-based and geometry-based point cloud media
US20230276053A1 (en) Adaptive streaming of geometry-based point clouds
CN116830588A (zh) 用于基于视觉体积视频（v3c）媒体和基于几何的点云（g-pcc）媒体的流式传输的mmt信令
WO2024006279A1 (en) Signaling parameter sets for geometry-based point cloud streams
KR20240089338A (ko) 기하구조 기반 포인트 클라우드의 적응적 스트리밍
WO2023059730A1 (en) Adaptive streaming of geometry-based point clouds