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

Abstract

The present disclosure concerns a method of encapsulating a bitstream of media data into a media file, in a processing device, the bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the method comprising: generating a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, − generating descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one sub- bitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream, generating the media file comprising the track and the descriptive metadata.

Description

[0001] METHOD AND APPARATUS FOR ENCAPSULATING AND PARSING A MEDIA FILE HAVING SPLIT SAMPLES

[0002] FIELD OF THE DISCLOSURE

[0003] The present disclosure concerns a method and a device for encapsulating and parsing a media file.

[0004] BACKGROUND OF DISCLOSURE

[0005] 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.

[0006] 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.

[0007] 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.

[0008] 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.

[0009] 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.

[0010] 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.

[0011] ISOBMFF allows creating files encapsulating layered media, for example MV-HEVC or LC-EVC, either:

[0012] - 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

[0013] - 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.

[0014] 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.

[0015] For example, Figure 1 shows a media file with an interleaving of base layer and enhancement layer data for each sample.

[0016] 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. A 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).

[0017] 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-2 lb or 110-22b) and process only the ones for the base layer (e.g. 110-1 la.... 110-2 la or 110-22a).

[0018] Moreover, in ISO / IEC 14496-15, when the codec for the base is a different codec, the multitrack approach is recommended.

[0019] 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.

[0020] SUMMARY OF THE DISCLOSURE

[0021] The present disclosure has been devised to address one or more of the foregoing concerns.

[0022] According to a first aspect, there is provided a method of encapsulating a bitstream of media data into a media file, in a processing device, the bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the method comprising: generating a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, generating descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one subbitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream, generating the media file comprising the track and the descriptive metadata.

[0023] Thanks to these features, a mutualization of the information of property or configuration of a bit-stream is possible, in order to avoid duplicating property box(es).

[0024] In an embodiment, the sub-bitstream represents one of a layer, a tile, a subpicture, a 3D region, an operating point or a reconstruction point as defined by a multi-layer or multi-codec coding format or the data corresponding to a split-layer which is a part of a full sample from a multi-layer bitstream or multi-codec bitstream. In an embodiment, a sample table box in a track box of the media file comprises at least one sample entry box describing the sample, wherein the at least one information of the at least one sub-bitstream is stored in a single property container box in the sample table box, wherein the single property container box comprises a list of a plurality of property boxes or fullboxes, wherein each property box or fullbox describes an information representing a property or a configuration that may further characterize a sub-bitstream.

[0025] In an embodiment, the at least one sample entry box comprises a property association box associating an identifier of the at least one sub-bitstream to a property index list, wherein the property index list may list zero, one or more of the plurality of property boxes or fullboxes.

[0026] In an embodiment, the bitstream comprises a plurality of sub-bitstreams, and the property association box further comprises, for each property box or fullbox, a flag indicating that the property box or fullbox is essential or not.

[0027] In an embodiment, another property box or fullbox may be declared directly within the at least one sample entry box, the property index list further comprising the other property box or fullboxes.

[0028] In an embodiment, the property index list associated with the identifier of a subbitstream may be null if no property box is associated with the sub-bitstream.

[0029] In an embodiment, the property association box further comprises, for each property box or fullbox, an indicator that the property box or fullbox is declared in the single property container box or in the at least one sample entry box.

[0030] In an embodiment, the indicator is a bit within the property association box.

[0031] In an embodiment, the property index list associated with the identifier of a subbitstream may be null if no property box is associated with the sub-bitstream.

[0032] In an embodiment, the property index list associated with the identifier of a subbitstream is null if all property boxes are associated with the sub-bitstream. Alternatively, in an embodiment, the property index list associated with the identifier of a sub-bitstream is equal to zero if all property boxes are associated with the sub-bitstream.

[0033] In an embodiment wherein the data corresponds to a split-layer which is a part of a full sample from a multi-layer bitstream or multi-codec bitstream, 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.

[0034] 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).

[0035] 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- 1 ike constructs and keeps the original ISOBMFF design for base data (or base split layer).

[0036] 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.

[0037] 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.

[0038] 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.

[0039] In an embodiment, the size information is stored in at least one additional box in the sample table box.

[0040] In an embodiment, the different parts of the samples are stored in chunks in the media file.

[0041] 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.

[0042] 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.

[0043] 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.

[0044] In an embodiment, the additional parts of the different samples are contiguous in the chunk.

[0045] In an embodiment, each chunk includes only data of the first part of different samples or data of an additional part of different samples.

[0046] 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.

[0047] In an embodiment, the chunk offset information is stored in at least one additional box in the sample table box.

[0048] 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.

[0049] In an embodiment, the base data corresponds to data associated with a base layer and the additional data correspond to data associated with at least one additional layer of a multi-layer bitstream. In an embodiment, the at least one additional layer corresponds to at least one enhancement layer.

[0050] In an embodiment, the base data and the additional data are data corresponding to different types of coding formats.

[0051] In an embodiment, the base data and the additional data are data corresponding to spatial parts of a video.

[0052] 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 a base split layer.

[0053] In an embodiment, the generated media file includes sample auxiliary information associated with the base data and / or with the additional data., and the descriptive metadata includes information concerning the position of the sample auxiliary information in the media file.

[0054] In an embodiment, the base data correspond to data of a first part of a sample associated with a base split layer of the track and the additional data correspond to data of at least one additional part of the sample associated with at least one additional split layer of the track. The sample auxiliary information is associated with the base split layer and / or with at least one additional split layer.

[0055] In an embodiment, the information concerning the position of the sample auxiliary information is stored in a box describing the samples of a track of the media file.

[0056] In an embodiment, the box describing the samples of a track of the media file includes directly at least one box containing information concerning the position of the sample auxiliary information associated with the base split layer.

[0057] In an embodiment, the box describing the samples of a track of the media file includes directly a box containing an offset position of the sample auxiliary information associated with the base split layer in the media file and a box containing a size of the sample auxiliary information associated with the base split layer.

[0058] In an embodiment, the box describing the samples of a track of the media file includes directly a box containing a sample auxiliary information header associated with the base split layer, the sample auxiliary information header providing description and configuration information associated with sample auxiliary information associated with the base split layer.

[0059] In an embodiment, the box describing the samples of a track of the media file includes a box containing size information for the size of the parts of samples of the base split layer. In an embodiment, the different parts of the samples are stored in chunks in the media file. The box describing the samples of a track of the media file includes box containing a chunk offset information associated with the base split layer.

[0060] In an embodiment, for each additional split layer, the box describing the samples of a track of the media file includes a container box including the information concerning the position of the sample auxiliary information associated with the additional split layer.

[0061] In an embodiment, the box including the information concerning the position of the sample auxiliary information associated with an additional split layer includes a box containing an offset position of the sample auxiliary information associated with the additional split layer in the media file and a box containing a size of the sample auxiliary information associated with the additional split layer.

[0062] In an embodiment, the box including the information concerning the position of the sample auxiliary information associated with an additional split layer includes a box containing a sample auxiliary information header associated with the additional split layer, the sample auxiliary information header providing description and configuration information associated with sample auxiliary information associated with the additional split layer.

[0063] In an embodiment, the box including the information concerning the position of the sample auxiliary information associated with an additional split layer includes a box containing size information for the size of the samples of the additional split layer.

[0064] In an embodiment, the different parts of the samples are stored in chunks in the media file. The box including the information concerning the position of the sample auxiliary information associated with an additional split layer includes a box containing a chunk offset information associated with the additional split layer.

[0065] In an embodiment, the box describing the samples of a track of the media file includes a container box containing a number of additional split layers in the media file.

[0066] In an embodiment, the box containing a number of additional split layers in the media file includes a flag indicating whether the sample auxiliary information contained in the box included directly in the box describing the samples of a track of the media file is related to the base split layer.

[0067] In an embodiment, the box describing the samples of a track of the media file includes a box containing decoder configuration for the base split layer and at least one decoder configuration for the additional split layer, and parameters for defining a reconstruction process of a reaggregated sample from data of the base split layer and additional split layers. In an embodiment, the information relative to the organization of the at least one additional part of the samples comprises an indication indicating whether the base data and the additional data associated with a single time are contiguous or are in different chunks.

[0068] In an embodiment, said indication includes a parameter that have: a first value to indicate that the base data and the additional data associated with a single time are contiguous; or a second value to indicate that the base data and the additional data associated with a single time are in different contiguous chunks; or a third value to indicate that the base data and the additional data associated with a single time are in different non-contiguous chunks.

[0069] 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.

[0070] 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.

[0071] According to another aspect, there is provided a computer-readable storage medium storing instructions of a computer program product as previously described.

[0072] 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] The data organization of the sample parts preserves encryption, sample grouping description, subsample information. According to another aspect, there is provided a device for encapsulating a bitstream of media data into a media file, the bitstream comprising at least one subbitstream that comprises a contiguous or non-contiguous sequence of bytes, wherein the device comprises a processor configured to : generate a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, generate descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one subbitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream, generate the media file comprising the track and the descriptive metadata.

[0077] According to another aspect, there is provided a device for parsing a bitstream of media data into a media file, a media file including: the bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the media file comprising a track and descriptive metadata, the track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, the descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one sub-bitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one subbitstream, wherein the device comprises a processor configured to decode the at least one sub-bitstream according to the descriptive metadata.

[0078] According to another aspect, there is provided a media file including a bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the media file comprising: a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, and descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one sub-bitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream.

[0079] 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:

[0080] Figure 1 illustrates an encapsulated media file according to the state of the art:

[0081] Figure 2 illustrates an embodiment of a system for encapsulation and parsing of images or sequence of images;

[0082] Figure 3 illustrates an encapsulated media file according to a first embodiment of the disclosure;

[0083] Figure 4 illustrates an encapsulated media file according to a second embodiment of the disclosure;

[0084] Figure 5 illustrates an encapsulated media file according to a third embodiment of the disclosure;

[0085] Figure 6 illustrates an encapsulation process according to an embodiment of the disclosure;

[0086] Figure 7 illustrates a parsing process according to an embodiment of the disclosure;

[0087] Figure 8 is a schematic block diagram of a computing device for implementation of one or more embodiments of the disclosure; and

[0088] Figure 9 illustrates a sample table box of an encapsulated media file according to an embodiment of the disclosure;

[0089] Figure 10 illustrates a sample table box of an encapsulated media file according to another embodiment of the disclosure;

[0090] Figure 11 illustrates a media information box of a track of an encapsulated media file according to another embodiment of the disclosure;

[0091] Figure 12 illustrates a media information box of a track of an encapsulated media file according to another embodiment of the disclosure;

[0092] Figure 13 illustrates a media information box of a track of an encapsulated media file according to another embodiment of the disclosure.

[0093] Figure 14 illustrates a media information box of a track of an encapsulated media file according to another embodiment of the disclosure.

[0094] DETAILED DESCRIPTION OF THE DISCLOSURE

[0095] 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 (‘esgh’) 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.

[0096] 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.

[0097] 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).

[0098] 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.

[0099] 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).

[0100] The media data 225 may be considered as a base layer whereas the other media data 230 (or a part of) may be considered as one or more additional layers.

[0101] 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.

[0102] 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.

[0103] 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.

[0104] 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.

[0105] 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 layer 225 (e.g. HEVC bitstream) or to decoded images from the base layer plus one or more additional layers 230 (e.g. L-HEVC bitstream), notably one or more enhancement layers. For volumetric media, base layer may correspond to the geometry of the content, while additional layers may correspond to one or more attributes.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] It can be noted that in ISOBMFF, a sample usually designates all the data associated with a single time in a track. In other words, a track does not include two samples that share the same decoding timestamp and / or that share the same composition timestamp. All the data of a given sample in a track are contiguous.

[0110] In following embodiments, the terms split-sample or split sample or full sample or aggregate sample or re-aggregate sample or reconstructed sample are equivalent and designate a sample, i.e. all the data associated with a single time, from a multi-layer bitstream or multi-codec bitstream. All the data of a given split-sample may be non-contiguous. A split-sample is composed of multiple split-layers, a base split-layer and one or more additional split-layers. A split-layer may represent a single video enhancement layer or several ones, or multiple tiles, or part of a sample coded with a different codec from another part of the sample of a multi-layer bitstream or multi-codec bitstream. It can be noted that a split-layer is used to designate a part of a sample, typically a part of a full sample, and can also be denoted sample layer, sample extent, sample split, sample part or sample supplement. According to embodiments described herein, some data structures from ISOBMFF usually describing samples are used to describe the base split-layer and additional data structures are defined to describe the additional split-layers and their re-aggregation as full samples or split-samples.

[0111] 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).

[0112] 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 ‘moot’), 101 containing metadata defining the position of the media data in the media data box(es) and temporal position of the media data.

[0113] 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.

[0114] 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.

[0115] 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 associated with an enhancement layer or one or more tiles for example. An enhancement layer is a layer that enhances a base layer (in quality, temporal resolution or spatial resolution or a combination of those for video streams).

[0116] 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). The base layer comprises the parts of the samples corresponding to the base split layer.

[0117] 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. An additional layer comprises the parts of the samples corresponding to an additional split layer.

[0118] 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-11 b. 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.

[0119] 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.

[0120] Besides, the sequence of parts of samples corresponding to a split layer may comprise one or more empty parts of samples (not illustrated). Such empty parts of samples in a split layer are used to align the split samples, notably according to a temporal level of the base split layer, e.g. when an additional split layer is used to increase the frame rate of the base split layer or of an additional split layer with lower temporal level.

[0121] 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.

[0122] 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).

[0123] 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).

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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)

[0142] 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).

[0143] Following this order allows a parser to map a chunk offset to a given additional split layer.

[0144] 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.

[0145] 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.

[0146] 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:

[0147] 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 .

[0148] } 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. SplitSampleDescriptionsBox. 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.

[0149] An example of syntax for box 103-7 can be as follows:

[0150] SplitSampleDescriptionsBox extends Box ( ' sshd' ) { SampleEntryBox boxes [ ] / / any sample entry of the same base type as the sample entry, eg Ihvl / lhel...

[0151] }

[0152] A SplitSampleDescriptionsBox 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 SplitSampleDescriptionsBox. 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.

[0153] Preferably, the chunking is the same between all split layers, i.e. a single SampleToChunk box 103-2 is present in the track description.

[0154] As well boxes 103-6 may consist in a box container, containing one or more existing chunk offset boxes, as follows: SplitChunkOf f setBox extends Box ( ' ssco' ) { / / as many as split layers declared in a box like 103-7 Box chunk offsets [ ] ; / / only stco or co64 }

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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):

[0159] SplitSampleLayerConf igBox extends FullBox ( 'sslc' , 0 , 0 ) { unsigned int ( 32 ) num split layers ;

[0160] }

