Mesh data encoding device, mesh data encoding method, mesh data decoding device and mesh data decoding method

Abstract

A method according to embodiments may comprise the steps of: decapsulating a file that includes a bitstream including mesh data; and decoding the mesh data. A method according to embodiments may comprise the steps of: encoding mesh data; and encapsulating a file including a bitstream that includes the mesh data.

Description

Mesh data encoding device, mesh data encoding method, mesh data decoding device and mesh data decoding method

[0001] The embodiments provide a method for providing Point Cloud content to provide various services to users, such as VR (Virtual Reality), AR (Augmented Reality), MR (Mixed Reality), and autonomous driving services.

[0002] A point cloud is a collection of points in 3D space. There is a problem in that it is difficult to generate point cloud data because there are many points in 3D space.

[0003] There is a problem in that a large amount of throughput is required to transmit and receive point cloud data.

[0004] The technical problem according to the embodiments is to provide a point cloud data transmission device, a transmission method, a point cloud data reception device, and a reception method for efficiently transmitting and receiving point clouds in order to solve the aforementioned problems, etc.

[0005] The technical problem according to the embodiments is to provide a point cloud data transmission device, a transmission method, a point cloud data reception device, and a reception method for solving latency and encoding / decoding complexity.

[0006] However, the scope of rights of the embodiments is not limited to the technical problems described above, and may be extended to other technical problems that can be inferred by a person skilled in the art based on the entire content of this document.

[0007] To achieve the above-described purpose and other advantages, the method according to the embodiments may include the step of decapsulating a file containing a bitstream containing mesh data; and the step of decoding the mesh data. The method according to the embodiments may include the step of encoding the mesh data; and the step of encapsulating a file containing a bitstream containing mesh data.

[0008] The point cloud data transmission method, transmission device, point cloud data reception method, and reception device according to the embodiments can provide a high-quality point cloud service.

[0009] The point cloud data transmission method, transmission device, point cloud data reception method, and reception device according to the embodiments can achieve various video codec methods.

[0010] The point cloud data transmission method, transmission device, point cloud data reception method, and reception device according to the embodiments can provide general-purpose point cloud content such as autonomous driving services.

[0011] Drawings are included to further understand the embodiments, and the drawings illustrate the embodiments along with descriptions related to the embodiments. For a better understanding of the various embodiments described below, one must refer to the description of the embodiments below in relation to the following drawings, which include parts corresponding to similar reference numerals throughout the drawings.

[0012] FIG. 1 shows a system for providing dynamic mesh content according to embodiments.

[0013] FIG. 2 illustrates a V-MESH compression method according to embodiments.

[0014] FIG. 3 shows the pre-processing of V-MESH compression according to the embodiments.

[0015] FIG. 4 illustrates a mid-edge subdivision method according to embodiments.

[0016] FIG. 5 illustrates a displacement generation process according to embodiments.

[0017] FIG. 6 illustrates the intra-frame encoding process of the V-MESH compression method according to the embodiments.

[0018] FIG. 7 illustrates the inter-frame encoding process of the V-MESH compression method according to the embodiments.

[0019] FIG. 8 illustrates a lifting conversion process for displacement according to embodiments.

[0020] FIG. 9 illustrates the process of packing conversion coefficients according to embodiments into a 2D image.

[0021] FIG. 10 illustrates the attribute transfer process of the V-MESH compression method according to the embodiments.

[0022] FIG. 11 illustrates the intra-frame decoding process of the V-MESH compression method according to the embodiments.

[0023] FIG. 12 shows a V-MES, and FIG. 13 shows a point cloud data transmission device according to embodiments.

[0024] FIG. 13 shows a point cloud data transmission device according to embodiments.

[0025] FIG. 14 shows a point cloud data receiving device according to embodiments.

[0026] FIG. 15 shows a V-DMC bitstream according to embodiments.

[0027] FIG. 16 shows a V3C unit according to embodiments.

[0028] FIG. 17 shows a mesh system according to embodiments.

[0029] FIG. 18 shows the track of a file according to the embodiments.

[0030] FIG. 19 shows the track of a file according to the embodiments.

[0031] FIG. 20 shows an example of a track reference for a single atlas having no submesh and a single atlas tile according to the embodiments.

[0032] FIG. 21 shows an example of a track reference for a single atlas having multiple submeshes and a single atlas tile, without a submesh track according to the embodiments.

[0033] FIG. 22 shows an example of a track reference for a single atlas track and submesh tracks having multiple submeshes and a single atlas tile according to embodiments.

[0034] FIG. 23 shows an example of a track reference for a single atlas and multiple submeshes having a single atlas tile according to embodiments.

[0035] FIG. 24 shows an example of a track reference composed of a single atlas having a single atlas tile and multiple submeshes as submesh tracks according to embodiments.

[0036] FIG. 25 shows an example of a track reference configured with atlas tile tracks, comprising a single atlas and multiple submeshes having a single atlas tile according to embodiments.

[0037] FIG. 26 shows an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[0038] FIG. 27 shows a receiving device according to embodiments.

[0039] FIG. 28 shows the relationship between atlas tiles and sub-meshes according to embodiments.

[0040] FIG. 29 shows an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[0041] FIG. 30 shows a track reference example comprising a single atlas having a single atlas tile according to embodiments and multiple submeshes configured as submesh tracks.

[0042] FIG. 31 shows an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[0043] FIG. 32 illustrates a method of using a submesh track group as an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[0044] FIG. 33 is an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments, and illustrates a method of using a submesh track group.

[0045] FIG. 34 shows an example of encoding displacement and texture (attribute) composed of atlas tiles and submeshes according to embodiments into a video codec.

[0046] FIG. 35 shows an example of V3C (or VDMC) tile video component track grouping according to embodiments.

[0047] FIG. 36 illustrates a encoding method according to embodiments.

[0048] FIG. 37 illustrates a decoding method according to embodiments.

[0049] Preferred embodiments of the embodiments are described in detail, and examples thereof are shown in the accompanying drawings. The following detailed description, with reference to the accompanying drawings, is intended to describe preferred embodiments of the embodiments rather than merely embodiments that may be implemented according to the embodiments. The following detailed description includes details to provide a thorough understanding of the embodiments. However, it is obvious to those skilled in the art that the embodiments may be practiced without these details.

[0050] Most terms used in the embodiments are selected from those commonly used in the field, but some terms are chosen at the applicant's discretion, and their meanings are described in detail in the following description as necessary. Accordingly, the embodiments should be understood based on the intended meaning of the terms, rather than their mere names or meanings.

[0051] FIG. 1 shows a system for providing dynamic mesh content according to embodiments.

[0052] The system of FIG. 1 includes a point cloud data transmission device (100) and a point cloud data reception device (110) according to embodiments. The point cloud data transmission device may include a dynamic mesh video acquisition unit (101), a dynamic mesh video encoder (102), a file / segment encapsulator (103), and a transmitter (104). The point cloud data reception device (110) may include a receiver (111), a file / segment decapsulator (112), a dynamic mesh video decoder (113), and a renderer (114). Each component of FIG. 1 may correspond to hardware, software, a processor, and / or a combination thereof. Hereinafter, the point cloud data transmission device according to embodiments may be interpreted as a term referring to the transmission device (100) or the dynamic mesh video encoder (hereinafter, encoder) (102). The point cloud data receiving device according to the embodiments may be interpreted as a term referring to the receiving device (110) or the dynamic mesh video decoder (hereinafter, decoder) (113).

[0053] The system of Fig. 1 can perform video-based dynamic mesh compression and decompression.

[0054] With advancements in 3D capture, modeling, and rendering, users can access various forms of 3D content, such as AR, XR, the metaverse, and holograms, across multiple platforms and devices. 3D content represents objects more sophisticatedly and realistically to enable users to enjoy immersive experiences, and for this purpose, the creation and use of 3D models require a large amount of data. Among the various types of 3D content, 3D meshes are widely used for efficient data utilization and realistic object representation. The embodiments include a series of processing steps in a system that uses such mesh content.

[0055] First, the method for compressing dynamic mesh data originates from the V-PCC (Video-based point cloud compression) standard technology. Point cloud data consists of data containing color information along with vertex coordinates (X, Y, Z). Mesh data refers to data where connectivity information between vertices is added to this vertex data. Content can be created in a mesh data format from the outset when generating content. Point cloud data can be converted into mesh data and used by adding connectivity information.

[0056] Currently, the MPEG standards organization defines the data types for dynamic mesh data as the following two types: Category 1: Mesh data containing texture maps as color information. Category 2: Mesh data containing vertex colors as color information.

[0057] Mesh coding standards for Category 1 data are currently being developed, and standardization work for Category 2 data is also scheduled to proceed in the future. As shown in Fig. 1, the entire process for providing mesh content services may include an acquisition process, an encoding process, a transmission process, a decoding process, a rendering process, and / or a feedback process.

[0058] To provide mesh content services, 3D data acquired through multiple cameras or special cameras can be processed into a mesh data type through a series of processes and then generated as a video. The generated mesh video is transmitted after undergoing a series of processes, and at the receiving end, the received data can be processed back into a mesh video and rendered. Through this, the mesh video is provided to the user, and the user can use the mesh content according to their intention through interaction.

[0059] A mesh compression system may include a transmission device and a reception device. The transmission device can encode mesh video to output a bitstream and transmit it to the reception device via a digital storage medium or network in the form of a file or streaming (streaming segment). The digital storage medium may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, and SSD.

[0060] The transmission device may schematically include a mesh video acquisition unit, a mesh video encoder, and a transmission unit. The receiving device may schematically include a receiver, a mesh video decoder, and a renderer. The encoder may be referred to as a mesh video / image / picture / frame encoding device, and the decoder may be referred to as a mesh video / image / picture / frame decoding device. The transmitter may be included in the mesh video encoder. The receiver may be included in the mesh video decoder. The renderer may include a display unit, and the renderer and / or the display unit may be composed of separate devices or external components. The transmission device and the receiving device may further include separate internal or external modules / units / components for a feedback process.

[0061] Mesh data represents the surface of an object using multiple polygons. Each polygon is defined by a vertex in 3D space and connectivity information indicating how those vertices are connected. It may also include vertex attributes such as color and normals. Mapping information, which enables the surface of the mesh to be mapped onto a 2D planar area, can also be included as an attribute of the mesh. Mapping can generally be described by a set of parametric coordinates, referred to as UV coordinates or texture coordinates, associated with the mesh vertices. The mesh contains a 2D attribute map, which can be used to store high-resolution attribute information such as textures, normals, and displacements.

[0062] The mesh video acquisition unit may include processing 3D object data acquired through a camera, etc., into a mesh data type having the attributes described above through a series of processes, and generating a video composed of such mesh data. In a mesh video, the attributes of the mesh, namely vertices, polygons, connectivity information between vertices, color, normals, etc., may change over time. A mesh video having attributes and connectivity information that change over time in this way can be described as a dynamic mesh video.

[0063] A mesh video encoder can encode input mesh video into one or more video streams. A single video may contain multiple frames, and a single frame may correspond to a still image or picture. In this document, the term "mesh video" may include mesh images, frames, or pictures, and the terms mesh video and mesh images, frames, or pictures may be used interchangeably. A mesh video encoder can perform a Video-based Dynamic Mesh (V-Mesh) Compression procedure. To improve compression and coding efficiency, a mesh video encoder can perform a series of procedures such as prediction, transformation, quantization, and entropy coding. The encoded data (encoded video / image information) can be output in the form of a bitstream.

[0064] The file / segment encapsulation module can encapsulate encoded mesh video data and / or mesh video-related metadata into a file or the like. Here, the mesh video-related metadata may be received from a metadata processing module or the like. The metadata processing module may be included in the mesh video encoder or may be configured as a separate component / module. The encapsulation module can encapsulate the data into a file format such as ISOBMFF or process it into other forms such as DASH segments. Depending on the embodiment, the encapsulation module may include mesh video-related metadata in the file format. Mesh video metadata may be included, for example, in various levels of boxes in the ISOBMFF file format or as data within a separate track in the file. Depending on the embodiment, the encapsulation module may encapsulate the mesh video-related metadata itself into a file.

[0065] The transmission processing unit can apply transmission processing to mesh video data encapsulated according to the file format. The transmission processing unit may be included in the transmission unit or may be configured as a separate component / module. The transmission processing unit can process mesh video data according to any transmission protocol. Processing for transmission may include processing for delivery via a broadcast network and processing for delivery via broadband. According to an embodiment, the transmission processing unit may receive mesh video-related metadata from the metadata processing unit in addition to mesh video data, and apply transmission processing to it.

[0066] The transmission unit can transmit encoded video / image information or data output in the form of a bitstream to the receiving unit of a receiving device via a digital storage medium or a network in the form of a file or streaming. The digital storage medium may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, and SSD. The transmission unit may include elements for creating a media file through a predetermined file format and elements for transmission via a broadcasting / communication network. The receiving unit can extract the bitstream and transmit it to a decoding device.

[0067] The receiver can receive mesh video data transmitted by a mesh video transmission device. Depending on the transmission channel, the receiver may receive mesh video data via a broadcast network or via broadband. Alternatively, it may receive mesh video data via a digital storage medium.

[0068] The receiving processing unit can perform processing on the received mesh video data according to the transmission protocol. The receiving processing unit may be included in the receiving unit or may be configured as a separate component or module. Corresponding to the processing for transmission performed on the transmitting side, the receiving processing unit may perform the reverse process of the aforementioned transmission processing unit. The receiving processing unit may transmit the acquired mesh video data to the decapsulation processing unit and the acquired mesh video-related metadata to the metadata parser. The mesh video-related metadata acquired by the receiving processing unit may be in the form of a signaling table.

[0069] The file / segment decapsulation module can decapsulate mesh video data in file format received from the receiving module. The decapsulation module can decapsulate files based on ISOBMFF, etc., to obtain a mesh video bitstream or mesh video-related metadata (metadata bitstream). The obtained mesh video bitstream can be transmitted to a mesh video decoder, and the obtained mesh video-related metadata (metadata bitstream) can be transmitted to a metadata processing module. The mesh video bitstream may also contain metadata (metadata bitstream). The metadata processing module may be included in the mesh video decoder or configured as a separate component / module. The mesh video-related metadata obtained by the decapsulation module may be in the form of boxes or tracks within the file format. If necessary, the decapsulation module may receive metadata required for decapsulation from the metadata processing module. Mesh video-related metadata may be passed to a Mesh video decoder and used in the Mesh video decoding process, or passed to a renderer and used in the Mesh video rendering process.

[0070] The Mesh Video Decoder receives a bitstream as input and performs operations corresponding to those of the Mesh Video Encoder to decode the video. The decoded Mesh Video can be displayed through a display unit. The user can view all or part of the rendered result through a VR / AR display or a standard display.

[0071] The feedback process may include the process of transmitting various feedback information, which can be obtained during the rendering / display process, to the transmitting side or to the decoder of the receiving side. Interactivity in mesh video consumption may be provided through the feedback process. According to an embodiment, head orientation information, viewport information indicating the area the user is currently viewing, etc., may be transmitted during the feedback process. According to an embodiment, the user may interact with elements implemented in a VR / AR / MR / autonomous driving environment, and in this case, information related to such interaction may be transmitted to the transmitting side or the service provider side during the feedback process. According to an embodiment, the feedback process may not be performed.

[0072] Head orientation information can refer to information regarding the user's head position, angle, movement, etc. Based on this information, viewport information—that is, information about the area the user is currently viewing within the mesh video—can be calculated.

[0073] Viewport information may be information about the area currently being viewed by the user within a mesh video. Through this, gaze analysis can be performed to determine how the user consumes the mesh video and to what extent they gaze at specific areas of the mesh video. Gaze analysis may be performed at the receiving end and transmitted to the transmitting end via a feedback channel. Devices such as VR / AR / MR displays can extract the viewport area based on the user's head position / orientation, the vertical or horizontal FOV supported by the device, etc.

[0074] According to the embodiment, the aforementioned feedback information may not only be transmitted to the transmitting side but may also be consumed at the receiving side. That is, decoding and rendering processes at the receiving side may be performed using the aforementioned feedback information. For example, using head orientation information and / or viewport information, only the mesh video for the area currently viewed by the user may be preferentially decoded and rendered.

[0075] This document relates to dynamic mesh video compression as described above. The methods / embodiments disclosed in this document may be applied to the MPEG (Moving Picture Experts Group) Video-based Dynamic Mesh Compression Method (V-Mesh) standard or next-generation video / image coding standards. Dynamic mesh video compression is a method for processing mesh connection information and attributes that change over time, and it can perform lossy and lossless compression for various applications such as real-time communication, storage, free-viewpoint video, and AR / VR.

[0076] The dynamic mesh video compression method described below is based on MPEG's V-Mesh method.

[0077] In this document, "picture" or "frame" generally refers to a unit representing a single image of a specific time period.

[0078] A pixel or pel may refer to the smallest unit that constitutes a picture (or image). Additionally, the term 'sample' may be used as a counterpart to pixel. A sample can generally represent a pixel or a pixel value, and may represent only the pixel / pixel value of the lumina component, only the pixel / pixel value of the chroma component, or only the pixel / pixel value of the depth component.

[0079] A unit may represent a basic unit of image processing. A unit may include at least one of a specific area of ​​a picture and information related to that area. Depending on the case, the term unit may be used interchangeably with terms such as block or area. In general, an MxN block may include samples (or sample arrays) or a set (or array) of transform coefficients consisting of M columns and N rows.

[0080] The encoding process of Fig. 1 is as follows.

[0081] Video-based dynamic mesh compression (V-Mesh) compression methods can provide a method for compressing dynamic mesh video data based on 2D video codecs such as HEVC and VVC. In the V-Mesh compression process, compression is performed by receiving the following data as input.

[0082] Input mesh: It includes the 3D coordinates (geometry) of the vertices constituting the mesh, normal information for each vertex, mapping information for mapping the mesh surface to a 2D plane, and connection information between the vertices constituting the surface. The surface of the mesh can be represented by triangles or polygons of greater size, and connection information between the vertices constituting each surface is stored according to a defined shape. The input mesh can be saved in the OBJ file format.

[0083] Attribute map: (Hereafter, Texture map is used with the same meaning): It contains information on the attributes (color, normals, displacement, etc.) of a mesh and stores data in the form of mapping the mesh surface onto a 2D image. Mapping which part of the mesh (surface or vertex) corresponds to each data point in this attribute map is based on the mapping information contained in the input mesh. Since the attribute map holds data for each frame of the mesh video, it can also be referred to as an attribute map video (or simply "attribute"). In the V-Mesh compression method, the attribute map primarily contains the mesh's color information and is stored in image file formats (PNG, BMP, etc.).

[0084] Material Library File: Contains material attribute information used in the mesh, specifically information that links the input mesh with its corresponding attribute map. This is saved in the Wavefront Material Template Library (MTL) file format.

[0085] In the V-Mesh compression method, the following data and information can be generated through the compression process.

[0086] Base Mesh: By simplifying (decimating) the input mesh through a preprocessing stage, objects from the input mesh are represented using the minimum number of vertices determined according to user criteria.

[0087] Displacement: Displacement information used to represent the input mesh as similarly as possible using the base mesh, expressed in the form of 3D coordinates.

[0088] Atlas information: This is metadata required to reconstruct a mesh using base mesh, displacement, and attribute map information. It can be generated and utilized as sub-units (sub-mesh, patch, etc.) that constitute the mesh.

[0089] Referring to FIGS. 2 through 7, a method for encoding mesh position information (vertices) is described, and referring to FIGS. 6-10 and others, a method for restoring mesh position information and encoding attribute information (attribute map) is described.

[0090] FIG. 2 illustrates a V-MESH compression method according to embodiments.

[0091] FIG. 2 illustrates the encoding process of FIG. 1, and the encoding process may include pre-processing and encoding processes. The encoder of FIG. 1 may include a pre-processor (200) and an encoder (201) as in FIG. 2. The transmitting device of FIG. 1 may be broadly referred to as an encoder, and the dynamic mesh video encoder of FIG. 1 may be referred to as an encoder. The V-Mesh compression method may include pre-processing (200) and encoding (201) processes as in FIG. 2. The pre-processor of FIG. 2 may be located in front of the encoder of FIG. 2. The pre-processor and encoder of FIG. 2 may be referred to as a single encoder.

[0092] The pre-processor can receive a static dynamic mesh and / or attribute map. The pre-processor can generate a base mesh and / or displacement through preprocessing. The pre-processor can receive feedback information from an encoder and generate a base mesh and / or displacement based on the feedback information.

[0093] The encoder can receive a base mesh, displacement, static and dynamic meshes, and / or attribute maps. The encoder can encode mesh-related data to generate a compressed bitstream.

[0094] FIG. 3 shows the pre-processing of V-MESH compression according to the embodiments.

[0095] Figure 3 shows the configuration and operation of the pre-processor of Figure 2.

[0096] FIG. 3 illustrates a process of performing preprocessing on an input mesh. The preprocessing process (200) may include four main steps: 1) generation of a Group of Frame (GoF), 2) mesh decimation, 3) UV parameterization, and 4) fitting subdivision surface (300). The pre-processor (200) may receive the input mesh, generate displacement and / or a base mesh, and transmit it to the encoder (201). The pre-processor (200) may transmit GoF information associated with GoF generation to the encoder (201).

[0097] Below, each step of Fig. 3 is explained.

[0098] GoF Generation: This is the process of creating a reference structure for mesh data. If the number of vertices, texture coordinates, vertex connectivity, and texture coordinate connectivity of the mesh in the previous frame and the current mesh are all identical, the previous frame can be set as the reference frame. In other words, if only the vertex coordinate values ​​differ between the current input mesh and the reference input mesh, inter-frame encoding can be performed. Otherwise, the frame undergoes intra-frame encoding.

[0099] Mesh Decimation: This is the process of simplifying the input mesh to generate a simplified mesh, or base mesh. After selecting vertices to remove from the original mesh based on user-defined criteria, the selected vertices and the triangles connected to them can be removed.

[0100] In the process of performing mesh decimation, information regarding the input mesh (voxelized), target triangle ratio (TTR), and minimum triangle component (CCCount) is passed as input, and a decimated mesh can be obtained as output. In this process, connected triangle components smaller than the set minimum triangle component (CCCount) can be removed.

[0101] UV Parameterization: This is the process of mapping 3D surfaces to a texture domain for a decimated mesh. Parameterization can be performed using a UV Atlas tool. Through this process, mapping information is generated regarding where each vertex of the decimated mesh can be mapped to on a 2D image. This mapping information is expressed and stored as texture coordinates, and the final base mesh is generated through this process.

[0102] Fitting subdivision surface: This is the process of performing subdivision on a decimated mesh. User-defined methods, such as the mid-edge method, can be applied as the subdivision method. A fitting process is performed to make the input mesh and the subdivision mesh similar to each other.

[0103] FIG. 4 illustrates a mid-edge subdivision method according to embodiments.

[0104] Figure 4 illustrates the mid-edge method of the fitting subdivision surface described in Figure 3. Referring to Figure 4, an original mesh containing 4 vertices is subdivided to create a sub-mesh. A sub-mesh can be created by creating a new vertex at the midpoint of the edge between vertices.

[0105] When a fitted subdivided mesh (hereinafter referred to as the fitted subdivided mesh) is generated, displacement is calculated using this result and a pre-compressed and decoded base mesh (hereinafter referred to as the reconstructed base mesh). That is, the reconstructed base mesh is subdivided in the same way as the fitting subdivision surface. The positional difference between this result and the fitted subdivided mesh for each vertex becomes the displacement for each vertex. Since displacement represents a positional difference in three-dimensional space, it is also expressed as a value in the (x, y, z) space of the Cartesian coordinate system. Depending on the user input parameters, the (x, y, z) coordinate values ​​can be converted into (normal, tangential, bi-tangential) coordinate values ​​of the local coordinate system.

[0106] FIG. 5 illustrates a displacement generation process according to embodiments.

[0107] FIG. 5 illustrates in detail the displacement calculation method of a fitting subdivision surface (300) as described in FIG. 4.

[0108] An encoder and / or pre-processor according to the embodiments may include 1) a subdivision unit, 2) a local coordinate system calculation unit, and 3) a displacement calculation unit. The subdivision unit may receive a restored base mesh and generate a subdivided restored base mesh. The local coordinate system calculation unit may receive a fitted subdivided mesh and a subdivided restored base mesh and convert a coordinate system relating to the mesh to a local coordinate system. The local coordinate system calculation operation may be optional. The displacement calculation unit calculates the positional difference between the fitted subdivision mesh and the subdivided restored base mesh. For example, it may generate a positional difference value between the vertices of the two input meshes. The vertex positional difference value becomes the displacement.

[0109] The method and apparatus for transmitting point cloud data according to the embodiments can encode the point cloud as follows. The point cloud data according to the embodiments (which may be referred to simply as point cloud) may refer to data including vertex coordinates and color information. Point cloud is a term that includes mesh data, and in this document, point cloud and mesh data may be used interchangeably.

[0110] The V-Mesh compression (restoration) method according to the embodiments may include intra-frame encoding (Fig. 6) and inter-frame encoding (Fig. 7).

[0111] Intra-frame encoding or inter-frame encoding is performed based on the results of the aforementioned GoF generation. In the case of intra-frame encoding, the data to be compressed may include a base mesh, displacement, and attribute map. In the case of inter-frame encoding, the data to be compressed may include displacement, attribute map, and the motion field between the reference base mesh and the current base mesh.

[0112] FIG. 6 illustrates the intra-frame encoding process of the V-MESH compression method according to the embodiments.

[0113] The encoding process of FIG. 6 illustrates the encoding of FIG. 1 in detail. That is, it shows the configuration of the encoder when the encoding of FIG. 1 is an intra-frame method. The encoder of FIG. 6 may include a preprocessor (200) and / or an encoder (201).

[0114] A pre-processor receives an input mesh and can perform the aforementioned preprocessing. Through preprocessing, a base mesh and / or a fitted subdivided mesh can be generated. A quantizer can quantize the base mesh and / or the fitted subdivided mesh. A static mesh encoder can encode a static mesh. A static mesh encoder can generate a bitstream containing the encoded base mesh. A static mesh decoder can decode the encoded static mesh. An inverse quantizer can inversely quantize the quantized static mesh. A displacement computer receives the restored static mesh and, based on the fitted subdivided mesh, can generate displacement, which is the positional difference. A forward linear lifting unit receives the displacement and can generate lifting coefficients. A quantizer can quantize the lifting coefficients. An image packing unit can pack an image based on the quantized lifting coefficients. A video encoder can encode a packed image. A video decoder decodes the encoded video. An image unpacker can unpack a packed image. An inverse quantizer can inversely quantize an image. An inverse linear lifting unit applies inverse lifting to the image to generate a reconstructed displacement. A mesh recovery unit reconstructs a deformed mesh using the reconstructed displacement and the reconstructed base mesh. An attribute transfer unit receives an input mesh and / or an input attribute map and generates an attribute map based on the reconstructed deformed mesh. Push-pull padding can pad data into the attribute map based on a push-pull method. A color space conversion unit can convert the space of the color component, which is an attribute. A video encoder can encode attributes. A multiplexer can multiplex the compressed base mesh, compressed displacement, and compressed attributes to generate a bitstream.

[0115] FIG. 7 illustrates the inter-frame encoding process of the V-MESH compression method according to the embodiments.

[0116] The encoding process of FIG. 7 illustrates the encoding of FIG. 1 in detail. That is, it shows the configuration of the encoder when the encoding of FIG. 1 is an inter-frame method. The encoder of FIG. 7 may include a preprocessor (200) and / or an encoder (201).

[0117] Refer to the description of FIG. 7 for the configuration corresponding to the encoding operation of FIG. 6 among the encoding operations of FIG. 7. For the inter-frame based encoding of FIG. 7, the motion encoder can encode motion based on a reconstructed quantized reference base mesh. The base mesh reconstruction unit can reconstruct a base mesh based on the reconstructed quantized reference base mesh.

[0118] The encoder of FIG. 6 generates a bitstream by compressing the base mesh, displacement, and attributes within the frame, and the encoder of FIG. 7 generates a bitstream by compressing the motion, displacement, and attributes between the current frame and the reference frame.

[0119] The encoding method according to the embodiments includes base mesh encoding (intra encoding). When performing intra frame encoding on the current input mesh frame, the base mesh generated during the preprocessing process can be encoded using static mesh compression technology after undergoing a quantization process. In the V-Mesh compression method, for example, Draco technology is applied, and vertex position information, mapping information (texture coordinates), vertex connection information, etc. of the base mesh are subject to compression.

[0120] The encoding method according to the embodiments may include motion field encoding (inter encoding). Inter frame encoding may be performed when a one-to-one correspondence between vertices is established between the reference mesh and the current input mesh, and only the position information of the vertices differs. When performing inter frame encoding, instead of compressing the base mesh, the difference between the vertices of the reference base mesh and the current base mesh, i.e., the motion field, may be calculated and this information encoded. The reference base mesh is the result of quantizing already decoded base mesh data and is determined according to the reference frame index determined in the GoF generation. The motion field may be encoded as is. Alternatively, the motion fields of the restored vertices among the vertices connected to the current vertex may be averaged to calculate a predicted motion field, and this predicted motion field value and the current The residual motion field, which is the difference between the motion field values ​​of the vertices, can be encoded. This value can be encoded using entropy coding. The process of encoding displacement and attribute maps, excluding the motion field encoding process of inter-frame encoding, is identical to the structure of intra-frame encoding, excluding base mesh encoding.

[0121] FIG. 8 illustrates a lifting conversion process for displacement according to embodiments.

[0122] FIG. 9 illustrates the process of packing conversion coefficients according to embodiments into a 2D image.

[0123] FIGS. 8-9 respectively show the process of converting the displacement of the encoding process of FIGS. 6-7 and the process of packing the conversion coefficients.

[0124] The encoding method according to the embodiments includes displacement encoding.

[0125] After encoding the base mesh through base mesh encoding and / or motion field encoding, a reconstructed base mesh is generated through reconstruction and inverse quantization. Subdivision is then performed on this reconstructed base mesh, and the displacement between the result and the fitted subdivided mesh generated through the fitting subdivision surface can be calculated. For effective encoding, a data transform process such as a wavelet transform can be applied to the displacement information.

[0126] FIG. 8 illustrates the process of transforming displacement information using a lifting transform in V-Mesh. The transformation coefficients generated through the transformation process are quantized and then packed into a 2D image as shown in FIG. 9. The transformation coefficients are organized into one block for every 256 (=16 x 16) units, and each block can be packed in z-scan order. The number of horizontal blocks is fixed at 16, while the number of vertical blocks can be determined by the number of vertices in the subdivided base mesh. Within a single block, the transformation coefficients can be packed by aligning them using a Morton code. The packed images generate a displacement video for every GoF unit, and this displacement video can be encoded using a conventional video compression codec.

