Method, device, and computer program for optimizing dynamic encapsulation and analysis of content data

Abstract

At least one embodiment of a method for encapsulating media data of several presentations into a media file. After obtaining a part of the media data of the first presentation, a first part, a first presentation consisting of a first set of tracks, and first metadata describing the first set of tracks are encapsulated, and the first part is encapsulated into one or more first media fragments. After obtaining a part of the media data of the second presentation, a second part, a second presentation consisting of a second set of tracks, and second metadata describing the tracks of the second set of tracks are encapsulated into one or more second media fragments following the first media fragment, and the second part is encapsulated into one or more second media fragments. The second metadata includes an indication for signaling that it does not include at least one track as described in the first metadata in which the second set of tracks is encapsulated.

Description

Technical Field

[0001] The present invention relates to a method, a device, and a computer program for improving the dynamic encapsulation and analysis of media data.

Background Art

[0002] The ISO Base Media File Format (ISOBMFF, also called the file format) is a general format that forms the basis for many other more specific file formats. ISOBMFF is standardized as ISO / IEC 14496-12 by the International Organization for Standardization. This format includes characteristics of media data such as the timing, size, or media information of a time-limited sequence of media data, such as an audio-visual presentation. These characteristics are generally referred to as metadata (or structured data) with respect to the media data (or data). An ISO base media file (also called a media file, movie file, or media presentation) can be one file containing the entire presentation or multiple segment files, where each segment contains a temporal part of the presentation. ISO base media files are structured into "boxes", each of which is identified by a four-character code, also represented as FourCC or 4CC. In the file format, the entire presentation is called a movie. A movie or presentation is logically divided into tracks or consists of one or more tracks, where each track represents a time-limited sequence of media (e.g., a time-limited sequence of video pictures, where the pictures can be either frames or fields for interlaced video). Within each track, each time-limited unit is called a sample. Each track has one or more sample descriptions. Each sample within a track is associated with a description by reference. All the structured data or metadata that defines the arrangement and timing of the media is contained in structured boxes. The media data (e.g., a video frame or an audio sample) is referenced by this structured data or metadata. The media data is stored in media data boxes (e.g., "mdat", "imda", etc.). A presentation can contain zero or more media data boxes. The overall duration of each track is defined within the structured data. Each sample has a defined duration.The exact decoding timestamp of a sample is defined by summing the durations of the preceding samples.

[0003] FIG. 1 shows an example of encapsulated media data temporally organized as a fragmented presentation in one or more media files according to the ISO base media file format.

[0004] The media data encapsulated within media file 100 begins with a FileTypeBox ("ftyp") box (101) that provides a set of brands that identify the exact specification to which the encapsulated media data conforms, which is used by the reader to determine whether it can process the encapsulated media data. Following the "ftyp" box is a MovieBox ("moov") box referenced at 105. The MovieBox box provides the initialization information necessary for the reader to begin processing the encapsulated media data. Specifically, it provides a description of the presentation content, the number of tracks, and information regarding their respective timelines and characteristics. For illustration purposes, the MovieBox box may indicate that the presentation comprises one track with an identifier track_ID equal to 1.

[0005] The fragmented ISO-based media file 100 may be a set of media segment files in which the movie box ("moov") box 105 does not contain information for the entire duration of the movie. In particular, it may have few or no samples within that track (the track is described by the "track" box 135). This minimal or empty movie has additional samples described mainly by a hierarchy of pairs of boxes of a "moof" box (e.g., "moof" box 110 or 120) and an "mdat" box (e.g., "mdat" box 115 or 125) into a structure called movie fragments (e.g., movie fragments 100-1 and 100-2). Each movie fragment contains metadata stored in a MovieFragmentBox ("moof") box (and its sub-boxes) and media data stored in a MediaDataBox ("mdat") box (or an identified media data box "imda"). The presence or absence of movie fragments in the media file is indicated early in the file by the MovieExtendsBox ("mvex") box 130. If movie fragments exist in the media file, the information contained in this box warns the reader that subsequent movie fragments may exist and that these movie fragments must be found and scanned in a given order to obtain all samples of the track. To do so, the information contained in this box needs to be combined with other information of the MovieBox box. The MovieExtendsBox box 130 may include an optional MovieExtendsHeaderBox ("mehd") box and one TrackExtendsBox ("trex") box for each track defined in the MovieBox "moov" box 105. If there is a MovieExtendsHeaderBox box, the overall duration of the fragmented movie is displayed.Each TrackExtendsBox box defines default parameter values for the description of samples (type, size, duration, control flags, etc.) of a track fragment.

[0006] For the sake of explanation, media file 100 includes a first movie fragment 100-1 that contains and describes samples 1 to N of a track identified by a track_ID equal to 1 (as shown in the "tfhd" box). This first movie fragment 100-1 is composed of a "moof" box 110 and an "mdat" box 115. For further explanation, media file 100 includes a second movie fragment 100-2 that contains and describes samples N+1 to N+M of a track identified by a track_ID equal to 1. Similar to the first movie fragment, the second movie fragment 100-2 is composed of a "moof" box (referred to as 120) and an "mdat" box (referred to as 125).

[0007] The encapsulated media data may be fragmented into a single media file or multiple media segment files (referred to as segment files). When encapsulated in multiple segment files, the FileTypeBox and MovieBox boxes (hereinafter also referred to as initialization fragments) are included in an initial segment file (also referred to as an initialization segment) that does not contain any samples of one or more tracks. Subsequent segment files include one or more movie fragments such as movie fragment 100-1 and movie fragment 100-2. These one or more movie fragments may constitute an ISOBMFF segment, a DASH segment, a DASH media segment, a CMAF segment, or a CMAF fragment.

[0008] The use of movie fragments is particularly relevant to live encoding and live packaging (or encapsulation) because this encapsulation mode requires less buffer capacity for the encapsulation module. Since movie fragments can be made available for use as soon as they are encoded and encapsulated, this is also relevant to low-latency streaming such as HTTP-based adaptive streaming like DASH or HLS (HTTP Live Streaming).

[0009] Movie fragments such as movie fragments 100-1 and 100-2 have a box hierarchy different from the box hierarchy under the "moov" box. Similarly, track fragments (described in TrackFragmentBox ("traf") boxes, e.g., "traf" boxes 111 and 121) have a box hierarchy different from the TrackBox box (e.g., different from "trak" box 135). As shown, TrackBox box 135 includes a SampleTableBox ("stbl") box within its box hierarchy that contains descriptive timing information for the media samples of the track. Note that when media file 100 is fragmented, it may not have samples described in boxes below the SampleTableBox ("stbl") box, such as boxes that provide sample size or timing information. However, the SampleTableBox ("stbl") box includes a SampleDescriptionBox ("stsd") box that contains the coding format of the samples (the coding format is identified by a specific 4CC as indicated by the "xxxx" characters) and one or more SampleEntry boxes that provide the initialization information required to configure a decoder according to the coding format.

[0010] For illustration purposes, a SampleEntry box with a four-character type set to "vvc1" or "vvi1" indicates that the associated sample contains media data encoded according to the VVC (Versatile Video Coding) format, and a SampleEntry box with a four-character type set to "hvc1" or "hev1" indicates that the associated sample contains media data encoded according to the HEVC (High Efficiency Video Coding) format. As another example, the sample entry "gpe1" or "gpeg" indicates volumetric media data encoded with G-PCC (ISO / IEC 23090-9). A SampleEntry box may contain other boxes that contain information applicable to all samples associated with this SampleEntry box. Samples are associated with a SampleEntry box via the sample_description_index parameter either within the SampleToChunkBox ("stsc") box within the SampleTableBox ("stbl") box when the media file is an unfragmented media file, or otherwise, when the media file is fragmented, within the TrackFragmentHeaderBox ("tfhd") box within the TrackFragmentBox ("traf") box of the MovieFragmentBox ("moof"), or within the TrackExtendsBox ("trex") box of the MovieExtendsBox ("mvex"). According to the ISO base media file format, all tracks and all sample entries within a presentation are defined within a "moov" box such as the "moov" box 105 and cannot be declared later during the presentation.

[0011] In a movie fragment, this sample is mainly described in the TrackFragmentHeaderBox ("tfhd") box, which may provide, in some cases, the default sample entry (the type of codec in use and the code configuration information), the default sample size, and / or the default sample duration. The actual sample size, duration, offset in the media data portion, or flags (if these values are different from the default values or if no default values are defined) may be indicated in the TrackRunBox ("trun") box for sample description. The TrackRunBox ("trun") box documents a consecutive set (run) of samples of a track within a movie fragment.

[0012] For example, regarding sample timing, a track fragment may include a TrackFragmentBaseMediaDecodeTimeBox ("tfdt") box that provides the absolute decode time stamp, measured on the decode time line, of the first sample in decode order within the track fragment (using the baseMediaDecodeTime parameter). For random access or synchronization, the track fragment may have an indication of the decode time within the "tfdt" box. If this box exists, the player or reader does not need to sum the sample durations of all preceding samples in the previous fragment to find this value. For example, the MPEG DASH specification requires that this box be present in each "traf" box of a media segment within the live profile for ISOBMFF. The "moof" box may contain one or more "traf" boxes, for example, multiplexing audio and video track fragments within the same media data box. Some specifications based on ISOBMFF may constrain the media file or segment file to include one "traf" box per "moof" box.

[0013] It should also be noted that ISOBMFF and its extensions include several grouping mechanisms for grouping tracks, static items, or samples together and associating group descriptions with the groups. Groups typically share common semantics and / or characteristics. For example, the MovieBox ("moov") box 105 and / or the MovieFragmentBox ("moof") boxes 110 and 120 may include sample groups that associate properties with samples of a track or track fragment. A sample group characterized by a grouping type may be defined by two linked boxes: a SampleToGroupBox ("sbgp") box that represents the assignment of samples to the sample group, and a SampleGroupDescriptionBox ("sgpd") box that contains a sample group entry for each sample group that describes the properties of the group.

[0014] Common Media Application Format (CMAF) is standardized as ISO / IEC 23000-19. It is built on top of ISOBMFF, particularly ISOBMFF segments, as a general-purpose container for the streaming delivery of multimedia presentations. For example, the same CMAF presentation may be described by different manifests such as an MPD for MPEG DASH or a playlist for HTTP Live Streaming.

[0015] CMAF is codec agnostic and defines several profiles for audio, video, subtitles, etc., depending on the codec and type of application in use. For example, CMAF provides guidelines regarding the setting of CMAF fragments when the target application is low-latency streaming. This is often a trade-off between encoding delay, buffering constraints, and bitrate efficiency. The longer the CMAF fragment, the larger the receive buffer and presumably the latency, but the compression can be more efficient (avoiding the encoding of intra-encrypted frames such as IDR, CRA frames in the MPEG video codec, i.e., frames without encryption dependency on preceding encoded frames).

[0016] Figure 2 shows the relationship between addressable CMAF segments from a streaming manifest and ISOBMFF movie fragments. A CMAF segment, such as CMAF segment 200, typically has a duration of several seconds (e.g., 2 - 10 seconds) and may contain one or more consecutive CMAF fragments of the same track. CMAF fragments correspond to encoded ISOBMFF media segments with some specific constraints.

[0017] In the example shown in FIG. 2a, the CMAF segment 200 includes a single CMAF fragment 205 that is referenced and consists of a “moof” box 210 and an “mdat” box 215. For the sake of explanation, the “mdat” box 215 includes video samples such as 220-1, 220-6, and 220-10. Further, according to the illustrated example, the first sample (i.e., sample 220-1) corresponds to a random access point, a stream access point, or a stream switching point in the video stream. This access point can be used to start a presentation from a given period, to search in a presentation, to change the resolution or bit rate, to switch for streaming adaptation, etc. It is observed that the samples shown in FIG. 2 correspond to video samples, and the same organization may also be applied to other types of media streams (e.g., audio, subtitles, etc.).

[0018] As shown in FIG. 2b, the CMAF fragment may include several CMAF chunks. According to the illustrated example, the CMAF fragment 205’ includes three CMAF chunks referenced from 250-1 to 250-3. Further according to this example, each of the CMAF chunks comprises a set of consecutive samples and covers a given period that may vary from chunk to chunk. As illustrated, each CMAF chunk is actually constructed like a movie fragment and includes a “moof” box and an “mdat” box. For example, the CMAF chunk 250-1 comprises a “moof” box 255-1 and an “mdat” box 260-1.

[0019] The first CMAF chunk of a CMAF fragment (e.g., CMAF chunk 250-1) may be constrained to be addressable (e.g., associated with a URL or URL template) or to start at an adaptive switching point. This reduces the streaming latency because instead of waiting for an entire CMAF segment (such as segment 200 in Figure 2a) to be encoded, packaged (or encapsulated), and sent, the client must wait for a single CMAF chunk to be encoded, packaged, and sent. In other words, the client should only have to wait for the CMAF chunk to become available for it to request, rather than waiting for the entire segment to be ready.

[0020] CMAF chunks follow the ISOBMFF rules for movie fragments that, for example, have one "traf" box per movie fragment with only one "trun" box, one mandatory "tfdt" per track fragment, and additional constraints such as, depending on the use case, additional boxes that describe encryption (e.g., SampleAuxiliaryInformationOffsetsBox "saio", SampleAuxiliaryInformationSizesBox ("saiz") box, or "seig" sample group description (CencSampleEncryption group)).

