Methods, devices, and computer programs for optimizing the 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-based media file format (ISOBMFF, also known as the file format) is a common format that forms the basis for many other more specific file formats. ISOBMFF is standardized by the International Organization for Standardization as ISO / IEC 14496-12. This format includes characteristics of media data such as timing, size, or media information for timed sequences of media data, such as audiovisual presentations. These characteristics are generally called metadata (or structural data) for media data (or data). An ISO-based media file (also called a media file, movie file, or media presentation) can be a single file containing the entire presentation or multiple segment files, each segment containing a time portion of the presentation. ISO-based media files are structured into "boxes," each identified by a four-letter 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, each representing a timed sequence of media (for example, a timed sequence of videopictures, where a picture is either a frame or a field for interlaced video). Within each track, each time unit is called a sample. Each track has one or more sample descriptions. Each sample within a track is linked to a description by reference. All structural data or metadata that defines the placement and timing of media is contained in a structured box. Media data (e.g., video frames or audio samples) is referenced by this structural data or metadata. 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 structural data. Each sample has a defined duration.The exact decoded timestamp of a sample is defined by summing the durations of the preceding samples.

[0003] Figure 1 shows an example of encapsulated media data that is temporally organized as a fragmented presentation in one or more media files, according to the ISO-based 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 identifying the exact specifications to which the encapsulated media data conforms, which is used by the reader to determine whether the encapsulated media data can be processed. Following the "ftyp" box is a MovieBox("moov") box referenced in 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 about the timelines and characteristics of each of them. For illustrative purposes, the MovieBox box may indicate that the presentation has one track with an identifier track_ID equal to 1.

[0005] A 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 its tracks (tracks are described by the "track" box 135). This minimal or empty movie is further supplemented with additional samples, which are described primarily by a hierarchy of boxes consisting of pairs of "moof" boxes (e.g., "moof" boxes 110 or 120) and "mdat" boxes (e.g., "mdat" boxes 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 the MovieFragmentBox ("moof") box (and its subboxes) and media data stored in the MediaDataBox ("mdat") box (or identified media data box "imda"). The presence or absence of movie fragments in a media file is indicated early in the file by the MovieExtendsBox ("mvex") box 130. If movie fragments exist within the media file, the information in this box warns the reader that further 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 this, the information in this box must be combined with other information in the MovieBox box. The MovieExtendsBox box 130 may contain an optional MovieExtendsHeaderBox ("mehd") box and one TrackExtendsBox ("trex") box for each track defined in the MovieBox "moov" box 105. If a MovieExtendsHeaderBox box is present, the overall duration of the fragmented movie is displayed.Each TrackExtendsBox box defines default parameter values ​​for describing a track fragment sample (type, size, duration, control flags, etc.).

[0006] For illustrative purposes, media file 100 contains a first movie fragment 100-1 that describes samples 1 through N of a track identified by a track_ID equal to 1 (as shown in the "tfhd" box). This first movie fragment 100-1 consists of a "moof" box 110 and a "mdat" box 115. For further illustrative purposes, media file 100 contains a second movie fragment 100-2 that describes samples N+1 through 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 consists of a "moof" box (referenced in 120) and a "mdat" box (referenced in 125).

[0007] Encapsulated media data may be fragmented into a single media file or into multiple media segment files (referred to as segment files). When encapsulated into multiple segment files, the FileTypeBox and MovieBox boxes (hereinafter also referred to as initialization fragments) are contained within an initial segment file (also referred to as an initialization segment) in which one or more tracks do not contain any samples. Subsequent segment files contain 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] Because this encapsulation mode requires less buffer capacity for the encapsulation module, the use of movie fragments is particularly relevant to live encoding and live packaging (or encapsulation). This is also relevant to low-latency streaming, such as adaptive streaming over HTTP, like DASH or HLS (HTTP Live Streaming), as the encoded media can be made available as soon as the movie fragment is encoded and encapsulated.

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

[0010] For illustrative 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, while 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, a sample entry "gpe1" or "gpeg" indicates volumetric media data encoded in G-PCC (ISO / IEC 23090-9). A SampleEntry box may also contain other boxes containing information applicable to all samples associated with this SampleEntry box. The sample is associated with the SampleEntry box via the sample_description_index parameter in either the SampleToChunkBox("stsc") box within the SampleTableBox("stbl") box if the media file is not fragmented, or in either the TrackFragmentHeaderBox("tfhd") box within the TrackFragmentBox("traf") box of the MovieFragmentBox("moof"), or the TrackExtendsBox("trex") box within the MovieExtendsBox("mvex") box if the media file is fragmented. According to the ISO-based media file format, all tracks and all sample entries in a presentation are defined within a "moov" box, such as the "moov" box, and cannot be declared later during the presentation.

[0011] In a movie fragment, this sample is primarily described within a TrackFragmentHeaderBox ("tfhd") box, which may provide a default sample entry (the type of codec used and code configuration information), a default sample size, and / or a default sample duration. The actual sample size, duration, offset in the media data portion, or flags (if these values ​​differ from the default values, or if no default values ​​are defined) may be shown in a TrackRunBox ("trun") box for sample description. The TrackRunBox ("trun") box documents a sequence of samples (runs) for the track within the movie fragment.

[0012] For example, with respect to sample timing, a track fragment may include a TrackFragmentBaseMediaDecodeTimeBox ("tfdt") box that provides an absolute decode timestamp (using the baseMediaDecodeTime parameter) of the first sample in the decoding order within the track fragment, measured on the decoding timeline. For random access or synchronization, a track fragment may have a decoding time indication within the "tfdt" box. If this box is present, a 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 within each "traf" box in a media segment within a live profile for ISOBMFF. A "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 restrict media files or segment files to contain one "traf" box per "moof" box.

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

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

[0015] CMAF is codec-independent and defines several profiles for audio, video, subtitles, etc., depending on the codec and application type being used. For example, CMAF provides guidelines for setting 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 will be, and presumably the latency will be higher, but the compression may be more efficient (avoiding encoding intra-encrypted frames such as IDR and CRA frames in MPEG video codecs, i.e., frames that do not have encryption dependency on preceding encoded frames).

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

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

[0018] As shown in Figure 2b, a CMAF fragment may contain several CMAF chunks. In the illustrated example, CMAF fragment 205' contains three CMAF chunks referenced from 250-1 to 250-3. Furthermore, in this example, each CMAF chunk has a consecutive set of samples and covers a given period which may differ from chunk to chunk. As illustrated, each CMAF chunk is actually constructed like a movie fragment and contains a "moof" box and an "mdat" box. For example, CMAF chunk 250-1 has 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 begin at an adaptive switching point. This reduces streaming latency because, instead of waiting for the entire CMAF segment (like 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 no longer have to wait for the entire segment to be ready, but should only have to wait for a CMAF chunk to become available for requesting.

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

[0021] While the ISOBMFF file format has proven efficient, there is a growing need for flexibility in the file format (e.g., ISOBMFF or CMAF) to cope with the proliferation of live adaptive streaming or on-demand video streaming services. In fact, content data is no longer viewed as a single piece of data with a pre-known complete structure, but rather as dynamic content data into which content can be injected or spliced, for example, to add advertisements during the playout of a movie or sporting event. Similarly, additional media data may be overlaid on 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, despite fragmentation, all tracks and all sample descriptions must be known and declared in advance in ISOBMFF and its derived specifications. [Overview of the project]

[0022] This invention was devised to address one or more of the aforementioned problems.

[0023] According to a first aspect of the present invention, a method is provided for encapsulating media data of multiple presentations into at least one media file based on ISOBMFF, the method being: This involves obtaining a portion of the media data of the first presentation, which is referred to as the first part, and the first presentation consists of a first set of tracks. Encapsulating first metadata describing the tracks of a first set of tracks, and encapsulating a first portion of the media data of a first presentation into one or more first media fragments, This involves obtaining a portion of the media data for the second presentation, which is referred to as the second part, and the second presentation consists of a second set of tracks. 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 part of the media data of the second presentation into one or more second media fragments, 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 dynamics and / or flexibility for encapsulation and parsing while maintaining the main features of file formats 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 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 the 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 the first metadata is encapsulated in the metadata portion of the at least one or more first media fragments.

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

[0031] According to some embodiments, an instruction signaling that at least one track as described in the first metadata encapsulated by a second set of tracks is not included comprises 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 comprises an instruction for signaling that one or more second media fragments can be analyzed 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 multiple presentations, wherein the media data is encapsulated based on ISOBMFF as multiple fragments of one or more media files, and this method is performed by a client. Obtaining the first metadata that describes the first set of tracks for the first presentation, Retrieving a media fragment containing encapsulated second metadata and encapsulated media data, wherein the second metadata describes a second set of tracks for a second presentation, the encapsulated media data is media data for the second presentation, and at least one media fragment following the media fragment contains media data for a first presentation. Analyzing at least a portion of the second metadata, If it is determined that the second set of tracks contains an instruction that signals that the second set of tracks does not contain at least one track as described in the first encapsulated metadata, then the track description is updated to parse the encapsulated media data, A method is provided that includes this.

[0035] Therefore, the method of the present invention provides dynamism and / or flexibility for encapsulation and analysis while maintaining key features of the file format, such as fragmentation and random access. This flexibility includes adding or deleting tracks, invalidating initially declared tracks, overwriting tracks, replacing tracks, and inserting tracks. Displaying changes in the track configuration preserves random access and means that any player tuned to media presentation can obtain the current track configuration without additional requests, minimizing startup delays.

