Method and apparatus for encapsulating and parsing a media file having split samples

Abstract

Encapsulating media data into a media file, the media data comprising base data and additional data to the base data, the method comprising, generating a track comprising a sequence of samples, each s

Description

FIELD OF THE DISCLOSURE The present disclosure concerns a method and a device for encapsulating and parsing a media file. BACKGROUND OF DISCLOSURE The International Standard Organization Base Media File Format (ISOBMFF, ISO / IEC 14496-12) is a well-known flexible and extensible format that describes the encapsulation of timed or untimed media data or bitstreams either for local storage or transmission via a network or via another bitstream delivery mechanism. An ISO Base media file is object-oriented and structured into “boxes” that are sequentially or hierarchically organized. Boxes are data structures provided to describe the data in the files. Boxes (also denoted objects, atoms, structure-data, or data structures) are building blocks starting with a header which gives both size and a unique type identifier (typically a four-character code (32-bit), also noted FourCC or 4CC). Some boxes, called ‘FullBox’, also contain a version number and flags field. All data in a file (media data and metadata describing the media data) is contained in boxes. There is no other data within the file. File-level boxes are boxes that are not contained in other boxes. More particularly, inside a media file, medias are generally represented as tracks. A track is a timed sequence of related samples, a sample corresponding to the data associated with a single time. For instance, for a video media, a track is a sequence of video frames, each frame associated with a given time. A derived specification ISO / IEC 14496-15 defines the carriage of NAL-unit (“Network Abstraction Layer” unit) structured video in ISOBMFF, for example for AVC, HEVC, VVC, EVC codecs.... It is to be noted that concepts of ISO / IEC 14496-15 may also be used for non-NALU based video codecs like for example AV1. ISOBMFF provides a sample description, mainly through sample entry in a Sample Description Box with a four-character code ‘stsd’. A sample entry is a box structure which defines and describes the format of some number of samples in a track. This number corresponds to the chunks of samples referencing this sample entry that is declared in a sample-to-chunk box. A chunk is a set of contiguous samples. By design, in ISOBMFF, within a chunk, the samples are contiguously stored. Therefore, if a chunk contains two samples, the position of the second can be found by adding the size of the first to the offset for the chunk. The chunk offset table provides the offsets; the sample-to-chunk table provides the mapping from sample number to chunk number. A sample entry usually contains a configuration box providing information for decoder initialization, sometimes called “decoder configuration” or “decoder initialisation”. For example, a layered HEVC track may contain two configuration boxes, one describing the base - layer, another one describing the other layers. ISOBMFF allows creating files encapsulating layered media, for example MV-HEVC or LC-EVC, either: - as a single HEVC track, possibly with two decoder configuration boxes, where a sample contains all the layers, thus leading to an interleaving of base layer and enhancement layer data for each sample, or - as multiple tracks where each track and samples of this track contain one or more layers, meaning that a reconstruction process is defined to reconstruct a full picture consisting in all the layers. However, the multi-track approach is heavy, introduces track reference methods, often requires specification of bitstream reconstruction process and implies many redundant information such as timing and composition offsets. For example, Figure 1 shows a media file with an interleaving of base layer and enhancement layer data for each sample. In particular, as shown in Figure 1, media data are stored in a media data box 'mdat'. The samples are stored contiguously in chunks 110-1 and 110-2. Each sample comprises data for a base layer and data for different enhancement layers. For example, a first sample in chunk 110-1 includes data 110-1 la for a base layer and data 110-1 lb for enhancement layers. Another sample 110-21 in chunk 110-2 includes data 110-21a for a base layer and data 110-21b for enhancement layers. Another sample 110-22 in chunk 110-2 includes data 110-22a for a base layer and data 110-22b for enhancement layers. Thus, the data for a base layer of different samples are separated by data for enhancement layers. Also to be noted, a sample description box 103-1 contains a sample entry comprising one or two configuration boxes (the "cfg" ones) to describe the coding configuration for the base layer and the coding configuration for the whole set of layers. The problem to be solved by the present disclosure is to allow carriage of multilayer bitstream within a single track which is backward compatible with the single layer sample entry (i.e., compatible with the coding type of the base layer). In particular, this problem cannot be solved with single track and multiple decoder configuration due to the interleaving of base and enhancement layers in each sample, as illustrated on Figure 1. Indeed, a decoder supporting only the base layer should be able to discard the data for the enhancement layer (e.g. 110-llb... 110-21b or 110-22b) and process only the ones for the base layer (e.g. 110-lla.... 110-21a or 110-22a). Moreover, in ISO / IEC 14496-15, when the codec for the base is a different codec, the multitrack approach is recommended. Thus, there is a need for single track encapsulation indicating the different parts (or levels or layers) for the samples available in the track with a sample organization (in the data) matching this organization in different layers or levels or parts. SUMMARY OF THE DISCLOSURE The present disclosure has been devised to address one or more of the foregoing concerns. According to a first aspect, there is provided a method of encapsulating media data into a media file, the media data comprising base data and additional data to the base data, the method comprising: generating a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising: a first part including data of the base data associated with the single time and at least one additional part including data of the additional data associated with the single time, generating descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track; generating the media file comprising the generated track and the descriptive metadata. Thus, the entire bitstream is described in the media file in terms of samples, so that the tools for sample description remain available: subsample, sample groups and sample auxiliary information remain the same. This means that without additional signalling, any description of the sample (like sample groups, subsample or sample auxiliary information) is done on the complete reaggregated sample (base data and additional data, also called “full” sample) These tools stay the same, and allow a media file reader to “thin” the media file by fetching only the parts of samples it requires. If performing sample thinning, a file reader may have to edit these descriptions accordingly, i.e. remove descriptions corresponding to parts of the file that have been removed by the thinning process to keep the sample descriptions backward compatible. Indeed, backward compatibility is possible as long as none of these description structures include byte ranges from the additional split layers (the additional parts). Therefore, the present disclosure makes possible to describe, in a single track, a base configuration for basic players for parsing base data, with additional configurations for advanced players or readers for parsing base data with additional data. It has no extractors-like constructs and keeps the original ISOBMFF design for base data (or base split layer). In an embodiment, the descriptive metadata comprises decoder configuration for the first part of the samples only and at least one decoder configuration for an aggregation of the first part and at least one additional part of the samples. In an embodiment, the information relative to the organization of the at least one additional part of the samples in the track comprises configuration information for the organization of the at least one additional part of the samples in the track and size information for the size of the at least one additional part of the samples. In an embodiment, the information relative to the organization of the at least one additional part of the samples in the track is stored in at least one additional box in a track box of the media file. In an embodiment, the configuration information is stored in an additional box in a sample table box in the track box of the media file. In an embodiment, the size information is stored in at least one additional box in the sample table box. In an embodiment, the different parts of the samples are stored in chunks in the media file. In an embodiment, each chunk includes data of the first parts and of additional parts of different samples, the first parts of the different samples being contiguous in the chunk. The chunks of this embodiment provide a non-contiguous splitting that allows a media file reader to fetch only the parts of samples (e.g. samples of a given layer, tiles or subpictures) it requires for a given time in a single I / O or network operation. There are many use cases where being able to store a single track while splitting the samples would be beneficial, for example scalable layers in a single track, multi-codec support in a single track (AVC+L-HEVC or LC-EVC, ...), tiled bitstreams, whether encoded or not, temporal sub-layers. Therefore, this embodiment allows reconsidering the design for sample organisation in ISOBMFF mandating that within a chunk, the samples are contiguously stored by allowing splitting samples. In an embodiment, the additional parts of the different samples are contiguous in the chunk. In an embodiment, each chunk includes only data of the first part of different samples or data of an additional part of different samples. In an embodiment, the information relative to the organization of the at least one additional part of the samples in the track also comprises chunk offset information for each chunk. In an embodiment, the chunk offset information is stored in at least one additional box in the sample table box. In an embodiment, the chunk offset information and the size information are stored in different boxes in at least one additional box in the track box, outside the sample table box. In an embodiment, the base data corresponds to data associated with a base split layer and the additional data correspond to data associated with at least one additional split layer of a multi-layer bitstream. In an embodiment, the at least one additional split layer corresponds to at least one enhancement layer. In an embodiment, the base data and the additional data are data corresponding to different types of coding formats. In an embodiment, the base data and the additional data are data corresponding to spatial parts of a video. In an embodiment, the sequence of samples further comprises an empty sample. Such empty sample is used to align the split samples, notably according to a temporal level of the base split layer. According to another aspect, there is provided a method of parsing a media file including: a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising: a first part including data of base data associated with the single time and at least one additional part including data of additional data associated with the single time, descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track; wherein the method comprises a reconstruction of the samples based on the first part of the samples only or based on an aggregation of the first part of the samples with the at least one additional part of the samples according to said descriptive metadata. According to another aspect, there is provided a computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method of encapsulating media data into a media file or a method of parsing a media file as previously described, when loaded into and executed by the programmable apparatus. According to another aspect, there is provided a computer-readable storage medium storing instructions of a computer program product as previously described. According to another aspect, there is provided a device for encapsulating media data into a media file, the media data comprising base data and additional data to the base data, the device comprising a processor configured to: generate a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising: a first part including data of the base data associated with the single time and at least one additional part including data of the additional data associated with the single time, generate descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track; generate the media file comprising the generated track and the descriptive metadata. According to another aspect, there is provided a device for parsing a media file including: a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising: a first part including data of base data associated with the single time and at least one additional part including data of additional data associated with the single time, descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track; wherein the device comprises a processor configured to reconstruct the samples based on the first part of the samples only or based on an aggregation of the first part of the samples with the at least one additional part of the samples according to said descriptive metadata. According to another aspect, there is provided a media file including: a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising: a first part including data of base data associated with the single time and at least one additional part including data of additional data associated with the single time, descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track. A basic player (notably a basic parser) can process such media file. In particular, the basic player can process the base bitstream and can ignore unknown boxes related to the at least one additional part of the samples and by processing boxes from regular sample description related to the first part of the samples. The data organization of the sample parts preserves encryption, sample grouping description, subsample information. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the disclosure will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates an encapsulated media file according to the state of the art: Figure 2 illustrates an embodiment of a system for encapsulation and parsing of images or sequence of images; Figure 3 illustrates an encapsulated media file according to a first embodiment of the disclosure; Figure 4 illustrates an encapsulated media file according to a second embodiment of the disclosure; Figure 5 illustrates an encapsulated media file according to a third embodiment of the disclosure; Figure 6 illustrates an encapsulation process according to an embodiment of the disclosure; Figure 7 illustrates a parsing process according to an embodiment of the disclosure; Figure 8 is a schematic block diagram of a computing device for implementation of one or more embodiments of the disclosure. DETAILED DESCRIPTION OF THE DISCLOSURE Figure 2 schematically illustrates a system for encapsulation and parsing of images or sequences of images, according to some embodiments of the disclosure. As illustrated, a server 200 comprises an encapsulation module 205. The server 200 may be connected, via a network interface (not represented), to a communication network 210 to which is also connected, via a network interface (not represented), a client 215 comprising a parser (or de-encapsulation module) 220 or a storage device (not represented). Optionally, the server 200 may comprise an encryption module 241 to encrypt sensitive parts of or the whole data, preferably after compression. For encryption, the MPEG Common Encryption (also called CENC and specified as ISO / IEC 23001-7) may be used. Likewise, the client 215 optionally comprises a decryption module 251 to decrypt sensitive parts of, or the whole data that have been previously encrypted. Preferably, the decryption is done before decompression. The exact order may also be indicated by indicating in an Essential description hierarchy sample grouping fesgh’) or as a restricted track or restricted sample entry. It is to be noted that encryption and decryption modules may be contained in other processing modules external to server 200 and client 215, respectively. According to the given example, server 200 processes data 225, for example data representing a 3D sequence or a video sequence for streaming or for storage. Server 200 may also receive other media data 230, for example of the text or audio type and / or encoded video bitstreams, and / or metadata (not represented). These other media data and these metadata may be either in an encoded format or in an uncompressed format. The media data 225 and the other media data 230 may be encoded using different codecs, for example AVC and HEVC when media is video, or V-PCC or V-DMC when media is volumetric (3D point cloud or mesh). The media data 225 and the other media data 230 may also be encoded using a layered codec, e.g. the other media data 230 being coded differentially to media data 225. The media data 225 and the other media data 230 may be independently compressed, for example when a volumetric or a video source is split into regions, each being individually encoded (like HEVC motion-constrained tiles or VVC subpictures or tiles in V3C). The media data 225 may be considered as a base split layer whereas the other media data 230 (or a part of) may be considered as one or more additional split layers. For the sake of illustration, media data 225 may correspond to the recording of a scene by one or several cameras (or image sensors), referred to as a source (i.e. a source of sequences of images). When media data 225 are uncompressed, they are called raw or uncompressed data. When media data 225 are encoded, for example using MPEG codecs like AVC, HEVC or VVC for video or V-PCC or V-DMC or G-PCC for 3D volumetric media, they are called compressed or encoded data. The encoding may be done within the server 200 by a compression module 240 or may be done outside the server in which case the media data 225 are provided in a compressed bitstream. Server 200 may index or describe the media data of the source into a media file 235 or into segment files (containing one or more segments), as they are processed, for example for live recording or live transmission. This index or description consist in information allowing to locate samples in time, determine their type (e.g. l-frame or not for video), and determine their size, (data) container, and offset into that container. The media file 235 or the generated segment files may be stored in a local or remote storage device or may be transmitted to a client, for example to client 215. Client 215 may be configured to process data received from communication network 210, for example to process media file 235, or to process encapsulated data read from a storage device. After the received or the read data have been parsed in parser 220 (also known as a de-encapsulation module or a reader, or even a player or a media player), the parsed data may be stored, displayed or output. According to the given example, the parser outputs the media data referenced 260, possibly with additional media data, such as other media data 265, for example of the text or audio type and / or encoded video or volumetric bitstreams, and / or metadata. These additional media data 265 form one or several bitstreams that may be displayed. Depending on the configuration or on the capabilities of the client 215, in particular its decompression capabilities, the media data 260 may correspond to decoded video for a base split layer 225 (e.g. HEVC bitstream) or to decoded images from the base split layer plus one or more additional split layers 230 (e.g. L-HEVC bitstream), notably one or more enhancement split layers. For volumetric media, base split layer may correspond to the geometry of the content, while additional split layers may correspond to one or more attributes. It is observed that some of the data of the received or read data, for example some data of media file 235, may be compressed data blocks. To be rendered or processed, these compressed data blocks require decompression (or decoding). This decompression can be performed by the decompression module 250 in client 215. It is observed that server 200 and client 215 may be user devices but may also be network nodes acting on media files being transmitted or stored. It is also noted that media file 235 or any other media file received or read by client 215 may be communicated to parser 220 in different ways. In particular, the encapsulation module 205 may generate media file 235 with a media description (e.g. a DASH MPD, i.e. a media presentation description (MPD) of the dynamic adaptive streaming over HTTP (DASH) protocol) and may communicate (or stream) it directly to parser 220 upon receiving a request from client 215. Media file 235 may also be downloaded, at once or progressively, by client 215 and stored locally. Media file 235 may also be provided as one or more segment files. According to some embodiments of the disclosure, the encapsulation comprises indexing parts of samples possibly encoded or compressed. The indexation consists in describing information relative to the organization of the samples into different parts of samples. In a symmetrical way, processing the encapsulated data in a reader comprises obtaining sample description, obtaining indexing information on parts of samples, reconstructing the samples (full sample) or parts of samples based in the obtained information, as described by reference to Figure 7. Figure 3 illustrates a first embodiment of a media file 100 according to the disclosure. Such media file 100 can correspond to a media file 235 in figure 2. The media file 100 is object-oriented and structured into “boxes” that are sequentially or hierarchically organized. This media file 100 is configured to encapsulate media data (e.g. uncompressed or encoded video, possibly with additional media data) into boxes, notably according to ISO Base Media File Format (ISOBMFF, ISO / IEC 14496-12). The media file 100 includes two kinds of boxes. A first kind of box corresponds to one or several “media data boxes” (e.g. ‘mdat’ or ‘imda’), 104-1 containing the media data. A second kind of box corresponds to “metadata boxes” or “structure-data wrapper” (e.g. ‘moov’ or ‘moof’), 101 containing metadata defining the position of the media data in the media data box(es) and temporal position of the media data. For example, the media data box 104-1 contains all the data for image data 225 and all the data for possible other media data 230 shown on figure 2. In particular, the media data box ‘mdat’ 104-1 can multiplex media data 225 and the other media data 230 shown on figure 2. Alternatively, there may also be several media data boxes, for example a first set of media data boxes for the media data 225 and a second set of media data boxes for the other media data 230. The media data 225 and the other media data 230 form data samples. In particular, the media data 225 and the other media data 230 are split into different layers for each sample of data. Therefore, the media data contains samples including data for different layers. A split layer is a part of a sample. A split layer may correspond to a base split layer or to an additional split layer, for example an additional split layer may be an enhancement layer or one or more tiles for example. An enhancement layer is a layer that enhances a base split layer (in quality, temporal resolution or spatial resolution or a combination of those for video streams). A base split layer is a split layer that corresponds to the sample data described by existing ISOBMFF structures (sample size, chunk offset, sample to chunk). An additional split layer: (or complementary) is a split layer corresponding to the sample data described by additional ISOBMFF structures than the classical sample description. The data of an additional split layer correspond to additional data to the base data. The media data box 104-1 is organized by chunk. For example, on figure 3, the media data box 104-1 includes a chunk 110-1 and a chunk 110-2. A chunk can include one or more samples of data or parts of sample data. For example, the chunk 110-1 includes three samples, each sample having three split layers. For example, a sample includes data for a base split layer 110-11a, and data for two different additional split layer 110-11b. The chunk 110-2 includes three samples, each sample having three split layers. For example, one sample includes data for a base split layer 110-21 a, and data for two different additional split layer 110-21 b, and another sample includes data for a base split layer 110-22a, and data for two different additional split layers 110-22b. Besides, the sequence of samples may further comprise one or more empty samples (not illustrated). Such empty samples are used to align the split samples, notably according to a temporal level of the base split layer. According to the present disclosure, the samples are not contiguous in a chunk. Each chunk is organized so that the part of data associated with a given split layer are contiguous in a chunk. More particularly, the data of the base split layer are the first data in each chunk, the data of the additional split layers follow the data of the base split layer in each chunk. Moreover, the data of a given split layer are organized according to their sample order. Such data organization of the media data of a multi-layer bitstream within a single track is backward compatible with the single layer sample entry (i.e., compatible with the coding type of the base split layer). Indeed, in such media data box, there is no interleaving of base and enhancement layers in each sample. Therefore, a decoder supporting only the base split layer can discard the data for the enhancement split layer (e.g. 110-11 b... 110-21 b or 110-22b) and process only the ones for the base split layer (e.g. 110-11a.... 110-21 a or 110-22a). This data organization may be convenient to make easier the reconstruction of full samples and for sample entry type corresponding to the coding configuration of all the layers. Regarding the metadata of the media file, a movie box ‘moov’ 101 includes a track box ‘trak’ 102. The track box ‘trak’ 102 represents a single media track within the media file 100. The track box ‘trak’ 102 includes a sample table box ‘stbl’ 103. The sample table box ’stbl’ 103 provides metadata about the samples in a track. The sample table box ’stbl’ 103 allows efficient access to the media data. The sample table box ‘stbl’ 103 includes notably a sample description box ‘stsd’ 103-1, a Sample-to-Chunk box ‘stsc’ 103-2, a chunk offset box ‘stco’ 103-3 and a sample size box ‘stsz’ 103-4. The sample description box ‘stsd’ 103-1 describes the format of the samples in a track. For example, it defines the codec and configuration information needed for decoding the samples. In particular, the sample description box ‘stsd’ includes at least a configuration box ‘cfg’ to describe the coding configuration for the base split layer. The sample-to-chunk box ‘stsc’ 103-2 maps samples to chunks and defines how many samples are stored in each chunk. It helps in organizing samples into chunks, allowing efficient data retrieval. In this embodiment, the number of samples per chunk is the same for all split layers and the chunk offset is indicated only for the base split layer. The chunk offset box ‘stco’ 103-3 stores the byte offsets of each chunk, indicating where each chunk starts within the media data box ‘mdat’. This enables the parser to locate and access the actual media data in the file. The sample size box ‘stsz’ 103-4 specifies the size of each sample in a track, notably the sizes of the base split layer parts of the samples. To describe additional split layer in sample description, the sample description is extended to provide an indication of a number of split layers in a track. In particular, the sample table box ‘stbl’ 103 also includes split sample sizes boxes 103-5. These split sample sizes boxes 103-5 are used to specify the size of each part of sample. In particular, the sample table box ‘stbl’ 103 includes one split sample sizes box 103-5 per split layer, except for the base split layer. Indeed, the sizes of the base split layer parts of the samples are stored in the sample size box ‘stsz” 103-4. The sample table box ‘stbl’ 103 further includes a split layer configuration box 103-7. This split layer configuration box 103-7 specifies the split layer configuration of the additional split layer(s), notably the order of the parts of samples in the chunks. The information in sample-to-chunk box ‘stsc’ 103-2 and in the chunk offset box ‘stco’ 103-3 apply to each split layer and lead to data organization as in the media data box ‘mdat’ 104-1. Therefore, the sample-to-chunk information and the chunk offset information is not repeated in the sample description. Such sample table box ‘stbl’ allows indicating, for a single track encapsulation, the different parts for the samples available in the track with a sample organization (in the data) matching this organization in different parts. Therefore, regarding the metadata of the media file, the description of base split layer follows the regular sample description using expected boxes under 'stbl' (like 103 illustrated on Figure 3) or parameters in track fragment boxes to indicate sample to chunk (103-2), sample sizes (103-4), sample timings (not represented) and offsets (103-2) in the data part (104-1) of the media file, or segment. It is considered, by default, that properties for samples, group of samples or part of samples that can be indicated by sample groups or subsample information boxes (not represented) within the sample table box apply to the "full sample". To apply only to the base sample or to a given set of additional layers, it is possible to use an additional signaling in the sample description or to use NAL unit mapping for NAL unit based encoded video tracks. Figure 4 illustrates a second embodiment of a media file 100 according to the disclosure. In this media file, the number of samples per chunk is the same for all split layers but the chunk offsets are indicated per split layer. The data organization consists in storing chunks for split layers as possibly non-contiguous chunks, each chunk having the same number of parts of samples, possibly in any order. Moreover, each chunk includes data of a given split layer only. The chunks for base split layer are disposed before the chunk for additional split layers in the media data box ‘mdat’ 104-2. In particular, in this second embodiment, the sample-to-chunk information (i.e. the number of samples per chunk, 103-2) is not repeated in the sample description while the chunk offsets are indicated per split layer (chunk offset box 103-3 for the base split layer and split chunk offsets boxes 103-6 for additional split layers). The information in the sample-to-chunk box ‘stsc’ box 103-2 then apply to each split layer and lead to media data organization as in the media data box 104-2. The chunk offsets are indicated in instances of an additional split chunk offsets box 103-6. For example, the sample table box ‘stbl’ includes one split chunk offsets box 103-6 per split layer. In this second embodiment, the split layer configuration box 103-7 can indicate a declaration order of the split chunk offset boxes, notably after the split layer configuration. The split sample sizes boxes 103-5 are configured to specify the size of each part of the samples, except for the base split layer. The sizes of the base split layer parts is still indicated in the sample size box ‘stsz’ 103-4. The split sample sizes boxes 103-5 are preferably declared in a same container box (not represented here) The locations of a given chunk of a given additional split layer in the media data box ‘mdat’ 104-2 can be determined from the split chunk offsets boxes 103-6, and from the declaration order of these split chunk offsets boxes 103-6. The split chunk offsets boxes 103-6 are preferably declared in a same container box (not represented here). Following this order allows a parser to map a chunk offset to a given additional split layer. It is also possible to consider more flexible data organization in which the chunk offset provides a split layer indication. For example, the split layer indication can be an index in the split layer configuration box 103-7. This split layer indication also allows to have more than one split layer in a chunk, the number of additional split layers being indicated in the split chunk offsets box 103-6. This organization may be indicated in the sample description, notably in a dedicated box, for example in the split layer configuration box 103-7. This organization may be convenient to make easier the reconstruction of base samples and for sample entry type corresponding to the coding configuration of the base split layer. This organization can also be more convenient for backward compatibility to make sure that less advanced players will be able to parse the media file. Other data organization can be considered. For example, it is possible to have different sample to chunk (i.e. number of sample in a chunk) per split layer. In this case, additional boxes in sample description are used to describe the number of samples per chunk for each split layer. More particularly, a split sample sizes box 103-5 can consist in a box container. .It consists in a hierarchy of sample size boxes to describe non-base split layers (i.e. additional split layers) in terms of sample sizes for a given split layer. This box contains one or more existing sample size box (‘stsz’ or its compact version ‘stz2’), as follows: SplitSampleSizesBox extends Box ('ssss') { / / as many as split layers declared in a box like 103-7 / / if there are no data in split sample, allow its size=0 SampleSizeBox boxes[]; / / and only of this type / / if there is no data for a sample, a sample size equal to 0 is allowed. } Preferably, a SplitSampleSizesBox defines the size of the non-base split layer(s) in the order they are defined in the box 103-7, e.g. SpiitsampieDescriptionsBox. Each of the SampleSizeBox included in SplitSampleSizesBox has the same sample count as the SampleSizeBox 103-4 in the SampleTableBox. The SampleSizeBox in the sample description of the track 103-4 defines the size of the samples in the base split layer only. It is allowed to have a sample size of 0 if the data for the full sample is only present in other (additional) split layers. In other words, in a sample size box for a given split layer within a SplitSampleSizesBox, it is allowed to have a sample size of 0 if there is no data for the given split layer. An example of syntax for box 103-7 can be as follows: SpiitsampieDescriptionsBox extends Box('sshd'){ SampleEntryBox boxes [] / / any sample entry of the same base type as the sample entry, eg Ihvl / lhel... } A SpiitsampieDescriptionsBox provides for each additional split layer one or more decoder configurations if desired, in the sample description of the track. In SampleEntry of a track with split samples, there may be at most one SpiitsampieDescriptionsBox. It is a container box for sample entries describing each split layer, excluding the base split layer. It should be indicated when split layers are present in a media file or when encapsulation module is configured to store a track as split samples). The base split layer is described in a sample entry within the sample description box ‘stsd” 103-1. Preferably, the chunking is the same between all split layers, i.e. a single SampleToChunk box 103-2 is present in the track description. As well boxes 103-6 may consist in a box container, containing one or more existing chunk offset boxes, as follows: SplitChunkOffsetBox extends Box('ssco') { / / as many as split layers declared in a box like 103-7 Box chunk offsets[]; / / only stco or co64 } The ChunkOffsetBox or ChunkLargeOffsetBox indicates the chunk size of the samples from the base split layer only. It is allowed to have a chunk size of 0 if all data for the samples of the chunk are in split layers. TimeToSampleBox, CompositionToDecodeBox, SyncSampleBox and all other boxes are defined for the complete bitstream (include all Alls, Access Units). When bytes are trimmed from the split layers, any of these boxes referring to byte ranges (like for example CENC SAI, subsamples) will have to be re-interpreted by the player. If SplitChunkOffsetBox is absent, the chunk offset for split layer N is considered equal to the chunk offset of split layer N-1 (if 0, chunk offset of the base) plus the total size of the samples for the split layer N-1 in the chunk. In other words, split layers chunks offsets are reconstructed from lower split layers offsets. Otherwise (SplitChunkOffsetBox is present), the offset for chunk K for split layer N is given by the K-th entry of stco or co64 box at the N-th entry in this box (1 being the first entry). There should be as many entries in each of these chunk offsets boxes as there are entries in the chunk offset box 103-3 for the base split layer (present in the SampleTableBox). In other words, split layers have the same sample to chunk grouping, and chunk offsets or enhancement sizes indicated per split layer. Finally, in SampleTableBox (‘stbl’), at most one box 103-7 may be defined, preferably as the first box in the ‘stbl’ as follows (box name and box type are just examples): SplitSampleLayerConfigBox extends FullBox('sslc' , 0, 0){ unsigned int(32) num split layers; } Where num_spiit_iayers gives the number of split layers, not including the base split layer, used in this track. The base split layer uses a classical sample description. The number of split layers may differ from the number of configurations (or reconstruction levels considering the different combinations of split layers). This box provides information for all boxes describing split layers, at least the number of split layers and their relative order. It may further contain information about the possible reconstruction processes for different levels and describes backward compatibility of the base split layer declared in the sample entry of the track. It is possibly organized in another split samples configuration box, as follows: SplitSamplesConfigurationBox extends FullBox('ssdC', 0, 0) { bit(l) all split layers independent; / / tiles, no coding dependencies between the split layers bit(2) single base compatible; bit(l) no default reaggregation; bit(l) other reaggregations; bit(3) reserved; if (other reaggregations) { unsigned int(32) num reaggregations; [ unsigned int(32) nb split layers reagg; unsigned int(32) split layers index[nb split layers reagg]; unsigned int(32) num configurations; unsigned int(32) split stsd idx[num configurations]; ](num reaggregations) } } With the following semantics: all_split_layers_independent indicates, if set to 1, that all split layers are independent and could be processed independently. single base compatible takes one of the following values: 0: the sample can be reaggregated to be compliant to the associated sample entry type 1: the track without the additional split layers is conformant to the sample entry type and does not have any empty samples introduced by the splitting process. - 2: the track without the additional split layers is conformant to the sample entry type only after removal of 0-size samples. 3: reserved no_defauit_reaggregation indicates, if set to 1, that the default reaggregation is not possible. The default reaggregation consists in appending to the sample data the split layer data in the order the layers are described in the SplitSampleDescriptionsBox other_reaggregations indicates, if set to 1, that other reaggregations than the default one are possible. This bit is set to one if no_def auit_reaggregation is set to 1. num_reaggregations indicates the number of additional possible reaggregations nb_spiit_iayers_reagg indicates the number of split layers in a reaggregation spiit_iayers_index indicates the index of the split layer to aggregate, with the value 0 being the base sample data num_configurations gives the number of split sample entries used by this reconstruction spiit_stsd_idx is the index of a sample entry used by this reaggregation, the value 0 meaning the base sample entry, the value 1 being the first entry in spiitsampieDescriptionsBox. This value shall not be greater than the number of entries in SpiitsampieDescriptionsBox. Any codec specific data (e.g parameter sets or equivalent for non video media types), present in this entry is forwarded to the decoder in the order of appearance in this list. Preferably, the last entry shall indicate the highest codec requirements for the reaggregation, e.g. highest profile-tier-level in video coding. The default reconstruction process is to aggregate the base split layer sample data and each of the additional split layers, in the order they are defined in the SpiitsampieDescriptionsBox. In a variant the split sample descriptions box (for example called SpiitsampieDescriptionsBox) is directly inserted in the sample description box ‘stsd’ 103-1 ‘of the base split layer. This box, at most one in a track, is considered mandatory if split layers are present in this track. Therefore, the parser can inspect the split sample descriptions box, along with the information for base split layer, to know whether filtering some data allows to reconstruct a compliant bitstream for the indicated sample entry type. Figure 5 illustrates a third embodiment of a media file 100 according to the disclosure. In this media file, the metadata part of the media file includes an intermediate level between track and sample levels. In particular, the description for split samples is organized in the metadata part of the media file 101 in an intermediate level between track and sample levels. For example, this intermediate level is named ‘split’ track description. Such intermediate level discloses a description for split samples. Each ‘split track’ (504, 505) is contained in a track. A ‘split track’ contains the parts of a given layer of the samples (base split layer or additional layer). A full sample corresponding to the aggregation of the parts of samples described in each split track. More particularly, the track box ‘trak’ includes ‘split track’ boxes 504, 505 for each split layer of the samples. A ‘split track’ box is a specific container that has a dedicated type identifier “4CC”. A ‘split track’ is part of its containing track, meaning that the parts of samples it describes can be reaggregated with the parts of samples described in other ‘split tracks’ of this containing track. Therefore, a ‘split track’ box is a container to describe a sequence of parts of samples from a same media file stored in a media data box 104 that the track refers in a data reference box (not represented). A ‘split track’ can also be seen as a container for a set of partial samples (or parts of samples) that can be reaggregated to reconstruct the full samples of a media file. The difference with classical single track encapsulation is that: data for a chunk of full samples are no more contiguous in the media data box the sample description is no more unique but split into different ‘split tracks’. Each ‘split track’ box includes a split chunk offsets box and a split sample sizes box. For example, the ‘split track’ 504 includes a split chunk offsets box 551-1 and a split sample sizes box 551-2, and the ‘split track’ 505 includes a split chunk offsets box 552-1 and a split sample sizes box 552-2. The split chunk offsets box indicates the offsets of the chunks for the parts of samples. The split sample sizes box indicates the sizes of the part of samples in each chunk. A ‘split track’ inherits the common sample description (timing, properties, possibly the number of samples per chunk) from its containing track. However, it may override or complement some parts of this description. The parts to complement or to override concern the sizes of the part of samples (in split sample sizes box 551-2 or 552-2), possibly the number of samples per chunk (in split chunk offsets box 551-1 or 552-1), the coding configuration for the split layer. The common sample description is extended with information about split layers (like box 103-7 from embodiments at sample description level). There may be as many split tracks as split layers in the box 103-7. The track box ‘trak’ at track description level only contains common description to all split layers. As a variant, as shown on Figure 5, the ‘trak’ box 102 contains common description to all split layers with the information for the base split layer. The first and second embodiments disclosed previously for chunking can also apply in this embodiment for split tracks. For fragmented case, the number of samples per chunk and sample flags are used as for the base split layer. For the additional split layers, it is proposed to have an extension to track runs to describe split layer sizes and optionally offsets. It is proposed to add in TrackFragmentBox at most one additional box, as follows: SplitSampleTrackRunBox extends FullBox('srun', 0, 0) { / / nb entries is the number of split layers indicated in a box like 103-7 / / sample count is the sample count from the track run box for (i=0; i<nb entries; i++) { signed int(32) data offset; { unsigned int(32) sample size; }[ sample count ] } } Note: the sample_size may be encoded on 16 bits for a split layer to save some description cost. The number of bits may be flags controlled, in this box or in default sample description flags in one of the track fragment boxes. In a variant, a self-contained version of the SplitSampleTrackRunBox is defined as follows: SplitSampleTrackRunBox extends FullBox('srun', 0, 0) { unsigned int(32) nb entries; / / the same as the number of split layers sslc.num split layers unsigned int(32) sample count; / / the same as the sample count from immediately preceding track run for (i=0; i<nb entries; i++) { signed int(32) data offset; / / offset relative to the containing moof { unsigned int(32) sample size; / / 16 bits may also be used }[ sample count ] } } Preferably, each SplitSampleTrackRunBox immediately follows the TrackFragmentBox containing the information for the base split layer. This avoids the need for additional signaling of a mapping between a run of samples in a fragment (a ‘trun’ box) and its split into split samples (e.g. the ‘srun’ box). Preferably the encapsulation module uses explicit data offset are from the containing ‘moof’ box, using appropriate flags values defined in ISOBMFF. As another embodiment, the split sample boxes or split tracks may be replaced by an SAI-based approach (use of Sample Auxiliary Information boxes). An array of 'saiz' / 'saio' boxes may be used per split layer. The 'aux_info_type' field of the 'saiz' box would provide the sample entry type corresponding to the layer and the 'aux_info_type_parameter’ of the ‘saiz’ box would indicate the split layer index that is described. The values for ‘split layer index’ correspond to the values declared in a split layer configuration box, like 103-7. The ‘sample_info_size’ of the ‘saiz’ box would provide the data size for the sample part in the split layer with index equal to ‘aux_info_type_parameter’ value. Optionally, ‘saio’ may be used to provide byte offset in the media data to locate the split layer data when not stored contiguously as illustrated on Figure 3. Using an array of sample auxiliary box would allow to deal with more than dual split layers and splitting in more split layers (multiple levels or tiles). To handle temporal scalability, the sample auxiliary may consider that related sample may be an empty sample (sample with sample_size = 0). To indicate that a track is stored as split samples or split layer, there may be a dedicated brand, that when declared as major brand, would require the support of the boxes for split layer and split samples description (e.g. like 103-7, 103-5 or 504, 505 and their respective variants) to be able to render the full track. When this brand is listed in the compatibility brand, player may choose rendering the base split layer only, all the split layer or any of the reaggregation indicated in the SplitSampleDescriptionsBox. Figure 6 illustrates an example of steps of an encapsulation process according to an embodiment of the disclosure. The illustrated steps may be carried out in an encapsulation module, for example in encapsulation module 205 in Figure 2. At step 600, the encapsulation module receives the image data source to be encapsulated. The data can be a media data 225 and other media data 230, as shown in Figure 2. The media data can be one or more images. The encapsulation module can be configured to encapsulate the image data source as split samples meaning that a part of the samples are indexed and described according to the classical sample description from ISO / IEC 14496-12 while other, additional or complementary, parts of the samples are indexed and described using additional boxes. Then, at step 605, the encapsulation module is configured after having received image data in step 600. Such a configuration step 605 may comprise setting encapsulation options such as setting parameters indicating whether the file is fragmented or not, whether to generate a single media file or multiple segment files, whether there is a single media data box or several, whether the data are multiplexed if other media data (such as media data 230 in Figure 2) are to be encapsulated in the same track or not, etc. The settings of the configuration may be set by a user through a graphical user interface or through a command line. Alternatively, these settings may be hard-coded in the server wherein the media data are encapsulated. According to some embodiments, the configuration of the encapsulation module comprises configuration of the compression module such as compression module 240 in Figure 2. The compression module can be configured by selecting a same layered codec or different codecs for the different media data 225 or the ones in 230. This may be indicated in a compression configuration box in the metadata part of the media file 235. At step 605, during the configuration of the encapsulation module, the encapsulation module starts creating the media file with the top-level metadata boxes, for example the following metadata boxes when ISOBMFF is used: FileTypeBox (‘ftyp’) or SegmentTypeBox (‘styp’) (for segment files), MovieBox (‘moov’) and optionally MovieFragmentBox (‘moof’) if the media file is configured for fragmentation. The ‘ftyp’ or ‘styp’ box may contain a brand value indicating that samples are stored as split samples (either as major_brand or in the list of compatible brands). When the data read in step 600 correspond to a sequence of images of a video or to a sequence of volumetric frames for 3D content, the metadata part is indicated under a top-level ‘moov’ box, possibly followed by zero or more ‘moof’ top-level boxes, depending on encapsulation settings. The sample description can be initialized in step 605 by creating, a sample table box ‘stbl’ (like 103 on Figures 3, 4 and 5) and sample entries (within stsd box 103-1 on figures 3, 4, 5). For example, a sample entry type may indicate the coding format in use for the base split layer or may indicate the coding format for the set of the base split layer plus the one or more additional split layers, as discussed in reference to Figures 3 to 5. After being configured, the encapsulation module may begin reading, at step 610, a first part of the sample data. The first part of the sample data corresponds to data associated with a base split layer of the sample. In the case of video or volumetric data, a first part of the sample data may correspond to a frame or an image from media data 225 and one or more other parts of the sample may correspond to a frame or an image from the other media data 230. A part may correspond to a spatial part of a frame. It may correspond to a decimated version of a frame or coarse representation of a frame or partial representation of a frame. At step 615, the first part of the sample data is stored in the media file, and then indexed in the metadata part of the media file according to one of the embodiments described in reference to Figures 3, 4 or 5. Then, the encapsulation module performs a test 625 to determine whether the sample includes another part. Such another part of data corresponds to data associated with an additional split layer of the sample. In particular, when another part exists in the sample (test 625 true), the encapsulation module obtains the next part of the sample, possibly with side information describing it or as encoded version that the encapsulation module may inspect to obtain information about the part. This information is used to store data in the data part of the file in step 635 and to describe and index this sample part in the metadata part of the media file at step 640 according to one of the embodiments described in reference to Figures 3, 4 or 5. The steps 630, 635 and 640 are iterated until the last part of the sample is processed. In particular, when test 625 allows determining that there is no other part in the sample (test 625 false), it means that the last part of the sample has been processed. Then, the encapsulation module checks at test 645, from input media whether more samples are to be processed. When test 645 is true, the encapsulation module processes the next sample according to steps 610 to 640. The obtained media file (e.g., media file 235 in Figure 2) may be stored as one media file (e.g. a .mp4 file) or as multiple segment files (e.g. ,m4s files). When test 645 is false, it means that there is no other sample to be processed. Then, the media file is saved for later use by media applications at step 650. Figure 7 illustrates a parsing process according to an embodiment of the disclosure. At step 705, a parser receives a media file encapsulated according to the previously described encapsulation process. At step 710, the parser interprets metadata of the media file to determine for example whether the media file contains split samples. The parser also interprets the metadata to determine whether reconstruction levels can be achieved by the parser. The parser also interprets the metadata to determine whether it can support at least one of these reconstruction levels. In particular, at step 720, the parser checks whether a reconstruction level is supported by the parser. If no reconstruction level (test 720 false) can be supported, the parser returns an error in 730. Otherwise, the parser selects one supported reconstruction level in step 725. Then, at step 735, the parser checks whether the samples are encapsulated as split sample or not. If the samples are not encapsulated as split sample (test 735 false), the sample description is read at step 740 and samples are extracted from media data at step 745 to build a bitstream at step 750 for the decompression module 250, optionally preceded by a decryption of the bitstream by decryption module 251. If the samples are encapsulated as split sample (test 735 true), the split layer configuration is read, at step 755, from the split layer configuration box to determine the number of split layers for the selected reconstruction level. Then, at step 760, the parser obtains a part of sample from split layer description and media data. This can be obtained by split layer size and possibly split layer offset information that can be embedded in the media file according to embodiments described before in relation with Figures 3, 4 and 5. Then, the parser tests, at step 765 if it has obtained the expected number of split layers for the selected reconstruction level or not. If there is another part of sample in the media data, then steps 760 and 765 are reiterated. If there is no more part of sample in the media data , the parser aggregates the sample parts that have been obtained by simple concatenation in order of the split layer, by default, or by following a reconstruction rule that may be indicated in the metadata part of the media file 235 according to one of the embodiments described previously in relation with Figures 3, 4 and 5. Finally, the aggregation of the parts of the sample have been performed allows obtaining a reconstructed bitstream that can be sent at step 750 to the decompression module 250, optionally preceded by a decryption by decryption module 251. At step 735, even if additional split layers are present in the media file, a player may ignore it or may decide to process only the base split layer. Then, the number of split samples to process is zero and the next step is step 740. A player may ignore the additional split layers because it does not understand the boxes describing the split of samples and can only process regular ISOBMFF boxes and samples descriptions. A player may ignore the additional split layers even if it does understand the boxes describing the split of samples, for example for application needs or user settings. Processing only the base split layer or backward compatibility, is possible as long as none of the description structures (like sample group, subsample, sample auxiliary information) include byte ranges from the additional split layers (the additional parts). This works well in most cases, but may be problematic in common encryption using subsamples: if all split layers are protected, a reader may encounter a CENC SAI (Common Encryption Sample Auxiliary Information) describing more bytes than are present in the sample. One approach to this problem could be to use per split layer CENC SAI with a mechanism as an array of ‘saiz’ (respectively ‘saio’) boxes for each split layer SAI size (respectively SAI offset) which explicitly warns readers about such cases. For use cases where only the base split layer is encrypted, it is proposed to allow a CENC SAI to describe less than the sample size, leaving unmapped bytes in clear. This would avoid adding many subsamples with no protected byte ranges (to match the constraint of same number encrypted bytes than bytes in the sample size for the base split layer). This could be indicated by using a new CENC scheme which explicitly warns readers about such cases, or in within a CENC box, for example the TrackEncryptionBox as described below. Preferably, full sample encryption modes would not be recommended (to preserve access to split layers) as settings of the encapsulation module in step 605. As well, the encapsulation module may use an extended version of the TrackEncryptionBox to indicate the encryption settings: for example, the length of encryption keys (e.g. 128 bits or 256 bits, the use of full sample or subsample encryption, whether the auxiliary information is provided via a ‘sene’ box or through ‘saiz’ / ’saio’ boxes. The so-extended TrackEncryptionBox may have the following syntax (in bold): aligned(8) class TrackEncryptionBox extends FullBox('tenc', version, flags=0) { unsigned int(8) reserved = 0; if (version==0) { unsigned int(8) reserved = 0; } else if (version >1) { / / version is 1 or greater unsigned int(4) default crypt byte block; unsigned int(4) default skip byte block; } else { / / version is 2 or greater unsigned int(l) AES_256_flag; unsigned int(l) full_sample_encryption; unsigned int(1) use_senc; unsigned int(l) allow_partial_last_block; unsigned int(l) unmapped_bytes; unsigned int(l) pattern_mode; unsigned int (1) multi_key; unsigned int (1) reserved_bit; } unsigned int(8) default isProtected; unsigned int(8) default Per Sample IV Size; unsigned int(8)