[0021] The ISOBMFF file format has proven to be efficient, but there is an increasing need for flexibility in file formats (e.g., ISOBMFF or CMAF), especially to address the surge in live adaptive streaming or on-demand video streaming services. In fact, content data is no longer considered as one piece of data with a pre-known complete composition, but rather as dynamic content data into which content can be injected or spliced, for example, to add advertisements during the playback of a movie or a sports event. Similarly, additional media data may be overlaid on the video, for example, to provide scores or statistics on a sports game video. This requires dynamic processes that were not considered in the file format. For example, in ISOBMFF and derivative specifications, all tracks and all sample descriptions must be known and declared in advance, despite fragmentation.

SUMMARY OF THE INVENTION

[0022] The present invention has been devised to address one or more of the aforementioned problems.

[0023] According to a first aspect of the present invention, there is provided a method for encapsulating media data of a plurality of presentations in at least one media file based on ISOBMFF, the method comprising: obtaining a first portion of the media data of a first presentation, the first presentation being composed of a first set of tracks, the obtaining; encapsulating first metadata describing the tracks of the first set of tracks and encapsulating the first portion of the media data of the first presentation into one or more first media fragments; obtaining a second portion of the media data of a second presentation, the second presentation being composed of a second set of tracks, the obtaining; Encapsulate second metadata that describes a second set of tracks into one or more second media fragments following the first media fragment, and encapsulate a second portion of the media data of the second presentation into one or more second media fragments, and The second metadata includes an indication signaling that the second set of tracks does not include at least one track as described in the encapsulated first metadata.

[0024] Thus, the method of the present invention provides dynamic and / or flexibility for encapsulation and parsing while maintaining the main features of the file format such as fragmentation and random access, for example. This flexibility lies in adding or deleting tracks, invalidating the initially declared tracks, overwriting tracks, replacing tracks, inserting tracks, etc. The display of changes in the track configuration maintains random access, meaning that any player tuned to the media presentation can obtain the current track configuration without additional requirements to minimize startup delay.

[0025] According to some embodiments, the second metadata includes an indication for signaling that the value of at least one parameter of the description of at least one track belonging to the first set of tracks and the second set of tracks is different in the first metadata and the second metadata.

[0026] According to some embodiments, the second set of tracks does not include at least one track described in the first metadata.

[0027] According to some embodiments, the second set of tracks includes at least one track not described in the first metadata.

[0028] According to some embodiments, at least one media file comprises a metadata portion for encapsulating metadata common to all media data encapsulated in the at least one media file, and first metadata is encapsulated in the metadata portion.

[0029] According to some embodiments, at least one or more first media fragments comprise a metadata portion for encapsulating metadata common to all media data encapsulated in the at least one or more first media fragments, and first metadata is encapsulated in the metadata portion of the at least one or more first media fragments.

[0030] According to some embodiments, an indication signaling that a second set of tracks does not include at least one track as described in first metadata encapsulated in the second set of tracks includes an indicator indicating that the second set of tracks is a new set of tracks.

[0031] According to some embodiments, an indication signaling that a second set of tracks does not include at least one track as described in first metadata encapsulated in the second set of tracks includes an indicator indicating that the second set of tracks has already been described and that at least one parameter of the description of the second set of tracks has changed.

[0032] According to some embodiments, the second metadata further includes an indication for signaling that one or more second media fragments can be parsed independently of the first fragment.

[0033] According to some embodiments, the fragment is a segment or fragment of a Common Media Application Format (CMAF) or a segment or fragment of an ISO Base Media File Format (ISOBMFF).

[0034] According to a second aspect of the present invention, a method for analyzing media data of a plurality of presentations, wherein the media data is encapsulated based on ISOBMFF as a plurality of fragments of one or more media files, the method being executed by a client, obtaining first metadata describing a first set of tracks of a first presentation; obtaining at least one media fragment including encapsulated second metadata and encapsulated media data, the second metadata describing a second set of tracks of a second presentation, the encapsulated media data being the media data of the second presentation, and at least one media fragment following the media fragment including the media data of the first presentation; analyzing at least a part of the second metadata; when it is determined that the second metadata includes an instruction for signaling that at least one track as described in the encapsulated first metadata is not included in the second set of tracks, updating the track description for analyzing the encapsulated media data; A method is provided that includes.

[0035] Thus, the method of the present invention provides dynamism and / or flexibility for encapsulation and analysis while maintaining the main features of the file format such as fragmentation and random access. This flexibility lies in adding or deleting tracks, invalidating initially declared tracks, overwriting tracks, replacing tracks, inserting tracks, etc. The indication of a change in track configuration preserves random access, meaning that any player tuned to the media presentation can obtain the current track configuration without additional requirements to minimize startup delay.

[0036] According to some embodiments, updating the track description includes analyzing at least another portion of the second metadata, and updating the track description is based on the metadata of at least another portion of the second metadata.

[0037] According to some embodiments, at least another portion of the second metadata includes a description of at least one track not described in the first metadata.

[0038] According to some embodiments, at least another portion of the second metadata includes a new value of at least one parameter of the description of at least one track described in the first metadata.

[0039] According to some embodiments, one or more media files include a metadata portion for encapsulating metadata common to all media data encapsulated in the one or more media files, and the first metadata is encapsulated in the metadata portion.

[0040] According to some embodiments, the first metadata is obtained from a media fragment.

[0041] According to some embodiments, the method is obtaining at least one media fragment including encapsulated third metadata and encapsulated media data, wherein the third metadata describes a third set of tracks of a presentation including the media data encapsulated in the at least one media fragment including the third metadata, analyzing at least a portion of the third metadata, If it is determined that the third metadata includes an instruction to signal that the description of the third set of tracks is similar to the description of the set of tracks previously determined, skip the analysis of another part of the third metadata and use the current description of the set of tracks to analyze the media data of at least one media fragment including the encapsulated third metadata, and further includes.

[0042] According to another aspect of the present invention, there is provided a processing device including a processing unit configured to execute each step of the method described above. Other aspects of the present disclosure have any features and advantages similar to the above-described first and second aspects.

[0043] At least a part of the method according to the present invention can be implemented by a computer. Therefore, the present invention can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects that are generally referred to as "circuits", "modules", or "systems" in this specification. Further, the present invention can take the form of a computer program product embodied in any tangible expression medium having computer-usable program code embodied therein.

[0044] Since the present invention can be realized by software, the present invention can be implemented as computer-readable code for providing to a programmable device on any suitable carrier medium. The tangible carrier medium may include a storage medium such as a floppy (registered trademark), CD-ROM, hard disk drive, magnetic tape device, or solid state memory device. The transient carrier medium may include an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal, or an electromagnetic signal, such as a signal such as a microwave or a RE signal.

Brief Description of the Drawings

[0045] Here, embodiments of the present invention will be described by way of example only with reference to the following drawings.

[0046]

Figure 1

[0047]

Figure 2

[0048]

Figure 3a

Figure 3b

Figure 3c

[0049]

Figure 4

[0050]

Figure 5

[0051]

Figure 6a

Figure 6b

[0052]

Figure 7

[0053]

Figure 8

Figure 9

[0054]

Figure 10

[0055]

Figure 11a

Figure 11b

Figure 11c

[0056]

Figure 12

[0057]

Figure 13

[0058]

Figure 14

[0059]

Figure 15

DETAILED DESCRIPTION OF THE INVENTION

[0060] According to some embodiments of the present invention, the content of some "moof" boxes of fragmented ISOBMFF media data is optimized to provide dynamics and / or flexibility to encapsulation and parsing while maintaining the main features of the file format such as fragmentation and random access.

[0061] According to some embodiments of the present invention, the track structure or track configuration may be declared not only at the start of the presentation but also along the media presentation. Further, this track configuration is repeated to guarantee random access for the reader, and this repetition is done in a way that avoids wasteful processing for the reader to continuously play the file. Thus, some embodiments of the present invention extend movie fragments and facilitate fragment or segment concatenation with minimal ISOBMFF structure rewriting. A new ISOBMFF structure is defined to make this feature interoperable between a writer and a parser that support this feature.

[0062] [General Encapsulation and Parsing Process] Figure 3a shows an overview of a first method for encapsulating or storing a multimedia presentation according to some embodiments of the present invention. For encapsulation or storage, the media data 305 being referenced can be video, a spatial sub-part of a video, audio, volumetric visual media, subtitles, or a combination of such elementary streams. They are encapsulated in a media file or media segment file 325, in a way that may enable adaptive streaming via HTTP, possibly with low latency. As shown, the server 300 includes an encapsulation module 320 (also called an ISOBMFF writer or simply a writer), and optionally a streaming manifest generation module (not shown). This server 300 may be connected to a communication network 330 to which a client 350 is also connected via a network interface (not shown). Examples of clients are media players on a PC, tablet, TV, or smartphone.

[0063] Server 300 processes media data 305 and prepares it for streaming or storage, which is called encapsulation. It mainly consists of adding metadata that describes the media data in terms of, for example, data type, codec in use, size, data offset, timing, etc. As described above, media data 305 can correspond to an audio presentation or a video presentation, or both, and may optionally be accompanied by subtitles or timed text. Media data 305 may be raw data captured by a sensor or generated by a content producer or editing tool. Media data 305 may also be available as compressed or encoded media data 315 according to different encoding versions in some cases. Encoding or compression may be performed using an encoder module such as encoder module 310 (optionally one for each media type), or remotely from the server, or by the server itself. Compression may be live encoding (and encapsulation).

[0064] Media data 305 may also be encapsulated media data, and these media data are encapsulated in a way that is not suitable for low-latency streaming, for example, as unfragmented tracks. In the latter case, the encapsulation module (e.g., encapsulation module 320) also includes a reading part for decrypting the media data and then encapsulating the decrypted media data according to some embodiments of the present invention.

[0065] According to the illustrated example, the encapsulation module 320 of the server 300 is used to encapsulate media data into movie fragments, for example, according to ISOBMFF and its extensions (such as CMAF, NAL unit-based file format, etc.). The server 300 then generates the referenced media file 325 or one or more segment files 325. Optionally, the server 300 may generate a streaming manifest such as a DASH MPD or an HLS playlist (not shown). The generated file, segment file, or manifest may be stored in a remote storage device accessible via, for example, the network 340, for redistribution via on-demand or live streaming.

[0066] According to some embodiments of the present invention, the encapsulation module 320 generates an encapsulated file (or segment) that enables low-latency and adaptive streaming via HTTP.

[0067] The client 350 is used to process data received from the communication network 330 or read from a (local or remote) storage device, for example, to process a media file or media segment 325. This data may be streamed to the client and thus involves a streaming module (not shown) responsible for parsing the streaming manifest, determining requests to fetch media streams, and adapting the transmission according to instructions in the manifest and client parameters such as available bandwidth, CPU, application needs, or user preferences.

[0068] This received data is decapsulated within a decapsulation module 360 (also known as an ISOBMFF parser, ISOBMFF reader, or simply a parser or reader), and the decapsulated data (or parsed data) may be decoded by a decoding module for storage display or for output to an application or user. The decoder module (one or more per media type in some cases) may be part of the client, an external module, or dedicated hardware.

[0069] The decapsulated data may correspond to the encapsulated media data 365 (e.g., a video bitstream, an audio bitstream, etc.). Decapsulation, decoding, and rendering may, for example, minimize the latency between, e.g., a multimedia presentation recorded (as media data 305) and its visualization by the user as media data 375, e.g., by processing data chunks of each media stream in parallel and synchronously, and may be a live operation that processes the media file as soon as it is received.

[0070] The client or server may be a user device, but may also be a network node that acts on the transmitted or stored media file. The server or client may each include only the encapsulated and unencapsulated portions.

[0071] Note that the media file 325 may be communicated to the client or reader 350 in different ways. In particular, the server or writer (or packager) 300 may generate a media file 325 with a media description (e.g., DASH MPD) and, upon receiving a request from the client 350, communicate it directly (or stream it) to the client 350. The media file 325 may also be downloaded and stored by the client 350, either all at once or progressively.

[0072] For illustration purposes, the media file 325 may encapsulate media data in boxes according to the ISO Base Media File Format (ISOBMFF, ISO / IEC 14496-12) and its derivative specifications (e.g., the carriage of NAL unit structured video in ISOBMFF, ISO / IEC 14496-15 or Common Media Application Format, CMAF ISO / IEC 23001-19). In such a case, the media file 325 may correspond to one or more media files (indicated within a FileTypeBox ("ftyp") box or a SegmentTypeBox ("styp") box). According to ISOBMFF, the media file 325 can include two types of boxes, one or more "media data boxes" (e.g., "mdat" or "imda" boxes) containing media data, and "metadata boxes" (e.g., "moov" or "moof" boxes) containing metadata that defines the arrangement and timing of the media data. The media file or segment file includes movie fragments. The media data box contains all the data of the media data 305 or the encoded media data 315. There may be one media data box that multiplexes the media data, but there may also be one or more media data boxes, for example, one for each media type, and in some cases, one or more for each movie fragment.

[0073] This system configuration may particularly have a modification example on the encapsulation side as shown in FIG. 3b or FIG. 3c.

[0074] FIG. 3b shows an overview of a second method for encapsulating or storing a multimedia presentation according to some embodiments of the present invention.

[0075] For the sake of explanation, media file 305-1 is similar to media file 305 in FIG. 3a, and optional encoder module 310 and encoded media file 315 are similar to the optional encoder module 310 and encoded media file 315 described with reference to FIG. 3a.