[0127] Referring to FIG. 8, the base mesh (original) may include vertices and edges for LoD0. A first subdivision mesh generated by dividing the base mesh includes vertices generated by further dividing the edges of the base mesh. The first subdivision mesh includes vertices for LoD0 and vertices for LoD1. LoD1 includes subdivided vertices and vertices of the base mesh (LoD0). A second subdivision mesh may be generated by dividing the first subdivision mesh. The second subdivision mesh includes LoD2. LoD2 includes base mesh vertices (LoD0), LoD1 containing vertices additionally generated from LoD0, and vertices additionally divided from LoD1. LoD is a Level of Detail indicating the degree of detail; as the level index increases, the distance between vertices becomes closer, and the level of detail increases. LoD N includes the vertices included in the previous LoDN-1 as they are. When vertices are further subdivided through subdivision, the mesh can be encoded based on a prediction and / or update method by considering the previous vertices v1 and v2 and the subdivided vertex v. Instead of encoding the information for the current LoD N as is, the size of the bitstream can be reduced by generating residuals between the previous LoD N-1 and encoding the mesh using these residuals. The prediction process refers to the operation of predicting the current vertex v based on the previous vertices v1 and v2. Since adjacent subdivided meshes possess similar data, efficient encoding can be achieved by utilizing this property. The current vertex position information is predicted using the residuals from the previous vertex position information, and the previous vertex position information is updated using these residuals.

[0128] Referring to FIG. 9, the vertices have coefficients generated through a lifting transformation. The coefficients of the vertices related to the lifting transformation can be encoded by packing them into an image.

[0129] FIG. 10 illustrates the attribute transfer process of the V-MESH compression method according to the embodiments.

[0130] Figure 10 shows the detailed operation of attribute transfer of encoding such as Figures 6-7.

[0131] The encoding according to the embodiments includes attribute map encoding.

[0132] Information regarding the input mesh is compressed through base mesh encoding, motion field encoding, and displacement encoding. The input mesh compressed during the encoding process is restored through base mesh decoding (intra frame), motion field encoding (inter frame), and displacement video decoding. The resulting restored deformed mesh (hereinafter referred to as Recon. deformed mesh) is used to compress the input attribute map, as shown in FIGS. 6 and 7. The Recon. deformed mesh possesses vertex position information, texture coordinates, and corresponding connection information, but lacks color information corresponding to the texture coordinates. Accordingly, as shown in FIG. 10, a new attribute map having color information corresponding to the texture coordinates of the reconstructed deformed mesh is generated through the attribute transfer process in the V-Mesh compression method.

[0133] Attribute transfer first checks for every point P(u, v) in the 2D texture domain whether the point belongs to a texture triangle of the reconstructed deformed mesh, and if it does, calculates the barycentric coordinates (α, βγ) of P(u, v) according to that triangle T. Then, using the 3D vertex position of triangle T and (α, βγ), calculates the 3D coordinates M(x, y, z) of P(u, v). In the input mesh domain, finds the vertex coordinates M'(x', y', z') corresponding to the position most similar to the calculated M(x, y, z) and triangle T' containing this point. Then, the center of mass coordinates (α', β', γ') of M'(x', y', z') in this triangle T' are calculated. Using the texture coordinates corresponding to the three vertices of Triangle T' and (α', β', γ'), texture coordinates (u', v') are calculated, and the color information corresponding to these coordinates is found in the Input Attribute Map. The color information found in this way is then assigned to the pixel location (u, v) in the new Attribute Map. If P(u, v) does not belong to any triangle, the pixel at that location in the new Attribute Map can be filled with a color value using a padding algorithm such as the Push-Pull algorithm.

[0134] The new attribute map generated through attribute transfer is bundled in GoF units to form an attribute map video, which is then compressed using a video codec.

[0135] Referring to FIG. 10, the reference relationships between the input mesh, input attribute map, restored mesh, and generated attribute map can be seen.

[0136] The decoding process of Fig. 1 can perform the reverse process of the corresponding process of the encoding process of Fig. 1. The specific decoding process is as follows.

[0137] FIG. 11 illustrates the intra-frame decoding process of the V-MESH compression method according to the embodiments.

[0138] Figure 11 shows the configuration and operation of the decoder of the receiving device of Figure 1.

[0139] Figure 11 illustrates the intra-decoding process of V-Mesh technology. First, the input bitstream can be separated into a mesh sub-stream, a displacement sub-stream, an attribute map sub-stream, and a sub-stream containing mesh patch information such as V3C / V-PCC.

[0140] The mesh sub-stream is decoded through a decoder of a static mesh codec used in encoding, such as Google Draco, and as a result, connectivity information, vertex geometry, and vertex texture coordinates of the base mesh can be restored. The displacement sub-stream is decoded into displacement video through a decoder of a video compression codec used in encoding, and is restored into displacement information for each vertex through image unpacking, inverse quantization, and inverse transform processes. After inverse quantization is applied to the restored base mesh, the result is combined with the restored displacement information to generate the final decoded mesh.

[0141] The attribute map sub-stream is decoded through the decoder of the video compression codec used in encoding, and then restored to the final attribute map after undergoing processes such as color format conversion.

[0142] The restored decoded mesh and decoded attribute map can be utilized at the receiving end as final mesh data that the user can use.

[0143] Referring to FIG. 11, the bitstream includes patch information, a mesh substream, a displacement substream, and an attribute map substream. A substream is interpreted as a term referring to a substream included in the bitstream. The bitstream includes patch information (data), mesh information (data), displacement information (data), and attribute cap information (data).

[0144] The decoder performs the next decoding operation within the frame. The static mesh decoder decodes the mesh to generate a reconstructed quantized base mesh, and the inverse quantizer applies the quantization parameters of the quantizer in reverse to generate the reconstructed base mesh. The video decoder decodes the displacement, the unpacker unpacks the decoded video image, and the inverse quantizer quantizes the quantized image in reverse. The linear lifting inverse transform unit generates the reconstructed displacement by applying a lifting transform as the inverse process of the encoder. The mesh reconstruction unit generates a deformed mesh based on the base mesh and displacement. The video decoder decodes the attribute map, and the color conversion unit converts the color format and / or space to generate the decoded attribute map.

[0145] Figure 12 illustrates the inter-frame decoding process of the V-MESH compression method.

[0146] Figure 12 shows the configuration and operation of the decoder of the receiving device of Figure 1.

[0147] Figure 12 illustrates the inter-decoding process of V-Mesh technology. First, the input bitstream can be separated into a motion sub-stream, a displacement sub-stream, an attribute sub-stream, and a sub-stream containing mesh patch information such as V3C / V-PCC.

[0148] The motion sub-stream is decoded through entropy decoding and inverse prediction processes, and the restored motion information is combined with the already restored reference base mesh to generate a reconstructed quantized base mesh for the current frame. The result of applying inverse quantization to this is combined with displacement information restored in the same way as the aforementioned intra decoding to generate a final decoded mesh. The attribute map sub-stream is decoded in the same way as the intra decoding. The restored decoded mesh and the decoded attribute map can be utilized at the receiving end as final mesh data that can be used by the user.

[0149] Referring to FIG. 12, the bitstream includes motion, displacement, and attribute maps. Since inter-frame decoding is performed, the process of decoding inter-frame motion information is further included. The motion is decoded, and a reconstructed quantized base mesh for the motion is generated based on a reference base mesh to create a reconstructed base mesh. For a description of the operation in FIG. 12 which is identical to FIG. 11, refer to the description in FIG. 11.

[0150] FIG. 13 shows a point cloud data transmission device according to embodiments.

[0151] FIG. 13 corresponds to the transmitting device (100) of FIG. 1, the dynamic mesh video encoder (102), the encoder (preprocessor and encoder) of FIG. 2, and / or the corresponding transmitting encoding device. Each component of FIG. 13 corresponds to hardware, software, a processor, and / or a combination thereof.

[0152] The operation process of the transmitting end for compressing and transmitting dynamic mesh data using V-Mesh compression technology may be as shown in FIG. 13.

[0153] The mesh preprocessor takes the original mesh as input and generates a decimated mesh. Decimation can be performed based on the target number of vertices or polygons constituting the mesh. Parameterization can be performed on the decimated mesh to generate texture coordinates and texture connectivity information per vertex. Additionally, floating-point mesh information can be quantized into fixed-point form. This result can be encoded as a base mesh through a static mesh encoder. The mesh preprocessor can generate additional vertices by performing mesh subdivision on the base mesh. Depending on the subdivision method, vertex connectivity information including the added vertices, texture coordinates, and texture coordinate connectivity information can be generated. The subdivided mesh can be fitted by adjusting vertex positions to resemble the original mesh, thereby generating a fitted subdivided mesh.

[0154] When intra-encoding is performed on the corresponding mesh frame, the base mesh generated through the mesh preprocessor can be compressed through the static mesh encoder. In this case, encoding can be performed on the base mesh's connectivity information, vertex geometry information, vertex texture information, normal information, etc. The base mesh bitstream generated through encoding is transmitted to the multiplexer.

[0155] When inter-encoding is performed on the corresponding mesh frame, a motion vector encoding unit is executed. Using the base mesh and the reference restoration base mesh as inputs, the motion vector between the two meshes is calculated and the value is encoded. The motion vector encoding unit performs prediction based on connection information using the previously encoded / decoded motion vector as a predictor, and can encode the residual motion vector obtained by subtracting the predicted motion vector from the current motion vector. The motion vector bitstream generated through encoding is transmitted to the multiplexer.

[0156] The encoded base mesh and motion vectors can generate a restored base mesh through the base mesh restoration unit.

[0157] The displacement vector calculator can perform mesh subdivision on the reconstructed base mesh. The displacement vector can be calculated as the difference in vertex positions between the subdivided reconstructed base mesh and the fitted subdivision mesh generated in the preprocessing unit. As a result, displacement vectors can be calculated for each vertex of the subdivision mesh. The displacement vector calculation unit can convert the displacement vector calculated in a 3D Cartesian coordinate system into a local coordinate system based on the normal vector of each vertex.

[0158] A displacement vector video generator can transform displacement vectors for effective encoding. Depending on the embodiment, the transformation may be performed using a lifting transformation, a wavelet transformation, etc. Additionally, quantization can be performed on the transformed displacement vector values, i.e., the transformation coefficients. Different quantization parameters can be applied to each axis of the transformation coefficients, and the quantization parameters can be derived by the agreement of the encoder / decoder. The displacement vector information that has undergone transformation and quantization can be packed into 2D images. A displacement vector video can be generated by combining the packed 2D images for each frame, and the displacement vector video can be generated for each GoF (Group of Frame) unit of the input mesh.

[0159] The displacement vector video encoder can encode the generated displacement vector video using a video compression codec. The generated displacement vector video bitstream is transmitted to the multiplexer.

[0160] The displacement vector restored through the displacement vector restorer and the base mesh restored and subdivided through the base mesh restorer are restored through the mesh restorer, and the restored mesh contains restored vertices, connection information between vertices, texture coordinates, and connection information between texture coordinates.

[0161] The texture map of the original mesh can be regenerated into a texture map for the restored mesh through the texture map video generation unit. Vertex-specific color information from the original mesh's texture map can be assigned to the texture coordinates of the restored mesh. The texture maps regenerated for each frame can be grouped by GoF unit to generate a texture map video.

[0162] The generated texture map video can be encoded using a video compression codec through the texture map video encoding unit. The texture map video bitstream generated through encoding is transmitted to the multiplexer.

[0163] The generated motion vector bitstream, base mesh bitstream, displacement vector bitstream, and texture map bitstream can be multiplexed into a single bitstream and transmitted to the receiver via the transmitter. Alternatively, the generated motion vector bitstream, base mesh bitstream, displacement vector bitstream, and texture map bitstream can be generated into a file with one or more track data or encapsulated into segments and transmitted to the receiver via the transmitter.

[0164] Referring to FIG. 13, the transmitting device (encoder) can encode the mesh using an intra-frame or inter-frame method. The transmitting device according to intra-encoding can generate a base mesh, displacement vectors (displacement), and a texture map (attribute map). The transmitting device according to inter-encoding can generate motion vectors (motion), a base mesh, displacement vectors (displacement), and a texture map (attribute map). The texture map obtained from the data input unit is generated and encoded based on the restored mesh. Displacement is generated and encoded through the difference in vertex positions between the base mesh and the divided mesh. The base mesh is generated by preprocessing, simplifying, and encoding the original mesh. Motion is generated as a motion vector for the mesh of the current frame based on the reference base mesh of the previous frame.

[0165] FIG. 14 shows a point cloud data receiving device according to embodiments.

[0166] FIG. 14 corresponds to the receiving device (110) of FIG. 1, the dynamic mesh video decoder (113), the decoders of FIG. 11-12, and / or the corresponding receiving decoding device. Each component of FIG. 14 corresponds to hardware, software, a processor, and / or a combination thereof. The receiving (decoding) operation of FIG. 14 may follow the reverse process of the corresponding process of the transmitting (encoding) operation of FIG. 13.

[0167] The received Mesh bitstream is demultiplexed into a compressed motion vector bitstream or base mesh bitstream, displacement vector bitstream, and texture map bitstream after file / segment decapsulation.

[0168] If the current mesh has inter-frame encoding applied based on the frame header information, decoding can be performed on the motion vector bitstream in the motion vector decoder. The final motion vector can be restored by using the previously decoded motion vector as a predictor and adding it to the residual motion vector decoded from the bitstream.

[0169] If the current mesh has in-frame encoding applied based on the frame header information, the base mesh bitstream can restore the base mesh's connectivity information, vertex geometry, texture coordinates, normal information, etc., through the static mesh encoding section.

[0170] In the base mesh restoration unit, if the current mesh is subject to inter-frame encoding, the current base mesh can be restored by adding the decoded motion vector to the reference base mesh and then performing inverse quantization. If the current mesh is subject to intra-frame encoding, the restored base mesh can be generated by performing inverse quantization on the mesh decoded through the static mesh decoding unit.

[0171] The displacement vector bitstream can be decoded as a video bitstream using a video codec in the displacement vector video decoder.

[0172] In the displacement vector restoration unit, displacement vector transformation coefficients are extracted from the decoded displacement vector video, and the displacement vector is restored through inverse quantization and inverse transformation processes. If the restored displacement vector is a value in the local coordinate system, an inverse transformation to the Cartesian coordinate system can be performed.

[0173] The mesh restoration unit can generate additional vertices by performing subdivision on the restored base mesh. Through subdivision, vertex connection information including the added vertices, texture coordinates, and connection information of the texture coordinates can be generated. The subdivided restored base mesh can be combined with the restored displacement vectors to generate the final restored mesh.

[0174] The texture map bitstream can be decoded as a video bitstream using a video codec in the texture map video decoder. The restored texture map contains color information for each vertex contained in the restored mesh, and the color value of the corresponding vertex can be retrieved from the texture map using the texture coordinates of each vertex.

[0175] The restored mesh and texture map are displayed to the user through a rendering process using a mesh data renderer, etc.

[0176] Referring to FIG. 14, a receiving device (decoder) can decode a mesh using an intra-frame or inter-frame method. A receiving device according to intra-decoding receives a base mesh, a displacement vector (displacement), and a texture map (attribute map), and can render mesh data by decoding the restored mesh and the restored texture map. A receiving device according to inter-decoding receives a motion vector (motion), a base mesh, a displacement vector (displacement), and a texture map (attribute map), and can render mesh data by decoding the restored mesh and the restored texture map.

[0177] A point cloud data transmission device and method according to the embodiments may encode mesh data and transmit a bitstream containing the encoded mesh data. A point cloud data reception device and method according to the embodiments may receive a bitstream containing mesh data and decode the mesh data. A point cloud data transmission and reception method / device according to the embodiments may be referred to simply as a method / device according to the embodiments. A point cloud data transmission and reception method / device according to the embodiments may also be referred to as a mesh data transmission and reception method / device according to the embodiments.

[0178] An encoding method / device according to embodiments (Fig. 1 transmitting device (100), acquisition unit (101), encoder (102), encapsulator (103), transmitter (104), Fig. 2, Fig. 3, Fig. 5, Fig. 7 pre-processing, encoder, Fig. 13 encoder, multiplexer, transmission unit, Fig. 15 to Fig. 16 bitstream and syntax generation, Fig. 17 acquisition unit, pre-processing, encoding, encapsulating, Fig. 18 to Fig. 34 file encapsulating, Fig. 35 encoding method) can encode mesh data and generate a bitstream as in Fig. 15.

[0179] A decoding method / device according to embodiments (a receiving device (110) in FIG. 1, a receiving unit (111), a decapsulator (112), a decoder (113), a renderer (114), decoding in FIG. 11 and FIG. 12, a receiving unit, a demultiplexer, a renderer in FIG. 14, bitstream and syntax acquisition in FIG. 15 to 16, decapsulating, decoding, rendering in FIG. 17, file decapsulating in FIG. 18 to 34, a file receiver, a file parser, a bitstream packager, a decoder in FIG. 27, a decoding method in FIG. 26, etc.) receives a bitstream as in FIG. 15 and can decode mesh data based on parameter information included in the bitstream.

[0180] The method and apparatus according to the embodiments may include and perform a multiple track reference and group signaling scheme of dynamic mesh coding bitstream.

[0181] For example, it may include a method for storing a V-DMC (Video-based Dynamic Mesh Coding) bitstream as multiple tracks within a file and a method for signaling, a method for file encapsulation when the V-DMC bitstream is composed of submesh, a method for signaling partial access or partial access to the V-DMC bitstream, a method for signaling connection information between a scene object and a submesh of the V-DMC bitstream, a method for signaling multiple submeshs of the V-DMC bitstream, a method for signaling track references for multiple tracks of the V-DMC bitstream, and a method for signaling track grouping for multiple tracks of the V-DMC bitstream.

[0182] The embodiments include a transmitter (encoder) or a receiver (decoder) for providing a mesh content service that efficiently stores V-DMC or mesh bitstreams within a plurality of tracks in a file and provides signaling therefor.

[0183] The embodiments include a transmitter or receiver for providing a mesh content service that processes a file storage technique to enable efficient access to a stored V-DMC bitstream.

[0184] The embodiments are described in terms of V-DMC, but the contents according to the embodiments may be applied not only to V-DMC but also to bitstreams using other mesh coding configured in the same manner or a similar bitstream form.

[0185] According to the embodiments, if the basemesh data of the V-DMC bitstream is composed of a submesh, the embodiments further include a method for signaling submesh-related information to file-level sample entries and / or samples.

[0186] When the base mesh data of the V-DMC bitstream according to the embodiments is composed of a submesh and scene object information is signaled within the content, the embodiments further include a method of signaling relationship information between the scene object and the submesh to the existing spatial region information.

[0187] According to the embodiments, when the base mesh data of the V-DMC bitstream is composed of a submesh and scene object information is signaled together with spatial region information, the embodiments further include a signaling method for dynamically changing spatial region information using a sample grouping method.

[0188] According to the embodiments, when the V-DMC bitstream includes one or more submeshes, and the basemesh bitstream and submesh bitstream are stored as respective tracks, the embodiments further include a signaling method for the connection relationship between the basemesh track and the submesh track according to the sample entry type.

[0189] When each V-DMC component constituting the V-DMC bitstream according to the embodiments is configured as multiple tracks, the embodiments further include signaling methods for connecting and grouping the tracks.

[0190] Mesh content encoded in V-DMC can be encapsulated into multiple tracks based on ISOBMFF files to be provided as a service, such as streaming.

[0191] When the basemesh data of a V-DMC bitstream is composed of submesh, the receiver may be able to decode sequentially or in parallel simultaneously on a submesh basis. Additionally, partial access and decoding may be possible on a submesh basis. To this end, the embodiments may generate and derive the following signaling information at the file level. For example, it may include a file-level signaling method for submesh information, a track grouping method between one or more submesh tracks, etc.

[0192] At the V-DMC bitstream level, partial decoding may be possible at the submesh level. However, submeshes at the bitstream level can only be decoded independently and cannot become meaningful 3D objects. Therefore, the embodiments configure sparse region signaling to enable partial access at the file level in units of meaningful sparse regions, and include mapping signaling with one or more submeshes associated with each sparse region. For example, the methods may include a signaling method for sparse regions for partial access, a signaling method for mapping information between sparse regions and submeshes, a signaling method for scene object and submesh configuration information, and a signaling method for dynamically changing sparse region configuration information using sample grouping.

[0193] Where a basemesh bitstream is composed of one or more submesh bitstreams, the embodiments further include a method for signaling by defining the connection relationships and constraints between the basemesh track and the submesh track according to the sample entry type of each track when encapsulating in a multiple track file format.

[0194] When not only the basemesh bitstream but also other V-DMC components constituting the V-DMC bitstream are encapsulated into individual tracks, the connections between these tracks can be signaled using track referencing and track grouping methods. By defining and signaling the connections between tracks, the receiver can parse, decode, and render only for related tracks in scenarios such as partial access based on the viewport.

[0195] FIG. 15 shows a V-DMC bitstream according to embodiments.

[0196] An encoding method / device according to embodiments (Fig. 1 transmitting device (100), acquisition unit (101), encoder (102), encapsulator (103), transmitter (104), Fig. 2, Fig. 3, Fig. 5, Fig. 7 pre-processing, encoder, Fig. 13 encoder, multiplexer, transmission unit, Fig. 15 to Fig. 16 bitstream and syntax generation, Fig. 17 acquisition unit, pre-processing, encoding, encapsulating, Fig. 18 to Fig. 34 file encapsulating, Fig. 35 encoding method) can encode mesh data and generate a bitstream as in Fig. 15.

[0197] A decoding method / device according to embodiments (a receiving device (110) in FIG. 1, a receiving unit (111), a decapsulator (112), a decoder (113), a renderer (114), decoding in FIG. 11 and FIG. 12, a receiving unit, a demultiplexer, a renderer in FIG. 14, bitstream and syntax acquisition in FIG. 15 to 16, decapsulating, decoding, rendering in FIG. 17, file decapsulating in FIG. 18 to 34, a file receiver, a file parser, a bitstream packager, a decoder in FIG. 27, a decoding method in FIG. 26, etc.) receives a bitstream as in FIG. 15 and can decode mesh data based on parameter information included in the bitstream.

[0198] Referring to FIG. 15(a), the bitstream may include a sequence header, an encoded base mesh, encoded displacement (displacement), encoded attributes (textures or attributes), etc. The sequence header may include decoder configuration information. The encoded base mesh includes an input mesh file. The encoded displacement may be data that is packed into a 2D image and encoded using a video codec method, wherein the displacement information, which is the difference between vertices between a fitted and subdivided base mesh and a restored submesh, is data that is encoded using a video codec such as HEVC. The encoded attributes may be data that is encoded using a video codec such as HEVC, wherein attributes (e.g., colors) generated by matching the attribute (texture (2D)) coordinates of the restored base mesh using an input attribute map (e.g., PNG image).

[0199] In other words, FIG. 15(a) may be an example of a bitstream format resulting from video-based dynamic mesh encoding. The bitstream may include a sequence header, compressed basemesh data, compressed displacement data, and compressed texture data.

[0200] Basemesh data can be compressed using an Edgebreaker or Draco tool.

[0201] Displacement data can be compressed using video codecs such as HEVC, VVC, or arithmetic coding.

[0202] Texture / Attribute data can be compressed with video codecs such as HEVC, VVC, etc.

[0203] Referring to FIG. 15(b), as a result of video-based dynamic mesh encoding, the bitstream according to the embodiments may be composed of sample stream units. For example, the bitstream may include a sample stream DMC header and at least one sample stream DMC unit. The sample stream DMC unit may include parameter information, mesh data, etc.

[0204] VPS (V-DMC Parameter Set): May include decoder configuration information and / or parameter set information related to mesh encoding / decoding. AD (Atlas Data): May include information related to 2D mapping or texture mapping for 3D objects. BMD (Base Mesh Data): Encoded base mesh information for mesh encoding / decoding. DD (Displacements Data): Displacement information encoded using arithmetic coding. GVD (Geometry Video Data): Displacement information encoded by a video codec. Displacement information may be referred to as geometry information, etc. AVD (Attribute Video Data): Attribute or texture information encoded by a video codec.

[0205] FIG. 16 shows a V3C unit according to embodiments.

[0206] Specifically, FIG. 16 shows the header syntax of a V3C unit, which is a sample stream DMC unit (which may be referred to as a sample stream unit or a V3C unit) included in the bitstream of FIG. 15. The V3C unit (v3c_unit(numBytesInV3CUnit)), which is a data unit of the bitstream, includes a header (Fig. 16, v3c_unit_header( )) and a payload (v3c_unit_payload( numBytesInV3CUnit - 4)).

[0207] The unit type (vuh_unit_type) of the unit header can represent unit types such as VPS, AD, OVD, GVD, AVD, PVD, PVD, CAD, etc. using values ​​from 0 to 6 as follows.

[0208] vuh_unit_typeIdentifierV3C unit typeDescription0V3C_VPSV3C parameter setV3C level parameters1V3C_ADAtlas dataAtlas information2V3C_OVDOccupancy video dataOccupancy information3V3C_GVDGeometry video dataGeometry information4V3C_AVDAttribute video dataAttribute information5V3C_PVDPacked video dataPacking information6V3C_CADCommon atlas dataInformation that is common for atlases in a CVS. Specified in ISO / IEC 23090-127...31V3C_RSVDReserved-

[0209] vuh_unit_type: As shown above, indicates the specified V3C unit type. Values ​​marked as Reserved are reserved by ISO / IEC for future use.

[0210] vuh_v3c_parameter_set_id: Represents the value of vps_v3c_parameter_set_id for the active V3C VPS. The value of vuh_v3c_parameter_set_id is in the range of 0 to 15.

[0211] vuh_atlas_id: Represents the ID of the atlas corresponding to the current V3C unit. The value of vuh_atlas_id is in the range of 0 to 63.

[0212] vuh_attribute_index: Represents the index of the attribute data included in the attribute video data unit. The value of vuh_attribute_index is in the range of 0 to (ai_attribute_count[vuh_atlas_id] - 1).

[0213] vuh_attribute_partition_index: Represents the index of the attribute dimension group included in the attribute video data unit. The value of vuh_attribute_partition_index is in the range of 0 to ai_attribute_dimension_partitions_minus1[vuh_atlas_id][vuh_attribute_index].

[0214] vuh_map_index: Represents the map index of the current geometry or attribute stream. If this value is missing, the map index of the current geometry or attribute sub-bitstream is derived based on the type of the sub-bitstream and specific operations performed on the geometry and attribute video sub-bitstreams. If present, the value of vuh_map_index is in the range of 0 to vps_map_count_minus1[vuh_atlas_id].

[0215] vuh_auxiliary_video_flag: If 1, it indicates that the associated geometry or attribute video data unit is a sub-bitstream dedicated to point video coded in RAW and / or EOM. If vuh_auxiliary_video_flag is 0, it indicates that the associated geometry or attribute video data unit may contain points coded in RAW and / or EOM. If vuh_auxiliary_video_flag is missing, its value is inferred to be 0.

[0216] vuh_reserved_zero_12bits: equal to 0 in bitstreams following this version of this document.

[0217] vuh_reserved_zero_17bits: equal to 0 in bitstreams following this version of this document.

[0218] vuh_reserved_zero_23bits: equal to 0 in bitstreams following this version of this document.

[0219] vuh_reserved_zero_27bits: equal to 0 in bitstreams following this version of this document.

[0220] The syntax of the sample stream DMC header and sample stream DMC unit of the bitstream according to the embodiments can be defined as follows.

[0221] Syntax of the sample stream DMC header:

[0222] sample_stream_dmc_header() {Descriptorsdmh_unit_size_precision_bytes_minus1u(3)sdmh_reserved_zero_5bitsu(5)}

[0223] sdmh_unit_size_precision_bytes_minus1: Adding 1 to this value indicates the precision (bytes) of the sdmu_dmc_unit_size element in all sample stream DMC units. sdmh_unit_size_precision_bytes_minus1 is in the range of 0 to 7. The syntax for sample stream DMC units is as follows. Each sample stream DMC unit contains one type of DMC unit among VPS, AD, BMD, DD, GVD, and AVD. The contents of each sample stream DMC unit are associated with the same access unit as the DMC unit contained within the sample stream DMC unit.

[0224] sample_stream_dmc_unit() {Descriptorsdmu_dmc_unit_sizeu(v)dmc_unit(sdmu_dmc_unit_size )}

[0225] sdmu_dmc_unit_size: Indicates the size (in bytes) of the subsequent dmc_unit. The number of bits used to represent sdmu_dmc_unit_size is equal to (sdmh_unit_size_precision_bytes_minus1 + 1) * 8. A dmc_unit may consist of a unit header and a unit payload. Type information for the unit payload may be inserted in the unit header, and data of that type may be inserted in the unit payload. The dmc_unit data syntax and semantics may be in the format of v3c_unit used in ISO / IEC 23090-5, i.e., the V3C codec specification, which is referenced in the V-DMC standard, but may not be limited to such format. The contents according to the embodiments may be implemented specifically and independently of the V-DMC or V3C codec. The bitstream according to the embodiments may consist of a sample stream Network Abstraction Layer (NAL) unit. The sample stream NAL unit may include a sample stream NAL header and a sample stream NAL unit.

[0226] Sample stream NAL header syntax:

[0227] sample_stream_nal_header() {Descriptorssnh_unit_size_precision_bytes_minus1u(3)ssnh_reserved_zero_5bitsu(5)}

[0228] Sample Stream NAL Header Unit Syntax:

[0229] sample_stream_nal_unit() {Descriptorssnu_nal_unit_sizeu(v)nal_unit (ssnu_nal_unit_size)}

[0230] Semantics of Sample Stream NAL Headers: Sample Stream NAL headers are always at the beginning of the NAL stream. ssnh_unit_size_precision_bytes_minus1: Adding 1 to this value indicates the precision (bytes) of the ssnu_nal_unit_size element in every sample stream NAL unit. ssnh_unit_size_precision_bytes_minus1 is in the range of 0 to 7.

[0231] ssnh_reserved_zero_5bits: is equal to 0 in a bitstream following this version of this document.

[0232] Sample Stream NAL Unit Semantics:

[0233] The order of sample stream NAL units in a sample stream follows the decoding order of the NAL units included in the sample stream NAL units.

[0234] The unit (nal_unit) included in the bitstream according to the embodiments may be basemesh data that can be included in a sample of the basemesh track described below. That is, the unit of the bitstream may be a basemesh NAL unit (bmesh_nal_unit) or / or displacement data encoded by arithmetic coding (displ_nal_unit).

[0235] Additionally, nal_unit may be submesh data that can be included in the samples of the submesh track described later. The submesh data may be defined in the form of bmesh_nal_unit.

[0236] ssnu_nal_unit_size represents the size (bytes) of the subsequent NAL_unit. The number of bits used to represent ssnu_nal_unit_size is equal to (ssnh_unit_size_precision_bytes_minus1 + 1) * 8.

[0237] The bitstream can include a basemesh sub-bitstream.

[0238] The NAL sample stream format can construct the NAL unit stream format by arranging NAL units in decoding order and prefixing each NAL unit with a heading indicating the exact size (in bytes) of the NAL unit. The sample stream header is included at the beginning of the sample stream bitstream, indicating the precision (in bytes) of the signaled NAL unit size. The NAL unit stream format can be extracted from the sample stream format by traversing the sample stream format, reading the size information, and appropriately extracting each NAL unit.

[0239] General NAL Unit Syntax:

[0240] bmesh_nal_unit( NumBytesInNalUnit ) {Descriptorbmesh_nal_unit_header( )NumBytesInRbsp = 0for( i = 2; i < NumBytesInNalUnit; i++ )rbsp_byte[ NumBytesInRbsp++ ]b(8)}

[0241] NAL Unit Header Syntax:

[0242] bmesh_nal_unit_header() {Descriptorbmesh_nal_forbidden_zero_bitf(1)bmesh_nal_unit_typeu(6)bmesh_nal_layer_idu(6)bmesh_nal_temporal_id_plus1u(3)}

[0243] Raw byte sequence payload, trailing bit, and byte alignment syntax BaseMesh sequence parameter set RBSP syntax General BaseMesh sequence parameter set RBSP syntax

[0244] bmesh_sequence_parameter_set_rbsp( ) {Descriptorbmsps_sequence_parameter_set_idu(4)bmesh_profile_tier_level( )bmsps_intra_mesh_codec_idu(8)bmsps_inter_mesh_codec_idu(8)bmsps_inter_mesh_motion_group_size_minus1u(8)bmsps_inter_mesh_max_num_neighbours_minus1u(8)bmsps_geometry_3d_bit_depth_minus1u(5)bmsps_facegroup_segmentation_methodue(v)bmsps_mesh_attribute_countu(7)for( i = 0; i < bmsps_mesh_attribute_count; i++ ) {bmsps_mesh_attribute_type_id[ i ]u(4)bmsps_attribute_bit_depth_minus1[ i ]u(5)bmsps_attribute_msb_align_flag[ i ]u(1)}bmsps_log2_max_mesh_frame_order_cnt_lsb_minus4ue(v)bmsps_max_dec_mesh_frame_buffering_minus1ue(v)bmsps_long_term_ref_mesh_frames_flagu(1)bmsps_num_ref_mesh_frame_lists_in_bmspsue(v)for( i = 0; i < bmsps_num_ref_mesh_frame_lists_in_bmsps; i++ )bmesh_ref_list_struct( i )bmsps_extension_present_flagu(1)if( bmsps_extension_present_flag ) {bmsps_extension_countu(8)}if( bmsps_extension_count ){bmsps_extensions_length_minus1ue(v)for( i = 0; i < bmsps_extension_count;i++ ) {bmsps_extension_type[ i ]u(8)bmsps_extension_length[ i ]u(16)bmsps_extension( bmsps_extension_type[ i ], bmsps_extension_length[ i ] )}}rbsp_trailing_bits( )};

[0245] 베이스메쉬 SPS 확장 신택스:

[0246] bmsps_extension( extension_type, extension_length ) {Descriptorfor( j = 0; j < extension_length; j++ )bmsps_extension_data_byteu(8)length_alignment( )}

[0247] 베이스메쉬 프로파일, 티어 및 레벨 신택스:

[0248] bmesh_profile_tier_level( ) {Descriptorbmptl_tier_flagu(1)bmptl_profile_codec_group_idcu(7)bmptl_reserved_zero_32bitsu(32)bmptl_level_idcu(8)bmptl_num_sub_profilesu(6)bmptl_extended_sub_profile_flagu(1)for( i = 0; I < bmptl_num_sub_profiles; i++ ) {bmptl_sub_profile_idc[ i ]u(v)}bmptl_toolset_constraints_present_flagu(1)if( bmptl_toolset_constraints_present_flag ) {bmesh_profile_toolset_constraints_information( )}}

[0249] 프로파일 툴셋 제약 정보(Profile toolset constraints information) 신택스:

[0250] bmesh_profile_toolset_constraints_information( ) {Descriptorbmptc_one_mesh_frame_only_flagu(1)bmptc_intra_frames_only_flagu(1)bmptc_reserved_zero_6bitsu(6)bmptc_num_reserved_constraint_bytesu(8)for( i = 0; i < bmptc_num_reserved_constraint_bytes; i++ )bmptc_reserved_constraint_byte[ i ]u(8)}

[0251] 베이스메쉬 프레임 파라미터 세트 RBSP 신택스:제너럴 베이스메쉬 프레임 파라미터 RBSP 신택스:

[0252] bmesh_frame_parameter_set_rbsp( ) {Descriptorbfps_mesh_sequence_parameter_set_idu(4)bfps_mesh_frame_parameter_set_idu(4)bmesh_sub_mesh_information( ) bfps_output_flag_present_flagu(1)bfps_num_ref_idx_default_active_minus1ue(v)bfps_additional_lt_mfoc_lsb_lenue(v)bfps_extension_present_flagu(1)if( bfps_extension_present_flag )bfps_extension_8bitsu(8)if( bfps_extension_8bits )while( more_rbsp_data( ) )bfps_extension_data_flagu(1)rbsp_trailing_bits( )}

[0253] 베이스메쉬 서브메쉬 정보:

[0254] bmesh_sub_mesh_information( ) {Descriptorbmsi_use_single_mesh_flagu(1)if(!bmsi_use_single_mesh_flag){bmsi_num_submeshes_minus1u(8)}elsebmsi_num_submeshes_minus1 = 0bmsi_signalled_submesh_id_flagu(1)if( bmsi_signalled_submesh_id_flag ) {bmsi_signalled_submesh_id_length_minus1ue(v)for( i = 0; < bmsi_num_submeshes_minus1 + 1; i++ )bmsi_submesh_id[ i ]u(v)SubMeshIDToIndex[ bmsi_submesh_id[ i ] ] = iSubMeshIndexToID[ i ] = bmsi_submesh_id[ i ]}}elsefor( i = 0; i < bmsi_num_submeshes_minus1 + 1; i++ ) { bmsi_submesh_id[ i ] = iSubMeshIDToIndex[ i ] = iSubMeshIndexToID[ i ] = i}}

