Media file encapsulating an image, method for encapsulating and decapsulating an image, apparatus for encapsulating and decapsulating an image

CN122972030APending Publication Date: 2026-10-23CANON KK
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202580022595.7
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-03-25
Filing Date
2025-03-25
Publication Date
2026-10-23

AI Technical Summary

Technical Problem

[0007]由于元数据的移除可能在媒体接收和处理单元侧产生解析错误这一事实,因此这种需要变得复杂

Benefits of technology

[0038]这些规定呈现与本发明的第二方面的封装方法对象类似的优点。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122972030A_ABST
    Figure CN122972030A_ABST
Patent Text Reader

Abstract

A method for encapsulating an image in a media file comprises the steps of generating an image description and / or an image header in the media file based on an encapsulation mode selected from at least a regular description mode and a compact description mode, the image description and / or image header comprising a set of decoder configuration parameters, wherein, in the compact description mode, compared to the regular description mode, a smaller encoding of fewer parameters and / or parameter values for the set of decoder configuration parameters is used.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to media files containing images, methods for encapsulating images, methods for decapsulating images, and corresponding computer program products, computer-readable storage media, and devices.

[0002] This invention applies to a compact description of the codecs or decoder configurations used for small images in the High Efficiency Image Format (HEIF) standard. Background Technology

[0003] With the increase in cross-network transmission capabilities and computing power, the size of media transmitted and processed by computing devices has gradually increased.

[0004] Along with the size of such media content, the size of the metadata describing that media content has also increased.

[0005] In the current system, given the static nature of the metadata structure used by image transmission and processing standards (such as efficient image format standards), relatively small images need to be transmitted and processed. For these images, the current ratio of media content to metadata size is unsatisfactory.

[0006] Small images can be defined by the resolution of the image (such as 1024x1024 or equivalent and below) or by the memory space occupied by the image (e.g., such as 16 kilobytes and below). Small images can also be defined in a given use case where specific operating parameters in terms of image size are to be used.

[0007] This need is complicated by the fact that removing metadata can cause parsing errors on the media receiving and processing unit side. Such metadata, for example, corresponds to decoder (codec) signaling information.

[0008] The current need is to generate compact descriptions for small images in HEIF while ensuring simple parsing and extraction of items described using compact descriptions.

[0009] Furthermore, there is now a need to enable the generation of compact descriptions of codecs or decoder configurations for small images in HEIF while maintaining the same decoder initialization capabilities as traditional decoder configurations in media file parsers.

[0010] The image file format standard (HEIF-ISO / IEC 23008-12) describes how images are encapsulated as image items in ISOBMFF-based media files. For use cases with small images, the MPEG file format group is considering a more compact version of HEIF. Summary of the Invention

[0011] The present invention is intended to correct all or some of these disadvantages.

[0012] Therefore, according to a first aspect, the present invention aims to provide a method for encapsulating an image in a media file, comprising the following steps:

[0013] - Generate an image description and / or image header in a media file based on a wrapping mode in at least one of a regular description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, compared to the regular description mode, the compact description mode uses fewer parameters and / or smaller encoding of parameter values ​​for the set of decoder configuration parameters.

[0014] Such a specification enables the provision of a limited number and / or small-sized metadata parameters in the image header and / or image description to represent the image content during encapsulation, and the intelligent parsing of metadata parameters in the image header and / or image description during decapsulation.

[0015] In a particular embodiment, if the encapsulation mode indicates a compact description mode, then during the generation step, only decoder configuration parameters that are not associated with reserved or predetermined values ​​in a regular description mode are used to generate the image description and / or image header.

[0016] This provision allows for the removal of decoder configuration parameters associated with reserved or predefined values.

[0017] In a particular embodiment, if the encapsulation mode indicates a compact description mode, then during the generation step, only decoder configuration parameters that are not associated with the multi-image content are used to generate the image description and / or image header.

[0018] Such a provision allows the removal of decoder configuration parameters associated with multi-image (such as video) media.

[0019] This specification allows for the provision of a limited number of metadata parameters and / or a small number of decoder configuration parameters during encapsulation. For example, in the case of HEVC, VVC, and AVC codecs, such decoder configuration parameters provided in a property box containing codec or decoder configuration can represent a large number of HEIF signal notifications.

[0020] In a particular embodiment, the image container format corresponds to the image container format according to the High Efficiency Image Format (HEIF) standard.

[0021] According to a second aspect, the present invention aims to provide a method for encapsulating at least one image, comprising the following steps:

[0022] - Select the encapsulation mode between regular description mode and compact description mode for images, and

[0023] - Generate an image description and / or image header based on the selected encapsulation mode, wherein, compared to the conventional description mode, the compact description mode uses fewer parameters and / or smaller encoding of parameter values.

[0024] This specification enables the generation of smaller image descriptions and / or image headers within encapsulated images.

[0025] In a particular embodiment, if the compact description mode is selected, a compact set of decoder configuration parameters is generated during the generation step.

[0026] This specification enables the generation of smaller decoder configuration parameters in the image description and / or image header of the encapsulated image.

[0027] In a particular embodiment, when the encapsulation mode indicates a compact description mode, if the length of at least one decoder configuration parameter is greater than a length threshold, the at least one decoder configuration parameter is compressed, and the compressed at least one decoder configuration parameter is used to generate an image description and / or an image header during the generation step.

[0028] This specification allows for the compression of decoder configuration parameters.

[0029] In a particular embodiment, if the encapsulation mode indicates a compact description mode, then during the generation step, the parameters of each network abstraction layer unit associated with a usage probability estimate greater than a threshold are used to generate the image description and / or image header.

[0030] This provision allows for the removal of decoder configuration parameters that are unlikely to be used by the decoder.

[0031] In a particular embodiment, if the encapsulation mode indicates a compact description mode, then the image description and / or image header are generated during the generation step using configuration parameters that are determined to be non-derivative.

[0032] This provision allows for the removal of decoder configuration parameters that can be inferred from the decoder.

[0033] In a particular embodiment, at least one decoder configuration parameter is a network abstraction layer unit type parameter that exists in the configuration record of the image.

[0034] In a particular embodiment, at least one decoder configuration parameter is the number and / or length of network abstraction layer units present in the configuration record of the image.

[0035] In a particular embodiment, the encapsulation mode also indicates one of a plurality of compact description modes representing the degree of compactness of the intent, and the generation step is performed according to said degree of compactness.

[0036] According to a third aspect, the present invention aims to provide a method for decapsulating an image from a media file, comprising the following steps:

[0037] - Parse the image description and / or image header based on a wrapping mode in at least one of a regular description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, compared to the regular description mode, the compact description mode parses fewer parameters and / or smaller encodings of parameter values ​​for the set of decoder configuration parameters.

[0038] These provisions present advantages similar to those of the encapsulation method object of the second aspect of the present invention.

[0039] According to a fourth aspect, the present invention aims to provide an apparatus for encapsulating an image within a media file, comprising:

[0040] - A component for generating an image description and / or image header in a media file based on a wrapping mode in at least one of a regular description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, compared to the regular description mode, the compact description mode uses fewer parameters and / or smaller encoding of parameter values ​​for the set of decoder configuration parameters.

[0041] According to a fifth aspect, the present invention aims to provide an apparatus for decapsulating images from a media file, comprising:

[0042] - A component for resolving an image description and / or image header based on a wrapping mode in at least one of a regular description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, in the compact description mode, fewer parameters and / or smaller encodings of parameter values ​​are resolved for the set of decoder configuration parameters compared to the regular description mode.

[0043] According to a sixth aspect, the present invention aims to provide a media file encapsulating an image, comprising parameters representing an encapsulation mode in at least one of a conventional description mode and a compact description mode, wherein, compared to the conventional description mode, the compact description mode is used to generate an image description and / or image header including the decoder configuration parameter set with fewer parameters for a decoder configuration parameter set and with less encoding of the parameter values.

[0044] In a particular embodiment, the media file conforms to an image encapsulation format according to the High Efficiency Image Format (HEIF) standard.

[0045] According to a seventh aspect, a computer program product is characterized in that the computer program product includes instructions that, when executed by a computer, cause the computer to perform the method object of the present invention.

[0046] According to an eighth aspect, the present invention aims to provide a computer-readable storage medium storing programming instructions that, when executed by a computer, cause the computer to perform the method object of the present invention. Attached Figure Description

[0047] Other advantages, objects, and particular features of the invention will become apparent from the following non-exhaustive description of at least one specific embodiment of the invention, taken in conjunction with the accompanying drawings, in which:

[0048] Figure 1 The illustration schematically depicts a series of steps in a first specific embodiment of the method for encapsulating an object according to the present invention.

[0049] Figure 2a The diagram schematically illustrates a series of steps in a second specific embodiment of the method for encapsulating an object according to the present invention.

[0050] Figure 2b The diagram schematically illustrates a series of steps in a third specific embodiment of the method for encapsulating an object according to the present invention.

[0051] Figure 2c The illustration schematically depicts a series of steps in a fourth specific embodiment of the method for encapsulating an object according to the present invention.

[0052] Figure 3 The diagram schematically illustrates a series of steps in a fifth specific embodiment of the method for encapsulating an object according to the present invention.

[0053] Figure 4 The illustration schematically depicts a series of steps in a specific embodiment of the method for decapsulating an object according to the present invention, and

[0054] Figure 5 This schematically illustrates a specific embodiment of a device suitable for encapsulating and decapsulating image files. Detailed Implementation

[0055] This description is not exhaustive, as features of one embodiment can be advantageously combined with any other feature of any other embodiment. Furthermore, various inventive concepts can be embodied as one or more methods, examples of which have been provided. Actions performed as part of a method can be ordered in any suitable manner. Therefore, embodiments can be constructed that perform actions in a different order than that illustrated, which may include performing several actions simultaneously, even if shown as sequential actions in the illustrative embodiment.

[0056] Unless explicitly indicated to the contrary, the indefinite articles “a” and “an” as used herein in the specification and claims shall be understood to mean “at least one”.

[0057] As used herein in the specification and claims, the phrase “and / or” should be understood to mean “any one or both” of the elements so combined, that is, elements that are combined in some cases and separate in others. Multiple elements listed with “and / or” should be interpreted in the same way, that is, “one or more” of the elements so combined. In addition to the elements specifically identified by the “and / or” clause, other elements may optionally be present, whether related to or unrelated to those specifically identified. Thus, as a non-limiting example, when used in conjunction with open-ended language such as “comprising,” a reference to “A and / or B” may in one embodiment refer only to A (optionally including elements other than B); in another embodiment, only to B (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); and so on.

[0058] As used herein in the specification and claims, “or” should be understood to have the same meaning as “and / or” as defined above. For example, when separating items in a list, “or” or “and / or” should be interpreted as inclusive, i.e., including at least one, but also including multiple elements or more than one in a list of elements, and optionally, additional unlisted items. Only terms that clearly indicate the opposite (such as “only one of…” or “exact one of…”, or, when used in the claims, “consisting of…”, etc.) will refer to including multiple elements or exactly one element in a list of elements. Generally, the term “or” as used herein should only be interpreted as indicating an exclusive alternative (i.e., “one or the other, not both”) when preceded by an exclusive term (such as “any,” “one of…,” “only one of…,” or “exact one of…”, etc.). When used in the claims, “consisting substantially of…” should have its ordinary meaning as used in the field of patent law.

[0059] As used herein in the specification and claims, the phrase "at least one" when referring to a list of one or more elements should be understood to mean at least one element selected from any one or more elements in the list, but does not necessarily include each and every element specifically listed in the list, and does not exclude any combination of elements in the list. This definition also allows for the optional presence of elements other than those specifically identified within the list of elements referred to by the phrase "at least one," whether related to or unrelated to those specifically identified elements. Thus, as a non-limiting example, "at least one of A and B" (or equivalently "at least one of A or B," or equivalently "at least one of A and / or B") in one embodiment may refer to at least one (optionally including more than one) A, without B (and optionally including elements other than B); in another embodiment, it refers to at least one (optionally including more than one) B, without A (and optionally including elements other than A); in yet another embodiment, it refers to at least one (optionally including more than one) A and at least one (optionally including more than one) B (and optionally including other elements); and so on.

[0060] In the claims and the foregoing description, all transitional phrases (such as "comprising," "including," "carrying," "having," "containing," "involving," "holding," "consisting of," etc.) shall be understood as open-ended, meaning including but not limited to. Only the transitional phrases "consisting of" and "substantially consisting of" shall be closed or semi-closed transitional phrases, respectively.

[0061] It should be noted that the accompanying drawings are not drawn to scale.

[0062] In the context of this invention, "ISOBMFF" refers to the ISO Basic Media File Format, where "ISO" refers to the International Organization for Standardization. ISOBMFF is a container file format used to define the general structure of files containing time-based multimedia data such as video and audio.

[0063] According to ISOBMFF and its extensions, media files are composed of "boxes." A box (also called a container) is a hierarchical data structure provided to describe the data in a file. A box is an object-oriented building block defined by a unique type identifier (usually a four-character code, also called "FourCC" or "4CC") and a length. All data in the file (media data and metadata describing the media data) is contained within a box. There is no other data within the file. File-level boxes are boxes that are not contained within other boxes.

[0064] In the context of this invention, "HEIF" refers to the High-Efficiency Image File Format. HEIF is a container format for storing individual digital images and image sequences. The standard covers multimedia files, which may also include other media streams such as timed text, audio, and video.