[0036] According to some embodiments, updating a track description involves parsing at least another portion of a second metadata, and updating a track description is based on metadata from 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 for 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 one or more media files, wherein 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, this method is Obtaining at least one media fragment containing encapsulated third metadata and encapsulated media data, wherein the third metadata describes a third set of tracks of a presentation containing media data encapsulated in at least one media fragment containing the third metadata, Analyzing at least a portion of the third metadata, If it is determined that the third metadata contains an instruction that signals that the description of the third set of tracks is similar to the description of the previously determined set of tracks, then the analysis of other parts of the third metadata is skipped, and the current description of the set of tracks is used to analyze the media data of at least one media fragment containing the encapsulated third metadata. It also includes.

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

[0043] At least a portion of the methods according to the present invention can be implemented on a computer. Therefore, the present invention can take the form of a hardware embodiment overall, a software embodiment overall (including firmware, resident software, microcode, etc.), or a combination of software and hardware aspects, all of which in this specification are generally referred to as “circuits,” “modules,” or “systems.” Furthermore, the present invention can take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in that medium.

[0044] Since the present invention can be implemented in software, it can be implemented as computer-readable code for provision to a programmable device on any suitable carrier medium. The tangible carrier medium may include storage media such as floppy disks, CD-ROMs, hard disk drives, magnetic tape devices, or solid-state memory devices. The transient carrier medium may include signals such as electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals, or electromagnetic signals, such as microwave or RE signals. [Brief explanation of the drawing]

[0045] Herein, embodiments of the present invention will be described with reference to the following drawings, merely as examples.

[0046] [Figure 1] This shows an example of encapsulated media data, temporally organized as a fragmented presentation in one or more media files, according to the ISO-based media file format.

[0047] [Figure 2] This shows the relationship between addressable CMAF segments from a streaming manifest and ISOBMFF movie fragments.

[0048] [Figure 3a] , [Figure 3b] , and [Figure 3c] The following outlines some embodiments of the present invention outline methods for encapsulating or storing multimedia presentations.

[0049] [Figure 4] An example of the encapsulation process according to several embodiments of the present invention is shown.

[0050] [Figure 5] An example of the analysis process steps according to several embodiments of the present invention is shown.

[0051] [Figure 6a] and [Figure 6b] This is an example of box-based information to show the dynamic track configuration within a media file.

[0052] [Figure 7] This shows an example of a track configuration that disables tracks declared in the "moov" box.

[0053] [Figure 8] and [Figure 9] This is another example of the use of some embodiments of the present invention.

[0054] [Figure 10] Here's another example of a track configuration change where the track initially declared in the "moov" box is overwritten.

[0055] [Figure 11a] , [Figure 11b] , and [Figure 11c] Here is an example of changing the track configuration.

[0056] [Figure 12] This shows an example of the updated syntax for DynamicMovieBox.

[0057] [Figure 13] An example is shown using the additional parameter `bundle_id`, which is explained by referring to Figure 12, for splicing with configuration changes contained within separate movie fragments of a presentation.

[0058] [Figure 14] The additional parameter bundle_id, as explained with reference to Figure 12, illustrates another example where it is not used to splice audiovisual content in a single movie fragment, with configuration changes.

[0059] [Figure 15] A processing device configured to implement at least one embodiment of the present invention is schematically illustrated. [Modes for carrying out the invention]

[0060] According to some embodiments of the present invention, the contents of several “moof” boxes of fragmented ISOBMFF media data are optimized to provide dynamism and / or flexibility to encapsulate and analyze while maintaining key 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 throughout the media presentation. Furthermore, this track configuration is repeated to ensure random access for the reader, and this repetition is carried out in a manner that avoids unnecessary processing for the reader to play the file continuously. 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 functionality interoperable between writers and parsers that support this functionality.

[0062] [General encapsulation and analysis processes] Figure 3a outlines a first method for encapsulating or storing a multimedia presentation according to several embodiments of the present invention. The media data 305 to be encapsulated or stored may be video, spatial subparts of 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 manner that enables adaptive streaming over HTTP, possibly with low latency. As shown, the server 300 comprises an encapsulation module 320 (also called an ISOBMFF writer or simply a writer) and optionally a streaming manifest generation module (not shown). The server 300 may be connected via a network interface (not shown) to a communication network 330 to which a client 350 is also connected. Examples of clients are media players on PCs, tablets, TVs, or smartphones.

[0063] Server 300 processes media data 305 and prepares it for streaming or storage, a process called encapsulation. This primarily involves adding metadata that describes the media data regarding the type of data, the codec in use, the size, data offset, timing, etc. As described above, media data 305 can correspond to an audio presentation, a video presentation, or both, and may include subtitles or timed text. Media data 305 may be raw data captured by a sensor or generated by a content creator or editing tool. Media data 305 may be available as compressed or encoded media data 315, depending on the encoding version. This means that encoding or compression may be performed by the server itself, remotely from the server, or using an encoder module such as encoder module 310 (possibly one for each type of media). Compression may be live encoding (and encapsulation).

[0064] Media data 305 may also be encapsulated media data, which is encapsulated in a manner unsuitable for low-latency streaming, for example, as an unfragmented track. In the latter case, the encapsulation module (e.g., encapsulation module 320) also includes a read unit for decapsulating the media data and then encapsulating the decapsulated media data, according to some embodiments of the present invention.

[0065] As illustrated in the example, the encapsulation module 320 of server 300 is used to encapsulate media data into movie fragments, for example, according to ISOBMFF and its extensions (e.g., CMAF, NAL unit-based file format, etc.). Server 300 then generates a referenced media file 325 or one or more segment files 325. Server 300 may optionally generate a streaming manifest, such as a DASH MPD or HLS playlist (not shown). The generated files, segment files, or manifest may be stored in a remote storage device, for example, in a remote storage device accessible via 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 over HTTP.

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

[0068] The 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 output to an application or user. The decoder modules (possibly one or more per media type) may be part of the client, external modules, or dedicated hardware.

[0069] The deencapsulated data may correspond to encoded media data 365 (e.g., video bitstream, audio bitstream, etc.). Deencapsulation, decoding, and rendering may be live operations that process the media file as soon as it is received, for example by processing data chunks of each media stream in parallel and synchronously, in order to minimize latency between the recorded multimedia presentation (as media data 305) and its visualization by the user as media data 375 on the user's device screen, for example.

[0070] A client or server may be a user device, or it may be a network node that acts on a media file being transmitted or stored. A server or client may consist only of the encapsulated and deencapsulated portions, respectively.

[0071] It should be noted 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 having a media description (e.g., DASH MPD) and, upon receiving a request from the client 350, communicate (or stream) it directly to the client 350. The media file 325 may also be downloaded and stored by the client 350, either all at once or incrementally.

[0072] For illustrative purposes, media file 325 may encapsulate media data in boxes according to the ISO-based media file format (ISOBMFF, ISO / IEC 14496-12) and its derivative specifications (e.g., ISOBMFF, ISO / IEC 14496-15, or Common Media Application Format, CMAF, NAL unit structured video carriage in ISO / IEC 23001-19). In such cases, 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, media file 325 may contain 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 defining the placement and timing of the media data. A media file or segment file contains movie fragments. A media data box contains all the data of media data 305 or encoded media data 315. There may be one media data box that duplicates media data, but there may also be one or more media data boxes, for example, one for each media type, and possibly one or more for each movie fragment.

[0073] This system configuration may include variations on the encapsulation side, particularly as shown in Figure 3b or Figure 3c.

[0074] Figure 3b outlines a second method for encapsulating or storing a multimedia presentation according to several embodiments of the present invention.

[0075] For illustrative purposes, media file 305-1 is the same as media file 305 in Figure 3a, and the optional encoder module 310 and encoded media file 315 are the same as the optional encoder module 310 and encoded media file 315 described with reference to Figure 3a.

[0076] As illustrated, compared to the encapsulation module 320 shown in Figure 3a, the encapsulation module 320' may encapsulate media data from several sources within the media file 325', such as media data 305-1 and media data 305-2, for example 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 to be inserted in the middle of a movie which is media data 305-1.

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

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

[0079] As shown in the example in Figure 3c, a first writer is used to encapsulate a first media file; for example, writer 300-1 is used to encapsulate media file 305-1, which may be a movie. A second writer is used to encapsulate a second media file; for example, writer 300-2 is used to encapsulate media file 305-2, which may be an advertisement. The encapsulated media files may be combined within media file 325''. Writers 300-1 and 300-2 may be separate entities that operate independently of each other and, in some cases, are unaware of each other's actions. Note that writer 300-2 may include an encoder module (not shown). For illustrative purposes, media file 325'' may consist of a concatenation of a media file generated by writer 300-1 on the one hand and a media file generated by writer 300-2 on the other.

[0080] Encapsulation module 320-1 within writer 300-1 may be responsible for encapsulating the main presentation, and a second encapsulation module 320-2 within writer 300-2 may be responsible for encapsulating additional content, substitutions, splicing, or alternative content. In such cases, the actions performed by the second writer may be called "blind" splicing or "late splicing."

[0081] According to some embodiments, two writers can share knowledge of common setup information, such as information written to a “moov” box, like an initial track or sample configuration, as suggested in reference number 380. This allows for the implementation of use cases more advanced than blind splicing. For example, it may be possible to disable some tracks, overload some tracks, and keep some tracks active. Such configurations may be referred to as “non-blind splicing” or “early splicing.”

