Method, apparatus and computer program for optimizing dynamic encapsulation and parsing of content data

Abstract

At least one embodiment of a method for encapsulating a number of rendered media data in a media file. After a portion (first portion) of first rendered media data composed of a first set of tracks has been obtained, first metadata describing tracks in the first set of tracks is encapsulated and the first portion is encapsulated in one or more first media segments. After obtaining a portion (second portion) of second rendered media data consisting of a second set of tracks, second metadata describing tracks in the second set of tracks is encapsulated in one or more second media segments following the first media segment, and encapsulating the second portion in one or more second media segments. The second metadata includes an indication that the second set of tracks does not include at least one track as described in the encapsulated first metadata.

Description

Technical Field

[0001] The present invention relates to a method, apparatus and computer program for improving dynamic packaging and parsing of media data. Background Art

[0002] The ISO base media file format (ISOBMFF, also called the file format) is a generic format that forms the basis of many other more specific file formats. ISOBMFF is standardized by the International Organization for Standardization as ISO / IEC 14496-12. This format contains characteristics of media data, such as the timing, size or media information of a timed sequence of media data (such as an audiovisual presentation, etc.). These characteristics are generally referred to as metadata (or structural data) in contrast to media data (or data). An ISO base media file (also called a media file or animation file or media presentation) can be a file containing the entire presentation, or as multiple segment files, where each segment contains a time portion of the presentation. The ISO base media file is structured into "boxes", each of which is identified by a four-character code (also expressed as FourCC or 4CC). In the file format, the entire presentation is called an animation. An animation or presentation is logically divided into tracks, or consists of one or more tracks, where each track represents a timed sequence of media (for example, a timed sequence of video pictures, where a picture is a frame or field of interlaced video). In each track, each timing unit is called a sample. Each track has one or more sample descriptions. Each sample in a track is associated with a description by reference. All structural data or metadata (including structural data or metadata that defines the placement and timing of the media) is contained in a structured box. Media data (such as 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 may contain zero or more media data boxes. The total duration of each track is defined in the structural data. Each sample has a defined duration. The exact decoding timestamp of a sample is defined by adding the duration of the previous sample.

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

[0004] The media data encapsulated in media file 100 begins with a FileTypeBox ("ftyp") box (101), which provides a set of categories used to identify the precise specifications to which the encapsulated media data conforms, which a reader uses to determine whether the encapsulated media data can be processed. The "ftyp" box is followed by a MovieBox ("moov") box, labeled 105. The MovieBox box provides initialization information required by the reader to initiate processing of the encapsulated media data. In particular, the MovieBox box provides a description of the presentation content, the number of tracks, and information about their respective timelines and characteristics. For illustration, the MovieBox box may indicate that the presentation includes one track having an identifier track_ID equal to 1.

[0005] The fragmented ISO base media file 100 may be a collection of media segment files in which the MovieBox ("moov") box 105 does not contain information for the entire duration of the animation. In particular, there may be few or no samples in the tracks of the box (the tracks are described by the "trak" box 135). For this minimal or empty animation, additional samples are added in structures called animation fragments (e.g., animation fragments 100-1 and 100-2), which are described by a hierarchy of boxes (primarily a pair of "moof" boxes (e.g., "moof" boxes 110 or 120) and "mdat" boxes (e.g., "mdat" boxes 115 or 125)). Each animation fragment includes metadata stored in the MovieFragmentBox ("moof") box (and its child boxes) and media data stored in the MediaDataBox ("mdat") box (or the identified media data box "imda"). The presence or absence of animation clips in a media file is indicated early in the file by a MovieExtendsBox ("mvex") box 130. When present, the information contained in this box warns the reader that subsequent animation clips may exist and that these animation clips must be found and scanned in the given order to obtain all samples of the track. To this end, the information contained in this box should be combined with the other information of the MovieBox box. The MovieExtendsBox box 130 can contain one TrackExtendsBox ("trex") box for each track defined in the MovieBox "moov" box 105 and an optional MovieExtendsHeaderBox ("mehd") box. When present, the MovieExtendsHeaderBox box provides the total duration of the fragmented animation. Each TrackExtendsBox box defines the default parameter values ​​(type, size, duration, control flags, etc.) for the description of the samples of the track fragments.

[0006] For illustration, the media file 100 includes a first animation clip 100-1 that contains and describes samples 1 to N of a track identified with a track_ID equal to 1 (as indicated in a "tfhd" box). The first animation clip 100-1 is composed of a "moof" box 110 and an "mdat" box 115. Still for illustration, the media file 100 includes a second animation clip 100-2 that contains and describes samples N+1 to N+M of a track identified with a track_ID equal to 1. Like the first animation clip, the second animation clip 100-2 is composed of a "moof" box (labeled 120) and an "mdat" box (labeled 125).

[0007] The encapsulated media data may be fragmented into a single media file or multiple media segment files (referred to as segment files). When encapsulated into multiple segment files, the FileTypeBox and MovieBox boxes (hereinafter also referred to as initialization fragments) are contained in the initialization segment file (also referred to as initialization segment), wherein in the initialization segment, one or more tracks do not contain any samples. Subsequent segment files contain one or more animation clips such as animation clip 100-1 and animation clip 100-2. These one or more animation clips may constitute ISOBMFF segments, DASH segments, DASH media segments, CMAF segments, or CMAF fragments.

[0008] The use of animation segments is particularly relevant to real-time encoding and real-time packaging (or encapsulation), as this encapsulation mode requires less buffering capacity of the encapsulation module. It is also relevant to low-latency streaming (e.g., adaptive streaming over HTTP like DASH or HLS (HTTP Live Streaming)), as the encoded media is available as soon as the animation segments are encoded and encapsulated.

[0009] Animation clips, such as animation clips 100-1 and 100-2, have a box hierarchy that is different from the box hierarchy under the "moov" box. Similarly, track fragments (described in TrackFragmentBox ("traf") boxes, such as "traf" boxes 111 and 121) have a box hierarchy that is different from the TrackBox box (e.g., different from the "trak" box 135). As shown, the TrackBox box 135 contains a SampleTableBox ("stbl") box in its box hierarchy, which in turn contains descriptive and timing information for the media samples of the track. Note that in the case where the media file 100 is fragmented, there may be no 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, which give descriptive information about the coding format of the sample (the coding format is identified by a specific 4CC (as shown by "xxxx" characters)), and the initialization information required to configure the decoder according to the coding format.

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

[0011] In an animation clip, samples are primarily described in a TrackFragmentHeaderBox ("tfhd") box, which may provide default sample entries (codec type in use and encoding configuration information), default sample sizes, and / or default sample durations. The actual sample size, duration, offset in the media data section, or flags (in case these values ​​differ from the defaults, or in case no default values ​​are defined) may be indicated in a TrackRunBox ("trun") box for sample descriptions. A TrackRunBox ("trun") box records a contiguous set of samples (a run) for a track in an animation clip.

[0012] For example, with respect to sample timing, a track fragment may contain a TrackFragmentBaseMediaDecodeTimeBox ("tfdt") box that provides the absolute decode timestamp (using the baseMediaDecodeTime parameter) of the first sample in the track fragment in decoding order, measured on the decoding timeline. For random access or synchronization, a track fragment may have an indication of the decode time in the "tfdt" box. When this box is present, a player or reader is not required to sum the sample durations of all preceding samples in the previous fragment to find the value. For example, the MPEG DASH specification mandates that this box appear in each "traf" box of a media segment in the real-time profile of ISOBMFF. A "moof" box may contain one or more "traf" boxes, for example to multiplex audio and video track fragments in the same media data box. Some specifications based on ISOBMFF may constrain a media file or segment file to contain one "traf" box for each "moof" box.

[0013] It should also be noted that ISOBMFF and its extensions include several grouping mechanisms to group tracks, static items, or samples together, and to associate group descriptions with groups. Groups generally share common semantics and / or properties. For example, the MovieBox ("moov") box 105 and / or the MovieFragmentBox ("moof") boxes 110 and 120 may contain sample groups that associate properties with groups of samples of a track or track fragment. Sample groups characterized by a grouping type may be defined by two linking boxes, a SampleToGroupBox ("sbgp") box representing the assignment of samples to sample groups, 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 builds on ISOBMFF, and in particular on ISOBMFF segments, as a common container for streaming of multimedia presentations. For example, the same CMAF presentation can be described by different manifests (such as MPD for MPEG DASH or playlists in HTTP Live Streaming).

[0015] CMAF is codec-independent and defines several profiles for audio, video, subtitles, etc. depending on the type of codec and application used. For example, when the target application is low-latency streaming, CMAF provides guidelines on CMAF segment settings. This is usually a trade-off between encoding latency and buffering constraints and bitrate efficiency: the longer the CMAF segment, the larger the receive buffer and possible latency will be, but the compression may be more efficient (avoiding encoding of intra-coded frames (i.e. frames that do not have encoding dependencies on previously coded frames) such as IDR, CRA frames in MPEG video codecs).

[0016] FIG2 illustrates CMAF segments addressable from a streaming manifest and their relationship to ISOBMFF animation fragments. A CMAF segment such as CMAF segment 200 typically has a duration of a few seconds (e.g., 2 to 10 seconds) and may contain one or more consecutive CMAF fragments of the same track. A CMAF fragment corresponds to a coded ISOBMFF media segment with some specific constraints.

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

[0018] As shown in b of Figure 2, a CMAF fragment may contain several CMAF chunks. According to the example shown, the CMAF fragment 205' includes three CMAF chunks labeled 250-1 to 250-3. Still according to this example, each CMAF chunk includes a set of continuous samples covering a given time period that can change from one chunk to another. As shown in the figure, each CMAF chunk is actually constructed like an animation clip and includes a "moof" box and an "mdat" box. For example, CMAF chunk 250-1 includes a "moof" box 255-1 and an "mdat" box 260-1.

[0019] The first CMAF chunk of the CMAF fragment (e.g., CMAF chunk 250-1) can be constrained to be addressable (e.g., associated with a URL or URL template) or start from an adaptive switching point. This reduces streaming latency because the client only has to wait for a single CMAF chunk to be encoded, packaged (or encapsulated), and transmitted, rather than waiting for the entire CMAF segment (e.g., segment 200 in FIG. 2a) to be encoded, packaged, and transmitted. In other words, the client will only wait for the CMAF chunk to be available to request the chunk, without having to wait for the entire segment to be ready.

[0020] CMAF chunking follows the ISOBMFF rules for animation clips with additional constraints, such as one "traf" box per animation clip with only one "trun" box, mandatory "tfdt" for each track fragment, and additional boxes describing encryption depending on the use case (e.g., SampleAuxiliaryInformationOffsetsBox "saio" or SampleAuxiliaryInformationSizesBox ("saiz") box or "seig" sample group description (CencSampleEncryption group)).

[0021] Although the ISOBMFF file format has proven to be efficient, there is a need to improve the packaging efficiency, in particular the increasing need for flexibility of file formats (such as ISOBMFF or CMAF) to cope with the surge in real-time adaptive streaming or on-demand video streaming services. In fact, content data is no longer considered as one data with a complete configuration known in advance, but as dynamic content data, where content can be injected or spliced ​​at a certain time, for example to add advertisements during the playback of animations or sports events. In addition, additional media data can be overlaid on the video, for example to provide scores or statistics on a sports game video. This requires dynamic processing that is not taken into account in the case of file formats. For example, despite the presence of fragmentation, in ISOBMFF and derived specifications, all tracks and all sample descriptions must be known and declared in advance. Summary of the invention

[0022] The present invention is designed to address one or more of the aforementioned problems.

[0023] According to a first aspect of the present invention, a method for encapsulating media data of multiple presentations in at least one media file based on ISOBMFF is provided, the method comprising:

[0024] Obtain a portion of media data of a first presentation, the portion denoted as a first portion, the first presentation consisting of a first set of tracks;

[0025] encapsulating first metadata describing tracks in the first set of tracks and encapsulating the first portion of media data of the first presentation in one or more first media fragments;

[0026] obtaining a portion of media data of a second presentation, the portion denoted as a second portion, the second presentation consisting of a second set of tracks; and

[0027] encapsulating second metadata describing tracks in the second set of tracks in one or more second media fragments following the first media fragment, and encapsulating the second portion of media data for the second presentation in the one or more second media fragments,

[0028] Wherein the second metadata comprises an indication signaling that the second set of tracks does not include at least one track as described in the encapsulated first metadata.

[0029] Thus, the method of the present invention provides dynamism and / or flexibility of encapsulation and parsing while preserving key features of the file format (e.g., fragmentation and random access). The flexibility may be in adding or removing tracks, disabling tracks declared at the beginning, overwriting tracks, replacing tracks, inserting tracks, etc. The indication of changes to the track configuration preserves random access, which means that any player tuned to the media presentation is able to obtain the current track configuration without additional requests to minimize startup delays.

[0030] According to some embodiments, the second metadata comprises an indication signaling that a 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 in the second metadata.

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

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

[0033] According to some embodiments, the at least one media file comprises a metadata portion, the metadata portion being used to encapsulate metadata common to all media data encapsulated in the at least one media file, the first metadata being encapsulated in the metadata portion.

[0034] According to some embodiments, at least one of the one or more first media fragments includes a metadata part, which is used to encapsulate 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 part of the at least one of the one or more first media fragments.

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

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

[0037] According to some embodiments, the second metadata further comprises an indication signaling that the one or more second media segments can be parsed independently of the first media segment.

[0038] According to some embodiments, the segments are Common Media Application Format segments or fragments, namely CMAF segments or fragments, or ISO Base Media File Format segments or fragments, namely ISOBMFF segments or fragments.

[0039] According to a second aspect of the present invention, a method for parsing a plurality of presented media data is provided, wherein the media data is encapsulated as a plurality of segments of one or more media files based on ISOBMFF, the method being executed by a client and comprising:

[0040] obtaining first metadata describing tracks in a first track set for a first presentation,

[0041] obtaining at least one media fragment comprising encapsulated second metadata describing tracks in a second set of tracks of a second presentation and encapsulated media data, the second metadata being media data of the second presentation, and the at least one media fragment following the media fragment comprising the media data of the first presentation,

[0042] parsing at least a portion of the second metadata, and

[0043] Upon determining that 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, a track description to be used for parsing the encapsulated media data is updated.

[0044] Thus, the method of the present invention provides dynamism and / or flexibility of encapsulation and parsing while preserving key features of the file format (e.g., fragmentation and random access). The flexibility may be in adding or removing tracks, disabling tracks declared at the beginning, overwriting tracks, replacing tracks, inserting tracks, etc. The indication of changes to the track configuration preserves random access, which means that any player tuned to the media presentation is able to obtain the current track configuration without additional requests to minimize startup delays.

[0045] According to some embodiments, updating the track description comprises parsing at least another portion of the second metadata, updating the track description being based on metadata of the at least another portion of the second metadata.

[0046] According to some embodiments, the at least another part of the second metadata comprises a description of at least one track not described in the first metadata.

[0047] According to some embodiments, said at least another part of said second metadata comprises a new value of at least one parameter of the description of at least one track described in said first metadata.

[0048] According to some embodiments, 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, the first metadata being encapsulated in the metadata portion.

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

[0050] According to some embodiments, the method further comprises:

[0051] obtaining at least one media fragment including encapsulated third metadata and encapsulated media data, the third metadata describing tracks in a third track set of a presentation including the media data encapsulated in the at least one media fragment including the third metadata;

[0052] parsing at least a portion of the third metadata; and

[0053] When it is determined that the third metadata includes an indication that signals that the description of the third track set is similar to the description of a previously determined track set, parsing of another portion of the third metadata is skipped, and media data of at least one media fragment including the encapsulated third metadata is parsed using the current description of the track set.

[0054] According to another aspect of the present invention, a processing device is provided, which includes a processing unit configured to execute each step of the above method. Other aspects of the present invention have optional features and advantages similar to the above first and second aspects.

[0055] At least a portion of the method according to the invention may be computer-implemented. Thus, the invention may take the form of a fully hardware embodiment, a fully software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, which embodiments may be collectively referred to herein as "circuits," "modules," or "systems." Furthermore, the invention may take the form of a computer program product embodied in any tangible medium of expression having a computer-usable program code embodied in the medium.

[0056] Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for providing to a programmable device on any suitable carrier medium. Tangible carrier media may include storage media such as floppy disks, CD-ROMs, hard disk drives, magnetic tape devices, or solid-state memory devices. Transient carrier media may include signals such as electrical, electronic, optical, acoustic, magnetic, or electromagnetic signals, such as microwave or RF signals. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Embodiments of the present invention will now be described, by way of example only, and with reference to the following drawings, in which:

[0058] FIG. 1 illustrates an example of encapsulated media data temporally organized as fragmented presentations in one or more media files according to the ISO base media file format;

[0059] Figure 2 illustrates the CMAF segments addressable from a streaming manifest and their relationship to ISOBMFF animation segments;

[0060] Figure 3a , Figure 3b and Figure 3c An overview of a method for packaging or storing a multimedia presentation according to some embodiments of the present invention is illustrated;

[0061] Figure 4 illustrates an example of steps of a packaging process according to some embodiments of the present invention;

[0062] Figure 5 illustrates an example of steps of a parsing process according to some embodiments of the present invention;

[0063] Figure 6a and Figure 6b An example of box-based information for indicating a dynamic track configuration in a media file is illustrated;

[0064] Figure 7 An example of a track configuration that invalidates the track declared in the "moov" box is illustrated;

[0065] Figure 8 and Fig. 9 are other examples of uses of some embodiments of the present invention;

[0066] Fig.10 illustrates another example of a track configuration change where the tracks originally declared in the "moov" box are overwritten;

[0067] Figures 11a to 11c An example of rail configuration change is illustrated;

[0068] Fig.12 An example of the update syntax of DynamicMovieBox is illustrated;

[0069] Fig.13 Illustrated using reference Fig.12 An example of splicing with the additional parameter bundle_id described to utilize configuration changes contained in a single animation clip presented;

[0070] Fig.14 Another example is shown, where no reference is used Fig.12 The additional parameter bundle_id described in the description is used to splice the audiovisual content in a single animation clip using configuration changes; and

[0071] Fig.15 A processing device configured to implement at least one embodiment of the present invention is schematically illustrated. DETAILED DESCRIPTION

[0072] According to some embodiments of the present invention, the contents of some "moof" boxes of fragmented ISOBMFF media data are optimized to provide dynamics and / or flexibility of encapsulation and parsing while retaining key features of the file format (such as fragments and random access).

[0073] According to some embodiments of the present invention, track structures or track configurations may be declared along the media presentation, not just at the beginning of the presentation. Furthermore, the track configuration is repeated to ensure random access by the reader, the repetition being done in a manner to avoid useless processing for readers that play the file continuously. Thus, some embodiments of the present invention extend animation fragments and facilitate segment or fragment concatenation with minimal ISOBMFF structure rewrite. New ISOBMFF structures are defined to make this feature interoperable between writers and parsers that support it.

[0074] General packaging and parsing

[0075] Figure 3a An overview of a first method for encapsulating or storing multimedia presentations according to some embodiments of the present invention is illustrated. The media data to be encapsulated or stored, marked as 305, can be a video, a spatial sub-part of a video, an audio, a volumetric visual media, a subtitle, or a combination of these elementary streams. They are encapsulated into a media file or a media segment file 325 in a manner that allows adaptive streaming (possibly with low latency) over HTTP. As shown, the server 300 includes an encapsulation module 320 (also referred to as an ISOBMFF writer or simply a writer) and an optional streaming manifest generation module (not shown). The server 300 can be connected to a communication network 330 via a network interface (not shown), and the communication network 330 is also connected to a client 350 via a network interface (not shown). An example of a client is a media player on a PC, a tablet, a TV, or a smart phone.

[0076] Server 300 processes media data 305 to prepare for streaming or storage, which is called encapsulation. Processing mainly lies in adding metadata describing media data in terms of the type of data, the codec in use, size, data offset, timing, etc. As mentioned above, media data 305 can correspond to audio presentation or video presentation or both, and may have subtitles or timed text. Media data 305 can be original (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 according to different encoding versions. This means that encoding or compression can be performed by the server itself with an encoder module (such as encoder module 310) (possibly one encoder module for each media type), or remotely from the server. Compression can be real-time encoding (and encapsulation).

[0077] The media data 305 may also be encapsulated media data that is encapsulated in a manner that is not suitable for low-latency streaming, such as as a non-fragmented track. In the latter case, according to some embodiments of the present invention, the encapsulation module (e.g., encapsulation module 320) also includes a reader portion to decapsulate the media data and then encapsulate the decapsulated media data.

[0078] According to the example shown, the encapsulation module 320 of the server 300 is used to encapsulate the media data into animation clips, for example, according to ISOBMFF and its extensions (e.g., CMAF, NAL unit-based file formats, etc.). The server 300 then generates a media file or one or more segment files 325, labeled 325. The server 300 can optionally generate a streaming manifest, such as a DASH MPD or an HLS playlist (not shown). The generated file, segment file, or manifest can be stored in a remote storage device, such as a remote storage device 340 accessible via a network, for redistribution via on-demand or real-time streaming.

[0079] According to some embodiments of the present invention, encapsulation module 320 generates encapsulated files (or segments) that allow low-latency and adaptive streaming over HTTP.

[0080] The client 350 is used to process data received from the communication network 330 or read from a (local or remote) storage device, for example, to process the media file or media segment 325. The data can be streamed to the client, thereby involving a streaming module (not shown) that is responsible for parsing the streaming manifest, determining requests to obtain media streams, and adjusting the transmission according to the instructions in the manifest and client parameters (such as available bandwidth, CPU, application requirements or user preferences).

[0081] The received data is decapsulated in a decapsulation module 360 ​​(also referred to 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 (one or more) users. The decoder module (possibly one or more decoder modules for each media type) may be part of the client, may be an external module, or may be dedicated hardware. The decapsulated data may correspond to encoded media data 365 (e.g., a video bitstream, an audio bitstream, etc.).

[0082] Decapsulation, decoding, and rendering may be real-time operations for processing the media files once they are received (e.g., by processing data chunks of the various media streams in parallel and synchronously to minimize delays between the recorded multimedia presentation (as media data 305) and its visualization by (one or more) users as media data 375, e.g., on a screen of his / her device).

[0083] A client or server may be a user device, but may also be a network node acting on the media files being transmitted or stored. A server or client may contain only the encapsulation and decapsulation parts, respectively.

[0084] It should be noted that the media file 325 can be communicated to the client or reader 350 in different ways. In particular, the server or writer (or packager) 300 can generate a media file 325 with a media description (e.g., DASH MPD) upon receiving a request from the client 350, and communicate (or stream) it directly to the client 350. The media file 325 can also be downloaded by the client 350 once or gradually and stored in the client 350.

[0085] For illustration, the media file 325 may encapsulate media data into boxes according to the ISO Base Media File Format (ISOBMFF, ISO / IEC 14496-12) and its derivative specifications (e.g., ISOBMFF, ISO / IEC 14496-15, or the Common Media Application Format (CMAF) ISO / IEC 23001-19 for carrying structured video in NAL units). In this case, the media file 325 may correspond to one or more media files (indicated in a FileTypeBox ("ftyp") box or a SegmentTypeBox ("styp") box). According to ISOBMFF, the media file 325 may include two kinds 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 animation clips. The (one or more) media data boxes contain all the data of the media data 305 or the coded media data 315. There may be one media data box for the multiplexed media data, but there may also be one or more than one media data box, for example one media data box per media type, and possibly one or more than one media data box per animation clip.

[0086] There may be variations in system configuration, especially in Figure 3b or Figure 3c The package side is depicted.

[0087] Figure 3b An overview of a second method for packaging or storing a multimedia presentation according to some embodiments of the present invention is illustrated.

[0088] To illustrate, media file 305-1 is similar to Figure 3a The media file 305 in FIG. 1 and the optional encoder module 310 and the encoded media file 315 are similar to those in FIG. Figure 3a An optional encoder module 310 and encoded media file 315 are depicted.

[0089] As shown in the figure, Figure 3aCompared to the encapsulation module 320 described in the above, the encapsulation module 320' can encapsulate media data from several sources (e.g., media data 305-1 and media data 305-2) in the media file 325' by, for example, adding data from media data 305-2 to media data 305-1, overwriting data from media data 305-1 with data from media data 305-2, or replacing data from media data 305-1 with data from media data 305-2. Media data 305-2 can be, for example, an advertisement to be inserted in the middle of an animation that is media data 305-1.

[0090] Figure 3c An overview of a third method for packaging or storing a multimedia presentation according to some embodiments of the present invention is illustrated, wherein several packaging modules are used to package different media data in a media file 325".

[0091] Still for illustration, media files 305-1 and 305-2 may be similar to Figure 3b 305-1 and 305-2 in the media files, and the optional encoder module 310 and the encoded media file 315 can be similar to the reference Figure 3a The optional encoder module 310 and the encoded media file 315 described in the embodiment of the present invention are shown in FIG. 3. In addition, the writer 300-1 and the packaging module 320-1 can be similar to Figure 3a The writer 300 and the encapsulation module 320 in.

[0092] according to Figure 3c In the example shown, 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 an animation, and 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 a media file 325". Writers 300-1 and 300-2 may be different entities that work independently of each other and may not have any knowledge of each other. Note that writer 300-2 may also include an encoder module (not depicted). Still for illustration, media file 325" may consist of a cascade of media files generated by writer 300-1 on the one hand and media files generated by writer 300-2 on the other hand.

[0093] The packaging module 320-1 in the writer 300-1 can be responsible for packaging the main presentation, and the second packaging module 320-2 in the writer 300-2 can be responsible for packaging additional, replacement, spliced ​​or alternative content. In this case, the operation performed by the second writer can be called "blind" splicing or "late splicing".

[0094] According to some embodiments, as suggested by reference numeral 380, the two writers may share common setup information, such as knowledge of the information written in the "moov" box, such as the initial track or sample configuration. This allows more advanced use cases than blind splicing to be implemented. For example, this allows some tracks to be invalidated, some tracks to be overloaded, some tracks to be kept active, etc. This configuration may be denoted as "non-blind splicing" or "early splicing".

[0095] Packaging of media files according to some embodiments of the present invention

[0096] Figure 4 An example of the steps of the packaging process according to some embodiments of the present invention is illustrated. For illustration, in Figure 3a In the encapsulation module 320, in Figure 3b In the encapsulation module 320', or in Figure 3c Such steps are performed in the encapsulation module 320-1 or 320-2.

[0097] As shown, the first step involves initializing the writer (step 400), e.g. Figure 3a The writer 300, Figure 3b The writer 300' or Figure 3c The configuration may involve the writer 300-1 and / or 300-2. Figure 3a The encapsulation module 320, Figure 3b The encapsulation module 320', or Figure 3c The encapsulation module 320-1 or 320-2 in and the encoder module 310 or (one or more than one) encapsulation module (only when the encoder settings cannot be controlled, such as when the configuration is hard-coded). For illustration, the configuration step may include indicating whether the media file to be generated is a single file or multiple segmented files. The configuration may include defining the granularity of random access in the presentation (e.g., every second, every 2 seconds, etc.), and possibly, for streaming applications, defining switching points and addressable objects in the presentation (e.g., DASH media segments, CMAF segments, CMAF fragments, or CMAF chunks). The configuration may also include indicating whether the media file to be generated is fully dynamic.

[0098] Full-dynamic media files differ from known ISO base media files in that they may not contain the same box hierarchy as defined in ISO / IEC 14496-12. For example, a sequence of objects in a presentation in a full-dynamic media file may not contain exactly one MovieBox, as this is the case with traditional ISO base media files. Typically, an ISO base media file contains a top-level "moov" box that contains one or more "trak" boxes, each of which declares a track (media type, header information) and a sample configuration (e.g., a "stsd" box in "stbl"). Full-dynamic ISOBMFF may not contain a "moov" box. This type of media file that provides dynamic animation clips or dynamic tracks may be indicated using the category "dytk" in ExtendedTypeBox or by using the category "isod" or higher in FileTypeBox ("typyp") or SegmentTypeBox ("styp"). MovieBox "moov" may not be mandatory in full-dynamic media files, for example, with dynamic tracks. However, in this case, the first animation clip loaded may have a FileTypeBox or ExtendedTypeBox indicating support for dynamic tracks (e.g., using the categories proposed above or any category value defined for indicating support for dynamic tracks). The FileTypeBox may even be made optional and replaced by a mandatory SegmentTypeBox instead. A full dynamic media file may alternatively still contain an animation box, but it may not contain track declarations, e.g., only animation header information.

[0099] If the media file to be generated is not a full-dynamic media file (test 401 is false), the writer generates initialization data according to ISOBMFF (step 402), including an "ftyp" box and a "moov" box at the top level of the file. The created "moov" box contains a "trak" box, and the information of the track known at the creation time of the media file is declared for each "trak" box. For a full-dynamic media file, the media file here may contain a specific category indicating that it can contain or support dynamic tracks (i.e., tracks that can be declared later in the file and not necessarily in the "trak" box below the top-level "moov" box). This initialization data can be used as an initialization segment for adaptive streaming use, for example. Then, after initialization, the writer starts to encapsulate data for media presentation. For illustration, it is assumed that the encapsulation is intended to encapsulate first media data (e.g., animation) and second media data (e.g., advertisements or temporary information drawn on top of or along the animation). 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 the time of setup. Therefore, the "moov" box can include track declarations for the first media data, but not for the second media.

[0100] As shown, the encapsulation step may include checking whether second media data is to be encapsulated (test 403), and if no second media data is to be encapsulated, obtaining some first media data (step 404) and encapsulating the obtained first media data (step 407). Encapsulation may include describing samples and indexing corresponding data stored in a media data box (e.g., "mdat" or "imda"). For example, a sample description (e.g., size, data offset, duration and / or composition time) for the first media data may be provided in a "trun" box. The media data thus encapsulated is output as part of a media file (step 408), and the process is iterated until the end of the media presentation (test 409). If the end of the presentation is not reached, the algorithm loops to step 403 to obtain the second media data (if any). If second media data is to be encapsulated, the second media data is obtained and the writer generates a new track configuration (step 406). Reference is made here to Figure 6a and Figure 6b An indication of a track configuration is described. As shown, the first media data may also be obtained in parallel with obtaining the second media data (step 405). After indicating the track configuration, the writer encapsulates the first media data, the second media data, or both the first media data and the second media data (step 407), and outputs the encapsulated media data as part of a media file (step 408). The output may be based on an ISOBMFF fragment basis, a CMAF fragment basis, a CMAF segment basis, or an ISOBMFF segment basis.

[0101] If the media file to be generated is a full dynamic media file (test 401 is false), the encapsulation module generates a minimum set of initialization information items (step 420), for example, only an "ftyp" or "styp" box or an "ftyp" or "styp" with a minimum "moov" box (for example, there is no track declaration therein). Next, the writer obtains the media data to be encapsulated (step 421), i.e., the first media data and / or the second media data, and generates track configuration information for the obtained media data (step 422). In the following, reference is made to Figure 6a and Figure 6b The steps of indicating track configuration are described. Next, the obtained media data is encapsulated (step 423) (including samples describing the different tracks), and the encapsulated media data is output as part of the media file for storage, transmission, or any purpose of using the media file. If the end of the presentation is not reached (step 425), the algorithm loops at step 421. As described with reference to step 409, the output can be based on an ISOBMFF fragment basis, a CMAF fragment basis, a CMAF segment basis, or an ISOBMFF segment basis.

[0102] Parsing of Encapsulated Media Files According to Some Embodiments of the Invention

[0103] Figure 5 An example of steps of a parsing process according to some embodiments of the present invention is illustrated. Note that a client or reader that performs such steps may also be referred to as a "parser", "application", "media player" or "player".

[0104] As shown, the process begins with a media file or a media segment file (possibly with a manifest file, generated according to some embodiments of the present invention, for example, based on the media file or media segment file received from the server or accessed locally) Figure 4 The parser is initialized (step 500) by using the steps shown in the figure. More specifically, the player is initialized using information obtained by requesting the beginning (e.g., the first byte) of the initialization segment or media file. The URL or byte range for the initialization data can be obtained from a manifest file such as DASH MPD or a playlist for HTTP real-time streaming. Based on the obtained initialization information, the player can determine the type of media data present in the media presentation, whether the media file is fully dynamic, the codec in use, etc.

[0105] Determining whether a media file is fully dynamic (step 501) can be based on a category indication (e.g., a "dytk" category in the media file or any dedicated category value for indicating a dynamic track) or by the presence or absence of a "moov" box and the presence of one or more "trak" boxes. For example, if the player detects an "ftyp" or "styp" box without any "moov" box (or has a "moov" without any track declaration), it can be determined that the media file is a fully dynamic media file.

[0106] If the media file is not fully dynamic, the parser reads initialization data (step 502) and instantiates the appropriate decoder to handle the media data requested in subsequent steps. Reading these initialization data, the parser can determine that a change in track configuration or a modification of the presentation may occur (indication in the category, such as using a "dytk" value, where the "moov" box provides a complete track description). Next, the parser obtains the encapsulated media data (step 503), for example, by reading or downloading the data or by using a streaming or progressive transmission mechanism. Note that the data can be obtained at different granularities, for example, as an animation clip, ISOBMFF segment, CMAF fragment, or CMAF segment. Next, the parser checks whether the new track configuration is part of the obtained data (step 504). If there is no track configuration, the parser or reader decapsulates (or parses) samples from each track (step 506) and provides the obtained data to the appropriate buffer, decoder, or renderer (step 507).

[0107] If there is a new track configuration in the obtained data (as determined in step 504), the parser decodes and interprets the new track configuration to determine the current number of tracks and their configuration. Figure 6a and Figure 6b Describes an example of a track configuration. There may be new tracks and / or tracks defined in the "moov" box. Depending on the track, in particular when there are new tracks (i.e. tracks not described in the "moov" box), the parser further checks whether these new tracks have been encountered. If not, the track description may be further checked, for example to obtain a sample description. The track configuration and sample description may affect the set of decoders initialized at step 502. Depending on the track configuration, the parser may need to reset some decoders, or it may be inferred from the track configuration that some previous configurations may be reused without any reset. The parsing process is repeated until the end of the encapsulated media file is reached (i.e. if the end of the encapsulated media file has not been reached, the algorithm loops at step 503).

[0108] If the parser determines that the media file is fully dynamic (step 501), then the decoder may not be set up immediately. The parser obtains more data (step 520), such as by reading, downloading, or using a streaming mechanism. Again, this data can be obtained at different granularities, such as as animation clips, ISOBMFF segments, CMAF fragments, or CMAF segments. Figure 6a and Figure 6b As illustrated, for fully dynamic tracks, the parser processes the track configuration (step 521). Based on the track configuration, the parser can determine the current number of tracks and their characteristics (step 522). Note that when encountered for the first time, the track configuration may cause a certain decoder to be initialized. When already encountered by the parser, the track configuration may consist in reusing a decoder configuration that has already been assigned or set (e.g., in a previous step 522). After handling the track configuration, the parser or reader parses the samples (step 523) to obtain the corresponding data, and outputs the data to a buffer, decoder, or renderer depending on the application using the media file (step 524). As shown, the process iterates until the end of the presentation is reached (i.e., if the end of the presentation is not reached, the algorithm loops at step 520).

[0109] Dynamic rail indication

[0110] Figure 6a and Figure 6b An example of box-based information for indicating dynamic track configurations in a media file is illustrated. This involves two aspects. The first aspect is intended to define a metadata structure that fits in an ISOBMFF box to indicate a track configuration change (step 406) or a new track configuration (step 422). This signaling should also allow random access: whenever a player or reader starts parsing (or tuning to) a media presentation, the player or reader should be able to obtain the current track configuration. This means that the indication of the track configuration should be repeated. The second aspect is intended to provide an indication as to whether the track configuration has changed (i.e., simply repeated). The second aspect can also provide an indication of the extent of the track configuration change, such as a "minor" change (also known as functionally equivalent), or a "significant" change that may require the parser or reader to handle a reset or update of the decoder configuration.

[0111] To handle changes, the options could have relied on versions of the box: the same version number would indicate a duplication, but this conflicts with box versioning and some boxes do not even have a version field, like the UserDataBox. Furthermore, this is not the intended purpose of box versions (to indicate changes in the binary syntax rather than changes in the payload). One approach to address this second aspect could be to do a comparison of past and current boxes, typically through a hash function. While this allows detecting identical configurations, it has several disadvantages as it is expensive in terms of client resources (additional processing and memory requirements) and does not allow signaling of duplicate configurations with slight changes (e.g. in metadata) that do not require re-parsing of the data. Therefore, a change detection mechanism needs to be introduced to indicate track configuration changes in animation fragments (e.g. dynamic tracks or sample description changes) so that a parser or reader can correctly identify duplicate information across fragments.

[0112] Finally, although a sample can be signaled as a repeating sample using a dependency flag, ISOBMFF lacks support for such signaling for non-sample data (metadata or box structure). There is a mechanism that allows configuration information for media presentation to be sent. For example, the DSM-CC (ISO / IEC13818-6) standard specifies data carousels and object carousels. Object carousels extend the more limited data carousel 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, but this feature is not available in ISOBMF. According to the illustrated embodiment, a DynamicMovieBox (marked as 600) that can be contained in a movie clip ("moof" box (not shown)) is defined, and the DynamicMovieBox contains zero or more DynamicTrackBoxes (marked as 601), each DynamicTrackBox contains a specific DynamicTrackHeaderBox (marked as 602), and some common boxes found in the TrackBox (e.g., "stsd", "trgr", "tref", etc.).

[0113] Dynamic animation frame

[0114] A DynamicMovieBox 600 may contain zero or more than zero UserDataBoxes 620 or MetaBoxes 630 as defined in ISOBMFF. A DynamicMovieBox 600 is identified by a 4CC code, such as "dymv" or any dedicated 4CC reserved for this use and not conflicting with existing 4CCs.

[0115] DynamicMovieBox completely or partially overrides the MovieBox settings (track list, user data or meta) of a given fragment. The MovieBox settings may also be referred to as "track configuration". The mode (partial or complete override of track configuration or extension of track configuration) may be indicated in the parameters of the DynamicMovieBox box (e.g., a flag or field within a Box or FullBox). The parameter may be referred to as, for example, "source_id" or "rousel_id". For example, the parameter may be an identifier of a presentation and / or may be repeated along a presentation or portion (time interval) of a sequence. Each DynamicMovieBox may have an associated source_id, which indicates how the animation fragment extends or modifies the initial MovieBox ("moov") or a previous DynamicMovieBox ("dymov"). A source_id equal to 0 may indicate that the MovieBox is extended by the animation fragment. A source_id different from 0 may indicate that the MovieBox is ignored (i.e., it is considered to not exist or no longer be active for a given animation fragment).

[0116] For example, this parameter of the DynamicMovieBox box can be set by the encapsulation module to indicate the presence of the following field, where the field allows the player to be informed whether the track configuration is a duplicate, whether the track configuration supplements, overloads or invalidates the track configuration that may be present in the "moov" box or in the previous animation clip. This box can be present in the animation clip or can only be present in the first animation clip of an ISOBMFF segment (for example, a segment with dependent animation clips). In this way, there can be zero or more DynamicMovieBoxes in the media file, but no more than one DynamicMovieBox for each MovieFragment Box ("moof"). When used in the first animation clip of a segment that contains a dependent animation clip, the dependent animation clip can also inherit the track declarations (DynamicMovieBox, DynamicTrackBox, DynamicTrackHeaderBox) from the first animation clip, in addition to other properties of the first animation clip.

[0117] For DynamicMovieBox, the following flags can be defined:

[0118] -0x000001, source-info-present, if set, indicates the presence of source information (or carousel-like or carousel information); if not set, both source_id and source_flags take the value 0. Source information, "carousel-like" or carousel information corresponds to information that can be repeated in an animation clip.

[0119] -0x000002, for in-splice, if set, indicates that the track described in the DynamicMovieBox corresponds to a content splicing period, which will soon be moved back to the previous configuration. By monitoring this flag and the source_id field, the media pipeline can be optimized if necessary (e.g., to avoid unloading / reloading, e.g., decoder resources). If source_id is 0, this flag should not be set. This is because source_id=0 indicates some continuity in the initial presentation (e.g., in the presentation timeline).

[0120] A DynamicMovieBox with a source_id different from 0 may contain zero or more DynamicTrackBoxes. When dynamic tracks are used, the first track fragment ("traf") of each track in the parent animation clip ("moof") should have a TrackFragmentBaseMediaDecodeTimeBox ("tfdt") box present. This can facilitate time adjustments between two different presentations by a reader or player. When the encapsulation module inserts a DynamicMovieBox with a source_id different from 0 in an animation clip, it can indicate to the player or reader that there may be a discontinuity between the two animation clips (e.g., in the presentation timeline). It can be used as an indication to the player or reader to forget a previously encountered source_id (along with the corresponding decoder configuration) that may have been recorded, because the encapsulation module can reuse its previously used source_id. Therefore, a DynamicMovieBox with a source_id different from 0 and without any DynamicTrackBox is an indication that there is no continuity between the values ​​of the source_id before and after the animation clip containing such a DynamicMovieBox.

[0121] Alternatively or as a variation of flag value 0x000002, a third flag value (eg, 0x000004) may be used to indicate that, when set, the track configuration is temporary and will soon move back to the "moov" configuration.

[0122] Alternatively or as a variation of the flag value 0x000002, another flag value (eg, 0x000008) may be used to indicate that, when set, the track configuration is temporary and will soon move back to the track configuration of the previous animation clip.

[0123] With these additional flag values, a parser or reader can have a finer handling of the decoder configuration and can decide to buffer more or less configuration to avoid some decoder resets and possible display freezes. For example, when the flag value 0x000004 is set, this means that the decoder can keep only the initial decoder configuration (corresponding to the configuration derived from the "moov" box).

[0124] Example of DynamicMovieBox syntax

[0125] According to a first example, fields and boxes are mixed as follows:

[0126]

[0127] According to the second syntax example, the DynamicMovieBox box contains only boxes and, therefore, can inherit from Box instead of FullBox:

[0128]

[0129] In the case where DynamicMovieBoxHeader is a Box or FullBox that provides fields equivalent to source_id and source_flags from the first example, DynamicMovieBoxHeader can be defined as follows:

[0130]

[0131]

[0132] When DynamicMovieHeaderBox is not present, a parser or reader may assume that the new track configuration simply indicates that the "moov" configuration applies to the movie clip. DynamicMovieHeaderBox may contain additional parameters that provide parameters that apply to all tracks within the new track configuration, such as a time scale or language or transform matrix (as in MovieHeaderBox "mvhd") indication.

[0133] The semantics of DynamicMovieBox can be defined as follows:

[0134] Figure 6aThe source_id (or carousel_id, the names are examples only) marked as 604 in the source_id field identifies the origin (e.g., presentation) of the movie clip. If source_id is set to 0, the DynamicMovieBox changes the MovieBox (e.g., invalidates, rewrites, adds or replaces some tracks, or changes sample descriptions or high-level metadata). Otherwise, all tracks, user data, and possible high-level metadata declared in the MovieBox should be ignored. In other words, when the value of this field is different from 0, the DynamicMovieBox indicates a new track configuration or a new presentation of one or more movie clips (as many times as the value is repeated in the movie clip). When set to 0, this field can be regarded by a parser or reader as an indication that the media or presentation maintains the same timeline and the same set of track identifiers as in "moov", where new ones or some are overwritten. When different from 0, this field can be interpreted by a parser or reader as a complete change in the track configuration that may change with the presentation timeline. Assume, for example, that the default value of source_id is 0 when there is no declaration.

[0135] exist Figure 6a The source_flags (or carousel_flags, the names are examples only) marked as 605 in the DynamicMovieBox parameter identifies the modifications declared in this DynamicMovieBox compared to the previous DynamicMovieBox (if any) with the same source_id value. The following flags may be defined to be set or combined in the value of the source_flags parameter:

[0136] - 0x00000001 (if set) indicates that one or more tracks have changed. For example, one or more tracks have been added, overloaded, or invalid (temporarily removed).

[0137] - 0x00000002 (if set) indicates that the global user data (e.g. in a "moov" box or in a DynamicMovieBox "dymov" box, e.g. a user data box for the entire presentation) has changed,

[0138] - 0x00000004 (if set) indicates that a global metabox (e.g., metadata for the entire presentation in a "moov" box or in a DynamicMovieBox "dymov" box) has changed,

[0139] - 0x00800000 (if set) indicates that the modification (to presentation or track configuration) is functionally equivalent to a previous DynamicMovieBox with the same source_id. In this case, a file reader or parser can safely skip processing the DynamicMovieBox if the previously parsed DynamicMovieBox has the same source_id. In other words, a reader or parser can decide not to parse the track configuration indicated in a DynamicMovieBox with this flag value set when it has already processed a DynamicMovieBox with the same source_id. This flag also indicates that the player can safely continue to use the decoder configuration, avoiding decoder handling such as resetting or reinitializing to another configuration (codec change, profile or level change, etc.) and skipping Figure 5 0x00800000. Note that when source_id is equal to 0, the value of source_flags may be set to 0 or 0x00800000. This is because source_id equal to 0 means that the presentation declared in "moov" is active (is the current presentation), and then, if a DynamicMovieBox is used to indicate a track configuration change, no further indication is needed, e.g. that the track configuration has changed (because the player must handle it), unless that track configuration has already been encountered and the flag value 0x00800000 is set. The value of source_flags may be set to 0x00800000, but should be ignored (i.e., considered not set) by the file reader when a previous DynamicMovieBox had a different source_id or when this is the first DynamicMovieBox parsed.

[0140] A change in the source_id value between two consecutive animation fragments N and N-1 in a single byte sequence (file, remote resource, etc.) is an indication 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, the timeline is not guaranteed to be continuous between fragments N and N-1. Whether and / or how the file reader reconstructs the continuous timeline in this case (e.g., between fragments N and N-1) depends on the implementation (i.e., may not be standardized) and may be driven by processing pipeline capabilities. However, for these reconstructions, the implementation should avoid introducing long playback gaps at the source_id change points. For example, the parser or reader may decide to recalculate the timing (e.g., by using sample descriptions, by "tfdt" or any box for timing indications, by using some edit list, etc.).

[0141] If two consecutive animation clips N and N-1 have the same value for source_id, the timelines of all tracks active in these two fragments can be interpreted by a reader or parser as continuous, and the constraints on the TrackFragmentBaseMediaDecodeTimeBox of each track can be respected: for track fragments with the same trackID, the first "tfdt" in animation clip N is equal to or greater than the first "tfdt" in animation clip N-1 plus the sum of the sample durations in animation clip N-1. If several tracks need to be inserted or replaced, these tracks can all be declared in a single DynamicMovieBox, each track in its own DynamicMovieBox, or according to a mix of these two approaches.

[0142] If a track from a MovieBox is not listed for update or removal in one of the DynamicTrackBoxes of a DynamicMovieBox with a source_id value of 0, the track is considered still valid, but there may be no track fragment for it in the movieclip, as is the case for regular movieclip.

[0143] In a variation, DynamicMovieBox 600 can be a top-level box for a segment or fragment. This allows the declaration of track configurations to be varied across multiple movie clips. This may be suitable for encapsulation where there is one track per movie clip. This may not be suitable for encapsulation where one "moof" contains all tracks. The same fields and sub-boxes can be used in a DynamicMovieBox declared as a top-level box. Another variation is to indicate (e.g., Figure 4 420 in step 420) or identification (e.g., Figure 5 501 in step 502) The media file is fully dynamic (instead of the "moov" box when one of the top-level boxes is a DynamicMovieBox). When a DynamicMovieBox 600 is used as the top-level box, the SegmentIndexBox (when present) may reference the start of the DynamicMovieBox (instead of the "moof" box, or in addition to the "moof" box). This may be indicated by a special (new value) reference_type in the "sidx" box.

[0144] Dynamic rail frame

[0145] like Figure 6aAs shown, DynamicTrackBox 601 can contain zero or more than zero boxes. DynamicTrackBox 601 is identified by a 4CC code (e.g., "dytk" or any dedicated 4CC reserved for this purpose and not conflicting with an existing 4CC). DynamicTrackBox 601 provides a lighter track declaration than the "trak" box and its child boxes. Since DynamicTrackBox 601 can be repeated along the media presentation, some fields or child boxes may not always be present, thereby providing a more compact track description than the track description in the "moov" and "trak" boxes. DynamicTrackBox declares a new track or modifies (e.g., partially or completely overwrites) or replaces an existing track for the duration of the parent animation clip.

[0146] Tracks declared by a DynamicTrackBox and for which no track with a matching track_ID exists in the MovieBox implicitly declare a TrackExtennsBox with the value default_sample_description_index set to 1 and the values ​​default_sample_duration, default_sample_size and default_sample_flag set to 0. In addition, tracks declared by a DynamicTrackBox and with an associated source_id not equal to 0 may also implicitly declare these boxes. This allows default values ​​for the track runs boxes describing the samples of these tracks to be defined. Note that the default values ​​may need to be set in the TrackFragmentHeaderBox (since there is no explicit TrackExtennsBox); if multiple track fragments are used for dynamic tracks within a movie clip, the default values ​​may need to be re-encoded for each track fragment. Zero or more DynamicTrackBoxes 601 may be contained in a DynamicMovieBox 600. A DynamicTrackBox contains a DynamicTrackHeaderBox (in Figure 6a and Figure 6b 602).

[0147] A variation of the implicit declaration of TrackExtendsBox is to declare it in a "dymv" box. Combined with a source_flags value (a special value indicating that the "trex" or default values ​​used by a clip do not change between clips or segments), this can indicate when the default values ​​change from one clip to another or still apply.

[0148] The semantics of DynamicTrackBox can be defined as follows:

[0149] data_info, if present, gives the source or location of the sample data for this dynamic track. If not present, the sample data exists in a container (MediaData box). The location of the data may be indicated by a URL or URN or any kind of data entry that inherits from DataEntryBaseBox, and

[0150] minf_header_info, if present, gives the media specific header box normally found in the MediaInformationBox of a track with the same handler_type as this dynamic track. An exported specification may enforce its presence. minf_header_info may be any of the specific media handlers ("vmhd", "smhd", "hmhd", "sthd", "nmhd", "vvhd", etc. defined by ISOBMFF, or an exported specification).

[0151] Except for the DynamicTrackHeaderBox described below, the other boxes contained in DynamicTrackBox have unchanged semantics compared to the boxes specified in ISO / IEC 14496-12. When present, these boxes replace their corresponding boxes in the TrackBox (and subboxes) of the MovieBox or previous DynamicTrackBox.

[0152] Dynamic Rail Header Box

[0153] Figure 6b Instantiates DynamicTrackHeaderBox (e.g. Figure 6a. An example of the syntax of a DynamicTrackHeaderBox 602 in a MovieBox. A DynamicTrackBox may be used to disable an existing track from a MovieBox (or an existing track from a previous DynamicMovieBox), overwrite or replace the definition of an existing track from a MovieBox (or an existing track in a previous DynamicMovieBox), or define an entirely new track. As shown, a DynamicTrackHeaderBox 602 may contain a track identifier (e.g., track_ID) and overall information about the track. A DynamicTrackHeaderBox 602 is identified by a 4CC code (e.g., "dtkh" or any dedicated 4CC that is reserved for this purpose and does not conflict with an existing 4CC). A DynamicTrackHeaderBox 602 provides a track header declaration that is lighter than the sub-boxes of the "tkhd" box and the "trak" box. Since a DynamicTrackHeaderBox 602 may be repeated along a media presentation, some fields or sub-boxes may not always be present, thereby providing a more compact track description than the track description in "moov". In other words, DynamicTrackBox can be viewed as a compression of TrackHeaderBox, EditListBox, and MediaHeaderBox in a single container to keep the track signaling overhead low.

[0154] DynamicTrackHeaderBox is contained in each DynamicTrackBox.

[0155] The following flags may be defined for the dynamic track header box (values ​​of the Flags field 602-1 of DynamicTrackHeaderBox):

[0156] 0x000001, denoted as ignore_track (or dyn_tk_ignore_track), which when set indicates that the track declared in the MovieBox or in a previous DynamicMovieBox with the same source_id as the parent DynamicMovieBox should be ignored (treated as if not present) until the next movie clip is received for that track.

[0157] This flag value can be used, for example, in "non-blind splicing" mode.

[0158] If the flag value 0x000001 (ignore_track or dyn_tk_ignore_track) is not set in the DynamicTrackHeaderBox, the parent DynamicTrackBox overwrites the existing track or declares a new track. In this case:

[0159] - If a "stsd" box exists in the parent DynamicTrackBox: if a track with the same ID exists in the MovieBox, overwrite it with the current track, otherwise add the new track to the presentation,

[0160] ○ Note 1: The exported specification can force the handler type / timescale / width / height to remain the same in which case,

[0161] ○ Note 2: This is usually used to update the sample description of the track,

[0162] - If the "stsd" box does not exist in the parent DynamicTrackBox: A track with the same ID should exist in the MovieBox, and all fields in the DynamicTrackHeaderBox should match their corresponding fields in the track / handler / media header box declared in the MovieBox. This can be used to update the UserDataBox, MetaBox, TrackReferenceBox or TrackGroupBox of the track. In this case, the sample description of the track remains unchanged. With such an indication, the player or reader can assume that no decoder reset is required. Additional flag values ​​can be defined to indicate that the track header has changed but remains functionally equivalent to the previous occurrence of the track header (the same track_ID in "dytk" within "dymv" with the same source_id value). For some values ​​for DynamicMovieBox or DynamicTrackBox, the value 0x800000 can be used here. This can be used, for example, when volume information changes or when some parameters that do not affect the decoder configuration have changed. For the case where there is no "stsd" box, a dedicated flag can also be used to avoid re-listing elements that match those of the "moof" track.

[0163] The semantics of DynamicTrackHeaderBox can be:

[0164] track_ID indicates the ID declared by the track. track_ID can be a track_ID already declared in the TrakBox under the moov box (for track removal or track overloading) or a new track_ID (for track addition).

[0165] modification_flags 602-2 identifies the modifications in the parent DynamicTrackBox compared to the previous DynamicTrackBox in the parent DynamicMovieBox with the same track_ID value and the same source_id value. Readers can use these flags to optimize the handling of consecutive track fragments with the same track_id and source_id.

[0166] The following flags may be defined (for modification_flags 602-2):

[0167] - 0x000001: The track configuration has changed (a change in one or more fields other than modification_flags in DynamicTrackHeaderBox, a change in an associated media header box ("vmhd", "smhd", etc.) or a change in an associated data info box),

[0168] -0x000002: The media configuration has changed (e.g., new sample description),

[0169] -0x000004: Track UserDataBox has changed,

[0170] -0x000008: Track MetaBox has changed,

[0171] -0x000010: TrackReferenceBox has changed,

[0172] -0x000020: TrackGroupBox has changed.

[0173] -0x800000: Track modification is functionally equivalent to the previous DynamicTrackBox with the same track_id and source_id. This flag may be set by the encapsulation module in 602-2, but the file reader should ignore this flag (i.e., treat it as not set) when the previous DynamicMovieBox had a different source_id or when this is the first DynamicTrackBox parsed for this track_id and source_id. When modification_flags is not set (explicitly or according to the above rules) or has a value of 0, there is no available information about possible changes to the track compared to the previous DynamicTrackBox with the same track_id and source_id, and the entire contents of the DynamicTrackBox must be re-evaluated.

[0174] handler_type is the same as the handler_type in HandlerBox.

[0175] media_timescale is the same as the time scale in MediaHeaderBox,

[0176] delay indicates the media delay of the track in media_timescale. The presentation time of any sample in the track is the sum of the composition time of the sample and this value. A negative presentation time indicates that (part of) the sample data should not be presented (a media skip), and a value of 0 can be used by a parser or reader if it is not encoded.

[0177] track_flags is the same as the flags in TrackHeaderBox. If this field is not encoded and there is no matching track with the same track_ID in MovieBox, the field value is inferred to be 0x000003,

[0178] language is the same as the language in MediaHeaderBox.

[0179] extended_language is the same as in ExtendedlanguageBox,

[0180] alternate_group is the same as in TrackHeaderBox,

[0181] width is the same as in TrackHeaderBox, or if not encoded the media width after pixel aspect ratio and clean aperture are applied.

[0182] height is the same as in TrackHeaderBox, or if not encoded, the media height after applying pixel aspect ratio and clean aperture.

[0183] layer is the same as in TrackHeaderBox. If not encoded, layer 0 is used.

[0184] matrix is ​​the same as in TrackHeaderBox, if not encoded, the same matrix is ​​used, and

[0185] volume is the same as in TrackHeaderBox, or the full volume (1.0) if not encoded.

[0186] When using from Figure 6a and Figure 6bIn the simple case, signaling a new track may cost STSD to add:

[0187] -12 bytes for the DynamicTrackHeaderBox header,

[0188] - 17 bytes for audio (without volume), 27 bytes for video with size / layer and without track matrix (63 with matrix),

[0189] - 8 bytes for the DynamicTrackBox header, and

[0190] - 12 bytes for the DynamicMovieBox header.

[0191] The overhead for a one-second segment is estimated to be approximately 0.392kbps for audio and 0.47kbps for video (0.76kbps if the full visual matrix is ​​specified), so approximately 1.3kbps for full signaling (tracks and "stsd"), compared to more than 4kbps if the new track would be described with a classic TrackBox.

[0192] According to some embodiments of the present invention, for a one second segment, the signaling indicating the removal of a track is estimated to be 12 plus 4 plus 8 plus 12 bytes, or 0.288 kbps.

[0193] Furthermore, the proposed box allows efficient signaling of track additions, providing a unified method to add tracks or change codec configurations in a presentation. The proposed box allows track removal (or signaling temporarily invalid or inactive tracks), and various flags in DynamicMovieBox or DynamicTrackHeaderBox allow parsers or readers to easily detect repeated or changed track configurations as well as temporary changes in track configurations, such as splicing periods (time intervals where a new presentation replaces a previous presentation (e.g., an advertisement in an animation)).

[0194] The proposed box can be combined with a animation clip that will depend on a referenced animation clip. Assume that such a dependent animation clip will be signaled by a specific version, for example as follows:

[0195] extends FullBox('mfhd',version,0){

[0196] unsigned int(32)sequence_number;

[0197] }

[0198] If the version is not 0, any SampleGroupDescriptionBox, DynamicTrackBox, or MetaBox defined in the last MovieClip or the last TrackFragment in the last MovieClip whose MovieFragmentHeaderBox version is 0 also applies to this MovieClip, and there should not be any SampleGroupDescriptionBox, DynamicTrackBox, or MetaBox defined for this MovieClip. Note that the flags field can be used as a variation of the version field. This may be more convenient if you need to extend the MovieFragmentHeaderBox with new fields (preferably contained in the version number). .

[0199] Example of rail removal

[0200] Figure 7 An example of a track configuration that invalidates a track declared in a "moov" box is illustrated. In this example, two tracks represented as 700 and 701 are initially declared in the "moov" (705) and "trak" (710, 720) boxes, where track_ID = "i" and "j". As shown, the tracks are fragmented into 700-5 and 701-1 to 701-5 in animation clips 700-1, 700-2, etc. These tracks are initially described in the "trak" boxes 710 and 720 in the "moov" box 705. For example, these tracks may correspond to a first media source or presentation that may be considered a primary media source (e.g., an animation or a live sporting event).

[0201] From animation clips 700-3 and 701-3, a new track configuration is indicated in the media file (in the "moof" box 730) to invalidate the tracks (with track_IDs "i" and "j") declared in the "moov" box 705. The new content marked 706 can be used with, for example, Figure 4 4. The new track configuration is signaled in the media file as DynamicMovieBox 730-1 and is repeated in DynamicMovieBox 731-1 (as indicated by the same source_id value) and DynamicMovieTrackBox boxes 730-2 and 730-3 and DynamicMovieTrackBox boxes 731-2 and 731-3. As shown, DynamicMovieBox 730-1 has an overwritten field indicating the initial configuration that was set. Figure 7In the example of , this corresponds to a source_id field having a value different from 0 (here 1). DynamicMovieBox 730-1 indicates, for example in the source_flags field, what the changes to this movie clip (if any) are. In this example, the value can be set to 0, indicating that no further information on track configuration changes is provided in the DynamicMovieBox. In fact, since this is the first occurrence of a "dymv" box with this identifier (source_id) value, the indication of what information exists or may have changed can be omitted (e.g. source_flags=0). The indication to the player or reader is that this first occurrence should be processed regardless of the indication of changes through the source_flags field (here 0, but it may take different values).

[0202] The two DynamicTrackBoxes labeled 730-2 and 730-3 declare new tracks with track_ID="k" and "l". These two boxes have modification_flags in their headers indicating no changes (0 or 0x800000) because this is the first occurrence of this track ID for this source_id (or presentation). The value 0 is an indication that the player or reader should process the track descriptions (parameters in "dytk" 730-2 or 730-3 and "dtkh" 730-21 or 730-31). The sample descriptions of these new tracks are provided in the "stsd" boxes 730-22 and 730-32. The sample descriptions provide the player or reader with information, such as about codecs, profiles, or level values ​​to set up its decoder. These sample descriptions may require a decoder to reset or create a new decoder configuration to handle the samples of these new tracks "k" or "l".

[0203] Next, for each segment up to segment 700-4 and 701-4, the track configuration is repeated to provide random access. However, in order to avoid useless processing of players that have started at or before segment 700-3 and 701-3, source_id is kept at the same value (here 1) in DynamicMovieBox box 731-1 and source_flags can be set to 0x800000 (or even 0) to indicate that the track configuration is the same as the previous track configuration defined in DynamicMovieBox box 730-1 with the same source_id value (here 1). Using 0 or 0x800000 results in the same parser or reader behavior: if the track configuration with this source_id value has been processed, the boxes indicating and describing the track configuration (DynamicMovieBox731-1 and its sub-box 731-3) can be ignored. Using 0x800000 will provide more detailed information than the value 0, thereby indicating that the track configuration may have changes, but these are minor configurations. For example, the modification concerns high-level metadata or user data but does not affect the number of tracks or the configuration of (one or more) decoders. Similarly, the details of the track information in the DynamicTrackBox box 731-2 or 731-3 indicate that modification_flags is 0x800000, indicating that the track configuration is almost the same as in the previous segment or at least that it does not require a decoder reset or reconfiguration. The "stsd" boxes 730-22 and 730-32 are still present for a player or reader to randomly access the animation segment 700-4 or 701-4 to obtain a sample description of track "k" or "l". Although attention has been paid here to the possible values ​​of source_id, source_flags or modification_flags, it should be noted that other parameters from DynamicTrackBox or DynamicTrackHeaderBox (for example in Figure 6a and Figure 6b Parameters shown above, not shown for clarity) can also be specified in these boxes. It should also be noted that when fragments 700-4 and 701-4 are dependent animation fragments (because the player cannot randomly access the bitstream starting from these fragments), the presence of "stsd" boxes 730-22 and 730-32 may be optional.

[0204] For the movie clip from 700-5 or 701-5, there is no DynamicMovieBox box, which can be used as an indication to the player or reader to consider the configuration defined in the "moov" box 705 to apply or restore or be restored. If the player or reader has saved the decoder settings for track "i" or "j", it can (for example in Figure 5 505 or 522 in the "moov" box 705) to restore the setting to the previous configuration (or if the player or reader maintains several configurations, the setting can be switched from one configuration to another). It should be noted that the player or reader can decide to store the decoder configuration depending on the value of the flag field of the DynamicMovieBox box 730-1 or 731-1. In this example, the flag value is set to 3 (0x000003), which means that the configuration change is temporary and can return to the previous configuration (here the configuration defined in the "moov" box 705). It should also be noted that additional values ​​defined in the variants described about DynamicMovieBox can also be set here. In addition, 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 have been set to 0, thus avoiding the declaration of modification_flags, especially for fragments 700-3 and 701-3 (the first occurrence of a new track declaration). In the case where source_flags in the parent "dymv" is not 0 or 0x800000, it may be useful to have a flag value equal to 2 in the DynamicTrackHeaderBox in the consecutive fragment to further indicate a change in track configuration at the track level.

[0205] To be clear, not all DynamicMovieBox and DynamicTrackBox are represented in Figure 7According to some embodiments of the present invention, each animation clip that appears between animation clip 700-3 or 701-3 and animation clip 700-4 or 701-4 should have a DynamicMovieBox box, with one DynamicTrackBox box for each track. It should also be noted that when no changes occur in the corresponding tracks from one animation clip to another that require the decoder to be reinitialized, the modification_flags value in the repeated occurrences of the DynamicTrackBox between animation clip 700-3 or 701-3 and animation clip 700-4 or 701-4 can have a value set to 0 or 0x800000. If changes occur, the value of modification_flags should be set accordingly. Using the value 0x800000 instead of 0 brings some flexibility in the following sense: the value 0 will indicate no change at all, while the value 0x800000 will indicate a "slight" change, at least without resetting the decoder. Of course, the values ​​0 or 0x800000 are examples, and other values ​​can be used for the same purpose as long as they are designated for that purpose. In addition to the track_ID which can also refer to the track_ID from the "dytk" box included in the animation clip, the usual boxes within the "moof" box (such as "traf", "trun", etc.) are not described, because these boxes apply as defined by ISOBMFF. Figure 7 In the example of , the "traf" box references tracks "k" and "l" of segments 700-3 to 700-4 and 701-3 to 701-4, respectively. This animation segment sequence 706 represents a second presentation (eg, an advertisement) spliced ​​into a first or primary presentation (eg, an animation).

[0206] Figure 8 800-1 to 800-6. Track 800 is declared with its corresponding TrackBox 810 and sub-boxes.

[0207] At some point in the presentation timeline corresponding to the animation clip 800-2, the first new track (track 801 with track_ID="k") is added. This track also consists of one or more animation clips 801-2 to 801-4. This addition of a new track is indicated by the encapsulation module having DynamicMovieBox 830-1. The DynamicMovieBox has a flag value set to 1 to indicate that there is a source_id value. The source_id is set here to the value 0 to indicate that the track configuration declared in "moov" 805 is modified, where the new track 801 described in DynamicTrackBox 830-2 and DynamicTrackHeaderBox830-21 is added here. The source_flags parameter of DynamicMovieBox 830-1 can be set to 0 (no indication of a track configuration change) or to 1 to indicate that the change is a change in the number of tracks. The DynamicMovieBox contains a DynamicTrackBox 830-2, which itself contains a DynamicTrackHeaderBox 830-21 and at least one sample description box "stsd" 830-22. The flag value set to 2 in the DynamicTrackHeaderBox 830-21 indicates that further information about track modifications is provided in the modification_flags parameter. Here, the value 0 or 0x00800000 indicates that no significant modification has occurred because this is the first time it has occurred. An alternative could be to encode a flag value of 0 for the DynamicTrackHeaderBox 830-21 without indicating modification_flags. The "moof" 830 contains a "traf" box 830-3 that references the new track (with track_ID="k"), and its associated media data box 830-4 is also placed in the media file. Finally, the animation clip for track "i" is also available as "moof" 810-1 and its associated media data box 810-2. The animation clip 810-1 does not require a specific designation such as "dymv", "dytk" or "dtkh".

[0208] Later in the presentation timeline, at a time corresponding to animation clip 800-3, another added track 802 is introduced, which has track_ID="j". The animation clips described for this time period are animation clips for tracks "i" (not represented, as in the classic "moof" box of 810-1 and the "mdat" box of 810-2), "j" (832) and "k" (831). Animation clip 831 contains a DynamicMovieBox 831-1 with a source_id (e.g., equal to 0) indicating that the track configuration from "moov" is modified again (e.g., a track is added here). The source_flags of DynamicMovieBox 831-1 are set to 1 to indicate that there is a change in the track configuration: a new track "j" marked as 802 is added. DynamicTrackBox 831-2 repeats the sample description to allow random access, and its DynamicTrackHeaderBox labeled 831-21 indicates that no modifications have occurred for track "k" since the last animation segment of the DynamicMovieBox with 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 provide associated media data in the "mdat" box 831-4. "moof" 832 contains a DynamicMovieBox 832-1 with source_id set to the value 0 to indicate a change in the track configuration. source_flags can be set to 1 to indicate a change in the number of tracks, i.e., the addition of track "j". DynamicMovieBox 832-1 contains DynamicTrackBox 832-2, which itself contains DynamicTrackHeaderBox 832-21 with a flag that may be set to 0 (because it is the first occurrence for track_ID="j"). Dynamic TrackBox 832-2 also contains a sample description in a "stsd" box 832-22 for a player or reader to obtain information about the samples, about the codec in use, etc. Finally, "moof" 832 contains one or more "traf" 832-3 boxes referencing the new track "j" as well as other fragment related boxes defined by ISOBMFF (such as "trun", etc.) and their associated media data boxes 832-4.

[0209] At the time corresponding to animation clip 800-4, there are still two new tracks "j" and "k". The dynamic animation box exists in its corresponding "moof" box (not shown). The flags for the DynamicMovieBox still also have source_id set to 0 and source_flags set to 0 to indicate that the track configuration from 800-3, 801-3 and 802-3 is repeated in the current time interval. Each DynamicMovieBox has a DynamicTrackBox with flags set appropriately to indicate, for example, that no changes have occurred. Sample description boxes 830-22 and 832-22 still exist in their corresponding DynamicTrackBoxes to ensure random access at the time corresponding to animation clip 800-4.

[0210] At the time corresponding to animation segment 800-5 or 802-5, track "k" no longer exists. Therefore, DynamicMovieBox 834-1 (in the "moof" box 834) indicates the change in the number of tracks (track "k" no longer exists) with source_id=0 and source_flags=1. DynamicMovieBox 834-1 contains DynamicTrackBox 834-2 with sample description 832-22 (repeated from segment 802-3), which may have other boxes (not shown). DynamicTrackBox834-2 contains DynamicTrackHeaderBox834-21 with flag=2 to indicate the presence of modification_flags. modification_flags with a value of 0x00800000 indicates that no "significant" changes have occurred for this track "j". Then, classic blocks "traf" 834-3 and "mdat" 834-4 follow to provide descriptions and data (in 814-1 and 814-2) of the samples of segment 802-5 and the samples of segment 800-5.

[0211] At the time corresponding to animation clip 800-6, only the tracks from the "moov" box are retained. No dynamic animation box or dynamic track box is required, and the track configuration automatically switches back to the track configuration declared in the "moov" box 805.

[0212] Except that the new tracks 902 and 901 are declared in a single "moof" box (similar to tracks 802 and 801), Fig. 9 Illustrated with Figure 8900-3 or 900-4, there are two new tracks "j" and "k", and the "moof" box 931 contains a DynamicMovieBox 931-1, which itself contains two DynamicTrackBoxes 931-2 and 931-3. DynamicTrackBoxes 931-2 and 931-3 each contain a DynamicTrackHeaderBox labeled 931-21 and 931-31, respectively, and sample descriptions labeled 931-22 and 932-22. The values ​​of their flag fields are set to 2 (to indicate modification_flags) and 0 (first appearance), respectively. The modification_flags for track "k" is set to 0 or 0x00800000 to indicate that there is no change in the track, that is, the continuation of the track. Next, each track "j" and "k" has its "traf" labeled as boxes 931-4 and 931-5, respectively, and an associated "mdat" box 931-6. For clarity, the animation clip of track "i" corresponding to 900-3 is not shown here. Finally, when only the new track "j" remains in addition to track "i", DynamicMovieBox934-1 contains only one DynamicTrackBox 934-2, which is for track "j". DynamicTrackHeaderBox 934-21 indicates that there are no changes for track "i". DynamicMovieBox934-1 indicates a change in the track configuration (source_flags=1) corresponding to the end of track 901 (the track with track_id="k").

[0213] Fig.10 Another example of a track configuration change is illustrated, where a track originally declared in the "moov" box is overwritten. The overwrite may consist in updating the sample description, for example in changing the codec or changing the user data of the track or some parameters of the track described in the top-level metadata or the track header. Such a modification may occur in non-blind or early splicing mode, since knowledge of the "moov" box is needed, in particular in order to reuse track_ID values.

[0214] according to Fig.10In the example illustrated in , the presentation contains one or more tracks as represented by 1000 (track_ID "i") and 1001 (track_ID "j"). These tracks are described in the "moov" box 1005 and its sub-boxes. The individual tracks are fragmented (e.g., animation segments 1000-1 to 1000-5 and 1001-1 to 1001-5). At some points in the presentation timeline (even though only one occurrence is shown for simplicity, this may occur several times), the presentation is modified by a new track configuration. For example, new content is injected from segments 1000-3 and 1001-3. The change is indicated by the encapsulation module in the animation segment box describing segments 1001-3 and 1000-3. There may be one "moof" box describing all track segments 1001-3 and 1000-3 or one "moof" box for each track segment. The example illustrates the case of only one "moof" box 1030. The "moof" box 1030 contains a DynamicMovieBox 1030-1 with source_id=0 indicating that there is a track configuration change or modification of the presentation. A source_flags with a value of 1 indicates that a change has occurred at the track level. A DynamicTrackBox 1030-2 indicates in its track header 1032-21 that the track with ID equal to "i" is modified. The flag value of this box can be set to 0, because it is its first appearance. Alternatively, in the case where modification_flags provides a change, the flag value can be set to 2: for example, to indicate an overload of the "stsd" box (setting the flag value 0x000002 in modification_flags), and to indicate a possible overload of the MetaBox of the track (setting the flag value 0x000008 in modification_flags), resulting in modification_flags=10, or if the track layout changes, a flag value 0x000003.

[0215] DynamicTrackBox 1030-2 contains overload boxes "stsd" 1030-22 and "meta" 1030-23, which provide new definitions of sample descriptions and high-level metadata for track "i" for the duration of the segment. These new definitions replace the definitions declared for track "i" in the "moov" box and apply for the duration of the segment (1000-3). The flag value of DynamicMovieBox (1030-1) is set to 1 to indicate that there is information for source identification (source_id parameter). DynamicMovieBox 1030-1 also contains a second DynamicTrackBox 1030-3, which indicates changes to track "j" (e.g. changes to track header information), as indicated by modification_flags=1. It should be noted here that since there is no new sample description (no "stsd" box), the sample configuration from the "trak" box 1011 continues to apply. The "moof" box 1030 also contains the classic "traf" box (1030-4 and 1030-5) and its sub-boxes to describe sample offsets, sizes, durations, etc. The sample data corresponding to the fragments 1000-3 and 1001-3 are stored in the "mdat" box 1030-6.

[0216] At the times corresponding to segments 1000-4 and 1001-4, the new track configuration declared for segments 1000-3 and 1001-3 continues to apply. Therefore, the "moof" box 1040 contains a DynamicMovieBox 1040-1, which has a source_flags indicating that no changes have occurred compared to the previous track configuration with source_id=0. This is further confirmed in each DynamicTrackBox, which has a modification_flags value of 0x00800000 to indicate to the player or reader that the same track configuration as in the previous segment is applied. It should be noted that for track "i", the "stsd" and "meta" boxes (1030-22 and 1030-23) are repeated to ensure random access when playing the presentation starting at the time corresponding to segment 1000-4 or 1001-4.

[0217] It should be noted that although Fig.10The example in illustrates the overwriting of all tracks originally declared in the "moov" box, but some embodiments of the present invention still apply if only a subset of tracks are overwritten (e.g. only track "i" or only track "j"). In this case, the DynamicMovieBox and DynamicTrackBox boxes indicate which tracks are modified, but there is no need to include DynamicTrackBox boxes for tracks that are not modified.

[0218] It should be noted that regardless of Figures 7 to 10 How about an example where the presentation is encapsulated as one track fragment per "moof" box, and the media file contains several movie clips for a given time interval, at least two of which contain a DynamicMovieBox box (such as Figure 8 id). To avoid any ambiguity for a reader or player to determine within this set of DynamicMovieBoxes whether they relate to the same presentation, the DynamicMovieBox may be extended with an additional parameter (called e.g. bundle_id). This parameter may be used to identify a set of DynamicMovieBox boxes that relate to the same presentation. The fact that the source_id is used by a reader or player to determine whether a DynamicMovieBox and its sub-boxes indicating a track configuration change should be processed depends on the source_id. When bundle_id is present, it is the pair (bundle_id, source_id) (the unchanged values ​​of these two parameters) that should be considered instead of the source_id alone.

[0219] Example of multiple DynamicMovieFragments

[0220] This embodiment addresses one limitation of the above embodiment, in which DynamicMovieBox 600 contains only a source_id parameter and no bundle_id parameter. In this embodiment, the syntax of DynamicMovieBox is extended and reuses most of the parameters defined and described above (e.g. Figure 6a and Figure 6b 601 on ). As described below, the extended DynamicMovieBox will also support reference Figure 7 , Fig. 9 , Fig.10 Described use case and will address Figure 8 Possible limitations of use cases.

[0221] Figures 11a to 11c An example of rail configuration change is illustrated.

[0222] Fig.11aAn example of a presentation update or adding or splicing a dynamic track into a presentation that may cause a change in the track configuration is illustrated. For illustration, animation clips 1101 and 1102 correspond to a first presentation 1100 with a track configuration (e.g., a sequence of animation and track fragments with track_ID=1). Animation clips 1111 and 1112 correspond to a second presentation 1110, which is spliced ​​or appended at a given time in the first sequence 1100 using its track configuration. Still for illustration, presentation 1110 consists of a sequence of animation clips, which includes animation clips 1111 and 1112. It should be noted that each animation clip may also contain several track fragments ("traf"), but for clarity only one track fragment is illustrated.

[0223] Fig.11b Example Fig.11a How can the animation clips 1111 and 1112 of the second presentation 1110 in be inserted or spliced ​​into a sequence (e.g., Fig.11a1100 in the first sequence 1100) was previously modified by the encapsulation module. It should be noted here that in order to conform to the original fragments of the second presentation 1110, a dynamic animation box "dymv" is added for each animation clip (for example, a dynamic animation box "dymv" 1121 for animation clip 1111 and a dynamic animation box "dymv" 1122 for animation clip 1112). This is a case where additional parameters such as the bundle_id parameter can be useful in DynamicMovieBox. By adding this parameter, two DynamicMovieBoxes 1121 and 1122 can be associated with the presentation and describe parts or components of the presentation. This is an indication that a new track configuration corresponds to the addition of the respective track configuration described in each of these parts. It should be noted that, depending on the value of source_id in the DynamicMovieBox, the track configuration for the current fragment can also contain track configurations from animation clips that do not have a DynamicMovieBox. For consistency, when the source_id of a DynamicMovieBox of a given fragment is set to 0, the source_id of another DynamicMovieBox in the same fragment (possibly in a different "moof") is also set to 0. The name bundle_id is just an example, it can also be named "subset_id", "component_id", "partition_id" or any other name dedicated to indicating an identifier used to track partial configuration changes within a source_id. With these parameters, a track declared or modified in a DynamicMovieBox can have the same configuration for several consecutive animation fragments. When indicated by the encapsulation module, the source_flags parameter of the DynamicMovieBox allows the file parser to detect that the DynamicMovieBox is a repetition of a previous DynamicMovieBox with the same values ​​for source_id and bundle_id. For the same source_id value, if multiple dynamic tracks or animation-related metadata (e.g., user data or meta boxes) are modified or declared in more than one DynamicMovieBox, these DynamicMovieBoxes each use a different bundle_id. This can allow indicating that a part of the presentation has changed.

[0224] Fig.11cAn example is illustrated where a portion of the track configuration of a presentation has changed to insert presentation 1110. According to the example, the configuration of track N (labeled 1121-21) in DynamicMovieBox 1121-2 has changed. This partial configuration can be indicated at the DynamicTrackBox level (1121-21) using a modification flag, or at the DynamicMovieBox level (1121-2) by assigning a new value of bundle_id for that DynamicMovieBox 1121-2. This can be used to indicate that a portion of the track configuration has changed between movie clips of the track without having to process the entire track configuration for both track N (1121-2) and K (labeled 1122-2), but only for the track with the bundle_id changed (i.e., DynamicMovieBox 1121-2 in the example). Having this information in a DynamicMovieBox allows detecting partial configuration (track or moov level) changes by the reader without checking the (one or more) DynamicTrackBox(es) contained in the DynamicMovieBox. Figure 5 504 in ). For example, when there is no change to the pair (source_id, bundle_id) and source_flags further indicates no change, the reader can safely skip DynamicTrackBox. It should be noted that bundle_id can also correspond to configuration changes that are not exactly track configuration changes, such as high-level changes in the "moov" box, such as metadata in MetaBox ("meta") or user data in UserDataBox ("udat").

[0225] Fig.12 An example of the update syntax of a DynamicMovieBox is illustrated for handling the case where two or more dynamic tracks are inserted in the initial animation or each in its own animation clip during the splicing period. According to this embodiment, the DynamicMovieBox 1200 contains parameters identifying the part within a given source_id, for example, represented as bundle_id (in Fig.12 1205). Figure 6aAs described in DynamicMovieBox 600 in , a DynamicMovieBox may contain zero or more DynamicTrackBoxes. It should be noted that a DynamicMovieBox with a source_id different from 0 can be used without any DynamicTrackBox to force a discontinuity between two movie clips. Using a DynamicMovieBox with a source_id equal to 0 without any DynamicTrackBox can be used to update a MetaBox or a UserDataBox.

[0226] Tracks declared or modified in a DynamicMovieBox can have the same configuration for several consecutive animation clips. The source_flags parameter allows the file parser to detect that a DynamicMovieBox is a repeat of a previous DynamicMovieBox with the same values ​​for source_id and bundle_id. For the same source_id value, if multiple dynamic tracks or animation-related metadata (user data, meta) are modified or declared in more than one DynamicMovieBox, each of these DynamicMovieBoxes can use a different bundle_id. For this extended DynamicMovieBox (1200), the following flags can be defined:

[0227] -0x000001source-info-present, if set, indicates that source information is present; if not set, source_id, bundle_id, and source_flags are 0, and

[0228] -0x000002in-splice, if set, indicates that the track described in the DynamicMovieBox corresponds to a content splice period, which will soon be moved back to the previous configuration. By monitoring this flag and the source_id field, the media pipeline can be optimized if necessary (e.g., to avoid unloading / reloading of e.g. decoder resources). If source_id is 0, this flag should not be set. It should be noted that the encapsulation module can also signal this using a flag in "styp" to simplify versioning of files during cascading.

[0229] It should be noted that the presence or absence of the bundle_id parameter 1205 can be controlled by the version of the DynamicMovieBox. For example, version 0 (no bundle_id) can be used if there is only one "moof" describing all inserted tracks (dynamic tracks), and version 1 can be used if there are multiple tracks (dynamic tracks) to be inserted, which are described in at least two movie clips ("moof" boxes).

[0230] The semantics can be updated as follows:

[0231] source_id identifies the origin of the fragment. A value of 0 may indicate that the source is a MovieBox, and that the DynamicMovieBox modifies the MovieBox. Other values ​​may identify sources other than MovieBox, and all tracks, UserDataBox, MetaBox, and any other properties defined in the MovieBox should be ignored.

[0232] bundle_id provides an identifier for tracking partial configuration changes for a given source_id. Note that bundle_id is usually needed when two or more dynamic tracks are inserted, each in its own animation clip, either in the initial animation or during a splice period. This allows the file reader to detect that changes to a given bundle ad have already been processed in a previous animation clip, and

[0233] source_flags identifies the modifications declared in this DynamicMovieBox compared to the previous DynamicMovieBox with the same source_id and bundle_id values. The flags may be defined as follows:

[0234] 0x000001, if set, indicates that one or more rail configurations have changed.

[0235] 0x000002, if set, indicates that the global (MovieBox level) user data has changed, 0x000004, if set, indicates that the global (MovieBox level) metabox has changed,

[0236] 0x800000, if 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, a file reader can safely skip processing the DynamicMovieBox if a previously parsed DynamicMovieBox had the same source_id and bundle_id. Otherwise (this is the first DynamicMovieBox parsed with this source_id and bundle_id values), this flag may be set but should be ignored by the file reader (i.e., considered not set).

[0237] A box should not be skipped when source_flags is not set (explicitly or according to the above rules) or has the value 0. In this case, there is no information about modifications of sub-boxes compared to the previous DynamicMovieBox and the entire content of the box must be re-evaluated.

[0238] When source_flags is not set to 0x000001, any DynamicTrackBox present in this DynamicMovieBox should have modification_flags set to 0x800000.

[0239] It should be noted that the source_id or bundle_id parameter can be encoded on a lower number of bits (e.g. 8 or 9 bits instead of 32 bits). Using 32 bits makes it consistent with the number of bits of track_ID in TrackHeaderBox, however, using 8 bits may be sufficient and make it possible to reduce the description cost of dynamic tracks. The same applies to the source_flags parameter: using 24 bits makes it consistent with the flags in TrackHeaderBox, however, using 8 bits (or 16) may be sufficient to indicate what has changed in the track configuration and reduce the description cost of dynamic tracks.

[0240] Fig.13 Illustrated using reference Fig.12 The example of splicing audiovisual content 1320 contained in separate animation clips of presentation 1300 using the additional parameter bundle_id is described.

[0241] For illustration, presentation 1300 includes one or more consecutive animation clips (1301 or 1302) for one or more tracks (here with track_id=1 indicating only one track). Spliced ​​content 1320 is contained in separate animation clips for segments from Ni to Ki, with "i" representing the individual media (e.g., as a track described by a sequence of animation clips such as animation clips 1310, 1311, 1312, or 1313). For clarity and conciseness, the corresponding "mdat" boxes for these segments are not illustrated. The animation clips from N to K each have a DynamicMovieBox 1310-1, 1311-1; or the segments in 1312 and 1313 that are not represented have their flags set to the value 3, indicating source_id_present and in-splice.

[0242] The value of source_id in these DynamicMovieBoxes is set to a value greater than 0 to indicate that the track configuration from the MovieBox is replaced by this track configuration. Each DynamicMovieBox has a bundle_id value set to "i". Finally, source_flags is set to 0x800000 (or 0x800001 as a hint to the reader that the track configuration has changed). Each DynamicMovieBox then contains a DynamicTrackBox (e.g., DynamicTrackBox 1310-2 or 1311-2) where the track_ID is indicated in its DynamicTrackHeaderBox (not shown) and SampleDescriptionBox ("stsd", not shown). If the individual tracks in the spliced ​​content have different track identifier values, track_ID can take any value (new value or reuse the value from the MovieBox and its child boxes). The modification_flags of these DynamicTrackHeaderBoxes are set to 0x800000. This modification flag will cause the player to process the file with spliced ​​content at the first occurrence of a dynamic animation or track box (e.g., segments 1310 and 1311), and skip the following segments (until segment K, denoted by reference numerals 1312 and 1313). Then, from the segment at K+1 (corresponding to the switch back to the previous configuration), if the previous configuration is the same configuration as in the MovieBox ("moov"), no DynamicMovieBox is needed.

[0243] Fig.14 Another example is illustrated as follows, in which reference Fig.12The additional parameter bundle_id described is used to splice the audiovisual content in a single animation clip (with configuration changes) (the data part of the animation clip is not illustrated for clarity).

[0244] For illustration, a first presentation 1400 includes a sequence of animation clips denoted by reference numerals 1401 and 1402. At a given time (e.g., time N), new content denoted 1420 is inserted into the first presentation. The new content is a sequence of animation clips having T track segments, T being the number of tracks representing the new content 1420. Fig.14 In the example shown, the number of tracks T is set to 3, such as one video track, one audio track and one subtitle track, but it can be several tracks of the same media type, such as 2 video tracks or 2 audio tracks in different languages. The various tracks of the content of splicing 1420 are as a sequence of animation clips such as 1410, 1411 to 1414, each fragment containing all track fragments as detailed for animation clip 1410, in which the MovieFragmentBox contains DynamicMovieBox "dymv" 1410-1, which itself contains three DynamicTrackBox "dytk" labeled 1410-21 to 1410-23 and three TrackFragmentBox (one "traf" for each track, not shown). Subsequent MovieClips 1411 to 1414 also contain a DynamicMovieBox "dymv", which itself contains three DynamicTrackBoxes "dytk" and three TrackFragmentBoxes. It is explained below how the parameters in the "dymv" and "dytk" boxes can be used to indicate configuration changes over time. In particular, this example illustrates changes at the beginning of the splice (time N) but also within the spliced ​​content: a configuration change occurs at C1 and switches back to the previous configuration after C2. These changes can be represented as follows:

[0245] For the segment in [N, C1], the corresponding Animation Clip 1410, and possibly other subsequent Animation Clips (not shown), contain a DynamicMovieBox 1410-1 with the following parameter values: flags is set to 3 (source-id-present and in-splice), source_id is set to 1 (indicating that the configuration from the MovieBox does not apply to these Animation Clips), bundle_id (if present) is set to 0 (which does not play any role in this example), and source_flags may be set to 0x800000 or 0x800001 as a hint to the player that a change in track configuration has occurred. Setting the value 0x000001 is optional because the first occurrence of the Dynamic Animation Box 1410-1 will be processed and subsequent Dynamic Animation Boxes will be skipped (because the values ​​of source_id and bundle_id do not change between N and C1). Dynamic Track Boxes 1410-21 to 1410-23 have the following values ​​for their parameters. First, the track_ID value can be any value, even the track_ID value used in the MovieBox or its child boxes, because the source_id is greater than 0 (invalidating, overwriting or changing the "moov" configuration). Of course, each of the 3 tracks can have its own track_ID. The collection of track_ID values ​​can be called splice_track_ID. These values ​​are set in each DynamicTrackHeaderBox (not shown) of each "dytk" box and referenced in each TrackFragmentBox that describes the samples of each of the 3 tracks. The modification_flags of each DynamicTrackHeaderBox (not shown) is set to 0x800000. Each DynamicTrackBox 1410-21 to 1410-23 contains a sample description box ("stsd") that provides detailed information about the type of encoding used and any initialization information required for the encoding. This can be used to reset the decoder if necessary.

[0246] For the segment at C1 (animation segment 1411), a sample configuration change occurs. Segment C1 has a DynamicMovieBox 1411-1, which has the same values ​​as those 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 indicated in the DynamicTrackBox (not shown) where the change occurs. For example, each dynamic track has an "stsd" box (to ensure random access), and the change of "stsd" is indicated in its corresponding DynamicTrackHeaderBox (where modification_flags is set to 0x000002 (and for dynamic tracks without "stsd" changes, it is set to 0x800000)) (not shown). This value 0x000002 forces the player to process a dynamic track box with this value, even if the source_id and bundle_id values ​​are the same as in the previous fragment (1410). The track identifier is splice_track_ID.

[0247] For the fragments (one or more than one) in [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 in 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). The respective DynamicTrackBoxes (not shown) in DynamicMovieBox1412-1 contain the same "stsd" as in fragment 1411 (to ensure random access). This is indicated in its corresponding DynamicTrackHeaderBox (with modification_flags set to 0x800002) (not shown). The track identifier is splice_track_ID.

[0248] For the segment at C2+1, the movie clip 1413 contains a DynamicMovieBox 1413-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_Id as identifier), each with one "stsd". The modification_flags of the corresponding DynamicTrackHeaderBox is set to 0x000002 to indicate a configuration change (in the sample description of switching back to the configuration as in [N, C1]). Each dynamic track or a subset of the dynamic tracks in the set of T tracks may have this configuration change. For tracks that have not changed, modification_flags may be set to 0x800002 or 0x800000. The track identifier is splice_track_ID.

[0249] For the segments in [C2+2, K] represented by one or more fragments 1414, each fragment 1414 contains a DynamicMovieBox 1414-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_Id as identifier), each with one "stsd". The modification_flags of the corresponding DynamicTrackHeaderBox is set to 0x800002 to indicate that no changes have occurred between fragment C2+1 and fragment C2+2, and so on (until fragment K).

[0250] Finally, the presentation switches back to the original configuration (in the MovieBox for presentation 1400) from fragment K+1 (labeled 1402). If the configuration to be applied is the same configuration as declared in "moov", then no DynamicMovieBox is needed here (which is the case in the example 1402 with presentation 1400). The track_ID is then the track_ID declared in the TrackHeaderBox within the "moov" box.

[0251] Utilization of dependent or predicted fragment usage

[0252] The proposed DynamicMovieBox 1200 and its sub-boxes can be combined with a MovieFragment that will depend on a referenced MovieFragment. It is assumed that such a dependent MovieFragment will be signaled by a specific version of MovieFragmentHeaderBox, for example as follows:

[0253] aligned(8)class MovieFragmentHeaderBox extends FullBox('mfhd',version,0){

[0254] unsigned int(32)sequence_number;

[0255] }

[0256] If the version is not 0, then any SampleGroupDescriptionBox, DynamicMovieBox, UserDataBox, or MetaBox defined in the last MovieClip with MovieFragmentHeaderBox version 0 or in the last TrackFragment in the last MovieClip also applies to this MovieClip, and there should be no SampleGroupDescriptionBox, DynamicMovieBox, UserDataBox, or MetaBox defined for this MovieClip.

[0257] It should be noted that instead of the version, a specific flag value may be defined instead to avoid any conflict with the versioning of MovieFragmentHeaderBox (eg to encode sequence_number on 64 bits). The above statements will similarly apply.

[0258] Examples of hardware for executing the method steps of embodiments of the present invention

[0259] Fig.15 is a schematic block diagram of a computing device 1500 for implementing one or more embodiments of the present invention. The computing device 1500 may be a device such as a microcomputer, a workstation, or a lightweight portable device. The computing device 1500 includes a communication bus 1502 that is connected to:

[0260] - Central processing unit (CPU) 1504, such as a microprocessor;

[0261] - Random Access Memory (RAM) 1508, which is used to store executable code of the method of the embodiment of the present invention and registers suitable for recording variables and parameters required for implementing the method of encapsulating, indexing, decapsulating and / or accessing data, and its memory capacity can be expanded by, for example, an optional RAM connected to an expansion port;

[0262] - a read-only memory (ROM) 1506 for storing computer programs for implementing embodiments of the present invention;

[0263] - A network interface 1512, which in turn is generally connected to a communication network 1514, through which digital data to be processed is transmitted or received. The network interface 1512 may be a single network interface, or may be composed of a collection of different network interfaces (e.g., wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data is written to the network interface for transmission, or read from the network interface for reception, under the control of a software application running in the CPU 1504;

[0264] - User interface (UI) 1516, which is used to receive input from the user or display information to the user;

[0265] - Hard disk (HD) 1510; and / or

[0266] - I / O module 1518 for receiving / sending data from / to external devices such as a video source or a display.

[0267] The executable code may be stored in the read-only memory 1506, on the hard disk 1510 or on a removable digital medium such as a disk. According to a variant, the executable code of the program may be received over the communication network via the network interface 1512 to be stored in one of the storage devices of the communication device 1500 such as the hard disk 1510 before execution.

[0268] The central processing unit 1504 is adapted to control and direct the execution of instructions or software code portions of one or more programs according to embodiments of the present invention, which instructions are stored in one of the aforementioned storage devices. After power-on, the CPU 1504 is capable of executing instructions related to software applications from the main RAM memory 1508, after loading these instructions, for example, from the program ROM 1506 or the hard disk (HD) 1510. When executed by the CPU 1504, such software applications cause the steps of the flowcharts shown in the previous figures to be performed.

[0269] In this embodiment, the device is a programmable device that implements the invention using software. Alternatively, however, the invention may be implemented in hardware (for example in the form of an application specific integrated circuit or ASIC).

[0270] Although the present invention has been described above with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications within the scope of the present invention will be apparent to those skilled in the art.

[0271] Many further modifications and variations will occur to those skilled in the art when referring to the foregoing illustrative embodiments, which are given by way of example only and are not intended to limit the scope of the invention, which is determined solely by the appended claims. In particular, different features from different embodiments may be interchanged where appropriate.

[0272] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage.

Claims

1. A method for encapsulating media data of multiple presentations in at least one media file based on ISOBMFF, the method comprising: Obtain a portion of media data of a first presentation, the portion denoted as a first portion, the first presentation consisting of a first set of tracks; encapsulating first metadata describing tracks in the first set of tracks and encapsulating the first portion of media data of the first presentation in one or more first media fragments; Obtaining a portion of media data of a second presentation, the portion denoted as a second portion, the second presentation consisting of a second set of tracks; as well as encapsulating second metadata describing tracks in the second set of tracks in one or more second media fragments following the first media fragment, and encapsulating the second portion of media data for the second presentation in the one or more second media fragments, Wherein the second metadata comprises an indication signaling that the second set of tracks does not include at least one track as described in the encapsulated first metadata.

2. The method according to claim 1, wherein: The second metadata comprises an indication which signals that a 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 in the second metadata.

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

4. The method according to any one of claims 1 to 3, wherein: The second track set includes at least one track not described in the first metadata.

5. The method according to any one of claims 1 to 4, wherein: The at least one media file comprises a metadata part, wherein the metadata part is used to encapsulate metadata common to all media data encapsulated in the at least one media file, and the first metadata is encapsulated in the metadata part.

6. The method according to any one of claims 1 to 4, wherein: At least one of the one or more first media fragments includes a metadata part, which is used to encapsulate 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 part of the at least one of the one or more first media fragments.

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

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

9. The method according to any one of claims 1 to 8, wherein: The second metadata also includes an indication signaling that the one or more second media segments can be parsed independently of the first media segment.

10. The method according to any one of claims 1 to 9, wherein: The segments are Common Media Application Format segments or fragments, namely CMAF segments or fragments, or ISO Base Media File Format segments or fragments, namely ISOBMFF segments or fragments.

11. A method for parsing media data of multiple presentations, wherein the media data is encapsulated as multiple segments of one or more media files based on ISOBMFF, the method being executed by a client and comprising: obtaining first metadata describing tracks in a first set of tracks of a first presentation including one or more first media segments; Obtaining at least one second media fragment including encapsulated second metadata describing tracks in a second set of tracks of a second presentation and encapsulated media data, the second metadata being media data of the second presentation, and the at least one second media fragment following a first media fragment including media data of the first presentation; parsing at least a portion of the second metadata; as well as Upon determining that 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, a track description to be used for parsing the encapsulated media data is updated.

12. The method according to claim 11, wherein: Updating the track description includes parsing at least another portion of the second metadata, updating the track description being based on metadata of the at least another portion of the second metadata.

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

14. The method according to claim 12, wherein: The at least another part of the second metadata comprises a new value of at least one parameter of the description of at least one track described in the first metadata.

15. The method according to any one of claims 11 to 14, wherein: The one or more media files include a metadata part, where the metadata part is used to encapsulate metadata common to all media data encapsulated in the one or more media files, and the first metadata is encapsulated in the metadata part.

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

17. The method according to any one of claims 11 to 16, further comprising: obtaining at least one third media fragment including encapsulated third metadata and encapsulated media data, the third metadata describing tracks in a third set of tracks of a presentation including the media data encapsulated in the at least one third media fragment including the third metadata; parsing at least a portion of the third metadata; as well as When it is determined that the third metadata includes an indication that signals that the description of the third track set is similar to the description of a previously determined track set, parsing of another portion of the third metadata is skipped, and media data of at least one third media fragment including the encapsulated third metadata is parsed using the current description of the track set.

18. A computer program product for a programmable device, the computer program product comprising instructions for executing the steps 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 non-transitory computer-readable storage medium storing instructions of a computer program for implementing the method according to any one of claims 1 to 17.

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

Images