[0065] According to a specific embodiment, the present invention aims to provide a media file encapsulating an image, comprising parameters representing an encapsulation mode selected from at least a conventional description mode and a compact description mode, wherein the compact description mode is used to generate an image description and / or an image header including a set of decoder configuration parameters, wherein compared to the conventional description mode, the set of decoder configuration parameters has fewer parameters and / or smaller encoding of parameter values.

[0066] Such a parameter can correspond to an explicit parameter, which can be associated with two values ​​("Compact mode active" or "Compact mode inactive"). In variations, the explicit parameter can be associated with more than two values ​​corresponding to different compactness levels or grades. In variations, the explicit parameter can be signaled in the media file as a brand, or signaled in the media file as a four-character code indicating the box type, which indicates whether the box includes a regular description or a compact description.

[0067] Such parameters can correspond to the fact that in an image file format with a predetermined number of image description and / or image header parameters, there are fewer parameters in the image file's image description and / or image header parameters.

[0068] Such parameters can correspond to including a brand in the image file parameters, where the brand indicates the presence of a compact format of the image file or indicates that a compact description mode is active, and another brand indicates the presence of a regular format of the image file or indicates that a regular description mode is active.

[0069] Possible branding definitions for a compact description of an image may include using the 'mif3' branding to indicate one of the following file requirements: the presence of a MinimizedImageBox box, for example, with a 'mini' box type as the top-level box for media files; and, for media files compatible with the 'mif1' branding, the presence of a MetaBox 'meta' box and its sub-boxes (for backward compatibility).

[0070] In certain embodiments, the image encapsulation format includes a compact set of decoder configuration parameters.

[0071] In a particular embodiment, the image container format corresponds to the image container format according to the High Efficiency Image Format (HEIF) standard.

[0072] Figure 1 Specific embodiments of the method for encapsulating objects according to the present invention are illustrated schematically in its main processing steps.

[0073] It should be understood that this encapsulation method can be performed based on an iterative process that is applied sequentially to each image to be represented in HEIF format.

[0074] Figure 1 The processing steps represent the processing of one image. However, in some cases, more than one image can be represented in the same media file. Some images can also be derived from previously represented images, thus introducing dependencies between image items. In another example, the encapsulated input can include a sequence of one or more images to represent an animation. In this case, Figure 1 The encapsulation process described herein can be applied sequentially to each input image in the sequence. Therefore, the encapsulation method can retain previously generated media files in memory and update those previously generated media files instead of generating new media files (as disclosed with respect to steps 103 to 106).

[0075] In the first step 101, the method for encapsulation determines the image configuration. This step 101 can be performed by a computer program executing on a computing device. Such a computer program can be configured to read and interpret metadata stored in the image file.

[0076] This image configuration corresponds to a set of parameters or properties associated with the image to be encapsulated. For example, the image configuration may include parameters that indicate the codecs associated with profile, tier, and / or level data information used to compress the image to be represented in the HEIF file.

[0077] Configuration parameters may also include a set of encoded structures that describe the encoding configuration that enables the decoder to be instantiated. Such a set of encoded structures is also referred to in this document as configuration data or decoder configuration parameters.

[0078] Other parameters representing the configuration of an image include, for example, the image's size or resolution. Configuration parameters may also include the number of components present in the image. A component is defined as a set of data that has the same semantics associated with image pixels. For example, the pixel values ​​of an image form an image component.

[0079] If such a channel exists in the encoded image, then the alpha plane or alpha channel can correspond to another component.

[0080] Some images can be associated with metadata that can be described using EXIF ​​(for “Exchangeable Image File Format”) or XMP (for “Extensible Metadata Platform”) metadata formats.

[0081] In this document, each metadata set is considered a component.

[0082] It should be noted that in monochrome formats, pixel value data may include a single channel, but such a channel is still considered a component. In color formats, each pixel is associated with several pixel values ​​(e.g., red, green, and blue values). Colors form channels, and all color channels form components. Image configuration parameters may also include the length of configuration data for each component in bits or bytes and / or the length of compressed data for each component in bits or bytes.

[0083] The method for encapsulation also includes a check step 102, which determines, based on the encapsulation mode, whether to use a compact (or simplified or reduced or compacted) file format or a regular file format (i.e., non-compacted) to describe the media file.

[0084] This step 102 can be performed by a computer program that executes on a computing device. Such a computer program can be configured to read and interpret configuration parameters stored in the image file.

[0085] Such a step 102 can execute deterministic rules to determine the encapsulation mode, for example, based on an image size parameter that is predetermined or determined as an execution parameter of step 102. If such a rule is determined as an execution parameter, such a rule can be set by a user on a graphical user interface (GUI) or automatically set by another computer program.

[0086] In other embodiments, regardless of the image's configuration parameters, step 102 is performed on the computing system, and the encapsulation mode is determined following algorithmic rules belonging to the computing system. For reasons of transmission or processing speed, the computing system may need to encapsulate the image in a compact manner.

[0087] The compact description patterns and corresponding compact descriptions disclosed in this document are designed to provide a minimal description of an image, enabling simplified parsing of HEIF descriptions and parallel processing of image components. The benefit of compact descriptions also lies in their ability to provide a compact description for compressed images represented with a small amount of data. The compactness of compressed data may stem from efficient compression (which may result in a loss of quality) or from the small size of the image, leading to low resolution.

[0088] The criteria that will trigger such compact representations are varied. Such criteria may rely on, for example, the necessity of rapidly rendering low-resolution images to generate graphical user interfaces or rendering interactive entities (such as clickable images) in web pages.

[0089] Other criteria may be related to image configuration (such as the size of the encoded data, the number of components, or the length in bits or bytes), which may also prevent the image from being described using a compact description.

[0090] When an image does not meet the criteria checked in step 102, the encapsulation process generates a media file header in step 103 using a regular or standard encapsulation mode and the corresponding regular encapsulation (such as HEIF), and uses a MetaBox with version 0 to represent the image as HEIF entries to describe the image data. The generation of MetaBox information is handled by... Figure 1 Step 104 is illustrated below. The steps of generating the 103 media file header and generating the 104 metadata box are known to those skilled in the art of image encapsulation and will not be further disclosed here.

[0091] Conversely, if a compact description is selected in step 102, steps 105 to 106 apply to starting from generating the media file header in step 105.

[0092] Step 105 may include generating an HEIF media file header that begins with a Box (e.g., FileTypeBox) indicating a set of brands applicable to the media file. This Box may indicate a primary brand, one or more secondary brands, or a set of compatible brands. When using a compact description, specific brands can be indicated in a list of brands to indicate the presence of a compact description-specific box. For example, these boxes may be generated in step 106. An optimized version of FileTypeBox may be used in the compact description.

[0093] In step 106, the encapsulation process generates a compact (or reduced, simplified, or compacted) image description of the image. (See reference...) Figure 3 Describes the processing used to generate compact image descriptions.

[0094] Figure 3 Specific embodiments of the steps for generating a compact encapsulation of media or image files are illustrated, which can be implemented in embodiments of the method for encapsulating objects of the present invention.

[0095] In the first step 300, a compact (or minimized, reduced, or streamlined) image header is generated. This compact image header includes a reduced number of parameters describing the image configuration. These reduced number of parameters specify the properties of the image.

[0096] The compact image header may include a version number that indicates a value that makes it possible to distinguish different versions of the compact description syntax.

[0097] The compact image head may include parameters that indicate the type of color profile configuration (e.g., sRGB, ICC profile, etc.).

[0098] A compact image header may include the width and height of an image as described by a compact description.

[0099] The compact image header may include bits used to represent the pixel values ​​of the image described by the compact description.

[0100] The compact image header may include an indication of whether the pixel format uses floating-point or integer representation.

[0101] A compact image header can include an indication of the range of pixel values.

[0102] The compact image header may include an indication of whether the image described by the compact description is associated with the alpha plane.

[0103] The compact image header may include an indication of whether the pixel values ​​of the image described by the compact description are premultiplied by the alpha plane.

[0104] The compact image header may include an indication of whether the image described by the compact description data includes an explicit list of codec types.

[0105] In step 301, a data structure is generated that includes compressed data corresponding to pixel value components (i.e., pixel values ​​of the image).

[0106] This data structure may also include configuration data or decoder configuration parameters. Configuration data may include decoder (or codec) configuration boxes or decoder configuration records, which may be provided in the SampleEntry of the ISOBMFF file or as an item property associated with one or more items.

[0107] For example, for the HEVC (for "High Efficiency Video Coding") item, the configuration data may correspond to the contents of the HEVCConfigurationBox ('hvcC') according to ISO / IEC 14496-15, or to a compact version of the contents of that box according to embodiments of this disclosure.

[0108] Another example is VVCConfigurationBox('vvcC') or AVCConfigurationBox('avcC') as defined in the same specification for VVC (for "General Video Coding") or AVC (for "Advanced Video Coding") items respectively, or a compact version of the contents of these boxes according to embodiments of this disclosure.

[0109] Another example is any decoder configuration that can be used to compress still images using the MPEG (Moving Picture Experts Group) codec. (See reference) Figures 2a to 2c The generation of the codec or decoder configuration in step 302 is described in further detail.

[0110] In step 303, when the image includes an alpha plane, another data structure is generated that includes auxiliary components such as alpha channels or depth data. This data structure is identical to the data structure for the pixel components of the image described using a compact description.

[0111] It should be noted that several configuration parameters can be provided in the compact image description, for example, one for the main image and another for the alpha image. In this case, a decoder configuration for the alpha plane can also be generated using a step similar to 302. More generally, the generation of the decoder configuration in step 302 can be applied to decoder configuration data described using a simplified description of the image.

[0112] Both pixels and auxiliary data can be represented as encoded items that provide data for the data structure generated in steps 301 and 303. This data structure is represented as a minimized item data structure (also represented as a minimized item data structure), and items described in the compact description of the image can be represented as minimized items. Minimized items are items described in the compact description of the image. As a counterexample, items described in a traditional HEIF MetaBox based on ItemInfoBox and ItemLocationBox are not minimized items.

[0113] In step 304, when the image is associated with metadata (such as EXIF ​​or XMP metadata), the metadata is represented as an encoded item using the same minimal item data structure.

[0114] In step 305, the ColourData data structure represents information related to color information, such as primary colors, transmission characteristics, and matrix coefficients.

[0115] These data structures are not ISOBMFF boxes; they are all contained within a single ISOBMFF box (e.g., a minimized image box). A minimized image can be defined as an image described using a compact description.

[0116] As understood, a decoder or codec configuration can be provided in a compact description. The content of the decoder configuration depends on the encoding format of the encoded data in the image, or more precisely, on the encoded data of the items associated with the decoder configuration.

[0117] For example, MPEG (Moving Picture Experts Group) codecs can be used to compress still images. VVC, HEVC, and AVC, for example, provide decoder configurations that describe the encoding parameters of the encoder. ISO / IEC 14496-15 enables these standards' decoder configurations to support a wide range of video and still images, resulting in lengthy decoder configurations.

[0118] In the context of compact image description, the size or length of the decoder configuration, as specified in ISO / IEC 14496-15, represents an important part of the description of a small image.

[0119] In this document, encapsulation processes can be used to compress the size of the decoder configuration through various means to ensure a compact description.

[0120] As an overview of a general solution, encapsulation processing can rely on the fact that, when used in a compact image description, the decoder configuration is applied to a single image (not a video). It can be observed that some parameters in a conventional or regular decoder configuration (i.e., a non-compact decoder configuration) are only useful or even meaningful for the video sequence. Encapsulation processing can signal in the bitstream that these video-related parameters are not present in the decoder configuration. Based on this signaling, decapsulation processing can resolve the compact decoder configuration provided in the compact image description. To ensure the same initialization capability as the conventional decoder configuration syntax, the parser can infer parameters not provided in the compact decoder configuration to generate a conventional decoder configuration according to ISO / IEC 14496-15.

[0121] The following sections disclose several embodiments of compression decoder configurations, focusing on examples of VVC, AVC, and HEVC codec formats. These embodiments can be applied to other decoder configuration formats that can be compressed using compression mechanisms equivalent to or similar to those described for the different embodiments.

[0122] In the first embodiment, the generation step 302 of the compact decoder configuration is in Figure 2aThe process is described in the diagram. During this generation step, in the first step 200, the conventional or traditional decoder configuration parameters specified according to ISO / IEC 14496-15 are determined. Then, the parameters of the conventional or traditional decoder configuration are processed sequentially in a processing loop consisting of steps 201 to 205.

[0123] During step 201, a check is performed to ensure that all parameters have been processed in order to end the processing loop by running step 206 as described below.

[0124] For each parameter, during step 202, the encapsulation process checks whether the parameter or a portion thereof is associated with a reserved or predetermined value. For example, a conventional decoder configuration may include padding bits with values ​​equal to 0. Parameters that meet this criterion are marked as "optional" in step 203 because they are irrelevant for a single image or image sequence track (without strict timing indication).

[0125] This step of determining whether at least one decoder configuration parameter is associated with a reserved or predetermined value can be performed by executing a computer program on a computing device. During this determination step, several configurations can be generated. In some configurations, as shown above, during the determination step, the presence of padding bits can be detected and determined to correspond to a reserved size or value that can be marked as "optional".