[0161] Where num_split_layers 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.

[0162] 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: SplitSamplesConf igurationBox 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 ;

[0163] [ unsigned int ( 32 ) nb split layers reagg ; unsigned int ( 32 ) split layers index f nb split layers reagg] ; unsigned int ( 32 ) num configurations ; unsigned int ( 32 ) split stsd idx f num configurations ] ;

[0164] ] ( num reaggregations )

[0165] }

[0166] }

[0167] 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:

[0168] 0: the sample can be reaggregated to be compliant to the associated sample entry type

[0169] 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.

[0170] - 2: the track without the additional split layers is conformant to the sample entry type only after removal of 0-size samples.

[0171] 3: reserved no_default_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_default_reaggregation is set to 1 . num_reaggregations indicates the number of additional possible reaggregations nb_split_layers_reagg indicates the number of split layers in a reaggregation splitjayersjndex 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 split_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 SplitSampleDescriptionsBox. This value shall not be greater than the number of entries in SplitSampleDescriptionsBox. 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.

[0172] 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 SplitSampleDescriptionsBox. In a variant the split sample descriptions box (for example called SplitSampleDescriptionsBox) 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.

[0173] 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.

[0174] 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.

[0175] 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”.

[0176] 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.

[0177] 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).

[0178] 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.

[0179] 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’.

[0180] 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.

[0181] 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.

[0182] In a variant, the split sample sizes box 551-2 or 552-2 in a split track can be a sample size box ‘stsz’ or a compact sample size box ‘stz2,’ as defined by ISOBMFF.

[0183] In a variant, the split chunk offsets box 551-1 or 552-1 in a split track can be a chunk offset box ‘stco’ or a chunk large offset box ‘co64’, as defined by ISOBMFF.

[0184] Sample auxiliary information for a part of samples described in a split track 504 or 505 can be stored anywhere in the same file as the data of a part of sample, typically in a media data box ‘mdat’ or an identified media data box ‘imda’, as defined by ISOBMFF. The data of the sample auxiliary information for a given split track is located anywhere within the data part of the file, using auxiliary information offsets, described by a sample auxiliary information offsets box 'saio' defined in this given split track to indicate the location of the data of the sample auxiliary information, and using an associated sample auxiliary information sizes box ‘saiz’ also defined in this given split track to indicate the size of the data of the sample auxiliary information. The sample auxiliary information offsets box 'saio' and the sample auxiliary information sizes box ‘saiz’ are associated by having the same values for their aux_info_type and aux_info_type_parameter parameters.

[0185] 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.

[0186] The first and second embodiments disclosed previously for chunking can also apply in this embodiment for split tracks.

[0187] 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

[0188] / / 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 ] } }

[0189] 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.

[0190] 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 ] } }

[0191] 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.

[0192] 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).

[0193] 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.

[0194] Figure 6 illustrates an example of steps of an encapsulation process according to an embodiment of the disclosure.

[0195] The illustrated steps may be carried out in an encapsulation module, for example in encapsulation module 205 in Figure 2.

[0196] 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.

[0197] 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.

[0198] 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.

[0199] 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 (‘moot’) 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 ‘moot’ 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.

[0200] 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.

[0201] 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.

[0202] 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.

[0203] 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.

[0204] The steps 630, 635 and 640 are iterated until the last part of the sample is processed.

[0205] 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.

[0206] 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).

[0207] 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.

[0208] Figure 7 illustrates a parsing process according to an embodiment of the disclosure.

[0209] At step 705, a parser receives a media file encapsulated according to the previously described encapsulation process.

[0210] 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.

[0211] 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.

[0212] Then, at step 735, the parser checks whether the samples are encapsulated as split sample or not.

[0213] 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.

[0214] 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.

[0215] 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.

[0216] Then, the parser tests, at step 765 if it has obtained the expected number of split layers for the selected reconstruction level or not.

[0217] If there is another part of sample in the media data, then steps 760 and 765 are reiterated.

[0218] 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.

[0219] 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.

[0220] 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.

[0221] 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 ;

[0222] } 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 (l) use_senc ; unsigned int (l) allow_partial_last_block ; unsigned int ( l) unmapped_bytes ; unsigned int ( 1 ) pattern_mode ; unsigned int (1) multi_key; unsigned int (1) reserved_bit ;

[0223] } unsigned int ( 8 ) default isProtected; unsigned int ( 8 ) default Per Sample IV Size ; unsigned int ( 8 )

[0016] 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):

[0224] 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 Protected Data) 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).

[0225] In a variant, the new version of the TrackEncryptionBox still provides the parameters describing the encryption pattern, when the pattern mode is on (and the semantics remains the same as in above variant): aligned (8) class TrackEncryptionBox extends FullBox ( ' tenc ' , version, flags=0) { unsigned int(8) reserved = 0; if (version==0) { unsigned int(8) reserved = 0;

[0226] } else if (version == 1) { / / version is 1 or greater unsigned int(4) default crypt byte block; unsigned int(4) default skip byte block;

[0227] } else if (version ==2) { unsigned int(l) AES_256_f lag; unsigned int(l) full_sample_encryption; unsigned int(l) 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 ; if (pattern_mode == 1) { unsigned int (4) default crypt byte block; unsigned int (4) default skip byte block;

[0228] }

[0229] } unsigned int ( 8 ) default isProtected; unsigned int ( 8 ) default Per Sample IV Size; unsigned int ( 8 )

[0016] 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; } }

[0230] 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

[0231] 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. To expose in the MIME type the encryption features in use, there may be 2 options, with a common aspect about what to expose. The exposed features can be taken from the flags of the TrackEncryptionBox defined above. Since they are flags, their presence indicates that the feature is in use, their absence indicates that the feature is not in use. The Table below proposes a mapping of TrackEncryptionBox’s flags to keys to use in MIME type parameter.

[0232] Then, about where to indicate these parameters, a first option could be to indicate these encryption features within the “codecs” parameter._A dedicated prefix is introduced, to be used in the “codecs” parameter as a “cenc” prefix. The “cenc” prefix may be present only when the codec contains one of the protection scheme.

[0233] For example codecs= " codec=resv.cenc.hvc1.1.6.L93.B0 + cenc=k256. full. sene" means encrypted HEVC with AES-256, single key, full sample encryption with presence of sene box. The prefix could also correspond to the protection scheme, or the protection scheme could be listed as the first value of the “cenc” parameter. This could avoid having it in the “codec” value. A second option could be to indicate these encryption features as a new MIME parameter, called for example “encryption”, letting the codecs value unchanged.

[0234] For example,: codecs- 'resv.cenc. hvc1.1.6. L93. BO” encryption-’ k256. full. sene" means encrypted HEVC with AES-256, single key, full sample encryption with presence of sene box. As for the first option, the protection scheme could also be indicated in the value for this new “encryption” parameter. The first option may have greater support in players since it is common that they parse the “codecs” parameter (while another parameter than “codecs” might be ignored).

[0235] 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:

[0236] - a central processing unit 804, such as a microprocessor, denoted CPU;

[0237] - 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;

[0238] - a read only memory 806, denoted ROM, for storing computer programs for implementing embodiments of the disclosure;

[0239] - 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;

[0240] - a graphical user interface 816 may be used for receiving inputs from a user or to display information to a user;

[0241] - a hard disk 810 denoted HD may be provided as a mass storage device;

[0242] - an I / O module 818 may be used for receiving / sending data from / to external devices such as a video source or display.

[0243] 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.

[0244] 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.

[0245] 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 C' Application-Specific Integrated Circuit").

[0246] Figure 9 illustrates a sample table box (“SampleTableBox”, ‘stbl’) 900 of an encapsulated media file according to another embodiment of the disclosure.

[0247] The sample table box is included in a track box ‘trak’ in a movie box “moov’ comprising meta data of the media file.

[0248] The “SampleTableBox” ‘stbl’ 900 comprises a split sample layer configuration box (“SplitSampleLayerConfigBox”, ‘sslc’) 905, a sample description box (“SampleDescriptionBox”, ‘stsd’) 910, a sample size box (“SampleSizeBox”, ‘stsz’) 935 and a chunk offset box (“ChunkOffsetBox, ‘stco’) 940.

[0249] The “SampleTableBox” ‘stbl’ 900 can also comprises a Sample auxiliary information header (“SAI header”) 945.

[0250] The “SampleTableBox” ‘stbl’ 900 can also comprises a sample auxiliary information sizes box (“SampleAuxiliarylnformationSizesBox”, ‘saiz’) 950 and a sample auxiliary information offsets box (“SampleAuxiliarylnformationOffsetsBox ‘saio’) 955.

[0251] The sample table box 900 comprises the description of the samples (also denoted “full” or reaggregated samples in this disclosure) of a track in an encapsulated media file. A sample in a track usually corresponds to all the data associated with a single time or single period of time. Samples of a track are split into several split layers, a base split layer and one or more additional split-layers, to allow storing the data of media samples as non-contiguous pieces of data in a track. A split-layer is a part of a sample data (i.e. part of data of a media sample). The data of parts of samples described by a split layer can be data of a single video enhancement layer or several ones, or multiple tiles, or data of parts of samples encoded with different codecs or coding formats, or data of parts of samples where each part of these samples corresponds to one or more timed units of an independently encoded sub-bitstream from a plurality of multiplexed sub-bitstreams. In other words, a split-layer may contain a single video enhancement layer or several ones, or multiple tiles, or part of a media sample coded with a different codec from another part of the sample for example.

[0252] A base split-layer is a split-layer corresponding to the part of sample data whose offsets / sizes and timing are described by boxes in “SampleTableBox” or “TrackFragmentBox” (e.g. sample size, chunk offset, sample to chunk, time to sample).

[0253] Additional split-layer is a split-layer whose offsets / sizes are described within a “SplitLayerBox” in the “SampleTableBox” or “TrackFragmentBox”.

[0254] The original media sample can be obtained by reaggregating the data of the splitlayers following the reconstruction process described by “SplitSamplesConfigurationBox”.

[0255] In this embodiment, sample auxiliary information (SAI) can be associated with a split layer part of a sample.

[0256] Sample auxiliary information (SAI) per split layer, also denoted split layer auxiliary information, is data associated with the data of the parts of samples described by a split layer, that is not part of the sample data, and that cannot be intended to be rendered by itself but provides supplemental information, such as data complementing the data of the associated part of sample, e.g. transparency or depth data, or any descriptive metadata of the associated part of sample, or encryption metadata, e.g. Common Encryption sample auxiliary information (CENC SAI) containing cryptographic information such as initialization vector or subsample information for partial encryption of the sample data.

[0257] The “SplitSampleLayerConfigBox” ‘sslc’ 905, when present, indicates that samples of the track are split into split-layers and describes general configuration information about the split layers of a track.

[0258] Preferably, this “SplitSampleLayerConfigBox” ‘sslc’ 905 is defined in the “SampleTableBox” ‘stbl’ 900 before the “SampleDescriptionBox” ‘stsd’ 910. This allows a parser to be informed early in a parsing process that the track comprises split layers.

[0259] The “SplitSampleLayerConfigBox” ‘sslc’ 905 can be defined as follows:

[0260] Box Type: 'sslc'

[0261] Container: SampleTableBox or TrackFragmentBox

[0262] Mandatory: No

[0263] Quantity: Zero or one (per container) aligned(8) class SplitSampleLayerConfigBox extends Full Box('sslc', 0, 0)

[0264] { unsigned int(l) SAI_per_split_layer_flag; bit(7) reserved; unsigned int(32) num_split_layers;

[0265] }

[0266] Where

[0267] SAI_per_split_layer_flag indicates, if set to 0, that sample auxiliary information directly declared in the “SampleTableBox” is related or apply to the reaggregated sample, and if set to 1 , that sample auxiliary information directly declared in the “SampleT ableBox” is related or apply to the part of the sample corresponding to the base split layer only. num_split_layers gives the number of split layers used in this track, not including the base split layer.

[0268] The indication SAI_per_split_layer_flag is optional.

[0269] In a variant, if not present, it is assumed that sample auxiliary information declared by the “SampleAuxiliarylnformationSizesBox” ‘saiz’ 950 and the “SampleAuxiliarylnformationOffsetsBox” ‘saio’ 955 directly in the “SampleTableBox” ‘stbl’ 900 is related or apply to the part of the sample corresponding to the base split layer. This variant improves the backward compatibility for common encryption using subsamples. This guarantees that CENC SAI associated with a base split layer does not describe subsamples that are not present in parts of samples of the base split layer.

[0270] In another variant, if not present, sample auxiliary information declared by the “SampleAuxiliarylnformationSizesBox” ‘saiz’ 950 and the ’’SampleAuxiliarylnformationOffsetsBox” ‘saio’ 955 directly in the “SampleTableBox” ‘stbl’ 900 is related or apply to the reaggregated sample. This variant reduces the description cost when more than the base split layer, i.e. the base split layer and / or one or more of the additional split layers, need to be protected. In such case, CENC SAI declared at base split layer level by the “SampleAuxiliarylnformationSizesBox” ‘saiz’ 950 and the “SampleAuxiliarylnformationOffsetsBox” ‘saio’ 955 can describe subsamples for the base split layer and for any of the additional split layers without having to declare additional “SampleAuxiliarylnformationSizesBox” ‘saiz’ and

[0271] “SampleAuxiliarylnformationOffsetsBox” ‘saio’ for each additional protected split layer, for instance for the split layer box 960, described below.

[0272] Sample entries are defined to give detailed information about the coding type used, and any initialization information needed for that coding for each split-layer.

[0273] A sample entry describing the base split-layer is a sample entry defined in “SampleDescriptionBox”. A sample entry describing an additional split layer is a sample entry defined in a “SplitSampleDescriptionsBox” in the sample entry describing the base split layer.

[0274] The “SampleDescriptionBox” ‘stsd’ 910 describes the format of each split layer that composes the samples in a track.

[0275] The “SampleDescriptionBox” ‘stsd’ 910 includes a sample entry box (“SampleEntry”, e.g. ‘hvc1’). The “SampleEntry” box 915 defines the codec and configuration information needed for decoding the base split layer. For instance, the four- character code corresponding to the box type of the “SampleEntry” box 915, e.g. ‘hvcT for HEVC data, ‘vvcT for VVC data, indicates the codec or format of the base split layer and additional decoder configuration box (not represented) provides decoder configuration information for initializing the decoder for the base split layer.

[0276] The “ChunkOffsetBox” ‘stco’ 940 or (“ChunkLargeOffsetBox”) and the “SampleSizeBox” ‘stsz’ 935 (or “CompactSampleSizeBox”) in the “SampleTableBox” provides the locations of the chunks and sizes of the data of 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 other than the base split layer.