[0082] [Encapsulation of media files according to several embodiments of the present invention] Figure 4 shows an example of an encapsulation process according to several embodiments of the present invention. For illustrative purposes, such a process may be performed in the encapsulation module 320 of Figure 3a, in the encapsulation module 320' of Figure 3b, or in the encapsulation module 320-1 or 320-2 of Figure 3c.

[0083] As illustrated, the first step is directed to initializing the writer (step 400), for example, writer 300 in Figure 3a, writer 300' in Figure 3b, or writer 300-1 and / or 300-2 in Figure 3c. The configuration may involve the encapsulation module 320 in Figure 3a, encapsulation module 320' in Figure 3b, or encapsulation module 320-1 or 320-2 in Figure 3c, and the encoder module 310, or the encapsulation module(s) only if the encoder settings cannot be controlled, for example, if this configuration is hardcoded. For illustrative purposes, this configuration step may also include indicating whether the media file to be generated consists of a single file or multiple segment files. This configuration may include defining the granularity of random access in the presentation (e.g., every second, every two 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 files to be generated are entirely dynamic.

[0084] Fully dynamic media files differ from known ISO-based media files in that they do not necessarily contain the same box hierarchy as defined in ISO / IEC 14496-12. For example, a sequence of objects in a presentation within a fully dynamic media file does not necessarily contain exactly one movie box, as it would in a conventional ISO-based media file. Typically, ISO-based media files contain a top-level "moov" box containing one or more "trak" boxes, each declaring a track (media type, header information) and a sample configuration (e.g., a "stsd" box within a "stbl" box). Fully dynamic ISOBMFFs do not necessarily contain a "moov" box. These types of media files that provide dynamic movie fragments or dynamic tracks may be indicated using the ExtendedTypeBox brand "dytk" or the FileTypeBox ("ftyp") or SegmentTypeBox ("styp") brand "isod" or higher. The "moov" movie box is not mandatory in fully dynamic media files, 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 (for example, using the proposed brand or any brand value defined above to indicate support for dynamic tracks). The FileTypeBox can also be optional and can be replaced with a mandatory SegmentTypeBox instead. Alternatively, a fully dynamic media file may still contain a movie box, but it may not contain track declarations and instead contain only movie header information, for example.

[0085] If the media file to be generated is not a fully dynamic media file (test 401 is false), the writer generates initialization data containing an "ftyp" box and a "moov" box at the top of the file according to ISOBMFF (step 402). The created "moov" box contains a "trak" box, each declaring information about a track known at the time of media file creation. With respect to fully dynamic media files, the media file here may contain a specific brand indicating that it may support or contain dynamic tracks (i.e., tracks that may be declared later within the file and do not necessarily have to be in the "trak" box below the top-level "moov" box). This initialization data may be used, for example, as an initialization segment for adaptive streaming use. Next, after initialization, the writer begins encapsulating the data for media presentation. For illustrative purposes, it is assumed that this encapsulation aims to encapsulate first media data (e.g., a movie) and second media data (e.g., advertisements or temporary information to be rendered on or along with 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 time. Therefore, the "moov" box may have track declarations for the first media data and track declarations for the second media.

[0086] As illustrated, 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 if the second media data should not be encapsulated (step 404), and a step of encapsulating the obtained first media data (step 407). This encapsulation may include describing a sample and indexing the corresponding data stored in a media data box (e.g., "mdat" or "imda"). For example, a sample description of the first media data (e.g., size, data offset, duration, and / or configuration time) may be provided in a "trun" box. The encapsulated media data is output as part of the 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, it is obtained, and the writer generates a new track configuration (step 406). The display of the track configuration is described below with reference to Figures 6a and 6b. As shown, the first media data may be acquired in parallel with the acquisition of the second media data (step 405). After displaying the track configuration, the writer encapsulates the first, second, or both media data (step 407) and outputs the encapsulated media data as part of a media file (step 408). This output may be based on ISOBMFF fragments, CMAF fragments, CMAF segments, or ISOBMFF segments.

[0087] If the media file to be generated is a fully dynamic media file (test 401 is false), the encapsulation module generates only the minimum set of initialization information items, e.g., only the "ftyp" or "styp" boxes, or generates either "ftyp" or "styp" along with a minimum "moov" box (e.g., without a track declaration) (step 420). Next, the writer retrieves the media data to be encapsulated, i.e., the first and / or second media data (step 421), and generates track configuration information for the retrieved media data (step 422). This step of indicating the track configuration is described below with reference to Figures 6a and 6b. Next, the obtained media data is encapsulated (step 423), which involves 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), the algorithm loops back to step 421. As described with reference to step 409, this output may be based on ISOBMFF fragments, CMAF fragments, CMAF segments, or ISOBMFF segments.

[0088] [Analysis of encapsulated media files according to several embodiments of the present invention] Figure 5 shows an example of the steps of the analysis process according to several embodiments of the present invention. Note that the client or reader that performs such steps may also be called a “parser,” “application,” “media player,” or “player.”

[0089] As illustrated, this process begins with parser initialization (step 500) based on a media file or media segment file received from a server or optionally accessed locally using a manifest file, which is generated according to some embodiments of the present invention, for example, according to the steps shown in Figure 4. More precisely, the player is initialized using 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 from 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 fully dynamic or not, the codec being used, and so on.

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

[0091] If the media file is not entirely dynamic, the parser reads initialization data (step 502) and instantiates an appropriate decoder to process the media data required in subsequent steps. By reading this initialization data, the parser can determine that changes to the track configuration or modifications to the presentation may occur (e.g., instructions in the brand, with a "dytk" value having a "moov" box that provides a complete track description). The parser then retrieves the encapsulated media data, for example, by reading or downloading the data, or by using a streaming or incremental transmission mechanism (step 503). Note that the data may be retrieved at different granularities, for example, as movie fragments, ISOBMFF segments, CMAF fragments, or CMAF segments. The parser then checks whether a new track configuration is part of the retrieved data (step 504). If no track configuration exists, the parser or reader decapsulates (or parses) samples from each track (step 506) and provides the resulting data to an appropriate buffer, decoder, or renderer (step 507).

[0092] If the obtained data contains new track configurations (as determined in step 504), the parser decodes and interprets the new track configurations to determine the current number of tracks and their configurations. Examples of track configurations are described below with reference to Figures 6a and 6b. There may be new tracks or tracks defined within the "moov" box. Depending on these tracks, and 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 may further examine the track descriptions to obtain, for example, 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, or it may infer from the track configuration that some previous configurations can be reused without resetting. 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, the algorithm loops in step 503).

[0093] If the parser determines that the media file is entirely dynamic (step 501), it may not be able to immediately set up the decoder. This is because it may acquire more data, for example, by reading, downloading, or using a streaming mechanism (step 520). In this case as well, this data may be acquired at different granularities, for example, as movie fragments, ISOBMFF segments, CMAF fragments, or CMAF segments. For entirely dynamic tracks, the parser processes the track configuration as described below with reference to Figures 6a and 6b (step 521). From this track configuration, the parser can determine the current number of tracks and their characteristics (step 522). Note that when the track configuration is filled for the first time, it may lead to several decoder initializations. When it has already been filled by the parser, the track configuration may consist of reusing a decoder configuration that has already been 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, depending on the application using the media file (step 524). As illustrated, this process is repeated until the end of the presentation is reached (i.e., if the end of the presentation is not reached, the algorithm loops in step 520).

[0094] [Dynamic Track Instructions] Figures 6a and 6b show examples of box-based information for indicating dynamic track configurations within a media file. This is directed toward two embodiments. The first embodiment aims to define a metadata structure that fits into ISOBMFF boxes to indicate a change in track configuration (step 406) or to indicate a new track configuration (step 422). This signal should also be randomly accessible so that the current track configuration can be obtained whenever a player or reader begins parsing (or tuning) the media presentation. This means that the track configuration instruction should be repeatable. The second embodiment aims to provide an instruction on whether the track configuration changes or not (i.e., whether it simply repeats or not). The second embodiment may also provide an instruction on the range of track configuration changes, such as "minor" changes, also called functionally equivalent or "significant" changes, which may require a parser or reader to handle the reset or update decoder configuration.

[0095] To handle this change, the option could have relied on the box version. While the same version number indicates repetition, this conflicts with box versioning, and some boxes don't even have a version field like UserDataBox. Furthermore, it indicates changes in binary syntax rather than the intended purpose of box versioning, and does not indicate changes in payload. One approach to address this second aspect could be to perform a comparison of past and present boxes, typically via a hash function. While this allows for the detection of identical configurations, it has several drawbacks, such as being costly in terms of client resources (additional processing and memory requirements) and not allowing signaling of recurring configurations with slight variations (e.g., in metadata) that do not require data reparation. Therefore, a change detection mechanism needs to be introduced to indicate track configuration changes (e.g., dynamic track or sample description changes) within movie fragments so that the parser or reader can properly identify information that is repeated across fragments.