[0076] As shown, compared to the encapsulation module 320 described in FIG. 3a, the encapsulation module 320' may encapsulate media data from several sources in media file 325', e.g., media data 305-1 and media data 305-2, by adding data from media data 305-2 to media data 305-1, by overwriting data in media data 305-1 with data from media data 305-2, or by replacing data from media data 305-1 with data from media data 305-2. Media data 305-2 may be, for example, an advertisement for insertion in the middle of a movie that is media data 305-1.

[0077] FIG. 3c shows an overview of a third method for encapsulating or storing a multimedia presentation according to some embodiments of the present invention, where several encapsulation modules are used to encapsulate different media data in media file 325''.

[0078] For further explanation, media files 305-1 and 305-2 may be similar to media files 305-1 and 305-2 in FIG. 3b, and optional encoder module 310 and encoded media file 315 may be similar to the optional encoder module 310 and encoded media file 315 described with reference to FIG. 3a. Similarly, writer 300-1 and encapsulation module 320-1 may be similar to writer 300 and encapsulation module 320 in FIG. 3a.

[0079] According to the example shown in FIG. 3c, the first writer is used to encapsulate the first media file. For example, writer 300-1 is used to encapsulate media file 305-1 which can be a movie. The second writer is used to encapsulate the second media file. For example, writer 300-2 is used to encapsulate media file 305-2 which can be an advertisement. The encapsulated media files may be combined within media file 325''. Writers 300-1 and 300-2 may operate independently of each other and may be separate entities that in some cases do not know anything about each other. Note that writer 300-2 may include an encoder module (not shown). For the sake of explanation, media file 325'' may consist of the concatenation of the media file generated by writer 300-1 on the one hand and the media file generated by writer 300-2 on the other hand.

[0080] The encapsulation module 320-1 within writer 300-1 may be responsible for encapsulating the main presentation, and the second encapsulation module 320-2 within writer 300-2 may be responsible for encapsulating additional content, replacement, splicing, or alternative content. In such a case, the operation performed by the second writer may be referred to as "blind" splicing or "late splicing".

[0081] According to some embodiments, the two writers can share knowledge of a common set of setup information, for example, information written in a "moov" box such as an initial track or sample configuration as suggested by reference number 380. This enables implementation of use cases that are more advanced than blind splicing. For example, this can disable some tracks, overload some tracks, and keep some tracks active. Such a configuration may be described as "non-blind splicing" or "early splicing".

[0082] [Encapsulation of Media Files According to Some Embodiments of the Present Invention] FIG. 4 shows an example of the steps of an encapsulation process according to some embodiments of the present invention. For the sake of explanation, such steps may be executed in the encapsulation module 320 of FIG. 3a, in the encapsulation module 320' of FIG. 3b, or in the encapsulation modules 320-1 or 320-2 of FIG. 3c.

[0083] As shown, the first step is directed to initializing a writer (step 400), for example, the writer 300 of FIG. 3a, the writer 300' of FIG. 3b, or the writers 300-1 and / or 300-2 of FIG. 3c. The configuration may be related to the encapsulation module(s) only if the encapsulation module 320 of FIG. 3a, the encapsulation module 320' of FIG. 3b, or the encapsulation modules 320-1 or 320-2 of FIG. 3c, and the encoder module 310, or the encoder settings cannot be controlled, for example, if this configuration is hard-coded. For the sake of explanation, this configuration step may include indicating whether the media file to be generated consists of a single file or multiple segment files. This configuration includes defining the granularity of random access in the presentation (e.g., every second, every 2 seconds, etc.) and, optionally, for streaming applications, defining the switching points and addressable objects in the presentation (e.g., DASH media segments, CMAF segments, CMAF fragments, or CMAF chunks). This configuration may also include indicating whether the media file to be generated is completely dynamic or not.

[0084] A fully dynamic media file is different from a known ISO-based media file in that it may not contain the same box hierarchy as defined in ISO / IEC 14496-12. For example, the sequence of objects within a presentation in a fully dynamic media file may not contain exactly one movie box as it would if it were a conventional ISO-based media file. Typically, an ISO-based media file contains a top-level "moov" box that includes one or more "trak" boxes, each declaring a track (media type, header information) and a sample composition (such as the "stsd" box within "stbl"). A fully dynamic ISOBMFF may not contain a "moov" box. This type of media file that provides dynamic movie fragments or dynamic tracks may be indicated using the brand "dytk" of the ExtendedTypeBox, or using a brand of "isod" or higher of the FileTypeBox ("ftyp") or SegmentTypeBox ("styp"). The "moov" of the movie box may not be essential in a fully dynamic media file, for example when using dynamic tracks. However, in that case, the first movie fragment loaded may have a FileTypeBox or ExtendedTypeBox indicating support for dynamic tracks (e.g., using the proposed brands or any brand value defined to indicate support for dynamic tracks). The FileTypeBox can also be optional and replaced with an essential SegmentTypeBox instead. Alternatively, a fully dynamic media file may still contain a movie box, but it may not contain track declarations and may contain, for example, only movie header information.

[0085] If the generated media file is not a completely dynamic media file (test 401 is false), the writer generates initialization data including an "ftyp" box and a "moov" box at the top of the file according to ISOBMFF (step 402). The created "moov" box contains "trak" boxes, each of which declares track information known at the time of creation of the media file. For a completely dynamic media file, the media file here may contain a specific brand indicating that it may support or contain dynamic tracks (i.e., tracks that can be declared later in the file and do not necessarily have to be in the "trak" box under the top-level "moov" box). This initialization data may be used, for example, as an initialization segment for adaptive streaming. Next, after initialization, the writer starts encapsulating the data for the media presentation. For the sake of explanation, it is assumed that this encapsulation aims to encapsulate the first media data (e.g., a movie) and the second media data (e.g., an advertisement or temporary information for rendering over or along the movie). The main difference between the first media data and the second media data is that the first media data is assumed to be known at setup. Thus, the "moov" box may include a track declaration for the first media data and a track declaration for the second media.

[0086] As shown, this encapsulation process may include a step of checking whether the second media data should be encapsulated (test 403), a step of obtaining some first media data (step 404) if the second media data should not be encapsulated, and a step of encapsulating the obtained first media data (step 407). This encapsulation may include describing the samples and indexing the corresponding data stored in a media data box (e.g., "mdat" or "imda"). For example, the sample description of the first media data (e.g., size, data offset, duration, and / or composition time) may be provided within the "trun" box. The media data encapsulated in this way is output as part of a media file (step 408), and this process is repeated until the end of the media presentation (test 409). If the end of the presentation has not been reached, the algorithm loops back to step 403 to obtain the second media data. If the second media data is encapsulated, they are obtained and the writer generates a new track configuration (step 406). The display of the track configuration will be described below with reference to FIGS. 6a and 6b. As shown, the first media data may be obtained in parallel with obtaining the second media data (step 405). After showing the track configuration, the writer encapsulates the first, second, or both the first and second media data (step 407) and outputs the encapsulated media data as part of a media file (step 408). This output may be based on an ISOBMFF fragment base, a CMAF fragment base, a CMAF segment base, or an ISOBMFF segment.

[0087] If the media file to be generated is a completely dynamic media file (test 401 is false), the encapsulation module generates a minimum set of initialization information items, for example, only the "ftyp" or "styp" box, or generates either "ftyp" or "styp" together with a minimum "moov" box (e.g., without a track declaration therein) (step 420). Next, the writer obtains the media data to be encapsulated, i.e., the first and / or second media data (step 421), and generates track configuration information for the obtained media data (step 422). This step of showing the track configuration will be described below with reference to FIGS. 6a and 6b. Next, the obtained media data is encapsulated (step 423), which includes describing samples of different tracks, and the encapsulated media data is output as part of the media file for storage, transmission, or any use of the media file. If the end of the presentation has not been reached (step 425), this algorithm loops at step 421. As described with reference to step 409, this output may be based on ISOBMFF fragment base, CMAF fragment base, CMAF segment base, or ISOBMFF segment base.

[0088] [Analysis of Encapsulated Media Files According to Some Embodiments of the Present Invention] FIG. 5 shows an example of the steps of the analysis process according to some embodiments of the present invention. Note that a client or reader that executes such a process may also be called a "parser", "application", "media player", or "player".

[0089] As shown, this process starts from the initialization of the parser (step 500) according to some embodiments of the present invention, for example, based on a media file or a media segment file received from a server and generated according to the steps shown in FIG. 4, or in some cases accessed locally using a manifest file. More precisely, this player is initialized using the information obtained by requesting the initialization segment or start (e.g., the first byte) of the media file. The URL or byte range for the initialization data may be obtained from a manifest file such as a DASH MPD or a playlist for HTTP Live Streaming. From the obtained initialization information, the player may determine the type of media data present in the media presentation, whether the media file is completely dynamic, the codec in use, etc.

[0090] Determining whether the media file is completely dynamic (step 501) may be based on a brand indication (e.g., the "dytk" brand or any dedicated brand value for indicating dynamic tracks within the media file), or on the presence or absence of the "moov" box and the presence of one or more "trak" boxes. For example, if the player detects an "ftyp" or "styp" box that does not have a "moov" box (or has a "moov" without a track declaration), the media file may be determined to be a completely dynamic media file.

[0091] If the media file is not completely dynamic, the parser reads the initialization data (step 502) and instantiates an appropriate decoder to process the media data required in subsequent steps. After reading these initialization data, the parser can determine that changes to the track configuration or modifications to the presentation may occur in some cases (e.g., an indication in the brand with a "dytk" value having a "moov" box that provides a complete track description). Next, the parser obtains the encapsulated media data, for example, by reading or downloading the data, or by using a streaming or progressive delivery mechanism (step 503). It should be noted that the data may be obtained at different granularities, for example, as movie fragments, ISOBMFF segments, CMAF fragments, or CMAF segments. Next, the parser checks whether the new track configuration is part of the obtained data (step 504). If the track configuration does not exist, the parser or reader decapsulates (or parses) the samples from each track (step 506) and provides the obtained data to an appropriate buffer, decoder, or renderer (step 507).

[0092] If a new track configuration exists in the obtained data (as determined in step 504), the parser decodes and interprets the new track configuration to determine the current number of tracks and their configurations. Examples of track configurations are described below with reference to FIGS. 6a and 6b. There may be new tracks, or tracks defined within the "moov" box. Depending on this track, especially if there are new tracks (i.e., tracks not described in the "moov" box), the parser further checks whether it has already encountered these new tracks. If it has not yet encountered these new tracks, the parser can further examine the track description, for example, to obtain sample descriptions. This track configuration and sample description may affect the set of decoders initialized in step 502. Depending on the track configuration, the parser may need to reset some decoders, and it may be assumed that some previous configurations can be reused without resetting from the track configuration. This parsing process is repeated until the end of the encapsulated media file is reached (i.e., if the end of the encapsulated media file is not reached, this algorithm loops at step 503).

[0093] If the parser determines that the media file is completely dynamic (step 501), it may not be able to immediately set up the decoder. That is, for example, by reading, downloading, or using the streaming mechanism, more data is obtained (step 520). Also in this case, these data may be obtained at different granularities, for example, as movie fragments, ISOBMFF segments, CMAF fragments, or CMAF segments. For a completely dynamic track, the parser processes the track configuration as described below with reference to FIGS. 6a and 6b (step 521). From this track configuration, the parser can determine the current number of tracks and their characteristics (step 522). It should be noted that when satisfied for the first time, the track configuration can lead to several decoder initializations. When already satisfied by the parser, the track configuration may consist of reusing the decoder configuration already allocated or set up (for example, in the previous step 522). After processing the track configuration, the parser or reader analyzes the samples to obtain the corresponding data (step 523) and outputs this data to a buffer, decoder, or renderer according to the application using the media file (step 524). As shown, this process is repeated until the end of the presentation is reached (that is, if the end of the presentation is not reached, this algorithm loops at step 520).

[0094] [Dynamic Track Indication] Figures 6a and 6b show an example of box-based information for indicating the dynamic track configuration within a media file. This is directed towards two aspects. The first aspect aims to define a metadata structure that conforms to the ISOBMFF box for indicating a change in the track configuration (step 406) or indicating a new track configuration (step 422). This signal should also enable random access, and the current track configuration should be obtainable whenever the player or reader starts parsing (or tuning) the media presentation. This means that the indication of the track configuration should be repeated. The second aspect aims to provide an indication as to whether the track configuration changes (i.e., whether it is simply repeated or not). The second aspect may also provide an indication of the scope of track configuration changes, such as "minor" changes that are also called functionally equivalent or "significant" changes that may require a parser or reader to process a reset or update of the decoder configuration.

[0095] To handle this change, the option could have been to rely on the box version. The same version number indicates repetition, but this conflicts with box version management, and some boxes do not even have a version field like the UserDataBox. Furthermore, it does not indicate the intended purpose of the box version; rather, it indicates a change in the binary syntax and not a change in the payload. One approach to dealing with this second aspect could be to perform a comparison of past and current boxes, typically via a hash function. While this enables detection of the same configuration, it has several drawbacks in terms of client resources (additional processing and memory requirements) and does not allow signaling of iterative configurations with minor variations that do not require re-parsing of the data (e.g., in metadata). Therefore, it is necessary to introduce a change detection mechanism for indicating track configuration changes (e.g., dynamic track or sample description changes) within the movie fragment so that the parser or reader can properly identify information repeated across fragments.