[16] default KID; if (default isProtected ==1 &&default Per Sample IV Size == 0) { unsigned int(8) default constant IV size; unsigned int(8)[default constant IV size] default constant IV; } } with the following for the new fields (other remain unchanged): AES_256_flag is a flag indicating, when set that 256-bit key length is in use and, when not set that 128-bit length is used for the encryption keys. full_sample_encryption is a flag indicating, when set, that full sample encryption is in use and when not set that subsample encryption is in use. use_senc is a flag indicating, when set, that the ‘sene’ box is used to provide CENC SAI and, when not set, that sample auxiliary information is used to provide CENC SAI. In a variant, this field uses 2 bits (using for example the reserved bit) to indicate: 0 - no CENC SAI; 1 - use of sene box; 2 - use of sample auxiliary boxes; 3 - reserved. allow_partial_last_block is a flag indicating, when set, that the last cypher block in a sample may be a partial cipher block (less than 16 bytes). When not set, it indicates that there are no partial cypher blocks (no cipher blocks less than 16 bytes); unmapped_bytes is a flag indicating, when set, that there may be more encrypted bytes (Bytesof ProtectedData) indicated than actually present in a sample. When not set, it indicates that there are should be no unmapped bytes, i.e. the number of encrypted bytes should correspond to the sample size. This may be indicated only when full_sample_encryption is set to false. When not present, the default value should be considered as false. pattern_mode is a flag indicating whether the pattern encryption mode is in use (value 1) or not (value 0). multi_key is a flag indicating whether there is a single key in use (value 0) of multiple keys (value 1). In a variant, these additional fields may be indicated by through the flags field of the box. This variant may assume default values for the additional fields when the corresponding flags values are not set. For example, by default AES_256_flag is set to false, use_senc is set to false, full_sample_encryption is set to false (thus making use of subsample encryption implicit), allow_partial_last_block is set to false, unmapped_bytes is set to false, multi_key is set to false These parameters improve the interoperability between writers and readers by listing clearly in the encrypted file the CENC features in use. They may be exposed in MIME types as a sub-parameter as soon as the MIME type indicated protected media stream. As well, there may be a dedicated CENC or ISOBMFF brand indicating the use of this extended track encryption box. Figure 8 is a schematic block diagram of a computing device 800 for implementation of one or more embodiments of the disclosure. The computing device 800 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 800 comprises a communication bus connected to: - a central processing unit 804, such as a microprocessor, denoted CPU; - a random access memory 808, denoted RAM, for storing the executable code of the method of embodiments of the disclosure as well as the registers adapted to record variables and parameters necessary for implementing the method according to embodiments of the disclosure, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example; - a read only memory 806, denoted ROM, for storing computer programs for implementing embodiments of the disclosure; - a network interface 812 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface 812 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 packets 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 804; - a graphical user interface 816 may be used for receiving inputs from a user or to display information to a user; - a hard disk 810 denoted HD may be provided as a mass storage device; - an I / O module 818 may be used 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 806, on the hard disk 810 or on a removable digital medium such as for example 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 804, in order to be stored in one of the storage means of the communication device 800, such as the hard disk 806, before being executed. The central processing unit 804 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 disclosure, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 841 is capable of executing instructions from main RAM memory 808 relating to a software application after those instructions have been loaded from the program ROM 806 or the hard-disc (HD) 810 for example. Such a software application, when executed by the CPU 801, causes the steps of the flowcharts of the disclosure to be performed. Any step of the algorithms of the disclosure may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC ("Personal Computer"), a DSP ("Digital Signal Processor") or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA ("Field-Programmable Gate Array") or an ASIC ("Application-Specific Integrated Circuit"). 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 skilled person 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 disclosure, that being determined solely by the appended claims. In particular, the different features from different embodiments may be interchanged, where appropriate. Each of the embodiments of the disclosure described above can be implemented solely or as a combination of a plurality of the embodiments. Also, features from different embodiments can be combined where necessary or where the combination of elements or features from individual embodiments in a single embodiment is beneficial. 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 of encapsulating media data into a media file, the media data comprising base data and additional data to the base data, the method comprising:generating a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising:a first part including data of the base data associated with the single time and at least one additional part including data of the additional data associated with the single time,generating descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track;generating the media file comprising the generated track and the descriptive metadata.