[0096] Finally, while samples may be signaled as iterative samples using dependency flags, ISOBMFF lacks support for such signaling for non-sample data (metadata or box structures). Mechanisms exist that allow configuration information to be sent for media presentations. For example, the DSM-CC (ISO / IEC 13818-6) standard specifies data carousels and object carousels. Object carousels extend the more limited data carousels and specify a standard format for representing a file system directory structure including a root directory or service gateway and one or more files and directories, a feature not available in ISOBMFF. According to the illustrated embodiment, a DynamicMovieBox referenced at 600, which may be contained within a movie fragment (not shown, "moof"), contains DynamicTrackBoxes referenced at 0 or more 601, each containing a specific DynamicTrackHeaderBox referenced at 602 and several common boxes found within the TrackBox (e.g., "stsd", "trgr", "tref", etc.).

[0097] [Dynamic Movie Box] A DynamicMovieBox600 may contain zero or more UserDataBox620s or MetaBox630s, as defined in ISOBMFF. This is identified, for example, by the 4CC code "dymv", or by any dedicated 4CC reserved for this use and not conflicting with existing 4CCs.

[0098] A DynamicMovieBox completely or partially overrides the MovieBox setup (track list, user data, or metadata) of a particular fragment. This MovieBox setting is sometimes called the “track setting.” This mode (partial or complete override of the track configuration, or extension of the track configuration) may be indicated by a parameter of the DynamicMovieBox box (e.g., a flag or field within the Box or FullBox). This parameter may be called, for example, “source_id” or “carousel_id.” For example, this parameter may be a presentation identifier and / or may be repeated along the presentation or part (time interval) of the sequence. Each DynamicMovieBox may have an associated source_id that indicates how the movie fragment extends or modifies the initial 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 other than 0 may indicate that the movie box is ignored (i.e., it does not exist for a given movie fragment or is considered inactive).

[0099] For example, this parameter of the DynamicMovieBox box may be set by the encapsulation module to indicate the presence of a field that allows the player to be informed whether the track configuration is repetitive, complementary, overloaded, or whether to invalidate any track configurations that may exist in the “moov” box or the previous movie fragment. This box may exist in a movie fragment, or only in the first movie fragment of an ISOBMFF segment (e.g., a segment containing dependent movie fragments). Thus, there may be zero or more DynamicMovieBoxes in a 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 dependent movie fragments, this dependent movie fragment may inherit track declarations (DynamicMovieBox, DynamicTrackBox, DynamicTrackHeaderBox) from this first movie fragment, in addition to other properties of this first movie fragment.

[0100] For DynamicMovieBox, the following flags may be defined: -0x000001 is written as source-info-present, and if set to this value, it indicates that source information (or carousel-like information or carousel information) exists. If not set, both source_id and source_flags will have a value of 0. Source information, "carousel-like" information, or carousel information corresponds to information that may be repeated in a movie fragment. -0x000002 is marked as in-splice, and when set this way, it indicates that the track described in DynamicMovieBox corresponds to a content splice period, which immediately reverts to the previous configuration. By monitoring this flag and the source_id field, the processing media pipeline can be optimized as needed (for example, to avoid unloading / reloading decoder resources). If 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 a presentation timeline.

[0101] A DynamicMovieBox with a source_id different from 0 may contain 0 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 facilitates time adjustments by the reader or player between two different presentations. When an 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 discontinuities (e.g., within the presentation timeline) between the two movie fragments. This can be used as an instruction to the player or reader to forget that it may have recorded (along with the corresponding decoder configuration) a previously encountered source_id, since the encapsulation module may reuse previously used source_ids. Therefore, a DynamicMovieBox with a source_id different from 0 and without a DynamicTrackBox is a kind of indicator that there is no continuity between the source_id values ​​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 used to indicate that, when set, the track configuration is temporary and will immediately revert to the "moov" configuration.

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

[0104] These additional flag values ​​allow the parser or reader to have finer processing of the decoder configuration and decide to buffer some configurations to avoid some decoder resets and, in some cases, display freezes. For example, if flag value 0x000004 is set, it means that the decoder may only retain the first decoder configuration corresponding to what was derived from the "moov" box.

[0105] [Example of DynamicMovieBox syntax] 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, a DynamicMovieBox box can 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 DynamicMovieBoxHeader is a Box or FullBox that provides fields equivalent to source_id and source_flags from the first example, 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; } / / In some cases, other fields that provide information about the track configuration, or information common to all tracks in the track configuration.

[0108] If a DynamicMovieHeaderBox does not exist, the parser or reader may simply assume a new track configuration indicating that the “moov” configuration applies to this movie fragment. The DynamicMovieHeaderBox may include additional parameters that provide parameters that apply to all tracks in the new track configuration, such as timescale, language, or a transformation matrix (like in MovieHeaderBox “mvhd”).

[0109] The semantics for DynamicMovieBox may also be defined as follows: In Figure 6a, the source_id (or carousel_id, the name is just an example) referenced in 604 identifies the origin of the movie fragment (e.g., the presentation). If DynamicMovieBox is set to 0, DynamicMovieBox modifies the MovieBox (e.g., by disabling, overwriting, adding, replacing, or changing the sample description or high-level metadata). Otherwise, all tracks, user data, and potentially high-level metadata declared in the MovieBox are ignored. In other words, when the value of this field is not 0, DynamicMovieBox indicates a new track configuration or a new presentation for one or more movie fragments (this value is repeated the same number of times in the movie fragment). When this field is set to 0, the parser or reader may interpret this 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 not 0, the parser or reader may interpret this as a complete change in the track configuration, possibly involving a change in the presentation timeline. The default value for source_id is assumed to be 0, for example, if it is not declared. The source_flags (or carousel_flags, where name is just an example and is referenced in Figure 6a, 605) identify the modifications declared in this DynamicMovieBox and compare them if they have the same source_id value as the previous DynamicMovieBox. The following flags may be defined to be set or bound to the value of the source_flags parameter. -0x00000001 indicates that one or more tracks have been modified, if this setting is enabled. For example, one or more tracks may have been added, overloaded, or disabled (temporarily removed). -0x00000002 indicates that global user data (for example, user data boxes for the entire presentation, e.g., within the "moov" box or the DynamicMovieBox "dymv" box) has been modified, if this setting is enabled. -0x00000004 indicates that a global metabox (for example, metadata for the entire presentation, e.g., metadata within the "moov" box or the DynamicMovieBox "dymv" box) has been modified, if this setting is enabled. -0x00800000, when set to this value, 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 the DynamicMovieBox if a previously parsed DynamicMovieBox has the same source_id. In other words, the reader or parser may decide not to parse the track configuration shown in the DynamicMovieBox with this flag value set when it has already been processed with the same source_id. This also indicates that the player can safely continue using the decoder configuration and thus avoid processing the decoder (e.g., resetting or reinitializing to a different configuration (codec change, profile or level change, etc.), and skipping steps 522 or 505 in Figure 5, etc.). The default value of source_flags is, for example, 0 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 is because a source_id equal to 0 means that the presentation declared as "moov" is active (the current one), and at that time, if a change in the track configuration is indicated using DynamicMovieBox, the player must handle it, for example, unless they have already encountered this track configuration, so there is no need to further indicate that the flag value 0x00800000 is set. The value of source_flags may be set to 0x00800000, but it should be ignored by the file reader (i.e., considered not set) if the previous DynamicMovieBox has a different source_id, or if this is the first DynamicMovieBox that was 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 or remote resource) is an instruction to the reader or player that the track in fragment N should be treated as a new track, and the track in fragment N-1 should be ignored. In this case, there is no guarantee that the timeline is continuum 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 continuum timeline is implementation-dependent (i.e., may not be standardized) and may be driven by processing pipeline capabilities. However, for these reconstructions, implementations should avoid introducing long playback gaps at source_id changes. For example, the parser or reader may decide to recalculate the timing (e.g., by using some edit list, via "ftdt" or any box for timing instructions, for example, by using a sample description).

[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 consecutive by the reader or parser, and the constraints on 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 it is necessary to insert or replace some tracks, all of these tracks may be declared in a single DynamicMovieBox, in their own DynamicMovieBoxes, or in a combination of both approaches.

[0112] If a DynamicTrackBox of a DynamicMovieBox with a Source_id value of 0 does not have a track from the MovieBox enumerated for updating or deletion, the track is still considered valid, but, as with a normal movie fragment, the movie fragment may not have a track fragment for this track.

[0113] In a variation, DynamicMovieBox600 may be the top-level box for a segment or fragment. This allows for mutual declaration of track configurations across multiple movie fragments. This may be suitable for encapsulations where there is one track per movie fragment. This may be less suitable for encapsulations where one "moof" contains all tracks. The same fields and subboxes may be used in DynamicMovieBox declared as the top-level box. Another variation is to indicate (e.g., step 420 in Figure 4) or identify (e.g., step 501 in Figure 5) that the media file is entirely dynamic when one of the top-level boxes is DynamicMovieBox, instead of the "moof" box. When DynamicMovieBox600 is used as the top-level box, SegmentIndexBox may refer to the beginning of DynamicMovieBox, instead of or in addition to the "moof" box, if present. This may be indicated by a specific (new value) reference_type in the "sidx" box.

[0114] [Dynamic Trackbox] The DynamicTrack box 601 may contain zero or more boxes, as shown in Figure 6a. It is identified by a 4CC code, for example, "dytk", or any dedicated 4CC reserved for this use and not conflicting with existing 4CCs. It provides a lighter track declaration than the "trak" box and its subboxes. Because it may be repeated along the media presentation, some fields or subboxes 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 duration of the parent movie fragment.

[0115] Tracks declared by DynamicTrackBox and for which there are no tracks with a matching track_ID within MovieBox implicitly declare a TrackExtendsBox with the value default_sample_description_index set to 1 and the values ​​default_sample_duration, default_sample_size, and default_sample_flags set to 0. Similarly, tracks declared by DynamicTrackBox and for which the associated source_id is not equal to 0 may also implicitly declare these boxes. This allows defining default values ​​for the track run boxes that describe samples of these tracks. 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 dynamic tracks within a single movie fragment, the default values ​​may need to be re-encoded for each track fragment. A DynamicMovieBox600 may contain zero or more DynamicTrackBox601. A DynamicTrackBox contains a DynamicTrackHeaderBox, which provides track information, see 602 in Figures 6a and 6b.

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

[0117] The semantics for DynamicTrackBox may also be defined as follows: `data_info`, if present, indicates the source or location of the sample data for this dynamic track. If it does not exist, the sample data resides in a container (media data box). The location of this data may be indicated by a URL or URN, or by any type of data entry inherited from `DataEntryBaseBox`. minf_header_info, if present, provides a media-specific header box typically found within the MediaInformationBox of tracks with 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., as defined by ISOBMFF or a derived specification).