[0096] Finally, while the sample may be signaled as an iterative sample using a dependency flag, ISOBMFF lacks support for such signaling for non-sample data (metadata or box structure). There are mechanisms that enable the transmission of configuration information for media presentation. For example, the DSM-CC (ISO / IEC 13818-6) standard defines data carousels and object carousels. The object carousel extends the more limited data carousel and specifies a standard format for representing a file system directory structure that includes a root directory or service gateway and one or more files and directories, but this feature is not available in ISOBMFF. According to the illustrated embodiment, the DynamicMovieBox, referenced at 600, which may be included within a movie fragment (not shown, "moof"), includes zero or more DynamicTrackBoxes, referenced at 601, each of which includes a specific DynamicTrackHeaderBox, referenced at 602, and some common boxes found within the TrackBox (e.g., "stsd", "trgr", "tref", etc.).

[0097] [Dynamic Movie Box] The DynamicMovieBox 600 may include zero or more UserDataBoxes 620 or MetaBoxes 630, as defined in ISOBMFF. This is identified, for example, by the 4CC code of "dymv", or any dedicated 4CC reserved for this use and not conflicting with existing 4CCs.

[0098] The DynamicMovieBox overwrites completely or partially the MovieBox setup (track list, user data, or meta) of a specific fragment. This MovieBox setup is sometimes called "track setup". This mode (partial or full overwrite of the track configuration, or extension of the track configuration) may be indicated by parameters of the DynamicMovieBox box (e.g., flags or fields within a Box or FullBox). This parameter may be called, for example, "source_id" or "carousel_id". For example, this parameter may be an identifier of a presentation, and / or may be repeated along a presentation or part (time interval) of a sequence. Each DynamicMovieBox may have an associated source_id that indicates how the movie fragment extends or modifies the first MovieBox ("moov") or a previous DynamicMovieBox ("dymv"). A source_id equal to 0 may indicate that the movie box is extended by the movie fragment. A source_id different from 0 may indicate that the movie box is ignored (i.e., does not exist or is considered no longer active for a given movie fragment).

[0099] For example, this parameter of the DynamicMovieBox box may be set by the encapsulation module to indicate the presence of a field that enables the player to be informed about whether the track configuration is iterative, complementary, overloaded, or whether it disables track configurations that may be present in the "moov" box or in the previous movie fragment. This box may be present in the movie fragment or only in the first movie fragment of the ISOBMFF segment (e.g., a segment with a dependent movie fragment). Thus, there may be zero or more DynamicMovieBoxes within the media file, but there can be no more than one DynamicMovieBox per movie fragment box ("moof"). When used in the first movie fragment of a segment containing a dependent movie fragment, this dependent movie fragment may inherit track declarations (DynamicMovieBox, DynamicTrackBox, DynamicTrackHeaderBox) from this first movie fragment in addition to other characteristics of this first movie fragment.

[0100] For DynamicMovieBox, the following flags may be defined: - 0x000001 is denoted as source-info-present and, if so set, indicates the presence of source information (or information like a carousel or carousel information), and if not set, both source_id and source_flags take the value 0. Source information, "information like a carousel", or carousel information corresponds to information that may be repeated in the movie fragment. -0x000002 is marked as in - splice and, when so set, indicates that the track described in the DynamicMovieBox corresponds to the content splice period, and this immediately returns to the previous configuration. By monitoring this flag and the source_id field, the processing media pipeline can be optimized as needed (e.g., to avoid unloading / reloading decoder resources). When source_id is 0, this flag is not set. This is because source_id = 0 indicates some continuity in the initial presentation, for example, in the presentation timeline.

[0101] A DynamicMovieBox with a source_id different from 0 may contain one or more DynamicTrackBoxes. When using dynamic tracks, the first track fragment (「traf」) of each track in the parent movie fragment (「moof」) should have a TrackFragmentBaseMediaDecodeTimeBox (「tfdt」) box. This can facilitate time adjustment by a reader or player between two different presentations. When the encapsulation module inserts a DynamicMovieBox with a source_id different from 0 into a movie fragment, it can indicate to the player or reader that there may be a discontinuity (e.g., within the presentation timeline) between two movie fragments. This may be used as an indication to the player or reader to avoid forgetting that the encapsulation module may reuse the source_id it previously used for a previously encountered source_id and thus may have recorded (along with the corresponding decoder configuration). Therefore, a DynamicMovieBox with a source_id different from 0 and no DynamicTrackBox is a kind of indicator that there is no continuity between the values of the source_id before and after the movie fragment containing such a DynamicMovieBox.

[0102] Optionally, or as a variation of flag value 0x000002, a third flag value (e.g., 0x000004) may be set and used to indicate that the track configuration is temporary and will immediately return to the "moov" configuration.

[0103] Optionally, or as a variation of flag value 0x000002, another flag value (e.g., 0x000008) may be set and used to indicate that the track configuration is temporary and will immediately return to the track configuration of the previous movie fragment.

[0104] Using these additional flag values, the parser or reader can have more detailed processing of the decoder configuration and can decide to buffer some configurations to avoid some decoder resets and possibly display freezes. For example, when the flag value 0x000004 is set, it means that the decoder may only hold the first decoder configuration corresponding to what was derived from the "moov" box.

[0105] [Syntax Example of DynamicMovieBox] According to the first example, fields and boxes are mixed as follows. aligned(8) class DynamicMovieBox extends FullBox('dymv', version = 0, flags) { if (flags & 1) { unsigned int(32) source_id; unsigned int(32) source_flags; } DynamicTrackBox tracks; / / Optional: 0 or 1 UserDataBox user_data; / / Optional: 0 or 1 MetaBox meta; / / Optional: 0 or 1 }

[0106] According to the second syntax example, the DynamicMovieBox box may contain only such boxes and may inherit from Box instead of FullBox. aligned(8) class DynamicMovieBox extends Box('dymv'){ DynamicMovieBoxHeader dyn_movie_header; / / 0 or 1. DynamicTrackBox tracks; / / Optional: 0 or 1 UserDataBox user_data; / / Optional: 0 or 1 MetaBox meta; / / Optional: 0 or 1 }