[0277] A time to sample box, “TimeToSampleBox” 'stts', and a composition to decode box, “CompositionToDecodeBox” 'cslg', and “SyncSampleBox” ‘stss’ (not represented) in “SampleTableBox” ‘stbl’ 900 are defined for the ’’full” samples (i.e. include all reaggregated samples).

[0278] The “SampleEntry” box 915 further contains a split sample descriptions box (“SplitSampleDescriptionsBox” ‘sshd’) 920 that comprises a sample entry box (“SampleEntry”, e.g. hvT) 925 defining the codec and configuration information needed for decoding a split layer (notably an additional split layer), other than the base split layer.

[0279] The “SplitSampleDescriptionsBox” 920 can be defined as follows:

[0280] Box Type: 'sshd'

[0281] Container: SampleEntry box in SampleDescriptionBox

[0282] Mandatory: Yes, if split layers are present

[0283] Quantity: Zero or one aligned(8) class SplitSampleDescriptionsBox extends Box('sshd’) { SampleEntry()[];

[0284] }

[0285] Where SampleEntry()[] is an array of “SampleEntry” boxes describing the codecs and configuration information, if needed, for decoding each split layer (notably each additional split layer), excluding the base split layer.

[0286] The type of sample entry form for the “SampleEntry” box 925, e.g. a visual sample entry (“VisualSampleEntry”), a volumetric visual sample entry (“VolumetricVisualSampleEntry”), a metadata sample entry (“MetadataSampleEntry”), or others, is determined by the media handler of the track, using a suitable form, either the same form or a compatible form as the “SampleEntry” box 915 of the base split layer.

[0287] In a variant, the 1-based index of the “SampleEntry” box 925 in declaration order in “SplitSampleDescriptionsBox” ‘sshd’ 920 indicates the layer identifier (layerjd) of the layer represented by the split layer described by the “SampleEntry” box 925. The value 0 is reserved and represents the base layer. The layer identifier (layerjd) may correspond to an identifier in the bitstream, e.g. the nuhjayerjd of a Network Abstraction Layer (NAL) unit-based bitstream, or a tilejd or any other identifier in the bitstream that characterizes the data encapsulated in a split-layer. In an alternative, the layer identifier (layerjd) may be any arbitrary identifier.

[0288] The “SampleEntry” box 915 further contains a split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 930, as defined by reference to Figure 4 in this disclosure, and with following box type, container, mandatory and quantity values:

[0289] Box Type: 'ssdC

[0290] Container: SampleEntry box in SampleDescriptionBox

[0291] Mandatory: Yes, if split layers are present

[0292] Quantity: Zero or one

[0293] The “SplitSamplesConfigurationBox” provides parameters for defining the reconstruction process of a reaggregated or “full” sample from data of the base split layer and additional split layers. It is recalled that 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 “SplitSampleDescriptionsBox”.

[0294] The “SplitSamplesConfigurationBox” allows describing alternative possible reconstruction processes, if any, and backward-compatibility of the base split-layer in the sample entry of the track.

[0295] In a variant of reconstruction process, if, in “SplitSamplesConfigurationBox”, the no_default_reaggregation parameter is set to 1 indicating that there is no default reaggregation of the split layers in the reconstruction process and other_reaggregations parameter is set to 0 indicating that there is no other reaggregation rules in the reconstruction process, this indicates to the parser that the split layers are not intended to be reaggregated in a “full” sample. In other words, each split layer may be processed individually.

[0296] The SampleTableBox ‘stbl’ 900 also comprises a container box, named split layer box (“SplitLayerBox” ‘sply’) 960. The “SplitLayerBox” describes the offsets / sizes and additional descriptive information, e.g. sample auxiliary information, of a part of the “full” samples for a split layer (notably an additional split layer) other than the base split layer. The “SampleTableBox” ‘stbl’ 900 comprises a “SplitLayerBox” ‘sply’ 960 for each split layer (notably each additional split layer) declared in the SplitSampleDescriptionsBox ‘sshd’ 920. The number of “SplitLayerBox(es)” ‘sply’ 960 in the “SampleTableBox” corresponds to the parameter num_split_layers in the “SplitSampleLayerConfigBox” ‘sslc’ 905, when present.

[0297] The “SplitLayerBox(es)” 960 are declared in the “SampleTableBox” ‘stbl’ 900 (or T rackFragmentBox) in the same order as their corresponding “SampleEntry” box(es) 925 in “SplitSampleDescriptionsBox” ‘sshd’ 920. Thus, the ith“SampleEntry” box in the “SplitSampleDescriptionsBox” ‘sshd’ is associated with the ith“SplitLayerBox” ‘sply’ in declaration order.

[0298] The “SplitLayerBox” 960 can be defined as follows:

[0299] Box Type: 'sply'

[0300] Container: SampleTableBox or TrackFragmentBox

[0301] Mandatory: Yes, if split layers are present

[0302] Quantity: Exactly one per split layer aligned(8) class SplitLayerBox extends Box('sply’) {

[0303] Box boxes[];

[0304] }

[0305] Where boxes are any box defined within the scope of a split layer.

[0306] For example, boxes defined within the scope of a split layer may comprise any one of the following boxes (without being limitative):

[0307] “SampleGroupDescriptionBox” ‘sgpd’ and possibly “SampleToGroupBox” ‘sbgp’ for describing properties associated with a split-layer for a group of samples.

[0308] “SubSamplelnformationBox” ‘subs’ for describing properties associated with a byte-range within the sample data of a split-layer.

[0309] “MetaBox” ‘meta’ and its sub-boxes for describing general untimed metadata associated with a split layer. “UserDataBox” ‘udta’ for describing informative user-data associated with a splitlayer.

[0310] In a variant, the “SplitLayerBox” comprises an identifier to associate the “SplitLayerBox” with the corresponding “SampleEntry” box of the “SplitSampleDescriptionsBox” so that the “SplitLayerBox” 960 comprising the identifier having a value i is associated with the 1 -based ith“SampleEntry” box in the “SplitSampleDescriptionsBox” ‘sshd’ 920 in declaration order. The value i equal to 0 is reserved and represents the base split-layer. In other words, the “SplitLayerBox” comprising an identifier equal to i contains boxes related to the split layer corresponding to the 1 -based ith“SampleEntry” box in the “SplitSampleDescriptionsBox” ‘sshd’ in declaration order.

[0311] For non-fragmented cases, the “SplitLayerBox” ‘sply’ 960 comprises a sample size box (“SampleSizeBox”, ‘stsz’) 965 (or“CompactSampleSizeBox”) and a chunk offset box (“ChunkOffsetBox” ‘stco’) 970 (or “ChunkLargeOffsetBox”) describing the locations of the chunks and sizes of the data of the split layer (notably the additional split layer). It is allowed to have a sample size of 0 in the “SampleSizeBox” ‘stsz’ 965 (or “CompactSampleSizeBox”) if there is no data for the given split layer.

[0312] The “SampleSizeBox” ‘stsz’ 965 (or “CompactSampleSizeBox”) included in each “SplitLayerBox” 960 has the same sample count as the “SampleSizeBox” ‘stsz’ 935 (or “CompactSampleSizeBox”) in the “SampleTableBox” ‘stbl’ 900 of the track.

[0313] If “ChunkOffsetBox” ‘stco’ 970 (or ChunkLargeOffsetBox) is absent in a “SplitLayerBox” ‘sply’ 960, the chunk offset for this split layer is equal to the chunk offset of the preceding split layer described by the preceding “SplitLayerBox” ‘sply’, if any in the “SampleTableBox”, or, by default, is equal to the chunk offset of the base split layer plus the total size of the samples for this preceding split layer in the chunk. Otherwise (“ChunkOffsetBox” 970 (or ChunkLargeOffsetBox) is present in a “SplitLayerBox” ‘sply’ 960), there is as many entries as there are entries in the “ChunkOffsetBox” 940 (or ChunkLargeOffsetBox) for the base split layer (present in the “SampleTableBox” 900).

[0314] Preferably, the chunking is the same between all split layers, i.e. a “SampleToChunk” box ‘stsc’ (not represented) is present only in the “SampleTableBox” 900. In a variant, if the chunking is different between split layers, a “SampleToChunk” box ‘stsc’ is present in the “SampleTableBox” 900 for describing the chunks of data for the base split layer, and another “SampleToChunk” box ‘stsc’ is present in each “SplitLayerBox” 960. Sample auxiliary information for parts of samples corresponding to the base split layer or for the reaggregated samples, depending on the SAI_per_split_layer_flag value or on the default behaviour configured when SAI_per_split_layer_flag is absent, can be stored in the media file. Such sample auxiliary information, also denoted split layer auxiliary information, can be stored anywhere in the same file as the data of the samples, typically in a “MediaDataBox” ‘mdat’ or “IdentifiedMediaDataBox” ‘imda’. Their location and size are indicated by the “SampleAuxiliarylnformationSizesBox” ‘saiz’ 950 and the SampleAuxiliarylnformationOffsetsBox ‘saio’ 955 in the “SampleTableBox” 900.

[0315] The data of the sample auxiliary information for a split layer (notably an additional split layer) other than the base split layer is located, anywhere within the file, using auxiliary information offsets, described by a “SampleAuxiliarylnformationOffsetsBox” 'saio' 985 defined in the “SplitLayerBox” 960 corresponding to the split layer, and using an associated “SampleAuxiliarylnformationSizesBox” ‘saiz’ 980 defined in same “SplitLayerBox” 960 to indicate the size of the data of the sample auxiliary information. The “SampleAuxiliarylnformationOffsetsBox” 'saio' 985 and the “SampleAuxiliarylnformationSizesBox” ‘saiz’ 980 are associated by having the same values for their aux_info_type and aux_info_type_parameter parameters.

[0316] A plurality of sample auxiliary information per split layer can be stored by using a plurality of “SampleAuxiliarylnformationOffsetsBox” 'saio' and “SampleAuxiliarylnformationSizesBox” ‘saiz’ with different values of the tuple {aux_info_type, aux_info_type_parameter}.

[0317] The format of the sample auxiliary information associated with a split layer is determined by the parameter aux_info_type, when present in both “SampleAuxiliarylnformationSizesBox” and “SampleAuxiliarylnformationOffsetsBox”. If aux_info_type and aux_info_type_parameter are omitted then the implied value of aux_info_type is either (a) in the case of transformed content, such as protected content, the scheme_type included in a protection scheme info box (“ProtectionSchemelnfoBox”) or in a scramble scheme info box (“ScrambleSchemelnfoBox”), or otherwise (b) the sample entry type of the sample entry associated with the split layer.

[0318] Optionally, a SAI header 945, 975, can be defined to provide description and configuration information associated with sample auxiliary information.

[0319] In a variant, the SAI header 945, 975 is defined as a container box, e.g. a “SAIDescriptionBox” ‘sade’, comprising all description and configuration information of all sample auxiliary information at the same box level as the “SAIDescriptionBox”. The “SAIDescriptionBox” consists of one or more “SAIHeaderBox”. Each “SAIHeaderBox” documents a single sample auxiliary information data.

[0320] The “SAIDescriptionBox” is specified as follows:

[0321] Box Type: ' sade'

[0322] Container: SampleTableBox, trackFragmentBox or SplitLayerBox

[0323] Mandatory: No

[0324] Quantity: zero or one aligned(8) class SAIDescriptionBox extends Box('sade')

[0325] {

[0326] }

[0327] A “SAIHeaderBox” contained in “SAIDescriptionBox” is specified as follows:

[0328] Box Type: ' saih'

[0329] Container: SAIDescriptionBox

[0330] Mandatory: Yes, in SAIDescriptionBox

[0331] Quantity: At least one aligned(8) class SAIHeaderBox extends FullBox('saih', version=0, flags)

[0332] { unsigned int(32) aux_info_type; unsigned int(32) aux_info_type_parameter; unsigned int(1) sai_content_encoding_present_flag; unsigned int(7) reserved = 0; if (aux_info_type == 'mime') { utf8string content_type;

[0333] } else if (aux_info_type == 'uri ') { utf8string encoding_uri_type;

[0334] }

[0335] If (sai_content_encoding_present_flag) { utf8string content_encoding; / / optional

[0336] }

[0337] }

[0338] Where: aux_info_type is an integer that identifies the type of the sample auxiliary information; aux_info_type_parameter identifies the “stream” of sample auxiliary information having the same value of aux_info_type and associated with the split layer. The semantics of aux_info_type_parameter is determined by the value of aux_info_type. sai_content_encoding_present_flag when set to 1 indicates that the sample auxiliary information is encoded with the content_encoding method. sai_content_encoding_present_flag when set to 0 indicates that the sample auxiliary information is not encoded. content_type is the MIME type of the SAI. If the SAI is content encoded, then the content type refers to the SAI after content decoding. encoding_uri_type is an absolute URI, that is used as a type indicator. content_encoding optionally indicates that the SAI is encoded and needs to be decoded before interpreted. The values are as defined for Content-Encoding for HTTP / 1.1. Some possible values are “gzip”, “compress” and “deflate”. An empty string indicates no content encoding. Note that the SAI is stored after the content encoding has been applied.

[0339] A “SAIHeaderBox” in a “SAIDescriptionBox” describes the sample auxiliary information data represented by the “SampleAuxiliarylnformationOffsetsBox” 'saio' and “SampleAuxiliarylnformationSizesBox” ‘saiz’ having the same tuple {aux_info_type, aux_info_type_parameter} and located at the same box level as the “SAIDescriptionBox”.

[0340] In a variant, SAI header information, e.g. 945 for a base split layer, or 975 for an additional split layer, is stored in respective sample entry box, e.g. 915 for a base split layer, or 925 for an additional split layer. This allows a parser to have all description and configuration information for a split layer (base or additional split layer) and for their associated sample auxiliary information in a same location, in “SampleDescriptionBox” ‘stsd’.

[0341] In a variant, SAI header information and associated sample auxiliary information, e.g. 945 with 950 and 955, or 975 with 980 and 985, are associated together by defining the SAI header and associated “SampleAuxiliarylnformationSizesBox” ‘saiz’ and “SampleAuxiliarylnformationOffsetsBox” ‘saio’ in a same container box, e.g. a “SAIBox” ‘saib’, defined as follows:

[0342] Box Type: 'saib'

[0343] Container: SampleTableBox, trackFragmentBox or SplitLayerBox

[0344] Mandatory: No

[0345] Quantity: zero or more aligned(S) class SAI Box extends Box('saib')

[0346] {

[0347] SAIHeaderBox header;

[0348] SampleAuxiliarylnformationSizesBox sizes;

[0349] SampleAuxiliarylnformationOffsetsBox offsets;

[0350] Box otherBoxesfl; / / Other boxes for additional configuration information

[0351] }

