Methods to encapsulate and carry coded basemesh data of video-based dynamic mesh coding bitstreams in isobmff media containers

By generating track references for sub-streams and encapsulating them in ISOBMFF, the method addresses the challenge of compressing video-based dynamic meshes, improving the efficiency of immersive media rendering.

WO2026015360A1PCT designated stage Publication Date: 2026-01-15INTERDIGITAL VC HOLDINGS INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
PCT/US2025/036317
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-07-09
Filing Date
2025-07-02
Publication Date
2026-01-15

AI Technical Summary

Technical Problem

Existing technologies face challenges in efficiently compressing and encapsulating video-based dynamic mesh coding bitstreams in ISOBMFF media containers, which is crucial for immersive media applications like extended reality (XR).

Method used

The method involves generating track references for sub-streams including an atlas sub-stream, basemesh sub-stream, and submesh sub-streams, and encapsulating them in a container file format like ISOBMFF, with reference identifiers to link these sub-streams, enabling efficient compression and decoding of dynamic meshes.

Benefits of technology

This approach allows for effective compression and decoding of dynamic meshes, enhancing the rendering of immersive media by reducing computational complexity and improving media playback efficiency.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure US2025036317_15012026_PF_FP_ABST
    Figure US2025036317_15012026_PF_FP_ABST
Patent Text Reader

Abstract

Some embodiments of a method may include: receiving, by an encoder, one or more sub-streams of a media content item, wherein the one or more sub-streams comprise an atlas sub-stream, a basemesh sub-stream, and one or more submesh sub-streams; generating, by the encoder, a plurality of track references; and encapsulating, by the encoder, the plurality of sub-streams in a container file format, wherein the container file format comprises a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.
Need to check novelty before this filing date? Find Prior Art

Description

METHODS TO ENCAPSULATE AND CARRY CODED BASEMESH DATA OF VIDEO-BASED DYNAMIC MESH CODING BITSTREAMS IN ISOBMFF MEDIA CONTAINERSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims benefit of U.S. Provisional Patent Application No. 63 / 669,186, entitled “METHODS TO ENCAPSULATE AND CARRY CODED BASEMESH DATA OF VIDEO-BASED DYNAMIC MESH CODING BITSTREAMS IN ISOBMFF MEDIA CONTAINERS” and filed July 9, 2024, which is hereby incorporated by reference in its entirety.INCORPORATION BY REFERENCE

[0002] The present application incorporates by reference in their entirety the following applications: U.S. Provisional Patent Application Serial No. 63 / 622,977, entitled “Carriage of Coded Base Mesh and Displacement Data of Video-based Dynamic Mesh Coding in ISOBMFF Media Containers” and filed January 19, 2024 (‘“977 application”); European Patent Application Serial No. EP24305101 , entitled “SIGNALING SUPPLEMENTARY INFORMATION RELATED TO ATTRIBUTES IN V3C BITSTREAM AND BASEMESH BITSTREAM” and filed January 16, 2024 (‘“101 application”), European Patent Application Serial No. EP24306096, entitled “METHODS TO SIGNAL MESH ATTRIBUTES FOR RECONSTRUCTION IN THE V-DMC BITSTREAM” and filed July 3, 2024 (“‘096 application”)BACKGROUND

[0003] Working Group 7 (WG7) of the Motion Picture Experts Group (MPEG) is understood to be currently working on developing a new standard (ISO / IEC 23090-29) for efficient compression of dynamic meshes. This new standard, titled ‘Video-based Dynamic Mesh Coding (V-DMC)”, extends the ISO / IEC 23090-5 specification for Visual Volumetric Video-based Coding (V3C) (Information Technology- Coded Representation of Immersive Media - Part 5: Visual Volumetric Video-Based Coding (V3C) and Video-Based Point Cloud Compression (V- PCC), ISO / IEC 23090-5 (2023), available at iso<dot>org / standard / 83535<dot>html (“ISO / IEC 23090-5”)). The latest committee draft (CD) version of the V-DMC specification may be found in S. 2. Secretariat, Text of ISO / IECCD 23090-29 Video-Based Mesh Coding, ISO / IEC CD 23090-29 (June 4, 2024), available at: dms<dot>mpeg<dot>expert / doc_end_user / documents / 146_Rennes / wg11 / MDS23903_WG07_N00885<dot>zi p (“ISO / IEC CD 23090-29”).SUMMARY

[0004] A first example method in accordance with some embodiments may include: receiving, by an encoder, one or more sub-streams of a media content item, wherein the one or more sub-streams include an atlas substream, a basemesh sub-stream, and one or more submesh sub-streams; generating, by the encoder, a plurality of track references; and encapsulating, by the encoder, the plurality of sub-streams in a container file format, wherein the container file format includes a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.

[0005] For some embodiments of the first example method, the container file format includes an International Standards Organization Base Media File Format (ISOBMFF).

[0006] For some embodiments of the first example method, the atlas sub-stream includes a V3C atlas track, and the basemesh sub-stream includes a basemesh track.

[0007] For some embodiments of the first example method, the file format further includes a track reference to link the atlas sub-stream to the basemesh sub-stream.

[0008] For some embodiments of the first example method, the file format further includes a submesh track reference to link the basemesh sub-stream to a submesh track.

[0009] For some embodiments of the first example method, the submesh track includes one or more submesh subsamples.

[0010] For some embodiments of the first example method, at least one of the one or more submesh subsamples corresponds to one of the one or more submesh sub-streams.

[0011] For some embodiments of the first example method, the file format further includes atlas tile track information.

[0012] For some embodiments of the first example method, the atlas tile track information includes information corresponding to the atlas sub-stream.

[0013] For some embodiments of the first example method, the atlas tile track information includes one or more submesh identifiers.

[0014] For some embodiments ofthe first example method, at leastone ofthe one or more submesh identifiers corresponds to one of the one or more submesh sub-streams.

[0015] For some embodiments of the first example method, at least one of the sub-streams corresponds to a track in the encapsulated container file format.

[0016] A media consumption device in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0017] At least one processor in accordance with some embodiments may be operatively connected to at least one transceiver, the at least one processor and at least one transceiver configured to perform any one of the methods shown above.

[0018] A network device in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0019] A computing device in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0020] An integrated circuit in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0021] A first example method / apparatus in accordance with some embodiments may include: a processor; and a computer-readable medium storing instructions operative, when executed by the processor, to cause the apparatus to: receive, by an encoder, one or more sub-streams of a media content item, wherein the one or more sub-streams include an atlas sub-stream, a basemesh sub-stream, and one or more submesh sub-streams; generate, by the encoder, a plurality of track references; and encapsulate, by the encoder, the plurality of substreams in a container file format, wherein the container file format includes a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.

[0022] A second example method in accordance with some embodiments may include: obtaining an encoded bitstream corresponding to a media content item; decoding, by a decoder, the encoded bitstream into a decoded bitstream; splitting the decoded bitstream into container file format data and one or more sub-streams, wherein the one or more sub-streams include an atlas sub-stream, a basemesh sub-stream, and one or more submeshsub-streams, and wherein the container file format data includes a reference identifier for the basemesh substream and reference identifiers for each of the one or more submesh sub-streams.

[0023] For some embodiments of the second example method, the container file format includes an International Standards Organization Base Media File Format (ISOBMFF).BRIEF DESCRIPTION OF THE DRAWINGS

[0024] FIG. 1 A is a system diagram illustrating an example set of interfaces for a system according to some embodiments.

[0025] FIG. 1 B is a system diagram illustrating an example set of interfaces for a scene description (stored as an item in gITF.json), three video tracks, an audio track, and a JSON patch update track in an ISOBMFF file according to some embodiments.

[0026] FIG. 2A is a functional block diagram of block-based video encoder, such as an encoder used for Versatile Video Coding (VVC), according to some embodiments.

[0027] FIG. 2B is a functional block diagram of a block-based video decoder, such as a decoder used for VVC, according to some embodiments.

[0028] FIG. 3 is a system diagram illustrating an example set of interfaces for atlas tile track and basemesh submesh track grouping according to some embodiments.

[0029] FIG. 4 is a flowchart illustrating an example process for populating a file in a container file format according to some embodiments.

[0030] The entities, connections, arrangements, and the like that are depicted in— and described in connection with— the various figures are presented by way of example and not by way of limitation. As such, any and all statements or other indications as to what a particular figure “depicts,” what a particular element or entity in a particular figure “is” or “has,” and any and all similar statements— that may in isolation and out of context be read as absolute and therefore limiting— may only properly be read as being constructively preceded by a clause such as “In at least one embodiment, ... " For brevity and clarity of presentation, this implied leading clause is not repeated ad nauseam in the detailed description.DETAILED DESCRIPTION

[0031] FIG. 1 A is a system diagram illustrating an example set of interfaces for a system according to some embodiments. An extended reality display device, together with its control electronics, may be implemented using a system such as the system of FIG. 1A. System 140 can be embodied as a device including the various components described below and is configured to perform one or more of the aspects described in this document. Examples of such devices, include, but are not limited to, various electronic devices such as personal computers, laptop computers, smartphones, tablet computers, digital multimedia set top boxes, digital television receivers, personal video recording systems, connected home appliances, and servers. Elements of system 140, singly or in combination, can be embodied in a single integrated circuit (IC), multiple ICs, and / or discrete components. For example, in at least one embodiment, the processing and encoder / decoder elements of system 140 are distributed across multiple ICs and / or discrete components. In various embodiments, the system 140 is communicatively coupled to one or more other systems, or other electronic devices, via, for example, a communications bus or through dedicated input and / or output ports. In various embodiments, the system 140 is configured to implement one or more of the aspects described in this document.