[0107] If the DynamicMovieBoxHeader is a Box or FullBox that provides fields equivalent to source_id and source_flags from the first example, the DynamicMovieBoxHeader may be defined as follows. aligned(8) class DynamicMovieHeaderBox extends FullBox('dymv', version=0, flags){ if (flags & 1) { unsigned int(32) source_id; unsigned int(32) source_flags; } / / Optionally, information about the track configuration, or other fields that provide information common to all tracks in the track configuration.

[0108] If there is no DynamicMovieHeaderBox, the parser or reader may simply assume a new track configuration indicating that the "moov" structure applies to this movie fragment. The DynamicMovieHeaderBox may contain additional parameters that provide parameters applicable to all tracks within the new track configuration, such as time scale, language, or transformation matrix (as in the MovieHeaderBox "mvhd").

[0109] The semantics for the DynamicMovieBox may be defined as follows. The source_id (or carousel_id, the name is just an example) referenced at 604 in Figure 6a identifies the starting point of the movie fragment (e.g., a presentation). If the DynamicMovieBox is set to 0, the DynamicMovieBox modifies the MovieBox (e.g., disabling, overwriting, adding, replacing some tracks, or changing sample descriptions or high-level metadata). Otherwise, all tracks, user data, and possibly high-level metadata declared in the MovieBox are ignored. In other words, when the value of this field is different from 0, the DynamicMovieBox indicates a new track configuration or a new presentation for one or more movie fragments (the same number as this value is repeated in the movie fragment). When this field is set to 0, it may be seen by the parser or reader as indicating that the media or presentation maintains the same timeline, the same set of track identifiers as "moov" (possibly with new ones), or something that has been overwritten. When this field is different from 0, it may be interpreted by the parser or reader as a complete change of track configuration, possibly involving a change in the presentation timeline. The default value of the source_id is considered to be 0 if not declared, for example. source_flags (or carousel_flags, name is just an example and is referenced at 605 in Figure 6a) identifies the modifications declared in this DynamicMovieBox and compares it if there is a source_id with the same value as the previous DynamicMovieBox. The following flags may be defined to be set or combined into the value of the source_flags parameter. -0x00000001, if so set, indicates that one or more tracks have been modified. For example, one or more tracks have been added, overloaded, or invalidated (temporarily removed). -0x00000002, if so set, indicates that the global user data (e.g., the user data box for the entire presentation, e.g., the user data box within the "moov" box or within the DynamicMovieBox "dymv" box) has been modified. -0x00000004, if so set, indicates that the global meta box (e.g., the metadata for the entire presentation, e.g., the metadata within the "moov" box or within the DynamicMovieBox "dymv" box) has been modified. -0x00800000, if so set, indicates that the change (for presentation or track configuration) is functionally equivalent to a previous DynamicMovieBox with the same source_id. In this case, the file reader or parser may safely skip processing of the DynamicMovieBox if the previously parsed DynamicMovieBox has the same source_id. In other words, the reader or parser may decide not to parse the track configuration indicated within the DynamicMovieBox with this flag value when the same source_id has already been processed. This also indicates that the player can safely continue using the decoder configuration, and thus avoid decoder processing (e.g., reset or re-initialization to another configuration (such as codec change, profile or level change, etc.), and skipping steps 522 or 505 of FIG. 5). The default value of source_flags is considered 0, for example, if not declared. Note that when source_id is equal to 0, the value of source_flags may be set to 0 or 0x00800000. This means that a source_id equal to 0 indicates that the presentation declared in "moov" is active (current), and at that time, if a change in track configuration is indicated using a DynamicMovieBox, the player must process it, for example, unless it has already encountered this track configuration, further indicating that the flag value 0x00800000 is set. The value of source_flags may be set to 0x00800000, but it needs to be ignored (i.e., considered not set) by the file reader if the previous DynamicMovieBox has a different source_id, or if this is the first DynamicMovieBox being parsed.

[0110] A change in the source_id value between two consecutive movie fragments N and N-1 in a single-byte sequence (such as a file, remote resource, etc.) is an indication to the reader or player that the track within fragment N should be considered a new track and the track within fragment N-1 should be ignored. In this case, there is no guarantee that the timeline is continuous between fragments N and N-1. In such cases (e.g., between fragments N and N-1), whether and / or how the file reader reconstructs a continuous timeline depends on the implementation (i.e., it need not be standardized) and may be driven by the processing pipeline capabilities. However, for these reconstructions, the implementation should avoid introducing long playback gaps at the source_id change points. For example, the parser or reader may decide to recalculate the timing (e.g., by using some edit list, such as by using sample descriptions, via the "ftdt" or any box for timing instructions).

[0111] If two consecutive movie fragments N and N-1 have the same value for source_id, the timelines of all active tracks in both fragments may be interpreted as continuous by the reader or parser, and the constraints on the TrackFragmentBaseMediaDecodeTimeBox for each track may be respected. For track fragments with the same track ID, the first "tfdt" in movie fragment N is equal to or greater than the first "tfdt" in movie fragment N-1 plus the sum of the sample durations in movie fragment N-1. If some tracks need to be inserted or replaced, these tracks may all be declared in a single DynamicMovieBox, in their own DynamicMovieBox, or a combination of both approaches may be used to declare them.

[0112] If the track from the MovieBox is not enumerated for update or deletion in any of the DynamicTrackBoxes of the DynamicMovieBox with Source_id value 0, this track is considered still valid, but there may be no track fragments of this track in the movie fragment, as in the case of a normal movie fragment.

[0113] In a variant, the DynamicMovieBox 600 may be a top-level box of a segment or a fragment. Thereby, it is possible to mutually declare the track configuration across multiple movie fragments. This may be suitable for encapsulation where there is one track per movie fragment. This may not be more suitable for encapsulation where one "moof" contains all tracks. In the DynamicMovieBox declared as a top-level box, the same fields and sub-boxes may be used. When one of the top-level boxes is the DynamicMovieBox instead of the "moov" box, indicating (e.g., step 420 in FIG. 4) or identifying (e.g., step 501 in FIG. 5) that the media file is completely dynamic is another variant. When using the DynamicMovieBox 600 as the top-level box, the SegmentIndexBox, if it exists, may refer to the beginning of the DynamicMovieBox instead of or in addition to the "moof" box. This may be indicated by a specific (new value) reference_type in the "sidx" box.

[0114] [Dynamic Track Box] As shown in Figure 6a, the DynamicTrack box 601 may contain zero or more boxes. This is identified, for example, by the 4CC code of "dytk", or any dedicated 4CC reserved for this use and not conflicting with existing 4CCs. This provides a lighter track declaration than the "trak" box and its sub-boxes. Since this can be repeated along the media presentation, some fields or sub-boxes may not always be present, thus providing a more compact track description than those in the "moov" and "trak" boxes. The DynamicTrackBox declares a new track, or modifies (e.g., partially or completely overwrites) or replaces an existing track during the period of the parent movie fragment.

[0115] Tracks declared by a DynamicTrackBox that do not have a matching track_ID within the MovieBox implicitly declare a TrackExtendsBox with the value of default_sample_description_index set to 1 and the values of default_sample_duration, default_sample_size, and default_sample_flags set to 0. Similarly, tracks declared by a DynamicTrackBox with an associated source_id not equal to 0 may also implicitly declare these boxes. This allows the default values of the track run boxes that describe the samples of these tracks to be defined. Note that the default values may need to be set in the TrackFragmentHeaderBox (since there is no explicit TrackExtendsBox). If multiple track fragments are used for a dynamic track within one movie fragment, the default values may need to be re-encoded for each track fragment. The DynamicMovieBox600 may contain zero or more DynamicTrackBox601. The DynamicTrackBox contains a DynamicTrackHeaderBox and provides track information with reference to 602 in FIGS. 6a and 6b.

[0116] A variation of the implicit declaration of the TrackExtendsBox is to declare this box within the "dymv" box. Combined with the source_flags value (a "trex" used by the movie fragment or a dedicated value indicating that the default value has not changed between two movie fragments or segments), it becomes possible to indicate when the default value has changed or when it is still applicable from one movie fragment to another.

[0117] The semantics for the DynamicTrackBox may be defined as follows. If present, data_info indicates the source or location of the data for the samples of this dynamic track. If not present, the sample data is present in the container (media data box). The location of this data may be indicated by a URL or URN, or any kind of data entry inherited from DataEntryBaseBox. If present, minf_header_info provides the media-specific header box that is normally found within the MediaInformationBox of a track having the same handler_type as this dynamic track. Derived specifications may mandate its presence. This may be any one of the specific media handlers (such as "vmhd", "smhd", "hmhd", "sthd", "nmhd", "vvhd", etc. defined by ISOBMFF or derived specifications).

[0118] Other boxes contained in the DynamicTrackBox, except for the DynamicTrackHeaderBox described below, have semantics that do not change compared to those defined in ISO / IEC 14496-12. If they are present, they replace the corresponding boxes in the TrackBox (and sub-boxes) of the MovieBox or the previous DynamicTrackBox.

[0119] [Dynamic Track Header Box] Figure 6b shows an example of the syntax of a DynamicTrackHeaderBox, such as DynamicTrackHeaderBox 602 of Figure 6a. The DynamicTrackBox can be used to disable an existing track of a MovieBox (or an existing track of a previous DynamicMovieBox), overwrite or replace the definition of an existing track of a MovieBox (or an existing track of a previous DynamicMovieBox), or define a completely new track. As shown, the DynamicTrackHeaderBox 602 may include track identification information (e.g., track_ID) and overall information about the track. This is identified, for example, by the 4CC code of "dtkh" or any dedicated 4CC reserved for this use and not conflicting with existing 4CCs. This provides a lighter track header declaration than the sub-boxes of the "tkhd" box and the "trak" box. Since this can be repeated along the media presentation, some fields or sub-boxes may not always be present, thus providing a more compact track description than that in "moov". In other words, the DynamicTrackBox may be regarded as a compactification of the TrackHeaderBox, EditListBox, and MediaHeaderBox within a single container to keep the track signaling overhead low.

[0120] The DynamicTrackHeaderBox is included in each DynamicTrackBox.

[0121] The following flags may be defined for the dynamic track header box (values of the flag field 602-1 of the DynamicTrackHeaderBox): -0x000001 is indicated as ignore_track (or dyn_tk_ignore_track), and when this value is set, it indicates that the track declared within a previous DynamicMovieBox or MovieBox having the same source_id as the parent DynamicMovieBox should be ignored (treated as if it does not exist) until the next movie fragment is received for this track.

[0122] This flag value may be used, for example, in the "non-blind splicing" mode.

[0123] If the flag value 0x000001 (ignore_track or dyn_tk_ignore_track) is not set in the DynamicTrackHeaderBox, the parent DynamicTrackBox either overwrites the existing track or declares a new track. In this case, - If there is a "stsd" box in the parent DynamicTrackBox: If there is a track with the same id in the MovieBox, overwrite the current track; otherwise, add a new track to the presentation. · Note 1: In the derived specification, it can be specified that the handler type / time scale / width / height remain the same in this case. · Note 2: This is generally used for updating the sample description of the track, - When there is no "stsd" box in the parent DynamicTrackBox: There must exist a track in the MovieBox with the same id, and all fields of the DynamicTrackHeaderBox must match the corresponding fields of the track / handler / media header box declared in the MovieBox. This may be used to update the UserDataBox, MetaBox, TrackReferenceBox, or TrackGroupBox of the track. In this case, the sample descriptions of the track are not changed. Using such an indication, the player or reader may assume that a decoder reset is not required. Additional flag values may be defined to indicate that the track header has changed but remains functionally equivalent to its previous occurrence (the same track_ID within "dytk" within "dymv" with the same source_id value). For some values used in the DynamicMovieBox or DynamicTrackBox, the value 0x800000 may be used here. This may be used, for example, when volume information changes or when some parameters that do not affect the decoder configuration change. When there is no "stsd" box, a dedicated flag may also be used to avoid re-enumerating elements that match elements in the "moof" track elements.

[0124] The semantics of the DynamicTrackHeaderBox are: The track_ID indicates the ID of the track declaration. It may be the track_ID already declared in the TrakBox under the moov box (for track removal or track overload) or a new track_ID (for track addition). modification_flags602-2 identifies modifications in the parent DynamicMovieBox by comparing them with previous DynamicTrackBoxes having the same value of track_ID and the same value of source_id in the parent DynamicMovieBox. These flags may be used by the reader to optimize the processing of consecutive track fragments having the same track_id and source_id.

[0125] (Regarding modification_flags602-2) The following flags may be defined. -0x000001: The track configuration has changed (change of one or more fields in the DynamicTrackHeaderBox, change of an associated media header box (such as "vmhd", "smhd", etc.), or change of an associated data information box). -0x000002: The media configuration has changed (e.g., new sample description). -0x000004: The track UserDataBox has changed. -0x000008: The track MetaBox has changed. -0x000010: The track TrackReferenceBox has changed. -0x000020: The track TrackGroupBox has changed. -0x800000: The track modification is functionally equivalent to a previous DynamicTrackBox having the same track_id and source_id. This flag is set within 602-2 by the encapsulation module, but should be ignored (i.e., considered not set) by the file reader when a previous DynamicMovieBox has a different source_id, or when this is the first DynamicTrackBox analyzed for this track_id and source_id. If modification_flags is not set (either explicitly or according to the above rules), or if the value is 0, there is no information regarding the track's modifiability compared to a previous DynamicTrackBox with the same track_id and source_id, and the entire content of the DynamicTrackBox needs to be re-evaluated. The same handler_type as the handler_type of the HandlerBox, The same media_timescale as the timescale of the MediaHeaderBox, delay indicates the media delay of the track in media_timescale. The presentation time of any sample within the track is the sum of the sample's composition time and this value. A negative presentation time indicates that the sample data (or part thereof) is not presented (media skip), and when not encrypted, the value 0 may be used by the parser or reader. The same track_flags as the flags of the TrackHeaderBox. If this field is not encoded and there is no track within the MovieBox that matches the same track_ID, this field value is presumed to be 0x000003. The same language as the language of the MediaHeaderBox. The same extended_language as within the ExtendedLanguageBox. The same alternate_group as within the TrackHeaderBox. If it is not encrypted and has the same width as inside the TrackHeaderBox, the media width after applying the pixel aspect ratio and clean aperture is used. If it is not encrypted and has the same height as inside the TrackHeaderBox, the media height after applying the pixel aspect ratio and clean aperture is used. If it is not encrypted and has the same layer as inside the TrackHeaderBox, the layer is 0. If it is not encrypted and has the same matrix as inside the TrackHeaderBox, the identity matrix is used. If it is not encrypted and has the same volume as inside the TrackHeaderBox, full volume (1.0) is used.

[0126] When using the new boxes from Figures 6a and 6b, in a simple case, signaling a new track may incur the following costs in addition to the STSD. - 12 bytes for the DynamicTrackHeaderBox header - 17 bytes for audio (without volume), 27 bytes for video with size / layer and no track matrix (63 with matrix), - 8 bytes for the DynamicTrackBox header - 12 bytes for the DynamicMovieBox header.

[0127] The overhead for a 1 - second fragment is estimated to be around 0.392 kbps for audio and around 0.47 kbps for video (0.76 kbps if a full visual matrix is specified). Thus, it is estimated to be around 1.3 kbps for full signaling (track and "stsd") compared to over 4 kbps if the new track were to be described with a classical TrackBox.

[0128] According to some embodiments of the present invention, the signaling for indicating the removal of a track is estimated to be 12 + 4 + 8 + 12 bytes, i.e., 0.288 kbps, in the case of a 1 - second fragment.

[0129] Furthermore, the proposed box enables efficient signaling of track addition and provides an integrated approach for adding tracks in a presentation or for changing codec configurations. This enables the removal of tracks (or signaling of temporarily inactive or non - active tracks), and the various flags in the DynamicMovieBox or DynamicTrackHeaderBox can easily cause a parser or reader to detect repeated or changed track configurations, similar to temporary changes in track configuration (such as splice periods), for example, the time interval when a new presentation replaces a previous one, such as an advertisement for a movie.

[0130] This proposed box may be combined with movie fragments that depend on reference movie fragments. Assume that such dependent movie fragments are signaled by a particular version, for example, as follows. aligned(8) class MovieFragmentHeaderBox extends FullBox('mfhd', version, 0){ unsigned int(32)sequence_number; } If the version is not 0, the SampleGroupDescriptionBox, DynamicTrackBox, or MetaBox defined in the last movie fragment where the MovieFragmentHeaderBox version is 0, or the last TrackFragment within the last movie fragment, shall apply to this movie fragment, and there will be no SampleGroupDescriptionBox, DynamicTrackBox, or MetaBox defined for this movie fragment. Note that this flag field can be used as a variation of the version field. This can be more convenient when the MovieFragmentHeaderBox needs to be preferably extended with new fields enclosed within the version number.

[0131] [Example of track removal] Figure 7 shows an example of a track configuration that disables the tracks declared in the "moov" box. In this example, two tracks represented as 700 and 701 are first declared within the "moov" (705) and "trak" (710, 720) boxes with track_ID = "i" and "j". As shown, the tracks are fragmented into movie fragments 700-1, 700-2, etc. up to 700-5, and 701-1 to 701-5. These tracks are first described in the "moov" box 705 and the "trak" boxes 710 and 720. They may correspond to, for example, a first media source or presentation that can be regarded as a primary media source (e.g., a movie or a sports live event).

[0132] To disable the tracks declared in the 「moov」 box 705 (having track_ID 「i」 and 「j」), a new track configuration is shown within the media file (within the 「moof」 box 730) from the movie fragments 700-3 and 701-3. The new content referenced at 706 may correspond to, for example, a second media source, splicing, or alternative content of the first or main media source that is encapsulated at step 407 of FIG. 4. This new track configuration is signaled within the media file as DynamicMovieBox 730-1, repeated within DynamicMovieBox 731-1 (as indicated by the same value of source_id), and repeated within DynamicMovieTrackBox boxes 730-2 and 730-3, and DynamicMovieTrackBox boxes 731-2 and 731-3. As shown, DynamicMovieBox 730-1 has a field indicating an overwrite of the initial configuration being set. In the example of FIG. 7, this corresponds to a source_id field having a value different from 0 (here 1). DynamicMovieBox 730-1 indicates, for example, in the source_flags field, the change (if any) of this movie fragment. In this example, this value may be set to 0, indicating that no further information is provided to the DynamicMovieBox in the track configuration change. In fact, since this is the first occurrence of the 「dymv」 box having this identifier (source_id) value, the indication of what information exists or what might have been changed can be omitted (e.g., source_flags = 0). It is an indication to the player or reader that any indication of change through the source_flags field (which is 0 here but could take a different value) should be processed for this first occurrence.

[0133] The two DynamicTrackBoxes referenced by 730-2 and 730-3 declare new tracks with track_ID = "k" and "l". Since these two boxes are the first occurrences of these track IDs for this source_id (or presentation), they have modification_flags (0 or 0x800000) in the header indicating no change. The value 0 is an indication that the player or reader needs to process the track descriptions (parameters of "dytk" 730-2 or 730-3 and "dtkh" 730-21 or 730-31). The sample descriptions for these new tracks are provided in the "stsd" boxes 730-22 and 730-32. This provides information, for example, about the codec, profile, or level values for the player or reader to set up the decoder. These sample descriptions may require a reset of the decoder or creation of a new decoder configuration to process the samples of these new tracks "k" or "l".

[0134] Next, for each fragment up to fragments 700-4 and 701-4, the track configuration is repeated to provide random access. However, to avoid unnecessary processing for players that started before fragment 700-3 and 701-3 or earlier, the source_id is kept at the same value (here 1), and in the DynamicMovieBox box 731-1, the source_flags can be set to 0x800000 (or even 0) to indicate that the track configuration is the same as the previous track configuration defined in the DynamicMovieBox box 730-1 having the same value of source_id (here value 1). Using 0 or 0x800000 makes the operation of the parser or reader the same. If the track configuration with this source_id value has already been processed, the boxes (DynamicMovieBox 731-1 and its sub-box 731-3) that describe and represent the track configuration are ignored. Using 0x800000 provides more detailed information than using 0, which indicates that there may be changes in the track configuration but these are minor configurations. For example, the modifications relate to high-level metadata or user data but do not affect the number of tracks or the decoder configuration. Similarly, the details of the track information in the DynamicTrackBox boxes 731-2 or 731-3 are indicated by the modification_flags for 0x800000, indicating that the track configuration is approximately the same as the previous fragment or at least does not require a decoder reset or reconfiguration. The "stsd" boxes 730-22 and 730-32 still exist for a player or reader that randomly accesses this movie fragment 700-4 or 701-4 to obtain the sample descriptions of tracks "k" or "l".Here, we focus on the possible values of source_id, source_flags, or modification_flags, but note that other parameters from the DynamicTrackBox or DynamicTrackHeaderBox may also be specified in these boxes (e.g., those shown in FIGS. 6a and 6b that are not shown explicitly for clarity). Note also that the presence of the "stsd" boxes 730~22 and 730~32 may be optional when the fragments 700~4 and 701~4 are dependent movie fragments (since the player cannot randomly access the bitstream starting from these fragments).

[0135] In the case of movie fragments from 700-5 or 701-5, there is no DynamicMovieBox box that can be used as an instruction to the player or reader to consider that the configuration defined in the "moov" box 705 applies or resumes, or is restored. The decoder set up for track "i" or "j" may be restored to the previous configuration, for example, at 505 or 522 in Figure 5, if saved by the player or reader (or if the player or reader can maintain some configurations and switch from one configuration to another). Note that the player or reader may decide to store the decoder configuration depending on the value of the flags field of the DynamicMovieBox box 730-1 or 731-1. In this example, the flag value is set to 3 (0x000003), which means that the configuration change is temporary and can return to the previous configuration (here, the configuration defined in the "moov" box 705). Also note that additional values defined in the variations described in relation to DynamicMovieBox can be set here. Similarly, for the DynamicTrackHeaderBox boxes 730-21, 730-31, 731-21, or 731-31, the flag value is set to 2 (0x000002) to further indicate modification_flags. Alternatively, in this example, the flag value could have been set to 0, thus avoiding the declaration of modification_flags, especially on fragments 700-3 and 701-3 (the first occurrence of the new track declaration). If the source_flags of the parent "dymv" is not 0 or 0x800000, it may be useful to set the flag value of the DynamicTrackHeaderBox of consecutive fragments to 2 to further indicate the change in track configuration at the track level.

[0136] For clarity, not all DynamicMovieBox and DynamicTrackBox boxes are shown in Figure 7. According to some embodiments of the present invention, there should be one DynamicMovieBox box per movie fragment and one DynamicTrackBox box per track, occurring between movie fragment 700-3 or 701-3 and movie fragment 700-4 or 701-4. It should also be noted that the modification_flags value in the repeated occurrence of the DynamicTrackBox between movie fragment 700-3 or 701-3 and movie fragment 700-4 or 701-4 may be set to either 0 or 0x800000 when no change occurs in the corresponding track that requires decoder re-initialization from one movie fragment to another. If a change occurs, the value of modification_flags needs to be set accordingly. Using the value 0x800000 instead of 0 indicates that the value 0 has not changed at all, while the value 0x800000 indicates a "minor" change that does not require at least resetting the decoder, providing some flexibility. Of course, the values 0 or 0x800000 are examples, and other values can be used for the same purpose if they are specified for this use. Normal boxes within the "moof" box, such as "traf", "trun", etc., are applied as defined by ISOBMFF and are not described except that the track_ID may refer to the track_ID from the "dytk" box included in the movie fragment. In the example of Figure 7, the "traf" box refers to tracks "k" and "l" of fragments 700-3 to 700-4 and 701-3 to 701-4, respectively. This sequence of movie fragment 706 represents a second presentation (e.g., an advertisement) spliced into the first presentation or the main presentation (e.g., a movie).

[0137] Figure 8 is another example of the use of some embodiments of the present invention, showing the addition of tracks in their own movie fragments. According to this example, one or more tracks for a first presentation are declared in the "moov" box 805 (for clarity, only one track, referenced at 800 and having track_ID = "i", is shown). As shown, track 800 includes several movie fragments such as movie fragments 800-1 to 800-6. Track 800 is declared along with its corresponding track box 810 and sub-boxes.

[0138] At a point in the presentation timeline corresponding to movie fragment 800-2, a first new track is added (track 801, track_ID = "k"). This track is also composed of one or more movie fragments 801-2 to 801-4. The addition of this new track is indicated by the encapsulation module having a DynamicMovieBox830-1. This DynamicMovieBox has a flag value set to 1 to indicate the presence of a source_id value. Here, source_id is set to the value 0, indicating that the track configuration declared in "moov" 805 has been modified, and here, the new track 801 described in DynamicTrackBox830-2 and DynamicTrackHeaderBox830-21 is added. The source_flags parameter of DynamicMovieBox830-1 can be set to 0 (no indication of track configuration change) or 1 to indicate that the change is in the number of tracks. The DynamicMovieBox includes the DynamicTrackBox830-2 itself, which includes the DynamicTrackHeaderBox830-21 and at least the sample description box "stsd" 830-22. The flag value set to 2 in the DynamicTrackHeaderBox830-21 indicates that further information regarding the track modification is provided in the modification_flags parameter. Here, the value 0 or 0x00800000 indicates that no significant change has occurred because this is the first occurrence. An alternative could be to encode the flag value 0 of the DynamicTrackHeaderBox830-21 without indicating the modification_flags. "moof" 830 includes a "traf" box 830-3 that references the new track (having track_ID = "k"), and its associated media data box 830-4 is also placed in the media file. Finally, the movie fragments of track "i" are also available as "moof" 810-1 and its associated media data box 810-2.This movie fragment 810-1 does not require specific instructions such as "dymv", "dytk", or "dtkh".

[0139] Thereafter, in the presentation timeline, at the time corresponding to movie fragment 800-3, another additional track 802 is introduced with track_ID = "j". The movie fragments described for the period are movie fragments for track "i" (not shown, classical "moof" boxes such as 810-1 and "mdat" boxes such as 810-2), "j" (832), and "k" (831). Movie fragment 831 includes a DynamicMovieBox831-1 with a source_id (e.g., equal to 0) indicating that the track configuration is changed again from "moov" (e.g., here track addition). The source_flags of DynamicMovieBox831-1 are set to 1 to indicate that there is a change in the track configuration (addition of the new track "j" referenced at 802). DynamicTrackBox831-2 repeats the sample description to enable random access, and its DynamicTrackHeaderBox referenced at 831-21 has a DynamicMovieBox with a source_id equal to 0, indicating that no modification has occurred for track "k" after the last movie fragment. This can be indicated by the modification_flags value 0 or 0x00800000, or simply by setting the flag value of "dtkh" 831-21 to 0. "moof" 831 includes one or more classical "traf" boxes 831-3 referencing track_ID "k", and the associated media data is provided within "mdat" box 831-4. "moof" 832 includes a DynamicMovieBox832-1 with a source_id set to 0 to indicate that the track configuration changes. The source flag can be set to 1 to indicate a change in number or track, i.e., the change of track "j". DynamicMovieBox832-1 includes a DynamicTrackBox832-2 that itself includes a DynamicTrackHeaderBox832-21 with a flag that can be set to 0 since it is the first occurrence for track_ID = "j".The DynamicTrackBox832-2 also includes sample descriptions within the "stsd" box 832-22 for the player or reader to obtain information about samples, information about the codec in use, etc. Finally, the "moof" 832 includes one or more "traf" 832-3 boxes that reference the new track "j", other fragment-related boxes defined by ISOBMFF (such as "trun", etc.), and its associated media data box 832-4.

[0140] At the time corresponding to the movie fragment 800-4, two new tracks "j" and "k" still exist. The dynamic movie boxes exist in their respective "moof" boxes (not shown). The flags of the DynamicMovieBox are set to source_id = 0 and source_flags = 0 to indicate that the track configurations of 800-3, 801-3, and 802-3 are repeated at the current time interval. Each DynamicMovieBox has a DynamicTrackBox with appropriately set flags, for example, to indicate that no changes have occurred. The sample description boxes 830-22 and 832-22 still exist in their respective DynamicTrackBoxes to guarantee random access at the time corresponding to the movie fragment 800-4.

[0141] At the time corresponding to movie fragment 800-5 or 802-5, track "k" no longer exists. Thus, the DynamicMovieBox834-1 (within the "moof" box 834) indicates a change in the number of tracks having source_id = 0 and source_flags = 1 (track "k" no longer exists). The DynamicMovieBox834-1 includes a DynamicTrackBox834-2 having sample description 832-22 (repeated from fragment 802-3), optionally along with other boxes (not shown). The DynamicTrackBox834-2 includes a DynamicTrackHeaderBox834-21 having flags = 2 indicating the presence of modification_flags. The modification_flags having the value 0x00800000 indicate that no "significant" change occurred for this track "j". Next, the classical boxes "traf" 834-3 and "mdat" 834-4 provide the sample description and data for the samples of fragment 802-5 and fragment 800-5 (within 814-1 and 814-2).

[0142] At the time corresponding to movie fragment 800-6, only the tracks from the "moov" box remain. There is no need for a dynamic movie box or a dynamic track box, and the track configuration automatically switches to that declared in the "moov" box 805.

[0143] Figure 9 shows the same scenario as Figure 8, except that new tracks 902 and 901 (similar to tracks 802 and 801) are declared within a single "moof" box. Thus, at the time corresponding to movie fragment 900-3 or 900-4, there are two new tracks "j" and "k", and the "moof" box 931 contains a DynamicMovieBox 931-1 which itself contains two DynamicTrackBoxes 931-2 and 931-3. Each contains a DynamicTrackHeaderBox referenced at 931-21 and 931-31 respectively, and a sample description referenced at 931-22 and 932-22 respectively. The values of their flag fields are set to 2 (to indicate modification_flags) and 0 (first occurrence) respectively. The modification_flags of track "k" are set to 0 or 0x00800000 to indicate that there is no change to this track, i.e., the continuation of this track. Next, each track "j" and "k" has its "traf" referenced at boxes 931-4 and 931-5 respectively, and an associated "mdat" box 931-6. For clarity, the movie fragment of track "i" corresponding to 900-3 is not shown here. Finally, if only the new track "j" remains, in addition to track "i", the DynamicMovieBox 934-1 contains only one DynamicTrackBox 934-2 for track "j". The DynamicTrackHeaderBox 934-21 indicates that there is no change to track "i". The DynamicMovieBox 934-1 indicates a change in the track configuration (source_flags = 1) corresponding to the end of track 901 (the one with track_id = "k").

[0144] Figure 10 shows another example of a track configuration change where the track first declared in the "moov" box is overwritten. This overwrite consists of updating the sample description, for example, changing the codec, or changing some of the parameters of the track described in the top-level metadata, or user data for the track, or the track header. Such modifications may occur in non-blind or early splicing modes, especially because knowledge of the "moov" box is required to reuse the track_ID value.

[0145] According to the example shown in FIG. 10, the presentation includes one or more tracks represented by 1000 (track_ID "i") and 1001 (track_ID "j"). These tracks are described in the "moov" box 1005 and its sub-boxes. Each track is fragmented (e.g., movie fragments 1000-1 to 1000-5 and 1001-1 to 1001-5). At some points on the presentation timeline (which may occur several times even if only one occurrence is shown for simplicity), the presentation is modified by a new track configuration. For example, new content is injected from fragments 1000-3 and 1001-3. This change is indicated by the encapsulation module within the movie fragment box that describes fragments 1001-3 and 1000-3. There may be one "moof" box that describes all track fragments 1001-3 and 1000-3, or one "moof" box for each track fragment. This example shows the case of just one "moof" box 1030. The "moof" box 1030 includes a DynamicMovieBox1030-1 with source_id = 0 indicating that there is a change or modification in the track configuration of the presentation. The source_flags with a value of 1 indicates that a change has occurred at the track level. The DynamicTrackBox1030-2 indicates in its track header 1032-21 that the track with an ID equal to "i" is modified. The flag value of this box can be set to 0 because it appears for the first time. Alternatively, this can be set to 2 using modification_flags that provide a change, for example, indicating an overload of the "stsd" box (flag value 0x000002 set in modification_flags), indicating the possibility of an overload of the MetaBox of the track (flag value 0x000008 set in modification_flags), and thus resulting in a flag value of 0x000003 when modification_flags = 10, or when the track layout is changed.

[0146] DynamicTrackBox 1030-2 includes an overloaded box "stsd" 1030-22 and "meta" 1030-23 that provide new definitions for sample description, and high-level metadata for the track "i" for the fragment period. These new definitions replace those declared in the "moov" box of the track "i" and apply for the duration of the fragment (1000-3). The flag value of the DynamicMovieBox (1030-1) is set to 1 to indicate the presence of source identification information (source_id parameter). DynamicMovieBox 1030-1 also includes a second DynamicTrackBox 1030-3 that indicates a change to the track "j", such as a change to the track header information, as indicated by modification_flags = 1. Note here that since there is no new sample description (no "stsd" box), the sample configuration from the "trak" box 1011 continues to apply. The box 1030 "moof" also includes classical "traf" boxes (1030-4 and 1030-5) that describe sample offsets, sizes, durations, etc., and the sample data corresponding to fragments 1000-3 and 1001-3 is stored in the "mdat" box 1030-6.

[0147] At the time corresponding to fragments 1000-4 and 1001-4, the new track configurations declared for fragments 1000-3 and 1001-3 continue to apply. Thus, the "moof" box 1040 contains a DynamicMovieBox 1040-1 with a source_flag indicating that no change occurred compared to the previous track configuration with source_id = 0. This is further verified in each DynamicTrackBox, and each DynamicTrackBox has a modification_flags value of 0x00800000, indicating to the player or reader that the same track configuration as the previous fragment is applied. For track "i", note that the "stsd" and "meta" boxes (1030-22 and 1030-23) are repeated to guarantee random access when starting the presentation playback at the time corresponding to fragment 1000-4 or 1001-4.

[0148] The example of FIG. 10 shows the overwriting of all tracks first declared in the "moov" box, but note that some embodiments of the present invention are still applicable when only a subset of tracks is overwritten (e.g., only track "i" or only track "j"). In such cases, the DynamicMovieBox and DynamicTrackBox boxes indicate which tracks have been changed, but it is not necessary to include a DynamicTrackBox box for tracks that have not been changed.

[0149] Regardless of the examples of FIGS. 7 - 10, when a presentation is encapsulated as one track fragment per "moof" box, it should be noted that the media file will then contain several movie fragments, at least two of which contain one DynamicMovieBox box (as shown in FIG. 8) during a given time interval. Within this set of DynamicMovieBoxes, in order to avoid ambiguity for the reader or player in determining whether those DynamicMovieBoxes are related to the same presentation, the DynamicMovieBox can be extended with an additional parameter called, for example, bundle_id. This parameter can be used to identify a set of DynamicMovieBox boxes related to the same presentation. In fact, the use of source_id by the reader or player to determine whether the DynamicMovieBox and its sub - boxes indicating track configuration changes should be processed depends on source_id. If a bundle_id exists, this is the pair (bundle_id, source_id) that should be considered instead of source_id alone (the unchanged values of these two parameters).

[0150] [Embodiment for Multiple DynamicMovieFragments] This embodiment addresses one limitation of the above - described embodiment where the DynamicMovieBox 600 contains only the source_id parameter and does not contain the bundle_id parameter. In this embodiment, the syntax of the DynamicMovieBox is extended to reuse most of the parameters defined and described above (e.g., 601 in FIGS. 6a and 6b). This extended DynamicMovieBox also supports the use cases described with reference to FIGS. 7, 9, and 10 and resolves possible limitations of use cases such as those in FIG. 8, as described below.

[0151] FIGS. 11a - 11c show examples of track configuration changes.

[0152] Figure 11a shows an example of a presentation update, or an example where a dynamic track is added to or spliced into a presentation, which may lead to a change in the track configuration. For the sake of explanation, movie fragments 1101 and 1102 correspond to a first presentation 1100 having that track configuration (e.g., a series of movies and track fragments with track_ID = 1). Movie fragments 1111 and 1112 correspond to a second presentation 1110 having that track configuration for splicing or adding within a given period in the first sequence 1100. For further explanation, presentation 1110 consists of a sequence of movie fragments including movie fragments 1111 and 1112. Each movie fragment can also include several track fragments ("traf"), but note that only one is shown for clarity.

[0153] Figure 11b shows how the movie fragments 1111 and 1112 of the second presentation 1110 of Figure 11a can be modified by the encapsulation module before being inserted or spliced into a sequence, such as the first sequence 1100 of Figure 11a. Here, note that for each movie fragment, one dynamic movie box "dymv" is added according to the original fragmentation of the second presentation 1110 (e.g., dynamic movie box "dymv" 1121 for movie fragment 1111 and dynamic movie box "dymv" 1122 for movie fragment 1112). Here, in the DynamicMovieBox, additional parameters such as the bundle_id parameter can be used. By adding this parameter, the two DynamicMovieBoxes 1121 and 1122 can associate a presentation with, as described, a part or component of this presentation. This indicates that the new track configuration corresponds to the addition of each track configuration described in these parts. Note that depending on the value of the source_id in the DynamicMovieBox, the track configuration of the current fragment may also include the track configuration from the movie fragment without the DynamicMovieBox. For consistency, when the DynamicMovieBox of a given fragment sets its source_id to 0, other DynamicMovieBoxes within the same fragment (possibly different "moof") should also set their source_id to 0. The name bundle_id is just an example and can also be called any other arbitrary name for indicating identifiers such as "subset_id", "component_id", "partition_id", or for tracking partial configuration changes within the source_id. Using these parameters, the tracks declared or changed in the DynamicMovieBox can have the same configuration for multiple consecutive movie fragments.The source_flags parameter of the DynamicMovieBox, when indicated by the encapsulation module, enables the file parser to detect that the DynamicMovieBox is a repetition of a previous DynamicMovieBox having the same values for source_id and bundle_id. For the same value of source_id, if multiple dynamic tracks or movie-related metadata (such as user data or metaboxes) are changed or declared in multiple DynamicMovieBoxes, these DynamicMovieBoxes each use a different bundle_id. This may enable indicating that a part of the presentation has changed.

[0154] Figure 11c shows an example in which a part of the track configuration of a presentation has been changed to the inserted presentation 1110. According to this example, the configuration of track N (refer to 1121-21) of DynamicMovieBox1121-2 has been changed. This partial configuration may be indicated at the DynamicTrackBox level (1121-21) by using a modification flag or at the DynamicMovieBox level (1121-2) by assigning a new value of the bundle_id to this DynamicMovieBox1121-2. This is useful for indicating that a part of the track configuration has been changed between movie fragments of a track only for those with a bundle_id change (i.e., DynamicMovieBox1121-2 in the example) without the need to process the entire track configurations of both tracks N (1121-2) and K (referred to at 1122-2). This information within the DynamicMovieBox enables the reader to detect changes in the partial configuration (track or moov level) without inspecting the DynamicTrackBoxes contained in the DynamicMovieBox (step 504 in Figure 5). For example, when it is shown that the pair (source_id, bundle_id) does not change and the source_flags do not change further, the reader can safely skip the DynamicTrackBoxes. Note that the bundle_id may also correspond to configuration changes that are not exactly track configuration changes, such as high-level changes within the "moov" box like metadata within the MetaBox ("meta") or user data within the UserDataBox ("udat").

[0155] Figure 12 shows an example of an updated syntax for DynamicMovieBox to process a case where two or more dynamic tracks are inserted during the first movie or splice period, each inserted into its own movie fragment. According to this embodiment, DynamicMovieBox1200 includes, for example, a parameter for identifying a part within a given source_id, denoted as bundle_id (referred to as 1205 in Figure 12). As described with reference to DynamicMovieBox600 in Figure 6, DynamicMovieBox may include zero or more DynamicTrackBoxes. Note that it is possible to use a DynamicMovieBox with a source_id different from 0 without using a DynamicTrackBox to enforce discontinuity between two movie fragments. A DynamicMovieBox with a source_id equal to 0 may be used without using any DynamicTrackBox to update MetaBox or UserDataBox.

[0156] Tracks declared or modified in a DynamicMovieBox may have the same configuration for a plurality of consecutive movie fragments. The source_flags parameter enables the file parser to detect that the DynamicMovieBox is a repetition of a previous DynamicMovieBox having the same values for source_id and bundle_id. For the same value of source_id, if multiple dynamic tracks or movie-related metadata (user data, meta) are modified or declared in multiple DynamicMovieBoxes, these DynamicMovieBoxes may each use a different bundle_id. For this extended DynamicMovieBox (1200), the following flags can be defined. -0x000001 source-info-present, if set, indicates the presence of source information; if not set, source_id, bundle_id, and source_flags take the value 0. -0x000002 in splice, if set, indicates that the tracks described in the DynamicMovieBox correspond to the content splice period and will immediately revert to the previous setting. By monitoring this flag and the source_id field, the processing media pipeline can be optimized as needed (e.g., avoiding unloading / reloading decoder resources). If source_id is 0, this flag is not set. Note that the encapsulation module can also use the flag in "styp" to signal this to simplify the editing of the concatenated files.

[0157] Note that the presence or absence of the bundle_id parameter 1205 can be controlled by the version of the DynamicMovieBox. For example, version 0 (without bundle_id) can be used when there is only one "moof" that describes all inserted tracks (dynamic tracks), and version 1 can be used when there are multiple tracks (dynamic tracks) to be inserted, and these tracks are described in at least two movie fragments ("moof" boxes).

[0158] This semantics may be updated as follows. source_id identifies the starting point of the fragment. The value 0 may indicate that the source is a MovieBox and the DynamicMovieBox modifies the MovieBox. Other values may identify a source other than a MovieBox, and all tracks, UserDataBox, MetaBox, and other properties defined in the MovieBox should be ignored. bundle_id provides an identifier for tracking partial configuration changes of a given source_id. Note that the bundle_id is typically required when two or more dynamic tracks are inserted into the first movie or during the splice period, each in its own movie fragment. This enables the file reader to detect that the modifications advertised for a given bundle have already been processed in a previous movie fragment. The source_flags identify the modifications declared in this DynamicMovieBox as compared to the previous DynamicMovieBox with the same values of source_id and bundle_id. This flag may be defined as follows. 0x000001, if set, indicates that one or more track configurations have been changed. 0x000002, if set, indicates that global (MovieBox-level) user data has been changed. 0x000004, if set, indicates that the global (MovieBox-level) metabox has been changed. 0x800000, if set, indicates that the modification is functionally equivalent to the previous DynamicMovieBox with the same source_id and bundle_id. If this flag is set, and the previously parsed DynamicMovieBox has the same source_id and bundle_id, the file reader may safely skip processing the DynamicMovieBox. Otherwise (this is the first DynamicMovieBox parsed with these source_id and bundle_id values), this flag may be set but will be ignored by the file reader (i.e., considered not set).

[0159] If source_flags is not set (either explicitly or according to the above rules) or the value is 0, the box should not be skipped. In this case, there is no information about the modification of child boxes compared to the previous DynamicMovieBox, and the entire content of the box must be re-evaluated.

[0160] If source_flags is not set to 0x000001, the DynamicTrackBoxes present in this DynamicMovieBox should set 0x800000 modification_flags.

[0161] Note that the source_id or bundle_id parameters can be encoded with fewer bits, e.g., 8 or 16 bits instead of 32 bits. However, using 32 bits aligns the source_id or bundle_id parameters with the number of bits for track_ID in the TrackHeaderBox, while using 8 bits may be sufficient and can reduce the description cost for dynamic tracks. The same applies to the source_flags parameter. Using 24 bits aligns the source_flags parameter with the flags in the TrackHeaderBox, while using 8 bits (or 16) may be sufficient to indicate what has changed within the track configuration and suggest the description cost for dynamic tracks.

[0162] Figure 13 shows an example of using the additional parameter bundle_id, which is explained by referring to Figure 12, to splice the audiovisual content 1320 included in a separate movie fragment of the presentation 1300.

[0163] For illustration purposes, presentation 1300 consists of one or more contiguous movie fragments (1301 or 1302) for one or more tracks (here only one track is represented by track_Id = 1). The spliced content 1320 is included in a separate movie fragment for the fragments from Ni to Ki, where "i" represents each media (e.g., as a track described by a sequence of movie fragments such as movie fragments 1310, 1311, 1312, or 1313). For clarity and brevity, the corresponding "mdat" boxes for these fragments are not shown. The movie fragments from N to K each have an attached DynamicMovieBox 1310-1, 1311-1, or 1312 and 1313 not shown, and set their flags to the value 3 indicating source_id_present and in-splice.

[0164] The values of the source_id of these DynamicMovieBoxes are set to values greater than 0 to indicate that the track configuration of the MovieBox has been replaced by that track configuration. Each DynamicMovieBox has a bundle_id value set to "i". Finally, the source_flags are set to 0x800000 (or 0x800001 as a hint to inform the reader that the track configuration has been changed). Then, each DynamicMovieBox contains a DynamicTrackBox (e.g., DynamicTrackBox1310-2 or 1311-2) having a track_ID shown in their DynamicTrackHeaderBox (not shown) and SampleDescriptionBox ("stsd", not shown). This track_ID can take any value (their new values or reused from the MovieBox and its sub-boxes) under the condition that each track in the spliced content has a different track identifier value. The modification_flags of these DynamicTrackHeaderBoxes are set to 0x800000. This change flag results in the player processing the file with the spliced content during the processing of the first occurrence of the dynamic movie or track box (e.g., fragments 1310 and 1311) and skipping the next ones (up to fragment K represented by references 1312 and 1313). Next, from fragment K+1, if this previous configuration is the same as the configuration of the MovieBox ("moov") corresponding to the switch back to the previous configuration, there is no need for a DynamicMovieBox.

[0165] Figure 14 illustrates another example where the additional parameter bundle_id, described with reference to Figure 12, is not used for splicing audio-visual content within a single movie fragment with a configuration change (for clarity, the data portion of the movie fragment is not shown).

[0166] For illustration purposes, the first presentation 1400 includes a series of movie fragments represented by references 1401 and 1402. At a given period, for example, at time N, new content referenced at 1420 is inserted into this first presentation. This new content is obtained as a series of movie fragments having T track fragments, where T is the number of tracks representing the new content 1420. In the example shown in FIG. 14, the number of tracks T is set to three, for example, one video track, one audio track, and one subtitle track, although it could be several tracks of the same media type, for example, two video tracks, or two audio tracks in different languages. Each track of the content to the splice 1420 is obtained as a sequence of movie fragments such as 1410, 1411 - 1414, and each fragment includes all the track fragments as detailed for movie fragment 1410, where the movie fragment box includes the DynamicMovieBox "dymv" 1410 - 1 itself that contains three DynamicTrackBox "dytk" referenced at 1410 - 21 to 1410 - 23, and three TrackFragmentBoxes (one "traf" per track, not shown). The subsequent movie fragments 1411 - 1414 also include a DynamicMovieBox "dymv" that itself contains three DynamicTrackBox "dytk" and three TrackFragmentBoxes. Below, to show the configuration changes over time, an explanation is given of how to use the parameters within the "dymv" and "dytk" boxes. Specifically, this example shows not only the start of splicing (time N), but also the changes within the spliced content, namely, the configuration change that occurs at C1 and the switch back to the previous configuration after C2. These variations can be represented as follows. For the fragments within N and C1, the corresponding movie fragment 1410, and possibly other subsequent movie fragments (not shown), include a DynamicMovieBox 1410-1 with the following parameter values: the flag is set to 3 (source-id-present and in-splice), the source_id is set to 1 (indicating that the configuration from the MovieBox does not apply to these movie fragments), the bundle_id is set to 0 if it exists (serving no role in this example), and the source flag may be set to 0x800000 or 0x800001 as a hint to the player that a change in track configuration has occurred. The setting value 0x000001 is optional because the first occurrence of the dynamic movie box 1410-1 will be processed, and since the values of source_id and bundle_id do not change between N and C1, the following will be skipped. The dynamic track boxes 1410-21 to 1410-23 have the following values as parameters. First, since the source_id is greater than 0 (invalidating, overwriting, or changing the "moov" configuration), the track_ID value can be any value, even if it is the track_ID value used in the MovieBox or its sub-box. Of course, each of these three tracks may have its own track_ID. This set of track_ID values may be referred to as splice_track_IDs. These values are set in each DynamicTrackHeaderBox (not shown) of each "dytk" box and are referenced in each TrackFragmentBox that describes the samples of each of the three tracks. Each DynamicTrackHeaderBox (not shown) has modification_flags set to 0x800000. Each DynamicTrackBox 1410-21 to 1410-23) includes a sample description box ("stsd") that provides detailed information about the encryption type used and the initialization information required for that encryption. This may be used to reset the decoder if necessary. For the fragment in C1 (movie fragment 1411), a sample configuration change occurs. Fragment C1 has a DynamicMovieBox 1411-1 with the same value as that in 1410-1 (i.e., flags = 3 (source-id-present and in-splice), source_id = 1, bundle_id = 0, source_flags = 0x800000 (or 0x800001 as a hint)). The sample setting change is shown in DynamicTrackBoxes (not shown), where the change occurs. For example, each dynamic track has an "stsd" box (to guarantee random access), and the change in "stsd" is shown in the corresponding DynamicTrackHeaderBox (not shown), and the modification_flags is set to 0x000002 (and 0x800000 for dynamic tracks without "stsd" change). This value 0x000002 causes the player to process the dynamic track box with this value even if the source_id value and bundle_id value are the same as those of the previous fragment (1410). This track identifier is splice_track_IDs. For the fragment(s) within [C1+1, C2], no change occurs. This is indicated by the encapsulation module within DynamicMovieBoxes 1412-1 and 1413-1 having the same value as DynamicMovieBox 1410-1 or 1411-1 (i.e., flags = 3 (source-id-present and in-splice), source_id = 1, bundle_id = 0, source_flags = 0x800000 (or 0x800001 as a hint)). Each DynamicTrackBox within DynamicMovieBox 1412-1 (not shown) contains the same "stsd" as fragment 1411 (to guarantee random access). This is shown in their corresponding DynamicTrackHeaderBoxes (not shown) having modification_flags set to 0x800002. This track identifier is splice_track_IDs. For the fragment in C2+1, the movie fragment 1413 contains one DynamicMovieBox1413-1 with flags = 3 (source-id-present and in-splice), source_id = 1, bundle_id = 0, and source_flags = 0x000001. This box contains three DynamicTrackBoxes (tracks with splice_track_Ids as identifiers), each having one "stsd". The modification_flags of the corresponding DynamicTrackHeaderBox are set to 0x000002 to indicate a configuration change (in a sample description that switches to a configuration like within [N, C1]). Each or subset of the dynamic tracks within the set of T tracks may have this configuration change. For tracks with no change, the modification_flags can be set to 0x800002 or 0x800000. This track identifier is splice_track_IDs. For the fragment in [C2+2, K] represented by one or more fragments 1414, each fragment 1414 contains one DynamicMovieBox1414-1 with flags = 3 (source-id-present and in-splice), source_id = 1, bundle_id = 0, and source_flags = 0x000001. This box contains three DynamicTrackBoxes (tracks with splice_track_Ids as identifiers), each having one "stsd". The corresponding DynamicTrackHeaderBox sets their modification_flags to 0x800002 to indicate that no change occurred between fragments such as fragment C2+1 and fragment C2+2 up to fragment K. Finally, from fragment K+1 (referenced at 1402), the presentation switches to the original configuration (the MovieBox for presentation 1400). Here, when the configuration to be applied is the same as the configuration declared in "moov" (in the case of example 1402 of presentation 1400), there is no need for a DynamicMovieBox. This track_ID is the one declared in the TrackHeaderBox within the "moov" box.