[0255] Basemesh submesh layer RBSP 신태스

[0256] bmesh_submesh_layer_rbsp( ) {Descriptorsubmesh_header( )submesh_data_unit( mfh_submesh_type, SubMeshUnitSize )rbsp_trailing_bits( )}

[0257] Basemesh Submesh Header Syntax:

[0258] submesh_header( ) {Descriptorif( nal_unit_type >= NAL_BLA_W_LP && nal_unit_type <= NAL_RSV_IRAP_ACL_29 )smh_no_output_of_prior_mesh_frames_flagu(1)smh_basemesh_frame_parameter_set_idu(4)smh_idu(v)subMeshID = smh_idsmh_typeue(v)if( bfps_output_flag_present_flag )smh_mesh_output_flagu(1)smh_mesh_frm_order_cnt_lsbu(v)if( bmsps_num_ref_mesh_frame_lists_in_bmsps > 0 )smh_ref_mesh_frame_list_msps_flagu(1)if( smh_ref_basemesh_frame_list_msps_flag == 0 )basemesh_ref_list_struct( bmsps_num_ref_mesh_frame_lists_in_bmsps )else if( bmsps_num_ref_mesh_frame_lists_in_bmsps > 1 )smh_ref_mesh_frame_list_idxu(v)for( j = 0; j < NumLtrMeshFrmEntries[ RlsIdx ];j++ ) {smh_additional_mfoc_lsb_present_flag[ j ]u(1)if( smh_additional_mfoc_lsb_present_flag[ j ] )smh_additional_mfoc_lsb_val[ j ]u(v)}if( smh_type != SKIP_SUBMESH ) { if( smh_type == P_SUBMESH && num_ref_entries[ RlsIdx ] > 1 ) {smh_num_ref_idx_active_override_flagu(1)if( smh_num_ref_idx_active_override_flag )smh_num_ref_idx_active_minus1ue(v)}}byte_alignment( )};

[0259] 레퍼런스 리스트 구조 신택스:

[0260] bmesh_ref_list_struct( rlsIdx ) {Descriptornum_ref_entries[ rlsIdx ]ue(v)for( i = 0; i < num_ref_entries[ rlsIdx ]; i++ ) {if( bmsps_long_term_ref_mesh_frames_flag )st_ref_mesh_frame_flag[ rlsIdx ][ i ]u(1)if( st_ref_mesh_frame_flag[ rlsIdx ][ i ] ) {abs_delta_mfoc_st[ rlsIdx ][ i ]ue(v)if( abs_delta_mfoc_st[ rlsIdx ][ i ] > 0 )straf_entry_sign_flag[ rlsIdx ][ i ]u(1)} elsemfoc_lsb_lt[ rlsIdx ][ i ]u(v)}}

[0261] 베이스메쉬 서브메쉬 데이터 유닛 신택스:

[0262] submesh_data_unit( subMeshID, unitSize ) {Descriptorif( smh_type == I_SUBMESH ) {sdu_intra_sub_mesh_unit( subMeshID, unitSize )}else if( smh_type == P_SUBMESH ) {sdu_inter_sub_mesh_unit( subMeshID )}else if( smh_type == SKIP_SUBMESH ) {sdu_skip_sub_mesh_unit( )}}

[0263] Basemesh Intra-Submesh Data Unit Syntax:

[0264] sdu_intra_sub_mesh_unit( subMeshID, vertexCount ) {Descriptorsismu_intra_unit( subMeshID )length_alignment( )}

[0265] sismu_intra_unit(subMeshID, sismu_intra_unit_size) contains a portion of mesh data of size sismu_intra_unit_size[subMeshID], which is an aligned string of bytes or bits capable of identifying the location of unit boundaries in the data pattern. The format of this mesh data is identified by bmptl_profile_codec_group_idc or component codec mapping SEI messages. Basemesh Inter-Submesh Data Unit Syntax:

[0266] sdu_inter_sub_mesh_unit( subMeshID, vertexCount ) {Descriptorsismu_inter_vertex_count[ subMeshID ]ue(v)sismu_inter_unit( subMeshID , sismu_inter_vertex_count[ subMeshID ] )length_alignment( )}

[0267] sismu_inter_unit(sismu_inter_unit_size, sismu_inter_vertex_count) contains a portion of motion data of size sismu_inter_unit_size, which is an ordered stream of bytes or bits capable of identifying the locations of unit boundaries within the data pattern. The format of this mesh data is identified by bmptl_profile_codec_group_idc or component codec mapping SEI messages. Basemesh inter-submesh data unit syntax:

[0268] sismu_inter_unit_default ( subMeshID, vertexCount ) {Descriptorif( vertexCount > 0 ) sismu_derived_mv_present_flag[ subMeshID ]ae(v)for( i = 0; i < vertexCount ; i++ ) {if(sismu_derived_mv_present_flag[ subMeshID ])sismu_mv_signalled_flag[ subMeshID ][ v ]ae(v)}groupSize = bmsps_inter_mesh_motion_group_size_minus1 + 1groupCount = ( vertexCount - 1) / groupSize + 1vStart = 0for( g = 0; g < groupCount: g++ ) {sismu_mv_pred_mode_group[ subMeshID ][ g ]ae(v)if ( g == (groupCount - 1) )groupSize = submeshMotionCount- groupSize *(groupCount - 1)for( v = vStart; v < (vStart+groupSize); v++ ) {if( sismu_mv_signalled_flag[ subMeshID ][ v ]) {for( k = 0; k < 3;k++ ) {sismu_mv_residual_abs_gt0[ subMeshID ][ v ][ k ]ae(v)if (sismu_mv_residual_abs_gt0[ subMeshID ][ v ][ k ]) {sismu_mv_residual_sign[ subMeshID ][ v ][ k ]ae(v)sismu_mv_residual_abs_gt1[ subMeshID ][ v ][ k ]ae(v)if (sismu_mv_residual_abs_gt1[ subMeshID ][ v ][ k ]) sismu_mv_residual_abs_rem[ subMeshID ][ v ][ k ]ae(v)}}}} / vvStart += groupSize}};

[0269] Basemesh Steep Submesh Data Unit Syntax:

[0270] sdu_skip_sub_mesh_unit( ) {Descriptor}

[0271] The semantics of the aforementioned syntax are explained below. BaseMesh NAL Unit Semantics: General NAL Unit Semantics: NumBytesInNalUnit represents the size of a NAL unit in bytes. This value is required to decode the NAL unit. To enable the inference of NumBytesInNalUnit, a form that distinguishes NAL unit boundaries is required.

[0272] rbsp_byte[ i ] is the i-th byte of the RBSP. An RBSP is specified as an aligned sequence of bytes as follows.

[0273] RBSP contains a data bit (SODB) string as follows.

[0274] - If SODB is empty (i.e., its length is 0 bits), RBSP is also empty.

[0275] - Otherwise, RBSP includes SODB as follows.

[0276] 1) The first byte of RBSP contains the first (most significant, leftmost) 8 bits of SODB. The next byte of RBSP contains the next 8 bits of SODB, and so on, until less than 8 bits of SODB remain.

[0277] 2) The syntax structure of rbsp_trailing_bits() is as follows after SODB.

[0278] i) The first (most significant, leftmost) bit of the last RBSP byte contains the remaining bits of SODB (if any).

[0279] ii) The next bit consists of a single bit equal to 1 (i.e., rbsp_stop_one_bit).

[0280] iii) If rbsp_stop_one_bit is not the last bit of a byte-aligned byte, there is one or more bits equal to 0 (i.e., instances of rbsp_alignment_zero_bit) to align the byte.

[0281] Syntax structures having these RBSP attributes are indicated in the syntax table using the "_rbsp" suffix. These structures are passed within the NAL unit as the contents of the rbsp_byte[ i ] data bytes.

[0282] NAL Unit Header Semantics:

[0283] As with atlases, similar NAL unit types are defined for the base mesh, enabling similar functions for random access and partitioning of the mesh. Unlike tiled atlases, the concept of sub-meshes is defined, and specific NAL units corresponding to coded mesh data are defined. Additionally, NAL units capable of containing metadata, such as SEI messages, are also defined.

[0284] The supported default mesh NAL unit types are as follows.

[0285] bmesh_nal_unit_typeName of bmesh_nal_unit_typeContent of base mesh NAL unit and RBSP syntax structureNAL unitype class01NAL_TRAIL_NNAL_TRAIL_RCoded sub-mesh of a non-TSA, non STSA trailing base mesh framesub_mesh_layer_rbsp( )BMCL23NAL_TSA_NNAL_TSA_RCoded sub-mesh of a TSA base mesh framesub_mesh_layer_rbsp( )BMCL45NAL_STSA_NNAL_STSA_RCoded sub-mesh of a STSA base mesh framesub_mesh_layer_rbsp( )BMCL67NAL_RADL_NNAL_RADL_RCoded sub-mesh of a RADL base mesh framesub_mesh_layer_rbsp( )BMCL89NAL_RASL_NNAL_RASL_RCoded sub-mesh of a RASL base mesh framesub_mesh_layer_rbsp( )BMCL1011NAL_SKIP_NNAL_SKIP_RCoded sub-mesh of a skipped base mesh framesub_mesh_layer_rbsp( )BMCL1214NAL_RSV_BMCL_N12NAL_RSV_BMCL_N14Reserved non-IRAP sub-layer non-reference BMCL mesh NAL unit typesBMCL1315NAL_RSV_BMCL_R13NAL_RSV_BMCL_R15Reserved non-IRAP sub-layer reference BMCL mesh NAL unit typesBMCL161718NAL_BLA_W_LPNAL_BLA_W_RADLNAL_BLA_N_LPCoded sub-mesh of a BLA base mesh framesub_mesh_layer_rbsp()BMCL1920NAL_IDR_W_RADLNAL_IDR_N_LPCoded sub-mesh of an IDR base mesh framesub_mesh_layer_rbsp( ) (BMCL)BMCL21NAL_CRACoded sub-mesh of a CRA base mesh framesub_mesh_layer_rbsp( )BMCL2223NAL_RSV_IRAP_BMCL_22NAL_RSV_IRAP_BMCL_23Reserved IRAP BMCL NAL unit typesBMCL24..29NAL_RSV_BMCL_24..NAL_RSV_BMCL_29Reserved non-IRAP BMCL NAL unit typesBMCL30NAL_BMSPSBase mesh sequence parameter setbmesh_sequence_parameter_set_rbsp( )non-BMCL31NAL_BMFPSBase mesh frame parameter setbmesh_frame_parameter_set_rbsp( )non-BMCL32NAL_AUDdelimiteraccess_unit_delimiter_rbsp( )non-BMCL33NAL_EOSEnd of sequenceend_of_sequence_rbsp( )non-BMCL34NAL_EOBEnd of bitstreamend_of_bmesh_sub_bitstream_rbsp( )non-BMCL35NAL_FDFillerfiller_data_rbsp( )non-BMCL3637NAL_PREFIX_NSEINAL_SUFFIX_NSEINon-essential supplemental enhancement informationsei_rbsp( )non-BMCL3839NAL_PREFIX_ESEINAL_SUFFIX_ESEIEssential supplemental enhancementinformationsei_rbsp( )non-BMCL40..4445..63NAL_RSV_NBMCL_40NAL_RSV_NBMCL_44NAL_UNSPEC_45NAL_UNSPEC_63Reserved non-BMCL NAL unit typesUnspecified non-BMCL NAL unit typesnon-BMCLnon-BMCL

[0286] Basemesh Raw byte sequence payloads, trailing bits, and byte alignment semantics: Basemesh sequence parameter set RBSP semantics: General Basemesh sequence parameter set RBSP semantics: bmsps_sequence_parameter_set_id: An identifier for a basemesh sequence parameter set that other syntax elements can reference.

[0287] bmsps_intra_mesh_codec_id: Represents the identifier of the codec used to compress the static mesh. The bmsps_intra_mesh_codec_id ranges from 0 to 255. This codec can be identified through profiles defined in ISO / IEC 23090-29, component codec mapping SEI messages, or means outside of this document. It may be associated with a specific mesh or motion mesh codec through profiles specified in the relevant specification, or explicitly indicated by SEI messages as is done in the V3C specification for video sub-bitstreams.

[0288] bmsps_inter_mesh_codec_id: Represents the identifier of the codec used to compress motion data. The bmsps_inter_mesh_codec_id ranges from 0 to 255. This codec can be identified through profiles defined in ISO / IEC 23090-29, component codec mapping SEI messages, or means outside of this document. It may be associated with a specific mesh or motion mesh codec through profiles specified in the relevant specification, or explicitly indicated by SEI messages as is done in the V3C specification for video subbitstreams.

[0289] bmsps_inter_mesh_motion_group_size_minus1: Adding 1 to this value indicates the size of the vertex grouping in motion vector coding. bmsps_inter_mesh_motion_group_size_minus1 is in the range of 0 to 255.

[0290] bmsps_inter_mesh_max_num_neighbours_minus1: Adding 1 to this value indicates the maximum number of vertex neighbors to use for motion vector predictor calculations. bmsps_inter_mesh_max_num_neighbours_minus1 is in the range of 0 to 255.

[0291] bmsps_geometry_3d_bit_depth_minus1: Adding 1 to this value indicates the bit depth of the geometry coordinates of the reconstructed mesh. bmsps_geometry_3d_bit_depth_minus1 is in the range of 0 to 31.

[0292] bmsps_facegroup_segmentation_method: Represents the identifier of the method for deriving face group IDs from the mesh.

[0293] bmsps_mesh_attribute_count: Indicates the number of attributes associated with the mesh. bmsps_mesh_attribute_count ranges from 0 to 127.

[0294] bmsps_mesh_attribute_type_id[ i ]: Represents the attribute type of the attribute with index i for the mesh. The relationship between the list of supported attributes and bmsps_mesh_attribute_type_id[ i ] is as follows.

[0295] bmsps_mesh_attribute_type_id[ i ]IdentifierAttribute type0ATTR_TEXTURETexture1ATTR_MATERIAL_IDMaterial ID2ATTR_TRANSPARENCYTransparency3ATTR_REFLECTANCEReflectance4ATTR_NORMALNormals5ATTR_FACEGROUP_IDFacegroup ID6..14ATTR_RESERVEDReserved15ATTR_UNSPECIFIEDUnspecified

[0296] bmsps_attribute_bit_depth_minus1[ i ]: Adding 1 to this value represents the bit depth of the attribute with index i for the mesh. bmsps_attribute_bit_depth_minus1[ i ] ranges from 0 to 31. bmsps_log2_max_mesh_frame_order_cnt_lsb_minus4: Adding 4 to this value represents the values ​​of the variables Log2MaxMeshFrmOrderCntLsb and MaxMeshFrmOrderCntLsb, which are used in the decoding process for the atlas frame order count, as follows: Log2MaxMeshFrmOrderCntLsb = bmsps_log2_max_mesh_frame_order_cnt_lsb_minus4 + 4

[0297] MaxMeshFrmOrderCntLsb = 2Log2MaxMeshFrmOrderCntLsb

[0298] The value of bmsps_log2_max_mesh_frame_order_cnt_lsb_minus4 is in the range of 0 to 12.

[0299] bmsps_max_dec_mesh_frame_buffering_minus1: Adding 1 to this value indicates the maximum size of the decoded atlas frame buffer required for CAS in atlas frame storage buffer units. The value of bmps_max_dec_mesh_frame_buffering_minus1 is in the range of 0 to 15.

[0300] bmsps_long_term_ref_mesh_frames_flag: If this value is 0, it indicates that long-term reference atlas frames are not used for inter-prediction of coded atlas frames in CAS. If bmsps_long_term_ref_mesh_frames_flag is 1, it indicates that long-term reference atlas frames can be used for inter-prediction of one or more coded atlas frames in CAS.

[0301] bmsps_num_ref_mesh_frame_lists_in_bmsps: Indicates the number of bmesh_ref_list_struct(rlsIdx) syntax structures included in the atlas sequence parameter set. The value of bmsps_num_ref_mesh_frame_lists_in_bmsps is in the range of 0 to 64.

[0302] Note: Since there may be only one bmesh_ref_list_struct(rlsIdx) syntax structure signaled directly from the atlas tile header of the current atlas tile, the decoder allocates memory for a total number of bmesh_ref_list_struct(rlsIdx) syntax structures, such as (bmsps_num_ref_mesh_frame_lists_in_bmsps + 1).

[0303] bmsps_extension_present_flag: If this value is 1, it indicates that bmsps_extension_count_minus1 is in the basemesh sequence parameter set.

[0304] bmsps_extension_count: Indicates the number of BMSPS extensions in the v3c_parameter_set() syntax structure. If none exist, bmsps_extension_count is inferred to be equal to 0. If bmsps_extension_count is equal to 0, BmspsExtensionsLength, which specifies the cumulative length in bytes of all extensions following this syntax element, is equal to 0.

[0305] If bmsps_extensions_length_minus1 is present, it represents the cumulative length in bytes of all extensions following this syntax element. This is BmspsExtensionsLength. BmspsExtensionsLength is calculated as follows.

[0306] if( bmsps_extension_count == 0 )

[0307] BmspsExtensionsLength = 0

[0308] else

[0309] BmspsExtensionsLength = bmsps_extensions_length_minus1 + 1

[0310] If bmsps_extension_count is not 0, BmspsExtensionsLength is equal to 3 * bmsps_extension_count and the sum of all bmsps_extension_length[ i ].

[0311] bmsps_extension_type[ i ]: Represents the BMSPS extension type for the extension with index i as specified in ISO / IEC 23090-29.

[0312] bmsps_extension_length[ i ]: Represents the number of bytes used to indicate the payload size of the syntactic structure of the associated extension at index i. If bmsps_extension_length[ i ] is 0, there is no extension payload for the extension at index i. Otherwise, the extension at index i has a payload size in bits ranging from 8 * ( bmsps_extension_length[ i ] - 1 ) + 1 to 8 * bmsps_extension_length[ i ] (inclusive).

[0313] Basemesh SPS Extension Semantics:

[0314] bmsps_extension_data_byte can have any value.

[0315] Basemesh Profile, Hierarchy and Level Semantics:

[0316] bmptl_tier_flag represents a hierarchy context for resolving bmptl_level_idc as specified in ISO / IEC 23090-29.

[0317] bmptl_profile_codec_group_idc: Represents the codec group profile component compliant with CVS as specified in ISO / IEC 23090-29.

[0318] bmptl_profile_toolset_idc: Represents the toolset combination profile components compliant with CVS as specified in ISO / IEC 23090-29.

[0319] bmptl_profile_reconstruction_idc: Represents the reconstruction profile components recommended for CVS compliance as specified in ISO / IEC 23090-29.

[0320] bmptl_reserved_zero_16bits: equal to 0 in a bitstream.

[0321] bmptl_reserved_0xffff_16bits: Equivalent to 0xFFFF in bitstream.

[0322] bmptl_level_idc: Indicates the level of compliance by CVS as specified in ISO / IEC 23090-29.

[0323] bmptl_num_sub_profiles represents the number of bmptl_sub_profile_idc[ i ] syntax elements.

[0324] bmptl_extended_sub_profile_flag: If this value is 1, it indicates that 64 bits should be used to represent the bmptl_sub_profile_idc[ i ] syntax elements. If bmptl_extended_sub_profile_flag is 0, it indicates that 32 bits should be used to represent the bmptl_sub_profile_idc[ i ] syntax elements.

[0325] bmptl_sub_profile_idc[ i ]: Rec. Represents the i-th interoperability metadata registered as specified in ITU-T T.35, which is not specified in this document. The number of bits used to represent bmptl_sub_profile_idc[ i ] is equal to (bmptl_extended_sub_profile_flag == 0 ? 32 : 64).

[0326] If bmptl_toolset_constraints_present_flag is 1, it indicates that the additional structure profile_toolset_constraints_information() is present in the bitstream. If bmptl_toolset_constraints_present_flag is 0, it indicates that the structure profile_toolset_constraints_information() is not present.

[0327] Basemesh Profile Toolset Constraint Information Semantics:

[0328] If bmptc_one_mesh_frame_only_flag is present, it has the meaning specified in ISO / IEC 23090-29, and the profile represented by bmptl_profile_toolset_idc is the profile specified in ISO / IEC 23090-29. If absent, ptc_one_mesh_frame_only_flag is inferred to be the same as 0.

[0329] If bmptc_intra_frames_only_flag is 1, it indicates that the bitstream contains only sdu_intra_sub_mesh_unit(). If absent, bmptc_intra_frames_only_flag is inferred to be the same as 0.

[0330] bmptc_reserved_zero_6bits is equivalent to 0 in a bitstream following this version of this document.

[0331] bmptc_num_reserved_constraint_bytes indicates the number of reserved constraint bytes.

[0332] bmptc_reserved_constraint_byte[ i ] can have any value. Its existence and value do not affect the decoder's suitability for the profile specified in this version of this document. Decoders following this version of this document ignore the values ​​of all bmptc_reserved_constraint_byte[ i ] syntax elements.

[0333] Basemesh Frame Parameter Set RBSP Semantics:

[0334] General Basemesh Frame Parameter Set RBSP Semantics:

[0335] bfps_mesh_sequence_parameter_set_id: Represents the value of bmsps_sequence_parameter_set_id for the active Basemesh sequence parameter set.

[0336] bfps_mesh_parameter_set_id identifies the basemesh frame parameter set so that other syntax elements can reference it.

[0337] If bfps_output_flag_present_flag is 1, it indicates that the smh_output_flag syntax element is present in the associated submesh header. If bfps_output_flag_present_flag is 0, it indicates that the smh_output_flag syntax element is not present in the associated submesh header.

[0338] bfps_num_ref_idx_default_active_minus1 plus 1 represents the inferred value of the variable NumRefIdxActive for tiles where smh_num_ref_idx_active_override_flag is 0. The value of bfps_num_ref_idx_default_active_minus1 is in the range of 0 to 14.

[0339] bfps_additional_lt_mfoc_lsb_len represents the value of the variable MaxLtMeshFrmOrderCntLsb, which is used in the decoding process of the reference atlas frame list, as follows.

[0340] MaxLtMeshFrmOrderCntLsb =

[0341] 2 * (Log2MaxMeshFrmOrderCntLsb + bfps_additional_lt_mfoc_lsb_len)

[0342] The value of bfps_additional_lt_mfoc_lsb_len is in the range of 0 to 32 - Log2MaxAtlasFrmOrderCntLsb.

[0343] If bmsps_long_term_ref_mesh_frames_flag is 0, the value of bfps_additional_lt_mfoc_lsb_len is equal to 0.

[0344] If bfps_extension_present_flag is 1, it indicates that the syntax element bfps_extension_8bits is present in the basemesh frame parameter set. If bfps_extension_present_flag is 0, it indicates that the syntax element bfps_extension_8bits is not present.

[0345] If bfps_extension_8bits is 0, it indicates that the bfps_extension_data_flag syntax element is missing from the AFPS RBSP syntax structure. If the value of bfps_extension_8bits is not 0, it is reserved for future use by ISO / IEC.

[0346] bfps_extension_data_flag can have any value.

[0347] Basemesh Submesh Information:

[0348] If bmsi_use_single_mesh_flag is 1, it indicates that there is only one submesh referencing the BFPS in each mesh frame. If bmsi_use_single_mesh_flag is 0, it indicates that there may be two or more submesh referencing the BFPS in each mesh frame.

[0349] bmsi_num_submeshes_minus1 plus 1 indicates the number of submeshes referencing BFPS in each mesh frame. The value of bmsi_num_submeshes_minus1 is in the range of 0 to 63. If it does not exist and bmsi_use_single_mesh_flag is 1, the value is inferred to be 1.

[0350] If bmsi_signalled_submesh_id_flag is 1, it indicates that the submesh ID of each mesh frame is signaled. If bmsi_signalled_tile_id_flag is 0, it indicates that the submesh ID is not signaled.

[0351] bmsi_signalled_submesh_id_length_minus1 plus 1 represents the number of bits used to indicate the syntax element bmsi_tile_id[ i ] if present, and the syntax element submesh_id of the submesh header. The value of bmsi_signalled_tile_id_length_minus1 is in the range of 0 to 15. If absent, the value is inferred to be equal to Ceil(Log2(bmsi_num_submeshes_minus1 + 1 )) - 1.

[0352] bmsi_submesh_id[ i ] represents the tile ID of the i-th submesh. The length of the bmsi_submesh_id[ i ] syntax element is bmsi_signalled_submesh_id_length_minus1 + 1 bit. If it does not exist, the value of bmsi_submesh_id[ i ] is inferred to be equal to i for each i in the range from 0 to bmsi_num_submeshes_minus1. It is a bitstream conformance requirement that bmsi_submesh_id[ i ] must not be equal to bmsi_submesh_id[ j ] for all i != j. The length of the bmsi_submesh_id[ i ] syntax element is bmsi_signalled_submesh_id_length_minus1 + 1 bit.

[0353] The variable FirstSubmeshID is calculated as follows.

[0354] FirstSubmeshID=bmsi_submesh_id

[0000]

[0355] for ( i = 1; i < bmsi_num_submeshes_minus1+ 1; i++ )

[0356] FirstSubmeshID = Min(FirstSubmeshID, bmsi_submesh_id[ i ])

[0357] Basemesh Submesh Header Semantics:

[0358] If present, the values ​​of the atlas tile header syntax elements smh_basemesh_frame_parameter_set_id, smh_mesh_output_flag, smh_no_output_of_prior_mesh_frames_flag, and smh_mesh_frm_order_cnt_lsb are the same across all submesh headers of the coded mesh frames.