[0126] During this determination step, the presence of some parameters that indicate the version of the decoder configuration syntax can also be detected—most of the time such parameters are set to predetermined values ​​(e.g., equal to 0).

[0127] Then, during step 204, it is determined whether the parameter describes information that is inconsistent with the content of a single image but is meaningful only for the content of multiple images. For example, it could be video-related information such as frame rate or time level. In step 203, parameters that satisfy this criterion are marked as "optional".

[0128] Otherwise, in step 205, parameters that do not meet the previous criteria are marked as "required".

[0129] In the final step, the encapsulation module generates a compact decoder configuration containing only the "necessary" parameters (in other words, only parameters relevant to still images). It should be noted that the list of relevant parameters may vary depending on the trim level or brand specifications.

[0130] For example, when the grade indicates a still image grade, the decapsulation module can infer that only one image exists in the file, and the parameters describing the decoder configuration for the video aspect are set to predetermined values, such as 0 or 1. As another example, if the image file contains a brand as a compatible brand, such as '1pic' in the 'ftyp' box (or a compact version of that box), the decapsulation can perform the same operation. In these cases, the encapsulation module can consider the parameters describing the decoder configuration for the video aspect to be optional in step 203.

[0131] In this context, the decapsulation module infers the values ​​of optional parameters that are not present in the compact decoder configuration as equal to predetermined values ​​(e.g., 1 or 0 or unspecified) to construct the decoder configuration expected by a traditional player.

[0132] The decapsulation process, responsible for regenerating the legacy decoder configuration, needs to know the inferred values. This is possible because the parser can be configured to generate correct values, for example, those standardized in ISO / IEC 14496-15. For example, there are two reserved parameters canonically defined as equal to '11111'b and a third reserved set equal to 0. For instance, the decapsulation process could regenerate the optional (as marked in step 203) constant_format_rate to a value of 0 because it is not applicable to the image.

[0133] For example, the syntax of the decoder configuration content can be corresponding to the following according to ISO / IEC 14496-15:

[0134] aligned(8) class VvcDecoderConfigurationRecord {

[0135] bit(5) reserved = '11111'b;

[0136] unsigned int(2) LengthSizeMinusOne;

[0137] unsigned int(1) ptl_present_flag;

[0138] if (ptl_present_flag) {

[0139] unsigned int(9) ols_idx;

[0140] unsigned int(3) num_sublayers;

[0141] unsigned int(2) constant_frame_rate;

[0142] unsigned int(2) chroma_format_idc;

[0143] unsigned int(3) bit_depth_minus8;

[0144] bit(5) reserved = '11111'b;

[0145] VvcPTLRecord(num_sublayers) native_ptl;

[0146] unsigned_int(16) max_picture_width;

[0147] unsigned_int(16) max_picture_height;

[0148] unsigned int(16) avg_frame_rate;

[0149] }

[0150] unsigned int(8) num_of_arrays;

[0151] for (j=0; j < num_of_arrays; j++) {

[0152] unsigned int(1) array_completeness;

[0153] bit(2) reserved = 0;

[0154] unsigned int(5) NAL_unit_type;

[0155] if (NAL_unit_type != DCI_NUT && NAL_unit_type != OPI_NUT)

[0156] unsigned int(16) num_nalus;

[0157] for (i=0; i< num_nalus; i++) {

[0158] unsigned int(16) nal_unit_length;

[0159] bit(8 nal_unit_length) nal_unit;

[0160] }

[0161] }

[0162] }

[0163] aligned(8) class VvcPTLRecord(num_sublayers) {

[0164] bit(2) reserved = 0;

[0165] unsigned int(6) num_bytes_constraint_info;

[0166] unsigned int(7) general_profile_idc;

[0167] unsigned int(1) general_tier_flag;

[0168] unsigned int(8) general_level_idc;

[0169] unsigned int(1) ptl_frame_only_constraint_flag;

[0170] unsigned int(1) ptl_multilayer_enabled_flag;

[0171] unsigned int(8 num_bytes_constraint_info - 2) general_constraint_info;

[0172] for (i=num_sublayers - 2; i >= 0; i--)

[0173] unsigned int(1) ptl_sublayer_level_present_flag[i];

[0174] for (j=num_sublayers; j<=8 && num_sublayers > 1; j++)

[0175] bit(1) ptl_reserved_zero_bit = 0;

[0176] for (i=num_sublayers-2; i >= 0; i--)

[0177] if (ptl_sublayer_level_present_flag[i])

[0178] unsigned int(8) sublayer_level_idc[i];

[0179] unsigned int(8) ptl_num_sub_profiles;

[0180] for (j=0; j < ptl_num_sub_profiles; j++)

[0181] unsigned int(32) general_sub_profile_idc[j];

[0182] }

[0183] In these records, the bits for the parameters "reserved" and "ptl_reserved_zero_bit" have predetermined values ​​equal to 1 (or 0). Therefore, the encapsulation process marks these parameters as optional according to the criteria checked in step 202.

[0184] The parameters “num_sublayers”, “constant_frame_rate”, and “avg_frame_rate” are video-related and inconsistent for still image content. Therefore, in step 204, the encapsulation process determines them to be optional.

[0185] The compact decoder configuration contains parameters defined as required, but no optional parameters. It allows obtaining the decoder configuration and thus the reduced or compact size of the image description. An additional set of trailing bits (represented by the `trailing_bits()` function) can be provided at the end of the compact configuration record to ensure that the compact configuration record is byte-aligned.

[0186] Therefore, the encapsulation process can (in step 206) generate a compact VVC decoder configuration according to the first embodiment, including the following parameters. This CompactVvcDecoderConfigurationRecord (or CondensedVvcDecoderConfigurationRecord) can be signaled, for example, in a CompactVvcDecoderConfigurationBox (or CondensedVvcDecoderConfigurationBox) with 'vvcc' as the four-character code box type:

[0187] aligned(8) class CompactVvcDecoderConfigurationBox extends Box('vvcc') {

[0188] CompactVvcDecoderConfigurationRecord () vvcConfig;

[0189] }

[0190] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0191] unsigned int(2) LengthSizeMinusOne;

[0192] unsigned int(1) ptl_present_flag;

[0193] if (ptl_present_flag) {

[0194] unsigned int(9) ols_idx;

[0195] unsigned int(2) chroma_format_idc;

[0196] unsigned int(3) bit_depth_minus8;

[0197] VvcPTLRecord(1) native_ptl;

[0198] unsigned_int(16) max_picture_width;

[0199] unsigned_int(16) max_picture_height;

[0200] }

[0201] unsigned int(8) num_of_arrays;

[0202] for (j=0; j < num_of_arrays; j++) {

[0203] unsigned int(1) array_completeness;

[0204] unsigned int(5) NAL_unit_type;

[0205] if (NAL_unit_type != DCI_NUT && NAL_unit_type != OPI_NUT)

[0206] unsigned int(16) num_nalus;

[0207] for (i=0; i< num_nalus; i++) {

[0208] unsigned int(16) nal_unit_length;

[0209] bit(8 nal_unit_length) nal_unit;

[0210] }

[0211] }

[0212] trailing_bits()

[0213] }

[0214] aligned(8) class VvcPTLRecord(num_sublayers) {

[0215] unsigned int(6) num_bytes_constraint_info;

[0216] unsigned int(7) general_profile_idc;

[0217] unsigned int(1) general_tier_flag;

[0218] unsigned int(8) general_level_idc;

[0219] unsigned int(1) ptl_frame_only_constraint_flag;

[0220] unsigned int(1) ptl_multilayer_enabled_flag;

[0221] unsigned int(8 num_bytes_constraint_info - 2) general_constraint_info;

[0222] for (i=num_sublayers - 2; i >= 0; i--)

[0223] unsigned int(1) ptl_sublayer_level_present_flag[i];

[0224] for (i=num_sublayers-2; i >= 0; i--)

[0225] if (ptl_sublayer_level_present_flag[i])

[0226] unsigned int(8) sublayer_level_idc[i];

[0227] unsigned int(8) ptl_num_sub_profiles;

[0228] for (j=0; j < ptl_num_sub_profiles; j++)

[0229] unsigned int(32) general_sub_profile_idc[j];

[0230] }

[0231] In another example, the syntax of the content of the HEVC decoder configuration is as follows according to ISO / IEC 14496-15:

[0232] aligned(8) class HEVCDecoderConfigurationRecord {

[0233] unsigned int(8) configurationVersion = 1;

[0234] unsigned int(2) general_profile_space;

[0235] unsigned int(1) general_tier_flag;

[0236] unsigned int(5) general_profile_idc;

[0237] unsigned int(32) general_profile_compatibility_flags;

[0238] unsigned int(48) general_constraint_indicator_flags;

[0239] unsigned int(8) general_level_idc;

[0240] bit(4) reserved = '1111'b;

[0241] unsigned int(12) min_spatial_segmentation_idc;

[0242] bit(6) reserved = '111111'b;

[0243] unsigned int(2) parallelismType;

[0244] bit(6) reserved = '111111'b;

[0245] unsigned int(2) chroma_format_idc;

[0246] bit(5) reserved = '11111'b;

[0247] unsigned int(3) bit_depth_luma_minus8;

[0248] bit(5) reserved = '11111'b;

[0249] unsigned int(3) bit_depth_chroma_minus8;

[0250] unsigned int(16) avgFrameRate;

[0251] unsigned int(2) constantFrameRate;

[0252] unsigned int(3) numTemporalLayers;

[0253] unsigned int(1) temporalIdNested;

[0254] unsigned int(2) lengthSizeMinusOne;

[0255] unsigned int(8) numOfArrays;

[0256] for (j=0; j < numOfArrays; j++) {

[0257] unsigned int(1) array_completeness;

[0258] bit(1) reserved = 0;

[0259] unsigned int(6) NAL_unit_type;

[0260] unsigned int(16) numNalus;

[0261] for (i=0; i< numNalus; i++) {

[0262] unsigned int(16) nalUnitLength;

[0263] bit(8 nalUnitLength) nalUnit;

[0264] }

[0265] }

[0266] }

[0267] In these records, the bits for the parameters "reserved" and "configurationVersion" have predetermined values ​​equal to 1 (or 0). Therefore, the encapsulation process marks these parameters as optional according to the criteria checked in step 202.

[0268] The parameters “avgFrameRate”, “constantFrameRate”, and “numTemporalLayers”, as well as temporalIdNested, are video-related and inconsistent for still image content. Therefore, in step 204, the encapsulation process determines them to be optional.

[0269] Therefore, the encapsulation process can (in step 206) generate a compact HEVC decoder configuration according to the first embodiment, including the following parameters. This CompactHEVCDecoderConfigurationRecord (or condensedHEVCDecoderConfigurationRecord) can be signaled, for example, in a CompactHEVCDecoderConfigurationBox (or CondensedHEVCDecoderConfigurationBox) having a 'hvcc' four-character codebox type (the presence of these four-character codes indicates that the compact description mode is active):

[0270] aligned(8) class CompactHEVCDecoderConfigurationBox extends Box('hvcc') {

[0271] CompactHEVCDecoderConfigurationRecord () hevcConfig;

[0272] }

[0273] aligned(8) class CompactHEVCDecoderConfigurationRecord {

[0274] unsigned int(2) general_profile_space;

[0275] unsigned int(1) general_tier_flag;

[0276] unsigned int(5) general_profile_idc;

[0277] unsigned int(32) general_profile_compatibility_flags;

[0278] unsigned int(48) general_constraint_indicator_flags;

[0279] unsigned int(8) general_level_idc;

[0280] unsigned int(12) min_spatial_segmentation_idc;

[0281] unsigned int(2) parallelismType;

[0282] unsigned int(2) chroma_format_idc;

[0283] unsigned int(3) bit_depth_luma_minus8;

[0284] unsigned int(3) bit_depth_chroma_minus8;

[0285] unsigned int(16) avgFrameRate;

[0286] unsigned int(2) constantFrameRate;

[0287] unsigned int(3) numTemporalLayers;

[0288] unsigned int(1) temporalIdNested;

[0289] unsigned int(2) lengthSizeMinusOne;

[0290] unsigned int(8) numOfArrays;

[0291] for (j=0; j < numOfArrays; j++) {

[0292] unsigned int(1) array_completeness;

[0293] unsigned int(6) NAL_unit_type;

[0294] unsigned int(16) numNalus;

[0295] for (i=0; i< numNalus; i++) {

[0296] unsigned int(16) nalUnitLength;

[0297] bit(8 nalUnitLength) nalUnit;

[0298] }

[0299] }

[0300] trailing_bits()

[0301] }

[0302] In another example, the syntax of the AVC decoder configuration is as follows, according to ISO / IEC 14496-15:

[0303] aligned(8) class AVCDecoderConfigurationRecord {

[0304] unsigned int(8) configurationVersion = 1;

[0305] unsigned int(8) AVCProfileIndication;

[0306] unsigned int(8) profile_compatibility;

[0307] unsigned int(8) AVCLevelIndication;

[0308] bit(6) reserved = '111111'b;

[0309] unsigned int(2) lengthSizeMinusOne;

[0310] bit(3) reserved = '111'b;

[0311] unsigned int(5) numOfSequenceParameterSets;

[0312] for (i=0; i< numOfSequenceParameterSets; i++) {

[0313] unsigned int(16) sequenceParameterSetLength ;

[0314] bit(8 sequenceParameterSetLength) sequenceParameterSetNALUnit;

[0315] }

[0316] unsigned int(8) numOfPictureParameterSets;

[0317] for (i=0; i< numOfPictureParameterSets; i++) {

[0318] unsigned int(16) pictureParameterSetLength;

[0319] bit(8 pictureParameterSetLength) pictureParameterSetNALUnit;

[0320] }

[0321] if( AVCProfileIndication != 66 && AVCProfileIndication != 77 &&AVCProfileIndication != 88 )

[0322] {

[0323] bit(6) reserved = '111111'b;

[0324] unsigned int(2) chroma_format;

[0325] bit(5) reserved = '11111'b;

[0326] unsigned int(3) bit_depth_luma_minus8;

[0327] bit(5) reserved = '11111'b;

[0328] unsigned int(3) bit_depth_chroma_minus8;

[0329] unsigned int(8) numOfSequenceParameterSetExt;

[0330] for (i=0; i< numOfSequenceParameterSetExt; i++) {

[0331] unsigned int(16) sequenceParameterSetExtLength;

[0332] bit(8 sequenceParameterSetExtLength)sequenceParameterSetExtNALUnit;

[0333] }

[0334] }

[0335] }

[0336] In these records, the parameter "configurationVersion" and the reserved field bits have predetermined values ​​equal to 1 (or 0). Therefore, the encapsulation process marks these parameters as optional according to the criteria checked in step 202.

[0337] Therefore, the encapsulation process can (in step 206) generate a compact AVC decoder configuration according to the first embodiment, including the following parameters. This CompactAVCDecoderConfigurationRecord (or CondensedAVCDecoderConfigurationRecord) can be signaled, for example, in a CompactAVCDecoderConfigurationBox (or CondensedAVCDecoderConfigurationBox) of type 'avcc' four-character codebox:

[0338] aligned(8) class CompactAVCDecoderConfigurationBox extends Box('avcc') {

[0339] CompactAVCDecoderConfigurationRecord () avcConfig;

[0340] }

[0341] aligned(8) class CompactAVCDecoderConfigurationRecord {

[0342] unsigned int(8) AVCProfileIndication;

[0343] unsigned int(8) profile_compatibility;

[0344] unsigned int(8) AVCLevelIndication;

[0345] unsigned int(2) lengthSizeMinusOne;

[0346] unsigned int(5) numOfSequenceParameterSets;

[0347] for (i=0; i< numOfSequenceParameterSets; i++) {

[0348] unsigned int(16) sequenceParameterSetLength;

[0349] bit(8 sequenceParameterSetLength) sequenceParameterSetNALUnit;

[0350] }

[0351] unsigned int(8) numOfPictureParameterSets;

[0352] for (i=0; i< numOfPictureParameterSets; i++) {

[0353] unsigned int(16) pictureParameterSetLength;

[0354] bit(8 pictureParameterSetLength) pictureParameterSetNALUnit;

[0355] }

[0356] if( AVCProfileIndication != 66 && AVCProfileIndication != 77 &&

[0357] AVCProfileIndication != 88 )

[0358] {

[0359] unsigned int(2) chroma_format;

[0360] unsigned int(3) bit_depth_luma_minus8;

[0361] unsigned int(3) bit_depth_chroma_minus8;

[0362] unsigned int(8) numOfSequenceParameterSetExt;

[0363] for (i=0; i< numOfSequenceParameterSetExt; i++) {

[0364] unsigned int(16) sequenceParameterSetExtLength;

[0365] bit(8 sequenceParameterSetExtLength)sequenceParameterSetExtNALUnit;

[0366] }

[0367] }

[0368] trailing_bits()

[0369] }

[0370] The semantics of the parameters in this box remain unchanged compared to a traditional AVC decoder configuration.

[0371] Similar methods can also be used for SVCDecoderConfigurationRecord, MVCDecoderConfigurationRecord, LHEVCDecoderConfigurationRecord, EVCDecoderConfigurationRecord and LCEVCDecoderConfigurationRecord according to ISO / IEC 14496-15.

[0372] Although this document primarily describes an example of a decoder configuration used for 2D video content encoded with an MPEG codec, similar methods can be used for any decoder or codec configuration that may have optional parameters. Furthermore, this embodiment can also be used for codec or decoder configurations for volumetric or 3D content or audio content.

[0373] In another embodiment, a conventional decoder configuration includes parameters encoded using several bits. Encapsulation processing can compress these parameters by limiting their maximum values. For example... Figure 2b As shown, the generation of the compact decoder configuration has been modified.

[0374] As in the previous embodiments, the parameters are processed sequentially. In addition to the criteria described in the previous embodiments, the generation of the decoder configuration determines whether the parameters can be compressed during step 207. During step 207, a check can be performed to assess whether the parameter length in bits exceeds a predetermined threshold. When it exceeds the threshold, the parameter can be encoded using a more compact coded representation and is marked as compressible in step 208. Otherwise, the parameter is marked as required.

[0375] The predetermined threshold can be set by a user, a computer program, or it can correspond to a predetermined value defined, for example, in a standard implemented in a packaged format.

[0376] During step 207, the maximum parameter value for a particular parameter can be calculated based on all possible values ​​of that parameter. If this maximum parameter value can be encoded using less code than that used in a regular wrapper pattern for a particular format, then such code is used to encode all (or at least one) parameter values ​​for that parameter.

[0377] In the final step 206, the encapsulation module generates a compact decoder configuration that contains only the "required" and "compressible" parameters.

[0378] For example, a parameter that is known to have a value that typically uses less than 8 bits of encoding but is 16-bit encoded can be encoded using a reduced number of bits (e.g., at most 8 bits). Thus, several bits are saved within the signal notification of a compact description of the decoder configuration.

[0379] In such an embodiment, if the compact description mode is selected, the method for encapsulation includes the following steps:

[0380] - Determine the length of at least one decoder configuration parameter, and

[0381] - If the length of at least one decoder configuration parameter is greater than a length threshold, the at least one decoder configuration parameter is compressed, and the compressed at least one decoder configuration parameter is used to generate an image description and / or an image header during the generation step.

[0382] To prevent the encapsulation process from using a compact codec configuration when the value exceeds a predetermined threshold, step 102 can check whether one of the encoding configuration parameters exceeds its predetermined threshold. In this case, the encapsulation may not use a compact description and instead use a conventional (i.e., non-compact) media file description to generate that portion of the image description.

[0383] In a variant, when the parameter value exceeds a predetermined threshold, step 208 is modified. All parameters of the decoder configuration are marked as required, and the processing loop stops. This indicates that the encapsulation process cannot compress the decoder configuration. In this case, the compact decoder configuration generated in step 206 is the same as the conventional decoder configuration. This corresponds to the conventional syntax of falling back to the decoder configuration. In this case, the decoder configuration should not be signaled as a compact decoder configuration.

[0384] In another example, when the parameters primarily have a small range of values, a variable-length compression method is used for parameters marked as compressible. Variable-length encoding can be, for example, exp-golomb (exponential Golomb code) or varint (variable-length integer) encoding.

[0385] In the VVC decoder configuration log, parameters such as the number of arrays allow specifying up to 256 arrays to carry initialization non-VCL NAL units. For a compact image description of a single image, this number can be reduced to a lower number. For example, there are a maximum of 19 types of non-VCL NAL units in VVC. Additionally, only DCI, OPI, VPS, SPS, PPS, prefix APS, and prefix SEI NAL units are typically provided in the decoder configuration. Therefore, a maximum of 7 arrays are actually needed. For this reason, the length of the `num_of_arrays` parameter can be limited to 3 bits. The same principle applies to HEVC decoder configurations: in a traditional HEVC decoder configuration, the number of arrays can be up to 32, and a maximum of 5 NAL units (e.g., VPS, SPS, PPS, prefix SEI, or suffix SEI NAL units) can be stored in these arrays. Therefore, for most bitstreams, a maximum of 5 arrays are actually needed. For this reason, the length of the `num_of_arrays` parameter can be limited to 3 bits.

[0386] In VVC decoder configurations, the `NAL_unit_type` length allows specifying up to 32 different NAL unit types, while only 7 types of NAL units can actually be provided in the array. Therefore, the `NAL_unit_type` length is limited to 3 bits, and the following values ​​are used to indicate the NAL unit types in the array: when `NAL_unit_type` equals 0, it corresponds to `OPI_NUT`; for `DCI_NUT`, `NAL_unit_type` equals 1; for `VPS_NUT`, `NAL_unit_type` equals 2; for `SPS_NUT`, `NAL_unit_type` equals 3; for `PPS_NUT`, `NAL_unit_type` equals 4; for `PREFIX_APS_NUT`, `NAL_unit_type` equals 5; and for `PREFIX_SEI_NUT`, `NAL_unit_type` equals 6. For HEVC decoder configurations, the `NAL_unit_type` field allows defining more than 5 NAL units that are allowed to be declared in the decoder configuration. For VVC decoder configurations, the NAL_unit_type field in the compact decoder configuration is encoded using up to 3 bits, and a value of this field is associated with each of the five NAL units.

[0387] For each array, up to 65536 NAL units can be specified in the VVC decoder configuration. In practice, at most one OPI, VPS, SPS, or PPS is provided for a single image. Therefore, the num_nalus parameter is inferred to be equal to 1 for all such NAL unit types. For prefix APS and prefix SEI NAL units, the number can be slightly larger. Therefore, a num_nalus parameter exists for prefix APS and prefix SEINAL units, but it is limited to 3 bits to limit the number of provided SEI and APS NAL units to 8. For the HEVC decoder configuration, a similar approach can be used to encode the numNalus parameter in the compact HEVC decoder configuration using, for example, 3 bits used for prefix or suffix SEINAL units. For other NAL unit types, the numNalus parameter is inferred to be equal to 1. For the AVC decoder configuration, a similar approach can be used to encode the numOfSequenceParameterSets, numOfPictureParameterSets, and numOfSequenceParameterSetExt parameters in the compact HEVC decoder configuration, which can be inferred to be equal to 1, for example.

[0388] The length of each NAL unit in bytes is signaled in the VVC decoder configuration and is limited to 65536 bytes. In practice, the size of a NAL unit is smaller than this value and can be represented using 10 bits in most cases. Therefore, the bit length of nal_unit_length is limited to a lower number of bits, for example, less than or equal to 10 bits. For AVC and HEVC decoder configurations, in the corresponding compact decoder configurations, the fields indicating the bit length of the NAL unit (e.g., nalUnitLength for HEVC and sequenceParameterSetLength, pictureParameterSetLength, and sequenceParameterSetExtLength for AVC) can be limited to 10 bits.

[0389] The `array_completeness` flag allows you to indicate whether all NAL units of a given type are present in the VVC or HEVC decoder configuration and are not present in the sample or item data of the image. For a single image, when the value of `array_completeness` is set to 1 for a given NAL unit type, it is likely that the value of `array_completeness` is the same for all NAL unit types described in the decoder configuration. Therefore, the `array_completeness` value is specified only for the first array entry, while for other array entries in the compact decoder configuration, the `array_completeness` value is inferred to be equal to the same value.

[0390] In a variation, in the compact decoder configuration, even for the first array entry, the array_completeness value is not signaled, and it is inferred to be a predetermined value. For example, the array_completeness value could be inferred to be equal to 1 to indicate that all configuration NAL units are provided in the compact decoder configuration and are not copied in the image item data.

[0391] The VVC decoder configuration can provide information about the output layer set index, which is represented by the referenced CVS. In a traditional VVC decoder configuration, the maximum value of ols_idx is 512. In practice, the number of output layer sets indicated in the VVC bitstream is relatively low. The number of output layer sets that can exist in the bitstream is proportional to the number of layers in the bitstream. In fact, for some VVC grades, the number of layers present in a still image can be equal to 1. Therefore, if the VVC grade used does not allow multiple layers, ols_idx can be removed. Grade signaling is performed in the VvcPTLRecord. Therefore, in the compact decoder configuration record, ols_idx is signaled after the grade indication. The VvcPTLRecord also specifies ptl_multilayer_enabled_flag, which also indicates whether multiple layers are used. Therefore, the existence of ols_idx is conditional upon ptl_multilayer_enabled_flag being equal to 1.

[0392] When multiple layers can be used (i.e., ptl_multilayer_enabled_flag equals 1), a total of 128 layers are allowed. In practice, for small images, the number of layers can be limited to 8. Therefore, lower bit depths (e.g., 3 bits) are sufficient to describe the index of the output layer set.

[0393] The syntax of the compact decoder configuration can be, for example, a combination of the previous embodiments as follows.

[0394] aligned(8) class CompactVvcDecoderConfigurationBox extends Box('vvcc') {

[0395] CompactVvcDecoderConfigurationRecord () vvcConfig;

[0396] }

[0397] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0398] unsigned int(2) LengthSizeMinusOne;

[0399] unsigned int(1) ptl_present_flag;

[0400] if (ptl_present_flag) {

[0401] unsigned int(2) chroma_format_idc;

[0402] unsigned int(3) bit_depth_minus8;

[0403] VvcPTLRecord(1) native_ptl;

[0404] if (native_ptl.ptl_multilayer_enabled_flag == 1)

[0405] unsigned int(3) ols_idx;

[0406] unsigned_int(16) max_picture_width;

[0407] unsigned_int(16) max_picture_height;

[0408] }