[0167] [Use of dependent or predicted fragments] The proposed DynamicMovieBox 1200 and its sub-boxes may be combined with movie fragments that depend on reference movie fragments. Assume that such dependent movie fragments are signaled, for example, by a particular version of the MovieFragmentHeaderBox as follows. aligned(8) class MovieFragmentHeaderBox extends FullBox('mfhd', version, 0){ nsigned int(32) sequence_number; }

[0168] If the version is not 0, the last movie fragment for which the MovieFragmentHeaderBox version is 0, or the SampleGroupDescriptionBox, DynamicMovieBox, UserDataBox, or MetaBox defined in the last TrackFragment within the last movie fragment, applies to this movie fragment, and there shall be no SampleGroupDescriptionBox, DynamicMovieBox, UserDataBox, or MetaBox defined for this movie fragment.

[0169] Note that instead of a version, a specific flag value may be defined instead to avoid any conflict with the version management of the MovieFragmentHeaderBox (e.g., for encoding the sequence_number in 64 bits). The above description will apply similarly.

[0170] [Example of hardware for performing the steps of the method of the embodiment of the present invention] FIG. 15 is a schematic block diagram of a computing device 1500 for implementing one or more embodiments of the present invention. The computing device 1500 may be a device such as a microcomputer, a workstation, or a light portable device. The computing device 1500 includes a communication bus 1502 connected thereto. That is, - a central processing unit (CPU) 1504 such as a microprocessor, and - a random access memory (RAM) 1508 for storing the executable code of the method of the embodiment of the present invention and variables and parameters necessary for implementing a method for encapsulating, indexing, decapsulating, and / or accessing data, and which can expand its memory capacity, for example, by an optional RAM connected to an expansion port, the random access memory 1504, and - a read only memory (ROM) 1506 for storing a computer program for implementing the embodiment of the present invention, and - A network interface 1512 that is typically sequentially connected to a communication network to which digital data to be processed is transmitted or received. The network interface 1512 may be a single network interface or may be composed of a set of different network interfaces (e.g., wired and wireless interfaces, or different types of wired or wireless interfaces). Data is written to the network interface for transmission or read from the network interface for reception under the control of a software application executed in the CPU 1504: - A user interface (UI) 1516 for receiving input from a user or displaying information to a user. - A hard disk (HD) 1510. And / or - An I / O module 1518 used for receiving / sending data from / to an external device such as a video source or a display.