[0032] The system 140 includes at least one processor 142 configured to execute instructions loaded therein for implementing, for example, the various aspects described in this document. Processor 142 may include embedded memory, input output interface, and various other circuitries as known in the art. The system 140 includes at least one memory 144 (e.g. , a volatile memory device, and / or a non-volatile memory device). System 140 may include a storage device 148, which can include non-volatile memory and / or volatile memory, including, but not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Read-Only Memory (ROM), Programmable Read-Only Memory (PROM), Random Access Memory (RAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), flash, magnetic disk drive, and / or optical disk drive. The storage device 148 can include an internal storage device, an attached storage device (including detachable and non-detachable storage devices), and / or a network accessible storage device, as non-limiting examples.

[0033] System 140 includes an encoder / decoder module 146 configured, for example, to process data to provide an encoded video or decoded video, and the encoder / decoder module 146 can include its own processor and memory. The encoder / decoder module 146 represents module(s) that can be included in a device to perform the encoding and / or decoding functions. As is known, a device can include one or both of the encoding and decoding modules. Additionally, encoder / decoder module 146 can be implemented as a separate element of system 140 or can be incorporated within processor 142 as a combination of hardware and software as known to those skilled in the art.

[0034] Program code to be loaded onto processor 142 or encoder / decoder 146 to perform the various aspects described in this document can be stored in storage device 148 and subsequently loaded onto memory 144 for execution by processor 142. In accordance with various embodiments, one or more of processor 142, memory 144, storage device 148, and encoder / decoder module 146 can store one or more of various items during the performance of the processes described in this document. Such stored items can include, but are not limited to, the input video, the decoded video or portions of the decoded video, the bitstream, matrices, variables, and intermediate or final results from the processing of equations, formulas, operations, and operational logic.

[0035] In some embodiments, memory inside of the processor 142 and / or the encoder / decoder module 146 is used to store instructions and to provide working memory for processing that is needed during encoding or decoding. In other embodiments, however, a memory external to the processing device (for example, the processing device can be either the processor 142 or the encoder / decoder module 142) is used for one or more of these functions. The external memory can be the memory 144 and / or the storage device 148, for example, a dynamic volatile memory and / or a non-volatile flash memory. In several embodiments, an external non-volatile flash memory is used to store the operating system of, for example, a television. In at least one embodiment, a fast external dynamic volatile memory such as a RAM is used as working memory for video coding and decoding operations, such as for MPEG-2 (MPEG refers to the Moving Picture Experts Group, MPEG-2 is also referred to as ISO / IEC 13818, and 13818-1 is also known as H.222, and 13818-2 is also known as H.262), HEVC (HEVC refers to High Efficiency Video Coding, also known as H.265 and MPEG-H Part 2), or VVC (Versatile Video Coding, a new standard being developed by JVET, the Joint Video Experts Team).

[0036] The input to the elements of system 140 can be provided through various input devices as indicated in block 162. Such input devices include, but are not limited to, (i) a radio frequency (RF) portion that receives an RF signal transmitted, for example, over the air by a broadcaster, (ii) a Component (COMP) input terminal (or a set of COMP input terminals), (iii) a Universal Serial Bus (USB) input terminal, and / or (iv) a High Definition Multimedia Interface (HDMI) input terminal. Other examples, not shown in FIG. 1A, include composite video.

[0037] In various embodiments, the input devices of block 162 have associated respective input processing elements as known in the art. For example, the RF portion can be associated with elements suitable for (I) selecting a desired frequency (also referred to as selecting a signal, or band-limiting a signal to a band of frequencies), (ii) downconverting the selected signal, (iii) band-limiting again to a narrower band of frequencies to select (for example) a signal frequency band which can be referred to as a channel in certain embodiments,(iv) demodulating the downconverted and band-limited signal, (v) performing error correction, and (vi) demultiplexing to select the desired stream of data packets. The RF portion of various embodiments includes one or more elements to perform these functions, for example, frequency selectors, signal selectors, bandlimiters, channel selectors, filters, downconverters, demodulators, error correctors, and demultiplexers. The RF portion can include a tuner that performs various of these functions, including, for example, downconverting the received signal to a lower frequency (for example, an intermediate frequency or a near-baseband frequency) or to baseband. In one set-top box embodiment, the RF portion and its associated input processing element receives an RF signal transmitted over a wired (for example, cable) medium, and performs frequency selection by filtering, downconverting, and filtering again to a desired frequency band. Various embodiments rearrange the order of the above-described (and other) elements, remove some of these elements, and / or add other elements performing similar or different functions. Adding elements can include inserting elements in between existing elements, such as, for example, inserting amplifiers and an analog-to-digital converter. In various embodiments, the RF portion includes an antenna.

[0038] Additionally, the USB and / or HDMI terminals can include respective interface processors for connecting system 140 to other electronic devices across USB and / or HDMI connections. It is to be understood that various aspects of input processing, for example, Reed-Solomon error correction, can be implemented, for example, within a separate input processing IC or within processor 142 as necessary. Similarly, aspects of USB or HDMI interface processing can be implemented within separate interface ICs or within processor 142 as necessary. The demodulated, error corrected, and demultiplexed stream is provided to various processing elements, including, for example, processor 142, and encoder / decoder 146 operating in combination with the memory and storage elements to process the datastream as necessary for presentation on an output device.

[0039] Various elements of system 140 can be provided within an integrated housing, Within the integrated housing, the various elements can be interconnected and transmit data therebetween using suitable connection arrangement 164, for example, an internal bus as known in the art, including the Inter-IC (I2C) bus, wiring, and printed circuit boards.

[0040] The system 140 includes communication interface 150 that enables communication with other devices via communication channel 152. The communication interface 150 can include, but is not limited to, a transceiver configured to transmit and to receive data over communication channel 152. The communication interface 150 can include, but is not limited to, a modem or network card and the communication channel 152 can be implemented, for example, within a wired and / or a wireless medium.

[0041] Data is streamed, or otherwise provided, to the system 140, in various embodiments, using a wireless network such as a Wi-Fi network, for example IEEE 802.11 (IEEE refers to the Institute of Electrical and Electronics Engineers). The Wi-Fi signal of these embodiments is received over the communications channel 152 and the communications interface 150 which are adapted for Wi-Fi communications. The communications channel 152 of these embodiments is typically connected to an access point or router that provides access to external networks including the Internet for allowing streaming applications and other over-the-top communications. Other embodiments provide streamed data to the system 140 using a set-top box that delivers the data over the HDMI connection of the input block 162. Still other embodiments provide streamed data to the system 140 using the RF connection of the input block 162. As indicated above, various embodiments provide data in a non-streaming manner. Additionally, various embodiments use wireless networks other than Wi-Fi, for example a cellular network or a Bluetooth network.

[0042] The system 140 can provide an output signal to various output devices, including a display 166, speakers 168, and other peripheral devices 170. The display 166 of various embodiments includes one or more of, for example, a touchscreen display, an organic light-emitting diode (OLED) display, a curved display, and / or a foldable display. The display 166 can be for a television, a tablet, a laptop, a cell phone (mobile phone), or other device. The display 166 can also be integrated with other components (for example, as in a smart phone), or separate (for example, an external monitor for a laptop). The other peripheral devices 170 include, in various examples of embodiments, one or more of a stand-alone digital video disc (or digital versatile disc) (DVR, for both terms), a disk player, a stereo system, and / or a lighting system. Various embodiments use one or more peripheral devices 170 that provide a function based on the output of the system 140. For example, a disk player performs the function of playing the output of the system 140.

[0043] In various embodiments, control signals are communicated between the system 140 and the display 166, speakers 168, or other peripheral devices 170 using signaling such as AV.Link, Consumer Electronics Control (CEC), or other communications protocols that enable device-to-device control with or without user intervention. The output devices can be communicatively coupled to system 140 via dedicated connections through respective interfaces 154, 156, and 158. Alternatively, the output devices can be connected to system 140 using the communications channel 152 via the communications interface 150. The display 166 and speakers 168 can be integrated in a single unit with the other components of system 140 in an electronic device such as, for example, a television. In various embodiments, the display interface 154 includes a display driver, such as, for example, a timing controller (T Con) chip.

[0044] The display 166 and speaker 168 can alternatively be separate from one or more of the other components, for example, if the RF portion of input 162 is part of a separate set-top box. In various embodiments in which the display 166 and speakers 168 are external components, the output signal can be provided via dedicated output connections, including, for example, HDMI ports, USB ports, or COMP outputs.

[0045] The system 140 may include one or more sensor devices 160. Examples of sensor devices that may be used include one or more GPS sensors, gyroscopic sensors, accelerometers, light sensors, cameras, depth cameras, microphones, and / or magnetometers. Such sensors may be used to determine information such as user’s position and orientation. Where the system 140 is used as the control module for an extended reality display (such as control modules 124, 132), the user’s position and orientation may be used in determining how to render image data such that the user perceives the correct portion of a virtual object or virtual scene from the correct point of view. In the case of head-mounted display devices, the position and orientation of the device itself may be used to determine the position and orientation of the user for the purpose of rendering virtual content. In the case of other display devices, such as a phone, a tablet, a computer monitor, or a television, other inputs may be used to determine the position and orientation of the user for the purpose of rendering content. For example, a user may select and / or adjust a desired viewpoint and / or viewing direction with the use of a touch screen, keypad or keyboard, trackball, joystick, or other input. Where the display device has sensors such as accelerometers and / or gyroscopes, the viewpoint and orientation used for the purpose of rendering content may be selected and / or adjusted based on motion of the display device.

[0046] The embodiments can be carried out by computer software implemented by the processor 142 or by hardware, or by a combination of hardware and software. As a non-limiting example, the embodiments can be implemented by one or more integrated circuits. The memory 144 can be of any type appropriate to the technical environment and can be implemented using any appropriate data storage technology, such as optical memory devices, magnetic memory devices, semiconductor-based memory devices, fixed memory, and removable memory, as non-limiting examples. The processor 142 can be of any type appropriate to the technical environment, and can encompass one or more of microprocessors, general purpose computers, special purpose computers, and processors based on a multi-core architecture, as non-limiting examples.Scene Description Framework for XR