2. The method according to claim 1, the descriptive metadata comprises decoder configuration for the first part of the samples only and at least one decoder configuration for an aggregation of the first part and at least one additional part of the samples.

3. The method according to claim 1 or 2, wherein the information relative to the organization of the at least one additional part of the samples in the track comprises configuration information for the organization of the at least one additional part of the samples in the track and size information for the size of the at least one additional part of the samples.

4. The method according to any one of claims 1 to 3, wherein the information relative to the organization of the at least one additional part of the samples in the track is stored in at least one additional box in a track box of the media file.

5. The method according to claim 3 and 4, wherein the configuration information is stored in an additional box in a sample table box in the track box of the media file.

6. The method according to claim 5, wherein the size information is stored in at least one additional box in the sample table box.

7. The method according to any one of claims 1 to 7, wherein the different parts of the samples are stored in chunks in the media file.

8. The method according to claim 7, wherein each chunk includes data of the first parts and of additional parts of different samples, the first parts of the different samples being contiguous in the chunk.

9. The method according to claim 8, wherein the additional parts of the different samples are contiguous in the chunk.

10. The method according to claim 7, wherein each chunk includes only data of the first part of different samples or data of an additional part of different samples.

11. The method according to any one of claims 7 to 10, the information relative to the organization of the at least one additional part of the samples in the track also comprises chunk offset information for each chunk.12., The method according to claims 5 and 11, wherein the chunk offset information is stored in at least one additional box in the sample table box.