[0171] The executable code may be stored in any of the read-only memory 1506, the hard disk 1510, or a removable digital medium such as a disk, for example. According to a variant, the executable code of the program can be received by a communication network via the network interface 1512 so as to be stored in one of the storage means of the communication device 1500 such as the hard disk 1510 before being executed.

[0172] The central processing unit 1504 is adapted to control and direct the execution of program instructions or a part of the software code according to an embodiment of the present invention, and the instructions are stored in one of the aforementioned storage means. After power-on, the CPU 1504 can execute instructions from the main RAM memory 1508 regarding the software application after those instructions are read from the program ROM 1506 or the hard disk 1510. When such a software application is executed by the CPU 1504, it causes the steps of the flowchart shown in the previous figure to be executed.

[0173] In this embodiment, the device is a programmable device that uses software to implement the present invention. However, the present invention may also be implemented in hardware (e.g., forming an application-specific integrated circuit or ASIC).

[0174] As described above, the present invention has been described based on specific embodiments, but the present invention is not limited to the above embodiments, and various modifications are possible without departing from the gist of the present invention.

[0175] Furthermore, referring to the above-described exemplary embodiments, many further modifications and changes have been proposed to those skilled in the art, which are merely given as examples and are not intended to limit the scope of the present invention determined solely by the appended claims. In particular, different features from various embodiments may be appropriately exchanged at appropriate locations.

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

