Method, device, and computer program for encoding or decoding volumetric data into or from a coded mesh bitstream comprising submeshes data

Abstract

The application relates to methods for encoding or decoding volumetric data including mesh data into or from a coded mesh bitstream, the mesh data including sub-meshes and defining a plurality of mesh frames. The methods comprise encoding or decoding the mesh data, to or from coding layer data units, for a considered time period, using coding layer data units grouped either per sub-mesh or per frame. A computer program product, a non-transitory computer-readable storage medium, a processing device for implementing these methods are also described.

Description

FIELD OF THE INVENTION The present invention relates to a method, a device, and a computer program for encoding or decoding 3D data, also called volumetric data into or from a coded mesh bitstream comprising submeshes data. BACKGROUND OF THE INVENTION Advancements in processing speed, enhanced storage capacity, and the availability of sophisticated algorithms for real-time photorealistic rendering from 3D data (or volumetric data) are driving a rapid upsurge in its applications across virtual and augmented reality, animated films, and the emerging metaverse, among others. The dominant format for volumetric data is based on point clouds, mesh data based on these point clouds, and textures providing the colour information. The mesh data may include any form of connectivity to describe or define surfaces based on the points of the point cloud. It may include in particular meshes of triangles. To address the need to swiftly exchange volumetric data, new methods are being defined to encode volumetric data in a compressed form, and then to decode them to restore the original volumetric data again. Part-5 of the international standard for Coded representation of immersive media (MPEG-I), called “Visual volumetric video-based coding (V3C) and videobased point cloud compression (V-PCC)” for instance specifies a generic mechanism for visual volumetric video coding, i.e. visual volumetric video-based coding. This standard is commonly denoted ISO / IEC 23090-5 or MPEG-I Part 5. In short, MPEG-I Part-5 defines V3C bitstreams. A V3C bitstream, (visual volumetric video-based coding bitstream) is a sequence of bits that forms the representation of coded volumetric frames and associated data forming one or more Coded V3C Sequences (CVSs). The generic mechanism may be used by applications targeting volumetric content, such as point clouds, immersive video with depth, mesh representations of visual volumetric frames, etc. MPEG-I Part-5 also comprises specific definitions dedicated to point clouds called V-PCC for Video-based Point Cloud Compression. A second part of MPEG-I, Part-12 (ISO / IEC 23090-12), consists in volumetric media encoded as MPEG Immersive Video (MIV) that can also be described within the generic V3C bitstream structure. Another part (Part-29, under definition) of the international standard for Coded representation of immersive media (MPEG-I), called “Video-based dynamic mesh coding (V-DMC)” specifies syntax, semantics, and decoding for video based dynamic mesh coding (V-DMC) methods. Furthermore, this Part-29 specifies processes that may be needed for reconstruction of visual volumetric media and may also include additional processes such as post decoding, pre-reconstruction, post reconstruction, and adaptation. In short Part-29 defines V-DMC bitstreams, which are one of the main examples of coded mesh bitstreams. The syntax and semantics for the Part-29 are specified as an extension of Part-5. While a V3C bitstream was already mixing several kinds of bitstreams or sub-bitstreams: for example, atlas sub-bitstream with video sub-bitstreams (for geometry, attributes and occupancy), V-DMC is defining additional types of bitstreams or sub-bitstreams, thus requiring modifications in the V3C bitstream description and additional parameters to expose for media players and decoders. As an example, V-DMC is considering two additional sub-bitstreams, respectively a basemesh sub-bitstream (or component) and a displacement sub-bitstream. The basemesh sub-bitstream is a simplified low-resolution approximation of the original mesh, and the displacement sub-bitstream provides displacement vectors, to refine the basemesh to better fit the original mesh. This enables to provide spatial / quality scalability to the encoded mesh. Encoding of the displacement sub-bitstream is specified either using any video codec (such as HEVC, WC for example) or arithmetic codec. For basemesh sub-bitstream, V-DMC specification introduces new bitstream format. This new bitstream format, as for video coding format such as HEVC or the atlas sub-bitstream used in V3C, also uses NAL (Network Abstraction Layer) units. High Level Syntax (HLS) structures or syntax structures such as base mesh sequence parameter sets (BMSPS), base mesh frame parameter sets (BMFPS), or a submesh layer raw byte sequence payload (RBSP) syntax structure representing the content of some of the NAL units of a V-DMC bitstream are also specified. Among these syntax structures, the submesh layer RBSP enables to segment a mesh into multiple smaller partitions, called submeshes. These submeshes can be decoded completely independently, providing partial decoding and spatial random access. Moreover, when constrained to use the same coding order and same references, it may also provide random access capability. Figure 7 illustrates the format of a CVS (Coded V3C Sequence) as specified in ISO / IEC 23090 Part-29. As shown in the upper part of this figure, such a CVS is composed of asetofV3C units, each described bya V3C unit header (or unit header), as represented by 700, 710, 720, or 730, followed by a V3C unit payload (or unit payload), as represented by 705, 715, 725, or 735. The V3C unit header contains an information indicating the type of the V3C unit payload. It enables to identify if the payload corresponds to a type of descriptive information, e.g., such as a V3C parameter set (V3C_VPS), or to compressed volumetric data (also called coding layer) or V3C sub-bitstream (or component), for example atlas data, basemesh data, displacement data or attribute data. In Figure 7, the first V3C unit (700, 705) may represent a V3C parameter set. V3C unit (710, 715) may represent atlas data component, V3C unit (720, 725) may correspond to basemesh data component and V3C unit (730, 735) may represent either displacement data or attribute data component, for example texture attribute. More V3C units may be present, to enable encoding for example both displacement and attribute data components or to provide other attribute data component information. Among the different components, the lower part of figure 7 shows in particular a basemesh data sub-bitstream 725, or more simply a basemesh sub-bitstream 725. The basemesh sub-bitstream 725 is composed of a set of NAL units (e.g. basemesh NAL units), each described by a NAL unit header (or NAL header), as represented by 750, 760, 770, or 780, followed by a NAL unit payload (or NAL payload), as represented by 755, 765, 775, or 785. The NAL unit header contains information indicating the type of the NAL unit payload, for example as a syntax element called bmesh_nal_unit_type. It enables to identify if the payload corresponds to a descriptive information such as basemesh sequence parameter set (NAL_BMSPS, also denoted BMSPS), basemesh frame parameter set (NAL_BMFPS, also denoted BMFPS) or to coded submesh layer unit, also called coded submesh layer NAL unit, basemesh coding layer or NAL_BMCL, also denoted BMCL. In the following description, NAL_BMCL or more simply BMCL is a generic name for coded submesh layer NAL units that belong to a NAL unit type class “BMCL”, in opposition to parameter sets, delimiters or supplemental enhancement information NAL units that belong to a NAL unit type class “non-BMCL”. A NAL_BMCL may correspond to different (several) NAL unit types NAL_xxx where xxx defines the type of the NAL unit as specified in the description of the basemesh sub-bitstream. It can be any NAL unit type of the NAL unit type class “BMCL”, for example NAL_IDR_N_LP or NAL_CRA as defined in ISO / IEC 23090 Part-29. When a basemesh is composed of several submeshes, the NAL_BMFPS contains information indicating the number of sub-meshes, for example as a syntax element called bmsi_num_submeshes_minus2, described in the basemesh sub-bitstream. In addition, each NAL_BMCL contains two pieces of information indicating respectively to which submesh the NAL_BMCL corresponds and the frame it corresponds to (in short, a frame identifier or a frame index or a frame count). For example, these two pieces of information can be represented as syntax elements called bmshjd and bmsh_mesh_frm_order_cnt_lsb respectively. For example, as illustrated in the lower part of Figure 7, assuming a basemesh sub-bitstream comprises one basemesh frame decomposed in N submeshes, the first NAL unit (750, 755) may represent a NAL_BMSPS or a NAL_BMFPS. The following NAL unit (760, 765) is the coded representation as a NAL_BMCL of a first submesh. The following NAL units (770, 775) ... to (780, 785) are NAL_BMCL representing respectively a second, a third submesh , ... up to a Nth submesh. Figure 7 illustrates a single coded basemesh frame. For this reason, the frame identifiers of all the NAL_BMCL have the same value. It should be noted however that a basemesh sub-bitstream may comprise a plurality of basemesh frames, each basemesh frame being then possibly decomposed in a plurality of submeshes. It should also be noted that more NAL units may be present, providing for example descriptive information like supplemental information NAL unit(s) (NAL_SEI) or additional NAL_BMCL for each submesh, providing temporal layer or enhancement layer. It may also be noted that the encoded data representing a submesh within a frame may be carried into several NAL_BMCL units for example to limit the size of the NAL units. For simplicity and clarity, on figure 7 the encoded data describing a submesh are illustrated by only one NAL_BMCL unit per submesh, but it should be understood that the encoded data of a submesh may be carried by a plurality of NAL_BMCL units even for a single frame. It should also be noted that NAL_BMSPS or NAL_BMFPS may appear only once in a basemesh sub-bitstream. In order to encode in a V3C bitstream basemesh data comprising a plurality of submeshes and defining a plurality of basemesh frames, the V3C-compliant or V-DMC compliant format described above proposes to organize the NAL_BMCL as follows. The organization of the coded NAL units is generally the same as the one shown on figure 7. However, the mesh data comprise NAL_BMCL for a plurality of submeshes for a plurality of basemesh frames. Therefore (as proposed by the test model for V-DMC called TMM6), all NAL_BMCL units of a first submesh in a basemesh sub-bitstream are stored first in the basemesh sub-bitstream; then, all NAL_BMCL units for a second submesh are stored in the basemesh sub-bitstream , then all the NAL_BMCL units for a third submesh, ... etc. For each submesh, the different NAL_BMCL units are ordered per frame index or frame count. Accordingly, the basemesh sub-bitstream exhibits a ‘frame-order first’ organization, which means that in the basemesh sub-bitstream, the NAL_BMCL are first grouped by frames order for one submesh. Incidentally, for the different groups of NAL_BMCL for a considered submesh, the BMCL are preferably ordered per submesh identifier. Such organization however has a few drawbacks. First, when the CVS has been encoded in this fashion, the calculation (be it for encoding or decoding) for the first volumetric frame, or in fact for any volumetric frame, can only be made once almost the whole sequence of volumetric frames has been received or is available, because normally all sub-meshes contribute to each frame. Therefore, this organization requires more memory storage. In addition, while this organization may seem convenient for encoding the submeshes data into a bitstream, it may actually be problematic for decoders reconstructing the full mesh or for ISOBMFF parsers performing multi track encapsulation entity or application processing the bitstream on a full mesh basis. Indeed, it may require many parsing operations and buffering into memory, for example for determining a sample of a basemesh track ( ) or for determining all the frames that compose a submesh sub-bitstream when storing a submesh in a dedicated sub-mesh track. In particular, to determine all the frames that compose a submesh sub-bitstream, this organization requires to parse all NAL headers to identify the start and end of the NAL_BMCL corresponding to each submesh. In the case of volumetric data comprising several sub-meshes, another possible organization for the bitstream is proposed by the V-DMC specification. Indeed, this specification supports the possibility to generate a bitstream with several contiguous CVS. Therefore, if the bitstream comprises several coded basemesh frames, it is possible to describe these multiple coded basemesh frames (whether or not they comprise a plurality of submeshes) as multiple CVS, each CVS starting with a V3C_VPS, according to the V3C specification (ISO / IEC 23090-5) However, this leads to have a less efficient bitstream due to repetition of the most part of the V3C_VPS. In addition, since the data related to the different frames are lodged in different CVS parts of the bitstream, any calculation which implies a plurality of frames is difficult to carry out. Consequently, encoding or decoding mesh data into bitstreams, in particular in the case of mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes may require more time, more computing power and may come therefore at a higher cost. This is obviously a major concern in the production and consumption of media files. Therefore, there is need for methods and devices which make it possible to reduce the time and the cost needed to encode or decode media files comprising mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes. SUMMARY OF THE INVENTION The present invention has been devised to address one or more of the foregoing concerns. It has appeared that these concerns may be mitigated by efficiently organizing the mesh data associated both to a frame and to a submesh within one or more coded submesh layer NAL units, which NAL units (also denoted data units) are called herein ‘NAL_BMCL’, in a basemesh sub-bitstream of a V3C bitstream. Indeed, when basemesh frames are segmented as several sub-meshes, there are different possible organizations or ordering of the corresponding NAL units. Advantageously, the organizations proposed below reduce the need of memory and processing time to determine the NAL units that belong to a same frame or to a same submesh. They also enable to use parallel processing of the submeshes. In some cases, as it will be explained below, additional signaling in the bitstream may be provided to facilitate the handling of the multiple frames (or samples) by the encoder, the decoder or more broadly any file generator or parser tasked to handle the bitstream encapsulated in a media file. The media file may be in particular a media file compliant with the ISO Base Media File Format (ISOBMFF). According to a first aspect of the invention, there is provided a method for encoding volumetric data into a coded mesh bitstream, in a processing device, the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes, the method comprising encoding the mesh data associated both to a frame and to a submesh within one or more coding layer data units; and encoding the mesh data so that, for a considered time period covering a plurality of frames: - the coding layer data units are grouped by submesh; each group for a considered submesh including the coding layer data units for the considered submesh for all the frames of said time period in which the considered submesh is present; and among the groups associated with the different submeshes, any two groups are separated from each other by a separator; or - the coding layer data units are grouped by frame, each group for a considered frame including the coding layer data units for at least the submesh(s) present, or all the submeshes, for the considered frame. During the encoding, the mesh data is usually encoded in at least one mesh bitstream (preferably a sub-bitstream in case the coded mesh bitstream is coded in compliance with the V3C specification). In most cases, the coded mesh bitstream defines at least two frames, each of which including each at least two submeshes. The above-defined method proposes two possibilities to organize the coding layer data units within the coded mesh bitstream. According to the first possibility, the coding layer data units are grouped by submesh in the coded mesh bitstream, ‘per-submesh groups’, and separators are provided to separate adjacent groups. Consequently, per- submesh retrieval of mesh data relative to specific submeshes is facilitated. According to the second possibility, the coding layer data units are grouped by frame in the coded mesh bitstream, in ‘per-frame groups’, for each frame, all coding layer data units related to each submesh form a group and the groups are separated from each other. Advantageously, by forming separated groups for the respective frames, per-frame retrieval of mesh data relative to specific frame or frames is facilitated. In some embodiment of the second alternative defined above, the coded mesh bitstream comprises a plurality of sub-bitstreams; and during the encoding step, each group for the respective submeshes composes a respective sub-bitstream of the coded mesh bitstream, each sub-bitstream being carried in a dedicated data unit, wherein said separator preferably is a header of the dedicated data unit. The coded mesh bitstream may for instance be a V3C compliant bitstream and the dedicated data unit a V3C unit. In these embodiments (in which per-frame groups of coding layer data units are constituted), the mesh data associated with different submeshes are therefore stored in different basemesh sub-bitstreams within a Coded V3C Sequence, thus facilitating the retrieval of either per-submesh or per-frame data. In some embodiments, the separator is a non-coding layer data unit. A noncoding layer data unit is typically a data unit which does not encode mesh data, and may comprise parameters describing or defining the content of the coding layer data units. In some embodiments, during the encoding step, for each submesh, inside each group, the coding layer data units relative to the different frames are encoded ordered by frame order within the group. In some embodiments, for each submesh, the coding layer data units related to the submesh are preferably recorded sequentially in the bitstream to form the group. The methods proposed above are defined for different possible organizations of the coding layer data units within the coded mesh bitstream. In some cases, an organization is chosen beforehand and fixed (for instance, imposed by a standard). In some other cases, some flexibility is allowed for the choice of the organization. To address these cases, in some embodiments, the bitstream is encoded with an indication for indicating, at least for the considered time period, whether the coding layer data units are grouped by submesh or the coding layer data units are grouped by frame. Said at least one indication can be for instance, if the coded mesh bitstream is V3C compliant, either in a parameter set-type V3C unit of the bitstream, or in a parameter-set-type NAL unit of a basemesh sub-bitstream. The indication can be for instance an indicator included in a V3C parameter set unit, the indicator defining whether the bitstream includes or not multiple basemesh sub-bitstreams, and indicating optionally the number of basemesh subbitstreams. In some variants of these embodiments, the indication further defines that the coding layer data units of distinct submeshes are stored as distinct sub-bitstreams carried in distinct dedicated data units, or defines that the coding layer data units of distinct submeshes are stored in a single sub-bitstream for the considered time period but are separated by a non-coding layer data unit. In some embodiments, the separator comprises an identifier of the submesh associated with the group of coding layer data units following the separator. To decode coded mesh bitstream which have been encoded using perframe groups to encode the coding layer data units, the following method is proposed. This method is a method for decoding a coded mesh bitstream in a processing device, the method comprising: retrieving a group or part of a group of coding layer data units; the coding layer data units of the coded mesh bitstream defining volumetric data encoded in the coded mesh bitstream; the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes; each coding layer data unit defining mesh data associated both to a frame and to a submesh; the group of coding layer data units including coding layer data units only for the sub-mesh(es) present in one frame, or all the sub-meshes for the frame; generating said one frame or part of said one frame based on the retrieved group or the retrieved part of the group. Preferably, over a portion of the coded mesh bitstream covering a time period, all the coding layer data units associated with frames concerning that time period are grouped in the coded mesh bitstream grouped by frame. On the other hand, to decode coded mesh bitstream which have been encoded using per-submesh groups to encode the coding layer data units, the following method is proposed. This method is a method for decoding a coded mesh bitstream, in a processing device, the method comprising: identifying a separator in the coded mesh bitstream; the separator separating two groups of coding layer data units; the coding layer data units of the coded mesh bitstream defining volumetric data encoded in the coded mesh bitstream; the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes; each coding layer data unit defining mesh data associated both to a frame and to a submesh; each of the two groups being defined for a time period and including coding layer data units only for a considered submesh, for all the frames in the time period in which the considered submesh is present; and retrieving one of said two groups of coding layer data units based on the separator; and generating at least one frame or part of one frame based on the retrieved coding layer data units. Preferably, all coding layer data units in the coded mesh bitstream are grouped by submesh, at least for said time period. The time period may be common to the two groups, or to all groups. Retrieving the group of coding layer data units can be done by first locating that group based on the separator, then retrieving the coded layer data units it contains. In some embodiments, the separator comprises an identifier of the submesh associated with the group of coding layer data units following the separator. In some embodiments, within at least one of said two groups, the coding layer data units are ordered by frame order. In some embodiments, the coded mesh bitstream comprises a plurality of subbitstreams; each of said sub-bitstreams including coding layer data units only for a considered submesh and being carried in a dedicated data unit, wherein said separator preferably is a header of the dedicated data unit. In particular, the coded mesh bitstream may be a V3C compliant bitstream and the dedicated data units may be V3C units. In some embodiments, in the case where coding layer data units are grouped by submesh, said separator may preferably be a non-coding layer data unit. In order to decode coded mesh bitstreams in which different organizations may be used for the coding layer data units, the following method is proposed. This method is a method for decoding a coded mesh bitstream in a processing device, which comprises: identifying an organization of coding layer data units encoded in the coded mesh bitstream, the coding layer data units defining volumetric data encoded in the coded mesh bitstream; the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes; each coding layer data unit defining mesh data associated both to a frame and to a submesh; the organization defining at least whether, at least for a considered time period covering a plurality of frames, the coding layer data units are grouped: - by submesh; each group for a considered submesh including the coding layer data units for all the frames of said time period in which the considered submesh is present; and among the groups associated with the different submeshes, any two groups are separated from each other by a separator; or - by frame; each group for a considered frame including the coding layer data units for at least the sub-mesh(s) present, or all the sub-meshes, for the considered frame. retrieving one or more coding layer data units based on the identified organization; and generating at least one frame or part of a frame (e.g. including only one or more sub-meshes) based on the retrieved coding layer data units. In some embodiments, the determined organization further defines in which order the coding layer data units are ordered inside the groups, either relative to the sub-meshes or to the frames. In some embodiments, the organization of the coding layer data units is determined based on one or more indications indicating whether, at least for the considered time period, the coding layer data units are grouped by submesh or by frame. As an alternative, the organization can be identified by parsing the first coding layer data units. In the different methods proposed herein, the coded mesh bitstream may be in particular a V3C compliant bitstream. In the different methods proposed herein, the mesh data may be encoded in at least one mesh sub-bitstream, preferably in at least one basemesh sub-bitstream. A basemesh sub-bitstream describes a basemesh which is a simplified low-resolution approximation of an original mesh. According to other aspects of the invention, there is provided a processing device comprising a processing unit configured for carrying out each step of the methods described above. The other aspects of the present disclosure have optional features and advantages similar to the first and second above-mentioned aspects. At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium. Since the present invention can be implemented in software, the present invention can be embodied as computer-readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid-state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal. BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the disclosure will become apparent from the following description of non-limiting exemplary embodiments, with reference to the appended drawings, in which: Figure 1 illustrates a method to select and to organize a basemesh sub-bitstream according to the different submesh NAL unit organizations. Figure 2 illustrates a method to determine basemesh samples depending of coded submesh NAL unit organization. Figure 3 illustrates a first coded submesh NAL unit organization. Figure 4 illustrates a second coded submesh NAL unit organization. Figure 5 illustrates a third coded submesh NAL unit organization. Figure 6 is a schematic block diagram of a computing device for implementation of the method. Figure 7 illustrates a basemesh sub-bitstream and coding layer data units format according to Test Model 6 for V-DMC specification. DETAILED DESCRIPTION OF EMBODIMENTS OF THE DISCLOSURE Several encoding and decoding methods according to the present disclosure are now going to be described in relation with the figures. These methods are provided respectively to encode or to decode coded mesh bitstreams, such as for instance V3C-compliant bitstreams (V3C bitstreams). The structure of (that is, the different data constituting) a V3C bitstream has been described above in relation with figure 7 in the case where the bitstream comprises data, in particular volumetric data, of a single frame. As explained above, the methods according to the present disclosure address the case where the bitstream comprises volumetric data encoded as a basemesh with plurality of submeshes and which forms a plurality, also called a sequence, of volumetric frames. Figure 1 describes methods for encoding volumetric data into a coded mesh bitstream, in the present case, a V-DMC compliant bitstream, in a processing device according to the present disclosure. The volumetric data considered herein include mesh data, and more precisely, mesh data forming a plurality of mesh frames partitioned into a plurality of submeshes. At least two frames include each at least two submeshes. As known per se, the coded mesh bitstream is composed of Coded V3C Sequences, or CVSs. Inside each CVS, the mesh data are encoded in mesh bitstreams; more precisely, in the present example, in sub-bitstreams, the coded mesh bitstream being compliant with the V3C specification. In the coded mesh bitstream, the mesh data are encoded inside coding layer data units. Each coding layer data unit is associated both with a frame and with a submesh. The different mesh frames are defined for different time points covering a certain time period. According to the method the mesh data are encoded so that, at least for that period, the coding layer data units are grouped either by submesh, or they are grouped by frame. In the first case, each group for a considered submesh includes the coding layer data units for at least all the frames of said period in which the considered submesh is present, and among the groups associated with the different submeshes, any two adjacent groups are separated from each other by a separator. On the other hand, in the second case, each group of coding layer data units for a considered frame includes the coding layer data units for at least the sub-mesh(s) present, or all the sub-meshes, for the considered frame. The exemplary encoding method shown on Figure 1 advantageously makes it possible to encode a coded mesh bitstream, e.g. a Visual Volumetric Video-based Coding (V3C) compliant bitstream or a Video-based Dynamic Mesh Coding (V-DMC) compliant bitstream, according to different organizations described herein, so as to optimize the encoding and / or the decoding of the volumetric data in the coded mesh bitstream. This method is performed by a processing device, that is, a volumetric encoder, to generate a V3C or V-DMC bitstream in which the coding layer data units are organized as described in any one of the embodiments described herein. In an initial step (not represented), the settings of the encoding method are stored in the encoder. These settings or parameters include in particular the values of the parameters defining the organization of the coding layer data units inside the coded mesh bitstream. They may further include the number of submeshes used to encode the original mesh sequence. These settings may be predefined, or may be set by a user or a program. Different settings may be chosen to implement the encoding method. In some embodiments, the organization of the coding layer data units describing the mesh data is constrained by fixed rules (for example mandated by V-DMC specification). In this case the settings defining this organization may be stored permanently in the memory of the encoder (ROM 606 on Fig.6) as the default encoding organization. In other embodiments, a plurality of organizations are possible, which gives some flexibility to the encoder to execute the encoding method. In these embodiments, to allow the encoder to adequately select the right organization, the parameter setting operation is performed before executing the encoding method, for instance through a user interface (616 on Fig.6). After the optional parameter setting step has been executed, the steps described by Figure 1 are performed for each CVS to encode the original volumetric data. At step 100, the volumetric data representing the original mesh is obtained (acquired). At step 105, the encoder generates the different payloads according to the V3C or V-DMC specification. In the present exemple, for each mesh a basemesh is calculated in order to compress the mesh data. Accordingly the encoding method actually is applied to the basemesh rather than to the original mesh. It should be understood that the methods according to the present disclosure may be applied directly to the original meshes, or to meshes derived from the original meshes, for instance low-resolution version of the original meshes, etc. The compressed payload data for all the sub-bitstreams (e.g. for the basemesh, displacement, atlas and attribute sub-bitstreams) are obtained at step 105. For example, the encoder may use HEVC (or VVC) codec format for an attribute sub-bitstream and / or displacement sub-bitstream and generate syntax element for descriptive payload part, also denoted V3C parameter sets, such as V3C_VPS. For atlas and basemesh sub-bitstreams, it generates different NAL units (Network Abstraction Layer units), such as for example NAL_ BMSPS, NAL_BMFPS or NAL_BMCL data units (NAL_BMCL data unit is synonym of coding layer data units). During this step, the mesh data associated both to a frame and to a submesh are encoded within one or more coding layer data units. Consequently, when the mesh (the basemesh) is divided into several submeshes, the mesh data defining the different sub-meshes are encoded respectively into corresponding coding layer data units for the different sub-meshes. Then in step 110, the encoder checks whether fixed (or predetermined) rules are to be followed for the organization of the coding layer data units. As an alternative, when the organization of the coding layer data units defining the mesh data is predetermined, step 110 is skipped. When at step 110 the encoder determines that a fixed rule for coded submesh coding layer data units organization is used (for instance a fixed rule mandated by the V-DMC specification), then step 115 is the next step to be performed. In that case no additional syntax element either in V3C_VPS or NAL_BMSPS or NAL_BMFPS is added. On the contrary, if step 110 corresponds to a selection of a specific organization or ordering of the coding layer data units among a plurality of possible organizations or ordering, step 150 may be executed. In particular, in some embodiments in which the organization can be detected by an initial analysis of the bitstream by the decoder, step 150 may be omitted. At step 150, an indication defining whether the coding layer data units of the mesh data are grouped per-frame or per-submesh within the at least one basemesh sub-bitstream is added in the bitstream. This indication (or indications) constitutes signaling information which is added as a syntax element, either in the V3C bitstream or in a sub-bitstream thereof, for instance in a parameter set either of a V3C unit, e.g. in V3C_VPS, or of a NAL unit, e.g. in NAL_BMSPS_or NAL_BMFPS. The added syntax element indicates the organization or ordering to use for the coding layer data units when several sub-meshes are described by the basemesh sub-bitstream. Then, the encoder successively processes the compressed data of the different sub-bitstreams which have been obtained at step 105. The sub-bitstreams are processed successively. For each sub-bitstream, at step 115 the encoder checks if the current V3C unit to generate corresponds to a mesh sub-bitstream. If the data from the sub-bitstream currently processed corresponds to a V3C parameter set payload or to any other sub-bitstream different than a mesh subbitstream, the corresponding V3C unit is / are added to the V3C bitstream, for example by adding the V3C unit header identifying the V3C unit type in front of the payload provided. If the payload corresponds to a mesh sub-bitstream (step 115 positive), in step 120, depending on the organization to encode the coding layer data units, the algorithm continues at step 125 or 130. It is thus selected whether, during encoding, the coding layer data units are to be grouped either per frame (step 125, described in relation with figure 3) or per submesh (step 130, described in relation with figures 4 and 5). Grouping the coding layer data units by submesh means that the coding layer data units defining the different sub-meshes are first grouped into groups where each group includes the mesh data for a considered sub-mesh, over all the frames (at least over a considered period). Then, inside any group so constituted for a given submesh, the coding layer data units can be ordered for instance by frame order. By contrast, grouping the coding layer data units by frame means that the coding layer data units defining the different sub-meshes are first grouped into groups where each group includes the mesh data for a considered frame (at a specific time point), across all the sub-meshes, or at least all the submeshes present in the considered frame. Inside any group so constituted for a given frame, the mesh data can be ordered in any relevant order, for instance by submesh in any relevant order. With other words, the different organizations may also be considered as follows: - frame-order first “organization, where for a given submesh its corresponding NAL units appear in their increasing frame order, and all frame-ordered NAL units of other submeshes appear in the increasing order of their submesh identifier (as described e.g. in Figure 4 or 5). - a “submesh-order first” organization, where for a given frame all NAL units appear first in their submesh order, and then all submesh-ordered NAL units of all following frames appear in the order of their frame count (as described e.g. in Figure 3) If step 120 is positive, at step 125, the coding layer data units (‘CLDUs’) are grouped ‘per frame’. Accordingly at step 125 the encoder organizes the basemesh sub-bitstream by grouping all the coding layer data units of the different submeshes in their order of submeshes for the first frame, then repeats the same operation for each of the following frames. For each frame, within the group of coding layer data units describing the respective sub-meshes at the considered frame, the coding layer data units are ordered respecting the order of the submeshes present in the frame, either in an increasing or decreasing order of an identifier representing the submeshes. As an alternative, the different groups of coding layer data units corresponding to the different sub-meshes inside a per-frame group may be ordered based on a spatially-related organization, for instance following an order relation of the submeshes within a 3D coordinate system. Optionally, a NAL submesh delimiter, in particular a NAL submesh delimiter such as e.g. NAL_SMD or NAL_BMSD may be inserted between successive sub-groups of coding layer data units all associated with the same submesh, in order to delimit the coding layer data units associated with distinct submeshes. Optionally, an Access Unit delimiter (NAL_AUD) may be inserted between adjacent sub-groups of coding layer data units belonging to a same per-group frame. If step 120 is negative, it is concluded that the coding layer data units have to be grouped per submesh. At step 130 the encoder then checks if the coding layer data units organization (either predefined, according to a fixed rule or selected by a user) requires that a single V3C unit be used for each per-submesh group. If step 130 is positive, the coding layer data units will have to be organized (or stored in the bitstream) as described in Figure 5; the algorithm continues at step 140. At step 140, the encoder generates the coded mesh bitstream by organizing the V3C payload of the V3C_BMD, as follow: First add optional NAL parameter set units (NAL_BMSPS, then NAL_BMFPS if any), Followed for each submeshes (i) in the order of the submeshes (e.g. order of the bmsh_id): by a NAL submesh delimiter (NAL_SMD or NAL_BMSD), optional if only one submesh is described, by all NAL_BMCL units corresponding to the submesh i for all the frames of the CVS, in the order of the frame. If step 130 is negative, corresponding to coding layer data units organization described in Figure 4, then step 135 is executed. This step creates N V3C_BMD units, each describing one of the N submeshes, by aggregating all NAL_BMCL units corresponding to the submesh i for all the frames of the CVS in the order of the frame. After each of the steps (125, 135, 140), one or more V3C units corresponding to the basemesh sub-bitstream are therefore added. At step 145, the V3C units are written into the coded mesh bitstream. In some embodiments, an ISOBMFF reader or parser may reconstruct a V-DMC bitstream from an ISOBMFF file containing a volumetric bitstream with a NAL unit organization for the basemesh bitstream that is different than the volumetric bitstream encapsulation in the media file. In that case, in an initial reconstruction step, the media file reader selects the organization of the coded submesh NAL, based on the track file organization or based on predetermined settings or based on the presence of specific indication in the V-DMC bitstream that would have been stored in the track description (e.g. indication of a NAL unit order for the submesh or presence of specific NAL units acting as submesh delimiters). Then, it generates the basemesh sub-bitstream according to the selected basemesh sub-bitstream organization. It may signal or update the selected organization in one of the NAL units of the reconstructed. . As a result, the parser can either maintain the same organization as the original V3C bitstream or may transform basemesh sub-bitstream from submesh-order first organization to frame-order first organization^ vice-versa). In a variant of these embodiments, when ISOBMFF writer encapsulates the V-DMC bitstream, it embeds in the track description, an additional metadata information to indicate the ‘preferred’ or ‘recommended’ or supported basemesh sub-bitstream organization. For example, as a parameter of a decoder configuration box of the track carrying the base mesh or submesh frames. This parameter may take that indicate the organization: one equal to 0, it may indicate a submesh-order first organization and when equal to 1 a frame-order first organization. This parameter may be coded on at least one bit Figure 2 illustrates a method for decoding a coded mesh bitstream, in a processing device. For instance, the coded mesh bitstream may be a Visual Volumetric Videobased Coding (V3C) compliant bitstream or a Video-based Dynamic Mesh Coding (V-DMC) compliant bitstream. The main steps of this method are the following: - receiving and identifying mesh sub-bitstreams within the coded mesh bitstream; - identifying an organization of the coding layer data units encoded in the identified mesh sub-bitstreams (unless the organization has been acquired beforehand); - retrieving coding layer data units (NAL_BMCL) of at least for one frame or part of a frame from the identified at least one mesh sub-bitstream; - generating at least one sample, or frame (mesh frame) or a part of a sample, or frame, based on the retrieved coding layer data units. Accordingly, this method makes it possible to determine mesh samples (that is, volumetric samples or frames). In the embodiment presented on Figure 2, the frames (in this example, basemesh frames) are calculated depending on the organization of the coding layer data units. This decoding method is implemented for example in a processing device, e.g., such as a V-DMC decoder to display video based dynamic mesh coded bitstream on a screen or a subset of such bitstream (for example only parts corresponding to a subset of submeshes). It may also be used in an V3C unit parser within an encapsulation module for the carriage of a V-DMC bitstream into a dedicated basemesh track (storing and aggregating all coding layer data units) or into several tracks (one track per submesh or tracks for subsets of submeshes, for example a set of submeshes corresponding to an atlas tile, or to a specific area or viewpoint in a 3D scene). The steps of the decoding method are performed iteratively on each V3C unit of the V3C bitstream. This makes it possible to decode successively all the CVSs of the V3C bitstream. For each CVS, the steps described below are carried out. The same process, which is illustrated by figure 2, is carried out successively for each V3C unit contained in the CVS. In a first step 200, the V3C unit (the next V3C unit of the V3C units constituting the CVS) is obtained from the V3C bitstream. This step comprises for example using V3C sample stream format as specified in ISO / IEC 23090 Part-5, and receiving a memory block of size ssvu_v3c_unit_size corresponding to the V3C unit. Then at step 205, the decoder determines the unit type of the V3C unit. The V3C unit may be a parameter-set-type V3C unit or a sub-bitstream-type V3C unit. This determination is performed by parsing the memory block and extracting from the v3c_unit_header syntax, the information coding the vuh_unit_type for the different V3C units. Accordingly, among the V3C unit types, in that step the parser determines if the considered V3C unit has a vuh_unit_type value indicating a V3C parameter set unit (V3C_VPS) or a V3C unit sub-bitstream. A V3C unit may contain a sub-bitstream of several types, such as an Atlas sub-bitstream (V3C_AD), a basemesh sub-bitstream (V3C_BMD), an attribute data sub-bitstream (V3C_AVD) or a displacement sub-bitstream (V3C_DIS or V3C_GVD). For example, as specified in ISO / IEC 23090 Part-5, the value of vuh_unit_type equals 0 for a V3C_VPS, equals 4 for V3C_AVD and 7 for V3C_BMD. For displacement bitstream it may use a vuh_unit_type equal to 3 (V3C_GVD), when encoded as a video sub-bitstream or a new value among the reserved values for extension (for example vuh_unit_type=8 for V3C_DIS). Once the V3C unit type is determined, at step 205 the decoder further checks if the V3C unit corresponds to a V3C parameter set unit. When test 205 is negative, at step 210 the decoder checks if the sub-bitstream contained in the V3C unit corresponds to a mesh sub-bitstream (for example V3C_BMD, or any other value indicating a mesh sub-bitstream). When test 210 is negative, it is determined that the sub-bitstream contained in the V3C unit is either an atlas sub-bitstream, either an attribute sub-bitstream or a displacement sub-bitstream or any other sub-bitstream that can be determined from a pre-defined V3C unit type, except a basemesh sub-bitstream type. Then, at step 230 the decoder determines the number of samples and the content of each sample (frame) contained in the corresponding sub-bitstream as specified by the format used to encode the sub-bitstream. For example, samples of an attribute sub-bitstream encoded using HEVC codec (or WC codec) are determined according to ISO / IEC 14496-15 specification. When it is determined in step 205 that the V3C unit is a parameter set (e.g., of type V3C_VPS), step 215 is performed. At step 215, the parser determines how the coding layer data units (or BMCL) are organized. The outcome of this step depends on the encoding method executed to organize the coding layer data units (Figure 1). If the organization of the coding layer data units is fixed or predefined, during step 215 the organization of the V3C unit does not have to be determined (in this case, step 215 may be skipped). Otherwise, when a plurality of organizations are possible to store the coding layer data units (BMCL) in the V3C unit, the organization selected for the V3C unit is determined at step 215. It may either be determined by a user via a user interface, or may be retrieved as parameter(s) of a parameter set. This or these parameter(s) can be retrieved for instance from a the V3C parameter set unit. When it is determined in step 210 that the V3C unit corresponds to a mesh sub-bitstream (V3C_BMD), step 220 may be performed to determine the coded submesh NAL unit organization. This step is dependent on the embodiment selected for the coded submesh NAL unit organization. In particular, if it has been decided to store the parameters defining the organization of the BMCL in a parameter set of the V3C unit itself, then at step 220 the organization is determined by parsing this parameter set. The organization may either consist in fixed rule(s) to determine the basemesh samples based on basemesh NAL unit syntax element, or in additional syntax element(s) in V3C bitstream, or / and in V3C unit or / and in basemesh NAL units (such as NAL_BMSPS, NAL_BMFPS). In other words, depending on whether the coded submesh NAL unit organization is implicit due to fixed rules or / and in indication in the bitstream provided by an encoder, step 220 may be present or optional. Then at step 225, the decoder determines the samples (or frames), or parts of samples, which can be calculated (that is, decoded) at this stage. This / these sample(s) or parts of sample(s) are based on the mesh data contained in the already received coding layer data units. In this purpose, based on the organization determined at step 220, the decoder determines the number of samples and the content of each sample which can be decoded at this stage, based on the sub-bitstream(s). When several submeshes are present in the basemesh sub-bitstream, in order to decode a sample, the decoder first checks whether all NAL_BMCL submesh units corresponding to this sample are stored in the sample. As for step 215 (or 220), this step depends on the organization of the coding layer data units. At step 225, the decoder determines the number of submeshes and the coding layer data units to store in each sample by method adapted to the coded submesh NAL unit organization, using additional V3C NAL units, and / or modified V3C Unit syntax element (such as V3C_VPS), and / or additional or modified basemesh NAL unit. Step 225 (as well as steps 215 or 220) will now be described in more details for different types of organizations which can be chosen to encode the coded submesh NAL unit organization. In relation with figures 3 to 6, various possibilities for organizing coding layer data units within a CVS will now be presented. In each of these cases, it is supposed that the basemesh data encoded in the CVS describe mesh data partitioned into N sub-meshes and forming M volumetric frames. In these figures, while only one coding layer data unit is shown for a considered submesh, it should be understood that two or more coding layer data unit may be used to encode the mesh data for a considered submesh, for a certain frame. Figure 3 illustrates a first possibility for organizing coding layer data units within a CVS. In this embodiment, all the basemesh data for a time period (at least of a considered basemesh) are stored in the same V3C unit 325, shown on figure 3, which accordingly is a basemesh sub-bitstream. Basemesh sub-bitstream 325 is identical to the basemesh sub-bitstream 725 shown on figure 7 except for the aspects presented below. The fundamental difference is that the inner organization of the sub-bitstream 325 is different from the organization of the sub-bitstream 725 shown on figure 7. The individual NAL units composing the sub-bitstream 325 of figure 3 are essentially the same as those of the sub-bitstream 725 of figure 7. However, importantly, the order in which these NAL units, more precisely, the coding layer data units are stored in the sub-bitstream 325 is different: In the sub-bitstream 325, the coding layer data units are grouped per frame (frame #1, frame #2,... frame #M). Therefore, the sub-bitstream 325 of the present example comprises M groups, each group corresponding to one of the frames #1 to #M encoded in the sub-bitstream; each group includes a variable number of coding layer data units (CLDUs) comprised between 1 and N, each CLDU corresponding to one of the N submeshes (submesh #1, submesh #2,... submesh #N). Accordingly in this case (in contrast with the organization shown on figure 7 extended to a multi-frame seting), the organization of the coding layer data units is fixed and requires that coding layer data units are grouped per frame, then inside each group by sub-mesh order. This organization normally applies to all the basemesh sub-bitstreams of the CVS. In detail, the sequence of NAL units composing sub-bitstream 325, which is similar (except for the order) to the sequence of NAL units composing sub-bitstream 725 of figure 7, is the following: The first NAL unit (containing 300 and 305) of sub-bitstream 325 represents a parameter set of type NAL_BMSPS and / or NAL_BMFPS, that may be present in the basemesh sub-bitstream (or V3C_BMD unit). Then for the first frame #1 of the CVS, the sub-bitstream comprises a group of up to N basemesh NAL units (for example the one containing 310-1, 315-1) corresponding successively to the coded submesh data of submesh 1, the coded submesh data of submesh 2, etc., until the NAL units containing 320-1 and 325-1 for sub-mesh #N (in the case where all the submeshes are present for frame #1). In this group, the coded submesh data for the different submeshes are stored in the order of the submesh identifiers. Examples of order may be in an increasing or decreasing order. As another example, the submeshes may be ordered according to a spatially-related organization or order of the submeshes within a 3D coordinate system. Then, for the second frame #2 of the CVS, the sub-bitstream also comprises a group of up to N basemesh NAL units defined as the coded NAL units of frame #1, but now for frame #2. Then, from the third frame up to the Mth frame of the CVS, other groups of up to N basemesh NAL units (310-M, 315-M) corresponding to the coded submesh data of submesh 1 and (320-M, 325-M) for the coded submesh data of submesh N are included in the basemesh sub-bitstream. To encode such a basemesh sub-bitstream, the following basemesh NAL syntax elements defined in Part-9 Annex H may be used. A basemesh NAL unit is defined by structure bmesh_nal_unit, composed of a basemesh NAL unit header (bmesh_nal_unit_header represented for example in 300 or 310-1), followed by a basemesh NAL unit payload (rbsp_byte or RBSP represented for example in 305 or 315-1). RBSP stands for a Raw Byte Sequence Payload and consists in a sequence of bytes that is either empty or has the form of a string of data bits containing syntax elements followed by a bit equal to 1 and zero or more subsequent bits equal to 0 to result in byte alignment. The bmesh_nal_unit_header contains bmesh_nal_unit_type information, that specifies the type of the RBSP data structure contained in the basemesh NAL unit, and identifies if the basemesh NAL unit contains descriptive information of the basemesh sub-bitstream (such as sequence parameter set (NAL_BMSPS) or frame parameter set (NAL_BMFPS)) or data representative of the coded data, such as for coding layer data units. Moreover, for all coded submesh layer NAL units, the NAL payload is further described by a bmesh_submesh_layer_rbsp() data structure, composed of a bmesh_submesh_header part for descriptive data, followed by a bmesh_submesh_data_unit, for coded data. Among other information described in the bmesh_submesh_header, bmshjd enables to identify one submesh and bmsh_mesh_frm_order_cnt_lsb enables to determine the current frame (sample) encoded. To guarantee that the basemesh sub-bitstream 325 is organized as shown on Figure 3, the following fixed rules are defined for the NAL units composing a basemesh sub-bitstream: The first V3C_BMD unit of a CVS must start with a NAL_BMSPS, followed by a NAL_BMFPS Coded base mesh layer are stored first by their submesh ID, bmsh_id for a same frame count, then by the frame count obtained from the ordered bmsh_mesh_frm_order_cnt_lsb In other words, such rules may be defined as constraints in the Part-29, using naming and syntax as defined in Part 29, by: First defining an access unit, as: An access unit consists of one coded basemesh frame with nal_layer_id equal to 0 and a unique value of bmsh_mesh_frm_order_cnt_lsb, zero or more coded basemesh frame with nal_layer_id greater than 0 and same unique value of bmsh_mesh_frm_order_cnt_lsb, and zero or more non-BMCL NAL units. Then, describing order of NAL units of basemesh sub-bitstream, that set rules to have submesh-order first organization, as follow: Each BMCL NAL unit is part of a coded basemesh frame. The order of the BMCL NAL units within a coded basemesh frame is constrained as follows: - The first BMCL NAL unit of the coded basemesh frame shall have bmshjd equal to FirstSubmeshlD. - The submeshes of a coded basemesh frame shall be in increasing order of their bmshjd values. The first access unit in the bitstream starts with the first NAL unit of the bitstream. Let firstBIAFrmNalUnit be the first BMCL NAL unit of a coded basemesh frame with naljayerjd equal to 0. The first of any of the following NAL units preceding firstBIAFrmNalUnit and succeeding the last BMCL NAL unit preceding firstBIAFrmNalUnit, if any, specifies the start of a new access unit: - access unit delimiter or V3C access unit delimiter NAL unit with naljayerjd equal to 0 (when present), - BMSPS NAL unit with naljayerjd equal to 0 (when present), - BMFPS NAL unit with naljayerjd equal to 0 (when present), - Prefix SEI NAL unit with naljayerjd equal to 0 (when present), - NAL units with nal_unitjype in the range of NAL_RSV_NBMCL_40..NAL_RSV_NBMCL_44 with naljayerjd equal to 0 (when present), - NAL units with nal_unitjype in the range of NAL_UNSPEC_45..NAL_UNSPEC_63 with naljayerjd equal to 0 (when present). When there is none of the above NAL units preceding firstBIAFrmNalUnit and succeeding the last BMCL NAL preceding firstBIAFrmNalUnit, if any, firstBIAFrmNalUnit starts a new access unit. Let firstFrmCount be the first frame order count of the first access unit for a basemesh sequence. The order of access unit in basemesh sequence is constrained as follows: - The first access unit of the basemesh sequence shall have bmsh_mesh_frm_order_cnt_lsb equal to firstFrmCount. - The access unit of a basemesh sequence shall be in increasing order of their bmsh_mesh_frm_order_cnt_lsb values. Back to Figure 3, when a basemesh sub-bitstream is organized as in Figure 3, the decoding method shown on figure 2 may be executed as follows. At steps 215 and 220, the decoder does not perform any operation since the organization of the coded submesh NAL layer units is predetermined and follows the fixed or predefined rules described above. At step 225, the decoder uses the bmsh_mesh_frm_order_cnt_lsb variable to identify the N consecutive coded submesh NAL layer units, contained in each group associated with a considered frame. It may also use the information of the bmsh_id variable to check if the order of NAL units is compliant with the implicit or pre-defined order imposed by the fixed rules. Calculating a basemesh sample for a new volumetric frame begins with increasing by 1 the value of bmsh_mesh_frm_order_cnt_lsb from the value of the previous basemesh sample bmsh_mesh_frm_order_cnt_lsb. For the first basemesh sample, the bmsh_mesh_frm_order_cnt_lsb variable is set to the value obtained from the first coded submesh layer NAL unit. The calculation ends with the last coded submesh layer NAL unit with the bmsh_mesh_frm_order_cnt_lsb of the current determined sample. In other words, all the coded NAL units for any submesh within a same frame have the same bmsh_mesh_frm_order_cnt_lsb value. Figure 4 illustrates a second possibility for organizing coding layer data units within a CVS. Each one of the M frames may comprise a variable number of submeshes between 1 and N. In this embodiment, the organization for recording the coding layer data units is fixed or predefined and is the same for all the V3C units. This organization requires several V3C units to encode the basemesh sub-bitstream: Each of these V3C units contains a group of coding layer data units which comprises all the coding layer data units associated with a given submesh for a period of time (The example of a submesh ‘x’ is illustrated by figure 4). Inside such a group (and therefore inside the V3C unit), the coding layer data units are preferably in the frame order for one or more frames. This organization is therefore different from the one of the test model version 6 for ISO / IEC 23090 Part-29, in which a single V3C unit contains all the NAL units for all the submeshes for a given frame or even for a given group of frames. As illustrated by Figure 4, the CVS is composed of a set of V3C units, each described by a V3C unit header (or unit header), as represented by 400, 410, 420-1, 420-N, or 430, followed by a V3C unit payload (or unit payload), as represented by 405, 415, 425-1, 425-N or 435. In Figure 4, as expected from ISO / IEC 23090 Part-29, the first V3C unit (made up of 400 and 405) represents a V3C parameter set. The V3C unit containing a header 410 and a payload 415 represents atlas data component and the V3C unit containing a header 430 and payload 435 represents either displacement data or attribute data component, for example texture attribute. In addition, in Figure 4, to encode the data relative to the N submeshes, N different V3C_B MD units (420-1, 425-1), (420-2, 425-2) (not represented), ... until (420-N, 425-N) are present in the CVS. Each of these V3C units includes a group comprising all the coding layer data units associated with a given submesh for a period of time (from #1 to #N). The encapsulation of the coding layer data units for the different submeshes in different V3C_BMD units makes it possible, during decoding, to identify the start of a coding layer for a new submesh. As shown on the lower part of figure 4, each of these V3C_BMD units is composed of several submesh NAL units contained in a sub-bitstream 425-x, which encodes up to M frames in which the considered submesh (‘x’ on figure 4) of the basemesh sub-bitstream is present. In 425-x, where x varies from 1 to N (the number of submeshes), the first NAL unit (with header 450 and payload 455) may represent a NAL_BMSPS or a NAL_BMFPS. NAL unit. The subsequent NAL unit (composed of 460-1 and 465-1) represents the NAL_BMCL of a the first frame for the submesh “x” considered; the subsequent NAL units represent the NAL_BMCL for the following frames in which the considered “x” submesh is present, up to the final NAL unit (e.g. the header 460-M and the payload 465-M) which represents the Mth frame of the same submesh “x” encoded in the CVS. “x” is an identifier for the submesh, for example the bmsh_id syntax element encoded in the V-DMC bitstream within the syntax structure bmesh_submesh_header. As for Figure 7, it should be noted that other types of V3C units may be present to enable encoding, for example an atlas sub-bitstream, attribute data sub-bitstream(s), possible displacement sub-bitstream, in addition to the basemesh sub-bitstreams. When an encoding method according to the present disclosure is executed, in order to guarantee that the basemesh sub-bitstreams of the respective V3C units are organized as in Figure 4, the following fixed rules are defined: The CVS must first start with a V3C_VPS indicating the number of submeshes present in the CVS (For example N submeshes) N V3C_BMD units, each containing basemesh NAL units where the NAL_BMCL are all for the same bmsh_id, must then be added in the V3C bitstream. The N V3C_BMD units are ordered in the order of NAL_BMCL bmsh_id. Each V3C_BMD containing M ordered NAL_BMCL units of the submesh identified by bmsh_id is obtained from the ordered bmsh_mesh_frm_order_cnt_lsb NAL units. In addition, once a basemesh sub-bitstream has been organized as shown in Figure 4, the decoding method according to the present disclosure can be executed as follows (based on the method shown on Figure 2): At step 215, the decoder determines the number of submeshes present in the CVS, in order to verify the presence of the correct number of V3C_BMD units. For that purpose, an information may be added as a syntax element to the syntax structure of the V3C parameter set (v3c_parameter_set) to identify the number of submeshes. The VPS extension for V-DMC (vps_vdmc_extension) can then be modified as follow: vps_vdmc_extension () { Descriptor vps_has_multiple_submesh_flag u(1) If (vps_has_multiple_submesh_flag) { vps_n um_su bmeshes_mi nus2 ue(v) } for( k=0; k<vps_atlas_count_minus1+1; k++ ){ j = vps_atlas_id[ k ] vps_ext_bmesh_data_substream_codec_id[ j ] u(8) ... } } where: vps_has_multiple_submesh_flag equal to 1 specifies that there are at least 2 submeshes in the basemesh sub-bitstream, each submesh data being present in a dedicated V3C_BMD unit. When the vps_has_multiple_submesh_flag is equal to 0, it specifies that the basemesh sub-bitstream is composed of a single submesh. Vps_num_submeshes_minus2 plus 2 specifies the number of submeshes composing the basemesh sub-bitstream. The value of vps_num_submeshes_minus2 may be limited to the range of 0 to 62, inclusive. When vps_num_submeshes_minus2 is not present (i.e. vps_has_multiple_submesh_flag is equal to 0) the number of submeshes is inferred to be equal to 1. At step 220, the decoder does not perform any operation, since the organization of the coding layer data units is implicit from the fixed or predefined rules. At step 225, the decoder uses the bmsh_mesh_frm_order_cnt_lsb variable to identify the different frames (samples) of the coded submesh layer NAL units, and the identifier bmshjd, to identify to which submesh the coded data contained in the V3C_BMD corresponds. Such identification of the submesh may be necessary for example to decode or to store a sequence of only one specific submesh or of a subset of submeshes. A basemesh sample may correspond to all the NAL_BMCL units having the same value of mesh frame order count. A basemesh sample may correspond to all the NAL_BMCL units having a same value of bmsh_mesh_frm_order_cnt_lsb. In a variant, the vps_vdmc_extension may indicate only the number of submeshes, without any flag or identifier to identify the submesh. In that case, the vps_num_submeshes_minus2 variable is renamed vps_num_submeshes_minus1 and its value shall be in the pre-defined range, for example from 0 to 63. In another variant, to easily check the presence of the N different submeshes in the V3C bitstream, the v3c_unit_header syntax structure is modified to contain an identifier of the submesh it contains, for example as follows: v3c_unit_header() { Descripto r vuh_unit_type u(5) if( vuh_unit_type == V3C_AVD || vuh_unit_type == V3C_GVD || vuh_unit_type == V3C_0VD || vuh_unit_type == V3C_AD || vuh_unit_type == V3C_CAD || vuh_unit_type == V3C_PVD || vuh_unit_type == V3C_BMD ) vuh_v3c_parameter_set_id u(4) if( vuh_unit_type == V3C_AVD || vuh_unit_type == V3C_GVD || vuh_unit_type == V3C_0VD || vuh_unit_type == V3C_AD || vuh_unit_type == V3C_PVD || vuh_unit_type == V3C_BMD ) vuhatlasid u(6) if( vuh_unit_type == V3C_AVD ) { vuh_attribute_index u(7) vuh_attribute_partition_index u(5) vuh_map_index u(4) vuh_auxiliary_video_flag u(1) } else if( vuh_unit_type == V3C_GVD ) { vuh_map_index u(4) vuh_auxiliary_video_flag u(1) vuh_reserved_zero_12bits u(12) } else if( vuh_unit_type == V3C_BMD ) { vuh_submesh_id u(6) } else if( vuh_unit_type == V3C_OVD || vuh_unit_type == V3C_ AD || vuh_unit_type == V3C_PVD) vuh_reserved_zero_17bits u(17) else if( vuh_unit_type == V3C_CAD) vuh_reserved_zero_23bits u(23) Else vuh_reserved_zero_27bits u(27) } In this case, in addition to the fields specified in ISO / IEC 23090 Part-5, the vuh_submesh_id variable specifies the submesh described by the basemesh sub-bitstream contained in a V3C_BMD unit. The value of 5 vuh_submesh_id shall be in the range 0 to 63. The value of the vuh_submesh_id shall reflect the value bmshjd of the NAL_BMCL units contained in the V3C BMD unit. In a variant of this structure, the value of vuh_submesh_id is conditionally 10 coded to the value of vps_has_multiple_submesh_flag. For example, vuh_submesh_id is coded only when vps_has_multiple_submesh_flag is present in vps_vdmc_extension and is equal to 1. When not coded, the identifier for submesh may be inferred to be 1. Figure 5 illustrates a third possibility for organizing coding layer data 15 units within a CVS. Figure 5 shows a third coded submesh NAL unit organization, to encode M frames, each with N submeshes or with a subset of submeshes from 1 to N. In some embodiments this organization is fixed or predefined. This frame-order first organization requires that all coding layer data units of a submesh be aggregated first by frame-order, then preferably by submeshorder, in a single V3C_BMD unit. Moreover, as the number of frames may vary between different CVS, a new separation NAL unit is appended to the basemesh sub-bitstream before starting describing any additional submesh. This bitstream organization is convenient for submesh-based processing (decoding or encapsulation for example); advantageously, the new NAL unit preceding a submesh is useful to locate the submeshes, for example to seek from a submesh to another submesh without parsing the basemesh submesh header or to process submeshes in parallel. In this embodiment, the sub-bitstream 725 of Figure 7 corresponding to the basemesh sub-bitstream is composed of a sequence of several basemesh NAL units. A first NAL unit (with header 500 and payload 505) represents NAL_BMSPS and / or NAL_BMFPS, that may be present in the V3C_BMD unit. Then for the first submesh of the CVS, a sequence of M basemesh NAL units is built to by adding basemesh NAL units in frame order to the basemesh sub-bitstream. For example, the sequence starts with NAL (510-1 / 515-1) unit representing the coded data for submesh 1 for frame 1 up to NAL unit (510-M, 515-M) representing the coded data of submesh 1 for frame M. Then, a new NAL unit 51-20 is appended to the basemesh sub-bitstream, as a submesh delimiter, helping to identify the end of the first submesh and at the same time the start of a new submesh description. As another example, the NAL unit 5(N-1)-20 indicates the end of submesh with identifier (N-1) and at the same time indicates the beginning of submesh N. This NAL unit is called for example a submesh delimiter (or submesh sub-bitstream delimiter), also denoted as NAL_SMD (NAL Submesh delimiter) or NAL_BMSD (for NAL unit for Base Mesh Submesh Delimiter). Then, the basemesh sub-bitstream is composed of the NAL units with the same frame-order of a second submesh (Not represented), followed by an NAL_SMD or NAL_BMSD. Finally, for the Nth submesh of the basemesh, another sequence of M basemesh NAL units is appended to the basemesh sub-bitstream, starting from NAL unit (5N0-1, 5N5- 1) corresponding to the coded data of submesh N of the first frame of the CVS up to NAL unit (5N0-M, 5N5-M) representing the coded data of submesh N of the frame M. The NAL units of a given submesh are added to the basemesh sub-bitstream in their increasing frame order. At the end of the basemesh sub-bitstream, an optional NAL_SMD may be added to clearly separate the last submesh from additional non-BMCL NAL units (for example suffix NAL_SEI). It should be noted that a NAL_SMD (50-20) may also be added before the first NAL unit of the first submesh to ease the determination of the corresponding submesh sub-bitstream. It may be a requirement, that when several submeshes are present in a basemesh sub-bitstream, there shall be a submesh NAL unit delimiter (NAL_BMSD) preceding the first NAL_BMCL for a given submesh. This first submesh delimiter is also optional in case only a single submesh is present in the basemesh sub-bitstream. To support the additional submesh NAL unit delimiter, a new bmesh_nal_unit is defined where value of bmesh_nal_unit_type in bmesh_nal_unit_header is equal for example to 40, or any other value corresponding to reserved or unspecified value for non-BMCL NAL unit type, not conflicting with a value already used. For this NAL unit, the NAL unit payload may be specified as an empty payload as follows: submesh_delimiter_unit() { Descriptor } To guarantee that basemesh sub-bitstream is organized as in Figure 5, the following fixed or predefined, or implicit rules are defined, for the generation of basemesh sub-bitstream by V-DMC encoders, with N submeshes: It starts with 0 or more non NAL_BMCL units (such as NAL_BMSPS, NAL_BMFPS), Followed by 0 or 1 NAL_SMD unit, Then iteratively for the N submeshes in increasing order of their bmsh_id: Followed by all NAL_BMCL units, with same bmsh_id, corresponding to the M samples in increasing order of their bmsh_mesh_frm_order_cnt_lsb Optionally followed by 0 or more non NAL_BMCL units (such as NAL_SEI, ..) Followed by a NAL_SMD, except optionnaly for the last submesh. When basemesh sub-bitstream is organized as in Figure 5, the following description applies to the Figure 2. Step 215 does not perform any specific operation. Step 220 after determining from an initial (or the last) BM_FPS the number of submeshes present in the basmesh sub-bitstream performs the following operation once it determines that several submeshes are present. Otherwise step 225 is executed to determine the samples present in the basemesh sub-bitstream that contains a single submesh. Step 220, when several submeshes are present in the received basemesh sub-bitstream contained in the V3C_BMD unit, determines the first NAL unit corresponding to the first coded submesh by identifying the first NAL_BMCL unit or optionally the first NAL_SMD if present. Then step 225 determines all NAL units corresponding to the M frames of submesh 1 by searching for the next NAL unit with bmesh_nal_unit_type equal to NAL_SMD. It may then start executing step 225 for all the buffered data corresponding to submesh 1. This enables parallel execution of the submesh sub-bitstream sample determination. Step 220 may then determine data segments corresponding to a second submesh by searching the next NAL_SMD unit, that once determined may be processed in parallel as described in step 225. Finally, the last data segment corresponding either to end of the basemesh subbitstream or to a last optional NAL_SMD is determined and further processed by step 225. Step 225 uses the bmsh_mesh_frm_order_cnt_lsb to determine the M consecutive frames (samples) corresponding to each submesh sub-bitstream, using bmsh_mesh_frm_order_cnt_lsb. When all samples for the N submeshes are determined, steps 220 and 225 have ended processing of V3C_BMD unit and step 20 is then executed. In a variant, the NAL unit payload of the additional NAL_SMD provides additional information, such as submesh identifier, as follows: submesh_delimiter_unit() { Descriptor sdu_submesh_id ue(v) } Where sdu_submesh_id specifies the submesh described by the following NAL_BMCL units up to the next NAL_SMD or to the ned of the basemesh sub-bitstream. Value of sdu_submesh_id shall be in the range 0 to 63. Value of the sdu_submesh_id shall reflect the value bmsh_id of the NAL_BMCL units following the NAL_SMD unit. In another embodiment, any of the two coded submesh NAL unit organization as described by Figure 3 or Figure 5, are possible at basemesh sub-bitstream level. In that case, further signaling is provided, for example in NAL_BMSPS or NAL_BMFPS and used in step 220 to determine the coded submesh NAL unit organization. The signaling is provided for example by additional information as a new syntax element in bmesh_submesh_information syntax structure as follows: bmesh_submesh_information() { Descriptor bmsi_use_single_mesh_flag u(1) if(!bmsi_use_single_mesh_flag){ bmsi_num_submeshes_minus2 ue(v) NumBmeshSubMeshes = bmsi_num_submeshes_minus2 + 2 bmsi_submesh_organization_flag u(1) } Else NumBmeshSubMeshes = 1 ... } Where the new syntax element has the following semantics: bmsi_submesh_organization_flag equal to 0 specifies that submeshes are organized first by submesh-order, then by frame order in a single V3C_BMD unit (cf Figure 3). When equal to 1, it specifies that submeshes are organized first frame-order for a submesh, then by submesh-order in a single V3C_BMD unit (cf Figure 5). There may be additional modes, then this syntax element would be coded as an integer value taking values from a pre-determined range, each value indicating an submesh organization or arrangement mode. In a variant, no specific signaling is added and instead, decoders or parsers or any entity processing such V-DMC bitstream may rely on the presence or absence of specific V3C or base mesh NAL units to determine the subsmesh organization, for example a submesh delimiter. For example, in step 220, the determination is performed by parsing the NAL unit headers and check if at least one is a NAL_SMD. If this is the case, the entity processing the V-DMC bitstream infers that the coded submesh NAL unit organization is one like illustrated on Figure 5. If no specific V3C units or NAL units are of type NAL_SMD, the entity processing the V-DMC bitstream infers that the coded submesh NAL unit organization is one like illustrated on Figure 3. In a variant, for any of the two coded submesh NAL unit organizations, the signaling is performed at V3C bitstream level using additional information in vps_vdmc_extension as follow: vps_vdmc_extension () { Descriptor vps_h as_m u 11 i p I e_su bmes h_f I ag u(1) If (vps_has_multiple_submesh_flag) { vps_n um_su bmeshes_mi nus2 ue(v) vps_submesh_organization_flag u(1) } for( k=0; k<vps_atlas_count_minus1+1; k++ ){ j = vps_atlas_id[ k ] vps_ext_bmesh_data_substream_codec_id[ j ] u(8) ... } } 10 Where the new syntax elements have the following semantics: vps_submesh_organization_flag equal to 0 specifies that submeshes are organized first by submesh-order, then by frame order in a single V3C_BMD unit. When equal to 1, it specifies that submeshes are organized by frame-order first for a given submesh, then by submesh-order in a single V3C_BMD unit. In that case, determination of the coded submesh NAL unit organization is performed in step 215 (in place of 220), by checking the value of the bmsi_submesh_organization_flag. In another variant, for any of the two coded submesh NAL unit organizations, the signaling is performed in another sub-bitstream than the basemesh sub-bistream. For example, using NAL units of the atlas sub-bitstream, such as atlas sequence parameter set (NAL_ASPS) or atlas frame parameter set (NAL_AFPS). Preferably the signaling is performed in the atlas sub-bitstream contained in V3C_AD unit, in the NAL Atlas sequence parameter set using asps_vdmc_extension as follows: asps_vdmc_extension() { Descri pto r asve_subdivision_method u(3) if( asve_subdivision_method ! = 0 ) { } else AspsSubdivisionCount = 0 asve_has_multiple_submesh_flag u(1) If (asve_has_multiple_submesh_flag) { asve_num_submeshes_minus2 ue(v) asve_submesh_organization_value u(1) } } Where the new syntax elements have the following semantics: asve_has_multiple_submesh_flag equal to 1 specifies that there are at least 2 submeshes in the basemesh sub-bitstream. asve_has_multiple_submesh_flag equal to 0 specifies that the basemesh sub-bitstream is composed of a single submesh. asve_num_submeshes_minus2 plus 2 specifies the number of submeshes composing the basemesh sub-bitstream. The value of asve_num_submeshes_minus2 shall be in a pre-defined range, for example from 0 to 62, inclusive. When asve_num_submeshes_minus2 is not present or asve_has_multiple_submesh_flag is equal to 0, the number of submeshes is inferred to be equal to 1. asve_submesh_organization_value equal to 0 specifies that submeshes are organized by submesh-order first, then by frame order in a single V3C_BMD unit. When equal to 1, it specifies that submeshes are organized by frame-order first for a submesh, then by submesh-order in a single V3C_BMD unit. In that case, determination of the coded submesh NAL unit organization is performed when analysing the V3C_AD sub-bitstream in additional steps 235 (not represented in Figure 2), between step 210 and 230. During this additional step, the coded submesh NAL unit organization is determined and memorized in internal variable, that is then used in step 220 as result for the organization determination. It should be noted that this signaling is more efficient if the atlas sub-bitstream is present in the V3C bitstream before the basemesh subbitstream. Indeed, it then avoids to keep in memory all the basemesh subbitstream, waiting for the coded submesh NAL unit organization to start sample determination processing. In another embodiment, any of the coded submesh NAL unit organizations as described by Figure 3, Figure 4 or Figure 5, are possible at basemesh sub-bitstream level. In that case, the signaling is performed at V3C bitstream level using additional information (new syntax elements) in the vps_vdmc_extension syntax structure but using a vps_submesh_organization_value in place of the vps_submesh_organization_flag. The syntax is for example the following: vps_vdmc_extension () { Descriptor vps_has_multiple_submesh_flag u(1) If (vps_has_multiple_submesh_flag) { vps_n um_su bmeshes_mi nus2 ue(v) vps_submesh_organization_value u(2) } for( k=0; k<vps_atlas_count_minus1+1; k++ ){ j = vps_atlas_id[ k ] vps_ext_bmesh_data_substream_codec_id[ j ] u(8) ... } } Where the new syntax elements have the following semantics: vps_submesh_organization_value equal to 0 specifies that submeshes are organized by submesh-order first, then by frame order in a single V3C_BMD unit. When equal to 1, it specifies that submeshes are organized by frame-order first for a given submesh, then by submesh-order in a single V3C_BMD unit. When equal to 2, it specifies that submeshes are organized by ordered submesh sub-bitstream, each contained in a separate V3C_BMD unit. In that case, determination of the coded submesh NAL unit organization is performed in step 215 (in place of 220), by checking the value of the bmsi_submesh_organization_value. Example of hardware to carry out steps of the method of embodiments of the invention Figure 6 is a schematic block diagram of a computing or processing device 600 for implementation of one or more embodiments of the invention. The computing or processing device 600 may be a device such as a microcomputer, a workstation, or a light portable device. The computing or processing device 600 comprises a communication bus 602 connected to: - a central processing unit (CPU) 604, such as a microprocessor; - a random access memory (RAM) 608 for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method for encapsulating, indexing, de-encapsulating, and / or accessing data, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example; - a read only memory (ROM) 606 for storing computer programs for implementing embodiments of the invention; - a network interface 612 that is, in turn, typically connected to a communication network 614 over which digital data to be processed are transmitted or received. The network interface 612 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 604; - a user interface (UI) 616 for receiving inputs from a user or to display information to a user; - a hard disk (HD) 610; and / or - an I / O module 618 for receiving / sending data from / to external devices such as a video source or display. The executable code may be stored either in read only memory 606, on the hard disk 610 or on a removable digital medium for example such as a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 612, in order to be stored in one of the storage means of the communication device 600, such as the hard disk 610, before being executed. The central processing unit 604 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 604 is capable of executing instructions from main RAM memory 608 relating to a software application after those instructions have been loaded from the program ROM 606 or the hard-disc (HD) 610 for example. Such a software application, when executed by the CPU 604, causes the steps of the flowcharts shown in the previous figures to be performed. In this embodiment, the apparatus is a programmable apparatus which uses software to implement the invention. However, alternatively, the present invention may be implemented in hardware (for example, in the form of an Application Specific Integrated Circuit or ASIC). Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a person skilled in the art which lie within the scope of the present invention. Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

1. A method for encoding volumetric data into a coded mesh bitstream, in a processing device,the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes, the method comprisingencoding the mesh data associated both to a frame and to a submesh within one or more coding layer data units; andencoding the mesh data so that, for a considered time period covering a plurality of frames:- the coding layer data units are grouped by submesh;each group for a considered submesh including the coding layer data units for the considered submesh for all the frames of said time period in which the considered submesh is present; andamong the groups associated with the different submeshes, any two groups are separated from each other by a separator; or- the coding layer data units are grouped by frame, each group for a considered frame including the coding layer data units for at least the submesh(s) present, or all the submeshes, for the considered frame.

2. A method according to claim 1, wherein the coded mesh bitstream comprises a plurality of sub-bitstreams; and during the encoding step, each group for the respective submeshes composes a respective sub-bitstream of the coded mesh bitstream, each sub-bitstream being carried in a dedicated data unit, wherein said separator preferably is a header of the dedicated data unit.

3. A method according to claim 2, wherein the coded mesh bitstream is a V3C compliant bitstream and the dedicated data unit is a V3C unit.

4. A method according to any one of claims 1 to 3, wherein said separator is a non-coding layer data unit.

5. A method according to any one of claims 1 to 4, wherein during the encoding step, for each submesh, inside each group, the coding layer data units relative to the different frames are encoded ordered by frame order within the group.

6. A method according to any one of claims 1 to 5, wherein the bitstream is encoded with an indication for indicating, at least for the considered time period, whether the coding layer data units are grouped by submesh or the coding layer data units are grouped by frame.

7. A method according to claim 6, wherein the indication further defines that the coding layer data units of distinct submeshes are stored as distinct sub-bitstreams carried in distinct dedicated data units, or defines that the coding layer data units of distinct submeshes are stored in a single sub-bitstream for the considered time period but are separated by a non-coding layer data unit.

8. A method according to any one of claims 1 to 7, wherein the separator comprises an identifier of the submesh associated with the group of coding layer data units following the separator.

9. A method for decoding a coded mesh bitstream in a processing device, the method comprising:retrieving a group or part of a group of coding layer data units;the coding layer data units of the coded mesh bitstream defining volumetric data encoded in the coded mesh bitstream;the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes;each coding layer data unit defining mesh data associated both to a frame and to a submesh;the group of coding layer data units including coding layer data units only for the sub-mesh(es) present in one frame, or all the sub-meshes for the frame;generating said one frame or part of said one frame based on the retrieved group or the retrieved part of the group.

10. A method for decoding a coded mesh bitstream, in a processing device, the method comprising:identifying a separator in the coded mesh bitstream;the separator separating two groups of coding layer data units;the coding layer data units of the coded mesh bitstream defining volumetric data encoded in the coded mesh bitstream;the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes;each coding layer data unit defining mesh data associated both to a frame and to a submesh;each of the two groups being defined for a time period and including coding layer data units only for a considered submesh, for all the frames in the time period in which the considered submesh is present; andretrieving one of said two groups of coding layer data units based on the separator; andgenerating at least one frame or part of one frame based on the retrieved coding layer data units.

11. A method according to claim 10, wherein the separator comprises an identifier of the submesh associated with the group of coding layer data units following the separator.

12. A method according to claim 10 or 11, wherein within at least one of said two groups, the coding layer data units are ordered by frame order.

13. A method according to any one of claims 10 to 12, wherein the coded mesh bitstream comprises a plurality of sub-bitstreams; each of said sub-bitstreams including coding layer data units only for a considered submesh and being carried in a dedicated data unit, wherein said separator preferably is a header of the dedicated data unit.

14. A method according to claim 13, wherein the coded mesh bitstream is a V3C compliant bitstream and the dedicated data units are V3C units.

15. A method according to any one of claims 10 to 12, in the case where coding layer data units are grouped by submesh wherein said separator is a non-coding layer data unit.

16. A method for decoding a coded mesh bitstream in a processing device, the method comprising:identifying an organization of coding layer data units encoded in the coded mesh bitstream,the coding layer data units defining volumetric data encoded in the coded mesh bitstream;the volumetric data including mesh data forming a plurality of mesh frames partitioned into a plurality of sub-meshes;each coding layer data unit defining mesh data associated both to a frame and to a submesh;the organization defining at least whether, at least for a considered time period covering a plurality of frames, the coding layer data units are grouped:- by submesh;each group for a considered submesh including the coding layer data units for all the frames of said time period in which the considered submesh is present; andamong the groups associated with the different submeshes, any two groups are separated from each other by a separator; or- by frame;each group for a considered frame including the coding layer data units for at least the sub-mesh(s) present, or all the sub-meshes, for the considered frame;retrieving one or more coding layer data units based on the identified organization; andgenerating at least one frame or part of a frame based on the retrieved coding layer data units.

17. A method according to claim 16, wherein the determined organization further defines in which order the coding layer data units are ordered inside the groups, either relative to the sub-meshes or to the frames.

18. A method according to claim 16 or 17, wherein the organization of the coding layer data units is determined based on one or more indications indicating whether, at least for the considered time period, the coding layer data units are grouped by submesh or by frame..

19. A method according to any one of claims 1 to 18, in which the coded mesh bitstream is a V3C compliant bitstream.

20. A method according to any one of claims 1 to 19, in which the mesh data are encoded in at least one mesh sub-bitstream, preferably in at least one basemesh sub-bitstream, wherein a basemesh sub-bitstream describes a basemesh which is a simplified low-resolution approximation of an original mesh.

21. A computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of the method according to any one of claims 1 to 18 when the program is loaded and executed by a programmable apparatus.

22. A non-transitory computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 18.

23. A processing device comprising a processing unit configured for carrying out each step of the method according to any one of claims 1 to 18.

Images