[0352] Where: otherBoxes are boxes providing additional configuration or description information for sample auxiliary information associated with a specific aux_info_type and aux_info_type_parameter, for instance a decoder configuration box providing information for decoding the data of the sample auxiliary information. sizes and offsets provide the sizes and offsets of the sample auxiliary information. header is a “SAIHeaderBox” defined as follows:

[0353] Box Type: 'saih'

[0354] Container: SAI Box

[0355] Mandatory: Yes

[0356] Quantity: Exactly one aligned(8) class SAIHeaderBox extends FullBox('saih', version=0, flags)

[0357] { unsigned int(32) aux_info_type; unsigned int(32) aux_info_type_parameter; unsigned int(1) sai_content_encoding_present_flag; unsigned int(7) reserved = 0; if (aux_info_type == 'mime') { utf8string content_type;

[0358] } else if (aux_info_type == 'uri ') { utf8string encoding_uri_type;

[0359] }

[0360] If (sai_content_encoding_present_flag) { utf8string content_encoding; / / optional

[0361] }

[0362] }

[0363] Where: aux_info_type, aux_info_type_parameter, sai_content_encoding_present_flag, content_type, encoding_uri_type and content_encoding are defined as previously described for SAIHeaderBox.

[0364] In this variant, the value of (flags & 1) is set to 1 for both “SampleAuxiliarylnformationSizesBox” ‘saiz’ and

[0365] “SampleAuxiliarylnformationOffsetsBox” ‘saio’. This allows not repeating the aux_info_type and aux_info_type_parameter parameters in “SampleAuxiliarylnformationSizesBox” ‘saiz’ and

[0366] “SampleAuxiliarylnformationOffsetsBox” ‘saio’. The aux_info_type and aux_info_type_parameter parameters of “SampleAuxiliarylnformationSizesBox” ‘saiz’ and “SampleAuxiliarylnformationOffsetsBox” ‘saio’ are derivated from aux_info_type and aux_info_type_parameter parameters defined in “SAIHeaderBox”.

[0367] For fragmented cases, the sample chunking is used as for the base split-layer. The “TrackFragmentBox" comprises a “SplitLayerBox” for each split layer other than the base split layer, the “SplitLayerBoxes” being declared in same order as the corresponding “SampleEntry” box in “SplitSampleDescriptionsBox”.

[0368] For the split layers other than the base split layer, a simplified version of track runs, denoted “SplitLayerTrackRunBox” ‘srun’, is used to describe split layer sizes and optionally offsets. In other words, the “SplitLayerTrackRunBox” describes the sizes and optionally offsets for the data in a split layer. It is defined as follows:

[0369] Box Type: 'srun'

[0370] Container: SplitLayerBox

[0371] Mandatory: Yes

[0372] Quantity: One or more aligned(8) class SplitLayerTrackRunBox extends FullBoxfsrun’, 0, 0) { signed int(32) data_offset;

[0373] { unsigned int(32) sample_size;

[0374] } [ sample_count ]

[0375] }

[0376] Where: sample_count the number of samples being added in this run; also the number of rows in the following table (the rows can be empty). sample_count is the sample_count from the track run box ‘trun’ describing the base split layer in the same track fragment box. data_offset is added to the implicit or explicit base_data_offset established in the track fragment header.

[0377] It can be noted that 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.

[0378] In a track fragment box, there are as many SplitLayerTrackRunBox in each SplitLayerBox as there are TrackRunBox in the track fragment box.

[0379] Preferably, the “SplitLayerBoxes” are declared after the “TrackRun Boxes” in a track fragment box.

[0380] Sample auxiliary information per split layer as defined for non fragmented cases also apply to fragmented cases with the following change: data structures related to the SAI header, “SampleAuxiliarylnformationSizesBox” and “SampleAuxiliarylnformationOffsetsBox”, all related to the base split layer are stored in a “TrackFragmentBox” ‘traf’ instead of a “SampleTableBox” ‘stbl’.

[0381] In other words, sample auxiliary information per split layer (also denoted split layer auxiliary information) is described by defining "SampleAuxiliarylnformationSizesBox" and "SampleAuxiliarylnformationOffsetsBox" in the "SampleTableBox" or "TrackFragmentBox" for the base split layer and in a "SplitLayerBox" for an additional split layer. If needed, a "SAIHeaderBox" can be defined per couple of

[0382] "SampleAuxiliaryInformationSizesBox7"SampleAuxiliaryInformationOffsetsBox" to provide description and configuration information associated with sample auxiliary information, the association being done using the aux_info_type and a ux J nfo_type_pa ra meter pa ra meters.