[0118] Other boxes within a DynamicTrackBox, with the exception of the DynamicTrackHeaderBox described below, have semantics that are unchanged compared to those specified in ISO / IEC 14496-12. They replace the TrackBox (and subboxes) of the MovieBox or the corresponding boxes of the previous DynamicTrackBox, if present.

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

[0120] A DynamicTrackHeaderBox is included in each DynamicTrackBox.

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

[0122] This flag value may be used, for example, in "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 will either overwrite the existing track or declare a new track. In this case, - If the parent DynamicTrackBox has a box named "stsd": If there is a track with the same ID in the MovieBox, it will overwrite the current track; otherwise, a new track will be added to the presentation. • Note 1: In the derived specification, it can be specified that the handler type / timescale / width / height remain the same in this case. • Note 2: This is generally used to update the sample description of a track. -If the parent DynamicTrackBox does not have a "stsd" box: The MovieBox must have a track with the same ID, and all fields in the DynamicTrackHeaderBox must match the corresponding fields in the track / handler / media header box declared in the MovieBox. This may be used to update the track's UserDataBox, MetaBox, TrackReferenceBox, or TrackGroupBox. In this case, the track's sample description is not changed. Using such instructions, 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 been changed but remains functionally equivalent to a previous occurrence of this track header (the same track_ID in "dytk" within "dymv" with the same source_id value). For some values ​​used in DynamicMovieBox or DynamicTrackBox, the value 0x800000 may be used here. This may be used, for example, when volume information is changed, or when some parameters that do not affect the decoder configuration are changed. If the "stsd" box does not exist, you can also use a dedicated flag to avoid re-enumerating elements that match the "moof" track element.

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

[0125] (Regarding modification_flags602-2) The following flags may be defined. -0x000001: The track configuration has been changed (changes to one or more fields in DynamicTrackHeaderBox, changes to the associated media header box ("vmhd", "smhd", etc.), or changes to the associated data information box). -0x000002: Media configuration has been changed (e.g., a new sample description). -0x000004: Track UserDataBox has been modified. -0x000008: Track MetaBox has been modified. -0x000010: TrackReferenceBox has been modified. -0x000020: TrackGroupBox has been modified. -0x800000: The track modification is functionally equivalent to a previous DynamicTrackBox with the same track_id and source_id. This flag is set within 602-2 by the encapsulation module, but should be ignored by the file reader (i.e., considered not set) when the previous DynamicMovieBox has a different source_id, or when this is the first DynamicTrackBox parsed for this track_id and source_id. If modification_flags is not set (explicitly or according to the rules above), or if the value is 0, there is no information about 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 HandlerBox's handler_type, The same media_timescale as the timescale in MediaHeaderBox. `delay` indicates the media delay of a track using `media_timescale`. The presentation time for any sample within a track is the sum of the sample's composition time and this value. A negative presentation time indicates that (part of) the sample data is not presented (media skipped), and a value of 0 can be used by the parser or reader if it is not encrypted. The same `track_flags` as the `TrackHeaderBox` flags. If this field is not encoded and there is no track matching the same `track_ID` in the `MovieBox`, the value of this field is presumed to be 0x000003. The same language as MediaHeaderBox. The same extended_language as within ExtendedLanguageBox. The same alternate_group as inside TrackHeaderBox. The same width as within the TrackHeaderBox is used; if not encrypted, the media width after applying the pixel aspect ratio and clean aperture is used. The same height as within the TrackHeaderBox is used; if not encrypted, the media height after applying the pixel aspect ratio and clean aperture is used. The same layer as within the TrackHeaderBox; if not encrypted, the layer is 0. The same matrix used within the TrackHeaderBox is used; if not encrypted, the identity matrix is ​​used. The same volume as in the TrackHeaderBox is used; if it's not encrypted, the 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 STSD: - For DynamicTrackHeaderBox headers, 12 bytes, - For audio (no volume), 17 bytes; for video with size / layers and no track matrix, 27 bytes (63 bytes 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.392kbps for audio and around 0.47kbps for video (0.76kbps if a full visual matrix is ​​specified). Therefore, it is estimated to be over 4kbps if a new track is described using a classic TrackBox, compared to approximately 1.3kbps for full signaling (tracks and "stsd").

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

[0129] Furthermore, the proposed boxes enable efficient signaling for adding tracks and provide an integrated approach for adding tracks or changing codec configurations in a presentation. This allows for the removal of tracks (or signaling for temporarily disabled or inactive tracks), and various flags in DynamicMovieBox or DynamicTrackHeaderBox allow parsers or readers to easily detect recurring or modified track configurations, as well as temporary changes to the track configuration (such as splice periods) (e.g., the time interval between new presentations replacing previous ones, e.g., movie advertisements).

[0130] This proposed box may be combined with a movie fragment that depends on a reference movie fragment. Let's assume that such a dependent movie fragment is signaled by a specific 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 with a MovieFragmentHeaderBox version of 0, or in the last TrackFragment within that movie fragment, will apply to this movie fragment, and no SampleGroupDescriptionBox, DynamicTrackBox, or MetaBox defined for this movie fragment will exist. Note that this flag field can be used as a variation of the version field. This may be more useful when the MovieFragmentHeaderBox needs to be expanded with a new field preferably enclosed within a version number.

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

[0132] To override the tracks declared in the "moov" box 705 (which have track_IDs "i" and "j"), a new track configuration is shown within the media file (within the "moov" box 730) from movie fragments 700-3 and 701-3. The new content referenced in 706 may correspond to, for example, a second media source, splicing, or alternative content for the first or main media source, which is encapsulated in step 407 of Figure 4. This new track configuration is signaled within the media file as DynamicMovieBox 730-1, repeated in DynamicMovieBox 731-1 (as indicated by the same value of source_id), and repeated in DynamicMovieTrackBox boxes 730-2 and 730-3, and DynamicMovieTrackBox boxes 731-2 and 731-3. As shown in the figure, DynamicMovieBox 730-1 has a field indicating the override of the initial configuration being set. In the example in Figure 7, this corresponds to the source_id field, which has a value other than 0 (here, 1). DynamicMovieBox730-1 indicates, for example, any changes to this movie fragment in the source_flags field. In this example, this value could be set to 0, which indicates that no further information is provided to DynamicMovieBox in the case of a track configuration change. In fact, since this is the first occurrence of the "dymv" box with this identifier (source_id) value, it is possible to omit any indication of what information exists or may have changed (e.g., source_flags=0). Whatever the indication of change through the source_flags field (here, 0, but it could take a different value) may be, this first occurrence should be processed, which is an instruction to the player or reader.

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