[0047] In some embodiments, examples disclosed herein may be used in the domain of rendering of extended reality scene description and extended reality rendering. For some embodiments, for example, the presentapplication may be applied in the context of the formatting and the playing of extended reality applications when rendered on end-user devices such as mobile devices or Head-Mounted Displays (HMD). For some example embodiments, gITF material may be rendered in a 3D environment that is rendered through a 2D screen. The examples presented herein in accordance with some embodiments are not limited to XR applications.

[0048] In XR applications, a scene description is used to combine explicit and easy-to-parse description of a scene structure and some binary representations of media content.

[0049] In time-based media streaming, the scene description itself can be time-evolving to provide the relevant virtual content for each sequence of a media stream. For instance, for advertising purpose, a virtual bottle can be displayed during a video sequence where people are drinking.

[0050] This kind of behavior can be achieved by relying on the framework defined in the Scene Description for MPEG media document, I nformation technology - Coded representation of immersive media - Part 14: Scene Description for MPEG media, ISO / IEC DIS 23090-14 :2021 (E). A scene update mechanism based on the JSON Patch protocol as defined in IETF RFC 6902 may be used to synchronize virtual content to MPEG media streams.

[0051] FIG. 1 B is a system diagram illustrating an example set of interfaces for a scene description (stored as an item in gITF.json), three video tracks, an audio track, and a JSON patch update track in an ISOBMFF file 182 according to some embodiments.Block-Based Video Coding

[0052] Like HEVC, the WC is built upon the block-based hybrid video coding framework. FIG. 2A gives the block diagram of a block-based hybrid video encoding system 200. Variations of this encoder 200 are contemplated, but the encoder 200 is described below for purposes of clarity without describing all expected variations.

[0053] Before being encoded, a video sequence may go through pre-encoding processing 204, for example, applying a color transform to an input color picture (e.g., conversion from RGB 4:4:4 to YCbCr 4:2:0), or performing a remapping of the input picture components in order to get a signal distribution more resilient to compression (for instance using a histogram equalization of one of the color components). Metadata can be associated with the pre-processing and attached to the bitstream.

[0054] The input video signal 202 including a picture to be encoded is partitioned 206 and processed block by block in units of, for example, CUs. Different CUs may have different sizes. In VTM-1.0, a CU can be up to 128x128 pixels. However, different from the HEVC which partitions blocks only based on quad-trees, in the VTM-1.0, a coding tree unit (CTU) is split into CUs to adapt to varying local characteristics based on quad / binary / ternary-tree. Additionally, the concept of multiple partition unit type in the HEVC is removed, such that the separation of CU, prediction unit (PU) and transform unit (TU) does not exist in the WC-1.0 anymore; instead, each CU is always used as the basic unit for both prediction and transform without further partitions. In the multi-type tree structure, a CTU is firstly partitioned by a quad-tree structure. Then, each quad-tree leaf node can be further partitioned by a binary and ternary tree structure. Different splitting types may be used, such as quaternary partitioning, vertical binary partitioning, horizontal binary partitioning, vertical ternary partitioning, and horizontal ternary partitioning.

[0055] In the encoder of FIG. 2A, spatial prediction 208 and / or temporal prediction 210 may be performed. Spatial prediction (or “intra prediction”) uses pixels from the samples of already coded neighboring blocks (which are called reference samples) in the same video picture / slice to predict the current video block. Spatial prediction reduces spatial redundancy inherent in the video signal. Temporal prediction (also referred to as “inter prediction” or “motion compensated prediction”) uses reconstructed pixels from the already coded video pictures to predict the current video block. Temporal prediction reduces temporal redundancy inherent in the video signal. A temporal prediction signal for a given CU may be signaled by one or more motion vectors (MVs) which indicate the amount and the direction of motion between the current CU and its temporal reference. Also, if multiple reference pictures are supported, a reference picture index may additionally be sent, which is used to identify from which reference picture in the reference picture store 212 the temporal prediction signal comes.

[0056] The mode decision block 214 in the encoder chooses the best prediction mode, for example based on a rate-distortion optimization method. This selection may be made after spatial and / or temporal prediction is performed. The intra / inter decision may be indicated by, for example, a prediction mode flag. The prediction block is subtracted from the current video block 216 to generate a prediction residual. The prediction residual is de-correlated using transform 218 and quantized 220. (For some blocks, the encoder may bypass both transform and quantization, in which case the residual may be coded directly without the application of the transform or quantization processes.) The quantized residual coefficients are inverse quantized 222 and inverse transformed 224 to form the reconstructed residual, which is then added back to the prediction block 226 to form the reconstructed signal of the CU. Further in-loop filtering, such as deblocking / SAO (Sample Adaptive Offset) filtering, may be applied 228 on the reconstructed CU to reduce encoding artifacts before it is put in the reference picture store 212 and used to code future video blocks. To form the output video bit-stream 230, coding mode(inter or intra), prediction mode information, motion information, and quantized residual coefficients are all sent to the entropy coding unit 108 to be further compressed and packed to form the bit-stream.

[0057] FIG. 2B gives a block diagram of a block-based video decoder 250. In the decoder 250, a bitstream is decoded by the decoder elements as described below. Video decoder 250 generally performs a decoding pass reciprocal to the encoding pass as described in FIG. 2A. The encoder 200 also generally performs video decoding as part of encoding video data.

[0058] In particular, the input of the decoder includes a video bitstream 252, which can be generated by video encoder 200. The video bit-stream 252 is first unpacked and entropy decoded at entropy decoding unit 254 to obtain transform coefficients, motion vectors, and other coded information. Picture partition information indicates how the picture is partitioned. The decoder may therefore divide 256 the picture according to the decoded picture partitioning information. The coding mode and prediction information are sent to either the spatial prediction unit 258 (if intra coded) or the temporal prediction unit 260 (if inter coded) to form the prediction block. The residual transform coefficients are sent to inverse quantization unit 262 and inverse transform unit 264 to reconstruct the residual block. The prediction block and the residual block are then added together at 266 to generate the reconstructed block. The reconstructed block may further go through in-loop filtering 268 before it is stored in reference picture store 270 for use in predicting future video blocks.

[0059] The decoded picture 272 may further go through post-decoding processing 274, for example, an inverse color transform (e.g. , conversion from YCbCr 4:2:0 to RGB 4:4:4) or an inverse remapping performing the inverse of the remapping process performed in the pre-encoding processing 204. The post-decoding processing can use metadata derived in the pre-encoding processing and signaled in the bitstream. The decoded, processed video may be sent to a display device 276. The display device 276 may be a separate device from the decoder 250, or the decoder 250 and the display device 276 may be components of the same device.

[0060] Various methods and other aspects described in this disclosure can be used to modify modules of a video encoder 200 or decoder 250. Moreover, the systems and methods disclosed herein are not limited to WC or HEVC, and can be applied, for example, to other standards and recommendations, whether pre-existing or future-developed, and extensions of any such standards and recommendations (including VVC and HEVC). Unless indicated otherwise, or technically precluded, the aspects described in this disclosure can be used individually or in combination.

[0061] A User Equipment (UE) may correspond to any extended Reality (XR) device / node which may come in variety of form factors. Typical UE (e.g., XR UE) may include, but not limited to the following: Head Mounted Displays (HMD), optical see-through glasses and video see-through HMDs for Augmented Reality (AR) and Mixed Reality (MR), mobile devices with positional tracking and camera, wearables etc. In addition to the above, several different types of XR UE may be envisioned based on XR device functions for e.g., as display, camera, sensors, sensor processing, wireless connectivity, XR / Media processing, and power supply, to be provided by one or more devices, wearables, actuators, controllers and / or accessories. One or more device / nodes / UEs may be grouped into a collaborative XR group for supporting any of XR applications / experience / services.

[0062] Working Group 7 (WG7) of the Motion Picture Experts Group (MPEG) is understood to be currently working on developing a new standard (ISO / IEC 23090-29) for efficient compression of dynamic meshes. This new standard, titled “Video-based Dynamic Mesh Coding (V-DMC)”, extends the ISO / IEC 23090-5 specification for Visual Volumetric Video-based Coding (V3C) (Information Technology- Coded Representation of Immersive Media - Part 5: Visual Volumetric Video-Based Coding (V3C) and Video-Based Point Cloud Compression (V- PCC), ISO / IEC 23090-5 (2023), available at. iso<dot>org / standard / 83535<dot>html (‘7SO / / EC 23090-5”)). The latest committee draft (CD) version of the V-DMC specification may be found in S. 2. Secretariat, Text of ISO / IEC CD 23090-29 Video-Based Mesh Coding, ISO / IEC CD 23090-29 (June 4, 2024), available at: dms<dot>mpeg<dot>expert / doc_end_user / documents / 146_Rennes / wg11 / MDS23903_WG07_N00885<dot>zi p (“ISO / IEC CD 23090-29”).

[0063] In V3C, a sequence of dynamic mesh(es) is / are represented by several V3C components: a base mesh, a set of displacements, one or more 2D representation of the attributes, and an atlas.

[0064] The base mesh component is a low-resolution approximation of the original mesh. A decoded basemesh is further enhanced geometrically and visually by transformation process such as sub-division as well as applying a set of displacements to the sub-divided basemesh. A basemesh bitstream format is specified in Annex H of ISO / IEC CD 23090-29. For brevity, basemesh format in Annex H of ISO / IEC CD 23090-29 is called “MPEG basemesh” in the rest of the document.