[0383] Figure 10 illustrates a sample table box ("SampleTableBox", 'stbl7) 1000 of an encapsulated media file according to another embodiment of the disclosure.

[0384] More particularly, this embodiment is an example illustrating a signalling of properties associated with layers of a multi-layer bitstream or multi-codec bitstream encapsulated as a track of a media file according to the disclosure.

[0385] According to this embodiment, it is possible to associate static properties (e.g. 'coir', 'mdcv', 'clli', 'cclv', and others) in sample entry associated to each split-layer, or parameters that may change dynamically over time using sample groups associated with each split-layer. Moreover, this embodiment offers additional flexibility to support both the usual data organization, i.e. data of each split-layer is contiguous per sample, and the ability to organize the data of each layer in separate chunks (contiguous or noncontiguous) per layer.

[0386] The “SampleTableBox" 1000 is included in a track box ‘trak’ (not illustrated) describing the track, the track box being included in a movie box “moov’ (not illustrated) comprising meta data of the media file.

[0387] The sample table box 1000 comprises the description of the samples (also denoted "full" or reaggregated samples in this disclosure) of a track in the encapsulated media file. A sample in the track corresponds to all the data of the bitstream described by the track that is associated with a single time or single period of time.

[0388] According to this embodiment, a sample of a track carrying all the data from a multi-layer bitstream or multi-codec bitstream can be denoted split-sample or multi-layer sample. A split-sample can be described as multiple split-layers, a base split-layer and one or more additional split-layers. The split-layers may also be denoted sample layers. A split-layer is a part of a sample data (e.g. part of data of a media sample). The data of parts of samples described by a split layer can be data of a single video enhancement layer or several ones, or multiple tiles, or data of parts of samples encoded with different codecs or coding formats, or data of parts of samples where each part of these samples corresponds to one or more timed units of an independently encoded sub-bitstream from a plurality of multiplexed sub-bitstreams. In other words, a split-layer may contain a single video enhancement layer or several ones, or multiple tiles, or part of a media sample coded with a different codec from another part of the sample for example.

[0389] The data of layers corresponding to the split-layers of a split-sample can be stored as a contiguous piece of data of a sample of a track similarly to the data organization illustrated in the “MediaDataBox” ‘mdat’ of Figure 3 or can be stored as noncontiguous pieces of data of a sample in the track. In the latter case, the part of sample data of each split-layer is stored in different chunks in a “MediaDataBox” ‘mdat’ as illustrated in the “MediaDataBox” ‘mdat’ of Figures 4 or 5.

[0390] The “SampleTableBox” ‘stbl’ 1000 may comprise a “SplitSampleLayerConfigBox” 1005. When present, “SplitSampleLayerConfigBox” indicates that samples of the track are composed of multiple layers described by split-layers and describes general configuration information about the split-layers of the track. Preferably, this “SplitSampleLayerConfigBox” ‘sslc’ 1005 is defined in the “SampleTableBox” ‘stbl’ 1000 before a “SampleDescriptionBox” ‘stsd’ 1010. This allows a parser to be informed early in a parsing process that the track comprises layers described by split-layers.

[0391] The “SplitSampleLayerConfigBox” ‘sslc’ 1005 can be defined as follows: Box Type: 'sslc'

[0392] Container: SampleTableBox or TrackFragmentBox

[0393] Mandatory: No

[0394] Quantity: Zero or one (per container) aligned(8) class SplitSampleLayerConfigBox extends Full Box('sslc', 0, 0)

[0395] { unsigned int(l) non_contiguous_sample_data_flag; bit(7) reserved; unsigned int(32) num_split_layers;

[0396] }

[0397] Where non_contiguous_sample_data_flag indicates, if set to 0, that data of the split-layers for a split-sample are contiguous within a sample of the track, and if set to 1, that data of split-layers of a split-sample is split into different chunks. num_split_layers gives the number of split layers used in this track, not including the base split layer.

[0398] In a variant, “SplitSampleLayerConfigBox” ‘sslc’ 1005 also comprises the SAI_per_split_layer_flag as described by reference to Figure 9.

[0399] In another variant, the “SplitSampleLayerConfigBox”, when present, indicates that samples of the track are composed of multiple layers described by split-layers and describes general configuration information about the split-layers of the track.

[0400] A parameter contiguous_sample_data_idc indicates the sample data organization of split-layers:

[0401] When it equals to 0, the data of each split-layer is contiguous within a sample and any “SplitLayerBox” in “SampleTableBox” or corresponding “TrackFragmentBox” does not comprise “SampleSizeBox” (or “CompactSampleSizeBox”) and “ChunkOffsetBox” (or “ChunkLargeOffsetBox”).

[0402] When it equals to 1 , the data of split-layers of a split-sample is split into different contiguous chunks. Any “SplitLayerBox” in “SampleTableBox” or corresponding “TrackFragmentBox” comprises “SampleSizeBox” (or “CompactSampleSizeBox”) and does not comprise “ChunkOffsetBox” (or “ChunkLargeOffsetBox”).

[0403] When it equals to 2, the data of split-layers of a split-sample is split into different non-contiguous chunks. Any “SplitLayerBox” in “SampleTableBox” or corresponding “TrackFragmentBox” comprises both “SampleSizeBox” (or “CompactSampleSizeBox”) and “ChunkOffsetBox” (or “ChunkLargeOffsetBox”).

[0404] The “SplitSampleLayerConfigBox” ‘sslc’ 1005 can be then defined as follows:

[0405] Box Type: 'sslc'

[0406] Container: SampleTableBox or TrackFragmentBox

[0407] Mandatory: Yes, if split-layers are present

[0408] Quantity: Zero or one (per container) aligned(8) class SplitSampleLayerConfigBox extends FullBox('sslc', 0, 0)

[0409] { unsigned int(l) contiguous_sample_data_idc; unsigned int(l) SAI_per_split_layer_flag; bit(7) reserved; unsigned int(32) num_split_layers;

[0410] }

[0411] Where contiguous_sample_data_idc indicates, if set to 0, that data of the splitlayers for a split-sample are contiguous within a sample of the track. It indicates, if set to 1, that data of split-layers of a split-sample is split into different contiguous chunks. It indicates, if set to 2, that data of split-layers of a split-sample is split into different non-contiguous chunks. Value 3 is reserved. When not present, the default value for contiguous_sample_data_idc is 0.

[0412] SAI_per_split_layer_flag indicates, if set to 0, that sample auxiliary information directly declared in the SampleTableBox is related or apply to the reaggregated sample, and if set to 1, that sample auxiliary information directly declared in the SampleTableBox is related or apply to the part of the sample corresponding to the base split-layer only. num_split_layers gives the number of split-layers used in this track, not including the base split-layer.

[0413] The “SampleTableBox" 1000 includes a "SampleDescriptionBox" 'stsd' 1010 comprising at least one "SampleEntry" box 1015 that gives detailed information about the format of split-samples of the track, typically the coding type used, and optionally any initialization information needed for that coding and property information for each split-layer. The "SampleDescriptionBox" 'stsd' 1010 may comprise multiple "SampleEntry" boxes when the format of split-samples is different for different samples of the track.

[0414] A sample entry describing the base split-layer is a sample entry defined directly in "SampleDescriptionBox".

[0415] A sample entry describing an additional split layer is a sample entry defined in a "SplitSampleDescriptionsBox" in the sample entry describing the base split layer.

[0416] When there are multiple "SampleEntry" boxes in "SampleDescriptionBox" 'stsd' 1010, each of these multiple "SampleEntry" box contains a "SplitSampleDescriptionsBox" that defines the split-layers corresponding to the base split-layer described by the "SampleEntry" box. In an alternative, when there are multiple "SampleEntry" boxes in "SampleDescriptionBox" 'stsd' 1010, if a "SampleEntry" box describing a base split-layer does not comprise a "SplitSampleDescriptionsBox", it then inherits from the "SplitSampleDescriptionsBox" from the first preceding "SampleEntry" box having a "SplitSampleDescriptionsBox" in order of declaration.

[0417] The "SampleEntry" box 1015 representing the base split-layer contains a split sample descriptions box (“SplitSampleDescriptionsBox” ‘sshd’) 1020 and optionally a split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 as described by reference to Figure 9. The split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 is present if the data of split-layers of a split-sample is split into different chunks and therefore it is required for a parser to conduct a reconstruction process to obtain from an encapsulated media file a complete or full sample comprising the data of all the split-layers for this sample. Otherwise, the split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 may not be present. The BoxType, Container, Mandatory and Quantity properties of the “SplitSamplesConfigurationBox” are then defined as follows:

[0418] Box Type: 'ssdC

[0419] Container: SampleEntry box in SampleDescriptionBox

[0420] Mandatory: No

[0421] Quantity: Zero or one

[0422] In a variant, the split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 is present if non_contiguous_sample_data_flag is equal to 1 and may be not present if non_contiguous_sample_data_flag is equal to 0. In another variant, the split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 is present if contiguous_sample_data_idc is equal to 1 or 2 and may be not present if contiguous_sample_data_idc is equal to 0.

[0423] In a variant, default values are associated to each parameter of the split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 in case this box is not present. The semantics of the parameters of the split samples configuration box (“SplitSamplesConfigurationBox” ‘ssdC’) 1045 are then defined as follows: all_split_layers_independent indicates, if set to 1 , that all split-layers are independent and could be processed independently. If set to 0, layer dependencies is unknown. The default value is 0. single_base_compatible takes one of the following values:

[0424] - 0: the sample shall be reaggregated to be compliant to the associated sample entry type

[0425] - 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.

[0426] - 2: the track without the additional split-layers is conformant to the sample entry type only after removal of 0-size samples.

[0427] - 3: reserved

[0428] The default value is 0. no_default_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. The default value is 0. other_reaggregations indicates, if set to 1 , that other reaggregations than the default one are possible. If set to 0, there is no information on other possible reaggregations than the default one. The default value is 0.

[0429] NOTE If no_default_reaggregation is set to 1 indicating that there is no default reaggregation of the split-layers in the reconstruction process and other_reaggregations is set to 0 indicating that there is no other reaggregation rules in the reconstruction process, this indicates to the parser that the split-layers are not intended to be reaggregated in a “full” sample. num_reaggregations indicates the number of additional possible reaggregations. The default value is 0. nb_split_layers_reagg indicates the number of split-layers in a reaggregation. The default value is 0. splitjayersjndex indicates the index of the split-layer to aggregate, with the value 0 being the base sample data. The default value is 0. num_configurations gives the number of split sample entries used by this reconstruction. The default value is 0. split_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 SplitSampleDescriptionsBox. This value shall not be greater than the number of entries in SplitSampleDescriptionsBox. Any codec specific data (parameter sets or equivalent for non video media types) present in this entry shall be forwarded to the decoder in the order of appearance in this list. The last entry shall indicate the highest codec requirements for the reaggregation, e.g. highest profile-tier-level in video coding. The default value is 0.

[0430] The split sample descriptions box (“SplitSampleDescriptionsBox” ‘sshd’) 1020 comprises a sample entry box for each split-layer except the base split-layer, e.g. the “SampleEntry” box 1025 representing a first additional split-layer and the “SampleEntry” 1040 representing a second additional split-layer.

[0431] The "SampleEntry" box 1015, 1025 or 1040 may comprise a layer identifier parameter (layerjd) to identify the corresponding split-layer, the value 0 representing the base layer.

[0432] In a variant, the 1-based index of the "SampleEntry" box 1025 or 1040 in declaration order in "SplitSampleDescriptionsBox" 'sshd' 1020 indicates the layer identifier (layerjd) of the layer represented by the split layer described by the "SampleEntry" box 1025 or 1040 respectively. The value 0 is reserved and represents the base layer. The layer identifier (layerjd) may correspond to an identifier in the bitstream, e.g. the nuhjayerjd of a Network Abstraction Layer (NAL) unit-based bitstream, or a tilejd or any other identifier in the bitstream that characterizes the data encapsulated in a split-layer. In an alternative, the layer identifier (layerjd) may be any arbitrary identifier.

[0433] Each "SampleEntry" box 1015, 1025 and 1040 defines the codec and configuration information, if needed, for decoding the corresponding split layer, and the properties associated with the split-layer. For instance, the four-character code corresponding to the box type of the "SampleEntry" box 1015, e.g. 'hvcl' for HEVC data, 'wcl' for WC data, indicates the codec or format of the base split layer and the four- character code corresponding to the box type of the "SampleEntry" box 1025, e.g. 'Ihvl' for L-HEVC data indicates the codec or format of the first additional split layer. Each "SampleEntry" box 1015, 1025 and 1040 may comprise a decoder configuration box, as illustrated by the decoder config box 1030 in "SampleEntry" 1025, that provides decoder configuration information for initializing the decoder for decoding the corresponding layer.

[0434] Each "SampleEntry" box 1015, 1025 and 1040 may also comprise one or more property-related boxes, as illustrated by the property box 1035 in "SampleEntry" 1025, that provides properties associated with the corresponding layer.

[0435] A property box can be any box defined in a "SampleEntry" box whose content is related or applies within the scope of the split-layer represented by the "SampleEntry" box. Examples of property box may include "Colourinformation Box" 'coir' providing colour information, "ContentLightLevelBox" 'clli' providing light level in the content, "MasteringDisplayColourVolumeBox" 'mdcv' providing information about the colour primaries, white point, and mastering luminance in the content, "ContentColourVolumeBox" 'cclv' describing the colour volume characteristics of associated pictures, "AmbientViewingEnvironmentBox" 'amve' providing information about the characteristics of the nominal ambient viewing environment for the display of the associated video content.

[0436] The SampleTableBox 'stbl' 1000 further comprises boxes describing the offsets / sizes and timing of the sample data corresponding to the split-layers.

[0437] When the split-layers of a split-sample are stored as non-contiguous pieces of data of a sample of the track, typically when non_contiguous_sample_data_flag is equal to 1 (or contiguous_sample_data_idc is equal to 1 or 2), then:

[0438] - offsets / sizes and timing of the part of sample data corresponding to the base split-layer are described by boxes directly declared in "SampleTableBox" or "TrackFragmentBox" (e.g. boxes providing sample size, chunk offset, sample to chunk, time to sample).

[0439] - offsets / sizes of the part of sample corresponding to an additional splitlayer are described within a "SplitLayerBox" in the "SampleTableBox" or "T rackFrag mentBox".

[0440] - original sample representing all the split-layers of a split-sample is obtained by reaggregating the data of the split-layers following the reconstruction process described by the "SplitSamplesConfigurationBox". When the split-layers of a split-sample are stored as a contiguous piece of data of a sample of the track, typically when non_contiguous_sample_data_flag is equal to 0 (or contiguous_sample_data_idc is equal to 0), then:

[0441] - offsets / sizes and timing of the sample data corresponding to all the splitlayers of the split-sample are described by boxes directly declared in "SampleTableBox" or "TrackFragmentBox" (e.g. boxes providing sample size, chunk offset, sample to chunk, time to sample).

[0442] The "SampleTableBox" 'stbl' 1000 illustrates an example where the splitlayers of a split-sample are stored as a contiguous piece of data of a sample of the track. In such example, the "ChunkOffsetBox" 'stco' 1055 or ("ChunkLargeOffsetBox") and the "SampleSizeBox" 'stsz' 1050 (or "CompactSampleSizeBox") in the "SampleTableBox" 1000 provides the locations of the chunks and sizes of the data of the full samples, i.e. comprising the data of all the split-layers of those samples. These boxes are not present in the "SplitLayerBox" 'sply' 1070 and 1090 associated to each additional split-layer.

[0443] Sample groups defined by "SampleGroupDescriptionBox" 'sgpd' and the optional "SampleToGroupBox" 'sbgp' 1060 directly declared in the "SampleTableBox" 1000 allows associating properties with the part of sample data representing the base split-layer.

[0444] Additional boxes 1065 directly declared in the "SampleTableBox" 1000 may also provide additional information within the scope of the base split layer: E.g.,

[0445] “SubSamplelnformationBox” ‘subs’ for describing properties associated with a byte-range within the sample data of the base split-layer.

[0446] “MetaBox” ‘meta’ and its sub-boxes for describing general untimed metadata associated with the base split layer.

[0447] “UserDataBox” ‘udta’ for describing informative user-data associated with the base split-layer.

[0448] The "SampleTableBox" 'stbl' 1000 also comprises a container box, named split layer box ("SplitLayerBox" 'sply'), e.g. 1070 and 1090. The "SplitLayerBox" comprises boxes providing descriptive information related to a given split-layer other than the base split-layer. It may describes the offsets / sizes and additional descriptive information, e.g. sample auxiliary information or sample groups, of a part of the "full" samples for a split-layer other than the base split-layer.

[0449] If the split-layers of a split-sample are stored as non-contiguous pieces of data of a sample of the track, typically when non_contiguous_sample_data_flag is equal to 1 (or contiguous_sample_datajdc is equal to 1 or 2), then the "SplitLayerBox" may also describe the offsets / sizes of the data corresponding to the given split-layer using "ChunkOffsetBox" 'stco' or ("ChunkLargeOffsetBox") and the "SampleSizeBox" 'stsz' (or "CompactSampleSizeBox") as described by reference to Figure 9. Otherwise, the splitlayers of a split-sample are stored as a contiguous piece of data of a sample of the track, typically when non_contiguous_sample_data_flag is equal to 0 (or contiguous_sample_data_idc is equal to 0), the "SplitLayerBox" does not contain "ChunkOffsetBox" 'stco' or ("ChunkLargeOffsetBox") and "SampleSizeBox" 'stsz' (or "CompactSampleSizeBox").

[0450] In other words, the "SplitLayerBox" may comprises a "SampleSizeBox" (or "CompactSampleSizeBox") and a "ChunkOffsetBox" (or "ChunkLargeOffsetBox") describing the locations of the chunks and sizes of the data of the split-layer according to contiguous_sample_data_idc in "SplitSampleLayerConfigBox".

[0451] When present, it is allowed to have a sample size of 0 in the "SampleSizeBox" (or "CompactSampleSizeBox") if there is no data for the given split-layer.

[0452] When present, the "SampleSizeBox" (or "CompactSampleSizeBox") included in each "SplitLayerBox" has the same sample count as the "SampleSizeBox" (or "CompactSampleSizeBox") in the "SampleTableBox" of the track.

[0453] If "SampleSizeBox" (or "CompactSampleSizeBox") is present and "ChunkOffsetBox" (or "ChunkLargeOffsetBox") is absent in a "SplitLayerBox", the chunk offset for this split-layer is equal to the chunk offset of the preceding split-layer described by the preceding "SplitLayerBox", if any in the "SampleTableBox", or, by default, is equal to the chunk offset of the base split-layer plus the total size of the samples for this preceding split-layer in the chunk. Otherwise, if "SampleSizeBox" (or "CompactSampleSizeBox") is present and "ChunkOffsetBox" (or "ChunkLargeOffsetBox") is present in a "SplitLayerBox", there is as many entries as there are entries in the "ChunkOffsetBox" (or "ChunkLargeOffsetBox") for the base split-layer (present in the "SampleTableBox").

[0454] The "SplitLayerBox" can include any one of the following boxes providing descriptive information (without being limitative):

[0455] - "SampleGroupDescriptionBox" 'sgpd' and possibly "SampleToGroupBox" 'sbgp' 1080 for describing properties associated with the split-layer for a group of samples. - "SubSamplelnformationBox" 'subs' for describing properties associated with a byte-range within the sample data of the split-layer.

[0456] - "MetaBox" 'meta' and its sub-boxes for describing general untimed metadata associated with the split layer.

[0457] - "UserDataBox" 'udta' for describing informative user-data associated with the split-layer.

[0458] The "SplitLayerBox" can also comprise Sample Auxiliary Information related to the split-layer as described by reference to Figure 9.

[0459] The "SplitLayerBox" 1070, 1090 may comprise a "SplitLayerHeaderBox" 1075, 1095 for providing header information such as a split-layer identifier. If the "SplitLayerHeaderBox" is present, the split-layer identifier in "SplitLayerHeaderBox" is used to associate the parent "SplitLayerBox" 1070, 1090 with the corresponding "SampleEntry" 1025, 1040 having same layer identifier values.

[0460] If the "SplitLayerHeaderBox" is not present, the "SampleTableBox" 'stbl' 1000 comprises a "SplitLayerBox" 'sply' for each split layer (notably each additional split layer) declared in the "SplitSampleDescriptionsBox" 'sshd' 1010. The number of "SplitLayerBox(es)" 'sply' 1070, 1090 in the "SampleTableBox" 1000 corresponds to the parameter num_split_layers in the "SplitSampleLayerConfigBox" 'sslc' 1005, when present, or to the number of "SampleEntry" boxes 1025, 1040 in the "SplitSampleDescriptionsBox" 1020. The "SplitLayerBox(es)" 1070, 1090 are therefore declared in the "SampleTableBox" 'stbl' 1000 (or TrackFragmentBox) in the same order as their corresponding "SampleEntry" box(es) 1025, 1040 in

[0461] "SplitSampleDescriptionsBox" 'sshd' 1020. Thus, the ith "SampleEntry" box in the "SplitSampleDescriptionsBox" 'sshd' is associated with the ith "SplitLayerBox" 'sply' in declaration order.

[0462] In an alternative embodiment, properties are associated with a layer in a sample comprising multi-layer data using a layer mapping sample grouping with grouping_type 'laym' declared in the "SampleTableBox".

[0463] The "LayerMapEntry" may be used to assign an identifier, called "groupID", to each layer in a multi-layer sample. The "LayerMapEntry", when present, is linked to a sample group description providing the semantics of that "groupID". This link is provided by setting the grouping_type_parameter of the "SampleToGroupBox" of type 'laym' to the four-character code of the associated sample grouping type. Consequently, a "SampleToGroupBox" of type 'laym' never uses version 0 of the box. It is not permitted to indicate an associated grouping_type for which the sample group description definition does not provide semantics for groupID.

[0464] An advantage of this embodiment is that there is no need to determine a number of NAL units per layer to associate a property with a layer that can vary along samples. class LayerMapEntry() extends VisualSampleGroupEntry ('laym') { bit(7) reserved = 0; unsigned int(l) large_size; unsigned int(l) rle; if (large_size) { unsigned int(16) entry_count;

[0465] } else { unsigned int(8) entry_count;

[0466] } for (i= 1; i<= entry_count; i++) { if (rle) { if (large_size) { unsigned int(16) layer_id_start_number;

[0467] } else { unsigned int(8) layer_id_start_number;

[0468] }

[0469] } unsigned int(16) groupID;

[0470] }

[0471] } where large_size indicates whether the number of layers entries in the track samples is represented on 8 or 16 bits. rle indicates whether run-length encoding is used (1) to assign groupID to layers or not (0) entry_count specifies the number of entries in the map. Note that when rle is equal to 1, the entry_count corresponds to the number of runs where consecutive layers are associated with the same group. When rle is equal to 0, entry_count represents the total number of layers. groupID specifies the unique identifier of the group. All layers mapped to the same group with a particular groupID value have the same properties in all the sample groups that indicate a mapping to that particular groupID value and are contained in this track. More information about the group is provided by the sample group description entry with this groupID and grouping_type equal to the grouping_type_parameter of the "SampleToGroupBox" of type 'laym'.

[0472] When used with movie fragments, new layer maps can be defined for the duration of the movie fragments, by defining a new "SampleGroupDescriptionBox", typically with grouping_type equal to 'laym', in the "TrackFragmentBox" as defined in ISO / IEC 14496-12.

[0473] Figure 11 illustrates a media information box ("MedialnformationBox", 'minf') 1100 of a track of an encapsulated media file according to another embodiment of the disclosure.

[0474] The media information box is contained in the media box ‘mdia’ of a track box ‘trak’ in a movie box “moov’ comprising meta data describing the media data in the media file.

[0475] According to this embodiment, the content of the sample table box 'stbl' 1110 is not modified and provides samples-related description of a track as defined in ISO / IEC 14496-12 8thedition or previous editions. The data contained in the samples described by the hierarchy of boxes in sample table box 'stbl' 1110 corresponds to the data of the base split-layer of a split-sample. In other words, the data contained in the samples described by this sample table box 'stbl' 1110 corresponds to the base layer of a multilayer video bitstream, or the base layer or a tile of a tiled video bitstream, or a first part of a sample coded with different codecs in a multi-layer bitstream or multi-codec bitstream.

[0476] All the additional signalling related to the split-sample and split-layers is carried in a companion or extension box “SplitSampleTableBox” ‘ssbl’ 1150, also denoted “SampleTableExtensionBox” or alike, next to the sample table box 1110.

[0477] The “SampleTableBox" 1110 includes a "SampleDescriptionBox" 'stsd' 1120 comprising at least one "SampleEntry" box 1125 that gives detailed information about the format of samples of the track carrying the base split-layer, typically the coding type used, and optionally any initialization information needed for that coding and property information for this base split-layer. The “ChunkOffsetBox” ‘stco’ 1135 or (“ChunkLargeOffsetBox”) and the “SampleSizeBox” ‘stsz’ 1130 (or “CompactSampleSizeBox”) in the “SampleTableBox” 1110 provides the locations of the chunks and sizes of the data of 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 other than the base split layer.

[0478] A time to sample box, “TimeToSampleBox” 'stts', and a composition to decode box, “CompositionToDecodeBox” 'cslg', and “SyncSampleBox” ‘stss’ (not represented) in “SampleTableBox” ‘stbl’ 1110 are defined for the ’’full” samples (i.e. for all the reaggregated samples after applying a reconstruction process to the base split-layer and some of the additional split-layers).

[0479] Additional boxes 1140 applying within the scope of the base split-layer may also be present, e.g.:

[0480] — “SampleGroupDescriptionBox" 'sgpd' and possibly "SampleToGroupBox" 'sbgp' for describing static or dynamic properties associated with the base split-layer for a group of samples.

[0481] — "SubSamplelnformationBox" 'subs' for describing properties associated with a byte-range within the sample data of the base split-layer.

[0482] — "MetaBox" 'meta' and its sub-boxes for describing general untimed metadata associated with the base split layer.

[0483] — "UserDataBox" 'udta' for describing informative user-data associated with the base split-layer.

[0484] — Sample Auxiliary Information (SAI) associated with the base split-layer and described by a "SampleAuxiliarylnformationOffsetsBox" 'saio' and associated "SampleAuxiliaryInformationSizesBox" 'saiz'.

[0485] It can be noted that some of the additional boxes 1140 may also apply to the "full" samples depending on the semantics associated with the box and / or if a corresponding box is defined or not per split-layer in the "SplitSampleTableBox" 'ssbl' 1150.

[0486] The "SplitSampleTableBox" 'ssbl' 1150 is a container box that contains all the information related to one or more split-layers in a track. The "SplitSampleTableBox" 'ssbl' 1150 contains at least one "SplitLayerBox" 'sply' 1160, 1190, and the "SplitSamplesConfigurationBox" 'ssdC' 1155 describing the "full" sample reconstruction process parameters. The "SplitSampleTableBox" 'ssbl' 1150 may also contain a "SplitSampleLayerConfigBox" 'sslc' (not represented) providing general configuration or descriptive information about the split-samples and associated split-layers of the track as described in embodiments of this disclosure.

[0487] Each "SplitLayerBox" 1160, 1190, includes the data needed to process an additional split-layer other than the base split-layer. The number of additional split-layers to be processed may be determined by the number of "SplitLayerBox"(es) or by information in the "SplitSampleLayerConfigBox" 'sslc' (not represented) in the "SplitSampleTableBox" 1150, or by reconstruction process parameters in "SplitSamplesConfigurationBox" 1155.

[0488] In particular, each "SplitLayerBox" 1160, 1190 includes descriptive metadata including information relative to the organization of the split-samples of an additional split-layer in the track.

[0489] Each "SplitLayerBox" 1160, 1190, may include a "SplitSampleLayerConfigBox" 1165 (also denoted "SplitLayerHeaderBox" or alike) for providing general configuration or descriptive information about the split-layer and / or header information such as a splitlayer identifier.

[0490] Each "SplitLayerBox" 1160, 1190, includes at least one sample entry 1170, 1195 providing the codec and configuration information needed for decoding the split layer and properties associated with the split-layer.

[0491] Each "SplitLayerBox" 1160, 1190, may comprise other boxes 1185 related to the split-layer as described in any other embodiments of this disclosure.

[0492] It can be noted that if this embodiment works well when there is one sample entry per layer, it does not allow to easily associate sample entries of the base split layer and sample entries of the additional split-layers when there are multiple sample entries that change over time per layer since many boxes of different types are contained in a same container. Some of the embodiments that follow have been devised to address this concern.

[0493] Figure 12 illustrates a media information box ("MedialnformationBox", 'minf) 1200 of a track of an encapsulated media file according to another embodiment of the disclosure.

[0494] In this embodiment, the "MedialnformationBox" 'minf' 1200 comprises a single "SampleTableBox" 1210 and at least one companion or extension box, e.g. "SplitSampleTableBox" 1250 similarly to embodiment described by reference to figure 11, that contains all the information related to one or more split-layers in a track except that all the sample entry box(es) 1280, 1290 declared inside a "SplitLayerBox" 'sply' 1260 are contained in a "SplitSampleDescriptionsBox" 'sshd' 1270 as described by reference to figures 9 or 10.

[0495] In a variant, the "SplitSampleDescriptionsBox" 'sshd' 1270 can be replaced with a "SampleDescriptionBox" 'stsd' similar to the "SampleDescriptionBox" 'stsd' 1220 but dedicated to the sample entries of the split-layer corresponding to the "SplitLayerBox" 1260.

[0496] The number of sample entry box(es) declared in the "SplitSampleDescriptionsBox" or SampleDescriptionBox 'stsd' 1270 of a "SplitLayerBox" 1260 is equal to the number of sample entry box(es) 1230, 1240 in the "SampleDescriptionBox" 1220 declared in the "SampleTableBox" 1210 representing the base split-layer.

[0497] Each sample entry box in a container box "SampleDescriptionBox" 1220 or "SplitSampleDescriptionsBox" 1270 has an associated implicit 1-based index corresponding to its declaration order in its respective container box.

[0498] The sample entry box for the base split-layer in "SampleDescriptionBox" 1220 or the sample entry box for an additional split-layer in corresponding "SplitSampleDescriptionsBox" 1270 that corresponds to data associated with a given single time, is the sample entry with the index equal to the sample_description_index as defined in ISO / IEC 14496-12, e.g. in "SampleToChunkBox" or "T rackFragmentHeaderBox".

[0499] Thus, the ithsample entry box in declaration order in the "SplitSampleDescriptionsBox" 1270 is in relation with the ithsample entry box in declaration order in the "SampleDescriptionBox" 1220.

[0500] In a variant, a dedicated box or the "SplitSampleLayerConfigBox" in the "SplitSampleTableBox" may declare explicitly the association between a sample entry box of the "SampleDescriptionBox" 1220 and the sample entry boxes declared in "SplitSampleDescriptionsBox" of each "SplitLayerBox" as follows: SplitSampleLayerConfigBox extends FullBoxCssIc', 0, 0){ unsigned int(32) num_split_layers; unsigned int(32) nb_base_sample_entries; for (i=0; i<nb_base_sample_entries; i++) { for 0=0; i< num_split_layers; j++) { unsigned int(32) split_layer_sample_entry_index [i][j];

[0501] } }