[0409] unsigned int(3) num_of_arrays;

[0410] for (j=0; j < num_of_arrays; j++) {

[0411] if (j == 0)

[0412] unsigned int(1) array_completeness;

[0413] unsigned int(3) NAL_unit_type_idc;

[0414] if (NAL_unit_type_idc >= 5)

[0415] unsigned int(3) num_nalus;

[0416] else

[0417] num_nalus = 1

[0418] for (i=0; i< num_nalus; i++) {

[0419] unsigned int(10) nal_unit_length;

[0420] bit(8 nal_unit_length) nal_unit;

[0421] }

[0422] }

[0423] trailing_bits()

[0424] }

[0425] Except for NAL_unit_type_idc and ols_idx, the semantics of the parameters remain unchanged. NAL_unit_type_idc indicates the type of the NAL units in the following array (which should all be of this type); it can take the following values:

[0426] - NAL_unit_type_idc equals 0, indicating that the NAL unit is an OPI NAL unit;

[0427] - NAL_unit_type_idc equals 1, NAL unit is DCI NAL unit;

[0428] - NAL_unit_type_idc equals 2, NAL unit is VPS NAL unit;

[0429] - NAL_unit_type_idc equals 3, NAL unit is SPS NAL unit;

[0430] - NAL_unit_type_idc equals 4, NAL unit is PPS NAL unit;

[0431] - NAL_unit_type_idc equals 5, NAL unit is prefix APS NAL unit;

[0432] - NAL_unit_type_idc equals 6, NAL unit is prefix SEI NAL unit.

[0433] ols_idx specifies the index of the output layer set represented by the referenced CVS (if it exists). If it does not exist, ols_idx is inferred to be equal to 0.

[0434] In another embodiment, the decoder configuration includes a set of parameters that may be useful for initializing the decoder, or (one or more) required SEI NAL units. To further compress the bitstream, the encapsulation process can constrain the type and order of the NAL units present in the compact decoder configuration.

[0435] For example, the order of NAL units can follow the presence probability of NAL units in the decoder configuration. In most cases, the NAL units present in the decoder configuration record are a set of parameters in the order of activation and use of VCL NAL units.

[0436] For example, mandatory NAL units are placed first, followed by optional NAL units. Generally, in a bitstream, the presence of parameter set NAL units such as VPS, SPS, and PPS NAL units is mandatory for encapsulation according to the codec specification. Other parameter set NAL units are optional because they depend on the activation of a particular encoding tool. However, these other parameter set NAL units are mandatory when some encoding tools are enabled. This is the case for the APS NAL unit, for example, in VVC. In this case, these other parameter set NAL units are placed immediately after the mandatory NAL unit. Other NAL units are optional and not necessary for proper decoding of the bitstream. This is the case for DCI, OPI, and SEI NAL units. DCI and OPI NAL units can be used to indicate which layer should be decoded by the decoder, and therefore they are more important than the generally included SEI NAL units, which contain supplementary information that is not mandatory for decoding the bitstream.

[0437] Therefore, the order of NAL units could be, for example, first VPS, then SPS, PPS and APS (if any) NAL units, followed by DCI OPI, and finally prefix SEI NAL units.

[0438] Other NAL units, such as DCI or OPI and prefix SEI, are unlikely to be used. Therefore, the encapsulation can indicate, for example, a parameter following the most important set of parameters to indicate whether additional NAL units exist in the decoder configuration. For example, when the parameter equals 0, it indicates that no additional NAL units exist in the decoder configuration. Otherwise, when the parameter equals 1, it indicates that additional NAL units exist in the decoding configuration.

[0439] In such an embodiment, if a compact description mode is selected, the method may further include a step for estimating the likelihood of using at least one network abstraction layer unit parameter. During the generation step, image descriptions and / or image heads can be generated using the respective network abstraction layer parameters associated with the usage likelihood estimate greater than a threshold.

[0440] Based on the predetermined order of NAL units in the decoder configuration, the parser can determine the type of the NAL units.

[0441] The syntax of the compact decoder configuration can be, for example, a combination of the previous embodiments as follows:

[0442] aligned(8) class CompactVvcDecoderConfigurationBox extends Box('vvcc') {

[0443] CompactVvcDecoderConfigurationRecord () vvcConfig;

[0444] }

[0445] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0446] unsigned int(2) LengthSizeMinusOne;

[0447] unsigned int(1) ptl_present_flag;

[0448] if (ptl_present_flag) {

[0449] unsigned int(2) chroma_format_idc;

[0450] unsigned int(3) bit_depth_minus8;

[0451] VvcPTLRecord(1) native_ptl;

[0452] if (native_ptl.ptl_multilayer_enabled_flag == 1)

[0453] unsigned int(3) ols_idx;

[0454] unsigned_int(16) max_picture_width;

[0455] unsigned_int(16) max_picture_height;

[0456] }

[0457] unsigned int(1) nal_units_present_flag;

[0458] if (nal_units_present_flag) {

[0459] unsigned int(1) array_completeness;

[0460] unsigned int(8) vps_nal_unit_length;

[0461] bit(8 vps_nal_unit_length) vps_nal_unit;

[0462] unsigned int(8) sps_nal_unit_length;

[0463] bit(8 sps_nal_unit_length) sps_nal_unit;

[0464] unsigned int(8) pps_nal_unit_length;

[0465] bit(8 pps_nal_unit_length) pps_nal_unit;

[0466] unsigned int(1) additional_nal_unit_flag;

[0467] if (additional_nal_unit_flag) {

[0468] unsigned int(3) num_aps_nal_unit;

[0469] unsigned int(3) num_sei_nal_unit;

[0470] for (i=0; i< num_aps_nalus; i++) {

[0471] unsigned int(8) aps_nal_unit_length;

[0472] bit(8 aps_nal_unit_length) aps_nal_unit;

[0473] }

[0474] for (i=0; i< num_sei_nalus; i++) {

[0475] unsigned int(8) sei_nal_unit_length;

[0476] bit(8 sei_nal_unit_length) sei_nal_unit;

[0477] }

[0478] }

[0479] }

[0480] trailing_bits()

[0481] }

[0482] The semantics remain unchanged except for the following parameters:

[0483] The nal_units_present_flag indicates that NAL units exist in the decoder configuration.

[0484] `vps_nal_unit_length` indicates the length of the NAL unit in bytes. When it equals 0, the VPS NAL unit does not exist.

[0485] vps_nal_unit contains VPS NAL units as specified in ISO / IEC 23090-3.

[0486] sps_nal_unit_length indicates the length of the NAL unit in bytes. When it is equal to 0, the SPS NAL unit does not exist.

[0487] sps_nal_unit contains SPS NAL units as specified in ISO / IEC 23090-3.

[0488] `pps_nal_unit_length` indicates the length of the NAL unit in bytes. When it equals 0, the PPS NAL unit does not exist.

[0489] pps_nal_unit contains PPS NAL units as specified in ISO / IEC 23090-3.

[0490] An additional_nal_unit_flag of 1 indicates that an additional NAL unit exists in the decoder configuration record, while an additional_nal_unit_flag of 0 indicates that no additional NAL unit exists in the decoder configuration record.

[0491] num_aps_nal_unit indicates the number of APS NAL units included in the configuration record of the referenced CVS.

[0492] num_sei_nal_unit indicates the number of SEI NAL units included in the configuration record of the referenced CVS.

[0493] aps_nal_unit_length indicates the length of an APS NAL unit in bytes.

[0494] aps_nal_unit contains APS NAL units as specified in ISO / IEC 23090-3.

[0495] sei_nal_unit_length indicates the length of the SEI NAL unit in bytes.

[0496] sei_nal_unit contains SEI NAL units as specified in ISO / IEC 23090-3.

[0497] In a variation, the type and / or order of NAL units are unrestricted in the bitstream. The type of NAL units is defined in the NAL unit header of the NAL units provided in the decoder or codec configuration. Therefore, the decoder can determine the type of a NAL unit by parsing the type specified in the NAL unit header of each NAL unit present in the configuration record. The number of NAL units present in the decoder configuration record is signaled. Then, the length and data of each NAL unit in bytes are indicated in the decoder configuration.

[0498] In another variation to avoid having to specify the number and length of NAL units signaled in the decoder configuration, the encapsulation process provides NAL units as a collection of NAL units separated by start codes. Anti-emulation bytes can be inserted to prevent unwanted emulated start codes from appearing in the buffer storing the NAL unit collection. For example, for VVC, HEVC, or AVC codecs, the NAL unit collection forms a bitstream conforming to the byte stream format of the corresponding codec specification.

[0499] In another embodiment, a compact decoder configuration can constrain the decoder configuration to not transmit any NAL units. In this case, the decoder configuration parameters associated with the NAL units are predetermined. For example, for a VVC decoder configuration, num_of_arrays is predetermined to be equal to 0; for a HEVC decoder configuration, numOfArrays is predetermined to be equal to 0; and for AVC, numOfSequenceParameterSets, numOfPictureParameterSets, and numOfSequenceParameterSetExt are inferred to be equal to 0.

[0500] In another embodiment, in order to efficiently encode parameters in the decoder configuration, the encapsulation process may rely on the encoded representation used in the minimized image box to limit the length of the parameters in the decoder configuration.

[0501] MinimizedImageBox can define parameters or indicators to limit the range of some parameters that encode the attributes of an image. For example, an indicator can limit the size of the parameters that encode the width and height of the image (i.e., the image size) to be represented at a predetermined maximum number of bits.

[0502] The encapsulation process can encode the image size data encoded in the codec or decoder configuration box using the same encoding representation used for the image size parameters encoded in the MinimizeImageBox.

[0503] Additionally, minimizing the image box can specify the length of the codec or decoder configuration data associated with the item. The bit-level length of this parameter limits the length of the NAL units present in the decoder or codec configuration. In practice, the length of the NAL units present in the decoder configuration must be less than the length of the decoder configuration. Therefore, the number of bits used to encode the length of the NAL units present in the decoder configuration must be less than or equal to the number of bits used to encode the length of the decoder configuration.

[0504] The encapsulation process can encode the NAL unit length in the codec or decoder configuration record using an encoded representation of the length of the codec or decoder configuration used in the MinimizedImageBox.

[0505] The syntax of the CompactVvcDecoderConfigurationRecord generated by the encapsulation process can be as follows:

[0506] aligned(8) class CompactVvcDecoderConfigurationRecord(unsigned intbit_len_dim, unsigned int bit_len_coded_sizes) {

[0507] unsigned int(2) LengthSizeMinusOne;

[0508] unsigned int(1) ptl_present_flag;

[0509] if (ptl_present_flag) {

[0510] unsigned int(9) ols_idx;

[0511] unsigned int(2) chroma_format_idc;

[0512] unsigned int(3) bit_depth_minus8;

[0513] VvcPTLRecord(1) native_ptl;

[0514] unsigned int(bit_len_dim) max_picture_width;

[0515] unsigned int(bit_len_dim) max_picture_height;

[0516] }

[0517] unsigned int(1) array_completeness;

[0518] unsigned int(bit_len_coded_sizes) vps_nal_unit_length;

[0519] bit(8 vps_nal_unit_length) vps_nal_unit;

[0520] unsigned int(bit_len_coded_sizes ) sps_nal_unit_length;

[0521] bit(8 sps_nal_unit_length) sps_nal_unit;

[0522] unsigned int(bit_len_coded_sizes ) pps_nal_unit_length;

[0523] bit(8 pps_nal_unit_length) pps_nal_unit;

[0524] trailing_bits()

[0525] }

[0526] The `bit_len_dim` and `bit_len_coded_sizes` parameters of this class indicate the bit-length of the image size parameters (i.e., `max_picture_width` and `max_picture_height`) and the bit-length of the encoded size of the NAL cell length parameter, respectively. The wrapper process can initialize these values ​​to the bit-length of the image size parameters and the bit-length of the configuration data length parameter used in the MinimizedImageBox.

[0527] In another embodiment, the decoder configuration indicates the use of a predetermined number of bits to encode profile, hierarchy, and level information. In practice, the number of profiles, hierarchy, and level (PTL) defined by the codec specification is finite. Therefore, instead of defining a wide range of bits for these parameters, the encapsulation process can reduce the number of bits used to encode the PTL parameters. The values ​​of these new parameters can indicate the profile based on a predetermined set of values. For example, in the VVC decoder configuration, the parameter `general_profile_idc` could have a value of 1 for main 10 profiles, 65 for main 10 still image profiles, 33 for main 10 4:4:4 profiles, 97 for main 10 4:4:4 still image profiles, 17 for multi-level main 10 profiles, 49 for multi-level main 10 4:4:4 profiles, 2 for main 12 profiles, 10 for main 12 intra-frame profiles, and 66 for main 12 still image profiles, etc. This represents a total of 17 possible values. Therefore, instead of using 8 bits to encode this parameter, `general_profile_idc` is encoded in 5 bits. Each value of the new compressed `general_profile_idc` parameter is associated with one of the values ​​of the uncompressed `general_profile_idc` defined in ISO / IEC 23090-3. In a variation, a flag can be encoded in the compact decoder configuration, which can be set to 1 to indicate that the compressed version of `general_profile_idc` does not reference a predetermined profile, and in this case, an additional 8-bit field is provided to encode the uncompressed value of `general_profile_idc` (i.e., the full range of possible values ​​for the profile). A similar approach can be used for other parameters of the PTL structure in the decoder configuration.