[0359] smh_no_output_of_prior_mesh_frames_flag affects the output of previously decoded mesh frames in DAB after decoding the atlas in the CAS AU rather than the first AU of the bitstream. If smh_no_output_of_prior_mesh_frames_flag is not present, its value is inferred to be 0.

[0360] As a requirement for bitstream conformance, the value of smh_no_output_of_prior_mesh_frames_flag is the same for all mesh frames in the AU.

[0361] The smh_no_output_of_prior_mesh_frames_flag value of the submesh header is the output_of_prior_mesh_frames_flag value of the AU.

[0362] smh_basemesh_frame_parameter_set_id represents the value of bfps_basemesh_frame_parameter_set_id for the active basemesh frame parameter set for the current submesh.

[0363] smh_id represents the submesh ID associated with the current submesh. If it does not exist, the value of smh_id is inferred to be 0.

[0364] The following applies.

[0365] - The length of smh_id is bmsi_signalled_submesh_id_length_minus1 + 1 bit.

[0366] - The value of smh_id must be within the range of values ​​specified in the SubMeshIndexToID[i] array, where i is in the range from 0 to bmsi_num_submeshes_minus1.

[0367] The following constraints apply to the requirements of bitstream conformity.

[0368] - The value of smh_id is not the same as the smh_id value of another coded atlas tile unit of the same coded atlas frame.

[0369] - The tiles in the atlas frame are sorted according to the increasing order of smh_id values.

[0370] smh_type indicates the coding type of the current submesh as follows. The value of smh_type is 0, 1, or 2 in bitstreams following this version of this document.

[0371] smh_typeName of smh_type0P_SUBMESH1I_SUBMESH2SKIP_SUBMESH3..RESERVED

[0372] smh_mesh_output_flag affects the decoded mesh output and removal process. If smh_mesh_output_flag is absent, it is inferred to be equal to 1. smh_mesh_frm_order_cnt_lsb indicates the number of mesh frame orders modulo MaxMeshFrmOrderCntLsb for the current submesh. The length of the smh_mesh_frm_order_cnt_lsb syntax element is equal to the number of bits in Log2MaxMeshFrmOrderCntLsb. The value of smh_mesh_frm_order_cnt_lsb ranges from 0 to MaxMeshFrmOrderCntLsb - 1. If smh_ref_mesh_frame_list_bmsps_flag is 1, it indicates that the reference bmesh frame list of the current submesh is derived based on one of the bmesh_ref_list_struct(rlsIdx) syntax structures of the active BMSPS. If smh_ref_mesh_frame_list_bmsps_flag is 0, it indicates that the reference bmesh frame list of the current submesh is derived based on the bmesh_ref_list_struct(rlsIdx) syntax structure directly contained in the submesh header of the current submesh. When bmsps_num_ref_mesh_frame_lists_in_bmsps is 0, the value of smh_ref_mesh_frame_list_bmsps_flag is inferred to be 0. smh_ref_mesh_frame_list_idx indicates the index of the bmesh_ref_list_struct(rlsIdx) syntax structure used to derive the reference mesh frame list of the current submesh from the list of bmesh_ref_list_struct(rlsIdx) syntax structures contained in the active ASPS. The syntax element smh_ref_mesh_frame_list_idx is represented by the Ceil(Log2(bmsps_num_ref_mesh_frame_lists_in_bmsps)) bit.If it does not exist, the value of smh_ref_mesh_frame_list_idx is inferred to be equal to 0. The value of smh_ref_mesh_frame_list_idx is in the range from 0 to bmsps_num_ref_mesh_frame_lists_in_bmsps - 1. If smh_ref_mesh_frame_list_bmsps_flag is 1 and bmsps_num_ref_mesh_frame_lists_in_bmsps is 1, the value of smh_ref_mesh_frame_list_idx is inferred to be equal to 0.

[0373] The variable RlsIdx of the current atlas tile is derived as follows.

[0374] RlsIdx = smh_ref_mesh_frame_list_bmsps_flag ?

[0375] smh_ref_mesh_frame_list_idx : bmsps_num_ref_mesh_frame_lists_in_bmsps

[0376] If smh_additional_mfoc_lsb_present_flag[ j ] is 1, it indicates that smh_additional_mfoc_lsb_val[ j ] exists in the current submesh. If smh_additional_mfoc_lsb_present_flag[ j ] is 0, it indicates that smh_additional_mfoc_lsb_val[ j ] does not exist.

[0377] smh_additional_mfoc_lsb_val[ j ] represents the value of FullMeshFrmOrderCntLsbLt[ RlsIdx ][ j ] for the current atlas tile as follows.

[0378] FullMeshFrmOrderCntLsbLt[RlsIdx][j] =

[0379] smh_additional_mfoc_lsb_val[ j ] * MaxMeshFrmOrderCntLsb+mfoc_lsb_lt[RlsIdx][j]

[0380] The syntax element smh_additional_mfoc_lsb_val[ j ] is represented by the bfps_additional_lt_mfoc_lsb_len bit. If it does not exist, the value of smh_additional_mfoc_lsb_val[ j ] is inferred to be equal to 0.

[0381] If smh_num_ref_idx_active_override_flag is 1, it indicates that the syntax element smh_num_ref_idx_active_minus1 exists for the current submesh. If smh_num_ref_idx_active_override_flag is 0, it indicates that the syntax element smh_num_ref_idx_active_minus1 does not exist. If smh_num_ref_idx_active_override_flag is not present, its value is inferred to be equal to 0.

[0382] smh_num_ref_idx_active_minus1 is used to derive the variable NumRefIdxActive for the current submesh. The value of smh_num_ref_idx_active_minus1 is in the range of 0 to 14.

[0383] If the current submesh is P_SUBMESH submesh and smh_num_ref_idx_active_override_flag is 1 and smh_num_ref_idx_active_minus1 is not present, smh_num_ref_idx_active_minus1 is inferred to be 0.

[0384] The variable NumRefIdxActive is derived as follows.

[0385] if( smh_type == P_SUBMESH || smh_type == SKIP_SUBMESH ) {

[0386] if( smh_num_ref_idx_active_override_flag == 1 )

[0387] NumRefIdxActive = smh_num_ref_idx_active_minus1 + 1

[0388] else {

[0389] if( num_ref_entries[ RlsIdx ] >= bfps_num_ref_idx_default_active_minus1 + 1 )

[0390] NumRefIdxActive = bfps_num_ref_idx_default_active_minus1 + 1

[0391] else

[0392] NumRefIdxActive = num_ref_entries[RlsIdx]

[0393] }

[0394] }

[0395] else

[0396] NumRefIdxActive = 0

[0397] The value obtained by subtracting 1 from NumRefIdxActive represents the maximum value of the atlas reference frame index that can be used to decode the current atlas tile.

[0398] Reference List Structure Semantics:

[0399] num_ref_entries[rlsIdx] represents the number of entries in the bmesh_ref_list_struct(rlsIdx) syntax structure, where rlsIdx is the index of the mesh frame reference list. For P_SUBMESH and SKIP_SUBMESH, the value of num_ref_entries[rlsIdx] is in the range of 1 to bmsps_max_dec_mesh_frame_buffering_minus1 + 1. Otherwise, the value of num_ref_entries[rlsIdx] is in the range of 0 to bmsps_max_dec_mesh_frame_buffering_minus1 + 1.

[0400] If st_ref_mesh_frame_flag[rlsIdx][i] is 1, it indicates that the i-th entry of the bmesh_ref_list_struct(rlsIdx) syntax structure is a short-reference mesh frame entry. If st_ref_mesh_frame_flag[rlsIdx][i] is 0, it indicates that the i-th entry of the ref_list_struct(rlsIdx) syntax structure is a long-reference mesh frame entry. If it does not exist, the value of st_ref_mesh_frame_flag[rlsIdx][i] is inferred to be equal to 1.

[0401] The variable NumLtrMeshFrmEntries[rlsIdx] is derived as follows.

[0402] NumLtrMeshFrmEntries[rlsIdx] = 0

[0403] for( i = 0; i < num_ref_entries[rlsIdx]; i++)

[0404] if(!st_ref_mesh_frame_flag[rlsIdx][i])

[0405] NumLtrMeshFrmEntries[rlsIdx]++

[0406] abs_delta_mfoc_st[rlsIdx][i] represents the absolute difference between meshes if the i-th item is the first short-referenced mesh frame item of the bmesh_ref_list_struct(rlsIdx) syntax structure. It represents the frame order count value of the mesh frame referenced by the current mesh tile and the i-th item, or if the i-th item is a short-referenced mesh frame item but not the first short-referenced mesh frame item of the bmesh_ref_list_struct(rlsIdx) syntax structure, it represents the absolute difference between the i-th item in the bmesh_ref_list_struct(rlsIdx) syntax structure and the mesh frame order count value of the mesh frame referenced by the previous short-referenced mesh frame item. The value of abs_delta_mfoc_st[rlsIdx][i] is in the range of 0 to 215 - 1.

[0407] If straf_entry_sign_flag[rlsIdx][i] is 1, it indicates that the i-th item of the syntax structure bmesh_ref_list_struct(rlsIdx) has a value greater than or equal to 0. If straf_entry_sign_flag[rlsIdx][i] is 0, it specifies that the i-th item of the syntax structure bmesh_ref_list_struct(rlsIdx) has a value less than 0. If absent, the value of straf_entry_sign_flag[rlsIdx][i] is inferred to be 1.

[0408] The list DeltaMfocSt[rlsIdx][i] is derived as follows.

[0409] for( i = 0; i < num_ref_entries[rlsIdx]; i++ )

[0410] if( st_ref_mesh_frame_flag[ rlsIdx ][ i ] )

[0411] DeltaMfocSt[ rlsIdx ][ i ] =

[0412] ( 2 * straf_entry_sign_flag[ rlsIdx ][ i ] - 1 ) * abs_delta_mfoc_st[ rlsIdx ][ i ]

[0413] else

[0414] DeltaMfocSt[rlsIdx][i] = 0

[0415] mfoc_lsb_lt[ rlsIdx ][ i ] represents the value of the mesh frame order count modulo MaxMeshFrmOrderCntLsb of the mesh frame referenced by the i-th item of the bmesh_ref_list_struct( rlsIdx ) syntax structure. The length of the mfoc_lsb_lt[ rlsIdx ][ i ] syntax element is Log2MaxMeshFrmOrderCntLsb bits.

[0416] Basemesh Submesh Data Unit Semantics:

[0417] Basemesh Inter-Submesh Data Unit Semantics:

[0418] sismu_derived_mv_present_flag[ subMeshID ] indicates that sismu_mv_signalled_flag exists in the bitstream. If sismu_derived_mv_present_flag[ subMeshID ] is 0, sismu_mv_signalled_flag[ subMeshID ][ v ] is always inferred as 1.

[0419] sismu_mv_signalled_flag[ subMeshID ][ v ] indicates that the motion vector of the vertex with index v exists in the bitstream. If sismu_mv_signalled_flag[ subMeshID ][ v ] is not in the bitstream, sismu_mv_signalled_flag[ subMeshID ][ v ] is inferred to be 1.

[0420] sismu_mv_pred_mode_group[ subMeshID ][ g ] indicates the method used to predict the motion vector associated with the vertex of the group containing the current submesh index g. The submesh ID is equal to subMeshID.

[0421] sismu_mv_residual_abs_gt0[ subMeshID ][ v ][ k ] indicates whether the k-th component of the motion vector prediction residual associated with the vertex at index v of the current submesh has an absolute value greater than 0 (if 1) or not (if 0).

[0422] sismu_mv_residual_sign[ subMeshID ][ v ][ k ] indicates whether the k-th component of the motion vector prediction residual associated with the vertex at index v of the current submesh has a positive sign (if 1) or not (if 0). If sismu_mv_residual_sign[ v ][ k ] is missing, it is inferred to be equal to 1.

[0423] sismu_mv_residual_abs_gt1[ subMeshID ][ v ][ k ] indicates whether the k-th component of the motion vector prediction residual associated with the vertex at index v of the current submesh has an absolute value greater than 1 (if 1) or not (if 0). If sismu_mv_residual_abs_gt1[ v ][ k ] is not present, it is inferred to be equal to 0.

[0424] sismu_mv_residual_abs_rem[ subMeshID ][ v ][ k ] represents the absolute value of the k-th component of the motion vector prediction residual associated with the vertex at index v of the current submesh, and the submesh ID is the value of subMeshID minus 2. If sismu_mv_residual_abs_rem[ v ][ k ] is not present, it is inferred to be equal to 0.

[0425] The k-th component of the motion vector prediction residual VertexMotionVectorResiduals[ v ][ k ] associated with the vertex at index v of the current submesh is calculated as follows.

[0426] VertexMotionVectorResiduals[ v ][ k ] = sismu_mv_residual_sign[ v ][ k ] ? 1:-1)*

[0427] (sismu_mv_ residual_sign_gt0[ v ][ k ] + sismu_mv_ residual_sign wk_gt1[ v ][ k ] +

[0428] sismu_mv_ residual_sign _rem[ v ][ k ])

[0429] Arthmetic Coded Displacement Sub-bitstream:

[0430] The NAL sample stream format can be constructed from the NAL unit stream format by arranging NAL units in decoding order and prefixing each NAL unit with a heading that specifies the exact size (in bytes) of the NAL unit. The sample stream header is included at the beginning of the sample stream bitstream, specifying the precision (in bytes) of the signaled NA unit size. The NAL unit stream format can be extracted from the sample stream format by traversing the sample stream format, reading the size information, and appropriately extracting each NAL unit.

[0431] Below, the syntax of an arismetic coded displacement sub-bitstream is described.

[0432] NAL Unit Syntax:

[0433] General NAL Unit Syntax:

[0434] displ_nal_unit( NumBytesInNalUnit ) {Descriptordispl_nal_unit_header( )NumBytesInRbsp = 0for( i = 2; i < NumBytesInNalUnit; i++ )rbsp_byte[ NumBytesInRbsp++ ]b(8)}

[0435] NAL Unit Header Syntax:

[0436] displ_nal_unit_header() {Descriptordispl_nal_forbidden_zero_bitf(1)displ_nal_unit_typeu(6)displ_nal_layer_idu(6)displ_nal_temporal_id_plus1u(3)}

[0437] Raw byte sequence payload, trailing bit, byte alignment syntax: Displacement sequence parameter set RBSP syntax: General displacement sequence parameter set RBSP syntax:

[0438] displ_sequence_parameter_set_rbsp( ) {Descriptordsps_sequence_parameter_set_idu(4)dsps_codec_idu(8)dsps_profile_tier_level( )dsps_range_log2_minus2u(3)dsps_single_dimension_flagu(1)dsps_msb_align_flagu(1)dsps_log2_max_displ_frame_order_cnt_lsb_minus4ue(v)dsps_max_dec_displ_frame_buffering_minus1ue(v)dsps_long_term_ref_displ_frames_flagu(1)dsps_num_ref_displ_frame_lists_in_dspsue(v)for( i = 0; i < dsps_num_ref_displ_frame_lists_in_dsps; i++ ) displ_ref_list_struct( i )dsps_extension_present_flagu(1)if( dsps_extension_present_flag ) {dsps_extension_count_minus1u(7)dsps_extension_length_minus1ue(v)while( more_rbsp_data( ) )dsps_extension_data_byte u(1)}rbsp_trailing_bits( )}

[0439] 디스플레이스먼트 프로파일, 티어, 및 레벨 신택스:

[0440] Dsps_profile_tier_level( ) {Descriptordptl_tier_flagu(1)dptl_profile_codec_group_idcu(7)dptl_profile_toolset_idcu(8)dptl_reserved_zero_32bitsu(32)dptl_level_idcu(8)dptl_num_sub_profilesu(6)dptl_extended_sub_profile_flagu(1)for( i = 0;

[0441] Profile toolset constraints information syntax:

[0442] dptl_profile_toolset_constraints_information( ) {Descriptordptc_one_displacement_frame_only_flagu(1)dptc_reserved_zero_7bitsu(6)dptc_num_reserved_constraint_bytesu(8)for( i = 0; i < dptc_num_reserved_constraint_bytes; i++ )dptc_reserved_constraint_byte[ i ]u(8)}

[0443] Displacement Frame Parameter Set RBSP Syntax: General Displacement Frame Parameter Set RBSP Syntax:

[0444] displ_frame_parameter_set_rbsp( ) {Descriptordfps_displ_sequence_parameter_set_idu(4)dfps_displ_frame_parameter_set_idu(4)displ_information( ) dfps_output_flag_present_flagu(1)dfps_num_ref_idx_default_active_minus1ue(v)dfps_additional_lt_dfoc_lsb_lenue(v)dfps_extension_present_flagu(1)if( dfps_extension_present_flag )dfps_extension_8bitsu(8)if( dfps_extension_8bits )while( more_rbsp_data( ) )dfps_extension_data_flagu(1)rbsp_trailing_bits( )}

[0445] 디스플레이스먼트 레퍼런스 리스트 구조 신택스:

[0446] displ_ref_list_struct( rlsIdx ) {Descriptordrl_num_ref_entries[ rlsIdx ]ue(v)for( i = 0; i < drl_num_ref_entries[ rlsIdx ]; i++ ) {if( dsps_long_term_ref_displ_frames_flag )drl_st_ref_displ_frame_flag[ rlsIdx ][ i ]u(1)if( drl_st_ref_displ_frame_flag[ rlsIdx ][ i ] ) {drl_abs_delta_dfoc_st[ rlsIdx ][ i ]ue(v)if( drl_abs_delta_dfoc_st[ rlsIdx ][ i ] > 0 )drl_straf_entry_sign_flag[ rlsIdx ][ i ]u(1)} elsedrl_dfoc_lsb_lt[ rlsIdx ][ i ]u(v)}}

[0447] Displacement Layer RBSP Syntax:

[0448] displ_layer_rbsp() {Descriptordispl_header()displ_data_unit(displID)rbsp_trailing_bits()}

[0449] Displacement header syntax:

[0450] displ_header( ) {Descriptorif( nal_unit_type >= NAL_BLA_W_LP && nal_unit_type <= NAL_RSV_IRAP_DCL_29 )dh_no_output_of_prior_displ_frames_flagu(1)dh_frame_parameter_set_idu(4)dh_idu(v)displID = dh_iddh_typeue(v)if( dfps_output_flag_present_flag )dh_output_flagu(1)dh_frm_order_cnt_lsbu(v)if( dsps_num_ref_displ_frame_lists_in_dsps > 0 )dh_ref_displ_frame_list_dsps_flagu(1)if( dh_ref_displ_frame_list_dsps_flag == 0 )displ_ref_list_struct( dsps_num_ref_displ_frame_lists_in_dsps )else if( dsps_num_ref_displ_frame_lists_in_dsps > 1 )ref_displ_frame_list_idxu(v)for( j = 0; j < NumLtrDisplFrmEntries[ RlsIdx ]; j++ ) {dh_additional_dfoc_lsb_present_flag[ j ]u(1)if( additional_dfoc_lsb_present_flag[ j ] )dh_additional_dfoc_lsb_val[ j ]u(v)}if( dh_type == P_DISPLACEMENT && num_ref_entries[ RlsIdx ] > 1 ) {dh_num_ref_idx_active_override_flagu(1)if( num_ref_idx_active_override_flag )dh_num_ref_idx_active_minus1ue(v)}dh_log2_subblock_size_minus6u(4)byte_alignment( )}

[0451] Displacement Data Unit Syntax:

[0452] displ_data_unit( displID ) {Descriptorif( dh_type == I_DISPLACEMENT ) {displ_intra_unit( displID )}else if( dh_type == P_DISPLACEMENT ) {displ_inter_unit( displID )}}

[0453] Displacement Intra Data Unit Syntax:

[0454] displ_intra_unit( displID ) {Descriptordiu_lod_count[ displID ]for( i = 0; i < displ_lod_count; i++ ) {diu_vertex_count_lod[ displID ][ i ]subblockSize = 1 << dh_log2_subblock_size_minus6for( k = 0; k < 3; k++ ) {diu_last_sig_coeff[ k ]ae(v)for( b = 0; b < lodCount; b++ ) {diu_coded_block_flag[ k ][ b ]u(v)if( diu_coded_block_flag[ k ][ b] ) {subblockCountPerLevel =Ceil( diu_vertex_count_lod[ displID ][ b ] / subblockSize )for( s = 0; s < subblockCountPerLevel; s++ ) {diu_coded_subblock_flag[ k ][ b ][ s ]u(v)if( diu_coded_subblock_flag[ k ][ b ][ s ] ) {for( v = vStart; v < subblock_size; v++ ) {diu_coeff_abs_level_gt0[ k ][ b ][ s ][ v ]u(v)if( diu_coeff_abs_level_gt0[ k ][ b ][ s ][ v ] ) {diu_coeff_abs_level_gt1[ k ][ b ][ s ][ v ]u(v)diu_coeff_sign[ k ][ b ][ s ][ v ]u(1)if( diu_coeff_abs_level_gt1[ k ][ b ][ s ][ v ] ) {diu_coeff_abs_level_rem[ k ][ b ][ s ][ v ]ue(v)}}}}}}}if ( dsps_single_dimension_flag ) {break;}}}

[0455] Displacement Inter-Data Unit Syntax: The arithmetic decoding engine is a context-isolated binary arithmetic decoder that performs binary renormalization and generates binary output. The displacement residual is derived from the arithmetic decoding.

[0456] displ_inter_unit( dispID ) {Descriptor / * Can be the same as specified in 4.3.1.3.7 * / }

[0457] The semantics of the Arthmetic Coded Displacement sub-bitstream are described below. NAL Unit Semantics: General NAL Unit Semantics: NumBytesInNalUnit represents the size of a NAL unit in bytes. This value is required to decode the NAL unit. Some form that distinguishes NAL unit boundaries is required to enable the inference of NumBytesInNalUnit.

[0458] Note: The Displacement Coding Layer (DCL) is specified to efficiently represent the contents of displacement data. The NAL is specified to format the data and provide header information in a manner suitable for transmission over various communication channels or storage media. All data is contained within NAL units, each containing an integer byte. NAL units represent a general format usable in both packet-oriented and bitstream systems. The format of NAL units is the same for both packet-oriented transmission and sample streams, but in the sample stream format, an additional element specifying the size of the NAL unit may precede each NAL unit.

[0459] rbsp_byte[ i ] is the i-th byte of the RBSP. An RBSP is specified as an aligned sequence of bytes as follows.

[0460] RBSP contains a data bit (SODB) string as follows.

[0461] - If SODB is empty (i.e., its length is 0 bits), RBSP is also empty.

[0462] - Otherwise, RBSP includes SODB as follows.

[0463] 3) The first byte of RBSP contains the first (most significant, leftmost) 8 bits of SODB. The next byte of RBSP contains the next 8 bits of SODB, and this continues until less than 8 bits of SODB remain.

[0464] 4) The syntax structure of rbsp_trailing_bits() exists after SODB as follows.

[0465] iv) The first (most significant, leftmost) bit of the last RBSP byte contains the remaining bits of SODB (if any).

[0466] v) The next bit consists of a single bit equal to 1 (i.e., rbsp_stop_one_bit).

[0467] vi) If rbsp_stop_one_bit is not the last bit of a byte-aligned byte, one or more bits equal to 0 (i.e., instances of rbsp_alignment_zero_bit) exist to align the byte.

[0468] Syntactic structures with these RBSP attributes are indicated in the syntax table using the "_rbsp" suffix. These structures are passed within the NAL unit as the contents of the rbsp_byte[ i ] data bytes. The association between RBSP syntax structures and NAL units is as shown in the table below.

[0469] Note: If the boundaries of the RBSP are known, the decoder can extract SODB from the RBSP by concatenating the byte bits of the RBSP, discarding rbsp_stop_one_bit where the last (least significant, rightmost) bit is 1, and discarding the subsequent (less significant, further rightmost) bit where the bit is 0. The data required for the decoding process is contained in the SODB portion of the RBSP.

[0470] NAL Unit Header Semantics:

[0471] displ_nal_forbidden_zero_bit

[0472] displ_nal_unit_type

[0473] Similar to the atlas case, a similar NAL unit type is defined for displacement, and a similar function for random access defines a specific NAL unit corresponding to the coded displacement data. Additionally, NAL units capable of containing metadata, such as SEI messages, are also defined.

[0474] In particular, the supported displacement NAL unit types are specified as follows.

[0475] NAL Unit Type Codec and NAL Unit Type Class:

[0476] displ_nal_unit_typeName of displ_nal_unit_typeContent of displacement NAL unit and RBSP syntax structureNAL unitype class01NAL_TRAIL_NNAL_TRAIL_RCoded displacement of a non-TSA, non STSA trailing displacement framedispl_layer_rbsp( )DCL23NAL_TSA_NNAL_TSA_RCoded displacement of a TSA displacement framedispl_layer_rbsp( )DCL45NAL_STSA_NNAL_STSA_RCoded displacement of a STSA displacement framedispl_layer_rbsp( )DCL67NAL_RADL_NNAL_RADL_RCoded displacement of a RADL displacement framedispl_layer_rbsp( )DCL89NAL_RASL_NNAL_RASL_RCoded displacement of a RASL displacement framedispl_layer_rbsp( )DCL1011NAL_SKIP_NNAL_SKIP_RCoded displacement of a skipped displacement framedispl_layer_rbsp( )DCL1214NAL_RSV_DCL_N12NAL_RSV_DCL_N14Reserved non-IRAP sub-layer non-reference DCL displacement NAL unit typesDCL1315NAL_RSV_DCL_R13NAL_RSV_DCL_R15Reserved non-IRAP sub-layer reference DCL displacement NAL unit typesDCL161718NAL_BLA_W_LPNAL_BLA_W_RADLNAL_BLA_N_LPCoded displacement of a BLA displacementframedispl_layer_rbsp( )DCL1920NAL_IDR_W_RADLNAL_IDR_N_LPCoded displacement of an IDR displacement framedispl_layer_rbsp( )DCL21NAL_CRACoded displacement of a CRA displacement framedispl_layer_rbsp( )DCL2223NAL_RSV_IRAP_DCL_22NAL_RSV_IRAP_DCL_23Reserved IRAP DCL NAL unit typesDCL24..29NAL_RSV_DCL_24..NAL_RSV_DCL_29Reserved non-IRAP DCL NAL unit typesDCL30NAL_DSPSDisplacement sequence parameter setdispl_sequence_parameter_set_rbsp( )non-DCL31NAL_DFPSDisplacement frame parameter setdispl_frame_parameter_set_rbsp( )non-DCL32NAL_DAUDAccess unit delimiteraccess_unit_delimiter_rbsp( )non-DCL33NAL_DEOSEnd of sequenceend_of_sequence_rbsp( )non-DCL34NAL_DEOBEnd of bitstreamend_of_displ_sub_bitstream_rbsp( )non-DCL35NAL_FDFillerfiller_data_rbsp( )non-DCL3637NAL_PREFIX_NSEINAL_SUFFIX_NSEINon-essential supplemental enhancement informationsei_rbsp( )non-DCL383940..4445..63NAL_PREFIX_ESEINAL_SUFFIX_ESEINAL_RSV_NDCL_40NAL_RSV_NDCL_44NAL_UNSPEC_45NAL_UNSPEC_63Essential supplemental enhancementinformationsei_rbsp( )Reserved non-DCL NAL unit typessnspecified non-DCL NAL unit typesnon-DCLnon-DCLnon-DCL

[0477] displ_nal_layer_id displ_nal_temporal_id_plus1 The order of NAL units and displacement frames, and the relationship with coded displacement frames, access units, and coded displacement sequences: Raw byte sequence payload, trailing bit, byte alignment semantics: Displacement sequence parameter set RBSP semantics:

[0478] General Displacement Sequence Parameter Set RBSP Semantics:

[0479] dsps_sequence_parameter_set_id: An identifier for the displacement sequence parameter set that other syntax elements can reference.

[0480] dsps_codec_id: This is the identifier of the codec used to compress the displacement. The dsps_codec_id ranges from 0 to 255. This codec can be identified through a profile defined in ISO / IEC 23090-29, a SEI message mapping component codec, or means outside of this document. It can be associated with a specific displacement codec through the profile specified in the relevant specification, or explicitly indicated as an SEI message as is done in the V3C specification for video sub-bitstreams.

[0481] dsps_range_log2_minus2: Adding 2 to this value represents the range of geometric displacement coordinates. dsps_range_log2_minus2 is in the range of 0 to 3.

[0482] dsps_single_dimension_flag: Indicates the number of dimensions associated with the displacement. If dsps_single_dimension_flag is 0, it indicates that three components are used for the displacement. If dsps_single_dimension_flag is 1, it indicates that only a general component is used for the displacement.

[0483] dsps_msb_align_flag: Indicates how decoded displacement samples are converted into samples of displacement range bit depth.

[0484] dsps_log2_max_displ_frame_order_cnt_lsb_minus4: Adding 4 to this value represents the values ​​of the variables Log2MaxDisplFrmOrderCntLsb and MaxDisplFrmOrderCntLsb used in the decoding process for the displacement frame order count as follows.

[0485] Log2MaxDisplFrmOrderCntLsb =

[0486] dsps_log2_max_displ_frame_order_cnt_lsb_minus4 + 4

[0487] MaxDisplFrmOrderCntLsb = 2Log2MaxDisplFrmOrderCntLsb

[0488] The value of dsps_log2_max_displ_frame_order_cnt_lsb_minus4 is in the range of 0 to 12.

[0489] dsps_max_dec_displ_frame_buffering_minus1 plus 1 represents the maximum required size of the decoded displacement frame buffer for the CDS in displacement frame storage buffer units. The value of dsps_max_dec_displ_frame_buffering_minus1 is in the range of 0 to 15.

[0490] If dsps_long_term_ref_displ_frames_flag is 0, it indicates that long-term reference displacements are not used for inter-predicting of all coded displacement frames in the CDS. If dsps_long_term_ref_displ_frames_flag is 1, it indicates that long-term reference displacement frames can be used for inter-predicting of one or more coded displacement frames in the CDS.

[0491] dsps_num_ref_displ_frame_lists_in_dsps indicates the number of displ_ref_list_struct(rlsIdx) syntax structures included in the set of displacement sequence parameters. The value of dsps_num_ref_displ_frame_lists_in_dsps is in the range of 0 to 64.

[0492] Note: Since there may be only one displ_ref_list_struct(rlsIdx) syntax structure that is signaled directly from the displacement header of the current displacement frame, the decoder allocates memory for a total number of displ_ref_list_struct(rlsIdx) syntax structures, such as (dsps_num_ref_displ_frame_lists_in_dsps + 1).

[0493] If dsps_extension_present_flag is 1, it indicates that dsps_extension_count_minus1 and dsps_extension_length_minus1 are in the set of displacement sequence parameters.

[0494] Adding 1 to dsps_extension_count_minus1 indicates the number of extensions in the current set of displacement sequence parameters. If none exist, dsps_extension_count_minus1 is inferred to be equal to -1.