[0502] } where num_split_layers gives the number of split layers, not including the base split layer, used in this track. nb_base_sample_entries is the number of sample entry box(es) declared in "SampleDescriptionBox" 1220 for the base split-layer. split_layer_sample_entry_index is an array that gives the index of the sample entry box corresponding to the jthadditional split-layer associated with the ithsample entry box of the base split-layer.

[0503] In this variant, the number of sample entry box(es) declared in "SampleDescriptionBox" 1220 and in any "SplitSampleDescriptionsBox" 1270 may be different.

[0504] In a variant, rather than declaring the property or configuration box(es), or any boxes usually declared in a sample entry, directly in each sample entry to which they apply or are associated with, these boxes can be declared once in a single container box. Then one or more association box(es) can be used to associate each box from the single container box with each of the sample entries, or inversely, to associate a sample entry with the corresponding property or configuration box(es) in the single container box.

[0505] An advantage of this variant is that this avoids duplicating boxes that apply to multiple sample entries.

[0506] The single container box containing property or configuration box(es) can be defined as follows:

[0507] Box Type: 'spco'

[0508] Container: MedialnformationBox or SampleTableBox or SplitSampleTableBox

[0509] Mandatory: No

[0510] Quantity: Zero or one aligned(8) class SamplePropertyContainerBox extends Box('spco')

[0511] {

[0512] Box properties[]; / / boxes derived from

[0513] / / Box or FullBox or SampleProperty or

[0514] 11 SampleFullProperty, or FreeSpaceBox(es)

[0515] / / to fill the box }

[0516] If the "SamplePropertyContainerBox" is declared in the "MedialnformationBox", its property or configuration boxes may be associated with a sample entry of a base split-layer or of an additional split-layer or both.

[0517] If the "SamplePropertyContainerBox" is declared in a "SampleTableBox", respectively "SplitSampleTableBox", its property or configuration boxes may be associated only with a sample entry of the base split-layer, respectively of an additional split-layer. In such case, a "SamplePropertyContainerBox" may be declared in both a "SampleTableBox" and a "SplitSampleTableBox".

[0518] The property box(es) declared in the "SamplePropertyContainerBox" are associated with the sample entries to which they apply via a "SamplePropertyAssociationBox". In other words, the property box(es) are associated with the samples or sample parts that refer to the sample entry with which the property box(es) are associated via a "SamplePropertyAssociationBox". The "SamplePropertyAssociationBox" may be declared at different box level as illustrated by the following variants. In a first variant, the "SamplePropertyAssociationBox" is declared in the SampleEntry with which the property box(es) are associated and may have the syntax as follows:

[0519] Box Type: 'spma'

[0520] Container: SampleEntry

[0521] Mandatory: No

[0522] Quantity: Zero or more aligned(8) class SamplePropertyAssociationBox extends FullBox('spma', version, flags)

[0523] { unsigned int(8) association_count; for 0=0; j<association_count; j++) { bit(l) essential; if (flags & 1) unsigned int(15) propertyjndex; else unsigned int(7) propertyjndex;

[0524] } } where propertyjndex is either 0 indicating that no property is associated (the essential indicator shall also be 0), or is the 1-based index (counting all boxes, including FreeSpace boxes) in the "SamplePropertyContainerBox" contained in an upper-level or enclosing container of the "SamplePropertyAssociationBox". In variants, the upper-level or enclosing container can be either "MedialnformationBox" or "SampleTableBox" or "SplitSampleTableBox". propertyjndex shall not be greater than the number of boxes contained in the "SamplePropertyContainerBox" of the enclosing container. essential when set to 1 indicates that the associated property is essential to the sample referring to the sample entry enclosing the "SamplePropertyAssociationBox", otherwise it is non-essential.

[0525] In a second variant, the "SamplePropertyAssociationBox" is declared per splitlayer. This allows reducing the number of "SamplePropertyAssociationBox" defined in the file compared to the first variant when they are multiple sample entries per splitlayer. In such case, it can be declared in a "SampleTableBox" for the base split-layer or in a "SplitLayerBox" for an additional split-layer, as follows:

[0526] Box Type: 'spma'

[0527] Container: SampleTableBox or SplitLayerBox

[0528] Mandatory: No

[0529] Quantity: Zero or more aligned(8) class SamplePropertyAssociationBox extends FullBox('spma', version, flags)

[0530] { unsigned int(32) entry_count; for (i = 0; i < entry_count; i++) { if (version < 1) unsigned int(16) sample_descriptionjndex; else unsigned int(32) sample_descriptionjndex; unsigned int(8) association_count; for 0=0; j<association_count; j++) { bit(l) essential; if (flags & 1) unsigned int(15) propertyjndex; else unsigned int(7) propertyjndex;

[0531] }

[0532] } where sample_descriptionjndex is an integer that gives the index of the sample entry with which properties are associated. If the "SamplePropertyAssociationBox" is declared in a "SampleTableBox", the index ranges from 1 to the number of sample entries in the "SampleDescriptionBox" of this "SampleTableBox". If the

[0533] "SamplePropertyAssociationBox" is declared in a "SplitLayerBox", the index ranges from 1 to the number of sample entries in the "SampleDescriptionBox" or "SplitSampleDescriptionBox" of this "SplitLayerBox". propertyjndex is either 0 indicating that no property is associated (the essential indicator shall also be 0), or is the 1-based index (counting all boxes, including FreeSpace boxes) in the "SamplePropertyContainerBox" contained in an upper-level or enclosing container of the "SamplePropertyAssociationBox". In variants, the upper-level or enclosing container can be either "MedialnformationBox" or "SampleTableBox" or "SplitSampleTableBox". propertyjndex shall not be greater than the number of boxes contained in the "SamplePropertyContainerBox" of the enclosing container. essential when set to 1 indicates that the associated property is essential to the sample referring to the sample entry identified by sample_descriptionjndex, otherwise it is non-essential.

[0534] The "SamplePropertyAssociationBox" is ordered by increasing sample_descriptionjndex, and there is at most one occurrence of a given sample_descriptionjndex.

[0535] In a third variant, the "SamplePropertyAssociationBox" is declared at same level as the "SamplePropertyContainerBox". In other words, both "SamplePropertyAssociationBox" and "SamplePropertyContainerBox" may be declared in e.g. a "MedialnformationBox" or a "SampleTableBox" or a "SplitSampleTableBox". In such case, they may be also enclosed in a same container box, e.g. a "SamplePropertiesBox", in a "MedialnformationBox" or a "SampleTableBox" or a "SplitSampleTableBox". With this variant, a player can more easily find at the same place the property or configuration boxes and their associations with sample entries for each split-layer.

[0536] In this third variant, the "SamplePropertyAssociationBox", when defined within a a "MedialnformationBox" or a "SplitSampleTableBox", may be defined as follows:

[0537] Box Type: 'spma'

[0538] Container: MedialnformationBox or a SplitSampleTableBox or a

[0539] SamplePropertiesBox (itself defined in a MedialnformationBox or a SplitSampleTableBox) Mandatory: No

[0540] Quantity: Zero or more aligned(8) class SamplePropertyAssociationBox extends FullBox('spma', version, flags)

[0541] { unsigned int(32) entry_count; for (i = 0; i < entry_count; i++) { if (version < 1) { unsigned int(16) sample_description_index; unsigned int(16) splitjayerjdentifier;

[0542] } else { unsigned int(32) sample_description_index; unsigned int(32) splitjayerjdentifier;

[0543] } unsigned int(8) association_count; for 0=0; j<association_count; j++) { bit(l) essential; if (flags & 1) unsigned int(15) propertyjndex; else unsigned int(7) propertyjndex;

[0544] }

[0545] } where sample_descriptionjndex, propertyjndex have similar semantics as previously described. split_layer_identifier is an integer that gives the identifier of a split-layer, where 0 indicates the base split-layer.

[0546] The "SamplePropertyAssociationBox" is ordered by increasing splitjayerjdentifier first and then by increasing sample_description_index, and there is at most one occurrence of a given couple sample_description_index and splitjayerjdentifier.ln any variants, multiple "SamplePropertyAssociationBox" may be declared at a same level, i.e. in a same enclosing box. In such case, there is at most one "SamplePropertyAssociationBox" with a given pair of values of version and flags. E.g. this allows supporting future extensions (versions) of the "SamplePropertyAssociationBox".