[0528] In another embodiment, the encapsulation process can avoid specifying parameters in the compact decoder configuration box that can be derived from the parameters indicated in the MinimizedImageBox. For example, parameters can be provided in the header of the MinimizedImageBox or at the beginning of the MinimizedImageBox.

[0529] Figure 2c This illustrates the generation of a compact configuration. As in the previous embodiments, the parameters are processed sequentially. In addition to the guidelines of the previous embodiments, step 209 also checks whether the parameters provided in the conventional decoder configuration box can be derived from the parameters encoded previously in the configuration box in the MinimizedImageBox.

[0530] When step 209 indicates that the parameter can be derived from the parameter previously encoded in the MinimizedImageBox, the parameter is marked as redundant in step 210.

[0531] For example, the decoder configuration box can provide parameters specifying the image size, chroma format, and bit depth for the pixel values ​​of the image. Since similar parameters are also provided at the beginning of the mini-box, there is redundancy.

[0532] In such an embodiment, if a compact description mode is selected, the method for encapsulation further includes a step of determining whether decoder configuration parameters are deducible, wherein the individual configuration parameters determined to be non-derivable are used to generate an image description and / or an image header during the generation step.

[0533] It should be understood that a parameter can be considered derivable if its value can be derived from the value of another parameter in the image file format metadata.

[0534] Therefore, in step 206, the encapsulation process can generate a compact decoder configuration without these parameters. The parser can infer the values ​​of the conventional decoder configuration box based on minimizing the parameters provided in the image box. In the final step 206, the encapsulation module generates a compact decoder configuration that contains only the "required" and "compressible" parameters, without any optional or redundant parameters.

[0535] For example, the VVC decoder configuration record defined in ISO / IEC 14496-15 contains `chroma_format_idc`, which indicates the chroma format applied to the referenced CVS. The minimized image box also defines chroma subsampling parameters. These two parameters have the same semantics, therefore the value of `chroma_format_idc` and its value in `MinimizedImageBox` are redundant.

[0536] Therefore, the encapsulation process generates a compact VVC decoder configuration that does not indicate the chroma_format_idc parameter. The parser uses the subsampling information provided in the MinimizedImageBox to determine the value of chroma_format_idc in the traditional VVC decoder configuration.

[0537] In another example, the HEVC decoder configuration record, as defined in ISO / IEC 14496-15, contains chroma_format_idc, which has the same semantics as that in MinimizedImageBox and can therefore be considered redundant.

[0538] The MinimizedImageBox also specifies the image dimensions, namely the width and height of the main item. This information is also provided in the VVC decoder configuration. To further compress the VVC decoder configuration, the encapsulation process generates a compact VVC decoder configuration record without indicating the image size. The parser then uses the image size information, as specified in the MinimizedImageBox, to determine the values ​​in the traditional decoder configuration record.

[0539] For example, the encapsulation can generate the following compact decoder configuration record where the parameters chroma_format_idc, bit_depth_minus8, max_picture_width, and max_picture_height are absent. The parser will infer the values ​​of these parameters from the parameters encoded in the MinimizedImageBox.

[0540] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0541] unsigned int(2) LengthSizeMinusOne;

[0542] unsigned int(1) ptl_present_flag;

[0543] if (ptl_present_flag) {

[0544] VvcPTLRecord(1) native_ptl;

[0545] if (native_ptl.ptl_multilayer_enabled_flag == 1)

[0546] unsigned int(3) ols_idx;

[0547] }

[0548] unsigned int(1) nal_units_present_flag;

[0549] if (nal_units_present_flag) {

[0550] unsigned int(1) array_completeness;

[0551] unsigned int(8) vps_nal_unit_length;

[0552] bit(8 vps_nal_unit_length) vps_nal_unit;

[0553] unsigned int(8) sps_nal_unit_length;

[0554] bit(8 sps_nal_unit_length) sps_nal_unit;

[0555] unsigned int(8) pps_nal_unit_length;

[0556] bit(8 pps_nal_unit_length) pps_nal_unit;

[0557] unsigned int(1) additional_nal_unit_flag;

[0558] if (additional_nal_unit_flag) {

[0559] unsigned int(3) num_aps_nal_unit;

[0560] unsigned int(3) num_sei_nal_unit;

[0561] for (i=0; i< num_aps_nalus; i++) {

[0562] unsigned int(8) aps_nal_unit_length;

[0563] bit(8 aps_nal_unit_length) aps_nal_unit;

[0564] }

[0565] for (i=0; i< num_sei_nalus; i++) {

[0566] unsigned int(8) sei_nal_unit_length;

[0567] bit(8 sei_nal_unit_length) sei_nal_unit;

[0568] }

[0569] }

[0570] }

[0571] trailing_bits()

[0572] }

[0573] The compact decoder configuration is not necessarily restricted to use within a MinimizedImageBox and can be used in other contexts or boxes.

[0574] In another embodiment, the compact decoder configuration replaces the regular or conventional decoder configuration in the SampleEntry of a track (e.g., a video track or an image sequence track). The compact decoder configuration may also replace the decoder configuration properties associated with an image item, or the compact image properties may be defined using fields corresponding to the parameters of the compact decoder configuration.

[0575] The same compaction method described in the previous embodiments remains valid for the parameters of the compact decoder configuration in the SampleEntry of the track. Parameters marked as optional or compressible can be handled as in the previous embodiments. Regarding the parameters that can be derived in step 209, encapsulation and decapsulation can rely on parameters provided in the track cassette (such as the track head cassette, etc.) to infer the values ​​of the decoder configuration parameters, or via a dedicated sample entry type. For example, the image size specified in the track can be used to infer the image size recorded by the compact decoder configuration.

[0576] In another embodiment, the compact description may include additional information generated by the encapsulation process. The parser can use this additional information to determine the characteristics of compression for the decoder configuration box. This information may be, for example, a set of bits indicating the presence of parameters in the compact description. For example, the first bit indicates that a predetermined parameter is not present in the compact decoder configuration. The second bit indicates that an inconsistent parameter is not present in the compact decoder configuration. The third bit indicates that a compressible parameter has been compressed in the compact decoder configuration. The fourth bit indicates that a deducible parameter is not present in the compact decoder configuration.

[0577] In variations, additional information indicates the compaction level (or degree of compaction) used for the compact description. For example, a first level indicates that a predetermined parameter is absent in the compact decoder configuration. A second level indicates that both predetermined and inconsistent parameters are absent in the compact decoder configuration. A third level indicates that both predetermined and inconsistent parameters are absent in the compact decoder configuration, and compressible parameters have been compressed in the compact decoder configuration. In addition to the constraints of the third level, a fourth level also indicates that no deducible parameters are absent in the compact decoder configuration. The level information can be, for example, an integer parameter encoded in 2 bits. In variations, any selection and / or combination of compaction features (i.e., removal of optional parameters, removal of inconsistent parameters, removal of redundant parameters, or compression of compressible parameters) can be associated with a level.

[0578] In another variation, additional information can be inferred when a brand is present in the list of compatible brands for a file. For example, the brand 'ccnf' could instruct the compact decoder to be configured for boxes present in the file (e.g., including sample entries and / or MinimizedImageBoxes). Brands can be associated with various compaction levels. For instance, the brand 'ccf1' could instruct the compact decoder to be configured for boxes present in the file, with the compaction level set to 1. The brand 'ccf2' could instruct the compact decoder to be configured for boxes present in the file, with the compaction level set to 2. More generally, the brand 'ccfX' (where X is a number between 0 and 9) instructs the compact decoder to be configured for boxes present in the file, with the compaction level equal to the number X.

[0579] In another embodiment, the array of parameter sets, typically placed in the decoder configuration box, is implicitly present in the data. All syntactic elements of the parameter array can then be omitted. This can be indicated by a specific item type when used for image items or by a sample entry type when used in tracks. Specifically, video tracks distinguish between tracks where the entire parameter set is in a sample entry, or tracks where the parameter set may be both in a sample entry and in the data, but there is no sample item type to indicate that they are all present in the data and not in the decoder configuration box.

[0580] In another embodiment, the parameters provided in the decoder configuration record or box are constrained to provide the necessary information for a single image (or picture). The decoder configuration record or box includes parameter set NAL units that are necessary for a single image, such as SPS or PPS NAL units in the context of VVC, HEVC, AVC, or any other NAL unit-based codec. Information considered non-necessary for a single image corresponds to optional NAL units that are not necessary for the initialization of the decoder for a single image. For example, for a VVC bitstream, this information may correspond to an APS NAL unit, or more generally, for any MPEG codec, this information may be an SEI NAL unit. Video parameter set (VPS) NAL units provide parameters describing multiple layers of multiple images or pictures being encoded. Therefore, VPS is not considered necessary information for a single image. Additionally, for multi-layer images, multiple SPS and PPS NAL units may exist (e.g., one NAL unit per layer). These NAL units specify the parameters applied to a given layer. For such images, only one set of SPS and PPS NAL units is considered necessary. For example, the decoder configuration record only provides SPS and PPS NAL units corresponding to the layers that should be displayed by default. In a variation, only the parameter set NAL unit describing the base layer (e.g., a layer with a layer identifier equal to 0) is provided.

[0581] In this embodiment, necessary information for a single image is communicated via signaling, and optional non-essential information for a single image is also provided.

[0582] For example, encapsulation can generate the following compact decoder configuration record.

[0583] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0584] unsigned int(2) lengthSizeMinusOne;

[0585] unsigned int(6) num_additional_nal_units; / / default = 0

[0586] unsigned int(8) sps_nal_unit_length;

[0587] bit(8 sps_nal_unit_length) sps_nal_unit;

[0588] unsigned int(8) pps_nal_unit_length;

[0589] bit(8 pps_nal_unit_length) pps_nal_unit;

[0590] for (i=0; i< num_additional_nal_units; i++) {

[0591] unsigned int(8) nal_unit_length[ i ];

[0592] bit(8 nal_unit_length) nal_unit[ i ];

[0593] }

[0594] }

[0595] The lengthSizeMinusOne parameter plus 1 indicates the length in bytes of the NALUnitLength field in the image item associated with this decoder configuration.

[0596] `num_additional_nal_units` indicates the number of NAL units present in the decoder configuration, in addition to indicating the mandatory or required SPS and PPS for the main image item. This parameter defaults to 0 when the decoder configuration record only provides the required information for a single layer. Otherwise, when greater than 1, this parameter indicates that non-required information for a single image is provided. Therefore, during decapsulation, the player can determine the presence of multiple layers of images when `num_additional_nal_units` is greater than 0 and one or more VPS or PPS or SPS NAL units are present in the additional unit list (which corresponds to the `nal_unit[i]` syntax element). When no required information is provided (e.g., when both `sps_nal_unit_length` and `pps_nal_unit_length` are equal to 0), the encapsulation process can constrain this parameter to 0. The purpose of this optional constraint is to ensure that the compact decoder configuration provides at least the required information for a single image, rather than only describing non-required information.

[0597] sps_nal_unit_length indicates the length of the NAL unit in bytes. When it is equal to 0, the SPS NAL unit does not exist.

[0598] sps_nal_unit contains the SPS NAL unit as specified in ISO / IEC 23090-3 (if it exists).

[0599] `pps_nal_unit_length` indicates the length of the NAL unit in bytes. When it equals 0, the PPS NAL unit does not exist. A constraint greater than 0 can be imposed on either `sps_nal_unit_length` or `pps_nal_unit_length` during encapsulation processing. This constraint ensures that the necessary information for a single image is not empty. In a variation, since the information provided in the SPS is of a higher level than that provided in the PPS, encapsulation can constrain the length of the SPS to be greater than 0 (this ensures that at least one SPS NAL unit is provided) and allow the length of the PPS to be greater than or equal to 0.

[0600] nal_unit_length[i] indicates the length in bytes of the i-th additional NAL unit stored in this property.

[0601] nal_unit[i] contains the i-th additional NAL unit as specified in ISO / IEC 23090-3. During encapsulation, the order of the additional NAL units can be constrained to follow their importance order to initialize the decoder. For example, the order of the NAL additional units can be as follows: zero or one VPS NAL unit, zero or more than zero SPS NAL units (describing additional layers different from the layers described by the SPS of the sps_nal_unit syntax element), zero or more than zero PPS NAL units (describing additional layers different from the layers described by the PPS of the pps_nal_unit syntax element), zero or more than zero APS NAL units (for any layer of the item), and zero or more than zero SEI NAL units (for any layer of the item). The advantage is that the decapsulation process can determine the presence of the VPS NAL unit by resolving only the first additional unit provided in the nal_unit[0] parameter, i.e., by resolving at most three NAL units (required SPS and PPS NAL units (if present) and the NAL unit of the nal_unit[0] parameter).

[0602] In this embodiment, the presence of the hierarchy information in the decoder configuration record (e.g., represented as ptl_present_flag according to ISO / IEC 14496-15) is skipped (e.g., ptl_present_flag is not signaled in the compact decoder configuration and is inferred to be equal to 0). In practice, this information is also generally present in the SPS or PPS NAL units. Therefore, the determination of the hierarchy information from the compact decoder configuration record is inferred from the SPS and PPS NAL units, which are provided as essential information for a single image.