[0495] dsps_extension_length_minus1 plus 1 indicates the length of the dsps_extension_data_byte element following this syntax element. If it does not exist, dsps_extension_length_minus1 is inferred to be equal to -1.

[0496] dsps_extension_data_byte can have any value.

[0497] Displacement Profile, Tier, and Level Semantics:

[0498] dptl_tier_flag represents the tier context for resolving dptl_level_idc as specified in ISO / IEC 23090-29.

[0499] dptl_profile_codec_group_idc represents the codec group profile components that CDS complies with as specified in ISO / IEC 23090-29.

[0500] dptl_profile_toolset_idc represents the toolset combination profile component that CDS complies with as specified in ISO / IEC 23090-29.

[0501] If dptl_reserved_zero_32bits is present, it is equal to 0 in bitstreams that comply with this version of this document.

[0502] dptl_level_idc indicates the level of compliance by CDS as specified in ISO / IEC 23090-29.

[0503] dptl_num_sub_profiles represents the number of dptl_sub_profile_idc[ i ] syntax elements.

[0504] If dptl_extended_sub_profile_flag is 1, it indicates that if dptl_sub_profile_idc[ i ] syntax elements exist, they should be represented using 64 bits. If dptl_extended_sub_profile_flag is 0, it indicates that if dptl_sub_profile_idc[ i ] syntax elements exist, they should be represented using 32 bits.

[0505] dptl_sub_profile_idc[ i ] represents the i-th interoperability metadata registered as specified in Rec. ITU-T T.35. The number of bits used to represent dptl_sub_profile_idc[ i ] is equal to (dptl_extended_sub_profile_flag == 0 ? 32 : 64).

[0506] If dptl_toolset_constraints_present_flag is 1, it indicates that the additional structure dptl_profile_toolset_constraints_information() is present in the bitstream. If dptl_toolset_constraints_present_flag is 0, it indicates that the structure dptl_profile_toolset_constraints_information() is not present.

[0507] Displacement Profile Toolset Constraint Information Semantics:

[0508] If dptc_one_displacement_frame_only_flag is present, it has the meaning specified in ISO / IEC 23090-29. Here, the profile represented by dptl_profile_toolset_idc is the profile specified in ISO / IEC 23090-29. If absent, dptc_one_displacement_frame_only_flag is inferred to be equal to 0.

[0509] dptc_reserved_zero_7bits is equal to 0 in a bitstream that follows this version of this document.

[0510] dptc_num_reserved_constraint_bytes represents the number of reserved constraint bytes.

[0511] dptc_reserved_constraint_byte[ i ] can have any value.

[0512] Displacement Frame Parameter Set RBSP Semantics

[0513] General Displacement Frame Parameter Set RBSP Semantics

[0514] dfps_displ_sequence_parameter_set_id specifies the value of dsps_sequence_parameter_set_id for the active displacement sequence parameter set.

[0515] dfps_displ_parameter_set_id identifies a set of displacement frame parameters so that other syntax elements can reference it.

[0516] If dfps_output_flag_present_flag is 1, it indicates that the displ_output_flag syntax element is present in the associated displacement header. If dfps_output_flag_present_flag is 0, it indicates that the displ_output_flag syntax element is not present in the associated displacement header.

[0517] dfps_num_ref_idx_default_active_minus1: Adding 1 to this value represents the inferred value of the variable NumRefIdxActive for tiles where displ_num_ref_idx_active_override_flag is 0. The value of dfps_num_ref_idx_default_active_minus1 is in the range of 0 to 14.

[0518] dfps_additional_lt_dfoc_lsb_len represents the value of the variable MaxLtDisplFrmOrderCntLsb, which is used in the decoding process of the reference atlas frame list, as follows.

[0519] MaxLtDisplFrmOrderCntLsb =

[0520] 2 * (Log2MaxDisplFrmOrderCntLsb + dfps_additional_lt_dfoc_lsb_len)

[0521] The value of dfps_additional_lt_dfoc_lsb_len is in the range of 0 to 32 - Log2MaxDisplFrmOrderCntLsb.

[0522] If dsps_long_term_ref_displ_frames_flag is 0, the value of dfps_additional_lt_dfoc_lsb_len is equal to 0.

[0523] If dfps_extension_present_flag is 1, it indicates that the syntax element dfps_extension_8bits is present in the displacement frame parameter set. If dfps_extension_present_flag is 0, it indicates that the syntax element dfps_extension_8bits is not present. In this version of this document, the value of dfps_extension_present_flag is 0.

[0524] If dfps_extension_8bits is 0, it indicates that the dfps_extension_data_flag syntax element is missing from the DFPS RBSP syntax structure. If dfps_extension_8bits is present, it is equal to 0 in bitstreams following this version of this document.

[0525] dfps_extension_data_flag can have any value.

[0526] displ_no_output_of_prior_displ_frames_flag affects the output of previously decoded displacement frames in the DDB after decoding displacement frames in the CDS AU rather than the first AU of the bitstream, as specified in ISO / IEC 23090-29. If no_output_of_prior_displ_frames_flag is present, its value is inferred to be 0.

[0527] As a requirement for bitstream conformance, the value of no_output_of_prior_displ_frames_flag is the same for all displacement frames in AU.

[0528] The no_output_of_prior_displ_frames_flag value of the displacement header is the output_of_prior_displ_frames_flag value of the AU.

[0529] displ_frame_parameter_set_id represents the value of dfps_displ_frame_parameter_set_id for the active displacement frame parameter set for the current displacement frame.

[0530] dislp_type indicates the coding type of the current displacement frame according to the table below. The value of smh_type is 0, 1, or 2 in bitstreams following this version of this document. Other values ​​of smh_type are reserved by ISO / IEC for future use.

[0531] Relationship to dislp_type

[0532] smh_typeName of smh_type0P_DISPLACEMENT1I_DISPLACEMENT2...RESERVED

[0533] utput_flag: Affects the decoded displacement output and removal process as specified in ISO / IEC 23090-29. If displ_output_flag is absent, it is inferred to be equal to 1. displ_frm_order_cnt_lsb: Indicates the displacement frame order number modulo MaxDisplFrmOrderCntLsb for the current displacement frame. The length of the displ_frm_order_cnt_lsb syntax element is equal to Log2MaxDisplFrmOrderCntLsb bits. The value of displ_frm_order_cnt_lsb ranges from 0 to MaxDisplFrmOrderCntLsb - 1. If ref_displ_frame_list_dsps_flag is 1, it indicates that the reference displacement frame list for the current displacement frame is derived based on one of the displ_ref_list_struct(rlsIdx) syntax structures of the active DSPS. If ref_displ_frame_list_dsps_flag is 0, it indicates that the referenced displacement frame list for the current displacement frame is derived based on the displ_ref_list_struct(rlsIdx) syntax structure directly contained in the displacement frame header of the current displacement frame. When dsps_num_ref_displ_frame_lists_in_dsps is 0, the value of ref_displ_frame_list_dsps_flag is inferred to be 0. ref_displ_frame_list_idx indicates the index of the displ_ref_list_struct(rlsIdx) syntax structure used to derive the referenced displacement frame list for the current displacement frame from the list of displ_ref_list_struct(rlsIdx) syntax structures contained in the active DSPS. The syntax element ref_displ_frame_list_idx is represented by the Ceil(Log2(dsps_num_ref_displ_frame_lists_in_dsps)) bit.If it does not exist, the value of ref_displ_frame_list_idx is inferred to be equal to 0. The value of ref_displ_frame_list_idx is in the range from 0 to dsps_num_ref_displ_frame_lists_in_dsps - 1. If ref_displ_frame_list_dsps_flag is 1 and dsps_num_ref_displ_frame_lists_in_dsps is 1, the value of ref_displ_frame_list_idx is inferred to be equal to 0.

[0534] The variable RlsIdx of the current atlas tile is derived as follows.

[0535] RlsIdx = ref_displ_frame_list_dsps_flag ?

[0536] ref_displ_frame_list_idx : dsps_num_ref_displ_frame_lists_in_dsps

[0537] If additional_dfoc_lsb_present_flag[ j ] is 1, it indicates that additional_dfoc_lsb_val[ j ] exists for the current displacement frame. If additional_dfoc_lsb_present_flag[ j ] is 0, it indicates that additional_dfoc_lsb_val[ j ] does not exist.

[0538] additional_dfoc_lsb_val[ j ] represents the value of FullFrmOrderCntLsbLt[ RlsIdx ][ j ] for the current atlas tile as follows.

[0539] FullDisplFrmOrderCntLsbLt[RlsIdx][j] =

[0540] additional_dfoc_lsb_val[ j ] * MaxDisplFrmOrderCntLsb +dfoc_lsb_lt[ RlsIdx ][ j ]

[0541] The syntax element additional_dfoc_lsb_val[ j ] is represented by the dfps_additional_lt_dfoc_lsb_len bit. If it does not exist, the value of additional_dfoc_lsb_val[ j ] is inferred to be 0.

[0542] If num_ref_idx_active_override_flag is 1, it indicates that there is a syntax element num_ref_idx_active_minus1 for the current displacement frame. If num_ref_idx_active_override_flag is 0, it indicates that there is no syntax element num_ref_idx_active_minus1. If num_ref_idx_active_override_flag is not present, the value is inferred to be 0.

[0543] num_ref_idx_active_minus1 is used to derive the variable NumRefIdxActive as specified in Equation 5 for the current displacement frame. The value of num_ref_idx_active_minus1 is in the range of 0 to 14.

[0544] If the current displacement frame is a P_DISPLACEMENT displacement frame, num_ref_idx_active_override_flag is 1, and num_ref_idx_active_minus1 is not present, num_ref_idx_active_minus1 is inferred to be equal to 0.

[0545] The variable NumRefIdxActive is derived as follows.

[0546] if( displ_type == P_DISPLACEMENT ) {

[0547] if( num_ref_idx_active_override_flag == 1 )

[0548] NumRefIdxActive = num_ref_idx_active_minus1 + 1

[0549] else {

[0550] if( num_ref_entries[ RlsIdx ] >= dfps_num_ref_idx_default_active_minus1 + 1 )

[0551] NumRefIdxActive = dfps_num_ref_idx_default_active_minus1 + 1

[0552] else

[0553] NumRefIdxActive = num_ref_entries[RlsIdx]

[0554] }

[0555] }

[0556] else

[0557] NumRefIdxActive = 0

[0558] The value obtained by subtracting 1 from NumRefIdxActive represents the maximum value of the displacement reference frame index that can be used to decode the current displacement frame.

[0559] Displacement Reference List Structure Semantics:

[0560] drl_num_ref_entries[rlsIdx] represents the number of entries in the displ_ref_list_struct(rlsIdx) syntax structure, where rlsIdx is the index of the displacement frame reference list. For P_DISPLACEMENT, the value of num_ref_entries[rlsIdx] is in the range of 1 to dsps_max_dec_displ_frame_buffering_minus1 + 1. Otherwise, the value of num_ref_entries[rlsIdx] is in the range of 0 to dsps_max_dec_displ_frame_buffering_minus1 + 1.

[0561] If drl_st_ref_displ_frame_flag[rlsIdx][i] is 1, it indicates that the i-th entry of the displ_ref_list_struct(rlsIdx) syntax structure is a short-reference displacement frame entry. If st_ref_displ_frame_flag[rlsIdx][i] is 0, it indicates that the i-th entry of the displ_ref_list_struct(rlsIdx) syntax structure is a long-reference displacement frame entry. If it does not exist, the value of drl_st_ref_displ_frame_flag[rlsIdx][i] is inferred to be equal to 1.

[0562] The variable NumLtrDisplFrmEntries[rlsIdx] is derived as follows.

[0563] NumLtrDisplFrmEntries[rlsIdx] = 0

[0564] for( i = 0; i < drl_num_ref_entries[rlsIdx]; i++)

[0565] if(!drl_st_ref_displ_frame_flag[rlsIdx][i])

[0566] NumLtrDisplFrmEntries[rlsIdx]++

[0567] drl_abs_delta_dfoc_st[rlsIdx][i], if the i-th item is the first short-term reference displacement frame entry of displ_ref_list_struct(rlsIdx), the syntax structure specifies the absolute difference between the displacement frame order count values ​​of the current displacement frame referenced by the i-th item, or if the i-th item is a short-term reference displacement frame entry but not the first short-term reference displacement frame entry of the displ_ref_list_struct(rlsIdx) syntax structure, it indicates the absolute difference between the displacement frame order count values ​​of the displacement frames referenced by the i-th item and the previous short-term reference displacement frame entry.

[0568] The value of drl_abs_delta_dfoc_st[rlsIdx][i] is in the range of 0 to 215-1.

[0569] If drl_straf_entry_sign_flag[rlsIdx][i] is 1, it indicates that the i-th item of the syntax structure displ_ref_list_struct(rlsIdx) has a value greater than or equal to 0. If drl_straf_entry_sign_flag[rlsIdx][i] is 0, it indicates that the i-th item of the syntax structure displ_ref_list_struct(rlsIdx) has a value less than 0. If not present, the value of drl_straf_entry_sign_flag[rlsIdx][i] is inferred to be 1.

[0570] The DeltaDfocSt[rlsIdx][i] list is derived as follows.

[0571] for( i = 0; i < drl_num_ref_entries[rlsIdx]; i++ )

[0572] if( drl_st_ref_displ_frame_flag[rlsIdx][i])

[0573] DeltaDfocSt[rlsIdx][i] =

[0574] ( 2 * drl_straf_entry_sign_flag[rlsIdx][i] - 1) * drl_abs_delta_dfoc_st[rlsIdx][i]

[0575] else

[0576] DeltaDfocSt[rlsIdx][i] = 0

[0577] drl_dfoc_lsb_lt[rlsIdx][i] represents the displacement frame order count value for MaxDisplFrmOrderCntLsb of the displacement frame referenced by the i-th item of the displ_ref_list_struct(rlsIdx) syntax structure. The length of the drl_dfoc_lsb_lt[ rlsIdx ][ i ] syntax element is Log2MaxDisplFrmOrderCntLsb bits.

[0578] Displacement Layer RBSP Semantics:

[0579] Displacement Header Semantics:

[0580] dh_no_output_of_prior_displ_frames_flag affects the output of previously decoded displacement frames in the DDB after decoding the displacement frames of the CDS AU, not the first AU of the bitstream, as specified in ISO / IEC 23090-29. If no_output_of_prior_displ_frames_flag is missing, the value is inferred to be 0.

[0581] As a requirement for bitstream conformance, the value of no_output_of_prior_displ_frames_flag is the same for all displacement frames in AU.

[0582] The no_output_of_prior_displ_frames_flag value of the displacement header is the output_of_prior_displ_frames_flag value of the AU.

[0583] dh_frame_parameter_set_id represents the dfps_displ_frame_parameter_set_id value for the active displacement frame parameter set for the current displacement frame.

[0584] dh_id: Represents the displacement header ID.

[0585] dh_type indicates the coding type of the current displacement frame as shown in the table below. The value of dh_type is 0 or 1 in bitstreams following this version of this document. Other values ​​of dh_type are reserved by ISO / IEC for future use.

[0586] dh_type relationship

[0587] smh_typeName of smh_type0P_DISPLACEMENT1I_DISPLACEMENT2...RESERVED

[0588] dh_frm_order_cnt_lsb: Represents the modulo displacement frame order number of MaxDisplFrmOrderCntLsb for the current displacement frame. The length of the dh_frm_order_cnt_lsb syntax element is equal to the number of bits in Log2MaxDisplFrmOrderCntLsb. The value of dh_frm_order_cnt_lsb ranges from 0 to MaxDisplFrmOrderCntLsb - 1. If dh_ref_displ_frame_list_dsps_flag is 1, it indicates that the referenced displacement frame list of the current displacement frame is derived from one of the displ_ref_list_struct(rlsIdx) syntax structures of the active DSPS. If dh_ref_displ_frame_list_dsps_flag is 0, it indicates that the referenced displacement frame list of the current displacement frame is derived from the displ_ref_list_struct(rlsIdx) syntax structure directly contained in the displacement frame header of the current displacement frame. If dsps_num_ref_displ_frame_lists_in_dsps is 0, the value of dh_ref_displ_frame_list_dsps_flag is inferred to be 0. dh_ref_displ_frame_list_idx specifies the index of the displ_ref_list_struct(rlsIdx) syntax structure list contained in the active DSPS, which is the displ_ref_list_struct(rlsIdx) syntax structure used to derive the reference displacement frame list of the current displacement frame. The syntax element dh_ref_displ_frame_list_idx is represented by the Ceil(Log2(dsps_num_ref_displ_frame_lists_in_dsps)) bit. If it does not exist, the value of dh_ref_displ_frame_list_idx is inferred to be equal to 0. The value of dh_ref_displ_frame_list_idx is in the range from 0 to dsps_num_ref_displ_frame_lists_in_dsps - 1.If dh_ref_displ_frame_list_dsps_flag is 1 and dsps_num_ref_displ_frame_lists_in_dsps is 1, the value of ref_displ_frame_list_idx is inferred to be 0. The variable RlsIdx of the current atlas tile is derived as follows: RlsIdx = dh_ref_displ_frame_list_dsps_flag ?.

[0589] ref_displ_frame_list_idx : dsps_num_ref_displ_frame_lists_in_dsps

[0590] If dh_additional_dfoc_lsb_present_flag[ j ] is 1, it indicates that dh_additional_dfoc_lsb_val[ j ] is present in the current displacement frame. If dh_additional_dfoc_lsb_present_flag[ j ] is 0, it indicates that dh_additional_dfoc_lsb_val[ j ] is not present.

[0591] dh_additional_dfoc_lsb_val[ j ] represents the value of FullFrmOrderCntLsbLt[ RlsIdx ][ j ] for the current atlas tile as follows.

[0592] FullDisplFrmOrderCntLsbLt[ RlsIdx ][ j ] = dh_additional_dfoc_lsb_val[ j ] *

[0593] MaxDisplFrmOrderCntLsb +dfoc_lsb_lt[ RlsIdx ][ j ]

[0594] The syntax element dh_additional_dfoc_lsb_val[ j ] is represented by dfps_additional_lt_dfoc_lsb_len bits. If it does not exist, the value of dh_additional_dfoc_lsb_val[ j ] is inferred to be equal to 0.

[0595] If dh_num_ref_idx_active_override_flag is 1, it indicates that there is a syntax element num_ref_idx_active_minus1 for the current displacement frame. If dh_num_ref_idx_active_override_flag is 0, it indicates that there is no syntax element num_ref_idx_active_minus1. If dh_num_ref_idx_active_override_flag is not present, its value is inferred to be equal to 0.

[0596] dh_num_ref_idx_active_minus1 is used to derive the variable NumRefIdxActive for the current displacement frame. The value of dh_num_ref_idx_active_minus1 is in the range of 0 to 14.

[0597] If the current displacement frame is a P_DISPLACEMENT displacement frame, dh_num_ref_idx_active_override_flag is 1, and dh_num_ref_idx_active_minus1 is not present, dh_num_ref_idx_active_minus1 is inferred to be equal to 0.

[0598] The variable NumRefIdxActive is derived as follows.

[0599] if( dh_type == P_DISPLACEMENT ) {

[0600] if( dh_num_ref_idx_active_override_flag == 1 )

[0601] NumRefIdxActive = dh_num_ref_idx_active_minus1 + 1

[0602] else {

[0603] if( num_ref_entries[ RlsIdx ] >= dfps_num_ref_idx_default_active_minus1 + 1 )

[0604] NumRefIdxActive = dfps_num_ref_idx_default_active_minus1 + 1

[0605] else

[0606] NumRefIdxActive = num_ref_entries[RlsIdx]

[0607] }

[0608] }

[0609] else

[0610] NumRefIdxActive = 0

[0611] Subtracting 1 from NumRefIdxActive represents the maximum value of the displacement reference frame index that can be used to decode the current displacement frame.

[0612] Adding 6 to dh_log2_subblock_size_minus6 results in the value of the variable subblockSize as follows.

[0613] subblockSize = 1 << ( log2_subblock_size_minus6 + 6 )

[0614] Displacement Data Unit Semantics:

[0615] displ_intra_unit( displID ) contains a displacement unit stream as an aligned stream of bytes or bits, and the location of the unit boundary within this stream can be identified from the pattern of the data. The format of this displacement unit stream is identified by the 4CC code or component codec mapping SEI message defined by dptl_profile_codec_group_idc.

[0616] displ_inter_unit( displID ) contains a displacement unit stream as an ordered stream of bytes or bits, and the location of the unit boundary within this stream can be identified from the data pattern. The format of this displacement unit stream is identified by the 4CC code or component codec mapping SEI message defined by dptl_profile_codec_group_idc.

[0617] Displacement Intra-Data Unit Semantics:

[0618] The arithmetic decoding engine is a context-decoupled binary arithmetic decoder that performs binary renormalization and generates binary output.

[0619] The displacement value is derived from arithmetic decoding.

[0620] diu_lod_count[ displID ] represents the number of granularity levels used in the signaled displacement in the data unit associated with displID.

[0621] diu_vertex_count_lod[ displID ] [ i ] represents the number of displacements for the i-th level of the wavelet transform for the data unit associated with displID.

[0622] diu_last_sig_coeff[ k ] represents the last position index of the non-zero displacement coefficient level in the k-th component.

[0623] diu_coded_block_flag[ k ][ b ] indicates whether there is a non-zero displacement coefficient level in the k-th component of the block at index b (if 1) or not (if 0).

[0624] diu_coded_subblock_flag[ k ][ b ][ s ] indicates whether there is a non-zero displacement coefficient level in the k-th component of the subblock at index s of the block at index b (if 1) or not (if 0).

[0625] diu_coeff_abs_level_gt0[ k ][ b ][ s ][ v ] indicates whether the k-th component of the displacement coefficient level associated with the vertex at index v of the sub-block at index s of the block at index b has an absolute value greater than 0 (if 1) or has none (if 0).

[0626] diu_coeff_abs_level_gt1[ k ][ b ][ s ][ v ] indicates whether the k-th component of the displacement coefficient level associated with the vertex at index v of the sub-block at index s of the block at index b has an absolute value greater than 1 (if 1) or not (if 0). If diu_coeff_abs_level_gt1[ k ][ b ][ s ][ v ] is not present, it is inferred to be equal to 0.

[0627] diu_coeff_sign[ k ][ b ][ s ][ v ] indicates whether the k-th component of the displacement coefficient level associated with the vertex at index v of the sub-block at index s of the block at index b has a positive sign (if 1) or not (if 0). If diu_coeff_sign[ k ][ b ][ s ][ v ] is not present, it is inferred to be equal to 1.

[0628] diu_coeff_abs_level_rem[ k ][ b ][ s ][ v ] represents the absolute value of the k-th component of the displacement coefficient level associated with the vertex at index v of the block obtained by subtracting 2 from index b. If diu_coeff_abs_level_rem[ k ][ b ][ s ][ v ] is not present, it is inferred to be equal to 0.

[0629] Displacement Inter-Data Unit Semantics:

[0630] The arithmetic decoding engine is a context-separated binary arithmetic decoder that performs binary renormalization and generates binary output.

[0631] The displacement residual is derived from arithmetic decoding. It may be the same as the one described above.

[0632] The encoding method according to the embodiments can generate submesh SOI relationship indication information and transmit it as SEI information (Submesh SOI relationship indication SEI payload) within the bitstream.

[0633] Syntax of Submesh SOI relationship indication SEI payload:

[0634] submesh_soi_relationship_indication( payloadSize ) {Descriptorssr_persistence_association_flagu(1)ssr_number_of_active_scene_objectsue(v)ssr_submesh_id_length_minus1ue(v)for( i = 0; i < ssr_number_of_active_scene_object; i++ ) {ssr_soi_object_idx[ i ]u(v)ssr_number_of_submesh_included[ i ]ue(v)for( j = 0; j < ssr_number_of_submesh_included[ i ]; j++ ) {ssr_submesh_id[ i ][ j ]u(v)ssr_completely_included[ i ][ j ]u(1)}}}TK1926

[0635] Semantics:

[0636] The submesh SOI relationship indication SEI message according to the embodiments indicates the relationship between a scene object and a submesh. One or more submeshes can be connected to each scene object, and a submesh can be connected to two or more scene objects.

[0637] Relationship persistence flag (ssr_persistence_association_flag): Indicates that the relationship between a scene object and a submesh is persistent. If the value of this flag is '0', the relationship is valid only for the current frame.

[0638] Count of active scene objects (ssr_number_of_active_scene_object): Represents the number of active scene objects defined for the mesh when the SEI message is signaled.

[0639] Submesh ID length (ssr_submesh_id_length_minus1): Adding 1 to this value indicates the number of bits used to represent the syntax element ssr_submesh_id[i][j].

[0640] Scene Object Index (ssr_soi_object_idx[i]): Represents the index of the i-th scene object (object) to be connected to the submesh.