[0065] The MPEG base mesh codec delegates the compression process to the static mesh codec and the motion codec. The design of the MPEG basemesh codec is codec-agnostic. In other words, any static mesh and / or motion codec may be used to code the base mesh bitstream. The ISO / IEC 23090-29 specification definesa static mesh codec in Annex I that may be used to code static mesh for the MPEG basemesh component. A motion decoder is specified to temporally transform the static mesh over a period.

[0066] The displacements component provides displacement vectors, which may be encoded as V3C geometry video component using any video codec. Alternatively, the profile may indicate that the displacement component is encoded using arithmetic coding defined in Annex J of ISO / IEC CD 23090-29.

[0067] The atlas component provides information to a V3C decoding and / or rendering system on how to perform inverse reconstruction. For example, the atlas component may provide information on how to perform the subdivision of a base mesh, how to apply the displacement vectors to the subdivided mesh vertices, and how to apply attributes to the reconstructed mesh.

[0068] A sub-mesh is represented by a set of vertices, their connectivity, and the associated mesh attributes. Sub-meshes may be decoded completely independently. Each base mesh may include one or more sub-meshes identifiable through a unique identifier in the base mesh sub-bitstream frame parameter set. Each patch in an atlas tile is associated with the corresponding sub-mesh identifier.ISO Base Media File Format

[0069] Within the ISO / IEC 14496 (MPEG-4) standard there are several parts that define file formats for the storage of time-based media. These are all based on and derived from the ISO Base Media File Format (ISOBMFF) (Information Technology — Coding of Audio-Visual Objects: Part 12 ISO Base Media File Format, ISO / IEC 14496-12 (2022), available at iso<dot>org / standard / 83102<dot>html (“ISO / IEC 14496-12”)), which is a structural, media-independent definition. ISOBMFF contains structural and media data information mainly for timed presentations of media data such as audio and video, among other things. There is also support for nontimed data, such as metadata at different levels within the file structure. The logical structure of the file is of a movie that in turn contains a set of time-parallel tracks. The time structure of the file is such that the tracks contain sequences of samples in time, and those sequences are mapped into the timeline of the overall movie. ISOBMFF is based on the concept of box-structured files. A box-structured file consists of a series of boxes (sometimes called atoms), which have a size and a type. The types are 32-bit values and are usually chosen to be four printable characters, also known a four-character code (4CC). Un-timed data may be contained in a metadata box, at the file level, or attached to the movie box or one of the streams of timed data, called tracks, within the movie.

[0070] Among the top-level boxes within an ISOBMFF container is the MovieBox ('moov'), which contains metadata for the continues media streams present in the file. These metadata items are signaled within the hierarchy of boxes in the Movie box, e.g., within the TrackBox (“t rak’). A track represents a continuous media stream that is present in the file. The media stream itself consists of a sequence of samples, such as audio or video access units of an elementary media stream and are enclosed within a MediaDataBox (“mdat”) that is present at the top-level of the container. The metadata for each track includes a list of sample description entries, each providing the coding or encapsulation format used in the track and the initialization data for processing that format. Each sample is associated with one of the sample description entries of the track.

[0071] ISO / IEC 14496-12 provides a tool for defining an explicit timeline map for each track. This timeline map is known as an edit list and is signalled using an EditListBox with the syntax shown below in Code Listing 1. Each entry defines part of the track timeline: by mapping part of the composition timeline, or by indicating ‘empty’ time (which are portions of the presentation timeline that map to no media - an ‘empty’ edit). As shown in Code Listing 1, version 1 uses 64-bit fields for media_time and edit_duration, while version 0 uses 32-bit fields. The media_rate_integer and the media_rate_fraction are 16-bit fields for both versions. aligned(8) class EditListBox extends FullBox ( ' elst ' , version, flags) { unsigned int (32) entry count; for (i=l; i<=entry count; i++) { if (version == 1) { unsigned int (64) edit duration; int (64) media_time;} else { / / version == 0 unsigned int (32) edit duration; int (32) media time;} int(16) media rate integer; int(16) media rate fraction = 0; } }Code Listing 1.

[0072] Specification Information Technology— Coded Representation of Immersive Media Part 10: Carriage of Visual Volumetric Video-Based Coding Data, ISO / IEC 23090-10 (2022), available at:iso<dot>org / standard / 78991 <dot>html ^‘ISO / IEC 23090-10”) defines extensions to the ISO-IEC 14496-12 specification to enable encapsulation (carriage) of V3C bitstreams in ISOBMFF media containers.Access Unit

[0073] An access unit is made up of a set of Network Abstraction Layer (NAL) units. Each NAL unit is represented with a length field and NAL unit data. The length field indicates the length in bytes of the following NAL unit. The NAL unit data is specified as per the respective standard such as HEVC, AVC, and V3C, among other standards.Sample

[0074] A sample is an access unit or a part of an access unit in which an access is as defined in the corresponding specification. The data carried in a sample is associated with a specific time.Sub-Sample Encapsulation

[0075] A sub-sample is a contiguous range of bytes of a sample. A sample within the context of a track in the file format may carry multiple sub-samples. Therefore, all sub-samples in a sample carries data associated with the same time in the media playback timeline. The specific definition of a subsample is given by the coding system (e.g., HEVC, H.264 / AVC, among other standards). Each sub-sample may be related to other subsamples of the track by some means.

[0076] A sub-sample information box is defined in sub-clause 8.7.7 of ISO / IEC 14496-12 (2020). The box is designed to contain sub-sample information, such as the number of sub-samples in a sample, the size of each sub-sample, and some other codec-specific parameters.Basemesh Bitstream

[0077] A basemesh bitstream is defined in the ISO / IEC CD 23090-29 bitstream format for a sequence of encoded basemesh frames. A basemesh frame may be comprised of individual sub-meshes, where each submesh in a basemesh frame corresponds to sub part of the basemesh. The segmentation into sub-meshes allows flexibility and parallel access within a basemesh frame to decode and / or render a part of the basemesh.

[0078] The following entities are defined in the ‘977 application and referred to later in the present application.Basemesh Track

[0079] A Basemesh track in an ISOBMFF container is a track that carries the data in a basemesh bitstream. For example, as specified in the ‘977 application, a basemesh track may contain a sample entry of type Ba seme sh S amp l eEnt ry with derives from the Vo lumt e r i cVi sual S ampl eEnt ry. A Ba seme sh S amp l eEnt ry may contain a Ba s eMe shCon f i gurat i onBox, which contains configuration information needed to initialize the basemesh mesh decoder.Submesh Track

[0080] A submesh in the basemesh bitstream is an independently decodable access unit. A submesh track carries sub-mesh data for one or more submeshes in the basemesh bitstream. A submesh track may be used for partially accessing part of the basemesh without fetching the entire basemesh data. An example of a submesh track is described in the ‘977 application.

[0081] A submesh track contains one or more basemesh submesh sequences. Submeshes are independently decodable. A set of submeshes may be grouped together to represent certain sub-parts of the basemesh. Alternatively, the grouping of submeshes may be determined through external means. One such scenario is when a basemesh bitstream is used as a sub-bitstream in V-DMC. An atlas tile may contain patches that correspond to a set of submeshes in the basemesh bitstream, as specified in ISO / IEC CD 23090-29 and as mentioned below. Therefore, samples carried within the atlas track which carry atlas data require decoding a set of submeshes in the basemesh bitstream as specified in ISO / IEC CD 23090-29.

[0082] A submesh track stores samples corresponding to a submesh or a set of submeshes in a basemesh bitstream, where the set may be determined by one of the grouping mechanisms as described above. In case the syntax element afmi_use_single_mesh_flag as specified in ISO / IEC CD 23090-29 is true, there shall be one submesh carried in the submesh track. Otherwise, the number of submeshes carried in the submesh track is determined based on the syntax elements afmi_num_submeshes_minus2 plus 2 and shall be in the range of 2 to 64, inclusive. Collectively, this means that a basemesh track contains at least one submesh. A submesh track may include a sample entry, for example Baseme sh SubMe shS amp ieEnt ry. The identifiers for all the basemesh submeshes carried by a submesh track are signaled in a configuration box, for example configuration box Bas eme sh Subme shConf i gurat i onBox within sample entry Ba seme sh Subme shS amp ieEnt ry as described in the ‘977 application.Relationship of an Atlas Tile and Submeshes in V-DMC

[0083] An atlas frame is a collection of 2D bounding boxes and their associated information placed onto a rectangular frame and corresponding to a volume in the 3D space on which volumetric data is rendered and a list of metadata corresponding to a part of a surface of a mesh in the 3D space. An atlas frame in the atlas bitstream may be split into multiple atlas tiles, and each atlas tile may contain several patches. Each patch in an atlas tile corresponds to data which facilitate the 3D reconstruction of the volumetric object. In V-DMC (ISO / IEC CD 23090-29), a new patch (mesh patch) is specified. A mesh patch includes data in an atlas that enables the conversion of basemesh into the reconstructed mesh.

[0084] Each mesh patch is associated with a submesh in the basemesh bitstream as specified in the mesh patch data unit of ISO / IEC 23090-29 (sub-clause 8.3.9.3 in ISO / IEC CD 23090-29). The corresponding submesh is identified by the submesh ID with syntax element mdu_subme sh_id for a mesh patch in an atlas tile. Therefore, an atlas tile may store 3D reconstruction information for many submeshes. The number of submeshes related to an atlas tile is determined by the number of mesh patch data units in the atlas tile.Atlas Tile Track

[0085] A V3C atlas tile track is a track in which samples contain only Atlas Coded Layer (ACL) NAL units, which belong to the same atlas. V3C atlas tile tracks contain ACL NAL units for at least one tile, which are indicated by the t i le_id of that tile. An atlas tile track is specified in ISO-IEC 23090-5.Mesh Attribute for Reconstruction