[0603] The parameters describing the existence of NAL units in the decoder configuration (e.g., num_of_arrays, num_nalus, and NAL_unit_type according to ISO / IEC 14496-15) can be derived from the parameters of the compact decoder configuration. For example, when the num_additional_nal_units parameter is equal to 0, there are two arrays (num_of_arrays): one for required SPS and one for required PPS NAL units. The number of arrays can be equal to 1 when the length of either the required SPS or PPS NAL unit is set to 0. The number of arrays can be equal to 0 when the lengths of both the SPS and PPS NAL units are set to 0. For each array, the number of NAL units (num_nalus) is pre-defined to be equal to 1. The NAL_unit_type of the first array indicates the SPS NAL unit type and PPS NAL unit type of the second array (if present). When num_additional_nal_units is greater than 0, the number of arrays is incremented for each new NAL unit type resolved in the nal_unit array, and the number of NAL units of that type (num_nalus) is incremented by 1 for each NAL unit resolved.

[0604] In this embodiment, CompactVvcDecoderConfigurationRecord is considered equivalent to a VvcDecoderConfigurationRecord as defined in ISO / IEC 14496-15 with the following fields:

[0605] ● ptl_present_flag is set to 1.

[0606] ● num_sublayers is set to 1.

[0607] ● constant_frame_rate is set to 1.

[0608] ● If the codec configuration properties are associated with the main image item, then:

[0609] ○ chroma_format_idc is set to the value from the chroma_subsampling field of the MinimizedImageBox.

[0610] ● If the codec configuration properties are associated with the alpha-assisted image item, then:

[0611] ○ chroma_format_idc is set to 0.

[0612] ● If the codec configuration properties are associated with the primary image item or with the alpha auxiliary image item, then:

[0613] ○ bit_depth_minus8 is set to 0 (if the value from the high_bit_depth_flag field of MinimizedImageBox is 0), or is set to the value from the bit_depth_minus9 field of MinimizedImageBox plus 1.

[0614] ○ max_picture_width is set to the value of the width_minus1 field from the MinimizedImageBox plus 1.

[0615] ○ max_picture_height is set to the value of the height_minus1 field from the MinimizedImageBox plus 1.

[0616] ● If the codec configuration properties are associated with gain map image items, then:

[0617] ○ bit_depth_minus8 is set to 0 (if the value of the gainmap_high_bit_depth_flag field from MinimizedImageBox is 0), or is set to the value of the gainmap_bit_depth_minus9 field from MinimizedImageBox plus 1.

[0618] ○ max_picture_width is set to the value of the gainmap_width_minus1 field from MinimizedImageBox plus 1.

[0619] ○ max_picture_height is set to the value of the gainmap_height_minus1 field from the MinimizedImageBox plus 1.

[0620] ● avg_frame_rate is set to 0.

[0621] ● The native_ptl parameter is inferred from the profile_tier_level(1, sps_max_sublayers_minus1) structure defined in seq_parameter_set_rbsp() according to ISO / IEC 23090-3 for the SPS NAL unit provided in sps_nal_unit.

[0622] ● num_of_arrays is determined as follows:

[0623] ○ num_of_arrays is set to equal to 2.

[0624] ○ There exists an SPS NAL cell array, where:

[0625] ■ NAL_unit_type is set to 15 (as defined in ISO / IEC 23090-3 as SPS_NUT).

[0626] ■ num_nalus is set to 1, nal_unit_length is set to sps_nal_unit_length, and nal_unit is set to sps_nal_unit.

[0627] ○ There exists a PPS NAL cell array, where:

[0628] ■ NAL_unit_type is set to 16 (as defined in ISO / IEC 23090-3 as PPS_NUT).

[0629] ■ num_nalus is set to 1, nal_unit_length is set to pps_nal_unit_length, and nal_unit is set to pps_nal_unit.

[0630] ● If num_additional_nal_units is greater than 0, then each i-th additional unit nal_unit[i] is processed as follows:

[0631] ○ Determine the NAL unit type of nal_unit[i] (such as nal_unit_type as defined in ISO / IEC 23090-3).

[0632] ■ There exists an array of NAL units whose NAL_unit_type is set to nal_unit[i] and whose nal_unit_type is NAL_unit_type.

[0633] ● If nal_unit[i]'s nal_unit_type is neither 15 (as defined in ISO / IEC 23090-3 as SPS_NUT) nor 16 (as defined in ISO / IEC 23090-3 as PPS_NUT), and if nal_unit[i] is the first NAL unit of that NAL unit type, then num_array is incremented by 1.

[0634] ● If num_nalus is the first NAL element of the array, then num_nalus is set to 1; otherwise, num_nalus is incremented by 1.

[0635] ● The following adds a new collection of nal_unit_length and nal_unit to the array.

[0636] ○ nal_unit_length is set to nal_unit_length[i] of CompactVvcDecoderConfigurationRecord.

[0637] ○ nal_unit is set to nal_unit[i] of CompactVvcDecoderConfigurationRecord.

[0638] ● In VvcDecoderConfigurationRecord, array_completeness is set to 1.

[0639] Use the other parameters as is, and repeat if necessary.

[0640] In a variation of the previous embodiment, both necessary and unnecessary NAL units are signaled within the same signaling loop. Through the design of the decoder configuration recording semantics, the minimum number of NAL units described in the processing loop is constrained to be equal to 2. For example, a compact decoder configuration syntax can be as follows:

[0641] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0642] unsigned int(2) lengthSizeMinusOne;

[0643] unsigned int(6) num_nal_units_minus2;

[0644] for (i=0; i< num_nal_units+2; i++) {

[0645] unsigned int(8) nal_unit_length[ i ];

[0646] bit(8 nal_unit_length) nal_unit[ i ];

[0647] }

[0648] }

[0649] The semantics of the lengthSizeMinusOne and nal_unit[i] syntactic elements are the same as in the previous variant.

[0650] `num_nal_units_minus2` plus 2 indicates the number of NAL units present in the decoder configuration. The encapsulation can constrain that when `nal_unit_length[0]` is greater than 0, `nal_unit[0]` (the first NAL unit of the signaling loop) contains an SPSNAL unit; and when `nal_unit_length[1]` is greater than 0, `nal_unit[1]` (the second NAL unit of the signaling loop) contains a PPS NAL unit. To ensure that at least one set of parameter NAL units provides the necessary information for a single image, the encapsulation can constrain that only one of `nal_unit_length[0]` and `nal_unit_length[1]` is equal to 0. NAL units described after the first two NAL units correspond to non-essential information for a single image.

[0651] In another variation, the length of the last NAL unit provided in the compact decoder configuration can be inferred from the total length of the compact decoder configuration record. For example, this length can be provided before signaling the record. For instance, this length can be provided as a parameter (e.g., main_item_codec_config_size) in the MinimizedImageBox. The length of the last NAL unit is equal to the length of the compact codec configuration (main_item_codec_config_size) minus the sum of the lengths of all NAL units provided in the compact decoder configuration except the last one, and minus the lengths of other parameters provided in the compact decoder configuration unit.

[0652] For example, a compact decoder configuration can be configured using the following syntax:

[0653] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0654] unsigned int(2) LengthSizeMinusOne;

[0655] unsigned int(6) num_additional_nal_units;

[0656] unsigned int(8) sps_nal_unit_length;

[0657] bit(8 sps_nal_unit_length) sps_nal_unit;

[0658] if (num_additional_nal_units > 0)

[0659] unsigned int(8) pps_nal_unit_length;

[0660] bit(8 pps_nal_unit_length) pps_nal_unit;

[0661] for (i=0; i< num_additional_nal_units; i++) {

[0662] if (i < num_additional_nal_units – 1)

[0663] unsigned int(8) nal_unit_length[ i ];

[0664] bit(8 nal_unit_length) nal_unit[ i ];

[0665] }

[0666] }

[0667] The semantics of the parameters are the same as in the previous variant, with the following additional statements:

[0668] When it does not exist, pps_nal_unit_length is inferred to be equal to main_item_codec_config_size – 1 – sps_nal_unit_length – additional_units_length. In this formula, 1 byte is subtracted from the length of the compact decoder configuration because it corresponds to the length of lengthSizeMinusOne and num_additional_nal_units; the variable additional_units_length represents the sum of the lengths of the additional NAL units provided in the NAL unit signaling loop. Therefore, when num_additional_nal_units is greater than 1, additional_units_length is equal to the sum of nal_unit_length[i], where i is in the range from 0 to num_additional_nal_units-1 (inclusive). Otherwise, when num_additional_nal_units is less than or equal to 1, additional_units_length is inferred to be equal to 0.

[0669] Another possible syntax for the decoder configuration record is as follows:

[0670] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0671] unsigned int(2) lengthSizeMinusOne;

[0672] unsigned int(6) num_nal_units_minus2;

[0673] for (i=0; i< num_nal_units_minus2+2; i++) {

[0674] if (i < num_nal_units_minus2 + 1)

[0675] unsigned int(8) nal_unit_length[ i ];

[0676] bit(8 nal_unit_length) nal_unit[ i ];

[0677] }

[0678] }

[0679] The semantics of the parameters are the same as in the previous variant, with the following additional statement: nal_unit_length[num_nal_units_minus2 + 1] is inferred to be equal to main_item_codec_config_size – 1 – signaled_units_length. When num_nal_units_minus2 is greater than 1, the variable signaled_units_length, which is the sum of the lengths of the NAL units provided in the NAL unit signaling loop, is equal to the sum of nal_unit_length[i], where i is in the range from 0 to num_nal_units_minus2 (inclusive). Otherwise, when num_nal_units_minus2 is less than or equal to 1, signaled_units_length is inferred to be equal to 0.

[0680] In another variation of the previous embodiment, the compact decoder configuration syntax provides only the necessary information for a single image. Therefore, any syntactic elements related to signal notifications of non-essential information for a single image are removed from the compact decoder configuration record. For example, at most one SPS and one PPS NAL unit are provided in the decoder configuration record. Other non-essential information can be provided in the image item data.

[0681] For example, the syntax of the compact decoder configuration record can be as follows, and has similar semantics to the previous variant example.

[0682] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0683] unsigned int(2) lengthSizeMinusOne;

[0684] unsigned int(8) sps_nal_unit_length;

[0685] bit(8 sps_nal_unit_length) sps_nal_unit;

[0686] unsigned int(8) pps_nal_unit_length; / / optional

[0687] bit(8 pps_nal_unit_length) pps_nal_unit;

[0688] }

[0689] As in one of the previous variations that avoids signaling the length of the last NAL unit of a record (which is the length of the PPS NAL unit represented by pps_nal_unit_length in the above syntax example), the length of the last NAL unit of a record can be inferred from the length of the record. The length of the last NAL unit of a record can be derived from the record configuration length in the MinimizedImageBox ('mini' box) using the following formula: pps_nal_unit_length = main_item_codec_config_size – 1 - sps_nal_unit_length.

[0690] In another embodiment, the decoder configuration is further simplified and compressed by removing the length of the NAL units provided in the decoder configuration record. The set of NAL units provided as necessary information for a single image is the parameter set NAL unit. The syntax of these NAL units is provided in codec specifications such as VVC, HEVC, AVC, or any other MPEG codec. Therefore, the parser can determine the contents of these necessary NAL units by following the codec specification and can infer the length of the NAL units by counting the number of parsed bytes. Thus, the encapsulation process avoids signaling the length of known NAL units from the decoder configuration.

[0691] For example, considering VVC (but applicable to AVC, HEVC, or any other MPEG codec), the compact decoder configuration syntax can be as follows, with the same semantics as in the previous embodiments and variations:

[0692] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0693] unsigned int(2)    lengthSizeMinusOne;

[0694] VVC_SPSNALUnit sps_nal_unit;

[0695] VVC_PPSNALUnit pps_nal_unit;

[0696] }

[0697] aligned(8) class VVC_SPSNALUnit {

[0698] nal_unit_header( ) / / as per codec specification e.g. ISO / IEC 23090-3

[0699] seq_parameter_set_rbsp( ) / / as per codec specification e.g. ISO / IEC23090-3

[0700] }

[0701] aligned(8) class VVC_PPSNALUnit {

[0702] nal_unit_header( ) / / as per codec specification e.g. ISO / IEC 23090-3

[0703] pps_parameter_set_rbsp( ) / / as per codec specification e.g. ISO / IEC23090-3

[0704] }

[0705] In a variation, the compact decoder configuration provides NAL units with syntax that the parser may not support. For example, this syntax could correspond to optional SEI NAL units that the decoder might discard. In this case, the encapsulation process can signal these optional NAL units at the end of the decoder configuration. When the parser processes a compact decoder configuration containing NAL units with unknown syntax, it can skip all remaining NAL units up to the end of the compact decoder configuration (which can be determined using the length of the compact decoder configuration, provided, for example, as a parameter in the MinimizedImageBox).

[0706] In variations, encapsulation can use specific NAL units as delimiters between required and unnecessary NAL units of a single image, or between any resolvable and optional NAL units that the parser may not be aware of. When the parser encounters this specific delimiter NAL unit, it can consider the remaining NAL units to be optional (or unnecessary). For example, a NAL unit used as a delimiter could be a NAL unit of a type that is not typically allowed in a conventional decoder configuration. In the case of MPEG codecs, a NAL unit used as a delimiter could be, for example, an access unit delimiter or an EOB (End of Bitstream) or EOS (End of Slice) NAL unit. The advantages of EOB and EOS NAL units come from ease of parsing syntax and small payload size. Any other similar NAL unit, different from the parameter set NAL units or SEI NAL units that are not allowed in a conventional decoder configuration, can be used as a delimiter.