Claims

Claim 1 A method for encapsulating media data of a plurality of presentations into at least one media file based on ISO BMFF, the method comprising: obtaining a first portion of the media data of a first presentation, said first presentation being composed of a first set of tracks; encapsulating first metadata describing the tracks of the first set of tracks and encapsulating the first portion of the media data of the first presentation into one or more first media fragments; obtaining a second portion of the media data of a second presentation, said second presentation being composed of a second set of tracks; encapsulating second metadata describing the tracks of the second set of tracks into one or more second media fragments following the one or more first media fragments and encapsulating the second portion of the media data of the second presentation into the one or more second media fragments; wherein the second metadata includes an indication signaling that the second set of tracks does not include at least one track as described in the encapsulated first metadata. Claim 2 The method according to claim 1, wherein the second metadata includes an indication for signaling that at least one parameter value of the description of at least one track belonging to the first set of tracks and the second set of tracks is different in the first metadata and the second metadata. Claim 3 The method according to claim 1 or 2, wherein the second set of tracks does not include at least one track described in the first metadata. Claim 4 The method according to any one of claims 1 to 3, wherein the second set of tracks includes at least one track not described in the first metadata. Claim 5 The at least one media file comprises a metadata portion for encapsulating metadata common to all media data encapsulated in the at least one media file, and the first metadata is encapsulated in the metadata portion, the method according to any one of claims 1 to 4.

6. At least one of the one or more first media fragments comprises a metadata portion for encapsulating metadata common to all media data encapsulated in the at least one of the one or more first media fragments, and the first metadata is encapsulated in the metadata portion of the at least one of the one or more first media fragments, the method according to any one of claims 1 to 4.

7. The instruction for signaling that the second set of tracks does not include at least one track as described in the encapsulated first metadata includes an indicator indicating that the second set of tracks is a new set of tracks, the method according to any one of claims 1 to 6.

8. The instruction for signaling that the second set of tracks does not include at least one track as described in the encapsulated first metadata includes an indicator indicating that the second set of tracks has already been described and that at least one parameter of the description of the second set of tracks has changed, the method according to any one of claims 1 to 6.

9. The second metadata further includes an instruction for signaling that the one or more second media fragments can be parsed independently of the first fragment, the method according to any one of claims 1 to 8.

10. The fragment is a segment or fragment of a common media application format (CMAF) or a segment or fragment of an ISO base media file format (ISOBMFF), the method according to any one of claims 1 to 9.

11. A method for analyzing media data of a plurality of presentations, wherein the media data is encapsulated based on ISO BMFF as a plurality of fragments of one or more media files, and the method is executed by a client, obtaining first metadata describing a first set of tracks of a first presentation including one or more first media fragments; obtaining at least one second media fragment including encapsulated second metadata and encapsulated media data, wherein the second metadata describes a second set of tracks of a second presentation, and the encapsulated media data is the media data of the second presentation, and at least one of the at least one second media fragment following the first media fragment includes the media data of the first presentation; analyzing at least a part of the second metadata; when it is determined that the second metadata includes an instruction to signal that at least one track as described in the encapsulated first metadata is not included in the second set of tracks, updating the track description to analyze the encapsulated media data; A method comprising: **Claim 12** The method according to claim 11, wherein updating the track description includes analyzing at least another part of the second metadata, and updating the track description is based on the metadata of the at least another part of the second metadata. **Claim 13** The method according to claim 12, wherein the at least another part of the second metadata includes a description of at least one track not described in the first metadata. **Claim 14** The method according to claim 12, wherein the at least another part of the second metadata includes a new value of at least one parameter of a description of at least one track described in the first metadata. **Claim 15** The method according to any one of claims 11 to 14, wherein the one or more media files comprise a metadata portion for encapsulating metadata common to all media data encapsulated in the one or more media files, and the first metadata is encapsulated in the metadata portion.

16. The method according to any one of claims 11 to 14, wherein the first metadata is obtained from a media fragment.

17. Obtaining at least one third media fragment comprising encapsulated third metadata and encapsulated media data, wherein the third metadata describes a third set of tracks of a presentation comprising the media data encapsulated in the at least one third media fragment comprising the third metadata; Analyzing at least a portion of the third metadata; When it is determined that the third metadata includes an instruction signaling that the description of the third set of tracks is similar to the description of a previously determined set of tracks, skipping the analysis of another portion of the third metadata and using the current description of the set of tracks to analyze the media data of the at least one third media fragment comprising the encapsulated third metadata; The method according to any one of claims 11 to 16, further comprising.

18. A computer program product for a programmable device, comprising instructions for performing each step of the method according to any one of claims 1 to 17 when the program is read and executed by the programmable device.

19. A computer-readable storage medium storing computer program instructions for implementing the method according to any one of claims 1 to 17.

20. A processing device comprising a processing unit configured to perform each step of the method according to any one of claims 1 to 17.

Images