13. The method according to claims 5 and 11, wherein the chunk offset information and the size information are stored in different boxes in at least one additional box in the track box, outside the sample table box.

14. The method according to any one of claims 1 to 13, wherein the base data correspond to data associated with a base split layer and the additional data correspond to data associated with at least one additional split layer of a multi-layer bitstream.

15. The method according to claim 14, wherein the at least one additional split layer corresponds to at least one enhancement layer.

16. The method according to any one of claims 1 to 13, wherein the base data and the additional data are data corresponding to different types of coding formats.

17. The method according to any one of claims 1 to 13, wherein the base data and the additional data are data corresponding to spatial parts of a video.

18. The method according to any one of claims 1 to 17, wherein the sequence of samples further comprises an empty sample.

19. A method of parsing a media file including a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising:a first part including data of base data associated with the single time andat least one additional part including data of additional data associated with the single time,descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track;wherein the method comprises a reconstruction of the samples based on the first part of the samples only or based on an aggregation of the first part of the samples with the at least one additional part of the samples according to said descriptive metadata.

20. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 1 to 19, when loaded into and executed by the programmable apparatus.

21. A computer-readable storage medium storing instructions of a computer program product according to claim 20.

22. A device for encapsulating media data into a media file, the media data comprising base data and additional data to the base data, the device comprising a processor configured to:generate a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising:a first part including data of the base data associated with the single time and at least one additional part including data of the additional data associated with the single time,generate descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track;generate the media file comprising the generated track and the descriptive metadata.

23. A device for parsing a media file including:a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising:a first part including data of base data associated with the single time andat least one additional part including data of additional data associated with the single time,descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track;wherein the device comprises a processor configured to reconstruct the samples based on the first part of the samples only or based on an aggregation of the first part of the samples with the at least one additional part of the samples according to said descriptive metadata.

24. A media file including:a track comprising a sequence of samples, each sample being associated with a single time, each sample comprising:a first part including data of base data associated with the single time andat least one additional part including data of additional data associated with the single time,descriptive metadata including information relative to the organization of the at least one additional part of the samples in the track.

Images