[0641] Number of submesh in scene object (ssr_number_of_submesh_included[i]: indicates the number of submeshes completely included in the i-th scene object (scene object).

[0642] Submesh ID(ssr_submesh_id[i][j]: Represents the identifier of the j-th submesh included in the i-th scene object. The number of bits used to represent ssr_submesh_id[i][j] is ssr_submesh_id_length_minus1 + 1.

[0643] Whether submesh is included in scene object(ssr_completely_included[i][j]: indicates that the j-th submesh is completely included in the i-th scene object.

[0644] FIG. 17 shows a mesh system according to embodiments.

[0645] Referring to the overall structure of the mesh system in FIG. 17, scenes and / or objects acquired in the real world using multiple cameras, sensors, and / or virtual cameras undergo mesh data pre-processing and mesh data encoding processes, after which an output is generated in the form of a V-DMC bitstream. This mesh bitstream can be converted into a file format suitable for storage and / or transmission through a file encapsulation process.

[0646] The dynamic mesh player can restore a file acquired and / or received through the above process into a mesh bitstream form through a file decapsulation process, and the restored mesh bitstream can be displayed on a display device, etc. through a mesh data decoding process and a mesh data processing / rendering process.

[0647] The mesh data encoding / decoding method according to the embodiments includes a method related to file / segment encapsulation or encapsulator and file / segment decapsulation or encapsulator.

[0648] The track of the file according to the embodiments may include a common data structure.

[0649] Common Data Structure:

[0650] DMC Decoder Configuration Record:

[0651] This information represents decoder configuration information for mesh-based point cloud content. This record includes a version field. The specification for this version defines version 1 of this record. Incompatible changes to the record are indicated by a change in the version number.

[0652] Syntax:

[0653] aligned(8) class DMCDecoderConfigurationRecord {

[0654] unsigned int(8) configurationVersion = 1;

[0655] unsigned int(8) num_of_setup_units;

[0656] for (i=0; I < num_of_setup_units; i++) {

[0657] unsigned int(8) setup_unit_type; / VPS, SPS, FPS, GPS, APS…

[0658] SetupUnit setup_unit;

[0659] }

[0660] / There may be additional fields.

[0661] }

[0662] Semantics:

[0663] configurationVersion: This is the version field. Incompatible changes to the record are indicated by a change in the version number.

[0664] num_of_setup_units: Indicates the number of DMC setup units in the decoder configuration record.

[0665] setup_unit_type represents a set of parameters of a DMC-related type.

[0666] SetupUnit is an instance of an encapsulation structure that conveys VPS (V-DMC parameter set), SPS (sequence parameter set), FPS (frame parameter set), DPS (displacement parameter set), GPS (geometric parameter set), and / or APS (attribute parameter set). These parameter sets may be information based on the parameter sets defined in the V-DMC specification.

[0667] DMC decoder configuration box

[0668] The DMC decoder configuration box contains a DMCDecoderConfigurationRecord. The version is 0.

[0669] Syntax:

[0670] class DMCConfigurationBox extends FullBox('dmcC', version = 0, 0) {

[0671] DMCDecoderConfigurationRecord();

[0672] }

[0673] Semantics:

[0674] DMCDecoderConfigurationRecord follows the description above.

[0675] DMC component information record:

[0676] The DMC component information record represents DMC component information including the type of the DMC component (e.g., geometry or attribute).

[0677] Syntax:

[0678] aligned(8) class DMCComponentInfoRecord(){

[0679] unsigned int(8) component_type;

[0680] if(component_type == 4){ / property component

[0681] unsigned int(8) attr_index;

[0682] utf8string attr_name;

[0683] }

[0684] / Additional fields may exist.

[0685] }

[0686] Semantics:

[0687] component_type: Identifies the type of DMC component specified in the table below. In this version of this document, the value of this field is 1, 2, or 4.

[0688] DMC component types

[0689] component_type valueDescription1Displacement component2Geometry component3Reserved4Attribute component5..31Reserved

[0690] attr_index is the type of the attribute, i.e., it can represent the kind, and can be mapped to the bmsps_mesh_attribute_type_id value of the basemesh sequence parameter set.

[0691] attr_name specifies a human-readable name for the type of the DMC attribute component.

[0692] DMC Component Information Box

[0693] If this box is in a sample item of a track, it indicates the type of DMC component delivered by that track. If this box is in a sample item of a DMC attribute track, it also provides the attribute name and optional attribute type information.

[0694] Syntax:

[0695] aligned(8) class DMCComponentInfoBox extends FullBox('dcin', 0, flags){

[0696] DMCComponentInfoRecord();

[0697] }

[0698] Semantics:

[0699] DMCComponentInfoRecord follows the description above.

[0700] The encoding method according to the embodiments can generate mapping information for multiple atlas tiles and multiple submeshes as common data within a file. The decoding method according to the embodiments can decode mesh data based on the mapping information for multiple atlas tiles and multiple submeshes within the file.

[0701] When a dynamic mesh bitstream consists of one or more atlas tiles and one or more submeshes, the receiver (decoder) may need information regarding the relationship between each atlas tile and submeshe to perform partial decoding and rendering on an atlas tile basis. This can be defined as the syntax and semantics below and may be signaled by including it in the sample entries of the atlas track and / or basemesh track.

[0702] Syntax

[0703] aligned (8) class SubmeshTileMappingBox() {

[0704] unsigned int(16) num_atlas_tiles;

[0705] for(int i=0; i < num_atlas_tiles; i++) {

[0706] unsigned int(16) atlas_tile_id;

[0707] unsigned int(16) num_submeshes;

[0708] for(int j=0; j < num_submeshes; j++) {

[0709] unsigned int(16) submesh_id;

[0710] }

[0711] }

[0712] }

[0713] Semantics

[0714] Count of atlas tiles (num_atlas_tiles): Represents the number of atlas tiles included in the track.

[0715] Atlas Tile ID (atlas_tile_id): Represents the atlas tile ID of the atlas tile containing the patch associated with the track's submesh.

[0716] Count of submeshes (num_submeshes): Represents the number of submeshes associated with the atlas tile.

[0717] Submesh ID (submesh_id): The identifier of the submesh. The value of submesh_id is equal to the value of the corresponding bmsi_submesh_id statement element in bmesh_sub_mesh_information().

[0718] Multiple Track Encapsulation:

[0719] When the mesh data encoding method according to the embodiments encodes mesh data to generate a V-DMC bitstream and encapsulates the bitstream into one or more tracks, the track types can be configured according to the data types included in the bitstream. Each can process a base mesh track, an atlas track, a geometry track or a displacement track, and an attribute track. The geometry track corresponds to cases where displacement data is recorded with a video codec, and the displacement track corresponds to cases where arithmetic coding is used. Additionally, when displacement data is processed with arithmetic coding, base mesh data, atlas data, and displacement data can be encapsulated by configuring them into a single track.

[0720] Basemesh track sample entry

[0721] Sample Entry Type: 'bmc1', 'bmcg', 'bmcb'

[0722] Container: SampleDescriptionBox

[0723] Mandatory: A 'bmc1' or 'bmcg' sample entry is mandatory

[0724] Quantity: One or more

[0725] The encoding method according to the embodiments can encapsulate basemesh data of a V-DMC bitstream into a basemesh track. The decoding method according to the embodiments can decapsulate a file to parse a basemesh track containing basemesh data of a V-DMC bitstream. A sample entry of the basemesh track may include configuration box (DMCConfigurationBox) information. If the sample entry type is 'bmc1', all parameter sets related to the basemesh data may be included in the setup_unit of the DMCConfigurationBox. If the sample entry type is 'bmcg', all parameter sets related to the basemesh data may be included in the setup_unit of the DMCConfigurationBox and / or in the sample of the basemesh track. A receiver (decoder) may recognize a track with a sample entry type of 'bmc1' or 'bmcg' as an entry point and perform a decoding operation.

[0726] Values ​​of sample entry types according to the embodiments, such as 'bmc1', 'bmcg', 'bmcb', etc., may be displayed according to, for example, the 4CC (Four Character Code) of MP4RA. Depending on the type of file format, they may be used to identify types such as video or audio streams. The notations 'bmc1', 'bmcg', 'bmcb' according to the embodiments may be replaced with other name formats.

[0727] A sample entry type of 'bmcb' indicates a case where a basemesh track references one or more submesh tracks. The references between the basemesh track and the submesh track are explained in detail in the description of submesh data encapsulation that follows.

[0728] Syntax:

[0729] aligned(8) class DMCBaseMeshSampleEntry() extends VolumetricVisualSampleEntry (type) {

[0730] / type is 'bmc1' or 'bmcg'

[0731] DMCConfigurationBox config; / as defined in section 4.5.2

[0732] }

[0733] Semantics:

[0734] config is the aforementioned decoder configuration box.

[0735] If the basemesh track is the entry point, the config information may include a V-DMC or V3C parameter set (VPS) and / or a parameter set such as SPS, FPS, etc. associated with the basemesh bitstream.

[0736] Basemesh track sample format

[0737] As in ISO / IEC 23090-29, each sample within the basemesh track corresponds to a single-coded basemesh access unit.

[0738] Syntax

[0739] aligned(8) class DMCBaseMeshSample {

[0740] / sample_size size of sample from SampleSizeBox

[0741] for (int i = 0; i < sample_size; ) {

[0742] sample_stream_nal_unit ss_nal_unit; / Refer to the aforementioned description of the sample stream NAL unit.

[0743] i += ss_nal_unit.ssnu_nal_unit_size; / You can generate a nal unit of basemesh samples by increasing count i by the sample stream nal unit size.

[0744] }

[0745] Semantics:

[0746] The sample stream NAL unit (ss_nal_unit) includes a single NAL unit (bmesh_nal_unit) within the NAL unit sample stream format as defined in ISO / IEC 23090-29.

[0747] NAL unit size (ssnu_nal_unit_size) indicates the size of the sample stream NAL unit in bytes.

[0748] Displacement track sample entry

[0749] Sample Entry Type: 'dpc1', 'dpcg'

[0750] Container: SampleDescriptionBox

[0751] Mandatory: A 'dpc1' or 'dpcg' sample entry is mandatory

[0752] Quantity: One or more

[0753] If the displacement data of the DMC bitstream is encoded in arithmetic coding, it can be encapsulated into a displacement track. Sample entries in the displacement track may contain DMCConfigurationBox information. If the sample entry type is 'dpc1', all associated parameter sets may be included in the setup unit of the DMCConfigurationBox. If the sample entry type is 'dpcg', all associated parameter sets may be included in the setup unit of the DMCConfigurationBox and / or in the sample of the displacement track.

[0754] Syntax:

[0755] aligned(8) class DMCDisplSampleEntry() extends VolumetricVisualSampleEntry (type) {

[0756] / type is 'dpc1' or 'dpcg'

[0757] DMCConfigurationBox config;

[0758] }

[0759] Semantics:

[0760] config is the aforementioned decoder configuration box.

[0761] Displacement Track Sample Format:

[0762] Syntax:

[0763] aligned(8) class DMCDisplSample {

[0764] / sample_size size of sample from SampleSizeBox

[0765] for (int i = 0; i < sample_size; ) {

[0766] sample_stream_nal_unit ss_nal_unit; / Refer to the aforementioned description of the sample stream NAL unit.

[0767] i += ss_nal_unit.ssnu_nal_unit_size; / You can generate a nal unit of basemesh samples by increasing count i by the sample stream nal unit size.

[0768] }

[0769] }

[0770] Semantics:

[0771] The sample stream NAL unit (ss_nal_unit) includes a single NAL unit (displ_nal_unit) within the NAL unit sample stream format, as defined in ISO / IEC 23090-29.

[0772] The sample stream NAL unit size (ssnu_nal_unit_size) represents the size of the sample stream NAL unit in bytes.

[0773] Atlas Track

[0774] The V-DMC specification, ISO / IEC 23090-29, is currently undergoing technical development and standardization by MPEG regarding the utilization of atlas data constituting dynamic mesh bitstreams. If atlas data is used for the same or similar purposes as in the V3C specification, ISO / IEC 23090-5, the file encapsulation method for the atlas data may follow the syntax and semantics of the atlas sample entry and sample format defined in the Carriage of V3C specification, ISO / IEC 23090-10. However, the sample entry type may be newly defined within V-DMC, such as 'dmc1' when the parameter set remains unchanged within the stream, or 'dmcg' when the parameter set changes within the stream. The receiver can operate by recognizing a track with a sample entry type of 'dmc1' or 'dmcg' as an entry point. When an atlas track is an entry point, the config information that may be included in the sample entry may include a V-DMC or V3C parameter set (VPS) and / or parameter sets such as SPS, FPS, etc. associated with the atlas bitstream.

[0775] DMC video component track

[0776] The displacement data constituting the dynamic mesh bitstream can follow the file encapsulation method for 2D video of ISOBMFF, referenced in the Carriage of V3C specification, i.e., ISO / IEC 23090-10, for geometry data and attribute data encoded by the video codec. The receiver can identify information about each data type contained in the track through the V3CUnitHeaderBox information included in the SchemeInformationBox.

[0777] The syntax and semantics of V3CunitHeaderBox may follow the aforementioned details by referring to the V3C specification, namely ISO / IEC 23090-5.

[0778] V3C video component tracks transmit 2D video-encoded data of V3C video components. Storage of V3C video component tracks utilizes existing functions of ISO-based media file formats and derived specifications. For example, ISO / IEC 14496-15 defines a mechanism for transmitting V3C video components coded in ISO / IEC 14496-10 and ISO / IEC 23008-2.

[0779] The V3C video component track must be represented as restricted video in the file and use the standard restricted sample item 'resv' with additional requirements.

[0780] SchemeTypeBox is in RestrictedSchemeInfoBox and scheme_type is set to 'vvvc'

[0781] SchemeInformationBox is in RestrictedSchemeInfoBox and includes V3CUnitHeaderBox.

[0782] In the track header, the track_in_movie flag is set to 0 to indicate that this track should not be displayed alone.

[0783] Through the aforementioned DMCComponentInfoBox signaling, the receiver can identify the data component types included in the corresponding track and information about each data.

[0784] Submesh track sample entry

[0785] Sample Entry Type: 'smc1'

[0786] Container: SampleDescriptionBox

[0787] Mandatory: Yes

[0788] Quantity: One or more

[0789] If the base mesh data consists of one or more submesh data, it can be encapsulated into submesh tracks containing the submesh data, i.e., tracks with a sample entry type of 'smc1'. The sample entry of each submesh track may contain information about the contained submesh data.

[0790] Syntax

[0791] aligned(8) class DMCSubMeshSampleEntry() extends VolumetricVisualSampleEntry (type) {

[0792] / type is 'smc1'

[0793] DMCSubMeshConfigurationBox submesh_info

[0794] }

[0795] Semantics:

[0796] Submesh_info is information about the submesh included in the track described later (see DMCSubMeshConfigurationBox).

[0797] Submesh track sample format

[0798] Each sample within the submesh track corresponds to a single-coded submesh access unit, as defined in ISO / IEC 23090-29.

[0799] Syntax:

[0800] aligned(8) class DMCSubMeshSample {

[0801] / sample_size size of sample from SampleSizeBox

[0802] for (int i = 0; i < sample_size; ) {

[0803] sample_stream_nal_unit ss_nal_unit; the aforementioned sample stream NAL unit

[0804] i += ss_nal_unit.ssnu_nal_unit_size; / You can generate a nal unit of basemesh samples by increasing count i by the sample stream nal unit size.

[0805] }

[0806] }

[0807] Semantics:

[0808] The NAL unit (ss_nal_unit) contains a single NAL unit (bmesh_nal_unit) within the NAL unit sample stream format as defined in ISO / IEC 23090-29.

[0809] The content regarding the base mesh sample and the content regarding the submesh sample can be the same.

[0810] FIG. 18 shows the track of a file according to the embodiments.

[0811] Track References

[0812] If the bass mesh track is the entry track:

[0813] Among the tracks composed of each track type, the basemesh track can be designated as the entry point where the file parser can first start parsing. References between tracks can be made using the TrackReferenceBox of the TrackBox defined in the ISOBMFF specification (ISO / IEC 14496-12) within each track.

[0814] The possible reference relationships between the tracks resulting from this are as follows.

[0815] Track Reference Method 1

[0816] FIG. 18(a) is an example in which a base mesh track references an atlas track, and the atlas track references a geometry track and an attribute track.

[0817] To connect various types of tracks, use the track reference tool of ISO / IEC 14496-12.

[0818] Add a TrackReferenceTypeBox to the TrackReferenceBox within the BaseMesh Track's TrackBox. The TrackReferenceTypeBox contains an array of track_IDs that specify the tracks referenced by the DMC track. To connect a BaseMesh Track to an Atlas Track, the reference type (reference_type) of the BaseMesh Track's TrackReferenceTypeBox identifies the associated Atlas Track and identifies the associated DMC Track. The 4CCs of these track reference types are as follows.

[0819] 'bmct': the referenced atlas track(s).

[0820] 'atcg': the referenced geometry track(s).

[0821] 'atca': the referenced attribute track(s).

[0822] Track Reference Method 2

[0823] FIG. 18(b) is an example in which a base mesh track references an atlas track, a geometry track, and an attribute track.

[0824] To associate a base mesh track with each track, the reference_type of the base mesh track's TrackReferenceTypeBox identifies the associated DMC track. The 4CCs of these track reference types are as follows.

[0825] 'bmct': Referenced atlas track(s)

[0826] 'bmcg': Referenced geometry track(s)

[0827] 'bmca': Referenced attribute track(s)

[0828] FIG. 19 shows the track of a file according to the embodiments.

[0829] If the atlas track is the entry track:

[0830] Among the tracks composed of each track type, the atlas track can be designated as the entry point where the file parser can first start parsing. References between tracks can be made using the TrackReferenceBox of the TrackBox defined in the ISOBMFF specification (ISO / IEC 14496-12) within each track.

[0831] The reference relationships between the possible tracks resulting from this are as shown in Fig. 19.

[0832] To connect various types of tracks, use the track reference tool of ISO / IEC 14496-12.

[0833] Add a TrackReferenceTypeBox to the TrackReferenceBox within the Base Mesh Track's TrackBox. The TrackReferenceTypeBox contains an array of track_IDs that specify the tracks referenced by the V-DMC track. To connect a Base Mesh Track to an Atlas Track, the reference_type of the Base Mesh Track's TrackReferenceTypeBox identifies the associated Atlas Track, and the Atlas Track identifies the associated V-DMC Track. The 4CCs of these track reference types are as follows.

[0834] 'atcb': Referenced bass mesh track(s)

[0835] 'atcg': Referenced geometry track(s)

[0836] 'atca': Referenced attribute track(s)

[0837] The encoding method according to the embodiments can generate a file based on grouping between tracks within the file. The decoding method according to the embodiments can receive a file and decapsulate the tracks based on the track grouping.

[0838] The encoding method according to the embodiments can provide V3C atlas tile track referencing within a file as follows. The decoding method according to the embodiments can obtain a plurality of atlas tile tracks based on information related to atlas tile track referencing within the file.

[0839] Referencing V3C atlas tile tracks

[0840] To link a V3C atlas track with sample entry 'v3c1', 'v3cg', 'v3a1', or 'v3ag' to a V3C atlas tile track with sample entry 'v3t1', use the track reference tool of ISO / IEC 14496-12. The 4CC of this track reference type is 'v3ct'.

[0841] Referencing V3C video component tracks

[0842] To link a V3C atlas track with sample entry 'v3c1', 'v3cg', 'v3a1', or 'v3ag', or a V3C atlas tile track with sample entry 'v3t1', to a video component track, use the Track Reference tool of ISO / IEC 14496-12. You must add one or more TrackReferenceTypeBoxes for each component to the TrackReferenceBox within the TrackBox of the V3C atlas track or V3C atlas tile track. The TrackReferenceTypeBox must contain an array of track_IDs specifying the video track referenced by the V3C atlas track or V3C atlas tile track. The reference_type of the TrackReferenceTypeBox identifies the type of the video component (e.g., accusation, geometry, attributes, or packed data). The 4CCs of these track reference types are as follows:

[0843] ― 'v3vo': Includes video-coded occupied V3C components on the referenced track.

[0844] ― 'v3vg': The referenced track contains video-coded geometry V3C components.

[0845] ― 'v3va': The referenced track contains a video-coded attribute V3C component.

[0846] ― 'v3vp': Contains video-coded packed V3C components on the referenced track.

[0847] The type of V3C component delivered by the referenced restricted video track and displayed in the track's RestrictedSchemeInfoBox matches the track reference type of the V3C atlas track or V3C atlas tile track.

[0848] If there is a 'v3ct' track reference in the V3C atlas track, the 'v3va', 'v3vo', 'v3vg', and 'v3vp' references are not used.

[0849] V-DMC submesh track referencing method according to embodiments

[0850] To connect a V-DMC basemesh track with sample entry 'bmcb' to a V-DMC submesh track with sample entry 'smc1', use the track reference tool defined in ISO / IEC 14496-12. The 4CC of this track reference type is 'bmcs'.

[0851] Method for referencing V-DMC component tracks according to embodiments

[0852] To link a VDMC atlas track with sample entries 'v3c1', 'v3cg', 'v3a1', or 'v3ag', or a VDMC atlas tile track with sample entry 'v3t1', to a VDMC component track, use the Track Reference tool of ISO / IEC 14496-12. Add one or more TrackReferenceTypeBoxes for each component to the TrackReferenceBox within the TrackBox of the VDMC atlas track or VDMC atlas tile track. The TrackReferenceTypeBox contains an array of track_IDs that specify the video tracks referenced by the VDMC atlas track or VDMC atlas tile track. The reference_type of the TrackReferenceTypeBox identifies the type of the VDMC component (e.g., basemesh, displacement, or attribute). The 4CCs of these track reference types are as follows:

[0853] 'vdmb': The referenced track contains the bass mesh VDMC component.

[0854] 'vdms': The referenced track contains the submesh VDMC component.

[0855] 'vdmg': Contains video-coded displacement VDMC components on the referenced track.

[0856] 'vdmd': Contains arithmetic-coded displacement VDMC components for the referenced track.

[0857] 'vdma': Contains VDMC components with video-coded properties for the referenced track.

[0858] However, for displacement data, the corresponding reference type may also be used in relation to the cofield type. (Example: Reference type 'vdmg')

[0859] The type of VDMC component included in each component track must match the track reference type of the VDMC atlas track or VDMC atlas tile track.

[0860] The V-DMC submesh track reference method and V-DMC component track reference method according to the embodiments can be configured as follows.

[0861] The Track Reference tool of ISO / IEC 14496-12 is used to indicate the association between V-DMC component tracks and V3C atlas tracks or V3C atlas tile tracks. Here, V3C atlas tracks or V3C atlas tile tracks contain track references to V-DMC component tracks. The reference_type of the TrackReferenceTypeBox identifies the type of V-DMC component (i.e., base mesh or arithmetic coding displacement). The 4CCs of these track reference types are as follows.

[0862] ― 'vdmb': The referenced track contains the base mesh V-DMC component.

[0863] ― 'vdmd': The referenced track includes an arithmetic coding displacement V-DMC component.

[0864] ― Track reference type 'v3vo' 4CC does not exist.

[0865] FIG. 20 shows an example of a track reference for a single atlas having no submesh and a single atlas tile according to the embodiments.

[0866] In the case where a single atlas with no submesh and one atlas tile is composed of multiple tracks: When the VDMC bitstream is composed of a single atlas and a single atlas tile (or no atlas tile), track references for the multiple tracks can be connected as shown in FIG. 20. A V3C atlas track with sample entry type 'v3c1' or 'v3cg' can be referenced to a basemesh track with sample entry type 'bmc1' or 'bmcg', a displacement video track encoded with a video codec, and an attribute video track using track reference types 'vdmb', 'vdmg', and 'vdma', respectively.

[0867] FIG. 21 shows an example of a track reference for a single atlas having multiple submeshes and a single atlas tile, without a submesh track according to the embodiments.

[0868] Case where a single atlas with a single atlas tile and multiple submeshes are configured as multiple tracks without a submesh track: When the VDMC bitstream consists of a single atlas, a single atlas tile (or no atlas tile), and multiple submeshes, and is not configured as a submesh track, track references for the multiple tracks can be connected as shown in FIG. 21. A V3C atlas track with sample entry type 'v3c1' or 'v3cg' can be referenced to a basemesh track with sample entry type 'bmc1' or 'bmcg', and to a displacement video track and an attribute video track encoded with a video codec, respectively, using track reference types 'vdmb', 'vdmg', and 'vdma'.

[0869] FIG. 22 shows an example of a track reference for a single atlas track and submesh tracks having multiple submeshes and a single atlas tile according to embodiments.

[0870] In the case where a single atlas with a single atlas tile and multiple submeshes are configured as multiple tracks with submesh tracks: When the VDMC bitstream is composed of a single atlas, a single atlas tile (or no atlas tile), and multiple submeshes, and configured with submesh tracks, track references for the multiple tracks can be connected as shown in FIG. 22. A V3C atlas track with sample entry type 'v3c1' or 'v3cg' can be referenced with track reference types 'vdmb', 'vdmg', and 'vdma', respectively, for a basemesh track with sample entry type 'bmcb', a displacement video track encoded with a video codec, and an attribute video track. Additionally, a basemesh track can be referenced with track reference type 'bmcs' for submesh tracks with sample entry type 'smc1'. A basemesh track may only contain common information, such as basemesh parameter sets associated with each referenced submesh track, i.e., non-BMCL NAL unit data.

[0871] FIG. 23 shows an example of a track reference for a single atlas and multiple submeshes having a single atlas tile according to embodiments.

[0872] This explanation assumes an example where Atlas Tile 1 is mapped to Submesh 1 and Submesh 2, and Atlas Tile 2 is mapped to Submesh 3.

[0873] When a single atlas with multiple atlas tiles is configured into multiple tracks: When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, and multiple submeshes, track references for multiple tracks can be connected as shown in FIG. 23. It is assumed that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track with sample entry type 'v3c1' or 'v3cg' can be referenced with track reference types 'vdmb', 'vdmg', and 'vdma', respectively, to a basemesh track with sample entry type 'bmc1' or 'bmcg', a displacement video track encoded with a video codec, and an attribute video track.

[0874] FIG. 24 shows an example of a track reference composed of a single atlas having a single atlas tile and multiple submeshes as submesh tracks according to embodiments.

[0875] Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3.

[0876] When a single atlas with multiple atlas tiles is configured into multiple tracks by configuring them into submesh tracks: When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, multiple submeshes, and submesh tracks, track references for multiple tracks can be connected as shown in FIG. 24. It is assumed that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track with sample entry type 'v3c1' or 'v3cg' can reference a basemesh track with sample entry type 'bmcb', a displacement video track encoded with a video codec, and an attribute video track with track reference types 'vdmb', 'vdmg', and 'vdma', respectively. Additionally, a basemesh track can reference submesh tracks with sample entry type 'smc1' with track reference type 'bmcs'. A basemesh track can only contain common information, such as basemesh parameter sets associated with each referenced submesh track, i.e., non-BMCL NAL unit data.

[0877] Tracks associated with each atlas tile can be grouped and signaled according to the VDMC tile component track grouping method.

[0878] FIG. 25 shows an example of a track reference configured with atlas tile tracks, comprising a single atlas and multiple submeshes having a single atlas tile according to embodiments.

[0879] This is explained with an example where Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3.

[0880] When a single atlas with multiple atlas tiles is configured into multiple tracks by configuring them into atlas tile tracks: When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, multiple submeshes, and submesh tracks, track references for multiple tracks can be connected as shown in FIG. 25. It is assumed that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track with sample entry type 'v3cb' can reference atlas tile tracks with sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track can only contain common information, such as atlas parameter sets related to each atlas tile track being referenced, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track with sample entry type 'bmc1' or 'bmcg' using track reference type 'vdmb'. Each atlas tile track can be referenced by track reference types 'vdmg' and 'vdma' for the displacement video track and attribute video track encoded with the video codec, respectively.

[0881] FIG. 26 shows an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[0882] This is explained in an example where Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3.

[0883] When a single atlas with multiple atlas tiles is configured into multiple tracks, each containing an atlas track, an atlas tile track, and multiple submesh tracks: When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, and multiple submeshs, and the atlas tile bitstream is encapsulated into separate atlas tile tracks and submesh tracks for storage and transmission, track references for multiple tracks can be connected as shown in FIG. 26. It is assumed that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track with sample entry type 'v3cb' can reference atlas tile tracks with sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track may only contain common information, such as an atlas parameter set related to each referenced atlas tile track, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track with sample entry type 'bmcb' using track reference type 'vdmb', and a basemesh track can reference submesh tracks with sample entry type 'smc1' using track reference type 'bmcs'.A basemesh track can only contain common information, such as basemesh parameter sets associated with each referenced submesh track—that is, non-BMCL NAL unit data. Each atlas tile track can reference a displacement video track and an attribute video track encoded by a video codec using track reference types 'vdmg' and 'vdma', respectively. Tracks associated with each atlas tile may also be grouped and signaled according to the VDMC tile component track grouping scheme.

[0884] Track Grouping:

[0885] Submesh track group:

[0886] A submesh track group is a method of indicating that each identical submesh track is the same basemesh when a file is encapsulated into one or more submesh tracks.

[0887] definition:

[0888] Box Types: 'sutg'

[0889] Container: TrackGroupBox

[0890] Mandatory: No

[0891] Quantity: Zero or more

[0892] A submesh track group is defined using a SubmeshTrackGroupBox, which is a track group type that extends the TrackGroupTypeBox defined in ISO / IEC 14496-12. The SubmeshTrackGroupBox indicates that a track belongs to a set of tracks that constitute a submesh group. For each submesh group to which a track belongs, a corresponding instance of the SubmeshTrackGroupBox with the unique track group ID (track_group_id) of that playout group exists in the TrackGroupBox of that track.

[0893] Syntax:

[0894] aligned(8) class SubmeshTrackGroupBox extends TrackGroupTypeBox('sutg') {

[0895] / The track group ID (track_group_id) can be inherited from the track group type box (TrackGroupTypeBox)}

[0896] The method according to the embodiments further includes a V-DMC tile component track grouping method within a file.

[0897] Two or more atlas tiles and their respective associated VDMC components can be grouped using track groups.

[0898] Tracks constituting the submesh and video component associated with each atlas tile can be signaled by grouping them using a track group box with track_group_type 'vdtg' as follows. For example, in the aforementioned example of the track reference, VDMC component tracks associated with atlas tile 1 can be grouped with the same track_group_id, and VDMC component tracks associated with atlas tile 2 can be grouped with the same track_group_id to distinguish them. By using this, partial decoding and rendering at the atlas tile level may be possible.

[0899] Syntax

[0900] aligned(8) class VDMCTileComponentGroupBox extends TrackGroupTypeBox('vdtg') {

[0901] / track_group_id is inherited from TrackGroupTypeBox

[0902] unsigned int(16) num_tiles;

[0903] for(int i=0; i < num_tiles; i++) {

[0904] unsigned int(8) atlas_id;

[0905] unsigned int(16) atlas_tile_id;

[0906] unsigned int(16) num_submeshes;

[0907] for(int j=0; j < num_submeshes; j++) {

[0908] unsigned int(16) submesh_id;

[0909] }

[0910] }

[0911] }

[0912] Semantics

[0913] The tile count (num_tiles) represents the number of atlas tiles connected to this track group.

[0914] The atlas ID (atlas_id) represents the atlas ID associated with the tile_id.

[0915] The atlas_tile_id represents the atlas tile ID of the atlas tile containing the patch associated with the submesh of this track group instance.

[0916] The number of submeshes (num_submeshes) represents the number of submeshes connected to the atlas tile.

[0917] The submesh_id is an identifier for a submesh of this track group instance. The value of submesh_id may be equal to the value of the corresponding bmsi_submesh_id syntax element of bmesh_sub_mesh_information() defined in ISO / IEC 23090-29.

[0918] Submesh data encapsulation methods:

[0919] The encoding method according to the embodiments can encapsulate the submesh data of the mesh data within a file. The decoding method according to the embodiments can receive the file and decode the submesh data.

[0920] Method for signaling by defining a Submesh Configuration Box (DMCSubMeshConfigurationBox):

[0921] Submesh-related information included in the V-DMC bitstream can be signaled in the sample entries of the submesh tracks when the V-DMC track is encapsulated into multiple tracks.

[0922] Syntax:

[0923] aligned(8) class DMCSubMeshConfigurationBox {

[0924] unsigned int(8) num_of_submeshes;

[0925] for (i=0; i < num_of_submeshes; i++) {

[0926] unsigned int(8) submesh_id;

[0927] }

[0928] / Additional fields

[0929] }

[0930] Semantics:

[0931] Number of submeshes (num_of_submeshes): Represents the number of submeshes included in the bitstream. The value of num_of_submeshes can be mapped to the number of submeshes (bmsi_num_submeshes_minus1) in the basemesh submesh information (bmesh_sub_mesh_information()).

[0932] Submesh ID (submesh_id): Represents the identification of each submesh included in the bitstream. The submesh_id value can be mapped to the submesh ID (bmsi_submesh_id) value within the bmesh_sub_mesh_information() information.

[0933] The encoding method according to the embodiments can signal subsamples within a file.

[0934] To use the SubSampleInformationBox in a V-DMC bitstream, subsamples are defined based on the value of the flag field of the SubSampleInformationBox. The flag field can indicate the type of subsample information provided to this box as follows.

[0935] If flag is 0: Indicates a submesh-based subsample. The subsample contains one or more consecutive submesh data units corresponding to a single V-DMC submesh.

[0936] Other values ​​for the flag may be reserved.

[0937] The subsample_priority field can be set to a value according to the specifications of this field in ISO / IEC 14496-12 [ISOBMFF].

[0938] The codec_specific_parameters of the SubsampleInformationBox can be defined as follows:

[0939] if (flags == 0) {

[0940] unsigned int(1) submesh_data_present;

[0941] bit(7) reserved = 0;

[0942] if (submesh_data_present)

[0943] unsigned int(24) submesh_id;

[0944] else

[0945] bit(24) reserved = 0;

[0946] }

[0947] Submesh data present: If this value is 1, it indicates that the subsample contains a submesh data unit.

[0948] Submesh ID (submesh_id): Represents the identifier of each submesh included in the bitstream. The submesh_id value can be mapped to the bmsi_submesh_id value within the bmesh_sub_mesh_information() information.

[0949] Tile mapping information structure:

[0950] Syntax:

[0951] aligned(8) class TileMappingInfoStruct() {

[0952] unsigned int(16) num_tiles;

[0953] for (j=0; j < num_tiles; j++) {

[0954] unsigned int(16) tile_id;

[0955] }

[0956] }

[0957] Semantics:

[0958] Count of tiles (num_tiles): Represents the number of signaled V-DMC atlas tiles in this information structure.

[0959] Tile ID (tile_id): The identifier of the V-DMC atlas tile being signaled.

[0960] VDMC Object Information Box:

[0961] Syntax:

[0962] aligned(8) class VDMCObjectInfo() {

[0963] unsigned int(16) object_idx;

[0964] unsigned inf(16) num_of_submeshes;

[0965] for(i=0; i < num_of_submeshes; i++) {

[0966] unsigned int(15) submesh_id;

[0967] unsigned int(1) sumesh_completely_included_flag;

[0968] }

[0969] / additional fields

[0970] }

[0971] aligned(8) class ObjectInformationBox() {

[0972] unsigned int(16) num_of_objects;

[0973] for (j=0; j < num_of_objects; j++) {

[0974] VDMCObjectInfo object_info;

[0975] }

[0976] }

[0977] Semantics:

[0978] Object Index (object_idx): Represents the value of the object index as defined in the scene object information SEI message of the V3C or VDMC specification.

[0979] Count of submeshes (num_of_submeshes): Represents the number of submeshes included in the scene object.

[0980] Submesh ID (submesh_id): Represents the identifier of a submesh included in a scene object.

[0981] Submesh_completely_included_flag: Indicates that the submesh is completely included in the scene object.

[0982] Count of Objects (num_of_objects): Represents the number of scene objects in the object information box.

[0983] Object info (object_info): Contains information related to scene objects.

[0984] Spatial region information structure:

[0985] Syntax:

[0986] aligned(8) class VDMCSpatialRegionStruct() {

[0987] unsigned int(32) size;

[0988] unsigned int(16) region_id;

[0989] unsigned int(1) bounding_box_present_flag;

[0990] unsigned int(1) dimensions_included_flag;

[0991] unsigned int(1) submesh_info_present_flag;

[0992] unsigned int(5) reserved;

[0993] if(bounding_box_present_flag) {

[0994] VDMCBoundingBox(dimensions_included_flag);

[0995] }

[0996] if(submesh_info_present_flag) {

[0997] SubmeshInfoStruct();

[0998] }

[0999] }

[1000] Semantics:

[1001] Size: An integer value that specifies the number of bytes of this element, including all fields and contained elements.

[1002] Region ID (region_id): An identifier for a 3D spatial region.

[1003] Bounding box present flag (bounding_box_present_flag): Indicates whether 3D bounding box information exists for the signaled area.

[1004] Dimensions_included_flag: Indicates whether dimension information is present in the signaled spatial region.

[1005] Submesh info present flag (submesh_info_present_flag): Indicates whether submesh information exists for the signaled spatial region.

[1006] VDMC bounding box information can basically follow the information defined in V3C carriage (ISO / IEC 23090-10) or G-PCC carriage (ISO / IEC 23090-18).

[1007] The information in the submesh information structure (SubmeshInfoStruct()) may be information related to the submesh as described above.

[1008] Mapping information between scene objects and submeshes defined in the VDMC codec can be added to the sparse region information and signaled as follows. Scene object information refers to additional information such as 3D bounding boxes, labels, and priorities related to one or more 3D objects included in the frame of the VDMC content, and can be signaled by being classified as the SEI (Supplemental Enhancement Information) type of the Setup Unit within the aforementioned Decoder Configuration Record (DMCDecoderConfigurationRecord).

[1009] There is information on the submesh information structure (SubmeshInfoStruct()) that can be included in a 3D sparse region defined at the file system level, but since this can be used to signal the relationship between one or more submeshes and one or more V-DMC atlas tiles, object information (VDMCObjectInfo()) can be added as described above to signal the relationship between one or more scene objects and one or more submeshes included in the 3D sparse region.

[1010] Syntax:

[1011] aligned(8) class VDMCSpatialRegionStruct() {

[1012] unsigned int(32) size;

[1013] unsigned int(16) region_id;

[1014] unsigned int(1) bounding_box_present_flag;

[1015] unsigned int(1) dimensions_included_flag;

[1016] unsigned int(1) submesh_info_present_flag;

[1017] unsigned int(1) object_info_present_flag;

[1018] unsigned int(4) reserved;

[1019] if(bounding_box_present_flag) {

[1020] VDMCBoundingBox(dimensions_included_flag);

[1021] }

[1022] if(submesh_info_present_flag) {

[1023] SubmeshInfoStruct();

[1024] }

[1025] if(object_info_present_flag) {

[1026] VDMCObjectInfo();

[1027] }

[1028] }

[1029] Semantics:

[1030] Object info present flag (object_info_present_flag): Indicates whether VDMC object information exists in the signaled space area.

[1031] VDMCObjectInfo() contains information related to the object as described above.

[1032] Static spatial region signaling

[1033] Box Types: 'vdsr'

[1034] Container: DMCBaseMeshSampleEntry ('bmc1', 'bmcg')

[1035] Mandatory: No

[1036] Quantity: Zero or one

[1037] The spatial region information box (DMCSpatialRegionInfoBox) contains information about one or more 3D spatial regions of the V-DMC bitstreams transmitted by each track.

[1038] Syntax:

[1039] aligned(8) class DMCSpatialRegionInfoBox extends FullBox('vdsr',0,0){

[1040] unsigned int(16) num_regions;

[1041] for (int i=0; i < num_regions; i++) {

[1042] VDMCSpatialRegionStruct();

[1043] }

[1044] }

[1045] Semantics:

[1046] Number of regions (num_regions): Represents the number of signaled 3D spatial regions.

[1047] Spatial Region Structure (VDMCSpatialRegionStruct()): Contains the aforementioned 3D spatial region information.

[1048] Dynamic spatial region signaling:

[1049] This metadata track with sample entry type 'vddr' represents dynamically changed 3D spatial region information or connections between 3D spatial regions and sub-meshes and atlas tiles over time, corresponding to part or all of the V-DMC bitstream. If a V-DMC track or basemesh track is connected to a dynamic spatial region time metadata track, the 3D spatial region information of the V-DMC bitstream conveyed by the track or the connections between 3D spatial regions and sub-meshes and atlas tiles are considered dynamic.

[1050] Syntax:

[1051] aligned(8) class DynamicDMCSpatialRegionSampleEntry

[1052] extends MetaDataSampleEtnry('vddr',0,0){

[1053] DMCSpatialRegionInfoBox region_info;

[1054] }

[1055] Semantics:

[1056] Region info (region_info): As described above, it represents the initial 3D spatial region information.

[1057] In addition, signaling for dynamic spatial region information can use the aforementioned submesh method or sample grouping method.

[1058] Sample Group:

[1059] definition:

[1060] Group Types: 'sgsr'

[1061] Container: Sample Group Description Box ('sgpd')

[1062] Mandatory: No

[1063] Quantity: Zero or more

[1064] Using grouping_type 'sgsr' in sample grouping indicates the spatial region information of samples in V-DMC basemesh tracks or V-DMC atlas tracks.

[1065] Syntax:

[1066] aligned(8) class VDMCSpatialRegionSampleGroupDescriptionEntry() extends VolumetricVisualSampleGroupEntry('sgsr') {

[1067] unsigned int(16) num_regions;

[1068] for (int i=0; i < num_regions; i++) {

[1069] VDMCSpatialRegionStruct();

[1070] }

[1071] }

[1072] Semantics:

[1073] Number of regions (num_regions): Represents the number of signaled 3D spatial regions.

[1074] Spatial Region Structure (VDMCSpatialRegionStruct()): Provides 3D spatial region information related to sub-meshes.

[1075] FIG. 27 shows a receiving device according to embodiments.

[1076] Referring to FIG. 27, the decoder can decode the submesh track and submesh information as follows.

[1077] File Receiver: The receiver (decoder) can receive dynamic mesh content consisting of submesh data in the form of a file and can parse one or more tracks included in the file.

[1078] The received dynamic mesh content may include signaling information containing one or more scene object information.

[1079] File Parser: The receiver's file parser parses the sample entries of one or more tracks within the dynamic mesh content file to find bass mesh tracks with a sample entry type of 'bmc1' or 'bmcg'.

[1080] The receiver can obtain decoder configuration information by parsing the configuration box (DMCConfigurationBox) included in the sample entry of the basemesh track. Additionally, if the content supports partial access, the sample entry may include a sparsal region information box (DMCSpatialRegionInfoBox). A receiver supporting partial access can obtain information regarding each sparsal region, one or more submeshes included in the sparsal region, and / or one or more atlas tiles by parsing this DMCSpatialRegionInfoBox.

[1081] In addition, by parsing the scene object information included in each spatial region, connection information between each scene object and submeshes can be obtained.

[1082] FIG. 28 shows the relationship between atlas tiles and sub-meshes according to embodiments.

[1083] The receiver's bitstream packager can collect data per submesh and / or atlas tile corresponding to each sparsal region through file parsing and configure it into a decoding-capable dynamic mesh basemesh bitstream.

[1084] FIG. 28 is an example illustrating the relationship between texture and displacement data associated with a base mesh composed of three submeshes. For example, if Tile 0 includes Submeshe 0 and Submeshe 1, and Tile 1 includes Submeshe 2, the decoder can decode displacement (geometry) data for the three submeshes associated with the two tiles. Additionally, the decoder can decode texture data for the three submeshes associated with the two tiles. If a sparse region includes a base mesh that includes a submeshe identified by submeshe index 0 and a submeshe identified by submeshe index 2, the receiver can select and decode texture and displacement data corresponding to the submeshes.

[1085] V-DMC Decoder: Can decode dynamic mesh bitstreams organized into each sparal region unit through a bitstream packager. Can provide scene object information included in each sparal region and associated submesh information to a receiver (decoder).

[1086] The method and apparatus according to the embodiments may further include and perform a multiple track reference and group signaling scheme of dynamic mesh coding bitstream.

[1087] FIG. 29 shows an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[1088] Explain using an example where Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3.

[1089] This is a second embodiment in which a single atlas with multiple atlas tiles is composed of multiple tracks, each including an atlas track, an atlas tile track, and multiple submesh tracks.

[1090] When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, and multiple submeshes, and the atlas tile bitstream is encapsulated into separate atlas tile tracks and submeshe tracks for storage and transmission, track references for the multiple tracks can be connected as shown in FIG. 29. This embodiment assumes that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track having sample entry type 'v3cb' can reference atlas tile tracks having sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track may only contain common information, such as atlas parameter sets associated with each referenced atlas tile track, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track with sample entry type 'bmcb' using track reference type 'vdmb', and a basemesh track can reference submesh tracks with sample entry type 'smc1' using track reference type 'bmcs'. A basemesh track may only contain common information, such as basemesh parameter sets associated with each referenced submesh track, i.e., non-BMCL NAL unit data. Each atlas tile track can reference a displacement video track and an attribute video track encoded with a video codec using track reference types 'vdmg' and 'vdma', respectively. In this embodiment, the atlas track of sample entry type 'v3cb' can reference the displacement bio tracks and attribute tracks associated with each tile to reference types 'vdmg' and 'vdma', respectively, and the atlas tile tracks may not have separate track references.

[1091] In the case of this embodiment, tracks associated with each atlas tile may be grouped and signaled according to the VDMC tile component track grouping method.

[1092] In addition, in the case of this embodiment, a constraint may be applied that related component tracks can be directly referenced even when referencing the atlas track of sample entry type 'v3cb', i.e., the atlas tile track.

[1093] The method and apparatus according to the embodiments may further include and perform an Atlas Tile-based Multiple Track Reference and Group Signaling of Dynamic Mesh Coding Bitstream.

[1094] The embodiments further include an atlas tile base track reference signaling scheme for multiple tracks of a V-DMC bitstream.

[1095] The VDMC atlas tile data unit syntax in the bitstream according to the embodiments is as follows.

[1096] General VDMC atlas tile data unit syntax:

[1097]

[1098] Meshpatch information data syntax:

[1099]

[1100] Meshpatch data unit syntax:

[1101]

[1102] VDMC Atlas Tile Data Unit Semantics:

[1103] General VDMC Atlas Tile Data Unit Syntax:

[1104] atdu_meshpatch_mode[ tileID ][ p ] indicates the mesh patch mode for the mesh patch with patch index p whose tile ID is tileID in the current atlas tile. The allowed values ​​for atdu_meshpatch_mode[ tileID ][ p ] are as follows for atlas tiles with ath_type I_TILE, atlas tiles with ath_type P_TILE, atlas tiles with ath_type I_TILE_ATTR, atlas tiles with ath_type P_TILE_ATT, and atlas tiles with ath_type SKIP_TILE. If this value is not specified, the value of atdu_meshpatch_mode[ tileID ][ p ] is inferred to be the same as P_SKIP. Bitstreams conforming to this version of this document do not have modes marked as reserved.

[1105] The mesh patch mode for atlas tiles of type I_TILE is as follows.

[1106] The definitions for each value of atdu_meshpatch_mode[ tileID ][ p ] are as follows: 0: Unexpected meshpatch mode, 1-13: Modes reserved for future use by ISO / IEC, 14: Meshpatch termination mode.

[1107] The mesh patch modes for P_TILE type atlas tiles are as follows.

[1108] The definitions for each value of atdu_meshpatch_mode[ tileID ][ p ] are as follows.

[1109] 0: P_SKIP Meshpatch skip mode, 1: P_MERGE Meshpatch merging mode, 2: P_INTER Predicted meshpatch mode, 3: P_INTRA Unpredicted meshpatch mode, 4-13: P_RESERVED Mode reserved for future use by ISO / IEC, 14: P_END Patch termination mode.

[1110] The meshpatch modes for atlas tiles of type I_TILE_ATTR are as follows.

[1111] Each value of atdu_meshpatch_mode[ tileID ][ p ] is as follows: 0: I_INTRA Unpredicted meshpatch mode, 1-13: I_RESERVED Mode reserved for future use by ISO / IEC, 14: I_END Meshpatch end mode.

[1112] The meshpatch modes for atlas tiles of type P_TILE_ATTR are as follows.

[1113] The definitions for each value of atdu_meshpatch_mode[ tileID ][ p ] are as follows: 0: Meshpatch skip mode, 1: Unexpected meshpatch mode, 2-13: Modes reserved for future use by ISO / IEC, 14: Patch end mode.

[1114] The mesh patch modes for SKIP_TILE type atlas tiles are as follows.

[1115] If atdu_meshpatch_mode[ tileID ][ p ] is 0: indicates mesh patch skip mode.

[1116] Mesh patch data unit syntax:

[1117] mdu_submesh_id[ tileID ][ patchIdx ] represents the associated submesh ID assigned to the current mesh patch with index patchIdx in the current atlas tile, where the tile ID is equal to tileID. The value of mdu_submesh_id[ tileID ][ patchIdx ] must be one of afmi_submesh_id[ i ], where i is in the range from 0 to 63.

[1118] In a bitstream conforming to this version of this document, a coded atlas frame cannot contain two or more mesh patch data units representing the same LOD index and the same submesh ID within a geometry tile where ath_type is P_TILE or I_TILE.

[1119] An atlas frame coded in a bitstream conforming to this version of this document cannot contain two or more mesh patch data units representing the same LOD index and the same submesh ID within a tile where ath_type is P_TILE_ATTR or I_TILE_ATTR.

[1120] mdu_subdispl_id[ tileID ][ patchIdx ] represents the associated subdisplacement ID assigned to the current mesh patch with index patchIdx on the current atlas tile with tileID. The value of mdu_subdispl_id[ tileID ][ patchIdx ] ranges from 0 to 65535.

[1121] mdu_lod_idx[ tileID ][ patchIdx ] represents the LOD index to which the data of the current patch with index patchIdx is applied on the current atlas tile with tile ID tileID. If mdu_lod_idx[ tileID ][ patchIdx ] is not present, the value is inferred to be 0.

[1122] mdu_2d_pos_x[ tileID ][ patchIdx ] specifies the x-coordinate of the top-left corner of the mesh patch bounding box of the current mesh patch at index patchIdx in the current atlas tile. The tile ID is equal to tileID and is expressed as a multiple of PatchPackingBlockSize.

[1123]

[1124] mdu_2d_pos_y[ tileID ][ patchIdx ] specifies the y-coordinate of the top-left corner of the bounding box of the current mesh patch at index patchIdx on the current atlas tile. The tile ID is equal to tileID and is expressed as a multiple of PatchPackingBlockSize. Adding 1 to mdu_2d_size_x_minus1[ tileID ][ patchIdx ] specifies the bounding box width value of the mesh patch at index patchIdx on the current atlas tile. The tile ID is equal to tileID and is expressed as a multiple of PatchPackingBlockSize.

[1125] Adding 1 to mdu_2d_size_y_minus1[ tileID ][ patchIdx ] specifies the bounding box height value of the mesh patch at index patchIdx on the current atlas tile. The tile ID is equal to tileID and is expressed as a multiple of PatchPackingBlockSize. PatchPackingBlockSize.

[1126] If mdu_parameters_override_flag[ tileID ][ patchIdx ] is 1, it indicates that the parameters mdu_subdivision_iteration_count_present_flag, mdu_subdivision_iteration_count, mdu_subdivision_method_present_flag, mdu_quantization_present_flag, mdu_transform_method_present_flag and mdu_transform_parameters_present_flag exist in the mesh patch with index patchIdx, and the tile ID is equal to tileID. If mdu_parameters_override_flag[ tileID ][ patchIdx ] is 0, the parameters mdu_subdivision_iteration_count_present_flag, mdu_subdivision_iteration_count, mdu_subdivision_method_present_flag, mdu_quantization_present_flag, mdu_transform_method_present_flag, and mdu_transform_parameters_present_flag indicate that there is no mesh patch with an index patchIdx that has a tile ID equal to tileID in the current atlas tile.

[1127] If mdu_subdivision_iteration_count_present_flag[ tileID ][ patchIdx ] is 1, the parameter mdu_subdivision_iteration_count indicates that there is a mesh patch with an index patchIdx that has a tile ID equal to tileID in the current atlas tile. If mdu_parameters_override_flag is 0 and mdu_subdivision_iteration_count_present_flag[ tileID ][ patchIdx ] is missing, the value is inferred to be 0.

[1128] mdu_subdivision_iteration_count[ tileID ][ patchIdx ] represents the number of iterations used for the subdivision of the mesh patch with index patchIdx in the current atlas tile, where the tile ID is the same as tileID. If mdu_subdivision_iteration_count[ tileID ][ patchIdx ] is not present, the value is inferred as afve_subdivision_iteration_count.

[1129] If mdu_transform_method_present_flag[ tileID ][ patchIdx ] is 1, it indicates that mdu_transform_method exists in the mesh patch with index patchIdx on the current atlas tile, and the tile ID is equal to tileID. If mdu_transform_method_present_flag[ tileID ][ patchIdx ] is not present, the value is inferred to be 0.

[1130] If mdu_subdivision_method_present_flag[ tileID ][ patchIdx ] is 1, it indicates that mdu_subdivision_method exists in the mesh patch with index patchIdx in the current atlas tile, and the tile ID is equal to tileID. If mdu_subdivision_method_present_flag[ tileID ][ patchIdx ] is missing, and PatchSubdivisionCount[ tileID ][ patchIdx ] is 0, then mdu_subdivision_method_present_flag[ tileID ][ patchIdx ] is inferred to be 0, otherwise mdu_subdivision_iteration_count_present_flag[ tileID ][ patchIdx ] is 1 and PatchSubdivisionCount[ tileID ][ patchIdx ] is not 0, then mdu_subdivision_method_present_flag[ tileID ][ patchIdx ] is inferred to be 1, otherwise mdu_subdivision_method_present_flag[ tileID ][ patchIdx ] is inferred to be 0.

[1131] mdu_quantization_present_flag[ tileID ][ patchIdx ] equal to 1 indicates that the vdmc_quantization_parameters(qpIndex, subdivisionCount, refSubdivisionCount) syntax structure exists in the meshpatch containing the index patchIdx of the current atlas tile, and the tile ID is equal to tileID. If mdu_quantization_present_flag[ tileID ][ patchIdx ] is not present, the value is inferred as 0 if mdu_parameters_override_flag is 1 and asve_quantization_parameters_present_flag is 0, otherwise, the value is inferred as 1 if mdu_parameters_override_flag is 1, asve_quantization_parameters_present_flag is 1, and mdu_subdivision_iteration_count_present_flag is 1, otherwise, the value is inferred as 0.

[1132] The variable QpIndex meshpatch, which has an index patchIdx with tile ID tileID in the current atlas tile, is derived as follows.

[1133] QpIndex[tileID][patchIdx] =

[1134] mdu_quantization_present_flag[ tileID ][ patchIdx ] ? 2:

[1135] afve_quantization_parameters_present_flag ? 1: 0

[1136] The variable IQSkip for the current mesh patch with index patchIdx, whose tile ID is tileID in the current atlas tile, is derived as follows.

[1137] IQSkip[tileID][patchIdx] =

[1138] !mdu_quantization_present_flag[ tileID ][ patchIdx ] &&

[1139] !afve_quantization_parameters_present_flag &&

[1140] !asve_quantization_parameters_present_flag

[1141] When mdu_transform_parameters_present_flag[ tileID ][ patchIdx ] is 1, the vdmc_lifting_transform_parameters(lptIndex, subdivisionCount) syntax structure exists in the meshpatch containing the index patchIdx of the current atlas tile, and the tile ID is equal to tileID. If mdu_transform_parameters_present_flag[ tileID ][ patchIdx ] is not present, and if PatchSubdivisionCount[ tileID ][ patchIdx ] is 0, then mdu_transform_parameters_present_flag[ tileID ][ patchIdx ] is inferred to be 0, otherwise, if mdu_parameters_override_flag is 1 and PatchSubdivisionCount[ tileID ][ patchIdx ] is not 0 and mdu_subdivision_iteration_count_present_flag is 1 or mdu_transform_method_present_flag is 1, then mdu_transform_parameters_present_flag is inferred to be 1, otherwise mdu_transform_parameters_present_flag is inferred to be 0.

[1142] The variable LtpIndex of the current mesh patch with an index, and patchIdx, where the tile ID in the current atlas tile is tileID, are derived as follows.

[1143] LtpIndex[tileID][patchIdx] =

[1144] mdu_transform_parameters_present_flag[ tileID ][ patchIdx ] ? 2:

[1145] afve_transform_parameters_present_flag ? 1: 0

[1146] If mdu_lod_adaptive_subdivision_flag[ tileID ][ patchIdx ] is 1, it indicates that the subdivision method is signaled for each subdivision iteration of the mesh patch with index patchIdx in the current atlas tile. If mdu_lod_adaptive_subdivision_flag is 0, it indicates that the same subdivision method is applied for each subdivision iteration of the mesh patch with index patchIdx in the current atlas tile. The same subdivision method is applied for each subdivision iteration of the mesh patch with tile ID tileID.

[1147] mdu_subdivision_method[ tileID ][ patchIdx ][ i ] represents the identifier of the method that subdivides the mesh associated with the meshpatch at index patchIdx in the current atlas tile. The tile ID is equal to the tileID of the subdivision with subdivision index i. If mdu_subdivision_method[ tileID ][ patchIdx ][ i ] is missing, the value is inferred to be the same as afve_subdivision_method[ i ].

[1148] If mdu_edge_based_subdivision_flag[ tileID ][ patchIdx ] is 1, it specifies that edge length-based subdivision determination is enabled in the last iteration when midpoint subdivision is used in all iterations for the subdivision of the mesh associated with the meshpatch at index patchIdx in the current atlas tile. Tile ID is equal to tileID. If mdu_edge_based_subdivision_flag[ tileID ][ patchIdx ] is 0, it specifies that edge length-based subdivision determination is disabled. If not present, the value of mdu_edge_based_subdivision_flag[ tileID ][ patchIdx ] is inferred to be 0.

[1149] The requirement for bitstreams conforming to this version of this document is that when mdu_subdivision_method[ i ] is not equal to MIDPOINT, the value of mdu_edge_based_subdivision_flag must be equal to 0 for all i from 0 to mdu_subdivision_iteration_count - 1.

[1150] mdu_subdivision_min_edge_length[ tileID ][ patchIdx ] represents the threshold value for edge-length-based subdivision decisions for the subpart of the mesh associated with the mesh patch at index patchIdx in the current atlas tile. The tile ID is equal to tileID. If mdu_subdivision_min_edge_length[ tileID ][ patchIdx ] is not present, mdu_subdivision_min_edge_length[ tileID ][ patchIdx ] is equal to afve_subdivision_min_edge_length.

[1151] If mdu_inverse_quantization_offset_enable_flag[ tileID ][ patchIdx ] is 1, it specifies that the inverse quantization offset is used to compensate for the inverse quantized wavelet transform displacement coefficients of the displacement. If mdu_inverse_quantization_offset_enable_flag is 0, it specifies that the inverse quantization offset is not used. If mdu_inverse_quantization_offset_enable_flag is not present, mdu_inverse_quantization_offset_enable_flag is inferred to be 0.

[1152] mdu_inverse_quantization_offset_sign[ tileID ][ patchIdx ][ i ][ j ][ k ] represents the sign of the inverse quantization offset value used to compensate the inverse quantization wavelet transform displacement coefficient located in region k with LoD i of the patch, to the mesh patch with index patchIdx in the current atlas tile. This mesh patch is identical to tileID. If it does not exist, the value of mdu_inverse_quantization_offset_sign[ tileID ][ patchIdx ][ i ][ j ][ k ] is inferred to be 0.

[1153] mdu_inverse_quantization_offset_value_log2_prec1_delta[ tileID ][ patchIdx ][ i ][ j ][ k ] represents the difference in value of the inverse quantization offset value for the first precision level located in region k with displacement dimension j between LoD i and LoD i-1. Here, i is a non-zero value, and the tile ID in the patch containing the mesh patch with index patchIdx in the current atlas tile is equal to tileID. If i is 0, it represents the absolute value of the offset value for the first precision level associated with LoD 0. If it does not exist, mdu_inverse_quantization_offset_value_log2_prec1_delta[ tileID ][ patchIdx ][ i ][ j ][ k ] is inferred to be equal to 0.

[1154] mdu_inverse_quantization_offset_value_log2_prec2_delta[ tileID ][ patchIdx ][ i ][ j ][ k ] represents the value of the inverse quantization offset for the second precision level located in region k with displacement dimension j between LoD i and LoD i-1 when i is a non-zero value. In the current atlas tile, the tile ID is equal to tileID in the patch containing the mesh patch with index patchIdx. When i is 0, it represents the absolute value of the offset for the second precision level associated with LoD 0. If it does not exist, mdu_inverse_quantization_offset_value_log2_prec2_delta[ tileID ][ patchIdx ][ i ][ j ][ k ] is inferred to be equal to 0.

[1155] mdu_displacement_coordinate_system[ tileID ][ patchIdx ] represents the coordinate system identifier of the mesh subpart associated with the mesh patch with index patchIdx on the current atlas tile. The tile ID is the same as tileID. The relationship between the list of displacement coordinate systems and mdu_displacement_coordinate_system[ tileID ][ patchIdx ] is as follows. If this value is 0, it indicates CANNONICAL, and if this value is 1, it indicates LOCAL.

[1156] mdu_transform_method[ tileID ][ patchIdx ] represents the transformation identifier applied to the displacement associated with the mesh patch at index patchIdx on the current atlas tile, where the tile ID is equal to tileID. If PatchSubdivisionCount[ tileID ][ patchIdx ] is 0, the value is inferred to be 0. If PatchSubdivisionCount[ tileID ][ patchIdx ] is not 0 and mdu_transform_method[ tileID ][ patchIdx ] is missing, the value is inferred to be the same as afve_transform_method. Table 3 describes the list of supported transformations and their relationship with mdu_transform_method[ tileID ][ patchIdx ].

[1157] If mdu_lifting_offset_present_flag[ tileID ][ patchIdx ] is 1, it indicates that a lifting offset parameter exists for a mesh patch with index patchIdx, whose tile ID is the same as tileID, in the current atlas tile. If mdu_lifting_offset_present_flag[ tileID ][ patchIdx ] is 0, it indicates that there is no lifting offset parameter. If it does not exist, mdu_lifting_offset_present_flag[ tileID ][ patchIdx ] is inferred to be 0.

[1158] mdu_lifting_offset_values_num[ tileID ][ patchIdx ][ i ] represents the numerator of the lifting offset used to handle the bias in the detail level lifting transformation with index i for the submesh with submesh ID mdu_submesh_id[ tileID ][ patchIdx ].

[1159] mdu_lifting_offset_values_deno_minus1[ tileID ][ patchIdx ][ i ] plus 1 represents the denominator of the lifting offset used to handle the bias in the Level of Detail (LOD) lifting transformation for the submesh with index i and submesh ID mdu_submesh_id[ tileID ][ patchIdx ].

[1160] If mdu_directional_lifting_present_flag[ tileID ][ patchIdx ] is 1, it indicates that a directional lifting parameter exists for the mesh patch with index patchIdx on the current atlas tile and that the tile ID is the same as tileID. If mdu_directional_lifting_present_flag[ tileID ][ patchIdx ] is 0, it indicates that a directional lifting parameter does not exist. If it does not exist, mdu_directional_lifting_present_flag[ tileID ][ patchIdx ] is inferred to be the same as 0.

[1161] mdu_directional_lifting_mean_num[ tileID ][ patchIdx ] represents the numerator of the mean used to calculate the Z-score in directional lifting for the submesh with submesh ID mdu_submesh_id[ tileID ][ patchIdx ].

[1162] The value obtained by adding 1 to mdu_directional_lifting_mean_deno_minus1[ tileID ][ patchIdx ] represents the denominator of the mean used to calculate the Z-score in directional lifting for the submesh with submesh ID mdu_submesh_id[ tileID ][ patchIdx ].

[1163] mdu_directional_lifting_std_num[ tileID ][ patchIdx ] represents the numerator of the standard deviation used to calculate the z-score of directional lifting for the submesh with submesh ID mdu_submesh_id[ tileID ][ patchIdx ].

[1164] The value obtained by adding 1 to mdu_directional_lifting_std_deno_minus1[ tileID ][ patchIdx ] represents the denominator of the standard deviation used to calculate the z-score of directional lifting for the submesh with submesh ID mdu_submesh_id[ tileID ][ patchIdx ].

[1165] The value obtained by adding 1 to mdu_block_count_minus1[ tileID ][ patchIdx ][ i ] specifies the quotient of the number of vertices associated with the i-th subdivision iteration for the current mesh patch at index patchIdx in the current atlas tile. The tile ID is equal to tileID and is the value divided by PatchPackingBlockSize × PatchPackingBlockSize. The length of the mdu_block_count_minus1[ tileID ][ patchIdx ][ i ] syntax element is blockCountBitCount bits, and blockCountBitCount is calculated as follows.

[1166] blockCountBitCount = max ( 1, ceil( Log2(

[1167] ( mdu_2d_size_x_minus1[ tileID ][ patchIdx ] + 1 ) *

[1168] ( mdu_2d_size_y_minus1[ tileID ][ patchIdx ] + 1) ) ) )

[1169] If ApsDisplacementIdPresentFlag is 1, the quotient of the number of vertices is connected to a subdivision iteration like i.

[1170] If ApsDisplacementIdPresentFlag is 0, the quotient of the vertex count is associated with a subdivision iteration such as mdu_lod_idx[ tileID ][ patchIdx ].

[1171] mdu_last_pos_in_block[ tileID ][ patchIdx ][ i ] represents the remainder of the number of vertices associated with the i-th subdivision iteration for the current mesh patch at index patchIdx in the current atlas tile. The tile ID is the value of tileID divided by PatchPackingBlockSize * PatchPackingBlockSize. The mdu_last_pos_in_block[ tileID ][ patchIdx ][ i ] syntax element has 2asps_log2_patch_packing_block_size bits.

[1172] If ApsDisplacementIdPresentFlag is 1, the remainder of the vertex count is associated with a sub-partition iteration like i.

[1173] If ApsDisplacementIdPresentFlag is 0, the remainder of the vertex count is associated with a sub-partition iteration such as mdu_lod_idx[ tileID ][ patchIdx ].

[1174] mdu_attributes_2d_pos_x[ tileID ][ patchIdx ] specifies the x-coordinate of the top-left corner of the attribute bounding box of the mesh patch for the current mesh patch at index patchIdx on the current atlas tile. The tile ID is equal to tileID and is expressed as a multiple of PatchPackingBlockSize. If mdu_attributes_2d_pos_x[ tileID ][ patchIdx ] is not present, the value is inferred as 0.

[1175] mdu_attributes_2d_pos_y[ tileID ][ patchIdx ] specifies the y-coordinate of the top-left corner of the attribute bounding box of the mesh patch for the current mesh patch at index patchIdx on the current atlas tile. The tile ID is equal to tileID and is expressed as a multiple of PatchPackingBlockSize. If mdu_attributes_2d_pos_y[ tileID ][ patchIdx ] is missing, the value is inferred to be 0.

[1176] Adding 1 to mdu_attributes_2d_size_x_minus1[ tileID ][ patchIdx ] specifies the attribute bounding box width value of the mesh patch with index patchIdx in the current atlas tile, and the tile ID is equal to tileID. If mdu_attributes_2d_size_x_minus1[ tileID ][ patchIdx ] is not present, the value is inferred to be equal to TileWidthAtt[ TileIDToAtlasAttributeIdx[ tileID ] ][ TileIDToIndex[ tileID ] ] - 1.

[1177] The value obtained by adding 1 to mdu_attributes_2d_size_y_minus1[ tileID ][ patchIdx ] specifies the height value of the attribute bounding box of the mesh patch at index patchIdx in the current atlas tile for the attribute signaled in the atlas attribute nominal frame at index i. The tile ID is equal to tileID. If mdu_attributes_2d_size_y_minus1[ tileID ][ patchIdx ] is not present, the value is inferred to be equal to TileHeightAtt[ TileIDToAtlasAttributeIdx[ tileID ] ][ TileIDToIndex[ tileID ] ] - 1.

[1178] FIG. 30 shows a track reference example comprising a single atlas having a single atlas tile according to embodiments and multiple submeshes configured as submesh tracks.

[1179] An example is described assuming that Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3. The method and apparatus according to the embodiments can configure the reference and grouping relationships of each track as shown in FIG. 30.

[1180] Example of configuring a single atlas with multiple atlas tiles into atlas tile tracks to form multiple tracks

[1181] When a VDMC bitstream consists of a single atlas, multiple atlas tiles, multiple submeshes, and submesh tracks, track references for multiple tracks can be connected as shown in FIG. 26. This embodiment assumes that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track having sample entry type 'v3c1' can reference atlas tile tracks having sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track may only contain common information, such as an atlas parameter set related to each atlas tile track being referenced, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track having sample entry type 'bmc1' or 'bmcg' using track reference type 'vdmb'. Each atlas tile track can be referenced by track reference types 'vdmg' and 'vdma' for the displacement video track and attribute video track encoded with the video codec, respectively.

[1182] Example of configuring a single atlas with multiple atlas tiles into multiple tracks each including an atlas track, an atlas tile track, and multiple submesh tracks

[1183] When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, and multiple submeshes, and the atlas tile bitstream is encapsulated into separate atlas tile tracks and submesh tracks for storage and transmission, track references for multiple tracks can be connected as shown in FIG. 26. This embodiment assumes that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track having sample entry type 'v3c1' can reference atlas tile tracks having sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track may only contain common information, such as an atlas parameter set related to each referenced atlas tile track, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track with sample entry type 'bmcb' using track reference type 'vdmb', and a basemesh track can reference submesh tracks with sample entry type 'smc1' using track reference type 'bmcs'. A basemesh track can only contain common information, such as basemesh parameter sets related to each referenced submesh track, i.e., non-BMCL NAL unit data.Each atlas tile track can be referenced by track reference types 'vdmg' and 'vdma' for the displacement video track and attribute video track encoded with the video codec, respectively.

[1184] In the case of this embodiment, tracks associated with each atlas tile may be grouped and signaled according to the VDMC tile component track grouping method.

[1185] FIG. 31 shows an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[1186] We will explain assuming an example where Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3.

[1187] A second embodiment in which a single atlas with multiple atlas tiles is composed of multiple tracks each including an atlas track, an atlas tile track, and multiple submesh tracks.

[1188] When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, and multiple submeshes, and the atlas tile bitstream is encapsulated into separate atlas tile tracks and submesh tracks for storage and transmission, track references for multiple tracks can be connected as shown in FIG. 31. This embodiment assumes that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track having sample entry type 'v3c1' can reference atlas tile tracks having sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track may only contain common information, such as an atlas parameter set related to each referenced atlas tile track, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track with sample entry type 'bmcb' using track reference type 'vdmb', and a basemesh track can reference submesh tracks with sample entry type 'smc1' using track reference type 'bmcs'. A basemesh track can only contain common information, such as basemesh parameter sets related to each referenced submesh track, i.e., non-BMCL NAL unit data.Each atlas tile track can reference the displacement video track and attribute video track encoded with a video codec as track reference types 'vdmg' and 'vdma', respectively. In this embodiment, the atlas track of sample entry type v3c1 can reference the displacement video tracks and attribute tracks associated with each tile as reference types 'vdmg' and 'vdma', respectively, and the atlas tile tracks may not have separate track references.

[1189] In the case of this embodiment, tracks associated with each atlas tile may be grouped and signaled according to the VDMC tile component track grouping method.

[1190] In addition, in the case of this embodiment, a constraint may be applied that allows for direct referencing of related component tracks even when referencing the atlas track of sample entry type 'v3c1', i.e., the atlas tile track.

[1191] FIG. 32 illustrates a method of using a submesh track group as an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments.

[1192] We will explain assuming an example where Atlas Tile 1 is associated with Submesh 1 and Submesh 2, and Atlas Tile 2 is associated with Submesh 3.

[1193] Example of using a submesh track group, wherein a single atlas with multiple atlas tiles is composed of multiple tracks each including an atlas track, an atlas tile track, and multiple submesh tracks.

[1194] When a VDMC bitstream is composed of a single atlas, multiple atlas tiles, and multiple submeshes, and the atlas tile bitstream is encapsulated into separate atlas tile tracks and submesh tracks for storage and transmission, track references for multiple tracks can be connected using submesh track groups of submesh tracks as shown in FIG. 32. This embodiment assumes that atlas tile 1 is associated with submesh 1 and submesh 2, and atlas tile 2 is associated with submesh 3. A V3C atlas track having sample entry type 'v3c1' can reference atlas tile tracks having sample entry type 'v3t1' using track reference type 'v3ct'. An atlas track may only contain common information, such as an atlas parameter set related to each referenced atlas tile track, i.e., non-ACL NAL unit data. Additionally, an atlas track can reference a basemesh track with sample entry type 'bmcb' using track reference type 'vdmb', and a basemesh track can reference submesh tracks with sample entry type 'smc1' using track reference type 'bmcs'. A basemesh track can only contain common information, such as basemesh parameter sets related to each referenced submesh track, i.e., non-BMCL NAL unit data.Each atlas tile track can be referenced by track reference types 'v3vg' and 'v3va' for the displacement video track and attribute video track encoded with the video codec, respectively.

[1195] In the case of this embodiment, according to the submesh track grouping method, submesh tracks associated with each atlas tile can be signaled by track grouping them into track group type 'smtg'.

[1196] FIG. 33 is an example of a track reference for a single atlas and multiple submeshes having multiple atlas tiles according to embodiments, and illustrates a method of using a submesh track group.

[1197] In addition to FIG. 31, the reference and grouping relationships of each track can be configured as in FIG. 33.

[1198] Referring to SubmeshTrackGroupBox extends TrackGroupTypeBox('sutg') described in FIG. 26, the method and apparatus according to the embodiments can signal by configuring the SubmeshTrackGroupBox in a way that adds association information between atlas tiles and submeshes, rather than simply grouping submesh tracks as described above. The association between atlas tiles and submesh data is as described above. That is, the association relationship may exist as follows. An atlas tile may contain one or more mesh patch data, and one mesh patch data is identical to one submesh data. Here, mesh patch data or submesh data may be the minimum unit that a receiver can independently decode. The concept of the connection relationship between atlas tiles and submesh data is a signaling newly defined in V-DMC that did not exist in the existing V3C.

[1199] / track_group_id is inherited from TrackGroupTypeBox

[1200] unsigned int(16) num_tiles;

[1201] for(int i=0; i < num_tiles; i++) {

[1202] unsigned int(16) tile_id;

[1203] unsigned int(16) num_submeshes;

[1204] for(int j=0; j < num_submeshes; j++) {

[1205] unsigned int(16) submesh_id;

[1206] }

[1207] }

[1208] }

[1209] num_tiles represents the number of atlas tiles associated with this track group.

[1210] tile_id specifies the atlas tile ID of the atlas tile containing the patch associated with the submesh of this track group instance.

[1211] num_submeshes represents the number of submeshes associated with an atlas tile.

[1212] submesh_id is an identifier for the submesh of this track group instance. The value of submesh_id is equal to the value of the corresponding bmsi_submesh_id syntax element of bmesh_sub_mesh_information() defined in ISO / IEC 23090-29.

[1213] Referring to FIG. 27, using an atlas tile-based track reference and grouping scheme, the decoding method according to the embodiments can parse a file, obtain syntax information within a bitstream in the file, and decode mesh data.

[1214] A file receiver, for example, can receive V-DMC content files. That is, an atlas track of sample entry type 'v3c1' or 'v3gc' may contain two atlas tiles. A basemesh consists of three submeshs, and a basemesh track of sample entry type 'bmcb' may contain a submesh track of sample entry type 'smc1' containing submesh 1 and submesh 2, and a submesh track containing submesh 3.

[1215] The file parser parses each track included in the file and identifies that an atlas track with sample entry type 'v3c1' or 'v3cg' is an entry track. Subsequently, by parsing the track reference box included in the atlas track, it can identify the basemesh track, displacement track, and attribute track that the atlas track references. Additionally, by parsing the sample entries of the remaining tracks, it can identify the presence or absence of a V-DMC tile component group box with track_group_type 'vdtg' as described in Section 4.9.2 of this document, as well as information about the grouped V-DMC component tracks, namely the atlas ID, atlas tile, and the number and ID of associated submeshes.

[1216] FIG. 34 shows an example of encoding displacement and texture (attribute) composed of atlas tiles and submeshes according to embodiments into a video codec.

[1217] The bitstream packager can collect data corresponding to each atlas tile and configure it into a dynamic mesh basemesh bitstream that can be decoded. As shown in FIG. 34, in an embodiment illustrating the relationship between texture and displacement data related to a basemesh composed of three submeshes, mesh data can be decoded using the relationship between the tiles and submeshes.

[1218] The V-DMC decoder can selectively decode only the associated tracks for each tile. By acquiring information about the configuration as shown in Fig. 34 and utilizing data relationships, it can determine information about the tracks corresponding to a specific tile according to the user's viewport or use-case scenario, and can decode and render only the displacement track, attribute track, and submesh track associated with the selected atlas tile.

[1219] The method and apparatus according to the embodiments may further include an atlas tile-based multiple track group signaling scheme of dynamic mesh coding bitstream.

[1220] The method and apparatus according to the embodiments may further include and perform an atlas tile base track grouping step for multiple tracks of a V-DMC bitstream.

[1221] Track grouping according to the embodiments may include Option 1 and Option 2.

[1222] Option 1: Submesh track group

[1223] This is a method to indicate that each identical submesh track is the same basemesh when encapsulated by one or more submesh tracks. Refer to the aforementioned SubmeshTrackGroupBox extends TrackGroupTypeBox('sutg') syntax and description.

[1224] In addition, for V-DMC content containing one or more atlas data in this signaling, atlas id signaling can be added and defined as follows.

[1225] Option 2: Submesh track group

[1226] A submesh track may contain one or more submeshes, and these submeshes are associated with one or more atlas tiles included in one or more corresponding atlas tracks or atlas tile tracks. To represent the relationship between atlas tiles and associated submesh tracks, a track group SubMeshTrackGroupBox (extended to TrackGroupTypeBox) defined in ISO / IEC 14496-12 is defined.

[1227] Syntax

[1228] aligned(8) class SubMeshTrackGroupBox extends TrackGroupTypeBox('smtg') {

[1229] / track_group_id is inherited from TrackGroupTypeBox

[1230] unsigned int(8) num_tiles;

[1231] for(int i=0; i < num_tiles; i++) {

[1232] unsigned int(6) atlas_id;

[1233] bit(2) reserved = 0;

[1234] unsigned int(16) tile_id;

[1235] unsigned int(16) num_submeshes;

[1236] for(int j=0; j < num_submeshes; j++) {

[1237] unsigned int(16) submesh_id;

[1238] }

[1239] }

[1240] }

[1241] Semantics

[1242] num_tiles represents the number of atlas tiles associated with this track group.

[1243] atlas_id represents the atlas ID associated with tile_id.

[1244] tile_id specifies the atlas tile ID of the atlas tile associated with the submesh of this track group instance. The value of tile_id is equal to the value of the afti_tile_id syntax element of the atlas frame tile information defined in ISO / IEC FDIS 23090-5.

[1245] num_submeshes represents the number of submeshes associated with an atlas tile.

[1246] submesh_id is an identifier for a submesh of this track group instance. The value of submesh_id is equal to the value of the corresponding bmsi_submesh_id syntax element of bmesh_submesh_information() defined in ISO / IEC 23090-29:Annex H.

[1247] FIG. 35 shows an example of V3C (or VDMC) tile video component track grouping according to embodiments.

[1248] Option 2: VDMC Tile Component Track Grouping

[1249] The method according to the embodiments may further include a method of adding a submesh track included in V-DMC content by extending the V3C tile video component track grouping defined in the V3C codec (ISO / IEC 23090-10).

[1250] A V3C Tile Video Component Track Group is a track group that groups all tracks containing V3C video component information associated with an atlas tile set. This track group is used when an atlas contains two or more tiles and all atlas component tiles of that atlas are included in the corresponding V3C Atlas Track. An example of using V3C Tile Video Component Track Grouping for a single atlas track containing tiles 1 and 2 is shown in FIG. 35.

[1251] If a track has a TrackGroupTypeBox with track_group_type 'vtcg', it indicates that the track belongs to the V3C Video Component Track Group corresponding to the V3C Tile Video Component Group.

[1252] Tracks belonging to the same V3C tile video component group have the same track_group_id value for track_group_type 'vtcg', and the track_group_id of a track in one V3C tile video component track group is different from the track_group_id of a track in another V3C tile video component track group.

[1253] The predefined V3CtileVideoComponentGroupBox can only contain V3C video component tracks. It can be extended by adding the following to include V-DMC component tracks, i.e., submesh tracks.

[1254] Additionally, V3C tile video component track groups may include V3C non-video component tracks, such as submesh tracks, to support V-DMC content.

[1255] Syntax

[1256] aligned(8) class V3CTileVideoComponentGroupBox extends TrackGroupTypeBox('vtcg') {

[1257] unsigned int(8) num_tiles;

[1258] for (int i=0; i < num_tiles; i++) {

[1259] unsigned int(6) atlas_id;

[1260] bit(2) reserved = 0;

[1261] unsigned int(16) tile_id;

[1262] }

[1263] }

[1264] Semantics

[1265] num_tiles is the number of V3C atlas tiles associated with the track group.

[1266] atlas_id represents the atlas ID associated with tile_id.

[1267] tile_id is the ID of a V3C atlas tile. The value of tile_id is equal to the value of the afti_tile_id syntax element of the atlas frame tile information defined in ISO / IEC 23090-5.

[1268] Referring to FIG. 27, the file receiver can receive V-DMC content files. That is, the atlas track of sample entry type 'v3c1' or 'v3gc' may contain two or more atlases and two atlas tiles. The basemesh is composed of three submeshes, and the basemesh track of sample entry type 'bmcb' may contain a submesh track of sample entry type 'smc1' containing submesh 1 and submesh 2, and a submesh track containing submesh 3.

[1269] The file parser parses each track included in the file and identifies that an atlas track with sample entry type 'v3c1' or 'v3cg' is an entry track. Subsequently, by parsing the track reference box included in the atlas track, the basemesh track, displacement track, and attribute track referenced by the atlas track can be identified. Additionally, if an atlas track contains one or more atlas data, the relationships with the atlas, atlas tile, and submesh can be identified based on the information contained within the SubMeshTrackGroupBox defined in Section 4.9.

[1270] The bitstream packager can collect data corresponding to each atlas and atlas tile and configure it in the form of a dynamic mesh basemesh bitstream that can be decoded. The method according to the embodiments can decode mesh data by utilizing the relationship between texture and displacement data associated with a basemesh composed of three submeshes, as shown in FIG. 34.

[1271] The V-DMC decoder can selectively decode only the collected data, specifically the associated tracks for each atlas tile. Based on the aforementioned information, the receiver can determine the information regarding tracks corresponding to a specific tile according to the user's viewport or use-case scenario, and can decode and render only the displacement track, attribute track, and submesh track associated with the selected atlas and atlas tile.

[1272] FIG. 36 illustrates a encoding method according to embodiments.

[1273] The method according to the embodiments may include the step of encoding mesh data (S3600); and / or the step of encapsulating a file containing a bitstream containing mesh data (S3610); etc.

[1274] The step of encoding mesh data (S3600) may include encoding of the encoder in FIGS. 1 to 14 and FIG. 17, syntax and bitstream generation in FIGS. 15 to 16, etc.

[1275] The step (S3510) of encapsulating a file containing a bitstream containing mesh data may include creating reference relationships between files and tracks, such as FIGS. 18 to 26, FIGS. 28, FIGS. 29 to 34-35.

[1276] FIG. 36 The encoding method can be performed by an encoding device. The encoding device includes a memory; at least one processor connected to the memory; and the at least one processor may be configured to: encode mesh data; and encapsulate a file containing a bitstream containing mesh data.

[1277] The file may include: a first track containing atlas data for 2D mapping of objects for mesh data; a second track containing base mesh data for mesh data; a third track containing displacement data for mesh data; and a fourth track containing attribute data for mesh data.

[1278] An atlas is a collection of 2D bounding boxes and related information placed in a rectangular frame, corresponding to a volume in 3D space, and includes a list of metadata where volume data is rendered and corresponds to parts of the mesh surface in 3D space.

[1279] The atlas frame corresponds to a 2D rectangular array of atlas samples onto which patches (ISO / IEC 23090-5(4E):2025:3.91) are projected, additional patch-related information (ISO / IEC 23090-5(4E):2025:3.91), and a volume frame (ISO / IEC 23090-5(4E):2025:3.142), and corresponds to a mesh patch list, additional mesh patch-related information, and a volume frame (ISO / IEC 23090-5(4E):2025:3.142).

[1280] An atlas sample is a location in a rectangular frame onto which a patch associated with the atlas (ISO / IEC 23090-5(4E):2025:3.91) is projected, or an element of a list of mesh patches associated with the atlas.

[1281] An atlas tile is an independently decodingable rectangular area of ​​an atlas frame, consisting of geometry tiles, attribute tiles, or both, and has no dependency on other atlas tiles of the current frame.

[1282] An atlas track is a volumetric visual track containing an atlas bitstream in the case of a multi-track container.

[1283] An atlas tile track is a volumetric visual track containing a portion of an atlas bitstream corresponding to one or more tiles in the case of a multi-track container.

[1284] The embodiments further include a computer-readable storage medium that stores a bitstream generated by the method according to FIG. 36.

[1285] The embodiments further comprise a method comprising the steps of: acquiring a bitstream for mesh data, wherein the bitstream is generated based on the steps of: encoding base mesh data of the mesh data; encoding attribute data of the mesh data; encoding displacement data of the mesh data; and encoding atlas data of the mesh data; encapsulating a file containing the bitstream; and transmitting data containing the file.

[1286] FIG. 37 illustrates a decoding method according to embodiments.

[1287] The method according to the embodiments may include the step of decapsulating a file containing a bitstream containing mesh data (S3700); and / or the step of decoding the mesh data (S3710); etc.

[1288] The step (S3700) of decapsulating a file containing a bitstream containing mesh data may include operations such as obtaining the syntax and bitstream of FIGS. 15 to 16 based on the creation of reference relationships between files and tracks of FIGS. 18 to 26, FIGS. 28, FIGS. 29 to 34-35.

[1289] The step of decoding mesh data (S3610) may include operations such as decoding of the decoder in FIGS. 1 to 14 and FIG. 17.

[1290] In relation to the example of multiple track encapsulation such as FIG. 19, the file may include: a first track containing atlas data for 2D mapping of objects to mesh data; a second track containing base mesh data to mesh data; a third track containing displacement data to mesh data; and a fourth track containing attribute data to mesh data.

[1291] With respect to the atlas tile track and TrackReferenceTypeBox, the file further includes an atlas tile track containing atlas data for one or more tiles, and at least one of the first track containing atlas data or the second track containing base mesh data for mesh data may include track reference type information.

[1292] Regarding signaling relationships between component tracks (displacement tracks, attribute tracks, base mesh tracks, etc.) and atlas tracks, or signaling relationships between component tracks and atlas tile tracks, the relationship between component tracks including a second track containing base mesh data for mesh data, a third track containing displacement data for mesh data, and a fourth track containing attribute data for mesh data, and a first track or atlas tile track containing atlas data can be indicated based on track reference type information.

[1293] With respect to the example values ​​vdmb and vdmd, the vdmb of the reference type of the track reference type information may indicate that the referenced track includes a basemesh component, and the vdmd of the reference type may indicate that the referenced track includes an arithmetic-coded displacement component.

[1294] Regarding tile component track grouping, the first track containing atlas data may further include grouping information of mesh data components related to atlas tiles for atlas data for one or more tiles.

[1295] Regarding the tile component track grouping semantics (num_tiles, atlas_id, atlas_tile_id, num_submeshes), the grouping information may include at least one of information indicating the number of atlas tiles associated with the track group, an atlas ID associated with the tile ID, an atlas tile ID of the atlas tile that carries patches associated with the track group, information indicating the number of submeshes associated with the atlas tile, and an identifier of the submeshes.

[1296] The decoding method of FIG. 37 can be performed by a decoding device. The decoding device includes a memory; at least one processor connected to the memory; and the at least one processor may be configured to: decapsulate a file containing a bitstream containing mesh data; and decode the mesh data.

[1297] The method and apparatus according to the embodiments of FIGS. 35 to 36 provide the following technical effects.

[1298] A transmitter or receiver for providing mesh content services configures a V-DMC bitstream as described above and stores a file. It enables effective multiplexing of the V-DMC bitstream. It enables the transmission of metadata for data processing and rendering within the V-DMC bitstream into the file. A video-based dynamic mesh compression processing device, transmitter, receiver, mesh player, encoder, or decoder according to the embodiments of this document provide the effects described above.

[1299] In other words, the data representation method described above provides the effect of enabling efficient access to V-DMC bitstreams. A transmitter or receiver according to the embodiments of this document can efficiently store and transmit V-DMC bitstream files by using storage techniques and signaling to store the V-DMC bitstream into multiple tracks within a file. As described above, if information regarding basemesh data composed of submesh is provided at the file level, the receiver can efficiently manage available resources based on this information. Furthermore, by encapsulating each submesh data into a submesh track, partial access and decoding can be performed at the submesh level.

[1300] In addition, the aforementioned signaling method transmits one or more spatial regions and one or more scene objects and submesh-related linkage information that may be included therein, thereby enabling the receiver to provide services such as partial access based on spatial regions containing scene object information.

[1301] In the manner described above, a dynamic mesh bitstream composed of one or more submeshes can be encapsulated into multiple tracks. In this regard, encapsulation and decapsulation into submesh tracks associated with the basemesh track can be performed according to a newly defined sample entry type of the basemesh track, and receivers can perform the same parsing and decoding operations according to the constraints for each sample entry type as described above.

[1302] In the manner according to the embodiments, signaling of track reference relationships between each component can be performed when encapsulating each component constituting the V-DMC bitstream into multiple tracks. The receiver can perform efficient decoding and rendering of V-DMC content composed of one or more atlas tile tracks and / or one or more submesh tracks, for the submesh tracks associated with the atlas tile.

[1303] When encapsulating each component constituting the V-DMC bitstream into multiple tracks, signaling of the track reference relationships between each component can be performed. The receiver can efficiently decode and render the submesh tracks associated with the atlas tile for V-DMC content composed of one or more atlas tile tracks and / or one or more submesh tracks.

[1304] When encapsulating each component constituting the V-DMC bitstream into multiple tracks, signaling of track references and track grouping relationships between each component is possible. The receiver can efficiently decode and render V-DMC content composed of one or more atlases and / or atlas tile tracks and / or one or more submesh tracks, specifically for submesh tracks associated with a particular atlas and atlas tile.

[1305] The embodiments have been described in terms of methods and / or devices, and the description of the methods and the description of the devices may be applied complementarily.

[1306] Although the drawings have been described separately for the convenience of explanation, it is also possible to design a new embodiment by combining the embodiments described in each drawing. Furthermore, designing a computer-readable recording medium containing a program for executing the previously described embodiments, as required by a person skilled in the art, falls within the scope of the embodiments. The apparatus and method according to the embodiments are not limited to the configuration and method of the embodiments described above; rather, the embodiments may be configured by selectively combining all or part of each embodiment to allow for various modifications. Although preferred embodiments have been illustrated and described, the embodiments are not limited to the specific embodiments described above. It is not only possible for a person skilled in the art to make various modifications without departing from the essence of the embodiments claimed in the claims, but such modifications should not be understood individually from the technical concept or perspective of the embodiments.

[1307] Various components of the device of the embodiments may be implemented by hardware, software, firmware, or a combination thereof. Various components of the embodiments may be implemented as a single chip, for example, a single hardware circuit. Depending on the embodiments, the components according to the embodiments may each be implemented as separate chips. Depending on the embodiments, at least one of the components of the device according to the embodiments may be composed of one or more processors capable of executing one or more programs, and one or more programs may include instructions for performing or executing any one or more of the operations / methods according to the embodiments. Executable instructions for performing the methods / operations of the device according to the embodiments may be stored in non-transient CRMs or other computer program products configured to be executed by one or more processors, or may be stored in transient CRMs or other computer program products configured to be executed by one or more processors. Additionally, memory according to the embodiments may be used as a concept that includes not only volatile memory (e.g., RAM, etc.) but also non-volatile memory, flash memory, PROM, etc. In addition, it may also include implementation in the form of carrier waves, such as transmission over the Internet. Furthermore, processor-readable recording media are distributed across networked computer systems, allowing processor-readable code to be stored and executed in a distributed manner.

[1308] In this document, “ / ” and “,” are interpreted as “and / or.” For example, “A / B” is interpreted as “A and / or B,” and “A, B” is interpreted as “A and / or B.” Additionally, “A / B / C” means “at least one of A, B and / or C.” Also, “A, B, C” means “at least one of A, B and / or C.” Additionally, in this document, “or” is interpreted as “and / or.” For example, “A or B” may mean 1) “A” alone, 2) “B” alone, or 3) “A and B.” In other words, “or” in this document may mean “additionally or alternatively.”