[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 started before fragments 700-3 and 701-3, the source_id is kept the same value (1 in this case), and in DynamicMovieBox box 731-1, source_flags can be set to 0x800000 (or even 0) to indicate that the track configuration is the same as a previous track configuration defined in DynamicMovieBox box 730-1, which has the same source_id value (value 1 in this case). Using 0 or 0x800000 results in the same behavior for the parser or reader. If a track configuration with this source_id value has already been processed, the boxes (DynamicMovieBox 731-1 and its subboxes 731-3) that indicate and describe the track configuration are ignored. Using 0x800000 provides more detailed information than the value 0, indicating that there may be changes to the track configuration, but these are minor configurations. For example, modifications relate to high-level metadata or user data, but do not affect the number of tracks or the decoder configuration. Similarly, the track information details in DynamicTrackBox boxes 731-2 or 731-3 indicate modification_flags for 0x800000, indicating that the track configuration is nearly 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 so that a player or reader randomly accessing this movie fragment 700-4 or 701-4 can obtain a sample description of track "k" or "l".While this focuses on possible values ​​for source_id, source_flags, or modification_flags, note that other parameters from DynamicTrackBox or DynamicTrackHeaderBox may also be specified in these boxes (e.g., those shown in Figures 6a and 6b, which are not shown for clarity). Also note that the presence of "stsd" boxes 730-22 and 730-32 may be optional when fragments 700-4 and 701-4 are dependent movie fragments (since the player cannot randomly access the bitstream starting from these fragments).

[0135] For 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 applying, resuming, or restoring the configuration defined in the "moov" box 705. The decoder set up for track "i" or "j" may be restored to the previous configuration if saved by the player or reader (or if the player or reader maintains several configurations and can switch from one configuration to another), for example in 505 or 522 in Figure 5. Note that the player or reader may decide to store the decoder configuration depending on the value of the flags field in 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 revert to the previous configuration (in this case, the configuration defined in the "moov" box 705). Also note that additional values ​​defined in the variations described in relation to DynamicMovieBox may be set here. Similarly, for 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 be 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 track configuration change 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, with one DynamicTrackBox box for each track occurring between movie fragment 700-3 or 701-3 and movie fragment 700-4 or 701-4. Note that the modification_flags value in repeated occurrences of 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 changes occur in the corresponding track from one movie fragment to another that require decoder reinitialization. If changes occur, the value of modification_flags should be set accordingly. Using the value 0x800000 instead of 0 offers some flexibility, as 0 indicates no change at all, while 0x800000 indicates a change that is at least "minor" and does not require a decoder reset. Of course, the values ​​0 or 0x800000 are examples, and other values ​​may be used for the same purpose if they are specified for this use. The usual boxes within the "moof" box, such as "traf" and "trun," are applied as defined by ISOBMFF and are not explained except that track_ID may refer to track_ID from the "dytk" box contained in the movie fragment. In the example in Figure 7, the "traf" box refers to tracks "k" and "l" of fragments 700-3~700-4 and 701-3~701-4, respectively. This sequence in movie fragment 706 represents a second presentation (e.g., an advertisement) spliced ​​into a first presentation or main presentation (e.g., a movie).

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

[0138] At some point in the presentation timeline corresponding to movie fragment 800-2, a first new track is added (track 801, track_ID="k"). This track also consists of one or more movie fragments 801-2 to 801-4. The addition of this new track is indicated by an encapsulation module having DynamicMovieBox830-1. This DynamicMovieBox has a flag value set to 1 to indicate the existence 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 a new track 801 is added, as described in DynamicTrackBox830-2 and DynamicTrackHeaderBox830-21. 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 a change in the number of tracks. The DynamicMovieBox contains DynamicTrackHeaderBox830-21 and DynamicTrackBox830-2 itself, which contains at least the sample description box "stsd"830-22. The flag value set to 2 in DynamicTrackHeaderBox830-21 indicates that further information regarding track modifications is provided in the modification_flags parameter, where a value of 0 or 0x00800000 indicates that no significant changes occurred because this is the first occurrence. An alternative may be to encode the flag value of 0 in DynamicTrackHeaderBox830-21 without indicating modification_flags. "moof"830 contains the "traf" box830-3 which refers to the new track (with track_ID="k"), and its associated media data box830-4 is also placed in the media file. Finally, the movie fragment for track "i" is also available as "moof"810-1 and its associated media data box810-2.This movie fragment 810-1 does not require any specific instructions such as "dymv", "dytk", or "dtkh".

[0139] Subsequently, in the presentation timeline, another additional track 802 is introduced at the time corresponding to movie fragment 800-3, with track_ID="j". The movie fragments described for the period are movie fragments for tracks "i" (not shown, classic "moof" boxes like 810-1 and "mdat" boxes like 810-2), "j" (832), and "k" (831). Movie fragment 831 contains DynamicMovieBox831-1 with source_id (e.g., equal to 0) indicating that the track configuration from "moov" is changing again (e.g., track addition here). 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 in 802). DynamicTrackBox831-2 repeats the sample description to enable random access, and its DynamicTrackHeaderBox referenced in 831-21 indicates that no modifications have occurred for track "k" since the last movie fragment which has a DynamicMovieBox with a source_id equal to 0. This can be indicated by a modification_flags value of 0 or 0x00800000, or simply by setting the flag value of "dtkh"831-21 to 0. "moof"831 contains one or more classic "traf" boxes 831-3 that reference track_ID "k", and the associated media data is provided in the "mdat" box 831-4. "moof"832 contains DynamicMovieBox832-1 with a source_id set to a value of 0 to indicate a change in track configuration. The source flag can be set to 1 to indicate a change in number or track, i.e., a change in track "j". DynamicMovieBox832-1 contains DynamicTrackBox832-2, which itself contains DynamicTrackHeaderBox832-21, and has a flag that can be set to 0 because it is the first occurrence of track_ID="j".DynamicTrackBox832-2 also includes a sample description in the “stsd” box 832-22 for the player or reader to obtain information about the sample, information about the codec being used, etc. Finally, “moof”832 includes one or more “traf”832-3 boxes that refer to a new track “j”, other fragment-related boxes defined by ISOBMFF (e.g., “trun”, etc.), and its associated media data box 832-4.

[0140] At the time corresponding to movie fragment 800-4, two new tracks "j" and "k" still exist. Dynamic MovieBoxes 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 in the current time interval. Each DynamicMovieBox has a DynamicTrackBox with appropriately set flags to indicate, for example, that no changes have occurred. Sample description boxes 830-22 and 832-22 still exist in their respective DynamicTrackBoxes to ensure random access at the time corresponding to movie fragment 800-4.

[0141] At the time corresponding to movie fragment 800-5 or 802-5, track "k" no longer exists. Therefore, DynamicMovieBox834-1 (inside the "moof" box 834) shows the change in the number of tracks with source_id=0 and source_flags=1 (track "k" no longer exists). DynamicMovieBox834-1 contains DynamicTrackBox834-2, which has sample description 832-22 (repeated from fragment 802-3), along with other boxes (not shown) in some cases. DynamicTrackBox834-2 contains DynamicTrackHeaderBox834-21 with flags=2, indicating the presence of modification_flags. modification_flags with the value 0x00800000 indicates that no "significant" change occurred for this track "j". Next, the classic boxes “traf” 834-3 and “mdat” 834-4 provide descriptions and data for samples of fragments 802-5 and 800-5 (in 814-1 and 814-2).

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

[0143] Figure 9 shows the same scenario as Figure 8, except that the 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 DynamicMovieBox931-1, which itself contains two DynamicTrackBoxes 931-2 and 931-3, respectively. These contain DynamicTrackHeaderBoxes referenced in 931-21 and 931-31, and sample descriptions referenced in 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 for track “k” are set to 0 or 0x00800000 to indicate that there is no change to this track, i.e., a continuation of this track. Next, each track "j" and "k" has its "traf" referenced in boxes 931-4 and 931-5, respectively, and an associated "mdat" box 931-6. For clarity, the movie fragment for track "i" corresponding to 900-3 is not shown here. Finally, if only the new track "j" remains, in addition to track "i", DynamicMovieBox934-1 contains only one DynamicTrackBox934-2 for track "j". DynamicTrackHeaderBox934-21 indicates that there are no changes to track "i". DynamicMovieBox934-1 shows the change in 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 initially declared in the “moov” box is overwritten. This overwrite involves updating the sample description, for example, changing the codec, or changing some parameters of the track described in the top-level metadata, user data about the track, or the track header. Such modifications may occur in non-blind or early splicing modes, as they require knowledge of the “moov” box, particularly to reuse the track_ID value.

[0145] As shown in the example in Figure 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 "moof" box 1005 and its subboxes. Each track is fragmented (e.g., movie fragments 1000-1 to 1000-5 and 1001-1 to 1001-5). At some point in the presentation timeline (this may occur several times, or only one occurrence may be shown for brevity), 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 an encapsulation module within the movie fragment box describing fragments 1001-3 and 1000-3. There may be one "moof" box describing 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 contains DynamicMovieBox1030-1 with source_id=0, indicating that there is a change or modification to the track configuration of the presentation. A source_flags value of 1 indicates that a change has occurred at the track level. DynamicTrackBox1030-2 indicates that a track with an ID equal to “i” in its track header 1032-21 has been modified. The flag value for this box can be set to 0 because it is the first occurrence. Alternatively, this can be set to 2 with modification_flags, which provide the changes, for example, indicating an overload of the “stsd” box (flag value 0x000002 set in modification_flags), indicating a possible overload of the track’s MetaBox (flag value 0x000008 set in modification_flags), and thus resulting in modification_flags=10, or flag value 0x000003 if the track layout has been changed.

[0146] DynamicTrackBox1030-2 includes the overload boxes "stsd"1030-22 and "meta"1030-23, which provide new definitions for the sample description, and high-level metadata for track "i" for the fragment duration. These new definitions replace those declared in the "moov" box for track "i" and apply to the duration of the fragment (1000-3). The flag value of DynamicMovieBox(1030-1) is set to 1 to indicate the presence of source identification information (source_id parameter). DynamicMovieBox1030-1 also includes a second DynamicTrackBox1030-3 indicating changes to track "j", such as changes to the track header information, as indicated by modification_flags=1. Note that the sample configuration from the "trak" box 1011 continues to apply because there is no new sample description (no "stsd" box). Box 1030 "moof" also contains classic "traf" boxes (1030-4 and 1030-5) with subboxes for describing sample offset, size, duration, etc., and the sample data corresponding to fragments 1000-3 and 1001-3 is stored in the "mdat" box 1030-6.

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

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