[0086] A list of basemesh attributes for reconstruction is created using the syntax elements in the VPS V- DMC extension syntax structure. The size the of basemesh attribute list is equal to the value of syntax element vp s_ext_bme sh_dat a_at t r ibut e_count for atlas ID vp s_at i a s_iD. There are syntax elements which provide additional information about each basemesh attribute, such as attribute type, bit depth, attribute index in the basemesh bitstream, and bit depth alignment. The syntax element vp s_ext_bme sh_att r ibut e_t ype identifies the basemesh attribute type such as ATTR-TEXCOORD, ATTR.NORMAL, and ATTR_FACEGROUP_ID, among other types.

[0087] The decoder and renderer are instructed which basemesh attributes to use and how to use the basemesh attributes for the final reconstruction of the mesh. There may be cases where the same type of mesh attribute is signaled multiple times in the basemesh bitstream. For example, a facegroupID basemesh attribute may indicate a connected group of four vertices of the mesh and another facegroupID basemesh attributes mayindicate connected group of three vertices of the mesh. Another example is situation where a basemesh attribute texture coordinate may be used to achieve different texture mappings per mesh.

[0088] Therefore, proper reconstruction of the basemesh depends on which basemesh attribute is used. There may be signaling provided in the V-DMC bitstream to index the basemesh attribute to be used for reconstruction. Alternatively, a V-DMC bitstream may rely on external means to instruct the V-DMC decoder to index the basemesh bitstream to be used for reconstruction. The selection of mesh attributes may be handled outside of the V-DMC bitstream. For some embodiments, the index of mesh attributes for reconstruction may be indicated in a container format such as ISOBMFF or RTP, among others.

[0089] A file format for basemesh attribute indexing is described below. V-DMC specifies a relationship between submeshes in the basemesh bitstream and the atlas bitstream. This relationship enables partial access of a V-DMC coded mesh sequence.

[0090] A scheme for encapsulation of a basemesh bitstream in ISOBMFF container for efficient delivery is discussed below. Several methods to encapsulate basemesh bitstream in an ISOBMFF file are presented in this application. These methods allow packaging of the basemesh bitstream in a manner which allows for random access of mesh partials. This further facilitates efficient storage and transmission of a basemesh bitstream.

[0091] Furthermore, this application discusses storage and efficient delivery of coded basemesh content encapsulated in ISOBMFF containers for some embodiments. Below are sub-sections which describe storage and delivery formats for a basemesh data encapsulated in ISOBMFF containers. Descriptions include basemesh submesh track sample and sub-sample concepts, methods to define submesh track for basemesh data, methods to associated submesh track to V-DMC atlas track, and a box structure to signal information related to the index of the basemesh attributes in the basemesh bitstream to be used for reconstruction. Starting with the atlas track / atlas tile track defined in ISO / IEC 23090-10, additions are made to that structure.Basemesh and Submesh Track Sample

[0092] A sample in a basemesh track or submesh track contains either of the following: (1) one or more complete submeshes as specified in ISO / IEC CD 23090-29 that collectively form a sub-part of the basemesh; or (2) one submesh as specified in ISO / IEC 23090-29 that forms a sub-part of the basemesh.

[0093] A sync sample in a basemesh track or submesh track is a sample that contains an Intra Random Access Point (IRAP) basemesh codec submesh access unit as defined in ISO / IEC 23090-29. Basemesh parameter sets, and SEI messages may be repeated if needed for a sync sample to allow for random access.Definition of a Sub-Sample for Basemesh Track

[0094] A sample in a basemesh track may include a set of submeshes. Each submesh in a basemesh track is a sub-sample. For the use of the SubSampieinformationBox subclause 8.7.7 in ISO / IEC 14496-12 in a Basemesh track, a sub-sample is defined based on the value of the flags field of the sub-sample information box as specified below. The presence of this box is mandatory if more than one submesh is carried in the track.

[0095] If the sub-sample information box is present in a basemesh track containing submesh data for more than one submesh, the codec_specif ic_parameters field in the box shall have the semantics defined below.

[0096] The flags field specifies the type of sub-sample information given in this box. A value of 0 indicates that there are submesh NAL-unit-based sub-samples. A sub-sample contains NAL unit data for one submesh. The carried submesh is one of the submeshes stored in the sample of the basemesh track. A sample in the basemesh track stores NAL-unit data for all submeshes of a basemesh. A submesh track may carry sub-samples in which each sub-sample stores NAL unit data for a submesh. An NAL unit of a submesh is defined in ISO / IEC 23090-29. Therefore, a sample in the submesh track may carry more than one submesh of NAL unit data. A sample in the ISOBMFF may have more than one sub-sample for some embodiments. Values other than 0 are reserved for future use.

[0097] The subsampie_priority field is set to a value in accordance with the specification of this field in ISO / IEC 14496-12.

[0098] The discardable field is set to 1 only if this sample is still decodable if this sub-sample is discarded (e.g., the sub-sample consists of an SEI NAL unit). When the first byte of an NAL unit is included in a sub-sample, the preceding length field is also included in the same sub-sample.

[0099] The codec_specif ic_parameters field Of the SubSampieinformationBox is defined for a basemesh track as shown in Code Listing 2. if (flags == 0) { unsigned int ( 16) submesh_id;unsigned int (l) rap nal unit flag; unsigned int (l) submesh self contained flag; bit (14) reserved = 0;}Code Listing 2.

[0100] The submesh_id field identifies the submesh associated with the sub-sample of the basemesh track. submesh_id is equal to the submesh identifier signaled in the syntax element bmsi_submesh_id.

[0101] If the flag rap_n i_unit_f lag is equal to 0, this indicates that none of the NAL units in the sub-sample has nal_unit_type equal to BNAL_IDR_W_RADL, BNAL_IDR_N_LP, or BNAL_CRA as specified in Annex H of ISO / IEC 23090-29. If the flag rap_nai_unit_f lag is equal to 1, this indicates that all NAL units in the sub-sample have nai_unit_type equal to BNAL_IDR_W_RADL, BNAL_IDR_N_LP, or BNAL_CRA as specified in Annex H of ISO / IEC 23090-29. The acronym RAP stands for Random Access Point. An RAP for a NAL-based bitstream is generally identified by the NAL unit types. In a typical case, the NAL units carried within each sub-sample should match. This allows for a client application to seek into the bitstream without decoding any previous frame in bitstream.

[0102] If the flag submesh_seif_contained_f lag is equal to 0, this indicates thatsome data (e.g., prefix data) for each submesh is present as specified in a basemesh sequence parameter set in ISO / IEC 23090- 29. If the flag submesh_seif_contained_f lag is equal to 1, this indicates that each sub-sample in the sample of the basemesh track is self-contained.Definition of a Sub-Sample for Submesh Track

[0103] A sample in a submesh track may include a set of submeshes. Each submesh in a submesh track is a sub-sample. For the use of the SubSampieinformationBox subclause 8.7.7 in ISO / IEC 14496-12 in a Basemesh submesh track, a sub-sample is defined based on the value of the flags field of the sub-sample information box as specified below. The presence of this box is mandatory in the case where more than one submesh is carried in the track.

[0104] Submeshes carried in the submesh track may belong exclusively to a unique atlas tile. In such a case, a submesh track shall not contain submeshes that are related to different atlas tiles.

[0105] If a SubSample inf ormat ionBox field is present in a submesh track containing data for more than one submesh, the codec_specific_parameters field in the box shall have the semantics defined below.

[0106] The flags field specifies the type of sub-sample information given in this box. A value of 0 indicates that there are submesh NAL-unit-based sub-samples. A sub-sample contains NAL unit data for one submesh. The carried submesh belongs to a group of submeshes which are stored in the sample of the submesh track. The group of submeshes may be identified with a syntax element (e.g., submesh_set_id). Values other than 0 are reserved for future use.

[0107] The subsampie_priorit y field shall be set to a value in accordance with the specification of this field in ISO / IEC 14496-12.

[0108] The discardable field shall be set to 1 only if this sample is still decodable if this sub-sample is discarded (e.g., the sub-sample consists of an SEI NAL unit). When the first byte of an NAL unit is included in a sub-sample, the preceding length field is also included in the same sub-sample.

[0109] The codec_specific_parameters field Of the SubSamplelnf ormat ionBox is defined for Basemesh bitstream as shown in Code Listing 3. if (flags == 0 ) { unsigned int (l) rap nal unit flag; unsigned int (l) submesh self contained flag; bit (30) reserved = 0;}Code Listing 3.

[0110] If the flag rap_nai_unit_f lag is equal to 0, this indicates that none of the NAL units in the sub-sample has nal_unit_type equal to BNAL_IDR_W_RADL, BNAL_IDR_N_LP, or BNAL_CRA as specified in Annex H of ISO / IEC 23090-29. If the flag rap_nai_unit_f lag is equal to 1, this indicates that all NAL units in the sub-sample have nal_unit_type equal to BNAL_IDR_W_RADL, BNAL_IDR_N_LP, or BNAL_CRA as specified in Annex H of ISO / IEC 23090-29.

[0111] If the flag submesh_seif_contained_f lag is equal to 0, this indicates that some data e.g. prefix data for each submesh is present as specified in basemesh sequence parameter set in ISO / IEC 23090-29. If the flag submesh_seif_contained_f lag is equal to 1, this indicates that each sub-sample in the sample of the submesh track is self-contained.Association of Submesh Track to V-DMC Atlas Track / Atlas Tile Track

[0112] The atlas sub-bitstream provides the information used for reconstruction of a basemesh or a set of submeshes in the basemesh. An atlas tile may correspond to a set of submeshes with reconstruction information stored in different patches. Therefore, a set of submeshes are grouped to allow for partial decoding and reconstruction of a sub-part of the basemesh along with the reconstruction information stored in the corresponding atlas tiles to signal the association between a submesh track and a V3C atlas tile track containing the atlas information for the set of submeshes,Atlas Track