[0707] In another variation, the encapsulation process can signal the length of the NAL unit only after the NAL unit used as a delimiter. In this case, when the parser recognizes the NAL unit, it continues to parse the remaining data configured by the compact decoder into a continuous sequence of NAL unit lengths, followed by NAL unit data. There is no NAL unit length preceding the NAL unit before the delimiter.

[0708] In another embodiment, the compact decoder configuration does not signal the length in bytes of the NALUnitLength field in the image item associated with the decoder configuration. For example, it could correspond to lengthSizeMinusOne in some previous embodiments. In this case, the parser infers the value of this parameter as a predetermined value, such as 3 bytes.

[0709] In a variation, the value of the parameter is inferred from the parameters defined in the box containing the compact decoder configuration. The MinimizedImageBox can define parameters or indicators to limit the range of some parameters used to encode the image in bytes. For example, the MinimizedImageBox can provide a parameter (e.g., large_item_data_flag) that is equal to 0 when 15 bits are used to signal the size of the image or item, and equal to 1 when the size is represented in 28 bits. Since the byte length of NALUnitLength is used to signal the length of the NAL unit used to encode the item or image, the value of lengthSizeMinusOne can be determined from the MinimizedImageBox parameter. For example, when large_item_data_flag is equal to 1, lengthSizeMinusOne is inferred to allow specifying a value for a NAL unit with a length of up to 2^28 bits (e.g., the value could be 3 to indicate 4 bytes for NALUnitLength). Otherwise, when large_item_data_flag equals 0, lengthSizeMinusOne is inferred to be equal to a value that can represent a NAL unit length of up to 2^15 bits (e.g., the value could be 1 to indicate 2 bytes for NALUnitLength).

[0710] In another variation, when using a compact decoder configuration within a MinimizedImageBox, the length of the NALUnitLength field in the item data has the same value as the parameter specifying the length of the item data in the MinimizedImageBox in bytes. For example, when large_item_data_flag equals 0, the length of NALUnitLength in bits is 15 bits. When large_item_data_flag equals 1, the length of NALUnitLength in bits is 28 bits.

[0711] The syntax for a compact decoder configuration without lengthSizeMinusOne can be as follows, with the same semantics as the previous embodiment:

[0712] aligned(8) class CompactVvcDecoderConfigurationRecord {

[0713] VVC_SPSNALUnit sps_nal_unit;

[0714] VVC_PPSNALUnit pps_nal_unit;

[0715] }

[0716] Figure 4 The main steps in the decapsulation process according to some embodiments of the present invention are illustrated.

[0717] First, in step 401, the media file is parsed to determine the presence of a compact description in the media file in step 402. This could be indicated, for example, by a specific brand in the FileTypeBox or by the presence of a minimized image box.

[0718] If it is determined in step 402 that no compact description exists, the MetaBox's conventional or regular processing is performed in step 409. Otherwise, the processing is applied sequentially through steps 403 to 408.

[0719] When a media file includes a compact description (detected in step 405), this means that at least one minimized image box is present in the media file. The minimized image box is parsed in step 403 to determine the nature of the image described using the compact description. The compact description of the image may include a decoder configuration. In this case, the type of decoder configuration is determined in step 404, meaning whether it is a decoder configuration with regular or conventional syntax according to ISO / IEC 14496-15 (indicating that the compact description mode is inactive) or a compact codec configuration (indicating that the compact description mode is active). The compact codec configuration syntax can be determined using the version or flag parameters indicated in the decoder configuration record. In variations, the compact codec configuration syntax may depend on the presence of a brand. In variations, the compact codec configuration syntax can be determined using the type or version or flag of the box containing the decoder configuration record. For example, a VVC decoder configuration record using regular or conventional syntax is generally provided in a box with the type "vvcC" (i.e., a four-character code registered according to ISO / IEC 14496-15, indicating that the compact description mode is inactive). When using compact syntax, the type of the box can be set to "vvcc" (i.e., set to another four-character code specifically for this purpose, the presence of which indicates that the compact description mode is active).

[0720] When the decoder configuration uses compact syntax, the decapsulation process infers the conventional decoder configuration (i.e., using conventional verbose syntax) in step 406.

[0721] The decapsulation module reconstructs the minimized item selected by the application in step 407 by extracting minimized item data provided in the byte range determined in 403. The decoder for the minimized item data structure can be initialized by configuration data provided in the minimized item data structure (if present) or inferred from the major_brand of the FileTypeBox based on the value of the explicit_codec_type parameter. Then, in step 408, data describing each item in the compact description can be provided to the decoder to generate a decoded version of the item data.

[0722] When using a compact decoder configuration, the minimized picture box has an explicit_codec_type set to 0, and the parser can infer the codec as a predefined type (e.g., VVC codec type) for the main picture item and the alpha picture item (if present). This can also be inferred from the brand provided in the ISOBMFF file. For example, if a brand is associated with the VVC codec format, then alpha_item (if present), gainmap_item (if present), and main_item make their decoder configuration information defined by CompactVvcDecoderConfigurationRecord and compressed using VVC. The same principle can be applied to any MPEG codec type.

[0723] In another embodiment, the compact decoder configuration is used for sample entries of a track, or as an item property associated with an item described in a meta-logic box, and step 409 may include processing steps similar to those in steps 404 to 406 (not illustrated) to parse the compact decoder configuration.

[0724] As an alternative to a compact decoder configuration, one or more control flags can be added to the decoder configuration syntax to control the number of bits used to represent parameters. For example, a control flag may exist that, when set, indicates the decoder configuration is for a single image, and when not set, indicates the decoder configuration is for multiple images. In this case, there may be a bit allocation that depends on the value of the flag. For example, when the flag is set, the parameter corresponding to the video is encoded in 0 bits (meaning the parameter is inferred), and when the flag is set, the number of bits is as defined in ISO / IEC 14496-15. Control flags may exist applied to compressed parameters (as in step 209) to indicate whether reduced bit depth or the expected number of bits from ISO / IEC 14496-15 is used. For example, a flag called `compact_representation` indicates the use of reduced bit depth when set, and indicates the use of a non-compact representation when not set. When used in a FullBox, these flags can be the values ​​of the FullBox's "Flags" field. This allows for maintaining the same syntax for decoder configurations regardless of the codec, and makes conversion from compact representations to the intended representation from ISO / IEC 14496-15 easier. It should be noted that while the examples of decoder configurations primarily refer to MPEG video codecs, the invention can also be applied to other decoder configurations or metadata describing compressed bitstreams and how to set up the appropriate decoder.

[0725] Figure 5 This is a schematic block diagram of a computing device 500 for implementing one or more embodiments of the present invention. The computing device 500 may be a device such as a microcomputer, workstation, or lightweight portable device. The computing device 500 includes a communication bus connected to:

[0726] - The central processing unit 501, labeled as CPU, such as a microprocessor;

[0727] - Random access memory 502, labeled RAM, is used to store executable code of the methods of embodiments of the present invention and registers adapted to record variables and parameters required to implement the methods according to embodiments of the present invention. Its memory capacity can be expanded, for example, by an optional RAM connected to an expansion port.

[0728] - A read-only memory 503, labeled ROM, is used to store a computer program for implementing embodiments of the present invention;

[0729] - Network interface 504, which is typically connected to a communication network, transmits or receives digital data to be processed on the communication network. Network interface 504 can be a single network interface or a collection of different network interfaces (e.g., wired and wireless interfaces, or different types of wired or wireless interfaces). Under the control of the software application running in CPU 501, data packets are written to the network interface for transmission or read from the network interface for reception.

[0730] - The graphical user interface 505 can be used to receive input from the user or display information to the user;

[0731] - The HD-labeled 506 hard drive can be provided as a high-capacity storage device;

[0732] - I / O module 507 can be used to receive / send data to external devices such as video sources or displays.

[0733] Executable code can be stored in read-only memory 503, hard disk 506, or on a removable digital medium such as a disk. Alternatively, the executable code can be received via network interface 504 through a communication network and stored in one of the storage components of the communication device 500 (such as hard disk 506) before execution.

[0734] The central processing unit 501 can be adapted to control and direct the execution of instructions or portions of software code of one or more programs according to embodiments of the present invention, these instructions being stored in one of the aforementioned storage components. For example, upon power-up, the CPU 501 is capable of executing software application-related instructions from the main RAM memory 502 after the instructions have been loaded from the program ROM 503 or the hard disk (HD) 506. Such a software application, when executed by the CPU 501, enables the steps of the flowchart of the present invention to be performed.

[0735] Any step of the algorithm of the present invention may be implemented in software by executing a set of instructions or a program by a programmable computing machine (such as a PC (“personal computer”), DSP (“digital signal processor”) or microcontroller); or in hardware by a machine or special-purpose component (such as a FPGA (“field-programmable gate array”) or ASIC (“application-specific integrated circuit”)).

[0736] 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 falling within the scope of the present invention will be apparent to those skilled in the art.

[0737] When referring to the foregoing exemplary embodiments, those skilled in the art will realize many further modifications and variations. These embodiments are given by way of example only and are not intended to limit the scope of the invention, which is defined only by the appended claims. In particular, different features from different embodiments may be interchanged where appropriate.

[0738] The embodiments of the invention described above can each be implemented individually or as a combination of multiple embodiments. Furthermore, features from different embodiments can be combined where necessary, or where a combination of elements or features from various embodiments in a single embodiment is advantageous.

Claims

1. A method for encapsulating an image in a media file, comprising the following steps: A media file including an image description and / or an image header is generated based on a container mode selected from at least a regular description mode and a compact description mode. The image description and / or image header includes a set of decoder configuration parameters, wherein, compared to the regular description mode, the compact description mode uses fewer parameters for the decoder configuration parameter set and more compact encoding of the parameter values.

2. The method according to claim 1, wherein, When the encapsulation mode indicates a compact description mode, the decoder configuration parameters associated with the reserved or predetermined values ​​in the regular description mode are not present in the generated image description and / or image header.

3. The method according to claim 1 or 2, wherein, When the encapsulation mode indicates a compact description mode, the decoder configuration parameters associated with the multiple image contents in the regular description mode are not present in the generated image description and / or image header.

4. The method according to any one of claims 1 to 3, wherein, When the encapsulation mode indicates a compact description mode, at least one decoder configuration parameter is encoded using a predefined number of bits or bytes less than that of the regular description mode.

5. The method according to any one of claims 1 to 4, wherein, When the encapsulation mode indicates a compact description mode, the decoder configuration parameter set includes a first indication that indicates whether the decoder configuration parameter set includes the length of at least one network abstraction layer unit that is mandatory for decoding the image.

6. The method according to claim 5, wherein, The decoder configuration parameter set also includes a second indication that indicates whether the decoder configuration parameter set includes the length of at least one additional network abstraction layer unit that is not mandatory for decoding the image.

7. The method according to any one of claims 1 to 6, wherein, At least one decoder configuration parameter is the number of network abstraction layer units present in the configuration record of the image.

8. The method according to any one of claims 1 to 7, wherein, The generated media file also includes parameters representing the encapsulation mode.

9. The method according to any one of claims 1 to 8, wherein, The image description and / or image header are included in a minimized image box, and the decoder configuration parameter set is included in a decoder configuration record structure within the minimized image box.

10. A method for decapsulating an image from a media file, comprising the following steps: The image description and / or image header is parsed based on determining a wrapping mode in at least one of a conventional description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, compared with the conventional description mode, the compact description mode parses fewer parameters for the decoder configuration parameter set and more compact encoding of parameter values.

11. The method according to claim 10, wherein, When the encapsulation mode indicates a compact description mode, the method further includes a step of processing the decoder configuration parameter set to obtain a decoder configuration parameter set according to the regular description mode.

12. The method according to claim 11, wherein, The obtained set of decoder configuration parameters according to the conventional description mode includes image size parameters determined from the image size parameters in the image description and / or image header.

13. The method according to any one of claims 10 to 12, wherein, The method includes the step of obtaining parameters representing the encapsulation mode in the media file.

14. An apparatus for encapsulating an image in a media file, comprising: A component for generating a media file including an image description and / or an image header based on a container mode selected from at least a regular description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, compared to the regular description mode, the compact description mode uses fewer parameters for the decoder configuration parameter set and more compact encoding of the parameter values.

15. An apparatus for decapsulating an image from a media file, comprising: A component for resolving an image description and / or image header based on a wrapper mode selected from at least a conventional description mode and a compact description mode, the image description and / or image header including a set of decoder configuration parameters, wherein, compared to the conventional description mode, the compact description mode resolves fewer parameters for the decoder configuration parameter set and more compactly encodes the parameter values.

16. A media file encapsulating an image, comprising a parameter representing an encapsulation mode selected from at least a regular description mode and a compact description mode, wherein, Compared to the conventional description mode, the compact description mode is used to generate an image description and / or image header that includes the decoder configuration parameter set with fewer parameters for the decoder configuration parameter set and more compact encoding of the parameter values.

17. The media file according to claim 16, wherein, The media file conforms to the image encapsulation format according to the High Efficiency Image Format (HEIF) standard.

18. A computer program product, characterized in that, The computer program product includes instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 13.

19. A computer-readable storage medium storing programming instructions that, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 13.