[1309] Terms such as "first," "second," etc., may be used to describe various components of the embodiments. However, the interpretation of the various components according to the embodiments should not be limited by these terms. These terms are merely used to distinguish one component from another. For example, the first user input signal may be referred to as the second user input signal. Similarly, the second user input signal may be referred to as the first user input signal. The use of these terms should be interpreted as not departing from the scope of the various embodiments. Although the first user input signal and the second user input signal are both user input signals, they do not mean the same user input signals unless clearly indicated in the context.

[1310] The terms used to describe the embodiments are intended for the purpose of describing specific embodiments and are not intended to limit the embodiments. As used in the description of the embodiments and in the claims, the singular is intended to include the plural unless explicitly indicated in the context. Expressions of and / or are used to mean including all possible combinations between the terms. Expressions of include describe the presence of features, numbers, steps, elements, and / or components and do not imply the exclusion of additional features, numbers, steps, elements, and / or components. Conditional expressions such as "if" or "when" used to describe the embodiments are not limited to being optional. It is intended to be interpreted as "when a specific condition is satisfied," "when a related action is performed in response to a specific condition," or "when a related definition is interpreted."

[1311] Additionally, operations according to the embodiments described herein may be performed by a transmitting and receiving device including memory and / or a processor, depending on the embodiments. The memory may store programs for processing / controlling operations according to the embodiments, and the processor may control various operations described in this document. The processor may be referred to as a controller, etc. Operations in the embodiments may be performed by firmware, software, and / or a combination thereof, and the firmware, software, and / or a combination thereof may be stored in the processor or in memory.