[0113] An atlas track may contain information related to submeshes, such as submeshlD, which correspond to the atlas sample. Such information is contained in the sample entry of an atlas track. This box may not be necessary if there is not more than one submesh in the basemesh bitstream. aligned (8) class V3CSubmeshInf ormat ionBox extends FullBox ( ' v3SC' , version = 0, 0) { unsigned int (1) tile info; bit (7) reserved = 0; unsigned int (16) num submeshes minusl; for (j = 0; j < num submeshes minusl; j++) { unsigned int (16) submesh_id; if (tile_info) { unsigned int (16) tile id;}}}Code Listing 4.

[0114] The semantics of the vscsubmeshinf ormat ionBox class are described below.

[0115] The field tils info specifies whether tile information for each submesh is available. When the t iie_inf o flag value is 0, tile information for each submesh is not available. When tiie_inf o flag value is 1, tile information for each submesh is available.

[0116] The field num_submeshes indicates the number of submeshes associated with this atlas track instance.

[0117] The field submesh_id identifies a submesh which is carried in the basemesh submesh track.

[0118] The field t iie_id indicates the atlas tile ID of an atlas tile carrying the patches associated with the submesh corresponding to submesh_id .

[0119] The information signaled for all submeshes corresponding to an atlas tile carried by an atlas track are Signaled in the VSCSubmeshlnf ormat ionBox class Of the V3CAt lasSampleEnt ry class. aligned(8) class V3CAtlasSampleEntry ( ) extendsVolumetricVisualSampleEntry (type) { / / type is 'v3cl ' , 'v3cg' , 'v3cb' , 'v3al ' , or 'v3ag'V3CConf igurationBox config;V3CUnitHeaderBox unit header;V3CSubmeshInf ormationBox submesh info; / / optional}Code Listing 5.Atlas Tile Track

[0120] An atlas tile track may contain information related to submeshes, such as submeshlD, which correspond to the atlas sample. Such information is contained in the sample entry of an atlas tile track.V3C Atlas Tile Submesh Configuration Box

[0121] A v3CAt lasiimeSubmeshConf igurationBox provides information on the submeshes associated with each atlas tile in a V3C atlas tile track in the case of V-DMC content. The v3CAt lasiimeSubmeshConf igurationBox is defined as shown in Code Listing 6. aligned (8) class V3CAtlasTileSubmeshConf igurationBox extendsFullBox ( ' v3SC' , version=0, 0) {unsigned int (16) num tiles; for (int i=0; i<num tiles; i++) { unsigned int ( 16) tile_id; unsigned int ( 16) num submeshes minusl ; for (j = 0; j<num submeshes minusl+1; j++) { unsigned int ( 16) submesh_id;}}}Code Listing 6.

[0122] The semantics of the v3CAtiasiiieSubmeshConf igurationBox class are described below.

[0123] The field num tiles indicates the number of atlas tiles contained in the track.

[0124] The field tiie_id specifies the atlas tile ID of the atlas tile contained in the track. The value of tile_id is equal to a value in the afti_tile_id syntax element of the atlas frame tile information, as defined in ISO / IEC 23090-5.

[0125] The field num_submeshes_minusi plus 1 specifies the number of submeshes corresponding to an atlas tile with an atlas ID of t ile_id.

[0126] The field submesh id indicates the identifier for the submesh carried in the atlas tile track.

[0127] Alternatively, for some embodiments, if a set of submeshes are exclusively related to an atlas tile, the V3CAt lasTileSubmeshConf igurationBox class may refer to the submesh_set_id for each atlas tile with tile I D t i 1 e_i d . aligned (8) class V3CAtlasTileSubmeshConf igurationBox extendsFullBox ( ' v3SC' , version=0, 0) { unsigned int ( 16) num_tiles; for (int i=0; i < num tiles; i++) { unsigned int (16) tile id; unsigned int (16) submesh_set_id;}}Code Listing 7.

[0128] The semantics of the v3CAtiasTiieSubmeshConf igurationBox class are described below.

[0129] The field tiie_id specifies the atlas tile ID of the atlas tile contained in the track. The value of tile_id is equal to a value in the afti_tile_id syntax element in the atlas frame tile information, as defined in ISO / IEC 23090-5.

[0130] The field submesh_set_id indicates a unique identifier for a set of submeshes for atlas tile with tile identifier tiie_iD. The group of submeshes are carried in the basemesh submesh track.

[0131] The information signaled for all submeshes corresponding to an atlas tile carried by an atlas tile track are signaled in the V3CAtlasTileSubmeshConf igurationBox class Of the V3CAt lasTileSampleEnt ry class.

[0132] The class v3CAtiasTiieSubmeshConf igurationBox shall be present when the profile toolset indicator in the V3C parameter sets corresponds to a value reserved for V-DMC. aligned (8) class V3CAt lasTileSampleEntry ( ) extends VolumetricVisualSampleEntry ( 'v3tl ' ) {V3CAt lasTileConf igurationBox tile info;V3CAtlasTileSubmeshConf igurationBox submesh info; / / optional}Code Listing 8.Extension to V3C Atlas Tile Configuration Box

[0133] For some embodiments, the v3CAti as TiieConf igurationBox class specified in ISO / IEC 23090-10 may be extended to include submesh information for an atlas tile. The label “v3tc” shown in Code Listing 9 refers to the 4CCs for the V3CAtlasTileConfig urationBox class, and the label “v3tc” is not shown in FIG. 3. The label “v3ct” refers to the 4CCs for track referencing, and the label “v3ct” shown in FIG. 3 is used to reference an atlas tile track 310, 314 corresponding to an atlas track 302. class V3CAtlasTileConf igurationBox extends FullBox ( ' v3tC ' , version=0, 0) {unsigned int (3) unit_size_precision_bytes_minusl ; unsigned int(l) spatial scalability enabled flag; unsigned int(l) submesh information present flag; bit (3) reserved = 0; if ( spatial_scalability_enabled_f lag) { unsigned int(8) lod_index;} unsigned int(16) num tiles; for (int i=0; i < num tiles; ill) { unsigned int (16) tile id; if ( submesh_information_present_f lag) { unsigned int (16) num_submeshes_minusl ; for (int j=0; j<num_submeshes_minusl+l; j++) { unsigned int (16) submesh id;}}}}Code Listing 9.

[0134] The additional semantics of the vscAtiasTiieConf igurationBox class are described below.

[0135] The flag submesh_information_present_f lag indicates whether submesh information for an atlas tile is present. When the submesh_information_present_f lag is zero, then this instance of the atlas tile track does not contain submesh information. When the submesh_inf ormat ion_present_f lag is one, then this instance of the atlas tile track contains submesh information.

[0136] The field num_submeshes_minusi plus 1 indicates the number of submeshes associated with an atlas tile with atlas tile identifier t i le_id.

[0137] The field submesh id identifies the submesh carried in the atlas tile track.

[0138] In case a set of submeshes are exclusively related to an atlas tile, the V3CAt las Tile SubmeshConf igurationBox class may also refer to the submesh_set_id for each atlas tile associated with tile identifier tile_iD. class V3CAtlasTileConf igurationBox extends FullBox ( ' v3tC ' , version=0, 0) { unsigned int (3) unit_size_precision_bytes_minusl ; unsigned int(l) spatial scalability enabled flag; unsigned int(l) submesh_information_present_f lag; bit (3) reserved = 0; if ( spatial_scalability_enabled_f lag) { unsigned int(8) lod index;} unsigned int(16) num tiles; for (int i=0; i<num tiles; i++) { unsigned int (16) tile_id; if ( submesh_information_present_f lag) { unsigned int (16) num submeshes; unsigned int (16) submesh set id; } }}Code Listing 10.

[0139] The additional semantics Of V3CAtlasTileConf igurationBox are as follows:

[0140] The flag submesh_information_present_f lag indicates whether submesh information for an atlas tile is present. When the submesh_inf ormation_present_f lag is zero, then this instance of the atlas tile track does not contain submesh information. When the submesh_inf ormation_present_f lag is one, then this instance of the atlas tile track contains submesh information.

[0141] The field num_submeshes indicates the number of submeshes corresponding to an atlas tile with atlas ID t ile_ id.

[0142] The field subme sh_s et_id indicates a unique identifier for a set of submeshes for an atlas tile associated with tile identifier tiie_iD. The group of submeshes are carried in the basemesh submesh track.Track Grouping

[0143] FIG. 3 is a system diagram illustrating an example set of interfaces for atlas tile track and basemesh submesh track grouping according to some embodiments. A V-DMC decoder requires information from the atlas bitstream to reconstruct the basemesh. A basemesh may be sub-divided into submeshes which allows for efficient access and independent decode capability. An atlas tile in the atlas bitstream stores information for a submesh or a set of submeshes to enable 3D reconstruction of the basemesh.

[0144] An atlas tile track which contains information for a submesh or a set of submeshes shall be group with the submesh track(s) with the matching submeshlD(s). A submesh track shall not be grouped with more than one atlas tile track. FIG. 3 illustrates an example structure 300 for a V3C atlas track 302 in which atlas tile tracks 310, 314 are grouped with the submesh tracks containing data for submesh ID value subme sh_i D(s) corresponding to the subme sh_i d referred in the atlas tile track.

[0145] A new track reference type “v3vb” is defined to link the atlas track 302 to a basemesh track 304 carrying basemesh data. A T rackRe fe rence TypeBox with the reference type 'v3vb' is added to a T rackRe ference TypeBox within the T rackBox Of the atlas track. The T rackRe ference TypeBox shall contains an array of t rack_i Ds designating the identifiers for the reference basemesh track(s).