[0547] In a variant, sample groups may also refer to property or configuration box(es) declared in a "SamplePropertyContainerBox".

[0548] Figure 13 illustrates a media information box ("MedialnformationBox", 'minf') 1300 of a track of an encapsulated media file according to another embodiment of the disclosure.

[0549] This embodiment illustrates a variant of the embodiment described by reference to figure 10, where the "SampleTableBox" 'stbl' 1310 may comprise a "SplitSampleLayerConfigBox" 'sslc' as previously described and comprises a "SampleDescriptionBox" 'stsd' 1010 as described by reference to figure 10, i.e. comprising at least one "SampleEntry" box that gives detailed information about the format of the base split-layer, typically the coding type used, and optionally any initialization information needed for that coding and associated property information. Each "SampleEntry" box related to the base split-layer in "SampleDescriptionBox" 'stsd' 1010 comprises a "SplitSampleDescriptionsBox" providing similar information for each split-layer other than the base split-layer.

[0550] In this embodiment, the "SampleDescriptionBox" does not comprise the "SplitLayerBox"(es). All the "SplitLayerBox" 1070, 1090 are declared in a companion or extension box"SplitSampleTableBox" 1350 next to the "SampleDescriptionBox" 1010.

[0551] The ith"SplitLayerBox" in declaration order in the "SplitSampleTableBox" 1350 corresponds to the split-layer described by the ithsample entry box in a "Spl itSa m pleDescri ptionsBox".

[0552] In a variant, a "SamplePropertyContainerBox" is defined in the "SampleTableBox" 1310 for containing possibly the configuration or property boxes, and a "SamplePropertyAssociationBox" may be defined in "SampleDescriptionBox" and / or in "SplitSampleDescriptionsBox" for associating the sample entries with their configuration or property box(es).

[0553] In a variant, both "SamplePropertyContainerBox" and "SamplePropertyAssociationBox" are defined in "SampleTableBox" 1310 or "SampleDescriptionBox" 1010, possibly also enclosed in a same container box, e.g. a "SamplePropertiesBox".

[0554] In a variant of any embodiment of this disclosure, when a track can be encrypted, e.g. using common encryption (CENC) as defined in ISO / IEC 23001-7, the "SplitSampleLayerConfigBox" 'sslc' or the "SplitLayerHeaderBox" 'slyh' may comprise an indication indicating whether encryption is applied to the split-sample after reconstruction, or to each split-layer individually.

[0555] If the encryption applies to each split-layer individually, then the following applies:

[0556] — some of the split-layers (including the base split-layer) may or may not be encrypted,

[0557] — the sample entry of an encrypted split-layer is transformed in a protected sample entry comprising a "ProtectionSchemelnfoBox" as described in ISO / IEC 14496-12 and ISO / IEC 23001-7,

[0558] — protection system specific data that are usually stored in a "ProtectionSystemSpecificHeaderBox" as defined in ISO / IEC 23001-7 is stored in the "MovieBox" or "MovieFragmentBox",

[0559] — common encryption information for a split-layer for the whole media track - this includes default values for the key identifier (KID), initialization vector and vector size, protection pattern, and protection flag - is contained in a "TrackEncryptionBox", as defined in ISO / IEC 23001-7, declared within the sample entry of the split-layer,

[0560] — common encryption information for data of a split-layer corresponding to groups of media samples can be carried in a "SampleGroupDescriptionBox" that is referenced by a "SampleToGroupBox", both associated with the split-layer, e.g. by declaring them in the corresponding "SplitLayerBox", as described in some embodiments of this disclosure.

[0561] — cryptographic information for individual data of a split-layer corresponding to a sample such as initialization vectors and subsample encryption data may be given in a CENC Sample Auxiliary Information (SAI), as described in ISO / IEC 23001-7, referenced by a "SampleAuxiliarylnformationSizesBox" 'saiz' and "SampleAuxiliarylnformationOffsetBox" 'saio' with aux_info_type equal to the scheme and aux_info_type_parameter equal to 0 or 1, and both associated with the split-layer, e.g. by declaring them in the corresponding "SplitLayerBox", as described in some embodiments of this disclosure. Alternatively, a "SampleEncryptionBox" declared in a "SplitLayerBox", respectively within the "TrackBox" box hierarchy or within "TrackFragmentBox", may provide an optional storage location for CENC SAI of data of the split-layer corresponding to samples in a track or track fragment respectively.

[0562] Hereinabove, some embodiments of the disclosure are introduced wherein a single property container box is dedicated to containing property box(es), or any boxes usually declared within the sample entry to which they apply or are associated with. A property box describes an information of property or configuration (also denoted decoder configuration) of a sample entry. One or more association box(es) can be used to associate each box from the single property container box with each of the sample entries, or inversely, to associate a sample entry with the corresponding property or configuration box(es) in the single property container box, so that duplicating boxes that apply to multiple sample entries is avoided.

[0563] The application of the principle has been described in various embodiments wherein the information of property or configuration is associated with a split-layer rather than with the sample entry as a whole. Namely, a property box may be associated to a first split-layer and also to a second split layer in order to avoid the duplication of the property box.

[0564] In general, a track comprises a sequence of samples. Each sample is associated with a single time. Hence, the track comprises a plurality of samples carried by a bitstream.

[0565] One can define a sub-bitstream within the bitstream. The sub-bitstream is defined as a sequence of bytes, possibly non-contiguous, in a bitstream. Sub-bitstream properties are properties or configuration information associated with a sub-bitstream carried in a track.

[0566] The principle of the mutualization of the description of the properties or configurations associated with the split-layers) through the use of a single property container box may be extended to describe any property or decoder configuration that may be associated with any type of sub-bitstreams carried in a track (i.e. without splitlayers) in ISOBMFF. It is noted that the single property container box can be also denoted a generic, common or mutualized property container box or sub-bitstream properties container box. Examples of property box may include "ColourlnformationBox" 'coir' providing colour information, "CleanApertureBox" 'clap' providing cropping information to be applied to the content, "ContentLightLevelBox" 'clli' providing light level in the content, "MasteringDisplayColourVolumeBox" 'mdcv' providing information about the colour primaries, white point, and mastering luminance in the content, "ContentColourVolumeBox" 'cclv' describing the colour volume characteristics of associated pictures, "AmbientViewingEnvironmentBox" 'amve' providing information about the characteristics of the nominal ambient viewing environment for the display of the associated video content, or any decoder configuration box according to the codec in use in the track, for instance "HEVCConfigurationBox" for HEVC-based content, "VvcConfigurationBox" for VVC-based content, "V3CConfigurationBox" for V3C-based content, "BaseMeshConfigurationBox" for basemesh-based content.

[0567] There is a variety of type of sub-bitstreams. Namely, the type of a subbitstream may be selected in the list comprising :

[0568] - a layer, a tile, a subpicture, a 3D region, an operating point or a reconstruction point ; as defined by a multi-layer or multi-codec coding format within the ISO BMFF ecosystem, or

[0569] - the data corresponding to a split-layer in split samples; as defined in the current disclosure.

[0570] Whatever the type of sub-bitstream, each sub-bitstream may be identified by a sub-bitstream identifier, for example referred to as 'tilejd', 'layerjd', 'subpicturejd', 'region id', 'olsjd' within the ISO BMFF ecosystem.

[0571] Figure 14 illustrates a media information box ("MedialnformationBox", 'minf) 1400 of a track of an encapsulated media file according to an embodiment of the disclosure. The media information box 1400 is included in a track box ‘trak’ in a movie box “moov’ comprising meta data of the media file. The media information box 1400 according to this embodiment comprises a sample table box (“SampleTableBox”, ‘stbl’) 1410, for example as defined in the ISO BMFF.

[0572] The sample table box 1410 comprises a sample description box (“SampleDescriptionBox”, ‘stsd’) 1420, to provide description of the samples, mainly through sample entries. A sample entry is a box structure which defines and describes the format of one of the samples in the track, for instance the coding type used, and optionally any initialization information needed for that coding and associated property information.

[0573] According to this embodiment, it is proposed:

[0574] - To define a generic notion of sub-bitstream in ISOBMFF, that may represent a layer, an operating point, a partial partition, a 3D region or a reconstruction point as defined by a multi-layer or multi-codec coding format.

[0575] - To define a single container box SubbitstreamPropertyContainerBox in the SampleTableBox that provides a common place to declare any boxes (e.g. properties or configuration information) that apply to a sub-bitstream of the media carried in a single track.

[0576] - To declare mapping information in sample entries to associate any box from the SubbitstreamPropertyContainerBox or directly declared in the sample entry with an identifier identifying the sub-bitstream with which the box is associated.

[0577] As represented with reference to Figure 14, the sample description box 1420 may comprise a plurality of sample entries, each sample entry being associated with one or more samples of the track. For the sake of illustration, two sample entries are represented : a first sample entry 1430 (‘SampleEntry #T) and a second sample entry 1450 (‘SampleEntry #2’). One would understand that the sample description box 1420 of the embodiment may comprise in general any number of sample entries.

[0578] The sample table box 1410 further comprises an additional box, which is a single sub-bitstream property container box C'SubbitstreamPropertyContainerBox", 'sbpc7) 1460 which provides a common place to declare any property boxes 1465, 1470 or 1475 describing the information of property or configuration that may apply to a subbitstream of the media carried in a single track.

[0579] In order to declare mapping information between an identified sub-bitstream and a property box which applies to the sub-bitstream, a sub-bitstream property association box C'SubbitstreamPropertyAssociationBox", 'sbpa7) may be declared within at least some of the sample entry boxes (some of the sample entry boxes may not need a sub-bitstream property association box). The sub-bitstream property association box 1440 represented on Figure 14 is declared in the first sample entry 1430. The subbitstream property association box 1455 is declared in the second sample entry. The sub-bitstream property association box 1440 or 1455 associate any property box 1465, 1470 or 1475 from the single property container box 1460 with an identifier identifying the sub-bitstream with which the property box is associated.

[0580] The sub-bitstream property association box 1440 or 1455 further associates any property box 1435, respectively 1454 located directly in the sample entry 1430, respectively 1450 with an identifier identifying the sub-bitstream with which the property box is associated.

[0581] In other words, a property box may be declared either directly within the sample entry, or within the single property container box. The sub-bitstream property association box declared in each sample entry refers to the applicable property boxes of the sample entry.

[0582] In other words, a sub-bitstream is defined as a sequence of bytes, possibly non-contiguous, in a bitstream. It may represent a layer, a tile, a subpicture, a 3D region, an operating point, a reconstruction point as defined by a multi-layer or multi-codec coding format or the data corresponding to a split-layer in split samples.

[0583] Sub-bitstream properties are properties or configuration information associated with a sub-bitstream carried in a track.The association of these sub-bitstream properties with a sub-bitstream in samples of a track is described using one or more "SubbitstreamPropertyAssociationBox" (es) in the sample entry that associate a subbitstream with a property or a configuration information. These properties or configuration information are located either directly in the enclosing sample entry or in a "SubbitstreamPropertyContainerBox" in the "SampleTableBox".

[0584] A sub-bitstream property container box C'SubbitstreamPropertyContainerBox", 'sbpc7) contains an implicitly indexed list of Box(es) or FullBox(es) describing properties or configuration information associated with a sub-bitstream carried in a track. The "boxtype" of the contained "Box"(es) or "FullBox"(es) specifies the property type. The "FreeSpaceBox" may occur in the "SubbitstreamPropertyContainerBox"; it has no meaning, and should not be associated with any sub-bitstream.

[0585] The syntax and semantics of the "SubbitstreamPropertyContainerBox" may be defined as follows:

[0586] Box Type: 'sbpc'

[0587] Container: SampleTableBox

[0588] Mandatory: No Quantity: Zero or one aligned(8) class SubbitstreamPropertyContainerBox extends Box('sbpc')

[0589] {

[0590] Box properties[]; / / boxes derived from

[0591] / / Box or FullBox or FreeSpaceBox(es)

[0592] / / to fill the box

[0593] }

[0594] Where properties is an array of boxes to be associated with a sub-bitstream within a track. Any box allowed in a sample entry may be present in this array. In a variant, the boxes in the properties array may be any type of boxes that may be or need to be associated with a sub-bitstream.

[0595] In a variant, the container of a sub-bitstream property container box C'SubbitstreamPropertyContainerBox") may be the sample entry comprising the associated sub-bitstream property association box C'SubbitstreamPropertyAssociationBox").

[0596] In another variant, the container of a sub-bitstream property container box C'SubbitstreamPropertyContainerBox") may be located in a box comprising the "TrackBox" 'trak' or the "TrackFragmentBox" 'traf' to allow mutualizing the property boxes among multiple tracks.

[0597] A sub-bitstream property association box C'SubbitstreamPropertyAssociationBox", 'sbpa7) associates a sub-bitstream identified by a targetjd, also denoted subbitstreamjdentifier or sub-bitstream identifier, with properties or boxes declared in "SubbitstreamPropertyContainerBox".

[0598] The type of sub-bitstream referenced by targetjd is determined by a syntax element target_specificjnfo, also denoted subbitstream_specificjnfo. Following values of target_specificjnfo may be defined:

[0599] - 0x00000000 is reserved.

[0600] - 0x00000001 denoted "targetjayer" or "layer_subbitstream"; It indicates that the target sub-bitstream is a layer as defined by the codec in use.

[0601] - 0x00000002, denoted "target_multi-layer_reconstruction_point" or "multi-layer_reconstruction_point_subbitstream"; It indicates that the target sub- bitstream is a layer set representing a reconstruction point as defined by the codec in use.

[0602] For instance, a multi-layer reconstruction point may be an output layer set as defined in ISO / IEC 14496-15 for HEVC and VVC coding format.

[0603] - 0x00000003, denoted "target_spatial_partition" or "tile_subbitstream"; It indicates the target sub-bitstream corresponds to a spatial partition of the content represented by the bitstream, for instance a tile or subpicture or 3D region of the content. For instance, tiles in a motion-constrained HEVC (ISO / IEC 23008-2) or sub-pictures in WC (ISO / IEC 23090-3) can be documented as target_spatial_partition.

[0604] Any values of target_specific_info such that (target_specific_info & OxOOOOOOFC) is not equal to 0 are reserved. The values of target_specific_info is such that (flags & OxFFFFFFOO) is equal to 0 unless defined otherwise by a derived specification of the ISOBMFF standard. Both (target_specific_info & OxOOOOOOFF) and (target_specific_info & OxFFFFFFOO) are not equal to 0. In other words, one of (target_specific_info & OxOOOOOOFF) or (target_specific_info & OxFFFFFFOO) is different from 0, but not both.