[1312] Meanwhile, the operation according to the embodiments described above may be performed by a transmitting device and / or a receiving device according to the embodiments. The transmitting and receiving device may include a transmitting and receiving unit for transmitting and receiving media data, a memory for storing instructions (program code, algorithm, flowchart and / or data) for a process according to the embodiments, and a processor for controlling the operations of the transmitting and receiving devices.

[1313] The processor may be referred to as a controller, etc., and may correspond, for example, to hardware, software, and / or a combination thereof. The operation according to the embodiments described above may be performed by the processor. Additionally, the processor may be implemented as an encoder / decoder, etc., for the operation of the embodiments described above.

[1314] As described above, the relevant details have been explained in the best mode for carrying out the embodiments.

[1315] As described above, the embodiments may be applied wholly or partially to point cloud data transmission and reception devices and systems.

[1316] Those skilled in the art may make various changes or modifications to the embodiments within the scope of the embodiments.

[1317] The embodiments may include modifications / variations, and such modifications / variations do not exceed the scope of the claims and their equivalents.

Claims

1. A step of decapsulating a file containing a bitstream containing mesh data; and A step of decoding the above mesh data; comprising, Decryption method.

2. In Paragraph 1, The above file is: A first track including atlas data for 2D mapping of an object for the above mesh data; A second track including base mesh data for the above mesh data; A third track including displacement data for the above mesh data; and A fourth track including attribute data for the above mesh data; comprising, Decryption method.

3. In Paragraph 2, The above file further includes an atlas tile track containing atlas data for one or more tiles, and At least one of the first track including the atlas data or the second track including base mesh data for the mesh data includes track reference type information. Decryption method.

4. In Paragraph 3, The relationship between component tracks including a second track containing base mesh data for the mesh data, a third track containing displacement data for the mesh data, and a fourth track containing attribute data for the mesh data, and a first track containing the atlas data or the atlas tile track is indicated based on the track reference type information. Decryption method.

5. In Paragraph 4, The vdmb of the reference type in the above track reference type information indicates that the referenced track includes a basemesh component, and The vdmd of the above reference type indicates that the referenced track includes an arithmetic-coded displacement component. Decryption method.

6. In Paragraph 3, The first track containing the above atlas data is Further including grouping information of components of the mesh data related to the atlas tiles for the atlas data for the one or more of the above tiles, Decryption method.

7. In Paragraph 6, The above grouping information is information indicating the number of atlas tiles associated with a track group, Atlas ID associated with tile ID, Atlas tile ID of the atlas tile transmitting patches associated with the above track group, Information indicating the number of submeshes associated with the above atlas tile, including at least one identifier of the submesh, Decryption method.

8. Memory; At least one processor connected to the memory; comprising, wherein the at least one processor: Decapsulating a file containing a bitstream containing mesh data; and Configured to decode the above mesh data, Decoding device.

9. In Paragraph 8, The above file is: A first track including atlas data for 2D mapping of an object for the above mesh data; A second track including base mesh data for the above mesh data; A third track including displacement data for the above mesh data; and A fourth track including attribute data for the above mesh data; comprising, Decoding device.

10. Step of encoding mesh data; and A step of encapsulating a file containing a bitstream containing the above mesh data; comprising, Encoding method.

11. In Paragraph 10, The above file is: A first track including atlas data for 2D mapping of an object for the above mesh data; A second track including base mesh data for the above mesh data; A third track including displacement data for the above mesh data; and A fourth track including attribute data for the above mesh data; comprising, Encoding method.

12. Memory; At least one processor connected to the memory; comprising, wherein the at least one processor: Encoding mesh data; and Configured to encapsulate a file containing a bitstream containing the above mesh data, Encoding device.

13. In Paragraph 12, The above file is: A first track including atlas data for 2D mapping of an object for the above mesh data; A second track including base mesh data for the above mesh data; A third track including displacement data for the above mesh data; and A fourth track including attribute data for the above mesh data; comprising, Encoding device.

14. A computer-readable storage medium for storing a bitstream generated by the method according to paragraph 10.

15. Step of acquiring a bitstream for mesh data, The bitstream is generated based on the steps of: encoding base mesh data of the mesh data; encoding attribute data of the mesh data; encoding displacement data of the mesh data; and encoding atlas data for the mesh data; A method comprising the steps of: encapsulating a file containing the bitstream; and transmitting data containing the file.

Images