[0146] A track reference type “v3t s” (not shown in FIG. 3) may be defined to link the submesh tracks 312, 316 to their corresponding atlas tile track carrying the data for the submesh. A TrackRe f erenceBox with the reference type ’v3t s' is added to a T rackRe ference TypeBox within the TrackBox of the atlas tile track. The T rackRe ference TypeBox may contain an array of t rack_iDs designating the identifiers for the reference basemesh track(s). An atlas tile track shall only reference submesh track(s) for which the atlas tile contains the data for the associated submeshes with matching submesh I D(s).

[0147] FIG. 3 shows an example V3C atlas track 302 that has “v3ct” links to two atlas tile tracks 310, 314 and associated track groups 306, 308. Each atlas title track box 310, 314 contains one or more submesh IDs. Each track group 306, 308 also contains one or more submesh tracks 312, 316. Each submesh track 312, 316 contains one or more submesh subsamples and associated submesh IDs. The example V3C atlas track 302 also has a“v3vb” link to a basemesh track 304 that goes by the name “vbm1 This basemesh track 304 has multiple “vlbm” links to submesh tracks 312, 316. For some embodiments, a track group 306 may contain a single submesh track 312 that contains multiple submesh subsamples and an atlas tile track which provides information for the associated submeshes with submesh IDs equal to the submesh IDs of the submesh sub-samples carried in the submesh track. For some embodiments, a track group 308 may contain multiple submesh tracks 316 and an atlas tile track that provides information for the associated submeshes with submesh IDs equal to the submesh IDs of the submesh tracks. For some embodiments, a track group may be a combination (which is not shown in FIG. 3) of stand-alone submesh tracks 316 and submesh tracks 312 containing one or more submesh subsamples.

[0148] The association between one or more submesh tracks and a V3C atlas tile track containing the atlas information for the submesh or the set of submeshes is signaled using a new track group VDMCAt lasTi leSubmeshTrackGroupBox, which extends the TrackGroupTypeBox Class defined in ISO / IEC 14496-12 as shown in Table 1 and Code Listing 11.al igned ( 8 ) class VDMCAt lasTi leSubMeshTrackGroupBox extendsTrackGroupTypeBox ( ' vdmg ' ) { / / t rack_group_id i s inherited from TrackGroupTypeBox uns igned int ( 1 6 ) num_of_submeshes_minus l ; for ( int i = 0 ; i < num_o f_submeshes_minus l + 1 ; i++ ) { uns igned int ( 1 6 ) submesh id;} uns igned int ( 1 6 ) ti le_id;}Code Listing 11.

[0149] The semantics Of the fields Of the VDMCAt lasTileSubmeshTrackGroupBox class are described below.

[0150] The field num_of_submeshes_minusi plus 1 indicates the number of the submeshes associated with an atlas tile with atlas tile identifier tiie_id.

[0151] The field submesh_id identifies the submesh carried in the atlas tile track.

[0152] The field til e_i d identifies the associated atlas tile.

[0153] Alternatively, for some embodiments, a set of submesh identifiers, such as submesh_set_id, is signaled in the submesh track as described below. In such a case, the class VDMCAt lasTiieSubmeshTrackGroupBox may be defined as shown in Table 1 and Code Listing 12. aligned (8) class VDMCAt lasTileSubMeshTrackGroupBox extendsTrackGroupTypeBox ( ' vdmg ' ) { / / t rack_group_id is inherited from TrackGroupTypeBox unsigned int (16) submesh_set_id unsigned int ( 16) tile_id;}Code Listing 12.

[0154] Class VDMCAt lasTiieSubmeshTrackGroupBox uses the fields submesh_set_id and tiie_id. Unsigned integer submesh_set_id identifies a set of submeshes. Unsigned integer t i ie_i d identifies the atlas tile.

[0155] Alternatively, the atlas tile track(s) and the submesh track(s) may be grouped using the EntityToGroupBox class as specified in ISO / IEC 14496-12. For the EntityToGroupBox class, setting group ing_type equal to “vasg” specifies the grouping of track / tracks containing submesh data and corresponding atlas tile track which carry some information for example reconstruction information for submeshes carried in the grouped submesh track / tracks. The reconstruction of a subpart of the basemesh represented by the data carried in the submesh track(s) requires additional information from the corresponding atlas tile track that carries the necessary information to reconstruct the basemesh. The logical relationship between the submesh track(s) to the atlas tile track is contained in the EntityToGroupBox class if the grouping_type is "vasg”. This information is used for reconstructing the basemesh. aligned (8) class V3CAt lasTileAndSubmeshGroupingBox (version, flags)extends Ent ityToGroupBox ( ' vasg ' , version, flags) { for (i=0; i<num entities in group; i++) { bit ( 6) reserved = 0; unsigned int (l ) tile id flag [i] ; unsigned int (l ) submesh id flag [i] ; }}Code Listing 13.

[0156] If the flag tile_id_f lag [i] is equal to 0, this specifies that the entity ID does not correspond to an identifier for an atlas tile.

[0157] If the flag tile_id_f lag [1] is equal to 1, this specifies that the entity ID corresponds to an identifier for an atlas tile.

[0158] If the flag submesh_id_f lag [i] is equal to 0, this specifies that the entity ID does not correspond to an identifier for a submesh.

[0159] If the flag submesh_id_f l g [ i ] is equal to 1, this specifies that the entity ID corresponds to an identifier for a submesh.

[0160] Only one of tile_id_flag [i] and submesh_id_f lag [i] shall be equal to 1 for each value of i in the range of 0 to (num_entit les_in_group - 1), inclusive.Attribute Indexing for Mesh Reconstruction.

[0161] A new structure may be specified to indicate the index of basemesh mesh attributes such as texture coordinate and facegroup ID to be used for reconstruction for an atlas ID as shown in Code Listing 14. aligned (8) class Reconstruct ionMeshAttribute ( ) { unsigned int (8) atlas count minusl; for (int j=0; j<atlas count minusl+1 ; j++) { unsigned int ( 8 ) at las_id; unsinged int (8) texture coordinate index; unsigned int (8) facegroup id index; }}Code Listing 14.

[0162] The semantics of the Rec on st ruct i onMe shAt t r ibut e box class are described below.

[0163] The field at ias_count_minus i plus 1 specifies the number of atlas tracks present in the file.

[0164] The field atlas id indicates the atlas identifier for an atlas carried in an atlas track.

[0165] The field texture_coordinate_i ndex indicates the index of the basemesh attribute of type ATTR_TEXCOORD signaled in the VPS V-DMC parameter extension.

[0166] The field facegroup_id_i ndex indicates the index of the basemesh attribute of type ATTR_FACEGROUP_ID signaled in the VPS V-DMC parameter extension.

[0167] For reconstruction, the signaled index of the mesh attributes, such as texture coordinate and facegroup ID, for an atlas ID may be used.

[0168] FIG. 4 is a flowchart illustrating an example process for populating a file in a container file format according to some embodiments. For some embodiments, an example process 400 may include receiving 402, by an encoder, one or more sub-streams of a media content item, wherein the one or more sub-streams comprise an atlas sub-stream, a basemesh sub-stream, and one or more submesh sub-streams. For some embodiments, the example process 400 may further include generating 404, by the encoder, a plurality of track references. For some embodiments, the example process 400 may further include encapsulating 406, by the encoder, the plurality of sub-streams in a container file format, wherein the container file format comprises a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh substreams.

[0169] An example apparatus in accordance with some embodiments may include at least one processor configured to perform any one of the methods described within this application. An example apparatus in accordance with some embodiments may include a computer-readable medium storing instructions for causing one or more processors to perform any one of the methods described within this application. An example apparatus in accordance with some embodiments may include at least one processor and at least one non- transitory computer-readable medium storing instructions for causing the at least one processor to perform any one of the methods described within this application. An example signal in accordance with some embodiments may include a bitstream generated according to any one of the methods described within this application.

[0170] While the methods and systems in accordance with some embodiments are generally discussed in context of extended reality (XR), some embodiments may be applied to any XR contexts such as, e.g., virtual reality (VR) I mixed reality (MR) / augmented reality (AR) contexts. Also, although the term “head mounted display (HMD)” is used herein in accordance with some embodiments, some embodiments may be applied to a wearable device (which may or may not be attached to the head) capable of, e.g., XR, VR, AR, and / or MR for some embodiments.

[0171] A first example method in accordance with some embodiments may include: receiving, by an encoder, one or more sub-streams of a media content item, wherein the one or more sub-streams include an atlas substream, a basemesh sub-stream, and one or more submesh sub-streams; generating, by the encoder, a plurality of track references; and encapsulating, by the encoder, the plurality of sub-streams in a container file format, wherein the container file format includes a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.

[0172] For some embodiments of the first example method, the container file format includes an International Standards Organization Base Media File Format (ISOBMFF).

[0173] For some embodiments of the first example method, the atlas sub-stream includes a V3C atlas track, and the basemesh sub-stream includes a basemesh track.

[0174] For some embodiments of the first example method, the file format further includes a track reference to link the atlas sub-stream to the basemesh sub-stream.

[0175] For some embodiments of the first example method, the file format further includes a submesh track reference to link the basemesh sub-stream to a submesh track.

[0176] For some embodiments of the first example method, the submesh track includes one or more submesh subsamples.

[0177] For some embodiments of the first example method, at least one of the one or more submesh subsamples corresponds to one of the one or more submesh sub-streams.

[0178] For some embodiments of the first example method, the file format further includes atlas tile track information.

[0179] For some embodiments of the first example method, the atlas tile track information includes information corresponding to the atlas sub-stream.

[0180] For some embodiments of the first example method, the atlas tile track information includes one or more submesh identifiers.

[0181] For some embodiments ofthe first example method, at leastone ofthe one or more submesh identifiers corresponds to one of the one or more submesh sub-streams.

[0182] For some embodiments of the first example method, at least one of the sub-streams corresponds to a track in the encapsulated container file format.

[0183] A media consumption device in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0184] At least one processor in accordance with some embodiments may be operatively connected to at least one transceiver, the at least one processor and at least one transceiver configured to perform any one of the methods shown above.