[0149] Regardless of the examples in Figures 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, each containing at least two DynamicMovieBox boxes (as shown in Figure 8) for a given time interval. Within this set of DynamicMovieBoxes, to avoid ambiguity for the reader or player in determining whether those DynamicMovieBoxes are related to the same presentation, a DynamicMovieBox can be extended with an additional parameter, such as 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 a DynamicMovieBox and its subboxes indicating a track configuration change should be dealt with depends on source_id. If 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] [Embodiments for multiple DynamicMovieFragments] This embodiment addresses one limitation of the above embodiment in which DynamicMovieBox600 includes only the source_id parameter and does not include the bundle_id parameter. In this embodiment, the syntax of DynamicMovieBox is extended to reuse most of the parameters defined and described above (e.g., 601 in Figures 6a and 6b). This extended DynamicMovieBox also supports the use cases described with reference to Figures 7, 9, and 10, and resolves the possible limitations of use cases like Figure 8, as described below.

[0151] Figures 11a to 11c show examples of track configuration changes.

[0152] Figure 11a illustrates an example of a presentation update, or an example of how dynamic tracks can be added to or spliced ​​into a presentation, potentially leading to a change in the track configuration. For illustrative purposes, movie fragments 1101 and 1102 correspond to a first presentation 1100 having its track configuration (e.g., a series of movie and track fragments with track_ID=1). Movie fragments 1111 and 1112 correspond to a second presentation 1110 having its track configuration for splicing or appending to a given period within the first sequence 1100. For further illustrative purposes, presentation 1110 consists of a sequence of movie fragments, including movie fragments 1111 and 1112. Note that each movie fragment can also contain several track fragments ("traf"), but only one is illustrated for clarity.

[0153] Figure 11b shows how movie fragments 1111 and 1112 of the second presentation 1110 in Figure 11a can be modified by an encapsulation module before being inserted into or spliced ​​into a sequence, for example, the first sequence 1100 in Figure 11a. Note that, to correspond to the original fragmentation of the second presentation 1110, one dynamic movie box "dymv" is added for each movie fragment (e.g., dynamic movie box "dymv" 1121 for movie fragment 1111, and dynamic movie box "dymv" 1122 for movie fragment 1112). Here, additional parameters such as the bundle_id parameter can be used in DynamicMovieBox. By adding this parameter, the two DynamicMovieBoxes 1121 and 1122 can be associated with the presentation and, as described, with parts or components of this presentation. This shows that the new track configurations correspond to the addition of each track configuration described for each of these parts. Note that, depending on the value of source_id within the DynamicMovieBox, the current fragment's track configuration may also include track configurations from movie fragments that do not contain a DynamicMovieBox. For consistency, when a given fragment's DynamicMovieBox sets its source_id to 0, other DynamicMovieBoxes within the same fragment (and possibly different “moof”) should also set their source_id to 0. The name bundle_id is just an example and could also be called “subset_id”, “component_id”, “partition_id”, or any other name specifically for identifying a partial configuration change within source_id. Using these parameters, tracks declared or modified in a DynamicMovieBox can have the same configuration across multiple consecutive movie fragments.The `source_flags` parameter of a `DynamicMovieBox`, when indicated by an encapsulation module, allows the file parser to detect that a `DynamicMovieBox` is a repetition of a previous `DynamicMovieBox` that had the same values ​​for `source_id` and `bundle_id`. If multiple dynamic tracks or movie-related metadata (such as user data or metaboxes) are modified or declared in multiple `DynamicMovieBox`s for the same `source_id`, each of these `DynamicMovieBox`s will use a different `bundle_id`. This can make it possible to indicate that a part of the presentation has changed.

[0154] Figure 11c shows an example where part of the track configuration of a presentation has been changed to insert presentation 1110. In this example, the configuration of track N (see 1121-21) of DynamicMovieBox 1121-2 has been changed. This partial configuration may be indicated at the DynamicTrackBox level (1121-21) using a modification flag, or at the DynamicMovieBox level (1121-2) by assigning a new value for bundle_id to this DynamicMovieBox 1121-2. This may be useful to indicate that part of the track configuration has been changed between movie fragments of a track, only for those with a bundle_id change (i.e., DynamicMovieBox 1121-2 in the example), without having to process the entire track configuration of both tracks N (1121-2) and K (referenced in 1122-2). This information within DynamicMovieBox allows the reader to detect partial configuration changes (track or moov level) without inspecting the DynamicTrackBox contained within the DynamicMovieBox (step 504 in Figure 5). For example, if a pair (source_id, bundle_id) does not change and source_flags does not change further, the reader can safely skip DynamicTrackBoxes. Note that bundle_id may also correspond to configuration changes that are not exactly track configuration changes, such as higher-level changes within "moov" boxes, like metadata in MetaBox ("meta") or user data in UserDataBox ("udat").

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

[0156] Tracks declared or modified in DynamicMovieBox may have the same configuration for multiple consecutive movie fragments. The source_flags parameter allows the file parser to detect that DynamicMovieBox is a repetition of a previous DynamicMovieBox with the same values ​​for source_id and bundle_id. If multiple dynamic tracks or movie-related metadata (user data, meta) are modified or declared in multiple DynamicMovieBoxes for the same source_id, these DynamicMovieBoxes may each use a different bundle_id. The following flags can be defined for this extended DynamicMovieBox(1200). -0x000001 source-info-present indicates that source information exists if set as such; otherwise, source_id, bundle_id, and source_flags take the value 0. -0x000002 in splice indicates that, when set, the track described in DynamicMovieBox corresponds to a content splice period and immediately reverts to the previous setting. 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). If source_id is 0, this flag is not set. Note that the encapsulation module may also use a flag in "styp" to signal this in order to simplify editing of files being concatenated.

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

[0158] This semantics may be updated as follows: The source_id identifies the origin of the fragment. A value of 0 may indicate that the source is a MovieBox and that 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. The 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 a splice, and each is present in its own movie fragment. This allows the file reader to detect if the modifications advertised for a given bundle have already been processed in the preceding movie fragment. The source_flags identify modifications declared in this DynamicMovieBox compared to previous DynamicMovieBoxes with the same source_id and bundle_id values. This flag may be defined as follows: 0x000001, if set this way, indicates that one or more track configurations have been changed. 0x000002, if set this way, indicates that global (MovieBox level) user data has been changed. 0x000004, if set this way, indicates that the global (MovieBox level) metabox has been modified. 0x800000, when set, indicates that the modification is functionally equivalent to a previous DynamicMovieBox with the same source_id and bundle_id. When this flag is set, the file reader may safely skip processing a DynamicMovieBox if a previously parsed DynamicMovieBox has the same source_id and bundle_id. Otherwise (this is the first DynamicMovieBox parsed using these source_id and bundle_id values), this flag may be set but ignored by the file reader (i.e., considered not set).

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

[0160] If source_flags is not set to 0x000001, the DynamicTrackBox present in this DynamicMovieBox must have its modification_flags set to 0x800000.

[0161] It should be noted that the source_id or bundle_id parameters can be encoded with a lower number of bits, e.g., 8 or 16 bits, instead of 32 bits. However, while using 32 bits matches the number of bits for the source_id or bundle_id parameter in the TrackHeaderBox, using 8 bits may be sufficient, which allows for a reduction in the description cost for dynamic tracks. The same applies to the source_flags parameter. While using 24 bits matches the flags in the TrackHeaderBox, using 8 bits (or 16 bits) may be sufficient to indicate what has changed within the track configuration and reduce the description cost for dynamic tracks.

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

[0163] For illustrative purposes, presentation 1300 consists of one or more consecutive 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 contained in separate movie fragments for fragments Ni through 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. Each movie fragment from N to K is accompanied by a DynamicMovieBox 1310-1, 1311-1, or the unshown 1312 and 1313, with its flag set to the value 3, indicating source_id_present and in-splice.

[0164] The source_id value of these DynamicMovieBoxes is set to a value greater than 0 to indicate that the MovieBox's track configuration 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). Each DynamicMovieBox then contains a DynamicTrackBox (e.g., DynamicTrackBox1310-2 or 1311-2) with a track_ID shown in its DynamicTrackHeaderBox (not shown) and SampleDescriptionBox ("stsd", not shown). This track_ID can take any value (new or reused from the MovieBox and its subboxes) provided 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 files with spliced ​​content in the first occurrence of a dynamic movie or trackbox (e.g., fragments 1310 and 1311), and skipping the next ones (up to fragment K, represented by references 1312 and 1313). Then, from fragment K+1 onwards, corresponding to a switch to return to the previous configuration, if this previous configuration is the same as MovieBox ("moov"), DynamicMovieBox is not necessary.

[0165] Figure 14 illustrates another example where the additional parameter bundle_id, as explained with reference to Figure 12, is not used to splice audiovisual content within a single movie fragment, with configuration changes (for clarity, the data portion of the movie fragment is not shown).