[0605] In a variant, the values from 0x00000004 to OxOOOOFFFF are ISO-IEC reserved, for instance for a future edition of the ISOBMFF specification. And the values 0x00010000 to OxFFFFFFFF are user-defined. For instance, a derived specification may define their values in the user-defined range.

[0606] There is at most one "SubbitstreamPropertyContainerBox" with one of these target_specific_info value in a sample entry.

[0607] The entries of each "SubbitstreamPropertyAssociationBox" may be ordered by increasing targetjd or subbitstreamjdentifier. This allows retrieving more rapidly all the properties or boxes associated with a given value of targetjd or subbitstreamjdentifier.

[0608] Each property association may be marked as either essential or non- essential. A reader is not intended to process a sub-bitstream carried in samples that is associated with a property that is not recognized or not supported by the reader and that is marked as essential to the sub-bitstream. A reader may ignore an associated item property that is marked non-essential to the sub-bitstream.

[0609] For a given targetjd, the quantity of associated properties of a given type allowed in a sample entry shall be the same as the allowed quantity of this box type in a sample entry. If the property is not allowed in a sample entry, the quantity of associated properties is as defined by the specification of the property. For example, there can only be zero or one 'pasp' associated property for a given targetjd.

[0610] The syntax and semantics of the "SubbitstreamPropertyAssociationBox" may be defined as follows:

[0611] Box Type: 'sbpa'

[0612] Container: SampleEntry

[0613] Mandatory: No

[0614] Quantity: Zero or more, with exactly one per target_specific_info value aligned(8) class SubbitstreamPropertyAssociationBox extends FullBox('sbpa', version, flags)

[0615] { unsigned int(32) target_specific_info; unsigned int(32) entry_count; for (i = 0; i < entry_count; i++) { unsigned int(32) targetjd; unsigned int(8) association_count; for 0=0; j<association_count; j++) { bit(l) essential; bit(l) source; if (source == 0) unsigned int(14) property J ndex;

[0616] / * in SubbitstreamPropertyContainerBox * / else unsigned int(6) propertyjndex;

[0617] / * in SampleEntry * /

[0618] }

[0619] }

[0620] } where target_specificjnfo indicates the type of sub-bitstream to which properties apply. entry_count is an integer that gives the number of entries (or subbitstreams) for which there is an association table. targetjd is an identifier of a target sub-bitstream of the type declared in target_specific_info with which properties are associated association_count is an integer that gives the number of associations for the ithentry in the "SubbitstreamPropertyAssociationBox". essential when set to 1 indicates that the associated property is essential to the sub-bitstream identified by targetjd in the sample referring to the enclosing sample entry, otherwise it is non-essential. source indicates, when equal to 0, the propertyjndex is an index of a box in the "SubbitstreamPropertyContainerBox" located in the enclosing "SampleTableBox", and when equal to 1, an index in the enclosing sample entry. propertyjndex if equal to 0, indicates that all the properties in the container box indicated by source are associated, otherwise it is the 1-based index (counting all boxes, including FreeSpace boxes) of the child box in the associated SubbitstreamPropertyContainerBox or sample entry, propertyjndex shall not be greater than the number of boxes contained in the associated container box indicated by source.

[0621] In a variant, the value 0 of propertyjndex may be reserved to indicate that no property is associated with the sub-bitstream identified by targetjd.

[0622] Although the embodiment has been described hereinabove with reference to static boxes defined in SampleTableBox or sample entry boxes, it is possible to support dynamic (time-changing) properties and / or associations, by declaring the "SubbitstreamPropertyContainerBox" and / or "SubbitstreamPropertyAssociationBox" as sample groups (i.e. as a specific sample group description box with a dedicated grouping_type as the 'pasp' box can also be declared as a 'pasp' sample group in ISOBMFF).

[0623] In the following, it is noted several aspects of ISO / IEC 14496-15 with regards to usage of 14496-12 sample entry child boxes and visual sample entry width / height in single-track multi-layer storage, that is summarized as follows:

[0624] - In AVC / SVC and AVC / MVC, the sample entry width and height describe the base layer.

[0625] - In L-HEVC: o The hvcl / hevl sample entry width and height describe the base layer o The hvc2 / hev2 sample entry width and height describe 'maximum' of any layer, and are undefined for coir, clli, mdcv, clap, pasp

[0626] - In WC, o If ptl_present=l, sample entry describes clearly the indicated operating point (complex), if there is one output layer in that operating layer set (OLS) o If ptl_present=O, this is unspecified.

[0627] It is noted that neither HEIF or slim-HEIF describe generic rules for width / height or other properties in case of scalable bitstreams. L-HEVC items do specify a single output image through an associated operating point, which implies that the image properties describe the reconstructed image.

[0628] It is also noted that 'maximum frame dimension', as used for width and height sample entry rules, is not clearly defined (For instance, what is the maximum of 1920x1080 and 1080x1920 ?).

[0629] In the following more detailed analysis of ISO / IEC 14496-15 (also denoted NALUFF) is described for multi-layer bitstream storage in single track regarding sample descriptions fields and child boxes to identify what should be described by generic child boxes (ISOBMFF) present in sample entries describing multi-layer bitstreams.

[0630] Per default rules for any NALUFF, the width and height fields in a VisualSampleEntry correctly document the maximum cropped frame dimensions in any sample of the video stream that is described by that entry. This does not state if this is for the base layer or for any operating points. It is also noted that the maximum frame dimension is not defined. For example, if two independent layers with resolutions 1920x1080 and 1080x1920 are present in the samples. Moreover, there are no additional notes on other possible child boxes of sample entry such as pasp, clap, mdcv, clli, btrt.

[0631] For AVC and SVC, when the decoder configuration record is used for a stream that can be interpreted as either an SVC or AVC stream, the AVC decoder configuration record reflects the properties of the AVC compatible base layer, e.g. it contains only parameter sets needed for decoding the AVC base layer. The fields AVCProfilelndication, AVCLevellndication carry the profile and level indications, respectively, indicating the profile and level of the entire scalable stream in this track, but does not specify whether this is the maximum profile and level of the Highest operating point.

[0632] It is also noted that if an SVC elementary stream contains an AVC compatible base layer, then an AVC visual sample entry ('avcr,'avc2', 'avc3', or 'avc4') is used. The AVCConfigu ration Box documents the Profile, Level and Parameter Set information pertaining to the AVC compatible base layer. The SVC ConfigurationBox documents the Profile, Level, and possibly also parameter sets pertaining to the entire stream containing the SVC compatible enhancement layers. If AVC base is in the track, usage of 'avcl', 'avc2', 'avc3', or 'avc4' sample entry is required and avcC must be present, describing the base. The visual width and height documented in a VisualSampleEntry of a stream containing SVC VCL NAL unit are the cropped frame dimensions of the AVC base layer, if the stream is described by a sample entry of type 'avcl', 'avc2', 'avc3' or 'avc4'; otherwise, they are the cropped frame dimensions of decoded pictures by decoding the entire stream. In such a case, all sample entry child boxes except decoder configuration describe the base layer, not the SVC reconstruction(s).

[0633] When the AVC decoder configuration record is used for a stream that can be interpreted as either an MVC or AVC stream, the AVC decoder configuration record reflects the properties of the AVC compatible base view, e.g. it contains only parameter sets needed for decoding the AVC base view. If AVC base is in the track, usage of 'avcl', 'avc2', 'avc3', or 'avc4' sample entry is required and avcC must be present, describing the base. Multiview and depth-specific boxes in MVC sample entry either describe the entire bitstream or all views in the bitstream.

[0634] - Intrinsic and extrinsic camera parameters are not associated to a given layer / operating point

[0635] - View identifier identifies all views and their temporal and multiview bitstream IDs

[0636] For the AVC sample entries 'avcl','avc2', 'avc3' and 'avc4', the width and height fields in the sample entry document the cropped frame dimensions of the AVC base layer. In such a case, all sample entry child boxes except decoder configuration describe the base layer, not the MVC reconstruction(s).

[0637] For layered HEVC, if the sample entry type is 'hvcl' or 'hevl', the width and height documented in the VisualSampleEntry is set using only the base layer information. In such a case, all sample entry child boxes also describe the base layer.

[0638] It is noted that if the sample entry type is 'hvc2', 'hev2', 'hvc3' or 'hev3' and the track contains an L-HEVC configuration record, width and height are the maximum cropped frame dimensions of the decoded pictures, within the scope of the sample entry, of any layer in the track that is marked as an output layer of any output layer set. In such a case, all sample entry child boxes also describe the "maximum" value of any output layer, but this would require defining what is the maximum for coir, mdcv, clli, pasp.

[0639] For Versatile Video Coding (WC), there are no specific structures for layered bitstreams in single track. The VvcDecoderConfigurationRecord structure provides fields describing maximum picture with and maximum picture height for a given operating point. If two coded video sequences differ in colour space or bit depth indications, then two different VVC sample entries are required. This does not cover the case where different colour space are present for different operation points. In such case, what should be described in the sample entry is unknown.

[0640] When the referenced coded video sequences (CVS) contain multiple layers and samples are reconstructed for the operating point specified by olsjdx and num_sublayers, avg_frame_rate gives the average access unit rate of the referenced CVSs of the operating point. This would indicate that when ptl_present flag is set in 'wcC' box, the description in the sample entry is for the indicated operating point. However, it is unclear what should be described when the flag is not present.

[0641] When the BitRateBox is present in a WC sample entry with ptl_present_flag equal to 1 in its decoder configuration record, it signals the bit rate information of the sequence of consecutive CVSs associated with the WC sample entry. In such case, the box would describe the entire bitstream, not a specific operating point.

[0642] When the sample entry name is 'wcl' or 'wil' and profile, tier, and level information is present in the sample entry, the contiguous CVSs that the sample entry references forms a compliant WC bitstream as viewed by a VVC decoder operating under the configuration (including profile, tier, and level) given in the VvcConfigurationBox.

[0643] In other words, if ptl_present = 1, the sample entry child boxes should describe the stream under this operating point. o If multiple outputs in OLS, we may have the same problem as L-HEVC with hvc2 / hev2, i.e. different coir, clli. Otherwise, sample entry child boxes should describe the OLS. If ptl_present = 0 and track has to be played, the sample group 'vopi' describes all OLS. Similarly, as with hvc2 / hev2, it is unclear what description to put in the sample entry.

[0644] It is also noted that WC doesn't state anything regarding width and height fields in the sample entry.

[0645] For EVC, only temporal scalability is described in EVC and the sample entry describes the entire stream. In order to address foregoing concerns, it is proposed that:

[0646] - For single track storage of multi-layer bitstreams, unless explicitly stated otherwise, all information described in child boxes defined in ISO-IEC 14496-12 present in the sample entry describe the base layer, lowest temporal sub-layer,

[0647] - Information provided by these boxes may be available per layer or per operating point using the "SubbitstreamPropertyContainerBox" and "SubbitstreamPropertyAssociationBox".

[0648] 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.

[0649] 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.

[0650] 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.

[0651] 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

83CLAIMS1. A method of encapsulating a bitstream of media data into a media file, in a processing device, the bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the method comprising: generating a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, generating descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one subbitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream, generating the media file comprising the track and the descriptive metadata.

2. The method according to claim 1 , wherein the sub-bitstream represents one of a layer, a tile, a subpicture, a 3D region, an operating point or a reconstruction point as defined by a multi-layer or multi-codec coding format or the data corresponding to a split-layer which is a part of a full sample from a multi-layer bitstream or multi-codec bitstream.

3. The method according to claim 1 or 2, wherein a sample table box in a track box of the media file comprises at least one sample entry box describing the sample, wherein the at least one information of the at least one sub-bitstream is stored in a single property container box in the sample table box, wherein the single property container box comprises a list of a plurality of property boxes or fullboxes, wherein each property box or fullbox describes an information representing a property or a configuration that may further characterize a sub-bitstream.

4. The method according to claim 3, wherein the at least one sample entry box comprises a property association box associating an identifier of the at least one subbitstream to a property index list, wherein the property index list may list zero, one or more of the plurality of property boxes or fullboxes.

5. The method according to claim 4, wherein the bitstream comprises a plurality of subbitstreams, and wherein the property association box further comprises, for each property box or fullbox, a flag indicating that the property box or fullbox is essential or not.

846. The method according to claim 4 to 5, wherein another property box or fullbox may be declared directly within the at least one sample entry box, the property index list further comprising the other property box or fullboxes.

7. The method according to claim 6, wherein the property association box further comprises, for each property box or fullbox, an indicator that the property box or fullbox is declared in the single property container box or in the at least one sample entry box.

8. The method according to claim 7, wherein the indicator is a bit within the property association box.

9. The method according to any one of claim 4 to 8, wherein the property index list associated with the identifier of a sub-bitstream may be null if no property box is associated with the sub-bitstream.

10. A method according to any one of claim 1 to 9, wherein the sub-bitstream represents data from a split-layer, wherein the media data comprising base data and additional data to the base data, the method further 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.

11. The method according to claim 10, 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.

12. The method according to claim 10 or 11 , 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.

13. The method according to any one of claims 8 to 9, 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.

14. The method according to claim 10 and 11 , wherein the configuration information is stored in an additional box in a sample table box in the track box of the media file.8515. A method of parsing a bitstream of media data into a media file, in a processing device, the bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the media file comprising a track and descriptive metadata, wherein the track comprises a sequence of samples, each sample comprising media data of the bitstream associated with a single time, wherein the descriptive metadata describes the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one subbitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream, wherein the method comprises decoding the at least one sub-bitstream according to the descriptive metadata.

16. 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 15, when loaded into and executed by the programmable apparatus.

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

18. A device for encapsulating a bitstream of media data into a media file, the bitstream comprising at least one sub-bitstream that comprises a contiguous or noncontiguous sequence of bytes, wherein the device comprises a processor configured to generate a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, generate descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one subbitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream, generate the media file comprising the track and the descriptive metadata.

19. A device for parsing a bitstream of media data into a media file, :86 the bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the media file comprising a track and descriptive metadata, the track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, the descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one sub-bitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one subbitstream, wherein the device comprises a processor configured to decode the at least one subbitstream according to the descriptive metadata.

20. A media file including a bitstream comprising at least one sub-bitstream that comprises a contiguous or non-contiguous sequence of bytes, the media file comprising: a track comprising a sequence of samples, each sample comprising media data of the bitstream associated with a single time, and descriptive metadata describing the bitstream, wherein the descriptive metadata comprises at least one item of information describing the at least one sub-bitstream, wherein the at least one item of information represents a property or a configuration characterizing the at least one sub-bitstream.

Images