[0185] A network device in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0186] A computing device in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0187] An integrated circuit in accordance with some embodiments may be configured to perform any one of the methods shown above.

[0188] A first example method / apparatus in accordance with some embodiments may include: a processor; and a computer-readable medium storing instructions operative, when executed by the processor, to cause the apparatus to: receive, by an encoder, one or more sub-streams of a media content item, wherein the one or more sub-streams include an atlas sub-stream, a basemesh sub-stream, and one or more submesh sub-streams; generate, by the encoder, a plurality of track references; and encapsulate, by the encoder, the plurality of substreams in a container file format, wherein the container file format includes a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.

[0189] A second example method in accordance with some embodiments may include: obtaining an encoded bitstream corresponding to a media content item; decoding, by a decoder, the encoded bitstream into a decoded bitstream; splitting the decoded bitstream into container file format data and one or more sub-streams, wherein the one or more sub-streams include an atlas sub-stream, a basemesh sub-stream, and one or more submeshsub-streams, and wherein the container file format data includes a reference identifier for the basemesh substream and reference identifiers for each of the one or more submesh sub-streams.

[0190] For some embodiments of the second example method, the container file format includes an International Standards Organization Base Media File Format (ISOBMFF).

[0191] This disclosure describes a variety of aspects, including tools, features, embodiments, models, approaches, etc. Many of these aspects are described with specificity and, at least to show the individual characteristics, are often described in a manner that may sound limiting. However, this is for purposes of clarity in description, and does not limit the disclosure or scope of those aspects. Indeed, all of the different aspects can be combined and interchanged to provide further aspects. Moreover, the aspects can be combined and interchanged with aspects described in earlier filings as well.

[0192] Various numeric values may be used in the present disclosure, for example. The specific values are for example purposes and the aspects described are not limited to these specific values.

[0193] Embodiments described herein may be carried out by computer software implemented by a processor or other hardware, or by a combination of hardware and software. As a non-limiting example, the embodiments can be implemented by one or more integrated circuits. The processor can be of any type appropriate to the technical environment and can encompass one or more of microprocessors, general purpose computers, special purpose computers, and processors based on a multi-core architecture, as non-limiting examples.

[0194] When a figure is presented as a flow diagram, it should be understood that it also provides a block diagram of a corresponding apparatus. Similarly, when a figure is presented as a block diagram, it should be understood that it also provides a flow diagram of a corresponding method / process.

[0195] The implementations and aspects described herein can be implemented in, for example, a method or a process, an apparatus, a software program, a data stream, or a signal. Even if only discussed in the context of a single form of implementation (for example, discussed only as a method), the implementation of features discussed can also be implemented in other forms (for example, an apparatus or program). An apparatus can be implemented in, for example, appropriate hardware, software, and firmware. The methods can be implemented in, for example, a processor, which refers to processing devices in general, including, for example, a computer, a microprocessor, an integrated circuit, or a programmable logic device. Processors also includecommunication devices, such as, for example, computers, cell phones, portable / personal digital assistants (“PDAs”), and other devices that facilitate communication of information between end-users.

[0196] Reference to “one embodiment” or “an embodiment” or “one implementation” or “an implementation”, as well as other variations thereof, means that a particular feature, structure, characteristic, and so forth described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrase “in one embodiment” or “in an embodiment” or “in one implementation” or “in an implementation”, as well any other variations, appearing in various places throughout this disclosure are not necessarily all referring to the same embodiment.

[0197] Additionally, this disclosure may refer to “determining” various pieces of information. Determining the information can include one or more of, for example, estimating the information, calculating the information, predicting the information, or retrieving the information from memory.

[0198] Further, this disclosure may refer to “accessing” various pieces of information. Accessing the information can include one or more of, for example, receiving the information, retrieving the information (for example, from memory), storing the information, moving the information, copying the information, calculating the information, determining the information, predicting the information, or estimating the information.

[0199] Additionally, this disclosure may refer to “receiving” various pieces of information. Receiving is, as with “accessing”, intended to be a broad term. Receiving the information can include one or more of, for example, accessing the information, or retrieving the information (for example, from memory). Further, “receiving” is typically involved, in one way or another, during operations such as, for example, storing the information, processing the information, transmitting the information, moving the information, copying the information, erasing the information, calculating the information, determining the information, predicting the information, or estimating the information.

[0200] It is to be appreciated that the use of any of the following 7”, “and / or”, and “at least one of’, for example, in the cases of “A / B”, “A and / or B” and “at least one of A and B”, is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of both options (A and B). As a further example, in the cases of “A, B, and / or C” and “at least one of A, B, and C”, such phrasing is intended to encompass the selection of the first listed option (A) only, or the selection of the second listed option (B) only, or the selection of the third listed option (C) only, or the selection of the first and the second listed options (A and B) only, or the selection of the first and third listed options (A and C) only, or the selection of thesecond and third listed options (B and C) only, or the selection of all three options (A and B and C). This may be extended for as many items as are listed.

[0201] Implementations can produce a variety of signals formatted to carry information that can be, for example, stored or transmitted. The information can include, for example, instructions for performing a method, or data produced by one of the described implementations. For example, a signal can be formatted to carry the bitstream of a described embodiment. Such a signal can be formatted, for example, as an electromagnetic wave (for example, using a radio frequency portion of spectrum) or as a baseband signal. The formatting can include, for example, encoding a data stream and modulating a carrier with the encoded data stream. The information that the signal carries can be, for example, analog or digital information. The signal can be transmitted over a variety of different wired or wireless links, as is known. The signal can be stored on a processor-readable medium.

[0202] Note that various hardware elements of one or more of the described embodiments are referred to as “modules” that carry out (i.e., perform, execute, and the like) various functions that are described herein in connection with the respective modules. As used herein, a module includes hardware (e.g., one or more processors, one or more microprocessors, one or more microcontrollers, one or more microchips, one or more application-specific integrated circuits (ASICs), one or more field programmable gate arrays (FPGAs), one or more memory devices) deemed suitable by those of skill in the relevant art for a given implementation. Each described module may also include instructions executable for carrying out the one or more functions described as being carried out by the respective module, and it is noted that those instructions could take the form of or include hardware (i.e., hardwired) instructions, firmware instructions, software instructions, and / or the like, and may be stored in any suitable non-transitory computer-readable medium or media, such as commonly referred to as RAM, ROM, etc.

[0203] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in any combination with the other features and elements. In addition, the methods described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMdisks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

CLAIMS1. A method comprising: receiving, by an encoder, a plurality of sub-streams of a media content item, wherein the plurality of sub-streams comprise an atlas sub-stream, a basemesh sub-stream, and one or more submesh sub-streams; generating, by the encoder, a plurality of track references; and encapsulating, by the encoder, the plurality of sub-streams in a container file format, wherein the container file format comprises a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.

2. The method of claim 1 , wherein the container file format comprises an International Standards OrganizationBase Media File Format (ISOBMFF).

3. The method of any one of claims 1-2, wherein the atlas sub-stream comprises a V3C atlas track, and wherein the basemesh sub-stream comprises a basemesh track.

4. The method of any one of claims 1 -3, wherein the container file format further comprises a track reference to link the atlas sub-stream to the basemesh sub-stream.

5. The method of any one of claims 1-4, wherein the container file format further comprises a submesh track reference to link the basemesh sub-stream to a submesh track.

6. The method of claim 5, wherein the submesh track comprises one or more submesh subsamples.

7. The method of claim 6, wherein at least one of the one or more submesh subsamples corresponds to one of the one or more submesh sub-streams.

8. The method of any one of claims 1-7, wherein the container file format further comprises atlas tile track information.

9. The method of claim 8, wherein the atlas tile track information comprises information corresponding to the atlas sub-stream.

10. The method of any one of claims 8-9, wherein the atlas tile track information comprises one or more submesh identifiers.11 . The method of claim 10, wherein at least one of the one or more submesh identifiers corresponds to one of the one or more submesh sub-streams.

12. The method of any one of claims 1-11 , wherein at least one of the sub-streams corresponds to a track in the container file format.

13. A media consumption device configured to perform the method of any one of claims 1-12.

14. At least one processor operatively connected to at least one transceiver, the at least one processor and at least one transceiver configured to perform the method of any one of claims 1 -12.

15. A network device configured to perform the method of any one of claims 1-12.

16. A computing device configured to perform the method of any one of claims 1 -12.1 . An integrated circuit configured to perform the method of any one of claims 1-12.

18. An apparatus comprising: a processor; and a computer-readable medium storing instructions operative, when executed by the processor, to cause the apparatus to perform the method of any one of claims 1 -12.

19. A method comprising: obtaining an encoded bitstream corresponding to a media content item; decoding, by a decoder, the encoded bitstream into a decoded bitstream; splitting the decoded bitstream into container file format data and a plurality of sub-streams, wherein the plurality of sub-streams comprise an atlas sub-stream, a basemesh sub-stream, and one or more submesh sub-streams, and wherein the container file format data comprises a reference identifier for the basemesh sub-stream and reference identifiers for each of the one or more submesh sub-streams.

20. The method of claim 19, wherein the container file format comprises an International Standards OrganizationBase Media File Format (ISOBMFF).21 . A media consumption device configured to perform the method of any one of claims 19-20.

22. At least one processor operatively connected to at least one transceiver, the at least one processor and at least one transceiver configured to perform the method of any one of claims 19-20.

23. A network device configured to perform the method of any one of claims 19-20.

24. A computing device configured to perform the method of any one of claims 19-20.

25. An integrated circuit configured to perform the method of any one of claims 19-20.

26. An apparatus comprising: a processor; and a computer-readable medium storing instructions operative, when executed by the processor, to cause the apparatus to perform the method of any one of claims 19-20.