[0166] For illustrative purposes, the first presentation 1400 includes a series of movie fragments represented by references 1401 and 1402. During a given period, e.g., time N, new content referenced in 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 Figure 14, the number of tracks T is set to three, e.g., one video track, one audio track, and one subtitle track, but it could be several tracks of the same media type, e.g., two video tracks, or two audio tracks in different languages. Each track of content into splice 1420 is obtained as a sequence of movie fragments such as 1410, 1411-1414, each fragment containing all track fragments as detailed for movie fragment 1410, where the movie fragment box contains DynamicMovieBox "dymv" 1410-1 itself, which contains three DynamicTrackBox "dytk" referenced in 1410-21-1410-23, and three TrackFragmentBoxes (one "traf" per track, not shown). Subsequent movie fragments 1411-1414 also contain DynamicMovieBox "dymv" itself, which contains three DynamicTrackBox "dytk" and three TrackFragmentBoxes. Below, we will explain how to use the parameters within the "dymv" and "dytk" boxes to show configuration changes over time. Specifically, this example illustrates not only the start of splicing (time N), but also changes within the spliced ​​content, namely the configuration change that occurs at C1 and the switch that reverts to the previous configuration after C2. These variations can be represented as follows: For fragments within [N, 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), source_id is set to 1 (indicating that the configuration from the MovieBox is not applied to these movie fragments), bundle_id is set to 0 if present (it serves no role in this example), and 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 dynamic movie box 1410-1 will be processed, and because the values ​​of source_id and bundle_id do not change between N and C1, the following will be skipped. Dynamic track boxes 1410-21~1410-23 have the following values ​​as parameters. First, since source_id is greater than 0 (disables, overrides, or modifies the "moov" configuration), the track_ID value can be any value, even the track_ID value used in the MovieBox or its subboxes. 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) in each "dytk" box and referenced in each TrackFragmentBox that describes each of the three tracks' samples. Each DynamicTrackHeaderBox (not shown) has modification_flags set to 0x800000. Each DynamicTrackBox (1410-21~1410-23) contains a sample description box ("stsd") that provides details 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 values ​​as 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 configuration change is shown in DynamicTrackBoxes (not shown), where the change occurs. For example, each dynamic track has a "stsd" box (to ensure random access), and the change to "stsd" is shown in the corresponding DynamicTrackHeaderBox (not shown), where modification_flags is set to 0x000002 (and 0x800000 for dynamic tracks with no "stsd" change). This value, 0x000002, causes the player to process dynamic trackboxes with this value, even if the source_id and bundle_id values ​​are the same as in the previous fragment (1410). This track identifier is splice_track_IDs. For fragments (one or more) within [C1+1,C2], no changes occur. This is indicated by the encapsulation modules in DynamicMovieBox1412-1 and 1413-1, which have the same values ​​as DynamicMovieBox1410-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 DynamicMovieBox1412-1 (not shown) contains the same "stsd" as fragment 1411 (to ensure random access). This is indicated in their corresponding DynamicTrackHeaderBox (not shown), which have modification_flags set to 0x800002. The track identifier is splice_track_IDs. For fragments in C2+1, 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 with one "stsd". The modification_flags of the corresponding DynamicTrackHeaderBox are set to 0x000002 to indicate a configuration change (in the sample description that switches to a configuration like in [N, C1]). Each or a subset of dynamic tracks in the set of T tracks may have this configuration change. For tracks that have not been changed, modification_flags can be set to 0x800002 or 0x800000. The track identifier for this is splice_track_IDs. For fragments within [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 with one "stsd". The corresponding DynamicTrackHeaderBoxes set their modification_flags to 0x800002 to indicate that no changes occurred between fragment C2+1 and fragment C2+2, etc., up to fragment K. Finally, from fragment K+1 (referenced in 1402), the presentation switches back to the original configuration (MovieBox for presentation 1400). Here, if the configuration to be applied is the same as the configuration declared in "moov" (as in example 1402 for presentation 1400), DynamicMovieBox is not necessary. This track_ID is the one declared in the TrackHeaderBox within the "moov" box.

[0167] [Use of dependent or predictive fragments] The proposed DynamicMovieBox1200 and its subboxes may be combined with a movie fragment that depends on a reference movie fragment. Suppose such a dependent movie fragment is signaled by a specific version of MovieFragmentHeaderBox, for example, as follows: aligned(8) class MovieFragmentHeaderBox extends FullBox('mfhd', version, 0){ nsigned int(32) sequence_number; }

[0168] If the version is not 0, any SampleGroupDescriptionBox, DynamicMovieBox, UserDataBox, or MetaBox defined in the last movie fragment with a MovieFragmentHeaderBox version of 0, or in the last TrackFragment within that movie fragment, shall apply to this movie fragment, and no SampleGroupDescriptionBox, DynamicMovieBox, UserDataBox, or MetaBox defined for this movie fragment shall exist.

[0169] Note that instead of a version, a specific flag value may be defined to avoid any conflicts with the versioning of MovieFragmentHeaderBox (for example, to encode sequence_number in 64 bits). The above description would also apply.

[0170] [Example of hardware for performing the steps of the method according to the embodiment of the present invention] Figure 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 to the following: - A central processing unit (CPU) 1504 such as a microprocessor, - Random access memory (RAM) 1508 for storing registers adapted to record variables and parameters necessary to implement the executable code of the method of an embodiment of the present invention, and a method for encapsulating, indexing, deencapsulating, and / or accessing data, wherein the memory capacity can be expanded, for example, by optional RAM connected to an expansion port, - A read-only memory (ROM) 1506 for storing a computer program for implementing an embodiment of the present invention, - The system comprises a network interface 1512, which is typically connected sequentially to a communication network to which the digital data to be processed is transmitted or received. The network interface 1512 may be a single network interface or may consist of a set of different network interfaces (e.g., wired and wireless interfaces, or different types of wired or wireless interfaces). The data is written to the network interface for transmission or read from the network interface for reception under the control of a software application running on the CPU 1504: - A user interface (UI) 1516 for receiving input from the user or for displaying information to the user. - Hard disk (HD) 1510. and / or - I / O module 1518, used for receiving / transmitting data to / from external devices such as video sources or displays.

[0171] The executable code may be stored in read-only memory 1506, hard disk 1510, or a removable digital medium such as a disk. In a modified example, the program's executable code may be received by a communication network via a network interface 1512 so that it is stored in one of the storage means of a communication device 1500, such as the hard disk 1510, before execution.

[0172] The central processing unit 1504 is adapted to control and direct the execution of program instructions or a portion of software code according to embodiments of the present invention, and such 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 relating to a software application after those instructions have been 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 performed.

[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., by forming an application-specific integrated circuit or ASIC).

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

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

[0176] In the claims, the word “equipped with” does not exclude other elements or processes, and the indefinite article “a” or “an” does not exclude plurals. The mere fact that different features are described in different dependent claims does not imply that combinations of these features cannot be used advantageously.

Claims

1. A method for encapsulating media data of multiple presentations into at least one media file based on ISOBMFF, wherein the method is: To obtain the first portion of the media data of the first presentation, which consists of the first set of tracks, The first metadata describing the tracks of the first set of tracks is encapsulated in a moov box, and the first portion is encapsulated in one or more first media fragments. To obtain the second portion of the media data for the second presentation, which consists of a second set of tracks, Encapsulating the second metadata describing the tracks of the second set into a moof box corresponding to one or more second media fragments following the first media fragment, The method comprises encapsulating the second portion in one or more second media fragments, A method comprising a signal indicating that the second metadata does not include at least one track described in the first metadata.

2. The method according to claim 1, wherein the second metadata includes an instruction 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.

3. The method according to claim 1, wherein the second set of tracks does not include at least one track described in the first metadata.

4. The method according to claim 1, wherein the second set of tracks includes at least one track not described in the first metadata.

5. The method according to claim 1, wherein 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.

6. The method according to claim 1, wherein 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.

7. The method according to claim 1, wherein the instruction that signals that the second set of tracks does not include at least one track described in the first metadata includes an indicator that the second set of tracks is a new set of tracks.

8. The method according to claim 1, wherein the signal indicating that the second set of tracks does not include at least one track described in the 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.

9. The method according to claim 1, wherein the second metadata further includes instructions for signaling that one or more second media fragments can be analyzed independently of the first fragment.

10. The method according to claim 1, wherein the media fragment is a segment or fragment of a Common Media Application Format (CMAF) or a segment or fragment of an ISO-based Media File Format (ISOBMFF).

11. A method for analyzing media data of multiple presentations, wherein the media data is encapsulated based on ISOBMFF as multiple fragments of one or more media files, and the method is performed by a client. Retrieving first metadata from the moov box that describes a first set of tracks in a first presentation containing one or more first media fragments, Metadata describing a second set of tracks for a second presentation, wherein second metadata is obtained, which is encapsulated in a moof box corresponding to at least one second media fragment following the first media fragment, Obtaining the at least one second media fragment containing the media data of the second presentation, Analyzing at least a portion of the second metadata described above, When it is determined that the second metadata contains an instruction that signals that the second set of tracks does not include at least one track described in the first metadata, the track description is updated in order to analyze the encapsulated media data. Methods that include...

12. The method according to claim 11, wherein updating the track description comprises parsing 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.

13. The method according to claim 12, wherein the at least other portion of the second metadata includes a description of at least one track not described in the first metadata.

14. The method according to claim 12, wherein the at least other portion of the second metadata includes a new value for at least one parameter of the description of at least one track described in the first metadata.

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

16. The method according to claim 11, wherein the first metadata is obtained from a media fragment.

17. Obtaining at least one third media fragment containing encapsulated third metadata and encapsulated media data, wherein the third metadata describes a third set of tracks of a presentation containing the media data encapsulated in the at least one third media fragment containing the third metadata, Analyzing at least a portion of the above-mentioned third metadata, If it is determined that the third metadata contains an instruction that signals that the description of the third set of tracks is similar to the description of a previously determined set of tracks, then the analysis of another part of the third metadata is skipped, and the current description of the set of tracks is used to analyze the media data of the at least one third media fragment containing the encapsulated third metadata. The method according to claim 11, 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 loaded and executed by the programmable device.

19. A computer-readable storage medium storing instructions for a computer program to implement the method described in 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